Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT
Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 27 May 2013 17:42 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 027C221F8E76 for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 10:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.113
X-Spam-Level:
X-Spam-Status: No, score=0.113 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, 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 Vg6WUWv0Udya for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 10:42:27 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 1690521F8ED8 for <mmusic@ietf.org>; Mon, 27 May 2013 10:42:26 -0700 (PDT)
Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta02.westchester.pa.mail.comcast.net with comcast id h0DD1l0050ldTLk515iSGj; Mon, 27 May 2013 17:42:26 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id h5iS1l00F3ZTu2S3Q5iSLu; Mon, 27 May 2013 17:42:26 +0000
Message-ID: <51A39B01.6030305@alum.mit.edu>
Date: Mon, 27 May 2013 13:42:25 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B1C37797E@ESESSMB209.ericsson.se> <519F7DEB.2010809@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3794F5@ESESSMB209.ericsson.se>, <51A38AA4.70309@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C379C4A@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C379C4A@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369676546; bh=aYWYJk5KYxKlaMt3EWpcKSO3hzr/whQUuR5COT33+aE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dOptPhHl6GB+wgNBkuC6g3YkZyor7Kz7SGX8Jhs+IVuUz8L3E/j0z+wuPWmVE/794 w8tCf5+vYAhMQeEepMpR1bS7RtwzakyWRKaPYaEXQAwKZOb1oSSkSP6/l0Sndi7w43 zjn56844EerCnWYVM1wt3kB9NsENPOM+9fxFyHZSmiM2BqKriT9ZPK7EgvciY3aGwA 1BPxS4paCbWTfO/fyqNEJymVoEPn14F2XNSs04t2KzZ9+jipVmQ0yDBUt8i+8GhN+y aWliC/QgPU2F+R7RUUVEAK6Sno25doGDlhPcq6ejsx09bQapnGnWSyy86pLeJ1K5OO XbWEwx94aO02Q==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT
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: Mon, 27 May 2013 17:42:36 -0000
On 5/27/13 1:16 PM, Christer Holmberg wrote: > > Hi, > >>>>> At the interim yesterday, we agreed to use the SDP BUNDLE group >>>>> attribute to indicate on which port bundled media will be sent. In an >>>>> SDP offer, the order of the attribute mid values can be used by the >>>>> offerer to indicate a "wish", but the first attribute mid value in the >>>>> answer indicates where the answerer will eventually send bundled media. >>>> >>>> This could be interpreted to mean the first a=mid value in the SDP. >>>> I'm sure you mean "the first mid value in the a=group:bundle" line. >>> >>> Yes. >>> >>>> Or perhaps "the first mid value in the bundle group" - assuming there is a definition that "bundle group" means an a=group:bundle line. >>> >>> In the draft "bundle group" means (or, at least is supposed to mean :) the bundle grouped m- lines, and in general I think it is better to explicitly mention the line/attribute. >>> >>>> This can be "future proofed" by saying that the first mid value in the bundle group in the answer that references an m-line with non-zero >>>> port value. I realize this adds nothing unless 5888 is revised to permit m-lines with zero port in a bundle group. But at least it will be ready for that, and harms nothing. >>> >>> I agree, but suggest a little different wording: by saying the first mid value in the group attribute MUST NOT represent a port zero m- line. >> >> I just want to be sure we're clear here. >> >> Are you saying that even if we relax 5888 so that we may have m-lines >> with port zero in a bundle group, that the *first* mid in the bundle >> group can't designate a zero port??? > > Yes, for BUNDLE. It doesn't have to be a generic 5888 rule. > >> I guess that should always be possible as long as there is at least one >> with a non-zero port. >> >> Do we have a possibility, with ICE, that all the m-lines in the bundle >> will have zero port? (Because we are waiting for ICE to figure out the >> actual port.) Or are we going to use something else for that purpose? >> >> As long as there is no possibility of having a bundle where all the >> ports are zero then I'm ok with what you propose. > > I hear what you're saying. > > But, in that case saying "first non-zero mid" does not work either, does it? :) Yep, you're right! > Another option is to also allow mids for zero-port m- lines to be first. A first mid for a port zero m- line would mean that there is no port for bundled media. Maybe there could be a use-case for that. That sounds like a bad choice if one of the other m-lines in the bundle has a non-zero port. So maybe your rule is best, if it works: first mid in bundle must identify an m-line in the bundle with non-zero port if there is one. If there are non with non-zero port then it can refer to one that is zero. But we can't take this too far without deciding if we want to allow rejected m-lines in bundles, and if so, what that means. Thanks, Paul
- [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT Christer Holmberg
- Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT Paul Kyzivat
- Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT Suhas Nandakumar
- Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT Christer Holmberg
- Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT Cullen Jennings (fluffy)
- Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT Paul Kyzivat
- Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT Christer Holmberg
- Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT Paul Kyzivat
- Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT Christer Holmberg