02-19-2015 02:42 PM - edited 03-19-2019 09:13 AM
Hi There,
We have CUCM 8.6 and Verint Call Recording 10. We use CUCM silent monitoring through the BIB (Built-In Bridge). What I understand is that the monitoring party should automatically placed on hold when the agent places the customer on hold and the monitoring session automatically resumes when the agent resumes the call. I believe when the agent places the customer on hold, recording calls are torn down. When the call is resumed, two new recording calls are established. Is this assumtion valid?
Our issue is that the recording stops as soon as the agent retrievs the call from hold. Anybody got into a similar situation. Any solution/recommandation would be greately appreciated.
Thanks,
MK
02-19-2015 09:14 PM
Hi MK,
Recording calls get torn down when the agent puts the call on hold, and they get reestablished when the agent resumes the call.
The Start Recording Request from an application persists throughout the call.
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/8_5_1/ccmfeat/fsgd-851-cm/fsmr.html#wp1058289
HTH
Manish
02-20-2015 07:05 AM
HI Manish,
Thank you for replying.
What you're saying is exactly what my understanding is and this is what I wrote in my description when I posted this question. Would you happen to have a solution for why the recording doesn't pick up when the agent resumes the call?
Thanks,
MK
02-23-2015 10:34 AM
Anybody with any idea?
Thanks,
MK
02-25-2015 05:02 AM
Hi MK,
Yes, in a normal scenario recording should resume after hold/resume. There were a couple of bugs related to call recording on cucm 8.6 version, one of them is given below
https://tools.cisco.com/bugsearch/bug/CSCug24286
Symptom:
Intermittently calls are not being recorded from BiB.
Conditions:
An active call to an agent will go on hold even before recording call start ( with a CTI application initiating the hold immediately after the media cut thru; it is hard to hit this issue via manual hold). However, upon resume of the call; we would expect recording to start automatically; however it does not. It is a race condition between the hold and the recording.The fix is to handle this race condition and let the recording resume upon the call resume.
Workaround:
Delay the hold from the application for a few milliseconds to let the recording start before going on hold.
Although it is not the exact match as yours but you can check if your cucm 8.6.2 is running one of the fixed or higher versions listed in it.
HTH
Manish
02-25-2015 06:59 AM
Hi Manish,
Thank you for taking the time and replying.
I don`t understand the workaround. Could you please explain how to "Delay the hold from the application for a few milliseconds "?
Our current version is 8.6.2.22900-9
Soon, we are upgrading to 9.1.2SU2a, would the bug be fixed in that version?
Thanks,
MK
02-25-2015 08:49 AM
Hi MK,
In your case the hold / resume is manual, so the above workaround can not be tried. I would need to check how it is applied though. This bug applies to 8.x version so an upgrade to 9.x version will take care of the same.
HTH
Manish
02-25-2015 11:36 AM
Our upgrade is scheduled in 6 months. We can't wait until the upgrade resolves the issue. What would you need to be able to check how it applies? Please let me know.
Thanks,
MK
03-09-2015 12:10 PM
Anybody with any ideas for this issue?
Thanks,
MK
07-05-2018 12:45 PM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide