idnits 2.17.1 draft-ietf-p2psip-disco-02.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 (August 1, 2013) is 3922 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 (-10) exists of draft-ietf-p2psip-share-01 == Outdated reference: A later version (-21) exists of draft-ietf-p2psip-sip-11 ** 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-05 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: February 2, 2014 G. Hege 6 daviko GmbH 7 M. Waehlisch 8 link-lab & FU Berlin 9 August 1, 2013 11 A RELOAD Usage for Distributed Conference Control (DisCo) 12 draft-ietf-p2psip-disco-02 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 February 2, 2014. 41 Copyright Notice 43 Copyright (c) 2013 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 and 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.ietf-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.ietf-p2psip-share],as well as selected terms defined in SIP 174 [RFC3261] and the framework for conferencing with SIP [RFC4353]. 175 Additionally, the following terms are used: 177 Coordinate Value: An opaque string that describes a host's relative 178 position in the network topology. 180 DisCo Peer: A RELOAD Peer that provides SIP conferencing functions 181 and implements the Usage for distributed conferencing. 183 Focus Peer: A DisCo Peer that has registered itself in the overlay 184 as a focus for one or several conferences. It is called 'active' 185 if already involved in signaling relations to conference 186 participants. Every DisCo Peer can potentially serve as a Focus 187 Peer. 189 3. Overview of DisCo 191 3.1. Reference Scenario 193 The reference scenario for the Distributed Conference Control (DisCo) 194 is shown in Figure 1. Peers are connected via a RELOAD 195 [I-D.ietf-p2psip-base] instance, in which peers A and B are managing 196 a single multiparty conference. The conference is identified by a 197 unique conference URI, but located at peers A and B fulfilling the 198 role of the focus, see [RFC4353]. The mapping of the conference URI 199 to the responsible focus peers A and B is stored in a new RELOAD 200 Resource for distributed conferencing within a data structure denoted 201 as DisCo-Registration. The storing peer SP of the distributed 202 conference resource holds this data. 204 The focus peers A and B maintain SIP signaling relations to 205 conference participants, which can have different conference protocol 206 capabilities. In this example, peer A is the focus for the RELOAD 207 peer C and the plain SIP user agent E, whereas peer B serves as a 208 focus for RELOAD peer D and the RELOAD client F. 210 RELOAD peers and clients obtain the contact information for the 211 conference from the storing peer. In contrast to this, the user 212 agent E receives the conference URI not by RELOAD mechanisms, but 213 resolves the ID and joins the conference by plain SIP negotiation. 215 Focus peers maintain mutual SIP signaling relations among each other 216 used for synchronizing the conference event states. Additionally, 217 focus peers can transfer calls between each other by a call 218 delegation mechanism. 220 +-------------------+ +------------------+ 221 |Access Control List| |DisCo-Registration| 222 +-------------------+ +------------------+ 223 \ / 224 +-------+ 225 |Storing| 226 # # # # # # # # # # | Peer | # # # # # # # # # # 227 # | SP | # 228 # +-------+ # 229 # # 230 # # 231 # # 232 +----+ +----+ 233 |Peer| \ RELOAD Instance |Peer| 234 | C | \ | D | 235 +----+ \ +----+ 236 # SIP # 237 # \ # 238 # \ # 239 # +-------+ +-------+ #( 240 # | Focus | | Focus | # ) 241 # # | Peer | # # # # # # # # # # # | Peer | # # ( 242 | A | <===Conf.Events/====> | B | ) 243 +-------+ Call delegation +-------+ Overlay 244 / \ Comm. 245 / \ ( 246 SIP SIP ) 247 / \ ( 248 / \ ) 249 +----------+ +--------+ 250 |User Agent| | Client | 251 | E | | F | 252 +----------+ +--------+ 254 Figure 1: Reference Scenario: Focus peers A,B maintain a distributed 255 conference 257 3.2. Initiating a Distributed Conference 259 A DisCo Peer that wishes to initiate a distributed conference first 260 obtains an unused conference URI, and second announces itself as a 261 Focus Peer for this conference. It stores its own contact 262 information (Node-ID) as a DisCo-Registration Kind (cf., Figure 2) in 263 the RELOAD overlay, using the hashed conference URI as the 264 Resource-ID. This Shared Resource will later accumulate the contact 265 IDs of all potential focus peers including optional topological 266 descriptors. 268 3.3. Joining a Conference 270 A RELOAD-aware node (cf., Bob in Figure 2) intending to join an 271 existing conference requests the list of Focus Peers stored in the 272 DisCo-Registration for this conference Resource-ID. The node selects 273 one of the Focus Peers (e.g., Alice) and establishes a direct SIP or 274 SIPS connection as defined in Section 5 of [I-D.ietf-p2psip-sip]. 275 This transport connection is then used for a regular conference 276 INVITE in SIP. The selection of the focus peer can optionally be 277 based on proximity information if available. 279 A conference member can propose itself as a focus for subsequent 280 participants by adding its Node-ID to the DisCo-Registration stored 281 under the conference URI in the RELOAD overlay. The decision whether 282 to announce as a focus, are likely to account for system and network 283 resources as well as other constraints, the details of which are 284 beyond the scope of this document. 286 Alice RELOAD Bob 287 (initiating peer) (joining peer) 288 -------------------------------------------------------------------- 289 | | | 290 | Alice stores her mapping to register a conference | 291 | Store mapping(ConfURI, Alice) | | 292 |------------------------------>| | 293 | Bob requests the list of potential focus peers | 294 | | Lookup ConfURI | 295 | |<------------------------------| 296 | | Result list of conf. focus | 297 | |------------------------------>| 298 | | | 299 | Bob establishes transport connection to Alice | 300 | AppAttach | 301 |<--------------------------------------------------------------| 302 | AppAttach | 303 |-------------------------------------------------------------->| 304 | INVITE | 305 |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 306 | OK | 307 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| 308 | ACK | 309 |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 310 | Media | 311 |<=============================================================>| 312 | | | 313 | Bob stores his mapping to become a focus peer too | 314 | | Store mapping(ConfURI, Bob) | 315 | |<------------------------------| 316 | | | 318 Figure 2: DisCo Usage generic Call Flow 320 3.4. Conference State and Synchronization 322 In a distributed conference, each Focus Peer maintains signaling 323 connections to its related participants independently of other 324 conference controllers, while each Focus Peer has a full view of the 325 entire conference state. In DisCo, state synchronization is required 326 and based on the SIP-specific event notification [RFC3265]. For this 327 purpose, Focus Peers establish mutual connections for exchanging 328 state changes. An application layer multicast could also be used in 329 future versions of this protocol. 331 DisCo conference state is described by an extension of the SIP 332 conference event package (see [RFC4575] and Section 8 for more 333 details). The event notification package for distributed conferences 334 enables Focus Peers to synchronize conference state by subscribing to 335 the corresponding event packages of other focus peers. Receivers of 336 event notifications update their local conference state document to 337 represent a valid view of current total conference state. Details 338 are defined in this document in Section 5.By providing a global view 339 each focus peer is enabled to perform additional load balancing 340 operations and enhances the robustness against departures of focus 341 peers. 343 3.5. Call delegation 345 Call delegation (see Section 6.1) is a feature used to transfer an 346 incoming participation request to another focus peer. It can be 347 applied for traffic optimization, load balancing and to prevent 348 overloading of individual peers. Call delegation is achieved through 349 SIP REFER requests, which carry signaling and session description 350 information of the caller to be transferred. This feature remains 351 transparent for the transferred user agent by using a source routing 352 mechanism at SIP dialog establishment. Algorithms for optimization 353 and misbalance detection are beyond the scope of this document. 355 3.6. Resilience 357 A focus peer can decide to leave the conference or could ungracefully 358 fail. In a traditional conferencing scenario, loss of the conference 359 controller or the media distributor would cause a complete failure of 360 the multiparty conversation. Distributed conferencing uses the 361 redundancy provided by multiple Focus Peers to reconfigure a current 362 multiparty conversation. Participants that loose their entry point 363 to the conference can re-invite themselves via the remaining focus 364 peers or will be re-invited by the latter. This option is based on 365 the conference state and call delegation functions. 367 3.7. Topology Awareness 369 DisCo supports the optimization of the conference topology with 370 respect to the underlying network using topological descriptors. An 371 extension for the RELOAD XML configuration document is defined in 372 Section 4.8 to support landmarking approaches. Each peer intending 373 to create or participate in a distributed conference is enabled to 374 determine a topological descriptor that expresses its relative 375 position in the network. Focus Peers store these coordinate values 376 in an additional data field in the DisCo-Registration data structure. 377 This enables joining peers to select the closest focus with respect 378 to its coordinate values. 380 4. RELOAD Usage for Distributed Conference Control 382 4.1. Shared Resource DisCo-Registration 384 A distributed conference is a cooperative service of several 385 individual devices that use a common identifier. To enable a mapping 386 from one conference identifier to multiple focus peers, this document 387 defines the new Kind data structure DisCo-Registration. The DisCo 388 Kind uses the definitions for Shared Resources 389 [I-D.ietf-p2psip-share] to allow a jointly maintenance by multiple 390 focus peers. Hence, write permission to a DisCo-registration is 391 shared by the conference creator with all authorized focus peers. 393 DisCo complies with the following requirements for Shared Resources: 395 Isolated Data Storage: DisCo uses the dictionary data model. Each 396 dictionary key is the Node-ID of the certificate that will be used 397 to sign the stored data 399 ResourceNameExtension field: A DisCo-Registration can contain the 400 ResourceNameExtension structure an initial field in the Kind data 401 structure. It contains the conference URI of the registered 402 DisCo-record. 404 4.2. Kind Data Structure 406 Each DisCo-Registration data structure stores a mapping of a 407 conference identifier to one or multiple focus peers that 408 cooperatively control the conference. Additionally, each DisCo- 409 Registration provides the coordinate value, which indicates the 410 relative network position of the focus peers. 412 The data structure uses the RELOAD dictionary type. The dictionary 413 key MUST be the Node-ID of the focus peer that is associated with the 414 dictionary entry. This allows a focus peer to update only its own 415 mapping. The DisCo data structure of type DisCoRegistration is 416 constructed as follows: 418 struct { 419 /* This field is optional, see documentation */ 420 ResourceNameExtension res_name_ext; 421 opaque coordinate<0..2^16-1>; 422 NodeId node_id; 423 } DisCoRegistration; 425 The DisCoRegistration structure is composed of the following values: 427 res_name_ext: This field can contain the conference URI. It meets 428 the requirement for the USER-CHAIN-ACL access policy defined in 429 [I-D.ietf-p2psip-share] to enable variable resource names. 431 coordinate: This field contains a topological descriptor that 432 indicates the relative position of the peer in the network. To 433 support different algorithms the coordinate field is represented 434 as an opaque string. 436 node_id: This field contains the Node-ID of the peer storing the 437 DisCoRegistration and is used to contact the peer when utilizing 438 its service as a focus. 440 4.3. Variable Conference Identifier 442 DisCo-Registrations can be stored based on a variable Resource Name. 443 However, a conference identifier set by a user MUST follow the 444 requirements for Kinds using variable Resource Names as defined in 445 the ShaRe Usage [I-D.ietf-p2psip-share]. 447 4.4. Conference Creation 449 The registration of a distributed conference includes the storage of 450 the following two Kinds (see Figure 3). 452 DisCo-Registration Kind: contains the conference identifier and the 453 optional coordinate value. If used, the coordinate value MAY be 454 determined previously to the conference registration. The 455 Resource Name and hence the Resource-ID is defined by the hash 456 over the desired conference identifier (using the hash algorithm 457 of the overlay). 459 Access Control List Kind: contains the conference participants that 460 are allowed to register as focus peers for a conference (see 461 [I-D.ietf-p2psip-share]). Its Resource Name/ID is equal to those 462 of the corresponding DisCo-Registration. 464 Preliminary to storage of DisCo-Registration and Access Control List 465 (ACL) Kinds the conference creator SHOULD perform a RELOAD StatReq to 466 verify that no former conference is present. If neither a DisCo- 467 Registration nor an associated ACL exist, the conference creator 468 stores a DisCo-Registration with a valid conference identifier (see 469 Section 4.3) and an ACL referring to the DisCo-Registration Kind-ID. 471 If DisCo registrations and ACL Kinds from previous conferences are 472 still existing there are two options. First, if conference creator 473 is aware of the indexes from previous ACL Kinds, it refreshes the 474 root item of this ACL and stores its registration as focus peer as 475 DisCo-Registration Kind. Second, If the creator is unaware of 476 indexes, it fetches all Access List Kinds to determine the index of 477 the root item. 479 Alice Peer1 Overlay PeerN Storing Peer 480 ------------------------------------------------------------- 481 | StatReq Res:Conf-URI | | 482 |------------>|----------->|----------->|----------->| 483 | StatAns | | | 484 |<------------|<-----------|<-----------|<-----------| 485 | StoreReq Res:Conf-URI Kinds:DisCo, Access-List | 486 |------------>|----------->|----------->|----------->| 487 | StoreAns | | | 488 |<------------|<-----------|<-----------|<-----------| 489 | | | | | 491 Figure 3: Initial creation of a Distributed Conference 493 Optionally the conference initiator (or any active focus) MAY store 494 an additional RELOAD SIP-Registration in the overlay 495 [I-D.ietf-p2psip-sip] or even at a standard SIP registrar [RFC3261] 496 under a URI for which it has write permission. This allows DisCo- 497 unaware or even legacy SIP user agents to participate in the 498 conference. Those registrations SHOULD always point to a currently 499 active focus, who is prepared to accept legacy user agents. The user 500 agent who initially performed the registrations is responsible for 501 updating them appropriately. How authorization has been obtained to 502 perform those registration is out of scope of this document. 504 The lifetime of a distributed conference is not necessarily limited 505 by the participation time of its creator. As long as the root item 506 of an Access Control List to a DisCo-Registration is not expired, 507 Authorized Peers are allowed to further provide a conferencing 508 service and even store new focus registrations. 510 4.5. Advertising Focus Ability 512 All participants of a distributed conference MAY potentially become a 513 focus peer for their conference. This depends on its capacities such 514 as sufficient processing power (CPU, Memory) for the desired media 515 type, the quality of the network connectivity, and the conference 516 policy. Information about network connectivity with respect to NAT 517 or restricted firewalls can be obtained via ICE [RFC5245] 518 connectivity checks. If a peer is behind a NAT, it SHOULD allow for 519 incoming connections via AppAttach/ICE. Peers that can only accept 520 connections with the support of TURN should not act as a focus. 522 Nevertheless, under special circumstances it might be reasonable to 523 locate a focus peer behind such a NAT (e.g., within a companies 524 network infrastructure). 526 If a participant is a candidate to become a focus for the conference, 527 it stores its Node-ID and optional coordinate value into the DisCo 528 data structure. An entry in the corresponding ACL 529 [I-D.ietf-p2psip-share] must be present to allow this peer to write 530 the DisCo-Registration resource. By storing the mapping into the 531 data structure a participant becomes a potential focus. 533 4.6. Determining Coordinates 535 Each RELOAD peer within the context of a distributed conference MAY 536 be aware of its relative position in the network topology. To 537 constuct a topology-aware conference, the DisCo Usage provides the 538 coordinate value within the DisCo-Registration data structure. Focus 539 peers store their relative network position together with the 540 announcement as conference focus. Joining peers that are able to 541 determine their coordinates may then select a focus peer whose 542 relative position is in its vicinity (see Section 4.7). 544 Some algorithms determine topology information by measuring Round- 545 Trip Times (RTT) towards a set of hosts serving as landmarks (e.g., 546 [landmarks-infocomm02]). To support such algorithms this document 547 describes an extension to the RELOAD XML configuration document that 548 allows to configure the set of landmark hosts peer must use for 549 position estimation (see Section 4.8). Once a focus peer has 550 registered its mapping in the DisCo data structure, it also stores 551 the according coordinates in the same mapping. These vectors are used by peers joining the conference to 553 select the focus peer that is relatively closest to itself. 555 Because topology-awareness can be obtained by many different 556 approaches a concrete algorithms is out of scope of this document. 558 4.7. Proximity-aware Conference Participation 560 The participation procedure to a distributed conference is composed 561 of three operation. 563 1. Resolution of the conference identifier. 565 2. Establishment of of transport connection. 567 3. SIP signaling to join a conference. 569 Figure 4 and the following specifications give a more detailed view 570 on the joining procedure. 572 Bob Peer1 Overlay PeerN Storing Peer Alice 573 -------------------------------------------------------------- 574 | StatReq Res:Conf-URI | | | 575 |--------->|--------->|--------->|--------->| | 576 | |StatAns | | | | 577 |<---------|<---------|<---------|<---------| | 578 | FetchReq Res:Conf-URI Kind:DisCo,ACL | | 579 |--------->|--------->|--------->|--------->| | 580 | |FetchAns | | | | 581 |<---------|<---------|<---------|<---------| | 582 | | | | | | 583 | Bob calculates Alice as closest Focus | | 584 | | | | | | 585 | |AppAttach application:5060 | | 586 |--------->|--------->|--------->|--------->|--------->| 587 | |AppAttach application:5060 | | 588 |<---------|<---------|<---------|<---------|<---------| 589 | | | | | | 590 |<-------------------ICE Checks----------------------->| 591 | | | | | | 592 | | INVITE sip:Alice | | 593 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| 594 | | 200 OK | | | 595 |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 596 | | ACK | | | 597 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| 598 | | | | | | 600 Figure 4: Participation of a Distributed Conference 602 1. The joining peer MAY determine its own coordinate value (if 603 used). 605 2. The joining peer sends a StatReq message to obtain all indexes of 606 the Access Control List (ACL) Kinds stored. 608 3. The joining peer sends a FetchReq message for the DisCo and ACL 609 Kind to the Resource-ID of the conference URI. The FetchReq 610 SHOULD NOT include any specific dictionary keys, but SHOULD fetch 611 for those array ranges previously determined the StatReq. With 612 the ACL items, the joining peer is able to verify whether DisCo- 613 Registrations are stored by authorized focus peers (see 614 [I-D.ietf-p2psip-share]). 616 4. Using the retrieved coordinates values of the DisCo- 617 Registrations, the joining peer MAY calculate which of than 618 opaque <0..2^16-1> initial field in the Kind data structure focus 619 peers is the relatively closest to itself. 621 5. The joining peer then establishes a transport using RELOADs 622 AppAttach, respectively, ICE procedures to create a transport to 623 the chosen focus peer. 625 6. Finally, the established transport is used to create a SIP dialog 626 from the joining peer to the focus peers. 628 The SIP INVITE request MAY contain the joining peer's topological 629 descriptor as a URI-parameter called 'coord' in the contact-header in 630 base64 encoded form [RFC4648]. An example contact URI is "sip:alice@ 631 example.com;coord=PEknbSBhIHRvcG9sb2dpY2FsIGRlc2NyaXB0b3I+". When 632 the called focus is full and needs to delegate the call it uses the 633 contents of the 'coord'-parameter. It determines the next available 634 focus closest to the calling peer (Section 4.6) using the received 635 descriptor and the other focuses' descriptors from the conference 636 state synchronization document and delegates the call accordingly 637 (see Section 6.1). 639 A conference focus MAY allow the joining peer to also become a focus 640 (depending on the conference policy see Section 6.2). Therefore, it 641 stores a new ACL Kind that delegates write permission for the DisCo- 642 Registration to the new participant. It sets the 'user_name' field 643 in the ACL Kind to its own user name and sets the 'to_user' field to 644 the user name of the joining peer. If no other conference policy is 645 defined, the focus peer MAY set the allow_delegation flag to true. 646 For further details about the trust delegation using the ACL Kind see 647 [I-D.ietf-p2psip-share]. 649 4.8. Configuration Document Extension 651 This section defines an additional parameter for the 652 element that extends the RELOAD XML configuration document. The 653 proposed element allows RELOAD provider to publish a set 654 of accessible and reliable hosts that SHOULD be used if RELOAD peers 655 use landmarking algorithms to determine relative position in the 656 network topology. 658 The element serves as container for the 659 sub-elements, each representing a single host that serves as a 660 landmark. The uses the following attributes: 662 address: The IP address (IPv4 or IPv6) of the landmark host. 664 port: The port on which the landmark host responds for distance 665 estimation. 667 More than one landmark hosts SHOULD be present in the configuration 668 document. 670 5. Conference State Synchronization 672 The global knowledge about signaling and media relations among the 673 conference participants and focus peers defines the global state of a 674 distributed conference. It is composed of the union of every local 675 state at the focus peers. To enable focus peers to provide 676 conference control operations that modify and/or require the global 677 state of a conference, this document defines a mechanism for inter- 678 focus state synchronization. It is based on mutual subscriptions for 679 an Event Package for Distributed Conferences and allows to preserve a 680 coherent knowledge of the global conference state. This XML based 681 event package named 'distributed-conference' MUST be supported by 682 each RELOAD peer that is registered with a DisCo-Registration. 683 Participants of a distributed conference MAY support it. To provide 684 backward compatibility to conference members that do not support the 685 distributed-conference event package, this document defines a 686 translation to the Event Package for Conference State [RFC4575]. 688 5.1. Event Package Overview 690 The 'distributed-conference' event package is designed to convey 691 information about roles and relations of the conference participants. 692 Conference controllers obtain the global state of the conference and 693 use this information for load balancing or conference restructuring 694 mechanisms in case of a focus failure. Figure Figure 5 gives a 695 general overview of the document hierarchy. 697 distributed-conference 698 | 699 |-- version-vector 700 | |-- version 701 | |-- version 702 | 703 |-- conference-description 704 | 705 |-- focus 706 | |-- focus-state 707 | | |-- user-count 708 | | |-- coordinate 709 | | |-- maximum-user-count 710 | | |-- active 711 | | |-- locked 712 | | |-- conf-uris 713 | | |-- available-media 714 | | 715 | |-- users 716 | | |-- user 717 | | | |-- endpoint 718 | | | | |-- media 719 | | | | |-- call-info 720 | | 721 | |-- relations 722 | | |-- relation 723 |-- focus 724 | |-- ... 726 Figure 5: Overview of the event package for distributed conferences 728 The document structure is designed to allow concurrent change events 729 at several focus peers. To prevent race conditions each focus peer 730 has exclusive writing permission to the 'focus' sub element that 731 describes itself. It is achieved by a unique mapping from a focus 732 peer to its XML element using the 'Element Keys' mechanisms for 733 partial notification [RFC4575](sections 4.4-5.). A focus peer is 734 only allowed to update or change that sub element, whose 735 'entity' Element Key contains its RELOAD user name. This restriction 736 also applies to the child elements of the 'version-vector' element. 737 Each 'version' number belongs to a specific focus peer maintaining 738 the version number. 740 The local state of a focus peer is described within a 'focus' 741 element. It provides general information about a focus peer and its 742 signaling and media relations to participants and focus peers. The 743 Conference participants are aggregated within 'users' elements, 744 respectively, 'user' sub elements. 746 General information about the conference as a whole, is provided 747 within a 'conference-description' element. In contrast to the 748 'focus' and 'version-vector' elements, conference description is not 749 meant for concurrent updating. Instead, it provides static 750 conference descriptions that rarely change during a multiparty 751 session. 753 More detailed descriptions about the event package and its elements 754 are provided in the following sections. The complete XML schema 755 definition is given in Section 8. 757 5.2. 759 The element is the root of a distributed 760 conference XML document. It uses the following attributes: 762 entity: This attribute contains the conference URI that identifies 763 the distributed conference. A SIP SUBSCRIBE request addressed to 764 this URI initiates an subscribe/notify relation between 765 participants and their related focus peer. 767 state: This attribute indicates whether the content of a distributed 768 conference document is a 'full', 'partial' or 'deleted' 769 information. It is in accordance with [RFC4575] to enable the 770 partial notification mechanism. 772 The child elements are , 773 and the elements. An event 774 notification of state 'full' MUST include all these elements. An 775 event notification of state 'partial' MUST contain at least and its sub elements. 778 5.3. / 780 The Event Package for Distributed Conferences uses the and its sub elements to enable a coherent 782 versioning scheme. It is based on vector clocks as defined in 783 [timestamps-acsc88]. Each element contains a unsigned 784 integer that describes the state of a specific focus peer and 785 contains the following attributes: 787 entity: This attribute contains the user name of the focus peer 788 whose local version number is described by this element. 790 node-id: This attribute contains the Node-ID of the focus peer. 792 Whenever the local status of a focus peer changes (e.g. a new 793 participant arrived) the version number of the corresponding 794 element MUST be incremented by one. Each change in the 795 local state also triggers a new event notification containing the 796 entire and the changes contained in a 797 element. 799 The recipient of a change event needs to update it local XML 800 document. If a received number is higher that the local, 801 it updates the element and its associated element 802 with the retrieved elements. All other elements remain constant. 804 If the length or contents of the retrieved is 805 different to the local copy it indicates a incoherent knowledge about 806 the entire conference state. If the retrieved 807 contains any unknown focus peers and any local version numbers for 808 the known focus peers is lower, the receiver SHOULD request a 'full' 809 XML notification. 811 If any local number is retarded more than one, the receiver 812 SHOULD request a 'full' event notification from the sender. The full 813 state notification updates all elements whose corresponding 814 element is out of date. 816 5.4. 818 The element provides general information and 819 links to auxiliary services for the conference. The following sub 820 elements provide human-readable text descriptions about the 821 conference: 823 : Contains a short textual description about the 824 conference 826 : Contains the subject of the conference 828 : Contains a longer textual description about the 829 conference 831 : Contains a list of keywords that match the conference 832 topic. The XML schema definition and semantic is imported from 833 the 'conference-info' event package [RFC4575]. 835 The sub element enables focus peers to advertise 836 auxiliary services for the conference. The XML schema definition and 837 semantic is imported from the 'conference-info' event package 838 [RFC4575]. 840 The element uses the 'state' Element Key to 841 enable the partial notification mechanism. 843 5.5. 845 Each element describes a focus peer actively controlling the 846 conference. It provides general information about a focus peer 847 (e.g., display-text, languages, etc.), contains conference specific 848 information about the state of a focus peer (user-count, available 849 media types, etc.) and announces signaling and media information 850 about the maintained participants. Additionally, it describes 851 signaling or media relations to further focus peers. 853 The element uses the following attributes: 855 entity: This attribute contains the user name of the RELOAD peer 856 acting as focus peer. It uniquely identifies the focus peer that 857 is allowed to update or change all sub elements of . All 858 other focus peers SHOULD NOT update or change sub elements of this 859 element. A SUBSCRIBE request addressed to the user name 860 initiates a conference state synchronization with the focus peer. 862 Node-ID This attributed contains the Node-ID of the peer acting as 863 conference focus 865 state: In accordance to [RFC4575], this attribute indicates whether 866 the content of the element is a 'full', 'partial' or 867 'deleted' information. A 'partial' notification contains at 868 maximum a single element. 870 The following sub elements of provide general information 871 about a focus peer: 873 : Contains a short text description of the user acting 874 as focus peer. 876 : This element contains additional URIs that are 877 associated with this user. 879 This element MAY contain human-readable text descriptions 880 about the roles of the user in the conference. 882 : This element contains a list of tokens, each describing 883 a language understood by the user. 885 The XML schema definition and semantic for , 886 and are imported from the 'conference-info' event package 887 [RFC4575] 889 Following, a detailed description of the remaining sub elements. 891 5.5.1. 893 The element aggregates a set of conference specific 894 information about the RELOAD user acting as focus peer. The 895 following attribute is defined for the element: 897 status: This attribute indicates whether the content of the element is a 'full', 'partial' or 'deleted' information. 900 The element has the following sub elements: 902 : This element contains the number of participants that 903 are connected to the conference via this focus peer at a certain 904 moment. 906 This element contains the coordinate value Section 4.2 907 of the focus peer 909 : This number indicates a threshold of 910 participants a focus peer is able to serve. This value might 911 change during a conference, depending on the focus peers current 912 load. 914 : This element MAY contain other conference URIs in order 915 to access the conference via different signaling means. The XML 916 schema definition and semantic is imported from [RFC4575]. 918 : This element is imports the type XML scheme definitions from [RFC4575]. It allows a 920 focus peer to list its available media streams. 922 : This boolean element indicates whether a focus peer is 923 currently active. Conference participation requests or a call 924 delegation request SHOULD succeed. 926 : In contrast to , this element indicates that a 927 focus peer is not willing to accept anymore participation or call 928 delegation request. 930 5.5.2. / 932 The , respectively, each element describes a single 933 participant that is maintained by the focus peer described by the 934 parent element. The element XML schema definition 935 and its semantic is imported from the 'conference-info' event package 936 [RFC4575]. 938 5.5.3. / 940 The element serves as container for elements, 941 each describing a specific connection to another focus peer. The 942 parent element uses the 'state' attribute to enable the 943 partial notification mechanism. For the element the 944 following attributes are defined: 946 entity: This attribute contains the user name of the remote focus. 948 node-id This attribute contains the Node-ID of the remote focus 949 peer. 951 The content of each is a comma separated string that 952 describes the tuple . The CONNECTION- 953 TYPE is a string token describing the type of connection (e.g. media, 954 signaling, etc.) and the IDENTIFIER contains a variable connection 955 identifier. It is a generic method to announce any kind of 956 connection to a remote focus. This specification defines following 957 tuples: 959 media: