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

Justin Uberti <juberti@google.com> Wed, 22 May 2013 05:01 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 DA07721F9253 for <mmusic@ietfa.amsl.com>; Tue, 21 May 2013 22:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.403
X-Spam-Level:
X-Spam-Status: No, score=-101.403 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 VEAudm38W2MJ for <mmusic@ietfa.amsl.com>; Tue, 21 May 2013 22:01:21 -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 5A78221F859B for <mmusic@ietf.org>; Tue, 21 May 2013 22:01:18 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id c13so4152074ieb.24 for <mmusic@ietf.org>; Tue, 21 May 2013 22:01:18 -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=rO7psW5I7vJoGmnIISEfdHmWKlYf33lcpkGgimR67bQ=; b=KYBEousVeQW6rzaSXodfD8FSFrSq+ErkS9ZVA4aThRR0s/cJAe9Z1mWv5LW/5k+kiK vp3ZN+2gdC9LcMWKo/xW32FrMIGEUvks33N851dhT9hvL+OLY1zGjrvPbOHAJ8B/iqqa h2gsUwDmn90gZCR769zwDsnGVgmUXHyxm340qazfl6U5Uo8MdTorL29i0DPkatYsDdmJ wTTHsnOyxCqRqEhF2a3APWe5R+04AaTqAWa031wrgZyyqRZH84Gb+DwGr+pSEM6M61kL OLiZMR/g6dDMdgX0bH/3uN2uU4oDRWmDeSQN6kkWITObq79nBP3P42p/LzcNcBhQWvov Ju2w==
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=rO7psW5I7vJoGmnIISEfdHmWKlYf33lcpkGgimR67bQ=; b=TT1LiSiSbXB+qtStDQd0LxKk3gUw2FG3Babkq2fXEvEDeahq6YsqQilXJwujTDfuuQ t2v52hJR1cjRQlvL+PPrdtGy2VvfaEUAOWBcC1w+TTjHhX8M+o/1SCgO/0gz7LvNADlF LAYbgRFM2Itq8Ey2F1RKrQp21MBP0ZrRDmgR7x/O99nUBDEBjrWWKmrz6JRD6pNpr9I7 JEP7QhWiAd6R17LHlmfUxEEFertc3s5ztKC1bW1JmGfAgs9xm6x+FX+/VMBtwkaKupzX qFmONYd+AO2MA9yDoSTnkxldDaXUONyIHfziUpsHJ3Y6J/CbLTRmGldeQB57tfcuKXDP alBg==
X-Received: by 10.42.92.78 with SMTP id s14mr2668354icm.40.1369198877883; Tue, 21 May 2013 22:01:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.153.69 with HTTP; Tue, 21 May 2013 22:00:56 -0700 (PDT)
In-Reply-To: <CABkgnnXqBzteoxH2qWBw1Xn9PHt2r___UCsp1Eoq4o8_VWvBZg@mail.gmail.com>
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>
From: Justin Uberti <juberti@google.com>
Date: Tue, 21 May 2013 22:00:56 -0700
Message-ID: <CAOJ7v-2xXb=uz3jBAKSXhyJ2mU9BGvYHZ=dkeKcZTWov7udWKQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=14dae9d7c094be6b5804dd477420
X-Gm-Message-State: ALoCoQlviUSWrYQs2O1ju0BOhUwDSSJQC8cBr13CuR813+qmyfhf52Cgzg6cwrTM8GDzPOn/kJf7f9keBStub+c6qPpJOv7bJIEKMmFIzC6JTclAD2HbR0eBoVqalMH/Me9dBBEZE3rhMnVnltJWNrmM7c5OoutLK2Ct3ivO1CfO0w3KmPeiitv3S9FK5twfoWHZPE0pHOF2
Cc: mmusic <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>, 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 05:01:23 -0000

On Tue, May 21, 2013 at 4:29 PM, Martin Thomson <martin.thomson@gmail.com>wrote;wrote:

> On 21 May 2013 15:38, Justin Uberti <juberti@google.com> wrote:
> > Lots of discussion here; is this an accurate summary of the discussed
> > behavior?
>
> Yeah, this discussion was too much for me to track properly.
>
> > 1) BUNDLE offerers must be able to receive on any port (until they get a
> > BUNDLE-compatible answer)
> > 2) Once the answer is received, bundling is activated, and BUNDLEs use
> the
> > port of the first non-rejected m= line in the offer
> > 2a) at this point, the other ports can be discarded
> > 3) All m= lines offered in a BUNDLE must be present in the answer, unless
> > they are rejected
> > 3a) no selective unbundling/BUNDLE splitting is permitted
>
> Only one qualm with that last item.  Agree with the splitting, but I
> believe that the restriction on unbundling only applies if you create
> an offer that assumes bundle support (i.e., same transport parameters
> on every m-line).  This is the optimized option that I expect we'll
> need a constraint for in WebRTC.  In that case, you don't have a port
> to use for the unbundled m-line.
>
> It should be possible to have a new m-line negotiated out of a bundle
> (but not into another bundle).  It's just a refinement of the
> answerer-does-not-support-BUNDLE case.
>

I agree. This carries over into subsequent offers - if you add a m= line
that assumes BUNDLEing (i.e. uses the same transport parameters as an
existing m= line), the recipient cannot choose to unBUNDLE it.

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?