Hey Peter, great to see you looking into this!
(CCing jingle as I think a few interested people are only listening
there. Actually, we could maybe move the discussion there ...?)
More inline:
On 03.06.14, 06:47, Peter Saint-Andre wrote:
I'm working on an implementation of COLIBRI (XEP-0340) and have some
questions and comments...
The relationship (if any) to Jingle isn't explained at all.
Well, there isn't supposed to be much of a relationship, other than the
discussion mailing list and a few borrowed elements. But you are right
of course, that confusion should be clarified.
As a small
example, is the 'name' attribute of the <content/> element supposed to
match the same construction in Jingle?
No. It has the same ... "spirit" (i.e., refer to a specific media type),
but not the same syntax, nor semantics. The <content> in COLIBRI uses
the general COLIBRI namespace. Currently: http://jitsi.org/protocol/colibri
As a larger example, is the
<content/> element supposed to (potentially) contain <description/>
No.
and
<transport/>
Not directly. Transports are meant to be
elements from the Jingle specs, as is hinted by examples 2
and 3? (Note that example 3 has <payload-type/> elements without the
<description/> wrapper - this seems like a plain error.)
It's only an error if <content> was claiming to be the same as in
Jingle, which it is not doing.
Another
example: are the values of the 'direction' attribute (e.g., "recvonly")
supposed to match the values of the 'senders' attribute in Jingle?
No, not at all. It neither has the same name, nor possible values. It's
a command that tells a channel how to behave so there is some similarity
but they are not the same thing.
The text says that creation of a conference enables the organizers to
specify the participants. But I don't see any connection between the
channels that are created and any given JID. Should the <channel/>
element include a JID for the participant?
COLIBRI is not meant to place any dependencies on Jingle or XMPP. It is
just a command interface for a bridge or an SFU. The actual sessions can
very well be established with SIP for example or some other protocol.
The only entity that is guaranteed to talk XMPP in the whole picture is
the focus (i.e., the controlling/organising entity) and they don't even
need to participate in the conference.
What section are you pointing to? Maybe we could clarify the text there.
(Nit: the 'initiator'
attribute here might be confused with the meaning of "initiator" in
Jingle.)
Confused how? The initiator attribute is supposed to tell the bridge/SFU
that it has to behave as the controlling ICE agent and it needs to be
the DTLS/SRTP negotiation server (just as a Jingle initiator would be
actually ...). Do you think we should be using a different name?
What are the allowable values for the 'rtp-level-relay-type' attribute,
and why?
'mixer' and 'relay'. The former tells the bridge/SFU that it would need
to mix all content and only then send a single mixed stream through the
channel.
'relay' means that all streams will be relayed with no mixing so the
endpoint will see them all arriving.
Does this answer your question or did you mean something else?
Example 7 strikes me as odd (for adding a new channel).
Yes, it's a bit misleading. It's actually adding two channels for
(presumably) one new participant.
Is this really done by sending an IQ-get or is that a typo?
Busted! I believe that all through the document (and our implementation
for that matter) use of IQ types is somewhere between liberal and
arbitrary. I think we can just say that they are all "set" and be done
with it.
More importantly, how does
the media bridge know that this stanza is intended to update an existing
conference, rather than to create a new one?
Because of the ID.
I think we might want an
explicit 'action' attribute, so that we can differentiate between
conference creation and conference modification.
Hmmm ... why? Currently a known ID means you are modifying. No ID means
you are creating. An unknown ID means an error. There's no place for
confusion. Adding an action would only serve to create more error
states: like for example an action="create" for an existing conf ID.
There's no reference to XEP-0320 for the <fingerprint/> element or to
XEP-0339 for the <source/> element.
Yup. Should be fixed. I don't think either of those existed when we were
writing this but we can obviously use them now that they are there.
I might have more questions once I make more progress on the code I'm
writing...
That would be great!
Emil
--
https://jitsi.org
