I believe I have found a bug in Lync 2013 regarding integration with Exchange 2010 and IM. Please let me know if you know of a fix. Also, it would be helpful if someone could try to reproduce this problem and verify they get it too.
Situation: When using Outlook Web Access
to send an IM, and the sending user is homed on a SBS, the IM fails. When
the sending user is homed on the FE pool, it works fine. Also, when the
sending user is homed on a SBS, but uses the Lync client to send the IM, it
works fine.
More details:
Presence in OWA works fine. I am
able to create and send the initial IM from OWA, but never see a response. Also, if I try to send a second line of text
in the same IM chat, I immediately get the error: ‘This message couldn't be
delivered to all recipients because some recipients are offline or don't want
to be disturbed.’
At the same time on the recipient pc – they get the IM toast
and can select to Reply. But when the
chat window opens, there is no message there.
If I try to reply, it takes about 30 seconds to fail with the
message: ‘This message may not have been
delivered to [sender name] because there was no response from the server.’
Environment: Lync 2013 Enterprise pool with 3x FE, and
one Surv. Branch Server. All Lync servers are version 5.0.8308.577. Exchange 2010 SP3. CAS servers have appropriate software
installed for IM/Presence integration: Visual C++2008 (9.0.21022), Ms
OCS 2007 R2, UC Managed API 2.0 Core (3.5.6907.249), Ms OCS 2007 R2, Web
Service Provider (3.5.6907.202)
Testing: I have done extensive
testing and examined all the OCS & Lync logs. The communications failure appears to be the
way the first Front End server receives the Invite from the CAS server and
routs it to the SBS, then another Front End sever, then to the destination client,
but that initial FE server does NOT put a Record-Route entry for itself (FE1). When the 200 OK comes back from the
destination client, the Record-Route sequence is: FE2, SBS. When it reaches the CAS server and it sends
the ACK with Route: SBS, FE, this path does not match signaling path, because
the next hop is the Front End pool, not the SBS. When the Front End pool server gets the ACK,
it fails to route it with these messages:
TL_WARN(TF_DIAG)
[lyncpool31\USPOPLYNCFE32]2CA4.2720::05/01/2014-21:14:59.182.00078419
(SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(805)) [497043544]
$$begin_record
Severity: warning
Text: Cannot process Route headers from a non-trusted
source, or with first Route field in the set not matching the connection on
which the request arrived
Result-Code: 0xc3e93c5e SIPPROXY_E_ROUTING
SIP-Start-Line: ACK
sip:usposvcltu1pool31@blount.com;opaque=user:epid:sj64VsbGTFG0_d8cjdQVEQAA;gruu
SIP/2.0
SIP-Call-ID: 5aa753c0-2b34-4d96-b537-d4fd1276b850
SIP-CSeq: 5294 ACK
Source: blountowa.com:41138
TL_INFO(TF_PROTOCOL)
[lyncpool31\USPOPLYNCFE32]2CA4.2F58::05/01/2014-21:14:59.386.00078443
(SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))
[497043545]
Trace-Correlation-Id: 497043545
Instance-Id: 26A78B7
Direction: outgoing;source="local"
Peer: blountowa.com:41138
Message-Type: response
Start-Line: SIP/2.0 504 Server time-out
From:
<sip:john.crouch@blount.com>;epid=479A82DF66;tag=89a8c153f1
To:
<sip:usposvcltu1pool31@blount.com>;epid=98c5390fbd;tag=0e573d6c71
Call-ID: 5aa753c0-2b34-4d96-b537-d4fd1276b850
CSeq: 5295 MESSAGE
Via: SIP/2.0/TLS
10.20.0.110:41138;branch=z9hG4bK3670b713;ms-received-port=41138;ms-received-cid=10D64000
Content-Length: 0
ms-diagnostics: 1022;reason="Cannot process routing
destination";destination="sip:USPOPLYNCSBS01.BLTDOM.blountopg.com:5061;transport=tls;opaque=state:F:Eu;lr";source="USPOPLYNCFE32.BLTDOM.blountopg.com"
I initially thought it was a problem with the
Trusted Apps and/or certificates, but all those tested fine when the sending
user was homed on the Front End pool.
