SIP Location Conveyance

The IETF SIP Working Group has a sub-group working on SIP Location Conveyance. The current draft is
draft-ietf-sip-location-conveyance

This is proposed as a tool to enable SIP endpoints (such as SIP phones or ATAs) or their proxy upstream to convey the calling party's location to the called party. The imagined applications are:

Calling an emergency number, like 911, so the first-responders know how to reach you

Calling for pizza, so the pizza makes it to the right place.

This standard doensn't try to solve the problem of knowing where the user is. But it would allow a service provider who maintains a registered physical address for an endpoint to add that information before sending the call to a PSAP (Public Service Answering Point, i.e., an inbound call center for emergencies). In this sense, the standard would replace the ALI (Automatic Line Identification) database lookups with a service-provider lookup. However, if the SIP endpoint knew where it was -- say, based on GPS -- then the endpoint could convey that directly using this standard.

The argument on the conference call was that, for emergency purposes, the PSAP would generally trust the information provided by the calling endpoint, rather than what the service provider knows as the location. This is based on the assumption that the calling endpoint may be moved without telling the service provider in the middle.

OTOH, pizza delivery would likely trust what the service provider says.

It appears the standard will define a way to convey multiple locations; so, e.g., the service provider indicates one location, and the endpoint another. Or maybe the endpoint provides multiple locations itself. But nobody knows the semantics for that -- i.e., what it means.

