[asterisk-dev] [Code Review] 2508: Create unreal channel framework for derivative channels like local channels.

[rmudgett]

> On May 9, 2013, 9:41 p.m., Mark Michelson wrote:
> > /team/group/bridge_construction/include/asterisk/core_local.h, lines 50-52
> > <https://reviewboard.asterisk.org/r/2508/diff/3/?file=37563#file37563line50>
> >
> >     Do you think there would be value to putting a restriction in the function to ensure that you could only get the local channel peer if this function is called between ast_request() and ast_call()?
> >     
> >     Same thing for ast_local_setup_bridge() and ast_local_setup_masquerade()

The ast_local_get_peer() can be useful anytime during the life of a local channel pair.

The ast_local_setup_bridge() and ast_local_setup_masquerade() already do enforce that restriction.

I adjusted the doxygen comments accordingly.


- rmudgett


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


On May 9, 2013, 7:19 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2508/
> -----------------------------------------------------------
> 
> (Updated May 9, 2013, 7:19 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-21713
>     https://issues.asterisk.org/jira/browse/ASTERISK-21713
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Part of the bridging work being done needs the ability to manipulate local channels in new ways:
> 1) When one-touch parking a multi-party bridge, a local channel needs to be created between the bridge being parked and the park holding bridge.  In this case, the local;2 channel needs to be pushed into the parking bridge since there isn't a dialplan location to execute.
> 2) When attended transferring a multi-party bridge to an application like voicemail using channel driver protocol transfers.  A local channel needs to be created between the transferred bridge and the application.  In this case, the local;2 channel needs to masquerade into the channel running voicemail.
> 3) The ConfBridge announcer channels need to replace the chan_bridge channels with an unreal channel framework channel for implementation reasons. (The chan_bridge driver will be deleted as a result.)
> 4) The chan_agent channel driver will use the unreal channel framework to create Agent channels.
> 
> This patch refactors chan_local.c into core_local.c, extracts an unreal channel driver framework to create derivative channel types similar to local channels, and moves it into the system core.
> 
> The new API calls for custom local channel manipulation are:
> ast_local_get_peer() - Get the other local channel in the pair.  Useful for getting the local;2 channel after an ast_request().
> ast_local_setup_bridge() - After performing an ast_request(), using this call will make the subsequent ast_call() push the local;2 channel into the specified bridge.
> ast_local_setup_masquerade() - After performing an ast_request(), using this call will make the subsequent ast_call() masquerade the local;2 channel into the specified channel.
> 
> Changes/fixes in local/unreal channel behavior:
> * Made unreal COLP indicate handling always set the caller information on the other unreal channel in the pair.  Previously this happened only in the local;2 to local;1 direction.
> 
> * Fixed using the wrong callerid when checking if the exten exists in local_call().
> 
> * Renamed LOCAL_MOH_PASSTHRU to AST_UNREAL_MOH_INTERCEPT and invert the use of the flag to match the new name.  This makes the unreal channels default to not keeping state information in case they optimize.  Local channels still behave the same for the /m option.  I would love to make local channels not default to handling the HOLD/UNHOLD frames because this represents state that will disappear when the local channels optimize out.  Unfortunately, there is likely too much inertia expecting this behavior.
> 
> 
> Diffs
> -----
> 
>   /team/group/bridge_construction/CHANGES 388214 
>   /team/group/bridge_construction/apps/app_dial.c 388214 
>   /team/group/bridge_construction/apps/app_followme.c 388214 
>   /team/group/bridge_construction/apps/app_queue.c 388214 
>   /team/group/bridge_construction/bridges/bridge_builtin_features.c 388214 
>   /team/group/bridge_construction/channels/chan_agent.c 388214 
>   /team/group/bridge_construction/channels/chan_local.c 388214 
>   /team/group/bridge_construction/channels/chan_sip.c 388214 
>   /team/group/bridge_construction/include/asterisk/_private.h 388214 
>   /team/group/bridge_construction/include/asterisk/bridging.h 388214 
>   /team/group/bridge_construction/include/asterisk/ccss.h 388214 
>   /team/group/bridge_construction/include/asterisk/core_local.h PRE-CREATION 
>   /team/group/bridge_construction/include/asterisk/core_unreal.h PRE-CREATION 
>   /team/group/bridge_construction/main/asterisk.c 388214 
>   /team/group/bridge_construction/main/bridging.c 388214 
>   /team/group/bridge_construction/main/channel.c 388214 
>   /team/group/bridge_construction/main/core_local.c PRE-CREATION 
>   /team/group/bridge_construction/main/core_unreal.c PRE-CREATION 
>   /team/group/bridge_construction/main/pbx.c 388214 
> 
> Diff: https://reviewboard.asterisk.org/r/2508/diff/
> 
> 
> Testing
> -------
> 
> Local channels still optimize out.
> The /n option prevents optimization.
> The /m option still works.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130510/58310e2f/attachment.htm>