[jitsi-dev] Crazy idea: To run Jitsi Meet WITHOUT Jitsi Videobridge


#1

Sorry I am new to Jitsi Meet. My crazy idea may be stupid.

Jitsi Meet is amazing and I am thinking to host it on my own server, which
may be available to public.

According to my understanding, Jitsi Meet is not based on p2p architecture,
which is different from a typical WebRTC application. If every video stream
is relayed by Videobridge, the server cost could be heavy. So I am thinking
the possibility to run Jitsi Meet WITHOUT Jitsi Videobridge to low the
server cost.

Technically is it possible? Also, if it is possible, in theory, Jitsi Meet
can talk with other WebRTC applications if they use same signal server.

Can someone clarify?

Thank you in advance,

Ying


#2

Hey there,

Sorry I am new to Jitsi Meet. My crazy idea may be stupid.

Jitsi Meet is amazing and I am thinking to host it on my own server, which
may be available to public.

Thanks for your kind words!

According to my understanding, Jitsi Meet is not based on p2p architecture,
which is different from a typical WebRTC application. If every video stream
is relayed by Videobridge, the server cost could be heavy.

It could be but it probably wouldn't unless you have a *very*
successful service (as in millions of calls per month).

So I am thinking
the possibility to run Jitsi Meet WITHOUT Jitsi Videobridge to low the
server cost.

Full mesh is a very bad idea for multi-party calls. It basically means
that all of your calls, beyond 1-to-1 and potentially 3-participant
calls, would be very bad quality. The one place where a peer-to-peer
connection makes sense is a 1-to-1 call.

All of Meet is built around the idea of bridge connections. Adding a
full mesh mode would hence imply a lot of effort for no substantial
gain.

What we would possibly do though is to accept a patch that *in
addition* to the bridge peer connection, also creates a direct one
where this is possible and switches between the two when this makes
sense.

Technically is it possible? Also, if it is possible, in theory, Jitsi Meet
can talk with other WebRTC applications if they use same signal server.

Our signaling server is Jicofo (Jitsi Conference Focus). I am not
aware of anyone other than Jitsi Meet using Jicofo.

Can someone clarify?

Hope this helps,
Emil

···

On Thu, Nov 12, 2015 at 8:04 AM, Ying LEE <mr.ying.lee@gmail.com> wrote:

Thank you in advance,

Ying

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#3

We do this in Talky - peer-to-peer for 2 participants with an upgrade to the JVB when the 3rd participant joins. It's complicated to handle and I'm not sure that it's a great thing to recommend in general.

Peter

···

On 11/15/15 3:28 PM, Emil Ivov wrote:

Hey there,

On Thu, Nov 12, 2015 at 8:04 AM, Ying LEE <mr.ying.lee@gmail.com> wrote:

Sorry I am new to Jitsi Meet. My crazy idea may be stupid.

Jitsi Meet is amazing and I am thinking to host it on my own server, which
may be available to public.

Thanks for your kind words!

According to my understanding, Jitsi Meet is not based on p2p architecture,
which is different from a typical WebRTC application. If every video stream
is relayed by Videobridge, the server cost could be heavy.

It could be but it probably wouldn't unless you have a *very*
successful service (as in millions of calls per month).

So I am thinking
the possibility to run Jitsi Meet WITHOUT Jitsi Videobridge to low the
server cost.

Full mesh is a very bad idea for multi-party calls. It basically means
that all of your calls, beyond 1-to-1 and potentially 3-participant
calls, would be very bad quality. The one place where a peer-to-peer
connection makes sense is a 1-to-1 call.

All of Meet is built around the idea of bridge connections. Adding a
full mesh mode would hence imply a lot of effort for no substantial
gain.

What we would possibly do though is to accept a patch that *in
addition* to the bridge peer connection, also creates a direct one
where this is possible and switches between the two when this makes
sense.


#4

Hey there,

Sorry I am new to Jitsi Meet. My crazy idea may be stupid.

Jitsi Meet is amazing and I am thinking to host it on my own server,
which
may be available to public.

Thanks for your kind words!

According to my understanding, Jitsi Meet is not based on p2p

architecture,
which is different from a typical WebRTC application. If every video
stream
is relayed by Videobridge, the server cost could be heavy.

It could be but it probably wouldn't unless you have a *very*
successful service (as in millions of calls per month).

So I am thinking

the possibility to run Jitsi Meet WITHOUT Jitsi Videobridge to low the
server cost.

Full mesh is a very bad idea for multi-party calls. It basically means
that all of your calls, beyond 1-to-1 and potentially 3-participant
calls, would be very bad quality. The one place where a peer-to-peer
connection makes sense is a 1-to-1 call.

