8000 Multiple Relay Sessions Created by Coturn, but Only One Used for Traffic · Issue #1647 · coturn/coturn · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Multiple Relay Sessions Created by Coturn, but Only One Used for Traffic #1647

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.

Sign up for GitHub

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

Jump to bottom
Open
quadriq opened this issue Feb 28, 2025 · 4 comments
Open

Multiple Relay Sessions Created by Coturn, but Only One Used for Traffic #1647

quadriq opened this issue Feb 28, 2025 · 4 comments

Comments

@quadriq
Copy link
quadriq commented Feb 28, 2025

Hi,

I was trying to separate relay sessions and noticed that when the connection type is "relay," this event is triggered for one of the sessions created by Coturn (Coturn usually creates 4–6 sessions per connection):

   // Line 3767
   case STUN_METHOD_CHANNEL_BIND:
        handle_turn_channel_bind(server, ss, &tid, resp_constructed, &err_code, &reason, unknown_attrs, &ua_num,
                                 in_buffer, nbh);

However, in some cases, Coturn triggers this event 2 or even 3 times for a single client, leading to the creation of multiple relay sessions. But in the end, only one session is actually used for communication (as observed in traffic logs).

For example, if Coturn creates two relay-sessions for a single client:

001000000000000001
001000000000000002

I can clearly see that traffic flows only through one session (e.g., 001000000000000002), while the other (001000000000000001) remains unused.

Traffic distribution could look like this:

001000000000000001 – 5 KB
001000000000000002 – 50 MB

If the client terminates before the timeout occurs (i.e., in less than 10 minutes), both sessions get terminated, indicating that Coturn is aware of both of them.

However, if the client terminates after the timeout threshold (i.e., more than 10 minutes), the unused session gets terminated first with a "timeout" message after 10 minutes. reason: allocation timeout

My question:

  • What exactly is happening here?
  • Is this a bug, or is it expected behavior?
  • If expected, where and how does Coturn decide which session to use for relay traffic? (the place in code would be very helpfull)

Thanks in advance for your insights!
@quadriq
Copy link
Author
quadriq commented Mar 10, 2025

Hi @eakraly, @jonesmz Could you please take a look at this issue, I am really stuck I can't find a way to solve it. It would be niche if we could find a way to terminate unused sessions as soon as cotrun pickups the "correct" one.. I can try to implement it myself and create PR, but I need to know the place in code where to look at. So the place where coturn decides which session to use for relay communcation.

@dntam00
Copy link
dntam00 commented Mar 10, 2025 •
edited
Loading

Hello
@quadriq,
For the question:
If expected, where and how does Coturn decide which session to use for relay traffic? (the place in code would be very helpfull)
I think CoTurn server cannot decide which session will be used for relay traffic, it depends on the webRTC handshake process and 2 peers will decide it instead of CoTURN, they will try to establish connection asynchronously and it will use the best method (it could be P2P or relay through CoTURN).
This is what I'm understanding.

@quadriq
Copy link
Author
quadriq commented Mar 10, 2025 •
edited
Loading

Hi @dntam00 , yes, I understand that peers take best method, like P2P or Relay. But what I observe: Coturn creates from 4 to 8 sessions .(some for TCP and some for UDP). Later on two of them would be used for Relay Connection. Which we can observe as soon as case STUN_METHOD_CHANNEL_BIND: happening. But in fact only one of the sessions finaly used for real relay traffic. But is it not a CoTurn descission which one to use finaly? Becuase only CoTurn is aware of another peer in case of Relay, not?

@jonesmz
Copy link
Contributor
jonesmz commented Mar 10, 2025

You don't say what software you're using coturn with.

coturn is just a proxy. It creates "allocations" (Per the TURN protocol RFC's meaning of the term) when client software asks it to, and then data is relayed through those allocations when the client software sends the data.

Coturn has no interest in managing that, it just does what it's told.

Typically webrtc clients will create one OR MORE allocations, depending on any number of factors, including TCP vs. UDP, IPv4 vs. IPv6, multiple network connections (Ethernet, wifi, VPN, etc), and so on.

But then after those multiple allocations are created, and the initial connection handshake is completed between the two webrtc peers, only one allocation on the turnserver will be used, at most. in most situations with webrtc, even though an allocation is made on the turnserver, it is not used for the media exchange. And even if a turnserver allocation is used to relay traffic, only one such would be used. Almost always this would be the UDP allocation if there are more than one.

As for your observation about timeouts.

Allocations are kept alive for a config-file determined amount of time, or the amount of time the client asks for, whichever is lower. If your config file says to leave an allocation alive for 10 minutes, then the client software must send refresh packets to keep the allocation alive periodically.

If the client software only needs to use one relay, it will typically explicitly shut down the unneeded allocations with a packet saying to refresh the timeout to 0 seconds. But a lot of software is not so polite, and just stops using the no-longer-needed timeout.

as far as i can tell, what you're describing in your original comment is the normal and expected behavior.

If you have other concerns, please elaborate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jonesmz @quadriq @dntam00
0