<?xml version="1.0" encoding="UTF-8"?>
<!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'">
	 <!-- Include general documentation entities -->
	 <!ENTITY % docentities SYSTEM "../../../../doc/docbook/entities.xml">
	 %docentities;
	]
>

<section id="tm.parameters" xmlns:xi="http://www.w3.org/2001/XInclude">
    <sectioninfo>
    </sectioninfo>

    <title>Parameters</title>

    <section id="tm.p.fr_timer">
	<title><varname>fr_timer</varname> (integer)</title>
	<para>
	    Timer which hits if no final reply for a request or ACK for a
	    negative INVITE reply arrives (in milliseconds).
	</para>
	<para>
	    Default value is 30000 ms (30 seconds).
	</para>
	<para>
		See also: <function>t_set_fr()</function>,
				<varname>max_noninv_lifetime</varname>.
	</para>
	<example>
	    <title>Set <varname>fr_timer</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "fr_timer", 10000)
...
	    </programlisting>
	</example>
    </section>

    <section id="tmp.p.fr_inv_timer">
	<title><varname>fr_inv_timer</varname> (integer)</title>
	<para>
	    Timer which hits if no final reply for an INVITE arrives after a
	    provisional message was received (in milliseconds).
	</para>
	<para>
	</para>
	<para>
		Note: This timer can be restarted when a provisional response is
		received. For more details see
		<varname>restart_fr_on_each_reply</varname>.
	</para>
	<para>
	    Default value is 120000 ms (120 seconds).
	</para>
	<para>
		See also: <function>t_set_fr()</function>,
				<varname>max_inv_lifetime</varname>.
	</para>
	<example>
	    <title>Set <varname>fr_inv_timer</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "fr_inv_timer", 180000)
...
	    </programlisting>
	</example>
    </section>

	<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
		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_inv_timer</varname> and
		<varname>fr_timer</varname> values.
	</para>
	<para>
		An INVITE transaction will be kept in memory for maximum:
		<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
		<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
		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, ...).
		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
		used (each failed DNS destination can introduce a new branch).
	</para>
	<para>
		The default value is 180000 ms (180 seconds - the rfc3261
		timer C value).
	</para>
	<para>
		See also: <varname>max_noninv_lifetime</varname>,
					<function>t_set_max_lifetime()</function> (allows changing
					<varname>max_inv_lifetime</varname> on a per transaction
					basis),
					<function>t_reset_max_lifetime</function>
					<varname>fr_timer</varname>,
					<varname>wt_timer</varname>,
					<varname>restart_fr_on_each_reply</varname>.
	</para>
	<example>
	    <title>Set <varname>max_inv_lifetime</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "max_inv_lifetime", 150000)
...
	    </programlisting>
	</example>
    </section>

	<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
		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
		non-INVITEs.
	</para>
	<para>
		A non-INVITE transaction will be kept in memory for a maximum of:
		<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
		<varname>max_noninv_lifetime</varname> is per the whole transaction.
		An example when a transaction can live substantially more then its
		<varname>fr_timer</varname> and where
		<varname>max_noninv_lifetime</varname> will help is when DNS failover
		is used (each failed DNS SRV destination can introduce a new branch).
	</para>
	<para>
		The default value is 32000 ms (32 seconds - the RFC3261 timer F value).
	</para>
	<para>
		See also: <varname>max_inv_lifetime</varname>,
					<function>t_set_max_lifetime()</function> (allows changing
					<varname>max_noninv_lifetime</varname> on a per transaction
					basis),
					<function>t_reset_max_lifetime</function>
					<varname>fr_timer</varname>,
					<varname>wt_timer</varname>.
	</para>
	<example>
	    <title>Set <varname>max_noninv_lifetime</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "max_noninv_lifetime", 30000)
...
	    </programlisting>
	</example>
    </section>

    <section id="tm.p.wt_timer">
	<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
	    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
	    finished by a final reply or FR timer--we simplified).
	</para>
	<para>
	    Default value is 5000 ms (5 seconds).
	</para>
	<example>
	    <title>Set <varname>wt_timer</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "wt_timer", 1000)
...
	    </programlisting>
	</example>
    </section>

    <section id="tm.p.retr_timer1">
	<title><varname>retr_timer1</varname> (integer)</title>
	<para>
	    Initial retransmission period (in milliseconds).
	</para>
	<para>
	    Default value is 500 milliseconds.
	</para>
	<example>
	    <title>Set <varname>retr_timer1</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "retr_timer1", 1000)
...
	    </programlisting>
	</example>
    </section>

    <section id="tm.p.retr_timer2">
	<title><varname>retr_timer2</varname> (integer)</title>
	<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
		<varname>retr_timer2</varname>.
	</para>
	<para>
	    Default value is 4000 milliseconds.
	</para>
	<example>
	    <title>Set <varname>retr_timer2</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "retr_timer2", 2000)
...
	    </programlisting>
	</example>
    </section>

    <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
		always replied. If it's not set, the transaction has only one
		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
		 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
		timeout interval for INVITEs is lower or equal than tm's
		<varname>fr_inv_timer</varname>.
	</para>
	<para>
	    Default value is 1 (on).
	</para>
	<example>
	    <title>Set <varname>noisy_ctimer</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "noisy_ctimer", 1)
