Browse code

tm Update readme with section ID's, fix typos

Yes, it was a boring flight...

Olle E. Johansson authored on 17/12/2014 20:25:49
Showing 2 changed files
... ...
@@ -675,7 +675,7 @@ modparam("tm", "fr_timer", 10000)
675 675
    Timer which hits if no final reply for an INVITE arrives after a
676 676
    provisional message was received (in milliseconds).
677 677
 
678
-   Note: this timer can be restarted when a provisional response is
678
+   Note: This timer can be restarted when a provisional response is
679 679
    received. For more details see restart_fr_on_each_reply.
680 680
 
681 681
    Default value is 120000 ms (120 seconds).
... ...
@@ -696,7 +696,7 @@ modparam("tm", "fr_inv_timer", 180000)
696 696
    transaction fr_inv_timer and fr_timer values.
697 697
 
698 698
    An INVITE transaction will be kept in memory for maximum:
699
-   max_inv_lifetime+fr_timer(from the ack to the final reply
699
+   max_inv_lifetime+fr_timer(from the ACK to the final reply
700 700
    wait)+wt_timer.
701 701
 
702 702
    The main difference between this timer and fr_inv_timer is that the
... ...
@@ -707,8 +707,8 @@ modparam("tm", "fr_inv_timer", 180000)
707 707
    provisional reply. Even if restart_fr_on_each_reply is not set the
708 708
    fr_inv_timer will still be restarted for each increasing reply (e.g.
709 709
    180, 181, 182, ...). Another example when a transaction can live
710
-   substantially more then its fr_inv_timer and where max_inv_lifetime
711
-   will help is when dns failover is used (each failed dns destination can
710
+   substantially more than its fr_inv_timer and where max_inv_lifetime
711
+   will help is when DNS failover is used (each failed DNS destination can
712 712
    introduce a new branch).
713 713
 
714 714
    The default value is 180000 ms (180 seconds - the rfc3261 timer C
... ...
@@ -732,17 +732,17 @@ modparam("tm", "max_inv_lifetime", 150000)
732 732
    transaction fr_timer value. It's the same as max_inv_lifetime, but for
733 733
    non-INVITEs.
734 734
 
735
-   A non-INVITE transaction will be kept in memory for maximum:
735
+   A non-INVITE transaction will be kept in memory for a maximum of:
736 736
    max_noninv_lifetime+wt_timer.
737 737
 
738 738
    The main difference between this timer and fr_timer is that the
739 739
    fr_timer is per branch, while max_noninv_lifetime is per the whole
740 740
    transaction. An example when a transaction can live substantially more
741
-   then its fr_timer and where max_noninv_lifetime will help is when dns
742
-   failover is used (each failed dns destination can introduce a new
741
+   then its fr_timer and where max_noninv_lifetime will help is when DNS
742
+   failover is used (each failed DNS SRV destination can introduce a new
743 743
    branch).
744 744
 
745
-   The default value is 32000 ms (32 seconds - the rfc3261 timer F value).
745
+   The default value is 32000 ms (32 seconds - the RFC3261 timer F value).
746 746
 
747 747
    See also: max_inv_lifetime, t_set_max_lifetime() (allows changing
748 748
    max_noninv_lifetime on a per transaction basis), t_reset_max_lifetime
... ...
@@ -757,9 +757,9 @@ modparam("tm", "max_noninv_lifetime", 30000)
757 757
 
758 758
    Time for which a transaction stays in memory to absorb delayed messages
759 759
    after it completed (in milliseconds); also, when this timer hits,
760
-   retransmission of local cancels is stopped (a puristic but complex
761
-   behavior would be not to enter wait state until local branches are
762
-   finished by a final reply or FR timer--we simplified).
760
+   retransmission of local CANCEL requests is stopped (a puristic but
761
+   complex behavior would be not to enter wait state until local branches
762
+   are finished by a final reply or FR timer--we simplified).
763 763
 
764 764
    Default value is 5000 ms (5 seconds).
765 765
 
... ...
@@ -773,7 +773,7 @@ modparam("tm", "wt_timer", 1000)
773 773
    Time after which a to-be-deleted transaction currently ref-ed by a
774 774
    process will be tried to be deleted again (in milliseconds).
775 775
 
776
-   Note: this parameter is obsolete for ser 2.1 (in 2.1 the transaction is
776
+   Note: this parameter is obsolete for SER 2.1 (in 2.1 the transaction is
777 777
    deleted the moment it's not referenced anymore).
778 778
 
779 779
    Default value is 200 milliseconds.
... ...
@@ -814,10 +814,11 @@ modparam("tm", "retr_timer2", 2000)
814 814
    response was ever received on this branch, it will be silently dropped
815 815
    (no 408 reply will be generated) This behavior is overridden if a
816 816
    request is forked, the transaction has a failure route or callback, or
817
-   some functionality explicitly turned it on for a transaction (like acc
818
-   does to avoid unaccounted transactions due to expired timer). Turn this
819
-   off only if you know the client UACs will timeout and their timeout
820
-   interval for INVITEs is lower or equal than tm's fr_inv_timer.
817
+   some functionality explicitly turned it on for a transaction (like the
818
+   ACC module does to avoid unaccounted transactions due to expired
819
+   timer). Turn this off only if you know the client UACs will timeout and
820
+   their timeout interval for INVITEs is lower or equal than tm's
821
+   fr_inv_timer.
821 822
 
822 823
    Default value is 1 (on).
823 824
 
... ...
@@ -852,7 +853,7 @@ modparam("tm", "restart_fr_on_each_reply", 0)
852 852
 
853 853
    If set (default) tm will automatically send and 100 reply to INVITEs.
854 854
 
855
-   Setting it to 0 one can be used to enable doing first some tests or
855
+   Setting it to 0 can be used to enable first running some tests or
856 856
    pre-processing on the INVITE and only if some conditions are met
857 857
    manually send a 100 (using t_reply()). Note however that in this case
858 858
    all the 100s have to be sent "by hand". t_set_auto_inv_100() might help
... ...
@@ -870,7 +871,7 @@ modparam("tm", "auto_inv_100", 0)
870 870
 
871 871
 4.12. auto_inv_100_reason (string)
872 872
 
873
-   Set reason text of the automatically send 100 to an INVITE.
873
+   Set reason text of the automatically sent 100 to an INVITE.
874 874
 
875 875
    Default value is "trying -- your call is important to us".
876 876
 
... ...
@@ -885,8 +886,8 @@ modparam("tm", "auto_inv_100_reason", "Trying")
885 885
 
886 886
    Unix socket transmission timeout, in milliseconds.
887 887
 
888
-   If unix sockets are used (e.g.: to communicate with sems) and sending a
889
-   message on a unix socket takes longer then unix_tx_timeout, the send
888
+   If UNIX sockets are used (e.g.: to communicate with sems) and sending a
889
+   message on a UNIX socket takes longer than unix_tx_timeout, the send
890 890
    will fail.
891 891
 
892 892
    The default value is 500 milliseconds.
... ...
@@ -898,15 +899,17 @@ modparam("tm", "unix_tx_timeout", 250)
898 898
 
899 899
 4.14. aggregate_challenges (integer)
900 900
 
901
-   If set (default), the final reply is a 401 or a 407 and more then one
902
-   branch received a 401 or 407, then all the WWW-Authenticate and
901
+   If set (default) and the final response is a 401 or a 407 and more than
902
+   one branch received a 401 or 407, then all the WWW-Authenticate and
903 903
    Proxy-Authenticate headers from all the 401 and 407 replies will be
904
-   aggregated in a new final reply. If only one branch received the
904
+   aggregated in a new final response. If only one branch received the
905 905
    winning 401 or 407 then this reply will be forwarded (no new one will
906
-   be built). If 0 only the first 401, or if no 401 was received the first
907
-   407, will be forwarded (no header aggregation).
906
+   be built).
908 907
 
909
-   Default value is 1 (required by rfc3261).
908
+   If disabled (set to 0) only the first 401, or if no 401 was received
909
+   the first 407, will be forwarded (no header aggregation).
910
+
911
+   Default value is 1 (required by RFC 3261).
910 912
 
911 913
    Example 1.14. Set aggregate_challenges parameter
912 914
 ...
... ...
@@ -923,13 +926,13 @@ modparam("tm", "aggregate_challenges", 0)
923 923
    INVITE message. Do not disable the INVITE re-parsing for example in the
924 924
    following cases:
925 925
 
926
-   - The INVITE contains a preloaded route-set, and SER forwards the
927
-   message to the next hop according to the Route header. The Route header
928
-   is not removed in the CANCEL without reparse_invite=1.
926
+   - The INVITE contains a preloaded route-set, and Kamailio forwards the
927
+   message to the next hop according to the "Route" header. The "Route"
928
+   header is not removed in the CANCEL without reparse_invite=1.
929 929
 
930
-   - SER record-routes, thus an in-dialog INVITE contains a Route header
931
-   which is removed during loose routing. If the in-dialog INVITE is
932
-   rejected, the negative ACK still contains the Route header without
930
+   - Kamailio record-routes, thus an in-dialog INVITE contains a "Route"
931
+   header which is removed during loose routing. If the in-dialog INVITE
932
+   is rejected, the negative ACK still contains the "Route" header without
933 933
    reparse_invite=1.
934 934
 
935 935
    Default value is 1.
... ...
@@ -946,7 +949,7 @@ modparam("tm", "reparse_invite", 0)
946 946
    INVITE.
947 947
 
948 948
    Note, that the parameter value effects only those headers which are not
949
-   covered by RFC-3261 (which are neither mandatory nor prohibited in
949
+   covered by RFC 3261 (which are neither mandatory nor prohibited in
950 950
    CANCEL and ACK), and the parameter can be used only together with
951 951
    reparse_invite=1.
952 952
 
... ...
@@ -959,11 +962,11 @@ modparam("tm", "ac_extra_hdrs", "myfavoriteheaders-")
959 959
 
960 960
 4.17. blst_503 (integer)
961 961
 
962
-   If set and the blacklist support is enabled, every 503 reply source is
963
-   added to the blacklist. The initial blacklist timeout (or ttl) depends
964
-   on the presence of a Retry-After header in the reply and the values of
965
-   the following tm parameters: blst_503_def_timeout, blst_503_min_timeout
966
-   and blst_503_max_timeout.
962
+   If set and the Kamailio blacklist support is enabled, every 503 reply
963
+   source is added to the blacklist. The initial blacklist timeout (or
964
+   ttl) depends on the presence of a "Retry-After" header in the reply and
965
+   the values of the following tm parameters: blst_503_def_timeout,
966
+   blst_503_min_timeout and blst_503_max_timeout.
967 967
 
968 968
    WARNING:blindly allowing 503 blacklisting could be very easily
969 969
    exploited for DOS attacks in most network setups.
... ...
@@ -977,13 +980,13 @@ modparam("tm", "blst_503", 1)
977 977
 
978 978
 4.18. blst_503_def_timeout (integer)
979 979
 
980
-   Blacklist interval in seconds for a 503 reply with no Retry-After
980
+   Blacklist interval in seconds for a 503 reply with no "Retry-After"
981 981
    header. See also blst_503, blst_503_min_timeout and
982 982
    blst_503_max_timeout.
983 983
 
984
-   The default value is 0, which means that if no Retry-After header is
985
-   present, the 503 reply source will not be blacklisted (rfc conformant
986
-   behaviour).
984
+   The default value is 0, which means that if no "Retry-After" header is
985
+   present, the 503 reply source will not be blacklisted (RFC 3261
986
+   conformant behaviour).
987 987
 
988 988
    Example 1.18. Set blst_503_def_timeout parameter
989 989
 ...
... ...
@@ -993,9 +996,10 @@ modparam("tm", "blst_503_def_timeout", 120)
993 993
 4.19. blst_503_min_timeout (integer)
994 994
 
995 995
    Minimum blacklist interval in seconds for a 503 reply with a
996
-   Retry-After header. It will be used if the Retry-After value is
997
-   smaller. See also blst_503, blst_503_def_timeout and
998
-   blst_503_max_timeout.
996
+   "Retry-After" header. It will be used if the "Retry-After" value is
997
+   smaller than this value.
998
+
999
+   See also blst_503, blst_503_def_timeout and blst_503_max_timeout.
999 1000
 
1000 1001
    The default value is 0
1001 1002
 
... ...
@@ -1007,9 +1011,10 @@ modparam("tm", "blst_503_min_timeout", 30)
1007 1007
 4.20. blst_503_max_timeout (integer)
1008 1008
 
1009 1009
    Maximum blacklist interval in seconds for a 503 reply with a
1010
-   Retry-After header. It will be used if the Retry-After value is
1011
-   greater. See also blst_503, blst_503_def_timeout and
1012
-   blst_503_min_timeout.
1010
+   "Retry-After header". It will be used if the "Retry-After" value is
1011
+   greater than this limit.
1012
+
1013
+   See also blst_503, blst_503_def_timeout and blst_503_min_timeout.
1013 1014
 
1014 1015
    The default value is 3600
1015 1016
 
... ...
@@ -1029,11 +1034,11 @@ modparam("tm", "blst_503_max_timeout", 604800)
1029 1029
    INFO=16, REGISTER=32, SUBSCRIBE=64, NOTIFY=126, OTHER=256 (all the
1030 1030
    unknown types). Check parser/msg_parser.h for farther details.
1031 1031
 
1032
-   Change the value carefully, because requests not having provisional
1033
-   response (everything but INVITE) can easily cause the next hop to be
1034
-   inserted into the blacklist by mistake. For exmaple the next hop is a
1035
-   proxy, it is alive, but waiting for the response of the UAS, and has
1036
-   higher fr_timer value.
1032
+   Change the value carefully, because requests that doesn't get a
1033
+   provisional response (everything but INVITE) can easily cause the next
1034
+   hop to be inserted into the blacklist by mistake. For exmaple the next
1035
+   hop is a proxy, it is alive, but waiting for the response of the UAS,
1036
+   and has higher fr_timer value.
1037 1037
 
1038 1038
    The default value is 1, only INVITEs trigger blacklisting
1039 1039
 
... ...
@@ -1045,8 +1050,8 @@ modparam("tm", "blst_methods_add", 33)
1045 1045
 
1046 1046
 4.22. blst_methods_lookup (unsigned integer)
1047 1047
 
1048
-   Bitmap of method types that are looked-up in the blacklist before
1049
-   statefull forwarding. See also blst_methods_add
1048
+   Bitmap of method types that are looked-up in the blacklist before being
1049
+   forwarded statefully. See also blst_methods_add
1050 1050
 
1051 1051
    The default value is 4294967287, every method type except BYE. (We try
1052 1052
    to deliver BYEs no matter what)
... ...
@@ -1060,10 +1065,10 @@ modparam("tm", "blst_methods_lookup", 1)
1060 1060
 4.23. cancel_b_method (integer)
1061 1061
 
1062 1062
    Method used when attempting to CANCEL an unreplied transaction branch
1063
-   (a branch where no reply greater the 99 was received). The possible
1064
-   values are 0, 1, and 2.
1063
+   (a branch where no response was received). The possible values are 0,
1064
+   1, and 2.
1065 1065
 
1066
-   0 will immediately stop the request (INVITE) retransmission on the
1066
+   - 0 will immediately stop the request (INVITE) retransmission on the
1067 1067
    branch and it will behave as if the branch was immediately replied with
1068 1068
    a 487 (a fake internal 487 reply). The advantage is the unreplied
1069 1069
    branches will be terminated immediately. However it introduces a race
... ...
@@ -1071,22 +1076,22 @@ modparam("tm", "blst_methods_lookup", 1)
1071 1071
    have an UA receiving a 2xx after a 487. Moreover this risk is greatly
1072 1072
    amplified by packet loss (e.g. if an 180 is lost the branch will look
1073 1073
    as unreplied and a CANCEL will silently drop the branch, but a 2xx can
1074
-   still come at a later time). This is the behaviour for ser versions
1075
-   older then 2.1.
1074
+   still come at a later time). This is the behaviour for SER versions
1075
+   older than 2.1.
1076 1076
 
1077
-   1 will keep retransmitting the request on unreplied branches. If a
1078
-   provisional answer is later received a CANCEL will be immediately sent
1079
-   back (attempting to quickly trigger a 487). This approach is race free
1080
-   and avoids the 2xx after 487 problem, but it's more resource intensive:
1077
+   - 1 will keep retransmitting the request on unreplied branches. If a
1078
+   provisional answer is received a CANCEL will be immediately sent back
1079
+   (attempting to quickly trigger a 487). This approach is race free and
1080
+   avoids the 2xx after 487 problem, but it's more resource intensive:
1081 1081
    faced with a branch towards and UA that doesn't answer, a CANCEL
1082 1082
    attempt will keep the transaction alive for the whole timeout interval
1083 1083
    (fr_timer).
1084 1084
 
1085
-   2 will send and retransmit CANCEL even on unreplied branches, stopping
1086
-   the request retransmissions. This has the same advantages as 1 and also
1087
-   avoids the extra roundtrip in the case of the provisional reply, but
1088
-   it's not RFC 3261 conforming (the RFC allows sending CANCELs only on
1089
-   pending branches).
1085
+   - 2 will send and retransmit CANCEL even on unreplied branches,
1086
+   stopping the request retransmissions. This has the same advantages as 1
1087
+   and also avoids the extra roundtrip in the case of the provisional
1088
+   reply, but it's not RFC 3261 conforming (the RFC allows sending CANCELs
1089
+   only on pending branches).
1090 1090
 
1091 1091
    The default value is 1.
1092 1092
 
... ...
@@ -1113,8 +1118,8 @@ modparam("tm", "cancel_b_method", 1)
1113 1113
    the outgoing socket address is not corrected in any other part of the
1114 1114
    message. It is dangerous on multihomed hosts: when the new SIP request
1115 1115
    after the DNS failover is sent via different interface than the first
1116
-   request, the message can contain incorrect ip address in the
1117
-   Record-Route header for instance.
1116
+   request, the message can contain incorrect IP address in the
1117
+   Record-Route header.
1118 1118
 
1119 1119
    Default value is 1.
1120 1120
 
... ...
@@ -1142,7 +1147,7 @@ onreply_route["stateless_replies"] {
1142 1142
 
1143 1143
 4.26. contacts_avp (string)
1144 1144
 
1145
-   This is the name of an XAVP that t_load_contacts() function uses to
1145
+   This is the name of an XAVP that the t_load_contacts() function uses to
1146 1146
    store contacts of the destination set and that t_next_contacts()
1147 1147
    function uses to restore those contacts.
1148 1148
 
... ...
@@ -1156,7 +1161,7 @@ modparam("tm", "contacts_avp", "tm_contacts")
1156 1156
 
1157 1157
 4.27. contact_flows_avp (string)
1158 1158
 
1159
-   This is the name of an XAVP that t_next_contacts() function uses to
1159
+   This is the name of an XAVP that the t_next_contacts() function uses to
1160 1160
    store contacts (if any) that it skipped, because they contained same
1161 1161
    +sip.instance value than some other contact, and that
1162 1162
    t_next_contact_flows() function uses to restore those contacts.
... ...
@@ -1178,9 +1183,6 @@ modparam("tm", "contact_flows_avp", "tm_contact_flows")
1178 1178
    fr_timer timer, effectively overriding the value configured in fr_timer
1179 1179
    parameter for the current transaction.
1180 1180
 
1181
-   The value of this parameter is the the name of the AVP to be checked,
1182
-   without the $ character or "$avp" prefix.
1183
-
1184 1181
 Note
1185 1182
 
1186 1183
    The value of the AVP is expected to be expressed in seconds and not
... ...
@@ -1195,13 +1197,14 @@ Note
1195 1195
 
1196 1196
    In Kamailio compatibility mode (defined by #!KAMAILIO), the value of
1197 1197
    the parameter must be the name of an AVP in pseudo-variable format:
1198
-   $avp(name). In SER compatibility mode it must by just AVP name.
1198
+   $avp(name). In SER compatibility mode it must be just AVP name.
1199 1199
 
1200 1200
    Example 1.28. Set fr_timer_avp parameter
1201 1201
 ...
1202
-modparam("tm", "fr_timer_avp", "i:708")
1203
-# K mode
1202
+# Kamailio mode
1204 1203
 modparam("tm", "fr_timer_avp", "$avp(i:708)")
1204
+# Old SER mode
1205
+modparam("tm", "fr_timer_avp", "i:708")
1205 1206
 ...
1206 1207
 
1207 1208
 4.29. fr_inv_timer_avp (string)
... ...
@@ -1214,9 +1217,6 @@ modparam("tm", "fr_timer_avp", "$avp(i:708)")
1214 1214
    effectively overriding the value configured in fr_inv_timer parameter
1215 1215
    for the current transaction.
1216 1216
 
1217
-   The value of this parameter is the the name of the AVP to be checked,
1218
-   without the $ character or "$avp" prefix.
1219
-
1220 1217
 Note
1221 1218
 
1222 1219
    The value of the AVP is expected to be expressed in seconds and not
... ...
@@ -1235,22 +1235,24 @@ Note
1235 1235
 
1236 1236
    Example 1.29. Set fr_inv_timer_avp parameter
1237 1237
 ...
1238
-modparam("tm", "fr_inv_timer_avp", "my_fr_inv_timer")
1239
-# K mode
1238
+# Kamailio mode
1240 1239
 modparam("tm", "fr_inv_timer_avp", "$avp(my_fr_inv_timer)")
1240
+# Old SER mode
1241
+modparam("tm", "fr_inv_timer_avp", "my_fr_inv_timer")
1241 1242
 ...
1242 1243
 
1243 1244
 4.30. unmatched_cancel (string)
1244 1245
 
1245 1246
    This parameter selects between forwarding CANCELs that do not match any
1246 1247
    transaction statefully (0, default value), statelessly (1) or dropping
1247
-   them (2). Note that the statefull forwarding has an additional hidden
1248
-   advantage: tm will be able to recognize INVITEs that arrive after their
1249
-   CANCEL. Note also that this feature could be used to try a memory
1250
-   exhaustion DOS attack against a proxy that authenticates all requests,
1251
-   by continuously flooding the victim with CANCELs to random destinations
1252
-   (since the CANCEL cannot be authenticated, each received bogus CANCEL
1253
-   will create a new transaction that will live by default 30s).
1248
+   them (2). Note that the stateful forwarding has an additional hidden
1249
+   advantage: the tm module will be able to recognize INVITEs that arrive
1250
+   after their CANCEL. Note also that this feature could be used to try a
1251
+   memory exhaustion DOS attack against a proxy that authenticates all
1252
+   requests, by continuously flooding the victim with CANCELs to random
1253
+   destinations (since the CANCEL cannot be authenticated, each received
1254
+   bogus CANCEL will create a new transaction that will live by default
1255
+   30s).
1254 1256
 
1255 1257
    Default value is 0.
1256 1258
 
... ...
@@ -1261,9 +1263,9 @@ modparam("tm", "unmatched_cancel", "2")
1261 1261
 
1262 1262
 4.31. ruri_matching (integer)
1263 1263
 
1264
-   If set it will also try to match the request uri when doing pre-3261
1265
-   transaction matching (the via branch parameter does not contain the
1266
-   3261 cookie).
1264
+   If set the TM module will try to match the request URI when doing SIP
1265
+   1.0 (pre-RFC 3261) transaction matching (the "Via" header branch
1266
+   parameter does not contain the 3261 cookie).
1267 1267
 
1268 1268
    The only reason to have it not set is for interoperability with old,
1269 1269
    broken implementations.
... ...
@@ -1280,9 +1282,9 @@ modparam("tm", "ruri_matching", 1)
1280 1280
 
1281 1281
 4.32. via1_matching (integer)
1282 1282
 
1283
-   If set it will also try to match the topmost via when doing pre-3261
1284
-   transaction matching (the via branch parameter does not contain the
1285
-   3261 cookie).
1283
+   If set the TM module will try to match the topmost "Via" header when
1284
+   doing SIP 1.0 (pre-RFC 3261) transaction matching (the "Via" header
1285
+   branch parameter does not contain the 3261 cookie).
1286 1286
 
1287 1287
    The only reason to have it not set is for interoperability with old,
1288 1288
    broken implementations.
... ...
@@ -1299,12 +1301,12 @@ modparam("tm", "via1_matching", 1)
1299 1299
 
1300 1300
 4.33. callid_matching (integer)
1301 1301
 
1302
-   If set it will also try to match the callid when doing transaction
1303
-   matching.
1302
+   If set the TM module will try to match the callid when doing
1303
+   transaction matching.
1304 1304
 
1305 1305
    Turn on if you don't want replies/requests from broken clients who send
1306 1306
    a mangled Call-ID to match the transaction. For example when the other
1307
-   side won't recognise the response anyway because of changed Call-ID,
1307
+   side won't recognise the response anyway because of a changed Call-ID,
1308 1308
    this setting will prevent accounting records to be created or
1309 1309
    failure_route to be skipped.
1310 1310
 
... ...
@@ -1365,11 +1367,11 @@ modparam("tm", "default_reason", "Unknown reason")
1365 1365
 
1366 1366
 4.37. disable_6xx_block (integer)
1367 1367
 
1368
-   If set tm will treat all the 6xx replies like normal replies (warning:
1369
-   this would be non-rfc conformant behaviour).
1368
+   If set the TM module will treat all the 6xx replies like normal replies
1369
+   (warning: this would be non-RFC conformant behaviour).
1370 1370
 
1371 1371
    If not set (default) receiving a 6xx will cancel all the running
1372
-   parallel branches, will stop dns failover and forking. However serial
1372
+   parallel branches, will stop DNS failover and forking. However serial
1373 1373
    forking using append_branch() in the failure_route will still work.
1374 1374
 
1375 1375
    It can be overwritten on a per transaction basis using
... ...
@@ -1389,12 +1391,12 @@ modparam("tm", "disable_6xx_block", 1)
1389 1389
 
1390 1390
 4.38. local_ack_mode (integer)
1391 1391
 
1392
-   It controls where locally generated ACKs for 2xx replies to local
1393
-   transactions (transactions created via t_uac*() either thorugh the tm
1394
-   api or via RPC/mi/fifo) are sent.
1392
+   This setting controls where locally generated ACKs for 2xx replies to
1393
+   local transactions (transactions created via t_uac*() either through
1394
+   the TM api or via RPC/mi/fifo) are sent.
1395 1395
 
1396 1396
    It has 3 possible values:
1397
-     * 0 - the ACK destination is choosen according to the rfc: the next
1397
+     * 0 - the ACK destination is choosen according to the RFC: the next
1398 1398
        hop is found using the contact and the route set and then DNS
1399 1399
        resolution is used on it.
1400 1400
      * 1 - the ACK is sent to the same address as the corresponding INVITE
... ...
@@ -1403,11 +1405,11 @@ modparam("tm", "disable_6xx_block", 1)
1403 1403
 
1404 1404
 Note
1405 1405
 
1406
-   Mode 1 and 2 break the rfc, but are useful to deal with some simple UAs
1407
-   behind the NAT cases (no different routing for the ACK and the contact
1408
-   contains an address behind the NAT).
1406
+   Mode 1 and 2 does not follow RFC 3261, but are useful to deal with some
1407
+   simple UAs behind a NAT (no different routing for the ACK and the
1408
+   contact contains an address behind the NAT).
1409 1409
 
1410
-   The default value is 0 (rfc conformant behaviour).
1410
+   The default value is 0 (RFC conformant behaviour).
1411 1411
 
1412 1412
    Can be set at runtime, e.g.:
1413 1413
         $ kamcmd cfg.set_now_int tm local_ack_mode 0
... ...
@@ -1419,9 +1421,9 @@ modparam("tm", "local_ack_mode", 1)
1419 1419
 
1420 1420
 4.39. failure_reply_mode (integer)
1421 1421
 
1422
-   It controls how branches are managed and replies are selected for
1423
-   failure_route handling: keep all, drop all, drop last branches in SIP
1424
-   serial forking handling.
1422
+   This parameter controls how branches are managed and replies are
1423
+   selected for failure_route handling: keep all, drop all, drop last
1424
+   branches in SIP serial forking handling.
1425 1425
 
1426 1426
    To control per transaction see t_drop_replies().
1427 1427
 
... ...
@@ -1433,7 +1435,7 @@ modparam("tm", "local_ack_mode", 1)
1433 1433
        redirection in failure route, sent to a new destination and this
1434 1434
        one timeout, you will get again the 3xx). Use t_drop_replies() on
1435 1435
        per transaction fashion to control the behavior you want. It is the
1436
-       default behaviour comming from SER 2.1.x.
1436
+       default behaviour coming from SER 2.1.x.
1437 1437
      * 1 - all branches are discarded by default. You can still overwrite
1438 1438
        the behaviour via t_drop_replies()
1439 1439
      * 2 - by default only the branches of previous leg of serial forking
... ...
@@ -1530,7 +1532,7 @@ modparam("tm", "remap_503_500", 0)
1530 1530
 
1531 1531
 4.44. failure_exec_mode (boolean)
1532 1532
 
1533
-   Add local failed branches in timer to be cosidered for failure routing
1533
+   Add local failed branches in timer to be considered for failure routing
1534 1534
    blocks. If disabled, relay functions will return false in case the
1535 1535
    branch could not be forwarded (default behaviour before v4.1.0).
1536 1536
 
... ...
@@ -1544,15 +1546,16 @@ modparam("tm", "failure_exec_mode", 1)
1544 1544
 4.45. dns_reuse_rcv_socket (boolean)
1545 1545
 
1546 1546
    Control reuse of the receive socket for additional branches added by
1547
-   dns failover. If set to 1, the receive socket is used for sending out
1547
+   DNS failover. If set to 1, the receive socket is used for sending out
1548 1548
    the new branches, unless the socket is forced explicitely in
1549 1549
    configuration file. If set to 0, selected socket is done depending on
1550
-   value of global parameter mhomed (if mhomed=0, then the first listen
1550
+   value of global parameter "mhomed" (if mhomed=0, then the first listen
1551 1551
    socket is used, otherwise the socket is selected based on routing
1552 1552
    rules).
1553 1553
 
1554
-   Do enable it with caution, it might create troubles on dns results with
1555
-   different transport layer. Better let it disabled and enable mhomed.
1554
+   Do enable it with caution, it might create troubles on DNS results with
1555
+   different transport layer. Better let it be disabled and enable
1556
+   "mhomed".
1556 1557
 
1557 1558
    Default value is 0 (disabled).
1558 1559
 
... ...
@@ -15,7 +15,7 @@
15 15
 
16 16
     <title>Parameters</title>
17 17
 
18
-    <section id="fr_timer">
18
+    <section id="tm.p.fr_timer">
19 19
 	<title><varname>fr_timer</varname> (integer)</title>
20 20
 	<para>
21 21
 	    Timer which hits if no final reply for a request or ACK for a
... ...
@@ -38,7 +38,7 @@ modparam("tm", "fr_timer", 10000)
38 38
 	</example>
39 39
     </section>
40 40
 
41
-    <section id="fr_inv_timer">
41
+    <section id="tmp.p.fr_inv_timer">
42 42
 	<title><varname>fr_inv_timer</varname> (integer)</title>
43 43
 	<para>
44 44
 	    Timer which hits if no final reply for an INVITE arrives after a
... ...
@@ -47,7 +47,7 @@ modparam("tm", "fr_timer", 10000)
47 47
 	<para>
48 48
 	</para>
49 49
 	<para>
50
-		Note: this timer can be restarted when a provisional response is
50
+		Note: This timer can be restarted when a provisional response is
51 51
 		received. For more details see
52 52
 		<varname>restart_fr_on_each_reply</varname>.
53 53
 	</para>
... ...
@@ -68,7 +68,7 @@ modparam("tm", "fr_inv_timer", 180000)
68 68
 	</example>
69 69
     </section>
70 70
 
71
-	<section id="max_inv_lifetime">
71
+	<section id="tm.p.max_inv_lifetime">
72 72
 	<title><varname>max_inv_lifetime</varname> (integer)</title>
73 73
 	<para>
74 74
 		Maximum time an INVITE transaction is allowed to be active (in 
... ...
@@ -81,7 +81,7 @@ modparam("tm", "fr_inv_timer", 180000)
81 81
 	<para>
82 82
 		An INVITE transaction will be kept in memory for maximum:
83 83
 		<varname>max_inv_lifetime</varname>+<varname>fr_timer</varname>(from 
84
-		the ack to the final reply wait)+<varname>wt_timer</varname>.
84
+		the ACK to the final reply wait)+<varname>wt_timer</varname>.
85 85
 	</para>
86 86
 	<para>
87 87
 		The main difference between this timer and 
... ...
@@ -95,10 +95,10 @@ modparam("tm", "fr_inv_timer", 180000)
95 95
 		provisional reply. Even if <varname>restart_fr_on_each_reply</varname>
96 96
 		is not set the <varname>fr_inv_timer</varname> will still be restarted
97 97
 		for each increasing reply (e.g. 180, 181, 182, ...). 
98
-		Another example when a transaction can live substantially more then its
98
+		Another example when a transaction can live substantially more than its
99 99
 		<varname>fr_inv_timer</varname> and where
100
-		<varname>max_inv_lifetime</varname> will help is when dns failover is 
101
-		used (each failed dns destination can introduce a new branch).
100
+		<varname>max_inv_lifetime</varname> will help is when DNS failover is 
101
+		used (each failed DNS destination can introduce a new branch).
102 102
 	</para>
103 103
 	<para>
104 104
 		The default value is 180000 ms (180 seconds - the rfc3261 
... ...
@@ -136,7 +136,7 @@ modparam("tm", "max_inv_lifetime", 150000)
136 136
 		non-INVITEs.
137 137
 	</para>
138 138
 	<para>
139
-		A non-INVITE transaction will be kept in memory for maximum:
139
+		A non-INVITE transaction will be kept in memory for a maximum of:
140 140
 		<varname>max_noninv_lifetime</varname>+<varname>wt_timer</varname>.
141 141
 	</para>
142 142
 	<para>
... ...
@@ -146,11 +146,11 @@ modparam("tm", "max_inv_lifetime", 150000)
146 146
 		<varname>max_noninv_lifetime</varname> is per the whole transaction.
147 147
 		An example when a transaction can live substantially more then its
148 148
 		<varname>fr_timer</varname> and where
149
-		<varname>max_noninv_lifetime</varname> will help is when dns failover
150
-		is used (each failed dns destination can introduce a new branch).
149
+		<varname>max_noninv_lifetime</varname> will help is when DNS failover
150
+		is used (each failed DNS SRV destination can introduce a new branch).
151 151
 	</para>
152 152
 	<para>
153
-		The default value is 32000 ms (32 seconds - the rfc3261 timer F value).
153
+		The default value is 32000 ms (32 seconds - the RFC3261 timer F value).
154 154
 	</para>
155 155
 	<para>
156 156
 		See also: <varname>max_inv_lifetime</varname>,
... ...
@@ -171,13 +171,13 @@ modparam("tm", "max_noninv_lifetime", 30000)
171 171
 	</example>
172 172
     </section>
173 173
 
174
-    <section id="wt_timer">
174
+    <section id="tm.p.wt_timer">
175 175
 	<title><varname>wt_timer</varname> (integer)</title>
176 176
 	<para>
177 177
 	    Time for which a transaction stays in memory to absorb delayed
178 178
 	    messages after it completed (in milliseconds); also, when this 
179 179
 	    timer hits,
180
-	    retransmission of local cancels is stopped (a puristic but complex
180
+	    retransmission of local CANCEL requests is stopped (a puristic but complex
181 181
 	    behavior would be not to enter wait state until local branches are
182 182
 	    finished by a final reply or FR timer--we simplified).
183 183
 	</para>
... ...
@@ -194,14 +194,14 @@ modparam("tm", "wt_timer", 1000)
194 194
 	</example>
195 195
     </section>
196 196
 
197
-    <section id="delete_timer">
197
+    <section id="tm.p.delete_timer">
198 198
 	<title><varname>delete_timer</varname> (integer)</title>
199 199
 	<para>
200 200
 	    Time after which a to-be-deleted transaction currently ref-ed by a
201 201
 	    process will be tried to be deleted again (in milliseconds).
202 202
 	</para>
203 203
 	<para>
204
-	    Note: this parameter is obsolete for ser 2.1 (in 2.1 the transaction
204
+	    Note: this parameter is obsolete for SER 2.1 (in 2.1 the transaction
205 205
 		 is deleted the moment it's not referenced anymore).
206 206
 	</para>
207 207
 	<para>
... ...
@@ -217,7 +217,7 @@ modparam("tm", "delete_timer", 100)
217 217
 	</example>
218 218
     </section>
219 219
     
220
-    <section id="retr_timer1">
220
+    <section id="tm.p.retr_timer1">
221 221
 	<title><varname>retr_timer1</varname> (integer)</title>
222 222
 	<para>
223 223
 	    Initial retransmission period (in milliseconds).
... ...
@@ -235,7 +235,7 @@ modparam("tm", "retr_timer1", 1000)
235 235
 	</example>
236 236
     </section>
237 237
 
238
-    <section id="retr_timer2">
238
+    <section id="tm.p.retr_timer2">
239 239
 	<title><varname>retr_timer2</varname> (integer)</title>
240 240
 	<para>
241 241
 	    Maximum retransmission period (in milliseconds). The retransmission
... ...
@@ -256,7 +256,7 @@ modparam("tm", "retr_timer2", 2000)
256 256
 	</example>
257 257
     </section>
258 258
 
259
-    <section id="noisy_ctimer">
259
+    <section id="tm.p.noisy_ctimer">
260 260
 	<title><varname>noisy_ctimer</varname> (integer)</title>
261 261
 	<para>
262 262
 	    If set, INVITE transactions that time-out (FR INV timer) will be 
... ...
@@ -265,7 +265,7 @@ modparam("tm", "retr_timer2", 2000)
265 265
 		will be silently dropped (no 408 reply will be generated)
266 266
 		This behavior is overridden if a request is forked, the transaction
267 267
 		 has a failure route or callback, or some functionality explicitly 
268
-		 turned it on  for a transaction (like acc does to avoid unaccounted
268
+		 turned it on  for a transaction (like the ACC module does to avoid unaccounted
269 269
 		 transactions due to expired timer).
270 270
 		Turn this off only if you know the client UACs will timeout and their
271 271
 		timeout interval for INVITEs is lower or equal than tm's
... ...
@@ -284,7 +284,7 @@ modparam("tm", "noisy_ctimer", 1)
284 284
 	</example>
285 285
     </section>
286 286
 
287
-	<section id="restart_fr_on_each_reply">
287
+	<section id="tm.p.restart_fr_on_each_reply">
288 288
 	<title><varname>restart_fr_on_each_reply</varname> (integer)</title>
289 289
 	<para>
290 290
 		If set (default), the <varname>fr_inv_timer</varname> for an INVITE
... ...
@@ -318,17 +318,17 @@ modparam("tm", "restart_fr_on_each_reply", 0)
318 318
 	</example>
319 319
 	</section>
320 320
 
321
-	<section id="auto_inv_100">
321
+	<section id="tm.p.auto_inv_100">
322 322
 	<title><varname>auto_inv_100</varname> (integer)</title>
323 323
 	<para>
324 324
 		If set (default) tm will automatically send and 100 reply to INVITEs.
325 325
 	</para>
326 326
 	<para>
327
-		Setting it to 0 one can be used to enable doing first some tests or
327
+		Setting it to 0 can be used to enable first running some tests or
328 328
 		pre-processing on the INVITE and only if some conditions are met
329 329
 		manually send a 100 (using <function>t_reply()</function>). Note 
330 330
 		however that in this case all the 100s have to be sent "by hand".
331
-		<function>t_set_auto_inv_100()</function> might  help to selectively
331
+		<function>t_set_auto_inv_100()</function> might help to selectively
332 332
 		turn off this feature only for some specific transactions.
333 333
 	</para>
334 334
 	<para>
... ...
@@ -348,10 +348,10 @@ modparam("tm", "auto_inv_100", 0)
348 348
 	</example>
349 349
 	</section>
350 350
 
351
-	<section id="auto_inv_100_reason">
351
+	<section id="tm.p.auto_inv_100_reason">
352 352
 	<title><varname>auto_inv_100_reason</varname> (string)</title>
353 353
 	<para>
354
-		Set reason text of the automatically send 100 to an INVITE.
354
+		Set reason text of the automatically sent 100 to an INVITE.
355 355
 	</para>
356 356
 	<para>
357 357
 		Default value is "trying -- your call is important to us".
... ...
@@ -369,14 +369,14 @@ modparam("tm", "auto_inv_100_reason", "Trying")
369 369
 	</example>
370 370
 	</section>
371 371
 
372
-	<section id="unix_tx_timeout">
372
+	<section id="tm.p.unix_tx_timeout">
373 373
 	<title><varname>unix_tx_timeout</varname> (integer)</title>
374 374
 	<para>
375 375
 		Unix socket transmission timeout, in milliseconds.
376 376
 	</para>
377 377
 	<para>
378
-		If unix sockets are used (e.g.: to communicate with sems) and sending
379
-		a message on a unix socket takes longer then 
378
+		If UNIX sockets are used (e.g.: to communicate with sems) and sending
379
+		a message on a UNIX socket takes longer than 
380 380
 		<varname>unix_tx_timeout</varname>, the send will fail.
381 381
 	</para>
382 382
 	<para>
... ...
@@ -392,20 +392,22 @@ modparam("tm", "unix_tx_timeout", 250)
392 392
 	</example>
393 393
 	</section>
394 394
 
395
-    <section id="aggregate_challenges">
395
+        <section id="tm.p.aggregate_challenges">
396 396
 	<title><varname>aggregate_challenges</varname> (integer)</title>
397 397
 	<para>
398
-		If set (default), the final reply is a 401 or a 407 and more then
398
+		If set (default) and the final response is a 401 or a 407 and more than
399 399
 		one branch received a 401 or 407, then all the WWW-Authenticate and 
400 400
 		Proxy-Authenticate headers from all the 401 and 407 replies will 
401
-		be aggregated in a new final reply. If only one branch received the
401
+		be aggregated in a new final response. If only one branch received the
402 402
 		 winning 401 or 407 then this reply will be forwarded (no new one
403 403
 		 will be built).
404
-		If 0 only the first 401, or if no 401 was received the first 407,  will
404
+	</para>
405
+	<para>
406
+		If disabled (set to 0) only the first 401, or if no 401 was received the first 407,  will
405 407
 		be forwarded (no header aggregation).
406 408
 	</para>
407 409
 	<para>
408
-	    Default value is 1 (required by rfc3261).
410
+	    	Default value is 1 (required by RFC 3261).
409 411
 	</para>
410 412
 	<example>
411 413
 	    <title>Set <varname>aggregate_challenges</varname> parameter</title>
... ...
@@ -417,7 +419,7 @@ modparam("tm", "aggregate_challenges", 0)
417 417
 	</example>
418 418
     </section>
419 419
 
420
-    <section id="reparse_invite">
420
+    <section id="tm.p.reparse_invite">
421 421
 	<title><varname>reparse_invite</varname> (integer)</title>
422 422
 	<para>
423 423
 		If set (default), the CANCEL and negative ACK requests are
... ...
@@ -429,15 +431,15 @@ modparam("tm", "aggregate_challenges", 0)
429 429
 		the INVITE re-parsing for example in the following cases:
430 430
 	</para>
431 431
 	<para>
432
-		- The INVITE contains a preloaded route-set, and SER forwards
433
-		the message to the next hop according to the Route header. The
434
-		Route header is not removed in the CANCEL without
432
+		- The INVITE contains a preloaded route-set, and &kamailio; forwards
433
+		the message to the next hop according to the "Route" header. The
434
+		"Route" header is not removed in the CANCEL without
435 435
 		<varname>reparse_invite</varname>=1.
436 436
 	</para>
437 437
 	<para>
438
-		- SER record-routes, thus an in-dialog INVITE contains a Route
438
+		- &kamailio; record-routes, thus an in-dialog INVITE contains a "Route"
439 439
 		header which is removed during loose routing. If the in-dialog
440
-		INVITE is rejected, the negative ACK still contains the Route
440
+		INVITE is rejected, the negative ACK still contains the "Route"
441 441
 		header without <varname>reparse_invite</varname>=1.
442 442
 	</para>
443 443
 	<para>
... ...
@@ -453,7 +455,7 @@ modparam("tm", "reparse_invite", 0)
453 453
 	</example>
454 454
     </section>
455 455
 
456
-    <section id="ac_extra_hdrs">
456
+    <section id="tm.p.ac_extra_hdrs">
457 457
 	<title><varname>ac_extra_hdrs</varname> (string)</title>
458 458
 	<para>
459 459
 		Header fields prefixed by this parameter value are included
... ...
@@ -462,12 +464,12 @@ modparam("tm", "reparse_invite", 0)
462 462
 	</para>
463 463
 	<para>
464 464
 		Note, that the parameter value effects only those headers
465
-		which are not covered by RFC-3261 (which are neither mandatory
465
+		which are not covered by RFC 3261 (which are neither mandatory
466 466
 		nor prohibited in CANCEL and ACK), and the parameter can be used
467 467
 		only together with <varname>reparse_invite</varname>=1.
468 468
 	</para>
469 469
 	<para>
470
-	    Default value is "".
470
+	    	Default value is "".
471 471
 	</para>
472 472
 	<example>
473 473
 	    <title>Set <varname>ac_extra_hdrs</varname> parameter</title>
... ...
@@ -479,12 +481,12 @@ modparam("tm", "ac_extra_hdrs", "myfavoriteheaders-")
479 479
 	</example>
480 480
     </section>
481 481
 
482
-    <section id="blst_503">
482
+    <section id="tm.p.blst_503">
483 483
 	<title><varname>blst_503</varname> (integer)</title>
484 484
 	<para>
485
-		If set and the blacklist support is enabled, every 503 reply source is
485
+		If set and the &kamailio; blacklist support is enabled, every 503 reply source is
486 486
 		added to the blacklist. The initial blacklist timeout (or ttl) depends
487
-		on the presence of a Retry-After header in the reply and the values of
487
+		on the presence of a "Retry-After" header in the reply and the values of
488 488
 		the following tm parameters: <varname>blst_503_def_timeout</varname>, 
489 489
 		<varname>blst_503_min_timeout</varname> and 
490 490
 		<varname>blst_503_max_timeout</varname>.
... ...
@@ -506,19 +508,19 @@ modparam("tm", "blst_503", 1)
506 506
 	</example>
507 507
     </section>
508 508
 
509
-    <section id="blst_503_def_timeout">
509
+    <section id="tm.p.blst_503_def_timeout">
510 510
 	<title><varname>blst_503_def_timeout</varname> (integer)</title>
511 511
 	<para>
512 512
 		
513
-		Blacklist interval in seconds for a 503 reply with no Retry-After 
513
+		Blacklist interval in seconds for a 503 reply with no "Retry-After"
514 514
 		header.
515 515
 		See also <varname>blst_503</varname>, 
516 516
 		<varname>blst_503_min_timeout</varname> and 
517 517
 		<varname>blst_503_max_timeout</varname>.
518 518
 	</para>
519 519
 	<para>
520
-		The default value is 0, which means that if no Retry-After header is
521
-		present, the 503 reply source will not be blacklisted (rfc conformant
520
+		The default value is 0, which means that if no "Retry-After" header is
521
+		present, the 503 reply source will not be blacklisted (RFC 3261 conformant
522 522
 		 behaviour).
523 523
 	</para>
524 524
 	<example>
... ...
@@ -531,13 +533,15 @@ modparam("tm", "blst_503_def_timeout", 120)
531 531
 	</example>
532 532
     </section>
533 533
 
534
-    <section id="blst_503_min_timeout">
534
+    <section id="tm.p.blst_503_min_timeout">
535 535
 	<title><varname>blst_503_min_timeout</varname> (integer)</title>
536 536
 	<para>
537 537
 		
538 538
 		Minimum blacklist interval in seconds for a 503 reply with a 
539
-		Retry-After header. It will be used if the Retry-After value is 
540
-		smaller.
539
+		"Retry-After" header. It will be used if the "Retry-After" value is 
540
+		smaller than this value.
541
+	</para>
542
+	<para>
541 543
 		See also <varname>blst_503</varname>, 
542 544
 		<varname>blst_503_def_timeout</varname> and 
543 545
 		<varname>blst_503_max_timeout</varname>.
... ...
@@ -555,13 +559,15 @@ modparam("tm", "blst_503_min_timeout", 30)
555 555
 	</example>
556 556
     </section>
557 557
 
558
-    <section id="blst_503_max_timeout">
558
+    <section id="tm.p.blst_503_max_timeout">
559 559
 	<title><varname>blst_503_max_timeout</varname> (integer)</title>
560 560
 	<para>
561 561
 		
562 562
 		Maximum blacklist interval in seconds for a 503 reply with a 
563
-		Retry-After header. It will be used if the Retry-After value is 
564
-		greater.
563
+		"Retry-After header". It will be used if the "Retry-After" value is 
564
+		greater than this limit.
565
+	</para>
566
+	<para>
565 567
 		See also <varname>blst_503</varname>, 
566 568
 		<varname>blst_503_def_timeout</varname> and 
567 569
 		<varname>blst_503_min_timeout</varname>.
... ...
@@ -579,7 +585,7 @@ modparam("tm", "blst_503_max_timeout", 604800)
579 579
 	</example>
580 580
     </section>
581 581
 
582
-    <section id="blst_methods_add">
582
+    <section id="tm.p.blst_methods_add">
583 583
 	<title><varname>blst_methods_add</varname> (unsigned integer)</title>
584 584
 	<para>
585 585
 		Bitmap of method types that trigger blacklisting on
... ...
@@ -594,8 +600,8 @@ modparam("tm", "blst_503_max_timeout", 604800)
594 594
 		Check parser/msg_parser.h for farther details.
595 595
 	</para>
596 596
 	<para>
597
-		Change the value carefully, because requests not having
598
-		provisional response (everything but INVITE) can easily
597
+		Change the value carefully, because requests that doesn't get
598
+		a provisional response (everything but INVITE) can easily
599 599
 		cause the next hop to be inserted into the blacklist
600 600
 		by mistake. For exmaple the next hop is a proxy, it is alive,
601 601
 		but waiting for the response of the UAS, and has higher
... ...
@@ -615,11 +621,11 @@ modparam("tm", "blst_methods_add", 33)
615 615
 	</example>
616 616
     </section>
617 617
 
618
-    <section id="blst_methods_lookup">
618
+    <section id="tm.p.blst_methods_lookup">
619 619
 	<title><varname>blst_methods_lookup</varname> (unsigned integer)</title>
620 620
 	<para>
621 621
 		Bitmap of method types that are looked-up in the blacklist
622
-		before statefull forwarding.
622
+		before being forwarded statefully.
623 623
 		See also <varname>blst_methods_add</varname>
624 624
 	</para>
625 625
 	<para>
... ...
@@ -637,15 +643,15 @@ modparam("tm", "blst_methods_lookup", 1)
637 637
 	</example>
638 638
     </section>
639 639
 
640
-    <section id="cancel_b_method">
640
+    <section id="tm.p.cancel_b_method">
641 641
 	<title><varname>cancel_b_method</varname> (integer)</title>
642 642
 	<para>
643 643
 		Method used when attempting to CANCEL an unreplied transaction branch
644
-		(a branch where no reply greater the 99 was received).
644
+		(a branch where no response was received).
645 645
 		The possible values are 0, 1, and 2.
646 646
 	</para>
647 647
 	<para>
648
-		<emphasis>0</emphasis> will immediately stop the request (INVITE) 
648
+		- <emphasis>0</emphasis> will immediately stop the request (INVITE) 
649 649
 		retransmission on the branch and it will behave as if the branch was 
650 650
 		immediately replied with a 487 (a fake internal 487 reply). The 
651 651
 		advantage is the unreplied branches will be terminated immediately.
... ...
@@ -654,11 +660,11 @@ modparam("tm", "blst_methods_lookup", 1)
654 654
 		 487. Moreover this risk is greatly amplified by packet loss
655 655
 		(e.g. if an 180 is lost the branch will look as unreplied and
656 656
 		 a CANCEL will silently drop the branch, but a 2xx can still come at
657
-		 a later time). This is the behaviour for ser versions older then 2.1.
657
+		 a later time). This is the behaviour for SER versions older than 2.1.
658 658
 	</para>
659 659
 	<para>
660
-		<emphasis>1</emphasis> will keep retransmitting the request on 
661
-		unreplied branches. If a provisional answer is later received a CANCEL
660
+		- <emphasis>1</emphasis> will keep retransmitting the request on 
661
+		unreplied branches. If a provisional answer is received a CANCEL
662 662
 		will be immediately sent back (attempting to quickly trigger a 487). 
663 663
 		This approach is race free and avoids the 2xx after 487 problem, but
664 664
 		 it's more resource intensive: faced with a branch towards and UA that
... ...
@@ -666,7 +672,7 @@ modparam("tm", "blst_methods_lookup", 1)
666 666
 		 the whole timeout interval (<varname>fr_timer</varname>).
667 667
 	</para>
668 668
 	<para>
669
-		<emphasis>2</emphasis> will send and retransmit CANCEL even on 
669
+		- <emphasis>2</emphasis> will send and retransmit CANCEL even on 
670 670
 		unreplied branches, stopping the request retransmissions. This has the
671 671
 		same advantages as <emphasis>1</emphasis> and also avoids the extra 
672 672
 		roundtrip in the case of the provisional reply, but it's not RFC 3261 
... ...
@@ -685,7 +691,7 @@ modparam("tm", "cancel_b_method", 1)
685 685
 	</example>
686 686
     </section>
687 687
 
688
-    <section id="reparse_on_dns_failover">
688
+    <section id="tm.p.reparse_on_dns_failover">
689 689
 	<title><varname>reparse_on_dns_failover</varname> (integer)</title>
690 690
 	<para>
691 691
 		If set to 1, the SIP message after a DNS failover is constructed
... ...
@@ -707,8 +713,7 @@ modparam("tm", "cancel_b_method", 1)
707 707
 		the outgoing socket address is not corrected in any other part of the message.
708 708
 		It is dangerous on multihomed hosts: when the new SIP request after
709 709
 		the DNS failover is sent via different interface than the first request,
710
-		the message can contain incorrect ip address in the Record-Route header
711
-		for instance.
710
+		the message can contain incorrect IP address in the Record-Route header.
712 711
 	</para>
713 712
 	<para>
714 713
 		Default value is 1.
... ...
@@ -723,7 +728,7 @@ modparam("tm", "reparse_on_dns_failover", 0)
723 723
 	</example>
724 724
     </section>
725 725
 
726
-    <section id="on_sl_reply">
726
+    <section id="tm.p.on_sl_reply">
727 727
 	<title><varname>on_sl_reply</varname> (string)</title>
728 728
 	<para>
729 729
 		Sets reply route block, to which control is passed when a
... ...
@@ -746,11 +751,11 @@ onreply_route["stateless_replies"] {
746 746
 	</example>
747 747
     </section>
748 748
 	
749
-	<section>
749
+	<section id ="tm.p.contacts_avp">
750 750
 		<title><varname>contacts_avp</varname> (string)</title>
751 751
 		<para>
752
-		This is the name of an XAVP
753
-                that <function>t_load_contacts()</function> function uses to
752
+		This is the name of an XAVP that the 
753
+		<function>t_load_contacts()</function> function uses to
754 754
                 store contacts of the destination set and that
755 755
                 <function>t_next_contacts()</function> function uses to
756 756
                 restore those contacts.
... ...
@@ -772,11 +777,11 @@ modparam("tm", "contacts_avp", "tm_contacts")
772 772
 		</example>
773 773
 	</section>
774 774
 	
775
-	<section>
775
+	<section id="tm.p.contact_flows_avp">
776 776
 		<title><varname>contact_flows_avp</varname> (string)</title>
777 777
 		<para>
778 778
 		This is the name of an XAVP
779
-                that <function>t_next_contacts()</function> function uses to
779
+                that the <function>t_next_contacts()</function> function uses to
780 780
                 store contacts (if any) that it skipped, because they
781 781
 		contained same +sip.instance value than some other contact,
782 782
                 and that <function>t_next_contact_flows()</function>
... ...
@@ -798,7 +803,7 @@ modparam("tm", "contact_flows_avp", "tm_contact_flows")
798 798
 		</example>
799 799
 	</section>
800 800
 
801
-	<section id="fr_timer_avp">
801
+	<section id="tm.p.fr_timer_avp" >
802 802
 		<title><varname>fr_timer_avp</varname> (string)</title>
803 803
 		<para>
804 804
 			The value of fr_timer timer can be overriden on per-transaction
... ...
@@ -809,10 +814,6 @@ modparam("tm", "contact_flows_avp", "tm_contact_flows")
809 809
 			value configured in <varname>fr_timer</varname> parameter for the
810 810
 			current transaction.
811 811
 		</para>
812
-		<para>
813
-			The value of this parameter is the the name of the AVP to be
814
-			checked, without the $ character or "$avp" prefix.
815
-		</para>
816 812
 		<note><para>
817 813
 			The value of the AVP is expected to be expressed in 
818 814
 			<emphasis>seconds</emphasis> and not milliseconds (unlike the rest
... ...
@@ -831,22 +832,23 @@ modparam("tm", "contact_flows_avp", "tm_contact_flows")
831 831
 		<para>
832 832
 			In Kamailio compatibility mode (defined by #!KAMAILIO), the value
833 833
 			of the parameter must be the name of an AVP in pseudo-variable
834
-			format: $avp(name). In SER compatibility mode it must by just
834
+			format: $avp(name). In SER compatibility mode it must be just
835 835
 			AVP name.
836 836
 		</para>
837 837
 		<example>
838 838
 			<title>Set <varname>fr_timer_avp</varname> parameter</title>
839 839
 			<programlisting>
840 840
 ...
841
-modparam("tm", "fr_timer_avp", "i:708")
842
-# K mode
841
+# Kamailio mode
843 842
 modparam("tm", "fr_timer_avp", "$avp(i:708)")
843
+# Old SER mode
844
+modparam("tm", "fr_timer_avp", "i:708")
844 845
 ...
845 846
 			</programlisting>
846 847
 		</example>
847 848
 	</section>
848 849
 	
849
-	<section id="fr_inv_timer_avp">
850
+	<section id="tm.p.fr_inv_timer_avp">
850 851
 		<title><varname>fr_inv_timer_avp</varname> (string)</title>
851 852
 		<para>
852 853
 			The value of fr_inv_timer timer can be overriden on
... ...
@@ -858,10 +860,6 @@ modparam("tm", "fr_timer_avp", "$avp(i:708)")
858 858
 			configured in <varname>fr_inv_timer</varname> parameter for the
859 859
 			current transaction.
860 860
 		</para>
861
-		<para>
862
-			The value of this parameter is the the name of the AVP to be
863
-			checked, without the $ character or "$avp" prefix.
864
-		</para>
865 861
 		<note><para>
866 862
 			The value of the AVP is expected to be expressed in
867 863
 			<emphasis>seconds</emphasis> and not milliseconds (unlike the rest
... ...
@@ -887,22 +885,23 @@ modparam("tm", "fr_timer_avp", "$avp(i:708)")
887 887
 			<title>Set <varname>fr_inv_timer_avp</varname> parameter</title>
888 888
 			<programlisting>
889 889
 ...
890
-modparam("tm", "fr_inv_timer_avp", "my_fr_inv_timer")
891
-# K mode
890
+# Kamailio mode
892 891
 modparam("tm", "fr_inv_timer_avp", "$avp(my_fr_inv_timer)")
892
+# Old SER mode
893
+modparam("tm", "fr_inv_timer_avp", "my_fr_inv_timer")
893 894
 ...
894 895
 			</programlisting>
895 896
 		</example>
896 897
 	</section>
897 898
 
898
-	<section id="unmatched_cancel">
899
+	<section id="tm.p.unmatched_cancel">
899 900
 		<title><varname>unmatched_cancel</varname> (string)</title>
900 901
 		<para>
901 902
 			This parameter selects between forwarding CANCELs
902 903
 			that do not match any transaction statefully (0,
903 904
 			default value), statelessly (1) or dropping them
904
-			(2). Note that the statefull forwarding has an
905
-			additional hidden advantage: tm will be able to
905
+			(2). Note that the stateful forwarding has an
906
+			additional hidden advantage: the tm module will be able to
906 907
 			recognize INVITEs that arrive after their CANCEL.
907 908
 			Note also that this feature could be used to try
908 909
 			a memory exhaustion DOS attack against a proxy that
... ...
@@ -925,11 +924,11 @@ modparam("tm", "unmatched_cancel", "2")
925 925
 		</example>
926 926
 	</section>
927 927
 
928
-	<section id="ruri_matching">
928
+	<section id="tm.p.ruri_matching">
929 929
 	<title><varname>ruri_matching</varname> (integer)</title>
930 930
 	<para>
931
-		If set it will also try to match the request uri  when doing
932
-		pre-3261 transaction matching (the via branch parameter does
931
+		If set the TM module will try to match the request URI when doing
932
+		SIP 1.0 (pre-RFC 3261) transaction matching (the "Via" header branch parameter does
933 933
 		not contain the 3261 cookie).
934 934
 	</para>
935 935
 	<para>
... ...
@@ -955,11 +954,11 @@ modparam("tm", "ruri_matching", 1)
955 955
 	</example>
956 956
 	</section>
957 957
 
958
-	<section id="via1_matching">
958
+	<section id="tm.p.via1_matching">
959 959
 	<title><varname>via1_matching</varname> (integer)</title>
960 960
 	<para>
961
-		If set it will also try to match the topmost via when doing
962
-		pre-3261 transaction matching (the via branch parameter does
961
+		If set the TM module will try to match the topmost "Via" header when doing
962
+		SIP 1.0 (pre-RFC 3261) transaction matching (the "Via" header branch parameter does
963 963
 		not contain the 3261 cookie).
964 964
 	</para>
965 965
 	<para>
... ...
@@ -985,16 +984,16 @@ modparam("tm", "via1_matching", 1)
985 985
 	</example>
986 986
 	</section>
987 987
 
988
-	<section id="callid_matching">
988
+	<section id="tm.p.callid_matching">
989 989
 	<title><varname>callid_matching</varname> (integer)</title>
990 990
 	<para>
991
-		If set it will also try to match the callid when doing
991
+		If set the TM module will try to match the callid when doing
992 992
 		transaction matching.
993 993
 	</para>
994 994
 	<para>
995 995
 		Turn on if you don't want replies/requests from broken clients who
996 996
 		send a mangled Call-ID to match the transaction. For example when
997
-		the other side won't recognise the response anyway because of changed
997
+		the other side won't recognise the response anyway because of a changed
998 998
 		Call-ID, this setting will prevent accounting records to be created
999 999
 		or failure_route to be skipped.
1000 1000
 	</para>
... ...
@@ -1017,7 +1016,7 @@ modparam("tm", "callid_matching", 1)
1017 1017
 	</example>
1018 1018
 	</section>
1019 1019
 
1020
-	<section id="pass_provisional_replies">
1020
+	<section id="tm.p.pass_provisional_replies">
1021 1021
 	<title><varname>pass_provisional_replies</varname> (integer)</title>
1022 1022
 	<para>
1023 1023
 		If set, TMCB_LOCAL_REPONSE_OUT tm registered callbacks will be called
... ...
@@ -1043,7 +1042,7 @@ modparam("tm", "pass_provisional_replies", 1)
1043 1043
 	</example>
1044 1044
 	</section>
1045 1045
 
1046
-	<section id="default_code">
1046
+	<section id="tm.p.default_code">
1047 1047
 	<title><varname>default_code</varname> (integer)</title>
1048 1048
 	<para>
1049 1049
 		Default response code sent by <function>t_reply()</function> if it
... ...
@@ -1069,7 +1068,7 @@ modparam("tm", "default_code", 501)
1069 1069
 	</example>
1070 1070
 	</section>
1071 1071
 
1072
-	<section id="default_reason">
1072
+	<section id="tm.p.default_reason">
1073 1073
 	<title><varname>default_reason</varname> (string)</title>
1074 1074
 	<para>
1075 1075
 		Default SIP reason phrase sent by <function>t_reply()</function> if it
... ...
@@ -1094,15 +1093,15 @@ modparam("tm", "default_reason", "Unknown reason")
1094 1094
 	</example>
1095 1095
 	</section>
1096 1096
 
1097
-	<section id="disable_6xx_block">
1097
+	<section id="tm.p.disable_6xx_block">
1098 1098
 	<title><varname>disable_6xx_block</varname> (integer)</title>
1099 1099
 	<para>
1100
-		If set tm will treat all the 6xx replies like normal replies 
1101
-		(warning: this would be non-rfc conformant behaviour).
1100
+		If set the TM module will treat all the 6xx replies like normal replies 
1101
+		(warning: this would be non-RFC conformant behaviour).
1102 1102
 	</para>
1103 1103
 	<para>
1104 1104
 		If not set (default) receiving a 6xx will cancel all the running
1105
-		parallel branches, will stop dns failover and forking. However
1105
+		parallel branches, will stop DNS failover and forking. However
1106 1106
 		serial forking using <function>append_branch()</function> in the
1107 1107
 		<function>failure_route</function> will still work.
1108 1108
 	</para>
... ...
@@ -1132,18 +1131,18 @@ modparam("tm", "disable_6xx_block", 1)
1132 1132
 	</example>
1133 1133
 	</section>
1134 1134
 
1135
-<section id="local_ack_mode">
1135
+	<section id="tm.p.local_ack_mode">
1136 1136
 	<title><varname>local_ack_mode</varname> (integer)</title>
1137 1137
 	<para>
1138
-		It controls where locally generated ACKs for 2xx replies to local
1138
+		This setting controls where locally generated ACKs for 2xx replies to local
1139 1139
 		transactions (transactions created via <function>t_uac*()</function>
1140
-		either thorugh the tm api or via RPC/mi/fifo) are sent.
1140
+		either through the TM api or via RPC/mi/fifo) are sent.
1141 1141
 	</para>
1142 1142
 	<para> It has 3 possible values:</para>
1143 1143
 	<itemizedlist>
1144 1144
 		<listitem><para>
1145 1145
 		<emphasis>0</emphasis> - the ACK destination is choosen according to
1146
-		the rfc: the next hop is found using the contact and the route set and
1146
+		the RFC: the next hop is found using the contact and the route set and
1147 1147
 		then DNS resolution is used on it.
1148 1148
 		</para></listitem>
1149 1149
 		<listitem><para>
... ...
@@ -1156,12 +1155,12 @@ modparam("tm", "disable_6xx_block", 1)
1156 1156
 		</para></listitem>
1157 1157
 	</itemizedlist>
1158 1158
 	<note><para>
1159
-	Mode 1 and 2 break the rfc, but are useful to deal with some simple UAs
1160
-	behind the NAT cases (no different routing for the ACK and the contact 
1159
+	Mode 1 and 2 does not follow RFC 3261, but are useful to deal with some simple UAs
1160
+	behind a NAT (no different routing for the ACK and the contact 
1161 1161
 	contains an address behind the NAT).
1162 1162
 	</para></note>
1163 1163
 	<para>
1164
-		The default value is 0 (rfc conformant behaviour).
1164
+		The default value is 0 (RFC conformant behaviour).
1165 1165
 	</para>
1166 1166
 	<para>
1167 1167
 		Can be set at runtime, e.g.:
... ...
@@ -1179,10 +1178,10 @@ modparam("tm", "local_ack_mode", 1)
1179 1179
 	</example>
1180 1180
 	</section>
1181 1181
 	
1182
-	<section id="failure_reply_mode">
1182
+	<section id="tm.p.failure_reply_mode">
1183 1183
 	<title><varname>failure_reply_mode</varname> (integer)</title>
1184 1184
 	<para>
1185
-		It controls how branches are managed and replies are selected for
1185
+		This parameter controls how branches are managed and replies are selected for
1186 1186
 		failure_route handling: keep all, drop all, drop last branches in
1187 1187
 		SIP serial forking handling.
1188 1188
 	</para>
... ...
@@ -1199,7 +1198,7 @@ modparam("tm", "local_ack_mode", 1)
1199 1199
 		the redirection in failure route, sent to a new destination and this
1200 1200
 		one timeout, you will get again the 3xx). Use t_drop_replies() on per
1201 1201
 		transaction fashion to control the behavior you want. It is the
1202
-		default behaviour comming from SER 2.1.x.
1202
+		default behaviour coming from SER 2.1.x.
1203 1203
 		</para></listitem>
1204 1204
 		<listitem><para>
1205 1205
 		<emphasis>1</emphasis> - all branches are discarded by default. You
... ...
@@ -1360,7 +1359,7 @@ modparam("tm", "remap_503_500", 0)
1360 1360
 	<section id="tm.p.failure_exec_mode">
1361 1361
 		<title><varname>failure_exec_mode</varname> (boolean)</title>
1362 1362
 		<para>
1363
-			Add local failed branches in timer to be cosidered for failure
1363
+			Add local failed branches in timer to be considered for failure
1364 1364
 			routing blocks. If disabled, relay functions will return false
1365 1365
 			in case the branch could not be forwarded (default behaviour
1366 1366
 			before v4.1.0).
... ...
@@ -1383,17 +1382,17 @@ modparam("tm", "failure_exec_mode", 1)
1383 1383
 		<title><varname>dns_reuse_rcv_socket</varname> (boolean)</title>
1384 1384
 		<para>
1385 1385
 			Control reuse of the receive socket for additional branches added
1386
-			by dns failover. If set to 1, the receive socket is used for
1386
+			by <acronym>DNS</acronym> failover. If set to 1, the receive socket is used for
1387 1387
 			sending out the new branches, unless the socket is forced
1388 1388
 			explicitely in configuration file. If set to 0, selected socket
1389
-			is done depending on value of global parameter mhomed (if mhomed=0,
1389
+			is done depending on value of global parameter "mhomed" (if mhomed=0,
1390 1390
 			then the first listen socket is used, otherwise the socket is
1391 1391
 			selected based on routing rules).
1392 1392
 		</para>
1393 1393
 		<para>
1394
-			Do enable it with caution, it might create troubles on dns results
1395
-			with different transport layer. Better let it disabled and enable
1396
-			mhomed.
1394
+			Do enable it with caution, it might create troubles on DNS results
1395
+			with different transport layer. Better let it be disabled and enable
1396
+			"mhomed".
1397 1397
 		</para>
1398 1398
 		<para>
1399 1399
 			Default value is 0 (disabled).