[SR-Users] replay of tls delayed by 30 secs.

Andrew Chen achen at fuze.com
Thu Sep 27 15:15:00 CEST 2018


So I log when the server side sends an UPDATE request to the Kamailio and
then I log when the t_relay is completed to the client application.  Those
were on the same second.  It's when the message left the box and then
arrived at the client side is where the 30 sec difference came from.  So
our engineering is questioning if the t_relay really did relay it properly
out of the system as it was logged.  They are suspecting there could be
some issue with the t_relay and the OS level tcp queue.

On Thu, Sep 27, 2018 at 6:23 AM José Seabra <joseseabra4 at gmail.com> wrote:

> update to my last email.
>
> If do you see that the SIP transaction(UPDATE) arrives at your client fast
> enough, it isn't a problem with TCP send Queue (ignore my last email).
> Do you can see the reply to the SIP transaction(UPDATE)  sent from your
> client arriving to the host where kamailio is running? If not, seems that
> it isn't a problem in your Kamailio.
>
> Regards
> José
>
> José Seabra <joseseabra4 at gmail.com> escreveu no dia quinta, 27/09/2018
> à(s) 10:47:
>
>> Hi,
>>
>> Kamailio has some configuration options that logs a msg to the syslog
>> when some config script action takes more time that is expected, the
>> options are:
>>
>>    - latency_limit_action=500
>>    -
>>       https://www.kamailio.org/wiki/cookbooks/4.1.x/core#latency_limit_action
>>    - latency_limit_db=500
>>    - https://www.kamailio.org/wiki/cookbooks/4.1.x/core#latency_limit_db
>>    - latency_log=2
>>    - https://www.kamailio.org/wiki/cookbooks/4.1.x/core#latency_log
>>
>> The issue could also be related with the TCP write queue, maybe you have
>> set low values on the following parameters:
>>
>>    - tcp_conn_wq_max
>>       -
>>       https://www.kamailio.org/wiki/cookbooks/4.1.x/core#tcp_conn_wq_max
>>    - tcp_wq_max
>>       - https://www.kamailio.org/wiki/cookbooks/4.1.x/core#tcp_wq_max
>>
>> Other hint is to look for the OS  send Queue, the package could be
>> delayed because the other end is not reading it fast enough:
>>
>>    - netstat -altp
>>
>> it also will be important try to isolate the issue in terms of SIP, the
>> transaction delayed(UPDATE) is always the same in all situation that the
>> issue occurs?
>>
>> Hope that the information above helped you.
>>
>> Regards
>> José
>>
>
>
> --
> Cumprimentos
> José Seabra
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen at thinkingphones.com>fuze.com

-- 
*Confidentiality Notice: The information contained in this e-mail and any

attachments may be confidential. If you are not an intended recipient, you

are hereby notified that any dissemination, distribution or copying of this

e-mail is strictly prohibited. If you have received this e-mail in error,

please notify the sender and permanently delete the e-mail and any

attachments immediately. You should not retain, copy or use this e-mail or

any attachment for any purpose, nor disclose all or any part of the

contents to any other person. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180927/3d09d4d0/attachment.html>


More information about the sr-users mailing list