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