tm Module

Bogdan-Andrei Iancu

   voice-system.ro

Jiri Kuthan

   FhG FOKUS

Edited by

Jiri Kuthan

Bogdan-Andrei Iancu

   Copyright  2003 FhG FOKUS

   Copyright  2005 voice-system.ro
     _________________________________________________________

   Table of Contents
   1. User's Guide

        1.1. Overview

              1.1.1. Per-Branch flags

        1.2. Dependencies

              1.2.1. OpenSER Modules
              1.2.2. External Libraries or Applications

        1.3. Exported Parameters

              1.3.1. fr_timer (integer)
              1.3.2. fr_inv_timer (integer)
              1.3.3. wt_timer (integer)
              1.3.4. delete_timer (integer)
              1.3.5. retr_timer1p1 (integer)
              1.3.6. retr_timer1p2 (integer)
              1.3.7. retr_timer1p3 (integer)
              1.3.8. retr_timer2 (integer)
              1.3.9. noisy_ctimer (integer)
              1.3.10. ruri_matching (integer)
              1.3.11. via1_matching (integer)
              1.3.12. unix_tx_timeout (integer)
              1.3.13. restart_fr_on_each_reply (integer)
              1.3.14. fr_timer_avp (string)
              1.3.15. fr_inv_timer_avp (string)
              1.3.16. tw_append (string)
              1.3.17. branch_flag_mask (string)
              1.3.18. pass_provisional_replies (integer)

        1.4. Exported Functions

              1.4.1. t_newtran()
              1.4.2. t_lookup_request()
              1.4.3. t_relay(proto:host:port),
              1.4.4. t_relay()
              1.4.5. t_forward_nonack()
                      t_forward_nonack(proto:host:port)

              1.4.6. t_reply(code, reason_phrase)
              1.4.7. t_retransmit_reply()
              1.4.8. t_replicate(URI)
              1.4.9. t_release()
              1.4.10. t_check_status(re)
              1.4.11. t_flush_flags()
              1.4.12. t_local_replied(reply)
              1.4.13. t_write_fifo(info,fifo)
                      t_write_unix(info,sock)

              1.4.14. t_check_trans()
              1.4.15. t_was_cancelled()
              1.4.16. t_on_failure(failure_route)
              1.4.17. t_on_reply(reply_route)
              1.4.18. t_on_branch(branch_route)

        1.5. Pseudo-Variables

   2. Developer's Guide

        2.1. Functions

              2.1.1. load_tm(*import_structure)

   3. Frequently Asked Questions

   List of Examples
   1-1. Set fr_timer parameter
   1-2. Set fr_inv_timer parameter
   1-3. Set wt_timer parameter
   1-4. Set delete_timer parameter
   1-5. Set retr_timer1p1 parameter
   1-6. Set retr_timer1p2 parameter
   1-7. Set retr_timer1p4 parameter
   1-8. Set retr_timer2 parameter
   1-9. Set noisy_ctimer parameter
   1-10. Set ruri_matching parameter
   1-11. Set via1_matching parameter
   1-12. Set unix_tx_timeout parameter
   1-13. Set restart_fr_on_each_reply parameter
   1-14. Set fr_timer_avp parameter
   1-15. Set fr_inv_timer_avp parameter
   1-16. Set tw_append parameter
   1-17. Set branch_flag_mask parameter
   1-18. Set pass_provisional_replies parameter
   1-19. t_newtran usage
   1-20. t_lookup_request usage
   1-21. t_relay usage
   1-22. t_relay usage
   1-23. t_forward_nonack usage
   1-24. t_reply usage
   1-25. t_retransmit_reply usage
   1-26. t_replicate usage
   1-27. t_release usage
   1-28. t_check_status usage
   1-29. t_flush_flags usage
   1-30. t_local_replied usage
   1-31. t_write_fifo/unix usage
   1-32. t_check_trans usage
   1-33. t_was_cancelled usage
   1-34. t_on_failure usage
   1-35. t_on_reply usage
   1-36. t_on_branch usage
     _________________________________________________________

