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/