Share via

Skype for Business Troubleshooting: We couldn’t connect to the presentation because of network issues

  • Article

All Skype for Business Clients from remote locations were unable to present the screen sharing through meet now, peer to peer and conference. This a new deployment and users were unable to present desktop.

Test scenarios

  1. from remote users n/w to my home n/w – received error (we couldn’t connect to the presentation because of n/w issues. Please try again later)
  2. from remote users n/w to my office n/w – received error (we couldn’t connect to the presentation because of n/w issues. Please try again later)

Troubleshooting

  1. Did a telnet to lyncdiscover.domain.com on port 80 and 443. (This was done just to make sure the clients when logging in gets all the updated info of the pool, SFB config etc.)
  2.  Did a telnet to meet.domain.com on port  443 – successful
  3.  Did a telnet to join.domain.com on port  443 – successful
  4. Did a telnet to av.domain.com on 443 successful

Scenario

Assume the below scenario deployment:

  1. The edges were in DNSLB and were in scaled consolidated topology using NAT.
  2. UDP 3478 for AV service external IP.
  3. TCP 443 for external IP’s.
  4.  Port 50000 was blocked in my case since no legacy OCS clients.
  5. No edge hair pin traffic is allowed for Audio and Video Public IPs.

https://exchangequery.files.wordpress.com/2016/12/dmzsc12.png?w=600

Did a Snooper trace from the affected remote client and got the following info on the snooper logs.

Getting error as 

call failed due to media connectivity failure when both the end points are remote.

https://exchangequery.files.wordpress.com/2016/12/snoop.png?w=600

This is the time to dig into the analysis of which protocol fashion the SFB clients establishes the connection. So started to explore on STUN, TURN & ICE since was having a glossy look on these topics.

Protocols

SFB/Lync uses all these 3 protocols to establish a media connectivity:

  1. ICE: The stands for Interactive Connectivity Establishment protocol for communications. All Lync/SFB clients are ICE clients and use ICE to try and establish connectivity between itself and another ICE client. Remember this is the main protocol which functions as the core and wraps the other two to establish a path.
  2. STUN: The new name for this acronym is Session Traversal Utilities for NAT. This will allow the SFB client to discover the available public IP for the SFB media path in order to establish the connectivity.
  3. TURN: Traversal Using Relay around NAT. This will establish a chain of connection between the external client and the client inside the network. By using this, edge servers will create a chain and will offer ports on UDP and TCP for the media path. Once this chain is established it promises the remote client to send its media connection to the internal network client.

So now we can understand clearly that the External Corporate firewall requires a Hairpin traffic to be allowed for the A/V edge Public IPs for the STUN and TURN to work in the required  UDP TCP path.

Since these are the most commonly used RFC standard protocols SFB clients also use them. These all are IETF standards protocols and hence Microsoft also uses them.

Process to establish a media connectivity with the remote client

Now the SFB clients will use the below process to establish a media connectivity with the remote client:

  • Candidate Discovery: Where the clients discover their available public IP addresses for media connectivity. These include both STUN and TURN addresses of the Edge server.
  • Candidate Exchange: This is the place where both the SFB clients send each other lists of addresses on which they can be communicated for this media path. Remember this will be bidirectional.
  • Connectivity Checks: This is where both the candidates(clients) try to establish a connection on all these addresses simultaneously (not one by one). Finally, the result would be the SFB client will pick any one of the available routes and establish a connection with the client whoever is responding first.
  • Candidate Promotion: This is the Final stage of the SFB client and happens after the call is established and its running. Here the clients if identify any path which is more optimum and quick they decide to change that route which gives the better experience to the user.

This candidate information can be seen in snooper logs

Candidate information

We can see three types of candidate information:

The first one below is for port 50000 and can be ignored if you are not having this option.

https://exchangequery.files.wordpress.com/2016/12/dmzsc1.png?w=600

The second one is for audio and the last one will be for video. We will have the same like one for audio with label main mentioned as audio.

https://exchangequery.files.wordpress.com/2016/12/dmzsc11.png?w=600

Let's say if we have only port 50000 opened and not 443 for UDP then we can see only those 50000 candidate lists.

TCP-ACT indicates that with this candidate pair the client is able to send RTP and RTCP traffic

https://exchangequery.files.wordpress.com/2016/12/dmzsc.png?w=600

By having a look at it, we can confirm that the candidate is a STUN pair. TCP-ACT and typ srfx raddr is the thing that indicates they are STUN pair.

In this case, if the candidate discovery fails in all the cases we can find BYE sip in the snooper logs and which mentions opaque=epid followed by GUID.

Solutions

There are two solutions for this problem to work:

Allow Port 50000 inbound

We can allow the media communications on this edge Audio/Video Ip only on port 50 K. But at real times when users connecting from a different network for the media path they need to cross firewalls where they might have only the standard 80 & 443 allowed and these ports might be blocked.

Allow the hair pin edge traffic:

Allow the traffic on the edge server external firewall to traverse the traffic between the two AV Edge servers public IP addresses. This will give the appropriate candidate lists for the clients connecting via different edge servers on UDP port 3478 through this hair pin traffic.

Note:

  1. If we have only one edge server installed we do not need to follow this steps since all the clients will connect only to one edge server node and no issues will be identified. Just make sure the UDP 3478 is opened for this communication.
  2. SFB  clients will always try to establish media path via UDP as preferred if it's available. If UDP isn’t available it tries to switch to TCP and establishes the connectivity.