IETF Logo Mail Archive

Re: [MMUSIC] Feedback requested on requirements

worley@ariadne.com (Dale R. Worley) Thu, 18 April 2013 20:49 UTC

Return-Path: <worley@shell01.TheWorld.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256F021F9154 for <mmusic@ietfa.amsl.com>; Thu, 18 Apr 2013 13:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.768
X-Spam-Level:
X-Spam-Status: No, score=-2.768 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 BxoU2fLXYiwf for <mmusic@ietfa.amsl.com>; Thu, 18 Apr 2013 13:49:20 -0700 (PDT)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC7C21F9130 for <mmusic@ietf.org>; Thu, 18 Apr 2013 13:49:20 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r3IKmL5h021043 for <mmusic@ietf.org>; Thu, 18 Apr 2013 16:48:23 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r3IKmLij2959301 for <mmusic@ietf.org>; Thu, 18 Apr 2013 16:48:21 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3IKmKE12951312; Thu, 18 Apr 2013 16:48:20 -0400 (EDT)
Date: Thu, 18 Apr 2013 16:48:20 -0400
Message-Id: <201304182048.r3IKmKE12951312@shell01.TheWorld.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: mmusic@ietf.org
In-reply-to: <516E56BE.2040606@ericsson.com> (magnus.westerlund@ericsson.com)
References: <201304091539.r39FdjqJ2253833@shell01.TheWorld.com> <516E56BE.2040606@ericsson.com>
Subject: Re: [MMUSIC] Feedback requested on requirements
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2013 20:49:21 -0000

> From: Magnus Westerlund <magnus.westerlund@ericsson.com>
> 
> On 2013-04-09 17:39, Dale R. Worley wrote:
> >    DES F7  If an answerer that does understand the bundle mechanism
> >       processes an offer that contains a bundle, it must be able to (1)
> >       accept the bundle and selectively accept or reject each
> >       constituent RTP session within it, (2) reject the bundle as a
> >       whole, or (3) reject the bundling and selectively accept or reject
> >       each constituent RTP session as separate RTP sessions.
> 
> If you with "constituent RTP session within it" where it is a bundle
> means the RTP media streams resulting from that particular SDP media
> description (m= block) then I believe I agree with 1).

Ah, yes, I meant "media description" instead of "RTP session".  I'll
fix that in the next version of the draft.

> When it comes to 2) what makes this different from rejecting each m=
> block within the bundle?

If we allow bundles that contain zero media descriptions, then it is
conceptually possible that the bundle is accepted but all of the
constituent media descriptions are rejected, leaving the bundle
empty.  I do not see an immediate use for that, but in the long run,
it is desirable that the mechanism is able to express that.

> 3) is required if legacy fallback at all going to be available.

Dale

v2.23.0 | Report a Bug | By Email