0

To easily describe the problem, allow me to quote Figure 1 from RFC8656 (link: https://www.rfc-editor.org/rfc/rfc8656.txt ).

Assume that the current Client is unable to receive data directly from Peer A and Peer B, with turn's relay enabled.

I can understand that if Peer A or Peer B need to send data to Client, send the data directly to turn server's relay address (192.0.2.15:50000). Turn server will send (relay) the corresponding data to Client through the direct connection between Client and turn server.

What I want to know now is, if Client wants to send data to Peer A, will it be relayed via Turn Server or possibly sent directly via Prflx or Srflx (192.0.2.150:32102)? I will call this data as uplink traffic.

Based on efficiency and performance considerations, uplink traffic that can be sent directly to Peer A via prflx or srflx is definitely the better way (I call this way Direct). But since Peer A may not be reached directly due to NAT, then there are two ways to solve it:

one is using the exsisted Client assigned Relay, which is that 192.0.2.15:50000, I call this way OldRelay;

Another way is Peer A also use its own Turn Relay, that becomes another structure, I'll ignore this scenario.

To summarize, my questions are:

  1. Are both the Direct way and the OldRelay way allowed?

  2. If both Direct and OldRelay are allowed, what is the difference between the client's Candidate pair in these two cases? Or how to distinguish between these two cases from Candidate Pair?

=====================Updated===========================

In fact, there is a problem with my old question. Because if one direction can be served directly, then actually the other direction can be served directly as well. So there is no case of relay in one direction and direct delivery in the other.

I am not going to modify my original question, because there is already a user discussion for this issue and pointed out my mistake.

But I would like to say that my error comes from a strange state screencap: https://postimg.cc/F1wRM7Y5 lcoal_relay&remote_prflx

I'm discussing this with @PhilippHancke, because as understood, if one can get the Prflx on the other end, then one should use p2p instead of relay.

Is this theoretically the case in the diagram (I've checked that there is no policy forcing the use of relay).

I'm also trying to figure out whether to use relay or p2p in this scenario.

Thank you very much~

                                       Peer A
                                       Server-Reflexive    +---------+
                                       Transport Address   |         |
                                       192.0.2.150:32102   |         |
                                           |              /|         |
                         TURN              |            / ^|  Peer A |
      Client's           Server            |           /  ||         |
      Host Transport     Transport         |         //   ||         |
      Address            Address           |       //     |+---------+
   198.51.100.2:49721  192.0.2.15:3478     |+-+  //     Peer A
              |            |               ||N| /       Host Transport
              |   +-+      |               ||A|/        Address
              |   | |      |               v|T|     203.0.113.2:49582
              |   | |      |               /+-+
   +---------+|   | |      |+---------+   /              +---------+
   |         ||   |N|      ||         | //               |         |
   | TURN    |v   | |      v| TURN    |/                 |         |
   | Client  |----|A|-------| Server  |------------------|  Peer B |
   |         |    | |^      |         |^                ^|         |
   |         |    |T||      |         ||                ||         |
   +---------+    | ||      +---------+|                |+---------+
                  | ||                 |                |
                  | ||                 |                |
                  +-+|                 |                |
                     |                 |                |
                     |                 |                |
            Client's                   |             Peer B
            Server-Reflexive     Relayed             Transport
            Transport Address    Transport Address   Address
            192.0.2.1:7000       192.0.2.15:50000    192.0.2.210:49191

                                  Figure 1
progquester
  • 1,228
  • 14
  • 23
  • 1
    if the prflx candidate works as intended, why would the priority algorithm pick the relayed candidate pair? – Philipp Hancke May 24 '23 at 04:29
  • @PhilippHancke thank you. I don't know if there are two directions using different mechanisms. For example, downstream and downstream data cannot be sent to me by the other side, thus relaying via turn. but I can still send upstream data directly to the other side? – progquester May 24 '23 at 05:31
  • @PhilippHancke Would you please check this choosed ice candiate pair? The local is relay, and remote is prflx. I don't know if this situation is relay or p2p? Screencap is https://postimg.cc/F1wRM7Y5 – progquester May 24 '23 at 06:29
  • 1
    This describes the candidate *pair*. The local candidate is using the relay port but the remote candidate has been discovered via STUN (which can happen sometimes, it depends on whether the other side signalled the candidate or not). Data is sent via the TURN server. – Philipp Hancke May 24 '23 at 08:02

0 Answers0