I’ve been working as design and deployment lead on a globally significant full Collaboration on-premise deployment for the last 3 months (think 120 CUCM across 9 Leaf Clusters on 101 UCS C240’s) that’s been keeping me quite busy 🙂
As part of the deployment design phase, a decision was taken to centrally host Unity Connection for all 9 Leaf Clusters. As I commenced with the dial plan design, while I reviewed the business requirements I identified a call flow that I knew would immediately create a problem. Some like a board, pen and paper or even spreadsheets for call routing – I like to do these in my head as I jot down the configuration elements in notepad++. Your preferred method is irrelevant – the point is always to model your call flow design prior to implementation – with the intention to find inherent call flow failures.
The client had a strong use case for a proxied manager configuration, with a secretary available to take calls on their behalf. There are a number of ways to configure this, but from a routing perspective, a separate partition is always required for the manager, with reach-ability only from the secretary’s CSS.
The Challenge:
- Call flow required is CUC > SME > Leaf > Manager Phone
- MWI is routed from CUC via an Out-of-Dialog SIP NOTIFY
- In the CUCM SIP construct, this uses the same Inbound CSS as a standard call
The Likely Result:
- The manager’s MWI will never light up – no reach-ability in the inbound CSS without violating an inter-cluster proxied routing requirement
- Depending on your configuration, the proxied line on the secretary’s phone is probably going to light up instead!
The requirement is not unique, but the advent of SIP, and wanting a scale-able solution posed a challenge.
Due to the scale of deployment and tight timelines, our local SE was kind enough to arrange some time with a BU dial plan specialist to review my dial plan design, with some recommendations along the way (what an awesome experience!). I was keen to pose my dial plan issue to the BU, as I was quite sure that a special method would be needed to accommodate this.
After some discussion, a Lua script was proposed. I was quite keen on the idea, as I’ve had some experience writing these before. The call flow idea was actually quite simple:
- CUC > SME > Leaf (end-to-end SIP)
- SIP Normalization Script (on Leaf Trunk) > Custom Routing Prefix on Manager DN (think “**”)
- Translation Pattern (PreDot strip with correct re-prefixing) > Custom CSS with prioritization of Manager Partition(s)
The BU provided me a script for a similar case, which I customized to support my requirement:
–[[
Author : Jonathan Els
Description:
Script for separate handling of MWI to accommodate proxied partitions for centralized voicemail designs with SME – e.g. with Proxied Manager/Secretary configurations
Script strips initial chars (“0” hard-coded in this script) to add a prefix for custom routing
Future development:
1. Add contextual checks to specifically limit to MWI – possible matching on Content (“Messages-Waiting” etc.) or CUC source address could apply
1. Use prefix as script param.
–]]
M={}
trace.enable()
function M.inbound_NOTIFY(msg)
— Set prefix for MWI
prefix = “**”
— Need to convert E.164 to **-prefixed string in request URI and To header
local m,r,v = msg:getRequestLine()
r=string.gsub (r,”sip:0(%d*)@”, “sip:” .. prefix .. “%1@”)
msg:setRequestUri (r )
local t = msg:getHeader(“To”)
t=string.gsub (t,”sip:0(%d*)@”, “sip:” .. prefix .. “%1@”)
msg:modifyHeader (“To”, t)
end
return M
In our dial plan, we deviated from the +-E.164 CVD best practice due to a limitation on the client’s billing system. We preferred localized DID’s instead. As a result, the above script uses the following pattern match:
sip:0(%d*)@”
Without excessive deviation, if your call routing requirement dictates the need for Lua scripting, please take the time to understand Lua Pattern Matching. Lua’s about *speed*. Regex is damn slow.
During testing, I hit a snag and reached out to the BU once again…
Looking at SDL showed the script to be working:
00240075.000 |17:09:45.622 |SdlSig |SIPNormalizeReq |wait |SIPNormalization(2,100,78,1) |SIPHandler(2,100,79,1) |2,100,14,91.8^192.168.116.12^* |*TraceFlagOverrode
00240075.001 |17:09:45.622 |AppInfo |//SIP/SIPNormalization/trace_sip_message: After inbound SIP Normalization msg is:
[20427,INT]
NOTIFY sip:**111001001@192.168.116.21:5060 SIP/2.0
Date: Wed, 24 Jun 2015 15:09:45 GMT
From: <sip:voicemail@192.168.116.12>;tag=36349161
Event: message-summary
Content-Length: 23
User-Agent: Cisco-CUCM10.5
To: <sip:**111001001@192.168.116.21>
Contact: <sip:voicemail@192.168.116.12:5060;transport=tcp>
Content-Type: application/simple-message-summary
Call-ID: ad6c800-58a1c839-13de1-c74a8c0@192.168.116.12
Subscription-State: active
Via: SIP/2.0/TCP 192.168.116.12:5060;branch=z9hG4bK13ecf35a0eda8
CSeq: 102 NOTIFY
Max-Forwards: 70
Messages-Waiting: yes
However, I soon found that the standard digit analysis engine was not being applied. The TP’s in my CSS’s were not being matched! I actually confirmed this by configuring my expected pattern – **111001001 – on an entirely different phone and watched its MWI light up.
The BU suggested that I try setting the Advanced CallManager Service Parameter Multiple Tenant MWI Mode to “True”. In our initial discussions, I’d been informed that this was not required in the SIP Trunking use case, but this ultimately did not prove to be the case. After doing this, the translation pattern kicked in and that elusive MWI lit up immediately.
