One document matched: draft-knauf-p2psip-disco-01.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-knauf-p2psip-disco-01" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?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>alexander.knauf@haw-hamburg.de</email>
<uri>http://inet.cpt.haw-hamburg.de/members/knauf</uri>
</address>
</author>
<author fullname="Gabriel Hege" initials="G." surname="Hege">
<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>hege@fhtw-berlin.de</email>
<uri>http://inet.cpt.haw-hamburg.de/members/hege</uri>
</address>
</author>
<author fullname="Thomas C. Schmidt" initials="T C." surname="Schmidt">
<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="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 day="30" month="December" year="2010" />
<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. The document also
introduces methods to establish security and trust for a shared resource
access, as well as for compatibility with conference unaware
clients.</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 protocol scheme for distributed conference control</t>
<t>RELOAD Usage and definition of conferencing Kind</t>
<t>RELOAD Usage and definition of a Kind for shared Resources in
RELOAD</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>
<t>Methods of establishing security and trust for shared resource
access</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 the demands for distributed conferences. The
'DisCo' data structure stores the mapping of a single conference to
multiple conference controllers and thereby separates the conference URI
from focus instantiations.</t>
<t>Authorized controllers of a conference are permitted to register
their mapping into the DisCo data structure independently. 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 defines a Usage to share a specific RELOAD Resource. A RELOAD
user explicitly authorizes RELOAD peers within a RELOAD Kind data
structure called 'access list'.</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>The terminology and definitions from der RELOAD base <xref
target="I-D.ietf-p2psip-base"> </xref>, the peer-to-peer SIP concepts
draft <xref target="I-D.ietf-p2psip-concepts"></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 multiparty manager for
the RELOAD peer C and the plain SIP user agent E whereas focus peer B
serves 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, 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 establish 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[ +----------+
|DisCo Data|
+----------+
/
+-------+
|Storing|
# # # # # # # # # # | Peer | # # # # # # # # # #
# | O | #
# +-------+ #
# #
# #
# #
+----+ +----+
|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
(Address-of-Record or Destination List) in the RELOAD overlay as a
DisCo-Registration Kind (cf., <xref format="default"
target="fig-overview-cf"></xref>). The hashed conference URI is used
as the Resource-ID. This data structure will later contain the contact
IDs of all potential focus peers including optionally 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 retrieves the list of potential focus peers stored in the
DisCo-Registration under the conference's Resource-ID. To join the
conference it selects any of the focus peers (e.g., Alice) and
establishes a connection using AppAttach. 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 to contact can optionally be
based on proximity information if available.</t>
<t>A conference member proposes as a focus for subsequent participants
by storing a mapping of the conference URI to his Address-of-Record or
Destination List in the RELOAD overlay in the DisCo-Registration data
structure. This decision should incorporate 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) | |
|------------------------------>| |
| | Lookup ConfURI |
| |<------------------------------|
| | Result ConfURI |
| |------------------------------>|
| | |
| 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 conference focus peers. In
DisCo, state synchronization is based on a SIP specific event
notifications mechanism <xref target="RFC3265"></xref>.</t>
<t>Each focus peer can complete its view of the entire conference
state among the focus peers by subscribing the other focus peers for
an XML event package for distributed conferences. It is defined in
this document (see section <xref target="sec-css"></xref>) and is
based on the event package for conference state <xref
target="RFC4575"></xref>. Receivers of event notifications update
their local conference state document to regain a valid view of
current 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 allow views of the
responsibilities of any focus peer in the conference. By providing
these views 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>The call delegation (see <xref target="subsec-dc"> </xref>.) is a
feature used to transfer an incoming participation request to another
focus peer. It can be applied to prevent an overloading of focus peers
reaching its limit of serving new clients. Call delegation is realized
through SIP REFER requests, which carry signaling and session
description information of the callee to be transferred. A focus peer
can decide to refer an incoming call to a less loaded remote focus.
This feature is achieved transparently to 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, a loss of the conference
controller or the media distributor would cause a complete fail of the
multiparty conversation. Distributed conferencing uses the redundancy
by multiple focus peers to reconfigure a running multiparty.
Participants that lost their entry point to the conference re-invite
itself via the remaining focus peers or will be re-invited by the
controllers. This option is based on the conference state and call
delegation functions.</t>
</section>
<section anchor="subsubsec-tatl" title="Topology Awareness">
<t>DisCo supports landmarking approaches based on an extension for the
RELOAD XML configuration document (see <xref
target="subsec-cde"></xref>) to construct topology-aware connections
between focus and peers. 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 as 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 title="Kind Data Structure">
<t>Each DisCo-Registration data structure stores mappings for one
conference instance to many focus peers and for each focus peer the
related coordinates value. The data structure uses the RELOAD
dictionary type whereas the DictionaryKey value is the Node-ID of the
focus peer behind the dictionary entry. This allows a focus peer to
update it mapping. The DisCo data structure of type DisCoRegistration
is shown as follows:</t>
<figure align="center" suppress-title="true">
<artwork align="left" xml:space="preserve"><![CDATA[
enum {
sip_focus_uri (1),
sip_focus_node_id (2), (255)
} DisCoRegistrationtType;
struct {
opaque coordinate<0..2^16-1>
select (DisCoRegistrationtType.type) {
case sip_focus_uri:
opaque uri<0..2^16-1>
case sip_focus_node_id:
Destination destination_list<0..2^16-1>
/* This type can be extended */
}
} DisCoRegistrationData;
struct {
DisCoRegistrationtType type;
uint16 length;
DisCoRegistrationData data;
} DisCoRegistration;]]></artwork>
</figure>
<t>The content of the DisCoRegistrationData structure are as
follows:</t>
<figure align="center" suppress-title="true">
<artwork align="center" xml:space="preserve"><![CDATA[type
type of the registration
length
the length of the registration PDU
data
the conference registration data]]></artwork>
</figure>
<t><list counter="2" style="symbols">
<t>If the DisCoRegistration is set to "sip_focus_uri", then it
contains an Address-of-Record (AoR) as an opaque string and opaque
"coordinates" string, that describes the relative network
position. See more in section 4.4.</t>
<t>If registration type is set to "sip_focus_node" then it
contains the Destination list for the peer and an opaque string
"coordinates" describing the focus' relative network position.</t>
</list></t>
<t>The structure is designed for enabling a peer to contact a focus of
the conference that is the nearest to itself. A joining peer MAY
select the focus peer, whose coordinate value matches at most to its
own. In this manner it reduces the problem of triangle inequality as
without this feature a joining peer could choose an inadequate remote
conference controller causing large signaling and may streaming
delays.</t>
</section>
<section anchor="subsec-dc" title="Determining Coordinates">
<t>Each RELOAD peer within the context of a distributed conference MAY
be aware of it's relative position in the network topology. Those
position information can support a topology-aware conference
construction avoiding long signaling and media delays. Providing this
the Usage for distributed conference foresees the coordinates value
within the DisCo-Registration data structure that allows focus peers
to store a topological descriptor. It is a generic field that
describes a peer's relative position in the network. Focus peers store
this coordinate value together with their announcement as conference
focus. Joining peers likewise MAY determine their coordinates value
and then select a focus peer whose relative position matches at most
(see section <xref target="subsec-pcp"></xref>).</t>
<t>Many algorithms determine topology information by measuring
Round-Trip Times (RTT) towards a set on hosts serving as so called
landmarks. To support such algorithms this document describes an
extension to the RELOAD XML configuration document that allows to
configure the set of Landmark hosts that peer must use for position
estimation (see section <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 at conference
join 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-cc" title="Conference Creation">
<t>Before a peer registers to a new distributed conference, it is
RECOMMENDED to ensure the initiating peer has a most up to date copy
of the configuration document. In this way, the conference creator
assures that all joining peers will equally determine their
coordinates value if such a algorithm is used. The first peer that
creates a distributed conference registers it in the RELOAD overlay
following the steps as described in <xref
target="fig-conf-create-cf"></xref>:</t>
<figure align="center" anchor="fig-conf-create-cf"
suppress-title="false"
title="Creation of a Distributed Conference">
<artwork align="center" xml:space="preserve"><![CDATA[
CA Alice Peer1 Overlay PeerN StoringPeer
------------------------------------------------------------
| | StatReq Res:Conf-URI | |
| |---------->|--------->|--------->|--------->|
| | StatAns | | |
| |<----------|<---------|<---------|<---------|
|<==Cert===| | | | |
| | | | | |
|===Cert==>| StoreReq Res:Conf-URI Kinds:DisCo[,SIP] |
| |---------->|--------->|--------->|--------->|
| | StoreAns | | |
| |<----------|<---------|<---------|<---------|
| | | | | |
]]></artwork>
</figure>
<t><list style="numbers">
<t>The peer MAY determine its own coordinate value (if used).</t>
<t>The peer SHOULD probe whether the desired conference URI is
available. It therefore generates the Resource-ID of the
conference URI with the overlay hash function and sends a RELOAD
StatReq towards this address. By the corresponding StatAns
response the peer knows whether the desired URI is occupied by
another a DisCo Kind or even a SIP-Registration Kind <xref
target="I-D.ietf-p2psip-sip"></xref>. If it is, the user MUST
choose another URI and repeat the availability checks. If no other
DisCo or SIP-Registration Kind are stored at this Resource-ID it
proceeds the registration.</t>
<t>Storing a conference registration is similar to registering a
new virtual user that has the conference URI as its
Address-of-Record. Two options for obtaining a conference
certificate are available as detailed in section <xref
target="subsec-conf-cert"></xref>. The first does not require
contacting the enrollment server, but only allows a set of
conference URIs closely related to the registering peer's user
name. The second option allows any form of conference URI but
needs to contact the enrollment server. In both cases the
resulting certificate contains the conference URI as a user
name.</t>
<t>The peer finally registers the DisCo data structure signed with
the private key corresponding to the above certificate by a Store
request towards the storing peer (the owner of the address space
for the Resource-ID of the conference URI).</t>
</list></t>
<t>The additional certificate is needed for 2 major purposes:<list
style="symbols">
<t>It separates the conference creator from the multiparty
instance.</t>
<t>It ensures the conference initiator's privacy. Because the
DisCo data structure will be accessed by many peers using the same
conference private key. If they were using the conference
creators’ key, they were permitted to write non-shared
Resources of the creator.</t>
</list></t>
<t>When the conference creator has obtained the conference certificate
from the enrollment server, it MAY also register the conference URI as
a SIP-Registration Kind as well. In this case, it also MUST sign the
Store request with the private key that matches the certificate
obtained for the conference URI, since the SIP-Registration Kind uses
the USER-NODE-MATCH policy. In case of the conference creator's
departure, the remaining focus peers are permitted to redirect the SIP
mapping to another focus peer still serving the conference. The
SIP-Registration MAY be sent in the same StoreReq as the DisCo
registration.</t>
</section>
<section anchor="subsec-conf-cert"
title="Obtaining a Conference Certificate">
<t>In RELOAD each node uses a certificate to identify itself when
storing data at a specific location. Since the DisCo-Registration
needs to be written by multiple nodes, the private key of a group
certificate is distributed among all authorized focus peers. This
demands the assignment of a certificate for each conference ID which
is used for conferencing matters only. This document describes two
options for obtaining a conference certificate. The method to be used
depends on the desired pattern of the conference ID being
registered.</t>
<t>In both cases the certificate should have a sufficiently short
lifetime to prevent a compromised certificate from being used
continuously. The chance of a conference key leaking and thus being
compromised is much larger than for normal RELOAD certificates, since
the key is shared among the focus peers of a conference.</t>
<section title="Self-generated">
<t>A conference initiator can only register a conference ID that is
derived from the user name defined in it's own certificate, without
contacting an enrollment server. The conference ID must be closely
related to the user name of the creator to prevent malicious peers
not associated with the conference from generating a certificate for
the same name and registering themselves as a focus.</t>
<t>The building scheme for constructing legitimate conference URIs
MUST be specified in the overlay configuration document using a
simple pattern matching scheme.</t>
<figure align="left">
<artwork><![CDATA[
Example:
URI pattern: *-conf-$USER@$DOMAIN
User Name: alice@example.com
XYZ-conf-alice@example.com is allowed
my-pretty-conf-alice@example.com is allowed
alice-conference@example.com is NOT allowed]]></artwork>
</figure>
<t>The conference initiator generates a new public/private key pair
and signs the public key with his own private key, thus generating a
certificate for the conference. The conference certificate contains
the conference URI in the user name field, which MUST comply with
the URI pattern specified for DisCo-conferences in the configuration
document. Any peer validating the certificate MUST traverse the
certificate chain up to the enrollment server and only accept it if
the certificates of the creator and of the enrollment server are
valid. Additionally the user name in the certificate of the creator
MUST match the user name in the conference certificate using the
specified pattern.</t>
<t>This conference certificate is subsequently used to sign all
entries of the DisCo-Registration kind stored in the overlay. It
MUST be accepted by the responsible peer. This results in an
extension of the common USER-MATCH access control policy to
USER-CHAIN-MATCH, specified in <xref
target="sec-acc-contr-pol"></xref>.</t>
<!-- for next revision
<t>TODO: additional kind for certificate revocation? -> stored
under ResourceID of conference, can be used to revoke conference
certificate or certificates for individual focus peers</t>
-->
</section>
<section title="Using Enrollment Server">
<t>An enrollment server MAY issue certificates for conferences with
any URI that is not related to the user name of the conference
initiator.</t>
<t>Therefore a user agent intending to register a new conference
contacts the enrollment server and requests a certificate using the
standard mechanism defined in <xref
target="I-D.ietf-p2psip-base">RELOAD</xref> Section 10.3.</t>
<t>Conferences with certificates obtained from an enrollment server
use the USER-MATCH access control policy for the DisCo-Registration
kind.</t>
<t>The enrollment server MUST NOT reuse the Node-ID of the
conference initiator for the conference certificate, since this
certificate is intended for distribution among the focus peers of a
conference. This would allow the focus peers to compromise any
private resources stored by the initiator using the NODE-MATCH
policy.</t>
</section>
</section>
<section anchor="subsec-pcp"
title="Proximity-aware Conference Participation">
<t>A RELOAD peer intending to join a distributed conference follows
the steps shown in <xref target="fig-conf-join-cf"></xref>:</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 OwnerOfID Alice
--------------------------------------------------------------
| FetchReq Res:Conf-URI Kind:DisCo | |
|--------->|--------->|--------->|--------->| |
| |FetchAns | | | |
|<---------|<---------|<---------|<---------| |
| | | | | |
| Bob calculates Alice as closest Focus | |
| | | | | |
| |AppAttach--application:5060 | |
|--------->|--------->|--------->|--------->|--------->|
| |AppAttach--application:5060 | |
|<---------|<---------|<---------|<---------|<---------|
| | | | | |
|<-------------------ICE Checks----------------------->|
| | | | | |
| | INVITE sip:Alice | |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
| | 200 OK | | |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| | ACK | | |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
| | | | | |
| Optinally, Alice passes writing permission |
| | | | | |
| INFO content:Conf-Key{DisCo-Resource} |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| | | | | |]]></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 FetchReq message for the DisCo Kind to
the Resource-ID that corresponds to the hash over the conference
URI using the overlays hash-function. The FetchReq SHOULD NOT
include any specific dictionary keys thus it will receive all
potential -and active focus peers of the conference.</t>
<t>Once the joining peer received the Fetch results, it calculates
which of the focus peers is the relatively closest to itself.</t>
<t>The focus with the smallest distance MAY be chosen for
establishing a SIP signaling relation.</t>
</list></t>
<t>Depending on which DisCo-Registration type the selected focus has
stored its mapping, the joining Peer has the following 2
possibilities:<list style="numbers">
<t>If the DisCoRegistrationType is sip_focus_node_id, the joining
peer uses RELOADs AppAttach request to establish a direct
transport connection to the selected focus peer. The application
field of the request MUST be set to 5060 indicating for SIP. This
transport connection SHOULD be used to a form an ordinary SIP
dialog. Further media session establishment is achieved by usual
SIP mechanisms.</t>
<t>If the DisCoRegistrationType is sip_focus_uri, the joining peer
MUST use the SIP-Registration <xref
target="I-D.ietf-p2psip-sip"></xref> Usage to resolve the URI and
form connectivity to the selected focus.</t>
</list></t>
<t>Note that in the second case a focus peer can have multiple
locations for its SIP-registration. Therefore a focus MUST assure that
its coordinate value corresponds to its current mapping AoR to
location. If a focus peer has not determined its relative network
position, the coordinates field MUST be left empty.</t>
<t>Regardless of how the focus peer has registered its mapping in the
overlay a joining peer MUST add it's coordinate value base64 encoded
as URI-parameter in the contact-header field of the SIP INVITE
request. An example contact URI is
“sip:alice@example.com;coord=YWxpY2VAZXhhbXBsZS5jb20=”.
The additional parameter is used by the requested focus peer as it is
not capable of serving additional conference participants. It then it
MUST delegate the call (see section <xref target="subsec-dc"></xref>)
to the focus peer whose coordinate value matches next best to the
coordinates of the joining peer. The focus peer therefore uses the
same calculation as described in the joining process.</t>
<t>After the final SIP ACK request completes the signaling relation, a
conference focus MAY passes the writing permission to the new
participant. It therefore sends a SIP INFO request carrying the
conference private key for the DisCo Resource. The decision whether to
pass writing permission depends on the selected security model for the
distributed conference as described in section <xref
target="subsec-ls"></xref>.</t>
</section>
<section anchor="subsec-ada" title="Advertising Focus Ability">
<t>All participants of a distributed conference can become a focus
peer for their conference. The decision can depend on the capacities
of the joining peer like sufficient processing power (CPU, Memory) for
the desired media type and quality of the network connectivity.
Additionally, a peer intending to become focus of a conference SHOULD
NOT be located behind NAT or its IP SHOULD NOT belong to the private
address range. The information whether a participant is behind NAT can
be obtained by ICE connectivity checks during the conference joining
process. Nevertheless, under special circumstances it might be
reasonable to locate a focus peer behind a NAT. For instance within a
companies network infrastructure.</t>
<t>If a participant is a candidate to become a focus of the conference
it stores its mapping (Destination List or AoR) and coordinate value
into the DisCo data structure. Because the DisCo Kind uses either the
USER-MATCH or the USER-CHAIN-MATCH access control policy, the shared
'private' key passed by the participant's focus peer is sufficient to
permit this peer to write the DisCo Resource. By storing the mapping
into the data structure a participant becomes a potential focus.</t>
<!--<t>All focus peers MUST observe whether their mapping entries and
coordinate value in the DisCo data structure are always valid and
available. For instance while a focus peer is serving a conference, it
MUST assure that lifetime of the dictionary entry does not expire.</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 of the
<landmark-host> sub-elements each representing a single host
that serves 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 responses
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 within 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
| | |-- maximum-user-count
| | |-- active
| | |-- locked
| | |-- conf-uris
| | |-- available-media
| |
| |-- users
| | |-- user
| | | |-- endpoint
| | | | |-- media
| | | | |-- call-info
| |
| |-- relations
| | |-- relation
|-- focus
| |-- ...
]]></artwork>
</figure>
<t>The local state for each focus peer is described within a
corresponding 'focus' element. Each provides general information about
a focus peer, its signaling and media relations to participants and
focus peers. Conference participants are aggregated within 'users'
elements, respectively, 'user' sub elements.</t>
<t>The document structure of 'distributed-conference' is designed to
allow concurrent occurring change events at several focus peers. For
that reason, each focus peer has exclusive writing permission to the
'focus' sub element that describes itself. The Event Package for
Distributed Conferences therefore imports the mechanisms for partial
notification and uses the 'Element Keys' definitions described in
<xref target="RFC4575"></xref> (see <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
the same AoR as the AoR of RELOAD user that is acting focus peer. This
restriction also applies to the child elements of the 'version-vector'
element. Each 'version' number is a property of a specific focus peer
which is exclusively responsible to increment the version number.</t>
<t>General information about the conference itself, is provided within
a 'conference-description' element. In contrast to the 'focus' and
'version-vector' elements, the 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 section <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 described by the XML
document. A SUBSCRIBE request addressed to this URI results in an
ordinary subscribe/notify relation between participants and their
related focus peer.</t>
<t hangText="state:">In accordance to <xref
target="RFC4575"></xref>, this attribute indicates whether the
content of a distributed conference document is a 'full',
'partial' or 'deleted' information.</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>, respectively, <version> elements to
enable a coherent versioning scheme based on vector clocks as defined
in <xref target="timestamps-acsc88"></xref>. Each <version>
element contains a unsigned integer that describes the local version
of a specific focus peer and contains the following attribute: <list
style="hanging">
<t hangText="entity">This attribute contains the AoR of the focus
peer. This AoR corresponds to the 'user name' field, that is
declared in the certificate that the RELOAD user acting as focus
peer obtained while enrollment.</t>
</list></t>
<t>If a focus peer originates a notification for a change event, the
focus peer MUST increment its associated <version> element by
one. Additionally, a change event notification MUST contain a complete
<version-vector> that carries each <version> element known
by the focus peer.</t>
<t>The recipient of a change event needs to update the <version>
element of the originator of the event notification in its local XML
document. All other <version> elements remain constant, although
the received <version-vector> might be different. Instead, a
comparison of both version vectors can indicate a different knowledge
about the global conference state.</t>
<t>As long as each <version> number in the recipients XML
document is at least lower than one to the received
<version-vector> numbers, there is no need for a subscription
refresh. In this case, one or more change event notifications might
not reached all subscribers yet.</t>
<t>Otherwise, if any <version> number of the recipient is
retarded more than one, the recipient SHOULD refresh the subscription
in order to trigger a 'full' state notification. The recipient uses
the full state notification to recursively update every <focus>
element, whose corresponding <version> element is retarded more
than one.</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 text
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>In accordance with <xref target="RFC4575"></xref> a
<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>The <focus> element describes an active focus peer as whole.
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.). Announces the signaling and media information
about participants maintained by this focus peer and describes
Signaling or media connections to other focus peers.</t>
<t>The <focus> element uses the following attributes: <list
style="hanging">
<t hangText="entity:">This attribute contains the AoR of the
RELOAD user acting as focus peer to the conference. This AoR
corresponds to the 'user name' field, that is declared in the
certificate the user obtained while RELOAD enrollment <xref
target="I-D.ietf-p2psip-base"></xref>. The AoR in the 'entity'
attribute uniquely identifies the focus peer, that is allowed to
update or change the sub elements of <focus>. All other
focus peers SHOULD NOT update or change sub elements of this
<focus> element. A SUBSCRIBE request addressed to this AoR
MUST be interpreted as the request for conference state
synchronization with another focus peer.</t>
<t hangText="state:">In accordance to RFC4575, this attribute
indicates whether the content of the <focus> element is a
'full', 'partial' or 'deleted' information. Since the event
package for distributed conferences uniquely restricts
modifications on <focus> sub elements to a specific focus
peer, a 'partial' notification contains a single <focus>
element at maximum.</t>
</list></t>
<t>The following sub elements of <focus> provide general
information about a focus peer. The XML schema definition and semantic
for <associated-aors>, <roles> and <languages> are
imported from the 'conference-info' event package <xref
target="RFC4575"></xref>. <list style="hanging">
<t hangText="<display-text>:">Contains a short text
description about the user acting as focus peer.</t>
<t hangText="<associated-aors>:">In accordance with <xref
target="RFC4575"></xref>, this element contains additional URIS
that are associated with this user.</t>
<t hangText="roles:">In accordance with <xref
target="RFC4575"></xref>, this element MAY contain human-readable
text descriptions about the roles of the user in the
conference.</t>
<t hangText="<languages>:">In accordance with <xref
target="RFC4575"></xref>, this element contains a list of tokens,
each describing a language understood by the user.</t>
</list></t>
<t>The following sections describe the remaining sub elements of
<focus> more detailed.</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="<maximum-user-count>:">This number indicates
a threshold of participants a focus peer is able to serve. This
value MAY changes during a conference, depending on the focus
peers current load.</t>
<t hangText="<conf-uris>:">In accordance with the
'conference-info' event package <xref target="RFC4575"></xref>,
this element MAY contains 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 any 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 connected to the conference
via the focus peer which is 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
between to another focus peer. The parent element <relations>
uses the 'state' attribute to enable the partial notification
mechanism. For the <relation> element the following attribute
is defined: <list style="hanging">
<t hangText="entity:">This attribute contains the AoR of the
remote focus.</t>
</list></t>
<t>The content of each <relation> is a comma separated string
that describes the tuple <CONNECTION-TYPE,IDENTIFIER>. The
CONNECTION-TYPE describes the type of connection (e.g. media,
signaling, etc.) and the IDENTIFIER contains a token that uniquely
identifies the connection in the conference. It is meant as 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 originated in the focus peer described in the parent
<focus> element. The 'media' part indicates that this
connections belongs to any kind of media connection. The 'label'
part uniquely identifies to the stream within the conference and
corresponds to the SDP "label" media attribute defined in <xref
target="RFC4574"></xref>.</t>
<t hangText="sync,call-id:">This tuple indicates a subscription
for the event package for distributed conferences. The remote
focus peer described in the 'entity' attribute is a subscriber
for distributed-conference event package for the purpose of
conference state synchronization. The 'call-id' part thereby
corresponds to the call-id of the SIP subscription dialog.</t>
</list></t>
</section>
</section>
<section anchor="subsec-dce" title="Distribution of Change Events">
<t>Maintaining a coherent conference state at each controller of a
distributed conference, requires a common protocol scheme to
communicate each conference change event to each focus peer. Using SIP
specific event notifications <xref target="RFC3265"></xref>, this
requirement would result in an N to M relation (with N=M), between N
notifiers and M subscribers to synchronize the conference state. To
avoid a 'full meshed' subscription topology, where each focus peer has
N subscriptions to all other focus peers, this section describes a
'mutual' subscription scheme that constructs a spanning tree topology
among the focus peers.</t>
<t>A member in a distributed conference that accepted an authorized
participation request and becomes a new focus peer, SHOULD join the
state synchronization process of a conference. Therefore, it sends a
SIP SUBSCRIBE to request the Event Package for Distributed Conferences
to its own focus peer. The subscription request SHOULD be addressed to
AoR of the active focus peer, thus it 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>Following, the subscribed focus peer has to subscribe the new
upcoming focus peer for the distributed conference event package. The
corresponding notification by the new focus carries a 'partial'
conference state XML document. It contains the received
<version-vector> including a new <version> element for
itself and contains a new <focus> element that describes its
local state (see section <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 firstly 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,
secondly, triggers a new event notification process at the receiver of
the change event. It notifies all its subscribers with excepting the
sender of the event notification (which is not necessarily the event
originator). Thus, 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. Firstly, the
semantic of these elements are fitting the demands to describe the
global state of a distributed conference and, secondly, 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. New notifications SHOULD be
triggered by change events that are originated within a focus peer
and SHOULD be triggered by reception of a 'distributed-conference'
event state of another 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 the focus peer through which they
are connected to the conference. Thus, the ci.<host-info>
element contains information about a focus peer that is serving its
participants.</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 defined by the logical concatenation over all
disco.<active> elements by an OR-operator.</t>
<t hangText="<locked>">The boolean ci.<locked>
element is defined by 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">
<section anchor="subsec-cd" title="Call delegation">
<t>Distributed conference control provides the possibility to delegate
the control for a conference participant from one focus to another
remote focus for some reason. In contrast to common call transfers that
are using the SIP REFER method as described in <xref
target="RFC3515"></xref>, call delegations are achieved transparently
to the transferred party.</t>
<t>However, a focus peer starts 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 original SIP
dialog establishment 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 the contact information
(URI, IP-address,..) of this peer.</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>
<!-- not in this draft version -01
<section anchor="subsec-lb" title="Load Balancing">
<t>Description how an overloaded focus peer selectes an adequate focus
to tranfer a call. Begin with something like: Load distribution is
normallay given by proximity aware focus selection...</t>
</section>
-->
<section anchor="subsec-ls" title="Conference Access">
<t>It is an important issue to define who is allowed to participate 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. Additionally, it is an
issue which of the conference participant is allowed to become a
controller of the multiparty session.</t>
<t>To provide those constraints for distributed conferences in RELOAD,
this document defines a basic set of conference access that decide
whether: <list style="symbols">
<t>A peer is allowed to participate a conference</t>
<t>A peer is allowed to become a focus of the conference</t>
</list> 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 by 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. Each focus peer
forwards all media streams it receives from the conference to all
connected peers it is responsible for and similarly all streams from
its peers to its responsible focus. This results in the media stream
naturally following the SIP signalling paths. Implementations MAY
choose to use a more sophisticated scheme, e.g. employing cross
connections between different sub-trees of the conference, but MUST
take measures to prevent loops in media routing.</t>
<t>When a new peer has been attached to a focus, new media steams may
be available to the focus, which need to be forwarded to the
conference. To accomplish this, the new media streams need to be
signalled to the other participants. This is usually done by sending a
SIP re-INVITE and modifying the media sessions, adding the new streams
to the SDP. This renegotiation can be costly since it needs to be
propagated through the whole conference. Also, 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 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 media streams used in 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 MUST
NOT contain any media streams not matching an offer (cf. <xref
target="RFC3264"></xref> Section 6). A joining peer which is aware
of the distributed nature of the conference, SHOULD NOT send an SDP
offer in the initial INVITE message, but instead send an empty
INVITE to which the focus replies with an OK, containing the 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>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>
<t>A focus has two options when distributing media streams from a
new participant to the conference. The focus can either mix the new
streams into his own, thus averting the need to modify the already
established media sessions with neighboring peers or in case the
focus is not willing or able to do mixing of the media streams, he
SHOULD modify the media sessions with all attached peers by sending
a re-INVITE, adding the new media streams coming from the newly
joined participant to the SDP. This SHOULD subsequently be done by
all other focus peers upon receiving the new stream, resulting in
the stream being distributed across the conference.</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 focus, are supposed
to reconnect to the synchronization graph, by subscribing the
leaving peer's parent node.</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" xml:space="preserve"><![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 a coordinates value describing a peers relative network
position acting as focus for the conference. Additionally it
contains either the peers URI or a Destination list.
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-MATCH
or
USER-CHAIN-MATCH
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
XOR one of the two following data:
sip_focus_uri
the URI of the peer action as focus
sip_focus_node_id
the Destination list of the peer acting as focus]]></artwork>
</figure>
</section>
<section anchor="sec-acc-contr-pol"
title="Access Control Policy USER-CHAIN-MATCH">
<t>The base RELOAD document <xref target="I-D.ietf-p2psip-base"></xref>
mandates that every kind definition specifies an Access Control Model to
use. The base document defines four access control policies, of which
none is fitting for the purpose of shared write access to a resource.
This document defines a new access control model called
USER-CHAIN-MATCH.</t>
<t>In the USER-CHAIN-MATCH policy, a given value MUST be written (or
overwritten) if and only if the request is singed with a key associated
with a certificate whose user name hashes (using the hash function for
the overlay) to the Resource-ID for the resource. Also the user name of
the certificate MUST match the user name of an intermediary certificate
in the chain to the root certificate, using the matching pattern
specified in the configuration document for the corresponding kind.</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="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: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="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: Describing the privacy level for a conference instance;
define whether a joining user is allowed to become a member or even
focus of a conference.</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.4575"?>
<?rfc include="reference.I-D.ietf-p2psip-base"?>
<?rfc include="reference.I-D.ietf-p2psip-sip"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-p2psip-concepts"?>
<?rfc include="reference.RFC.4353"?>
<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>
</references>
<section title="Change Log ">
<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:19:33 |