[cisco-voip] g711 sample size in CCM - 10ms or 20ms

[Paul Long]

Functionally, there are two input buffers--a reordering buffer and a
jitter buffer. They are often combined. A vendor must implement a
reordering buffer because packets can and often arrive in a different
order than they were sent; however, vendors will sometimes cut corners
by not implementing a jitter buffer. If there is no jitter buffer or if
the jitter buffer is not big enough, you'll hear occasional cut outs.
Not a big deal but noticeable.

There are static and dynamic jitter buffers, dynamic of course being
better but more complicated to implement. The larger the jitter buffer,
the better it is at masking jitter in the media stream but the more
delay it imposes on the stream. A dynamic jitter algorithm always tries
to minimize the jitter buffer to minimize delay while providing just
enough "cushion" to absorb packets that are not isochronous.

H.323 allows an endpoint to advertise its transmit capabilities, and
vendors often include them, but they are of only very obscure utility.
For example, another endpoint can send a RequestMode message to request
that the endpoint send a specific set of streams, e.g,. H.263 QCIF video
and G.723.1 low-bitrate, knowing exactly what the endpoint is able to
transmit.

Paul

-----Original Message-----
From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Wes Sisk
Sent: Tuesday, February 15, 2005 12:58 PM
To: Eric Knudson
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] g711 sample size in CCM - 10ms or 20ms

Yes, codec is somewhat independent of sample size.  The two are 
typically related by available buffer memory in the endpoint.  The 
receiving endpoint must implement a de-jitter buffer, otherwise voice 
quality will directly suffer.  de-jitter buffer is simply a space of 
memory to receive and sort RTP payload before playout.  high bit rate 
codecs such as g711 take more space to implement a 40 msec dejitter 
buffer compared to low bit rate codecs such as g729.

AFAIK all protocols advertise RECIEVE capabilities, not transmit 
capabilities.  This is a subtle difference as the two should basically 
match.

I know in CCM 3.0 and 3.1 it was possible to setup asymetric audio 
streams so

ep1                                ep2
g711(20)------------->
              <-------------g729(20)

I used to see this when a 12SP+ or 30VIP called a 7960.  I have not seen

this in a long time.  The call actually worked fine.

/Wes

Eric Knudson wrote:

>additionally, just for my edification - isn't codec independent of
>sample size? Additionally, isn't each rtp stream independent from
>another - for example, you could have:
>
>endpoint                  endpoint
>g.711(10ms)----------->
>           <--------------g.711(160ms)
>_______________________________________________
>cisco-voip mailing list
>cisco-voip at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-voip
>  
>
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip