[jitsi-dev] dev Digest, Vol 14, Issue 76


#1

Send dev mailing list submissions to
        dev@jitsi.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.jitsi.org/mailman/listinfo/dev
or, via email, send a message with subject or body 'help' to
        dev-request@jitsi.org

You can reach the person managing the list at
        dev-owner@jitsi.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dev digest..."

Today's Topics:

   1. Re: [ice4j] Message.addAttribute function replaces previous
      instance of attribute (Pawe? Domas)
   2. Re: MCU performances/scalability and beyond (Emil Ivov)
   3. Re: MCU performances/scalability and beyond (Regnoult Francois)
   4. Re: MCU performances/scalability and beyond (Philipp Hancke)
   5. Re: MCU performances/scalability and beyond (Emil Ivov)

----------------------------------------------------------------------

Message: 1
Date: Wed, 28 May 2014 08:43:16 +0200
From: Pawe? Domas <pawel.domas@jitsi.org>
To: Jitsi Developers <dev@jitsi.org>
Subject: Re: [jitsi-dev] [ice4j] Message.addAttribute function
        replaces previous instance of attribute
Message-ID:
        <
CAME7wR66KKK_smO5SaZBdayd40q__c6dQeEEcv8ndKYqmUqysA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi Aakash,

> Hi Aakash,
>
>> attributeSetLogic.patch :
>>
>> added logic for multiple occurrence of attributes of a given type
>> add various additional functions for multiple occurrence of patches
like:
>>
>> removeAttributeFromSet(Attribute attribute)
>> getAttributeSet(char attributeType)
>> and more.
>
> I don't like the idea of having two collections of attributes and
> trying to keep them in sync. Is it possible to use only
> "attributesSetMap" ?

I tried this at first place with attributesSetMap only but in that case

when we've to write stun messages where only one instance of each attribute
has to be encoded then we can return the first instance of the
LinkedHashSet
but what if we have to select other than the first one.
In that case we have to mark the instance for each attributeType this was
done by using the current attributes variable to store mapping of the
Attribute object for each type.
This way it also maintained the legacy of the code and adding new
flexibility.

Please provide suggestions if any. :slight_smile:

Also getDataLength does not take into an account multiple attributes

of the same type.

I missed it here is the code for it also added the code for the another

missing getDataLengthWithoutPadding():

    /**
     * Returns the length of this message's body where only one instance of
each
     * Attribute-type is used.

···

On Wed, May 28, 2014 at 1:28 PM, <dev-request@jitsi.org> wrote:

On Tue, May 27, 2014 at 10:13 PM, Pawe? Domas <pawel.domas@jitsi.org> > wrote:
> On Sat, May 10, 2014 at 12:49 PM, Aakash Garg <aakashgargnsit@gmail.com> > wrote:

     *
     * @return the length of the data in this message.
     */
    public char getDataLength()
    {
        char length = 0;

        List<Attribute> attrs = getAttributes();
        for (Attribute att : attrs)
        {
            int attLen = att.getDataLength() + Attribute.HEADER_LENGTH;

            //take attribute padding into account:
            attLen += (4 - (attLen % 4)) % 4;

            length += attLen;
        }
        return length;
    }

    /**
     * Returns the length of this message's body where all instances of each
     * Attribute-type are used.
     *
     * @return the full length of the data in this message.
     */
    public char getFullDataLength()
    {
        char length = 0;

        for (LinkedHashSet<Attribute> attList :
this.attributesSetMap.values())
        {
            for (Attribute att : attList)
            {
                int attLen = att.getDataLength() + Attribute.HEADER_LENGTH;

                // take attribute padding into account:
                attLen += (4 - (attLen % 4)) % 4;

                length += attLen;
            }
        }
        return length;
    }

    /**
     * Returns the length of this message's body without padding where only
one
     * instance of each attribute type is considered.
     * Some STUN/ICE dialect does not take into account padding (GTalk).
     *
     * @return the length of the data in this message.
     */
    public char getDataLengthWithoutPadding()
    {
        char length = 0;

        List<Attribute> attrs = getAttributes();

        for (Attribute att : attrs)
        {
            int attLen = att.getDataLength() + Attribute.HEADER_LENGTH;
            length += attLen;
        }
        return length;
    }

    /**
     * Returns the full length of this message's body without padding where
each
     * instance of attribute type is considered.
     * Some STUN/ICE dialect does not take into account padding (GTalk).
     *
     * @return the length of the data in this message.
     */
    public char getFullDataLengthWithoutPadding()
    {
        char length = 0;

        for (LinkedHashSet<Attribute> attList :
this.attributesSetMap.values())
        {
            for (Attribute att : attList)
            {
                int attLen = att.getDataLength() + Attribute.HEADER_LENGTH;
                length += attLen;
            }
        }
        return length;
    }

