[prev in list] [next in list] [prev in thread] [next in thread]
List: cisco-voip
Subject: Re: [cisco-voip] Jabber 11.6.1 & 11.6.2 | Slow Outlook Contact Resolution & Presence
From: Ryan Huff <ryanhuff () outlook ! com>
Date: 2016-07-29 1:53:16
Message-ID: BLUPR18MB04824188F97228BC6ED17B17C5010 () BLUPR18MB0482 ! namprd18 ! prod ! outlook ! com
[Download RAW message or body]
Dan, I think (need to confirm this in logs tomorrow) but I think you may ju=
st 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 fro=
m you :).
-Ryan
On Jul 28, 2016, at 9:42 PM, Daniel Pagan <dpagan@fidelus.com<mailto:dpagan=
@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/c=
ustomers with Jabber 11.6.x. While the root cause details are not fully exp=
lained, there's an internal defect that describes an issue where Jabber exp=
eriences slow contact resolution for Outlook presence status - CSCva40039. =
The user-facing issue is that an email is created or opened and, when Outlo=
ok contacts (that are non-Jabber contacts) are displayed or typed in, the p=
resence status can take tens of seconds to multiple minutes before it's dis=
played.
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 Jabb=
er then finally use XMPP to obtain presence status. The long queue before s=
ending the resolution request will cause presence status to in Outlook to a=
ppear extremely delayed or non-existent. Again, this will impact presence s=
tatus 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 usin=
g mail attribute >> IF SIP proxyAddress doesn't exist, Jabber uses primary =
SMTP address instead (at least, in 11.5 lab testing) >> IF contact resoluti=
on fails using the full proxyAddress, Jabber takes the *user* portion of th=
e proxyAddress attribute for resolving the contact against LDAP using sAMAc=
count >> Contact is resolved through one of these queries and then retrieve=
s presence from IM&P using the SIP proxyAddress (which must match JID) >> P=
resence status provided to Outlook
Details:
Jabber logs will show it receives the contact resolution request from Outlo=
ok -- search for "GetContactByUri request for <address>", where <address> i=
s 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 addre=
ss 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 wi=
ll look like "[EMAIL_QUERY] with parameter [<proxyAddress>]", and below thi=
s 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 pr=
ogress, then the time between the contact resolution request from Outlook a=
nd the actual LDAP query for resolution should be significant, whereas a wo=
rking scenario should be measureable in milliseconds. Note this is not rela=
ted to attribute indexing and the performance issues observed when indexing=
is disabled. Indexing proper attributes will not speed this up as the dela=
y is in sending the query, as opposed to completing the query. This is obse=
rvable 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 cont=
act in question is not in your contact list.
Hopefully this helps someone who comes across this thread in e-mail or a we=
b search at some point in time.
- Dan
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div>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!</div> <div><br>
</div>
<div>Very happy to see your traffic lately on the list; I always learn a TON from you \
:).</div> <div><br>
</div>
<div>-Ryan</div>
<div>On Jul 28, 2016, at 9:42 PM, Daniel Pagan <<a \
href="mailto:dpagan@fidelus.com">dpagan@fidelus.com</a>> wrote:<br> <br>
</div>
<blockquote type="cite">
<div>
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">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.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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 \
*<b>not</b>* already on a user’s Jabber contact list or at least locally \
cached.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Workflow:<o:p></o:p></p>
<p class="MsoNormal">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<o:p></o:p></p> <p \
class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Details:<o:p></o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Somewhat related -- also note that Outlook contact resolution \
and presence is not currently possible when using UDS as a contact source \
*<b>and</b>* the contact in question is not in your contact list.<o:p></o:p></p> <p \
class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Hopefully this helps \
someone who comes across this thread in e-mail or a web search at some point in \
time.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">- Dan<o:p></o:p></p>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>cisco-voip mailing list</span><br>
<span><a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a></span><br>
<span><a href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a></span><br>
</div>
</blockquote>
</body>
</html>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
--===============5443861719020889604==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic