[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=242116#comment-242116 ] 

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

Looking at the pcaps.  There appears to be two things wrong here.  The provider is botching the SIP transaction and we are crashing on their CANCEL.

When we send the INVITE to the provider, they respond with a 100 trying followed by a reINVITE.  They should not be sending us a reINVITE.  The reINVITE is too early since they have not sent a final response for our INVITE yet.  We rightly respond to their reINVITE with a 481 call does not exist which they ACK.  They then repeatedly try new reINVITE transactions without completing them.  When they give up, they send a CANCEL and we crash.  They then send us a 480 unavailable final response to the original INVITE.  The 480 response shows that they didn't misdirect a final response before they sent us a reINVITE.

> 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/General
>    Affects Versions: 13.19.0
>         Environment: CentOS 6.9 64bit
>            Reporter: Leandro Dardini
>            Assignee: Unassigned
>            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, core.srv02-2018-02-11T17-53-10+0100-brief.txt, core.srv02-2018-02-11T17-53-10+0100-full.txt, core.srv02-2018-02-11T17-53-10+0100-locks.txt, core.srv02-2018-02-11T17-53-10+0100-thread1.txt, crash-27666.pcap, crashlog.pcap, debug_log_27666
>
>
> 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)