Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement RFC-6062 #118

Open
kleky opened this issue Jan 20, 2020 · 8 comments
Open

Implement RFC-6062 #118

kleky opened this issue Jan 20, 2020 · 8 comments

Comments

@kleky
Copy link

kleky commented Jan 20, 2020

Summary

Implement RFC-6062, Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations

Motivation

To provide a TCP relay client for use with a service such as Coturn.

Describe alternatives you've considered

Unable to find any clients that support RFC-6062.

Additional context

Already discussed over Slack with a colleague of mine, Lewis Jessett and @Sean-Der :

https://gophers.slack.com/archives/CAK2124AG/p1579206089185600

We've been given the clearance to contribute on this, but will probably need some guidance from the pion community.

Looking at the RFC I've tried to summarize what is required as follows:

  1. Client to setup a Turn ALLOCATE request for TCP ( REQUESTED-TRANSPORT attribute == 6)
  2. Refresh of ALLOCATION identical to UDP
  3. Ability for client to send a Connect request over control connection (including an XOR-PEER-ADDRESS attribute containing the transport address of the peer to which a connection is desired). -Upon success response the CONNECTION-ID attribute is returned to client.
  4. Ability for client to initiate another TCP connection using a different local transport address, then a ConnectionBind request over the new connection that includes the CONNECTION-ID attribute. Upon success, this is the client data connection.

Does another new data connection get created when a peer tries to connect, as per RFC-6062 Section 4.4?

@Sean-Der
Copy link
Member

Fantastic news! So excited you are able to use Pion @kleky I will make sure to help with the whole process/get things landed :)

I am reading the RFC now and will come back with my thoughts!

@kleky
Copy link
Author

kleky commented Jan 20, 2020

pion/transport#27

Looks like we need to update vnet as it doesn't support TCP.

@Sean-Der
Copy link
Member

@kleky

Don't worry about adding TCP support to vnet. I don't think that blocks us getting this in at all. It is useful for testing how things behave in different network topologies, but I think it is less useful for TCP.

I read the RFC and seems pretty straight forward. We need to add some new handlers in turn.go to handle Connect + ConnectionBind

Then we need to make a ConnHandler equivalent here this is the relay.

I am going to setup coturn and do a wireshark of TCP traffic. If you already have it setup would you mind sharing a pcap I can move a lot faster that way, but if you don't have one it is totally fine :)

@kleky
Copy link
Author

kleky commented Jan 21, 2020

Thanks @Sean-Der , at client.go:45, Net appears to be tied to vnet.

Glad you think it's pretty straight forward! 😆

I created a fork here and pushed a change already. not wanting to duplicate on this so shall we decide who's on what? Unless you've got it all covered or prefer a different way of working?

Many thanks.

..will look into getting you coturn. no idea about a pcap though sorry

@Sean-Der
Copy link
Member

@kleky I added both of you to the pion organization. You can push a branch directly here!

That will make it a lot easier for us all to work together :) You will also get all the nice tooling/be able to pin easier.


I think we need to modify Client extensively, and have a TCP and UDP mode. We will can add a new entry TCPConn that takes a net.Conn

We also need to support it running it as connecting to the Relay or Control socket. The currently Client only targets connecting to the control socket.

@Sean-Der
Copy link
Member

This is a pretty big paradigm shift, but we will make it work :)

Feel free to refactor/change aggressively as well. I will work on getting test coverage up higher also, will make things a lot less brittle.

@kleky
Copy link
Author

kleky commented Jan 21, 2020

Haha yes indeed, we realized there appears more work than anticipated, but we'll get there. Although, because we're using coturn maybe someone else could take on the pion turn server side of it?

Thanks for adding us, it'll be much easier.

We started looking at (3) the sending of the Connect request, which will involve a new message type in stun/message.go

@Sean-Der
Copy link
Member

I can do all the server work!

If you can get the client + tests passing with coturn, I can then point them against the server and implement everything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants