> -----Original Message----- > From: Philip Matthews [mailto:[EMAIL PROTECTED] > Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > > David Barrett's algorithm, if I understand it correctly, would work in > this situation. (As far as I can tell, David's is a simplified version > of ICE).
That's correct. The major differences (so far as I know) between what I'm doing and what ICE does include: - Peer's needn't exchange SDP before attempting connection establishment (rather, the rendezvous server just tells both sides the others' LAN/NAT addresses and they try to connect immediately). - Paths are evaluated in parallel rather than sequentially (ie, I attempt to contact you direct via the LAN and indirectly via your NAT at the same time, and then pick the faster of the two) - There's no support for TURN servers as my application doesn't require them (though it would be extremely straightforward to add). - Clients attempt NAT classification as a *purely advisory* function to support debugging and feed into certain non-critical pairwise optimizations. (Said another way, even if the classification is totally wrong, it'll still work.) - Clients use adaptive keepalives to a STUN server to keep their NAT/FW "hole" open. By "adaptive" I mean I use probing to determine highest safe keepalive frequency of the NAT/FW. (Incidentally, there's no requirement that any two clients use the same STUN server, and indeed I intend to move to enable a "distributed STUN service" using the peers themselves.) Basically, I do the minimum necessary for my requirements, which I respect are much easier than SIP's. However, know that despite my system being much easier, it has been *extremely difficult and time consuming* to get working, despite dozens of iterations drawing upon a network of hundreds of thousands of machines on which to test. Thus I would suggest that if my solution took as long as it did, and went through as many variations as it did, the SIP/ICE implementers should be very wary of hardening anything too early before it hits the real world. Because the real world is really, really strange and unpredictable, I can guarantee you that. Phillip's asked me to put together a bit more precise overview of the system I use and I'll try to get to that soon. -david _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
