Overview of Circuit-Switched Interfaces

Interfaces to the PSTN come in two flavorsanalog and digital.

In analog interfaces, a microphone directly converts voice energy into electrical energy on a wire, while a speaker on the far end of the wire converts the electrical signal back into voice energy. The underlying voice technology does not differ significantly from that used since the beginning of the twentieth century.

In digital interfaces, voice energy from the speaker is sampled by the phone and converted into a sequence of binary numbers (a process called analog-to-digital conversion [ADC]). The bits in these binary numbers are then encoded on to the wire in sequence, with zeroes representing one voltage level and ones representing a different voltage level. A digital-to-analog converter (DAC) in the receiving device can then convert the numbers back into a close approximation of the original voice energy.

Because the voice information is first being encoded, digital systems can interleave nonvoice information in the information stream sent to the other end of the wire. This interleaving allows digital interfaces to support signaling protocols (which allow the phone system to deal with a wider variety of call scenarios than traditional analog techniques) and signaling information (such as reasons for call clearing, calling name and number, and called name and number).

Analog Trunks

Analog interfaces come in three flavors:

• Foreign Exchange Station (FXS)
• Foreign Exchange Office (FXO)
• Ear and Mouth (E&M)

The sections that follow describe these interfaces in more detail.

FXS/FXO Trunks

FXS/FXO signaling is the most common type of signaling used by residential phones. FXS/FXO signaling can also be used for trunk connections between two PBXs or between a PBX and a central office switch. When connecting analog devices using these interfaces, always pair an FXO device on one end to an FXS device on the other end; two FXS or FXO devices cannot directly communicate. In a residence, the RJ-11 wall jack provides an FXO interface to the analog phone, and in the switching office (or concentrator), a corresponding FXS interface exists to connect the switch to the phone.

FXS/FXO signaling is carried over a pair of wires, twisted to permit the signal to carry over a longer distance. The pair of wires comprises a single circuit, which is always connected in the switch (which provides electricity to the circuit via a battery or electrical ground connection) and which is only connected in the phone when the phone is off-hook.

Signaling occurs via making and breaking the circuit. Two major signaling schemes exist: loop-start signaling and ground-start signaling.

In loop-start signaling, which is the kind most commonly used in residential service, when the phone goes off-hook, the circuit is closed, and the central office detects the change in current. The central office then inserts tone detectors to collect the digits, which are sent as tones on the wire. When offering calls, the switch applies ring voltage to the line and, when voltage changes when the user answers and completes the circuit, connects the user through to the caller.

All the preceding discussion talks about phones, even though this is the trunks chapter. What gives?

In a CallManager cluster, when you deploy gateways running loop-start FXO signaling, CallManager essentially emulates a standard home phone. So, when a user places a call to the PSTN from a Cisco 79xx series IP Phone, when the gateway receives the call, it simply takes the FXO interface off-hook. Similarly, when the IP Phone user hangs up, the analog gateway simply goes back on-hook.

In a residential environment, the central office always leaves its part of the loop-start circuit connected. Only the phone side of the circuit actually hangs up on a call by breaking the circuit; in effect, the central office has no way to hang up on the phone side. The loop-start signaling scheme, thus, relies on a user's physical presence at the phone to recognize that the far end has hung up (a valediction such as "goodbye," silence on the line, impatience, or other purely human reasons) and to disconnect the circuit. In other words, an FXO loop-start interface lacks disconnect supervision, because the FXS interface can't hang up (discounting more recent techniques such as power denial and battery reversal, which certain analog devices, by convention, can interpret as a disconnection by the far end).

As a result, when a machine, such as a packet- to circuit-switched gateway is playing the part of the user, scenarios arise in which the gateway doesn't realize that the far end has hung up and therefore leaves the call connected. In extreme cases, such as when an incoming FXO call is transferred back out another FXO gateway, the circuits can be taken permanently out of service (and potentially a large phone bill rung up).

Cisco gateways provide a variety of ways to deal with the lack of disconnect supervision on FXO loop-start trunks. The Cisco Press book Troubleshooting Cisco IP Telephony goes into more detail about the sorts of problems that can arise with the lack of disconnect supervision and possible solutions.

Unlike loop-start signaling, ground-start signaling does not suffer from the lack of disconnect supervision. In ground-start signaling, the gateway on the FXO interface can detect changes in the current, and the FXS side of the connection changes its behavior to indicate disconnection.

Table 4-1 indicates the Cisco gateways that offer FXS and FXO interfaces.

Table 4-1. Cisco Gateways/VICs That Offer FXS/FXO Interfaces

