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

[Colin Barrett]

I didn't know you had a blog -- I think it would be interesting for  
everyone to be following. URL, please? :)

-Colin

On Nov 9, 2006, at 8:58 PM, Alan Humpherys wrote:

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