[SR-Users] Kamailio OPTIONS Round-Trip

Wed Feb 19 21:14:58 CET 2020

Just for future reference:

https://github.com/kamailio/kamailio/issues/2223

On Tue, Apr 30, 2019 at 3:27 AM Rhys Hanrahan <rhys at nexusone.com.au> 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 <sr-users-bounces at lists.kamailio.org> on behalf of Nuno
> Ferreira <nferreira at fuze.com>
> *Reply-To: *"Kamailio (SER) - Users Mailing List" <
> sr-users at lists.kamailio.org>
> *Date: *Tuesday, 5 February 2019 at 1:37 am
> *To: *"Kamailio (SER) - Users Mailing List" <sr-users at lists.kamailio.org>
> *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 <pojogas at gmail.com> 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 <pojogas at 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 <nferreira at 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 <
> miconda at 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.tryba at 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> _______________________________________________
>
> Kamailio (SER) - Users Mailing List
>
> sr-users at lists.kamailio.org
>
> 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
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
>
> --
>
> *Nuno Ferreira* | Architect, CoreUC | nferreira at fuze.com | +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
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
>
> --
>
> *Nuno Ferreira* | Architect, CoreUC | nferreira at fuze.com | +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
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200219/aa726873/attachment.html>