Aaron Clauson wrote: > ICE (which is STUNv2 and TURN) may be better at handling NATs but it > requires TURN for the cases that STUNv1 couldn't handle and TURN isn't > a signalling solution. In my humble opinion if proxying media is the > answer why not just multiplex the media and the signalling in the > first place, aka IAX & Skype, and avoid the need to implement ICE (yes > multiplexing means scalability suffers but so does TURN). I always > find these sorts of discussion ironic, ALGs were introduced to help > SIP deal with NAT but because they generally make such a mess of > things they are now one of the reasons to introduce ICE, a fix for a > fix for a fix; RFC3261 not handling NAT being fixed by ALGs being > fixed by ICE.
ALGs are bad, ALGs bundled with STUN-capable clients are the worst thing that can happen. Full-ACK on this. We all know that RFC3261 didn't take care of NAT issues. All complaints on this fact will not help - I'd suggest to look forward instead. ICE, SIP-OUTBOUND and other well done documents are showing us the way to go. ICE is a really good thing. It would allow you to run a hosted PBX on public internet for many phones behind a single NAT, leaving all RTP streams for internal calls within that very same internal network. By "hosted PBX" I do NOT mean Asterisk, but something really able to route SIP: you could use a few proxy servers to scale out, maybe equipped with a B2BUA layer for some special features... There are available SIP Proxy implementations able to understand ICE and to add relay canditates on-the-fly. At least the latest OpenSIPS / MediaProxy releases can do so, give them a try. They would allow you to seriously scale out. With them, UACs do not even need to gather relay candidates using classic TURN mechanisms. I cannot immagine a better and more scalable solution than ICE-capable UACs provided with local, reflected and relay canditates. Btw: STUN as of RFC5389 is able to detect (many) ALGs. However as far as I remember it does not tell us what an UAC shall do if it does so ;-) > I appreciate it's a somewhat philosophical debate and doesn't answer > your original question so I'll stop while I've only put one foot in > it. Thank you ;-) Anyone else? The original question was: how should an UAC able to do nothing but STUN as of RFC3489 behave, if it discovers itself being behind a symmetric NAT? a) ignore this fact and use nonetheless the reflected information it retrieved using STUN (IP:Port...) b) do NOT use this information, leave SIP and SDP as it would sit on public internet, filled with information from it's very own local sockets I'd strongly opt for b), however there are implementations doing a). So where can I point them to prove that b) is better? Regards, Thomas Gelf -- mail: tho...@gelf.net web: http://thomas.gelf.net/ _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