Chapter 1. User's Guide

1.1. Overview

   TM module enables stateful processing of SIP transactions. The
   main use of stateful logic, which is costly in terms of memory
   and CPU, is some services inherently need state. For example,
   transaction-based accounting (module acc) needs to process
   transaction state as opposed to individual messages, and any
   kinds of forking must be implemented statefully. Other use of
   stateful processing is it trading CPU caused by retransmission
   processing for memory. That makes however only sense if CPU
   consumption per request is huge. For example, if you want to
   avoid costly DNS resolution for every retransmission of a
   request to an unresolvable destination, use stateful mode.
   Then, only the initial message burdens server by DNS queries,
   subsequent retransmissions will be dropped and will not result
   in more processes blocked by DNS resolution. The price is more
   memory consumption and higher processing latency.

   From user's perspective, there are these major functions :
   t_relay, t_relay_to_udp and t_relay_to_tcp. All of them setup
   transaction state, absorb retransmissions from upstream,
   generate downstream retransmissions and correlate replies to
   requests. t_relay forwards to current URI; (be it original
   request's URI or a URI changed by some of URI-modifying
   functions, such as sethost). t_relay_to_udp and t_relay_to_tcp
   forward to a specific address over UDP or TCP respectively.

   In general, if TM is used, it copies clones of received SIP
   messages in shared memory. That costs the memory and also CPU
   time (memcpys, lookups, shmem locks, etc.) Note that non-TM
   functions operate over the received message in private memory,
   that means that any core operations will have no effect on
   statefully processed messages after creating the transactional
   state. For example, calling record_route after t_relay is
   pretty useless, as the RR is added to privately held message
   whereas its TM clone is being forwarded.

   TM is quite big and uneasy to program--lot of mutexes, shared
   memory access, malloc & free, timers--you really need to be
   careful when you do anything. To simplify TM programming,
   there is the instrument of callbacks. The callback mechanisms
   allow programmers to register their functions to specific
   event. See t_hooks.h for a list of possible events.

   Other things programmers may want to know is UAC--it is a very
   simplistic code which allows you to generate your own
   transactions. Particularly useful for things like NOTIFYs or
   IM gateways. The UAC takes care of all the transaction
   machinery: retransmissions , FR timeouts, forking, etc. See
   t_uac prototype in uac.h for more details. Who wants to see
   the transaction result may register for a callback.
     _________________________________________________________

1.1.1. Per-Branch flags

   First what is the idea with the branch concept: branch route
   is a route to be execute separately for each branch before
   being sent out - changes in that route should reflect only on
   that branch.

   There are two types of flags in OpenSER :

     * global flags - global because they are visible everywhere
       in the transaction (in all routes and in all sequential
       replies/request).
     * branch flags - flags that are visible only from a specific
       branch - in all replies and routes connected to this
       branch.

   For example: I have a call parallel forking to GW and to a
   user. And I would like to know from which branch I will get
   the final negative reply (if so). I will set a branch route
   before relaying the calls (with the 2 branches). The branch
   route will be separately executed for each branch; in the
   branch going to GW (I can identified it by looking to RURI), I
   will set a branch flag. This flag will appear only in the
   onreply route run for replied from GW. It will be also be
   visible in failure route if the final elected reply belongs to
   the GW branch. This flags will not be visible in the other
   branch (in routes executing replies from the other branch).

   For how to define branch flags and use via script, see Section
   1.3.17 and Section 1.4.18.

   Also, modules may set branch flags before transaction creation
   (for the moment this feature is not available in script). The
   REGISTRAR module is the first to use this feature. If the
   "use_branch_flags" param is enabled, the NAT flag will be push
   in branch flags instead in message flags - IMPORTANT: be sure
   that NAT flag is in the range of the branch flags ad defined
   in TM. Using this, NAT traversal per branch may be
   implemented.
     _________________________________________________________

1.2. Dependencies

1.2.1. OpenSER Modules

   The following modules must be loaded before this module:

     * No dependencies on other OpenSER modules.
     _________________________________________________________

