![]() ![]() There are 2 solutions for this problem to work: 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 TCP-ACT and typ srfx raddr is the thing that indicates they are STUN pair. TCP-ACT indicates that with this candidate pair the client is able to send RTP and RTCP trafficīy having a look at it we can confirm that the candidate is a STUN pair. Lets say if we have only port 50k opened and not 443 for UDP then we can see only those 50k candidate lists. We will have the same like one for audio with label main mentioned as audio. The second one is for audio and last one will be for video. The first one below is for port 50k and can be ignored if you are not having this option We can see 3 types of candidate information These candidate information can be seen in snooper logs 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 is the Final stage of the SFB client and happens after the call is established and its running. This is where both the candidates(clients) try to establish a connection on all these addresses simultaneously (not one by one).įinally 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 place where both the SFB clients sends each other list of addresses on which they can be communicated for this media path. These include both STUN and TURN addresses of the Edge server. Where the clients discover their available public IP addresses for media connectivity. Now the SFB clients will use the below process to establish a media connectivity with the remote client: These all are IETF standards protocols and hence Microsoft also uses them. Since these are the most commonly used RFC standard protocols SFB clients also uses them. 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. Once this chain is established it promises the remote client to send its media connection to the internal network client. 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. This will allow the SFB client to discover the available public IP for the SFB media path inorder to establish the connectivity. The new name for this acronym is Session Traversal Utilities for NAT. 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 stands for Interactive Connectivity Establishment protocol for communications. SFB/Lync uses all these 3 protocols to establish a media connectivity: 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. Getting error as call failed due to media connectivity failure when both the end points are remote. ![]() Please try again later)ġ)Did a telnet to 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.,)Ģ)Did a telnet to on port 443 – successfulģ)Did a telnet to on port 443 – successfulĤ)Did a telnet to av. on 443 successfulġ)The edges were in DNSLB and were in scaled consolidated topology using NAT.Ĥ)Port 50k was blocked in my case since no legacy OCS clients.ĥ)No edge hair pin traffic is allowed for Audio and Video Public Ips.ĭid a Snooper trace from the affected remote client and got the following info on the snooper logs Please try again later)Ģnd 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. This a new deployment and users were unable to present desktop.ġst 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. All Skype for Business Clients from remote locations were unable to present the screen sharing through meet now ,peer to peer and conference. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |