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
- [MEDIACTRL] Chaining the MRB function DRAGE, Keith (Keith)
- Re: [MEDIACTRL] Chaining the MRB function Eric Burger
- Re: [MEDIACTRL] Chaining the MRB function MUNSON, GARY A
- Re: [MEDIACTRL] Chaining the MRB function Worley, Dale R (Dale)
- Re: [MEDIACTRL] Chaining the MRB function Chris Boulton
- Re: [MEDIACTRL] Chaining the MRB function Worley, Dale R (Dale)