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 miconda@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...
Regards
On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba d.tryba@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