Gateway Model	Gateway Control Protocol
Cisco IOS Integrated Routers
Cisco 1750	MGCP, H.323, SIP
Cisco 1751	MGCP, H.323, SIP
Cisco 1760	MGCP, H.323, SIP
Cisco 1800 series	MGCP, H.323, SIP
Cisco 2600 series	MGCP, H.323, SIP
Cisco 2800 series	MGCP, H.323, SIP
Cisco 3600 series	MGCP, H.323, SIP
Cisco 3700 series	MGCP, H.323, SIP
Cisco 3800 series	MGCP, H.323, SIP
Cisco Standalone Voice Gateways
Cisco Voice Gateway 200 (VG200)	MGCP, H.323, SIP
Cisco Access Analog Trunk Gateway (AT-2, AT-4, AT-8)	Skinny Gateway Control Protocol
Cisco Access Analog Station Gateway (AS-2, AS-4, AS-8)	Skinny Gateway Control Protocol
Cisco VG224 Analog Phone Gateway	Skinny Client Control Protocol
Cisco VG248 Analog Phone Gateway	Skinny Client Control Protocol
Cisco IAD2420	MGCP
Cisco Catalyst Voice Gateway Modules
Cisco Catalyst 4000 Access Gateway Module (WS-X4604-GWY)	MGCP, H.323, SIP
Cisco Catalyst 4224 Voice Gateway Switch	MGCP, H.323, SIP
Cisco Catalyst 6000 24-Port FXS Analog Interface Module (WS-X6624-FXS)	MGCP
Cisco Communication Media Module (WS-X6600-24FXS)	MGCP

 

E&M Trunks

E&M interfaces are most commonly used on PBXs. Unlike FXO/FXS interfaces, E&M trunks rely on a four-wire, six-wire, or eight-wire circuit.

In E&M signaling, two of these wiresE and Mare used to communicate signaling information. From a practical standpoint, this means that E&M trunks don't suffer from the disconnect supervision issues that can trouble FXS/FXO deployments and that a condition called glare can occur. Glare occurs when both sides of the wire simultaneously go off-hook on the interface. Glare avoidance allows one or the other side to back down gracefully.

Table 4-2 lists Cisco gateways/VICs that support E&M interfaces.

Table 4-2. Cisco Gateways That Offer E&M Interfaces

Gateway Model	Gateway Control Protocol
Cisco IOS Integrated Routers
Cisco 1751	MGCP, H.323, SIP
Cisco 1760	MGCP, H.323, SIP
Cisco 1800 series	MGCP, H.323, SIP
Cisco 2600 series	MGCP, H.323, SIP
Cisco 3600 series	MGCP, H.323, SIP
Cisco 3700 series	MGCP, H.323, SIP
Cisco 3800 series	MGCP, H.323, SIP
Cisco Standalone Voice Gateways
Cisco Voice Gateway 200 (VG200)	MGCP, H.323, SIP
Cisco Catalyst Voice Gateway Modules
Cisco Catalyst 4000 Access Gateway Module (WS-X4604-GWY)	MGCP, H.323, SIP
Cisco Catalyst 4224 Voice Gateway Switch	MGCP, H.323, SIP

 

Digital Trunks

Digital interfaces come in three basic flavors:

• Channel Associated Signaling (CAS) trunks
• Basic Rate Interface (BRI) trunks
• Primary Rate Interface (PRI) trunks

In addition, PRI trunks can run a protocol called QSIG, which fosters feature interoperability between PBXs.

What is the common characteristic of these interfaces? They're based on the concepts of time-division multiplexing (TDM) and pulse code modulation (PCM).

Using analog technologies, if you want to support 24 simultaneous active calls, you must pull 24 sets of wires from your service provider into your enterprise.

Reducing the number of wires required to manage multiple conversations necessarily means that somehow these conversations need to be able to learn how to share the capacity of a single wire. In the 1960s, Bell System introduced the T-carrier system, which defines exactly how this task can be done. A different system, the E-carrier system, is used in Europe.

The T-carrier system depends on TDM. In TDM, the idea is each user of a particular facility must "take turns" communicating.

Figure 4-3 captures the essence of the stratagem.

Figure 4-3. Time-Division Multiplexing

Assume that Alice and Bob are conversing and Carol and Dave are conversing. Alice and Carol must share the same communications facility. They both want to encode a sentence to send to their respective partners.

If Alice were to say her entire sentence before Carol could start to say her sentence, the conversations would be full of long pauses. Instead of encoding full sentences, however, the communication could be broken into smaller bits; then Alice and Carol could communicate simultaneously. This process of breaking communications into a small piece is the process of sampling.

Assume that Alice and Carol, in the space of one second, say exactly a single word and that the system is breaking the communications into one-second samples. Each sample, therefore, contains a single word.

Also assume that the communications facility between the women and the men is capable of transmitting two samples every second.

To prevent Alice's and Carol's conversations from becoming hopelessly entangled, Alice and Carol can take turns putting their samples into the communication facility.

If by prior arrangement Alice places her samples into the communications facility in odd-numbered turns and Carol places her samples into the communications facility in even-numbered turns, all the information can be encoded into the same stream in the jumbled yet orderly fashion depicted.

