Just for future reference: https://github.com/kamailio/kamailio/issues/2223
On Tue, Apr 30, 2019 at 3:27 AM Rhys Hanrahan <[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]> on behalf of Nuno > Ferreira <[email protected]> > *Reply-To: *"Kamailio (SER) - Users Mailing List" < > [email protected]> > *Date: *Tuesday, 5 February 2019 at 1:37 am > *To: *"Kamailio (SER) - Users Mailing List" <[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]> 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]> 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]> 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]> 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]> 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] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > _______________________________________________ > > 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 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 > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > > -- > > *Nuno Ferreira* | Architect, CoreUC | [email protected] | +351 308805903 > Rua Carlos Silva Melo Guimarães 23, 3800-126 Aveiro, Portugal > > [image: Image removed by sender.] <http://www.facebook.com/fuze> [image: > Image removed by sender.] <http://www.twitter.com/fuze> [image: Image > removed by sender.] <https://www.linkedin.com/company/fuze-inc> [image: > Image removed by sender.] <https://plus.google.com/110150232345018024360> > [image: Image removed by sender.] <https://www.instagram.com/fuze_hq/> > > [image: 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] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > > -- > > *Nuno Ferreira* | Architect, CoreUC | [email protected] | +351 308805903 > Rua Carlos Silva Melo Guimarães 23, 3800-126 Aveiro, Portugal > > [image: Image removed by sender.] <http://www.facebook.com/fuze> [image: > Image removed by sender.] <http://www.twitter.com/fuze> [image: Image > removed by sender.] <https://www.linkedin.com/company/fuze-inc> [image: > Image removed by sender.] <https://plus.google.com/110150232345018024360> > [image: Image removed by sender.] <https://www.instagram.com/fuze_hq/> > > [image: 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] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
