Dial Peers for CUCM/CUBE using E164

[TONY SMITH]

Hi,

I was just wondering how people typically set up outbound dial peers when using E164 in both directions.   Increasingly we're finding that ITSPs are presenting called number in E164, and either want or prefer outbound in E164 as well.   So unless you create lots of explicit CUCM dial peers matching only the current DDI ranges, you have no obvious way to configure unambiguous destination patterns.   Unless there's a trick I'm missing the options seem to be ..

(1) As described, restrict the CUCM dial peers to only and exactly match the incoming DDI ranges.  Personally I dislike having to have the detailed dialplan duplicated on gateways in this way.

(2) Configure "+T" dial peers pointing to CUCM and to the ITSP with CUCM as the lower preference, relying on CUCM returning 404 and the gateway hunting on to the lower preference ITSP dial peers.

(3) Convert the outbound dialled numbers from CUCM into something other than E164, for example old-school 9 prefix.  That allows unambiguous destination patterns.  Convert back to E164 with an outbound translation profile/

None of these seem specially elegant, so I wondered whether I'm missing a trick, and also what other people generally use.

Thanks, Tony S

[Jonathan Schulenberg · Accepted solution]

There are at least two better ways of doing this:

1. If there are only two "sides" to the CUBE configuration - PSTN and CUCM - you can use Dial-Peer Groups to bypass the outbound dial-peer matching logic. This isn't viable if there is more than two possible destinations (e.g. CUCM & CVP from the PSTN).
2. Use Class of Restriction, or LPCOR on ASR since it lacks traditional COR, to restrict what outbound dial-peers are available based off the incoming dial-peer.

Personally, I'm a fan of option two and have been using this since 12.4(15)T.

[Ayodeji Okanlawon]

The latest version of CUBE IOS / and ASRs have had features to make life easier in scenarios like this for a while

1. On the inbound to CUCM..Use e164 pattern maps. Use text file to add your e164 DDI and upload them to router flash or to a central repository and tell cube the location of the files.

2. With e164 pattern maps you can have a single dial-peer to route multiple DDIs and with e164 numbers its even much easier

3. I am not a fan of +T ( I personally think its a very lazy approach).

For outbound calls to ITSP, if your ITSP supports E164 numbers and your CUCM dialplan is using E164 numbers, then you can leverage provisioning policy on CUBE that allows you to route calls not on the called number but on a set of attributes received on the inbound SIP INVITE

Its a really beautiful feature and with this you can do something like this

1. if call comes in from cucm cluster A either send the call to ITSP A

2. if the call comes in from cucm cluster B send the call to ITSP B

With this you will never have to do consider option (2) mentioned above (this is quite ugly :)

This way of call routing overcomes the traditional approach where you have to route calls either by called number or called-uri etc. It gives you the flexibility to route calls based on a number of factors including calling number, and variety of sip URIs.

For example, we have seven cucm clusters that use centralized CUBE sip trunks and we use a single inbound dial-peer (based on provisioning policy) and a single outbound dial-peer to route the call. No more gateways with spagetti dial-peers!

You can read more here

http://www.cisco.com/c/en/us/support/docs/voice/dial-plan/200103-Configure-and-Troubleshoot-Multiple-Patt.html

[Carl Ratcliffe]

Hi All 

I've used e164 pattern maps for outbound calls and it works great.

What I haven't tried using them for yet is inbound calls so incoming calling and incoming called dial peer matching.  Does anyone know what priority e164 pattern maps slot into the existing order of matching as I can't find it in the documentation. 

Preference for Dial-Peer Matching

The following is the order in which inbound dial-peer is matched for SIP call-legs:

 voice class uri URI-class-identifier with incoming uri {via} URI-class-identifier

 voice class uri URI-class-identifier with incoming uri {request} URI-class-identifier

 voice class uri URI-class-identifier with incoming uri {to} URI-class-identifier

 voice class uri URI-class-identifier with incoming uri {from} URI-class-identifier

 incoming called-number DNIS-string

 answer-address ANI-string

