RTCP Receiver Report RFC 3550 compliance

[Stepan Salenikovich]

Hi,

I noticed in the WebRTC code, in the sending and receiving of RTCP receiver reports (module/rtp_rtcp/source/rtcp_packet/report_block.cc) the "cumulative number of packets lost" is interpreted as an unsigned integer. However, in RFC 3550 it is defined as 24 bit signed integer (see https://tools.ietf.org/html/rfc3550#appendix-A.3 for details) since the loss can be negative if there are duplicates.

From what I can tell, this means that if other RTCP RR implementations send a negative packet loss, WebRTC could interpret this as a very high loss.

Or am I missing something?

-stepan

[Harald Alvestrand]

This was actually recently noted and fixed in the WebRTC stats spec.

Can you file a bug on the base code?

(I think it's unlikely that this would happen in practice, but if someone can think of how to generate a test case, that would be nice.)

--

---
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-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7b8074dd-0b4c-47cb-8ea1-9af0253c1ec2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stepan Salenikovich]

I filed the bug here:
https://bugs.chromium.org/p/webrtc/issues/detail?id=8626

Not sure if it would help in writing a test case, but I wrote in the bug report the only scenario in which I can think of this happening:

An SFU which doesn't handle retransmission itself (instead it relays NACKs between peers). Some peers may experience packet loss without the SFU experiencing packet loss and send NACKs. This would result in re-transmissions and the SFU would get duplicate packets resulting in it receiving more packets than it expects and calculating a negative packet loss.

On Thursday, December 7, 2017 at 4:32:50 AM UTC-5, Harald Alvestrand wrote:

This was actually recently noted and fixed in the WebRTC stats spec.

Can you file a bug on the base code?

(I think it's unlikely that this would happen in practice, but if someone can think of how to generate a test case, that would be nice.)

On Thu, Dec 7, 2017 at 1:08 AM, Stepan Salenikovich <stepan.sa...@jive.com> wrote:

Hi,

I noticed in the WebRTC code, in the sending and receiving of RTCP receiver reports (module/rtp_rtcp/source/rtcp_packet/report_block.cc) the "cumulative number of packets lost" is interpreted as an unsigned integer. However, in RFC 3550 it is defined as 24 bit signed integer (see https://tools.ietf.org/html/rfc3550#appendix-A.3 for details) since the loss can be negative if there are duplicates.

From what I can tell, this means that if other RTCP RR implementations send a negative packet loss, WebRTC could interpret this as a very high loss.

Or am I missing something?

-stepan

--

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