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

[Sébastien Duthil]

On 21/10/16 10:21 AM, Mark Michelson wrote:
> I have opened https://issues.asterisk.org/jira/browse/ASTERISK-26492
> and have attached the patch there. Feel free to try it out and let me
> know on the issue how it works for you.

I've played around with your patch, and it works very well. Thanks for
sharing it!

> I had thought about making the list of channel variables per-ARI app
> instead of global, but I don't know if that's actually desired.

I've looked at how to implement per-application variables, based on
Mark's patch: my goal was to enrich ARI events with only the variables
subscribed by the application that would receive the event. I didn't
know much of the internals of Asterisk, but I understand now that this
is not possible: we must embed all variables required by every
application in all channel snapshots, because when the channel snapshot
is created, we have no idea what application will receive it. This means
that per-application subscription to variables would only add variables
to a global list of ARI variables: there would be no difference between
10 applications subscribing to 1 variable each and 1 application
subscribing to 10 variables.

On 21/10/16 12:32 PM, Kevin Harwell wrote:
> what about adding the desired variables to the event subscribe
> command? Each app could subscribe (or when they subscribe) to an event
> and specify the variable(s) they desire

Applications subscribing to variables upon HTTP requests, as Kevin
proposes, is more flexible than a global configuration, and it does not
conflict with a global list of ARI variables: the global config would
provide a minimal set of variables, and applications subscribing via
HTTP may add variables to this global set. So we could start with a
first version having a global list of ARI variables, defined in the
global configuration, as Mark's patch does, and eventually, in a future
version, add more dynamic subscriptions via HTTP requests if the need is
strong enough for someone to implement it. In my case, the global
configuration is enough.

As Mark says in the Jira issue, the only thing lacking in this patch is
tests, so I intend to add some tests and propose the patch in Gerrit,
unless someone thinks it's unreasonable.

-- 
Sébastien Duthil