Check out http://www.anaptyxmesh.com You’ll find indoor and outdoor models that will easily run your OpenWRT variant. Add to the fact it’s designed for dual radio usage, where one card serves the mesh and the other serves the client. I suspect you would of course alter this layout, but maybe it would help you with hardware for the more demanding situation.

Yes I tried to check out your samples yesterday but received a 404 error when I hit the link. 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.

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

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.

Thanks,

David

Ok, you’ve convinced me, that this is a PLC problem

Examples I’ve shown are for generic PLC, i.e. it works on any raw-audio stream. So you just decode packet to raw audio and then apply this PLC. We developed it for the cases when codec does not have internal PLC, like G.711. It’s a shame Asterisk still does not have PLC.

Algorithm 3 (which produces audio with clicks) is actually a dumb frame repetition algorithm – something you can code in an evening by yourself. Algorithm 4 is frame repetition with smoothing just to remove clicks. It requires slightly more work. Seems I can’t tell you a lot about algorithms 0-2, as it’s a IP of SIPez LLC. I just can tell that it took my co-worker quite some time to implement and polish them to remove all clicks and pops and make it as smooth as possible while introducing zero delay. I would love to see this algorithms in open-source, but that’s not in my competence.

I’ve created examples of the same audio with 80ms audio frames and 20% of loss, but I can’t put them online right now, because my ISP is having difficulties in receiving money from me, grr.. I’ll post the link here when my connection brings up.

I still advise you to capture real audio (on sending side) with real packet loss (on receiving side), so we can model it and ply with.

PS Why have you chosen to use Asterisk as a SIP UA? It seems it’s more of a server, then UA. Writing some client will take some more time, but will likely be lighter the Asterisk and will likely have things like PLC.

The packet loss test involved sending a VOIP call over a mesh network that was loaded with UDP traffic such that it had a measurable packet loss (2%, 5% etc). The VOIP call was sent and received by lightly loaded x86 Asterisk boxes, the MP was not being used for voice processing, just passing on packets.

Nothing special was done to handle packet loss, I just used some standard Asterisk boxes with the GSM codec.

Wow 20% packet loss concealment is very impressive. What sort of codec were you using? Are you concealment algorithms open source?

I would like to see more work done in the area of packet loss but it is very time consuming and we have many other tasks to do on the Village Telco project.

If we use 4 codec packet aggregation it is likely that 4 consecutive packets will be lost (80ms) so the distribution won’t be random.

Cheers,

David

Hum. IIRC, my impression was that this quality drop was not due to packet loss. I may be wrong, but I recall that you measured call quality on MP’s phone port. In this case bad quality on the MP may be caused by local audio drops due to high CPU load. I.e. the real problem was not with packet loss, but with local audio processing.
Sorry if I misunderstood your test setup.

re: Packet loss rate.
20% of randomly distributed packet loss is very well concealed by PLC. You may check out these samples wito 20% of packet loss, concealed with PLC, developed by us for SIPez: http://ipse.chemeris.ru/plc/
There are two dirs with samples: “MaleFast” and “MaleSlow”. Each dir contains original audio and this audio with 20% loss, concealed by different 5 PLC algorithms. Lost fragments are 20ms long. Algorithm 3 is very simple, 4 is slightly more complicated, 2 is even more complicated, 0 and 1 are advanced. You may see here, that even simple algorithm provides enough intelligibility at 20% of uniform random loss.
Thus you either (1) have no PLC at all, (2) your distribution of loss is not uniform random loss (e.g. you may loose more then one packet at a time) or (3) your audio issues are caused by different issue.