One document matched: draft-burger-xcon-mmodels-00.txt




XCON                                                           E. Burger
Internet-Draft                                  SnowShore Networks, Inc.
Expires: August 8, 2004                                 February 8, 2004


              Centralized Conferencing (XCON) Media Models
                      draft-burger-xcon-mmodels-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 8, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This document describes various models for endpoint control of media
   policy for centralized conferencing services.  The models include
   detailed mixer control, as in H.248, individual end-point
   negotiation, and participant roles, as in MSCML.












Burger                   Expires August 8, 2004                 [Page 1]

Internet-Draft    Centralized Conferencing (XCON) Media Models      February 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Low-Level Stream Control . . . . . . . . . . . . . . . . . . .  3
   2.1 Decription . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.3 Drawbacks  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Individual End-Point Negotiation . . . . . . . . . . . . . . .  4
   3.1 Decription . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.3 Drawbacks  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Role-Directed Control  . . . . . . . . . . . . . . . . . . . .  5
   4.1 Decription . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.3 Drawbacks  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Other Thoughts . . . . . . . . . . . . . . . . . . . . . . . .  5
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
       Informative References . . . . . . . . . . . . . . . . . . . .  6
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
       Intellectual Property and Copyright Statements . . . . . . . .  7






























Burger                   Expires August 8, 2004                 [Page 2]

Internet-Draft    Centralized Conferencing (XCON) Media Models      February 2004


1. Introduction

   There is debate about how one should control the centralized mixing
   service in the XCON framework.  We term this control media policy.

   Some offer low-level manipulation of media streams and resources on a
   per-user basis.  Others offer models based on end-device negotiation
   of streams of interest and doing local manipulation.  Yet others
   offer models based on fixed frameworks and user roles to indirectly
   determine the media policay.

   In one sense, the different models are isomorphic.  One can construct
   the end-device-centric model from the low-level model.  Likewise, one
   can construct the frameworks-and-roles model from the
   end-device-centric or the low-level model.  Given this, it is
   important to consider the use cases for media policy manipulation.
   As this document will assert, the different models impose quite
   different requirements on the endpoints.

   Another factor this document will examine is the ease of
   implementation, both of the server (mixer) and client (endpoint).

   Everything needs to loop back to and have examples for how to meet
   the Conferencing Scenarios draft [1].

2. Low-Level Stream Control

2.1 Decription

   Low-level stream control is where the endpoint manipulates a direct
   representation of the media processing resources of the mixer.  This
   representation can be physical, as in terms of directly plumbing DSP
   resources in the manner of H.248.1.  The representation can be
   logical, as in terms of XML mappings of DSP topologies.

2.2 Benefits

   This is the most flexible model available.  Just as one can construct
   all logic circuits from an OR gate and a NOT gate, one can construct
   all possible media mixing scenarios from a two-input mixer and an
   attinuator.

2.3 Drawbacks

   Unless the mixer physically maps to the primitives of the device
   control model, it is very conceivable for a legal mixing request to
   be unrenderable by the mixing device.  For example, an 8-input mixer
   with the loudest three talkers with four outputs being the full mix,



Burger                   Expires August 8, 2004                 [Page 3]

Internet-Draft    Centralized Conferencing (XCON) Media Models      February 2004


   the mix less the loudest talker, the mix less the second loudest
   talker, and the mix less the third loudest talker is a 13-element
   composition (7x 2-input mixers, 3x loudest talker selectors, and 3x
   2-input mixers with "not loudest talkers").  The mixing device must
   be able to map the representation into primitives it understands,
   such as an 8-input mixer.

   Another drawback is the mixer may not be able to globally optimize
   the mixing resources, as there are many ways of representing the same
   mix result.  For small mixers, this is a denial of service
   opportunity.  For large mixers, properly scaling the system requires
   minimizing the resource utilization for the average conference.

   Finally, this model requires the endpoint developer to be an expert
   in DSP technology.  This is because the developer has to manage and
   manipulate the DSP resources at a fairly low level.

