[asterisk-dev] ARI StasisEnd event vs. channel variables

[Sébastien Duthil]

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] http://fr.slideshare.net/SylvainBoily2/ari-xivo-astricon2016
[2]
https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+REST+Data+Models#Asterisk13RESTDataModels-StasisEnd

-- 
Sébastien Duthil