Subject: [Sipping] conf: comments on draft-mahy-sipping-media-policy-control-00

From: "Eric Burger" <[email-masked]>
Date: Thu, 20 Mar 2003 14:43:51 -0500

Section 2.1:
The operations described in the last paragraph (XML schema, queriable collections, methods, etc) sounds like SOAP in terms of model and operation.  Should one simply say that?

Section 2.2:
MUST support at least one standard collection:  everyone supporting a different standard collection doesn't help anyone.  Either chose a single MUST IMPLEMENT or drop the requirement.  The requirement has no value, otherwise.

The behavior described for building sidebars, etc. is overly complex.  The idea of simple building blocks is good.  The idea of arbitrarily complex connection models with arbitrarily complex behavior is bad.  The ability to *create* arbitrarily complex models from simple building blocks is best.

Looking at some of the operations of CPCP, like creating and deleting conferences, sounds a lot like... SIP.  Is the idea that most of CPCP can be SIP, or is the idea that we will create something that does exactly what SIP does, only it does the other stuff, too?

Section 3:
The statement that all connections have an input source and an output source doesn't mesh with hold or mute.  Is there going to be an explicit "hold tank"?  This sounds more and more like H.248...

Section 3.1:
I would strongly suggest looking at the CCXML work in the VBWG at the W3C.  That group has been looking at signaling transactions for about a year now.

Section 5:
I can buy that layout and floor controls are within the scope of CPCP.  However, I would offer that IVR operations are way out of scope (text2speech and speech2text).  There already are lots of IVR languages and protocols out there that work just fine.  Moreover, are we getting into a little SciFi with speech2gesture and speech2signlanguage?

Section 5.1.1:
What is the use case for picking the n-th loudest speaker?  That is a rather expensive operation.  The loudest speaker or the m loudest speakers makes sense.

Section 5.1.3:
What is the use case for the n-mixer?  People spent a LOT of time figuring out the n-1 mixer.  An n-mixer is a bug...

Section 5.1.5:
Is gain control per input leg, per output leg, per arbitrary in-out combination?  The first two are relatively easy.  The last one is particularly nasty and expensive.

Section 5.2.2:
I don't get "... the first input connection to all streams connected to the ou[t]put connector that match the input stream."

For that matter I don't get the use case for any of the topology manipulation blocks or how they would be used.  A deployable use case would be VERY helpful here.

Section 7:
The XML Schema reference is:
Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, May 2001.
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP