[asterisk-bugs] [JIRA] (ASTERISK-29437) ARI / channel events: events emitted after ChannelDestroyed

[Joshua C. Colp (JIRA)]

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

Joshua C. Colp commented on ASTERISK-29437:
-------------------------------------------

Okay, the fact you have two applications would be why this is happening. Ordering is only guaranteed at an application level. 84 and 87 are published to "noOp" while 91 and 93 are published to "bridge-dial". There is no guarantee of ordering between the two applications. They could go out of order, they might not.

> ARI / channel events: events emitted after ChannelDestroyed
> -----------------------------------------------------------
>
>                 Key: ASTERISK-29437
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29437
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_ari_channels
>    Affects Versions: 16.16.0
>            Reporter: Jean Aunis - Prescom
>            Assignee: Unassigned
>            Severity: Major
>         Attachments: events_outoforder.pcap, full.txt
>
>
> It happens randomly that ChannelHangupRequest and StasisEnd events are emitted by Asterisk after the ChannelDestroyed event.
> As far as I understand, ChannelDestroyed should always be the last event emitted for a given channel, so ChannelHangupRequest and StasisEnd should be always emitted before.
> I'm attaching the full log and a wireshark capture of the ARI Websocket highlighting the issue:
> - a SIP call is received and cancelled after 2 seconds
> - when the CANCEL request is received, ARI events are emitted in this order :
> 1- ChannelDestroyed (packets 84 and 87)
> 2- ChannelHangupRequest (packet 91)
> 3- StasisEnd (packet 93)



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