- DNS sub-system in Kamailio
- DNS failover
- DNS load balancing
- NAT ( Network Address Translation)
- NAT ( Network Address Translation)
- Why is NAT is important in SIP?
- Types of NAT solutions
- NAT behaviours
- RTP NAT
- Fixing NAT
- NAT Traversal Module
- Why use keepalive when Registrations are already there for NATing ?
- How keepalives work for NATing ?
- function nat_keepalive()
- Params
- Functions
- client_nat_test()
- fix_contact()
- nat_keepalive()
- Pseudo Variables
- Statistics
- NATHelper Module
- NAT pinging types
- UDP packet
- SIP request
- params
- functions
- Pseudo Variables
- RPC Commands
- NAT pinging types
In this article, we discuss Nating in a SIP Server like Kamailio. Types of NAT pings, their behaviour and types. Also some implementation of some of the Kamailios modules like
- NAT Traversal module
- NAT helper module
- STUN module
A repository for extensive application of kamailio modules for various usecases is https://github.com/altanai/kamailioexamples
DNS sub-system in Kamailio
To resolve hostname into IPs Kamailio can do either of below
- use libresolv and a combination of the locally configured DNS server /etc/hosts and the local Network Information Service (NIS/YP a.s.o) or
- cache the query results and first look into internal cache
DNS failover – if destination resolves to multiple addresses tm can try all of them until it finds one to which it can successfully send the packet or it exhausts all of them, with internal DNS cache. Also used when the destination host doesn’t send any reply to a forwarded invite within the SIP timeout interval (tm fr_timer parameter).
DNS load balancing – SRV based load balancing with weight value in the DNS SRV record.
- (-) Only the locally configured DNS server (usually in /etc/resolv.conf) is
used for the requests (/etc/hosts and the local Network Information Service are ignored).- optional: disable the DNS cache (use_dns_cache=off or compile without -DUSE_DNS_CACHE).
- (-) DNS cache uses extra memory
- optional: disable the DNS cache.
- (-) DNS failover introduces a very small performance penalty
- optional: disable the DNS failover (use_dns_failover=off).
- (-) DNS failover increases the memory usage (the internal structures used to represent the transaction are bigger when the DNS failover support is compiled).
- optional: compile without DNS failover support (DUSE_DNS_FAILOVER).Turning it off from the config file is not enough in this case (the extra memory will still be used).
NAT ( Network Address Translation)
Network address translation replaces the IP address within packets with a different IP address which internet endpoints can relate with. This enables multiple hosts in a private subnet with their pwn private address ( 10.x.x.x or 192.x.x.x etc ) to share single public IP address interface, to access the Internet.
NAT is bidirectional- If the private ip:port got translated to public ip:port on the inside interface while entering outside internet, on arriving from outside interface it will get translated from public ip:port to private ip:port.
For a SBC ( Session border controller ) or where the kamailio server is directly customer facing, where you dont have a private line or VPN to clients, then it is often encountered with NATed endpoints. Read more about NAT traversal using STUN and TURN here
Why is NAT is important in SIP?
These characteristics of SIP design and operation flows demonstrate why NAT solutions are so important
- RFC 3261 for SIP presumed end-to-end reachability and does not specify much around ANT issues .
- No NLRI (Network Layer Reachability Information) translation layer exists, such as DNS or ARP
- SIP is designed to used RTP which uses dynamically allocated ports to stream media.
It is comparable to FTP which creates ephemeral connections on unpredictable dynamic ports to send multiplexed data and “metadata”, instead of protocol like HTTP where all data is sent on same connection. - UDP (default transport for SIP) is connection less and session tracking requires these be mapped onto a statelful flow, rigorous keepalives and other such techniques like using TCP instead have their own tradeoffs
- since sip packets put network and transport information right on sip header they are limited by the rateability and awareness of their network interface thereby prevent other endpoint from reaching its ip or port
Types of NAT solutions
- Client-side NAT traversal – clients are responsible for identifying their WAN NLRI and adding ip and port to navigate them in outside world
- Server-side NAT traversal – SIP server should discover the client’s WAN addressing while clients continue to work transparently behind NAT. Requires that DIP server look at the source and destination ip and port of actual packets instead of relying on the encapsulated sip headers and SDP body.
- ALG (Application Layer Gateways) – mostly applied at router itself. wodk by susbtitung public IP/port information inplace of provate and vice versa for return packets. Limitataions – they dont provide a fullproof fix example they may fix Via but not the Contact address or SDP body or RTP ports
Far-end NAT traversal solution ( TURN server)
NAT behaviours
| Cone NAT | Symmetric NAT |
| Local client performs an outbound connection to a remote UA and a dynamic rule is created for the destination IP tuple, allowing the remote machine to connect back. | Local client allows inbound connections from a specific source IP address and port, also NAT assigns a new random source port for each destination IP tuple |
| Further subdivied into: 1. Full Cone NAT 2. Restricted Cone NAT – all requests from the same internal IP address and port are mapped to the same external IP address and port. -3. Port-Restricted Cone NAT |
RTP NAT
NAT not only applies to sip signalling packets but also to RTP. Even RTP packets are not able to transverse accross private -public network interfaces to the right place across a NAT’d connection.
To solve two-way media RTP performs RTP latching, where client listens for at least one RTP frame arriving at the destination port it advertised, and harvests the source IP and port from that packet and uses that for the return RTP path. RTP latching works out of the box for public RTP endpoints but not for ones behind NAT.
It is thus recommended to use an intermediate RTP relay such as RTPengine on kamailio. It is controlled via a UDP control socket by kamailio as an external process. More on installation and descrition of RTP engine on kamailio is covered here. When RTPengine control module receives RTP offer /answer from Kamailio, it opens a pair of RTP/RTCP ports to receive traffic and substitues in SDP. Doing so for both ends makes RTP engine come in the path of media stream packets for both directions.
A first INVITE has no no corresponding on NAT ( as no port has been allocated yet ) so the c= contact and m = media lines would look like
c=IN IP4 192.0.2.13.
m=audio 23767 RTP/AVP 0 101.
We can force RTP to go through a proxy by changing c line and m line to
c=IN IP4 address-of-proxy m=audio port-on-proxy RTP/AVP 0 101
A separate daemon called an RTP proxy (with a public IP address) that both user agents can send their audio to, can be setup by calling force_rtp_proxy().
Fixing NAT
When the client is behind NAT, following needs to be taken careof to provide smooth operation
- Ensuring Tranactional replies are sent to correct source address ( maybe using ;rport param and forcerport() method ) instead of just relying on via header transport protocol and port.
example:
if (client_nat_test("3")){
//CALL RE-INVITE/UPDATE Nat DETECTED $ci\n");
force_rport();
fix_contact();
...
}
also Change Media ip address to public IP
if(nat_uac_test("8") && search("Content-type: application/sdp")) {
// RE-INVITE/UPDATE CALL fix SDP- NAT
fix_nated_sdp("2");
}
Any far-end NAT traversal solution ( TURN server) if employed should stay in path of entire Dialog not just for initial INVITE transaction which many times results in ACK being dropped. This can be achived by adding Record-Route header of rr module to the initial INVITE request itself
Set the advertised address of the public-facing inetrface to the Public NAT IP using “listen” parameter
Ensure contact URI is NAT processed by using NATHelper modules which rewrites the domain portion of the Contact URI to contain the source IP and port of the request or reply. add_contact_alias([ip_addr, port, proto]) in NAThelper module which adds “;alias=ip~port~transport” parameter to the contact URI containing either received ip, port, and transport protocol or those given as parameters
Implement RTP proxy which performs NAT for streams such as rtpengine module
NAT Traversal Module
Provides far-end NAT traversal to kamailio’s SIP signalling. Its role is
- detect user agents behind NAT
- manipulate SIP headers so that user agents can continue working behind NAT transparently
- keepalives to UA behind NAT to preserve their visibility in network
Some pros and cons of NATTravsersal module
- (+) detect even UAs behind multiple cascaded NAT boxes, complex distributed env with multiple proxies
- (+) handle env where incoming and outgoing paths are diff for SIP messages
- (+) handle cases when routing path may even change between consecutive dialogs
- (+) can work for other than registered UA’s also
- (-) built for IPv4 NAT handling not adapted to support IPv6 session keepalives.
Why use keepalive when Registrations are already there for NATing ?
- NAT binding works for registered users who want incoming calls. However for cases like outgoing calls or for presence subscription notifications, failings registration implies inability to receive further in-dialog messages after the NAT binding expires. This artificial binding for registrations makes system unreliable and volatile as it doesnot guarantee the delivery of in-dialog messages for outgoing calls without registration renewal. Therefore keepalive are adopted which also works for unregistered users.
- Minimizes the traffic as only border proxies send keepalives which send keepalives statelessly, instead of having to relay messages generated by the registrars.
- Also for situations when DNS resolves diff proxies for outgoing or incoming path traditional register based keepalives fail to associate or dissociate correct routes.
How keepalives work for NATing ?
This mechanism works by sending a SIP request to a user agent behind NAT to make that user agent send back a reply. The purpose is to have packets sent from inside the NAT to the proxy often enough to prevent the NAT box from timing out the connection.
Module sends Keeplaives to preserve their visibility only in :
- Registration – for user agent that have registered to for incoming calls, triggering keepalive for a REGISTER request.
- Subscription – for presence agents that have subscribed to some events for receiving back notifications with SUBSCRIBE request.
- Dialogs – for user agents that have initiated an outgoing call for receiving further in-dialog messages.
When all the conditions to keepalive a NAT endpoint will disappear, that endpoint will be removed from the list with the NAT endpoints that need to be kept alive.
function nat_keepalive()
- the function needs to be called on proxy directly interacting with UA behind NAT.
- call only once for the requests (REGISTER, SUBSCRIBE or outgoing INVITEs) that triggers the need for network visibility.
- call before the request gets either a stateless reply or it is relayed with t_relay()
- for outgoing INVITE , it triggers dialog tracing for that dialog and will use the dialog callbacks to detect changes in the dialog state.
Dependencies – sl , tm and dialog module
Params
- keepalive_interval – time interval between sending a keepalive message to all the endpoints that need being kept alive. A negative value or zero will disable the keepalive functionality.
modparam("nat_traversal", "keepalive_interval", 30) // 30 seconds keeplaive inetrval
- keepalive_method – SIP method to use to send keepalive messages.usual ones are NOTIFY and OPTIONS. Default value is “NOTIFY”.
modparam("nat_traversal", "keepalive_method", "OPTIONS")
- keepalive_from – SIP URI to use in the From header of the keepalive requests. default sip:keepalive@proxy_ip,with IP address of the outgoing interface
modparam("nat_traversal", "keepalive_from", "sip:keepalive@altanai.com")
- keepalive_extra_headers – extra headers that should be added to the keepalive messages. Header must also include the CRLF (\r\n) line separator. Multiple headers can be specified by concatenating with \r\n separator.
modparam("nat_traversal", "keepalive_extra_headers", "User-Agent: Kamailio\r\nX-MyHeader: some_value\r\n")
- keepalive_state_file – filename where information about the NAT endpoints and the conditions for which they are being kept alive is saved . It is used when Kamailio starts to restore its internal state and continue to send keepalive messages to the NAT endpoints that have not expired in the meantime. Also used at kamailio restart as it avoids losing keepalive state information about the NAT endpoints.
modparam("nat_traversal", "keepalive_state_file", "/var/run/kamailio/keepalive_state")
Functions
- client_nat_test ()– Check if the client is behind NAT. Tests to be performed gievn by int can be :
1 – tests if client has a private IP address or one from shared address space in the Contact field of the SIP message.
2 – tests if client has contacted Kamailio from an address that is different from the one in the Via field.
4 – tests if client has a private IP address or one from shared address space in the top Via field of the SIP message.
For example calling client_nat_test(“3”) will perform test 1 and test 2 and return true if at least one succeeds, otherwise false.
- fix_contact() – replace the IP and port in the Contact header with the IP and port the SIP message was received from. Usually called after a succesfull call to client_nat_test(type)
if (client_nat_test("3")) {
fix_contact();
}
- nat_keepalive() – Triggers keepalive functionality for the source address of the request. When called it only sets some internal flags, which will trigger later the addition of the endpoint to the keepalive list if a positive reply is generated/received (for REGISTER and SUBSCRIBE) or when the dialog is started/replied (for INVITEs). For this reason, it can be called early or late in the script. The only condition is to call it before replying to the request or before sending it to another proxy. If the request needs to be sent to another proxy, t_relay() must be used to be able to intercept replies via TM or dialog callbacks.
If stateless forwarding is used, the keepalive functionality will not work. Also for outgoing INVITEs, record_route() should also be used to make sure the proxy that keeps the caller endpoint alive stays in the path.
if ((method=="REGISTER" || method=="SUBSCRIBE" ||
(method=="INVITE" && !has_totag())) && client_nat_test("3"))
{
nat_keepalive();
}
Pseudo Variables
- $keepalive.socket(nat_endpoint)
- $source_uri
Statistics
- keepalive_endpoints – total number of NAT endpoints that are being kept alive.
- registered_endpoints – NAT endpoints kept alive for registrations
- subscribed_endpoints – NAT endpoints kept alive for subscriptions.
- dialog_endpoints – Indicates how many of the NAT endpoints are kept alive for taking part in an INVITE dialog.
NATHelper Module
NAT traversal and reuse of TCP connections.
Helps symmetric UAs who are not able to determine their public address.
NAT pinging types
| UDP packet 4 bytes (zero filled) UDP packets are sent to the contact address. | SIP request a stateless SIP request is sent to the UDP contact address. |
| (+) low bandwitdh traffic, (+) easy to generate by Kamailio; | (+) bidirectional traffic through NAT (+) since each PING request from Kamailio (inbound traffic) will force the SIP client to generate a SIP reply (outbound traffic) – the NAT bind will be surely kept open. |
| (-) unidirectional traffic through NAT (inbound – from outside to inside); if many NATs do update the bind timeout only on outbound traffic, the bind may expire and closed. | (-) higher bandwitdh traffic (-) more expensive (as time) to generate by Kamailio; |
Dependencies – usrloc
Params
- force_socket – Socket to be used when sending NAT pings for UDP communication.
modparam("nathelper", "force_socket", "127.0.0.1:5060")
- natping_interval
- ping_nated_only
- natping_processes – How many timer processes should be created by the module for the exclusive task of sending the NAT pings.
- natping_socket
- received_avp – AVP used to store the URI containing the received IP, port, and protocol by fix_nated_register
- sipping_bflag
- sipping_from
- sipping_method
- natping_disable_bflag
- nortpproxy_str
- keepalive_timeout
- udpping_from_path
- append_sdp_oldmediaip
- filter_server_id
Functions
- fix_nated_contact() – rewrites the “Contact” header field with request’s source address:port pair
- fix_nated_sdp() – adds the active direction indication to SDP and updates ource ip address information too
- add_rcv_param() – add a received parameter to the “Contact” header fields or the Contact URI.
- fix_nated_register() exports the request’s source address:port into an AVP to be used during save()
- nat_uac_test()- check if client’s request originated behind a nat
- is_rfc1918()
- add_contact_alias() – Adds an “;alias=ip~port~transport” parameter to the contact URI
- handle_ruri_alias() – Checks if the Request URI has an “alias” parameter and if so, removes it and sets the “$du” based on its value.
- set_contact_alias()
Pseudo Variables
- $rr_count – Number of Record Routes in received SIP request or reply.
- $rr_top_count – If topmost Record Route in received SIP request or reply is a double Record Route, value of $rr_top_count is 2.
RPC Commands
nathelper.enable_ping
References :
- [1] https://www.kamailio.org/docs/modules/5.1.x/modules/nat_traversal.html
- [2] https://kamailio.org/docs/modules/5.1.x/modules/nathelper.html
- [3] https://www.kamailio.org/docs/modules/devel/modules/stun.html
- [4] RFC1631
- [5] RFC 4787
Telecom R & D 