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

From: Bo Burman <[email-masked]>
Date: Thu, 6 Jul 2017 11:49:26 +0000

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:[email-masked]]
> Sent: den 13 mars 2017 14:43
> To: Bo Burman <[email-masked]>
> Cc: mmusic ([email-masked]) <[email-masked]>; Taylor Brandstetter ([email-masked])
> <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast
> 
> 2017-03-13 14:41 GMT+01:00 Bo Burman <[email-masked]>:
> > [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
> <[email-masked]>

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 Jul 2017 12:53:28 +0200

Thanks! These changes look good to me, and I've added them to a -11 
version of the document, and uploaded it to the i-d repository:

https://www.ietf.org/id/draft-ietf-mmusic-rid-11.txt

/a

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Jul 2017 09:21:14 -0700

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 <[email-masked]> wrote:

> 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)
>
> > 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
> > <[email-masked]>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Jul 2017 11:29:54 -0500

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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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)
>
>     > From: Iñaki Baz Castillo [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     > To: Bo Burman <[email-masked]
>     <mailto:[email-masked]>>
>     > Cc: mmusic ([email-masked] <mailto:[email-masked]>)
>     <[email-masked] <mailto:[email-masked]>>; Taylor Brandstetter
>     ([email-masked] <mailto:[email-masked]>)
>     > <[email-masked] <mailto:[email-masked]>>;
>     [email-masked]
>     <mailto:[email-masked]>;
>     [email-masked]
>     <mailto:[email-masked]>
>     > 2017-03-13 14:41 GMT+01:00 Bo Burman <[email-masked]
>     <mailto:[email-masked]>>:
>     > > [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
>     > <[email-masked] <mailto:[email-masked]>>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Jul 2017 09:34:54 -0700

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 <[email-masked]> wrote:

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

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 26 Jul 2017 16:48:09 +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.

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Jul 2017 12:01:28 -0500

On 7/26/17 11:34, Bernard Aboba 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.

Not all SDP attributes are exposed or controllable through the WebRTC 
API, mostly because there's an SDP world outside WebRTC. For example, 
CLUE adds new group types to SDP, but we don't fret about surfacing them 
in web browsers. I think we can safely say that your typical WebRTC 
implementation will neither produce nor consume these; they'll just be 
safely ignored.

Well, right up until the moment that you find a use case that requires 
them, at least.

/a