Hi all,
So for a while now I've been working with our engineering team to troubleshoot these random events where the UPDATE message sent from the server never made it to the client side. Here is the the topology:
Server -(tcp)-> kamailio -(tls)-> client
So looks pretty straight forward and I have logging messages stating t_relay() was successful in sending the message.
The question is how do we know t_relay really successfully sent it? Does it actually monitor the physical interface as it goes out?
Please advise.
Thanks.
Hello,
On 08.12.17 02:23, Andrew Chen wrote:
Hi all,
So for a while now I've been working with our engineering team to troubleshoot these random events where the UPDATE message sent from the server never made it to the client side. Here is the the topology:
Server -(tcp)-> kamailio -(tls)-> client
So looks pretty straight forward and I have logging messages stating t_relay() was successful in sending the message.
The question is how do we know t_relay really successfully sent it? Does it actually monitor the physical interface as it goes out?
t_relay() may return successful code if the message was put in the writing queue. Later can be another log message if sending ended int a transmission timeout. Do you have a failure_route set for such t_relay()? If not, you can add one, it should be executed if sending fails.
Cheers, Daniel
Hi Daniel,
Thanks for the response. The question that's been raised by our engineers is how do we know the message that's put in the queue actually successfully been sent on the wire/network? Have there been situations where it gets stuck in the queue and never sent out?
Thanks. --Andy
On Fri, Dec 8, 2017 at 12:35 AM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
Hello,
On 08.12.17 02:23, Andrew Chen wrote:
Hi all,
So for a while now I've been working with our engineering team to troubleshoot these random events where the UPDATE message sent from the server never made it to the client side. Here is the the topology:
Server -(tcp)-> kamailio -(tls)-> client
So looks pretty straight forward and I have logging messages stating t_relay() was successful in sending the message.
The question is how do we know t_relay really successfully sent it? Does it actually monitor the physical interface as it goes out?
t_relay() may return successful code if the message was put in the writing queue. Later can be another log message if sending ended int a transmission timeout. Do you have a failure_route set for such t_relay()? If not, you can add one, it should be executed if sending fails.
Cheers, Daniel
-- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
Btw...I do call sl_reply_error() on relay fails. Below is a sample block:
if (!t_relay())
{
....log some errors....
sl_reply_error();
}
else
{
....log successful relay....
}
On Fri, Dec 8, 2017 at 9:15 AM, Andrew Chen achen@fuze.com wrote:
Hi Daniel,
Thanks for the response. The question that's been raised by our engineers is how do we know the message that's put in the queue actually successfully been sent on the wire/network? Have there been situations where it gets stuck in the queue and never sent out?
Thanks. --Andy
On Fri, Dec 8, 2017 at 12:35 AM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
Hello,
On 08.12.17 02:23, Andrew Chen wrote:
Hi all,
So for a while now I've been working with our engineering team to troubleshoot these random events where the UPDATE message sent from the server never made it to the client side. Here is the the topology:
Server -(tcp)-> kamailio -(tls)-> client
So looks pretty straight forward and I have logging messages stating t_relay() was successful in sending the message.
The question is how do we know t_relay really successfully sent it? Does it actually monitor the physical interface as it goes out?
t_relay() may return successful code if the message was put in the writing queue. Later can be another log message if sending ended int a transmission timeout. Do you have a failure_route set for such t_relay()? If not, you can add one, it should be executed if sending fails.
Cheers, Daniel
-- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
-- Andy Chen Sr. Telephony Lead Engineer 415 516 5535 (M) achen@ achen@thinkingphones.comfuze.com
Add a failure route execution:
if(is_method("UPDATE")) {
t_on_failure("FRT_UPDATE");
}
if (!t_relay())
... your rest of the code here
At the end of kamailio.cfg add:
failure_route[FRT_UPDATE] {
xlog("sending UPDATE failed\n");
}
and watch the logs to see if the xlog message appears.
Cheers, Daniel
On 08.12.17 18:21, Andrew Chen wrote:
Btw...I do call sl_reply_error() on relay fails. Below is a sample block:
if (!t_relay())
{
....log some errors....
sl_reply_error();
}
else
{
....log successful relay....
}
On Fri, Dec 8, 2017 at 9:15 AM, Andrew Chen <achen@fuze.com mailto:achen@fuze.com> wrote:
Hi Daniel, Thanks for the response. The question that's been raised by our engineers is how do we know the message that's put in the queue actually successfully been sent on the wire/network? Have there been situations where it gets stuck in the queue and never sent out? Thanks. --Andy On Fri, Dec 8, 2017 at 12:35 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com>> wrote: Hello, On 08.12.17 02:23, Andrew Chen wrote: > Hi all, > > So for a while now I've been working with our engineering team to > troubleshoot these random events where the UPDATE message sent from > the server never made it to the client side. Here is the the topology: > > Server -(tcp)-> kamailio -(tls)-> client > > So looks pretty straight forward and I have logging messages stating > t_relay() was successful in sending the message. > > The question is how do we know t_relay really successfully sent it? > Does it actually monitor the physical interface as it goes out? > > t_relay() may return successful code if the message was put in the writing queue. Later can be another log message if sending ended int a transmission timeout. Do you have a failure_route set for such t_relay()? If not, you can add one, it should be executed if sending fails. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - www.asipto.com <http://www.asipto.com> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com <http://www.kamailioworld.com> -- Andy Chen Sr. Telephony Lead Engineer 415 516 5535 (M) achen@ <mailto:achen@thinkingphones.com>fuze.com <http://fuze.com>-- Andy Chen Sr. Telephony Lead Engineer 415 516 5535 (M) achen@ mailto:achen@thinkingphones.comfuze.com http://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.*
Thanks Daniel. I will give that a try.
On Sat, Dec 9, 2017 at 12:08 AM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
Add a failure route execution:
if(is_method("UPDATE")) {
t_on_failure("FRT_UPDATE");
}
if (!t_relay())
... your rest of the code here
At the end of kamailio.cfg add:
failure_route[FRT_UPDATE] {
xlog("sending UPDATE failed\n");
}
and watch the logs to see if the xlog message appears.
Cheers, Daniel
On 08.12.17 18:21, Andrew Chen wrote:
Btw...I do call sl_reply_error() on relay fails. Below is a sample block:
if (!t_relay())
{
....log some errors.... sl_reply_error();}
else
{
....log successful relay....}
On Fri, Dec 8, 2017 at 9:15 AM, Andrew Chen achen@fuze.com wrote:
Hi Daniel,
Thanks for the response. The question that's been raised by our engineers is how do we know the message that's put in the queue actually successfully been sent on the wire/network? Have there been situations where it gets stuck in the queue and never sent out?
Thanks. --Andy
On Fri, Dec 8, 2017 at 12:35 AM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
Hello,
On 08.12.17 02:23, Andrew Chen wrote:
Hi all,
So for a while now I've been working with our engineering team to troubleshoot these random events where the UPDATE message sent from the server never made it to the client side. Here is the the topology:
Server -(tcp)-> kamailio -(tls)-> client
So looks pretty straight forward and I have logging messages stating t_relay() was successful in sending the message.
The question is how do we know t_relay really successfully sent it? Does it actually monitor the physical interface as it goes out?
t_relay() may return successful code if the message was put in the writing queue. Later can be another log message if sending ended int a transmission timeout. Do you have a failure_route set for such t_relay()? If not, you can add one, it should be executed if sending fails.
Cheers, Daniel
-- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
-- Andy Chen Sr. Telephony Lead Engineer 415 516 5535 (M) achen@ achen@thinkingphones.comfuze.com
-- Andy Chen Sr. Telephony Lead Engineer 415 516 5535 (M) achen@ achen@thinkingphones.comfuze.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.*
-- Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
Hello,
On 08.12.17 18:15, Andrew Chen wrote:
Hi Daniel,
Thanks for the response. The question that's been raised by our engineers is how do we know the message that's put in the queue actually successfully been sent on the wire/network? Have there been situations where it gets stuck in the queue and never sent out?
once in the queue it may get discarded if connection cannot be established or because of transmission timeout.
Cheers, Daniel
Thanks. --Andy
On Fri, Dec 8, 2017 at 12:35 AM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello, On 08.12.17 02:23, Andrew Chen wrote: > Hi all, > > So for a while now I've been working with our engineering team to > troubleshoot these random events where the UPDATE message sent from > the server never made it to the client side. Here is the the topology: > > Server -(tcp)-> kamailio -(tls)-> client > > So looks pretty straight forward and I have logging messages stating > t_relay() was successful in sending the message. > > The question is how do we know t_relay really successfully sent it? > Does it actually monitor the physical interface as it goes out? > > t_relay() may return successful code if the message was put in the writing queue. Later can be another log message if sending ended int a transmission timeout. Do you have a failure_route set for such t_relay()? If not, you can add one, it should be executed if sending fails. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - www.asipto.com <http://www.asipto.com> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com <http://www.kamailioworld.com>-- Andy Chen Sr. Telephony Lead Engineer 415 516 5535 (M) achen@ mailto:achen@thinkingphones.comfuze.com http://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.*
-
Andrew Chen -
Daniel-Constantin Mierla