[Bug 769771] rtpbuffer: Add buffer flag RETRANSMISSION

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=769771

--- Comment #10 from Håvard Graff (hgr) <havard.graff at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #9)
> The problem here was two:
> - you don't know, in general, if something is a retransmission or not. There
> are cases where retransmissions are sent with the same SSRC, etc. The
> Kurento guys always told me that this is how a) they implement it and b)
> Firefox does it. As such, this flag would only be an indication but not
> always correct

You will always know if the packet used to be a RFC 4588 packet. That RFC even
specifies why it is a terrible idea to re-send the same packet: (from
https://tools.ietf.org/html/rfc4588#section-3)

  "One approach may be to retransmit the RTP packet with its original
   sequence number and send original and retransmission packets in the
   same RTP stream.  The retransmission packet would then be identical
   to the original RTP packet, i.e., the same header (and thus same
   sequence number) and the same payload.  However, such an approach is
   not acceptable because it would corrupt the RTCP statistics.  As a
   consequence, requirement 1 would not be met.  Correct RTCP statistics
   require that for every RTP packet within the RTP stream, the sequence
   number be increased by one."


> - are retransmissions really to be considered not part of the RTT? Arguably
> they are just like reordered packets. The packet just took that long to
> arrive, for whatever reason
> 
Easy example: You have just fired of a RTX request for a packet, but the
original packet arrives 1 nanosecond later. According to the previous
jitterbuffer calculation, with no way of telling the original apart from the
retransmitted, your RTT is now 1 nanosecond...

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.