[asterisk-bugs] [JIRA] (ASTERISK-28310) Inconsistent Stasis/AMI event ordering for queue members calling
Nathan Bruning (JIRA)
noreply at issues.asterisk.org
Wed Feb 27 17:56:47 CST 2019
[ https://issues.asterisk.org/jira/browse/ASTERISK-28310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nathan Bruning updated ASTERISK-28310:
--------------------------------------
Summary: Inconsistent Stasis/AMI event ordering for queue members calling (was: Inconsistent Stasis event ordering for queue members calling)
> Inconsistent Stasis/AMI event ordering for queue members calling
> ----------------------------------------------------------------
>
> Key: ASTERISK-28310
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-28310
> Project: Asterisk
> Issue Type: Improvement
> Security Level: None
> Components: Applications/app_queue
> Affects Versions: 15.7.1, 16.1.1
> Environment: any
> Reporter: Nathan Bruning
> Severity: Minor
>
> We are dialing queue members using local channels.
> The main channel will send out an {{AgentCalled}} event, followed by a {{DialBegin}} event.
> The dialing channel, started with {{ast_call}}, will also send events, for example a {{UserEvent}} in the dialplan.
> Because the main channel and dialing channel are handled on separate threads, the main- and dialing events may occur in any order; ie:
> - {{AgentCalled}}, {{DialBegin}}, and then {{UserEvent}} of dialing ch
> - {{UserEvent}} and then {{AgentCalled}}, {{DialBegin}}
> While this is not necessarily wrong, I believe the second ordering is very confusing for consumers of the events, as the {{AgentCalled}} event makes you aware of the logical connection between the queue channel and the dialing channel. It's even more confusing that the order changes now and then, semi-randomly.
> Therefore, I feel it's better to *first* send out the {{AgentCalled}} and {{DialBegin}} events, and *then* call {{ast_call}} on the dialing channel.
> I'll push a patch to gerrit for review.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list