<blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">Patch Set 1:</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">Patch Set 1:</p><p style="white-space: pre-wrap; word-wrap: break-word;">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).</p><p style="white-space: pre-wrap; word-wrap: break-word;">What are the thoughts from others?</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">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?</p><p><a href="https://gerrit.asterisk.org/c/asterisk/+/15908">View Change</a></p><ul style="list-style: none; padding: 0;"></ul><p>To view, visit <a href="https://gerrit.asterisk.org/c/asterisk/+/15908">change 15908</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.asterisk.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.asterisk.org/c/asterisk/+/15908"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: asterisk </div>
<div style="display:none"> Gerrit-Branch: 16 </div>
<div style="display:none"> Gerrit-Change-Id: I7492645ae4307553d0f586d78e13a4f586231fdf </div>
<div style="display:none"> Gerrit-Change-Number: 15908 </div>
<div style="display:none"> Gerrit-PatchSet: 5 </div>
<div style="display:none"> Gerrit-Owner: N A <mail@interlinked.x10host.com> </div>
<div style="display:none"> Gerrit-Reviewer: Friendly Automation </div>
<div style="display:none"> Gerrit-Reviewer: Richard Mudgett <rmudgett@digium.com> </div>
<div style="display:none"> Gerrit-CC: George Joseph <gjoseph@digium.com> </div>
<div style="display:none"> Gerrit-CC: Joshua Colp <jcolp@sangoma.com> </div>
<div style="display:none"> Gerrit-Comment-Date: Wed, 19 May 2021 12:35:51 +0000 </div>
<div style="display:none"> Gerrit-HasComments: No </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Gerrit-MessageType: comment </div>