CUCM 6.1.1, CUPS 6.0.2, OCS 2007, Extension Mobility issue

afullagar · ‎04-13-2008

Hi All

Test Lab consists of CUCM 6.1.1 (latest patches), CUPS 6.0.2 (latest patches). Everything works ok once you are logged in to a phone, you can control the phone. If you log out of one phone and into another phone the mac address is not updated and you lose control until you log back into the original phone. Seems the CTIGW controls are not updating OCS via CUPS when OCS requests the new mac address to control.

Testing is not being done with shared lines so each phone has one extension that is unique.

Anyone else run into this problem? Maybe a cisco bug?

agiaccone · ‎04-14-2008

I ran into this problem too, observing that only a MOC "sign-out sign-in" resolve the issue.

This means that when you login on another telephone using EM, you'll have to have sign-out and then sign-in again in MOC to have it request to OCS-CUPS the new "position" of the line to control.

HTH

Alberto

karlfisher · ‎02-13-2009

Hi,

I'm seeing a similar issue with CUCM6.1.3 , CUP6.0.4 and OCS.

We are using EM redundancy with a load balancer sharing 50/50 between PUB and SUB03.

We login into a phone using EM, the traces show the request goes via the PUB.

We get RCC from the MOC client ok.

If we then logout/login again on a different phone and the EM request goes via SUB03 then we do not get RCC on MOC.

The traces show that when logging in via SUB03 OCS still gets presented with the device-id of the phone when it logged in via PUB.

So,

user logs into phoneA (EM request to PUB), RCC ok. traces show device-id=phoneA

user then logs into phoneB (EM request via SUB03), RCC fails, traces show device-id=phoneA.

Haven't got to the bottom of why the CTI information isn't being updated correctly yet, but will post when I get some results.

K.

htluo · ‎02-13-2009

This problem is kind of complicated unless you understand how things work.

First of all, I would recommend you upgrade to CUPS 6.0(5) or 7.0(3) to eliminate any potential CTIGW bugs.

On OCS/MOC side, you configure URI for the phone control. You may or may not specify the device name in the URI. Lots of customers tend to NOT configure the device name for "simplicity".

If you don't specify the device name, you'll have to fully understand how CUPS choose a device (if the DN exists on two or more devices).

For details, see:

http://www.cisco.com/en/US/docs/voice_ip_comm/cups/6_0_1/install_upgrade/deployment/guide/dgmsint.html#wp1049685

When EM is involved, things are more complicated.

1. I would recommend you specify the EM profile name as device name in URI.

2. Make sure change notification works fine between CUCM and CUPS. Otherwise, device mapping might not be updated. The easiest way to test is to change something on CUCM side and see if it got updated on CUPS side.

Michael

http://htluo.blogspot.com/

karlfisher · ‎02-03-2010

Hi,

Thought I'd share the fix for this one.

This issue turned out to be a bug with replicating the EM information about the device that the user can control.

If the EM request went to the publisher then the PUB database was updated correctly and the controlled device information was replicated to the CUP cluster.

However if the EM request went to s subscriber the the PUB database was updated by the controlled device information was not replicated to the CUP cluster.

Fixed by upgrading to 6.1.4

Regards

Karl.