Google, Jabber, and Jingle

An anonymous reader writes "Jabber has published the experimental draft Jingle specs, which extend XMPP for use in voice over IP (VoIP), video, and other peer-to-peer multimedia sessions. Google released an open-source library called 'Libjingle' on SourceForge. Libjingle is a set of components provided by Google that let your programs interoperate with Google Talk's peer-to-peer and voice calling capabilities. The package includes source code for Google's implementation of Jingle and Jingle-Audio."

Comments

References...

[Cherita Chen]

Google has an informative page wich includes all related links, etc... Here

Re:References...

[MountainMan101]

Anyone care to speculate on how soon GAIM will have Google voip capability?

Re:References...

[chrisjrn]

Yeah... The BETA is out tomorrow. It's called "Gaim-vv"

Re:References...

[Anonymous Coward]

Actually, if you look at the Changelog in CVS, it doesn't list voice chat as one of the new features. So maybe not yet.

Re:References...

[TheTimoo]

But it won't have any "vv" (voice/video) functionality yet, at least the CVS builds don't. From what I understand the basics are there, but it's not visible to the user.

Re:References...

[Wikipedia]

or http://gaim-vv.sourceforge.net/

Re:References...

[Wikipedia]

See google's projects here:

http://sourceforge.net/users/google/

        * libjingle (libjingle)
        * Google APIlity PHP Library for AdWords (google-apility)
        * google-sparsehash (goog-sparsehash)
        * google-goopy (goog-goopy)
        * google-perftools (goog-perftools)
        * google-coredumper (goog-coredumper)
        * google-mmaim (goog-mmaim)
        * google-sitemap_gen (goog-sitemapgen)
        * atomfeed (atomfeed)
        * google-ajaxslt (goog-ajaxslt)
        * google-kongulo (goog-kongulo)
        * google-adwords-api-client (goog-ad-api-cli)
        * google-prettify (goog-prettify)

other devs are members of:

        * libjingle (libjingle)
        * Google APIlity PHP Library for AdWords (google-apility)
        * Gcomm serial communications program (gcomm)
        * XDraft -- drawing and drafting program (xdraft)
        * 3DS File Format Library (lib3ds)
        * XawM -- athena widgets with modern look (xawm)
        * sortmail -- download and classify email (sortmail)
        * Netcfg -- gui network configuration tool (netcfg)
        * google-perftools (goog-perftools)
        * google-mmaim (goog-mmaim)
        * google-goopy (goog-goopy)
        * google-coredumper (goog-coredumper)
        * google-sparsehash (goog-sparsehash)
        * google-sitemap_gen (goog-sitemapgen)
        * fplan (fplan)
        * google-kongulo (goog-kongulo)
        * google-ajaxslt (goog-ajaxslt)
        * google-adwords-api-client (goog-ad-api-cli)
        * Geodome -- geodesic dome design program (geodome)
        * Dstar space wars game (dstar)

        * libjingle (libjingle)
        * POLE - The PHP Open Layout Engine (pole)
        * google-sparsehash (goog-sparsehash)
        * google-perftools (goog-perftools)
        * google-coredumper (goog-coredumper)
        * google-goopy (goog-goopy)

Re:References...

[Breakfast Pants]

Unfortunately it was a little late and only just arrived. Voice supported wasn't scheduled for this beta, but it is being worked on I believe by several people including the lead gaim developer who was recently hired by Google.

I see...

[RussR42]

This is some sort of christmas joke, right?

Spam

[HillaryWBush]

Not to be cynical or redundant but they're really, really going to have to implement some kind of user rating system or spam control on the server, because I'm not going to log on to their network just to get a lot of w33n0rp0rn.

I have the only w33n0r I think I need to see when logging on.

Re:Spam

[Seumas]

I don't use Google Talk, but I do use Jabber almost exclusively. Are you saying that Google doesn't have a "accept messages only from people on my contact list" option?!

By the way, this sounds like BS to me. "Jingle"? Christmas time? This sounds a lot like the google pigeon TCP/IP protocol thing.

Re:Spam

[ciroknight]

That's why Google hasn't opted to add Server-to-Server communication yet; if you're on their server, they can kick your ass off and ban you, but coming from other servers it's a lot more difficult to regulate (and I'm sure they've got someone working on it with their 20% free time).

As for the person who said it sounds like BS being named "Jingle"; A lot of people say "I'll give you a ring" as a way of saying they'll call you later. Thus, Jingle (a ringing sound).

Re:Spam

[Randle_Revar]

Are you saying that Google doesn't have a "accept messages only from people on my contact list" option?!

I don't know if Google's implementation has that option right now, but there are several JEP's (158, 159, 161) that deal with spim (IM spam), and they include the option "accept messages only from people on my contact list". I would imagine Google will add it soon if they haven't already.

Jingle is not a joke, on the list of JEP's (http://www.jabber.org/jeps/jeplist.shtml) the jokes are clearly marked.

Re:Spam

[Anonymous Coward]

The Jingle name is more likely due to jabber.org's rule, that every spec must be given a ~6-letter name starting with "J".

Re:Spam

[burns210]

(and I'm sure they've got someone working on it with their 20% free time).

The 20% idea is for, like you said, free time. I think you are right, that they will work on some sort of spam control for third-party server's, but it will be an 80% project, something the company assigns, not a free time project.

Though, having a preference that says a user will only accept (or be bothered with requests from) user's already in their buddy list would seem to solve this for the most part. These settings have been around for years (on AIM, atleast, where you can have only Buddy List members IM you, as a form of spam/parental control).

Re:Spam

[dasunt]

That's why Google hasn't opted to add Server-to-Server communication yet; if you're on their server, they can kick your ass off and ban you, but coming from other servers it's a lot more difficult to regulate (and I'm sure they've got someone working on it with their 20% free time).

Yet google has opted to add server-to-server communication to email. Why would google be quite good at avoiding spam on gmail, but be unable to deal with spam on jabber?

Re:Spam

[ciroknight]

Instant packet network protocol (instant message) vs. Delayed message network protocol (email); apples to oranges comparison.

Google has a HUGE database of spam emails to compare a suspect email to; doing the same with Instant Messages would instantly through privacy nuts into convolutions (much like gmail did when it started; ZOMG GOOGLES READING MY IMZ), but is entirely possible to do. So it's not far-fetched that they use a similar system, but it's a lot more work to convince people to use this system.

A better solution would be to find a way to keep spam from coming in without reading the IMs in the first place. But, if I had an answer to that problem, I would be working for Google. You could opt for encryption, but as soon as an encrypted spammer arrived, you'd be up shit's creek even further than you are now (as decrypting someone's IMs would be even worse for Google PR). So for now, Google's opted to keep its doors closed to the public, and that's just fine. Don't like it? Go use another Instant Messaging protocol which means you have to go through someone elses server anyways. But the way I look at it is "I trust Google more than I trust Microsoft, Yahoo, and AOL combined; I'd rather use Google's service".

PS: (Oh, and if you think running your own Jabber server is a way around it, what do you think happens when you want to message someone off server? That's right, your message goes through someone elses server. That means they could be spying on you! Oh noes! To tell you the honest truth, I'd rather have the security in numbers of a huge company's client, then chancing my message through someone's private server; the huge company's more likely to have a lot more imporant things on its mind than reading people's IMs...)

Re:Spam

[HillaryWBush]

But the way I look at it is "I trust Google more than I trust Microsoft, Yahoo, and AOL combined; I'd rather use Google's service".

How does that work exactly, combining trust values? I bet the sprawl of THAT overloaded += operator would put my homegrown garbage collector's to shame.

Re:Spam

[Da w00t]

Spam? on Jabber? This is news to me.

Jabber has built in anti spam. In order for me to talk to you, I have to ask you if I can, and then you have to tell me that it's OK. This is part of the Jabber protocol itself. Google Talk has no reason not to turn on server-to-server connectivity. They're limiting their usefulness by leaving it off. I really do wish they would turn it on because I already run my own Jabber server, and my Jabber ID is the same as my email address. I'm confident that gaim will support Jingle soon, so all Google needs to do is enable s2s support and I can completely ditch AOL IM and stop signing into Google Talk.

I want to ditch AOL IM because lately AOL IM has turned to crap, with their auth-servers (the servers that verify your screen name and password) successfully authenticating me, and then redirecting me to a chat server (commonly known as a BOS server) that is dead. Dead as a doorknob. -ECONNREFUSED. And if I mash reconnect enough times while they continue to direct me to a broken chat server, they put a ban on me for trying to sign in!

Re:Spam

[trollable]

How does that work exactly, combining trust values?

Trust is probability.
If they are acting independently, P0+(1-P0)*P1+(1-P0-(1-P0)*P1)*P2+... with P sorted from the higher to the lower. If they are acting together, max(P0,P1,P2,...). If you don't know, interpolate ;)
personnal theory

Re:Spam

[Anonymous Coward]

...and then redirecting me to a chat server (commonly known as a BOS server) that is dead...And if I mash reconnect enough times while they continue to direct me to a broken chat server, they put a ban on me for trying to sign in!

You Sir need to learn to take a hint

Re:Spam

[emidln]

Does google store the buddy lists on their servers? If so, you could implement only allow a message if the sender is a friend, and only allow an add request if that person is your friend's friend.

You could take that out maybe two levels with some security, and anyone who goes evil and starts spamming not only takes them out, but their friends out as well. I worked a little on a trust network like this a few years ago for some third-party Yahoo chat clients. Very little was published because a lot of us lost interest and moved on, but I think the idea is workable.

Re:Spam

[ceejayoz]

Jabber has built in anti spam. In order for me to talk to you, I have to ask you if I can, and then you have to tell me that it's OK.

CHECK.IT.OUT.PENIS.ENLARGMENT.CHEAP@BIGGER-PENIS.N ET would like to talk to you.

Re:Spam

[Anonymous Coward]

Jabber has built in anti spam. In order for me to talk to you, I have to ask you if I can, and then you have to tell me that it's OK. This is part of the Jabber protocol itself. Google Talk has no reason not to turn on server-to-server connectivity.

Bzzz... wrong. That built in support is for the two parties to see each other in their contact lists. That said, most clients have an ignore events from contacts not in your roster type option one could always check.

Re:Spam

[bedroll]

Though, having a preference that says a user will only accept (or be bothered with requests from) user's already in their buddy list would seem to solve this for the most part. These settings have been around for years (on AIM, atleast, where you can have only Buddy List members IM you, as a form of spam/parental control).

The first client I saw that feature in was, like so many other features we take for granted in IM, ICQ. It's really effective in keeping spammers and other unwanteds away. The problem is, how different would that be from what we have now? It's been my experience that you have to accept someone as a contact before the client will tell them you're online.

The other part of this is that with gmail/gtalk once a spammer has your IM they have your email and vice versa. So what does a filter like that do if a spammer knows that your account exists? Your mail box is still going to get spammed.

Then again, I've not been spammed in gtalk. Does anyone have any firsthand experience with a spammer using it?

Re:Spam

[Zilch]

Jabber has built in anti spam. In order for me to talk to you, I have to ask you if I can, and then you have to tell me that it's OK. This is part of the Jabber protocol itself.

This is very wrong but a common misconception. You are confusing presence subscriptions with messaging. You need to subscribe to someones *presence* but anyone can send you a message. For example a website may send you a message to say that someone replied to your thread on slashdot. Slashdot.org doesn't really care if you are online or not.

...of course on the *client* you are welcome to discard any messages from people who have not subscribed to your presence, but that's not a part of the Jabber protocol.

Zilch.

Re:Spam

[bigsmoke]

Google Talk uses your Gmail contact list. If you delete one of your contacts from Google Talk, it is consequently removed from your Gmail address book. At least, that was still the behaviour when I last used the official Google Talk client.

I'm not sure wether this is a nuisance or convenience to other users, but for me, it's mostly a convenience.

Re:Spam

[KevPsi]

As noted, the mechanism referred to is for presence (status), not chat messages but the Jabber Software Foundation are already trying to address the issues of spam on im before they become an issue for the Jabber/XMPP community. Robot Challenges, SPIM Blocking Control and SPIM Reporting are three such approaches.

Re:Spam

[21mhz]

<iq from='you@yourdomain.net/resource' type='set' id='blah'>
  <query xmlns='jabber:iq:privacy'>
    <list name='block-the-entire-fucking-spammer-domain'>
      <item type='jid'
            value='bigger-penis.net'
            action='deny'
            order='1'/>
    </list>
  </query>
</iq>

Re:Spam

[zo1dberg]

"I have the only w33n0r I think I need to see when logging on." You need to see it when logging on? You aren't a bit obsessed with it, are you?

Re:Spam

[Hatta]

Oh, and if you think running your own Jabber server is a way around it, what do you think happens when you want to message someone off server? That's right, your message goes through someone elses server. That means they could be spying on you!

This is why all IM's (and all emails for that matter) should be encrypted end to end. It should be in the protocol, and not left to the implementation, otherwise we'll never have widespread encryption.

Re:Spam

[Anonymous Coward]

if you're on their server, they can kick your ass off and ban you, but coming from other servers it's a lot more difficult to regulate

Identity 2.0 - credentials issued from sources you choose to trust or not

Re:Spam

[Seumas]

Am I the only one that counted out how many letters are in "Jesus" when I read that?

Re:Spam

[rsborg]

Am I the only one that counted out how many letters are in "Jesus" when I read that?

No, I immediately thought of "Jeebus" (nice: IM with an eliza-bot that thinks it's god!)

Re:Spam

[ceejayoz]

Quick, go tell the anti-spam vendors that all they need to do is blacklist spammer domain names! ;-)

Re:Spam

[21mhz]

Jabber domains are not like email domains.
s2s connections are verified with a reciprocal DNS lookup and (in the newer revisions of the protocol) can be authenticated. If your server only accepts connections from servers authenticated with a valid certificate, spammers will spend time and money obtaining certificates for their domains which can then be banned in a few seconds. Even valid domain names cost actual money, as opposed to email messages with fake sender address.

Re:Spam

[ceejayoz]

Even valid domain names cost actual money, as opposed to email messages with fake sender address.

Sure, but you only need one person to earn you that $10 affiliate fee for the pornsite or the poker to pay for the domain.

If banning domains were all it took, I wouldn't get phishing scams in my Gmail inbox.

Re:Spam

[JThundley]

Jabber has built in anti spam. In order for me to talk to you, I have to ask you if I can, and then you have to tell me that it's OK.

Actually, that authorization only applies to presence. If you want to see if I'm online or read my away message, I have to authorize you to be able to see that, but we can still send messages back and fourth. I'm using psi, and don't see a way to block a contact. I sent you a message to one of your JID's, let me know if you get it ;)

Re:Spam

[21mhz]

Sure, but you only need one person to earn you that $10 affiliate fee for the pornsite or the poker to pay for the domain.

Yes, but email spammers draw this gullible person from a pool of hundreds of thousands. If IM spam controls are maintained early in the system's adoption, the SPIMmers may not get the sucker base to break profit.

Re:Spam

[Broken_Ladder]

According to the guys in #gaim on irc.freenode.net (the developers), Google is going through a lot of work to make a Jabber implementation that will scale well to the large volume they'll be doing as compared to other Jabber servers, which use the reference servers. I thought they were intentionally leaving out compatibility too, but that's not the case. They are actively working on it, but it's harder than it sounds. There's still a bit of cynicism in me about this, but I think the gaim devs are pretty reliable for information like this.

server-to-server

[Anonymous Coward]

Now if google would just implement server-to-server jabber connections, this might be useful!

Re:server-to-server

[Anonymous Coward]

Someone noted on one of the Google Talk mailing lists that as of the 9th of December Gmail's DNS has contained the SRV record necessary for other Jabber servers to send messages to the talk.google.com server (previously only the SRV record for clients was there), so it looks like it's definitely coming soon.

Also a beta of GAIM 2.0 is due today supposedly containing support for Jingle-Audio, so it looks like things are really starting to move in the Google Talk/Jabber camp.

Re:server-to-server

[FireFury03]

Someone noted on one of the Google Talk mailing lists that as of the 9th of December Gmail's DNS has contained the SRV record necessary for other Jabber servers to send messages to the talk.google.com server (previously only the SRV record for clients was there), so it looks like it's definitely coming soon.

_xmpp-server._tcp.google.com. 86400 IN SRV 5 0 5269 federation.google.com.

Notice the "federation.google.com" bit - implies they're sticking to their federation plans and won't be letting people running their own servers connect. Whilest I understand why, I think this is a Bad Thing because the thing that makes Jabber so good is that I can (and do) run my own server and still talk to other people in the network.

Re:server-to-server

[Anonymous Coward]

The SRV record you quoted was for Google.com. Google Talk uses JIDs in the form of user@gmail.com (and user@googlemail.com for UK users i guess).

So the DNS request will be made for gmail.com and googlemail.com.

_xmpp-server._tcp.gmail.com. 70235 IN SRV 5 0 5269 talk.google.com.
_xmpp-server._tcp.googlemail.com. 86400 IN SRV 5 0 5269 talk.google.com.

I'm unsure why Google.com has an xmpp-server SRV record unless, of course, Google employees are on an internal Jabber server.

Re:server-to-server

[Breakfast Pants]

Exactly. I think the only thing the "federation" should be used for is for buddy list "join" requests, so that those don't get spammed. Make it so that the person on the federated network must make the request. And even this solution should be temporary until something better can be found (I like computational challenge/requests personally: if you know me and can't get in touch with me another way to get me to add you to my list, compute on this thing for an hour (user adjustable) and get back to me).

i want conference mode and pocketpc voice client

[Anonymous Coward]

Let's hope someone can now develop a Gtalk pocketpc application with voice. While they are at it: add conference mode to Gtalk; in business environments it's very handy.

I'm not interested...

[Schraegstrichpunkt]

... until they implement server-to-server communication.

Re:I'm not interested...

[ciroknight]

Good for you! Meanwhile, for the rest of us who aren't paranoid/Google-bashers, this is a boon, including Jabber users (you know, this will work for your Jabber server too, right? ;)

Besides, Google hasn't implemented Server-to-Server communication yet for reasons posted elseware in this very article; they don't want spam. It's harder to validate posts coming from offserver without actually reading them, which would breech your privacy, right? (On server they have the option of reading it [via EULA], post rate limiting, banning accounts, etc)

So please, next time Google (or $BIG_COMPANY) gives the open source world a donation and a piece of code it's been needing for a while now, take it as a gift, and try not to be so critical about it. Thanks.

Re:I'm not interested...

[luvirini]

One should allways be cynical atleast.. and examine the thing and reasons critically.. but if the thing is good accept with thanks.

Re:I'm not interested...

[ciroknight]

One should allways be cynical atleast.. and examine the thing and reasons critically.. but if the thing is good accept with thanks

I didn't say not to be critical at all, I said "try not to be so critical". Secondly, how could releasing your code and giving a donation be a bad thing? If the code was terrible, it'd simply get dropped and not used.

Re:I'm not interested...

[obender]

Besides, Google hasn't implemented Server-to-Server communication yet for reasons posted elseware in this very article; they don't want spam.

I don't buy this. Spam in Jabber is much more difficult to achieve (some people say it's impossible but they're probably wrong) and Jabber without server to server is not fully Jabber.

Re:I'm not interested...

