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 188.8.131.5200-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.
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 184.108.40.20600-37 to 220.127.116.1102-22, and CUCM 18.104.22.16800-1 to 22.214.171.12414-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!!