×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

IPCC "The agent extension is out of service"

Answered Question
Aug 1st, 2006
User Badges:

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.



Correct Answer by Patrik Englund about 10 years 11 months ago

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!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (4 ratings)
Loading.
fred.s.mollenkopf Tue, 08/01/2006 - 12:44
User Badges:
  • Gold, 750 points or more

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


Please rate any helpful posts


Thanks


Fred

smolz Tue, 08/01/2006 - 13:29
User Badges:

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.

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 Fri, 09/15/2006 - 05:04
User Badges:

Hi,


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


greetings


Joke Van Bogaert

Correct Answer
Patrik Englund Mon, 09/18/2006 - 03:17
User Badges:

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 Mon, 09/18/2006 - 08:10
User Badges:

Sure does, thanks!


i wonder why it does that

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.

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


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.

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 Sat, 12/09/2006 - 15:16
User Badges:

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 Wed, 02/07/2007 - 09:45
User Badges:
  • Bronze, 100 points or more

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 Mon, 05/28/2007 - 05:24
User Badges:
  • Silver, 250 points or more

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 Thu, 06/30/2011 - 17:36
User Badges:

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

yavuzsab Wed, 07/13/2011 - 20:11
User Badges:

Hi Brett, We have the exact same issue with a client of mine with the same CUCM/UCCX and CAD version. I suspect this to be a defect with CUCM. Was a Cisco TAC SR raised against this fault? Cheers! Yavuz

Brett Hanson Wed, 07/13/2011 - 20:39
User Badges:

Hi Yavuzsab,


I didn't log a case with TAC for this as I managed to resolve it.

The only solution for me was to delete the phone (device) from CUCM, and recreate it.

After I did that - it worked without issue.


As I mentioned - I suspect CUCM db corruption for the device somehow.

Cheers,

Brett

keithchiang Fri, 07/22/2011 - 05:03
User Badges:

We experienced this issue yesterday.  We restarted CTIManager service on all CM servers, the restarted Node Manager services on IPCC servers, failover IPCC back and forth between primary and secondary, nothing worked.  In the end we resolved the issue by disconnect phones from affected agents, plugged phone back in, FIXED!.

yavuzsab Fri, 07/22/2011 - 17:56
User Badges:

Thanks! We had performed the same procedure to resolve it. Definitely need to Cisco TAC to provide us a bug ID for this.


Sent from my iPhone

Brett Hanson Fri, 07/22/2011 - 21:11
User Badges:

Hi Wei and Yavuzsab,


Must be some weird bug with CUCM... as I stated in my original post...

..."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."...


Your solution, unfortunately didn't work for us - it required delete the phone, recreate the phone.

Nothing major like services restart, etc. but nothing as simple as unplug-replug in phone


Cheers,

Brett

Brett Hanson Fri, 07/22/2011 - 21:10
User Badges:

Hi Wei and Yavuzsab,


Must be some weird bug with CUCM... as I stated in my original post...

..."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."...


Your solution, unfortunately didn't work for us - it required delete the phone, recreate the phone.

Nothing major like services restart, etc. but nothing as simple as unplug-replug in phone


Cheers,

Brett

keithchiang Tue, 07/26/2011 - 06:59
User Badges:

Brett,


I definitely agree with you that this has to be some kind of defect.  Unfortunately, we opened a TAC case with Cisco, TAC was able to assist us because both our customer's CM and IPCC are end-of-life.  After disconnecting and reconnecting back did resolve the issue for us for that night.  Immediately, the following morning, agents on the morning shift were unable to set into Ready state.  Here was what we did to really resolve this issue -


1.       Agent phone needs to be dis-associated from the RMJTAPI account (in your case, Application User account)


2.       On CCM, users Extension Mobility needs to be disassociated as well


3.       On IPCC end, we will need to delete the inactive agent that was disassociated on CCM earlier


4.       On CCM, associate back the Extension Mobility profile with the agent user profile


5.       Once this user is configured on CCM it should re-appear as a new agent


6.       Configure the new agent with their old details (like skill set level, team )


7.       Associate their agent device back with RMJTAPI user

Actions

This Discussion