Chrome fails to use TURN/TLS when block udp

[Huipeng Ren]

I set pc_config for RTCPeerConnection in my application as following,

pc_config = {iceServers: [{url: "turn:54.xx.x.x:5349?transport=tcp", credential: "password", username: "user"}]};

and block network udp, then start  RTCPeerConnection. In WireShark I see Chrome keeps sending some STUN Binding Requests to 54.xx.x.x:5349 over udp, because udp is blocked, Chrome can not get the STUN responses. It just keeps sending the STUN Binding Requests over udp and does not try any tcp messages, so it can not get any relay candidate. Is the a bug in Chrome? 

I tried the Chrome (31.0.1650.63)  and Chrome Canary(34.0.1787.2) and get the same result.

[Mallinath Bareddy]

What happened with TURN allocate request/response? Did they sent over tcp?

For STUN chrome uses only udp, in this case it behaved as expected. Also call should get established in your scenario, but it will be using relay.

--
 
---
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Silvia Pfeiffer]

Restart your Chrome - it should have updated to Chrome 32 by now. I
had plenty of issues with Chrome 31 and am glad it's gone!

Silvia.

[Huipeng Ren]

Sorry, I miss an important information, My Chrome is set by a HTTP proxy. And I change pc_config = {iceServers: [{url: "turn:54.xx.x.x:443?transport=tcp", credential: "password", username: "user"}]};

I did see Chrome send a HTTP CONNECT to 54.xx.x.x:443, but the same result, it can not get any relay candidate.

[Nazmus Shakeeb]

I think Chrome doesn't support HTTP proxy.

Shakeeb

[Warren McDonald]

If you are trying to connect using TLS then you must use the turns: protocol not turn: The rest looks correct. Although there many other settings that have to be right including realm. 

If set right you should get something like this in the turnserver log

1389880891: handle_turn_command: user <>: request BINDING processed, error 0

1389880891: IPv4. tcp or tls connected to: ipaddr:port

1389880891: handle_turn_command: user <>: message processed, error 401

1389880891: IPv4. Server relay addr: 10.0.0.100:0

1389880891: IPv4. Local relay addr: 10.0.0.100:55669

1389880891: new Allocation: id=0xd150d5ee, username=<username>, lifetime=600

 

Also make sure UDP is properly blocked to the remote browser otherwise you may still have a UDP path to the peer, which will never fall back to TURN. Are you testing in real world scenarios or inside the same network?    

Chrome will use a configured HTTP proxy, but the proxy server must support the connect method on the port used. So 443 should be fine here.

[Rocko Heffer]

Hi,

I have a question along these lines for understanding.

Issue 2865 says that TURN/TLS is not yet supported in WebRTC standalone. However, Chrome(>=)30 supports TURN/TLS.

Since, WebRTC uses libjingle and it still does not support TURN/TLS connection to the TURN server, does it mean that Chromium and Firefox also don't support TURN/TLS connection to the TURN server?

Thanks.

[Philipp Hancke]

On Mon, Jul 21, 2014 at 6:58 AM, Rocko Heffer <afaq...@gmail.com> wrote:

Hi,

I have a question along these lines for understanding.

Issue 2865 says that TURN/TLS is not yet supported in WebRTC standalone. However, Chrome(>=)30 supports TURN/TLS.

Since, WebRTC uses libjingle and it still does not support TURN/TLS connection to the TURN server, does it mean that Chromium and Firefox also don't support TURN/TLS connection to the TURN server?

Chrome has supported TURN/TLS for quite a while (https://code.google.com/p/webrtc/issues/detail?id=1425). I think it became fully functional in M35 but http://code.google.com/p/chromium/issues/detail?id=306285 gives me a permission-denied error.

[Justin Uberti]

It works properly in desktop Chrome. There are a number of differences between the implementation in Chrome and the standalone stack, since WebRTC uses Chrome's network stack when running there.

--

---
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.

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

[Rocko Heffer]

That explains it all. Thanks Justin.