Regards,
Aakash Garg

Regards,
Pawel

------------------------------

Message: 2
Date: Wed, 28 May 2014 09:07:25 +0200
From: Emil Ivov <emcho@jitsi.org>
To: Jitsi Developers <dev@jitsi.org>
Subject: Re: [jitsi-dev] MCU performances/scalability and beyond
Message-ID: <53858B2D.3000307@jitsi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hey Francois,

On 28.05.14, 04:14, Regnoult Francois wrote:
> Hi all,
>
> I would really appreciate a dev point of view about these questions.
>
> Thanks
>
> On 19/05/2014 11:38, Regnoult Francois wrote:
>> Hi,
>> Now I have been interested to test some parameters using the MCU:

So it's probably worth mentioning from the start that Jitsi Videobridge
is NOT an MCU. It is an SFU (Selective Forwarding Unit). This is *very*
important because it makes for all the difference in terms of scalability.

>> - CPU performances on the client side. Should I expect a gain using
>> the MCU?

A gain compared to what?

Compared to full mesh WebRTC conferences: Yes. In those scenarios the
browser would typically create one encoding per receiver and this would
be quite heavy on the CPU. Given the full mesh architecture though,
you'd probably hit an upstream bandwidth limitation much earlier than a
CPU one.

Compared to a regular MCU that mixes everything and sends it back to you
as a single stream: No. But the small added client-side CPU efficiency
of the MCU (compared to the SFU) comes at the expense of added latency,
lower quality, *significantly* higher server-side cost, and degraded UX
(not possible to switch to a specific participant).

>> - CPU/Memory performances on the server side. What is for you the
>> maximum number of client the server can handle at the same time? Under
>> what scenario?

It is very hard to say. It depends on bandwidth, topology (how many send
and how many receive), stream quality, server configuration and many
more. But, in order to give you a perspective we recently had the
following data point from a user:

In a scenario with one sender and 180 receivers (i.e. the bridge
decrypts one stream and then re-encrypts it 180 times) it uses
400 MBits of bandwidth on the server and on an i7 quad core the bridge
was taking 30% CPU.

>> - Scalability of the MCU. If you would have to handle 1 000 000 of
>> users I believe you would distribute the load on more than one MCU.
>> Although on the documentation I don't see this scenario being
>> considered. What would be your approach in this case?

