2.8.20 Centralized Conferencing (xcon)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional XCON Web Page

Last Modified: 2005-10-24

Chair(s):

Adam Roach <adam@nostrum.com>
Alan Johnston <ajohnston@tello.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Allison Mankin <mankin@psg.com>

Mailing Lists:

General Discussion: xcon@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/xcon
Archive: http://www.ietf.org/mail-archive/web/xcon/index.html

Description of Working Group:

The focus of this working group is to develop a standardized suite of
protocols for tightly-coupled multimedia conferences, where strong
security and authorization requirements are integral to the solution.
Tightly-coupled conferences have a central point of control and
authorization (known as a focus) so they can enforce specific media and
membership relationships, and provide an accurate roster of
participants. The media mixing or combining function of a
tightly-coupled conference need not be performed centrally, however.

The scope of this effort is intentionally more narrow than previous
attempts to standardize conferencing (e.g. centralized control), and is
intended to enable interoperability in a commercial environment which
already has a number of non-standard implementations using some of the
protocols.

Privacy, security, and authorization mechanisms are integral to the
solution generated by the working group. This includes allowing
participants to be invisible to all but the conference owner, or to be
visible but participate anonymously with respect to some or all of
the other participants.

Authorization rules allow for participants and non-participants
to have roles (ex: speaker, moderator, owner), and to be otherwise
authorized to perform membership and media manipulation for or on
behalf of other participants. In order to preserve these properties,
the protocols used will require implementation of channel security
and authentication services.

Due to the centralized architecture of the WG, XCON's mechanisms will
place requirements on the signaling protocol used between the focus
and
the participants. At a high level, the signaling protocol must be able
to establish, tear down, modify, and perform call control operations on
multimedia streams, including voice, video, and instant messaging, in
both a centralized and distributed mixing architecture. SIP will be
the
reference session signaling protocol used for examples; however, none
of
the XCON solutions themselves will be signaling protocols, nor will
XCON
extend existing signaling protocols. Other signaling protocols than
SIP
may be used between the focus and participants, including non-IETF
protocols, but the requirements and possible extensions needed for
other
signaling protocols to utilize the full functionality of the XCON
architecture is outside the scope of XCON.

The deliverables for the group will be:
- A mechanism for membership and authorization control
- A mechanism to manipulate and describe media "mixing" or "topology"
  for multiple media types (audio, video, text)
- A mechanism for notification of conference related events/changes
(for
  example a floor change)
- A basic floor control protocol

The initial set of protocols will be developed for use in unicast media
conferences. The working group will perform a second round of work to
enhance the set of protocols as necessary for use with multicast media
after their initial publication.

The following items are specifically out-of-scope:
- Voting
- Fully distributed conferences
- Loosely-coupled conferences (no central point of control)
- Far-end device control
- Protocol used between the conference controller and the mixer(s)
- Capabilities negotiation of the mixer(s)
- Master-slave cascaded conferences

The working group will coordinate closely with the SIPPING and
MMUSIC working groups. In addition the working group will cooperate
with other groups as needed, including SIP, MSEC, AVT, and the W3C
SMIL working groups. In addition, the working group will consider
a number of existing drafts as input to the working group.

Goals and Milestones:

Done  Submit Requirements for Basic Floor Control for publication as Informational
Done  Submit Conferencing Scenarios document for publication as Informational
Done  Submit Basic Floor Control Protocol for publication as PS
Mar 2005  Submit Framework and Data Model for publication as PS
Dec 2005  Submit updated future document milestones

