Browse code

- tm doc updated for 2.0: - fixed timer examples (use milliseconds instead of seconds) - see also, small typos - added missing doc for restart_fr_on_each_reply - noisy_ctimer doc update - regenerated README

Andrei Pelinescu-Onciul authored on 20/06/2008 17:37:22
Showing 4 changed files
... ...
@@ -20,10 +20,11 @@ Jiri Kuthan
20 20
         1.3.5. retr_timer1 (integer)
21 21
         1.3.6. retr_timer2 (integer)
22 22
         1.3.7. noisy_ctimer (integer)
23
-        1.3.8. unix_tx_timeout (integer)
24
-        1.3.9. aggregate_challenges (integer)
25
-        1.3.10. blst_methods_add (unsigned integer)
26
-        1.3.11. blst_methods_lookup (unsigned integer)
23
+        1.3.8. restart_fr_on_each_reply (integer)
24
+        1.3.9. unix_tx_timeout (integer)
25
+        1.3.10. aggregate_challenges (integer)
26
+        1.3.11. blst_methods_add (unsigned integer)
27
+        1.3.12. blst_methods_lookup (unsigned integer)
27 28
 
28 29
    1.4. Functions
29 30
 
... ...
@@ -105,9 +106,8 @@ Jiri Kuthan
105 106
 
106 107
 1.2. Known Issues
107 108
 
108
-     * We don't have authentication merging on forking.
109
-     * Local ACK/CANCELs copy'n'pastes Route and ignores deleted Routes.
110
-     * 6xx should be delayed.
109
+     * Local ACK/CANCELs copy'n'pastes Route and ignores deleted Routes
110
+       (solved in ser 2.1).
111 111
      * Possibly, performance could be improved by not parsing non-INVITEs,
112 112
        as they do not be replied with 100, and do not result in
113 113
        ACK/CANCELs, and other things which take parsing. However, we need
... ...
@@ -121,8 +121,6 @@ Jiri Kuthan
121 121
      * t_replicate should be done more cleanly--Vias, Routes, etc. should
122 122
        be removed from a message prior to replicating it (well, does not
123 123
        matter any longer so much as there is a new replication module).
124
-     * SNMP support (as nobody cares about SNMP, in particular for TM, I
125
-       will drop this item soon).
126 124
 
127 125
 1.3. Parameters
128 126
 
... ...
@@ -134,11 +132,13 @@ Jiri Kuthan
134 132
    Timer which hits if no final reply for a request or ACK for a negative
135 133
    INVITE reply arrives (in milliseconds).
136 134
 
137
-   Default value is 30 seconds.
135
+   Default value is 30000 ms (30 seconds).
136
+
137
+   See also: t_set_fr().
138 138
 
139 139
    Example 1. Set fr_timer parameter
140 140
 ...
141
-modparam("tm", "fr_timer", 10)
141
+modparam("tm", "fr_timer", 10000)
142 142
 ...
143 143
 
144 144
 1.3.2. fr_inv_timer (integer)
... ...
@@ -146,38 +146,43 @@ modparam("tm", "fr_timer", 10)
146 146
    Timer which hits if no final reply for an INVITE arrives after a
147 147
    provisional message was received (in milliseconds).
148 148
 
149
-   Default value is 120 seconds.
149
+   Note: this timer can be restarted when a provisional response is
150
+   received. For more details see restart_fr_on_each_reply.
151
+
152
+   Default value is 120000 ms (120 seconds).
153
+
154
+   See also: t_set_fr().
150 155
 
151 156
    Example 2. Set fr_inv_timer parameter
152 157
 ...
153
-modparam("tm", "fr_inv_timer", 200)
158
+modparam("tm", "fr_inv_timer", 180000)
154 159
 ...
155 160
 
156 161
 1.3.3. wt_timer (integer)
157 162
 
158 163
    Time for which a transaction stays in memory to absorb delayed messages
