[asterisk-dev] [Code Review] 2654: Make built-in attended transfer feature complete

[Mark Michelson]

> On July 4, 2013, 10:29 p.m., opticron wrote:
> > /trunk/main/bridging_basic.c, lines 1512-1520
> > <https://reviewboard.asterisk.org/r/2654/diff/1/?file=41054#file41054line1512>
> >
> >     This appears to ignore any merge inhibition flags that a bridge may have. While this is acceptable for the target bridge since it was created by the attended transfer code, I'm not so sure that it will always be the case for the transferee bridge.

This is actually done on purpose.

Both bridges shift personalities from a normal basic bridge to an atxfer basic bridge. Atxfer basic bridges do not have permanent bridge-scoped merge or swap inhibition flags set. In addition, we purposely enable temporary merge inhibition on both bridges. This means that any attempts to call ast_bridge_move() or ast_bridge_merge() involving these bridges will fail. This is to prevent outside influences like AMI or ARI from attempting to mess with the bridges in the midst of an attended transfer. However, a side effect of enabling merge inhibition is that now we also can't merge bridges through the normal API calls. So what we have to do is purposely bypass the merge inhibition checks. This is the "mechanical" reason behind the merge method used.

Philosophically, we can get away with this sort of behavior because what we have done by changing personalities, setting temporary merge inhibition, and creating the monitor thread is effectively taken ownership of the bridges and locked them down from outside influences. From our perspective, these bridges our ours and we don't need to worry about someone else doing something to them.

Your point is valid before we've actually taken ownership, though. When the attended transfer DTMF sequence is initially entered, I can check the bridge to see if temporary merge inhibition is already enabled and bail out of the transfer attempt immediately if that's the case. Right now, a check like this will never trigger because attended transfer is the only operation that enables temporary merge inhibition. This would be a good future-proofing measure though.


- Mark


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


On July 2, 2013, 10:11 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2654/
> -----------------------------------------------------------
> 
> (Updated July 2, 2013, 10:11 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-21543
>     https://issues.asterisk.org/jira/browse/ASTERISK-21543
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This review contains the content necessary to get DTMF attended transfer feature complete.
> 
> In order to facilitate this, there are some background tasks that needed to be done first. First, when an attended transfer is initiated, it was clear that the bridge that the parties were in would need to behave differently from how it normally did. In order to allow for this to happen, the concept of bridge "personalities" was added. When a bridge is being used in an attended transfer, it has its personality changed to be that of an attended transfer basic bridge instead of a normal basic bridge. With this personality, the following changes are present:
> 
> * The bridge will never dissolve on its own. It must be destroyed by an outside influence.
> * The bridge recognizes when a channel with the "transferer" role enters. This channel is bestowed with DTMF hooks and a hangup hook that other channels do not get.
> * The normal DTMF hooks are not present for channels. This makes compounding transfers impossible.
> 
> In order to make use of an alternate personality for basic bridging, attended transfer functionality was moved from bridges/bridge_builtin_features.c to main/bridging_basic.c. While performing this move, it became clear that it made sense to move blind transfer functionality as well since attended and blind transfers share some common code.
> 
> Attended transfer operation has been completely overhauled from its old form. In its old form, the attended transfer DTMF hook would not return until a conclusive result of the transfer could be determined. With this set of changes, the attended transfer DTMF hook sets up an attended_transfer_properties structure that has all the relevant pieces of information for the attended transfer. After setting up the properties, the feature hook launches a monitoring thread and returns.
> 
> This monitor thread then runs a state machine that responds to stimuli from various hooks and callbacks. The state machine allows for orderly operation since stimuli may be coming from multiple other threads.
> 
> In addition to the normal feedback for reviews (i.e. memory leaks, potential deadlocks, etc.), let me know if you have alternate suggestions for names of things. I struggled to come up with cogent state names for the state machine, so if you have better suggestions for the names, please let me know.
> 
> 
> Diffs
> -----
> 
>   /trunk/main/features.c 393507 
>   /trunk/main/bridging_roles.c 393507 
>   /trunk/main/bridging_basic.c 393507 
>   /trunk/main/bridging.c 393507 
>   /trunk/include/asterisk/stasis_bridging.h 393507 
>   /trunk/include/asterisk/features_config.h 393507 
>   /trunk/include/asterisk/bridging_roles.h 393507 
>   /trunk/include/asterisk/bridging_private.h PRE-CREATION 
>   /trunk/include/asterisk/bridging_features.h 393507 
>   /trunk/include/asterisk/bridging.h 393507 
>   /trunk/bridges/bridge_builtin_features.c 393507 
>   /trunk/main/features_config.c 393507 
>   /trunk/main/stasis_bridging.c 393507 
> 
> Diff: https://reviewboard.asterisk.org/r/2654/diff/
> 
> 
> Testing
> -------
> 
> Using the state machine as a guide, I ran through every transition that can be reliably tested (for instance, I couldn't easily test transfer failures that rely on memory allocation failures). In all cases, I got the result I expected.
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

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