Hello,
Thanks for this feedback.
Here the description of the issue I am trying to solve.
I use already tcp_keepalive.
Call flow is:
UACs --> Nat device --> Kamailio
Transport protocol is TLS.
Kamailio sends TCPs keepalive (tcp_keepalive option) to the softphone located behind the nat devices in order to prevent disconnection due to network inactivity.
In most cases I have the expected behavior, I do not have any problems.
I think somes NAT devices don't properly handle TCPs keepalive because they close the connection after TCP keepalives.
I have always this issue with NAT devices using VSS-Monitoring protocol.
A network capture shows:
- Kamailio sends a tcp keepalive
- The NAT device sends a tck keepalive ACK to Kamailio with a new filed : vss-monitoring
Frame 70: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
Linux cooked capture
Internet Protocol Version 4, Src: x.x.x.x, Dst: x.x.x.x
Transmission Control Protocol, Src Port: 13178, Dst Port: 443, Seq: 2752, Ack: 6214, Len: 0
VSS-Monitoring ethernet trailer, Source Port: 0
Src Port: 0
- Kamailio received then a TCP from the NAT device that notifies the closure of the connection.
Frame 73: 87 bytes on wire (696 bits), 87 bytes captured (696 bits)
Linux cooked capture
Internet Protocol Version 4, Src: x.x.x.x, Dst: x.x.x.x
Transmission Control Protocol, Src Port: 13178, Dst Port: 443, Seq: 3436, Ack: 6214, Len: 31
Secure Sockets Layer
TLSv1.2 Record Layer: Alert (Level: Warning, Description: Close Notify)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 26
Alert Message
Level: Warning (1)
Description: Close Notify (0)
- After a FIN ACK sent to Kamailio by the NAT device, a new tcp three-way handshake is made again.
Sometimes, I have this issue during the connection establishment that cause a problem of sending or receiving SIP messages (for examples 200 OK and ACK).
The advantage of the SIP ping options is a bidirectional traffic through NAT. I think in this case, my issue will be solved.
Regards
Abdoul OSSENI