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
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
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
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
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. H.323 Call Models
This chapter doesn't discuss two other models -one 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
CallManager fits into the H.323 model as follows:
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.
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
At the end of this section, "RAS Messaging Details" provides a detailed
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 18.104.22.168. Gatekeepers in the network listening for such
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
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
Several other fields configured on the Trunk Configuration page in CallManager Administration come into play during registration:
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.
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
Like other CallManager devices, you assign device pools to H.323 trunk devices.
, which contain CallManager
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
After a given H.323 trunk instance has been given the opportunity to extend the call to the other cluster, a round-
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
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.
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
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
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
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
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
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# .
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 call -for instance, if a phone in one region places the call on hold, and a phone in a different region retrieves the call -CallManager 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 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
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
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
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
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
Upon receiving RELEASE COMPLETE, CallManager starts
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 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
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:
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
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 clipping -the 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.