Understanding a ISDN PRI capture
ITU-T Recommendation Q.931 is the ITU standard ISDN connection control signalling protocol, forming part of Digital Subscriber Signalling System No. 1. It  was designed for ISDN call establishment, maintenance, and release of network connections between two notes (or DTEs - Data terminal equipments) on the ISDN D channel.
Q.931 does not have a direct equivalent in the Internet Protocol stack, but can be compared to SIP. Â Q.931 does not provide flow control or perform retransmission, since the underlying layers are assumed to be reliable and the circuit-oriented nature of ISDN allocates bandwidth in fixed increments of 64 kbit/s. Like TCP, Q.931 documents both the protocol itself and a protocol state machine.
A Q.931 frame contains the following elements:Â
Protocol discriminator (PD) - Specifies which signaling protocol is used for the connection (e.g. PD=8 for DSS1)
Call reference value (CR) - Addresses different connections which can exist simultaneously. The value is valid only during the actual time period of the connection
Message type (MT) - Specifies the type of a layer 3 message out of the Q.931-defined Message type set for call control (e.g. SETUP). There are messages defined for the call setup, the call release and the control of call features.
Information elements (IE) - Specify further information which is associated to the actual message. An IE contains the IE name (e.g. bearer capability), their length and a variable field of contents.
Q.931 Messages
SETUP: This message is sent by the calling user to the network and by the network to the called user to initiate access connection establishment.
CALL PROCEEDING: This message is sent by the called user to the network or by the network to the calling user to indicate that requested call establishment has been initiated and no more call establishment information will be accepted.
ALERTING: This message is sent by the called user to the network, and by the network to the calling user, to indicate that called user alerting (or ringing) has been initiated
CONNECT: This message is sent by the called user to the network, and by the network to the calling user, to indicate call acceptance by the called user
CONNECT ACKNOWLEDGE: This message is sent by the network to the called user to indicate that the user has been awarded the access connection. It may also be sent by the calling user to the network to allow symmetrical access connection control procedures
DISCONNECT: sent to indicate a request to terminate the connection, by the end that seeks to terminate
RELEASE: This message is sent by the user or the network to indicate that the equipment sending the message has disconnected the channel (if any), and intends to release the channel and the call reference, and that the receiving equipment should release the channel and prepare to release the call reference after sending RELEASE COMPLETE
RELEASE COMPLETE: This message is sent by the user or the network to indicate that the equipment sending the message has released the channel (if any) and call reference. The channel is available for reuse, and the receiving equipment shall release the call reference
RESTART: This message is sent by the user or network to request the recipient to restart (i.e. return to an idle condition) the indicated channel(s) or interface
RESTART ACKNOWLEDGE: This message is sent to acknowledge the receipt of the RESTART message and to indicate that the requested restart is complete.
ISDN PRI Asterisk debug captureÂ
To understand the Asterisk logger output when PRI debug is enabled, first you need to know which side is sending which messages.
Â
When Asterisk SENDS a message to the telco, the messages start with:
Â
>
Â
When Asterisk RECEIVES a message from the telco, the messages start with:
Â
<
Â
If Asterisk sends a call out to the telco, you will see something like this:
Â
> Protocol Discriminator: Q.931 (8) len=65
> Call Ref: len= 2 (reference 353/0x161) (Originator)
> Message type: SETUP (5)
> [04 03 80 90 a2]
> Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0)
> Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
> Ext: 1 User information layer 1: u-Law (34)
> [18 03 a9 83 85]
> Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
> ChanSel: Reserved
> Ext: 1 Coding: 0 Number Specified Channel Type: 3
> Ext: 1 Channel: 5 ]
> [1e 02 80 83]
> Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: User (0)
> Ext: 1 Progress Description: Calling equipment is non-ISDN. (3) ]
> [28 14 b1 44 69 67 69 75 6d 20 54 65 63 68 20 53 75 70 70 6f 72 74]
> Display (len=20) Charset: 31 [ Digium Tech Support ]
> [6c 0c 21 81 32 35 36 34 32 38 36 30 30 30]
> Calling Number (len=14) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
> Presentation: Presentation permitted, user number passed network screening (1) '2564286000' ]
> [70 08 a1 35 32 30 31 32 38 31]
> Called Number (len=10) [ Ext: 1 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '5201281' ]
Â
As you can see, the message starts with > since Asterisk is sending the call. You will also see the Message type as  SETUP indicating the start of the call and the channel of the span being used  Ext: 1  Channel: 5 , the caller ID in the Calling Number (2564286000) and the number dialed in The called number (5201281).Â
Â
Another important thing when debugging (especially on a live system) is the reference number. The line above the Message type has this number which is the unique identifier for the call. In this case its 353. All messages related to this call will have the same reference number for outbound and inbound messages from the telco. Once you find the SETUP and the reference for it, you can track the whole call.
Â
After Asterisk sends a SETUP to the telco notifying them that it is sending them a new call, the telco should reply back with a CALL PROCEEDING. Some switches will first reply back with a SETUP ACKNOWLEDGE message before CALL PROCEEDING. It looks like this:
Â
Â
For this message the reference number is 353, and this message is from the telco as indicated by <. This basically means that the telco is processing the call.
Â
Â
The above message is also from the telco. This ALERTING message tells Asterisk that the phone it called is ringing.
Â
Â
This message from the telco tells Asterisk that the call was answered by the phone we dialed.
Â
Â
Asterisk is telling the telco that we are acknowledging the CONNECT and bringing the call fully up. After this point, the call is up and passing audio.
Â
Â
Disconnects marks the end of the call.  This message came from the telco and states a reason in the Cause field. On this message it was a normal hangup or cause 16.  If the call was disconnected because of an error, the reason will be displayed in this Cause field. Many times it's not clear as to what error happened though, and some research may be required. For more information please see ISDN Disconnect cause code
Â
Â
Asterisk sends this message back to the telco telling that the channel is being releaseÂ
Â
Â
Telco completes the handshake informing that it has released the channel.Â
Special scenarios
ALERTING messages that does not include progress  indication as the one showed below does not include ringback audio. This means the sender is still ALERTING that they are ringing, but is not sending any ringback. This can be a reason for the other end of the call to not hear any ringback.
Â
Â
RESTART: A message may be sent if there is a problem with one of the B-channels (such as a call collision), which results in a need to clear the channel and the far end must reply with a  RESTART ACKNOWLEDGE, meanwhile, no calls shall be placed or accepted over the channel by the originator of the RESTART message. This is stated on section 5.5.1 of the Q.931 specification.Â
Asterisk will also send RESTART periodically if the priresetinterval is specified in the chan_dahdi.conf file, as this indicates how often (if ever) to reset idle B-channels on the PRI