The recent news that online retailing giantAmazon.comwould open an app store to compete with Google’s Android Market has set off a flurry of speculation about the future app store landscape. Within the next few months there will be no fewer than three major Android app stores, including theVCastapp store recently announced by Verizon. Several other major players have announced their app store intentions (including AT&T, Sprint, Motorola, Samsung andBest Buyin the U.S. alone), though specifics are not yet public.

Last night, while enjoying a beer at the swank rooftop bar of 230 5th, I found myself in a lively discussion about Verizon's seemingly new attitude towards openness. I was speaking with an executive of BilltoMobile, a company that made headlines earlier this year when it announced a relationship with Verizon Wireless. Through the agreement, developers of online games and communities are able to collect payment from users, that are also Verizon Wireless subscribers, on their monthly cell phone bill. At the time, the news was surprising to many telecom veterans (myself included) because Verizon's reputation for protecting its ecosystem is legendary (especially when customer touch points are involved).

Within the past weeks, many VoIP service providers were taken by surprise by changes in the market for U.S. termination, as large VoIP wholesalers began to implemented LRN billing and intra-state billing for U.S. termination traffic. In many cases, the changes were made with little or no notice to wholesale customers.

These wholesale carriers are now charging for calls based on the LRN (Local Routing Number) instead of using the actual dialed digits (also known as DNIS or Dialed Number Identification Service).

By now, its old news that the world is app crazy (thanks to the Apple iTunes App Store). Every major player in the mobile OS space - Microsoft (Mobile 6.5/7), Google (Android), Nokia (Symbian), RIM (Blackberry), Palm (WebOS), and Sun (JavaFX) - has launched, or announced plans to launch, their own app store. Additionally, there are app stores from handset makers (LG, Samsung, SonyEricsson) as well as mobile operators (Orange, Vodafone, AT&T, Verizon) and various independents (Handango, GetJar). Other companies (Comverse, Amdocs, Qualcomm) offer app store 'in-a-box' solutions that facilitate the creation of new App stores. Although it makes for a chaotic ecosystem, the craze is understandable because handsets and service offerings are well along the way to commoditization, and apps are one of the few means of differentiation.

