Modify Diversion history

I ran into a challenge with a customer after upgrade from CUCM 8.6 to 11.0 and Mitel CMG from 7.5 to 8.2.

They have a flow where a caller calls a CTI-Port which during opening hours has a CFUR to a hunt-pilot. The hunt-pilot has a CFNA/CFB to the CMG IVR.

The diversion history becomes quite interesting here;

Diversion: <sip:huntpilotno@10.x.y.z>;reason=no-answer;privacy=off;screen=yes,<sip:ctiportno@10.x.y.z>;reason=out-of-service;privacy=off;screen=yes

The issue that arises is that we will look at the first redirecting number (ctiportno), which – technically speaking, actually has a very correct reason (out-of-service). So, to be able to determine the cause for this forward after hitting the hunt-pilot, we would have to look at the last redirecting information – but, that is another number, and we will run into issues matching that to the subscriber in CMG.

In order to use the last redirecting cause, but still rely on the first redirecting number, I applied a LUA-script to the trunk.

M = {}
 
function M.outbound_INVITE(msg)
    local diversion= msg:getHeader("Diversion")
    if string.find(diversion, "reason=") then
      startDivCause_str = string.find(diversion, "reason=")
      endDivCause_str = string.find(diversion, ";", startDivCause_str+1)
      divCause_str = string.sub(diversion, startDivCause_str, endDivCause_str)
      changedDivCause_str = string.gsub(diversion, "reason=out%-of%-service;", divCause_str)
      msg:modifyHeader("Diversion", changedDivCause_str)
    end
end

return M

This script will look if there is a reason within the Diversion and if so, search for the first occurrence (last redirecting pty) and then make a search and replace for reason=out-of-service with whatever the first reason is.

The diversion header in a call which does not get answered by the hunt will now look like this when hitting the CMG;

Diversion: <sip:huntpilotno@10.x.y.z>;reason=no-answer;privacy=off;screen=yes,<sip:ctiportno@10.x.y.z>;reason=no-answer;privacy=off;screen=yes

Some helpful resources;

NeTS failure on call from Jabber Softphone

NeTS version 5.8.2.9 will not accept calls from Jabber in softphone-mode. Failure from NeTS is a bit cryptic;

|SIP           |SipNclaHandler::ExtractCallInfo          |D0828412 |<-- EXITING METHOD THROUGH NICEEXCEPTION:NICEEXCEPTION: 0XFFFFE052 INVALID SIP ADDRESS, SIPADDRESS=  ||SipNclaHandler.cpp|388
|SIP           |.x1_D0828412-csmState::UpdateContextFrom |         |<-- EXITING METHOD THROUGH NICEEXCEPTION:NICEEXCEPTION: 0XFFFFE052 INVALID SIP ADDRESS, SIPADDRESS=  ||SIPCallCtrlSM.cpp|947
|SIP           |csmsuper::HandleEvent                    |         |CAUGHT EXCEPTION HANDLING SIPREQUEST. NICEEXCEPTION: 0XFFFFE052 INVALID SIP ADDRESS, SIPADDRESS= ||SIPCallCtrlSM.cpp|585
|SIP           |TrProcessSipProviderMessage              |         |_COM_ERROR: _COM_ERROR: HRESULT: 0X80004003(INVALID POINTER  ), INVALID POINTER,  ||TrProcessSipProviderMessage.cpp|85

When comparing the SIP INVITE from a Jabber softphone and a 9951, the following difference was encountered in the header;

Contact: <sip:7009@10.x.y.z:5060;transport=tcp>;video;audio;+u.sip!devicename.ccm.cisco.com="CSFMLUNDBOM";bfcp

The INVITE from the 9951 had only;

Contact: <sip:7009@10.x.y.z:5060;transport=tcp>;video;audio

Most likely, the +-sign is not interpreted correctly. The easy workaround here is to utilize the SIP-normalization rules and clean up the Contact-header (I can’t see any cases where this information would be relevant for NeTS).

Within CCMAdmin, go to Device, Device Settings and SIP Normalization Script. Click Add New. Give it a name, description and enter the following in Content;

M = {}
 
function M.outbound_INVITE(msg)
    local contact = msg:getHeader("Contact")
    local uri = string.match(contact, "(<.+>)")
    msg:modifyHeader("Contact", uri)
end

return M

Apply the script to your SIP-trunk heading to NeTS;

Capture

..and reset the trunk.

The result here is that regardless what extra flags is present in your Contact-header, only the content included within <> is sent over the trunk.

With this workaround, NeTS accepted the Jabber calls without issues.