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:
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 [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
