Third Screen

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.

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. Especially after spending billions of dollars to lay fiber, buy frequencies, build cell towers, etc. Yet, the proliferation of OTT services, of which Google Voice is just one example, indicates that this is direction things are headed.

So what will the network operators of the world do? The immediate answer is that they will fight tooth and nail. They will give precedence to their own services using all available means for as long as they possibly can. They will lobby congress (or the relevant governing bodies in other countries) against open access in an effort to maintain the world they know (witness the 700Mhz auctions of 2007). Along the way, innovative services like Google Voice will continue to be suffocated, if not killed outright.

But does it really have to be this way? The answer is a definitive 'No'. Not if network operators started to view the OTT application providers as potential customers instead of competitors. That doesn't mean that application providers should pay "extra" for priority over the last mile, as some network operators have suggested. Rather, it means that network operators should ask themselves "how can we provide value to OTT applications?" rather than fighting them off in congress and the courts (especially the court of public opinion).

When viewed in this way, there is actually quite a bit about network access that need not be dumb:

Payments - The bane of all digital content providers is collecting payment. Without a physical address to which goods may be delivered, digital merchants are constantly battling fraud and chargebacks. Even Paypal, the 800 pound gorilla in the area of online payments, must battle fraud when no physical delivery takes place. A network provider could very easily fill this void. They know where the customer lives, and they have a tangible physical connection to them. Much like NTTDoCoMo has been doing for years with iMode, they could act as a trusted intermediary and OTT application providers would happily pay them for this service.

Presence - Many of the promising applications just over the horizon will depend on the concept of presence. Are you in your car, or at your desk? Is your preferred method of communication a video call or an instant message? Does your device of choice have the capability to support MP3 or AAC as a file format? All of these questions can be answered by presence, and as the entity with a direct connection to your gadget, the pipe provider is in an optimal position to mediate it.

Directory Services - Closely related to the idea of presence are directory services. The ability to reproduce the good old phone book has proven to be one of the most vexing issues of the post-Ma Bell era. Just try to look-up the phone number of a mobile phone or VoIP user and you will understand the dilema. The lack of a trusted repository has caused ambitious attempts at creating online directory information, such as ENUM, to falter. Rather than evolving into online resources, however, the Bells have been steadily shedding their directory services ever since divestiture.

Location - As with presence, the network operator can best determine the actual physical location of the mobile subscriber. The current generation of location-based applications require that the application be 'turned-on' in order to transmit location information to the application provider (hogging precious CPU, battery and screen real estate in the process). A much saner approach would be for the network operator to maintain location information and then provide it to interested applications (with the subscriber's assent or course) upon request. Application providers would be willing to pay for this knowledge.

Marketing Intelligence - Since the pipe is the only common denominator between the subscriber and the many different providers of content the subscriber might access, the pipe owner is in an optimal position to provide marketing intelligence to the content owners. An astute pipe provider could build a comprehensive profile of its subscribers and offer this as a service to content providers. A Neilsen for the mobile age.

I can think of more, much more. But the above list should suffice to make the point.

Of course, there are some rough patches to be navigated. Chief among them is that all of the these services would entail drastic changes for the typical network operator (in terms of culture as much as business model). Further, a payment suitable model would have to be developed. The Internet is at odds with the traditional 'pay for access' model that network operators adhere to. A 'pay for play' model, where the network operator takes a chunk of the application providers paid-for transactions would work much better (again a'la iMode).

Yes, it's still early days. But it is evident to me that network operators must change their way of doing business in order to remain relevant. The question is which network operator will be the first to seize the mantle? Somehow, I don't think it will be AT&T.

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: 

1. 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.
2. 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. 
3. 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. 
4. 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.
    
   
    
5. 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.
    
    
    
6. 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).  
   
    
7. 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).
8. 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.
       
9. 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.

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.

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.

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 Ooma Telo.  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.

Hey Apple, are you listening?

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.  

With Gizmo5 you cannot build a true peer because the source code is not available. Its method of establishing the P2P overlay is proprietary and so without the source code you cannot build a true peer (it does not use the open P2P SIP standard). Therefore using the same yard stick used to denounce Skype as closed, Gizmo5 is also a "closed network."

 

Maybe [Gizmo5] thinks that it's open because it supports the SIP URI names/address space? But I think that would be a weak argument for two main reasons. Firstly because Skype supports not only the private Skype namespace (i.e. a Skype ID) but also the E.164 namespace (i.e. telephone numbers). There is little consumer demand for the additional support of the SIP URI space ... You can call between Skype and Gizmo using the E.164 namespace. I see no reason Skype should have to support the SIP URI namespace to help bolster a competitor! But again, this argument completely lacks vision of the long term evolution in communications, sticking to telephony calls over IP (yawn) being the future.

