Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast

Bernard Aboba <bernard.aboba@gmail.com> Wed, 26 July 2017 16:21 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CA7131CFD; Wed, 26 Jul 2017 09:21:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: 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 PnM_wWEdxlat; Wed, 26 Jul 2017 09:21:36 -0700 (PDT)
Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 C79211320A0; Wed, 26 Jul 2017 09:21:35 -0700 (PDT)
Received: by mail-ua0-x22e.google.com with SMTP id d29so111265836uai.2; Wed, 26 Jul 2017 09:21:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+p5hreK3PH0SUdqwKQYQywQcNEc+cEq3pdmKklDiCXw=; b=dYul1Z//S15qgjpSxvpeL2gTFwNrUfvcWPhUEpV/WrKmpipKBMp1A7jW9fzVKqmLlx DRfchg+i40gNM61jv0uuDN/ewiJfFDTTET4G9wWncJ6SfNDCTBv2lb2+4vn08PxnWl2I W+oZS14PnZ4kWafCG9AqpmubwMfYNAfRjVMvv6kDdrdp2CyHpWx4+ZG5+C2B5AlAdnfl aRc7fXTvTCx+WhNV2oNfgZPz8DfoJs0njODANls8rq64ANPUZtBScgNGETWWloTei1+d IlAY41gi8S+MuhXYf3pNzrmOjD3PieH8Ddg8+9+kypxUshOioBVAAhgGGSIciUvBFBmT pCqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+p5hreK3PH0SUdqwKQYQywQcNEc+cEq3pdmKklDiCXw=; b=lQ3I1tuXDyKDOKN5qtsDCj5IVt95UVk9ke734e20e1W/zxhlrwdlKFhu0BNZjRyg0U 4jFRkHTw85EYxymkgMXXERzJUeL+bzzeQnRlT3lguqq+WBBOZ5HANKU/PMlma3uhNcxv Pr1YsIXcBgx4Dzss/HpJu/WoQRDKt0sDgQR3jxsFb/M8DNK17kvVnyDMdvMqqi/wFvIM NqZTF5mh4trmtkdcZtUG/prVzOPJ4tg2czjfEOpON0fuWrEd6//icANeIiU6jcvjoZnl V9Qm1ZW2kLLwXw1/gCAh3v3nqAWfnRXxmw7h363eVMYaYZ+ukl5pnFTW+FTAMbuBro40 ILbg==
X-Gm-Message-State: AIVw111l2yKKl11y9t/7gg3Ki8+v+VaCmzIBPeGizpkH2bnu/L2rLwJS 6yKGN/J7uo+ySE1uCXZEIq9/KPlJSQ==
X-Received: by 10.176.3.162 with SMTP id 31mr971832uau.149.1501086094704; Wed, 26 Jul 2017 09:21:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.111 with HTTP; Wed, 26 Jul 2017 09:21:14 -0700 (PDT)
In-Reply-To: <AM5PR0701MB2577ACCA590E0F4FC4561F6C8DD50@AM5PR0701MB2577.eurprd07.prod.outlook.com>
References: <CALiegfkM+Gh5tnu_LU+Lo4FM_OVy+TixyBt2zBtoREucHHAsCg@mail.gmail.com> <3A98F0E8-772E-40E3-A872-5414AC8FDF35@iii.ca> <CALiegfm0+GkfTvUk0Kfj2SLf+zcw-k6b-xnqXd4omnVy7mPTEg@mail.gmail.com> <12EA18B8-39F0-491F-92B6-D41F3D640209@iii.ca> <CALiegfndNRoBH-1TYvLhC2TZsWApaLLZ0WBjh3HzL4pYJtCmGQ@mail.gmail.com> <CAK35n0ZuGu+FxYsdDGkX4aomeTC68XvBd0MniKS7NzdAeuEACQ@mail.gmail.com> <AM5PR0701MB2577FD1D3E43697C4672F80C8D250@AM5PR0701MB2577.eurprd07.prod.outlook.com> <CALiegfnUqrd_5z2gsgjsOqHxUXyciDv1uN1z+EJw_A8rNXmFMQ@mail.gmail.com> <AM5PR0701MB2577F4261814169B0AF408488D250@AM5PR0701MB2577.eurprd07.prod.outlook.com> <CALiegfmREKCotLeNkp9mj=zB8V-fir-Z=QQBUvVUUK9jsjELRQ@mail.gmail.com> <AM5PR0701MB257767A071B4BAE79A9DFE878D250@AM5PR0701MB2577.eurprd07.prod.outlook.com> <CALiegfm6rgrtpN55N3LYbt1ZMvKuxNSahEs4JikNc_eSHPfR0Q@mail.gmail.com> <AM5PR0701MB2577ACCA590E0F4FC4561F6C8DD50@AM5PR0701MB2577.eurprd07.prod.outlook.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Wed, 26 Jul 2017 09:21:14 -0700
Message-ID: <CAOW+2du5HCxfmnMg_PNQJ6jPeZ=TuLqJNMOtG_FE-j+kykGdvA@mail.gmail.com>
To: Bo Burman <bo.burman@ericsson.com>
Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>, "Adam Roach (adam@nostrum.com)" <adam@nostrum.com>, "draft-ietf-mmusic-rid@ietf.org" <draft-ietf-mmusic-rid@ietf.org>, "mmusic (mmusic@ietf.org)" <mmusic@ietf.org>, "draft-ietf-mmusic-sdp-simulcast@ietf.org" <draft-ietf-mmusic-sdp-simulcast@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c05ae0273c57305553ad70b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/qcKq3_99TCKDxUeLAIFYepyrJEs>
Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jul 2017 16:21:39 -0000

