Implement RTX for WebRTC
Categories
(Core :: WebRTC: Signaling, enhancement, P1)
Tracking
()
backlog | webrtc/webaudio+ |
People
(Reporter: pablo.platt, Assigned: dminor)
References
(Blocks 1 open bug)
Details
(Keywords: dev-doc-needed, Whiteboard: [jitsi-meet][wfh])
Attachments
(9 files, 2 obsolete files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150508094354 Steps to reproduce: From draft-ietf-rtcweb-jsep-09 "[RFC4588] MUST be implemented to signal RTX payload type associations." RTX RFC https://tools.ietf.org/html/rfc4588 Thanks
Comment 1•9 years ago
|
||
Do we know if the webrtc.org code supports RTP RTX? I have a feeling that support for this is a long way out.
Comment 2•9 years ago
|
||
Ok, it seems that Chrome does this for video, so webrtc.org probably supports it.
Comment 3•9 years ago
|
||
(In reply to Byron Campen [:bwc] from comment #2) > Ok, it seems that Chrome does this for video, so webrtc.org probably > supports it. It does, though we haven't tested it here.
Updated•9 years ago
|
Updated•9 years ago
|
Comment 4•7 years ago
|
||
Worth pointing out that once we add support for RTX we need to add support to a=ssrc-group in SDP handling as well apparently.
Comment 5•7 years ago
|
||
So the spec says we must implement RTX. Does it say we have to offer it, or if offered we have to accept it? I see little practical use in turning on RTX; not using it merely means that the requirement in sections 2 and 3 of RFC 4588 aren't dealt with -- retransmitting with the original payload/sequence means that RTCP statistics may be slightly incorrect, by the definition of plain no-retransmit RTP. In practice, how much does this hurt? Is it worth the additional complexity and negotiation? (and use of payload types?)
Comment 6•7 years ago
|
||
doesn't it influence those RTCP statistics that are responsible for congestion control, i.e. loss rate?
Comment 7•7 years ago
|
||
Negative packet loss! ;)
Comment 8•7 years ago
|
||
RTX is also good for the remote to properly distinguish between retransmitted packets amd reordered packets, which can be useful to determine the proper BWE for the sender.
Comment 9•7 years ago
|
||
RTX is also useful when probing for bandwidth: instead of sending empty padding packets in-line, the engine may send duplicate packets of the media stream in the RTX stream. This reduces the risk of actual losses as a result of probing. Furthermore probing for bandwidth with RTX makes it easier for the SFU to terminate probing. Some related observations, 1. RTX and in-band probing are not the only two ways to probe for bandwidth, 2. FF seems to have inherited the webrtc.org probing mechanism and it's sending padding packets when simulcast is enabled, which makes it harder for us (jitsi) to implement simulcast support for FF.
Comment 10•7 years ago
|
||
just a clarification because my wording is confusing, when RTX is enabled the webrtc.org engine will send dups in the RTX stream; without RTX it probes with padding packets (RTP packets filled with 0s) in-band, which is what FF seems to be doing (because it lacks RTX support).
Comment 11•7 years ago
|
||
Mass change P3->P4 to align with new Mozilla triage process.
Comment 12•6 years ago
|
||
Isn't RTX also required to prevent SRTP from thinking there's a replay attack (if sending raw retransmitted packets with the same session and SSRC as the original?) See https://groups.google.com/forum/#!topic/discuss-webrtc/Gx0yUGeAYIQ
Comment 13•6 years ago
|
||
(In reply to Jeremy Geras from comment #12) > Isn't RTX also required to prevent SRTP from thinking there's a replay > attack (if sending raw retransmitted packets with the same session and SSRC > as the original?) > > See https://groups.google.com/forum/#!topic/discuss-webrtc/Gx0yUGeAYIQ Yes, that's right. The separate SSRC used for RTX packets avoids keystream re-use (the two-time pad problem).
Comment 14•6 years ago
|
||
Just in case it needs to be stated explicitly (reviewing the comment history here, it doesn't seem like there's a consensus), the key benefit of supporting RTX is that when any given packet from a video stream is reported as lost by the receiver using a NACK, the sender only needs to resend the lost packet to repair the stream (assuming the round-trip delay is low enough). Without RTX, the sender needs to send an intra-frame (which uses much more bandwidth and which may itself lose packets), and results in the receiving user seeing the video freeze momentarily after every lost packet. Under constant loss rates of 1-8%, RTX can even provide flawless video reception, versus very frequent video freezes. In fact, I would argue that this feature, which is currently marked as P4, is a much more critical feature than FEC support (Bug 875922), which is currently marked as P2, because FEC can use significant bandwidth without handling bursty loss well.
Comment 15•6 years ago
|
||
Lee Ho: I don't think that is true. Without RTX the response to a NACK is the original packet instead of the same packet wrapped in RTX. What you are describing sounds more like the lack of NACK and that is implemented already. jeremy: SRTP won't consider this a replay attack unless it has already received the packet -- in which case its safe to drop. This is only a problem with naive SFU implementations.
Comment 16•6 years ago
|
||
The issue could be if a Browser implemented just RTX for WebRTC as retransmission means and needs to interop with Firefox (Firefox at the receiving side). If I didn't miss anything, I think that is the case for Edge, it only supports RTX for WebRTC for sending retransmissions I believe.
Comment 17•6 years ago
|
||
(In reply to oscar from comment #16) > The issue could be if a Browser implemented just RTX for WebRTC as > retransmission means and needs to interop with Firefox (Firefox at the > receiving side). > If I didn't miss anything, I think that is the case for Edge, it only > supports RTX for WebRTC for sending retransmissions I believe. But that's what SDP is for: to negotiate which features are supported and which not. Only implementing RTX and expecting all implementations to have at least implemented that sounds wrong to me.
Comment 18•6 years ago
|
||
(In reply to Lee Ho from comment #14) > Just in case it needs to be stated explicitly (reviewing the comment history > here, it doesn't seem like there's a consensus), the key benefit of > supporting RTX is that when any given packet from a video stream is reported > as lost by the receiver using a NACK, the sender only needs to resend the > lost packet to repair the stream (assuming the round-trip delay is low > enough). Without RTX, the sender needs to send an intra-frame (which uses > much more bandwidth and which may itself lose packets), and results in the > receiving user seeing the video freeze momentarily after every lost packet. Just to make clear: this is not true. Firefox has no support for RTX. And a missed video packet does not result in a full intra-frame getting send to recover from that loss. If that would be case video in Firefox would freeze all the time, and we would have prioritized this higher. When receiving the NACK Firefox simply sends exactly the missing packet again. On the SSRC of the stream where it's missing. On the wire it basically looks like a out-of-order retransmission.
Comment 19•6 years ago
|
||
(In reply to Nils Ohlmeier [:drno] from comment #17) > (In reply to oscar from comment #16) > > The issue could be if a Browser implemented just RTX for WebRTC as > > retransmission means and needs to interop with Firefox (Firefox at the > > receiving side). > > If I didn't miss anything, I think that is the case for Edge, it only > > supports RTX for WebRTC for sending retransmissions I believe. > > But that's what SDP is for: to negotiate which features are supported and > which not. Only implementing RTX and expecting all implementations to have > at least implemented that sounds wrong to me. Nils, sure, we all know what SDP negotiation is for. What I understand from current implementations, is that the behaviour in the case of an Edge sending and Firefox receiving is going to be that retransmissions will be turned off (since I believe Edge doesn't retransmit at all if the receiver does not support required ssrc multiplexed rtx from 4588), thus with the consequent loss in network resilience. Chrome and FF they do retransmit with the original payload/sequence, making the issue minor.
Comment 20•6 years ago
|
||
May i ask why is this resistance about implementing RTX? Seems like an arbitrary decision, so would like to understand what is preventing to implement it.
Comment 21•6 years ago
|
||
I feel the pain: Firefox implements RID for simulcast (even if it also signals SSRC values in the SDP). When it comes to signal RTX streams, a=ssrc-group can be used. However, the way to go with RID is RepairedRtpStreamId: https://tools.ietf.org/html/draft-ietf-avtext-rid-09, yet another RTP header extension. Firefox may do both: - use a=ssrc-group for signaling and associate RTX SSRC values in the SDP, - and use the RepairedRtpStreamId RTP header extension So I don't think this is about "resistance" but about complexity.
Comment 22•6 years ago
|
||
Not sure if RepairedRtpStreamId is fully supported on libwertc, but supporting ssrc-group attribute for rtx should be quite simple.
Comment 23•6 years ago
|
||
libwebrtc does not event support RID.
Comment 24•6 years ago
|
||
And IMHO it does not make much sense to use RID, which makes a=ssrc in SDP unnecessary (and makes it posible to change the SSRC on-the-fly because WE ALL KNOW THAT SSRC CONFLICTS DO HAPPEN EVEN IF THEY NEVER HAPPEN) and then having to signal RTX SSRCs in the SDP...
Comment 25•6 years ago
|
||
Well, if FF implements RID, i guess libwebrtc supports it somehow also.. ;) I know for sure it supports both extensions: constexpr ExtensionInfo kExtensions[] = { CreateExtensionInfo<TransmissionOffset>(), CreateExtensionInfo<AudioLevel>(), CreateExtensionInfo<AbsoluteSendTime>(), CreateExtensionInfo<VideoOrientation>(), CreateExtensionInfo<TransportSequenceNumber>(), CreateExtensionInfo<PlayoutDelayLimits>(), CreateExtensionInfo<VideoContentTypeExtension>(), CreateExtensionInfo<VideoTimingExtension>(), CreateExtensionInfo<RtpStreamId>(), CreateExtensionInfo<RepairedRtpStreamId>(), CreateExtensionInfo<RtpMid>(), }; Re. SSRC vs RID, you need to match the rtx stream with the rtp stream somehow, either RepairedRtpStreamId or ssrc-group, but you need at least one them.
Comment 26•6 years ago
|
||
Maybe libwebrtc is "ready" for RID but I've not seen it in RTP packets so far, neither the SDP generated by libwebrtc has a=rid lines at all.
> Re. SSRC vs RID, you need to match the rtx stream with the rtp stream somehow, either RepairedRtpStreamId or ssrc-group, but you need at least one them.
I've never said the opposite. I just meant that, given that Firefox properly implements RID (SSRC unaware) the ideal way to go is RepairedRtpStreamId.
Comment 27•6 years ago
|
||
> IMHO it does not make much sense to use RID
I failed to parse the rest of the your phrase.
RID is fully supported by the libwebrtc's rtp_rtcp module and it is just not negotiated/enabled on the PC/SDP layer. As you know, FF implement their own PC/SDP stuff, so that's why they are able to use it. Not sure if the RepairedRtpStreamId extension is fully usable in the rtcp_rtp module or if it is just half supported and not usable yet by FF.
Anyway, to be compatible with Edge/Chrome/Safari which don't use RIDs yet but ssrcs, it would be needed to implement ssrc-group.
So back to my original question, I would like to understand if what is the reason that is holding back the support of RTX in FF, if it is implementation complexity, or it is an strategic decision of some other kind.
Maybe if we understood the reasoning, we would be able to push in other directions.
Comment 28•6 years ago
|
||
One more question, given that Firefox doesn't support RTX, what is the most efficient way of doing bandwidth probing without disrupting media?
Comment 29•6 years ago
|
||
Hi guys, So what's the status of the "decision"? The main problem I see here is that Edge does not support nack on a NON RTX channel, so a p2p call between firefox and edge, will freeze at the first packet lost and this is quite annoying, since the interoperability on "consumer grade connection" condition is practically broken.
Comment 30•6 years ago
|
||
Hello all, Please comment and let me know if there has been a decision made about supporting RTX. Thanks
Comment 31•5 years ago
|
||
The patch includes the following changes: Add support for rtx format an apt attribute Modify both rs and sipcc sdp parsers New SdpFmtpAttributeList::RtxParameters with apt value Add SdpSsrcGroupAttributeList getter in SdpAttributeList Support rtx info on JsepCodecDescription Add mAssociatedPayload type for RTX video codec info Add rtxPayloadType and mRTXEnabled for the video codec info associated to the rtx paylaod. Add new RTX video codec description for each video codec in SetupDefaultCodecs On JsepTrack::NegotiateCodecs check RTX codec is present and enable rtx on video codec description of the associated payload type Add the rtx codec for the preferred codec int the codecsToKeep Set the libwebrtc send and receive config of theWebrtcVideoConduit with the rtx payload info RTX SSRC support Add SdpSsrcGroupAttributeList to the SdpAttributeList for both rs and sipcc code Add sdp parsing for ssrc-group for both rs and sipcc parsers Add GetFidGroups to the SdpHelper On the video conduit add a new attributes to host all the rtx ssrcs as a separate info. Modify the media conduit SetRemoteSSRC to be pass both the media ssrc and rtx ssrc at once (audio sets the rtx ssrc to 0). Modify the media conduit SetLocalSSRC to be pass both the media ssrc and rtx ssrc vectors at once (audio sets the rtx ssrc to empty vector). In JseptTrack add a new vector for storing the rtx ssrc as separate vector and generate them on the same places where the media ssrc vector is modified Add ssrcs to the media section in JsepTrack Add FID groups ito media section in JsepTrack When parsing remote ssrcs in JSepTrack, first parse ssrcs in FID groups, assigning either to media ssrc or rtx, and then for each ssrc attribute, check if it was not already present in one of the to vectors and append then to the media ssrc one (to handle backward compatibility) Set the ssrcs on the WebrtcVideoConduit on the libwebrtc send/recv configs
Comment 32•5 years ago
|
||
Tested both at network level and interoperability with vanilla firefox and chrome. Still some unit tests missing for ensuring SDP O/A with no rtx-entities, but hope to have them ready next week.
Comment 33•5 years ago
|
||
Good work! However, it seems that this code uses "a=ssrc-group: FID" for RTX. So, we have FF sending a=rid for simulcast (without signaling a=ssrc lines), but this code adds both media and RTX SSRCs into a=ssrc lines, is that right? Shouldn't FF go for RepairedRtpStreamId instead as defined in https://tools.ietf.org/html/draft-ietf-avtext-rid-09? Of course, RepairedRtpStreamId could just be used when sending simulcast with RTX. For receiving (no simulcast here) we still need the "a=ssrc-group: FID" stuff. This is hyper confusing for me: what does RTCWEB WG say about this? Isn't it yet clear which specs must be implemented to use RTX with simulcast?
Comment 34•5 years ago
|
||
The scope of this patch is implementing RTX without breaking interoperability with other browsers and given the state of art of libwebrtc, so supporting ssrc-group was needed. Note that signaling ssrc-group does not imply that RepairedRtpStreamId is not sent also in the rtx stream (I have not checked, but everything is wired up to libwebrtc to do so). Also, supporting receiving ssrc-group in remote sdp and being able to use it does not imply that association based RepairedRtpStreamId would not work if signaled+used. In fact FF does use it when learning ssrcs, but not sure if libwebrtc supports it internally. So, while this patch does not intend to provide the final rfc spec version, it doesn't create any conflict while implemented it and in fact can be done later additionally to this patch.
Comment 35•5 years ago
|
||
Yes sure, I understand. My complaint is more about the lack of clarification in WebRTC WG regarding simulcast and RTX. In fact I've asked in rtcweb mailing list right now about this: https://www.ietf.org/mail-archive/web/rtcweb/current/msg17540.html > Note that signaling ssrc-group does not imply that RepairedRtpStreamId is not sent also in the rtx stream (I have not checked, but everything is wired up to libwebrtc to do so). So you are saying that libwebrtc is ready to send RepairedRtpStreamId RTP header extension into RTX packets, right? If so, which is the way to signal those RepairedRtpStreamId in the SDP? I've not found any spec defining it. I mean something like a=rrid or whatever.
Comment 36•5 years ago
|
||
The rrid header has the same value as the rid one (so you can correlate both streams) so there is no need for signaling anything on SDP than the rid (which is already done) . As librbrtc has already the rid value, it could send it also on the rtx stream rrid header. IIRC it was also proposed to send rid header in rtx stream and differentiate both streams by pt. I guess it is the same mechanics than when rid is not in use and you only have the mid available.
Comment 37•5 years ago
|
||
> The rrid header has the same value as the rid one (so you can correlate both streams) so there is no need for signaling anything on SDP than the rid
Ah ok, I didn't know that rrid had the same value as rid. Makes sense.
Comment 38•5 years ago
|
||
Confirmed that by default FF copies all the packet headers in the rtx packet (this should contain the mid and the rid). Waiting for confirmation at IETF mailing list if rid should be removed from the rtx packet and added a new RepairedRtpStreamId header with new value, just send rid as today or send both.
Assignee | ||
Updated•5 years ago
|
Comment 39•5 years ago
|
||
Out of curiosity, why "RTX" in capitals in the SDP? RFC 4588 mentions audio/rtx, video/rtx, etc.. in lowercase and Chrome also uses a lowercase "rtx" in its SDP.
Comment 40•5 years ago
|
||
mime types are case insensitive, so should be irrelevant
Comment 41•5 years ago
|
||
Are you still able to work on this?
Comment 42•5 years ago
|
||
(In reply to Jeremy Lainé from comment #39)
Out of curiosity, why "RTX" in capitals in the SDP? RFC 4588 mentions
audio/rtx, video/rtx, etc.. in lowercase and Chrome also uses a lowercase
"rtx" in its SDP.
You are right. Since the RFC actually uses lower case I'm going to change it lower case in Firefox as well.
Comment 43•5 years ago
|
||
This turns on support for RTC (RFC 4588) in our WebRTC implementation.
Thank you to Sergio Garcia Murillo for the initial patch!
Updated•5 years ago
|
Comment 44•5 years ago
|
||
What's the status or next steps for this bug?
Appears to me like there's an 8 month old ni that may not happen?
Comment 45•4 years ago
|
||
This bug looks stalled right now.
Updated•4 years ago
|
Comment 46•4 years ago
|
||
Hello and thanks for all your work
I have been years recommending and teaching Firefox and now, for the first time I have to recommend to people not to use Firefox.
Please, make this feature request in this moments of so much need on communicating and organizing.
Thanks
Assignee | ||
Updated•4 years ago
|
Comment 47•4 years ago
|
||
offtopic-reviewed |
I have created a bounty towards this work: https://www.bountysource.com/issues/90834026-implement-rtx-for-webrtc
Comment 48•4 years ago
|
||
Hello and sorry for the bad reporting before :)
With Coronavirus a face-to-face class that I was going to give ended in a online class. When testing in Ubuntu 18.04 with Firefox 74.0 (64-bit), I realize that I was not able to share the screen with Jitsi meet. I searched and found that many users had problems and I didn't want to use Chrome, so I tried an old Firefox that I had, Firefox Developer Edition 64.0b8 (64-bit) and it worked. Then in the class we had to reconnect many times because we lost sound. So after the class, I kept searching and ended here from
https://github.com/jitsi/jitsi-meet/issues/4758
Now, when I have to use Jitsi, I have to say to people not to use Firefox :_( but that this will change and I will tell to them.
At this moment, I have ended another task and I will be pleased to test anything you need, here or in any other issue related to this problem. I find this problem very important because Jitsi is becoming famous and people that come to open source sofware with Firefox and doesn't know about what you are solving comments that free software is not good :(
Thanks a lot for your generous work
Comment 49•4 years ago
|
||
Same for me. For the first time in 19 years (!!!), I need to not recommand ff but chromium. In this period where jitsi in particular is gaining momemtum, this bug is earning an enormous visibility and it will make advocacy for FF even harder.
Comment 50•4 years ago
|
||
offtopic-reviewed |
(In reply to sam tygier from comment #47)
I have created a bounty towards this work: https://www.bountysource.com/issues/90834026-implement-rtx-for-webrtc
I have not paypal and found a friend to make a donation, but now the bounty page gives an error. I have tried several times for 3h.
Application error
An error occurred in the application and your page could not be served. If you are the application owner, check your logs for details. You can do this from the Heroku CLI with the command
heroku logs --tail
Comment 51•4 years ago
|
||
offtopic-reviewed |
(In reply to ona from comment #50)
bounty page gives an error. I have tried several times for 3h.
"We're really sorry for the recent site performance issues. We are working to fix this." -- https://twitter.com/Bountysource/status/1245863063162466311
Comment 52•4 years ago
|
||
It looks like Bounty Source is broken, so for the moment I'm going to flag both of those comments as off-topic; if it comes back in a reasonable time frame I'll change that.
For everyone else, I promise that we share your sense of urgency about this and the related bugs. Media codecs and inter-company diplomacy are both delicate work on a good day, and these have not been good days; still, please trust that we care about this, and are working on it. We'll have more to say, both in this bug and elsewhere, when it's ready to ship.
Thank you all.
Assignee | ||
Updated•4 years ago
|
Comment 53•4 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d1113fcda31e4a98785da95d914375c5b40aec59
Comment 54•4 years ago
|
||
Sorry if I miss something (didn't follow the evolution of this issue). Does the RTX implementation of Firefox also work with 'rtp-stream-id' (RID) and 'repaired-rtp-stream-id' (RRID) RTP header extensions? libwebrtc does.
Does Firefox announce and negotiate support for 'repaired-rtp-stream-id'? Does it send RTX packets with such a extension header?
These questions are just about simulcast.
Comment 55•4 years ago
|
||
We do not support repaired-rtp-stream-id. I doubt the version of webrtc.org that we're using right now supports that.
Comment 56•4 years ago
|
||
Ok, Sergio just told me that FF will send RID into RTX packets (instead of the standard RRID).
Comment 57•4 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7615079ead5030f10856cbab531aa5b763c04c14
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (advocacy) |
Comment hidden (offtopic) |
Comment 62•4 years ago
|
||
¡Hola!
Ended up here via https://github.com/jitsi/jitsi-meet/issues/5439 https://github.com/jitsi/jitsi-meet/issues/5439#issuecomment-605458804 and https://github.com/jitsi/jitsi-meet/issues/4758#issuecomment-604465391
Updating flags accordingly FWIW as this is still an issue on Firefox Nightly 20200415092524.
¡Gracias!
Alex
Comment 63•4 years ago
|
||
Please add support in Firefox for changing of the audio output devices
https://bugzilla.mozilla.org/show_bug.cgi?id=1631672
Hey there, what browser are you seeing this on ? Please note that the speakers will only be enumerated one chrome. Firefox and Safari, do not support changing of the audio output devices and therefore do not enumerate those devices.
https://github.com/jitsi/jitsi-meet/issues/6208#issuecomment-616929454
Comment 64•4 years ago
|
||
We gonna release the output device enumeration (bug 1630289) before the support for changing the output device. However, we are working actively on the latter, it is more involved and it takes more time, it's coming rapidly though.
Assignee | ||
Comment 65•4 years ago
|
||
(In reply to Iñaki Baz Castillo from comment #56)
Ok, Sergio just told me that FF will send RID into RTX packets (instead of the standard RRID).
Sergio is correct, the rid is copied into the headers of the rtx packet from the original packet. I've filed Bug 1632489 for rrid support. Our version of libwebrtc appears to support it already, so this is hopefully just a matter of adding support to the sdp parsers and the jsep implementation. I think that is too big a chunk of work to do as part of this bug, but I plan to start on rrid once this is up for review.
Assignee | ||
Comment 66•4 years ago
|
||
This changes the constructor to not take any parameters for consistency
with how the other parameters are handled. It also fixes serialization, the
current code will output an ascii character rather than the numeric value.
Assignee | ||
Comment 67•4 years ago
|
||
Depends on D72222
Assignee | ||
Comment 68•4 years ago
|
||
Depends on D72223
Assignee | ||
Comment 69•4 years ago
|
||
Depends on D72224
Assignee | ||
Comment 70•4 years ago
|
||
Depends on D72225
Assignee | ||
Comment 71•4 years ago
|
||
Depends on D72226
Assignee | ||
Comment 72•4 years ago
|
||
Depends on D72228
Assignee | ||
Comment 73•4 years ago
|
||
With rtx enabled, we can't just switch ssrcs when we receive a packet with an
unrecognized ssrc. This changes the ReceiveRTPPacket call to take the entire
rtp header, and then examines the payload type. If the payload type is
associated with rtx or ulpfec, the ssrc will not be changed. This is what is
done by the libwebrtc unsignaled ssrc change code, so this behaviour should
match what Chrome does.
Depends on D72229
Assignee | ||
Comment 74•4 years ago
|
||
This is disabled by default. I think we'll want to either support rrid or
disable rtx when simulcast is enabled before we want to pref this on.
Depends on D72230
Updated•4 years ago
|
Updated•4 years ago
|
Comment 75•4 years ago
|
||
Pushed by dminor@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9dea3e3fde18 Fixes to RtxParameters; r=bwc https://hg.mozilla.org/integration/autoland/rev/681fef42e386 Add support for parsing rtx fmtp parameters in sipcc; r=bwc https://hg.mozilla.org/integration/autoland/rev/c985621e8c34 Add sdp unit test for rtx; r=bwc https://hg.mozilla.org/integration/autoland/rev/42b4a06406eb Add jsep support for rtx; r=bwc https://hg.mozilla.org/integration/autoland/rev/75f8af7968c0 Update JsepSessionTest for rtx; r=bwc https://hg.mozilla.org/integration/autoland/rev/6002ef13d802 Add new JsepSessionTests for rtx; r=bwc https://hg.mozilla.org/integration/autoland/rev/13f662a653da Plumb rtx through peerconnection and conduits; r=bwc https://hg.mozilla.org/integration/autoland/rev/22b469147068 Do not switch ssrcs for packets with rtx and ulpfec packet types; r=bwc https://hg.mozilla.org/integration/autoland/rev/b974cc5c2efa Add pref for rtx; r=bwc
Comment 76•4 years ago
|
||
Off by default until we land repaired-rid support.
https://hg.mozilla.org/integration/autoland/rev/b974cc5c2efa
Are you able to advise if all aspects of this issue, Implement RTX for WebRTC, are planned to be enabled by default for Firefox 78 ESR? Thank you
Comment 77•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/9dea3e3fde18
https://hg.mozilla.org/mozilla-central/rev/681fef42e386
https://hg.mozilla.org/mozilla-central/rev/c985621e8c34
https://hg.mozilla.org/mozilla-central/rev/42b4a06406eb
https://hg.mozilla.org/mozilla-central/rev/75f8af7968c0
https://hg.mozilla.org/mozilla-central/rev/6002ef13d802
https://hg.mozilla.org/mozilla-central/rev/13f662a653da
https://hg.mozilla.org/mozilla-central/rev/22b469147068
https://hg.mozilla.org/mozilla-central/rev/b974cc5c2efa
Updated•4 years ago
|
Assignee | ||
Comment 78•4 years ago
|
||
(In reply to Óvári from comment #76)
Off by default until we land repaired-rid support.
https://hg.mozilla.org/integration/autoland/rev/b974cc5c2efaAre you able to advise if all aspects of this issue, Implement RTX for WebRTC, are planned to be enabled by default for Firefox 78 ESR? Thank you
At the moment, we're only planning to enable this for "nightly or early beta" which means it would not default to on in Firefox 78. If everything seems to be working fine while Firefox 78 is in beta, it's possible we'll change this so that is in enabled in 78. We'll have to see how things go.
Updated•4 years ago
|
Comment 79•4 years ago
|
||
(In reply to Dan Minor [:dminor] from comment #78)
At the moment, we're only planning to enable this for "nightly or early beta" which means it would not default to on in Firefox 78. If everything seems to be working fine while Firefox 78 is in beta, it's possible we'll change this so that is in enabled in 78. We'll have to see how things go.
- What stage/date of the Firefox 78 Beta would determine that everything seems to be working fine or otherwise?
- Is there a separate issue for "repaired-rid support" or would this be added to this issue?
Thank you
Assignee | ||
Comment 80•4 years ago
|
||
(In reply to Óvári from comment #79)
(In reply to Dan Minor [:dminor] from comment #78)
At the moment, we're only planning to enable this for "nightly or early beta" which means it would not default to on in Firefox 78. If everything seems to be working fine while Firefox 78 is in beta, it's possible we'll change this so that is in enabled in 78. We'll have to see how things go.
- What stage/date of the Firefox 78 Beta would determine that everything seems to be working fine or otherwise?
- Is there a separate issue for "repaired-rid support" or would this be added to this issue?
Thank you
We've hit a bug with Google Meet when RTX is enabled, which forced us to add a blocklist preventing it from being used with certain sites (Bug 1641600) as well as a problem with our MID filter affecting RTX packets (Bug 1640697). Those are both fixed in Firefox 79 and I don't think there is any plan to backport them to Firefox 78, although that would be possible. Repaired Rid Support did land in Firefox 78 (Bug 1632489).
So at this point, it doesn't seem very likely we would enable RTX in Firefox 78, it seems too risky to me when we're still encountering significant bugs and site compatibility issues in Nightly.
Comment 81•4 years ago
|
||
(In reply to Dan Minor [:dminor] from comment #80)
So at this point, it doesn't seem very likely we would enable RTX in Firefox 78, it seems too risky to me when we're still encountering significant bugs and site compatibility issues in Nightly.
Is RTX planned to be enabled by default with Firefox 79? Thank you
Comment 82•4 years ago
•
|
||
At a minimum, this should be mentioned in the Firefox X for developers page.
Ideally, we should have some content added that explains what RTX is (retransmission of lost/corrupted packets) and what its benefits are. We should also cover how to control use of RTX and so on. Someone implementing a service needs to know specifically about its effects on network behavior (more bits being transferred), decoding/presentation behavior (more latency and better reliability), how RTX is signaled in SDP, etc. dminor and/or drno may have more information.
Comment 83•4 years ago
|
||
Since RTX is only enabled in early beta and earlier, it should be mentioned on https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features
Comment 84•4 years ago
|
||
Does firefox 78 support RTX for WebRTC?
Assignee | ||
Comment 85•4 years ago
|
||
(In reply to Nedo from comment #84)
Does firefox 78 support RTX for WebRTC?
Sort of. Support was landed, but it is behind a pref which defaults to off. There are also some bug fixes that only landed in Firefox 79. You can try turning it on, but you will likely run into problems.
Comment 86•4 years ago
|
||
(In reply to Dan Minor [:dminor] from comment #85)
Support was landed, but it is behind a pref which defaults to off. There are also some bug fixes that only landed in Firefox 79.
Will the pref be defaulted to on in Firefox 79? Thank you
Comment 87•4 years ago
|
||
Will the preference "media.peerconnection.video.use_rtx" value will this be false by default in the stable version?. Couldn't find this details from the documentation. Can I get an answer for this?
BlueJeans meeting is also failing by enabling "rtx", If we are enabling by default we might need to blacklist this "*.bluejeans.com" domain.
Please let us know.
Comment 88•4 years ago
|
||
(In reply to Dan Minor [:dminor] from comment #85)
(In reply to Nedo from comment #84)
Does firefox 78 support RTX for WebRTC?
Sort of. Support was landed, but it is behind a pref which defaults to off. There are also some bug fixes that only landed in Firefox 79. You can try turning it on, but you will likely run into problems.
Does Firefox 79.0 support RTX for WebRTC by default? Couldn't see anything about this in Firefox 79 release notes
https://www.mozilla.org/en-US/firefox/79.0/releasenotes/
Thank you
Assignee | ||
Comment 89•4 years ago
|
||
(In reply to Óvári from comment #88)
(In reply to Dan Minor [:dminor] from comment #85)
(In reply to Nedo from comment #84)
Does firefox 78 support RTX for WebRTC?
Sort of. Support was landed, but it is behind a pref which defaults to off. There are also some bug fixes that only landed in Firefox 79. You can try turning it on, but you will likely run into problems.
Does Firefox 79.0 support RTX for WebRTC by default? Couldn't see anything about this in Firefox 79 release notes
https://www.mozilla.org/en-US/firefox/79.0/releasenotes/Thank you
We've turned it on by default in Firefox 80.
Comment 90•4 years ago
|
||
(In reply to Dan Minor [:dminor] from comment #89)
We've turned it on by default in Firefox 80.
Thank you for your work and reply.
Looking forward to the Firefox 80 release on 2020-08-25.
Hopefully Firefox with Jitsi Meet will be even more performant.
Is this something that the Firefox 80 release notes will state?
Thank you once again.
Comment 91•4 years ago
|
||
This feature was enabled by default with bug 1651722.
Description
•