XCON architecture and protocol musings Henning Schulzrinne Columbia University

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

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

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

The conference tree 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 all Acme Widget conferences weekly eng. mtg. instance 1

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.

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

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

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

Options SOAP with extensions mechanisms –all templates specify parameter (interface) extensions or new RPC Hierarchical parameter only

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