0

I'm creating a WebRTC connection between two laptops on the same network. I would expect the TURN server to NOT be chosen as the connection, but it currently is. I've taken a look at the ICE candidates and they seem to have my turn server as the bottom in terms of priority. Here's a JSON representation of my state:

 "connection": {
    "version": 4,
    "ip": "64.227.54.86\\r\\n"
  },
  "candidates": [
    {
      "foundation": 175723363,
      "component": 1,
      "transport": "udp",
      "priority": 2122260223,
      "ip": "192.168.86.64",
      "port": 64242,
      "type": "host",
      "generation": 0,
      "network-id": 1,
      "network-cost": 50,
      "_priority": "126 | 32542 | 255"
    },
    {
      "foundation": 2335266263,
      "component": 1,
      "transport": "udp",
      "priority": 1686052607,
      "ip": "24.6.16.241",
      "port": 64242,
      "type": "srflx",
      "raddr": "192.168.86.64",
      "rport": 64242,
      "generation": 0,
      "network-id": 1,
      "network-cost": 50,
      "_priority": "100 | 32542 | 255"
    },
    {
      "foundation": 1157279635,
      "component": 1,
      "transport": "tcp",
      "priority": 1518280447,
      "ip": "192.168.86.64",
      "port": 64852,
      "type": "host",
      "tcptype": "passive",
      "generation": 0,
      "network-id": 1,
      "network-cost": 50,
      "_priority": "90 | 32542 | 255"
    },
    {
      "foundation": 1039353576,
      "component": 1,
      "transport": "udp",
      "priority": 41885695,
      "ip": "64.227.54.86",
      "port": 38537,
      "type": "relay",
      "raddr": "24.6.16.241",
      "rport": 64242,
      "generation": 0,
      "network-id": 1,
      "network-cost": 50,
      "_priority": "2 | 32543 | 255"
    },
    {
      "foundation": 1936767512,
      "component": 1,
      "transport": "udp",
      "priority": 25108223,
      "ip": "64.227.54.86",
      "port": 57994,
      "type": "relay",
      "raddr": "24.6.16.241",
      "rport": 64851,
      "generation": 0,
      "network-id": 1,
      "network-cost": 50,
      "_priority": "1 | 32542 | 255"
    }
  ],

My question is, is there a way to debug why exactly a particular ICE candidate is chosen over others? I would love to understand why a particular one is chosen.

To provide a bit more context, ICE is selecting a TURN server as the connection when there is a perfectly valid non-TURN connectivity pathway that is possible. This is confirmed by taking off the TURN server from the ICE server list and having everything work.

Jorge Silva
  • 4,574
  • 1
  • 23
  • 42
  • How are you determining which candidate is chosen? – jib Aug 25 '20 at 00:11
  • I have no idea honestly. – Jorge Silva Aug 25 '20 at 03:09
  • To give a bit more context, I'm using the native webrtc library and just adding ice candidate to the peer connection when received, and sending them to the peer when created. I've looked into the SDP for them and get what information is being exchanged, but presume the logic for how this is selected is in the webrtc lib. – Jorge Silva Aug 25 '20 at 03:18

2 Answers2

1

This Stack Overflow post will help you.

In short:

Every ICE contains 'a node' of your network, until it has reached the outside. By this you send these ICE's to the other peer, so they know through what connection points they can reach you. See it as a large building: one is in the building, and needs to tell the other (who is not familiar) how to walk through it. Same here, if I have a lot of network devices, the incoming connection somehow needs to find the right way to my computer. By providing all nodes, the RTC connection finds the shortest route itself. So when you would connect to the computer next to you, which is connected to the same router/switch/whatever, it uses all ICE's and determine the shortest, and that is directly through that point. That your colleague got less ICE candidates has to do with the number of devices it has to go through. Please note that every network adapter inside your computer which has an IP address (I have a vEthernet switch from hyper-v) it also creates an ICE for it

MegaMix_Craft
  • 2,199
  • 3
  • 10
  • 36
Biju Kalanjoor
  • 532
  • 1
  • 6
  • 12
  • Thanks! This is a good explanation, but it kinda doesn't help me answer the question of how I actually debug this with code. It's all under the hood and there's no visibility into it. – Jorge Silva Aug 25 '20 at 17:19
  • 1
    If you are running in chrome you can see the log using Chrome://webrtc-internals – Biju Kalanjoor Aug 25 '20 at 17:47
  • No, using the webrtc native library. Might just start a connection with chrome client and see. – Jorge Silva Aug 25 '20 at 17:52
  • Pretty interesting: When I connect to a client in chrome the webrtc-internals show that my candidate pair within the network is the using sending and receiving all the data, but my connection string is still my TURN server. I guess everything is working as expected, but not sure why the connection string says that. – Jorge Silva Aug 25 '20 at 17:58
0

A callback method named onSelectedCandidatePairChanged of PeerConnection Observer.

Niessan
  • 1
  • 1