Subject: [XCON] Media Policy in Conferencing Framework

From: roni.even at polycom.co.il (Even, Roni)
Date: Mon Jul 14 13:22:38 2003

Eric,
As one of the companies having conferencing bridge we have third parties
developing conferencing application based on our API. This is the same API
we use for our conferencing application. That includes creating conferences
, adding users, defining the mixing modes and even forcing views. I would
imagine that those application developers would like to have a common
protocol for those applications. The reason for application development is
to enable them to create services according to their requirements.
Thanks
Roni Even
Polycom

-----Original Message-----
From: Eric Burger [mailto:[email-masked]]
Sent: Monday, July 14, 2003 6:10 PM
To: IETF XCON Discussion List (E-mail)
Subject: [XCON] Media Policy in Conferencing Framework

[on XCON list, even though a SIPPING draft]

draft-ietf-sipping-conferencing-framework-00 spends many pages on media
aspects of conference policy and on media policy itself.

First question: what requirements in the requirements document
(draft-ietf-sipping-conferencing-requirements-00) do these sections tie back
to?

For example, section 4.6, Conference Policy, is the *definition* of a
conferencing application.  I don't think we're ready to say that
conferencing applications are obsolete.  I doubt Polycom, Radvision,
Ubiquity, Spectel, or Voyant would agree.  Conferencing applications are
extremely difficult to develop.  Much of the intellectual challenge is in
the user interface.  Getting rid of packaged conference applications so end
users can create arbitrarily complex media plumbing and manipulation is not
likely to succeed.

Let's compare this to another user language, CPL.  The primitives and model
of CPL are oriented around the user's experience, and it is in the user's
terms.  The exposition of conference policy and media policy are in the
terms of a conference platform developer.  While one can argue about whether
Joe Six-Pack will write their own CPL scripts, one could expect a real
third-party CPL market happening.  I cannot ever envision Joe Six-Pack
writing their own conferencing application.  Moreover, I cannot envision
anyone getting economic returns from building, e.g., only the user interface
on top of half of a conferencing application (unless the bridge
manufacturers are planning on giving away their stuff, which isn't very
likely).

Section 5.10 describes very convoluted procedures for replumbing the
conference to play an announcement.  Most application developers just want
to say, "play a prompt to leg X".  They don't want to say, "reconfigure the
mixer to be one user smaller, disconnect X, allocate a player, connect the
player to X, start the player, when the player is done, disconnect X from
the player, deallocate the player, reconfigure the mixer to be one user
larger, and reconnect X."

On another topic, I don't see floor control being related at all to mixing
topology.  That presupposes the policy being done by plumbing instead of
having the client simply say what it wants to do.

Likewise, who would decide to change conference modes on the fly without a
vendor-supplied application (section 6.4)?

This really comes to my key point.  Who is the consumer of this protocol?
By "consumer", I mean who will write the client and who will write the
server?  If they are not by different people, there isn't much value for
standardization.

For that matter, plumbing and media manipulation do not meet the guideline
proposed in draft-ietf-sipping-cc-framework-02, that the primitives be
participant-oriented, not media relationship-oriented.

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon