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

[George Diamantopoulos]

Hello Daniel,

Thanks for the reply. Unfortunately I can't really use the database records
to achieve what I want. The example in my previous message didn't show
this, but I would like to be able to differentiate between the following:

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

In this case, how can I tell which destination went down? The URI is the
same, but the sockets differ for each id.

If only $ru is available in these event routes, I can't query the database
because $ru matches both records. If I can't access the socket used with a
PV, is there any way to have access to *either* the id *or* the setid for
the destination for which the event was generated?

Thanks!

BR,
George

On 20 December 2017 at 10:57, Daniel-Constantin Mierla <miconda at gmail.com>
wrote:

> 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    |     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
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierlawww.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/5435dfbf/attachment.html>