[SR-Users] Kamailio OPTIONS Round-Trip

Wed Jan 16 16:16:47 CET 2019

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 Listsr-users at 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 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
>>
>> <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 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/20190116/d08cc713/attachment.html>