> > I experimented a little bit and Asterisk behind NAT with SIP works. I created > > an account at iptel.org and use that account for outbound SIP traffic from > > Asterisk. > Great! I copied your information for other users to the Wiki. > > http://www.voip-info.org/tiki-index.php?page=Asterisk%20sip%20client%20SER > > Now, I have to check why it doesn't work on my Asterisk. Propably newbie behind > console keyboard, but anyway...
There has been a fair amount of discussion on the list as to whether nat works with various/different configurations of sip phones with *. The "exact" configuration required is highly dependent on a number of technical factors that must be well understood before anyone can make a generic statement relative to whether it works or doesn't work. Without that understanding, practically every statement made on the list has been based on opinion and/or some trial & error methodology that has resulted in a working example. (Nothing wrong with that, but the majority of the postings leave out critical info that causes the next person to attempt the same implementation but fails, and additional questions are generated.) The critical information needed to understand nat config's include: 1. Is * behind a nat box, sip phone behind a nat box, or both? 2. Is the nat box "sip aware"? 3. Can the nat box be programmed to forward a static "range" of ports to the "inside"? 4. Are there two nat boxes involved (one at each end of an expected sip-based connection)? 5. Does the sip phone support nat (eg, play nice with headers)? 6. Does * support nat (eg, play nice with headers) and is it config'ed? 7. Are there timers involved at either end of a nat traversal that are intended to keep nat table entries from timing out? 8. If so, what are the actual timeout values used for the specific nat box, and are sip end-point timers less then those of the nat box? (Don't assume all sip phones with nat functions are equal.) 9. What is the nat impact of a sip phone that has been configured to re-register every 60 seconds? 10. What is the range of rtp ports expected by the sip phone (eg, 7960's range from 16384 to 32766, but can be changed; xten uses 8000 to 8012 or something like that)? 11. Can the user implement iax (instead of sip) between end points? 12. When nat is found to function correctly, which end "originated" the nat traversal (makes a BIG difference)? And, probably another half dozen technical parameters that I'm forgetting to mention. I've spent many years working with corporate clients in more then 40 states diagnosing networking issues, doing protocol analysis, etc, and have seen a large number of nat boxes. The nat implementations from various vendors range from very basic translation tables to some rather sophisticated functions. And, just because a nat implementation comes from a well-known vendor doesn't mean anything (even Cisco has problems with "no" nat timeouts in certain boxes today). With that said, here's a couple of high-level examples that "could" work but these are not based on actual lab tests, etc. 1. If * is behind a nat box "and" * inititiates a tcp/udp conversation with a non-nat'ed address, some form of timer-based keep alive packet will keep the nat-box-table-entries active allowing the implementation to work. (Obviously assumes equipment can support sip header functions.) What are some of the configuration issues that may need to be addressed? a. limit the port numbers that can be used by * (rtp.conf) b. limit the port numbers that can be used by the sip phone. c. may still need to map the specific rtp port range in the nat box depending upon the nat box functionality. d. probably define nat=yes within *. (The real issue here is "which end initiated" the conversation and what is used to keep the nat translations active. I think we've already heard some folks doing this with certain Internet-based companies, but the postings left out a bunch of technical configuration data on both ends.) 2. * => nat => Internet => nat => sip phone Implement a combination of #1, above, at both ends assuming the end-point equipment has the capability to be configured (including the sip phone, nat boxes, etc). What tends to aggravate nat implementations are those NAT boxes that also implement PAT (port address translation), and the box vendor doesn't bother to hint at it in their documentation. (There are a very large number of networking folks that don't understand this, and its probably safe to assume 99.99% of the user community has never heard of it.) The PAT issues usually end up with someone suggesting sip phone #1 works but #2 doesn't and they are configured exactly the same. Or, call #1 works but call #2 fails. (And then the next person on the list says it works fine for them, but doesn't mention who's nat box he's using or what it's actually doing from a technical perspective.) I'd bet a small amount of money that Jan's example config fails under certain circumstances possibly including use of a different nat box, second sip phone, second phone call, etc. I think its fair to suggest that it would be nice to have working nat configurations documented, but it has to include a lot more specific info then just the * and sip phone config data. Working config's are out there, just need to gather config data from "all" components. Any volunteers? (may need to use a Sniffer/ethereal to document the actual ports used, etc.) <crawls off soap box and hides behind a nat box to avoid flames> _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users