I have an issue when agents answer a call there would be a few seconds delay in between before they could hear the person on the other end.
Is there any option that I can check to see if there was delay .
An help would be much appreciated.
Is this only happening to ACD calls or direct calls as well?
I've seen similar issues caused by head sets, so see if this can be reproduced by taking call with handset if you are using head sets.
Has anyone/anything shed any light on this issue? We just upgraded from UCCX and CUCM, 8x to 9.1 and suddenly get a fluid moving delay when agents answer a call....it will vary from 5-15 seconds of silence making callers think the call was dropped.
I say fluid as it moves from user to user during the day and varies in length. Someday a user has a constant 10 second silent pause before they can talk to the caller, the next day almost no pause then the next day the pause will vary from 5 seconds to 8 seconds then disappear. This behavior makes me think it’s not in the scripting and all the CTI ports appear ok……
Any suggestions or thoughts are appreciated.
In my case the script was missing 2 seconds dealy before Accept step at the beginning and as per TAC it is highly recommended to give enough time for Call Manager to connect correctly the call with UCCX.
My logs showed calls were flowing fine but the status of the agents were stuck in reserved and then change to talking because of the missing two second delay. Added the two second delay before the accept step to fix the issue.
Hope this helps
Good morning and thank you for your input. I checked the scripting right away and it appears we have had the delay this whole time per the images below.
I reuploaded the script and made some test calls and am experiencing the long silent pause.
All input is greatly appreciated!!
We have been getting this issue as well. We are running UCCX 9.0.2 and CUCM 9.1.1. We are having a hard time determining if this is a network congestion issue or a server issue. We have the 2 second delay in all our scripts as this was added to try to combat another issue where a call in queue gets presented to an agent, puts them in reserved mode but then never delivers the call thereby locking up the queue for all other agents.
This happens about every week to two weeks. It happens more often to certain branches than others, but also corrects itself after about 15-20 mins.
I opnened a case with TAC in regards to the above issue. We had just migrated from a physical UCS envirmoent to a virtual VMWare envirmoent and suddenly this issue started.
Here is the link TAC provded. We permormed the steps mentioned and the problem has all but completely disapeared for us!
No worries. I'm not an internet grammer cop. We also switched from physical to virtual when we upgraded from 8.0/8.5 to 9.0.
I will try your link. Thank you SO much for the quick reply. I will let you know how it turns out.
We are still having this issue. TAC has been almost no help at all their support has degraded down to worthless email correspondence every two to three days. In addition to this issue, we also get (about every 7-10 days) the situation where a large portion (can't verify if everyone. we have 50+ branches) of the agents will have their CAD freeze up where no calls can be accepted. Phones continue to work perfectly, just not from UCCX. This affects virtual and physical CAD clients simultaneously. It clears itself up after about 10-15 minutes and then all if good until the next occurance. I have a hard time believing these two issues are not related. Again, TAC is no help so far.
We are running Citrix VDI clients for the majority of agents. Until recently we did NOT have the "virtual client" set to yes using the postinstaller.exe. That has been set to yes but it affected the physical clients as well as the virutal ones.
Here is one of the logs from the uccx server at the time of occuance. I can find no help on the bippa errors.
2014-03-04 10:09:44:045 INFO BIPPA0037 There is no Enterprise data for this call.
2014-03-04 10:09:52:974 INFO BIPPA0037 There is no Enterprise data for this call.
2014-03-04 10:31:10:441 ERROR SPLKTSSP2038 Network communication error (TRANSIENT).
2014-03-04 10:31:10:441 INFO BIPPA0034 <default BIPPA Enterprise service> on <172.16.6.13> has become unavailable.
2014-03-04 10:31:10:470 INFO BIPPA0033 <default BIPPA Enterprise service> on <172.16.6.13> has become available.
2014-03-04 10:31:40:473 ERROR SPLKTSSP2038 Network communication error (TRANSIENT).
2014-03-04 10:31:40:473 INFO BIPPA0034 <default BIPPA Enterprise service> on <172.16.6.13> has become unavailable.
2014-03-04 10:31:40:475 INFO BIPPA0033 <default BIPPA Enterprise service> on <172.16.6.13> has become available.
2014-03-04 10:32:10:477 ERROR SPLKTSSP2038 Network communication error (TRANSIENT).
2014-03-04 10:32:10:477 INFO BIPPA0034 <default BIPPA Enterprise service> on <172.16.6.13> has become unavailable.
2014-03-04 10:32:10:478 INFO BIPPA0033 <default BIPPA Enterprise service> on <172.16.6.13> has become available.
2014-03-04 10:32:40:480 ERROR SPLKTSSP2038 Network communication error (TRANSIENT).
2014-03-04 10:32:40:481 INFO BIPPA0034 <default BIPPA Enterprise service> on <172.16.6.13> has become unavailable.
Did you ever get this issue resolved? We are still fighting this on and off for weeks now. Seems to clear up for a few days then rears it's ugly head all over again.
We run three CUCM 9.1 boxes in our CM cluster as well as two UCCX 9.1 boxes (HA). They are all VMware machines running on the same blade. We are getting an additional blade in to see if there is a resource issue.
Also, anyone else with this issue happen to be on Century Link network?