[asterisk-bugs] [JIRA] (ASTERISK-27666) Checking the HANGUPCAUSE variable, crash asterisk

[Richard Mudgett (JIRA)]

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

Richard Mudgett commented on ASTERISK-27666:
--------------------------------------------

We require additional debug to continue with triage of your issue. Please follow the instructions on the wiki [1] for how to collect debugging information from Asterisk. For expediency, where possible, attach the debug with a '.txt' file extension so that the debug will be usable for further analysis.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

>From the pcap:
Who is 138.201.140.216?
Who is 81.92.186.135?
Looking at the SDP, both sides seem to be Asterisk 13.19.0

Asterisk crashed trying to process a CANCEL.  From the pcap 138.201.140.216 seems to be your Asterisk.

A debug log of the whole call from the crashed Asterisk would be useful to know what Asterisk was thinking before the crash.


Please be aware that there is not active maintainer of chan_sip.  It is wholly supported by the community and response times will reflect that.

> Checking the HANGUPCAUSE variable, crash asterisk
> -------------------------------------------------
>
>                 Key: ASTERISK-27666
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27666
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/CallCompletionSupplementaryServices
>    Affects Versions: 13.19.0
>         Environment: CentOS 6.9 64bit
>            Reporter: Leandro Dardini
>            Severity: Minor
>         Attachments: core.srv02-2018-02-11T07-50-18+0100-brief.txt, core.srv02-2018-02-11T07-50-18+0100-full.txt, core.srv02-2018-02-11T07-50-18+0100-locks.txt, core.srv02-2018-02-11T07-50-18+0100-thread1.txt, crashlog.pcap
>
>
> I usually log the HANGUPCAUSE when the Dial command doesn't succeed. I discovered, with one particular provider, it crashes asterisk. Here the simple asterisk dialplan:
> {noformat}
>         9999 => {
>              Dial(SIP/999383371137 at crashprovider);
>              NoOp(This is CallEnd - DIALSTATUS is ${DIALSTATUS} - HANGUPCAUSE is ${HANGUPCAUSE});
>              }
> {noformat}
> In attach, you'll find the crash report and the pcap for the traffic with the server. The call was made from extension 103 (103-DEVEL)



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