[asterisk-bugs] [JIRA] (ASTERISK-27280) Dial Application Q Option Unexpectedly Removing SIP cause Header

[Paul Brooks (JIRA)]

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

Paul Brooks commented on ASTERISK-27280:
----------------------------------------

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 at 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.


> Dial Application Q Option Unexpectedly Removing SIP cause Header
> ----------------------------------------------------------------
>
>                 Key: ASTERISK-27280
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27280
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_dial, Channels/chan_pjsip
>    Affects Versions: 14.6.0
>         Environment: Debian 9.0  Stretch
>            Reporter: Paul Brooks
>            Assignee: Unassigned
>            Severity: Trivial
>         Attachments: asteriskq850queuetest.zip, asteriskQ850test.zip
>
>
> 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.



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