charlotte's blog

Some of you may have seen the press release from Microsoft announcing the release of the Response Point PBX and the role of Junction Networks as a preferred service provider.

Our favorite write-up of the partnership was over at Asterisk VOIP News, though that may be because they included a glowing note from the editor about the reliability of our service.

We tested the Response Point in our labs, of course, and found the setup to be almost ridiculously easy. The test network was set up and ready to go within 30 minutes of unpacking the box the system came in. Most of the Response Point customers that we've spoken to report a similar experience. The Junction Networks configuration can be downloaded from within the Response Point interface, which further simplifies the setup. Response Point is ideal for a 1 - 50 employee office with a set location and is geared to the non-technical administrator. The Response Point is a PBX, however, and the phones are "dumb", so they have to stay on the same LAN as the Response Point. If you like to move your phone around to locations all over the world, you'll probably be happier with our OnSIP Hosted PBX service.

We've put up a Knowledge Base article as well.

We've had a really busy week in the Junction Networks lab. We've started a testing program for some of the routers out on the market so that we can come up with some solid recommendations for routers that are known to work well with our network. (Alas, not all routers are created equally.)

The main rule is that the router needs to not interfere with SIP. Specifically, we need routers that don't rewrite SIP packets, because we do a fair amount of work in learning about the network that a packet comes from in order to route and transfer calls properly. When a router rewrites the packet its sending us, we start to see problems, because it's essentially lying to us about the network behind it.

One trend that we're seeing with router/firewalls (which for the SMB market are usually the same device) is the introduction of the Application Level Gateway. An Application Level Gateway does what it sounds like it does - it rewrites packets based on the application and hides the NAT, with the idea that this helps certain programs work with fewer problems. Unfortunately, in all the of the ALGs that we've seen so far, SIP packet rewriting is turned on by default. This means that we can't properly detect that NAT that the phones behind the router are on, which causes problems with call transfers.

One dead giveaway of this behavior for our OnSIP Hosted PBX customers is in the admin interface. If you look at the phone registration for a user, you'll see "NAT not detected" in red letters. This is almost always caused by an ALG.

The solution is to configure your firewall to remove the ALG for SIP. We're going through a series of routers in our testing and have found only one router that didn't have this functionality so far, but we resolved it via a firmware upgrade. Keep your eyes peeled to our Compatibility Guide for more information. We'll be updating it in the coming weeks with more details. We even have a new section in our knowledge base with information on how to turn off the ALG for routers that have made it through our labs.

We've been testing the Polycom IP 560 and the IP 320. These are really great phones - they came through all of our testing with flying colors, which didn't surprise us very much, since Polycom makes some of the most reliable SIP phones on the market.

The IP 320 is a great convenience phone and could certainly also work for most users, although the small screen makes it less ideal for heavy phone users. The functionality is all there, despite the smaller screen size. For a full feature set, see Polycom's spec sheet.

While the IP 320 is a nice phone, the IP 560 is the phone that really stole our hearts. It's an attractive phone, with a backlit screen that makes a nice impression. It is also, interestingly, capable of high definition voice. We were skeptical at first, but when we tried the feature out, we were all very impressed with the sound quality. Getting a high definition call is a little tricky, since both parties must have HD voice capable phones and it must be an Internet-only call (as soon as the call hits the PSTN, it's down sampled), but it's very impressive when it happens. The call quality is definitely superior to any other phone call that we've heard before and is close to stereo quality. We're big fans of the feature and are looking forward to the day when most calls are Internet-only so that it can become more common. OnSIP Hosted PBX users can take advantage of this on their internal calling and on Internet-only calls by buying HD-capable phones. It is definitely nifty.

On the downside, Polycom hasn't made much progress in making the phones boot faster, which we were hoping for. Still, a slow boot process is a small price to pay for the reliability and functionality of these phones.

The potential of IP telephony is, of course, very cool. But one concern that the industry buzzes about is SPIT - SPam over Internet Telephony. As with every IP service, spam is a real concern, although SPIT hasn't taken over to the same level that e-mail and blog spam have.

A SPIT spammer uses a VoIP system to make hundreds of unsolicited, pre-recorded phone calls. This seems like a telemarketer's dream, of course, but it has bigger concerns since it can easily be used for illegal activity, such as tricking the recipient into punching in a credit card number that can then be stored on the computer that placed the call. In my opinion, it is the use of VoIP for illegal activity that is the real concern. Although telemarketing is unpopular, it's a legal practice and VoIP doesn't give telemarketers the ability to do anything they aren't already doing - it just lowers the cost of doing business.