• Open Source means that the intellectual property used to create software is freely available for anyone to use and/or change.  The Asterisk PBX is the best known example of open source communications software. There are many open source SIP software implementations. Neither Skype nor Gizmo5 is open source in this sense.  
• Open Standard refers to a format or specification that has been agreed upon by concensus, is publicly available for reference, and can only be changed by a governing body through an established process.   The SIP protocol (IETF RFC 3261) is an open standard in this sense.  The Skype protocol, was created by Skype and is known and controlled only by Skype.   There may be some truth to belief held by many that it is a "better" protocol than SIP.  But an open standard it is not.
• Open Platform refers primarily to a business model where the owner of a network (be it a physical network like Verizon, or a social network such as Facebook) allows third parties to access its users for the purpose of pursuing commercial activities. Openess in this regard can vary greatly depending on the level of access that the network owner grants to third parties.  Skype is an open platform to the extent that it publishes an API that allows third parties to create complemetary products/services and conduct commerce with Skype subscribers.  Gizmo is an open platform to the extent that it's users are free to call and be called from other VoIP networks.  It makes no sense to talk about SIP in terms of an open platform, since it is a protocol.  

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.   

Typically, lawful intercept is performed in the core network using gear from vendors such as Narus or IP Fabric.  However, the RFC authors posit that the best place to perform this function for SIP traffic is at the session border controller.  Their motivation and intent are nicely stated in the introduction to the RFC:

One of the primary problems that service providers face when managing VoIP and multimedia calls is the separation of the signaling and media streams.  In other words it is quite possible that the two streams may take completely different paths through the network.  In addition, even when they do pass through the same device, it may not be aware of the relationship between the streams.  Some devices within the network are however specifically designed to understand and manage the separate signaling and media streams - session border controllers (SBC)[8].

SBC is a session-aware device that manages VoIP calls at the borders of an IP network.  Unlike most network devices, SBC are aware of the relationship between the two parts of a VoIP call: signaling and media.  Session Border Controllers handle both media and signaling, intercept can be performed in a completely undetectable manner.

SBCs usually sit between two service provider networks in a peering environment, or between an access network and a backbone network to provide service to residential and/or enterprise customers.  They typically are deployed at the border between two VoIP networks, and they offer an ideal location to implement a Lawful Intercept solution.

Whilst the detailed requirements for VoIP Lawful Interception may differ from one jurisdiction to another, the general requirements are the same.  The LI system must provide transparent interception of specified traffic only and the subject must not be aware of the intercept.  The service provided to other users must not be affected during interception.

As part of the effort in developing a broadband VoIP lawful interception architecture, we implemented a prototype and conducted evaluation experiments on the prototype system.  In this document, we first describe the prototype solutions and then report experimental results.  We hope that this document can provide useful information to those interested in the subject.

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. Sign Our Halloween Action Card

"They're Ba-ack..."

This Halloween, the powerful lobbyists at the National Association of Broadcasters (NAB) are trying to scare Washington with horror stories about "white spaces" -- vacant TV channels that can be used to bring high-speed Internet to rural and low-income Americans across the country.

The NAB's hired guns have bombarded policy makers with false claims in a desperate, last-ditch attempt to hoard these airwaves and to disrupt a critical FCC vote taking place in just six days.

The FCC's five commissioners must not buckle under the intense lobbying pressure:

Tell the FCC: Don't Give in to NAB Scare Tactics

Here are the facts:

1. If we open white spaces now, we can bring the social and economic benefits of a fast Internet connection to tens of millions of Americans now on the wrong side of the digital divide.

 

2. FCC engineers have tested white spaces devices and determined that the technology can deliver high-speed wireless Internet, without interfering with adjacent TV broadcasts.

 

3. The NAB and Big Media are doing everything in their power to close off access to white spaces because they fear competition from new innovators and losing control of the public airwaves.

The NAB is furiously spending millions of dollars on dirty tricks and political intimidation to scare the FCC away from white spaces. They have high-priced lawyers and lobbyists, but we have you.

Take just one minute to sign this Halloween action card and forward it to your friends. Free Press will deliver your cards to the FCC on Halloween and make sure they "treat" us by opening white spaces for eveyone's benefit:

This Halloween: Stand Up to the Lobbyists' Scare Tactics

With your support today, we'll expose Big Media's fear-mongering and make certain that white spaces are used to make fast, affordable Internet service a reality for everyone.

Thanks,

Timothy Karr
Campaign Director
Free Press
www.freepress.net

