[asterisk-bugs] [Asterisk 0012130]: Transcoded G.722 calls unintelligible
noreply at bugs.digium.com
noreply at bugs.digium.com
Tue Mar 4 22:23:42 CST 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=12130
======================================================================
Reported By: rickross
Assigned To: russell
======================================================================
Project: Asterisk
Issue ID: 12130
Category: Codecs/codec_g722
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Asterisk Version: 1.6.0-beta4
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 03-03-2008 20:53 CST
Last Modified: 03-04-2008 22:23 CST
======================================================================
Summary: Transcoded G.722 calls unintelligible
Description:
Ever since moving from 1.4.13 to 1.6.0b4 my users have been unable to use
G.722 successfully. The transcoding seems fine from other formats like
ulaw/gsm into G.722, but the other direction is almost completely garbled
and makes it sound like the speaker is under water. It is barely
intelligible (with some good guesswork.)
I'd be happy to give someone a call to demonstrate, if that would help.
For now we're simply disabling G.722 completely (a pity, since it sounds so
good when it works.) We had been using a backported G.722 under 1.4.x for
many months, so we know it can work. SOmething seems to have changed in the
1.6 beta.
======================================================================
----------------------------------------------------------------------
snuffy - 03-04-08 22:23
----------------------------------------------------------------------
milazzo, russell applied the fix to trunk/1.4
Please retest with svn of 1.6
*** russell, asterisk, branch-1.4, r105932 ***
Fix a bug that I just noticed in the RTP code. The calculation for
setting the len field in an ast_frame of audio was wrong when G.722 is in
use. The len field represents the number of ms of audio that the frame
contains. It would have set the value to be twice what it should be.
*** russell, asterisk, trunk, r105933 ***
Issue History
Date Modified Username Field Change
======================================================================
03-04-08 22:23 snuffy Note Added: 0083398
======================================================================
More information about the asterisk-bugs
mailing list