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 <mico...@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 <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 >> >> > > -- > 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