[asterisk-dev] [Code Review]: bridging: Holding bridge technology and app_bridgewait

[jrose]

> On Feb. 28, 2013, 12:12 p.m., Joshua Colp wrote:
> > /team/jrose/bridge_projects/apps/app_bridgewait.c, lines 170-174
> > <https://reviewboard.asterisk.org/r/2342/diff/3/?file=33639#file33639line170>
> >
> >     Do you do this just so you don't have to rely on module loading loading the bridge technology first?

At first this was just a statically created bridge created on load and yes, the reason for the change was largely inspired by the realization that loading order would need to be addressed in that case. But that could have been solved pretty trivially with loading priorities I think. Richard and I settled on this being the right approach for a couple reasons, among them being that the holding bridge used here is going to be somewhat impermanent as the idea is really to have numerous holding bridges later on.


- jrose


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2342/#review7960
-----------------------------------------------------------


On Feb. 25, 2013, 9:49 a.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2342/
> -----------------------------------------------------------
> 
> (Updated Feb. 25, 2013, 9:49 a.m.)
> 
> 
> Review request for Asterisk Developers and rmudgett.
> 
> 
> Summary
> -------
> 
> This fulfills some of the preliminary goals needed for refactoring parking. First I've created a bridging technology that is very minimalistic in nature (it doesn't do any actual communication between channels on a given holding bridge) for storing parked calls. This technology will also likely be used for queues and maybe some other stuff later on. Second, I've created an application that holds a reference to a single holding bridge which can place channels into the holding bridge.  It includes some options for playing music on hold, ringing, and for breaking the bridge (such as in a queue/park timeout) after a certain amount of time.
> 
> I haven't implemented any kind of silence generation since I'm not sure it would be necessary and I'm also just plain not sure how to do that at the moment.
> 
> 
> This addresses bug ASTERISK-21059.
>     https://issues.asterisk.org/jira/browse/ASTERISK-21059
> 
> 
> Diffs
> -----
> 
>   /team/jrose/bridge_projects/apps/app_bridgewait.c PRE-CREATION 
>   /team/jrose/bridge_projects/bridges/bridge_holding.c PRE-CREATION 
>   /team/jrose/bridge_projects/include/asterisk/bridging.h 381895 
> 
> Diff: https://reviewboard.asterisk.org/r/2342/diff
> 
> 
> Testing
> -------
> 
> So far I've just been testing the app against the options and seeing how the channels work in bridges. Everything seems to work as expected.
> 
> exten => 40,1,Answer()
> exten => 40,n,BridgeWait(mS(8))
> exten => 40,n,Playback(tt-weasels)
> 
> exten => 41,1,Answer()
> exten => 41,n,BridgeWait(rS(10))
> exten => 41,n,Playback(queue-youarenext)
> 
> exten => 42,1,Answer()
> exten => 42,n,BridgeWait()
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130228/2dcca602/attachment-0001.htm>