Subject: Re: [MEDIACTRL] Consumer Interface

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Mon, 6 Apr 2009 23:09:15 -0400

For the specific items mentioned here/below (mea culpa), part of my
intent was to raise some items where our initial take was that they
could be useful, but also so others could think about them further and
weigh in.

Our further thinking is as embedded below - [GAM xxxxx]

cheers,

Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Burger
Sent: Saturday, March 28, 2009 3:11 PM
To: [email-masked]
Subject: [MEDIACTRL] Consumer Interface

There was not any discussion of this on the list, and not much in San  
Francisco.  Speak up now or do not be surprised if we do not include  
these.

On Mar 4, 2009, at 11:06 PM, MUNSON, GARY A (GARY A) wrote:

> 7) Other items for Consumer interface:

>     - we should allow, for conferencing, for the request info to be
granular enough for the AS to say something like "I need 10 conference
ports, 6 of which are codec X and 4 of which are codec Z)
   [GAM - not useful; and could get complicated]

>     - geo location preference of MS resources (e.g., if the AS knows
all/most calls are coming from Europe in a given scenario, then it can
tell MRB a preference of ~ Europe for MS resource location, so MRB picks
the one in Czechia and not the one in Singapore).
   [GAM - very useful for improving QoS; additionally, at least one
service provider in the U.S. has had a need to force the call to be
handled by a MS in a legal jurisdiction (in this case state) different
from that of the caller]

>     - announcement set (not all MS resources may have the same set of)
   [GAM - not needed; an MS can fetch announcements so any MS
effectively has all announcements; and can cache for efficiency]

>     - announcement language (e.g., Spanish or Swahili; would be
implied if you specify which announcement set, but you might be doing,
e.g., text-to-speech)
    [GAM - not needed; for text-to-speech, seems like the same engine
can support multiple languages]

>    - ASR language
    [GAM - not needed; but there is a separate email that includes a
related topic] 

>    - AS/application/service ID, so MRB knows which application is
asking for resources, so MRB can apply any related per-service
allocation rules that it has
    [GAM - needed; in a large network, it may very well be that not all
applications have equal rights, or at least an application gets some
minimal share of MS resources when such resources are tight, so this
piece of information is critical]