[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:                kpfleming
====================================================================== 
Project:                    Asterisk
Issue ID:                   14021
Category:                   Core/RTP
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.21.2 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2008-12-04 16:02 CST
Last Modified:              2009-02-26 11:48 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.

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

---------------------------------------------------------------------- 
 (0100813) kpfleming (administrator) - 2009-02-26 11:48
 http://bugs.digium.com/view.php?id=14021#c100813 
---------------------------------------------------------------------- 
Josh just brought this issue to my attention, as this is an area that I've
been working in the last few days.

DEA's analysis is mostly correct, at least as far as why the outgoing
packet stream looks the way that it does. However, his conclusion that this
is related the timingfd on the channel is unfortunately not valid; when two
channels are bridged, there is no timingfd involved, nor is
'internal_timing' involved. In a channel bridge, outgoing packet timing is
based entirely on incoming packet timing.

This is certainly something that should and will be addressed, but it's
not a trivial change. It will require that *all* outbound RTP streams use a
timing source for generation of packets, because we cannot rely on the
inbound packet stream to provide timing (or even consistently sized input
packets). This is also necessary to do proper jitter buffering, since the
jitter buffer may have stored up frames to be delivered at a later time,
and there needs to be some trigger for when that time has arrived.

I'll give this some more thought and post some notes here, but it is
unlikely that this will be addressed in Asterisk 1.4 at all, as the
invasiveness of the changes would be likely to destabilize things too
much.

(I do find it unfortunate that jitter buffers in these products can't
handle 20ms of jitter; it makes those jitter buffers nearly useless) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-26 11:48 kpfleming      Note Added: 0100813                          
======================================================================