The following is the order in which inbound dial-peer is matched for H.323 call-legs:

 incoming uri {called} URI-class-identifier

 incoming uri {callling} URI-class-identifier

 incoming called-number DNIS-string

 answer-address ANI-string

The following is the order in which outbound dial-peer is matched for SIP call-legs:

 destination route-string

 destination URI-class-identifier with target carrier-id string

 destination-pattern with target carrier-id string

 destination URI-class-identifier

 destination-patternBet get carrier-id string

Thanks, Carl Ratcliffe Preston lLancashire England 

[Carl Ratcliffe]

OK so found the information in the link from this discussion. It looks like although it's a separate configuration for e164 it is just bundled into the existing priority matching.  

Dial-Peer Provisioning Sequences

Called number matches incoming called-number or incoming called E164-pattern-map.

 Calling number matches either answer-address or incoming calling E164-pattern-map.

Calling number matches with a destination-pattern.

Thanks, Carl Ratcliffe

Preston Lancashire England 

[Ayodeji Okanlawon]

Yes carl, Its still the same as called or calling number but just the modularity/flexibility of grouping multiple numbers in one place

[eschroedertb]

Can you expand a little about how provisioning policy would work? I have looked at the configuration and troubleshooting guides but I cannot seem to get a handle on it. 

My scenario is this: Single CUCM cluster with many sites, single carrier enterprise SIP trunk, CUBE in the middle. +E.164 in use on both sides. I want to have the simplest set of dial-peers as I can and not touch CUBE as more sites come live on the enterprise trunk. 

I cannot seem to grasp how provisioning policy would work in this case. Based on your example, you can use provisioning policy to route based on the invite "from" header, is that right? Could you post an example of how to accomplish this? 

[Ayodeji Okanlawon]

Its very late for me now need to sleep :), but I will do this tomorrow

[Ayodeji Okanlawon]

Hi Eschroedertb,

Voice class provisioning policy provides a level of flexibility that using traditional dial-peers do not have. Because of this it is hugely scalable especially when multiple CUCM clusters are concerned with a centralized gateway

Traditionally you can select an outbound dial-peer by looking at the following

• destination called number
• destination uri (host / pattern / user-id / phone)
• carrier-id target

What if I want to route calls based on a separate set of parameters, for example calling number.

Or what if in a multi cluster environment, I want all calls from a certain CUCM cluster to go out via a certain SIP provider

Or in a multiple CUCM cluster environment, I want to route calls using a single dial-peer to the same ITSP and I don't want to use all the wildcards ( +T, .T , because of all the issues they sometimes create).

The answer to so many of this conundrum is using provisioning policy. The documentation is a little confusing until you actually deploy it then it makes more sense.

Here goes my attempt to make sense of this great feature

Example 1: Routing based on Calling number

In this example we want to route a call based on the calling number

First of all we define the number we want to route on. If the calling number is 1111000010, then we will use dial-peer voice 302 to route the call

NB: We don't care what the called number is. Previously we cant do this, we will need to statically configure the destination pattern as the called number

++ Config ++

## define attribute to route on ##

router(config)#voice class e164-pattern-map 1
router(config-class)#e164 1111000010

### Next we configure the provisioning policy to use ###

router(config)#voice class dial-peer provision-policy 1
router(config-class)#description MatchBasedOnCalling
router(config-class)#preference 1 calling

### Associating Provision policy to incoming Dial-Peer ###

Here we are saying that when inbound dial-peer 301 is matched, use the provision policy defined to match an outbound dial-peer. In this case we are saying look for the outbound dial-peer with calling number "1111000010"

router(config)#dial-peer voice 301 voip
router(config-dial-peer)#destination provision-policy 1
Outbound Dial-Peer definition

### configure outbound dial-peer ###

 Here we apply the e164 patterm map configured earlier and this will be the matched outbound dial-peer 

router(config)#dial-peer voice 302 voip
router(config-dial-peer)#destination calling e164-pattern-map 1

Summary:

What is clear here is that we have totally changed the way we routed this call. In the past, we needed to use a destination-pattern ( or the other two show listed above) to match the outbound dial-peer, but now we are saying match outbound dial-peer based on calling number. Sweet :)

Example two:

++ Route Call based on SIP from header ++

In this example we route the call based on the from header. We don't care what the called number or calling number is. As long as the from header matches based on the provisioning attribute on the inbound dial-peer.  This is very useful in scenarios where we need to send calls coming from multiple cucm clusters to a service provider. we don't need to worry about the called numbers and hence the right dial-plan to configure on gateway etc, we just route based on the from header 

++ Config ++

### define the uri to use to match inbound dial-peer ###

voice class uri 36 sip
host lab.ccie.com

voice class uri 372 sip
host 95.94.107.107

### define server-groups to use for outbound call ###

voice class server-group 37
ipv4 81.106.287.17 preference 1
ipv4 95.94.107.107 preference 2

### configure dial-peer provision policy ###

voice class dial-peer provision-policy 36
preference 1 called
!
voice class dial-peer provision-policy 37
preference 1 from

### configure inbound dial-peer and apply provision policy ###

once this dial-peer is matched we will select the outbound dial-peer based on the provision policy. This dial-peer is matched based on the host portion of the from header which matches voice class uri 36 sip

### incoming INVITE ####
Received:
INVITE sip:+447868185374@192.168.132.207:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.131.100:5060;branch=z9hG4bK2e4031360a54fe
From: "Ayodeji Okanlawon" <sip:+442036622174@lab.ccie.com>;tag=11701040~20d1b888-4b6f-4b88-816d-f704cb366ea1-72151803

NB: The host portion of the from header=lab.ccie.com, hence our inbound dial-peer 20

### debug voip dialpeer inout ###

Calling Number=+442036622174, Called Number=+447868185374, Voice-Interface=0x0,
Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
Peer Info Type=DIALPEER_INFO_SPEECH
Feb 6 15:32:42.641: //-1/7E8E0E800000/DPM/dpAssociateIncomingPeerCore:
Result=Success(0) after DP_MATCH_FROM_URI; Incoming Dial-peer=120
Feb 6 15:32:42.641: //-1/7E8E0E800000/DPM/dpMatchSafModulePlugin:
dialstring=NULL, saf_enabled=0, saf_dndb_lookup=0, dp_result=0
Feb 6 15:32:42.641: //-1/xxxxxxxxxxxx/DPM/dpGetSIPUriProvisionBmp:
Tag=20
Feb 6 15:32:42.641: //-1/xxxxxxxxxxxx/DPM/dpGetSIPUriProvisionBmp:
Result=1 Bitmap=0x10

dial-peer voice 20 voip
description ** Incoming worldwide CUCM dial-peer Leg **
preference 1
session protocol sipv2
destination provision-policy 37
incoming uri from 36
voice-class codec 1
voice-class sip early-offer forced
voice-class sip bind control source-interface GigabitEthernet0/0/1
voice-class sip bind media source-interface GigabitEthernet0/0/1
dtmf-relay rtp-nte
no vad

### Now that we have matched the dial-peer we apply the provisioning policy to select an outbound dial-peer ###

voice class dial-peer provision-policy 37
preference 1 from

This policy states match an outbound dial-peer based on the "From" header in the SIP INVITE

Now we need to define which uri's from header should be used on the outbound dial-peer

### on the outbound dial-peer we tell it to match the from header on voice class uri 36.###

dial-peer voice 30 voip
description From global CUCM clusters to ITSP
session protocol sipv2
session server-group 37
destination uri-from 36
voice-class codec 37
voice-class sip options-keepalive profile 37
voice-class sip bind control source-interface GigabitEthernet0/0/2
voice-class sip bind media source-interface GigabitEthernet0/0/2
dtmf-relay rtp-nte
no vad

So any call from "lab.ccie.com" should be routed out this dial-peer to ITSP
This negates the need to configure multiple called number patterns using the traditional destination-pattern approach.

#### debug voip dialpeer inout ###

Feb 6 15:32:42.642: //-1/7E8E0E800000/DPM/dpMatchDestDPProvPolicy:
Calling Number=, Called Number=+447868185374, DPProvPolicy=37
Feb 6 15:32:42.642: //-1/7E8E0E800000/DPM/dpMatchDestDPProvPolicy:
Result=Success(0) after DP_MATCH_DEST_FROM_URI
Feb 6 15:32:42.642: //-1/7E8E0E800000/DPM/dpMatchPeersCore:
Result=SUCCESS(0) after DestDPProvPolicy
Feb 6 15:32:42.642: //-1/7E8E0E800000/DPM/dpMatchSafModulePlugin:
dialstring=+447868185374, saf_enabled=0, saf_dndb_lookup=1, dp_result=0
Feb 6 15:32:42.642: //-1/7E8E0E800000/DPM/dpMatchPeersMoreArg:
Result=SUCCESS(0)
List of Matched Outgoing Dial-peer(s):
1: Dial-peer Tag=30

Summary:

This feature provides huge benefits. As you can imagine, I didn't have to worry about the dialing habits of each cluster ( I have already ensured that the dialed numbers are routable through the gateways from CUCM's perspective). All I need to ensure is that CUCM sends outbound SIP INVITE (host portion) with SIP URI and not IP address. As long as the configured URI is matched, the provisioning policy will use the from header to match an outbound dial-peer. If I add another CUCM cluster, I don't have to touch the gateway, calls will route based on existing configuration

Simples :)

[eschroedertb]

This is very helpful, thank you. 

What if the SIP invite from CUCM uses IP rather than the domain for the URI? I see that I can only have 1 host per uri voice class, so most likely I want to make CUCM use the domain instead of IP. How would I change that? My SIP profile already has "Use Fully Qualified Domain Name in SIP Requests" checked, but the invites still show as coming form an IP. 

[Ayodeji Okanlawon]

When "Use Fully Qualified Domain Name in SIP Requests" is enabled on the SIP profile, the FROM header is sourced from the "Organization Top Level domain name" configured under enterprise parameters.

So configure your host portion of your URI there.

If the SIP invite has IP address then it wont match the inbound dial-peer that has your provisioning policy and your call will fail

[eschroedertb]

Just wanted to say thanks. I've gotten the in and outbound calls working using the SIP URIs, and your explanation was invaluable. 

One thing that I ran into: My SIP carrier send inbound calls to the CUBE from a range of unspecified media IPs, so I had to use the VIA method on the carrier inbound. I have two carrier inbound dial-peers since they have a redundant setup and they only use IP, not FQDNs. That complicated my config a little, because I now have 6 dial-peers instead of two, and I had to create a new provision-policy. But going forward, I should be golden. 

Thank you!

[Ayodeji Okanlawon]

You are welcome anytime. Glad to help. Don't forget to rate useful posts :)

[Ayodeji Okanlawon]

I know this is old but looking back at this you can configure multiple ips in your voice class URIs, hence no need for the multiple dial peers

To use ip address of multiple cucm nodes

Voice class URIs cucm sip

 host ipv4: x.x.x.x

 host ipv4: y.y.y.y

For ITSP

Voice class URIs itsp sip

 host ipv4: x.x x.x

 host ipv4: y.y.y.y

[TONY SMITH]

And multiple session targets as well.  Typically I now configure a simple CUBE with just two dial peers, one is both inbound and outbound for the ITSP, and one for the CUCM servers.