Then, if also via the prior arrangement, Alice's partner Bob agrees to listen to the communications facility only on odd-numbered turns and Carol's partner Dave agrees to listen to the communications facility only on even-numbered turns, Bob and Dave can extract the original utterance.

In the encoding scheme listed in Figure 4-3, the single facility shared by Alice and Carol is effectively divided into two independent virtualized circuits or channels. Furthermore, in any given second, two samples of information are being communicatedAlice's during the first half-second and Carol's during the second half-second. When Alice and Carol have both taken a turn, the words they transmittedone from Alice and one from Carolare called a frame.

According to a theory called Nyquist's theorem, to accurately encode an analog audio signal into a digital system and then accurately resynthesize the analog version, the frequency with which you must sample the signal must be at least twice the highest frequency present in the original analog signal. The spoken voice's highest frequency is around 3500 cycles per second. Rounding to 4000 cycles per second for good measure (and friendly math) and then doubling the sample rate for digital encoding yields 8000 samples per second.

Chapter 1 introduced codecs, which are different encoding schemes for converting analog speech into digital information. One of these codecs, G.711, uses PCM encoding. For each sample in a block of 8000 samples, PCM converts the analog frequency to a value between 0 and 255in binary, this is an 8-bit number in the range 00000000 to 11111111. Therefore, one second's worth of encoded audio contains 64,000 bits of information.

The original T-carrier system was therefore designed around units of 64,000 bits per second. The base unit, called a DS0, has a rate of transmission sufficient to carry a single PCM-encoded audio stream in real time; other interfaces are named in ascending order and correspondingly carry multiple DS0s worth of traffic. Table 4-3 presents the T-carrier classifications.

Table 4-3. T-Carrier Rates

T-Carrier Class	Number of DS0s
T1	24 DS0s
T2	96 DS0s
T3	672 DS0s

T-carrier classifications align with the DS classifications, so a T1 is also called a DS1.

E-carrier classifications don't line up directly with the DS system. Table 4-4 presents the number of DS0s provided by the different E-carrier classifications.

Table 4-4. E-Carrier Rates

E-Carrier Class	Number of DS0s
E1	32
E2	128
E3	512
E4	2048
E5	16,384

To recap, one second of speech encoded as PCM requires 64,000 bits of data, and each DS0 provides a transmission rate of 64,000 bits per second. The higher grade the interface, the more active channels it supports. So why exactly can one trunk interface support more channels than another?

Well, when a digital interface is transmitting a bit of information, what is really happening is that the interface is changing the voltage level on the line. This voltage change is transmitted down the line at light speed and detectors on the other side are monitoring the voltage changes. It's like a message being transmitted via Morse code, in which dots represent one voltage level (or levels) and dashes represent another voltage level. The faster the voltage levels change, the more sophisticated the equipment needs to be in order to make sure that no bits are "skipped."

The need to avoid "skipping bits" has another effect on the transmission of digital information. More information than just the sampled voice data is transmitted across the pipe. As mentioned in Figure 4-3, Bob and Dave can recover Alice's and Carol's conversation by agreeing, respectively, to listen to the first and second channels within a given frame. But by peeking at the wire, how is Bob to know which is the first frame and which is the second frame?

Bob drives his decision as to which channels are which by looking at his watch. In a perfect world, Alice is putting her sample on the communications facility during the first half of every second and Bob should be pulling his off in the first half of every second. But if Bob's watch is just a smidgen fast or slow, pretty soon he'll be pulling samples off of the communications facility at the end, not the beginning, of every second.

Therefore, digital trunks always reserve some of the bandwidth to encode framing bits, whose purpose is specifically to synchronize the clocks of the transmitter and receiver.

Finally, given that control information such as call signaling, caller ID, and called number information can also be encoded as a series of bits, digital trunks usually have a way of encoding information in addition to the voice samples being communicated.

So, to summarize, over a digital trunk

Step 1.	Every 1/8000 of a second, Alice's, Carol's, and, on a T1, 22 of their friends' voices are sampled and encoded using PCM into an 8-bit number.
Step 2.	Each sample is interleaved on the wire at a specific moment in times, a process called TDM.
Step 3.	When all the samples have been transmitted, the system adds a framing bit, the purpose of which (among other things) is to eliminate clock slippage.

CAS Trunks

CAS is a digital protocol that can emulate loop-start, ground-start, or E&M trunks. In CAS signaling, call events are signaled directly in the same channels that the voice bearer data uses.

Figure 4-4 presents a sample T1 frame. T1 interfaces support 24 channels of information, each capable of carrying 8 bits of information at a time. Thus, each T1 frame can carry one 1/8000 second PCM sample for up to 24 speakers.

Figure 4-4. T1 Frame

Adding a framing bit yields the following:

8 x 24 + 1 = 193 bits per frame

In order not to "fall behind" the sampler, each second, a T1 must be able to serialize 8000 samples for 24 speakers. In other words, a T1 can serialize 8000 193-bit frames per second. This capacity amounts to 1,544,000 bits per second for a T1, which is more commonly written as a rate of 1.544 kbps.

CAS trunks group frames into yet larger groups called superframes. One framing strategy called Superframe (SF) formatting groups frames into groups of 12; a framing strategy called Extended Superframe (ESF) formatting groups frames into groups of 24.

Each frame in the superframe still has its framing bit. In SF formatting, this means that every superframe contains 12 bits of information that can be used to communicate information outside of the actual sampled audio, while in ESF formatting, every extended superframe contains 24 bits of information that can be used to communicate information outside of the sampled audio. At 8000 frames per second on T1, 666 SF superframes or 333 ESF superframes can be sent.

With 24 channels, signaling events might need to be communicated for any of 24 current calls. So CAS uses bits from the bearer channels to flag the system when a particular channel has a signaling event to communicate. Instead of using the eighth bit of any given sample to communicate actual audio information, the eighth bit of specific samples is used to communicate a signaling event.

In SF formatting, the low-order bits of each sample in the sixth frame is called the A bit, and the low-order bits of each sample in the twelfth frame is called the B bit. ESF formatting uses these bits as well as the low-order bits in the eighteenth frame (the C bit) and the low-order bits in the twenty-fourth frame (the D bit).

This robbed bit has little effect on an audio call. In any given 8-bit sample, the eighth bit is the least-significant bit. For example, if the 8-bit value 01010100 (decimal 40) were changed to 01010101 (decimal 41), the human ear would be unlikely to notice a difference. For circuit-switched data, however, even a difference of 1 bit could corrupt a file.

Therefore, when circuit-switched data is sent over T1 CAS interfaces, the eighth bit in a channel cannot be meaningfully used to carry information. As a result, T1-CAS supports at most a transfer rate of 56 kbps for circuit-switched data connections.

Table 4-5 presents the gateways/VICs that support CAS interfaces.

Table 4-5. Cisco Gateways That Offer CAS Interfaces

Gateway Model	Gateway Control Protocol
Cisco IOS Integrated Routers
Cisco 1800 series	H.323, MGCP, SIP
Cisco 2600 series	MGCP, H.323, SIP
Cisco 2800 series	MGCP, H.323, SIP
Cisco 3600 series	MGCP, H.323, SIP
Cisco 3700 series	MGCP, H.323, SIP
Cisco 3800 series	MGCP, H.323, SIP
Cisco 7200	H.323
Cisco 7500	H.323
Cisco AS5300	H.323
Cisco AS5350	H.323
Cisco AS5400	H.323
Cisco AS5850	H.323
Cisco Standalone Voice Gateways
Cisco Voice Gateway 200 (VG200)	MGCP, H.323, SIP
Cisco Access Digital Trunk Gateway DT-24+	MGCP
Cisco IAD2420	MGCP
Cisco Catalyst Voice Gateway Modules
Cisco Catalyst 4000 Access Gateway Module (WS-X4604-GWY)	MGCP, H.323, SIP
Cisco Catalyst 4224 Voice Gateway Switch	MGCP, H.323, SIP
Cisco Catalyst 6000 8-Port Voice T1/E1 and Services Module (WS-X6608-T1)	MGCP
Cisco Communication Media Module (WS-X6600-6T1)	MGCP

 

BRI and PRI Trunks

Both BRI and PRI are digital protocols based on the ITU-T specifications Q.921 and Q.931, which form the basis for the Integrated Services Digital Network (ISDN). ISDN is an end-to-end digital network capable of supporting voice and data connections.

Strictly speaking, this end-to-end connection is rarely provided solely via BRI and PRI. BRI and PRI are interfaces that the specifications implicitly assume operate only at the edge of a carrier network. In other words, BRI and PRI simply handle the last mile of connectivity from your service provider to your equipment. Q.931 defines two roles, network and user, to participants in a Q.931 signaling exchange, and service providers invariably take on the role of the network. The user and network roles effectively correspond to the roles of client and server.

However, in enterprise telephony deployments, ISDN connections are often used to connect premise equipment not only to the PSTN but also to other equipment owned by the enterprise. In such cases, the enterprise must denote one side of the interface as the user side and the other as the network side, although in practice the relationship between the switches is usually more peer to peer in nature.

For any digital protocol to be successful, it is mandatory that signals encoded by one end of a signaling link be transmitted reliably to the other end of the link. In ISDN, Q.921 fulfills this role.

Q.931 is the protocol that fulfills the requirements of both the signaling and media control phases of a call. That is, in a call from Alice to Bob, it answers the questions "Does Bob want to talk to Alice?" and "How should Bob talk to Alice?"

