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

[Sean Brady (JIRA)]

Sean Brady created ASTERISK-25351:
-------------------------------------

             Summary: 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


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)