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

Sergio Garcia Murillo <> Sun, 02 December 2018 15:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C4F9130EC8 for <>; Sun, 2 Dec 2018 07:25:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9csCBsXRESdP for <>; Sun, 2 Dec 2018 07:25:45 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB7B212F1AB for <>; Sun, 2 Dec 2018 07:25:44 -0800 (PST)
Received: by with SMTP id x10so9599154wrs.8 for <>; Sun, 02 Dec 2018 07:25:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=W9XTs24D5O7jq61mNgJ4imCi/ydPt8KYPyRSqvvFYPc=; b=pWOE3sxeRGk7yDXfLbm1mgPpSu+K5cJ44sWGqR1etMKZt8ZSPYTO0BUzRH0MO6eT1Q xz9TrzNkNx7qVEArcMISVaKIVZmYig93Lc1AnVZz0ZL7izzooZiJuK866vmxr5IO9SHO iMrzV4TOjrRHATFw8iqujRShjBFFX6vcAstKMugsaMHBvHF/N8SIWKnmee34YLUUcRj9 BddJLSEcDZ0t2AzpjCejdz+rpPwQ7DhPNcgxsXunzKIblPndQi/cqAIujVEEBm/AebrK OlVs5iQVDHMUEOPF8yXhghRexCvHN+yVaSowpSSUQ9jm8yPBehzrbUd78Ee/+6KFiB+I aO3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=W9XTs24D5O7jq61mNgJ4imCi/ydPt8KYPyRSqvvFYPc=; b=XM8uSPw66gH9z+KznREpZPYCUZkx49emv70z5A9qmH5aW5H8gGJCL4B3hEJR3ae12l pOW9cooiqpavHmg6Q6J1Rlz/ONjLcaaxqG6C4iGZkZehuPcyn3r1q1EubhHK6ISSrH/S lSjcfaPfmCYRxcXRM9T8X+T2CQQO/30rsWw+n32kvGgSdNEB2l51ZV8J1lnOkSSw7z6t WBtWS1guxMwGGatoRywO7+B5G1Yp5g4mSJZKU7b4cfj31YdILbLKjMkKgZvsGoUrQINF y6aUk08CeLuKDiGuVUAd2JwYO3j09lpNXpH9dL9OSTDrUwYfIupcQ923KB/6HG2U0QNr K8Dw==
X-Gm-Message-State: AA+aEWbWyjjXkpOjwGZ8dm2503mNMC0i5UsYM5zXop3dF1jptWkOHJAM UXPCqF1TAfY7zurAMYEfEAu+sdYo
X-Google-Smtp-Source: AFSGD/Uy3TNO8lPbfj9SfEoOa1Uo+XaWaoNQXzYnkm11A2+bnVWFBxDhOzKeHPsyMtoruYKg7ybX0A==
X-Received: by 2002:a5d:5111:: with SMTP id s17mr10831290wrt.43.1543764343242; Sun, 02 Dec 2018 07:25:43 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id g201sm3687877wme.43.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Dec 2018 07:25:42 -0800 (PST)
References: <>
From: Sergio Garcia Murillo <>
Message-ID: <>
Date: Sun, 2 Dec 2018 16:29:23 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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: Sun, 02 Dec 2018 15:25:47 -0000

The value for the RepairedRtpStreamId is the same as the RtpStreamId 
which is negotiated in the a=rid value, so there is no further need for 
an a=rrid negotiation.

However, I have the doubt about the usage of the RepairedRtpStreamId as 
I have heard some opinions that the rtx could use also the RtpStreamId 
header and demultiplex media and rtx ssrcs via payload type. This would 
make sense as the rtx rfc states that the rtx packet should contain the 
same extensions as the original packet, so the RtpStreamId is copied by 
default by firefox in the rtx packet.

So I would like to get a clarification about what is the preferred way 
of implementing.

Also, when rid is not used I assume that the mid header extension should 
also be included in the rtx packet to be able to avoid ssrc negotiation. 
Should also mid have to be included when using simulcast (my assumption 
is that it is needed in order to differentiate between same rids in 
different mids).

Best regards

On 01/12/2018 13:04, Iñaki Baz Castillo wrote:
> Hi,
> We are almost in 2019 and, personally, I don't know yet which the
> proper/standard way for simulcast + RTX is.
> Clearly, RID must be used to send simulcast so, instead of signaling
> a=ssrc lines in the offer, the offerer signals a=rid values for all
> the simulcast streams. The remote learns the associated SSRC upon
> receipt of the first RTP packet by matching its RTP RID extension
> value. This is clearly specified in
> and Firefox does
> properly implement it.
> Now, the issue is when adding RTX to simulcast streams. Theoretically
> (if I'm not wrong) the sender should signal both the a=rid of media
> streams and the a=rrid of their associated RTX streams, and then send
> RTP RID in media RTP packets and RTP RepairedRtpStreamId in RTX RTP
> packets.
> NOTE: Not sure about a=rrid, I can't find it in any draft. So:
> Q1: Is there any spec defining the SDP syntax to indicate
> RepairedRtpStreamId values in the SDP?
> Q2: Is THIS (RID + RepairedRtpStreamId) the proper way to go for
> simulcast + RTX?
> Also, when it comes to receive media with RTX it's clear that WebRTC
> does not define how to receive simulcast streams for WebRTC clients
> (browsers), so browsers must receive a single stream plus an optional
> RTX stream.
> In this case, as far as a=mid plus RTP MID extension is used (or
> a=ssrc) signaled, there is zero need for RID. However, how is RTX
> supposed to be signaled in this case? Chrome expects ""a=ssrc-group:
> FID MEDIA_SSRC RTX_SSRC" in the remote SDP to be able to receive an
> additional RTX stream.
> Q3: Is this the way to go for receiving a single stream with RTX?