Freigeben über

Desktop sharing fails between federated contacts running Lync 2010 clients

  • Artikel

I would like to talk about another Lync 2010 problem where desktop sharing was failing between two federated contacts. Network traces and Lync ETL traces were collected while reproducing the problem. Here’s the troubleshooting steps that I followed:

 

ANALYSIS:

========

Note: Please note that usernames, IP addresses, server names etc are all replaced for privacy purposes.

 

Client IP: 10.98.2.1 (this is the client that initiates desktop sharing)

FE server IP: 10.10.10.1

Edge server internal IP: 10.3.0.34

Edge server external IP: 10.3.0.40

Edge server external IP (NATed): 2.2.2.2

Remote Edge server IP: 1.1.1.1

 

 1) I started with Lync client side ETL trace. It negotiates the application sharing media port with the help of Edge server:

 

=> Application sharing request sent by the internal client:

 

12/10/2012|10:43:06.703 24F8:2648 INFO :: Sending Packet - 10.10.10.1:5061 (From Local Address: 10.98.2.1:51647) 2520 bytes:

12/10/2012|10:43:06.703 24F8:2648 INFO :: INVITE sip:user2@fabrikam.com SIP/2.0

Via: SIP/2.0/TLS 10.98.2.1:51647

Max-Forwards: 70

From: <sip:user1@contoso.com>;tag=2cd64ff7dc;epid=6750f01948

To: <sip:user2@fabrikam.com>

Call-ID: a622d7b9f6464be3a455e6d98ec700b3

CSeq: 1 INVITE

Contact: <sip:user1@contoso.com;opaque=user:epid:lxH-F4F2KFaOdejdehenrlAAA;gruu>

User-Agent: UCCAPI/4.0.7577.4356 OC/4.0.7577.4356 (Microsoft Lync 2010)

Supported: ms-dialog-route-set-update

Supported: timer

Supported: histinfo

Supported: ms-safe-transfer

Supported: ms-sender

Supported: ms-early-media

Supported: ms-conf-invite

Ms-Conversation-ID: Ac3Wuri73DV0XRhGRBSO/PHZU2QhhQ==

ms-keep-alive: UAC;hop-hop=yes

Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS

ms-subnet: 10.98.22.0

ms-endpoint-location-data: NetworkScope;ms-media-location-type=Intranet

...

 

v=0

o=- 0 0 IN IP4 2.2.2.2

s=session

c=IN IP4 2.2.2.2

b=CT:99980

t=0 0

m=applicationsharing 58138 TCP/RTP/AVP 127

a=ice-ufrag:PFb1

a=candidate:1 1 TCP-PASS 2120613887 10.98.2.1 21916 typ host

a=candidate:1 2 TCP-PASS 2120613374 10.98.2.1 21916 typ host

a=candidate:2 1 TCP-ACT 2121006591 10.98.2.1 18574 typ host

a=candidate:2 2 TCP-ACT 2121006078 10.98.2.1 18574 typ host

a=candidate:3 1 TCP-PASS 6556159 2.2.2.2 58138 typ relay raddr 10.98.2.1 rport 13211

a=candidate:3 2 TCP-PASS 6556158 2.2.2.2 58138 typ relay raddr 10.98.2.1 rport 13211

...

 

=> Final response:

 

12/10/2012|10:43:10.418 24F8:2648 INFO :: Data Received - 10.10.10.1:5061 (To Local Address: 10.98.2.1:51647) 4311 bytes:

12/10/2012|10:43:10.418 24F8:2648 INFO :: SIP/2.0 200 OK

Authentication-Info: TLS-DSK qop="auth", opaque="2957C393", srand="ACCCF975", snum="68", rspauth="8dad7b71a068c9ec073868375fcd97955d8dd4bf", targetname="fepool01.contoso.com", realm="SIP Communications Service", version=4

Via: SIP/2.0/TLS 10.98.2.1:51647;ms-received-port=51647;ms-received-cid=657300

From: "user1 @ contoso.com"<sip:user1@contoso.com>;tag=2cd64ff7dc;epid=6750f01948

To: <sip:user2@fabrikam.com>;epid=c23c88d032;tag=fef0c3e438

Call-ID: a622d7b9f6464be3a455e6d98ec700b3

CSeq: 1 INVITE

...

Contact: <sip:user2@fabrikam.com;opaque=user:epid:wyPrDAU4lVq4GhmnrWqEFgAA;gruu>

User-Agent: UCCAPI/4.0.7577.4356 OC/4.0.7577.4356 (Microsoft Lync 2010)

Supported: histinfo

Supported: ms-safe-transfer

Supported: ms-dialog-route-set-update

Supported: ms-conf-invite

Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS

Session-Expires: 720;refresher=uac

ms-client-diagnostics: 51007;reason="Callee media connectivity diagnosis info";CalleeMediaDebug="application-sharing:ICEWarn=0x0,LocalSite=10.166.24.59:8541,LocalMR=1.1.1.1:50704,RemoteSite=10.98.2.1:21916,RemoteMR=2.2.2.2:58138,PortRange=50040:50059,LocalMRTCPPort=50704,RemoteMRTCPPort=58138,LocalLocation=1,RemoteLocation=2,FederationType=1"

ms-endpoint-location-data: NetworkScope;ms-media-location-type=Internet

...

 

v=0

o=- 0 0 IN IP4 1.1.1.1

s=session

c=IN IP4 1.1.1.1

b=CT:99980

t=0 0

m=applicationsharing 50704 TCP/RTP/SAVP 127

a=ice-ufrag:G/Yw

a=ice-pwd:EwhnzgwKgaoRuI2T2gKRRqYz

a=candidate:1 1 TCP-PASS 2120613887 10.26.10.50 50058 typ host

a=candidate:1 2 TCP-PASS 2120613374 10.26.10.50 50058 typ host

...

 

So we expect the media session to flow between 1.1.1.1 :50704 <---> 2.2.2.2:58138 (between the two Edge servers: Edge server @ contoso.com and Edge server @ fabrikam.com)

On the other hand, the internal client from where the user (user1@contoso.com) signed in will be accessing the Edge server @ contoso.com at TCP 443 (Mediarelay service listens on internal interface of the Edge server as well)

 

In summary, the communication should be as follows:

 

Flow1:

Internal client <--- > Edge server @ consoto.com internal interface:443

 

Flow2:

Edge server external interface (contoso.com) <---> Edge server external interface (fabrikam.com) (1.1.1.1 :50704 <---> 2.2.2.2:58138)

 

a) When I check the trace collected on Edge server, I see that the client has a successful session with the internal interface of the Edge server @ TCP 443:

 

No. Time Delta Source Destination Protocol Length Info

    344 2012-12-10 10:43:49.130 0.000 10.98.2.1 10.3.0.34 TCP 66 13211 > 443 [SYN] Seq=2226089608 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

    345 2012-12-10 10:43:49.130 0.000 10.3.0.34 10.98.2.1 TCP 66 443 > 13211 [SYN, ACK] Seq=3794450141 Ack=2226089609 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

    346 2012-12-10 10:43:49.131 0.000 10.98.2.1 10.3.0.34 TCP 60 13211 > 443 [ACK] Seq=2226089609 Ack=3794450142 Win=65536 Len=0

    347 2012-12-10 10:43:49.181 0.049 10.98.2.1 10.3.0.34 TLSv1 104 Client Hello

    348 2012-12-10 10:43:49.181 0.000 10.3.0.34 10.98.2.1 TLSv1 137 Server Hello, Server Hello Done

    349 2012-12-10 10:43:49.234 0.053 10.98.2.1 10.3.0.34 TLSv1 178 Ignored Unknown Record

    350 2012-12-10 10:43:49.234 0.000 10.3.0.34 10.98.2.1 TLSv1 189 Ignored Unknown Record

    354 2012-12-10 10:43:49.286 0.051 10.98.2.1 10.3.0.34 TLSv1 240 Ignored Unknown Record

    355 2012-12-10 10:43:49.286 0.000 10.3.0.34 10.98.2.1 TLSv1 178 Ignored Unknown Record

    358 2012-12-10 10:43:49.480 0.194 10.98.2.1 10.3.0.34 TCP 60 13211 > 443 [ACK] Seq=2226089969 Ack=3794450484 Win=65280 Len=0

    420 2012-12-10 10:43:53.067 3.586 10.98.2.1 10.3.0.34 TLSv1 328 Ignored Unknown Record

...

 

b) But the Edge server @ contoso.com fails to connect to Edge server @ fabrikam.com at the negotiated port:

Note: Since this trace is collected on Edge server, we see the private IP address (10.3.0.40) assigned to external interface of the AV Edge service on Edge server.

 

No. Time Delta Source Destination Protocol Length Info

   1299 2012-12-10 10:43:59.456 0.000 10.3.0.40 1.1.1.1 TCP 66 58138 > 50704 [SYN] Seq=3074395695 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

   1300 2012-12-10 10:43:59.499 0.042 1.1.1.1 10.3.0.40 TCP 60 50704 > 58138 [RST, ACK] Seq=0 Ack=3074395696 Win=0 Len=0

   1353 2012-12-10 10:44:00.002 0.503 10.3.0.40 1.1.1.1 TCP 66 58138 > 50704 [SYN] Seq=3074395695 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

   1356 2012-12-10 10:44:00.044 0.042 1.1.1.1 10.3.0.40 TCP 60 50704 > 58138 [RST, ACK] Seq=0 Ack=3074395696 Win=0 Len=0

   1360 2012-12-10 10:44:00.548 0.503 10.3.0.40 1.1.1.1 TCP 62 58138 > 50704 [SYN] Seq=3074395695 Win=8192 Len=0 MSS=1460 SACK_PERM=1

   1361 2012-12-10 10:44:00.590 0.042 1.1.1.1 10.3.0.40 TCP 60 50704 > 58138 [RST, ACK] Seq=0 Ack=3074395696 Win=0 Len=0

 

it gets a TCP RST to its connection attempts (like frame #1300, frame #1356, frame #1361). So the media session (application sharing) couldn’t be established.

 

We have to allow Edge server so that it could establish outbound TCP connections within this range for media communications:

 

https://technet.microsoft.com/en-us/library/gg425891(v=ocs.14).aspx Reference Architecture 1: Port Summary for Single Consolidated Edge

 

 

 

 

Summary:

========

After further investigation by our customer’s networking team, it was found out that the checkpoint firewall was not allowing outbound TCP connections in 50000-59999 port range and hence application sharing was failing.

 

Hope this helps you in resolving similar problems...

 

Thanks,

Murat

Comments

  • Anonymous
    July 15, 2014
    Thanks alot...Really helpful article!!!
  • Anonymous
    December 08, 2015
    good article