[Standards] Simple Jingle example(s) and spec(s) wanted

Matt Tucker matt at jivesoftware.com
Mon Feb 5 23:17:45 UTC 2007


> > Sad but true. So I think you're right that we need to develop 
> > something in between full ICE + TURN + STUN and nothing. 
> That may well 
> > be a relatively simple mediated TCP|UDP bytestream. Which sounds an 
> > awful lot like XEP-0065, eh?
> I just want to throw in, that there is also a NAT punching 
> protocol called Teredo [1] which can be used to pass NAT 
> routers. Especially on Windows systems (XP SP 2+) this 
> protocol can very easily (=nearly transparent for the client) 
> be used. Teredo can even be used with all file transfer 
> protocols we already had (jabber:iq:oob, Bytestreams and
> Jingle) without modifications in the file transfer protocol.

Teredo looks similar to ICE:

 1) Determine NAT devices using STUN.
 2) Try to tunnel automatically.
 3) If that fails, use a proxy.

Anyway, XEP-0065 type proxies should work well for things like Jingle
file transfers. However, it's not the best approach for voice proxying.
I actually researched this a lot before (relunctantly) reaching that
conclusion. Voice/video generally always uses UDP for speed and because
it's ok to drop some packets. There is a UDP mode for SOCKS5, which is
even discussed in the XEP. However, that's a foreign concept in the
voice world. UDP media proxies basically always use a port range -- so,
each proxy connection uses two unique ports (one for each host using the
proxy). This type of proxy doesn't really contain much logic -- it just
opens the ports when told to, then routes traffic between them. That's
good for proxy implementors, and for clients which don't need to
understand anything extra about the proxy, like the SOCS5 protocol.

I dislike having so many possible paths -- simple TCP proxy (XEP-0065),
simple UDP proxy (discussed above), plus ICE. However, it seems like the
best option at the moment? 


More information about the Standards mailing list