Repository navigation
Support TCP STUN for stun-nat-behavior #35
Description
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?
Activity
Sean-Der commentedon Jun 13, 2020
Hi @anildigital
Currently
stun-nat-behavioronly does UDP.I haven't done an TCP STUN myself, but if you are interested it would be a great contribution!
[-]UDP port needs to be opened for receiving xormapped address[/-][+]Support TCP STUN for stun-nat-behavior[/+]Tycho-X commentedon Apr 13, 2022
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 commentedon Nov 15, 2022
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.URLstruct in pion/ice:https://github.com/pion/ice/blob/master/url.go
I propose to move
ice.URLtostun.URLand add a type alias to theicemodule for API compatibility.Furthermore,
stun.URLcurrently 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
stunandturnmodules.@Sean-Der What is your take on this?
stv0g commentedon May 10, 2023
We have now merged #134 :) So work on this issue can proceed.
My first naive to use a
stun.Clientforstun-nat-behaviourfailed as we basically need to establish two connections to the STUN server to identifier NAT behaviour, while thestun.Clientrepresents just a single connection.We can fix this by creating a second
stun.ClienttoOTHER-ADDRESS.