Blog

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.

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.

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.

Douglas Crockford¹ of Yahoo! has just published an excellent new book titled Javascript: The Good Parts.

Another Book On Javascript?!

The nice thing about this book is that it is not just another manual on ECMAScript, but rather a terse description of JavaScript that "scrapes away the most horrendous features to reveal a subset of JavaScript that's more reliable, readable, and maintainable". The book covers more than the obvious topics like syntax and "global variables are evil" (though that is mentioned ad nauseam) - so you can be assured that this one isn't just a kiddy read.

Crockford's major theme of the book (and an excellent one IMHO) is that behind all the crust, fluff, and awkward features of JavaScript there is an elegant subset of truly excellent features in the language. The point being that by strictly adhering to only this subset we can make usable, extensible, manageable software that will have much greater durability than software produced using the ugly parts. I felt Crockford did a very nice job at hammering his points home about his take on the bad parts without sounding preachy in regards to coding style. Only in one of the appendices does he go into detail regarding his preferred style of coding, and even expressing these opinions he does so with sound arguments.

Who's it for?

If terms like "inheritance" and "closure" invoke images of coming to grips with your wealthy aunt Sally's passing, then this probably isn't the book for you. The book's value lies with the seasoned programmer that is experienced mainly in classical OOP or procedural programming. That programmer is the one who will find this book useful in coming to grips with the paradigm shift necessary to work with JavaScript rather than struggle with it. If you're one who finds yourself using JavaScript libraries like jQuery and Prototype but are confused as to what Object.extend and jQuery.extend are actually doing behind the scenes then you'll definitely want to purchase a copy. Plus, unlike those 1100 useless pages of Sams: Teach Yourself J2EE in 21 Days that have been sitting on my bookshelf since mid 2003², this book is sure to be one that you'll actually read. At a mere 100 pages or so (plus 40 pages of appendices), the book is quickly digestible and even more importantly, it's immediately applicable. You will notice your code improving in front of your eyes from the moment you get through the chapters on object literal notation and functions - chapters 3 & 4 respectively. Even if you are one who already know the basics of the language, simple things about JSON, and function scope - then you will still most certainly find use in the Crockford's demystifying coverage of a few of JavaScripts most popular object inheritance patterns.

So if, like my former self, you use JavaScript on a regular basis without a strong notion of how to do it "the JavaScript way", then I highly suggest giving this book a quick read. I promise that it will be time well spent.

1. For those who don't know who Doug Crockford is, he's the guy who wrote JSLint, along with many other invaluable JS tools
2. I should probably consider myself lucky that I never found those 21 days to give to J2EE

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.

Let's walk through my daily workflow, up to the point where I'm ready to commit back to my upstream SVN repository.

Since I work on a fair number of branches and I don't always know what I worked on last, I run git-status to see which branch I'm in, and any uncommitted work. This command shows my current branch, uncommitted files, and files in the index cache¹.

I like to keep my tree as fresh as possible, so I'll next run git-svn rebase to update my tree with the latest from SVN. You can't run a rebase, however, if your working tree is dirty, so I'll clean up what I can using git-commit and git-add --patch². Any code I can't fold into a commit, I put aside for a moment with git-stash.

When the rebase is completed, I'll put any stashed code back with git-stash apply. Now my tree is up-to-date, and I have all my local changes worked into it.

The rest of the day proceeds pretty normally. I hack on code, and I'll commit whenever I see fit (which is often - as I've mentioned, I'm a Machine Gun Committer).

We haven't committed any of this back to the SVN repository yet, but in the next article we'll cover that, along with how I fool my coworkers into thinking I magically do everything in one commit, even though I've actually committed very frequently.

1. Git's index cache (a.k.a. Staging Area) is an intermediate location between the Git repository and the current working copy. Coming from SVN, this will appear a little baffling to you, but it exists as a way to manipulate commits before generating a patch. You add files to the cache using git-add and git-commit commits everything in the cache to the repository.
2. git-add --patch, along with git-rebase -i branch, are some of the most useful and world-shaking things that come with git. In a future article I'll take a look at both of these commands to highlight some of their utility.

