Bo Burman
2017-03-13 09:56:36 UTC
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:rtcweb-***@ietf.org] On Behalf Of Taylor Brandstetter
Sent: den 11 mars 2017 00:18
To: Iñaki Baz Castillo <***@aliax.net>
Cc: RTCWeb IETF <***@ietf.org>; draft-ietf-mmusic-sdp-***@ietf.org
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.
I think that your example does not "work" well since simulcast is
achieved within a single m=video section.
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:rtcweb-***@ietf.org] On Behalf Of Taylor Brandstetter
Sent: den 11 mars 2017 00:18
To: Iñaki Baz Castillo <***@aliax.net>
Cc: RTCWeb IETF <***@ietf.org>; draft-ietf-mmusic-sdp-***@ietf.org
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.
If no simulcast, those two video streams are in different m=video sections, right?
yesachieved within a single m=video section.
--
Iñaki Baz Castillo
<***@aliax.net<mailto:***@aliax.net>>
_______________________________________________
rtcweb mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb
Iñaki Baz Castillo
<***@aliax.net<mailto:***@aliax.net>>
_______________________________________________
rtcweb mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb