[Adium-devl] Jingle, Sip and IAX2 in one step

[Sean Egan]

On 11/9/06, Colin Barrett <timber at lava.net> wrote:
> I think what Sean is *trying* to say is that: in a real-world
> situation, ICE is necessary to deal with firewalls and such. STUN does
> not, in his experience, cut it.

I originally said "almost irrelevant," but it's true. Jingle loses A
LOT without ICE. The main reason the Raw UDP transport was created is
solely to stream media directly to public servers that don't support
ICE (such as in interoperating with SIP). The documentation for the
Raw UDP XEP warns of this. The fact that Raw UDP is so much easier to
implement than ICE is worrisome; if major clients like Adium decide
Raw UDP is good enough, it will greatly impact the utility of Jingle
for the worse.

> I'd like a little bit more about the various ways ICE tries to manage
> things, but that's more just curiosity. Having Adium Just Work no
> matter what the networks situation is something we've been trying to
> work on, and I think having our AV stuff do that from the get go would
> be a BIG step in that direction

To satisfy your curiousity...

The Raw UDP XEP says "identify the one IP address/port combination
you're most likely to be reached at, and communicate it to the other
person."

ICE says "identify every single IP address/port combination you may
possibly be reached at, and send all of them. Then, have both sides
try each and every permutation of possible connections, and use
whichever one succeeds with the best round-trip-time."

Even with STUN, Raw UDP will fail fairly frequently. STUN fails with
restrictive NATs that open up bindings only to a specific IP
address/port. That is, only the STUN server you made the binding
request to can respond to you.

Suppose I'm sitting right next to Colin; we're both on the same
corporate network (which frequently have symmetric NATs). We each do a
STUN request, and tell the other person we're at two different ports
on the same NAT device. We try sending audio to each other, and the
router drops it on the floor.

In ICE, we've both also passed our local address. We connect directly,
without a problem.

Perhaps we're on the same corporate network, but I'm VPN'ed in from a
hotel. We both do STUN requests. I get the hotel NAT's IP address, he
gets the corporate NAT's IP address; I can't talk to him because the
corporate NAT won't let me through. Here, even the local address
wouldn't work, because my local address is that of the ($15/day) hotel
wireless.

However, ICE communicates ALL possible IP address/ports, on all
available interfaces... ethernet, wireless, vpn, etc.

Perhaps I'm plugged in to an ethernet connection and am also on
wireless. ICE does regular pings over every connection that works, to
determine which one to use. If the person is on the same wireless
network, it'll probably use that interface; otherwise it will use
wired.

All this ICE stuff succeeds in getting through 92% of the time,
according to Google's stats. I don't have a source to cite, but I
recall hearing that STUN alone is a little over 80%

In the RAW-UDP transport, the 20% of the time a direct connection
cannot be made, you're out of luck. In ICE, one of the candidates you
pass (along with local and STUN) is a relay candidate: the IP
address/port of a server that will relay packets for you. If this is
the only one that will let your pings go through, it will use it. With
a proper ICE implementation, packets are guaranteed to go through, and
will almost always go through directly (minimum latency).

This is not even to mention crazy scenarios libjingle takes care of
like corporate firewalls that block everything but HTTPS.

> I also I agree with Evan, we should target the Jingle spec as best we
> can with it being a moving target. It looks like we're going to need
> to use ICE, though. Alvaro, what are your thoughts?

*Please* go with ICE. It's certainly a lot more complex, but it's
really important for the entire XMPP network to standardize on this.

-s.