H.323 Gateways

The H.323 recommendation from the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) is an umbrella specification that defines how terminals, gateways, and gatekeepers provide communication services over packet-based networks. The specification is called an umbrella specification because it references other specifications for the call control, media control, and media coding and decoding specifications.

The protocols of interest in this chapter are as follows:

• RAS
• H.225
• H.245
• Audio codecs G.711, G.722, G.723, G.728, G.729a, and GSM
• Video codecs H.261, H.263, and H.264

The call signaling phase of an H.323 call uses RAS and H.225. The function of the call signaling phase is to coordinate the offering and answering of a call between two parties. In addition to its functions related to call signaling, RAS provides messages to allow H.323 endpoints to associate themselves with network elements that can help with call routing and call admission control (which can prevent VoIP calls from overutilizing network bandwidth and degrading the voice quality of all calls). H.225 handles the basic call setup and teardown.

The media control phase of an H.323 call uses H.245. The function of the media control phase is to provide the endpoints with the information they need to send and receive properly encoded media streams to and from each other.

The media exchange phase of an H.323 call allows the speakers on either end of a call to exchange information. G.711, G.723, G.729a, and GSM are codecs that encode audio information, while H.263 allows an endpoint to encode and decode video information.

CallManager and the H.323 Control Model

H.323 defines several network elements and several models for controlling calls. The most important of the network elements are endpoints and gatekeepers.

H.323 endpoints are the entities that place and receive calls, and the protocols are therefore designed for the establishment of sessions in between these endpoints. However, endpoints need not necessarily be user devices, but instead can serve as gateways from one type of network to another or even as just a protocol suite to another protocol suite.

H.323 gatekeepers are centralized points that fulfill an administrative role. They can aggregate endpoint registrations, provide a centralized call routing function for endpoints, and manage network resources to ensure that network bandwidth is not oversubscribed.

Figure 4-10 demonstrates three main control models for H.323 calls.

Figure 4-10. H.323 Call Models

Note

This chapter doesn't discuss two other modelsone in which a direct-mode gatekeeper handles RAS but routes media through a proxy, and one in which the gatekeeper routes H.225, H.245, and the media through a proxy. Neither of these are common CallManager deployment models.

The peer-to-peer model includes no gatekeeper at all. Endpoints communicate directly with each other, first via H.225 to coordinate the establishment of a call and then with H.245 to establish the media flow between the two endpoints. The other models include a gatekeeper. Using a gatekeeper necessitates the use of RAS, which permits endpoints to locate gatekeepers to serve them, register with those gatekeepers, and, when calls are placed, to ask for permission to admit calls into the network. In the direct signaling model, endpoints communicate with the gatekeeper using only RAS for call admissions and, when it admits calls, the gatekeeper provides enough information to the endpoints for them to negotiate H.225 call signaling and H.245 media control signaling with each other. In the gatekeeper-routed call, endpoints communicate not only RAS but also H.225 and H.245 signaling to the gatekeeper. Certain gatekeepers may also route the actual media flow through themselves by controlling the H.245 addresses.

CallManager fits into the H.323 model as follows:

