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

From: Lorenzo Miniero <[email-masked]>
Date: Sun, 8 Nov 2009 14:22:20 +0100

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 <[email-masked]>

---

From: "Syrett, Mark" <[email-masked]>
Date: Mon, 9 Nov 2009 10:55:21 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Miniero
Sent: 08 November 2009 14:22
To: [email-masked]
Subject: [MEDIACTRL] MRB discussion at the face-to-face meeting

Dear all,

   <required>
       <X>..</X>
       <Y>..</Y>
       <W>..</W>
   </required>

   <optional>
       <A>..</A>
       <B>..</B>
       <C>..</C>
   </optional>

Lorenzo

-- 
Lorenzo Miniero <[email-masked]>
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 9 Nov 2009 12:15:46 +0100

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

---

From: "Syrett, Mark" <[email-masked]>
Date: Mon, 9 Nov 2009 13:13:57 +0000

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:[email-masked]] 
Sent: 09 November 2009 12:16
To: Syrett, Mark
Cc: [email-masked]
Subject: Re: [MEDIACTRL] MRB discussion at the face-to-face meeting

Hi Mark,

Thanks,
Lorenzo

---

From: Chris Boulton <[email-masked]>
Date: Mon, 09 Nov 2009 19:02:52 +0000

> <optional> considered harmful... or not?
[Chris] Hi Mark - interesting perspective and raises a lot of thoughts.  
One thing we need to keep in mind is the intention that the interfaces 
provide the appropriate level of information to allow an MRB to make a 
decision.  The document in no way influences HOW that decision is made.  
It could be that your implementation does not take any of the 'optional' 
elements from an application into account when making a media server 
decision - its an implementation choice.

An example could be the codecs required for a mix.  You might have a 
required codec that needs to be supported by the media server but also 
offer optional codecs that could be used.  It would then be down to MRB 
policy on HOW that information if processed and enforced.  Is <optional> 
considered harmful?  I am not convinced - BUT I certainly think we need 
to delve a bit deeper to make sure we are seeing appropriate benefits.

-- 
Chris Boulton
CTO & Co-founder
NS-Technologies <http://www.ns-technologies.com>
m: +44.7876.476681

---

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Sun, 8 Nov 2009 23:35:49 -0500

Hi Lorenzo and folks,

Here's some feedback on a few points.  I'm in a 3GPP SA5 meeting at the
moment, so constrains my time to think about the MRB questions quickly.

a) Regarding filtering, offhand I don't see significant value in this.
On the Publish interface, it seems to complicate the interface and
implementation in the MS, only to gain some reduction in info that isn't
sent all that often. On the Consumer interface, it seems undesirable.
Right now, everything is initiated from the AS. If MRB says "I only want
such and such info", MRB would have to initiate that will all the AS.
Perhaps more importantly, I would think the AS is taught to only ask for
attributes it considers important on any given call, so they are
important for the service and would need to be supported by MRB as well.
So I see use of attributes between AS community and MRB as already
essentially in sync in any given implementation.

b) On location info, I continue to be strongly supportive. [Items 5 and
16.] If help is needed on specific text, please tell me and I'll try to
help supply (but wouldn't happen immediately). Secondary note: whether
on the Consumer interface the location is implied as required or
preferred is a question; one reason why the next item is useful.

c) I think required and optional elements on the Consumer interface is
useful. [Item 7]

d) AS asking for a number of IVR sessions (or conference of a certain
size) is very important. [Item 10]

e) Regarding "lease" in [Item 9], might be useful, but I only see it as
a safety mechanism. Doesn't allow for as efficient use of resources as
AS to proactively tell MRB when finished in query or possibly in-line
mode or (MRB to infer it in in-line mode from SIP BYE).

cheers,

Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Lorenzo Miniero
Sent: Sunday, November 08, 2009 8:22 AM
To: [email-masked]
Subject: [MEDIACTRL] MRB discussion at the face-to-face meeting

Dear all,

   <required>
       <X>..</X>
       <Y>..</Y>
       <W>..</W>
   </required>

   <optional>
       <A>..</A>
       <B>..</B>
       <C>..</C>
   </optional>

Lorenzo

---

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Mon, 9 Nov 2009 08:36:13 -0500

Hi Mark,

On this one, a simple example to me would be MS location, assuming
'optional' means what I think it means - i.e., a preference for.  An AS
handling a conference call may know most of the conferee legs will be,
say, in the New York City metro area, so may prefer a MS resource that's
in the locality, so may indicate a conference bridge with certain media
aspects necessary and an MS with location in, say, New York state, is
preferred.  Fine if the MRB can honor that location preference, but if
not, the MRB can still pick a MS elsewhere.

(Yes, I suppose there can be other ways to express whether required or
merely preferred, such as per-attribute flag, as opposed to a bucket of
required attributes followed by a bucket of optional/preferred
attributes.)

cheers,

Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Syrett, Mark
Sent: Monday, November 09, 2009 8:14 AM
To: Lorenzo Miniero
Cc: [email-masked]
Subject: Re: [MEDIACTRL] MRB discussion at the face-to-face meeting

Hi,

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. 

Mark

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

Hi Mark,

Thanks,
Lorenzo

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

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