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