Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId

Iñaki Baz Castillo <ibc@aliax.net> Tue, 04 December 2018 11:45 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8AF126CB6 for <rtcweb@ietfa.amsl.com>; Tue, 4 Dec 2018 03:45:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level:
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 p_-4OVZHFcog for <rtcweb@ietfa.amsl.com>; Tue, 4 Dec 2018 03:45:18 -0800 (PST)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 BB1BE128A6E for <rtcweb@ietf.org>; Tue, 4 Dec 2018 03:45:17 -0800 (PST)
Received: by mail-vs1-xe2a.google.com with SMTP id y27so9611263vsi.1 for <rtcweb@ietf.org>; Tue, 04 Dec 2018 03:45:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SMaLAJJKNwbQR/R/y7jzyw0/OF93lPONtUr7IAGDBRQ=; b=CjmZXTyx4OYXVHGI9oAwBP6ZT5TLIaeTt8cGvNi2OqLPljAheR8yB/C3X4EuKnQWoV /NEUWpkIXgrKFBcJIhnuEt8Dz3QQ4S3hXnn8CCFWdjU8lo9dA7pMq1g8C87iFgqfOE2y eg55qD2XRwjn18xETN5N0k32sCGK7vkQ/sQvSOuqSxJNrwEnA5t2uvQHgtYD3nBg8Tz3 0OKyAiYYDEqZfyeQQhvqtWzY5tZinLNrLAHMhaBSA34SA+av4kphYlRGbc5gwavJIYsS CmvWF0tQZyFKOWZ6rMQOs/m7TXT8ReeDY4nsr2h1Gtks9BfaPdOcWKrzhR5f83aS96le K92w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SMaLAJJKNwbQR/R/y7jzyw0/OF93lPONtUr7IAGDBRQ=; b=G4d1bcXLP+iXCkvbaWO+oeB34LszdJg6VFlyycp0KpSmYcR6lX6XiRJeA5oqVPvEy7 WuFQLzdAHM+1nv3eVYrxxpTUPnVcNqtiui5pmZ3ATupwTTQPVowKBS3KCB/Dy9fxaBai mfQSMKF2DJ74B2Vx7NiaTq8YEFz/aSIuPfa54YVnXRkdlJ1m2sfAlxmyHnBrEN0qJ6md jTJISWGMeHZ4ql1gdME0YcgVx6Kung0VtvT8mrL4X9WM5aDG9bJuwO7nAm3SCO2e7Rsl dtsEqdtu3FqIAzykogkiEzENYtxVvFHupzE0WcMkajW2srV/MUyixvDBHsykG2r7kCjy u/og==
X-Gm-Message-State: AA+aEWZKMGWppnuI6RMNk4z5qiJWyGQwfZiPmJX4b7ql1ZSstdq9hQp3 bijZ3cTGzamUE/6EE0EFvldrVN1XTlPcGHAbS48vig==
X-Google-Smtp-Source: AFSGD/UE12DnBQp7Uy8jUqYpfw2+uEvzKfZtV/KgpUrUvVe1sV/ViHfW6LU6oMypKh9O+ETX5zblw/TfZ7bCDV8FNx0=
X-Received: by 2002:a67:6204:: with SMTP id w4mr8802705vsb.68.1543923916698; Tue, 04 Dec 2018 03:45:16 -0800 (PST)
MIME-Version: 1.0
References: <CALiegfm=++8o=Ou1Tgu6bxyiVdw2ysgM5HnjRqi2hJBoy476yg@mail.gmail.com> <AM0PR07MB4979C0EC8765FA2DF70E613395AE0@AM0PR07MB4979.eurprd07.prod.outlook.com> <45beb8d6-6578-dc98-4ff7-1be7a55c0687@gmail.com> <AM0PR07MB4979571D1B2933258A18544A95AE0@AM0PR07MB4979.eurprd07.prod.outlook.com> <13ff90af-d62e-2f47-3ccc-16ca4e9e3cac@gmail.com> <CALiegfnh-_mMXpmwWnjjX=iayN0WaveHZOHuMrXk9=Tfgx2Z+Q@mail.gmail.com> <2613a4ff-0855-4f78-d3f0-9f9aaaf9ecdb@gmail.com> <CALiegf=ROnLmc388vDO3BJZdzO8q=Sy9mP6F4xTY7rGVZ9CtyQ@mail.gmail.com> <1af3105f-5e66-548d-cb31-6aaf9f2cd0b4@gmail.com> <AM0PR07MB49796A63E10D9CC57E1DD20F95AF0@AM0PR07MB4979.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR07MB49796A63E10D9CC57E1DD20F95AF0@AM0PR07MB4979.eurprd07.prod.outlook.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Tue, 4 Dec 2018 12:45:05 +0100
Message-ID: <CALiegf=ihCKCrsGJ_L7e8by1J7xc8HWCgLuZDHU1XVvcg59x7Q@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Cc: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, rtcweb@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/A9ByQDb8qM90V1vCBjpumt5toIM>
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2018 11:45:20 -0000

On Tue, 4 Dec 2018 at 10:58, Magnus Westerlund
<magnus.westerlund@ericsson.com> wrote:
> However, an RTP middlebox has the freedom to introduce those header
> extensions when switching. They do not need to be sent end-to-end all
> the time. So after the initial establishment of them, I see it as the
> central middlebox responsibility to ensure that they are included in the
> down stream legs towards the conference participants. Also at least for
> video introducing them only on reception of a FIR also makes sense.

The problem here is well known and happens often in this WG: the lack
of proper layer separation in SDP / RTP. The thing is:

1) MID/RID is valid within the context of a transport, nothing else.
And a transport is hop by hop. The receiver (an endpoint, a SFU, a
MCU, whatever) checks packet MID and then packet RID/RRID to figure
out the corresponding "transceiver" or m section and the corresponding
stream (media, simulcast, RTX).

2) If the receiver is a SFU which is gonna multiplex such a "track"
with many others to send them to a receiver over a single transport
(Bundle) then MID/RID does not make any sense because MID is typically
"0" or "1" etc. So the SFU would need to rewrite MID for each receiver
or just not announce MID support at all in the other leg.

3) In the case of RTX this is much more easier: RTX is just hop by
hop. If there is a SFU in the middle, you don't send a RTX packet
directly to the endpoint. You send it to the SFU (assuming the SFU
sent you a NACK). The SFU "decodes" and stores it. If the receiver in
the other leg sends a NACK, the SFU encapsulates such a stored packet
into a new RTX packet and sends it to the receiver. So RTX is hop by
hop, and hence it does not make any sense to talk about reusing
MID/RID headers for same reasons given in 2).

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