Title Subtitle

1

XCON WG Interim Meeting Boston, Jan 5-6th, 2005
XCON Framework Overview Issues Editors
Mary Barnes (mary.barnes_at_nortelnetworks.com)
Chris Boulton (cboulton_at_ubiquity.net)
Orit Levin (oritl_at_microsoft.com)
2
Overview

• Part 1 - Wednesday
• Current status of XCON framework document
• Proposed Data Model
• Issue Discussion
• Part 2 - Thursday
• Updates based on meeting agreements
• Way Forward

3
Current Framework Status

• Total re-write from -00 version based on IETF-61
  discussions.
• Terminology and descriptions are protocol
  agnostic in terms of call control signaling.
• Centers on Data Model (types and objects)
• No duplication of content from SIPPING
  Conferencing Framework (section 8 intended to
  address relationship)
• SIP used only as an example protocol, however,
  objective is to ensure that basic conferencing
  functionality for SIP is not impacted.
• Current version intended to provide the baseline
  terminology, model and high level interfaces
  (including protocols) -gt more work definitely
  required to describe detailed functionality once
  basics are agreed (hopefully today).

4
XCON System Decomposition
Logical XCON Server

• TEMPLATE
• Of the SYSTEM
• Pre-configured
• Initial/Default values

• TEMPLATE Policy
• Of TYPE RULES

• RESERVATION
• Of the INSTANCE
• Of TYPE CONFERENCE-INFO

• RESERVATION Policy
• Of TYPE RULES

• CURRENT Policy
• Of TYPE RULES

• STATE
• Of the CURRENT INSTANCE
• Of TYPE CONFERENCE-INFO

CCCP Server

• Conf Event
• Notification
• Server

• CPCP
• Server

• Floor
• Control
• Server

Focus
SIP/ PSTN/ H.323 T.120/ Etc.
SIP NOTIFY/ Etc.
CCCP
CPCP
BFCP
CPCP Client
CCCP Client
Notification Client
Floor Control Client
Call Signaling Client
Logical XCON Client
5
Basic Data Objects
Conference Definition, Creation, Lifetime
6
Issues Terminology

• What do we call a Conference Specific Instance?
• State can be confusing because each of the
  conference objects has its own state (not a
  conference instance only)
• Proposal Occurrence.
• Mixing pattern - type defined to abstract the
  details of the media mixer.
• Pending the TEMPLATE issue resolution
• Pattern concept can be used not for mixing
  only, but also for abstracting other advanced
  features, such as user input pattern, etc.
• Focus - do we need a new (enhanced) definition
  for XCON?
• Multimedia Stream
• Defined as the union of the set of media (in the
  context of FW)
• Keith Ls proposal that a stream shouldnt
  consist of multiple media propose to be
  consistent with RTP.
• Proposal be consistent with RTP or remove
  definition altogether as its only referenced in
  the context of RTP and the use of the signaling
  interface to manipulate.
• Define others and use consistently
• XCON Server
• XCON client
• .

7
Issue Data model and Template

• The current framework approach
• Conference Information Type is an umbrella for
  all conference information
• Media pattern is a subtype (or set of subtypes),
  each registered with IANA and used by the
  conference information type. (Note, issue raised
  over terminology Mixing pattern)
• Template, reservation and instance are data
  objects - all of the same Conference Information
  type.
• Brians alternative approach
• Template is the top type which includes all other
  possible conference information
• XCON will define multiple templates and register
  each with IANA
• In order to create a reservation or a conference
  instance, an XCON server needs to apply a
  separate set of ranges and policy rules to one of
  the standard template.xsd.
• Proposal To be discussed later today?

8
Issue Recurring Conferences

• Agreement on the need to be able to schedule a
  conference.
• Need to tighten definitions of reservation and
  state supporting this functionality
• Need to introduce naming conventions
• When the state (or the instance) begins with
  the Focus creation.
• Lack of agreement on the recurrence of a
  scheduled conference being in scope (i.e. it
  seems to be more of an application problem than
  XCON problem).
• Proposal Data structures and naming conventions
  should support the concept of a
  recurring/scheduled conference.
• Proposal The application mechanisms to cause the
  instantiation based on the recurrence are out
  of scope as for now.

9
Issue Policy Rules

