04-14-2009 05:41 AM - edited 03-18-2019 10:52 PM
Integration with MS MOC/CUPS and CCM 6., issue is when a user makes a call it automatically goes on hold when answered. If we disable the RCC in OCS, the issue goes away. So, need to find out why OCS places the call on hold. Has anyone ran into this issue?
04-14-2009 06:53 AM
This sounds like a known issue. The cause was CUPS sends CSTA message to OCS on non-controlled phones.
What version is the CUPS? I'd recommend you upgrade to the latest version.
Michael
04-14-2009 09:29 AM
System version: 6.0.5.1000-13
04-14-2009 11:41 AM
Try to to CUPS Admin > Application > CTI Gateway > Settings. Make sure there's only one "Cisco Unified Communications Manager Address" listed. Restart "Cisco UP SIP Proxy" service.
See if that alleviate the problem?
Thanks!
Michael
04-14-2009 03:52 PM
There is only one address.
The issue is, this occurs on a daily basis.
The temp workaround is either, have user log out and back in to the MOC, when the issue occurs or disable RCC for that user. Neither is what we want to do on a daily basis...Thank you
07-14-2010 02:29 PM
Has anyone ever found you a solution to this problem? We have had a few TAC cases attempt to resolve the issue, but nothing solid has been found and our users continue to have this problem.
12-13-2011 08:21 AM
I'm just hitting the same problem, Did anyone every resolve this?
12-13-2011 08:34 AM
Hi Matt22coll:
Here is some information I recieved from TAC on this issue (After 6 months of working thru this will different support cases as it was difficult to reproduce at times.)
This is a known issue and has been documented in this bug: CSCtc50956 - CTIGW: call automatically put on hold
This bug was never made public as it was found only by a few select customers. The description of the bug is as follows:
1. A call was established on MOC
2. MOC hit 8-hour recycling mark. It then sent a new INVITE/MonitorStart, etc.
3. MOC then closed the previous SIP session with BYE
4. When there was a new call coming, MOC found there was two calls active so it sent HoldCall event to CTIGW in trying to put the 1st call on Hold.
5. CTIGW uses the callid found in the HoldCall to put the call on hold. But since CTIGW had only one call data attached to the new scb, it put the 2nd call on hold instead.
Comparing this with the explanation provided by Microsoft we can see it matches. This bug has been fixed in the 7.0.6 or 8.0.1 release of CUPS. I am working to make this defect public so you can view it within the next few days. The resolution will be to upgrade your presence server to 7.0.6 or later.
12-13-2011 08:43 AM
Thanks,
I'll have a go at upgrading and see how we go.
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