Courtesy Callback with + on inbound number

[stork]

Working on getting Courtesy Callback to work when the inbound ANI is prefixed with a + in front of the number.  Some of our numbers for our call center come off our IP Toll Free SIP Trunks, which are all prefixed with a "+".  When those numbers hit the gateway and sent off to CVP the + is still there.  This causes an issue when attempting to request a callback within the Courtesy Callback application and throws a java error.

Translation profiles to remove the + from the gateway work when testing but the number to the application is sent in the sip header.  I opened a TAC case and removing the "header-passing" command from the gateway will allow the callback to work just fine.  The problem is then there is no header-passing to CVP if needed.

Has anyone come across this? 

[bill.king1 · Accepted solution]

Hi, this may be a dumb question but why not just remove the + from the caller's phone number and use the remaining number in the CCB Studio application? Is the "only" issue the + component when CCB is reading back the caller's phone number for instance? When you go to dial them back, you'd use just the number without the +. Those portions of the Studio script should be OK with Cisco to modify while remaining supported (since they have rules on what you technically can/can't modify).

[stork]

Yes the problem lies with reading back the customer number after they press 1 to offer a callback.  

Customer presses 1 to request callback, then customer is asked to record name then #.  After that the app gets the error because at that point the app would ask, "if you would like a callback from <ANI> press 1, press 2 to enter a different phone number'.

So reading the inbound number back to the customer with a + is the issue.  Never really thought about editing the actual app itself.  Just thinking how I would go about removing this.  If a customer wants a callback they are sent to the "Wants Callback" page of the CallbackEntry app.  I can see there that there is a decision element that checks to see if the ani exists and if it does it's sent to the "Confirm Callback Number 1" element.... I suppose I could get rid of that altogether and force the customer to the "Ask For Callback Number" element and maybe this would eliminate that since the app wouldn't be reading back the number?

Thoughts?

Thanks for the reply!

[janinegraves]

ICM is passing in the ani in one of the SetValue nodes. Might be easiest
to strip off the + sign in the ICM script than in the Studio app.

[stork]

Thanks Bill that worked!!!

Under the Wants Callback page of the application "CallbackEntry" I sent both the ANI existence check exits to the "Ask for Callback Number" element.  This forces the caller to enter a telephone number every time and eliminate the app from reading back the inbound ani and causing the error.

I had to Ignore the "Confirm Callback Number 1" element to validate the script but this solution works.

Thanks again!