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

Sergio Garcia Murillo <> Tue, 04 December 2018 09:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84D0F130E67 for <>; Tue, 4 Dec 2018 01:26:43 -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 OMklC5bkGsAb for <>; Tue, 4 Dec 2018 01:26:42 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A7790130E66 for <>; Tue, 4 Dec 2018 01:26:41 -0800 (PST)
Received: by with SMTP id u3so15089870wrs.3 for <>; Tue, 04 Dec 2018 01:26:41 -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=fgay/puvXqH9L8IYE95eL/xQ63k0v5NN6RwwvIIrRBw=; b=pJJGyaOBf4YaPyymI9EvjF5noZ4IeG1bnW8HvD+v0/irqKlt+qajx8l5YYqZS5O8Kh H+3gp4XRFp0qPoUHiJ5Q2h8JSQpXnLesmrFfRAAOgjpzBiiGx/EwH7pSXw3kocVLIq8P VwxcJSAoMZD5RBgUl1tXXgNtj7O3KB4zEWf4eZ0fJslKTIW0vNQX5icy8v1ExIoX+RwZ tibwZV2xVA4sLfQYE83SkTY8+2g3601cuRJmGDljhPhiwyClJzWea7kBrF3K6k/wrV83 lRfUE1VE1c0Ga5zdjkaz+pl0uXnSZRYYL+y0N5cIgq9nw0HOIU6nZXj8dzjTgFaBZ518 sUVw==
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=fgay/puvXqH9L8IYE95eL/xQ63k0v5NN6RwwvIIrRBw=; b=NaY7MdLpSQzvQO6yR0OAT0Zo8Xr0AXznCcTYKBNYiMovshhXCO9/PSxcmfvPKr1kUZ ZlIZ2bG1RXsQu3zqR3+H59qDqThZu7cAeXLxyMVv9zOKK7ACbfTaEei9ZD3hQDCWLHOd 2HfPJQyMy0eRg8pNBbYVamInxb3C7ELXJ8IyjE2NyaTfBB9thKQR06DRWmSnfsZQVkCU kcFkCW/v9q4huFN9ZCOawY5hiP7qpK+WPBtm6Z5/bsIxiaXL0ra2y4in2HR5rIQkkTuM dzq1I19gxsxt+Wmrmo+GAmuCrxqmnl6AJQYBeUZAQARPounzol8I/g1CDLEav5P52NyZ sn4A==
X-Gm-Message-State: AA+aEWaUf+/RDTVosYfxpdP2QWT1c7Y+kJc9wUzLAQWAru2tcuvzbLLS IbQCMLr1wgYkQ8HjZHbO1l1Yw0er
X-Google-Smtp-Source: AFSGD/WjaFW0YvkshtvucDGsjIfNT2iwEXBTnLdtpHHAaoHgijpnI+xj9AbT5kp9NTBTijru2OZb4g==
X-Received: by 2002:a5d:6907:: with SMTP id t7mr16900198wru.226.1543915599739; Tue, 04 Dec 2018 01:26:39 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id 80sm11568516wmv.6.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 01:26:38 -0800 (PST)
References: <> <> <> <>
From: Sergio Garcia Murillo <>
Message-ID: <>
Date: Tue, 4 Dec 2018 10:30:21 +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: Tue, 04 Dec 2018 09:26:43 -0000

On 04/12/2018 10:04, Magnus Westerlund wrote:
> On 2018-12-03 22:31, Iñaki Baz Castillo wrote:
>> On Mon, 3 Dec 2018 at 11:02, Magnus Westerlund
>> <> wrote:
>>> 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?
> That implications I actually hadn't thought about. But you are right
> there is an issue here.
> So RFC 4588 says this:
>     If the original RTP header carried an RTP header extension, the
>     retransmission packet SHOULD carry the same header extension.  This
>     header extension MUST be placed right after the fixed RTP header, as
>     specified in RTP [3].  In this case, the retransmission payload
>     header MUST be placed after the header extension.
> So following that an implementation SHOULD include the RtpStreamID
> header extension and the RFC is silent about adding additional ones. So
> the reconstructed original packet needs to have the RtpStreamId header
> extensio. However, some text on the use of RepairedRtpStreamId appears
> required. Like that it should be added at certain cases, like first
> sendings of an repair RTP stream (until know it be delivered) as well as
> when endpoints join the session. The receiver also needs to know to
> strip this particular header and not include it in those that are
> attached to the reconstructed packet.

Given that RFC 4588 already covers the inclusion of the original 
RTPStreamID header into the RTX packet and that FlexFEC will not use 
RapairedStreamId mechanism (as a single flex fec stream will be used for 
all protected media), I see no use at all for the RepairedStreamId 
header extension and related mechanisms at all.

Best regards