[Asterisk-Users] Weirdness with CALLERID / CALLERIDNAME from incoming PRI

Mark Spencer markster at digium.com
Tue Jan 6 06:26:51 MST 2004


> 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?

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.

Mark




More information about the asterisk-users mailing list