>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>
