UUI with CCX. Migrating from ISDN TCL to SIP

[eschroederJH]

I've got a current deployment where we have a UCCX cluster configured with inbound agent screen pops triggered by UUI data that comes in with calls to an ISDN gateway. The ISDN gateway has a TCL script on the inbound dialpeer - the script uses GTD infotags to scrape the UUI data from the ISDN setup headers and tacks it on to the end of the DNIS so that CCX can access it. That TCL script checks to see if that ISDN UUI data is present with the following if statement:

if {[infotag get evt_gtd gtd_setup] && [infotag get gtd_attr_exists gtd_setup uus.1]}

We're trying to migrate the inbound call flow to SIP, and I can't seem to get this TCL script working with my CUBE. The script is being run and the calls are being routed properly, but the UUI data is not being ingested. I see the following message when the script is run while having voip application error debugs enabled:

//636148//AFW_:/vtr_ev_gtd_object: rawmsg not found in event

I've tried to find voice TCL scripting/programming guides specifically related to SIP implementations but it's like this topic was dropped in 2004. Can someone point me to a resource where I can determine if my infotags need to be changed for SIP vs ISDN? I was under the impression that since GTD is supposed to be standardized that it would work for SIP as well as ISDN, but perhaps that's not the case?

[eschroederJH · Accepted solution]

I posted my solution to my own question but it seems to have been removed for some reason. I'm taking a wild guess that it was removed because I mentioned a SIP URI, which even though I put dummy data maybe was flagged for removal. Posting again without the SIP URI.

In case someone needs this in the future, I got this sorted out. Instead of checking to see if the data exists as my logical test, I just store the header from the SIP invite in a variable and check to see if its string length is greater than 0. If the data is present, that will be true and I can do what I need to. If there is no UUI data, the variable will be empty and the logical test will be false and the call routes as a normal call. To get the UUI data from a SIP INVITE message, I used the following: 

set uuiheader [infotag get leg_proto_headers "User-to-User"]

For leg_proto_headers to work, you must enable header-passing in the sip config. Once that's done, You can get your hands on the raw User-to-User header and do with it what you must. One caveat I've noticed is that by enabling header-passing, the ani and dnis of the call leg are no longer simply calling/called number, they are the full SIP URI (IE, sip:user-id@IP:port) so in addition to manipulating the UUI data I now will need to manipulate the dnis and ani values with my TCL script in order to match my existing dial peers. I did that by using the "string range" command to extract only the characters I care about - the DNIS.