Why would a redundancy RTP stream have an "a=rid" line of its own?  I am
struggling to find a use case for this.

On Thu, Jul 6, 2017 at 4:49 AM, Bo Burman <bo.burman@ericsson.com> wrote:

> To follow up on this, I suggest making the following addition to
> draft-ietf-mmusic-rid:
>
> ---- AFTER this text in section 4 ----
>
>    An "a=rid" SDP media attribute specifies restrictions defining a
>    unique RTP payload configuration identified via the "rid-id" field.
>    This value binds the restriction to the RTP Stream identified by its
>    RTP Stream Identifier SDES item [I-D.ietf-avtext-rid].  To be clear,
>    implementations that use the "a=rid" parameter in SDP MUST support
>    the RtpStreamId SDES item described in [I-D.ietf-avtext-rid].  Such
>    implementations MUST send it for all streams in an SDP media
>    description ("m=") that have "a=rid" lines remaining after applying
>    the rules in Section 6 and its subsections.
>
> ---- ... add this proposed, new text ----
>
>    Implementations that use the "a=rid" parameter in SDP and that
>    make use of redundancy RTP streams [RFC7656], e.g. RTP RTX
>    [RFC4588] or FEC [RFC5109][I-D.ietf-payload-flexible-fec-scheme],
>    for any of the source RTP streams that have "a=rid" lines remaining
>    after applying the rules in Section 6 and its subsections, MUST
>    support and use RepairedRtpStreamId SDES item described in
>    [I-D.ietf-avtext-rid] for those redundancy RTP streams. This provides
>    the binding between the source RTP stream and the corresponding
>    redundancy RTP stream, by setting RepairedRtpStreamId value for
>    the redundancy RTP stream to the RtpStreamId value of the source
>    RTP stream. The redundancy RTP stream MAY (but need not) have an
>    "a=rid" line of its own, in which case the RtpStreamId SDES item value
>    will be different from the corresponding source RTP stream.
>
> ---- End changes ----
>
> The -simulcast draft would be entirely agnostic to this clarification of
> "a=rid" and RepairedRtpStreamId usage and thereby transparently allow using
> redundancy RTP streams with simulcast.
>
> /Bo
> (as individual)
>
> > -----Original Message-----
> > From: Iñaki Baz Castillo [mailto:ibc@aliax.net]
> > Sent: den 13 mars 2017 14:43
> > To: Bo Burman <bo.burman@ericsson.com>
> > Cc: mmusic (mmusic@ietf.org) <mmusic@ietf.org>rg>; Taylor Brandstetter (
> deadbeef@google.com)
> > <deadbeef@google.com>om>; draft-ietf-mmusic-rid@ietf.org;
> draft-ietf-mmusic-sdp-simulcast@ietf.org
> > Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast
> >
> > 2017-03-13 14:41 GMT+01:00 Bo Burman <bo.burman@ericsson.com>om>:
> > > [BoB] Usage of RepairedRtpStreamId and RtpStreamId are already defined
> on RTP level by -avtext-rid. If we have
> > preferences on how to best use them with redundancy RTP streams in
> general, I suggest we add text to -mmusic-rid
> > about it. This would be regardless if we go for option A or B, but
> decided once and for all, thus applicable to RFC 4588 rtx
> > and FLEX-FEC alike.
> >
> > Agreed.
> >
> >
> > --
> > Iñaki Baz Castillo
> > <ibc@aliax.net>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>