matching dial-peers for multiple SIP providers

[kdotten36]

Looking for some advice on dial-peer configuration after adding a secondary SIP provider. This is not a redundant ITSP, it's for separate calls.

I've tried creating dial-peer provisioning policies to match destinations by URI and it has worked for inbound calls from ITSP. Each has its own inbound leg peer which can couple with its outbound peer to CUCM. From CUCM is the problem since all outbound calls go through the same SIP Trunk / IP. The SIP header Via/From is the CUCM and the Request/To is the CUBE IP configured for the SIP trunk.

The only difference is the set of DNs linked to each provider. ITSP2 has a much smaller pool and simpler to define.

My most recent attempt was to match by incoming calling e164-pattern-map which worked for inbound from CUCM leg but matched nothing outbound for the same destination calling e164-pattern-map

Here is that config without various sip options...

dial-peer 8001 voip
desc CUCM IN ITSP1
incoming calling e164 1

dial-peer 9999 voip
desc ITSP1 OUT
destination calling e164 3

dial-peer 2002 voip
desc CUCM IN ITSP2
incoming calling e164 2

dial-peer 2003 voip
desc ITSP2 OUT
destination calling e164 2

voice class e164 1
 desc ITSP1 DIDs
 e164 1...
 e164 7...
 e164 410.......
 e164 202.......
 e164 703.......

voice class e164 2
 desc ITSP2 DIDs
 e164 410555....
 e164 26..

voice class e164 3
 desc Match Any
 e164 .

With this config, calls from CUCM match the correct inbound dialpeer but fail to match any outgoing.

This only affects calls originating from CUCM. Incoming calls from ITSP2 work correctly somehow, although I think they're just bouncing around and failing until they pick the right outbound interface. (dial-peer 9999 is set for a destination-pattern . in production but I remove it to test the 'destination calling').

Any suggestions are appreciated. Even throwing away this plan and do something different is cool. On the inbound leg, I'm matching URI via with provision-policy for outbound leg.

[Chris Deren]

Use different steering codes on CUCM. If specific calls need to go out via one SIP turnk i.e. LD and Intl then you globally prefix/change the code via transformation pattern on the SIP trunk in CUCM, if you need to use different SIP trunk based on who is calling then you will need to have different CSS/PTs and prefix/change digits at the route pattern level for example. Then on the CUBE match outbound dial-peers based on the different destination-pattern.

[kdotten36]

I've been trying to avoid messing with CUCM because I want the change to be invisible to users.

The situation is that we've procured an Internet-based SIP provider and some people have concerns about the lack of true QoS. Our other provider is a LEC. So the plan is to keep our mission-critical users on the LEC while we monitor staff/etc ported to the new ITSP. My only real opportunity for logic is rerouting based on which DID is placing the outbound call or which ITSP owns their number.

I considered moving everyone within the target range to a new CSS but it seemed aggressive to invite so many potential points of failure in CUCM. I was hoping to find a solution in CUBE before conceding to a full dialing plan alteration internally. I've already lost more hours than I care to admit trying to tinker the DPs though, so I may just have to cave and do that if I don't find a miracle here.

Thanks for the reply.

[Daniele Giordano]

I'm not sure to have correctly understood your problem.

Anyhow, do you have already tested the voice source group feature?

http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/116440-configure-vsg-00.html

The routing is based on the IP address of the source.

Regards.

[kdotten36]

I have not toyed with a voice source group but, unfortunately, all calls originating from CUCM have the same source and destination IP, hence my problem. Call legs originating from ITSP have different IPs so I've been able to isolate those by matching VIA headers and destination URI.