Unlike analog protocols, digital protocols foster the exchange of out-of-band information about a particular communication session. For example, in traditional analog caller ID, to get the identity of the caller to display on a residential phone, the information isn't sent directly within the FXO signaling itself, which is really only capable of managing off-hook and on-hook events. Rather, traditional caller ID is sent by the PSTN in between the first and the second rings of the phone using a modem signal. That is, caller ID-capable phones incorporate a special-purpose modem to decode the provided name and number and display it.

Inherently digital interfaces such as BRI and PRI don't need to go to such lengths. Rather, ISDN encodes information such as calling number, calling name, codec type, clearing causes, and tone information directly in the Q.931 signaling.

Figure 4-5 depicts the Q.931 signaling sent when a user (with directory number 1000) connected to a switch via an ISDN connection dials 2000, a number associated with another user connected via an ISDN to a different switch. (The protocol used to connect the switches to each other.)

Figure 4-5. ISDN Call

Unlike CAS, BRI and PRI use Common Channel Signaling (CCS). With CCS, one of the 24 channels (or, for E1-PRI, 32 channels) is reserved specifically for signaling.

Each ISDN span supports different combination of channels. D channels have a rate of 64 kbps (16 kbps for BRI) and carry the signaling required to set up calls (Q.921 and Q.931). B channels have a rate of 64 kbps and carry the actual circuit-switched voice or data.

BRI is designed for residential users and supports two B and one D channels. The flow depicted in Figure 4-5 is consistent with a BRI connection, because it demonstrates the caller's switch collecting dialed digits one at a time from the caller.

PRI, on the other hand, is enterprise oriented. It's less about connecting individual user devices to a network and more about connecting switches to each other. PRI comes in two main formats, T1 and E1.

In North America, PRI is deployed over T1 trunks and supports 23 B and 1 D channels; however, in Europe, PRI is deployed over E1 trunks and supports 30 B and 1 D channel (sometimes with a backup D channel).

Note

Using a technique called non-facility associated signaling (NFAS), multiple digital circuits can be grouped so that all share the D channel of one member of the group. This technique frees up the D channels of the trunks in the other groups for voice traffic. Cisco gateways support this technique when running H.323 or SIP, but CallManager does not yet support it for MGCP.

For the most part, BRI and PRI provide a signaling interface that is sufficient to handle basic calls. The Q.932 standard adds extensions that permit ISDN switches to provide PBX features to the digital phones they serve. However, although Q.932 permits an ISDN user to invoke features, Q.932 doesn't ensure that the feature operates transparently when the users involved in the feature are served by different switches. For instance, if Alice calls Bob, and Bob transfers Alice to Charlie, in many cases, Alice's display won't reflect that she is now talking with Charlie.

A PRI variant called QSIG provides a sophisticated infrastructure that allows features to interoperate transparently. CallManager supports the QSIG protocol both across MGCP gateways and from cluster to cluster using H.323 tunneling of QSIG. The section "QSIG" later in the chapter provides more details.

Table 4-6 lists the Cisco gateways that support PRI interfaces.

Table 4-6. Cisco Gateways That Offer BRI and PRI

Gateway Model	Gateway Control Protocol
Cisco IOS Integrated Routers
Cisco 1760	MGCP, H.323, SIP
Cisco 2600 series	MGCP, H.323, SIP
Cisco 2800 series	MGCP, H.323, SIP
Cisco 3600 series	MGCP, H.323, SIP
Cisco 3700 series	MGCP, H.323, SIP
Cisco 3800 series	MGCP, H.323, SIP
Cisco 7200	H.323
Cisco 7500	H.323
Cisco AS5300	H.323
Cisco AS5350	H.323
Cisco AS5400	H.323
Cisco AS5850	H.323
Cisco Standalone Voice Gateways
Cisco Voice Gateway 200 (VG200)	MGCP, H.323, SIP
Cisco Access Digital Trunk Gateway DE-30+	MGCP
Cisco Access Digital Trunk Gateway DT-24+	MGCP
Cisco Catalyst Voice Gateway Modules
Cisco Catalyst 4000 Access Gateway Module (WS-X4604-GWY)	MGCP, H.323, SIP
Cisco Catalyst 4224 Voice Gateway Switch	MGCP, H.323, SIP
Cisco Catalyst 6000 8-Port Voice T1/E1 and Services Module (WS-X6608-T1) (WS-X6608-E1)	MGCP
Cisco Communication Media Module (WS-X6600-6T1) (WS-X6600-6E1)	MGCP

 

ISDN Timers

Layer 3 timers permit CallManager to recover from errors in the Q.931 interface. This section describes the ISDN Q.931 timers that CallManager uses. In MGCP gateways, CallManager terminates the Layer 3 signaling; however, H.323 gateways terminate the Layer 3 signaling from the attached circuit-switched network, so these timers have no effect there. Instead, H.323 gateways use H.225 timers to achieve the same results, because H.323 emulates Q.931 messages over the H.225 protocol.

Table 4-7 shows the configurable timers that CallManager uses for gateway Layer 3 Q.931 processing. The table provides default values for each parameter, but parameters are user-configurable.

Table 4-7. Layer 3 Timers

Parameter	Default Time (in Seconds)	Timer Description
TimerT301	180	Starts when CallManager receives a ringing indication from a terminal (or network) to which it has offered a call; stops when it receives an answer indication.
TimerT302	10	Starts when CallManager receives a dialed digit (INFO) from a calling terminal; stops when CallManager has collected enough digits to route the call.
TimerT303	10	Starts when CallManager sends a call setup request (SETUP) to a terminal; stops when it receives any message in response (PROCEED, ALERTING, PROGRESS, CONNECT).
TimerT304	20	Starts when CallManager forwards digits from a caller to another network in an overlap dialing scenario (INFO); stops when CallManager receives an indication that the attached network has received enough digits to route (PROCEED).
TimerT305	30	Starts when CallManager initiates clearing to a terminal with DISCONNECT; stops when it receives a clearing acknowledgement (RELEASE).
TimerT306	30	Starts when CallManager initiates clearing to a terminal with a DISCONNECT containing a progress indicator; stops when it receives a clearing acknowledgement (RELEASE).
TimerT308	4	Starts when CallManager issues a release message to a terminal (RELEASE); stops when it receives a final clearing acknowledgement (RELEASE CONFIRM).
TimerT309	90	Starts when CallManager detects a problem with the data link; stops when the data link recovers.
TimerT310	20	Starts when CallManager receives an indication that an attached network can route the provided digits (PROCEED); stops when the called device rings or answers (ALERTING, PROGRESS, or CONNECT).
TimerT313	4	Starts when CallManager answers a call (CONNECT); stops when the interface acknowledges the connection (CONNECT ACK).
TimerT316	120	Starts when CallManager issues a RESTART on an ISDN facility; stops upon receiving an acknowledgement (RESTART ACK).
TimerT317	300	Starts when CallManager receives a RESTART; stops when associated interface has been purged.
TimerT321	30	Starts when CallManager detects a link issue; stops upon restoration of the link.
TimerT322	4	Starts when CallManager issues a STATUS ENQUIRY to discover the state of the connected channel; stops upon receipt of a response (STATUS).

 

QSIG

QSIG is an ISDN-based protocol that has its roots in standards originally defined by the European Computer Manufacturing Association (ECMA). ECMA submitted the drafts for QSIG to the International Standards Organization (ISO) for standardization.

QSIG defines a framework by which different vendor call agents (called a PINX [Private Integrated Services Network Exchange] in QSIG) can provide feature transparency among each other in a privately owned network (called a PISN [Private Integrated Services Network] in QSIG).

What is feature transparency? Basically, it comes down to the ability, from a feature point of view, to make multiple call agents appear as a single call agent. So if a transfer is performed on one PINX in the PISN, the newly connected party information shows up on the display of the transferred party, even if the transferred party is served by a different PINX in the PISN. Feature transparency also allows PINXs to remove hairpins from transferred and forwarded calls and to monitor the state of endpoints served by different PINXs in the PISN.

But QSIG isn't really just a collection of definitions of feature flows that vendors agree to adhere to for interoperability. Okay, it is that, but it's also a framework for providing the transparency.

Digital protocols such as PRI and BRI are based on Q.931. Although Q.931 is an excellent protocol for establishing basic calls, it isn't designed for end-to-end feature operation. Its purpose is the establishment of end-to-end connections.

Early versions of Q.931 did try to put actual support for features in the protocol. For instance, early versions of Q.931 supported a TRANSFER message, and Q.932 provides messages for HOLD and RETRIEVE and a method of passing feature button presses to the serving switch. But it quickly became clear that, although it was possible for vendors to agree on ways that basic calls should be processed, every vendor's feature set was quite different and quite extensive and having to revisit and extend the definition of the protocol that was simply designed to manage placing basic calls would ultimately be unworkable. For example, should Q.931 have implemented a CALLBACK message? A CALL PICKUP message? A GROUP CALL PICKUP message?

QSIG, therefore, although it defines a specific basic call message flow, is notable in that its basic call messaging provides for information to be passed in basic call messages that the protocol logic is meant to be specifically ignorant of.

QSIG relies on some of the same principles underlying the IP infrastructure that makes up the Internet. Figure 4-6 demonstrates a simple IP network.

Figure 4-6. Simplified IP Infrastructure

In the world of IP communications, the function of the network is to permit applications to talk to each other. To oversimplify dramatically, the world can be divided into applications and routers. Both applications and routers are assigned IP addresses, but the only IP addresses of consequence are the IP addresses associated with the applications. The router's IP addresses are simply the glue that connects application to application.

In the world of IP, applications must often communicate data across a long distance, perhaps as a part of a client/server relationship. The Internet works because it provides a framework by which the applications don't really care how that data gets from the client to the server and by which the routers don't care what data is actually communicated from end to end.