3. Individual End-Point Negotiation

3.1 Decription

   The individual end-point negotiation model is where the endpoint
   negotiates directly with other conference endpoints and does any
   mixing locally.  One often finds this model for small audio or
   multimedia conferences.  If the endpoint wants a big video window, it
   will ask the remote endpoint for a big video transmission.  If the
   endpoint wants a thumbnail, it asks for a thumbnail.

   With the streams, the endpoint locally composes whatever layout or
   mixing policy it feels like.

   This model often relies on the us of silence-suppression codecs to
   reduce bandwidth to the endpoint and make active talker
   identification easier.  For the most part, only two people will try
   to talk for more than 500ms.  Human protocol usually results on one
   of the participants to backoff.

3.2 Benefits

   The main benefit of this model is the user is in complete control of
   their experience.  There are no questions about whether a mixing
   service can support the user interface, whether because of resource
   availability, computational complexity, or forsight into the possible
   media manipulation needs.

3.3 Drawbacks

   All media must traverse the network from all endpoints to the given



Burger                   Expires August 8, 2004                 [Page 4]

Internet-Draft    Centralized Conferencing (XCON) Media Models      February 2004


   endpoint.  This is not realistic for Internet-scale protocols.

   There is no centralized control of policy such as floor control.  For
   example, the moderator may wish to mute a particular speaker; the
   endpoint may still allow that speaker into the mix, ignoring the
   moderators mute request.

   The endpoint developer must be able to put together the media
   manipulation on their own.  For example, mixing; video demodulation,
   mixing, and remodulation; and stream selection are all now endpoint
   functions.

4. Role-Directed Control

4.1 Decription

   In role-directed control, the mixing service provides a set of
   templates for which different users have different roles.  The roles
   in the template dictates the media policy.  For example, in a lecture
   template, there is a lecturer and possibly listeners and questioners.
   The moderator is the only stream in the mix, unless a user becomes a
   questioner.  As a questioner, their media is added appropriately to
   the mix.  While straightforward for audio, the mix for video is more
   involved.  A likely scenario is to have multiple templates for
   different preferences, such as video switching to the current
   speaker, split pane with the lecturer and current questioner, and so
   on.

4.2 Benefits

   The endpoint operates at the level of a conference.  It only needs to
   know what role the user wants to be.  It does not need to know
   anything about DSP primitives or plumbing.

4.3 Drawbacks

   There is unquestionably a loss of generality with role-directed
   control.  However, that loss is made up with an increase in
   usability.

5. Other Thoughts

   BOBW: Role-Directed Control with a Framework Markup language?

6. Security Considerations

   While this document is entirely informative, it is worthwhile to note
   the above mentioned denial of service opportunities some of the



Burger                   Expires August 8, 2004                 [Page 5]

Internet-Draft    Centralized Conferencing (XCON) Media Models      February 2004


   methods outlined in the paper present.

Informative References

   [1]  Even, R., "Conferencing Scenarios",
        draft-ietf-xcon-conference-scenarios-00 (work in progress),
        December 2003.


Author's Address

   Eric Burger
   SnowShore Networks, Inc.
   285 Billerica Rd.
   Chelmsford, MA  01824-4120
   USA

   EMail: e.burger@ieee.org

Appendix A. Acknowledgements

   If I do this paper for real, there are boatloads of references to do,
   like Rohan's XML media representation, Jonathan's conferencing
   framework, Brian's extreamly cool Viper product, and all of Alan and
   Henry's work in the conferencing space.  Please forgive me this -00
   done in 00 time at all!

























Burger                   Expires August 8, 2004                 [Page 6]

Internet-Draft    Centralized Conferencing (XCON) Media Models      February 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Burger                   Expires August 8, 2004                 [Page 7]

Internet-Draft    Centralized Conferencing (XCON) Media Models      February 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Burger                   Expires August 8, 2004                 [Page 8]




PAFTECH AB 2003-20262026-04-23 04:17:13