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   >   >>
mr zippy 12/5/2012 | 3:39:12 AM
re: Google: Resistance Is Futile... "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."

I don't see how the behind the scenes architecture of the application has any effect on the user of the application. Whether it is client/server or peer-to-peer, all an average computer use cares about is is the person I want to talk to available, and can I start and continue a session with them. That's easier to achieve and more likely to happen in a peer-to-peer model, as the resources required are spread out or distributed and closer to the end points. The resource "path" requirements for the session are also more direct between the peer-to-peer end-points.

As an example, imagine I'm going to use Google's XMPP service. The "ulimate" in client server would be for them to run all their servers in one of their facilities somewhere in the US. Well, I live in Australia, so if Australia somehow gets cut off from the world, then I'm stuck, even though I'm still in a country with available Internet connectivity for all 20 Million or so of us, so there's still plenty of people I can talk to. I'd be better to choose a XMPP provider who's located in Australia. Then again, what if my city becomes cut off from the rest of the world, there's still people in my city I talk to - probably more than anywhere else in the country or world. Maybe I need to find a local XMPP provider in my City. Hmm, that's also vulnerable if my suburb gets cut off. Maybe, if I want the job done properly, I should do it myself, so that my IM capability fails only if the two end-points that would be involved failed, or if there was no IP path between them.

Regarding control and responsibility, there are two things that dictate that. Who owns it, or who's paid because they own it.

I own my PC, so I have to assume responsibility for making sure it's running. My IM session partner's would have the same responsibilty. If they're having trouble with their, I may be able to help them fix those problems if they can't - it's in my interests to do so if I want to talk to them.

I don't own my ISPs network, but I pay them to make it available - to keep it running - which includes making sure their upstream providers also provide availability. If my ISP doesn't provide availabilty, I'll find a different one that does.
mr zippy 12/5/2012 | 3:39:13 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."

The model is supposed to be that the SIP signalling messages may (but not must) go through server infrastructure, with the fundamental objective of converting that SIP address into a current IP address for the end-point. Once that is resolved, the media streams are intended to go direct between the end-points. Swap media streams for IM session, and that's the model that I think XMPP should follow. So, as somebody else said, the architecture tends to be hybrid, with the least amount of "client server", and client server being constrained to short lived transactions - the call signalling, rather than the actual voice data. Short lived transactions are fare less vulnerable to or impacted by server failure, and even then that can be designed around - DNS is a good example of how to do it.

Although people need to or tend to put in servers for SIP e.g. for NAT traversal, or Media Gateways, they tend to be closer to the "clients". The observation is that the closer to the clients the server is, the less scaling problems you have, and the less impact a server failure will have to a number of clients. The further away from the clients the server is (e.g. somewhere on the Internet, verses somewhere on your own network), which usually means more clients will connect to it, the harder (or more expensive) it is to increase performance (or scale it), and the harder it is to provide availability.

When I suffered a remote server failure while using Jabber, yet I knew that the person I was communicating with was still likely to be available via IP (we resorted to email to work out what happened, and could perform traceroutes to each other), the way to solve it that popped into my head was "I'll just run a jabber server" on my PC, and have him connect to that. He could have done the same. Of course, then I'm running both a Jabber client and Jabber server, which makes it a peer in the IM network - it both provides and receives services.

The only reason not to run a server on my PC, restricted to my own IM sessions, is if I didn't have the computing or bandwidth resources to do so. My PC sits at probably an average of 99% idle over a day, and the bandwidth consumed would be very minimal - this is text primarily after all. The only increase in resource consumption is going to occur when I'm sitting in front of my PC using IM. I have an excess of resources that I could run a server with (Remember, this server would be constrained to only being used by people I talk to, and there's only so many concurrent IM sessions my brain can handle - probably no more than about 5 to 7).

So maybe that's the rule. If running a "server" on the "client" is possible, and doing so will more easily allow increases in performance, provide better application scalability and provide increased availability by locallising the impact of a failure to only the peers using that failed peer, then the architecture of the application shouldn't be client/server, it should be peer-to-peer.
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.
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.
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.)

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.

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.
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.
Page 1 / 2   >   >>