[Home]

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-0600Date Closed:2011-06-07 14:10:27
Priority:MinorRegression?No
Status:Closed/CompleteComponents: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