[jitsi-dev] Fwd: [jitsi-issues] [JIRA] Created: (JITSI-1016) SIP only responds to the first 2xx response to an INVITE


#1

Hi robymcandrew,

is there an easy way to setup an environment so I can reproduce this
issue? In case you have such can you grant me access to it so I can
test?

Thanks
damencho

···

---------- Forwarded message ----------

From: robymcandrew (JIRA) <jira-no-reply@java.net>

Date: Wed, Feb 22, 2012 at 8:17 PM
Subject: [jitsi-issues] [JIRA] Created: (JITSI-1016) SIP only responds
to the first 2xx response to an INVITE
To: issues@jitsi.java.net

SIP only responds to the first 2xx response to an INVITE
---------------------------------------------------------

            Key: JITSI\-1016
            URL: http://java.net/jira/browse/JITSI-1016
        Project: jitsi
     Issue Type: Bug

Affects Versions: 1.0
Environment: Windows 7
Reporter: robymcandrew
Priority: Minor
Attachments: Jitsi.zip

As discussed with Emil Ivov on the dev group.

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.

This 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.

Attached is a zip containing my SIPp scripts and a Wireshark trace.
Note that one SIPp script deliberately waits for the CANCEL before
responding to the INVITE. This simulates the CANCEL and 200 crossing
in the network. The Wireshark trace has only parts of the initial
INVITE. I can re-run it a catch the rest, but I'm out of time tonight.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira