--
---
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.
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.
>>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.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAK35n0bArGm1R8v8%2Br%3DUjjAo4nG5WFcK3dRZ0dLB_Hq2pNypXQ%40mail.gmail.com.
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.
--
---
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.
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.
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?
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.