REMB ignored if not sent in a compound packet?

[Lorenzo Miniero]

Hi,

playing with the REMB support in our WebRTC server I've noticed that apparently Chrome ignores REMB packets that are not sent as part of a compound packet, in particular with a SR/RR+SDES. Specifically, for sendrecv sessions Chrome expects them with a SR+SDES, while for sendonly sessions (Chrome sending to the browser) it only works when they're sent together with a RR+SDES. Coupling them with a SDES only didn't work.

Is this by design or is it a bug? I actually expected an isolated REMB to work, but I verified in a reproduceable way that such packets were indeed completely ignored by Chrome.

Thanks,

Lorenzo

[Magnus Flodman]

Hi Lorenzo,

I'd expect this to work, so please file a bug with with the details you've observed.

Thanks for reporting,

-Magnus

[Sergio Garcia Murillo]

Check this:

https://tools.ietf.org/html/rfc5506

This document defines the "a=rtcp-rsize" Session Description Protocol (SDP) [RFC4566] attribute to indicate if the session participant is capable of supporting Reduced-Size RTCP for applications that use SDP for configuration of RTP sessions. It is REQUIRED that a participant that proposes the use of Reduced-Size RTCP shall itself support the reception of Reduced-Size RTCP. An offering client that wishes to use Reduced-Size RTCP MUST include the attribute "a=rtcp-rsize" in the SDP offer. If "a=rtcp-rsize" is present in the offer SDP, the answerer that supports Reduced-Size RTCP and wishes to use it SHALL include the "a=rtcp-rsize" attribute in the answer.

So imho, it is not a bug, but support of reduced size rtcp packets should be nice.

Best regards
Sergio

--

---
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/d/optout.

[Lorenzo Miniero]

Sergio,

good point, I was not aware of this. Anyway, it's weird that Chrome accepts FIR or PLI feedback out of the context of a compound packet, while it doesn't for REMB, which is what got me puzzled.

Asking Chrome developers, how should I proceed then?

Thanks

Lorenzo

[Sergio Garcia Murillo]

That's indeed a (nice) bug, according to RFC 4585:

   The FB message(s) MUST be placed in the compound packet after RR and
   SDES RTCP packets defined in [1].  The ordering with respect to other
   RTCP extensions is not defined.

   Two types of compound RTCP packets carrying feedback packets are used
   in this document:

   a) Minimal compound RTCP feedback packet

      A minimal compound RTCP feedback packet MUST contain only the
      mandatory information as listed above: encryption prefix if
      necessary, exactly one RR or SR, exactly one SDES with only the
      CNAME item present, and the FB message(s).  This is to minimize
      the size of the RTCP packet transmitted to convey feedback and
      thus to maximize the frequency at which feedback can be provided
      while still adhering to the RTCP bandwidth limitations.

      This packet format SHOULD be used whenever an RTCP FB message is
      sent as part of an Early RTCP packet.  This packet type is
      referred to as minimal compound RTCP packet in this document.

   b) (Full) compound RTCP feedback packet

      A (full) compound RTCP feedback packet MAY contain any additional
      number of RTCP packets (additional RRs, further SDES items, etc.).
      The above ordering rules MUST be adhered to.

      This packet format MUST be used whenever an RTCP FB message is
      sent as part of a Regular RTCP packet or in Regular RTCP mode.  It
      MAY also be used to send RTCP FB messages in Immediate Feedback or
      Early RTCP mode.  This packet type is referred to as full compound
      RTCP packet in this document.

   RTCP packets that do not contain FB messages are referred to as non-
   FB RTCP packets.  Such packets MUST follow the format rules in [1].


Best regards
Sergio

[Lorenzo Miniero]

Ok so now we risk having to send compounds for those as well in future versions!! :-D
Thanks for the clarifications, I should have studied the related RFCs in more detail before asking... just as an interesting fact, I also tried to send a compound RR+SDES+REMB where the RR had no blocks (rc=0) and the REMB was ignored as well, so there may be indeed another bug there :-)

Lorenzo

[Oscar Divorra Escoda]

Lorenzo,

    What version of Chrome presents this behavior to you?

    Thx.

          Òscar

[Stefan Holmer]

As Magnus said, it would be great if you could file a bug on this with repro instructions. Sounds to me like something might be broken.

[Sergio Garcia Murillo]

Indeed you should.. ;)

As you now, my MCU is mixer based so as I have to end all the media streams that is not a problem for me, but from my understanding, it should also not be a problem for an SFU/rtp switch (and maybe something to add to our joint rtcp in b2bua draft).

From my point of view, it should not only be possible but dessirable that the SFU/switch "termintes" the rtp stream and report back the rtcp SR/RR with the statistics between the endpoint and the server.

Best regards
Sergio

[Lorenzo Miniero]

I think it started happening with version 39, I'm now on 41.0.2224.3 and it definitely happens there.

As Stefan and Magnus suggested, I'll open an issue with info on how to replicate this. Since I experienced it with my gateway I think I'll place a demo somewhere with the different behaviours. Just allow me some time to prepare this.

Lorenzo