Today's New York Times contained an article concerning the increase in the cost of wholesale products.   According to the piece:


Taking the sum of individual rates in the grnVoIP A-Z rate deck for the  month of July 2007, divided by the total number of destinations, I arrived at an average rate of $0.15845.    Using the same calculation for the July 2008 rates, I got $0.15648.  Using sophisticated reverse regression analysis, two rolls of duct tape, and the shoelaces from an old pair of desert boots,  I then calculated that the average rate from July 2007 to July 2008 has actually decreased by approximately 1 percent.

So, by this metric at least, it appears that global inflationary trends have not affected the VoIP industry... yet.

Note:  In the interest of full disclosure, grnVoIP (a provider of pay-as-you-go wholesale SIP termination) is a customer of my company Solegy, and I am a member of their advisory board.

After years of searching, my prayers have finally been answered; I have found a WiFi VoIP phone that I can actually use.   The object of my desire is the Blackberry 8820 paired with T-Mobile's @Home service.  The irony of it is that it is not a SIP phone!

For years, I have searched for a convenient way to bring my office extension with me when I travel outside of the US.   For a while, I carried around an ATA (much to my wife's dismay) almost everywhere .  But, finding an Ethernet port to plug it into was often impossible.  When the first WiFi SIP phones turned up circa 2004, my inner geek rejoiced as my imagination ran wild with the possibilities.  Alas, the reality turned out to be wanting.   Weaknesses such as  power-hungry WiFi chipsets (resulting in poor battery life) and the inability to handoff when moving between WiFi access points plagued every device I tested.    Even the most recent unit I tried, Nokia's stylish E51, disappointed.   The gadget graveyard in my basement is a field of broken dreams as a result.

So, when I recently replaced my ailing Curve with the new Blackberry 8820, it was with low expectations.   In fact, I had avoided trying T-Mobile's @Home service because of poor reviews on the early handsets (the service was initially launched with the Nokia 6086 and Samsung t409).   The @Home service uses WiFi access points to allow users to connect from home or the office to make calls at landline rates  (info about @Home is here)  Much to my surprise though, they got it right with the 8820.  

This is not meant to be a review of the 8820, so I won't get into its many great features.   Let it suffice to say that the phone is eminently useable and has the same polish and functionality that crackberry addicts love and expect  (the combination of GPS and Google Maps alone is worth the price of the phone).  The point is that  I was able to place and receive calls from WiFi hotspots in Hong Kong (where free WiFi abounds) and Manila (which is decidedly less WiFi friendly than Hong Kong) as if I were sitting at my desk in the middle of Manhattan.   Amazing!

The only downside (and its not REALLY) is that a SIP device maker didn't come up with it first.  The 8820 uses GSM-over-IP  (there is no SIP client in the device) to allow seamless transition between cellular and hotspot coverage.  Still VoIP...  just not my favorite flavour.   Nonetheless the fundamentals of the phone  (WiFi chipset, battery life, user interface) lend themselves equally well to a SIP implementation.  I look forward to the day when cellco's will embrace the 2-sided telecom business model and allow such an animal to be created.

The recent acquisition of communications API provider Ribbit by BT has caused quite a stir within the VoIP industry.    Much of the commentary concerns the $105 Million price tag for the pre-revenue start-up (Thomas Howe explains why the deal makes sense for BT on the Telco 2.0 blog).

Another interesting aspect, however, is how this deal casts Adobe's Flash player and AIR SDK to the forefront as an enabler of communications applications.  In essence, Ribbit's appeal is that it allows web developers to create communications enabled business process (CEBP) apps without having to know anything about SIP or the underlying protocols related to VoIP.   To do this, Ribbit leveraged Adobe's cross-platform AIR runtime environment to provide a desktop programming environment that is familiar to most web developers. 

It is no secret that Adobe has had its eye on communications developers for a while now.  It went so far as to announce a project that would embed a SIP stack directly into the Flash code in September 2007.   Named Pacifica, the project appears to have been stillborn however, as very little information or anything else has emerged since then  (the official Pacifica blog is rather sparse).  And, while several other start-ups have created softphones using AIR (the AIR showcase is here) and Communigate uses AIR for its very impressive Pronto unified communications suite, to my knowledge, no major service enterprise has yet built a voice app on it (SIP or otherwise).

With Ribbit's newfound prominence however, that will change.  I won't go so far as to say that developers will flock to Ribbit and BT to 'communications enable' their desktop apps.  But, I will venture to say that Adobe and AIR will be on the short list of all future CEBP projects as a result of Ribbit's success.  Who knows, maybe this will even pump some life back into Pacifica.