[cisco-voip] Jabber 11.6.1 & 11.6.2 | Slow Outlook Contact Resolution & Presence

[Ryan Huff]

Dan, I think (need to confirm this in logs tomorrow) but I think you may just have saved me some grind time troubleshooting an issue I'm having in J4W 11.6.1 that appears very similar to this, thanks!

Very happy to see your traffic lately on the list; I always learn a TON from you :).

-Ryan
On Jul 28, 2016, at 9:42 PM, Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>> wrote:

I haven't contributed to the forum as must as I had previously, but wanted to give a quick heads up on an issue that might easily be affecting users/customers with Jabber 11.6.x. While the root cause details are not fully explained, there's an internal defect that describes an issue where Jabber experiences slow contact resolution for Outlook presence status - CSCva40039. The user-facing issue is that an email is created or opened and, when Outlook contacts (that are non-Jabber contacts) are displayed or typed in, the presence status can take tens of seconds to multiple minutes before it's displayed.

>From a more technical standpoint, what's occurring is that Outlook sends a request to Jabber to resolve the contacts needing presence status displayed and, after the request is received, the LDAP query (this affects EDI/BDI) will be queued and won't be sent for an extended period of time. Only after this extended period of time (and successful contact resolution) will Jabber then finally use XMPP to obtain presence status. The long queue before sending the resolution request will cause presence status to in Outlook to appear extremely delayed or non-existent. Again, this will impact presence status for Outlook contacts *not* already on a user's Jabber contact list or at least locally cached.

Workflow:
Outlook e-mail is created >> Contact added to To: field >> Outlook requests contact resolution and presence from Jabber on user in To: field >> Jabber uses the full SIP proxyAddress for resolving the contact against LDAP using mail attribute >> IF SIP proxyAddress doesn't exist, Jabber uses primary SMTP address instead (at least, in 11.5 lab testing) >> IF contact resolution fails using the full proxyAddress, Jabber takes the *user* portion of the proxyAddress attribute for resolving the contact against LDAP using sAMAccount >> Contact is resolved through one of these queries and then retrieves presence from IM&P using the SIP proxyAddress (which must match JID) >> Presence status provided to Outlook

Details:
Jabber logs will show it receives the contact resolution request from Outlook -- search for "GetContactByUri request for <address>", where <address> is the SIP proxy address assigned to the AD user object. If the user object doesn't have a SIP URI added to the proxyAddress attribute, then this address will be the primary SMTP address. Once you find this line, document the timestamp for when it occurred. Then, search the jabber.log file(s) for the LDAP query that's responsible for contact resolution -- by default this will look like "[EMAIL_QUERY] with parameter [<proxyAddress>]", and below this you should see the actual query for the user object against mail. If this LDAP query fails for resolving Outlook contacts for presence, a follow-up query will be sent for a user object using User ID against sAMAccount.

What's important is that if you're hitting CSCva40039, which is still in progress, then the time between the contact resolution request from Outlook and the actual LDAP query for resolution should be significant, whereas a working scenario should be measureable in milliseconds. Note this is not related to attribute indexing and the performance issues observed when indexing is disabled. Indexing proper attributes will not speed this up as the delay is in sending the query, as opposed to completing the query. This is observable in 11.6.1 and 11.6.2, but not 11.5.2.

Somewhat related -- also note that Outlook contact resolution and presence is not currently possible when using UDS as a contact source *and* the contact in question is not in your contact list.

Hopefully this helps someone who comes across this thread in e-mail or a web search at some point in time.

- Dan
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160729/70b1e1d0/attachment.html>