mike's blog

Most days I work out of my home office near Philadelphia on a 5 year old Windows 2000 machine. Most of what we do at Junction Networks is virtual. We use Salesforce.com for lead tracking and trouble tickets and Google for document sharing and e-mail. I tried an experiment this week to see how virtual I could be and see if anyone would notice.

I bought a new MacBook Air. My first Mac. I have to say I LOVE IT. Buy Apple stock now. I copied over usersnames/passwords and bookmarks from my Windows box to my new Firefox install on the Mac and left town. I drove 600+ away on a 'working vacation' in Indianapolis (where I grew up and my family still resides) so my kids could hang out with their cousins for a week. I only brought with me my Mac and my Polycom VOIP phone. I wondered if anyone would notice. I didn't tell anyone what I was up to.

First problem: SSH. We use SSH to log into our servers and I didn't have my key on my Mac. I created a new key and e-mailed it to John and asked him to upload it to my .ssh directory so I could log in. I thought my cover was going to be blown right there. But I explained it as 'away from the PC' and trying to log in with the MAC. John got me hooked up and I was logged into our servers. Phew. Over the first hurdle.

Plugged the Polycom phone into the DSL line and it came right up. My username and extensions all 100% intact. I called ext. 7008 to talk to Tim in Chicago and it worked perfectly. The MacBook Air effortlessly connected to the WiFi connection and e-mail was up and running.

I have to say the week went well. I was 100% on the Mac except for one instance where I needed to manipulate an Excel file with some serious string concat functions that aren't in Google docs yet. Other than that, eight hours a day on the MacBook keyboard (including this not-short post) and there were no issues. It is an amazingly comfortable keyboard and easy to touch type on. It didn't crash once and Firefox was lightning fast even with all the tabs open.

I think I made it. No customers or other employees know I'm not in Philadelphia. I was 100% effective here being able to access servers, customer records, e-mail and documents without issue and with the phone, I was accessible via my extension and was logged into both the sales and support phone queue the entire week.

Tomorrow, on the weekly conf. call on Friday, I'll spring it on everyone that I'm 12 hours away from our NYC office, not 1 hour as they assumed. I'm actually pretty shocked that it turned out this well, but I'm sure for our engineering team it will be a case of, 'yeah, we planned it that way.' Which, of course, they did.

I'm not sure how many people can do this in their day job, but I'm happy that I can. I can 'secretly replace' the 'near' me with a 'far away' me and no one notices. Pretty cool.

Now I need to go on vacation where I leave all this stuff at home...

In a well reasoned article entitled The case against VOIP author Carl Weinschenk makes three cases against VOIP:
1.) Companies looking at VoIP primarily as a way to cut costs on voice services should be careful.

I agree that in VOIP, as in all aspects of business, you should explore the full cost of any product or service prior to purchase. In the case of VOIP, the customer who we have seen with HUGE savings are those who think outside the box and take advantage of VOIP to its fullest extent. For example, worry less about the per-minute savings from VOIP and look at the savings you can obtain by sending the entire help desk staff to work from home thereby saving rent on an entire floor of people. One of the major advantages of VOIP is that it is not tied to a single geography like land lines. Users can be anywhere and still have full phone system access.
Reality: The real cost cutting comes from leveraging VOIP to meet your business needs, not just saving per-minute costs.

2.) The underlying plumbing counts. Organizations must do pre-deployment assessments, and those antiquated or inadequate infrastructure should not deploy VoIP. Upgrading substandard networks can wipe out any savings from VoIP.

I actually agree with this. But, if your network is some ancient token ring, then a little YouTube is going to bring you to your knees as well. Any decent 100Mb LAN is more than adequate for VOIP. Upgrade now and use collaboration tools like WebEx and other great business tools.
Reality: If your network isn't ready for VOIP, it's not ready for most of today's multimedia intense Internet applications and you need and upgrade anyway.

3.) There are many organizations that can get by quite nicely without VoIP. IT and finance should have a clear understanding of why VoIP is being deployed and a detailed and clear-eyed costs/benefits analysis should be performed.

You should always have a clear understanding of why any initiative is being deployed and a detailed analysis should be performed.

Bottom Line
VOIP is a perfect choice for any size company in a greenfield (new office, new network, new pbx) environment.
VOIP is a great choice for small companies looking for more functionality from their phone system. With VOIP they can do more (auto attendants, voicemail) with less.
VOIP is a great choice for companies with branch office and/or remote workers. VOIP is not tied to a location and allows for easy collaboration.
For large companies all in a single office building with no remote workers and no plans to let anyone work from home, VOIP must be evaluated carefully. If the only thing a company is doing is unplugging the phone lines and replacing them with a broadband connection, then the value of VOIP is diminished.

Lucky for us, most companies fall in the first three categories.

Andy Abramson in VOIP Watch is enthusiastic about new legislation to equate VOIP calls to land-line calls relative to access to E911.

It is a noble effort and certainly VOIP carriers should not be blocked from placing E911 calls, but my problem is that VOIP calls are not at all like land-line calls. It's more like trying to attach 911 to Instant Messenger. When I log in to IM, I could be at home, at the office or at some Wi-Fi hotspot somewhere. But, at each location, it's still me. IM is not tied down to a physical location.

Neither is VOIP. I have three phones all registered as "me". I have a phone in our NYC office, a phone in my home office and a soft phone on my laptop. That's three different physical locations. Two of them are relatively stationary, but my laptop could be anywhere. I could make three different 'users' for my three phones and make people call different extensions to find me, but all that hassle just to 'fix' 911 doesn't seem worth it. In order to do 911 properly, you need to tie down the phones to a single, never changing physical location, but that, in my opinion, kills one of the major selling points of VOIP.

Another major obstacle to VOIP 911 deployment is a notion of one phone number equals one location. For many, many of our customers, that is just not the case. Most customers have just one or two (a local and a toll-free) phone number but that represents handsets strewn around the globe. Specifically, we require the ability for a E911 service provider to provide service based on handsets or users, not on phone numbers.

Companies running their own PBX are another special case. Either the pbx needs to send the service provider all of the same E911 information or they need their own direct access to the PSAPs. Direct access would be best as it takes one of the links out of the chain. But, that would require an overhaul of the VOIP PBXs to directly support E911 and for PSAPs to accept calls from almost anywhere.

Fundamentally, I feel it is flawed to force VOIP to provide a destination when a call is placed to 911. Should dialing 911 reach a PSAP? Yes. But, it needs to be a different PSAP from what we have today. Ideally, there would be a national clearinghouse of 911 calls which could off-load the non-emergency calls and route the high-priority calls to the proper geography to be handled by local emergency responders.

For the most part, it's a square peg trying to fit into a round hole. There is no simple solution but there needs to be much more research and analysis done. Sadly, that's not the legislation I see being passed.

Junction Networks' OnSIP Hosted PBX users now have four ways to make/receive phone calls.

Firstly, you can use your SIP-based soft phone/hard phone. This is how the majority of the calls are made today. You simply dial your phone.

Secondly, you can use our "Click to Call" Firefox add-on. Then, any phone number listed anywhere in a WWW page is 'clickable'. When you click on that number, we place a call to your desk phone. Once you answer, you hear "Outside transfer" and then the 'ringing' of the phone for the phone number you clicked on.

Thirdly, use our "Click to call back" Ajax API, you can place some HTML into your WWW page which displays a form for entry of a phone number. The user puts their phone number into the field. When they submit the form, you receive an immediate phone call, again with the prompt of "Outside Transfer" followed by the ringing of the phone for the phone number they entered.

