asterisk users - Aug 2005 - any ISDN/PRI signaling experts out there?

I have officially engaged in a pissing contest with the local Telco over
PRI calling name delivery.

The telco publishes their calling name delivery over PRI feature as
being bellcore gr-1367-core compliant.

The gr-1367-core spec states that the calling name is to be included as
a facility IE in the setup message, or sent in a subsequent facility IE
message with an indicator in the setup message that the CNAM will
follow.

Extensive testing and ISDN/PRI protocol analysis shows that the facility
IE they are sending out with the CNAM in it comes only after we have
sent back PROGRESS and ALERTING in response to the SETUP. If we block
the PROGRESS and ALERTING and sit and WAIT for the FACILITY we never get
it, the call will time out, so we know they are actually waiting for the
call to progress before sending the facility IE CNAM.

As far as I can tell the GR-1367-CORE spec does not define a maximum
delay in sending the facility IE or whether it is acceptable to wait for
PROGRESS and ALERT before sending it.

The setup is; Telco PRI Lucent 5ESS <> Lucent MAX TNT <> Asterisk

The MAX TNT responds to the Facility IE with ISDN error 98, invalid
message for call state.

The SIP INVITE from the TNT to Asterisk contains no Caller Name
information.

It seems really odd to me that a Lucent TNT can not translate the caller
ID Name info delivered by a Lucent 5ESS switch.

On the same setup, if I connect another PRI device to it that emulates
switch side signaling and includes the CNAM as a Display IE in the
setup, the SIP invite is properly formatted and * receives the calling
party name.

Does anyone here have enough experience with ISDN PRI signaling to
comment with some level of authority on this?

Damon

See comments inline!

Damon Estep wrote:
> I have officially engaged in a pissing contest with the local Telco over
> PRI calling name delivery.
Welcome to my world, I deal with theses guys daily!  Errgiant arn't
they.  We have a saying around work 'The telco is always wrong!'.
> The telco publishes their calling name delivery over PRI feature as
> being bellcore gr-1367-core compliant.
> 
> The gr-1367-core spec states that the calling name is to be included as
> a facility IE in the setup message, or sent in a subsequent facility IE
> message with an indicator in the setup message that the CNAM will
> follow.
> 
> Extensive testing and ISDN/PRI protocol analysis shows that the facility
> IE they are sending out with the CNAM in it comes only after we have
> sent back PROGRESS and ALERTING in response to the SETUP. If we block
> the PROGRESS and ALERTING and sit and WAIT for the FACILITY we never get
> it, the call will time out, so we know they are actually waiting for the
> call to progress before sending the facility IE CNAM.
This sounds a little fishy, Orgination Number is usually transmitted in
the SETUP message.  Your are almost correct in your messaging:

Network                  User(Switch)
Setup
                         CALL PROCEEDING
                         ALERTING
                         CALL CONNECT
CALL CONNECT ACKNOWLEDGE
....

There is about a 4sec timeout allow after SETUP is initially sent, if
CALL PROCEEDING is not transmitted by that time, the Network side will
terminiate the call.
> As far as I can tell the GR-1367-CORE spec does not define a maximum
> delay in sending the facility IE or whether it is acceptable to wait for
> PROGRESS and ALERT before sending it.
> 
> The setup is; Telco PRI Lucent 5ESS <> Lucent MAX TNT <>
Asterisk
Here is an ISDN trace from a Dialogic board attached to a 5ESS switch
with framing/coding ESF/B8ZS:

SETUP(0x05)
  1:           BEARER CAPABILITY(0x04)
  2:           IE Length(0x03)
  3:  1------- Extension Bit
      -00----- Coding Standard
      ---00000 Info. Transfer Cap.
  4:  1------- Extension Bit
      -00----- Transfer Mode
      ---10000 Info. Transfer Rate
  5:  1------- Extension Bit
      -01----- Layer 1 Indent
      ---00010 User Info. Layer 1
  1:           CHANNEL ID(0x18)
  2:           IE Length(0x03)
  3:  1------- Extension Bit
      -0------ Interface ID Present
      --1----- Interface Type
      ---0---- Spare
      ----1--- Preferred/Exclusive
      -----0-- D-Channel Indicator
      ------01 Info. Channel Sel.
3.2:  1------- Extension Bit
      -00----- Coding Standard
      ---0---- Number Map
      ----0011 Channel/Map Element
  4:  1------- Extension Bit
      -0000001 Channel Number/Slot Map
  1:           CALLING PARTY NUM(0x6c)
  2:           IE Length(0x0b)
  3:  1------- Extension Bit
      -010---- Type Of Number
      ----0001 Numbering Plan ID
      949459xxxx  Number Digit(s)    <-- Here is the ANI
  1:           CALLED PARTY NUM(0x70)
  2:           IE Length(0x04)
  3:  1------- Extension Bit
      -100---- Type of Number
      ----0001 Numbering plan ID
      200  Number Digit(s)           <-- Here is the DNIS

Notice my comments on where ANI and DNIS arrive in the SETUP message.
> The MAX TNT responds to the Facility IE with ISDN error 98, invalid
> message for call state.
This is an actual CAUSE CODE from Q.931:

Cause No. 98 ? Message not compatible

This cause indicates that the message received is not compatible with
the call state or the message type is non-existent or not implemented.

In short it is a protocol error.  Check out
http://www.telos-systems.com/?/techtalk/cause.htm for a complete lists
of causes and there meaning.
> The SIP INVITE from the TNT to Asterisk contains no Caller Name
> information.
> 
> It seems really odd to me that a Lucent TNT can not translate the caller
> ID Name info delivered by a Lucent 5ESS switch.
> 
> On the same setup, if I connect another PRI device to it that emulates
> switch side signaling and includes the CNAM as a Display IE in the
> setup, the SIP invite is properly formatted and * receives the calling
> party name.
> 
> Does anyone here have enough experience with ISDN PRI signaling to
> comment with some level of authority on this?
Can you set a ISDN trace from your telco to your switch?  I would be
curious to see what it looks like.

Again, it looks like your telco's problem.  Your best to ask them to
through a ThunderBird (T-Bird) on your circuit at your demarc and ask
them if they see the CallerID, chances are they don't
> Damon
/PB

On Fri, Aug 19, 2005 at 07:01:00AM -0600, Damon Estep
wrote:
> On the same setup, if I connect another PRI device to it that emulates
> switch side signaling and includes the CNAM as a Display IE in the
> setup, the SIP invite is properly formatted and * receives the calling
> party name.
> 
> Does anyone here have enough experience with ISDN PRI signaling to
> comment with some level of authority on this?
Asteris/libpri can process and handle either style of caller name delivery
(GR-1367 and Display IE).  If they do now send the name information in the
SETUP message you may have to do a delay in your dialplan before you access
that information.  You'd have to hook your Asterisk machine directly up
to the 5E for that to work though.

-- 
Matthew Fredrickson

