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:5.2.x:core [2019/10/30 00:07] joelsdc |
cookbooks:5.2.x:core [2019/10/30 00:25] joelsdc |
||
---|---|---|---|
Line 2974: | Line 2974: | ||
==== route ==== | ==== route ==== | ||
- | This block is used to define ' | + | 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 that received only negative replies (>=300) for all branches. The ' | ||
+ | |||
+ | Note that in ' | ||
+ | |||
+ | |||
+ | Example of usage: | ||
+ | |||
+ | <code c> | ||
+ | request_route { | ||
+ | lookup(" | ||
+ | t_on_failure(" | ||
+ | if(!t_relay()) { | ||
+ | sl_send_reply(" | ||
+ | } | ||
+ | } | ||
+ | failure_route[TOVOICEMAIL] { | ||
+ | if(is_method(" | ||
+ | # call failed - relay to voice mail | ||
+ | | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | ==== reply_route ==== | ||
+ | |||
+ | Main SIP response (reply) handling block - it contains a set of actions to be executed for SIP replies. It is executed for all replies received from the network. | ||
+ | |||
+ | It does not have a name and it is executed by the core, before any other module handling the SIP reply. It is triggered only by SIP replies received on the network. | ||
+ | |||
+ | There is no network route that can be enforced for a SIP reply - it is sent based on Via header, according to SIP RFC3261 - therefore no dedicated actions for forwarding the reply must be used in this block. | ||
+ | |||
+ | This routing block is optional, if missing, the SIP reply is sent to the address in 2nd Via header. | ||
+ | |||
+ | One can decide to drop a SIP reply by using **drop** action. | ||
+ | |||
+ | Example: | ||
+ | |||
+ | <code c> | ||
+ | reply_route { | ||
+ | if(status==" | ||
+ | drop; | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | <fc # | ||
+ | |||
+ | ==== onreply_route ==== | ||
+ | |||
+ | |||
+ | SIP reply routing block executed by **tm** module. It contains a set of actions to be taken for SIP replies in the contect of an active transaction. | ||
+ | |||
+ | The ' | ||
+ | |||
+ | Core ' | ||
+ | |||
+ | <code c> | ||
+ | request_route { | ||
+ | lookup(" | ||
+ | t_on_reply(" | ||
+ | if(!t_relay()) { | ||
+ | sl_send_reply(" | ||
+ | } | ||
+ | } | ||
+ | |||
+ | reply_route { | ||
+ | if(!t_check_trans()) { | ||
+ | drop; | ||
+ | } | ||
+ | } | ||
+ | |||
+ | onreply_route[LOGRPL] { | ||
+ | if(status=~" | ||
+ | | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | ==== onsend_route ==== | ||
+ | |||
+ | The route is executed in when a SIP request is sent out. Only a limited number of commands are allowed (drop, if + all the checks, msg flag manipulations, | ||
+ | |||
+ | In this route the final destination of the message is available and can be checked (with snd_ip, snd_port, to_ip, to_port, snd_proto, snd_af). | ||
+ | |||
+ | This route is executed only when forwarding requests - it is not executed for replies, retransmissions, | ||
+ | |||
+ | Example: | ||
+ | |||
+ | <code c> | ||
+ | onsend_route { | ||
+ | if(to_ip==1.2.3.4 && !isflagset(12)){ | ||
+ | log(1, " | ||
+ | drop; | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | * snd_ip, snd_port - behave like src_ip/ | ||
+ | * to_ip, to_port - like above, but contain the ip/port the message will be sent to (not to be confused with dst_ip/ | ||
+ | * snd_proto, snd_af - behave like proto/af but contain the protocol/ | ||
+ | * msg:len - when used in an onsend_route, |