Summary:ASTERISK-20129: Incorrect <CallerID> from 'core show channels verbose' when using Queue()
Reporter:Stanimir Serbezov (stanimir_ss)Labels:
Date Opened:2012-07-16 04:23:49Date Closed:2012-07-18 18:05:10
Versions: Frequency of
Environment:CentOS 5.4 32bitAttachments:
Description:When using Queue() 'core show channels verbose' shows not the caller's <CallerID> but the <CallerID> of the sip user itself.
For example:
External client with number 0887654321 calls sip trunk BTK_1-1 which routes the call to Queue() in which members are sip users 11,21,31,41,12,22,32 and 42.
Currently only sip user 31 is registered, so the queue calls it.

Before answer 'core show channels verbose' shows:
Channel              Context              Extension        Prio State   Application  Data                      CallerID        Duration Accountcode PeerAccount BridgedTo          
SIP/BTK_1-1-0000001b execute-routing-apps cmd_Queue           8 Ring    Queue        dispatchers,rXx           0887654321      00:00:01                         (None)              
SIP/31-0000001c      from-internal        cmd_Queue           1 Ringing AppQueue     (Outgoing Line)           31              00:00:01                         (None)              
2 active channels
1 active call

After 31 answers 'core show channels verbose' shows:

Channel              Context              Extension        Prio State   Application  Data                      CallerID        Duration Accountcode PeerAccount BridgedTo          
SIP/BTK_1-1-0000001b execute-routing-apps cmd_Queue           8 Up      Queue        dispatchers,rXx           0887654321      00:00:11                         SIP/31-0000001c
SIP/31-0000001c      from-internal        cmd_Queue           1 Up      AppQueue     (Outgoing Line)           31              00:00:10                         SIP/BTK_1-1-0000001b
2 active channels
1 active call

In extensions.conf I'm calling Queue() with options: rXx

The problem is that you can't see who is calling 31 before it answers the call.
In Asterisk 1.6 for the <CallerID> in 31's row there was the actual client number. Now it shows 31.
Comments:By: Rusty Newton (rnewton) 2012-07-17 18:07:28.928-0500

The CallerID for channel SIP/BTK_1-1-0000001b shows as "0887654321" which seems appropriate per your description.

In the CallerID column, the CallerID for each channel should be displayed.

The CallerID will be associated with that channel itself, and not any channel that is calling or ringing that channel...

Therefore the CallerID of "31" for SIP/31-0000001c is appropriate unless you are attempting to set it to something else.

If this behavior was different in a previous Asterisk version, it was most likely a bug and is now fixed.

Am I understanding the issue correctly?

By: Stanimir Serbezov (stanimir_ss) 2012-07-18 01:49:13.096-0500

In Asterisk 1.6 for channel SIP/31-0000001c CallerID would be 0887654321 too. If Caller ID really should show caller's number(id), then I think the above mentioned value is more appropriate as this is the person who is calling 31.

If you say everything is the way it should be, then how else you would be able to know who is calling who when there is more than one call and they are still not bridged?

By: Rusty Newton (rnewton) 2012-07-18 18:05:01.342-0500

I've confirmed with various core developers that this current behavior is expected, and the behavior you have described was erroneous behavior that is now corrected.

The CallerID column you are looking at is intended to contain the CallerID of the channel listed in that row.

From a quick test I ran in 1.8.X with IAX2 channels - If you run "core show channel <channel>" where <channel> is a channel in the state of being rung, you should have fields "Connected Line ID:" and "Connected Line ID Name:" that will be populated by the CallerID of the calling channel.

There may be other ways to get the information you desire (through AMI and what not) that would be a support request, please search the mailing list, forums and so on, then post on them if you cannot find the answer there.