Metered Broadband Won't Work, or Won't Matter: Stop focusing on the heavy-tail customers

In a Telephony Online article, we're told that Verizon (Landline) CTO thinks the end will come for flat-rate broadband. He means that you won't be able to pay a flat rate and get unlimited access to the Internet. Apparently, AT&T and others have come out and said the same thing.

The problem is that CTOs are focusing on the heavy-tail customers; it works like this:
a

• Most of your users are clustered toward the bottom. They don't use very much Internet access.
  
• A few of your users are serious; they use twice or three times as much as most of your users.
  
• A very few of the users never stop downloading. They use thousands or millions of times as much bandwidth as their friends.
  

Heavy-tailed distributions skew familiar values like averages and medians; so if you have users that follow a heavy-tailed distribution as described above, and you look at your "average" customer use, you'll get something much larger than your "typical" customer's use.

The simplest approach to avoid metering broadband use is to just fire the customers who are using way too much. If you drop the top 5% of users, you'll regain tons of network capacity.

If you want to use versioning, then you can charge one price that covers nearly everybody, then a higher price for people who go over their limits. This is the standard US cell phone billing plan; you get N minutes, and if you use more than N minutes, then you get charged per minute. But people don't want to have the meter running.

Google Next Big Service: Plain-text transcriptions of Phone Call, Podcast, and Youtube Videos

Google provides some very nice services; Google Books is useful and technically interesting. They started with printed books, and figured out how to de-warp those images to produce nice flat pages.

Then they used Optical Character Recognition (OCR) to convert the photographs of text into actual computer-manageable text. This brings image data into the domain of structured data, and it makes the text searchable. On top of that, it's effectively 500-to-1 compression of the text data (assuming that a 1 MB photograph of a document compresses to about 2 kB of text).

Google is poised to make a similar transformation by converting audio to text. Witness:

• Google purchased "Grand Central" and called it "Google Voice". Each Google Voice user gets voicemail service, and incoming voicemails are automatically transcribed to text for email.
  
• Many people complained about the transcription quality, but last month, in August 2009, Google Voice announced improved transcription service. Therefore, Google has and is improving the technology to automatically transcribe spoken-word audio.
  
• Google Voice functions as type of telephone service, allowing you to place and receive calls. All of the call audio can route through Google Voice's system. This gives Google access to your call audio when using Google Voice.
  
• Google owns Youtube, which has much useful and educational spoken-word material.
  
• Google Books has demonstrated that Google is interested in converting from analog-domain data (printed books) to structured textual data.
  
