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

Justin Uberti <juberti@google.com> Wed, 22 May 2013 22:53 UTC

Return-Path: <juberti@google.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 DEB4811E8166 for <mmusic@ietfa.amsl.com>; Wed, 22 May 2013 15:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.175
X-Spam-Level:
X-Spam-Status: No, score=-101.175 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 i72mtw4+fDOf for <mmusic@ietfa.amsl.com>; Wed, 22 May 2013 15:53:42 -0700 (PDT)
Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3AE11E8161 for <mmusic@ietf.org>; Wed, 22 May 2013 15:53:41 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id c13so6653048ieb.38 for <mmusic@ietf.org>; Wed, 22 May 2013 15:53:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iq2gO4s7G9YU9tdSRg4AT40FTpIKlmQxtUo1NyHY6Qs=; b=Wuq+s/VlnLzCu6QJIx+J4DmeNRIQEyffEpWSR5WRSm0axH6a4UxHV0UP1R/E1RtfUW NNo8neXNZfB3VqmWpT0KcH962pwniO+/GZU5knD4vx5az/DOqkBvgpfOI3oh+k0osk7P kWfPNzSQUx3I2vdoIPv8OM5glYyqNxcRCBVxnHOaEU8yRcxfEfaCo3PbXqnwg0xMYDBx G+dv8vbl5XlsoWZdgCzbffUC2mjDg/aftS6r8BptYwrqx/qt73lcpq5mZB5K37m1b3Oe wDTNagKFqYEVKFnnrrkcs2sp4b8+BHw10NF7jvT7N0aVkbNkcM5q7R5+ADGq0mOdDAzR fnfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=iq2gO4s7G9YU9tdSRg4AT40FTpIKlmQxtUo1NyHY6Qs=; b=JqY5613UTVvkx1ALBVyQEhtpkLJoREqwIJ94iYxMFCd8mnW3EdYxiill4IGwR0dPW4 MrNwAB0F1dLvWTls8B4fnc+2JKBiNDZ6PPF6Gu6Sm7ezFUiMX1l4c0sCaeVp0+sOKqaI dCssf5Xx8l+W92L0Bq2ieYWr9Goytl5gFlXYxj8SPDOPcK3+UH2Zh/JPLV8NBE6NAK4Q 6N4ybHMX9Uw9oiVwpQ5AtBAwY7uomLmziXmX0KJcCoDkwLEXo0uPxqyge4yzvsjr82pJ 1I4qE62koJ0IF+lgFIOqZI02t1YHRbxWpDPUD06UMUTTdN3XG+U1U3ZqOXs6SzZJNZOO Ih+g==
X-Received: by 10.50.30.170 with SMTP id t10mr347845igh.95.1369263219305; Wed, 22 May 2013 15:53:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.153.69 with HTTP; Wed, 22 May 2013 15:53:19 -0700 (PDT)
In-Reply-To: <519CCE58.3000807@alum.mit.edu>
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> <CAOJ7v-398_MiXLWjexU0Z0xQju3A-zWuQFkWkJSLPA5UEGAu+g@mail.gmail.com> <CABkgnnXqBzteoxH2qWBw1Xn9PHt2r___UCsp1Eoq4o8_VWvBZg@mail.gmail.com> <CAOJ7v-2xXb=uz3jBAKSXhyJ2mU9BGvYHZ=dkeKcZTWov7udWKQ@mail.gmail.com> <519CCE58.3000807@alum.mit.edu>
From: Justin Uberti <juberti@google.com>
Date: Wed, 22 May 2013 15:53:19 -0700
Message-ID: <CAOJ7v-1NP9jwiqZgpPJmfMtGZMsa+3w2XanrK=HVaE2Dx01iQQ@mail.gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary=047d7bdc0a56ca9c3404dd566f54
X-Gm-Message-State: ALoCoQld67Nb9vnTCsitvTtQmNUzOzc7VLI+ooz5Fgc+sNPicF3G1MXlpLdmzmcuQm+6PDhbtK3oi+EgKzON0ggmk1YZ4PPKm343Gzjim5mSWNOQOouybawXs6Ma20BrX4k+eC9/Eht2P8+m7ZgLVEMLmEwdQnAZsdxoEPWz1Ha0LSi5xJsY+pNuvvXFtslcGGPwEkTyrs/S
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 22:53:43 -0000

On Wed, May 22, 2013 at 6:55 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 5/22/13 1:00 AM, Justin Uberti wrote:
>
>  Taking into account Emil's suggestion as well, this leads to this
>> restatement of the rules:
>>
>> 1.1) An offerer must be prepared to receive unbundled traffic on the
>> offered ports, as if talking to a legacy endpoint.
>> 1.2) An offerer must be prepared to receive bundled traffic on any port,
>> except the port associated with the last m= line.
>> 2) Once the answer is received, the decision on bundled/unbundled and
>> which ports to use is finalized.
>> 2.1) BUNDLEd m= lines use the port of the m= line that appears first in
>> the bundle.
>> 2.2) Unused ports can be discarded at this point.
>> 3.1) m= lines offered with distinct ports may be omitted from the bundle
>> answer, in line with RFC 5888.
>> 3.2) m= lines offered with the same port may not be omitted from the
>> bundle answer, since there is no unbundled port from them to fall back to.
>> 3.3) m= lines that are rejected are omitted from the bundle answer, per
>> RFC 5888.
>>
>> Quick check on 2.1: are we using the m= line that appears first in the
>> SDP, or the m= line that appears first in the a=group:BUNDLE?
>>
>
> IMO it would be best to use the lexically first m-line that has a non-zero
> port and that appears in the bundle group of the answer.
>
> Alternately, it *could* be the m-line with non-zero port that appears
> first in the bundle group of the answer. But if so, the exception in 1.2
> would also need to be correspondingly adjusted.
>
> AFAICT the only reason to mention that exception in 1.2 is that might
> provide an opportunity for optimization, by setting up the port with
> simpler code that doesn't support bundling. I don't see a requirement in
> 5888 that the bundle group in the answer be ordered the same way as in the
> offer. So the one m-line guaranteed not to receive bundled traffic would
> then not be predictable at the time of the offer, so could not be
> exploited. This problem doesn't exist if the lexical ordering of m-lines is
> used.
>

To me, this seems like an optimization that only adds complexity. I don't
think there's likely to be a significant savings by setting up 1 out of N
ports differently.

The one advantage of using the a=group:BUNDLE ordering is that it makes it
explicit where the answerer is planning to send the media, which might be
useful at some point. So I would prefer to use that ordering, and NOT
include rejected m= lines in the answer a=group attribute.