Summary:ASTERISK-08102: Quality issues with codec g726
Reporter:Loic Didelot (voipgate)Labels:
Date Opened:2006-11-10 02:57:18.000-0600Date Closed:2006-11-21 11:34:55.000-0600
Versions:Frequency of
Environment:Attachments:( 0) g726test.diff
( 1) sipdebbug1
( 2) sipdebbug2
Description:We recently noticed quality issues when using the g726 codec. So we tried to investigate a bit. Call is always connected fine and asterisk does not report any errors. But, depending which version of asterisk we use there are huge quality differences.

Here are our first results which have been verified quite alot:
G726 on asterisk 1.0.10: Quality is OK
G726 on asterisk 1.2.13: Quality is really bad
G726 on asterisk 1.2.trunk: Quality is OK
G726 on asterisk 1.4.trunk: Quality is really bad
G726 on asterisk 1.4.beta3: Quality is really bad


We did a basic test. A sip client using 9726 connects to an asterisk which uses the PlayBack application to play a GSM file.

But we tested also other type of calls and the issue exists only with g726.

There was no load on the server when testing.  Client and server hardware were on all tests the same.
Comments:By: Loic Didelot (voipgate) 2006-11-10 03:37:44.000-0600

Ok, now I got very evil. I compile 1.2.trunk (as g726 is ok there) then I copied the codec_g726.so file to my current asterisk 1.2.13 installation (/usr/lib/asterisk/modules).  Now, the quality is fine on my 1.2.13 version as well, where it was not ok before.

By: timrobbins (timrobbins) 2006-11-12 00:31:40.000-0600

Have you tried setting g726nonstandard = yes in sip.conf ?

By: Loic Didelot (voipgate) 2006-11-13 00:44:02.000-0600

How would this make sense? This would mean that the default behaviour changes from version to version? Well I did the test and added "g726nonstandard = yes" to my sip.conf but then g726 stops working => SIP Status: 488 Not acceptable here

By: Joshua C. Colp (jcolp) 2006-11-13 10:54:11.000-0600

The problem came up a few months ago that we were actually doing G726 encoding wrong, as were other devices such as the Sipuras and Grandstreams. Thus why we now have two encodings in Asterisk, RFC3551 and AAL2. What is probably happening is that it is using the wrong encoding, so it sounds awful. Setting g726nonstandard=yes should have fixed this - so since it didn't, please post a sip debug so we can see the codec negotiation. Thanks.

By: Loic Didelot (voipgate) 2006-11-14 06:40:46.000-0600

Ok,I checked out the latest SVN for asterisk 1.4 (revision: 47599). As client I user phonerlite (www.phoner.de). Check the attachment sipdebug1.

By: Joshua C. Colp (jcolp) 2006-11-14 10:40:44.000-0600

Ah! Give allow=g726aal2 a go.

By: Loic Didelot (voipgate) 2006-11-14 10:54:44.000-0600

Ok, looks like the codec is negotiated correctly now, But I have no audio. The client seems to no know the codec. Because normally it displays the codec per call which is not the case now. I attached sipdebug2.

By: Joshua C. Colp (jcolp) 2006-11-20 21:13:56.000-0600

Your softphone might be doing a negotiation based on name instead of payload, in which case it might not like that the name is different then it would expect. Try the attached patch and tell me if it works.

By: Loic Didelot (voipgate) 2006-11-21 11:15:41.000-0600

Patch works perfectly

By: Joshua C. Colp (jcolp) 2006-11-21 11:34:55.000-0600

Fixed in 1.4 as of revision 47897 and trunk as of revision 47898. Thanks!