[Standards-JIG] Jingle vs. Zoep

dirk.griffioen@voipster.com dgriffioen at voipster.com
Wed Feb 8 23:06:54 UTC 2006


Peter Saint-Andre wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>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.
>>>
>>>- Nolan
>>>
>>>      
>>>
>>Hi Nolan,
>>
>>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
>>(http://mail.jabber.org/pipermail/standards-jig/2006-February/009797.html):
>>
>>"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
>>SIP travels).
>>    
>>
>
>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
>>cross borders.
>>    
>>
>
>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
>not)?
>
>  
>
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 
questions here).

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

Dirk

>Peter
>
>- --
>Peter Saint-Andre
>Jabber Software Foundation
>http://www.jabber.org/people/stpeter.shtml
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (Darwin)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFD6mUlNF1RSzyt3NURApyhAKDOVNhTlAFwwh2ZwgRu2s6gOpd2WACgsnX0
>OEawjFTwrX5dvBry+9g8Adg=
>=rsKT
>-----END PGP SIGNATURE-----
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060209/e86194db/attachment.html>


More information about the Standards mailing list