To conclude this thread: the feature of sending keepalives from inside usrloc module and compute round trip time has been pushed to master branch, see the ka-related modparams:
* https://www.kamailio.org/docs/modules/devel/modules/usrloc.html#usrloc.p.ka_mode Still some work planned to be done there, then I will make a dedicated announcement -- for now, a few more details were added in the feature request tracker: * https://github.com/kamailio/kamailio/issues/2223#issuecomment-604937019 Testing and feedback is appreciated. Cheers, Daniel On 25.02.20 13:42, Daniel-Constantin Mierla wrote: > > > On 19.02.20 21:55, David Villasmil wrote: >> +1 here. This feature would be a BIG plus. I’m also interested in >> what Nuno pointed out, how is it decided which registrar will send >> the OPTIONS to the UAC if we have multiple registrars sharing >> contacts via DMQ? > > > What scenarios/network topologies are considered here? The registrar > servers being behind an edge proxy (sbc) or also anycast? With no edge > proxy, the registrar server that received the register request has to > do the keepalive. > > Currently, iirc, the server_id can be used to group the contacts and > do keepalives from a specific server -- as done now by nathelper in > stateless mode. > > The feature is on my to-do list for quite some time, just didn't get a > long enough spare frame to start doing it. Hope to get to it soon, if > nobody else jumps in before. > > Cheers, > Daniel > > >> >> On Wed, 19 Feb 2020 at 20:18, Joel Serrano <[email protected] >> <mailto:[email protected]>> wrote: >> >> Just for future reference: >> >> https://github.com/kamailio/kamailio/issues/2223 >> >> On Tue, Apr 30, 2019 at 3:27 AM Rhys Hanrahan >> <[email protected] <mailto:[email protected]>> wrote: >> >> Hi Everyone, >> >> >> >> I would just like to add that I’m also very interested in >> several of the things Daniel mentioned in this thread. >> Particularly the RTT/latency information for NAT’d contacts >> is very useful – so that’s a +1 from me. >> >> >> >> As someone who is trying to migrate from using Asterisk as >> our registrar, to using Kamailio, there’s several things >> Asterisk does with this info that our support team relies on >> heavily for day to day operations/support, and I need to find >> a way to replicate this behaviour. >> >> >> >> As an example of how we use this: >> >> >> >> * Asterisk will log when SIP endpoints become lagged or >> unreachable based on the OPTIONS RTT – so you can set a >> threshold and if a device takes too long to respond, >> Asterisk will log that it first Lagged, then Unreachable. >> * Asterisk will then log when a handset comes back online >> showing it as “Reachable”. >> >> >> >> This is a really handy way of historically trying to diagnose >> call drop outs or call quality issues, as you can quickly see >> with a few greps of syslog if all handsets at a particular IP >> at a particular time are dropping out at the same time, or >> not. While the goal would be to have proper monitoring of a >> customer’s internet connection, this can’t always be done. >> And having access to the latency on these NAT ping packets is >> extremely helpful in this case. Even with internet >> monitoring, having stats “per handset” is very useful. >> >> >> >> Not everyone would want to spam their logs with this info – >> but having access to the RTT information so you can decide >> what to do with it in your config is critical in my opinion. >> >> >> >> I was not aware of the UDP limitation of nathelper, but that >> explains some issues I saw, and that’s going to be an issue >> for us as well. >> >> >> >> So I would be very keen to see the features discussed >> further. I am trying to learn C at the moment so hopefully I >> can assist in some way in future as well. :-) >> >> >> >> Thanks, >> >> Rhys. >> >> >> >> *From: *sr-users <[email protected] >> <mailto:[email protected]>> on behalf of >> Nuno Ferreira <[email protected] <mailto:[email protected]>> >> *Reply-To: *"Kamailio (SER) - Users Mailing List" >> <[email protected] >> <mailto:[email protected]>> >> *Date: *Tuesday, 5 February 2019 at 1:37 am >> *To: *"Kamailio (SER) - Users Mailing List" >> <[email protected] >> <mailto:[email protected]>> >> *Subject: *Re: [SR-Users] Kamailio OPTIONS Round-Trip >> >> >> >> Hey there, >> >> >> >> Just trying to see if there was any conclusion on this topic... >> >> >> >> Thanks >> >> >> >> On Wed, Jan 16, 2019 at 3:18 PM Sergiu Pojoga >> <[email protected] <mailto:[email protected]>> wrote: >> >> After re-reading the original question, it appears that >> it isn't about Asterisk at all, it was a simple reference >> to it, the actual question being how to get RTT in >> Kamailios's usloc. >> >> >> >> Apologies for the confusion. Let's carry on with the >> topic, lol. >> >> >> >> Cheers, >> >> --Sergiu >> >> >> >> On Wed, Jan 16, 2019 at 9:55 AM Sergiu Pojoga >> <[email protected] <mailto:[email protected]>> wrote: >> >> Correct me if I'm wrong, but wasn't the original >> poster looking for Asterisk (behind Kamailio) to show >> the round-trip of its peers based on qualify OPTIONS >> requests that Asterisk sends out to the peer? >> >> >> >> If so, I'm curious what is the impediment not to >> accept the previously suggested sip PATH approach? >> Aside from elegance and simplicity to implement, it >> isn't even subject to the UDP limitation you've >> brought up. >> >> >> >> Not that the topic of usrloc qualify isn't >> of interest, but it just feels like we are drifting >> into another topic, although somehow related to the >> original one. >> >> >> >> Best regards, >> >> --Sergiu >> >> >> >> On Wed, Jan 16, 2019 at 7:59 AM Nuno Ferreira >> <[email protected] <mailto:[email protected]>> wrote: >> >> Hello Daniel, >> >> >> >> I'm reading this thread with some interests. We >> were planning to use nat_traversal module to do >> keepalive, but we came across the UDP only >> limitation. In our use case, we wanted to offload >> the registrar from doing keepalive. Of course, >> that's an option, but it has yet another >> limitation when having active/active registrar >> servers using dmq_usrloc. If one of the >> registrars goes down which server will be in >> charge of doing keepalive for the contacts >> previously registered on the faulty registrar? >> That was one of the reasons for us to seek doing >> keeplive on the edge with nat_traversal, but >> again it's only valid for UDP. >> >> If usrloc/dmq_usrloc provides some automatic >> election mechanism to keepalive orphan AORs, I >> would prefer going with it for the task. Another >> benefit like I read from your words is that we >> would automatically have available >> latency/rtt attached to each contact and that is >> a big plus. >> >> >> >> Regards, >> >> >> >> Nuno >> >> >> >> On Wed, Jan 16, 2019 at 12:26 PM >> Daniel-Constantin Mierla <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hello, >> >> maybe we can just add this feature to the >> usrloc module -- right now the nat keepalive >> is done from nathelper module, which queries >> usrloc module to retrieve the list of the >> contacts to send OPTIONS to. Of course, the >> nathelper has the other variant witj 4-bytes >> pings, but I expect not many are using it >> these days. >> >> Furthermore, because the nathelper has some >> options to forge the source ip address as >> well as willing to be lightweight, it sends >> the packets directly, no relying on tm module. >> >> However, it seems that it is an increase >> interest in having more feedback based on >> these keepalives. Including the ability to do >> mirroring for sipcapture (a feature request >> being open in the tracker). Other request in >> the past was to send OPTIONS also for non-UDP >> contacts, nathelper does it only for UDP. >> >> So we can consider adding a transaction based >> keepalive layer, which of course might take a >> bit more resources that current nathelper >> implementation, but can bring extra benefits. >> I think we can leave nathelper as it is and >> add this feature directly in the usrloc >> module, avoiding to pass data between >> modules, but also because we have to >> set/updates some fields in the contract >> structure (like this round trip time). >> >> There are other modules that do keepalive, >> some mentioned dispatcher, there is a >> dedicated one named keepalive, and, afaik, >> also nat_traversal can do it. I am listing >> them so others can assert where it would be >> better to add the new feature -- as said, I >> would do it in usrloc, but I am open for >> other suggestions as well (eventually >> accompanied with a pull request). >> >> Cheers, >> Daniel >> >> On 15.01.19 21:12, Julien Chavanton wrote: >> >> Depending on the use case, you could use >> the dispatcher module latency stats. >> >> >> >> >> https://kamailio.org/docs/modules/devel/modules/dispatcher.html#dispatcher.p.ds_ping_latency_stats >> >> >> >> Regards >> >> >> >> On Tue, Jan 15, 2019 at 2:29 AM Daniel >> Tryba <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Sun, Jan 13, 2019 at 10:08:31PM >> +0300, Soltanici Ilie wrote: >> > With Asterisk, we are able to get >> some peer round-trip connection >> statistic by setting qualify=yes for >> the specified peer. >> > It sends periodic OPTIONS to the >> peer and calculates the time round >> trip time. >> > It's something like - "Status: OK >> (30 ms)". >> > Is there any way to achieve this in >> Kamailio by using nathelper??module, >> or any other? >> >> I think the only way to do this is to >> make this yourself (tm). In your >> favorite scripting language, query >> the locations and fire OPTIONS and >> measure the time for a response (if >> any) on basis of the "random" callid >> you create. If you route these >> requests through kamailio you will >> prevent any NAT problems or >> connection with TCP endpoints. >> >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected] >> <mailto:[email protected]> >> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> >> _______________________________________________ >> >> Kamailio (SER) - Users Mailing List >> >> [email protected] >> <mailto:[email protected]> >> >> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> -- >> >> Daniel-Constantin Mierla -- www.asipto.com >> <http://www.asipto.com> >> >> www.twitter.com/miconda >> <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda >> <http://www.linkedin.com/in/miconda> >> >> Kamailio World Conference - May 6-8, 2019 -- >> www.kamailioworld.com <http://www.kamailioworld.com> >> >> Kamailio Advanced Training - Mar 4-6, 2019 in >> Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com >> <http://www.asipto.com> >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected] >> <mailto:[email protected]> >> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> >> >> -- >> >> *Nuno Ferreira* | Architect, CoreUC | >> [email protected] <mailto:[email protected]> | >> +351 308805903 >> Rua Carlos Silva Melo Guimarães 23, 3800-126 >> Aveiro, Portugal >> >> <https://www.google.com/maps/search/Rua+Carlos+Silva+Melo+Guimar%C3%A3es+23,+3800-126+Aveiro,+Portugal?entry=gmail&source=g> >> >> Image removed by sender. >> <http://www.facebook.com/fuze> Image removed by >> sender. <http://www.twitter.com/fuze> Image >> removed by sender. >> <https://www.linkedin.com/company/fuze-inc> Image >> removed by sender. >> <https://plus.google.com/110150232345018024360> Image >> removed by sender. >> <https://www.instagram.com/fuze_hq/> >> >> Image removed by sender. <http://www.fuze.com/> >> >> >> *Confidentiality Notice: The information >> contained in this e-mail and any >> attachments may be confidential. If you are not >> an intended recipient, you >> are hereby notified that any dissemination, >> distribution or copying of this >> e-mail is strictly prohibited. If you have >> received this e-mail in error, >> please notify the sender and permanently delete >> the e-mail and any >> attachments immediately. You should not retain, >> copy or use this e-mail or >> any attachment for any purpose, nor disclose all >> or any part of the >> contents to any other person. Thank >> you.*_______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected] >> <mailto:[email protected]> >> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected] >> <mailto:[email protected]> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> >> >> -- >> >> *Nuno Ferreira* | Architect, CoreUC | [email protected] >> <mailto:[email protected]> | +351 308805903 >> Rua Carlos Silva Melo Guimarães 23, 3800-126 Aveiro, Portugal >> >> <https://www.google.com/maps/search/Rua+Carlos+Silva+Melo+Guimar%C3%A3es+23,+3800-126+Aveiro,+Portugal?entry=gmail&source=g> >> >> Image removed by sender. >> <http://www.facebook.com/fuze> Image removed by sender. >> <http://www.twitter.com/fuze> Image removed by sender. >> <https://www.linkedin.com/company/fuze-inc> Image removed by >> sender. >> <https://plus.google.com/110150232345018024360> Image >> removed by sender. <https://www.instagram.com/fuze_hq/> >> >> Image removed by sender. <http://www.fuze.com/> >> >> >> *Confidentiality Notice: The information contained in this >> e-mail and any >> attachments may be confidential. If you are not an intended >> recipient, you >> are hereby notified that any dissemination, distribution or >> copying of this >> e-mail is strictly prohibited. If you have received this >> e-mail in error, >> please notify the sender and permanently delete the e-mail >> and any >> attachments immediately. You should not retain, copy or use >> this e-mail or >> any attachment for any purpose, nor disclose all or any part >> of the >> contents to any other person. Thank you.* >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected] <mailto:[email protected]> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected] <mailto:[email protected]> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> -- >> Regards, >> >> David Villasmil >> email: [email protected] >> <mailto:[email protected]> >> phone: +34669448337 >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected] >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- > Daniel-Constantin Mierla -- www.asipto.com > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com > Kamailio World Conference - April 27-29, 2020, in Berlin -- > www.kamailioworld.com -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
