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:
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”:
An attempt to send a message to this federated contact will display spinning dots:
… 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.
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”
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”
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
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”
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.
4 Responses
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.
I have the same issue but both pools are internal and we do not have any external connectivity with Lync.
same issue as above with 2 internal pools. Any ideas?
How I wish I was more IT advanced to do what you say here above.