We use Jabber (via Expressway mainly) and we have an overlapping dial plan, seperated by partitions. The extension numbers 1001 through 1050 exist in several partitions, the users in each partition can dial each other internally but not dial by extension between partitions.
Anyway, we are using Jabber and the Caller ID for users who have the same extension number are showing up with random names.
i.e. Joe Blogs and Sarah Smith both use x1002, they are in separate partitions but both use Jabber.
If Joe were to dial somebody else in his own partition (x1005 for example), the caller id comes up as Sarah Smith.
I have created a UC Service Profile with the 'Directory Profile' set to None but the issue is still there.
How does Jabber know which Caller ID to use? I assumed LDAP but with directory profile switched off, its still coming up as another user!
The Caller ID on the line for the CSF device is set correctly as the users name.
MRA forces users to use UDS, LDAP is not used over MRA for directory resolution.
BUT, you would in all probabilities have the same problem if you have your users in LDAP with the same DN configured as well and on-prem.
Jabber will go to the directory, and try to match the ANI to a user, and if the same number is used by more than one user, it will show whoever showed up first during the search.
There is no way around this, specially if using MRA as UDS is a flat directory.
If the users are not meant to dial each other, for on-prem, you could adjust the search base for each group, so they can only look at their own group in an OU, and get the right name.
The only real workaround, is to avoid this particular scenario on which more than one user, has the same DN in LDAP/CUCM.
If I were to blank out the Tel number field in CUCM for the MRA users so nobody had one, would Jabber use the Caller ID configured on the line itself? The users know their colleagues internal extensions so there is little benefit in the Tel Number field being in there, especially if its causing this issue.
I am less worried about the non MRA users as there are only a couple, the bulk use MRA.
I just want Jabber to use the Caller ID configured on the line and if removing all the Tel Number entries in the CUCM end user fields is the way to go, I am happy to do this. Even if it means the users can't search the directory for their colleagues.
Just did a quick test, you'll need to test this over MRA as I'm doing some maintenance to that in my lab.
For on-prem, I deleted the phone number for a user in LDAP, I can see that, as I no longer see the E.164 in Jabber for that user, but since I'm also using URIs associated to the DNs, I only see his URI for calls, so I'm still able to call him.
And I got the right name when calling, from the user without phone number, to other user.
Brill, I will go through and delete the Tel Numbers from the end users and get our users to test it.
At head office our numbers do not overlap so I will create a dummy user in one of their partitions which has one of the common directory numbers and see what happens...
Thanks for your help
we have a same problem, but users are imported from multiple active directories, each with different domain name, so userID in CUCM is unique and in format firstname.lastname@example.org. However, each domain users use 4-digit IP telephony numbers, they are defined in MS AD as IP phone field, so numbers are overlaping. Each domain is sepearated with partitions and css-es and everything working fine, until now when users requests to implement Jabber MRA.
Now, we have a big problem, and it is not easy to change numbering plan or numbers in IP phone field because a lot of other applications are using it.
Why is not possible to just ignore any directory search for contacts and using only name that appears on configured line? Can this be implement in any future version of Cisco Jabber for mobile?
If you want to place a request for something to be considered for the future, you need to reach out to your SE/AM to submit a PER.
The way Jabber was designed, is to work as you see right now (contact resolution from directory), if you want to understand the logic that was behind that, you would need to discuss that directly with the BU, and that would also be via your SE/AM.