Jabber Directory URI via MRA/UDS

[ruudvanstrijp]

Hi,

We currently have a strange setup where a subset of the users within an Active Directory domain is configured on CUCM 10.5. This subset of users uses the same email domain and Skype presence domain (@domain.com) as all other AD users. Some requirements force us to use a different presence domain on CUCM, so we use '@domaincisco.com' for the CUCM users' presence URI's.

Because of this, we cannot use the 'mail' or 'msRTCSIP-PrimaryUserAddress' LDAP fields for directory URI resolution; those domains differ from the CUCM presence domain. To solve this, we added all users' CUCM presence URI's to LDAP's 'extensionAttribute11' field and use the following line in jabber-config.xml:

   <SipUri>extensionAttribute11</SipUri>

This works perfectly for internal users, since they all use LDAP for their directory lookup of other CUCM users. When users log in externally through MRA, this doesn't work because Jabber then switches to UDS which of course does not know 'extensionAttribute11'. However, CUCM already has the proper presence URI in it's End User list, so if there would be a way to just say "when using UDS, use the CUCM Directory URI for lookup" this would be solved. Is there such a way? As far as I know and can find in the documentation, the 'SipUri' jabber-config setting applies to both UDS and LDAP.

Regards,
Ruud van Strijp

[ruudvanstrijp]

Unfortunately I haven't had a reply on this, but the issue is still valid for me. Basically what I'm asking, is if it is possible for UDS to just use the 'Directory URI' field of the End User to resolve their contact details, instead of the 'mail' field.

The famous <UseSipUriToResolveContacts>true</UseSipUriToResolveContacts> setting enables you to change from <userid>@<defaultdomain> to the use of Directory URI's, but in practice I always see this combined with '<DirectoryURI>mail</DirectoryURI>', which requires us to fill both the End User's Directory URI and Email address. In companies where email addresses are in a different domain than their SIP URI's, this doesn't work.