[ZuperDee]

So please, next time Google (or $BIG_COMPANY) gives the open source world a donation and a piece of code it's been needing for a while now, take it as a gift, and try not to be so critical about it. Thanks.

I wonder if you'd be saying the same thing (LET ALONE getting modded up to +5 Insightful, for that matter) if that $BIG_COMPANY was Microsoft instead of Google. Don't get me wrong--I hate Microsoft with a passion, and I am NOT trying to support them here. I'm merely trying to point out the obvious hypocrisy of people here on Slashdot, and how it seems like no matter what Google does, Google can do no wrong as far as Slashdotties are concerned, whereas if it were MICROSOFT that did something like this, you can bet people here would be viewing such a move with great suspicion and cynicism, to say the least.

In the end, the ONLY question that matters is: is Google doing a good job of meeting users' needs with their technology? Google Talk is a GREAT product, but one simply CANNOT debate the fact that it remains to be seen if Google Talk can truly topple any of the Big 3 IM systems (AIM, MSN Messenger, or Yahoo), which are already well established and well entrenched.

Sure, it's all very well to say "oh, but Google Talk is wonderful, because it's based on OPEN SOURCE and OPEN STANDARDS, JUST LIKE EMAIL IS!!!" Try telling that to your non-geek friends. Personally, I am finding it VERY difficult to try to convince all my friends to communicate with me using Google Talk as opposed to anything else, using arguments like "Oh, but Google Talk is based on the open XMPP protocol, unlike what you're using!" Trust me, arguments like that generally do not win the hearts and minds of the average person. Generally, the average user only cares about practical things like: Is it easy to use? Can I talk to MY friends and people I know with it? Does it support features I care about, like Voice, or using Webcams?

Re:I'm not interested...

[JonXP]

I would like to know who told you spam was difficult in Jabber.

If anything, it's easier, since you don't have to go through all the trouble of hooking up to a network with no public specs.

Re:I'm not interested...

[Bert64]

There was talk of google potentially buying AOL.. If this happened, they could migrate the existing AIM/ICQ networks over to a jabber based protocol, while maintaining the existing protocol for compatibility..
They could retain gtalk as it is too, and allow server to server jabber communication between both their servers and external jabber services..
AIM already has a large userbase, and with such ease of communication between services it may be large enough to convince yahoo/msn to co-operate too.

Re:I'm not interested...

[obender]

I would like to know who told you spam was difficult in Jabber.

FOSDEM 2005 Jabber Developers' Room

Re:I'm not interested...

[Anonymous Coward]

I wonder if you'd be saying the same thing (LET ALONE getting modded up to +5 Insightful, for that matter) if that $BIG_COMPANY was Microsoft instead of Google.

No, he would be busy shooting flying bigs, while selling powerfull heaters to help defrost hell.

Re:I'm not interested...

[16K Ram Pack]

The problem is that the way that Microsoft choose to make a profit is incompatible with the way that slashdotters think, where Google is more compatible. Google also release products that are simply dynamite (Gmail, Google Maps) where Microsoft release little more than products with tweaks or new graphics (see Office since 2000, Vista).

Let's not forget that Google want to make a decent profit. But companies have different ways to make a profit.

For instance, some manufacturers take the attitude of building in a short lifespan because then they can get another sale soon after. Others take the view of making a less than reliable product and making a lot of money on spare parts. Others use various means to ensure that any upgrades/consumables for the products will cost a great deal. And a few decide that the best way to trade is to make a great value product because even though you don't get a good short term hit, you build customer loyalty and word-of-mouth. Financially speaking, there's probably no right answer to make money.

Re:I'm not interested...

[cortana]

Link to video? Transcript?

Re:I'm not interested...

[sita]

On server they have the option of reading it [via EULA], post rate limiting, banning accounts, etc

If they can get themselves the option of reading your outgoing messages with an EULA, they can of course do the same for incoming messages.

Re:I'm not interested...

[JourneymanMereel]

Now that's very interesting.... they could do a "behind the scenes" converstion of AIM screen names and ICQ number to be Jabber ID's.... @aim.com and @icq.com. It should be able to be done in such a way that somebody who used Jabber wouldn't need Trillian or even an AIM screen name/password of their own to talk to somebody on one of those two networks. That would certainly make it really hard for Microsoft or Yahoo! to ignore. ICQ and Google Talk combined probably don't have half the number of users of MSN messenger, but the simple fact that there was network collaberation would force Microsoft at least to put their money where their mouth is (early on in the MSN messenger project, they said they wanted s2s interoperability). If that happened, it'd only leave Yahoo! out in the cold and I don't see them trying to make it on their own when all the other services let you talk to other users.

Sorry if this seems incoherant.... I typed as the thoughts were in my head and sometimes that can be a scary place.

Re:I'm not interested...

[Al Dimond]

The fact that they're releasing the spec and an open-source library should mean that once your Jabber client has Jingle support you can chat with anyone on any server that will peer with yours. Now, granted, that doesn't include their server, but that's their loss; you could just go to some other random server that would allow it.

Yeah, server-to-server would be cool, but we already have server-to-server and it works as long as it stays small enough that the spammers don't notice. Google wants to make this thing huge, and if they do, spammers will notice.

Re:I'm not interested...

[sacbhale]

Well the Issue is Yahoo and MSN have already announced that they would be makking interoprability between each other soon. So if one of them crosses over the other one will too.
However if the whole IM world comes together they would have to conform on features or u could not use some features with others. I mean things like smileys and animated messages (audibles in yahoo, other things in other clients)
That would still make people stick to other clients.
If it comes to any client signing onto any network..Imagine signing onto gtalk with a Y! client.
That would certainly be the day

Re:I'm not interested...

[Anonymous Coward]

(Your) From the I-have-no-idea-what-I-am-talking-about dept.

Check out some of the realy old threads in http://groups.google.com/group/google-talk-open the new ones are just rubbish...

Re:I'm not interested...

[Anonymous Coward]

Oh yea should of included this link, http://mail.jabber.org/pipermail/jdev/2005-August/ 021792.html

broken links

[netcrusher88]

Of all the people to have a broken link... Did anyone else try the "Home Page" link on the SF project description?

Crap! No Christmas vacation this year...

[zarkzervo]

I currently implement Jabber functionality into my project's code.

I better lock the door before my pointy haired boss comes in: "This looks interesting. I want VoIP before you can go home for Christmas."

Re:i want conference mode and pocketpc voice clien

[moro_666]

last time i checked they didn't have a voip client for linux either. you can use jabber'over'gaim to use gtalk itself but you're unable to make the calls. let's hope this library makes it possible.

until then, i stay with the hype-skype which works rather well (if you don't mind the cpu and network overheads ...)

Now only if..

[luvirini]

All these instant messagers and voice applications could somehow communicate so would not need to have so many on my computer. Even if the communication was on lowest common denominator, could use the ones I like and atleast communicate somehow with people using others.. oh well.. not likely to happen soon I guess.

Re:Now only if..

[ciroknight]

First, use a conglomerated client. That'll alleviate a great deal of stress alone.

Secondly, Google (amongst others) are trying to combat this problem, which is why they're trying so hard on their "federation" of VoIP providers (better to have a lot of providers on the same protocol than a bunch of providers speaking different languages and not being able to intercommunicate).

Lastly, if Google does end up acquiring AOL, this will be a major coup. Microsoft and Yahoo have already gotten in bed together, which only leaves Google and AOL as players. If Microsoft acquired AOL (which hopefully would be blocked through anti-trust litigation, if the SEC opened its eyes [Don't even get me started with AT&T]), it'd be all verses one, and we'd pretty much have that talk anywhere infrastructure you wish for. But, to be truthful, I'd rather it not happen that way.

It seems like it would be a trivial task to make a message passer; a client that simply accepted messages from one protocol, translated it to the other and sent out the message using a pre-programmed username/password combination. In a lot of ways, AJAX-IM clients are already doing this (ajax-form -> rewrite script -> IM protocol -> IM Server); why not make the same service? (other than the obvious takedown requests you'd get from AOL/Microsoft/Yahoo).

Re:Now only if..

[Randle_Revar]

It seems like it would be a trivial task to make a message passer; a client that simply accepted messages from one protocol, translated it to the other and sent out the message using a pre-programmed username/password combination.

That's what Jabber server transports do, I use Psi to talk to my brother on MSN all the time.

Re:Now only if..

[John Hurliman]

If only someone would code this idea.

Re:Now only if..

[KevPsi]

Indeed, one of the major players you left out of the list is the one that has already announced preliminary support, Psi. The Google guys have been working with the Psi team behind the scenes for a while already. Public Announcement Forum Discussion Homepage Disclaimer: I'm not an impartial observer to the project.

Re:Now only if..

[21mhz]

If Microsoft acquired AOL [...], it'd be all verses one, and we'd pretty much have that talk anywhere infrastructure you wish for.

Yeah, right like we have AIM/ICQ convergence after AOL bought Mirabilis.

Re:Now only if..

[Thomas Charron]

The largest issue with the usage of transports in this way is having to provide your user information to the transport in order for it to log into the server 'on your behalf'.

There is also issues when AOL or Yahoo deicde that 'too many connections' are coming in from a given IP, they tend to blacklist that IP.

This is one of the prime reasons why jabber.org no longer runs AIM/Yahoo/MSIM transports.

Is the format wasting bits?

[Stan Vassilev]

Using transcoded XML for binary audio support... I wonder if some bandwidth is wasted just because of the format (XML can't contain random binary data, so there's bit loss). Anyone checked deeper?

Re:Is the format wasting bits?

[pikine]

Just looking a bit deeper, but not too much, I think JEP-0166 outlines a handshaking protocol, but actual binary data transmission takes place on other channels, say over rtp or rtcp. It looks like when handshaking (signalling) takes place, a list of possible channel candidates are offered, but it's not clear to me how the accepting party tells the initiating party which candidate is chosen.

Re:Is the format wasting bits?

[Randle_Revar]

They use jingle to set up a RTP channel.

Re:Is the format wasting bits?

[FireFury03]

Just looking a bit deeper, but not too much, I think JEP-0166 outlines a handshaking protocol, but actual binary data transmission takes place on other channels, say over rtp or rtcp. It looks like when handshaking (signalling) takes place, a list of possible channel candidates are offered, but it's not clear to me how the accepting party tells the initiating party which candidate is chosen.

Yes, XMPP is used as the signalling protocol, similar to SIP. AFAIK Google uses peer-to-peer RTP for the actual voice traffic, which means that NAT discovery (e.g. STUN) and traversal is needed, exactly like when using SIP.

Whilest I like the fact that Google are doing some open innovation, I'm not sure what the advantage of this is over the already well established SIP. A brief glance over the spec seems to suggest that this is nowhere near as capable as SIP infact, just providing the bare essentials to get an RTP session up and running. If *all* the traffic was transported over XMPP then it would have the advantage of making it easy to use on NATted connections, but would also mean that the quality of service would be severely degraded by TCP's head-of-line blocking, slow-start and congestion algorithms. As it is, signalling over XMPP and putting the voice traffic over RTP seems to offer no advantage over SIP and adds yet another VoIP protocol to the mix.

OTOH, maybe the addition of VoIP to XMPP will cause more IM clients to support VoIP natively which would make them easier to extend to support SIP - that would be good since there seem to be very few open source soft-phones ATM (I've certainly not found any decent ones, I've been using sjPhone which is closed source but happens to be freely available for Linux)

Re:Is the format wasting bits?

[uhoreg]

re: NAT, Jabber already has a specification (JEP-0065) for bytestream proxying. My guess is that's what will be used to get around NAT.

Re:Is the format wasting bits?

[FireFury03]

re: NAT, Jabber already has a specification (JEP-0065) for bytestream proxying. My guess is that's what will be used to get around NAT.

Google Talk uses STUN.

But whatever NAT discovery and traversal method is used, I still don't see an advantage in signalling over XMPP rather than SIP.

Re:Is the format wasting bits?

[uhoreg]

The Jabber philosophy is to make the client simple, and push complexity to the server. SIP is a more complicated protocol.

Jabber originally tried to create a protocol (TINS) that would be a light wrapper around SIP. Google looked at it for their voice chat, at first, but found problems with it, and came up with their own protocol instead. You can look at Peter Saint Andre's blog for more history on Jingle.

Using XMPP also allows the use of transports, which will allow Jabber to connect to SIP and IAX networks, as well as supporting voice connections with MSN, Yahoo, etc.

Re:Is the format wasting bits?

[FireFury03]

Using XMPP also allows the use of transports, which will allow Jabber to connect to SIP and IAX networks, as well as supporting voice connections with MSN, Yahoo, etc.

Well you could do the same with SIP - gatewaying SIP calls to other networks through a SIP proxy has been possible for a long time (how do you think SIP PSTN gateways work?)

Re:Is the format wasting bits?

[uhoreg]

Yes, you can always gateway no matter what protocol you use. It's just a question of which protocol is easier to gateway. Apparently, the people who tried to use a combined XMPP/SIP protocol hated it and wanted a native XMPP protocol.

Re:Is the format wasting bits?

[Trejkaz]

OTOH, maybe the addition of VoIP to XMPP will cause more IM clients to support VoIP natively which would make them easier to extend to support SIP - that would be good since there seem to be very few open source soft-phones ATM (I've certainly not found any decent ones, I've been using sjPhone which is closed source but happens to be freely available for Linux)

I dunno, I find Twinkle to be quite good. The only flaw I can pick with it would be its lack of support for video chat.

Could be worse....

[kg4czo]

Could be "I want VoIP before you go home today."

In other news, a manager at a local business was brutally murdered yesterday by one of the software engineers working under him. The enraged developer showed no remorse, and his only comment was "VoIP sux0rz!" More at 11.

Re:Could be worse....

[zarkzervo]

Could be "I want VoIP before you go home today."

A whole week gives you time to really feel the vacation slipping. If he comes in today, I would have to decide if I should work this weekend or not ;)

How does it fit in with...

[hug_the_penguin]

...their system where the advertisers call you? It's safe to assume they'll be adopting the platform and munging it with some sort of phone connection to achieve this. This could be just the step they're looking for to lower costs and make more profit. And on top of that, how many other messengers have an open voice protocol? How long before we see extensions etc? And how long before some wisespark tries that Skypecasting thing with it? Since jabber can technically support any mime type, all we would need is for someone to plug theora into it and instantly it can be done.

Unless memory fails...

[Anonymous Coward]

XML can have any 8 bit encoded data in a CDATA section. Structured, unstructured, but definitely sized? Someone clarify?

Re:Unless memory fails...

[Stan Vassilev]

well it can't be ANY 8-bit data, since what if a sequence matches the CDATA closing tag (which is just 3 chars, so the probability is not very low).

Also I think XML is limited to only readable chars. It's getting extra weird if the XML is using Unicode format, which may assign multiple bytes per character.

Re:Unless memory fails...

[jcupitt65]

Sadly not ... you have to base64-encode your binary data. I have to do this to get ICC profiles embedded within an XML image file format header :-(

Psi

[Anonymous Coward]

And it's already working in Psi, awesome.

Psi Support

[Fritzy]

Psi, one of the most popular Jabber clients out there has announced that they are working on support for jingle. http://psi-im.org/forum/post/24491

OSS Voip great for BeOS

[Anonymous Coward]

There are a few things I cannot do in BeOS (soon to be replaced by the excellent Haiku-os.org clone)

1. flash

2. VOIP with Skype

Great news.

welcome to slashdot

[Anonymous Coward]

...where 2 comments saying exactly the same thing have +5 and -1 respectively.

Another voip protocol?

[vstanescu]

I don't see this as a good thing. There are already too many signalling protocols for voip. Another protocol just makes everything more messy.

Re:Another voip protocol?

[the grace of R'hllor]

Too many? Most are proprietary, or not suitable for IM (because of lack of quality NAT traverssal, frex).
SIP could work but is cumbersome when all you want to do is get an RTP voice stream going. Having a standard that is clear, concise and tailormade for IM applications is useful.

Re:Another voip protocol?

[n0d3]

I thought the intention was to use SIP as the underlaying protocol.

Re:Another voip protocol?

[the grace of R'hllor]

Incorrect. SIP is a signalling protocol, same as Jingle.

To set up a connection to a SIP-capable device you typically use:
- SIP to signal intent to communicate (and to accept or refuse or redirect, etc)
- SDP to describe the coming transport session (which port, where do I send the data, which codec do I use, etc)
- RTP to use that SDP data to make the actual connection and send the encoded data.

Jingle replaces the SIP/SDP steps. Summary of operation, Romeo tries to call Juliet:
- Romeo initiates a call to Juliet, sends back either "refuse", "redirect" (to a cellphone client, say) or "provisionally accept".
- Romeo offers up several candidate transports that it can use. It either does this all at once (burst) or one by one (dribble), which is specified in the initation message.
- Juliet offers up several candidate transports (RTP, G.711 codec, frex) that it can use.
- Once concensus is reached over a suitable transport, Jingle switches to "in progress" and RTP takes over. If concensus is impossible the connection ends.
- Finally, Jingle politely closes (and confirms) to end the conversation.

The two processes achieve the same endgoal: getting VoIP data from A to B. An advantages here is that SIP isn't very lightweight in terms of correct implementations, while Jingle can be 'spoken' by any client that can do XMPP as long as you add the statemachine.

Re:Another voip protocol?

[Anonymous Coward]

I don't believe XMPP is more lightweight than SIP, as it requires a whole XML stack. These things get extremely complex when you have to support the unicode representations and .. stuff.

SIP has been designed by some very competent people. Voice has a lot of things to take in consideration, such as it has to minimize turn-around. That's why you only send one UDP packet with SIP when you answer the phone and no TCP is involved.

Re:Another voip protocol?

[the grace of R'hllor]

Comparing XMPP to SIP is incredibly wrong. XMPP is a messaging and presence protocol, with a focus on clarity and extensibility, while SIP is a protocol designed to (per the name) initiate sessions for transport protocols. (Though yes, it does support messaging and presence indication)

Answering a phone with SIP may be just one packet, but before that there's quite a bit of negotiation, same as with Jingle. The difference is that, while SIP requires its own extensive library to run, Jingle is lightweight because it is built on the XMPP, which you're running anyway for your IM-client. Jingle is a Jabber/XMPP thing, not a generic plug'n'play solution.

Added to that, XMPP is not bound to TCP. It can be implemented over UDP, HTTP, whatever.

[OT-META] MODERATORS, PLEASE:

[hummassa]

The parent post is not Funny (even if it tries to be), but it's really INFORMATIVE!!!!

Perhaps they can combine the names...

[zenmojodaddy]

... and call their sweet new product Gibber.

Re:Perhaps they can combine the names...

[blugu64]

correction, it's jibber

Re:Perhaps they can combine the names...

[Anonymous Coward]

Don't give me that jibber-jabber! Mr. T

To clarify

[Anonymous Coward]

I meant gaim-vv, which was focusing on MSN and Yahoo voice chat. Given that Sean Egan is on the Google Talk team, I wouldn't be surprised if the GAIM beta was timed to coincide with the release of Jingle.

About Time

[ObsessiveMathsFreak]

IM clients are the obviousplace to strapon VOIP communication. The jabber system would be a perfect VOIP framework. Your "number" will simply be your JabberID. Which is similar to an email address, so it's easy to remember.

You'll simply dial something like "malda@slashdot.org" to complain to Taco about the preponderance of dupes, and Taco can simply add your address "slashbot@cheapisp.com" to his ignore list.

If telemarketers become a problem, some kind of del.ico.us system might enable VOIP users to share a list of banned domains or addresses. Potential for abuse etc, etc.

Key point here is that a system based on "email" like addresses would be batter and easier to remember than the current telecoms number based system.

Re:About Time

[Anonymous Coward]

The jabber system would be a perfect VOIP framework. Your "number" will simply be your JabberID. Which is similar to an email address, so it's easy to remember.

How does this give an advantage over the SIP approach "userid@server.domain"?

Re:About Time

[ObsessiveMathsFreak]

I was speaking more against the advantages over the H.323 system using 10 digit phone numbers.

Re:About Time

[Anonymous Coward]

No one uses H.323 anymore, it's a dead duck, because of what you describe and it's other peculiarities. SIP uses your email address as your phone number. All you need to have is a SIP proxy on your domain (which is actually easier to set up than Jabber).

Re:About Time

[Anonymous Coward]

You only use 10 digit phone numbers with H323 if you're using a telephone system. When the interface is a number pad, 10 digit numbers look like a good idea If you're just using TCP/IP soft clients then you can enter "dave@phone.example.com" and it connects to phone.example.com looking for dave.

Re:About Time

[mbwjr12]

Using SIP aliases makes this even better, in OpenSER for instance. This way, PSTN users can dial your number, while others can still reach you at an alphanumeric name. 12228027865@domain.com = me@domain.com Any of this supported in Jingle?

Re:About Time

[FireFury03]

Key point here is that a system based on "email" like addresses would be batter and easier to remember than the current telecoms number based system.

You already get this with SIP... I'm not, on the whole, sure what integrating this with XMPP does to benefit anyone. I'd far prefer to see a bunch of decent FOSS SIP clients than yet another VoIP protocol.

Re:About Time

[Thomas Charron]

Mostly becouse XMPP can be extended easily to transport new types of data, without requiring modification of the existing protocol/servers/clients.

SIP is great. For phone calls. Adding VoIP transport information to Jabber/XMPP is mad easy. Adding the actual handling OF the VoIP content which is, in reality, transport OOB (same with SIP anyway), is a bit harder for clients to do, but having Jabber support means one application can use the same common protocol for more things.

Re:About Time

[Thomas Charron]

It's not required, as the context of addressing is different within XMPP.

The raw phone number versus a user ID would be different entities, but there's no reason why it couldn't have a user register the number with the server, and dynamically, the number would now resolve to the user.

Now there would obviously be some sort of security tracking involved, but one could build into a server component the registration of numbers, and due to the use of presence and resources within XMPP, dynamically remap the numbers to the one your currently available at. Example:

6035551212@voip.jabber.org - Home
6032319874@voip.jabber.org - Work
6034936541@void.jabber.org - Cell

If a component provided mappings to a given JID, in my case, tcharron@jabber.org, based on presence notifications provided, I could map any of these numbers to each other, which in reality, maps to my JID.

I'm blathering. Basically, to answer the question in a short form, yes, but it's inferred support by the Jabber/XMPP protocol itself. Jingle doesnt have to support it, becouse it sits on top of a protocol that can handle this type of thing.

Re:About Time

[FireFury03]

Mostly becouse XMPP can be extended easily to transport new types of data, without requiring modification of the existing protocol/servers/clients.

Errm, except you _do_ need to modify the client, otherwise it won't understand the new data you're transporting (VoIP). So where was the advantage over using the industry standard protocol? Similarly, if you want the server to do anything interesting you also need to modify that (voicemail?). I would much prefer to see effort going into supporting the existing industry standard protocol rather than creating another set of software that just reimplements what we already have in an incompatable way (I still haven't found a decent FOSS Linux SIP softphone). And on the subject of compatability, you can already get plenty of hardware SIP phones (either desk phones or walk-about 802.11 phones) and they won't work with XMPP.

Sorry, but if someone hands me a VoIP address to call, I want it to be a SIP address so I can use existing SIP hardware and software to call it. If there is a significant advantage then it might be worth migrating all VoIP stuff to a new protocol, but in this case I just don't see a reason to do it.

SIP is great. For phone calls. Adding VoIP transport information to Jabber/XMPP is mad easy.

Just because it can be done and/or is easy doesn't necessarilly mean it _should_ be done if it doesn't gain you anything. Don't get me wrong, I'm a big fan of XMPP but I don't see the point in just adding stuff into it that's already handled by other open protocols if there's no advantage in doing so.

Jabber support means one application can use the same common protocol for more things.

I'm still not convinced that using "one protocol for everything" is necessarilly a good reason for creating yet another VoIP protocol which is no more capable than the existing protocol (and from what I saw in the specs it's a good deal less capable). What's next? ditch HTTP and SMTP in favor of doing web and email over XMPP? Yes, it may be possible but does that make it worthwhile changing what we already have?

Re:About Time

[Thomas Charron]

Errm, except you _do_ need to modify the client, otherwise it won't understand the new data you're transporting (VoIP). So where was the advantage over using the industry standard protocol?

    When it comes to mixed mode mdia comminications, SIP is hardly a standard. The closest thing that comes to s standard is Netmeeting, and yes, it can interface with SIP, but doesn't use it natively. The purpose of Jingle *IS NOT* to provide a telephone number for your IM name.

    On another note, once upon a time, people would have looked at your funny and said 'Why use this SIP crap? Just use Digital T1 signaling over the wire!'.

Similarly, if you want the server to do anything interesting you also need to modify that (voicemail?).

    There are many things from a serverside perspective that can be done and applied to any interaction that does not require knowledge of the services that server provides specifically. Store and forward, message routing, delivery confirmation, are just a few examples of what it can provide.

    Is it a bad time to point out that alot of SIP interfaces can use HTTP to transport call information?

    Christ, what good does a hypertext protocol do for a telephone call? :-)

I would much prefer to see effort going into supporting the existing industry standard protocol rather than creating another set of software that just reimplements what we already have in an incompatable way (I still haven't found a decent FOSS Linux SIP softphone). And on the subject of compatability, you can already get plenty of hardware SIP phones (either desk phones or walk-about 802.11 phones) and they won't work with XMPP.

    Well, go do it. Alot of us who might actually work on some of these things don't like being told what we should be doing just becouse YOU want it. Most would consider THAT sort of request.. Commercial Software.. But I'm glad you have the need to give your preferences on what the engineers having fun should be doing..

    Ever wonder *WHY* you can't find any decent VoIP open source softphones?

Re:About Time

[FireFury03]

When it comes to mixed mode mdia comminications, SIP is hardly a standard. The closest thing that comes to s standard is Netmeeting, and yes, it can interface with SIP, but doesn't use it natively.

Why does the VoIP signalling and IM traffic need to go over the same protocol? When you click a link in an email would you expect the web pages it points to to be retrieved over SMTP? If you have a SIP server and an XMPP server running on the same domain name and using the same user database then there's no reason why the client can't do IM over XMPP and VoIP over SIP transparantly.

On another note, once upon a time, people would have looked at your funny and said 'Why use this SIP crap? Just use Digital T1 signaling over the wire!'.

VoIP offers significant advantages over stuffing TDM traffic over a T1 or E1. I can't see any similarly significant advantages in using XMPP rather than SIP. The telco industry is slowly migrating from SS7 to SIGTRAN (as a stop-gap) and to IMS, which incorporates SIP - like it or not, SIP _is_ the industry standard VoIP protocol these days and there's a lot of software and hardware available to support it.

If we were designing VoIP from scratch then XMPP would be the place to put it, but with existing kid out there it seems silly to introduce another protocol which isn't really advantageous. To me, the only difference between Google inventing Jingle and Microsoft deciding they don't like Open Document and inventing something that does exactly the same job is that Jingle is open source - that still doesn't make it a Good Thing.

Most would consider THAT sort of request.. Commercial Software.. But I'm glad you have the need to give your preferences on what the engineers having fun should be doing..

Whilest I'm sure Google's employees may well have fun doing this stuff, this _is_ a commercial project - it was invented by Google for commercial reasons. I'd like to see some *good reasons* why they decided that they couldn't implement their project on a SIP architecture - "it's more fun" is not what I consider to be a good reason why a commercial entity would reinvent the wheel.

Re:i want conference mode and pocketpc voice clien

[zootm]

The main Gaim developer was hired by Google and given the low-down on the Jingle project some time ago, and it'll be added to the Gaim-vv system that's apparently coming in Gaim 2.0.

There is one.

[Anonymous Coward]

It's called GAIM. What you live under a rock?

Simple interim solution for server-to-server

[Nurgled]

Google should implement server-to-server but drop any incoming messages from users that are not on the recieving user's roster. This way people can still talk to their friends on other Jabber servers but unsolicited messages won't be a problem since they'll be dropped outright.

This may cause difficulties for agents that aren't people, such as services and bots, but at least it would open things up a little for person-to-person communication.

Great...

[HellYeahAutomaton]

So does this mean we can drop the already dead H.323 protocol and replace it with Jingle in Asterisk?

Hello, McFly

[Anonymous Coward]

Want to know the difference between Google and Microsoft?

Google have shown that they can be trusted. Microsoft have shown that they can not. If and when Google do something that breaks that trust, then it would be prefectly acceptable to expect people to show a similiar level of distrust in both Google and Microsoft. Until that happens, you're simply being paranoid with no proof. I understand such a condition can be treated with strong medication.

Alternative Library Name

[MikeFoss18]

They couldn't have come up with something better than libjingle?

What about libjingoober?

Or better yet, just a library without that jingle crap called libgoober?

How about Jabber / Talk for a LAN?

[Fahrvergnuugen]

About a month ago I looked high and low for an open source, multiplatform VoIP solution for our company's LAN. I found a few great jabber servers, but much to my surprise/dismay, I couldn't find any clients that supported voice, only text IM.

Re:How about Jabber / Talk for a LAN?

[the grace of R'hllor]

That would be because there was no standard VoIP negotiation protocol for XMPP.

When we first heard of XMPP at the place where I'm at now we implemented it for signalling. Nice to see it's an actual JEP now.

What? Nobody has posted this yet?!

[LordKaT]

Google, Jaber, Jingle. You can hear my sleigh bells ring. I am 'ol Kris Kringle. I'm the king of jing-le-ing!

Jingle all the way to the bank?

[amliebsch]

Hopefully the Asterisk devs will implement this and quick. I'm dying for something like MS Live Communications Server (with the Office Communicator) that works with Asterisk.

Re:Jingle all the way to the bank?

[uhoreg]

If you read the Jabber.org press release, you'll see that Digium, the main sponsor of Asterisk, has pledged support for Jingle.

THIS is why Google is so great!

[sharpestmarble]

They release something as open source that they are close to the top in. There are some others that do this, but Google just recently released Google Talk(I don't have any numbers on this, can somebody confirm & link it?)

Well, this is just one reason.

Who gets IM spam?

[denjin]

Seriously...

I just only allow people on my friend or buddy list to IM me on all my acounts (google, MSN, Yahoo, and AIM). I've never ever gotten spam of any kind.

Re:i want conference mode and pocketpc voice clien

[Anonymous Coward]

imov Messenger for the PocketPC and Smartphone will add voice support via Jingle by Q1 2006. It already has conferencing (MUC) support, but Gtalk doesn't support MUC yet.

Google at SCALE 4x

[Anonymous Coward]

Google will be exhibiting at SCALE 4x as a Silver Sponsor. In addition they'll have 2 speakers at the show: Chris Dibona and Dan Kegel.

What if they call libjingle...

[Anonymous Coward]

Joogle?

That would make a Jabber-Jingle-Joogle!

Try to say that 5 times... now we just need the right tune... :-)

Open-Source Multimedia Peer-to-Peer?

[Anonymous Coward]

How does this compare to what amicima released as GPL'd open-source a few months ago? Seems like if you really want to do multimedia through NATs and firewalls, they have a better solution, albeit not Jabber.

Ubuntu Breezy packages

[takis]

Add this line to your /etc/apt/sources.list:
deb http://lumumba.uhasselt.be/takis/breezy ./

Or fetch the individual packages:
http://lumumba.uhasselt.be/~takis/breezy/libjingle 0_0.1.0-1_i386.deb
http://lumumba.uhasselt.be/~takis/breezy/libjingle -dev_0.1.0-1_i386.deb

Network federation/link

[Anonymous Coward]

Now if Google Talk only could connect their server to the Jabber network so people who dont use the Google server can talk to people on Google Gmail. And that people who use the Google server can talk to people on the Jabber network.

the SRV record

[J_Omega]

which one is it?

I'm kind of partial to "Texas Flood," but "Couldn't Stand the Weather" is a good'un too. Heck, they all are!

Patents

[Anonymous Coward]

How do they get around patents in the AV compression space?