159
-   after it completed; also, when this timer hits, retransmission of local
160
-   cancels is stopped (a puristic but complex behavior would be not to
161
-   enter wait state until local branches are finished by a final reply or
162
-   FR timer--we simplified).
164
+   after it completed (in milliseconds); also, when this timer hits,
165
+   retransmission of local cancels is stopped (a puristic but complex
166
+   behavior would be not to enter wait state until local branches are
167
+   finished by a final reply or FR timer--we simplified).
163 168
 
164
-   Default value is 5 seconds.
169
+   Default value is 5000 ms (5 seconds).
165 170
 
166 171
    Example 3. Set wt_timer parameter
167 172
 ...
168
-modparam("tm", "wt_timer", 10)
173
+modparam("tm", "wt_timer", 1000)
169 174
 ...
170 175
 
171 176
 1.3.4. delete_timer (integer)
172 177
 
173 178
    Time after which a to-be-deleted transaction currently ref-ed by a
174
-   process will be tried to be deleted again.
179
+   process will be tried to be deleted again (in milliseconds).
175 180
 
176 181
    Default value is 200 milliseconds.
177 182
 
178 183
    Example 4. Set delete_timer parameter
179 184
 ...
180
-modparam("tm", "delete_timer", 5)
185
+modparam("tm", "delete_timer", 100)
181 186
 ...
182 187
 
183 188
 1.3.5. retr_timer1 (integer)
... ...
@@ -206,12 +211,15 @@ modparam("tm", "retr_timer2", 2000)
206 211
 
207 212
 1.3.7. noisy_ctimer (integer)
208 213
 
209
-   If set, on FR timer INVITE transactions will be explicitly canceled if
210
-   possible, silently dropped otherwise. Preferably, it is turned off to
211
-   allow very long ringing. This behavior is overridden if a request is
212
-   forked, or some functionality explicitly turned it off for a
213
-   transaction (like acc does to avoid unaccounted transactions due to
214
-   expired timer).
214
+   If set, INVITE transactions that time-out (FR INV timer) will be always
215
+   replied. If it's not set, the transaction has only one branch and no
216
+   response was ever received on this branch, it will be silently dropped
217
+   (no 408 reply will be generated) This behavior is overridden if a
218
+   request is forked, the transaction has a failure route or callback, or
219
+   some functionality explicitly turned it on for a transaction (like acc
220
+   does to avoid unaccounted transactions due to expired timer). Turn this
221
+   off only if you know the client UACs will timeout and their timeout
222
+   interval for INVITEs is lower or equal than tm's fr_inv_timer.
215 223
 
216 224
    Default value is 0 (false).
217 225
 
... ...
@@ -220,7 +228,29 @@ modparam("tm", "retr_timer2", 2000)
220 228
 modparam("tm", "noisy_ctimer", 1)
221 229
 ...
222 230
 
223
-1.3.8. unix_tx_timeout (integer)
231
+1.3.8. restart_fr_on_each_reply (integer)
232
+
233
+   If set (default), the fr_inv_timer for an INVITE transaction will be
234
+   restarted for each provisional reply received (rfc3261 mandated
235
+   behaviour). If not set, the fr_inv_timer will be restarted only for the
236
+   first provisional replies and for increasing replies greater or equal
237
+   180 (e.g. 180, 181, 182, 185, ...).
238
+
239
+   Setting it to 0 is especially useful when dealing with bad UAs that
240
+   continuously retransmit 180s, not allowing the transaction to timeout
241
+   (and thus making impossible the implementation of certain services,
242
+   like automatic voicemail after x seconds).
243
+
244
+   Default value is 1 (on).
245
+
246
+   See also: fr_inv_timer.
247
+
248
+   Example 8. Set restart_fr_on_each_reply parameter
249
+...
250
+modparam("tm", "restart_fr_on_each_reply", 0)
251
+...
252
+
253
+1.3.9. unix_tx_timeout (integer)
224 254
 
