[Serusers] Re: re-INVITES and dropped calls - ever figure it out?

[Java Rockx]

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 at 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 at 216.229.127.80>;tag=4217611370.
From: sip:4075660914 at sip.mycompany.com;tag=0a8eb95c.
Call-ID: 2063115359 at 24.154.237.253.
CSeq: 15749 INVITE.
Max-Forwards: 69.
Contact: sip:4075660914 at 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 at 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 at 216.229.127.80>;tag=4217611370.
From: sip:4075660914 at sip.mycompany.com;tag=0a8eb95c.
Call-ID: 2063115359 at 24.154.237.253.
CSeq: 15749 INVITE.
Max-Forwards: 69.
Contact: sip:4075660914 at 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 at 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
> 
>