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

Sergio Garcia Murillo <> Tue, 04 December 2018 11:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F9FC130EC2 for <>; Tue, 4 Dec 2018 03:22: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, HTML_MESSAGE=0.001, 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 BtO2NKRee6Rv for <>; Tue, 4 Dec 2018 03:22:45 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A70C3130EC1 for <>; Tue, 4 Dec 2018 03:22:44 -0800 (PST)
Received: by with SMTP id m22so8940084wml.3 for <>; Tue, 04 Dec 2018 03:22:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=P5PxbEZMY2dAW6B73RsuStFgPD/Uruth81xCiyHsSsA=; b=iqMziFJHfGtcGDqL3P7Tjk7kq5PR4G/jnUx2/SiyoXLgX7cUFWSXGQe+nw1UaAo6+0 g2NT2O+8DF4wAJnyec/LFSwll1xIKJARCnmTTpXJM/0rZmY+Sn7H3gHdks0WYbCvZnb2 JojRykHxSCNfs1cO6HxYdflTgs1svckaUauKL6Bf6j6CG3D/ec81pr1QawcSPcVyo4MI OoBef4NjQL9fgrjtjr7W76Mg4wvz6zZHr8k+mRffTVdOtdmi19Jth9ZPmNL9q2MTqaa9 +GYdtMD4ybrn6rqX6F4Gmu6UAIzWc0dNEK88xDs4ZZAXsxxBMQFgDwJ1G1tHQF4fZs22 0zng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=P5PxbEZMY2dAW6B73RsuStFgPD/Uruth81xCiyHsSsA=; b=T5kimxrJ5s9CRnBsJVjcT6R7iNGspeKF55/MTW4yJUsO/Sh2DFonr/8LaSFCn8J9dT 6YJlWxDh1RIlvLPGM0w8yQdMAr4w/IPG01n3vnZ2qVhf7HRMPTXgACPtv0/cAq6lVflc u8usOhLGrgOR/xJXd0rZJx3tDtJ+3QItpEC7DZNeCqk+WuBde6RA/liOjjmoLbaQB/IJ xBzp4ZCkOtvjuWlMRUaVNOtaqo3UeLT5xfjKUlZmHCYVFsNrFdE1Q4vxtLF7PljVpFfS jCnqNxGe3GDcS8nkmE9PajCs4bBQJgCf2xplRbi/Mu9zIa5eaobbkU5lllLKjKi6SOq8 29Hw==
X-Gm-Message-State: AA+aEWaf6PBlPij/Fp+GSavVWXB0gQ2AzPCSZEgrLu2pxJqU2Ew0Zt6S TJqb3UQ5u3xNeuBP5kr6J5X7+ACQ
X-Google-Smtp-Source: AFSGD/XYX271KNro1jFjtTM1SZE9tpv5r7PM3vrnAbS/fAsHFDNELMHNLNI2AwPdCfRQ5D6ftXTZyw==
X-Received: by 2002:a1c:44d6:: with SMTP id r205mr12346246wma.50.1543922562718; Tue, 04 Dec 2018 03:22:42 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id v19sm23534970wrd.46.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 03:22:41 -0800 (PST)
To: Magnus Westerlund <>, =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= <>
Cc: "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Sergio Garcia Murillo <>
Message-ID: <>
Date: Tue, 4 Dec 2018 12:26: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: multipart/alternative; boundary="------------D8735F7748E7564157EB0D58"
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 11:22:48 -0000

On 04/12/2018 11:51, Magnus Westerlund wrote:
> On 2018-12-04 11:01, Sergio Garcia Murillo 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.
>> Same could be said about changing the ssrc to avoid collisions and we
>> would have avoided our selves to introduced all this new ids.
> I think you are significantly misrepresenting the reasons why RID's are
> needed. The fact that we have multiple models for how RTP middleboxes
> works is a significant contributing factor. The next is in RTP ancestry
> as a non-centralized multi-party protocol, i.e. intended to work over
> any source multicast. And as simulcast do implies a selection by the
> middlebox that aspect do needs to be handled. A clean-slate approach
> could possibly select another set of constraints and maybe be somewhat
> simpler but not a lot.
> I do note that also the MIDs and RIDs only have per signalling context
> and may require translation between the various legs of the conference
> in a multi-party one.

I disagree with several of those statements, but my intention was not to 
start a new discussion about the need of mids/rids, but the usage in RTX 
which I have not yet got a good answer.

Trying to get back to the discussion:

  * What headers should contain a RTX packet from a track added via
    addTrack or addTransceiver without encodings
  * What headers should contain an RTX packet from a track added via
    addTransceiver with several encoding+rids

Best regards