Subject: [MEDIACTRL] Chaining the MRB function

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 15 Sep 2011 13:08:57 +0200

Given that the MRB can look to an application like a resource function, and and to a resource function like an application, it would appear to me that there is not reason why MRB functionality cannot be chained either logically, i.e. visit an MRB which supplies details of another MRB which is then queried for the particular resource, or physically, as in both MRBs operating in in-line mode.

I can so far see no mention of this possibility in the mrb document.

A potential use case might be were the resources are being provided by a different supplier to that which runs the application. The application provider runs an MRB to determine which resource supplier is best able to supply the resource. The resource provider runs an MRB to determine which resource best meets the needs.

Is it permitted, and are there any implications people can think of that ought to be documented in using performing this in this fashion.

Regards

Keith

---

From: Eric Burger <[email-masked]>
Date: Thu, 15 Sep 2011 10:25:07 -0400

I would offer it is permitted. Likewise, it is not un-permitted. Unless there is a compelling reason to talk about it, why talk about it?

On Sep 15, 2011, at 7:08 AM, DRAGE, Keith (Keith) wrote:

> _______________________________________________
> 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" <[email-masked]>
Date: Thu, 15 Sep 2011 14:30:25 +0000

Hi Keith,

I don't think this was ever explicitly discussed. We assumed a single logical MRB, and by definition (so far), MRB identifies a media resource (i.e., MRFC/MS) not possibly another MRB. I think of your scenario as an implementation that distributes MRB functionality and knowledge, as opposed to chaining MRBs.

Some initial thoughts:

For Query mode: In this case 'MRB1' would presumably do an HTTP Redirect back to the AS so the AS can in turn send another HTTP request to 'MRB2', rather than try to send a SIP INVITE to it for a call leg or control channel. So MRB1 would have to be able to make a distinction between what it had identified (MRB2) as in fact being another MRB as opposed to an MRFC/MS. I.e., MRB2 can't simply pose logically as an MRFC/MS to MRB1 in that particular regard.

For Inline mode: I see at least one thing that would need to be fixed/generalized. For IAMM, where MRB acts as B2BUA, to allow for AS sending the call leg to a MS and using a control channel to that MS, due to the way the control channel dialog ID is constructed, the MRB will pass back to the AS the SIP dialog info for the call leg as pertains to the MRB-MS connection (i.e., the call leg SIP dialog info as the MS knows it). If we have multiple MRBs in the path as B2BUA, we still need to get the SIP dialog of the last MRB-MS all the way back to the AS. So MRB1 would have to accept a SIP dialog info element (I forget the actual name) from MRB2, which isn't something MRB1 would expect to get from an MRFC/MS.

In either case, I think the Publish interface could be re-used between MRB1 and MRB2.

So I would see some further doable technical content needed to address in a clear way what you're asking about, as well as simply more explanatory text and expanded definition of MRB.

I personally don't have any significant inclination to add this idea to the current MRB document.

cheers,

Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: Thursday, September 15, 2011 7:09 AM
To: [email-masked]
Subject: [MEDIACTRL] Chaining the MRB function

Regards

Keith

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 19 Sep 2011 13:47:45 -0400

> From: DRAGE, Keith (Keith) [[email-masked]]
> 
> Given that the MRB can look to an application like a resource
> function, and and to a resource function like an application, it would
> appear to me that there is not reason why MRB functionality cannot be
> chained either logically, i.e. visit an MRB which supplies details of
> another MRB which is then queried for the particular resource, or
> physically, as in both MRBs operating in in-line mode.
> 

I am no expert in this, but I've been going over
draft-ietf-mediactrl-mrb.  It looks to me like chaining MRBs is
possible.  The problem is that there has been no intention to make the
interface an MRB presents to an AS look like the interface a MS
presents to an MRB, and similarly, the interface an AS presents to an
MRB does not look like the interface an MRB presents to an MS.

But it does looks like the elements and facilities of the interfaces
contain the needed data, so that if one MRB wished to use another MRB
as a "subordinate" resource broker, it can do so straightforwardly,
even though it is not described in the drafts.

Dale

---

From: Chris Boulton <[email-masked]>
Date: Tue, 20 Sep 2011 12:08:00 +0100

> Given that the MRB can look to an application like a resource function, and and to a resource function like an application, it would appear to me that there is not reason why MRB functionality cann…
Keith - have you seen this - 
http://tools.ietf.org/html/draft-boulton-mediactrl-mrb-location-function-02.

Chris.

-- 
Chris Boulton
CTO & Co-founder
NS-Technologies <http://www.ns-technologies.com>
m: +44.7876.476681

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 20 Sep 2011 13:55:08 -0400

> From: Chris Boulton [[email-masked]]
> 

I believe what Keith is talking about is an architecture where the AS
talks to MRB 1, MRB 1 talks to MRB 2, and MRB 2 talks directly to the
MS.

Dale