ICE connectivity check failures #3738
Comments
|
Attaching jvb.log |
|
https://community.jitsi.org/t/jvb-how-to-listen-to-port-443/15017 also looks relevant, but seems to suggest that setting up two separate machines is required - one for JVB and one for the jitsi-meet webserver. Is there a convenient way to have everything work 'out of the box' on a single host, or with minor configuration changes? (it'd seem beneficial if possible - allowing new customers to onboard more easily and saving support overhead) Until discovering the root cause I'm not entirely clear why single-host seems challenging (or if that indeed is the problem I'm hitting here) |
|
Is your jvb running behind NAT? |
|
The standard jitsi meet set-up on one machine does not allow to harvest TCP 443, it falls back to 4443 as 443 is being used by nginx. This may not affect your usage scenario. Making use of TCP 443 for media transport is supposed to be a "last resort" in case a user is sitting behind a very restricted firewall. For making use of TCP 443 for media transport you either split signalling (=jicofo+prosody+nginx) and videobridge on two servers, so that the latter also can bind to a 443 port OR you try to replace nginx with jetty web server - however we have not been able to make that work https://git.fairkom.net/hosting/fairmeeting/issues/17 |
|
Thanks @damencho @rasos for your responses. In this case there is no NAT involved - the jitsi-meet server is listening with apache2 on 443 (using the localhost.conf bundled with the In the I'd like to get this working on a single host if possible, partly because I'd like to understand what's required for that, but thank you for the ticket reference @rasos, I'll try split signalling if I can't make further progress. |
|
I don't get why you need to touch these: What is your idea? So NAT_HARVESTER_LOCAL_ADDRESS and NAT_HARVESTER_PUBLIC_ADDRESS, need to be set if jvb does not have locally configured its public address, cause jvb needs to add it in signaling. |
|
@damencho I'm fairly confident that the NAT settings should not be required; in this issue I'm reproducing everything within a local network, and JVB starts up and listens on an IP and port which the client can access: My plan / thinking with the overriden TCP harvesting settings was that perhaps the client wasn't aware of the 443 -> 4443 fallback and that a mapping could help. On second thoughts I don't think that should be required. Attached here is a Next I will try the |
|
@damencho My mistake; the network paste above was from a previous execution (where I had moved |
|
Does your deployment have its public address on the local machine, the address that matches the dns you use to access the deployment? If you open 3 tabs on your PC, does it work? |
|
@damencho Good check, thanks - yep, the public address is on the local machine. While testing locally I'm using When I browse to |
|
Next configuration: Results - same behavior:
|
This is not correct, remove those lines if you are not putting the public address there. From your words, I understand that you test everything in the same network and there is no public address. If this is the case you don't need any setting. Open chrome://webrtc-internals and find the streamer ssrc/streams and see is anything received at all. |
|
@damencho I'm not sure exactly what to look for here, but it does appear that some streams are being created in the human participant chrome browser:
Let me know if I should dump more of this for debugging purposes. |
|
Check recv ssrc, are there any bytes received |
|
@damencho it appears not - |
|
@damencho any recommendations on next debugging steps? Glad to provide further details and investigation while this is fresh in my mind. For what it's worth, I do also have a local checkout of |
|
Any errors on the other side, why ice fails there ... Not sure how ti debug the other client you use ... |
|
@damencho Sounds good; perhaps I'll have to follow this in a chrome-webrtc issue tracker too; I'll leave this issue open until finding out more |
ghost
mentioned this issue
|
Adding DTLS 1.2 support in |
|
Just for the record:
|
ghost
mentioned this issue
|
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. |
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 runningwebrtc-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 = trueadded 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-meetserver. Attempts to use each of the following configuration keys (often in combination) in/etc/jitsi/videobridge/sip-communicator.propertieshave been attempted but without any success so far:The following similar reading references have been found:
Current behavior
testtestfor stream namedExampleExamplejoining the roomExample, without receiving any video/audio from themExpected Behavior
Exampleis able to join and maintain a connection to the roomPossible Solution
This seems potentially related to ICE and client connectivity checks. The following warnings appear in the videobridge logs:
The error code
401from these logs appears to be retrieved in ice4 and documented in RFC 3489.In the client, which builds upon the Google
webrtcproject, warnings of the following format appear:Steps to reproduce
jitsi-meet, onewebrtc-streamerwith packages and versions documented herexmppvideostream.htmlinwebrtc-streamerNB: This same behavior can be observed by running
webrtc-streamerlocally against the cloud-hosted https://meet.jit.si instance - however server logs are not available in that case.Environment details
18.04.1 LTS (Bionic Beaver)1.0.3444-1 (nightly)e121eb9b344d837d90500The text was updated successfully, but these errors were encountered: