Summary:	ASTERISK-23841: DTMF atxfer doesn't set CallerID for the recall calls to the transferrer.
Reporter:	Richard Mudgett (rmudgett)	Labels:
Date Opened:	2014-06-09 16:23:34	Date Closed:	2014-12-22 15:24:49.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Features
Versions:	12.3.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:
Description:	A calls B, B does a DTMF blonde atxfer to C. If neither B nor C answers then the recall calls to B have issues with Caller ID.  If B is a PJSIP endpoint, the Caller ID displays as a UUID. The basic bridge sub-class needs to save the following information before the initial attempt to call party C: the accountcode of party B, the party A (COLP) identification, and party B (CLID) identification information for the possible recall calls. For B recall: After calling {{ast_dial_prerun()}}, use {{ast_dial_get_channel()}} to get the created channel and set COLP (party A), CLID (party B), and accountcode on it.  Setting the CLID is needed to ensure that if party B is reconnected to party A again party A will get the original party B identification instead of possibly nothing.  Should also copy the channel variables from the original B channel.  Then call {{ast_dial_run()}}. For C recall: After calling {{ast_request()}}, set COLP (party A) and possibly accountcode on the new channel before calling {{ast_call()}}.  Setting the COLP before {{ast_call()}} is needed to ensure that the party A identification is available before the Local;2 channel actually dials party C.  Some phones do not update the display if the party identification information changes once the call is started.
Comments: