connections to own relay addresses?
- Dominant language
- C
- Stars
- 14.4k
- Forks
- 2.3k
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 24
Description
Hello, I've been working on a TURN client and I had a question about how Coturn's TCP behaviour is supposed to work?
Let's say that I make an 'allocation' and request a TCP transport. In return I get a new relay address that can be used to send messages to my client. As far as I know: to be able to receive message from this address I then need to create a new permission for a peer. The peer connects to the address and any data they send to it gets routed to me. I think for this you need the exact IP and src port they will use.
While I was testing this out I had the idea of sending a create permission request with the TURN servers listen details. Then I sent a connect request and specified the clients own relay address for the destination. So essentially I told the TURN server to connect to itself on its relay address. This worked and it spat out a new connection ID. From that point on I created a new connection to the TURN server and issued a bind request using the connection ID from before. The server sent out a success code. I then tried to use the connection to see if anything happened.... and I was able to send data and receive it back again.
So the connection diagram probably looks something like this:
1. server -> data con 1 -> servers own relay address
2. client -> data con 2 -> server
3. client -> data con 2 -> server -> data con 1 -> servers own relay addr -> data con 2 -> client
Sorry if this is really obvious: but is this intended behaviour?
Contributor guide
Research direction
No source file or test is named. Start by reproducing the allocation, create-permission, connect, and bind sequence described in the issue, then trace the relevant TCP relay behavior. Done means establishing whether loopback to the server's own relay address is intended and documenting or correcting the behavior accordingly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100