Kamailio OPTIONS Round-Trip
Hi, 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? Thank you.
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.
The solution is much more simple.. Register peers through the intermidiary proxy using the sip PATH extension. Not only will asterisk show the address=original IP of the peer but also the RTT. Cheers, Sergiu On Tue, Jan 15, 2019, 5:29 AM Daniel Tryba <d.tryba@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Depending on the use case, you could use the dispatcher module latency stats. https://kamailio.org/docs/modules/devel/modules/dispatcher.html#dispatcher.p... Regards On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba <d.tryba@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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...
Regards
On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba <d.tryba@pocos.nl <mailto:d.tryba@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@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@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
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@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...
Regards
On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba <d.tryba@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- *Nuno Ferreira* | Architect, CoreUC | nferreira@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@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@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...
Regards
On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba <d.tryba@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
*Nuno Ferreira* | Architect, CoreUC | nferreira@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/>
*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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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...
Regards
On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba <d.tryba@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
*Nuno Ferreira* | Architect, CoreUC | nferreira@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/>
*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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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@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...
Regards
On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba <d.tryba@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
*Nuno Ferreira* | Architect, CoreUC | nferreira@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/>
*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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- *Nuno Ferreira* | Architect, CoreUC | nferreira@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.*
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@lists.kamailio.org> on behalf of Nuno Ferreira <nferreira@fuze.com> Reply-To: "Kamailio (SER) - Users Mailing List" <sr-users@lists.kamailio.org> Date: Tuesday, 5 February 2019 at 1:37 am To: "Kamailio (SER) - Users Mailing List" <sr-users@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@gmail.com<mailto:pojogas@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@gmail.com<mailto:pojogas@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@fuze.com<mailto:nferreira@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@gmail.com<mailto:miconda@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... Regards On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba <d.tryba@pocos.nl<mailto:d.tryba@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@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org<mailto:sr-users@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@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Nuno Ferreira | Architect, CoreUC | nferreira@fuze.com<mailto:nferreira@fuze.com> | +351 308805903 Rua Carlos Silva Melo Guimarães 23, 3800-126 Aveiro, Portugal <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@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Nuno Ferreira | Architect, CoreUC | nferreira@fuze.com<mailto:nferreira@fuze.com> | +351 308805903 Rua Carlos Silva Melo Guimarães 23, 3800-126 Aveiro, Portugal <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.*
Just for future reference: https://github.com/kamailio/kamailio/issues/2223 On Tue, Apr 30, 2019 at 3:27 AM Rhys Hanrahan <rhys@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@lists.kamailio.org> on behalf of Nuno Ferreira <nferreira@fuze.com> *Reply-To: *"Kamailio (SER) - Users Mailing List" < sr-users@lists.kamailio.org> *Date: *Tuesday, 5 February 2019 at 1:37 am *To: *"Kamailio (SER) - Users Mailing List" <sr-users@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@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@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@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@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...
Regards
On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba <d.tryba@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
*Nuno Ferreira* | Architect, CoreUC | nferreira@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
*Nuno Ferreira* | Architect, CoreUC | nferreira@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
+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? On Wed, 19 Feb 2020 at 20:18, Joel Serrano <joel@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@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@lists.kamailio.org> on behalf of Nuno Ferreira <nferreira@fuze.com> *Reply-To: *"Kamailio (SER) - Users Mailing List" < sr-users@lists.kamailio.org> *Date: *Tuesday, 5 February 2019 at 1:37 am *To: *"Kamailio (SER) - Users Mailing List" <sr-users@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@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@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@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@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...
Regards
On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba <d.tryba@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
*Nuno Ferreira* | Architect, CoreUC | nferreira@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: 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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
*Nuno Ferreira* | Architect, CoreUC | nferreira@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: 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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards, David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337
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@textplus.com <mailto:joel@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@nexusone.com.au <mailto:rhys@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@lists.kamailio.org <mailto:sr-users-bounces@lists.kamailio.org>> on behalf of Nuno Ferreira <nferreira@fuze.com <mailto:nferreira@fuze.com>> *Reply-To: *"Kamailio (SER) - Users Mailing List" <sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>> *Date: *Tuesday, 5 February 2019 at 1:37 am *To: *"Kamailio (SER) - Users Mailing List" <sr-users@lists.kamailio.org <mailto:sr-users@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@gmail.com <mailto:pojogas@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@gmail.com <mailto:pojogas@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@fuze.com <mailto:nferreira@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@gmail.com <mailto:miconda@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...
Regards
On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba <d.tryba@pocos.nl <mailto:d.tryba@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@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto:sr-users@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@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
*Nuno Ferreira* | Architect, CoreUC | nferreira@fuze.com <mailto:nferreira@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@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
*Nuno Ferreira* | Architect, CoreUC | nferreira@fuze.com <mailto:nferreira@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@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com <mailto:david.villasmil.work@gmail.com> phone: +34669448337
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@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
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_... 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@textplus.com <mailto:joel@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@nexusone.com.au <mailto:rhys@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@lists.kamailio.org <mailto:sr-users-bounces@lists.kamailio.org>> on behalf of Nuno Ferreira <nferreira@fuze.com <mailto:nferreira@fuze.com>> *Reply-To: *"Kamailio (SER) - Users Mailing List" <sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>> *Date: *Tuesday, 5 February 2019 at 1:37 am *To: *"Kamailio (SER) - Users Mailing List" <sr-users@lists.kamailio.org <mailto:sr-users@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@gmail.com <mailto:pojogas@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@gmail.com <mailto:pojogas@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@fuze.com <mailto:nferreira@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@gmail.com <mailto:miconda@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...
Regards
On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba <d.tryba@pocos.nl <mailto:d.tryba@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@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto:sr-users@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@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
*Nuno Ferreira* | Architect, CoreUC | nferreira@fuze.com <mailto:nferreira@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@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
*Nuno Ferreira* | Architect, CoreUC | nferreira@fuze.com <mailto:nferreira@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@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com <mailto:david.villasmil.work@gmail.com> phone: +34669448337
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@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
participants (9)
-
Daniel Tryba -
Daniel-Constantin Mierla -
David Villasmil -
Joel Serrano -
Julien Chavanton -
Nuno Ferreira -
Rhys Hanrahan -
Sergiu Pojoga -
Soltanici Ilie