[SR-Users] Dispatcher module OPTIONS and event routes: how are they handled by core?
Daniel-Constantin Mierla
miconda at gmail.com
Wed Dec 20 16:26:07 CET 2017
Hello,
an workaround would be to add a custom parameter to the destination
value, like sip:1.2.3.4:5060;sid=1. Unknown parameters should be ignored
by the receiving party. Or if you have only two records with same
address, add to one ";transport=udp".
Of course, coding in C to make it easier in config would be the elegant
solution.
Cheers,
Daniel
On 20.12.17 15:32, George Diamantopoulos wrote:
> 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 <http://111.111.11.1:5060>
> | 8 | 0 | socket=udp:44.44.44.1:5060
> <http://44.44.44.1:5060> |
> | 2 | 10 | sip:111.111.11.1:5060 <http://111.111.11.1:5060>
> | 8 | 0 | socket=udp:55.55.55.1:5060
> <http://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 <mailto: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 <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 <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
> --
> Daniel-Constantin Mierla
> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
> Kamailio Advanced Training - www.asipto.com <http://www.asipto.com>
> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com <http://www.kamailioworld.com>
>
>
--
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/54dc4d76/attachment.html>
More information about the sr-users
mailing list