<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 8, 2014 at 1:46 PM, Mark Michelson <span dir="ltr"><<a href="mailto:mmichelson@digium.com" target="_blank">mmichelson@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><span style="color:rgb(34,34,34)">I had a read of this, and the only rule on there that I disagreed with was:</span><br></div></div>
<br>
>Channel C1 leaves bridge B1 which owns X1. C1 is the last remaining channel in the bridge when it leaves:<br>
>C1 takes ownership of X1. The bridge remains affiliated with X1, but should be disposed of shortly.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Other than that the basic rules look good to me.<br>
<br>
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.<span class=""><font color="#888888"><br>
</font></span></blockquote></div><br><br>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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'll make sure to include a diagram detailing the troubles with local channel chains soon. Thanks for the suggestion.</div><div class="gmail_extra"><div><br></div>-- <br><div dir="ltr">Jonathan R. Rose<br>Digium, Inc. | Software Engineer<br>445 Jan Davis Drive NW - Huntsville, AL 35806 - US<br>direct +1 256 428 6139 <br><br>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a><br></div>
</div></div>