1

I'm using pseudo-variables $var in Kamailio because according to the documentation, they are faster than $dlg_var, but I'm wondering if it's safe to use them like this:

jansson_get("a", $http_rb, "$var(a)");

$var(i) = 0;
jansson_array_size("elements", $http_rb, "$var(elements_size)");

while($var(i) < $var(elements_size)) {
    jansson_get("elements[$var(i)].key", $http_rb, "$var(key)");
    jansson_get("elements[$var(i)].value", $http_rb, "$var(value)");
    insert_hf("$var(key): $var(value)\r\n");
    $var(i) = $var(i) + 1;
}

if ($var(a) == "some value") {
    route(RELAY);
}

I tried setting Kamailio with one process in configuration file, just to see how one Kamailio process processes messages. Then I made two calls at the same time and according to my logs it seems that messages are processed concurrently (I'm not sure if there are multiple threads in one Kamailio process).

So, my question is: Is it possible for concurrent messages to overwrite the value of $var (because it is shared variable for all messages processed by the same Kamailio process) and is there a safe way of using $var to minimize or eliminate that possibility?

I read the documentation and it states:

"Note: A script variable persists over the Kamailio process in which it was initialized, so be sure of giving it a new value before reading it or you'll get the value asigned in any other previous message processed by the same Kamailio process (pid)."

This note makes me think that messages are processed sequentially, or that at least I could safely use the $var while processing a single message. How can I be sure that value I give will not be changed while I'm still using it?

Loky
  • 13
  • 2

4 Answers4

4

Concurrent processing is not overwriting $var(x) variables, the value of $var(x) is stored in the private memory of the process. Kamailio is not using threads to process SIP traffic, parallel processing of SIP messages can happen only if you have configured Kamailio to start more than one SIP worker process.

In other words, looking at your example, $var(a) cannot be overwritten while processing that specific SIP message, no matter how many other SIP messages are handled by other SIP worker processes. The $var(a) value will be updated next time the same SIP worker process handles a new message and jansson_get("a", "$http_rb", "$var(a)") is executed again with a different value for $http_rb.

As a side note, $http_rb is not a valid variable with the standard Kamailio distribution, but I guess you either wrote your own extension or was given for the sake of this example.

miconda
  • 1,754
  • 11
  • 14
0

Values of $vars variables cleared at the start of new message loop.

So for the single message, it is safe.

Kamailio run X threads(configurable in config/at startup), the main loop send each message to one of threads. That way processing can go concurent and use all CPUs.

arheops
  • 15,544
  • 1
  • 21
  • 27
  • Actually $var(...) variables are not reset/cleared at the start of new SIP message processing, their value persist per process across many SIP message processing. They are updated only upon explicit assignment or being output param for function in config. No automatic update (reset or some other value) from the script interpreter. – miconda Mar 25 '20 at 19:38
0

If you are wanting a variable that's scope is for the SIP transaction and not the process (child), you probably want to use an $avp.

Kamailio Mailing List Discussion $var vs $avp

Sam Ware
  • 131
  • 9
0

Is it possible for concurrent messages to overwrite the value of $var (because it is shared variable for all messages processed by the same Kamailio process)

It is not possible for your $var(i) to be overwritten while that message is being processed, and use of the private variable as a loop iterator (making sure to set it to 0 before beginning the loop as you have done here) is fine. The biggest issues occur when the variable is not reinitialized (it does not automatically reset with a new message), or when someone assumes that the same variable will be accessible in reply or failure routes.

whosgonna
  • 1
  • 2