Standard
TM module enables statefuli [1] processing of SIP transactionsi [2]. The main use of stateful logic, which is costly in terms of memory and CPU, is some services inherently need state. For example, transactioni [3]-based accounting (module acc) needs to process transaction state as opposed to individual messages, and any kinds of forkingi [4] must be implemented statefully. Other use of stateful processing is it trading CPU caused by retransmissioni [5] 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 retransmissionsi [6] will be dropped and will not result in more processes blocked by DNS resolution. The price is more memory consumption and higher processing latency.
Jiri Kuthan
i [7] processing of SIP transactionsi [8]. The main use of stateful logic, which is costly in terms of memory and CPU, is some services inherently need state. For example, transactioni [9]-based accounting (module acc) needs to process transaction state as opposed to individual messages, and any kinds of forkingi [10] must be implemented statefully. Other use of stateful processing is it trading CPU caused by retransmissioni [11] 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 retransmissionsi [12] 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 upstreami [13], generate downstreami [14] retransmissions and correlate replies to requests. t_relay forwards to current URIi [15] (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 and 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 UACi [16]--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.
i [17] 2.1).
Possibly, performance could be improved by not parsing non-INVITEs, as they do not be replied with 100, and do not result in ACK/CANCELs, and other things which take parsing. However, we need to rethink whether we don't need parsed headers later for something else. Remember, when we now conserver a request in sh_mem, we can't apply any pkg_mem operations to it any more. (that might be redesigned too).
Another performance improvement may be achieved by not parsing CSeqi [18] in replies until reply branchi [19] matches branch of an INVITE/CANCEL in transaction table.
t_replicate should be done more cleanly--Vias, Routes, etc. should be removed from a message prior to replicating it (well, does not matter any longer so much as there is a new replication module).
i [20]) and sending a message on a unix socket takes longer then unix_tx_timeout, the send will fail.
The default value is 500 milliseconds.
The default value is 1, only INVITEs trigger blacklisting
fifo="/tmp/ser_fifo"
Then, an application can easily launch a new transaction by writing a transaction request to this named pipe. The request must follow very simple format, which is
:t_uac_from:[<file_name>]\n <method>\n <sender's uri>\n <dst uri>\n <CR_separated_headers>\n <body>\n .\n \n
(Filename is to where a report will be dumped. ser assumes /tmp as file's directory.)
Note the request write must be atomic, otherwise it might get intermixed with writes from other writers. You can easily use it via Unix command-line tools, see the following example:
[jiri@bat jiri]$ cat > /tmp/ser_fifo :t_uac_from:xxx MESSAGE sip:sender@iptel.org sip:mrx@iptel.org header:value foo:bar bznk:hjhjk p_header: p_value body body body yet body end of body .
or cat test/transaction.fifo > /tmp/ser_fifo
i [24]. Without it, to-tags are ignored. It is
disabled by default for two reasons:
-
It eliminates an unlikely race condition in which
transaction's to-tagi [25] is being rewritten by a 200 OK
whereas an ACK is being looked up by to-tag.
-
It makes UACs happy who set wrong to-tags.
-
It eliminates an unlikely race condition in which transaction's to-tagi [25] is being rewritten by a 200 OK whereas an ACK is being looked up by to-tag.
-
It makes UACs happy who set wrong to-tags.
It should not make a difference, as there may be only one negative reply sent upstream and 200/ACKs are not matched as they constitute another transaction. It will make no difference at all when the new magic cookie matching is enabled anyway.
CANCEL_TAG similarly enables strict matching of CANCELs including to-tags--act of mercy to UACs, who screw up the to-tags (however, it still depends on how forgiving the downstream UAS is). Like with ACK_TAG, all this complex transactions matching goes with RFC3261 [26]'s magic cookie away anyway.
For programmatic use only--register a function to be called back on an event. See t_hooks.h for more details.
Meaning of the parameters is as follows:
-
cb_type - Callback type.
-
cb_func - Callback function.
http://www.iptel.org/ser/doc/modules/tm
Links:
[1] http://www.iptel.org/glossary#term71
[2] http://www.iptel.org/glossary#term69
[3] http://www.iptel.org/glossary#term69
[4] http://www.iptel.org/glossary#term68
[5] http://www.iptel.org/glossary#term72
[6] http://www.iptel.org/glossary#term72
[7] http://www.iptel.org/glossary#term71
[8] http://www.iptel.org/glossary#term69
[9] http://www.iptel.org/glossary#term69
[10] http://www.iptel.org/glossary#term68
[11] http://www.iptel.org/glossary#term72
[12] http://www.iptel.org/glossary#term72
[13] http://www.iptel.org/glossary#term79
[14] http://www.iptel.org/glossary#term78
[15] http://www.iptel.org/glossary#term81
[16] http://www.iptel.org/glossary#term76
[17] http://www.iptel.org/glossary/term/244
[18] http://www.iptel.org/glossary#term223
[19] http://www.iptel.org/glossary#term253
[20] http://www.iptel.org/glossary/term/288
[21] http://www.iptel.org/glossary#term75
[22] http://www.iptel.org/glossary#term68
[23] http://www.iptel.org/glossary/term/244
[24] http://www.iptel.org/glossary#term256
[25] http://www.iptel.org/glossary#term256
[26] http://www.ietf.org/rfc/rfc3261.txt