Summary:	ASTERISK-08102: Quality issues with codec g726
Reporter:	Loic Didelot (voipgate)	Labels:
Date Opened:	2006-11-10 02:57:18.000-0600	Date Closed:	2006-11-21 11:34:55.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/CodecInterface
Versions:		Frequency of Occurrence
Related Issues:
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 ****** ADDITIONAL INFORMATION ****** 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!