tm: some restructuring to docbook for better ToC

modules/tm/README

@@ -8,9 +8,9 @@ Juha Heinanen
 
    <[email protected]>
 
-   Copyright © 2003 FhG FOKUS
+   Copyright © 2003 FhG FOKUS
 
-   Copyright © 2008 Juha Heinanen
+   Copyright © 2008 Juha Heinanen
      __________________________________________________________________
 
    1.1. Overview
@@ -61,52 +61,51 @@ Juha Heinanen
 
    1.5. Functions
 
-        1.5.1. t_relay_to_udp(ip, port), t_relay_to_udp(),
-                t_relay_to_tcp(ip, port) t_relay_to_tcp()
-                t_relay_to_tls(ip, port) t_relay_to_tls()
-                t_relay_to_sctp(ip, port) t_relay_to_sctp()
-
-        1.5.2. t_relay() t_relay(host, port)
-        1.5.3. t_on_failure(failure_route)
-        1.5.4. t_on_reply(onreply_route)
-        1.5.5. t_on_branch(branch_route)
-        1.5.6. append_branch()
-        1.5.7. t_newtran()
-        1.5.8. t_reply(code, reason_phrase)
-        1.5.9. t_lookup_request()
-        1.5.10. t_retransmit_reply()
-        1.5.11. t_release()
-        1.5.12. t_forward_nonack() t_forward_nonack(ip, port)
-                t_forward_nonack_udp(ip, port) t_forward_nonack_tcp(ip,
-                port) t_forward_nonack_tls(ip, port)
-                t_forward_nonack_sctp(ip, port)
-
-        1.5.13. t_set_fr(fr_inv_timeout [, fr_timeout])
-        1.5.14. t_reset_fr()
-        1.5.15. t_set_max_lifetime(inv_lifetime, noninv_lifetime)
-        1.5.16. t_reset_max_lifetime()
-        1.5.17. t_set_retr(retr_t1_interval, retr_t2_interval)
-        1.5.18. t_reset_retr()
-        1.5.19. t_set_auto_inv_100(0|1)
-        1.5.20. t_branch_timeout()
-        1.5.21. t_branch_replied()
-        1.5.22. t_any_timeout()
-        1.5.23. t_any_replied()
-        1.5.24. t_grep_status("code")
-        1.5.25. t_is_canceled()
-        1.5.26. t_is_expired()
-        1.5.27. t_relay_cancel()
-        1.5.28. t_lookup_cancel(), t_lookup_cancel(1)
-        1.5.29. t_drop_replies([mode])
-        1.5.30. t_save_lumps()
-        1.5.31. t_load_contacts()
-        1.5.32. t_next_contacts()
-        1.5.33. t_check_trans()
-        1.5.34. t_set_disable_6xx(0|1)
-        1.5.35. t_set_disable_failover(0|1)
-        1.5.36. t_replicate(params)
-        1.5.37. t_relay_to(proxy, flags)
-        1.5.38. t_set_no_e2e_cancel_reason(0|1)
+        1.5.1. t_relay([host, port])
+        1.5.2. t_relay_to_udp([ip, port])
+        1.5.3. t_relay_to_tcp([ip, port])
+        1.5.4. t_relay_to_tls([ip, port])
+        1.5.5. t_relay_to_sctp([ip, port])
+        1.5.6. t_on_failure(failure_route)
+        1.5.7. t_on_reply(onreply_route)
+        1.5.8. t_on_branch(branch_route)
+        1.5.9. append_branch()
+        1.5.10. t_newtran()
+        1.5.11. t_reply(code, reason_phrase)
+        1.5.12. t_lookup_request()
+        1.5.13. t_retransmit_reply()
+        1.5.14. t_release()
+        1.5.15. t_forward_nonack([ip, port])
+        1.5.16. t_forward_nonack_udp(ip, port)
+        1.5.17. t_forward_nonack_tcp(ip, port)
+        1.5.18. t_forward_nonack_tls(ip, port)
+        1.5.19. t_forward_nonack_sctp(ip, port)
+        1.5.20. t_set_fr(fr_inv_timeout [, fr_timeout])
+        1.5.21. t_reset_fr()
+        1.5.22. t_set_max_lifetime(inv_lifetime, noninv_lifetime)
+        1.5.23. t_reset_max_lifetime()
+        1.5.24. t_set_retr(retr_t1_interval, retr_t2_interval)
+        1.5.25. t_reset_retr()
+        1.5.26. t_set_auto_inv_100(0|1)
+        1.5.27. t_branch_timeout()
+        1.5.28. t_branch_replied()
+        1.5.29. t_any_timeout()
+        1.5.30. t_any_replied()
+        1.5.31. t_grep_status("code")
+        1.5.32. t_is_canceled()
+        1.5.33. t_is_expired()
+        1.5.34. t_relay_cancel()
+        1.5.35. t_lookup_cancel([1])
+        1.5.36. t_drop_replies([mode])
+        1.5.37. t_save_lumps()
+        1.5.38. t_load_contacts()
+        1.5.39. t_next_contacts()
+        1.5.40. t_check_trans()
+        1.5.41. t_set_disable_6xx(0|1)
+        1.5.42. t_set_disable_failover(0|1)
+        1.5.43. t_replicate(params)
+        1.5.44. t_relay_to(proxy, flags)
+        1.5.45. t_set_no_e2e_cancel_reason(0|1)
 
    1.6. TM Module API
 
@@ -176,7 +175,7 @@ Juha Heinanen
 Note
 
    Several Kamailio (OpenSER) TM module functionalities are now
-   implemented in the TMX module: “modules_k/tmx�. Check it to see if what
+   implemented in the TMX module: "modules_k/tmx". Check it to see if what
    you are looking for is there.
 
 1.2. Serial Forking Based on Q Value
@@ -1191,9 +1190,35 @@ modparam("tm", "e2e_cancel_reason", 0)
 
 1.5. Functions
 
-1.5.1.  t_relay_to_udp(ip, port), t_relay_to_udp(), t_relay_to_tcp(ip, port)
-t_relay_to_tcp() t_relay_to_tls(ip, port) t_relay_to_tls()
-t_relay_to_sctp(ip, port) t_relay_to_sctp()
+1.5.1. t_relay([host, port])
+
+   Relay a message statefully either to the destination indicated in the
+   current URI (if called without any parameters) or to the specified host
+   and port. In the later case (host and port specified) the protocol used
+   is the same protocol on which the message was received.
+
+   t_relay() is the statefull version for forward() while t_relay(host,
+   port) is similar to forward(host, port).
+
+   In the forward to uri case (t_relay()), if the original URI was
+   rewritten (by UsrLoc, RR, strip/prefix, etc.) the new URI will be
+   taken). The destination (including the protocol) is determined from the
+   uri, using SIP specific DNS resolving if needed (NAPTR, SRV a.s.o
+   depending also on the dns options).
+
+   Returns a negative value on failure -- you may still want to send a
+   negative reply upstream statelessly not to leave upstream UAC in lurch.
+
+   Example 41. t_relay usage
+...
+if (!t_relay())
+{
+    sl_reply_error();
+    break;
+};
+...
+
+1.5.2. t_relay_to_udp([ip, port])
 
    Relay a message statefully using a fixed protocol either to the
    specified fixed destination or to a destination derived from the
@@ -1211,7 +1236,7 @@ t_relay_to_sctp(ip, port) t_relay_to_sctp()
    derived from the message uri (using sip sepcific DNS lookups), but with
    the protocol corresponding to the function name.
 
-   Example 41. t_relay_to_udp usage
+   Example 42. t_relay_to_udp usage
 ...
 if (src_ip==10.0.0.0/8)
         t_relay_to_udp("1.2.3.4", "5060"); # sent to 1.2.3.4:5060 over udp
@@ -1219,35 +1244,19 @@ else
         t_relay_to_tcp(); # relay to msg. uri, but over tcp
 ...
 
-1.5.2.  t_relay() t_relay(host, port)
+1.5.3. t_relay_to_tcp([ip, port])
 
-   Relay a message statefully either to the destination indicated in the
-   current URI (if called without any parameters) or to the specified host
-   and port. In the later case (host and port specified) the protocol used
-   is the same protocol on which the message was received.
+   See function t_relay_to_udp([ip, port]).
 
-   t_relay() is the statefull version for forward(uri:host, uri:port)
-   while t_relay(host, port) is similar to forward(host, port).
+1.5.4. t_relay_to_tls([ip, port])
 
