VOIP services

Google: Resistance Is Futile...

Internet IM/VOIP services offered by Skype Ltd. and MSN Messenger have millions of users, but can't talk to one another. Google (Nasdaq: GOOG), however, says its Google Talk product is built on the sort of open standard that will eventually “federate” all the instant messenger and VOIP clients out there.

Google Talk product manager Mike Jazayeri likens the situation to the early days of email, when only people using the same client could email one another. Eventually they all adopted one open standard allowing all clients to interoperate.

For Internet-based VOIP, Google believes its XMPP -- also known as Jabber -- is that standard. “We said we were going to use an open standard from day one,” Jazayeri says. Other IM clients such as Apple Inc. (Nasdaq: AAPL)'s iChat and Cerulean Studios' Trillian also are underpinned by the XMPP standard. (See Google Jabbers On.)

When email federation happened, usage of email exploded. Usage of wireless text messaging also grew exponentially after the wireless service providers adopted the common SMS standard enabling, for example, a Cingular Wireless customer to send messages to a Sprint Wireless (NYSE: PCS) customer.

“We think it's inevitable that IM starts using an open standard,” Jazayeri says. If and when that happens, and if history is any guide, the spike in usage could take away still more call minutes from the wireline, wireless, and VOIP services of traditional voice providers.

The movement of IM/VOIP clients onto wireless devices also may help bump up usage. Jazayeri points out that Nokia Corp. (NYSE: NOK), Sony Corp. (NYSE: SNE), and BlackBerry (Blackberry) have built Google Talk into their wireless devices, effectively freeing the IM/voice service from the PC desktop. (See Nokia Adds Google Talk.) Of course Google isn't the only IM/voice provider claiming to use an "open" standard -- Yahoo Inc. (Nasdaq: YHOO) and Microsoft Corp. (Nasdaq: MSFT) make similar claims. Jazayeri argues that Google Talk’s XMPP is the only IM standard that’s been approved by a real industry body, the Internet Engineering Task Force (IETF) . (See Jabber Jingles All the Way.)

“Microsoft will tell you that their client is SIP compliant, but what they mean is that in their enterprise product they support SIP, but not their consumer product,” Jazayeri says.

Yahoo’s senior director of voice product management Jeff Bonforte told Light Reading some months ago that he is reluctant to open his service to others, for security reasons. VOIP has its own flavor of spam, called “SPIM,” and Bonforte says he doesn’t want to subject his users to the abuses of unscrupulous users from other services. SPIM can arrive as a junk IM or as a recorded or live voice call from somebody somewhere selling something. (See Yahoo Launches VOIP Service.)

Jazayeri isn’t having it. “It’s a smokescreen,” he says of Bonforte’s reasoning. Jazayeri says SPIM filtering technology has advanced to a point where the vast majority of the stuff is blocked. Google Talk users have control over their buddy lists, he explains, and the client won’t take IMs or calls from strangers. “That has resulted in zero SPIM on our network,” Jazayeri says.

While some competing IM companies allow their software clients to interoperate, most are closed to outsiders. Microsoft’s MSN Messenger struck a federation agreement with Yahoo’s Messenger product last October and, the companies say, it created the largest IM community in the world with around 275 million users. (See MSN, Yahoo Link IM Services.)

eBay Inc. (Nasdaq: EBAY)'s Skype service remains closed, but a recent advertising agreement between Google and eBay could lead to a peering arrangement with Google Talk users. Jazayeri says such an interconnection would allow the exchange of IMs between the two services, but not necessarily voice. (See Google, EBay Team .)

Whether or not a given service is open depends a lot on when it entered the market. “You can look back at history and see that people who came in early went to the walled garden approach -- email was almost entirely walled garden in its early days,” Jazayeri says. Services that picked up a large user base early on tend to wall their users in, he contends, while later entrants have less to lose and more to gain by federating.

Regardless, as services begin to catch on, Jazayeri says, the “walled garden” players are eventually moved by consumer demand to open their services to others. Players that don’t “will have a very difficult time."

— Mark Sullivan, Reporter, Light Reading

Page 1 / 2   >   >>
OldPOTS 12/5/2012 | 3:39:22 AM
re: Google: Resistance Is Futile... Just join Google and get SPIM/SPAM from everywhere those hackers can hide?

mr zippy 12/5/2012 | 3:39:21 AM
re: Google: Resistance Is Futile... btw, I tried to point this out to the XMPP developers a while back, and they'd already decided that they were going to fix these problems by spitting messages into a header and a body, and then allowing the body to be encrypted end-to-end. Unfortunately that doesn't protect against the centralised server know who you're talking to, which is still quite useful to an adversary. It's still not as end-to-end security as would be useful and ideal.

They also said they were introducing server redundancy. That sounds fine until you realise that they actually weren't solving the problem of your conversation continuing across a server failure. Who wants their conversation cut off mid sentence, when some server somewhere has failed, when they've still got an IP path to their IM peer ?

Because they were so stuck in the "client-server" mindset, they couldn't see how adopting a proper peer-to-peer application architecture would make these problems just disappear, rather than them having to develop work arounds that never fully solve these problems.
mr zippy 12/5/2012 | 3:39:21 AM
re: Google: Resistance Is Futile... IM type communications is naturally peer-to-peer. You and you IM session partner are both transmitters and receivers, or both "clients" and "servers" at the same time.

