diff --git a/inbox/coin.xml b/inbox/coin.xml new file mode 100644 index 00000000..5132b8fd --- /dev/null +++ b/inbox/coin.xml @@ -0,0 +1,714 @@ + + +%ents; +]> + + +
+ Delivering Conference Information to Jingle Participants (Coin) + 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. + + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XEP-0167 + + + + coin + + Emil + Ivov + emcho@sip-communicator.org + emcho@sip-communicator.org + + + Enrico + Marocco + enrico.marocco@telecomitalia.it + enrico@tilab.com + + jingle + + 0.0.1 + 2011-01-23 + ei/em + +

First draft.

+ + +
+ +

&xep0166; 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's conference + package &rfc4575;

+ + +
+ +
Mixer
+
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
+ +
+ + +

The extension defined herein is designed to meet the following + requirements:

+
    +
  1. Provide a means for mixer agents in tightly coupled + conferences to advertise call and member state information to the call + participants.
    2. +
  2. Reuse as much as possible the existing format and XML schema already + defined in RFC 4575.
    3. +
  3. Impose no requirements on agents joining the call other than those + necessary to establish a regular one-to-one call.
    4. +
  4. Allow straightforward interoperability with other conferencing + mechanisms such as RFC 4575; or &xep0272;
    5. +
+ + +

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, call members and mixers can use Coin to exchange + RFC 4575 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.

+ + + + + action='session-initiate' + initiator='romeo@montague.lit/orchard' + sid='a73sjjvkla37jfea'> + + + + + + + + ]]> +

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.

+ + + + + + + + Ending a relationship + + + + + 3 + + + + + + Romeo + + + + Romeo's smartphone + disconnected + + 2011-01-31T20:00:00Z + poisoned + + + + + main audio + audio + 432424 + + + + + + Romeo + + + + Juliet's netbook + connected + + + + audio + 2124 + + + + + + + Alice + + + + connected + + + + audio + 534232 + + + + + + + + ]]> + + + + + + +

If an entity supports Coin, it SHOULD advertise that fact by returning + a feature of "urn:xmpp:coin" in response to a &xep0030; + 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 &xep0115;. 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:

+
    +
  1. 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.
    2. +
+ + + + + + + + + + The protocol documented by this schema is defined in + XEP-0XXX: http://www.xmpp.org/extensions/xep-0XXX.html + + + + + + + + + + + ]]> + + + + + + + + The protocol documented by this schema is defined in + RFC 4575: http://tools.ietf.org/html/rfc4575 and reused by + XEP XXXX http://www.xmpp.org/extensions/xep-XXXX.html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + +