CUCM-SIP normalization script doesn't support integer operations

[awrabek]

We want to check if the user portion of the From in the INVITE to be sent out can be found the the number ranges defined in "ranges" set. If not, insert a predefined Diversion header into the INVITE, otherwise leave the outbound INVITE intact.

Cisco's dev guide says that only string lib is supported. Does that mean casting from string (type of uri:getUser() value e.g.) to integer is not possible? Similarly, are operations with integers not supported?

This was my initial idea (user part of URI in From doesnt have + prefix):

ranges = {
                    [121200005000] = 121200005999,
                    [15630000300] = 15630000399,
                    [4400000700] = 4400000799
}

checknum = 0
    
M = {}
function M.outbound_INVITE(msg)
local uriString = msg:getUri("From")
if uriString then
    local uri = sipUtils.parseUri(uriString)
    if uri then
        checknum = uri:getUser()
    end
    
local hit = false
    
for key,value in pairs(ranges) do
    if (checknum >= key and checknum <= value) then
        hit = true
        break
    end
end
    
if not hit then
    msg:addHeader("Diversion", "<sip:+121200005000@10.10.10.1>;reason=unconditional;privacy=off;screen=yes")
end

end
return M

From sample (shouldnt match any range:

From: <sip:1212000060011@10.10.10.1>;tag=365838385~61bc9044-c485-4615-8ebb-2c3827eec136-69722555

[Elliot Dierksen]

What are you trying to accomplish? There might be a different way, but it would be helpful to know what call routing goal you are trying to achieve.

[awrabek]

There is the following situation:

We had our own fax server on the site and we propagated our fax numbers to customers, suppliers, etc.

Fax server has been decommed and now we have a 3rd party provider who does fax to email service to us.

However management doesnt want to advertise the new fax numbers to our customers because they are used to the current ones.

We configured route patterns that mask outgoing number to the one we got from the 3rd party provider.

call flow:

ITSP--sip-->CUBE--sip-->CUCM(route pattern)--sip-->CUBE--sip-->ITSP

CUBEs are the same in the call flow

Since this is not a call forward, there is no Diversion header inserted into the INVITE back to the ITSP. In the From and PAI field there is a number out of the assigned DID range and there is no Diversion, so provider cannot validate the source of the call and bill accordingly.

It could be done on the CUBE with multiple dial peers and URI classes, but normalization script would be more centralized, since this is a GSIP CUBE serving multiple locations.

[b.winter]

But in this scenario, there won't be a Diversion header at all and adding one to it isn't the "fine" way.

For normal outgoing call, SIP providers validate a call against the FROM and in the second step, the PAI header. So, if the FROM contains a number not from your DID range (e.g. if an external calls and internal number --> forwards back to external), then the provider validates the PAI header, because the FROM number cannot be a DID range number.

So, why don't you just set the PAI header for every call to a fixed number?
I always set it to the main number + 0.

And if you have multiple DID ranges, you have to have a call routing mechanism in place already, to assign outgoing calls to the correct sip trunk.
I have written something about this mechanism here: https://community.cisco.com/t5/collaboration-knowledge-base/multiple-sip-trunks-on-cube-uri-based-dial-peer-matching/ta-p/4562385

[TechLvr]

I agree with both Elliot and b.winter's suggestions but if that is not possible then here is my recommendation. 

I think this can be done easier on the CUBE than CUCM. You will only need 1 new dial peer to cover all fax numbers using e164 pattern map. The idea is to xlate old fax numbers to the new fax numbers and then add a diversion header with a predefined number in the SIP invite when the invite contains a new FAX number. Also, this configuration enables the CUBE to route calls directly back to ITSP without the need for the CUCM. 

Call Flow 
ITSP ---(Old Fax Number)---->CUBE ---- New Fax Number w/ Diversion Header--->ITSP

Now, let's assume your fax numbers are as below:

Old Fax numbers (Known by customers)
2223334444
2223335555
Or a range of DIDs such as 222333....

New Fax Numbers (Not known by customers)
1212000060011
1212000060012
or a range of DIDs such as 121200006....

You will need to the add the following sample configs to your CUBE. Make sure to replace my sample DIDs and IP addresses with the actual ones.

voice class sip-profiles 100
request INVITE sip-header Diversion add "Diversion: <sip:+121200005000@10.10.10.1>;reason=unconditional;privacy=off;screen=yes"

voice class e164-pattern-map 100
e164 2223334444
e164 2223335555
e164 222333....
#####List all your old fax numbers here

voice translation-rule 100
rule 1 /2223334444/ /1212000060011/
rule 2 /2223335555/ /1212000060012/
rule 3 /222333(....\)/ /1212000060013/
######This rule translates your old fax numbers to the new fax numbers.

voice translation-profile OldToNewFaxNo
translate called 100

dial-peer voice 100 voip
description ** To_ITSP**
session protocol sipv2
destination e164-pattern-map 100
translation-profile outgoing OldToNewFaxNo
voice-class sip profiles 100
session target ipv4:111111
g711ulaw
voice-class sip bind control source-interface Loopback0
voice-class sip bind media source-interface Loopback0
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback pass-through
dtmf-relay rtp-nte
no vad

[Elliot Dierksen]

If it is SIP, why don't you just redirect the numbers in the ITSP's portal (assuming they have one). Then the numbers never touch your CM. However you do this in CM, you would be tying up 2 talks paths for the duration of the fax calls.

[awrabek]

This could be the simplest solution. I will check it with our provider.

Nevertheless, are integer operations allowed in Cisco's lua implementation in CUCM? Looks like only string operations are supported and CUCM ignores the integer ones. To be honest, the dev guide I linked in the post is not clear to me in terms of this.