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

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Tue, 04 December 2018 11:45 UTC

Return-Path: <sergio.garcia.murillo@gmail.com>
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 90299128CF3 for <rtcweb@ietfa.amsl.com>; Tue, 4 Dec 2018 03:45:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 E8a9M0IsYMin for <rtcweb@ietfa.amsl.com>; Tue, 4 Dec 2018 03:45:17 -0800 (PST)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 99225126CB6 for <rtcweb@ietf.org>; Tue, 4 Dec 2018 03:45:17 -0800 (PST)
Received: by mail-wr1-x431.google.com with SMTP id j2so15618904wrw.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=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=ocF0AC3jlEbQDJ6nsbsWQAytzUvM5FGT33hEu2ZFZdE=; b=B1bDWz6VGcLEVw1K0kTmze2ZD3yR3yq2qy3NLiEvHb5mspxxhmKYJxA5taZ+UjgjyU mPdPFyIUf524n8GkR0oIQ2kjRBeOeJa9QO5vYETjvjJKo/nZLbdWifiAJBIfGnUkosqO vTfk2o69hRiUjXPk5Eypg3rtE0jhywX7jW7GdwebxBSmv/+t+CyHnJw1RjS8GeWyPMz0 WPkKeZnfJsOhczo2OLpKHPjRZwgziPFywYmtb1iYBPkK5DTR2Cn75lTq2aSqPzqYrrQb qgsZRJ+Oo8HvFXvG9css3arrYMayUptf6T9dp+BsrASOT96H35XPcMcgHcMZgm9Hh7W2 u2GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ocF0AC3jlEbQDJ6nsbsWQAytzUvM5FGT33hEu2ZFZdE=; b=h5IbdQV5slgOIU8HD0cBwxC2E9NffMQyGJEzGb0Av9W7eCiF3mYvvry6La3h+PXADt gJafPg4RGA5NT+GOzDKYBgLcOmEQOo2ihHd3tMMZrv7gc4Dlkp77P1VByTrEj7BKLVbS OyVpPXbEm+3ibteQHYJMEbzdV+QkfovEjx7g6iShydedpFtOQosDd62WN6juCM1z8KBA s/eEqrZMZZAukdMa/AJxMO/ZVTtaSynB1qv+Y9ltV8O1SKSMKkKLH8OsMnI65OfAyPQ4 nwsMLn25wEIj3bKbB8gd4OQxaqFCzCcD1QEl15xX3oxt8FxtC05L+p67JMQ6OG36HCg4 Qd7Q==
X-Gm-Message-State: AA+aEWb2F7zfcJPwbMaWwoLIYBUVCx4M4RqTJeckvoTR/XTA2d8G00jV SlgGyslPaDl2USNvzdBZ1UYjQAYb
X-Google-Smtp-Source: AFSGD/Wo6l/0B0xbfTdAJWkXYq/mxs0JWLf7VP7QJ4NTcA+I825OfDp4Murf0Gc7bn5wKdzwaAun0g==
X-Received: by 2002:adf:ec50:: with SMTP id w16mr18176782wrn.171.1543923915740; Tue, 04 Dec 2018 03:45:15 -0800 (PST)
Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id v5sm21779086wrn.71.2018.12.04.03.45.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 03:45:14 -0800 (PST)
To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= <ibc@aliax.net>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, rtcweb@ietf.org
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> <CALiegfkh-4gaJu0npDf3FYmzbDC9+ywTP1H+J6_Q-EpicXBj-A@mail.gmail.com>
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Message-ID: <af051833-88f4-4858-7f15-edb4c533ba5f@gmail.com>
Date: Tue, 4 Dec 2018 12:48:57 +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: <CALiegfkh-4gaJu0npDf3FYmzbDC9+ywTP1H+J6_Q-EpicXBj-A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/FtqFhoG0WebVNFPrYFfY2MIH68k>
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:19 -0000

On 04/12/2018 12:34, Iñaki Baz Castillo wrote:
> On Tue, 4 Dec 2018 at 10:35, Sergio Garcia Murillo
> <sergio.garcia.murillo@gmail.com> wrote:
>> On 03/12/2018 22:26, Iñaki Baz Castillo wrote:
>>> On Mon, 3 Dec 2018 at 22:22, Sergio Garcia Murillo
>>> <sergio.garcia.murillo@gmail.com> wrote:
>>>> My point is that there is a single source in the transceiver/MID why
>>>> should we add default RID and waste 2 more bytes in each media and rtx
>>>> packet?
>>> Regardless what browsers do today, both MID and RID headers should be
>>> just included in the first packets. The receiver is supposed to update
>>> its ssrc table for faster matching.
>>>
>>> NOTE: The sender should also resend MID and RID if the SSRC changed
>>> because some RFCs state that SSRCs may conflict and things that
>>> absolutely never happen.
>>>
>> Kind of agree, but from a theoretical point of view remember that we
>> introduced MIDs/RIDs to cover rtp proxing/switching scenarios in which
>> ssrc conflicts may happen, so in order to cover those scenarios the
>> MIDs/RIDs values must be included in every packet.
> I don't think that rationale is correct. No need for MID/RID in
> *every* packet, but just in the first ones (despite what browsers do).
> Once magic SSRC conflict happens (AM I READY TALKING ABOUT SSRC
> CONFLICT??) the sender should just choose a new SSRC and add MID/RID
> in the next packets.

Yes, they could be sent in all packets until the first received RTCP RR 
for that ssrc (to ensure binding on the received side) and then only on 
first packet of an intra frame for video.


>> If we ignore that,
>> then could just go back to ssrc signaling and avoid mids/rids
>> completely, which I would be in favor of.
> Definitely signaling ssrcs instead of MID/RID is *much* easier for
> anyone who has implemented this stuff. I'm still waiting for any good
> reason to not signal ssrcs (NOTE: I do not believe in SSRC conflicts
> and will not believe in it no matter which "RTP middlebox stuff"
> rationale is given to me).


+1

btw, I use an alternative approach for signaling back rids/ssrc 
association for chrome sdp mangling in order to havea single processing 
algo on the SFU (note the ssrc attribute on the rid which is completely 
valid accoding to the rid ABNF ;)

a=ssrc-group:FID 3267388881 2718767991
a=ssrc:3267388881 cname:jwLMsXS4a6eBfofC
a=ssrc:3267388881 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:3267388881 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:3267388881 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:2718767991 cname:jwLMsXS4a6eBfofC
a=ssrc:2718767991 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:2718767991 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:2718767991 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc-group:FID 100 101
a=ssrc:100 cname:jwLMsXS4a6eBfofC
a=ssrc:100 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:100 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:100 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:101 cname:jwLMsXS4a6eBfofC
a=ssrc:101 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:101 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:101 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc-group:FID 102 103
a=ssrc:102 cname:jwLMsXS4a6eBfofC
a=ssrc:102 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:102 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:102 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:103 cname:jwLMsXS4a6eBfofC
a=ssrc:103 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:103 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:103 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc-group:SIM 3267388881 100 102
a=simulcast:send a;b;c
a=rid:a send ssrc=102
a=rid:b send ssrc=100
a=rid:c send ssrc=3267388881

> Said that, if we go that way (signal MID and RID instead of ssrcs)
> it's ok as far as we can also properly signal simulcast + RTX, which
> is not clear given the length of this thread.

Neither for non-simulcast scenarios


Best regards

Sergio