Best Practice


#1

Hey guys,

This may be too broad/non-specific of a question. I’m curious to hear what the general Jitsi best practice is, say for a group that might have as many as 30 on at one time (unlikely). Such as:

  • System requirements
  • Basic settings enabled such as Simulcast or screen sharing

I have been tasked with setting Jitsi up in an offline environment which makes things difficult, but I don’t believe that effects things too much. I’d have to implement coTURN instead of using Googles TURN servers etc.

I’ve looked around and haven’t really seen a general best practice and I know no one best practice is for everyone, everyones org/setup is slightly different than others. Maybe a high level “best practice” ? My goal is to nail down Jitsi best practices so I have the best or close to the best practices implemented here.

Thanks in advance!
Nate


#2

There is no best practice. For 30 people at the same time(with simulcast) very very roughly this means a max of 150 Mbit network, this would be the only constraint.

If your a looking for deploying signaling (prosody+jicofo) and media (jvb) on the same machine, then another recommendation is to have at least 8GB of RAM on it.

If all the clients will be in the same network (as you mention offline environment) you don’t need any stun/turn servers. Stun you will need for p2p to be able to discover public addresses and ports, in an environment without public address no need of that. Turn(coturn listening on port tcp 443 with valid cert) you need for clients behind restrictive enterprise firewalls when clients are in the same network they do not need that and have direct access to jvb, which is a relay the same way turn server is a relay.


#3

Sweet thanks for the info!

Since H.264 does not support simulcast is it recommended to have H.264 disabled across the board? I guess is it best to do whatever I can to get Simulcast to be working, or are there alternatives to simulcast built into Jitsi as well. I am trying to figure out if having this enabled there being almost a ‘conflict of interest’ which would cause issues between using and not using Simulcast.

        p2p: {
        // Enables peer to peer mode. When enabled the system will try to
        // establish a direct connection when there are exactly 2 participants
        // in the room. If that succeeds the conference will stop sending data
        // through the JVB and use the peer to peer connection instead. When a
        // 3rd participant joins the conference will be moved back to the JVB
        // connection.
        enabled: true,

EDIT:
I mention the above because earlier on in the config we have this bit -

    // If set to true, prefer to use the H.264 video codec (if supported).
    // Note that it's *****not recommended to do this because simulcast is not**
    // supported when  using H.264.***** For 1-to-1 calls this setting is enabled by
    // default and can be toggled in the p2p section.
    // preferH264: true,

Also I have a sort of long list of questions, would a mailing list be most appropriate for that as opposed to opening various threads here?

Anyways thanks damencho and everyone else, great info and very helpful.

Nate


#4

While ago we deprecated the mailinglist as we introduced discourse and this was what the community was asking, seems over time people stopped or didn’t want to use mailinglist, so there is none at the moment. The community forum is the best place for asking questions.