Conference state is described by a single , which contains a number of optional child elements, namely, in order, a conference description (), information about hosts (), conference state (), users (), sidebars () and possible extensions. Datatypes and other details are defined by the schema.

The element describes the overall state of the conference and contains the , , and child elements, all of which are optional. The element specifies the current number of users participating in the conference. Each element is similar to the described earlier, containing an element for each role, including the "any" role for the total participant count. The boolean element, with content "true" or "false", indicates if the conference is active or not. A conference is active if using one of in a call signaling protocol establishes a session between the user and the conference focus. The boolean element indicates whether the conference is currently locked. If a conference is locked, no new users can join the conference, but participants may leave or be removed from the conference.

This type defines a sequence of child elements, each of conference-medium-type. This type defines the 'state' attribute which can contain the values "full", "partial", or "deleted". This attribute indicates whether the element of conference-media-type contains all existing entries ("full"), only the entries that have changed since the previous notification ("partial"), or that the included entries have been deleted from the conference document ("deleted"). This type defines an extendable sequence of the following child elements. 5.5.1 This type defines the 'id' attribute, which is the media stream identifier being generated by the notification server such as its value is unique among all entries in the parent container. This attribute is the key to identify media streams in the container. Note, that the entries can be added and deleted on dynamic basis during the conference and the changes being reported in the conference state notifications. This element contains the following elements: , , elements. The element describes the media stream. The element identifies the media type of the media stream, with values drawn from the values registered for "media" of SDP [3].

The element 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 SDP "label" media attribute defined in [21].

The element may have the following attributes: This 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 participants, the focus must ensure that each anonymous URI is unique. The guidelines for generating anonymous URIs in RFC 3323 [9] should be followed. For example, "Anonymous1" could be used for a participant requesting privacy. The user element defines an extendable sequence of the following child elements. The element describes the user, e.g., providing his or her name. The element contains URIs associated with the user. [XXX Unclear what this is for.] The element enumerates the roles that the participant is playing in the conference, drawn from the set XXX. The element describes the language preference for the user, expressed in the same format as the Accept-Language string. [XXX] This information MAY be derived from call signaling. The element contains a conference URI for users that are connected to the main conference as a result of focus cascading. In accordance with the SIP conferencing framework [18], 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 event package alone. Advanced applications can construct the graph by subscribing to both this package and the Dialog Package [19] of each cascaded focus and correlating the relevant information. [XXX unclear]. Each entry can contain one or more endpoint elements enumerating all the signaling end points that the participant

The element contains information about an endpoint of the parent . The element can have unbounded number of appearances for each user participating in the conference. The first mandatory key 'entity' of an specifies one of the user devices. Potentially, each device can establish multiple call signaling sessions with the conference focus simultaneously. The secondary optional key 'call-id' can be included by the notification server in order to provide status information for each call signaling session of the endpoint individually. Each subscriber MUST be prepared to receive under a multiple elements with the same 'entity' value and different 'call-id' values. In a conferencing system where authentication is performed per endpoint (rather than per user), a focus is not necessarily aware of the logical association of multiple endpoints under a common user. In this case, the focus would arrange the endpoints as belonging to separate users in the conference document. Note, that typically in this case, a would contain a single with their 'entity' attributes having the same value. In a different case, due to privacy concerns for a participant, a focus may choose to shield the information about the participant's multiple endpoints from the third-party subscribers. To do so, the focus MAY aggregate the multiple endpoints' information into a single element under the participant's . Note, that in this case the notification server can still include the secondary 'call-id' key and provide the information for each call signaling session individually.

The element can contain the following attributes: The entity attribute contains the endpoint URI for the 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 endpoint belonging to an anonymous participant in a conference SHOULD be represented by a unique anonymous URI generated according to RFC 3323 [9]. This attribute is optional and its usage is a subject to the server's policy per subscriber. The value of this attribute is a numeric index, which is unique for each call signaling session of the parent endpoint. This attribute is used when the server needs to provide call signaling information for each signaling session (also known as a call or a dialog) between the endpoint and the focus individually. If 'call-id' is not included, it means that the server chose providing call signaling status of the collectively for (potentially multiple) call signaling sessions between the endpoint and the conference focus. [XXX Unclear what this is for] This type defines an extendable sequence of the following elements: , , , , , The element contains text describing the endpoint, meant for human consumption. The element contains information about the entity that introduced the endpoint to the conference. For SIP, this entity send a REFER request to the focus that contained the participant URI. The following child elements are defined: This element contains the date and time that the endpoint was referred to the conference and SHOULD be expressed in Coordinated Universal Time (UTC) format. This element contains the reason the endpoint was referred to the conference. [XXX text?] This element contains the URI of the entity that caused the endpoint to be referred to the conference.