The other day, I made a mistake while committing some work I'd done via Git to our SVN repository. Since this series of articles is about working with Git and SVN, I wanted to take a short time to look over what happened as well as a small change in my workflow that will prevent it from happening in the future.

The mistake was that I accidentally pushed a file I was working on to our main repository. There was no damage caused, as the file wasn't in use by anything in production yet, but I'd rather not have pushed it at all.

The solution is to diff my work against the current repository and make sure only the changes I want or going to be pushed. But since Git doesn't work in a centralized fashion, you can't run a straight diff: you first have to know which revision to use as the left hand side. In Subversion, this is straight forward as it's centralized; the left hand side is the SVN repository HEAD, and the right hand side are your uncommitted changes.

Well, with Git, it's only a tiny bit harder: all you need to know is that remote repositories have special "tracking" branches, in the Git's "remotes" branch heirarchy. When you initialized your repository with git-svn, it also created a "remotes/trunk" reference that you can use. Therefore:

% git-diff remotes/trunk
...

will show me a diff of exactly what will be committed. As I roll this into my workflow, I should be making fewer and fewer of these kinds of errors.

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.

I've been using Git for my personal projects for about six months now, but I've only recently taken the plunge into using it for work projects as well.

There are many good articles and talks out there on what Git is and what makes it different from "normal" version control systems like CVS and Subversion (SVN). In the interests of brevity, I will only summarize: with Git, your entire repository is cloned onto every developer's computer, and this opens up a huge range of possibilities for repository management. In addition, Git's revisions are cryptographically dependent on all previous revisions, so it is impossible to intentionally or unintentionally corrupt a repository.

We use Subversion here as our main source repository, and Subversion has worked very well for us in most ways. However, we like to use branches a lot, to segregate our work until it's ready to be merged, and this is one area where SVN just doesn't cut the mustard. To work around SVN's limitations, we tag our merge commits with the left hand and right hand revisions in the commit messages. This is passable, but error-prone and brittle.

In addition, when I'm coding, I tend to be a Machine Gun Committer. I commit constantly so I can always get a fine grained picture of how I've been working and what I've been doing. With a little bit of legwork, this also allows me to more accurately pin-point where my bugs showed up. However, it annoys my coworkers to no end, and I can see their point. It is pretty obnoxious.

Git offers the solutions to all these problems and more, all while integrating cleanly with our existing Subversion repository.

Let's start by first cloning your existing SVN repository into Git with git-svn:

% git-svn clone http://localhost/mysvnproj -T trunk -b branches -t tags
...

Now you have a private copy of mysvnproj (and it's entire history) in Git. A quick note: your "trunk" branch in SVN is called "master" in Git. You can change this behavior, but by default this is what you'll get.

Any changes you make in mysvnproj can be pushed back to the SVN repository when you're finished with "git-svn dcommit":

% git-svn dcommit
...

Pulling updates from the SVN repository into your Git repository is done with "git-svn rebase":

% git-svn rebase
...

This will not commit any of your local changes, but "rebase" them onto the new SVN head. In git terminology, "rebasing" takes a set of changes and applies them to a new head. I find it's useful to imagine this as a graph:

          /------ B
         /
A ------/-------- master

If I rebase B to master, the new change graph looks like this:

                 /------ B
                /
A -------------- master

This changes my local commit history to look like B inherited from the current master, rather than at some point in its history.

Now, the only other thing we have to cover in this installment is using an SVN-hosted branch. This is subtly different from a normal git branch, because it backends into SVN and thus can't use much of Git's history analysis for branching and merging. Because merging isn't made any easier (and in some ways is made harder) by using SVN branches, I prefer not to use them. Never-the-less, sometimes you might need to.

The good news is that once a branch has been created in SVN, you can use that branch in Git fairly easily:

% git-checkout mysvnbranch
% git-checkout -b local/mysvnbranch

This will tie your SVN branch to local/mysvnbranch so "git-svn dcommit" will Do The Right Thing™.

Over the next few days we'll dive into some work flows that will help show the power of Git, as well as solve the problems I've outlined above. Stay tuned!