Commentary

Junction Networks has an extensive Articles section. Articles are typically more in-depth than blog posts with topics covering everything from exploring Click to Call to Virtual Receptionists.

Today we posted a new article How Junction Networks Deals with HD Voice. The article details how Junction Networks, as a Hosted SIP provider, deals with HD voice both in SIP to SIP calls and calls to our Conference Bridge application.

Today marks the 134th birthday of the telephone. On March 10, 1876, Alexander Graham Bell shouted into the phone mouthpiece, “Mr. Watson - come here - I want to see you,” [source]. After which, assistant Thomas Watson walked to Alexander and said he heard him.

One hundred and thirty four years is a pretty long time. In the early 1970’s, the cell phone was invented, but didn’t hit the market until 1983 [source]. In the same year, the “first networking protocol used on the ARPANET was the Network Control Program” [source]. However, both the cell phone and the internet didn’t hit mainstream until the early 1990’s.

The telephone was a revolutionary invention in 1876, an accomplishment that will not be forgotten. But, Mr. Reader, come here – I want to show you: If you were using the same transportation system in 1876, you might be driving this:

Our point? Telephone on the Plain Old Telephone Network as we know it is a technology Grandpa. Respect him, but don’t use his gadgets!

After an extensive consulting engagement with our social media marketing guru, we have decided to make an important switch to Cloud Computing. Watch this video to see how we arrived at this important platform choice for OnSIP.

Enjoy!

I am a huge fan of My.OnSIP.com. Ok, yes, I'm supposed to be, but still, I love it. I love drag and drop call transfer. I love that I don't have to remember extensions - I just click on a name to call someone. I can see who is on a phone call before I call or IM them. My.OnSIP.com has given me hours of productivity and saved me untold levels of phone-tag frustration.

One of the harder things for me to give up, however, was my other Instant Messaging clients. On my Mac I prefer Adium and for Windows my choice is PSI. On the iPhone I prefer IM+ Lite and the recently announced Meebo. I have contacts in there from my AIM days, from Gmail and others. When an IM came in, I had to check two different applications to see who was chatting with me.

With the announcement today that OnSIP now supports IM on any XMPP-based application, OnSIP is now VoIP and IM on any standards based app or phone. That means I have the best of both worlds with a unified IM roster of my colleagues here at work (who are using OnSIP) along with my other IM contacts outside of my company (who are not on our OnSIP account). With the new support for XMPP-based apps from OnSIP, I configured my Adium IM client so I can IM everyone in my OnSIP account as well as on other XMPP based IM services. What's great is I have the choice of the most popular XMPP IM clients. I use Adium, but you could use Trillian, PSI or others.

For a true Unified Communications experience, you can use Counterpath's Bria soft phone which allows voice, video, IM and presence all in one application for OnSIP Hosted PBX users. (Config Page in KB.)

Once again, our standards-based/no walled garden approach has paid off for our customers. We have always been committed to customer choice and we believe you should not be told what IM client or VoIP phone you must use. That's why we followed up our my.onsip release with support for ANY XMPP platform. Now, we are working to enable phone status, e.g. "on a call", in other XMPP browsers as well. That is a tougher engineering challenge since there is little standardization for those messages, but we're working on it to enhance the customer experience. We will continue to innovate and change the world of business communications from one of proprietary technologies and walled gardens to one of open standards and open access.

Junction Networks receives a mention in an article in Processor.com, a newsletter for the Data Center marketplace.

I occasionally get questioned about our choice to run our own network and servers when we could outsource it all to a "cloud" provider like Amazon and thus save a lot of money while simultaneously improving the reliability of our service. I hate this question because it is loaded, and I know they are not likely to understand why we can't run on a cloud service no matter how patiently I try to explain the technical issues.

Anyway, Amazon's EC2 cloud systems are now apparently dropping packets and having network latency issues. People running near real-time applications like gaming and VoIP are not having a happy time and they are apparently scrambling all around trying to figure out why their services are going to crap and, all the while, Amazon says there is no problem. I imagine that these folks did not get an SLA from Amazon with respect to network performance.

Whocouldaknown?

Link: Are spot instances killing the performance of Amazon EC2? - Seldo.com

