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.

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 wires—E and M—are 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.

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:

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.

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).

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.

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 2—PBX 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 component—the part of the call processing software that handles basic call setup, typically using an ISDN protocol such as Q.931—to 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 addresses—IP 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:

H.323 endpoints use the Registration, Admission, and Status (RAS) protocol to interact with H.323 gatekeepers. RAS provides the following functions for endpoints:

The sections that follow describe each of these functions in more detail. Each section first describes the standards-supported methods and then describes how these standards are implemented in CallManager.

At the end of this section, “RAS Messaging Details” provides a detailed breakout of the RAS messages CallManager sends and receives.

Finding a Gatekeeper

Endpoints that need to be controlled via H.323 must first locate a gatekeeper with which to register. H.323 provides two methods by which H.323 endpoints can find a gatekeeper: manual discovery and automatic discovery.

In manual discovery, the H.323 is statically configured with the address of the gatekeeper that serves it.

In automatic discovery, an H.323 endpoint broadcasts the GRQ (Gatekeeper Request) message on multicast address 224.0.1.41. Gatekeepers in the network listening for such requests examine the specified address of the requestor (which can be either an alphanumeric alias or an E.164) and decide whether they want to serve the requesting endpoint. Gatekeepers that do want to be considered return a GCF (Gatekeeper Confirm) message; those that do not return a GRJ (Gatekeeper Reject) message or send no reply at all. Figure 4-13 depicts this procedure.

Figure 4-13. Automatic Gatekeeper Discovery

CallManager does not support automatic gatekeeper discovery. Instead, when you add a gatekeeper-controlled H.323 gateway or gatekeeper-controlled intercluster trunk, CallManager Administration allows you to specify the address of a primary gatekeeper that CallManager’s H.323 interface should register with.

Registering with a Gatekeeper

When a gatekeeper-controlled H.323 endpoint learns which gatekeepers are available to control it, it chooses to register with one of them.

To register, an H.323 endpoint issues an RRQ (Register Request) message, which the gatekeeper responds to with an RCF (Register Confirm) message if it wants to accept the registration and an RRJ (Register Reject) message if it wants to deny the registration. The RRQ contains information that the gatekeeper uses to authorize inbound and outbound calls to and from the endpoint. For instance, a registration contains the IP and port information that callers should use when they attempt to establish an H.225 session with the registering endpoint.

RAS is a protocol that operates over UDP. Unlike TCP, UDP does not establish and maintain connections. As a result, it is possible for an endpoint to register with a gatekeeper and then disappear from the network. The gatekeeper needs some way of knowing when this event occurs.

When you configure CallManager with the address of your gatekeeper, you specify a few values. One of these values is a gatekeeper refresh timeout, which defaults to 60 seconds (Registration Request Time To Live field on the Gatekeeper Configuration page). To keep the gatekeeper informed that CallManager is still operating, CallManager periodically sends a lightweight RRQ as a registration keepalive. If the H.323 gatekeeper doesn’t receive a periodic refresh of the registration, it expires the registration of the endpoint.

Several other fields configured on the Trunk Configuration page in CallManager Administration come into play during registration:

• Zone settings

• Technology prefix settings

• Device pool settings

Zones

The zone setting helps gatekeepers determine which H.323 endpoints they control. Cisco IOS gatekeepers only accept registrations for endpoints that register with zone information that the gatekeeper’s configuration has defined as local to it. If you are using a gatekeeper, you should assign each CallManager cluster in your enterprise its own unique zone.

Technology Prefix

The technology prefix is a routing-related setting that allows a gatekeeper to differentiate between groups of endpoints in the same zone. When an endpoint registers, it communicates both its zone information and its technology prefix, and the gatekeeper associates these values. The section “Admitting Calls” describes how zones and technology prefixes relate when a gatekeeper admits calls on to the network.

Device Pool

Like other CallManager devices, you assign device pools to H.323 trunk devices. Device pools, which contain CallManager group lists, normally control which CallManager nodes a physical device such as an IP phone attempt to connect to during registration. But CallManager’s H.323 trunks are built directly in to the software and therefore cannot possibly lose their connection to CallManager. What’s going on?

