[Asterisk-Dev] Re: jitterbuffer

Steve Kann stevek at stevek.com
Wed Apr 13 10:50:34 MST 2005


Jesse Kaijen wrote:

> Hi,
>
> I noticed that some people don't understand what I want to establish, 
> so here is some explanation.
>
> The possibility of changing a codec during a call can have various 
> impacts on the perceived audio quality.
> We all want the best audioperception and there are a few variables 
> that have impact.
> They are: codec, delay, loss and jitter.
> Jitter can be handled by a jitterbuffer and results in more delay 
> (and/or loss).
>
> So there are still 3 variables left.
> In our target environment we have no influence on delay and loss by 
> the network (open Internet!), but we do have on the jb_delay and 
> jb_loss. However jb_delay can be a trade off against jb_loss.
>
> Let's say we have three codecs available. ulaw, GSM, ILBC.
>
> ulaw: best_quality, high_bandwith, terrible with loss
> GSM: high_quality, low_bandwith, mediocre with loss
> ILBC: good_quality, low_bandwith, good with loss

I'm not sure why you state that uLaw is worse than GSM with loss..  
Since they both use the same PLC method, and uLaw is stateless, it will 
do much better in the presense of loss.  It will also probably do better 
than iLBC in terms of quality all around. 

> Assumption 1: we always want the best achievable audio quality and we 
> have little or no influence on the network.
> Assumption 2: user is stupid and/or can't give information of the 
> connection.
> Assumption 3: 'program' has to give best solution for all types of 
> connections, without manual reconfiguring.
>
> In a private network the end-end delivery is perfect ==>> ulaw.
> modem-connection ==>> GSM || ILBC
> internet-connection:
> if there is low traffic (no loss) ==>> ulaw
> if there is traffic and some loss ==>> GSM
> high traffic with losses ==>>ILBC      (if your kids uses Kazaa, kill 
> Kazaa and use ulaw)
> (extreme scenario: send more packets to push Kazaa 1d10ts out of the 
> link)
>
> With ILBC the loss is not resolved, but user perception will be better 
> because ILBC uses FEC/PLC techniques.

In the current asterisk and iaxclient implementations _every_ codec now 
has PLC support (well, maybe not G.723/G.729, but soon, I guess).

I don't think that iLBC uses FEC, but it is mostly stateless, such that 
the loss of a frame doesn't upset it's model as much as other compressed 
formats.


-SteveK




More information about the asterisk-dev mailing list