[Standards-JIG] Jingle vs. Zoep

Peter Saint-Andre stpeter at jabber.org
Wed Feb 8 21:39:50 UTC 2006


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

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

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

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

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?

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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060208/b5cc69d0/attachment.bin>


More information about the Standards mailing list