Call me Now

H323 / SIP Trunks for CallManager 4.x

By Vik Malhi

When the time comes for a CCIE Voice candidate to achieve routing calls between CallManager (CCM) and CallManager Express (CME), the CCIE Voice Lab presents a variety of challenges and options. What is deemed as the most logical choice in the real world may not necessarily present itself in the lab world. For example, with two nodes in the topology (CallManager cluster and CME) a gatekeeper may be adding complexity and so in the real world such a network would most probably be devoid of any gatekeeper. Do not make such an assumption when you are preparing for the lab!                                     

The objective of this article is to focus on when to use each of the different trunks or gateways that are available on CallManager 4.1(3). Before we get started, it is worth remembering that when you add an H323 gateway or trunk in CallManager, you are defining a virtual signaling interface in CallManager. It is easier for most people to envisage a phone registering to CallManager since there is a tangible device involved but ultimately you can think of the virtual signaling interface in the same light.

The first method discussed when calling between CallManager and CME is to use the gatekeeper. This makes the most sense in the larger IP Telephony deployments that are using H323 as the trunk side protocol since the routing decisions are handled by gatekeeper which also manages Call Admission Control across the multiple Call Control entities. This makes for a more scalable voice network. During call establishment CallManager and CME are in effect introduced to each other by the gatekeeper assuming there is enough bandwidth available across the WAN. After the initial introductions, CallManager and CME are able to communicate directly with each other via the H225, H245 and finally the RTP protocols

The advantage of using the gatekeeper can really be felt when there is more than one CallManager cluster or CME. Upon introducing a third Call Control agent (CCM or CME), rather than adding multiple dial-peers on the CME and additional trunks on the CallManager cluster thus creating a mesh of trunks and dial-peers, only a single command need to be added to the gatekeeper thus making the network administrators life somewhat easier. The beauty of the solution is that each node in the network requires only a single trunk (in the case of CallManager) or a single dial-peer (in the case of CME). The gatekeeper in effect allows there to be a single brain in the network which makes provisioning, configuration and troubleshooting much easier. It is often said that the gatekeeper enforces H323 into becoming a Master/Slave protocol from the normal peer to peer mode operation.

In terms of configuration on CallManager what do we need to do? Before deciding on which trunk to use, we must first add the gatekeeper in CallManager Administration. This can be done from the CCMAdmin GUI from Device > Gatekeeper > Add a New Gatekeeper. On this web page the administrator will then add the IP address of the gatekeeper. The next question is which IP address? The gatekeeper could have an IP address assigned to the serial interface, FastEthernet interface and also a Loopback interface. Typically the IP address defined on the web page should match what is being used as the RAS address for the zones defined on the gatekeeper as shown below.

gatekeeper
 zone local testzone ipexpert.com <RAS address>

Typically in deployments when HSRP redundancy is NOT being used, a loopback interface will be used since they are less susceptible to interface flapping

Once we have added the gatekeeper in CallManager, we now need to decide upon which trunk to use. There are 4 choices:

[Note: There is a fifth signaling interface which is H323 gateway. However this appears under the list of gateways as opposed to trunks.]

In this case the choice comes down to the first two options since those are the only trunks which can initiate RAS messaging required by the gatekeeper. If the version of CallManager is running 3.2 or higher then the H225 gatekeeper controlled trunk should be used (as is the case in the Voice Lab).

When you are configuring the trunk, you need to give it a unique name to be used to point traffic to the trunk in the next step. You also need to select the gatekeeper that you defined previously from a drop-down box, add an appropriate technology prefix. Always set the Terminal Type field to “gateway” for normal CAC. It is almost always desirable to have a different zone name for each CallManager cluster that is defined on the gatekeeper. This helps when configuring bandwidth management.

When there are multiple CallManager servers assigned to the CallManager Groups in the Device Pool for redundancy, then it must be noted that multiple trunks will register to the gatekeeper. The administrator does not need to define multiple trunks- the process is transparent to the administrator. Each trunk, from the perspective of the gatekeeper, will have a unique device name. The name of the trunk assigned to the Publisher CallManager will be <deivce_name_of_trunk>_1 and the first subscriber added to the cluster will have a separate relationship with the gatekeeper using a different trunk which has the unique name <deivce_name_of_trunk>_2. This can be verified from the gatekeeper by entering the command “show gatekeeper endpoints”. Note that the suffix _1 and _2 are automatically appended to the trunk name without any user intervention and cannot be changed.

