XEP-0298: Delivering Conference Information to Jingle Participants (Coin)
Abstract
This specification defines an XMPP extension for tightly coupled
conference calls. It allows users who participate in multiparty Jingle
calls via a focus agent (mixer) to retrieve information and receive
notifications about the state of the call and the other participants.
This extension is also meant to provide a straightforward way of
connecting SIP and XMPP clients to the same conference room.
WARNING: This document has been automatically Deferred after 12 months of inactivity in its previous Experimental state. Implementation of the protocol described herein is not recommended for production systems. However, exploratory implementations are encouraged to resume the standards process.
Jingle (XEP-0166) [1] defines a way for XMPP agents to establish and control
one-to-one media sessions. It is possible for either participant in such a
session to also establish additional conversations and then serve as a
media mixer. This could be viewed as a classic conference call scenario
and is also often referred to as a tightly coupled conference.
Basic participation or hosting of tightly coupled conferences requires
no specific protocol support. With the exception of the mixing agent, call
members, however, all perceive the session as a regular one-to-one call.
They have no way of obtaining additional information about how many and what
other users are participating.
The Coin extension (short for Conference Information) allows media
mixers to deliver to participants additional information about the status
of the call, and that of its members.
A conference participant exchanges Coin IQs only with the agent they
have established a session with. This means that it can also be used in
cases where only a subset of the users on a call are using XMPP while others
are connected via alternative mechanisms such as SIP conferencing as defined
in RFC 4579 [2]
Throughout this document the term is used to depict an entity that is
responsible for mixing and delivering to conference participants both
signalling and media. Other specifications refer to mixers and focus
agents as two distinct entities but we find this separation to be
unnecessary in the current specification and view both as a single logical
entity. This entity may be a person hosting the conference and doing the mixing
or a dedicated entity to which participants connect in order to establish a conference.
For the purposes of this specification, both scenarios are equivalent.
This section provides a friendly introduction to Coin.
In essence Coin allows clients that establish Jingle calls to
determine whether their peer is acting as a mixer or to announce themselves
as such. This way non-mixer participants would know when they are
participating in a conference call and would be able to notify the user
accordingly.
Once in a call, participants and mixers can use Coin to exchange
RFC 4575 [4] conference information indicating what participants
are currently on the call and what their status is.
When creating conference calls mixers SHOULD indicate the nature of the
call as early as possible. This is necessary in order to allow other
participating user agents to adapt their user interface in an appropriate
way.
Similarly mixers being dialed by new participants SHOULD indicate the
nature of the call by including the <conference-info/> element into
the Jingle session-accept message.
Finally, when transforming an existing one-to-one session into a
conference or vice-versa a mixer SHOULD send a Jingle session-info message
with the appropriate <conference-info/> element.
Note that presence of the <conference-info/> element is only
determines whether the party sending it is currently acting as a mixer or
not. If multiple peers in a call are independently acting as mixers they
should all indicate their status accordingly.
Once a conference call has been established and advertised as such, a
mixer MAY at any point send information describing the state of the call and
its current participants.
The IQ message containing the conference info document MAY also contain a jingle element with the
session id attribute indicting the session to which the conference information refers to.
If an entity supports Coin, it SHOULD advertise that fact by returning
a feature of "urn:xmpp:coin:1" in response to a Service Discovery (XEP-0030) [5]
information request.
In order for an application to determine whether an entity supports this
protocol, where possible it SHOULD use the dynamic, presence-based profile
of service discovery defined in Entity Capabilities (XEP-0115) [6]. However, if an application has
not received entity capabilities information from an entity, it SHOULD use
explicit service discovery instead.
PENDING: RFC 4575 mostly talks about authentication
conference-info subscriptions but these are not part of this specification.
The authors are hence currently unaware of any other Coin specific security
considerations
This document provides a basic description of a simple way to support
tightly coupled conference calls. It is in many respects still a stub and a
number of open issues require the attention of the community:
Need to define best practices for user agents to easily determine
whether the request of user to establish a conference call should result
in a Muji or a Coin conference.
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. ##
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 from, out of, or in connection with the Specification or the implementation, deployment, or other use of 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 can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
Visual Presentation
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".