Re: Factors Affecting Village Telco Performance

[Alexander Chemeris]

Hi David,

Continuing here discussion started at the blog:
http://www.villagetelco.org/2009/11/factors-affecting-village-telco-performance/#comments

> Yes I tried to check out your samples yesterday but received
> a 404 error when I hit the link.

Ok, I moved files to a more stable hosting:
http://www.chemeris.ru/plc/
There are 20 ms frames processing with 20% loss samples and
samples with 80 ms frame processing with 20% to model 4GSM-FR
packets.

> BTW for some reason I am not
> receiving email notifications from this site so my responses depend
> on me checking this blog. Feel free to continue this discussion
> on the Google Group if I am slow to respond.

Hum, I receive mails from it fine.

> The reasons for using Asterisk are described on the Village Telco FAQ”.

Aha, as I thought - just because you know it well. :)
Not a bad reason, though.

> I understand Asterisk does have some PLC algorithms, but we
> haven’t experimented with them yet. I guess we would require
> some notification of missed frames, and perhaps experimentation
> with the jitter buffer.

Yes, I recommend you to play with them and you may find you
can tolerate more packet loss.

One more thought re: bad audio quality. It may be the case that
you experience bad audio because jitter is too high. So after JB
processing in Asterisk you actually have much more then 2%
loss. Ping waits a second for echo packet and JB can't wait that
much. Have you had higher latency under high mesh load?
I wonder if Asterisk have a dynamic JB. It should have one..

I ask you once more to record with Wireshark traces on sending
and receiving sides. It would give us more insight on what's going.

PS Anyone know whether we can enable some kind of JB and PLC
debug output to see how many packets are dropped in JB?

--
Regards,
Alexander Chemeris.

[David Rowe]

Hi Alex,

> > The reasons for using Asterisk are described on the Village Telco FAQ”.
>
> Aha, as I thought - just because you know it well. :)
> Not a bad reason, though.

Yes Asterisk is also quite convenient for testing as it's so
configurable via dialplans. For example I can configure it to just echo
samples, or connect a SIP phone directly to a MP. Perhaps other clients
will be ported to the MP in time, that is fine. The tricky bit will be
the FXS driver, most soft phones assume a sound blaster and command line
or GUI.

Re the suggestions below, and sampling using wireshark sorry I don't
have the time right now - I am busy getting MP betas out the door and
progressing the production hardware. However it would be great to see
more work done in this area - you have some excellent suggestions Alex.

If any one is interested in working on packet loss performance it's
possible to emulate our environment with any Wifi link. Load the Wifi
channel with iptraf to get the desired packet loss then make a SIP/RTP
call over the loaded link. I use an x86 Asterisk box at either end
connected to SIP phones.

Cheers,

David

[David Rowe]

Hi Alex,

> Ok, I moved files to a more stable hosting:
> http://www.chemeris.ru/plc/
> There are 20 ms frames processing with 20% loss samples and
> samples with 80 ms frame processing with 20% to model 4GSM-FR
> packets.

CELP type codecs (like GSM, g729 etc) rely on a lot of "memory", for
example information in one packet affects the PCM output speech in many
future packets. This is due to the adaptive codebook or pitch
predictor. So the quality of many future frames will be affected when a
packet is lost - not just the frame we are dropping.

Therefore quality for these sorts of codecs will likely be poorer
compared to PLC acting on PCM streams. PCM has no memory between
packets so you just need to replace the dropped frame.

Also I guess we need to know that a packet has been dropped before
kicking in a PLC algorithm. This may not be obvious to us.

Re jitter buffering I am wondering about end-end delay if we aggregate
up to 80ms frames. We are going to receive 80ms of data at a time so
everything in the jitter buffer will operate on multiples of 80ms.

For example 3 aggregated frames in the jitter buffer will be an extra
240ms delay, if this happens on both ends of the link that's 480ms round
trip. The jitter buffer could probably do a better job on 20ms frames,
but the packet rate then jumps up.

Cheers,

David

[Alexander Chemeris]

Hi David,

On Thu, Dec 3, 2009 at 01:38, David Rowe <da...@rowetel.com> wrote:
> Re the suggestions below, and sampling using wireshark sorry I don't
> have the time right now - I am busy getting MP betas out the door and
> progressing the production hardware.  However it would be great to see
> more work done in this area - you have some excellent suggestions Alex.

Np, I have tons of other things to do. I'm rather overloaded then underloaded :)

> If any one is interested in working on packet loss performance it's
> possible to emulate our environment with any Wifi link.  Load the Wifi
> channel with iptraf to get the desired packet loss then make a SIP/RTP
> call over the loaded link.  I use an x86 Asterisk box at either end
> connected to SIP phones.

Hum. Not that simple. Using built-in card in my laptop I won't be able
to get any packet loss, even at saturated link. Seems it just blocks
sockets when it can't send a packet.

--
Regards,
Alexander Chemeris.

[Alexander Chemeris]

Hi David,

On Thu, Dec 3, 2009 at 01:52, David Rowe <da...@rowetel.com> wrote:
>> Ok, I moved files to a more stable hosting:
>> http://www.chemeris.ru/plc/
>> There are 20 ms frames processing with 20% loss samples and
>> samples with 80 ms frame processing with 20% to model 4GSM-FR
>> packets.
>
> CELP type codecs (like GSM, g729 etc) rely on a lot of "memory", for
> example information in one packet affects the PCM output speech in many
> future packets.  This is due to the adaptive codebook or pitch
> predictor.  So the quality of many future frames will be affected when a
> packet is lost - not just the frame we are dropping.
>
> Therefore quality for these sorts of codecs will likely be poorer
> compared to PLC acting on PCM streams.  PCM has no memory between
> packets so you just need to replace the dropped frame.

Yes, you're right. But GSM was designed to minimize the effect, IIRC.
And it also have a built-in PLC which *should* work better then generic
ones. The main goal of my samples was to show that 1-2% loss just
can't make stream un-intelligible, there should be *much* higher
loss or it should be very bursty.

> Also I guess we need to know that a packet has been dropped before
> kicking in a PLC algorithm.  This may not be obvious to us.

If packet hasn't arrived in time, it's lost. Simple. It's
soft-realtime after all. :)
JB will tell you when there is a packet and it is lost.

> Re jitter buffering I am wondering about end-end delay if we aggregate
> up to 80ms frames.  We are going to receive 80ms of data at a time so
> everything in the jitter buffer will operate on multiples of 80ms.
>
> For example 3 aggregated frames in the jitter buffer will be an extra
> 240ms delay, if this happens on both ends of the link that's 480ms round
> trip.  The jitter buffer could probably do a better job on 20ms frames,
> but the packet rate then jumps up.

That's why I have a strong hope one will put effort in IP-level aggregation
and/or RTP interleaving. With 80ms frames you'll have
1) Less stable JB - many algorithms tend to do more jumps when they
operate with bigger packets.
2) More latency, as you noticed.
3) More problems in case of packet loss. 80ms may carry one-two phonemes,
so you can't conceal that big loss. Even worse if you loose 160ms - you will
have to sing in slow tempo to be intelligible on the other side :)

--
Regards,
Alexander Chemeris.

[Donald Gordon]

Hi

If you want to simulate packetloss/jitter/etc, then http://wanem.sourceforge.net/ may be useful, it's a nice livecd distro on top of the linux netem facilities.

donald

--

You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To post to this group, send email to village-...@googlegroups.com.
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/village-telco-dev?hl=en.

[Alexander Chemeris]

Hi Donald,

Thank you. But I actually want to look at real-world traces.

--
Regards,
Alexander Chemeris.