<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 15, 2013 at 5:14 PM, Paul Belanger <span dir="ltr"><<a href="mailto:paul.belanger@polybeacon.com" target="_blank">paul.belanger@polybeacon.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="im">On Tue, Oct 15, 2013 at 3:35 PM, David M. Lee <<a href="mailto:dlee@digium.com">dlee@digium.com</a>> wrote:<br>

><br>
> On Oct 15, 2013, at 12:24 PM, Paul Belanger <<a href="mailto:paul.belanger@polybeacon.com">paul.belanger@polybeacon.com</a>> wrote:<br>
><br>
>> On Tue, Oct 15, 2013 at 1:07 PM, Joshua Colp <<a href="mailto:jcolp@digium.com">jcolp@digium.com</a>> wrote:<br>
>>> Paul Belanger wrote:<br></div></blockquote><div><br></div><div style><snip></div><div style> </div><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="im"></div>
<div class="im"><br>
> And you would have to pass the bridgeId into the DELETE, and passing<br>
> params into deletes is just freaky.<br>
><br>
</div>Ya, this is still an issue I guess. Can a channel live within more<br>
then one bridge? I don't think it can right? So, if DELETE<br>
/channels/{channelId}/bridge asterisk would have to look for said<br>
channel.  Not sure that is the right approach either.<br>
<div class="im"><br></div></blockquote><div><br></div><div style>Nope. Having a channel exist in multiple bridges would have been cool, but would have required another year of development (if not more).</div><div style><br>
</div><div style>There's two reasons why a channel joining a bridge should be an operation on a bridge, and not a channel:</div><div style>(1) The first is what you just pointed out: a channel can only be in one bridge, but a bridge can have many channels. Thus calling addChannel on multiple channels is acceptable; calling bridge on a channel multiple times is not.<br>
</div><div style>(2) Following that, from an OO perspective (which we have going with our resources and their properties/relationships), what changes is the bridge, not the channel. The bridge assumes ownership of the channel; hence it should be operations on the bridge that take ownership and release it.<br>
</div><div style>(2)  A bridge is not a state that a channel is in, which /channels/{id}/bridge implies. A bridge is an object. It has its own lifetime, properties, and state. Saying "bridge some channels" is actually a misnomer now: channels are in a bridge, they may have a bridge supporting them, but the bridge itself is a thing and the channels are just along for the ride.</div>
<div style><br></div><div style>I know that's a pretty sharp departure from previous versions of Asterisk, and goes against the grain of how we think about calls and channels and bridging: but I think it's important that we reflect that, particularly as we flesh out more complicated bridge technologies.</div>
<div style><br></div></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>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></div>
</div>
</div></div>