[asterisk-bugs] [Asterisk 0011491]: RTP timestamp skewed after return from hold.

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11491 
====================================================================== 
Reported By:                kanderson
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11491
Category:                   Core/RTP
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.15  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             12-07-2007 12:08 CST
Last Modified:              03-04-2008 11:56 CST
====================================================================== 
Summary:                    RTP timestamp skewed after return from hold.
Description: 
This is the response from Level 3 on a one way audio issue I have.  For
your reference I am including one of the captures.  'Bandwidth_1way' was
preformed by Level 3 and 'filtered_joint_capture' was done on our box. 
Both are for the same call but started at different times.  I have many
other examples spanning several weeks and will upload on request.  If you
use wireshark to look at the RTP jitter you will see the timestamp gaps
cause large jitter numbers (sometimes as high as 30382910.59ms on other
captures).

I believe the timestamps may be slipping when a call is placed on hold. 
This behavior has been noted in several of our calls that worked as well as
the ones that fail.  Furthermore, looking at the example skew we can see
the timestamps increment by 41,120 while the wireshark capture time only
increments by .123238.

As this is what I originally expected I have already tested it without NTP
running and ensured the time is synchronized with Level 3, but I was still
able to recreate the problem.

It may be worth mentioning this is on a Dell, which I have been told has a
crummy RTC.  I dont know if that is true but it appears to have manifested
itself if so.  

I have also noted two other recent tickets that deal with RTP timestamps,
0011429 and 0010355.  I am mentioning these because perhaps returning from
hold uses the wrong clock or is related to the issue with incorrect
timestamps after 200 ok (which I have also noticed).

Bellow is the email from Level 3:

This definitely appears to be an rtp issue based on the capture that
Marty performed. I have attached the capture that was taken in front of
our media gateway.
Based on the rtp stream, here is what I have found. If you look at the
packets from the customer up until packet number 7357, they are
correctly incrementing each packet sequence by 1 and each timestamp by
160.
Packet no. 7357 shows sequence no. 22225 and timestamp 2678222704.
Packet no. 7365 shows sequence no. 22226 and timestamp 2678263824.

This is the next packet in the sequence so the timestamp would increment
by 160 (at the most the timestamp would increment by 640(, however, the
timestamp that we receive for the next packet in sequence has
incremented by 41,120. You can see that in ethereal that this is
interpreted as a huge amount of jittter. Because our gateway is
receiving the next sequence number it also expects the timestamp to have
incremented by 160, the huge time delta causes the issue and the gateway
stops playing the audio. Certainly not an ideal behavior on our part,
however, the sequence number and timestamp should be tied together (rfc
3550 is the spec but the actual relationship between sequence and time
is relatively vague so this is how Lucent implemented).

Unfortunately there isn't much we can do on the gateway since it's a dsp
to jitter buffer relationship and would require a software patch. Is
there a way that the customer can send us re-invite for on-hold portion?
Of they could send a new SSRCID once the call comes off of hold which
the gateway would interpret as a new stream and should play out the
audio with no issues.....just a few tought. Let me know if you have any
questions.
====================================================================== 

---------------------------------------------------------------------- 
 jcomellas - 03-04-08 11:56  
---------------------------------------------------------------------- 
We have been experiencing the same problem with Asterisk 1.4.18 and Level
3. The suggestion from Level 3 to resolve the problem was:

1) Send us a new SSRC and we will treat this as a new RTP stream and there
will be no audio loss.

2) Send the time in the expected next increment 160.  Packet 11623
Time=59200 and then packet 11632 Time=2568454632.  Packet 11632 should be
59360. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-04-08 11:56  jcomellas      Note Added: 0083330                          
======================================================================