ISP compatibility issue

[Wei]

Hi,

 

In testing WebRTC in different environments, I run into an Internet Service Provider (ISP) compatibility problem: In some cases, peers from different ISPs do not connect. I use public STUN servers including some provided by Google.  The websocket server port is open on all ISPs.  Here is a scenario: Three peers A, B, and C each using a different ISP.  They are using the same peer-to-peer system.  It may be the case that A connects with B fine, B connects with C fine, but A does not connect with C.  With everything being equal, the only difference is the ISP, I think.

 

I appreciate advice and help on this issue.

-wl,

[Christoffer Jansson]

Hi,

It's probably related to the local users network rather than the ISP, for example if they are behind a symmetrical NAT, a turn server relaying the traffic must be used.

Read this article for more details.

Hope this helps.

/Chris

--

---
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/dea6a888-582d-4443-9516-d97d98cdf4fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Wei]

Chris,

 

Thanks for the quick pointer.  How can I use a TURN server as a fallback to STUN?  Say I have the following stun server configuration:

 

      "iceServers": [

      { "urls": "stun: stun3.l.google.com:19302” }

 

How does a fallback TURN server fits in the code?  Where do I start to build a TURN server? Do I have to have my own TURN server?

 

-wl,

[Wei]

Chris,

I tried adding TURN servers to the ice configuration, but still the same problem persists.  I used public TURN servers.  First,  I used only these TURN servers without any STUN server, the result is: those that connected before (using TURN servers only) still connect now (the TURN servers work fine) and those that did not connect before still do no connect. Then I tried using one STUN server followed by the TURN servers, the result is the same: those connected before still connect now, and those did not connect before still do not connect now.  In other words, adding TURN servers does not solve the problem.

Any advice?

-wl,

On Thursday, January 21, 2016 at 8:22:33 AM UTC-6, Christoffer Jansson wrote:

[Christoffer Jansson]

Do the clients that do not connect, have access to the TURN and STUN servers?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/c93d1986-c870-4c6a-adc4-3a21c6bb16be%40googlegroups.com.

[Christoffer Jansson]

Distance should only affect establish session time and RTT but should still succeed in setting up the connection (heavy packet loss could ofc be an issue). 

Coming to think of it, ISP's can ofc block services depending on the region but then nothing would be able to connect. 

Can you confirm that the audio is setup using turn as well? Also, do you know for sure that the turn servers are capable relaying all traffic? Best would be if you could have your own turn server as a reference, using public-ally available turn servers introduces uncertainty into the equation as you have no idea of what they are doing.

There several guides for how to do this, AWS is pretty popular: http://stackoverflow.com/questions/31161864/how-to-create-stun-turn-server-instance-using-aws-ec2.

Also check out https://github.com/coturn/rfc5766-turn-server/.

/Chris

On Fri, Jan 22, 2016 at 2:30 PM Wei <weil...@gmail.com> wrote:

Chris,

Yes, they do.  The following is the ice configuration I tried first:

     "iceServers": [

      {'urls': 'turn:192.158.29.39:3478?transport=udp',

        'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',

        'username': '28224511:1379330808'

      },

      {'urls': 'turn:192.158.29.39:3478?transport=tcp',

        'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',

        'username': '28224511:1379330808'

      }

     ]

Then, I tried the following:

     "iceServers": [

      { "urls": "stun:stun3.l.google.com:19302 }, 

      { "urls": "stun:stun4.l.google.com:19302 }, 

      {'urls': 'turn:192.158.29.39:3478?transport=udp',

        'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',

        'username': '28224511:1379330808'

      },

      {'urls': 'turn:192.158.29.39:3478?transport=tcp',

        'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',

        'username': '28224511:1379330808'

      },

The result is the same as I described.  However, the latest tests showed that the audio channel is connected, the video displaced a black rectangle box.  Are the distance between peer device and TURN server critical in the result?  The peers are in Asia, the TURN servers are in California and Canada?  

Thanks.

-wl,

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/06898929-069f-4dab-9f04-e925fb594467%40googlegroups.com.