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

[Evan Schoenberg]

(Please reply-to-all in this thread, as Brian West is not an Adium- 
devl subscriber).

I've spoken with Sean Egan, who is a leading engineer on the Google  
Talk team and the lead developer of Gaim, about Google, Jingle, ICE,  
and STUN.  He's basically the authority on all things related to Talk  
+ Open Source, which makes him an authority on Jingle and Google's  
plans for it.

Sean wrote:
> I'm working now on finishing up libjingle 0.4.0, after which, I'll
> commit the code to Google Code's svn and maintain it there, with the
> intent of making it track the XEPs (which are still a few weeks away
> from reaching draft state).
>
> When that hits 1.0.0 (meaning it's XEP-compliant), the client will  
> use it.
>
>> [Evan]: Is 0.4.0 any sort of an implied distance-from-XEP- 
>> compliance?  Are you
>> thinking weeks, months, or years?
> Weeks to months. Maybe about two months.

So the plan is for the official Google Talk clients to be using the  
standards-compliant version of jingle in approximately 2 months.   
Given that, working towards standards compliance rather than  
perceived Talk client compliance is definitely the way to go and is  
actually really good timing for us as a project.

In response to my queries about ICE, Sean wrote:
>  Jingle is almost irrelevent without ICE.

I asked for more detail on this, quoting Alvaro's statements about  
ICE not being a part of the Jingle JEP and summarizing the resulting  
discussion both on- and off-list to which I've been privy.  Sean  
replied:
> ICE is described at
> http://www.xmpp.org/extensions/xep-0176.html and has been part of the
> Jingle specs since before raw UDP was.
>
> Perhaps they meant the Jingle specs don't say ICE is *necessary,*
> which is true, but using STUN alone you're gong to have a lot of
> failure whenever anyone's behind NATs. I believe you've abandoned
> entire protocol implementations to avoid NAT problems before ;)

For those who, like me, aren't really up on what ICE and STUN do  
exactly, Sean's explanation in response to my query of "I'm not  
exactly sure what I'm debating here; can you enlighten me on what ICE  
is and why exactly I should care?" seems quite good:
> They're NAT-traversal methods. STUN is a naive system, where a host
> sends a request to an external STUN server which responds with the IP
> address and port that it received the request from (its
> externally-facing address). On some NATs, this will open up a binding
> on the NAT such that anything sent to the NAT on that port will be
> routed back to you. You can give that address out and then people can
> send you packets. If this happens for both sides, you can have a call.
>
> In ICE, both sides work together to figure out a way to get through
> their NATs. Both sides collect a ton of different possible addresses
> they can be reached at (their actual local address, their address
> determined from STUN, an address of a relay server that can relay
> packets between them), and they'll try them all to get the best
> quality connection as possible.

>> [Evan] You say Jingle is 'irrelevant' without ICE. When you say  
>> that, do you mean that, moving forward, Jingle will always be  
>> irrelevant without ICE, or is
>> Jingle-as-seen-in-Google-Talk's-Client-at-present irrelevant  
>> without ICE?
> Jingle is irrelevant without ICE, be it Google proto-ICE or the ICE
> XEPs as documented.

Gentlemen, discuss.  Civilly, please :)

-Evan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20061109/bd3f3c8b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20061109/bd3f3c8b/attachment.sig>