Up until now we have run SER as a foreground process. From this point forward we will run SER as a daemon. The fork directive tells the SER daemon to run in the background. This is a requirement for using the init.d start script shown in the appendix.

Since we are running SER as a background process we must set the log_stderror directive equal to no in order to not keep SER in the foreground.

The uri module is introduced here to access the has_totag() function. This function is necessary for processing re-INVITEs and is described below.

Here we load the nathelper module. Nathelper has functionality for rewriting SIP messages. It also communicates with rtpproxy, which is a standalone program. Make sure that you have rtpproxy started before you start SER. It can be found in the same cvs repository as SER or you can use the SER package provided on http://www.onsip.org/ under Downloads. Start rtpproxy without parameters and make sure it is running using the 'ps -ax | grep rtpproxy' command. If SER cannot communicate with rtpproxy, you will get errors in /var/log/messages when staring SER."

The textops module provide utility functions for manipulating text, searching for substrings, and checking for the existence of specific header fields.

Unlike mediaproxy, rtpproxy does not have a built-in ping keep-alive capability (i.e. sending packets regularly to the clients to make sure the NAT binding is kept in place and thus incoming SIP messages or RTP streams can come in). However, this functionality is instead built into nathelper.

The natping_interval is a very crucial setting which controls how often our ser proxy will ping registered SIP UAs. Most NAT devices will only hold port bindings open for a minute or two, so we specify 30 seconds here.

This causes ser to send a 4-byte UDP packet to each SIP UA every 30 seconds. This is all that is required to keep NATed clients alive.

NOTE: Some NAT devices have been reported to not allow incoming keep-alives. Thus, many UAs have their own implementations of keep-alive. If you experience one-way audio problems after a while, you may have run into this problem. The only solution is to turn on user client keep-alives.

Nathelper can ping all UAs or only the ones that have been flagged with a special nat flag (see further below). We only need to ping NATed clients as we assume all other clients have public addresses and keep-alive is not needed.

Ser and rtpproxy communicate via a standard Unix socket, with the default socket path specified here.

NOTE: If you change the socket path here, you must be sure to start rtpproxy with the parameter: s unix:socketpath

You can also start rtpproxy with f to let it run without forking. It will then show you what is happening.

When SIP clients attempt to REGISTER with our SIP proxy we need a way to tell the registrar module to store NAT information for the UA. We do this by using flag 6, which has been arbitrarily chosen (but defined earlier in the moduel parameter section). We could have specified another integer here, but 6 has become the accepted default for nat_flag.

When nat_flag is set before calling the save() function to store contact information, then ser will also preserve the NAT contact information as well as set the flags column in the MySQL location table. By doing so, we can call lookup(location) when processing messages and flag 6 will be set for NATed clients.

When we decide that a particular call must be proxied through our proxy server, we must also ensure that the call is torn down when a call is hung up (BYE) or cancelled (CANCEL).

Our NAT traversal requirements must handle re-INVITE messages in a special manner to prevent RTP media streams from dropping off during a re-INVITE. So we do special re-INVITE NAT processing here. The has_totag() function will return true if the SIP message has a To header field. If it has, the message be will be in-dialog.

force_rtp_proxy() has an l (lookup) parameter. When this parameter is specified, rtpproxy will only proxy the call if a session already exists. The reason for doing this is that rtpproxy cannot really know that this is a re-INVITE and we want to avoid unnecessary proxying calls that do not need it. All re-INVITEs will call force_rtp_proxy(l), but only existing proxied sessions will be re-proxied. We cannot put the force_rtp_proxy() call inside the nat_uac_test check, as this will prevent proxying to happen if the re-INVITE is sent from a non-NATed UA to a NATed UA (because nat_uac_test() will be false).

The other things we do here are: if NAT is detected for the UA sending the INVITE, set the NAT flag, so we know this is a NATed call (setflag(6)), add the received port to top-most via header (force_rport), as well as rewrite the Contact header with the public IP address of the user client (fix_nated_contact).

In the event that our message is no longer to be handled by our SIP router, we call our NAT handling route block to enable rtpproxy if needed before sending the message to its destination.

We now explicitly handle CANCEL messages. CANCEL messages can be safely processed with a simple call to t_relay() because SER will automatically match the CANCEL message to the original INVITE message. So here we just route the message to the default message handler.

Enable rtpproxy if needed before sending the message to its destination.

When dealing with NATed clients, we must correctly handle response messages that are destined back to the client. These response messages are accessible in ser by using a reply_route block.

Ser allows you to specify multiple reply_route blocks, which can perform many tasks. Here we specify that any reply messages must be passed to reply_route["1"], which is defined at the end of the ser.cfg file.

In order to invoke a reply_route, you simply need to set the handler prior to calling t_relay(), as we have done here.

If something goes wrong and we have called force_rtp_proxy (so that rtpproxy set up a new proxy call), we need to tell rtpproxy to tear it down again using unforce_rtp_proxy().

When SIP clients attempt to REGISTER with our SIP proxy we need a way to tell the registrar module to store NAT information this particular UA. We do this by using flag 6, which has been arbitrarily chosen (but defined earlier in the module parameter section). We could have specified another integer here, but 6 seems to be the accepted standard for nat_flag.

When nat_flag is set before calling the save() function to store contact information, then ser will also preserve the NAT contact information as well as set the flags column in the MySQL location table. By doing so, we can later call lookup(location) when processing messages and flag 6 will be set for NATed clients.

In order to determine whether a SIP client is NATed we use the nathelper function nat_uac_test(), which accepts an integer as a parameter. This parameter specifies which part of the SIP message to examine for determining the NAT status of the client. 19 indicates a common subset of tests, and are the recommended tests.

NOTE: These are the tests you can run using nat_uac_test (in the order they are employed):

The numbers in paranthesis indicate the number to be used to invoke the test in nat_uac_test(). To invoke more than one test, add up the numbers of the tests you want to run. So, as we use nat_uac_test(19) in our script, it means that test #1 (16) + #2 (2) + #3 (1) = 19, are run.

WARNING: Before changing the tests, you should know what you are doing. You should scrutinize the SIP message coming from your UAs to determine which tests will be true.

You will notice that we first call the search() function to find out if the <Contact:> header contains an asterisk or not. We only test for NAT if the <Contact:> header is not an asterisk.

NOTE: If the <Contact:> header is an asterisk rather than a SIP URI, then this indicates that the SIP client is attempting to unregister with the SIP proxy. The ser save() function has special provisions to remove all binds for the AOR in this case. It is important to understand that we cannot accurately determine the NAT status of a client when the contact information is missing.

We test to see if the user client is behind NAT, if so, we set the NAT flag (6). This flag is used further below.

Enable rtpproxy if needed before sending the message to its destination.

Enable rtpproxy if needed before sending the message to its destination.

Now that we have taken care of all the NAT related items, we can safely send the INVITE message to its destination.

Route[4] is a convenience route to enable rtpproxy.

If a client is NATed, we must do the following things: Add the received (public) port to the top-most Via header (force_rport), rewrite the Contact header with the public IP address and port of the NAT in front of the user client (fix_nated_contact), and set up the proxying using force_rtp_proxy(). Nathelper will then communicate to rtpproxy, which will allocate RTP (UDP) ports and the SDP payload of the INVITE will be rewritting (see the introductory section on NATing for details).

Here we introduce a reply_route. A reply_route is defined just like any other block in ser. The only difference is that it is called onreply_route.

Any message that is passed to this block will be returning to the original sender. You can think of these messages as the response to the original request that the caller made. The types of messages that will appear here will have an integer response code, much like HTTP response codes. Examples here would be 200, 401, 403, and 404.

In this ser.cfg we are only interested in response codes of 180, 183, and all 2xx messages for NATed clients. We can check the status as shown with a regular expression. If any of these response codes are found then this statement will be TRUE.

An important thing to note is that we can check flags set in the other route blocks because their scope is still valid. So our caller and callee NAT flags are still accessible.

We can only call force_rtp_proxy() for SIP messages that have a valid <contact> parameter in the SDP payload. So here we test to make sure the c= parameter is valid by simply checking the SDP payload length. We assume that if we have an SDP payload then we will have a c= parameter and can call force_rtp_proxy ().

Before our reply_route processing is complete we have one more NAT test to try. Here we make sure the <Contact:> header does not contain an RFC1918 IP address. If it does, then we replace it with the public IP address and port of the NAT in front of the user client.