RFC 4575
A Session Initiation Protocol (SIP) Event Package for Conference State
RFC 4575: A Session Initiation Protocol (SIP) Event Package for Conference State 🎀
okay bestie, this one is from August 2006 📅 and it's a Standards Track doc, so it's an actual Internet standard in the making 🔥. It was written by J. Rosenberg (Cisco Systems), H. Schulzrinne (Columbia University), and O. Levin, Ed. (Microsoft Corporation) 👑. It belongs to the Network Working Group. The title block doesn't list any Obsoletes or Updates line, so this doc isn't replacing or changing anything else ✨.
Status of This Memo 📜
this is an Internet standards track protocol for the Internet community, and the authors are asking for discussion and suggestions for improvements 💬. if you want the current standardization state and status, check the current edition of "Internet Official Protocol Standards" (STD 1) 🔍. distribution of this memo is unlimited 🌈.
Copyright Notice ⚖️
Copyright (C) The Internet Society (2006) 🫶.
Abstract 💜
this doc defines a conference event package for tightly coupled conferences 🎀. it uses the SIP events framework and comes with a data format for the notifications sent for this package 📦. the big idea is that users can subscribe to a conference Uniform Resource Identifier (URI) 🔗. notifications go out about changes in the membership of the conference, and optionally about changes in the state of other conference components 🦋.
Table of Contents 📚
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Conference Event Package ........................................4
3.1. Event Package Name .........................................5
3.2. Filtering ..................................................5
3.3. Subscription Duration ......................................5
3.4. NOTIFY Bodies ..............................................5
3.5. Notifier Processing of SUBSCRIBE Requests ..................6
3.6. Notifier Generation of NOTIFY Requests .....................6
3.7. Subscriber Processing of NOTIFY Requests ...................6
3.8. Handling of Forked Requests ................................7
3.9. Rate of Notifications ......................................7
3.10. State Agents ..............................................7
4. Conference Document .............................................7
4.1. Format .....................................................7
4.2. Namespace ..................................................7
4.3. Versioning .................................................8
4.4. Partial Notifications Mechanism ............................8
4.5. Element Keys ...............................................9
4.6. Constructing Coherent State Procedure ......................9
5. Conference Data ................................................11
5.1. Overview ..................................................11
5.2. <conference-info> .........................................13
5.3. <conference-description> ..................................14
5.3.1. <conf-uris> ........................................14
5.3.2. <service-uris> .....................................15
5.3.3. <maximum-user-count> ...............................16
5.3.4. <available-media> ..................................16
5.4. <host-info> ...............................................17
5.4.1. <display-text> .....................................17
5.4.2. <web-page> .........................................17
5.4.3. <uris> .............................................17
5.5. <conference-state> ........................................17
5.5.1. <user-count> .......................................17
5.5.2. <active> ...........................................18
5.5.3. <locked> ...........................................18
5.6. <users> and Its <user> Sub-elements .......................18
5.6.1. <display-text> .....................................19
5.6.2. <associated-aors> ..................................19
5.6.3. <roles> ............................................19
5.6.4. <languages> ........................................19
5.6.5. <cascaded-focus> ...................................19
5.6.6. <endpoint> .........................................20
5.7. <endpoint> ................................................20
5.7.1. <display-text> .....................................20
5.7.2. <referred> .........................................21
5.7.3. <status> ...........................................21
5.7.4. <joining-method> ...................................22
5.7.5. <joining-info> .....................................23
5.7.6. <disconnection-method> .............................23
5.7.7. <disconnection-info> ...............................23
5.7.8. <media> ............................................24
5.7.9. <call-info> ........................................24
5.8. <media> ...................................................24
5.8.1. <display-text> .....................................25
5.8.2. <type> .............................................25
5.8.3. <label> ............................................25
5.8.4. <src-id> ...........................................25
5.8.5. <status> ...........................................26
5.9. Sidebars ..................................................26
5.9.1. <sidebars-by-ref> ..................................26
5.9.2. <sidebar-by-val> ...................................26
6. XML Schema .....................................................26
7. Examples .......................................................35
7.1. Basic Example .............................................35
7.2. Rich Example ..............................................36
8. Security Considerations ........................................40
8.1. Connection Security .......................................40
8.2. Authorization Considerations ..............................41
9. IANA Considerations ............................................41
9.1. conference Event Package Registration .....................41
9.2. application/conference-info+xml MIME Registration .........42
9.3. URN Sub-Namespace Registration for ........................43
9.4. XML Schema Registration ...................................43
9.5. URI Purposes Sub-registry Establishment ...................44
10. Acknowledgements ..............................................45
11. References ....................................................45
11.1. Normative References .....................................45
11.2. Informative References ...................................461. Introduction 🦋
okay so the SIP events framework [10] is the general machinery for subscribing to events in SIP networks and getting notifications about them 🔔. it introduces a "package", which is a specific "instantiation" of the events framework for a well-defined set of events 💅. here we define a SIP event package for tightly coupled conferences 🎀. this package can be used by the conference notification service outlined in the SIP conferencing framework [16] ✨. as described there, subscriptions to a conference URI get routed to the focus handling the conference 👑. the focus acts as the notifier and gives clients updates on the conference state 🫶.
the info this package provides includes conference identifier(s), conference participants (optionally with their statuses and media description), conference sidebars, conference service URIs, etc. 🌸
2. Terminology 📖
in this doc, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in RFC 2119 [1], and they show the requirement levels for compliant implementations 💖.
this doc uses the conferencing terminology from the Conferencing Framework [16] 🧚. we also use the "roster" term to talk about the participants in a conference or a sub-conference together 🍓.
3. Conference Event Package 🌸
the conference event package lets a user subscribe to the info about a conference 💜. in SIP, conferences are represented by URIs 🔗. those URIs point to a SIP user agent (UA) called a focus, which is responsible for making sure all the users in the conference can talk to each other, as the Conferencing Framework [16] describes 🎀. the focus has enough info about the conference state to tell subscribers about it ✨.
a participant in the conference might actually be another focus 🦋. to get a more complete participant list, the focus MAY subscribe to the conference package of the other focus to find out the participant list in the cascaded conference 🌈. that info can then go into notifications using the <cascaded-focus> element, as this package specifies 🫶.
this section gives the details for defining a SIP-specific event notification package, as specified by RFC 3265 [10] 💅.
3.1. Event Package Name 🏷️
the name of this event package is "conference" 🎀. the package name goes in the Event and Allow-Events headers, as RFC 3265 [10] defines 💖.
3.2. Filtering 🎛️
filters for conference subscriptions are a desirable feature and could be a topic for future standardization work 🔮. this doc does not define the filters for the conference package that go in the SUBSCRIBE body 🙈.
a SUBSCRIBE for the conference package sent without a body implies the default subscription filtering policy 🧚. the default policy is:
- Notifications are generated every time there is any change in the state of the conference. ✨
- Notifications do not normally contain full state; rather, they only indicate the state that has changed. The exception is a NOTIFY sent in response to a SUBSCRIBE. These NOTIFYs contain the full state of the information requested by the subscriber. 💅
3.3. Subscription Duration ⏳
the default expiration time for a subscription to a conference is one hour ⏰. once the conference ends, all subscriptions to that conference get terminated, with a reason of noresource, as RFC 3265 [10] defines 💀.
3.4. NOTIFY Bodies 📬
okay so, per RFC 3265 [10], the NOTIFY message carries bodies that describe the state of the resource you subscribed to ✨ The body has to be in a format that's listed in the Accept header field of the SUBSCRIBE, or a package-specific default if the SUBSCRIBE didn't have an Accept header at all 💅
For this event package, the notification body is a conference information document that describes what's going on in a conference 🎀 All subscribers and notifiers MUST support the "application/conference-info+xml" data format described in Sections 9 and 5, no exceptions bestie 👑 By default (aka if there's no Accept header on the SUBSCRIBE), the NOTIFY will contain a body in the "application/conference-info+xml" format. If the Accept header IS present, it MUST include "application/conference-info+xml" and MAY include any other types too 🌸
3.5. Notifier Processing of SUBSCRIBE Requests 🔐
the conference info is super sensitive tbh 😭 So all subscriptions SHOULD be authenticated and then authorized before they get approved. The authorization policy is up to the administrator, as always 💖
That said, it is RECOMMENDED that all users in the conference be allowed to subscribe to the conference event package 🫶
3.6. Notifier Generation of NOTIFY Requests 🔔
Notifications SHOULD be generated for the conference state when a new participant joins (aka gets "connected" to) or a participant leaves (aka gets "disconnected" from) the conference ✨
Subject to a local focus policy, extra changes in participants' status, changes in their media types, and other optional info MAY be reported by the focus 🦋
Changes in sidebar rosters SHOULD be reported by the focus to their participants, and they MAY be reported to others too, subject to local policy 🧚
Changes in conference identifiers and service URIs SHOULD be reported 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 🧩
the SIP events framework expects packages to spell out how a subscriber handles NOTIFY requests in any package-specific ways. In particular, it's about how the subscriber uses those NOTIFYs to build a coherent view of the state of the subscribed resource 👀
Typically, the NOTIFY for the conference package only includes info about users whose state in the conference changed. So to build a coherent view of everyone's state, a subscriber has to combine the NOTIFYs it gets over time 🍓
Notifications in this package can convey partial information, meaning they can describe just a subset of the state tied to the subscription. So an explicit algorithm has to be defined to build coherent and consistent state. The details are specific to the particular document type. See Section 4.6 for info on constructing coherent information from an application/ conference-info+xml document 📖
3.8. Handling of Forked Requests 🍴
conferences in this package are centralized by nature 🏰 So SUBSCRIBE requests for a conference should not generally fork. If forking happens in the network, subscribers to this package MUST NOT establish more than a single SIP dialog as a result of a single SUBSCRIBE request 🚫 In the foci cascading case, detailed conference info can be retrieved by establishing an individual SUBSCRIBE dialog with each participating focus 💅
3.9. Rate of Notifications 🐢
For congestion control reasons, it's important that the rate of notifications doesn't get excessive 🚦 So it is RECOMMENDED that the server does not generate notifications for a single subscriber at a rate faster than once every 5 seconds ⏱️
3.10. State Agents 🕵️♀️
Conference state is ideally kept in the element where the conference lives, so a conference focus is the best-suited element to handle subscriptions to it 👑 Cascaded foci MAY implement state agents (as defined in RFC 3265 [10]) for this package 🫧
4. Conference Document 📄
4.1. Format 🖋️
Conference information is an XML document that MUST be well-formed and valid 💖 It MUST be based on Extensible Markup Language (XML) 1.0 and MUST be encoded using UTF-8 [14] 🌷
4.2. Namespace 🏷️
This specification uses XML namespaces to identify conference information documents and document fragments 🎀 The namespace URI for elements defined by this specification is a Uniform Resource Namespace (URN) [2], using the namespace identifier 'ietf' defined by [6] and extended by RFC 3688 [21]. The URN looks like this:
urn:ietf:params:xml:ns:conference-info4.3. Versioning 🔢
The conference information is described by a hierarchical XML structure with the root element <conference-info> 🌳 The root element is the only element in the schema that carries a meaningful version number for all the elements in the document, so the whole conference information is tied to that one version number 🦋
The 'version' attribute MUST be included in the root <conference-info> element ✨
4.4. Partial Notifications Mechanism 🧩
This specification defines a basic partial notifications mechanism using a 'state' attribute (more on that below). This mechanism MUST be supported by all subscribing clients 🙌 Additional general partial notifications mechanisms can be defined and applied to this package in the future 🔮
All sub-elements in the <conference-info> hierarchical XML structure can be sorted into two groups: permissible for partial notifications or not. Elements that carry a lot of data that changes often are permissible for partial notifications, and they get a 'state' attribute attached 🍰 All future extensions to this schema MUST define which extension elements can also use this mechanism 📝 All other elements can only be updated as atomic pieces of data 🧱
Here's the complete list of elements allowed to use the partial notifications mechanism defined here. (Heads up: future partial notifications mechanisms could potentially apply to more elements 👀)
- Element
<conference-info> - Element
<users> - Element
<user> - Element
<endpoint> - Element
<sidebars-by-val> - Element
<sidebars-by-ref>
The 'state' attribute value tells you whether the reported info about the element is "full" or "partial", or whether the element has been "deleted" from the conference state document 🗑️ The default value of any 'state' attribute is "full" 💅
A 'state' attribute on a child element MUST be consistent with its parent's 'state' 🫶 This 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" 🌈 A parent element with "deleted" 'state' SHOULD NOT contain child elements 🙅♀️ Any info provided for child elements of a "deleted" parent MUST be ignored by the package subscriber 🚫✨
4.5. Element Keys 🔑
The defined XML schema has a property of unique identification among sub-elements of a common parent, which is what makes the partial notifications mechanism defined in this document possible 🧠 This property is achieved by defining a key for each sub-element that can appear multiple times under the common parent 💜
In this specification, the element key is the set of mandatory attributes or sub-elements of an element. The key value MUST be unique for the element among its siblings of the same type 🔐
In this specification, two keys of type xs:anyURI are considered equal if the UTF-8 representations of the keys (including all URI parameters that can be included with the URI) are identical. So using relative URIs and lexical white space in these keys is NOT RECOMMENDED 🙈
Here's the list of elements (subject to partial notifications of their parent elements) with their keys as defined by this specification 📋
- Element
<user>uses as the key 'entity' - Element
<endpoint>uses as the key 'entity' - Element
<media>uses as the key 'id' - Element
<entry>(child to<sidebars-by-val>) uses as the key 'entity' - Element
<sidebars-by-ref>uses as the key<uri>
4.6. Constructing Coherent State Procedure ✨
okay bestie, this section is the recipe for building a coherent conference state as a subscriber 💅 The subscriber keeps one local version number for the whole conference document, plus a local element instance for every element in the schema 🧚 And for every element with keys (the ones we just talked about), it keeps a virtual table with a row for each existing key value 🌸
The first time a NOTIFY with a "full" document shows up (you can tell from the state attribute on <conference-info>), the conference package subscriber MUST set the local version number to the version attribute from that <conference-info> and fill its local data with the received info 🎀
Every time a new NOTIFY lands, compare the local version number with the version attribute of the new document. If the document's version is equal to or less than the local version, the document gets discarded without processing 🗑️
Otherwise, if the NOTIFY has a "full" or "deleted" state, the conference package subscriber MUST set the local version number to the version attribute from the received <conference-info> and replace the local information with the received document. Getting "deleted" state for the <conference-info> element means the conference has ceased to exist 💀 so the subscriber SHOULD terminate the subscription by sending the SUBSCRIBE with Expires = 0.
Otherwise (aka the NOTIFY has "partial" state), if the version in the received document is more than one number higher than the previous local version, the subscriber MUST generate a subscription refresh request to trigger a full state notification 🚨 If the version is exactly one higher than the local version, bump the local version number and use the document to update the local content, as described below ✨
For each sub-element of the <conference-info> element in the received document:
- If the element contains "full" state, the whole local element content is flushed and repopulated from the document.
- Otherwise, if the element contains "deleted" state, the whole element MUST be removed from the local content.
- Otherwise, if the 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 3.2.
3.2. For each atomic element received in the schema, the element is replaced with the new information as a whole. 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. Also, for each element with the state attribute set to "deleted", the whole element is removed from the local content.
3.3. For each non-atomic element with the state attribute set to "partial", the algorithm is applied recursively starting from step 3.1.
5. Conference Data 🌈
5.1. Overview
The <conference-info> document format is designed to convey info about the conference and about who's participating in it 🦋 The following non-normative diagram gives an example of the overall hierarchy used in this format. Conferences contain users, who can be represented by multiple endpoints, and each endpoint can have multiple media streams. Conferences can also include or reference "sidebar conferences". When sidebar info gets incorporated into a conference information document in a <sidebars-by-val> element, each <entry> element represents a sidebar and can include any sub-elements permitted in the <conference-info> top-level element.
conference-info
|
|-- conference-description
|
|-- host-info
|
|-- conference-state
|
|-- users
| |-- user
| | |-- endpoint
| | | |-- media
| | | |-- media
| | | |-- call-info
| | |
| | |-- endpoint
| | |-- media
| |-- user
| |-- endpoint
| |-- media
|
|-- sidebars-by-ref
| |-- entry
| |-- entry
|
|-- sidebars-by-val
|-- entry
| |-- users
| |-- user
| |-- user
|-- entry
|-- users
|-- user
|-- user
|-- userIn most cases, this document does not mandate how the info presented to subscribers through the conference document is obtained by the focus 🤷♀️ Often it can be dynamically learned from call signaling, and it can also be manually populated by an administrator, all subject to local policies. This document specifies what the XML elements mean so subscribers can interpret them properly. Some portions of the info are meant for automata, and others are for human consumption only. For example, the <display-text> sub-elements of elements <conf-uris>, <service-uris>, <available-media>, <host-info>, <endpoint>, and <media> are intended for display to human subscribers only 💖
Although in multiple places this document says that specific info "SHOULD" be communicated to subscribers, know that particular conference package subscribers (like someone representing a moderator, an administrator, or a cascaded focus) rely on that info being accurate for their proper operation 😭 So a conferencing server MUST ensure that all critical changes (the ones stated as "SHOULD") are communicated to these specific subscribers. Otherwise, these changes MUST be communicated to all subscribers to the conference information.
Following sections describe the XML schema in more detail 📖
5.2. <conference-info>
A conference information document begins with the root element tag <conference-info> of conference-type 👑
The following attributes are defined for <conference-info>:
entity: This attribute contains the conference URI that identifies the conference being described in the document. It's the SIP URI that an interested entity needs to SUBSCRIBE to in order to get the conference package info. Note that this URI can be listed as one of the URIs used to access the conference by SIP means, in accordance with Section 5.3.1 below.state: This attribute indicates whether the document contains the whole conference information ("full"), only the info that has changed since the previous document ("partial"), or whether the conference ceased to exist ("deleted"). For more detail, see Section 4.version: This attribute lets the recipient of conference information documents properly order the received notifications, and it MUST be used with the root<conference-info>element 🔢 The version number is a 32-bit monotonically increasing integer scoped within a subscription. A server MUST increment the version number for each notification (full, partial, and deleted) being sent to a subscriber that reports a change in the conference document state. For each partial notification, the version number MUST be increased by one. Note that a partial notification and a subsequent full notification over the same dialog MAY contain the same version number if no change in the conference state occurred in between.
The <conference-info> element is made up of <conference-description>, <host-info>, <conference-state>, <users>, <sidebars-by-ref>, and <sidebars-by-val> child elements. A "full" conference document MUST at least include the <conference-description> and <users> child elements 🫶
Following sections describe these elements in detail. The full XML schema is provided in Section 6.
5.3. <conference-description>
The <conference-description> element describes the conference as a whole 🎀
The child elements <display-text>, <subject>, <free-text>, and <keywords> are used to describe the conference content:
<display-text>: Contains descriptive text suitable for human consumption, for example, a listing in a directory.<subject>: Contains the subject of the conference.<free-text>: Contains an additional, longer description of the conference.<keywords>: Contains a list of space-separated string tokens that search engines can use to better classify the conference.
Additional child elements <conf-uris> and <service-uris> describe the conference-related URIs, and <maximum-user-count> and <available-media> describe the overall characteristics 🧠
This info is typically derived from the system conference policies, is set before the conference activation, and is rarely changed during the conference lifetime ⭐
The following sections describe the remaining elements in more detail. Other sub-elements can extend <conference-description> in the future 🦋
5.3.1. <conf-uris>
This element contains a sequence of <entry> child elements, each one containing a URI to be used to access the conference by different signaling means. The value of the URI MUST be unique in the conference context and is included in the <uri> sub-element.
Each <entry> MAY contain additional info that's useful to the participant when accessing the conference.
An <entry> element MAY contain the <display-text> sub-element, which provides a textual description meant for human consumption.
Each <entry> element SHOULD contain a <purpose> sub-element that describes what happens when accessing the URI. The currently defined <purpose> values to be used with the <conf-uris> are the following:
participation: Accessing a URI with this<purpose>will bring the party into the conference 🎉streaming: Accessing a URI with this<purpose>will commence streaming the conference, but won't allow active participation 📺
Examples of suitable URI schemes include sip: and sips: [8], xmpp: [22], h323: [20], and tel: [19] URIs. The rtsp [18] URI is suitable for streaming 🌸
Future extensions to this schema may define new values and register them with IANA under the registry established by this specification 💜
5.3.2. <service-uris> 🎀
Okay bestie, this one is all about the extra services hanging around the conference 🦋. Just like <conference-uris>, it's a bunch of <entry> children, and each one holds the URI you'd use to reach a different service for that particular conference ✨. Every URI MUST be unique in the conference context, and it lives in the <uri> sub-element 💖.
Each <entry> MAY have a <display-text> sub-element, which is basically a human-friendly description for users 🌸.
Each <entry> SHOULD also have a <purpose> sub-element 💅. These are the <purpose> values defined so far for <service-uris>:
web-page: a web page with extra info about the conference 🌐recording: where you can grab the recorded conference 🎬event: where you can request a subscription to the conference event package. This is usually the main conference URI 🔔
Future extensions to this schema may define new values and register them with IANA under the registry set up by this spec. Lots of new stuff incoming, periodt 🌈
5.3.3. <maximum-user-count> 🍓
The value here gives the recipient of the conference document a hint about how many users can be invited to the conference 👀. Usually this is the total number of users allowed to join by all the different routes published in <conf-uris>. Also, an administrator sets this number, and it can reflect local policies like network consumption, CPU power, and licensing rules 💅
5.3.4. <available-media> 🦋
This element is a sequence of <entry> children of conference-medium-type, and each one is indexed by the 'label' attribute 🎶
The 'label' attribute is the media stream identifier the conferencing server assigns. Its value will be unique in the <conference-info> context, and it will typically line up with the SDP "label" media attribute defined in [17] 🫶
Each <entry> describes one media stream available to the participants and includes:
<display-text>: the display text for the media stream 💬<type>: the media type of the stream. The value MUST be one of the values registered for "media" in SDP [3] and its later revisions, for example "audio", "video", "text", and "message" 🎧<status>: the available status of the media stream for the conference participants 📶
For <status>, here's an example: the status of a stream the focus would offer in a 'dial-out' scenario. Using normal SIP offer/answer mechanisms (defined in RFC 3264 [9]) in both dial-in and dial-out scenarios, a participant can totally establish only a subset of the available streams. For instance, they can request or accept a stream in one direction only, if both directions are available 🔄 The valid <status> values are "sendrecv", "sendonly", "recvonly", or "inactive", as defined in SDP [3] and its later revisions. Also, heads up: the value shows the direction from the participants' point of view 👀✨
5.4. <host-info> 🏠
This element holds info about the entity hosting the conference 💖 It gets set before the conference is activated and rarely changes during the conference lifetime, unless the whole conference moves to be hosted by a different entity. The host info is made up of these elements:
5.4.1. <display-text> 💬
This element has the display text describing the entity hosting the conference 🌸
5.4.2. <web-page> 🌐
This element contains an HTTP: or HTTPS: URI for a web page that describes either the conference service or the user hosting the conference 🎀
5.4.3. <uris> 🔗
This element has a set of <entry> children. Each one contains a URI value and, optionally, its description 🦋
5.5. <conference-state> 📊
By including this element in the conference document, the server can tell subscribers about changes in the overall conference info 🔥 The <conference-state> child elements are below.
5.5.1. <user-count> 🔢
The value here tells the recipient of the conference document the overall number of users participating in the conference at a certain moment 👥 Usually this is the total number of users who joined by the different routes published in <conf-uris>. Heads up: this number does not necessarily need to match, and it MAY exceed the number of entries in the <users> container. For example, in a lecturing scenario, big conference notifications may skip most participants in <users> and only report the panelists or speakers 🎤✨
5.5.2. <active> 🟢
This Boolean element says whether the conference is currently active 💅 A conference is active if an authorized client calls one of the <conf-uris> and that results in a successful signaling session between the client and the focus, plus a successful join to the conference 📞
5.5.3. <locked> 🔒
This Boolean element says whether the conference is currently locked. Here, "locked" means the conference roster can't be added to, although participants can still leave or be removed 🙅♀️
5.6. <users> and Its <user> Sub-elements 👑
The <users> element is a container of <user> children, and each one describes a single participant in the conference 🫶
These attributes are defined for the <user> element:
entity: the URI for the user in the conference. It's a logical identifier that corresponds to the call signaling authenticated identity of the participant 🪪 The'entity'value MUST be unique among all participants in the conference. If the focus decides not to reveal this info for some participants (for example, because of local policies or security reasons), the host portion of the user URI MUST use the .invalid top level domain (TLD), per RFC 2606 [5]. The focus also MUST build the user portion so the URI is unique among all participants of the same domain. For example, this convention:
"AnonymousX" <sip:anonymousX@anonymous.invalid>is one that SHOULD be used for a participant requesting privacy, in line with the guidelines for generating anonymous URIs in RFC 3323 [11]. Also, in a different case, such as when used together with Enhancements for Authenticated Identity Management in SIP [25], this convention can be used:
"AnonymousX" <sip:anonymousX@example.com>state: this attribute shows whether the document has the whole user info ("full"), only the info that changed since the previous document ("partial"), or whether the user was removed from the conference ("deleted") 🔄
These child elements are defined for the <user> element:
5.6.1. <display-text> 💖
This element is used to show the user-friendly name in the conference 🌸
5.6.2. <associated-aors> 🔗
This element has extra URIs (beyond the 'entity') associated with the <user> 💅 Usually an administrator provides this manually to show the logical link between signaling entities that are otherwise independent. For example, if the 'entity' of a <user> is a Globally Routable User URI (GRUU) [24] or a tel: URI RFC 3966 [19], it would be handy to fill this field with the Address of Record (AOR) of the person using those devices. Each device would be its own independent <user> 📱
5.6.3. <roles> 🎭
This element MAY contain a set of human-readable strings describing the user's roles in the conference. Note that this info is for human consumption only. This specification doesn't define the set of possible conferencing roles or what each one means. Future conferencing specs are expected to define those, plus the matching schema extensions, as appropriate ✨
5.6.4. <languages> 🌍
This element has a list of tokens separated by spaces, and each one is a language the user understands 🗣️ This info can be learned automatically via call signaling or set manually for each participant 💬
5.6.5. <cascaded-focus> 🌀
This element contains a conference URI (different from the main conference URI) for users who are connected to the main conference through focus cascading 🔗 Following the SIP Conferencing Framework [16], this package only covers peer-to-peer ("flat") focus cascading. The actual cascading graph can't be deduced from this package alone. Advanced apps can build the graph by subscribing to both this package and the Dialog Package [23] of each cascaded focus, then correlating the relevant info 🧠⭐
5.6.6. <endpoint> 📲
By including one or more <endpoint> elements under a parent <user> element, the server can give you the level of detail you want (including state, media streams, and access info) about the user's devices and signaling sessions in the conference 💜
In a conferencing system where authentication happens per endpoint (rather than per user), the focus might not know that several endpoints belong to the same user. In that case, each endpoint shows up as a separate <user> with its own <endpoint> sub-element(s) in the conference document 🙈
Or, the focus may choose to hide the info about a participant's multiple endpoints and signaling sessions from other subscribers entirely (for example, because of privacy policies). To do that, the focus MAY combine the info from multiple signaling sessions under a single <endpoint> element. Heads up: in this case, the detailed call signaling info (the <call-info> sub-element) will not be included 🫣
5.7. <endpoint> 📱
This section digs deeper into the <endpoint> element 🔍
These attributes are defined for the <endpoint> element:
entity: the server MUST generate the'entity'key for each<endpoint>element under the parent<user>, so its value is unique in the user context 🔑 In SIP terms, this can be the Contact URI, GRUU, and so on 💅state: this attribute shows whether the element has the whole endpoint info ("full"), only the info that changed since the previous document ("partial"), or whether the endpoint was removed from the conference ("deleted") 🔄
These child elements are defined for the <endpoint> element:
5.7.1. <display-text> 🌸
This element contains the display text for the endpoint 💖
5.7.2. <referred> 💖
okay so this element tells you who actually got this endpoint into the conference 🦋 like, the user whose action made it happen (ex: the SIP user at this URI sent a REFER to the focus). it MAY contain the following sub-elements:
<when>🕰️ this one is an XML dateTime type and holds the date and time the endpoint was referred to the conference. it SHOULD be expressed in Coordinated Universal Time (UTC) format, ngl that's the vibe. example:
<when>2005-03-04T20:00:00Z</when><reason>📝 this holds the reason the endpoint was referred to the conference. including it in the format from RFC 3326 [12] is RECOMMENDED, so it's giving organized 💅 example:
<reason>Reason: SIP;text="Ad-hoc Invitation"</reason><by>👑 this is the URI of the entity that caused the endpoint to be referred to the conference. for SIP, it gets filled in from the Referred-By header defined in RFC 3892 [15]. main character energy 🌟
5.7.3. <status> 🌸
this element is the status of the endpoint and it can be any of these values:
connected: the endpoint is a participant in the conference 🎀. depending on the media policies, they can send and receive media to and from other participants.disconnected: the endpoint isn't a participant in the conference, and no active dialog exists between the endpoint and the focus. bye bye 👋on-hold: an active signaling dialog exists between the endpoint and the focus, but the endpoint is "on-hold" for this conference, meaning they're neither "hearing" the conference mix nor having their media mixed in. for example, the endpoint asked to join over SIP but is waiting on moderator approval 🙈. in the meantime they hear music-on-hold or some other related content 🎶muted-via-focus: an active signaling dialog exists and the endpoint can "listen" to the conference, but their media isn't being mixed in 🤐. sometimes only some of the endpoint's media streams get muted by the focus (like poor-quality video) while others (like voice or IM) stay active. in that case, it is RECOMMENDED that the "aggregated" endpoint connectivity <status> reflects the status of the most active media 💜pending: the endpoint isn't in the session yet, but it's anticipated they'll join soon ⏳alerting: a Public Switched Telephone Network (PSTN) ALERTING or SIP 180 Ringing was returned for the outbound call, so the endpoint is being alerted 🔔dialing-in: the endpoint is dialing into the conference and isn't in the roster yet (probably being authenticated) 🔐dialing-out: the focus dialed out to connect the endpoint, but they're not in the roster yet (probably being authenticated) 📞disconnecting: the focus is in the middle of disconnecting the endpoint (ex: in SIP a DISCONNECT or BYE was sent to the endpoint) 🚪
ngl the transient statuses (like disconnecting, alerting, etc.) could generate a LOT of traffic 😭. so implementations MAY choose to generate notifications on these statuses to certain participants only, or not generate them at all, subject to local policy. it's all about balance 💅
5.7.4. <joining-method> 🧚
this element is the method the endpoint used to join the conference and it can be:
dialed-in: the endpoint dialed into the conference (ex: a SIP INVITE sent to the focus), and that led to a successful dialog establishment 📲dialed-out: the focus brought the endpoint into the conference (ex: in SIP, the focus sent a successful INVITE to the endpoint) 📤focus-owner: the endpoint IS the focus for this conference 👑. this status only gets used when a participant's UA acts as a conference focus.
5.7.5. <joining-info> 🍓
this element has info about how the endpoint joined and it MAY contain the following sub-elements:
<when>⏰ an XML dateTime type with the date and time the endpoint joined the conference. it SHOULD be expressed in Coordinated Universal Time (UTC).<reason>💬 the reason the endpoint joined the conference. including it in the format defined by RFC 3326 [12] is RECOMMENDED. example:
<reason>Reason: SIP;text="Ad-hoc Invitation"</reason><by>🫶 the URI of the entity that caused the endpoint to join the conference.
5.7.6. <disconnection-method> 🥀
this element is the method the endpoint used to leave the conference and it can be:
departed: in SIP, the endpoint sent a BYE, so they left the conference on their own 👋✨booted: in SIP, the endpoint got a BYE from the focus, which ejected them out of the conference 🥾. alternatively, the endpoint tried to dial into the conference but the focus rejected them because of local policy 🚫failed: in SIP, the server tried to bring the endpoint into the conference, but its attempt to contact that endpoint got a non-200 class final response 💀. alternatively, the endpoint tried to dial in and it didn't work out due to technical reasons 🔧busy: in SIP, the server tried to bring the endpoint into the conference, but its attempt to contact the endpoint got a 486 "Busy Here" final response 📵. alternatively, the endpoint tried to dial in but the focus responded with a 486 response 🙈
5.7.7. <disconnection-info> 🌙
this element has info about the endpoint's departure from the conference and it MAY contain the following sub-elements:
<when>🕰️ an XML dateTime type with the date and time the endpoint departed the conference. it SHOULD be expressed in Coordinated Universal Time (UTC).<reason>🗯️ the reason the endpoint departed the conference. when it's known and meaningful, including the info as conveyed or reported by the call signaling in the format defined by RFC 3326 [12] is RECOMMENDED. example:
<reason>Reason: SIP;cause=415;text="Unsupported Media Type"</reason><by>🫠 the URI of the entity that caused the endpoint to depart the conference.
5.7.8. <media> 🎧
this element has info about a single media stream and it's included for each media stream being established between the focus and the <endpoint>. the media stream definition can be found in SDP [3] 📖
if the<call-info>sub-element of the endpoint isn't included in the document by the server, it's possible that the media streams listed under the common<endpoint>were established by separate signaling sessions 👀
5.7.9. <call-info> 🔍
the <call-info> element gives detailed call signaling info for a call being maintained between the participant and the focus. privacy policies MUST be consulted before revealing this info to other participants 🔒
the <sip> sub-element holds the SIP dialog identifier of the endpoint's dialog with the focus 🦋. it includes the sub-elements <display-text>, <call-id>, <to-tag>, and <from-tag>.
in the future, the <call-info> element can be expanded to include call signaling protocol info for other protocols besides SIP 🌈
5.8. <media> 🎀
this section goes deeper into the <media> element 💅
a single 'id' attribute is defined for this element. it's the media stream identifier generated by the server, and its value is unique in the endpoint context. this attribute is the key to referring to a particular media stream in the conference document 🗝️
the following child elements are defined for <media>:
5.8.1. <display-text> 🏷️
this element holds the display text for the media stream. its value corresponds to the SDP description media attribute ("i") defined in SDP [3].
5.8.2. <type> 🎞️
this element holds the media type for the media stream. its value MUST be one of the values registered for "media" of SDP [3] and its later revision(s). no cap, that's a strict one 😤
5.8.3. <label> 🪪
the <label> element carries a unique identifier for this stream among all streams in the conference, and the focus assigns it ✨. its value will typically correspond to the SDP "label" media attribute defined in [17], and it's exchanged between a participant and a focus over the signaling connection between them 🤝
if the <available-media> information (described in Section 5.3.4) is included in the conference document, the value of this element MUST be equal to the 'label' value of the corresponding media stream <entry> in the <available-media> container 🫶
5.8.4. <src-id> 🎤
the <src-id> element, if applicable, carries info about the actual source of the media 🔊. for example, for Real-time Transport Protocol (RTP) / RTP Control Protocol (RTCP) [13] media streams, the value MUST contain the synchronization source (SSRC) identifier value the endpoint generated for the stream it sends.
when an RTP mixer generates a contributing source (CSRC) identifiers' list according to RTP/RTCP [13], it puts a list of the SSRC identifiers of the sources that contributed to a particular packet into that packet's RTP header 🧩. a quote from RFC 3550 [13] explains it like this:
"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)."
if an RTP mixer that follows the above is used, participants can perform an SSRC to user mapping and identify "a current speaker" 🎙️👑
5.8.5. <status> 🌤️
the <status> element shows the status in both directions of the media stream. it has the values sendrecv, sendonly, recvonly, or inactive, as defined in SDP [3] and its later revision(s) 💫. note that the value is from the participant's point of view. for example, a muted participant's stream will have the value recvonly 🙊
5.9. Sidebars 🪞
if a participant in the main conference joins a sidebar, a new <user> element representing that user gets created. it's either part of a separate sub-conference referenced from the <sidebars-by-ref> element, or it sits under one of the <sidebars-by-val> elements, as described below 🧁
the <user> in the main roster isn't deleted, but its media statuses can be updated to reflect the effect of their participation in the sidebar 🌸. how this info displays can vary among subscribers to the same conference information, subject to local policies and to the subscriber's role in both the sidebar and the main conference 💜
5.9.1. <sidebars-by-ref> 🔗
this element contains a set of <entry> child elements, each with a sidebar conference URI. the recipient can then subscribe to sidebar info independently from the main conference package subscription 📬
5.9.2. <sidebars-by-val> 🍭
this element contains a set of <entry> child elements, each with info about a single sidebar 🧾. by using this element of conference-type, the server can include a full or partial description of each sidebar (as a sub-conference) in the body of the main conference document 🌈
6. XML Schema ✨
Okay bestie, the schema keeps going 🎀 Every <xs:element> is a little box with its own rules, so I'm keeping every one exactly as written 💅
<?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">
<!--
This imports the xml:language definition
-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<!--
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="users"
type="users-type" minOccurs="0"/>
<xs:element name="sidebars-by-ref"
type="uris-type" minOccurs="0"/>
<xs:element name="sidebars-by-val"
type="sidebars-by-val-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="entity"
type="xs:anyURI" use="required"/>
<xs:attribute name="state"
type="state-type" use="optional" default="full"/>
<xs:attribute name="version"
type="xs:unsignedInt" use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
STATE TYPE
-->
<xs:simpleType name="state-type">
<xs:restriction base="xs:string">
<xs:enumeration value="full"/>
<xs:enumeration value="partial"/>
<xs:enumeration value="deleted"/>
</xs:restriction>
</xs:simpleType>
<!--
CONFERENCE DESCRIPTION TYPE
-->
<xs:complexType name="conference-description-type">
<xs:sequence>
<xs:element name="display-text"
type="xs:string" minOccurs="0"/>
<xs:element name="subject"
type="xs:string" minOccurs="0"/>
<xs:element name="free-text"
type="xs:string" minOccurs="0"/>
<xs:element name="keywords"
type="keywords-type" minOccurs="0"/>
<xs:element name="conf-uris"
type="uris-type" minOccurs="0"/>
<xs:element name="service-uris"
type="uris-type" minOccurs="0"/>
<xs:element name="maximum-user-count"
type="xs:unsignedInt" minOccurs="0"/>
<xs:element name="available-media"
type="conference-media-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
HOST TYPE
-->
<xs:complexType name="host-type">
<xs:sequence>
<xs:element name="display-text" type="xs:string"
minOccurs="0"/>
<xs:element name="web-page" type="xs:anyURI"
minOccurs="0"/>
<xs:element name="uris" type="uris-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CONFERENCE STATE TYPE
-->
<xs:complexType name="conference-state-type">
<xs:sequence>
<xs:element name="user-count" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element name="active" type="xs:boolean"
minOccurs="0"/>
<xs:element name="locked" type="xs:boolean"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CONFERENCE MEDIA TYPE
-->
<xs:complexType name="conference-media-type">
<xs:sequence>
<xs:element name="entry" type="conference-medium-type"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CONFERENCE MEDIUM TYPE
-->
<xs:complexType name="conference-medium-type">
<xs:sequence>
<xs:element name="display-text" type="xs:string"
minOccurs="0"/>
<xs:element name="type" type="xs:string"/>
<xs:element name="status" type="media-status-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="label" type="xs:string"
use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
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" default="full"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
URI TYPE
-->
<xs:complexType name="uri-type">
<xs:sequence>
<xs:element name="uri" type="xs:anyURI"/>
<xs:element name="display-text" type="xs:string"
minOccurs="0"/>
<xs:element name="purpose" type="xs:string"
minOccurs="0"/>
<xs:element name="modified" type="execution-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
KEYWORDS TYPE
-->
<xs:simpleType name="keywords-type">
<xs:list itemType="xs:string"/>
</xs:simpleType>
<!--
USERS TYPE
-->
<xs:complexType name="users-type">
<xs:sequence>
<xs:element name="user" type="user-type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="state" type="state-type"
use="optional" default="full"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
USER TYPE
-->
<xs:complexType name="user-type">
<xs:sequence>
<xs:element name="display-text" type="xs:string"
minOccurs="0"/>
<xs:element name="associated-aors" type="uris-type"The user type is next, and it's giving a lot of structure 🦋✨
minOccurs="0"/>
<xs:element name="roles" type="user-roles-type"
minOccurs="0"/>
<xs:element name="languages" type="user-languages-type"
minOccurs="0"/>
<xs:element name="cascaded-focus" type="xs:anyURI"
minOccurs="0"/>
<xs:element name="endpoint" type="endpoint-type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI"/>
<xs:attribute name="state" type="state-type"
use="optional" default="full"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
USER ROLES TYPE
-->
<xs:complexType name="user-roles-type">
<xs:sequence>
<xs:element name="entry" type="xs:string"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
USER LANGUAGES TYPE
-->
<xs:simpleType name="user-languages-type">
<xs:list itemType="xs:language"/>
</xs:simpleType>
<!--
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="status" type="endpoint-status-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:element name="media" type="media-type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="call-info" type="call-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:string"/>
<xs:attribute name="state" type="state-type"
use="optional" default="full"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
ENDPOINT STATUS TYPE
-->
<xs:simpleType name="endpoint-status-type">
<xs:restriction base="xs:string">
<xs:enumeration value="pending"/>
<xs:enumeration value="dialing-out"/>
<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="disconnected"/>
</xs:restriction>
</xs:simpleType>
<!--
JOINING TYPE
-->
<xs:simpleType name="joining-type">
<xs:restriction base="xs:string">
<xs:enumeration value="dialed-in"/>
<xs:enumeration value="dialed-out"/>
<xs:enumeration value="focus-owner"/>
</xs:restriction>
</xs:simpleType>
<!--
DISCONNECTION TYPE
-->
<xs:simpleType name="disconnection-type">
<xs:restriction base="xs:string">
<xs:enumeration value="departed"/>
<xs:enumeration value="booted"/>
<xs:enumeration value="failed"/>
<xs:enumeration value="busy"/>
</xs:restriction>
</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 namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CALL TYPE
-->
<xs:complexType name="call-type">
<xs:choice>
<xs:element name="sip" type="sip-dialog-id-type"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</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="call-id" type="xs:string"/>
<xs:element name="from-tag" type="xs:string"/>
<xs:element name="to-tag" type="xs:string"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
MEDIA TYPE
-->
<xs:complexType name="media-type">
<xs:sequence>
<xs:element name="display-text" type="xs:string"
minOccurs="0"/>
<xs:element name="type" type="xs:string"
minOccurs="0"/>
<xs:element name="label" type="xs:string"
minOccurs="0"/>
<xs:element name="src-id" type="xs:string"
minOccurs="0"/>
<xs:element name="status" type="media-status-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string"
use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
MEDIA STATUS TYPE
-->
<xs:simpleType name="media-status-type">
<xs:restriction base="xs:string">
<xs:enumeration value="recvonly"/>
<xs:enumeration value="sendonly"/>
<xs:enumeration value="sendrecv"/>
<xs:enumeration value="inactive"/>
</xs:restriction>
</xs:simpleType>
<!--
SIDEBARS BY VAL TYPE
-->
<xs:complexType name="sidebars-by-val-type">
<xs:sequence>
<xs:element name="entry" type="conference-type"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="state" type="state-type"
use="optional" default="full"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
</xs:schema>7. Examples ✨
7.1. Basic Example 🎀
okay so this is the part where we see the whole schema actually in action, bestie 🧚 here's an example of a full conference information document that's literally everything in one place:
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sips:conf233@example.com"
state="full" version="1">
<!--
CONFERENCE INFO
-->
<conference-description>
<subject>Agenda: This month's goals</subject>
<service-uris>
<entry>
<uri>http://sharepoint/salesgroup/</uri>
<purpose>web-page</purpose>
</entry>
</service-uris>
</conference-description>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>33</user-count>
</conference-state>
<!--
USERS
-->
<users>
<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>
<status>disconnected</status>
<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 id="1">
<display-text>main audio</display-text>
<type>audio</type>
<label>34567</label>
<src-id>432424</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
<!--
USER
-->
<user entity="sip:alice@example.com" state="full">
<display-text>Alice</display-text>
<!--
ENDPOINTS
-->
<endpoint entity="sip:4kfk4j392jsu@example.com;grid=433kj4j3u">
<status>connected</status>
<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 id="1">
<display-text>main audio</display-text>
<type>audio</type>
<label>34567</label>
<src-id>534232</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
</users>
</conference-info>7.2. Rich Example ✨
okay so this is the full-on main character example 💅 We've got a partial conference info doc for a voice conference with 32 participants 🎧 Bob got booted by Mike because of bad voice quality 💀 There are three sidebars. Two are only referenced by their sidebar URIs, and the info for the third is included right in this notification 🦋 The conference offers both audio and video, but only audio is actually in use right now 🎀
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns: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 goals</subject>
<free-text>We will start strict on time</free-text>
<keywords>sales meeting weekly</keywords>
<conf-uris>
<entry>
<uri>tel:+18005671234</uri>
<display-text>TTI Bridge</display-text>
<purpose>participation</purpose>
</entry>
<entry>
<uri>h323:conf545@h323.example.com</uri>
<purpose>participation</purpose>
</entry>
<entry>
<uri>http://real.streaming.com/54634/live.ram</uri>
<purpose>streaming</purpose>
</entry>
</conf-uris>
<service-uris>
<entry>
<uri>http://sharepoint/salesgroup/</uri>
<purpose>web-page</purpose>
</entry>
<entry>
<uri>http://quicktime.com/54634/recording.mov</uri>
<display-text>Quicktime</display-text>
<purpose>recording</purpose>
</entry>
</service-uris>
<maximum-user-count>100</maximum-user-count>
<available-media>
<entry label="34567">
<display-text>main audio</display-text>
<type>audio</type>
<status>sendrecv</status>
</entry>
<entry label="34569">
<display-text>main video</display-text>
<type>video</type>
<status>inactive</status>
</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>32</user-count>
<active>true</active>
<locked>false</locked>
</conference-state>
<!--
USERS
-->
<users>
<user entity="sip:bob@example.com">
<display-text>Bob Hoskins</display-text>
<associated-aors>
<entry>
<uri>mailto:bob@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<roles>
<entry>participant</entry>
</roles>
<languages>en</languages>
<!--
ENDPOINTS
-->
<endpoint entity="sip:bob@pc33.example.com">
<display-text>Bob's Laptop</display-text>
<referred>
<when>2005-03-04T20:00:00Z</when>
<reason>expert required</reason>
<by>sip:mike@example.com</by>
</referred>
<status>disconnecting</status>
<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>
<!--
MEDIA
-->
<media id="1">
<display-text>main audio</display-text>
<type>audio</type>
<label>34567</label>
<src-id>432424</src-id>
<status>sendrecv</status>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>hsjh8980vhsb78</call-id>
<from-tag>vav738dvbs</from-tag>
<to-tag>8954jgjg8432</to-tag>
</sip>
</call-info>
</endpoint>
</user>
</users>
<!--
SIDEBARS BY REFERENCE
-->
<sidebars-by-ref state="partial">
<entry>
<uri>sips:conf233@example.com;grid=45</uri>
<display-text>sidebar with Carol</display-text>
</entry>
<entry>
<uri>sips:conf233@example.com;grid=21</uri>
<display-text>private with Peter</display-text>
</entry>
</sidebars-by-ref>
<!--
SIDEBARS BY VALUE
-->
<sidebars-by-val state="partial">
<entry entity="sips:conf233@example.com;grid=77"
state="partial">
<users>
<user entity="sip:bob@example.com"/>
<user entity="sip:mark@example.com"/>
<user entity="sip:dan@example.com"/>
</users>
</entry>
</sidebars-by-val>
</conference-info>8. Security Considerations 🔐
okay this part is SERIOUS bestie 😭 Subscriptions to conference state info can reveal super sensitive stuff, so it is RECOMMENDED that a focus uses a strong means for authentication and conference information protection, and that it applies comprehensive authorization rules when using the conference notification mechanism defined here. The next sections dig into each of these aspects 🫶
8.1. Connection Security 🔒
it is RECOMMENDED that a focus authenticates a conference package subscriber using the normal SIP authentication mechanisms, like Digest as defined in Section 22 of RFC 3261 [8] 💖
the mechanism used for conveying the conference information MUST ensure integrity, and it SHOULD ensure confidentially of the information 🔥 To get there, an end-to-end SIP encryption mechanism, like S/MIME described in Section 26.2.4 of RFC 3261 [8], SHOULD be used ✨
if a strong end-to-end security means (like the one above) is not available, it is RECOMMENDED that a focus uses mutual hop-by-hop Transport Layer Security (TLS) authentication and encryption mechanisms described in Section 26.2.2 "SIPS URI Scheme" and Section 26.3.2.2 "Interdomain Requests" of RFC 3261 [8] 🌸
8.2. Authorization Considerations 👑
conference apps are literally obsessed with authorization decisions 😭 Mechanisms for establishing and enforcing those rules are a central concept across the whole SIP Conferencing Framework [16]. Since most of the info about a conference can be presented using the conference package, lots of the authorization rules apply directly to this spec too. So a notification server MUST be capable of generating distinct conference information views for different subscribers, depending on the subscriber's role in a conference, personal access rights, etc. All of this is subject to local authorization policies and rules 🧚
a focus gives out participant identity info using this event package, so participant privacy has to be taken seriously 🙈
a focus MUST support requests by participants for privacy. Privacy can be indicated by the conference policy, either for every participant or for select participants. It can also be indicated in the session signaling. In SIP, that's done with the Privacy header field described in RFC 3323 [11] 💜 For a participant who requested privacy, no identity information SHOULD be revealed by the focus in any included URI (e.g., the Address of Record, Contact, or GRUU). For these cases, the anonymous URI generation method outlined in Section 5.6 of this document MUST be followed 🦋
9. IANA Considerations 🌈
this document registers a SIP event package, a new MIME type called application/conference-info+xml, a new XML namespace, and a new XML schema. It also creates a sub-registry "URI purposes" under the existing registry: http://www.iana.org/assignments/sip-parameters 🎀
9.1. conference Event Package Registration 🍓
this spec registers an event package, based on the registration procedures defined in RFC 3265 [10]. Here's the info required for that registration:
Package Name: conference
Package or Template-Package: This is a package.
Published Document: RFC 4575
Person to Contact: IETF SIPPING Working Group <sipping@ietf.org>, as
designated by the IESG <iesg@ietf.org>9.2. application/conference-info+xml MIME Registration 💅
MIME media type name: application
MIME subtype name: conference-info+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [7]
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [7]
Security considerations: See Section 10 of RFC 3023 [7] and
Section 8 of this specification
Interoperability considerations: none
Published specification: This document
Applications which use this media type: This document type has been
used to support SIP conferencing applications
Additional Information:
Magic Number: None
File Extension: .xml
Macintosh file type code: "TEXT"
Personal and email address for further information: IETF SIPPING
Working Group <sipping@ietf.org>, as designated by the IESG
<iesg@ietf.org>
Intended usage: COMMON
Author/Change controller: IETF SIPPING Working Group
<sipping@ietf.org>, as designated by the IESG <iesg@ietf.org>9.3. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:conference-info 🧚
this section registers a new XML namespace, following the guidelines in RFC 3688 [21] ✨
URI: The URI for this namespace is
urn:ietf:params:xml:ns:conference-info
Registrant Contact: IETF SIPPING Working Group <sipping@ietf.org>,
as designated by the IESG <iesg@ietf.org>
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Conference Information Namespace</title>
</head
<body>
<h1>Namespace for Conference Information</h1>
<h2>urn:ietf:params:xml:ns:conference-info</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4575.txt">
RFC4575</a>.</p>
</body>
</html>
END9.4. XML Schema Registration 💖
this spec registers a schema, following the guidelines in RFC 3688 [21] 🥹
URI: please assign
Registrant Contact: IETF SIPPING Working Group <sipping@ietf.org>,
as designated by the IESG <iesg@ietf.org>
XML: The XML can be found as the sole content of Section 6.9.5. URI Purposes Sub-registry Establishment ✨
IANA made a brand new sub-registry called "URI purposes" 🎀. It lives under the registry that's already there at http://www.iana.org/assignments/sip-parameters, so it's giving organized 📋.
So here's the deal 💅: the purpose of a URI is an XML element that gets encoded in the conference event package from RFC 4575. The <purpose> element tells you what the URI is actually for in that event package context, and the definitions live in Sections 5.3.1 and 5.3.2 of this spec 🦋.
The sub-registry is a table with three columns:
- Value: the token being registered 🏷️
- Description: a text explaining what the URI is meant to be used for 📝
- Document: a reference to the document that defines the registration 📚
IANA set up the table with these starting values 🌈:
Value Description Document
------- ---------------------------------- ----------
participation The URI can be used to join the [RFC 4575]
conference
streaming The URI can be used to access the [RFC 4575]
streamed conference data
event The URI can be used to subscribe [RFC 4575]
to the conference event package
recording The URI can be used to access the [RFC 4575]
recorded conference data
web-page The URI can be used to access a [RFC 4575]
web page that contains additional
information of the conferenceOkay, the rules for adding new stuff 🔥: new values of "URI purposes" get registered by IANA, and they're specification required under RFC 2434 [4]. That means whoever wants a new value has to write a spec for it. The IANA Considerations section of that spec MUST include the following information 👑:
- Value: the
<purpose>element value being registered 🍓 - Description: a short description of what the URI is meant to do 💜
10. Acknowledgements 🫶
The authors want to thank Dan Petrie, Sean Olson, Alan Johnston, Rohan Mahy, Cullen Jennings, Brian Rosen, Roni Even, and Miguel Garcia for their comments and input 💖. You all are literally the MVPs 👑✨.
11. References 📚
11.1. Normative References 🔒
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[7] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[10] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[11] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[12] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[13] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[15] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[16] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[17] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
11.2. Informative References 🧚
[18] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[19] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[20] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme Registration", RFC 3508, April 2003.
[21] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[22] Saint-Andre, P., "A Uniform Resource Identifier (URI) Scheme for the Extensible Messaging and Presence Protocol (XMPP)", Work in Progress, December 2004.
[23] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[24] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, May 2006.
[25] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
Authors' Addresses 🏠
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027
US
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Orit Levin (editor)
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
EMail: oritl@microsoft.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧾
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 💜
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🌸
📦 where this page comes from
- ietf: rfc4575 2006-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms