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.
Below were the test scenarios:
1st test – 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)
2nd test – 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)
Below troubleshooting were done :
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
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 50k was blocked in my case since no legacy OCS clients.
5)No edge hair pin traffic is allowed for Audio and Video Public Ips.
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.
Now this is the time for me to dig into the analysis of in which protocol fashion the SFB clients establishes the connection.So started to explore on STUN,TURN & ICE since ever i was having a glossy look on these topics.
So what kind of protocols they use:
SFB/Lync uses all these 3 protocols to establish a media connectivity:
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 2 to establish a path.
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 inorder to establish the connectivity.
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 uses them. These all are IETF standards protocols and hence Microsoft also uses them.
Now the SFB clients will use the below process to establish a media connectivity with the remote client:
Where the clients discover their available public IP addresses for media connectivity. These include both STUN and TURN addresses of the Edge server.
This is the place where both the SFB clients sends each other list of addresses on which they can be communicated for this media path.
Remember this will happen bidirectional.
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 route and establish a connection with the client whoever is responding first.
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.
These candidate information can be seen in snooper logs
We can see 3 types of candidate information
The first one below is for port 50k and can be ignored if you are not having this option
The second one is for audio and last one will be for video. We will have the same like one for audio with label main mentioned as audio.
Lets say if we have only port 50k opened and not 443 for UDP then we can see only those 50k candidate lists.
TCP-ACT indicates that with this candidate pair the client is able to send RTP and RTCP traffic
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
There are 2 solutions for this problem to work:
Allow Port 50k 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 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.
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 preffered if its available. If UDP isn’t available it tries to switch to TCP and establishes the connectivity.
Thanks & Regards
MVP- Office Servers & Services.