| Summary: | ASTERISK-25351: SIP INFO not ACK'd by chan_pjsip on Asterisk 13.5.0 | ||||
| Reporter: | Sean Brady (SeanBrady) | Labels: | |||
| Date Opened: | 2015-08-28 13:31:00 | Date Closed: | 2015-08-28 13:36:27 | ||
| Priority: | Minor | Regression? | No | ||
| Status: | Closed/Complete | Components: | Channels/chan_pjsip | ||
| Versions: | 13.5.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| 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. | Attachments: | ( 0) SIP_packet_trace_obfuscated.rtf | ||
| Description: | 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. | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2015-08-28 13:31:01.311-0500 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: Sean Brady (SeanBrady) 2015-08-28 13:36:28.182-0500 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. By: Federico Santulli (fsantulli) 2016-03-15 18:39:48.389-0500 Any news about this issue? this is really annoying as our provider's sbc is shutting down our calls within few minutes. Could you provide a patch? | ||||