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

From: Bo Burman <[email-masked]>
Date: Mon, 13 Mar 2017 09:56:36 +0000

All,

This is forwarding a discussion that started in RTCWEB that mainly applies to -mmusic-rid and -mmusic-sdp-simulcast. I suggest we continue the detailed discussion here in MMUSIC.

As the forwarded mail says, it is still somewhat unclear what question that needs an answer, but it is clearly related to joint use of “a=rid”, “a=simulcast”, and use of retransmission (“rtx” format from RFC 4588). I think such usage may be slightly under-specified in one or both of the above drafts.

I think what Taylor suggests below is a very good start and may actually provide the solution we want (and should then document better).

I however note that:

·         RFC 4588 (section 4) says that RTP Header Extensions (such as RtpStreamId, used for “a=rid”) SHOULD be repeated by the retransmitted packet:
   “If the original RTP header carried an RTP header extension, the
   retransmission packet SHOULD carry the same header extension.  This
   header extension MUST be placed right after the fixed RTP header, as
   specified in RTP [3].  In this case, the retransmission payload
   header MUST be placed after the header extension.”

·         It is not self-evident that the retransmission redundancy RTP stream (RFC 7656) should be assigned the same RtpStreamId as the RTP stream it protects, especially since that would prevent assigning a separate RtpStreamId to the redundancy RTP stream itself (if that is ever needed)

·         -avtext-rid already provides a way to deal with this by defining RepairedRtpStreamId, but -mmusic-rid currently does not in any way detail its usage

I believe we need to decide on and document:

·         Whether to use RtpStreamId or RepairedRtpStreamId in the rtx redundancy RTP stream to indicate what RtpStreamId the original RTP stream has

·         If using the same RtpStreamId in the rtx redundancy RTP stream as in the original RTP stream (basically Taylor’s proposal):

o   That it is aligned with the RFC 4588 recommendation to copy original RTP HE (verbatim) into retransmitted packet

o   That “a=rid” specifies both original format and rtx format for the “pt=” parameter (as Taylor suggests below)

o   That this clearly indicates in SDP which “a=rid” uses retransmission (by pointing also to a rtx PT)

o   That if the rtx redundancy RTP stream itself needs an RtpStreamId, RepairedRtpStreamId is instead used to relate to the original RTP stream; I note that there’s a risk that an implementation that does not know of RepairedRtpStreamId will then not find the relation between original and rtx RTP stream

·         If always using RepairedRtpStreamId in the rtx redundancy RTP stream to relate to the original RTP stream:

o   That it is an (intentional) deviation from the RFC 4588 recommendation to repeat RTP Header Extension verbatim, but instead uses a format that “points” to what the original HE was

o   That “a=rid” specifies only the original format in “pt=” (because the rtx stream does not use that RtpStreamId, but uses RepairedRtpStreamId instead)

o   That this does not indicate in SDP which “a=rid” uses retransmission, but that the relation can only be found in the rtx redundancy RTP stream through RepairedRtpStreamId (HE and RTCP SR)

o   That the rtx redundancy RTP stream may, but need not, have an RtpStreamId of its own; in this case, there should be no risk that an implementation does not know of RepairedRtpStreamId or that it is used to relate to the original RTP stream RtpStreamId

·         In both cases above, RTCP SR with SDES RtpStreamId and/or RepairedRtpStreamId for the rtx redundancy RTP stream can be used by the RTP receiver to learn which SSRC the retransmitted stream has, even before receiving the first retransmitted RTP packet

I’m personally slightly inclined to suggest always using RepairedRtpStreamId in the rtx redundancy RTP stream to relate it to the original RTP stream (second “if” bullet above), mainly to avoid having to change interpretation of RtpStreamId based on the optional presence of RepairedRtpStreamId. I’m of course open to arguments.

I also propose that this relation between “a=rid” and retransmission is documented in -mmusic-rid rather than in -mmusic-sdp-simulcast, since I find nothing in this that is specific to simulcast.

/Bo
(as individual)

From: rtcweb [mailto:[email-masked]] On Behalf Of Taylor Brandstetter
Sent: den 11 mars 2017 00:18
To: Iñaki Baz Castillo <[email-masked]>
Cc: RTCWeb IETF <[email-masked]>; [email-masked]
Subject: Re: [rtcweb] How to signal RTX SSRCs with simulcast

What question are we still trying to answer? "How do we know that RTX is active"? I think Iñaki already gave the right answer earlier: if the endpoints negotiate an RTX "media format" ("a=rtpmap:96 rtx/90000"), each endpoint should be prepared to receive RTX packets for any encoding.

And if the "rid" line explicitly specifies what payload types are allowed to be used with that RID, it just needs to include the RTX payload type to allow RTX to be used. Like so:

a=rtpmap:96 VP8/90000
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rid:foo send pt=96,97

