Re: [MEDIACTRL] Chaining the MRB function

"Worley, Dale R (Dale)" <dworley@avaya.com> Mon, 19 September 2011 17:50 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF9321F8C90 for <mediactrl@ietfa.amsl.com>; Mon, 19 Sep 2011 10:50:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.468
X-Spam-Level:
X-Spam-Status: No, score=-103.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zU27hhLnNx-r for <mediactrl@ietfa.amsl.com>; Mon, 19 Sep 2011 10:50:17 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id D898321F8C8A for <mediactrl@ietf.org>; Mon, 19 Sep 2011 10:50:16 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EALaAd06HCzI1/2dsb2JhbABCpzx3gVMBAQEBAgESKDETCwIBCA0IIRAyJQEBBAESCBqHVZkwApsdhhhgBJkFjA0
X-IronPort-AV: E=Sophos;i="4.68,406,1312171200"; d="scan'208";a="304454068"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 Sep 2011 13:52:39 -0400
Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 Sep 2011 13:43:17 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Mon, 19 Sep 2011 13:52:39 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>, "mediactrl@ietf.org" <mediactrl@ietf.org>
Date: Mon, 19 Sep 2011 13:47:45 -0400
Thread-Topic: Chaining the MRB function
Thread-Index: Acxzl90rzZZpFizWR9i7i3WVShXHrwDXGAJS
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B222B1F58DE@DC-US1MBEX4.global.avaya.com>
References: <EDC0A1AE77C57744B664A310A0B23AE220C0DAF0@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE220C0DAF0@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MEDIACTRL] Chaining the MRB function
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2011 17:50:17 -0000

> From: DRAGE, Keith (Keith) [keith.drage@alcatel-lucent.com]
> 
> 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.

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