Like with physical IP devices, the CallManager list for H.323 trunks relates to redundancy. If, when you created an H.323 trunk, you created it only a single CallManager and statically associated it with either a gateway or a single CallManager in another cluster, calls between endpoints in your enterprise connected via the H.323 trunk will fail if a particular CallManager crashes. For example, in Figure 4-14, if either CallManager 1B or 2E fails, IP phones in cluster 1 cannot call IP phones in cluster 2.

Figure 4-14. Nonredundant H.323 Trunk

Therefore, when a CallManager cluster comes online, each CallManager starts one instance of the H.323 trunk on each configured H.323 trunk that includes the CallManager in its device pool. This behavior provides redundancy, but in a different way depending on whether the trunk is peer to peer or gatekeeper controlled.

When the trunk is peer to peer, in addition to configuring a device pool, you also configure a specific list of up to three IP addresses to which the H.323 trunk should connect. Because CallManager creates one H.323 trunk instance per CallManager in the CallManager list and the trunk is configured with up to three IP addresses to connect to in another cluster, this creates a 3×3 meshed connection between the clusters, as depicted in Figure 4-15.

Figure 4-15. Redundant Peer-to-Peer H.323 Trunk

When a user in one cluster calls a user in the other cluster over a peer-to-peer H.323 trunk, two load-sharing strategies occur.

The first load-sharing algorithm relates to which internal trunk device the CallManager cluster selects for placing the outbound call to the other cluster.

When CallManager attempts to place a call on behalf of a user, CallManager may create the call on any node in the cluster (although it typically creates the call on the same node as the caller). If CallManager detects that an H.323 trunk to the caller’s destination trunk exists on the same node as the call, CallManager uses that local instance. If no such local instance exists, CallManager chooses randomly from the H.323 trunk instances selected by the call. Assuming callers are evenly distributed around the active nodes in a cluster, this strategy can provide an even load across the H.323 trunk instances that the CallManager nodes create.

After a given H.323 trunk instance has been given the opportunity to extend the call to the other cluster, a round-robin approach takes over. For each subsequent call, the H.323 trunk instance selects the next IP address in its list of remote CallManager nodes. This process tends to spread out the burden of incoming peer-to-peer H.323 calls. It’s important that H.323 trunks in the receiving cluster be configured on the appropriate CallManagers to ensure the outbound call is accepted.

When an H.323 trunk is configured as gatekeeper controlled, the device pool provides a similar load-sharing mechanism via a different method.

When, in a given CallManager, an H.323 gatekeeper-controlled trunk comes online, it looks to see whether the other H.323 trunks in its device list have come online. When registering with the H.323 gatekeeper, CallManager specifies each other online H.323 trunk in its device pool as an alternate endpoint.

When resolving a dialed address, the H.323 gatekeeper, instead of specifying just a single H.323 call signaling address in the admission response, specifies all addresses sent in the original registration, including the alternate endpoints. In conjunction with the load-sharing mechanism whereby CallManager selects either a local or a random outbound trunk, this allows an H.323 trunk to attempt to route a call to alternate destinations if the attempt to contact the primary CallManager fails.

With gatekeeper-controlled H.323 trunks, the gatekeeper is also a component that is subject to failure. Therefore, just as endpoints can specify alternate endpoints when registering (via RRQ), when an endpoint registers, an H.323 gatekeeper can specify alternate gatekeepers when accepting a registration (via RCF). If, when an H.323 trunk attempts to place an outbound call, it cannot contact its gatekeeper, it can contact one of the alternate gatekeepers provided on the original registration.

When confirming the registration and providing a list of such alternate gatekeepers, the H.323 gatekeeper can specify the requiresRegistration field. When this field is set, an H.323 trunk issuing a call must actually register with one of the alternate gatekeepers before asking the alternate gatekeeper to admit the call.

Admitting Calls

When a gatekeeper-enabled endpoint wants to place or receive a call, it first asks for permission from the gatekeeper via the ARQ (Admissions Request) message. Although the ARQ includes information about the calling party and the called party, this information is only indirectly related to the actual call establishment. Rather, the sending of the ARQ is primarily related to policy enforcement.