I assume these people are not all in the same conference (which would be
a scenario we haven't much thought about right now) but if you simply
mean 1 000 000 users in different conferences then that kind of
scalability would depend on the business logic fronting Jitsi
Videobridge. You can easily run a fleet of a thousand JVB instances and
simply have to make sure that you take load into account before choosing
one to create your next conference on.

>> - What is your evaluation of the stability of the MCU currently?

Jitsi Videobridge: *Very* stable.
Jitsi Meet: rather stable with some quirks now and then (but nothing
that wouldn't go away after a page reload).

Hope this answers your questions.

Cheers,
Emil

>> Best regards,
>> --
>> Francois From Temasys
>
> --
> Francois From Temasys
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>

--
https://jitsi.org

------------------------------

Message: 3
Date: Wed, 28 May 2014 15:39:12 +0800
From: Regnoult Francois <regnoult@temasys.com.sg>
To: Jitsi Developers <dev@jitsi.org>
Subject: Re: [jitsi-dev] MCU performances/scalability and beyond
Message-ID: <538592A0.5000806@temasys.com.sg>
Content-Type: text/plain; charset=UTF-8; format=flowed

Thanks for the answers.

As I'm not an XMPP expert, when you say that it is possible to run
thousands VideoBridge instances, they would have to be referenced by
the XMPP server, isn't it? On prosody server (or other XMPP server) is
it possible to add XMPP components on the fly? Who would be the one
choosing which JVB to choose? Jitsi Meet (or other web server/
signalling application)?

If I want to start to tweak Jitsi Meet, what are the main files/class
that I should focus on? Like where is the connection with the XMPP
server/JVB is done? How can I decide how the JVB is going to be used
(webinar scenario or conference scenario)?

Best regards,
Francois

On Wed 28 May 2014 03:07:25 PM, Emil Ivov wrote:
> Hey Francois,
>
> On 28.05.14, 04:14, Regnoult Francois wrote:
>> Hi all,
>>
>> I would really appreciate a dev point of view about these questions.
>>
>> Thanks
>>
>> On 19/05/2014 11:38, Regnoult Francois wrote:
>>> Hi,
>>> Now I have been interested to test some parameters using the MCU:
>
> So it's probably worth mentioning from the start that Jitsi
> Videobridge is NOT an MCU. It is an SFU (Selective Forwarding Unit).
> This is *very* important because it makes for all the difference in
> terms of scalability.
>
>>> - CPU performances on the client side. Should I expect a gain using
>>> the MCU?
>
> A gain compared to what?
>
> Compared to full mesh WebRTC conferences: Yes. In those scenarios the
> browser would typically create one encoding per receiver and this
> would be quite heavy on the CPU. Given the full mesh architecture
> though, you'd probably hit an upstream bandwidth limitation much
> earlier than a CPU one.
>
> Compared to a regular MCU that mixes everything and sends it back to
> you as a single stream: No. But the small added client-side CPU
> efficiency of the MCU (compared to the SFU) comes at the expense of
> added latency, lower quality, *significantly* higher server-side cost,
> and degraded UX (not possible to switch to a specific participant).
>
>>> - CPU/Memory performances on the server side. What is for you the
>>> maximum number of client the server can handle at the same time? Under
>>> what scenario?
>
> It is very hard to say. It depends on bandwidth, topology (how many
> send and how many receive), stream quality, server configuration and
> many more. But, in order to give you a perspective we recently had the
> following data point from a user:
>
> In a scenario with one sender and 180 receivers (i.e. the bridge
> decrypts one stream and then re-encrypts it 180 times) it uses
> 400 MBits of bandwidth on the server and on an i7 quad core the bridge
> was taking 30% CPU.
>
>>> - Scalability of the MCU. If you would have to handle 1 000 000 of
>>> users I believe you would distribute the load on more than one MCU.
>>> Although on the documentation I don't see this scenario being
>>> considered. What would be your approach in this case?
>
> I assume these people are not all in the same conference (which would
> be a scenario we haven't much thought about right now) but if you
> simply mean 1 000 000 users in different conferences then that kind of
> scalability would depend on the business logic fronting Jitsi
> Videobridge. You can easily run a fleet of a thousand JVB instances
> and simply have to make sure that you take load into account before
> choosing one to create your next conference on.
>
>>> - What is your evaluation of the stability of the MCU currently?
>
> Jitsi Videobridge: *Very* stable.
> Jitsi Meet: rather stable with some quirks now and then (but nothing
> that wouldn't go away after a page reload).
>
> Hope this answers your questions.
>
> Cheers,
> Emil
>
>
>>> Best regards,
>>> --
>>> Francois From Temasys
>>
>> --
>> Francois From Temasys
>>
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>>
>

--
Francois From Temasys

------------------------------

Message: 4
Date: Wed, 28 May 2014 09:50:13 +0200
From: Philipp Hancke <fippo@goodadvice.pages.de>
To: dev@jitsi.org
Subject: Re: [jitsi-dev] MCU performances/scalability and beyond
Message-ID: <53859535.50909@goodadvice.pages.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Am 28.05.2014 09:39, schrieb Regnoult Francois:
> Thanks for the answers.
>
> As I'm not an XMPP expert, when you say that it is possible to run
> thousands VideoBridge instances, they would have to be referenced by the
> XMPP server, isn't it?

yeah. Better have an XMPP server that scales to the number of stanzas
then. Or run multiple xmpp servers.

> On prosody server (or other XMPP server) is it
> possible to add XMPP components on the fly?

I think that can be done with the telnet admin console. Possibly
changing the config and triggering a reload is sufficient.

Note that once you have configured components, you can dynamically
connect them.

> Who would be the one
> choosing which JVB to choose? Jitsi Meet (or other web server/
> signalling application)?

Currently it's hardcoded.
https://github.com/jitsi/jitsi-meet/blob/master/config.js#L5
You'd need to use your own logic to pass a certain bridge jid to the
focus constructor.

> If I want to start to tweak Jitsi Meet, what are the main files/class
> that I should focus on?

app.js

> Like where is the connection with the XMPP
> server

https://github.com/jitsi/jitsi-meet/blob/master/app.js#L53

> /JVB is done?

https://github.com/jitsi/jitsi-meet/blob/master/app.js#L631 (mostly) --
currently happens when you join a MUC.

Note that I don't think a clientside focus is such a good idea (even
though it works pretty well) if you want real scalability.

> How can I decide how the JVB is going to be used
> (webinar scenario or conference scenario)?

I wish I had more time to work on
https://github.com/jitsi/jitsi-meet/issues/6 :-/

------------------------------

Message: 5
Date: Wed, 28 May 2014 09:56:19 +0200
From: Emil Ivov <emcho@jitsi.org>
To: Jitsi Developers <dev@jitsi.org>
Subject: Re: [jitsi-dev] MCU performances/scalability and beyond
Message-ID: <538596A3.2070302@jitsi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hey Francois,

On 28.05.14, 09:39, Regnoult Francois wrote:
> Thanks for the answers.
>
> As I'm not an XMPP expert, when you say that it is possible to run
> thousands VideoBridge instances, they would have to be referenced by the
> XMPP server, isn't it?

That would be one way of doing it (for the record that specific way
wouldn't work right now because we always use the same jitsi-videobridge
subdomain, but this should be improved today or tomorrow) . They could
also run on separate XMPP servers. It depends on how you want to build
your architecture.

> On prosody server (or other XMPP server) is it
> possible to add XMPP components on the fly?

I think it takes a "reload" but I don't believe it's necessary to
restart it.

> Who would be the one choosing which JVB to choose?

The focus agent. The one that creates the conferences. In Jitsi Meet
this is the first person to join a conference but that's very
application specific. We expect that in most cases the focus would be a
server-side entity.

> Jitsi Meet (or other web server/
> signalling application)?

Jitsi Meet is just one application and only one way of using the bridge.
You are by no means constrained on using it the same way. As mentioned
Jitsi Meet has made the choice to add the focus features (the conference
session control) in the client. We will probably change this in the near
future though and have that run on the server. No changes would be
required in the bridge for this to happen.

> If I want to start to tweak Jitsi Meet, what are the main files/class
> that I should focus on?

Well that depends on what you want to do. Fortunately there aren't many
files right now so it's easy to find stuff.

> Like where is the connection with the XMPP
> server/JVB is done?

These are to separate things. The connection to the XMPP server is
handled by Strophe. The connection to JVB: by colibry.

> How can I decide how the JVB is going to be used
> (webinar scenario or conference scenario)?

I am not sure I understand the question. You decide whether you are
doing a webinar or a conference in the application that is using the
bridge. There's not much difference in how you are using the bridge though.

Emil

> Best regards,
> Francois
>
> On Wed 28 May 2014 03:07:25 PM, Emil Ivov wrote:
>> Hey Francois,
>>
>> On 28.05.14, 04:14, Regnoult Francois wrote:
>>> Hi all,
>>>
>>> I would really appreciate a dev point of view about these questions.
>>>
>>> Thanks
>>>
>>> On 19/05/2014 11:38, Regnoult Francois wrote:
>>>> Hi,
>>>> Now I have been interested to test some parameters using the MCU:
>>
>> So it's probably worth mentioning from the start that Jitsi
>> Videobridge is NOT an MCU. It is an SFU (Selective Forwarding Unit).
>> This is *very* important because it makes for all the difference in
>> terms of scalability.
>>
>>>> - CPU performances on the client side. Should I expect a gain using
>>>> the MCU?
>>
>> A gain compared to what?
>>
>> Compared to full mesh WebRTC conferences: Yes. In those scenarios the
>> browser would typically create one encoding per receiver and this
>> would be quite heavy on the CPU. Given the full mesh architecture
>> though, you'd probably hit an upstream bandwidth limitation much
>> earlier than a CPU one.
>>
>> Compared to a regular MCU that mixes everything and sends it back to
>> you as a single stream: No. But the small added client-side CPU
>> efficiency of the MCU (compared to the SFU) comes at the expense of
>> added latency, lower quality, *significantly* higher server-side cost,
>> and degraded UX (not possible to switch to a specific participant).
>>
>>>> - CPU/Memory performances on the server side. What is for you the
>>>> maximum number of client the server can handle at the same time? Under
>>>> what scenario?
>>
>> It is very hard to say. It depends on bandwidth, topology (how many
>> send and how many receive), stream quality, server configuration and
>> many more. But, in order to give you a perspective we recently had the
>> following data point from a user:
>>
>> In a scenario with one sender and 180 receivers (i.e. the bridge
>> decrypts one stream and then re-encrypts it 180 times) it uses
>> 400 MBits of bandwidth on the server and on an i7 quad core the bridge
>> was taking 30% CPU.
>>
>>>> - Scalability of the MCU. If you would have to handle 1 000 000 of
>>>> users I believe you would distribute the load on more than one MCU.
>>>> Although on the documentation I don't see this scenario being
>>>> considered. What would be your approach in this case?
>>
>> I assume these people are not all in the same conference (which would
>> be a scenario we haven't much thought about right now) but if you
>> simply mean 1 000 000 users in different conferences then that kind of
>> scalability would depend on the business logic fronting Jitsi
>> Videobridge. You can easily run a fleet of a thousand JVB instances
>> and simply have to make sure that you take load into account before
>> choosing one to create your next conference on.
>>
>>>> - What is your evaluation of the stability of the MCU currently?
>>
>> Jitsi Videobridge: *Very* stable.
>> Jitsi Meet: rather stable with some quirks now and then (but nothing
>> that wouldn't go away after a page reload).
>>
>> Hope this answers your questions.
>>
>> Cheers,
>> Emil
>>
>>
>>>> Best regards,
>>>> --
>>>> Francois From Temasys
>>>
>>> --
>>> Francois From Temasys
>>>
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>
>>
>
> --
> Francois From Temasys
>
> _______________________________________________
> 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
http://lists.jitsi.org/mailman/listinfo/dev

End of dev Digest, Vol 14, Issue 76
***********************************

--
*Aakash Garg*
*Netaji Subhas Institute of Technology (NSIT), Dwarka,*
*New Delhi*


#2

Send dev mailing list submissions to
        dev@jitsi.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.jitsi.org/mailman/listinfo/dev
or, via email, send a message with subject or body 'help' to
        dev-request@jitsi.org

You can reach the person managing the list at
        dev-owner@jitsi.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dev digest..."

Today's Topics:

   1. Re: [ice4j] Message.addAttribute function replaces previous
      instance of attribute (Pawe? Domas)
   2. Re: MCU performances/scalability and beyond (Emil Ivov)
   3. Re: MCU performances/scalability and beyond (Regnoult Francois)
   4. Re: MCU performances/scalability and beyond (Philipp Hancke)
   5. Re: MCU performances/scalability and beyond (Emil Ivov)

----------------------------------------------------------------------

Message: 1
Date: Wed, 28 May 2014 08:43:16 +0200
From: Pawe? Domas <pawel.domas@jitsi.org>
To: Jitsi Developers <dev@jitsi.org>
Subject: Re: [jitsi-dev] [ice4j] Message.addAttribute function
        replaces previous instance of attribute
Message-ID:

<CAME7wR66KKK_smO5SaZBdayd40q__c6dQeEEcv8ndKYqmUqysA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi Aakash,

> Hi Aakash,
>
>> attributeSetLogic.patch :
>>
>> added logic for multiple occurrence of attributes of a given type
>> add various additional functions for multiple occurrence of patches
>> like:
>>
>> removeAttributeFromSet(Attribute attribute)
>> getAttributeSet(char attributeType)
>> and more.
>
> I don't like the idea of having two collections of attributes and
> trying to keep them in sync. Is it possible to use only
> "attributesSetMap" ?

I tried this at first place with attributesSetMap only but in that case when
we've to write stun messages where only one instance of each attribute has
to be encoded then we can return the first instance of the LinkedHashSet
but what if we have to select other than the first one.

When do we need to select other than the first one ? In this case I
guess we need to get whole list of attributes of given type, right ?

In that case we have to mark the instance for each attributeType this was
done by using the current attributes variable to store mapping of the
Attribute object for each type.
This way it also maintained the legacy of the code and adding new
flexibility.

Please provide suggestions if any. :slight_smile:

So we use single attribute per type in STUN messages and in some TURN
cases we need multiple attributes per type, right ?
In this case we can make new class that will be capable of doing the
latter and we'll be creating it for multiple attribute per type cases.
Does it make sense ?

Regards,
Pawel

···

On Thu, May 29, 2014 at 9:19 AM, Aakash Garg <aakashgargnsit@gmail.com> wrote:

On Wed, May 28, 2014 at 1:28 PM, <dev-request@jitsi.org> wrote:

On Tue, May 27, 2014 at 10:13 PM, Pawe? Domas <pawel.domas@jitsi.org> >> wrote:
> On Sat, May 10, 2014 at 12:49 PM, Aakash Garg <aakashgargnsit@gmail.com> >> > wrote: