1164187 - Implement RTX for WebRTC

Status: RESOLVED FIXED

(Core :: WebRTC: Signaling, enhancement, P1)

Description

[Pablo]

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

[Byron Campen [:bwc]]

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

[Byron Campen [:bwc]]

Ok, it seems that Chrome does this for video, so webrtc.org probably supports it.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 4

[Nils Ohlmeier [:drno]]

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

[Randell Jesup [:jesup] (needinfo me)]

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

[Philipp Hancke [:fippo]]

doesn't it influence those RTCP statistics that are responsible for congestion control, i.e. loss rate?

Comment 7

[sergio.garcia.murillo]

Negative packet loss! ;)

Comment 8

[Iñaki Baz Castillo]

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

[George Politis [:gp]]

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

[George Politis [:gp]]

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

[Bulk Bug Changes for mreavy's org]

Mass change P3->P4 to align with new Mozilla triage process.

Comment 12

[Jeremy Geras]

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

[Lee Ho]

(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

[Lee Ho]

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

[Philipp Hancke [:fippo]]

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

[oscar.divorra]

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

[Nils Ohlmeier [:drno]]

(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

[Nils Ohlmeier [:drno]]

(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

[oscar.divorra]

(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

[sergio.garcia.murillo]

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

[Iñaki Baz Castillo]

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

[sergio.garcia.murillo]

Not sure if RepairedRtpStreamId is fully supported on libwertc, but supporting ssrc-group attribute for rtx should be quite simple.

Comment 23

[Iñaki Baz Castillo]

 libwebrtc does not event support RID.

Comment 24

[Iñaki Baz Castillo]

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

[sergio.garcia.murillo]

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

[Iñaki Baz Castillo]

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

[sergio.garcia.murillo]

> 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

[sergio.garcia.murillo]

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

[Francesco Durighetto]

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

[mmahimtura]

Hello all,

Please comment and let me know if there has been a decision made about supporting RTX.

Thanks

Comment 31

[sergio.garcia.murillo]

Attachment: Implement RTX (bug #:1164187)

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

[sergio.garcia.murillo]

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

[Iñaki Baz Castillo]

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

[sergio.garcia.murillo]

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

[Iñaki Baz Castillo]

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

[sergio.garcia.murillo]

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

[Iñaki Baz Castillo]

> 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

[sergio.garcia.murillo]

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.

Comment 39

[Jeremy Lainé]

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

[sergio.garcia.murillo]

mime types are case insensitive, so should be irrelevant

Comment 41

[Byron Campen [:bwc]]

Are you still able to work on this?

Comment 42

[Nils Ohlmeier [:drno]]

(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

[Nils Ohlmeier [:drno]]

Attachment: Bug 1164187: Implement RTX support for WebRTC. r=bwc

This turns on support for RTC (RFC 4588) in our WebRTC implementation.
Thank you to Sergio Garcia Murillo for the initial patch!

Comment 44

[Caspy7]

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

[Byron Campen [:bwc]]

This bug looks stalled right now.

Comment 46

[ona]

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

Comment 47

[sam tygier]

I have created a bounty towards this work: https://www.bountysource.com/issues/90834026-implement-rtx-for-webrtc

Comment 48

[ona]

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

[@fanf42]

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

[ona]

(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

[sam tygier]

(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

[Mike Hoye [:mhoye]]

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.

Comment 53

[Nico Grunbaum [:ng, @chew:mozilla.org]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d1113fcda31e4a98785da95d914375c5b40aec59

Comment 54

[Iñaki Baz Castillo]

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

[Byron Campen [:bwc]]

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

[Iñaki Baz Castillo]

Ok, Sergio just told me that FF will send RID into RTX packets (instead of the standard RRID).

Comment 57

[Nico Grunbaum [:ng, @chew:mozilla.org]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=7615079ead5030f10856cbab531aa5b763c04c14

Comment 58

[ona]

(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

Sorry if it is off-topic, but we have tried to register with an gmail and other email domain and it is not possible. I have gone and reported in their chat and remain for a day and they didn't answer. I have done test with emails for 2 days, the last this morning. I wanted to make diffusion, since I can't collaborate because I don't have knowledge in this subject to invite people that complains to pay. If someone with much knowledge or other means to communicate, tell to them (I have not twitter or private socials networks).

Thanks a lot: I see you are working hard and Jitsi is compromised to resolve this problem too :)

Comment 59

[ona]

(In reply to ona from comment #58)

(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

Sorry if it is off-topic, but we have tried to register with an gmail and other email domain and it is not possible. I have gone and reported in their chat and remain for a day and they didn't answer. I have done test with emails for 2 days, the last this morning. I wanted to make diffusion, since I can't collaborate because I don't have knowledge in this subject to invite people that complains to pay. If someone with much knowledge or other means to communicate, tell to them (I have not twitter or private socials networks).

Thanks a lot: I see you are working hard and Jitsi is compromised to resolve this problem too :)

It is not possible because we don't receive the email confirmation. Sorry to report incompletely

Comment 60

[Jérôme]

As a workaround, I advise the Chromium web browser which works well with Jitsi Meet.

Comment 61

[Iñaki Baz Castillo]

(In reply to Jérôme from comment #60)

As a workaround, I advise the Chromium web browser which works well with Jitsi Meet.

This is not a user forum but the Mozilla Firefox bug tracker. Please don't come here to recommend Chrome/Chromium browser.

Comment 62

[alex_mayorga]

¡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

[Óvári]

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

[Alex Chronopoulos [:achronop]]

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.

Comment 65

[Dan Minor [:dminor]]

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

Comment 66

[Dan Minor [:dminor]]

Attachment: Bug 1164187 - Fixes to RtxParameters; r=bwc!

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.

Comment 67

[Dan Minor [:dminor]]

Attachment: Bug 1164187 - Add support for parsing rtx fmtp parameters in sipcc; r=bwc!

Depends on D72222

Comment 68

[Dan Minor [:dminor]]

Attachment: Bug 1164187 - Add sdp unit test for rtx; r=bwc!

Depends on D72223

Comment 69

[Dan Minor [:dminor]]

Attachment: Bug 1164187 - Add jsep support for rtx; r=bwc!

Depends on D72224

Comment 70

[Dan Minor [:dminor]]

Attachment: Bug 1164187 - Update JsepSessionTest for rtx; r=bwc!

Depends on D72225

Comment 71

[Dan Minor [:dminor]]

Attachment: Bug 1164187 - Add new JsepSessionTests for rtx; r=bwc!

Depends on D72226

Comment 72

[Dan Minor [:dminor]]

Attachment: Bug 1164187 - Plumb rtx through peerconnection and conduits; r=bwc!

Depends on D72228

Comment 73

[Dan Minor [:dminor]]

Attachment: Bug 1164187 - Do not switch ssrcs for packets with rtx and ulpfec packet types; r=bwc!

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

Comment 74

[Dan Minor [:dminor]]

Attachment: Bug 1164187 - Add pref for rtx; r=bwc!

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

Comment 75

[Pulsebot]

Pushed by [e-mail]:
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

[Óvári]

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

[Narcis Beleuzu [:NarcisB]]

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

Comment 78

[Dan Minor [:dminor]]

(In reply to Óvári from comment #76)

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

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.

Comment 79

[Óvári]

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

1. What stage/date of the Firefox 78 Beta would determine that everything seems to be working fine or otherwise?
2. Is there a separate issue for "repaired-rid support" or would this be added to this issue?

Thank you

Comment 80

[Dan Minor [:dminor]]

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

1. What stage/date of the Firefox 78 Beta would determine that everything seems to be working fine or otherwise?
2. 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

[Óvári]

(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

[Eric Shepherd [:sheppy]]

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

[Mathew Hodson]

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

[Alfredo]

Does firefox 78 support RTX for WebRTC?

Comment 85

[Dan Minor [:dminor]]

(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

[Óvári]

(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

[siva.a.shankar]

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

[Óvári]

(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

Comment 89

[Dan Minor [:dminor]]

(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

[Óvári]

(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

[Mathew Hodson]

This feature was enabled by default with bug 1651722.