Tech

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.

Did you know that Junction Networks has a public web service API available to any of our customers that exposes all of the pieces necessary to manage your own hosted PBX and PSTN gateway services? In fact our admin.onsip.com web administration portal has been built entirely on top of the very same API that is open and available to the public - this means any feature you see in our administration portal is potentially available for you to implement in your very own VoIP product.

What does this mean for your business?

This means that you could build your own web portal to extend your product line to include a VoIP service without having to do the work of building the VoIP side of the service! You would be able to leverage all of the features from our OnSIP Hosted PBX and PSTN gateway products into your own product behind your own custom web portal. For example, let's say that you are a web host looking to augment your product offering in order to differentiate yourself from your competitors. By implementing the various pieces of the Junction Networks web service API you would allow your own customers to create and manage their own hosted PBX. You could even do some more advanced things like host your customers SIP domain in the primary domain that he has registered with your service already. Simply add an SRV record to identify Junction Networks as the domain's SIP service provider and the customer will be able to get their web, email, and voice service all from you - while you don't need to worry about any of the voice end of things. Additionally, you can implement your own pricing structure on top to fit your new VoIP offering to be in line with your current pricing. Since OnSIP never charges for users or extensions you can offer your implementation either with or without such charges - the choice is yours.

The benefits of implementing your new VoIP product offering this way is that you can continue to concentrate on your core business without a need to dedicate permanent valuable resources to building and maintaining your VoIP product. That's why we're here! It is our job to make sure that your VoIP services continue to stay up and working reliably.

Getting Started with the web service API

To get started with the Junction Networks API you can start by trying it out yourself on our API demo page. In order to use the demo you need to be a registered Junction Networks customer with an authentication name and password, you can signup for a free 30 day trial here to obtain these credentials. You can also get started with our VoIP web service API by reading the API documentation. If you happen to be looking for a feature that is not currently documented then please send us a support request and we'll be sure to get the API call documented as soon as possible.

Have fun.

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.

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

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.

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!

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.