Craig wrote:

Greetings all,

I have searched all over and have found bits and pieces on low bit rate
codecs, however I have found it very difficult to compare apples with
apples.

The conclusions I have come to are as follows, I would appreciate if
anyone has some feedback, or point me to where I might find this sort of
comparison in black and white....

G723.1 very low bit rate
used commercially, not avail for * (I am currently using this codec in another commercial application and
therefore it is my reference point)


G.723.1 is pretty much obsolete. You don't see it being used on anything new. Most people do VoIP using RTP. The overhead of RTP is so huge, a small saving on the codec makes little difference. People generally go for G,729 now, which sounds considerably better. If you compare the total bit rate for G.723.1 vs G.729 in RTP G.723.1 often comes out considerably lower. This is because it works in 30ms blocks - you only have 33 RTP packet overheads per second. You can choose to pack more G.729 data into each RTP packet and even this up.

The patent licencing for G.723.1 is a PITA, which hasn't helped it achieve widespread use. There are two variants of G.723.1, with different bit rates. The lower bite rate (5.something kbps) sounds nasty. The higher rate (6.something kbps) sounds more reasonable. Using 30ms blocks, it is not so compatible with *, which is geared to 20ms block processing. A lost packet causes a 30ms hole, so it tends to be less tolerant of packet loss than something working in smaller blocks. It sounds awful for anything but a single pure voice.

G729a
low bit rate
slightly higher bandwidth usage than 723.1 ???
avail as a low cost add-on for *
better quality that g723.1 ???


Definitely better quality than G.723.1. This is definitely the mainstream right now for VoIP. It is heavily patented, so free codecs are not possible. There are several bit rate options, but almost everyone uses the 8kbps variant. This sounds pretty good for its bit rate, though I think there have been better codecs. In telephony you need use something compatible with the far end, and G.729 seems to be the current common ground. It is rather intolerant of packet loss. Some people pack several G.729 blocks into a single RTP packet, to decrease the RTP overhead. That makes it even less tolerant of packet loss. It sounds awful for anything but a single pure voice.

iLBC
Low bit rate
slightly higher bandwidth usage than 723.1 and 729a ???
open source, no additional cost for *
quality comparable to G729a
stands up better ip paths suffering from latency and jitter ???


iLBC has a much higher bit rate than G.729, but the voice quality is about the same. Why does that make it interesting? Well, it is designed to be much more tolerant of packet loss, and that makes it take more bandwidth. The design of RTP makes that take so much overhead that the total bit rate using iLBC isn't a huge jump from using G.729. However, if you use a more efficient streaming mechanism - say IAX, or an RTP like format with many calls packed in a packet - the total bit rate difference starts to look wider. There, the increase in bits is so great its quite likely to be the *cause* of packet loss, by clogging up the channel. :-)

Good old GSM 06.10 is worthy of consideration. Free of patents (at least ones being actively pursued). Low compute requirements. Reasonable voice quality. Somewhat more tolerant of background noise than the codecs above. Although GSM networks don't use it much these days (they mostly use the newer EFR and half rate codecs) it's still a very servicable codec. Its bit rate lies between G.729 and iLBC. On a pure voice it gives poorer quality than G.729. Add some background noise and it can beat G.729. Its tolerance of packet loss is probably similar to G.729.

Regards,
Steve

_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Reply via email to