Subject: [XCON] Media Policy in Conferencing Framework

From: eburger at snowshore.com (Eric Burger)
Date: Mon Jul 14 10:09:55 2003

[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.

---

From: rohan at cisco.com (Rohan Mahy)
Date: Tue Jul 15 06:39:00 2003

On Monday, July 14, 2003, at 08:09 AM, Eric Burger wrote:

> 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.

Eric,

I agree that conferencing applications are hard to build.  This is 
exactly why we should split these apps from the actual conference and 
media policy underneath. The goal is to allow customers to select a 
conferencing application that can work with many vendor's mixers and 
conference servers.  So Acme Underwriting might decide it likes a 
conferencing application from Voyant, (because they liked the interface 
best) but wants to run the application with Snowshore, Cisco, and 
Microsoft conference servers. (for example).  Also, a company for which 
conferencing is business critical may develop (by hiring a contractor 
or using internal IT development resources) a company-specific 
conferencing application.  A good example might be a financial trading 
call center.  They can focus on the details of the media and 
authorization policies and the user interface, but they don't need to 
build a general purpose mixing engine, a focus, etc..

> 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."

First, I think you are missing some of the logical aspects of media 
policy.  To play a prompt to one user (or a subset of the users), it 
should be sufficient logically to create a subconference for the prompt 
(1 step) and move the user into it.  When the prompt is done, the 
subconference ends automatically and the user is returned to their 
original conference (0 steps).  To play a prompt to the entire 
conference in most cases, you just add the prompt as a participant to 
the conference.

Second, I think your APIs *will* have functions such as "play a prompt 
to user x", but I think these names can become ambiguous as you try to 
do more complex things.  I believe these APIs can just invoke media 
policy control commands, and this is pretty straightforward.

> 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.

You may be missing something that is unclear in the framework or in the 
media policy document. When the creator of a conference creates a media 
policy that includes floor control, it connects the logical holder(s) 
of floor to the input of the mix. As different users get the floor, the 
policy does not change.  You don't have to redo any plumbing when you 
switch floor holders.

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

a non-mixing vendor supplied application (which could be written by a 
different conference vendor) could decide to introduce a sidebar or 
switch between a media policy oriented towards presentation mode to 
panel mode to discussion mode.

> 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.

see above..

> 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.

actually they do.  I could use media policy to decide who participants 
are in which conversation space (participant-oriented), but I do not 
specify which call legs go where or how many or which type of mixers 
are controlled by the focus.

thanks,
-rohan

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

---

From: sfisher1 at att.com (Steve Fisher)
Date: Wed Jul 16 02:05:18 2003

Rohan,

In your response to Eric you state the following goal for xcon:

"The goal is to allow customers to select a 
conferencing application that can work with many vendor's mixers and 
conference servers."

I'm puzzled how this goal can be achieved when the protocol between the
application server and the mixers is explicitly out of scope for xcon?
According to the charter, the following is out of scope: "Protocol used
between the conference controller and the mixer(s)."

Steve