From Internet-Drafts@ietf.org Wed Apr 13 03:00:03 2011 Return-Path: X-Original-To: mediactrl@ietfc.amsl.com Delivered-To: mediactrl@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3BED6E06BB; Wed, 13 Apr 2011 03:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3TWUunDR8Eo; Wed, 13 Apr 2011 03:00:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 211E8E06E4; Wed, 13 Apr 2011 03:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.50 Message-ID: <20110413100002.31902.79699.idtracker@ietfc.amsl.com> Date: Wed, 13 Apr 2011 03:00:02 -0700 Cc: mediactrl@ietf.org Subject: [MEDIACTRL] I-D Action:draft-ietf-mediactrl-mrb-08.txt X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Server Control Working Group of the IETF. Title : Media Resource Brokering Author(s) : C. Boulton, et al. Filename : draft-ietf-mediactrl-mrb-08.txt Pages : 135 Date : 2011-04-13 The MediaCtrl work group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-mrb-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mediactrl-mrb-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-13025014.I-D@ietf.org> --NextPart-- From gm3472@att.com Wed Apr 13 03:33:43 2011 Return-Path: X-Original-To: mediactrl@ietfc.amsl.com Delivered-To: mediactrl@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5B913E06C1 for ; Wed, 13 Apr 2011 03:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wuaaVm-Aaac for ; Wed, 13 Apr 2011 03:33:42 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfc.amsl.com (Postfix) with ESMTP id 9675BE068E for ; Wed, 13 Apr 2011 03:33:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: gm3472@att.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1302690821!14051744!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 3627 invoked from network); 13 Apr 2011 10:33:41 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Apr 2011 10:33:41 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p3DAWeL8022427 for ; Wed, 13 Apr 2011 06:32:40 -0400 Received: from gaalpa1msgusr7b.ugd.att.com (gaalpa1msgusr7b.ugd.att.com [135.53.26.16]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p3DAWamw022381 for ; Wed, 13 Apr 2011 06:32:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Apr 2011 06:33:30 -0400 Message-ID: <2F41EF28ED42A5489E41742244C9117C03CD9A8B@gaalpa1msgusr7b.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MRB Publish interface suggestion Thread-Index: Acv5xjtOlmpOJzKqTa6ERxdGpMvsaA== From: "MUNSON, GARY A (ATTSI)" To: Subject: [MEDIACTRL] MRB Publish interface suggestion X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:33:43 -0000 Thanks for posting mrb-08. I have one modification to suggest for the Publish interface. Currently the Publish subscription element has a 'frequency' child element that says how often the MRB wants to receive notifications from an MS on status of its resources. I find myself wondering whether a notification interval range min and max might be more useful than frequency. I.e., so that the MRB would tell the MS that the interval duration from the last notification to the next notification should be no more than X seconds and no less than Y seconds. That way the MS could optionally be allowed to decide, within constraints, how often to send notifications to MRB. So, for example, when things are working normally the MS might send updates every 30 minutes, but if all of a sudden its real time consumption gets clobbered because of some system emergency audit running and the effective number of idle ports is seriously diminished, it can send a next event notification much sooner.=20 Specifying max/min values instead of a single frequency adds a tiny bit of complexity to the Publish interface but could have a significant benefit. And one could still specify a single frequency by setting min and max to the same value. BR, Gary Gary Munson AT&T