Determine Programmatically if WebRTC Will Work Without TURN

[Bradley Rubin]

Is there a way to determine programmatically if my device can work with WebRTC with only STUN and local connections (not TURN)? This could be some type of call to see if my network has a firewall that will block WebRTC. Or it could be a delegate callback that I'm missing in my iOS app.

I'm developing an iOS Application using WebRTC (libjingle) for file transfer. We don't want to use a TURN server. So, if WebRTC won't work using regular STUN or local connections, we'll fall back to another transfer method. 

We hit this issue mostly when the connection has a firewall, like at a Starbucks shared network. Right now, we try to make the WebRTC connection, and if it doesn't work in 10 seconds, we fallback to our other method. I'd like to determine whether WebRTC will work at all in this situation before the transfer, so we don't waste 10 seconds for each file transfer.

Thanks,

Brad

[Alexandre GOUAILLARD]

did you check if netscan would help detecting the problematic configurations?

https://www.netscan.co

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, 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/1c99dd79-d452-45ca-9757-25921be0b7ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

President - CoSMo Software Consulting, Singapore

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[Philipp Hancke]

2017-01-18 15:25 GMT+01:00 Bradley Rubin <bradley...@gmail.com>:

Is there a way to determine programmatically if my device can work with WebRTC with only STUN and local connections (not TURN)? This could be some type of call to see if my network has a firewall that will block WebRTC. Or it could be a delegate callback that I'm missing in my iOS app.

I'm developing an iOS Application using WebRTC (libjingle) for file transfer. We don't want to use a TURN server. So, if WebRTC won't work using regular STUN or local connections, we'll fall back to another transfer method. 

What does rolling your own fallback mechanism instead of the built-in one gain you?

 

We hit this issue mostly when the connection has a firewall, like at a Starbucks shared network. Right now, we try to make the WebRTC connection, and if it doesn't work in 10 seconds, we fallback to our other method. I'd like to determine whether WebRTC will work at all in this situation before the transfer, so we don't waste 10 seconds for each file transfer.

Listen for the iceconnectionstatechange to 'failed' event on the peerconnection.

You can also try creating a separate peerconnection in advance and see if you can gather STUN candidates but failing to gather one is not a clear indication that things can not work since connectivity depends on both end.

[shakeeb nazmus]

>>Is there a way to determine programmatically if my device can work with WebRTC with only STUN and local connections (not TURN)?

Yes. You can do it. TURN is required only when both devices you like to communicate by WebRTC are behind NAT and These NATs have specific mapping and filtering property.