225 255
    Unix socket transmission timeout, in milliseconds.
226 256
 
... ...
@@ -230,12 +260,12 @@ modparam("tm", "noisy_ctimer", 1)
230 260
 
231 261
    The default value is 500 milliseconds.
232 262
 
233
-   Example 8. Set unix_tx_timeout parameter
263
+   Example 9. Set unix_tx_timeout parameter
234 264
 ...
235 265
 modparam("tm", "unix_tx_timeout", 250)
236 266
 ...
237 267
 
238
-1.3.9. aggregate_challenges (integer)
268
+1.3.10. aggregate_challenges (integer)
239 269
 
240 270
    If set (default), the final reply is a 401 or a 407 and more then one
241 271
    branch received a 401 or 407, then all the WWW-Authenticate and
... ...
@@ -247,12 +277,12 @@ modparam("tm", "unix_tx_timeout", 250)
247 277
 
248 278
    Default value is 1 (required by rfc3261).
249 279
 
250
-   Example 9. Set aggregate_challenges parameter
280
+   Example 10. Set aggregate_challenges parameter
251 281
 ...
252 282
 modparam("tm", "aggregate_challenges", 0)
253 283
 ...
254 284
 
255
-1.3.10. blst_methods_add (unsigned integer)
285
+1.3.11. blst_methods_add (unsigned integer)
256 286
 
257 287
    Bitmap of method types that trigger blacklisting on transaction
