Back to blog
Blog , How-To

Controlling Multi-National Telecom and ISP Selection within CUCM

Eric Lavoie Eric Lavoie August 27, 2020

For multinational organizations, utilizing telecom and internet service providers that are country-specific can be crucial. Whether it’s due to data sovereignty laws specific to particular industries, to compliance standards, and more—where UC “connects” should be addressed. For example, if a company has multiple offices in the US along with multiple offices in Canada, voice and video services should be handled by ISPs in the respective countries—meaning all US offices connect to American ISPs, and all Canadian offices connect via ISPs within Canada.

Here’s how this can be achieved within your CUCM infrastructure.

On CUCM
Create 1 SIP Trunk Security Profile per Provider:

  • For the first provider let the incoming port to 5060
  • For the next providers choose a different incoming port (ex.5070, 5071, etc.)incoming port

Add a new Normalization Script

M = {}

function M.outbound_INVITE(msg)

— Get CUCM Trunk parameter

local provider = scriptParameters.getValue(“Provider”)

— Get URI from Request Line

local method, ruri, ver = msg:getRequestLine()

— Add Provider info to RequestURI

msg:setRequestUri(ruri..”;dtg=”..provider)

end

return M

Create 1 SIP Trunk per Provider:

  • Create your trunk as usual
  • Assign the appropriate SIP Trunk Security Profile
  • Assign the Normalization Script and add the parameter “Provider.” In the value field enter a unique name per trunk (ex. Verizon)Assign the Normalization Script and add the parameter

Build your Route Group, Route List, and Route Pattern as per your needs.

On CUBE

The differentiator factor between Trunks is now the Request URI. We now need to match our incoming calls on the SIP URI.

SIP URI will look like this:

INVITE sip:+15149401480@<CUBE IP or FQDN>:5060;dtg=Verizon SIP/2.0

“;dtg=Verizon” is added by the script

To match on SIP URI, we need to define a voice-class uri <name> sip and instruct CUBE to look for the pattern “Verizon.”

voice class uri Verizon sip

pattern Verizon

At dial-peer level we need to tell CUBE on which header to test the pattern. In this case, “request” what we want to evaluate.

dial-peer voice 1 voip

description ** Incoming – CUCM to CUBE for Verizon **
session protocol sipv2
incoming uri request Verizon

 

Once the incoming is match, we now have couple of options for the outbound call leg.

I prefer to use the “destination dpg” technique, but you can certainly use an incoming voice translation profile to modify the called number and route the call accordingly.

Need help? Drop us a line!

Ready to take your unified communications from headache to hassle-free?

No throwing darts at proposals or contracts. No battling through the back-end. No nonsense, no run-around.