Sure, so I was analyzing a pcap file and I noticed re-order frames which the bridge mis-handles and causes it to break the RTP stream.
Say you send frames A B C and each is comprised of 3 RTP packets (3 is not important, it can be N). So the sender emits A1, A2, A3, B1, B2, B3, C1, C2, C3. If the bridge receives something like this A1, A2, A3, C1, B1, B2, B3, C2, C3 it will break the RTP stream because it will uplift the B frame to Timestamp_C+1.
tl;dr; the RTP uplifting logic can cope with some packet re-ordering, but it doesn’t expect whole frames to be re-ordered. I’ve confirmed that it can cause long freezes; I’m not sure about scrambling but I find it much less likely.
You can view, comment on, or merge this pull request online at:
-- Commit Summary --
* refactor: Limits the RTP timestamp history to 20 entries.
* refactor: Checks for timestamp freshness before using it.
* refactor: Takes care of frame re-ordering.
-- File Changes --
M src/org/jitsi/impl/neomedia/transform/rewriting/SsrcRewriter.java (83)
-- Patch Links --
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: