Greg MacLellan

August 18, 2008

Terminating Network Cables

Filed under: Renovations,Telephony — groogs @ 9:59 pm

After running network cables the next step, of course, is to terminate them.

Using one of the old cabinets that happened to be close to the right size, I built a rudimentary 19″ rack. It’s not too bad for a DIY rack, especially considering a small swing-out metal rack costs around $250.

I basically took an old cabinet, cut the middle shelf out and turned the whole thing on its side. I added another piece of wood from another cabinet on the other end as a mounting location for the rack-mount gear, and I pre-drilled several pilot holes at 1U spacing (to prevent the wood from cracking when putting in screws). I used part of the old middle shelf to build a new shelf to hold my modem, router, VoIP adapter, etc.

I terminated all the cables from the jacks throughout the house onto the back of a 1U 24-port patch panel.

On the main floor I have 12 jacks so far – 2 network + 1 cable in each of 3 bedrooms; 2 network + 1 cable in two separate locations in the living room; 2 network on a wall shared by kitchen/dining room. I probably would have put another jack (and a cable hookup) in the kitchen, except that I plan on doing some major renovations there in the next couple of years, so I’ll just wait, since I don’t need them now anyways.

There are a couple of benefits to using a patch panel for this job. Any “network” jack in the house can be made into either an Ethernet jack, or an analog phone line. Since I use a VoIP PBX at home, I can actually put analog extensions anywhere I’d like, and keep the VoIP adapter in the rack (like the Linksys PAP2 you see on the right). Additionally, I can use PoE injectors (or a PoE switch) and selectively send PoE to ports that need it (eg, have a VoIP phone plugged in).

I can also run different networks to different spots in the house. Most people probably wouldn’t use this, but my main MythTV server (currently in my living room) is also my PBX server, and it has a public IP (VoIP traffic on its own IP avoids QoS issues). I have a hub on my cable modem that splits the connection to the router, and sends another “raw internet” line up to the PBX server (red cable going into the patch panel).

The other end of every connection is pretty simple. I ordered all the keystone jacks, wall plates and patch cables from monoprice.com. The jacks are 1/5 the price Home Depot sells them for, and the patch cables are sold for cheaper than I can buy the parts to make them myself.


March 12, 2007

Two Days to LNP

Filed under: General,Telephony — groogs @ 9:08 pm

Well finally wireless number portability is coming to Canada on March 14th. This means you will be able to transfer your wireless number to wireless another carrier, to a landline, or your landline to a wireless carrier. Transfers between wireless carriers should take 2.5 hours, transfers between wireless and landline could take up to two days, and fees for doing a transfer are left up to individual providers. I haven’t yet found out if transfers from wireless or landline to VoIP carriers will be possible, although I don’t see why it wouldn’t be.

On that note, I recently had to switch my home phone number. It’s not really a big deal since most people call my cell phone anyways, but basically Unlimitel pulled out of operating in Kingston. I am now with les.net (which has a really nice interface by the way – letting you pick and add DIDs to your account in seconds, see your balance, automatically send you a reminder when your balance is low, etc). I looked into porting my number over, but was told that I would be charged a $150 fee to port – I have to wonder if that would still be the case in a couple of days?

February 15, 2007

VoIP, Security systems, and FUD

Filed under: Rants,Telephony — groogs @ 1:31 am

I felt compelled to respond to an article NetworkWorld published (which made Slashdot) that talks about how VoIP and security systems are incompatible (as in home or business burglar alarms), and is apparently based on an article published by CBC. It does raise some valid points, but mostly it is sensational garbage.

First off, as the article correctly points out, VoIP does require power, so if you lose power, then you lose your phone line. This can be dealt with by getting a UPS (battery backup), and in fact, I’ve seen some providers that build batteries in to their modems/analog telephony adapters (though unfortunately, it’s not very common). It’s also true that your broadband connection is probably not as reliable as your PSTN lines – there are simply more things that can go wrong.

However, the article falls apart at this point, and starts arguing about how software changes to the security system could break everything (because on a PSTN they couldn’t? why are you upgrading your alarm system remotely/autonomously?), and how your TiVo, fax machine and conventional modem won’t work. I’m not quite sure what that has to do with security, nor am I sure why you’re using a conventional modem when you have a broadband internet connection.

The CBC article points out that one user went for a year and a half before noticing his alarm didn’t work. This is entirely his own fault. If you change your wiring, your service provider, or anything else, it’s just common sense to test the equipment hooked up to it. Surely if he added a new jack he would have picked up the phone to see if there was a dialtone instead of assuming everything worked. This is above and beyond the fact that most alarm systems suggest you test them at least monthly, ensuring that the sensors and sirens and phone connections are all working.


On a bit of a tangent, I’d also like to note how ineffective alarm signalling usually is: unconfirmed alarms are basically the lowest priority calls police will go on, so they often will not drive to your house until long after the alarm went off, if they even bother to show up at all. Here, the police charge businesses $60 for the second false alarm, $120 for the next, and so on (I’m not sure what they do for residences). Not to say that alarm dialing is useless, because the panic buttons should still get someone there pretty fast (it requires a human, as opposed to a motion sensor which can be a malfunction or pet), but if you think that the SWAT team arrives seconds after the alarm goes off with guns drawn, you’re sadly mistaken.

The best defence is to have neighbours that will hear your alarm going off (loud outdoor sirens help), notice the kids moving your big screen TV into a black van parked in the driveway, and call the police. Or get a big dog.


In my mind though, what these articles are really showing is how far behind the times everything else is. Yes, there are some major issues with VoIP that need to be addressed (911), but the benefits it has (the ability to have multiple phone numbers anywhere in the world, lower cost, multiple simultaneous calls..) are too much to ignore. To begin with, why don’t security systems call in periodically (weekly or monthly) to basically say “I’m alive!”? If they miss their call in, the security company can call the owner and say it missed its check-in. More sophisticated alarm systems usually have a special loop line, where the monitoring center actually sees immediately that they went offline, and can respond appropriately, this would be just a simpler version of that – although no emergency response would be mounted.Going forward, why are security systems still using phone lines? Why don’t they just get ethernet connections, and plug right into your broadband connection along with your PC? This would allow far more capabilities, including the constant monitoring mentioned above (but checking in every few seconds), remote access by the home owner, and the ability of the response center to save some money by ditching their banks of modems and PSTN lines in favour of running a few servers. Same thing goes for TiVos and satellite connections. To migrate existing non-ethernet devices, they could actually make another box that has an fxs port (which looks like a normal phone line to the TiVo) like a VoIP adapter, but actually be designed to emulate the head-end, and communicate via regular TCP/IP over the broadband connection back to the satellite/TiVo’s main office).

Based on the tone and conclusion (“But hardwired land lines seem to be the most solid answer for now anyway.”) of the original article, it sounds more like some Slashdot readers speculated – that the phone company is pushing for this drivel to be published because they’re starting to feel the sting of VoIP on their bottom line. I pay under $10 a month for my home phone service, have all the “features” that cost extra on PSTN lines, and can make multiple calls simultaneously if I want to – even a basic line with the telco is $25+, and if I were to get 4 or 5 lines with all the features active, I would be in the hundreds of dollars per month.

It would be great if the phone companies would leverage their existing (more reliable) network to basically run a second VoIP-only internet alongside the existing internet infrastructure, bringing the best of both worlds together – but unfortunately this will never happen because it would be too easy to use other providers, not pay outrageous long distance charges, etc.

January 9, 2007

freePBX 2.2.0

Filed under: General,Technology,Telephony — groogs @ 2:21 am

I haven’t posted here in a while, so I just thought I’d mention something about freePBX 2.2.0, which was just released a couple days ago. For those that don’t know, freePBX is an open source configuration and web-based interface to Asterisk, which allows you to configure and run a PBX that has the equivalent functionality to commercial PBXs costing several thousands of dollars (or more). I’ve been involved with the freePBX project since December 2004 (when it was called AMPortal, or AMP for short), and minus a 6 month hiatus in early 2006, I have been contributing to the project ever since.

2.2.0 is a fairly signifigant release, adding a fair chunk of new functionality, fixing lots of bugs (over 200) including some long-standing bugs that have been around since the 1.x series. Among these are some bugs in the call handling that dealt with certain situations where you pass a call from a queue to a ring group, or going to a cell phone, and then forwarded back to another extension, etc, that were sometimes causing voicemail to never pick up, and some other strange behaviour. I was busy rewriting the modules API to make everything a bit more solid, and wrote a fancy new module administration interface. I also ported a nice new design done by Steven Fischer, which was a much needed upgrade from the basic look that the interface had from the start. I’ve also written some new modules (announcements, phonebook directory, misc applications, speeddial) and done some work on a half dozen others. Overall, we’re quite happy with this release and definately suggest that anyone using 2.x upgrades.

Going forward, there’s a few things I’d really like to do – write some hooks to use QuickForm, to make writing GUI code a lot simpler; finish my text-to-speech and manualconditions modules (which I’ve started on already); finish the daemon to write config files (instead of having the web server invoke a script); write the framework for a user portal; and add a menu before going to voicemail to allow callers to do various things besides leave voicemail.

Now, if I just had a clone or two that could my other day-to-day tasks like go to work, I would be set.

April 12, 2006

VoIP over VPN improves call quality

Filed under: General,Telephony — groogs @ 10:51 am

I came across an interesting article showing that running VoIP over a (TCP-based) VPN actually improves call quality. This goes against what you would expect – VoIP traffic uses UDP to ensure the least amount of latency, while TCP ensures all packets arrive in order, but means that one holdup can stall the whole stream.

Once they investigated more, it actually makes sense why this happens. The VPN ensures that all packets get there, in order, which yields a better call. What is needed for this is enough burst bandwidth so if a packet is delayed, there is enough headroom to ‘catch up’ to the stream (detect the error, and retransmit enough data to fill the gap). A 64kbps VoIP call takes up about 80kbps when encapsulated in a VPN. Having a 100kbps connection isn’t quite enough, but in the tests 500kbps was enough to improve quality (see the chart). The flipside to this is that on a bad network, nothing helps, which really just seems obvious.

The interesting implication of this is that it’s actually another reason to deploy VPNs to remote workers. Not only is the call now encrypted (something many VoIP protocols don’t do) with proven SSL technology, but it actually helps the quality, provided they have a half-decent connection to begin with.

The other point here is that it’s actually okay to overprovision as long as you have enough burst bandwidth. For example, if you have a 2Mbps pipe, and are serving 12 users from it, they consume just under 1Mbps total. That leaves another 1Mbps for burst capability if any of the streams get left behind, and 12 times more than any single connection requires. (This is of course assuming no other traffic is flowing on the VPN, so adjust numbers accordingly if the VPN is used for browsing, file transfers, etc).

I’d like to see a test done using OpenVPN (they only used commercial VPN products), but it’s clear that it’s a good idea to add SSL. It’ll be interesting to see where this heads: if SIP phone manufacturers will start adding VPN clients or even just SSL transports to encapsulate the SIP traffic. Perhaps even a new TCP-based protocol will be thought up.
digg story