According to Bellcore and ANSI specifications, in-band progress tones and announcements are required for PSTN services and for ISDN speech and 3.1-kHz voice services. In order to guarantee that the necessary in-band tones are generated when required (and at the right switch), Cisco H.323 gateways must ensure that Progress Indicators or PIs are carried end-to-end in called signaling messages between the calling and called parties. The PI is an IE that signals when in-band tones and announcements are available. The PI is configured by the "progress_ind" command. Below is a list of PIs that can be configured on a Cisco H.323 gateway:
Configurable Progress Indicator Values for H.323 Gateways
- PI=0 No progress indicator is included. Message type: Setup
- PI=1 Call is not end-to-end ISDN; further call progress information may be available in-band. Message type: Alert, setup, progress, connect
- PI=2 Destination address is non-ISDN Message type: Alert, progress, connect
- PI=3 Origination address is non-ISDN Message type: Setup
- PI=8 In-band information or appropriate pattern is now available Message type: Alert, progress, connect
Interworking Between ISDN and non-ISDN Networks
If the originating CO switch does not include PI in the setup messages, the originating gateway assumes that the CO switch is ISDN and will generate the ringback tones for the call.
- To have the terminating switch produce the ringback tones, set the PI to 8 in the alert messages on the terminating gateway. This is configured in the POTS dial-peer.
- To have the originating gateway to produce the ringback tones, set the PI to 3 in setup messages on the originating gateway. This is configured in the VoIP dial-peer.
ISDN Q.931 Call Setup Diagram
This is a useful diagram to understand ISDN Q.931 traffic between the CO and your voice gateway. If you’re using T1-PRIs (i.e. most organizations in the US), this information is relevant to you.
Working Example of a Q.931 ISDN Output – Outbound over T1-PRI
This is an example of a successful Q.931 ISDN call over a T1-PRI. I placed a call from 555-516-3748 (area code changed purposefully) to 555-836-7626. My comments are inline below. I have also pointed out the progress indicator value below in red. I encourage you to compare the diagram above with the ISDN messages in the Q.931 output (e.g. CALL_PROC, CONNECT, ALERTING, etc.).
Feb 11 10:00:36.317: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x20D8
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98391
Exclusive, Channel 17 [## Using channel 17 on the T1-PRI]
Calling Party Number i = 0×2181, ’5555163748′ [## My desk phone that is calling outbound]
Plan:ISDN, Type:National
Called Party Number i = 0xA1, ’15558367626′ [## My cell phone that is receiving the call]
Plan:ISDN, Type:National
Feb 11 10:00:36.641: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0xA0D8
Channel ID i = 0xA98391
Exclusive, Channel 17
Feb 11 10:00:37.809: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0xA0D8
Progress Ind i = 0×8488 – In-band info or appropriate now available
Feb 11 10:00:38.349: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0xA0D6
Progress Ind i = 0×8482 – Destination address is non-ISDN [## I believe this is because the destination is an AT&T cell phone. Ideas?]
Feb 11 10:00:38.353: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x20D6
Feb 11 10:00:41.653: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0xA0D8
Feb 11 10:00:41.661: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x20D8
Feb 11 10:00:46.093: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x20D2
Cause i = 0×8090 – Normal call clearing
Feb 11 10:00:46.121: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0xA0D2
Feb 11 10:00:46.153: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x20D2
Feb 11 10:00:46.721: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x20D8
Cause i = 0×8090 – Normal call clearing
Feb 11 10:00:46.741: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0xA0D8
Feb 11 10:00:46.769: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x20D8
Working Example of a Q.931 ISDN Output – Inbound over T1-PRI
1787319: Feb 11 10:09:00.001: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8 callref = 0×0799
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3 [## Using channel 3 on the T1-PRI]
Facility i = 0x9F8B0100A10F02015206072A8648CE1500040A0100
Protocol Profile = Networking Extensions
0xA10F02015206072A8648CE1500040A0100
Component = Invoke component
Invoke Id = 82
Operation = InformationFollowing (calling_name)
Name information in subsequent FACILITY message
Calling Party Number i = 0×2183, ’5558367626′ [## My cell phone that is calling outbound]
Plan:ISDN, Type:National
Called Party Number i = 0×80, ’3748′ [## My desk phone that is receiving the call. Note: Our carrier sends us only the last four digits.]
Plan:Unknown, Type:Unknown
1787320: Feb 11 10:09:00.037: ISDN Se0/1/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0×8799
Channel ID i = 0xA98383
Exclusive, Channel 3
1787321: Feb 11 10:09:00.037: ISDN Se0/1/0:23 Q931: TX -> ALERTING pd = 8 callref = 0×8799
Progress Ind i = 0×8088 – In-band info or appropriate now available
1787322: Feb 11 10:09:00.297: ISDN Se0/1/0:23 Q931: RX <- FACILITY pd = 8 callref = 0×0799
Facility i = 0x9F8B0100A117020153020100800F4B524F4C4C204F4E20545241434B20
Protocol Profile = Networking Extensions
0xA117020153020100800F4B524F4C4C204F4E20545241434B20
Component = Invoke component
Invoke Id = 83
Operation = CallingName
Name Presentation Allowed Extended
Name = KROLL ON TRACK
1787323: Feb 11 10:09:01.645: ISDN Se0/1/0:23 Q931: RX <- PROGRESS pd = 8 callref = 0x805B
Cause i = 0x82FF – Interworking error; unspecified
Progress Ind i = 0×8281 – Call not end-to-end ISDN, may have in-band info [## I believe this is because the destination is an AT&T cell phone. Ideas?]
1787324: Feb 11 10:09:03.433: ISDN Se0/1/0:23 Q931: TX -> CONNECT pd = 8 callref = 0x838F
1787325: Feb 11 10:09:03.493: ISDN Se0/1/0:23 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x038F
1787326: Feb 11 10:09:03.789: ISDN Se0/1/0:23 Q931: TX -> CONNECT pd = 8 callref = 0×8799
1787327: Feb 11 10:09:03.845: ISDN Se0/1/0:23 Q931: RX <- CONNECT_ACK pd = 8 callref = 0×0799
1787328: Feb 11 10:09:05.093: ISDN Se0/1/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x805B
1787329: Feb 11 10:09:05.101: ISDN Se0/1/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x005B
1787330: Feb 11 10:09:06.409: ISDN Se0/1/1:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x317B
Cause i = 0×8290 – Normal call clearing
Good post. Very informative debugs. I look forward to reading more from you.
I have a question regarding PI and ring back. Can this also resolve delay at the begining of the call? I have calls that when they are dialed outbound, the call connects but the voip side does not hear the first 10 se4conds of the call.