extract from http://kamailio.org/dokuwiki/doku.php/core-cookbook:1.3.x
debug
Set the debug level. Higher values make SER to print more debug messages.
Examples of usage:
debug=3 -- print only important messages (like errors or more critical situations) - recommended for running proxy as daemon
debug=9 -- print a lot of debug messages - use it only when doing debugging sessions
The ‘debug’ parameter is usually used in concordance with ‘log_stderror’ parameter.
log_stderror
With this parameter you can make OpenSER to write log and debug messages to standard error. Possible values are:
– “yes” – write the messages to standard error
– “no” – write the messages to syslog
Default value is “no”.
log_facility
If OpenSER logs to syslog, you can control the facility for logging. Very
useful when you want to divert all OpenSER logs to a different log file.
See the man page syslog(3) for more details.
Default value is LOG_DAEMON.
fork
If set to ‘yes’ the proxy will fork and run in daemon mode – one process will be created for each network interface the proxy listens to and for each protocol (TCP/UDP), multiplied with the value of ‘children’ parameter.
When set to ‘no’, the proxy will stay bound to the terminal and runs as single process. First interface is used for listening to.
Default value is ‘yes’.
children
Number of children to fork for the UDP interfaces (one set for each interface – ip:port). Default value is 8.
port
The port the SIP server listens to. The default value for it is 5060.
mpath
Set the module search path. This can be used to simplify the loadmodule parameter
Example of usage:
mpath="/usr/local/lib/openser/modules" loadmodule "mysql.so" loadmodule "uri.so" loadmodule "uri_db.so" loadmodule "sl.so" loadmodule "tm.so" ...
route
Request routing block. It contains a set of actions to be taken for SIP requests.
The main ‘route’ block identified by ‘route{…}’ or ‘route[0]{…}’ is executed for each SIP request.
The implicit action after execution of the main route block is to drop the SIP request. To send a reply or forward the request, explicit actions must be called inside the route block.
Example of usage:
route {
if(is_method("OPTIONS")) {
# send reply for each options request
sl_send_reply("200", "ok");
exit();
}
route(1);
}
route[1] {
# forward according to uri
forward();
}
Note that if a ‘route(X)’ is called from a ‘branch_route[Y]’ then in ‘route[X]’ is just processed each separate branch instead of all branches together as occurs in main route.
branch_route
Request’s branch routing block. It contains a set of actions to be taken for each branch of a SIP request. It is executed only by TM module after it was armed via t_on_branch(“branch_route_index”).
Example of usage:
route {
lookup("location");
t_on_branch("1");
if(!t_relay()) {
sl_send_reply("500", "relaying failed");
}
}
branch_route[1] {
if(uri=~"10\.10\.10].10") {
# discard branches that go to 10.10.10.10
drop();
}
}
failure_route
Failed transaction routing block. It contains a set of actions to be taken each transaction that received only negative replies (>=300) for all branches. The ‘failure_route’ is executed only by TM module after it was armed via t_on_failure(“failure_route_index”).
Note that in ‘failure_route’ is processed the request that initiated the transaction, not the reply .
Example of usage:
route {
lookup("location");
t_on_failure("1");
if(!t_relay()) {
sl_send_reply("500", "relaying failed");
}
}
failure_route[1] {
if(is_method("INVITE")) {
# call failed - relay to voice mail
t_relay_to_udp("voicemail.server.com","5060");
}
}
onreply_route
Reply routing block. It contains a set of actions to be taken for SIP replies.
The main ‘onreply_route’ identified by ‘onreply_route {…}’ or ‘onreply_route[0] {…}’ is executed for all replies received.
Certain ‘onreply_route’ blocks can be executed by TM module for special replies. For this, the ‘onreply_route’ must be armed for the SIP requests whose replies should be processed within it, via t_on_reply(“onreply_route_index”).
route {
lookup("location");
t_on_reply("1");
if(!t_relay()) {
sl_send_reply("500", "relaying failed");
}
}
onreply_route[1] {
if(status=~"1[0-9][0-9]") {
log("provisional response\n");
}
}