Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 27 May 2013 16:32 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 D7F8721F96C2 for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 09:32:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.063
X-Spam-Level:
X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 mPS6yOfDrI66 for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 09:32:38 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id E068B21F96B8 for <mmusic@ietf.org>; Mon, 27 May 2013 09:32:37 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta14.westchester.pa.mail.comcast.net with comcast id h3BF1l0030QuhwU5E4YdWn; Mon, 27 May 2013 16:32:37 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id h4Yd1l00H3ZTu2S3N4YdJg; Mon, 27 May 2013 16:32:37 +0000
Message-ID: <51A38AA4.70309@alum.mit.edu>
Date: Mon, 27 May 2013 12:32:36 -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>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3794F5@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=1369672357; bh=D5QMiszVozjDeWL8DqSt7/qYQkJtvK4ThDoFYmaNNU0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QBPzEHhoKkTJXLi9jElH1bXpJ74lrcKrQ15aObJeWLV0Zk8SRvBQhx+HnpQn4olZ6 lgWpz5G64/aZ5qUhV1vZw5Rg+dSidO3V7Z4j/x3Ic3unlRY2C0xCf7Dl2feAs683OF mzBF7XJ0qzKXxu+iisMxShfOMalbO8F42D+6A6AuElZzLTmspdJy5gibczmdjHaVC8 U+uV9EY9MvNC8W3KLJ8GlbARLYt/ENTUz+nJGZvJpDufKOkvaD5zW4wHo3ZyzsjbDP k6DQGHfwtC16PvyrqUsozkBEHSU3b+WQ/aHpEnq5hiCmZ7cwV+hF1qgVjaDlfoPAb6 ixlJ7SbloOinA==
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 16:32:44 -0000

On 5/27/13 5:27 AM, 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???

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.

	Thanks,
	Paul