Support TCP STUN for stun-nat-behavior

[anildigital]

I had the only opened TCP for Inbound rules for port 443

stun-nat-behaviour --server turn.myserver.dev:443
2020/06/07 22:45:39 Connecting to STUN server: turn.myserver.dev:443
2020/06/07 22:45:39 Local address: 0.0.0.0:50272
^C⏎

But when I enable UDP for Inbound rules for port 443.. then I see

stun-nat-behaviour --server turn.myserver.dev:443
2020/06/07 22:46:41 Connecting to STUN server: turn.myserver.dev:443
2020/06/07 22:46:41 Local address: 0.0.0.0:56357
2020/06/07 22:46:41 Received xormapped address: 103.51.74.193:56357
^C⏎

Same happed with port 5349. Do we really need to have UDP protocol open in ordered to get xormapped address?

[Sean-Der]

Hi @anildigital

Currently stun-nat-behavior only does UDP.

I haven't done an TCP STUN myself, but if you are interested it would be a great contribution!

[Tycho-X]

Its great that tcp is now supported! According to Readme.md

RFC 7064 — STUN URI (TLS-over-)TCP client support

are supported too but i dont see any supprt for TLS/SSL or the "STUNS" URI in the source code.

Is it possible to establish a STUN over TLS / STUNS connection with "stun.Dial"?

[stv0g]

I see that all the examples currently resolve the server address manually and dial to it via UDP (IPv4).

We should add a new function stun.DialURL(u *URL) which handles all the magic and use it for the examples later on.

The only thing about which I am concerned is the duplication of code we already have an ice.URL struct in pion/ice: https://github.com/pion/ice/blob/master/url.go

I propose to move ice.URL to stun.URL and add a type alias to the ice module for API compatibility.

Furthermore, stun.URL currently implements only RFC 7064 (STUN URI) not RFC 7065 (TURN URL).

I am not so sure if we really want to split up the implementation of the URL struct into the stun and turn modules.

@Sean-Der What is your take on this?

[stv0g]

We have now merged #134 :) So work on this issue can proceed.

My first naive to use a stun.Client for stun-nat-behaviour failed as we basically need to establish two connections to the STUN server to identifier NAT behaviour, while the stun.Client represents just a single connection.

We can fix this by creating a second stun.Client to OTHER-ADDRESS.