07-26-2007, 02:51 PM
| | Re: VoIP tolerable latency and packet loss rate- configurable?
"Vin" <firstname.lastname@example.org> wrote in message
>> > i) where is it configured that a packet should be dropped if it is
>> > late by X seconds
>> At the receiving end, the phone will buffer the incoming packets as it
>> receives them. Into the incoming jitter buffer. The buffer will have a
>> length of time from receiving a packet to playout out the audio. Any
>> packets that arrive in this time can probably be fitted into places. If
>> the packet is too late, it gets dropped - there is no point playing an
>> out of sequence packet.
>> Of course, some cheapy voip phones don't have jitter buffers.
>> Good devices have dynamic jitter buffers. So if some packets are late,
>> then the receiver will grow the buffer to minimise the risk is missed.
>> A longer buffer leaves more time to receive inbound packets.
>> Of course there is a limit to how long the jitter buffer can grow before
>> the listener notices the latency on the line.
> Good explanation but got more questions on those when I think about
> it. I believe it is the software on a device that implements jitter
> buffer, so shouldnt it be more accurate to say the application's
> jitter buffer? As I see it, there is a tolerable latency above which
> the delay exceeds the maximum size of jitter buffer and packet is
> dropped. But isn't that upto the user to decide based on the quality
> of service he desires (or pays for)? So does anyone know what VoiP
> applications out there use for these things and how QoS is done? Also
> where does one implement it? For example, consider skype. Do the
> developers of skype applications decide what is maximum size of jitter
> buffer to use?
>> > ii) What is the tolerable packet loss rate and who specifies it. Based
>> > on this the application can change the codec which provides better
>> > packet loss concealement.
>> Nobody specifies it. You can pretty much hear any loss to some degree.
>> At the moment, I don't know of any VoIP devices that will change codec
>> mid-call when faced with network problems. It really would be neat.
> Skype does this, and it is well documented in some research papers.
> But again, skype is an application not a device. Shouldnt we be
> talking of applications rather than devices? Correct me if I am wrong.
> So I am looking for osme application in which I can decide how much
> late the packets can be before my phone/application has to drop it.
> Also, it would be neat if I can specify how much loss I would tolerate
> for my calls. Isn't there anything out there for such preferences? I
> looked at some open source VoIP clients, but was more confused after
You might find XTen's X-Lite series permit a lot of configuration (e.g. size
of jitter buffer in ms, etc.).
P.s. I would surmise that most implementations work to the principle or idea
of sustaining any level of packet loss still within the devices ability to
signal or determine its status (i.e. if it starts to lose enough data or
signalling to have no idea what is happening or to know if the device is
still connected or that data is still flowing - then it will have little or
no choice but to give up... and this seems to be what happens / the
prevalent implementation - i.e. most implementations seem to allow a pretty
reasonable period for a connection to resume or restore normal enough order
[10 to 30 seconds] before calling it a day - ... even if only a dribble of
data is received, provided enough data and signalling at that get through,
it will be rendered as audio however corrupt or gappy, etc.).