[asterisk-users] Why not g726-32?

[Steve Langstaff]

> -----Original Message-----
> From: asterisk-users-bounces at lists.digium.com 
> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of 
> Rich Adamson
> Sent: 17 September 2006 17:45
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [asterisk-users] Why not g726-32?
> 
> RR wrote:
> > On 9/16/06, Rich Adamson <radamson at routers.com> wrote:
> >> RR wrote:
> >> > All,
> >> >
> >> > is there anyone who uses g726-32 ? If not, then does anyone know 
> >> > why don't people use it?
> >>
> >> I use g726 on iax links between systems and to teliax.com 
> for LD calls.
> >> Have no idea if its -32 or what though. What ships with 
> asterisk (in 
> >> terms of g726) has been working very well for us with the 
> exception 
> >> of a period of time where all g726 calls via teliax were 
> not usable. 
> >> Teliax had to have had a problem or was playing around as that was 
> >> the only iax link that had bad audio.
> > 
> > Thanks Rich for the positive email about g726. Just FYI, 
> (*) supports 
> > only g726-32 AFAIK so that's probably what you've been 
> using. I don't 
> > have the worry of Teliax as I'd probably never be using them or at 
> > least not in the immediate/near future. Like I said, all I 
> want to do 
> > is avoid usage of license fees, save bandwidth, and not 
> stress out my 
> > systems with cpu intensive codecs like g729 and maybe find 
> something 
> > that can still deliver comparable quality.
> > 
> > I'm still confused as to why more people and carriers don't 
> use g726 
> > however.
> 
> I can only guess that many itsp's actually support it, but 
> don't advertise its availability, just like they don't 
> advertise ilbc, etc. 
> I'd also have to guess that phone manufacturers haven't 
> implemented it (in the past) due to limits on memory, etc.

There are actually two conflicting methods of packing G.726-32 samples
into bytes.

RFC 3551 has this to say:

   Note that the "little-endian" direction in which samples are packed
   into octets in the G726-16, -24, -32 and -40 payload formats
   specified here is consistent with ITU-T Recommendation X.420, but is
   the opposite of what is specified in ITU-T Recommendation I.366.2
   Annex E for ATM AAL2 transport.  A second set of RTP payload formats
   matching the packetization of I.366.2 Annex E and identified by MIME
   subtypes AAL2-G726-16, -24, -32 and -40 will be specified in a
   separate document.

That's all well and good, but there are some phones out there that pack
samples into RTP payloads using the AAL2 direction. This causes interop
nightmares (i.e. your phones talk G.726-32, someone elses phones talk
G.726-32, but it sounds rubbish when you attempt a conversation). I
would guess that this might be why people avoid the G.726 codec.