[asterisk-dev] [Code Review] 2470: Add API call to perform externally-intiated blind transfers on a bridge

Matt Jordan reviewboard at asterisk.org
Wed May 8 15:12:53 CDT 2013



> On May 8, 2013, 2:29 p.m., Matt Jordan wrote:
> > /team/group/bridge_construction/main/bridging.c, lines 4835-4841
> > <https://reviewboard.asterisk.org/r/2470/diff/4/?file=37138#file37138line4835>
> >
> >     Callers of this function expect that it will return NULL on error. However, this doesn't set transferee to NULL - ao2_cleanup merely derefs the ao2 object, which - if it caused the object to destruct, would result in this being a pointer to oblivion. If the transferer is in the bridge by themselves, transferee will be (potentially) garbage or a pointer to the transferer on exit.
> >     
> >     Although I'm not sure how it would happen, to be safe, you may want to initialize transferee to NULL in case no one is in the bridge and this gets called.
> 
> rmudgett wrote:
>     Matt, I think you misunderstand the code here.  Transferee is always initialized because the loop test is always done.  The loop terminates early if transferee != transferer with transferee holding a reference.

Whoops, yup. My bad.


- Matt


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


On May 2, 2013, 11:10 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2470/
> -----------------------------------------------------------
> 
> (Updated May 2, 2013, 11:10 p.m.)
> 
> 
> Review request for Asterisk Developers, jrose and rmudgett.
> 
> 
> Bugs: ASTERISK-21335
>     https://issues.asterisk.org/jira/browse/ASTERISK-21335
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This adds a new API call to bridging.h called ast_bridge_blind_transfer(). It is intended to be used by channel drivers and other entities that receive external notifications to perform a blind transfer.
> 
> The idea here is to provide the transferer channel, and the target extension and context. Given this information, all parties bridged to the transferer will be transferred to the given location. In the case where the transferer is bridged to multiple peers, the entire bridge is transferred by starting a local channel and swapping the transferer and local channel. In the case where the transferer is bridged to a single party, then that one party is redirected to the given destination.
> 
> Another parameter that the blind transfer code can be given is a framehook. This is useful for cases where the caller of ast_bridge_blind_transfer() wishes to be able to monitor the progress of the new outbound call. The framehook is attached either to the newly-created local channel (in the case of transferring multiple bridged peers) or to the existing transferee channel (in the case of transferring a single channel).
> 
> During implementation discussions, it was noticed that there were some special flags needed for bridges. One such flag always prohibits transfers from occurring on a bridge. This is useful for holding bridges, parking bridges, and other bridges where the participant is not necessarily aware that he is in a bridge. Another flag states that no matter the number of participants in the bridge, the entire bridge should be transferred rather than only transferring a single participant. This is used for bridges that are intended to always be multi-party, such as the bridge created by app_confbridge. I have applied these flags in a few places. Please let me know if there are other bridges where these flags should be applied.
> 
> Unfinished business:
> * There is a large chunk of code that is commented out with regards to parking. The API that this section relies on is currently a work in progress in /team/jrose/bridge_projects/. Once that code has been merged, then the parking-relevant code can be tested.
> * There are likely some small details that I have not addressed. For instance, I do not set any channel variables at all during a blind transfer. It may be desirable to set a BLINDTRANSFER or other variables on channels. Please let me know if there are items that I need to add here.
> * This review is intended only to implement blind transfers, but you will notice in bridging.h an ast_bridge_attended_transfer() function and a stub for it in bridging.c. This is simply a placeholder for now, but it will be implemented soon.
> 
> 
> Diffs
> -----
> 
>   /team/group/bridge_construction/apps/app_bridgewait.c 387543 
>   /team/group/bridge_construction/apps/app_confbridge.c 387543 
>   /team/group/bridge_construction/include/asterisk/bridging.h 387543 
>   /team/group/bridge_construction/include/asterisk/bridging_features.h 387543 
>   /team/group/bridge_construction/include/asterisk/channel.h 387543 
>   /team/group/bridge_construction/include/asterisk/framehook.h 387543 
>   /team/group/bridge_construction/main/bridging.c 387543 
>   /team/group/bridge_construction/main/channel.c 387543 
>   /team/group/bridge_construction/main/manager.c 387543 
>   /team/group/bridge_construction/main/pbx.c 387543 
> 
> Diff: https://reviewboard.asterisk.org/r/2470/diff/
> 
> 
> Testing
> -------
> 
> To test this, I created an AMI action called BlindTransfer. The action takes the transferer channel, context, and extension as an argument. With this action, I was able to test both a one-to-one blind transfer, as well as a transfer of a confbridge. They both worked. I wrote this AMI action as a way of testing this API, but I also documented it in case it is decided that this would be a useful action to have permanently.
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130508/3289eb57/attachment.htm>


More information about the asterisk-dev mailing list