Problem
You’ve set up federation between 2 Lync Server 2013 environments but notice that only 1 of the company can see presence information and have the ability to send messages while the other company is unable to see presence information from the other company, unable to send messages but is able to receive messages. Opening up a logging session on the Lync Edge server at the company that is unable to send or see presence information and the logs reveal the following error entries:
**Note that the user tluk@ccs.bm is able to send messages and view presence.
TL_INFO(TF_PROTOCOL) [0]09F8.0C88::10/12/2013-01:39:41.834.00012234 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2436.idx(196))[1741920323] $$begin_record
Trace-Correlation-Id: 1741920323
Instance-Id: 2BDA
Direction: outgoing;source=”internal edge”;destination=”external edge”
Peer: sip.ccs.bm:49487
Message-Type: response
Start-Line: SIP/2.0 200 OK
From: <sip:tluk@ccs.bm>;tag=2187c36e06;epid=25ff4d1f78
To: <sip:ccs@domain.bm>;epid=e69af42711;tag=ca96430b85
Call-ID: afd96a4c19f7408685609405dff39e7d
CSeq: 4 MESSAGE
Contact: <sip:ccs@domain.bm;opaque=user:epid:6m94aPj8T1WXhLvmR6kj4wAA;gruu>
Via: SIP/2.0/TLS 172.16.37.55:49487;branch=z9hG4bK5391C9B0.0FCE7A99208BC946;branched=FALSE;ms-internal-info=”cj7lCn8xAJRUUdlatMoH–sroWxv41foxdQ3JeVVGNT-qZes4PDsNiuwAA”;received=69.17.205.55;ms-received-port=49487;ms-received-cid=43E00
Via: SIP/2.0/TLS 172.16.1.152:51919;branch=z9hG4bK353C6B47.C170580869629948;branched=FALSE;ms-received-port=51919;ms-received-cid=500
Via: SIP/2.0/TLS 172.16.1.211:49162;branch=z9hG4bK9A01874C.B60005E6208AD946;branched=FALSE;ms-received-port=49162;ms-received-cid=8F1700
Via: SIP/2.0/TLS 172.16.58.131:54782;received=199.172.198.55;ms-received-port=57155;ms-received-cid=19F00
Content-Length: 0
$$end_record
TL_ERROR(TF_CONNECTION) [0]09F8.0C64::10/12/2013-01:39:45.516.000122b4 (SIPStack,SIPAdminLog::WriteConnectionEvent:1222.idx(452))[710685110] $$begin_record
Severity: error
Text: Failed to complete outbound connection
Peer-IP: 69.17.205.55:5061
Connection-ID: 0x44103
Transport: TLS
Result-Code: 0x8007274c
Data: fqdn=”sip.ccs.bm”;peer-type=”FederatedPartner”;winsock-code=”10060″;winsock-info=”The peer did not respond to the connection attempt”
$$end_record
TL_ERROR(TF_DIAG) [0]09F8.0C64::10/12/2013-01:39:45.516.000122da (SIPStack,SIPAdminLog::WriteDiagnosticEvent:1222.idx(784))[1836810921] $$begin_record
Severity: error
Text: Message was not sent because the connection was closed
SIP-Start-Line: SUBSCRIBE sip:tluk@ccs.bm SIP/2.0
SIP-Call-ID: 57e81be269b942b2a579617dc94553f0
SIP-CSeq: 1 SUBSCRIBE
Peer: 69.17.205.55:5061
$$end_record
TL_INFO(TF_DIAG) [0]09F8.0C64::10/12/2013-01:39:45.516.0001259d (SIPStack,SIPAdminLog::WriteDiagnosticEvent:1222.idx(778))[1836810921] $$begin_recordSeverity: information
Text: Routed a locally generated response
SIP-Start-Line: SIP/2.0 504 Server time-out
SIP-Call-ID: 57e81be269b942b2a579617dc94553f0
SIP-CSeq: 1 SUBSCRIBE
Peer: lyncstd01.corp.domain.bm:62684
$$end_record
TL_INFO(TF_PROTOCOL) [0]09F8.0C64::10/12/2013-01:39:45.516.000125f5 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2436.idx(196))[1836810921] $$begin_record
Trace-Correlation-Id: 1836810921
Instance-Id: 2BDB
Direction: outgoing;source=”local”;destination=”internal edge”
Peer: prplyncstd01.corp.domain.bm:62684
Message-Type: response
Start-Line: SIP/2.0 504 Server time-out
From: “CCS”<sip:ccs@domain.bm>;tag=7d7ab30b5f;epid=e69af42711
To: <sip:tluk@ccs.bm>;tag=205B29FB0474E9F50009EEADAE695524
Call-ID: 57e81be269b942b2a579617dc94553f0
CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 10.1.70.50:62684;branch=z9hG4bKF368244B.0850C8B18CE9E93B;branched=FALSE;ms-received-port=62684;ms-received-cid=44000
Via: SIP/2.0/TLS 10.1.70.50:62588;ms-received-port=62588;ms-received-cid=300
Content-Length: 0
ms-diagnostics: 1046;reason=”Failed to connect to a federated peer server”;fqdn=”sip.ccs.bm”;peer-type=”FederatedPartner”;winsock-code=”10060″;winsock-info=”The peer did not respond to the connection attempt”;source=”sip.domain.bm”
$$end_record
TL_WARN(TF_DIAG) [0]09F8.0C64::10/12/2013-01:39:45.516.0001263f (SIPStack,SIPAdminLog::WriteDiagnosticEvent:1222.idx(781))[1836810921] $$begin_recordSeverity: warning
Text: Routing error occurred; check Result-Code field for more information
Result-Code: 0xc3e93c7f SIPPROXY_E_ROUTING_MSG_SEND_CLOSED
SIP-Start-Line: SUBSCRIBE sip:tluk@ccs.bm SIP/2.0
SIP-Call-ID: 57e81be269b942b2a579617dc94553f0
SIP-CSeq: 1 SUBSCRIBE
Peer: 69.17.205.55:5061
$$end_record
TL_ERROR(TF_DIAG) [0]09F8.0C64::10/12/2013-01:39:45.516.00012653 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:1222.idx(784))[3012324582] $$begin_recordSeverity: error
Text: Message was not sent because the connection was closed
SIP-Start-Line: NOTIFY sip:tluk@ccs.bm;opaque=user:epid:6478nGN5flqtbdWmNWKPpQAA;gruu SIP/2.0
SIP-Call-ID: b67a5a8669c6498a8b9cff6f03b18d89
SIP-CSeq: 2 NOTIFY
Peer: 69.17.205.55:5061
$$end_record
TL_INFO(TF_DIAG) [0]09F8.0C64::10/12/2013-01:39:45.516.00012917 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:1222.idx(778))[3012324582] $$begin_recordSeverity: information
Text: Routed a locally generated response
SIP-Start-Line: SIP/2.0 430 Flow Failed
SIP-Call-ID: b67a5a8669c6498a8b9cff6f03b18d89
SIP-CSeq: 2 NOTIFY
Peer: lyncstd01.corp.domain.bm:62684
$$end_record
TL_INFO(TF_PROTOCOL) [0]09F8.0C64::10/12/2013-01:39:45.516.0001296d (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2436.idx(196))[3012324582] $$begin_recordTrace-Correlation-Id: 3012324582
Instance-Id: 2BDC
Direction: outgoing;source=”local”;destination=”internal edge”
Peer: prplyncstd01.corp.domain.bm:62684
Message-Type: response
Start-Line: SIP/2.0 430 Flow Failed
From: <sip:ccs@domain.bm>;tag=23480080
To: <sip:tluk@ccs.bm>;tag=e3520bfb35;epid=25ff4d1f78
Call-ID: b67a5a8669c6498a8b9cff6f03b18d89
CSeq: 2 NOTIFY
Via: SIP/2.0/TLS 10.1.70.50:62684;branch=z9hG4bK1A7CF1F8.E103137E90058948;branched=FALSE;ms-received-port=62684;ms-received-cid=44000
Content-Length: 0
ms-diagnostics: 1046;reason=”Failed to connect to a federated peer server”;fqdn=”sip.ccs.bm”;peer-type=”FederatedPartner”;winsock-code=”10060″;winsock-info=”The peer did not respond to the connection attempt”;source=”sip.domain.bm”
$$end_record
Solution
There wasn’t a whole lot I could find through searching the error messages so through logically thinking about it, what appeared to be the problem was that the company that could not send messages or see presence information was sending information out but wasn’t receiving any information back (hence the The peer did not respond to the connection attempt messages). Seeing how the other company that was able to send and see presence information was federated with other partners and was working properly, I figured it was probably because the other company probably had an outbound port blocked. A quick telnet via port 443 from the Edge server of the company that wasn’t able to send messages or receive presence information revealed that this was indeed the case and 443 was blocked. Once the Edge server was allowed TCP 443 outbound, the problem went away.
3 Responses
Hi Terence,
I am looking to do the same thing BUT on purpose. We want to enable IM and Presence in one direction only. That is Company A shall be able to see presence and send IMs to Company B users, but Company B shall not be able to do the same with Company A.
Any ideas?
I've heard that Verba is making an Ethical wall for Lync/SfB/Cisco which will be ready in the near future that can do this (and many other) features. http://www.verba.com/
I am hoping you still look at this blog. I have a similar issue, but I can see all attempts at messaging, but cannot respond. The federated partners show Presence Unknown to my internal clients, but their presence showing up in the Lync client of the federated partners. I see 443 traffic in the firewall to and from the Lync Edge server in the DMZ. But I do not see any 5061 traffic. We have been having trouble with the server, and as of last Friday AM the 5061 traffic was not sent by the Lync server any more, after a steady stream of 5061 traffic since the Edge server was set up. I have not changed any of the firewall rules. This system was working for 3 years.
It is as if the Lync client does not even try to respond to the message. What would cause that?