Žilinská univerzita > Fakulta riadenia a informatiky > Katedra informačných sietí

openser.cfg

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");
    }
}
Groups: