[Asterisk-code-review] app dial: remove pending CONNECTED LINE updates before initi... (asterisk[13])

[Richard Mudgett]

Richard Mudgett has posted comments on this change. ( https://gerrit.asterisk.org/9558 )

Change subject: app_dial: remove pending CONNECTED LINE updates before initialize calls
......................................................................


Patch Set 1:

> > I think extending the Dial, Queue, and FollowMe 'I' option to
 > block
 > > connected line updates in both directions would be a better
 > > approach.  The 'I' option currently blocks connected line updates
 > > from the called parties to the caller.  It is a simple matter to
 > > also have it block updates in the other direction for each of the
 > > applications.
 > >
 > > You are trying to lie to Charlie about who is calling at least
 > > until the transfer is complete.  You could use a connected line
 > > interception routine [1] set on Charlie's channel to keep the
 > party
 > > id as you want it without making any code changes.
 > >
 > > [1] https://wiki.asterisk.org/wiki/display/AST/Party+ID+Interception+Macros+and+Routines
 > 
 > With the same configuration, if Alice does blind transfer, Charlie
 > will see modified ID.
 > Do you think that it's normal that depending on the type of
 > transfer the asterisk behavior is different in this case? I think
 > it's a bug.
 > 
 > Could you please explain when/why the pending CONNECTED LINE update
 > can be used? I don't understand why it's a bad idea to delete this
 > pending update, which is not relevant.

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.

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.

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.


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

Gerrit-Project: asterisk
Gerrit-Branch: 13
Gerrit-MessageType: comment
Gerrit-Change-Id: I346652661949b6611c23e431ede0dbea1be3017a
Gerrit-Change-Number: 9558
Gerrit-PatchSet: 1
Gerrit-Owner: Alexei Gradinari <alex2grad at gmail.com>
Gerrit-Reviewer: Alexei Gradinari <alex2grad at gmail.com>
Gerrit-Reviewer: Jenkins2
Gerrit-Reviewer: Richard Mudgett <rmudgett at digium.com>
Gerrit-Comment-Date: Tue, 24 Jul 2018 23:58:05 +0000
Gerrit-HasComments: No
Gerrit-HasLabels: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20180724/9b0f0ac3/attachment.html>