• What is the format of the rules in XCON?
• XCON framework assumes that the common policy
  framework is the basis for the rules in XCON.
• What parts of CPCP XML schema remain and what
  need to be removed to support the XCON model?
• To be discussed later during separate discussion
  on Policy.

10
Issues addtl mailing list feedback

• How is a conference created?
• Who/what does a client talk to?
• How is reservation created?
• Floor control
• Suggestions that more detail is required.
• Other suggestion that there is too much detail
  (perhaps due to needing more detail in other
  sections of section 5?).
• Specific points
• input access - gt gain access to resources that
  are limited.
• Dont necessarily need to be a participant to be
  floor chair (however, participant doesnt have to
  be involved in media mixing).

11
Issues addtl mailing list feedback

• Terminology
• General consistency and definition of terms for
  referring to Conference state, data, information,
  rules, etc.
• XCON Server proposed as a general term to use
  consistently throughout
• Conference Policy more general, less data
  object centric definition
• .
• Section 8 XCON relationship to SIPPING Conf FW
• Should this be earlier in the document?
• Needs to be completed (Diagram in backup charts
  needs refining).
• Many other detailed points on consistency and
  clarifications needed.

12
Other Issues

• Conf announcements and recordings
• Sidebar
• Whisper not in scope?

13
Part 2

• Updates based on meeting agreements
• Additional Work items
• Way Forward

14
XCON System Decomposition
Updated Logical names. Corrected
directionality. Added logical grouping of data
Conference System
Conference-Object

• TEMPLATE
• Of the SYSTEM
• Pre-configured
• Initial/Default values

TEMPLATE Policy
RESERVATION Of the INSTANCE
RESERVATION Policy
CURRENT Policy
STATE Of the CURRENT INSTANCE
Data Manipulation Server

• Conf Event
• Notification
• Server

• Floor
• Control
• Server

