Mahesh,

I now know what the problem is, but I don't have any idea the cause or how to fix it. Fortunately the issue appears to be our PSTN gateway provider.

See we use a 3rd party for PSTN access. This 3rd party uses a [unknown] SIP proxy in front of their Sonus box.

The problem I have with them is that occasionally their SIP proxy changes the branch= tag in the top VIA which then appears to be a new re-INVITE and I believe SER properly processes it. However, the SIP UA always ignores it and I don't know if it should or not.

Anyhow here is a sample of what I'm referring to. The first re-INVITE is OK and is properly processed however we get a seconds re-INVITE from them (also shown) and this second re-INVITE is received __before__ we receive the ACK for our 200OK which we send back to them in response to the first re-INVITE.

You can see the top VIA is different.

FIRST RE-INVITE U 2005/03/22 18:17:34.949888 216.229.127.80:5060 -> 10.3.0.221:5060 INVITE sip:7246024356@24.154.237.253:5060 SIP/2.0. Via: SIP/2.0/UDP 216.229.127.80:5060;branch=z9hG4bK8152abf9bd6-899f6309. Via: SIP/2.0/UDP 216.229.118.76:4060;branch=z9hG4bK07650ade1b9163d1. To: "Paul" sip:7246024356@216.229.127.80;tag=4217611370. From: sip:4075660914@sip.mycompany.com;tag=0a8eb95c. Call-ID: 2063115359@24.154.237.253. CSeq: 15749 INVITE. Max-Forwards: 69. Contact: sip:4075660914@216.229.118.76:4060. Record-Route: sip:216.229.127.80:5060;lr. Route: sip:10.3.0.221:5060;ftag=4217611370;lr. Allow: OPTIONS, INVITE, CANCEL, ACK, BYE, PRACK, INFO. Accept: multipart/mixed, application/sdp, application/isup, application/dtmf, application/dtmf-relay. Supported: timer. Session-Expires: 240;refresher=uac. Content-Disposition: session;handling=required. Content-Type: application/sdp. Content-Length: 249. . v=0. o=Sonus_UAC 10885 11051 IN IP4 216.229.118.76. s=SIP Media Capabilities. c=IN IP4 216.229.118.100. t=0 0. m=audio 19432 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv.

SECOND RE-INVITE U 2005/03/22 18:17:35.450645 216.229.127.80:5060 -> 10.3.0.221:5060 INVITE sip:7246024356@24.154.237.253:5060 SIP/2.0. Via: SIP/2.0/UDP 216.229.127.80:5060;branch=z9hG4bK9157a393106-899f6309. Via: SIP/2.0/UDP 216.229.118.76:4060;branch=z9hG4bK07650ade1b9163d1. To: "Paul" sip:7246024356@216.229.127.80;tag=4217611370. From: sip:4075660914@sip.mycompany.com;tag=0a8eb95c. Call-ID: 2063115359@24.154.237.253. CSeq: 15749 INVITE. Max-Forwards: 69. Contact: sip:4075660914@216.229.118.76:4060. Record-Route: sip:216.229.127.80:5060;lr. Route: sip:10.3.0.221:5060;ftag=4217611370;lr. Allow: OPTIONS, INVITE, CANCEL, ACK, BYE, PRACK, INFO. Accept: multipart/mixed, application/sdp, application/isup, application/dtmf, application/dtmf-relay. Supported: timer. Session-Expires: 240;refresher=uac. Content-Disposition: session;handling=required. Content-Type: application/sdp. Content-Length: 249. . v=0. o=Sonus_UAC 10885 11051 IN IP4 216.229.118.76. s=SIP Media Capabilities. c=IN IP4 216.229.118.100. t=0 0. m=audio 19432 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv.

I can post a complete example SIP call log which shows this if you would like to look at it.

Also, I wonder if the SIP UA ignores the "second" re-INVITE because it is in a transaction with the first re-INVITE (because it didn't get the ACK back from the PSTN GW provider yet).

I'm not familiar enough with the RFC to know.

The bottom line is that last night I finally got our PSTN GW provider to admit they have something going on. They're looking in to why the top VIA is branching. No solution yet.

Regards, Paul

On Wed, 23 Mar 2005 07:50:37 -0600, Mahesh Subramanya mahesh@aptela.com wrote:

We're dealing with (somewhat) the same issue, interestingly, involving Sonus too. On our end, I've noticed that different UAs deal better (or worse) with this issue - Snoms seem to have no problem responding repeatedly to the same INVITE (whether they should or not is a different issue :-) ), while Polycoms just tend to crap out.

Anyhow, did you figure out a "correct" soln?

cheers