• Julien Isorce's avatar
    rtpmanager: add new rtprtxsend / rtprtxreceive elements · 5a1aa759
    Julien Isorce authored
    The purpose of the sender RTX object is to keep a history
    of RTP packets up to a configurable limit (in time). It will
    listen for custom retransmission events from downstream. When
    it receives a request for retransmission, it will look up the
    requested seqnum in its list of stored packets. If the packet
    is available, it will create a RTX packet according to RFC 4588
    and send this as an auxiliary stream.
    
    The receiver will listen to the custom retransmission events
    from the downstream jitterbuffer and will remember the SSRC1
    of the stream and seqnum that was requested. When it sees a
    packet with one of the stored seqnum, it associates the SSRC2
    of the stream with the SSRC1 of the master stream. From then
    on it knows that SSRC2 is the retransmission stream of SSRC1.
    This algorithm is stated in RFC 4588. For this algorithm to
    work, RFC4588 also states that no two pending retransmission
    requests can exist for the same seqnum and different SSRCs or
    else it would be impossible to associate the retransmission with
    the original requester SSRC.
    When the RTX receiver has associated the retransmission packets,
    it can depayload and forward them to the source pad of the element.
    
    RTX is SSRC-multiplexed
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711084
    5a1aa759