Kamailio module tm
Overview
Kamailio module tm 내용 정리.
Functions
t_is_set(target)
Return true if the attribute specified by 'target' is set for transaction.
The target parameter can be:
- branch_route: the function returns true if a branch route is set to be executed.
- failure_route: the function returns true if a failure route is set to be executed.
- onreply_route: the function returns true if an onreply route is set to be executed.
if(!t_is_set("failure_route")) {
LM_DBG("no failure route will be executed for current transaction\n");
}
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 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 taht the set of commands which are usable within faulure_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 fialure_route in 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:
- failure_route: Failure route block to be called.
...
route {
t_on_failure("1");
t_relay();
}
failure_route[1] {
revert_uri();
setuser("voicemail");
append_branch();
}
...
See misc/examples/mixed/onr.cfg for a more complex example of combination of serial with parallel forking.
t_relay([host, port])
Relay a message statefuly either to the destination 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 stateful 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.
if (!t_relay())
{
sl_reply_error();
break;
};
t_reply(code, reason_phrase)
Sends a stateful reply after a transaction has been established. See t_newtran for usage.
If the code is in the range 300-399 (redirect reply), the current destination set is appended to the reply as Contact headers. The destination set contains the request URI(R-URI), if it is modified compared to the received one, plus the branches added to the request(e.g., after an append_branch() or lookup("location")). If the R-URI was changed but it is not desired to be part of the destination set, it can be reverted using the function revert_uri().
Custom headers to the reply can be added using append_to_reply() function from textops module.
Parameters:
- code: Reply code number.
- reaons_phrase: Reason string.
...
t_reply("404", "Not found");
...
# block call redirect based on 3xx replies.
if (t_check_status("3[0-9][0-9]")) {
t_reply("404", "Not found");
exit;
}
...