[Home]

Summary:ASTERISK-03419: Missing Caller ID when using manager API the caller ID is missing
Reporter:Fernando Romo (el_pop)Labels:
Date Opened:2005-02-02 12:41:08.000-0600Date Closed:2008-01-15 15:24:39.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_dial
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_dial_patch.txt
( 1) call_debug_2.txt
( 2) call_debug.txt
Description:When i generate a call using the Manager API, the caller ID is missing in the events "Packets". The Phones receive well the CallerID but the manager Aplication not.

This is something like the bug 3471 (http://bugs.digium.com/bug_view_page.php?bug_id=0003471) but the caller id works in the call initiation but is missing when connect to terminal extension, The phones receive ok the CallerID but the Event Packet not.

****** ADDITIONAL INFORMATION ******

This is the command send to manager:

Action: Originate
Channel: ZAP/32/85909000
Context: default
Exten: 3000
Priority: 1
Callerid: 85909000
CalleridName: 85909000

i attach the file "call_debug.txt" with all the follow-up of the call. You can see clearly how the CallerID is erase in the extension event.

I try to work around using the Dial Plan, but until now i need the correct event indication.
Comments:By: Mark Spencer (markster) 2005-02-02 13:42:59.000-0600

Callerid is not a parameter that is sent for the Newexten, but you do see the callerid set in the "NewState" and "NewCallerid" events, so you don't need it anyway.
By: Fernando Romo (el_pop) 2005-02-02 14:57:26.000-0600

Only a comment: Is necesary take care of the extension info in the same Packet in my debug the "Newexten" and "NewcallerID" send the extension not the Phone number.


Event: Newexten
Channel: Zap/32-1
Context: default
Extension: 3000
Priority: 1
Application: Dial
AppData: Sip/3000|25|rt
Uniqueid: 1107368824.6


Event: Newcallerid
Channel: SIP/3000-ea20
CallerID: 3000
CallerIDName: <Unknown>
Uniqueid: 1107368826.7

in the CVS HEAD still this issue.
By: Fernando Romo (el_pop) 2005-02-02 15:03:59.000-0600

The patch send by  mflorell in the bug 3490 (http://bugs.digium.com/bug_view_page.php?bug_id=0003490) resolve the issue, but i try to implement.

I notice event "Newstate" miss the callerid to:

Event: Newstate
Channel: SIP/3000-ea20
State: Up
CallerID: 3000
CallerIDName: <unknown>
Uniqueid: 1107368826.7
By: Fernando Romo (el_pop) 2005-02-02 15:31:05.000-0600

Ok, i apply the patch of bug 3490, recompile and install and i send the second bug trace of a simple call in file "call_debug_2.txt", please compare the two debugs and you see the problem in the "Newexten", "NewcallerID" and "Newstate" events.

edited on: 02-02-05 15:34
By: Mark Spencer (markster) 2005-02-02 23:58:04.000-0600

What is the *problem*, I don't see any problem!
By: Fernando Romo (el_pop) 2005-02-03 10:08:18.000-0600

Ok, let me show in the CVS Head the "Newstate" send:

Event: Newstate
Channel: SIP/3000-ea20
State: Up
CallerID: 3000
CallerIDName: <unknown>
Uniqueid: 1107368826.7

in the patch version sends:

Event: Newstate

Channel: SIP/3000-831f
State: Up
CallerID: 85909000
CallerIDName: <unknown>
Uniqueid: 1107446445.49

Programs like Flash Operator Panel stop to receive the CallerID, a little system for a tiny ACD i wrote depend of this response. and many of the events reported miss the caller ID.

The problem is the "<unknown>" is send in place of "Caller ID", in past version of * (before 1.0.5) this work without problems. in the recen CVS Head stop to report the caller ID.

I have a liitle perl script to make a call an debug using manager. i trace a couple of calls and the caller id is missing. Thats is the problem.

And i forget, the "NewCallerid"  event send "<unknown>". I try again with last cvs head and send my comments.

edited on: 02-03-05 10:09

edited on: 02-03-05 10:30

edited on: 02-03-05 10:41
By: nicolasg (nicolasg) 2005-02-03 12:15:36.000-0600

Hi Mark:

There *is* a problem. I pointed it out on bug 3490.

Its a simple problem: you cannot grab the callerid of the caller from the manager and associate it to the ringing phone. There are no manager events that shows the remote callerid associated in some way to the ringing phone. We only have the Link event, so we cannot know the callerid of the remote party before that event (that is, when you pick up the phone).

Picture this: you receive a call on your Cisco phone, you look at the display and you see YOUR NUMBER instead of the number of the caller. So, you have a call FROM YOURSELF! (Well, it does not happen on your phone, but it happens on manager based applications)

The Link event is useless, we need to associate the callerid BEFORE we pickup the phone, while the phone is ringing. I don't care whats the callerid value on the channel structure. The only thing we need is to associate the two channels IN THE MANAGER in order to extract the remote callerid, BEFORE the call is bridged.

Show me the way to achieve this and I will agree with you that there is no problem at all. NOTE: I'm only testing this on stable 1.0.5, I don't know about HEAD.

I sent a patch on 3490 that adds such an event. But I'm not sure if its implemented correctly.. maybe not. It sends an event with the callerid of the remote party with the uniqueid and name of the ringing channel.
By: Mark Spencer (markster) 2005-02-03 13:17:33.000-0600

Well I see two ways to create this link.  One would be for ast_call to send a manager event like "Call" with the callerid (in this case, the one being transmitted to the end device), or the other would be to have some sort of event produced out of app_dial which says "This outbound channel is associated with this inbound channel".  Which of those sounds better?
By: nicolasg (nicolasg) 2005-02-03 14:30:07.000-0600

Hi Mark, I have just uploaded the patch I made for app_dial. The info it shows is the best/easier for *my* application. It displays the remote callerid together with the channel name and uniqueid of the ringing channel. (This way I don't need to play matchmakers to find the callerid). But I'm sure the implementation is not totally correct, its inside a loop I don't really understand, so it might generate many events instead of just one. If I call to SIP/20 from my phone ("Nicolas Gudino" Extension 16) you get on the manager:

Event: Newchannel
Channel: SIP/20-32f9
State: Ringing
CallerID: 20
Uniqueid: 1107461928.358

Event: RemoteCallerID
Channel: SIP/20-32f9
CallerID: "Nicolas Gudino" <16>
Uniqueid: 1107461928.358

If the ast_call event looks like the above, then go for it! The prelink event would make me work harder to implement the callerid on the Flash Operator Panel, but either way should be fine.

Thanks for your time.
By: Fernando Romo (el_pop) 2005-02-03 15:02:23.000-0600

The name must be set in "CallerIDName" and the raw phone number in "CallerID".

If is problematic preserve the CallerID in "Newstate" event, maybe use a "Call" event with the details of phone call is god idea. The packet must be look like this:

Event: Call
Channel: SIP/3000-831f
Agent: Agent/1001 [if is avaliable to control ACD transfer calls]
State: Up
CallerID: 85909000
CallerIDName: Nicolas Gudino
Uniqueid: 1107446445.49

The agent and Caller id is reported in the event "Newchannel" with "State: UP" but not the extension (vg SIP/3000)

Event: Newchannel
Channel: Agent/1001
State: Up
CallerID: 3101
CallerIDName: ACD 1
Uniqueid: 1107464085.84

What think about it?
By: Mark Spencer (markster) 2005-02-07 09:20:46.000-0600

Okies I added a new manager event called "Dial" that happens when this dialing takes place.  If you like it I can add it into app_queue, too.
By: Russell Bryant (russell) 2005-02-09 17:01:13.000-0600

new event not included in 1.0
By: Digium Subversion (svnbot) 2008-01-15 15:24:39.000-0600

Repository: asterisk
Revision: 4981

U   trunk/apps/app_dial.c

------------------------------------------------------------------------
r4981 | markster | 2008-01-15 15:24:39 -0600 (Tue, 15 Jan 2008) | 2 lines

Add "Dial" event to link callerid, src and destination channel (bug ASTERISK-3419)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=4981