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

Peter Thatcher <pthatcher@google.com> Wed, 26 July 2017 16:48 UTC

Return-Path: <pthatcher@google.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 7A70C1320BA for <mmusic@ietfa.amsl.com>; Wed, 26 Jul 2017 09:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 iscgnVvQ7pYy for <mmusic@ietfa.amsl.com>; Wed, 26 Jul 2017 09:48:21 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 BCA56131D28 for <mmusic@ietf.org>; Wed, 26 Jul 2017 09:48:21 -0700 (PDT)
Received: by mail-oi0-x231.google.com with SMTP id x3so81006513oia.1 for <mmusic@ietf.org>; Wed, 26 Jul 2017 09:48:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=COxc6C3OvAtAX7LUeUNhnq/cCykIFdL15B3KqL58g4c=; b=HLygUPVWiyxSZlyivw88TAnPmdVpL/EbpeoHjs4PyTSeBfQxGDv3Jn1XNSHqs6Rifk KOQNvfVU2mBZP2h3JLXldN+5974Lfj44SusH3GkGsa3pyXtEbLcg9OoZl60WOV06KJnz 3ePg3OAbyYc2clpSND506Kr6Vr7GEd/Y/uZtPqCjyJZW/IAm1EH2pjyim9M7Y9IJbS4W A0tnNUbe7IBWGg0DrNOa0IlyzgbQHeI125j2llEv7f0KBItihefhMx908WZv4MryPnBM LSIPiL0wcOKB73LIm2FBNN6OWjCuD+jiRsf/haj7RhpQI338EHRfqxNupoPcVtAmPXuh miBg==
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; bh=COxc6C3OvAtAX7LUeUNhnq/cCykIFdL15B3KqL58g4c=; b=dI8YbPj0KI0aTSyJgPthfY+EQA+mRdf3bWKBFb3c6cOc97FIR4uqVgI93LNBZI/8hl vDhJJbOGptXSj0MDikrQNRoOHZoKDE8eRK+kZn5EcJOshkuFkYCR5NG4elGRhTZwDrSJ luXPYpstw+yjdkhwVn8WrVV2RzjFyfHRQhx+y8unCsygPPUseYszt3+N0aXYaurDM2lx 3J6NaTXjtoEHOKT7MUbz+ycr9vTWUFKQi/qKLX/F7uJDz7Dvr7FclXVkgNZ61YWlUy9J Ajw6J0UKGJC8WL6T1C5gmcGGcC0QGxlPqpN7/3ipxvOIgEfEIr7iST/eelKAScMVNCNv JFZw==
X-Gm-Message-State: AIVw112TC3ykuTt8N2G4oFElWPVYhF3tIg3ZuoGxhmA0Cbb4YrY8Sp8Z OC+oYTOdHRXcBRSGz7xCk95WMkHY37dJ
X-Received: by 10.202.230.212 with SMTP id d203mr1620805oih.59.1501087700644; Wed, 26 Jul 2017 09:48:20 -0700 (PDT)
MIME-Version: 1.0
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> <CAOW+2dvFk35rXzo1ZgFxZeWWoLOG7+ML+vTNQvRVpjY2aSXDPQ@mail.gmail.com>
In-Reply-To: <CAOW+2dvFk35rXzo1ZgFxZeWWoLOG7+ML+vTNQvRVpjY2aSXDPQ@mail.gmail.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 26 Jul 2017 16:48:09 +0000
Message-ID: <CAJrXDUH+5p6v2OCHHyOQj6c_Pn1GDGCS-TD4C2T6TwhvBoG4hA@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>, 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="001a1141aede2ccf4805553b37ea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/EhTdKbMihv4smg5yz08p0hPDxAE>
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:48:26 -0000

RSIDs on source streams and RRIDs on repair streams make sense.

While we included the ability to have RSIDs on repair streams into the
header extensions, I don't see any use for them in the SDP and calling them
"a=rid" is just confusing.  If anything, they should be called something
else, like "a=rsid".  But again, I don't see any point.

On Wed, Jul 26, 2017 at 9:35 AM Bernard Aboba <bernard.aboba@gmail.com>
wrote:

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