On 05/26/2011 07:17 PM, IP Phone Guy wrote:

Would mind giving me a run down of how it works and possibly some example configurations? I've done this with an ACME packet before but never done it with an open source product... I can't find any information on the respective websites and was hoping I could get some information out of the list here.

Sure. So, there are two aspects to far-end NAT traversal; the first is dealing with signaling, the second is dealing with media. In the case of signaling, you can either assume all the SIP endpoints are NAT'd, or you can use the 'nathelper' module's NAT detection routines to attempt to pinpoint them. http://www.kamailio.org/docs/modules/3.1.x/modules_k/nathelper.html#id260317... Its NAT test functions work by (1) looking for obvious instances of RFC 1918 private IPs in some combination of the Via header, Contact URI (if applicable) and the media endpoint address in the SDP body, depending on which of these are applicable, and (2) looking for inconsistencies between the endpoint addresses announced in the message body and the source addresses and ports from which the message is actually received on the network and transport layer. There are flags provided as arguments to nat_uac_test() that can be AND'd together to meet your needs. The nat_uac_test() approach is generally a fine way to proceed if you have a mixture of NAT'd and directly reachable devices, but can bite you if you have directly reachable devices on a private RFC 1918 subnet, since a lot of those tests will take the mere presence of those addresses as evidence of a NAT'd endpoint. Next, you call some functions exported by 'nathelper' to apply some "fixups" to the private or inconsistent addresses seen in Via, Contact, etc. Which should be applied depends on the type of request that you are handling; in the case of REGISTER, you should probably use fix_nated_register() and for INVITEs, fix_nated_contact(). You can, of course, use fix_nated_contact() on AOR bindings in REGISTER too. The "fixups" substitute the actual Layer 3 & 4 received address:port combination for the private addresses declared in the message body. The media is a slightly different issue, and depends on what kind of far-end signaling agent and media gateway element your endpoints are talking to. Almost all media endpoints today require symmetrical RTP, which means they expect to receive RTP on the same port from which they send it, and that's also the port they advertise in the SDP offer/answer. The problem is that almost no NAT gateway/CPE out there (including supposedly intelligent SIP ALGs) understands SIP, and especially SDP semantics or keeps state enough to create the appropriate stateful connection tracking/NAT mappings for the port actually advertised in the SDP. Thus, you'll get a scenario where some private endpoint like, say, 192.168.1.10 will advertise port 27910 in its SDP offer when making an outbound call, and the NAT router will pass that SDP body through unadulterated. But in reality, when the endpoint actually starts sending media, the NAT router will remap the source port to say, 52500. If the far end follows the SDP offer, it will attempt to send RTP _back_ to external.ip:27910 (which is the extent of what you will have told it to do just with signaling fixups alone), which of course will not work since the NAT gateway is unaware that external.ip:27910 is supposed to be mapped back to 192.168.1.10:27910. The workaround is, of course, for the media gateway to ignore the port in the SDP and instead listen for the genuine source port of the media on the transport layer, and use that to send media back. If you happen to have a media gateway on the far end that can do this draft-comedia style NAT detection, you're set. Most commercial equipment out there has the capability to do this, but it isn't necessarily enabled. If you have a softswitch or SBC or what have you that can do it, do it. However, if you're routing this traffic to, say, most Tier 1 ITSPs and CLECs' edge equipment, they are not going to do this for you for a variety of technical and policy reasons. Thus, you're going to need some sort of media relay which has the intelligence to perform the aforementioned sensing for you. Asterisk's 'nat=yes' option enables in this functionality. Kamailio and OpenSIPS work with a variety of third-party media relays via various API control sockets. The media relays don't necessarily have to be on the same host as the SIP proxy, and you can have multiple ones. The major ones are 'rtpproxy' by Maxim Sabolev and MediaProxy from AG Projects, as well as the newer 'iptrtpproxy' from the Kamailio/sip-router side. The latter two are Linux kernel-bound and use netfilter conntrack APIs for forwarding, which will get you closest to wire speed. 'rtpproxy' in contrast is a userspace process and won't perform quite as well, but can still deliver a respectable 1000+ calls per box on the right hardware. It is also by far the simplest to set up, use and administer for a relatively low call volume, which is why I recommend it. In that case, instead of using fix_nated_sdp() in 'nathelper', you just use the 'rtpproxy' module and engage the 'rtpproxy' as appropriate in SDP-bearing requests and replies: http://www.kamailio.org/docs/modules/3.1.x/modules_k/rtpproxy.html You don't want to blindly engage it for all requests and replies; I'd definitely ensure they have an SDP payload: if(search("Content-Type: application/sdp")) ... And, of course, it goes without saying that you'll need to associate (stateful/TM) reply handlers with your initial request handlers to make this work. You'll also need to shut down the rtpproxy relay for the given dialog once it's torn down, i.e. on BYE, and when it's aborted, on CANCEL (you will have already engaged 'rtpproxy' at that point on the initial INVITE request and subsequent non-100 1xx provisional reply, so as to handle in-band ringback, etc.). There are various config examples bundled with the package, though they strike me as being a bit out of date and at times, somewhat facile and incomplete. Still, they convey the general idea: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=examples/... Possible complications: 1. Re-invites, especially where the media stream pivots; you'll need to handle sequential (in-dialog / loose_route()'d / To-tag-having) INVITEs and their replies and pivot the 'rtpproxy' stream with them. 2. Dumb consumer NAT router ALGs that throw a wrench in your plans by trying to 'help' you on the near end, and screwing all your NAT detection and traversal up in the process. If at all possible, all SIP ALGs on the customer side should be disabled; without question, they do more harm than good. 3. Firewall/routing issues surrounding all this; there needs to be full UDP reachability to and from the media relay from both the far and near ends, which can be a problem if you use a lot of stateful firewall rules reliant on not admitting arbitrarily-appearing non-connection-oriented streams from third parties, e.g. ESTABLISHED,RELATED 'iptables' rules with Linux. Best of luck. Please let me know if there are any other questions or specifics I can provide. Cheers, -- Alex -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/