Subject: [MEDIACTRL] Some comments about the drafts

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 30 Jul 2008 10:31:02 +0200

Hi all,

following our implementation efforts upon the MediaCtrl prototype, we  
met a few issues that we thought might prove valuable as feedback. The  
drafts are actually quite good, and in fact my comments are more  
related to some clarifications that might be needed than to real  
issues. Most of the points that are listed below come from real  
scenarios we tried to accomplish, while other just come from a review  
of the drafts themselves.

Here come just some doubts (and some nits) from respectively the  
framework, IVR and mixer draft. Anyway, I will also raise the same  
issues this afternoon during the MediaCtrl meeting session for further  
discussion.

Framework:

	* At pg.30 it is unclear whether the header is K-Alive or Keep-Alive,  
and at section 6.3.4.1 there is the same ambiguity (I think this is  
the same issue Roni reported in one of his previous mails)

	* The framework says that CONTROL "MAY" have a payload, but behaviour  
is not specified in case the MS receives a bodyless CONTROL... what  
should be generated? a framework level error message, or a package  
level error? or should a bodyless framework level 200 be generated?  
(which would result in a pretty useless transaction indeed!) In our  
implementation we currently handle it as a package level error: both  
the IVR and the Mixer package trigger an "element required" error (406  
and 45 respectively) since both the packages actually require a root  
element (mscivr and mscmixer)

	* It is still a bit unclear when and how to use some of the specified  
error codes: one of the examples is 400, which is specified but never  
again mentioned in the text. Should it be triggered when errors in  
headers are found or the like? (I guess this is the best  
interpretation of a framework level syntax error)

IVR Package

	* Instead of the previous global offset attribute, now each <media>  
element can be provided with a clipBegin attribute, to specify from  
where the media file needs to be started; why not adding a clipEnd  
attribute as well? it would furtherly enhance the control on the  
playback, since alternatives like repeatDur would not be of any help  
in this case, considering that's a global attribute and not a  
per-media one.

	* The dest attribute in the recording operation allows the AS to  
instruct the MS into sending the actual recording somewhere else,  
instead of using the internal MS storage if dest is specified; this  
upload can be done in realtime or once the recording is over. Anyway,  
this feature is not adequately described yet, and has a few  
ambiguities: for instance, if a real-time upload is requested, how  
should the MS deal with file formats with a header? (e.g. wav) such a  
header would need to be updated each time a new frame is appended, and  
in a real time upload this could be hard if the protocol does not  
support it.

	* Besides, dest has no information about authorization mechanisms  
that may be needed (e.g. HTTP POST, NFS, etc). Should the AS provide  
them as part of the provided dest uri, if possible, or do we need a  
different way to cope with such an issue?

	* params is apparently used to allow any kind of custom interaction,  
which makes it quite useful for developers since they could use it for  
debugging or any other interaction they might need... but in a  
deployment scenario, the use of such an element is quite likely to  
cause interoperability problems... will be see a draft called  
"<params> is evil" in the future? ;)

	* In <response> dialogid is specified as mandatory, but it actually  
isn't included in 6.1.2, which makes sense: in fact, if a dialog can't  
be prepared at all, there's no dialogid associated with it, and so  
nothing to report in the response. Is this ok? For this use case, we  
don't handle the attribute as mandatory in our prototype, but if it  
should be, how the scenario shall be handled should be clarified.

	* 6.2.1 says prompt is played twice, but no repeatCount is set;

	* In the example provided in section 6.2.2, the snippet says 1080  
while it actually should be 1800 (3 hours);

	* repeatCount allows multiple iterations of the specified operations.  
This is a really useful feature, nevertheless there are some  
ambiguities with respect to where/when the results of such operatios  
should appear, and which ones. Should only the result of the last  
iteration be provided in the dialogexit event (likely)? or the results  
of each transaction should be provided to the AS? and if so, should  
they all go in the dialogexit event, or each iteration notified in a  
dedicated (and currently missing) event? Our implementation currently  
provides only the results of the last iteration in dialogexit, but  
this needs to be clarifed anyway.

	* A doubt that is somehow related to the previous one: if repeatCount  
involves recording, should the requested recording operations be done  
in different files (and if so, we need a naming convention) or  
appended to the same file (and if appended, should a simple append be  
accomplished or should silence be generated for the duration of the  
other operations?) In our prototype we currently record to separate  
files, using an implementation specific naming for the filenames,  
which is probably not the desired approach to the problem.

	* prompt::termmode::maxduration is a leftover in the schema  
(maxduration is now associated to the whole dialog, as a consequence  
of the repeatDur attribute);

Mixer Package

	* Some doubts about the join mechanism. Let's consider two different  
users, respectively referenced by their connection identifiers a~b and  
c~d (the from~to tag mechanism), joined together by means of a  
previous <join> directive, and let's assume that each user has more  
media streams associated with the same media session (e.g. label c is  
the first user's audio stream, and label f is the second user's audio  
stream). Now, if a~b~c has already been disconnected from d~e~f in a  
previous transaction, does an unjoin having a~b and d~f as identifiers  
fail? This transaction would normally result in an already unjoined  
link, and consequently in an error, which I'm not sure is the desired  
behaviour; anyway, this is exactly what our implementation reports in  
that case.

	* Should the draft allow multiple joins of the same user to the same  
conference? a (maybe silly) use case for this might be having a user's  
video appear in 2 different regions of the same conference. With the  
current specification an "already joined" error would be generated,  
considering that the same connection/conference can only be attached  
once to each other.

	* The XCON data model allows for custom video layouts per user, but  
the mixer draft apparently doesn't... is this planned? a custom video  
layout per user would be quite useful (e.g. for the video echo  
cancellation), but it would of course require much more resources from  
the MS...

	* Is a static region mechanism the way to go? what if collisions  
occur in a request? besides, the reallocation of regions, (e.g. moving  
all participants to the following region they're in at the moment  
because a much more important person has joined), would be hard to  
accomplish and require a lot of framework transactions... a solution  
may be relying on some kind of priority mechanism, and let the MS  
automatically choose the best region for each user accordingly. Of  
course, a static region mechanism might be still envisaged in case a  
static association is required for someone for any reason.

	* If a user negotiated no audio, or its audio is not attached to a  
conference (e.g. a video of a powerpoint presentation), or more audio  
channels are available for the same user, how would the Voice Actvated  
Switching behave? Should the draft explicitly declare that there are  
cases when the VAS behaviour is unspecified?

	* The example at pg.13 is missing minParticipants in the  
<video-layout> elements

Hope that helped, see you later,
Lorenzo

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Universita' degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Universita' degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "McGlashan, Scott" <[email-masked]>
Date: Wed, 30 Jul 2008 10:28:48 +0000

Thanks for the comments, Lorenzo.

Responses ("[scott]") inline on IVR and mixer packages.

Thanks

Scott

IVR Package

        * Instead of the previous global offset attribute, now each <media> element can be provided with a clipBegin attribute, to specify from where the media file needs to be started; why not adding a clipEnd attribute as well? it would furtherly enhance the control on the playback, since alternatives like repeatDur would not be of any help in this case, considering that's a global attribute and not a per-media one.

[scott] clipEnd is possible (as offset from beginning of media) and good complement to clipBegin, but we need to cover the edge cases. I'll add it.

        * The dest attribute in the recording operation allows the AS to instruct the MS into sending the actual recording somewhere else, instead of using the internal MS storage if dest is specified; this upload can be done in realtime or once the recording is over. Anyway, this feature is not adequately described yet, and has a few
ambiguities: for instance, if a real-time upload is requested, how should the MS deal with file formats with a header? (e.g. wav) such a header would need to be updated each time a new frame is appended, and in a real time upload this could be hard if the protocol does not support it.

[scott] In the current spec there isn't a feature to allow the developer to control exactly how the recording is uploaded by the implementation. The (only) guarantee you get is that the file is uploaded when recording is complete. You may also need to take into account final silence which causes termination of the recording operation but is not part of the recording itself. I'll clarify some of these options in the text. Do you think we need to add more parameters to control these features?

        * Besides, dest has no information about authorization mechanisms that may be needed (e.g. HTTP POST, NFS, etc). Should the AS provide them as part of the provided dest uri, if possible, or do we need a different way to cope with such an issue?

[scott] This is a general issue with any URI: e.g. fetching media files, grammars etc. You can put the info into the URI itself, use separate certificates, etc. I can clarify that these are possible options  for authorization.

       * params is apparently used to allow any kind of custom interaction, which makes it quite useful for developers since they could use it for debugging or any other interaction they might need... but in a deployment scenario, the use of such an element is quite likely to cause interoperability problems... will be see a draft called "<params> is evil" in the future? ;)

[scott] Not sure this is valid given the other interoperability barriers - media types, URI schemes, etc - where we don't take a stance. Again, I can clarify how the AS responds in case of <dialogstart> features which it doesn't understand.

        * In <response> dialogid is specified as mandatory, but it actually isn't included in 6.1.2, which makes sense: in fact, if a dialog can't be prepared at all, there's no dialogid associated with it, and so nothing to report in the response. Is this ok? For this use case, we don't handle the attribute as mandatory in our prototype, but if it should be, how the scenario shall be handled should be clarified.

[scott] if the MS receives a dialogprepare without a dialogid, it must generate a dialogid and use it in the response. There was a similar issue with <dialogterminate> - if it doesn't contain a dialogid attribute then what would the dialogid be in the response? Dialogid in a response may be "" as result. However, I think the dialogid should be optional in response - this makes these cases much cleaner - and I don't have to fix the examples in 6.1.2.

[scott] Right. I'll fix that.

        * In the example provided in section 6.2.2, the snippet says 1080 while it actually should be 1800 (3 hours);

[scott] Right. Will fix.

        * repeatCount allows multiple iterations of the specified operations.
This is a really useful feature, nevertheless there are some ambiguities with respect to where/when the results of such operatios should appear, and which ones. Should only the result of the last iteration be provided in the dialogexit event (likely)? or the results of each transaction should be provided to the AS? and if so, should they all go in the dialogexit event, or each iteration notified in a dedicated (and currently missing) event? Our implementation currently provides only the results of the last iteration in dialogexit, but this needs to be clarifed anyway.

[scott] Agreed clarification needed. Only results of last operation should appear in the dialogexit.

        * A doubt that is somehow related to the previous one: if repeatCount involves recording, should the requested recording operations be done in different files (and if so, we need a naming convention) or appended to the same file (and if appended, should a simple append be accomplished or should silence be generated for the duration of the other operations?) In our prototype we currently record to separate files, using an implementation specific naming for the filenames, which is probably not the desired approach to the problem.

[scott] Again clarification required. Only the result of the last operation should be reported. On overwrite vs. append we have made no statement, so the implementation could do either. However, it may be better to give the developer control by adding a 'append={true|false}" attribute on <record>. Do you think this is necessary?

        * prompt::termmode::maxduration is a leftover in the schema (maxduration is now associated to the whole dialog, as a consequence of the repeatDur attribute);

[scott] Good catch. I'll fix.

Mixer Package

        * Some doubts about the join mechanism. Let's consider two different users, respectively referenced by their connection identifiers a~b and c~d (the from~to tag mechanism), joined together by means of a previous <join> directive, and let's assume that each user has more media streams associated with the same media session (e.g. label c is the first user's audio stream, and label f is the second user's audio stream). Now, if a~b~c has already been disconnected from d~e~f in a previous transaction, does an unjoin having a~b and d~f as identifiers fail? This transaction would normally result in an already unjoined link, and consequently in an error, which I'm not sure is the desired behaviour; anyway, this is exactly what our implementation reports in that case.

[scott] Ok, Some clarification needed.

        * Should the draft allow multiple joins of the same user to the same conference? a (maybe silly) use case for this might be having a user's video appear in 2 different regions of the same conference. With the current specification an "already joined" error would be generated, considering that the same connection/conference can only be attached once to each other.

[scott] So the question is - do we want multiple joins of the same user to the same conference?

        * The XCON data model allows for custom video layouts per user, but the mixer draft apparently doesn't... is this planned? a custom video layout per user would be quite useful (e.g. for the video echo cancellation), but it would of course require much more resources from the MS...

[scott] Not for this draft. Personalized mixers could be done in an advanced video mixer draft.

        * Is a static region mechanism the way to go? what if collisions occur in a request? besides, the reallocation of regions, (e.g. moving all participants to the following region they're in at the moment because a much more important person has joined), would be hard to accomplish and require a lot of framework transactions... a solution may be relying on some kind of priority mechanism, and let the MS automatically choose the best region for each user accordingly. Of course, a static region mechanism might be still envisaged in case a static association is required for someone for any reason.

[scott] If a collision occurs, there would be an error response to the join command. There could be good reason for having an additional approach between static and automatic, so can you describe the priority mechanism is more detail?

        * If a user negotiated no audio, or its audio is not attached to a conference (e.g. a video of a powerpoint presentation), or more audio channels are available for the same user, how would the Voice Actvated Switching behave? Should the draft explicitly declare that there are cases when the VAS behaviour is unspecified?

[scott] Right. We need to clarify switching behavior in these cases.

        * The example at pg.13 is missing minParticipants in the <video-layout> elements

[scott] Ok, will fix.

Dipartimento di Informatica e Sistemistica Universita' degli Studi di Napoli "Federico II"

Dipartimento di Informatica e Sistemistica Universita' degli Studi di Napoli "Federico II"