...
	    </programlisting>
	</example>
    </section>

	<section id="tm.p.restart_fr_on_each_reply">
	<title><varname>restart_fr_on_each_reply</varname> (integer)</title>
	<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
		<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
		(and thus making impossible the implementation of certain services,
		like automatic voicemail after x seconds).
	</para>
	<para>
		Default value is 1 (on).
	</para>
	<para>
		See also: <varname>fr_inv_timer</varname>,
				<varname>max_inv_lifetime</varname>.
	</para>
	<example>
		<title>Set <varname>restart_fr_on_each_reply</varname>
				parameter</title>
		<programlisting>
...
modparam("tm", "restart_fr_on_each_reply", 0)
...
	    </programlisting>
	</example>
	</section>

	<section id="tm.p.auto_inv_100">
	<title><varname>auto_inv_100</varname> (integer)</title>
	<para>
		If set (default) tm will automatically send a 100 reply to INVITEs.
	</para>
	<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
		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.
	</para>
	<para>
		Default value is 1 (on).
	</para>
	<para>
		See also: <function>t_set_auto_inv_100()</function>
				  <varname>auto_inv_100_reason</varname>.
	</para>
	<example>
		<title>Set <varname>auto_inv_100</varname> parameter</title>
		<programlisting>
...
modparam("tm", "auto_inv_100", 0)
...
	    </programlisting>
	</example>
	</section>

	<section id="tm.p.auto_inv_100_reason">
	<title><varname>auto_inv_100_reason</varname> (string)</title>
	<para>
		Set reason text of the automatically sent 100 to an INVITE.
	</para>
	<para>
		Default value is "trying -- your call is important to us".
	</para>
	<para>
		See also: <varname>auto_inv_100</varname>.
	</para>
	<example>
		<title>Set <varname>auto_inv_100_reason</varname> parameter</title>
		<programlisting>
...
modparam("tm", "auto_inv_100_reason", "Trying")
...
	    </programlisting>
	</example>
	</section>

	<section id="tm.p.unix_tx_timeout">
	<title><varname>unix_tx_timeout</varname> (integer)</title>
	<para>
		Unix socket transmission timeout, in milliseconds.
	</para>
	<para>
		If UNIX sockets are used (e.g.: to communicate with sems) and sending
		a message on a UNIX socket takes longer than
		<varname>unix_tx_timeout</varname>, the send will fail.
	</para>
	<para>
	    The default value is 500 milliseconds.
	</para>
	<example>
	    <title>Set <varname>unix_tx_timeout</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "unix_tx_timeout", 250)
...
	    </programlisting>
	</example>
	</section>

        <section id="tm.p.aggregate_challenges">
	<title><varname>aggregate_challenges</varname> (integer)</title>
	<para>
		If set (default) and 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
		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).
	</para>
	<para>
		If disabled (set to 0) only the first 401, or if no 401 was received the first 407,  will
		be forwarded (no header aggregation).
	</para>
	<para>
	    	Default value is 1 (required by RFC 3261).
	</para>
	<example>
	    <title>Set <varname>aggregate_challenges</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "aggregate_challenges", 0)
...
	    </programlisting>
	</example>
    </section>

    <section id="tm.p.reparse_invite">
	<title><varname>reparse_invite</varname> (integer)</title>
	<para>
		If set (default), the CANCEL and negative ACK requests are
		constructed from the INVITE message which was sent out instead
		of building them from the received request. The disadvantage is
		that the outgoing INVITE has to be partially re-parsed, the advantage
		is that the CANCEL/ACK is always RFC 3261-compliant, it always
		contains the same route-set as the INVITE message. Do not disable
		the INVITE re-parsing for example in the following cases:
	</para>
	<para>
		- The INVITE contains a preloaded route-set, and &kamailio; forwards
		the message to the next hop according to the "Route" header. The
		"Route" header is not removed in the CANCEL without
		<varname>reparse_invite</varname>=1.
	</para>
	<para>
		- &kamailio; record-routes, thus an in-dialog INVITE contains a "Route"
		header which is removed during loose routing. If the in-dialog
		INVITE is rejected, the negative ACK still contains the "Route"
		header without <varname>reparse_invite</varname>=1.
	</para>
	<para>
	    Default value is 1.
	</para>
	<example>
	    <title>Set <varname>reparse_invite</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "reparse_invite", 0)
...
	    </programlisting>
	</example>
    </section>

    <section id="tm.p.ac_extra_hdrs">
	<title><varname>ac_extra_hdrs</varname> (string)</title>
	<para>
		Header fields prefixed by this parameter value are included
		in the CANCEL and negative ACK messages if they were present
		in the outgoing INVITE.
	</para>
	<para>
		Note, that the parameter value effects only those headers
		which are not covered by RFC 3261 (which are neither mandatory
		nor prohibited in CANCEL and ACK), and the parameter can be used
		only together with <varname>reparse_invite</varname>=1.
	</para>
	<para>
	    	Default value is "".
	</para>
	<example>
	    <title>Set <varname>ac_extra_hdrs</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "ac_extra_hdrs", "myfavoriteheaders-")
...
	    </programlisting>
	</example>
    </section>

    <section id="tm.p.blst_503">
	<title><varname>blst_503</varname> (integer)</title>
	<para>
		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
		<varname>blst_503_max_timeout</varname>.
	</para>
	<para>
		<emphasis>WARNING:</emphasis>blindly allowing 503 blocklisting could
		be very easily exploited for DOS attacks in most network setups.
	</para>
	<para>
		The default value is 0 (disabled due to the reasons above).
	</para>
	<example>
	    <title>Set <varname>blst_503</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "blst_503", 1)
...
	    </programlisting>
	</example>
    </section>

    <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
		<varname>blst_503_max_timeout</varname>.
	</para>
	<para>
		The default value is 0, which means that if no "Retry-After" header is
		present, the 503 reply source will not be blocklisted (RFC 3261 conformant
		 behaviour).
	</para>
	<example>
	    <title>Set <varname>blst_503_def_timeout</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "blst_503_def_timeout", 120)
...
	    </programlisting>
	</example>
    </section>

    <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
		smaller than this value.
	</para>
	<para>
		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
	</para>
	<example>
	    <title>Set <varname>blst_503_min_timeout</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "blst_503_min_timeout", 30)
...
	    </programlisting>
	</example>
    </section>

    <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
		greater than this limit.
	</para>
	<para>
		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
	</para>
	<example>
	    <title>Set <varname>blst_503_max_timeout</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "blst_503_max_timeout", 604800)
...
	    </programlisting>
	</example>
    </section>

    <section id="tm.p.blst_methods_add">
	<title><varname>blst_methods_add</varname> (unsigned integer)</title>
	<para>
		Bitmap of method types that trigger blocklisting on
		transaction timeouts. (This setting has no
		effect on blocklisting because of send failures.)
	</para>
	<para>
		The following values are associated to the request methods:
		INVITE=1, CANCEL=2, ACK=4 (not retransmitted, thus, never
		times-out), BYE=8, INFO=16, REGISTER=32, SUBSCRIBE=64,
		NOTIFY=126, OTHER=256 (all the unknown types).
		Check parser/msg_parser.h for farther details.
	</para>
	<para>
		Change the value carefully, because requests that don't get
		a provisional response (everything but INVITE) can easily
		cause the next hop to be inserted into the blocklist
		by mistake. For example the next hop is a proxy, it is alive,
		but waiting for the response of the UAS, and has higher
		fr_timer value.
	</para>
	<para>
		The default value is 1, only INVITEs trigger blocklisting
	</para>
	<example>
	    <title>Set <varname>blst_methods_add</varname> parameter</title>
	    <programlisting>
...
# INVITEs and REGISTERs trigger blocklisting
modparam("tm", "blst_methods_add", 33)
...
	    </programlisting>
	</example>
    </section>

    <section id="tm.p.blst_methods_lookup">
	<title><varname>blst_methods_lookup</varname> (unsigned integer)</title>
	<para>
		Bitmap of method types that are looked-up in the blocklist
		before being forwarded statefully.
		See also <varname>blst_methods_add</varname>
	</para>
	<para>
		The default value is 4294967287, every method type except BYE.
		(We try to deliver BYEs no matter what)
	</para>
	<example>
	    <title>Set <varname>blst_methods_lookup</varname> parameter</title>
	    <programlisting>
...
# lookup only INVITEs
modparam("tm", "blst_methods_lookup", 1)
...
	    </programlisting>
	</example>
    </section>

    <section id="tm.p.cancel_b_method">
	<title><varname>cancel_b_method</varname> (integer)</title>
	<para>
		Method used when attempting to CANCEL an unreplied transaction branch
		(a branch where no response was received).
		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
		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
		 487. Moreover this risk is greatly amplified by packet loss
		(e.g. if an 180 is lost the branch will look as unreplied and
		 a CANCEL will silently drop the branch, but a 2xx can still come at
		 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
		unreplied branches. If a provisional answer is received a CANCEL
		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
		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
		conforming (the RFC allows sending CANCELs only on pending branches).
	</para>
	<para>
		The default value is 1.
	</para>
	<example>
	    <title>Set <varname>cancel_b_method</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "cancel_b_method", 1)
...
	    </programlisting>
	</example>
    </section>

    <section id="tm.p.reparse_on_dns_failover">
	<title><varname>reparse_on_dns_failover</varname> (integer)</title>
	<para>
		If set to 1, the SIP message after a DNS failover is constructed
		from the outgoing message buffer of the failed branch instead of
		from the received request.
	</para>
	<para>
		It must be set if multiple branches are installed, the SIP message is
		modified differently in them, and at least one of them can result
		in DNS failover. If the parameter is not set the per-branch modifications
		are lost after the failover.
	</para>
	<para>
		Note: If the parameter is set, branch route block and TMCB_REQUEST_FWDED
		callback are not called in case of the failover.
	</para>
	<para>
		Disadvantage: only the via header is replaced in the message buffer, so
		the outgoing socket address is not corrected in any other part of the message.
		It is dangerous on multihomed hosts: when the new SIP request after
		the DNS failover is sent via different interface than the first request,
		the message can contain incorrect IP address in the Record-Route header.
	</para>
	<para>
		Default value is 1.
	</para>
	<example>
	    <title>Set <varname>reparse_on_dns_failover</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "reparse_on_dns_failover", 0)