The current status of the endpoint is described by the element: The endpoint is a participant in the conference. Depending on the media policies, he/she can send and receive media to and from other participants. The endpoint is not a participant in the conference and no active dialog exists between the endpoint and the focus. An active SIP dialog exists between an endpoint and a focus, but the endpoint is on hold for this conference, i.e., neither receiving the conference media, nor contributing to the conference media mix. For example, an endpoint has asked to join the conference using SIP, but his or her participation is waiting for moderator approval. The endpoint might be receiving music-on-hold during that time. An active SIP dialog exists between the endpoint and the focus and the endpoint can receive conference media, but cannot contribute media to the conference media mix. Note that sometimes a subset of endpoint 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" endpoint connectivity reflects the status of the most active media stream. The endpoint is not yet in the session, but it is likely that he or she will be joining in the near future. The endpoint is being alerted, i.e., a focus-initiated PSTN call is ringing or a SIP call has returned the "180 Ringing" status message. The endpoint is connecting to the conference, but not yet in the roster, e.g., because it is being authenticated. The focus has dialed out to connect the endpoint to the conference, but the endpoint is not yet the roster, e.g., it is being authenticated. The focus is in the process of disconnecting the endpoint from the conference, e.g., by sending a SIP BYE request to the endpoint. Since delivering updates containing transient status types such as "disconnecting" or "alerting" could generate a lot of notifications, implementations MAY choose to suppress notifications of such state changes.

The element describes the method by which the endpoint joined the conference: The endpoint dialed into the conference by sending a SIP INVITE request to the focus, which resulted in successful dialog establishment. The focus has brought the endpoint into the conference by sending a successful SIP INVITE request to the endpoint. The endpoint is the focus for this conference. This status is used only when a participant's UA acts as a conference focus. The element describes how the endpoint joined the conference and can contain the following child elements: This element contains the date and time that the endpoint joined the conference and SHOULD be expressed in Coordinated Universal Time (UTC). This element contains the reason the endpoint joined the conference, as free text. This element contains the URI of the entity that caused the endpoint to join the conference.

The optional element describes the method by which an endpoint with status "disconnected" departed the conference, and can assume the following values: The endpoint sent a SIP BYE request to leave the conference. The endpoint was sent a SIP BYE request by the focus, booting it out of the conference. Alternatively, the endpoint tried to dial into to conference but was rejected by the focus. The focus tried to bring the endpoint into the conference, but its attempt to contact the specific endpoint resulted in a non-200 class final response. Alternatively, the endpoint tried to dial into the conference without success. The element contains information about the endpoint's departure from the conference and can contain the following child elements: This element contains the date and time that the endpoint departed the conference and SHOULD be expressed in Coordinated Universal Time (UTC). This element contains the reason the endpoint departed the conference. It is RECOMMENDED to include the information as reported by the call signaling in the format defined by RFC 3326 . For example, Reason: SIP ;cause=415 ;text="Unsupported Media Type" The URI of the entity that caused the endpoint to depart the conference.

The element contains information about a media stream of the endpoint. The element of the media-type can have an unbounded number of appearances in the endpoint-type for each media stream of the endpoint. Note, that if the 'call-id' attribute of the endpoint is not provided by the server, it is possible that the media streams listed under the common endpoint were established by separate signaling sessions, i.e., belong to different "calls" or "dialogs". [XX unclear]

The element provides detailed call signaling information for a call between the endpoint and the focus. Privacy policies MUST be consulted before revealing this information to third-party participants. The element MAY be used only if the server chose to explicitly identify each signaling session between the endpoint and the focus by including the 'call-id' attribute as the secondary key. The child element contains the SIP dialog identifier of the endpoint's dialog with the focus, described by the , , , and child elements. In the future, the element may be expanded to include call signaling protocol information for protocols beyond SIP.

This element contains the 'id' element-specific attribute. The attribute is the media stream identifier being generated by the notification server such as its value is unique in the endpoint context. This attribute is the key to identify media streams which can be added and deleted on dynamic basis during the conference and the changes being reported in the conference state notifications. The element contains a sequence of child elements, namely , , , and . The element describes the media stream. The element contains the media type for media stream. The value of this element MUST be one of the values registered for "media" of SDP [3] and the corresponding IANA registry. The element 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 SDP "label" media attribute defined in [21]. The element can be used to carry information about the media source. It is currently only defined for RTP media [12] and is OPTIONAL. For RTP media streams, the element contains the SSRC value used by the endpoint for its media streams. The information can be used by participants to map the CSRC information in RTP packets to identify the current speakers. (An RTP mixer generates the CSRC list in the RTP packet header by inserting a list of the SSRC identifiers of the sources that contributed to the generation of a particular 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)." [12] The element indicates whether the participant is sending, receiving or both. It has one of the values "sendrecv", "sendonly", "recvonly", or "inactive", as defined in SDP [3]. The value reflects the view of the participant. For example, a participant with a muted stream will have the value of "recvonly".