Voice Over IP On Wireless Mesh 109
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."
Wireless VoIP isn't feasible yet... (Score:5, Insightful)
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 [zdnet.com] 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... (Score:5, Informative)
I live in Los Angeles and communicate with an FWD [pulver.com] 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... (Score:4, Insightful)
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... (Score:2, Interesting)
And routers these days are generally easy to use. CompUSSR sells one for $20 with a nice web interface and very easy instructions.
However, the fact remains that most VoIP software has horrific problems when working with a router. Whether this is problems with most routers handling UDP, or just bad programming is something that's beyond me.
Skype (Score:1, Informative)
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 associat
Routers at Joes home (Score:1)
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.
People who use their computer more for working etc. have routers, that's true. But still I think Joe Averange, in most cases, doesn't have a router.
Re:Wireless VoIP isn't feasible yet... (Score:2, Interesting)
VoIP has companies advertising and it's becoming more popular as well as usable.
Re:Wireless VoIP isn't feasible yet... (Score:1)
I'd say about 70% of the people that call have routers even if they only have one computer
Maybe it's just that the ones without a router have less problems. ;-)
Re:Wireless VoIP isn't feasible yet... (Score:5, Informative)
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 on Wireless; East of Use and NAT. (Score:3, Informative)
Re:Wireless VoIP isn't feasible yet... (Score:2, Interesting)
Let me stick with my MSN (*awaits flames*) voice conversations with people I know
Re:Wireless VoIP isn't feasible yet... (Score:3, Interesting)
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... (Score:3, Insightful)
than PSTN. If I'm calling you on a VOIP phone,
I'm *not* calling you on a PSTN phone. The difference
in backbone traffic on the fiber is negligible, but
the difference to my wallet is significant.
Sign me up! (Score:2, Funny)
Re:Sign me up! (Score:1)
Oh, wireless electricity isn't really that difficult... it can be acheived through a microwave beam.
The real trick is coming up with wireless electricity that doesn't fry anyone alive who wanders into the path of that beam...
Re:Sign me up! (Score:2)
This link [permanent.com] is a summary paper of information from a variety of sources on Solar Power Satellites. This one [permanent.com] has a couple pictures of a test in Ca
Re:Sign me up! (Score:2, Funny)
Re:Wireless VoIP isn't feasible yet... (Score:5, Informative)
Re:Wireless VoIP isn't feasible yet... (Score:2)
So, that means we have to add 100 ms latency to everthing, right?
That's already getting close to the edge of what is considered tolerable.
Re:Wireless VoIP isn't feasible yet... (Score:1)
Locustworld User Experiences (Score:1)
Where's the beef? (Score:5, Informative)
Re:Where's the beef? (Score:3, Informative)
Re:Where's the beef? (Score:4, Informative)
Quality (Score:5, Insightful)
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.
Re:Quality (Score:3, Insightful)
Re:Quality (Score:1)
Re:Quality (Score:2)
Imagine:
You're watching the game. Your mother-in-law buzzes in. A little picture-in-picture appears. She thinks she's got your full attention, but in reality you're glued to the last play of the game! Brilliant. Hell maybe you've got another 'lindow' open where you're updating your online wager. Evil, but sexy.
Re:Quality (Score:1)
Re:Quality (Score:2, Insightful)
Re:Quality (Score:1)
Re:Quality (Score:2)
I had a job and fiancee in the USA, and vonage gave me a local number there and unlimited calling for about the same a british telecom charged for an hour long call each month.
Now the situation is flipped, I'm in the USA and need to call family and friends in the UK. I just converted my old vonage hardware to run with mywebcalls.com and i can get cheap calls the other way.
I called my mom yesterday using voip for the
QoS (Score:2)
Any type of wireless service (regardless of type) is subject to serious issues. On my cellphone, I occasionally place or receive calls
This is precisely (Score:5, Interesting)
Wireless vs. Fiber vs. Commercial vs. Govt (Score:3, Interesting)
Re:This is precisely (Score:1)
Really?
Justify this statement, please.
Re:This is precisely (Score:1)
People used to say that man would never fly. The things I speak of are possible. We just don't know how, yet.
Re:This is precisely (Score:2)
Also, zerconf(apple's rondezvous) does a lot of thigns we should be using... auto-assigning ips, and discovery, easy setup...
IPv6, more addresses, better inherit security....
TCP: that competition that made TCP uber-fast by tweaking it's algorythm... fastTCP, that has articles on
The next version of TCP/IP
Re:This is precisely (Score:2)
Okay then... Are YOU going to be the one sailing one of the boats needed, in the middle of the Pacific Ocean, with nothing but an 802.11 access point onboard to relay signals from contient to contient?
Yeah! They couldn't do that before with telephones, postal mail, wireless radios, smoke signals, et al., right?
Re:This is precisely (Score:1)
Buoys? Bouys? Those little floaty things used for navigations...
They couldn't do that before with telephones, postal mail...
Yes, but now encryption is easier. Actually, with all the noise already in the system, it's getting even easier to hide messages, and with wireless, it can be made harder to trace(think constantly changing IP addy's, in a spread spectrum kind of way, and the simple fact that you're mobile, like a scud launcher)
It does
Re:This is precisely (Score:2)
And how do you plan to power these buoys? Solar isn't powerful enough yet, and if you run a generator, somebody is going to have to go refuel them all the time.
I think most everyone will agree that postal mail can be as anonymous as you want it to be. You could even use PGP to encrypt the contents if you like.
Re:This is precisely (Score:1)
Those things roll around a lot. Something like the self winding mechanism in a watch, only big?
Anybody can spend a few bucks and build a powerful signal jammer that will just destroy all wireless networks in the area.
Curses...foiled again...back to the lab, pinky...I'll get back to you on that. I hope jammers will be easy to find, even in the cloud. Maybe, due to it's power level? or how the signal is modulated? All that work they're doing with active noise can
Re:This is precisely (Score:2)
It's been tried, it just doesn't provide enough power for much more than a dim lightbulb.
You also have wind power generation, which would be good on the sea where there's no obstructions, but I still don't believe it would be windy enough to provide (just) several dozen watts of power all day.
Well, jammers will be like spam
Re:This is precisely (Score:1)
Cops aren't going to be interested in comming out to find who is responsible...
The cops will probably most likely be the people responsible for putting UP the jammers. The gov't doesn't like P2P communications without going through on
Re:This is precisely (Score:2)
About the only possible way to block all types of signal jammers is to build an aluminum dome around them, that is connected to a large groundind rod with high gauge cables. Good luck!
my greatest dream (Score:5, Interesting)
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 (Score:5, Funny)
-1 (used phrase "information superhighway")
Re:my greatest dream (Score:3, Funny)
corporate projects are anti-social (Score:1, Insightful)
Queue up Lawyers and Lobbyists (Score:4, Funny)
Re:Queue up Lawyers and Lobbyists (Score:1)
So.. (Score:3, Interesting)
Re:So.. (Score:2)
I can't imagine how. It's just too fragile. Anyone can knock-out a large segment of a wireless network, and without some money behind it, who is going to try and make sure it doesn't happen, or that it's stopped right away?
And then there's the question of who is going to be the one to pay to setup and operate the relays in the middle of long hauls where you won't find any computers otherwise.
And there's always the fun part of having the o
Dell use VoIP for their Indian call centers (Score:4, Funny)
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 (Score:4, Informative)
Re:Latency my ass (Score:1, Informative)
WVoIP taking over Wireless (Mobile) (Score:2, Interesting)
Here are a few of the reasons:
Re:WVoIP taking over Wireless (Mobile) (Score:2)
Hacks do exist for VoIP systems but these dont seem to be any more widespread than other network applications. People still use FTP and SMTP despite their atrocious security records
An open standardized system is one of the best things about it. I can take my stock VoIP hardware and (in theory) make it work with any number of providers
Cisco make nice little boxes which have CAT5 in and Telephone out, Grandstream make real phones with CAT5 connections, someone even makes phones
Re:WVoIP taking over Wireless (Mobile) (Score:2, Interesting)
What about hardware? I'm talking about load balancers, servers, and phone sets? Let's suppose you roll something like this out to a community, what would they have to have to support it? Probably a server with a 1Gb backbone right? Something to handle all of the traffic too. Then they'll need hardware for the phone replacement.
Or it could be offered as a notebook/PDA based software that you use to make your calls.
Re:WVoIP taking over Wireless (Mobile) (Score:3, Informative)
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 every
voip in actual use (Score:1, Interesting)
doesn't cut it. That's where the market is though.
I've used some VOIP implementations in less than
ideal conditions and there is a lot of work to
be done before this is ready for prime time.
Not a coder ? Want to help spread Linux ? Click here ! [lp2p.com]
Injecting harsh realities (Score:4, Insightful)
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.
Re:Injecting harsh realities (Score:2, Informative)
Re:Injecting harsh realities (Score:1)
Reality Check (Score:2)
Mesh networks aren't perfect, but the extreme low bandwidth of voice (8kbps for G.729) relative to the channel capacity makes up for quite a bit. Voice is way more sensitive to packet loss than delay, because almost nobody's implemented error concealment*. You notice the dropped signal on your cell phone way before you notice the absolutely atrocious latency you chug through.
Multisecond RTT doesn't happen on anything but GPRS, and that's because the actual core bandwidth is so slow (well, it's fo
Re:Reality Check (Score:3, Informative)
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 or
Re:Reality Check (Score:4, Interesting)
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
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).
Gratuitous links:
congestion problems at TechEd conference [newswireless.net]
congestion melt down at CeBIT [newswireless.net]
GNU Radio's software defined radio (SDR) [comsec.com]
software defined radio on $2,000 of 'roids [xilinx.com] [it's a dev kit, but would work very well for almost any kind of project]
Re:Reality Check (Score:3, Interesting)
Still, I'm amazed you saw not dropped packets, but the MAC hold onto stuff for thousands of ms. Wow.
You know, the newest Linux wireless drivers have moved _everything_ into software -- thu
Re:Reality Check (Score:2)
Where can I find out how to do that? I researched this reccently, hostAP only works with cards that have built in support for being a master. I'd like to use cheap cards in routers made from old PC's to act as access points in mesh networks instead of operating in ad-hoc mode. What about the performance issues, will this work on early pentium hardware?
Actual measurement of a LW mesh (Score:4, Informative)
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.
A conflicting measurement. (Score:2)
Investigating.
Here are his ping numbers from 3 hops out from the gateway:
PING yahoo.com (66.218.71.113): 56 data bytes
64 bytes from 66.218.71.113: icmp_seq=0 ttl=51 time=88.457 ms
64 bytes from 66.218.71.113: icmp_seq=1 ttl=51 time=79.813 ms
64 bytes from 66.218.71.113: icmp_seq=2 ttl=51 time=166.744 ms
64 bytes from 66.21
A Self-Contradictory Measurement (Score:2)
PING yahoo.com (216.109.127.28): 56 data bytes
64 bytes from 216.109.127.28: icmp_seq=0 ttl=47 time=104.552 ms
64 bytes from 216.109.127.28: icmp_seq=1 ttl=47 time=167.325 ms
64 bytes from 216.109.127.28: icmp_seq=2 ttl=47 time=133.283 ms
64 bytes from 216.109.127.28: icmp_seq=3 ttl=47 time=110.557 ms
64 bytes from 216.109.127.28: icmp_seq=4 ttl=47 time=107.804 ms
64 bytes from 216.109.1
Like Air Supply, this could be big in Asia (Score:3, Interesting)
In many developing countries landlines simply aren't a viable option due to underresourced, corrupt and/or incompetent state-owned telecoms. Many of these countries have been able to develop more robust cell and broadband services, as these industries have seen less regulation and are more scaleable.
For security, convenience and efficiency reasons we like to provide staff in these offices with cell phones, however cell phones plans in may still leave much to be desired in some countries.
I think that many of our offices would be interested in VoIP cell phones if the coverage was decent (even covering major cities might be > or = to existing cell networks). Latency in phone conversations is already par for the course.
Could be an interesting microenterprise project.
looks pretty cool...but.... (Score:1)
WiMAX is the answer (Score:2)
RFC Correction (Score:3, Informative)
Fractal capacity? (Score:2)