2 thoughts on - RTP Timestamp Rewind

• –001a113d2106faffd00557f4cceb Content-Type: text/plain; charset=”UTF-8″

  Mark,

  You have cropped the image you inserted above and removed a very important part of the line you highlighted. I think is says “,Mark” after the time value – You can even see the un-cropped comma in your picture.

  RTP timestamps can be reset mid-stream if needed – It is part of the spec, and most commonly happens when initially (eg Asterisk) generated audio is replaced with audio from an external source once the call is bridged. The early timestamp comes from Asterisk, and the subsequent timestamp is retained from the new source of the RTP.

  No packets should be dropped though in my experience some jitter buffers can handle it poorly.

  Hope that helps, Steve

  –001a113d2106faffd00557f4cceb Content-Type: text/html; charset=”UTF-8″
  Content-Transfer-Encoding: quoted-printable

  Mark,

  You have cropped the image you inserted above and removed a very important part of the line you highlighted. I think is says ",Mark" after the time value – You can even see the un-cropped comma in your picture.

  RTP timestamps can be reset mid-stream if needed – It is part of the spec, and most commonly happens when initially (eg Asterisk) generated audio is replaced with audio from an external source once the call is bridged. The early timestamp comes from Asterisk, and the subsequent timestamp is retained from the new source of the RTP.

  No packets should be dropped though in my experience some jitter buffers can handle it poorly.

  Hope that helps,

  Steve

  On Tue, 29 Aug 2017 at 19:39 Mark Wiater <mark.wiater@greybeam.com> wrote:

  Hi folks.

  I have a couple of questions regarding RTP.

  The background of my inquiry is that I have packet captures of SIP
  and RTP traffic on an Asterisk and Broadworks SIP trunk and the RTP
  many times has a time stamp that rewinds by 480 using g.711u. The
  Sequence number continues to increment appropriately, but the
  timestamp just rewinds.

  

  It doesn't happen on every call, but it's frequent enough to make me
  want to understand it better.

  My questions are:

  Is there ever a circumstance where it would be normal or logical to
  see the RTP timestamp go backwards during the RTP stream? 
  Consistently by 480, 3 voice frames?

  Will Asterisk just drop the packets that compromise the rewind?

  Thanks

  Mark

  —
  _____________________________________________________________________
  — Bandwidth and Colocation Provided by http://www.api-digital.com —

  Check out the new Asterisk community forum at: https://community.asterisk.org/

  New to Asterisk? Start here:
        https://wiki.asterisk.org/wiki/display/AST/Getting+Started

  asterisk-users mailing list
  To UNSUBSCRIBE or update options visit:
     http://lists.digium.com/mailman/listinfo/asterisk-users

  –001a113d2106faffd00557f4cceb

• Thanks Steve,

  I did omit the Mark indication in the screenshot. Thanks! That helps.

  I had read the portion of rfc3550 that said

  The sampling instant MUST be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations

  So that led me to believe that the timestamps should increment at predictable intervals. Wireshark flagged it in the RTP stream analysis as being an Incorrect Timestamp too. Thanks for your response.