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 <mico...@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@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
>
>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