> -----Original Message-----
> From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-
> bounces@lists.digium.com] On Behalf Of Paul Belanger
> Sent: Friday, August 19, 2005 4:26 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [Asterisk-Users] any ISDN/PRI signaling experts out
there?
> 
> See comments inline!
> 
> Damon Estep wrote:
> > I have officially engaged in a pissing contest with the local Telco
over
> > PRI calling name delivery.
> 
> Welcome to my world, I deal with theses guys daily!  Errgiant arn't
> they.  We have a saying around work 'The telco is always wrong!'.
> 
> > The telco publishes their calling name delivery over PRI feature as
> > being bellcore gr-1367-core compliant.
> >
> > The gr-1367-core spec states that the calling name is to be included
as
> > a facility IE in the setup message, or sent in a subsequent facility
IE
> > message with an indicator in the setup message that the CNAM will
> > follow.
> >
> > Extensive testing and ISDN/PRI protocol analysis shows that the
facility
> > IE they are sending out with the CNAM in it comes only after we have
> > sent back PROGRESS and ALERTING in response to the SETUP. If we
block
> > the PROGRESS and ALERTING and sit and WAIT for the FACILITY we never
get
> > it, the call will time out, so we know they are actually waiting for
the
> > call to progress before sending the facility IE CNAM.
> 
> This sounds a little fishy, Orgination Number is usually transmitted
in
> the SETUP message.  Your are almost correct in your messaging:
> 
> Network                  User(Switch)
> Setup
>                          CALL PROCEEDING
>                          ALERTING
>                          CALL CONNECT
> CALL CONNECT ACKNOWLEDGE
> ....
> 
> There is about a 4sec timeout allow after SETUP is initially sent, if
> CALL PROCEEDING is not transmitted by that time, the Network side will
> terminiate the call.
> 
> > As far as I can tell the GR-1367-CORE spec does not define a maximum
> > delay in sending the facility IE or whether it is acceptable to wait
for
> > PROGRESS and ALERT before sending it.
> >
> > The setup is; Telco PRI Lucent 5ESS <> Lucent MAX TNT <>
Asterisk
> 
> Here is an ISDN trace from a Dialogic board attached to a 5ESS switch
> with framing/coding ESF/B8ZS:
> 
> SETUP(0x05)
>   1:           BEARER CAPABILITY(0x04)
>   2:           IE Length(0x03)
>   3:  1------- Extension Bit
>       -00----- Coding Standard
>       ---00000 Info. Transfer Cap.
>   4:  1------- Extension Bit
>       -00----- Transfer Mode
>       ---10000 Info. Transfer Rate
>   5:  1------- Extension Bit
>       -01----- Layer 1 Indent
>       ---00010 User Info. Layer 1
>   1:           CHANNEL ID(0x18)
>   2:           IE Length(0x03)
>   3:  1------- Extension Bit
>       -0------ Interface ID Present
>       --1----- Interface Type
>       ---0---- Spare
>       ----1--- Preferred/Exclusive
>       -----0-- D-Channel Indicator
>       ------01 Info. Channel Sel.
> 3.2:  1------- Extension Bit
>       -00----- Coding Standard
>       ---0---- Number Map
>       ----0011 Channel/Map Element
>   4:  1------- Extension Bit
>       -0000001 Channel Number/Slot Map
>   1:           CALLING PARTY NUM(0x6c)
>   2:           IE Length(0x0b)
>   3:  1------- Extension Bit
>       -010---- Type Of Number
>       ----0001 Numbering Plan ID
>       949459xxxx  Number Digit(s)    <-- Here is the ANI
>   1:           CALLED PARTY NUM(0x70)
>   2:           IE Length(0x04)
>   3:  1------- Extension Bit
>       -100---- Type of Number
>       ----0001 Numbering plan ID
>       200  Number Digit(s)           <-- Here is the DNIS
> 
> Notice my comments on where ANI and DNIS arrive in the SETUP message.
> 
> > The MAX TNT responds to the Facility IE with ISDN error 98, invalid
> > message for call state.
> 
> This is an actual CAUSE CODE from Q.931:
> 
> Cause No. 98 - Message not compatible
> 
> This cause indicates that the message received is not compatible with
> the call state or the message type is non-existent or not implemented.
> 
> In short it is a protocol error.  Check out
> http://www.telos-systems.com/?/techtalk/cause.htm for a complete lists
> of causes and there meaning.
> 
> > The SIP INVITE from the TNT to Asterisk contains no Caller Name
> > information.
> >
> > It seems really odd to me that a Lucent TNT can not translate the
caller
> > ID Name info delivered by a Lucent 5ESS switch.
> >
> > On the same setup, if I connect another PRI device to it that
emulates
> > switch side signaling and includes the CNAM as a Display IE in the
> > setup, the SIP invite is properly formatted and * receives the
calling
> > party name.
> >
> > Does anyone here have enough experience with ISDN PRI signaling to
> > comment with some level of authority on this?
> 
> Can you set a ISDN trace from your telco to your switch?  I would be
> curious to see what it looks like.
> 
> Again, it looks like your telco's problem.  Your best to ask them to
> through a ThunderBird (T-Bird) on your circuit at your demarc and ask
> them if they see the CallerID, chances are they don't
> 
> > Damon
> 

Peter,

Keep in mind it is CALLER ID NAME that I do not get, I do get the
DNIS/ANI.

Here is a PM session from the telco switch, a you will see the exchange
looks like this;

Telco - SETUP
Me - PROGRESS
Me - ALERTING
Telco - FACILTY <-this is where the telco is sending caller ID name
(CNAM).
Me - STATUS - Error 98 <- the TNT does like FACILITY after SETUP.
Me - CONNECT
Telco - CONNECT ACK.

Protocol Monitoring Session Translation                           

                                                                  

Session Number = 64     Completion Message = PM STOPPED           

                                                                  

       Line Identification Information                            

                                                                  

                DSL Group and Member (DSLGM)..............15-50-24

                Physical Port (PORT)......................15-H'a7e

                Trunk Group and Member Number (TKGMN).......1969-0

                Networking Equipment Number (NEN).....15-0-0-4-1-2

                Interface Type........................Standard PRI

                Port Type......Digital Networking Unit SONET Trunk

                Port Profile.....................Standard PRI Term

                                                                  

       Monitoring Session Parameters                              

                                                                  

                Starting Time....................05/08/13 11:33:56

 


                Ending Time......................05/08/13 11:35:26

                                                                  

                Number of Events Recorded.......................10

                                                                  

                Trigger Protocol.............................Q.931

                Trigger Type...................................PER

 


              Maximum Duration......................3600 Seconds


              Recording Protocol...........................Q.931


              Recording Offset................................30


 


 


    ================                                    ==============

    Switch Transmits                                    Switch Receives


    ================                                    ==============

    Event 1  05/08/13 11:34:15  TEI 0


 08 Q.931 Call Control Message


    Call Reference Value              Orig        83


 05 Message Type                               SETUP


 04 Bearer Capability                   Length =   3


 80   Coding Standard                          CCITT


      Info Transfer Cap.                      Speech


 90   Transfer Mode                          Circuit


      Transfer Rate                        64 kbit/s


 A2   Layer 1 Protocol                   G.711 u-law


 18 Channel Identification              Length =   3


 A9   Interface ID                Implicitly Defined


      Interface Type                         Primary


      Preferred/Exclusive                  Exclusive


      D Channel Indicator              Not D Channel


      Channel Selection                 As Indicated


 83   Coding Standard                          CCITT


      Coding Type                             Number


      Channel Type                         B Channel


 8F   Channel Number                              15


 1C Standard Facility                   Length =  21


 9F   Serv Discrim             Networking Extensions


      PDU Component Begins (hex)


                                 8B0100A10F020101...


 1E Progress Indicator                  Length =   2


 82   Coding Standard                          CCITT


      Location                  Local Public Network


 83   Value                   Originator is not ISDN


 6C Calling Party Number                Length =  12


 21   Type of Number                 National Number


      Numbering Plan      ISDN/Telephony E.164/E.163


 


 83   Presentation Indicator                 Allowed


      Screening Indicator           Network Provided


      Number                              720884XXXX                    

 70 Called Party Number                 Length =  11


 A1   Type of Number                 National Number


      Numbering Plan      ISDN/Telephony E.164/E.163


      Number                              303768XXXX


 


    Raw Hex Data


    08 02 00 53 05 04 03 80 90 A2 18 03 A9 83 8F 1C


    15 9F 8B 01 00 A1 0F 02 01 01 06 07 2A 86 48 CE


    15 00 04 0A 01 00 1E 02 82 83 6C 0C 21 83 37 32


    30 38 38 34 33 35 33 38 70 0B A1 33 30 33 37 36


    38 37 34 30 30


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


                         Event 2  05/08/13 11:34:15  TEI 0


                      08 Q.931 Call Control Message


                         Call Reference Value              Dest
83

                    M 02 Message Type                     CALL
PROCEEDING

                    I 18 Channel Identification              Length 3

                      A9   Interface ID                Implicitly
Defined

                           Interface Type
Primary

                           Preferred/Exclusive
Exclusive

                           D Channel Indicator              Not D
Channel

                           Channel Selection                 As
Indicated

                      83   Coding Standard
CCITT

                           Coding Type
Number

                           Channel Type                         B
Channel

                      8F   Channel Number
15

 

                         Raw Hex Data


                         08 02 80 53 02 18 03 A9 83 8F


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

                         Event 3  05/08/13 11:34:15  TEI 0


                      08 Q.931 Call Control Message


                         Call Reference Value              Dest
83

 


                    M 01 Message Type
