Summary:	ASTERISK-10067: g726 appears broken between 1.4.x and 1.2.x
Reporter:	Erik Smith (eeman)	Labels:
Date Opened:	2007-08-12 11:50:29	Date Closed:	2011-06-07 14:02:49
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Platform A : asterisk 1.2.24 centos/redhat 4.5 intel motherboard white box assembly Platform B: asterisk 1.4.10.1 centos/redhat 4.5 dell poweredge 2650 when trying to use g726 on an IAX2 channel between a 1.4.10 and 1.2.24 platform B is setup to allow both g726 and ulaw, g726 is preferred. if, on platform A, I disallow=all allow=g726,ulaw ulaw always gets chosen w/ a preference of 'unknown' if I force only g726 disallow=all allow=g726 I get incoming audio call: Aug 12 12:39:19 WARNING[18838]: channel.c:509 ast_best_codec: Don't know any of 0xe800 formats Aug 12 12:39:19 ERROR[18838]: chan_iax2.c:7478 socket_read: No best format in 0xe800??? outgoing audio call: the following shows up on the receiving side (asterisk 1.4.10) [Aug 12 12:59:02] WARNING[18775]: channel.c:718 ast_best_codec: Don't know any of 0xe000 formats [Aug 12 12:59:02] ERROR[18775]: chan_iax2.c:7486 socket_process: No best format in 0xe000??? could this be a result of 1.2.x referring to g726 as 0xe000 and 1.4.x referring to g726 as 0xe800? Would that result in the preferred codec showing up as 'unknown' ?
Comments:	By: Erik Smith (eeman) 2007-08-12 12:05:08 on asterisk 1.2 'show codecs' shows        INT    BINARY        HEX   TYPE    NAME   DESC --------------------------------------------------------------------------------         16 (1 <<  4)     (0x10)  audio    g726   (G.726) while on asterisk 1.4 'show codecs' shows        INT    BINARY        HEX   TYPE       NAME   DESC --------------------------------------------------------------------------------         16 (1 <<  4)     (0x10)  audio   g726aal2   (G.726 AAL2)       2048 (1 << 11)    (0x800)  audio       g726   (G.726 RFC3551) selecting g726aal2 as the codec on the 1.4 platform will result in a codec negotiation but no legible audio By: Erik Smith (eeman) 2007-08-12 12:13:52 the following comment indicates that g726aal2 as the codec on the 1.4 system should resolve the issue. However, it only seems to resolve the codec negotiation.. the actual call fails to produce audio after codec negotiation. * It has been determined that previous versions of Asterisk used the wrong codeword packing order for G726-32 data. This version supports both available packing orders, and can transcode between them. It also now selects the proper order when negotiating with a SIP peer based on the codec name supplied in the SDP. However, there are existing devices that improperly request one order and then use another; Sipura and Grandstream ATAs are known to do this, and there may be others. To be able to continue to use these devices with this version of Asterisk and the G726-32 codec, a configuration parameter called 'g726nonstandard' has been added to sip.conf, so that Asterisk can use the packing order expected by the device (even though it requested a different order). In addition, the internal format number for G726-32 has been changed, and the old number is now assigned to AAL2-G726-32. The result of this is that this version of Asterisk will be able to interoperate over IAX2 with older versions of Asterisk, as long as this version is told to allow 'g726aal2' instead of 'g726' as the codec for the call. By: Joshua C. Colp (jcolp) 2007-08-13 08:10:29 This is a configuration issue. You must also set the g726nonstandard to yes in sip.conf. If after this it still does not work feel free to reopen. By: Erik Smith (eeman) 2007-08-19 01:55:02 I am not using SIP at all in this circumstance. Call comes in PRI, creates an IAX2 connection to the other box and plays back a recording for their auto-attendant. When trying to use g726 between 1.2 and 1.4 the best I can achieve is a no-audio file. By: Jason Parker (jparker) 2007-08-20 17:40:47 Can you show us a log of what happens when on 1.4 you use allow=g726aal2 ? By: Joshua C. Colp (jcolp) 2007-08-22 11:33:23 On the system running 1.4 put: allow=g726aal2 On the system running 1.2 put: allow=g726 This should allow it to work fine (I just tested it). By: Erik Smith (eeman) 2007-08-22 11:39:37 it doesn't error but it fails to pass audio, i just hear some faint blips when playing back a sound file. I mentioned this in the first note of this bug thread. if  1.4 side sets g726 and 1.2 side sets g726 i get a negotiation error if 1.4 side sets g726aal2 and 1.2 side sets g726 i get no error but the audio stream is illegible if i set 1.4 side to ulaw and 1.2 side to ulaw the same audio file plays back fine By: Joshua C. Colp (jcolp) 2007-08-22 11:45:05 I need complete console output then on both boxes with iax2 debug enabled. I just tested it configured as I described and was able to do both directions fine. There has to be a configuration difference between both of our setups. By: Joshua C. Colp (jcolp) 2007-09-11 09:22:50 I'm suspending this since there has been no response and I assume you were able to find the mistake. If not reopen with the needed information.