Calls go on hold automatically

[mtpciscotech]

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?

[htluo]

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

http://htluo.blogspot.com

[mtpciscotech]

System version: 6.0.5.1000-13

[htluo]

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

[mtpciscotech]

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

[mullaneyp1]

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.

[matt22coll]

I'm just hitting the same problem, Did anyone every resolve this?

[mullaneyp1]

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.

[matt22coll]

Thanks,

I'll have a go at upgrading and see how we go.