Android WebRTC on LAN: only candidate 127.0.0.1 is sent to signaling server

Question

I am trying to create an Android video chat application based on WebRTC, for deployment on a local network. The setup is simple: 2 Android terminals and one Linux server on the same local network (Ethernet). No STUN nor TURN server. Only host candidates, and a signaling server (HTTP+WS).

A few years ago, I found an Android app on GitHub, based on libjingle-9127, along with the associated Node.js server. It worked out of the box with my setup.
This library being 4 years old, I tried to move to the latest google-webrtc Android SDK + a Node.js port of the appr.tc server. The signaling works well, but the video chat itself fails.

Trying to compare the two versions, I realized that the list of candidates sent to the signaling server is:

one candidate per network interface with the libjingle version
only 127.0.0.1 and :::1 with the google-webrtc version

This seems to be due to a mechanism of WebRTC called Trickle ICE introduced in-between. And I don't know how to configure WebRTC to declare the candidates corresponding to my local network interfaces.

Is there an API of the WebRTC Android SDK enabling me to do so?

Thank you!

PS: The list of candidates sent to the signaling server.

With libjingle-9127

{"type":"candidate","payload":{"label":0,"id":"audio","candidate":"candidate:2316705582 1 udp 2122260223 192.168.237.1 34869 typ host generation 0"},"from":"-Dl0-BWMLUwmKvvcAAAD"}]

,{"type":"candidate","payload":{"label":1,"id":"video","candidate":"candidate:2316705582 1 udp 2122260223 192.168.237.1 34869 typ host generation 0"},"from":"-Dl0-BWMLUwmKvvcAAAD"}]

,{"type":"candidate","payload":{"label":1,"id":"video","candidate":"candidate:2316705582 1 udp 2122260223 192.168.237.1 34869 typ host generation 0"},"from":"-Dl0-BWMLUwmKvvcAAAD"}]

,{"type":"candidate","payload":{"label":0,"id":"audio","candidate":"candidate:3614478314 1 udp 2122194687 172.17.84.124 52163 typ host generation 0"},"from":"-Dl0-BWMLUwmKvvcAAAD"}]

,{"type":"candidate","payload":{"label":1,"id":"video","candidate":"candidate:3614478314 1 udp 2122194687 172.17.84.124 52163 typ host generation 0"},"from":"-Dl0-BWMLUwmKvvcAAAD"}]

,{"type":"candidate","payload":{"label":0,"id":"audio","candidate":"candidate:1846788752 1 udp 2122129151 172.17.116.134 45915 typ host generation 0"},"from":"-Dl0-BWMLUwmKvvcAAAD"}]

,{"type":"candidate","payload":{"label":1,"id":"video","candidate":"candidate:1846788752 1 udp 2122129151 172.17.116.134 45915 typ host generation 0"},"from":"-Dl0-BWMLUwmKvvcAAAD"}]

,{"type":"candidate","payload":{"label":0,"id":"audio","candidate":"candidate:13699457 1 udp 2122063615 10.11.239.176 51039 typ host generation 0"},"from":"-Dl0-BWMLUwmKvvcAAAD"}]

,{"type":"candidate","payload":{"label":1,"id":"video","candidate":"candidate:13699457 1 udp 2122063615 10.11.239.176 51039 typ host generation 0"},"from":"-Dl0-BWMLUwmKvvcAAAD"}]

,{"type":"candidate","payload":{"label":0,"id":"audio","candidate":"candidate:3298157534 1 tcp 1518280447 192.168.237.1 36295 typ host tcptype passive generation 0"},"from":"-Dl0-BWMLUwmKvvcAAAD"}]

,{"type":"candidate","payload":{"label":1,"id":"video","candidate":"candidate:3298157534 1 tcp 1518280447 192.168.237.1 36295 typ host tcptype passive generation 0"},"from":"-Dl0-BWMLUwmKvvcAAAD"}]

,{"type":"candidate","payload":{"label":0,"id":"audio","candidate":"candidate:2582868762 1 tcp 1518214911 172.17.84.124 44376 typ host tcptype passive generation 0"},"from":"-Dl0-BWMLUwmKvvcAAAD"}]

,{"type":"candidate","payload":{"label":1,"id":"video","candidate":"candidate:2582868762 1 tcp 1518214911 172.17.84.124 44376 typ host tcptype passive generation 0"},"from":"-Dl0-BWMLUwmKvvcAAAD"}]

,{"type":"candidate","payload":{"label":0,"id":"audio","candidate":"candidate:546324064 1 tcp 1518149375 172.17.116.134 41308 typ host tcptype passive generation 0"},"from":"-Dl0-BWMLUwmKvvcAAAD"}]

With google-webrtc-1.0.26405

03-15 18:29:47.008  2318  2347 D RoomRTCClient: GAE->C #1 : {"type":"candidate","label":0,"id":"0","candidate":"candidate:1510613869 1 udp 2121932543 127.0.0.1 58474 typ host generation 0 ufrag rhKZ network-id 4"}

03-15 18:29:47.009  2318  2347 D RoomRTCClient: GAE->C #2 : {"type":"candidate","label":0,"id":"0","candidate":"candidate:559267639 1 udp 2122005759 ::1 46169 typ host generation 0 ufrag rhKZ network-id 5"}

Actually, the problem does not seem related to _Trickle ICE_. When I look at the WebRTC traces, it seems that all UDP binds fail on the network interfaces that are not **lo**. I don't understand why, because I haven't changed the network configuration between my tests using **google-webrtc-1.0.+** and **libjingle-9127**. What is this mysterious error 101? See traces below. — François.CA, Mar 21 '19 at 05:18
`03-20 17:07:54.622 17423 19629 I basic_port_allocator.cc: (line 766): Allocate ports on 6 networks 03-20 17:07:54.622 17423 19629 W physical_socket_server.cc: (line 200): Binding socket to network address 10. 11.239.187 failed; result: -3 03-20 17:07:54.622 17423 19629 E basic_packet_socket_factory.cc: (line 53): UDP bind failed with error 101 03-20 17:07:54.622 17423 19629 W physical_socket_server.cc: (line 200): Binding socket to network address 172.17.116.154 failed; result: -3 03-20 17:07:54.622 17423 19629 E basic_packet_socket_factory.cc: (line 53): UDP bind failed with er (...) ` — François.CA, Mar 21 '19 at 05:23

Android WebRTC on LAN: only candidate 127.0.0.1 is sent to signaling server

0 Answers0