One document matched: draft-ietf-p2psip-disco-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-ietf-p2psip-disco-00" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<!--<?rfc compact="yes" ?>-->
<?rfc strict="yes" ?>
<front>
<title abbrev="DisCo">A RELOAD Usage for Distributed Conference Control
(DisCo)</title>
<author fullname="Alexander Knauf" initials="A." surname="Knauf">
<organization abbrev="HAW Hamburg">HAW Hamburg</organization>
<address>
<postal>
<street>Berliner Tor 7</street>
<city>Hamburg</city>
<code>D-20099</code>
<country>Germany</country>
</postal>
<phone>+4940428758067</phone>
<email>alexanderknauf@gmail.com</email>
<uri></uri>
</address>
</author>
<author fullname="Thomas C. Schmidt" initials="T C." surname="Schmidt, Ed.">
<organization>HAW Hamburg</organization>
<address>
<postal>
<street>Berliner Tor 7</street>
<city>Hamburg</city>
<code>D-20099</code>
<country>Germany</country>
</postal>
<email>schmidt@informatik.haw-hamburg.de</email>
<uri>http://inet.cpt.haw-hamburg.de/members/schmidt</uri>
</address>
</author>
<author fullname="Gabriel Hege" initials="G." surname="Hege">
<organization abbrev="daviko GmbH">daviko GmbH</organization>
<address>
<postal>
<street>Am Borsigturm 50</street>
<city>Berlin</city>
<code>D-13507</code>
<country>Germany</country>
</postal>
<phone>+493043004344</phone>
<email>hege@daviko.com</email>
<uri></uri>
</address>
</author>
<author fullname="Matthias Waehlisch" initials="M." surname="Waehlisch">
<organization abbrev="link-lab & FU Berlin">link-lab & FU
Berlin</organization>
<address>
<postal>
<street>Hoenower Str. 35</street>
<city>Berlin</city>
<code>D-10318</code>
<country>Germany</country>
</postal>
<email>mw@link-lab.net</email>
<uri>http://www.inf.fu-berlin.de/~waehl</uri>
</address>
</author>
<date />
<abstract>
<t>This document defines a RELOAD Usage for Distributed Conference
Control (DisCo) with SIP. DisCo preserves conference addressing through
a single SIP URI by splitting its semantic of identifier and locator
using a new Kind data structure. Conference members are enabled to
select conference controllers based on proximity awareness and to
recover from failures of individual resource instances. DisCo proposes
call delegation to balance the load at focus peers.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document describes a RELOAD Usage for distributed conference
control (DisCo) in a tightly coupled model with SIP <xref
target="RFC3261"></xref>. The Usage provides self-organizing and
scalable signaling that allows RELOAD peers, clients and plain SIP user
agents to participate in a managed P2P conference. DisCo defines the
following functions:<list style="symbols">
<t>A SIP protocol scheme for distributed conference control</t>
<t>RELOAD Usage and definition of conferencing Kind</t>
<t>Mechanisms for conference synchronization and call delegation</t>
<t>Mechanism for proximity-aware routing within a conference</t>
<t>An XML event package for distributed conferences</t>
</list></t>
<t>In this document, the term distributed conferencing refers to a
multiparty conversation in a tightly coupled model in which the point of
control (i.e., the focus) is identified by a unique URI, but the focus
service is located at many independent entities. Multiple SIP <xref
target="RFC3261"></xref> user agents uniformly control and manage a
multiparty session. This document defines a new Usage for RELOAD,
including an additional Kind code point with a corresponding data
structure that complies with the demands for distributed conferences.
The 'DisCo' data structure stores the mapping of a single conference URI
to multiple conference controllers and thereby separates the conference
identifier from focus instantiations.</t>
<t>Authorized controllers of a conference are permitted to register
their mapping in the DisCo data structure autonomously. Thus, the DisCo
data structure represents a co-managed Resource in RELOAD. To provide
trusted and secure access to a co-managed Resource, this document uses
the definitions for Shared Resources (ShaRe) <xref
target="I-D.knauf-p2psip-share"></xref>.</t>
<t>Delay and jitter are critical issues in multimedia communications.
The proposed conferencing scheme supports mechanisms to build an
optimized interconnecting graph between conference participants and
their responsible conference controllers. Conference members will be
enabled to select the closest focus with respect to delay or jitter.</t>
<t>DisCo extends conference control mechanisms to provide a consistent
and reliable conferencing environment. Controlling peers maintain a
consistent view of the entire conference state. The multiparty system
can be re-structured based on call delegation operations.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119">
</xref>.<vspace blankLines="1" /></t>
<t>We use the terminology and definitions from der RELOAD base
draft<xref target="I-D.ietf-p2psip-base"> </xref>, the peer-to-peer SIP
concepts draft <xref target="I-D.ietf-p2psip-concepts"></xref>, the
usage for shared resources draft <xref
target="I-D.knauf-p2psip-share"></xref>,and the terminology formed by
the framework for conferencing with SIP <xref target="RFC4353"> </xref>.
Additionally the following terms are used:<list style="hanging">
<t hangText="Coordinate Value:">An opaque string that describes a
host's relative position in the network topology.</t>
<t hangText="Focus peer:">A RELOAD peer that provides SIP
conferencing functions and implements the Usage for distributed
conferencing. It is called 'active' if already involved in signaling
relation to conference participants. Otherwise, if only registered
in a distributed conference data structure, it is referred to as a
'potential' focus peer.</t>
</list></t>
</section>
<section anchor="sec-o" title="Overview of DisCo">
<section anchor="subsec-a" title="Reference Scenario">
<t>The reference scenario for the Distributed Conference Control
(DisCo) is shown in <xref target="fig-disco-arch"> </xref>. Peers are
connected via a RELOAD <xref target="I-D.ietf-p2psip-base"></xref>
instance, in which peers A and B are managing a single multiparty
conference. The conference is identified by a unique conference URI,
but located at peers A and B fulfilling the role of the focus. The
mapping of the conference URI to one or more responsible focus peers
is stored in a new RELOAD Resource for distributed conferencing within
a data structure denoted as DisCo-Registration. The storing peer SP of
the distributed conference resource holds this data.</t>
<t>The focus peers A and B maintain SIP signaling relations to
conference participants, which may have different conference protocol
capabilities. In this example, peer A is the focus for the RELOAD peer
C and the plain SIP user agent E whereas peer B serves as a focus for
RELOAD peer D and the RELOAD client F.</t>
<t>RELOAD peers and clients obtain the contact information for the
conference from the storing peer. In contrast to this, the user agent
E receives the conference URI not by RELOAD mechanisms, but resolves
the ID and joins the conference by plain SIP negotiation.</t>
<t>Focus peers maintain a SIP signaling relation among each other used
for notification messages that synchronize the conference focus peers'
knowledge about the entire conference state. Additionally, focus peers
can transfer calls to each other by a call delegation mechanism.</t>
<figure align="center" anchor="fig-disco-arch" suppress-title="false"
title="Reference Scenario: Focus peers A,B maintain a distributed conference">
<artwork align="center" name="DisCo Architecture"
xml:space="preserve"><![CDATA[
+-------------------+ +------------------+
|Access Control List| |DisCo-Registration|
+-------------------+ +------------------+
\ /
+-------+
|Storing|
# # # # # # # # # # | Peer | # # # # # # # # # #
# | SP | #
# +-------+ #
# #
# #
# #
+----+ +----+
|Peer| \ RELOAD Instance |Peer|
| C | \ | D |
+----+ \ +----+
# SIP #
# \ #
# \ #
# +-------+ +-------+ #(
# | Focus | | Focus | # )
# # | Peer | # # # # # # # # # # # | Peer | # # (
| A | <===Conf.Events/====> | B | )
+-------+ Call delegation +-------+ Overlay
/ \ Comm.
/ \ (
SIP SIP )
/ \ (
/ \ )
+----------+ +--------+
|User Agent| | Client |
| E | | F |
+----------+ +--------+]]></artwork>
</figure>
</section>
<section anchor="subsec-iadc"
title="Initiating a Distributed Conference">
<t>To create a conference the initiating user agent announces itself
as a focus for the conference. It stores its own contact information
(Node-ID) as a DisCo-Registration Kind (cf. <xref format="default"
target="fig-overview-cf"></xref>) in the RELOAD overlay. The hashed
conference URI is used as the Resource-ID. This Resource will later
contain the contact IDs of all potential focus peers including
optional topological descriptors.</t>
</section>
<section anchor="subsec-jac" title="Joining a Conference">
<t>A RELOAD-aware node (cf. Bob in <xref format="default"
target="fig-overview-cf"></xref>) intending to join an existing
conference requests the list of potential focus peers stored in the
DisCo-Registration under the conference's Resource-ID. The node
selects any of the focus peers (e.g., Alice) and establishes a
connection using AppAttach/ICE <xref target="RFC5245"></xref>. This
transport is then used to send an INVITE to the conference applying
the chosen focus as the contact. The selection of the focus peer can
optionally be based on proximity information if available.</t>
<t>A conference member proposes itself as a focus for subsequent
participants by adding its Node-ID to the DisCo-Registration stored
under the conference URI in the RELOAD overlay. The decision whether a
peer announces as a focus incorporates bandwidth, power, and other
constraints, but details are beyond the scope of this document.</t>
<figure align="center" anchor="fig-overview-cf" suppress-title="false"
title="DisCo Usage generic Call Flow">
<artwork align="center" name="DisCo Usage Overview"><![CDATA[
Alice RELOAD Bob
(initiating peer) (joining peer)
--------------------------------------------------------------------
| | |
| Alice stores her mapping to register a conference |
| Store mapping(ConfURI, Alice) | |
|------------------------------>| |
| Bob requests the list of potential focus peers |
| | Lookup ConfURI |
| |<------------------------------|
| | Result list of conf. focus |
| |------------------------------>|
| | |
| Bob establishes transport connection to Alice |
| AppAttach |
|<--------------------------------------------------------------|
| AppAttach |
|-------------------------------------------------------------->|
| INVITE |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| OK |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
| ACK |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Media |
|<=============================================================>|
| | |
| Bob stores his mapping to become a focus peer too |
| | Store mapping(ConfURI, Bob) |
| |<------------------------------|
| | |
]]></artwork>
</figure>
</section>
<section anchor="subsubsec-cs" title="Conference State Synchronization">
<t>Each focus of a conference maintains signaling connections to its
related participants independently from other conference controllers.
This distributed conference design effects that the entire SIP
conference state is jointly held by all focus peers. In DisCo, state
synchronization is based on a SIP specific event notifications
mechanism <xref target="RFC3265"></xref>.</t>
<t>Each focus peer maintains its view of the entire conference state
by subscribing to the other focus peers' XML event package for
distributed conferences. This is based on the event package for
conference state (cf. <xref target="RFC4575"></xref>). Details are
defined in this document in <xref target="sec-css"></xref>. Receivers
of event notifications update their local conference state document to
represent a valid view of current total conference state.</t>
<t>The event notification package for distributed conferences enables
focus peers to synchronize the entire conference state. The event
package defines additional XML elements and complex types (see <xref
target="sec-xmls"> </xref> for more details), which describe the
responsibilities of any focus peer in the conference. By providing a
global view each focus peer is enabled to perform additional load
balancing operations and enhances the robustness against departures of
focus peers.</t>
</section>
<section anchor="subsubsec-cdar" title="Call delegation">
<t>Call delegation (see <xref target="subsec-cd"> </xref>) is a
feature used to transfer an incoming participation request to another
focus peer. It can be applied to prevent overloading of focus peers.
Call delegation is realized through SIP REFER requests, which carry
signaling and session description information of the caller to be
transferred. This feature is achieved transparently for the
transferred user agent by using a source routing mechanism at SIP
dialog establishment. Descriptions of overload detection are beyond
the scope of this document.</t>
</section>
<section anchor="subsec-u" title="Resilience">
<t>A focus peer can decide to leave the conference or may ungracefully
fail. In a traditional conferencing scenario, loss of the conference
controller or the media distributor would cause a complete failure of
the multiparty conversation. Distributed conferencing uses the
redundancy provided by multiple focus peers to reconfigure a current
multiparty conversation. Participants that loose their entry point to
the conference re-invite themselves via the remaining focus peers or
will be re-invited by the latter. This option is based on the
conference state and call delegation functions.</t>
</section>
<section anchor="subsubsec-tatl" title="Topology Awareness">
<t>DisCo supports the optimization of the conference topology in
respect of the underlying network using topological descriptors. An
extension for the RELOAD XML configuration document is defined in
<xref target="subsec-cde"></xref> to support landmarking approaches.
Each peer intending to create or participate in a distributed
conference MAY determine a topological descriptor that describes its
relative position in the network. Focus peers store these coordinate
values in an additional data field in the DisCo-Registration data
structure. This enables peers joining the conference to select the
closest focus with respect to its coordinate values.</t>
</section>
</section>
<section title="RELOAD Usage for Distributed Conference Control">
<section anchor="subsec-srdr" title="Shared Resource DisCo-Registration">
<t>A distributed conference is a cooperative service of several
individual devices that use a common identifier. To enable a mapping
from one conference identifier to multiple focus peers, this document
defines the new Kind data structure DisCo-Registration. The DisCo Kind
uses the definitions for Shared Resources <xref
target="I-D.knauf-p2psip-share"></xref> to allow a jointly maintenance
by multiple focus peers. Hence, write permission to a
DisCo-registration is shared by the conference creator with all
authorized focus peers.</t>
<t>DisCo complies with the following requirements for Shared
Resources: <list style="hanging">
<t hangText="Isolated Data Storage:">DisCo uses the dictionary
data model. Each dictionary key is the Node-ID of the certificate
that will be used to sign the stored data</t>
<t hangText="ResourceNameExtension field:">A DisCo-Registration
can contain the ResourceNameExtension structure an initial field
in the Kind data structure. It contains the conference URI of the
registered DisCo-record.</t>
</list></t>
</section>
<section anchor="subsec-kds" title="Kind Data Structure">
<t>Each DisCo-Registration data structure stores a mapping of a
conference identifier to one or multiple focus peers that
cooperatively control the conference. Additionally, each
DisCo-Registration provides the coordinate value, which indicates the
relative network position of the focus peers.</t>
<t>The data structure uses the RELOAD dictionary type. The dictionary
key MUST be the Node-ID of the focus peer that is associated with the
dictionary entry. This allows a focus peer to update only its own
mapping. The DisCo data structure of type DisCoRegistration is
constructed as follows:</t>
<figure align="center" suppress-title="true">
<artwork align="left" xml:space="preserve"><![CDATA[
struct {
/* This field is optional, see documentation */
ResourceNameExtension res_name_ext;
opaque coordinate<0..2^16-1>;
NodeId node_id;
} DisCoRegistration;]]></artwork>
</figure>
<t>The DisCoRegistration structure is composed of the following
values: <list style="hanging">
<t hangText="res_name_ext:">This field can contain the conference
URI. It meets the requirement for the USER-CHAIN-ACL access policy
defined in <xref target="I-D.knauf-p2psip-share"></xref> to enable
variable resource names.</t>
<t hangText="coordinate:">This field contains a topological
descriptor that indicates the relative position of the peer in the
network. To support different algorithms the coordinate field is
represented as an opaque string.</t>
<t hangText="node_id:">This field contains the Node-ID of the peer
storing the DisCoRegistration and is used to contact the peer when
utilizing its service as a focus.</t>
</list></t>
</section>
<section anchor="subsec-vci" title="Variable Conference Identifier">
<t>DisCo-Registrations can be stored based on a variable Resource
Name. However, a conference identifier set by a user MUST follow the
requirements for Kinds using variable Resource Names as defined in the
ShaRe Usage <xref target="I-D.knauf-p2psip-share"></xref>.</t>
</section>
<section anchor="subsec-cc" title="Conference Creation">
<t>The registration of a distributed conference includes the storage
of the following two Kinds (see <xref
target="fig-conf-create-cf"></xref>). <list style="hanging">
<t hangText="DisCo-Registration Kind:">contains the conference
identifier and the optional coordinate value. If used, the
coordinate value MAY be determined previously to the conference
registration. The Resource Name and hence the Resource-ID is
defined by the hash over the desired conference identifier (using
the hash algorithm of the overlay).</t>
<t hangText="Access Control List Kind:">contains the conference
participants that are allowed to register as focus peers for a
conference (see <xref target="I-D.knauf-p2psip-share"></xref>).
Its Resource Name/ID is equal to those of the corresponding
DisCo-Registration.</t>
</list></t>
<t>Preliminary to storage of DisCo-Registration and Access Control
List (ACL) Kinds the conference creator SHOULD perform a RELOAD
StatReq to verify that no former conference is present. If neither a
DisCo-Registration nor an associated ACL exist, the conference creator
stores a DisCo-Registration with a valid conference identifier (see
<xref target="subsec-vci"></xref>) and an ACL referring to the
DisCo-Registration Kind-ID.</t>
<t>If DisCo registrations and ACL Kinds from previous conferences are
still existing there are two options. First, if conference creator is
aware of the indexes from previous ACL Kinds, it refreshes the root
item of this ACL and stores its registration as focus peer as
DisCo-Registration Kind. Second, If the creator is unaware of indexes,
it fetches all Access List Kinds to determine the index of the root
item.</t>
<figure align="center" anchor="fig-conf-create-cf"
suppress-title="false"
title="Initial creation of a Distributed Conference">
<artwork align="center" xml:space="preserve"><![CDATA[
Alice Peer1 Overlay PeerN Storing Peer
-------------------------------------------------------------
| StatReq Res:Conf-URI | |
|------------>|----------->|----------->|----------->|
| StatAns | | |
|<------------|<-----------|<-----------|<-----------|
| StoreReq Res:Conf-URI Kinds:DisCo, Access-List |
|------------>|----------->|----------->|----------->|
| StoreAns | | |
|<------------|<-----------|<-----------|<-----------|
| | | | |
]]></artwork>
</figure>
<t>Optionally the conference initiator (or any active focus) MAY store
an additional RELOAD SIP-Registration in the overlay <xref
target="I-D.ietf-p2psip-sip"></xref> or even at a standard SIP
registrar <xref target="RFC3261"></xref> under a URI for which it has
write permission. This allows DisCo-unaware or even legacy SIP user
agents to participate in the conference. Those registrations SHOULD
always point to a currently active focus, who is prepared to accept
legacy user agents. The user agent who initially performed the
registrations is responsible for updating them appropriately. How
authorization has been obtained to perform those registration is out
of scope of this document.</t>
<t>The lifetime of a distributed conference is not necessarily limited
by the participation time of its creator. As long as the root item of
an Access Control List to a DisCo-Registration is not expired,
Authorized Peers are allowed to further provide a conferencing service
and even store new focus registrations.</t>
</section>
<section anchor="subsec-ada" title="Advertising Focus Ability">
<t>All participants of a distributed conference MAY potentially become
a focus peer for their conference. This depends on its capacities such
as sufficient processing power (CPU, Memory) for the desired media
type, the quality of the network connectivity, and the conference
policy. Information about network connectivity with respect to NAT or
restricted firewalls can be obtained via ICE <xref
target="RFC5245"></xref> connectivity checks. If a peer is behind a
NAT, it SHOULD allow for incoming connections via AppAttach/ICE. Peers
that can only accept connections with the support of TURN should not
act as a focus. Nevertheless, under special circumstances it might be
reasonable to locate a focus peer behind such a NAT (e.g., within a
companies network infrastructure).</t>
<t>If a participant is a candidate to become a focus for the
conference, it stores its Node-ID and optional coordinate value into
the DisCo data structure. An entry in the corresponding ACL <xref
target="I-D.knauf-p2psip-share"></xref> must be present to allow this
peer to write the DisCo-Registration resource. By storing the mapping
into the data structure a participant becomes a potential focus.</t>
</section>
<section anchor="subsec-dc" title="Determining Coordinates">
<t>Each RELOAD peer within the context of a distributed conference MAY
be aware of its relative position in the network topology. To constuct
a topology-aware conference, the DisCo Usage provides the coordinate
value within the DisCo-Registration data structure. Focus peers store
their relative network position together with the announcement as
conference focus. Joining peers that are able to determine their
coordinates may then select a focus peer whose relative position is in
its vicinity (see <xref target="subsec-pcp"></xref>).</t>
<t>Some algorithms determine topology information by measuring
Round-Trip Times (RTT) towards a set of hosts serving as landmarks
(e.g., <xref target="landmarks-infocomm02"></xref>). To support such
algorithms this document describes an extension to the RELOAD XML
configuration document that allows to configure the set of landmark
hosts peer must use for position estimation (see <xref
target="subsec-cde"> </xref>). Once a focus peer has registered its
mapping in the DisCo data structure, it also stores the according
coordinates in the same mapping. These <Node-ID,coordinates>
vectors are used by peers joining the conference to select the focus
peer that is relatively closest to itself.</t>
<t>Because topology-awareness can be obtained by many different
approaches a concrete algorithms is out of scope of this document.</t>
</section>
<section anchor="subsec-pcp"
title="Proximity-aware Conference Participation">
<t>The participation procedure to a distributed conference is composed
of three operation. <list style="numbers">
<t>Resolution of the conference identifier.</t>
<t>Establishment of of transport connection.</t>
<t>SIP signaling to join a conference.</t>
</list></t>
<t><xref target="fig-conf-join-cf"></xref> and the following
specifications give a more detailed view on the joining procedure.</t>
<figure align="center" anchor="fig-conf-join-cf"
suppress-title="false"
title="Participation of a Distributed Conference">
<artwork align="center" xml:space="preserve"><![CDATA[
Bob Peer1 Overlay PeerN Storing Peer Alice
--------------------------------------------------------------
| StatReq Res:Conf-URI | | |
|--------->|--------->|--------->|--------->| |
| |StatAns | | | |
|<---------|<---------|<---------|<---------| |
| FetchReq Res:Conf-URI Kind:DisCo,ACL | |
|--------->|--------->|--------->|--------->| |
| |FetchAns | | | |
|<---------|<---------|<---------|<---------| |
| | | | | |
| Bob calculates Alice as closest Focus | |
| | | | | |
| |AppAttach application:5060 | |
|--------->|--------->|--------->|--------->|--------->|
| |AppAttach application:5060 | |
|<---------|<---------|<---------|<---------|<---------|
| | | | | |
|<-------------------ICE Checks----------------------->|
| | | | | |
| | INVITE sip:Alice | |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
| | 200 OK | | |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| | ACK | | |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
| | | | | |]]></artwork>
</figure>
<t><list style="numbers">
<t>The joining peer MAY determine its own coordinate value (if
used).</t>
<t>The joining peer sends a StatReq message to obtain all indexes
of the Access Control List (ACL) Kinds stored.</t>
<t>The joining peer sends a FetchReq message for the DisCo and ACL
Kind to the Resource-ID of the conference URI. The FetchReq SHOULD
NOT include any specific dictionary keys, but SHOULD fetch for
those array ranges previously determined the StatReq. With the ACL
items, the joining peer is able to verify whether
DisCo-Registrations are stored by authorized focus peers (see
<xref target="I-D.knauf-p2psip-share"></xref>).</t>
<t>Using the retrieved coordinates values of the
DisCo-Registrations, the joining peer MAY calculate which of than
opaque <0..2^16-1> initial field in the Kind data structure
focus peers is the relatively closest to itself.</t>
<t>The joining peer then establishes a transport using RELOADs
AppAttach, respectively, ICE procedures to create a transport to
the chosen focus peer. <!--Since SIP is utilized for signaling the
AppAttach requests a SIP session creation setting the port to
5060.--></t>
<t>Finally, the established transport is used to create a SIP
dialog from the joining peer to the focus peers.</t>
</list></t>
<t>The SIP INVITE request MAY contain the joining peer's topological
descriptor as a URI-parameter called 'coord' in the contact-header in
base64 encoded form <xref target="RFC4648"></xref>. An example contact
URI is
“sip:alice@example.com;coord=PEknbSBhIHRvcG9sb2dpY2FsIGRlc2NyaXB0b3I+”.
When the called focus is full and needs to delegate the call it uses
the contents of the 'coord'-parameter. It determines the next
available focus closest to the calling peer (<xref
target="subsec-dc"></xref>) using the received descriptor and the
other focuses' descriptors from the conference state synchronization
document and delegates the call accordingly (see <xref
target="subsec-cd"></xref>).</t>
<t>A conference focus MAY allow the joining peer to also become a
focus (depending on the conference policy see <xref
target="subsec-ls"></xref>). Therefore, it stores a new ACL Kind that
delegates write permission for the DisCo-Registration to the new
participant. It sets the 'user_name' field in the ACL Kind to its own
user name and sets the 'to_user' field to the user name of the joining
peer. If no other conference policy is defined, the focus peer MAY set
the allow_delegation flag to true. For further details about the trust
delegation using the ACL Kind see <xref
target="I-D.knauf-p2psip-share"></xref>.</t>
</section>
<section anchor="subsec-cde" title="Configuration Document Extension">
<t>This section defines an additional parameter for the
<configuration> element that extends the RELOAD XML
configuration document. The proposed <landmarks> element allows
RELOAD provider to publish a set of accessible and reliable hosts that
SHOULD be used if RELOAD peers use landmarking algorithms to determine
relative position in the network topology.</t>
<t>The <landmarks> element serves as container for the
<landmark-host> sub-elements, each representing a single host
that serves as a landmark. The <landmark-host> uses the
following attributes:<list style="hanging">
<t hangText="address:">The IP address (IPv4 or IPv6) of the
landmark host.</t>
<t hangText="port:">The port on which the landmark host responds
for distance estimation.</t>
</list> More than one landmark hosts SHOULD be present in the
configuration document.</t>
</section>
</section>
<section anchor="sec-css" title="Conference State Synchronization">
<t>The global knowledge about signaling and media relations among the
conference participants and focus peers defines the global state of a
distributed conference. It is composed of the union of every local state
at the focus peers. To enable focus peers to provide conference control
operations that modify and/or require the global state of a conference,
this document defines a mechanism for inter-focus state synchronization.
It is based on mutual subscriptions for an Event Package for Distributed
Conferences and allows to preserve a coherent knowledge of the global
conference state. This XML based event package named
'distributed-conference' MUST be supported by each RELOAD peer that is
registered with a DisCo-Registration. Participants of a distributed
conference MAY support it. To provide backward compatibility to
conference members that do not support the distributed-conference event
package, this document defines a translation to the Event Package for
Conference State <xref target="RFC4575"></xref>.</t>
<section anchor="subsec-epo" title="Event Package Overview">
<t>The 'distributed-conference' event package is designed to convey
information about roles and relations of the conference participants.
Conference controllers obtain the global state of the conference and
use this information for load balancing or conference restructuring
mechanisms in case of a focus failure. Figure <xref
target="fig-dcepo"></xref> gives a general overview of the document
hierarchy.</t>
<figure align="center" anchor="fig-dcepo" suppress-title="false"
title="Overview of the event package for distributed conferences">
<artwork align="left" xml:space="preserve"><![CDATA[
distributed-conference
|
|-- version-vector
| |-- version
| |-- version
|
|-- conference-description
|
|-- focus
| |-- focus-state
| | |-- user-count
| | |-- coordinate
| | |-- maximum-user-count
| | |-- active
| | |-- locked
| | |-- conf-uris
| | |-- available-media
| |
| |-- users
| | |-- user
| | | |-- endpoint
| | | | |-- media
| | | | |-- call-info
| |
| |-- relations
| | |-- relation
|-- focus
| |-- ...
]]></artwork>
</figure>
<t>The document structure is designed to allow concurrent change
events at several focus peers. To prevent race conditions each focus
peer has exclusive writing permission to the 'focus' sub element that
describes itself. It is achieved by a unique mapping from a focus peer
to its XML element using the 'Element Keys' mechanisms for partial
notification <xref target="RFC4575"></xref>(sections 4.4-5.). A focus
peer is only allowed to update or change that <focus> sub
element, whose 'entity' Element Key contains its RELOAD user name.
This restriction also applies to the child elements of the
'version-vector' element. Each 'version' number belongs to a specific
focus peer maintaining the version number.</t>
<t>The local state of a focus peer is described within a 'focus'
element. It provides general information about a focus peer and its
signaling and media relations to participants and focus peers. The
Conference participants are aggregated within 'users' elements,
respectively, 'user' sub elements.</t>
<t>General information about the conference as a whole, is provided
within a 'conference-description' element. In contrast to the 'focus'
and 'version-vector' elements, conference description is not meant for
concurrent updating. Instead, it provides static conference
descriptions that rarely change during a multiparty session.</t>
<t>More detailed descriptions about the event package and its elements
are provided in the following sections. The complete XML schema
definition is given in <xref target="sec-xmls"></xref>.</t>
</section>
<section anchor="subsec-xml-dc" title="<distributed-conference>">
<t>The <distributed-conference> element is the root of a
distributed conference XML document. It uses the following attributes:
<list style="hanging">
<t hangText="entity:">This attribute contains the conference URI
that identifies the distributed conference. A SIP SUBSCRIBE
request addressed to this URI initiates an subscribe/notify
relation between participants and their related focus peer.</t>
<t hangText="state:">This attribute indicates whether the content
of a distributed conference document is a 'full', 'partial' or
'deleted' information. It is in accordance with <xref
target="RFC4575"></xref> to enable the partial notification
mechanism.</t>
</list></t>
<t>The <distributed-conference> child elements are
<vector-version>, <conference-description> and the
<focus> elements. An event notification of state 'full' MUST
include all these elements. An event notification of state 'partial'
MUST contain at least <version-vector> and its sub elements.</t>
</section>
<section anchor="subsec-xml-vvv"
title="<version-vector>/<version>">
<t>The Event Package for Distributed Conferences uses the
<version-vector> and its <version> sub elements to enable
a coherent versioning scheme. It is based on vector clocks as defined
in <xref target="timestamps-acsc88"></xref>. Each <version>
element contains a unsigned integer that describes the state of a
specific focus peer and contains the following attributes: <list
style="hanging">
<t hangText="entity:">This attribute contains the user name of the
focus peer whose local version number is described by this
element.</t>
<t hangText="node-id:">This attribute contains the Node-ID of the
focus peer.</t>
</list></t>
<t>Whenever the local status of a focus peer changes (e.g. a new
participant arrived) the version number of the corresponding
<version> element MUST be incremented by one. Each change in the
local state also triggers a new event notification containing the
entire <version-vector> and the changes contained in a
<focus> element.</t>
<t>The recipient of a change event needs to update it local XML
document. If a received <version> number is higher that the
local, it updates the <version> element and its associated
<focus> element with the retrieved elements. All other elements
remain constant.</t>
<t>If the length or contents of the retrieved <version-vector>
is different to the local copy it indicates a incoherent knowledge
about the entire conference state. If the retrieved
<version-vector> contains any unknown focus peers and any local
version numbers for the known focus peers is lower, the receiver
SHOULD request a 'full' XML notification.</t>
<t>If any local <version> number is retarded more than one, the
receiver SHOULD request a 'full' event notification from the sender.
The full state notification updates all <focus> elements whose
corresponding <version> element is out of date.</t>
</section>
<section anchor="subsec-xml-cd" title="<conference-description>">
<t>The <conference-description> element provides general
information and links to auxiliary services for the conference. The
following sub elements provide human-readable text descriptions about
the conference: <list style="hanging">
<t hangText="<display-text>:">Contains a short textual
description about the conference</t>
<t hangText="<subject>:">Contains the subject of the
conference</t>
<t hangText="<free-text>:">Contains a longer textual
description about the conference</t>
<t hangText="<keywords>:">Contains a list of keywords that
match the conference topic. The XML schema definition and semantic
is imported from the 'conference-info' event package <xref
target="RFC4575"></xref>.</t>
</list></t>
<t>The <service-uris> sub element enables focus peers to
advertise auxiliary services for the conference. The XML schema
definition and semantic is imported from the 'conference-info' event
package <xref target="RFC4575"></xref>.</t>
<t>The <conference-description> element uses the 'state' Element
Key to enable the partial notification mechanism.</t>
</section>
<section anchor="subsec-xml-f" title="<focus>">
<t>Each <focus> element describes a focus peer actively
controlling the conference. It provides general information about a
focus peer (e.g., display-text, languages, etc.), contains conference
specific information about the state of a focus peer (user-count,
available media types, etc.) and announces signaling and media
information about the maintained participants. Additionally, it
describes signaling or media relations to further focus peers.</t>
<t>The <focus> element uses the following attributes: <list
style="hanging">
<t hangText="entity:">This attribute contains the user name of the
RELOAD peer acting as focus peer. It uniquely identifies the focus
peer that is allowed to update or change all sub elements of
<focus>. All other focus peers SHOULD NOT update or change
sub elements of this <focus> element. A SUBSCRIBE request
addressed to the user name initiates a conference state
synchronization with the focus peer.</t>
<t hangText="Node-ID">This attributed contains the Node-ID of the
peer acting as conference focus</t>
<t hangText="state:">In accordance to <xref
target="RFC4575"></xref>, this attribute indicates whether the
content of the <focus> element is a 'full', 'partial' or
'deleted' information. A 'partial' notification contains at
maximum a single <focus> element.</t>
</list></t>
<t>The following sub elements of <focus> provide general
information about a focus peer: <list style="hanging">
<t hangText="<display-text>:">Contains a short text
description of the user acting as focus peer.</t>
<t hangText="<associated-aors>:">This element contains
additional URIs that are associated with this user.</t>
<t hangText="<roles:>">This element MAY contain
human-readable text descriptions about the roles of the user in
the conference.</t>
<t hangText="<languages>:">This element contains a list of
tokens, each describing a language understood by the user.</t>
</list> The XML schema definition and semantic for
<associated-aors>, <roles> and <languages> are
imported from the 'conference-info' event package <xref
target="RFC4575"></xref></t>
<t>Following, a detailed description of the remaining sub
elements.</t>
<section anchor="subsubsec-xml-fs" title="<focus-state>">
<t>The <focus-state> element aggregates a set of conference
specific information about the RELOAD user acting as focus peer. The
following attribute is defined for the <focus-state> element:
<list style="hanging">
<t hangText="status:">This attribute indicates whether the
content of the <focus-state> element is a 'full',
'partial' or 'deleted' information.</t>
</list></t>
<t>The <focus-state> element has the following sub elements:
<list style="hanging">
<t hangText="<user-count>:">This element contains the
number of participants that are connected to the conference via
this focus peer at a certain moment.</t>
<t hangText="<coordinate>">This element contains the
coordinate value <xref target="subsec-kds"></xref> of the focus
peer</t>
<t hangText="<maximum-user-count>:">This number indicates
a threshold of participants a focus peer is able to serve. This
value might change during a conference, depending on the focus
peers current load.</t>
<t hangText="<conf-uris>:">This element MAY contain other
conference URIs in order to access the conference via different
signaling means. The XML schema definition and semantic is
imported from <xref target="RFC4575"></xref>.</t>
<t hangText="<available-media>:">This element is imports
the <conference-media-type> type XML scheme definitions
from <xref target="RFC4575"></xref>. It allows a focus peer to
list its available media streams.</t>
<t hangText="<active>:">This boolean element indicates
whether a focus peer is currently active. Conference
participation requests or a call delegation request SHOULD
succeed.</t>
<t hangText="<locked>:">In contrast to <active>,
this element indicates that a focus peer is not willing to
accept anymore participation or call delegation request.</t>
</list></t>
</section>
<section anchor="subsubsec-xml-uu" title="<users>/<user>">
<t>The <users>, respectively, each <user> element
describes a single participant that is maintained by the focus peer
described by the parent <focus> element. The <users>
element XML schema definition and its semantic is imported from the
'conference-info' event package <xref target="RFC4575"></xref>.</t>
</section>
<section anchor="subsubsec-xml-rr"
title="<relations>/<relation>">
<t>The <relations> element serves as container for
<relation> elements, each describing a specific connection to
another focus peer. The parent element <relations> uses the
'state' attribute to enable the partial notification mechanism. For
the <relation> element the following attributes are defined:
<list style="hanging">
<t hangText="entity:">This attribute contains the user name of
the remote focus.</t>
<t hangText="node-id">This attribute contains the Node-ID of the
remote focus peer.</t>
</list></t>
<t>The content of each <relation> is a comma separated string
that describes the tuple <CONNECTION-TYPE:IDENTIFIER>. The
CONNECTION-TYPE is a string token describing the type of connection
(e.g. media, signaling, etc.) and the IDENTIFIER contains a variable
connection identifier. It is a generic method to announce any kind
of connection to a remote focus. This specification defines
following tuples: <list style="hanging">
<t hangText="media:<label>:">This tuple identifies a
single media stream. The 'label' variable contains the SDP
"label" attribute. (see <xref target="RFC4574"></xref>).</t>
<t hangText="sync:<call-id>:">This tuple indicates a
subscription for the Event Package for Distributed Conferences.
The 'call-id' variable contains the call-id of the SIP
subscription dialog.</t>
</list></t>
</section>
</section>
<section anchor="subsec-dce" title="Distribution of Change Events">
<t>Each focus peer in a distributed conference must be able to
retrieve all change events from all other focus peers. A simple
approach would be to inter-connect each focus with all other focus in
a full meshed topology. To avoid a full mesh, this document describes
a 'mutual' subscription scheme that constructs a spanning tree
topology among the focus peers.</t>
<t>A conference participant that becomes a focus peer MUST send a SIP
SUBSCRIBE to request the Event Package for Distributed Conferences to
its own focus peer. The subscription request is addressed to user name
of the active focus peer. The latter interprets this subscription as a
request for conference state synchronization. The corresponding NOTIFY
message contains a 'full' distributed-conference state XML document
(see section Section <xref target="subsec-epo"></xref>).</t>
<t>The subscribed focus peer in turn subscribes the upcoming focus
peer for the distributed conference event package. The corresponding
NOTIFY message carries a 'partial' conference state XML document. It
contains the received <version-vector> including a new
<version> element for itself and a new <focus> element
that describes its local state (see <xref
target="subsec-xml-f"></xref>).</t>
<t>Resulting by this subscription scheme, each focus peer has at least
one subscription to obtain updates for the conference state and is a
notifier for change events originated itself. In a incrementally
increasing conference, the 1st and 2nd focus peer have a mutual
subscription for conference change events. A 3rd focus could have a
mutual subscription with the 1st focus, a 4th focus to the 2nd focus
and so forth. The result is a spanning tree topology among the focus
peers in which each focus peer is a possible root for distribution
tree for conference change events.</t>
<t>However, the fact that event notifications need to traverse one or
more intermediate focus peers until conference-wide delivery, demands
a forwarding mechanism for change events. On receiving a change event,
a notified focus validates based on the <version-vector> whether
the incoming state event is not a duplicate to previews notifications.
If its not a duplicate, the received change event triggers a new event
notification at the receiver of the change event. It notifies all its
subscribers with excepting the sender of the event notification. In
this way, the change event will be 'flooded' among the focus peer of a
conference.</t>
</section>
<section anchor="subsec-ttcep"
title="Translation to Conference-Info Event Package">
<t>The Event Package for Distributed Conferences imports several XML
element definitions of the Event Package for Conference State <xref
target="RFC4575"></xref>. This is caused by two reasons. First, the
semantic of these elements are fitting the demands to describe the
global state of a distributed conference and, second, it facilitates a
re-translation to <xref target="RFC4575"></xref> to enable a backward
compatibility to DisCo-unaware clients. Therefore, each focus peer MAY
provide a separate <xref target="RFC4575"></xref> conform event
notification service to its connected participants.</t>
<t>The following sections describe the translation to the Event
Package for Conference State <xref target="RFC4575"></xref> by
defining translation rules for the root element and its direct sub
elements. For a better understanding, the following sections use a
notation ci.<ELEMENT> to refer to a sub element of the
conference-info element, and disco.<ELEMENT> to refer to an
element of the distributed-conference event package.</t>
<section anchor="subsubsec-xml-ci" title="<conference-info>">
<t>The root element of Event Package for Conference State uses the
attributes 'entity', 'state' and 'version' and is the counterpart of
the <distributed-conference> root element in the DisCo Event
Package. The former two attributes 'entity' and 'state' are equal in
both root elements and can be seamlessly translated.</t>
<t>According to <xref target="RFC4575"></xref>, the 'version'
attribute SHOULD be incremented by one at any time a new
notification being sent to a subscriber. Hence, in DisCo the
'version' attributed increments with each change event that
originated by focus peer and each reception of a change events of
remote focus peer.</t>
</section>
<section anchor="subsubsec-xml-cicd"
title="<conference-description>">
<t>The <conference-description> element exists in both event
packages, conference-info and distributed-conference. Thus, the
following elements are seamlessly translatable: <keywords>,
<display-text>, <subject>, <free-text> and
<service-uris>.</t>
<t>The sub elements <conf-uris>, <maximum-user-count>
and <available-media> in conference-info have there
counterparts below the \focus\focus-state element of the
distributed-conference event package. Each describes a local state
of a focus peer in the conference. Hence, the intersection of every
disco.<conf-uris>, disco.<available-media> and the sum
over each disco.<maximum-user-count> element of each
disco.<focus> element in distributed-conference, specifies the
content of the corresponding conference-info elements.</t>
</section>
<section anchor="subsubsec-xml-hi" title="<host-info>">
<t>According to <xref target="RFC4575"></xref> the
ci.<host-info> element contains information about the entity
hosting the conference. For participants in a distributed
conference, the hosting entity is their focus peer. Thus, the
ci.<host-info> element contains information about a focus
peer.</t>
</section>
<section anchor="subsubsec-xml-cs" title="<conference-state>">
<t>The ci.<conference-state> element allows subscribers obtain
information about overall state of a conference. Its sub elements
ci.<user-count>, ci.<active> and ci.<locked> are
reused as sub elements of \focus\focus-state to describe the local
state of a focus peer in a distributed conference. The translation
rules from the distributed-conference to the conference-info event
package are the following: <list style="hanging">
<t hangText="<user-count>:">The sum over each value of the
disco.<user-count> element defines the corresponding
ci.<user-count>.</t>
<t hangText="<active>:">The boolean ci.<active>
element is the logical concatenation over all
disco.<active> elements by an OR-operator.</t>
<t hangText="<locked>">The boolean ci.<locked>
element is the logical concatenation over all
disco.<locked> elements by an AND-operator.</t>
</list></t>
</section>
<section anchor="subsubsec-xml-ciuu"
title="<users>/<user>">
<t>The distributed-conference event package imports the definitions
of the ci.<users> and ci.<user> elements under a parent
disco.<focus> element for each focus peer in a conference.
Thus, the aggregation over all disco.<users> elements
specifies the content of the corresponding ci.<users>
element.</t>
</section>
<section anchor="subsubsec-xml-sbrsbv"
title="<sidebars-by-ref>/<sidebars-by-value>">
<t>In accordance to <xref target="RFC4575"></xref>, if a participant
is connected to a sidebar, its responsible focus peer creates a new
<user> by referencing to the corresponding sidebar
conference.</t>
</section>
</section>
</section>
<section anchor="sec-dcco" title="Distributed Conference Control with SIP">
<t>Distributed conference control with SIP defined in this document
refers to multiparty conversation in a tightly coupled model that is
controlled by several independent entities. It enables a resilient
conferencing service for P2P scenarios and provides mechanisms for
load-balancing among the focus peers. This section describes additional
control operations for distributed conferences with SIP.</t>
<section anchor="subsec-cd" title="Call delegation">
<t>Distributed conference control enables load-balancing by a
mechanism for call delegation. Call delegations are performed by focus
peers that are running out of capacities to serve more participants.
Incoming participation requests are then transferred to other
established focus peer or conference participants that are registered
as potential focus peers in the overlay. Call delegations use SIP
REFER requests <xref target="RFC3515"></xref> that contain additional
session information and are achieved transparently to the transferred
party.</t>
<t>A focus peer initiates a call delegation by sending SIP REFER
request containing the URI of the participant in the Refer-To header
field. Additionally, the focus peer appends the following parameter to
the URI of the participant: <list style="hanging">
<t hangText="call-id:">Contains the call-ID of the initial SIP
dialog between the referred participant and the referring focus
peer.</t>
<t hangText="sess-id:">Contains the 'session identifier' value of
the original SDP 'o=' field of the original offer/answer process
between referred participant and referring focus peer.</t>
</list> If the recipient accepts the REFER request, it generates a
re-INVITE towards the referred party and sets the SIP call-id header
and the SDP 'session-identifier' field in the SDP offer, according to
the URI parameter values of the initial REFER request. The From header
field and contact header are set to the conference URI with setting
the 'isfocus' tag to contact header. This identifies the peer as a
focus to the conference and identifies this re-INVITE as a request of
the SIP dialog between the party and the conference. To ensure that
further signaling messages will be routed correctly, the new focus
adds a Record-Route header field that contains its contact information
(URI, IP-address,..).</t>
<t>An example call flow for call delegation is shown in <xref
target="fig-sip-refer-inv-cf"></xref>.</t>
<figure align="center" anchor="fig-sip-refer-inv-cf"
suppress-title="false"
title="Delegating a participant with SIP REFER">
<artwork align="center" xml:space="preserve"><![CDATA[
Participant Referring Focus Remote Focus
--------------------------------------------------------------------
| Dialog | |
|<============>| |
| | |
| Delegating a participant to remote focus |
| | |
| |(1) REFER refer-to:<uri>?call-id=123&sess-id=456
| |------------------------------------>|
| |(2) 200 OK |
| |<------------------------------------|
| |(3) Notify: pending |
| |<------------------------------------|
| |(4) 200 OK |
| |------------------------------------>|
| | |
| Remote focus adds RR-header that carries its URI |
| | |
| (5) INVITE sip:<uri> record-route:<rem.focus> |
|<---------------------------------------------------|
| (6) 200 OK | |
|--------------------------------------------------->|
| (7) ACK | |
|<---------------------------------------------------|
| |(8) Notify: active |
| |<------------------------------------|
| |(9) 200 OK |
| |------------------------------------>|
]]></artwork>
</figure>
<t>Note, subscriptions for the event packages 'distributed-conference'
and 'conference-info' are in scope of a specific focus peer and its
connected participants. Hence, after a successful call delegation, the
referring focus peer SHOULD terminate any subscription to the referred
participant. The notifier SHOULD include a reason parameter
"deactivated" to indicate a migration of the subscription as defined
in <xref target="RFC3265"></xref>. The new SUBSCRIBE request by the
party MUST be sent via the SIP dialog to the conference.</t>
</section>
<section anchor="subsec-ls" title="Conference Access">
<t>A conference policy defines who is allowed to participate in a
multimedia conference. In many cases, a group conversation can be an
open discussion free to participate, while in other occasions a closed
privacy of a multiparty session is demanded. In distributed
conferences, it is also an issue which of the conference participants
is allowed to become a controller of the multiparty session.</t>
<t>Thus it must be decided whether: <list style="symbols">
<t>A peer is allowed to participate in a conference</t>
<t>A peer is allowed to become a focus of the conference</t>
</list> Standard SIP authentication mechanisms can be used to
authenticate and accordingly authorize joining participants.</t>
<!--
Both cases can be regulated with plain SIP authorization
mechanisms achieved by the focus peers asking for a participants
credentials. Those credentials and the allowed users can be setup at
creation of the conference. -->
<!--It is up to the conference to define
different access role deciding if a user is allowed to become a focus
peer or not.</t>
-->
</section>
<section anchor="subsec-mnad" title="Media Negotiation and Distribution">
<t>This section describes a basic scheme for media negotiation and
distribution, which is done in an ad-hoc fashion.</t>
<t>In an established DisCo conference, each participant is attached to
one focus (possibly itself), and all focus peers maintain mutual
signaling relationships. Each focus peer receives media streams from
two groups, its locally attached members, as well as the neighboring
focus peers. It has two options when re-distributing media streams to
the conference. It either mixes streams from each group and thus
reduces the number of media sessions, or propagates the streams in
individual media sessions.</t>
<t>The basic media distribution naturally follows the SIP signaling
paths. Each focus peer forwards all media streams it receives from the
conference (possibly mixed) to all connected peers it is responsible
for, and similarly all streams from its peers to its responsible
focus. Implementations can choose more sophisticated schemes for media
distribution, e.g., some form of overlay multicast, but MUST take
measures to prevent loops in media routing.</t>
<section anchor="subsec-oa" title="Offer/Answer">
<t>A peer joining a conference negotiates media types and media
parameters with its designated focus using the standard SDP offer/
answer protocol <xref target="RFC3264"></xref>. The focus SHOULD
offer all existing media streams that it receives from the
conference.</t>
<t>A new participant does not necessarily know about all media
streams present in a conference beforehand, and thus some of the
media streams might not be included in the initial SDP offer sent by
the joining peer. An SDP answer sent by the corresponding focus
though cannot offer additional media types that do not match an
offer (cf. <xref target="RFC3264"></xref> Section 6). A joining
peer, which is aware of a heterogeneous conference, can invert the
offer/answer dialog by omitting an SDP offer in the initial INVITE
message. Instead it MAY send an empty INVITE to which the focus
replies with an OK, containing the SDP offer. This prevents the need
for a second offer/answer-dialog to modify the session. But for
compatibility the normal behavior with the INVITE containing the
offer MUST be supported.</t>
<t>For new media streams (e.g. those sent by the new participant),
the focus SHOULD only offer media types and codecs which are already
used in the conference and which will probably be accepted when
forwarded to neighboring peers, unless the focus is prepared to do
transcoding and/or mixing of the received streams.</t>
</section>
<section title="New Peers Joining">
<t>When a new peer has been attached to a focus, new media streams
may be available to the focus that need to be forwarded to the
conference. To accomplish this, the new media streams need to be
signalled to the other participants. This is commonly done by
sending a SIP re-INVITE <xref target="RFC4353"></xref> for modifying
the media sessions, adding the new streams to the SDP. This
renegotiation can be costly since it needs to be propagated
throughout the entire conference. In addition, distributing all
media streams separately to all participants can be quite bandwidth
intensive. Both problems can partially be mitigated by focus peers
performing mixing of media streams, thus trading bandwidth and
signalling overheads for computational load on focus peers.</t>
</section>
</section>
<section anchor="subsec-rac" title="Restructuring a Conference">
<t>Distributed conference control provides the possibility to delegate
calls to remote focus peers. This feature is used to restructure a
conference in case of departure of a focus peer. Following, this
section presents restructuring schemes for graceful and unexpected
leaves of conference focus peers.</t>
<section anchor="subsubsec-ogl" title="On Graceful Leave">
<t>In a graceful case, the leaving focus peer (LP) accomplishes the
following procedure: <list style="symbols">
<t>LP deletes its mapping in the DisCo-Registration by storing
the "non-existing" value as described in the RELOAD base
document <xref target="I-D.ietf-p2psip-base"></xref>.
Afterwards, it fetches the lasted version of the
DisCo-Registration to obtain all potential focus peers.</t>
<t>LP calculates for all its participants the closest focus
among all active and potential focus peer using the algorithm
described in <xref target="subsec-dc"></xref>. LP then delegates
all participants to those focus peers.</t>
<t>LP then announces its leave by sending a NOTIFY to all its
subscribers for the extended conference event package, setting
its <focus> state to 'deleted'. Thereafter, it ends its
own SIP conference dialog by sending by to its related focus
peer.</t>
</list></t>
<t>Since the state synchronization topology in a distributed
conference is commonly arranged in a spanning tree, a leave of a
focus peer effects a gab in the tree structure. Those focus peers
which had the leaving focus peer as their parent, are supposed to
reconnect to the synchronization graph by subscribing the parent
focus of the leaving peer.</t>
</section>
<section anchor="subsubsec-oul" title="On Unexpected Leave">
<t>If an unexpected leave is detected by a participant (e.g. missing
signaling and/or media packets) it MUST repeat the joining procedure
as described in <xref target="subsec-pcp"></xref>.</t>
</section>
</section>
</section>
<section title="DisCo Kind Definition">
<t>This section formally defines the DisCo kind.</t>
<figure align="center" suppress-title="true">
<artwork align="center"><![CDATA[
Name
DISCO-REGISTRATION
Kind IDs
The Resource name DISCO-REGISTRATION Kind-ID is the AoR of the
conference. The data stored is the DisCoRegistrationData, that
contains the Node-ID of a peer acting as a focus for the
conference and optionally a coordinates value describing a
peer's relative network position.
Data Model
The data model for the DISCO-REGISTRATION Kind-ID is dictionary.
The dictionary key is the Node-ID of the peer action as focus.
Access Control
USER-CHAIN-ACL]]></artwork>
</figure>
<t>The data stored for the Kind-ID DISCO-REGISTRATION is of type
DisCoRegistration. It contains a "coordinates" value, that describes the
peers relative network position and the Node-ID of the registered focus
peer.</t>
</section>
<section anchor="sec-xmls" title="XML Schema">
<t>The XML schema for the event package for distributed conferences
is:</t>
<figure align="center" anchor="fig-inet-ci-multifocus"
suppress-title="true">
<artwork align="center" xml:space="preserve"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ci="urn:ietf:params:xml:ns:conference-info"
xmlns="urn:ietf:params:xml:ns:distributed-conference"
targetNamespace="urn:ietf:params:xml:ns:distributed-conference"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!--
This imports the definitions in conference-info
-->
<xs:import namespace="urn:ietf:params:xml:ns:conference-info"
schemaLocation="http://www.iana.org/assignments/xml-registry/
schema/conference-info.xsd"/>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<!--
A DISTRIBUTED CONFERENCE ELEMENT
-->
<xs:element name="distributed-conference"
type="distributed-conference-type"/>
<!--
DISTRIBUTED CONFERENCE TYPE
-->
<xs:complexType name="distributed-conference-type">
<xs:sequence>
<xs:element name="version-vector"
type="version-vector-type" minOccurs="1"/>
<xs:element name="conference-description"
type="conference-description-type"
minOccurs="0" maxOccurs="1"/>
<xs:element name="focus"
type="focus-type"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:sequence>
<xs:attribute name="state" type="ci:state-type"/>
<xs:attribute name="entity" type="xs:anyURI"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
VERSION VECTOR TYPE
-->
<xs:complexType name="version-vector-type">
<xs:sequence>
<xs:element name="version"
type="version-type"
minOccurs="1"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CONFERENCE DESCRIPTION TYPE
-->
<xs:complexType name="conference-description-type">
<xs:sequence>
<xs:element name="display-text"
type="xs:string" minOccurs="0"/>
<xs:element name="subject" type="xs:string" minOccurs="0"/>
<xs:element name="free" type="xs:string" minOccurs="0"/>
<xs:element name="keywords"
type="ci:keywords-type" minOccurs="0"/>
<xs:element name="service-uris"
type="ci:uris-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:sequence>
<xs:attribute name="state" type="ci:state-type"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
FOCUS TYPE
-->
<xs:complexType name="focus-type">
<xs:sequence>
<xs:element name="display-text"
type="xs:string" minOccurs="0"/>
<xs:element name="associated-aors"
type="ci:uris-type" minOccurs="0"/>
<xs:element name="roles"
type="ci:user-roles-type" minOccurs="0"/>
<xs:element name="languages"
type="ci:user-languages-type" minOccurs="0"/>
<xs:element name="focus-state"
type="focus-state-type" minOccurs="0"/>
<xs:element name="users"
type="ci:users-type" minOccurs="0"/>
<xs:element name="relations"
type="relations-type" minOccurs="0"/>
<xs:any namespace="#other" processContents="lax"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI"/>
<xs:attribute name="node-id" type="xs:string"/>
<xs:attribute name="state" type="ci:state-type"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
VERSION TYPE
-->
<xs:complexType name="version-type">
<xs:simpleContent>
<xs:extension base="xs:unsignedInt">
<xs:attribute name="entity" type="xs:anyURI"/>
<xs:attribute name="node-id" type="xs:string"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!--
FOCUS STATE TYPE
-->
<xs:complexType name="focus-state-type">
<xs:sequence>
<xs:element name="user-count"
type="xs:unsignedInt" minOccurs="0"/>
<xs:element name="coordinate"
type="xs:string" minOccurs="0"/>
<xs:element name="maximal-user-count"
type="xs:unsignedInt" minOccurs="0"/>
<xs:element name="conf-uris"
type="ci:uris-type" minOccurs="0"/>
<xs:element name="available-media"
type="ci:conference-media-type" minOccurs="0"/>
<xs:element name="active" type="xs:boolean" minOccurs="0"/>
<xs:element name="locked" type="xs:boolean" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:sequence>
<xs:attribute name="state" type="ci:state-type"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
RELATIONS TYPE
-->
<xs:complexType name="relations-type">
<xs:sequence>
<xs:element name="relation"
type="relation-type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:sequence>
<xs:attribute name="state" type="ci:state-type"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
RELATION TYPE
-->
<xs:complexType name="relation-type">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="entity" type="xs:anyURI"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>]]></artwork>
</figure>
</section>
<section anchor="sec-rngg" title="Relax NG Grammar">
<t>The grammar for the Landmark configuration document extension is:</t>
<figure align="left" anchor="fig-le" suppress-title="true">
<artwork align="left" xml:space="preserve"><![CDATA[
<!--
LANDMARKS ELEMENT
-->
parameter &= element landmarks {
attribute version { xsd:int }
<!--
LANDMARK-HOST ELEMENT
-->
element landmark-host {
attribute address { xsd:string },
attribute port { xsd:int }
}*
}?]]></artwork>
</figure>
</section>
<section title="Security Considerations">
<section anchor="subsec-ta" title="Trust Aspects">
<t>TODO</t>
</section>
</section>
<section title="IANA Considerations">
<t>TODO: register Kind-ID code point at the IANA</t>
</section>
<section title="Acknowledgments">
<t>This work was stimulated by fruitful discussions in the P2PSIP
working group and SAM research group. We would like to thank all active
members for constructive thoughts and feedback. In particular, the
authors would like to thank (in alphabetical order) David Bryan,
Toerless Eckert, Lothar Grimm, Cullen Jennings, Peter Musgrave, Joerg
Ott, Peter Pogrzeba, Brian Rosen, and Jan Seedorf.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.RFC.3265"?>
<?rfc include="reference.RFC.3515"?>
<?rfc include="reference.RFC.4574"?>
<?rfc include="reference.RFC.4648"?>
<?rfc include="reference.RFC.4575"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.I-D.ietf-p2psip-base"?>
<?rfc include="reference.I-D.knauf-p2psip-share"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-p2psip-concepts"?>
<?rfc include="reference.RFC.4353"?>
<?rfc include="reference.I-D.ietf-p2psip-sip"?>
<reference anchor="timestamps-acsc88">
<front>
<title abbrev="f-tmspp-88">Timestamps in Message-Passing Systems
that Preserve the Partial Ordering</title>
<author fullname="Collin J. Fidge" initials="C." surname="Fidge"></author>
<date month="February" year="1988" />
</front>
<seriesInfo name="Proceedings of 11th Australian Computer Science Conference,"
value="pp. 56-66" />
</reference>
<reference anchor="landmarks-infocomm02">
<front>
<title>Topologically-Aware Overlay Construction and Server
Selection</title>
<author fullname="Syliva Ratnasamy" surname="Ratnasamy"></author>
<author fullname="Mark Handley" surname="Handley"></author>
<author fullname="Richard Karp" surname="Karp"></author>
<author fullname="Scott Shenker" surname="Shenker"></author>
<date year="2002" />
</front>
<seriesInfo name="Proc. of 21st Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM '02)"
value="pp. 1190-1199" />
<!-- wo kommt erscheinungsort hin? Washington, DC, USA -->
</reference>
</references>
<section title="Change Log">
<t>The following changes have been made from version
draft-knauf-p2psip-disco-04.<list style="numbers">
<t>Editorial improvements.</t>
<t>Updated references.</t>
</list></t>
<t>The following changes have been made from version
draft-knauf-p2psip-disco-03.<list style="numbers">
<t>Adapted mechanisms for storing DisCo-Registrations to new
requirements of Shared Resources draft <xref
target="I-D.knauf-p2psip-share"></xref></t>
</list></t>
<t>The following changes have been made from version
draft-knauf-p2psip-disco-02.<list style="numbers">
<t>DisCo-Registration uses now only the USER-CHAIN-ACL access
control policy.</t>
<t>Adapted mechanisms for storing DisCo-Registrations to new
requirements of Shared Resources draft <xref
target="I-D.knauf-p2psip-share"></xref></t>
</list></t>
<t>The following changes have been made from version
draft-knauf-p2psip-disco-01.<list style="numbers">
<t>The conference registration is now based on the Shared Resources
draft <xref target="I-D.knauf-p2psip-share"></xref>: <list
style="symbols">
<t>DisCo-Registration Kind now meets the requirements for
ShaRe.</t>
<t>Conference creation procedure now uses the ShaRe Access
List.</t>
<t>Replaced USER-CHAIN-MATCH access policy for
DisCo-Registration. Now uses USER-CHAIN-ACL or
USER-PATTERN-MATCH.</t>
</list></t>
<t>Allow focus peers behind NAT</t>
<t>Added a 'node-id' attribute to the event package XML
<version> element.</t>
<t>Added a 'node-id' attribute to the event package XML
<focus> element.</t>
<t>Added a 'coordinate' child element to the event package XML
<focus> element.</t>
<t>Corrected typos/wording</t>
</list></t>
<t>The following changes have been made from version
draft-knauf-p2psip-disco-00. <list style="numbers">
<t>Updated references.</t>
<t>Corrected typos.</t>
<t>New Section: Conference State Synchronization</t>
<t>XML Event Package for Distributed Conferences</t>
<t>New mechanism for generating chained conference certificates</t>
<t>Allow shared writing of resources using Access Control Policy
USER-CHAIN-MATCH</t>
<t>Media Negotiation mechanism in a distributed conference</t>
<t>New Section: Distributed Conference Control with SIP</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:21:45 |