WebRTC STUN protocol support

[Nazmus Shakeeb]

Does WebRTC support STUN TCP( send and receive binding request and response to STUN Server using TCP protocol) protocol ? If yes then how can I configure STUN TCP Server.

This is required to make P2P TCP call when both parties are behind nat. 

 

[Oleg Moskalenko]

Our TURN/STUN server:

https://code.google.com/p/rfc5766-turn-server/

does support TCP STUN Binding requests but I am not sure that it will really help in your case. The address that you will receive in TCP Binding response is the reflexive address of your TCP client socket that you are using for connection to the STUN server. When you will be trying to establish a P2P connection, you will be using a different TCP client socket and its reflexive address will be different. So I personally see no much point in using TCP Binding request - other than learning the reflexive IP address with some degree of reliability.

[Nazmus Shakeeb]

Does Chrome send STUN binding request using TCP protocol ? 

 

[Justin Uberti]

No. We have no plans to support STUN over TCP, since P2P TCP provides little benefit and significant additional complexity. If you need to support users who can only use TCP instead of UDP, use a TURN server.

On Tue, Nov 19, 2013 at 8:55 PM, Nazmus Shakeeb <sha...@eyeball.com> wrote:

Does Chrome send STUN binding request using TCP protocol ? 

 

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

[Raunak Pilani]

Hey, Justin, I know I'm reading this fairly late, hopefully things have changed since your last post.
I'm trying to make my chromium webRTC app send STUN requests over TCP and have not managed to do it yet.

However, I also found and successfully tried https://www.rfc-editor.org/rfc/rfc6544.txt using --enable-webrtc-tcp-server-socket while running chromium. This flag allows chromium to let the streaming work over TCP when UDP communication is blocked and the systems are present on addresses known to each other.

Should it not be only an extension of this flag to send STUN requests over TCP?

[Justin Uberti]

No, we still have no plans to support STUN over TCP. Can you explain why you need this?

[Raunak Pilani]

In many corporate networks, all outbound UDP traffic is blocked. Which makes WebRTC slow as it falls back on a TURN server. It would be great if STUN could work over TCP and try a TCP NAT traversal.

[Iñaki Baz Castillo]

2014-05-22 16:30 GMT+02:00 Raunak Pilani <rau...@browserstack.com>:
> In many corporate networks, all outbound UDP traffic is blocked. Which makes
> WebRTC slow as it falls back on a TURN server. It would be great if STUN
> could work over TCP and try a TCP NAT traversal.

Sorry, but you can not make the same magic with TCP as you do with
UDP. In case of a private LAN or a firewall blocking incoming TCP (as
usual) the browser cannot receive TCP connections, so the only way
(assuming UDP is blocked as you said) is using browser initiated TCP
connections against a TURN TCP server (or a WebRTC server with public
IP that can handle media over TCP.

Please, read how the STUN protocol works and you will realize that all
the "magic" it does is not feasible at all when switching to TCP.

--
Iñaki Baz Castillo
<i...@aliax.net>

[Justin Uberti]

Using a TURN server is probably a good thing here, since the TCP leg will only go from the client to the nearby TURN server, which will translate the TCP into UDP before sending it across the internet.

--

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