Re: [MMUSIC] "a=extmap" with BUNDLE

Taylor Brandstetter <deadbeef@google.com> Mon, 27 March 2017 17:44 UTC

Return-Path: <deadbeef@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 9A249129442 for <mmusic@ietfa.amsl.com>; Mon, 27 Mar 2017 10:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYTf_L1z8m6F for <mmusic@ietfa.amsl.com>; Mon, 27 Mar 2017 10:44:47 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 634B1129438 for <mmusic@ietf.org>; Mon, 27 Mar 2017 10:44:47 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id n21so44108217qta.1 for <mmusic@ietf.org>; Mon, 27 Mar 2017 10:44:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=33Xp8GI6EqowEQzpH/s3C8ndOvAfW25kMjBjFL4yBFY=; b=q/VUDD/xX2+xL62v3Sv3dCl2926L6YF/bDV/Y181VV06h+1UVDHJQv+0dC4ACOYzQ8 kgXxVnFmsIZD1Rxs1YyRnOTGDFxpCyQIwRM/5oPXzmz7R9S6y1Rv0MFDijNbO1/ymAPh /ZDLs7iPOUX85rILwwzAgQDf8KVcdFOn4sogBDg/omTkUezVJRMjLrYYQkE1HQg1fdu4 +/U/Up8C1UwKCeXdq1/3JGVQYAZPOwlBgBnO3MTTAXjOxghyqVl141llOfxoZPVqLSzY dXAykJWEQE2gE+FM7ra5bgGicmZWRqIYBIOXsAxZyHel80uZ/hsXBn93FzVbTFUbAMZO /+dA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=33Xp8GI6EqowEQzpH/s3C8ndOvAfW25kMjBjFL4yBFY=; b=BOSJHAROr3+wVYgIZ0ldzmg4/d3ZkNerYD5PzgiT5FBzF3NFogEJvRFzFuM1vMcc57 omzHDVzwV3stP1sK+WH3P1CX33pTjrEl+bePKOw58ipiHdt+7a1297CzSu7xhphniWfw LbMtIb3s9wzryRvRTjq/fI8srjONyHXyqRZT01d2wQo4x3DpC1nKwzYbjxgwYoyQmeBg 0yZdGUU4yei7mcJk5J3RAVgU7Uoy5+OK2kdYNRMk1ksADicvnlSLBNZ0gXuU618F5o61 QbQ6nv5K7lRl6fyBp22xmVVLHau89y3r7hGaf3pHUseTPfANtZDMejo4Wv6a8hcfnESy yxEg==
X-Gm-Message-State: AFeK/H378pnog7k+8nieSEy2kJdsis5/AoQIHqFBjeSvLbbvgEX16mtgO9PQQMfLZ1a6PIkZnjisgx4zQVljcyev
X-Received: by 10.237.55.229 with SMTP id j92mr20983043qtb.43.1490636686149; Mon, 27 Mar 2017 10:44:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.154.209 with HTTP; Mon, 27 Mar 2017 10:44:45 -0700 (PDT)
In-Reply-To: <CALiegfmDH4a8nM08ify77pcz+az38KbJ3=x1n-dso7SYoODD1A@mail.gmail.com>
References: <CAK35n0YEA8Cu_v33QsTHXRx70Jw6r-gYT_4rSjYvb6KR+YD81Q@mail.gmail.com> <CAMRcRGTJoOE0HLGwkdW261SiM+J3BCoAiDeq919d+YkyfhU6eg@mail.gmail.com> <CAK35n0ZMX6XVicnuvxHH16ADW5on0n18yK8_VDTLX7B1Gb0XDA@mail.gmail.com> <CALiegfmDH4a8nM08ify77pcz+az38KbJ3=x1n-dso7SYoODD1A@mail.gmail.com>
From: Taylor Brandstetter <deadbeef@google.com>
Date: Mon, 27 Mar 2017 10:44:45 -0700
Message-ID: <CAK35n0beszOvayncKgyC=JLZ+7ST_MW4awZ-VSMYt4qvNefX7A@mail.gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Cc: Suhas Nandakumar <suhasietf@gmail.com>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="001a113d1a742b449f054bb9e6c7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/cDY22aEo9fFLBARslJAl0HhZybk>
Subject: Re: [MMUSIC] "a=extmap" with BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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 Mar 2017 17:44:50 -0000

If extension IDs aren't unique across bundled m= sections, then on
receiving a packet, an implementation may need to determine which m=
section it's "associated" with before knowing how to interpret the
extension IDs. To do this, it may need to use the MID, which means that at
a minimum, the MID extension must be using a unique ID.

But this increases implementation complexity without much benefit (the
benefit being that by sharing IDs, you could more easily avoid running out
of spare IDs). So I'd be in favor of just requiring them to be unique.

On Sat, Mar 25, 2017 at 6:35 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 2017-03-24 19:28 GMT+01:00 Taylor Brandstetter <deadbeef@google.com>:
> > saw that. Which means that individual documents are responsible for
> defining
> > how their extensions work with BUNDLE.
> >
> > But something still would need to define the general restrictions for
> using
> > "extmap" with BUNDLE, such as the ID restriction. Or is that just
> something
> > that's common sense and doesn't need to be specified?
>
> https://tools.ietf.org/html/rfc5285#section-6 just mandates that the
> IDs must be unique within a m= section, but at the end, all the WebRC
> implementations use unique ID values across the entire SDP.
>
> There are some RTP extensions, such as
> http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01,
> that work at *transport* level (rather than at m= section level), but
> nothing prevents such a spec to work even if its ID is not unique
> within the m= sections.
>
> This is, IMHO we don't need a global behavior/requirement for the ID
> values within bundled m= sections.
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
>