• CallManager acts as an H.323 endpoint As previously mentioned, H.323 endpoints need not simply be user devices. Cisco IOS H.323 gateways, for instance, operate using VoIP protocols on their network interfaces and translate this signaling to activity on a circuit. Similarly, CallManager acts as an IP-to-IP call signaling and media control gateway to permit H.323 devices to communicate with non-H.323 devices such as SCCP endpoints. (Unlike Cisco IOS H.323 gateways, however, CallManager doesn't terminate the media path.) Figure 4-11 shows the similar roles that Cisco IOS H.323 gateways and CallManager have.

  Figure 4-11. CallManager's Role as H.323 Endpoint

   

  In H.323, in many respects, H.323 endpoints are completely autonomous entities. For example, if one endpoint in a call is supporting a variety of circuit-switched interfaces, the other endpoint doesn't see those interfaces. To it, the other endpoint acts as a black box.

  From a configuration standpoint, this means that H.323 endpoints that act as gateways are call agents in their own right. In practice, this means that if you deploy Cisco IOS H.323 or other H.323 gateways, you must often configure call routing settings directly on both CallManager and the H.323 gateways that connect to it.

• CallManager acts according to the peer-to-peer and direct signaling models In H.323, endpoints either signal each other directly or, via an H.323 gatekeeper, indirectly. Using CallManager Administration, you can configure static associations between CallManager H.323 trunks and other CallManagers and H.323 gatewaysthe peer-to-peer modelor you can configure CallManager H.323 trunks to allow a gatekeeper to provide routing and call admission control via RASthe direct signaling model.

  When the other end of an H.323 trunk is CallManager or a set of CallManagers, the connection is given the special term intercluster trunk. But, in fact, except for a few wrinkles in the media negotiation when CallManagers are connected via H.323 trunk, CallManager relates to other CallManagers as if they were H.323 gateways. (In the peer-to-peer model, you provision CallManager-to-CallManager trunks explicitly, so CallManager adjusts for the slightly different media signaling. In the gatekeeper models, CallManager automatically detects whether the other side is a CallManager and adjusts its signaling accordingly.)

  One other distinction between intercluster trunks and IP trunks to gateways is that CallManager supports H.323 Annex M, which permits the tunneling of the QSIG protocol over H.323 connections. CallManager uses QSIG tunneling to provide better feature transparency between clusters. The subsection "QSIG" goes into more detail about QSIG.

  Figure 4-11 and Figure 4-12 show CallManager using the peer-to-peer and direct signaling models to access both H.323 gateways and other CallManagers.

  Figure 4-12. CallManager's Support for H.323 Call Models

  

H.323 Call Signaling Details

This section goes into more detail about the actual signaling exchanges that occur in RAS, H.225, and H.245, and describes the ways in which CallManager uses these protocols.

RAS

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

• Gatekeeper location, provided via the GRQ, GCF, and GRJ messages
• Endpoint registration and KeepAlive, provided via the IRQ, IRR, RAI, RAC, RRQ, RCF, RRJ, URQ, UCF, and URJ messages
• Call routing, call admissions, and call clearing, provided with the ARQ, ACF, ARJ, DRQ, DCF, DRJ, LRQ, and LCF messages
• Mid-call bandwidth adjustments, provided via the BRQ, BCF, and BRJ messages

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

Changing Bandwidth Mid-Call

When configuring a gatekeeper with zone information, you can specify a maximum amount of bandwidth available for calls to and from that zone. When an H.323 endpoint asks the gatekeeper to admit the call to the network, it provides an amount of bandwidth that it wants the gatekeeper to grant. If the zone has been provisioned with a bandwidth limit, the gatekeeper compares the highest-bandwidth codec in the list of capabilities against the bandwidth available for the zone. If enough bandwidth is available, the gatekeeper admits the call.

Sometimes during a call, the codecs used by endpoints in a conversation can change. RAS includes the BRQ (Bandwidth Request) message to handle this event. If the gatekeeper wants to approve the bandwidth request, it issues a BCF (Bandwidth Confirm) message; if not, it returns a BRJ (Bandwidth Reject) message. If the bandwidth request is not granted, CallManager clears the affected call.

If the required bandwidth for an H.323 call changes during the callfor instance, if a phone in one region places the call on hold, and a phone in a different region retrieves the callCallManager notifies the gatekeeper of the new information so that the gatekeeper can properly track the amount of network bandwidth available. Because an attempt to change bandwidth might get rejected and cause calls to drop, you must specifically enable bandwidth adjustment using CallManager service parameters.

Gatekeepers can also request that endpoints adjust bandwidth. If CallManager receives a BRQ, it responds with a BRJ.

RAS Messaging Details

The RAS message support provided by CallManager is the H.225 version 2 protocol. Refer to Appendix C for detailed information about specific fields in H.225 RAS messages.

H.225

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 upin this case, the called partythe 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.225 Messaging Details

The call signaling protocol that is supported in the H.323 protocol umbrella is H.225. H.225 includes the call signaling messages and the RAS messages. This section covers the specific details of the call signaling messages.

H.225 messages follow the ITU-T Q.931. In H.225, the user-user information element (UUIE) conveys the H.225-related information. The H.323 user information protocol data unit (PDU) is ASN.1-encoded. The ASN.1 is encoded using the basic aligned variant of the packed encoding rules as specified in X.691. The ASN.1 structure begins with H323-UserInformation.

Tables in Appendix C list each H.225 message and provide the specific fields of the H.225 call signaling messages that CallManager exchanges with an H.323 gateway or CallManager H.323 trunk (GW in table). See Appendix C for more information.

H.245

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:

• Determination of which side of the H.245 is the master and which is the slave This assignment of roles allows the protocol to deal with glare conditions within the protocol and doesn't directly relate to the media session itself.
• Exchange of capabilities This event permits the endpoints in the conversation to choose a media encoding method that they can be confident that the other side supports. Although CallManager can be configured to insert special devices called "transcoders" (discussed in Chapter 5) into a conversation between two parties that don't otherwise share a common codec, direct end-to-end media streams are preferable.
• Exchange of streaming IP address and port This event tells the endpoints where to send their encoded media stream.
• Mid-call button presses for interaction with connected services Connected services include services such as voice mail and interactive voice response (IVR) units.

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:

• PROCEED
• ALERTING
• CONNECT (or PROGRESS)

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.

H.245 Fast Connect

One charge levied against H.323 is that it can cause clippingthe loss of the first few seconds of a voice conversation (often the important first words "Hello?") because media negotiation occurs in a completely separate phase from the actual call establishment.

With the use of fast connect (also called fast start), H.323 allows endpoints to embed information about the IP address, port, and codecs that they want to use for a particular conversation in the H.225 messages actually used to place the call. CallManager can respond to and forward fast start requests that it receives.

Fast start can speed the establishment of a conversation and avoid clipping. However, because mid-call feature invocations don't generate H.225 events, the full H.245 media renegotiation of necessity must occur. As a result, although the media channels related to initial call setup can occur quickly, media resumption can sometimes take longer when calls are transferred, retrieved from hold, retrieved from park, or the calls are the subject of other mid-call features. Normally, this isn't an issue. When receiving calls, users are conditioned to immediately answer with a "Hello," but users generally have fewer ingrained expectations when a mid-call feature is invoked.