[jitsi-dev] REST and Channel Bundle IDs


#1

I think i have some idea as to what I am doing wrong with the REST JSON objects.

In the first patch message at

https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest-videobridge.md

for each of the channels it specifies a channel bundle Id which is the same:

    "endpoint":"9f537ebb-1c2a-4ee9-9940-373304f9b260",
           "channel-bundle-id":"9f537ebb-1c2a-4ee9-9940-373304f9b260",

I have also done this which then bundles up the video, audio and data connection into the same bundle.

It may be that they should be different. What I have done is to pick one of the IDs of the candidates in the connection. That probably is also wrong.

I would guess that I should instead create a new ID and have separate IDs for each of the channels.

Is this right or is there something else?

This could cause the confusion between bundling channels, however.


#2

Hey John, if I'm understanding your question correctly:
If the channels are bundled, they should all share the same bundle id.
Since frequently (and in the example) all channels for an endpoint are
bundled, one easy thing to do is to just use the endpoint-id as the
bundle-id for all of the channels. You could also create some other,
arbitrary string for the bundle-id for all of the channels.

-brian

···

On Fri, Jan 13, 2017 at 5:41 AM, John Hemming <john@hemming.email> wrote:

I think i have some idea as to what I am doing wrong with the REST JSON
objects.

In the first patch message at

https://github.com/jitsi/jitsi-videobridge/blob/master/
doc/rest-videobridge.md

for each of the channels it specifies a channel bundle Id which is the
same:

   "endpoint": "9f537ebb-1c2a-4ee9-9940-373304f9b260",
          "channel-bundle-id": "9f537ebb-1c2a-4ee9-9940-373304f9b260",

I have also done this which then bundles up the video, audio and data
connection into the same bundle.

It may be that they should be different. What I have done is to pick one
of the IDs of the candidates in the connection. That probably is also
wrong.

I would guess that I should instead create a new ID and have separate IDs
for each of the channels.

Is this right or is there something else?

This could cause the confusion between bundling channels, however.

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


#3

As it stands I am simply trying to get the videobridge to work between Chrome and the Videobridge using the REST interface. I don't mind how this is done. I have experimented with various approaches.

I think I probably have a problem with the SDP. When I produce a working SDP using some other software not related to Jitsi that works I get session values for the ice candidates and fingerprint.

However, I got an SDP from OfMeet (which I believe was using jitsi in the plugin) and that had ice candidates against each media line.

I have used SIP and SDP in various guises, but have not written anything from scratch so far and it is entirely possible that I have messed up on something other than the json sent to jitsi.

Boris made the point that jitsi was bundling the audio/video and data channels, but not reliably. I have, therefore, today been trying to make things work by having the three channels each defined separately with separate channel bundles.

When I get an answer SDP from Chrome it does not have any candidates so I am not sending remote candidates to Jitsi. I am not sure that this is right either. The reference json on the jitsi rest web page makes reference to an empty array of candidates. Whether that is right or not I don't know.

Obviously it would be possible to me to implement the same things in XMPP, but I would rather stick to REST.

The difficulty, of course, is tracking down where it is all going wrong as there are so many different variables.

···

On 13/01/2017 16:06, Brian Baldino wrote:

Hey John, if I'm understanding your question correctly:
If the channels are bundled, they should all share the same bundle id. Since frequently (and in the example) all channels for an endpoint are bundled, one easy thing to do is to just use the endpoint-id as the bundle-id for all of the channels. You could also create some other, arbitrary string for the bundle-id for all of the channels.

-brian

On Fri, Jan 13, 2017 at 5:41 AM, John Hemming <john@hemming.email > <mailto:john@hemming.email>> wrote:

    I think i have some idea as to what I am doing wrong with the REST
    JSON objects.

    In the first patch message at

    https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest-videobridge.md
    <https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest-videobridge.md>

    for each of the channels it specifies a channel bundle Id which is
    the same:

        "endpoint":"9f537ebb-1c2a-4ee9-9940-373304f9b260",
               "channel-bundle-id":"9f537ebb-1c2a-4ee9-9940-373304f9b260",

    I have also done this which then bundles up the video, audio and
    data connection into the same bundle.

    It may be that they should be different. What I have done is to
    pick one of the IDs of the candidates in the connection. That
    probably is also wrong.

    I would guess that I should instead create a new ID and have
    separate IDs for each of the channels.

    Is this right or is there something else?

    This could cause the confusion between bundling channels, however.

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

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


#4

Hey John,
I sync'd up with Boris...there's no reliability issue with the bundling on
the bridge, so you're fine to use that (and I think you may have an easier
time, as most clients are going towards bundling now).

The REST examples don't include any ice information for a couple reasons:
1) Typically people do 'trickle ice', so the candidates are gathered
continuously and you don't need to wait for the gathering process to finish
before sending the answer, so the answer message wouldn't have the ice
information but subsequent messages would (unfortunately I'm not much help
with those subsequent messages as I haven't done it...you'll see why in #2
below)
2) If the bridge is not behind a firewall/NAT, sending candidates from the
client to the bridge is not even necessary, as long as the client has
candidates from the bridge. The client will start making ice connection
attempts to the bridge and the bridge will detect the address from which
those checks came and start checks using that address in the other
direction. (Note, that this is not always the case, but frequently when a
bridge is deployed it's deployed in such a way to be accessible by design,
so it can be done this way. This was the scenario I had when writing the
REST flow example).

-brian

···

On Fri, Jan 13, 2017 at 11:42 AM, John Hemming <john@hemming.email> wrote:

As it stands I am simply trying to get the videobridge to work between
Chrome and the Videobridge using the REST interface. I don't mind how this
is done. I have experimented with various approaches.

I think I probably have a problem with the SDP. When I produce a working
SDP using some other software not related to Jitsi that works I get session
values for the ice candidates and fingerprint.

However, I got an SDP from OfMeet (which I believe was using jitsi in the
plugin) and that had ice candidates against each media line.

I have used SIP and SDP in various guises, but have not written anything
from scratch so far and it is entirely possible that I have messed up on
something other than the json sent to jitsi.

Boris made the point that jitsi was bundling the audio/video and data
channels, but not reliably. I have, therefore, today been trying to make
things work by having the three channels each defined separately with
separate channel bundles.

When I get an answer SDP from Chrome it does not have any candidates so I
am not sending remote candidates to Jitsi. I am not sure that this is
right either. The reference json on the jitsi rest web page makes
reference to an empty array of candidates. Whether that is right or not I
don't know.

Obviously it would be possible to me to implement the same things in XMPP,
but I would rather stick to REST.

The difficulty, of course, is tracking down where it is all going wrong as
there are so many different variables.

On 13/01/2017 16:06, Brian Baldino wrote:

Hey John, if I'm understanding your question correctly:
If the channels are bundled, they should all share the same bundle id.
Since frequently (and in the example) all channels for an endpoint are
bundled, one easy thing to do is to just use the endpoint-id as the
bundle-id for all of the channels. You could also create some other,
arbitrary string for the bundle-id for all of the channels.

-brian

On Fri, Jan 13, 2017 at 5:41 AM, John Hemming <john@hemming.email> wrote:

I think i have some idea as to what I am doing wrong with the REST JSON
objects.

In the first patch message at

https://github.com/jitsi/jitsi-videobridge/blob/master/doc/
rest-videobridge.md

for each of the channels it specifies a channel bundle Id which is the
same:

   "endpoint": "9f537ebb-1c2a-4ee9-9940-373304f9b260",
          "channel-bundle-id": "9f537ebb-1c2a-4ee9-9940-373304f9b260",

I have also done this which then bundles up the video, audio and data
connection into the same bundle.

It may be that they should be different. What I have done is to pick one
of the IDs of the candidates in the connection. That probably is also
wrong.

I would guess that I should instead create a new ID and have separate IDs
for each of the channels.

Is this right or is there something else?

This could cause the confusion between bundling channels, however.
_______________________________________________ dev mailing list
dev@jitsi.org Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

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

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


#5

To clarify: I was referring to some of John's logs, which seemed inconsistent to me, in that some of the channels had bundles, and some didn't.

Jitsi-meet/jicofo always bundle all of the channels for an endpoint (audio + video + data), and this has been working reliably. Other users of jitsi-videobridge use separate transports, and I'm not aware of any issues with that either.

