UnhandledError: Uncaught NotSupportedError: Failed to construct 'RTCPeerConnection': Failed to initialize native PeerConnection

Some of the participants who join a call get this error in their console log and after this, Strophe removes p2p handlers. Thus, Jicofo signals every participant that a new participant has joined, but is unable to sync over p2p. This makes the affected user’s thumbnail go blank and without any video or audio. Any other event such as the participant leaving the room, etc does not go through. Even incoming messages from the server such as focus changed status for a participant ID results in an error because the recipient is out of sync. This results in a ghost user. There is no predictable nature that I could observe. I tried opening multiple tabs on different browsers but this happens regardless, and randomly for some users but works well for others.

I’m running a standalone Jitsi server with Meet, Jicofo, Prosody, and JVB running on the same machine. I have a separate TURN server running on 443. ICE works as expected. I was using BOSH and then switched to websockets but this error has persisted.

I checked my TURN server logs and found that a ‘Failed to construct RTCPeerConnection’ happens right after:

realm <mydomain.com> user <>: incoming packet message processed, error 401: Unauthorized

I wonder if this is normal behavior. Logs tell me that every lookup with a user ID succeeds but the one without a user ID fails followed by the DOMException about failing to construct an RTCPeerConnection.

w3c-test.org tells me that this exception is expected behavior for turns and an empty username string: Ref http://w3c-test.org/webrtc/RTCConfiguration-iceServers.html

Is this something to do with the client trying to construct an RTCPeerConnection before receiving a user ID from Prosody?

Meanwhile, I don’t see any errors on my Prosody, JVB, and Jicofo logs. I’m kinda stuck with this for two days now and have tried several options so far. Has someone else also seen this issue before (and were able to resolve it)?

Gists with console and TURN log messages: https://gist.github.com/mavenik/6543dc5b7db40fe38a8ceba1b47a1712

Maybe I misunderstand you, but this looks like your meaning is: Strope removes p2p handlers, this is bad and causes UI disruption. However it was my impression that for Jitsi client, p2p failure is not an option it’s a normal behaviour

Thanks for the link.

That approach works when JVB is accessible over UDP. In my case, we do not have an option to access UDP connections over 10000 from corporate firewalls, which is why the only possibility is to rely on p2p. I haven’t observed this issue on https://meet.jit.si which can be accessed from corporate firewalls but p2p does not fail there. So I am fairly confident that it has something to do with my setup, but am unable to zero-in on the root cause.

it is my understanding that when using turn server jvb is still used, only indirectly.

Yes it is used. However, connections are relayed via port 443 of turns server. Prosody provides for secure access via mod_turncredentials in that case.

As per my understanding,
p2p scheme: client -> turns (TCP 443) -> JVB (UDP 10000)
JVB scheme: client -> JVB (UDP 10000)

As JVB scheme does not work with firewalls that block UDP traffic, the only option is to rely on p2p. In usual cases, JVB will be used as a fallback when p2p fails.

Indeed I misunderstood you. For me p2p means point-to-point in the 2 users special case, where
client <----> client
However I think that for Jitsi devs, this 's the meaning I think that is referred to in the doc and in the traces.

@damencho Could you please have a look at this?

I’m also facing an issue of ghost users being created when the browser tab is refreshed. I see that it’s a known issue that has been worked upon and addressed already, but I am still seeing it. Am I missing something?

Ref: Ghost participants on refresh in recent Chrome

Any specific logs, or configuration templates that you’d like to see?

What is the prosody version?

@damencho I’m using 0.11 from Prosody’s Debian repository.

And the jitsi-meet versions? Latest from stable or unstable?

@damencho I’m using the latest stable from Jitsi’s Debian repo. I’m following quick install steps and then additionally making modifications for TURN and websockets. Would you like to go over my configuration templates for Prosody, meet, Jicofo, JVB, and Nginx?

Websockets for communicating with jvb, or websockets instead of bosh?

Websockets instead of BOSH.

I picked configuration settings from here:

Just that I didn’t need to set JICOFO_HOST and JVB_HOST to private IP. Just adding a jitsi-videobridge component to prosody configuration was enough to resolve Authentication error reported on that thread.

Have you applied the prosody patch, enabled smacks module and such …
Pawel had discussed that in a thread under the docker repo, check that out as there are several tweaks you need to make it work.
Bosh should be working out of the box and not having any problems.

This may be related in your issue:
Tip: coturn + certbot issue on Debian Buster

Yes, I followed that thread and have made tunings to prosody.cfg.lua for smacks tuning and it seems like websockets are working fine. Earlier, things worked with BOSH except for a harmless warning that streams are enabled but websockets are not. Even in case of BOSH, this error persisted.

I see that meet.jit.si works without any problems related to ghost users or this error around RTCPeerConnection. Can you think of any specific settings related to that, which I might have missed?

@emrah It doesn’t look like it. My setup works for most users but fails for some (1 in 4 or 5). So I know for the fact that my Coturn is working fine. Just that one out of 4 or 5 users sends an empty username field which causes a failure with RTCPeerConnection and I am unable to figure out why and when that happens.

1 Like

I redid my setup and started over with quick install and TURN server setup steps. I skipped the Ansible role I wrote for provisioning and things worked. I think it is something to do with my Jinja2 templates. I relied entirely on the configuration from quick install. So right now, things are working but I haven’t been able to automate the process. I’ll try approaching this via manual setup instead of quick install and report issues if any.

As of now, this stands resolved, even though I haven’t been able to pinpoint the exact problem. Thanks everyone who participated. Appreciate it!

1 Like

@mavenik i am having exactly same issue, same set up and same behavior.
Since then do you have any idea what can i solve this P2P issue?