1.2.2. External Libraries or Applications

   The following libraries or applications must be installed
   before running OpenSER with this module loaded:

     * None.
     _________________________________________________________

1.3. Exported Parameters

1.3.1. fr_timer (integer)

   Timer which hits if no final reply for a request or ACK for a
   negative INVITE reply arrives (in seconds).

   Default value is 30 seconds. 

   Example 1-1. Set fr_timer parameter
...
modparam("tm", "fr_timer", 10)
...
     _________________________________________________________

1.3.2. fr_inv_timer (integer)

   Timer which hits if no final reply for an INVITE arrives after
   a provisional message was received (in seconds).

   Default value is 120 seconds. 

   Example 1-2. Set fr_inv_timer parameter
...
modparam("tm", "fr_inv_timer", 200)
...
     _________________________________________________________

1.3.3. wt_timer (integer)

   Time for which a transaction stays in memory to absorb delayed
   messages after it completed; also, when this timer hits,
   retransmission of local cancels is stopped (a puristic but
   complex behavior would be not to enter wait state until local
   branches are finished by a final reply or FR timer--we
   simplified).

   Default value is 5 seconds. 

   Example 1-3. Set wt_timer parameter
...
modparam("tm", "wt_timer", 10)
...
     _________________________________________________________

1.3.4. delete_timer (integer)

   Time after which a to-be-deleted transaction currently ref-ed
   by a process will be tried to be deleted again.

   Default value is 2 seconds. 

   Example 1-4. Set delete_timer parameter
...
modparam("tm", "delete_timer", 5)
...
     _________________________________________________________

1.3.5. retr_timer1p1 (integer)

   Retransmission period.

   Default value is 1 second. 

   Example 1-5. Set retr_timer1p1 parameter
...
modparam("tm", "retr_timer1p1", 2)
...
     _________________________________________________________

1.3.6. retr_timer1p2 (integer)

   Retransmission period.

   Default value is 2 * retr_timer1p1 second. 

   Example 1-6. Set retr_timer1p2 parameter
...
modparam("tm", "retr_timer1p2", 4)
...
     _________________________________________________________

1.3.7. retr_timer1p3 (integer)

   Retransmission period.

   Default value is 4 * retr_timer1p1 second. 

   Example 1-7. Set retr_timer1p4 parameter
...
modparam("tm", "retr_timer1p3", 8)
...
     _________________________________________________________

1.3.8. retr_timer2 (integer)

   Maximum retransmission period.

   Default value is 4 seconds. 

   Example 1-8. Set retr_timer2 parameter
...
modparam("tm", "retr_timer2", 8)
...
     _________________________________________________________

1.3.9. noisy_ctimer (integer)

   If set, on FR timer INVITE transactions will be explicitly
   canceled if possible, silently dropped otherwise. Preferably,
   it is turned off to allow very long ringing. This behavior is
   overridden if a request is forked, or some functionality
   explicitly turned it off for a transaction (like acc does to
   avoid unaccounted transactions due to expired timer).

   Default value is 0 (false). 

   Example 1-9. Set noisy_ctimer parameter
...
modparam("tm", "noisy_ctimer", 1)
...
     _________________________________________________________

1.3.10. ruri_matching (integer)

   Should be request-uri matching used as a part of pre-3261
   transaction matching as the standard wants us to do so? Turn
   only off for better interaction with devices that are broken
   and send different r-uri in CANCEL/ACK than in original
   INVITE.

   Default value is 1 (true). 

   Example 1-10. Set ruri_matching parameter
...
modparam("tm", "ruri_matching", 0)
...
     _________________________________________________________

1.3.11. via1_matching (integer)

   Should be top most VIA matching used as a part of pre-3261
   transaction matching as the standard wants us to do so? Turn
   only off for better interaction with devices that are broken
   and send different top most VIA in CANCEL/ACK than in original
   INVITE.

   Default value is 1 (true). 

   Example 1-11. Set via1_matching parameter
...
modparam("tm", "via1_matching", 0)
...
     _________________________________________________________

1.3.12. unix_tx_timeout (integer)

   Send timeout to be used by function which use UNIX sockets (as
   t_write_unix).

   Default value is 2 seconds. 

   Example 1-12. Set unix_tx_timeout parameter
...
modparam("tm", "unix_tx_timeout", 5)
...
     _________________________________________________________

1.3.13. restart_fr_on_each_reply (integer)

   If true (non null value), the final response timer will be
   re-triggered for each received provisional reply. In this
   case, final response timeout may occure after a time longe
   than fr_inv_timer (if UAS keeps sending provisional replies)

   Default value is 1 (true). 

   Example 1-13. Set restart_fr_on_each_reply parameter
...
modparam("tm", "restart_fr_on_each_reply", 0)
...
     _________________________________________________________

1.3.14. fr_timer_avp (string)

   Full specification (NAME, ID, Alias) of an AVP which contains
   a final response timeout value. If present, ths value will
   overeide the static fr_timer parameter.

   If set to empty string, the whole mechanism for variable
   timeout will be disabled, falling back to the static value.

   Default value is "callee_fr_timer". 

   Example 1-14. Set fr_timer_avp parameter
...
modparam("tm", "fr_timer_avp", "i:24")
...
     _________________________________________________________

1.3.15. fr_inv_timer_avp (string)

   Full specification (NAME, ID, Alias) of an AVP which contains
   a final INVITE response timeout value. If present, ths value
   will overeide the static fr_inv_timer parameter.

   If set to empty string, the whole mechanism for variable
   timeout will be disabled, falling back to the static value.

   Default value is "callee_fr_inv_timer". 

   Example 1-15. Set fr_inv_timer_avp parameter
...
modparam("tm", "fr_inv_timer_avp", "i:25")
...
     _________________________________________________________

1.3.16. tw_append (string)

   List of additional information to be appended by t_write_fifo
   and t_write_unix functions.

   Default value is null string. 

   Syntax of the parameter is:

     * tw_append = append_name':' element (';'element)* 
     * element = ( [name '='] pseudo_variable) 

   The full list of supported pseudo-variables in OpenSER is
   availabe at:
   http://openser.org/docs/pseudo-variables-1.1.x.html

   Each element will be appended per line in "name: value"
   format. Element "$rb (message body)" is the only one which
   does not accept name; the body it will be printed all the time
   at the end, disregarding its position in the definition
   string.

   Example 1-16. Set tw_append parameter
...
modparam("tm", "tw_append",
   "test: ua=$hdr(User-Agent) ;avp=$avp(i:10);$rb;time=$Ts")
...
     _________________________________________________________

1.3.17. branch_flag_mask (string)

   Defined which flags shall be as branch flags. The branch flags
   will be visible only in the messages belonging to that branch
   (in branch, onreply and failure route). The global flags are
   visible for all messages of the corresponding transaction.

   The value of the parameter is a 32-bits mask. It may be
   defined using 2, 10 or 16 bases.

   Default value is NULL (no branch flags, all being global). 

   Example 1-17. Set branch_flag_mask parameter
...
# using base 16
modparam("tm", "branch_flag_mask", "0xff000000")
# or using base 2
modparam("tm", "branch_flag_mask", "b11111111000000000000000000000000")
# or using base 10
modparam("tm", "branch_flag_mask", "4278190080")
...
     _________________________________________________________

1.3.18. pass_provisional_replies (integer)

   Enable/disable passing of provisional replies to FIFO
   applications.

   Default value is 0. 

   Example 1-18. Set pass_provisional_replies parameter
...
modparam("tm", "pass_provisional_replies", 1)
...
     _________________________________________________________

1.4. Exported Functions

1.4.1. 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. Typically, it is used to deploy a UAS.

   Warning

   NOTE that the changes on the request that are made after this
   function call will not be saved into transaction!!!

   This function can be used from REQUEST_ROUTE.

   Example 1-19. t_newtran usage