IP does this by providing a system for encapsulating opaque data. Application data is broken into chunks and then "stuffed" into "envelopes" on which the address of the terminating address is "written." When delivering a packet thus addressed, the routers simply look at the address on the packet without having to decode any of the information it contains. The packet contents are strictly for the applications themselves to understand.

The feature model in a QSIG network is very much like a client/server model for applications in an IP network. Before the creation of the QSIG feature framework, features were self-contained within a particular PBX. For instance, Figure 4-7 demonstrates a traditional call forward operation in a non-QSIG framework.

Figure 4-7. Forwarding in a Non-QSIG Network

In Figure 4-7, if Alice on PBX 1 were to call Bob on PBX 2 and Bob were to forward his call to Charlie on PBX 1, the feature operation would typically occur wholly within PBX 2PBX 2 would simply extend a new call back to PBX 1. PBX 1 would be unlikely to realize that Alice's outbound call had been forwarded, and it would be unlikely to realize that the inbound leg from PBX 2 to Charlie was actually the same call as Alice's outbound call.

Even though, before QSIG, PBX vendors needed to solve the problem of "How should Charlie's phone display that the call is from Alice and was originally to Bob?" these solutions typically involved adding vendor-specific fields to the Q.931 signaling. That is, features were transparent if all the vendor equipment was identical, but, when mixing equipment, phone displays didn't update after feature invocations. And, note that, even if the display information could be communicated from PBX 1 to PBX 2, the method of extending call legs in the forward direction to effect features means that the call signaling and (in a circuit-switched network) media hairpins. Thus two circuits are used in a call that ultimately would have required no circuits at all.

QSIG changes this feature model considerably. QSIG looks at the problem of communicating information between switches as the problem of communication information between actual applications that happen to be running on the call agent. For instance, in a message waiting scenario in which a voice mail system attached to one call agent needs to light a lamp on a phone connected to another call agent, QSIG wonders "What if there were a message waiting client feature on the switch that is hosting the voice mail whose job is, when asked by the voice mail system, to issue a message waiting application message to a message waiting server feature on another call agent, which, in turn, could actually light the lamp on the phone?" Figure 4-8 illustrates this model.

Figure 4-8. MWI in a QSIG Network

Figure 4-8 depicts a PISN of PBXs. It depicts two message waiting indicator (MWI) features, a client and a server. Although the picture illustrates these features as outside of the PBXs, in practice PBXs contain these features. When the message waiting feature client receives a lamp-on command from the voice mail system for extension 1212, it wants to communicate this command to the MWI feature "server" in the node in the PISN that actually controls extension 1212.

To accomplish this, the MWI client encodes the command to activate the message waiting indicator and then asks the call control componentthe part of the call processing software that handles basic call setup, typically using an ISDN protocol such as Q.931to wrap the MWI activation command in an envelope and deliver it to the PINX that serves extension 1212.

Then, using the same call routing logic that would operate when routing a basic call to the node controlling 1212, the call agent network layer routes the call containing the application payload. When the node controlling 1212 is reached, the Call Control Layer in that node detects that a payload exists (but not the full nature of the payload) and routes the payload to the MWI "server" within that node.

Hence, in a fundamental way, feature-to-feature communication in a QSIG network parallels client-to-server communication in an IP network. In both systems, an application wants to communicate information to another application. In both systems, the applications have network addressesIP addresses in the case of data networks, numeric directory numbers in the case of QSIG. In both systems, applications stuff their information into envelopes on which the network address of the peer application is written. And in both networks, the underlying network layer in each network looks at the destination address specified and routes the information independent of the payload. As in the data network depicted in Figure 4-6, the applications don't care how information gets from end to end, and the routers don't care what application information is in the envelope. In Figure 4-8, the PINXs hosting the MWI client and server don't really care how the information gets through the PISN, and the PINX in the middle doesn't really care what application information the message contains. While in an IP network there are many pure applications that don't perform routing functions, in QSIG the PINXs typically have both application and routing roles, although these roles can be thought of as distinct. Figure 4-9 shows an abstraction of a TCP packet and a QSIG "packet."

Figure 4-9. Comparison Between TCP and QSIG "Packets"

Although there's a philosophical similarity between IP networks and QSIG networks, there are also several significant differences. In an IP network, connection establishment is normally done as a completely independent step. After the connection has been established, peer applications can exchange information.

In QSIG, many features occur while the connection itself is being established. For instance, in a forwarded call, the recipient of the call wants to know the caller information and the original destination of the call while the call is being offered, not when the call is answered. As a result, application information is typically not present in an IP network on the messages that establish an end-to-end data connection (via TCP, for instance). In QSIG, however, application information, or application protocol data units (APDU), can be present on the Q.931 messages that establish (SETUP) and tear down (DISCONNECT) connections, as well as many that happen in between (ALERTING, CONNECT).

