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) dont 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
• cant send focus session control messages

5
The conference tree
all Acme Widget conferences

• 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

weekly eng. mtg.
instance 1

• Each node can reference scheduling information
• but may not

6
Instance notion

• A conference MCU (mixer) works with a
  particular state document for an active
  conference
• It doesnt 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 its
  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
Options

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

11
Calendaring

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