coturn / coturn/coturn

connections to own relay addresses?

Open
#1,025 3 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.