The second method CallManager can use to communicate with CME is a direct H323 relationship without any other 3rd party elements involved. CME acts like a normal H323 gateway to CallManager with H225/H245/RTP communication being sent directly between CallManager and CME. In this instance, CallManager needs to have a H323 gateway defined in order to route calls to the CME. From CCMAdmin, go to Device > Gateway > Add a New gateway and Select H.323 Gateway from the drop-down list next to Gateway Type. On the gateway page, for Device Name, enter the IP address of the router. Notice that only one IP address is allowed. If the router might use multiple interfaces to communicate with its CallManager, you need to tell the router which one to use as the source of its messages (possibly a loopback interface). Use the h323-gateway voip bind srcaddr ip-address command, under interface configuration mode.

It must be mentioned that in the previous example, CallManager is oblivious to the fact that the H323 gateway is indeed a CME- the same method would be used to integrate any H323 gateway with POTS interfaces.

The third potential way CallManager could communicate to/from CME is via a Multiservice IP-to-IP gateway or Session Border Controller, more recently known as Cisco Unified Border Element (CUBE). If there is a gatekeeper operational in the network, then more often than not the CUBE and CallManager communicate in much the same way as was discussed above when CallManager and CME interacted with the help of the gatekeeper. That means gatekeeper introduces CUBE to CallManager and hence from CallManager’s perspective only a single H225 gatekeeper controlled trunk is required. CallManager does not need a separate signaling interface or trunk to accomodate CUBE. The difference between having CCM -> GK -> CME and CCM -> GK -> CUBE interactions is not related to the type of trunk but moreover the requirements of the H225 gk-controlled trunk.

Since the CUBE, based on the IOS version available in the CCIE Voice Lab, does not support the Empty Capabilities Set method for Supplementary services used by CallManager a Media Termination Point is required by the trunk for these supplementary services to function correctly (Hold, Transfer, Forward). This means that the MTP checkbox must be marked on the trunk web page. In addition the Wait for Far End H.245 Terminal Capability Set checkbox should be unchecked when integrating the CUBE with the gatekeeper.

In the absence of a gatekeeper, the CUBE and CallManager can communicate directly with each other, similar to the second method discussed above. However there is one significant difference when adding a H323 gateway with POTS interfaces and a CUBE which has no POTS interfaces. Rather than adding an H323 gateway, a non-gatekeeper controlled inter-cluster trunk should be used. In the device name of the trunk the IP address of the CUBE should be defined (on the router use the h323-gateway voip bind srcaddr ip-address command under the chosen interface configuration mode). In addition MTP should be enabled and the Terminal Type field should be set to “gateway”.

The fourth and final way CallManager and CME can interact is using a SIP trunk. In the CallManager 4.x versions, the codec for all calls established over a SIP trunk is restricted to either G.711 mu-law or a-law.

CallManager versions 4.x can register a SIP trunk connecting to a remote gateway, a proxy server, or CallManager Express. The trunk is referred to as a signaling interface. CallManager 5.x can register SIP phones, in addition to SIP trunks. Trunks can point to other Cisco CallManager clusters, also. On the SIP trunk, a media termination point (MTP) is required. This is to translate DTMF signals between SIP and SCCP phones. The SCCP phones uses an out-of-band DTMF mechanism based on H245 (h245-alphanumeric) whereas SIP can use either a different payload in the RTP packet (rtp-nte) or an out of band mechanism called SIP-NOTIFY.

RTP-NTE is an in-band DTMF relay method, which uses RTP Named Telephony Event (NTE) packets to carry DTMF information instead of voice. If RTP-NTE is configured, SDP is used to negotiate the payload type value for NTE packets and the events that will be sent using NTE.

RTP-NTE can cause problems communicating with SCCP phones, which use only out-of-band DTMF relay. In a CallManager 4.x network with SCCP phones, you must provision an MTP for calls that traverse the SIP trunk. This MTP translates between in-band and out-of-band DTMF signals. The MTP can either provisioned in hardware or in software on CallManager.

If the software MTP available on CallManager is being used, then it is vital that the correct Region is assigned to it since no low bit rate codecs are supported when using the software MTP (this is the difference between an MTP and Transcoder, the latter can support G729<->G711 conversion). Since the software MTP can only support g711 (and wideband which we shall discount at this time) it makes sense to create a new Region which can communicate to all other regions using g711. Assign this new Region to a new Device Pool and this new Device Pool should be assigned to the software MTP(s) as well as the SIP Trunk since only g711 is supported.

On the gateway or CME, configuration consists of simply adding one line under a VoIP dial peer configuration: session protocol sipv2. To change the transport protocol (UDP is the default), use the session transport [udp | tcp] command. This should match what has been configured on the CallManager SIP trunk.