Slashdot Mirror
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."
I'm not fat, just big boned...
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.
Climate Progress - Hell and High Water
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
I'd tell you the chances of this story being a dupe, but you wouldn't like it.
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).
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
And it's already working in Psi, awesome.
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
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.
I once had a signature.
That's what Jabber server transports do, I use Psi to talk to my brother on MSN all the time.
Climate Progress - Hell and High Water
If only someone would code this idea.
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!
da w00t. mtfnpy?
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.
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.
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.
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.