-   In the forward to uri case (t_relay()), if the original URI was
-   rewritten (by UsrLoc, RR, strip/prefix, etc.) the new URI will be
-   taken). The destination (including the protocol) is determined from the
-   uri, using SIP specific DNS resolving if needed (NAPTR, SRV a.s.o
-   depending also on the dns options).
+   See function t_relay_to_udp([ip, port]).
 
-   Returns a negative value on failure--you may still want to send a
-   negative reply upstream statelessly not to leave upstream UAC in lurch.
+1.5.5. t_relay_to_sctp([ip, port])
 
-   Example 42. t_relay usage
-...
-if (!t_relay())
-{
-    sl_reply_error();
-    break;
-};
-...
+   See function t_relay_to_udp([ip, port]).
 
-1.5.3.  t_on_failure(failure_route)
+1.5.6. t_on_failure(failure_route)
 
    Sets failure routing block, to which control is passed after a
    transaction completed with a negative result but before sending a final
@@ -1284,7 +1293,7 @@ failure_route[1] {
    See test/onr.cfg for a more complex example of combination of serial
    with parallel forking.
 
-1.5.4.  t_on_reply(onreply_route)
+1.5.7. t_on_reply(onreply_route)
 
    Sets the reply routing block, to which control is passed when a reply
    for the current transaction is received. Note that the set of commands
@@ -1314,7 +1323,7 @@ es');
         }
 }
 
-1.5.5.  t_on_branch(branch_route)
+1.5.8. t_on_branch(branch_route)
 
    Sets the branch routing block, to which control is passed after forking
    (when a new branch is created). For now branch routes are intended only
@@ -1338,7 +1347,7 @@ branch_route[1] {
         }
 }
 
-1.5.6.  append_branch()
+1.5.9. append_branch()
 
    Similarly to t_fork_to, it extends destination set by a new entry. The
    difference is that current URI is taken as new entry.
@@ -1352,7 +1361,7 @@ t_fork();
 t_relay();
 ...
 
-1.5.7.  t_newtran()
+1.5.10. t_newtran()
 
    Creates a new transaction, returns a negative value on error. This is
    the only way a script can add a new transaction in an atomic way.
