idnits 2.17.1 draft-ietf-sipping-conference-package-07.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 1888. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1865. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1872. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1878. ** 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 46 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 319 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 (November 27, 2004) is 7084 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) == Unused Reference: '13' is defined on line 1799, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1818, 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) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '4') ** Obsolete normative reference: RFC 3023 (ref. '5') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3265 (ref. '7') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3388 (ref. '9') (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '13') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2806 (ref. '14') (Obsoleted by RFC 3966) == 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: 13 errors (**), 0 flaws (~~), 11 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: May 28, 2005 H. Schulzrinne 4 Columbia University 5 O. Levin, Ed. 6 Microsoft Corporation 7 November 27, 2004 9 A Session Initiation Protocol (SIP) Event Package for Conference 10 State 11 draft-ietf-sipping-conference-package-07 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 May 28, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Conference Event Package . . . . . . . . . . . . . . . . . . . 6 59 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 6 60 3.2 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6 61 3.3 Subscription Duration . . . . . . . . . . . . . . . . . . 6 62 3.4 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 7 63 3.5 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 7 64 3.6 Notifier Generation of NOTIFY Requests . . . . . . . . . . 7 65 3.7 Subscriber Processing of NOTIFY Requests . . . . . . . . . 8 66 3.8 Handling of Forked Requests . . . . . . . . . . . . . . . 8 67 3.9 Rate of Notifications . . . . . . . . . . . . . . . . . . 8 68 3.10 State Agents . . . . . . . . . . . . . . . . . . . . . . . 8 69 4. Conference Document . . . . . . . . . . . . . . . . . . . . . 10 70 4.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.2 Namespace . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.3 Versioning . . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.4 State and Partial Notifications . . . . . . . . . . . . . 10 74 4.5 Element Keys . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.6 Constructing Coherent State Procedure . . . . . . . . . . 11 76 5. Conference Data . . . . . . . . . . . . . . . . . . . . . . . 13 77 5.1 conference-type . . . . . . . . . . . . . . . . . . . . . 13 78 5.1.1 conference-description of 79 conference-description-type . . . . . . . . . . . . . 13 80 5.1.2 host-info of host-type . . . . . . . . . . . . . . . . 13 81 5.1.3 conference-state of conference-state-type . . . . . . 14 82 5.1.4 users of users-type . . . . . . . . . . . . . . . . . 14 83 5.1.5 sidebars-by-ref of uris-type . . . . . . . . . . . . . 14 84 5.1.6 sidebar-by-val of conference-type . . . . . . . . . . 14 85 5.2 conference-description-type . . . . . . . . . . . . . . . 14 86 5.2.1 display-text of string type . . . . . . . . . . . . . 14 87 5.2.2 subject of string type . . . . . . . . . . . . . . . . 14 88 5.2.3 free-text of string type . . . . . . . . . . . . . . . 14 89 5.2.4 keywords of keywords-type . . . . . . . . . . . . . . 14 90 5.2.5 conf-uris of uris-type . . . . . . . . . . . . . . . . 15 91 5.2.6 service-uris of uris-type . . . . . . . . . . . . . . 15 92 5.2.7 maximum-user-count of user-count-type . . . . . . . . 15 93 5.2.8 available-media of conference-medias-type . . . . . . 15 94 5.3 host-type . . . . . . . . . . . . . . . . . . . . . . . . 15 95 5.3.1 display-text of string type . . . . . . . . . . . . . 15 96 5.3.2 web-page of anyURI type . . . . . . . . . . . . . . . 16 97 5.3.3 uris of uris-type . . . . . . . . . . . . . . . . . . 16 98 5.4 conference-state-type . . . . . . . . . . . . . . . . . . 16 99 5.4.1 user-count of user-count-type . . . . . . . . . . . . 16 100 5.4.2 active of Boolean type . . . . . . . . . . . . . . . . 16 101 5.4.3 locked of Boolean type . . . . . . . . . . . . . . . . 16 102 5.4.4 recording of uris-type . . . . . . . . . . . . . . . . 16 103 5.4.5 active-media of conference-medias-type . . . . . . . . 17 104 5.5 user-type . . . . . . . . . . . . . . . . . . . . . . . . 17 105 5.5.1 display-text of string type . . . . . . . . . . . . . 17 106 5.5.2 associated-aors of anyURI type . . . . . . . . . . . . 17 107 5.5.3 roles of user-roles-type . . . . . . . . . . . . . . . 17 108 5.5.4 language of language type . . . . . . . . . . . . . . 18 109 5.5.5 cascaded-focus of anyURI type . . . . . . . . . . . . 18 110 5.5.6 endpoint of endpoint-type . . . . . . . . . . . . . . 18 111 5.6 endpoint-type . . . . . . . . . . . . . . . . . . . . . . 18 112 5.6.1 display-text of string type . . . . . . . . . . . . . 19 113 5.6.2 referred of execution-type . . . . . . . . . . . . . . 19 114 5.6.3 status of endpoint-status-type . . . . . . . . . . . . 19 115 5.6.4 joining-method of joining-type . . . . . . . . . . . . 20 116 5.6.5 joining-info of execution-type . . . . . . . . . . . . 21 117 5.6.6 disconnection-method of disconnection-type . . . . . . 21 118 5.6.7 disconnection-info of execution-type . . . . . . . . . 21 119 5.6.8 media of media-type . . . . . . . . . . . . . . . . . 22 120 5.7 media-type . . . . . . . . . . . . . . . . . . . . . . . . 22 121 5.7.1 display-text of string type . . . . . . . . . . . . . 22 122 5.7.2 proto of string type . . . . . . . . . . . . . . . . . 22 123 5.7.3 src-id of string type . . . . . . . . . . . . . . . . 22 124 5.7.4 label of string type . . . . . . . . . . . . . . . . . 23 125 5.7.5 status of media-status-type . . . . . . . . . . . . . 23 126 5.7.6 call of call-type . . . . . . . . . . . . . . . . . . 23 127 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 24 128 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 129 7.1 Basic Example . . . . . . . . . . . . . . . . . . . . . . 32 130 7.2 Rich Example . . . . . . . . . . . . . . . . . . . . . . . 34 131 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 132 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 133 9.1 conference Event Package Registration . . . . . . . . . . 40 134 9.2 application/conference-info+xml MIME Registration . . . . 40 135 9.3 URN Sub-Namespace Registration for 136 urn:ietf:params:xml:ns:conference-info . . . . . . . . . . 40 137 9.4 XML Schema Registration . . . . . . . . . . . . . . . . . 41 138 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 139 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 140 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 43 141 11.2 Informative References . . . . . . . . . . . . . . . . . . . 43 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 44 143 Intellectual Property and Copyright Statements . . . . . . . . 46 145 1. Introduction 147 The Session Initiation Protocol (SIP) [6] Events framework Events 148 Framework [7] 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 [16]. 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 [16]. 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 using of the 186 element as specified by this package. 188 This section provides the details for defining a SIP Events package, 189 as specified by RFC 3265 [7]. 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 [7]. 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 220 [7]. 222 3.4 NOTIFY Bodies 224 As described in RFC 3265 [7], the NOTIFY message will contain bodies 225 that describe the state of the subscribed resource. This body is in 226 a format listed in the Accept header field of the SUBSCRIBE, or a 227 package-specific default if the Accept header field was omitted from 228 the SUBSCRIBE. 230 In this event package, the body of the notification contains a 231 conference information document. This document describes the state 232 of a conference. All subscribers and notifiers MUST support the 233 "application/conference-info+xml" data format described in Section 5. 234 The subscribe request MAY contain an Accept header field. If no such 235 header field is present, it has a default value of 236 "application/conference-info+xml". If the header field is present, 237 it MUST include "application/conference-info+xml", and MAY include 238 any other types. 240 Of course, the notifications generated by the server MUST be in one 241 of the formats specified in the Accept header field in the SUBSCRIBE 242 request. 244 3.5 Notifier Processing of SUBSCRIBE Requests 246 The conference information contains very sensitive information. 247 Therefore, all subscriptions SHOULD be authenticated and then 248 authorized before approval. Authorization policy is at the 249 discretion of the administrator, as always. However, a few 250 recommendations can be made. 252 It is RECOMMENDED that all users in the conference be allowed to 253 subscribe to the conference. 255 3.6 Notifier Generation of NOTIFY Requests 257 Notifications MUST be generated for the conference state when a new 258 participant joins (i.e. gets "connected" to) or a participant leaves 259 (i.e. gets "disconnected" from) the conference. 261 Subject to a local focus policy, additional changes in participants' 262 status, changes in their media types, and other optional information 263 MAY be reported by the focus. 265 Changes in sidebar rosters SHOULD be reported by the focus to their 266 participants and MAY be reported to others, subject to local policy. 268 Changes in conference identifiers and service URIs SHOULD be reported 269 by the focus to the Conference package subscribers. 271 Changes in other conference state information MAY be reported by the 272 focus to the Conference package subscribers. 274 3.7 Subscriber Processing of NOTIFY Requests 276 The SIP Events framework expects packages to specify how a subscriber 277 processes NOTIFY requests in any package specific ways, and in 278 particular, how it uses the NOTIFY requests to construct a coherent 279 view of the state of the subscribed resource. 281 Typically, the NOTIFY for the conference package will only contain 282 information about those users whose state in the conference has 283 changed. To construct a coherent view of the total state of all 284 users, a subscriber to the conference package will need to combine 285 NOTIFYs received over time. 287 Notifications within this package can convey partial information; 288 that is, they can indicate information about a subset of the state 289 associated with the subscription. This means that an explicit 290 algorithm needs to be defined in order to construct coherent and 291 consistent state. The details of this mechanism are specific to the 292 particular document type. See Section 4.6 for information on 293 constructing coherent information from an 294 application/conference-info+xml document. 296 3.8 Handling of Forked Requests 298 By their nature, the conferences supported by this package are 299 centralized. Therefore, SUBSCRIBE requests for a conference should 300 not generally fork. Users of this package MUST NOT install more than 301 a single subscription as a result of a single SUBSCRIBE request. 303 3.9 Rate of Notifications 305 For reasons of congestion control, it is important that the rate of 306 notifications not become excessive. As a result, it is RECOMMENDED 307 that the server not generate notifications for a single subscriber at 308 a rate faster than once every 5 seconds. 310 3.10 State Agents 312 Conference state is ideally maintained in the element in which the 313 conference resides. Therefore, the elements that maintain the 314 conference are the ones best suited to handle subscriptions to it. 315 Therefore, the usage of state agents is NOT RECOMMENDED for this 316 package. 318 4. Conference Document 320 4.1 Format 322 Conference information is an XML document that MUST be well-formed 323 and SHOULD be valid. It MUST be based on Extensible Markup Language 324 (XML) 1.0 and MUST be encoded using UTF-8 [11]. 326 4.2 Namespace 328 This specification makes use of XML namespaces for identifying 329 conference information documents and document fragments. The 330 namespace URI for elements defined by this specification is a URN 331 [2], using the namespace identifier 'ietf' defined by [4] and 332 extended by RFC 3688 [12]. This URN is: 334 urn:ietf:params:xml:ns:conference-info 336 4.3 Versioning 338 The conference information is described by a hierarchal XML structure 339 with the root element . The root element is the 340 only element in the schema that carries meaningful version number for 341 all the elements in the document. The whole conference information 342 is associated with this version number. 344 The optional 'version' attribute MUST be included in the root 345 element. 347 4.4 State and Partial Notifications 349 All sub-elements in the hierarchal XML structure 350 can be classified in two groups: those that carry relatively small 351 amount of data and those that can potentially carry a lot of data. 352 During partial notifications, the light elements are updated as 353 atomic pieces of data. On the other hand, elements that can carry a 354 substantial amount of data have the general 'state' attribute 355 attached to them. That is in order to support partial notifications 356 for their content. 358 The 'state' attribute indicates whether the reported information 359 about the element is "full", "partial" or the element is "deleted" 360 from the conference state document. The default value of any 'state' 361 attribute is "full". 363 A 'state' attribute of a child element in the document MUST adhere to 364 its parent 'state'. It means that if the parent's 'state' is "full", 365 the state of its children MUST be "full". If the parent's 'state' is 366 "partial", the state of its children MAY be either "partial", "full", 367 or "deleted". 369 4.5 Element Keys 371 In the context of this specification, the element key is the set of 372 mandatory attributes or sub-elements of the element. The key value 373 MUST be unique for the element among its siblings of the same type. 375 In a partial notification event it must be possible to uniquely 376 identify each sub-element among others of the same type under a 377 common parent element. In order to achieve this property, all 378 sub-elements, with possible multiple appearances under a common 379 parent (which has the attribute 'state') have keys defined to them. 381 Below is the list of the elements with their keys as defined by this 382 specification: 384 o Elements , , and use as the key 385 'entity' 386 o Element uses as the key 'id' 387 o Sub-element of uris-type contained in elements 388 , , and uses as the key 389 390 o Elements and of 391 conference-medias-type use as the key 392 o Elements and of count-type use 393 as the key 394 o Element of user-roles-type uses as the key 395 o Sub-element of conference-type contained in element 396 uses as the key 'entity' 397 o Elements and of uris-type use 398 as the key 400 4.6 Constructing Coherent State Procedure 402 A Conference package subscriber MUST initialize the 'version' 403 attribute from the element with the value in the 404 first document received. 406 The conference package subscriber locally maintains a local element 407 for each element in the schema and a table for each element with 408 key(s) in the schema and indexed by these key(s). 410 Each time a new NOTIFY is received, the value of the local version 411 number and the value of the 'version' attribute in the new received 412 document are compared. If the value in the document is less than the 413 local version, the document is discarded without processing. If the 414 value in the document is higher than the local version number, the 415 local version number is set to the value in the new document and the 416 document is processed. If the value in the received document is more 417 than one higher than the previous local version number and the 418 document contained a partial state, the subscriber SHOULD generate a 419 refresh request to trigger a full state notification. 421 Further processing of the conference information depends on the state 422 contained in the received conference document and indicated by the 423 value of the 'state' attribute in the element. If 424 it contains "full" state, the whole local content is flushed and 425 repopulated from the document. If it contains "deleted" state, it 426 means that the conference ceased to exist and the subscriber SHOULD 427 terminate the subscription by sending the SUBSCRIBE with Expires = 0. 429 If the document contains "partial" state, the document is used to 430 update the local content as described below. 432 Starting from outer elements in the received document, 434 1. If the parent element contains "full" state, the whole local 435 element content is flushed and repopulated from the document. 437 2. Otherwise, if the parent element contains "deleted" state, the 438 whole element MUST be removed from the local content. 440 3. Otherwise, if the parent element contains "partial" state: 442 3.1 For elements with keys, the subscriber compares the keys received 443 in the update with the keys in the local tables. 445 3.1.1 If a key does not exist in the local table, a row is added, and 446 its content is set to the element information from the update. 448 3.1.2 Otherwise, if a key of the same value does exist, for each 449 sub-element in the row the algorithm is applied from step 2.2. 451 3.2 For each atomic element received in the schema, the element is 452 replaced with the new information as a whole. Also, for each 453 non-atomic element received in the schema with either no 'state' 454 attribute included or the state attribute is set to "full", the 455 element is replaced with the new information as a whole. 457 3.3 For each non-atomic element with the state attribute set to 458 "partial", the algorithm is applied recursively starting from step 3. 460 5. Conference Data 462 A conference information document begins with the root element tag 463 of conference-type. Sections below describe the 464 complex types composing the hierarchal conference-type. The full XML 465 schema is defined in Section 6. 467 5.1 conference-type 469 This type defines the following attributes: 471 entity: This attribute contains the conference URI that identifies 472 the conference being described in the document. 474 state: This attribute indicates whether the document contains the 475 whole conference information ("full"), only the information that 476 has changed since the previous document ("partial"), or the 477 conference ceased to exist ("deleted"). For more details see 478 Section 4. 479 version: This attribute allows the recipient of conference 480 information documents to properly order them and it MUST be 481 included when used in the root element. 482 Versions start at 0 and increment by one for each new document 483 sent to a subscriber. Versions are scoped within a subscription. 484 Versions are represented using a 32 bit integer. 486 The conference-type defines an extendable sequence of child elements. 487 A "full" conference document MUST at least include the following 488 sub-elements: , , and 489 . 491 The child elements are described in details below: 493 5.1.1 conference-description of conference-description-type 495 This element contains conference information that is derived from 496 system conference policies, is set before the conference activation, 497 and is rarely changed during the conference lifetime. 499 5.1.2 host-info of host-type 501 This element contains information about the entity that hosts the 502 conference. This information is set before the conference 503 activation, and is rarely changed during the conference lifetime, 504 unless the whole conference is moved to be hosted by another entity. 506 5.1.3 conference-state of conference-state-type 508 This element contains the dynamic information about the current state 509 of the conference. 511 5.1.4 users of users-type 513 This element can contain an unbounded number of sub-elements 514 of user-type each containing the information about a participant in 515 the conference. 517 5.1.5 sidebars-by-ref of uris-type 519 This element contains sub-elements of uri-type which provide 520 pointers to sidebar information through sidebar URIs. The recipient 521 of the information can then subscribe to sidebar information 522 independently from the main conference package subscription. 524 5.1.6 sidebar-by-val of conference-type 526 This element provides sidebar information as a part of the main 527 conference package information. 529 5.2 conference-description-type 531 This type defines the 'state' attribute which can contain the values 532 "full", "partial", or "deleted". 534 This type defines an extendable sequence of the following child 535 elements: 537 5.2.1 display-text of string type 539 This element contains text description of the conference. 541 5.2.2 subject of string type 543 This element contains the subject of the conference. 545 5.2.3 free-text of string type 547 This element contains free form text about the conference. 549 5.2.4 keywords of keywords-type 551 This element contains a list of words that can be used by automatic 552 search engines to better classify the conference. 554 5.2.5 conf-uris of uris-type 556 This element contains a set of sub-elements - each containing 557 the information about an additional conference URI that this 558 conference can be accessed by. The value of the URI is included in 559 the sub-element and its description MAY be included in the 560 sub-element. 562 Examples of such URIs include h323: [15] and tel: [14] URIs. 564 5.2.6 service-uris of uris-type 566 This element contains a set of sub-elements - each containing 567 the URI to be used in order to access different services available 568 for the particular conference. The value of the URI is included in 569 the sub-element and its description MAY be included in the 570 sub-element. The purpose of the URI SHOULD be 571 included in the sub-element. The only currently defined 572 value is "web-page" which indicates a web page that 573 contains additional information about the conference. Future 574 extensions to this schema may define new values and establish an IANA 575 registry for the new values. 577 5.2.7 maximum-user-count of user-count-type 579 This element is used to specify the maximum number of users permitted 580 in the conference. The number SHOULD be provided for all 581 participants in total by populating the sub-element with value 582 "any". Additionally counters for users with certain roles in the 583 conference MAY be separately provided. 585 5.2.8 available-media of conference-medias-type 587 This element contains information about the media types available in 588 the conference. The sub-element MUST contain one of the 589 values registered for "proto" of SDP [3] and its later revision(s). 591 5.3 host-type 593 This type defines the 'state' attribute which can contain the values 594 "full", "partial", or "deleted". 596 This type defines an extendable sequence of the following child 597 elements: 599 5.3.1 display-text of string type 601 This element contains display text information about the entity 602 hosting the conference. 604 5.3.2 web-page of anyURI type 606 This element contains a web page URI about the user hosting the 607 conference. 609 5.3.3 uris of uris-type 611 The sub-element contains additional URIs pointing to the 612 conference host. 614 5.4 conference-state-type 616 This type defines the 'state' attribute which can contain the values 617 "full", "partial", or "deleted". 619 This type defines an extendable sequence of the following child 620 elements. 622 5.4.1 user-count of user-count-type 624 This element is used to specify the current number of users in the 625 conference. The number SHOULD be provided for all participants in 626 total by populating the sub-element with value "any". 627 Additionally counters for users with certain roles in the conference 628 MAY be separately provided. 630 5.4.2 active of Boolean type 632 This element says whether the conference is currently active or not. 633 For example, a conference can be scheduled for a certain start time 634 and its conference URI reserved and published. Still, the conference 635 will not be "active" till its actual start time. 637 5.4.3 locked of Boolean type 639 This element contains information about whether the conference is 640 currently locked. In this context, "locked" means that the 641 conference roster can not be added to (although participants may 642 leave or be removed from the conference). 644 5.4.4 recording of uris-type 646 The sub-element contains URIs related to the recording of the 647 conference. 649 5.4.5 active-media of conference-medias-type 651 This element contains information about the media types currently 652 active in the conference, which is a subset of those listed in the 653 element. 655 5.5 user-type 657 This type defines the following attributes: 659 entity: This attribute contains the URI for the user in the 660 conference. This is a logical identifier, which corresponds to 661 the authenticated identity of the participant. The 'entity' 662 attribute MUST be unique in the user element list because it is 663 used as the key in partial notifications about users' state. An 664 anonymous participant in a conference SHOULD be represented by an 665 anonymous URI generated by the focus. For multiple anonymous 666 participants, the focus must ensure that each anonymous URI is 667 unique. The guidelines for generating anonymous URIs in RFC 3323 668 [8] should be followed. For example, 670 "Anonymous1" 672 could be used for a participant requesting privacy. 674 state: This attribute indicates whether the document contains the 675 whole conference information ("full"), only the information that 676 has changed since the previous document ("partial"), or the 677 conference ceased to exist ("deleted"). 679 This type defines an extendable sequence of the following child 680 elements. 682 5.5.1 display-text of string type 684 This element contains the display text for the user. 686 5.5.2 associated-aors of anyURI type 688 This element contains associated URIs of the user. Usually this 689 information will be manually provided by a system administrator 690 showing the logical association between signaling entities otherwise 691 independent. 693 5.5.3 roles of user-roles-type 695 This element contains the roles of the user. 697 5.5.4 language of language type 699 This element contains the language preference of the user. This 700 information can be automatically learned via call signaling or be 701 manually set per participant. 703 5.5.5 cascaded-focus of anyURI type 705 This element contains a conference URI (different from the main 706 conference URI) for users that are connected to the main conference 707 as a result of focus cascading. In accordance with the SIP 708 conferencing framework [16], this package allows for representation 709 of peer-to-peer (i.e. "flat") focus cascading only. The actual 710 cascading graph can not be deduced from the information provided in 711 the package alone. Advanced applications can construct the graph by 712 subscribing to both this package and the Dialog Package [17] of the 713 cascaded foci and correlating the relevant information. 715 5.5.6 endpoint of endpoint-type 717 This element contains information about an endpoint of the user. The 718 element of the endpoint-type can have unbounded number of appearance 719 in the user-type for each endpoint of the user participating in the 720 conference. In a case when authentication is performed per endpoint 721 (rather than per user) in a system, a focus can be not aware of the 722 logical association among endpoints being used by the same user. In 723 this case the focus MAY present the endpoints as belonging to 724 separate users in the conference schema. 726 In a different case, due to privacy concerns for a user, the focus 727 may want to shield the information about multiple endpoints from the 728 recipients of the Conference document. To do so the focus MAY 729 aggregate the multiple endpoint information into a single endpoint 730 element under this user. 732 5.6 endpoint-type 734 This type defines the following attributes: 736 entity: The attribute contains the endpoint URI for the user in the 737 conference. In SIP terms, this is the Contact URI or GRUU. The 738 'entity' attribute MUST be unique in the endpoint element list 739 because it is used as the key in partial notifications about 740 users' endpoints. An endpoint belonging to an anonymous 741 participant in a conference SHOULD be represented by an anonymous 742 URI generated by the focus. For multiple anonymous endpoints, the 743 focus must ensure that each anonymous URI is unique. The 744 guidelines for generating anonymous URIs in RFC 3323 [8] should be 745 followed. 747 state: This attribute indicates whether the element contains the 748 whole endpoint information ("full"), only the information that has 749 changed since the previous document ("partial"), or the endpoint 750 has been deleted from the conference ("deleted"). 752 This type defines an extendable sequence of the following child 753 elements. 755 5.6.1 display-text of string type 757 This element contains the display text for the endpoint. 759 5.6.2 referred of execution-type 761 This element contains information about the user who's action 762 resulted in this endpoint being brought into the conference (e.g. 763 the SIP user identified by this URI sent a REFER to the focus). It 764 can contain the following sub-elements: 766 when: This element contains the date and time that the endpoint was 767 referred to the conference. 769 reason: This element contains the reason the endpoint was referred to 770 the conference. 772 by: This element contains the URI of the entity who caused the 773 endpoint to be referred to the conference. 775 5.6.3 status of endpoint-status-type 777 This element contains the status of the endpoint, and can assume the 778 following values: 780 connected: The endpoint is a participant in the conference. 781 Depending on the media policies, he/she can send and receive media 782 to and from other participants. 784 disconnected: The endpoint is not a participant in the conference and 785 no active dialog exists between the endpoint and the focus. 787 on-hold: Active SIP dialog exists between an endpoint and a focus, 788 but endpoint is "on-hold" for this conference, i.e. neither 789 he/she is "hearing" the conference mix, nor is his/her media being 790 mixed in the conference. As an example, the endpoint has asked to 791 join the conference using SIP, but his/her participation is 792 pending based on moderator approval. In the meantime he/she is 793 hearing music-on-hold or some other kind of related content. 795 muted-via-focus: Active SIP dialog exists between an endpoint and a 796 focus and the endpoint can "listen" to the conference, but 797 endpoint's media is not being mixed into the conference. Note 798 that sometimes a subset of endpoint media streams can be muted by 799 focus (such as poor quality video) while others (such as voice or 800 IM) can still be active. In this case, it is RECOMMENDED that the 801 "aggregated" endpoint connectivity reflects the status of 802 the mostly active media. 804 pending: Endpoint is not yet in the session, but it is anticipated 805 that he/she will join in the near future. 807 alerting: A PSTN ALERTING or SIP 180 Ringing was returned for the 808 outbound call, endpoint is being alerted. 810 dialing-in: Endpoint is dialing into the conference, not yet in the 811 roster (probably being authenticated). 813 dialing-out: Focus has dialed out to connect the endpoint to the 814 conference, but the endpoint is not yet in the roster (probably 815 being authenticated). 817 disconnecting: Focus is in the process of disconnecting endpoint 818 (either DISCONNECT or BYE was sent to the endpoint). 820 Note that the defined transient statuss (e.g., disconnecting, 821 alerting, etc.) could generate a lot of notifications. 822 Implementations MAY choose not to generate notifications on these to 823 all participants if it will generate too much traffic. 825 5.6.4 joining-method of joining-type 827 This element contains method by which the endpoint joined the 828 conference, and can assume the following values: 830 dialed-in: The endpoint dialed into the conference, i.e. sent INVITE 831 to the focus, which resulted in successful dialog establishment. 833 dialed-out: The focus has brought the endpoint into the conference by 834 sending a successful INVITE to the endpoint. 836 focus-owner: The endpoint is the focus for this conference. This 837 status is used only when a participant�s UA acts as a conference 838 focus. 840 5.6.5 joining-info of execution-type 842 This element contains information about how the endpoint joined and 843 can contain the following sub-elements: 845 when: This element contains the date and time that the endpoint 846 joined the conference. 848 reason: This element contains the reason the endpoint joined the 849 conference. 851 by: This element contains the URI of the entity who caused the 852 endpoint to join the conference. 854 5.6.6 disconnection-method of disconnection-type 856 This element contains method by which the endpoint departed the 857 conference, and can assume the following values: 859 departed: The endpoint sent a BYE, thus leaving the conference. 861 booted: The endpoint was sent a BYE by the focus, booting him/her out 862 of the conference. Alternatively, the endpoint tried to dial into 863 to conference without success because was rejected by the focus 864 according to local policy decisions. 866 failed: The server tried to bring the endpoint into the conference, 867 but its attempt to contact the specific endpoint resulted in a 868 non-200 class final response. Alternatively, the endpoint tried 869 to dial into the conference without success due to technical 870 reasons. 872 5.6.7 disconnection-info of execution-type 874 This element contains information about the endpoint's departure from 875 the conference and can contain the following sub-elements: 877 when: This element contains the date and time that the endpoint 878 departed the conference. 880 reason: This element contains the reason the endpoint departed the 881 conference. When known, it is RECOMMENDED to include the numeric 882 reason followed by the descriptive text as conveyed/reported by 883 the call signaling. 885 by: This element contains the URI of the entity who caused the 886 endpoint to depart the conference. 888 5.6.8 media of media-type 890 This element contains information about a media stream of this 891 endpoint. The element of the media-type can have unbounded number of 892 appearance in the endpoint-type for each media stream of the 893 endpoint. Note that it is possible that media streams listed under a 894 common endpoint MAY be established by separate signaling means and 895 consequently belong to different signaling "calls". 897 5.7 media-type 899 This type defines the following attributes: 901 id: The attribute is a unique identifier of a media stream on a per 902 endpoint basis. This attribute is used as a key to identify media 903 streams which may be added and deleted on a dynamic basis during 904 the conference. If the SDP "mid" (as defined in Grouping of Media 905 Lines in the SDP [9]) is used for establishing the media stream, 906 the 'id' SHOULD contain the same "mid" value, otherwise the 907 notification service MUST generate an 'id' value which is unique 908 in the endpoint context. 910 state: This attribute indicates whether the element contains the 911 whole media information ("full"), only the information that has 912 changed since the previous notification ("partial"), or that the 913 media element has been deleted from the conference document 914 ("deleted"). 916 This type defines an extendable sequence of the following child 917 elements. 919 5.7.1 display-text of string type 921 This element contains the display text for the media stream. 923 5.7.2 proto of string type 925 This element contains the media type for the media stream. The value 926 of this element MUST be one of the values registered for "proto" of 927 SDP [3] and its later revision(s). 929 5.7.3 src-id of string type 931 The element, if applicable, carries the information about 932 the actual source of the media. For example, for the RTP/RTCP [10] 933 media streams the value MUST contain the SSRC value generated by the 934 endpoint for the stream it sends. 936 When an RTP mixer generates a CSRC list according to RTP/RTCP [10], 937 it inserts a list of the SSRC identifiers of the sources that 938 contributed to the generation of a particular packet into the RTP 939 header of that packet. A quote from RFC 3550: "An example 940 application is audio conferencing where a mixer indicates all the 941 talkers whose speech was combined to produce the outgoing packet, 942 allowing the receiver to indicate the current talker, even though all 943 the audio packets contain the same SSRC identifier (that of the 944 mixer)." 946 5.7.4 label of string type 948 The element