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