Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 10 May 2013 22:21 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 996B821F9012 for <mmusic@ietfa.amsl.com>; Fri, 10 May 2013 15:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.15
X-Spam-Level:
X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 THmNwxOliyTy for <mmusic@ietfa.amsl.com>; Fri, 10 May 2013 15:21:21 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 9F92921F89AF for <mmusic@ietf.org>; Fri, 10 May 2013 15:21:20 -0700 (PDT)
Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id aA6m1l00G0ldTLk53NMJtx; Fri, 10 May 2013 22:21:18 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id aNMH1l01U3ZTu2S3QNMJwA; Fri, 10 May 2013 22:21:18 +0000
Message-ID: <518D72DD.2070601@alum.mit.edu>
Date: Fri, 10 May 2013 18:21:17 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> <C5E08FE080ACFD4DAE31E4BDBF944EB1134DEF4B@xmb-aln-x02.cisco.com> <CABcZeBMrgaHGXFi_NRk+znsT-AGnRS5EDLgFhZgGA+VG81BhZw@mail.gmail.com>
In-Reply-To: <CABcZeBMrgaHGXFi_NRk+znsT-AGnRS5EDLgFhZgGA+VG81BhZw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368224478; bh=040dTx+bUlZKO3tP8cH2PHrS5BV6TBtDn89KuDqAZwE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZZVsqCRGt6xmpOr+/RQJcLxnX+ZLl1xwnOZLT+aUOgHALka5mOX9MfKuQO3iJ93V5 rme11Lo0KmJQQKsjyULNL4oLgVF79zJltyuwlANWNNwhzsWcV7PHR4PtoCRd/oeVbT Eqk9V3XJ5W1g6k7TazPtPH0uzQTZiTo1YKvtSzma1A49fan1FQFs5V/wETk7WNzQex jVWqnIjCtKCdFkzj3sPcMnyyZrlrJuO7EKyKlwzSv3ZXQs4kiboWbHo5Wy/VgG/9FN uE65W2iMIQ8zKGtlqbv11Bi/8fR2LCvKAftqJDMRGGsqA+ptDFNFlclnzM6HHJogmW MiXlqbayLlL2A==
Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions
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: Fri, 10 May 2013 22:21:35 -0000

On 5/10/13 6:05 PM, Eric Rescorla wrote:

>      > 2.       SDP m- lines with a zero port value MUST NOT be put
>     inside a BUNDLE group (not in an offer, nor in an answer). There
>     will be a note indicating that, due to this, the number of m- lines
>     associated with a BUNDLE group may differ between the offer and the
>     associated answer. There will also be a note indicating that this is
>     due to RFC 5888, in case people later start to wonder where the
>     “MUST NOT” comes from.
>
>     object to this. I think EKR's idea of doing this explicitly in an
>     offer to indicate that the line is only being offered in a bundle is
>     a good one.
>
>
> I'm sorry to be slow today, but can you point me to the specific MUST
> NOT in RFC 5888.

Section 9.2:

    SIP entities refuse media streams by setting the port to zero in the
    corresponding "m" line. "a=group" lines MUST NOT contain
    identification-tags that correspond to "m" lines with the port set to
    zero.

While this is stated in the context of answers, the statement itself 
seems unqualified. And it would be pretty silly if you could do it in 
the offer and not in the answer.

	Thanks,
	Paul