Corrupted/wrong NACK RTCP packets generated
Reported by
ibc@aliax.net,
Sep 11 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36 Steps to reproduce the problem: 1. Establish a video call with Chrome >= 62 (Canary) 2. Wait for Chrome to loose some packets so it asks for them sending NACK. What is the expected behavior? NACKs should look nice. What went wrong? NACK packets generated by Chrome follow a weird pattern, with many NACK items inside that don't make any sense. Here a parsed NACK packet received from Chrome: RTC::RTCP::FeedbackRtp::Dump() | <NACK> RTC::RTCP::Feedback::Dump() | sender ssrc : 1 RTC::RTCP::Feedback::Dump() | media ssrc : 98927014 RTC::RTCP::Feedback::Dump() | size : 40 RTC::RTCP::FeedbackRtpNack::Dump() | <FeedbackRtpNackItem> RTC::RTCP::FeedbackRtpNack::Dump() | pid : 58245 RTC::RTCP::FeedbackRtpNack::Dump() | bpl : 0011000001111111 RTC::RTCP::FeedbackRtpNack::Dump() | </FeedbackRtpNackItem> RTC::RTCP::FeedbackRtpNack::Dump() | <FeedbackRtpNackItem> RTC::RTCP::FeedbackRtpNack::Dump() | pid : 36814 RTC::RTCP::FeedbackRtpNack::Dump() | bpl : 0000000000000101 RTC::RTCP::FeedbackRtpNack::Dump() | </FeedbackRtpNackItem> RTC::RTCP::FeedbackRtpNack::Dump() | <FeedbackRtpNackItem> RTC::RTCP::FeedbackRtpNack::Dump() | pid : 0 RTC::RTCP::FeedbackRtpNack::Dump() | bpl : 0000000000000001 RTC::RTCP::FeedbackRtpNack::Dump() | </FeedbackRtpNackItem> RTC::RTCP::FeedbackRtpNack::Dump() | <FeedbackRtpNackItem> RTC::RTCP::FeedbackRtpNack::Dump() | pid : 0 RTC::RTCP::FeedbackRtpNack::Dump() | bpl : 0000000000000000 RTC::RTCP::FeedbackRtpNack::Dump() | </FeedbackRtpNackItem> RTC::RTCP::FeedbackRtpNack::Dump() | <FeedbackRtpNackItem> RTC::RTCP::FeedbackRtpNack::Dump() | pid : 21061 RTC::RTCP::FeedbackRtpNack::Dump() | bpl : 0100110101000010 RTC::RTCP::FeedbackRtpNack::Dump() | </FeedbackRtpNackItem> RTC::RTCP::FeedbackRtpNack::Dump() | <FeedbackRtpNackItem> RTC::RTCP::FeedbackRtpNack::Dump() | pid : 270 RTC::RTCP::FeedbackRtpNack::Dump() | bpl : 1100111011000000 RTC::RTCP::FeedbackRtpNack::Dump() | </FeedbackRtpNackItem> RTC::RTCP::FeedbackRtpNack::Dump() | <FeedbackRtpNackItem> RTC::RTCP::FeedbackRtpNack::Dump() | pid : 1509 RTC::RTCP::FeedbackRtpNack::Dump() | bpl : 1000000110100110 RTC::RTCP::FeedbackRtpNack::Dump() | </FeedbackRtpNackItem> RTC::RTCP::FeedbackRtp::Dump() | </NACK> A common pattern in most of those wrong NACK packets is that there are always two consecutive NACK items with pid (first requested seq number) with value 0 (as in the NACK above). Also, pids in these NACK items are not related at all, having values so different and incorrelated. Did this work before? N/A Chrome version: 63.0.3212.0 Channel: canary OS Version: OS X 10.12.6 Flash Version: This does not happen in Chrome 60 or 61, but it happens with 62 (dev) and 63 (Canary).
,
Sep 11 2017
,
Sep 11 2017
More info (in order to discard NACK parsing errors in our WebRTC server): - The "media ssrc: 98927014" is correct. That's the SSRC of the stream/track that Chrome is receiving. - Such a Chrome generating NACKs in not sending any audio/video stream, so the "sender ssrc: 1" of the RTCP NACK feedback packet seems ok.
,
Sep 11 2017
Adding few labels for tracking purpose.
,
Sep 13 2017
Is there any Demo URL we can use to test and can check for sending NACKs.
,
Sep 15 2017
I don't have any URL that would block some packets artificially so Chrome would generate NACKs, sorry. Let me know if I can help in any other way. I'm just afraid that this is a real bug and M62 lands with it...
,
Sep 15 2017
Thank you for providing more feedback. Adding requester "ajha@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 18 2017
Cc'ing respective dev for further investigation as it is marked as Release block beta. holmer@/xjz@,Could you please take a look and reassign to the respective dev to proceed further. Thanks in advance..!!
,
Sep 18 2017
Thanks. I just want to clarify that we've been parsing NACK and other RTCP messages successfully for so long, and never seen this issue before. In fact, as said above, it just happens in Chrome M62 and M63. There is no too much complexity in parsing RTCP NACK messages. Anyhow here the code we use: https://github.com/versatica/mediasoup/blob/v2/worker/src/RTC/RTCP/FeedbackRtpNack.cpp https://github.com/versatica/mediasoup/blob/v2/worker/include/RTC/RTCP/FeedbackRtpNack.hpp
,
Sep 22 2017
holmer@/xjz@ Friendly ping to get an update on this issue as it is marked as beta blocker. Thanks..!
,
Sep 22 2017
Danil, I think you investigated a similar nack issue before, right? Can you take a look at this and see if it's something you can reproduce?
,
Sep 22 2017
Do you have a raw sample of the rtcp packet? parsed version look like a nack with single block followed by another rtcp message.
,
Sep 26 2017
Sorry for the delay. We'll attach a sample RTCP packet dump ASAP.
,
Sep 27 2017
Hi everyone, Sorry for the delay. This was related to an issue in our server which is already fixed. We were parsing the NACK packet considering the whole UDP size instead of the size indicated by the RTCP header, and thus we were parsing the contiguous REMB (which comes next to the NACK, on the same UDP packet) as NACK items. Please, feel free to close the issue since Chrome is behaving perfectly fine here.
,
Sep 27 2017
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by ranjitkan@chromium.org
, Sep 11 2017