Boris

···

On 13/01/2017 17:21, Brian Baldino wrote:

Hey John,
I sync'd up with Boris...there's no reliability issue with the bundling
on the bridge, so you're fine to use that (and I think you may have an
easier time, as most clients are going towards bundling now).


#6

The bridge is on the same computer as the client so connectivity should be OK.

···

On 13/01/2017 23:21, Brian Baldino wrote:

Hey John,
I sync'd up with Boris...there's no reliability issue with the bundling on the bridge, so you're fine to use that (and I think you may have an easier time, as most clients are going towards bundling now).

The REST examples don't include any ice information for a couple reasons:
1) Typically people do 'trickle ice', so the candidates are gathered continuously and you don't need to wait for the gathering process to finish before sending the answer, so the answer message wouldn't have the ice information but subsequent messages would (unfortunately I'm not much help with those subsequent messages as I haven't done it...you'll see why in #2 below)
2) If the bridge is not behind a firewall/NAT, sending candidates from the client to the bridge is not even necessary, as long as the client has candidates from the bridge. The client will start making ice connection attempts to the bridge and the bridge will detect the address from which those checks came and start checks using that address in the other direction. (Note, that this is not always the case, but frequently when a bridge is deployed it's deployed in such a way to be accessible by design, so it can be done this way. This was the scenario I had when writing the REST flow example).

-brian

On Fri, Jan 13, 2017 at 11:42 AM, John Hemming <john@hemming.email > <mailto:john@hemming.email>> wrote:

    As it stands I am simply trying to get the videobridge to work
    between Chrome and the Videobridge using the REST interface. I
    don't mind how this is done. I have experimented with various
    approaches.

    I think I probably have a problem with the SDP. When I produce a
    working SDP using some other software not related to Jitsi that
    works I get session values for the ice candidates and fingerprint.

    However, I got an SDP from OfMeet (which I believe was using jitsi
    in the plugin) and that had ice candidates against each media line.

    I have used SIP and SDP in various guises, but have not written
    anything from scratch so far and it is entirely possible that I
    have messed up on something other than the json sent to jitsi.

    Boris made the point that jitsi was bundling the audio/video and
    data channels, but not reliably. I have, therefore, today been
    trying to make things work by having the three channels each
    defined separately with separate channel bundles.

    When I get an answer SDP from Chrome it does not have any
    candidates so I am not sending remote candidates to Jitsi. I am
    not sure that this is right either. The reference json on the
    jitsi rest web page makes reference to an empty array of
    candidates. Whether that is right or not I don't know.

    Obviously it would be possible to me to implement the same things
    in XMPP, but I would rather stick to REST.

    The difficulty, of course, is tracking down where it is all going
    wrong as there are so many different variables.

    On 13/01/2017 16:06, Brian Baldino wrote:

    Hey John, if I'm understanding your question correctly:
    If the channels are bundled, they should all share the same
    bundle id. Since frequently (and in the example) all channels
    for an endpoint are bundled, one easy thing to do is to just use
    the endpoint-id as the bundle-id for all of the channels. You
    could also create some other, arbitrary string for the bundle-id
    for all of the channels.

    -brian

    On Fri, Jan 13, 2017 at 5:41 AM, John Hemming <john@hemming.email >> <mailto:john@hemming.email>> wrote:

        I think i have some idea as to what I am doing wrong with the
        REST JSON objects.

        In the first patch message at

        https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest-videobridge.md
        <https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest-videobridge.md>

        for each of the channels it specifies a channel bundle Id
        which is the same:

            "endpoint":"9f537ebb-1c2a-4ee9-9940-373304f9b260",
                   "channel-bundle-id":"9f537ebb-1c2a-4ee9-9940-373304f9b260",

        I have also done this which then bundles up the video, audio
        and data connection into the same bundle.

        It may be that they should be different. What I have done is
        to pick one of the IDs of the candidates in the connection. That probably is also wrong.

        I would guess that I should instead create a new ID and have
        separate IDs for each of the channels.

        Is this right or is there something else?

        This could cause the confusion between bundling channels,
        however.

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

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

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

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