Answer and Disconnect Supervision on T1 Digital Trunks

Introduction

There is often some confusion about the terms "Answer Supervision" and "Disconnect Supervision" on Telephony systems. This document describes what these terms mean and how they apply to routers with voice interfaces.

Prerequisites

Requirements

There are no specific reqirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Answer and Disconnect Supervision Basics

CAS E&M Signaling Basics

For digital T1 Channel Associated Signaling (CAS) trunks that run ear and mouth (E&M) signaling, there are generally only two states in which a a voice channel can be. When there is no call on a channel, the channel is in the Idle, or On- Hook state. When there is an active call on a channel, then the channel is in the Seized, or Off-Hook state. This table shows the standard Transmit/Receive ABCD signaling bit patterns for the Idle and Seized states:

After a channel is initially seized, each device must indicate the progress of a call. The progress indicators include whether a call is answered or remains unanswered, and when a call is answered, which party disconnects first. These call progress states are important as Telephony systems need to know when the call was attempted, answered, and cleared, hence the term Answer and Disconnect Supervision.

Why Answer and Disconnect Supervision is Required

The most obvious reason for Answer and Disconnect Supervision is for billing—the telephone exchange and the customer need an accurate indication of calls through a network. It is standard for telephone companies to not charge for unanswered or unsuccessful calls. All call detail records (CDRs) produced should indicate a call was unanswered or unsuccessful, and therefore, incur no charge from the billing system.

Secondly, some systems may not cut through the audio path until there is a positive indication that the called party answered the call—there may not be an audio connection until the answer signal is sent.

Lastly, the channel should become free to take new calls when the previous call clears. If there was no indication of the call's disconnect, all channels on the T1 trunk would eventually be blocked.

Example of Answer and Disconnect Supervision

This example illustrates how answer and disconnect supervision works and how IOS debugs can be used to gain visibility into this process.

Wink Start Signaling

This example shows E&M wink start signaling. This diagram illustrates the various call progress conditions.

Wink start is used to notify the remote side that it can send the Dialed Number Identification Service (DNIS), also referred to as the Called Number.

For an incoming call (network to router), this occurs:

1. Network goes off-hook. ABCD bits = 1111.

2. Router sends wink. ABCD bits transition from 0000 to 1111 for 200 ms, then back to 0000.

3. Network sees the wink, and then proceeds to send DNIS (Called Number) information. This is done when inband multifrequency/dual tone multifrequency (MF/DTMF) tones are sent, which are decoded by the DSPs.

4. Router goes off-hook when the call is answered. ABCD bits = 1111.

5. Audio path is opened, parties can talk, and the billing system registers a call start record.

In an outgoing call (router to network) the same procedure occurs, but the network and router switch roles. The reason is that the signaling is symmetric.

These occur when a disconnect from the network to the router happens:

1. Network goes on-hook. ABCD bits = 0000.

2. Router sees the network go on-hook and the router goes on-hook. ABCD bits = 0000.

3. Audio path is closed, and the billing system registers a call stop record.

For a disconnect from the router to the network, these steps are reversed.

It is possible to observe the answer and disconnect supervision if you run appropriate signaling debugs on voice gateway routers.

Wink Start Signaling Debug

These traces are from a Cisco AS5300 that shows calls from network to router and router to network. The AS5300 router ran the debug cas command to provide real-time traces of the CAS signaling bit status.

multi-5-17#show debug
CAS: Channel Associated Signaling debugging is on


!--- Router receives initial seizure from network:
 
May 15 15:35:59.455: from Trunk(0):(0/2): Rx LOOP_CLOSURE (ABCD=1111)


!--- Router sends a 200 msec wink towards network:
 
May 15 15:35:59.679: from Trunk(0):(0/2): Tx LOOP_CLOSURE (ABCD=1111)
May 15 15:35:59.883: from Trunk(0):(0/2): Tx LOOP_OPEN (ABCD=0000)
		

!--- Router sends an answer signal to indicate that the called !--- party has answered the call: 

May 15 15:36:09.943: from Trunk(0):(0/2): Tx LOOP_CLOSURE (ABCD=1111)


!--- Router receives a disconnect from network requesting !--- to clear the call:
 
May 15 15:36:32.975: from Trunk(0):(0/2): Rx LOOP_OPEN (ABCD=0000)


!--- Router responds with a disconnect, call is cleared: 

May 15 15:36:33.295: from Trunk(0):(0/2): Tx LOOP_OPEN (ABCD=0000)

The next trace shows a call from the router to the network.

multi-5-17#show debug
CAS: Channel Associated Signaling debugging is on


!--- Router sends initial seizure to network: 

May 15 15:40:26.471: from Trunk(0):(0/5): Tx LOOP_CLOSURE (ABCD=1111)


!--- Router receives a 200 msec wink from network: 

May 15 15:40:26.679: from Trunk(0):(0/5): Rx LOOP_CLOSURE (ABCD=1111)
May 15 15:40:26.883: from Trunk(0):(0/5): Rx LOOP_OPEN (ABCD=0000)


!--- Router receives an answer signal indicating that a telephone !--- handset on the network has answered the call: 

May 15 15:40:36.495: from Trunk(0):(0/5): Rx LOOP_CLOSURE (ABCD=1111)


!--- Router sends a disconnect to clear the call:
 
May 15 15:40:57.631: from Trunk(0):(0/5): Tx LOOP_OPEN (ABCD=0000)


!--- Router receives disconnect response from network, !--- call is cleared:
 
May 15 15:40:58.163: from Trunk(0):(0/5): Rx LOOP_OPEN (ABCD=0000)

As you can see from these debug traces, it is possible to determine the direction of the call and if the call was answered. These debugs help you resolve disagreements about the source and reason for call disconnects, as well as disputed billing records.

Related Information

• Troubleshooting EM_PARK Issues for E&M Digital CAS Signaling
• Voice Technology Support
• Voice and IP Communications Product Support
• Troubleshooting Cisco IP Telephony
• Technical Support - Cisco Systems