Service outages happen. Sometimes it’s the result of something you did, but more often than not it’s caused by factors completely out of your control. If you’re in the business of providing a hosted service over the Internet, then chances are that this unfortunate situation will happen to you at one point or another. We would all love to say that it has been XX months or X years since we’ve had any problems, but the fact of the matter is that when something like this happens (and it most likely will), what’s most important is how you deal with it.

Now we don’t know exactly what occurred but from what we’ve heard and read (there’s quite a bit of chatter on Twitter from actual packet8 customers), it seems like Packet8’s customer service/response during the outage was a bit iffy.

We had a little outage ourselves last year and we dealt with it by putting up multiple posts on our blog, posting regular updates to keep our customers informed on Twitter, and responding quickly to any questions. It was vital for us to keep up a constant stream of communication with our customers to let them know that we were doing everything in our power to get things back up and running. In this day and age, there’s little to no excuse for leaving your customers high and dry, especially when they need you the most.

After our outage, we put up an explanation of exactly what happened and everything we were going to do to prevent it from ever happening again. Industry analyst Gary Kim specifically mentioned us on his blog in a post entitled, ‘The Way to Deal with an Outage'.

I’m not going to sit here and tell all the Packet8 customers reading this that we’re going to be outage-free for the next 10 years. We can’t promise that. No provider can.

What I will say is that as a company, we’ve always prided ourselves on our customer service and that will remain the same, whether everything’s running at 100% or not.

e-Week is reporting that Google has big plans for VoIP in 2010. This is great news. Really great news. SIP-enabling Google Voice a la Gizmo5 would be a huge shot in the arm for SIP, solidifying its appeal to the masses. However, it still does not address the needs of business customers. Small and medium businesses are flocking to cloud computing in general and hosted VoIP specifically, but Google Voice is ignoring this segment of the market completely. Here are the top three reasons a small business should use the OnSIP Hosted PBX by Junction Networks instead of Google Voice:

Extension Dialing
SIP addresses are great. Mine is sip:mike@junctionnetworks.com. Put that address into your phone and my phone rings. Very cool. The problem is that business desk phones are still number pad based. If I want to call another Junction Networks user, it is far easier to dial their extension - which our system translates into a SIP address behind the scenes - than it is to type their SIP address into the phone via the number pad. For a business to use a VoIP system as an internal PBX, you must have extension dialing. Google Voice has no support for extensions. Currently, to reach a Google Voice customer you must dial their phone number. With the integration with Gizmo, that will expand to SIP addresses, but still no extensions.

PBX Functionality
If you have only one or two people in your company, then Google Voice is a good choice; mainly due to its cheapness. However, once you have five or more, you'll need services like attendant menus ("Hello, welcome to Acme Corp, press 1 for sales and 2 for customer service."), voicemail boxes, and dial-by-name directories. None of these features are currently supported with Google Voice. By contrast, the SoHo package of the OnSIP Hosted PBX includes three Attendant Menus, three ring groups, five voicemail boxes and one dial-by-name directory. That's everything a small business needs to get started.

Integration with Google Voice
Most VoIP providers make their service a walled garden. You may or may not be able to call outside SIP addresses, but very, very few allow you to add external SIP address to the PBX. OnSIP is different. We allow you to put external SIP addresses into your PBX and fully integrate them, even to the point of giving them extensions and using them in applications like the attendant menu. In this way, you can integrate Google Voice users into your corporate PBX. For example, if you have freelance developers with Google Voice accounts and SIP addresses, you can add them as extensions on your OnSIP Hosted PBX and get the best of both worlds.

To be fair, Google Voice is not targeting the small and medium business. Their purchase of Gizmo5 clearly shows that they are going after the Skype market. But the fact that they will be giving out SIP address further validates our reliance on a full integration of SIP. We are always happy to see big players adopt SIP.

There is no easy way to say this. Starting Friday November 13, 2009, calls to these seemingly free conference services and other reverse billing services will be charged at $0.50 per minute.

Starting Friday November 13, 2009, the affected rate centers are:
(712) 432-xxxx and (712) 338-xxxx

The Problem:

Calls to these rate centers are 20 times more expensive than a ‘normal’ call. Junction Networks cannot afford to subsidize these services and at the same time maintain our competitive pricing. We have only two options available to us – block calls to those numbers or charge the true market rate. We have chosen the latter.

The exposure of the reverse billing services has been in the news quite a bit lately. Some carriers have chosen to simply block these numbers. Speakeasy has an extensive list. Even Google has apparently noticed the same issue.

How do I turn on/off the ability to make these calls?

Junction Networks customers have the ability to turn on/off access to any call costing more than $0.029/min. Currently, unless you have filled out our Extended Dialing Form, access to more costly calls is turned off by default.

As we do more analysis of our bill, we expect to fine-tune the affected rate centers. Please see our full pricing schedule.

We know this will affect a number of our customers, as well as Junction Networks, as even we have been using these ‘free’ services. We expect that, as other carriers are handed large, unexpected bills, they will also be forced to pass on the true costs to their customers, or simply block access to these services. Eventually, the entire carrier compensation program that has been in place for decades will be challenged and likely overhauled, thereby ending the loophole that has allowed ‘free’ conference calling to exist. If and when rates to these calling areas return to normal, we will return to our standard $0.029/min for the affected rate centers.

As always, we appreciate your business and we do sincerely apologize for any hardship this may create. However, for Junction Networks, the economics are unsustainable.

We do sincerely apologize for this service interruption. We know that you have many choices for your phone service, and we deeply appreciate your patience and understanding during yesterday's interruption of service. Below are the full details of the service issue.

One of the first things we do when a service issue occurs is update our Network Alert Blog and Twitter page with as much information as we have at that time. We then post comments to that original post as we learn more. Our Network Alert blog is here:
http://www.junctionnetworks.com/blog/category/network-alerts

Click here to learn how to subscribe to our feeds:

Our Twitter account is:
http://www.twitter.com/onsip

As a rule, Junction Networks maintains three different types of maintenance windows:
1.) Weekend - early morning: The maintenance performed will produce a service disruption and could affect multiple systems.
2.) Weekday - early morning: The maintenance performed may produce a service disruption, but is isolated to a single system.
3.) Intra-day: The work performed should not affect our customers.
All maintenance, even that which is known to cause a service disruption, is not expected to cause a disruption for more than a few fractions of a second. For anything that would cause a more serious disruption (one second or more), backup services are swapped in to take the place of the maintenance system.

On October 26th around 10:10am, the firewall on a database server was restarted in order to update firewall rules. This maintenance has been performed in the past intra-day without issue. An authorization sub-system attempted to contact the database via the firewall at exactly the time the firewall was down. This caused the authorization sub-system to hang in a non-responsive state. None of the PSTN gateway machines could communicate with the authorization sub-system and therefore were rejecting all calls to/from the PSTN. It took approximately 20 minutes to diagnose the problem and to restart the authorization sub-system. Once the authorization sub-system was re-started, service returned to normal.

Also on October 26th around 11:15am, a main database server started filling the monitoring system with error messages. The monitoring system produced so many alarms that, at first, the problem was originally diagnosed as being either data corruption or a breakdown in the monitoring system itself. The system was so swamped with error messages that it took some time to figure out where the problem actually was. It was finally determined that the RAID system on the main database server had caused the box to freeze up. While the timing of the two problems implies they were related, the nature of each problem was very different.

At 11:30am, we began the process of migrating to our backup database server. The backup database server is designed to function as a "hot-swap" to which we can switch over without having to restore any data, as it syncs itself in real time. Unfortunately, the backup system had not been syncing since 10:10am when the first problem occured, and we did lose some data between 10:10am and 11:15am. By 11:40am, we had migrated the majority of the system over to the backup database server. There were a few hiccups after that - most notably phone registration data was 'old' and caused the system to think that some phones had lost registration. That state was corrected when phones either re-registered on their own or were rebooted.

Remedies:

Once the system was again stable, we sent an engineer to our datacenter to reboot the problematic database server. It came back up without incident and left no indication that there was ever a problem - it appears to be completely fine. Regardless, our engineers prepared new hardware to replace this server.

Around 11:00pm on October 26th, we finished bringing up a new database server (completely new physical hardware) which is now currently configured and synced as a hot-swap backup server to the currently running hot-swap backup server. This weekend, the new server will become the primary database server. We will be performing this maintenance during a weekend maintenance window, but do not expect any service disruption from this operation.