One of my major mania’s is catching on. Josh Richards just blogged about trying Askozia on an H-P T5700 thin client. These are great little devices. I was so lucky to stumble into a source about 18 months ago. A major corporate concern was about to pay to have a few boxes of these little wonders “recycled” by Dell. A friend and I intervened and relieved them of that necessity.
At present I have three of these running in my home office.
Astlinux 0.48 in production
An Askozia testbed
FreeNAS with SlimNAS
With a 1 GHz CPU and 256 MB RAM (more if you upgrade the one SODIMM ) they are reasonably powerful, certainly enough for a small Astlinux or Askozia installation.
The third unit is perhaps most interesting. FreeNAS is a NAS software based upon FreeBSD and the m0n0wall framework. Like m0n0wall it’s simple, just enough to do what you need and not a lot more. It runs great on the T5700. However, a NAS needs storage, a lot of storage.
The T5700 has an internal IDE connector that’s fitted with a 256 MB flash disk-on-module (DOM). You could swap that our for a 2.5″ HD with the right sort of adapter, but laptop hard drives have high $/GB and less than ideal MTBF.
The T5700 also has a number USB ports but these are USB 1.1…less than ideal for interface to portable hard drives. I was able to find the optional expansion chasis on Ebay for $20 each. This lets them take one standard PCI card, in my case a 4 port USB 2.0 card. Then I could connect a couple of external hard drives and…voila…cheap, silent, spacious NAS…with software RAID if you like.
One of the major uses for NAS around my home is music. I have a couple of Slim Devices Squeezeboxes as music playback for the home and office. These are outstanding devices! Truly change-your-life gadgets. They connect to your stereo and stream music off a PC server running a Perl based server software. It just so happens that Michael Herger has created a package called SlimNAS that installs the Slim Server software into FreeNAS. So this little box not only stores the music, it serves it up as well. All in <10 watts.
There in one little gotcha. You can set the BIOS to boot from a USB port, but it will only boot to the devices on-board ports. It won’t boot to a USB 2.0 port on a PCI card. This is minor. I built a 1 GB thumb drive with FreeNAS and SlimNAS, then added a pair of 250 GB HD in USB portable enclosures that I had sitting around. That’s 500 GB of RAID 0 or 250 GB of RAID 1 storage. Total power consumption < 25 watts. Ambient noise contribution to the room…none.
During the VOIP Users Conference call on December 14th someone made some claims about the ability to handle G.729a encoded calls on various platforms. The comments revolved around the significance of cpu cache when dealing with the G.729a codec. Also some claims of the ability to deal with very high numbers of calls. The claim about the numbers of simultaneous transcodes possible were troubling to me.
G.729a is one of the more complex codecs in the VOIP universe. It puts considerable load on the CPU of the system that must for whatever reason transcode the call. In particular it’s FPU intensive. While CPU architectures are deeply interesting to me, suffice it to say that on some hardware platforms floating point operations are amongst the slowest operations that a CPU may perform.
Of course transcoding is not always necessary. A call may be placed from a phone that is itself G.729a capable, through the local Asterisk instance to an ITSP and on to the recipient…all of which are also G.729a capable. The call can thus be made without any transcoding at all. However, at any point along the path the a stage may not accept G.729a stream and so the call gets transcoded into something more acceptable, perhaps G.711 or GSM. Most typically calls that get routed to voicemail are transcoded to G.711 for the VM subsystem, although not always. Asterisk always transcodes into G.711 for MeetMe conferences.
I know for a fact that the Soekris Net4801 embedded platform can handle two G.729a transcodes when suitable licenses are installed. I used this very arrangement for over a year, and even wrote an article about it here.
The Net4801 features a National Semiconductor Geode SC1100 CPU running at 266 MHz with an unspecified amount of cache. When I first started using G.729a on the Net4801 I inquired with Kristian Keilhofner, the lead author of Astlinux, about his experience with the board. Kristian told me that 2-3 simultaneous transcoded calls was the most I could expect due to CPU limitations. My own experience supports his assertion.
More recently I’m using a HP T5700 thin client which features a Transmeta Crusoe CPU running at 1 GHz and with 512 kb of L2 cache. Under test conditions I’ve had four G.729a transcodes ongoing on this platform, but my test was limited to having only four licenses installed. I suspect that it could handle a few more channels, but the CPU use with even four concurrent channels points to a hard limit perhaps around 10 channels. I may well test this myself some day soon should the need arise.
Finally, Digium’s TC400b PCI card is specifically built to accelerate transcoding and offload that task from the host CPU. According to Digium, “The TC400B is rated to handle up to 96 bi-directional G.729a transformations or 92 bi-directional G.723.1 transformations.” If this is the stated capability of their accelerator then it seems unreasonable to expect similar or greater performance from a small format embedded platform, whatever the CPU cache might be.
The statements mentioned previously indicated the potential for a dramatically larger number of transcoded calls than would seem to be possible on the given platform. I find this unlikely on the basis of personal experience, the opinion of others whom I respect and Digium’s own statements about their transcoding hardware.
If you need transcoding capability on a low cost embedded platform it can’t hurt to consult with sources you trust. Ultimately you should conduct your own testing to be certain that the hardware supports your requirements reliably under real-world circumstances.
When it comes to holiday gift giving my wife has to ask me for a list. Otherwise she knows that she has no hope of getting me anything techy that I’ll actually appreciate. In some ways, for those of us steeped in technology, buying a gadget is a deeply personal thing.
I’m an unabashed VOIP fan. Add to the mix the fact that I travel quite frequently. The conjunction of these two facts brings to light one of the best purchases I’ve made in the last couple of years; the Polycom C100 Communicator. A great holiday gift idea.
This little USB speakerphone device is really very good. I’ve tried several and it’s by far the best of the bunch. At around $120 USD it’s not the cheapest, but it’s not the most expensive either.
I tend to use it with X-Lite, Gizmo and (gasp!) Skype. It’s really just a USB audio device so it should work happily with all soft phone clients, even TringMe and the like.
The USB cord is attached, which is a bit of a drag, but it winds into a storage area located under the device when the pop-out stand is opened. The design is very nice. The device is physically robust and should suffer many accidental indignities without breaking.
The audio quality is excellent, just as you would expect from Polycom. Supporting their HD Voice technology this is about the cheapest way to try the new G.722 codec for wideband audio with 22 kHz sampling.
For the person giving the gift it’s merits are many. It only comes in one size, although several colors. It’s small enough to be inexpensive to ship (or fit in a computer bag) and of course, being from Polycom, it’s an indication of your good sense of taste, and concern for quality.
I’d post a link to an online e-tailer, but these are generally available and I don’t feel the need to drive traffic to any one particular source. I bought mine at a brick and mortar retailer, The Micro Centre, simply because it was on the shelf and I was standing right there. Just Google it.
Of course, you can always add it to your own list. You can’t go wrong with this device.
I was trying to not write this, but week upon week the trouble persists, and my search for a cordless phone continues ad nausea. This entire story I’ve now told to several people who hazarded to ask, “what’s wrong?” So now I write just to stop my hands from shaking, that I may eventually rest.
I need a cordless phone. Full stop, let’s consider that fact for a moment. Working in my home office, when home at all, I frequently attend long conference calls, or provide deep tech support and diagnostics via phone. I can spend a lot of my day on the phone. This is part of what drives my earlier assertion that “Life’s too short to use a cheap phone.” Call me a phone snob if you must. I don’t care.
Here’s the next fact of the case. I’m an early adopter. I buy stuff early in it’s life cycle just because it looks like it might be cool. Sometimes it is cool. Sometimes it isn’t, but with guidance it gets there. Other times it just doesn’t live up to its promise, and we move one having learned some lessons. Early adopters spend more than most to be early in the game…those of you in manufacturing take note.
Returning to my original statement. I need a cordless phone. Cross that fact with the fact that I have Asterisk in-house, as well as hosted PBX via my employer. So I can be more precise….I need a SIP cordless phone.
VOIP Supply lists no fewer than 12 SIP WIFI phones. You’d think that one would meet my needs. And you’d be wrong. Further, I’m betting if they don’t work for me they won’t satisfy the bulk of you either. So why are so many manufacturers bothering with Wifi SIP offerings? And where are they going wrong?
Let me say that I’ve definitely put my money into this quest. I bought a Hitachi Cable WIP-5000 directly from the importer when they were just being rolled out in the US. I paid over $350 for that device, more than any other phone I’d ever bought at the time. Even more than any cell phone I’d owned. It looked promising so I made the investment in both cash and time.
After four months using the WIP-5000 I put it back in the box and used the magic of E-bay to deliver it to a new home. Why? There are a lotta reasons;
1. Volume too low
Both in the handset and when using an earpiece. And I work in a relatively quiet home office. How anyone could use that phone in a busy office I’ll never know.
2. Battery life too short
A simple problem. I got about 2-3 hours talk time or 36 hours standby time.
3. Coverage too unreliable
Using common wifi APs, that is the <$100 devices as opposed to Cisco AiroNet, wifi coverage was not consistent enough to sustain a call more than about 10 yards away from the AP. I use two APs to provide coverage across our property. The WIP-5000 could not hand off from one to the other while sustaining a call.
These are the technical reasons why the WIP-5000 didn’t meet my requirements, but there are underlying design considerations that go unspoken as other manufacturers have rolled out more and more wifi handsets.
Now Hear This!
A cell phone is not the ideal form factor for a cordless phone!
Wireless <> Cordless!
If you look at essentially all the wifi sip handsets being offered they all presume that a cell phone is the ideal form factor. Some even go so far as to mimic the clamshell designs. For dedicated wifi sip handsets this is simply wrong. Wrong in so many ways.
* Buttons too small
* LCDs too small
* Limited access to PBX features/functions
* strange power connectors
* No integration with contact lists from server
* No belt clip
* etc, etc.
To illustrate my point lets consider one of the most successful companies in the corldess phone space, and a product that I once used (and loved)…Panasonic’s KXTG-4000 KSU system.
This was a great system for SOHO users. It had 4 FXOs, supported 8 cordless handsets, which were available both in handset and deskset form factors. So smart! Why did I love thee so?
* The handsets are large-ish, with buttons big enough to find while fumbling one-handed.
* Common pbx functions like hold transfer & redial each have dedicated buttons.
* Long range, as much as 100 yards
* Battery life is long, and the battery is end-user replaceable.
* There’s a belt clip, big enough not to let go if I bend over
* Durable, handles being dropped fairly well
* A standard wired headset jack
* Caller log & stored number directory are easy to use with a minimum of button presses
* Stored number directory can be sync’d from the base to the handset and vice versa
Now it wasn’t perfect. As a 2.4 GHz device it didn’t interact well with wifi networks. This model was replaced with a 5.8 GHz model that was a better fit into wifi enabled facilities.
Has anyone even noticed that Panasonic has a long and successful history in the cordless phone business? Does anyone even acknowledge that as a business, one that’s very different from the cell phone business?
The nearest thing to this in a SIP phone is the Aastra 480i CT, or the newer 57i CT. I bought a 480i CT which I really do like a lot, but its portable handsets are very small, with no dedicated keys at all. It’s a great SIP phone, but the cordless units are much less than ideal.
It’s worth noting that the Aastra phones are not wifi devices, they’re DECT based. DECT is a European standard in the 1.9 GHz band that was only recently adopted in the US. As such, these devices are wifi friendly. They also have reasonable range, easily comparable to my old Panasonic KSU.
I’m almost embarrassed to admit that I once purchased an Engenius long range cordless phone. At the time these were the very best option for commercial installation. Notice how the handset looks like a mid-1990s vintage Nokia cell phone? As far as I can tell this was when the cordless phone world turned the corner, in the wrong direction, and started trying to mimic cell phones.
This device worked as promised. And when used with an ATA it handled basic calling adequately. However, an ATA and a traditional cordless cordless phone puts the burden of accessing pbx features into the dialplan. You have to code all the different functions that would be natively appearing on a genuine SIP device. So that’s a double whammy, no dedicated button, and non-standard dialing to access PBX functions. Deduct several million points for usability.
In the end I stopped using this device because of short battery life and poor audio quality. It had a NiMH battery that suffered memory effect, and no upgrade path to a Lithium Ion power source.
This product is now defunct, but their current offering is a SIP wifi handset…with tiny little buttons and little or no access to pbx functions.
Sadly, this new device is essentially the same as the handset being offered by 3 Network in the UK, and known as the “Skype Phone.” It seems that there are only a few designs floating around Asia being branded by various companies in The West.
In part 2: Surveying the DECT SIP landscape, Polycom/SpectraLink, Aastra SIP-DECT & the new SNOM M3
a.k.a. The logic behind the third Asterisk in my home office
I work from a home office. I have for over 10 years. About three years ago I gave up my last land line and went 100% voip. Since then I’ve had an Asterisk server in my office.
At first I ran Asterisk on Fedora Core 2 using an old P3-800 Dell desktop. But I quickly found that I wanted more of an embedded approach, not unlike the Asterisk appliances that have become popular of late. I soon arrived at Astlinux as the preferred approach for my needs, most recently running on a recycled HP T5700 thin client. Low power. Low heat. Silent. Reliable. Great!!
A couple of months ago I read about Askozia, a project that combines FreeBSD, the m0n0wall GUI framework and Asterisk. As a long time fan of m0n0wall I thought that this could finally be something to rival Astlinux. Astlinux has only the most basic GUI. Since my configuration is not complex a GUI might be useful. To test Askozia I used another HP T5700 thin client device…that’s two servers running. To this point it looks interesting but I’m not yet certain that I want to put it into production use. I need more time to become familiar with its operation and administration.
Of course I also added a number of phones and a couple of ATAs over time. In picking my favorite phone I find myself torn between the Polycom IP600 and and Aastra 480i CT. There is no question, the Polycom is a GREAT phone. But the Aastra is just about as good…and the cordless capability is simply wonderful! It lets me wander around while on long calls, tend equipment, get coffee, etc. The backlit display is really handy as well.
Well, my employer in evolving their US operation decided that a hosted virtual PBX approach would be most ideal. It would tie together our two formal offices with a handful of home offices in a cohesive manner. We selected Junction Networks OnSIP service as the provider and I was given the task of setup and administration.
Junction Networks has been very good to work with. The service has been reliable and they provide good support for common voip devices, including Polycom phones. However, they don’t directly support Aastra phones. They did offer to help me investigate making the Aastra work with their servers, which are a combination of SER and Asterisk.
For a couple of weeks I tried various settings but I couldn’t quite achieve voip nirvana. The best I could do was make the phone use their proxy and register for a few minutes. But eventually the registration would drop and I would stop receiving incoming calls. So for a few months I went back to the Polycom device as my primary phone. It’s ok, but being tethered all the time is becoming a real drag.
So I decided to look for an out-of-the-box solution. I bought a GN9350 DECT cordless headset. It connects to a Polycom phone inline with the handset RJ connector, or to a PC via a USB connection. For some reason the GN headset was really noisy and induced a lot of echo into conference calls. It was simply unacceptable so it’ll be set free through the magic of Ebay some day real soon.
Which brings me to my current solution…I’ve built yet another Asterisk server with a minimal configuration that just bridges the Aastra phone to Junction Networks. Junction Networks supports Asterisk directly, even providing me solid config examples. I just got this working but it looks good so far. So my Aastra phone is about to make it’s way back onto my desk. I’ll be unwired again, which will be great.
The one issue I’ve yet to figure out is voicemail. When the Astlinux server access an incoming call from Junction Networks they figure that the call has been completed, even though I may not answer my phone. So I suspect that VM will have to be handled locally.
My primary server still handles our home line and variety of supplemental services like FWD, SIPPhone, etc. Several phones deal with Junction Networks directly. And the Astra 480 has its own Asterisk instance just to allow it to deal with Junction Networks. Then there’s an Askozia testbed.
I suppose I could merge many of these functions onto one server…but there’s no real reason to do this. It may be better to keep personal traffic separate from business calls.
Who might have thought that I would be using three Asterisk instances in a one man office? Certainly not I. Luckily each runs on minimal hardware with essentially no hard cost. Oh, the joys of Asterisk.
Following up on the question I asked last week (Nov 9) about QoS/traffic shaping, specifically comparing a vlan vs IP range based strategy. My issue stems from the fact that I’ve added a number of new voip devices to my lan over recent months. Some of them run through one of the now three(!) Asterisk servers I presently have running, while others connect to external hosts directly.
Previously it was easy to dedicate highest priority to traffic to/from the one Asterisk server, since all voip traffic passed through it. But that presents problems when there are other phones need equal access to bandwidth, and those devices use several different external hosted PBX services. Of course, I’m on a humble 1.5M / 786k ADSL connection.
With some guidance from the m0n0wall users list I am trying a simple traffic shaping arrangement based upon IP address ranges. This required that I come to know a bit more about CIDR notation for specifying subnets.
Within the routers traffic shaping mechanism there are a number of pipes fed by queues. Each pipe has as weighted traffic priority. There are separate paths for inbound vs outbound traffic. Traffic can can be directed into a specific queue or even to a pipe directly. Which queue or pipe it goes into determines its priority traversing the router. By going directly into a pipe, bypassing the associated queue, you can also minimize latency for specific types of traffic.
The traffic shaper allows a subnet, as specified using CIDR notation, to be passed through a specific high/medium/low priority path. By assigning my voip devices (192.168.1.128/25) to IP addresses conveniently separate from non-voip devices (192.168.1.1/25) I give priority to traffic from a specific range of devices.
For the CIDR challenged (like me) :
192.168.1.128/25 = all addresses 192.168.1.128 to 192.168.1.254
192.168.1.1/25 = all addresses 192.168.1.1 to 192.168.1.127
I am in the habit of letting all my devices DHCP and using MAC based IP assignments in the DHCP service, so changing the IP addresses of the voip devices was really easy and took only a few minutes to implement. It took less than five minutes to make all the changes in the router and it seems to be working perfectly for now.
If there are any problems I’ll try the vlan method.