Internet-Drafts:

  • draft-ietf-xcon-conference-scenarios-05.txt
  • draft-ietf-xcon-floor-control-req-03.txt
  • draft-ietf-xcon-bfcp-05.txt
  • draft-ietf-xcon-framework-02.txt

    No Request For Comments

    Current Meeting Report

    TUESDAY, November 8th, 2005, 0900-1130
    ======================================
    
     Agenda Bash
                Chairs (5 minutes)
     
    
        * No changes to the agenda for today
    
     Charter: Updating Milestones
                Chairs (10 minutes)
     
    
        * Floor control requirements is in RFC Editor's queue, BFCP is
          back with IESG security comments
        * Still need to finalize framework
        * Need to reset milestones, reflecting changes on WG view for
          media control and membership (now want one protocol)
        * Framework and Data Model next summer, event notification a
          little later, CCID in October, Template and Control protocol
          before 2007
        * Pushing IM-related work until Conference Control Protocol goes
          to IESG
    
     Floor Control: Epilogue
                Gonzalo Camarillo (15 minutes)
                draft-ietf-xcon-bfcp-05.txt
                draft-ietf-mmusic-sdp-bfcp-02.txt
                draft-ietf-xcon-floor-control-req-03.txt
     
    
        * Have comments from IESG, most significant are on security
        * TLS will be mandatory, use comedia to do fingerprint exchange of
          self-signed certs
        * Removing digest mechanism from XCON draft
        * Anyone have a problem with this plan?
        * MMUSIC draft also has point-to-point scenario - if I have
          connection with only digest, how do I continue? Actually, Digest
          is completely removed from XCON - but not from SIP. TLS is for
          BFCP, not for SIP.
        * Do you have to use TLS whether you want security or not? No, but
          TLS will be mandatory - but no one will use it, so the spec is
          fine...
        * Need a new document on BFCP connection without offer/answer,
          would allow digest over TLS, define digest mechanism - any interest?
        * Adam - we need a use case before we start doing this work? Brian
          - the use case is that someone calls you on a telephone...
          Cullen - yeah, we have a use case now
        * Is this document in the timeframe of the XCON protocol? No, not
          very long, matter of months - this document is completely
          independent, can have first draft before Dallas
        * Allison - other draft is critical for people who don't have this
          use case, OK to split it out.. All of these documents have a
          dependency on a TLS draft, Allison will shepherd these.
    
     XCON Framework
                Mary Barnes (45 minutes)
                draft-ietf-xcon-framework-02.txt
     
    
        * Quite a few updates since IETF 63, lots of constructive feedback
        * Most changes refine and clarify terminology - slight
          modifications of definitions, added a few new ones, replaced
          "XCON" with "Centralized Conferencing"
        * This is a really good time to read the document if you haven't
          read it yet
        * Expanded detail on identifiers in an appendix, will probably be
          separate document
        * Did changes/clarifications for Cloning Tree, and removed some
          terms that aren't needed now
        * Floor control section is simplified, details are removed, added
          example on conference creation and reworked security section
        * Conference policies are not addressed in this document. If we
          need a policy infrastructure, it will be FFS
        * Looking at two XML schema structure proposals - new namespace,
          or reuse namespace
        * Down to four candidate protocols, netconf is off the table
        * Don't have explicit requirements for the protocol (they are in
          SIPPING document)
        * Some potential derived requirements - could we make progress by
          abandoning or enforcing them? Will discuss on Wednesday meeting.
        * Still need to define sidebar, whisper, complete detailed
          examples in section 7
        * Need URI schema for conference object and conference user
          identifiers
        * Alternatives proposals for floor control based on templates
          (based on previous WG discussions)
        * Who has read most recent version? A fair number of people,
          silence means something.
        * Brian - probably more than one version remaining, but this
          document is "getting there" - if you have input, send text!
        * Brian - still inconsistent about how many sidebars go with a
          conference, and whether they are associated by reference or by
          value - Mary has a diagram, just needs to produce ASCII art... -
          Brian doesn't care what we do, we just need to pick something
          and move on
    
     XCON Common Data Model
                Oscar Novo (10 minutes)
                draft-novo-xcon-common-data-model-00.txt
     
    
        * Have a conference object and a conference template type
        * XML schema can be extended with templates or future extensions
        * Brian - how many times have we talked about this? If you want to
          add new functionality, you'll do a new software release anyway -
          defining it as "an extension mechanism" is a waste of bits
        * Henning - how to deal with the other reality? - vendors that
          have information we want to convey but don't understand
          ourselves, we will be matching with legacy systems that don't
          have an RFC, etc. We won't have a self-programming conference
          server, at least this isn't likely
        * Orit - Henning's question is about next presentation, so let's
          defer that. Issue about where to put the templates inside the
          schema is that we can't distribute information to conference
          participants until we revise the conference package
        * Brian - but if an RFC defines a template, it defines a package,
          which can be a superset
        * Orit - if we have templates outside, everyone will have a
          different mechanism to extend them
        * Henning - having undefined attributes is complexity we don't
          need today - ditch it, please
        * Orit - suggestion is to take templates outside?
        * Henning - yes
        * Cullen - issue is whether there's an extension in the
          description, or after the closing angle bracket - that's it,
          right? "there is an attribute called 'extension', which is
          extended by RFCs"...
        * Henning - adding "color of tie you have to wear to a conference"
          - how does this work? I'm lost
        * Orit - this schema will use the type from Brian's RFC
        * Roni - schema is based on event package definition - this isn't
          state of conference, it's policy for the conference - can't
          refer to other document because this isn't defined there - how
          does the conference server decide what to do? Could use any of
          five codecs based on policy, how does the server pick one? What
          do you do when the server picks one and a new participant joins
          and doesn't support that codec?
        * Dave - but isn't this negotiated by the endpoints anyway?
        * Roni - but have to know whether to admit endpoint to conference
        * Dave - wouldn't this be in the template?
        * Roni - even without a mixer, there are two ways to solve problem
          of incompatible codecs
        * Mary - this is multi-step, right?
        * Roni - looks like you are going the wrong direction because you
          are using the current state to define the conference, should be
          deriving the conference state from the conference
        * Adam - is this a codec problem or a general problem?
        * Roni - it's a general problem - PIN codes aren't in the event
          package, for instance
        * Orit - XCON has moved away from having the conference object
          contain the state of the conference (for simplicity). This also
          overlaps with conference reservations - only part of the schema
          is relavant, only part is being filled with data.
        * Roni - document doesn't actually say this
        * Adam - would adding elements to this schema address the concern?
        * Roni - yes - document doesn't say this is a superset, and it
          needs to
        * Orit - published document is preliminary, needs to reflect our
          discussion
        * Roni - this schema is the one that will be used by conference
          control protocol, needs all the information needed to create a
          conference, but that's not what you need when the conference is
          running
        * Orit - will send only information which is relevant
        * Adam - sounds like people think things are missing - please iron
          this out on the list rapidly
        * Extensibility of common conference information data - new
          namespace or schema extension? Planning to use schema extension
          - does anyone have opinions?
        * Mary - schema extension is a better option
        * Roni - package in SIPPING doesn't have all the required information
        * Mary - that's why we need to define a new superset that DOES
          have all the required information
        * Cullen - Jonathan had some problems when we discussed this -
          need to look at old draft and remember what these problems were
        * Does everyone agree on second option? We will go this way (no
          objections in the room, please tell us if you DO object)
        * Cullen - need to make sure this will work - if a specification
          requires a SIP URI, and not any URI, this won't work - the spec
          says "this is a SIP URI", it's a little more complicated than
          you're making this
        * Henning - root of discussion is that we have two models of
          inheritance, one being the schema, the other being a conference
          definition - as long as the schema isn't restrictive, this
          should be OK. If we inherit the whole document, we probably need
          to update the corresponding specification
        * Adam - we will reuse and extend as necessary, modulo technical
          showstoppers why this won't work
    
     Conference Package Entensions
                Orit Levin (20 minutes)
                draft-levin-xcon-conference-package-ext-00.txt
     
    
        * "This is the discussion starter"
        * Objectives  - "how?", "what info?", and exposing the main
          objects to external schemas
        * Expect at the end of the day we will merge this draft with
          Oscar's draft
        * The draft is about the XML issues when we extend packages
        * Schemas leave room for extensions using namespaces
        * Extensibility requirements: IETF can extend any schema, vendors
          can extend, multiple namespaces in one XML document, resultant
          document must adhere to valid schema, must be backward-compatible
        * Brian - why do we want to extend an existing object in our
          fundamental specification? What do we gain? Why are we starting
          here? Everyone who implements this object will write new code anyway
        * Orit - if we do this, rest of presentation and discussion will
          still be valid, but - we would like to support clients that have
          already been deployed
        * Adam - is Brian suggesting everything is new schemas?
        * Brian - issue of namespace vs. format used in that namespace. If
          a client implements a multiple packages, they can all be in one
          namespace (as long as we agree on naming conventions). Nobody
          has used our extension mechanism in the objects we've defined.
          XML has recently solved the versioning problem - this argument
          doesn't hold.
        * Naive approach results in invalid XML - example shows what
          happens when you insert another optional element. XML has a
          known extensibility issue. Different applications solve the
          problem in different ways.
        * Jari - Nobody should use this tool - it produces
          non-deterministic schemas. This is about stupid tools, not XML.
        * Cullen - other working groups have had this debate, and absorbed
          12 months - can we take their direction and short-circuit this?
        * Orit - solutions are specific to payloads. Would like to find
          something we can reuse.
        * Cullen - how about just using whatever answer the rest of the
          SIP working groups used?
        * Henning - experience on design team was that only viable way is
          to avoid anything fancy - have new namespaces for new things,
          everything else was complicated. Most of us are not XML experts.
          Anything that requires XML expertise isn't going to work in the
          real world
        * Orit - do you get a new namespace for every extension?
        * Henning - a new "sub-namespace", and this is based on a label
          convention, not on XML, which doesn't support "sub-namespaces".
        * Orit - how does this work with vendor extensions? Is this a
          different namespace, too?
        * Henning - if I extend an RFC, I have a namespace and a schema
          for the extension. You subscribe to event packages, not namespaces.
        * Solution is to include extensions outside of sequences. This
          gives us valid schemas. It works for both standard and vendor
          extensions, even in the same schema
        * Limitation is that extensions order must be known and predefined
          in the .xsd. All proprietary extensions must follow all
          standardized extensions. Vendor extensions must have an
          agreed-upon order if they are supported in a single product
        * Henning - this is creative. I'm completely lost as to what this
          adds beyond having namespaces - gives you the same advantages
          and none of the limitations. What is the justification for this?
          I missed it.
        * Orit - cannot compare the two approaches at this time
        * Henning - can we have the conversation offline?
        * What to add to the basic package - and why...
        * Conference state that will be destributed to subscribers
        * Using the conference package for more than events only...
        * Want to expose the main objects without prefixing each internal
          element
        * Add state, media, endpoint, user-roles, user to schema and make
          them easily accessible without prefixes in XML documents -
          justification is saving bits on the wire for every element of
          the document?
        * Cullen - kind of like this, but could we solve the problem
          another way - do we have to add user? (<<<<<<< sorry, I didn't
          get this part >>>>>)
        * Orit - there are issues to take into consideration, but you
          could do this as an option
    
     Role Definitions for Common Conferencing
                Dave Morgan (15 minutes)
                draft-morgan-xcon-roles-00.txt
     
    
        * Lots of people are defining roles as part of something else -
          want to factor this out
        * Adminstrator, creator, moderator, participant, observer
        * Separate document or part of another draft?
        * Should "presenter" be a role or a state?
        * Brian - worry about interaction with policy if roles and state
          of a participant are kind of fuzzy - need to have participant
          policy separate from roles and states of roles
        * Dave - have given this thought, don't have an answer
        * Cullen - (at least we don't have TWO answers) - can you hold
          more than one role at a time?
        * Dave - yes, but probably goes in a separate document
        * Cullen - what about Administrator and Participant (for example)?
          Roles can change?
        * Dave - that's fine, we have this today and want to accommodate this
        * Cullen - policy for both roles and individual users? I like this
        * Henning - there are several ways to look at this. Assign policy
          to roles? This would simplify things (atomic operations, etc.).
          Hybrid creates opportunities for confusion. Actually think
          hierarchy does matter. Need to know how changes happen
          (participant to observer OK, reverse is not) Administrator can
          create conferences - need to define what operations go with what
          roles, and how transitions happen
        * Keith - is there potential for interactions when you have
          multiple roles?
        * Dave - we can handle the administrator issue, but need to think
          more about details
        * Roni - not sure I agree with Cullen about inheritance - may have
          overlay of featuree. Administrator is a global role, not
          per-conference role
        * Andrew - do administrators need to join conferences? Dave thinks
          so.
        * Andrew - Is a presenter a state?
        * Dave - depends on the template.
        * Cullen - open issues are hierarchical/independent, using roles
          for group permissions. If we go down that path, we probably need
          to be able to create new roles easily.
        * Henning - New roles doesn't require new permissions unless
          permissions are really fine-grained. To the extent possible -
          it's confusing to have too many bits to set, please limit
          complexity by limiting number of roles. Do see division between
          creator and observer, for example - this is about who can inject
          media, etc. Moderator question - can I become a moderator, and
          am I a moderator now - these are two different things (if you
          have two moderators, for example). Same question about presentors.
        * Dave - this is about passing tokens, or the mixing algorithm
          (can both speak, but not at the same time)
        * Orit - want to support Henning's approach and we should define
          privileges per role.
        * Dave - needed to define roles before we could define privileges
          (chicken, egg)
    
     MSRP Centralized Conferencing
                Chris Boulton (10 minutes)
                draft-boulton-xcon-msrp-conferencing-02.txt
     
    
        * Draft written to prove a point ...
        * Most current discussion on voice and video, but framework has
          generic topics - need to prove that this works. MSRP has matured
          as a standard, IM matters, and MSRP isn't voice or video, so
          they went crazy
        * MSRP is peer-to-peer, so XCON server acts as endpoint
        * MSRP Send goes to XCON server, which then distributes it to all
          MSRP sessions
        * Covers Conference and Conference User (with MSRP), text
          sidebars, private messages
        * Doesn't touch MSRP protocol, only applies framework principles
        * Not a priority for the working group, but the authors will keep
          working on the draft
    
     People and Content Video Streams
                Roni Even (10 minutes)
                draft-even-xcon-pnc-00.txt
     
    
        * Providing H.239 principles to SIP with multiple video streams.
          Draft defines conference server behavior
        * Stream semantics based on content attribute from
          MMUSIC-SDP-MEDIA-CONTENT draft
        * Floor control based on BFCP
        * Want to advance this as a BCP, so it can be referenced in H.239
        * Orit - if someone uses MMUSIC definitions for point-to-point...
        * Roni - this is included in the draft
        * Orit - if this is about SIP, shouldn't it go to the SIP working
          group? Why do we need to replicate this work in IETF?
        * Roni - Allison said to bring the draft here, since it includes
          multipoint (and also based on workload in SIP working group)
    
    XCON (Wednesday 15:10 - 16:10)
    ==============================
    
    Agenda bash
    -----------
    
    1510 - 1520  Protocol Selection Discussion
    ------------------------------------------
                 Chairs (10 minutes)
    
    Adam: WG chair introduction to issue. Setting deadlines to the
    discussion. Any proposals not  covered in terms in protocol need
    to be produced by the end of the year. At beginning of  next year
    volunteers to author a document that does an evaluation of the different
    solutions. Goal is to have protocol solution by end of 2006.
    
    Cullen. Like the idea of setting dates. Not keen on an evaluation
    yet. Only proposal on  table that can manipulate the templates (the
    variable part). Other IETF group that did this  evaluation went and
    selected the worst one. We need to evolve all the solutions to meet the
    requirements and then choose the best.
    
    Mary: Need to sort out the most important requirements. Do not think we
    will make progress  with a protocol evaluation phase.
    
    Rohan: Echo. We do not need to decide to do this. Idea of closing input
    is excellent.
    
    Mary: May be best just to pick one solution. Does not matter which.
    
    Jon: This is valid in document by Ted Hardie. If don't know how to make
    a decision, then  this is as good as anything.
    
    Conclusion: Have discussion on list in January opn best way of moving
    forward.
    
    Henning: Be good to have an excutive summary of the particular
    approach. Supportors bring  this forward.
    
    Rohan: If no conclusion to January discussion, chairs should choose the
    approach, and this  should be done well berfore Dallas.
    
    All agreed.
    
    1520 - 1530  CCCP
    -----------------
    
                 Orit Levin (10 minutes)
                 draft-levin-xcon-cccp-03.txt
    
    Orit presenting: Heavily revised as a result of implementation
    experience. A new protocol,  as existing protocols do not meet the
    requirements. Not data manipulation (like XCAP or  WebDav) but rather
    object manipulation. Runs on any reliable protocol, but does not rely
    on  underlying transaction model (unlike SOAP/HTTP).
    
    Henning: Please clarify on request response association.
    
    Orit: In SOAP over HTTP cannot send multiple requests and responses.
    
    Henning: Partially true.
    
    Orit presenting: Transaction client-server protocol. Final response x2
    and provisional  pending response. Request and response attributes (like
    SIP headers). Multiple primitives in  a single operation - can signal an
    atomic operation. However have decided at the moment not  to use this,
    instead define a single primitive which combines the meaning of multiple
    primitives. Object manipulation approach - object identified by keys
    without navigating  through the entire XML document. Response codes carry
    application semantics. Example of  object manipulation primitive. Define
    dedicated primitives for operations where at least one  of the following
    properties are desirable - atomic, applied to set of objects, efficiency.
    Example of operation. CCCP and events - does not appear in draft, but
    is something from the  framework so added to presentation. Notifications
    can be sent using operation in CCCP as  transport for these rather than
    SIP. Next steps: CCCP is open to modification - !
     can be taken  as basis. If not planning to publish as informational.
    
    Henning: What is motivation to have two event notification mechanisms
    (SIP and CCCP) that  have to be implemented.
    
    Orit: SUBSCRIBE/NOTIFY not best choice because cannot reuse the transport.
    
    Keith: In follow that argument, then will also add floor control to this,
    as that does not  reuse same transport.
    
    Cullen: Nothing in framework to need this. Sidebars within main
    object. How will do this.  How do templates relate to this protocol.
    
    Orit: This protocol can manipulate anything that is defined in
    XML. Templates are XML. What  is missing from data manipulation protocols
    is primitives with semantic content.
    
    Cullen: Understand simplicity, but need extensible way of adding to
    "move sidebar" to an  existing client.
    
    Orit: Different clients with different requirements. Sidebars in
    templates draft are met by  placeholders. A single CCCP operation can
    modify this value.
    
    Henning: One of differentiating feature mentioned is ability to have
    provisional responses.  What in current set of operations has this been
    found to be useful? Also atomicity feature  where it is not used. Should
    not design protocols with unused features.
    
    Discussion Henning / Orit seemed to agree on removing features that were
    not used.
    
    Orit: Provision responses. Establish call to third party that takes time.
    
    Henning: Preference for fewest number of mechanisms. In SIP would get
    rid of provisional  responses and have event notification. Likewise here.
    
    Adam: Agree with Cullen that it makes more sense now. If someone were
    to design a template  variable to change the pitch of a speakers voice
    how would one use CCCP to do it?
    
    Orit: Depends on how template defined, but Modify template element
    (element name, element  new value).
    
    Cullen: Are we going down parth of two protocols, One part to manipulate
    the dynamic part  and one the static part?
    
    Orit: Not two protocols.
    
    
    1530 - 1545  Media Templates
    ----------------------------
    
                 Chris Boulton (15 minutes)
                 draft-boulton-xcon-media-template-02.txt
    
    Chris presenting: XCON framework defines conference object which is
    common conference  information and template. Subject of draft is the
    template. Described what a template is.  Described blueprint is an XML
    file based on .xsd.
    
    Brian: Thought we all agreed that blueprint was object with the initial
    set of values in it.
    
    Mary: In current version of framework, blueprint is common conference
    information along with  the template.
    
    Brian: But the initial values come from the blueprint. Clone values from
    the blueprint.
    
    Adam: talking past each other?
    
    Henning: If do Brian's approach have overlap with the cloning
    operation. This is a framework  issue. Unless we get this straight will
    have way too much complexity.
    
    Cullen: All know what we want but get confused on terminology. Should
    delegate to Mary to  enforce a common terminology on all participants.
    
    All agreed.
    
    Chris presenting: Document overview. Open issues. Functionality boundaries
    of templates.  Single namespace versus namespace per template - discussed
    yesterday but no conclusion.
    
    Cullen: Should pick same solution as chosen for SIMPLE.
    
    Chris presenting: Open issues. Also need to align with Cullen's
    draft. Need to cover wider  range of templates. Input required from
    WG. Is this a working group item.
    
    Adam (chair): More input from group before we make that decision.
    
    Cullen: All issues that are open are issues that can be solved in a
    WG document.
    
    Adam (chair): not yet sufficent discussion on the list.
    
    1545 - 1610  Protocol Selection Open Discussion
    -----------------------------------------------
    
                 Chairs (25 minutes)
    
    None.
    
    

    Slides

    XCON Agenda
    BFCP
    XCON Framework
    A Common Conference Information Data Model for XCON
    Conference Package Extensions
    Role Definitions for Common Conferencing
    Centralized Conferencing (XCON) using the Message Session Relay Protocol (MSRP)
    People and Content video streams
    draft-levin-xcon-cccp-03.txt
    Media Policy templates for XCON