Uploaded image for project: 'FreeSWITCH'
  1. FreeSWITCH
  2. FS-9709

JB drops packets after hole-punching

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.6.13
    • Fix Version/s: None
    • Component/s: freeswitch-core
    • Security Level: public
    • Labels:
      None
    • CPU Architecture:
      x86-64
    • Kernel:
      Linux
    • Userland:
      GNU/Linux
    • Distribution:
      Debian
    • Distribution Version:
      Debian 8 jessie
    • Compiler:
      gcc
    • FreeSWITCH GIT Revision:
      d998325bcaefd01308191dc38a92f36438c9877a
    • GIT Master Revision hash::
      d998325bcaefd01308191dc38a92f36438c9877a

      Description

      Some clients send a few RTP hole-punching packets before media starts coming in, and those hole-punching packets are currently added to the jitter buffer.

      These hole-punching packets are usually mostly randomized, with non-contiguous sequence numbers and an invalid payload type. Under certain circumstances -- specifically when the actual media RTP starts with a sequence number that is lower than the highest hole-punching sequence -- the jitter buffer will drop that first media RTP packet. For H.264 video, especially in bridged mode, this usually means missing on the initial SPS packet, with no indication on the bridged client that anything is missing RTP-wise. Hence the client's decoder can't initialize itself until the next round of extradata comes in.

      The solution, at least for video, seems to be to avoid putting hole-punching packets into the jitter buffer in the first place.

        Attachments

          Activity

            People

            • Assignee:
              mikej Mike Jerris
              Reporter:
              j0sh Josh Allmann
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: