[Standards] Re: Jingle bootstrapping

Thiago Camargo thiago at jivesoftware.com
Mon Mar 5 03:10:08 UTC 2007


I just finish a diagram showing the flow of my proposal for Jingle ICE XEP. I'll send the example with the Stanzas soon.

You can take a look on it:


-----Original Message-----
From: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] On Behalf Of Jean-Louis Seguineau
Sent: domingo, 4 de março de 2007 12:38
To: standards at xmpp.org
Subject: [Standards] Re: Jingle bootstrapping 

Good proposal Matt!

I would like to add that there is a lot of FUD in what many believe to be
insurmountable hurdles for NAT traversal. As you put it, the existing
standards work is bound by the constraints of SIP, more specifically the use
of UDP for SIP (signaling). As you have found out, this constraint does
*NOT* exist for XMPP, hence the facility with which you can have media
traverse several level of NAT. In short, the XMPP/TCP signaling path is
always available for the Jingle signaling between endpoints in a session. As
a result, we do *NOT* need STUN/TURN because the Jingle/XMPP signaling path
does not use UDP.

The second point of simplification is ICE. Once again, ICE has to cater for
the constraint of SIP for its implementation. But we should IMHO focus on
the philosophy of ICE rather than reproducing the protocol per se. ICE use
bursts of transport offers without waiting for the other party answers,
instead of a sequence of offers and associated answers in the traditional
SIP/SDP negotiation. We will benefit from the good ideas behind this IETF
standard without endorsing it blindly. And we also know this is working, as
this is what GTalk is using. In the end, we can greatly improve the
understanding of Jingle by just saying that it provides a two ways to
negotiate transports a/ burst of offers a la XEP-176, b/ sequential offers a
la XEP-177. It might be a good idea to remove the reference to ICE in


More information about the Standards mailing list