tm: docs - removed trailing spaces

src/modules/tm/doc/api.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" 
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
    "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
 
 <section id="tm.api" xmlns:xi="http://www.w3.org/2001/XInclude">
@@ -96,7 +96,7 @@ end of body
 	    </listitem>
 	    <listitem>
 		<para>
-		    CANCEL_TAG similarly enables strict matching of CANCELs 
+		    CANCEL_TAG similarly enables strict matching of CANCELs
 		    including to-tags--act of mercy to UACs, who screw up
 		    the to-tags (however, it still depends on how forgiving
 		    the downstream UAS is). Like with ACK_TAG, all this
@@ -129,7 +129,7 @@ end of body
 		</listitem>
 	    </itemizedlist>
 	</section>
-	
+
 	<section id="load_tm">
 	    <title>
 		<function>load_tm(*import_structure)</function>
@@ -233,7 +233,7 @@ end of body
 	    </itemizedlist>
 	    <para>Return value: 0 - success, &lt;0 - error.</para>
 	</section>
-    
+
 	<section id="t_cancel_suspend">
 	    <title>
 	    	<function>int t_cancel_suspend(unsigned int hash_index, unsigned int label)</function>

src/modules/tm/doc/functions.xml

@@ -237,11 +237,11 @@ event_route[tm:branch-failure:myroute] {
 ...
 loadmodule "/usr/local/lib/ser/modules/nathelper.so"
 ...
-route { 
+route {
 	/* if natted */
-	t_on_reply("1"); 
-	t_relay(); 
-} 
+	t_on_reply("1");
+	t_relay();
+}
 
 onreply_route[1] {
 	if (status=~ "(183)|2[0-9][0-9]"){
@@ -765,7 +765,7 @@ route {
 	    </listitem>
 	</itemizedlist>
 	<para>
-		See also: 
+		See also:
 			<varname>retr_timer1</varname>,
 			<varname>retr_timer2</varname>,
 			<function>t_reset_retr()</function>.

src/modules/tm/doc/params.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" 
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
 	"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 	[ <!ENTITY % local.common.attrib
 	 "xmlns:xi CDATA #FIXED 'http://www.w3.org/2001/XInclude'">
@@ -71,7 +71,7 @@ modparam("tm", "fr_inv_timer", 180000)
 	<section id="tm.p.max_inv_lifetime">
 	<title><varname>max_inv_lifetime</varname> (integer)</title>
 	<para>
-		Maximum time an INVITE transaction is allowed to be active (in 
+		Maximum time an INVITE transaction is allowed to be active (in
 		milliseconds). After this interval has passed from the transaction
 		creation, the transaction will be either moved into the wait state
 		or in the final response retransmission state, irrespective of the
@@ -80,28 +80,28 @@ modparam("tm", "fr_inv_timer", 180000)
 	</para>
 	<para>
 		An INVITE transaction will be kept in memory for maximum:
-		<varname>max_inv_lifetime</varname>+<varname>fr_timer</varname>(from 
+		<varname>max_inv_lifetime</varname>+<varname>fr_timer</varname>(from
 		the ACK to the final reply wait)+<varname>wt_timer</varname>.
 	</para>
 	<para>
-		The main difference between this timer and 
-		<varname>fr_inv_timer</varname> is that the 
-		<varname>fr_inv_timer</varname> is per branch, while 
+		The main difference between this timer and
+		<varname>fr_inv_timer</varname> is that the
+		<varname>fr_inv_timer</varname> is per branch, while
 		<varname>max_inv_lifetime</varname> is per the whole transaction.
-		Even on a per branch basis <varname>fr_inv_timer</varname> could be 
-		restarted. For example, by default if 
-		<varname>restart_fr_on_each_reply</varname> is not cleared, the 
-		<varname>fr_inv_timer</varname> will be restarted for each received 
+		Even on a per branch basis <varname>fr_inv_timer</varname> could be
+		restarted. For example, by default if
+		<varname>restart_fr_on_each_reply</varname> is not cleared, the
+		<varname>fr_inv_timer</varname> will be restarted for each received
 		provisional reply. Even if <varname>restart_fr_on_each_reply</varname>
 		is not set the <varname>fr_inv_timer</varname> will still be restarted
-		for each increasing reply (e.g. 180, 181, 182, ...). 
+		for each increasing reply (e.g. 180, 181, 182, ...).
 		Another example when a transaction can live substantially more than its
 		<varname>fr_inv_timer</varname> and where
-		<varname>max_inv_lifetime</varname> will help is when DNS failover is 
+		<varname>max_inv_lifetime</varname> will help is when DNS failover is
 		used (each failed DNS destination can introduce a new branch).
 	</para>
 	<para>
-		The default value is 180000 ms (180 seconds - the rfc3261 
+		The default value is 180000 ms (180 seconds - the rfc3261
 		timer C value).
 	</para>
 	<para>
@@ -127,12 +127,12 @@ modparam("tm", "max_inv_lifetime", 150000)
 	<section id="max_noninv_lifetime">
 	<title><varname>max_noninv_lifetime</varname> (integer)</title>
 	<para>
-		Maximum time a non-INVITE transaction is allowed to be active (in 
+		Maximum time a non-INVITE transaction is allowed to be active (in
 		milliseconds). After this interval has passed from the transaction
 		creation, the transaction will be either moved into the wait state
 		or in the final response retransmission state, irrespective of the
 		transaction <varname>fr_timer</varname> value.
-		It's the same as <varname>max_inv_lifetime</varname>, but for 
+		It's the same as <varname>max_inv_lifetime</varname>, but for
 		non-INVITEs.
 	</para>
 	<para>
@@ -140,9 +140,9 @@ modparam("tm", "max_inv_lifetime", 150000)
 		<varname>max_noninv_lifetime</varname>+<varname>wt_timer</varname>.
 	</para>
 	<para>
-		The main difference between this timer and 
-		<varname>fr_timer</varname> is that the 
-		<varname>fr_timer</varname> is per branch, while 
+		The main difference between this timer and
+		<varname>fr_timer</varname> is that the
+		<varname>fr_timer</varname> is per branch, while
 		<varname>max_noninv_lifetime</varname> is per the whole transaction.
 		An example when a transaction can live substantially more than its
 		<varname>fr_timer</varname> and where
@@ -175,7 +175,7 @@ modparam("tm", "max_noninv_lifetime", 30000)
 	<title><varname>wt_timer</varname> (integer)</title>
 	<para>
 	    Time for which a transaction stays in memory to absorb delayed
-	    messages after it completed (in milliseconds); also, when this 
+	    messages after it completed (in milliseconds); also, when this
 	    timer hits,
 	    retransmission of local CANCEL requests is stopped (a puristic but complex
 	    behavior would be not to enter wait state until local branches are
@@ -217,7 +217,7 @@ modparam("tm", "retr_timer1", 1000)
 	<para>
 	    Maximum retransmission period (in milliseconds). The retransmission
 		interval starts with <varname>retr_timer1</varname> and increases until
-		it reaches this value. After this it stays constant at 
+		it reaches this value. After this it stays constant at
 		<varname>retr_timer2</varname>.
 	</para>
 	<para>
@@ -236,12 +236,12 @@ modparam("tm", "retr_timer2", 2000)
     <section id="tm.p.noisy_ctimer">
 	<title><varname>noisy_ctimer</varname> (integer)</title>
 	<para>
-	    If set, INVITE transactions that time-out (FR INV timer) will be 
+	    If set, INVITE transactions that time-out (FR INV timer) will be
 		always replied. If it's not set, the transaction has only one
-		branch and no response was ever received on this branch, it 
+		branch and no response was ever received on this branch, it
 		will be silently dropped (no 408 reply will be generated)
 		This behavior is overridden if a request is forked, the transaction
-		 has a failure route or callback, or some functionality explicitly 
+		 has a failure route or callback, or some functionality explicitly
 		 turned it on  for a transaction (like the ACC module does to avoid unaccounted
 		 transactions due to expired timer).
 		Turn this off only if you know the client UACs will timeout and their
@@ -266,14 +266,14 @@ modparam("tm", "noisy_ctimer", 1)
 	<para>
 		If set (default), the <varname>fr_inv_timer</varname> for an INVITE
 		transaction will be restarted for each provisional reply received
-		(rfc3261 mandated behaviour). If not set, the 
+		(rfc3261 mandated behaviour). If not set, the
 		<varname>fr_inv_timer</varname> will be restarted only for the first
 		provisional replies and for increasing replies greater or equal 180
 		(e.g. 180, 181, 182, 185, ...).
 	</para>
 	<para>
 		Setting it to 0 is especially useful when dealing with bad UAs that
-		continuously retransmit 180s, not allowing the transaction to timeout 
+		continuously retransmit 180s, not allowing the transaction to timeout
 		(and thus making impossible the implementation of certain services,
 		like automatic voicemail after x seconds).
 	</para>
@@ -303,7 +303,7 @@ modparam("tm", "restart_fr_on_each_reply", 0)
 	<para>
 		Setting it to 0 can be used to enable first running some tests or
 		pre-processing on the INVITE and only if some conditions are met
-		manually send a 100 (using <function>t_reply()</function>). Note 
+		manually send a 100 (using <function>t_reply()</function>). Note
 		however that in this case all the 100s have to be sent "by hand".
 		<function>t_set_auto_inv_100()</function> might help to selectively
 		turn off this feature only for some specific transactions.
@@ -313,7 +313,7 @@ modparam("tm", "restart_fr_on_each_reply", 0)
 	</para>
 	<para>
 		See also: <function>t_set_auto_inv_100()</function>
-				  <varname>auto_inv_100_reason</varname>. 
+				  <varname>auto_inv_100_reason</varname>.
 	</para>
 	<example>
 		<title>Set <varname>auto_inv_100</varname> parameter</title>
@@ -353,7 +353,7 @@ modparam("tm", "auto_inv_100_reason", "Trying")
 	</para>
 	<para>
 		If UNIX sockets are used (e.g.: to communicate with sems) and sending
-		a message on a UNIX socket takes longer than 
+		a message on a UNIX socket takes longer than
 		<varname>unix_tx_timeout</varname>, the send will fail.
 	</para>
 	<para>
@@ -373,8 +373,8 @@ modparam("tm", "unix_tx_timeout", 250)
 	<title><varname>aggregate_challenges</varname> (integer)</title>
 	<para>
 		If set (default), the final response is a 401 or a 407 and more than
-		one branch received a 401 or 407, then all the WWW-Authenticate and 
-		Proxy-Authenticate headers from all the 401 and 407 replies will 
+		one branch received a 401 or 407, then all the WWW-Authenticate and
+		Proxy-Authenticate headers from all the 401 and 407 replies will
 		be aggregated in a new final response. If only one branch received the
 		 winning 401 or 407 then this reply will be forwarded (no new one
 		 will be built).
@@ -464,12 +464,12 @@ modparam("tm", "ac_extra_hdrs", "myfavoriteheaders-")
 		If set and the &kamailio; blocklist support is enabled, every 503 reply source is
 		added to the blocklist. The initial blocklist timeout (or ttl) depends
 		on the presence of a "Retry-After" header in the reply and the values of
-		the following tm parameters: <varname>blst_503_def_timeout</varname>, 
-		<varname>blst_503_min_timeout</varname> and 
+		the following tm parameters: <varname>blst_503_def_timeout</varname>,
+		<varname>blst_503_min_timeout</varname> and
 		<varname>blst_503_max_timeout</varname>.
 	</para>
 	<para>
-		<emphasis>WARNING:</emphasis>blindly allowing 503 blocklisting could 
+		<emphasis>WARNING:</emphasis>blindly allowing 503 blocklisting could
 		be very easily exploited for DOS attacks in most network setups.
 	</para>
 	<para>
@@ -488,11 +488,11 @@ modparam("tm", "blst_503", 1)
     <section id="tm.p.blst_503_def_timeout">
 	<title><varname>blst_503_def_timeout</varname> (integer)</title>
 	<para>
-		
+
 		Blocklist interval in seconds for a 503 reply with no "Retry-After"
 		header.
-		See also <varname>blst_503</varname>, 
-		<varname>blst_503_min_timeout</varname> and 
+		See also <varname>blst_503</varname>,
+		<varname>blst_503_min_timeout</varname> and
 		<varname>blst_503_max_timeout</varname>.
 	</para>
 	<para>
@@ -513,18 +513,18 @@ modparam("tm", "blst_503_def_timeout", 120)
     <section id="tm.p.blst_503_min_timeout">
 	<title><varname>blst_503_min_timeout</varname> (integer)</title>
 	<para>
-		
-		Minimum blocklist interval in seconds for a 503 reply with a 
-		"Retry-After" header. It will be used if the "Retry-After" value is 
+
+		Minimum blocklist interval in seconds for a 503 reply with a
+		"Retry-After" header. It will be used if the "Retry-After" value is
 		smaller than this value.
 	</para>
 	<para>
-		See also <varname>blst_503</varname>, 
-		<varname>blst_503_def_timeout</varname> and 
+		See also <varname>blst_503</varname>,
+		<varname>blst_503_def_timeout</varname> and
 		<varname>blst_503_max_timeout</varname>.
 	</para>
 	<para>
-		The default value is 0 
+		The default value is 0
 	</para>
 	<example>
 	    <title>Set <varname>blst_503_min_timeout</varname> parameter</title>
@@ -539,18 +539,18 @@ modparam("tm", "blst_503_min_timeout", 30)
     <section id="tm.p.blst_503_max_timeout">
 	<title><varname>blst_503_max_timeout</varname> (integer)</title>
 	<para>
-		
-		Maximum blocklist interval in seconds for a 503 reply with a 
-		"Retry-After header". It will be used if the "Retry-After" value is 
+
+		Maximum blocklist interval in seconds for a 503 reply with a
+		"Retry-After header". It will be used if the "Retry-After" value is
 		greater than this limit.
 	</para>
 	<para>
-		See also <varname>blst_503</varname>, 
-		<varname>blst_503_def_timeout</varname> and 
+		See also <varname>blst_503</varname>,
+		<varname>blst_503_def_timeout</varname> and
 		<varname>blst_503_min_timeout</varname>.
 	</para>
 	<para>
-		The default value is 3600 
+		The default value is 3600
 	</para>
 	<example>
 	    <title>Set <varname>blst_503_max_timeout</varname> parameter</title>
@@ -628,9 +628,9 @@ modparam("tm", "blst_methods_lookup", 1)
 		The possible values are 0, 1, and 2.
 	</para>
 	<para>
-		- <emphasis>0</emphasis> will immediately stop the request (INVITE) 
-		retransmission on the branch and it will behave as if the branch was 
-		immediately replied with a 487 (a fake internal 487 reply). The 
+		- <emphasis>0</emphasis> will immediately stop the request (INVITE)
+		retransmission on the branch and it will behave as if the branch was
+		immediately replied with a 487 (a fake internal 487 reply). The
 		advantage is the unreplied branches will be terminated immediately.
 		However it introduces a race risk with a possible slightly delayed
 		 2xx reply. In this case we could have an UA receiving a 2xx after a
@@ -640,19 +640,19 @@ modparam("tm", "blst_methods_lookup", 1)
 		 a later time). This is the behaviour for SER versions older than 2.1.
 	</para>
 	<para>
-		- <emphasis>1</emphasis> will keep retransmitting the request on 
+		- <emphasis>1</emphasis> will keep retransmitting the request on
 		unreplied branches. If a provisional answer is received a CANCEL
-		will be immediately sent back (attempting to quickly trigger a 487). 
+		will be immediately sent back (attempting to quickly trigger a 487).
 		This approach is race free and avoids the 2xx after 487 problem, but
 		 it's more resource intensive: faced with a branch towards and UA that
 		 doesn't answer, a CANCEL attempt will keep the transaction alive for
 		 the whole timeout interval (<varname>fr_timer</varname>).
 	</para>
 	<para>
-		- <emphasis>2</emphasis> will send and retransmit CANCEL even on 
+		- <emphasis>2</emphasis> will send and retransmit CANCEL even on
 		unreplied branches, stopping the request retransmissions. This has the
-		same advantages as <emphasis>1</emphasis> and also avoids the extra 
-		roundtrip in the case of the provisional reply, but it's not RFC 3261 
+		same advantages as <emphasis>1</emphasis> and also avoids the extra
+		roundtrip in the case of the provisional reply, but it's not RFC 3261
 		conforming (the RFC allows sending CANCELs only on pending branches).
 	</para>
 	<para>
@@ -749,7 +749,7 @@ function ksr_slreply(evname) {
 	<section id ="tm.p.contacts_avp">
 		<title><varname>contacts_avp</varname> (string)</title>
 		<para>
-		This is the name of an XAVP that the 
+		This is the name of an XAVP that the
 		<function>t_load_contacts()</function> function uses to
                 store contacts of the destination set and that
                 <function>t_next_contacts()</function> function uses to
@@ -771,7 +771,7 @@ modparam("tm", "contacts_avp", "tm_contacts")
 </programlisting>
 		</example>
 	</section>
-	
+
 	<section id="tm.p.contact_flows_avp">
 		<title><varname>contact_flows_avp</varname> (string)</title>
 		<para>
@@ -810,7 +810,7 @@ modparam("tm", "contact_flows_avp", "tm_contact_flows")
 			current transaction.
 		</para>
 		<note><para>
-			The value of the AVP is expected to be expressed in 
+			The value of the AVP is expected to be expressed in
 			<emphasis>seconds</emphasis> and not milliseconds (unlike the rest
 			of the timers).
 		</para></note>
@@ -842,7 +842,7 @@ modparam("tm", "fr_timer_avp", "i:708")
 			</programlisting>
 		</example>
 	</section>
-	
+
 	<section id="tm.p.fr_inv_timer_avp">
 		<title><varname>fr_inv_timer_avp</varname> (string)</title>
 		<para>
@@ -850,8 +850,8 @@ modparam("tm", "fr_timer_avp", "i:708")
 			per-transaction basis. The administrator can provide a value to be
 			used for a particular transaction in an AVP. This parameter
 			contains the name of the AVP that will be checked. If the AVP
-			exists, is non-empty and non-zero then its value will be used 
-			for the fr_inv_timer timer, effectively overriding the value 
+			exists, is non-empty and non-zero then its value will be used
+			for the fr_inv_timer timer, effectively overriding the value
 			configured in <varname>fr_inv_timer</varname> parameter for the
 			current transaction.
 		</para>
@@ -1014,7 +1014,7 @@ modparam("tm", "callid_matching", 1)
 	<section id="tm.p.callid_cseq_matching">
 		<title><varname>callid_cseq_matching</varname> (int)</title>
 		<para>
-			If set to something other than 0, will do transaction matching 
+			If set to something other than 0, will do transaction matching
 			using callid and cseq header values instead of via branch md5 value.
 
 		<emphasis>
@@ -1118,7 +1118,7 @@ modparam("tm", "default_reason", "Unknown reason")
 	<section id="tm.p.disable_6xx_block">
 	<title><varname>disable_6xx_block</varname> (integer)</title>
 	<para>
-		If set the TM module will treat all the 6xx replies like normal replies 
+		If set the TM module will treat all the 6xx replies like normal replies
 		(warning: this would be non-RFC conformant behaviour).
 	</para>
 	<para>
@@ -1178,7 +1178,7 @@ modparam("tm", "disable_6xx_block", 1)
 	</itemizedlist>
 	<note><para>
 	Modes 1 and 2 do not follow RFC 3261, but are useful to deal with some simple UAs
-	behind a NAT (no different routing for the ACK and the contact 
+	behind a NAT (no different routing for the ACK and the contact
 	contains an address behind the NAT).
 	</para></note>
 	<para>
@@ -1199,7 +1199,7 @@ modparam("tm", "local_ack_mode", 1)
 	    </programlisting>
 	</example>
 	</section>
-	
+
 	<section id="tm.p.failure_reply_mode">
 	<title><varname>failure_reply_mode</varname> (integer)</title>
 	<para>
@@ -1261,7 +1261,7 @@ modparam("tm", "failure_reply_mode", 0)
 		to faked replies such as the infamous 408 on branch timeout.
 	</para>
 	<para>
-		Internally, every reply is assigned a priority between 0 (high prio) 
+		Internally, every reply is assigned a priority between 0 (high prio)
 		and 32000 (low prio). With this parameter the priority of fake replies
 		can be adjusted.
 	</para>

src/modules/tm/doc/tm.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" 
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
 	"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 	[ <!ENTITY % local.common.attrib
 	 "xmlns:xi CDATA #FIXED 'http://www.w3.org/2001/XInclude'">