Voice Over IP On Wireless Mesh

infractor writes "ZDNet is reporting that the Linux based LocustWorld Mesh system now has SIP routing at every node. The LocustWorld boxes have been widely used in community broadband projects where DSL is not available, so successfully that they have been seen as a threat to next generation mobile networks. With the addition of VoIP support, these mesh networks can now compete with the telcos on voice as well as data services. More details here."

Comments

Re:Wireless VoIP isn't feasible yet...

[LOL WTF OMG!!!!!!!!!]

Mainly, latency is the biggest issue to be conquered at this time.

I live in Los Angeles and communicate with an FWD SIP with which I call a conference in Japan almost daily. Latency with that is very low, and that's with a free service!

I really don't latency is the problem as much as it is making the technology easier to use for the average joe ( X-Lite is NOT easy to set up if you have router ).

Where's the beef?

[Brento]

If it supports SIP, it's not obvious from their downloads. Their ISOs haven't been updated since 2002...

Re:Where's the beef?

[AndroidCat]

There's some newer files at their high capacity mirror (Haven't checked them over yet.)

Re:Where's the beef?

[Cheeze]

i see 2/10/2004 on the latest build on their ftp site.

Re:Wireless VoIP isn't feasible yet...

[mc6809e]

I live in Los Angeles and communicate with an FWD SIP with which I call a conference in Japan almost daily. Latency with that is very low, and that's with a free service!

But your situation is unlikely to be the most common.

Being on the west coast, you're probably just a few hops from a trans-Pacific link directly to Japan. You have what amounts to a nearly direct link from one place to another.

Latency my ass

[www.fuckingdie.com]

Latency is not a problem as far as I am concerned. I use FWD on a regular basis, and have never ran into a major issue making even ultra long distance calls. (This includes peak time calling, which has never given me trouble.)

Re:Latency my ass

[Anonymous Coward]

Every wireless hop adds a bunch of latency to the connection. Not so bad if you're 2-3 away, but if you're 10 away, it'll be hell.

Re:Wireless VoIP isn't feasible yet...

[kennybain]

In the real world, this isn't the case. You have multiple uplinks into the "wired" interent, so you are only going 3 or 4 hops into the mesh. Ping times to the internet never exceed 100ms on a properly designed mesh network. I use Packet8 over my network... http://www.fastlineinternet.com , we are the first US deployment of the LocustWorld system. So this is a voice of experience.

Skype

[Anonymous Coward]

I have a router. Everyone I know with a net connection has some type of router. Probably because we all have more than 1 computer, but it's not uncommon.

I've tried quite a few VoIP programs, and all of them have problems with routers. Last week I ran across Skype. All I can say is wow. Crystal clear sound, works through the router / firewall without changing a thing. No studder, "CB" effect, etc. and the sound quality is better than my phone.

It's currently in beta, and will most likely have a fee associated with it in the future, but grab it and give it a shot. There's even a PDA version for wireless PDA's. Digging through the site I found something that referenced checking back soon for linux and mac ports.

http://www.skype.com

Re:Injecting harsh realities

[kennybain]

Actually, you are only partially right. Traditional mesh networks, such as the one that MIT has been working on, require routing tables that grow (exponentially) each time a new node is added to the mesh. However, you should read up how LW has solved those issues. From the LW website: "As each mesh node is autonomous, discovering routes on demand, there is no central control to act as a bottle neck. As the network grows the routing task for each node does not grow exponentially, as they only build routes to the resources that they need. Routes are established on demand, and un-used routes are flushed out after a short time."
(Read complete article)

Latency on Wireless; East of Use and NAT.

[billstewart]

Latency on the wireless part of a connection and latency on the wired part of a connection are much different issues, and the whole VOIP and Video-over-IP world is riddled with mythology about latency. If you've got an ISP connection with decent trunking and your uplink isn't heavily loaded, the biggest components of your latency between LA and Japan are the distance to Japan (which regular phone calls also have) and the sampling time of your codec. But if you're sharing an overloaded community wireless LAN that takes six hops through random users' PCs (anything from laptops to PDAs to Fuzzballs to 5GHz-P4s running Genome@Home) to arrive at a 384/128 ADSL connection that's competing with the Mandrake BitTorrrent and three P2P music sharing networks, you'll get a lousy connection to someone in the next town.

However, I agree with you that ease of use is the more serious problem - the prevalence of NAT routers has been breaking the Internet End-to-End model to the extent that John Walker pulled his support for Speak Freely, one of the early pioneer VOIP systems. Some closed systems like Skype do supernode things to work around it, commercial systems like Vonage and AT&T use appropriately designed equipment, and some systems limit their support to the PC-to-PSTN direction. It's an ugly mess.

Actual measurement of a LW mesh

[Baldrson]

Here are ping times from a mesh node that is 3 hops from the gateway:

