[MEDIACTRL] Fw: New Version Notification for draft-ietf-mediactrl-mrb-13.txt

Lorenzo Miniero <lorenzo@meetecho.com> Tue, 10 July 2012 13:46 UTC

Return-Path: <lorenzo@meetecho.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 77E5A21F8714 for <mediactrl@ietfa.amsl.com>; Tue, 10 Jul 2012 06:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level:
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 TDUKgCDvy57q for <mediactrl@ietfa.amsl.com>; Tue, 10 Jul 2012 06:46:27 -0700 (PDT)
Received: from smtplq01.aruba.it (smtpweb23.aruba.it [62.149.158.23]) by ietfa.amsl.com (Postfix) with SMTP id 359AE21F870E for <mediactrl@ietf.org>; Tue, 10 Jul 2012 06:46:26 -0700 (PDT)
Received: (qmail 24432 invoked by uid 89); 10 Jul 2012 13:46:52 -0000
Received: from unknown (HELO smtp1.aruba.it) (62.149.158.221) by smtplq01.aruba.it with SMTP; 10 Jul 2012 13:46:52 -0000
Received: (qmail 7204 invoked by uid 89); 10 Jul 2012 13:46:52 -0000
Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.200) by smtp1.ad.aruba.it with SMTP; 10 Jul 2012 13:46:52 -0000
Date: Tue, 10 Jul 2012 15:46:42 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: mediactrl@ietf.org
Message-ID: <20120710154642.43be1860@lminiero-acer>
Organization: Meetecho
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Rating: smtp1.ad.aruba.it 1.6.2 0/1000/N
X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N
Cc: Chris Boulton <chris@ns-technologies.com>
Subject: [MEDIACTRL] Fw: New Version Notification for draft-ietf-mediactrl-mrb-13.txt
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: Tue, 10 Jul 2012 13:46:28 -0000

Dear all,

during his AD review of the MRB draft, Robert provided us with a lot of
excellent feedback, which greatly helped improving the document. The
result so far is this new version I've just submitted, which will
hopefully need just some editorial refinement to be considered complete.


There's still a pending issue, though, that Robert asked us to bring to
the list. In order to help you understand what the issue is about, I'll
paste here the exact point Robert raised:

   The 4th bullet of section 5.2.2.1's third list of bullets inspires
   the question of whether MRBs in IAMM support offerless invites.
   Please make it clear in the document what an MRB should do with an
   INVITE that contains no SDP.  

The problem in giving a simple aswer to this point is that,
considering the different scenarios that may occur in the IAMM mode, an
offerless INVITE could confuse the MRB. Specifically, as you'll know if
you read the draft, an INVITE reaching the MRB in IAMM mode can be any
of the following:

   1) an INVITE an AS sends to request a new session, or update an
   existing one, to the MRB, and negotiate a control channel with one
   of the chosen MS (in this case, the payload is multipart, containing
   both the Consumer request as XML and the SDP to negotiate the control
   channel);

   2) an INVITE an AS sends to request a new session, or update an
   existing one, to the MRB, and attach a media session to a MS (in this
   case too, the payload is multipart, containing both the Consumer
   request as XML and the SDP to negotiate the media streams);

   3) an INVITE an AS sends to just attach a media session to a MS (in
   this case, the payload only contains the SDP to negotiate the media
   streams).

All of the above scenario are documented in the Examples sections, for
an easier understanding of how they're conceived.

The problem with offerless INVITEs is that the MRB might (WILL) be
confused about what the AS is asking for. The easy way out might be
just saying "the MRB doesn't support offerless INVITEs", but this could
look overly restrictive. An alternative might be adding some text that
explains that, whenever an MRB receives an offerless INVITE, it must
assume it is related to the 3) case, that is, an AS will only
originate such INVITEs when trying to attach a media dialog to a MS.

Of course these are just a few alternatives that have come to my mind:
if you have any feedback or suggestion on how to best proceed on this
matter and close this final issue, please let us know.


Thanks,
Lorenzo



Inizio messsaggio inviato:

Data: Tue, 10 Jul 2012 06:25:12 -0700
Da: internet-drafts@ietf.org
A: lorenzo@meetecho.com
Cc: gamunson@att.com, chris@ns-technologies.com
Oggetto: New Version Notification for draft-ietf-mediactrl-mrb-13.txt



A new version of I-D, draft-ietf-mediactrl-mrb-13.txt
has been successfully submitted by Lorenzo Miniero and posted to the
IETF repository.

Filename:	 draft-ietf-mediactrl-mrb
Revision:	 13
Title:		 Media Resource Brokering
Creation date:	 2012-07-10
WG ID:		 mediactrl
Number of pages: 142
URL:
http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-mrb-13.txt
Status:
http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb
Htmlized:        http://tools.ietf.org/html/draft-ietf-mediactrl-mrb-13
Diff:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-mediactrl-mrb-13

Abstract:
   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.

                                                                                  


The IETF Secretariat


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com