[OpenSIPS-Users] strange TCP handling in opensips 2.4

Bogdan-Andrei Iancu bogdan at opensips.org
Tue Mar 26 04:04:34 EDT 2019

Hi Artem,

On the "real-behavior" - OpenSIPS generates and sends an OPTIONS request 
(a NAT ping) via the stale connection to A. You say :

1) the TCP write operation in OpenSIPS  blocks ? (you mentioned the 

2) the retransmission you mentioned, are at TCP level or SIP level ? If 
at TCP level, these are done by the TCP/IP stack in the Operating 
System, they are not done by OpenSIPS.

The received BYE is not sent out as the outgoing connection (to A) is 
locked by the process trying to send the OPTIONS to A (assuming that the 
write operation blocks).

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
OpenSIPS Summit 2019

On 03/25/2019 04:40 PM, Artem Chalkov wrote:
> Hi all.
> Today i encountered some strange behavior in TCP handling. Case:
> A - caller, proto=tcp, behind NAT
> B - callee, proto=udp, not behind NAT
> Nathelper is active, so A is pinged by OPTIONS from opensips.
> A registering and then calling to B, B answers, A sends ACK for 200 
> and in some moment after that - disappears from network (for example - 
> unplug network cable).
> After that B send BYE request.
> Parameters of proto_tcp:
> modparam("proto_tcp", "tcp_port", 5060)
> modparam("proto_tcp", "tcp_send_timeout", 5000)
> modparam("proto_tcp", "tcp_async", 1)
> modparam("proto_tcp", "tcp_crlf_pingpong", 0)
> Expected behavior:
> 1. if TCP session is still active: opensips will try to send BYE to A 
> via TCP and close TCP-connection after 5000ms (tcp_send_timeout 
> interval), send 477 Send Failed to himself and 408 to B, as result of 
> BYE transaction.
> 2. if TCP session is no active (after some TCP-FIN): opensips will try 
> to re-establish TCP session, and if it will be not successfull - send 
> 477 Send Failed to himself and 408 to B, as result of BYE transaction.
> Real behavior:
> TCP session is active (there was no TCP-FIN), next OPTIONS-ping from 
> opensips is not answered by A (because he disappeared from network) on 
> TCP-level (no TCP-ACK for request with options), opensips starts to 
> send TCP-retransminnions of last OPTIONS request (and continue to send 
> this retransmissions in a next few minutes), not trying to send BYE 
> request at all, not trying to close TCP session. After fr_timeout 
> number of  seconds opensips sends 408 to B as result of BYE 
> transaction and not sends 477 to himself.
> There is screenshot of my example:
> https://imgur.com/HNxwxPo
> So - it looks like opensips totally ignore tcp_send_timeout value and 
> it leads to some misbehavior in handling TCP requests. Am i right or i 
> missed something?
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20190326/f9c247ff/attachment.html>

More information about the Users mailing list