Re: [MEDIACTRL] MRB discussion at the face-to-face meeting

["Syrett, Mark" <[e-mail]>]

Hi,

On value in the required/optional approach to the consumer interface:

Does anyone have a good use-case/example that requires the optional?

I would say the use-case below isn't a good example - It's more a good way of introducing optional functionality, extra application code, tests, errors and complexity. 

<optional> considered harmful... or not?

Mark


-----Original Message-----
From: Lorenzo Miniero [mailto:[e-mail]] 
Sent: 09 November 2009 12:16
To: Syrett, Mark
Cc: [e-mail]
Subject: Re: [MEDIACTRL] MRB discussion at the face-to-face meeting

Hi Mark,

thanks for your feedback.

About the <required>/<optional> mechanism, the idea wasn't actually to
use it to implement a fallback mechanism, but was rather meant to
provide a way to address required functionality and optional
functionality: e.g. "I need a mixer session (required) and if you
support videomixing with a 2x2 layout it's better (optional)".

I definitely agree with you that employing it for fallback can lead to
problems, or unexpected behaviour at least, which is why for fallback
I'd stick to the separate, consecutive, requests.

That said, if we make this distinction clear in the text, do you still
see value in the required/optional approach?

Thanks,
Lorenzo


On Mon, 9 Nov 2009 10:55:21 +0000
"Syrett, Mark" <[e-mail]> wrote:

