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 statefuly. 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 unresolveable destination, use stateful mode. Then, only the initial message burdens
server by DNS queries, subsequent retranmissions 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 two major functions :
   t_relay and  t_relay_to.

Both 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 forwards to a specific address.

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

• SER Module TM Documentation

Dependencies

TM depends on

• No other SER module

---

Back to SIP Express Router