Video not working in Chrome when client has no default route

[Esger Abbink]

Hi All,

I am having some trouble with webrtc and chrome. Hope anybody can shed some light how to solve this.

I have a device "Server" (running Linux/GStreamer) that has a usb camera connected. A second device "Client" (Phone/Laptop) is connected to the device via either wifi or wired ethernet. Both are in the same subnet: server = 192.168.10.1, client = 192.168.10.2.

The server device runs a web application that can be used to access the usb camera video stream. SDP offer & answer are exchanged over a websocket connection. The server only offers candidates on the subnet the client is connected to.

Now, if the client device has no default route (ie. it is connected solely to the server device), Chrome is not able to establish a connection. It seems it discards the local candidate because the address is (still) 0.0.0.0(?) when calling CheckCandidateFilter() in basic_port_allocator.cc. The SDP answer sent to the server does not contain a candidate, and ICE connectivity checking fails.

partial chrome log:

[15092:1332:0611/144150.726:INFO:basic_port_allocator.cc(379)] Start getting ports with turn_port_prune_policy 0
[15092:1332:0611/144150.726:INFO:basic_port_allocator.cc(913)] Network manager has started
[15092:1332:0611/144150.726:INFO:basic_port_allocator.cc(823)] Allocate ports on any any
[15092:1332:0611/144150.726:INFO:basic_port_allocator.cc(1424)] Net[any:0.0.0.x/0:Wildcard:id=0]: Allocation Phase=Udp
[15092:1332:0611/144150.726:INFO:basic_port_allocator.cc(936)] Adding allocated port for video0
[15092:1332:0611/144150.726:INFO:basic_port_allocator.cc(956)] Port[1d64000:video0:1:0:host:Net[any:0.0.0.x/0:Wildcard:id=0]]: Added port to allocator
[15092:1332:0611/144150.726:INFO:basic_port_allocator.cc(1424)] Net[any:0:0:0:x:x:x:x:x/0:Wildcard:id=0]: Allocation Phase=Udp
[15092:1332:0611/144150.726:INFO:basic_port_allocator.cc(936)] Adding allocated port for video0
[15092:1332:0611/144150.726:INFO:basic_port_allocator.cc(956)] Port[1d69500:video0:1:0:host:Net[any:0:0:0:x:x:x:x:x/0:Wildcard:id=0]]: Added port to allocator
[15092:1332:0611/144150.729:INFO:basic_port_allocator.cc(973)] Port[1d64000:video0:1:0:host:Net[any:0.0.0.x/0:Wildcard:id=0]]: Gathered candidate: Cand[:3279208271:1:udp:2113937151:0.0.0.x:56879:host::0:uMaP:sO7/q5nROVsw272S2TehbRoh:0:999:0]
[15092:1332:0611/144150.729:INFO:basic_port_allocator.cc(1006)] Port[1d64000:video0:1:0:host:Net[any:0.0.0.x/0:Wildcard:id=0]]: Port ready.
[15092:1332:0611/144150.730:INFO:basic_port_allocator.cc(1017)] Discarding candidate because it doesn't match filter.
[15092:1332:0611/144150.730:INFO:basic_port_allocator.cc(1118)] Port[1d64000:video0:1:0:host:Net[any:0.0.0.x/0:Wildcard:id=0]]: Port completed gathering candidates.
[15092:1332:0611/144150.730:INFO:basic_port_allocator.cc(973)] Port[1d69500:video0:1:0:host:Net[any:0:0:0:x:x:x:x:x/0:Wildcard:id=0]]: Gathered candidate: Cand[:3972487048:1:udp:2113929727:[0:0:0:x:x:x:x:x]:56880:host::0:uMaP:sO7/q5nROVsw272S2TehbRoh:0:999:0]
[15092:1332:0611/144150.730:INFO:basic_port_allocator.cc(1006)] Port[1d69500:video0:1:0:host:Net[any:0:0:0:x:x:x:x:x/0:Wildcard:id=0]]: Port ready.
[15092:1332:0611/144150.730:INFO:basic_port_allocator.cc(1017)] Discarding candidate because it doesn't match filter.
[15092:1332:0611/144150.730:INFO:basic_port_allocator.cc(1118)] Port[1d69500:video0:1:0:host:Net[any:0:0:0:x:x:x:x:x/0:Wildcard:id=0]]: Port completed gathering candidates.
[15092:1332:0611/144150.741:INFO:basic_port_allocator.cc(1192)] All candidates gathered for video0:1:0

SDP answer:

