Hi Mikhael,
On May 7, 2015, at 09:24 , Mikael Abrahamsson <[email protected]> wrote:
> On Thu, 7 May 2015, Jonathan Morton wrote:
>
>> However the more common characteristic is that delay is sometimes low (link
>> idle) and sometimes high (buffer full) and rarely in between. In other
>> words, delay samples are not statistically independent; loss due to jitter
>> is bursty, and real-time applications like VoIP can't cope with that. For
>> that reason, and due to your low temporal sampling rate, you should take the
>> peak delay observed under load and compare it to the average during idle.
>
> Well, some applications will stop playing if the playout-buffer is empty, and
> if the packet arrives late, just start playing again and then increase the
> PDV buffer to whatever gap was observed, and if the PDV buffer has sustained
> fill, start playing it faster or skipping packets to play down the PDV buffer
> fill again.
>
> So you'll observe silence or cutouts, but you'll still hear all sound but
> after this event, your mouth-ear-mouth-ear delay has now increased.
>
> As far as I can tell, for instance Skype has a lot of different ways to cope
> with changing characteristics of the path, which work a lot better than a 10
> year old classic PSTN-style G.711-over-IP style system with static 40ms PDV
> buffers, which behave exactly as you describe.
Is this 40ms sort of set in stone? If so we have a new indicator for
bad buffer-bloat if inured latency > 40 ms link is unsuitable for decent voip
(using old equipment). Is the newer voip stuff that telcos roll out currently
any smarter?
Best Regards
Sebastian
>
> --
> Mikael Abrahamsson email: [email protected]
> _______________________________________________
> Bloat mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
