Lately, I had a unique experience where internally, the desktop sharing function wouldn’t work. In my experience for Office Communications Server 2007/2007 R2 & Lync Server 2010, the most challenging part is to get the Firewall, Network and Application (Lync Administrator) to talk to each other, and right now internally?! Oh well, guess you learn something new everyday.
So before we move on, here’s the environment’s setup:
- Lync Front-End Pool (Enterprise Edition)
- SQL Server 2008 R2
- Access Edge
All these server roles are located in the subnet of 10.21.185.x/24, known as the Production segment; where else the DMZ segment are located in this segment 10.21.151.x/24.
Some information about the 2 endpoints as well:
- Machine A: 10.106.1.180/24
- Machine B: 10.102.1.3/24
Using Two (2) machines, I’d turn on logging for the Lync Communicator at both computers:
I’d also run a the Lync logging from my Front-end Pool using the following options:
- Logging Options: SIPStack
- Flags: TF_COMPONENTS, TF_PROTOCOL, TF_CONNECTION, TF_SECURITY, TF_DIAG, TF_AUTH, TF_PARSE, TF_NETWORK, TF_STACKTRACE, TF_XMLSERIALIZER, All Flags
- Level: All
Hit on the Start Logging button and start initiating the Desktop Sharing session between the 2 endpoints. Waited till both sides receive an error: Cannot start Desktop/Application Sharing due to network issues.
Let’s now stop the Server Logging tool and analyze the output:
Based on the logging from the Pool Server, it seems that the traffic had actually went through the Access Edge and out the Firewall, and at the same time, Lync Server detects that both end points are coming within the same network
To confirm this, I’d to compare the traces from the client side (remember to terminate/exit the Lync Client else there’ll be too many traces to go through):
|12/15/2011|14:03:12.750 2924:3DBC INFO :: Data Received – 10.21.185.110:5061 (To Local Address: 127.0.0.1:61285) 1224 bytes:
12/15/2011|14:03:12.750 2924:3DBC INFO :: BYE sip:10.102.1.3:61286;transport=tls;ms-opaque=aa27651164;ms-received-cid=65000;grid SIP/2.0
Via: SIP/2.0/TLS 10.21.185.110:5061;branch=z9hG4bK9A3A9FCD.0BC4B30DC725C0C3;branched=FALSE;ms-internal-info=”boOIyMcAmFG-ythaXBKF_G5mqkEVyEPJYNLjSG-fSYZFcNs8QLt9KaFAAA”
Authentication-Info: TLS-DSK qop=”auth”, opaque=”8270CF30″, srand=”665E9944″, snum=”32″, rspauth=”6372b9b31f02483372456fc33382720513ae894f”, targetname=”Pool.domain.com”, realm=”SIP Communications Service”, version=4
Via: SIP/2.0/TLS 127.0.0.1:52452;received=10.106.1.180;ms-received-port=52453;ms-received-cid=65100
CSeq: 2 BYE
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)
ms-client-diagnostics: 22; reason=”Call failed to establish due to a media connectivity failure when both endpoints are internal”;CallerMediaDebug=”application-sharing:ICEWarn=0x29,LocalSite=10.106.1.180:3422,LocalMR=10.21.185.113:3478,RemoteSite=10.102.1.3:27735,PortRange=1025:65000,LocalLocation=2,RemoteLocation=2,FederationType=0″
12/15/2011|14:03:12.750 2924:3DBC INFO :: End of Data Received – 10.21.185.110:5061 (To Local Address: 127.0.0.1:61285) 1224 bytes
So, it has been confirmed that the initiated session was actually ‘thrown’ out to the firewall and back to through the Access Edge while the Desktop Sharing session is initiated – so there’re only 2 possibilites for this scenario:
- Firewall: A quick check shows that both endpoints doesn’t have any firewall installed or activated (Windows Firewall)
- Internal VLAN routing: When attempted to ping between the 2 endpoints, the packet doesn’t seem to be reaching each other. So I did a trace route (tracert) from the 10.106.1.0/24 to 10.102.0/24, subnet & also gateway. After 30 hops, it shows that the packet doesn’t reach to its gateway at all
Conclusion, when initiating Desktop Sharing and both endpoints are from the same network (intranet), a peer to peer connection would be established; hence inter-routing between VLAN must be configured.