[SR-Users] Kamailio OPTIONS Round-Trip
Daniel-Constantin Mierla
miconda at gmail.com
Fri Mar 27 11:59:47 CET 2020
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 <joel at textplus.com
>> <mailto:joel at textplus.com>> wrote:
>>
>> 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 <mailto: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
>> <mailto:sr-users-bounces at lists.kamailio.org>> on behalf of
>> Nuno Ferreira <nferreira at fuze.com <mailto:nferreira at fuze.com>>
>> *Reply-To: *"Kamailio (SER) - Users Mailing List"
>> <sr-users at lists.kamailio.org
>> <mailto: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
>> <mailto: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 <mailto: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 <mailto: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 <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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 <mailto:sr-users at lists.kamailio.org>
>>
>> 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
>> sr-users at lists.kamailio.org
>> <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>>
>> --
>>
>> *Nuno Ferreira* | Architect, CoreUC |
>> nferreira at fuze.com <mailto:nferreira at fuze.com> |
>> +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
>> sr-users at lists.kamailio.org
>> <mailto: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
>> <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>>
>> --
>>
>> *Nuno Ferreira* | Architect, CoreUC | nferreira at fuze.com
>> <mailto:nferreira at fuze.com> | +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
>> sr-users at lists.kamailio.org <mailto: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 <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>> --
>> Regards,
>>
>> David Villasmil
>> email: david.villasmil.work at gmail.com
>> <mailto:david.villasmil.work at gmail.com>
>> phone: +34669448337
>>
>> _______________________________________________
>> 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200327/7c2ff5c0/attachment.html>
More information about the sr-users
mailing list