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

Martin Thomson <martin.thomson@gmail.com> Tue, 21 May 2013 23:29 UTC

Return-Path: <martin.thomson@gmail.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 1A64F21F86C0 for <mmusic@ietfa.amsl.com>; Tue, 21 May 2013 16:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.689
X-Spam-Level:
X-Spam-Status: No, score=-4.689 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 ggBGq2OnPwvm for <mmusic@ietfa.amsl.com>; Tue, 21 May 2013 16:29:28 -0700 (PDT)
Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9F44721F9193 for <mmusic@ietf.org>; Tue, 21 May 2013 16:29:27 -0700 (PDT)
Received: by mail-lb0-f182.google.com with SMTP id z5so1446100lbh.13 for <mmusic@ietf.org>; Tue, 21 May 2013 16:29:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q/b4M+BQeRsDMuqXQMFtK/6kk9drI+h6ODPc2EJfiOU=; b=IfnRdCw6q3owNzzFsgN6iE2C1oxYFsNJy4Apn77ckvmI/TZareOy9hnPtbSEtAxWxT AdXYKVuqZnG0p+OgdqORP6M7BhSzN673vXp1JiLZQDURFbRJiiDOchZhEQ5QBXTUr88K 5hE2ulj/J4NYWgf2eDTgir25PQhnETn/Wt6+OSVY96J9mMQ6nFw0phkOEOfRi5zuxEwq 1Av/uQ0BZ78xqaudYxLKq8UdoNakBXbyh6PYo6MGyMAuDvJM44OWSAVdtDNMS3JixKhw 88asJbHkwxiGulhf4KKmIJP7NBpCUwMIUBUbhXF34QzlbJ34qcbC0Acb2/nb8x5LjJ3g C3Nw==
MIME-Version: 1.0
X-Received: by 10.112.19.9 with SMTP id a9mr2704839lbe.80.1369178966190; Tue, 21 May 2013 16:29:26 -0700 (PDT)
Received: by 10.112.235.233 with HTTP; Tue, 21 May 2013 16:29:26 -0700 (PDT)
In-Reply-To: <CAOJ7v-398_MiXLWjexU0Z0xQju3A-zWuQFkWkJSLPA5UEGAu+g@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>
Date: Tue, 21 May 2013 16:29:26 -0700
Message-ID: <CABkgnnXqBzteoxH2qWBw1Xn9PHt2r___UCsp1Eoq4o8_VWvBZg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Justin Uberti <juberti@google.com>
Content-Type: text/plain; charset=UTF-8
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: Tue, 21 May 2013 23:29:33 -0000

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.