258 288
    timeouts. (This setting has no effect on blacklisting because of send
... ...
@@ -271,13 +301,13 @@ modparam("tm", "aggregate_challenges", 0)
271 301
 
272 302
    The default value is 1, only INVITEs trigger blacklisting
273 303
 
274
-   Example 10. Set blst_methods_add parameter
304
+   Example 11. Set blst_methods_add parameter
275 305
 ...
276 306
 # INVITEs and REGISTERs trigger blacklisting
277 307
 modparam("tm", "blst_methods_add", 33)
278 308
 ...
279 309
 
280
-1.3.11. blst_methods_lookup (unsigned integer)
310
+1.3.12. blst_methods_lookup (unsigned integer)
281 311
 
282 312
    Bitmap of method types that are looked-up in the blacklist before
283 313
    statefull forwarding. See also blst_methods_add
... ...
@@ -285,7 +315,7 @@ modparam("tm", "blst_methods_add", 33)
285 315
    The default value is 4294967287, every method type except BYE. (We try
286 316
    to deliver BYEs no matter what)
287 317
 
288
-   Example 11. Set blst_methods_lookup parameter
318
+   Example 12. Set blst_methods_lookup parameter
289 319
 ...
290 320
 # lookup only INVITEs
291 321
 modparam("tm", "blst_methods_lookup", 1)
... ...
@@ -307,7 +337,7 @@ modparam("tm", "blst_methods_lookup", 1)
307 337
      * ip - IP address where the message should be sent.
308 338
      * port - Port number.
309 339
 
310
-   Example 12. t_relay_to_udp usage
340
+   Example 13. t_relay_to_udp usage
311 341
 ...
312 342
 t_relay_to_udp("1.2.3.4", "5060");
313 343
 ...
... ...
@@ -320,7 +350,7 @@ t_relay_to_udp("1.2.3.4", "5060");
320 350
    still want to send a negative reply upstream statelessly not to leave
321 351
    upstream UAC in lurch.
322 352
 
323
-   Example 13. t_relay usage
353
+   Example 14. t_relay usage
324 354
 ...
325 355
 if (!t_relay())
326 356
 {
... ...
@@ -349,7 +379,7 @@ if (!t_relay())
349 379
    Meaning of the parameters is as follows:
350 380
      * failure_route - Failure route block to be called.
351 381
 
352
-   Example 14. t_on_failure usage
382
+   Example 15. t_on_failure usage
353 383
 ...
354 384
 route {
355 385
     t_on_failure("1");
... ...
@@ -375,7 +405,7 @@ failure_route[1] {
375 405
    Meaning of the parameters is as follows:
376 406
      * onreply_route - Onreply route block to be called.
377 407
 
378
-   Example 15. t_on_reply usage
408
+   Example 16. t_on_reply usage
379 409
 ...
380 410
 loadmodule "/usr/local/lib/ser/modules/nathelper.so"
381 411
 ...
... ...
@@ -407,7 +437,7 @@ es');
407 437
    Meaning of the parameters is as follows:
408 438
      * branch_route - branch route block to be called.
409 439
 
410
-   Example 16. t_on_branch usage
440
+   Example 17. t_on_branch usage
411 441
 ...
412 442
 route {
413 443
         t_on_branch("1");
... ...
@@ -425,7 +455,7 @@ branch_route[1] {
425 455
    Similarly to t_fork_to, it extends destination set by a new entry. The
426 456
    difference is that current URI is taken as new entry.
427 457
 
428
-   Example 17. append_branch usage
458
+   Example 18. append_branch usage
429 459
 ...
430 460
 set_user("john");
431 461
 t_fork();
... ...
@@ -440,7 +470,7 @@ t_relay();
440 470
    the only way a script can add a new transaction in an atomic way.
441 471
    Typically, it is used to deploy a UAS.
442 472
 
443
-   Example 18. t_newtran usage
473
+   Example 19. t_newtran usage
444 474
 ...
445 475
 if (t_newtran()) {
446 476
     log("UAS logic");
... ...
@@ -459,7 +489,7 @@ if (t_newtran()) {
459 489
      * code - Reply code number.
460 490
      * reason_phrase - Reason string.
461 491
 
462
-   Example 19. t_reply usage
492
+   Example 20. t_reply usage
463 493
 ...
464 494
 t_reply("404", "Not found");
465 495
 ...
... ...
@@ -472,7 +502,7 @@ t_reply("404", "Not found");
472 502
    none was found. However this is safely (atomically) done using
473 503
    t_newtran.
474 504
 
475
-   Example 20. t_lookup_request usage
505
+   Example 21. t_lookup_request usage
476 506
 ...
477 507
 if (t_lookup_request()) {
478 508
     ...
... ...
@@ -483,7 +513,7 @@ if (t_lookup_request()) {
483 513
 
484 514
    Retransmits a reply sent previously by UAS transaction.
485 515
 
486
-   Example 21. t_retransmit_reply usage
516
+   Example 22. t_retransmit_reply usage
487 517
 ...
488 518
 t_retransmit_reply();
489 519
 ...
... ...
@@ -493,7 +523,7 @@ t_retransmit_reply();
493 523
    Remove transaction from memory (it will be first put on a wait timer to
494 524
    absorb delayed messages).
495 525
 
496
-   Example 22. t_release usage
526
+   Example 23. t_release usage
497 527
 ...
498 528
 t_release();
499 529
 ...
... ...
@@ -506,7 +536,7 @@ t_release();
506 536
      * ip - IP address where the message should be sent.
507 537
      * port - Port number.
508 538
 
509
-   Example 23. t_forward_nonack usage
539
+   Example 24. t_forward_nonack usage
510 540
 ...
511 541
 t_forward_nonack("1.2.3.4", "5060");
512 542
 ...
... ...
@@ -517,7 +547,7 @@ t_forward_nonack("1.2.3.4", "5060");
517 547
    transaction. If the transaction is already created (e.g called after
518 548
    t_relay() or in an onreply_route) all the branches will have their
519 549
    final response timeout updated on-the-fly. If one of the parameters is
520
-   0, it's value won't be changed.
550
+   0, its value won't be changed.
521 551
 
522 552
    Meaning of the parameters is as follows:
523 553
      * fr_inv_timeout - new final response timeout (in milliseconds) for
... ...
@@ -526,7 +556,9 @@ t_forward_nonack("1.2.3.4", "5060");
526 556
        non-INVITE transaction, or INVITEs which haven't received yet a
527 557
        provisional response. See also fr_timer.
528 558
 
529
-   Example 24. t_set_fr usage
559
+   See also: fr_timer, fr_inv_timer.
560
+
561
+   Example 25. t_set_fr usage
530 562
 ...
531 563
 route {
532 564
         t_set_fr(10000); # set only fr invite timeout to 10s
... ...
@@ -547,7 +579,7 @@ branch_route[1] {
547 579
    Returns true if the failure route is executed for a branch that did
548 580
    timeout. It can be used only from the failure_route.
549 581
 
550
-   Example 25. t_branch_timeout usage
582
+   Example 26. t_branch_timeout usage
551 583
 ...
552 584
 failure_route[0]{
553 585
         if (t_branch_timeout()){
... ...
@@ -562,7 +594,7 @@ failure_route[0]{
562 594
    receive at least one reply in the past (the "current" reply is not
563 595
    taken into account). It can be used only from the failure_route.
564 596
 
565
-   Example 26. t_branch_replied usage
597
+   Example 27. t_branch_replied usage
566 598
 ...
567 599
 failure_route[0]{
568 600
         if (t_branch_timeout()){
... ...
@@ -579,7 +611,7 @@ failure_route[0]{
579 611
    Returns true if at least one of the current transactions branches did
580 612
    timeout.
581 613
 
582
-   Example 27. t_any_timeout usage
614
+   Example 28. t_any_timeout usage
583 615
 ...
584 616
 failure_route[0]{
585 617
         if (!t_branch_timeout()){
... ...
@@ -596,7 +628,7 @@ failure_route[0]{
596 628
    receive some reply in the past. If called from a failure or onreply
597 629
    route, the "current" reply is not taken into account.
598 630
 
599
-   Example 28. t_any_replied usage
631
+   Example 29. t_any_replied usage
600 632
 ...
601 633
 onreply_route[0]{
602 634
         if (!t_any_replied()){
... ...
@@ -609,7 +641,7 @@ onreply_route[0]{
609 641
 
610 642
    Returns true if the current transaction was canceled.
611 643
 
612
-   Example 29. t_is_canceled usage
644
+   Example 30. t_is_canceled usage
613 645
 ...
614 646
 failure_route[0]{
615 647
         if (t_is_canceled()){
... ...
@@ -375,7 +375,7 @@ t_forward_nonack("1.2.3.4", "5060");
375 375
 		transaction. If the transaction is already created (e.g called after
376 376
 		 <function>t_relay()</function> or in an onreply_route) all the
377 377
 		 branches will have their final response timeout updated on-the-fly.
378
-		If one of the parameters is 0, it's value won't be changed.
378
+		If one of the parameters is 0, its value won't be changed.
379 379
 	</para>
380 380
 	<para>Meaning of the parameters is as follows:</para>
381 381
 	<itemizedlist>
... ...
@@ -391,6 +391,11 @@ t_forward_nonack("1.2.3.4", "5060");
391 391
 		</para>
392 392
 	    </listitem>
393 393
 	</itemizedlist>
394
+	<para>
395
+		See also: 
396
+			<varname>fr_timer</varname>,
397
+			<varname>fr_inv_timer</varname>.
398
+	</para>
394 399
 	<example>
395 400
 	    <title><function>t_set_fr</function> usage</title>
396 401
 	    <programlisting>
... ...
@@ -21,13 +21,16 @@
21 21
 	    negative INVITE reply arrives (in milliseconds).
22 22
 	</para>
23 23
 	<para>
24
-	    Default value is 30 seconds.
24
+	    Default value is 30000 ms (30 seconds).
25
+	</para>
26
+	<para>
27
+		See also: <function>t_set_fr()</function>.
25 28
 	</para>
26 29
 	<example>
27 30
 	    <title>Set <varname>fr_timer</varname> parameter</title>
28 31
 	    <programlisting>
29 32
 ...
30
-modparam("tm", "fr_timer", 10)
33
+modparam("tm", "fr_timer", 10000)
31 34
 ...
32 35
 	    </programlisting>
33 36
 	</example>
... ...
@@ -40,13 +43,21 @@ modparam("tm", "fr_timer", 10)
40 43
 	    provisional message was received (in milliseconds).
41 44
 	</para>
42 45
 	<para>
43
-	    Default value is 120 seconds.
46
+	</para>
47
+		Note: this timer can be restarted when a provisional response is
48
+		received. For more details see
49
+		<varname>restart_fr_on_each_reply</varname>.
50
+	<para>
51
+	    Default value is 120000 ms (120 seconds).
52
+	</para>
53
+	<para>
54
+		See also: <function>t_set_fr()</function>.
44 55
 	</para>
45 56
 	<example>
46 57
 	    <title>Set <varname>fr_inv_timer</varname> parameter</title>
47 58
 	    <programlisting>
48 59
 ...
49
-modparam("tm", "fr_inv_timer", 200)
60
+modparam("tm", "fr_inv_timer", 180000)
50 61
 ...
51 62
 	    </programlisting>
52 63
 	</example>
... ...
@@ -56,19 +67,20 @@ modparam("tm", "fr_inv_timer", 200)
56 67
 	<title><varname>wt_timer</varname> (integer)</title>
57 68
 	<para>
58 69
 	    Time for which a transaction stays in memory to absorb delayed
59
-	    messages after it completed; also, when this timer hits,
70
+	    messages after it completed (in milliseconds); also, when this 
71
+	    timer hits,
60 72
 	    retransmission of local cancels is stopped (a puristic but complex
61 73
 	    behavior would be not to enter wait state until local branches are
62 74
 	    finished by a final reply or FR timer--we simplified).
63 75
 	</para>
64 76
 	<para>
65
-	    Default value is 5 seconds.
77
+	    Default value is 5000 ms (5 seconds).
66 78
 	</para>
67 79
 	<example>
68 80
 	    <title>Set <varname>wt_timer</varname> parameter</title>
69 81
 	    <programlisting>
70 82
 ...
71
-modparam("tm", "wt_timer", 10)
83
+modparam("tm", "wt_timer", 1000)
72 84
 ...
73 85
 	    </programlisting>
74 86
 	</example>
... ...
@@ -78,7 +90,7 @@ modparam("tm", "wt_timer", 10)
78 90
 	<title><varname>delete_timer</varname> (integer)</title>
79 91
 	<para>
80 92
 	    Time after which a to-be-deleted transaction currently ref-ed by a
81
-	    process will be tried to be deleted again.
93
+	    process will be tried to be deleted again (in milliseconds).
82 94
 	</para>
83 95
 	<para>
84 96
 	    Default value is 200 milliseconds.
... ...
@@ -87,7 +99,7 @@ modparam("tm", "wt_timer", 10)
87 99
 	    <title>Set <varname>delete_timer</varname> parameter</title>
88 100
 	    <programlisting>
89 101
 ...
90
-modparam("tm", "delete_timer", 5)
102
+modparam("tm", "delete_timer", 100)
91 103
 ...
92 104
 	    </programlisting>
93 105
 	</example>
... ...
@@ -135,12 +147,17 @@ modparam("tm", "retr_timer2", 2000)
135 147
     <section id="noisy_ctimer">
136 148
 	<title><varname>noisy_ctimer</varname> (integer)</title>
137 149
 	<para>
138
-	    If set, on FR timer INVITE transactions will be explicitly canceled
139
-	    if possible, silently dropped otherwise. Preferably, it is turned
140
-	    off to allow very long ringing.  This behavior is overridden if a
141
-	    request is forked, or some functionality explicitly turned it off
142
-	    for a transaction (like acc does to avoid unaccounted transactions
143
-	    due to expired timer).
150
+	    If set, INVITE transactions that time-out (FR INV timer) will be 
151
+		always replied. If it's not set, the transaction has only one
152
+		branch and no response was ever received on this branch, it 
153
+		will be silently dropped (no 408 reply will be generated)
154
+		This behavior is overridden if a request is forked, the transaction
155
+		 has a failure route or callback, or some functionality explicitly 
156
+		 turned it on  for a transaction (like acc does to avoid unaccounted
157
+		 transactions due to expired timer).
158
+		Turn this off only if you know the client UACs will timeout and their
159
+		timeout interval for INVITEs is lower or equal than tm's
160
+		<varname>fr_inv_timer</varname>.
144 161
 	</para>
145 162
 	<para>
146 163
 	    Default value is 0 (false).
... ...
@@ -155,6 +172,39 @@ modparam("tm", "noisy_ctimer", 1)
155 172
 	</example>
156 173
     </section>
157 174
 
175
+	<section id="restart_fr_on_each_reply">
176
+	<title><varname>restart_fr_on_each_reply</varname> (integer)</title>
177
+	<para>
178
+		If set (default), the <varname>fr_inv_timer</varname> for an INVITE
179
+		transaction will be restarted for each provisional reply received
180
+		(rfc3261 mandated behaviour). If not set, the 
181
+		<varname>fr_inv_timer</varname> will be restarted only for the first
182
+		provisional replies and for increasing replies greater or equal 180
183
+		(e.g. 180, 181, 182, 185, ...).
184
+	</para>
185
+	<para>
186
+		Setting it to 0 is especially useful when dealing with bad UAs that
187
+		continuously retransmit 180s, not allowing the transaction to timeout 
188
+		(and thus making impossible the implementation of certain services,
189
+		like automatic voicemail after x seconds).
190
+	</para>
191
+	<para>
192
+		Default value is 1 (on).
193
+	</para>
194
+	<para>
195
+		See also: <varname>fr_inv_timer</varname>.
196
+	</para>
197
+	<example>
198
+		<title>Set <varname>restart_fr_on_each_reply</varname>
199
+				parameter</title>
200
+		<programlisting>
201
+...
202
+modparam("tm", "restart_fr_on_each_reply", 0)
203
+...
204
+	    </programlisting>
205
+	</example>
206
+	</section>
207
+
158 208
 	<section id="unix_tx_timeout">
159 209
 	<title><varname>unix_tx_timeout</varname> (integer)</title>
160 210
 	<para>
... ...
@@ -94,20 +94,10 @@
94 94
     <section id="tm.known_issues">
95 95
 	<title>Known Issues</title>
96 96
 	<itemizedlist>
97
-	    <listitem>
98
-		<para>
99
-		    We don't have authentication merging on forking.
100
-		</para>
101
-	    </listitem>
102 97
 	    <listitem>
103 98
 		<para>
104 99
 		    Local ACK/CANCELs copy'n'pastes Route and ignores deleted
105
-		    Routes.
106
-		</para>
107
-	    </listitem>
108
-	    <listitem>
109
-		<para>
110
-		    6xx should be delayed.
100
+		    Routes (solved in ser 2.1).
111 101
 		</para>
112 102
 	    </listitem>
113 103
 	    <listitem>
... ...
@@ -137,13 +127,6 @@
137 127
 		    longer so much as there is a new replication module).
138 128
 		</para>
139 129
 	    </listitem>
140
-	    <listitem>
141
-		<para>
142
-		    <acronym>SNMP</acronym> support (as nobody cares about
143
-		    <acronym>SNMP</acronym>, in particular for
144
-		    <acronym>TM</acronym>, I will drop this item soon).
145
-		</para>
146
-	    </listitem>
147 130
 	</itemizedlist>
148 131
     </section>
149 132