Lua Scripting – Proxied Manager Breaks MWI for Centralized CUC Behind SME

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:

  1. CUC > SME > Leaf (end-to-end SIP)
  2. SIP Normalization Script (on Leaf Trunk) > Custom Routing Prefix on Manager DN (think “**”)
  3. 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.

Advertisements

2 thoughts on “Lua Scripting – Proxied Manager Breaks MWI for Centralized CUC Behind SME

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s