@@ -1368,7 +1377,7 @@ if (t_newtran()) {
 
    See test/uas.cfg for more examples.
 
-1.5.8.  t_reply(code, reason_phrase)
+1.5.11. t_reply(code, reason_phrase)
 
    Sends a stateful reply after a transaction has been established. See
    t_newtran for usage.
@@ -1382,7 +1391,7 @@ if (t_newtran()) {
 t_reply("404", "Not found");
 ...
 
-1.5.9.  t_lookup_request()
+1.5.12. t_lookup_request()
 
    Checks if a transaction exists. Returns a positive value if so,
    negative otherwise. Most likely you will not want to use it, as a
@@ -1397,7 +1406,7 @@ if (t_lookup_request()) {
 };
 ...
 
-1.5.10.  t_retransmit_reply()
+1.5.13. t_retransmit_reply()
 
    Retransmits a reply sent previously by UAS transaction.
 
@@ -1406,7 +1415,7 @@ if (t_lookup_request()) {
 t_retransmit_reply();
 ...
 
-1.5.11.  t_release()
+1.5.14. t_release()
 
    Remove transaction from memory (it will be first put on a wait timer to
    absorb delayed messages).
@@ -1416,11 +1425,10 @@ t_retransmit_reply();
 t_release();
 ...
 
-1.5.12.  t_forward_nonack() t_forward_nonack(ip, port)
-t_forward_nonack_udp(ip, port) t_forward_nonack_tcp(ip, port)
-t_forward_nonack_tls(ip, port) t_forward_nonack_sctp(ip, port)
+1.5.15. t_forward_nonack([ip, port])
 
-   mainly for internal usage--forward a non-ACK request statefully.
+   Mainly for internal usage -- forward a non-ACK request statefully.
+   Variants of this functions can enforce a specific transport protocol.
 
    Meaning of the parameters is as follows:
      * ip - IP address where the message should be sent.
@@ -1431,7 +1439,23 @@ t_forward_nonack_tls(ip, port) t_forward_nonack_sctp(ip, port)
 t_forward_nonack("1.2.3.4", "5060");
 ...
 
-1.5.13.  t_set_fr(fr_inv_timeout [, fr_timeout])
+1.5.16. t_forward_nonack_udp(ip, port)
+
+   See function t_forward_nonack([ip, port]).
+
+1.5.17. t_forward_nonack_tcp(ip, port)
+
+   See function t_forward_nonack([ip, port]).
+
+1.5.18. t_forward_nonack_tls(ip, port)
+
+   See function t_forward_nonack([ip, port]).
+
+1.5.19. t_forward_nonack_sctp(ip, port)
+
+   See function t_forward_nonack([ip, port]).
+
+1.5.20. t_set_fr(fr_inv_timeout [, fr_timeout])
 
    Sets the fr_inv_timeout and optionally fr_timeout for the current
    transaction or for transactions created during the same script
@@ -1465,7 +1489,7 @@ branch_route[1] {
         }
 }
 
-1.5.14.  t_reset_fr()
+1.5.21. t_reset_fr()
 
    Resets the fr_inv_timer and fr_timer for the current transaction to the
    default values (set using the tm module parameters fr_inv_timer and
@@ -1484,7 +1508,7 @@ route {
 ...
 }
 
-1.5.15.  t_set_max_lifetime(inv_lifetime, noninv_lifetime)
+1.5.22. t_set_max_lifetime(inv_lifetime, noninv_lifetime)
 
    Sets the maximum lifetime for the current INVITE or non-INVITE
    transaction, or for transactions created during the same script
@@ -1513,7 +1537,7 @@ route {
                                           # INVITE and to 15s if not
 }
 
-1.5.16.  t_reset_max_lifetime()
+1.5.23. t_reset_max_lifetime()
 
    Resets the the maximum lifetime for the current INVITE or non-INVITE
    transaction to the default value (set using the tm module parameter
@@ -1532,7 +1556,7 @@ route {
 ...
 }
 
-1.5.17.  t_set_retr(retr_t1_interval, retr_t2_interval)
+1.5.24. t_set_retr(retr_t1_interval, retr_t2_interval)
 
    Sets the retr_t1_interval and retr_t2_interval for the current
    transaction or for transactions created during the same script
@@ -1578,7 +1602,7 @@ branch_route[1] {
         }
 }
 
-1.5.18.  t_reset_retr()
+1.5.25. t_reset_retr()
 
    Resets the retr_timer1 and retr_timer2 for the current transaction to
    the default values (set using the tm module parameters retr_timer1 and
@@ -1597,7 +1621,7 @@ route {
 ...
 }
 
-1.5.19.  t_set_auto_inv_100(0|1)
+1.5.26. t_set_auto_inv_100(0|1)
 
    Switch automatically sending 100 replies to INVITEs on/off on a per
    transaction basis. It overrides the auto_inv_100 value for the current
@@ -1614,7 +1638,7 @@ route {
 ...
 }
 
-1.5.20.  t_branch_timeout()
+1.5.27. t_branch_timeout()
 
    Returns true if the failure route is executed for a branch that did
    timeout. It can be used only from the failure_route.
@@ -1628,7 +1652,7 @@ failure_route[0]{
         }
 }
 
-1.5.21.  t_branch_replied()
+1.5.28. t_branch_replied()
 
    Returns true if the failure route is executed for a branch that did
    receive at least one reply in the past (the "current" reply is not
@@ -1646,7 +1670,7 @@ failure_route[0]{
         }
 }
 
-1.5.22.  t_any_timeout()
+1.5.29. t_any_timeout()
 
    Returns true if at least one of the current transactions branches did
    timeout.
@@ -1662,7 +1686,7 @@ failure_route[0]{
         }
 }
 
-1.5.23.  t_any_replied()
+1.5.30. t_any_replied()
 
    Returns true if at least one of the current transactions branches did
    receive some reply in the past. If called from a failure or onreply
@@ -1677,7 +1701,7 @@ onreply_route[0]{
         }
 }
 
-1.5.24.  t_grep_status("code")
+1.5.31. t_grep_status("code")
 
    Returns true if "code" is the final reply received (or locally
    generated) in at least one of the current transactions branches.
@@ -1691,7 +1715,7 @@ onreply_route[0]{
         }
 }
 
-1.5.25.  t_is_canceled()
+1.5.32. t_is_canceled()
 
    Returns true if the current transaction was canceled.
 
@@ -1704,7 +1728,7 @@ failure_route[0]{
         }
 }
 
