Subject: [mediactrl] Comments on MSCP

From: "Eric Burger" <[email-masked]>
Date: Tue, 2 Aug 2005 17:36:16 +0100 (BST)

GENERAL
=======
In general, I like the model presented, namely a media processing server
that accepts requests from an application server and either performs the
task and sends a response or rejects the response.  In particular, we
consider this to be far superior to a low-level, device control
protocol.

The use of namespaces is cool!

MSCP and SIP
------------
One thing I am trying to wrap my arms around is the relationship of MSCP
to SIP.  The text indicates that one uses SIP to connect the MS to the
UAC.  However, all of the control occurs through the MSCP channel.
Moreover, there are many cases where commands send through MSCP can
conflict with the session established over SIP.  Finally, MSCP has a lot
of commands that overlap considerably with SIP.  It would be much
cleaner to simply use SIP alone, rather than have an MSCP command that
results in an ambiguous SIP state.

Error Handling
--------------
Error handling in the proposal is less than satisfactory.  Things that
can have errors have ambiguous, non-interoperable error strings.  That
is OK if the only semantic is "an error occurred," and the only reason
for having an error string is for (human) debugging.  If clients are to
take action based on the error, then I would suggest using error codes
(much less chance of a typographical error) with optional error text. 

The Evils of <transfer>
-----------------------
The long, convoluted, complex, error prone procedures in section 4.8
(most of which look "correct" in context, by the way: good job!) should
be more than enough justification to explain why the <transfer> tag is
evil.

Can't we kill this bug once and for all?

Request-Response-Notification State Machine
-------------------------------------------
There is no consistent model for request/response versus notifications.
Throughout the document there are places where a request gets an interim
result, called a response, but then gets final results, often as
notifications.  Elsewhere, requests are notifications that get responded
to by notifications.

The state machine is not tenable, and suffers from a lot of known
problems with subscription management.  Moreover, there is 100% fate
sharing between the client and server that is an unnecessary limitation.
For example, what happens when the client goes away?  I have to assume
that crashes the server.  Not a good plan.

For example, look at example 6.1.  The client makes a <dialogstart>
request.  That request gets a <dialogstarted> response.  I can live with
that.  BUT, then it gets a <dialogexit> *response*.  Shouldn't that be a
notification?  Either way, how long does the client need to keep the
state necessary to understand the <dialogexit> notification?

If we used one of the standard subscription management packages, like
SIP SUBSCRIBE/NOTIFY, operations at the server can continue in the face
of client failure, and we can easily define how (pick your poison) a
client can find a new server (H.248 way) to notify or a server can
re-subscribe to the client (SIP way).

SPECIFICS
=========

Notifications
-------------
The whole notification mechanism is unworkable.

First off, there is no way for the notifier to *know* the notification
was delivered to the application.  Yes, it knows it was delivered to the
host, as SIP over TCP, SIP over SCTP, TCP, SCTP, +TLS, etc. is proposed
for the protocol.  However, that does not mean the client actually
understood the notification.  That is why, for example, a SIP NOTIFY
gets a 200 OK response.

Second, when requesting subscriptions (like in section 4.2 for
<dialogstart>), there needs to be explicit negotiation between the
client and server for what events the server supports.  As written
today, the client has no idea whether a server does not support an event
or the event simply didn't happen.  That is fine for closed systems, but
doesn't work for Internet systems.

SIP and MSCP
------------
What happens if the <stream> tag, like for <dialogstart>, conflicts with
SDP?  I can understand a dialog that is audio only (specified by the
<stream> tag) over a multimedia session.  However, what if the SDP says
the stream is recvonly, and the <stream> tag specifies "transmit"?

This is one of those instances where there is an interaction between
MSCP and SIP.  Why not simply use the SIP session parameters, and
explicitly state that the <stream> tag is really to identify individual
streams in a given SIP Dialog?

Likewise, why would the server issue a <dialogdisconnect> notification?
First of all, why is it a <notification> and not a <request>?  Second,
why doesn't the server simply terminate the SIP session?  Remember, the
client is in the SIP signaling path (see p. 8), so it would know what to
do.

On <dialogtransfer>, what happens to the SIP dialog?  <dialogterminate>
indicates the client wants the user out (actually, I'm guessing that is
the case; the next needs to be explicit).  However, who owns the
signaling?  The letter of the text is nothing.  The leg is out of the
transfer, but still at the server.  I would offer that if what is meant
is the leg is disconnected, that the client explicitly issues BYE's to
the end point and the server.

preparedialogid
---------------
I don't understand why you cannot use <stream> with a prepared dialog.

I also don't fully understand why a dialog must use the same prepared
dialog ID.  Is it the case that one must issue a prepare dialog command
*for a particular* dialog?  If so, why bother?

reason
------
Why mandate the inclusion of the "reason" attribute if it carries no
semantic information?

<dialogterminate>
-----------------
Why is this carried in a <notification>?  This is a command, that
returns a result.

<dialogexit>
------------
What possible errors can be associated with <dialogexit>?

Dialog Names
------------
Is "..." a legal dialog name?  It is given the definition in the text.

<namelist>
----------
There should be some text indicating the name list is purely a user-user
communication channel, with no defined semantics (i.e., what a given
"name" is).

<dialogdisconnect>
------------------
What values could possibly be in a name list for this command?  How
would it be used?

<dialogtransfer aai=>
---------------------
Besides my rant on the evils of the <transfer> tag, what is AAI in the
context of SIP?  Currently, there is no equivalent header or body part
for AAI.

For a blind transfer, who terminates the session on the server?  I
assume it is the client, as all signaling goes through the client and it
is easy enough for it to issue the BYE to the server.

See above about the fate of the SIP dialog on <dialogterminate>.

For a bridged transfer could, or should, the server reply with a
conference ID in the <conferencejoined> response.

<dialogterminatetransfer>
-------------------------
[AARGH - I HATE <TRANSFER>] If the "reason" attribute has semantics,
they must be defined.  "near_end_disconnect" is an opaque string.
Define it to mean something.  Again, I would offer codes, like SIP
result codes, with optional text.

Same goes for <dialogtransfercomplete>.

Also, here is another confusion of MSCP and SIP.  Why doesn't the client
simply terminate the bridge?  What is the use case for the server to
EVER issue this notification?

<createconference>
------------------
What about text and data for reservedmedia?

I disagree on the association of videomixingpolicy and
audiomixingpolicy.  The use case for audiomixingpolicy="nbest" and
videomixingpolicy="manual" is obvious, e.g., earnings announcement,
moderated classroom, etc.

I would suggest videomixingvas be specified in milliseconds, not
seconds.

<destroyconference>
-------------------
When would a conference not get destroyed?  The example doesn't make
sense.  If a conference that does not exist gets destroyed, it is
destroyed (success).  An error result here just complicates the client.

What happens if there are participants in the conference when it gets
destroyed?  Do they go into limbo, or does the server disconnect them.
If the server disconnects them, does it issue BYE's on the respective
SIP Dialogs (preferred), or does it send a ton of disconnect requests to
the client (not preferred).

What if mediapreferred="true" and direction="receive"?

What should I do for entertone if I have public participants, for whom a
beep and beep-beep is fine, but I also have private participants, for
whom I do NOT want the server to emit a tone?

<unjoin>
--------
Again, what happens to the SIP Dialog.  Does the leg listen to digital
silence, or is it disconnected.  If it is disconnected, who does the
disconnecting?

What possible error state can there be for <unjoin>?

<conferenceuser>
----------------
If there is to be any hope of interoperable clients and servers, we MUST
have a registry for the <conferenceuser> name attribute values and for
the name lists it returns.

MRCPv2 describes how to do vendor proprietary extensions.

Example 6.2
-----------
Second to last message, "The participant leaves the conference."  I
presume this is in response to the client issuing <conferenceunjoin>?
If not, again, what happens to the signaling?  Why didn't the client see
the end point issue the BYE, since the client is proxying the signaling
in the first place?

Example 6.3
-----------
Can you show the VoiceXML that would result in the behavior described?

Section 7.2.3: Request
----------------------
Why isn't REQ bi-directional?  There are a number of requests issued by
the server to the client.

Section 7.2.5: Notification
---------------------------
See the GENERAL section for the need for an OK response, unless
notifications are truly "fire and forget."

Section 8: Notice in Schema
---------------------------
The Copyright notice does not indicate the copyright owner.  Also, it is
somewhat incompatible with the IETF copyright policy.  See BCP 78.

Section 9: Security Considerations
----------------------------------
There is a raft of security considerations for any protocol that uses
XML.  See BCP 70.

Section 10: IANA Considerations
-------------------------------
The URN isn't quite right.  See BCP 73.

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