H.323 Trunk Overview ccie bootcamp training in delhi gurgaon india

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

As illustrated in Figure 3-2, CUCM supports several different types of H.323 trunks. CUCM
cluster A uses a nongatekeeper-controlled intercluster trunk (ICT) to CUCM cluster B. In
addition, CUCM cluster A is configured with a gatekeeper-controlled intercluster trunk.
The gatekeeper-controlled intercluster trunk points to a gatekeeper, which is used for
address resolution. A gatekeeper is an optional H.323 component implemented on a Cisco
IOS router that allows centralized call processing and optionally call admission control
(CAC). In this example, the gatekeeper can route calls between all phones controlled by
CUCM clusters A, C, and D.
H.323 Trunk Overview 57
Figure 3-2 H.323 Trunk Overview
Non-Gatekeeper-Controlled ICT
H.323 Trunk Comparison
Table 3-1 compares characteristics of the three available H.323 trunk types in CUCM.
Table 3-1 H.323 Trunk Comparison
Nongatekeeper-
Controlled ICT
Gatekeeper-
Controlled ICT H.225 Trunk
IP Address
Resolution
IP address specified in
trunk configuration
IP address resolved by H.323 RAS (gatekeeper)
Gatekeeper Call
Admission
No Yes, by H.323 RAS (gatekeeper)
Scalability Limited Scalable
Peer CUCM Before Cisco
CallManager 3.2
Cisco CallManager
3.2 or higher and all
other H.323 devices
58 Chapter 3: Implementing Multisite Connections
The nongatekeeper-controlled intercluster trunk is the simplest, because it does not use a
gatekeeper. It requires the IP address of the remote CUCM server or servers to be specified,
because the dialed number is not resolved to an IP address by a gatekeeper. CAC can be
implemented by locations but not by gatekeeper CAC. Scalability is limited because no
address resolution is used and all IP addresses have to be configured manually. The nongatekeeper-
controlled intercluster trunk points to the CUCM server or servers of the other
cluster.
You may define up to three remote CUCM servers in the same destination cluster. The trunk
automatically load-balances across all defined remote CUCM servers. In the remote cluster,
it is important to configure a corresponding intercluster trunk (nongatekeeper-controlled)
that has a CUCM group containing the same servers that were defined as remote CUCM
servers in the first cluster. A similar configuration is required in each CUCM cluster that is
connected by the intercluster trunks.
The gatekeeper-controlled intercluster trunk should be used instead of the nongatekeepercontrolled
trunk for a larger number of clusters. The advantages of using the gatekeepercontrolled
trunk are mainly the overall administration of the cluster and failover times.
Nongatekeeper-controlled trunks generally require that a full mesh of trunks be configured,
which can become an administrative burden as the number of clusters increases. In
addition, if a subscriber server in a cluster becomes unreachable, a 5-second (the default)
timeout occurs while the call is attempted. If an entire cluster is unreachable, the number
of attempts before either call failure or rerouting over the public switched telephone
network (PSTN) depends on the number of remote servers defined for the trunk and on the
number of trunks in the route list or route group. If many remote servers and many
nongatekeeper-controlled trunks exist, the call delay can become excessive.
With a gatekeeper-controlled intercluster trunk, you configure only one trunk that can then
communicate via the gatekeeper with all other clusters that are registered to the gatekeeper.
If a cluster or subscriber becomes unreachable, the gatekeeper automatically directs the call
to another subscriber in the cluster or rejects the call if no other possibilities exist. This
allows the call to be rerouted over the PSTN (if required) with little incurred delay. With a
single Cisco gatekeeper, it is possible to have 100 clusters that each register a single trunk
to the gatekeeper, with all clusters being able to call each other through the gatekeeper. Of
course, in an enormous enterprise environment with 100 clusters, multiple gatekeepers
configured as a gatekeeper cluster would eliminate the single point of failure. With
nongatekeeper-controlled intercluster trunks, this same topology would require 99 trunks
to be configured in each cluster. The formula for full-mesh connections is N(N-l)/2. Therefore,
without the gatekeeper, 100 clusters would require 4950 total trunks for complete intercluster
connectivity. The gatekeeper-controlled intercluster trunk should be used to
communicate only with other CUCMs, because the use of this trunk with other H.323
MGCP Gateway Implementation
devices might cause problems with supplementary services. In addition, a gatekeeper-controlled
intercluster trunk must be used for backward compatibility with CUCM versions earlier
than Release 3.2 (referred to as Cisco CallManager).
The H.225 trunk is essentially the same as the gatekeeper-controlled intercluster trunk,
except that it can work with CUCM clusters (Release 3.2 and later). It also can work with
other H.323 devices, such as Cisco IOS gateways (including CUCM Express), conferencing
systems, and clients. This capability is achieved through a discovery mechanism on a callby-
call basis. This type of trunk is the recommended H.323 trunk if all CUCM clusters are
at least Release 3.2.