This topic describes the characteristics of a SIP trunk.
- Distributed dial plan
- Can be connected to any device that supports SIP, including Cisco IOS gateways, Cisco Expressway, Cisco Unified Border Element, remote Cisco Unified Communications Manager clusters, and third-party SIP devices
- Simple, customizable protocol
- The preferred protocol
SIP uses the distributed call-processing model, so a SIP gateway or proxy has its own local dial plan and performs call processing on its own. A Cisco Unified Communications Manager SIP trunk can connect to Cisco IOS gateways, a Cisco Unified Border Element, other Cisco Unified Communications Manager clusters, or a SIP implementation with network servers (such as a SIP proxy).
SIP is a simple, customizable protocol with a rapidly evolving feature set. SIP has become the preferred signaling protocol.
H.323 Trunk Overview
This topic describes the characteristics of an H.323 trunk.
The figure shows various types of H.323 trunks.
In the example, the Cisco Unified Communications Manager cluster A uses a nongatekeeper-controlled ICT to Cisco Unified Communications Manager cluster B. In addition, Cisco Unified Communications Manager cluster A is configured with a gatekeeper-controlled ICT. The gatekeeper-controlled ICT points to a gatekeeper, which is used for address resolution. In this example, the gatekeeper can route calls between Cisco Unified Communications Manager clusters A, C, and D.
H.323 Trunk Comparison
The table compares characteristics of the three available H.323 trunk types.
|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)|
|Peer||Cisco Unified Communications Manager||Before Cisco CallManager Version 3.2||Cisco CallManager Version 3.2 or later and all other H.323 devices|
The nongatekeeper-controlled ICT is the simplest trunk, because it does not use a gatekeeper. It requires the IP address of the remote Cisco Unified Communications Manager 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 the gatekeeper CAC. Scalability is limited because no address resolution is used and all IP addresses must be configured manually. The nongatekeeper-controlled ICT points to the Cisco Unified Communications Manager server of the other cluster.
For a larger number of clusters, the gatekeeper-controlled ICT should be used instead of the nongatekeeper-controlled trunk. The advantages of using the gatekeeper-controlled 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. Also, if a subscriber server in a cluster becomes unreachable, there will be a 5-second (default) timeout while the call is attempted. If an entire cluster is unreachable, the number of attempts before either a call failure or a rerouting of the call over the PSTN will depend on the number of remote servers that are defined for the trunk and on the number of trunks in the route list or route group. If there are many remote servers and many nongatekeeper-controlled trunks, the call delay can become excessive.
With a gatekeeper-controlled ICT, you configure only one trunk. That trunk then communicates 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 action allows the call to be rerouted over the PSTN (if required) with little delay. With a single Cisco gatekeeper, it is possible to have 100 clusters that register a single trunk each, with all clusters able to call each other. With nongatekeeper-controlled trunks, this same topology would require 99 trunks to be configured in each cluster. The gatekeeper-controlled ICT should be used for communicating only with other Cisco Unified Communications Managers, because the use of this trunk with other H.323 devices might cause problems with supplementary services. In addition, a gatekeeper-controlled ICT must be used for backward compatibility with Cisco Unified Communications Manager versions earlier than Version 3.2 (referred to as Cisco CallManager).
The H.225 trunk is essentially the same as the gatekeeper-controlled ICT, except that it has the capability of working with Cisco Unified Communications Manager clusters (Version 3.2 and later), as well as other H.323 devices, such as Cisco IOS gateways (including Cisco Unified Communications Manager Express), conferencing systems, and clients. This capability is achieved through a discovery mechanism on a call-by-call basis. This type of trunk is the recommended H.323 trunk if all Cisco Unified Communications Manager clusters are at least Version 3.2.