[asterisk-bugs] [JIRA] (ASTERISK-25351) SIP INFO not ACK'd by chan_pjsip on Asterisk 13.5.0

[Sean Brady (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sean Brady updated ASTERISK-25351:
----------------------------------

    Attachment: SIP packet trace obfuscated.rtf

SIP trace of a call setup and SIP INFO packets being received by chan_pjsip sent from the carrier. This call would be torn down by the carrier at just over 23 minutes. 

> SIP INFO not ACK'd by chan_pjsip on Asterisk 13.5.0
> ---------------------------------------------------
>
>                 Key: ASTERISK-25351
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25351
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 13.5.0
>         Environment: FreePBX Distro 6.12.65-29, kernel version 2.6.32-431.el6.i686, Asterisk 13.5.0 using chan_pjsip connecting to a carrier's ACME Packet SBC (unknown version) sitting in front of a Nortel CS2000 switch. 
>            Reporter: Sean Brady
>            Severity: Minor
>         Attachments: SIP packet trace obfuscated.rtf
>
>
> Asterisk is not replying to SIP INFO messages, even when the PJSIP endpoint has dtmf_mode=info enabled. See pastebin URL for PJSIP packet trace. According to the PJSIP documentation you need to explicitly handle SIP INFO packets in chan_pjsip (https://trac.pjsip.org/repos/wiki/FAQ#info-method). 
> I am proposing this is an issue due to the following statement in RFC 2976: "A 200 OK response MUST be sent by a UAS for an INFO request with no message body if the INFO request was successfully received for an existing call."
> In this instance, the lack of response from Asterisk to the SIP INFO packets is causing the carrier's SBC to disconnect the call after about 23 minutes. The explanation for the disconnect is that the carrier is using the replies from the SIP INFO packet to determine if the remote host, Asterisk 13.5.0 in this case, is still active.
> While I believe that the use of the SIP INFO method is inappropriate in this case, there is precedent in the RFC for Asterisk to reply to SIP INFO packets with a "200 OK", it is possible within the framework with apparently little effort, and it ensures interoperability with a major SIP equipment vendor and carrier. 



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