...
if (t_newtran()) {
        log("UAS logic");
        t_reply("999","hello");
} else sl_reply_error();
...
     _________________________________________________________

1.4.2. 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 typical application of a looku-up is to introduce a
   new transaction if none was found. However this is safely
   (atomically) done using t_newtran.

   This function can be used from REQUEST_ROUTE.

   Example 1-20. t_lookup_request usage
...
if (t_lookup_request()) {
        ...
};
...
     _________________________________________________________

1.4.3. t_relay(proto:host:port),

   Relay a message statefully to a fixed destination. The
   destination is specified as "[proto:]host[:port]".

   This functions can be used from REQUEST_ROUTE, FAILURE_ROUTE.

   Example 1-21. t_relay usage
...
t_relay("tcp:192.168.1.10:5060");
t_relay("mydomain.com:5070");
t_relay("udp:mydomain.com");
...
     _________________________________________________________

1.4.4. t_relay()

   Relay a message statefully to destination indicated in current
   URI. (If the original URI was rewritten by UsrLoc, RR,
   strip/prefix, etc., the new URI will be taken). Returns a
   negative value on failure--you may still want to send a
   negative reply upstream statelessly not to leave upstream UAC
   in lurch.

   This function can be used from REQUEST_ROUTE, FAILURE_ROUTE.

   Example 1-22. t_relay usage
...
if (!t_relay()) { sl_reply_error(); break; };
...
     _________________________________________________________

1.4.5. t_forward_nonack() t_forward_nonack(proto:host:port)

   Similar to t_relay() but it expects the transaction to be
   already created - this why it cannot handle ACK (which are
   statelessly forwarded). It should be used along with
   t_newtran().

   The destination is specified either as parameter ( in
   "[proto:]host[:port]" format), either is taken from the
   current URI.

   This functions can be used from REQUEST_ROUTE.

   Example 1-23. t_forward_nonack usage
...
t_forward_nonack("tcp:1.2.3.4:5060");
t_forward_nonack("udp:1.2.3.4");
t_forward_nonack();         # use RURI for destination
...
     _________________________________________________________

1.4.6. t_reply(code, reason_phrase)

   Sends a stateful reply after a transaction has been
   established. See t_newtran for usage.

   Meaning of the parameters is as follows:

     * code - Reply code number.
     * reason_phrase - Reason string.

   This function can be used from REQUEST_ROUTE, FAILURE_ROUTE.

   Example 1-24. t_reply usage
...
t_reply("404", "Not found");
...
     _________________________________________________________

1.4.7. t_retransmit_reply()

   Retransmits a reply sent previously by UAS transaction.

   This function can be used from REQUEST_ROUTE, FAILURE_ROUTE
   and BRANCH_ROUTE.

   Example 1-25. t_retransmit_reply usage
...
t_retransmit_reply();
...
     _________________________________________________________

1.4.8. t_replicate(URI)

   Replicates a request to another destination. No information
   due the replicated request (like reply code) will be forwarded
   to the original SIP UAC.

   The destination is specified by a SIP URI. If multiple
   destinations are to be used, the additional SIP URIs have to
   be set as branches.

   This functions can be used from REQUEST_ROUTE.

   Example 1-26. t_replicate usage
...
t_replicate("sip:1.2.3.4:5060");
t_replicate("sip:1.2.3.4:5060;transport=tcp");
t_replicate("sip:1.2.3.4");
...
     _________________________________________________________

1.4.9. t_release()

   Remove transaction from memory (it will be first put on a wait
   timer to absorb delayed messages).

   This function can be used from REQUEST_ROUTE.

   Example 1-27. t_release usage
...
t_release();
...
     _________________________________________________________

1.4.10. t_check_status(re)

   Returns true if the regualr expresion "re" match the reply
   code of the response message as follows:

     * in routing block - the code of the last sent reply.
     * in on_reply block - the code of the current received
       reply.
     * in on_failure block - the code of the selected negative
       final reply.

   This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE,
   FAILURE_ROUTE and BRANCH_ROUTE .

   Example 1-28. t_check_status usage