...
	    </programlisting>
	</example>
    </section>

    <section id="tm.p.on_sl_reply">
	<title><varname>on_sl_reply</varname> (string)</title>
	<para>
		Sets reply route block, to which control is passed when a
		reply is received that has no associated transaction.
		The reply is passed to the core for stateless forwarding after
		the route block execution unless drop is executed (or it returns 0).
	</para>
	<para>
		If KEMI is used, the parameter has to be the KEMI function name, which
		receives a string parameter with the event name, respectively "on_sl_reply".
	</para>
	<example>
	    <title>Set <varname>on_sl_reply</varname> parameter</title>
	    <programlisting>
...
modparam("tm", "on_sl_reply", "stateless_replies")
...

onreply_route["stateless_replies"] {
	# do not allow stateless replies to be forwarded
	return 0;
}
	    </programlisting>
	</example>
	<example>
	    <title>Set <varname>on_sl_reply</varname> parameter (KEMI javascript)</title>
	    <programlisting>
...
modparam("tm", "on_sl_reply", "ksr_slreply")
...
-- event callback function implemented in javascript
function ksr_slreply(evname) {
	# the evname is set to "on_sl_reply"
	# do not allow stateless replies to be forwarded
	KSR.x.drop();
}
	    </programlisting>
	</example>
    </section>

	<section id ="tm.p.contacts_avp">
		<title><varname>contacts_avp</varname> (string)</title>
		<para>
		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
                restore those contacts.
		</para>
		<para>
		<emphasis>
			Default value is "NULL"
			(t_load_contacts()/t_next_contacts() functions
			are disabled).
		</emphasis>
		</para>
		<example>
		<title>Set <varname>contacts_avp</varname> parameter</title>
		<programlisting format="linespecific">
...
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>
		This is the name of an XAVP
                that the <function>t_next_contacts()</function> function uses to
                store contacts (if any) that it skipped, because they
		contained same +sip.instance value than some other contact,
                and that <function>t_next_contact_flows()</function>
		function uses to restore those contacts.
		</para>
		<para>
		<emphasis>
			Default value is "NULL".  This parameter MUST be
			set if variable contacts_avp is set.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>contact_flows_avp</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("tm", "contact_flows_avp", "tm_contact_flows")
...
</programlisting>
		</example>
	</section>

	<section id="tm.p.fr_timer_avp" >
		<title><varname>fr_timer_avp</varname> (string)</title>
		<para>
			The value of fr_timer timer can be overriden on 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 then its value
			will be used for the fr_timer timer, effectively overriding the
			value configured in <varname>fr_timer</varname> parameter for the
			current transaction.
		</para>
		<note><para>
			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>
		<para>
			This parameter is kept for backwards compatibility (hence its
			value expressed in seconds instead of milliseconds and its arcane
			way of specifying the avps). The recommended replacement is using
			<function>t_set_fr()</function> on a per transaction basis.
		</para>
		<para>
			See also: <function>t_set_fr()</function>,
			<varname>fr_timer</varname>.
		</para>
		<para>
			In Kamailio compatibility mode (defined by #!KAMAILIO), the value
			of the parameter must be the name of an AVP in pseudo-variable
			format: $avp(name). In SER compatibility mode it must be just
			AVP name.
		</para>
		<example>
			<title>Set <varname>fr_timer_avp</varname> parameter</title>
			<programlisting>
...
# Kamailio mode
modparam("tm", "fr_timer_avp", "$avp(i:708)")
# Old SER mode
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>
			The value of fr_inv_timer timer can be overriden on
			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
			configured in <varname>fr_inv_timer</varname> parameter for the
			current transaction.
		</para>
		<note><para>
			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>
		<para>
			This parameter is kept for backwards compatibility (hence its
			value expressed in seconds instead of milliseconds and its arcane
			way of specifying the avps). The recommended replacement is using
			<function>t_set_fr()</function> on a per transaction basis.
		</para>
		<para>
			See also: <function>t_set_fr()</function>,
			<varname>fr_inv_timer</varname>.
		</para>
		<para>
			In Kamailio compatibility mode (defined by #!KAMAILIO), the value
			of the parameter must be the name of an AVP in pseudo-variable
			format: $avp(name). In SER compatibility mode it must by just
			AVP name.
		</para>
		<example>
			<title>Set <varname>fr_inv_timer_avp</varname> parameter</title>
			<programlisting>
...
# Kamailio mode
modparam("tm", "fr_inv_timer_avp", "$avp(my_fr_inv_timer)")
# Old SER mode
modparam("tm", "fr_inv_timer_avp", "my_fr_inv_timer")
...
			</programlisting>
		</example>
	</section>

	<section id="tm.p.unmatched_cancel">
		<title><varname>unmatched_cancel</varname> (integer)</title>
		<para>
			This parameter selects between forwarding CANCELs
			that do not match any transaction statefully (0,
			default value), statelessly (1) or dropping them
			(2). Note that the stateful forwarding has an
			additional hidden advantage: the tm module will be able to
			recognize INVITEs that arrive after their CANCEL.
			Note also that this feature could be used to try
			a memory exhaustion DOS attack against a proxy that
			authenticates all requests, by continuously flooding
			the victim with CANCELs to random destinations
			(since the CANCEL cannot be authenticated, each
			received bogus CANCEL will create a new transaction
			that will live by default 30s).
		</para>
		<para>
			Default value is 0.
		</para>
		<example>
			<title>Set <varname>unmatched_cancel</varname> parameter</title>
			<programlisting>
...
modparam("tm", "unmatched_cancel", 2)
...
			</programlisting>
		</example>
	</section>

	<section id="tm.p.ruri_matching">
	<title><varname>ruri_matching</varname> (integer)</title>
	<para>
		If set the TM module will try to match the request URI when doing
		SIP 1.0 (pre-RFC 3261) transaction matching (the "Via" header branch parameter does
		not contain the 3261 cookie).
	</para>
	<para>
		The only reason to have it not set is for interoperability with old,
		broken implementations.
	</para>
	<para>
		Default value is 1 (on).
	</para>
	<para>
		Can be set at runtime, e.g.:
		<programlisting>
	$ &sercmd; cfg.set_now_int tm ruri_matching 0
		</programlisting>
	</para>
	<example>
		<title>Set <varname>ruri_matching</varname> parameter</title>
		<programlisting>
...
modparam("tm", "ruri_matching", 1)
...
	    </programlisting>
	</example>
	</section>

	<section id="tm.p.via1_matching">
	<title><varname>via1_matching</varname> (integer)</title>
	<para>
		If set the TM module will try to match the topmost "Via" header when doing
		SIP 1.0 (pre-RFC 3261) transaction matching (the "Via" header branch parameter does
		not contain the 3261 cookie).
	</para>
	<para>
		The only reason to have it not set is for interoperability with old,
		broken implementations.
	</para>
	<para>
		Default value is 1 (on).
	</para>
	<para>
		Can be set at runtime, e.g.:
		<programlisting>
	$ &sercmd; cfg.set_now_int tm via1_matching 0
		</programlisting>
	</para>
	<example>
		<title>Set <varname>via1_matching</varname> parameter</title>
		<programlisting>
...
modparam("tm", "via1_matching", 1)
...
	    </programlisting>
	</example>
	</section>

	<section id="tm.p.callid_matching">
	<title><varname>callid_matching</varname> (integer)</title>
	<para>
		If set the TM module will try to match the callid when doing
		transaction matching.
	</para>
	<para>
		Turn on if you don't want replies/requests from broken clients who
		send a mangled Call-ID to match the transaction. For example when
		the other side won't recognise the response anyway because of a changed
		Call-ID, this setting will prevent accounting records to be created
		or failure_route to be skipped.
	</para>
	<para>
		Default value is 0 (off).
	</para>
	<para>
		Can be set at runtime, e.g.:
		<programlisting>
	$ &sercmd; cfg.set_now_int tm callid_matching 0
		</programlisting>
	</para>
	<example>
		<title>Set <varname>callid_matching</varname> parameter</title>
		<programlisting>
...
modparam("tm", "callid_matching", 1)
...
	    </programlisting>
	</example>
	</section>

	<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
			using callid and cseq header values instead of via branch md5 value.

		<emphasis>
			Note that this behavior is non-RFC conpliant!
		</emphasis>
		</para>
		<para>
		<emphasis>
			Default value is 0.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>callid_cseq_matching</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("tm", "callid_cseq_matching", 0)
...

kamcmd cfg.set_now_int tm callid_cseq_matching 1
		</programlisting>
		</example>
	</section>

	<section id="tm.p.pass_provisional_replies">
	<title><varname>pass_provisional_replies</varname> (integer)</title>
	<para>
		If set, TMCB_LOCAL_RESPONSE_OUT tm registered callbacks will be called
		also for provisional replies.
	</para>
	<para>
		Default value is 0 (off).
	</para>
	<para>
		Can be set at runtime, e.g.:
		<programlisting>
	$ &sercmd; cfg.set_now_int tm pass_provisional_replies 1
		</programlisting>
	</para>
	<example>
		<title>Set <varname>pass_provisional_replies</varname> parameter
		</title>
		<programlisting>
...
modparam("tm", "pass_provisional_replies", 1)
...
	    </programlisting>
	</example>
	</section>

	<section id="tm.p.default_code">
	<title><varname>default_code</varname> (integer)</title>
	<para>
		Default response code sent by <function>t_reply()</function> if it
		cannot retrieve its parameters (e.g. inexistent avp).
		Valid values are between 400 and 699.
	</para>
	<para>
		Default value is 500.
	</para>
	<para>
		Can be set at runtime, e.g.:
		<programlisting>
	$ &sercmd; cfg.set_now_int tm default_code 505
		</programlisting>
	</para>
	<example>
		<title>Set <varname>default_code</varname> parameter </title>
		<programlisting>
...
modparam("tm", "default_code", 501)
...
	    </programlisting>
	</example>
	</section>

	<section id="tm.p.default_reason">
	<title><varname>default_reason</varname> (string)</title>
	<para>
		Default SIP reason phrase sent by <function>t_reply()</function> if it
		cannot retrieve its parameters (e.g. inexistent avp).
	</para>
	<para>
		Default value is "Server Internal Error".
	</para>
	<para>
		Can be set at runtime, e.g.:
		<programlisting>
	$ &sercmd; cfg.set_now_string tm default_reason "Unknown error"
		</programlisting>
	</para>
	<example>
		<title>Set <varname>default_reason</varname> parameter </title>
		<programlisting>
...
modparam("tm", "default_reason", "Unknown reason")
...
	    </programlisting>
	</example>
	</section>

	<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
		(warning: this would be non-RFC conformant behaviour).
	</para>
	<para>
		If not set (default) receiving a 6xx will cancel all the running
		parallel branches, will stop DNS failover and forking. However
		serial forking using <function>append_branch()</function> in the
		<function>failure_route</function> will still work.
	</para>
	<para>
		It can be overwritten on a per transaction basis using
		<function>t_set_disable_6xx()</function>.
	</para>
	<para>
		Default value is 0 (off, rfc conformant behaviour).
	</para>
	<para>
		Can be set at runtime, e.g.:
		<programlisting>
	$ &sercmd; cfg.set_now_int tm disable_6xx_block 0
		</programlisting>
	</para>
	<para>
		See also: <function>t_set_disable_6xx()</function>.
	</para>
	<example>
		<title>Set <varname>disable_6xx_block</varname> parameter</title>
		<programlisting>
...
modparam("tm", "disable_6xx_block", 1)
...
	    </programlisting>
	</example>
	</section>

	<section id="tm.p.local_ack_mode">
	<title><varname>local_ack_mode</varname> (integer)</title>
	<para>
		This setting controls where locally generated ACKs for 2xx replies to local
		transactions (transactions created via <function>t_uac*()</function>
		either through the TM api or via RPC/mi/fifo) are sent.
	</para>
	<para> It has 3 possible values:</para>
	<itemizedlist>
		<listitem><para>
		<emphasis>0</emphasis> - the ACK destination is choosen according to
		the RFC: the next hop is found using the contact and the route set and
		then DNS resolution is used on it.
		</para></listitem>
		<listitem><para>
		<emphasis>1</emphasis> - the ACK is sent to the same address as the
		corresponding INVITE branch.
		</para></listitem>
		<listitem><para>
		<emphasis>2</emphasis> - the ACK is sent to the source of the 2xx
		reply.
		</para></listitem>
	</itemizedlist>
	<note><para>
	Mode 1 and 2 does 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
	contains an address behind the NAT).
	</para></note>
	<para>
		The default value is 0 (RFC conformant behaviour).
	</para>
	<para>
		Can be set at runtime, e.g.:
		<programlisting>
	$ &sercmd; cfg.set_now_int tm local_ack_mode 0
		</programlisting>
	</para>
	<example>
		<title>Set <varname>local_ack_mode</varname> parameter</title>
		<programlisting>
...
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>
		This parameter controls how branches are managed and replies are selected for
		failure_route handling: keep all, drop all, drop last branches in
		SIP serial forking handling.
	</para>
	<para>
		To control per transaction see <function>t_drop_replies()</function>.
	</para>
	<para> It has 4 possible values:</para>
	<itemizedlist>
		<listitem><para>
		<emphasis>0</emphasis> - all branches are kept, no matter a new leg of
		serial forking has been started. Beware that if the new leg fails, you
		may get in failure_route a reply code from a branch of previous serial
		forking legs (e.g., if in first leg you got a 3xx, then you handled
		the redirection in failure route, sent to a new destination and this
		one timeout, you will get again the 3xx). Use t_drop_replies() on per
		transaction fashion to control the behavior you want. It is the
		default behaviour coming from SER 2.1.x.
		</para></listitem>
		<listitem><para>
		<emphasis>1</emphasis> - all branches are discarded by default. You
		can still overwrite the behaviour via t_drop_replies()
		</para></listitem>
		<listitem><para>
		<emphasis>2</emphasis> - by default only the branches of previous leg
		of serial forking are discarded
		</para></listitem>
		<listitem><para>
		<emphasis>3</emphasis> - all previous branches are discarded if there
		is a new serial forking leg. This is the default behaviour coming from
		Kamailio 1.5.x. Use this mode if you don't want to handle in a per
		transaction fashion with t_drop_replies(). It ensures that you will
		get the winning reply from the branches of last serial forking step
		(e.g., if in first step you get 3xx, then you forward to a new
		destination, you will get in failure_route the reply coming from that
		destination or a local timeout).
		</para></listitem>
	</itemizedlist>
	<para>
		The default value is 3.
	</para>
	<example>
		<title>Set <varname>failure_reply_mode</varname> parameter</title>
		<programlisting>
...
modparam("tm", "failure_reply_mode", 0)
...
	    </programlisting>
	</example>
	</section>

	<section id="faked_reply_prio">
	<title><varname>faked_reply_prio</varname> (integer)</title>
	<para>
		It controls how branch selection is done. It allows to give a penalty
		to faked replies such as the infamous 408 on branch timeout.
	</para>
	<para>
		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>
	<itemizedlist>
		<listitem><para>
		<emphasis>0</emphasis> - disabled (default)
		</para></listitem>
		<listitem><para>
		<emphasis>&lt; 0</emphasis> - priority is increased by given amount.
		</para></listitem>
		<listitem><para>
		<emphasis>&gt; 0</emphasis> - priority is decreased by given amount.
		Do not make it higer than 10000 or faked replies will even loose
		from 1xx clsss replies.
		</para></listitem>
	</itemizedlist>
	<para>
		The default value is 0.
	</para>
	<para>
		To let received replies win from a locally generated 408, set this
		value to 2000.
	</para>
	<example>
		<title>Set <varname>faked_reply_prio</varname> parameter</title>
		<programlisting>
...
modparam("tm", "faked_reply_prio", 2000)
...
	    </programlisting>
	</example>
	</section>

	<section id="local_cancel_reason">
		<title><varname>local_cancel_reason</varname> (boolean)</title>
		<para>
			Enables/disables adding reason headers (RFC 3326) for CANCELs
			generated due to receiving a final reply. The reason header added
			will look like: "Reason: SIP;cause=&lt;final_reply_code&gt;".
		</para>
		<para>
			Default value is 1 (enabled).
		</para>
		<para>
			Can be set at runtime, e.g.:
			<programlisting>
	$ &sercmd; cfg.set_now_int tm local_cancel_reason 0
			</programlisting>
		</para>
		<para>
			See also: <varname>e2e_cancel_reason</varname>.
		</para>
		<example>
			<title>Set <varname>local_cancel_reason</varname> parameter</title>
			<programlisting>
...
modparam("tm", "local_cancel_reason", 0)
...
			</programlisting>
		</example>
	</section>


	<section id="e2e_cancel_reason">
		<title><varname>e2e_cancel_reason</varname> (boolean)</title>
		<para>
			Enables/disables adding reason headers (RFC 3326) for CANCELs
			generated due to a received CANCEL.  If enabled the reason headers
			from received CANCELs will be copied into the generated hop-by-hop
			CANCELs.
		</para>
		<para>
			Default value is 1 (enabled).
		</para>
		<para>
			Can be changed at runtime, e.g.:
			<programlisting>
	$ &sercmd; cfg.set_now_int tm e2e_cancel_reason 0
			</programlisting>
		</para>
		<para>
			See also: <function>t_set_no_e2e_cancel_reason()</function> and
						<varname>local_cancel_reason</varname>.
		</para>
		<example>
			<title>Set <varname>e2e_cancel_reason</varname> parameter</title>
			<programlisting>
...
modparam("tm", "e2e_cancel_reason", 0)
...
			</programlisting>
		</example>
	</section>

	<section id="remap_503_500">
		<title><varname>remap_503_500</varname> (boolean)</title>
		<para>
			Enables/disables conversion of 503 response code to 500. By default
			it is enabled, based on the SIP RFC requirement. This is global
			setting for all received replies handled by TM. To do it per
			transaction basis, let this option disabled, set a failure route
			and then do t_reply("500", "...") inside it.
		</para>
		<para>
			Default value is 1 (enabled).
		</para>
		<example>
			<title>Set <varname>remap_503_500</varname> parameter</title>
			<programlisting>
...
modparam("tm", "remap_503_500", 0)
...
			</programlisting>
		</example>
	</section>

	<section id="tm.p.failure_exec_mode">
		<title><varname>failure_exec_mode</varname> (boolean)</title>
		<para>
			Add local failed branches in timer to be considered for failure
			routing blocks. If disabled, relay functions will return false
			in case the branch could not be forwarded (default behaviour
			before v4.1.0).
		</para>
		<para>
			Default value is 0 (disabled).
		</para>
		<example>
			<title>Set <varname>failure_exec_mode</varname> parameter</title>
			<programlisting>
...
modparam("tm", "failure_exec_mode", 1)
...
			</programlisting>
		</example>
	</section>


	<section id="tm.p.dns_reuse_rcv_socket">
		<title><varname>dns_reuse_rcv_socket</varname> (boolean)</title>
		<para>
			Control reuse of the receive socket for additional branches added
			by <acronym>DNS</acronym> failover. If set to 1, the receive socket is used for
			sending out the new branches, unless the socket is forced
			explicitely in configuration file. If set to 0, selected socket
			is done depending on value of global parameter "mhomed" (if mhomed=0,
			then the first listen socket is used, otherwise the socket is
			selected based on routing rules).
		</para>
		<para>
			Do enable it with caution, it might create troubles on DNS results
			with different transport layer. Better let it be disabled and enable
			"mhomed".
		</para>
		<para>
			Default value is 0 (disabled).
		</para>
		<example>
			<title>Set <varname>dns_reuse_rcv_socket</varname> parameter</title>
			<programlisting>
...
modparam("tm", "dns_reuse_rcv_socket", 1)
...
			</programlisting>
		</example>
	</section>

	<section id="tm.p.xavp_contact">
		<title><varname>xavp_contact</varname> (string)</title>
		<para>
		The name of XAVP storing the attributes per contact. This must be the same as
		the usrloc parameter <varname>xavp_contact</varname>.
		</para>
		<para>
		<emphasis>
			Default value is <quote>NULL</quote>.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>xavp_contact</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("tm|usrloc", "xavp_contact", "ulattrs")
...
</programlisting>
		</example>
	</section>

	<section id="tm.p.event_callback">
		<title><varname>event_callback</varname> (str)</title>
		<para>
			The name of the function in the kemi configuration file (embedded
			scripting language such as Lua, Python, ...) to be executed instead
			of event_route[tm:local-request] block. The function receives
			a string parameter with the name of the event, respectively
			"tm:local-request".
		</para>
		<para>
		<emphasis>
			Default value is 'empty' (no function is executed for events).
		</emphasis>
		</para>
		<example>
		<title>Set <varname>event_callback</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("tm", "event_callback", "ksr_tm_event")
...
-- event callback function implemented in Lua
function ksr_tm_event(evname)
	KSR.info("===== tm module triggered event: " .. evname .. "\n");
	return 1;
end
...
</programlisting>
		</example>
	</section>

	<section id="tm.p.event_callback_lres_sent">
		<title><varname>event_callback_lres_sent</varname> (str)</title>
		<para>
			The name of the function in the kemi configuration file (embedded
			scripting language such as Lua, Python, ...) to be executed instead
			of event_route[tm:local-response] block. The function receives
			a string parameter with the name of the event, respectively
			"tm:local-response".
		</para>
		<para>
		<emphasis>
			Default value is 'empty' (no function is executed for events).
		</emphasis>
		</para>
		<example>
		<title>Set <varname>event_callback_lres_sent</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("tm", "event_callback_lres_sent", "ksr_tm_event_response_sent")
...
-- event callback function implemented in Lua
function ksr_tm_event_response_sent(evname)
	KSR.info("===== tm module triggered event: " .. evname .. "\n");
	return 1;
end
...
</programlisting>
		</example>
	</section>

	<section id="tm.p.relay_100">
		<title><varname>relay_100</varname> (str)</title>
		<para>
			This parameter controls whether or not a SIP 100 response is proxied.
			Note that this is not valid behavior when operating in stateful mode
			per RFC 3261 Section 21.1.1, and therefore is useful only when
			operating as a stateless proxy.
			When using this feature, it is possible to control which 100 responses
			are proxied and which are not by detecting whether they are part of
			an existing transaction and setting up the appropriate logic in
			onreply_route.
		</para>
		<para>
		<emphasis>
			Default value is 0 (disabled).
		</emphasis>
		</para>
		<example>
		<title>Set <varname>relay_100</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("tm", "relay_100", 1)
...
</programlisting>
		</example>
	</section>

	<section id="tm.p.rich_redirect">
		<title><varname>rich_redirect</varname> (int)</title>
		<para>
			When sending a 3xx class reply, include additional branch info
			to the contacts such as path vector and branch flags.
		</para>
		<itemizedlist>
			<listitem><para>
			<emphasis>0</emphasis> - no extra info is added (default)
			</para></listitem>
			<listitem><para>
			<emphasis>1</emphasis> - include branch flags as contact header parameter
			</para></listitem>
			<listitem><para>
			<emphasis>2</emphasis> - include path as contact uri Route header
			</para></listitem>
		</itemizedlist>
		<para>
		Values may be combined (added).
		</para>
		<example>
			<title>rich_redirect example</title>
			<programlisting>
...
modparam("tm", "rich_redirect", 3)
....
			</programlisting>
		</example>
	</section>

	<section id="tm.p.exec_time_check">
		<title><varname>exec_time_check</varname> (int)</title>
		<para>
			Duration in milliseconds for executing transaction failure callbacks
			and failure_route block after which to do a safety check if
			transaction is still active.
		</para>
		<para>
			Set it to 0 in order to disable this check.
		</para>
		<para>
		<emphasis>
			Default value is 5000 (5 seconds).
		</emphasis>
		</para>
		<example>
		<title>Set <varname>exec_time_check</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("tm", "exec_time_check", 0)
...
</programlisting>
		</example>
	</section>

	<section id="tm.p.reply_relay_mode">
		<title><varname>reply_relay_mode</varname> (int)</title>
		<para>
			If set to 1, a received 200 OK response that was suspeneded is no
			longer forwarded in the transactional context if another final
			response was forward while 200 OK was suspended. Forwarding the 200 OK,
			even it was received first, results in overwritting the transaction
			response buffer that can impact matching of incoming ACKs.
		</para>
		<para>
			Set it to 0 in order to disable this behaviour and attempt to forward
			suspended 200 OK in the transaction context. This was the behaviour
			before the commit 18410da0.
		</para>
		<para>
		<emphasis>
			Default value is 1.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>reply_relay_mode</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("tm", "reply_relay_mode", 0)
...
</programlisting>
		</example>
	</section>

	<section id="tm.p.enable_uac_fr">
		<title><varname>enable_uac_fr</varname> (int)</title>
		<para>
			Enable failure route trigger, for uac. This will copy the tm uac into uas.
			Thus, failure route can be triggered even for uac messages.
		</para>
		<example>
			<title>enable_uac_fr example</title>
			<programlisting>
...
modparam("tm", "enable_uac_fr", 1)
....
			</programlisting>
		</example>
	</section>

	<section id="tm.p.failover_reply_codes">
		<title><varname>failover_reply_codes</varname> (string)</title>
		<para>
			This parameter defines the response codes (only codes >= 300 and class >= 3), which enable
			dns failover  to continue to try next ips when previous one fail. It is a list separated by
			colons, where you may define either a single code (e.g. "code=408" would accept 408 as an
			additional response code) or a class of responses, you want to accept (e.g. "class=3" would accept
			everything from 300 to 999 as valid response).
			(with default behaviour only 503 code or no response from previous one will try next ip).
		</para>
		<para>
		<emphasis>
			Default value is <quote></quote>
		</emphasis>
		</para>
		<example>
		<title>Set the <quote>failover_reply_codes</quote> parameter</title>
<programlisting format="linespecific">
...
modparam("tm", "failover_reply_codes", "code=403;code=488;class=5")
...
</programlisting>
		</example>
	</section>

</section>
