[asterisk-dev] Defining a call under the new bridging architecture

[Jonathan Rose]

On Mon, Sep 8, 2014 at 1:46 PM, Mark Michelson <mmichelson at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140908/63614090/attachment.html>