[Home]

Summary:ASTERISK-02445: the CALLERIDNAME information not populated on a PRI Call
Reporter:frank (frank)Labels:
Date Opened:2004-09-21 16:50:03Date Closed:2011-06-07 14:10:41
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:the TE405 is connected as CPE to a nortel DMS100 switch.  calls that come in to the 405 from the nortel have all of the caller id number and name information in the facility message.  however, the CALLERIDNAME variable never is filled with the caller id Name

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

the following lines in extensions.conf
extensions.conf:exten => _X.,1,noop(${CALLERIDNAME})
extensions.conf:exten => _X.,2,noop(${CALLERIDNUM})
extensions.conf:exten => _X.,3,noop(${CALLERID})
always produce the the Caller id Number only on the monitor.  

however the facility message has the following in it that shows the telco is sending the caller id name
^@^M^[[Ka1*CLI> ^M< Facility (len=31, codeset=0) [ ^@^M< Facility (len=31, codeset=0) [ 0x9f, 0x8b, 0x01, 0x00, 0xa1, 0x17, 0x02, 0x01, 'a', 0x02, 0x01, 0x00, 0x80, 0x0f, 'WIRELESS', 0x20, 'CALLER'^@^M< Facility (len=31, codeset=0) [ 0x9f, 0x8b, 0x01, 0x00, 0xa1, 0x17, 0x02, 0x01, 'a', 0x02, 0x01, 0x00, 0x80, 0x0f, 'WIRELESS', 0x20, 'CALLER' ]

Comments:By: frank (frank) 2004-09-21 16:52:32

this problem does not seem to be impacting the comedian voicemail system which is able to somehow get the caller id name and number.  from an email sent by comedian mail.

You were just left a 0:23 long message (number 1)
in mailbox 8423721 from "TRI STATE TITLE" <3144631462>, on Tuesday, September 21, 2004 at 05:23:08 PM.
By: frank (frank) 2004-09-21 16:59:18

if a call comes in on one of the spans of the TE405 (PRI) and the extension.conf has something like
exten => _X.,1,Dial(Zap/r2/${EXTEN})
to route the call back out one of the other PRI spans on the 405, then the equipment that is receiving the call from asterisk never sees any of the caller id name information.  the only thing that asterisk sends with the call is caller id number.
By: frank (frank) 2004-09-21 17:15:42

in the for what it's worth category, this has been reported to support under
[digium.com ASTERISK-8786]
By: arnu (arnu) 2004-09-21 19:43:20

This is actually not a bug.
The FACILITY message is sent some time after the initial SETUP message.
Your extensions.conf pulls the variables IMMEDIATELY after the received SETUP.
At this point of time the FACILITY message has not been received yet.
So CALLERIDNAME is not populated yet. Just add a wait(1) on priority 1 and everything will work fine.

Actually this has been discussed on the mailing lists several times.

- Alfred.
By: frank (frank) 2004-09-21 20:40:15

well, regarding the list, i did a search on callerid for the last several months and found nothing.  not sure how i missed it.

but why does the bridged call to the outbound pri span not carry with it any of the caller id name information?

also, matt at digium support confirmed this as an issue that was "actively" being addressed.  so, someone at digium is under the impression that there is something here that requires some attention.  is there some confusion here or there?  what might they be actively addressing?

either way, i confirm your wait(1).
By: Brian West (bkw918) 2004-09-21 22:06:10

Same BUG http://bugs.digium.com/bug_view_page.php?bug_id=0002310

This btw is not major....
By: frank (frank) 2004-09-22 05:53:57

only a part of what i put in this bug is duplicated by ASTERISK-2280.  the other part is not a duplicate. further more, digium support indicated that they are, in their words, "actively being addressing" this issue.  if it is not a problem or bug, what are they addressing?  i think this bug should remain un-resolved and open.

as a bug marshal, why not leave it open or see if you can get it resolved by having digium support put in the bug what they are actively addressing realated to this.  perhaps it should be marked resolved and closed.  but we sure do not know since the work at digium support i pointed out appears to be related and the details of their work have not been revealed yet.

i hesitated even bothering to put this into the bug system.  matt @digium support suggested i could open a bug.  i asked matt@digium support to please enter it into the bug tracker in a hope that the bug would not be summarily dismissed and closed/resolved/invalid or otherwise noted as 'not a bug' because "it doesn't work with all..." (see bug 2165).
By: Mark Spencer (markster) 2004-09-22 08:04:11

Because your callerid name is arriving in a separate FACILITY message after the call setup, you will need to do a Wait(1) if you want to be able to receive that before proceeding.

Please confirm that doing a Wait(1) before your NoOp gives you the name, thanks.
By: arnu (arnu) 2004-09-22 09:37:09

frank.

you are combining two seperate issues.
-a) your initial observation that you can't see incoming CNAMES is not a bug at        
   all. The ability process a call immediately after SETUP gives the *
   programmer more flexibility than a built in mandatory 1 sec. wait. (BTW 1    
   sec is sometimes not long enough when connected to a slow PSTN-CO which has    
   to pull the name out of a database so in this case 2 sec. is more
   appropriate).

-b) your observation that * is not sending CNAME on outgoing calls is not  
   entirely correct. Then the span is configured as PRI_NET it will send CNAME  
   to the other end. * currently uses the DISPLAY IE to do so, not the    
   FACILITY IE.  
   Both ways are correct means to transmit CNAME. Although transport in the
   FACILITY IE seems to be more popular with PBX vendors.

Anyway this has been addressed in bug 002310