Enabling Forward Error Correction in Chrome.

[Robert Jongbloed]

I am trying to add WebRTC support to my VoIP library. Using a SIP stack over WebSocket, the SDP negotiation indicates that red and ulpfec are supported and accepted from the offer, and yet, Chrome only ever sends the raw VP8 video on payload type 100. Never the red packets on payload type 116.

Chrome offer:
m=video 1 RTP/SAVPF 100 116 117
...
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
...

My answer:
m=video 44094 RTP/SAVPF 100 116 117
a=rtcp-fb:* ccm fir
a=rtcp-fb:* nack pli
a=rtcp-fb:* goog-remb
a=rtpmap:100 VP8/90000
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
...

Which to the best of my knowledge is correct to all the relevant RFC's, and there are a few!


As an aside, Chome does not advertise support for PLI in it's SDP, and yet as far as I can determine it does, in fact, support it. Not rel4evant ot the problem at hand though.


Doing the web research, a lot of people talked about FEC only happening when there is packet loss. So, I hacked my code to fake packet loss in the RTCP-SR records sent back to Chrome for it's transmitted video. Even at 25% packet loss, no FEC packets were forthcoming. At 50%, Chome seemed to deem the link unusable and disconnected, though not at all sure that was the reason.

I have tried sending many PLI packets. I have tried sending REMB packets in case that was required. Nothing works.



Now, the final kicker, when I do a call between two computers running Chome (Mac to PC, if it matters) using https://apprtc.appspot.com, and observe the RTP traffic using Wireshark, I can see that Chrome is sending red packets, and, by implication ulpfec, via the payload type (116) which you can still see, as the RTP header not encrypted in SRTP.

As Chrome was sending red packet while over my LAN, the statements that it only does so in the presence of packet loss does not seem correct. It is certainly possible it is not putting in the redundant ulpfec part or the red packet until a certain level of packet loss, but it is sending red packets. And I have not managed to get it to do that much.


The conclusion is there is some criteria that Chrome needs, which has so far eluded me, does anyone have a clue as to what that might be?

Robert Jongbloed
OPAL/OpenH323/PTLib Architect and Co-founder.
Commercial support at http://www.voxlucida.com.au

[Vikas]

Looking at issue 2851 it seems like with the current libjingle problem related to FEC and NACK, the only way to enable FEC is by enabling both FEC and NACK. This is what apprtc does. Still not sure why it is not working for you.

/Vikas

[Justin Uberti]

When ulpfec and red are enabled, Chrome will always send red, but only include the FEC packets in the red when conditions warrant it.

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ben Weekes]

Is the best way to debug this type of thing to build the Chrome browser and run it through a debugger?

If so, is Windows the best platform for such things?

Thanks

Ben

[Fakher Oueslati]

Check this issue:   http://webrtc-codereview.appspot.com/7789004/
I have just finished correcting the problem.

[Robert Jongbloed]

Thank you very much for your efforts, I have two questions:


How long before a change like this flows through to Chrome?


Second, my problem is not the same as the one you indicate. In my case, first I am enabling NACK. Second, the other issue was seeing red packets, but no ulpfec. I am not even seeing red packets. Do you think the fix is the same for both behaviours?

Robert Jongbloed
OPAL/OpenH323/PTLib Architect and Co-founder.
Commercial support at http://www.voxlucida.com.au

On Thursday, February 6, 2014 6:14:11 AM UTC+11, Fakher Oueslati wrote:

Check this issue:   http://webrtc-codereview.appspot.com/7789004/
I have just finished correcting the problem.

On Monday, January 27, 2014 3:39:41 PM UTC-8, Robert Jongbloed wrote: