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

Bernard Aboba <bernard.aboba@gmail.com> Wed, 26 July 2017 16:35 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 D0A58131D10; Wed, 26 Jul 2017 09:35:18 -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 aWFcSqatpByc; Wed, 26 Jul 2017 09:35:16 -0700 (PDT)
Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 3232F1320AE; Wed, 26 Jul 2017 09:35:16 -0700 (PDT)
Received: by mail-ua0-x236.google.com with SMTP id k43so84371186uaf.3; Wed, 26 Jul 2017 09:35:16 -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=IK5ABWMYmu4wCNQ2Rcr5cA4EUtDmjlCWHe1bnMzgI9U=; b=ZNQ1HwWABJ0UGZtz9zwEgIYWZ/ZnR9A6aTcciIXxNLHSopEPgOhHOH0AWE9xkfFVVu hSDU2gzBwfDHvqUM6hnMHqZwZpXLzUr6C3myavO0pOaPbuTJN9pswS71KZswhv+69ObE lvvxDaou/FVyehT0+kmouOdDr/aLnxANYC4SYKTxuW074jzdt4Wo2tdqvqDfFto6MaGz ymHb9C19bfoDGG3hCFg3svb0A30NqV0fI0uPOZ7nRlHw92mCdOp5Q1H0vtwEVaJpNZ2N 8CmbTyuWLNv0+LbqiCNYAobjui114sAYtcNzvADH+3PvSHE5Gcsk66BidCi8wYbxYdAL BB3Q==
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=IK5ABWMYmu4wCNQ2Rcr5cA4EUtDmjlCWHe1bnMzgI9U=; b=tXbPGe6C/VrKw5+UKRWJVRXZqout6x5TdMltb3Ck0piuKInP1sTBkX8SLVuEX4LTey /da4Klo/v0fPPOZPFBxl5nLxsfjOlEqioKPuoFCNP2fomBt8A0/41xdXibUnp41gM21A hpwGPWyskwvmavihYh4+I0ebW497ARk4Yw0bkNkyMGOmot6EEN0tc/HcjuAz0ccqlB92 TYdO+vgfewt+rQnxRS6ppu9h5sSBKO6YCmOQfNNzzme13cNpJpTbvAxnnnA6Z+WKtd6o MaXM5yObKmz1tJmaBWaQZZhb+YGKFuWq0f25oC6D+G5/nhOYdj59e+sYpwh+YZOABKcH vPEg==
X-Gm-Message-State: AIVw110AAvoOW8ePDVjMpylNPPqDb2QVfUxPqeLXh3cdPl62qK/EHdPj uDZBZyh4BH3fDtUCta0jqbuQf1AEvkCsqZI=
X-Received: by 10.159.52.79 with SMTP id s15mr1055958uab.157.1501086915069; Wed, 26 Jul 2017 09:35:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.111 with HTTP; Wed, 26 Jul 2017 09:34:54 -0700 (PDT)
In-Reply-To: <d9f36f52-52c2-b8f9-a6f6-e6c47519d7c6@nostrum.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> <CAOW+2du5HCxfmnMg_PNQJ6jPeZ=TuLqJNMOtG_FE-j+kykGdvA@mail.gmail.com> <d9f36f52-52c2-b8f9-a6f6-e6c47519d7c6@nostrum.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Wed, 26 Jul 2017 09:34:54 -0700
Message-ID: <CAOW+2dvFk35rXzo1ZgFxZeWWoLOG7+ML+vTNQvRVpjY2aSXDPQ@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: Bo Burman <bo.burman@ericsson.com>, =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>, "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="f403043ed1d4598cfd05553b084d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/Nd7xZsMRAlNrPqdOVMg2Mp2SXOk>
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:35:19 -0000

Currently the WebRTC API only exposes RIDs used for media streams, not for
redundancy streams and JSEP currently doesn't indicate whether it is
permitted for redundancy streams to have their own RIDs.

So adding this text creates a potential ambiguity.

On Wed, Jul 26, 2017 at 9:29 AM, Adam Roach <adam@nostrum.com> wrote:

> Future-proofness.
>
> Recall that the original design here was to give redundancy streams the
> same ID as the stream they're repairing, but there were objections that
> doing so would preclude using the mechanism to talk about redundancy
> streams in SDP if such a need ever arose in the future. So, we allow for
> signaling of these IDs in SDP, but (since as you correctly point out there
> are no concrete use cases at the moment) do not require it.
>
> You seem to think this is a problem. Can you describe a scenario in which
> it causes interop issues or additional implementation complexity?
>
> /a
>
>
> On 7/26/17 11:21, Bernard Aboba wrote:
>
> 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
>>
>
>
>