[asterisk-commits] mmichelson: branch mmichelson/digit_manipulation r196343 - /team/mmichelson/d...

[SVN commits to the Asterisk project]

Author: mmichelson
Date: Fri May 22 13:32:58 2009
New Revision: 196343

URL: http://svn.asterisk.org/svn-view/asterisk?view=rev&rev=196343
Log:
Commit a comment in transfer code that I am using as a guideline for getting things working properly.


Modified:
    team/mmichelson/digit_manipulation/main/features.c

Modified: team/mmichelson/digit_manipulation/main/features.c
URL: http://svn.asterisk.org/svn-view/asterisk/team/mmichelson/digit_manipulation/main/features.c?view=diff&rev=196343&r1=196342&r2=196343
==============================================================================
--- team/mmichelson/digit_manipulation/main/features.c (original)
+++ team/mmichelson/digit_manipulation/main/features.c Fri May 22 13:32:58 2009
@@ -1635,6 +1635,32 @@
 		/* Due to a limitation regarding when callerID is set on a Local channel,
 		 * we use the transferer's connected line information here.
 		 */
+
+		/* xferchan is transferee, and newchan is the transfer target
+		 * So...in a transfer, who is the caller and who is the callee?
+		 *
+		 * When the call is originally made, it is clear who is caller and callee.
+		 * When a transfer occurs, it is my humble opinion that the transferee becomes
+		 * the caller, and the transfer target is the callee.
+		 *
+		 * The problem is that these macros were set with the intention of the original
+		 * caller and callee taking those roles. A transfer can totally mess things up,
+		 * to be technical. What sucks even more is that you can't effectively change
+		 * the macros in the dialplan during the call from the transferer to the transfer
+		 * target because the transferee is stuck with whatever role he originally had.
+		 *
+		 * I think the answer here is just to make sure that it is well documented that
+		 * during a transfer, the transferee is the "caller" and the transfer target
+		 * is the "callee."
+		 *
+		 * This means that if party A calls party B, and party A transfers party B to
+		 * party C, then B has switched roles for the call. Now party B will have the
+		 * caller macro called on his channel instead of the callee macro.
+		 *
+		 * Luckily, the method by which the bridge is launched here ensures that the 
+		 * transferee is the "chan" on the bridge and the transfer target is the "peer,"
+		 * so my idea for the roles post-transfer does not require extensive code changes.
+		 */
 		connected_line.source = AST_CONNECTED_LINE_UPDATE_SOURCE_TRANSFER;
 		ast_channel_update_connected_line(xferchan, &connected_line);
 		ast_channel_lock(xferchan);