<blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">I think extending the Dial, Queue, and FollowMe 'I' option to<br>block<br>connected line updates in both directions would be a better<br>approach.  The 'I' option currently blocks connected line updates<br>from the called parties to the caller.  It is a simple matter to<br>also have it block updates in the other direction for each of the<br>applications.<br>> You are trying to lie to Charlie about who is calling at least<br>until the transfer is complete.  You could use a connected line<br>interception routine [1] set on Charlie's channel to keep the<br>party<br>id as you want it without making any code changes.<br>> [1] https://wiki.asterisk.org/wiki/display/AST/Party+ID+Interception+Macros+and+Routines</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">With the same configuration, if Alice does blind transfer, Charlie<br>will see modified ID.<br>Do you think that it's normal that depending on the type of<br>transfer the asterisk behavior is different in this case? I think<br>it's a bug.</p><p style="white-space: pre-wrap; word-wrap: break-word;">Could you please explain when/why the pending CONNECTED LINE update<br>can be used? I don't understand why it's a bad idea to delete this<br>pending update, which is not relevant.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">In the general case, you don't know why a connected line update is pending which is why the initial approach is a sledge hammer.  That connected line update could be coming from the Alice endpoint if it were another PBX or ITSP.  In this particular case the connected line update is coming from the attended transfer code when it moves channels around.  That would be where you should look into suppressing the creation of the initial connected line update.</p><p style="white-space: pre-wrap; word-wrap: break-word;">One place that can generate the initial update is when the local;1 channel enters the bridge with Alice after Alice dials the transfer number.  You should be able to suppress the connected line update there by adding the AST_BRIDGE_IMPART_INHIBIT_JOIN_COLP flag to the ast_bridge_impart() in bridge_basic.c:feature_attended_transfer().  The other place that likely needs to suppress the initial update is when Alice first enters the transfer_target bridge with local;1.  You need to be aware that Alice can bounce back and forth between the target_bridge and the transferee_bridge using the default *4 DTMF sequence (atxferswap).  Connected line updates happen when Alice moves between bridges.</p><p style="white-space: pre-wrap; word-wrap: break-word;">This whole thing depends upon why you are altering the party id sent to Charlie.  If it is just a systematic mapping of party ids then you need to use the interception routines.  If it is a temporary lie to Charlie then the initial suppression is fine.</p><p><a href="https://gerrit.asterisk.org/9558">View Change</a></p><ul style="list-style: none; padding: 0;"></ul><p>To view, visit <a href="https://gerrit.asterisk.org/9558">change 9558</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/9558"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: asterisk </div>
<div style="display:none"> Gerrit-Branch: 13 </div>
<div style="display:none"> Gerrit-MessageType: comment </div>
<div style="display:none"> Gerrit-Change-Id: I346652661949b6611c23e431ede0dbea1be3017a </div>
<div style="display:none"> Gerrit-Change-Number: 9558 </div>
<div style="display:none"> Gerrit-PatchSet: 1 </div>
<div style="display:none"> Gerrit-Owner: Alexei Gradinari <alex2grad@gmail.com> </div>
<div style="display:none"> Gerrit-Reviewer: Alexei Gradinari <alex2grad@gmail.com> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins2 </div>
<div style="display:none"> Gerrit-Reviewer: Richard Mudgett <rmudgett@digium.com> </div>
<div style="display:none"> Gerrit-Comment-Date: Tue, 24 Jul 2018 23:58:05 +0000 </div>
<div style="display:none"> Gerrit-HasComments: No </div>
<div style="display:none"> Gerrit-HasLabels: No </div>