We now have a fourth way to make phone calls and the flexibility of this application is what excites me. I just used it this morning to call a SIP address directly because calling a SIP address from my SIP-based desk phone is laborious. Log into the OnSIP Hosted PBX user portal (as a user, not as an admin, if you are an admin you have to go to your 'user' page directly by editing the URL to: https://admin.onsip.com/users/xxxx/info/, where xxxx is your User ID number.)

Now, at the top of the portal is a link to "Place a Call". Clicking on the link creates a "call box" where you can type in a phone number or SIP address. Click on "Call" to place the call. Immediately your desk phone will ring and you will hear "Outside Transfer". You then hear the ringing of the phone on the other end. I love it.

Is Video over SIP the 'Next Big Thing'? Andy Abramson seems to think so. Andy states, "By offering and delivering video, along with voice and text as the new universally used platform for real time communications voice gets to come along for the ride via a real standard, SIP (session initiation protocol.)"

As long as the video is using the SIP standard, we at Junction Networks are all for it. Our OnSIP Hosted PBX already supports video codecs using the SIP standards. Today, any customer with a video phone can make video calls.

Oddly, however, I have the capability and most of us here at Junction Networks have video cameras, but I do not make it a habit to make video calls for business. My kids call the grandparents on the video phone every now and then, but as a business tool, at least here, it has not caught on. Does anyone have an industry where they use the video phone all the time? If so, I would love to hear about it.

The good news is that by supporting the SIP standards, we are ready to support anything that comes along.

Excellent post in Gigaom today: Web 2.0, Please Meet your Host, the Internet. The point of the story is that too many of the Web 2.0 companies are caught up in the software and not concerned about the 'host', in this case the Internet.

In my 'spare' time I coach my 10yo daughter's AAU basketball team. We have a great team with a lot of talent. Our travel season ended up with two championships and a 26 and 0 record. Pretty impressive. Our AAU season has not been as successful, so the head coach, Coach John, has instituted a 'back to basics' practice regimen the last two weeks. He, and any good coach, will tell you that a team with good fundamentals will always beat a team with pure talent. We're going back to the basics to re-establish those fundamentals.

The Gigaom article is similar. You can have the coolest Web 2.0 application, but if you can not handle the fundamentals of providing a service over the Internet, the equivalent of shooting and passing well, your application, whatever it is, will fail.

I feel that this is one of the reasons that Junction Networks has had so much success with the Web 2.0 version of our OnSIP Hosted PBX platform. Yes, it is Ruby on Rails, javascript and Ajax, but most importantly, it is built on a very firm foundation of servers, routers and BGP connections. To date, we have nearly a dozen BGP connections to ISPs both big and small. We have multiple, redundant servers interconnected to a mesh of routers. We have a very solid foundation upon which to build our next generation applications.

Inc. Magazine has a great article in their current - May 2008 - edition. In it they discuss how a company can cut their IT budget by outsourcing services like e-mail, CRM and their phone system.

Yes, Junction Networks is mentioned in the article including a glowing customer review. We are very excited to be singled out by a magazine that is such a great resource to our target market, namely entrepreneurial business.

The main focus of the article is well reasoned. Outsource what you can, and allow your company to focus on what I call 'the center of the plate.' For example, we here at Junction Networks, we use Salesforce.com for CRM, eFax.com for our faxing and Google for application sharing and e-mail. Especially since we have so many people working outside of the corporate offices, by sharing applications and information via WWW-based applications, it allows us to more quickly and efficiently share information across the entire organization.

Hopefully you like the changes to our marketing WWW Sites, http://www.junctionnetworks.com and http://www.onsip.com. Our marketing department is right on track with our messaging. We are using the Drupal content management system which should allow us more timely updates to the site, our knowledgebase and our Blog.

In addition to the new marketing WWW sites, we have also launched a new User Portal. The User Portal allows all OnSIP Hosted PBX users to log into the system to see their settings. Previously, only account administrators were able to log into the interface. The User portal only contains information pertaining to that user and does not show any account-level information. The new User Portal also contains a newly revamped and updated knowledgebase.

While we were at it, we launched a new application: Conference Bridge for OnSIP. OnSIP users pay $19.95 per month for unlimited conference bridge use for up to 10 (ten) simultaneous callers. Any callers coming in via the PSTN would still pay the regular 2.9c/min.

As an update, we recently changed the pricing on our ACD Queues to $19.95 for the ability to have up to 5 callers in a queue simultaneously. Around the same time we launched “Announcements” under the “Apps” tab. Announcements allow you to play a recording to the caller and then send the caller to a new destination. This is useful for ‘business hours’ or ‘directions’ announcements within an IVR application. Lastly, we launched the “Inbound Bridge” application which allows a customer to purchase phone numbers (DID) for any other VoIP provider and ‘bridge’ those DIDs into the Junction Networks service.

The next big release for us will be the User Dashboard, but more about that later.

Please let us know what you think about our new WWW Sites and our new applications.

Starting at around 7:20pm EST and continuing until around 8:13pm EST, routes from Junction Networks to the Global Crossing networks were corrupted. No traffic was able to reach Junction Networks from anywhere on the Global Crossing network. All inbound and outbound traffic would have been affected. Unable to repair the situation, the Global Crossing network peer was disabled forcing all traffic around the issue. Service was fully restored at 8:13pm.

One an unrelated note, Junction Networks will be performing a network upgrade from 9am until Noon on Saturday, April 12th. We do not expect any customer affecting service interruptions from this operation.

Starting this morning, a subset of New York state phone numbers, area codes (212, 718, 845), were not completing when called from withing New York state. Only some numbers were affected. Outbound calling was unaffected. When the calls were not completing, they were not hitting the Junction Networks switch. We immediately opened a ticket with our inbound carrier. Around 11:45am EST, the issue was resolved.

We received the following analysis from our carrier:
"Early this morning a peering customer's switching fabric went offline from a
failed maintenance window. We then began to see flooding into the SS7
network with critical errors flooding our SS7 links. They were unable to
resolve and put our network into a level 3 congestion state. At the same
time our major inbound carrier had a major outage as well which limited
their ability to assist in restoration causing them to continue to stream
RSC messages. This caused an unhappy state between our LSG and LNC and STP.
Our switch vendor continues to review root cause. We have all executive
levels working the issues with providers and vendors at this time and are
systemically treating each circuit level issue trying to process the most
calls possible at this time. The impact is not entire but partial."