...
if (t_check_status("(487)|(408)")) {
    log("487 or 408 negative reply\n");
}
...
     _________________________________________________________

1.4.11. t_flush_flags()

   Flush the flags from current request into the already created
   transaction. It make sens only in routing block if the
   trnasaction was created via t_newtran() and the flags have
   been altered since.

   This function can be used from REQUEST_ROUTE and BRANCH_ROUTE
   .

   Example 1-29. t_flush_flags usage
...
t_flush_flags();
...
     _________________________________________________________

1.4.12. t_local_replied(reply)

   Returns true if all or last (depending of the parameter)
   reply(es) were local generated (and not received).

   Parameter may be "all" or "last".

   This function can be used from REQUEST_ROUTE, BRANCH_ROUTE,
   FAILURE_ROUTE and ONREPLY_ROUTE.

   Example 1-30. t_local_replied usage
...
if (t_local_replied("all")) {
        log ("no reply received\n");
}
...
     _________________________________________________________

1.4.13. t_write_fifo(info,fifo) t_write_unix(info,sock)

   Write via FIFO file or UNIX socket a lot of information
   regarding the request. Which information should be written may
   be control via the "tw_append" parameter.

   This functions can be used from REQUEST_ROUTE, FAILURE_ROUTE
   and BRANCH_ROUTE.

   Example 1-31. t_write_fifo/unix usage
...
modparam("tm","tw_append","append1:Email=avp[i:12];UA=hdr[User-Agent]")
modparam("tm","tw_append","append2:body=msg[body]")
...
t_write_fifo("voicemail/append1","/tmp/appx_fifo");
...
t_write_unix("logger/append2","/var/run/logger.sock");
...
     _________________________________________________________

1.4.14. t_check_trans()

   Returns true if the current request is associated to a
   transaction. The relationship between the request ans
   transaction is defined as follow:

     * non-CANCEL/non-ACK requests - is true if the request
       belongs to a transaction; if so, it means that the request
       is a retransmision.
     * CANCEL request - true if the cancelled INVITE transaction
       exists.
     * ACK request - true if the ACK is a local end-to-end ACK
       for an existent INVITE transaction.

   This function can be used from REQUEST_ROUTE and BRANCH_ROUTE.

   Example 1-32. t_check_trans usage
...
if ( is_method("CANCEL") ) {
        if ( t_check_trans() )
                t_relay();
        exit;
}
...
     _________________________________________________________

1.4.15. t_was_cancelled()

   Retuns true if called for an INVITE transaction that was
   explicitly cancelled by UAC side via a CANCEL request.

   This function can be used from ONREPLY_ROUTE, FAILURE_ROUTE.

   Example 1-33. t_was_cancelled usage
...
if (t_was_cancelled()) {
    log("transaction was cancelled by UAC\n");
}
...
     _________________________________________________________

