Here is an excerpt from the spec:
Upon communication with members of the Google Talk team, it was discovered that the emerging Jingle approach was conceptually (and even syntactically) quite similar to the signalling protocol used in the Google Talk application. Therefore, in the interest of interoperability and adoption, we decided to harmonize the two approaches. The signalling protocol specified therein is, therefore, substantially equivalent to the existing Google Talk protocol, with several adjustments based on feedback received from implementors as well as for publication within the Jabber Software Foundation's standards process.
The spec document is written in an accessible language. It was easy for me to grasp the concepts and scetch out the basic interactions between calling parties. Looks like a protocol that should be relatively easy to implement in client devices.
The authors deliberately chose to push as much complexity as possible to gateways and servers. Even more so than in SIP. In several sections in the document the text points out why certain features were implemented differently than SIP, which shows the advantage that the authors had designing something from scratch taking into account lessons learned from SIP experience.
I have been told in the past from engineers at several telco operators that SIP is somewhat heavy to implement for thin mobile devices as compared to XMPP. At the time Jingle was not standardized, so the comparison could not have been complete. Still their experience was an indication that XMPP may be a formidable competitor to SIP for VoIP signaling.
For as long as both protocols are open standards, I am only expecting good things to happen for both mainstream developers and end user.
See the full text of the Jingle Specification Document.
4 comments:
Why does everybody insist on inventing their own little standard? Can't they all just agree on SIP as the VOIP signaling standard, and collaborate on making it better. Besides pushing intelligence back into the core of the network is so Class Fiveish. This whole thing is just silly, IMO.
In a perfect world, everyone would agree on a single standard. In the real world, the way to get there is through open competition. H323 is also an IP based VoIP standard, which preceded SIP. As it turns out, SIP competed successfully and is the preferred protocol now. XMPP Jingle may be just another iteration in the evolution of VoIP protocols. This is a relatively new area after all.
I would not interpret the Jingle architecture as an attempt to push intelligence to the core. Nothing prevents a smart client device to act as an end point as well as gateway.
Instead, having a simplistic requirement for end points means that even the thiniest clients can participate in the network.
Ivelin,
I admit I don't know much about jingle, or XMPP for that matter to give an educated opinion. But I'll say this, I generally don't feel comfortable when you take a certain piece of technology that was intended for something (P&IM in the case of XMPP) and try to target it at another type of application, as an afterthought. So now they want to handle voice/video, any ideas on how they are planning to handle other apps like, collaboration for instance, or multimodal communications? What's their story with respect to IMS? is IMS support in their future?
SIP, on the other hand, has been designed from the ground up as a signaling protocol for establishing all kind of communicating apps between various endpoints. It so happened voice was the first one to be implemented. Also, IMS figures front and center in its design.
Mike,
You got me here. I am not aware of any good story positioning XMPP or Jingle in IMS. It looks more like a grass roots aproach that is not influenced or taking into account all telco initiatives where SIP is positioned. This is not necessarily a bad thing though.
Ivelin
Post a Comment