When QSIG needs to communicate information on an already existing connection, it uses a specially defined message called FACILITY, whose sole purpose is for the communication of application-to-application information.

In an IP network, the predominant models for application interactions are client/server or peer to peer. In QSIG, there tends to be at least one feature agent per participant in a feature interaction. So, while message waiting features are client/server, a call transfer relates a transferee, a transferor, and a transfer destination. Therefore, the QSIG flow involves communication between three agents, each of which represents one participant in a call.

In an IP network, most connections are purely data related.

In QSIG, most connections occur for the purpose of voice communications between the endpoints involved. For example, when a transfer completes, users have the expectation not only that they can see who they are talking to (the data information of the call) but also that they can converse over media channels reserved as part of call establishment.

Therefore, QSIG supports a few models for delivery of APDUs:

• Connectionless Sort of the QSIG analog to UDP, this method uses the FACILITY message to deliver information from one PINX to another PINX without actually establishing a connection. APDUs delivery is not guaranteed end to end. Almost no QSIG features use this type of delivery mechanism.
• Connection-oriented, call independent The method used by the MWI example earlierafter all, the voice mail system doesn't actually want to stream information to a listener. This method doesn't actually set up any media channels between the sending and receiving PINX. Rather, the connection that exists between the PINXs is signaling-only, and communication is over the D channel between the PINXs.
• Connection-oriented, call dependent The method used by the majority of PINX features, this method provides for delivery of both data relating to a call while setting up the media channels for the conversation.

QSIG Rerouting Features

Because QSIG relies on feature agents to accomplish feature operations, it permits a feature model that the traditional method of effecting features does not.

Figure 4-7 illustrated a traditional call forwarding scenario across an inter-PINX trunk. In the scenario, a call from a user on one PINX to a second user on another PINX that forwards to a third user on the first PINX causes a signaling and media hairpin.

With QSIG, it's possible for a feature agent on the redirecting node (either the transferor or forwarder) to instead of extending a new leg in the forward direction to ask the feature agent that represents the redirected call (either the transferee or forwarded caller) to place the call to the destination directly. This pattern of redirection allows the redirected call to be established according to the most efficient path. For some features, QSIG offers one variant that relies on redirection to remove hairpins and refresh phone displays and another variant that simply guarantees display refreshes but does not perform the more complex hairpin removal. For instance, the call forwarding rerouting variant removes circuit hairpins, but the call forwarding switch variant does not.

In a circuit-switched network, it minimizes the number of circuits that must be used to handle redirected calls. In a packet-switched network, media tends to flow directly from end to end. However, even VoIP call agents sometimes introduce devices that intercept and forward media (for example, MTPs, which Chapter 5 describes). QSIG features that use rerouting can eliminate redundant MTPs from the media path.

This rerouting pattern introduces routing complexity. For instance, in Figure 4-7, if Bob is used to dialing Charlie's number differently from the way Alice does, when Alice's PINX is asked to reroute the call, the call might misroute. Chapter 2 covers such routing scenarios in more detail.

QSIG and CallManager

CallManager supports the QSIG protocol (both the ISO and ECMA 2 variants) over gateways that run MGCP. In addition, CallManager supports QSIG between CallManager clusters using a technology called QSIG tunneling, which H.323 defines in Annex M1.

Table 4-8 lists the QSIG features that CallManager supports, the type of QSIG connections used (connectionless, connection-oriented call dependent, connection-oriented call independent), and whether the feature incorporates rerouting.

Table 4-8. Supported QSIG Features

Feature	Connection Type	Reroute?	Function
Path replacement	COCD	Yes	Eliminate signaling and media hairpins after a call forward (switch variant) or call transfer occurs.
Call transfer	COCD	No	Communicate new connected party information after a call transfer occurs.
Call forward (switch variant)	COCD	No	Communicate new connected party information after a call forward occurs.
Call forward (rerouting variant)	COCD	Yes	Effect a call forward by asking the originating PINX to place a call to the destination on behalf of the forwarded party. This feature only kicks in if CallManager determines that the destination party is on another node and if you enable the service parameter Forward By Reroute.
Message waiting indicator	CICD	No	Allows voice mail systems to deliver message waiting for indications to devices connected to different PINXs from the voice mail system. CallManager allows systems to activate or deactivate the message waiting indicator but not to query the existing setting (a feature called interrogation).
Call completion on busy Call completion on no reply	CICD and COCD	Yes	Allows a user on one PINX who receives a busy signal or no answer from a user on another PINX to monitor the status of the called user and get prompted to place a call to the called user when he or she becomes available.
Calling line presentation and restriction Calling name presentation and restriction Alerting name presentation and restriction Connected line presentation and restriction Connected name presentation and restriction	COCD	No	Present the name and number of the caller and ringing/connected party, while honoring privacy settings on the caller and called party.

Appendix C provides detailed information about the APDUs for each feature.