|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|
|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!