Skip to main content

Cloud

OCS CallManager and CUPS – a bug!

I’ve written a bunch on my OCS 2007 CallManager 5.1 and Cisco Unified Presence Server (CUPS) 6.0.1 integration. For the most part – it’s all working great. My previous posts talked about resolving issues with shared line appearances (where your extension is on multiple phones). I was happy to clear that up. But now – I’m faced with an even trickier issue.

The problem

You have a user, Hillary, who has a secretary (let’s call him Bill) and they each have Hillary’s phone number (1600) on their phones. Hillary is signed into OCS with Remote Call Control enabled talking on the phone with a friend (let’s call him Rudy).

Just then, another call comes in from one of her associates (let’s call him Mitt).

Hillary sees the call coming in from Mitt, but decides not to answer it. So her secretary, Bill, decides to answer the call for her. As soon as Bill picks up that call on his phone, Hillary’s original call with Rudy gets put on hold.

That, folks, is a bug. When the secretary picks up the call, it should have no effect on Hillary’s original call. But the CUPS-OCS integration doesn’t have any way of understanding that it was Bill, not Hillary, who was answering the second call. So it gets all confused and just thinks – "yikes, I better put the call on hold in case it was really Hillary who answered it".

My Course of Action

I verified that this happens all the time, no matter how you have the users configured in OCS, CCM, or CUPS. Tried it dozens of times and it works the same way. So I opened a TAC case with Cisco. I got the same TAC engineer, Michael, as I did when I was looking to resolve the other "shared line appearance" issue. Since he pretty much rocks, I figured he’d have a fix for me in no time.

Well, we took a bunch of CUPS and CCM traces and he sent them off to the developers. This was my first clue that I had a real problem on my hands. A couple days later, Michael told me "Don’t bother giving us any more traces – it’s a bug". They created a bug ID and got to work on it.

The developers came back and said "The trouble is that once the secretary picks the call up, we have no way of notifying OCS to stop ringing – so even if CCM doesn’t put the call on hold, the OCS user continues to see the call coming in".

At that point, Cisco suggested that I get MS on the phone and see if we could work with their developers to amend the integration standards between the two. So I opened an MS case and the PSS guy told me "Well, to be honest, I can’t imagine that this is affecting loads of customers. The only way to get this resolved quickly is if you have Cisco open the case with us".

So – back to Cisco. Well by now, Cisco developers had come up with a solution to the whole problem. Hooray! I called off the dogs at MS and told them Cisco had developed a fix for CUPS.

The Bad News

Right now, Cisco is saying that they will incorporate this fix in CUPS 6.0.3 – due out in May. Doh! I am currently trying to get this escalated so that Cisco will release a patch (or "Engineering Special" in Cisco-ese) that I can apply now and take care of this. But again, unfortunately it doesn’t seem like this is affecting thousands of angry customers and isn’t going to be a rush priority.

Conclusion

I don’t think that I was doing anything that odd – users around the world have secretaries who answer calls for them. I was a little disappointed that this goofy bug existed in the first place – but at least it’s getting some attention. Stay tuned for the exciting resolution once I get my hands on the patch.

-Matt

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Matt McGillen

More from this Author

Follow Us