[Standards] Re: Jingle bootstrapping

Peter Saint-Andre stpeter at jabber.org
Mon Mar 5 23:47:00 UTC 2007


Jean-Louis Seguineau wrote:
> 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.

Yes I think we have pretty darn good firewall traversal in XMPP. As long 
as port 5222 is open, we have connectivity for signalling. So how can we 
leverage that?

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

Right. Again, we want to build something that can interoperate but 
doesn't necessarily use all the pieces they need in SIP.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070305/f7390280/attachment.bin>


More information about the Standards mailing list