[jitsi-dev] Possible SIP bug with handling multiple 2xx to INVITE


#1

I've been using Jitsi to test some proxy functionality, and I think I have an issue if multiple forked legs answer.

My scenario is Jitsi calls into a proxy which forks the call to two destinations. Both destinations send "200 OK" to the INVITE, simulating a simultaneous answer.

The proxy generates a CANCEL to the second leg, but the UA simply sends a "200 OK" to the CANCEL as per RFC 3261 Section 9.2 (The UAS has sent a final response to the INVITE so it cannot send a 487).

The proxy forwards both 200 responses back to Jitsi, as per RFC 3261 Page 110.

Jitsi should send ACKs to both "200 OK" responses, and then send a BYE to the second leg (as it doesn't want two connections). See RFC 3261 Section 13.2.2.4.

I am seeing ACK to only the first 200; the second 200 is simply absorbed.

I can supply Wireshark traces and the SIPp scripts I am using as my UASs if required, but I'd have to modify them to remove customer info.....

I am running 1.0-beta1-nightly.build.3820 on Windows 7

Andy Miller
Crocodile RCS Ltd


#2

Hey Andrew,

Could you please open a ticket in the tracker? We'd have to check if we
get the second OK from our SIP stack and if so make sure we do the ACK/BYE.

Also, is this actually breaking an use case or is it just a 3261
compliance test? It doesn't sound like something that could happen very
easily so I am trying to confirm if it's also a corner case for you or
if it's somehow urgent.

Cheers,
Emil

···

On 22.02.12 18:43, Andrew Miller wrote:

I've been using Jitsi to test some proxy functionality, and I think I
have an issue if multiple forked legs answer.

My scenario is Jitsi calls into a proxy which forks the call to two
destinations. Both destinations send "200 OK" to the INVITE, simulating
a simultaneous answer.

The proxy generates a CANCEL to the second leg, but the UA simply sends
a "200 OK" to the CANCEL as per RFC 3261 Section 9.2 (The UAS has sent a
final response to the INVITE so it cannot send a 487).

The proxy forwards both 200 responses back to Jitsi, as per RFC 3261
Page 110.

Jitsi should send ACKs to both "200 OK" responses, and then send a BYE
to the second leg (as it doesn't want two connections). See RFC 3261
Section 13.2.2.4.

I am seeing ACK to only the first 200; the second 200 is simply absorbed.

I can supply Wireshark traces and the SIPp scripts I am using as my UASs
if required, but I'd have to modify them to remove customer info.....

I am running 1.0-beta1-nightly.build.3820 on Windows 7

Andy Miller
Crocodile RCS Ltd

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#3

Emil,

It can happen in the real world, but it is rare. It becomes much more likely in networks with long round-trips between the forking proxy and the UASs.

In the event that it happens, you get a stuck call to one UAS, and potentially a billing issue. I found it whilst testing billing.

I would not describe it as urgent, but it is worthwhile.

I will raise a ticket on the tracker.

Andy Miller
Crocodile RCS Ltd

···

On 22/02/2012 17:35, Emil Ivov wrote:

Hey Andrew,

Could you please open a ticket in the tracker? We'd have to check if we
get the second OK from our SIP stack and if so make sure we do the ACK/BYE.

Also, is this actually breaking an use case or is it just a 3261
compliance test? It doesn't sound like something that could happen very
easily so I am trying to confirm if it's also a corner case for you or
if it's somehow urgent.

Cheers,
Emil

On 22.02.12 18:43, Andrew Miller wrote:

I've been using Jitsi to test some proxy functionality, and I think I
have an issue if multiple forked legs answer.

My scenario is Jitsi calls into a proxy which forks the call to two
destinations. Both destinations send "200 OK" to the INVITE, simulating
a simultaneous answer.

The proxy generates a CANCEL to the second leg, but the UA simply sends
a "200 OK" to the CANCEL as per RFC 3261 Section 9.2 (The UAS has sent a
final response to the INVITE so it cannot send a 487).

The proxy forwards both 200 responses back to Jitsi, as per RFC 3261
Page 110.

Jitsi should send ACKs to both "200 OK" responses, and then send a BYE
to the second leg (as it doesn't want two connections). See RFC 3261
Section 13.2.2.4.

I am seeing ACK to only the first 200; the second 200 is simply absorbed.

I can supply Wireshark traces and the SIPp scripts I am using as my UASs
if required, but I'd have to modify them to remove customer info.....

I am running 1.0-beta1-nightly.build.3820 on Windows 7

Andy Miller
Crocodile RCS Ltd