I'm hoping to give a demonstration of a mesh network between farm vehicles soon. I'd like to use VoIP as the application. I have lots of VoIP stuff already and I'm thinking of buying some Cisco 7940 phones.
However...for most of the nodes I want to use Linksys WRT54G wireless routers running OpenWRT (and OLSR for the mesh routing). The problem is that I want the nodes to be able to communicate with each other even when there is no path to the wired network. (A situation would be two tractors working a distant field with no trucks, etc. to relay back to the barn.)
To do this I just realized that I'm going to want something on the order of Asterisk running on each node, able to route calls to any other node independently. The Linksys box has a tiny amount of memory. I don't think Asterisk can begin to fit in it.
So is there a very simple VoIP switch that can fit on a small system like this? Do I need to roll my own with something like libiax? Normally I'd want to use IAX but the only IAX device I have is an IAXy (which didn't work well) so I'd rather have something that can at least speak SIP to the devices. I'm thinking IAX is probably better for being able to move calls efficiently though.
Suggestions? Even reasons why it's not likely to work well will be appreciated. I can still punt and use more powerful systems than the WRT54G.
I don't believe you need a sip proxy at all to call between VOIP phones. I can call between my Grandstreams by dialing the IP address directly. It is a bit of a long "number" to dial, but for a quick proof-of-concept demo it might be ok.
That would leave you with only having to do the code for the mesh routing. I understand that isn't as easy as it first appears. The MIT rooftop folks have some very uncharitable things to say about the
802.11b signaling protocol and how it is basically impossible to keep their ad-hoc mesh from forming isolated islands.
We'll see. I'm just starting to work on it and it's only 11 days away.
formatting link
'm trying to bite off enough to be interesting but not so much that I end up having to deal with lots of extra equipment, writing software from scratch, bailing at the last minute, ...
I had found a page on voip-info.org about being able to configure Asterisk to set up a call between SIP devices and then get out of the way, leaving them to speak directly to each other. I was thinking that would be a start, but...
Ah ha! That would be *wonderful*. Any idea if that's supported on Cisco 7940s?
Oh, it's a perfect solution! I assume I can even use speed dials to make it transparent.
It *is* easy. Well, for me, after playing with it for a long time it's easy. I'm using OLSR. There's even an OpenWRT package for it. I set it up last night with five devices (including my WRT in my car in the driveway) and walked around the neighborhood with my pen tablet. Geeky fun!
Oh, there are certainly non-trivial problems to overcome with mesh networks but for a small example like this I think I'll be o.k. I will probably try using CTS/RTS to deal with hidden nodes. It'll be interesting to see how a SIP session survives.
There is nothing like a bit of pressure for getting the creative juices flowing. ;-)
Sorry, I don't know much about the Ciscos. They were always way too rich for my blood. (The ones I looked at were $350 w/o SIP firmware.)
If the connectivity between nodes is generally good, you should be ok.
What the MIT folks found is that the nodes in their northern Cambridge mesh had a tendency to form different BSSID networks even though their SSID's were set to the same value.
from: grid:bac-meng.pdf p.48
BSSID partitioning
When 802.11 interfaces are put into Ad Hoc mode, they go through a somewhat complicated pro cedure to join what is known as a Basic Service Set, or BSS [11]. A BSS is a kind of virtual network; even if two different no des are op erating on the same channel, they will not "see" each other's packets unless they are in the same BSS. Basic Service Sets are identified by a 6-byte numb er known as the Basic Service Set ID, or BSSID, which is transmitted in the header of every 802.11 frame. When an 802.11b adapter enters Ad Ho c mo de, it is configured with a Service Set ID (SSID), which is a string that is intended to identify the network it wishes to join. The adapter then scans through all of the 802.11b channels, listening for b eacons sent by other no des. Beacons contain, among other things, the SSID and BSSID b eing used by the sending no de. If the adapter hears a beacon containing the SSID that matches its own, then it joins this existing Basic Service Set by setting its own BSSID to the one received in the beacon.
If the adapter does not receive any b eacons with a matching SSID within a certain period of time, it decides that no Basic Service Set currently exists with its SSID. In this case, it sets up itself as a new Basic Service Set by selecting a random BSSID and using that for all of its traffic. Any other no des using the same SSID which start up in range of this no de will hear its beacons and configure themselves to use its BSSID.
This creates a serious problem for an Ad Ho c network. Namely, if two no des start up at different times and are not within radio range of each other, they will start with different BSSIDs and b e on different logical networks, despite b oth having the same SSID. Because 802.11 adapters ignore all frames whose BSSID do es not match their own, this creates a partition in the network and prevents all of the nodes from being able to communicate properly. Ideally, it would be possible to set the BSSID directly to ensure that a given set of nodes would all be able to communicate. Unfortunately, this is not possible using 802.11b hardware.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.