ICE4J, NAT, and TURN server impacts on pair failed issue

#1

Hi,

In our Jitsi meet installation, We have a problem with someone who is almost grayed in the meetings. He can’t send and receive any video or audio but sometimes can receive other participants’ audio. It happens almost 3 minutes after joining. In other words, the user joins, grayed, can’t send anything for 3 minutes while can receive other participants voices, then suddenly sends audio, but after 1 minute, again can’t send anything. The cycle repeats until the end of the meeting. I tracked jvb logs. For the mentioned user, there are some logs of the form:
pair failed for participant_ip:participant_port
It means the user is connected successfully and is not blocked by any gateway or firewall because its IP is visible.
I am sure about the IP of the user and have double-checked it.
After 3 minutes, the pair succeeds, the user can send and receive data, but after 1 minute, the user can’t send anything to other participants.
I took a look at ICE, TURN, STUN, and WEBRTC protocols and faced some questions which confuse me:

0- Do we have passed the right way to evaluate the problem?

1- ICE, TURN, STUN, and WEBRTC are used to initiate a tunnel between two peers whose IP is not valid in the network and mostly are behind several levels of NAT layers. Our media sever (jvb) has a public IP address and is accessible directly by the clients, so why do we need to use ICE protocol? The clients can send SDPs directly to the media server.

2- Deleted

3- Edited: How can I solve the pair failed problem? One idea is to set up a local TURN server (or use Google TURN server) and force the clients (whom their pair failed) to use TURN server to relay the media instead of JVB. Is it possible? If yes, How?
The idea comes from jitsi-videobridge/tcp.md at master · jitsi/jitsi-videobridge · GitHub , It is recommended to Use TURN in conjunction with JVB. Would you please describe more? Is there any documentation on setting up TURN and JVB together?

4- What is the purpose of org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS while we’re using ICE?

5- What is the difference between org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS and org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS?

6- Edited: Is there something like TURN or STUN in jitsimeet components?

I appreciate any help in answering the questions. There are some forums about pair failed but no solution is found. I can send any configuration settings of our system.

Some notes:
1- We have disabled p2p
2- The tests were on meeting with three or more participants.

#2

Cause this is how webrtc works, uses ice. There are cases where udp is not allowed in the network and it will fallback to using turn through TCP, but this fallback mechanism is handled by ICE and webrtc.

I’m not sure you can use the Google’s turnserver with no authentication.
I good example of turnserver configuration is to install jitsi-meet on a clean VM, which comes with default turnserver configured on standard ports for stun and turn.

The jvb to know its public address so it can send it to jicofo and jicofo will use that for the offers send to clients, so clients can send its media to jvb public address.

org.jitsi.videobridge is deprecated and probably already removed.

Yep, just install jitsi-meet using quick install guide.

1 Like
#3

Thanks a lot, Damian,

Only one question remains: Is it possible to install TURN service outside the media (jvb) server?

The reason: The IP of jvb may be blocked by a datacenter, gateway, or … for a user. In this case, If the TURN service is installed near JVB, then the user can’t connect to TURN too (Both have the same IP), so I’m willing to install TURN on another server and possibly another data center to fix this issue.

#4

according to Setting up TURN · Jitsi Meet Handbook , we only need to configure Prosody and TURN server, not JVB.
Does JVB understand that it should use our turn server via Prosody messaging?
If yes, since I’m not using Prosody, Do I have to hardcode the TURN server settings in JVB source code?

#5

Yep, check meet.jit.si this how it is deployed.
I was giving you the simple one server setup so you can check the working configurations, bit you can move components

#6

Thank you, sure I check the configuration of meet.jit.si, but what about the case in which the XMPP server is other than Prosody? I’m not using Prosody.
despite the above, Setting up TURN · Jitsi Meet Handbook says that TURN server is used for P2P calls while I’m going to use it for meetings with more than two participants (If one of the participants failed (pair failed), using TURN server to relay his media in and out of the meeting). Does JVB use TURN server for such a participant?

#7

Your xmpp server needs to support XEP-0215: External Service Discovery

We use turns for tcp connection to the bridge.

#8

You mean the TURN server initiates the request to the bridge? I thought it was the other way around.

#9

I want to use TURN server without authentication at first step, Is it still necessary to support XEP-0215?
from Setting up TURN · Jitsi Meet Handbook :
One way to configure TURN support in meet with a static configuration. You can simply fill out the p2p.stunServers option with appropriate values, e.g.:

[
    { urls: 'turn:turn.example.com1', credential: 'user', password: 'pass' },
]
#10

Yep, the client uses the turnserver to relay its request to the bridge

#11

Well the servers coming for jvb are always coming from xmpp as everyone wants to use turnservers with authentication, otherwise you risk a lot of abuse of traffic.

1 Like
#12

The clients are authenticated by XMPP server. My XMPP server (Ejabberd) supports XEP 0215 only for business plans (I don’t want to use a business plan yet). Also, I want to set up the TURN as fast as possible, So at the first step, I want to bypass credential exchange between the XMPP server and the TURN server and use hardcoded credentials in config.js. In the next steps, I will find a way to solve the security issues.

Thank you, Damian, It was quite well.

#13

You will need to modify lib-jitsi-meet if you want to use that for jvb connection.

#14

Thanks, I try it.

#15

I finally succeeded in solving the pair failed problem by setting up a TURN server without using Prosody mod_turncredential (you should hardcode the credential in lib-jitsimeet or use coturn rest API.)
Thanks to the guys who provided solutions here to test TURN server functionality.

#16

Why Jitsi disabled useTurnUdp in config.js?
what’s the difference between turns and turn in TURN urls? Do I have to include both of them in Iceservers?
(ex: turn:example.com:5349, turns:example.com:5349)

#17

Turns is the one over tcp. There is no point of using turn over udp, as if you can do udp, then connect directly to jvb instead of adding one more hop and adding on RTT of every packet.

#18

Yeah, that’s right, Thank you.
but what about turns, Does it mean using SSL to connect to the turn server? according to the Coturn documentation, both secure and plain connections can be established with 3478 and 5349.

#19

Yes, turns means turn over TLS. This looks as a normal https session.

1 Like