VoIP Configuration: Dial Peer Matching with URI and E164 Maps

If you have spent any time configuring Cisco voice gateways, you have likely struggled with dial-peer matching. Until recently, things were reasonably straightforward. Telephone directory numbers (extensions) were typically four digits. When a call came in from the outside, the carrier typically sent just the last four to seven digits. When you wanted to place an outside call, you would prefix the call with a 9. In short, incoming numbers and outgoing numbers were formatted in a way that made them easy to spot, and easy to match in a dial-peer.

Once SIP trunks became more standard, things began to get a little complicated. The carrier is now sending the entire number, including the country code; they also often send the number with a leading + (what is called E.164, or a +E.164 format), and expect us to send outgoing calls in the same manner. And VoIP teams worked with that and said: hey, no big deal, we can just catch the +1 XXX-XXX-XXXX numbers inbound and strip off everything but the last four and match it on our Cisco Unified Communications Manager (CUCM) facing dial-peers. And on the outgoing public switched telephone network (PSTN) calls, you can watch for that leading 9, strip it and prefix it with a +, or a +1, or whatever is needed to reestablish the natural order of things.

Explore CDW’s telephony and VoIP solutions and services.

Cisco Updates Dial-Peer Configuration

Just as everyone was coming to grips with these changes, full E.164 internal dial plans began to make a lot of sense for organizations. Instead of calling 4455 for an internal call, 9-555-1212 for a local call and 9-1-222-555-1212 for a national long-distance call, users can dial the full E.164 number for whomever they are calling, leaving it to the call routing logic in the PBX to decide if it’s an on-net or off-net call.

The result is that every number is arriving at the voice gateway in the same format, which requires a new approach to dial-peer matching. Fortunately, Cisco has unleashed some much-needed updates to dial-peer configuration that allow us to route calls not only based on a fixed string of digits, but also based on the IP address(es) where the call originated. This is done via the uniform resource identifier (URI) config and an editable list of variable length numbers that can match outbound called an E164 map.

URI and E164 Map Example

Consider this (very simple) classic example: A PSTN SIP trunk from the carrier to a gateway and an internal SIP connection to a Cisco Communications Manager server cluster where all the system phones register for call control. A typically configuration would look something like the following. A dial-peer to match inbound from the carrier on the direct inward dialing numbers (DIDs) that strips off the extra digits and some outbound dial peers that match those remaining digits and send the call off to the PBX, then some inbound dial-peers to match what’s coming from the PBX, strip the 9 prefix and sends it off to the carrier. The config would look something like this:

dial-peer voice 1 voip
description INBOUND from PSTN (SIP)
translation-profile incoming StripNPA-NXX
session protocol sipv2
incoming called-number 33022233..
!
dial-peer voice 2 voip
description OUTBOUND to CUCM1 (SIP)
preference 1
destination-pattern 33..
session protocol sipv2
session target ipv4:10.1.1.10
!
dial-peer voice 3 voip
description OUTBOUND to CUCM2 (SIP)
preference 2
destination-pattern 33..
session protocol sipv2
session target ipv4:10.1.1.11
!
dial-peer voice 4 voip
description OUTBOUND to CUCM3 (SIP)
preference 2
destination-pattern 33..
session protocol sipv2
session target ipv4:10.1.1.12
!
dial-peer voice 5 voip
description INBOUND from CUCM (SIP)
translation-profile incoming Strip9
session protocol sipv2
incoming called-number 9.T
!
dial-peer voice 6 voip
description OUTBOUND to PSTN Server 1 (SIP)
destination-pattern 1....…
session protocol sipv2
session target ipv4:172.16.10.30
!
dial-peer voice 7 voip
description OUTBOUND to PSTN Server 2 (SIP)
destination-pattern 1....…
session protocol sipv2
session target ipv4:172.16.10.31

Note: Voice translation rules and profiles, as well as some common dial-peer configuration elements, have been omitted from these examples for brevity sake. These dial-peers are for illustrative purposes only.

