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

Iñaki Baz Castillo <ibc@aliax.net> Mon, 27 March 2017 20:59 UTC

Return-Path: <ibc@aliax.net>
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 8AE80129659 for <mmusic@ietfa.amsl.com>; Mon, 27 Mar 2017 13:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.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 OMSzEPBanUN1 for <mmusic@ietfa.amsl.com>; Mon, 27 Mar 2017 13:59:23 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 26243129669 for <mmusic@ietf.org>; Mon, 27 Mar 2017 13:59:23 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id w43so62379244wrb.0 for <mmusic@ietf.org>; Mon, 27 Mar 2017 13:59:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Oi6NZcV1DVpLI8zJlKquYqTfTDbu3S4NNXvXvPIf75I=; b=vOKttJ4MSjy4gPZ8GbnfZrmEGSBGNVOkdf8lbNtl1C8B1Ghw+Ajv/g5O9WyP5O2iXG Mgk2MTRbrlCd8cWuvELp9Y/f0h1Y0Ko7LQcmpg/Q5Lx9LUneySRAYp+vltOwJCQqRCku RJurHqN3H+ZjSeJrLJZG43DQIPoCBbPeKcoqn/mJ9dBL1fQjZfYX0BzU8uTKoHQEAb0q 6ZKjzjNv7W//5MAGh344E9mz9NG4lC7KcKze9mSzKM2edr3n0XebsLrDrO+YcS3HgBll LD+NzmhQdF/MRLFiz+hM2XHX8pHr63APF4QkXIrfuP6phjf4lEZWgFt210puQvNctce4 rhPw==
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:content-transfer-encoding; bh=Oi6NZcV1DVpLI8zJlKquYqTfTDbu3S4NNXvXvPIf75I=; b=H1pqgFQR7ZwV6VVYxiw7pWJSDdSvuo3s0ESVQXj2dw4feJcfg3HbTj9+Aw76ZGYzue dLBj3UxrlMQdO8NmNnAF4V1D57nq3MLK8BDnG2lsU+Gd8+7zUQG/glRc2VElytJ4WbtP qT8KkT1A7wFQc9Gu7sDIuFh6WLZPjx6TmOaHc7+EmKLLlCEBjdHqICdmmd9doxs4Vre5 wnmUwVRt3VV++WHmcAU7vYrOufoTyFJISaxJLTmTbva70gld0xp+T4yR5kNIYqX1wizk IuN8sFPYN9hvIamVxFGS6IG3Dq28SQUkF+6bJ+41mzw8RWl2qzauKLkmbfhI3t4OlngW zfXw==
X-Gm-Message-State: AFeK/H15TTaNlxeQ7zP2E9FICNZivdhLzKbkVW2POjPYJH9nsMRxnSoLZyU57wNvrFUTviYZg7huJM+pq1ViGw==
X-Received: by 10.28.182.7 with SMTP id g7mr11760333wmf.108.1490648361597; Mon, 27 Mar 2017 13:59:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.138.222 with HTTP; Mon, 27 Mar 2017 13:59:01 -0700 (PDT)
In-Reply-To: <CAK35n0beszOvayncKgyC=JLZ+7ST_MW4awZ-VSMYt4qvNefX7A@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> <CAK35n0beszOvayncKgyC=JLZ+7ST_MW4awZ-VSMYt4qvNefX7A@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 27 Mar 2017 22:59:01 +0200
Message-ID: <CALiegfkfq5Li9hnKNNNrBpzgi7zacgBv4EM4Pa2c0tXoWXkFXQ@mail.gmail.com>
To: Taylor Brandstetter <deadbeef@google.com>
Cc: Suhas Nandakumar <suhasietf@gmail.com>, mmusic WG <mmusic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/SkzvFKqcTLf0xGkZrJRzzDE8ReI>
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 20:59:26 -0000

2017-03-27 19:44 GMT+02:00 Taylor Brandstetter <deadbeef@google.com>:
> 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.

Yes.


> 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.

Oh no, not at all. It's just about getting the appropriate RtpReceiver
associated to the current RTP packet (this can be done by MID, RID,
SSRC or even PT, as the ORTC and JSEP "RTP Matching Rules" define).
Once we have the proper RtpReceiver, pass the packet to it so it can
set the corresponding RTP extension ID mappings (because those params
belong to each RtpReceiver), and later, let the transport get
transport related IDs (such as REMB or transport-cc) from the RTP
packet.

Well, I implemented it yesterday so... :)

https://github.com/ibc/mediasoup/blob/master/worker/src/RTC/Transport.cpp
https://github.com/ibc/mediasoup/blob/master/worker/src/RTC/RtpStreamRecv.cpp#L57



> 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.

Me too.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>