Summary:	ASTERISK-13265: Wrong CallerID on attended transfer
Reporter:	Andrey Solovyev (corruptor)	Labels:
Date Opened:	2008-12-23 08:51:11.000-0600	Date Closed:	2011-06-07 14:08:15
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_features
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	This was introduces after 1.4.21.2. During attended transfer callerid is set to extension name which have dialed transferer. ****** ADDITIONAL INFORMATION ****** You can reproduce using this dialplan. [internal] exten => 999111,1,Noop(Inbound CallerID - ${CALLERID(num)}) exten => 999111,n,Dial(SIP/204,100,t) exten => _X.,1,Noop(CallerID - ${CALLERID(num)}) exten => _X.,n,Dial(SIP/${EXTEN},100,t) SIP/205 dials 999111. SIP/204 answers. SIP/204 does attended transfer to 203. Console output. -- Executing [999111@internal:1] NoOp("SIP/205-09b114c8", "Inbound CallerID - 205") in new stack    -- Executing [999111@internal:2] Dial("SIP/205-09b114c8", "SIP/204|100|t") in new stack    -- Called 204    -- SIP/204-09ab1718 is ringing    -- SIP/204-09ab1718 answered SIP/205-09b114c8    -- Started music on hold, class 'default', on SIP/205-09b114c8    -- <SIP/204-09ab1718> Playing 'pbx-transfer' (language 'ru')    -- Executing [203@internal:1] NoOp("Local/203@internal-34a6,2", "CallerID - 999111") in new stack    -- Executing [203@internal:2] Dial("Local/203@internal-34a6,2", "SIP/203|100|t") in new stack    -- Called 203    -- SIP/203-09aad2d8 is ringing    -- Local/203@internal-34a6,1 is ringing    -- SIP/203-09aad2d8 answered Local/203@internal-34a6,2 -------------------------- You can see that callerid is 999111 for some reason.
Comments:	By: Mark Michelson (mmichelson) 2008-12-23 10:28:21.000-0600 There is an important piece of information missing here: What is it that you expect the CallerID to be set to? Also you mentioned that the bug was introduced after 1.4.21.2, but when I tried your sample dialplan myself, 1.4.21.2 and the current tip of the 1.4 branch both produced the same results. By: Andrey Solovyev (corruptor) 2008-12-24 06:06:52.000-0600 Sorry. Earlier versions of 1.4 have the same behaviour. Hmmm. It seems that this is the way it should be and I haven't noticed this earlier. I expect it to be set to callerid of the transferer's (callerid of SIP/204 in my scenario) because he is actually makes call. The other option is to set to the callerid of the transferee (CallerID of SIP/205) (blind transfer works this way). By: Andrey Solovyev (corruptor) 2008-12-25 03:08:41.000-0600 I've found similar bug http://bugs.digium.com/view.php?id=11947 . Russel has said that "seeing the callerid of the original called party is correct in this case" but we see the extension of the called party not the callerid. Device can be dialed using many extensions. It can be a member of many ring groups, for example, so every time it transfers we'll see different callerid. I think this is not good. By: Andrey Solovyev (corruptor) 2009-02-17 03:15:19.000-0600 Any thoughts on this? By: David Woolley (davidw) 2009-02-17 05:51:36.000-0600 Firstly, this is specific to using the Asterisk, rather than the SIP, attended transfer mechanism. I imagine it works this way because the calls are setup in such a direction that SIP/205 will never send its caller ID to Asterisk, and, in the general case, there may be no way to match up a sip.conf specified caller ID with the call to the phone taking the role of SIP/205 (e.g. it might actually be specified as SIP/192.168.0.1 or SIP/xyzzy. (For real SIP transfers, Asterisk will not know that the call from 205 to 203 is part of a transfer, until it has already sent the caller ID to 203, although, as it will see an incoming call from 205, it will derive caller ID in the normal way for incoming calls.  The SIP session from Asterisk to 203 is not replaced when the transfer completes, so the caller ID will not change.) By: Andrey Solovyev (corruptor) 2009-02-17 09:58:26.000-0600 Thanks, davidw. I think I've got that. I see that asterisk don't know the callerid of SIP/204 because this is the outbound call in my scenario. My problem can be solved using dialplan and variable inheritance if I defenetely know the callerid of the called peer. In my scenario I know that CallerId number of SIP/204 is 204 so I can insert "Set(__CalledCallerId=204)" before Dial and then use it in new channel. Anyway I think the way it works makes callerid almost useless. Maybe it should be set to transferee's callerid as it's done with blind transfer? By: Joshua C. Colp (jcolp) 2009-04-28 10:52:55 This can be made to work exactly as you want using the 'o' option to Dial. It will cause the callerid to be what is configured in sip.conf for the outgoing channel.