This standards also exceeds the signaling capability of the traditional protocols, like ISDN ISUP or SS7. They don't have a way of conveying location, so this data couldn't be passed through an ordinary PSTN gateway. To make use of it, the called parties (like Domino's Pizza, or the local PSAP) would need to have VoIP interconnection with the calling party's service provider.

Because an intermediate SIP proxy or B2BUA can insert new location information, the standard could be deployed without major modifications to most SIP endpoints. Instead, it could be implemented in the service provider's core gear, which might be BroadSoft, MetaSwitch, Sylantro, Asterisk, etc.

The biggest "upset" from this standard could be the displacement of the ALI database. Who knows whether that'll be accepted.

Verizon vs. Vonage on patents -- consensus growing on "direct media" issue

Consensus is growing among some system implementors that Verizon's patents for calling to PSTN and VoIP endpoints is tightly coupled to "direct media". This article discusses the three claims on which Vonage was found infringing and how it relates to other hosted VoIP carriers, like those using MetaSwitch, Sylantro, or BroadSoft.

US Patent 6,104,711, Claim 20 talks about making calls directly to VoIP endpoints. One requirement of this system is that the service provider system returns the actual IP address of the called VoIP endpoint. But in many VoIP systems, this isn't the case; a call agent (like that in a MetaSwitch VP3510) or a Session Border Controller (SBC, like the Acme Packet SD or Ditech C100) actually gets the media first. However, in many systems even with SBCs, the media flows directly between endpoints when it can; e.g., when the calling and called party are on the same local network (or, strictly speaking, behind the same NAT router). So in those cases, the media is direct, and the Verizon patent may cover that case.

US Patent 6,282,574, Claim 27 discusses calls to PSTN endpoints. And, just like the '711 patent, the IP address of the PSTN gateway has to be returned. But in many systems, the IP address of the PSTN gateway is never returned; instead, an SBC in the middle mediates the media. However, if you're using a local, enterprise gateway, then the IP address of that gateway may well be returned to the calling party.

Would a jury see it this way? I don't know. They may adopt some abstraction that says that the SBC becomes part of the media gateway as a larger system, or the SBC represents the PSTN endpoint. Under that reasoning, even calling via an SBC could be infringing. But that seems clearly outside the scope of the patent claims.

US Patent 6,539,880, Claims 1, 6, 7, and 8 talks about calls to a wireless handset, and it doesn't have the same IP-address-of-the-called-endpoint restriction. This patent covers the VoIP call no matter how it's signaled. The classic case for this is a SIP soft client (such as CounterPath X-Ten) calling to a SIP-registered WiFi phone via a registrar. (Replace "SIP" in hat sentence with "H.323" and it applies just as much. However, the patent requires "registration", so MGCP probably wouldn't apply -- unless we consider an RSIP message to be a sort of registration.) But it's unclear to me whether this patent could cover a cordless phone connected to an ATA (such as the Linksys/Sipura SPA-2100), or calls from an SIP phone or an ATA, or from a PSTN gateway.

Then there's the prior-art question -- H.323 was already standardized by the time the Verizon patents were filed. And SIP was well along the path. H.323 and SIP were designed specifically to support networks like the one Verizon patented. Does that pre-existence of an enabling technology make this un-patentable?

Verizon vs. Vonage: We need some details!

Verizon sued Vonage in case 1:06-cv-00682-CMH-BRP in the US District Court of the Eastern Virgina region. Verizon has won, for now. As people who make VoIP work, the engineers and operators of VoIP systems need some actual useful information to work with to build networks that observe Verizon's patents. This posting is just an attempt to collect some of that info in a useful place.

The web is littered with jumpy commentary on the Verizon vs. Vonage patent case. Some reports of the outcome of the case just quote Verizon's press release.

Wikipedia's page on Vonage actually lists some patent numbers. However, the Talk page doesn't substantiate where those patent numbers came from.

The actual Federal documents in the case are tucked away in the arcane PACER system. I have cached Document 371, a Court Order on Claim Construction of the Patents-in-Suit.

Russell Shaw of ZDNet has a few articles on three of the patents:

• US Patent 6,104,711
  
• US Patent 6,282,574
  
• US Patent 6,359,880
  

In addition, I have a cache of the Civil Docket for the case. Some interesting entries include:

Minute Entry for proceedings held before Judge Claude M. Hilton : Jury Trial cont'd on 3/7/2007. Appearances as previous. Preliminary matters heard. Exhibits admitted. Jury instruction conference held w/counsel. Closing arguments heard. The Court charged the jury and the jury retired to deliberate (@2:50). The Court rec'd a question from the jury @ 5:50 re: definitions of 'name translation' and 'method comprising'. Question to be discussed w/counsel tomorrow morning. Jury excused to return 3/8/07 @ 10:00 for further deliberations. (Court Reporter Linnell/Thomson.) (tarm, ) (Entered: 03/08/2007)

Minute Entry for proceedings held before Judge Claude M. Hilton : Jury Trial cont'd on 3/8/2007. Appearances as previous. Jury question rec'd 3/7/07 addressed w/counsel. Jury reinstructed re: name translation and given the definition of 'method comprising'. The jury returned to the jury room to continue deliberations. The jury returned to the courtroom at 2:50 w/a verdict finding infringement of claim 27 of the '574 patent, claim 20 of the '711 patent and Claims 1, 6, 7, and 8 of the '880 patent and finding that the infringement was not willful. The jury did not find infringement of claims 1 & 2 of the '869 patent and Claims 1 & 2 of the '275 patent. The jury found none of the claims at issue in patents '574, '711, '869, '275, or '880 to be invalid. The jury awarded pltfs damages in the amount of $58,000,000.00 and found the reasonable royalty percentage to be 5.5%. Judgment to be entered in accordance with the verdict. Pltfs motion for Permanent Injunction to heard on 3/23/07 @ 10:00. (Court Reporter Linnell.) (tarm, ) (Entered: 03/08/2007)

VON no shows; fixed-mobile convergence; Skype mobile

VON trade show: the no-show list

San Jose, CA -- The VON spring 2007 trade-show this year was notable for who was absent. Among the non-attenders: Cisco, Lucent, and Nortel. Sonus didn't have a booth, but they rented some meeting rooms.

To be precise, Cisco was present in the logos of some literature in the Linksys booth, but the extremely popular Cisco SIP phones and AS5400 gateways were not represented at all.

I heard several folks say they wouldn't be back for spring next year; some of these had the big expensive booths, too.

It just seems like there are too many VON shows; i.e., one too many in the US. The Boston fall VON seems like plenty. Perhaps if they had fewer, they could also be more choosy about their speakers.

Fixed-Mobile Convergence -- All in the edge device?

One speaker from Motorola, John Waclawsky, argued that the edge device -- e.g., the cell phone -- would be the key to future innovation. And maybe it will be. But I didn't see in his model exactly how you're going to get the mobile carriers to play along. By this I mean: if I have a PSTN number, that number can only reside at one LRN, an that LRN can only be routed to one switch. So what if my device does GSM and WiFi -- if I leave the GSM network and register via VoIP with WiFi, I won't be able to get calls that go to my PSTN number hosted on the GSM-network's switch. At least, not by default.

We could setup number forwarding, so that calls will try the cell phone network first, then be forwarded to a VoIP number. That might work OK. Outbound caller ID might be tricky to get right, depending on where you hosted the number and how you forwarded the number. Another, more sophisticated and robust mechanism might be integrating with a mobile carrier's network to become a visitor network. My point here is that just enabling an endpoint device to talk lots of wireless protocols doesn't mean its user will be able to receive telephone calls automatically.

Perhaps the IMS registration mechanism is a reasonable way of doing this. I haven't seen much of IMS that seemed innovative. Mostly just acronyms and Bellheads running another good idea into the ground. I'd like to be disproved in this.

Skype's New Services

I just chatted with one of Pulver Media's journalists from Israel as he and I were leaving the VON show in San Jose. In his view, the Skype CEO's talk at the show was the big news. The announcements:

Skype will provide a front-end to Paypal money transfers between Skype users. Will that be useful? Who knows. On the face, it's not exactly technically innovative, but sometimes baby steps in usability can make let you cross the line between hassle and usefulness.

Skype will have a version that runs over EV-DO and other broadband wireless services. That seems like a nifty implementation. But who will pay $50 or $100 per month for high-speed wireless Internet service...then use Skype on top of it? According to my Israeli friend, high-speed wireless service is cheaper in Israel -- $10/month for 1 GB of transfers. Assuming a 8 kbps codec, 1 GB is about 113 hours of talking. (

1*10^9 [gigabytes / byte] / 8 [kbps] * 1024 [bits/kb] * 1.2 [overhead for IP] * 2 [individual streams in the conversation] / 8 [bytes per bit] / 3600 [seconds per hour]

)

The journalist was impressed by the way Skype is piggybacking on systems that other people operate. Skype definitely isn't cheating anybody, though -- they're completely dependent on infrastructure provided by others. This is classic layered application development. In effect, Skype is offering the application, while the ISPs offer the transport network.

But the ISPs all want to do "triple play" -- i.e., they want to sell you telephone service, Internet service, and television programming (a la Cable TV). It's difficult to buy high-speed residential Internet service from a telco without buying telephone service along with it (i.e., "naked DSL" is rare). The cable carriers are glad to just sell Internet service, but they'd love to bundle in their overpriced TV and phone service. So as a business proposition which I am completely unqualified to analyze, Skype will have a hard time competing with existing carriers for the voice calls.

OTOH, Skype is a handy supplemental tool for people who are already buying all of those services. If you already have Internet service, then Skype gives you something else to do with it.