User Tools

Site Tools


cookbooks:5.2.x:core

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

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:16]
joelsdc
cookbooks:5.2.x:core [2019/10/30 00:27]
joelsdc
Line 3013: Line 3013:
  
 The sub-route blocks allow to make the configuration file modular, simplifying the logic and helping to avoid duplication of actions. The sub-route blocks allow to make the configuration file modular, simplifying the logic and helping to avoid duplication of actions.
 +==== 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:
 +
 +<code c>
 +    request_route {
 +        lookup("location");
 +        t_on_branch("OUT");
 +        if(!t_relay()) {
 +            sl_send_reply("500", "relaying failed");
 +        }
 +    }
 +    branch_route[OUT] {
 +        if(uri=~"10\.10\.10\.10") {
 +            # discard branches that go to 10.10.10.10
 +            drop();
 +        }
 +    }
 +</code>
 +
 +==== 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:
 +
 +<code c>
 +    request_route {
 +        lookup("location");
 +        t_on_failure("TOVOICEMAIL");
 +        if(!t_relay()) {
 +            sl_send_reply("500", "relaying failed");
 +        }
 +    }
 +    failure_route[TOVOICEMAIL] {
 +        if(is_method("INVITE")) {
 +             # call failed - relay to voice mail
 +             t_relay_to_udp("voicemail.server.com","5060");
 +        }
 +    }
 +</code>
 +
 +==== 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=="128"") {
 +    drop;
 +  }
 +}
 +</code>
 +
 +<fc #4682b4>Note: for backward compatibility reasons, the main 'reply' routing block can be also identified by 'onreply_route {...}' or 'onreply_route[0] {...}'.</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 'onreply_route' must be armed for the SIP requests whose replies should be processed within it, via t_on_reply("onreply_route_index").
 +
 +Core 'reply_route' block is executed before a possible **tm** 'onreply_route' block.
 +
 +<code c>
 +  request_route {
 +      lookup("location");
 +      t_on_reply("LOGRPL");
 +      if(!t_relay()) {
 +          sl_send_reply("500", "relaying failed");
 +      }
 +  }
 +
 +  reply_route {
 +      if(!t_check_trans()) {
 +          drop;
 +      }
 +  }
 +
 +  onreply_route[LOGRPL] {
 +      if(status=~"1[0-9][0-9]") {
 +           log("provisional response\n");
 +      }
 +  }
 +</code>
 +==== 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, send(), log(), textops::search()).
 +
 +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, or locally generated messages (e.g. via fifo uac).
 +
 +Example:
 +
 +<code c>
 +  onsend_route {
 +    if(to_ip==1.2.3.4 && !isflagset(12)){
 +      log(1, "message blocked\n");
 +      drop;
 +    }
 +  }
 +</code>
 +
 +  * snd_ip, snd_port - behave like src_ip/src_port, but contain the ip/port Kamailio will use to send the message
 +  * to_ip, to_port - like above, but contain the ip/port the message will be sent to (not to be confused with dst_ip/dst_port, which are the destination of the original received request: Kamailio's ip and port on which the message was received)
 +  * snd_proto, snd_af - behave like proto/af but contain the protocol/address family that Kamailio will use to send the message
 +  * msg:len - when used in an onsend_route, msg:len will contain the length of the message on the wire (after all the changes in the script are applied, Vias are added a.s.o) and not the lentgh of the original message.
cookbooks/5.2.x/core.txt ยท Last modified: 2020/04/03 09:34 by henningw