IPCC "The agent extension is out of service"

[smolz]

We are using IPCC 4.0(3)_Build080, we have setup a new user in the system like everyone else. When this user tries to go into a ready state in the agent desktop he gets the following error:

13:16:20 Cannot go to the ready state while the phone is out of service. Other state changes are possible.

--------------------------------------------

13:16:20 The agent extension is out of service.

Ready state change and call control operations cannot be performed.

[fred.s.mollenkopf]

Make sure the agent's phone is controlled by RMUser.

Please rate any helpful posts

Thanks

Fred

[smolz]

I did check that, he is associated. The user is able to log into the desktop agent, just is unable to go into a ready state.

[don.mcneil]

I have the exact same problem. Only these are not new users. They are existing users that were all working fine on Friday and now on Monday they are getting this same error message.The phone is registered and associated with the RMuser acct. Nothing has changed but all of the sudden I have a handful of users that can NOT get to a READY state.

Does ANYONE at Cisco have a clue as to why this is happening. I running the same version of IPCC 4.0(4)_

[vbogaerj5]

Hi,

We are having the same problems also with existing users. Did you already find a solution for this?

greetings

Joke Van Bogaert

[Patrik Englund · Accepted solution]

I have the same problem occasionaly. I use version 3.5.(2) and the solution for me have been that i have deassociated the users extensions with both rm user and the agent itself. Then associated the extension with my id and then logged on to the desktop agent and go into ready state without any problem on the affected extension.

After i have done this i have associated the extension with the rm user and the agent itself again and it have been working every time.

I have no clue though why this happens but it could have something to do with replication / connectio nbetween IPCC and CCM systems.

Hope this would help you!

[smolz]

Sure does, thanks!

i wonder why it does that

[wrichmond]

Hi guys, I just came across this problem for the first time, and was confused like many of you. We deploy 7940, 2-button phones for our queue agents. The phone worked fine, registered, called in and out on both lines, and had a working PC connected to the PC port, but we kept getting this error. I finally visited the user and noticed the buttons were really hard to push. The phone looked clean, but looking closely, it appeared like a massive liquid spill took out the phone at some point in the past. I replaced the phone and the problem was solved. In replacing the phone, I may have reset all CM and CC DB entries with a new MAC address, so don?t know if the phone was physically damaged in a minor way due to spill, or if just changing the MAC address solved problem. In any case, you now have any easy solution-replace phone.

[wrichmond]

UDPATE2: This problem continued to occur even on new phones. There was a twist though. As long as the phones hadn?t been introduced into the network yet (ie, registered with CM), they would work. As soon as I unregistered phone, assigned a new one to the IPCC user and then re-assigned the newly introduced phone back into network, error would occur again.

I opened a TAC case, and they were interested in the unisteresting EV logs from the CM and IPCC servers and the agent log on the agent PC. Both yielded no interesting information. I rebooted both Call Managers and IPCC Server and the problem went away. I think this is a bug in this software combo:

1) CM: 4.1.3sr2

2) IPCC: 4.0.4 enterprise edition

[don.mcneil]

I have a TAC case open on this as well. So TAC has been unable to come up with anything. It is a random occurance but once it I get one agent who can't get to READY I get several and the OPNLY way to resolve it is to reboot the IPCC server. Once it happens again I will be sending a new set of MIVR logs that cover few hours before the problem occurs. TAC wants to know what was happening before the Agent goes into NOT Ready State, ie some kind of trigger.

[wrichmond]

Hi Don, Glad someone out there is seeing what I am seeing--I think. Here is my TAC case details on this. I think they are putting this into an unknown bucket at the moment. Don't know if I want to do a CM upgrade at the moment just to see if it fixes problem:

==========TAC RESPONSE BELOW==========

SR# 604635263 - ipcc users unable to go to ready since active phone appears to not be in service: I am located in Sydney timezone. From what we know about the problem, since JTAPI on CRS receives out of service event then most likely this issue is not related to CRS. If you don't see any device unregistration messages in the Application log (on any CallManager servers in the cluster) around that time then most likely the issue is not related to phone getting unregistered.

