[Standards-JIG] Jingle vs. Zoep
dgriffioen at voipster.com
Wed Feb 8 23:06:54 UTC 2006
Peter Saint-Andre wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>dirk.griffioen at voipster.com wrote:
>>Nolan Eakins wrote:
>>>Other than that, I would shy away from having two VoIP specs. If this
>>>proposal was vastly superior, then it would be good to phase out the
>>>lesser. That's not the case here.
>>Could you maybe elaborate a little on 'that's not the case here'? As is,
>>it feels like an unargumented qualification (no offense meant :-) ).
>I think Nolan's point is that the Zoep document does not make a strong
>argument that the Zoep approach is superior to the Jingle approach. So
>in the absence of such an argument, it is not obvious that the Zoep
>approach is indeed superior.
The document was not meant to state superiority, it rather points out a
way how to do things without going into questions like these.
>>Secondly, other than Peters remark
>>"2. Require dual-stack clients and simply launch SIP from XMPP",
>>in my view Zoep is not really a dual stack client.
>Well, in a sense it seems to be, because you're just sending full SIP
>traffic in an XMPP wrapper, so presumably you have to hand off the SIP
>messages to a SIP stack for processing.
Yes, of course, but, using Jingle would mean handing it over to a Jingle
stack of some sort. Then, what is the difference?
One good argument would be validating the payload for conformity (as you
state below) and/or security, but SIP is not unstructured or 'raw' as
you put it below: it has a structure and can be parsed and thus
validated. Either way, doing this would take processing power and
therefore time, so maybe we can cross them out against one another?
>>It rather separates SIP and XMPP to do what they do best:
>>- SIP is concerned with signalling states
>>- XMPP concerns the transport and routing.
>>(In SIP terms, I believe, this is called a 'transport' - SIP allows for
>>multiple transports: TCP, UDP; XMPP is merely the layer on top of which
>I would not say that XMPP is a "transport" in the sense that TCP or UDP
>is in the OSI Model.
Got me there, it's not OSI - but forgive me, otherwise I would have to
read through 250 pages of SIP (or ...) again; what I am advocating here
is that there is really no need for a Jingle state-machine and more; it
just seems like renventing the weel where many rolling roll, but yes a
fancy one it is :-)
>>In a way this this is a 2 layered approach where both layers are
>>transparant to each other. SIP does not care about XMPP and vice versa
>>(it's 'just a message' to XMPP)..
>>We use XMPP for all the benefits it has, but we do not bring signalling
>>state and other issues into the XMPP realm. A clear separation of
>>concern if you will. It has the added benefit of being compatible with
>>all existing SIP solutions available out-of-the box and further, there's
>>no need for a heavy duty gateway: you just remove/add the XMPP layer to
>Part of the problem I see is that both XMPP and SIP have addressing
>formats, which are different. What is the relationship between a SIP
>address and an XMPP address in Zoep? Are they the same? If so, how do
>you handle internationalized addresses (which XMPP supports but SIP does
For pc2pc calls, all addressing, authentication or internationalization
would be handled by XMPP; only the signalling and subsequent states go
through the SIP stack. For pc2pstn (we call it that) the call would be
to a number, and dealt with by the SIP stack itself (wide open to
>Another issue: authentication. It's optional in SIP, required in XMPP.
>Also, validated from addresses. Unsupported in SIP, required in XMPP.
>In general we don't like to send raw text over XMPP. One of the reasons
>certain organizations like XMPP is that they can validate all the
>traffic using the XML schemas for XMPP and its extensions. Sending raw
>SIP within XMPP could be seen as an effort to get around that kind of
>schema checking. SIP is a wide open texty format and it's hard to know
>what is really being sent across the wire.
>In general I'd like to see an argument for why SIP-over-XMPP is a great
>approach. What are the benefits? What do we gain? Is it more secure?
>More scalable? More user-friendly? Easier to implement for developers?
>(If so, why? SIP is huge, are you assuming that developers will just
>make a call out to a SIP stack rather than writing a SIP implementation
>of their own? What's the interaction between the XMPP stack and the SIP
>stack? Etc.) Easier to deploy for admins?
Code reuse, ease of implementation, ease of connection with 'legacy', as
secure as both XMPP and SIP are.
It is not more user-friendly (the user would not know if signalling
passes gateways or not - maybe it's slower? I believe this was mentioned
at the mailing list), or more scalable (we still would need hardware).
Existing SIP stacks can be used, if they have an abstraction for the
transport - one would add an XMPP transport and presto ...
The admins I don't know about, could you hint?
>Jabber Software Foundation
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (Darwin)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards