asterisk users - Aug 2017 - RTP Timestamp rewind

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20170829/4eef3c58/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nofgcbcgfipggiec.png
Type: image/png
Size: 8550 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20170829/4eef3c58/attachment.png>

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20170830/bb681c2b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nofgcbcgfipggiec.png
Type: image/png
Size: 8550 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20170830/bb681c2b/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nofgcbcgfipggiec.png
Type: image/png
Size: 8550 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20170830/bb681c2b/attachment-0001.png>

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20170830/3023c696/attachment.html>