Subject: [mediactrl] initial comments on mscp

From: Tim Melanchuk <[email-masked]>
Date: Thu, 4 Aug 2005 18:27:39 +0100 (BST)

hi scott,

below are my general thoughts and comments on the mscp draft.

in general, i like the proposal, partly because it is very similar to
msml, both being based to one extent or another on ccxml. ;-)
but there seems to be no recognition within the document that
other proposals for ms control exist. it would have been nice to 
see comparison in the document identitifying specific differences, 
their rationale, and why any requirements that this proposal meets 
could not met by other proposals such as msml. 

i agree with some of eric's comments and nits and won't repeat
them here. i too like the use of namespaces ;-) i'm on the fence
on transfer - i see a need but i'm not sure of the best realization.
unlike eric, i am in favour of using a control channel(s) for 
*application* control of media servers because i think decoupling 
application control from session signalling provides more architectural 
options. chris boulton and i have a draft out discussing this. 

i think that the use of "dialog" gets confusing. for example the use
of dialog[prepare | start | terminate] is refering to dialogs in the
voicexml sense. however the dialog[disconnet | transfer] appear to
be referring to the sip dialog. 

i like some of facilities that have been added to support voicexml.
how well will some of those work for other dialog languages? i think
there is a real need for "lightweight" simple prompt/collect/record 
dialog operations (similar to those in mscml) from a 
performance/capacity perspective. i'm not sure whether the 
modulariztion of vxml v3 will meet this need (although it would be 
nice if it did).

also, i'm not sure that i understand how the characteristics/properties 
of media streams and conference mixes can be dynamically changed.
for example it looks like <join> is used to both create a stream, 
set its properties,  change the properties, and possibly to unjoin it. 
if so, i think  the explicit <join>, <modify>, <unjoin>
model of msml (with analagous mechanisms for conference mixes)
is preferable.

cheers,
timm

--------------------------
Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.
Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper.