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 <pojo...@gmail.com> 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 <nferre...@fuze.com> 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 < >> mico...@gmail.com> 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 <d.tr...@pocos.nl> 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 >>>> sr-users@lists.kamailio.org >>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>> >>> >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing >>> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >>> -- >>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- >>> www.linkedin.com/in/miconda >>> Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com >>> Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in >>> Washington, DC, USA -- www.asipto.com >>> >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing List >>> sr-users@lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >> >> >> -- >> >> *Nuno Ferreira* | Architect, CoreUC | nferre...@fuze.com | +351 308805903 >> Rua Carlos Silva Melo Guimarães 23, 3800-126 Aveiro, Portugal >> >> <http://www.facebook.com/fuze> <http://www.twitter.com/fuze> >> <https://www.linkedin.com/company/fuze-inc> >> <https://plus.google.com/110150232345018024360> >> <https://www.instagram.com/fuze_hq/> >> >> <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 >> sr-users@lists.kamailio.org >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
