[asterisk-bugs] [Asterisk 0014021]: RTP playout does not match ptime

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14021 
====================================================================== 
Reported By:                Skavin
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14021
Category:                   Core/RTP
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.21.2 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-12-04 16:02 CST
Last Modified:              2008-12-07 01:31 CST
====================================================================== 
Summary:                    RTP playout does not match ptime
Description: 
when a sip client invites with a alaw and ptime of 30. Asterisk sends RTP
at intervals of 20 and 40 ms as captured by tcpdump on the asterisk
server.
this is causing 20ms jitter on these connections.

====================================================================== 

---------------------------------------------------------------------- 
 (0095935) DEA (reporter) - 2008-12-07 01:31
 http://bugs.digium.com/view.php?id=14021#c95935 
---------------------------------------------------------------------- 
I think I figured out what is happening and can offer up a few suggestions
to fix it.  It will be mid-week before I can work on a patch, so I am
hoping
a core developer can validate my ideas.

Scenario-
    Client A uses 20ms packetization/framing
    Client B uses 30ms packetization/framing
    Clock/RTP starts at zero to simplify the explination

TS = 0   Client A sends a 20ms packet to Asterisk
         Client B's write callback is triggered, and the smoother 
         attepts to build a packet, but the smoother does not 
         contain enough audio, so it returns a null
TS = 20  Client A sends anouther 20ms packet
         Client B's write callback is triggered and finds 40ms of
         audio in the smoother and sends a properly framed 30ms packet
TS = 40  Client A sends anouther 20ms packet
         Client B's write callback is triggered and finds 30ms of
         audio in the smoother, 10ms left over from the 2nd packet
         from client A's send packet and 20ms from the 3rd packet
         and sends a properly framed 30ms packet.  The smoother is now
         empty and the process starts over

Why it happens-
         The internal_timing and packetization features were developed
         at roughly the same time, and there were some interdepenencies.
         One change that appears to have been lost was setting the 
         timeout for the channels Zap/Dahdi timer to the packetization
         interval.

Possible solutions-
         1.  Just change the call timing/generator timer to 80 samples
             or 10ms.  The timer will fire twice as often, but will 
             allow for accurate RTP timing.
             Pros-
                  1 or 2 lines of code
             Cons-
                  Increased system load for the extra timer activity
                  May not work well with 33ms iLBC

          2.  Pass appropriate information to the generator setup
              function to set the timer to fire at the packetization
              interval.
              Pros-
                  Lower system load
                  Should work with any packetization
              Cons-
                  More code, more complex

One other issue that concerns me is smoother sizing.  I need to 
re-read the code a few more times to be sure of this, but I suspect
that we may not be setting a large enough buffer.  Imagine the crazy
situation where one client has a 20ms packetization requirement and
is bridged to a client using 240ms.  While 240ms packetizaion is
likely insane, it is legal for some codecs.  The channel servicing
the 20ms client would need a buffer 13~15 times larger than it's
packetization interval to hold the audio and to have a chance to buffer
the second packet.  When coding the smoother, should we focus on the
realistic, or the legal possible requirements?

I suspect this issue is related to a number of recent bug reports that
involve meetme and playback, where the client devices are not using
20ms of audio.  The issue also effects 1.4 and 1.6

putnopvut, I hope this helps explain the issue.  I maybe able to put
some time towards this on Tuesday or Wednesday, but I'd like some
guidence about which solution option would be prefered.

frame, and nothing happens 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-12-07 01:31 DEA            Note Added: 0095935                          
======================================================================