Media Control Policy Chris Boulton, Umesh Chandra, Roni Even, Cullen Jennings, Alan Johnston, Brian Rosen, Mark Trayer

We started with two approaches Rohan’s “Flow Graphs” approach Cullen and Brian’s “Template” approach We decided to do both – All conference servers will support templates, which are predefined – Some may support flow graphs, as a way of essentially dynamically creating a template

Team fleshed out the template idea New draft includes the template language and worked out concepts for roles, streams, controls, etc. Includes a starter set of template definitions – This will be excerpted into a separate draft in the next revision

Templates A template is a description of the – Roles one can assume – Streams one can source or sink – Controls one has over the streams – Parameters specializing a template for use The template describes how one builds a user interface to control a conference using that template Media Policy Control Protocol primarily is concerned with manipulating the controls defined by the template A conference is defined with the template to be used, which must be supported by the conference server, and the values of the parameters of that template Clients can be built to implement a set of templates which would have good user interfaces The template language is defined such that a client could render a reasonable UI for a template it did not directly implement. Open Issue: Can templates be derived from another template.

Use of templates Conference server offers a list of templates it supports Convener selects one template and specifies parameter values Participants learn the template in use which determines the UI they offer Participants and conference server exchange XML subsets of the template to manipulate controls Open Issue: Transport (assume XCAP)

Templates Defined in an XML form in a public document Have an IANA registered name the template is known by Have Parameters, which are variables used to define some flexibility in the templates – Parameter values are fixed before the conference is instantiated – Fundamentally used to limit the number of templates required to describe a range of similar conference capabilities Define Roles, Streams, Controls, and Lists

Roles Template defines the allowed roles – CPCP used to define permissions, actually assume roles, announce role changes, etc. Roles can define streams (source or sink) and controls that are only available to participants currently in the role – Implies that the streams and controls you have can change dynamically as your role changes Roles can be defined hierarchically (nested) – Roles defined within a role inherit all the streams and controls that are defined in the enclosing role – Note: Current examples don’t show this

Streams Define the streams a participant sources or sinks to the mixer Defined with a name, a type (audio, video, text) and a direction (in, out) Conference package maps SDP (or whatever) to stream names

Controls UI manipulations of the mixer Defined with name, label, type (integer, real, Boolean, enumeration,…), value, enable, etc. Rendered by the client UI with widgets of some kind, or automatically calculated. Template can include a default (initial) value Clients can change the value while the conference is in progress Clients get notified if the value of a control they have changes Server can change the value if necessary

Floor Control Template defines which floors it has support for, which might be controlled by parameters Templates describe (in English) how the mix changes as a result of floor holder changes Streams and controls may be restricted to only being available to holders of a particular floor Open Issues: Have not synced up with floor control team

Open Issues The flow graph work is not yet defined – Will be a separate draft The complete set of templates has not yet been designed, but this work is started. How the CPCP mechanisms work with templates (e.g. how do controls work)

Proposal Let the design team do one more round

Basic Audio Template

Changing the value of a control