idnits 2.17.1 draft-ietf-sipping-conference-package-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1911. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1918. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1924. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 43 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 49 instances of too long lines in the document, the longest one being 207 characters in excess of 72. ** There are 318 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 6, 2004) is 7080 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC XXXX' on line 1775 == Unused Reference: '4' is defined on line 1805, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1845, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1864, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (ref. '2') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2327 (ref. '3') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '5') ** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3265 (ref. '8') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3388 (ref. '11') (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '15') (Obsoleted by RFC 7826) == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-03 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-05 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-02 == Outdated reference: A later version (-01) exists of draft-ietf-mmusic-sdp-media-label-00 Summary: 14 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING J. Rosenberg 2 Internet-Draft Cisco Systems 3 Expires: June 6, 2005 H. Schulzrinne 4 Columbia University 5 O. Levin, Ed. 6 Microsoft Corporation 7 December 6, 2004 9 A Session Initiation Protocol (SIP) Event Package for Conference 10 State 11 draft-ietf-sipping-conference-package-08 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on June 6, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 This document defines a conference event package for the Session 47 Initiation Protocol (SIP) Events framework, along with a data format 48 used in notifications for this package. The conference package 49 allows users to subscribe to a conference URI. Notifications are 50 sent about changes in the membership of this conference and 51 optionally about changes in the state of additional conference 52 components. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Conference Event Package . . . . . . . . . . . . . . . . . . . 4 59 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 5 60 3.2 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5 61 3.3 Subscription Duration . . . . . . . . . . . . . . . . . . 5 62 3.4 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 5 63 3.5 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 6 64 3.6 Notifier Generation of NOTIFY Requests . . . . . . . . . . 6 65 3.7 Subscriber Processing of NOTIFY Requests . . . . . . . . . 6 66 3.8 Handling of Forked Requests . . . . . . . . . . . . . . . 7 67 3.9 Rate of Notifications . . . . . . . . . . . . . . . . . . 7 68 3.10 State Agents . . . . . . . . . . . . . . . . . . . . . . . 7 69 4. Conference Document . . . . . . . . . . . . . . . . . . . . . 7 70 4.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.2 Namespace . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.3 Versioning . . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.4 State and Partial Notifications . . . . . . . . . . . . . 8 74 4.5 Element Keys . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.6 Constructing Coherent State Procedure . . . . . . . . . . 9 76 5. Conference Data . . . . . . . . . . . . . . . . . . . . . . . 10 77 5.1 conference-type . . . . . . . . . . . . . . . . . . . . . 10 78 5.1.1 conference-description of 79 conference-description-type . . . . . . . . . . . . . 11 80 5.1.2 host-info of host-type . . . . . . . . . . . . . . . . 11 81 5.1.3 conference-state of conference-state-type . . . . . . 11 82 5.1.4 users of users-type . . . . . . . . . . . . . . . . . 11 83 5.1.5 sidebars-by-ref of uris-type . . . . . . . . . . . . . 11 84 5.1.6 sidebar-by-val of conference-type . . . . . . . . . . 11 85 5.2 conference-description-type . . . . . . . . . . . . . . . 12 86 5.2.1 display-text of string type . . . . . . . . . . . . . 12 87 5.2.2 subject of string type . . . . . . . . . . . . . . . . 12 88 5.2.3 free-text of string type . . . . . . . . . . . . . . . 12 89 5.2.4 keywords of keywords-type . . . . . . . . . . . . . . 12 90 5.2.5 conf-uris of uris-type . . . . . . . . . . . . . . . . 12 91 5.2.6 service-uris of uris-type . . . . . . . . . . . . . . 13 92 5.2.7 maximum-user-count of user-count-type . . . . . . . . 13 93 5.2.8 available-media of conference-medias-type . . . . . . 13 94 5.3 host-type . . . . . . . . . . . . . . . . . . . . . . . . 13 95 5.3.1 display-text of string type . . . . . . . . . . . . . 14 96 5.3.2 web-page of anyURI type . . . . . . . . . . . . . . . 14 97 5.3.3 uris of uris-type . . . . . . . . . . . . . . . . . . 14 98 5.4 conference-state-type . . . . . . . . . . . . . . . . . . 14 99 5.4.1 user-count of user-count-type . . . . . . . . . . . . 14 100 5.4.2 active of Boolean type . . . . . . . . . . . . . . . . 14 101 5.4.3 locked of Boolean type . . . . . . . . . . . . . . . . 14 102 5.4.4 active-media of conference-medias-type . . . . . . . . 14 103 5.5 user-type . . . . . . . . . . . . . . . . . . . . . . . . 15 104 5.5.1 display-text of string type . . . . . . . . . . . . . 15 105 5.5.2 associated-aors of anyURI type . . . . . . . . . . . . 15 106 5.5.3 roles of user-roles-type . . . . . . . . . . . . . . . 15 107 5.5.4 language of language type . . . . . . . . . . . . . . 15 108 5.5.5 cascaded-focus of anyURI type . . . . . . . . . . . . 16 109 5.5.6 endpoint of endpoint-type . . . . . . . . . . . . . . 16 110 5.6 endpoint-type . . . . . . . . . . . . . . . . . . . . . . 16 111 5.6.1 display-text of string type . . . . . . . . . . . . . 17 112 5.6.2 referred of execution-type . . . . . . . . . . . . . . 17 113 5.6.3 status of endpoint-status-type . . . . . . . . . . . . 17 114 5.6.4 joining-method of joining-type . . . . . . . . . . . . 18 115 5.6.5 joining-info of execution-type . . . . . . . . . . . . 19 116 5.6.6 disconnection-method of disconnection-type . . . . . . 19 117 5.6.7 disconnection-info of execution-type . . . . . . . . . 19 118 5.6.8 media of media-type . . . . . . . . . . . . . . . . . 20 119 5.7 media-type . . . . . . . . . . . . . . . . . . . . . . . . 20 120 5.7.1 display-text of string type . . . . . . . . . . . . . 20 121 5.7.2 proto of string type . . . . . . . . . . . . . . . . . 20 122 5.7.3 src-id of string type . . . . . . . . . . . . . . . . 20 123 5.7.4 label of string type . . . . . . . . . . . . . . . . . 21 124 5.7.5 status of media-status-type . . . . . . . . . . . . . 21 125 5.7.6 call of call-type . . . . . . . . . . . . . . . . . . 21 126 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 22 127 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 128 7.1 Basic Example . . . . . . . . . . . . . . . . . . . . . . 29 129 7.2 Rich Example . . . . . . . . . . . . . . . . . . . . . . . 31 130 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 131 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 132 9.1 conference Event Package Registration . . . . . . . . . . 36 133 9.2 application/conference-info+xml MIME Registration . . . . 36 134 9.3 URN Sub-Namespace Registration for 135 urn:ietf:params:xml:ns:conference-info . . . . . . . . . . 37 136 9.4 XML Schema Registration . . . . . . . . . . . . . . . . . 38 137 9.5 URI Purposes Sub-registry Establishment . . . . . . . . . 38 138 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 139 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 140 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 39 141 11.2 Informative References . . . . . . . . . . . . . . . . . . . 40 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41 143 Intellectual Property and Copyright Statements . . . . . . . . 43 145 1. Introduction 147 The Session Initiation Protocol (SIP) [7] Events framework Events 148 Framework [8] defines general mechanisms for subscribing to, and 149 receiving notifications of, events within SIP networks. It 150 introduces the notion of a package, which is a specific 151 "instantiation" of the events framework for a well-defined set of 152 events. Here, we define an event package for SIP conferences. This 153 package provides the conference notification service as outlined in 154 the SIP conferencing framework [18]. As described there, 155 subscriptions to a conference URI are routed to the focus that is 156 handling the conference. It acts as the notifier, and provides 157 clients with updates on conference state. 159 The information provided by this package is comprised of conference 160 identifier(s), conference participants (optionally with their 161 statuses and media description), conference sidebars, conference 162 service URIs, etc. 164 2. Terminology 166 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 167 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 168 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 169 indicate requirement levels for compliant implementations. 171 3. Conference Event Package 173 The conference event package allows a user to subscribe to a 174 conference. In SIP, conferences are represented by URIs. These URIs 175 route to a SIP user agent, called a focus, that is responsible for 176 ensuring that all users in the conference can communicate with each 177 other, as described in Conferencing Framework [18]. The focus has 178 sufficient information about the state of the conference to inform 179 subscribers about it. 181 It is possible a participant in the conference may in fact be another 182 focus. In order to provide a more complete participant list, the 183 focus MAY subscribe to the conference package of the other focus to 184 discover the participant list in the cascaded conference. This 185 information can then be included in notifications by use of the 186 element as specified by this package. 188 This section provides the details for defining a SIP-specific event 189 notification package, as specified by RFC 3265 [8]. 191 3.1 Event Package Name 193 The name of this event package is "conference". This package name is 194 carried in the Event and Allow-Events header, as defined in RFC 3265 195 [8]. 197 3.2 SUBSCRIBE Bodies 199 A SUBSCRIBE for a conference package MAY contain a body. This body 200 defines a filter to apply to the subscription. Filter documents are 201 not specified in this document, and at the time of writing, are 202 expected to be the subject of future standardization activity. 204 A SUBSCRIBE for a conference package MAY be sent without a body. 205 This implies the default subscription filtering policy. The default 206 policy is: 207 o Notifications are generated every time there is any change in the 208 state of the conference. 209 o Notifications do not normally contain full state; rather, they 210 only indicate the state that has changed. The exception is a 211 NOTIFY sent in response to a SUBSCRIBE. These NOTIFYs contain the 212 full state of the information requested by the subscriber. 214 3.3 Subscription Duration 216 The default expiration time for a subscription to a conference is one 217 hour. Once the conference ends, all subscriptions to that particular 218 conference are terminated, with a reason of "noresource" RFC 3265 219 [8]. 221 3.4 NOTIFY Bodies 223 As described in RFC 3265 [8], the NOTIFY message will contain bodies 224 that describe the state of the subscribed resource. This body is in 225 a format listed in the Accept header field of the SUBSCRIBE, or a 226 package-specific default if the Accept header field was omitted from 227 the SUBSCRIBE. 229 In this event package, the body of the notification contains a 230 conference information document. This document describes the state 231 of a conference. All subscribers and notifiers MUST support the 232 "application/conference-info+xml" data format described in Section 5. 233 The subscribe request MAY contain an Accept header field. If no such 234 header field is present, it has a default value of 235 "application/conference-info+xml". If the header field is present, 236 it MUST include "application/conference-info+xml", and MAY include 237 any other types. 239 Of course, the notifications generated by the server MUST be in one 240 of the formats specified in the Accept header field in the SUBSCRIBE 241 request. 243 3.5 Notifier Processing of SUBSCRIBE Requests 245 The conference information contains very sensitive information. 246 Therefore, all subscriptions SHOULD be authenticated and then 247 authorized before approval. Authorization policy is at the 248 discretion of the administrator, as always. However, a few 249 recommendations can be made. 251 It is RECOMMENDED that all users in the conference be allowed to 252 subscribe to the conference. 254 3.6 Notifier Generation of NOTIFY Requests 256 Notifications MUST be generated for the conference state when a new 257 participant joins (i.e. gets "connected" to) or a participant leaves 258 (i.e. gets "disconnected" from) the conference. 260 Subject to a local focus policy, additional changes in participants' 261 status, changes in their media types, and other optional information 262 MAY be reported by the focus. 264 Changes in sidebar rosters SHOULD be reported by the focus to their 265 participants and MAY be reported to others, subject to local policy. 267 Changes in conference identifiers and service URIs SHOULD be reported 268 by the focus to the Conference package subscribers. 270 Changes in other conference state information MAY be reported by the 271 focus to the Conference package subscribers. 273 3.7 Subscriber Processing of NOTIFY Requests 275 The SIP Events framework expects packages to specify how a subscriber 276 processes NOTIFY requests in any package specific ways, and in 277 particular, how it uses the NOTIFY requests to construct a coherent 278 view of the state of the subscribed resource. 280 Typically, the NOTIFY for the conference package will only contain 281 information about those users whose state in the conference has 282 changed. To construct a coherent view of the total state of all 283 users, a subscriber to the conference package will need to combine 284 NOTIFYs received over time. 286 Notifications within this package can convey partial information; 287 that is, they can indicate information about a subset of the state 288 associated with the subscription. This means that an explicit 289 algorithm needs to be defined in order to construct coherent and 290 consistent state. The details of this mechanism are specific to the 291 particular document type. See Section 4.6 for information on 292 constructing coherent information from an 293 application/conference-info+xml document. 295 3.8 Handling of Forked Requests 297 By their nature, the conferences supported by this package are 298 centralized. Therefore, SUBSCRIBE requests for a conference should 299 not generally fork. Users of this package MUST NOT install more than 300 a single subscription as a result of a single SUBSCRIBE request. 302 3.9 Rate of Notifications 304 For reasons of congestion control, it is important that the rate of 305 notifications not become excessive. As a result, it is RECOMMENDED 306 that the server not generate notifications for a single subscriber at 307 a rate faster than once every 5 seconds. 309 3.10 State Agents 311 Conference state is ideally maintained in the element in which the 312 conference resides. Therefore, the elements that maintain the 313 conference are the ones best suited to handle subscriptions to it. 314 Therefore, the usage of state agents is NOT RECOMMENDED for this 315 package. 317 4. Conference Document 319 4.1 Format 321 Conference information is an XML document that MUST be well-formed 322 and SHOULD be valid. It MUST be based on Extensible Markup Language 323 (XML) 1.0 and MUST be encoded using UTF-8 [13]. 325 4.2 Namespace 327 This specification makes use of XML namespaces for identifying 328 conference information documents and document fragments. The 329 namespace URI for elements defined by this specification is a URN 330 [2], using the namespace identifier 'ietf' defined by [5] and 331 extended by RFC 3688 [14]. This URN is: 333 urn:ietf:params:xml:ns:conference-info 335 4.3 Versioning 337 The conference information is described by a hierarchal XML structure 338 with the root element . The root element is the 339 only element in the schema that carries meaningful version number for 340 all the elements in the document. The whole conference information 341 is associated with this version number. 343 The optional 'version' attribute MUST be included in the root 344 element. 346 4.4 State and Partial Notifications 348 All sub-elements in the hierarchal XML structure 349 can be classified in two groups: those that carry relatively small 350 amount of data and those that can potentially carry a lot of data. 351 During partial notifications, the light elements are updated as 352 atomic pieces of data. On the other hand, elements that can carry a 353 substantial amount of data have the general 'state' attribute 354 attached to them. That is in order to support partial notifications 355 for their content. 357 The 'state' attribute indicates whether the reported information 358 about the element is "full", "partial" or the element is "deleted" 359 from the conference state document. The default value of any 'state' 360 attribute is "full". 362 A 'state' attribute of a child element in the document MUST adhere to 363 its parent 'state'. It means that if the parent's 'state' is "full", 364 the state of its children MUST be "full". If the parent's 'state' is 365 "partial", the state of its children MAY be either "partial", "full", 366 or "deleted". 368 4.5 Element Keys 370 In the context of this specification, the element key is the set of 371 mandatory attributes or sub-elements of the element. The key value 372 MUST be unique for the element among its siblings of the same type. 374 In a partial notification event it must be possible to uniquely 375 identify each sub-element among others of the same type under a 376 common parent element. In order to achieve this property, all 377 sub-elements, with possible multiple appearances under a common 378 parent (which has the attribute 'state') have keys defined to them. 380 Below is the list of the elements with their keys as defined by this 381 specification: 383 o Elements , , and use as the key 384 'entity' 385 o Element uses as the key 'id' 386 o Sub-element of uris-type contained in elements 387 and uses as the key 388 o Elements and of 389 conference-medias-type use as the key 390 o Elements and of count-type use 391 as the key 392 o Element of user-roles-type uses as the key 393 o Sub-element of conference-type contained in element 394 uses as the key 'entity' 395 o Elements and of uris-type use 396 as the key 398 4.6 Constructing Coherent State Procedure 400 A Conference package subscriber MUST initialize the 'version' 401 attribute from the element with the value in the 402 first document received. 404 The conference package subscriber locally maintains a local element 405 for each element in the schema and a table for each element with 406 key(s) in the schema and indexed by these key(s). 408 Each time a new NOTIFY is received, the value of the local version 409 number and the value of the 'version' attribute in the new received 410 document are compared. If the value in the document is less than the 411 local version, the document is discarded without processing. If the 412 value in the document is higher than the local version number, the 413 local version number is set to the value in the new document and the 414 document is processed. If the value in the received document is more 415 than one higher than the previous local version number and the 416 document contained a partial state, the subscriber SHOULD generate a 417 refresh request to trigger a full state notification. 419 Further processing of the conference information depends on the state 420 contained in the received conference document and indicated by the 421 value of the 'state' attribute in the element. If 422 it contains "full" state, the whole local content is flushed and 423 repopulated from the document. If it contains "deleted" state, it 424 means that the conference ceased to exist and the subscriber SHOULD 425 terminate the subscription by sending the SUBSCRIBE with Expires = 0. 427 If the document contains "partial" state, the document is used to 428 update the local content as described below. 430 Starting from outer elements in the received document, 431 1. If the parent element contains "full" state, the whole local 432 element content is flushed and repopulated from the document. 434 2. Otherwise, if the parent element contains "deleted" state, the 435 whole element MUST be removed from the local content. 437 3. Otherwise, if the parent element contains "partial" state: 439 3.1 For elements with keys, the subscriber compares the keys received 440 in the update with the keys in the local tables. 442 3.1.1 If a key does not exist in the local table, a row is added, and 443 its content is set to the element information from the update. 445 3.1.2 Otherwise, if a key of the same value does exist, for each 446 sub-element in the row the algorithm is applied from step 2.2. 448 3.2 For each atomic element received in the schema, the element is 449 replaced with the new information as a whole. Also, for each 450 non-atomic element received in the schema with either no 'state' 451 attribute included or the state attribute is set to "full", the 452 element is replaced with the new information as a whole. 454 3.3 For each non-atomic element with the state attribute set to 455 "partial", the algorithm is applied recursively starting from step 3. 457 5. Conference Data 459 A conference information document begins with the root element tag 460 of conference-type. Sections below describe the 461 complex types composing the hierarchal conference-type. The full XML 462 schema is defined in Section 6. 464 5.1 conference-type 466 This type defines the following attributes: 468 entity: This attribute contains the conference URI that identifies 469 the conference being described in the document. 471 state: This attribute indicates whether the document contains the 472 whole conference information ("full"), only the information that 473 has changed since the previous document ("partial"), or the 474 conference ceased to exist ("deleted"). For more details see 475 Section 4. 477 version: This attribute allows the recipient of conference 478 information documents to properly order them and it MUST be 479 included when used in the root element. 480 Versions start at 0 and increment by one for each new document 481 sent to a subscriber. Versions are scoped within a subscription. 482 Versions are represented using a 32 bit integer. 484 The conference-type defines an extendable sequence of child elements. 485 A "full" conference document MUST at least include the following 486 sub-elements: , , and 487 . 489 The child elements are described in details below: 491 5.1.1 conference-description of conference-description-type 493 This element contains conference information that is derived from 494 system conference policies, is set before the conference activation, 495 and is rarely changed during the conference lifetime. 497 5.1.2 host-info of host-type 499 This element contains information about the entity that hosts the 500 conference. This information is set before the conference 501 activation, and is rarely changed during the conference lifetime, 502 unless the whole conference is moved to be hosted by another entity. 504 5.1.3 conference-state of conference-state-type 506 This element contains the dynamic information about the current state 507 of the conference. 509 5.1.4 users of users-type 511 This element can contain an unbounded number of sub-elements 512 of user-type each containing the information about a participant in 513 the conference. 515 5.1.5 sidebars-by-ref of uris-type 517 This element contains sub-elements of uri-type which provide 518 pointers to sidebar information through sidebar URIs. The recipient 519 of the information can then subscribe to sidebar information 520 independently from the main conference package subscription. 522 5.1.6 sidebar-by-val of conference-type 524 This element provides sidebar information as a part of the main 525 conference package information. 527 5.2 conference-description-type 529 This type defines the 'state' attribute which can contain the values 530 "full", "partial", or "deleted". 532 This type defines an extendable sequence of the following child 533 elements: 535 5.2.1 display-text of string type 537 This element contains text description of the conference. 539 5.2.2 subject of string type 541 This element contains the subject of the conference. 543 5.2.3 free-text of string type 545 This element contains free form text about the conference. 547 5.2.4 keywords of keywords-type 549 This element contains a list of words that can be used by automatic 550 search engines to better classify the conference. 552 5.2.5 conf-uris of uris-type 554 This element contains a set of sub-elements - each containing 555 the information about an additional conference URI that this 556 conference can be accessed by. The value of the URI is included in 557 the sub-element and its description MAY be included in the 558 sub-element. 560 The purpose of the URI SHOULD be included in the 561 sub-element. The currently defined values to be used with 562 the are: 564 participation: Indicates that dialing into this URI will bring the 565 party into the conference 566 streaming: Indicates that "listening" to this URI will provide the 567 conference live content 569 Future extensions to this schema may define new values and register 570 them with IANA under the registry established by this specification. 572 Examples of such URIs include sip: / sips: [7], h323: [17], and tel: 574 [16] URIs. 576 5.2.6 service-uris of uris-type 578 This element contains a set of sub-elements - each containing 579 the URI to be used in order to access different services available 580 for the particular conference. The value of the URI is included in 581 the sub-element and its description MAY be included in the 582 sub-element. 584 The purpose of the URI SHOULD be included in the 585 sub-element. The currently defined values to be used with 586 the are: 588 web-page: Indicates the web page containing the additional 589 information about the conference 590 recording: Indicates the link at which the recorded conference 591 context can be retrieved 592 event: Indicates the URI to which the subscription to the conference 593 event package needs to be performed 595 Future extensions to this schema may define new values and register 596 them with IANA under the registry established by this specification. 598 5.2.7 maximum-user-count of user-count-type 600 This element is used to specify the maximum number of users permitted 601 in the conference. The number SHOULD be provided for all 602 participants in total by populating the sub-element with value 603 "any". Additionally counters for users with certain roles in the 604 conference MAY be separately provided. 606 5.2.8 available-media of conference-medias-type 608 This element contains information about the media types available in 609 the conference. The sub-element MUST contain one of the 610 values registered for "proto" of SDP [3] and its later revision(s). 612 5.3 host-type 614 This type defines the 'state' attribute which can contain the values 615 "full", "partial", or "deleted". 617 This type defines an extendable sequence of the following child 618 elements: 620 5.3.1 display-text of string type 622 This element contains display text information about the entity 623 hosting the conference. 625 5.3.2 web-page of anyURI type 627 This element contains a web page URI about the user hosting the 628 conference. 630 5.3.3 uris of uris-type 632 The sub-element contains additional URIs pointing to the 633 conference host. 635 5.4 conference-state-type 637 This type defines the 'state' attribute which can contain the values 638 "full", "partial", or "deleted". 640 This type defines an extendable sequence of the following child 641 elements. 643 5.4.1 user-count of user-count-type 645 This element is used to specify the current number of users in the 646 conference. The number SHOULD be provided for all participants in 647 total by populating the sub-element with value "any". 648 Additionally counters for users with certain roles in the conference 649 MAY be separately provided. 651 5.4.2 active of Boolean type 653 This element says whether the conference is currently active or not. 654 For example, a conference can be scheduled for a certain start time 655 and its conference URI reserved and published. Still, the conference 656 will not be "active" till its actual start time. 658 5.4.3 locked of Boolean type 660 This element contains information about whether the conference is 661 currently locked. In this context, "locked" means that the 662 conference roster can not be added to (although participants may 663 leave or be removed from the conference). 665 5.4.4 active-media of conference-medias-type 667 This element contains information about the media types currently 668 active in the conference, which is a subset of those listed in the 669 element. 671 5.5 user-type 673 This type defines the following attributes: 675 entity: This attribute contains the URI for the user in the 676 conference. This is a logical identifier, which corresponds to 677 the authenticated identity of the participant. The 'entity' 678 attribute MUST be unique in the user element list because it is 679 used as the key in partial notifications about users' state. An 680 anonymous participant in a conference SHOULD be represented by an 681 anonymous URI generated by the focus. For multiple anonymous 682 participants, the focus must ensure that each anonymous URI is 683 unique. The guidelines for generating anonymous URIs in RFC 3323 684 [9] should be followed. For example, 686 "Anonymous1" 688 could be used for a participant requesting privacy. 690 state: This attribute indicates whether the document contains the 691 whole conference information ("full"), only the information that 692 has changed since the previous document ("partial"), or the 693 conference ceased to exist ("deleted"). 695 This type defines an extendable sequence of the following child 696 elements. 698 5.5.1 display-text of string type 700 This element contains the display text for the user. 702 5.5.2 associated-aors of anyURI type 704 This element contains associated URIs of the user. Usually this 705 information will be manually provided by a system administrator 706 showing the logical association between signaling entities otherwise 707 independent. 709 5.5.3 roles of user-roles-type 711 This element contains the roles of the user. 713 5.5.4 language of language type 715 This element contains the language preference of the user. This 716 information can be automatically learned via call signaling or be 717 manually set per participant. 719 5.5.5 cascaded-focus of anyURI type 721 This element contains a conference URI (different from the main 722 conference URI) for users that are connected to the main conference 723 as a result of focus cascading. In accordance with the SIP 724 conferencing framework [18], this package allows for representation 725 of peer-to-peer (i.e. "flat") focus cascading only. The actual 726 cascading graph can not be deduced from the information provided in 727 the package alone. Advanced applications can construct the graph by 728 subscribing to both this package and the Dialog Package [19] of the 729 cascaded foci and correlating the relevant information. 731 5.5.6 endpoint of endpoint-type 733 This element contains information about an endpoint of the user. The 734 element of the endpoint-type can have unbounded number of appearance 735 in the user-type for each endpoint of the user participating in the 736 conference. In a case when authentication is performed per endpoint 737 (rather than per user) in a system, a focus can be not aware of the 738 logical association among endpoints being used by the same user. In 739 this case the focus MAY present the endpoints as belonging to 740 separate users in the conference schema. 742 In a different case, due to privacy concerns for a user, the focus 743 may want to shield the information about multiple endpoints from the 744 recipients of the Conference document. To do so the focus MAY 745 aggregate the multiple endpoint information into a single endpoint 746 element under this user. 748 5.6 endpoint-type 750 This type defines the following attributes: 752 entity: The attribute contains the endpoint URI for the user in the 753 conference. In SIP terms, this is the Contact URI or GRUU. The 754 'entity' attribute MUST be unique in the endpoint element list 755 because it is used as the key in partial notifications about 756 users' endpoints. An endpoint belonging to an anonymous 757 participant in a conference SHOULD be represented by an anonymous 758 URI generated by the focus. For multiple anonymous endpoints, the 759 focus must ensure that each anonymous URI is unique. The 760 guidelines for generating anonymous URIs in RFC 3323 [9] should be 761 followed. 763 state: This attribute indicates whether the element contains the 764 whole endpoint information ("full"), only the information that has 765 changed since the previous document ("partial"), or the endpoint 766 has been deleted from the conference ("deleted"). 768 This type defines an extendable sequence of the following child 769 elements. 771 5.6.1 display-text of string type 773 This element contains the display text for the endpoint. 775 5.6.2 referred of execution-type 777 This element contains information about the user who's action 778 resulted in this endpoint being brought into the conference (e.g. 779 the SIP user identified by this URI sent a REFER to the focus). It 780 can contain the following sub-elements: 782 when: This element contains the date and time that the endpoint was 783 referred to the conference. 785 reason: This element contains the reason the endpoint was referred to 786 the conference. 788 by: This element contains the URI of the entity who caused the 789 endpoint to be referred to the conference. 791 5.6.3 status of endpoint-status-type 793 This element contains the status of the endpoint, and can assume the 794 following values: 796 connected: The endpoint is a participant in the conference. 797 Depending on the media policies, he/she can send and receive media 798 to and from other participants. 800 disconnected: The endpoint is not a participant in the conference and 801 no active dialog exists between the endpoint and the focus. 803 on-hold: Active SIP dialog exists between an endpoint and a focus, 804 but endpoint is "on-hold" for this conference, i.e. neither 805 he/she is "hearing" the conference mix, nor is his/her media being 806 mixed in the conference. As an example, the endpoint has asked to 807 join the conference using SIP, but his/her participation is 808 pending based on moderator approval. In the meantime he/she is 809 hearing music-on-hold or some other kind of related content. 811 muted-via-focus: Active SIP dialog exists between an endpoint and a 812 focus and the endpoint can "listen" to the conference, but 813 endpoint's media is not being mixed into the conference. Note 814 that sometimes a subset of endpoint media streams can be muted by 815 focus (such as poor quality video) while others (such as voice or 816 IM) can still be active. In this case, it is RECOMMENDED that the 817 "aggregated" endpoint connectivity reflects the status of 818 the mostly active media. 820 pending: Endpoint is not yet in the session, but it is anticipated 821 that he/she will join in the near future. 823 alerting: A PSTN ALERTING or SIP 180 Ringing was returned for the 824 outbound call, endpoint is being alerted. 826 dialing-in: Endpoint is dialing into the conference, not yet in the 827 roster (probably being authenticated). 829 dialing-out: Focus has dialed out to connect the endpoint to the 830 conference, but the endpoint is not yet in the roster (probably 831 being authenticated). 833 disconnecting: Focus is in the process of disconnecting endpoint 834 (either DISCONNECT or BYE was sent to the endpoint). 836 Note that the defined transient statuss (e.g., disconnecting, 837 alerting, etc.) could generate a lot of notifications. 838 Implementations MAY choose not to generate notifications on these to 839 all participants if it will generate too much traffic. 841 5.6.4 joining-method of joining-type 843 This element contains method by which the endpoint joined the 844 conference, and can assume the following values: 846 dialed-in: The endpoint dialed into the conference, i.e. sent INVITE 847 to the focus, which resulted in successful dialog establishment. 849 dialed-out: The focus has brought the endpoint into the conference by 850 sending a successful INVITE to the endpoint. 852 focus-owner: The endpoint is the focus for this conference. This 853 status is used only when a participant�s UA acts as a conference 854 focus. 856 5.6.5 joining-info of execution-type 858 This element contains information about how the endpoint joined and 859 can contain the following sub-elements: 861 when: This element contains the date and time that the endpoint 862 joined the conference. 864 reason: This element contains the reason the endpoint joined the 865 conference. 867 by: This element contains the URI of the entity who caused the 868 endpoint to join the conference. 870 5.6.6 disconnection-method of disconnection-type 872 This element contains method by which the endpoint departed the 873 conference, and can assume the following values: 875 departed: The endpoint sent a BYE, thus leaving the conference. 877 booted: The endpoint was sent a BYE by the focus, booting him/her out 878 of the conference. Alternatively, the endpoint tried to dial into 879 to conference without success because was rejected by the focus 880 according to local policy decisions. 882 failed: The server tried to bring the endpoint into the conference, 883 but its attempt to contact the specific endpoint resulted in a 884 non-200 class final response. Alternatively, the endpoint tried 885 to dial into the conference without success due to technical 886 reasons. 888 5.6.7 disconnection-info of execution-type 890 This element contains information about the endpoint's departure from 891 the conference and can contain the following sub-elements: 893 when: This element contains the date and time that the endpoint 894 departed the conference. 896 reason: This element contains the reason the endpoint departed the 897 conference. When known and meaningful, it is RECOMMENDED to 898 include the information as conveyed/reported by the call signaling 899 in the format defined by RFC 3326 [10]. For example, 901 Reason: SIP ;cause=415 ;text="Unsupported Media Type" 902 by: This element contains the URI of the entity who caused the 903 endpoint to depart the conference. 905 5.6.8 media of media-type 907 This element contains information about a media stream of this 908 endpoint. The element of the media-type can have an unbounded number 909 of appearances in the endpoint-type for each media stream of the 910 endpoint. Note that it is possible that media streams listed under a 911 common endpoint MAY be established by separate signaling means and 912 consequently belong to different signaling "calls". 914 5.7 media-type 916 This type defines the following attributes: 918 id: The attribute is a unique identifier of a media stream on a per 919 endpoint basis. This attribute is used as a key to identify media 920 streams which may be added and deleted on a dynamic basis during 921 the conference. If the SDP "mid" (as defined in Grouping of Media 922 Lines in the SDP [11]) is used for establishing the media stream, 923 the 'id' SHOULD contain the same "mid" value, otherwise the 924 notification service MUST generate an 'id' value which is unique 925 in the endpoint context. 927 state: This attribute indicates whether the element contains the 928 whole media information ("full"), only the information that has 929 changed since the previous notification ("partial"), or that the 930 media element has been deleted from the conference document 931 ("deleted"). 933 This type defines an extendable sequence of the following child 934 elements. 936 5.7.1 display-text of string type 938 This element contains the display text for the media stream. 940 5.7.2 proto of string type 942 This element contains the media type for the media stream. The value 943 of this element MUST be one of the values registered for "proto" of 944 SDP [3] and its later revision(s). 946 5.7.3 src-id of string type 948 The element, if applicable, carries the information about 949 the actual source of the media. For example, for the RTP/RTCP [12] 950 media streams the value MUST contain the SSRC value generated by the 951 endpoint for the stream it sends. 953 When an RTP mixer generates a CSRC list according to RTP/RTCP [12], 954 it inserts a list of the SSRC identifiers of the sources that 955 contributed to the generation of a particular packet into the RTP 956 header of that packet. A quote from RFC 3550: "An example 957 application is audio conferencing where a mixer indicates all the 958 talkers whose speech was combined to produce the outgoing packet, 959 allowing the receiver to indicate the current talker, even though all 960 the audio packets contain the same SSRC identifier (that of the 961 mixer)." 963 If an RTP mixer compliant to the above is used, participants can 964 perform an SSRC to user mapping and identify "a current speaker". 966 5.7.4 label of string type 968 The element