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

Mark Michelson reviewboard at asterisk.org
Thu May 9 08:36:36 CDT 2013



> On May 8, 2013, 9:55 p.m., Mark Michelson wrote:
> > There are a bunch of functions in core_local.h where it's not clear why they were made public. For instance, why are the channel technology callbacks public? Why is the unreal_pvt destructor public?
> > 
> > You need to standardize on "unreal" or "local" because right now it appears that which one is used in specific instances is arbitrary. For instance, I'd call ast_
> 
> rmudgett wrote:
>     There are two things here.  The unreal framework and local channels using the unreal framework.  The unreal framework is used to create channel types that are similar to local channels.  The unreal framework is the equivalent to an abstract base class.  chan_agent will use the unreal framework to create Agent;1--Agent;2 channels just like local channels thus the common channel technology callbacks need to be made public.

You know what's really weird? I completely changed what this comment said because after looking at the implementation of core_local.c some more, it completely clicked what you were doing. I'm completely blaming reviewboard for keeping the old version of my comment when I published my review.

But like I said, I *changed* the comment, I didn't remove it.

What I actually wanted to say was that "unreal" and "local" seem to be intermixed too much here, which can cause confusion for someone trying to figure out what it is they should be using. So what I suggest is that the unreal and local stuff should be split apart into separate files. This way, it becomes more obvious to readers of the code that the unreal is an abstract channel API and local is a user of that API.


- Mark


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


On May 8, 2013, 11:36 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2508/
> -----------------------------------------------------------
> 
> (Updated May 8, 2013, 11:36 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 388107 
>   /team/group/bridge_construction/apps/app_dial.c 388107 
>   /team/group/bridge_construction/apps/app_followme.c 388107 
>   /team/group/bridge_construction/apps/app_queue.c 388107 
>   /team/group/bridge_construction/bridges/bridge_builtin_features.c 388107 
>   /team/group/bridge_construction/channels/chan_agent.c 388107 
>   /team/group/bridge_construction/channels/chan_local.c 388107 
>   /team/group/bridge_construction/channels/chan_sip.c 388107 
>   /team/group/bridge_construction/include/asterisk/_private.h 388107 
>   /team/group/bridge_construction/include/asterisk/bridging.h 388107 
>   /team/group/bridge_construction/include/asterisk/ccss.h 388107 
>   /team/group/bridge_construction/include/asterisk/core_local.h PRE-CREATION 
>   /team/group/bridge_construction/main/asterisk.c 388107 
>   /team/group/bridge_construction/main/bridging.c 388107 
>   /team/group/bridge_construction/main/channel.c 388107 
>   /team/group/bridge_construction/main/core_local.c PRE-CREATION 
>   /team/group/bridge_construction/main/pbx.c 388107 
> 
> 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/20130509/1e06d6b8/attachment-0001.htm>


More information about the asterisk-dev mailing list