[SR-Users] Kamailio OPTIONS Round-Trip

Mon Feb 4 15:33:18 CET 2019

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 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
>>>
>> _______________________________________________
> 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.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190204/bf05856d/attachment.html>