Hello,

if it happens also between INVITE and 200ok or between 200ok and the ACK, then very likely sending the OPTIONS will not help. Probably the far end routers have a broken implementation of NAT.

Is this happening only for a specific group of users, or happens randomly for different users?

Cheers,
Daniel


On 05.04.17 14:25, Abdoul Osséni wrote:
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

2017-04-05 12:48 GMT+02:00 Daniel-Constantin Mierla <miconda@gmail.com>:

Hello,

nathelper module does ping OPTIONS only for UDP.

For tcp/tls, there is transport layer keepalive:

  - https://www.kamailio.org/wiki/cookbooks/5.0.x/core#tcp_keepalive

What is the problem you are trying to solve with this? Maybe there are some other options for it.

Cheers,
Daniel

On 31.03.17 13:03, Abdoul Osséni wrote:
Hi,

Is it possible to send ping OPTIONS over tcp or tls?

If yes, could you me how?

Regards
Abdoul.


_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com