asterisk users - Dec 2003 - Weirdness with CALLERID / CALLERIDNAME from incoming PRI

Hey all,

We've upgraded our PRI trunk to support what BellSouth calls "enhanced
caller id name delivery". The weird part is, I'm only capable of seeing
the name portion on incoming calls within voicemail2's email delivery.

For example, on an incoming call, asterisk is reporting this:

Context from extensions.conf (BS delivers 7-digit DIDs):

exten => 9133727,1,Answer
exten => 9133727,2,SetMusicOnHold,random
exten => 9133727,3,NoOp,${CALLERID}
exten => 9133727,4,Dial(SIP/5001&SIP/5013,20)
exten => 9133727,5,Voicemail2(u5001@sip)
exten => 9133727,105,Dial(SIP/5002)
exten => 9133727,106,Voicemail2(u5001@sip)
exten => 9133727,206,Voicemail2(b5001@sip)

When calling from 404-555-8183 to the number above the console is
reporting:

    -- Accepting call from '4045558183' to '9133727' on channel
6, span
1
    -- Executing SetMusicOnHold("Zap/6-1", "random") in new
stack
    -- Executing NoOp("Zap/6-1", "4049338183") in new stack

So from the NoOp echo, I don't see the full name (fyi, I get the same
for CALLERIDNAME also).

However, if I let the call go through to voicemail via priority 5, the
email message I receive has the following header:

	Just wanted to let you know you were just left a 0:05 long
message (number 1) in mailbox 5001 from "ATLANTA, GA"
<4045558183>, on
Wednesday, December 24, 2003 at 10:18:22 AM so you might want to check
it when you get a chance.  Thanks!

My thought is that the name is being delivered else voicemail2 wouldn't
be able to get the "ATLANTA, GA" portion.

Running from CVS, version:      Asterisk CVS-12/24/03-10:55:24

Any idea why I'm not able to parse or see the CALLERIDNAME from
extensions.conf but voicemail2 sees it just fine?

Happy Holidays all,

--- Gavin Adams
Promisant (Technology) Ltd.
Atlanta, GA

> -----Original Message-----
> From: Joe Kellman [mailto:jkellman@chutneytech.com]
> 
> i am not sure if somebody asked this question in relation to your
problem,
> what do you get when you do a pri debug span X.  i know with some
> providers
> (i am using xo) the messages are transmitted as a facility message
that
> doesn't get picked by * too well...jak
Hi Joe,

Thanks for the reply. Yup, sure enough it appears the calling party name
is in the facility message. I get the following, where the 'ATLANTA' and
'GA' sections are the calling party name.

< Protocol Discriminator: Q.931 (8)  len=32
< Call Ref: len= 2 (reference 527/0x20F) (Originator)
< Message type: FACILITY (98)
< Facility (len=25) [ < Facility (len=25) [ 0x9f, 0x8b, 0x01, 0x00,
0xa1, 0x13, 0x02, 0x01, 0x01, 0x02, 0x01, 0x00, 0x80, 0x0b, 'ATLANTA',
0x2c, 0x20, 'GA'< Facility (len=25) [ 0x9f, 0x8b, 0x01, 0x00, 0xa1,
0x13, 0x02, 0x01, 0x01, 0x02, 0x01, 0x00, 0x80, 0x0b, 'ATLANTA', 0x2c,
0x20, 'GA' ]
-- Processing IE 28 (Facility)

I don't have a good understanding for the Q.931 signaling process, but
is it possible the call is being presented and handled by the extension
logic prior the facility message coming through? Or is this just the way
the pri debug span X output is given?

I guess the next question is, are there any commands that could map the
facility message to the calling party name before sending the call to
the extension?

Thanks for the pointer, one step closer!

Regards,

--- Gavin

> -----Original Message-----
> From: asterisk-users-admin@lists.digium.com [mailto:asterisk-users-
> admin@lists.digium.com] On Behalf Of Mark Spencer
> 
> Try doing a Wait(1) before you do the dial command.  The
"facility" is
> sent *after* the initial setup in a totally separate message, so
unless
> you wait first, we won't get the name.  We *do* have some code to try
to
> extract it from FACILITY, but since we don't know the spec, it's
just
a
> hack based on our observations on one particular switch.
Works great here too Mark, thanks. FYI, the switch we speak with is a
5ESS (BellSouth).

If you need any pri debugs, feel free to ask.

Regards,

--- Gavin