Re: codec bytes command under dial-peer

Hunt.Lee · ‎08-03-2004

Sorry if this is a silly question, but I'm kind of a newbie to Cisco AVVID, so would appreciate any help.

What's the codec byte command for? For instance, if I use 'codec g729ar8 bytes 10' under my dial peer, what does it achieve?

For bandwidth, My guess is that the default payload size for G.729 is 8, so it is now 'increase' to 10.

Is this correct?

As for delay, does it actually inrease or decrease the delay?

Thanks,

Hunt

aamercado · ‎08-03-2004

codec is just compression so with regards to lan vs wan.

1. smaller size so great for low speed wan links go for 729

2. voice quality deteriorates with compression so stick with 711 on lan side

Hunt.Lee · ‎08-04-2004

Hi aamercado,

I understand that. What I'm trying to understand is what does the codec bytes achieve...

Thanks,

Hunt

jasyoung · ‎08-04-2004

It allows you to tune the number of voice samples packed into one IP packet. You can only set it to certain multiples, the sample size for that codec. There's a really good explanation here:

http://www.cisco.com/warp/public/788/pkt-voice-general/bwidth_consume.html

It's a tradeoff is between delay and bandwidth. Most people never need to tune it, because the defaults are pretty good. Sending more voice samples in one packet (more bytes) increases efficiency and reduces bandwidth utilization somewhat, but it increases delay. Sending fewer voice samples in one packet decreases efficiency because of all the extra IP packets and overhead, but it decreases delay.

The only time we've ever had a good reason for changing the defaults is on an ATM-based wide area network. If you use PPP over ATM and then use cRTP (RTP header compression) on top of that, there's a sweet spot for g.729 if you pack three 10ms samples instead of the default two. With ATM you have that fixed cell size and unused space within a cell is wasted. Going to three samples per packet decreases the packets-per-second rate by a third, and then the resulting IP packet fits in one ATM cell, whereas a two sample g.729 packet without cRTP actually spans two cells. That's a pretty big bandwidth savings, and the only cost is an extra 10ms of latency in the conversation which nobody will really notice.

Hunt.Lee · ‎08-05-2004

Thanks Jasyoung!!!

However, since the default payload for G.729 is 20bytes for the payload, if I use:-

codec bytes <10>

That would be decreasing the payload size, so the bandwidth per call would actually increase while the delay per call will increase? Since you now need 'more packets' to complete each call?

Is this correct?

Hunt

jasyoung · ‎08-09-2004

You would be decreasing the payload size by half. This will double the number of packets (thus increasing bandwidth usage) but it would reduce the delay.

Suppose I'm a DSP listening to some FXS port. I've just collected 10ms of your voice from the wire. If I'm sending g.729 10ms packets, I can wrap that up in an RTP packet and dispatch it to the destination immediately. If I'm sending 20ms packets, I sit around and listen to you for another 10ms, then send both samples together in one packet. This longer packet is going to get to the destination sometime at least 10ms later (on average) than the short packet example, simply because the origin router had to sit on it for another 10ms.

Is there some practical problem you're trying to solve? If you're just curious about it that's fine; I just want to know if you think you have a good reason to tune those values. It's rarely a good idea, and nobody is going to notice 10ms of delay, whether added or subtracted.

jbouwkamp · ‎08-09-2004

I would also use RTP header compression if you are going to make the payload 10ms as the compression will almost eliminate the additional overhead induced by doubling the number of packets. Of course I would use RTP header compression anyway heh.