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

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 protected]] On Behalf Of Taylor Brandstetter
Sent: den 11 mars 2017 00:18
To: Iñaki Baz Castillo <[email protected]>
Cc: RTCWeb IETF <[email protected]>; [email protected]
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 protected]<mailto:[email protected]>> wrote:
2017-03-10 23:54 GMT+01:00 Cullen Jennings <[email protected]<mailto:[email protected]>>:
>> 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 protected]<mailto:[email protected]>>
_______________________________________________
rtcweb mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
rtcweb mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtcweb