cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
947
Views
35
Helpful
11
Replies

Gateway dial peer selection for routing to CCE and CUCM best practice?

I have a post in the Unified Communications forum, but I wanted to ask it here. I have a customer with a PCCE installation and multiple CUCM clusters. I want to use different inbound dial peers for the calls to PCCE because those require "service survivability". If I apply that service to the incoming dial peer for calls going to CUCM, the service alters the calling party name which causes the users complain. I saw a lot of CCE designs reference CUSP (SIP Proxy), but that product has been retired. What is considered best practice for dial peer selection in a gateway/CUBE that routes some calls to CCE/CVP and some calls elsewhere like to CUCM?

11 Replies 11

MapleLeaf
Level 1
Level 1

What you need is a SIP profile on the DP to CUCM to remove the funky CVP stuff that get's added. Here's a sample that you can alter to your needs:

Add this sip profile in the outgoing dial-peer to CUCM on the ingress CUBE/Gateway .

Copy the display name from the
"Remote-party-ip" header or "From" header in the Sip invite message from
Ingress gateway to CUCM


voice class sip-profiles 1
request INVITE sip-header From modify "--CVP_8_5_1_0_0_0_1440(.*)" "\1"
request INVITE sip-header
Remote-Party-ID
modify "--CVP_8_5_1_0_0_0_1440(.*)" "\1"
!

change --cvp with the output from your invite header

Thanks, that makes in the inbound dial peer part easier. I wonder if having the serviceability service attached to that dial peer for calls going to CUCM adds any overhead or CPU to the gateway. I am still debating other ways to to identify which calls should go to CVP/CCE. I guess an option I hadn't considered is to try and route all calls to CVP first. If CVP doesn't have a dialed number for it, it should return 404 and then I could fail over to the CUCM facing dial peer.

I don't think this method will work, because when the call it sent to CVP/ICM and there is no configured route, the survivability script will kick in on the failure and take over call control to play the male error message. I've always done these setups exactly how you have it right now. All of my CC numbers point to CVP and personal DIDs, etc are sent to CUCM. I like to use e164 pattern maps to manage the phone numbers.

If you do go ahead with testing the 404 method, let me know how it pans out. I am curious to know if it will work or not.

Thanks, good to know I am not out in left field! I am leaning towards trying to centralize the number list for the pattern map into a URL as @Jonathan Schulenberg suggested and then refreshing the pattern map via kron as @Roger Kallberg suggested. that should be fairly easy to accomplish.

@MapleLeaf 's approach is the way to go IMHO, have two pattern map files, one for calls you're sending to UCM and one for the calls to CVP/UCCE.

Dmytro Benda
Spotlight
Spotlight

Hi @Elliot Dierksen , 

Why don't you simply separate the inbound dial-peer selection with incoming called-number command? To reach the CVP and CUCM the customers dial different called numbers, right? So you can configure let's say two different inbound dial-peers with different incoming called-number masks. One of them (for CVP) will have service survivability, while the second inbound dial-peer (for CUCM) will be without survivability.  

My Cisco Unified Communications Blog

I do have separate peers now. I was debating trying to minimize that which is what prompted the question. I think I am going to stay with the pattern map and different incoming peers.

How many dial peers are we talking about here? With the suggestions at hand and with what you have outlined, ie two target systems, CVP and CM, it seems like you could come away with four dial peers in total. Two inbound with inbound called number match with e164 maps and two outbound with server group objects that includes the CVP or CM servers. You can as well use DPGs to send the calls to the outbound dial peers based on the inbound dial peer. That way you would have a very deterministic call path.



Response Signature


Yes, it is 4 dial peers we are talking about. I have a pattern map for specific ones that go to CVP/CCE, and everything else goes to CUCM. For this customer, they have close to 40K numbers. The big question was if there was a better way then the pattern map since CUSP is no longer an option. I am leaning towards making the source of the pattern map in the 20+ gateways be a URL and then using kron in the routers to refresh that pattern map periodically.

Come to think about this I might have oversimplified the dial peers somewhat. Likely you would need a few more dial peers for inbound from CM and possibly CVP, I don’t know how that system operates to know for sure, and then outbound dial peer(s) towards PSTN. It all depends on what you use the SBC for. For any inbound dial peers coming from something where you don’t need to separate the inbound match I would recommend you to use the VIA header for the match.



Response Signature


Personally, we do the voice class e164-pattern-map load to refresh the pattern map when a change is made like adding a new number. Your suggestion of a job makes sense since you have a number of gateways, but to me the challenge then is what happens if someone loads it early (i.e. CUBE resource is ready but contact center resource isn't done). Doing the refresh manually gives you more control, lets you test with one, etc., but just my personal preference.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: