Subject: [MEDIACTRL] MRB Discussion - Consumer Interface

From: "Chris Boulton" <[email-masked]>
Date: Wed, 27 Aug 2008 13:38:30 +0100

Hi All,

As promised in the face to face meeting in Dublin I would like to start
two threads surrounding the interfaces proposed in the MRB draft
(http://tools.ietf.org/html/draft-boulton-mediactrl-mrb-02) which will
form the basis of the next version.  This mainly is concerned with the
'Consumer' interface (for example, the App server requesting an MS to
carry out service from an MRB) while the second mail (to follow) will
look at the 'Publishing' interface (for example, the MS publishes
information to an MRB).  I would like to split the discussion for both
mails into two parts - firstly, the 'type' of protocol we think is
appropriate and secondly, the contents of that interface.

Consumer Protocol

As discussed in the meeting I think we should revisit an earlier mail
discussion in which a preference for 'SOAP' was established for the
consumer interface.  I believe, after further thought and discussion
there might be some doubt on this topic.  I have heard suggestions that
we should maybe consider simply using a plain HTTP+XML interface (REST)
to reduce complexity and align with other areas of the IETF.  I
personally have no problem with either approach and would like to hear
your thoughts.  For more information on the background of the Consumer
interface read the appropriate section from the link at the start of
this mail.  Thoughts please?

Consumer Interface

Here is the current list of 'data' that we accumulated last time looked
into this interface.  Please take a look and comment on what already
exists + what you think is missing etc (it looks very thin at the
moment).

- Number of active RTP sessions (including codec information)
 
     o For example, 10 G711 RTP sessions, 3 H.264 sessions.
 
   - Existence of an existing Conference Instance
 
     o Linked to Conference Control Package ID.

   MRB Response to AS
 
   - Address of selected Media Server.
 
   - Reason for non-selection of a Media Server????

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

---

From: "MUNSON, GARY A (GARY A)" <[email-masked]>
Date: Thu, 28 Aug 2008 14:55:09 -0400

Hi Chris and folks,

On Consumer Protocol, I am ambivalent between plain HTTP or SOAP,
assuming both meet all our needs.

On Consumer Interface, mostly dredging up stuff from past discussions
and also looking at what's in the draft in the Publishing section, I
think we want to also take into account in requests from an AS
1) A variety of 'attributes' associated with sessions/'ports', some of
which are in the Publication Interface list in the MRB draft that
acknowledges some of those items would likely be appropriate for the
Consumer interface as well: DTMF capability - receive or produce; other
tone capability (such as TTY/Baudot); speech recognition capability
info, announcement set identifiers (not all MSes may contain all
announcements); text-to-speech capability

2) Geographic preferences for where the MS resources are located

3) Ability for AS to modify a prior request - add more or drop some
'ports'; especially useful for conferencing

4) Ability for AS to tell MRB when the MS resources are to be returned
to the idle pool (this could be viewed as a special case of the prior
item)

5) Application ID (so MRB can perform, e.g., a fair-share allocation
function among various applications)

6) Application-specific info; MRB would use it in association with the
prior item (6)

7) The set of control protocols the AS can use with whatever MS is
selected; e.g., the AS can use A or B (but not C)

8) Second/alternative choice set of resources if the preferred choice
cannot be granted?? 

9) Estimated duration of use??

In terms of what the MRB responds with, also include

a) MS address to which the AS can establish a corresponding control
channel; potentially separate from/in addition to the MS address(es) for
setting up the SIP sessions?

b) allow for multiple MS addresses; e.g. to cover the case where a large
conference will straddle more than one physical MS

c) if (b) above, then in the case of mixed resources, which types of
resources are associated with which MS address

d) related to (7) above, which control protocol the selected MS can
support; e.g. the MS can do A (but not B or C)

e) if (8) above, then which choice was granted - first or alternative

Lastly, I would float two questions
1. Should we allow for some kind of AS-MRB interaction where one or the
other can do a sanity check on an outstanding request? E.g., MRB can ask
an AS whether it's still using the resources associated with prior
request X.

2. Should we allow for some kind of flow control mechanism so an MRB can
throttle the volume of requests it is receiving? 

Happy to discuss anything further. Thanks.

cheers,

Gary

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chris Boulton
Sent: Wednesday, August 27, 2008 8:39 AM
To: [email-masked]
Subject: [MEDIACTRL] MRB Discussion - Consumer Interface

Hi All,

Consumer Protocol

Consumer Interface

 

   MRB Response to AS