4 Feb
2019
4 Feb
'19
5:33 p.m.
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(a)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(a)gmail.com> wrote:
--
*Nuno Ferreira* | Architect, CoreUC | nferreira(a)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.*
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(a)fuze.com> wrote:
Kamailio (SER) - Users
Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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(a)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.…
Regards
On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba <d.tryba(a)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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
*Nuno Ferreira* | Architect, CoreUC | nferreira(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users