[Asterisk-bugs] [Asterisk 0010229]: Sound problems when bridging sip channels with packetization level different than 20ms

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10229 
====================================================================== 
Reported By:                gspiliot
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10229
Category:                   Addons/chan_mobile
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:            1.4.6 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        No 
Request Review:              
====================================================================== 
Date Submitted:             07-18-2007 11:02 CDT
Last Modified:              07-18-2007 23:25 CDT
====================================================================== 
Summary:                    Sound problems when bridging sip channels with
packetization level different than 20ms
Description: 
When bridging chan_mobile with another sip channel which, for example,
receives packets with 90ms size instead of the default 20ms then the sound
coming out chan_mobile is choppy. It seems that repacketization or the rtp
stream is needed if chan_mobile works with fixed 20ms packets.
====================================================================== 

---------------------------------------------------------------------- 
 russell - 07-18-07 23:25  
---------------------------------------------------------------------- 
When you say "sound coming out of chan_mobile", do you mean that the audio
that came in over RTP and is being sent over chan_mobile sounds bad?  or
that the audio from chan_mobile going out over RTP sounds bad?

(This is a note for other developers looking at the issue)  bbryant was
looking at this issue and assuming that it is the first scenario, I
suggested that one way to approach this would be to use an ast_smoother in
the write callback of chan_mobile.  You could put all frames through that
to ensure that you are then always receiving 20ms frames for sending out in
chan_mobile.  We do this same thing for handling frames that are going to
be sent out over RTP already to ensure that we get frames into the right
size (20ms or 30ms default size, or whatever is configured via
packetization settings). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-18-07 23:25  russell        Note Added: 0067565                          
======================================================================