avery's blog

If there's one thing that a VC can get behind, it's the idea of the virgin market. Being the first entrant into a sea of untapped, not-yet-tapped consumers gives the possibility of actually owning a whole market. Be the first with the new widget and everyone's catching up with you, fighting for your marketshare and feeding off the scraps you left behind.

There's an old business axiom that fits this model: "Those that lead, bleed".

I bet you thought that I was going to say "With risk comes reward" or "Building the market is the best way to own the market" - which are all great, but the vast majority of companies that are started with the concept of doing something brand new fail miserably.

Let that sink in for a minute.

There's a reason it's called the bleeding edge. Regardless of how ripe a new market is for the picking, when you're the first ones out of the gate, you have to build the market - new products, consumer education, heavy sales and marketing. In the case of Vonage, they figured that with the massive deployment of broadband to the home, coupled with a more tech-savvy market and a real lack of competition from the cable companies - the market was ready for consumer-grade Voice over IP.

The promise of VoIP was cheaper calls, and the promise of Vonage was simple implementation that was as easy as plugging a box into the router and a phone into the box. Vonage contracted with hardware manufacturers to sell ATAs (the phone to VoIP converters) and VoIP routers - purchased them in bulk, set up automatic provisioning services and then launched a massive advertising campaign to get people to switch.

However, within months of Vonage's business taking off - first-followers started to emerge. These were essentially copy-cats - offering essentially the same service as Vonage but with small key differences. Since they could use Vonage as a business and architectural reference, startup was faster and cheaper, with less of the technology dead-ends and false starts that plague most startups.

As the largest player in the VoIP space, Vonage had the benefit of a good revenue stream which brought a decent amount of funding. However, being the prime mover in the market turned Vonage into a lightning rod. Key components of VoIP, VoiceMail, IVR and other technologies have been patented by the telcos that Vonage was poaching customers from. Though the patents are poorly conceived and never should have been approved by the USPTO, until a successful challenge is made, the telcos had a way to make Vonage pay. Verizon extracted $66 million and Sprint approximately $80 million - and a new broad reaching AT&T lawsuit could end up in the same region. With only 2.5 million subscribers, that's a cost of approximately $80-$90 per subscriber in penalties.

This leads to the hard lesson of Vonage.

Vonage didn't get to where it was by creating a new market. Vonage simply sold a cheaper method to do the same thing that the big, well funded carriers were doing. As soon as the media started reporting that Vonage was doing damage to the Telcos, it didn't take a rocket scientist to figure out that the Telcos would strike back - and with a legitimate stockpile of patents to pull from, all the carriers have essentially banded together to "put the smackdown" on Vonage.

Unfortunately, if Vonage fails, it's the death knell for the VoIP providers who are simply looking to be cut-rate telcos: selling transport and basic features to consumers. Thankfully, we're certainly not trying to become a telco.

As someone who has been in the thick of the enhanced voice world for well over a decade, it's funny that as much as things change, things really stay the same. Sure, we've made major shifts in infrastructure by beginning the migration from TDM (Time-Division Multiplexing, better known as the common phone network) to VoIP, but these infrastructure changes haven't really shown a significant benefit to business end users aside from cost reduction.

Not that cost reduction is a bad thing, but as Ralph Waldo Emerson said "Build a better mousetrap and the world will beat a path to your door." If I can build a corollary to this, it would be "Build a cheaper mousetrap and the world will eventually shift over to you - but it won't create any sense of loyalty and someone will build an even cheaper mousetrap and you'll eventually go out of business since you're just slashing your margins."

In the web world, Internet 2.0 was really pushed forward because of two technology concepts: REST and AJAX. Without getting into the guts of what these are and how they work, REST is a simple interface that can be placed on a system that makes it easy for pretty much any system - from an old legacy mainframe to a new web application to simply exchange data. Want to add a mapping function to a website? Find the REST interface to Google Maps, sign up for an account and you're essentially done. AJAX describes the ability to present data (such as from a REST interface) when it happens instead of making you click the refresh button on your browser to see if you have new mail.

This new economy of REST and AJAX has spurred the creation of the mashup. Mashups are a new style of website, taking services from multiple providers, putting them together under a single new "skin" and using it to create innovative services but with a significantly reduced cost. It's a better and cheaper mousetrap.

The voice world still hasn't come to grips with the concept of the mashup. Yes, there are innovative developers such as Thomas Howe, but the fundamental technology platforms just aren't there to support mashups in the same manner.

One of the things that we did at Junction Networks from pretty much the beginning was to separate platform and presentation. To this point, we created a voice application services platform, a RESTful API which can be used to control 100% of the platform, and then a website which used the API to create and manage the services for users. It wasn't an attempt to do something differently, in fast it was one of those things that just happens when a bunch of web developers decide to build a voice communications platform. Because we built the platform, then exposed it through the API, then built the web interface - there's no case (aside from some limited credit card processes) where another developer can't build a better mousetrap based on our interface.

Because of this, we're starting to see voice mashups happen - people building websites (handling school closures, playing video games by phone, etc.) that solve business problems and use our network as part of the solution.

We're not shocked that this is happening. However, I am disheartened that we're pretty much the only voice services platform that supports this level of open transparency.

If no man is an island, then no system is a silo.

As we are constantly working to prevent issues like the no-audio condition that some of our customers experienced last week, I realized that it might be a good idea to take a minute and explain a bit about how the phone networks work in general, and how they interconnect with Junction Networks.

All telephone traffic - either calls that originate from or terminate to a phone number are carried by the PSTN, or Public Switched Telephony Network. If you really simplify the network, you can imagine that your phone is connected to a wire that runs to a central office of the Local Exchange Carrier (LEC). The central office handles a set of area codes and exchanges (a US phone number consists of a three digit area code, three digit exchange and a four digit extension).

To get a call to go between one exchange and another exchange, you have to use an Inter-Exchange Carrier (IXC), also known as a long distance provider. These IXCs know how to get a call from one exchange to another. So, if I make a call from 212-555-1212 to 415-555-1212 - my local central office in Manhattan says "I can't deliver the call directly to California - what IXC does the caller subscribe to (ATT, Verizon, Time Warner, etc...)" Every Central Office knows how to reach every FCC registered IXC. So, if I was using Verizon, it would give the call to Verizon, who would then send the call via their IXC (long distance) network to the Central Office that handles all 415-555 numbers, which would then terminate the call.

Phone numbers have limitations - every phone is attached to a single CO, which has sole responsibility for that phone number, regardless of the carrier you select. So, if a CO, for some reason, loses its connection to your IXC or if it goes down completely - you can't make or receive calls until it's fixed. That's what causes phone outages.

Toll Free numbers work differently. As part of the breakup of AT&T in 1984, Toll Free numbers were "unbundled" - which meant that any IXC could assign and route toll free numbers. Later on, multi-manager services were added, which allowed a call to be shared between multiple carriers. For large call centers who cared about disaster survivability, this was key. Even today, many large businesses split their 800 traffic between multiple carriers so that if one goes down, calls can be re-routed through the others within a couple of minutes.

Fast forward to today. The Local Exchange Carrier/Central Office system has changed slightly. Now, in many areas around the country, there are competitive local exchange carriers (CLECs) which provide local phone services. Major CLECs include Comcast, Time-Warner, Level 3, RNK and XO.

Junction Networks contracts with CLECs all throughout the country to provide inbound (and outbound) phone service. When someone calls a Junction Networks phone number, the caller's Central Office contacts the Central Office that handles the area code and exchange, which sends the call to the appropriate CLEC, which sends the call over to us. When we make an outbound call, we pick the best IXC (we contract with many as well) based on where the call is going (and if there are any issues impacting a specific network).

Most of the problems that impact our clients happen before the call ever gets to us. For example, last week, one of the CLEC interconnects in the midwestern area had a problem which caused calls to come to us with no audio. Unfortunately, at this point - there's nothing we can do. Since the calls are coming from the PSTN to us with no audio, there's no way we can "failover" the call to another CLEC or do some sort of internal magic to somehow make the audio work since it's not coming to us in the first place. Even worse, the PSTN system takes days to move phone numbers from one CLEC to another, so there's not even a fast remedy for us to move calls between networks.

It's been a while since you've seen any real commentary here on the Junction Networks blog. It's not because we don't have anything to say - but our conference season runs from mid August (SpeechTek) through September (IT Expo) and into early October (VON) and that means that we've been spending lots of time on the road, preparing for briefings, etc.

Last week, at SpeechTek, we announced our partnership with Vicorp. Vicorp creates development and analytics tools for creating multi-tenant speech applications. In less techie terms, they're a good group of people out of the UK who create tools and design applications for carriers who have implemented speech recognition.

We're working with Vicorp to add new business services as part of the upcoming release of our updated onSIP Hosted PBX platform. For example, many of our existing customers have been looking for a more robust dial by name directory. Vicorp, who has built applications like this for many large enterprises and carriers, is building us a speech-enabled company directory which will be configurable "within the onSIP skins" - that means from inside our existing user interface, you'll be able to drag your users into the application and it will automatically configure itself.

Thoughts? Comments? Let us know in the forums.

This morning, we performed a number of small maintenance updates and upgrades on our system. There was no system interruption during the upgrade.

Starting at 14:00 EDT 8/14/07, one of our primary upstream providers of inbound telephone numbers started experiencing issues, and at approximately 14:30 - we stopped receiving inbound calls into the network.

As of 15:45, we are starting to receive calls again.

A full explanation will be posted as soon as it is made available.

As I mentioned in the inaugural post on this blog, we're getting very close to the release of onSIP, the next generation of our Hosted PBX offering. We're still a few weeks away from screenshots, but we wanted to at least share something. So, without further ado, here is the new onSIP logo!

Questions? Comments? Leave a comment or discuss it on the forums!

Well, it seems that conspiracy theorists are running around like mad putting up rumors that TeleBlend, one of the two SunRocket named "preferred providers" alongside Packet8 is really just SunRocket (or ex-SunRocket employees) poaching back their customers.

