Thoughts below.

On Tue, Oct 11, 2016 at 2:04 PM, Sébastien Duthil
<> wrote:
> Hi everyone,
> Sylvain Boily and I gave a talk during Astridevcon 2016 about our usage
> of ARI in the XiVO project [1]. We'd like to discuss some of the issues
> we encountered, to see if other people have had similar issues, and how
> we could address them. We'll stick to one issue per thread.
> Current ARI behavior:
> Given a channel is in the Stasis application, when this channel is hung
> up, a StasisEnd event is generated on the websocket. [2]
> Constraints:
> - an ARI application that must do some channel-variable-based logic when
> it receives a StasisEnd event
> - the ARI application is stateless (because stateless scales better, is
> easier to test, etc.)
> Issue:
> There is no reliable way for the ARI application to know what variables
> were set on the channel that left. The StasisEnd event may happen
> because the channel was redirected: in this case, the ARI application
> may still get the channel variables. But the StasisEnd event may also
> happen because the channel was hung up: in this case, the ARI
> application can't get the channel variables, as the channel does not
> exist anymore. The only way to get around this issue is for the ARI
> application to keep track of channel variables, which is painful for a
> stateless application (external storage).
> Proposition:
> The StasisEnd event (and also the ChannelDestroyed event) should include
> the list of variables of the channel and their values. This would give
> the ARI application all the necessary information to execute its logic.
> Questions:
> - Does anyone else have similar issues?
> - What do you think of the proposition? (difficulty to implement?
> performance impact? apply to other events?)
> - Do you have other propositions to address this issue? For example,
> something like an additional Asterisk module that would keep the
> variable values, and emit new ARI events containing the variable values?
> Thank you.
> [1]
> [2]
> --
> Sébastien Duthil

First off, sorry about the delayed response.  Your proposal sounds
reasonable to me - that is to say, I can't see anything wrong with
adding that behavior.  Perhaps making channel variable dumping on
StasisEnd optional instead of mandatory would be better, but other
than that everything seems sane.  Maybe Josh or Mark might want to
weigh in on it.

Matthew Fredrickson
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA

-- Bandwidth and Colocation Provided by --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:

Reply via email to