Subject: [MEDIACTRL] To 'MRB' or not to 'MRB' - That is the question

From: "Chris Boulton" <[email-masked]>
Date: Thu, 7 Jun 2007 13:12:15 +0100

Hi All,

As promised on a call a couple of weeks ago, Roni and I have put
together a discussion document for Media Resource Brokering.  This is a
very rough '00' and we are looking for lively discussion and ideas to
expand for the Chicago meeting.  Until it appears in the archives it can
be retrieved form the following link -
http://www.ubiquitysoftware.com/goto/mediactrl/draft-boulton-mediactrl-m
rb-00.txt.

Best Regards.

Chris & Roni.

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.

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

---

From: <[email-masked]>
Date: Thu, 7 Jun 2007 20:17:24 -0400

Hi Chris, Roni,

I'm glad you're pursuing this topic, especially if more allusions to the
Bard are in store. Here are some observations from me.

1) It should be explained that the Query Model more naturally can
support a broader set of potential requirements than In-Line.

a. For example, with In-Line, presumably the MRB is left to determine
that a MS resource is freed up when a call leg to it is ended (i.e.
seeing a SIP BYE). Whereas with Query, it is the AS that determines when
a MS resource is to be freed up. That may be critical, for example for
conferencing, where participants may be taking an ad-hoc brief coffee or
lunch break and some callers temporarily drop off; the AS doesn't want
those port resources released and thrown back into the pool because
those will be shortly in use again, so it should be up to the AS to
decide when ports are freed up.

b. As another example, again for conferencing, suppose the AS initially
requests MS resources for a conference for 50 ports. An hour into the
conference only 10 ports may be in use, so the AS can tell MRB it is
releasing, say, 35 of the originally requested ports.

c. As another example, Query can straightforwardly allow you some mild
negotiation. AS may ask for a port that can do DTMF and/or speech
recognition, and MRB might not have such a port available, but could
respond to the AS with a DTMF-only port. AS could accept it or not.

2) In-Line may be fine for some scenarios, for example IVR where it's
obvious that when the call leg clears from the MS that the MS resource
is indeed intended to be freed up, and assuming you don't care about (c)
above.

You make the important observation in Section 4.2 that with In-Line the
MRB functionality may have to get a lot more complicated wrt looking
inside messages/message manipulation, including control protocol; and I
agree. I would personally not be in favor of that complexity, and MRB
would have to be renamed to MRBroker/Meddler. But, as just observed,
depending on the scope of application for a given scenario, such as
perhaps IVR, In-Line works fine without hitting that level of
complexity. 

3) As you can probably tell by now, I think that a solution/tool kit
should allow both models. If you have Query, then you also basically
have In-Line because

- as you already say about the "Media Server Resource Publishing
Interface": it can be the same for In-Line as Query

- the manner in which MS capabilities are described for Query can also
be used for In-Line and just passed as payload in the SIP INVITE toward
the MRB

4) Regarding placeholder section on MS Resource Publishing Interface
(5.1), my initial thoughts are

SNMP - you're probably going to want an 'operations' interface like this
for certain reasons anyway; e.g. for MRB to know about planned/unplanned
MS downtime, or potentially as a way of telling MRB about conference
reservations, or setting other rules about which ASes (or services) can
have what portion of the MS pool when push comes to shove

Control Channel - Huh??

SOAP  - Maybe.

SIP Publish or Subscribe - Maybe.  And with Subscribe are you thinking
along the lines of Presence?

5) Regarding placeholder section on MS Resource Consumer Interface
(5.2), my initial thoughts are

SNMP - Huh??

Control Channel - Huh??

SOAP - Good choice. Low overhead and suffices. I don't see it as a
hardship for a SIP AS to be doing SOAP/http for this. Would want to be
clear on exactly what value-added SOAP has over the use of straight
http. 

SIP Publish/Subscribe - Doesn't seem as straightforward. 

6) Hopefully we all agree that the algorithm that the MRB uses to select
MS resources is out of scope, and so we should say that. It could be
simple or sophisticated; not our concern. 

7) Editorial nit. I would not say that the difference between Query and
In-Line is 'subtle' (section 4.2 first sentence).

cheers,

Gary

________________________________

From: Chris Boulton [mailto:[email-masked]] 
Sent: Thursday, June 07, 2007 8:12 AM
To: [email-masked]
Subject: [MEDIACTRL] To 'MRB' or not to 'MRB' - That is the question

Hi All,

Best Regards.

Chris & Roni.

Information contained in this e-mail and any attachments are intended
for the use of the addressee only, and may contain confidential
information of Ubiquity Software Corporation. All unauthorized use,
disclosure or distribution is strictly prohibited. If you are not the
addressee, please notify the sender immediately and destroy all copies
of this email. Ubiquity Software Corporation plc, a company registered
under the laws of England and Wales, Registration 2719723, registered
offices at Eastern Business Park, Building 3, Wern Fawr Lane, St.
Mellons, Cardiff CF3 5EA, Wales, United Kingdom.

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 19 Jun 2007 14:54:52 +0100

Hi Gary - thanks for the review.  I have noted the changes for the next
version of the document (when we have more comments - hint hint :-)).

More comments in-line.

Chris.

[Chris Boulton] Good point.

[Chris Boulton] It does help with such models.  Let the AS decide if
what is provided is 'good' enough.

[Chris Boulton] Agreed.

Control Channel - Huh??

[Chris Boulton] So making use of the Control Framework (new package) for
interactions with an MRB.

SOAP  - Maybe.

[Chris Boulton] Not really.  Just using RFC 3265 mechanisms + RFC 3903
for resource state reporting/querying.

SNMP - Huh??

[Chris Boulton] could not the MRB seen as an operations entity that can
convey am accumulated view?

Control Channel - Huh??

[Chris Boulton] as above for other interface.

[Chris Boulton] I quite like this one as well.  Not so sure about the
requirement for 'pushing' state on change.  Is this just a query?

 

[Chris Boulton] Agreed.

[Chris Boulton] I will change the language.

cheers,

Gary

  _____  

Hi All,

Best Regards.

Chris & Roni.