CIPC/Extension Mobility/Unregistered Phones

[RyanHeseltine]

Hi all,

I'm having a few problems currently with Cisco IP Communicator in that if a user is logged on to a phone and then closes the phone without logging out and then goes to another phone and logs in an application that requires the information of the new users phone for CTI controls never gets the update that this person is on a different phone and therefore keeps trying to control the old phone(which isn't in use anymore).

The obvious answer is to log out properly, however, with a VDI environment once the user has forgotten this causes quite a few problem.

My understanding of it is that although the old CIPC is logged out when the new phone is logged into because the CIPC is 'Unregistered' within call manager it never updates the application to let it know that it has a new logged out number and thus a conflict is created.

Is there any way to simulate with call manager(7.1) that a phone has accepted it's new logged out number so that I could perhaps automate to do this against all our CIPC out of hours and therefore call manager will then update the application with the phones logged out numbers?

Regards,

Ryan

[Jaime Valencia]

Disable the ability to login on multiple phones with EM, any other phone on which they previously logged in will be automatically logged out and only the last device they logged in succesfully will be used.

EDIT: another option is to enable the maximum login timer (X minutes after a user logs in), but there is no way to configure in CUCM to log out eveyone at a certain time.

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

[RyanHeseltine]

Unfortunately, we've already got the ability to log in to multiple phones disabled. However, because its a CIPC if it is closed down without turning off it's not able to accept it's logged out number and therefore doesn't update the application until it's turned back on.(This is reflected in call manager by the unregistered status)

Hence, we need to be able to make call manager think that the CIPC has accepted the new number and it will then update the application with the new details.

With regards to not being able to log everyone out at a certain time, surely this is possible using the logout URL for extension mobility on a loop with a list of all the MAC addresses? Although like I said this wouldn't fix our problem anyway.

[Jaime Valencia]

Yeah that's possible if you create your own logout script and send the logout URL to the CUCM server with the MAC from the device.

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

[Aaron Harrison]

Hi

That sounds more like a bug to me - a phone doesn't have to be connected to be logged in or out. If for example you were logged into a phone that went faulty and died, you would not expect to have to restart the cluster or any services to clear that line state - you would just log onto another phone.

I'd probably raise a TAC case.

Are the CTI apps you are having problems with Cisco, third party or your own?

Aaron Harrison

Principal Engineer at Logicalis UK

Please rate helpful posts...

[RyanHeseltine]

Hi,

It is a bug to an extent that has been fixed by version 8, however, we can't really upgrade at the moment.

If a normal phone went faulty the same thing would happen, as it would never accept it's new line and wouldn't therefore update the 3rd party CTI application.

It doesn't affect any of Cisco's functionality I.e. you can still log/out on another phone, but because it's gone faulty(or with CIPC been shutdown without logging off) Call Manager never updates the CTI application as it can't communicate with the original device.

Regards,

Ryan

[Aaron Harrison]

Hi

So if it's a bug then you are likely a little stuck.

Logging the CIPCs out by firing URLs at the EM web app will most likely work the same as logging in on another phone - the EM web app will just submit a logout to the original phone and then log in the new one.

CallManager doesn't need to communicate with the device to know what state it's in, they're fairly dumb and the status of lines is managed on CUCM rather than the device itself.

I often use CIPC with UCCX/CAD and haven't seen such an issue - perhaps it needs to be driven more by the CTI app (i.e. responding differently to messages received when a line goes out of service and attempting to re-establish the CTI session).

Aaron

[RyanHeseltine]

Cheers for your help on this, I am a bit stuck atm.

I know that CUCM manages the state of the lines, but because when a phone is unplugged without logging off it never receives it's new number so call manager puts the phone in 'Unregistered' mode this results in the Cisco TAPI never updating the CTI application. Admittedly the application could be smarter in the way it handles this, but I'm not hear to blame just to try and get a fix

Does anyone know definitevely whether you can change the status under (Device > Phone) from Unregistered to Unknown?

[RyanHeseltine]

Scrap what I said above about turning a phone from Unregistered to Unknown, as this wouldn't solve the problem.

The problem lies somewhere in the phone not sending some form of confirmation that it has it's new line which doesn't cause a problem for Cisco stuff, but results in the TAPI not updating the CTI applicaiton.

Result in the Applications record never being updated. So I guess my question now is if it's possible to mimic the log off process as if the phone is still switched on?

[Aaron Harrison]

Hi Ryan

Unknown = never registered since last restart (or in CUCM's living memory), whereas Unregistered means that physical phone is has unregistered. You can't set those, they're just showing you the current realtime state...

The phone doesn't need to confirm that it doesn't have the line. You can log it on and off using URLs you send to EM (or for a simpler option use my little free EM application - www.ipcommute.co.uk).

You could use the Julmar TAPI phone (http://www.julmar.com/tapi/) to take control of a CIPC, and then kill it, see what messages are received, and play with the EM state etc. Might help you get a clearer picture of what's going on..

Aaron