Parameters
<varname>fr_timer</varname> (integer)
Timer which hits if no final reply for a request or ACK for a
negative INVITE reply arrives (in milliseconds).
Default value is 30000 ms (30 seconds).
See also: t_set_fr(),
max_noninv_lifetime.
Set <varname>fr_timer</varname> parameter
...
modparam("tm", "fr_timer", 10000)
...
<varname>fr_inv_timer</varname> (integer)
Timer which hits if no final reply for an INVITE arrives after a
provisional message was received (in milliseconds).
Note: this timer can be restarted when a provisional response is
received. For more details see
restart_fr_on_each_reply.
Default value is 120000 ms (120 seconds).
See also: t_set_fr(),
max_inv_lifetime.
Set <varname>fr_inv_timer</varname> parameter
...
modparam("tm", "fr_inv_timer", 180000)
...
<varname>max_inv_lifetime</varname> (integer)
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 fr_inv_timer and
fr_timer values.
An INVITE transaction will be kept in memory for maximum:
max_inv_lifetime+fr_timer(from
the ack to the final reply wait)+wt_timer.
The main difference between this timer and
fr_inv_timer is that the
fr_inv_timer is per branch, while
max_inv_lifetime is per the whole transaction.
Even on a per branch basis fr_inv_timer could be
restarted. For example, by default if
restart_fr_on_each_reply is not cleared, the
fr_inv_timer will be restarted for each received
provisional reply. Even if restart_fr_on_each_reply
is not set the fr_inv_timer will still be restarted
for each increasing reply (e.g. 180, 181, 182, ...).
Another example when a transaction can live substantially more then its
fr_inv_timer and where
max_inv_lifetime will help is when dns failover is
used (each failed dns destination can introduce a new branch).
The default value is 180000 ms (180 seconds - the rfc3261
timer C value).
See also: max_noninv_lifetime,
t_set_max_lifetime() (allows changing
max_inv_lifetime on a per transaction
basis),
t_reset_max_lifetime
fr_timer,
wt_timer,
restart_fr_on_each_reply.
Set <varname>max_inv_lifetime</varname> parameter
...
modparam("tm", "max_inv_lifetime", 150000)
...
<varname>max_noninv_lifetime</varname> (integer)
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 fr_timer value.
It's the same as max_inv_lifetime, but for
non-INVITEs.
A non-INVITE transaction will be kept in memory for maximum:
max_noninv_lifetime+wt_timer.
The main difference between this timer and
fr_timer is that the
fr_timer is per branch, while
max_noninv_lifetime is per the whole transaction.
An example when a transaction can live substantially more then its
fr_timer and where
max_noninv_lifetime will help is when dns failover
is used (each failed dns destination can introduce a new branch).
The default value is 32000 ms (32 seconds - the rfc3261 timer F value).
See also: max_inv_lifetime,
t_set_max_lifetime() (allows changing
max_noninv_lifetime on a per transaction
basis),
t_reset_max_lifetime
fr_timer,
wt_timer.
Set <varname>max_noninv_lifetime</varname> parameter
...
modparam("tm", "max_inv_lifetime", 30000)
...
<varname>wt_timer</varname> (integer)
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 cancels 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).
Default value is 5000 ms (5 seconds).
Set <varname>wt_timer</varname> parameter
...
modparam("tm", "wt_timer", 1000)
...
<varname>delete_timer</varname> (integer)
Time after which a to-be-deleted transaction currently ref-ed by a
process will be tried to be deleted again (in milliseconds).
Note: this parameter is obsolete for ser 2.1 (in 2.1 the transaction
is deleted the moment it's not referenced anymore).
Default value is 200 milliseconds.
Set <varname>delete_timer</varname> parameter
...
modparam("tm", "delete_timer", 100)
...
<varname>retr_timer1</varname> (integer)
Initial retransmission period (in milliseconds).
Default value is 500 milliseconds.
Set <varname>retr_timer1</varname> parameter
...
modparam("tm", "retr_timer1", 1000)
...
<varname>retr_timer2</varname> (integer)
Maximum retransmission period (in milliseconds). The retransmission
interval starts with retr_timer1 and increases until
it reaches this value. After this it stays constant at
retr_timer2.
Default value is 4000 milliseconds.
Set <varname>retr_timer2</varname> parameter
...
modparam("tm", "retr_timer2", 2000)
...
<varname>noisy_ctimer</varname> (integer)
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 acc 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
fr_inv_timer.
Default value is 1 (on).
Set <varname>noisy_ctimer</varname> parameter
...
modparam("tm", "noisy_ctimer", 1)
...
<varname>restart_fr_on_each_reply</varname> (integer)
If set (default), the fr_inv_timer for an INVITE
transaction will be restarted for each provisional reply received
(rfc3261 mandated behaviour). If not set, the
fr_inv_timer will be restarted only for the first
provisional replies and for increasing replies greater or equal 180
(e.g. 180, 181, 182, 185, ...).
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).
Default value is 1 (on).
See also: fr_inv_timer,
max_inv_lifetime.
Set <varname>restart_fr_on_each_reply</varname>
parameter
...
modparam("tm", "restart_fr_on_each_reply", 0)
...
<varname>auto_inv_100</varname> (integer)
If set (default) tm will automatically send and 100 reply to INVITEs.
Setting it to 0 one can be used to enable doing first some tests or
pre-processing on the INVITE and only if some conditions are met
manually send a 100 (using t_reply()). Note
however that in this case all the 100s have to be sent "by hand".
t_set_auto_inv_100() might help to selectively
turn off this feature only for some specific transactions.
Default value is 1 (on).
See also: t_set_auto_inv_100()
auto_inv_100_reason.
Set <varname>auto_inv_100</varname> parameter
...
modparam("tm", "auto_inv_100", 0)
...
<varname>auto_inv_100_reason</varname> (string)
Set reason text of the automatically send 100 to an INVITE.
Default value is "trying -- your call is important to us".
See also: auto_inv_100.
Set <varname>auto_inv_100_reason</varname> parameter
...
modparam("tm", "auto_inv_100_reason", "Trying")
...
<varname>unix_tx_timeout</varname> (integer)
Unix socket transmission timeout, in milliseconds.
If unix sockets are used (e.g.: to communicate with sems) and sending
a message on a unix socket takes longer then
unix_tx_timeout, the send will fail.
The default value is 500 milliseconds.
Set <varname>unix_tx_timeout</varname> parameter
...
modparam("tm", "unix_tx_timeout", 250)
...
<varname>aggregate_challenges</varname> (integer)
If set (default), the final reply is a 401 or a 407 and more then
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 reply. If only one branch received the
winning 401 or 407 then this reply will be forwarded (no new one
will be built).
If 0 only the first 401, or if no 401 was received the first 407, will
be forwarded (no header aggregation).
Default value is 1 (required by rfc3261).
Set <varname>aggregate_challenges</varname> parameter
...
modparam("tm", "aggregate_challenges", 0)
...
<varname>reparse_invite</varname> (integer)
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:
- The INVITE contains a preloaded route-set, and SER forwards
the message to the next hop according to the Route header. The
Route header is not removed in the CANCEL without
reparse_invite=1.
- SER 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 reparse_invite=1.
Default value is 1.
Set <varname>reparse_invite</varname> parameter
...
modparam("tm", "reparse_invite", 0)
...
<varname>blst_503</varname> (integer)
If set and the blacklist support is enabled, every 503 reply source is
added to the blacklist. The initial blacklist timeout (or ttl) depends
on the presence of a Retry-After header in the reply and the values of
the following tm parameters: blst_503_def_timeout,
blst_503_min_timeout and
blst_503_max_timeout.
WARNING:blindly allowing 503 blacklisting could
be very easily exploited for DOS attacks in most network setups.
The default value is 0 (disabled due to the reasons above).
Set <varname>blst_503</varname> parameter
...
modparam("tm", "blst_503", 1)
...
<varname>blst_503_def_timeout</varname> (integer)
Blacklist interval in seconds for a 503 reply with no Retry-After
header.
See also blst_503,
blst_503_min_timeout and
blst_503_max_timeout.
The default value is 0, which means that if no Retry-After header is
present, the 503 reply source will not be blacklisted (rfc conformant
behaviour).
Set <varname>blst_503_def_timeout</varname> parameter
...
modparam("tm", "blst_503_def_timeout", 120)
...
<varname>blst_503_min_timeout</varname> (integer)
Minimum blacklist interval in seconds for a 503 reply with a
Retry-After header. It will be used if the Retry-After value is
smaller.
See also blst_503,
blst_503_def_timeout and
blst_503_max_timeout.
The default value is 0
Set <varname>blst_503_min_timeout</varname> parameter
...
modparam("tm", "blst_503_min_timeout", 30)
...
<varname>blst_503_max_timeout</varname> (integer)
Maximum blacklist interval in seconds for a 503 reply with a
Retry-After header. It will be used if the Retry-After value is
greater.
See also blst_503,
blst_503_def_timeout and
blst_503_min_timeout.
The default value is 3600
Set <varname>blst_503_max_timeout</varname> parameter
...
modparam("tm", "blst_503_max_timeout", 604800)
...
<varname>blst_methods_add</varname> (unsigned integer)
Bitmap of method types that trigger blacklisting on
transaction timeouts. (This setting has no
effect on blacklisting because of send failures.)
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.
Change the value carefully, because requests not having
provisional response (everything but INVITE) can easily
cause the next hop to be inserted into the blacklist
by mistake. For exmaple the next hop is a proxy, it is alive,
but waiting for the response of the UAS, and has higher
fr_timer value.
The default value is 1, only INVITEs trigger blacklisting
Set <varname>blst_methods_add</varname> parameter
...
# INVITEs and REGISTERs trigger blacklisting
modparam("tm", "blst_methods_add", 33)
...
<varname>blst_methods_lookup</varname> (unsigned integer)
Bitmap of method types that are looked-up in the blacklist
before statefull forwarding.
See also blst_methods_add
The default value is 4294967287, every method type except BYE.
(We try to deliver BYEs no matter what)
Set <varname>blst_methods_lookup</varname> parameter
...
# lookup only INVITEs
modparam("tm", "blst_methods_lookup", 1)
...
<varname>cancel_b_method</varname> (integer)
Method used when attempting to CANCEL an unreplied transaction branch
(a branch where no reply greater the 99 was received).
The possible values are 0, 1, and 2.
0 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 then 2.1.
1 will keep retransmitting the request on
unreplied branches. If a provisional answer is later 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 (fr_timer).
2 will send and retransmit CANCEL even on
unreplied branches, stopping the request retransmissions. This has the
same advantages as 1 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).
The default value is 1.
Set <varname>cancel_b_method</varname> parameter
...
modparam("tm", "cancel_b_method", 1)
...
<varname>reparse_on_dns_failover</varname> (integer)
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.
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.
Note: If the parameter is set, branch route block and TMCB_REQUEST_FWDED
callback are not called in case of the failover.
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
for instance.
Default value is 1.
Set <varname>reparse_on_dns_failover</varname> parameter
...
modparam("tm", "reparse_on_dns_failover", 0)
...
<varname>on_sl_reply</varname> (string)
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 it returns 0.
Set <varname>on_sl_reply</varname> parameter
...
modparam("tm", "on_sl_reply", "stateless_replies")
...
onreply_route["stateless_replies"] {
# do not allow stateless replies to be forwarded
return 0;
}
<varname>contacts_avp</varname> (string)
This is the name or Id of an AVP
that t_load_contacts() function uses to
store contacts of the destination set and that
t_next_contacts() function uses to
restore those contacts.
Default value is "NULL"
(t_load_contacts()/t_next_contacts() functions
are disabled).
Set <varname>contacts_avp</varname> parameter
...
modparam("tm", "contacts_avp", "$avp(i:25)")
...
<varname>fr_timer_avp</varname> (string)
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 fr_timer parameter for the
current transaction.
The value of this parameter is the the name of the AVP to be
checked, without the $ character or "$avp" prefix.
The value of the AVP is expected to be expressed in
seconds and not milliseconds (unlike the rest
of the timers).
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
t_set_fr() on a per transaction basis.
See also: t_set_fr(),
fr_timer.
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.
Set <varname>fr_timer_avp</varname> parameter
...
modparam("tm", "fr_timer_avp", "i:708")
# K mode
modparam("tm", "fr_timer_avp", "$avp(i:708)")
...
<varname>fr_inv_timer_avp</varname> (string)
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 fr_inv_timer parameter for the
current transaction.
The value of this parameter is the the name of the AVP to be
checked, without the $ character or "$avp" prefix.
The value of the AVP is expected to be expressed in
seconds and not milliseconds (unlike the rest
of the timers).
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
t_set_fr() on a per transaction basis.
See also: t_set_fr(),
fr_inv_timer.
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.
Set <varname>fr_inv_timer_avp</varname> parameter
...
modparam("tm", "fr_inv_timer_avp", "my_fr_inv_timer")
# K mode
modparam("tm", "fr_inv_timer_avp", "$avp(my_fr_inv_timer)")
...
<varname>unmatched_cancel</varname> (string)
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 statefull forwarding has an
additional hidden advantage: tm 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).
Default value is 0.
Set <varname>unmatched_cancel</varname> parameter
...
modparam("tm", "unmatched_cancel", "2")
...
<varname>ruri_matching</varname> (integer)
If set it will also try to match the request uri when doing
pre-3261 transaction matching (the via branch parameter does
not contain the 3261 cookie).
The only reason to have it not set is for interoperability with old,
broken implementations.
Default value is 1 (on).
Can be set at runtime, e.g.:
$ sercmd cfg.set_now_int tm ruri_matching 0
Set <varname>ruri_matching</varname> parameter
...
modparam("tm", "ruri_matching", 1)
...
<varname>via1_matching</varname> (integer)
If set it will also try to match the topmost via when doing
pre-3261 transaction matching (the via branch parameter does
not contain the 3261 cookie).
The only reason to have it not set is for interoperability with old,
broken implementations.
Default value is 1 (on).
Can be set at runtime, e.g.:
$ sercmd cfg.set_now_int tm via1_matching 0
Set <varname>via1_matching</varname> parameter
...
modparam("tm", "via1_matching", 1)
...
<varname>pass_provisional_replies</varname> (integer)
If set, TMCB_LOCAL_REPONSE_OUT tm registered callbacks will be called
also for provisional replies.
Default value is 0 (off).
Can be set at runtime, e.g.:
$ sercmd cfg.set_now_int tm pass_provisional_replies 1
Set <varname>pass_provisional_replies</varname> parameter
...
modparam("tm", "pass_provisional_replies", 1)
...
<varname>default_code</varname> (integer)
Default response code sent by t_reply() if it
cannot retrieve its parameters (e.g. inexistent avp).
Valid values are between 400 and 699.
Default value is 500.
Can be set at runtime, e.g.:
$ sercmd cfg.set_now_int tm default_code 505
Set <varname>default_code</varname> parameter
...
modparam("tm", "default_code", 501)
...
<varname>default_reason</varname> (string)
Default SIP reason phrase sent by t_reply() if it
cannot retrieve its parameters (e.g. inexistent avp).
Default value is "Server Internal Error".
Can be set at runtime, e.g.:
$ sercmd cfg.set_now_string tm default_reason "Unknown error"
Set <varname>default_reason</varname> parameter
...
modparam("tm", "default_reason", "Unknown reason")
...
<varname>disable_6xx_block</varname> (integer)
If set tm will treat all the 6xx replies like normal replies
(warning: this would be non-rfc conformant behaviour).
If not set (default) receiving a 6xx will cancel all the running
parallel branches, will stop dns failover and forking. However
serial forking using append_branch() in the
failure_route will still work.
It can be overwritten on a per transaction basis using
t_set_disable_6xx().
Default value is 0 (off, rfc conformant behaviour).
Can be set at runtime, e.g.:
$ sercmd cfg.set_now_int tm disable_6xx_block 0
See also: t_set_disable_6xx().
Set <varname>disable_6xx_block</varname> parameter
...
modparam("tm", "disable_6xx_block", 1)
...
<varname>local_ack_mode</varname> (integer)
It controls where locally generated ACKs for 2xx replies to local
transactions (transactions created via t_uac*()
either thorugh the tm api or via RPC/mi/fifo) are sent.
It has 3 possible values:
0 - 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.
1 - the ACK is sent to the same address as the
corresponding INVITE branch.
2 - the ACK is sent to the source of the 2xx
reply.
Mode 1 and 2 break the rfc, but are useful to deal with some simple UAs
behind the NAT cases (no different routing for the ACK and the contact
contains an address behind the NAT).
The default value is 0 (rfc conformant behaviour).
Can be set at runtime, e.g.:
$ sercmd cfg.set_now_int tm local_ack_mode 0
Set <varname>local_ack_mode</varname> parameter
...
modparam("tm", "local_ack_mode", 1)
...
<varname>failure_reply_mode</varname> (integer)
It 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.
To control per transaction see t_drop_replies().
It has 4 possible values:
0 - 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 comming from SER 2.1.x.
1 - all branches are discarded by default. You
can still overwrite the behaviour via t_drop_replies()
2 - by default only the branches of previous leg
of serial forking are discarded
3 - 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).
The default value is 0.
Set <varname>failure_reply_mode</varname> parameter
...
modparam("tm", "failure_reply_mode", 3)
...
<varname>faked_reply_prio</varname> (integer)
It controls how branch selection is done. It allows to give a penalty
to faked replies such as the infamous 408 on branch timeout.
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.
0 - disabled (default)
< 0 - priority is increased by given amount.
> 0 - priority is decreased by given amount.
Do not make it higer than 10000 or faked replies will even loose
from 1xx clsss replies.
The default value is 0.
To let received replies win from a locally generated 408, set this
value to 2000.
Set <varname>faked_reply_prio</varname> parameter
...
modparam("tm", "faked_reply_prio", 2000)
...
<varname>local_cancel_reason</varname> (boolean)
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=<final_reply_code>".
Default value is 1 (enabled).
Can be set at runtime, e.g.:
$ sercmd cfg.set_now_int tm local_cancel_reason 0
See also: e2e_cancel_reason.
Set <varname>local_cancel_reason</varname> parameter
...
modparam("tm", "local_cancel_reason", 0)
...
<varname>e2e_cancel_reason</varname> (boolean)
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.
Default value is 1 (enabled).
Can be changed at runtime, e.g.:
$ sercmd cfg.set_now_int tm e2e_cancel_reason 0
See also: t_set_no_e2e_cancel_reason() and
local_cancel_reason.
Set <varname>e2e_cancel_reason</varname> parameter
...
modparam("tm", "e2e_cancel_reason", 0)
...