Contact resolution in Jabber

[KhanalZ]

When I search contacts in Jabber using phone number, it does not resolve to their names even though the users I am searching are all CUCM users. I can search them from deskphone and number to name resolution works fine there. Is there anything I need to do to make it work for Jabber?

[Roger Kallberg]

Jabber does not normally use the data in CM to search for users, it uses the LDAP source that you have configured in CM under service profile(s).

[Jonathan Schulenberg]

Jabber is capable of using CUCM for contact resolution with UDS - but only does this by default over MRA. You would need to change the Service Profile to UDS if you want it to avoid LDAP while on-prem.

IP Phones do not perform number to name resolution however. The phone will display whatever calling/connected identity is conveyed to it by CUCM. For on-net calls that is the Alerting Name and Display Name attributes on the DN. Jabber will do this too if a UDS/LDAP match isn’t found but some features won’t work (eg contact photo, chat reply option in toast, etc.) The Corporate Directory XML Phone Service only searches by name.

Lastly, be mindful that the the calling/called number must match exactly with the phone number on the LDAP user or CUCM End User. You can use Application Dial Rules (outgoing calls) and Directory Lookup Rules (incoming calls), and/or the PhoneNumberMasks Jabber XML parameter to transform calling/called numbers on the fly. The first two options are cluster-wide so they work best when CUCM is either +E.164 or serving sites within a single national numbering plan.

[KhanalZ]

Hi Jonathan, we use UDS in service profile but still Jabber cannot resolve number to names while I do the search.

[KhanalZ]

Thanks for your response. We use UDS as source for contact resolution but I changed that to LDAP and still not working. I am asked by the management to make number to name resolution work and am struggling how to make it happen. We use Telephone number field in AD to sync with CUCM and numbers are in e.164 format.

[DanielFlieth43587]

Hi, is it also your goal that incoming calls will be shown with the name? So you have stored customers or any other external person saved in ldap or sql server? And if this person is calling somebody in your company, the name from the person and not only the number will be shown on ip phone and jabber?

[Carlo Poggiarelli]

Hi @KhanalZ  ,

to allow jabber to resolve names from numbers, you need to enable indexing and ANR for AD telephoneNumber attribute and use an AD as LDAP source

https://techcommunity.microsoft.com/t5/microsoft-entra-blog/indexing-in-active-directory/ba-p/243119

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/12_8/cjab_b_parameter-reference-guide-jabber-128/cjab_b_parameter-reference-guide-jabber-128_chapter_01010.html#reference_2DD20BBF2EE60FA9B5E209DC7AA40D9F

HTH

Regards

Carlo

[Jonathan Schulenberg]

Neither ANR or attribute indexing are relevant with UDS, only Active Directory/LDAP. ANR is only used for partial name search results, not telephone numbers. For example, ANR allows you to type "Smi" (as in Smith) in Jabber and see all users where the character string "smi" appears in their given, surname, or display name attributes. Attribute indexing is critically important with LDAP - Cisco declares it a prerequisite in the config guide - so you don't accidentally DDoS the Domain Controller. The LDAP query would return the same results even if the attribute(s) aren't indexed, just with a much higher load on the LDAP server. Load considerations on the LDAP server are important because every call Jabber receives/places triggers a query.

Back to the OP: why aren't user identities being mapped to calling/called numbers? Something doesn't line up. I'll provide a few illustrative examples but this list isn't exhaustive:

• An incoming call with a calling number of +14045550100 arrives. No Directory Lookup Rules have been configured in CUCM and no PhoneNumberMasks have been defined in jabber-config.xml. Jabber queries UDS (or LDAP) for a user object with a telephone number of "+14045550100". It's always expecting an exact match! If the phone number in UDS (CUCM End User) or LDAP differs in any way - missing the leading plus, whitespace or separator characters, etc. - it won't match. None of these examples would match: "+1 404 555 0100" "+1 (404) 555-0100", etc.
  • It's also worth mentioning that there must be a single user record returned for a given phone number. If UDS or LDAP return multiple search results - which will be in a random order in practice - Jabber will use the first result. This is very misleading to users; they think someone else is calling them! For this reason you should treat phone numbers in UDS (CUCM End User) or LDAP as globally unique!
• An incoming call with a calling number of +14045550100 arrives. A Directory Lookup Rule exists to strip the leading +1 because phone numbers are stored in their nationally significant number format in the directory. No PhoneNumberMasks have been defined in jabber-config.xml though. Jabber queries UDS (or LDAP) for a user object with a telephone number of "4045550100".
• An incoming call with a calling number of +14045550100 arrives. No Directory Lookup Rules have been configured in CUCM. A PhoneNumberMasks has been defined for +1|+1 ### ### #### to allow for space separator characters. Jabber queries UDS (or LDAP) for a user object with a telephone number of "+1 404 555 0100".
  • I don't remember the order of operations when using both, so test that if needed. My guess is the CUCM rule is processed first and the result gets run through PhoneNumberMasks.

Same story for outbound calls but it's an Application Dial Rule instead of a Directory Lookup Rule.

[Carlo Poggiarelli]

Hi,

Here a similar post with a solution on how to resolve numbers to name while searching contacts on Jabber.

https://community.cisco.com/t5/collaboration-applications/jabber-search-for-phone-numbers-extensions/m-p/3718136/highlight/true#M37866

Regards

Carlo

[Jonathan Schulenberg]

Ok, that makes sense since they're typing a phone number into the search field. AFAIK the predictive search logic is not used for the number-to-contact resolution though - and I suspect for a very good reason: it's trying to find a single unique user record. Partial string matches are far more likely to return more than one match.

If @KhanalZ wants to type a partial phone number into the search box of Jabber and see results, then I agree they would have to use Active Directory specifically (OpenLDAP doesn't support ANR) and switch the Service Profile from UDS to CDI (LDAP). This won't work over MRA though since that's UDS only.

[DanielFlieth43587]

@Jonathan Schulenberg very good explanation. For me, the most important tip here is, if you want to have a correct resolved number, the phone numbers should be unique for each entry in your ldap/database.

For incoming calls we solved it with External Call Control Profile(ECCP). With our Solution EasyUC we have the option that you can build a phonebook from different sources (ldap, sql, csv, cucm enduser) which will be used to resolve incoming calls. So call comes in to CUCM, CUCM is sending it via ECCP to us, then in best case we find a name to the number and give back the number. The advantage is, if the user has a Jabber for Win, Jabber for iPhone and also an IP Phone, all 3 phones will show the same information for this incoming call. 

For me this works really well. Also we can block individual numbers, for all users or maybe only for a single user. I really like the ECCP / CURRI API.

[Jonathan Schulenberg]

This seems a bit off-topic for the thread. That wouldn't resolve the calling/called number to another Jabber/IM&P user. That just overwrites the calling name information. For example, it wouldn't enable the chat reply option in the Jabber toast notification.

[DanielFlieth43587]

thats correct, thats only for external calls