Against this backdrop, it was interesting to hear Motorola announce that it has no intention of creating its own app store (as stated by Moto co-CEO Sanjay Jha at the Mobilize '09 conference last week). Instead, Moto has created a hardware specific app for its new Cliq handset designed to enhance other apps that a user might run. Among other things, the app (called MotoBlur) will combine feeds and status updates from various social networks (like Linked-In and Facebook) and give users access to the most important information directly from the home screen on the new phone.

The move is thought-provoking for several reasons:

Although a successful app store is a good way to create a lasting relationship with the customer, it seems obvious that there is not enough room in the app store universe for all the interested parties. Many of the current app stores are destined to fail. It remains to be seen what other types of relationships might be created. Yahoo! attempted an alternative approach with Go 3 which optimistically aspired to be a device independent entry point for user applications. The device-specific MotoBlur approach is yet another alternative.

Apart from creating lasting relationships with end-users, it is also necessary to cultivate lasting relationships with mobile software developers. If the developer community does not create appealing apps, then there will be nothing to attract end users. In the case of the iPhone (where Apple controls the OS, device and store) Apple can create a controlled development environment. While this may simplify the development process for developers, it can also prove constraining, as witnessed in the well-publicized case where Apple denied entry to the Google Voice app. To the extent that other players do not control all three legs of the tripod, it may hamper (or enhance) their ability to attract developers.

It seems logical that mobile users will tend to have a 'favorite' app store. The question this raises is which party in the ecosystem has a competitive advantage to win this role. Both the OS makers and the network providers have unique attributes. The OS makers can provide APIs that give apps more capabilities and ease development. The network providers can provide additional services that bring into play elements that are beyond the scope of the device itself (which I have previously blogged about here). It seems to me that device makers not in control of the OS are at a decided disadvantage when it comes to attracting software developers.

After years of poor execution, Moto is clearly against the ropes. A failure now could be devastating to the future of its handset division. So the decision not to play in the app store space is a bold one that will either prove prescient or another nail in the its coffin.

Like many others, I will be watching closely to see how these issues play out.
Continue Reading...

The Federal Trade Commission's new rules regulating U.S. telemarketing calls (scheduled to go into effect on September 1) will have a significant impact on the VoIP industry. According to the rules, prerecorded commercial telemarketing calls will be prohibited, unless the telemarketer has obtained permission in writing from consumers who want to receive such calls.

Given that most auto-dialer traffic is delivered over VoIP networks today, the new rules will have a tremendous impact on many aspects of the VoIP industry.

Based on my own unscientific calculations, I estimate that auto-dialer generated calls represent at least 25% of the total number of VoIP calls made today. When these calls are no longer permitted, it will affect the businesses of the vendors that make and run the predictive dialer software, the call centers that handle the calls, and the networks that terminate the calls. This is business that will be lost forever to the VoIP world, as marketers are forced to shift their budgets to other media. Based on current market size estimates of $1.1 Billion (for the affected industries), that could mean a contraction amounting to hundreds of millions of dollars (although auto-dialer traffic constitutes a large percentage of VoIP calls, actual revenue is significantly less - percentage-wise - since the cost of each call is relatively small.

Anyone that is involved in the wholesale VoIP termination business will know that predictive dialer traffic has already changed the landscape. In particular, the deluge of auto-dialer calls has forced most U.S. network providers to impose stringent surcharges (in most cases, having this traffic profile will result in a $0.01 surcharge on calls with a duration of less than 6 seconds) and to forcefully adhere to RBOC vs. Non-RBOC blending rules.

The aftershocks of the new rules will likely have similar repercussions.

The recent row between Google, Apple and AT&T concerning the removal of Google Voice from the Apple iPhone store highlights the friction existing between network operators and so-called over the top (OTT) application providers. Most observers believe that AT&T initiated the blockade because Google Voice (which offers free or highly discounted calling rates) is a direct threat to AT&Ts call revenue (Google Voice users need only pay AT&T for access to the Internet).

At the heart of the matter is the stark reality that network operators don't want to be dumb pipes. More specifically, they dread the idea that outfits like Google may generate rich service fees from subscribers, while they are left with relatively paltry access fees.

It has been about a month since I started using Google Voice (the relaunched service formerly known as GrandCentral) and I am impressed. I am always reluctant to use superlatives, but Google's spin on a 'one number' service is far and away the best implementation I have seen so far. It has the potential to be a game changer on several levels.

Although the service is not available to the public yet (only existing GrandCentral users get access for now) I would be very surprised if customer uptake does not surge when it becomes generally available.

Here are some of the highlights:

The essence of the offering is a 'follow-me' service that allows you to filter, screen or direct inbound calls to the phone of your choice. Google Voice provides a local number at no cost. Calls to the local number can then be handled in several different ways: forwarded to one or more phones (including SIP phones, see below); sent to voicemail, screened, or recorded.

The best part of the service is that it is free (at least in pecuniary terms). There is no charge for the local number that gets assigned, or for outbound calls to the U.S. Every other follow-me service that I am aware of charges a monthly fee for the former, and a per-minute fee for the latter. The quid pro quo is that you must sacrifice yet another level of privacy to the great Google machine. Google will undoubtedly use this service as another means of targeting advertisements (more on this later). If you are still operating under the delusion that anything you do is private, then this is not the service for you.

The user interface closely resembles Gmail, so it is both familiar and intuitive. It seems obvious that Google plans to merge the Voice interface into Gmail at some point in the future, which would conveniently place all incoming messages in a single screen.

The interface displays all of the contacts from your Gmail account. This makes it very easy to manage your contacts as well as to select a contact name and create handling rules. You can also create custom greetings so that every caller in your address book will hear a unique and personalized message. The screenshot below shows the special greeting I created for family members.

The call handling screen gives you an option to forward calls to one or more phones, and one of the options is a Gizmo SIP account. Gizmo is a paid service, but offers a free version that allows you to register a SIP phone and receive calls from other on-net users. The SIP option promises to open up a lot of flexibility, although I was unable to make it work with my own Gizmo account (It's possible that Gizmo disables inbound calls from Google Voice since this would compete directly with their own inbound call service, which is not free). It would be nice if Google added an option to forward calls to any SIP URI.

The most useful new feature is voice transcription, which will convert an audio message left to voicemail into text. The resulting text transcript is then visible in your inbox and is searchable. While the voice recognition software used for the transcription is not perfect, it is definitely good enough to facilitate keyword searches. In the example shown in the screenshot below, the brand name was garbled, but I was able to locate the message by searching for "sale" and "tractor" (the lawn tractor is still for sale, in case anyone in the Fairfield county area is interested).

It is possible to make outbound calls from within the user interface. Calls within the U.S. are free, while international calls can be made using a prepaid account. Rates for international calls are lower than you would expect to pay your cellco, but not as low as are available from specialty service providers. Calls originated through the Google Voice servers will first ring your phone, and then the phone of the called party. This gives you the very convient option to record outbound conversations (although it is not currently possible to get a transcript of these calls).

For good measure, Google Voice also includes an SMS short text service. This allows you to receive SMS messages into your Google Voice inbox, which are then searchable, just like voicemail messages. You can also send SMS messages from inside the user interface using a lightweight ajax interface.

All of the web UI functions, including placing an outbound call or SMS, can be used from a mobile browser. The already utilitarian interface is rendered more sparse to make access from slow mobile data connections more tolerable. Testing with the Blackberry mobile browser and the Opera mobile browser was surprisingly easy. And, I would be very surprised if access was not made even easier from future Android phones.

About the only negative aspect of the service is that calls originated from your mobile and landline phones do not show the Google Voice number in the recipient's caller ID display. So, people that simply hit the call button from their call history will not be routed through the Google Voice service. This limitation does not apply, however, if you originate the calls from the Google Voice interface.

While Google's record is a mixed bag when it comes to non-search services (think of Google Video, Lively or Orkut), I predict that Google Voice will be a killer app. They have taken an inherently difficult task (managing inbound phone calls) and made it easy. Given the already large base of Gmail users who will benefit with almost no learning curve tax, this can only mean success in terms of both user adoption and revenue generation (through more finely targeted advertisements).

Importantly, the implications of Google Voice for other service providers (including VoIP service providers, the LECs, and cellcos) will be more profound than even Skype. I intend to address that topic in my next post to this blog.

It seems like every so often incidences of VoIP fraud spike. Whether it's an effect of the weak global economy, or some other factor, Q3 of 2009 is turning out to be one of those periods.

Don't get me wrong, VoIP fraud is always an issue to be contended with - partly because lax security on the part of systems administrators makes it easy to achieve, and partly because the nature of the Internet opens service providers up to anybody with a desire to test their defenses. However, over the the past few weeks, I have been hearing reports of wholesale VoIP fraud that are particularly appalling.

One that is currently making the rounds is the Zambia scam. Apparently one or more large carriers have been allowing wholesale customers to make calls to any destination in the world if an e.164 formatted number is prefixed with 260 (the country code for Zambia). For example, a carrier that is susceptible to this hack would route a call dialed as 26005352632040 to Cuba (country code 53). Since that dialstring would normally be routed and billed as if it were terminating to Zambia (where the going rate for a wholesale call is under $0.03) instead of to Cuba (where the going rate is over $0.50), a provider in the chain is bound to lose out.

It is not clear whether these calls are actually re-originated through Zambia through a local PTT such as Zamtel, or are the result of a botched route entry in a shared underlying carrier further up the line. The anecdotal reports I have heard seem to indicate that the former is the case. In either event, the problem is difficult to detect because the routing will appear to be legitimate for all service providers that handle the call prior to the error. As a result, any service provider that notices a spike in traffic to Zambia would be well served to investigate more closely.

For a bit of shameless self-promotion, be sure to try grnVoIP if you are in need of prepaid wholesale VoIP termination. With sophisticated anti-fraud technology from Solegy, grnVoIP is able to maintain low rate VoIP termination by staying one step ahead of the bad guys.Continue Reading...

The announcement by Oracle yesterday that it would purchase Sun for approximately $7.4 Billion marks the end of an era. As their advertising proclaimed, with only slight hyperbole, Sun put the dot in dot-com. No other single company has done more to advance the Internet. Amidst the hype around cloud computing these days, it is easy to forget that Sun founder John Gage coined the phrase "The network is the computer" nearly twenty-eight years ago.

Nostalgia aside, Sun chose to exercise its technology vision in a way that genuinely made a difference - by pursuing a business plan built around open source software. Its contributions to open source, which include Java, OpenSolaris, Open Office and MySQL (to name just a few of the more well-known packages), have had a meaningful impact on the world. If for no other reason, by providing viable alternatives to proprietary software in almost every category. As with other open source companies, Sun hoped to generate services revenue around its systems (it is ironic that the company's bread and butter market - high-end servers - was eroded by the very commodity computing it espoused).

Unfortunately, Sun's management could not convince the market that the open source model would generate a sufficient financial return. And, whatever Oracle decides to do with Sun's technology assets, it seems safe to say that open source will be the loser in this deal. It is difficult to imagine Oracle, with management firmly focused on the bottom line, allocating resources in the same way.

Perhaps Sun's demise as an independent company was inevitable. I'm just saying that it would have been nice to see them go to a company less brutally efficient than Oracle.Continue Reading...

An issue that appears more and more frequently in my daily travails has to do with the growing number of IP-PBX implementations that can not reliably use UDP as a transport protocol.

First, the good news. Based on my own personal observations, deployments of IP-PBX equipment are seemingly on the rise, despite (or maybe because of) the tough economic climate. No doubt, this is partially because productivity-enhancing unified communications features are getting better, and there are a wide variety of very viable IP-PBX vendors from which to choose.

The bad news is that the growing feature list has introduced unexpected compatibility problems. The issue is that many modern SIP PBX makers put proprietary parameters into the SIP protocol headers. This extra content is used to define how calls are handled within the PBX environment. It can contain everything from XML code about which prompt to play, to snippets of audio needed for speech recognition. While this is allowed by the SIP protocol, a side effect is that the SIP header becomes larger, often exceeding the default 1500 byte maximum size for a UDP datagram packet. The result is that the SIP header becomes fragmented, spread across two or more packets.

Fragmented UDP packets can pose certain problems. Since UDP is a fire and forget protocol, there is no correction built into the the transport layer for dropped or delayed packets. This means that SIP endpoints must be smart enough to reassemble or otherwise compensate. And therein lies the problem.

It turns out that more than a few SIP implementations are not able to process fragmented SIP packets. In one extreme case (which I encountered today), a fragmented SIP INVITE message actually crashed a major vendor's SIP gateway. In other cases, packet fragments are either dropped or rejected. Obviously, this can cause havoc for IP PBX administrators.

One workaround is to use TCP instead of UDP. TCP allows for a greater packet size, and also incorporates error correction as part of the protocol. Some vendors (like Microsoft in its Office Communications Suite) have opted to support only TCP, even though the current SIP specification (RFC 3261) requires support for both. However, many older SIP implementations (those based on RFC 2543) do not support TCP at all because it was optional at the time. And, SIP implementors still consider UDP to be the least common denomiator for transport.

When you combine the packet fragmention issue with the lack of TCP support in older SIP implementations, it becomes increasingly likely that one will come across incompatible SIP implementations at the transport layer. Being aware of this added level of complexity in the SIP interoperability puzzle could save you valuable time in troubleshooting and diagnosis.

I am sure that the various vendors involved will get up to speed and either fix their handling of UDP fragmentation, or support TCP. In the meanwhile, think of this as just another growing pain along the road to an IP enabled world.

Do you ever come across stuff on the web that makes you want to share it with all your geekiest friends as soon as possible? Yesterday was one of those days for me, as I stumbled across OpenBTS, the ultimate mobile phone hack. At the risk of causing my beautiful wife Jaime to throw her arms up in despair because of my own geekiness, I must admit that discovering OpenBTS triggered the same thrill of possibility that I used to get when reading 2600 as a college kid.

In a nutshell, OpenBTS allows anyone to create a micro GSM base station that can talk to any standard GSM handset, and then convert the session to VoIP using an Asterisk server. Essentially, it performs the same function as a femtocell, which is a new class of device that is being used by cellco's such as T-Mobile to extend mobile phone coverage into homes and other areas where their wireless signal might be weak. The practical benefit is that users can access a VoIP network wirelessly, using a GSM handset instead of purpose built devices such as a DECT VoIP adapter (like Ooma's Telo), WiFi VoIP, or a UMA enabled handset.

In technical terms, the OpenBTS Project is an effort to construct an open-source Unix application that uses the Universal Software Radio Peripheral (USRP) to present a GSM air interface ("Um") to standard GSM handsets. Put another way, its an open source implementation of the GSM protocol stack paired with a software radio. According to the Wikipedia entry, the project was started by Harvind Samra and David A. Burgess to reduce the cost of GSM service provision, in rural areas and the developing world, to below $1 per month per subscribe. The commercially supported version of OpenBTS is provided by Kestrel. David Burgess provides more background on the genesis of the project, as well as some interesting facts about the cost of building a GSM network, on his blog.

It is worth noting that OpenBTS is just one example of a quiet revolution that is occurring in the wireless industry. All radios will be software-based in the not-too-distant future. This means that the same piece of silicon will be used to make a call on a mobile network, listen to the radio (FM and satellite), control your bluetooth devices, and open your garage door. When paired with open wireless spectrum, the opportunity for innovation and new services will be immense. Until that happens, however, it is nice to see projects like OpenBTS making headway.

With the right commercial roaming agreement, and a dollop of ingenuity, it could be used to build the killer home communications hub.

Before you go out and purchase the components (which are available here) to setup your own micro cellphone service however, be aware that it could be illegal to operate such a device in areas where the GSM band frequencies have been licensed. In addition, while the OpenBTS implementation is open source, the intellectual property for the GSM protocol itself is owned, and closely guarded, by companies such as Ericsson, AT&T and Alcatel-Lucent. At least in the United States, OpenBTS can be legally used for testing purposes and to satisfy your intellectual curiosity only.Continue Reading...

A few days ago, Verizon formally launched a new product called Verizon Hub. The consumer device is designed to meld a VoIP line with several web-based and wireless services. For example, a user can access driving directions and send text messages while on a voice call. All things considered, there's not much new ground being broken here, and the device has gotten mediocre reviews at best. However, when seen alongside other recently launched products, the Verizon offering points to an exciting new trend in the consumer device space.

Exhibits B and C are the Vonage V-Portal and OomaTelo. Both are VoIP ATAs that combine multi-line cordless (DECT) phones with an LCD display that makes configuration and usage easier (Ooma has other good attributes, that I wrote about here). Exhibit D is the femtocell, a new type of wireless device that has been recently made available by several U.S. mobile carriers. Femtocells are mini cell-phone towers that use a broadband connection to extend a wireless signal into dead zones and other territories. Femtocells are a huge step forward for mobile carriers because they provide a cost effective way (the subscriber typically pays for the device and the broadband connection) to expand their networks (both for in-fill and globally). They also open the door to tighter integration between carrier wireless and other Internet services. My previous blogs on femtocells are here and here.

So here's the problem that's waiting to be solved. During a typical day in my home office, I find myself juggling between 5 phone devices: office VoIP extension, home VoIP line, home landline and two mobile phones (three of these devices have incompatible wireless headsets). Many phone conversations also require that I check my Blackberry, online calendar or phonebook. Finding a way to streamline all of the above is something I would pay good money for.

If you are like me, then you can see the ingredients for a winning product recipe. Combine all of these devices into a single unit, throw in a dash of bluetooth, a hint of PBX, and a dolop of webservices connectivity to online APIs like Plaxo or Facebook, and the result would be truly irresistible.

Carriers and service providers have been trying to merge devices and services for years. Despite fitful starts (such as FMC) not much headway has been made. One big reason is that consumers like to be able to pick and choose among the devices and services available from different providers. But, while it may be difficult for a single service provider to meet all needs, a clever device maker could tie them all together with relative ease.

The result: a communications home hub that would give your entire household a single device from which to conduct all communications across different networks and providers.

A couple months back, I attended a dinner organized by Lee Dryburgh (founder of the popular eComm Emerging Communications Conference) and Thomas Howe. The event was a rousing success with many pillars of the VoIP community in attendance. Soon afterwards, the mailing list that had originally been used to organize the dinner venue became a forum for a discussion about whether the success of Skype has obviated the usefullness of the SIP protocol as an enabler of innovation.

Lee's argument in favor of the proposition had three parts. To paraphrase:

(1) Skype has done a better job as a multi-modal client (voice, video, IM and file transfer) than any applications built using the SIP protocol;

(2) the SIP protocol was never designed for, and is therefore ill-suited for, the next generation of communications applications in general (and social networking in particular), and;

(3) the emerging communications industry will stagnate if it continues to view SIP as an acceptable protocol for innovation.

As someone who has been closely involved with the development of OpenSBC, the open source session border controller (OpenSBC is primarily developed and sponsored by Solegy), I always take pleasure (and not a little pride) when I find others who have been able to put it to good use.

The most recent example of this comes from the China Internet Network Information Center (CNNIC) - the Chinese equivalent to InterNIC, among other things. The developers there have used OpenSBC as the foundation for a proof of concept demonstrating that lawful intercept can be successfully implemented in a session border controller, and their proposed architecture has been submitted to the IETF as an RFC.

Lawful Intercept is the process by which legally sanctioned authorities are able to access private communications through a wiretap. This is challenging in the VoIP world for many reasons, not the least of which is because audio payload often follows a different path than call control signals when packets are sent over the Internet. In the United States, the Communications Assistance for Law Enforcement Act (CALEA) mandates that ITSP's and broadband service providers must be able to direct VoIP audio payload to a law enforcement agency, in realtime, upon receipt of a warrant.
Continue Reading...

I am posting the content of a letter from Timothy Karr of FreePress.net concerning the upcoming FCC decision on the future treatment of wireless frequency vacated by digital broadcast TV. An explanation of the issue is here.

As I have previously posted here and here, the availability of wireless spectrum for use by competitive broadband providers is of paramount importance to the future of the communications industry. In the FCC's previous opportunity opportunity to make spectrum available - last years 700Mhz auction - it fortified the telco/celco stranglehold on the U.S. communications industry, with AT&T emerging as the majority winner. Given current technology, the whitespace frequencies represents the last opportunity to carve out a piece of the wireless spectrum for competitive wireless broadband services.

Please take the time to let the FCC know how you feel.

Dear Eric,

Tell the FCC to Stand Up to Scare Tactics and Open White Spaces for Everyone.