[asterisk-bugs] [JIRA] (ASTERISK-26642) pjsip: Improper Handling of extra 200 OK from forked INVITE

Tim L (JIRA) noreply at issues.asterisk.org
Wed Dec 7 21:50:11 CST 2016


    [ https://issues.asterisk.org/jira/browse/ASTERISK-26642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234121#comment-234121 ] 

Tim L commented on ASTERISK-26642:
----------------------------------

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.



> pjsip: Improper Handling of extra 200 OK from forked INVITE
> -----------------------------------------------------------
>
>                 Key: ASTERISK-26642
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26642
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Third-Party/pjproject
>    Affects Versions: 13.11.2
>            Reporter: Tim L
>            Assignee: Tim L
>            Severity: Minor
>
> 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!



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list