&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 conferencing as defined in &rfc4579;

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. 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.

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. Reuse the existing format and XML schema already defined in RFC 4575.
3. Impose no requirements on agents joining the call other than those necessary to establish a regular one-to-one call.
4. Allow straightforward interoperability with other conferencing mechanisms such as &rfc4579; or &xep0272;

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 &rfc4575; 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 &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.

Jitsi's participation in this specification is funded by the NLnet Foundation.