If you can directly communicate with your peer (as you can on the Internet, that's the way it is designed), why should communications go through a server, which introduces both a single point of failure as well as a performance / scalability bottleneck. It also adds another party who's privy to the conversation, and therefore needs to be trusted. That might be a reasonable requirement for some corporations who wish to record their employees IM conversations (although you have to wonder how they're controlling what their employees might be showing or telling outsiders after they leave work for the day).

The XMPP model always involves a server, with all messages going through the server. If the server fails (which has happened to me), you IM session fails, even though you may, or are actually likely to have a direct IP path still available between you and your IM session peer. Last I looked into it, it only supported encryption between IM clients and the server. IOW, you might think you have a secure conversation, but reality is the security is not and could not be guaranteed to be end-to-end, and end-to-end is all that you care about - you don't want anybody else other than your IM session to be able to see what you're typing. You had no assurance that your IM session peer also was using encryption with the server. Regardless, the server needed to perform decryption to route the messages anyway.

A hybrid XMPP architecture might have been better, where a server is used to track presence and location, and then the IM sessions were established directly between "clients". That being said, the various SIP options, including pure and simple DNS, are probably ideal, as SIP follows the Internet peer-to-peer model.

It seems to me that XMPP/Jabber has been designed by people who don't understand or aren't aware of the fundamentals of how applications are designed to fit the Internet model, which if followed, gives them robustness against localalised and transient network failures, and scalability. For them, the Internet is purely "client / server", so that is how they've built a naturally peer-to-peer application.
mr zippy 12/5/2012 | 3:39:20 AM
re: Google: Resistance Is Futile... I did ask about any architectural documents that discussed design decisions, and got the "refer to the RFC drafts". They were full of client-server model descriptions, so I realised that it was probably going to be an uphill battle trying to suggest a peer-to-peer model, so I didn't persist.

Regarding the redundant server/end-to-end discussion, I'm pretty that was on slashdot. Who knows, I could have been discussing it with one of the XMPP/Jabber developers.

Anyway, I think it is a good example of where the "default" client/server model is inadequate for Internet based applications. The default should be peer-to-peer (with the benefit of robustness and scalability), with the introduction of client/server only when the problem can't be solved or solved easily with a peer-to-peer architecture.
optodoofus 12/5/2012 | 3:39:19 AM
re: Google: Resistance Is Futile... Mr. Zippy,

It sounds like a great business opportunity to me. Instead of venting on the LR chat room, why don't you get out in your garage and start making it happen?

The one problem I see with peer-to-peer is who-ya-gonna-call when it doesn't work? If there is no central point of control, then there is no one responsible for making sure the service works. It's usually not a problem for the tech savvy, but could be a major problem for the average computer user.

spelurker 12/5/2012 | 3:39:17 AM
re: Google: Resistance Is Futile... > It sounds like a great business opportunity to me.

Not really. It's not a good business opportunity to make an open-interface peer-to-peer application, because there's really no way to make money.
This is probably why the designers went with a client-server approach. They work for some company, and their company can make money either by operating the servers or by developing a robust/scalable server application. So naturally, they are thinking in that direction.
optodoofus 12/5/2012 | 3:39:17 AM
re: Google: Resistance Is Futile... > Not really.

Exactly. And that is why I said Mr. Zippy should work on it and didn't hightail it out to my own garage to do it myself. (This is the problem with sarcasm in the written medium; if you don't apply thickly enough it has no effect; too thick and you look mean.)

zwixard 12/5/2012 | 3:39:16 AM
re: Google: Resistance Is Futile... The world is not black and white but a mixture of colors. So are the software applications.
For IM and VoIP, the presence part of the solution suits the server model, which is a database application. The usage part is best for peer-to-peer.
lightreader101 12/5/2012 | 3:39:16 AM
re: Google: Resistance Is Futile... Mr. Zippy,
Conceptually you are correct: peer-to-peer model is more efficient, secure, and attractive than the client-server-server-client model.
In reality, pure peer-to-peer model has limitations and must utilize various tricks to bypass them. For example, how can two users behind NAT communicate, if their NAT servers change local port mapping depending on destination IP & port numbers? In addition, how can a Skype user logon to a new PC and find all his/her contact entries show up? All those things need the help from one or multiple middle guy(s) and servers.
It's not a news that Skype asks all users to agree on Article 4 (Utilization of your computer) of their End User License Agreement. Basically it allows any PC to be the middle guy for Skype network.
Therefore, it could be hard to argue which is more secure and efficient--the model of using random middle guys or a model to use trusted servers (note: end-to-end encryption still possible on the server model). It could be a serious security concern if your equipment is selected as the middle guy at times for unknown communication.
An enterprise may utilize its own XMPP servers for internal and/or external communication but disallow employees to open any peer-to-peer communcation applications.
rwelbourn 12/5/2012 | 3:39:15 AM
re: Google: Resistance Is Futile... SIP/SIMPLE-based IM is not necessarily any better than XMPP; it's just a different protocol, but in reality it operates in much the same way.

Although SIP can, in theory, operate in a peer-to-peer manner, in practice it almost always goes through some kind of server, for reasons of authentication, registering presence, registering location, and (not least) NAT traversal.

Both SIMPLE and XMPP use centralized servers for message passing; SIP MESSAGE packets go exactly the same route as INVITEs, REGISTERs, NOTIFYs and SUBSCRIBEs.

Rob W.
Page 1 / 2   >   >>
Sign In