[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 14:37 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.

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

---------------------------------------------------------------------- 
 (0100848) DEA (reporter) - 2009-02-26 14:37
 http://bugs.digium.com/view.php?id=14021#c100848 
---------------------------------------------------------------------- 
I saw the post on the -dev list about the multiframe queuing and wondered
if
it would alter the situation.

I understand the two bridged channel scenario, but would this also
explain
the same behaviour when a channel is 'bridged' to an app, such as meetme?

I have continued to think about the options, and I suspect the the RTP
session would need a dedicated write thread, but only if the channels
differ in their framing/packetization/timing requirements.

If such a thread was used, then ast_write could continue to feed frames
into the smoother and the thread would 'consume' the frames based on the
required timing.  Where I get lost is how we would schedule the thread,
usleep is to ugly to consider (yes?), and a callback implimentation is
beyond my skills. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-26 14:37 DEA            Note Added: 0100848                          
======================================================================