One document matched: draft-knauf-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-knauf-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 strict="yes" ?>
<front>
<title abbrev="DisCo">A RELOAD Usage for Distributed Conference Control
(DisCo)</title>
<author fullname="Alexander Knauf" initials="A.K." surname="Knauf">
<organization abbrev="HAW Hamburg">HAW Hamburg</organization>
<address>
<postal>
<street>Berliner Tor 7</street>
<city>Hamburg</city>
<code>D-20099</code>
<code>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.H." 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>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.W." 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 month="June" year="2010" />
<abstract>
<t>This document defines a RELOAD Usage for Distributed Conference
Control (DisCo) with SIP. DisCo splits the semantic of identifier and
locator of a SIP conference URI using a new Kind data structure.
Conference members are enabled to select conference controllers based on
proximity awareness. DisCo proposes call delegation to balance load at
focus peers. The document addresses also aspects of security and trust,
as well as compatibility for 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 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>Mechanisms for conference synchronization and call delegation</t>
<t>Mechanisms for proximity-aware routing for conference
participants</t>
<t>XML extension for the event package for conference state</t>
<t>A graduated trust delegation system</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 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
data structure stores the mapping of a single conference to multiple
conference controllers and thereby separates the conference URI from
focus instantiations.</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>
<t>To provide secure mechanisms, which allows users to join or even
control a distributed conference, this document describes a graduated
trust delegation system. The proposed system guides implementors how to
maintain privacy and trust to other peers in a distributed multiparty
system.</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="Delegatee:">A user agent that was refered by the
requested focus to another remote focus.</t>-->
<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 can be 'active' if is already in signaling
relations to conference participants. Otherwise it is 'potential' if
it is only registered in a distributed conference data structure but
not maintaining signaling relations yet.</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 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 owner O 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 owner O. 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|
+----------+
/
+-----+
|Owner|
# # # # # # # # # # |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 under
DisCo-Registration Kind (cf., Figure <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 Figure <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 node that is not aware of RELOAD uses common SIP signaling to
retrieve the conference URI.</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 using the conference
Resource-ID. 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 SIP specific event
notifications <xref target="RFC3265"></xref>.</t>
<t>Each focus peer can complete its view of the entire conference
state among the focus peers by subscribing all other focus peers for
an XML event package for distributed conferences. This is defined in
this document and 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. It is designed
as an extension to the XML event package for conference state, which
provides signaling and media parameters for each peer participating in
the multiparty session. The extension defines additional XML elements
and complex types (see <xref target="sec-csepe"> </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-delc"> </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="Resiliance">
<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="sec-cde"></xref>)
to construct topology-aware connections between focus and peers. Each
peer intending to create or participate in a distributed conference
SHOULD determine a topological descriptor that describes its relative
position in the n-dimensional Cartesian space. 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 the mappings for one
conference 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
mappings. The DisCo data structure of type DisCoRegistration is shown
as follows:<figure align="center" suppress-title="true">
<artwork align="center" 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>
<t>The content of the DisCoRegistrationData structure are as
follows:<figure align="center" suppress-title="true">
<artwork align="center" xml:space="preserve">type
type of the registration
length
the length of the registration PDU
data
the conference registration data</artwork>
</figure> <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 MUST
select the focus peer, which coordinate value matches at most (see
section <xref target="subsec-pcp"></xref>) 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
SHOULD 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 as an N value long
position vector in the N-dimensional Cartesian space. Focus peers
store this coordinate value together with their announcement as
conference focus. Joining peers likewise SHOULD 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="sec-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 differnt
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 alogithm 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>:<figure align="center"
anchor="fig-conf-create-cf" suppress-title="false"
title="Creation of a Distributed Conference">
<artwork align="center" xml:space="preserve"><![CDATA[
Enroll.Serv Alice Peer1 Overlay PeerN StoringPeer
-------------------------------------------------------------------
| | StatReq Res:Conf-URI | |
| |---------->|--------->|--------->|--------->|
| | StatAns | | |
| |<----------|<---------|<---------|<---------|
|<==Cert===| | | | |
| | | | | |
|===Cert==>| StoreReq Res:Conf-URI Kinds:DisCo[,SIP] |
| |---------->|--------->|--------->|--------->|
| | StoreAns | | |
| |<----------|<---------|<---------|<---------|
| | | | | |]]></artwork>
</figure><list style="numbers">
<t>The peer MUST determine its own coordinate value (if used).</t>
<t>The peer MUST 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 like to register a new
virtual user that has the conference URI as its Address-of-Record.
Therefore, the conference initiator MUST request the enrollment
server for a new overlay certificate that contains the conference
URI as user name. A sample certificate is shown below: <figure
align="center" anchor="fig-cert-sample" suppress-title="true">
<artwork align="center" xml:space="preserve">
User name: conference@dht.example.com
Node-ID: 013456789abcdef
Serial: 0815
</artwork>
</figure></t>
<t>The peer finally registers the DisCo data structure signed with
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 certificate. If they were using the conference
creators’ certificate, they were permitted to write
non-shared Resources of the creator.</t>
</list></t>
<t>The conference creator MAY registers the conference URI as
SIP-Registration Kind as well. In this case, it also MUST sign the
Store request with the private key that matches to the certificate
obtained for the conference URI. This is necessary because in the case
of the departure of the conference creator, the other focus peers are
permitted to redirect the mapping to another focus peer still serving
the conference. The SIP-Registration SHOULD be sent in the same
StoreReq as the DisCo registration.</t>
<t>The creator of a distributed conference MUST select on the access
models as described in section <xref target="subsec-ls"></xref> to
define the desired privacy level of the multiparty conference.</t>
<t>TODO: a description how a new certificate is generated in the
RELOAD instance without enrollment server</t>
</section>
<section anchor="subsec-pcp"
title="Proximity-aware Conference Participation">
<t>A RELOAD peer intending to join a distributed conference follows
the steps showed in <xref target="fig-conf-join-cf"></xref> :<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:Cert{DisCo-Resource} |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| | | | | |]]></artwork>
</figure><list style="numbers">
<t>The joining peer MUST 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 by
making the following calculation for each dictionary entry:<list
style="symbols">
<t>For each coordinate entry, calculate the each difference Di
= Fi – Pi, with Fi is the coordinates vector of the
Focus peer and Pi the coordinates vector of the joining
peer.</t>
<t>For ech Di, calculate the scalar product of Di</t>
</list></t>
<t>The focus with the smallest scalar product SHOULD 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.</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-delc"></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></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
certificate 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 multiparty. 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.</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 the
USER-MATCH access control policy, the shared certificate 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>-->
<t>TODO: What to do if the set of Landmark hosts changes during
conference?</t>
</section>
<section anchor="subsec-riadc"
title="Resiliance in a Distributed Conference">
<t>The decentralized character of distributed conferences provide
abilities to prevent the breakdown of the entire multiparty session in
the case that a focus peer disappears. Two possibilities of a focus
departure must be distinguished:<list style="hanging">
<t hangText="Friendly leave:">A user whose peer is acting as
conference focus decides to quit coonference participation.</t>
<t hangText="Unexpected leave:">Any case in which a peer serving
as conference focus fails.</t>
</list></t>
<t>In the friendly case the leaving peer (lp) MUST accomplish the
following procedure: <list style="symbols">
<t>Lp deletes its mapping in the DisCo data structure by storing
the "nonexisting" value as described in the RELOAD base document
<xref target="I-D.ietf-p2psip-base"></xref>.</t>
<t>Lp searches the conference state XML document (see section
<xref target="sec-csepe"></xref>) for 'active' focus peers that
have free capacities to serve further participants. Additionally,
it fetches the lastest DisCo data structure for this conference to
obtain all 'potential' focus peers.</t>
<t>The lp then calculates for all its related participants the
closest focus peer using the algorithm described in <xref
target="subsec-dc"></xref>.</t>
<t>Based on the results from the previews step lp transfers all
it's participants to their ascertained focus peers using the call
delegation described in <xref target="subsec-delc"></xref></t>
</list></t>
<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>
<t>Assuming unfavorably circumstances it can happen that the available
capacities over all potential and active focus peers are insufficient
to reassemble all lost participants. In this case it RECOMMENDED to
reassemble as many participants as possible in a first come first
serve algorithm and to fail the rest.</t>
</section>
</section>
<section anchor="sec-fcco" title="Focus Call Control Operations">
<t>This section describes SIP call flows for third party call control
for distributed conferences. Those operation comprise the call
delegation and state synchronization mechanisms.</t>
<section anchor="subsec-baaf" title="Becoming an active Focus">
<t>A conference participant that stored its mapping to the distributed
DisCo data structure serves as potential focus for further
participation requests by other peers. On incomming participation
request a potential focus becomes an active focus and is then
responsible to grant the joining peer access to the conference. Two
differnt scenarios for participaton requests must be
distinguished:<list style="symbols">
<t>A joining peer requests the potential focus</t>
<t>An already active focus peer transfers a participation request
to the potential focus</t>
</list></t>
<t>The second case will be dicussed as part of the call delegation in
<xref target="subsec-delc"></xref>.</t>
<t>For the case that a RELOAD peer directly requests a potential focus
for participation the call flow in <xref
target="fig-sip-direct-inv-cf"></xref> describes the necessary
procedure. The joing peer (JP) has already established a transport
connection and sends a SIP INVITE request (1) to the contact address
(IP) to its selected potential focus (PF). Note that JP is thereby
unaware that PF does not serve any other participants yet. PF is
participating the conference through its own active focus (AF) and is
aware of the offered media types for the multiparty session. This PF
offers the available media parameter to JP in (2). After finalizing
the signaling in (3) and establishment of the media streams the PF in
charge to synchronize the distributed conference state. As the first
step of the pairwise subscrption (4) PF MUST send a SIP SUBSCRIBE
<xref target="RFC3265"></xref> request to the AF that is the focus
peer respoonsible for signaling with PF. It subscribes for the
conference for the event package for conference state<xref
target="RFC4575"></xref> with 'multi-focus' extension <xref
target="sec-csepe"></xref>. This document therefore defines a new
content type "application/distributed-conference-info+xml" for a MIME
entity that contains conference state information for distributed
conferences. After confirming the subscription (5) AF informs PF about
the entire conference state by sending a 'full' XML document. It
includes the list of all participants, active focus peers and used
media types. In the second step for in the subscription procudure (8)
AF MUST subscribe PF for distributed conference. After confirmation in
(9), PF MUST inform AF about the arrival of JP and also MUST advertise
its own capacities. Pf therefore sends a NOTIFY request containing a
'partial' conference state XML document that describes PF's local
state (e.g. capabilities, responsibilities for JP). This step
finalizes the promotion of PF to an active focus peer. <figure
align="center" anchor="fig-sip-direct-inv-cf"
suppress-title="false"
title="Pairwise subscription for conference state synchronization">
<artwork align="center" xml:space="preserve"><![CDATA[
JoiningPeer PotentialFocus ActiveFocus
--------------------------------------------------------------------
| (1) INVITE pot.Focus | |
|------------------------> | |
| (2) 200 OK | |
|<--------------------------| |
| (3) ACK | |
|-------------------------->| |
| MEDIA | |
|<=========================>| |
| | |
| Pot.Focus requests conference state XML |
| | |
| | (4) SUBSCRIBE-event:disco |
| |---------------------------->|
| | (5) 200 OK |
| |<----------------------------|
| | (6) NOTFY conf.state XML |
| |<----------------------------|
| | (7) 200 OK |
| |---------------------------->|
| | |
| Active Focus completes pairwise subscription |
| | |
| | (8) SUBSCRIBE event.disco |
| |<----------------------------|
| | (9) 200 OK |
| |---------------------------->|
| | |
| Pot.Focus notifies about the new member JP |
| | |
| | (10) NOTIFY conf.state XML |
| |---------------------------->|
| | (11) 200 OK |
| |<----------------------------|]]></artwork>
</figure></t>
<t>Depending on whether AF has more subscriptions for the distributed
conference event package it will synchronize all other focus peers
sending notifications containing partial conference state XML document
received from PF.</t>
<t>Since PF is aware of the entire conference and MAY establishes more
subscriptions to other active focus peers. This can reduce signaling
delays and could serve as guideline for new routes for the media
streams. A specification of how those new subscription should be done
is a TODO in this document.</t>
</section>
<section anchor="subsec-delc" title="Delegating Calls">
<t>The call delegation feature described in this document provides
focus peers the possibility to transfer an incoming participation
request to another focus peer. A focus peer SHOULD delegate incoming
participation requests if the number of participants it currently
maintains is equal to the 'max_participants' value the focus
advertised in the distributed conference XML document.</t>
<t>A sample scenario for call delegation in shown in <xref
target="fig-sip-refer-inv-cf"></xref>. A joining peer (JP) requests
the active focus (AF) for conference participation (1). AF has no more
capacity to serve JP as focus peer and has to transfer the call. AF
firstly temporally accepts the call (2-3) and then selects an adequate
focus peer for call delegation based on JP's coordinate value (sent
base64 encoded as URI parameter in (1) see section <xref
target="subsec-pcp"></xref>). AF fetches the lastest DisCo data
structure (not shown in <xref target="fig-sip-refer-inv-cf"></xref>)
to obain all available potential and active focus peers. As shown in
the exmaple, AF determines the potential focus (PF) as best candidate
to become JP's focus and transfers the participation request to PF
sending a SIP REFER request (4). The REFER request MUST contain the
session identifier from JP as payload in the request body and the
call-ID of (1) as parameter in the URI of the refer-to header field,
e.g., 'Refer-To: <sip:bob@dht.example;call-id=1234>'</t>
<t>Triggered by the REFER request PF is in charge to become JP's focus
peer and to enter the conference state sychronization process. Because
the call delegation operation should not interrupt JP's participation
request PF MUST use the signaling and session information of (4). PF
sends a re-INVITE request to JP that appears as it were orginated by
AF with an additional Record-Route header field set to PF's contact
address. By using this technique a distributed conference appeares as
one single entity. The additional Record-Route header thereby ensures
that further SIP signaling will be routed to PF. After the signaling
process the negotiated media session can be established.</t>
<t>PF then is in charge to enter the conference state synchronization
mechanism by pairwise subscribting PF->AF, AF-->PF for the event
package for conference with multi-focus extension (9-14) as described
<xref target="subsec-baaf"></xref>. Note that PF could subscribe
another active focus peer than AF since this is not necessarily the
conference controller responsible for PF.<figure align="center"
anchor="fig-sip-refer-inv-cf" suppress-title="false"
title="Call delegation to potential focus peer">
<artwork align="center" xml:space="preserve"><![CDATA[
JoiningPeer ActiveFocus PotentialFocus
--------------------------------------------------------------------
| (1) INVITE act.Focus | |
|------------------------->| |
| (2) 200 OK | |
|<-------------------------| |
| (3) ACK | |
|------------------------->| |
| | |
| AF reached its threshold for serving new calls |
| | |
| | (4) REFER refer-to:JP |
| |-------------------------->|
| | (5) 200 OK |
| |<--------------------------|
| | |
| PF re-invites JP using AF's contact |
| | |
| (6) INVITE JP record-route:potentialFocus |
|<-----------------------------------------------------|
| (7) 200 OK | |
|----------------------------------------------------->|
| (8) ACK | |
|<-----------------------------------------------------|
| MEDIA |
|<====================================================>|
| | (9) SUBSCRIBE event:disco |
| |<------------------------- |
| | (10) 200 OK |
| |-------------------------> |
| | (11) NOTIFY conf.state XML|
| |-------------------------> |
| | (12) SUBSCRIBE event:disco|
| |-------------------------->|
| | (13) 200 OK |
| |<--------------------------|
| | (14) NOTIFY conf.state XML|
| |<--------------------------|]]></artwork>
</figure></t>
</section>
<section title="Synchronizing the Conference State">
<t>The entire state of the distributed conference changes partly on
every event that happens at an active focus peer. Most commenly those
events refer to joins or lefts of conference participants. In order to
maintain a coherent conference state all focus peers MUST send NOTIFY
messages <xref target="RFC3265"></xref> to all subscribers (other
focus peers) to synchronize the conference state. The payload of the
notifications MUST only contain a partial state information about the
changes in the state from the previews conference state.</t>
<t>If the connection graph build by the pairwise subscriptions between
the focus peers is not structured in a full mesh topology, state
notifations MUST be forwarded by intermediate focus peers. The
extension for the event package described in <xref
target="sec-csepe"></xref> therefore provides an XML element that
allows every focus to reconstruct the connection graph among the focus
peers.</t>
<t>If a state notification is received multiple times a focus peer
MUST NOT forward the dublicate state information for prevent
loops.</t>
</section>
</section>
<section title="DISCO Kind Definition">
<t>This section formally defines the DisCo kind.<figure align="center"
suppress-title="true">
<artwork align="center" xml:space="preserve">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
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></t>
</section>
<section anchor="sec-csepe"
title="Conference State Event Package Extension">
<t>This section presents the XML extension for the event package for
conference state that enables a focus peer to have a view on the
responsibilities of each other focus peer. The additional information by
exentending the XML schema defined RFC4575 <xref
target="RFC4575"></xref> is can be used in the case of a focus departure
and call delegations. The new <focus-states> element as shown in
<xref target="fig-fsp"></xref> is placed as child-of the root-element
<conference-info>. It's child element <focus> represents
every conference participant that is in the role of an active focus peer
to the conference.</t>
<figure align="left" anchor="fig-fsp" suppress-title="true">
<artwork align="left" xml:space="preserve">
conference-info
|
|-- conference-description
|
|-- host-info
|
|-- users
|
|-- focus-states
| |
| |-- focus
|
..
|-- ..</artwork>
</figure>
<section anchor="subsubsec-fse"
title="The <focus-states> and <focus> elements">
<t>The <focus-states> element serves as container of the
<focus> sub-elements, each describing the responsibilities of a
conference participant acting as focus peer.</t>
<t>The <focus> uses the following attributes:<list
style="hanging">
<t hangText="entity:">This attribute contains the AoR of the focus
peer that is declared in the user name field in the RELOAD
certificate. This AoR MUST correspond to the entity attribute
defined in the focus peer's <user> element in the base
conference event package. A user that whishes to lookup a focus
peer's signaling information can retrieve it by looking at the
corresponding <user> element with the same AoR in the entity
attribute.</t>
<t hangText="state:">This attribute indicates whether the
transmitted conference state for this focus peer is 'full',
'partial' or 'deleted' and have to be interpreted as defined in
<xref target="RFC4575"></xref>.</t>
</list></t>
<t>The <focus> element uses the complex focus-type that contains
the following child-elements:<list style="hanging">
<t hangText="<focus-capacity> :">This element describes a
focus peer's maximal number of participants it can serve
respectively the maximal number media connections to other focus
peers it can handle.</t>
<t hangText="<participant> :">Each participant element
describes a conference member that has this focus peer as it's
conference controller. It uses the 'entity' attribute that
contains the AoR that this RELOAD peer uses as user name in the
overlay certificate. It corresponds to the AoR in the <user>
element in the base conference event XML document. Additionally,
the <participants> element uses the 'state' attribute to
provide the partial notification mechanism as defined in <xref
target="RFC4575"></xref>.</t>
<t hangText="<graph> :">Each <graph> element describes
a conference state synchronization relation this focus peer
maintains. By reference to this element each conference controller
has a view of the entire synchronization topology over the focus
peers. It uses the 'state' attribute as well.</t>
</list></t>
</section>
<section anchor="subsec-xmls" title="XML Schema">
<t>The schema for XML extension is:<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
targetNamespace="http://www.example.org/inet-ci-multifocus-ext"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.example.org/inet-ci-multifocus-ext"
elementFormDefault="qualified" >
<!--
FOCUS STATES ELEMENT
-->
<xs:element name="focus-states" type="focus-states-type"/>
<xs:complexType name="focus-states-type">
<xs:sequence>
<!--
FOCUS ELEMENT
-->
<xs:element name="focus" type="focus-type"
maxOccurs="unbounded" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:sequence>
<xs:attribute name="state" type="state-type"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
FOCUS TYPE
-->
<xs:complexType name="focus-type">
<xs:sequence>
<xs:element name="focus-capacity"
type="focus-capacity-type" maxOccurs="1" minOccurs="0"/>
<xs:element name="participant" type="participant-type"
maxOccurs="unbounded" minOccurs="0"/>
<xs:element name="graph" type="graph-type"
maxOccurs="unbounded" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI"/>
<xs:attribute name="state" type="state-type"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
FOCUS-CAPACITY TYPE
-->
<xs:complexType name="focus-capacity-type">
<xs:sequence>
<xs:element name="max-participants" type="xs:int"
maxOccurs="1" minOccurs="0"/>
<xs:element name="max-focus-references" type="xs:int"
maxOccurs="1" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:sequence>
<xs:attribute name="state" type="state-type"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
PARTICIPANT TYPE
-->
<xs:complexType name="participant-type">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI"/>
<xs:attribute name="state" type="state-type"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
GRAPH TYPE
-->
<xs:complexType name="graph-type">
<xs:sequence>
<xs:element name="ref-to-focus" type="xs:anyURI"
maxOccurs="1" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:sequence>
<xs:attribute name="state" type="state-type"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
</xs:schema>]]></artwork>
</figure></t>
</section>
</section>
<section anchor="sec-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>
<section anchor="subsec-lalh"
title="The <landmark> and <Landmark-host> elements">
<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 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>
<section title="Example">
<t>TODO: Call flow examples for joining, delegating</t>
</section>
<section title="Security Considerations">
<section anchor="subsec-ls" title="Layered Security">
<t>TODO: An ad hoc conference can be set up to a layered security
model. Three models: open access, focus authenticate, closed access
model.</t>
</section>
<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>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3265"?>
<?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"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:56:43 |