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

[Daniel-Constantin Mierla]

Hello,

those event routes are executed with a so called faked request (a
request generated internally, unrelated to the OPTIONS request sent to
the wire), apart of request uri, the rest of values are not related to
the dispatcher records.

To get access to other attributes of dispatcher records in a straight
way in the config, it would require C coding, Anyhow, even now using
scripting, you can try with sql queries to database or rpc commands
execution via jsonrpcs module and then parse the result using jansson
module.

Cheers,
Daniel


On 18.12.17 13:33, George Diamantopoulos wrote:
> 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 <http://192.168.0.1:5060>    |    
> 8 |        0 | socket=udp:10.10.10.1:5060 <http://10.10.10.1:5060>  |
> |  2 |     1 | sip:111.111.11.1:5060 <http://111.111.11.1:5060>  
> |     8 |        0 | socket=udp:44.44.44.1:5060
> <http://44.44.44.1:5060>  |
> |  3 |     1 | sip:222.222.22.2:5060 <http://222.222.22.2:5060>  
> |     8 |        0 | socket=udp:55.55.55.1:5060
> <http://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 <http://192.168.0.1:5060>) Contact:
> <sip:111.111.11.1:5060> udp:10.10.10.1:5060 <http://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 <http://192.168.0.1:5060>
> $ds: Contact: <sip:111.111.11.1:5060>
> $Ru: udp:10.10.10.1:5060 <http://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 <http://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
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171220/bccd24a7/attachment.html>