On 8/30/2017 5:03 AM, Steve Davies wrote: > 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. Thanks Steve,
I did omit the Mark indication in the screenshot. > > 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. 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. > No packets should be dropped though in my experience some jitter > buffers can handle it poorly. > > Hope that helps, > Steve > Thanks for your response.
-- _____________________________________________________________________ -- 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
