<!-- Module User's Guide -->

<chapter>
	<chapterinfo>
	<revhistory>
		<revision>
		<revnumber>$Revision: 1827 $</revnumber>
		<date>$Date: 2007-03-12 17:22:53 +0200 (Mon, 12 Mar 2007) $</date>
		</revision>
	</revhistory>
	</chapterinfo>
	<title>User's Guide</title>
	
	<section>
	<title>Overview</title>
	<para>
		This is a module to help with &nat; traversal. In particular, 
		it helps symmetric &ua;s that don't advertise they are symmetric 
		and are not able to determine their public address. fix_nated_contact 
		rewrites Contact header field with request's source address:port pair. 
		fix_nated_sdp adds the active direction indication to &sdp; (flag
		0x01) and updates source &ip; address too (flag 0x02).
	</para>
	<para>
		Known devices that get along over &nat;s with nathelper are ATAs 
		(as clients) and Cisco Gateways (since 12.2(T)) as servers.  See <ulink
		url="http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bf9.html">
		http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bf9.html"></ulink>
	</para>
	</section>

	<section>
	<title>NAT pinging types</title>
	<para>
		Currently, the nathelper module supports two types of NAT pings:
	</para>
	<itemizedlist>
		<listitem>
			<para>
			<emphasis>UDP package</emphasis> - 4 bytes (zero filled) UDP 
			packages are sent to the contact address.
			</para>
			<itemizedlist>
				<listitem>
				<para><emphasis>Advantages:</emphasis> low bandwitdh traffic,
				easy to generate by &ser;;
				</para>
				</listitem>
				<listitem>
				<para><emphasis>Disadvantages:</emphasis> unidirectional 
				traffic through NAT (inbound - from outside to inside); As 
				many NATs do update the bind timeout only on outbound traffic,
				the bind may expire and closed.
				</para>
				</listitem>
			</itemizedlist>
		</listitem>
		<listitem>
			<para>
			<emphasis>SIP request</emphasis> - a stateless SIP request is 
			sent to the contact address.
			</para>
			<itemizedlist>
				<listitem>
				<para><emphasis>Advantages:</emphasis> bidirectional traffic
				through NAT, since each PING request from &ser; (inbound 
				traffic) will force the SIP client to generate a SIP reply 
				(outbound traffic) - the NAT bind will be surely kept open.
				</para>
				</listitem>
				<listitem>
				<para><emphasis>Disadvantages:</emphasis> higher bandwitdh 
				traffic, more expensive (as time) to generate by &ser;;
				</para>
				</listitem>
			</itemizedlist>
		</listitem>
	</itemizedlist>
	</section>

	<section>
	<title>Dependencies</title>
	<section>
		<title>&ser; Modules</title>
		<para>
		The following modules must be loaded before this module:
			<itemizedlist>
			<listitem>
			<para>
				<emphasis>usrloc</emphasis> module - only if the NATed 
				contacts are to be pinged.
			</para>
			</listitem>
			</itemizedlist>
		</para>
	</section>
	<section>
		<title>External Libraries or Applications</title>
		<para>
		The following libraries or applications must be installed before 
		running &ser; with this module loaded:
			<itemizedlist>
			<listitem>
			<para>
				<emphasis>None</emphasis>.
			</para>
			</listitem>
			</itemizedlist>
		</para>
	</section>
	</section>
	<section>
	<title>Exported Parameters</title>
	<section>
		<title><varname>natping_interval</varname> (integer)</title>
		<para>
		Period of time in seconds between sending the NAT pings to all 
		currently registered &ua;s to keep their &nat; bindings alive. 
		Value of 0 disables this functionality.
		</para>
		<note><para>
		Enabling the NAT pinging functionality will force the module to
		bind itself to USRLOC module.
		</para></note>
		<para>
		<emphasis>
			Default value is 0.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>natping_interval</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("nathelper", "natping_interval", 10)
...
</programlisting>
		</example>
	</section>
	<section>
		<title><varname>ping_nated_only</varname> (integer)</title>
		<para>
		If this variable is set then only contacts that have 
		<quote>behind_NAT</quote> flag in user location database set will 
		get ping.
		</para>
		<para>
		<emphasis>
			Default value is 0.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>ping_nated_only</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("nathelper", "ping_nated_only", 1)
...
</programlisting>
		</example>
	</section>
	<section>
		<title><varname>received_avp</varname> (str)</title>
		<para>
		The name of the Attribute-Value-Pair (AVP) used to store the URI 
		containing the received IP, port, and protocol. The URI is created 
		by fix_nated_register function of nathelper module and the attribute 
		is then used by the registrar to store the received parameters. Do 
		not forget to change the value of corresponding parameter in
		registrar module if you change the value of this parameter.
		</para>
		<note>
		<para>
		You must set this parameter if you use "fix_nated_register". In such
		case you must set the parameter with same name of "registrar"
		module to same value.
		</para>
		</note>
		<para>
		<emphasis>
			Default value is "NULL" (disabled).
		</emphasis>
		</para>
		<example>
		<title>Set <varname>received_avp</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("nathelper", "received_avp", "$avp(i:42)")
...
</programlisting>
		</example>
	</section>
	<section>
		<title><varname>rtpproxy_sock</varname> (string)</title>
		<para>
		Socket used to connect to RTPProxy. It may specify a UNIX socket or an
		IPv4/IPv6 UDP socket.
		</para>
		<para>
		<emphasis>
			Default value is <quote>unix:/var/run/rtpproxy.sock</quote>.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>rtpproxy_sock</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("nathelper", "rtpproxy_sock", "udp:localhost:12221")
...
</programlisting>
		</example>
	</section>
	<section>
		<title><varname>rtpproxy_disable</varname> (integer)</title>
		<para>
		If true (set to a non 0 value), the RTPProxy support will be
		disabled - no connection to it will be established.
		</para>
		<para>
		<emphasis>
			Default value is <quote>0 (false)</quote>.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>rtpproxy_disable</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("nathelper", "rtpproxy_disable", 1)
...
</programlisting>
		</example>
	</section>
	<section>
		<title><varname>rtpproxy_disable_tout</varname> (integer)</title>
		<para>
		Once RTPProxy was found unreachable and marked as disable, nathelper
		will not attempt to establish communication to RTPProxy for 
		rtpproxy_disable_tout seconds.
		</para>
		<para>
		<emphasis>
			Default value is <quote>60</quote>.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>rtpproxy_disable_tout</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("nathelper", "rtpproxy_disable_tout", 20)
...
</programlisting>
		</example>
	</section>
	<section>
		<title><varname>rtpproxy_tout</varname> (integer)</title>
		<para>
		Timeout value in waiting for reply from RTPProxy.
		</para>
		<para>
		<emphasis>
			Default value is <quote>1</quote>.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>rtpproxy_tout</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("nathelper", "rtpproxy_tout", 2)
...
</programlisting>
		</example>
	</section>
	<section>
		<title><varname>rtpproxy_retr</varname> (integer)</title>
		<para>
		How many times nathelper should retry to send and receive after
		timeout was generated.
		</para>
		<para>
		<emphasis>
			Default value is <quote>5</quote>.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>rtpproxy_retr</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("nathelper", "rtpproxy_retr", 2)
...
</programlisting>
		</example>
	</section>
	<section>
		<title><varname>force_socket</varname> (string)</title>
		<para>
		Socket to be forced in communicating to RTPProxy. It makes sense only
		for UDP communication. If no one specified, the OS will choose.
		</para>
		<para>
		<emphasis>
			Default value is <quote>NULL</quote>.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>force_socket</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("nathelper", "force_socket", "localhost:33333")
...
</programlisting>
		</example>
	</section>
	<section>
		<title><varname>sipping_bflag</varname> (integer)</title>
		<para>
		What branch flag should be used by the module to identify NATed 
		contacts for which it should perform NAT ping via a SIP request 
		instead if dummy UDP package.
		</para>
		<para>
		<emphasis>
			Default value is -1 (disabled).
		</emphasis>
		</para>
		<example>
		<title>Set <varname>sipping_bflag</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("nathelper", "sipping_bflag", 7)
...
</programlisting>
		</example>
	</section>
	<section>
		<title><varname>sipping_from</varname> (string)</title>
		<para>
		The parameter sets the SIP URI to be used in generating the SIP
		requests for NAT ping purposes. To enable the SIP request pinging
		feature, you have to set this parameter. The SIP request pinging 
		will be used only for requests marked so.
		</para>
		<para>
		<emphasis>
			Default value is <quote>NULL</quote>.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>sipping_from</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("nathelper", "sipping_from", "sip:pinger@siphub.net")
...
</programlisting>
		</example>
	</section>
	<section>
		<title><varname>sipping_method</varname> (string)</title>
		<para>
		The parameter sets the SIP method to be used in generating the SIP
		requests for NAT ping purposes.
		</para>
		<para>
		<emphasis>
			Default value is <quote>OPTIONS</quote>.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>sipping_method</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("nathelper", "sipping_method", "INFO")
...
</programlisting>
		</example>
	</section>
	<section>
		<title><varname>nortpproxy_str</varname> (string)</title>
		<para>
		The parameter sets the SDP attribute used by nathelper to mark
		the packet SDP informations have already been mangled.
		</para>
		<para>
		If empty string, no marker will be added or checked.
		</para>
		<note><para>
		The string must be a complete SDP line, including the EOH (\r\n).
		</para></note>
		<para>
		<emphasis>
			Default value is <quote>a=nortpproxy:yes\r\n</quote>.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>nortpproxy_str</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("nathelper", "nortpproxy_str", "a=sdpmangled:yes\r\n")
...
</programlisting>
		</example>
	</section>
	</section>


	<section>
	<title>Exported Functions</title>
	<section>
		<title>
		<function moreinfo="none">fix_nated_contact()</function>
		</title>
		<para>
		Rewrites Contact <acronym>HF</acronym> to contain request's source 
		address:port.
		</para>
		<para>
		This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, BRANCH_ROUTE.
		</para>
		<example>
		<title><function>fix_nated_contact</function> usage</title>
		<programlisting format="linespecific">
...
if (search("User-Agent: Cisco ATA.*") {fix_nated_contact();};
...
</programlisting>
		</example>
	</section>
	<section>
		<title>
		<function moreinfo="none">fix_nated_sdp(flags [, ip_address])</function>
		</title>
		<para>
		Alters the SDP information in orer to facilitate NAT traversal. What
		changes to be performed may be controled via the 
		<quote>flags</quote> paramter.
		</para>
		<para>Meaning of the parameters is as follows:</para>
		<itemizedlist>
			<listitem><para>
			<emphasis>flags</emphasis> - the value may be a bitwise OR of 
			the following flags:
			</para>
			<itemizedlist>
				<listitem>
					<para><emphasis>0x01</emphasis> - adds 
					<quote>a=direction:active</quote> SDP line;
					</para>
				</listitem>
				<listitem>
					<para><emphasis>0x02</emphasis> - rewrite media
					&ip; address (c=) with source address of the message
					or the provided IP address (the provide IP address take
					precedence over the source address).
				</listitem>
				<listitem>
					<para><emphasis>0x04</emphasis> - adds 
					<quote>a=nortpproxy:yes</quote> SDP line;
				</listitem>
				<listitem>
					<para><emphasis>0x08</emphasis> - rewrite IP from
					origin description (o=) with source address of the message
					or the provided IP address (the provide IP address take
					precedence over the source address).
				</listitem>
			</itemizedlist>
			</listitem>
			<listitem><para>
			<emphasis>ip_address</emphasis> - IP to be used for rewritting SDP.
			If not specified, the received signalling IP will be used. The
			parameter allows pseudo-variables usage. NOTE: For the IP to be
			used, you need to use 0x02 or 0x08 flags, otherwise it will have
			no effect.
			</para>
		</itemizedlist>
		<para>
		This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, 
		FAILURE_ROUTE, BRANCH_ROUTE.
		</para>
		<example>
		<title><function>fix_nated_sdp</function> usage</title>
		<programlisting format="linespecific">
...
if (search("User-Agent: Cisco ATA.*") {fix_nated_sdp("3");};
...
</programlisting>
		</example>
	</section>
	<section>
		<title>
		<function moreinfo="none">force_rtp_proxy([flags [, ip_address]])</function>
		</title>
		<para>
		Rewrites &sdp; body to ensure that media is passed through 
		an &rtp; proxy. It can have optional parameters to force additional
		features. If ip_address is provided, it will be used to replace the
		one in SDP.
		</para>
		<para>Meaning of the parameters is as follows:</para>
		<itemizedlist>
		<listitem>
			<para>
			<emphasis>flags</emphasis> - flags to turn on some features.
			</para>
			<itemizedlist>
				<listitem><para>
				<emphasis>a</emphasis> - flags that UA from which message is
				received doesn't support symmetric RTP.
				</para></listitem>
				<listitem><para>
				<emphasis>l</emphasis> - force <quote>lookup</quote>, that is,
				only rewrite SDP when corresponding session is already exists 
				in the RTP proxy. Only makes sense for SIP requests, replies 
				are always processed in <quote>lookup</quote> mode.
				</para></listitem>
				<listitem><para>
				<emphasis>i</emphasis> - flags that message is received from 
				UA in the LAN (internal network). Only makes sense when 
				RTP proxy is running in the bridge mode.
				</para></listitem>
				<listitem><para>
				<emphasis>e</emphasis> - flags that message is received from 
				UA in the WAN (external network). Only makes sense when RTP 
				proxy is running in the bridge mode.
				</para></listitem>
				<listitem><para>
				<emphasis>f</emphasis> - instructs nathelper to ignore marks 
				inserted by another nathelper in transit to indicate that the 
				session is already goes through another proxy. Allows creating 
				chain of proxies.
				</para></listitem>
				<listitem><para>
				<emphasis>r</emphasis> - flags that IP address in SDP should 
				be trusted. Without this flag, nathelper ignores address in 
				the SDP and uses source address of the SIP message as media 
				address which is passed to the RTP proxy.
				</para></listitem>
				<listitem><para>
				<emphasis>o</emphasis> - flags that IP from the origin 
				description (o=) should be also changed.
				</para></listitem>
				<listitem><para>
				<emphasis>c</emphasis> - flags to change the session-level 
				SDP connection (c=) IP if media-description also includes 
				connection information.
				</para></listitem>
				<listitem><para>
				<emphasis>s</emphasis> - flags to swap creation with 
				confirmation between requests and replies. By default, a 
				request creates the RTP session and a reply confirms it. If
				swapped, a reply will create the RTP session and a request
				will confirm it.
				</para></listitem>
			</itemizedlist>
		</listitem>
		<listitem><para>
		<emphasis>ip_address</emphasis> - new SDP IP address.
		</para></listitem>
		</itemizedlist>
		<para>
		This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, 
		FAILURE_ROUTE, BRANCH_ROUTE.
		</para>
		<example>
		<title><function>force_rtp_proxy</function> usage</title>
		<programlisting format="linespecific">
...
if (search("User-Agent: Cisco ATA.*") {force_rtp_proxy();};
if (src_ip=1.2.3.4) {force_rtp_proxy("i");};
if (search("User-Agent: Cisco ATA.*") {force_rtp_proxy("","1.2.3.4");};
...
</programlisting>
		</example>
	</section>
	<section>
		<title>
		<function moreinfo="none">unforce_rtp_proxy()</function>
		</title>
		<para>
		Tears down the RTPProxy session for the current call.
		</para>
		<para>
		This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.
		</para>
		<example>
		<title><function>unforce_rtp_proxy</function> usage</title>
		<programlisting format="linespecific">
...
unforce_rtp_proxy();
...
</programlisting>
		</example>
	</section>
	<section>
		<title>
		<function moreinfo="none">add_rcv_param([flag])</function>,
		</title>
		<para>
		Add received parameter to Contact header fields or Contact URI.
		The parameter will 
		contain URI created from the source IP, port, and protocol of the 
		packet containing the SIP message. The parameter can be then 
		processed by another registrar, this is useful, for example, when 
		replicating register messages using t_replicate function to
		another registrar.
		</para>
		<para>Meaning of the parameters is as follows:</para>
		<itemizedlist>
			<listitem><para>
			<emphasis>flag</emphasis> - flags to indicate if the parameter
			should be added to Contact URI or Contact header. If the flag is
			non-zero, the parameter will be added to the Contact URI. If not
			used or equal to zero, the parameter will go to the Contact 
			header.
			</para></listitem>
		</itemizedlist>
		<para>
		This function can be used from REQUEST_ROUTE.
		</para>
		<example>
		<title><function>add_rcv_paramer</function> usage</title>
		<programlisting format="linespecific">
...
add_rcv_param(); # add the parameter to the Contact header
....
add_rcv_param("1"); # add the paramter to the Contact URI
...
</programlisting>
		</example>
	</section>
	<section>
		<title>
		<function moreinfo="none">fix_nated_register()</function>
		</title>
		<para>
		The function creates a URI consisting of the source IP, port, and 
		protocol and stores the URI in an Attribute-Value-Pair. The URI will 
		be appended as "received" parameter to Contact in 200 OK and 
		registrar will store it in the user location database.
		</para>
		<para>
		This function can be used from REQUEST_ROUTE.
		</para>
		<example>
		<title><function>fix_nated_register</function> usage</title>
		<programlisting format="linespecific">
...
fix_nated_register();
...
</programlisting>
		</example>
	</section>
	<section>
		<title>
			<function>nat_uac_test(flags)</function>
		</title>
		<para>
			Tries to guess if client's request originated behind a nat.
			The parameter determines what heuristics is used.
		</para>
		<para>Meaning of the flags is as follows:</para>
		<itemizedlist>
			<listitem><para>
			<emphasis>1</emphasis> -  Contact header field is searched 
			for occurrence of RFC1918 addresses.
			</para></listitem>
			<listitem><para>
			<emphasis>2</emphasis> -  the "received" test is used: address
			in Via is compared against source IP address of signaling
			</para></listitem>
			<listitem><para>
			<emphasis>4</emphasis> -  Top Most VIA is searched 
			for occurrence of RFC1918 addresses
			</para></listitem>
			<listitem><para>
			<emphasis>8</emphasis> -  SDP is searched for occurrence of 
			RFC1918 addresses
			</para></listitem>
			<listitem><para>
			<emphasis>16</emphasis> -  test if the source port is different
			from the port in Via 
			</para></listitem>
		</itemizedlist>
		<para>
		All flags can be bitwise combined, the test returns true if any of 
		the tests identified a NAT.
		</para>
		<para>
		This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.
		</para>
	</section>
</chapter>

<!-- Keep this element at the end of the file
Local Variables:
sgml-parent-document: ("nathelper.sgml" "Book" "chapter")
End:
-->
