XEP-proto-mingle0.1: Mingle
This specification defines an XMPP protocol extension for initiating and
managing multiparty voice and video conferences within an XMPP MUC
Document Information
Series: XEP
Number: proto-mingle0.1
Publisher: XMPP Standards Foundation
Status:
ProtoXep
Type:
Extension
Version: 0.0.0.1
Last Updated: 2008-10-28
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0045, XEP-0166
Supersedes: None
Superseded By: None
Short Name: mingle
Author Information
Legal Notices
Copyright
This XMPP Extension Protocol is copyright (c) 1999 - 2008 by the XMPP Standards Foundation (XSF).
Permissions
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
Disclaimer of Warranty
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##Limitation of Liability
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
IPR Conformance
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <
http://xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).
Discussion Venue
The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.
Errata may be sent to <editor@xmpp.org>.
Table of Contents
Jingle XEP-0166 is used to negotiate peer to peer media sessions.
Mingle is a way to coordinate Jingle sessions between a group of people.
Mingle conferences are held in XEP-0045 rooms.
A Mingle conference has a number of contents, each of which has unique name.
content type, and an encoding. Each participant may provide a stream for each
content, and communicates which contents they are willing to provide streams
for, along with encoding information, in their MUC presence. This serves two
purposes. Firstly, so that each participant knows which contents every other
participant provides. Secondly, so that there is a global payload type (PT)
mapping for the various contents, so that clients only need to encode and
payload each content that they provide once.
Participants can participate in a read-only mode by not advertising any
contents. Participants are not required to participate all the contents that
are available. For example, a Mingle client might choose to only request audio
streams.
Assuming there is no existing Mingle conference in the XEP-0045
room a new conference can be started by a user putting a Mingle stanza with
the proposed contents in its presence. As shown in the example below:
<presence from='wiccarocks@shakespeare.lit/laptop'
to='darkcave@chat.shakespeare.lit/oldhag'>
<c xmlns="http://jabber.org/protocol/caps"
node="http://telepathy.freedesktop.org/wiki/Mingle"
ver="48QdBuXRCJFb8qIzgy1FOHSGO0U="
hash="sha-1" />
<mingle xmlns='http://telepathy.freedesktop.org/mingle'>
<content name='video'>
<description xmlns='urn:xmpp:jingle:apps:rtp:0' media='video'>
<payload-type id='98' name='theora' clockrate='90000'/>
</description>
</content>
<content creator='initiator' name='voice'>
<description xmlns='urn:xmpp:jingle:apps:rtp:0' media='audio'>
<payload-type id='97' name='speex' clockrate='8000'/>
<payload-type id='18' name='G729'/>
</description>
</content>
</mingle>
</presence>
A client that is a member of a MUC joins a Mingle conference by first
updating their MUC presence with a Mingle stanza reflecting the contents
they want to provide.
A Mingle client MUST NOT advertise Mingle capabilities in their MUC presence
before they have received MUC presence from every other participant in the
MUC, because otherwise they cannot reliably create a payload type mapping
that's compatible with those of the existing participants. This means that
the initial MUC presence must not contain Mingle data.
When a client adds a payload ID to a content description, it MUST have the
same codec name and encoding parameters as the corresponding entries in
other participants' payload maps for that content. For instance, if Alice
defines a payload type with ID 98, codec Speex and a a clock rate of 8000
for a content called “voice0”, then Bob must define payload type 98
identically or not at all for that content.
Furthermore, each content description MUST include at least one payload type
that every other participant supports. In other words, the intersection of
payload type mappings in descriptions for a content must not be the empty
set. This avoids clients having to encode the same stream multiple times,
which can be very costly, and also allows sending the encoded data only once
where the transport makes this possible (e.g. IP multicast).
Once a client has constructed content descriptions and advertised them in
its MUC presence, it MUST initiate a Jingle session with every other
participant. The requirement that it is the joining participant that
initiates sessions avoids race conditions.
Jingle sessions are initiated between the MUC JIDs of participants. That is,
the Jingle session-intiate stanza is sent from one MUC JID to another. This
allows participants to easily identify sessions as belonging to a Mingle
conference. Content names inside Mingle-related Jingle sessions always refer
to the content with the same name inside the Mingle conference.
To leave a conference first the Mingle information, presence MUST first be
removed from the participant's presence; subsequently it SHOULD terminate
all Jingle sessions related to that conference. Updating the presence first
reduces the likelihood of situations where new participants initiate
sessions with participants who are leaving the conference.
- There is a race when two participants try to start a new Mingle
conference at the same time. This can be solves by making the initial
conference announceemnt two stage and relying on the fact that messages
are ordered to be the arbiter. (Note: actually find out if presence is
guaranteed to be ordered.)
- Describe how to add/remove contents.
- Add support for relays. Not all participants might have the necessary
upstream bandwidth to stream to everyone. A relay can help by relaying
the RTP streams of on or more participants. The relay could either be a
specialised component or just another client. Participants will provide
relay services by advertising them in their MUC presence.
- Add support for mixers in a similar way. Not all participants might
have the CPU power to decode all streams or the downstream bandwidth to
receive all streams. A mixer could mix various media streams into one
media stream and relay that. Again the mixer could be a specialised
component or just another client.
Notes
Revision History
Version 0.0.0.1 (2008-10-28)
(sjoerd)
END