[asterisk-users] Why not g726-32?
steve.langstaff at citel.com
Mon Sep 18 02:25:19 MST 2006
> -----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
> >> 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
> > 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
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
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.
More information about the asterisk-users