Courtesy call back does not display caller ID

[Sureshkumar Mohanraj]

I have a question on the Courtesy Callback Entry app we have the Calling Line ID which is static 10 digit most of the time, and I would like to change this to dynamic based on what ICM provides.

Here is what i have done, 

Set the Call.PeripheralVariable6 = 1234567890

ICM i modifed the variable : concatenate("ani=",Call.CallingLineID,";ccbnum=",Call.PeripheralVariable6)

So i am able to see the ccbnum in the start parameter and see the 10 digit value as well.

CallbackEntry,06/04/2024 01:59:18.034,,start,parameter,ccbnum=1234567890

in CCB, entry app field "Calling Line ID : {Data.Session.ccbnum}"

But somehow the value what i got in the ccbnum start parameter is not parsing to Callback wait script

CallbackWait,05/29/2024 18:33:48.395,Get Status_01,data,cli,{Data.Session.ccbnum}

ideally this should be : Get Status_01,data,cli,1234567890

Due to this, caller id shown as "unknown"

So any idea, how i can make this happen ?

[janinegraves]

Woohoo - you were correct! The updateCommonClasses.bat does indeed now update everything under VXMLServer/common!
That's definitely the best method to use (least impactful). And it makes sense that Cisco would have implemented this on hosted systems where they can't allow you to restart the VXMLServer service.

Now the question is, whether the same is true for updating the jdbc jar file and the context.xml file when using the Database element.

Do you happen to know if someone restarted the VXMLServer service for you?

It's always been the case that updating the jar file in VXMLServer/Tomcat/lib and the context.xml file in VXMLServer/Tomcat/conf required a restart of the VXMLServer service. I wonder if that's somehow been changed - do you know whether

[Sureshkumar Mohanraj]

Restarting the VXML service on the cloud platform is not possible without change request. So it was just running the "updateCommonClasses.bat" made the difference.