Browse code

- pre-release documentation update

Jan Janak authored on 22/06/2005 23:12:08
Showing 2 changed files
... ...
@@ -32,23 +32,46 @@ Jiri Kuthan
32 32
               1.3.7. retr_timer1p3 (integer)
33 33
               1.3.8. retr_timer2 (integer)
34 34
               1.3.9. noisy_ctimer (integer)
35
+              1.3.10. ruri_matching (integer)
36
+              1.3.11. via1_matching (integer)
37
+              1.3.12. uac_from (string)
38
+              1.3.13. unix_tx_timeout (integer)
39
+              1.3.14. restart_fr_on_each_reply (integer)
40
+              1.3.15. fr_timer_avp (string)
41
+              1.3.16. fr_inv_timer_avp (string)
42
+              1.3.17. tw_append (string)
35 43
 
36 44
         1.4. Exported Functions
37 45
 
38 46
               1.4.1. t_relay_to_udp(ip, port), t_relay_to_tcp(ip,
39
-                      port)
47
+                      port), t_relay_to_tls(ip, port)
40 48
 
41 49
               1.4.2. t_relay()
42
-              1.4.3. t_on_negative(reply_route)
43
-              1.4.4. append_branch()
44
-              1.4.5. t_newtran()
45
-              1.4.6. t_reply(code, reason_phrase)
46
-              1.4.7. t_lookup_request()
47
-              1.4.8. t_retransmit_reply()
48
-              1.4.9. t_release()
49
-              1.4.10. t_forward_nonack(ip, port)
50
-              1.4.11. External Usage of TM
51
-              1.4.12. Known Issues
50
+              1.4.3. t_on_failure(reply_route)
51
+              1.4.4. t_on_failure(reply_route)
52
+              1.4.5. t_on_failure(reply_route)
53
+              1.4.6. t_on_reply(onreply_route)
54
+              1.4.7. t_check_status(regex)
55
+              1.4.8. t_write_req(fifo, application)
56
+              1.4.9. t_write_unix(socket, application)
57
+              1.4.10. append_branch()
58
+              1.4.11. t_newtran()
59
+              1.4.12. t_reply(code, reason_phrase)
60
+              1.4.13. t_lookup_request()
61
+              1.4.14. t_retransmit_reply()
62
+              1.4.15. t_release()
63
+              1.4.16. t_replicate(ip, port), t_replicate_udp(ip,
64
+                      port), t_replicate_tcp(ip, port),
65
+                      t_replicate_tls(ip, port)
66
+
67
+              1.4.17. t_forward_nonack(ip, port),
68
+                      t_forward_nonack_uri(),
69
+                      t_forward_nonack_udp(ip, port),
70
+                      t_forward_nonack_tcp(ip, port),
71
+                      t_forward_nonack_tls(ip, port)
72
+
73
+              1.4.18. External Usage of TM
74
+              1.4.19. Known Issues
52 75
 
53 76
    2. Developer's Guide
54 77
 
... ...
@@ -70,16 +93,21 @@ Jiri Kuthan
70 93
    1-7. Set retr_timer1p4 parameter
71 94
    1-8. Set retr_timer2 parameter
72 95
    1-9. Set noisy_ctimer parameter
73
-   1-10. t_relay_to_udp usage
74
-   1-11. t_relay usage
75
-   1-12. t_on_negative usage
76
-   1-13. append_branch usage
77
-   1-14. t_newtran usage
78
-   1-15. t_reply usage
79
-   1-16. t_lookup_request usage
80
-   1-17. t_retransmit_reply usage
81
-   1-18. t_release usage
82
-   1-19. t_forward_nonack usage
96
+   1-10. Set tw_append parameter
97
+   1-11. t_relay_to_udp usage
98
+   1-12. t_relay usage
99
+   1-13. t_on_failure usage
100
+   1-14. t_on_failure usage
101
+   1-15. t_on_failure usage
102
+   1-16. t_on_reply usage
103
+   1-17. t_check_status usage
104
+   1-18. append_branch usage
105
+   1-19. t_newtran usage
106
+   1-20. t_reply usage
107
+   1-21. t_lookup_request usage
108
+   1-22. t_retransmit_reply usage
109
+   1-23. t_release usage
110
+   1-24. t_forward_nonack usage
83 111
      _________________________________________________________
84 112
 
85 113
 Chapter 1. User's Guide
... ...
@@ -277,9 +305,108 @@ modparam("tm", "noisy_ctimer", 1)
277 305
 ...
278 306
      _________________________________________________________
279 307
 
308
+1.3.10. ruri_matching (integer)
309
+
310
+   The parameter controls whether the Request-URI should be
311
+   included in pre-RFC3261 transaction maching. When set 1 then
312
+   the Request-URI will be included, when set to 0 then it will
313
+   be not included.
314
+
315
+   Default value is 1 (include Request-URI). 
316
+     _________________________________________________________
317
+
318
+1.3.11. via1_matching (integer)
319
+
320
+   The parameter controls whether the topmost Via header field
321
+   should be included in pre-RFC3261 transaction maching. When
322
+   set 1 then the topmost Via header field will be included, when
323
+   set to 0 then it will be not included.
324
+
325
+   Default value is 1 (include topmost Via header field). 
326
+     _________________________________________________________
327
+
328
+1.3.12. uac_from (string)
329
+
330
+   This parameter allows to configure the URI that will be put in
331
+   the From header field of SIP request generated localy by the
332
+   UAC in tm module. This parameter is currently not used.
333
+
334
+   Default value is "sip:foo@foo.bar". 
335
+     _________________________________________________________
336
+
337
+1.3.13. unix_tx_timeout (integer)
338
+
339
+   Maximum timeout in seconds for the request sent over the unix
340
+   domain socket interface (using t_write_unix function). The
341
+   function will indicate failure if it does not manage to send
342
+   all the data within the interval configured by this parameter.
343
+
344
+   Default value is 2 seconds. 
345
+     _________________________________________________________
346
+
347
+1.3.14. restart_fr_on_each_reply (integer)
348
+
349
+   The parameter controls whether the FR timer will be restarted
350
+   on each provisional reply received.
351
+
352
+   Default value is 1 (yes). 
353
+     _________________________________________________________
354
+
355
+1.3.15. fr_timer_avp (string)
356
+
357
+   This parameter makes it possible to override the value of FR
358
+   (final reply) timer on per-transaction basis. TM module can
359
+   pick the value of the timer from an AVP. The name or ID of the
360
+   AVP can be configured by this parameter. If there is no such
361
+   AVP then the default value configured through fr_timer
362
+   parameter will be used.
363
+
364
+   Default value is "callee_fr_timer". 
365
+     _________________________________________________________
366
+
367
+1.3.16. fr_inv_timer_avp (string)
368
+
369
+   This parameter makes it possible to override the value of FR
370
+   Invite (final response for INVITE transactions) timer on
371
+   per-transaction basis. TM module can pick the value of the
372
+   timer from an AVP. The name or ID of the AVP can be configured
373
+   by this parameter. If there is no such AVP then the default
374
+   value configured through fr_inv_timer parameter will be used.
375
+
376
+   Default value is "callee_fr_inv_timer". 
377
+     _________________________________________________________
378
+
379
+1.3.17. tw_append (string)
380
+
381
+   This parameter configures additional information that can be
382
+   passed over the FIFO or unix domain socket interfaces by TM
383
+   module to another application. TM module can pass values of
384
+   AVPs, SIP message header fields, or the message body. Syntax
385
+   of the parameter is as follows:
386
+tw_append = name ':' element ( ';' element ) *
387
+element   = [ title '=' ] ( avp_val | hdr_val )
388
+element   = title '=' body_val
389
+avp_val   = "avp" '[' avp_spec ']'
390
+hdr_val   = "hdr" '[' hdr_name ']'
391
+body_val  = "msg[body]"
392
+
393
+   Default value is "". 
394
+
395
+   Example 1-10. Set tw_append parameter
396
+
397
+   Pass the value of callee_fr_timer AVP, the contents of Subject
398
+   header field, and the whole SIP message body to the
399
+   application over FIFO or unix domain socket interface.
400
+...
401
+modparam("tm", "tw_append", "params:avp[callee_fr_timer];hdr[Subject];b
402
+ody=msg[body]")
403
+...
404
+     _________________________________________________________
405
+
280 406
 1.4. Exported Functions
281 407
 
282
-1.4.1. t_relay_to_udp(ip, port), t_relay_to_tcp(ip, port)
408
+1.4.1. t_relay_to_udp(ip, port), t_relay_to_tcp(ip, port),
409
+t_relay_to_tls(ip, port)
283 410
 
284 411
    Relay a message statefully to a fixed destination. This along
285 412
    with t_relay is the function most users want to use--all other
... ...
@@ -292,7 +419,7 @@ modparam("tm", "noisy_ctimer", 1)
292 419
      * ip - IP address where the message should be sent.
293 420
      * port - Port number.
294 421
 
295
-   Example 1-10. t_relay_to_udp usage
422
+   Example 1-11. t_relay_to_udp usage
296 423
 ...
297 424
 t_relay_to_udp("1.2.3.4", "5060");
298 425
 ...
... ...
@@ -307,13 +434,95 @@ t_relay_to_udp("1.2.3.4", "5060");
307 434
    negative reply upstream statelessly not to leave upstream UAC
308 435
    in lurch.
309 436
 
310
-   Example 1-11. t_relay usage
437
+   Example 1-12. t_relay usage
311 438
 ...
312 439
 if (!t_relay()) { sl_reply_error(); break; };
313 440
 ...
314 441
      _________________________________________________________
315 442
 
316
-1.4.3. t_on_negative(reply_route)
443
+1.4.3. t_on_failure(reply_route)
444
+
445
+   Sets reply routing block, to which control is passed after a
446
+   transaction completed with a negative result but before
447
+   sending a final reply. In the referred block, you can either
448
+   start a new branch (good for services such as
449
+   forward_on_no_reply) or send a final reply on your own (good
450
+   for example for message silo, which received a negative reply
451
+   from upstream and wants to tell upstream "202 I will take care
452
+   of it"). Note that the set of command which are usable within
453
+   reply_routes is strictly limited to rewriting URI, initiating
454
+   new branches, logging, and sending stateful replies (t_reply).
455
+   Any other commands may result in unpredictable behavior and
456
+   possible server failure. Note that whenever reply_route is
457
+   entered, uri is reset to value which it had on relaying. If it
458
+   temporarily changed during a reply_route processing,
459
+   subsequent reply_route will ignore the changed value and use
460
+   again the original one.
461
+
462
+   Meaning of the parameters is as follows:
463
+
464
+     * reply_route - Reply route block to be called.
465
+
466
+   Example 1-13. t_on_failure usage
467
+...
468
+route {
469
+    t_on_failure("1");
470
+    t_relay();
471
+}
472
+
473
+failure_route[1] {
474
+    revert_uri();
475
+    setuser("voicemail");
476
+    append_branch();
477
+}
478
+...
479
+
480
+   See test/onr.cfg for a more complex example of combination of
481
+   serial with parallel forking.
482
+     _________________________________________________________
483
+
484
+1.4.4. t_on_failure(reply_route)
485
+
486
+   Sets reply routing block, to which control is passed after a
487
+   transaction completed with a negative result but before
488
+   sending a final reply. In the referred block, you can either
489
+   start a new branch (good for services such as
490
+   forward_on_no_reply) or send a final reply on your own (good
491
+   for example for message silo, which received a negative reply
492
+   from upstream and wants to tell upstream "202 I will take care
493
+   of it"). Note that the set of command which are usable within
494
+   reply_routes is strictly limited to rewriting URI, initiating
495
+   new branches, logging, and sending stateful replies (t_reply).
496
+   Any other commands may result in unpredictable behavior and
497
+   possible server failure. Note that whenever reply_route is
498
+   entered, uri is reset to value which it had on relaying. If it
499
+   temporarily changed during a reply_route processing,
500
+   subsequent reply_route will ignore the changed value and use
501
+   again the original one.
502
+
503
+   Meaning of the parameters is as follows:
504
+
505
+     * reply_route - Reply route block to be called.
506
+
507
+   Example 1-14. t_on_failure usage
508
+...
509
+route {
510
+    t_on_failure("1");
511
+    t_relay();
512
+}
513
+
514
+failure_route[1] {
515
+    revert_uri();
516
+    setuser("voicemail");
517
+    append_branch();
518
+}
519
+...
520
+
521
+   See test/onr.cfg for a more complex example of combination of
522
+   serial with parallel forking.
523
+     _________________________________________________________
524
+
525
+1.4.5. t_on_failure(reply_route)
317 526
 
318 527
    Sets reply routing block, to which control is passed after a
319 528
    transaction completed with a negative result but before
... ...
@@ -336,14 +545,14 @@ if (!t_relay()) { sl_reply_error(); break; };
336 545
 
337 546
      * reply_route - Reply route block to be called.
338 547
 
339
-   Example 1-12. t_on_negative usage
548
+   Example 1-15. t_on_failure usage
340 549
 ...
341 550
 route {
342
-    t_on_negative("1");
551
+    t_on_failure("1");
343 552
     t_relay();
344 553
 }
345 554
 
346
-reply_route[1] {
555
+failure_route[1] {
347 556
     revert_uri();
348 557
     setuser("voicemail");
349 558
     append_branch();
... ...
@@ -354,13 +563,85 @@ reply_route[1] {
354 563
    serial with parallel forking.
355 564
      _________________________________________________________
356 565
 
357
-1.4.4. append_branch()
566
+1.4.6. t_on_reply(onreply_route)
567
+
568
+   Sets reply routing block, to which control is passed when a
569
+   reply is received from one of downstream branches. Only a
570
+   limited set of functions is available in onreply_route blocks.
571
+   The routing block will be called for every reply received from
572
+   downstream. A typical use for onreply_route blocks would be
573
+   rewriting contacts with private IP addresses in 200 OK replies
574
+   by nathelper module.
575
+
576
+   Meaning of the parameters is as follows:
577
+
578
+     * onreply_route - Reply route block to be called.
579
+
580
+   Example 1-16. t_on_reply usage
581
+...
582
+route {
583
+    t_on_reply("1");
584
+    t_relay();
585
+}
586
+
587
+onreply_route[1] {
588
+    fix_nated_contact();
589
+    force_rtp_proxy();
590
+}
591
+...
592
+     _________________________________________________________
593
+
594
+1.4.7. t_check_status(regex)
595
+
596
+   This function can be used to check the status code in replies
597
+   from failure_route and onreply_route blocks. It allows to
598
+   differentiate processing based on the status code received.
599
+
600
+   Meaning of the parameters is as follows:
601
+
602
+     * regex - Regular expression to be matched agains the status
603
+       code.
604
+
605
+   Example 1-17. t_check_status usage
606
+...
607
+failure_route[1] {
608
+    if (t_check_status("486")) {
609
+        # Busy
610
+        t_relay_to_udp("1.2.3.4", "5060");
611
+    };
612
+ }
613
+...
614
+     _________________________________________________________
615
+
616
+1.4.8. t_write_req(fifo, application)
617
+
618
+   Send the request ove the FIFO interface to another
619
+   application, such as SEMS.
620
+
621
+   Meaning of the parameters is as follows:
622
+
623
+     * fifo - Name of the FIFO interface.
624
+     * application - Name of the application.
625
+     _________________________________________________________
626
+
627
+1.4.9. t_write_unix(socket, application)
628
+
629
+   Send the request ove the unix domain socket interface to
630
+   another application, such as SEMS.
631
+
632
+   Meaning of the parameters is as follows:
633
+
634
+     * socket - Filename of the unix domain socket.
635
+     * application - Name of the application.
636
+     _________________________________________________________
637
+
638
+1.4.10. append_branch()
358 639
 
359 640
    Similarly to t_fork_to, it extends destination set by a new
360 641
    entry. The difference is that current URI is taken as new
361 642
    entry.
362 643
 
363
-   Example 1-13. append_branch usage
644
+   Example 1-18. append_branch usage
364 645
 ...
365 646
 set_user("john");
366 647
 t_fork();
... ...
@@ -370,13 +651,13 @@ t_relay();
370 651
 ...
371 652
      _________________________________________________________
372 653
 
373
-1.4.5. t_newtran()
654
+1.4.11. t_newtran()
374 655
 
375 656
    Creates a new transaction, returns a negative value on error.
376 657
    This is the only way a script can add a new transaction in an
377 658
    atomic way. Typically, it is used to deploy a UAS.
378 659
 
379
-   Example 1-14. t_newtran usage
660
+   Example 1-19. t_newtran usage
380 661
 ...
381 662
 if (t_newtran()) {
382 663
     log("UAS logic");
... ...
@@ -387,7 +668,7 @@ if (t_newtran()) {
387 668
    See test/uas.cfg for more examples.
388 669
      _________________________________________________________
389 670
 
390
-1.4.6. t_reply(code, reason_phrase)
671
+1.4.12. t_reply(code, reason_phrase)
391 672
 
392 673
    Sends a stateful reply after a transaction has been
393 674
    established. See t_newtran for usage.
... ...
@@ -397,13 +678,13 @@ if (t_newtran()) {
397 678
      * code - Reply code number.
398 679
      * reason_phrase - Reason string.
399 680
 
400
-   Example 1-15. t_reply usage
681
+   Example 1-20. t_reply usage
401 682
 ...
402 683
 t_reply("404", "Not found");
403 684
 ...
404 685
      _________________________________________________________
405 686
 
406
-1.4.7. t_lookup_request()
687
+1.4.13. t_lookup_request()
407 688
 
408 689
    Checks if a transaction exists. Returns a positive value if
409 690
    so, negative otherwise. Most likely you will not want to use
... ...
@@ -411,7 +692,7 @@ t_reply("404", "Not found");
411 692
    new transaction if none was found. However this is safely
412 693
    (atomically) done using t_newtran.
413 694
 
414
-   Example 1-16. t_lookup_request usage
695
+   Example 1-21. t_lookup_request usage
415 696
 ...
416 697
 if (t_lookup_request()) {
417 698
     ...
... ...
@@ -419,44 +700,59 @@ if (t_lookup_request()) {
419 700
 ...
420 701
      _________________________________________________________
421 702
 
422
-1.4.8. t_retransmit_reply()
703
+1.4.14. t_retransmit_reply()
423 704
 
424 705
    Retransmits a reply sent previously by UAS transaction.
425 706
 
426
-   Example 1-17. t_retransmit_reply usage
707
+   Example 1-22. t_retransmit_reply usage
427 708
 ...
428 709
 t_retransmit_reply();
429 710
 ...
430 711
      _________________________________________________________
431 712
 
432
-1.4.9. t_release()
713
+1.4.15. t_release()
433 714
 
434 715
    Remove transaction from memory (it will be first put on a wait
435 716
    timer to absorb delayed messages).
436 717
 
437
-   Example 1-18. t_release usage
718
+   Example 1-23. t_release usage
438 719
 ...
439 720
 t_release();
440 721
 ...
441 722
      _________________________________________________________
442 723
 
443
-1.4.10. t_forward_nonack(ip, port)
724
+1.4.16. t_replicate(ip, port), t_replicate_udp(ip, port),
725
+t_replicate_tcp(ip, port), t_replicate_tls(ip, port)
726
+
727
+   Replicate a message to another server. Functions with "_tls"
728
+   suffix are only available with additional TLS package.
729
+
730
+   Meaning of the parameters is as follows:
731
+
732
+     * ip - IP address where the message should be sent.
733
+     * port - Port number.
734
+     _________________________________________________________
735
+
736
+1.4.17. t_forward_nonack(ip, port), t_forward_nonack_uri(),
737
+t_forward_nonack_udp(ip, port), t_forward_nonack_tcp(ip, port),
738
+t_forward_nonack_tls(ip, port)
444 739
 
445 740
    mainly for internal usage--forward a non-ACK request
446
-   statefully.
741
+   statefully. t_forward_nonack_tls is only available with
742
+   additional TLS package.
447 743
 
448 744
    Meaning of the parameters is as follows:
449 745
 
450 746
      * ip - IP address where the message should be sent.
451 747
      * port - Port number.
452 748
 
453
-   Example 1-19. t_forward_nonack usage
749
+   Example 1-24. t_forward_nonack usage
454 750
 ...
455 751
 t_forward_nonack("1.2.3.4", "5060");
456 752
 ...
457 753
      _________________________________________________________
458 754
 
459
-1.4.11. External Usage of TM
755
+1.4.18. External Usage of TM
460 756
 
461 757
    There are applications which would like to generate SIP
462 758
    transactions without too big involvement in SIP stack,
... ...
@@ -504,7 +800,7 @@ end of body
504 800
    or cat test/transaction.fifo > /tmp/ser_fifo
505 801
      _________________________________________________________
506 802
 
507
-1.4.12. Known Issues
803
+1.4.19. Known Issues
508 804
 
509 805
      * We don't have authentication merging on forking.
510 806
      * Local ACK/CANCELs copy'n'pastes Route and ignores deleted
... ...
@@ -284,6 +284,149 @@ modparam("tm", "noisy_ctimer", 1)
284 284
 	    </example>
285 285
 	</section>
286 286
 
287
+	<section>
288
+	    <title><varname>ruri_matching</varname> (integer)</title>
289
+	    <para>
290
+		The parameter controls whether the Request-URI should be
291
+		included in pre-RFC3261 transaction maching. When set 1 then
292
+		the Request-URI will be included, when set to 0 then it will be
293
+		not included.
294
+	    </para>
295
+	    <para>
296
+		<emphasis>
297
+		    Default value is 1 (include Request-URI).
298
+		</emphasis>
299
+	    </para>
300
+	</section>
301
+
302
+	<section>
303
+	    <title><varname>via1_matching</varname> (integer)</title>
304
+	    <para>
305
+		The parameter controls whether the topmost Via header field
306
+		should be included in pre-RFC3261 transaction maching. When set
307
+		1 then the topmost Via header field will be included, when set
308
+		to 0 then it will be not included.
309
+	    </para>
310
+	    <para>
311
+		<emphasis>
312
+		    Default value is 1 (include topmost Via header field).
313
+		</emphasis>
314
+	    </para>
315
+	</section>
316
+
317
+	<section>
318
+	    <title><varname>uac_from</varname> (string)</title>
319
+	    <para>
320
+		This parameter allows to configure the URI that will be put in
321
+		the From header field of SIP request generated localy by the
322
+		UAC in tm module. This parameter is currently not used.
323
+	    </para>
324
+	    <para>
325
+		<emphasis>
326
+		    Default value is "sip:foo@foo.bar".
327
+		</emphasis>
328
+	    </para>
329
+	</section>
330
+
331
+	<section>
332
+	    <title><varname>unix_tx_timeout</varname> (integer)</title>
333
+	    <para>
334
+		Maximum timeout in seconds for the request sent over the unix
335
+		domain socket interface (using t_write_unix function). The
336
+		function will indicate failure if it does not manage to send
337
+		all the data within the interval configured by this parameter.
338
+	    </para>
339
+	    <para>
340
+		<emphasis>
341
+		    Default value is 2 seconds.
342
+		</emphasis>
343
+	    </para>
344
+	</section>
345
+
346
+	<section>
347
+	    <title><varname>restart_fr_on_each_reply</varname> (integer)</title>
348
+	    <para>
349
+		The parameter controls whether the FR timer will be restarted on
350
+		each provisional reply received.
351
+	    </para>
352
+	    <para>
353
+		<emphasis>
354
+		    Default value is 1 (yes).
355
+		</emphasis>
356
+	    </para>
357
+	</section>
358
+
359
+	<section>
360
+	    <title><varname>fr_timer_avp</varname> (string)</title>
361
+	    <para>
362
+		This parameter makes it possible to override the value of FR
363
+		(final reply) timer on per-transaction basis. TM module can
364
+		pick the value of the timer from an AVP. The name or ID of the
365
+		AVP can be configured by this parameter. If there is no such
366
+		AVP then the default value configured through fr_timer
367
+		parameter will be used.
368
+	    </para>
369
+	    <para>
370
+		<emphasis>
371
+		    Default value is "callee_fr_timer".
372
+		</emphasis>
373
+	    </para>
374
+	</section>
375
+
376
+	<section>
377
+	    <title><varname>fr_inv_timer_avp</varname> (string)</title>
378
+	    <para>
379
+		This parameter makes it possible to override the value of FR
380
+		Invite (final response for INVITE transactions) timer on
381
+		per-transaction basis. TM module can pick the value of the
382
+		timer from an AVP. The name or ID of the AVP can be configured
383
+		by this parameter. If there is no such AVP then the default
384
+		value configured through fr_inv_timer parameter will be used.
385
+	    </para>
386
+	    <para>
387
+		<emphasis>
388
+		    Default value is "callee_fr_inv_timer".
389
+		</emphasis>
390
+	    </para>
391
+	</section>
392
+
393
+	<section>
394
+	    <title><varname>tw_append</varname> (string)</title>
395
+	    <para>
396
+		This parameter configures additional information that can be
397
+		passed over the FIFO or unix domain socket interfaces by TM
398
+		module to another application. TM module can pass values of
399
+		AVPs, SIP message header fields, or the message body. Syntax of
400
+		the parameter is as follows:
401
+	    </para>
402
+	    <programlisting>
403
+tw_append = name ':' element ( ';' element ) *
404
+element   = [ title '=' ] ( avp_val | hdr_val )
405
+element   = title '=' body_val
406
+avp_val   = "avp" '[' avp_spec ']'
407
+hdr_val   = "hdr" '[' hdr_name ']'
408
+body_val  = "msg[body]"
409
+</programlisting>
410
+	    <para>
411
+		<emphasis>
412
+		    Default value is "".
413
+		</emphasis>
414
+	    </para>
415
+
416
+	    <example>
417
+		<title>Set <varname>tw_append</varname> parameter</title>
418
+		<para>
419
+		    Pass the value of callee_fr_timer AVP, the contents of
420
+		    Subject header field, and the whole SIP message body to the
421
+		    application over FIFO or unix domain socket interface.
422
+		</para>
423
+		<programlisting format="linespecific">
424
+...
425
+modparam("tm", "tw_append", "params:avp[callee_fr_timer];hdr[Subject];body=msg[body]")
426
+...
427
+</programlisting>
428
+	    </example>
429
+	</section>
287 430
 
288 431
 
289 432
     </section>
... ...
@@ -292,7 +435,8 @@ modparam("tm", "noisy_ctimer", 1)
292 435
 	<section>
293 436
 	    <title>
294 437
 		<function moreinfo="none">t_relay_to_udp(ip, port)</function>,
295
-		<function moreinfo="none">t_relay_to_tcp(ip, port)</function>
438
+		<function moreinfo="none">t_relay_to_tcp(ip, port)</function>,
439
+		<function moreinfo="none">t_relay_to_tls(ip, port)</function>
296 440
 	    </title>
297 441
 	    <para>
298 442
 		Relay a message statefully to a fixed destination. This along with <function
... ...
@@ -342,9 +486,108 @@ if (!t_relay()) { sl_reply_error(); break; };
342 486
 	    </example>
343 487
 	</section>
344 488
 
489
+
490
+
491
+
492
+	<section>
493
+	    <title>
494
+		<function moreinfo="none">t_on_failure(reply_route)</function>
495
+	    </title>
496
+	    <para>
497
+		Sets reply routing block, to which control is passed after a transaction completed
498
+		with a negative result but before sending a final reply. In the referred block, you
499
+		can either start a new branch (good for services such as forward_on_no_reply) or
500
+		send a final reply on your own (good for example for message silo, which received a
501
+		negative reply from upstream and wants to tell upstream <quote>202 I will take care
502
+		of it</quote>). Note that the set of command which are usable within reply_routes
503
+		is strictly limited to rewriting &uri;, initiating new branches, logging, and
504
+		sending stateful replies (<function>t_reply</function>). Any other commands may
505
+		result in unpredictable behavior and possible server failure. Note that whenever
506
+		reply_route is entered, uri is reset to value which it had on relaying. If it
507
+		temporarily changed during a reply_route processing, subsequent reply_route will
508
+		ignore the changed value and use again the original one.
509
+	    </para>
510
+	    <para>Meaning of the parameters is as follows:</para>
511
+	    <itemizedlist>
512
+		<listitem>
513
+		    <para><emphasis>reply_route</emphasis> - Reply route block to be called.
514
+		    </para>
515
+		</listitem>
516
+	    </itemizedlist>
517
+	    <example>
518
+		<title><function>t_on_failure</function> usage</title>
519
+		<programlisting format="linespecific">
520
+...
521
+route { 
522
+    t_on_failure("1"); 
523
+    t_relay(); 
524
+} 
525
+
526
+failure_route[1] {
527
+    revert_uri(); 
528
+    setuser("voicemail"); 
529
+    append_branch(); 
530
+}
531
+...
532
+</programlisting>
533
+	    </example>
534
+	    <para>
535
+		See test/onr.cfg for a more complex example of combination
536
+		of serial with parallel forking.
537
+	    </para>
538
+	</section>
539
+
540
+	<section>
541
+	    <title>
542
+		<function moreinfo="none">t_on_failure(reply_route)</function>
543
+	    </title>
544
+	    <para>
545
+		Sets reply routing block, to which control is passed after a transaction completed
546
+		with a negative result but before sending a final reply. In the referred block, you
547
+		can either start a new branch (good for services such as forward_on_no_reply) or
548
+		send a final reply on your own (good for example for message silo, which received a
549
+		negative reply from upstream and wants to tell upstream <quote>202 I will take care
550
+		of it</quote>). Note that the set of command which are usable within reply_routes
551
+		is strictly limited to rewriting &uri;, initiating new branches, logging, and
552
+		sending stateful replies (<function>t_reply</function>). Any other commands may
553
+		result in unpredictable behavior and possible server failure. Note that whenever
554
+		reply_route is entered, uri is reset to value which it had on relaying. If it
555
+		temporarily changed during a reply_route processing, subsequent reply_route will
556
+		ignore the changed value and use again the original one.
557
+	    </para>
558
+	    <para>Meaning of the parameters is as follows:</para>
559
+	    <itemizedlist>
560
+		<listitem>
561
+		    <para><emphasis>reply_route</emphasis> - Reply route block to be called.
562
+		    </para>
563
+		</listitem>
564
+	    </itemizedlist>
565
+	    <example>
566
+		<title><function>t_on_failure</function> usage</title>
567
+		<programlisting format="linespecific">
568
+...
569
+route { 
570
+    t_on_failure("1"); 
571
+    t_relay(); 
572
+} 
573
+
574
+failure_route[1] {
575
+    revert_uri(); 
576
+    setuser("voicemail"); 
577
+    append_branch(); 
578
+}
579
+...
580
+</programlisting>
581
+	    </example>
582
+	    <para>
583
+		See test/onr.cfg for a more complex example of combination
584
+		of serial with parallel forking.
585
+	    </para>
586
+	</section>
587
+
345 588
 	<section>
346 589
 	    <title>
347
-		<function moreinfo="none">t_on_negative(reply_route)</function>
590
+		<function moreinfo="none">t_on_failure(reply_route)</function>
348 591
 	    </title>
349 592
 	    <para>
350 593
 		Sets reply routing block, to which control is passed after a transaction completed
... ...
@@ -368,15 +611,15 @@ if (!t_relay()) { sl_reply_error(); break; };
368 611
 		</listitem>
369 612
 	    </itemizedlist>
370 613
 	    <example>
371
-		<title><function>t_on_negative</function> usage</title>
614
+		<title><function>t_on_failure</function> usage</title>
372 615
 		<programlisting format="linespecific">
373 616
 ...
374 617
 route { 
375
-    t_on_negative("1"); 
618
+    t_on_failure("1"); 
376 619
     t_relay(); 
377 620
 } 
378 621
 
379
-reply_route[1] {
622
+failure_route[1] {
380 623
     revert_uri(); 
381 624
     setuser("voicemail"); 
382 625
     append_branch(); 
... ...
@@ -390,6 +633,119 @@ reply_route[1] {
390 633
 	    </para>
391 634
 	</section>
392 635
 
636
+	<section>
637
+	    <title>
638
+		<function moreinfo="none">t_on_reply(onreply_route)</function>
639
+	    </title>
640
+	    <para>
641
+		Sets reply routing block, to which control is passed when a
642
+		reply is received from one of downstream branches. Only a
643
+		limited set of functions is available in onreply_route
644
+		blocks. The routing block will be called for every reply
645
+		received from downstream. A typical use for onreply_route
646
+		blocks would be rewriting contacts with private IP addresses in
647
+		200 OK replies by nathelper module.
648
+	    </para>
649
+	    <para>Meaning of the parameters is as follows:</para>
650
+	    <itemizedlist>
651
+		<listitem>
652
+		    <para><emphasis>onreply_route</emphasis> - Reply route block to be called.
653
+		    </para>
654
+		</listitem>
655
+	    </itemizedlist>
656
+	    <example>
657
+		<title><function>t_on_reply</function> usage</title>
658
+		<programlisting format="linespecific">
659
+...
660
+route { 
661
+    t_on_reply("1"); 
662
+    t_relay(); 
663
+} 
664
+
665
+onreply_route[1] {
666
+    fix_nated_contact();
667
+    force_rtp_proxy();
668
+}
669
+...
670
+</programlisting>
671
+	    </example>
672
+	</section>
673
+
674
+	<section>
675
+	    <title>
676
+		<function moreinfo="none">t_check_status(regex)</function>
677
+	    </title>
678
+	    <para>
679
+		This function can be used to check the status code in replies
680
+		from failure_route and onreply_route blocks. It allows to
681
+		differentiate processing based on the status code received.
682
+	    </para>
683
+	    <para>Meaning of the parameters is as follows:</para>
684
+	    <itemizedlist>
685
+		<listitem>
686
+		    <para><emphasis>regex</emphasis> - Regular expression to be
687
+		    matched agains the status code.
688
+		    </para>
689
+		</listitem>
690
+	    </itemizedlist>
691
+	    <example>
692
+		<title><function>t_check_status</function> usage</title>
693
+		<programlisting format="linespecific">
694
+...
695
+failure_route[1] {
696
+    if (t_check_status("486")) {
697
+        # Busy
698
+        t_relay_to_udp("1.2.3.4", "5060");
699
+    };
700
+ }
701
+...
702
+</programlisting>
703
+	    </example>
704
+	</section>
705
+
706
+	<section>
707
+	    <title>
708
+		<function moreinfo="none">t_write_req(fifo, application)</function>
709
+	    </title>
710
+	    <para>
711
+		Send the request ove the FIFO interface to another application,
712
+		such as SEMS.
713
+	    </para>
714
+	    <para>Meaning of the parameters is as follows:</para>
715
+	    <itemizedlist>
716
+		<listitem>
717
+		    <para><emphasis>fifo</emphasis> - Name of the FIFO interface.
718
+		    </para>
719
+		</listitem>
720
+		<listitem>
721
+		    <para><emphasis>application</emphasis> - Name of the application.
722
+		    </para>
723
+		</listitem>
724
+	    </itemizedlist>
725
+	</section>
726
+
727
+	<section>
728
+	    <title>
729
+		<function moreinfo="none">t_write_unix(socket, application)</function>
730
+	    </title>
731
+	    <para>
732
+		Send the request ove the unix domain socket interface to another application,
733
+		such as SEMS.
734
+	    </para>
735
+	    <para>Meaning of the parameters is as follows:</para>
736
+	    <itemizedlist>
737
+		<listitem>
738
+		    <para><emphasis>socket</emphasis> - Filename of the unix
739
+		    domain socket.
740
+		    </para>
741
+		</listitem>
742
+		<listitem>
743
+		    <para><emphasis>application</emphasis> - Name of the application.
744
+		    </para>
745
+		</listitem>
746
+	    </itemizedlist>
747
+	</section>
748
+
393 749
 	<section>
394 750
 	    <title>
395 751
 		<function moreinfo="none">append_branch()</function>
... ...
@@ -525,10 +881,43 @@ t_release();
525 881
 
526 882
 	<section>
527 883
 	    <title>
528
-		<function moreinfo="none">t_forward_nonack(ip, port)</function>
884
+		<function moreinfo="none">t_replicate(ip, port)</function>,
885
+		<function moreinfo="none">t_replicate_udp(ip, port)</function>,
886
+		<function moreinfo="none">t_replicate_tcp(ip, port)</function>,
887
+		<function moreinfo="none">t_replicate_tls(ip, port)</function>
888
+	    </title>
889
+	    <para>
890
+		Replicate a message to another server. Functions with "_tls"
891
+		suffix are only available with additional TLS package.
892
+	    </para>
893
+	    <para>Meaning of the parameters is as follows:</para>
894
+	    <itemizedlist>
895
+		<listitem>
896
+		    <para><emphasis>ip</emphasis> - &ip address where the message should be sent.
897
+		    </para>
898
+		</listitem>
899
+		<listitem>
900
+		    <para><emphasis>port</emphasis> - Port number.
901
+		    </para>
902
+		</listitem>
903
+	    </itemizedlist>
904
+	</section>
905
+
906
+	<section>
907
+	    <title>
908
+		<function moreinfo="none">t_forward_nonack(ip,
909
+		port)</function>,
910
+		<function moreinfo="none">t_forward_nonack_uri()</function>,
911
+		<function moreinfo="none">t_forward_nonack_udp(ip,
912
+		port)</function>,
913
+		<function moreinfo="none">t_forward_nonack_tcp(ip,
914
+		port)</function>,
915
+		<function moreinfo="none">t_forward_nonack_tls(ip, port)</function>
529 916
 	    </title>
530 917
 	    <para>
531
-		mainly for internal usage--forward a non-ACK request statefully.
918
+		mainly for internal usage--forward a non-ACK request
919
+		statefully. t_forward_nonack_tls is only available with
920
+		additional TLS package.
532 921
 	    </para>
533 922
 	    <para>Meaning of the parameters is as follows:</para>
534 923
 	    <itemizedlist>