Summary:	ASTERISK-27280: app_dial: Q Option Unexpectedly Removing Reason:SIP cause Header
Reporter:	Paul Brooks (javauser)	Labels:
Date Opened:	2017-09-19 17:58:16	Date Closed:
Priority:	Trivial	Regression?
Status:	Open/New	Components:	Applications/app_dial Channels/chan_pjsip
Versions:	14.6.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	Debian 9.0 Stretch	Attachments:	( 0) asteriskq850queuetest.zip ( 1) asteriskQ850test.zip
Description:	I am using Asterisk 14.6.0 with the PJSIP channel driver and I am interested in using Q(NONE) as a Dial option (parameter) in order to suppress the Reason:Q.850 header from appearing in the SIP Cancel messages that result from a call being answered elsewhere. Curiously, the addition of the Q parameter to the Dial Application, which appears to have occurred with the release of Asterisk 13, is not listed in the “New in 13” section of the Asterisk documentation. Nonetheless, starting with that version, the Q parameter appears as an option within the Dial application documentation, which explains that Q(cause) is used to specify the Q.850/Q.931 cause to send on unanswered channels when another channel answers the call. Of particular interest to me is the part of the documentation that says, “You can also specify 0 or NONE to send no cause”. The reason I want to suppress the Reason:Q.850 header from appearing in the Cancel messages is because several brands of SIP phones are getting confused by its presence and improperly logging these “answered elsewhere” calls as missed calls (Obi, Grandstream and Yaelink are some that I verified). With the old SIP channel driver the Reason:Q.850 did not appear in the Cancel messages and under this circumstance these phones behave well, not improperly logging the call. But the Q(NONE) option is not working for me. Please observe. Without Q(NONE) as a Dial parameter, what I see in the SIP Cancel message are two Reason headers (excerpt from Cancel message): CSeq: 6562 CANCEL Reason: Q.850;cause=26 Reason: SIP;cause=200;text="Call completed elsewhere" Max-Forwards: 70 User-Agent: Asterisk PBX 14.6.0 Content-Length: 0 However, with Q(NONE) specified as a Dial parameter, what I see in the SIP Cancel message is that the wrong Reason header appears to have been suppressed (excerpt from Cancel message): CSeq: 19076 CANCEL Reason: Q.850;cause=0 Max-Forwards: 70 User-Agent: Asterisk PBX 14.6.0 Content-Length: 0 Why is the Reason:SIP header missing in the Q(NONE) case? What I expected to see with the use of the Q(NONE) option was the removal of the Reason:Q.850 header and the continued presence of the Reason:SIP header. This seems to be a bug.
Comments:	By: Asterisk Team (asteriskteam) 2017-09-19 17:58:17.519-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: Rusty Newton (rnewton) 2017-09-22 07:05:29.055-0500 Does look like a bug. Can you provide your dialplan and pjsip configuration along with a full Asterisk log showing the reproduction with pjsip traffic, along with the warning,error,notice,verbose and debug output? By: Paul Brooks (javauser) 2017-09-22 16:19:56.744-0500 Attached are the traces requested. The logger output came out almost identical to the CLI output that I captured. The extensions.conf and pjsip.conf files are the exact files used to perform this test. Within all the attached files I redacted 3 things: passwords, WAN IPs, and phone numbers. This test was run with with the Q(NONE) option passed to the Dial application. You can easily find the two CANCEL messages in the SIP trace and see that they are missing the Reason:SIP header. It should be trivial to duplicate this test. If you remove the Q(NONE) option from the Dial Application and make a test call you will see the Reason:SIP header return. By: Paul Brooks (javauser) 2017-09-26 19:09:54.363-0500 I attached files related to a second test performed with the Q(NONE) option passed to the Dial Application. The configuration for the second test was slightly different than the first, and the results -- while they do also demonstrate that the Q(NONE) parameter appears broken -- are different from the first test. The first test (first attachment) was a multiring scenario with the use of Local channels where the Q option passed to the Dial() step in the outer level, i.e. not overridden with the Dial() step that takes place in the Local channel. The second test (second attachment) was also a mutliring scenario, but the Q option is specified in the inner level, i.e. specified with the Dial() step that takes in the Local channel. This second test, in contrast to the first, uses the Queue() application and its ringall strategy to establish the multring scenario. As demonstrated in my previous posts, the first scenario shows that using the Q(NONE) option removes the wrong Reason: header in the Cancel Messages. However, as demonstrated by this new test involving the Queue() application, the use of the Q(NONE) option in the Dial() application has no effect at all. The traces show that NEITHER Reason: header is removed from the SIP Cancel messages; in fact, it doesn't even change the value of the Q.850 reason code showing in the message. Any effort to fix the functionality of the Q Parameter of the Dial() application should necessarily address its non functionality in all usable cases, including an outer Dial() command, an inner Dial() command within a Local Channel, and including the use of the Queue() application as illustrated in my second test. All relevant config files, logs and CLI capture are included in the attachment for the second test. Thank you in advance for your attention to these details. By: Paul Brooks (javauser) 2017-09-29 01:41:34.695-0500 FWIW, regarding the second multiring scenario involving Queue(). I ran that same test again after tweaking the queues.conf file by adding /n as a local channel modifier to the member, just to be sure that the Q option wasn't being lost when the Local channel was being optimized out of the path. So the member looked like this, member => Local/payphonetest3-0000FFFF0001@Q_Dialer/n,,,PJSIP/payphonetest3 But alas, it yielded the same result. The Q option still had no effect on the Reason: headers appearing in the Cancel message. I did confirm by observation that the addition of /n changed the number of active channels showing in the CLI after answer. It just didn't change the result of the CANCEL Q.850 problem. By: Daniil (daniil.rostov) 2018-10-12 02:13:07.322-0500 My Asterisk is 14.7.6 and it have problem too. Why do not work option "suppress_q850_reason_headers=yes" for endpoint? By: Paul Brooks (javauser) 2018-10-30 13:47:47.928-0500 Version 14.6.2 doesn't have the endpoint option suppress_q850_reason_headers. Perhaps the option was added as a way to address this issue? Interesting other thing, too. When I upgrade to Asterisk 16 without changing any settings, my SIP phones are no longer logging calls as "missed" whenever they are answered elsewhere, even without suppress_q850_reason_headers enabled. Seems like something is different in the later version that might render this issue resolved?