[jitsi-dev] [libjitsi] Rewrite simulcast timestamps via wallclocks (#91)


#1

Upon rewriting RTP packets for the purposes of SSRC rewriting, rewrites their RTP timestamps as well in order to produce an output RTP stream with monotonically increasing timestamps with a single timestamp base. The rewriting utilizes information about the remote wallcocks of the respective SSRCs (i.e. RTP streams).
You can view, comment on, or merge this pull request online at:

  https://github.com/jitsi/libjitsi/pull/91

-- Commit Summary --

  * Fixes javadocs.
  * Fixes a warning.
  * Splits a method into two for the purposes of readability.
  * Simplifies, clarifies source code.
  * Renames classes, methods, fields related to remote wallclock estimation in the hope of achieving clarification.
  * Reduces autoboxing. Uses standard Java naming.
  * Moves RemoteClockEstimator out of BasicRTCPTerminationStrategy in order to make it available elsewhere.
  * Uses long synchronization source identifier (SSRC) values when in need of expressing invalid values as well.
  * Exposes RTPTranslator through MediaStream.
  * Exposes finding MediaStream by receive SSRC through RTPTranslator.
  * Makes RemoteClockEstimator MediaType-aware in order to default to 90kHZ for video clock frequency/rate.
  * Rewrites RTP timestamps in simulcast based on remote (wall)clocks.

-- File Changes --

    M pom.xml (2)
    M src/org/jitsi/impl/neomedia/MediaStreamImpl.java (15)
    M src/org/jitsi/impl/neomedia/MediaStreamStatsImpl.java (87)
    M src/org/jitsi/impl/neomedia/RawPacket.java (2)
    A src/org/jitsi/impl/neomedia/rtcp/RemoteClock.java (349)
    A src/org/jitsi/impl/neomedia/rtcp/RemoteClockEstimator.java (218)
    A src/org/jitsi/impl/neomedia/rtcp/Timestamp.java (86)
    M src/org/jitsi/impl/neomedia/rtcp/termination/strategies/BasicRTCPTerminationStrategy.java (42)
    M src/org/jitsi/impl/neomedia/rtcp/termination/strategies/MediaStreamRTCPTerminationStrategy.java (32)
    D src/org/jitsi/impl/neomedia/rtcp/termination/strategies/ReceivedRemoteClock.java (102)
    D src/org/jitsi/impl/neomedia/rtcp/termination/strategies/RemoteClock.java (66)
    D src/org/jitsi/impl/neomedia/rtcp/termination/strategies/RemoteClockEstimator.java (129)
    M src/org/jitsi/impl/neomedia/rtp/translator/RTPTranslatorImpl.java (17)
    M src/org/jitsi/impl/neomedia/transform/rewriting/ExtendedSequenceNumberInterval.java (83)
    M src/org/jitsi/impl/neomedia/transform/rewriting/SsrcGroupRewriter.java (197)
    M src/org/jitsi/impl/neomedia/transform/rewriting/SsrcRewriter.java (241)
    M src/org/jitsi/impl/neomedia/transform/rewriting/SsrcRewritingEngine.java (89)
    M src/org/jitsi/service/neomedia/MediaStream.java (9)
    M src/org/jitsi/service/neomedia/RTPTranslator.java (10)

-- Patch Links --

https://github.com/jitsi/libjitsi/pull/91.patch
https://github.com/jitsi/libjitsi/pull/91.diff

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/pull/91


#2

I'm testing this and in my (brilliant) setup (that reorders UDP packets..) a lot of packets are being dropped at the receiver as replay attacks.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/pull/91#issuecomment-190441445


#3

Note that I have no idea where the problem is coming from, but I'm suspecting that the problem has always been there (before this PR). Maybe this PR just amplified it so that it became visible.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/pull/91#issuecomment-190447818


#4

I and @gpolitis looked into the SRTP replay attacks and couldn't tie them to the RTP timestamp rewriting.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/pull/91#issuecomment-190812983


#5

Merged #91.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/pull/91#event-578219671