Occasionally we may experience some transient issue in the CTIManager where a restart of the CTIManager can refresh the connections and resolve the issue. In regards to the issue you have faced I would like to recommend the following actions:

- Apply the latest SR, CallManager 4.1(3)SR3c if possible, there are defects resolved that improve the stability of CTIManager and JTAPI but I could not find any specific defects related to this issue.

- Enable detailed CCM and CTI tracing, also enable CCM SDL and CTI SDL tracing on all the CallManager's in the cluster. If the issue happens again, provide details of what happened, along with the agent logs and the CCM, CTI, CCM SDL and CTI SDL from all the nodes in the CallManager cluster and we will investigate further.

Please let me know if you will be able to apply the latest SR, also let me know how long you would like to monitor this issue for, if it happens again then supply the requested logs and we can investigate further, thanks.

[Jose Robles]

I have the same problem with CCM 4.1(3)sr3c and 4.0(4)SR01_Build029. Is it a bug? I'll change to sr4b and see hot it goes. The new Jtapi 3.22 version.

[johnnylingo]

Did you end up doing this?

I haven't hit this bug yet, but am running 4.0(4)SR01_Build029 and debating if I should patch CCM to 4.1(3)sr3c or 4.1(3)sr4b

[mmelbourne]

I am seeing similar issues after adding a second node to a CRS 4.0(5) cluster for HA.

During testing in the lab, it seems to be more prevalent after the system has failed over (or a forced failover to return the roles to their original servers). However, I found if the phone was taken off-hook briefly, then the agent could move into the Ready state. The phones are all associated with the RMJTAPI user.

In the lab, I did try updating CCM to the 4.1(3)sr4d release and sync'ing the new version of JTAPI on the CRS servers to see whether it improved stability. This didn't appear to make much difference, as the problem remained.

Are others running HA clusters? Is it possible to increase the the CAD logging, to possibly provide some clues as to why it's not possible at times to move into a Ready state?

[Brett Hanson]

Hi guys,

Solution, for us, was to delete the phone from CUCM, and recreate it.

This process took less than 1 minute…

I located the device (phone) in CUCM by MAC address and deleted it.

All  of our Service Desk phones are identical in config (they are setup for  Extension Mobility to allow for desk sharing) - so I simply "super-copied"  another SDA phone using the problematic phone's MAC, and changed the description.

Next I associated  the 'newly created' device with the RMCM application user (User  Management > Application User > < whatever username you gave  for  your UCCX RMCM username>).

Once the new "old" device had  registered, Joe Bloggs logged in with his extension mobility login,  logged into CAD, and was able to go 'Ready'.

Solved.

Information/background and initial troubleshooting:

We are on...

CUCM 8.0.2.40000-1

UCCX 8.0.2.11004-12

CAD 8.0.2.400 (says 8.0(2) at startup, the 'about' shows 8.0.2.400)

We had the issue this morning where Joe Bloggs (SDA) was able to login to his phone (extension mobility), login to CAD (Cisco Agent Desktop), but could not go ‘Ready’ state.

He was being presented the following error:

     07:20:29  Resource's Device is Off.

     --------------------------------------------

     07:20:29  The agent extension is out of service.

     Ready state change and call control operations cannot be performed.

I logged into his device (phone) as myself and then logged into CAD. I was presented with the same error when attempting to go 'Ready'.

Other SDA’s with the same device (phone) and device profile (extension mobility) config did not have any trouble on their phones – so appeared to have been a phone issue - or at least an issue between CUCM and the device.

I had Joe Bloggs perform the factory default reset (unplug network cable, holding # - plug back in network cable, when line buttons flashed in sequence type 123456789*0#) – after reset, tested again, made no difference - the error persisted.

Next, I disassociated Joe Bloggs from the DN (Directory Number/Extension) and then disassociated both the device and the device profile (ext. mobility) from RMCM ‘Application User’, saved – then re-associated – made no difference, the problem continued.

....

Not sure why it happened - appears as though maybe the record of this particular device had become corrupt in CUCM somehow.

Hope this helps someone else - as it was a lot quicker (for our setup) than disassociating user extensions and devices, etc.

Cheers,

Brett