And one can detect these mapping and filtering property using STUN server. ( https://tools.ietf.org/html/rfc5780 )     

Sometimes these mapping and filtering property of NAT are changed when NAT becomes loaded. So although you can detect it, it will not be accurate all the times and this may perform worse than the built in option of WebRTC. 
 

[Taylor Brandstetter]

Just a quick mention: There's a "stunprober" utility in the webrtc codebase, which can be used to tell if you're behind a NAT, and whether or not it's symmetric.

But that doesn't tell you everything. You may be behind a symmetric NAT but still be able to connect to a peer behind a less restrictive NAT; "Symmetric NAT <-> Port Restricted NAT" doesn't work, but "Symmetric NAT <-> Address Restricted NAT" does. Or you could be behind nice NATs, but have incoming traffic blocked by a firewall or something else. The only 100% reliable way to know if ICE will work is to try it.

It looks like netscan provides more information, but I'm curious about the exact criteria for "can accept incoming UDP connections" mentioned here: https://www.netscan.co/docs/result-explained/#webrtc-connectivity-tests

On Thu, Jan 19, 2017 at 12:52 AM, shakeeb nazmus <nsha...@gmail.com> wrote:

>>Is there a way to determine programmatically if my device can work with WebRTC with only STUN and local connections (not TURN)?

Yes. You can do it. TURN is required only when both devices you like to communicate by WebRTC are behind NAT and These NATs have specific mapping and filtering property.

And one can detect these mapping and filtering property using STUN server. ( https://tools.ietf.org/html/rfc5780 )     

Sometimes these mapping and filtering property of NAT are changed when NAT becomes loaded. So although you can detect it, it will not be accurate all the times and this may perform worse than the built in option of WebRTC. 
 

On Wednesday, January 18, 2017 at 10:47:07 PM UTC+8, Bradley Rubin wrote:

Is there a way to determine programmatically if my device can work with WebRTC with only STUN and local connections (not TURN)? This could be some type of call to see if my network has a firewall that will block WebRTC. Or it could be a delegate callback that I'm missing in my iOS app.

I'm developing an iOS Application using WebRTC (libjingle) for file transfer. We don't want to use a TURN server. So, if WebRTC won't work using regular STUN or local connections, we'll fall back to another transfer method. 

We hit this issue mostly when the connection has a firewall, like at a Starbucks shared network. Right now, we try to make the WebRTC connection, and if it doesn't work in 10 seconds, we fallback to our other method. I'd like to determine whether WebRTC will work at all in this situation before the transfer, so we don't waste 10 seconds for each file transfer.

Thanks,

Brad

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, 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/e7865197-7c4c-4b6c-ba77-3243449b873a%40googlegroups.com.

[Kaiduan Xie]

One way is to use the fall back method first, and at the same time establish P2P data channel. You need to keep the same API/flow control for the two methods. If P2P data channel can be established without TURN server, then switch to P2P data channel, otherwise stay with fall back method.

/Kaiduan

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAK35n0bArGm1R8v8%2Br%3DUjjAo4nG5WFcK3dRZ0dLB_Hq2pNypXQ%40mail.gmail.com.

[Bradley Rubin]

Thanks everyone for your responses, appreciate the help.

did you check if netscan would help detecting the problematic configurations?

I'll check this out to look for hints, though looks like there's no Netscan iOS/Android/REST API that I could use programmatically in the app. Doesn't look this this is going to provide all I need.

What does rolling your own fallback mechanism instead of the built-in one gain you?

We don't want to pay for and maintain a TURN server, especially if we're transferring large files.

Listen for the iceconnectionstatechange to 'failed' event on the peerconnection.

You can also try creating a separate peerconnection in advance and see if you can gather STUN candidates but failing to gather one is not a clear indication that things can not work since connectivity depends on both end.

I don't get a "failed" iceconnectionstatechange event. True on your other statement, though I don't know how I could use that.

Just a quick mention: There's a "stunprober" utility in the webrtc codebase, which can be used to tell if you're behind a NAT, and whether or not it's symmetric.

This looks like it might work for us. We don't need to be 100% accurate in detecting if WebRTC will work, but I'd rather fallback to our backup method if it's possible WebRTC will fail compared to just trying it.

Only thing is the stun prober doesn't look like it's in the lib jingle distribution, I'll need to compile and install from the updated codebase and try this. 

Also I found this on the Netscan website (https://www.netscan.co/docs/getting-started/#understanding-webrtc-connectivity)

• Inbound UDP The client accepts inbound UDP connections. Again, this can be inferred by a STUN candidate. UDP inbound connectivity can happen event if the client is behind a NAT router, due to the stateless nature of the UDP protocol. This is the single fact that enables NAT traversal and all the home based clients to perform a WebRTC connection

It seems like based on the STUN ICE candidates, I could look at them and see if there's a pattern between when the transfer fails and works. Does anyone know the specific rules for which types of ICE candidates mean that the user is behind a firewall? Or which types of ICE candidates mean that the user can't accept incoming UDP?

Thanks,

Brad

On Thursday, January 19, 2017 at 10:49:47 AM UTC-5, kaiduan wrote:

One way is to use the fall back method first, and at the same time establish P2P data channel. You need to keep the same API/flow control for the two methods. If P2P data channel can be established without TURN server, then switch to P2P data channel, otherwise stay with fall back method.

/Kaiduan

On Thu, Jan 19, 2017 at 4:00 AM, 'Taylor Brandstetter' via discuss-webrtc <discuss...@googlegroups.com> wrote:

Just a quick mention: There's a "stunprober" utility in the webrtc codebase, which can be used to tell if you're behind a NAT, and whether or not it's symmetric.

But that doesn't tell you everything. You may be behind a symmetric NAT but still be able to connect to a peer behind a less restrictive NAT; "Symmetric NAT <-> Port Restricted NAT" doesn't work, but "Symmetric NAT <-> Address Restricted NAT" does. Or you could be behind nice NATs, but have incoming traffic blocked by a firewall or something else. The only 100% reliable way to know if ICE will work is to try it.

It looks like netscan provides more information, but I'm curious about the exact criteria for "can accept incoming UDP connections" mentioned here: https://www.netscan.co/docs/result-explained/#webrtc-connectivity-tests

On Thu, Jan 19, 2017 at 12:52 AM, shakeeb nazmus <nsha...@gmail.com> wrote:

>>Is there a way to determine programmatically if my device can work with WebRTC with only STUN and local connections (not TURN)?

Yes. You can do it. TURN is required only when both devices you like to communicate by WebRTC are behind NAT and These NATs have specific mapping and filtering property.

And one can detect these mapping and filtering property using STUN server. ( https://tools.ietf.org/html/rfc5780 )     

Sometimes these mapping and filtering property of NAT are changed when NAT becomes loaded. So although you can detect it, it will not be accurate all the times and this may perform worse than the built in option of WebRTC. 
 

On Wednesday, January 18, 2017 at 10:47:07 PM UTC+8, Bradley Rubin wrote:

Is there a way to determine programmatically if my device can work with WebRTC with only STUN and local connections (not TURN)? This could be some type of call to see if my network has a firewall that will block WebRTC. Or it could be a delegate callback that I'm missing in my iOS app.

I'm developing an iOS Application using WebRTC (libjingle) for file transfer. We don't want to use a TURN server. So, if WebRTC won't work using regular STUN or local connections, we'll fall back to another transfer method. 

We hit this issue mostly when the connection has a firewall, like at a Starbucks shared network. Right now, we try to make the WebRTC connection, and if it doesn't work in 10 seconds, we fallback to our other method. I'd like to determine whether WebRTC will work at all in this situation before the transfer, so we don't waste 10 seconds for each file transfer.

Thanks,

Brad

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/e7865197-7c4c-4b6c-ba77-3243449b873a%40googlegroups.com.

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

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Taylor Brandstetter]

Just a quick mention: There's a "stunprober" utility in the webrtc codebase, which can be used to tell if you're behind a NAT, and whether or not it's symmetric.

This looks like it might work for us. We don't need to be 100% accurate in detecting if WebRTC will work, but I'd rather fallback to our backup method if it's possible WebRTC will fail compared to just trying it.

If you do try using this, use the "--shared_socket" mode. This will try pinging different STUN servers from the same source port, which is needed to detect if a NAT is symmetric.

It seems like based on the STUN ICE candidates, I could look at them and see if there's a pattern between when the transfer fails and works. Does anyone know the specific rules for which types of ICE candidates mean that the user is behind a firewall? Or which types of ICE candidates mean that the user can't accept incoming UDP?

If you get a "srflx" UDP candidate, that indicates that a STUN binding request/response was successful, so you're not behind a UDP-blocking firewall. 

To unsubscribe from this group and stop receiving emails from it, 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/232426ad-8e99-4fb3-b6ef-99786557db7e%40googlegroups.com.