Differences

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

--- cookbooks:devel:core [2019/02/22 19:00]
henningw [pv_buffer_size]
+++ cookbooks:devel:core [2019/03/28 08:54]
joelsdc [flags]
@@ Line 383: / Line 383: @@
 ===== Core Keywords =====
-Keywords specific to SIP messages which can be used mainly in '''if''' expressions.
+Keywords specific to SIP messages which can be used mainly in ''if'' expressions.
 ==== af ====
@@ Line 866: / Line 866: @@
 ==== flags ====
-**Alias name: bool**
+SIP message (transaction) flags can have string names.
+The //name// for flags cannot be used for **branch** or **script flags**(*)
+<code c>
+...
+flags
+  FLAG_ONE   : 1,
+  FLAG_TWO   : 2;
+...
+</code>
+(*) The named flags feature was propagated from the source code merge back in 2008 and is not extensively tested. The recommended way of defining flags is using [[cookbooks:5.2.x:core#define|#!define]] (which is also valid for branch/script flags):
+<code c>
+#!define FLAG_NAME FLAG_BIT
+</code>
 ==== force_rport ====
@@ Line 943: / Line 960: @@
 <code c>
 kemi.onsend_route_callback="ksr_my_onsend_route"
+</code>
+==== kemi.received_route_callback ====
+Set the name of callback function in the KEMI script to be executed as the equivalent of `event_route[core:msg-received]` block (from the native configuration file). For execution, it also require to have the received_route_mode global parameter set to 1.
+Default value: none
+Set it to empty string or "none" to skip execution of this callback function.
+Example:
+<code c>
+kemi.received_route_callback="ksr_my_receieved_route"
 </code>
@@ Line 1116: / Line 1147: @@
 ==== log_prefix ====
-Specify the text to be prefixed to the log messages printed by Kamailio while processing a SIP message. It can contain script variables that are evaluated at runtime (see log_prefix_mode about when/how evaluation is done).
+Specify the text to be prefixed to the log messages printed by Kamailio while processing a SIP message (that is, when executing route blocks). It can contain script variables that are evaluated at runtime.
+See [[#log_prefix_mode]] about when/how evaluation is done.
+If a log message is printed from a part of the code executed out of routing blocks actions (e.g., can be timer, evapi worker process, ...), there is no log prefix set, because this one requires a valid SIP message structure to work with.
 Example - prefix with message type (1 - request, 2 - response), CSeq and Call-ID:
@@ Line 1126: / Line 1161: @@
 ==== log_prefix_mode ====
-If set to 0 (default), then log_prefix is evaluated when the sip message is received and then reused (recommended if the log_prefix has only variables that have same value for same message). This is the current behaviour of log_prefix evaluation.
+Control if [[#log_prefix|log prefix]] is re-evaluated.
+If set to 0 (default), then log prefix is evaluated when the sip message is received and then reused (recommended if the **log_prefix** has only variables that have same value for same message). This is the current behaviour of **log_prefix** evaluation.
-If set to 1, then the log prefix is evaluated before/after each config action (needs to be set when the log_prefix has variables that are different based on the context of config execution, e.g., $cfg(line)).
+If set to 1, then the log prefix is evaluated before/after each config action (needs to be set when the **log_prefix** has variables that are different based on the context of config execution, e.g., $cfg(line)).
 Example:
@@ Line 1427: / Line 1464: @@
 <code>
 rundir="/tmp"
+</code>
+==== received_route_mode ====
+Enable or disable the execution of event_route[core:msg-received] routing block or its corresponding Kemi callback.
+Default value: 0 (disabled)
+Example of usage:
+<code c>
+received_route_mode=1
 </code>
@@ Line 3074: / Line 3123: @@
 <code c>
 reply_route {
-  if(status=="128"") {
+  if(status=="128") {
     drop;
   }
@@ Line 3143: / Line 3192: @@
   * groupid - should be the name of the module that triggers the event
   * eventid - some meaningful short text describing the event
+=== Core Event Routes ===
 Implementations:
@@ Line 3154: / Line 3205: @@
 }
 </code>
+  * **event_route[core:msg-received]** - executed when a message is received from the network. It runs with a faked request and makes available the $rcv(key) variables to access what was received and related attribtues.
+    * it has to be enabled with received_route_mode global parameter. For usage via Kemi, set kemi.received_route_callback global parameter.
+    * if drop is executed, the received message is no longer processed
+<code c>
+event_route[core:msg-received] {
+  xlog("rcv on $rcv(af)/$rcv(proto): ($rcv(len)) [$rcv(buf)] from [$rcv(srcip):$rcv(srcport)] to [$rcv(rcvip):$rcv(rcvport)]\n");
+  if($rcv(srcip) == "1.2.3.4") {
+    drop;
+  }
+}
+</code>
+=== Module Event Routes ===
+Here are only a few examples, to see if a module exports event_route blocks and when they are executed, check the readme of the module.
   * **event_route[htable:mod-init]** - executed by **htable** module after all modules have been initialised. Good for initialising values in hash tables.
@@ Line 3194: / Line 3262: @@
   * **event_route [tm:branch-failure]** - executed on all failure responses.
 <code c>
-event_route [tm:failure-branch] { # Handle failure response
+request_route {
+    ...
+    t_on_branch_failure("myroute");
+    t_relay();
+}
+event_route[tm:branch-failure:myroute] {
   xlog("L_INFO", "Handling $T_reply_code response to $rm to <$ru>\n");
   if (t_check_status("430")) { # Outbound flow failed
@@ Line 3203: / Line 3277: @@
   }
 }
 </code>

Kamailio SIP Server Wiki

User Tools

Site Tools

Differences

Page Tools