I’ve been thinking a lot about header overhead over the past few weeks, to figure out how to downtune the overhead (also for mobile VoIP). I worked on a method that could compress the combined IPv6/UDP/RTP headers to about 1 byte, which is possible because they are highly predictable. But, as so often, such generally useful work has already been itching with someone else:

http://www.rohc.net/

I didn’t know about the RoHC line of RFC’s before, but there is at least one implementation in open source that you might want to port to OpenWRT for your purposes although I think it might need expansion with RTP-mode compression.

It looks like a normal IPv6/UDP/RTP header combo would reduce to about 1 byte, exactly as what I found to be possible. Codec2 and RoHC could combine to IP-level telephony traffic at 5+1 bytes once per 40 ms… or 1200 b/s…!

As for the Ethernet level, it’s good to know that there is an ethernet payload type for RoHC, namely 0x22F1. So you don’t need to worry about compatibility issues with uncompressed traffic, and you won’t even need the two bytes for LLC1.

I thought that was worth bothering you once more for

Cheers,
-Rick

As we pile protocol on protocol, we often forget what can be done at the lower layers. The mirror image of UDP on IP is LLC1 on Ethernet. For a mesh, you probably don’t need full-blown IP anyway — and as a radio amateur you’ll like it — LLC1 and LLC2 are look a lot like AX.25.

If I was to save on RTP bandwidth, I would start off by using IPv6, not IPv4. That is a good idea for SIP/RTP anyway, and perhaps it is time to stop the stampede of NAT. All rarely transmitted stuff, so SIP and RTCP, would just be shipped as IPv6 traffic, but RTP would be siphoned through another procedure.

If the entire country uses a fixed /64 prefix to cover its telephone net, than that prefix would not add any information. And the lower 64 bits can simply be an EUI-64 address, so basically a MAC address. This means that such IPv6 addresses can be reduced to a MAC address. Now on to the UDP port used for RTP. Assuming that a small range of (even) UDP ports is assigned to RTP and statically mapped to the SAP values of an LLC1 link, it would be possible to remove the UDP port as well. It is now up to you to decide if the RTP header adds valuable information, or if one or more RTP packets could be packaged with a payload type annex 8-bit VPI.

Another bit of information that seems to be forgotten, is that early ethernets could use 2-byte addresses instead of the common 6-byte, globally unique addresses. In a mesh architecture, it should be quite possible to use this abbreviated form, provided of course that modern WiFi hardware still supports it.

Finally, do we need 802.1p/q headers? I don’t think so — the transmission over the air is not going to be sped up and your mesh probably has no switches; and upon arrival, the special transmission format makes these packets easily recognisable and subjectable to internal prioritisation / traffic shaping.

So, what do we have now?
– 2 or 6 bytes ethernet destination
– 2 or 6 bytes ethernet source
– 2 bytes length < 1500
– 2 bytes for LLC1
– n RTP dressed-down packets, each
– 1 byte payload type
– 7 bytes of compressed voice
If n=5 and 2-byte ethernet still works, we'd have 13 bytes of "overhead" and 35 bytes of data, the valuable content being 73% of the total. More than enough room to challenge yourself to an even more radical Codec 2…

I'll leave it to you to decide if this is inspired or insane

The overhead of sending RTP packets individually is surprising, and I’ve been thinking about this problem in the past. In a trunkish setup, with a number of RTP streams flowing between the same endpoints, it would be possible to combine a number of RTP packets into one, thus spreading the header overhead over a number of RTP streams.

This would work best if some concentration of traffic takes place; for instance in a PBX per village. Or, since broadcasting is free in a WiFi setting, multiple recipients within reach could be addressed in the same message.

RFC 2198 defines a binary format for piling up various RTP pieces, at a tagging overhead of 4 bytes. And voila, Codec2 is once again a bandwidth-slurping beast I’m pretty sure you’ll be able to sacrafice several of these bytes by specialising this approach for your codec, and thereby find the motivation to make Codec 2 even more impressive than it already is.

You would end up with nodes collecting a few RTP packets from different sources, taking them apart, splitting them each to their destination, and shipping those out once in a while. This would lead to extra delays, but that may be compensated: it is possible to send smaller packets at more regular intervals since there is less waste — 40 ms could become 10 ms, with 10-20 ms delay at intermediate nodes.

The real disadvantage would be that you would need to do something similar to VPI setup in ATM; when the RTP payload type is used so much, it is probably necessary to change it on each RTP-packing-unpacking hop; a lookup table depending on the sender with the sent payload type could serve to lookup the outgoing hop and payload type.

I’ll leave it to you to decide if this is inspired or insane

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