The above setup requires the outgoing and incoming number to be in a specific format in order to match the correct set of dial-peers, and it also is not very flexible. It often requires the inclusion of additional dial-peers when adding servers to the cluster, or when digit strings are not contiguous.

E164 Map and SIP URI Example

Instead of matching on a fixed called digit string in the dial-peers, what if you could match on a variable length list of numbers? Also, what if you could match inbound based on the IP address of the system where the call originated? Let’s look at a modern example using E164 maps and SIP URI matching.

Consider this second example, a very typical setup of what exists today. A SIP trunk from the carrier that uses the IP addresses of 172.17.10.5 and 172.17.10.6. A range of DIDs from +1 (440) 333-4400 to +1 (440) 333-4499, a toll-free number of +1 (888) 555-1212, and a small block of numbers for an office in the next town over who use this SIP trunk for PSTN access as well, along with a DID range of +1 (440) 334-2201, 2204 and 3917. And to make it more interesting, let’s include a full +E164 internal dial plan, so all station DNs use the full +1 PSTN DID.

First, let’s create two sets of URI containers and some server groups; URI 10 to match the carrier – 172.17.10.5 and 172.17.10.6, URI 12 will match our internal CUCM server cluster 10.10.10.100, 10.10.20.101 and 10.10.20.103. Server group 10 will match the carrier’s IPs and Server group 13 will match our CUCM IPs.

voice class uri 10 sip
host ipv4:172.17.10.5
host ipv4:172.17.10.6
!
voice class uri 12 sip
host ipv4:207.227.242.165
host ipv4:207.227.226.11
!
voice class server-group 10
ipv4 172.17.10.5 preference 1
ipv4 172.17.10.6 preference 2
!
voice class server-group 13
ipv4 10.10.100.101 preference 1
ipv4 10.10.100.102 preference 2
ipv4 10.10.100.103 preference 3

Now you can create two E164 maps, A E164 Map 11 that includes all the DID numbers on our SIP trunk for inbound calls and an E164 Map 13 that includes all of the patterns dialed for outbound PSTN calls.

!
voice class e164-pattern-map 11
e164 +144033344..
e164 +18885551212
e164 +14403342201
e164 +14403342204
e164 +14403343917
!
voice class e164-pattern-map 13
e164 +011.T
e164 +1....…
e164 11

Dial-Peers for PSTN

Once these elements are in place, you can create dial-peers for calls originating from the PSTN; dial-peer #10 to match inbound on URI #10 (the IP addresses of the carrier’s SIP equipment) and send the unmodified +E.164 number to dial-peer #11, which uses an E164 map to send the calls outbound to the CUCM servers via the server map.

For calls from the internal phones out to the PSTN, you can set up the dial-peers as follows:

Dial-peer 12 matches inbound on URI #12 (CUCM server IP addresses) and sends the called number (this time around don’t use a 9 for outgoing calls) to dial-peer #13 and matches against the E164 map 13, which includes the wildcards for PSTN formatted numbers (any number we don’t own).

Again, these are simplified dial-peers to highlight my example.

dial-peer voice 10 voip
description INBOUND from PSTN (SIP)
incoming uri via 10
session protocol sipv2
!
dial-peer voice 11 voip
description OUTBOUND to CUCM (SIP)
destination e164-pattern-map 11
session protocol sipv2
session server-group 11
!
dial-peer voice 12 voip
description INBOUND from CUCM (SIP)
incoming uri via 12
session protocol sipv2
!
dial-peer voice 13 voip
description OUTBOUND to PSTN (SIP)
destination e164-pattern-map 13
session protocol sipv2
session server-group 13

As you can see from the above example, you are able to reduce the number of dial-peers needed even though the overall complexity of the dial plan is increased. Instead of matching based on number format and length, you match based on arrays of configuration elements. This is a much more rational approach in an environment where inbound numbers and outbound numbers are formatted the same.

Dial-peer matching is always a challenge. I hope these scripts can help you bring some efficiencies and order to your VoIP network.