UCCX Menu Prompt Truncated after Moving to SIP

[Jason Amick]

We recently migrated/ported some of our toll free numbers from a PRI to a SIP and everything with the port went smooth.  The only issue we noticed is with some toll free numbers that direct to a CCX route point/trigger internally the menu prompt/audio will be truncated and the calling party will not hear the complete first word.  Example instead of hearing "Thanks for Calling Company A" you hear "anks for calling Company A".

We basically have a group of DIDs assigned to our SIP trunk and we point each toll free number to one of the local DIDs assigned to our trunk which is our DNIS we receive from Level3.  One of our toll free numbers gets truncated when dialing both the toll free and the local DID but the other is only truncated when dialing the toll free and not the local DID.  We can dial both triggers/route points internally and the initial main greeting prompt is not truncated and works fine.  We have reached out to the carrier for troubleshooting on their side but carrier states no latency on either one of their call legs and the call was properly handed of to our network.  Any help would be greatly appreciated, this was not an issue when the number lived on a PRI.

ITSP SIP Trunk ==> CUBE ==> CUCM ==> UCCX RP == CTI Port

[Jonathan Schulenberg · Accepted solution]

This is not uncommon and the easiest solution is to add a one second Delay step to your CCX script after the Accept step.

Unity Connection has a similar Delay After Answer Advanced setting on the SIP Port Group.

[Jason Amick]

Jonathan:

Thanks that did the trick somehow this particular script was missing the 1 second delay after the accept step.  Once we added the delay it worked like a charm. I know a 1 second delay after the accept step is Cisco best practice and I do that with any script I create but this script was legacy and done by another engineer.  Would you be able to clarify why the greeting was not truncated when the toll free lived on a PRI but when we ported it over to SIP we then experienced the delay?  Thanks again for the quick response.

[Jonathan Schulenberg]

It's a byproduct of how/when the audio cut-through occurs. At the risk of over-simplifying, the PVDM (i.e. DSP) of an ISDN gateway completed audio cut-through in order to provide a progress indicator and ringback to the calling party. You didn't [usually] hear clipping because audio was already flowing all the way across the PSTN by the time the CCX CTI Port answered. The only thing that had to finish cutting through audio was CCX to the gateway, typically over a low latency LAN connection.

SIP on the other hand typically does not have a DSP involved. When CCX answers the call, CUCM and CUBE in turn have cut audio through all the way across the PSTN. That process just takes a second.

Another thing to consider with SIP is that every time you put a call on hold or transfer it the audio is actually suspended all the way across the PSTN and then reconnected, even if only for a 100ms. You may notice similar clipping when playing a prompt immediately after taking a call off hold in the CCX IVR/queued loop.

Admittedly this isn't my most precise answer but hopefully it still helps. 

[Jason Amick]

Jonathan:

Thanks for the quick response and this makes sense.  Either way we should have a delay 1 second step on all of our UCCX script after the accept script.  Thanks for all the help!!