draft-ietf-p2psip-disco-01.txt   draft-ietf-p2psip-disco-02.txt 
Network Working Group A. Knauf Network Working Group A. Knauf
Internet-Draft T. Schmidt, Ed. Internet-Draft T C. Schmidt, Ed.
Intended status: Standards Track HAW Hamburg Intended status: Standards Track HAW Hamburg
Expires: January 13, 2014 G. Hege Expires: February 2, 2014 G. Hege
daviko GmbH daviko GmbH
M. Waehlisch M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
July 12, 2013 August 1, 2013
A RELOAD Usage for Distributed Conference Control (DisCo) A RELOAD Usage for Distributed Conference Control (DisCo)
draft-ietf-p2psip-disco-01 draft-ietf-p2psip-disco-02
Abstract Abstract
This document defines a RELOAD Usage for Distributed Conference This document defines a RELOAD Usage for Distributed Conference
Control (DisCo) with SIP. DisCo preserves conference addressing Control (DisCo) with SIP. DisCo preserves conference addressing
through a single SIP URI by splitting its semantic of identifier and through a single SIP URI by splitting its semantic of identifier and
locator using a new Kind data structure. Conference members are locator using a new Kind data structure. Conference members are
enabled to select conference controllers based on proximity awareness enabled to select conference controllers based on proximity awareness
and to recover from failures of individual resource instances. DisCo and to recover from failures of individual resource instances. DisCo
proposes call delegation to balance the load at focus peers. proposes call delegation to balance the load at focus peers.
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2014. This Internet-Draft will expire on February 2, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of DisCo . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of DisCo . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Reference Scenario . . . . . . . . . . . . . . . . . . . 4 3.1. Reference Scenario . . . . . . . . . . . . . . . . . . . . 6
3.2. Initiating a Distributed Conference . . . . . . . . . . . 6 3.2. Initiating a Distributed Conference . . . . . . . . . . . 7
3.3. Joining a Conference . . . . . . . . . . . . . . . . . . 6 3.3. Joining a Conference . . . . . . . . . . . . . . . . . . . 8
3.4. Conference State Synchronization . . . . . . . . . . . . 7 3.4. Conference State and Synchronization . . . . . . . . . . . 9
3.5. Call delegation . . . . . . . . . . . . . . . . . . . . . 8 3.5. Call delegation . . . . . . . . . . . . . . . . . . . . . 10
3.6. Resilience . . . . . . . . . . . . . . . . . . . . . . . 8 3.6. Resilience . . . . . . . . . . . . . . . . . . . . . . . . 10
3.7. Topology Awareness . . . . . . . . . . . . . . . . . . . 8 3.7. Topology Awareness . . . . . . . . . . . . . . . . . . . . 10
4. RELOAD Usage for Distributed Conference Control . . . . . . . 8 4. RELOAD Usage for Distributed Conference Control . . . . . . . 11
4.1. Shared Resource DisCo-Registration . . . . . . . . . . . 9 4.1. Shared Resource DisCo-Registration . . . . . . . . . . . . 11
4.2. Kind Data Structure . . . . . . . . . . . . . . . . . . . 9 4.2. Kind Data Structure . . . . . . . . . . . . . . . . . . . 11
4.3. Variable Conference Identifier . . . . . . . . . . . . . 10 4.3. Variable Conference Identifier . . . . . . . . . . . . . . 12
4.4. Conference Creation . . . . . . . . . . . . . . . . . . . 10 4.4. Conference Creation . . . . . . . . . . . . . . . . . . . 12
4.5. Advertising Focus Ability . . . . . . . . . . . . . . . . 11 4.5. Advertising Focus Ability . . . . . . . . . . . . . . . . 13
4.6. Determining Coordinates . . . . . . . . . . . . . . . . . 12 4.6. Determining Coordinates . . . . . . . . . . . . . . . . . 14
4.7. Proximity-aware Conference Participation . . . . . . . . 12 4.7. Proximity-aware Conference Participation . . . . . . . . . 14
4.8. Configuration Document Extension . . . . . . . . . . . . 14 4.8. Configuration Document Extension . . . . . . . . . . . . . 16
5. Conference State Synchronization . . . . . . . . . . . . . . 15 5. Conference State Synchronization . . . . . . . . . . . . . . . 18
5.1. Event Package Overview . . . . . . . . . . . . . . . . . 15 5.1. Event Package Overview . . . . . . . . . . . . . . . . . . 18
5.2. <distributed-conference> . . . . . . . . . . . . . . . . 16 5.2. <distributed-conference> . . . . . . . . . . . . . . . . . 20
5.3. <version-vector>/<version> . . . . . . . . . . . . . . . 17 5.3. <version-vector>/<version> . . . . . . . . . . . . . . . . 20
5.4. <conference-description> . . . . . . . . . . . . . . . . 18 5.4. <conference-description> . . . . . . . . . . . . . . . . . 21
5.5. <focus> . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.5. <focus> . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.5.1. <focus-state> . . . . . . . . . . . . . . . . . . . . 19 5.5.1. <focus-state> . . . . . . . . . . . . . . . . . . . . 23
5.5.2. <users>/<user> . . . . . . . . . . . . . . . . . . . 20 5.5.2. <users>/<user> . . . . . . . . . . . . . . . . . . . . 23
5.5.3. <relations>/<relation> . . . . . . . . . . . . . . . 20 5.5.3. <relations>/<relation> . . . . . . . . . . . . . . . . 24
5.6. Distribution of Change Events . . . . . . . . . . . . . . 21 5.6. Distribution of Change Events . . . . . . . . . . . . . . 24
5.7. Translation to Conference-Info Event Package . . . . . . 22 5.7. Translation to Conference-Info Event Package . . . . . . . 25
5.7.1. <conference-info> . . . . . . . . . . . . . . . . . . 22 5.7.1. <conference-info> . . . . . . . . . . . . . . . . . . 26
5.7.2. <conference-description> . . . . . . . . . . . . . . 23 5.7.2. <conference-description> . . . . . . . . . . . . . . . 26
5.7.3. <host-info> . . . . . . . . . . . . . . . . . . . . . 23 5.7.3. <host-info> . . . . . . . . . . . . . . . . . . . . . 26
5.7.4. <conference-state> . . . . . . . . . . . . . . . . . 23 5.7.4. <conference-state> . . . . . . . . . . . . . . . . . . 26
5.7.5. <users>/<user> . . . . . . . . . . . . . . . . . . . 24 5.7.5. <users>/<user> . . . . . . . . . . . . . . . . . . . . 27
5.7.6. <sidebars-by-ref>/<sidebars-by-value> . . . . . . . . 24 5.7.6. <sidebars-by-ref>/<sidebars-by-value> . . . . . . . . 27
6. Distributed Conference Control with SIP . . . . . . . . . . . 24 6. Distributed Conference Control with SIP . . . . . . . . . . . 28
6.1. Call delegation . . . . . . . . . . . . . . . . . . . . . 24 6.1. Call delegation . . . . . . . . . . . . . . . . . . . . . 28
6.2. Conference Access . . . . . . . . . . . . . . . . . . . . 26 6.2. Conference Access . . . . . . . . . . . . . . . . . . . . 29
6.3. Media Negotiation and Distribution . . . . . . . . . . . 26 6.3. Media Negotiation and Distribution . . . . . . . . . . . . 30
6.3.1. Offer/Answer . . . . . . . . . . . . . . . . . . . . 26 6.3.1. Offer/Answer . . . . . . . . . . . . . . . . . . . . . 30
6.3.2. New Peers Joining . . . . . . . . . . . . . . . . . . 27 6.3.2. New Peers Joining . . . . . . . . . . . . . . . . . . 31
6.4. Restructuring a Conference . . . . . . . . . . . . . . . 27 6.4. Restructuring a Conference . . . . . . . . . . . . . . . . 31
6.4.1. On Graceful Leave . . . . . . . . . . . . . . . . . . 27 6.4.1. On Graceful Leave . . . . . . . . . . . . . . . . . . 31
6.4.2. On Unexpected Leave . . . . . . . . . . . . . . . . . 28 6.4.2. On Unexpected Leave . . . . . . . . . . . . . . . . . 32
7. DisCo Kind Definition . . . . . . . . . . . . . . . . . . . . 28 7. DisCo Kind Definition . . . . . . . . . . . . . . . . . . . . 33
8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9. Relax NG Grammar . . . . . . . . . . . . . . . . . . . . . . 32 9. Relax NG Grammar . . . . . . . . . . . . . . . . . . . . . . . 38
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10.1. Trust Aspects . . . . . . . . . . . . . . . . . . . . . 33 10.1. Trust Aspects . . . . . . . . . . . . . . . . . . . . . . 39
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
13.1. Normative References . . . . . . . . . . . . . . . . . . 33 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42
13.2. Informative References . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 35 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
This document describes a RELOAD Usage for distributed conference This document describes a RELOAD Usage for distributed conference
control (DisCo) in a tightly coupled model with SIP [RFC3261]. The control (DisCo) in a tightly coupled model with SIP [RFC3261]. The
Usage provides self-organizing and scalable signaling that allows Usage provides self-organizing and scalable signaling that allows
RELOAD peers, clients and plain SIP user agents to participate in a RELOAD peers, clients and plain SIP user agents to participate in a
managed P2P conference. DisCo defines the following functions: managed P2P conference. DisCo defines the following functions:
o A SIP protocol scheme for distributed conference control o A SIP protocol scheme for distributed conference control
skipping to change at page 4, line 10 skipping to change at page 4, line 40
complies with the demands for distributed conferences. The 'DisCo' complies with the demands for distributed conferences. The 'DisCo'
data structure stores the mapping of a single conference URI to data structure stores the mapping of a single conference URI to
multiple conference controllers and thereby separates the conference multiple conference controllers and thereby separates the conference
identifier from focus instantiations. identifier from focus instantiations.
Authorized controllers of a conference are permitted to register Authorized controllers of a conference are permitted to register
their mapping in the DisCo data structure autonomously. Thus, the their mapping in the DisCo data structure autonomously. Thus, the
DisCo data structure represents a co-managed Resource in RELOAD. To DisCo data structure represents a co-managed Resource in RELOAD. To
provide trusted and secure access to a co-managed Resource, this provide trusted and secure access to a co-managed Resource, this
document uses the definitions for Shared Resources (ShaRe) document uses the definitions for Shared Resources (ShaRe)
[I-D.knauf-p2psip-share]. [I-D.ietf-p2psip-share].
Delay and jitter are critical issues in multimedia communications. Delay and jitter are critical issues in multimedia communications.
The proposed conferencing scheme supports mechanisms to build an The proposed conferencing scheme supports mechanisms to build an
optimized interconnecting graph between conference participants and optimized interconnecting graph between conference participants and
their responsible conference controllers. Conference members will be their responsible conference controllers. Conference members will be
enabled to select the closest focus with respect to delay or jitter. enabled to select the closest focus with respect to delay or jitter.
DisCo extends conference control mechanisms to provide a consistent DisCo extends conference control mechanisms to provide a consistent
and reliable conferencing environment. Controlling peers maintain a and reliable conferencing environment. Controlling peers maintain a
consistent view of the entire conference state. The multiparty consistent view of the entire conference state. The multiparty
skipping to change at page 4, line 32 skipping to change at page 5, line 14
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
We use the terminology and definitions from der RELOAD base We use the terminology and definitions from der RELOAD base
draft[I-D.ietf-p2psip-base], the peer-to-peer SIP concepts draft draft[I-D.ietf-p2psip-base], the peer-to-peer SIP concepts draft
[I-D.ietf-p2psip-concepts], the usage for shared resources draft [I-D.ietf-p2psip-concepts], the usage for shared resources draft
[I-D.knauf-p2psip-share],and the terminology formed by the framework [I-D.ietf-p2psip-share],as well as selected terms defined in SIP
for conferencing with SIP [RFC4353]. Additionally the following [RFC3261] and the framework for conferencing with SIP [RFC4353].
terms are used: Additionally, the following terms are used:
Coordinate Value: An opaque string that describes a host's relative Coordinate Value: An opaque string that describes a host's relative
position in the network topology. position in the network topology.
Focus peer: A RELOAD peer that provides SIP conferencing functions DisCo Peer: A RELOAD Peer that provides SIP conferencing functions
and implements the Usage for distributed conferencing. It is and implements the Usage for distributed conferencing.
called 'active' if already involved in signaling relation to
conference participants. Otherwise, if only registered in a Focus Peer: A DisCo Peer that has registered itself in the overlay
distributed conference data structure, it is referred to as a as a focus for one or several conferences. It is called 'active'
'potential' focus peer. if already involved in signaling relations to conference
participants. Every DisCo Peer can potentially serve as a Focus
Peer.
3. Overview of DisCo 3. Overview of DisCo
3.1. Reference Scenario 3.1. Reference Scenario
The reference scenario for the Distributed Conference Control (DisCo) The reference scenario for the Distributed Conference Control (DisCo)
is shown in Figure 1. Peers are connected via a RELOAD is shown in Figure 1. Peers are connected via a RELOAD
[I-D.ietf-p2psip-base] instance, in which peers A and B are managing [I-D.ietf-p2psip-base] instance, in which peers A and B are managing
a single multiparty conference. The conference is identified by a a single multiparty conference. The conference is identified by a
unique conference URI, but located at peers A and B fulfilling the 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 role of the focus, see [RFC4353]. The mapping of the conference URI
responsible focus peers is stored in a new RELOAD Resource for to the responsible focus peers A and B is stored in a new RELOAD
distributed conferencing within a data structure denoted as DisCo- Resource for distributed conferencing within a data structure denoted
Registration. The storing peer SP of the distributed conference as DisCo-Registration. The storing peer SP of the distributed
resource holds this data. conference resource holds this data.
The focus peers A and B maintain SIP signaling relations to The focus peers A and B maintain SIP signaling relations to
conference participants, which may have different conference protocol conference participants, which can have different conference protocol
capabilities. In this example, peer A is the focus for the RELOAD capabilities. In this example, peer A is the focus for the RELOAD
peer C and the plain SIP user agent E whereas peer B serves as a peer C and the plain SIP user agent E, whereas peer B serves as a
focus for RELOAD peer D and the RELOAD client F. focus for RELOAD peer D and the RELOAD client F.
RELOAD peers and clients obtain the contact information for the RELOAD peers and clients obtain the contact information for the
conference from the storing peer. In contrast to this, the user conference from the storing peer. In contrast to this, the user
agent E receives the conference URI not by RELOAD mechanisms, but agent E receives the conference URI not by RELOAD mechanisms, but
resolves the ID and joins the conference by plain SIP negotiation. resolves the ID and joins the conference by plain SIP negotiation.
Focus peers maintain a SIP signaling relation among each other used Focus peers maintain mutual SIP signaling relations among each other
for notification messages that synchronize the conference focus used for synchronizing the conference event states. Additionally,
peers' knowledge about the entire conference state. Additionally, focus peers can transfer calls between each other by a call
focus peers can transfer calls to each other by a call delegation delegation mechanism.
mechanism.
+-------------------+ +------------------+ +-------------------+ +------------------+
|Access Control List| |DisCo-Registration| |Access Control List| |DisCo-Registration|
+-------------------+ +------------------+ +-------------------+ +------------------+
\ / \ /
+-------+ +-------+
|Storing| |Storing|
# # # # # # # # # # | Peer | # # # # # # # # # # # # # # # # # # # # | Peer | # # # # # # # # # #
# | SP | # # | SP | #
# +-------+ # # +-------+ #
# # # #
# # # #
# # # #
+----+ +----+ +----+ +----+
|Peer| \ RELOAD Instance |Peer| |Peer| \ RELOAD Instance |Peer|
| C | \ | D | | C | \ | D |
+----+ \ +----+ +----+ \ +----+
# SIP # # SIP #
# \ # # \ #
# \ # # \ #
# +-------+ +-------+ #( # +-------+ +-------+ #(
# | Focus | | Focus | # ) # | Focus | | Focus | # )
# # | Peer | # # # # # # # # # # # | Peer | # # ( # # | Peer | # # # # # # # # # # # | Peer | # # (
| A | <===Conf.Events/====> | B | ) | A | <===Conf.Events/====> | B | )
+-------+ Call delegation +-------+ Overlay +-------+ Call delegation +-------+ Overlay
/ \ Comm. / \ Comm.
/ \ ( / \ (
SIP SIP ) SIP SIP )
/ \ ( / \ (
/ \ ) / \ )
+----------+ +--------+ +----------+ +--------+
|User Agent| | Client | |User Agent| | Client |
| E | | F | | E | | F |
+----------+ +--------+ +----------+ +--------+
Figure 1: Reference Scenario: Focus peers A,B maintain a distributed Figure 1: Reference Scenario: Focus peers A,B maintain a distributed
conference conference
3.2. Initiating a Distributed Conference 3.2. Initiating a Distributed Conference
To create a conference the initiating user agent announces itself as A DisCo Peer that wishes to initiate a distributed conference first
a focus for the conference. It stores its own contact information obtains an unused conference URI, and second announces itself as a
(Node-ID) as a DisCo-Registration Kind (cf. Figure 2) in the RELOAD Focus Peer for this conference. It stores its own contact
overlay. The hashed conference URI is used as the Resource-ID. This information (Node-ID) as a DisCo-Registration Kind (cf., Figure 2) in
Resource will later contain the contact IDs of all potential focus the RELOAD overlay, using the hashed conference URI as the
peers including optional topological descriptors. Resource-ID. This Shared Resource will later accumulate the contact
IDs of all potential focus peers including optional topological
descriptors.
3.3. Joining a Conference 3.3. Joining a Conference
A RELOAD-aware node (cf. Bob in Figure 2) intending to join an A RELOAD-aware node (cf., Bob in Figure 2) intending to join an
existing conference requests the list of potential focus peers stored existing conference requests the list of Focus Peers stored in the
in the DisCo-Registration under the conference's Resource-ID. The DisCo-Registration for this conference Resource-ID. The node selects
node selects any of the focus peers (e.g., Alice) and establishes a one of the Focus Peers (e.g., Alice) and establishes a direct SIP or
connection using AppAttach/ICE [RFC5245]. This transport is then SIPS connection as defined in Section 5 of [I-D.ietf-p2psip-sip].
used to send an INVITE to the conference applying the chosen focus as This transport connection is then used for a regular conference
the contact. The selection of the focus peer can optionally be based INVITE in SIP. The selection of the focus peer can optionally be
on proximity information if available. based on proximity information if available.
A conference member proposes itself as a focus for subsequent A conference member can propose itself as a focus for subsequent
participants by adding its Node-ID to the DisCo-Registration stored participants by adding its Node-ID to the DisCo-Registration stored
under the conference URI in the RELOAD overlay. The decision whether under the conference URI in the RELOAD overlay. The decision whether
a peer announces as a focus incorporates bandwidth, power, and other to announce as a focus, are likely to account for system and network
constraints, but details are beyond the scope of this document. resources as well as other constraints, the details of which are
beyond the scope of this document.
Alice RELOAD Bob Alice RELOAD Bob
(initiating peer) (joining peer) (initiating peer) (joining peer)
-------------------------------------------------------------------- --------------------------------------------------------------------
| | | | | |
| Alice stores her mapping to register a conference | | Alice stores her mapping to register a conference |
| Store mapping(ConfURI, Alice) | | | Store mapping(ConfURI, Alice) | |
|------------------------------>| | |------------------------------>| |
| Bob requests the list of potential focus peers | | Bob requests the list of potential focus peers |
| | Lookup ConfURI | | | Lookup ConfURI |
| |<------------------------------| | |<------------------------------|
| | Result list of conf. focus | | | Result list of conf. focus |
| |------------------------------>| | |------------------------------>|
| | | | | |
| Bob establishes transport connection to Alice | | Bob establishes transport connection to Alice |
| AppAttach | | AppAttach |
|<--------------------------------------------------------------| |<--------------------------------------------------------------|
| AppAttach | | AppAttach |
|-------------------------------------------------------------->| |-------------------------------------------------------------->|
| INVITE | | INVITE |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| OK | | OK |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
| ACK | | ACK |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Media | | Media |
|<=============================================================>| |<=============================================================>|
| | | | | |
| Bob stores his mapping to become a focus peer too | | Bob stores his mapping to become a focus peer too |
| | Store mapping(ConfURI, Bob) | | | Store mapping(ConfURI, Bob) |
| |<------------------------------| | |<------------------------------|
| | | | | |
Figure 2: DisCo Usage generic Call Flow Figure 2: DisCo Usage generic Call Flow
3.4. Conference State Synchronization 3.4. Conference State and Synchronization
Each focus of a conference maintains signaling connections to its
related participants independently from other conference controllers.
This distributed conference design effects that the entire SIP
conference state is jointly held by all focus peers. In DisCo, state
synchronization is based on a SIP specific event notifications
mechanism [RFC3265].
Each focus peer maintains its view of the entire conference state by In a distributed conference, each Focus Peer maintains signaling
subscribing to the other focus peers' XML event package for connections to its related participants independently of other
distributed conferences. This is based on the event package for conference controllers, while each Focus Peer has a full view of the
conference state (cf. [RFC4575]). Details are defined in this entire conference state. In DisCo, state synchronization is required
document in Section 5. Receivers of event notifications update their and based on the SIP-specific event notification [RFC3265]. For this
local conference state document to represent a valid view of current purpose, Focus Peers establish mutual connections for exchanging
total conference state. state changes. An application layer multicast could also be used in
future versions of this protocol.
The event notification package for distributed conferences enables DisCo conference state is described by an extension of the SIP
focus peers to synchronize the entire conference state. The event conference event package (see [RFC4575] and Section 8 for more
package defines additional XML elements and complex types (see details). The event notification package for distributed conferences
Section 8 for more details), which describe the responsibilities of enables Focus Peers to synchronize conference state by subscribing to
any focus peer in the conference. By providing a global view each the corresponding event packages of other focus peers. Receivers of
focus peer is enabled to perform additional load balancing operations event notifications update their local conference state document to
and enhances the robustness against departures of focus peers. represent a valid view of current total conference state. Details
are defined in this document in Section 5.By providing a global view
each focus peer is enabled to perform additional load balancing
operations and enhances the robustness against departures of focus
peers.
3.5. Call delegation 3.5. Call delegation
Call delegation (see Section 6.1) is a feature used to transfer an Call delegation (see Section 6.1) is a feature used to transfer an
incoming participation request to another focus peer. It can be incoming participation request to another focus peer. It can be
applied to prevent overloading of focus peers. Call delegation is applied for traffic optimization, load balancing and to prevent
realized through SIP REFER requests, which carry signaling and overloading of individual peers. Call delegation is achieved through
session description information of the caller to be transferred. SIP REFER requests, which carry signaling and session description
This feature is achieved transparently for the transferred user agent information of the caller to be transferred. This feature remains
by using a source routing mechanism at SIP dialog establishment. transparent for the transferred user agent by using a source routing
Descriptions of overload detection are beyond the scope of this mechanism at SIP dialog establishment. Algorithms for optimization
document. and misbalance detection are beyond the scope of this document.
3.6. Resilience 3.6. Resilience
A focus peer can decide to leave the conference or may ungracefully A focus peer can decide to leave the conference or could ungracefully
fail. In a traditional conferencing scenario, loss of the conference fail. In a traditional conferencing scenario, loss of the conference
controller or the media distributor would cause a complete failure of controller or the media distributor would cause a complete failure of
the multiparty conversation. Distributed conferencing uses the the multiparty conversation. Distributed conferencing uses the
redundancy provided by multiple focus peers to reconfigure a current redundancy provided by multiple Focus Peers to reconfigure a current
multiparty conversation. Participants that loose their entry point multiparty conversation. Participants that loose their entry point
to the conference re-invite themselves via the remaining focus peers to the conference can re-invite themselves via the remaining focus
or will be re-invited by the latter. This option is based on the peers or will be re-invited by the latter. This option is based on
conference state and call delegation functions. the conference state and call delegation functions.
3.7. Topology Awareness 3.7. Topology Awareness
DisCo supports the optimization of the conference topology in respect DisCo supports the optimization of the conference topology with
of the underlying network using topological descriptors. An respect to the underlying network using topological descriptors. An
extension for the RELOAD XML configuration document is defined in extension for the RELOAD XML configuration document is defined in
Section 4.8 to support landmarking approaches. Each peer intending Section 4.8 to support landmarking approaches. Each peer intending
to create or participate in a distributed conference MAY determine a to create or participate in a distributed conference is enabled to
topological descriptor that describes its relative position in the determine a topological descriptor that expresses its relative
network. Focus peers store these coordinate values in an additional position in the network. Focus Peers store these coordinate values
data field in the DisCo-Registration data structure. This enables in an additional data field in the DisCo-Registration data structure.
peers joining the conference to select the closest focus with respect This enables joining peers to select the closest focus with respect
to its coordinate values. to its coordinate values.
4. RELOAD Usage for Distributed Conference Control 4. RELOAD Usage for Distributed Conference Control
4.1. Shared Resource DisCo-Registration 4.1. Shared Resource DisCo-Registration
A distributed conference is a cooperative service of several A distributed conference is a cooperative service of several
individual devices that use a common identifier. To enable a mapping individual devices that use a common identifier. To enable a mapping
from one conference identifier to multiple focus peers, this document from one conference identifier to multiple focus peers, this document
defines the new Kind data structure DisCo-Registration. The DisCo defines the new Kind data structure DisCo-Registration. The DisCo
Kind uses the definitions for Shared Resources Kind uses the definitions for Shared Resources
[I-D.knauf-p2psip-share] to allow a jointly maintenance by multiple [I-D.ietf-p2psip-share] to allow a jointly maintenance by multiple
focus peers. Hence, write permission to a DisCo-registration is focus peers. Hence, write permission to a DisCo-registration is
shared by the conference creator with all authorized focus peers. shared by the conference creator with all authorized focus peers.
DisCo complies with the following requirements for Shared Resources: DisCo complies with the following requirements for Shared Resources:
Isolated Data Storage: DisCo uses the dictionary data model. Each Isolated Data Storage: DisCo uses the dictionary data model. Each
dictionary key is the Node-ID of the certificate that will be used dictionary key is the Node-ID of the certificate that will be used
to sign the stored data to sign the stored data
ResourceNameExtension field: A DisCo-Registration can contain the ResourceNameExtension field: A DisCo-Registration can contain the
skipping to change at page 9, line 40 skipping to change at page 11, line 43
cooperatively control the conference. Additionally, each DisCo- cooperatively control the conference. Additionally, each DisCo-
Registration provides the coordinate value, which indicates the Registration provides the coordinate value, which indicates the
relative network position of the focus peers. relative network position of the focus peers.
The data structure uses the RELOAD dictionary type. The dictionary The data structure uses the RELOAD dictionary type. The dictionary
key MUST be the Node-ID of the focus peer that is associated with the key MUST be the Node-ID of the focus peer that is associated with the
dictionary entry. This allows a focus peer to update only its own dictionary entry. This allows a focus peer to update only its own
mapping. The DisCo data structure of type DisCoRegistration is mapping. The DisCo data structure of type DisCoRegistration is
constructed as follows: constructed as follows:
struct { struct {
/* This field is optional, see documentation */ /* This field is optional, see documentation */
ResourceNameExtension res_name_ext; ResourceNameExtension res_name_ext;
opaque coordinate<0..2^16-1>; opaque coordinate<0..2^16-1>;
NodeId node_id; NodeId node_id;
} DisCoRegistration; } DisCoRegistration;
The DisCoRegistration structure is composed of the following values: The DisCoRegistration structure is composed of the following values:
res_name_ext: This field can contain the conference URI. It meets res_name_ext: This field can contain the conference URI. It meets
the requirement for the USER-CHAIN-ACL access policy defined in the requirement for the USER-CHAIN-ACL access policy defined in
[I-D.knauf-p2psip-share] to enable variable resource names. [I-D.ietf-p2psip-share] to enable variable resource names.
coordinate: This field contains a topological descriptor that coordinate: This field contains a topological descriptor that
indicates the relative position of the peer in the network. To indicates the relative position of the peer in the network. To
support different algorithms the coordinate field is represented support different algorithms the coordinate field is represented
as an opaque string. as an opaque string.
node_id: This field contains the Node-ID of the peer storing the node_id: This field contains the Node-ID of the peer storing the
DisCoRegistration and is used to contact the peer when utilizing DisCoRegistration and is used to contact the peer when utilizing
its service as a focus. its service as a focus.
4.3. Variable Conference Identifier 4.3. Variable Conference Identifier
DisCo-Registrations can be stored based on a variable Resource Name. DisCo-Registrations can be stored based on a variable Resource Name.
However, a conference identifier set by a user MUST follow the However, a conference identifier set by a user MUST follow the
requirements for Kinds using variable Resource Names as defined in requirements for Kinds using variable Resource Names as defined in
the ShaRe Usage [I-D.knauf-p2psip-share]. the ShaRe Usage [I-D.ietf-p2psip-share].
4.4. Conference Creation 4.4. Conference Creation
The registration of a distributed conference includes the storage of The registration of a distributed conference includes the storage of
the following two Kinds (see Figure 3). the following two Kinds (see Figure 3).
DisCo-Registration Kind: contains the conference identifier and the DisCo-Registration Kind: contains the conference identifier and the
optional coordinate value. If used, the coordinate value MAY be optional coordinate value. If used, the coordinate value MAY be
determined previously to the conference registration. The determined previously to the conference registration. The
Resource Name and hence the Resource-ID is defined by the hash Resource Name and hence the Resource-ID is defined by the hash
over the desired conference identifier (using the hash algorithm over the desired conference identifier (using the hash algorithm
of the overlay). of the overlay).
Access Control List Kind: contains the conference participants that Access Control List Kind: contains the conference participants that
are allowed to register as focus peers for a conference (see are allowed to register as focus peers for a conference (see
[I-D.knauf-p2psip-share]). Its Resource Name/ID is equal to those [I-D.ietf-p2psip-share]). Its Resource Name/ID is equal to those
of the corresponding DisCo-Registration. of the corresponding DisCo-Registration.
Preliminary to storage of DisCo-Registration and Access Control List Preliminary to storage of DisCo-Registration and Access Control List
(ACL) Kinds the conference creator SHOULD perform a RELOAD StatReq to (ACL) Kinds the conference creator SHOULD perform a RELOAD StatReq to
verify that no former conference is present. If neither a DisCo- verify that no former conference is present. If neither a DisCo-
Registration nor an associated ACL exist, the conference creator Registration nor an associated ACL exist, the conference creator
stores a DisCo-Registration with a valid conference identifier (see stores a DisCo-Registration with a valid conference identifier (see
Section 4.3) and an ACL referring to the DisCo-Registration Kind-ID. Section 4.3) and an ACL referring to the DisCo-Registration Kind-ID.
If DisCo registrations and ACL Kinds from previous conferences are If DisCo registrations and ACL Kinds from previous conferences are
still existing there are two options. First, if conference creator still existing there are two options. First, if conference creator
is aware of the indexes from previous ACL Kinds, it refreshes the is aware of the indexes from previous ACL Kinds, it refreshes the
root item of this ACL and stores its registration as focus peer as root item of this ACL and stores its registration as focus peer as
DisCo-Registration Kind. Second, If the creator is unaware of DisCo-Registration Kind. Second, If the creator is unaware of
indexes, it fetches all Access List Kinds to determine the index of indexes, it fetches all Access List Kinds to determine the index of
the root item. the root item.
Alice Peer1 Overlay PeerN Storing Peer Alice Peer1 Overlay PeerN Storing Peer
------------------------------------------------------------- -------------------------------------------------------------
| StatReq Res:Conf-URI | | | StatReq Res:Conf-URI | |
|------------>|----------->|----------->|----------->| |------------>|----------->|----------->|----------->|
| StatAns | | | | StatAns | | |
|<------------|<-----------|<-----------|<-----------| |<------------|<-----------|<-----------|<-----------|
| StoreReq Res:Conf-URI Kinds:DisCo, Access-List | | StoreReq Res:Conf-URI Kinds:DisCo, Access-List |
|------------>|----------->|----------->|----------->| |------------>|----------->|----------->|----------->|
| StoreAns | | | | StoreAns | | |
|<------------|<-----------|<-----------|<-----------| |<------------|<-----------|<-----------|<-----------|
| | | | | | | | | |
Figure 3: Initial creation of a Distributed Conference Figure 3: Initial creation of a Distributed Conference
Optionally the conference initiator (or any active focus) MAY store Optionally the conference initiator (or any active focus) MAY store
an additional RELOAD SIP-Registration in the overlay an additional RELOAD SIP-Registration in the overlay
[I-D.ietf-p2psip-sip] or even at a standard SIP registrar [RFC3261] [I-D.ietf-p2psip-sip] or even at a standard SIP registrar [RFC3261]
under a URI for which it has write permission. This allows DisCo- under a URI for which it has write permission. This allows DisCo-
unaware or even legacy SIP user agents to participate in the unaware or even legacy SIP user agents to participate in the
conference. Those registrations SHOULD always point to a currently conference. Those registrations SHOULD always point to a currently
active focus, who is prepared to accept legacy user agents. The user active focus, who is prepared to accept legacy user agents. The user
skipping to change at page 12, line 12 skipping to change at page 14, line 12
incoming connections via AppAttach/ICE. Peers that can only accept incoming connections via AppAttach/ICE. Peers that can only accept
connections with the support of TURN should not act as a focus. connections with the support of TURN should not act as a focus.
Nevertheless, under special circumstances it might be reasonable to Nevertheless, under special circumstances it might be reasonable to
locate a focus peer behind such a NAT (e.g., within a companies locate a focus peer behind such a NAT (e.g., within a companies
network infrastructure). network infrastructure).
If a participant is a candidate to become a focus for the conference, If a participant is a candidate to become a focus for the conference,
it stores its Node-ID and optional coordinate value into the DisCo it stores its Node-ID and optional coordinate value into the DisCo
data structure. An entry in the corresponding ACL data structure. An entry in the corresponding ACL
[I-D.knauf-p2psip-share] must be present to allow this peer to write [I-D.ietf-p2psip-share] must be present to allow this peer to write
the DisCo-Registration resource. By storing the mapping into the the DisCo-Registration resource. By storing the mapping into the
data structure a participant becomes a potential focus. data structure a participant becomes a potential focus.
4.6. Determining Coordinates 4.6. Determining Coordinates
Each RELOAD peer within the context of a distributed conference MAY Each RELOAD peer within the context of a distributed conference MAY
be aware of its relative position in the network topology. To be aware of its relative position in the network topology. To
constuct a topology-aware conference, the DisCo Usage provides the constuct a topology-aware conference, the DisCo Usage provides the
coordinate value within the DisCo-Registration data structure. Focus coordinate value within the DisCo-Registration data structure. Focus
peers store their relative network position together with the peers store their relative network position together with the
skipping to change at page 13, line 8 skipping to change at page 15, line 6
1. Resolution of the conference identifier. 1. Resolution of the conference identifier.
2. Establishment of of transport connection. 2. Establishment of of transport connection.
3. SIP signaling to join a conference. 3. SIP signaling to join a conference.
Figure 4 and the following specifications give a more detailed view Figure 4 and the following specifications give a more detailed view
on the joining procedure. on the joining procedure.
Bob Peer1 Overlay PeerN Storing Peer Alice Bob Peer1 Overlay PeerN Storing Peer Alice
-------------------------------------------------------------- --------------------------------------------------------------
| StatReq Res:Conf-URI | | | | StatReq Res:Conf-URI | | |
|--------->|--------->|--------->|--------->| | |--------->|--------->|--------->|--------->| |
| |StatAns | | | | | |StatAns | | | |
|<---------|<---------|<---------|<---------| | |<---------|<---------|<---------|<---------| |
| FetchReq Res:Conf-URI Kind:DisCo,ACL | | | FetchReq Res:Conf-URI Kind:DisCo,ACL | |
|--------->|--------->|--------->|--------->| | |--------->|--------->|--------->|--------->| |
| |FetchAns | | | | | |FetchAns | | | |
|<---------|<---------|<---------|<---------| | |<---------|<---------|<---------|<---------| |
| | | | | | | | | | | |
| Bob calculates Alice as closest Focus | | | Bob calculates Alice as closest Focus | |
| | | | | | | | | | | |
| |AppAttach application:5060 | | | |AppAttach application:5060 | |
|--------->|--------->|--------->|--------->|--------->| |--------->|--------->|--------->|--------->|--------->|
| |AppAttach application:5060 | | | |AppAttach application:5060 | |
|<---------|<---------|<---------|<---------|<---------| |<---------|<---------|<---------|<---------|<---------|
| | | | | | | | | | | |
|<-------------------ICE Checks----------------------->| |<-------------------ICE Checks----------------------->|
| | | | | | | | | | | |
| | INVITE sip:Alice | | | | INVITE sip:Alice | |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
| | 200 OK | | | | | 200 OK | | |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| | ACK | | | | | ACK | | |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
| | | | | | | | | | | |
Figure 4: Participation of a Distributed Conference Figure 4: Participation of a Distributed Conference
1. The joining peer MAY determine its own coordinate value (if 1. The joining peer MAY determine its own coordinate value (if
used). used).
2. The joining peer sends a StatReq message to obtain all indexes of 2. The joining peer sends a StatReq message to obtain all indexes of
the Access Control List (ACL) Kinds stored. the Access Control List (ACL) Kinds stored.
3. The joining peer sends a FetchReq message for the DisCo and ACL 3. The joining peer sends a FetchReq message for the DisCo and ACL
Kind to the Resource-ID of the conference URI. The FetchReq Kind to the Resource-ID of the conference URI. The FetchReq
SHOULD NOT include any specific dictionary keys, but SHOULD fetch SHOULD NOT include any specific dictionary keys, but SHOULD fetch
for those array ranges previously determined the StatReq. With for those array ranges previously determined the StatReq. With
the ACL items, the joining peer is able to verify whether DisCo- the ACL items, the joining peer is able to verify whether DisCo-
Registrations are stored by authorized focus peers (see Registrations are stored by authorized focus peers (see
[I-D.knauf-p2psip-share]). [I-D.ietf-p2psip-share]).
4. Using the retrieved coordinates values of the DisCo- 4. Using the retrieved coordinates values of the DisCo-
Registrations, the joining peer MAY calculate which of than Registrations, the joining peer MAY calculate which of than
opaque <0..2^16-1> initial field in the Kind data structure focus opaque <0..2^16-1> initial field in the Kind data structure focus
peers is the relatively closest to itself. peers is the relatively closest to itself.
5. The joining peer then establishes a transport using RELOADs 5. The joining peer then establishes a transport using RELOADs
AppAttach, respectively, ICE procedures to create a transport to AppAttach, respectively, ICE procedures to create a transport to
the chosen focus peer. the chosen focus peer.
skipping to change at page 14, line 36 skipping to change at page 16, line 33
(see Section 6.1). (see Section 6.1).
A conference focus MAY allow the joining peer to also become a focus A conference focus MAY allow the joining peer to also become a focus
(depending on the conference policy see Section 6.2). Therefore, it (depending on the conference policy see Section 6.2). Therefore, it
stores a new ACL Kind that delegates write permission for the DisCo- stores a new ACL Kind that delegates write permission for the DisCo-
Registration to the new participant. It sets the 'user_name' field Registration to the new participant. It sets the 'user_name' field
in the ACL Kind to its own user name and sets the 'to_user' field to in the ACL Kind to its own user name and sets the 'to_user' field to
the user name of the joining peer. If no other conference policy is the user name of the joining peer. If no other conference policy is
defined, the focus peer MAY set the allow_delegation flag to true. defined, the focus peer MAY set the allow_delegation flag to true.
For further details about the trust delegation using the ACL Kind see For further details about the trust delegation using the ACL Kind see
[I-D.knauf-p2psip-share]. [I-D.ietf-p2psip-share].
4.8. Configuration Document Extension 4.8. Configuration Document Extension
This section defines an additional parameter for the <configuration> This section defines an additional parameter for the <configuration>
element that extends the RELOAD XML configuration document. The element that extends the RELOAD XML configuration document. The
proposed <landmarks> element allows RELOAD provider to publish a set proposed <landmarks> element allows RELOAD provider to publish a set
of accessible and reliable hosts that SHOULD be used if RELOAD peers of accessible and reliable hosts that SHOULD be used if RELOAD peers
use landmarking algorithms to determine relative position in the use landmarking algorithms to determine relative position in the
network topology. network topology.
skipping to change at page 15, line 38 skipping to change at page 19, line 5
5.1. Event Package Overview 5.1. Event Package Overview
The 'distributed-conference' event package is designed to convey The 'distributed-conference' event package is designed to convey
information about roles and relations of the conference participants. information about roles and relations of the conference participants.
Conference controllers obtain the global state of the conference and Conference controllers obtain the global state of the conference and
use this information for load balancing or conference restructuring use this information for load balancing or conference restructuring
mechanisms in case of a focus failure. Figure Figure 5 gives a mechanisms in case of a focus failure. Figure Figure 5 gives a
general overview of the document hierarchy. general overview of the document hierarchy.
distributed-conference distributed-conference
| |
|-- version-vector |-- version-vector
| |-- version | |-- version
| |-- version | |-- version
| |
|-- conference-description |-- conference-description
| |
|-- focus |-- focus
| |-- focus-state | |-- focus-state
| | |-- user-count | | |-- user-count
| | |-- coordinate | | |-- coordinate
| | |-- maximum-user-count | | |-- maximum-user-count
| | |-- active | | |-- active
| | |-- locked | | |-- locked
| | |-- conf-uris | | |-- conf-uris
| | |-- available-media | | |-- available-media
| | | |
| |-- users | |-- users
| | |-- user | | |-- user
| | | |-- endpoint | | | |-- endpoint
| | | | |-- media | | | | |-- media
| | | | |-- call-info | | | | |-- call-info
| | | |
| |-- relations | |-- relations
| | |-- relation | | |-- relation
|-- focus |-- focus
| |-- ... | |-- ...
Figure 5: Overview of the event package for distributed conferences Figure 5: Overview of the event package for distributed conferences
The document structure is designed to allow concurrent change events The document structure is designed to allow concurrent change events
at several focus peers. To prevent race conditions each focus peer at several focus peers. To prevent race conditions each focus peer
has exclusive writing permission to the 'focus' sub element that has exclusive writing permission to the 'focus' sub element that
describes itself. It is achieved by a unique mapping from a focus describes itself. It is achieved by a unique mapping from a focus
peer to its XML element using the 'Element Keys' mechanisms for peer to its XML element using the 'Element Keys' mechanisms for
partial notification [RFC4575](sections 4.4-5.). A focus peer is partial notification [RFC4575](sections 4.4-5.). A focus peer is
only allowed to update or change that <focus> sub element, whose only allowed to update or change that <focus> sub element, whose
skipping to change at page 23, line 19 skipping to change at page 26, line 27
events of remote focus peer. events of remote focus peer.
5.7.2. <conference-description> 5.7.2. <conference-description>
The <conference-description> element exists in both event packages, The <conference-description> element exists in both event packages,
conference-info and distributed-conference. Thus, the following conference-info and distributed-conference. Thus, the following
elements are seamlessly translatable: <keywords>, <display-text>, elements are seamlessly translatable: <keywords>, <display-text>,
<subject>, <free-text> and <service-uris>. <subject>, <free-text> and <service-uris>.
The sub elements <conf-uris>, <maximum-user-count> and <available- The sub elements <conf-uris>, <maximum-user-count> and <available-
media> in conference-info have there counterparts below the \focus media> in conference-info have there counterparts below the
\focus-state element of the distributed-conference event package. \focus\focus-state element of the distributed-conference event
Each describes a local state of a focus peer in the conference. package. Each describes a local state of a focus peer in the
Hence, the intersection of every disco.<conf-uris>, disco.<available- conference. Hence, the intersection of every disco.<conf-uris>,
media> and the sum over each disco.<maximum-user-count> element of disco.<available-media> and the sum over each disco.<maximum-user-
each disco.<focus> element in distributed-conference, specifies the count> element of each disco.<focus> element in distributed-
content of the corresponding conference-info elements. conference, specifies the content of the corresponding conference-
info elements.
5.7.3. <host-info> 5.7.3. <host-info>
According to [RFC4575] the ci.<host-info> element contains According to [RFC4575] the ci.<host-info> element contains
information about the entity hosting the conference. For information about the entity hosting the conference. For
participants in a distributed conference, the hosting entity is their participants in a distributed conference, the hosting entity is their
focus peer. Thus, the ci.<host-info> element contains information focus peer. Thus, the ci.<host-info> element contains information
about a focus peer. about a focus peer.
5.7.4. <conference-state> 5.7.4. <conference-state>
The ci.<conference-state> element allows subscribers obtain The ci.<conference-state> element allows subscribers obtain
information about overall state of a conference. Its sub elements ci information about overall state of a conference. Its sub elements
.<user-count>, ci.<active> and ci.<locked> are reused as sub elements ci.<user-count>, ci.<active> and ci.<locked> are reused as sub
of \focus\focus-state to describe the local state of a focus peer in elements of \focus\focus-state to describe the local state of a focus
a distributed conference. The translation rules from the peer in a distributed conference. The translation rules from the
distributed-conference to the conference-info event package are the distributed-conference to the conference-info event package are the
following: following:
<user-count>: The sum over each value of the disco.<user-count> <user-count>: The sum over each value of the disco.<user-count>
element defines the corresponding ci.<user-count>. element defines the corresponding ci.<user-count>.
<active>: The boolean ci.<active> element is the logical <active>: The boolean ci.<active> element is the logical
concatenation over all disco.<active> elements by an OR-operator. concatenation over all disco.<active> elements by an OR-operator.
<locked> The boolean ci.<locked> element is the logical <locked> The boolean ci.<locked> element is the logical
skipping to change at page 28, line 39 skipping to change at page 33, line 9
6.4.2. On Unexpected Leave 6.4.2. On Unexpected Leave
If an unexpected leave is detected by a participant (e.g. missing If an unexpected leave is detected by a participant (e.g. missing
signaling and/or media packets) it MUST repeat the joining procedure signaling and/or media packets) it MUST repeat the joining procedure
as described in Section 4.7. as described in Section 4.7.
7. DisCo Kind Definition 7. DisCo Kind Definition
This section formally defines the DisCo kind. This section formally defines the DisCo kind.
Name Name
DISCO-REGISTRATION DISCO-REGISTRATION
Kind IDs Kind IDs
The Resource name DISCO-REGISTRATION Kind-ID is the AoR of the The Resource name DISCO-REGISTRATION Kind-ID is the AoR of the
conference. The data stored is the DisCoRegistrationData, that conference. The data stored is the DisCoRegistrationData, that
contains the Node-ID of a peer acting as a focus for the contains the Node-ID of a peer acting as a focus for the
conference and optionally a coordinates value describing a conference and optionally a coordinates value describing a
peer's relative network position. peer's relative network position.
Data Model Data Model
The data model for the DISCO-REGISTRATION Kind-ID is dictionary. The data model for the DISCO-REGISTRATION Kind-ID is dictionary.
The dictionary key is the Node-ID of the peer action as focus. The dictionary key is the Node-ID of the peer action as focus.
Access Control Access Control
USER-CHAIN-ACL USER-CHAIN-ACL
The data stored for the Kind-ID DISCO-REGISTRATION is of type The data stored for the Kind-ID DISCO-REGISTRATION is of type
DisCoRegistration. It contains a "coordinates" value, that describes DisCoRegistration. It contains a "coordinates" value, that describes
the peers relative network position and the Node-ID of the registered the peers relative network position and the Node-ID of the registered
focus peer. focus peer.
8. XML Schema 8. XML Schema
The XML schema for the event package for distributed conferences is: The XML schema for the event package for distributed conferences is:
skipping to change at page 32, line 30 skipping to change at page 38, line 5
<xs:complexType name="relation-type"> <xs:complexType name="relation-type">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:extension base="xs:string">
<xs:attribute name="entity" type="xs:anyURI"/> <xs:attribute name="entity" type="xs:anyURI"/>
<xs:anyAttribute namespace="##other" processContents="lax"/> <xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Figure 7
9. Relax NG Grammar 9. Relax NG Grammar
The grammar for the Landmark configuration document extension is: The grammar for the Landmark configuration document extension is:
<!-- <!--
LANDMARKS ELEMENT LANDMARKS ELEMENT
--> -->
parameter &= element landmarks { parameter &= element landmarks {
attribute version { xsd:int } attribute version { xsd:int }
<!-- <!--
LANDMARK-HOST ELEMENT LANDMARK-HOST ELEMENT
--> -->
element landmark-host { element landmark-host {
attribute address { xsd:string }, attribute address { xsd:string },
attribute port { xsd:int } attribute port { xsd:int }
}* }*
}? }?
Figure 8
10. Security Considerations 10. Security Considerations
10.1. Trust Aspects 10.1. Trust Aspects
TODO TODO
11. IANA Considerations 11. IANA Considerations
TODO: register Kind-ID code point at the IANA TODO: register Kind-ID code point at the IANA
skipping to change at page 33, line 34 skipping to change at page 42, line 15
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-p2psip-base] [I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-26 (work in Base Protocol", draft-ietf-p2psip-base-26 (work in
progress), February 2013. progress), February 2013.
[I-D.knauf-p2psip-share] [I-D.ietf-p2psip-share]
Knauf, A., Hege, G., Schmidt, T., and M. Waehlisch, "A Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A
Usage for Shared Resources in RELOAD (ShaRe)", draft- Usage for Shared Resources in RELOAD (ShaRe)",
knauf-p2psip-share-03 (work in progress), April 2012. draft-ietf-p2psip-share-01 (work in progress),
February 2013.
[I-D.ietf-p2psip-sip]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S.,
Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD",
draft-ietf-p2psip-sip-11 (work in progress), July 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264,
2002. June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description [RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574, August 2006. Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006. State", RFC 4575, August 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245,
2010. April 2010.
13.2. Informative References 13.2. Informative References
[I-D.ietf-p2psip-concepts] [I-D.ietf-p2psip-concepts]
Bryan, D., Willis, D., Shim, E., Matthews, P., and S. Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
Dawkins, "Concepts and Terminology for Peer to Peer SIP", Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-04 (work in progress), October draft-ietf-p2psip-concepts-05 (work in progress),
2011. July 2013.
[I-D.ietf-p2psip-sip]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S.,
Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD",
draft-ietf-p2psip-sip-09 (work in progress), February
2013.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the [RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353, February Session Initiation Protocol (SIP)", RFC 4353,
2006. February 2006.
[landmarks-infocomm02] [landmarks-infocomm02]
Ratnasamy, ., Handley, ., Karp, ., and . Shenker, Ratnasamy, Handley, Karp, and Shenker, "Topologically-
"Topologically-Aware Overlay Construction and Server Aware Overlay Construction and Server Selection", Proc. of
Selection", Proc. of 21st Annual Joint Conference of the 21st Annual Joint Conference of the IEEE Computer and
IEEE Computer and Communications Societies (INFOCOM '02) Communications Societies (INFOCOM '02) pp. 1190-1199,
pp. 1190-1199, 2002. 2002.
[timestamps-acsc88] [timestamps-acsc88]
Fidge, C., "Timestamps in Message-Passing Systems that Fidge, C., "Timestamps in Message-Passing Systems that
Preserve the Partial Ordering", Proceedings of 11th Preserve the Partial Ordering", Proceedings of 11th
Australian Computer Science Conference, pp. 56-66, Australian Computer Science Conference, pp. 56-66,
February 1988. February 1988.
Appendix A. Change Log Appendix A. Change Log
The following changes have been made from version draft-knauf-p2psip- The following changes have been made from version
disco-04. draft-ietf-p2psip-disco-00.
1. Editorial improvements. 1. Editorial improvements.
2. Updated references. 2. Updated references.
The following changes have been made from version draft-knauf-p2psip- The following changes have been made from version
disco-03. draft-knauf-p2psip-disco-04.
1. Editorial improvements.
2. Updated references.
The following changes have been made from version
draft-knauf-p2psip-disco-03.
1. Adapted mechanisms for storing DisCo-Registrations to new 1. Adapted mechanisms for storing DisCo-Registrations to new
requirements of Shared Resources draft [I-D.knauf-p2psip-share] requirements of Shared Resources draft [I-D.ietf-p2psip-share]
The following changes have been made from version draft-knauf-p2psip- The following changes have been made from version
disco-02. draft-knauf-p2psip-disco-02.
1. DisCo-Registration uses now only the USER-CHAIN-ACL access 1. DisCo-Registration uses now only the USER-CHAIN-ACL access
control policy. control policy.
2. Adapted mechanisms for storing DisCo-Registrations to new 2. Adapted mechanisms for storing DisCo-Registrations to new
requirements of Shared Resources draft [I-D.knauf-p2psip-share] requirements of Shared Resources draft [I-D.ietf-p2psip-share]
The following changes have been made from version draft-knauf-p2psip- The following changes have been made from version
disco-01. draft-knauf-p2psip-disco-01.
1. The conference registration is now based on the Shared Resources 1. The conference registration is now based on the Shared Resources
draft [I-D.knauf-p2psip-share]: draft [I-D.ietf-p2psip-share]:
* DisCo-Registration Kind now meets the requirements for ShaRe. * DisCo-Registration Kind now meets the requirements for ShaRe.
* Conference creation procedure now uses the ShaRe Access List. * Conference creation procedure now uses the ShaRe Access List.
* Replaced USER-CHAIN-MATCH access policy for DisCo- * Replaced USER-CHAIN-MATCH access policy for DisCo-
Registration. Now uses USER-CHAIN-ACL or USER-PATTERN-MATCH. Registration. Now uses USER-CHAIN-ACL or USER-PATTERN-MATCH.
2. Allow focus peers behind NAT 2. Allow focus peers behind NAT
skipping to change at page 36, line 7 skipping to change at page 45, line 13
element. element.
4. Added a 'node-id' attribute to the event package XML <focus> 4. Added a 'node-id' attribute to the event package XML <focus>
element. element.
5. Added a 'coordinate' child element to the event package XML 5. Added a 'coordinate' child element to the event package XML
<focus> element. <focus> element.
6. Corrected typos/wording 6. Corrected typos/wording
The following changes have been made from version draft-knauf-p2psip- The following changes have been made from version
disco-00. draft-knauf-p2psip-disco-00.
1. Updated references. 1. Updated references.
2. Corrected typos. 2. Corrected typos.
3. New Section: Conference State Synchronization 3. New Section: Conference State Synchronization
4. XML Event Package for Distributed Conferences 4. XML Event Package for Distributed Conferences
5. New mechanism for generating chained conference certificates 5. New mechanism for generating chained conference certificates
skipping to change at page 36, line 37 skipping to change at page 46, line 15
Authors' Addresses Authors' Addresses
Alexander Knauf Alexander Knauf
HAW Hamburg HAW Hamburg
Berliner Tor 7 Berliner Tor 7
Hamburg D-20099 Hamburg D-20099
Germany Germany
Phone: +4940428758067 Phone: +4940428758067
Email: alexanderknauf@gmail.com Email: alexanderknauf@gmail.com
URI:
Thomas C. Schmidt Thomas C. Schmidt
HAW Hamburg HAW Hamburg
Berliner Tor 7 Berliner Tor 7
Hamburg D-20099 Hamburg D-20099
Germany Germany
Email: schmidt@informatik.haw-hamburg.de Email: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Gabriel Hege Gabriel Hege
daviko GmbH daviko GmbH
Am Borsigturm 50 Am Borsigturm 50
Berlin D-13507 Berlin D-13507
Germany Germany
Phone: +493043004344 Phone: +493043004344
Email: hege@daviko.com Email: hege@daviko.com
URI:
Matthias Waehlisch Matthias Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
Hoenower Str. 35 Hoenower Str. 35
Berlin D-10318 Berlin D-10318
Germany Germany
Email: mw@link-lab.net Email: mw@link-lab.net
URI: http://www.inf.fu-berlin.de/~waehl URI: http://www.inf.fu-berlin.de/~waehl
 End of changes. 68 change blocks. 
352 lines changed or deleted 361 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/