All of Meet is built around the idea of bridge connections. Adding a
full mesh mode would hence imply a lot of effort for no substantial
gain.

What we would possibly do though is to accept a patch that *in
addition* to the bridge peer connection, also creates a direct one
where this is possible and switches between the two when this makes
sense.

We do this in Talky - peer-to-peer for 2 participants with an upgrade to
the JVB when the 3rd participant joins. It's complicated to handle

That's good feedback. Thanks! Could you maybe share where the complexity

came from?

and I'm not sure that it's a great thing to recommend in general.

I guess it is a matter of a lesser evil. I certainly wouldn't think it

would be worth it for anything but massive services. Once you are there
though it is a matter of whether you'd be happy to pay more or accept
whatever compromises are in front of you.

Emil

···

On Sunday, 15 November 2015, Peter Saint-Andre <peter@andyet.net> wrote:

On 11/15/15 3:28 PM, Emil Ivov wrote:

On Thu, Nov 12, 2015 at 8:04 AM, Ying LEE <mr.ying.lee@gmail.com> wrote:

Peter

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#5

        Hey there,

            Sorry I am new to Jitsi Meet. My crazy idea may be stupid.

            Jitsi Meet is amazing and I am thinking to host it on my own
            server, which
            may be available to public.

        Thanks for your kind words!

            According to my understanding, Jitsi Meet is not based on
            p2p architecture,
            which is different from a typical WebRTC application. If
            every video stream
            is relayed by Videobridge, the server cost could be heavy.

        It could be but it probably wouldn't unless you have a *very*
        successful service (as in millions of calls per month).

            So I am thinking
            the possibility to run Jitsi Meet WITHOUT Jitsi Videobridge
            to low the
            server cost.

        Full mesh is a very bad idea for multi-party calls. It basically
        means
        that all of your calls, beyond 1-to-1 and potentially 3-participant
        calls, would be very bad quality. The one place where a peer-to-peer
        connection makes sense is a 1-to-1 call.

        All of Meet is built around the idea of bridge connections. Adding a
        full mesh mode would hence imply a lot of effort for no substantial
        gain.

        What we would possibly do though is to accept a patch that *in
        addition* to the bridge peer connection, also creates a direct one
        where this is possible and switches between the two when this makes
        sense.

    We do this in Talky - peer-to-peer for 2 participants with an
    upgrade to the JVB when the 3rd participant joins. It's complicated
    to handle

That's good feedback. Thanks! Could you maybe share where the complexity
came from?

I could ask Lance or Fippo to chime in, but as I understand it the UI code is fairly complex. For instance, there is a slight delay as the session is upgraded from p2p to mediated, which can be confusing for users. Also, there's some logic to handle downgrades but you don't want to downgrade too fast once the session goes back down to 2 people (I think we settled on 30 seconds). It was a bit tricky to get these things right.

    and I'm not sure that it's a great thing to recommend in general.

I guess it is a matter of a lesser evil. I certainly wouldn't think it
would be worth it for anything but massive services. Once you are there
though it is a matter of whether you'd be happy to pay more or accept
whatever compromises are in front of you.

Actually I think it is helpful for even relatively small services, because it can save you money on running multiple JVB instances (which in our experience run best on bare metal servers, and those aren't cheap).

Peter

···

On 11/15/15 3:51 PM, Emil Ivov wrote:

On Sunday, 15 November 2015, Peter Saint-Andre <peter@andyet.net > <mailto:peter@andyet.net>> wrote:
    On 11/15/15 3:28 PM, Emil Ivov wrote:
        On Thu, Nov 12, 2015 at 8:04 AM, Ying LEE > <mr.ying.lee@gmail.com> wrote:


#6

Just my 2 cents, but I think that having p2p as default in jitsimeet when
only 2 clients join, and then upgrade to SFU when more clients join would
be a very welcome addition!

I totally understand that more than 3 clients make p2p very problematic,
but 3 or less should be possible to do p2p with great quality (like the
Temasys guys have done with get a room) and with the added privacy bonus
(no need to have jvb decrypt the streams).

Are there any plans to do this?

Cheers,
Peter

···

On Sun, Nov 15, 2015 at 10:51 PM, Emil Ivov <emcho@jitsi.org> wrote:

On Sunday, 15 November 2015, Peter Saint-Andre <peter@andyet.net> wrote:

On 11/15/15 3:28 PM, Emil Ivov wrote:

Hey there,

On Thu, Nov 12, 2015 at 8:04 AM, Ying LEE <mr.ying.lee@gmail.com> wrote:

Sorry I am new to Jitsi Meet. My crazy idea may be stupid.

Jitsi Meet is amazing and I am thinking to host it on my own server,
which
may be available to public.

Thanks for your kind words!

According to my understanding, Jitsi Meet is not based on p2p

architecture,
which is different from a typical WebRTC application. If every video
stream
is relayed by Videobridge, the server cost could be heavy.

It could be but it probably wouldn't unless you have a *very*
successful service (as in millions of calls per month).

So I am thinking

the possibility to run Jitsi Meet WITHOUT Jitsi Videobridge to low the
server cost.

Full mesh is a very bad idea for multi-party calls. It basically means
that all of your calls, beyond 1-to-1 and potentially 3-participant
calls, would be very bad quality. The one place where a peer-to-peer
connection makes sense is a 1-to-1 call.

All of Meet is built around the idea of bridge connections. Adding a
full mesh mode would hence imply a lot of effort for no substantial
gain.

What we would possibly do though is to accept a patch that *in
addition* to the bridge peer connection, also creates a direct one
where this is possible and switches between the two when this makes
sense.

We do this in Talky - peer-to-peer for 2 participants with an upgrade to
the JVB when the 3rd participant joins. It's complicated to handle

That's good feedback. Thanks! Could you maybe share where the complexity

came from?

and I'm not sure that it's a great thing to recommend in general.

I guess it is a matter of a lesser evil. I certainly wouldn't think it

would be worth it for anything but massive services. Once you are there
though it is a matter of whether you'd be happy to pay more or accept
whatever compromises are in front of you.

Emil

Peter

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

Just my 2 cents, but I think that having p2p as default in jitsimeet when
only 2 clients join, and then upgrade to SFU when more clients join would
be a very welcome addition!

I totally understand that more than 3 clients make p2p very problematic,
but 3 or less should be possible to do p2p with great quality

(like the Temasys guys have done with get a room) and with the added

privacy bonus (no need to have jvb decrypt the streams).

Are there any plans to do this?

We (the Atlassian team) want to do this at some point but don't currently
have it scheduled.

Emil

···

On Tuesday, 17 November 2015, Peter Villeneuve <petervnv1@gmail.com> wrote:

Cheers,
Peter

On Sun, Nov 15, 2015 at 10:51 PM, Emil Ivov <emcho@jitsi.org > <javascript:_e(%7B%7D,'cvml','emcho@jitsi.org');>> wrote:

On Sunday, 15 November 2015, Peter Saint-Andre <peter@andyet.net >> <javascript:_e(%7B%7D,'cvml','peter@andyet.net');>> wrote:

On 11/15/15 3:28 PM, Emil Ivov wrote:

Hey there,

On Thu, Nov 12, 2015 at 8:04 AM, Ying LEE <mr.ying.lee@gmail.com> >>>> wrote:

Sorry I am new to Jitsi Meet. My crazy idea may be stupid.

Jitsi Meet is amazing and I am thinking to host it on my own server,
which
may be available to public.

Thanks for your kind words!

According to my understanding, Jitsi Meet is not based on p2p

architecture,
which is different from a typical WebRTC application. If every video
stream
is relayed by Videobridge, the server cost could be heavy.

It could be but it probably wouldn't unless you have a *very*
successful service (as in millions of calls per month).

So I am thinking

the possibility to run Jitsi Meet WITHOUT Jitsi Videobridge to low the
server cost.

Full mesh is a very bad idea for multi-party calls. It basically means
that all of your calls, beyond 1-to-1 and potentially 3-participant
calls, would be very bad quality. The one place where a peer-to-peer
connection makes sense is a 1-to-1 call.

All of Meet is built around the idea of bridge connections. Adding a
full mesh mode would hence imply a lot of effort for no substantial
gain.

What we would possibly do though is to accept a patch that *in
addition* to the bridge peer connection, also creates a direct one
where this is possible and switches between the two when this makes
sense.

We do this in Talky - peer-to-peer for 2 participants with an upgrade to
the JVB when the 3rd participant joins. It's complicated to handle

That's good feedback. Thanks! Could you maybe share where the complexity

came from?

and I'm not sure that it's a great thing to recommend in general.

I guess it is a matter of a lesser evil. I certainly wouldn't think it

would be worth it for anything but massive services. Once you are there
though it is a matter of whether you'd be happy to pay more or accept
whatever compromises are in front of you.

Emil

Peter

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org <javascript:_e(%7B%7D,'cvml','dev@jitsi.org');>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org