Kamailio module tm: Difference between revisions
Line 17: | Line 17: | ||
=== t_on_failure(failure_route) === | === 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. | 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. | |||
<pre> | |||
... | |||
route { | |||
t_on_failure("1"); | |||
t_relay(); | |||
} | |||
failure_route[1] { | |||
revert_uri(); | |||
setuser("voicemail"); | |||
append_branch(); | |||
} | |||
... | |||
</pre> | |||
See misc/examples/mixed/onr.cfg for a more complex example of combination of serial with parallel forking. | |||
=== t_relay([host, port]) === | === t_relay([host, port]) === |
Revision as of 10:49, 18 March 2020
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; };