[asterisk-bugs] [JIRA] (ASTERISK-28877) Duplicate RINGING DeviceStateChange AMI events from chan_sip.c

[Joshua C. Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-28877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua C. Colp closed ASTERISK-28877.
-------------------------------------

    Resolution: Not A Bug

There is nothing inherently in AMI that prevents multiple events from occurring with the same information, and nothing in other places to prevent it. It's expected that consumers handle this and not depend on such behavior.

> Duplicate RINGING DeviceStateChange AMI events from chan_sip.c
> --------------------------------------------------------------
>
>                 Key: ASTERISK-28877
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28877
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 13.33.0, 16.10.0
>         Environment: Vanilla Asterisk (no FreePBX et al) on Gentoo on QEMU KVM
>            Reporter: Troy Bowman
>            Severity: Minor
>
> I have an AMI event listener that logs additional events to my queue_log to help me tie in agent device availability into my queue reports.
> Whenever I have tried to upgrade Asterisk to a later version, My AMI event listener would log DeviceStateChange events twice whenever the device would ring.  I have been stuck on Asterisk 13.13 for years because I could not understand why RINGING would be duplicated, but other DeviceStateChange events were fine.
> Today, I finally tracked it down to Gerrit change id I547a458fc59721c918cb48be060cbfc3c88bcf9c and ASTERISK-24488.  It seems to me that this was a hack of sorts to get the RINGING Device State Change event through to the newer (at the time) Stasis Message Bus code because of some kind of race condition.
> I realize that I should migrate to chan_pjsip, but I am still not ready to do that in production yet.  I fear that since chan_sip is EoL, no one will care about this, but I am reporting it anyway.  For now, I am simply commenting out those lines of code that duplicate the event.
> If it is intended that the same AMI events should be sent multiple times, then I guess I'll have to write code that somehow debounces events on my side.  It is my opinion that the AMI events should only be sent once per event.



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