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

Iñaki Baz Castillo <> Mon, 03 December 2018 21:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DFDE12D4ED for <>; Mon, 3 Dec 2018 13:30:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Status: No, score=-3.36 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kYbzIvxu-NYM for <>; Mon, 3 Dec 2018 13:30:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0BB4129BBF for <>; Mon, 3 Dec 2018 13:30:45 -0800 (PST)
Received: by with SMTP id d19so4988340uaq.11 for <>; Mon, 03 Dec 2018 13:30:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zGPzTTFylWPwAsvUFrJuHG0/inqtFXMTtrgiVTh8gsk=; b=N1g3vJafr6bWCdnd3gIvxrSEWuQoiED4+6tm732/Ro0G+AqtMMq6+Qd3JcaZNh0bCD 7LXmKH09v6SMWDxXO6Le1zZj3kWPXcBA3mSl8LrdOXYDmYMoFtHiqx/TrVx5FlGc6dv4 wVZETd0untz7crmZeSKkSznHJMCK6sn8yC2+1FjzO8WCqU+7yoq0/gkEiWW1RYAUI7Ai BX4se3N4PAOHLbm1DVMpEWf8tGcHXIEuiY7Q14RgLBus2BLjKGEYkhP1vAySQCRKol7P RyvAKaZwq7qLpkW7JMAdmt53yJ6pqKCrh9pUoH9PEogaRio6JqYQlpUU/BwT6C0PoC+z oHoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zGPzTTFylWPwAsvUFrJuHG0/inqtFXMTtrgiVTh8gsk=; b=UOmQqzqRt2IixfteunPn/70RDuslAcTWuo8ovs9Rq8bBYwy9Y4ki21LPAu5Ez/j8Ou dVB/bO/yYWjKRnDMomLuaqOWGqYU5N+lg/YO4ff91+jzLff3Yx6Ob8w8dG7u+mWPBftv BDYC3zxEJvl614A7b4EnNKwZLG+0gs3TG+ORoXQajtDlaEMd/nIsLdUpGDI0exO0o6OJ JzC4jSUTof6MrmpLNh/R3/o8quSP58lwbOCQ6QYFIOn9UQbmMlY0ysAZgcDGXeZhn6ok ECb7mCQzNvGH6qSqCd5f3iW5I3Eo15S5U5td+l4w5tgkJfNuQHdrz08qbdrWy0A0tlH8 VuMg==
X-Gm-Message-State: AA+aEWZw8sKkeyG7K4bN/kxMsU29bisISpTKKqaeb0ehVWrJJK47Fjb/ y7su4b0eo/RWJWuhwE8zchiLlmMK+sne4TmGeYMvOQ==
X-Google-Smtp-Source: AFSGD/XttfrEDfazXF7wKNRQmcEcwupZR3eyweyfQSohueffUbknNorbyROBNuA53d/Iaz7AAS5EEKJbPcbv5kLg0uE=
X-Received: by 2002:ab0:7048:: with SMTP id v8mr7566022ual.84.1543872644696; Mon, 03 Dec 2018 13:30:44 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
Date: Mon, 3 Dec 2018 22:30:33 +0100
Message-ID: <>
To: Magnus Westerlund <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Dec 2018 21:30:47 -0000

On Mon, 3 Dec 2018 at 11:02, Magnus Westerlund
<> wrote:

> To attempt to restate your question. For RTP sessions, where there are a
> single source media stream per Media Description in SDP (m= block) and
> where there is explicit MID signalling and SSRC signalling, then one
> will not need RepairedStreamId and can instead rely on explicit MID
> signalling for the RTX stream?
> I think no. I think using RepairedStreamId independent if there is
> multiple source RTP streams or not per media description provides a more
> consistent experience.

So, you say that the receiver would receive both media and RTX streams
with same RID values, and then the receiver would decide whether it's
a media or a rtx packet based on PT, right?

> However, as noted at the start. The use of RepairedStreamId for RFC4588
> RTX format is not well defined and how to handle and detect legacy. So,
> I think an update should be done.

Is that issue related to the fact that RTX packets are supposed to
also carry original packet header extensions?

Why is there any problem with 4588? This is just about the browser
adding RID to RTX packets. That breaks nothing in RFC 4588 (IMHO).

Iñaki Baz Castillo