On Tue, Oct 18, 2016 at 9:26 AM, Joshua Colp <jc...@digium.com> wrote:
> Matt Fredrickson wrote:
> <snip>
>> 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.
> I don't think that channel variables are substantial enough in the case
> where this isn't being used to really need to adding a knob to turn it
> on/off. That's just me, though.

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.

Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Reply via email to