Subject: [MEDIACTRL] Media Resource Broker -04

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 04 Mar 2009 17:44:25 +0100

Dear all,

Chris and I just submitted an updated version of the MRB draft:

http://www.ietf.org/internet-drafts/draft-boulton-mediactrl-mrb-04.txt

it takes into account the discussions we had at the latest meetings.

To revive the discussion on this topic, we also prepared some cues  
throughout the text. Each cue is labeled as [MRB-##]. We encourage you  
to read the document and provide us with comments and suggestions  
about how you feel the work should proceed.

Thanks,
Lorenzo

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Universita' degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]

---

From: "MUNSON, GARY A (GARY A)" <[email-masked]>
Date: Wed, 4 Mar 2009 23:06:56 -0500

Hi Lorenzo and Chris,

Thanks very much for this draft. Here are some comments:

1) General. On the In-Line option, I think it should be described such
that the AS can indeed pass information about MS characteristics that it
needs. In fact, it should be able pass the same kind of MS
characteristics info as in the Query option, using the same format for
the information. This makes the In-Line option much more useful and
allows the MRB to operate on the same input with either option. (Side
note: I would expect that some MRB implementations would be bi-modal.)

Those without history on the subject may then wonder why there are the
two options, Query and In-Line, since they would both have the AS
passing the same info. And the answer, at least in part, is that In-Line
option may suffice for many common scenarios, such as IVR, and is in
some sense simpler, but the Query option addresses a broader set of
needs. (E.g., with Query, it can be the AS that decides when MS
resources/ports are to be released, which in the case of conferencing
may very well be different from when call legs drop, whereas with
In-Line the MRB infers the MS resource is freed up when the call leg
drops.)

This change would affect various places in the draft.

2) (Partly related to the above), we should say how MRB knows when MS
resources are freed up. My assumption is that
- in the case of In-Line, MRB infers it from SIP signaling (e.g. BYE
from AS or MS), which it will see because it's in the call path
- in the case of Query, AS sends another message to MRB telling it that
the MS resources are no longer needed

3) We should cover the case that the AS asks for a conference for N
participants, where N is large enough and/or MS resources are tight
enough that it requires connection of multiple ( > 1) MS, so with Query
the MRB has to provide MS address information for each MS and the number
of ports at each MS).

4) With In-Line, we should say how the AS knows which MS was selected
for the purpose of establishing a new or using an existing AS-MS control
channel with that MS.

5) To be helpful to readers of this doc't, we should observe that there
may be additional information that the MRB needs to perform its job that
it *won't* get over the Publishing Interface from MSes, for example
(these are just examples)
  - info on reservation requests, e.g., for future conference calls
  - MS resource allocation rules among various different services/AS
sharing the MS pool
  - planned or unplanned downtime of MS resources
  - the planned addition of future MS resources
We could expand the notion of the Publishing Interface to allow what
would in practice be an OSS or BSS to use that interface to convey such
info to the MRB, or we could leave it out of scope. But I don't think we
should be completely silent on this topic.

6) Regarding question MRB-01, my vote would be to remove that topology
example.

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)
     - 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).
     - announcement set (not all MS resources may have the same set of
announcements)
     - 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)
    - ASR language
    - 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

cheers,

Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Lorenzo Miniero
Sent: Wednesday, March 04, 2009 11:44 AM
To: [email-masked]
Subject: [MEDIACTRL] Media Resource Broker -04

Dear all,

Thanks,
Lorenzo

_______________________________________________
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: Fri, 06 Mar 2009 11:27:27 +0100

Hi Gary,

thanks a lot for your great comments!
We'll definitely take them into account for the next version of the  
draft. I've added some comments myself inline ([LM]).

> note: I would expect that some MRB implementations would be bi-modal.)

[LM] I agree, that was one of my concerns as well. What happens if an  
AS only supports one while a MS the other? We definitely need to have  
a common ground, if not the same.

> from AS or MS), which it will see because it's in the call path

[LM] From SIP signaling and MediaCtrl signaling as well, which would  
provide more details about the state of the resources (since it  
wouldn't describe only if users are still connected, but also if an  
IVR dialog is still running, for instance).

> the MS resources are no longer needed

[LM] This may not be given for granted, since the Query model assumes  
an AS queries for a suitable MS and then directly interacts with it,  
without having the MRB on the path. We should clarify whether the MRB  
becomes aware of resources being freed only out of the MS-generated  
events, or if we expect the AS to inform the MRB about it as well  
after it has concluded its operation on the MS.

> the MRB has to provide MS address information for each MS and the number

[LM] You mean something like cascading? This is an interesting aspect,  
and it would be worth investigating how it could be done within the  
context of the MediaCtrl architecture. However, this would also bring  
back the discussion about distributed mixing that took place at the  
beginning of the WG.

> for the purpose of establishing a new or using an existing AS-MS control

[LM], I agree, that's what [MRB-02] note is about in fact.

> should be completely silent on this topic.

[LM] Good point, feedback from the list about a set of info they think  
should not belong in here would be great. Resource reservation already  
was something most of the people agreed upon, if I recall correctly.

> ports, 6 of which are codec X and 4 of which are codec Z)

[LM] This may be a specific use case of the RTP ports availability. Do  
you think a generic approach like the one we already have is enough,  
or do you see good motivations for this additional granularity?

Thanks,

Lorenzo

---

From: Eric Burger <[email-masked]>
Date: Sat, 28 Mar 2009 15:11:24 -0400

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.