draft-ietf-sipping-conference-package-05.txt   draft-ietf-sipping-conference-package-06.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft dynamicsoft Internet-Draft dynamicsoft
Expires: January 16, 2005 H. Schulzrinne Expires: April 25, 2005 H. Schulzrinne
Columbia University Columbia University
O. Levin, Ed. O. Levin, Ed.
Microsoft Corporation Microsoft Corporation
July 18, 2004 October 25, 2004
A Session Initiation Protocol (SIP) Event Package for Conference A Session Initiation Protocol (SIP) Event Package for Conference
State State
draft-ietf-sipping-conference-package-05 draft-ietf-sipping-conference-package-06
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 16, 2005. This Internet-Draft will expire on April 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This document defines a conference event package for the Session This document defines a conference event package for the Session
Initiation Protocol (SIP) Events framework, along with a data format Initiation Protocol (SIP) Events framework, along with a data format
used in notifications for this package. The conference package used in notifications for this package. The conference package
allows users to subscribe to a conference URI. Notifications are allows users to subscribe to a conference URI. Notifications are
sent about changes in the membership of this conference and sent about changes in the membership of this conference and
optionally about changes in the state of additional conference optionally about changes in the state of additional conference
components. components.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Conference Event Package . . . . . . . . . . . . . . . . . . . 6 3. Conference Event Package . . . . . . . . . . . . . . . . . . . 7
3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 6 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 7
3.2 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6 3.2 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 7
3.3 Subscription Duration . . . . . . . . . . . . . . . . . . 6 3.3 Subscription Duration . . . . . . . . . . . . . . . . . . 7
3.4 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 7 3.4 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 8
3.5 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 7 3.5 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 8
3.6 Notifier Generation of NOTIFY Requests . . . . . . . . . . 7 3.6 Notifier Generation of NOTIFY Requests . . . . . . . . . . 8
3.7 Subscriber Processing of NOTIFY Requests . . . . . . . . . 8 3.7 Subscriber Processing of NOTIFY Requests . . . . . . . . . 9
3.8 Handling of Forked Requests . . . . . . . . . . . . . . . 8 3.8 Handling of Forked Requests . . . . . . . . . . . . . . . 9
3.9 Rate of Notifications . . . . . . . . . . . . . . . . . . 8 3.9 Rate of Notifications . . . . . . . . . . . . . . . . . . 9
3.10 State Agents . . . . . . . . . . . . . . . . . . . . . . . 8 3.10 State Agents . . . . . . . . . . . . . . . . . . . . . . . 9
4. Conference Data Format . . . . . . . . . . . . . . . . . . . . 10 4. Conference Data Model . . . . . . . . . . . . . . . . . . . . 11
4.1 Conference Information . . . . . . . . . . . . . . . . . . 10 5. Constructing Coherent State . . . . . . . . . . . . . . . . . 12
4.1.1 User Element . . . . . . . . . . . . . . . . . . . . . 10 6. Conference Data . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1.1 User Attributes . . . . . . . . . . . . . . . . . 11 6.1 Conference Information . . . . . . . . . . . . . . . . . . 14
4.1.1.2 User Status Elements . . . . . . . . . . . . . . . 12 6.1.1 Conference Type . . . . . . . . . . . . . . . . . . . 14
4.1.1.3 Media Information . . . . . . . . . . . . . . . . 13 6.1.1.1 conference-description of
4.1.1.3.1 Media Attributes . . . . . . . . . . . . . . . 13 conference-description-type . . . . . . . . . . . 14
4.1.1.3.2 Media Elements . . . . . . . . . . . . . . . . 14 6.1.1.2 host-info of host-type . . . . . . . . . . . . . . 14
4.1.1.4 User Role . . . . . . . . . . . . . . . . . . . . 14 6.1.1.3 conference-state of conference-state-type . . . . 15
4.1.2 Sidebar Element . . . . . . . . . . . . . . . . . . . 15 6.1.1.4 user of user-type . . . . . . . . . . . . . . . . 15
4.1.3 Additional Conference Identifiers . . . . . . . . . . 15 6.1.1.5 sidebars-by-ref of uris-type . . . . . . . . . . . 15
4.1.4 Policy URIs . . . . . . . . . . . . . . . . . . . . . 15 6.1.1.6 sidebar-by-val of conference-type . . . . . . . . 15
4.1.5 Recording . . . . . . . . . . . . . . . . . . . . . . 15 6.1.2 Conference Description Type . . . . . . . . . . . . . 15
4.1.6 Streaming . . . . . . . . . . . . . . . . . . . . . . 16 6.1.2.1 display-text of string type . . . . . . . . . . . 15
4.2 Constructing Coherent State . . . . . . . . . . . . . . . 16 6.1.2.2 subject of string type . . . . . . . . . . . . . . 15
4.2.1 The Algorithm . . . . . . . . . . . . . . . . . . . . 17 6.1.2.3 free-text of string type . . . . . . . . . . . . . 15
4.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1.2.4 keywords of keywords-type . . . . . . . . . . . . 16
4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1.2.5 web-page of anyURI type . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6.1.2.6 conf-uris of uris-type . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 6.1.2.7 service-uris of uris-type . . . . . . . . . . . . 16
6.1 conference Event Package Registration . . . . . . . . . . 24 6.1.2.8 maximum-user-count of user-count-type . . . . . . 16
6.2 application/conference-info+xml MIME Registration . . . . 24 6.1.2.9 available-media of conference-medias-type . . . . 16
6.3 URN Sub-Namespace Registration for 6.1.3 Host Type . . . . . . . . . . . . . . . . . . . . . . 16
urn:ietf:params:xml:ns:conference-info . . . . . . . . . . 24 6.1.3.1 display-text of string type . . . . . . . . . . . 16
6.4 XML Schema Registration . . . . . . . . . . . . . . . . . 25 6.1.3.2 web-page of anyURI type . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 6.1.3.3 uris of uris-type . . . . . . . . . . . . . . . . 17
8. Changes History . . . . . . . . . . . . . . . . . . . . . . . 27 6.1.4 Conference State Type . . . . . . . . . . . . . . . . 17
8.1 Changes since -04 . . . . . . . . . . . . . . . . . . . . 27 6.1.4.1 user-count of user-count-type . . . . . . . . . . 17
8.2 Changes since -03 . . . . . . . . . . . . . . . . . . . . 27 6.1.4.2 security-level of security-level-type . . . . . . 17
8.3 Changes since -02 . . . . . . . . . . . . . . . . . . . . 27 6.1.4.3 active of Boolean type . . . . . . . . . . . . . . 17
8.4 Changes since -01 . . . . . . . . . . . . . . . . . . . . 28 6.1.4.4 locked of Boolean type . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1.4.5 recording of uris-type . . . . . . . . . . . . . . 17
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 29 6.1.4.6 active-media of conference-medias-type . . . . . . 18
9.2 Informative References . . . . . . . . . . . . . . . . . . . 29 6.1.5 User Type . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 6.1.5.1 display-text of string type . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 32 6.1.5.2 associated-aors of anyURI type . . . . . . . . . . 18
6.1.5.3 roles of user-roles-type . . . . . . . . . . . . . 18
6.1.5.4 language of language type . . . . . . . . . . . . 19
6.1.5.5 cascaded-focus of anyURI type . . . . . . . . . . 19
6.1.5.6 endpoint of endpoint-type . . . . . . . . . . . . 19
6.1.6 Endpoint Type . . . . . . . . . . . . . . . . . . . . 19
6.1.6.1 display-text of string type . . . . . . . . . . . 20
6.1.6.2 referred of execution-type . . . . . . . . . . . . 20
6.1.6.3 state of endpoint-state-type . . . . . . . . . . . 20
6.1.6.4 joining-method of joining-type . . . . . . . . . . 21
6.1.6.5 joining-info of execution-type . . . . . . . . . . 21
6.1.6.6 disconnection-method of disconnection-type . . . . 22
6.1.6.7 disconnection-info of disconnection-type . . . . . 22
6.1.6.8 whispering-to of uris-type . . . . . . . . . . . . 22
6.1.6.9 media of media-type . . . . . . . . . . . . . . . 22
6.1.7 Media Type . . . . . . . . . . . . . . . . . . . . . . 23
6.1.7.1 display-text of string type . . . . . . . . . . . 23
6.1.7.2 proto of string type . . . . . . . . . . . . . . . 23
6.1.7.3 ssrc of string type . . . . . . . . . . . . . . . 23
6.1.7.4 label of string type . . . . . . . . . . . . . . . 24
6.1.7.5 state of media-state-type . . . . . . . . . . . . 24
6.1.7.6 snd-status of media-state-type . . . . . . . . . . 24
6.1.7.7 rcv-status state of media-state-type . . . . . . . 24
6.1.7.8 call of call-type . . . . . . . . . . . . . . . . 24
7. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1 Basic Example . . . . . . . . . . . . . . . . . . . . . . 33
8.2 Rich Example . . . . . . . . . . . . . . . . . . . . . . . 35
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41
10.1 conference Event Package Registration . . . . . . . . . . 41
10.2 application/conference-info+xml MIME Registration . . . . 41
10.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:conference-info . . . . . . . . . . 41
10.4 XML Schema Registration . . . . . . . . . . . . . . . . . 42
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
12. Changes History . . . . . . . . . . . . . . . . . . . . . . 44
12.1 Changes since -05 . . . . . . . . . . . . . . . . . . . . 44
12.2 Changes since -04 . . . . . . . . . . . . . . . . . . . . 44
12.3 Changes since -03 . . . . . . . . . . . . . . . . . . . . 44
12.4 Changes since -02 . . . . . . . . . . . . . . . . . . . . 44
12.5 Changes since -01 . . . . . . . . . . . . . . . . . . . . 45
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
13.1 Normative References . . . . . . . . . . . . . . . . . . . . 46
13.2 Informative References . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . 49
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [6] Events framework Events The Session Initiation Protocol (SIP) [6] Events framework Events
Framework [7] defines general mechanisms for subscribing to, and Framework [7] defines general mechanisms for subscribing to, and
receiving notifications of, events within SIP networks. It receiving notifications of, events within SIP networks. It
introduces the notion of a package, which is a specific introduces the notion of a package, which is a specific
"instantiation" of the events framework for a well-defined set of "instantiation" of the events framework for a well-defined set of
events. Here, we define an event package for SIP conferences. This events. Here, we define an event package for SIP conferences. This
package provides the conference notification service as outlined in package provides the conference notification service as outlined in
the SIP conferencing framework [14]. As described there, the SIP conferencing framework [15]. As described there,
subscriptions to a conference URI are routed to the focus that is subscriptions to a conference URI are routed to the focus that is
handling the conference. It acts as the notifier, and provides handling the conference. It acts as the notifier, and provides
clients with updates on conference state. clients with updates on conference state.
The information provided by this package is comprised of conference The information provided by this package is comprised of conference
identifier(s), conference participants (optionally with their identifier(s), conference participants (optionally with their
statuses and media description), conference sidebars, conference statuses and media description), conference sidebars, conference
policy URIs, etc. service URIs, etc.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. Conference Event Package 3. Conference Event Package
The conference event package allows a user to subscribe to a The conference event package allows a user to subscribe to a
conference. In SIP, conferences are represented by URIs. These URIs conference. In SIP, conferences are represented by URIs. These URIs
route to a SIP user agent, called a focus, that is responsible for route to a SIP user agent, called a focus, that is responsible for
ensuring that all users in the conference can communicate with each ensuring that all users in the conference can communicate with each
other, as described in Conferencing Framework [14]. The focus has other, as described in Conferencing Framework [15]. The focus has
sufficient information about the state of the conference to inform sufficient information about the state of the conference to inform
subscribers about it. subscribers about it.
It is possible a participant in the conference may in fact be another It is possible a participant in the conference may in fact be another
focus. In order to provide a more complete participant list, the focus. In order to provide a more complete participant list, the
focus MAY subscribe to the conference package of the other focus to focus MAY subscribe to the conference package of the other focus to
discover the participant list in the cascaded conference. This discover the participant list in the cascaded conference. This
information can then be included in notifications by using of the information can then be included in notifications by using of the
"cascaded-focus" attribute as specified by this package. "cascaded-focus" element as specified by this package.
This section provides the details for defining a SIP Events package, This section provides the details for defining a SIP Events package,
as specified by RFC 3265 [7]. as specified by RFC 3265 [7].
3.1 Event Package Name 3.1 Event Package Name
The name of this event package is "conference". This package name is The name of this event package is "conference". This package name is
carried in the Event and Allow-Events header, as defined in RFC 3265 carried in the Event and Allow-Events header, as defined in RFC 3265
[7]. [7].
skipping to change at page 7, line 17 skipping to change at page 8, line 17
As described in RFC 3265 [7], the NOTIFY message will contain bodies As described in RFC 3265 [7], the NOTIFY message will contain bodies
that describe the state of the subscribed resource. This body is in that describe the state of the subscribed resource. This body is in
a format listed in the Accept header field of the SUBSCRIBE, or a a format listed in the Accept header field of the SUBSCRIBE, or a
package-specific default if the Accept header field was omitted from package-specific default if the Accept header field was omitted from
the SUBSCRIBE. the SUBSCRIBE.
In this event package, the body of the notification contains a In this event package, the body of the notification contains a
conference information document. This document describes the state conference information document. This document describes the state
of a conference. All subscribers and notifiers MUST support the of a conference. All subscribers and notifiers MUST support the
"application/conference-info+xml" data format described in Section 4. "application/conference-info+xml" data format described in Section 6.
The subscribe request MAY contain an Accept header field. If no such The subscribe request MAY contain an Accept header field. If no such
header field is present, it has a default value of "application/ header field is present, it has a default value of
conference-info+xml". If the header field is present, it MUST "application/conference-info+xml". If the header field is present,
include "application/conference-info+xml", and MAY include any other it MUST include "application/conference-info+xml", and MAY include
types capable of representing dialog state. any other types.
Of course, the notifications generated by the server MUST be in one Of course, the notifications generated by the server MUST be in one
of the formats specified in the Accept header field in the SUBSCRIBE of the formats specified in the Accept header field in the SUBSCRIBE
request. request.
3.5 Notifier Processing of SUBSCRIBE Requests 3.5 Notifier Processing of SUBSCRIBE Requests
The conference information contains very sensitive information. The conference information contains very sensitive information.
Therefore, all subscriptions SHOULD be authenticated and then Therefore, all subscriptions SHOULD be authenticated and then
authorized before approval. Authorization policy is at the authorized before approval. Authorization policy is at the
discretion of the administrator, as always. However, a few discretion of the administrator, as always. However, a few
recommendations can be made. recommendations can be made.
It is RECOMMENDED that all users in the conference be allowed to It is RECOMMENDED that all users in the conference be allowed to
subscribe to the conference. subscribe to the conference.
3.6 Notifier Generation of NOTIFY Requests 3.6 Notifier Generation of NOTIFY Requests
Notifications SHOULD be generated for the conference whenever there Notifications MUST be generated for the conference state when a new
is a change in the state in any of the information delivered to the participant joins (i.e. gets "connected" to) or a participant leaves
subscriber. (i.e. gets "disconnected" from) the conference.
The changes generally occur when a new participant joins (i.e. gets
"connected" to) or a participant leaves (i.e. gets "disconnected"
from) the conference.
Subject to a local focus policy, additional changes in participant's Subject to a local focus policy, additional changes in participants'
status, changes in its media types, and other optional media status, changes in their media types, and other optional information
attributes MAY be reported by the focus. MAY be reported by the focus.
Changes in sidebar rosters SHOULD be reported by the focus to their Changes in sidebar rosters SHOULD be reported by the focus to their
participants and MAY be reported to others, subject to local policy. participants and MAY be reported to others, subject to local policy.
Changes in conference identifiers and policy URIs SHOULD be reported Changes in conference identifiers and service URIs SHOULD be reported
by the focus to the conference participants. by the focus to the Conference package subscribers.
Changes in other conference state information MAY be reported by the
focus to the Conference package subscribers.
3.7 Subscriber Processing of NOTIFY Requests 3.7 Subscriber Processing of NOTIFY Requests
The SIP Events framework expects packages to specify how a subscriber The SIP Events framework expects packages to specify how a subscriber
processes NOTIFY requests in any package specific ways, and in processes NOTIFY requests in any package specific ways, and in
particular, how it uses the NOTIFY requests to construct a coherent particular, how it uses the NOTIFY requests to construct a coherent
view of the state of the subscribed resource. view of the state of the subscribed resource.
Typically, the NOTIFY for the conference package will only contain Typically, the NOTIFY for the conference package will only contain
information about those users whose state in the conference has information about those users whose state in the conference has
changed. To construct a coherent view of the total state of all changed. To construct a coherent view of the total state of all
users, a subscriber to the conference package will need to combine users, a subscriber to the conference package will need to combine
NOTIFYs received over time. NOTIFYs received over time.
Notifications within this package can convey partial information; Notifications within this package can convey partial information;
that is, they can indicate information about a subset of the state that is, they can indicate information about a subset of the state
associated with the subscription. This means that an explicit associated with the subscription. This means that an explicit
algorithm needs to be defined in order to construct coherent and algorithm needs to be defined in order to construct coherent and
consistent state. The details of this mechanism are specific to the consistent state. The details of this mechanism are specific to the
particular document type. See Section 4.2 for information on particular document type. See Section 5 for information on
constructing coherent information from an application/ constructing coherent information from an
conference-info+xml document. application/conference-info+xml document.
3.8 Handling of Forked Requests 3.8 Handling of Forked Requests
By their nature, the conferences supported by this package are By their nature, the conferences supported by this package are
centralized. Therefore, SUBSCRIBE requests for a conference should centralized. Therefore, SUBSCRIBE requests for a conference should
not generally fork. Users of this package MUST NOT install more than not generally fork. Users of this package MUST NOT install more than
a single subscription as a result of a single SUBSCRIBE request. a single subscription as a result of a single SUBSCRIBE request.
3.9 Rate of Notifications 3.9 Rate of Notifications
skipping to change at page 10, line 5 skipping to change at page 11, line 5
a rate faster than once every 5 seconds. a rate faster than once every 5 seconds.
3.10 State Agents 3.10 State Agents
Conference state is ideally maintained in the element in which the Conference state is ideally maintained in the element in which the
conference resides. Therefore, the elements that maintain the conference resides. Therefore, the elements that maintain the
conference are the ones best suited to handle subscriptions to it. conference are the ones best suited to handle subscriptions to it.
Therefore, the usage of state agents is NOT RECOMMENDED for this Therefore, the usage of state agents is NOT RECOMMENDED for this
package. package.
4. Conference Data Format 4. Conference Data Model
Conference information is an XML document that MUST be well-formed Conference information is an XML document that MUST be well-formed
and SHOULD be valid. Dialog information documents MUST be based on and SHOULD be valid. Dialog information documents MUST be based on
XML 1.0 and MUST be encoded using UTF-8. This specification makes XML 1.0 and MUST be encoded using UTF-8. This specification makes
use of XML namespaces for identifying dialog information documents use of XML namespaces for identifying dialog information documents
and document fragments. The namespace URI for elements defined by and document fragments. The namespace URI for elements defined by
this specification is a URN [3], using the namespace identifier this specification is a URN [3], using the namespace identifier
'ietf' defined by [4] and extended by [1]. This URN is: 'ietf' defined by [4] and extended by [1]. This URN is:
The conference information is described by a hierarchal XML structure
with the root element "conference-info". The root element is the
only element in the schema that carries meaningful version number for
all the elements in the document. The whole conference information
is associated with this version number.
All sub-elements in the "conference-info" hierarchal XML structure
can be classified in two groups: those that carry relatively small
amount of data and those that can potentially carry a lot of data.
During partial notifications, the light elements are updated as
atomic pieces of data. On the other hand, elements that can carry a
substantial amount of data have the general "state" attribute
attached to them. That is in order to support partial notifications
for their content.
A "state" attribute of a child element in the document MUST adhere to
its parent "state". It means that if the parent's "state" is "full",
the state of its children MUST be "full". If the parent's "state" is
"partial", the state of its children MAY be either "partial", "full",
or "deleted".
For elements with the optional "state" attribute, if the attribute is
omitted from the notification for the element, it means that the
reported element's state is "full".
All sub-elements, with possible multiple appearances under a common
parent, have keys defined to them in order to uniquely identify each
element among others of the same type in the partial notification
event.
5. Constructing Coherent State
A Conference package subscriber MUST initialize the "version"
attribute from the "conference-info" element with the value in the
first document received.
The conference package subscriber locally maintains a local element
for each element in the schema and a table for each element with
key(s) in the schema and indexed by these key(s).
Each time a new NOTIFY is received, the value of the local version
number and the "version" attribute in the new received document are
compared. If the value in the new document is one higher than the
local version number, the local version number is increased by one,
and the document is processed. If the value in the document is more
than one higher than the local version number, the local version
number is set to the value in the new document, the document is
processed, and the subscriber SHOULD generate a refresh request to
trigger a full state notification. If the value in the document is
less than the local version, the document is discarded without
processing.
Further processing of the conference information document depends on
whether it contains full or partial state. If it contains full
state, indicated by the value of the "state" attribute in the
"conference-info" element, the whole local content is flushed and
repopulated from the document. If it contains "deleted" state,
indicated by the value of the "state" attribute in the
"conference-info" element, it means that the conference ceased to
exist and the subscriber SHOULD terminate the SUBSCRIBE dialog.
If the document contains partial state, as indicated by the value of
the "state" attribute in the "conference-info" element, the document
is used to update the local content as described below.
Starting from outer elements in the received document,
1. If the parent element contains "full" state, the whole local
element content is flushed and repopulated from the document.
2. Otherwise, if the parent element contains "deleted" state, the
whole element MUST be removed from the local content.
3. Otherwise, if the parent element contains "partial" state:
3.1 For elements with keys, the subscriber compares the keys received
in the update with the keys in the local tables.
3.1.1 If a key does not exist in the local table, a row is added, and
its content is set to the element information from the update.
3.1.2 Otherwise, if a key of the same value does exist, for each
sub-element in the row the algorithm is applied from step 2.2.
3.2 For each atomic element received in the schema, the element is
replaced with the new information as a whole. Also, for each
non-atomic element received in the schema with either no "state"
attribute included or the state attribute is set to "full", the
element is replaced with the new information as a whole.
3.2.1 If an element, which doesnĘt have key(s), is updated or created
such that its content is empty, that element MAY be removed from the
local content at any time.
3.3 For each non-atomic element with the state attribute set to
"partial", the algorithm is applied recursively starting from step 3.
6. Conference Data
urn:ietf:params:xml:ns:conference-info urn:ietf:params:xml:ns:conference-info
A conference information document begins with the root element tag A conference information document begins with the root element tag
"conference-info". "conference-info".
4.1 Conference Information 6.1 Conference Information
A conference instance is defined as a top level element
"conference-info" of a type "conference-type". Sections below
describe the complex types composing the hierarchal
"conference-type". The full XML schema is defined in Section 7.
6.1.1 Conference Type
This type has the following attributes:
Conference information begins with the top level element
"conference-info". This element has three mandatory attributes:
version: This mandatory attribute allows the recipient of conference version: This mandatory attribute allows the recipient of conference
information documents to properly order them. Versions start at 0 information documents to properly order them. Versions start at 0
and increment by one for each new document sent to a subscriber. and increment by one for each new document sent to a subscriber.
Versions are scoped within a subscription. Versions MUST be Versions are scoped within a subscription. Versions MUST be
represented using a 32 bit integer. represented using a 32 bit integer.
state: This mandatory attribute indicates whether the document
contains the full conference information, or whether it contains
only the information that has changed since the previous document
(partial).
entity: This mandatory attribute contains the conference URI that entity: This mandatory attribute contains the conference URI that
identifies the conference being described in the document. identifies the conference being described in the document.
The "conference-info" element has zero or more "user" sub-elements state: This mandatory attribute indicates whether the document
which contain information on the users in the conference. This is contains the whole conference information ("full"), only the
followed by zero or more "sidebar" sub-elements which contain information that has changed since the previous document
information on the sidebars in the conference. This is followed by ("partial"), or the conference ceased to exist ("deleted"). For
zero or more "conf-uri" sub-elements which contain information on more details see Section 5.
additional URIs that the conference can be accessed by. This is
followed by zero or more "policy-uri" sub-elements which contain This type defines an extendable sequence of the following optional
information on additional URIs that the conference policies can be child elements:
accessed by. This is followed by "recording" and "streaming"
elements describing recording and streaming statuses of the 6.1.1.1 conference-description of conference-description-type
This element contains conference information that is derived from
system conference policies, is set before the conference activation,
and is rarely changed during the conference lifetime.
6.1.1.2 host-info of host-type
This element contains information about the entity that hosts the
conference. This information is set before the conference
activation, and is rarely changed during the conference lifetime,
unless the whole conference is moved to be hosted by another entity.
6.1.1.3 conference-state of conference-state-type
This element contains the dynamic information about the current state
of the focus.
6.1.1.4 user of user-type
This element contains the information about a participant in the
conference. The element of the user-type can have unbounded number
of appearance in the conference-type for each participant in the
conference. conference.
4.1.1 User Element 6.1.1.5 sidebars-by-ref of uris-type
4.1.1.1 User Attributes This element provides a pointer to sidebar information through
sidebar URIs. The recipient of the information can then subscribe to
sidebar information independently from the main Conference package
subscription.
The user element has one mandatory attribute, "uri" that indicates 6.1.1.6 sidebar-by-val of conference-type
the URI for the user in the conference. This is a logical
identifier, which corresponds to the authenticated identity of the
participant. The "uri" attribute MUST be unique in the user element
list because it is used as the key in partial notifications about
users' state.
If a conference participant has more than a single signaling dialog This element provides sidebar information as a part of the main
associated with the conference, the conference focus MAY present the Conference package information.
user's aggregated information (e.g. the statuses) and display all
its media streams under a single user element.
Note, that the optional element "instance" of "media" (see below) MAY 6.1.2 Conference Description Type
be used in this case to specify the actual signaling dialog for each
media stream.
An anonymous participant in a conference SHOULD be represented by an This element contains the "state" attribute which can contain the
values "full", "partial", or deleted".
This type defines an extendable sequence of the following optional
child elements:
6.1.2.1 display-text of string type
This element contains text information about the conference.
6.1.2.2 subject of string type
This element contains information about the subject of a conference.
6.1.2.3 free-text of string type
This element contains free form text about the conference.
6.1.2.4 keywords of keywords-type
This element contains a list of keywords which describe the
conference topic.
6.1.2.5 web-page of anyURI type
This element contains a URI of a web page that contains information
related to the conference.
6.1.2.6 conf-uris of uris-type
This element contains information about additional conference URIs
that this conference can be accessed by. Examples of such URIs
include h323: [14] and tel: [13] URIs.
6.1.2.7 service-uris of uris-type
This element contains the service-related URIs. These URIs can be
used to manipulate the conference policies or state, for example.
6.1.2.8 maximum-user-count of user-count-type
This element contains a count of the maximum number of users
permitted in the conference. The count can be specified for all
participants in total (using the sub-element with value "any") or
count the users by their roles in the conference.
6.1.2.9 available-media of conference-medias-type
This element contains information about the media types available in
a conference. The "entry" sub-element MUST be a value registered for
"proto" of SDP [12].
6.1.3 Host Type
This element contains the "state" attribute which can contain the
values "full", "partial", or deleted".
This type defines an extendable sequence of the following optional
child elements:
6.1.3.1 display-text of string type
This element contains display text information about the user hosting
the conference.
6.1.3.2 web-page of anyURI type
This element contains a web page URI about the user hosting the
conference.
6.1.3.3 uris of uris-type
The "entity" sub-element contains additional URIs relating to the
user hosting the conference.
6.1.4 Conference State Type
This element contains the "state" attribute which can contain the
values "full", "partial", or deleted".
This type defines an extendable sequence of the following optional
child elements.
6.1.4.1 user-count of user-count-type
This element contains a count of the current number of users in the
conference. The count can be specified for all participants in total
(using the sub-element with value "any") or count the users by their
roles in the conference.
6.1.4.2 security-level of security-level-type
This element contains information about the conference security
level. The values can be "none", "low", "medium", or "high".
6.1.4.3 active of Boolean type
This element contains information about whether the conference is
currently active or not.
6.1.4.4 locked of Boolean type
This element contains information about whether the conference is
currently locked. In this context, locked means that the conference
roster can not be added to (although participants may leave or be
removed from the conference).
6.1.4.5 recording of uris-type
The "entry" sub-element contains URIs related to the recording of the
conference.
6.1.4.6 active-media of conference-medias-type
This element contains information about the media types currently
active in the conference which is a subset of those listed in the
"available-media" element.
6.1.5 User Type
This type has the following attributes:
entity: The mandatory attribute contains the URI for the user in the
conference. This is a logical identifier, which corresponds to
the authenticated identity of the participant. The "entity"
attribute MUST be unique in the user element list because it is
used as the key in partial notifications about users' state. An
anonymous participant in a conference SHOULD be represented by an
anonymous URI generated by the focus. For multiple anonymous anonymous URI generated by the focus. For multiple anonymous
participants, the focus must ensure that each anonymous URI is participants, the focus must ensure that each anonymous URI is
unique. The guidelines for generating anonymous URIs in RFC 3323 [8] unique. The guidelines for generating anonymous URIs in RFC 3323
should be followed. For example, [8] should be followed. For example,
"Anonymous1" <sip:anonymous1@anonymous.invalid> "Anonymous1" <sip:anonymous1@anonymous.invalid>
could be used for a participant requesting privacy. could be used for a participant requesting privacy.
The optional attribute "display-name" contains a display name for the state: This mandatory attribute indicates whether the document
user. The standard "xml:lang" language attribute can also be present contains the whole conference information ("full"), only the
to indicate the language of the display-name. information that has changed since the previous document
("partial"), or the conference ceased to exist ("deleted").
The optional attribute "cascaded-focus" contains a conference URI This type defines an extendable sequence of the following optional
(different from the main conference URI) for users that are connected child elements.
to the main conference as a result of focus cascading. In accordance
with the SIP conferencing framework [14], this package allows for
representation of peer-to-peer (i.e. "flat") focus cascading only.
The actual cascading graph can not be deduced from the information
provided in the package alone. Advanced applications can construct
the graph by subscribing to both this package and the Dialog Package
[15] of the cascaded foci and correlating the relevant information.
If the main conference "state" is "full", the state of its user(s) 6.1.5.1 display-text of string type
MUST "full". If the main conference "state" is "partial", the state
of its user(s) MAY be either "partial" or "full".
4.1.1.2 User Status Elements This element contains the display text for the user.
Three optional status elements are defined: status, joining-mode, and 6.1.5.2 associated-aors of anyURI type
disconnection-reason.
o "status": provides information about user's current level of
participation in the conference.
o "joining-mode": if present, provides information about the way the
user joined the conference.
o "disconnection-reason": if present, provides information about the
way the user left the conference.
The following statuses are defined for the "status" element: This element contains associated URIs of the user. Usually this
connected: The user is a participant in the conference. Depending on information will be manually provided by a system administrator
the media policies, he/she can send and receive media to and from showing the logical association between signaling entities otherwise
other participants. independent.
disconnected: The user is not a participant in the conference and no
active dialog exists between the user and the focus.
on-hold: Active SIP dialog exists between a user and a focus, but
user is "on-hold" for this conference, i.e. neither he/she is
"hearing" the conference mix, nor is his/her media being mixed in
the conference. As an example, the user has asked to join the
conference using SIP, but his/her participation is pending based
on moderator approval. In the meantime he/she is hearing
music-on-hold or some other kind of related content.
muted-via-focus: Active SIP dialog exists between a user and a focus
and the user can "listen" to the conference, but user's media is
not being mixed into the conference. Note that sometimes a subset
of user media streams can be muted by focus (such as poor quality
video) while others (such as voice or IM) can still be active. In
this case, it is RECOMMENDED that the "aggregated" user
connectivity "status" reflects the status of the mostly active
media.
blocked: User is denied from ever participating in this conference.
pending: User is not yet in the session, but it is anticipated that
he/she will join in the near future.
calling: User is being called by the focus.
ringing: An PSTN ALERTING or SIP 180 Ringing was returned for the
outbound call, user is being alerted.
dialing-in: User is dialing into the conference, not yet in the
roster (probably being authenticated).
disconnecting: Focus is in the process of disconnecting user (either
DISCONNECT or BYE was sent to the user's device).
removed: This status is used to remove the user from the roster using
partial notifications mechanism.
Note that the defined transient states (e.g., calling, ringing, etc.) 6.1.5.3 roles of user-roles-type
could generate a lot of notifications. Implementations MAY choose
not to generate notifications on these to all participants if it will
generate too much traffic.
The following statuses are defined for the "joining-mode" element: This element contains the roles of the user.
dialed-in: The user dialed into the conference, i.e. sent INVITE to
the focus, which resulted in successful dialog establishment.
dialed-out: The focus has brought the user into the conference by
sending a successful INVITE to the user.
focus-owner: The user is the focus for this conference. This status
is used only when a participant UA acts as a conference focus.
The following statuses are defined for the disconnection-reason 6.1.5.4 language of language type
element:
departed: The user sent a BYE, thus leaving the conference.
booted: The user was sent a BYE by the focus, booting him/her out of
the conference. Alternatively, the user tried to dial into to
conference without success because was rejected by the focus
according to local policy decisions.
failed: The server tried to bring the user into the conference, but
its attempt to contact the specific user resulted in a non-200
class final response. Alternatively, the user tried to dial into
the conference without success due to technical reasons.
4.1.1.3 Media Information This element contains the language used by the user.
Each user has zero or more "media" sub-elements. 6.1.5.5 cascaded-focus of anyURI type
Each "media" element indicates the media that the user is currently This element contains a conference URI (different from the main
connected to. Here, "connected to" implies that a user has a media conference URI) for users that are connected to the main conference
line in his/her SDP [12] document(s). With this definition, a user as a result of focus cascading. In accordance with the SIP
is connected to a media stream even if he/she is not sending any conferencing framework [15], this package allows for representation
media. of peer-to-peer (i.e. "flat") focus cascading only. The actual
cascading graph can not be deduced from the information provided in
the package alone. Advanced applications can construct the graph by
subscribing to both this package and the Dialog Package [16] of the
cascaded foci and correlating the relevant information.
4.1.1.3.1 Media Attributes 6.1.5.6 endpoint of endpoint-type
The "media" element has a mandatory "media-type" attribute which This element contains information about an endpoint of the user. The
identifies the media type (e.g. audio, video, message and element of the endpoint-type can have unbounded number of appearance
application) and MUST have one of the values registered for "media" in the user-type for each endpoint of the user participating in the
of SDP [12]. conference. In a case when authentication is performed per endpoint
(rather than per user) in a system, a focus can be not aware of the
logical association among endpoints being used by the same user. In
this case the focus MAY present the endpoints as belonging to
separate users in the conference schema.
The optional "id" attribute serves as a unique reference to a "media" In a different case, due to privacy concerns for a user the focus may
element within the "user" element. It MUST be included for each want to shield the information about multiple endpoints from the
"media" element for all notifications if the focus uses "partial" recipients of the Conference document. To do so the focus MAY
user notifications for this conference. Otherwise, the "id" aggregate the multiple endpoint information into a single endpoint
attribute MAY be omitted. element under this user.
If the user "state" is "full", the state of its "media" element(s) 6.1.6 Endpoint Type
MUST be "full". If the user "state" is "partial", the state of its
"media" element(s) MAY be either "partial" or "full".
4.1.1.3.2 Media Elements This type has the following attributes:
The "media" element has also an optional "proto" sub-element, which entity: The mandatory attribute contains the endpoint URI for the
MUST has the value registered for "proto" of SDP [12]. user in the conference. In SIP terms, this is the Contact URI or
GRUU. The "entity" attribute MUST be unique in the endpoint
element list because it is used as the key in partial
notifications about users' endpoints. An anonymous participant in
a conference SHOULD be represented by an anonymous URI generated
by the focus. For multiple anonymous participants, the focus must
ensure that each anonymous URI is unique. The guidelines for
generating anonymous URIs in RFC 3323 [8] should be followed.
An optional "ssrc" sub-element, if present, carries the value of SSRC state: This mandatory attribute indicates whether the element
(defined in RTP/RTCP [10]) as generated by the user for the stream it contains the whole endpoint information ("full"), only the
sends. information that has changed since the previous document
("partial"), or the endpoint has been deleted from the conference
("deleted").
When an RTP mixer generates a CSRC list according to RTP/RTCP [10], This type defines an extendable sequence of the following optional
it inserts a list of the SSRC identifiers of the sources that child elements.
contributed to the generation of a particular packet into the RTP
header of that packet. "An example application is audio conferencing
where a mixer indicates all the talkers whose speech was combined to
produce the outgoing packet, allowing the receiver to indicate the
current talker, even though all the audio packets contain the same
SSRC identifier (that of the mixer)."
An optional "info" sub-element, if present, carries a human readable 6.1.6.1 display-text of string type
description for this stream populated by the focus. The value of
this element corresponds to the information media attribute "i" in
SDP [12].
An optional "label" sub-element, if present, carries a unique This element contains the display text for the endpoint.
identifier for this stream among all streams in the conference and is
assigned by the focus. The value of this element corresponds to the
"label" media attribute in SDP [12] and defined in [18].
An optional "instance" sub-element, if present, carries a URI, which 6.1.6.2 referred of execution-type
MUST uniquely identify the signaling dialog being used for
establishing of this media stream. In SIP, for example, values of
Contact URI or GRUU [17] can be used for this purpose. It is
RECOMMENDED to include the "instance" information for every user that
has more than a single dialog associated with the conference. This
element SHOULD NOT be included for an anonymous participant.
An optional "status" sub-element, if present, is used to remove This element contains the URI of the user who's action resulted in
"media" elements during partial notifications. this endpoint being brought into the conference (e.g. the user
identified by this URI sent a REFER to the focus).
Optional "snd-status" and "rcv-status" sub-elements, if present, 6.1.6.3 state of endpoint-state-type
describe the status of media streams in each direction.
4.1.1.4 User Role This element contains the state of the endpoint, and can assume the
following values:
The optional "role" element conveys the role of the user in the connected: The endpoint is a participant in the conference.
conference, e.g. participant, presenter, panelist, host, etc. Depending on the media policies, he/she can send and receive media
User's role MAY change dynamically in the course of the conference. to and from other participants.
Also, a user MAY have more than a single role in one time.
This document does not define fixed values for the "role" element, disconnected: The endpoint is not a participant in the conference and
instead it is expected that conferencing applications will define no active dialog exists between the endpoint and the focus.
custom-fit roles by templates.
4.1.2 Sidebar Element on-hold: Active SIP dialog exists between an endpoint and a focus,
but endpoint is "on-hold" for this conference, i.e. neither
he/she is "hearing" the conference mix, nor is his/her media being
mixed in the conference. As an example, the endpoint has asked to
join the conference using SIP, but his/her participation is
pending based on moderator approval. In the meantime he/she is
hearing music-on-hold or some other kind of related content.
The sidebar element is of the general "conference-type" and MAY use muted-via-focus: Active SIP dialog exists between an endpoint and a
all the attributes and elements defined by it. Typically, only the focus and the endpoint can "listen" to the conference, but
"entity", which uniquely identifies the sidebar, and the "user" endpoint's media is not being mixed into the conference. Note
elements will be useful to present to the majority of the that sometimes a subset of endpoint media streams can be muted by
participants in the conference. focus (such as poor quality video) while others (such as voice or
IM) can still be active. In this case, it is RECOMMENDED that the
"aggregated" endpoint connectivity "status" reflects the status of
the mostly active media.
The "conference-type" mandatory attributes MUST be included for each pending: Endpoint is not yet in the session, but it is anticipated
sidebar. that he/she will join in the near future.
The value of the "version" attribute is meaningless for "sidebar" alerting: A PSTN ALERTING or SIP 180 Ringing was returned for the
elements and MUST be ignored because it is always overruled by the outbound call, endpoint is being alerted.
"version" attribute of the main "conference-info".
If the main conference "state" is "full", the state of its sidebar(s) dialing-in: Endpoint is dialing into the conference, not yet in the
MUST be "full". If the main conference "state" is "partial", the roster (probably being authenticated).
state of its sidebar(s) MAY be either "full" or "partial".
The "entity" URI attribute MUST be unique among the sidebar dialing-out: Focus has dialed out to connect the endpoint to the
identifiers of the same conference. Attribute "entity" is used as conference, but the endpoint is not yet in the roster (probably
the key for "sidebar" elements in partial notifications for being authenticated).
"conference-info".
4.1.3 Additional Conference Identifiers disconnecting: Focus is in the process of disconnecting endpoint
(either DISCONNECT or BYE was sent to the endpoint's device).
In addition to the Conference URI present in the "entity" attribute, Note that the defined transient states (e.g., disconnecting,
a conference MAY have additional URIs of various types. Connecting alerting, etc.) could generate a lot of notifications.
to these URIs will result in joining to the same conference. Implementations MAY choose not to generate notifications on these to
all participants if it will generate too much traffic.
4.1.4 Policy URIs 6.1.6.4 joining-method of joining-type
A policy URI specifies where and how a certain policy pertaining to This element contains method by which the endpoint joined the
the conference can be accessed. The actual policy name and usage is conference, and can assume the following values:
deduced from the URI schema name.
An example for the "policy-uri" usage is inclusion of the URI of the dialed-in: The endpoint dialed into the conference, i.e. sent INVITE
CPCP [16]. A subscriber to the Conference package can use the Policy to the focus, which resulted in successful dialog establishment.
URI to access and modify the conference policy.
4.1.5 Recording dialed-out: The focus has brought the endpoint into the conference by
sending a successful INVITE to the endpoint.
In many cases, legal regulations require conference providers to focus-owner: The endpoint is the focus for this conference. This
announce to the participants that a specific conference is being status is used only when a participant UA acts as a conference
recorded. focus.
In addition to the recording "status" information, the "recording" 6.1.6.5 joining-info of execution-type
element MAY include the URIs specifying the location and the format
of the recorded data. Typically, the recorded data becomes available
after the conference ends. Multiple URIs can be provided, for
example, specifying different content types. For Web-Page embedded
media, a plain HTTP URI MAY be provided.
4.1.6 Streaming This element contains information about how the endpoint joined and
can contain the following sub-elements:
The "streaming" element, if present, specifies whether the conference when: This element contains the date and time that the endpoint
output is being streamed (to general public, for example), in what joined the conference.
streaming format, and at what (e.g. multicast) addresses it can be
listened at. RTSP [11] is an example of such streaming protocol.
4.2 Constructing Coherent State reason: This element contains the reason the endpoint joined the
conference.
The conference information is described by a hierarchal XML structure by: This element contains the URI of the entity who caused the
with the root element "conference-info". The root element is the endpoint to join the conference.
only element in the schema that carries meaningful version number for
all the elements in the document. The whole conference information
is associated with this version number.
The version number MUST be initialized with the value of the 6.1.6.6 disconnection-method of disconnection-type
"version" attribute from the "conference-info" element in the first
document received. Each time a new document is received, the value
of the local version number, and the "version" attribute in the new
document, are compared. If the value in the new document is one
higher than the local version number, the local version number is
increased by one, and the document is processed. If the value in the
document is more than one higher than the local version number, the
local version number is set to the value in the new document, the
document is processed, and the subscriber SHOULD generate a refresh
request to trigger a full state notification. If the value in the
document is less than the local version, the document is discarded
without processing.
Further processing of the conference information document depends on This element contains method by which the endpoint departed the
whether it contains full or partial state. If it contains full conference, and can assume the following values:
state, indicated by the value of the "state" attribute in the
"conference-info" element, the whole local content is flushed and
repopulated from the document.
If the document contains partial state, as indicated by the value of departed: The endpoint sent a BYE, thus leaving the conference.
the "state" attribute in the "conference-info" element, the document
is used to update the local content as described below.
All sub-elements in the "conference-info" hierarchal XML structure booted: The endpoint was sent a BYE by the focus, booting him/her out
can be classified in two groups: those that carry relatively small of the conference. Alternatively, the endpoint tried to dial into
amount of data and those that can potentially carry a lot of data. to conference without success because was rejected by the focus
During partial notifications, the light elements are updated as according to local policy decisions.
atomic pieces of data. On the other hand, elements that can carry a
substantial amount of data have the general "state" attribute
attached to them. That is in order to support partial notifications
for their content.
A "state" attribute of a child element in the document MUST adhere to failed: The server tried to bring the endpoint into the conference,
its parent "state". It means that if the parent's "state" is "full", but its attempt to contact the specific endpoint resulted in a
the state of its children MUST be "full". If the parent's "state" is non-200 class final response. Alternatively, the endpoint tried
"partial", the state of its children MAY be either "partial" or to dial into the conference without success due to technical
"full". reasons.
For elements with optional "state" attribute, if the attribute is not 6.1.6.7 disconnection-info of disconnection-type
included for an element, it means that the element's state is "full".
For a parent element with "state", its sub-elements with possible This element contains information about the endpoint's departure from
multiple appearances under the parent have keys that uniquely the conference and can contain the following sub-elements:
identify each element among others in the same list.
4.2.1 The Algorithm when: This element contains the date and time that the endpoint
departed the conference.
The conference package subscriber locally maintains a local element reason: This element contains the reason the endpoint departed the
for each element in the schema and a table for each "element with conference.
key(s)" in the schema. The tables are indexed by the key(s) defined
in schema for the element.
Starting from outer elements in the received document, by: This element contains the URI of the entity who caused the
endpoint to depart the conference.
1. If the parent element contains full state, the element is 6.1.6.8 whispering-to of uris-type
replaced with the new information as a whole.
2. Otherwise, if the parent element contains partial state, If an endpoint is participating in a whisper session with other
entities, the URIs of these other entities MAY be contained in this
element.
2.1 For elements with keys, the subscriber compares the keys received 6.1.6.9 media of media-type
in the update with the keys in the local tables.
2.1.1 If a key doesn't exist in the local table, a row is added, and This element contains information about a media stream of this
its content is set to the element information from the update. endpoint. The element of the media-type can have unbounded number of
appearance in the endpoint-type for each media stream of the
endpoint. Note that it is possible that media streams listed under a
common endpoint MAY be established by separate signaling means and
consequently belong to different signaling "calls".
2.1.2 Otherwise, if a key of the same value does exist, for each 6.1.7 Media Type
sub-element in the row the algorithm is applied from step 2.2.
2.2 For each atomic element received in the schema, the element is This type has the following attributes:
replaced with the new information as a whole. Also, for each
non-atomic element received in the schema with either no "state"
attribute included or the state attribute is set to "full", the
element is replaced with the new information as a whole.
2.2.1 If the updated or created element carries the "removed" status, entity: The mandatory attribute is a unique identifier of a media
that element SHOULD be removed from the local content. If the stream on a per endpoint basis. This attribute is used as a key
element is updated or created, such that it is empty, that element to identify media streams which may be added and deleted on a
MAY be removed from the local content at any time. dynamic basis during the conference. The value of this element
SHOULD correspond to the "mid" value in the SDP document as
defined in Grouping of Media Lines in the SDP [9].
2.3 For each non-atomic element with the state attribute set to state: This mandatory attribute indicates whether the element
"partial", the algorithm is applied recursively starting from step 2. contains the whole media information ("full"), only the
information that has changed since the previous document
("partial"), or the media element has been deleted from the
conference document ("deleted").
4.3 Schema This type defines an extendable sequence of the following optional
child elements.
6.1.7.1 display-text of string type
This element contains the display text for the media stream.
6.1.7.2 proto of string type
This element contains the media type for the media stream. The value
of this element MUST be a value registered for "proto" of SDP [12].
6.1.7.3 ssrc of string type
The "ssrc" element carries the value of SSRC (defined in RTP/RTCP
[10]) as generated by the endpoint for the stream it sends. When an
RTP mixer generates a CSRC list according to RTP/RTCP [10], it
inserts a list of the SSRC identifiers of the sources that
contributed to the generation of a particular packet into the RTP
header of that packet. "An example application is audio conferencing
where a mixer indicates all the talkers whose speech was combined to
produce the outgoing packet, allowing the receiver to indicate the
current talker, even though all the audio packets contain the same
SSRC identifier (that of the mixer)."
6.1.7.4 label of string type
The element "label" carries a unique identifier for this stream among
all streams in the conference and is assigned by the focus. The
value of this element corresponds to the "label" media attribute in
SDP [12] and defined in [19].
6.1.7.5 state of media-state-type
The element "state" contains the state of the media stream and can
have the values "active", "inactive", or "muted".
6.1.7.6 snd-status of media-state-type
The element "state" contains the state of the sending media stream
(from the perspective of the endpoint) and can have the values
"active", "inactive", or "muted".
6.1.7.7 rcv-status state of media-state-type
The element "state" contains the state of the receiving media stream
(from the perspective of the endpoint) and can have the values
"active", "inactive", or "muted".
6.1.7.8 call of call-type
The "call" element contains the "sip" sub-element which contains the
SIP dialog identifier of the endpoint's dialog with the focus. The
"sip" element includes sub-elements "display-text", "call-id",
"to-tag", "from-tag"
7. Schema
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-info" xmlns:tns="urn:ietf:params:xml:ns:conference-info" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:conference-info" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-info" xmlns:tns="urn:ietf:params:xml:ns:conference-info" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:conference-info" elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- <!--
This import brings in the XML language attribute xml:lang This import brings in the XML language attribute xml:lang
--> -->
<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd" /> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd" />
<xs:element name="conference-info" type="tns:conference-type"/> <!--
CONFERENCE ELEMENT
-->
<xs:element name="conference-info" type="conference-type"/>
<!--
CONFERENCE TYPE
-->
<xs:complexType name="conference-type">
<xs:sequence>
<xs:element name="conference-description" type="conference-description-type" minOccurs="0"/>
<xs:element name="host-info" type="host-type" minOccurs="0"/>
<xs:element name="conference-state" type="conference-state-type" minOccurs="0"/>
<xs:element name="user" type="user-type" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="sidebars-by-ref" type="uris-type" minOccurs="0"/>
<xs:element name="sidebar-by-val" type="conference-type" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI" use="required"/>
<xs:attribute name="state" type="state-type" use="optional"/>
<xs:attribute name="version" type="xs:string" use="optional"/>
<xs:anyAttribute/>
</xs:complexType>
<!--
STATE TYPE
-->
<xs:simpleType name="state-type"> <xs:simpleType name="state-type">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="full" /> <xs:enumeration value="full" />
<xs:enumeration value="partial" /> <xs:enumeration value="partial" />
<xs:enumeration value="deleted"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!--
<xs:complexType name="conference-type"> CONFERENCE DESCRIPTION TYPE
-->
<xs:complexType name="conference-description-type">
<xs:sequence> <xs:sequence>
<xs:element name="user" type="user-type" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="display-text" type="xs:string" minOccurs="0"/>
<xs:element name="sidebar" type="conference-type" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="subject" type="xs:string" minOccurs="0"/>
<xs:element name="conf-ids" type="conf-ids-type" minOccurs="0" maxOccurs="1" /> <xs:element name="free-text" type="xs:string" minOccurs="0"/>
<xs:element name="policy-ids" type="policy-ids-type" minOccurs="0" maxOccurs="1" /> <xs:element name="keywords" type="keywords-type" minOccurs="0"/>
<xs:element name="recording" type="recording-type" minOccurs="0" maxOccurs="1" /> <xs:element name="web-page" type="xs:anyURI" minOccurs="0"/>
<xs:element name="streaming" type="streaming-type" minOccurs="0" maxOccurs="1" /> <xs:element name="conf-uris" type="uris-type" minOccurs="0"/>
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="service-uris" type="uris-type" minOccurs="0"/>
<xs:element name="maximum-user-count" type="user-count-type" minOccurs="0"/>
<xs:element name="available-media" type="conference-medias-type" minOccurs="0"/>
<xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="state" type="state-type" use="optional"/>
<xs:attribute name="version" type="xs:nonNegativeInteger" use="required"/>
<xs:attribute name="state" type="tns:state-type" use="required"/>
<xs:attribute name="entity" type="xs:anyURI" use="required"/>
<xs:anyAttribute /> <xs:anyAttribute />
</xs:complexType> </xs:complexType>
<!--
<xs:complexType name="conf-ids-type"> HOST TYPE
-->
<xs:complexType name="host-type">
<xs:sequence> <xs:sequence>
<xs:element name="conf-uri" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="display-text" type="xs:string" minOccurs="0"/>
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="web-page" type="xs:anyURI" minOccurs="0"/>
<xs:element name="uris" type="uris-type" minOccurs="0"/>
<xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="state" type="state-type" use="optional"/>
<xs:anyAttribute /> <xs:anyAttribute />
</xs:complexType> </xs:complexType>
<!--
<xs:complexType name="policy-ids-type"> CONFERENCE STATE TYPE -->
<xs:complexType name="conference-state-type">
<xs:sequence> <xs:sequence>
<xs:element name="policy-uri" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="user-count" type="user-count-type" minOccurs="0"/>
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="security-level" type="security-level-type" minOccurs="0"/>
<xs:element name="active" type="xs:boolean" minOccurs="0"/>
<xs:element name="locked" type="xs:boolean" minOccurs="0"/>
<xs:element name="recording" type="uris-type" minOccurs="0"/>
<xs:element name="active-media" type="conference-medias-type" minOccurs="0"/>
<xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="state" type="state-type" use="optional"/>
<xs:anyAttribute /> <xs:anyAttribute />
</xs:complexType> </xs:complexType>
<!--
<xs:complexType name="recording-type"> CONFERENCE MEDIAS TYPE
-->
<xs:complexType name="conference-medias-type">
<xs:sequence> <xs:sequence>
<xs:element name="uri" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="entry" type="conference-media-type" maxOccurs="unbounded"/>
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence> </xs:sequence>
<xs:attribute name="state" type="state-type" use="optional"/>
<xs:attribute name="status" type=="stream-status-type" use="required"/>
<xs:anyAttribute /> <xs:anyAttribute />
</xs:complexType> </xs:complexType>
<!--
<xs:complexType name="streaming-type"> CONFERENCE MEDIA TYPE
-->
<xs:complexType name="conference-media-type">
<xs:sequence> <xs:sequence>
<xs:element name="uri" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="proto" type="xs:string"/>
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="status" type="stream-status-type" use="required"/>
<xs:anyAttribute /> <xs:anyAttribute />
</xs:complexType> </xs:complexType>
<!--
CONFERENCE URIs TYPE
-->
<xs:complexType name="uris-type">
<xs:sequence>
<xs:element name="entry" type="uri-type" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="state" type="state-type" use="optional"/>
<xs:anyAttribute/>
</xs:complexType>
<!--
CONFERENCE URI TYPE
-->
<xs:complexType name="uri-type">
<xs:sequence>
<xs:element name="uri" type="xs:anyURI"/>
<xs:element name="label" type="xs:string" minOccurs="0"/>
<xs:element name="modified" type="execution-type" minOccurs="0"/>
<xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<!--
USER COUNT TYPE
-->
<xs:complexType name="user-count-type">
<xs:sequence>
<xs:element name="entry" type="count-type" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="state" type="state-type" use="optional"/>
<xs:anyAttribute/>
</xs:complexType>
<!--
COUNT TYPE
-->
<xs:complexType name="count-type">
<xs:sequence>
<xs:element name="role" type="user-role-type"/>
<xs:element name="count" type="xs:nonNegativeInteger"/>
<xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<!--
SECURITY LEVEL TYPE
-->
<xs:simpleType name="security-level-type">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="low"/>
<xs:enumeration value="medium"/>
<xs:enumeration value="high"/>
</xs:restriction>
</xs:simpleType>
<!--
KEWORDS TYPE
-->
<xs:simpleType name="keywords-type">
<xs:list itemType="xs:string"/>
</xs:simpleType>
<!--
USER TYPE
-->
<xs:complexType name="user-type"> <xs:complexType name="user-type">
<xs:sequence> <xs:sequence>
<xs:element name="status" type="tns:user-status-type" minOccurs="0"/> <xs:element name="display-text" type="xs:string" minOccurs="0"/>
<xs:element name="joining-mode" type="tns:user-joining-mode-type" minOccurs="0"/> <xs:element name="associated-aors" type="uris-type" minOccurs="0"/>
<xs:element name="disconnection-reason" type="tns:user-disconnection-reason-type" minOccurs="0"/> <xs:element name="roles" type="user-roles-type" minOccurs="0"/>
<xs:element name="media" type="tns:media-type" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="language" type="xs:language" minOccurs="0"/>
<xs:element name="role" type="xs:string" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="cascaded-focus" type="xs:anyURI" minOccurs="0"/>
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="endpoint" type="endpoint-type" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="entity" type="xs:anyURI"/>
<xs:attribute name="uri" type="xs:anyURI" use="required"/> <xs:attribute name="state" type="state-type" use="optional"/>
<xs:attribute name="display-name" type="xs:string" use="optional"/>
<xs:attribute ref="xml:lang" use="optional"/>
<xs:attribute name="cascaded-focus" type="xs:anyURI" use="optional"/>
<xs:attribute name="state" type="tns:state-type" use="optional"/>
<xs:anyAttribute /> <xs:anyAttribute />
</xs:complexType> </xs:complexType>
<!--
USER ROLES TYPE
-->
<xs:complexType name="user-roles-type">
<xs:sequence>
<xs:element name="entry" type="user-role-type" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="state" type="state-type" use="optional"/>
<xs:anyAttribute/>
</xs:complexType>
<!--
USER ROLE TYPE
-->
<xs:complexType name="user-role-type">
<xs:choice>
<xs:element name="label" type="xs:string"/>
</xs:choice>
<xs:attribute name="conf-template" type="xs:string" use="optional"/>
</xs:complexType>
<!--
ENDPOINT TYPE
-->
<xs:complexType name="endpoint-type">
<xs:sequence>
<xs:element name="display-text" type="xs:string" minOccurs="0"/>
<xs:element name="referred" type="execution-type" minOccurs="0"/>
<xs:element name="state" type="endpoint-state-type" minOccurs="0"/>
<xs:element name="whispering-to" type="uris-type" minOccurs="0"/>
<xs:element name="joining-method" type="joining-type" minOccurs="0"/>
<xs:element name="joining-info" type="execution-type" minOccurs="0"/>
<xs:element name="disconnection-method" type="disconnection-type" minOccurs="0"/>
<xs:element name="disconnection-info" type="execution-type" minOccurs="0"/>
<xs:simpleType name="user-status-type"> <xs:element name="media" type="media-type" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI"/>
<xs:attribute name="state" type="state-type" use="optional"/>
<xs:anyAttribute/>
</xs:complexType>
<!--
ENDPOINT STATE TYPE
-->
<xs:simpleType name="endpoint-state-type">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="connected"/>
<xs:enumeration value="disconnected"/>
<xs:enumeration value="on-hold"/>
<xs:enumeration value="muted-via-focus"/>
<xs:enumeration value="blocked"/>
<xs:enumeration value="pending"/> <xs:enumeration value="pending"/>
<xs:enumeration value="calling"/> <xs:enumeration value="dialing-out"/>
<xs:enumeration value="ringing"/>
<xs:enumeration value="dialing-in"/> <xs:enumeration value="dialing-in"/>
<xs:enumeration value="alerting"/>
<xs:enumeration value="on-hold"/>
<xs:enumeration value="connected"/>
<xs:enumeration value="muted-via-focus"/>
<xs:enumeration value="disconnecting"/> <xs:enumeration value="disconnecting"/>
<xs:enumeration value="removed"/> <xs:enumeration value="disconnected"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!--
<xs:simpleType name="user-joining-mode-type"> JOINING TYPE
-->
<xs:simpleType name="joining-type">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="dialed-in" /> <xs:enumeration value="dialed-in" />
<xs:enumeration value="dialed-out" /> <xs:enumeration value="dialed-out" />
<xs:enumeration value="focus-owner" /> <xs:enumeration value="focus-owner" />
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!--
<xs:simpleType name="user-disconnection-reason-type"> DISCONNECTION TYPE
-->
<xs:simpleType name="disconnection-type">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="departed" /> <xs:enumeration value="departed" />
<xs:enumeration value="booted" /> <xs:enumeration value="booted" />
<xs:enumeration value="failed" /> <xs:enumeration value="failed" />
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!--
EXECUTION TYPE
-->
<xs:complexType name="execution-type">
<xs:sequence>
<xs:element name="when" type="xs:dateTime" minOccurs="0"/>
<xs:element name="reason" type="xs:string" minOccurs="0"/>
<xs:element name="by" type="xs:anyURI" minOccurs="0"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<!--
MEDIA TYPE
-->
<xs:complexType name="media-type"> <xs:complexType name="media-type">
<xs:sequence> <xs:sequence>
<xs:element name="display-text" type="xs:string" minOccurs="0"/>
<xs:element name="proto" type="xs:string" minOccurs="0"/> <xs:element name="proto" type="xs:string" minOccurs="0"/>
<xs:element name="ssrc" type="xs:nonNegativeInteger" minOccurs="0"/> <xs:element name="ssrc" type="xs:string" minOccurs="0"/>
<xs:element name="info" type="xs:string" minOccurs="0"/>
<xs:element name="label" type="xs:string" minOccurs="0"/> <xs:element name="label" type="xs:string" minOccurs="0"/>
<xs:element name="instance" type="xs:anyURI" minOccurs="0"/> <xs:element name="state" type="media-state-type" minOccurs="0"/>
<xs:element name="status" type="tns:media-status-type" minOccurs="0"/> <xs:element name="snd-status" type="media-state-type" minOccurs="0"/>
<xs:element name="snd-status" type="tns:stream-status-type" minOccurs="0"/> <xs:element name="rcv-status" type="media-state-type" minOccurs="0"/>
<xs:element name="rcv-status" type="tns:stream-status-type" minOccurs="0"/> <xs:element name="call" type="call-type" minOccurs="0"/>
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="entity" type="xs:string" use="required"/>
<xs:attribute name="media" type="xs:string" use="required"/> <xs:attribute name="state" type="state-type" use="optional"/>
<xs:attribute name="id" type="nonNegativeInteger" use="optional"/>
<xs:attribute name="state" type="tns:state-type" use="optional"/>
<xs:anyAttribute /> <xs:anyAttribute />
</xs:complexType> </xs:complexType>
<!--
<xs:simpleType name="media-status-type"> MEDIA STATUS TYPE
<xs:restriction base="xs:string"> -->
<xs:enumeration value="removed" /> <xs:simpleType name="media-state-type">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="stream-status-type">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="on"/> <xs:enumeration value="active"/>
<xs:enumeration value="off"/> <xs:enumeration value="inactive"/>
<xs:enumeration value="muted" /> <xs:enumeration value="muted" />
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!--
CALL TYPE
-->
<xs:complexType name="call-type">
<xs:choice>
<xs:element name="sip" type="sip-dialog-id-type"/>
<xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:anyAttribute/>
</xs:complexType>
<!--
SIP DIALOG ID TYPE
-->
<xs:complexType name="sip-dialog-id-type">
<xs:sequence>
<xs:element name="display-text" type="xs:string" minOccurs="0"/>
<xs:element name="dialog-id" type="xs:string"/>
<xs:element name="from-tag" type="xs:string"/>
<xs:element name="to-tag" type="xs:string"/>
<xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<!--
EXTENDED TYPE
-->
<xs:complexType name="extended-type">
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="target-namespace" type="xs:string" use="required"/>
</xs:complexType>
</xs:schema> </xs:schema>
4.4 Example 8. Examples
8.1 Basic Example
The following is an example conference information document: The following is an example conference information document:
<?xml version="1.0" encoding="utf-8" ?> <conference-info entity="sips:conf233@example.com" state="partial" version="5" >
<conference-info version="0" state="full" entity="sip:conf233@example.com"> <!--
<user uri="sip:bob@example.com" display-name="Bob Jones"> CONFERENCE INFO
<status>connected</status> -->
<joining-mode>dialed-in</joining-mode> <conference-description>
<media media="audio"> <subject>Agenda: This month's target</subject>
<proto>RTP/AVP</proto> <service-uris>
<ssrc>583398</ssrc> <entry>
<uri>http://salesgroup.example.com/conference-policies/sales-weekly-meeting.xml</uri>
<label>CPCP</label>
</entry>
</service-uris>
</conference-description>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>
<entry>
<role>
<label>any</label>
</role>
<count>33</count>
</entry>
</user-count>
<active-media>
<entry>
<proto>audio</proto>
</entry>
</active-media>
</conference-state>
<!--
USER
-->
<user entity="sip:bob@example.com" state="full">
<display-text>Bob Hoskins</display-text>
<!--
ENDPOINTS
-->
<endpoint entity="sip:bob@pc33.example.com">
<display-text>Bob's Laptop</display-text>
<state>disconnected</state>
<disconnection-method>departed</disconnection-method>
<disconnection-info>
<when>2005-03-04T20:00:00Z</when>
<reason>bad voice quality</reason>
<by>sip:mike@example.com</by>
</disconnection-info>
<!--
MEDIA
-->
<media entity="1">
<display-text>main audio</display-text>
<proto>audio</proto>
<ssrc>432424</ssrc>
<label>34567</label>
<state>active</state>
</media> </media>
</endpoint>
</user> </user>
<user uri="sip:barbara@example.com" display-name="Barbara Jones">
<status>on-hold</status> <!--
</user> USER
<user uri="sip:bill@example.com" display-name="Bill Minelli"> -->
<status>on-hold</status> <user entity="sip:alice@example.net" state="full">
<display-text>Alice</display-text>
<!--
ENDPOINTS
-->
<endpoint entity="sip:4kfk4j392jsu@example.net;grid=433kj4j3u">
<state>connected</state>
<joining-method>dialed-out</joining-method>
<joining-info>
<when>2005-03-04T20:00:00Z</when>
<by>sip:mike@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media entity="1">
<display-text>main audio</display-text>
<proto>audio</proto>
<ssrc>534232</ssrc>
<label>34564</label>
<state>active</state>
</media>
</endpoint>
</user> </user>
</conference-info>
<sidebar version="0" state="full" entity="sip:conf233.1@example.com"> 8.2 Rich Example
<user uri="sip:barbara@example.com" />
<user uri="sip:bill@example.com" />
</sidebar>
<conf-ids> The following is an example conference information document. In this
<conf-uri>tel:+18005671234</conf-uri> example of a partial state notification, there are 32 participants in
<conf-uri>h323:conf545@example.com</conf-uri> a voice conference. The user Bob has been booted from the conference
</conf-ids> by Mike due to bad voice quality. Note that there are three sidebars
in the conference, two are referenced just by their sidebar URI and
information about the third sidebar is included in this notification.
Also note that while this conference offers both audio and video
capabilities, only audio is currently in use.
<recording status="on"> <conference-info entity="sips:conf233@example.com" state="partial" version="5" >
<!--
CONFERENCE INFO
-->
<conference-description>
<display-text>Weekly Sales Meeting</display-text>
<subject>Agenda: This month's target</subject>
<free-text>xyz</free-text>
<keywords>sales, meeting, weekly</keywords>
<web-page>http://sharepoint/salesgroup/</web-page>
<conf-uris>
<entry>
<uri>tel:+18005671234</uri>
<label>TTI Bridge</label>
</entry>
<entry>
<uri>h323:conf545@h323.example.com</uri>
</entry>
</conf-uris>
<service-uris>
<entry>
<uri>http://salesgroup.example.com/conference-policies/sales-weekly-meeting.xml</uri>
<label>CPCP</label>
</entry>
</service-uris>
<maximum-user-count>
<entry>
<role>
<label>any</label>
</role>
<count>52</count>
</entry>
<entry>
<role conf-template="Basic">
<label>participant</label>
</role>
<count>50</count>
</entry>
</maximum-user-count>
<available-media>
<entry>
<proto>audio</proto>
</entry>
<entry>
<proto>video</proto>
</entry>
</available-media>
</conference-description>
<!--
HOST INFO
-->
<host-info>
<display-text>Sales Host</display-text>
<web-page>http://sharepoint/salesgroup/hosts/</web-page>
<uris>
<entry>
<uri>sip:sales@example.com</uri>
</entry>
</uris>
</host-info>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>
<entry>
<role>
<label>any</label>
</role>
<count>33</count>
</entry>
<entry>
<role conf-template="Basic">
<label>participant</label>
</role>
<count>32</count>
</entry>
</user-count>
<security-level>medium</security-level>
<active>true</active>
<locked>false</locked>
<recording>
<entry>
<uri>http://quicktime.streaming.com/54634/recording.mov</uri> <uri>http://quicktime.streaming.com/54634/recording.mov</uri>
<label>Quicktime</label>
</entry>
<entry>
<uri>http://real.streaming.com/54634/recording.ram</uri> <uri>http://real.streaming.com/54634/recording.ram</uri>
<uri>http://windowsmedia.streaming.com/54634/recording.wmv</uri> </entry>
<uri>http://www.streaming.com/54634/recording.html</uri>
</recording> </recording>
<active-media>
<entry>
<proto>audio</proto>
</entry>
</active-media>
</conference-state>
</conference-info> <!--
USERS
-->
<user entity="sip:bob@example.com" state="full">
<display-text>Bob Hoskins</display-text>
<associated-aors>
<entry>
<uri>mailto:bob@example.com</uri>
<label>email</label>
</entry>
</associated-aors>
<roles>
<entry>
<label>participant</label>
</entry>
</roles>
<language>en</language>
<!--
ENDPOINTS
-->
<endpoint entity="sip:bob@pc33.example.com">
<display-text>Bob's Laptop</display-text>
<referred>
<when>2005-03-04T20:00:00Z</when>
<by>sip:mike@example.com</by>
</referred>
<state>disconnecting</state>
<whispering-to>
<entry>
<uri>sip:rob@example.com</uri>
</entry>
<entry>
<uri>sip:helen@example.com</uri>
</entry>
</whispering-to>
<joining-method>dialed-out</joining-method>
<joining-info>
<when>2005-03-04T20:00:00Z</when>
<reason>invitation</reason>
<by>sip:mike@example.com</by>
</joining-info>
<disconnection-method>booted</disconnection-method>
<disconnection-info>
<when>2005-03-04T20:00:00Z</when>
<reason>bad voice quality</reason>
<by>sip:mike@example.com</by>
</disconnection-info>
This conference currently has three users, two of which are in a <!--
sidebar conversation. The conference is being recorded. There are MEDIA
additional means to join the conference either by phone using tel URI -->
[14] or by H.323 protocol using H.323 URL [13]. <media entity="1" state="full">
<display-text>main audio</display-text>
<proto>audio</proto>
<ssrc>432424</ssrc>
<label>34567</label>
<state>active</state>
<call>
<sip>
<display-text>full info</display-text>
<dialog-id>hsjh8980vhsb78</dialog-id>
<from-tag>vav738dvbs</from-tag>
5. Security Considerations <to-tag>8954jgjg8432</to-tag>
</sip>
</call>
</media>
</endpoint>
</user>
<!--
SIDEBARS BY REFERENCE
-->
<sidebars-by-ref>
<entry>
<uri>sips:conf233@example.com; grid=45</uri>
<label>sidebar with Carol</label>
</entry>
<entry>
<uri>sips:conf233@example.com; grid=21</uri>
<label>private sidebar with Peter</label>
</entry>
</sidebars-by-ref>
<!--
SIDEBARS BY VALUE
-->
<sidebar-by-val entity="sips:conf233@example.com; grid=77" state="partial">
<user entity="sip:bob@example.com" state="partial"></user>
<user entity="sip:mark@example.com" state="partial"></user>
<user entity="sip:dan@example.com" state="partial"></user>
</sidebar-by-val>
</conference-info>
9. Security Considerations
Subscriptions to conference state can reveal very sensitive Subscriptions to conference state can reveal very sensitive
information. For this reason, the document recommends authentication information. For this reason, the document recommends authentication
and authorization, and provides guidelines on sensible authorization and authorization, and provides guidelines on sensible authorization
policies. policies.
Since the data in notifications is sensitive as well, end-to-end SIP Since the data in notifications is sensitive as well, end-to-end SIP
encryption mechanisms using S/MIME SHOULD be used to protect it. encryption mechanisms using S/MIME SHOULD be used to protect it.
Since a focus provides participants identity information using this Since a focus provides participants identity information using this
skipping to change at page 24, line 5 skipping to change at page 41, line 5
focus MUST support requests by participants for privacy. Privacy can focus MUST support requests by participants for privacy. Privacy can
be indicated by the conference policy - for every participant or be indicated by the conference policy - for every participant or
select participants. It can also be indicated in the session select participants. It can also be indicated in the session
signaling. In SIP this can be done using the Privacy header field signaling. In SIP this can be done using the Privacy header field
described in RFC 3323 [8]. For a participant requesting privacy, no described in RFC 3323 [8]. For a participant requesting privacy, no
identity information SHOULD be revealed by the focus such as a URI identity information SHOULD be revealed by the focus such as a URI
(e.g. the Address of Record, Contact, or GRUU). For these cases, (e.g. the Address of Record, Contact, or GRUU). For these cases,
the anonymous URI generation method outlined in section "User the anonymous URI generation method outlined in section "User
Element" of this document MUST be followed. Element" of this document MUST be followed.
6. IANA Considerations 10. IANA Considerations
This document registers a SIP event package, a new MIME type, This document registers a SIP event package, a new MIME type,
application/conference-info+xml, a new XML namespace, and a new XML application/conference-info+xml, a new XML namespace, and a new XML
schema. schema.
6.1 conference Event Package Registration 10.1 conference Event Package Registration
This specification registers an event package, based on the This specification registers an event package, based on the
registration procedures defined in RFC 3265 [7]. The following is registration procedures defined in RFC 3265 [7]. The following is
the information required for such a registration: the information required for such a registration:
Package Name: conference Package Name: conference
Package or Template-Package: This is a package. Package or Template-Package: This is a package.
Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX
with the RFC number of this specification). with the RFC number of this specification).
Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net. Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.
6.2 application/conference-info+xml MIME Registration 10.2 application/conference-info+xml MIME Registration
MIME media type name: application MIME media type name: application
MIME subtype name: conference-info+xml MIME subtype name: conference-info+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [5]. specified in RFC 3023 [5].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [5]. application/xml as specified in RFC 3023 [5].
Security considerations: See Section 10 of RFC 3023 [5] and Section 5 Security considerations: See Section 10 of RFC 3023 [5] and Section 9
of this specification. of this specification.
Interoperability considerations: none. Interoperability considerations: none.
Published specification: This document. Published specification: This document.
Applications which use this media type: This document type has been Applications which use this media type: This document type has been
used to support SIP conferencing applications. used to support SIP conferencing applications.
Additional Information: Additional Information:
Magic Number: None Magic Number: None
File Extension: .cif or .xml File Extension: .cif or .xml
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Jonathan Personal and email address for further information: Jonathan
Rosenberg, <jdrosen@jdrosen.net> Rosenberg, <jdrosen@jdrosen.net>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
6.3 URN Sub-Namespace Registration for 10.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:conference-info urn:ietf:params:xml:ns:conference-info
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
[1]. [1].
URI: The URI for this namespace is URI: The URI for this namespace is
urn:ietf:params:xml:ns:conference-info. urn:ietf:params:xml:ns:conference-info.
Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>, Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>,
Jonathan Rosenberg <jdrosen@jdrosen.net>. Jonathan Rosenberg <jdrosen@jdrosen.net>.
XML: XML:
skipping to change at page 25, line 29 skipping to change at page 42, line 29
<title>Conference Information Namespace</title> <title>Conference Information Namespace</title>
</head </head
<body> <body>
<h1>Namespace for Conference Information</h1> <h1>Namespace for Conference Information</h1>
<h2>urn:ietf:params:xml:ns:conference-info</h2> <h2>urn:ietf:params:xml:ns:conference-info</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
6.4 XML Schema Registration 10.4 XML Schema Registration
This specification registers a schema, as per the guidelines in in This specification registers a schema, as per the guidelines in in
[1]. [1].
URI: please assign. URI: please assign.
Registrant Contact: IETF, SIPPING Working Group Registrant Contact: IETF, SIPPING Working Group
(sipping@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). (sipping@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
XML: The XML can be found as the sole content of Section 4.3. XML: The XML can be found as the sole content of Section 7.
7. Acknowledgements 11. Acknowledgements
The authors would like to thank Dan Petrie, Sean Olson, Alan The authors would like to thank Dan Petrie, Sean Olson, Alan
Johnston, and Rohan Mahy for their comments and inputs. Johnston, and Rohan Mahy for their comments and inputs.
8. Changes History 12. Changes History
8.1 Changes since -04 12.1 Changes since -05
o General schema clean-up.
o Definition of common types being used by multiple elements.
o Introduction of an "endpoint" element as a part of hierarchy:
user/endpoint/media.
12.2 Changes since -04
o o
o "Sidebar-type" has been removed. "Sidebar" conference element is o "Sidebar-type" has been removed. "Sidebar" conference element is
defined using the general "conference-type". defined using the general "conference-type".
o "Recording" conference attribute has been replaced with o "Recording" conference attribute has been replaced with
"recording" and "streaming" elements within "conference-type". "recording" and "streaming" elements within "conference-type".
New "recording-type" and "streaming-type" have been introduced. New "recording-type" and "streaming-type" have been introduced.
o Attribute "state" has been added to "user-type". o Attribute "state" has been added to "user-type".
o Element "media-stream" within "user-type" has been renamed to o Element "media-stream" within "user-type" has been renamed to
"media". "media".
o Element "role" within "user-type" has been introduced. o Element "role" within "user-type" has been introduced.
skipping to change at page 27, line 30 skipping to change at page 44, line 36
removed. removed.
o User status "muted-by-focus" has been renamed to o User status "muted-by-focus" has been renamed to
"muted-via-focus". "muted-via-focus".
o Attributes "id" and "state" have been added to "media-type". o Attributes "id" and "state" have been added to "media-type".
o Elements "status", "snd-status" and "rcv-status" have been added o Elements "status", "snd-status" and "rcv-status" have been added
to "media-type". to "media-type".
o Element "dialog-id" has been renamed to "instance". o Element "dialog-id" has been renamed to "instance".
o "Constructing Coherent State" section has been updated to include o "Constructing Coherent State" section has been updated to include
user and media partial notifications. user and media partial notifications.
8.2 Changes since -03 12.3 Changes since -03
o "Constructing Coherent State" section has been updated. o "Constructing Coherent State" section has been updated.
o In order to support partial notifications, two placeholders o In order to support partial notifications, two placeholders
"conference-ids" and "policy-ids" (for "conf-uri" and "policy-uri" "conference-ids" and "policy-ids" (for "conf-uri" and "policy-uri"
elements, correspondingly) are created. elements, correspondingly) are created.
o Discussion and security considerations regarding anonymous o Discussion and security considerations regarding anonymous
participation have been added. participation have been added.
o Optional elements "dialog-uri", "info" and "label" per media o Optional elements "dialog-uri", "info" and "label" per media
stream are added. stream are added.
8.3 Changes since -02 12.4 Changes since -02
o State "muted-by-focus" is added to user's status. o State "muted-by-focus" is added to user's status.
o Optional conference attribute "recording" is added. o Optional conference attribute "recording" is added.
o Policy URI placeholder (i.e. element "policy-uri") is created. o Policy URI placeholder (i.e. element "policy-uri") is created.
o Example's syntax is corrected. o Example's syntax is corrected.
o Optional attribute "cascaded-focus" URI per user is added. o Optional attribute "cascaded-focus" URI per user is added.
o Optional additional conference identifiers (i.e. element o Optional additional conference identifiers (i.e. element
"conf-uri") are added. "conf-uri") are added.
o In order to cover all possible cases, participant's status is o In order to cover all possible cases, participant's status is
expressed using three optional statuses: "status", "joining-mode" expressed using three optional statuses: "status", "joining-mode"
and "disconnection-reason". That is instead of "activity-status", and "disconnection-reason". That is instead of "activity-status",
"history-status" and "is-on-dial-out-list". "history-status" and "is-on-dial-out-list".
8.4 Changes since -01 12.5 Changes since -01
o Package parameters are removed. Decision about performing o Package parameters are removed. Decision about performing
"recursive" membership algorithm is perceived as a focus local "recursive" membership algorithm is perceived as a focus local
policy. policy.
o General information (i.e. pointers to additional available o General information (i.e. pointers to additional available
services) is removed. The defined XML schema can be extended in services) is removed. The defined XML schema can be extended in
future to include those when XCON work matures. future to include those when XCON work matures.
o Dialog information is removed. It can be obtained by direct o Dialog information is removed. It can be obtained by direct
subscription to a dialog package of a participant. subscription to a dialog package of a participant.
o Media stream information is aligned with SDP definitions (media o Media stream information is aligned with SDP definitions (media
and proto) and SSRC attribute is added. and proto) and SSRC attribute is added.
o Participant's status is expressed using two optional statuses: o Participant's status is expressed using two optional statuses:
"activity" and "history". Optional "is-on-a-dial-out-list" "activity" and "history". Optional "is-on-a-dial-out-list"
indication is added. indication is added.
o Normative references to XCON work are removed. o Normative references to XCON work are removed.
o Optional sidebar rosters are added. o Optional sidebar rosters are added.
9. References 13. References
9.1 Normative References 13.1 Normative References
[1] Mealling, M., "The IETF XML Registry", [1] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-05 (work in progress), June draft-mealling-iana-xmlns-registry-05 (work in progress), June
2003. 2003.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Moats, R., "URN Syntax", RFC 2141, May 1997. [3] Moats, R., "URN Syntax", RFC 2141, May 1997.
skipping to change at page 29, line 42 skipping to change at page 46, line 42
Protocol (SIP)", RFC 3323, November 2002. Protocol (SIP)", RFC 3323, November 2002.
[9] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne, [9] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol "Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002. (SDP)", RFC 3388, December 2002.
[10] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, [10] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
9.2 Informative References 13.2 Informative References
[11] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming [11] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998. Protocol (RTSP)", RFC 2326, April 1998.
[12] Handley, M. and V. Jacobson, "SDP: Session Description [12] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[13] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme [13] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
2000.
[14] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme
Registration", RFC 3508, April 2003. Registration", RFC 3508, April 2003.
[14] Rosenberg, J., "A Framework for Conferencing with the Session [15] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Initiation Protocol",
draft-ietf-sipping-conferencing-framework-02 (work in draft-ietf-sipping-conferencing-framework-03 (work in
progress), June 2004. progress), October 2004.
[15] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog [16] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog
Event Package for the Session Initiation Protocol (SIP)", Event Package for the Session Initiation Protocol (SIP)",
draft-ietf-sipping-dialog-package-04 (work in progress), draft-ietf-sipping-dialog-package-04 (work in progress),
February 2004. February 2004.
[16] Koskelainen, P. and H. Khartabil, "Requirements for Conference [17] Koskelainen, P. and H. Khartabil, "Requirements for Conference
Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-03 (work in Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in
progress), April 2004. progress), August 2004.
[17] Rosenberg, J., "Obtaining and Using Globally Routable User [18] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004. (SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004.
[18] Levin, O. and G. Camarillo, "The SDP (Session Description [19] Levin, O. and G. Camarillo, "The SDP (Session Description
Protocol) Label Attribute", Protocol) Label Attribute",
draft-levin-mmusic-sdp-media-label-00 (work in progress), July draft-ietf-mmusic-sdp-media-label-00 (work in progress),
2004. September 2004.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/