1.4.16. t_on_failure(failure_route)

   Sets reply routing block, to which control is passed after a
   transaction completed with a negative result but before
   sending a final reply. In the referred block, you can either
   start a new branch (good for services such as
   forward_on_no_reply) or send a final reply on your own (good
   for example for message silo, which received a negative reply
   from upstream and wants to tell upstream "202 I will take care
   of it").

   As not all functions are available from failure route, please
   check the documentation for each function to see the
   permissions. Any other commands may result in unpredictable
   behavior and possible server failure.

   Only one failure_route can be armed for a request. If you use
   many times t_on_failure(), only the last one has effect.

   Note that whenever failure_route is entered, RURI is set to
   value of the winning branch.

   Meaning of the parameters is as follows:

     * failure_route - Reply route block to be called.

   This function can be used from REQUEST_ROUTE, BRANCH_ROUTE,
   ONREPLY_ROUTE and FAILURE_ROUTE.

   Example 1-34. t_on_failure usage
...
route {
        t_on_failure("1");
        t_relay();
}

failure_route[1] {
        seturi("sip:user@voicemail");
        append_branch();
        t_relay();
}
...
     _________________________________________________________

1.4.17. t_on_reply(reply_route)

   Sets reply routing block, to which control is passed each time
   a reply (provisional or final) for the transaction is
   received. The route is not called for local generated replies!
   In the referred block, you can inspect the reply and perform
   text operations on it.

   As not all functions are available from this type of route,
   please check the documentation for each function to see the
   permissions. Any other commands may result in unpredictable
   behavior and possible server failure.

   Only one onreply_route can be armed for a request. If you use
   many times t_on_reply(), only the last one has effect.

   If the processed reply is provisionla reply (1xx code), by
   calling the drop() function (exported by core), the execution
   of the route will end and the reply will not be forwarded
   further.

   Meaning of the parameters is as follows:

     * reply_route - Reply route block to be called.

   This function can be used from REQUEST_ROUTE, BRANCH_ROUTE,
   ONREPLY_ROUTE and FAILURE_ROUTE.

   Example 1-35. t_on_reply usage
...
route {
        t_on_reply("1");
        t_relay();
}

onreply_route[1] {
        if (t_check_status("1[0-9][0-9]")) {
                setflag(1);
                log("provisional reply received\n");
                if (t_check_status("183"))
                        drop;
        }
}
...
     _________________________________________________________

1.4.18. t_on_branch(branch_route)

   Sets a branch route to be execute separately for each branch
   of the transaction before being sent out - changes in that
   route should reflect only on that branch.

   As not all functions are available from this type of route,
   please check the documentation for each function to see the
   permissions. Any other commands may result in unpredictable
   behavior and possible server failure.

   Only one branch_route can be armed for a request. If you use
   many time t_on_branch(), only the last one has effect.

   The per-branch flags which are modified in the branch route
   will be visible only in the replies related to that branch.
   See Section 1.3.17 also.

   By calling the drop() function (exported by core), the
   execution of the branch route will end and the branch will not
   be forwarded further.

   Meaning of the parameters is as follows:

     * branch_route - Branch route block to be called.

   This function can be used from REQUEST_ROUTE, BRANCH_ROUTE,
   ONREPLY_ROUTE and FAILURE_ROUTE.

   Example 1-36. t_on_branch usage
...
route {
        t_on_reply("1");
        t_relay();
}

branch_route[1] {
        if (uri=~"bad_uri") {
                xlog("dropping branch $ru \n");
                drop;
        }
        if (uri=~"GW_uri") {
                append_rpid();
        }
}
...
     _________________________________________________________

1.5. Pseudo-Variables

   This module exports the follong pseudo-variables:

     * $T_branch_index - the index (starting with 1 for the first
       branch) of the branch for which is executed the
       branch_route[]. If used outside of branch_route[] block,
       the value is '0'.
     _________________________________________________________

Chapter 2. Developer's Guide

2.1. Functions

2.1.1. load_tm(*import_structure)

   For programmatic use only--import the TM API. See the cpl-c,
   acc or jabber modules to see how it works.

   Meaning of the parameters is as follows:

     * import_structure - Pointer to the import structure - see
       "struct tm_binds" in modules/tm/tm_load.h
     _________________________________________________________

Chapter 3. Frequently Asked Questions

   3.1. Where can I find more about OpenSER?
   3.2. Where can I post a question about this module?
   3.3. How can I report a bug?

   3.1. Where can I find more about OpenSER?

   Take a look at http://openser.org/.

   3.2. Where can I post a question about this module?

   First at all check if your question was already answered on
   one of our mailing lists:

     * User Mailing List -
       http://openser.org/cgi-bin/mailman/listinfo/users
     * Developer Mailing List -
       http://openser.org/cgi-bin/mailman/listinfo/devel

   E-mails regarding any stable OpenSER release should be sent to
   <users@openser.org> and e-mails regarding development versions
   should be sent to <devel@openser.org>.

   If you want to keep the mail private, send it to
   <team@openser.org>.

   3.3. How can I report a bug?

   Please follow the guidelines provided at:
   http://sourceforge.net/tracker/?group_id=139143.