Re: [MMUSIC] Bundle offer with different ports - where to expect media?

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 22 May 2013 14:16 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 D8E1021F9232 for <mmusic@ietfa.amsl.com>; Wed, 22 May 2013 07:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.311
X-Spam-Level:
X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[AWL=0.126, 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 FP39UwOa6bY4 for <mmusic@ietfa.amsl.com>; Wed, 22 May 2013 07:15:55 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id E398A21F91CA for <mmusic@ietf.org>; Wed, 22 May 2013 07:15:54 -0700 (PDT)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta12.westchester.pa.mail.comcast.net with comcast id ez2F1l0091swQuc5C2FtVM; Wed, 22 May 2013 14:15:53 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id f2Ft1l00V3ZTu2S3b2FtyT; Wed, 22 May 2013 14:15:53 +0000
Message-ID: <519CD318.7020605@alum.mit.edu>
Date: Wed, 22 May 2013 10:15:52 -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: Emil Ivov <emcho@jitsi.org>
References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <CAPvvaa+A=LkYp9A+wENAABwCYaQcD0HVeX4o+O_16iJRPXZfNw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <CAPvvaaJsPNk1DAJXYoc8aUgZ0ZayV_8q84W=Mm7vwuRRGuwC-g@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519BF676.5070500@jitsi.org>
In-Reply-To: <519BF676.5070500@jitsi.org>
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=1369232153; bh=pvhaeCBxBhSTpdg1taxMzADPzFz8oJEpJBcbOnnoECE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rkFmRoknC7FwKk4+VSpsGxCo2lJiApzGwWWkgfRRun2NCiJevFVnFeq4l0szWjEs9 wzIXpnzJO4GCY06xiSb0gsmR1F49p9Nlr/q2uInOSuFWMaQTBdb/pZA6GL5Zk6qwcC iSHjjWyTQvUtdfxLbDT237Ek41l4bgyCPYV5S2fDG8Twb094s9U0YCAryniYl3HJR6 FJosOhNYeomxTdO6q9KKQ7SM8EQr0+qRU0JqE5nDmGIEzQI9Tc1eDonnAi9hyJYbL8 dxlbA+BCfT2w2GtdP/7MHUVwKTel177H6IBPSaDtOVwe0FZc9+S3W0NxblRNt5I2GM RVGZc7NqWH40A==
Cc: mmusic <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media?
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: Wed, 22 May 2013 14:16:01 -0000

On 5/21/13 6:34 PM, Emil Ivov wrote:

>> The point of wanting the one line unbundled is so that it can be
>> *received* on a different address/port. Perhaps there is a separate
>> device or process that will be supporting that one, that must be reached
>> at its own addr/port.
>
> Yes, sure. My point was that the party that unbundled the one m= line
> can receive it separately. The party that sent the offer can keep
> getting it on the same port.
>
>> Unless you expect that this would have a common addr/port on the
>> offering side and different addr/ports on the answering side.

Your statement above seems to be exactly what my following statement says.

>> But we
>> investigated that approach early in the bundle discussions, and gave it up.
>
> No I don't and I suspect you misunderstood me.

I must be misunderstanding you. Your "no I don't" comment seems to be in 
direct conflict with what you said above.

But maybe we don't need to keep discussing this. It seems the discussion 
has moved beyond it.

> Also in all my comments I kept noting that we shouldn't be allowing the
> answer to unbundle a single m= line. In your response to Cullen you
> seemed to agree with this so I guess we are in agreement.

Its getting hard to sort out what these statements mean out of context. 
So I don't know.

>>> Still, the thing that I don't quite understand is: if the answerer has a
>>> problem with the c= line, how could that problem only apply to the first
>>> m= line and not to the entire bundle?
>>
>> Presumably this would only happen if the c= for were not all the same in
>> the offer. Certainly that is possible. When allocating "ports" for each
>> m-line one might also end up with different addresses.
>
> This makes me wonder: should we even allow for different c= addresses
> within a bundle? The reason to use different ports was a compromise, not
> a choice based on the necessity to give that option to applications.
> While falling back to different port numbers is defendable, I don't see
> how we would justify the possibility to fallback to different c= lines.

When faced with a choice of leaving something general or narrowing it, I 
opt for leaving it general unless there is some compelling reason to do 
otherwise.

IMO in the entire discussion, when we talk about "different ports" that 
is really shorthand for "different address/port pairs". (And this 
includes cases where the addresses are different and the ports are the 
same.)

If the offerer needs a bunch of address/port pairs to assign to the 
different m-lines of the bundle, it will presumably allocate them out of 
some pool available to it. That pool may include multiple addresses as 
well as ports. Restricting to a set that all share the same address may 
cause it difficulty. An example of where this might occur is if it is 
using STUN/TURN to get the address/ports.

>> Consistency is good. But isn't it just as consistent to say that the
>> first *accepted* m-line defines the bundle addr/port as it is to say
>> that the first offered m-line?
>
> The bundle suggestion started out by saying that all ports would be the
> same. We then moved to a version where we would use different ports, in
> order to prevent some non-bundle endpoints from fainting at the sight of
> port reuse. We still agreed that the first one is the bundle port and
> the others are there just for fall back. So far so good.
>
> Now we are discussing the possibility of saying: your bundle port will
> be the first one you offer, unless the answerer rejects that m= line, in
> which case it could be the port of the second m= line, or the third one ...
>
> I agree it wouldn't be the end of the world, but to me this doesn't
> sound particularly consistent.

I agree it is a complication. If the alternative is saying that the 
answer can't unbundle or reject the first m-line, or that if it 
unbundles it then it will be bundled on one end and unbundled on the 
other end, then that is also a complication. So its a value judgment 
which complication is most acceptable.

	Thanks,
	Paul