I recently upgraded a customer from 8 to 8.5 to fix an issue and have run into a new one.
For three agents I've gotten the error message: "Login failed due to a configuration error with your phone and JTAPI or Unified CM. Contact your administrator."
For two of them, the fix was to un-associate and re-associate their device with the RmCm user. For the last fella, I've tried complete rips and rebuilds and I can't get him past the error message.
Call Manager is at version 22.214.171.12400-8 which shows up on the compat chart as a match for CCX 8.5 SU1.
I seem to have nothing but bad luck with CCX 8.0 and 8.5...buggy buggy products. Tried a directory resync, multiple add / removes of the agent in CCX. Made sure the inactive agent was deleted before re-adding. Multiple add / removes from the RmCm user.
Gonna try a server reboot tonight in case I'm hitting a bug where the old agent id information is stored in memory.
Try to restart the CTI manager on all the CUCM nodes then restart the UCCX engine.
Make sure there is not shared lines on the ICD line and ICD line is in the first 4 lines on the IP phone.
The extension was used across both the desk phone and an IP Communicator that the agent sometimes uses from home. Once I removed the IP Communicator as an associated device under the RmCm user, things worked again.
I'll have to ask the customer how they've been using this in the past. I'm guessing the CCX jtapi code just says, "grab the first device you see in the RmCm list of controlled devices that matches this extension" and doesn't think to check for others if the device shows as unregistered.
That configuration is documented as unsupported. The only way to "share" an ACD extension between multiple devices is to assign it to a Device Profile exclusively and then login using Extension Mobility to whatever device they wish to use. Note that all possible devices that will be logged into must be associated to the RmCm application user.
The release notes state this in the Unsupported Configurations for Agent Phones:
The following configurations are not supported for agent phones:
•Two lines on an agent’s phone that have the same extension but exist in different partitions.
•A Unified CCX extension assigned to multiple devices.
•Configuring the same Unified CCX extension in more than one device profile, or configuring the same Unified CCX extension in any combination of device profiles and devices. (Configuring an Unified CCX extension in a single device profile is supported.)
•In the Unified CM Administration Directory Number Configuration web page for each Unified CCX line, setting Maximum Number of Calls to a value other than 2.
•In the Unified CM Administration Directory Number Configuration web page for each Unified CCX line, setting Busy Trigger to a value other than 1.
•Configuring a Cisco Unified IP Phone with Secure Real-Time Protocol (SRTP) for use in silent monitoring and recording.
•No Cisco Unified Communications Manager device can be forwarded to the Unified CCX extension of an agent.
•The Unified CCX extension of an agent cannot be configured to forward to a Cisco Unified CCX route point.
•Use of characters other than the numerals 0–9 in the Unified CCX extension of an agent.
•Configuring the Unified CM intercom feature.
•Configuring the hold reversion feature.
Where can I find this documentation? I have had the same issue, we upgraded from 8.0 to 8.5 and now need to have some hard evidence to show our client that shared lines is not supported. Also, where could i find the compatability documentation? any help would be great.
thanks so much.
Martin, here's the link to the compatibility guides:
It's the release notes that mention the "no shared lines" (page 7 on the 8.5 release notes):
Link to all CCX guides (too many documents, arghh):
Looks like "I'm guessing the CCX jtapi code just says, "grab the first device you see in the RmCm list of controlled devices that matches this extension" and doesn't think to check for others if the device shows as unregistered." was the exact problem in my case, I had replaced a phone for a user but the old mac was still listed under the RmCm list of controlled devices, once I removed the old phone from the controlled devices I got no more JTAPI errors on the desktop agent. Thanks for the info!
Just FYI. I was having the same issue with same error and performed the same troubleshooting steps. But my resolutions was the position of the CCX extension. Customer had it on the 5th line of the phone, and i moved it up as frzhang suggested and it works. Just somethine weird in this version. Worked fine in 7.0.
I will go one better. Running CUCM 8.5.1 and UCCX 8.02 and everything was fine. Upgraded UCCX to 8.5.1SU1 and had two phones that got the same error message when trying to login to CAD using Extension Mobility on a 7960 phone. They can signon to CAD when using CIPC with no problem. Rebooted CUCM and UCCX server and the problem disappeared. However when adding an additional phone, it did not work, so I rebooted the servers again and it fixed that phone but broke one of the original phones that had the problem.
Opened a TAC case and was told that the problem was a config problem with CUCM. How can it be a CUCM problem when the only thing that changed was upgrading from UCCX 8.02 to 8.5.1SU1.
If anyone has a suggestion, I would be greatful, because TAC is not listening to me.
I just had this exact issue.
We upgraded UCCX 126.96.36.19900-37 to 188.8.131.5202-22, and CUCM 184.108.40.20600-1 to 220.127.116.1114-1 last night.
Originally both the softphone and hardphone MAC addresses could exist as a controlled device under my RmCm application users.
However after the upgrade if the directory number is associated with 2 devices we get the above error.
Users can now logon after removing the softphone MAC's from the user and leaving just the hardphones.
David you are very correct about the bugs in current versions. We have upgraded CUCM twice and UCCX once since going into production only 2 weeks ago!! Our customer is not impressed!
You've got my sympathy, Matty. You truly do.
You hit the nail on the head. With any existing customers I had to make sure RmCm only had one entry, where as before I could have an IP Communicator unregistered but assigned to RmCm and still have things work.
The bugs keep coming:
I've been slowly swapping customers over to su2 this week and LDAP Monitor Service and VOIP Monitor Service have still been acting flaky on some. I've got a TAC case going on right now for an issue with su2 integrating with CUPS 8.5.4, and I have a customer that has a TAC case open for the email system randomly deciding when it wants to deliver emails to agents.
A good one I had on Monday was, after the su2 upgrade, any new triggers built were registering with the slave instead of the master, even when we failed from the primary node to the secondary node, it then tried to grab the primary. We had to remove the offending triggers, reboot the servers in order, then new triggers magically started pointing to the correct server.
I would be interested to know the outcome of your TAC case with regards to random email. The reason we upgraded to UCCX su2 was 'CSCsz97295' cannot connect to IMAP via SSL.
Now we have upgraded and I am setting up Email CSQ's but the agent is totally hit and miss!!
Matty, the issue my customer is having appears to be related to the email file size.
Here's a snippet from the Calabrio developer replying to them:
"Based on the current logs, it looks like the problem is cause by EEM service attempting to write a large email to socket to CAD desktop. The email being sent is around 16KB but the socket send buffer is set to 8KB. Since the data is larger than buffer size, it fails to write the whole message in one shot. It does not loop to attempt to send the rest but instead aborts.
There is a newer SplkSocket in a different source code branch (rev 65424) that does do looping if fails to write in 1 shot that is likely to address this issue. We will need to coordinate with others on the fix will.
From the logs, it looks like there is only 1 email of that size in the system. So while waiting for the official fix, as a workaround, manually handle that particular large email manually (i.e. via Outlook) and remove it from the system. Once it is gone, agents will likely not have this issue."
To add another note for anyone that stumbles across this. We have upgraded our CUCM 4+ times and our UCCX 3+ times. We are currently on an ES for CUCM and having shared line errors with our agents when using Extension Mobility. We started with errors similar to the original post and noticed that if the Agent extension only existed on the EM profile we had far better results with logins if we associated the EM and not the physical device to the RMCM user. We also on previous versions had good luck repairing a similar issue by renaming the RMCM user. Good luck!!!!
Well the saga continues: CUCM 18.104.22.16800-2 and CCX 22.214.171.12402-22
- Extention Mobility Agent, Agent can login phone ok
- Confirmed No Shared Lines for CCX Ext:
- Line is configured as 1st Line appearnce.
- EM Profile is assosiated with RMuser
- Device Profile has CTI control enabled
- User has been configured for all CTI groups
Still JTAPI error
Funny thing is configuration worked before upgrade now it does
Following error at the agent desktop with trace runining, think we are running into a bug because CCM config is as documented.....
GetDebugInfo --------------------- Begin: CONTROL_FAILURE_CONF ---------------------
2012-02-10 12:01:09:591 DEBUG [0x8d4] EventHandler.cpp GetDebugInfo: CONTROL_FAILURE_CONF: InvokedID = 3
2012-02-10 12:01:09:591 DEBUG [0x8d4] EventHandler.cpp GetDebugInfo: CONTROL_FAILURE_CONF: FailureCode is CF_GENERIC_UNSPECIFIED
2012-02-10 12:01:09:591 DEBUG [0x8d4] EventHandler.cpp GetDebugInfo: CONTROL_FAILURE_CONF: PeripheralErrorCode is 88001
2012-02-10 12:01:09:591 DEBUG [0x8d4] EventHandler.cpp GetDebugInfo: CONTROL_FAILURE_CONF: Error Text: Unable to login agent due to problems in JTAPI or CM
2012-02-10 12:01:09:591 DEBUG [0x8d4] EventHandler.cpp GetDebugInfo: GetDebugInfo --------------------- End: CONTROL_FAILURE_CONF ---------------------
Also restart the CTI Manager on the CUCM is not the answer! Unity, Paging, 3rd Party Attendant console all use this service should bump those things to fix an Agent log in. We really need a fix for this. TAC Case has not resolved anything thus far.....
Anyone got the Solution to this issue. I can't even get one user login to the system ? TAC has not resolved the issue. anyone can help on this will be a grate help.. I am planing to Role back to 8.0 ?
I just did an upgrade from 4.2 CCM 4.2 Unity and 4.0 IPCC to 8.6 CCM 8.5 Unity connection and 8.5 UCCX. I was getting the same error. When I called TAC they said I should upgrade to 8.5 su2 and that should resolve the issue. After upgrading I had the same issue !!! I didnt have the issue of having 2 phones all users only have 1 phone and 1 line. It was giving me the same error the user is not associated with the rm jtapi user even though they were.
This is what I just did and I can finally get agents to login as I just tested every single one.
I removed all agents from the rmcm user and then re-synced the Jtapi and then added everyone back in.
My Exact version are
UCCX - 126.96.36.19902-22
CCM - 188.8.131.5200-1
Thank you for the reply, i found out my problem, the Phone line button was my issue. i had the agent on line 6, UCCX 8.5 only support line 1 to 4, moved the agent to line 4 fixed the problem,
Thank You to 2nd RTP UCCX TAC tech Ryan, 1st tech guy spend 6 hours no help
Error is "Login failed due to a configuration error with your phone and JTAPI or Unified CM. Contact your administrator"
DN is configured as Line 1 on a 7975 Phone
Where are the mivr logs located now? I am new to UCCX 8x. Looked in RTMT log collection and do not see MIVR logs.
Thanks for the response.
Are there any new workarounds for this problem, I am hitting this same issue on a fresh install. I removed both test agents from rcmc application user, resynched jtapi and added them back. No one agent is working and the other still is not. Both lines are on Button 1. Has this actually been identified as a bug? Using CAD 184.108.40.206 UCCX 220.127.116.1102-22 Thanks!
If you are using Extension mobility the behaviour has changed from 8.0.1. You should associate the UDP instead of the physical device. It is mentionned in bug CSCtx48427 (UCCX: User Device Profiles Should Be Associated to RMJTAPI User). An extract is below.
If using CUCM 8.0.1, associate the agent User Device Profile to the RMJTAPI Provider Application User instead of the physical device.
Starting with CUCM 8.0.1, CTI and JTAPI were enhanced to allow the association of User Device Profiles to the RMJTAPI Provider Application User instead of physical devices. In a solution where agents use Extension Mobility, the User Device Profile should be associated to the Application User instead of the physical device.
In addition, the possibility exists that both CTI and JTAPI believe two devices have the ICD line associated in the below scenario even though one of the devices is unregistered. In this circumstance, JTAPI and CTI believe this to be a shared line and therefore unsupported in UCCX. To mitigate this possibility, the 'Intra-cluster Multiple Login Behavior' Extension Mobility Service Parameter in CUCM should be set to 'Auto Logout'.
Thanks for the help.
"the fix was to un-associate and re-associate their device with the RmCm user." - this worked for me today.
The problem arose when the user got a replacement phone; I checked if that phone was already associated with the RmCm (RMJTAPI user in my case) and it was so I thought they were good to go. But when they got the error message I had to un-associate the device then re-associate it with the RMJTAPI user. After that, the user could login again.
I had a similar issue, after a CUCM upgrade to 8.6.2. All UCCX agent one button login failed with error similar to "Agent is unable to login due to phone configured for IPv6. IPv6 is not supported by IPPA." I set the common device setting to support IPv4, reset phones, unassociated then associated from/to RmCm user. Reset the BIPPA service, CTI service, UCCX serviceability, etc. I ended up going to the phone device setting selecting the one button login service and updating the subscription. This resolved my issue. I don't know if that will help, but it resolved my issue.
I'm finding that when users move between phones (primarily IP Communicators) they are receiving the JTAPI configuration error (We do not have Device profiles assigned to specific devices to allow users to hot desk if neccessary). As with one of the posts above, removing the device they're trying to use from the RMCM user, saving and then re-adding it sometimes fixes it, but I've found in most cases I need to remove the device the user is now trying to use as well as the one they previously used, save the change, then add them back to the RMCM user.
This problem seems to be getting worse, as it was not something that happened everytime an agent moved, but it seems to be heading that way, despite no recent configuration changes (our upgrade to CUCM 18.104.22.16865-1 and UCCX 22.214.171.12402-22 occurred months ago)
Is anyone else seeing this problem occur and is there a know fix rather than the workaround I'm currently using?
I have admittadly been ignoring this thread lately; however, I wanted to point out that CUCM 8.6(2a)SU2 just got posted. Those of you running into errors, esspecially with Extension Mobiilty, may want to patch CUCM to this release. The 8.6 train has had a fair amount of CTI-related defects due to some architectual changes they made under the hood. Two examples are CSCty63127 and CSCty63105.