Need help to modify SIP normalization script to change HISTORY-INFO header into a DIVERSION header

[voip7372]

Does anyone have experience successfully editing the SIP normalization scripts to modify certain information in calls coming in from a server (calls from MS Lync 2013 server in this case)? I think the solution to our problem is simple, but I'm not familiar with these Lua scripts and I need some help to correctly modify the 'lync_interop' script that Cisco provides on their support web site. We've been using this script applied to our CUCM SIP trunks that connect to the Lync server with good results but there are two types of calls from Skype that fail.

I will attach the existing SIP normalization script that we've been using.  This is the one we got from Cisco HERE.

Call flow looks like this (if you're curious):
Incoming call from Verizon SIP trunks on CUBE to CUCM > CUCM phone device forwarded to Skype/Lync server using the user's Skype Line URI > User has Skype client set to use simultaneous ring or 'unanswered calls will go to' option enabled which sends the call back to CUCM (to ultimately go back out to Verizon) > CUCM receives call from Lync server > CUCM sends call to CUBE router for Verizon because the number is an external number > CUBE sends call to Verizon SIP trunks.

Below are two call examples with HISTORY-INFO headers that came from the Lync server to CUCM. The first one is correctly modified by the script, but the other one is not modified and the call fails once it hits Verizon SIP trunks (PSTN).

History header generated by Lync server when the user has 'Forward my calls to' option enabled in the Skype for Business client. This call woks fine - it's converted to a diversion header by CUCM.  Looking at the script, I see info in the script that apparently is looking for specific info like ms-retarget-reason=forwarding in the SIP message that has the history header so I think that's why this one is working (because the script finds this message and successfully modifies it).  FYI: 16145551212 is a fake number for the purpose of this posting in public and that would represent the internal user's valid Verizon DID number and that's the party that was originally called. 18585559999 is also a fake number for the purpose of posting here in public on the forum and that number represents the party that's actually calling in (original external calling party):

HISTORY-INFO: <sip:+16145551212;ext=5551212@SERVER-HOSTNAME.DOMAIN.COM;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20Temporarily%22>;index=1;ms-retarget-reason=forwarding,<sip:+18585559999@SERVER-HOSTNAME.DOMAIN.COM;user=phone>;index=1.1

Next, the history header generated by the Lync server when the user has 'simultaneous ring' or 'Unanswered calls will go to' enabled in the Skype client. This call fails because the HISTORY-INFO header is not converted to a diversion header in CUCM and therefore, when CUCM sends the call to our Verizon SIP trunks, Verizon rejects the call because the calling party number appears to be the original calling party which is an external party, rather than the internal party that was called. The internal party has a Verizon DID number assigned and that is the number we want to present in a diversion header to Verizon. Again, 16145551212 is a fake number for the purpose of this posting and that would represent the internal user's valid Verizon DID number and that's the party that was originally called. 18585559999 is also a fake number for the purpose of posting here in public on the forum and that number represents the party that's actually calling in (original calling party):

HISTORY-INFO: <sip:+16145551212;ext=5551212@SERVER-HOSTNAME.DOMAIN.COM;user=phone>;index=1,<sip:+18585559999@SERVER-HOSTNAME.DOMAIN.COM;user=phone>;index=1.1

What we would like to do is this:
1. Leave all the other information in the SIP normalization script so we don't break anything else that this script normally does for Skype/Lync to CUCM calls.

2. ADD information to the script so that the script will look for the more generic form of the HISTORY-INFO header from Lync and convert that into a diversion header (keeping the same info the HISTORY-INFO header had, but now it's a diversion header instead of a history-info header. That will solve the problem of failed calls going out to our Verizon SIP trunks because the diversion header will tell Verizon the call is a diverted call from a valid Verizon number we own.

If you're familiar with how to do this and would be able to help me come up with the exact text to add to the script and exactly where in the script to place it, I would be greatly appreciative!  I've seen the 'Developer Guide for SIP Transparency and Normalization' Cisco page already but it's not very clear on how to do what I need.  Hopefully someone else has already been through this and knows exactly what to do in this case.  

[voip7372]

FYI.    

I see a basic example for history to diversion changes on Cisco's site. Is this REALLY all we need?  Remove the other more specific entries related to changing history-info headers into diversion headers and replace it with this (exactly the text that is in the Script section below and nothing else???   The original script Cisco provides is much more complex and has a lot more information in it that seems to be related to the history-info headers being changed to Diversion headers and I'm just not exactly which pieces to remove from that existing script and add the new text below (in that example below). 

For example, since tehre's already a M = {} at the beginning of the script and a return M at the very end, if we were to add this new more general version of a script to change history-info into a diversion header, maybe we only need this part added into the script somewhere?   (see how it gets confusing? :-)):

M.allowHeaders = {"History-Info"}
function M.inbound_INVITE(msg)
msg:convertHIToDiversion()
end

Cisco's developer guide example:

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/sip_tn/8_5_1/sip_t_n/3-sip_msg.html

convertHIToDiversion
   convertHIToDiversion()

Cisco Unified CM supports receiving the Diversion header for handling redirecting information. For example, when a call is forwarded before reaching Cisco Unified CM. In such a case, the SIP message may contain a Diversion header which is used by Cisco Unified CM to establish the redirecting number. However, many SIP servers use the History-Info header for this purpose instead of the Diversion header.

Note: Some implementations may require use of the raw header APIs (e.g. getHeader, addHeader, modifyHeader, and removeHeader) instead of or in addition to this API.

Example:

The allowHeaders must specify "History-Info". Without it, the incoming History-Info headers will get dropped before script processing. Thus the call to convertHIToDiversion won't produce any useful results.

Script:

M = {}
M.allowHeaders = {"History-Info"}
function M.inbound_INVITE(msg)
msg:convertHIToDiversion()
end
return M

SIP Message Example:

INVITE sip:1001@10.10.10.1 SIP/2.0
.
History-Info: <sip:2401@10.10.10.2?Reason=sip;cause=302;text="unconditional">;index=1
History-Info: <sip:1001@10.10.10.1>;index=1.1

Result from message example above:

INVITE sip:1001@10.10.10.1 SIP/2.0
.
Diversion: <sip:2401@10.10.10.2>;reason=unconditional;counter=1
History-Info: <sip:2401@10.10.10.2?Reason=sip;cause=302;text="unconditional">;index=1
History-Info: <sip:1001@10.10.10.1>;index=1.1

[voip7372]

EDIT:  Disregard this idea below because I just tested to see what shows up in CUBE and that history-info header is not showing up in CUBE because I think that header gets removed by CUCM before the call goes to CUBE.  So, I think whatever I do to fix this, it will likely need to be in that script in CUCM that's applied to the SIP trunks connected to the Lync/Skype servers...so, I still need help with that :-)

As an alternative, I could use the SIP profile settings in our CUBE router to change the info, but at first glance I'm not sure of the correct entry/entries.  I already have entries in CUBE that modify info in various headers before the call goes to Verizon, but in this case I would need to look for a history-info header in a SIP message and then copy the contents of that header and ADD a diversion header with that info.   I think that would work fine.  

For example, if we see the history-info header below:

HISTORY-INFO: <sip:+16145551212;ext=5551212@SERVER-HOSTNAME.DOMAIN.COM;user=phone>;index=1,<sip:+18585559999@SERVER-HOSTNAME.DOMAIN.COM;user=phone>;index=1.1

Change that to a diversion header or simply ADD a diversion header to that same SIP message (Invite for example):

DIVERSION: <sip:+16145551212;ext=5551212@SERVER-HOSTNAME.DOMAIN.COM;user=phone>;index=1,<sip:+18585559999@SERVER-HOSTNAME.DOMAIN.COM;user=phone>;index=1.1

Is it possible?  If so, please let me know if you can provide some guidance on the correct entries in CUBE to do this (under our existing SIP profile).  

Thanks

[voip7372 · Accepted solution]

Just a little update on this.  It turns out that the script from Cisco is just fine.  I found the problem is with the Skype for Business / Lync 2013 server and/or the Skype for Business mobile app on someone's mobile phone. 

If I SIGN OUT of my Skype for Business mobile app on my iPhone, suddenly ALL types of forwarding and simultaneous ringing from Skype works perfectly (CUCM correctly recognizes the diversion via the history-info header and it inserts the diversion header as it should, because of the script).  It will simultaneously ring my mobile number if I want it to, it will forward to my mobile number if I want it to, it will also forward to my mobile number after X seconds if I set the 'Unanswered calls will go to' option in my Skype app to go to my mobile number.  Everything works perfectly.

What we learned was that Skype for Business / Lync 2013 server had 'Simultaneous Ring' stuck on.  Even when we disabled the simultaneous ring, it still keep doing it.  Finally, I had the idea not to just shut down the mobile app, but to SIGN OUT of the mobile app...then it works perfectly.  So, for some reason the mobile app is causing Skype to simultaneously ring constantly even if we have it turned OFF.  

So, there's some kind of bug or problem with Skype for Business and that mobile app or the Lync 2013 server.  One or the other or both.  Either way, now I know what's causing this problem and I don't need to edit the script (my original reason for this posting) because the script is working fine.