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

Wireless VoIP isn't feasible yet...

[mindless4210]

With the addition of VoIP support, these mesh networks can now compete with the telcos on voice as well as data services.

I would have to disagree with that comment. Yes, these networks can now provide voice services, but they cannot effectively compete. In reality, wireless VoIP is still being developed and will most likely not be of acceptable quality for another year or so. Mainly, latency is the biggest issue to be conquered at this time. I think until they are able to reduce latency times significantly in these applications, it won't be widely accepted. It's just too frustrating when theres a couple seconds in between speaking and hearing a response from the other person.

Furthermore, while a mesh network can still carry a high data rate, the high number of hops to a wired connection from some locations along the network could make talking over VoIP rather unbearable. I imagine that on a larger mesh network you could experience latency upwards of 1000 ms.

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 ).

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

[JoScherl]

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 ).

Does Joe have a router? I think not. Ok, thanks to DSL-Lines, at least here in Germany, many people get routers, but still I don't think Joe Average has one. The greater problem is that a) Joe dosn't know about it and b) he doesn't know anybody else who uses the same VoIP system. To make use from VoIP it would imho need one big company advertising these services, but I think the ISPs do not like VoIP 'cause it creates huge amount of traffic

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.

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

[PretzelBat]

So long as this is internet to internet there is no service fee.

However, this sort of thing, if it becomes common, could quite possibly lead to a tragedy of the commons. If everyone actually started using all the bandwidth they had available, the networks would become jammed quickly enough.

Free VOIP is great in the short-term, but there is *not,* at this point, an unlimited amount of free bandwidth available.

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.

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.

Quality

[lukewarmfusion]

Compete? Maybe not. Remember when NPR discussed this and one of the callers started having problems - right in the middle of his praise for VoIP?

That said, I'm anxious to find an inexpensive way to replace my $90 cell, $50 broadband cable, and $40 landline. If I can cut these bills down significantly (by using my broadband to provide my landline) I'd be happy. And I'd bet that most bill-paying consumers would be too.

This is precisely

[iminplaya]

the kind of "wireless internet" that I have been babbling about in other threads. This is what can liberate us from corporate control of internet access. I want to see this "wireless cloud" cover the planet. The latency issues will be worked out. In the meantime, this is great for "little" community internets where latency is not that bad. Even if they can't access the net at large, they can communicate, completely free from interference from the gov't, with each other. Maybe (hopefully) it can bring about completely anonymous, untracable communications. Just because it's not codified into law, anonymity is a right, and anything that can bring it about is a good thing.

my greatest dream

[ericbrow]

I've always thought that this should be. Wouldn't it be great if wireless networking were as easy to come by as electricty, but without the wires.

I know it's a little communistic in thinking, but I really believe that to gain true freedom of information, we need to make the information superhighway free to use.

While I know many problems would have to be worked out, like security, but it would change everything. Imagine every student being able to turn in assignments anywhere. Imagine doctors being able to monitor patients real-time, as they were being rushed to the emergency room. Yes it would put the telcos and cable companies in an uproar. But I think that would be the price of progress.

Re:my greatest dream

[cavebear42]

There should be a mod:
-1 (used phrase "information superhighway")

Queue up Lawyers and Lobbyists

[rock_climbing_guy]

Let's set up a queue for all the lawyers and lobbyists for Cingular and Nokia to try to get a bunch of stupid laws passed to tariff / cripple this technology.

Dell use VoIP for their Indian call centers

[Anonymous Coward]

5 second pause...

Hello, my name is Bob Thandushepatindiar how may I help you?

5 second pause....

My computar's borken! Help.

5 second pause...

I understand your unhappiness.

5 second pause....

I said my COMPUTAR'S BORKEN!

5 second pause...

Thank you, come again.

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.)

Injecting harsh realities

[PureFiction]

The code is there, the actual performance is going to be lackluster at best.

Mesh networks suffer from scaling problems due to the overhead associated with ad-hoc protocols. All that flexibility and adaptability come at a price: efficiency, latency and throughtput all decrease as the size of the mesh increases (and even more so when you have popular / power law nodes attracting routes)

Voice is notoriously sensitive to delay and to some degree packet loss. Sure, delay effects can be overblown (ATM anyone?) but you get a saturated mesh network trying to route voice and those multi-second round trip times are going to make your cable modem look like a T3.

[You get losses due to interference, transient link problems, mobile nodes, sun spots, whatever, that cause delays at the physical layer (an ethernet frame takes a while to traverse the ether) which then affects all higher layer protocols: UDP packets can't be reassembled because a fragment is lost. TCP starts backing off too agressively. Retransmission timers get triggered adding to inefficiencies, the list goes on]

Wireless and mesh networking in particular are very promising and useful technologies, but they are no where near the utopia that is often presented.

Trivial DoS attacks, scalability problems, and compounded complexity all add up to make it a very volatile environment.

Sure, this stuff will work, but only in very constrained configurations / environments.

Maybe someday further in the future these dreams can be realized when we have robust MIMO software radios and intelligent network stacks that can adapt to such harsh conditions. :-)

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.

Re:Reality Check

[PureFiction]

I'll shut up after this, promise. :-)

Multisecond RTT doesn't happen on anything but GPRS

I've seen it far too often on congested wifi networks. you easily get into a congested state with a crowded AP that forces lots of client waits for the DCF (i.e DIFS + padding, each in turn) and also induces lots of retransmission at the physical level due to collision with so many clients trying to talk to the same AP. Low power clients associated at the 1 or 2 Mbps rates drive this contention over the DCF even higher, severely punishing everyone associated.

The big conference venues are notoriously bad about this, as you often end up with 10-20+ people associated with a single access point. That is just too many, and the 802.11 MAC was never meant to handle that kind of load efficiently. It is a pretty good solution for the general case that simply can't cover all the edge cases (long shots, high client loads, noisy RF environments).

This type of situation results in really weird ping times, for example. I've seen fluctuations myself that go from 80ms, 120ms to 3s!, 2s!, etc. then back down to a few score milliseconds. That is the 802.11 MAC trying to cope with scenario's it was never designed to encounter.

I mentioned software radios in the first post because having access to timing and congestion control in the MAC would allow mesh boxes, clients, and AP's to make very significant performance enhancements for situations where they were needed. Why be forced to use a static, inflexible, proprietary hardware layer when you can have the open flexibility associated with software radio? (It's coming, just not soon enough :-) There are also extensions to the ad-hoc routing protocols (like passive monitor of route info between other clients in DSR) that could be supported if only the hardware was open enough to do so.

I don't want to bitch too much; we have come a long way from sub-megabit data via FHSS over 900Mhz. I just want the really good stuff to hurry up and get here already so that things like mesh networks, low latency/loss voice over IP, and highly available multipath/redundant network configurations can be enjoyed to their full potential. (software radio + multiple input / multiple output + intelligent network stacks that can handle a diverse and volatile network environment). ... and a pony!

Gratuitous links:
congestion problems at TechEd conference

congestion melt down at CeBIT

GNU Radio's software defined radio (SDR)

software defined radio on $2,000 of 'roids [it's a dev kit, but would work very well for almost any kind of project]