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

Wed May 8 14:39:36 CDT 2013

> On May 8, 2013, 4:11 p.m., rmudgett wrote:
> > /team/group/bridge_construction/main/bridging.c, line 4932
> > <https://reviewboard.asterisk.org/r/2470/diff/4/?file=37138#file37138line4932>
> >
> >     Transferrer is misspelled throughout this patch and many other places.  There are two r's in a row. :)

I have mixed feelings about this observation.

On the one hand, if you look in a dictionary at the word "transfer" it will tell you that the word "transferrer" refers to someone who transfers. On the other hand, if you look at RFC 5589 (which discusses SIP transfers) as an example, it actually uses the word "transferor" as the name of the party that transfers a call. On the other hand, "transferer" fits the commonly used form of having "action" + "er" for the person performing the action and "action" + "ee" for the one receiving the action.

Furthermore, have a look at the following:
root at levin:/usr/src/asterisk/trunk# wcgrep transferrer | wc -l
1
root at levin:/usr/src/asterisk/trunk# wcgrep transferer | wc -l
235
root at levin:/usr/src/asterisk/trunk# wcgrep transferor | wc -l
8

As you can see, by spelling the word correctly in this diff, I'll actually be creating a rift. It will be difficult to keep track of where the word is spelled correctly and where it is spelled incorrectly if I introduce the 43 new uses of "transferrer" to this review. The alternative would be to use some sed magic to change every instance of "transferer" to "transferrer" but that would make the scope of this review much larger than it needs to be.

As a final data point, I'd just like to point out that the spell checker for Google Chrome does not recognize "transferrer", "transferer", or "transferor" as being spelled correctly.

So as much as I hate to leave a misspelled word in, I feel like changing it in this case will do more harm than good. So I think the way to go here is, for this review anyway, just leave things consistent. Once all current transfer work is merged into trunk, then perhaps that would be a time to change the spelling of the variable and documentation. For now, I'm dropping this issue.

- Mark

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

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/fa27f392/attachment-0001.htm>