Summary: | ASTERISK-05825: ManagerAPI Event - CallerID is set wrong on call (dial) | ||
Reporter: | Gerhard Venter (gventer) | Labels: | |
Date Opened: | 2005-12-12 16:52:36.000-0600 | Date Closed: | 2011-06-07 14:10:27 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Core/ManagerInterface |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | The CallerId is set with the extension being called in app_dial.c thus ending up with the wrong CallerID and lost CallerIDName in the events that follows the Dial event. The Dial event seems to be new and has the correct CallerID, in my case and actual event listed below it is <UNKOWN>, but all events that follows has the wrong CallerID. In the method ast_channel *wait_for_answer in the app_dial.c file you have the following code: } else { senddialevent(in, o->chan); /* After calling, set callerid to extension */ if (!ast_test_flag(peerflags, OPT_ORIGINAL_CLID)) ast_set_callerid(o->chan, ast_strlen_zero(in->macroexten) ? in->exten : in->macroexten, get_cid_name(cidname, sizeof(cidname), in), NULL); } We see the senddialevent() call here and then for some reason even in the comments it says "after calling set callerid to extension" which I dont understand why. Here is the ouput from my Events: Event: Newchannel Privilege: call,all Channel: SIP/3624-14a3 State: Down CallerID: <unknown> <=======Correct CallerIDName: <unknown> Uniqueid: 1134090513.2 12/8/2005 5:08:32 PM Event: Dial Privilege: call,all Source: Zap/1-1 Destination: SIP/3624-14a3 CallerID: <unknown> <===== Correct and Dialplan changed CallerIDName CallerIDName: inbound-PRIVATE SrcUniqueID: 1134090511.1 DestUniqueID: 1134090513.2 12/8/2005 5:08:32 PM Event: Newcallerid Privilege: call,all Channel: SIP/3624-14a3 CallerID: 3624 <=====WRONG! CallerIDName: <Unknown> Uniqueid: 1134090513.2 CID-CallingPres: 0 (Presentation Allowed, Not Screened) 12/8/2005 5:08:32 PM Event: Newchannel Privilege: call,all Channel: SIP/3624-14a3 State: Ringing CallerID: 3624 <=====WRONG! See it is ringing and lost the CallerIDName too CallerIDName: <unknown> Uniqueid: 1134090513.2 12/8/2005 5:08:32 PM Event: ExtensionStatus Privilege: call,all Exten: 3624 Context: monitor Status: 8 Channels = 2 12/8/2005 5:08:42 PM Event: Newstate Privilege: call,all Channel: SIP/3624-14a3 State: Up CallerID: 3624 CallerIDName: <unknown> Uniqueid: 1134090513.2 Channels = 2 12/8/2005 5:08:42 PM Event: Link Privilege: call,all Channel1: Zap/1-1 Channel2: SIP/3624-14a3 Uniqueid1: 1134090511.1 Uniqueid2: 1134090513.2 CallerID1: (null) CallerID2: 3624 <====Here it seems to be correct. If I am missing something let me know. | ||
Comments: | By: Gerhard Venter (gventer) 2005-12-14 08:59:53.000-0600 Hi Kenny: Can you help me out here I dont know the SVC procedures but once we report the bugs do we also have to supply the patch as well? I am not a C programmer although I can read and follow it. The status of the 2 bugs that I reported is still new, it will be nice if there was something like "read" or "bug noted". Right now I can't tell from either bugs that I reported what is going on. Also I cannot change the severity as this is becoming more major since any Manager API client is broken out there. How do you edit an issue reported? See issues 5980 and 5981. Thanks Gerhard By: Russell Bryant (russell) 2005-12-14 09:44:14.000-0600 This was an intentional change. It is noted in UPGRADE.txt: Dialing: * The Caller*ID of the outbound leg is now the extension that was called, rather than the Caller*ID of the inbound leg of the call. The "o" flag for Dial can be used to restore the original behavior if desired. Note that if you are looking for the originating callerid from the manager event, there is a new manager event "Dial" which provides the source and destination channels and callerid. There is a lot of discussion about this in the mailing list archives. Here is a link to one such thread: http://lists.digium.com/pipermail/asterisk-dev/2005-July/013956.html |