Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Google, Jabber, and Jingle 141

Posted by CowboyNeal from the happy-holidays dept.
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."
This discussion has been archived. No new comments can be posted.

Google, Jabber, and Jingle More

Google, Jabber, and Jingle

Comments Filter:

  • References... (Score:5, Informative)

    by Cherita Chen ( 936355 ) on Friday December 16, 2005 @02:53AM (#14270462) Homepage
    Google has an informative page wich includes all related links, etc... Here [google.com]

  • I see... (Score:1, Funny)

    by RussR42 ( 779993 )
    This is some sort of christmas joke, right?

  • Spam (Score:3, Interesting)

    by HillaryWBush ( 882804 ) on Friday December 16, 2005 @02:55AM (#14270469)
    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.

    • 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 (Score:2, Informative)

        by Randle_Revar ( 229304 )

        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 [jabber.org]) the jokes are clearly marked.

      • Re:Spam (Score:1, Interesting)

        by 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 (Score:5, Insightful)

      by ciroknight ( 601098 ) on Friday December 16, 2005 @03:10AM (#14270502)
      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 (Score:5, Insightful)

        by burns210 ( 572621 ) <maburns@gmail.com> on Friday December 16, 2005 @04:10AM (#14270615) Homepage Journal
        (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).

        • 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

          • 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.

        • 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

      • 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 (Score:5, Insightful)

          by ciroknight ( 601098 ) on Friday December 16, 2005 @04:50AM (#14270671)
          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 (Score:2, Funny)

            by HillaryWBush ( 882804 )
            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.

            • 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
          • 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 (Score:5, Informative)

        by Da w00t ( 1789 ) * on Friday December 16, 2005 @05:25AM (#14270714) Homepage
        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 [sf.net] 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 (Score:5, Funny)

          by ceejayoz ( 567949 ) <cj@ceejayoz.com> on Friday December 16, 2005 @08:25AM (#14271123) Homepage Journal
          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.
          • <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>
            • Quick, go tell the anti-spam vendors that all they need to do is blacklist spammer domain names! ;-)
              • 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.
                • 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.
                  • 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 (Score:1, Informative)

          by 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.

        • 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

        • 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 ;)

      • 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.

  • server-to-server (Score:5, Interesting)

    by Anonymous Coward on Friday December 16, 2005 @02:59AM (#14270478)
    Now if google would just implement server-to-server jabber connections, this might be useful!

    • Re:server-to-server (Score:5, Interesting)

      by Anonymous Coward on Friday December 16, 2005 @04:09AM (#14270611)
      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.
      • 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 runn
        • 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).
      • 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!

    • welcome to slashdot (Score:1, Interesting)

      by Anonymous Coward
      ...where 2 comments saying exactly the same thing have +5 [slashdot.org] and -1 [slashdot.org] respectively.

  • i want conference mode and pocketpc voice client (Score:2, Interesting)

    by 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.

  • broken links (Score:5, Funny)

    by netcrusher88 ( 743318 ) <netcrusher88@gm a i l . c om> on Friday December 16, 2005 @03:44AM (#14270573)
    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... (Score:5, Funny)

    by zarkzervo ( 634677 ) on Friday December 16, 2005 @03:47AM (#14270578) Homepage Journal
    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."

    • 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.
      • 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 ;)

  • Now only if.. (Score:5, Interesting)

    by luvirini ( 753157 ) on Friday December 16, 2005 @03:50AM (#14270582)
    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.. (Score:5, Informative)

      by ciroknight ( 601098 ) on Friday December 16, 2005 @04:07AM (#14270607)
      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.. (Score:2, Informative)

        by Randle_Revar ( 229304 )
        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.
        • 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.
      • 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.. (Score:4, Informative)

      by John Hurliman ( 152784 ) on Friday December 16, 2005 @04:36AM (#14270657) Homepage
      If [ceruleanstudios.com] only [sourceforge.net] someone [jdennis.net] would [kde.org] code [everybuddy.com] this [infoanarchy.org] idea [epicware.com].

  • Is the format wasting bits? (Score:3, Interesting)

    by Stan Vassilev ( 939229 ) on Friday December 16, 2005 @03:51AM (#14270583)
    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? (Score:4, Informative)

      by pikine ( 771084 ) on Friday December 16, 2005 @04:24AM (#14270641) Journal
      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.
      • They use jingle to set up a RTP channel.
      • 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
        • re: NAT, Jabber already has a specification (JEP-0065 [jabber.org]) for bytestream proxying. My guess is that's what will be used to get around NAT.
          • 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.
            • 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 [jabber.org]) 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 [saint-andre.com] for more history on Jingle.

              Using XMPP also allows the use of transports, which will allow Jabber to connect to SIP and IAX

              • 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?)
                • 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.

        • 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.

  • How does it fit in with... (Score:3, Interesting)

    by hug_the_penguin ( 933796 ) on Friday December 16, 2005 @04:04AM (#14270599) Homepage
    ...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 [slashdot.org] 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.

  • Psi (Score:1, Informative)

    by Anonymous Coward
    And it's already working in Psi [psi-im.org], awesome.
  • 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.
    • 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? (Score:2, Interesting)

        by n0d3 ( 708403 )
        I thought the intention was to use SIP as the underlaying protocol.

        • Re:Another voip protocol? (Score:4, Informative)

          by the grace of R'hllor ( 530051 ) on Friday December 16, 2005 @09:20AM (#14271355)
          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.
  • ... and call their sweet new product Gibber.

  • About Time (Score:5, Interesting)

    by ObsessiveMathsFreak ( 773371 ) <obsessivemathsfreakNO@SPAMeircom.net> on Friday December 16, 2005 @06:31AM (#14270853) Homepage Journal
    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.
    • 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.
      • 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.
        • 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
          • 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
            • 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 reas
  • So does this mean we can drop the already dead H.323 protocol and replace it with Jingle in Asterisk?

  • 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?

  • 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.
  • Google, Jaber, Jingle. You can hear my sleigh bells ring. I am 'ol Kris Kringle. I'm the king of jing-le-ing!
  • 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.

Slashdot Top Deals

"Conversion, fastidious Goddess, loves blood better than brick, and feasts most subtly on the human will." -- Virginia Woolf, "Mrs. Dalloway"

Close