Focus
SIP/ PSTN/ H.323 T.120/ Etc.
SIP NOTIFY/ Etc.
BFCP
Data Manipulation Client
Notification Client
Floor Control Client
Call Signaling Client
Client
15
Basic Data Object
Conference Definition, Creation, Lifetime
Conference-Information Type
Conference Description
No changes Agreed. Generally, support the
notion to collapse the objects into a single
object (per logical grouping on previous
chart Authors feel theres value in separation
In understanding functionality.
Membership (Roles, Capacity, Names)
Signaling (Protocol, Direction, Status)
Sidebars (and other attributes)
Conference Template
16
Issues Terminology

• What do we call a Conference Specific Instance?
• State can be confusing because each of the
  conference objects has its own state (not a
  conference instance only)
• Proposal Occurrence.
• Conclusion Conference Object.
• Mixing pattern - type defined to abstract the
  details of the media mixer.
• Pattern concept can be used not for mixing
  only, but also for abstracting other advanced
  features, such as user input pattern, etc.
• Conclusion Subsumed by Conference Template
• Focus - do we need a new (enhanced) definition
  for XCON?
• Conclusion need a more general definition for
  XCON. Proposal
• Focus The focus is a call signaling endpoint
  that is addressed by a unique conference
  identifier. The focus maintains a call signaling
  relationship with each participant in the
  conference. The focus ensures, in some way, that
  each participant receives the media that make up
  the conference. The focus also implements
  conference policies. The focus is a logical
  role.

17
Issues Terminology

• Multimedia Stream
• Defined as the union of the set of media (in the
  context of FW)
• Keith Ls proposal that a stream shouldnt
  consist of multiple media propose to be
  consistent with RTP.
• Proposal be consistent with RTP or remove
  definition altogether as its only referenced in
  the context of RTP and the use of the signaling
  interface to manipulate.
• Conclusion Agreement to remove definition until
  we actually reference.
• Define others and use consistently
• XCON Server Conclusion Use general term
  conferencing system
• XCON client Proposal Use term
  ltprotocolgt client
• .

18
Issue Data model and Template

• The current framework approach
• Conference Information Type is an umbrella for
  all conference information
• Media pattern is a subtype (or set of subtypes),
  each registered with IANA and used by the
  conference information type. (Note, issue raised
  over terminology Mixing pattern)
• Template, reservation and instance are data
  objects - all of the same Conference Information
  type.
• Brians alternative approach
• Template is the top type which includes all other
  possible conference information
• XCON will define multiple templates and register
  each with IANA
• In order to create a reservation or a conference
  instance, an XCON server needs to apply a
  separate set of ranges and policy rules to one of
  the standard template.xsd.
• Conclusion Concluded check minutes.

19
Issue Recurring Conferences

• Agreement on the need to be able to schedule a
  conference.
• Need to tighten definitions of reservation and
  state supporting this functionality
• Need to introduce naming conventions
• Conclusion will need a reference (handle to
  instance) to an ical thing (eg. Time range)
• When the state (or the instance) begins with
  the Focus creation. Conclusion Implementation
  issue
• Lack of agreement on the recurrence of a
  scheduled conference being in scope (i.e. it
  seems to be more of an application problem than
  XCON problem).
• Conclusion ical object used to describe time.
• Conclusion ical proposed as the required
  mechanism to be referenced (i.e. XCON wont
  define any ical extensions).

20
Issue Policy Rules

• What is the format of the rules in XCON?
• XCON framework assumes that the common policy
  framework is the basis for the rules in XCON.
• What parts of CPCP XML schema remain and what
  need to be removed to support the XCON model?
• To be discussed later during separate discussion
  on Policy.
• Conclusion Use ranges to control limits on
  values
• Conclusion Use list format described in minutes
  to control membership and permissions

21
Issues addtl mailing list feedback

• How is a conference created?
• Who/what does a client talk to?
• How is reservation created?
• Conclusion Need to add text to address this
  concept per earlier discussion
• Floor control
• Suggestions that more detail is required.
• Other suggestion that there is too much detail
  (perhaps due to needing more detail in other
  sections of section 5?).
• Specific points
• input access - gt gain access to resources that
  are limited.
• Dont necessarily need to be a participant to be
  floor chair (however, participant doesnt have to
  be involved in media mixing).
• Conclusion ensure that the text is consistent
  with BFCP doc. Security aspects need to be
  addressed (e.g. nonce from CPCP)

22
Issues addtl mailing list feedback

• Terminology
• General consistency and definition of terms for
  referring to Conference state, data, information,
  rules, etc. Conclusion Agree that changes are
  needed
• Conferencing Server proposed as a general term to
  use consistently throughout (rather than XCON
  server, etc.)
• Conference Policy more general, less data
  object centric definition.
• Proposal Conference Policy The complete set of
  rules for a particular conference manipulated by
  a CPCP server. The conference policy is used to
  specify and control the operation of a conference
  occurrence, reservation and template.
• Section 8 XCON relationship to SIPPING Conf FW
• Should this be earlier in the document?
• Needs to be completed (Diagram in backup charts
  needs refining).
• Conclusion Complete the section and then decide
  whether it makes sense to move earlier in the
  document.
• Conclusion Agree that need some minimal
  introductory text to set the context for the XCON
  FW (without duplicating functionality defined in
  SIPPING Conf FW).
• Many other detailed points on consistency and
  clarifications needed.

23
Additional work items to incorporate

• Need scenarios/flows to highlight how the XCON
  functional elements work together and more
  importantly how a UA interfaces to the elements
  to achieve the desired functionality.
• Add some full physical realization EXAMPLES with
  a mix of XCON functions and existing protocols ?

24
Way Forward

• Plans are to update doc based on mailing list
  discussion thus far and meeting conclusions.
• Is the general direction of the document
  sufficient to agree this as a WG document?

25
Backup

• Diagram SIP/XCON relationships

26
Basic model

• CPCP
• Server

Conf Policy

• System Templates
• Pre-configured
• System/mixer limits
• Templates supported

CCCP Server
Floor Control Server

• Template
• Pre-configured
• Initial/Default values

• Conference Rules
• Policy
• Privileges
• Allowed media

• Conference Rules
• Policy
• Privileges
• Allowed media

Basic CONF FW
Conf Aware Participant 1
Updates During Conf
Applied during Conf Instantiation
Conf Instantiation
Conf Unaware Participant 2
Focus
Conf State

• State of Current Instance including
• Members
• Media details

• Conf
• Notification
• Server

Conf Unaware Participant 3
Signaling I/F not defined by XCON (e.g.
SIP) Data I/F Signaling I/F - defined by XCON
XCON DATA