[asterisk-commits] bridge: When performing a blonde transfer update connected l... (asterisk[master])

[SVN commits to the Asterisk project]

Matt Jordan has submitted this change and it was merged.

Change subject: bridge: When performing a blonde transfer update connected line information.
......................................................................


bridge: When performing a blonde transfer update connected line information.

When performing a blonde transfer the code uses the old masquerade
mechanism to move a channel around. As a result of this certain information,
such as connected line, is moved between the channels involved. Upon
completion of the move a frame is queued which is supposed to update the
connected line information on the channel. This does not occur as the
code considers it a redundant update since the masquerade operation
updated the channel (but did not inform it of the new connected line
information). The code also does not queue a connected line update
to be handled by the thread handling the channel. Without this any
other channel that may be loosely involved does not know it is
talking to a different caller.

This change does the following to resolve this:

1. The indicated connected line information is cleared upon
completion of the masquerade operation when doing a blonde transfer.
This prevents the connected line update from being considered
redundant.

2. A connected line update frame is now queued upon the completion
of the masquerade operation so any other channel loosely involved
knows that there is a different caller.

ASTERISK-25157 #close
Reported by: Joshua Colp

Change-Id: Ibb8798184a1dab3ecd35299faecc420034adbf20
---
M main/bridge_channel.c
1 file changed, 20 insertions(+), 0 deletions(-)

Approvals:
  Mark Michelson: Looks good to me, but someone else must approve
  Richard Mudgett: Looks good to me, but someone else must approve
  Matt Jordan: Looks good to me, approved; Verified



diff --git a/main/bridge_channel.c b/main/bridge_channel.c
index 9e30068..1597226 100644
--- a/main/bridge_channel.c
+++ b/main/bridge_channel.c
@@ -1761,6 +1761,17 @@
 		return;
 	}
 
+	/* The ast_channel_move function will end up updating the connected line information
+	 * on chan_target to the value we have here, but will not inform it. To ensure that
+	 * AST_FRAME_READ_ACTION_CONNECTED_LINE_MACRO is executed we wipe it away here. If
+	 * we don't do this then the change will be considered redundant, since the connected
+	 * line information is already there (despite the channel not being told).
+	 */
+	ast_channel_lock(chan_target);
+	ast_party_connected_line_free(ast_channel_connected_indicated(chan_target));
+	ast_party_connected_line_init(ast_channel_connected_indicated(chan_target));
+	ast_channel_unlock(chan_target);
+
 	if ((payload_size = ast_connected_line_build_data(connected_line_data,
 		sizeof(connected_line_data), &connected_target, NULL)) != -1) {
 		struct ast_control_read_action_payload *frame_payload;
@@ -1774,6 +1785,15 @@
 		ast_queue_control_data(chan_target, AST_CONTROL_READ_ACTION, frame_payload, frame_size);
 	}
 
+	/* A connected line update is queued so that if chan_target is remotely involved with
+	 * anything (such as dialing a channel) the other channel(s) will be informed of the
+	 * new channel they are involved with.
+	 */
+	ast_channel_lock(chan_target);
+	ast_connected_line_copy_from_caller(&connected_target, ast_channel_caller(chan_target));
+	ast_channel_queue_connected_line_update(chan_target, &connected_target, NULL);
+	ast_channel_unlock(chan_target);
+
 	ast_party_connected_line_free(&connected_target);
 }
 

-- 
To view, visit https://gerrit.asterisk.org/642
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: Ibb8798184a1dab3ecd35299faecc420034adbf20
Gerrit-PatchSet: 2
Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-Owner: Joshua Colp <jcolp at digium.com>
Gerrit-Reviewer: Mark Michelson <mmichelson at digium.com>
Gerrit-Reviewer: Matt Jordan <mjordan at digium.com>
Gerrit-Reviewer: Richard Mudgett <rmudgett at digium.com>