Re: [codec] #16: Multicast?

["Raymond (Juin-Hwey) Chen" <[e-mail]>]

Hi Christian,

> What are those specific codec requirements, then?
> - narrow-band?
> - 5ms or 10ms frame size?
> - low complexity
> - low memory footprint
> - transcoding robust ...

[Raymond]: 
- For the foreseeable future, I think most of the VoIP gateway
voice channels will still be narrowband.  We may start to see
some wideband (16 kHz sampling).
- There are different VoIP gateway customers.  Some just want
the lowest possible cost of deployment and don't care too 
much about call quality or latency; they will probably 
use 20 ms packets. However, some want to compete seriously 
with the PSTN telephony offered by incumbent telcos. 
There they have to have good quality and low latency
since PSTN latency is very low. These customers will want to 
use 10 ms packets or even 5 ms packets if their hardware can 
handle it.
- Yes, relatively low complexity and low memory footprint are both important for VoIP gateway implementation of codecs.
- Good transcoding performance is also a plus, although 
generally if a codec's single encoding performance is already 
high, then it transcoding performance is usually good as well.

> And, are these requirements unique or are they covered by 
> existing codecs like G.711 and G.729 already? Is it likely 
> that gateways, which operate already on their limits, can 
> support yet another codec?

[Raymond]:
- G.729 has a 10 ms frame size, but its complexity is around 
20 MIPS or so.  G.729A can be optimized to around 10 MIPS, so 
it's better for gateways, but G.729A voice quality is somewhat 
lower than G.729.  The biggest issue with G.729 and G.729A, 
though, is that they are royalty-bearing.  G.711 has good 
quality, low delay, low complexity, and is royalty-free.  
However, at 8 bits/sample, G.711 is inefficient with the bit-
rate. A 16 kb/s codec will reduce the payload bit-rate by a 
factor of 4 and reduce the overall bit-rate (including packet 
header, without header compression) by a factor of about 2X 
and 1.6X for 10 ms and 5 ms packets, respectively, which are 
still significant saving in transmission bandwidth and I/O 
bandwidth/throughput.
- Supporting yet another codec is not a problem for gateways 
because it just means a little additional storage of the codec 
program and data tables in ROM, which is cheap.  The gateways 
are already at or near their limits in terms of MIPS, RAM, and 
I/O bandwidth, not in terms of ROM. More importantly, you 
don't run the additional codec as additional voice channels; 
you simply replace some of the existing codecs already 
supported by the gateway in some (or all) of the channels. 
Therefore, as long as the new codec added does not require 
significantly more MHz or RAM than the existing supported 
codecs, it shouldn't be an issue.