Many of the countermeasures that are suggested as ways to combat SPIT will be familiar to the technically savvy; whitelists, blacklists and greylisting, audio captcha and setting up phones to act as honeypots and create centralized blacklists of phone numbers. Although somewhat trickier in the telephony world because of the expectation of the end user to be able to call any number at any time, if properly applied, these countermeasures should not affect using the phone any more than current e-mail spam countermeasures do.

As VoIP attracts more and more market share and networks switch from hybrid environments to pure IP, it will become more attractive to spammers. But sending a million SPIT messages requires more resources than sending a million e-mails does, so hopefully it will be a good long time before we see the same proliferation of SPIT spammers that we see on the rest of the Internet. When that time comes, the industry is far more prepared than it was when the first e-mail spammers hit the 'Net. After all, we've seen this before.

To add to our growing list of phones that have gone through the Junction Networks lab, we've been testing the Grandstream GXP 2000 and the GXP 2020.

These attractive phones offer a budget conscious buyer a solid entry point for VoIP hardware. Both phones have a nice corporate look to them. The user interface is simple and well-designed and the menu system on the phones is one of the better ones we've seen. One of the things we really liked about these phones is that the IP address is displayed on the LCD, so doing the initial configuration is even easier. These are good phones for someone whose primary job function is not the phone, but advanced users are likely to have some frustration with them. We ran into a few problems, which in the interest of full disclosure, we have to mention here.

Initially our testing was stalled because calls did not seem to be hanging up properly. Test Phone A called Test Phone B. Test Phone A hung up the call, but Test Phone B went into a fast busy state until someone reached over and manually hung up the call. After working with the friendly folks over at Grandstream, we tweaked a setting (the "turn off speaker on remote disconnect" setting) and that resolved the issue. Grandstream assured us that this was intended behavior, but we wished that the configuration would default to hanging up the phone without manual intervention.

Our second issue was that we initially had some trouble figuring out how to do an attended transfer. We're apparently not alone - as some helpful soul made a YouTube instructional video to explain the process. After practicing once or twice, we got the hang of it, but it's not nearly as intuitive as other phones we've tested. The phones also do not allow for attended transfer with early completion (transferring the call to the second party while the second party's line is still ringing). The transfer option does not become available until after the second party has picked up the line, which certainly can be a business issue. Transferring has been a sticky issue for Grandstream in general, but we were hoping to see more improvement.

If you are using these phones, we've put up a configuration guide for their use on Junction Networks. We'd love to hear your experiences.

Today was another exciting day at the Junction Networks lab - we put the Linksys SPA962 and the SPA942 through our testing and are pleased to give them our endorsement.

We also really like the color screen of the SPA962 and spent entirely more time than was necessary adjusting the picture. While it ships with a default picture of the San Francisco bay bridge, we thought it should have the OnSIP Hosted PBX logo, so we changed that.

Otherwise, the testing for these phones was absolutely delightful - everything just worked, with the one exception that we had to map *98 to the voicemail button.

All in all, we happily give these phones our endorsement. Particularly since the SPA962 with its pretty screen will be my new desk phone...at least until something cooler comes along.

Last week on the subway, I saw an unintentional but interesting social experiment. I was outside the turnstiles where you swipe your ticket to pay for your ride. Someone had left the emergency exit door wide open and there were no transit employees around. Here was a perfectly easy way to get a free ride off of the subway, but it would involve breaking a minor law.

As I watched my fellow New Yorkers scope each other out to figure out who would be the first to go through the door (because as we all know, it's not really breaking the law if it's done in a group), I walked over to the turnstiles and paid for my ride. Most people did the same thing as me, but finally, one person walked through the open door.

After that, everyone walked through the open door. After all, the door was left open.

One thing that surprises many of our customers at Junction Networks is that we have a policy of calling to verify financial information. We do this to protect ourselves, of course, but we also do it to protect our customers. With the anonymity of the Internet world, security is such a strong concern that every employee of Junction Networks is responsible for keeping an eye out. When we find stolen credit cards being used, we follow it up and alert the owners of the cards. We've helped people discover when they've been the victims of identity theft, which does make us feel good. We can't keep the baddies from stealing credit cards, but we can create at least one network where they can't use them.

