ICE connectivity check failures

Description

---

In a two-server environment, one host is running jitsi-meet (from a recently jitsi nightly deb package), with some small configuration modifications detailed below, and another host is running webrtc-streamer (with a small fix applied as per #688).

The streamer client appears to join the room and the browser client expands a full black screen to commence video output, but connectivity from the streamer client drops out, reproducibly.

There are some existing reports (both in the Jitsi community forum, and under the https://github.com/jitsi repo issue trackers) of similar issues and most of them point towards issues with NAT and ICE configuration - in this case the server is configured with near-default settings. The modifications from default are:

• /etc/apache2/sites-enabled/localhost.conf: Header set Access-Control-Allow-Origin "*" added to allow cross-domain JS requests
• /etc/prosody/prosody.cfg.lua: cross_domain_bosh = true added to allow cross-domain JS requests
• /etc/jitsi/meet/localhost-config.js - config.p2p.enabled: false - configured since the environment is intended for a minimum of three participants (streamer and at least two human discussion partners)

No firewalling is present on the jitsi-meet server. Attempts to use each of the following configuration keys (often in combination) in /etc/jitsi/videobridge/sip-communicator.properties have been attempted but without any success so far:

• org.jitsi.videobridge.TCP_HARVESTER_PORT
• org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT
• org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS
• org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS

The following similar reading references have been found:

• https://git.fairkom.net/hosting/fairmeeting/issues/7
• https://github.com/jitsi/ice4j/issues/116

Current behavior

---

• Human client joins channel test
• Streamer client joins channel test for stream named Example
• Human client observes participant named Example joining the room
• Human client observes connectivity issues (see screenshot) for participant Example, without receiving any video/audio from them

Expected Behavior

---

• Participant Example is able to join and maintain a connection to the room

Possible Solution

---

This seems potentially related to ICE and client connectivity checks. The following warnings appear in the videobridge logs:

JVB 2018-12-26 01:05:46.475 INFO: [266] org.ice4j.ice.ConnectivityCheckClient.log() Error response for pair: 192.168.2.126:10000/udp/host -> 192.168.2.126:41487/udp/prflx (stream.RTP), failing.  Code = 401(class=4; number=1)

The error code 401 from these logs appears to be retrieved in ice4 and documented in RFC 3489.

In the client, which builds upon the Google webrtc project, warnings of the following format appear:

[042:060] [12565] (port.cc:614): Port[e807f890:video:1:0:local:Net[wlan0:192.168.2.x/24:Unknown:id=3]]: Received STUN request with bad local username gZhD from 192.168.2.x:10000

Steps to reproduce

---

• Configure two hosts; one jitsi-meet, one webrtc-streamer with packages and versions documented here
• Apply documented configuration changes from this issue
• Join a channel as a human client
• Begin streaming to the same channel via xmppvideostream.html in webrtc-streamer

NB: This same behavior can be observed by running webrtc-streamer locally against the cloud-hosted https://meet.jit.si instance - however server logs are not available in that case.

Environment details

---

• os: 18.04.1 LTS (Bionic Beaver)
• jitsi-meet: 1.0.3444-1 (nightly)
• webrtc: e121eb9
• webrtc-streamer: b344d83
• webrtc-streamer-html: 7d90500

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ghost]

Just for the record:

• Building against bcgit/bc-java@2ae106c63 has allowed me to get to the point where the webrtc-streamer client connects and no more ‘Bunny is having connectivity issues …’ messages appear for the human participant
• Video still does not appear and I believe this is due to a DTLS handshake failure for the RTP stream - the following error appears in the webrtc-streamer client at high logging verbosity:

[005:363] [16909] (opensslstreamadapter.cc:784): BeginSSL with peer.
[005:363] [16909] (opensslstreamadapter.cc:841): ContinueSSL
[005:364] [16909] (opensslstreamadapter.cc:872):  -- error want read

• I’ve tracked the error in the previous item down to an open issue in the webrtc issue tracker: https://bugs.chromium.org/p/webrtc/issues/detail?id=3644 , and have almost managed to rebase and apply one of the proposed patches to fix this, but there’s one remaining issue to resolve re: determining whether a server address is ‘secure’ or not for the purposes of using UDP (insecure) vs DTLS (secure)