The NapoNet project continues. Kyle Elliott and Ed King, undergraduates at CU, and Matt Hulse, now a graduate student at CU, traveled to the pokiesnzonline.com Napo on June 2nd. The goals of the trip were to check up on the network and perform whatever maintenance was needed, install a new node in the village of Campo Serio, and perform qualitative interviews with users of the network.
Here are a few pictures pending further updates:
There is quite a lot of hardware out there for physical handsets. This post assumes we’re going with a physical handset as our on-site device. As alternatives to handsets, there are many free softphone applications (VoIP-app that runs on a computer) if there are PC workstations to piggyback off of for no additional cost. I believe we still need to come up with a performance specification for exactly how many handsets we’d want at each site and why. But here’s a summary of some initial digging:
There is a huge list available from VoIP-Info.org located here. I’m working my way through a thorough follow-up of every link (finding some dead ones too) to get a full list of budget phones. In terms of capability, I want to highlight the following feature v. cost comparisons:
- Hardline v. Wireless: Most handsets connect to the network via an RJ45 jack that we’d run to the local WiFi router. However, wireless 802.11 protocol transceivers would mean not having to lay out a physical network under each tower or each local WiFi transceiver. It’d be an effective “cell phone” for the local site, and likely we wouldn’t require local WiFi routers. Costs are minimum $100 more per unit.
- LAN pass-through: Some handsets have one RJ45, some two. Cost difference is negligible on some models and significant on others. The implication of supporting pass through is being able to support a PC workstation or another LAN device ‘behind’ the handset. This could benefit physical network topology, but only if we’re expecting PC workstations or other devices on the local networks.
- Supported Codec: Asterisk or FreeSwitch will support a multitude of codecs, I’m not going to focus too hard on which codecs handsets support until we come up with a performance/estimation matrix and better define our bandwidth and user requirements.
- Supported Protocol: The most common protocol supported by handsets is SIP, which unfortunately is a pain to setup under a NAT network. I’m not exactly sure of the Layer 3/4 configuration of the network and if we’ll have to work with NAT or not, but if we do we could make an early design decision to not go with SIP and rather use Asterisk’s IAX protocol. A much smaller subset of handsets that support this fall in line with our budget considerations as those that support SIP.
Overall, it looks like the “budget” price spectrum for IP phone handsets is between $30-$70 per unit. I’ll continue to work on preparing a list of specific models we should consider for our application. Best;
Cheapest I could find is something like this: Acer Aspire ONE D250-1165 – Atom N270 1.6 GHz – 10.1″ TFT
another useful review site: http://computers.toptenreviews.com/netbooks/
Also, looks like ubuntu and asterisk (or asteriskNOW) will probably be our platform: http://www.asterisknow.org/. Kevin will probably have more on this at the meeting.
There was some discussion at the last meeting about having a computer at each node, but after talking it over with my roommate (big networking guy..) we really only need 1 computer, for the server. All traffic can be monitored (or even capped) with one computer, and that could save us money. That one computer could even act as a router, if need be.
Depending on how we are going to use the existing backbone, we might not need much hardware. This has been explained to me once, and I’m not sure I completely understand it, so I’m hoping Matt (my roommate) can come to our next meeting, but:
Will we have our own, private network? or can we use the existing routers to route calls to our phones? If we want to keep the med and educ networks completely independent (192.xxx.xxx.xxx = med, 193.xxx.xxx.xxx = health), we’ll need our own routers, but if we can modify the existing routers to direct calls to either the health setup (if 192.168.1.1 is called, for example) or our IP phone (192.168.1.2, for example), then we don’t need additional routers..
just wanted to get ideas down here. we can talk more at the next meeting.
[Devin: You might know this already, but to make links with descriptive anchor text you can click on the button with the chain on it. - Brian]