[asterisk-bugs] [JIRA] (ASTERISK-28053) chan_pjsip: Wrong or missing Q.850 reason in CANCEL

[Friendly Automation (JIRA)]

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

Friendly Automation commented on ASTERISK-28053:
------------------------------------------------

Change 16345 merged by Friendly Automation:
apps/app_dial.c: HANGUPCAUSE reason code for CANCEL is set to AST_CAUSE_NORMAL_CLEARING

[https://gerrit.asterisk.org/c/asterisk/+/16345|https://gerrit.asterisk.org/c/asterisk/+/16345]

> chan_pjsip: Wrong or missing Q.850 reason in CANCEL
> ---------------------------------------------------
>
>                 Key: ASTERISK-28053
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28053
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 13.23.0
>         Environment: Debian 9
> X86_64
>            Reporter: Simone Lazzaris
>            Assignee: Unassigned
>              Labels: patch, pjsip
>         Attachments: debug_q850.txt, qcom_reason850.patch
>
>
> Hi all;
> I have an issue regarding the Q850 reason code in CANCEL messages.
> The scenario is this: number A calls number B; while the second leg is still not established (e.g. while number B is RINGING), A aborts the call.
> Asterisk will receive a CANCEL message with a Reason field like this:
> Reason: SIP;cause=487;text="Request terminated by user" 
> Immediatly, a CANCEL is sent to B, with this Reason
> Reason: Q.850;cause=0
> The correct message that my carrier expect is "cause=16". 
> I've not found a way to set the cause via dialplan. Even setting the "Q(16)" flag within the Dial app doesn't work.
> I've tried to debug the issue and I've found the following line in the debug log:
> chan_pjsip.c: AST hangup cause 0 (no match found in PJSIP)
> I think that the issue is due to the fact that the 487 Reason is not forwarded from leg a to leg b.
> Any hints?



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