Folks, please help me -- share with me techniques for NAT traversal you use and have hands-on experience with. People repeatedly ask about it, and I'd like to create an FAQ that reflects deployment experience and as wide user feed-back as possible. Just tell me the technique you use, its requirements, limitations, the devices it is known (not) to work with, why you prefer one method over the other, etc. I'll then try to compile it in an FAQ. So please send me an e-mail, an example is attached. I will appreciate any practical details. Thank you, -Jiri ---------------------------------------------------------------- technique: using symmetric communication requirements: phone devices that support symmetric communication; existing species: Cisco's ATA configuration practice: ATAs need to be configured to advertise public address in signaling, or learn it from REGISTER replies; alternatively, one can rewrite signaling using ser's nethelper module; one needs to rewrite SIP anyway because ATAs don't advertise their symmetricity; see www.foo.bar for info on configuring ATA... limitations: non-symmetric devices, like Messenger don't work; misc: ATA has no display, that's why I am anxiously waiting for more vendors to support symmetric signaling ---------------------------------------------------------------- technique: UPnP requirements: NATs and phones with UPnP support; Messenger and snom are known to support UPnP; there is linux support for it configuration practice: of course, upnp requires by definition no configuration ;-) (I'm not serious -- anyone actually tried it?) ---------------------------------------------------------------- technique: geek tweaks: set-up port forwading manually configuration practice: you need to configure NATs to split its public-side port numbers accross your private-side phones, and configure the phones (if they allows so) to use these port numbers; also, phones need to be configured to use publicly reachable address in their payloads requriements: configurable NATs (many residental NATs are configurable) and configurable phones (ATAs do that, I heard pingtel did it too) ---------------------------------------------------------------- technique: ALG requirements: SIP-capable NAT (like Intertex or Cisco/PIX) issues: intertex freezes my ssh connections after some time on-line and elderly models don't like all Ethernet devices; when things don't work, the red-button off-on helps sometimes ---------------------------------------------------------------- technique: STUN requirements: STUN-enabled phone (like k-phone, snom) limitations: doesn't work over symmetric NATs (words-of-mouth propaganda has been telling me that many residential NATs are fortunately not symmetric, but I don't know how objective this information really is) ---------------------------------------------------------------- -- Jiri Kuthan http://iptel.org/~jiri/