Query on Signalling and STUN/TURN

[vishal...@mistminds.com]

If a client is behind NAT, when does STUN/TURN come into play? 

1. After Peer connection object is created?

2. After setting SDPs?

3. Before sending ice candidates?

[Antonis Tsakiridis]

Here's the sequence roughly:

- Create PeerConnection (pass to it STUN/TURN servers, collectively called ICE servers) and call PC.createOffer()

- PC generates SDP offer (without candidates) and you typically call PC.setLocalDescription() with them

- PC uses STUN/TURN protocol to retrieve reflexive + relayed candidates from ICE servers you provided; you get a callback for each candidate: onIceCandidate()

- ICE candidates are sent across so that connectivity checks can start (again using STUN protocol) and viable media path can be discovered

Notice though that STUN continues to be used after media has started flowing, to verify that the media channel remains open.

Hope this helps

Best regards,

-- 

Antonis Tsakiridis

Lead Developer, Mobile SDKs at Telestax

antonis.t...@telestax.com

www.telestax.com

[Vishal Singh]

Wow, nice simple explanation. Thank you.

When the STUN server fails to get behind NAT traversal, TURN servers are used as relay servers.

Does that mean, ICE candidates are not required?

Also once the STUN servers have provided ICE candidates , webrtc would have to ideally take over to create a peer to peer connection right?

On Wed, Jul 19, 2017 at 12:34 PM, Antonis Tsakiridis <antonis.t...@telestax.com> wrote:

Here's the sequence roughly:

- Create PeerConnection (pass to it STUN/TURN servers, collectively called ICE servers) and call PC.createOffer()

- PC generates SDP offer (without candidates) and you typically call PC.setLocalDescription() with them

- PC uses STUN/TURN protocol to retrieve reflexive + relayed candidates from ICE servers you provided; you get a callback for each candidate: onIceCandidate()

- ICE candidates are sent across so that connectivity checks can start (again using STUN protocol) and viable media path can be discovered

Notice though that STUN continues to be used after media has started flowing, to verify that the media channel remains open.

Hope this helps

Best regards,

-- 

Antonis Tsakiridis

Lead Developer, Mobile SDKs at Telestax

antonis.tsakiridis@telestax.com

www.telestax.com

On Tuesday, July 18, 2017 at 10:26:39 AM UTC+3, vishal...@mistminds.com wrote:

If a client is behind NAT, when does STUN/TURN come into play? 

1. After Peer connection object is created?

2. After setting SDPs?

3. Before sending ice candidates?

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/VOZgfdN6SfY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/5c76af35-7fcd-4e9a-8f72-09994bb1b993%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Antonis Tsakiridis]

Please see inline for further responses

Best regards

On Wednesday, July 19, 2017 at 12:12:52 PM UTC+3, Vishal Singh wrote:

Wow, nice simple explanation. Thank you.

Glad to help

 

When the STUN server fails to get behind NAT traversal, TURN servers are used as relay servers.

When NAT cannot be traversed by use of reflexive candidates (i.e. returned by the STUN server), then relayed candidates (i.e. gathered from TURN server) are tried as a last resort to establish media connectivity. 

 

Does that mean, ICE candidates are not required?

ICE candidates are always required. Remember that ICE candidates are all of: host, reflexive (STUN) and relayed (TURN) candidates

 

Also once the STUN servers have provided ICE candidates , webrtc would have to ideally take over to create a peer to peer connection right?

Yes after ICE candidates have been gathered in both sides, then connectivity checks commence between the candidates to decide which is the best route for media transfer. Once that candidate pair has been found media transfer starts.

 

On Wed, Jul 19, 2017 at 12:34 PM, Antonis Tsakiridis <antonis.t...@telestax.com> wrote:

Here's the sequence roughly:

- Create PeerConnection (pass to it STUN/TURN servers, collectively called ICE servers) and call PC.createOffer()

- PC generates SDP offer (without candidates) and you typically call PC.setLocalDescription() with them

- PC uses STUN/TURN protocol to retrieve reflexive + relayed candidates from ICE servers you provided; you get a callback for each candidate: onIceCandidate()

- ICE candidates are sent across so that connectivity checks can start (again using STUN protocol) and viable media path can be discovered

Notice though that STUN continues to be used after media has started flowing, to verify that the media channel remains open.

Hope this helps

Best regards,

-- 

Antonis Tsakiridis

Lead Developer, Mobile SDKs at Telestax

antonis.t...@telestax.com

www.telestax.com

On Tuesday, July 18, 2017 at 10:26:39 AM UTC+3, vishal...@mistminds.com wrote:

If a client is behind NAT, when does STUN/TURN come into play? 

1. After Peer connection object is created?

2. After setting SDPs?

3. Before sending ice candidates?

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/VOZgfdN6SfY/unsubscribe.

To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

[Vishal Singh]

You have been very helpful. Thanks again

To unsubscribe from this group and all its topics, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/6a618816-7541-4194-9883-6829ca1decf7%40googlegroups.com.