[SR-Users] Dispatcher module OPTIONS and event routes: how are they handled by core?
George Diamantopoulos
georgediam at gmail.com
Thu Dec 21 18:15:05 CET 2017
Hello Daniel,
A URI param doesn't sound bad at all for this purpose, and works like a
charm! I believe the parameter never makes it to the receiving end when
using regular dispatcher functionality, as the R-URI is not rewritten and
only the $du variable is set with this URI, which never appears in the SIP
message anywhere, right? So there's some degree of elegance here as well
:-D.
Thanks again for the workaround, I've been working on this for a while...
Best regards,
George
On 20 December 2017 at 17:26, Daniel-Constantin Mierla <miconda at gmail.com>
wrote:
> 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 | 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
>>
>>
>
> --
> 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/20171221/2594b74c/attachment.html>
More information about the sr-users
mailing list