[Asterisk-Dev] Re: jitterbuffer

[Jesse Kaijen]

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

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.

This is the theory I am trying to prove and for that I need correct 
netstats.
In the first few seconds of a call a user may experience some (little) 
delay/loss and won't notice it (maybe repeat his name...) but only if after 
those few moments the audio perception is good.

If a connection between two *-boxes is mediocre then a switch between those 
to boxes (causing transcoding back and forth) can help the audio quality 
while increasing the delay. Ofcource making the audio switch end-to-end is 
preffered, but this can only be done by handshaking through the whole path. 
I will probably work on that after my research on current topic is 
completed.

Hopefully my intentions are more clear for people. That's why I send it 
again to asterisk-dev - I think carrier people may be interested as well.

Greetings,

Jesse Kaijen

(Note: We are based in Europe, so we would actually prefer alaw, but for 
argument's sake we will take ulaw too ;-))

----- Original Message ----- 
From: "Steve Kann" <stevek at stevek.com>
To: "Steve Underwood" <steveu at coppice.org>
Cc: <iaxclient-devel at lists.sourceforge.net>
Sent: Wednesday, April 13, 2005 6:31 PM
Subject: Re: [Iaxclient-devel] jitterbuffer


> Steve Underwood wrote:
>
>> Steve Kann wrote:
>>
>>> In the larger context, it was my understanding that (one of?) your goals 
>>> is to use the jitterbuffer to detect congestion, and then change codecs 
>>> or something to try to avoid the congestion.
>>>
>>> As I said before, the idea of congestion avoidance (and increasing call 
>>> quality by avoiding loss), is interesting, but I don't think that 
>>> changing codecs alone is really the best solution, since you have the 
>>> constant 12kb/s overhead for sending 50 packets per second.  However, if 
>>> you do figure out how to detect congestion well, there's several things 
>>> you can do:
>>
>>
>> Detecting that there is congestion is largely worthless unless you are 
>> using an end-to-end private network. In that case congestion should only 
>> occur when you overwhelm the QoS controls you should have in place. If 
>> all the users of the link back off their bandwidth demands, congestion 
>> detection might be quite valuable.
>>
>> Most of use are using a shared network, like the public Internet. Here 
>> you need to detect exactly where the congestion occurs, to be able to do 
>> anything meaningful about it. In most cases the legs where bandwidth 
>> reduction makes sense will be the local legs, where QoS should probably 
>> have avoided the congestion in the first place. Reducing your demands on 
>> the shared backbone can actually result in worse, rather than better, 
>> performance for a number of reasons. I haven't seen a well thought paper 
>> that suggests it makes any sense.
>
> I agree, there's going to be few cases where this would help, but Jesse 
> finds it interesting, so maybe he'll be the one to research the topic and 
> find a good solution.

:D
finally.... they understand....
:D

>
> The case where I can see it helping is when the congestion is largely due 
> to calls made using this technology, _and_ QOS can't help.  (i.e. if all 
> the traffic on the link is VoIP or Video over IP -- QoS can't make more 
> than 1.544mbps fit on a T1).  In that case, if the calls lowered their bit 
> usage, they'd get better performance.  This doesn't seem like an 
> outrageously outlying case:    If you have an (oversubscribed) Dedicated 
> IP link between two VoIP endpoints, this can happen as you approach your 
> peak capacity.
>
> You can then extend your capacity by cutting back on bandwidth usage, in 
> one of the ways listed.
>
> However, the other likely case is that your calls are going over the 
> internet, and some huge pipe in the middle is dropping packets.  In that 
> case, it's likely that changing _your_ bandwidth usage won't make a whit 
> of difference, and in these cases, all of the lower-bandwidth strategies 
> are both of a lesser base quality, _and_ of lower tolerance to loss.  In 
> _this_ case, what you might want to do is be a bad internet-neighbor, and 
> use _more_ bandwidth to get some loss tolerance (for instance, use FEC or 
> something like that).
>
> I'm not sure how you can distinguish between these two cases though :)
> [I'm pretty sure this has all been covered already on the various lists..]
>
> Cc'ing back to iaxclient-list; hope you don't mind, Steve.
>
> -SteveK
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Iaxclient-devel mailing list
> Iaxclient-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>