But JSEP doesn't say "pt=" should be used, so I don't think this is even a concern.

On Fri, Mar 10, 2017 at 2:56 PM, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> wrote:
2017-03-10 23:54 GMT+01:00 Cullen Jennings <[email-masked]<mailto:[email-masked]>>:
>> If no simulcast, those two video streams are in different m=video sections, right?

> yes

I think that your example does not "work" well since simulcast is
achieved within a single m=video section.

--
Iñaki Baz Castillo
<[email-masked]<mailto:[email-masked]>>
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 13 Mar 2017 11:46:01 +0100

2017-03-13 10:56 GMT+01:00 Bo Burman <[email-masked]>:
> I’m personally slightly inclined to suggest always using RepairedRtpStreamId
> in the rtx redundancy RTP stream to relate it to the original RTP stream
> (second “if” bullet above), mainly to avoid having to change interpretation
> of RtpStreamId based on the optional presence of RepairedRtpStreamId. I’m of
> course open to arguments.

Personally I prefer option A (use a shared RtpStreamId). My rationale:

If we go with option B (RepairedRtpStreamId) then we will need
something similar when it comes to FLEX-FEC [*]:

        v=0
        o=ali 1122334455 1122334466 IN IP4 fec.example.com
        s=2-D Parity FEC with no in band signalling Example
        t=0 0
        m=video 30000 RTP/AVP 100 110
        c=IN IP4 233.252.0.1/127
        a=rtpmap:100 MP2T/90000
        a=rtpmap:110 flexfec/90000
        a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000
        a=ssrc:1234
        a=ssrc:2345
        a=ssrc-group:FEC-FR 1234 2345

For me it's to think in RtpStreamId as "the identificator of a media
stream and, optionally, also the identificator of the RTX stream and
FEC stream of such a media stream".

[*] https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-03

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 13 Mar 2017 11:46:35 +0100

> FEC stream of such a media stream".

Sorry, I meant "For me it's OK to think in...".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Bo Burman <[email-masked]>
Date: Mon, 13 Mar 2017 11:41:10 +0000

Could you elaborate a bit to help me understand why that would be needed for FLEX-FEC when using RepairedRtpStreamId?

Is it that you get explicit indication in SDP, like "a=rid:<rid-id> send pt=<media-fmt>,<redundancy-fmt> ..." when using RtpStreamId for both original and redundancy RTP stream?

I guess that use of RtpStreamId or RepairedRtpStreamId on RTP level (in the RTP and RTCP packets) should not matter much, neither for FLEX-FEC nor RTX, as long as it is clearly defined what it means?

/Bo
(as individual)

> -----Original Message-----
> From: Iñaki Baz Castillo [mailto:[email-masked]]
> Sent: den 13 mars 2017 11:46
> 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
> 
> > I’m personally slightly inclined to suggest always using
> > RepairedRtpStreamId in the rtx redundancy RTP stream to relate it to
> > the original RTP stream (second “if” bullet above), mainly to avoid
> > having to change interpretation of RtpStreamId based on the optional
> > presence of RepairedRtpStreamId. I’m of course open to arguments.
> 
> If we go with option B (RepairedRtpStreamId) then we will need something similar when it comes to FLEX-FEC [*]:
> 
>         v=0
> For me it's to think in RtpStreamId as "the identificator of a media stream and, optionally, also the identificator of the RTX
> stream and FEC stream of such a media stream".
> 
> 
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 13 Mar 2017 12:49:35 +0100

> Could you elaborate a bit to help me understand why that would be needed for FLEX-FEC when using RepairedRtpStreamId?

I just meant that, in case of option A above, FLEX-FEC would require
the same as RTX (when RID is in use and ssrcs are therefore not
signaled).

> I guess that use of RtpStreamId or RepairedRtpStreamId on RTP level (in the RTP and RTCP packets) should not matter much, neither for FLEX-FEC nor RTX, as long as it is clearly defined what it mean…

I'm not against it. It's just that this requires a new draft about RID
and "complementary streams" (or include it into existing ones).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Bo Burman <[email-masked]>
Date: Mon, 13 Mar 2017 13:41:14 +0000

> Sent: den 13 mars 2017 12:50
> 
> I just meant that, in case of option A above, FLEX-FEC would require the same as RTX (when RID is in use and ssrcs are
> therefore not signaled).
[BoB] OK

> 
> 
> > I guess that use of RtpStreamId or RepairedRtpStreamId on RTP level (in the RTP and RTCP packets) should not matter
> much, neither for FLEX-FEC nor RTX, as long as it is clearly defined what it means?
> 
> I'm not against it. It's just that this requires a new draft about RID and "complementary streams" (or include it into
> existing ones).
[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.

/Bo
(as individual)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 13 Mar 2017 14:43:07 +0100

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

Agreed.

-- 
Iñaki Baz Castillo
<[email-masked]>