Slashdot Mirror

← Back to Stories (view on slashdot.org)

Voice Over IP On Wireless Mesh

Posted by timothy on from the network-is-the-network dept.

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

8 of 109 comments (clear)

  1. Re:Wireless VoIP isn't feasible yet... by LOL+WTF+OMG!!!!!!!!! · · Score: 5, Informative

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

    --
    That CSS file that blocks ads
  2. Where's the beef? by Brento · · Score: 5, Informative

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

    --
    What's your damage, Heather?
    1. Re:Where's the beef? by AndroidCat · · Score: 3, Informative

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

      --
      One line blog. I hear that they're called Twitters now.
    2. Re:Where's the beef? by Cheeze · · Score: 3, Informative

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

      --
      Why read the article when I can just make up a snap judgement?
  3. Re:Wireless VoIP isn't feasible yet... by mc6809e · · Score: 4, Informative

    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.

  4. Latency my ass by www.fuckingdie.com · · Score: 4, Informative
    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.)

    --
    That really is my homepage, no kidding.
  5. Re:Wireless VoIP isn't feasible yet... by kennybain · · Score: 5, Informative

    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.

  6. Actual measurement of a LW mesh by Baldrson · · Score: 3, Informative
    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.

    --
    Seastead this.