<div dir="ltr"><div>Alex,</div><div><br></div><div>I've seen this but most of the time it was related or to SSL issues (speed of connection establishing) caused by DNS, especially DNS reverse names resolution.</div><div>I'd check this part and for sure - check on network level that timings are accurate <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 12 déc. 2022 à 13:47, Alex Balashov <<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I’ve run into stubbornly persistent problems with packets not reaching WSS clients until some seconds (5-6s or more!) after they were supposedly sent. The symptom is that Kamailio logs the event as sent at 20:00:00, including in the onsend_route, but in actual reality it takes quite a bit longer to send at the OS network stack level. This happens occasionally and quite universally, with no discernible pattern tied to particular endpoints, networks, etc.<br>
<br>
For a long time, I’ve just assumed this was a receive delay, since Kamailio logged an expectedly prompt relay time. I figured it was an application or browser execution delay and had nothing to do with networking. Based on what we know about the capriciousness of browsers and their internal task scheduling, this seemed rather plausible. However, I’ve since been able to ascertain that this is not the right understanding of the problem, because a parallel and unrelated WS keepalive, going from a different backend to the same application/browser tab/event loop, is consistently replied to in a timely manner. <br>
<br>
Anyway, I’m curious what else can be done to debug and/or fix this. <br>
<br>
I did turn up the size of my write buffers — tcp_wq_conn_max and the global one — quite a lot, some time ago and for unrelated reasons. I wonder if this might actually make the problem worse, since it leads to more bytes queued to send to an endpoint on the other side that could, conceivably, not be reading them fast enough. But I also wonder if this is tied up in some low-level TLS or WS parameters unrelated to more general TCP configuration.<br>
<br>
Thanks much!<br>
<br>
— Alex<br>
<br>
—<br>
Sent from mobile, apologies for brevity and errors.<br>
__________________________________________________________<br>
Kamailio - Users Mailing List - Non Commercial Discussions<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
Important: keep the mailing list in the recipients, do not reply only to the sender!<br>
Edit mailing list options or unsubscribe:<br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Best regards,<div>Ihor (Igor)<br></div></div></div>