[Asterisk-code-review] func_channel: Added new OTHER_CHANNEL function (asterisk[16])

[George Joseph]

George Joseph has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/15908 )

Change subject: func_channel: Added new OTHER_CHANNEL function
......................................................................


Patch Set 5:

> Patch Set 5:
> 
> > Patch Set 5:
> > 
> > > Patch Set 1:
> > > 
> > > > Patch Set 1:
> > > > 
> > > > I need to give this thought as to whether this is something that is reasonable or not. It feels very very very dangerous to go down this kind of road and allow arbitrary access to other channels like this, including to their dialplan functions (I'm wondering if it's possible to cause a deadlock using this).
> > > > 
> > > > What are the thoughts from others?
> > > 
> > > Just to explain my thought process, my rationale was to explicitly allow for access to their dialplan functions. I have a scenario in my dialplan currently, where I would like to set a custom CDR variable on another channel (which can be perfectly legitimate). MASTER_CHANNEL doesn't help because I use Dial with the n option to prevent optimization, so the new channel is the master channel. I wrote this so I could do just that, and write into another channel's CDR variable. I'm aware that issues from irresponsible usage could arise if the dialplan writer doesn't have good discretion but currently there does not seem to be any other way to perform these operations.
> > 
> > At the point you need to call this, is the other channel in a bridge with this one?  If so, could we limit updates to only channels that are bridged together?   Is there anything else we can use to limit the set of potential "other" channels?
> 
> In my specific use case here, I guess technically yes, I want to update a parent channel's CDR variable from a channel variable, but the Dial /n optimization prevention prevents going up the channel hierarchy. (More generally, something like this would be needed to update CDR variables after that channel's Dial() has already started.) So, such a limitation would be compatible with my primary use case and makes sense to me. I can't think off the top of my head now of any scenarios where I might want to update a CDR variable on a non-bridged channel. I use SHARED variables when possible for other cases.

OK so what you could do is rename the function to PEER_CHANNEL and use ast_channel_bridge_peer() to get the peer channel and set variables on it.  This way it works just like MASTER_CHANNEL where you don't even have to specify the other channel as an argument.


-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/15908
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: 16
Gerrit-Change-Id: I7492645ae4307553d0f586d78e13a4f586231fdf
Gerrit-Change-Number: 15908
Gerrit-PatchSet: 5
Gerrit-Owner: N A <mail at interlinked.x10host.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: Richard Mudgett <rmudgett at digium.com>
Gerrit-CC: George Joseph <gjoseph at digium.com>
Gerrit-CC: Joshua Colp <jcolp at sangoma.com>
Gerrit-Comment-Date: Wed, 19 May 2021 15:24:59 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20210519/30a0a6af/attachment-0001.html>