Summary:	ASTERISK-26642: res_pjsip_session: Improper Handling of extra 200 OK from forked INVITE
Reporter:	Tim L (axl127)	Labels:
Date Opened:	2016-12-05 20:30:12.000-0600	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Resources/res_pjsip_session
Versions:	13.11.2	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) ackbye_asterisk.txt
Description:	I am using Kamailio as a SIP Proxy in front of multiple Asterisk servers. I am using 13.11.2 with pjsip. Users can register with Kamailio from multiple devices and Kamailio is performing parallel forking of INVITEs sent to those users. Kamailio will CANCEL all but the first INVITE that receives a 200 OK. However, if two devices respond with a 200 OK at the same time, Kamailio forwards both 200 OKs to Asterisk. I believe Kamailio is required to do this so that a UAC can send an ACK+BYE for all but one of the 200 OKs. What seems to be happening is that neither dialog is actually ended with a BYE, but the SDP answer from the second 200 OK is used, leaving the first one basically unusable. Thank you for your support!
Comments:	By: Asterisk Team (asteriskteam) 2016-12-05 20:30:13.054-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Joshua C. Colp (jcolp) 2016-12-06 06:17:56.865-0600 Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need: 1. The specific steps or actions you took that caused you to encounter the problem. 2. The behavior you expected and the location of documentation that led you to that expectation. 3. The behavior you actually encountered. To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines [2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Tim L (axl127) 2016-12-07 21:49:32.993-0600 Reproducing the issue requires a SIP Proxy (in my case Kamailio) in front of an Asterisk server.  Phones register with Kamailio, but Kamailio forwards the INVITEs to Asterisk to actually handle the call. Steps to reproduce: 1) Register SIP Client A with URI #1 2) Register SIP Clients B and C with URI #2  (both the same) 3) Call URI #2 from client A - send INVITE to Kamailio 4) Kamailio forwards INVITE to Asterisk 5) Asterisk sets up second call leg to call URI #2 - sends INVITE to Kamailio 4) Kamailio forks the INVITE to both B and C 5) Answer the call on B and C at the same time - both send 200 OK very close together 6) Kamailio receives one of the 200 OKs first and sends a CANCEL for the other INVITE, but the other phone has already sent the 200 OK 7) both 200 OKs are forwarded to Asterisk 8) Phones B and C now both think they have a dialog, so the CANCEL is no longer valid and is ignored by the second phone 9) Asterisk sends ACK for first 200 OK 10) Asterisk sends ACK for second 200 OK At this point, both phones have fully established dialogs, but only one of them is actually useful.  One phone can talk but the other can't and doesn't know anything is wrong.  Asterisk should send an ACK followed by a BYE for the second one. According to the PJSIP maintainers, PJSUA will do this by default.  It implements the callback for on_dlg_forked, and the PJSUA implementation sends the BYE.  The PJSUA implementation is in pjsua_call.c and looks like it might actually work for Asterisk too.  It doesn't look like it accesses any data other than what is passed in to it.  If someone with more Asterisk/PJSIP integration could give it a sanity check to make sure it won't cause any obvious problems, I would be willing to try it out in our test environment. By: Joshua C. Colp (jcolp) 2016-12-08 07:51:25.512-0600 Can you please attach a "pjsip set logger on" of this actually happening? The instructions are good but still require a lot of setup. With a SIP trace we can potentially create a SIPP scenario which does this to help determine what to do on our side, as well as to include in the testsuite going forward.