This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
cookbooks:devel:core [2019/10/11 14:18] miconda [udp_mtu_try_proto] |
cookbooks:devel:core [2019/10/31 18:36] henningw spelling fix |
||
---|---|---|---|
Line 9: | Line 9: | ||
===== Structure ===== | ===== Structure ===== | ||
- | The structure of the kamailio.cfg can be seen as thee parts: | + | The structure of the kamailio.cfg can be seen as three parts: |
* global parameters | * global parameters | ||
Line 253: | Line 253: | ||
* **# | * **# | ||
* **# | * **# | ||
+ | |||
+ | Predefined keywords: | ||
+ | * **KAMAILIO_X[_Y[_Z]]** - Kamailio versions | ||
+ | * **MOD_X** - when module X has been loaded | ||
+ | See ' | ||
Among benefits: | Among benefits: | ||
Line 2987: | Line 2992: | ||
Add " | Add " | ||
+ | |||
===== Custom Global Parameters ===== | ===== Custom Global Parameters ===== | ||
- | These are parameters that can be defined by the writer of kamailio.cfg in order to be used inside routing blocks. | + | These are parameters that can be defined by the writer of kamailio.cfg in order to be used inside routing blocks. |
+ | |||
+ | The definition of a custom global parameter must follow the pattern: | ||
+ | |||
+ | < | ||
+ | group.variable = value desc " | ||
+ | |||
+ | </ | ||
+ | |||
+ | The value can be a quoted string or integer number. | ||
+ | |||
+ | Example: | ||
+ | |||
+ | <code c> | ||
+ | pstn.gw_ip = " | ||
+ | </ | ||
+ | |||
+ | The custom global parameter can be accessed inside a routing block via: | ||
+ | |||
+ | < | ||
+ | $sel(cfg_get.group.variable) | ||
+ | </ | ||
+ | |||
+ | Example: | ||
+ | |||
+ | <code c> | ||
+ | $ru = " | ||
+ | </ | ||
+ | |||
+ | **Note:** Some words cannot be used as (part of) names for custom variables or groups, and if they are used a syntax error is logged | ||
+ | |||
+ | ===== Routing Blocks ===== | ||
+ | |||
+ | The routing blocks are the parts of the configuration file executed by kamailio at runtime. They can be seen as blocks of actions similar to functions (or procedures) from common programming languages. | ||
+ | |||
+ | A routing block is identified by a specific token, followed by a name in between square brackets and actions in between curly braces. | ||
+ | |||
+ | <code c> | ||
+ | route_block_id[NAME] { | ||
+ | ACTIONS | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | The name can be any alphanumeric string, with specific routing blocks enforcing a particular format. | ||
+ | |||
+ | <fc # | ||
+ | |||
+ | Route blocks can be executed on network events (e.g., receiving a SIP message), timer events (e.g., retransmission timeout) or particular events specific to modules. | ||
+ | |||
+ | There can be so called sub-route blocks, which can be invoked from another route blocks, like a function. Invocation is done with ' | ||
+ | |||
+ | Example: | ||
+ | |||
+ | <code c> | ||
+ | request_route{ | ||
+ | ... | ||
+ | route(" | ||
+ | ... | ||
+ | } | ||
+ | |||
+ | route[" | ||
+ | ... | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | ==== request_route ==== | ||
+ | |||
+ | Request routing block - is executed for each SIP request. | ||
+ | |||
+ | It contains a set of actions to be executed for SIP requests received from the network. It is the equivalent of *main()* function for handling the SIP requests. | ||
+ | |||
+ | <fc # | ||
+ | |||
+ | 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 (e.g., sl_send_reply(), | ||
+ | |||
+ | Example of usage: | ||
+ | |||
+ | <code c> | ||
+ | request_route { | ||
+ | | ||
+ | # send reply for each options request | ||
+ | sl_send_reply(" | ||
+ | exit(); | ||
+ | } | ||
+ | | ||
+ | } | ||
+ | route[FWD] { | ||
+ | # forward according to uri | ||
+ | | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | ==== route ==== | ||
+ | |||
+ | This block is used to define ' | ||
+ | |||
+ | The definition of the sub-route block follows the general rules, with a name in between square brackets and actions between curly braces. A sub-route can return an integer value back to the routing block that executed it. The return code can be retrieved via $rc variables. | ||
+ | |||
+ | Evaluation of the return of a subroute is done with following rules: | ||
+ | * negative value is evaluated as false | ||
+ | * 0 - is interpreted as **exit** | ||
+ | * positive value is evaluated as true | ||
+ | |||
+ | |||
+ | <code c> | ||
+ | request_route { | ||
+ | if(route(POSITIVE)) { | ||
+ | xlog(" | ||
+ | } | ||
+ | if( ! route(NEGATIVE)) { | ||
+ | xlog(" | ||
+ | } | ||
+ | if( route(ZERO)) { | ||
+ | xlog(" | ||
+ | } | ||
+ | } | ||
+ | |||
+ | route[POSITIVE] { | ||
+ | return 10; | ||
+ | } | ||
+ | |||
+ | route[NEGATIVE] { | ||
+ | return -8; | ||
+ | } | ||
+ | |||
+ | route[ZERO] { | ||
+ | return 0; | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | A sub-route can execute another sub-route. There is a limit to the number of recursive levels, avoiding ending up in infinite loops -- see **max_recursive_level** global parameter. | ||
+ | |||
+ | The sub-route blocks allow to make the configuration file modular, simplifying the logic and helping to avoid duplication of actions. | ||
+ | ==== branch_route ==== | ||
+ | |||
+ | Request' | ||
+ | |||
+ | Example of usage: | ||
+ | |||
+ | <code c> | ||
+ | request_route { | ||
+ | lookup(" | ||
+ | t_on_branch(" | ||
+ | if(!t_relay()) { | ||
+ | sl_send_reply(" | ||
+ | } | ||
+ | } | ||
+ | branch_route[OUT] { | ||
+ | if(uri=~" | ||
+ | # 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 th |