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

[Alan Humpherys]

I agree with Sean and Evan that we should work very hard to make  
Adium "Just Work" (TM) on the firewall/NAT traversal mechanisms.

As I have been doing work on the support for the iChat AV/AIM  
protocols for AV, they use a mechanism with the same general  
principles as STUN/ICE to find their way through as many NAT and  
Firewall combinations as possible.   My plan is to support this  
mechanism, and I would like us to do the same thing with our JINGLE  
(GTalk) support.

I am working on a document for this on my blog and will try to post  
it tomorrow...  They use SNATMAP instead of STUN, and a proprietary  
protocol like ICE to try all possible combinations to get a  
connection going.

Suffice it to say that it is definitely worth the effort to support  
ICE in our Jingle application.  (Not that I am volunteering this  
week...  My hands are full with AIM/iChat)

Alan
______
Alan Humpherys


On Nov 9, 2006, at 8:46 PM, Sean Egan wrote:

> 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.
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com
>