> Hi,
> 
> On the Consumer Interface and query mechanisms based on <required> and <optional> elements...
> 
> How would this handle use-cases like:
> 
> Give me resources for a HD video conference for 20 people, if resources aren't available I can fall-back to a low-res video conf for 10 with listen/broadcast only for another 10.
> Give me resources for 20 ASR sessions with complex grammars, if resources aren't available I can fall-back to using DTMF input instead.
> 
> Would they be handled:
> 
> As one required/optional query with the required (minimum) being the fall-back? I don't find it very natural to specify what you need/want as optional.
> As several queries (or negotiation) if the first resource request can't be granted until the appropriate resources are granted.
> Or at runtime during the application execution when resources are short?
> 
> Regards,
> 
> Mark Syrett 
> 
> HP CMS
> www.hp.com
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Lorenzo Miniero
> Sent: 08 November 2009 14:22
> To: [e-mail]
> Subject: [MEDIACTRL] MRB discussion at the face-to-face meeting
> 
> Dear all,
> 
> the face to face meeting is getting closer, and so is the discussion of
> the new MRB document. Chris and I have updated the document and added a
> lot of stuff, but of course there's still something missing, and
> questions on what we've added naturally arised. Long story short, we
> need you!
> 
> I'll summarize here in this message the points that will be discussed
> at the meeting, points that were picked from the slides Chris prepared:
> mostly the questions definitely need ML feedback. Be aware that this is
> going to be a very LONG mail: there are many things to discuss, so I
> thought it would be better to get it all in one place, instead of
> sending 30 mails on the ML.
> 
> 
> 
> 1) As you know, the Publish Interface is a framework control package,
> so we added a schema (more on that later) for that. A couple of
> questions on this:
> 
>      1a) At the moment, the MRB can just ask for the whole bunch of
> info the MS can provide; do you think adding filters to the request may
> be valuable? Something like an 'include' (give me just this) and/or
> 'exclude' (give me everything except this) list. It certainly makes
> sense to have filters in Consumer requests, while more doubts may come
> on the Publish interface, even though we personally find it useful.
> 
>      1b) We currently haven't added any way to stop ongoing
> notifications: do you think an explicit message is needed for that, or
> can we re-use the existing messages by implementing update mechanisms
> on extant notifications?
> 
> 
> Moving on, the publish schema is not complete yet. There are a few
> elements that people requested that haven't been fully specified yet.
> The reason for that is we need more feedback from you on what should
> really belong in there. So:
> 
> 
> 2) <mixing-modes> is supposed to report the mixing capability of an MS
> for what concerns both audio and video. What algorithms need to be
> included? Audio: N-Best, ? Video: List of supported video layouts (What
> should we include as default video layouts? How should they be
> represented?)
> 
> 
> 3) <supported-tones> were also discussed in Stockholm. How should this
> be represented in the document? Previous suggestions have included:
> ITU-T E.180/Q.35, but it may not be detailed enough. Specific package
> of H.248? Country specific tone plans? We need an expert volunteer to
> help us define this
> 
> 
> 4) <asr-tts-support> will specify whether or not an MS supports
> ASR/TTS, and for which languages. The idea is to have two values, one
> for ASR and another for TTS, each having a list of supported languages
> using ISO 639-1 codes. Do you people really need support for this
> element? Is the proposal reasonable? Or do you think we need expert
> volunteers to help better defining this?
> 
> 
> 5) <media-server-location> was also discussed in Stockholm, and there
> was strong support for this feature. How is it best to represent this?
> Country/State codes have been proposed, but we could definitely use
> some volunteer to write this up
> 
> 
> 6) <encryption> is assumed to advertise the MS capability for what
> concerns encryption of media streams. Is it sufficient to just indicate
> support of SRTP (yes/no)? Can we keep away from indicating supported
> keying mechanisms or would this be needed?
> 
> 
> 
> Now, to the Consumer Interface. This section is just a paceholder in
> the current version of the draft, at the moment, but we already started
> working on it. Specifically, we used the Publish Interface as an input
> to compile an initial list of elements for the Consumer Interface as
> well. Of course it is not a complete list, and other properties can
> input into Consumer interface elements if required.
> 
> 
> 7) About the protocol itself. We have already discussed about filtering
> in the Publish Interface. It definitely makes sense to have filtering
> in here as well. The idea is to re-use as many Publish elements as
> possible as input, and envisage query mechanisms based on <required>
> and <optional> elements, e.g.
> 
>    <required>
>        <X>..</X>
>        <Y>..</Y>
>        <W>..</W>
>    </required>
> 
>    <optional>
>        <A>..</A>
>        <B>..</B>
>        <C>..</C>
>    </optional>
> 
> 
> The MRB would extract the MRB that has all the 'required' stuff, and as
> many 'optional' stuff as possible. What do you think of this?
> 
> 
> 8) <required-packages> Consumer client lists the supported packages it
> requires from a MS. Publish Interface Input would be the
> <supported-packages> element.
> 
> 
> 9) <session-info> is what would provide optional session information,
> specifically:
>         * Update/remove an existing session
>         * Use lease mechanism
>                - Consumer leases resources from MRB
>                - If not updated/removed then expire at end of MRB lease
> timer Does this sound reasonable? Is it enough or do we need more info
> in here?
> 
> 
> 10) <required-ivr-sessions> allows a Consumer to ask for the number of
> concurrent IVR sessions it requires of a particular codec. The Publish
> Interface Input would be <non-active-rtp-sessions>.
> 
> 
> 11) <required-file-format> relates to the supported file format
> required for external streaming, recording or whatever involves support
> for a file format in particular. Associated package must be included in
> the request, since support is advertised per-package by the MS. Publish
> Interface Input would be <file-formats>.
> 
> 
> 12) <required-dtmf-type> relates to DTMF support type required by the
> Consumer client. As in 11), the associated package must be included.
> Publish Interface Input: <dtmf-support>
> 
> 
> 13) <required-tones>: Supported tones required by the Consumer client,
> which of course depends on Publish interface discussion (see discussion
> 3.) Publish Interface Input: <supported-tones> 
> 
> 
> 14) <required-asr-tts>: ASR + TTS support required by the Consumer
> client (see discussion 4. for Publish interface discussion, which would
> affect this one). Publish Interface Input: <asr-tts-support>
> 
> 
> 15) <required-vxml> for what concerns VXML support type required by the
> Consumer client. Package specific support must be indicated, since the
> MS advertises support for it per package. Publish Interface Input:
> <vxml-support>
> 
> 
> 16) <required-location> is the location required for the media server
> to pick up: it depends on Publish interface discussion (see discussion
> 5.). Publish Interface Input: <media-server-location>
> 
> 
> 17) <required-encryption>, Encryption required by Consumer client. It
> depends on Publish interface discussion (see 6.) so it could vary from
> a "I need/don't need encryption" to a much more complex "I need this
> mechanisms" as well. Publish Interface Input: <encryption>
> 
> 
> 18) <application-data>, Application data supplied by Consumer client.
> Publish Interface Input: <application-data>
> 
> 
> 19) <required-max-prepared-duration>, max prepared duration required by
> the Consumer client. Package specific support must be indicated.
> Publish Interface Input: <max-prepared-duration> 
> 
> 
> 20) <required-stream-mode>, Stream mode required by Consumer client.
> Package specific support has to be indicated. Publish Interface Input:
> <streaming-modes>
> 
> 
> 21) <required-mixers>, related to any mixer session of a particular
> codec required by the Consumer client. This could be an OR of multiple
> options. Publish Interface Input: <non-active-mixer-sessions> (which
> has to be discussed as well)
> 
> 
> 22) <required-mix-mode>, the mixing mode required by the Consumer
> client. This depends on Publish interface discussion (see discussion
> 2.). Publish Interface Input: <mixing-modes> 
> 
> 
> 
> 
> That's basically all, even though more cues for discussion may arise
> during the face-to-face meeting. After the discussion, Chris and I will
> prepare an updated version of the document, which will include a
> consolidated version of the Publish interface, and a first version of
> the Consumer Interface with a proper schema.
> 
> 
> If you managed to get this far, thanks for your patience, and for any
> feedback you'll be able to provide us with!
> 
> Lorenzo
> 
> -- 
> Lorenzo Miniero <[e-mail]>
> _______________________________________________
> MEDIACTRL mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
> 


-- 
Lorenzo Miniero <[e-mail]>