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

Iñaki Baz Castillo <ibc@aliax.net> Tue, 04 December 2018 11:34 UTC

Return-Path: <ibc@aliax.net>
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 9E70A126C7E for <rtcweb@ietfa.amsl.com>; Tue, 4 Dec 2018 03:34:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level:
X-Spam-Status: No, score=-3.359 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.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 7AFrnlQ-GwAd for <rtcweb@ietfa.amsl.com>; Tue, 4 Dec 2018 03:34:28 -0800 (PST)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 023B812875B for <rtcweb@ietf.org>; Tue, 4 Dec 2018 03:34:27 -0800 (PST)
Received: by mail-vs1-xe2f.google.com with SMTP id y27so9594600vsi.1 for <rtcweb@ietf.org>; Tue, 04 Dec 2018 03:34:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=M06p9UDL9v/TtzDhzWrkdDkAWjlywOUiMJKl7zGbYlU=; b=OP0EFMD82/8TeLC42ZvoJATpg5WQDzGvHen2OKaRibN9+bC9RRp3fZPrVus+ltirxF Tf46XiogL2HOALN+vyHRJxxISQmo7ZGqcthmyxJXgIOKnKRSn+Y5TiSbejMvJzlihsU5 iaubJtWmKoHW0Xuhhh1vh9yGpt8HQdm7JuOHoC45fQ2RYo/qd5C2V70jvdVMQAWq7ghq MyXIPp0L2yKh1ezd3j+0gOQxw07CjLXuKtL6X9BEud7LIYaskcUX2rQtbG2aunGRYxjJ ibCswA+WJAaQjXZIxnGcxyStQwZJ9k2UHCYwLYw6R3sgsfANm2q8Fk8ndB6NLRB+iw5y YJwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=M06p9UDL9v/TtzDhzWrkdDkAWjlywOUiMJKl7zGbYlU=; b=aCIXYPy11/TJgeaAltOl74NB3A9byJOwDRGc5HGhWv5K9Uf0iQ+yOB3JRpN0YDGzHi EQyJoD8u4ZGGTwn6BphoCTFj6jXxeLBqXf//4tAovGOgNyC4YqpOzMuAla5jPng/v8GN 0oDfnYcjpObOPt3xJ8DIJLVwE0+C+kth8jnhuhvuWOnyMnIlszLqT5/cY/G5agBNX+uO aP0LRkgtBOCnapA0OOM0YZz6FaqAzx4TA44GftBgHPK8plB39XTxc8jpPqUDdz88h4ew 90pUfjpKLqQ2gfOvATsodwHyBUknyA3VIXTzTdFwHpCibpY6yR6QtCQSKfqNv+7nWFd3 +LEQ==
X-Gm-Message-State: AA+aEWZAO7gCC1VoEgqpr5liDBm2cEO8t5oAz8Pq+CMlpHxIUTJalJ6u K1GOR8aP+UgL025YGx+rqN9aDqxGv+cHPmXOCk9yfA==
X-Google-Smtp-Source: AFSGD/XYKEFNvky2jctQ+f3Nuz7QnBbuZEeGaNOK0C7Nwq+FQ5Ctd8vubZk0J8kHesn/tNhwBU9cGIx7NUMgzYw7z6o=
X-Received: by 2002:a67:3edc:: with SMTP id a89mr8591894vsi.136.1543923266816; Tue, 04 Dec 2018 03:34:26 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <1af3105f-5e66-548d-cb31-6aaf9f2cd0b4@gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Tue, 4 Dec 2018 12:34:15 +0100
Message-ID: <CALiegfkh-4gaJu0npDf3FYmzbDC9+ywTP1H+J6_Q-EpicXBj-A@mail.gmail.com>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, rtcweb@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/9iLllkToaROJgwCVwJNZrqi26-g>
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:34:31 -0000

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.

> 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).

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.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>