[asterisk-app-dev] Originate/Channel Creation as a two step process

[Ben Langfeld]

>On Thu, Dec 5, 2013 at 10:57 AM, Ben Langfeld <ben at langfeld.me> wrote:
>> Thanks for starting this discussion here Matt.
>>
>> I would be satisfied by either of the two main proposed solutions.
>>
>> My implementation of a FreeSWITCH Inbound-Event-Socket app goes for the
>> "specify channel ID" approach. In this case I can just create a UUID
myself.
>>
>This one get my vote, plus we can just see how FreeSWITCH does it, trolo.
:)
>
>> I would be fine with requesting allocating of a UUID from Asterisk, but
I'm
>> not sure how this is really different from pre-allocating a
"proto-channel".
>>
>> Anything that doesn't ensure that I have the channel's uniqueid before I
>> request origination is not a solution and means that I have to go
>> single-threaded to guarantee correctness. We currently do this in
Adhearsion
>> and it hurts performance horribly.
>>
>What does your code look like to to day for AMI async originate? Can
>you share something that compares Asterisk to FreeSWITCH in that
>aspect.

I'd be glad to explain that, Paul. Also, hopefully my subscription to this
list is now working so I'll be replying correctly after this email.

On both Asterisk and FreeSWITCH, we have a routing actor which processes
AMI events and where they apply to a channel (a Call in Adhearsion), they
are routed to an actor for each individual active channel whose state we
are tracking. It looks up the applicable Call actor from a registry it
holds, mapping call ID to the actors.

Maintaining the correctness of this registry is the tricky part, and on
FreeSWITCH is simple. When we originate a new channel, we spin up the
actor, it creates itself an ID (a UUID), registers itself with the event
router and then instructs FreeSWITCH to register a call with the same ID.
In this manner, we ensure that the router is capable of correctly routing
events regardless of their ordering to the individual call actor.

On Asterisk, we have two complications, one of which is the fact that
channels are renamed. This means that we have to strictly process events in
order in order to ensure that renames are applied before subsequent events
with a new channel name encounter a registry miss.

Thankfully in Asterisk 12 the rename issue is gone, so we can now simplify
this and more quickly dispatch events to their appropriate threads. The
exception to this is in channel origination; here we specify a channel
variable of `punchblock_call_id`, containing the same UUID we use on
FreeSWITCH. We then have to maintain the registry on the basis of the
channel name requested and do fuzzy matches until we receive a VarSet event
in order to grab the actual channel name (in Asterisk 12 UniqueID) of the
channel and update the registry. This leaves us open to incorrect matches
in the meantime (you can't concurrently originate calls to the same channel
name or we'll get them mixed up).

If we were to drop this fuzzy matching on channel name, which is after all
part of the point of rationalised permanent channel IDs, we would need to
have the Call actor's initial event registration be definitive (as on
FreeSWITCH). The two proposals are acceptable solutions to this.

If the way we deal with Asterisk now sounds complicated and error-prone,
that's because it is. If my explanation doesn't meet your needs, do feel
free to prompt for further detail and I'd be happy to help.

This last problem needs to be solved in order for us to be able to make use
of the huge amount of work that went into maintaining permanent unique IDs
for channels; it really is all or nothing unfortunately.

>
>--
>Paul Belanger | PolyBeacon, Inc.
>Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
>Github: https://github.com/pabelanger | Twitter:
https://twitter.com/pabelanger>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131206/0e2b833f/attachment.html>