[Standards] Re: Jingle bootstrapping

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Sun Mar 4 15:37:35 UTC 2007

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