Unable to send instant messages or view presence information for federated partner in Lync Server 2013

Problem

You’ve configured federation between two Lync Server 2013 environments and noticed that one of the organizations can send instant messages and see presence information but the other one cannot.  The following is the organization that can send instant messages and see presence:

image

While the other company displays a globe indicating that the user is a federated contact and is able to receive messages, presence information is labeled as “unknown”:

clip_image001[4]

An attempt to send a message to this federated contact will display spinning dots:

clip_image001[6]

… then subsequently fail with the message:

When contacting your support team, reference error ID 504 (source ID 239).

Troubleshooting information is available online, including best practices for using Lync.
Test
When contacting your support team, reference error ID 1 (source ID 0).

Troubleshooting information is available online, including best practices for using Lync.

clip_image001[8]

A quick debugging session with the logging tool on the front end server of the user who is unable to send or see presence information will show the following:

TL_INFO(TF_PROTOCOL) [0]0C88.14F4::04/24/2013-22:53:16.498.0000358e (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2387.idx(196))[2663723319] $$begin_record

Trace-Correlation-Id: 2663723319

Instance-Id: 271E

Direction: incoming

Peer: svrgalyncedge01.ganet.internal:5061

Message-Type: response

Start-Line: SIP/2.0 430 Flow Failed

From: <sip:tluk@lyncNOT-WorkingDomain.bm>;tag=BE180080

To: <sip:tluk@lyncWorkingDomain.bm>;tag=0da93f28e3;epid=c0f4c0bf1f

Call-ID: 6c22e601bf384fbcb7aad1e83cf0ce57

CSeq: 2 NOTIFY

Via: SIP/2.0/TLS 10.99.1.33:54576;branch=z9hG4bK233B2AEC.2289D0E28FA1DC67;branched=FALSE;ms-received-port=54576;ms-received-cid=900

Content-Length: 0

ms-diagnostics: 1046;reason=”Failed to connect to a federated peer server”;fqdn=”sip.lyncWorkingDomain.bm”;peer-type=”FederatedPartner”;winsock-code=”10060″;winsock-info=”The peer did not respond to the connection attempt”;source=”sip.lyncNOT-WorkingDomain.bm”

image

TL_INFO(TF_PROTOCOL) [0]0C88.14F4::04/24/2013-22:53:16.529.0000391f (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2387.idx(196))[3715596209] $$begin_record

Trace-Correlation-Id: 3715596209

Instance-Id: 271F

Direction: incoming

Peer: svrgalyncedge01.ganet.internal:5061

Message-Type: response

Start-Line: SIP/2.0 504 Server time-out

From: “Terence Luk”<sip:tluk@lyncNOT-WorkingDomain.bm>;tag=8831ef87b3;epid=5f9c85c89d

To: “Terence Luk”<sip:tluk@lyncWorkingDomain.bm>;tag=0d2e9aac10;epid=c0f4c0bf1f

Call-ID: 9ff1cec1aa4e45cb89a737719a3a64dd

CSeq: 8 INFO

Via: SIP/2.0/TLS 10.99.1.33:54576;branch=z9hG4bK80E90095.A9B38655901FAC69;branched=FALSE;ms-received-port=54576;ms-received-cid=900

Via: SIP/2.0/TLS 10.99.1.33:49485;ms-received-port=49485;ms-received-cid=400

Content-Length: 0

ms-diagnostics: 1046;reason=”Failed to connect to a federated peer server”;fqdn=”sip.lyncWorkingDomain.bm”;peer-type=”FederatedPartner”;winsock-code=”10060″;winsock-info=”The peer did not respond to the connection attempt”;source=”sip.lyncNOT-WorkingDomain.bm”

image

TL_INFO(TF_DIAG) [0]0C88.14F4::04/24/2013-22:53:16.529.00003e8a (SIPStack,SIPAdminLog::WriteDiagnosticEvent:1198.idx(778))[3715596209] $$begin_record

Severity: information

Text: Response successfully routed

SIP-Start-Line: SIP/2.0 504 Server time-out

SIP-Call-ID: 9ff1cec1aa4e45cb89a737719a3a64dd

SIP-CSeq: 8 INFO

Peer: 10.99.1.33:49485

Data: destination=tluk@lyncNOT-WorkingDomain.bm

image

TL_INFO(TF_PROTOCOL) [0]0C88.14F4::04/24/2013-22:53:16.529.00003ee0 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2387.idx(196))[3715596209] $$begin_record

Trace-Correlation-Id: 3715596209

Instance-Id: 271F

Direction: outgoing

Peer: 10.99.1.33:49485

Message-Type: response

Start-Line: SIP/2.0 504 Server time-out

From: “Terence Luk”<sip:tluk@lyncNOT-WorkingDomain.bm>;tag=8831ef87b3;epid=5f9c85c89d

To: “Terence Luk”<sip:tluk@lyncWorkingDomain.bm>;tag=0d2e9aac10;epid=c0f4c0bf1f

Call-ID: 9ff1cec1aa4e45cb89a737719a3a64dd

CSeq: 8 INFO

Via: SIP/2.0/TLS 10.99.1.33:49485;ms-received-port=49485;ms-received-cid=400

Content-Length: 0

ms-diagnostics: 1046;reason=”Failed to connect to a federated peer server”;fqdn=”sip.lyncWorkingDomain.bm”;peer-type=”FederatedPartner”;winsock-code=”10060″;winsock-info=”The peer did not respond to the connection attempt”;source=”sip.lyncNOT-WorkingDomain.bm”

clip_image001[10]

Solution

After reviewing the logs, I decided to test the port connectivity from the Edge servers and noticed that the Edge server for the organization that wasn’t able to send messages or see presence information was unable to telnet to the federated partner’s Edge server SIP URL via port 5061 even though it was able to connect via 443.  This began to make sense as the problematic organization could see the globe indicating the contact was a federated partner but was unable to message or see presence information.  A quick change in the firewall rule and confirming that the Edge server for the problematic organization was able to connect via port 5061 corrected this problem.

clip_image001[12]

clip_image001[14]

4 Responses

  1. Hi Terence,
    I am having the same problem with another domain. they are able to send messages to us, but we cannot reply. i get the error below
    This message wasn't sent because @microsoft.com doesn't have permissions on your organization's network, or because the address is incorrect. Please contact your support team.
    hi
    I'm able to telnet to their sip address on port 5061 from my edge server, and I've added their addresses to my Federated Domains list.
    Thanks.

  2. I have the same issue but both pools are internal and we do not have any external connectivity with Lync.