When deploying an H.323 gatekeeper with CallManager, admissions requests hinge primarily on two factors. First, H.323 gatekeepers permit you to configure a multiple-cluster route plan in a centralized place. Without a gatekeeper, if your deployment exceeds two clusters, configuring a route plan to route calls in between clusters requires quite a bit of redundant configuration, because you must manually provision routes from cluster to cluster.

Figure 4-16 demonstrates the redundancy when you use the peer-to-peer model in a network requiring three or more clusters. In this figure, directory numbers are scattered around the enterprise with no use of number blocks to help algorithmically route the call. As a result, when a directory number is added to one cluster, specific routes must be provisioned in the other two clusters to route the call. Although it’s certainly possible to manage such a deployment, the configuration isn’t ideal.

Figure 4-16. Redundant Routing Information in a Multiple-Cluster Peer-to-Peer H.323 Network

If you use a gatekeeper-routed model instead, you can configure routing so that all calls that a given cluster doesn’t know how to route locally query the gatekeeper, which has a centralized configuration containing all routable addresses for the enterprise. This configuration scales much better because instead of having to configure a given address once in CallManager and once each in every other CallManager cluster, you just need to configure the address twice, no matter how many clusters you have. Figure 4-17 demonstrates this technique.

Figure 4-17. Routing Information in a Multiple-Cluster Gatekeeper-Controlled H.323 Network

As the section “Registering with a Gatekeeper” mentioned, zones also allow H.323 gatekeepers to set up policies related to endpoints grouped in a zone.

In particular, with IOS gateways, you can associate a certain amount of bandwidth that is available for calls to and from the zone. When you use gatekeeper-based call admission control, the gatekeeper tracks all gatekeeper-assisted H.323 calls and deducts a codec-based amount of bandwidth for each call placed between zones. When the bandwidth is exhausted, the gatekeeper permits no calls into or out of the depleted zone until one of the calls in the zone releases.

When an endpoint places a call, it provides the dialed address to the gatekeeper. The Cisco IOS gatekeeper compares these digits to the DN ranges assigned to each zone. For instance, assume cluster A manages directory number range 40000 to 49999, and cluster B manages directory number range 50000 to 59999. The following gatekeeper configuration allows the gatekeeper to understand the different numbering ranges:

       zone local cluster-A cisco.com
       zone prefix cluster-A 4....
       zone local cluster-B cisco.com
       zone prefix cluster-B 5....

If a caller dials 45555, CallManager’s gatekeeper-controlled H.323 trunk provides these digits to the gatekeeper. By comparing the dialed digits to the zone prefixes, the gatekeeper identifies the dialed address as being related to cluster A.

Upon identifying the zone, the Cisco gatekeeper looks for specifically registered endpoints in that zone. For instance, one could deploy a bunch of non-CallManager-controlled H.323 endpoints that specifically register their addresses with the Cisco gatekeeper.

When CallManager registers with a gatekeeper, it provides its zone information, but it does not provide any information related to specific endpoints; that is, CallManager does not register specific contacts for its SCCP phones, MGCP and H.323 gateways, route patterns, translation patterns, and so on. Instead, CallManager relies on a feature of the Cisco gatekeeper called the default technology prefix.

Normally, if the gatekeeper locates no specific registered contact, it rejects the call. But if you configure a default technology prefix with

       gw-type-prefix 1# default-technology

then when no specific match is found, the Cisco gatekeeper looks for endpoints that have registered with the specified technology prefix (in this case, 1#) and chooses one of these endpoints to route the call to. In the example, the dialed digits 45555 would first bind to zone cluster A, then the gatekeeper would find no specifically registered alias, the gatekeeper would find its default technology prefix of 1#, and then the gatekeeper would offer the call to the H.323 trunks that registered in the cluster A zone with technology prefix 1#.

As a result, for intercluster routing, you’d configure the zone of cluster A’s H.323 trunks as cluster-A and its technology prefix as 1# and the zone of cluster B’s H.323 trunks as cluster-B and its technology prefix as 1#.

When users conversing over an admitted call finish their conversation, each H.323 endpoint notifies the gatekeeper of call termination via the DRQ (Disengage Request) message, which the gatekeeper accepts by sending a DCF (Disengage Confirm) message (and rejects by sending a DRJ [Disengage Reject] message, although it’s hard to conceive of a case in which a gatekeeper would do this in practice).

H.225 is the protocol used in H.323 to actually offer a call to a destination. Unlike RAS, which is always supported over UDP, H.225 can run over UDP or TCP. CallManager supports H.225 over TCP but not UDP.

The default port for H.225 call signaling is well-known port 1720, although CallManager allows you to configure this per each H.323 device.

If multiple H.323 devices are configured with the same port, it would seem logical that CallManager could not reconcile messages from different H.323 endpoints. However, when accepting inbound H.225 messages from a given IP address, CallManager examines the source IP address to determine to which inbound trunk the message is inbound. CallManager delivers the inbound H.225 message to the H.323 trunk you’ve configured that specifies the sender’s IP address as its peer. However, this limitation does prevent you from specifying two different peer-to-peer H.323 trunks to the same IP address, which you might want to do if you want to take advantage of trunk-level policy settings such as calling search space or CallManager locations.

CallManager gatekeeper-controlled H.323 trunks act differently. When CallManager instantiates these trunks, it dynamically selects a port for receiving inbound messages and, when registering the trunk with the gatekeeper, provides the gatekeeper with this trunk value. As a result, with gatekeeper-controlled trunks, you can set up multiple H.323 trunks to apply different CallManager policy settings for different inbound calls. Similarly, when CallManager attempts to have a call admitted on to the network, one of the values that the gatekeeper specifies in the ACF message is the IP address and port to which CallManager should send the outbound call offering message.

When using gatekeeper-controlled trunks, you can specify one H.323 trunk that listens on port 1720. The service parameter Device Name of GK-controlled Trunk That Will Use Port 1720 enables you to specify the name of the gatekeeper-controlled H.323 trunk that listens on the well-known port. This can guarantee that H.323 endpoints on the other side of firewalls can still communicate with CallManager, because using dynamic ports might require that a firewall administrator unsecure more ports than are needed for processing H.323 calls.

Figure 4-18 presents the steps involved in call establishment via RAS and H.225.

Figure 4-18. H.225 Call Establishment

In Figure 4-18, a non-H.323 caller composes the address of a called party and provides the information to CallManager, whose routing tables indicate that the call should be offered out an H.323 trunk.

If the trunk is gatekeeper-enabled, CallManager first asks for permission from the gatekeeper to place the call. The gatekeeper examines the dialed address (possibly transformed by CallManager), possibly checks to see whether there is enough bandwidth to admit the call based on the caller’s specified codec, and then admits the call, providing CallManager the IP address and port to which it must issue the call request.

After the gatekeeper (if one exists) grants permission, CallManager issues a call setup request to the selected gateway on the appropriate IP address and port. In some cases, this setup includes information about the media addresses of the caller, a process called fast start. H.245 describes the media processes related to fast start more extensively.

If the receiving H.323 gateway or CallManager is gatekeeper-controlled, it also queries the gatekeeper, this time to ask permission to receive a call. If such permission is granted, the receiving H.323 endpoint can present the caller to the called user. In the case of the trunk devices this chapter describes, the gateway is likely to issue a call setup request of its own to the connected network.

Assuming the receiving endpoint considers the address complete, it notifies CallManager with a PROCEED message. In many cases, this first backward message contains information about the receiving endpoint’s media information to enable CallManager to begin setting up media channels for conversation. This approach, called early media, helps ensure that after the called party answers none of her speech is dropped or “clipped” because no end-to-end media path has yet been established.

When the terminating network offers the call to the called party, it sends some sort of alerting indication (which varies according to the nature of the terminating network) to the receiving endpoint, which sends an H.225 ALERTING message to CallManager. This message allows CallManager to instruct the related gateway to provide ringback to the caller.

When the called party answers, the terminating network sends some sort of answer indication (which varies according to the nature of the terminating network) to the receiving gateway, which sends an H.225 CONNECT message. If media is not yet established between the caller and called party, the CONNECT message causes CallManager to issue the H.245 control messages needed to establish media.

After all media information has been exchanged, the two parties can converse. When one hangs up—in this case, the called party—the receiving gateway receives disconnection information, and issues an H.225 RELEASE COMPLETE message to CallManager. If the receiving endpoint and CallManager are gatekeeper-controlled, they issue DRQ messages to the gatekeeper to notify it of call termination.

Upon receiving RELEASE COMPLETE, CallManager starts tearing down the media channels between caller and called party, and the call concludes.

H.245 is the protocol used in H.323 to allow endpoints to coordinate their media.

Originally, in H.323, H.225 controlled just the actual mechanics of call offer and answer, and then H.245 took over to permit the exchange of media information. This approach sometimes led to clipped speech, so a procedure called fast start was defined.

Before learning about fast start, you need to understand the purer H.245 flows.

Like H.225, H.245 signaling occurs over a TCP session. Four major types of events occur over an H.245 session:

One of the functions of RAS in the gatekeeper-controlled model was to provide to the calling H.323 endpoint the IP address and port with which it should attempt to establish the H.225 session (TCP or UDP).

Similarly, one of the functions of the H.225 session is to provide the endpoints, both calling and called, with the IP address and port to which the H.245 session (TCP) should be established. In H.225, the caller generally provides the address to which the called party should send H.245 control messages on the SETUP message; the called party provides the address to which the calling party should send H.245 control messages on one of the following backward messages:

In the backward direction, the earlier this information is communicated, the earlier the end-to-end media connection can be established.

Finally, one of the functions of the H.245 session is to provide the endpoints with the IP address and port to which the actual encoded media should be sent (Real-Time Transport Protocol [RTP] headers, wrapped in UDP packets).

Because CallManager wants to be involved in the signaling session and the media control session but not the exchange of media, CallManager constructs the messages so that the signaling and media transport addresses point to it but the actual media addresses are those of the endpoints. Figure 4-19 demonstrates this progression.

Figure 4-19. Progressive Establishment of Call Sessions

Figure 4-20 illustrates a full H.245 message exchange between two H.323 endpoints.

Figure 4-20. H.245 Message Exchange

Use of H.245 to Provide Features

Because H.323 decouples the media control signaling from the call signaling, it provides a way for endpoints to change bandwidth mid-call, to add new channels of information to an existing call (such as video or application collaboration), or to renegotiate codecs mid-call.

The ITU specification H.450 defines a framework by which H.323 endpoints can provide call-related features such as transfer, call completion, call forwarding, and others. CallManager does not support this standard. Nevertheless, H.323 endpoints can participate in features in three ways:

• CallManager supports the carriage of hookflash and dialed digits through the H.245 userInfoIndication field. This allows H.323 endpoints to interact with IVRs, voice mail systems, and so on.

• Many CallManager features operate solely through the use of established calls. Although an H.323 endpoint cannot park a call, because the version of H.323 CallManager supports does not give CallManager a way to detect that the H.323 endpoint wants to invoke a feature, an H.323 endpoint can retrieve a parked call, because this operation requires only that an endpoint be able to offer a call containing the address of the park code.

• H.323 endpoints can passively participate in features invoked via Cisco IP Phones via support for mid-call renegotiation of capabilities. H.323 requires that endpoints suspend sending media when they receive a mid-call request to select a new codec from an empty list of codecs. This capability is termed empty capability set support. What it means is that although an H.323 endpoint doesn’t have a way to initiate a transfer or hold or other mid-call feature, if an IP phone that the H.323 gateway is talking with initiates such a feature, the gateway’s media stream can be temporarily suspended while CallManager acts on the IP phone’s feature request. CallManager uses this capability to effect features such as hold and transfer.

Figure 4-21 demonstrates how CallManager uses the empty capability set to effect a call park and call park retrieval.

Figure 4-21. H.245 Feature-Related Message Exchange

In Figure 4-21, 2000 parks a call from an H.323 gateway. CallManager tells the gateway that 2000 supports no codecs, which the gateway interprets as a requirement to suspend sending media to 2000. (As part of the park operation, CallManager also tells 1000 to cease sending media to the gateway.)

When 1000 dials the park code to retrieve the call, CallManager begins another H.245 media control session with the gateway. The H.323 gateway and 1000 exchange codecs via CallManager and, as part of the coordination of the media streams, CallManager provides the gateway the IP address and port to which it should send media and vice versa.

Not all H.323 endpoints support the receipt of empty capability sets. When configuring CallManager to support one of these gateways, you must configure the H.323 trunk to use a media termination point (MTP). The MTP is a device that CallManager can insert into a call to insulate endpoints from incompatibilities between each other’s media control processing, to provide dual-tone multifrequency (DTMF) relay, and to provide call progress tones. Chapter 5 goes into more details about MTPs.

In SIP, the hold and resume features are media-level events. An endpoint that initiates a hold request asks the far end to suspend streaming media to it while suspending streaming media to the far end, and an endpoint that initiates a resume request asks the far end to resume streaming media.

SIP carries the media characteristics of the session in the body section of SIP messages, encoded in SDP. On an established session, a SIP UA that wants to initiate hold issues a new INVITE containing the dialog identifier for the existing session. The method of issuing a new INVITE on an existing session is termed a reINVITE. This reINVITE specifies one of three values in the SDP:

The resume operation is a nearly identical operation, except that instead of changing the mode to inactive or sendOnly or zeroing out the IP address, the retrieving UA restores the original media information.

MTPs enable UAs to invoke hold and retrieve. (The MTP also insulates SIP UAs from hold and retrieve operations from Cisco SCCP IP Phones.) When processing hold from a SIP UA, CallManager suspends only the SIP UA-to-MTP stream while retaining the media stream between the held party and the MTP. CallManager does not introduce music on hold in these situations.

SIP UAs can provide call forwarding functionality via the 3xx series of provisional responses. When receiving an INVITE, if a SIP UA wants to divert the call, it can send a “302 Moved Temporarily” message. The originating UA is expected to issue INVITEs to the destination or destinations specified in the response.

CallManager’s SIP trunk supports 302 and other 3xx messages. However, the processing for these messages occurs solely at the trunk itself—CallManager does not compare the redirection target against any provisioned phones, translation patterns, or route patterns. Instead, the SIP trunk consults DNS and issues the INVITE to the resulting IP address.

For a fairly long, awkward feature name, this set of features is really quite straightforward. It’s nothing more or less than caller ID and connected ID and your ability to decide whether the caller or called party gets to see the name, the number, neither, or both.

Calling and connected name describe the presentation of the name of the appropriate party, and calling and connected line relate to the phone number of the appropriate party.

SIP uses addresses in the form of user@domain, but just as in e-mail, the headers that contain this information provide you with the ability to indicate a display name. Therefore, if Alice is calling from 1000 in the cisco.com domain, the From: header of a SIP method might look like this:

       From: "Alice" <[email protected]>

SIP addresses can occur in any number of SIP header fields, but for line and name ID services with CallManager, only three are relevant:

As Chapter 2 describes, call restriction settings exist on route patterns, translation patterns, and the device pages. The accepted values of these presentation fields are Allowed, Restricted, and Default. If the gateway setting is Allowed or Restricted, this value takes precedence. If set to Default, the gateway level uses the setting on the route or translation pattern. (If the value on the route or translation pattern is also Default, the resulting value is whatever the caller provided.)

When encoding a line number in for caller or connected ID purposes, CallManager places the number in the user portion of the user@domain URI. CallManager encodes name information in the accompanying text description section.

The Remote-Party-Id header provides URI tags that allow a UA to indicate whether the name or number privacy should be honored. When the name is restricted but not the number, CallManager sets the privacy tag to name; when the number is restricted but not the name, CallManager sets the privacy tag to uri; and when both are restricted, CallManager sets the privacy tag to full.

Because the From: header permits no such tags, when the name is restricted, CallManager encodes it as “Anonymous”, and, when the number is restricted, CallManager doesn’t encode a user part at all.

Table 4-12 illustrates the possible encoding values from the From: and Remote-Party-Id headers.