E.164 Pattern Maps and Session Server Groups
With traditional dial peer configuration, you can configure only a single destination-pattern or incoming called-number command per dial peer. Even with regex and wildcards defined for maximum matches, this can mean a lot of dial peers. By using E.164 pattern maps, you can define a list of dial peer wildcard regex patterns as E.164 pattern entries and then apply an entire E.164 pattern map to a dial peer with either the incoming called e164-pattern-map or destination e164-pattern-map command. This effectively means that one dial peer can be configured to handle hundreds of incoming called number and destination pattern regex statements
It is possible to aggregate multiple session target commands into one logical group by using the voice class server-group command. A server group can contain up to five IPv4 or IPv6 entries and is applied to an outbound dial peer. Using server groups along with E.164 pattern maps can greatly reduce the number of dial peers configured on a system when the next-hop devices leverage application redundancy through clustering. Example 8-13 shows a sample voice-class server-group command with IPv4 and IPv6 entries. This server group is set up for the round-robin hunting scheme. The default hunting scheme uses the preference defined by the administrator. The command show voice class server-group can be leveraged to view elements of a server group.
OUTBOUND Calls from Corporate Network to ITSP
voice class e164-pattern-map 1
description E164 Pattern Map for PSTN Number Ranges
e164 9[2-9]......$
e164 91[2-9]..[2-9]......$
e164 9011T
e164 9?911$
!
dial-peer voice 1 voip
description Incoming from CUCM to CUBE
incoming called e164-pattern-map 1
session protocol sipv2
session target ipv4:172.16.1.1
!
dial-peer voice 11 voip
description Outbound from CUBE to PSTN
destination e164-pattern-map 1
session protocol sipv2
session target ipv4:10.1.1.1
INBOUND CALLS from ITSP to Corporate Network
voice class e164-pattern-map 2
description E164 Pattern Map for DID Number Ranges
e164 1408.......$
e164 1919574....$
e164 1919392....$
e164 +1T
!
voice class server-group 22
description CUCM Servers
hunt-scheme round-robin
ipv4 10.1.5.15 port 5060 preference 1
ipv4 10.1.5.16 port 5060 preference 2
!
dial-peer voice 2 voip
description Incoming from PSTN to CUBE
incoming called e164-pattern-map 2
session protocol sipv2
!
dial-peer voice 22 voip
description Outbound from CUBE to CUCM
destination e164-pattern-map 2
session protocol sipv2
session server-group 22
Dial Peer Groups (DPGs)
As you have already seen, the inbound dial peer selected for an inbound call leg can play a role in the selection of outbound dial peers. One way to force a call to use a specific outbound dial peer if a specific inbound dial peer is selected is to use a dial peer group (DPG). A DPG creates a static association between an inbound dial peer and one or more outbound dial peers. This is the first option in Table 8-5 because no other outbound dial peer matching criteria are evaluated when a DPG exists on an inbound dial peer matched on the inbound call leg.
The example below shows a DPG configured with the command voice class dpg number. Dial peers are assigned with the dial peer subcommand, and a preference can optionally be applied. The default preference is 0 (which is also the highest preference). The DPG is then applied to the inbound dial peer by using the destination dpg command. In this scenario, the called number 14085267209 would match dial peer 4 as the inbound dial peer due to the exact match incoming called-number 14085267209 command. Because this dial peer is configured with a destination dpg command, IOS looks at the dial peer configured as the destination for the call. The dial peers configured on the DPG are ordered by preference, and IOS selects the highest-preference dial peer for the outbound dial peer. In this example, only dial peer 400 is configured, and it is selected as the outbound dial peer. An outbound call leg session is set up using TCP SIP with the IP address returned by the DNS query on the FQDN (sj-cucm.ccnpcollab.lab), as per the session transport, session protocol, and session target commands.
voice class dpg 400
dial-peer 400 preference 1
!
dial-peer voice 4 voip
session protocol sipv2
destination dpg 400
incoming called-number 14085267209
!
dial-peer voice 400 voip
destination-pattern AAAAA
session protocol sipv2
session target ipv4: session target ipv4:10.1.1.1
Sourced-Based Call Routing with Dial Peer Groups
Source-based routing involves routing a call from a specific source to a static predefined destination, regardless of the calling/called number. The source match is performed by the voice class uri command assigned to an inbound dial peer. All calls with this source match the incoming uri statement, which is one of the first inbound match criteria checked. Then a DPG is assigned to the same inbound dial peer to force CUBE to use a specified outbound dial peer configured by the administrator. Example 8-18 shows voice class uri assigned to dial peer 5 to match all calls from a specific IP address in the SIP From header. When any call with a From header containing the IP address 172.18.110.65 is received, inbound dial peer 5 is selected, and the DPG is leveraged to select outbound dial peer 500 for outbound call routing. Note that dial peer 500 has destination-pattern set to AAAA, which forces the dial peer into an operationally up state. destination-pattern is not leveraged during this call as the DPG has already selected this dial peer as the outbound dial peer for the call.
voice class uri 5 sip
host ipv4:172.16.1.1
!
voice class dpg 500
dial-peer 500
!
dial-peer voice 5 voip
session protocol sipv2
destination dpg 500
incoming uri from 5
!
dial-peer voice 500 voip
session protocol sipv2
session target ipv4:10.1.1.1
destination-pattern AAAA
