This blog will be the first blog in a blog series covering H.323 and SIP gateways. H.323 and SIP gateways are significantly different than MGCP gateways. The MGCP gateway protocol follows a master/slave model in which the gateway is 100% reliant on the call agent (CUCM) to make call routing decisions. H.323 and SIP gateways represent peer to peer call routing paradigms where each gateway router analyzes the dialed digits and performs a call routing (steering) decision. To properly configure H.323 or SIP gateways, one must have a working understanding of Cisco IOS basics and develop proficiency for the digit consumption and manipulation commands used in Cisco IOS dial-peers.
It is my personal opinion that H.323 is a more stable gateway protocol than MGCP when using gateways with CUCM. H.323 offers better call survivability features than MGCP since the addition of the H.323 call preservation (call survivability) enhancement of IOS 12.4(9T). Cisco Unified Communications Manager Express (CUCME) is a self contained call routing platform that must use H.323 and/or SIP dial-peers for call routing decisions.
Dial-peers have four varieties described as follows:
POTS - Plain Old Telephony Service
VoIP – Voice over IP
VoFR – Voice over Frame
VoATM – Voice over ATM
POTS dial-peers are used to route calls to Time Division Multiplexing (TDM) interfaces (T1-CAS, FXS, FXO, E1, and T1-PRI, etc.). VoIP dial-peers are used to route calls over an IP network. VoIP dial-peers default to the H.323 protocol, but this may be changed to SIP version 2.0. Voice over Frame and Voice over ATM are two options that offered voice transport without the additional overhead of an IP / UDP / RTP header, but they never gained much popularity. Only POTS and VoIP dial-peers will be discussed in subsequent blogs about dial-peer configuration.
A dial-peer represents one or more addressable endpoints that create the call routing table in Cisco IOS. An example of a dial-peer is shown in the following example:
Router(config)#dial-peer voice 1 pots
The configuration above created a logical call routing dial-peer construct with a tab number of 1. The tab number is a field which is locally significant to the router that’s performing digit analysis. When first creating a dial-peer, the type of dial-peer must be specified. Subsequent dial-peer configuration changes can be made by addressing the tab number w/o the pots option as shown in the following example:
Router(config)#dial-p v 1
The above example also used some Cisco IOS concatenation commands that will allow the administrator to move around Cisco IOS configuration a bit faster. The following example is a dial-peer configuration for an analog phone with an internal 5-digit abbreviated dial plan plugged into FXS port 0/1/0 on the Cisco router:
POTS dial-peers only forward wildcard digits by default. Since the dial-peer configured above does not have any wildcards, no digits will be forwarded on the FXS port. We could change the behavior of this port by using the forward-digits all dial-peer configuration option shown.
This configuration has very undesirable effects on an FXS port connected to an analog phone. Every time a call is presented to the phone and the end user goes offhook on the phone, they will hear the five digits that were dialed. To restore the default digit stripping options of the pots dial-peer, use the “default forward-digits” command. The “no forward-digits all” command will put the command “forward-digits 0” into the dial-peer configuration. While forward-digits 0 would work in this example, the operation would be highly undesirable for TDM interfaces connecting to the PSTN or third-party voice systems.
The next blog will continue our coverage of dial-peers in Cisco IOS.
Dennis Hartmann, CCIE No. 15651, is a consultant with www.highpoint.com and author of Implementing Cisco Unified Communications Manager, Part 1. Dennis is also a lead instructor at Global Knowledge. Dennis has various certifications, including the Cisco CCVP, CCSI, CCNP, CCIP, and the Microsoft MCSE. Dennis has various specializations including unified communications, data center, routing & switching, service provider (MPLS and optical). Dennis has worked for various Fortune 500 companies, including AT&T, Sprint, Merrill Lynch, KPMG, and Cabletron Systems. He lives with his wife and children in Hopewell Junction, New York.