PING yahoo.com (66.218.71.114): 56 data bytes
64 bytes from 66.218.71.114: icmp_seq=0 ttl=52 time=581.611 ms
64 bytes from 66.218.71.114: icmp_seq=1 ttl=51 time=231.480 ms
64 bytes from 66.218.71.114: icmp_seq=2 ttl=51 time=381.342 ms
64 bytes from 66.218.71.114: icmp_seq=3 ttl=51 time=402.864 ms
64 bytes from 66.218.71.114: icmp_seq=4 ttl=51 time=439.277 ms
64 bytes from 66.218.71.114: icmp_seq=5 ttl=52 time=412.702 ms
64 bytes from 66.218.71.114: icmp_seq=6 ttl=51 time=151.642 ms
64 bytes from 66.218.71.114: icmp_seq=7 ttl=52 time=430.497 ms
64 bytes from 66.218.71.114: icmp_seq=8 ttl=51 time=444.032 ms
64 bytes from 66.218.71.114: icmp_seq=9 ttl=52 time=280.485 ms
64 bytes from 66.218.71.114: icmp_seq=10 ttl=51 time=724.143 ms
64 bytes from 66.218.71.114: icmp_seq=11 ttl=52 time=92.999 ms
64 bytes from 66.218.71.114: icmp_seq=12 ttl=51 time=695.740 ms
64 bytes from 66.218.71.114: icmp_seq=13 ttl=51 time=419.220 ms
64 bytes from 66.218.71.114: icmp_seq=14 ttl=51 time=737.417 ms
64 bytes from 66.218.71.114: icmp_seq=15 ttl=52 time=618.897 ms
64 bytes from 66.218.71.114: icmp_seq=16 ttl=52 time=539.789 ms
--- yahoo.com ping statistics ---
17 packets transmitted, 17 packets received, 0% packet loss
round-trip min/avg/max/stddev = 92.999/446.126/737.417/183.842 ms

Here are the ping times from the gateway itself:

PING yahoo.com (66.218.71.114): 56 data bytes
64 bytes from 66.218.71.114: icmp_seq=0 ttl=52 time=64.234 ms
64 bytes from 66.218.71.114: icmp_seq=1 ttl=53 time=64.491 ms
64 bytes from 66.218.71.114: icmp_seq=2 ttl=53 time=64.086 ms
64 bytes from 66.218.71.114: icmp_seq=3 ttl=52 time=63.948 ms
64 bytes from 66.218.71.114: icmp_seq=4 ttl=52 time=63.516 ms
64 bytes from 66.218.71.114: icmp_seq=5 ttl=53 time=65.467 ms
64 bytes from 66.218.71.114: icmp_seq=6 ttl=53 time=64.871 ms
64 bytes from 66.218.71.114: icmp_seq=7 ttl=52 time=64.494 ms
64 bytes from 66.218.71.114: icmp_seq=8 ttl=52 time=64.090 ms
64 bytes from 66.218.71.114: icmp_seq=9 ttl=52 time=64.252 ms
64 bytes from 66.218.71.114: icmp_seq=10 ttl=53 time=64.044 ms
64 bytes from 66.218.71.114: icmp_seq=11 ttl=53 time=67.765 ms
64 bytes from 66.218.71.114: icmp_seq=12 ttl=53 time=64.428 ms
64 bytes from 66.218.71.114: icmp_seq=13 ttl=53 time=63.651 ms
64 bytes from 66.218.71.114: icmp_seq=14 ttl=53 time=64.078 ms
64 bytes from 66.218.71.114: icmp_seq=15 ttl=53 time=63.852 ms
--- yahoo.com ping statistics ---
16 packets transmitted, 16 packets received, 0% packet loss
round-trip min/avg/max/stddev = 63.516/64.454/67.765/0.967 ms

A caveat on these numbers. First, I haven't optimized the mesh for VoIP -- I just got my VoIP equipment in and will be getting around to that shortly. Secondly, I'm running on the mesh myself so these were output to my ssh screen simultaneously from the distant box so the traffic was doubled up.

RFC Correction

[muonzoo]

Of course, RFC2543 as referenced in the parent article is deprecated, the current base SIP RFC(s) can be considered:

1. RFC3261,
2. RFC3262,
3. RFC3263,
4. RFC3264, and;
5. RFC3265.

Re:Reality Check

[PureFiction]

Good points. What I meant by latency is that losses in the physical layer result in large latencies at the transport layer (i.e. the 802.11 MAC).

And RTP wont fragment as you mention because of MTU (unless you were doing something really odd with fragmentation at the 802.11 MAC?). I was thinking along the lines of long setup delays for the sessions due to SIP over TCP with larger payloads.

I was a bit harsh on mesh networks. The combination of AODV, DSR, and DSDV is a huge shift in the style of ad-hoc organization and cooperation that makes for a truly useful and individual/community centered approach to communication. It is going to be fun.

I just tend to get a bit annoyed with the grand visions of a nationwide mesh utopia springing up from the bowls of democracy and freedom to release us from the tyranny of Big Co Telecom and whoever else... *grin*

Hmmm, I'm going to avoid discussing security implications of the various protocols for now (that's a whole other can of worms I'm sure you are well familiar with)

Trust and security in decentralized networks makes the security problems of the enterprise look appealing in comparison :-)

Re:WVoIP taking over Wireless (Mobile)

[grahamsz]

Well each device can be set to periodically configure itself by TFTP. That can then balance the load just by dividing the users up across your servers.

Typically you need somewhere between 32 (cell phone like) and 96 kbit/s (better than pots) quality call. However that's the peak bandwidth, at least half the call will be silence (while the other party talks) so you can survive with as little as 16kbit/s average.

A T3 should be able to support about 2800 low fi calls or almost 1000 hi fi calls. But not everyone will be calling at the same time... and also, most of the calls will be local so you wont need outbound bandwidth.