[jitsi-dev] Jisti video bridge

Archive
#1

Hi people,

I already have a webRTC application in place. My app works nicely, with
stun, turn, signaling, and it is basically a video chat.

But I'm concerned how it will behave after connecting 30 users
simultaneously. Searching in forums, people recommended jitsi.

I am not experienced with mcu, mixers and etc. Is the jitsi video bridge,
what can help me to "broadcast" the video?

And to integrate it with my webRTC code, what I need to do? Just add some
information to the peerConnection?

Sorry about the naive questions and thanks in advance.

Renan

#2

Hello,

Hi people,

I already have a webRTC application in place. My app works nicely, with
stun, turn, signaling, and it is basically a video chat.

But I'm concerned how it will behave after connecting 30 users
simultaneously. Searching in forums, people recommended jitsi.

I am not experienced with mcu, mixers and etc. Is the jitsi video
bridge, what can help me to "broadcast" the video?

Yes. In the usual scenario, WebRTC clients connect to jitsi-videobridge (in a star topology, with the bridge in the center), which forwards packets between the endpoints. In effect it broadcasts whatever the endpoints send.

And to integrate it with my webRTC code, what I need to do? Just add
some information to the peerConnection?

It wouldn't be quite as simple, and it depends very much on the signalling which you use. There are two main parts:
1. Allocating resources on the videobridge.
The bridge maintains a "conference", which holds multiple "channels". A "channel" is either audio or video and represents a connection to an endpoint.
Allocation of a "conference" and "channels" can be done either through the COLIBRI protocol over XMPP[1] or through the videobridge REST API[2].

2. Tweaking the signalling in your application, so that endpoints connect to the bridge. This basically involves replacing the ICE candidates in an SDP offer or answer with jitsi-videobridge candidates (obtained via COLIBRI/REST).

I hope that helps a bit. Let us know if you have any questions.

Regards,
Boris

[1] http://xmpp.org/extensions/xep-0340.html
[2] https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest-videobridge.md

···

On 13/01/15 01:45, Renan Reis wrote:

#3

Thank you so much Boris.

So, let me confirm some steps. Since I have the video bridge in place and
using REST, I need to send a POST to create a conference.

Given a conference I need to change the SDPs to point that to the video
bridge's conference. In my case, the signalling is not xmpp is node.js, so
I should to the changes there.

What about the changes in the SDP, there is a documentation to learn what
need to be made?

Thanks in advance.

Renan

···

2015-01-13 11:47 GMT-02:00 Boris Grozev <boris@jitsi.org>:

Hello,

On 13/01/15 01:45, Renan Reis wrote:

Hi people,

I already have a webRTC application in place. My app works nicely, with
stun, turn, signaling, and it is basically a video chat.

But I'm concerned how it will behave after connecting 30 users
simultaneously. Searching in forums, people recommended jitsi.

I am not experienced with mcu, mixers and etc. Is the jitsi video
bridge, what can help me to "broadcast" the video?

Yes. In the usual scenario, WebRTC clients connect to jitsi-videobridge
(in a star topology, with the bridge in the center), which forwards packets
between the endpoints. In effect it broadcasts whatever the endpoints send.

And to integrate it with my webRTC code, what I need to do? Just add
some information to the peerConnection?

It wouldn't be quite as simple, and it depends very much on the signalling
which you use. There are two main parts:
1. Allocating resources on the videobridge.
The bridge maintains a "conference", which holds multiple "channels". A
"channel" is either audio or video and represents a connection to an
endpoint.
Allocation of a "conference" and "channels" can be done either through the
COLIBRI protocol over XMPP[1] or through the videobridge REST API[2].

2. Tweaking the signalling in your application, so that endpoints connect
to the bridge. This basically involves replacing the ICE candidates in an
SDP offer or answer with jitsi-videobridge candidates (obtained via
COLIBRI/REST).

I hope that helps a bit. Let us know if you have any questions.

Regards,
Boris

[1] http://xmpp.org/extensions/xep-0340.html
[2] https://github.com/jitsi/jitsi-videobridge/blob/master/
doc/rest-videobridge.md

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

#4

Hello,

Thank you so much Boris.

So, let me confirm some steps. Since I have the video bridge in place
and using REST, I need to send a POST to create a conference.

That's right. And you can later PATCH it in order to get add more participants, for example.

Given a conference I need to change the SDPs to point that to the video
bridge's conference. In my case, the signalling is not xmpp is node.js,
so I should to the changes there.

What about the changes in the SDP, there is a documentation to learn
what need to be made?

Unless I am forgetting something, you only need the ICE candidates and the DTLS information. In the XMPP version of COLIBRI, these are represented according to [1] and [2].
With the REST interface, these XML elements are further translated to JSON.

So in order to understand how to translate the JSON to SDP, you'd need to go through XML first. Fortunately, these are all simple structures.

Regards,
Boris

[1] http://xmpp.org/extensions/xep-0176.html
[2] http://xmpp.org/extensions/xep-0320.html

···

On 13/01/15 20:57, Renan Reis wrote:

#5

Boris,

sorry for asking so many questions. But I'm new with this piece of the
architecture of webRTC and I could not get the pieces together yet.

I need to do a post to the video bridge, something like this:

{
    "contents" :
    [
        {
             "name" : "audio",
             "channels" : [ { "expire" : 60 } ]
        },
        {
            "name" : "video",
            "channels" : [ { "expire" : 60 } ]
        }
    ]
}

then I will get an conference ID. After that, what should I do? Intercept
the SDP in the signalling server? And based on that, what I need to change?

If you think it is valuable, after understanding how it works I could write
a tutorial about this.

Thank you so much.

Renan

···

2015-01-13 18:13 GMT-02:00 Boris Grozev <boris@jitsi.org>:

Hello,

On 13/01/15 20:57, Renan Reis wrote:

Thank you so much Boris.

So, let me confirm some steps. Since I have the video bridge in place
and using REST, I need to send a POST to create a conference.

That's right. And you can later PATCH it in order to get add more
participants, for example.

Given a conference I need to change the SDPs to point that to the video
bridge's conference. In my case, the signalling is not xmpp is node.js,
so I should to the changes there.

What about the changes in the SDP, there is a documentation to learn
what need to be made?

Unless I am forgetting something, you only need the ICE candidates and the
DTLS information. In the XMPP version of COLIBRI, these are represented
according to [1] and [2].
With the REST interface, these XML elements are further translated to JSON.

So in order to understand how to translate the JSON to SDP, you'd need to
go through XML first. Fortunately, these are all simple structures.

Regards,
Boris

[1] http://xmpp.org/extensions/xep-0176.html
[2] http://xmpp.org/extensions/xep-0320.html

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

#6

Boris,

sorry for asking so many questions. But I'm new with this piece of the
architecture of webRTC and I could not get the pieces together

I need to do a post to the video bridge, something like this:

{
     "contents" :
     [
         {
              "name" : "audio",
              "channels" : [ { "expire" : 60 } ]
         },
         {
             "name" : "video",
             "channels" : [ { "expire" : 60 } ]
         }
     ]
}

then I will get an conference ID. After that, what should I do?
Intercept the SDP in the signalling server? And based on that, what I
need to change?

The following assumes that the signalling server will be generating the offer. If that's not the case, the procedure will need to be different. Also, it is not the only way to go, but just an example (based on Jitsi Meet and jicofo).

1. The signalling server allocates a conference on the bridge. What you have above. Apart from the conference ID, the bridge will include a "transport" for each channel, which will have ICE candidates and a DTLS fingerprint.

2. The signalling server creates an SDP offer, and substitutes the ICE candidates and DTLS fingerprint with the ones obtained in step 1. It then sends the offer to the client.

3. The signalling server receives the client's answer. It takes the transport information, and the payload-type description, converts them to the COLIBRI/JSON format and sends it to the videobridge with a PATCH request.

Now the client and videobridge have each other's ICE candidates and will start ICE.

If you think it is valuable, after understanding how it works I could
write a tutorial about this.

Sure, I think that more documentation would be welcome. Thanks!

Regards,
Boris

···

On 15/01/15 15:45, Renan Reis wrote:

#7

I think I'm starting to understand and almost getting the solution.

But I still with some doubts, for example:

1. The signalling server allocates a conference on the bridge.

Just doing a post for the bridge.

What you have above. Apart from the conference ID, the bridge will include
a "transport" for each channel, which will have ICE candidates and a DTLS
fingerprint.

How the bridge will get the information about ice and dtls?

2. The signalling server creates an SDP offer, and substitutes the ICE
candidates and DTLS fingerprint with the ones obtained in step 1. It then
sends the offer to the client.

The signalling server creates an SDP offer? It should not be created by a
peerConnection and sent to the Signalling server?

3. The signalling server receives the client's answer. It takes the
transport information, and the payload-type description, converts them to
the COLIBRI/JSON format and sends it to the videobridge with a PATCH
request.

This part seems to be ok :smiley:

You know a lot about this, are you a jitsi contributor?

Regards,

Renan

···

2015-01-15 14:13 GMT-02:00 Boris Grozev <boris@jitsi.org>:

On 15/01/15 15:45, Renan Reis wrote:

Boris,

sorry for asking so many questions. But I'm new with this piece of the
architecture of webRTC and I could not get the pieces together

I need to do a post to the video bridge, something like this:

{
     "contents" :
     [
         {
              "name" : "audio",
              "channels" : [ { "expire" : 60 } ]
         },
         {
             "name" : "video",
             "channels" : [ { "expire" : 60 } ]
         }
     ]
}

then I will get an conference ID. After that, what should I do?
Intercept the SDP in the signalling server? And based on that, what I
need to change?

The following assumes that the signalling server will be generating the
offer. If that's not the case, the procedure will need to be different.
Also, it is not the only way to go, but just an example (based on Jitsi
Meet and jicofo).

1. The signalling server allocates a conference on the bridge.

What you have above. Apart from the conference ID, the bridge will include
a "transport" for each channel, which will have ICE candidates and a DTLS
fingerprint.

2. The signalling server creates an SDP offer, and substitutes the ICE
candidates and DTLS fingerprint with the ones obtained in step 1. It then
sends the offer to the client.

3. The signalling server receives the client's answer. It takes the
transport information, and the payload-type description, converts them to
the COLIBRI/JSON format and sends it to the videobridge with a PATCH
request.

Now the client and videobridge have each other's ICE candidates and will
start ICE.

If you think it is valuable, after understanding how it works I could
write a tutorial about this.

Sure, I think that more documentation would be welcome. Thanks!

Regards,
Boris

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

#8

Hello,

I think I'm starting to understand and almost getting the solution.

But I still with some doubts, for example:

    1. The signalling server allocates a conference on the bridge.

Just doing a post for the bridge.

    What you have above. Apart from the conference ID, the bridge will
    include a "transport" for each channel, which will have ICE
    candidates and a DTLS fingerprint.

How the bridge will get the information about ice and dtls?

When it allocates a channel, it will include in its own ICE candidates and DTLS fingerprint.

The clients' candidates and fingerptint(s) have to be included by the focus agent (e.g. "signalling server"), inside the "channel" elements of COLIBRI requests. (Note that the ICE candidates aren't strictly necessary.)

    2. The signalling server creates an SDP offer, and substitutes the
    ICE candidates and DTLS fingerprint with the ones obtained in step
    1. It then sends the offer to the client.

The signalling server creates an SDP offer? It should not be created by
a peerConnection and sent to the Signalling server?

That depends on your architecture. If the clients make the offer, then the signalling server will allocate COLIBRI resources after it received an offer, and will then substitute the bridge's candidates in the answer to the client.

    3. The signalling server receives the client's answer. It takes the
    transport information, and the payload-type description, converts
    them to the COLIBRI/JSON format and sends it to the videobridge with
    a PATCH request.

This part seems to be ok :smiley:

You know a lot about this, are you a jitsi contributor?

Yes, I work on the project.

Regards,
Boris

···

On 18/01/15 19:12, Renan Reis wrote: