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

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

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