{"sdp":"v=0
o=- 8825299116411210922 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video0
a=msid-semantic: WMS
m=video 9 UDP/TLS/RTP/SAVPF 97
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:N4tI
a=ice-pwd:CW7Sg12JZ/+kBU7W0CdaIX05
a=ice-options:trickle
a=fingerprint:sha-256 51:09:99:1B:4F:B6:37:96:85:56:7E:95:68:0F:EC:CB:BB:9F:F8:8B:50:9A:F2:78:6C:3D:32:51:2A:69:DE:88
a=setup:active
a=mid:video0
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:97 H264/90000
a=rtcp-fb:97 transport-cc
a=rtcp-fb:97 nack pli
a=fmtp:97 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
","type":"answer"}

Note that using Firefox everything works fine (both on phone and laptop). I can see at the server side there are candidates provided and the video stream is established.

If I configure the client to have a default route (to a bogus non-existing gateway(!)) Chrome suddenly ís able to establish the video stream. 

Chrome log then shows:

[4636:4396:0611/151348.584:INFO:basic_port_allocator.cc(379)] Start getting ports with turn_port_prune_policy 0
[4636:4396:0611/151348.584:INFO:basic_port_allocator.cc(913)] Network manager has started
[4636:4396:0611/151348.584:INFO:basic_port_allocator.cc(823)] Allocate ports on any any
[4636:4396:0611/151348.584:INFO:basic_port_allocator.cc(1424)] Net[any:0.0.0.x/0:Wildcard:id=0]: Allocation Phase=Udp
[4636:4396:0611/151348.584:INFO:basic_port_allocator.cc(936)] Adding allocated port for video0
[4636:4396:0611/151348.584:INFO:basic_port_allocator.cc(956)] Port[714b00:video0:1:0:host:Net[any:0.0.0.x/0:Wildcard:id=0]]: Added port to allocator
[4636:4396:0611/151348.584:INFO:basic_port_allocator.cc(1424)] Net[any:0:0:0:x:x:x:x:x/0:Wildcard:id=0]: Allocation Phase=Udp
[4636:4396:0611/151348.584:INFO:basic_port_allocator.cc(936)] Adding allocated port for video0
[4636:4396:0611/151348.584:INFO:basic_port_allocator.cc(956)] Port[13a9400:video0:1:0:host:Net[any:0:0:0:x:x:x:x:x/0:Wildcard:id=0]]: Added port to allocator
[4636:4396:0611/151348.588:INFO:basic_port_allocator.cc(973)] Port[714b00:video0:1:0:host:Net[any:0.0.0.x/0:Wildcard:id=0]]: Gathered candidate: Cand[:1451501089:1:udp:2113937151:192.168.10.x:53430:host::0:5xTl:1jI0pMv2fnd1QRh3/3BzGFHv:0:999:0]
[4636:4396:0611/151348.588:INFO:basic_port_allocator.cc(1006)] Port[714b00:video0:1:0:host:Net[any:0.0.0.x/0:Wildcard:id=0]]: Port ready.
[4636:4396:0611/151348.588:INFO:basic_port_allocator.cc(1118)] Port[714b00:video0:1:0:host:Net[any:0.0.0.x/0:Wildcard:id=0]]: Port completed gathering candidates.
[4636:4396:0611/151348.588:INFO:basic_port_allocator.cc(973)] Port[13a9400:video0:1:0:host:Net[any:0:0:0:x:x:x:x:x/0:Wildcard:id=0]]: Gathered candidate: Cand[:4271038715:1:udp:2113929727:[0:0:0:x:x:x:x:x]:53431:host::0:5xTl:1jI0pMv2fnd1QRh3/3BzGFHv:0:999:0]
[4636:4396:0611/151348.588:INFO:basic_port_allocator.cc(1006)] Port[13a9400:video0:1:0:host:Net[any:0:0:0:x:x:x:x:x/0:Wildcard:id=0]]: Port ready.
[4636:4396:0611/151348.588:INFO:basic_port_allocator.cc(1017)] Discarding candidate because it doesn't match filter.
[4636:4396:0611/151348.588:INFO:basic_port_allocator.cc(1118)] Port[13a9400:video0:1:0:host:Net[any:0:0:0:x:x:x:x:x/0:Wildcard:id=0]]: Port completed gathering candidates.
[4636:4396:0611/151348.600:INFO:basic_port_allocator.cc(1192)] All candidates gathered for video0:1:0

Note that the candidate now has the local interface address, instead of 0.0.0.0. And the SDP answer indeed has a candidate:

{"sdp":"v=0
o=- 6374905707583757402 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video0
a=msid-semantic: WMS
m=video 9 UDP/TLS/RTP/SAVPF 97
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:1018052734 1 udp 2113937151 1f91e742-e7bc-4853-b9a8-a1a3c412c9da.local 56847 typ host generation 0 network-cost 999
a=ice-ufrag:YWPQ
a=ice-pwd:OouLnhk4GdXwncjcG5gceTpE
a=ice-options:trickle
a=fingerprint:sha-256 1B:0B:CA:BD:67:D3:1B:76:2B:F6:94:D4:60:3C:A0:2A:5A:47:92:F2:F3:2F:F2:5C:92:F2:A4:DF:F2:53:01:C7
a=setup:active
a=mid:video0
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:97 H264/90000
a=rtcp-fb:97 transport-cc
a=rtcp-fb:97 nack pli
a=fmtp:97 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
","type":"answer"}

What is happening here, why is Chrome/Webrtc not using the interface address when there is no default route?

Is this expected behavior? If so, what can I do differently to make this situation work? Or have we hit a bug here?

Any help appreciated!

Esger

[Esger Abbink]

Additional testing shows Chromium, Edge, and Opera suffer from the same issue. Whereas Firefox has no problem also on OSX. I was not yet able to test Safari. But it seems the problem is bound to Chromium based browsers.