• Lots of useful, unique spoken-word information is presented in podcast and video form. A few podcasts are recordings of other written material (e.g., the Economist Magazine's podcast and audio edition), but most is probably never published in written format.
  
• Spoken word audio is not directly searchable by Google. Further, audio recordings are quite large; the number of bytes per word is very large. (The previous sentence in written form requires about 200 bytes of storage, including all the formatting around it. A 64 kbps MP3/Ogg Vorbis audio stream of the same sentence would require around 80,000 bytes of storage. The ratio is 400:1, similar to the ratio for printed books to printed text.)
  

Therefore, we should fully expect Google to implement new services:

• Podcasts can be transcribed. This would unlock lots of useful information that is currently inaccessible without a huge commitment of human time.
  
• Youtube videos can be transcribed. For ordinary, spoken-word presentation material, the benefits would be huge; the spoke-word material could be readily indexed, searched, and read. Google could use the temporal redundancy clues (i.e., whether this frame looks a lot like the previous frame; if there is motion in the video, the frames have little temporal redundancy) in the video to determine whether the video is changing often; if it's just a speaker with some text beside his head, they could even show us what's on the screen as the speaker speaks: At the beginnings of sentences, an individual frame can be extracted and shown along with the text.
  
• Google voice telephone calls can be recorded and transcribed. This would be a great way to record notes on work-related phone calls, and then go back and review notes from old calls. Recordings of phone calls are tedious, but transcriptions of those recordings would be fabulously useful.
  

IANAL Analysis of Patent 5,912,888 Claims against VoIP Gateway developers (MetaSwitch, etc.)

Last week, "Network Gateway Solutions LLC" filed a patent infringement case against many (but not all) VoIP gateway vendors. It's court case 1:09-cv-00667-UNA at the moment. (Justia)

You can download the complete court filings here. (I paid the PACER document access fees for you.)

• Complete ZIP file of documents available as of 2009 September 11 (4.5 MB)
  
• Document 1: Main Document, 38 pages
  
• Document 2: PDF of patent, Exhibit A, 46 pages
  
• Document 3: Civil Cover Sheet
  

US Patent 5,912,888 is in question. (US Patent and Trademark Office version.) The Patent was filed originally by US Robotics. It describes a Network Access Server, such as the US Robotics Total Control system. I worked extensively with the US Robotics TC system at a regional ISP in the 1990s. It was eventually sold to and marketed by 3Com.

The patent is a continuation of a patent that was filed June 9, 1994. It describes an "all-digital" system, where the Network Access Server has a T1 link to the telephone network. Back in 1994 and 1995, it was much more common for smallish ISPs to have analog modems connected via RS232 port to a network access server.

What companies are being sued?

Many (but not all) of the big names in VoIP network gateways.

• Adtran Inc -- sued for TA900
  
• Audiocodes Ltd. -- sued for Mediant 1000 MSBG
  
• Audiocodes Inc.
  
• Avaya Inc. -- G350 media gateway
  
• Cisco Systems Inc. -- AS5350 universal gateway
  
• Genband Inc. -- G6
  
• Juniper Networks,Inc. -- J2320
  
• Alcatel-Lucent -- CellPipe CELL-IAD-8T
  
• Alcatel-Lucent USA Inc. -- CELL-IAD-8T
  
• Media5 Corporation -- Mediatrix 3000
  
• Mediatrix Telecom Inc.-- Mediatrix 3000
  
• Metaswitch Inc.-- PB3100 card
  
• Mitel Networks Corporation -- MNC SX-200
  
• Mitel Networks Inc. -- MNi SX-200
  
• Multi-Tech Systems Inc.-- MultiVOIP MVP2410
  
• Patton Electronics Co. -- SmartNode 4960
  
• Quintum Technologies LLC -- Tenor Gateway DX2008
  
• Siemens AG -- HiPath RG2500
  
• Siemens Corporation -- HiPath RG2500
  
• Sonus Networks Inc. -- Sonus GSX9000
  
• Zhone Technologies Inc. -- IMACS-200
  

How did Digium, Taqua, Tekelec, and Nortel get left out of the list? Certainly they didn't actually buy a license for this patent.

So does this patent apply to modern VoIP gateways?

It's a real stretch to adapt this to VoIP equipment. The actual complaint sues on the basis of Claim 2 in the patent. The standard complaint is,

Defendant X, within United States, manufactures, uses, offers for sale, or sells network gateway systems including, but not limited to, Y, that fall within thte '888 patent. These devices have an all-digital network access system that connects remote computers for generating digital data to a network computer on a local or wide are a network via a digital telephone line. The Y includes modems, a telephone control interface, telephone bus, digital signal processing system, parallel bus, and a network gateway controller. At a minimum, X's Y contains each limitation set forth in at least claim 2 of the '888 patent.

The limitations of Claim 2 require (summarized in my language)

• At least one modem
  
• A telephone control interface for TDM management
  
• A telephone bus
  
• A digital signal processor (DSP) system for demodulating time-spaced bus signals into incoming binary data without conversion to analog form
  
• A parallel bus connected to the DSP
  
• A network gateway controller connected to that parallel bus, that formats the data for transmission on the local area network (like Ethernet.
  

The key problem for Network Gateway Solutions, LLC is that VoIP gateways have no modem. They have a digital network interface connected to the PSTN, usually in the form of DS1/T1 or DS3/T3 CSU/DSUs, but they don't have a "modem" in any conventional sense. And the lack of a modem is key to the distinction: this patent '888 relates to computers dialing in over modems, through the PSTN, to a network access server (NAS).

Claims of the Patent vs Modern VoIP Gateways

But let's look at all the claims, because they all hang together.

Patent Claims 1 and 2, "An all-digital network access server connecting remote computers generating digital data to a network computer on a local or wide area network": The inventor claims a system that connects a computer to an analog modem which connects to the digital PSTN, and eventually gets connected to another modem in the Network Access Server. But in a VoIP network, there isn't a computer on the PSTN side: it's a telephone in the kitchen.

Patent Claim 3 discusses "said incoming binary data", which data was generated by the digital computer connected to the analog modem of Claim 1.

Patent Claim 4 discusses the "packet of data from said network computer" (at the service provider) "destined for said remote computers" (connected to the analog modems) "via said digital telephone line". Again, there are no computers at the other end of the PSTN. Just phones in kitchens.

Patent Claim 5 also relates to the digital computer at the other end.

Patent Claim 6 discusses "an all-digital network access server for receiving and transmitting calls representing digital data", but in VoIP calls, the calls don't represent digital data. They represent calls.

The key to the Network Access Server is a digital computer at the far end of the connection, using an analog modem to connect to the PSTN. But in modern VoIP there is no analog modem. You might stretch to say that SIP phones are a type of digital computer, but there is no analog modem involved.

So if none of the claims relate to telephone calls, what could they possibly have on MetaSwitch, AudioCodes, and others?

So who DOES this patent apply to?

I believe this patent does not properly apply to VoIP network gateways because there is no modem involved in a VoIP gateway, as described in patent '888.

I'm not opposed to patents in principle. This all-digital network access system is a useful and innovative invention from the early 1990s. I do think Network Gateway Solutions LLC got one defendant right: The Cisco AS5300, AS5350, AS5400, etc that can operate with MICA modems do have modem capabilities. It appears that they are covered under this patent.

---

I am not a lawyer, but patents are about technology and precise thinking. Both of those are interesting. The Verizon Patent Win Against Vonage is also interesting to study because it applies quite broadly to VoIP Carriers.

TMC Blogger, Keating, wowed by new Decades-Old technology

Tom Keating of the TMC Net "VoIP and Gadgets Blog", please consider researching the facts before posting. You can't trust every company president who booths at the TMC IT Expo.

In a September 1, 2009 posting, "XCast Labs Cuts VoIP Bandwidth Requirements In Half," Keating oohs and ahs over XCast Lab's use of ordinary SIP technology. The technology innovation is described thus:

XCast Labs on the other hand uses their patented "direct RTP" which is able to tunnel through both user's firewalls and setup a direct peer-to-peer (P2P) RTP session between the two users. Once the call is setup, the two users are able to send the RTP media directly to each other. Since both callers are in California, they are just a few hops/routers away from each other thus dramatically reducing latency and jitter. XCast Labs simply maintains a small signaling connection to determine when the call ends for billing purposes.

Keating was "dumbfounded that no one else had thought of this". He should be dumbfounded if no one else had done this. XCast labs is using the the STANDARD way of doing RTP (prior to the hosted VoIP industry). There's nothing new here.

• Look in RFC 3261 that devices SIPv2: In the basic "SIP Trapezoid", the signaling flows between SIP proxies, but the RTP flows along the shortest, most efficient path between the endpoints.
  
  
• Look at the Acme Packet SBC: it supports Media Release directly. It's simple to configure (mm-in-realm=disabled), and used very commonly.
  
  
• Look at the Ditech PeerPoint C100: it supports direct media between endpoints, including those who are NAT'd with certain types of NAT.
  
  
• Look at the MetaSwitch: You can disable a setting called "restricted media" and get the exact behavior they're describing. So any MetaSwitch customer can do it.
  
  
• Look at BroadWorks: It does direct, shortest-path RTP *by default*. The only way to make BroadWorks control the media is to use advanced call mixing or recording features.
  

And let's not forget Verizon's patent, US Patent 6,104,711. In 2006, Vonage was found to be infringing of that patent. That patent covers cases where the IP address of the called party is returned to the calling party. This is exactly the requirement for XCast's direct media to occur!

So this is prior art -- and actually covered under another patent. Verizon has not apparently tried to enforce this patent, yet, against all the other service provides. In fact, Verizon USES BroadWorks and Acme Packet itself in their new fIOS VoIP architecture.

---

Update 2009 September 15: Tom Keating revised his post with some more details on the claim of new technology:

Ok, some clarification from XConnect. The key point which I guess I may not have made clear in my article is that their direct RTP is able to penetrate firewalls and initiate direct RTP sessions. That's their "secret sauce".

Here's what Vlad Smelyansky from XConnect told me:

Your description of our RTP is wrong and the comments (except reference to the patent) are correct. The guy actually picked on the core mistakes and ignored the rest.

There are gazillions of other cases when people are using direct RTP. Our patent and technology is not about the idea of sending traffic directly between end points because that is part of the RFC. Our patent and technology is that we actually can do it between endpoints behind firewall(s) without any special configuration of firewalls (NAT) or deploying additional technologies (STUN) on those endpoints. ACME, Nextone, and Ditech tried to do this and came to the conclusion that it is impossible without additional protocol or special firewall configuration. But if endpoint devices are on a public IP or the user is willing to do special NAT or use STUN, they all can do Direct RTP for last eight-nine years. Our specialty is that we can do it with almost any endpoint behind a firewall and do it totally plug-n-play. No one else can do that.

He referred to my comment about the patent. I am not a lawyer, but Vonage was found infringing of the claim in the patent where the IP address of the called party is provided to the calling party. AFAIK, Verizon hasn't tried to sue anybody else about that claim in US patent 6104711. Perhaps XCast has some way of setting up direct media between the calling and called parties without returning their IP addresses to each other; telepathy, maybe?

Nevertheless, I only mentioned the patent because it's a dated legal document showing that people were thinking about sending media directly between the two voice-over-packet endpoints.

---

(SIP Trapezoid image from https://wiki.sch.bme.hu/bin/view/Infoszak/IpTetelKidolgozasMedia?CGISESSID=0d198e2a22067629087267719d075294, but obviously drawn by Cisco.)