On Mon, Sep 8, 2014 at 1:46 PM, Mark Michelson <mmichel...@digium.com> wrote:
> I had a read of this, and the only rule on there that I disagreed with was: > > >Channel C1 leaves bridge B1 which owns X1. C1 is the last remaining > channel in the bridge when it leaves: > >C1 takes ownership of X1. The bridge remains affiliated with X1, but > should be disposed of shortly. > > Mainly, the "but should be disposed of shortly" was what I disagreed with > here. This happens to be the case for bridges that are created by app_dial > or app_queue, but does not work well for things like Stasis bridges. Stasis > bridges are created and destroyed based on the application's needs. For > something like a conferencing app, it's possible that the Stasis > application will create a mixing bridge, and then use that same bridge for > multiple conference calls. Since the bridge does not get disposed of after > the last channel has left, the bridge remains affiliated with its current > call ID. Based on entering rules, this means that all calls that use this > bridge will end up reusing the same call ID. > > I think that the rule I cited should be amended such that C1 takes > ownership of X1 and the bridge becomes unaffiliated with any call ID. > > Other than that the basic rules look good to me. > > For unreal/local channels, I didn't quite understand the trouble you were > trying to communicate with the bullet point about the call ID associated > with the ;1 half of a local channel being the winning one. It may help to > provide a more concrete scenario with channel and bridge names (and > potentially even a diagram) that illustrates the problem. > Ah, that's a good point. I wasn't thinking of bridges that get repurposed like stasis bridges and conference bridges. I'll change that part of the spec so that if the last channel leaves a bridge, it loses association entirely. I can't think of any negatives off the top of my head with that approach anyway aside from maybe losing some tags for some logs related to bridge destruction in the more normal cases, but since those bridges aren't really involved with the call anymore at that point this is acceptable. I'll make sure to include a diagram detailing the troubles with local channel chains soon. Thanks for the suggestion. -- Jonathan R. Rose Digium, Inc. | Software Engineer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US direct +1 256 428 6139 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: http://lists.digium.com/mailman/listinfo/asterisk-dev