-1.5.26.  t_is_expired()
+1.5.33. t_is_expired()
 
    Returns true if the current transaction has already been expired, i.e.
    the max_inv_lifetime/max_noninv_lifetime interval has already elapsed.
@@ -1718,7 +1742,7 @@ failure_route[0]{
         }
 }
 
-1.5.27.  t_relay_cancel()
+1.5.34. t_relay_cancel()
 
    Forwards the CANCEL if the corresponding INVITE transaction exists. The
    function is supposed to be used at the very beginning of the script,
@@ -1743,7 +1767,7 @@ if (method == CANCEL) {
         # do the same as for INVITEs
 }
 
-1.5.28.  t_lookup_cancel(), t_lookup_cancel(1)
+1.5.35. t_lookup_cancel([1])
 
    Returns true if the corresponding INVITE transaction exists for a
    CANCEL request. The function can be called at the beginning of the
@@ -1775,7 +1799,7 @@ if (method == CANCEL) {
         # do the same as for INVITEs
 }
 
-1.5.29.  t_drop_replies([mode])
+1.5.36. t_drop_replies([mode])
 
    Drops all the previously received replies in failure_route block to
    make sure that none of them is picked up again.
@@ -1803,7 +1827,7 @@ failure_route[0]{
         }
 }
 
-1.5.30.  t_save_lumps()
+1.5.37. t_save_lumps()
 
    Forces the modifications of the processed SIP message to be saved in
    shared memory before t_relay() is called. The new branches which are
@@ -1843,7 +1867,7 @@ failure_route[1] {
         t_relay();
 }
 
-1.5.31.  t_load_contacts()
+1.5.38. t_load_contacts()
 
    This is the first of the two functions that can be used to implement
    serial/parallel forking based on the q value of individual branches in
@@ -1896,7 +1920,7 @@ if (!t_load_contacts()) {
 };
 ...
 
-1.5.32.  t_next_contacts()
+1.5.39. t_next_contacts()
 
    The function t_next_contacts is the second of the two functions that
    can be used to implement serial/parallel forking based on the q value
@@ -1948,7 +1972,7 @@ if (!t_next_contacts()) {
 };
 ...
 
-1.5.33.  t_check_trans()
+1.5.40. t_check_trans()
 
    t_check_trans() can be used to quickly check if a message belongs or is
    related to a transaction. It behaves differently for different types of
@@ -1998,7 +2022,7 @@ if ( method == "CANCEL" && !t_check_trans())
         sl_reply("403", "cancel out of the blue forbidden");
 # note: in this example t_check_trans() can be replaced by t_lookup_cancel()
 
-1.5.34.  t_set_disable_6xx(0|1)
+1.5.41. t_set_disable_6xx(0|1)
 
    Turn off/on 6xx replies special rfc conformant handling on a per
    transaction basis. If turned off (t_set_disable_6xx("1")) 6XXs will be
@@ -2017,7 +2041,7 @@ route {
 ...
 }
 
-1.5.35.  t_set_disable_failover(0|1)
+1.5.42. t_set_disable_failover(0|1)
 
    Turn off/on dns failover on a per transaction basis.
 
@@ -2032,7 +2056,7 @@ route {
 ...
 }
 
-1.5.36.  t_replicate(params)
+1.5.43. t_replicate(params)
 
    Replicate the SIP request to a specific address.
 
@@ -2067,7 +2091,7 @@ t_replicate("sip:$var(h);transport=tls");
 t_replicate_to_udp("1.2.3.4", "5060");
 ...
 
-1.5.37.  t_relay_to(proxy, flags)
+1.5.44. t_relay_to(proxy, flags)
 
    Forward the SIP request to a specific address, controlling internal
    behavior via flags.
@@ -2101,7 +2125,7 @@ t_relay_to("tls:1.2.3.4");
 t_relay_to("0x01");
 ...
 
-1.5.38.  t_set_no_e2e_cancel_reason(0|1)
+1.5.45. t_set_no_e2e_cancel_reason(0|1)
 
    Enables/disables reason header (RFC 3326) copying from the triggering
    received CANCEL to the generated hop-by-hop CANCEL. 0 enables and 1
@@ -2188,7 +2212,7 @@ end of body
 
 1.6.2. Functions
 
-1.6.2.1.  register_tmcb(cb_type, cb_func)
+1.6.2.1. register_tmcb(cb_type, cb_func)
 
    For programmatic use only--register a function to be called back on an
    event. See t_hooks.h for more details.
@@ -2197,7 +2221,7 @@ end of body
      * cb_type - Callback type.
      * cb_func - Callback function.
 
-1.6.2.2.  load_tm(*import_structure)
+1.6.2.2. load_tm(*import_structure)
 
    For programmatic use only--import exported TM functions. See the acc
    module for an example of use.
@@ -2205,7 +2229,7 @@ end of body
    Meaning of the parameters is as follows:
      * import_structure - Pointer to the import structure.
 
-1.6.2.3.  int t_suspend(struct sip_msg *msg, unsigned int *hash_index,
+1.6.2.3. int t_suspend(struct sip_msg *msg, unsigned int *hash_index,
 unsigned int *label)
 
    For programmatic use only. This function together with t_continue() can
@@ -2243,7 +2267,7 @@ unsigned int *label)
    t_suspend() should return 0 to make sure that the script processing
    does not continue.
 
-1.6.2.4.  int t_continue(unsigned int hash_index, unsigned int label, struct
+1.6.2.4. int t_continue(unsigned int hash_index, unsigned int label, struct
 action *route)
 
    For programmatic use only. This function is the pair of t_suspend(),
@@ -2259,7 +2283,7 @@ action *route)
 
    Return value: 0 - success, <0 - error.
 
-1.6.2.5.  int t_cancel_suspend(unsigned int hash_index, unsigned int label)
+1.6.2.5. int t_cancel_suspend(unsigned int hash_index, unsigned int label)
 
    For programmatic use only. This function is for revoking t_suspend()
    from the same process as it was executed before. t_cancel_suspend() can

modules/tm/doc/functions.xml

@@ -8,16 +8,50 @@
 
     <title>Functions</title>
 
+    <section id="t_relay">
+	<title>
+	    <function>t_relay([host, port])</function>
+	</title>
+	<para>
+	    Relay a message statefully either to the destination indicated in the
+		current URI (if called without any parameters) or to the specified 
+		host and port. In the later case (host and port specified) the protocol
+		used is the same protocol on which the message was received.
+	</para>
+	<para>
+		<function>t_relay()</function> is the statefull version for 
+		<function>forward()</function>
+		while <function>t_relay(host, port)</function> is similar to 
+		<function>forward(host, port)</function>.
+	</para>
+	<para>
+		In the forward to uri case (<function>t_relay()</function>), if the
+	    original URI was rewritten (by UsrLoc, RR, strip/prefix, etc.) the new
+		URI will be taken). The destination (including the protocol) is 
+		determined from the uri, using SIP specific DNS resolving if needed
+		(NAPTR, SRV a.s.o depending also on the dns options).
+	</para>
+	<para>
+		Returns a negative value on failure -- you may still want to send a
+	    negative reply upstream statelessly not to leave upstream UAC in lurch.
+	</para>
+	<example>
+	    <title><function>t_relay</function> usage</title>
+	    <programlisting>
+...
+if (!t_relay()) 
+{ 
+    sl_reply_error(); 
+    break; 
+};
+...
+	    </programlisting>
+	</example>
+    </section>
+
     <section id="t_relay_to_udp">
 	<title>
-	    <function>t_relay_to_udp(ip, port)</function>,
-	    <function>t_relay_to_udp()</function>,
-	    <function>t_relay_to_tcp(ip, port)</function>
-	    <function>t_relay_to_tcp()</function>
-	    <function>t_relay_to_tls(ip, port)</function>
-	    <function>t_relay_to_tls()</function>
-	    <function>t_relay_to_sctp(ip, port)</function>
-	    <function>t_relay_to_sctp()</function>
+	    <function>t_relay_to_udp([ip, port])</function>
 	</title>
 	<para>
 	    Relay a message statefully using a fixed protocol either to the 
@@ -56,48 +90,33 @@ else
 	</example>
     </section>
 
-    <section id="t_relay">
+    <section id="t_relay_to_tcp">
 	<title>
-	    <function>t_relay()</function>
-	    <function>t_relay(host, port)</function>
+	    <function>t_relay_to_tcp([ip, port])</function>
 	</title>
 	<para>
-	    Relay a message statefully either to the destination indicated in the
-		current URI (if called without any parameters) or to the specified 
-		host and port. In the later case (host and port specified) the protocol
-		 used is the same protocol on which the message was received.
+		See function <function>t_relay_to_udp([ip, port])</function>.
 	</para>
+    </section>
+
+    <section id="t_relay_to_tls">
+	<title>
+	    <function>t_relay_to_tls([ip, port])</function>
+	</title>
 	<para>
-		<function>t_relay()</function> is the statefull version for 
-		<function>forward(uri:host, uri:port)</function>
-		while <function>t_relay(host, port)</function> is similar to 
-		<function>forward(host, port)</function>.
-	</para>
-	<para>
-		In the forward to uri case (<function>t_relay()</function>), if the
-	    original URI was rewritten (by UsrLoc, RR, strip/prefix, etc.) the new
-		URI will be taken). The destination (including the protocol) is 
-		determined from the uri, using SIP specific DNS resolving if needed
-		(NAPTR, SRV a.s.o depending also on the dns options).
+		See function <function>t_relay_to_udp([ip, port])</function>.
 	</para>
+    </section>
+
+    <section id="t_relay_to_sctp">
+	<title>
+	    <function>t_relay_to_sctp([ip, port])</function>
+	</title>
 	<para>
-		Returns a negative value on failure--you may still want to send a
-	    negative reply upstream statelessly not to leave upstream UAC in lurch.
+		See function <function>t_relay_to_udp([ip, port])</function>.
 	</para>
-	<example>
-	    <title><function>t_relay</function> usage</title>
-	    <programlisting>
-...
-if (!t_relay()) 
-{ 
-    sl_reply_error(); 
-    break; 
-};
-...
-	    </programlisting>
-	</example>
     </section>
-    
+
     <section id="t_on_failure">
 	<title>
 	    <function>t_on_failure(failure_route)</function>
@@ -367,15 +386,11 @@ t_release();
 
     <section id="t_forward_nonack">
 	<title>
-	    <function>t_forward_nonack()</function>
-	    <function>t_forward_nonack(ip, port)</function>
-	    <function>t_forward_nonack_udp(ip, port)</function>
-	    <function>t_forward_nonack_tcp(ip, port)</function>
-	    <function>t_forward_nonack_tls(ip, port)</function>
-	    <function>t_forward_nonack_sctp(ip, port)</function>
+	    <function>t_forward_nonack([ip, port])</function>
 	</title>
 	<para>
-	    mainly for internal usage--forward a non-ACK request statefully.
+		Mainly for internal usage -- forward a non-ACK request statefully.
+		Variants of this functions can enforce a specific transport protocol.
 	</para>
 	<para>Meaning of the parameters is as follows:</para>
 	<itemizedlist>
@@ -398,6 +413,42 @@ t_forward_nonack("1.2.3.4", "5060");
 	</example>
     </section>
 
+   <section id="t_forward_nonack_udp">
+	<title>
+	    <function>t_forward_nonack_udp(ip, port)</function>
+	</title>
+	<para>
+	    See function <function>t_forward_nonack([ip, port])</function>.
+	</para>
+    </section>
+
+   <section id="t_forward_nonack_tcp">
+	<title>
+	    <function>t_forward_nonack_tcp(ip, port)</function>
+	</title>
+	<para>
+	    See function <function>t_forward_nonack([ip, port])</function>.
+	</para>
+    </section>
+
+   <section id="t_forward_nonack_tls">
+	<title>
+	    <function>t_forward_nonack_tls(ip, port)</function>
+	</title>
+	<para>
+	    See function <function>t_forward_nonack([ip, port])</function>.
+	</para>
+    </section>
+
+   <section id="t_forward_nonack_sctp">
+	<title>
+	    <function>t_forward_nonack_sctp(ip, port)</function>
+	</title>
+	<para>
+	    See function <function>t_forward_nonack([ip, port])</function>.
+	</para>
+    </section>
+
 	<section id="t_set_fr">
 	<title>
 	    <function>t_set_fr(fr_inv_timeout [, fr_timeout])</function>
@@ -896,8 +947,7 @@ if (method == CANCEL) {
 
     <section id="t_lookup_cancel">
 	<title>
-	    <function>t_lookup_cancel()</function>,
-	    <function>t_lookup_cancel(1)</function>
+	    <function>t_lookup_cancel([1])</function>
 	</title>
 	<para>
 		Returns true if the corresponding INVITE transaction exists