In the ITEXPO Press Room I just met with Cliff Rees, President & CEO of XCast Labs. They have some interesting VoIP technology, including a patent called "direct RTP" which reduces VoIP bandwidth requirements in half. The example Cliff gave was a VoIP call from Los Angeles to San Francisco using Net2Phone based out of New Jersey. When the Los Angeles user calls the San Francisco user, it initiates a 90Kbps IP call cross-country to Net2Phone's headquarters in New Jersey. Net2Phone then routes the call cross-country back to a termination gateway which connects to the San Francisco user. This too uses 90Kbps of bandwidth for a total of 180Kbps for the RTP media. The Net2Phone server in New Jersey has to allocate and hold 180Kbps of bandwidth for each call. Additionally, the call has to cross the country twice which adds more jitter and latency.
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.
When Cliff from XCast Labs explained to this me, I was dumbfounded that no one else had thought of this. It seemed so obvious that a direct RTP session would result in less bandwidth requirements, better latency, and better voice quality. Their technology sounded eerily similar to Skype's ability to penetrate firewalls and initiate high quality peer-to-peer calls so I made the analogy with Skype and Cliff agreed they are very similar. Though in the case of XCast Labs they use standard SIP while Skype uses proprietary technology. Further, XCast Labs offers both a consumer (residential) and a hosted business offering with advanced functionality such as call parking, call transfer, etc. They also support video calls and video mail. They support both Polycom video phones as well as Grandstream, including the new GVX3140 H.264 video phone seen here:
XCast Labs developed everything in-house, including their own SIP stack and softswitch so they are not paying Sonus Networks, Acme Packet, Broadsoft, etc. any sort of licensing fees. They told me this helps them be extremely competitive when compared to other VoIP providers. They offer their own residential VoIP service but they also sell to the cable MSOs who white label it for their Triple Play packages. Lastly, XCast Labs said they support HD Voice using G.722 so if you have a G.722 end device you have have HD audio.
I Would like to read more about standard SIP. I use Vopium to call my family in India.
Of course you were dumbfounded that no one else had thought of this: Because XCast labs is using the the STANDARD way of doing RTP (prior to the hosted VoIP industry). There's nothing new here.
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.
Tom, I agree with Mark that they are probably using a variation of the well-known FW/NAT traversal procedure as codified in ICE. But I am surprised to hear that Verizon has a patent on that. Gaming applications have used such a scheme for some time now. If I recall correctly, VZ/Vonage dispute was related to PSTN interconnection.
Same feelings as Adrain here, sounds very interesting.
It’s funny how many of today's technological advances are usually a ‘tweak’ here or there on something already available in some form. Mark’s points seem to provide a great example of this.
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.
Tom -- Thanks for getting some clarification.
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.
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.
If XCast can setup direct media between any two port-restricted NAT'd endpoints, then congratulations are indeed in order.
Tom, it looks like you need to get more clarification. From your description and the new clarification it is not clear what is the new procedure. A quick search at USPTO site for "direct RTP" brings up a patent application 2009077245, "Client-to-client Direct RTP Exchange in a Managed Client-Server Network". Since the first inventor is also a cpo-founder and CTO of Xcast, I am assuming that the procedure described in that application is the correct reference.
I am not able to see how the procedure described is much different than ICE. Indeed, their procedure does not cover some of the cases, like when an end-point has multiple IP addresses. Assuming that they are not trying to patent ICE procedure and ignoring the additional cases covered by ICE, the two procedures are materially the same and yields the result using the same amount of overhead. So it is evident that I am missing something big in their proposed scheme. Interestingly, they mention STUN as a prior art, but do not mention ICE.
Folks what about the LI aspect? No one has mentioned CALEA requirements that they aren't able to meet.