conference object, instance, class, variable conference control client (CCC) = Entity (user or program) that controls aspects of the conference. Overview Centralized conferences maintain state about members and their media exchange relationships at a single logical point in the network. Media streams may be either mixed in a conference mixer or in end systems, or some combination thereof. For simplicity, the qualifier "centralized" is implied when this document discusses conferences. We distinguish two kinds of conferences in this framework, namely ad-hoc conferences and planned [?] conferences. Ad-hoc conferences are created when a signaling client sends a request to the focus (see below) and creates a conference named after the signaling URI. Planned conferences are created by a conference control protocol. A centralized conference is described by a conference description. Such a description contains all necessary information to invite or admit participants, to route and mix media and to perform other operations necessary for a conference, including policy information indicating who can perform such operations. We re-use the terminology of objected oriented programming languages such as Java, even though implementations may not necessarily use such languages. Conference descriptions are similar to classes, incorporating a set of data elements and operations on these elements. This document assumes the existence of a base class shared by all implementations, extended by derived classes. [CHECK TERM!] The abstract data type of a conference is either a basic conference (Section X) or a data type that derives from that basic conference by adding additional variables. In analogy to OO programming, we call the data type and inherited data types conference classes. A conference description instantiates variables in the class. It can leave some variables undefined. A conference instance may have a starting and ending time. It does not repeat. The ending time is specified relative to the starting time. A conference is called "active" if wall clock time falls between its starting and ending time. Thus, only conference objects with a starting time can become active. An active conference is said to possess conference state, which includes all conference description variables as well as other information, such as the number of active participants and the current media mixing matrix. Conference descriptions are identified by URNs. * Interacting with the Conference Participants interact with the conference system in four ways: they send media to zero or more conference mixers, they send signaling requests to the conference focus, they exchange floor control messages and, if they are conference control clients, they send conference control commands to the conference server. For a single conference instance, these four entities can be different hosts. * Inheritance We allow conferences to inherit some of their attribute values from a parent conference, so that conference descriptions can form a tree. Conference descriptions refer to their parent by the parent's conference URN. A conference can only have a single parent and only conferences at the leaf of such a tree can have a start and end time. Changing the value of a variable in a conference description changes the variable value in all conference descriptions that have that description as a parent, either directly or indirectly, unless a child node defines a variable itself. There is one exception to the inheritance rule. A parent may declare a particular variable or group of variables as "sticky". The sticky variable closest to the root of the tree determines the actual value of the variable. A parent description can reside at a different server than its children. Since the references are URNs, the physical location of a description can change over time without having to re-build a tree. This type of inheritance is effective when the conference is active, while the inheritance of the abstract data types discussed above defines the static data types of a conference as derived from the basic conference class. * Scheduling Conferences Recurring conferences are scheduled by including a reference to a conference description, i.e., a URN, in an iCal object. The conferencing system then creates a conference object for each time interval within the recurrence. The object is created no later than the start time of each recurrence, or when a conference control client changes one instance of the recurrence. All instances belonging to a single recurrence have that recurrence as their parent. The conferencing system should provide a mechanism to uniquely locate each instance by a combination of the URN identifying the recurrence and its starting time (GMT). * Conference Signaling URI (CS-URI) Each active conference instance has one or more conference signaling URIs (CS-URIs) that identify the focus for the conference and allow conference participants to send signaling requests to the conference. For each signaling protocol, there must be no more than one [?] conference signaling URI. These URIs are created by the conferencing system at any time prior to the beginning of the conference; in some cases, the conference control client may choose the CS-URI. In an ad-hoc conference, the signaling protocol creates the CS-URI and the corresponding conference object. Conferences that can be controlled via the PSTN offer the tel URI as one of their CS-URIs. * Basic Conference The basic conference description contains information about - the URLs of the conference focus; - initial media streams and their rendering; - the identities of moderators allowed to control the floor; - [other missing things] - the identity of users that can read and write the information above.