We like to make sure our doors are locked - it's better for us, of course, but it also makes a better Internet.

As those of you who read our newsletter already know, we've begun running Freeswitch on our production network. We're currently using it to power our conference bridge servers and we're very impressed with it.

Historically, Asterisk hasn't had a great track record for conference quality, due to its dependence on the ztdummy timer module. We had fairly poor experience with it, specifically with the quality of the conference bridge degrading over time. Seeing that we had to do something about our conference bridge, we went and tested a few different things.

First we tested Asterisk with the app_conference module. We skipped right over the Meet Me conference module because it still relies on the ztdummy timer. We hear that it's been improved, but decided it was more worth our time to investigate software that approached the problem from a different direction, which app_conference does. We were pleased with app_conference and found that the quality was greatly improved over our previous experience with Asterisk, but it doesn't have a lot of the functionality that we were looking for in a professional grade conference bridge, such as join/leave sounds, music cues and background noise reduction. (For a full list of functionality, see this matrix.)

But, being huge fans of open source development, we wanted to give Freeswitch a try, even though it is still in beta. Since it is a beta project, getting it up and running had some challenges, but after we started working with it, we really liked it. The conference bridge has the functionality that app_conference lacked and it has some exciting features that we really liked. The ability to mute speakers on the fly is entertaining....but bridging two conference bridges together has even more serious appeal. We've also been recording some internal conferences, which is a handy feature. The problem with sound quality degrading over time that we saw in Asterisk 1.2 was no longer an issue.

We've been using Freeswitch happily for months now and suspect that it will be giving Asterisk serious competition in the near future. We're looking forward to the release of version 1.0, which is scheduled for next Monday, May 26th.

And, of course, our PSTN Gateway service has been tested and approved by the Freeswitch community for interoperability. Freeswitch, we like you too!

This spring, I started seeing an ad campaign on the subway about how using public transportation reduces your carbon footprint. And then last week, when I was reading the last edition of the This Old House magazine, I saw the phrase again. As gas prices rise and the summer heat (and haze) set in, I suspect we're going to continue to hear more and more about it.

A carbon footprint, if you haven't run into it, is the measure of carbon dioxide produced by human activity. It's a method of figuring out how much an activity contributes to global warming. If you want to measure your carbon footprint, which is mostly caused by transportation, you can find one of many online carbon footprint calculators to figure it out.

Before I lived in New York, I commuted 20 miles each way to work by car, putting about 10,000 miles/year on my car and, more importantly in terms of carbon emissions, emitting 4.3 tons of carbon dioxide into the environment. I happen to drive a tiny car, but if I were driving a SUV, my carbon emissions for the same ride would be 5.9 tons per year.

Although there's still a lot of talk about whether or not global warming is actually caused by human activity, it's certainly a lot more pleasant to be somewhere without car exhaust, so the less carbon dioxide that we put out into the environment, the better we'll all breathe. Working from home even just one day a week can contribute to the effort, which of course, our service makes easy. On days where I work from home, I fire up Eyebeam on my laptop, log into my OnSIP account and it's just like I'm sitting in the office.

And hey, in the spare time you're not spending on the highway, you can spend some time in your garden - after all, plants are some of the biggest carbon dioxide consumers on the planet.

Today was an exciting day at the Junction Networks lab - we put the Astra 5xi series phones through the Junction Networks interoperability testing and are very pleased to give them our official stamp of approval!

Aside from supporting all of our OnSIP Hosted PBX features, these phones were easy to use and configure. We tested a 53i and a 57i with interoperability to a Polycom 501 and had no problems at all during our many tests. We even upgraded the firmware to the latest available from Aastra's website, which does require that you provide a TFTP server, but was a otherwise fairly simple and well documented process. And for extra points, we also rather enjoyed the LCD of the 57i for its geek chic appearance.

Our preference was for the 57i over the 53i for user interface, but with a little custom configuration of the programmable buttons (done via the phone's webpage), we were able to make it do everything the 57i could. Still, for out of the box use, the 57i may well be worth the extra money -- and it does have that snazzy LCD.

Considering an Aastra 5xi series phone? We've updated our Knowledge Base Aastra configuration article and hope that you'll find it useful.