ALERTING

 


                         Raw Hex Data


                         08 02 80 53 01


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

    Event 4  05/08/13 11:34:16  TEI 0


 08 Q.931 Call Control Message


    Call Reference Value              Orig        83


 62 Message Type                            FACILITY


 1C Standard Facility                   Length =  29


 9F   Serv Discrim             Networking Extensions


      PDU Component Begins (hex)


                                 8B0100A117020101...


 


    Raw Hex Data


    08 02 00 53 62 1C 1D 9F 8B 01 00 A1 17 02 01 01


    02 01 00 80 0F 51 57 45 53 54 20 20 20 20 20 20


    20 20 20 20


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


                         Event 5  05/08/13 11:34:16  TEI 0


                      08 Q.931 Call Control Message


                         Call Reference Value              Dest
83

                    M 7D Message Type
STATUS

                    I 08 Cause                               Length 3

                      80   Coding Standard
CCITT

                           Location
User

                      E2   Class                           Protocol
Error

                           Value      #98, Invalid Message for Call
State

                           Diagnostic                        Message
Type

                      62   Message Type
FACILITY

                    I 14 Call State                          Length 1

                      07   Coding Standard
CCITT

                           Value                            Call
Received

 


                         Raw Hex Data


                         08 02 80 53 7D 08 03 80 E2 62 14 01 07


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

                         Event 6  05/08/13 11:34:22  TEI 0


                      08 Q.931 Call Control Message


                         Call Reference Value              Dest
83

                    M 07 Message Type
CONNECT

 


                         Raw Hex Data


                         08 02 80 53 07


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

    Event 7  05/08/13 11:34:22  TEI 0


08 Q.931 Call Control Message                                           

    Call Reference Value              Orig        83


 0F Message Type                 CONNECT ACKNOWLEDGE


 


    Raw Hex Data


    08 02 00 53 0F


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


    Event 8  05/08/13 11:34:26  TEI 0


 08 Q.931 Call Control Message


    Call Reference Value              Orig        83


 45 Message Type                          DISCONNECT


 08 Cause                               Length =   2


 80   Coding Standard                          CCITT


      Location                                  User


90   Class                             Normal Event                     

      Value                #16, Normal Call Clearing


 


    Raw Hex Data


    08 02 00 53 45 08 02 80 90


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


                         Event 9  05/08/13 11:34:26  TEI 0


                      08 Q.931 Call Control Message


                         Call Reference Value              Dest
83

                    M 4D Message Type
RELEASE

                    I 08 Cause                               Length 2

                      80   Coding Standard
CCITT

                           Location
User

                      90   Class                             Normal
Event

                           Value                #16, Normal Call
Clearing

 


                         Raw Hex Data


                         08 02 80 53 4D 08 02 80 90


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

    Event 10  05/08/13 11:34:26  TEI 0


   08 Q.931 Call Control Message


      Call Reference Value              Orig        83


 M 5A Message Type                    RELEASE COMPLETE


      Raw Hex Data


      08 02 00 53 5A


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


 


 


                  =======================================

                  *  End of Protocol Monitoring Session  *


                  ========================================

> -----Original Message-----
> From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-
> bounces@lists.digium.com] On Behalf Of Matt Fredrickson
> Sent: Friday, August 19, 2005 10:56 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [Asterisk-Users] any ISDN/PRI signaling experts out
there?
> 
> On Fri, Aug 19, 2005 at 07:01:00AM -0600, Damon Estep wrote:
> > On the same setup, if I connect another PRI device to it that
emulates
> > switch side signaling and includes the CNAM as a Display IE in the
> > setup, the SIP invite is properly formatted and * receives the
calling
> > party name.
> >
> > Does anyone here have enough experience with ISDN PRI signaling to
> > comment with some level of authority on this?
> 
> Asteris/libpri can process and handle either style of caller name
delivery
> (GR-1367 and Display IE).  If they do now send the name information in
the
> SETUP message you may have to do a delay in your dialplan before you
> access
> that information.  You'd have to hook your Asterisk machine directly
up
> to the 5E for that to work though.
> 
> --
> Matthew Fredrickson
Matthew,

Have you seen cases where the Telco requires a response to setup before
they release the Facility IE with the CNAM in it? Does zaptel/libpri
handle this and put the CNAM in the SIP invite?

My telco delivers the Facility IE only after a response to setup, and
then some times up to 1 second after the setup message is sent. Their
explanation is that the end office (serving CO) does the LIDB dip.

Seems that the invite would have to be-resent with the CNAM to get it to
work, is this what Asterisk does?

Damon