Subject: [MEDIACTRL] input to MRB draft re Consumer Interface

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Thu, 18 Jun 2009 15:16:46 -0400

A few of us had an informal call on June 17 to discuss MRB interfaces
and use case motivations - recall the MRB!!! thread; specifically Chris
Boulton, Lorenzo Miniero, Gary Munson, Victor Paulsamy, Adnan Saleem.

Below is a brief summary of where we collectively came out on some
particular items on the Consumer Interface (that has Query and In-Line
flavors), which we offer as input to the mediactrl MRB draft.

Gary also on behalf of Chris, Lorenzo, Victor & Adnan
----------

Query
     - It should be possible for the AS to tell MRB when it no longer
needs previously-assigned MRB resources
     - It should be possible for the AS to tell MRB the quantity of
resources it needs (e.g. for conference with N participants) 
     - It should be possible for an AS to modify quantity in a former
request upwards or downwards
     - It should be possible for an AS to convey an application ID to
the MRB in a request
    - It may be desirable for the MRB to reply to an AS request with
more than one MS option (use MS X or use MS Y); in which case it should
be possible for the AS to tell MRB which it ends up using; consider
further

In-Line
-	Our initial take is that the first, third and last above items
cited for Query should not be part of In-Line, which is intentionally
simpler; but perhaps further exploration could reveal simple ways to
achieve some of that
-	It should be possible for the AS to pass the same kinds of MS
attributes to MRB in a SIP INVITE as would be conveyed in a request
using Query mode

General observations
-	 There is no intent to impose a level of intelligence or degree
of precision with which all MRBs operate. But there is an intent to
*allow* for a fairly sophisticated MRB for support of certain use
cases/needs having to do with likelihood of MS resources being available
to an AS as MRB believes, allocation of MS resources across different
types of applications, efficient use of MRB; generally related to large
conferencing or temporary high-volume IVR scenarios or cross-application
sharing in general.
-	It is understood that MRB knowledge of MS resource utilization
is imperfect. However, an MRB *could* have a sufficiently  accurate view
of MS spare capacity such that the likelihood of an MRB identifying a MS
resource for an AS request that cannot be honored by that MS can be
quite small. MRB could use heuristics, tuned over time through
experience and analysis of patterns of use, to translate raw info from
the Publish interface to a more refined view of spare capacity.