XCON architecture and protocol musings

1. XCON architecture and protocol musings Henning Schulzrinne Columbia University

2. Basic assumptions • Minimal “atom” of conference • compose from simple descriptions to build side bars, recurring meetings, policies • Scheduling handled externally • scheduling system references instances (needed in any event) • XCON protocol reference time slots (see later) • No XCAP for manipulation, but allow whole document as input to transfer or initialize state • No separation between CPCP and CCCP • “Flat” documents, rather than deeply layered ones • Changes of limits (or rules) don’t affect current state • Support simple MCUs that are ignorant of time

3. Disagreements with current XCON model • No separate terms (definitions) for template, reservation, instance • template = inherited conference state • reservation = conference definition in latent state • instance = conference in latent or active state • No separate protocol for CPCP • just a document instance

4. Conference state • active = mixing media (but not necessarily) • mixing media OR active focus URI  active, but • might be not mixing media and still be active • focus must be responsive to signaling • we do not determine the precise transition latent  active • implementation choice • latent = not active, not mixing media • can only change parameters for future instances • can change media mixing, but no effect on media flows • can’t send focus session control messages

5. Tree  inheritance Each level can be addressed via a URL Each layer links to parents and children Lowest layer information wins Parent can designate variables that cannot be overridden (“forced global”) Easily supports (corporate) policies recurring events with exceptions modifying the active conference only Probably also supports side bars and other multi-policy configurations permanent text chat rooms Each node can reference scheduling information but may not The conference tree all Acme Widget conferences weekly eng. mtg. instance 1

6. Instance notion • A conference MCU (mixer) “works with” a particular state document for an active conference • It doesn’t care that there are other documents • These other (latent) documents can be manipulated via the conference control protocol, via the hierarchy (affecting one, some or all) • Single active instance for each conference • Focus URI can be specific or generic – it’s inherited like other parameters • an instance can have multiple URIs (e.g., tel:, h323: or sip:) • Focus URI can be disambiguated by time, caller, etc.

7. Scheduling • By value • include actual time + date specification • SDP model: allow multiple specifications • e.g., SDP recurrence, iCal spec • By reference • link to calendar objects (opaque) • ask calendar for object and then modify object returned via conference control protocols

8. Media – the “bus” notion • Analog and digital audio and video mixers have the notion of a bus • Each input can be assigned to one or more buses • Buses have provision for “effect processor” (aux send/aux return) • Proposal: adopt this model – simple named buses and assign media streams to it • same fashion as SDP floor designation

9. Control Protocol • Avoid protocols that require transaction semantics • e.g., XCAP - update any subset of the conference document • Avoid re-inventing SOAP (or other full RPC protocol) • Re-use existing security mechanisms • Real need for XML? • Model: get/set parameters + provide whole document instantiation • Options: • SOAP • XML-RPC • IMAP/POP (SASL) • TCP (or TLS) single-line requests • status responses

10. Calendaring • query for date set within instance • get back a handle (URI) for that subset