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.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.

...
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.

...
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.

...
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.

...
modparam("tm", "delete_timer", 5)
...

1.3.5. retr_timer1p1 (integer)

Retransmission period.

Default value is 1 second.

...
modparam("tm", "retr_timer1p1", 2)
...

1.3.6. retr_timer1p2 (integer)

Retransmission period.

Default value is 2 * retr_timer1p1 second.

...
modparam("tm", "retr_timer1p2", 4)
...

1.3.7. retr_timer1p3 (integer)

Retransmission period.

Default value is 4 * retr_timer1p1 second.

...
modparam("tm", "retr_timer1p3", 8)
...

1.3.8. retr_timer2 (integer)

Maximum retransmission period.

Default value is 4 seconds.

...
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).

...
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).

...
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).

...
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.

...
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).

...
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".

...
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".

...
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 = [title '='] value

• value = ('avp['AVP_SPEC']') | 'hdr['HDR_NAME']' | 'msg[body]'

Each element will be appended per line in "title: value" format. If "title" is missing, the AVP or HDR name will be used. For "msg[body]", the title is irelevant.

...
modparam("tm", "tw_append",
    "test:ua=hdr[User-Agent];avpx=avp[i:13];msg[body]")
...

1.4.1. t_relay_to_udp(ip, port), t_relay_to_tcp(ip, port)

Relay a message statefully to a fixed destination. This along with t_relay is the function most users want to use--all other are mostly for programming. Programmers interested in writing TM logic should review how t_relay is implemented in tm.c and how TM callbacks work.

Meaning of the parameters is as follows:

• ip - IP address where the message should be sent.

• port - Port number.

...
t_relay_to_udp("1.2.3.4", "5060");
...

1.4.2. 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.

...
if (!t_relay()) { sl_reply_error(); break; };
...

1.4.3. t_on_negative(reply_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"). Note that the set of command which are usable within reply_routes is strictly limited to rewriting URI, initiating new branches, logging, and sending stateful replies (t_reply). Any other commands may result in unpredictable behavior and possible server failure. Note that whenever reply_route is entered, uri is reset to value which it had on relaying. If it temporarily changed during a reply_route processing, subsequent reply_route will ignore the changed value and use again the original one.

Meaning of the parameters is as follows:

• reply_route - Reply route block to be called.

...
route { 
	t_on_negative("1"); 
	t_relay(); 
} 

reply_route[1] {
	revert_uri(); 
	setuser("voicemail"); 
	append_branch(); 
}
...

See test/onr.cfg for a more complex example of combination of serial with parallel forking.

1.4.4. 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.

...
set_user("john"); 
t_fork(); 
set_user("alice");
t_fork(); 
t_relay();
...

1.4.5. 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.

...
if (t_newtran()) { 
	log("UAS logic"); 
	t_reply("999","hello"); 
} else sl_reply_error();
...

See test/uas.cfg for more examples.

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.

...
t_reply("404", "Not found");
...

1.4.7. 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.

...
if (t_lookup_request()) {
	...
};
...

1.4.8. t_retransmit_reply()

Retransmits a reply sent previously by UAS transaction.

...
t_retransmit_reply();
...

1.4.9. t_release()

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

...
t_release();
...

1.4.10. t_forward_nonack(ip, port) t_forward_nonack_udp(ip, port) t_forward_nonack_tcp(ip, port) t_forward_nonack_uri()

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

Meaning of the parameters is as follows:

• ip - IP address where the message should be sent.

• port - Port number.

t_forward_nonack_uri() will determin the detination address (proto:IP:port) based on the RURI.

...
t_forward_nonack("1.2.3.4", "5060");
t_forward_nonack_udp("1.2.3.4", "5060"); # force UDP proto
t_forward_nonack_tcp("1.2.3.4", "5060"); # force TCP proto
t_forward_nonack_uri();
...

1.4.11. t_replicate(ip, port) t_replicate_udp(ip, port) t_replicate_tcp(ip, port)

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

Meaning of the parameters is as follows:

• ip - IP address where the message should be sent.

• port - Port number.

...
t_replicate("1.2.3.4", "5060");
t_replicate_udp("1.2.3.4", "5060"); # force UDP proto
t_replicate_tcp("1.2.3.4", "5060"); # force TCP proto
...

1.4.12. 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.

...
if (t_check_status("(487)|(408)")) {
    log("487 or 408 negative reply\n");
}
...

1.4.13. 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.

...
t_flush_flags();
...

1.4.14. 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".

...
if (t_local_replied("all")) {
	log ("no reply received\n");
}
...

1.4.15. 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.

...
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");
...

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