Can anyone help us in with this problem? We are stumped!
Our Basic Architecture:
We are using the 8851 Built in brdige (BiB) and cucm call recording and monitoring feature to fork audio to our recording server to be converted to text. The converted text is sent back to the endpoint via JTAPI. We are using an XML service app to display the text on the Cisco phone. The phone in question is an 8851 on CUCM 10.5.
The Issue:
In lab tests and many other customer sites, there is typically a 3-5 second delay from when the audio is sent from the 8851's BiB to when the text returns and is displayed on the Cisco phone via xml service app. At the customer's site we are seeing this delay up to 60 seconds.
We can see in packet captures that our server and the network are not to blame. We see the text packets leave our server on time and heading for CUCM. We get a response from CUCM (we think saying that it received the text - not sure as the msg is cisco proprietary). 30-60 sec later, the text shows up on the 8851.
Questions
1. Is there a setting in CUCM (or the cisco phone - 8851) that would buffer text sent to it, headed for an 8851, via JTAPI?
2. If there is no setting in CUCM (or the phone) that would cause CUCM to hold on to the text for 30-60 seconds prior to displaying it, what else could cause the delay? A taxed CTI Manager perhaps?
We have been unable to reproduce this in our lab and it is happening at more than one customer location. The common theme in my opinion is the customers have 2 or more clusters of CUCM. Our lab environment is setup with a single CUCM.
If you can solve this one, I would be most grateful!
