[Bug 738319] rtpsession: fix Early Feedback Transmission

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=738319
  GStreamer | gst-plugins-good | 1.4.1

--- Comment #19 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2015-01-22 21:16:19 UTC ---
(In reply to comment #17)
> @@ +3179,3 @@
>      return;
> 
> +  /* FIXME: RFC 4585 3.5.2 5) Check retained packets if we duplicate one here?
> */
> 
> This one is non-trivial, as we probably want to suppress packets that only
> describe NACKs that have already been sent even if the RTCP packet is not
> identical. For example, if "1 2 5" is received, the first nack would be "3 4",
> but if 4 is later received, a nack with just "3" should probably be suppressed
> even though it's not identical. Or maybe I'm over-thinking this.

Well, it's definitely a solveable problem :) I just wasn't sure if those two
cases were left out on purpose, or were forgotten. I'll look into that then.

(In reply to comment #18)
> What's the use-case for send-rtcp-full ? The way I originally designed it,
> "send-rtcp" was just a polite request to send an early RTCP packet, but with no
> guarantees that one will actually be sent before the next timeout. Actually
> filling the packets is delayed to the "on-sending-rtcp" signal.
> 
> So even if the early rtcp is "refused", the next RTCP packet may be soon enough
> to be useful, so that the early nature may not matter. The code filling the
> rtcp packet would be responsible for deciding if one has happened fast enough,
> or if too much time has passed and a different kind of action is required.

It would be mostly convenience. You would already know that the next RTCP
packet will be too late, and don't need to calculate that yourself from the
time when on-sending-rtcp happens.


What's your understanding of the immediate RTCP situation, what I wrote in
comment 10? I have the feeling I missed something obvious in the RFC that
explains the missing piece :)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.