[MEDIACTRL] (no subject)

["MUNSON, GARY A (GARY A)" <[e-mail]>]

Hi Chris, Roni, 

Thanks for the latest version of draft-boulton-mediactrl-mrb (-02,
February 6 2008).

Below are some comments/suggestions from me for the next iteration. 

   Cheers,

   Gary


a) Section 1 "Intro", end of first paragraph. "Appropriate" is probably
a better word than 
"accurate".

b) It would be useful to make an observation in Section 3 "Problem
Discussion" for the M:M 
case that another (optional) job of the MRB function may be to ensure
that each application 
gets its fair share of media server resources, according to some
pre-defined rules or 
policy.

c) Somewhere it should be stated how the AS knows the address of the
separate control 
channel of the selected Media Server resources. This is too important a
topic to be left 
unspecified. (For Query, I'm assuming that the answer is that it can be
included in the 
response from the MRB back to the AS. For In-Line ...??)

d) Section 4.2 "In-Line MRB" first paragraph says "The client of the MRB
simply uses the 
signaling to offload the decision making process" and later under Figure
8 says "The result 
of such an architecture is that the decision is left entirely to the MRB
and the Application 
Server has no input into the selection process." ---  I don't think
those are good 
characterizations. With In-Line, the AS would still convey the
attributes that it desires as 
payload (in the SIP INVITE). So the AS does have input into the
selection process. And for 
either Query or MRB, it's true that the decision is left up to MRB, so
that's not a 
distinguishing factor.

e) In Section 5.2 it should be stated that, whereas the Consumer
*Interface* is not needed 
for In-Line, the In-Line option can still use the same media resource
characterization as 
would the Query option for the AS conveying to MRB what it wants. (i.e.
payload in a SIP 
message instead of in an http/SOAP message).

f) Related to (e) above, the draft cites the two options Query and
In-Line, but does not say 
why two options should be considered instead of just one. My personal
opinion is that Query 
is more versatile (I can give examples), while In-Line is simpler and
probably suffices for 
at least common IVR scenarios. -- What are your thoughts about including
such material? At 
present I think the reader not familiar with MRB would be perplexed as
to why two options; 
although I believe that including both is the right approach.

g) It should be stated that some information that the MRB may wish to
know in some 
implementations to perform its role would have to come from or more
naturally come from 
elsewhere than the Media Servers themselves.
For example
 - the media resource allocation rules per application (as per (b)
above)
 - planned and unplanned downtime
 - a simpler MS categorization than raw capabilities (e.g., a 'red' or
'blue' Media Server 
resource)
 - reservations (especially for conferencing)
 - schedules of future MS resource additions (useful - related to
reservations)

h) Related to (g) above, it should be stated that, while the various
figures show the 
Publishing interface as going between the Media Servers and MRB, it
could also be the case 
that there is some intermediate System X (e.g., an operations system)
that has the 
Publishing interface with MRB. System X is aware of the media server
resources and their 
attributes etc.

i) Related to (g) and (h) above, it would therefore be good to allow the
kinds of items 
cited in comment (g) to be included in the so-called Publishing
Interface.

j) Other things to add as items in Section 5.2
   AS request to MRB:
   - application identifier
   - conference ID (as appropriate)
   - 1st-choice attributes set; 2nd-choice attributes set
   - control package that the AS wants to use
   - request to release or add more resources (e.g. for conference
call); not in the initial 
request
   MRB response to AS:
   - MS resource address for separate control channel
   - whether 1st-choice or 2nd-choice was assigned

k) Other things to add as items in Section 5.1
   - control packages supported
   - specific announcement sets supported (not all MS will have the same
sets); could 
generalize to other types of content

_______________________________________________
MEDIACTRL mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl