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.)
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)
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.