WebRTC over TCP in Chrome

[Josh Nedelka]

I've read several other threads that touch on this issue (like https://groups.google.com/forum/#!msg/discuss-webrtc/bq2tUi_guE4/ijJfGFgS-5QJ) but I'm still coming away with questions.  I've seen in wireshark that it's possible to initiate the connection to the TURN server using TCP but even when only specifying a single iceServer with ?transport=tcp appended I still see a UDP relay being used.  The thread above seems to indicate that it's possible to use a TCP relay to send media traffic to the TURN server but for the life of me I cannot get the configurations right.  I'm using the latest EC2 AMI and a very restrictive network (only outbound 80/443 TCP allowed, no UDP at all), a fairly common enterprise setup, and I want to know if WebRTC in Chrome with a TURN server will be sufficient or if more needs to be done.  With these restrictions, will we be stuck because Chrome has so far not decided to support RFC 6062?

Thanks,

Josh

[Josh Nedelka]

I should note that the EC2 instance has all ports open and is available on the public internet.  The network of one of the clients I'm using is the restrictive one.

[Oleg Moskalenko]

Hi Josh

if you configured the TURN server on ports 80 and 443 in EC2 instance, and if you opened all UDP ports in the instance and if you set the authentication correctly, then you must be fine.

Why Chrome is still using UDP I have no idea. The TCP support in Chrome is freshly young and I am not sure about its status. I am not an WebRTC expert, we are answering mostly TURN-server-side questions here. But may be somebody would want to chime in.

Chrome actually decided on RFC 6062 - they decided NOT to support it.

Regards,

Oleg

--
You received this message because you are subscribed to the Google Groups "TURN Server project rfc5766-turn-server" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.
Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/groups/opt_out.

[Warren McDonald]

Hi Josh,

you can certainly get Chrome to create the connection to the TURN server using TCP, however the relay will always be UDP. 

That does not mean that 2 clients cannot connect to TURN servers and have their media relayed between the TURN servers as UDP. In fact, if they are both using the same TURN server, the relay can happen over local socket, which is very efficient. 

So from a logical perspective it looks like a trapezoid topology. Both clients connect to TURN process using TCP and both TURN processes connect to each other via UDP. For distantly geographically distributed sites this can work well if there is a TURN server close to each user, as the relay will be the longest link will benefit from the lower UDP latency.

Warren 

[Josh Nedelka]

Thanks.  So it sounds like clients who don't allow outbound or inbound UDP would be out of luck then, assuming they are using Chrome?  Ultimately this is my question, can someone use the current WebRTC implementations to communicate with a TURN server in this case?  I'll try posting over on the WebRTC forums with a similar question.  Thanks for all your great work on this TURN server too.  Setup was completely painless and simple, and testing without any other network restrictions it works perfectly.  

On Thursday, February 13, 2014 4:45:45 PM UTC-5, Oleg Moskalenko wrote:

Hi Josh

if you configured the TURN server on ports 80 and 443 in EC2 instance, and if you opened all UDP ports in the instance and if you set the authentication correctly, then you must be fine.

Why Chrome is still using UDP I have no idea. The TCP support in Chrome is freshly young and I am not sure about its status. I am not an WebRTC expert, we are answering mostly TURN-server-side questions here. But may be somebody would want to chime in.

Chrome actually decided on RFC 6062 - they decided NOT to support it.

Regards,

Oleg

On Feb 13, 2014, at 1:39 PM, Josh Nedelka <jfn1...@gmail.com> wrote:

I should note that the EC2 instance has all ports open and is available on the public internet.  The network of one of the clients I'm using is the restrictive one.

On Thursday, February 13, 2014 4:37:18 PM UTC-5, Josh Nedelka wrote:

I've read several other threads that touch on this issue (like https://groups.google.com/forum/#!msg/discuss-webrtc/bq2tUi_guE4/ijJfGFgS-5QJ) but I'm still coming away with questions.  I've seen in wireshark that it's possible to initiate the connection to the TURN server using TCP but even when only specifying a single iceServer with ?transport=tcp appended I still see a UDP relay being used.  The thread above seems to indicate that it's possible to use a TCP relay to send media traffic to the TURN server but for the life of me I cannot get the configurations right.  I'm using the latest EC2 AMI and a very restrictive network (only outbound 80/443 TCP allowed, no UDP at all), a fairly common enterprise setup, and I want to know if WebRTC in Chrome with a TURN server will be sufficient or if more needs to be done.  With these restrictions, will we be stuck because Chrome has so far not decided to support RFC 6062?

Thanks,

Josh

--
You received this message because you are subscribed to the Google Groups "TURN Server project rfc5766-turn-server" group.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

[Oleg Moskalenko]

Hi Warren,

you provided a great description. One thing that I’d like to point out is that there is only one TURN process per system - so if two clients are connected to the same TURN server, the relay happens within the same single process, and although the local sockets are still used, the relaying process is very efficient.

Regards,

Oleg

 

--
You received this message because you are subscribed to the Google Groups "TURN Server project rfc5766-turn-server" group.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.

[Josh Nedelka]

Hi Warren - 

If the firewall blocks all outbound UDP ports, how would this work?  Even when setting ?transport=tcp in the latest Chrome it still attempts to stream media to the TURN server using UDP, which fails due to the firewall rules that are in place.  

[Warren McDonald]

Hi Oleg,

I have found that recent Chrome behaviour when connecting to TURN is very variable and not according to comments made previously regarding priority of connections. Google had said that if multiple connection type are specified they will try in order of UDP, TCP, TLS. We have found this not to be the case and it appears that TCP and UDP are tried in close succession without either failing. So they may just be determining if the supplied iceServer connection types are actually reachable, before they decide which one to use. They may well be trying UDP for any specified server. Obviously, this also depends on whether TURN is actually required in ICE processing.

Warren  

On Friday, 14 February 2014 08:45:45 UTC+11, Oleg Moskalenko wrote:

Hi Josh

if you configured the TURN server on ports 80 and 443 in EC2 instance, and if you opened all UDP ports in the instance and if you set the authentication correctly, then you must be fine.

Why Chrome is still using UDP I have no idea. The TCP support in Chrome is freshly young and I am not sure about its status. I am not an WebRTC expert, we are answering mostly TURN-server-side questions here. But may be somebody would want to chime in.

Chrome actually decided on RFC 6062 - they decided NOT to support it.

Regards,

Oleg

On Feb 13, 2014, at 1:39 PM, Josh Nedelka <jfn1...@gmail.com> wrote:

I should note that the EC2 instance has all ports open and is available on the public internet.  The network of one of the clients I'm using is the restrictive one.

On Thursday, February 13, 2014 4:37:18 PM UTC-5, Josh Nedelka wrote:

I've read several other threads that touch on this issue (like https://groups.google.com/forum/#!msg/discuss-webrtc/bq2tUi_guE4/ijJfGFgS-5QJ) but I'm still coming away with questions.  I've seen in wireshark that it's possible to initiate the connection to the TURN server using TCP but even when only specifying a single iceServer with ?transport=tcp appended I still see a UDP relay being used.  The thread above seems to indicate that it's possible to use a TCP relay to send media traffic to the TURN server but for the life of me I cannot get the configurations right.  I'm using the latest EC2 AMI and a very restrictive network (only outbound 80/443 TCP allowed, no UDP at all), a fairly common enterprise setup, and I want to know if WebRTC in Chrome with a TURN server will be sufficient or if more needs to be done.  With these restrictions, will we be stuck because Chrome has so far not decided to support RFC 6062?

Thanks,

Josh

--
You received this message because you are subscribed to the Google Groups "TURN Server project rfc5766-turn-server" group.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

[Oleg Moskalenko]

Josh, Warrant answered your question. Two clients must connect to the TUR server over TCP.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.

[Warren McDonald]

Hi Josh,

Just to  clarify. Use from networks with only TCP egress/ingress will work with TURN. The only caveat is that the TURN server must be able to accept the TCP connections and the iceServers specify transport=tcp. The UDP relay will only be between TURN server sockets, it does NOT require a UDP leg back to the clients.

I have proven this in lab tests and practically in real world situations.

Warren  

[Josh Nedelka]

The last few posts of this issue seem to confirm my fears - https://code.google.com/p/webrtc/issues/detail?id=1913 but I hope it is simply other people misunderstanding things as I'm sure I am.  

On Thursday, February 13, 2014 4:37:18 PM UTC-5, Josh Nedelka wrote:

[Josh Nedelka]

I see.  I'll continue to debug the issue to see where it is failing then.  Thanks for your wisdom.

[Chris Koehncke]

Josh likely look for simple yes or no to what is a typical enterprise situation.

Hard core enterprise customers (financial firms and telco types) typically lock down their employees for the external Internet access. Usually allowing on web traffic via TCP port 80/443 and 'maybe' UDP port 53 for DNS queries.

The short answer is Chrome/WebRTC isn't capable of tunneling the media traffic via TCP. Recognize as well your signaling methodology must work via these ports or fail as well (this is outside scope for WebRTC).

If Skype is the benchmark, Skype too fails in this situation (at least in my own testing).

On Thursday, February 13, 2014 4:37:18 PM UTC-5, Josh Nedelka wrote:

[Josh Nedelka]

I was actually able to get this to connect outside of our network
(which has similar restrictions to what you describe). The TURN
server needed to be configured to listen on port 443 as well as have
some hardcoded internal/external instance IPs to work with our VPC.

Our signalling is done with a web client implementing XMPP, so that
isn't a problem.

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "TURN Server (Open-Source project)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/turn-server-project-rfc5766-turn-server/vR_2OAV9a_w/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> turn-server-project-rfc57...@googlegroups.com.
>

> To post to this group, send email to

> turn-server-project...@googlegroups.com.

> Visit this group at
> http://groups.google.com/group/turn-server-project-rfc5766-turn-server.

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

[Oleg Moskalenko]

Josh i did not get what you are saying about the hardcoded IPs. All ips can be configured, what did you mean ?

Sent from my iPhone

> You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.

[Oleg Moskalenko]

My understanding is that chrome must be able to use tcp for the media tunneling, officially. If not then it is a bug that has to be fixed by the chrome team.

Sent from my iPhone

--

[Josh Nedelka]

Just that I had not correctly setup the turnserver.conf file. In
addition to having the listening port at 443, the following were
needed:

listening-ip=<internal IP>
relay-ip=<internal IP>
external-ip=<external IP>/<internal IP>

just setting external-ip=<external IP> was not sufficient.

[Oleg Moskalenko]

Interesting. It must be sufficient if you have only one internal IP; the mapping option <external-IP>/<internal-IP> is required only if you have more than one internal IP.

Oleg

[T.R. Missner]

I can say with complete confidence Chrome can in fact tunnel media via TCP via TURN

I have a demo page setup that demonstrates this.

If anyone wants to try it send me an email at tr at voipjedi.com

Not sure how long I'll leave this page up but at least a couple months 

--tr

On Thursday, March 13, 2014 4:30:19 PM UTC-4, Oleg Moskalenko wrote:

My understanding is that chrome must be able to use tcp for the media tunneling, officially. If not then it is a bug that has to be fixed by the chrome team.

Sent from my iPhone

On Mar 13, 2014, at 12:52 PM, Chris Koehncke <ckoe...@gmail.com> wrote:

Josh likely look for simple yes or no to what is a typical enterprise situation.

Hard core enterprise customers (financial firms and telco types) typically lock down their employees for the external Internet access. Usually allowing on web traffic via TCP port 80/443 and 'maybe' UDP port 53 for DNS queries.

The short answer is Chrome/WebRTC isn't capable of tunneling the media traffic via TCP. Recognize as well your signaling methodology must work via these ports or fail as well (this is outside scope for WebRTC).

If Skype is the benchmark, Skype too fails in this situation (at least in my own testing).

On Thursday, February 13, 2014 4:37:18 PM UTC-5, Josh Nedelka wrote:

I've read several other threads that touch on this issue (like https://groups.google.com/forum/#!msg/discuss-webrtc/bq2tUi_guE4/ijJfGFgS-5QJ) but I'm still coming away with questions.  I've seen in wireshark that it's possible to initiate the connection to the TURN server using TCP but even when only specifying a single iceServer with ?transport=tcp appended I still see a UDP relay being used.  The thread above seems to indicate that it's possible to use a TCP relay to send media traffic to the TURN server but for the life of me I cannot get the configurations right.  I'm using the latest EC2 AMI and a very restrictive network (only outbound 80/443 TCP allowed, no UDP at all), a fairly common enterprise setup, and I want to know if WebRTC in Chrome with a TURN server will be sufficient or if more needs to be done.  With these restrictions, will we be stuck because Chrome has so far not decided to support RFC 6062?

Thanks,

Josh

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

[sandhya rajasekar]

Hi warren,

since you have said that chrome can create connection to TURN via TCP, what is the protocol that is used for transfering media in TCP? is it RTP ??? or any other protocol?

On Friday, February 14, 2014 3:17:54 AM UTC+5:30, Warren McDonald wrote:

Hi Josh

[Timotheus Kampik]

Just to be sure:

So if I run a TURN sever with the option --no-udp, but without --no-upd-relay, my server should work for connections to clients in networks only allowing outgoing TCP connections?

'cause when I run the turnserver with --no-udp-relay and connect with Chrome clients, TURN is stating: "error 403: UDP Transport is not allowed by the TURN Server configuration" although I specified TCP in the ICE server object: "...?transport=tcp"

[Oleg Moskalenko]

On Fri, Mar 6, 2015 at 2:30 AM, Timotheus Kampik
<timotheu...@gmail.com> wrote:
> Just to be sure:
> So if I run a TURN sever with the option --no-udp, but without
> --no-upd-relay, my server should work for connections to clients in networks
> only allowing outgoing TCP connections?

yes

And if you define no options, then everything will work - including
the TCP-only clients.

> 'cause when I run the turnserver with --no-udp-relay and connect with Chrome
> clients, TURN is stating: "error 403: UDP Transport is not allowed by the
> TURN Server configuration" although I specified TCP in the ICE server
> object: "...?transport=tcp"

that's right - you must never use --no-udp-relay together with WebRTC,
because WebRTC uses only UDP on the relay side.

>>>> turn-server-project-rfc57...@googlegroups.com.

>>>> To post to this group, send email to

>>>> turn-server-project...@googlegroups.com.

>>>> Visit this group at
>>>> http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>>

> --
> You received this message because you are subscribed to the Google Groups

> "TURN Server (Open-Source project)" group.

> To unsubscribe from this group and stop receiving emails from it, send an
> email to

> turn-server-project-rfc57...@googlegroups.com.

> To post to this group, send email to

> turn-server-project...@googlegroups.com.

> Visit this group at
> http://groups.google.com/group/turn-server-project-rfc5766-turn-server.

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

[Timotheus Kampik]

Thanks a lot!

>>>> turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.

>>>> To post to this group, send email to

>>>> turn-server-project-rfc5766-turn-...@googlegroups.com.

>>>> Visit this group at
>>>> http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>>
> --
> You received this message because you are subscribed to the Google Groups
> "TURN Server (Open-Source project)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to

> turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.

> To post to this group, send email to

> turn-server-project-rfc5766-turn-...@googlegroups.com.

[Timotheus Kampik]

An interesting observation I made is:

Establishing WebRTC connectivity through a Squid proxy did not work when outgoing UDP was blocked on my test machine (the proxy worked fine, otherwise/for HTTP(S) traffic).

When not going through the proxy and when using the proxy but allowing outgoing UDP everything went fine.

Does anyone have an explanation for this?

On Friday, March 6, 2015 at 6:06:45 PM UTC+1, Oleg Moskalenko wrote:

>>>> turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.

>>>> To post to this group, send email to

>>>> turn-server-project-rfc5766-turn-...@googlegroups.com.

>>>> Visit this group at
>>>> http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>>
> --
> You received this message because you are subscribed to the Google Groups
> "TURN Server (Open-Source project)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to

> turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.

> To post to this group, send email to

> turn-server-project-rfc5766-turn-...@googlegroups.com.

[Warren McDonald]

Hi Timotheus,

on which machine is UDP outgoing blocked. In your test setup where is the http proxy in relation to the turn server?

There are many things which have to correct in order for the http proxy CONNECT method to work. In my experience you actually have to be quite thorough in network setup to get Chrome to try to use this. If there is any other valid egress to the TURN server it will use this.

There is one possible explanation, if UDP is blocked and your DNS resolution is UDP only, all sorts of things will start to fail. Make sure you only block UDP above 53 on clients or on proxy servers etc. If you are doing this on a whole network segment this may cause failures where you may not be looking, such as the proxy not being able to resolve the remote address.

Cheers,

Warren       

[Timotheus Kampik]

Thanks for helping me out, Warren.

In my test setup, I am running proxy and WebRTC peer on the same machine and allow only the proxy to use UDP for DNS resolution.

The TURN server is throwing  "error 401: Unauthorised" during failing tests. It seems the credentials are missing in this setting.

Is there something I am not taking into account here?

[Timotheus Kampik]

Just in case it's relevant for somebody:

Testing in the same setting with the latest Chrome Canary (43.x) enables WebRTC via TURN/TCP.

So it could be an issue with my current Chrome version (38.x).