Now, I love a good conspiracy theory as much as anybody, but I don't think that there's anything that nefarious at play.

The theory seems to be based on three specific facts:

The MyTeleBlend.com domain was just registered on 7/18
The MyTeleBlend.com website has an appaling lack of information about their true identity
The phone numbers for MyTeleBlend are the same numbers for sales and support as SunRocket
When SunRocket imploded, Sherwood Partners, a respected firm that handles the wind-down of operations for failed companies, acting on behalf of their creditors to get as much value from the remaining assets became involved. Sherwood has no interest in running a VoIP company - their goal is to get pieces of the company sold off and to also try and keep services running in order to keep the investors/creditors from getting an even larger black eye from the failure.

From the chain of events, it looks like Packet8 was one of the first to pony up some cash to Sherwood to become a "preferred" alternative provider. Packet8 really didn't offer much - users still had to migrate over their numbers, wait for new hardware, etc. However, they were probably the first to offer any form of a solution.

Then comes TeleBlend - but who the heck is TeleBlend?

Teleblend is a newly formed subsidiary (or maybe just a brand name) of USA Telephone, a CLEC - or Competitive Local Exchange Carrier - which means that they are FCC registered as a carrier. This, by the way, isn't a simple process or cheap.

USA Telephone has CLEC (which means standard traditional telephony) status throughout New England and also is a provider/reseller of broadband internet services. My bet is that someone at SunRocket (or possibly at Sherwood) knew someone at USA Telephone and gave them a little nudge in the right direction to acquire some of the key SunRocket components to facilitate customer migration.

USA Telephone is not historically a VoIP provider, so my speculation is that since this isn't part of their key business, TeleBlend was set up - this way if it became a spectacular failure, the division could be closed or sold without any major impact to the USA Telephone brand. This is similar to the strategy behind Close Call America, Nationwide Connect and American Fiber Network, three other USA Telephone companies.

Sherwood, wanting to push calls away from SunRocket's support lines, most likely required TeleBlend to take the sales and support numbers for SunRocket. Most likely, only after the negotiations between USA Telephone and Sherwood were complete was the domain registered and a slapshod site was put up to facilitate migration.

If USA Telephone was smart, they probably got some of the infrastructure and even picked up some of the SunRocket staff who were already familiar with the systems. If you see some ex-SunRocket techs posting or boards, I wouldn't be surprised.

Maybe the wool has been pulled over my eyes on this, but in the grand scheme of plausible conspiracy theories, the idea of SunRocket bursting into flames and then rising like a phoenix under another name requires too much cunning, planning and strategic thinking - all skills that would have prevented its failure in the first place.

Over a week after its dramatic implosion, Sherwood Partners, one of the firms handling the wind-down of SunRocket, has done the right thing for its (ex-) customers by facilitating the transfer of accounts to a preferred provider.

TeleBlend, a small CLEC, has purchased "key assets" which will allow SunRocket refugees a simple migration over to TeleBlend services. What it looks like is that TeleBlend has purchased is the following:

The SunRocket Boot Servers, or at least the DNS entries for the SunRocket Boot Servers.
A master contract list that correlates phone numbers, expiration dates and some other information to verify the true holder of the contracts
A statement from Sherwood Partners (on behalf of SunRocket) stating that they are the "preferred" vendor for migration of existing customers

Why are these three things important?

The boot server is a key element. SunRocket sold locked hardware to its users. On a daily basis (or when restarted), these locked devices would ping the SunRocket boot servers to find out if a configuration needed to change or if new hardware was available. By owning the boot servers, TeleBlend can automatically reprogram the customer hardware, repointing the user's service.

The statement from Sherwood Partners goes a long way as well with the carriers when it comes to local number portability. In this case, using the support of Sherwood Partners, there is a blanket agreement to facilitate fast transfer of the phone numbers from SunRocket over to TeleBlend.

Finally, getting access to the contracts is key. Being able to get a user to enter his or her SunRocket number and automatically access the contract data (and possibly the hardware MAC address for reprogramming the hardware through the boot server) and push through the number porting process makes it a much simpler process than waiting three or four days to get one of the other vultures picking off the remaining SunRocket stragglers.

Of course, TeleBlend isn't offering to continue SunRocket customers existing deals. Those that migrate their service will be offered a "discounted" monthly service of $12.99/month for unlimited usage. However, any monies paid to SunRocket are still forfeit.

But with this said, hopefully we can finally put that last nail in the SunRocket coffin.

This afternoon, we changed our internal SIP addresses from the @junction.onsip.com domain over to the @junctionnetworks.com domain - so our email addresses and our SIP addresses are synchronized.

Cool, isn't it?

This did cause a 20 minute outage to the Junction Networks internal lines while we migrated our accounts over and re-configured our phones. If you called between 2:15 and 2:35 Eastern Time and got a busy signal, or if you called and nobody picked up the sales/support line, that's the culprit.

No calls were lost and no customers were impacted. Unless you were trying to call us... and in that case, we're sorry for the inconvenience.