idnits 2.17.1 draft-knauf-p2psip-disco-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 8, 2012) is 4364 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-21 ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-04 == Outdated reference: A later version (-21) exists of draft-ietf-p2psip-sip-07 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Knauf 3 Internet-Draft G. Hege 4 Intended status: Standards Track T C. Schmidt 5 Expires: November 9, 2012 HAW Hamburg 6 M. Waehlisch 7 link-lab & FU Berlin 8 May 8, 2012 10 A RELOAD Usage for Distributed Conference Control (DisCo) 11 draft-knauf-p2psip-disco-05 13 Abstract 15 This document defines a RELOAD Usage for Distributed Conference 16 Control (DisCo) with SIP. DisCo preserves conference addressing 17 through a single SIP URI by splitting its semantic of identifier and 18 locator using a new Kind data structure. Conference members are 19 enabled to select conference controllers based on proximity awareness 20 and to recover from failures of individual resource instances. DisCo 21 proposes call delegation to balance the load at focus peers. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 9, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Overview of DisCo . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Reference Scenario . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Initiating a Distributed Conference . . . . . . . . . . . 7 62 3.3. Joining a Conference . . . . . . . . . . . . . . . . . . . 8 63 3.4. Conference State Synchronization . . . . . . . . . . . . . 9 64 3.5. Call delegation . . . . . . . . . . . . . . . . . . . . . 10 65 3.6. Resilience . . . . . . . . . . . . . . . . . . . . . . . . 10 66 3.7. Topology Awareness . . . . . . . . . . . . . . . . . . . . 10 67 4. RELOAD Usage for Distributed Conference Control . . . . . . . 11 68 4.1. Shared Resource DisCo-Registration . . . . . . . . . . . . 11 69 4.2. Kind Data Structure . . . . . . . . . . . . . . . . . . . 11 70 4.3. Variable Conference Identifier . . . . . . . . . . . . . . 12 71 4.4. Conference Creation . . . . . . . . . . . . . . . . . . . 12 72 4.5. Advertising Focus Ability . . . . . . . . . . . . . . . . 13 73 4.6. Determining Coordinates . . . . . . . . . . . . . . . . . 14 74 4.7. Proximity-aware Conference Participation . . . . . . . . . 14 75 4.8. Configuration Document Extension . . . . . . . . . . . . . 16 76 5. Conference State Synchronization . . . . . . . . . . . . . . . 18 77 5.1. Event Package Overview . . . . . . . . . . . . . . . . . . 18 78 5.2. . . . . . . . . . . . . . . . . . 20 79 5.3. / . . . . . . . . . . . . . . . . 20 80 5.4. . . . . . . . . . . . . . . . . . 21 81 5.5. . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 5.5.1. . . . . . . . . . . . . . . . . . . . . 23 83 5.5.2. / . . . . . . . . . . . . . . . . . . . . 23 84 5.5.3. / . . . . . . . . . . . . . . . . 24 85 5.6. Distribution of Change Events . . . . . . . . . . . . . . 24 86 5.7. Translation to Conference-Info Event Package . . . . . . . 25 87 5.7.1. . . . . . . . . . . . . . . . . . . 26 88 5.7.2. . . . . . . . . . . . . . . . 26 89 5.7.3. . . . . . . . . . . . . . . . . . . . . . 26 90 5.7.4. . . . . . . . . . . . . . . . . . . 26 91 5.7.5. / . . . . . . . . . . . . . . . . . . . . 27 92 5.7.6. / . . . . . . . . 27 93 6. Distributed Conference Control with SIP . . . . . . . . . . . 28 94 6.1. Call delegation . . . . . . . . . . . . . . . . . . . . . 28 95 6.2. Conference Access . . . . . . . . . . . . . . . . . . . . 29 96 6.3. Media Negotiation and Distribution . . . . . . . . . . . . 30 97 6.3.1. Offer/Answer . . . . . . . . . . . . . . . . . . . . . 30 98 6.3.2. New Peers Joining . . . . . . . . . . . . . . . . . . 31 99 6.4. Restructuring a Conference . . . . . . . . . . . . . . . . 31 100 6.4.1. On Graceful Leave . . . . . . . . . . . . . . . . . . 31 101 6.4.2. On Unexpected Leave . . . . . . . . . . . . . . . . . 32 102 7. DisCo Kind Definition . . . . . . . . . . . . . . . . . . . . 33 103 8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 34 104 9. Relax NG Grammar . . . . . . . . . . . . . . . . . . . . . . . 38 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39 106 10.1. Trust Aspects . . . . . . . . . . . . . . . . . . . . . . 39 107 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 108 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 109 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 110 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 111 13.2. Informative References . . . . . . . . . . . . . . . . . . 43 112 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 44 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 115 1. Introduction 117 This document describes a RELOAD Usage for distributed conference 118 control (DisCo) in a tightly coupled model with SIP [RFC3261]. The 119 Usage provides self-organizing and scalable signaling that allows 120 RELOAD peers, clients and plain SIP user agents to participate in a 121 managed P2P conference. DisCo defines the following functions: 123 o A SIP protocol scheme for distributed conference control 125 o RELOAD Usage and definition of conferencing Kind 127 o Mechanisms for conference synchronization and call delegation 129 o Mechanism for proximity-aware routing within a conference 131 o An XML event package for distributed conferences 133 In this document, the term distributed conferencing refers to a 134 multiparty conversation in a tightly coupled model in which the point 135 of control (i.e., the focus) is identified by a unique URI, but the 136 focus service is located at many independent entities. Multiple SIP 137 [RFC3261] user agents uniformly control and manage a multiparty 138 session. This document defines a new Usage for RELOAD, including an 139 additional Kind code point with a corresponding data structure that 140 complies with the demands for distributed conferences. The 'DisCo' 141 data structure stores the mapping of a single conference URI to 142 multiple conference controllers and thereby separates the conference 143 identifier from focus instantiations. 145 Authorized controllers of a conference are permitted to register 146 their mapping in the DisCo data structure autonomously. Thus, the 147 DisCo data structure represents a co-managed Resource in RELOAD. To 148 provide trusted and secure access to a co-managed Resource, this 149 document uses the definitions for Shared Resources (ShaRe) 150 [I-D.knauf-p2psip-share]. 152 Delay and jitter are critical issues in multimedia communications. 153 The proposed conferencing scheme supports mechanisms to build an 154 optimized interconnecting graph between conference participants and 155 their responsible conference controllers. Conference members will be 156 enabled to select the closest focus with respect to delay or jitter. 158 DisCo extends conference control mechanisms to provide a consistent 159 and reliable conferencing environment. Controlling peers maintain a 160 consistent view of the entire conference state. The multiparty 161 system can be re-structured based on call delegation operations. 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 We use the terminology and definitions from der RELOAD base 170 draft[I-D.ietf-p2psip-base], the peer-to-peer SIP concepts draft 171 [I-D.ietf-p2psip-concepts], the usage for shared resources draft 172 [I-D.knauf-p2psip-share],and the terminology formed by the framework 173 for conferencing with SIP [RFC4353]. Additionally the following 174 terms are used: 176 Coordinate Value: An opaque string that describes a host's relative 177 position in the network topology. 179 Focus peer: A RELOAD peer that provides SIP conferencing functions 180 and implements the Usage for distributed conferencing. It is 181 called 'active' if already involved in signaling relation to 182 conference participants. Otherwise, if only registered in a 183 distributed conference data structure, it is referred to as a 184 'potential' focus peer. 186 3. Overview of DisCo 188 3.1. Reference Scenario 190 The reference scenario for the Distributed Conference Control (DisCo) 191 is shown in Figure 1. Peers are connected via a RELOAD 192 [I-D.ietf-p2psip-base] instance, in which peers A and B are managing 193 a single multiparty conference. The conference is identified by a 194 unique conference URI, but located at peers A and B fulfilling the 195 role of the focus. The mapping of the conference URI to one or more 196 responsible focus peers is stored in a new RELOAD Resource for 197 distributed conferencing within a data structure denoted as DisCo- 198 Registration. The storing peer SP of the distributed conference 199 resource holds this data. 201 The focus peers A and B maintain SIP signaling relations to 202 conference participants, which may have different conference protocol 203 capabilities. In this example, peer A is the focus for the RELOAD 204 peer C and the plain SIP user agent E whereas peer B serves as a 205 focus for RELOAD peer D and the RELOAD client F. 207 RELOAD peers and clients obtain the contact information for the 208 conference from the storing peer. In contrast to this, the user 209 agent E receives the conference URI not by RELOAD mechanisms, but 210 resolves the ID and joins the conference by plain SIP negotiation. 212 Focus peers maintain a SIP signaling relation among each other used 213 for notification messages that synchronize the conference focus 214 peers' knowledge about the entire conference state. Additionally, 215 focus peers can transfer calls to each other by a call delegation 216 mechanism. 218 +-------------------+ +------------------+ 219 |Access Control List| |DisCo-Registration| 220 +-------------------+ +------------------+ 221 \ / 222 +-------+ 223 |Storing| 224 # # # # # # # # # # | Peer | # # # # # # # # # # 225 # | SP | # 226 # +-------+ # 227 # # 228 # # 229 # # 230 +----+ +----+ 231 |Peer| \ RELOAD Instance |Peer| 232 | C | \ | D | 233 +----+ \ +----+ 234 # SIP # 235 # \ # 236 # \ # 237 # +-------+ +-------+ #( 238 # | Focus | | Focus | # ) 239 # # | Peer | # # # # # # # # # # # | Peer | # # ( 240 | A | <===Conf.Events/====> | B | ) 241 +-------+ Call delegation +-------+ Overlay 242 / \ Comm. 243 / \ ( 244 SIP SIP ) 245 / \ ( 246 / \ ) 247 +----------+ +--------+ 248 |User Agent| | Client | 249 | E | | F | 250 +----------+ +--------+ 252 Figure 1: Reference Scenario: Focus peers A,B maintain a distributed 253 conference 255 3.2. Initiating a Distributed Conference 257 To create a conference the initiating user agent announces itself as 258 a focus for the conference. It stores its own contact information 259 (Node-ID) as a DisCo-Registration Kind (cf. Figure 2) in the RELOAD 260 overlay. The hashed conference URI is used as the Resource-ID. This 261 Resource will later contain the contact IDs of all potential focus 262 peers including optional topological descriptors. 264 3.3. Joining a Conference 266 A RELOAD-aware node (cf. Bob in Figure 2) intending to join an 267 existing conference requests the list of potential focus peers stored 268 in the DisCo-Registration under the conference's Resource-ID. The 269 node selects any of the focus peers (e.g., Alice) and establishes a 270 connection using AppAttach/ICE [RFC5245]. This transport is then 271 used to send an INVITE to the conference applying the chosen focus as 272 the contact. The selection of the focus peer can optionally be based 273 on proximity information if available. 275 A conference member proposes itself as a focus for subsequent 276 participants by adding its Node-ID to the DisCo-Registration stored 277 under the conference URI in the RELOAD overlay. The decision whether 278 a peer announces as a focus incorporates bandwidth, power, and other 279 constraints, but details are beyond the scope of this document. 281 Alice RELOAD Bob 282 (initiating peer) (joining peer) 283 -------------------------------------------------------------------- 284 | | | 285 | Alice stores her mapping to register a conference | 286 | Store mapping(ConfURI, Alice) | | 287 |------------------------------>| | 288 | Bob requests the list of potential focus peers | 289 | | Lookup ConfURI | 290 | |<------------------------------| 291 | | Result list of conf. focus | 292 | |------------------------------>| 293 | | | 294 | Bob establishes transport connection to Alice | 295 | AppAttach | 296 |<--------------------------------------------------------------| 297 | AppAttach | 298 |-------------------------------------------------------------->| 299 | INVITE | 300 |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 301 | OK | 302 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| 303 | ACK | 304 |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 305 | Media | 306 |<=============================================================>| 307 | | | 308 | Bob stores his mapping to become a focus peer too | 309 | | Store mapping(ConfURI, Bob) | 310 | |<------------------------------| 311 | | | 313 Figure 2: DisCo Usage generic Call Flow 315 3.4. Conference State Synchronization 317 Each focus of a conference maintains signaling connections to its 318 related participants independently from other conference controllers. 319 This distributed conference design effects that the entire SIP 320 conference state is jointly held by all focus peers. In DisCo, state 321 synchronization is based on a SIP specific event notifications 322 mechanism [RFC3265]. 324 Each focus peer maintains its view of the entire conference state by 325 subscribing to the other focus peers' XML event package for 326 distributed conferences. This is based on the event package for 327 conference state (cf. [RFC4575]). Details are defined in this 328 document in Section 5. Receivers of event notifications update their 329 local conference state document to represent a valid view of current 330 total conference state. 332 The event notification package for distributed conferences enables 333 focus peers to synchronize the entire conference state. The event 334 package defines additional XML elements and complex types (see 335 Section 8 for more details), which describe the responsibilities of 336 any focus peer in the conference. By providing a global view each 337 focus peer is enabled to perform additional load balancing operations 338 and enhances the robustness against departures of focus peers. 340 3.5. Call delegation 342 Call delegation (see Section 6.1) is a feature used to transfer an 343 incoming participation request to another focus peer. It can be 344 applied to prevent overloading of focus peers. Call delegation is 345 realized through SIP REFER requests, which carry signaling and 346 session description information of the caller to be transferred. 347 This feature is achieved transparently for the transferred user agent 348 by using a source routing mechanism at SIP dialog establishment. 349 Descriptions of overload detection are beyond the scope of this 350 document. 352 3.6. Resilience 354 A focus peer can decide to leave the conference or may ungracefully 355 fail. In a traditional conferencing scenario, loss of the conference 356 controller or the media distributor would cause a complete failure of 357 the multiparty conversation. Distributed conferencing uses the 358 redundancy provided by multiple focus peers to reconfigure a current 359 multiparty conversation. Participants that loose their entry point 360 to the conference re-invite themselves via the remaining focus peers 361 or will be re-invited by the latter. This option is based on the 362 conference state and call delegation functions. 364 3.7. Topology Awareness 366 DisCo supports the optimization of the conference topology in respect 367 of the underlying network using topological descriptors. An 368 extension for the RELOAD XML configuration document is defined in 369 Section 4.8 to support landmarking approaches. Each peer intending 370 to create or participate in a distributed conference MAY determine a 371 topological descriptor that describes its relative position in the 372 network. Focus peers store these coordinate values in an additional 373 data field in the DisCo-Registration data structure. This enables 374 peers joining the conference to select the closest focus with respect 375 to its coordinate values. 377 4. RELOAD Usage for Distributed Conference Control 379 4.1. Shared Resource DisCo-Registration 381 A distributed conference is a cooperative service of several 382 individual devices that use a common identifier. To enable a mapping 383 from one conference identifier to multiple focus peers, this document 384 defines the new Kind data structure DisCo-Registration. The DisCo 385 Kind uses the definitions for Shared Resources 386 [I-D.knauf-p2psip-share] to allow a jointly maintenance by multiple 387 focus peers. Hence, write permission to a DisCo-registration is 388 shared by the conference creator with all authorized focus peers. 390 DisCo complies with the following requirements for Shared Resources: 392 Isolated Data Storage: DisCo uses the dictionary data model. Each 393 dictionary key is the Node-ID of the certificate that will be used 394 to sign the stored data 396 ResourceNameExtension field: A DisCo-Registration can contain the 397 ResourceNameExtension structure an initial field in the Kind data 398 structure. It contains the conference URI of the registered 399 DisCo-record. 401 4.2. Kind Data Structure 403 Each DisCo-Registration data structure stores a mapping of a 404 conference identifier to one or multiple focus peers that 405 cooperatively control the conference. Additionally, each DisCo- 406 Registration provides the coordinate value, which indicates the 407 relative network position of the focus peers. 409 The data structure uses the RELOAD dictionary type. The dictionary 410 key MUST be the Node-ID of the focus peer that is associated with the 411 dictionary entry. This allows a focus peer to update only its own 412 mapping. The DisCo data structure of type DisCoRegistration is 413 constructed as follows: 415 struct { 416 /* This field is optional, see documentation */ 417 ResourceNameExtension res_name_ext; 418 opaque coordinate<0..2^16-1>; 419 NodeId node_id; 420 } DisCoRegistration; 422 The DisCoRegistration structure is composed of the following values: 424 res_name_ext: This field can contain the conference URI. It meets 425 the requirement for the USER-CHAIN-ACL access policy defined in 426 [I-D.knauf-p2psip-share] to enable variable resource names. 428 coordinate: This field contains a topological descriptor that 429 indicates the relative position of the peer in the network. To 430 support different algorithms the coordinate field is represented 431 as an opaque string. 433 node_id: This field contains the Node-ID of the peer storing the 434 DisCoRegistration and is used to contact the peer when utilizing 435 its service as a focus. 437 4.3. Variable Conference Identifier 439 DisCo-Registrations can be stored based on a variable Resource Name. 440 However, a conference identifier set by a user MUST follow the 441 requirements for Kinds using variable Resource Names as defined in 442 the ShaRe Usage [I-D.knauf-p2psip-share]. 444 4.4. Conference Creation 446 The registration of a distributed conference includes the storage of 447 the following two Kinds (see Figure 3). 449 DisCo-Registration Kind: contains the conference identifier and the 450 optional coordinate value. If used, the coordinate value MAY be 451 determined previously to the conference registration. The 452 Resource Name and hence the Resource-ID is defined by the hash 453 over the desired conference identifier (using the hash algorithm 454 of the overlay). 456 Access Control List Kind: contains the conference participants that 457 are allowed to register as focus peers for a conference (see 458 [I-D.knauf-p2psip-share]). Its Resource Name/ID is equal to those 459 of the corresponding DisCo-Registration. 461 Preliminary to storage of DisCo-Registration and Access Control List 462 (ACL) Kinds the conference creator SHOULD perform a RELOAD StatReq to 463 verify that no former conference is present. If neither a DisCo- 464 Registration nor an associated ACL exist, the conference creator 465 stores a DisCo-Registration with a valid conference identifier (see 466 Section 4.3) and an ACL referring to the DisCo-Registration Kind-ID. 468 If DisCo registrations and ACL Kinds from previous conferences are 469 still existing there are two options. First, if conference creator 470 is aware of the indexes from previous ACL Kinds, it refreshes the 471 root item of this ACL and stores its registration as focus peer as 472 DisCo-Registration Kind. Second, If the creator is unaware of 473 indexes, it fetches all Access List Kinds to determine the index of 474 the root item. 476 Alice Peer1 Overlay PeerN Storing Peer 477 ------------------------------------------------------------- 478 | StatReq Res:Conf-URI | | 479 |------------>|----------->|----------->|----------->| 480 | StatAns | | | 481 |<------------|<-----------|<-----------|<-----------| 482 | StoreReq Res:Conf-URI Kinds:DisCo, Access-List | 483 |------------>|----------->|----------->|----------->| 484 | StoreAns | | | 485 |<------------|<-----------|<-----------|<-----------| 486 | | | | | 488 Figure 3: Initial creation of a Distributed Conference 490 Optionally the conference initiator (or any active focus) MAY store 491 an additional RELOAD SIP-Registration in the overlay 492 [I-D.ietf-p2psip-sip] or even at a standard SIP registrar [RFC3261] 493 under a URI for which it has write permission. This allows DisCo- 494 unaware or even legacy SIP user agents to participate in the 495 conference. Those registrations SHOULD always point to a currently 496 active focus, who is prepared to accept legacy user agents. The user 497 agent who initially performed the registrations is responsible for 498 updating them appropriately. How authorization has been obtained to 499 perform those registration is out of scope of this document. 501 The lifetime of a distributed conference is not necessarily limited 502 by the participation time of its creator. As long as the root item 503 of an Access Control List to a DisCo-Registration is not expired, 504 Authorized Peers are allowed to further provide a conferencing 505 service and even store new focus registrations. 507 4.5. Advertising Focus Ability 509 All participants of a distributed conference MAY potentially become a 510 focus peer for their conference. This depends on its capacities such 511 as sufficient processing power (CPU, Memory) for the desired media 512 type, the quality of the network connectivity, and the conference 513 policy. Information about network connectivity with respect to NAT 514 or restricted firewalls can be obtained via ICE [RFC5245] 515 connectivity checks. If a peer is behind a NAT, it SHOULD allow for 516 incoming connections via AppAttach/ICE. Peers that can only accept 517 connections with the support of TURN should not act as a focus. 519 Nevertheless, under special circumstances it might be reasonable to 520 locate a focus peer behind such a NAT (e.g., within a companies 521 network infrastructure). 523 If a participant is a candidate to become a focus for the conference, 524 it stores its Node-ID and optional coordinate value into the DisCo 525 data structure. An entry in the corresponding ACL 526 [I-D.knauf-p2psip-share] must be present to allow this peer to write 527 the DisCo-Registration resource. By storing the mapping into the 528 data structure a participant becomes a potential focus. 530 4.6. Determining Coordinates 532 Each RELOAD peer within the context of a distributed conference MAY 533 be aware of its relative position in the network topology. To 534 constuct a topology-aware conference, the DisCo Usage provides the 535 coordinate value within the DisCo-Registration data structure. Focus 536 peers store their relative network position together with the 537 announcement as conference focus. Joining peers that are able to 538 determine their coordinates may then select a focus peer whose 539 relative position is in its vicinity (see Section 4.7). 541 Some algorithms determine topology information by measuring Round- 542 Trip Times (RTT) towards a set of hosts serving as landmarks (e.g., 543 [landmarks-infocomm02]). To support such algorithms this document 544 describes an extension to the RELOAD XML configuration document that 545 allows to configure the set of landmark hosts peer must use for 546 position estimation (see Section 4.8). Once a focus peer has 547 registered its mapping in the DisCo data structure, it also stores 548 the according coordinates in the same mapping. These vectors are used by peers joining the conference to 550 select the focus peer that is relatively closest to itself. 552 Because topology-awareness can be obtained by many different 553 approaches a concrete algorithms is out of scope of this document. 555 4.7. Proximity-aware Conference Participation 557 The participation procedure to a distributed conference is composed 558 of three operation. 560 1. Resolution of the conference identifier. 562 2. Establishment of of transport connection. 564 3. SIP signaling to join a conference. 566 Figure 4 and the following specifications give a more detailed view 567 on the joining procedure. 569 Bob Peer1 Overlay PeerN Storing Peer Alice 570 -------------------------------------------------------------- 571 | StatReq Res:Conf-URI | | | 572 |--------->|--------->|--------->|--------->| | 573 | |StatAns | | | | 574 |<---------|<---------|<---------|<---------| | 575 | FetchReq Res:Conf-URI Kind:DisCo,ACL | | 576 |--------->|--------->|--------->|--------->| | 577 | |FetchAns | | | | 578 |<---------|<---------|<---------|<---------| | 579 | | | | | | 580 | Bob calculates Alice as closest Focus | | 581 | | | | | | 582 | |AppAttach application:5060 | | 583 |--------->|--------->|--------->|--------->|--------->| 584 | |AppAttach application:5060 | | 585 |<---------|<---------|<---------|<---------|<---------| 586 | | | | | | 587 |<-------------------ICE Checks----------------------->| 588 | | | | | | 589 | | INVITE sip:Alice | | 590 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| 591 | | 200 OK | | | 592 |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 593 | | ACK | | | 594 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| 595 | | | | | | 597 Figure 4: Participation of a Distributed Conference 599 1. The joining peer MAY determine its own coordinate value (if 600 used). 602 2. The joining peer sends a StatReq message to obtain all indexes of 603 the Access Control List (ACL) Kinds stored. 605 3. The joining peer sends a FetchReq message for the DisCo and ACL 606 Kind to the Resource-ID of the conference URI. The FetchReq 607 SHOULD NOT include any specific dictionary keys, but SHOULD fetch 608 for those array ranges previously determined the StatReq. With 609 the ACL items, the joining peer is able to verify whether DisCo- 610 Registrations are stored by authorized focus peers (see 611 [I-D.knauf-p2psip-share]). 613 4. Using the retrieved coordinates values of the DisCo- 614 Registrations, the joining peer MAY calculate which of than 615 opaque <0..2^16-1> initial field in the Kind data structure focus 616 peers is the relatively closest to itself. 618 5. The joining peer then establishes a transport using RELOADs 619 AppAttach, respectively, ICE procedures to create a transport to 620 the chosen focus peer. 622 6. Finally, the established transport is used to create a SIP dialog 623 from the joining peer to the focus peers. 625 The SIP INVITE request MAY contain the joining peer's topological 626 descriptor as a URI-parameter called 'coord' in the contact-header in 627 base64 encoded form [RFC4648]. An example contact URI is "sip:alice@ 628 example.com;coord=PEknbSBhIHRvcG9sb2dpY2FsIGRlc2NyaXB0b3I+". When 629 the called focus is full and needs to delegate the call it uses the 630 contents of the 'coord'-parameter. It determines the next available 631 focus closest to the calling peer (Section 4.6) using the received 632 descriptor and the other focuses' descriptors from the conference 633 state synchronization document and delegates the call accordingly 634 (see Section 6.1). 636 A conference focus MAY allow the joining peer to also become a focus 637 (depending on the conference policy see Section 6.2). Therefore, it 638 stores a new ACL Kind that delegates write permission for the DisCo- 639 Registration to the new participant. It sets the 'user_name' field 640 in the ACL Kind to its own user name and sets the 'to_user' field to 641 the user name of the joining peer. If no other conference policy is 642 defined, the focus peer MAY set the allow_delegation flag to true. 643 For further details about the trust delegation using the ACL Kind see 644 [I-D.knauf-p2psip-share]. 646 4.8. Configuration Document Extension 648 This section defines an additional parameter for the 649 element that extends the RELOAD XML configuration document. The 650 proposed element allows RELOAD provider to publish a set 651 of accessible and reliable hosts that SHOULD be used if RELOAD peers 652 use landmarking algorithms to determine relative position in the 653 network topology. 655 The element serves as container for the 656 sub-elements, each representing a single host that serves as a 657 landmark. The uses the following attributes: 659 address: The IP address (IPv4 or IPv6) of the landmark host. 661 port: The port on which the landmark host responds for distance 662 estimation. 664 More than one landmark hosts SHOULD be present in the configuration 665 document. 667 5. Conference State Synchronization 669 The global knowledge about signaling and media relations among the 670 conference participants and focus peers defines the global state of a 671 distributed conference. It is composed of the union of every local 672 state at the focus peers. To enable focus peers to provide 673 conference control operations that modify and/or require the global 674 state of a conference, this document defines a mechanism for inter- 675 focus state synchronization. It is based on mutual subscriptions for 676 an Event Package for Distributed Conferences and allows to preserve a 677 coherent knowledge of the global conference state. This XML based 678 event package named 'distributed-conference' MUST be supported by 679 each RELOAD peer that is registered with a DisCo-Registration. 680 Participants of a distributed conference MAY support it. To provide 681 backward compatibility to conference members that do not support the 682 distributed-conference event package, this document defines a 683 translation to the Event Package for Conference State [RFC4575]. 685 5.1. Event Package Overview 687 The 'distributed-conference' event package is designed to convey 688 information about roles and relations of the conference participants. 689 Conference controllers obtain the global state of the conference and 690 use this information for load balancing or conference restructuring 691 mechanisms in case of a focus failure. Figure Figure 5 gives a 692 general overview of the document hierarchy. 694 distributed-conference 695 | 696 |-- version-vector 697 | |-- version 698 | |-- version 699 | 700 |-- conference-description 701 | 702 |-- focus 703 | |-- focus-state 704 | | |-- user-count 705 | | |-- coordinate 706 | | |-- maximum-user-count 707 | | |-- active 708 | | |-- locked 709 | | |-- conf-uris 710 | | |-- available-media 711 | | 712 | |-- users 713 | | |-- user 714 | | | |-- endpoint 715 | | | | |-- media 716 | | | | |-- call-info 717 | | 718 | |-- relations 719 | | |-- relation 720 |-- focus 721 | |-- ... 723 Figure 5: Overview of the event package for distributed conferences 725 The document structure is designed to allow concurrent change events 726 at several focus peers. To prevent race conditions each focus peer 727 has exclusive writing permission to the 'focus' sub element that 728 describes itself. It is achieved by a unique mapping from a focus 729 peer to its XML element using the 'Element Keys' mechanisms for 730 partial notification [RFC4575](sections 4.4-5.). A focus peer is 731 only allowed to update or change that sub element, whose 732 'entity' Element Key contains its RELOAD user name. This restriction 733 also applies to the child elements of the 'version-vector' element. 734 Each 'version' number belongs to a specific focus peer maintaining 735 the version number. 737 The local state of a focus peer is described within a 'focus' 738 element. It provides general information about a focus peer and its 739 signaling and media relations to participants and focus peers. The 740 Conference participants are aggregated within 'users' elements, 741 respectively, 'user' sub elements. 743 General information about the conference as a whole, is provided 744 within a 'conference-description' element. In contrast to the 745 'focus' and 'version-vector' elements, conference description is not 746 meant for concurrent updating. Instead, it provides static 747 conference descriptions that rarely change during a multiparty 748 session. 750 More detailed descriptions about the event package and its elements 751 are provided in the following sections. The complete XML schema 752 definition is given in Section 8. 754 5.2. 756 The element is the root of a distributed 757 conference XML document. It uses the following attributes: 759 entity: This attribute contains the conference URI that identifies 760 the distributed conference. A SIP SUBSCRIBE request addressed to 761 this URI initiates an subscribe/notify relation between 762 participants and their related focus peer. 764 state: This attribute indicates whether the content of a distributed 765 conference document is a 'full', 'partial' or 'deleted' 766 information. It is in accordance with [RFC4575] to enable the 767 partial notification mechanism. 769 The child elements are , 770 and the elements. An event 771 notification of state 'full' MUST include all these elements. An 772 event notification of state 'partial' MUST contain at least and its sub elements. 775 5.3. / 777 The Event Package for Distributed Conferences uses the and its sub elements to enable a coherent 779 versioning scheme. It is based on vector clocks as defined in 780 [timestamps-acsc88]. Each element contains a unsigned 781 integer that describes the state of a specific focus peer and 782 contains the following attributes: 784 entity: This attribute contains the user name of the focus peer 785 whose local version number is described by this element. 787 node-id: This attribute contains the Node-ID of the focus peer. 789 Whenever the local status of a focus peer changes (e.g. a new 790 participant arrived) the version number of the corresponding 791 element MUST be incremented by one. Each change in the 792 local state also triggers a new event notification containing the 793 entire and the changes contained in a 794 element. 796 The recipient of a change event needs to update it local XML 797 document. If a received number is higher that the local, 798 it updates the element and its associated element 799 with the retrieved elements. All other elements remain constant. 801 If the length or contents of the retrieved is 802 different to the local copy it indicates a incoherent knowledge about 803 the entire conference state. If the retrieved 804 contains any unknown focus peers and any local version numbers for 805 the known focus peers is lower, the receiver SHOULD request a 'full' 806 XML notification. 808 If any local number is retarded more than one, the receiver 809 SHOULD request a 'full' event notification from the sender. The full 810 state notification updates all elements whose corresponding 811 element is out of date. 813 5.4. 815 The element provides general information and 816 links to auxiliary services for the conference. The following sub 817 elements provide human-readable text descriptions about the 818 conference: 820 : Contains a short textual description about the 821 conference 823 : Contains the subject of the conference 825 : Contains a longer textual description about the 826 conference 828 : Contains a list of keywords that match the conference 829 topic. The XML schema definition and semantic is imported from 830 the 'conference-info' event package [RFC4575]. 832 The sub element enables focus peers to advertise 833 auxiliary services for the conference. The XML schema definition and 834 semantic is imported from the 'conference-info' event package 835 [RFC4575]. 837 The element uses the 'state' Element Key to 838 enable the partial notification mechanism. 840 5.5. 842 Each element describes a focus peer actively controlling the 843 conference. It provides general information about a focus peer 844 (e.g., display-text, languages, etc.), contains conference specific 845 information about the state of a focus peer (user-count, available 846 media types, etc.) and announces signaling and media information 847 about the maintained participants. Additionally, it describes 848 signaling or media relations to further focus peers. 850 The element uses the following attributes: 852 entity: This attribute contains the user name of the RELOAD peer 853 acting as focus peer. It uniquely identifies the focus peer that 854 is allowed to update or change all sub elements of . All 855 other focus peers SHOULD NOT update or change sub elements of this 856 element. A SUBSCRIBE request addressed to the user name 857 initiates a conference state synchronization with the focus peer. 859 Node-ID This attributed contains the Node-ID of the peer acting as 860 conference focus 862 state: In accordance to [RFC4575], this attribute indicates whether 863 the content of the element is a 'full', 'partial' or 864 'deleted' information. A 'partial' notification contains at 865 maximum a single element. 867 The following sub elements of provide general information 868 about a focus peer: 870 : Contains a short text description of the user acting 871 as focus peer. 873 : This element contains additional URIs that are 874 associated with this user. 876 This element MAY contain human-readable text descriptions 877 about the roles of the user in the conference. 879 : This element contains a list of tokens, each describing 880 a language understood by the user. 882 The XML schema definition and semantic for , 883 and are imported from the 'conference-info' event package 884 [RFC4575] 886 Following, a detailed description of the remaining sub elements. 888 5.5.1. 890 The element aggregates a set of conference specific 891 information about the RELOAD user acting as focus peer. The 892 following attribute is defined for the element: 894 status: This attribute indicates whether the content of the element is a 'full', 'partial' or 'deleted' information. 897 The element has the following sub elements: 899 : This element contains the number of participants that 900 are connected to the conference via this focus peer at a certain 901 moment. 903 This element contains the coordinate value Section 4.2 904 of the focus peer 906 : This number indicates a threshold of 907 participants a focus peer is able to serve. This value might 908 change during a conference, depending on the focus peers current 909 load. 911 : This element MAY contain other conference URIs in order 912 to access the conference via different signaling means. The XML 913 schema definition and semantic is imported from [RFC4575]. 915 : This element is imports the type XML scheme definitions from [RFC4575]. It allows a 917 focus peer to list its available media streams. 919 : This boolean element indicates whether a focus peer is 920 currently active. Conference participation requests or a call 921 delegation request SHOULD succeed. 923 : In contrast to , this element indicates that a 924 focus peer is not willing to accept anymore participation or call 925 delegation request. 927 5.5.2. / 929 The , respectively, each element describes a single 930 participant that is maintained by the focus peer described by the 931 parent element. The element XML schema definition 932 and its semantic is imported from the 'conference-info' event package 933 [RFC4575]. 935 5.5.3. / 937 The element serves as container for elements, 938 each describing a specific connection to another focus peer. The 939 parent element uses the 'state' attribute to enable the 940 partial notification mechanism. For the element the 941 following attributes are defined: 943 entity: This attribute contains the user name of the remote focus. 945 node-id This attribute contains the Node-ID of the remote focus 946 peer. 948 The content of each is a comma separated string that 949 describes the tuple . The CONNECTION- 950 TYPE is a string token describing the type of connection (e.g. media, 951 signaling, etc.) and the IDENTIFIER contains a variable connection 952 identifier. It is a generic method to announce any kind of 953 connection to a remote focus. This specification defines following 954 tuples: 956 media: