[SR-Users] Dispatcher module OPTIONS and event routes: how are they handled by core?

George Diamantopoulos georgediam at gmail.com
Mon Dec 18 13:33:37 CET 2017


Hello all,

I use the dispatcher module extensively for load balancing and fail-over.
My kamailio instance is multihomed, and I use the "socket" attribute to
determine which socket SIP messages should use for each dispatcher
destination, as such:

+----+-------+-------------------------+-------+----------+-----------------------------+
| id | setid | destination             | flags | priority |
attrs                       |
+----+-------+-------------------------+-------+----------+-----------------------------+
|  1 |     0 | sip:192.168.0.1:5060    |     8 |        0 | socket=udp:
10.10.10.1:5060  |
|  2 |     1 | sip:111.111.11.1:5060   |     8 |        0 | socket=udp:
44.44.44.1:5060  |
|  3 |     1 | sip:222.222.22.2:5060   |     8 |        0 | socket=udp:
55.55.55.1:5060  |
+----+-------+-------------------------+-------+----------+-----------------------------+

The dispatcher module uses OPTIONS to probe each destination for
availability. When a destination goes down or up, the respective
event-route is executed.

What I need to do is to be able to "capture" the sending socket used for
this probing when a destination becomes unavailable or available in the
event-routes. The $fs variable is set, but unfortunately its value does not
make sense. Here's an example route and the results that are printed:

event_route[dispatcher:dst-down] {
    xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru $T_req($fs)
$T_req($Ru)\n");
}

Now say destination with id = '2' goes down. This is what I get in the logs
for the event_route above:

ERROR: <script>: Destination down: OPTIONS sip:111.111.11.1:5060 (sip:
192.168.0.1:5060) Contact: <sip:111.111.11.1:5060> udp:10.10.10.1:5060
<null> <null> <null>

The xlog PV/log mapping for the above line is the following:

$rm: OPTIONS
$ru: sip:111.111.11.1:5060
$du: sip:192.168.0.1:5060
$ds: Contact: <sip:111.111.11.1:5060>
$Ru: udp:10.10.10.1:5060
The rest are $null. $ru and $ds are consistent with the actual destination
being probed, $du and $fs are not (the are set to values corresponding to
id = '1', for some reason).

This log line is, of course, inaccurate. Not only does it not make sense,
but also this is not consistent with messages captured on network
interfaces using sngrep: Kamailio does indeed behave as it should, the
OPTIONS is sent out to 111.111.11.1 from socket
udp:44.44.44.1:5060. But this is not reflected in the log entry above when
the event_route is executed.

Now the weird part is that this OPTIONS "transaction" (which is locally
generated by kamailio) has the $du PV set to the value of another
destination (namely the that of id = '1'). As a result, the $fs PV is
consistent with that choice for $du. I can verify with sngrep that this is
not the case in reality, as the request was sent to destination id = '2'
from the correct socket as indicated above.

What I would like to ask is whether these "OPTIONS" used by dispatcher for
probing go through the request_route processing at some point. This is the
only way that would explain the $du PV being set to a false value. If yes,
is there any way to prevent this from happening? I need to be able to
access the $fs PV when a destination goes up or down, and I can't have any
other configuration file routes interfering with that. Thanks!

Best regards,
George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171218/e4252cc6/attachment.html>


More information about the sr-users mailing list