Summary:	ASTERISK-10657: Set CHANNELFORWARD variable to allow more control over setting CALLERID(num) on calls forwarded by 302 "Moved Temporarily"
Reporter:	Andrew Smith (eurodrew555)	Labels:
Date Opened:	2007-10-31 12:16:12	Date Closed:	2011-06-07 14:03:08
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_dial
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app_dial.patch
Description:	Example scenario Default callerid on ISDN30s (set by carrier) is 0208 123 4567. This is also our helpdesk number. User SIP/david has an extension of 4488 with an outgoing callerid number of 0208 123 4488. A user calls in from mobile 0777 123 4567 to 0208 123 4488. David's dial plan routes his call to his UA at SIP/david The SIP/david UA is a Linksys SPA-942, with call forwarding set to call forward to his mobile on 0777 400 9292. Asterisk CLI shows up as: -- Called user    -- Got SIP response 302 "Moved Temporarily" back from 10.0.0.2    -- Now forwarding Zap/116-1 to 'Local/07774009292@internal' (thanks to SIP/david-01505f80) What we would like to do: We would like to be able to set CALLERID(num)=02081239999 so that our user can see the call has been forwarded from his extension (as he recognises his own callerid number) Why we can't do it: Once the call is forwarded by Asterisk we are unable to find the original user that forwarded the call (SIP/david), so we are unable to correctly set the CALLERID(num). We can't use the incoming caller's callerid of 07771234567 as our carrier only allows us to set callerid of our own DIDs. If we cannot set the callerid correctly, then the default callerid of the ISDN30 is used (by default by the carrier) and then our user (David) then incorrectly believes he is receiving a call from our helpdesk, when in fact the call is being forwarded from his extension. If the CHANNELFORWARD variable (which in this case would be SIP/david-01505f80) is set, then we are able to do a simply MySQL lookup to retrieve his callerid number from his username, and then correctly set the callerid of the forwarding call to the extension that is forwarding the call. Our user (David) then sees that he is receiving a call from his own extension, and therefore knows that it is a forwarded call.
Comments:	By: Jason Parker (jparker) 2007-10-31 12:31:05 Please only upload patches as attachments. By: Leif Madsen (lmadsen) 2007-10-31 13:03:55 This seems unnecessary to me. You could just set this variable in the dialplan on the incoming leg and make it inherited to the Local channel, and then parse it there. I'd maybe do something like the following... [incoming] exten => _X.,1,NoOp() exten => _X.,n,Set(__CHANNELFORWARD=${CHANNEL}) ....etc.... [internal] exten => _X.,1,NoOp() ; Set the appropriate CID for the call exten => _X.,n,Exec(${IF($[${EXISTS(${CHANNELFORWARD})}]?GoSub(set_forward_cid,s,1):GoSub(set_std_cid,s,1))}) ; Continue on with the call as per normal [set_forward_cid] ; Inside here do your DB lookups and then set the CALLERID(num) exten => s,n,Return() [set_std_cid] ; Inside here set the normal CID for this call exten => s,n,Return() Either way, I don't think this functionality is needed -- seems you can do it in dialplan logic with an inherited variable. By: Leif Madsen (lmadsen) 2007-10-31 13:08:55 Since you can do this in the dialplan with inherited variables, then this patch is not necessary. Please find me as 'blitzrage' on IRC in #asterisk-bugs on the irc.freenode.net network if you would like to discuss this further.