04-17-2013 05:34 AM - edited 03-16-2019 04:51 PM
Hi,
I'm running CUCM 9.0.1 and have noticed a couple of problems with unsolicited SIP Notify messages for MWI:
1) A translation pattern containing the '!' digit results in 404 Not Found response
2) It is not possible to route next hop by calling party number with Notify messages
Ignoring route next hop by CgPN for now, in the first case I have a catch all TP in a partition that is hit when MWI comes in. e.g 201!, which points to the CSS containing the partition where my DN, 2017000, is located.
I always get 404 Not Found returned when there's a ! character anywhere in the TP. If I change the TP to 201XXXX, or 2017XXX or anything similar the MWI is routed perfectly (and I get 200OK back)
Has anyone managed to get a Notify routed when using the ! character?
For the second case, I wanted to route the MWI based on calling party number (i.e. From: header) instead of called party, but this simply doesn't work. If I send an Invite with the same To: and From: fields I can see the call being routed perfectly, but if I send a Notify I get 404 Not Found, which implies that A number routing doesn't work for Notify. Can anyone confirm that to be the case? I can't find any documentation that says as much.
I have a TAC case open for this and I'll post the findings if I hear back, but in the meantime has anyone had any success with these two issues?
Thanks
-Rob.
04-26-2013 08:04 AM
So, TAC case opened...investigated...and closed. Working "as designed" by all accounts.
Well, a couple of things about that:
1) The issue with the '!' character was that Urgent Priority had to be checked. Fair enough I suppose...
2) Routing on Calling Party Number is not supported for SIP Notify...by design, even though this works in other Cisco products, such as the PGW2200
From my investigations I've determined that MWI looks only at the NOTIFY URI, so not the To:, From: or Contact: headers.
In order to route on calling party number you'll have to write a SIP Normalization Script to take the URI from the From: header and insert it into the request URI, which I've done. Drop me a message if you need assistance.
-Rob
04-26-2013 08:55 AM
Rob..Great Job and thanks for updating us..
Few questions for you..Just to get the picture clearer and learn from your scenario
1. What is your setup and why do you want to send MWI to a variable pattern?
2. Why do you want to send MWI to calling number..I guess by default MWI is for called number..
3. Can you share your normalization script?
Please rate all useful posts
"opportunity is a haughty goddess who waste no time with those who are unprepared"
04-29-2013 01:02 AM
The reason for the MWI 'weirdness' is that the CUCM is being used in a multi-tenant environment, as is the voicemail platform (not UnityConnection or a Cisco product at all...)
A customer on the platform is identfied by the pilot number that they use to call the VM platform. When a user at a customer has a message waiting, the VM platform sends the MWI from the same pilot number to the DN.
The DN alone is not necessarily unique to the customer, so it is necessary to route the MWI based on the calling number (i.e. the VM pilot number) as well as the directory number: Calling Party Number in MWI MOTIFY identifies the customer, Called Party Number in MWI NOTIFY identifies the user.
The reason for using the '!' digit is that I was using Route Next Hop by Calling Party Number, so you need to catch all Called Party Digits first.
My normalization script is below. It takes two parameters as input: CPID-Length and RID-Length. I won't go into too much detail, but essentially the sum of those two is the length of the unique part of the Calling Party Number that identifies a customer. The script takes the first n digits of the From: field and prefixes them to the Notify URI:
M = {} -- Import CPID and RID lengths local CPID_len = scriptParameters.getValue("CPID-Length") local RID_len = scriptParameters.getValue("RID-Length") function M.inbound_NOTIFY(msg) -- Process inbound NOTIFY message -- Get the From header local From_header = msg:getUri("From") if From_header then -- Parse the uri in the From header local From_uri = sipUtils.parseUri(From_header) if From_uri then -- Extract the CgPN local CallingPN = From_uri:getUser() if CallingPN then trace.format("Calling Party Number %s", CallingPN) local VMCPIDRID = string.sub(CallingPN, 1, CPID_len + RID_len) trace.format("VM CPID + RID %s", VMCPIDRID) -- Process the Request URI local method, ruri, ver = msg:getRequestLine() -- Modify the Request URI to prefix the VMCPID + VMRID local modified_ruri = string.gsub(ruri, "%d+", VMCPIDRID.."%1", 1) trace.format("Updated ruri %s", modified_ruri) -- Change the NOTIFY Request URI msg:setRequestUri(modified_ruri) end end end end return M
04-29-2013 08:08 AM
Thanks Rob..Thats a beast of a script you have there..great job.
Please rate all useful posts
"opportunity is a haughty goddess who waste no time with those who are unprepared"
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide