On 10/19/2016 06:45 AM, Matthew Jordan wrote:
On Tue, Oct 18, 2016 at 4:02 PM, Joshua Colp <jc...@digium.com> wrote:
Matthew Jordan wrote:
<snip>
There are a few wrinkles with emitting channel variables with
arbitrary events (of which StasisEnd would qualify).
When an event is emitted out of the APIs, it's typically being done so
as a result of a message having been published on the Stasis message
bus. The messages on the bus don't contain a reference to a channel,
but rather a snapshot of the channel. Those snapshots, by default,
don't contain any channel variables, primarily for performance
reasons. Additionally, since dialplan functions can be freely
interchanged with channel variables, it's impossible (or very costly)
to evaluate dialplan function expressions on each snapshot creation.
Unfortunately, you really do need to rely on the messages coming
across the bus. By the time code is processing the sending of a
StasisEnd event, the ast_channel itself may already be gone. As such,
the variables have to be stored on the snapshot in some fashion.
AMI accomplished this by creating a core concept known as 'manager
variables'. These are set directly on the ast_channel structure, and -
when a snapshot is created - are evaluated and copied onto the
snapshot. Again, this is a rather costly operation, but it does limit
the impact of including variables on messages, as you have to
explicitly tell Asterisk which state you want transmitted along with
the channel.
If we wanted a similar concept in ARI, the manager variables could be
reused. I would note that you absolutely will take a performance hit
when using them - building and conveying that much state in every
event is not cheap. Because StasisEnd is rather 'special' - often the
channel core isn't aware of it - I'm not sure how you would convey
variables only on that event and not on all the rest.
The actual raising of StasisEnd is explicitly done inside of Stasis and
lives there. When raised the channel is there and valid. It currently uses a
channel blob as the payload but this could be changed to something else that
would allow channel variables (only channel variables explicitly set on the
channel) to also be added. This would scope the channel variables addition
to only StasisEnd. Now... if we wanted channel variables on every message...
then yeah, it would be difficult.
Two thoughts:
(1) I wonder if anyone needs the state conveyed on events other than
StasisEnd? If Asterisk is maintaining all of your state for you, and
you need to know some part of the state in your external application,
how do you ask for it?
(2) Even if we emit variable state on StasisEnd, how would we know
which state to emit? Would we want to require users to provide it up
front in ari.conf, or through some more dynamic mechanism?
I actually have a patch I've written locally in my spare time that adds
an ari.conf option called "channelvars" that works exactly the same as
for manager.conf. In other words, it modifies channel snapshots to have
the channel variables specified in ari.conf. Then, every channel
snapshot that is part of an event sent on the ARI websocket will have
those variables.
I came up with this idea because in addition to Sebastien's comment
about wanting variables on StasisEnd, other people told me they want
channel variables on other events. Their reasoning being that they don't
want the delay of having to look up channel variables every time channel
state changes. By emitting a subset of channel variables (those that you
care about in ARI), the message size can be limited to whatever you want.
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.
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
