cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2305
Views
10
Helpful
4
Replies

Unsolicited SIP Notify for MWI not routed correctly in CUCM

Rob Wilson
Level 1
Level 1

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.

4 Replies 4

Rob Wilson
Level 1
Level 1

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

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"

Please rate all useful posts

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

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"

Please rate all useful posts