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 mailto: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
<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 <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com <http://www.asipto.com>
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com <http://www.kamailioworld.com>

Thanks.

This is a network capture taken on Kamailio server that showing VSS Monitoring ethernet. --- This is not a LAN network. UAC is on Internet behind a NAT device so I can't capture the traffic in the network.

According your message, you think UAC send close notify alerts even during during the call establishment?

Regards Abdoul.

2017-04-05 14:58 GMT+02:00 Nathan Ward kamailio-sr-users@daork.net:

On 6/04/2017, at 12:25 AM, Abdoul Osséni abdoul.osseni@gmail.com wrote: 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*

Hi,

VSS-Monitoring is a function of your monitoring tap, is is not a function of your NAT box - http://www.vssmonitoring.com/resources/feature-brief/ Port-and-Time-Stamping.pdf It should not be included in the actual traffic packets going past the tap

• only the packets that you see on your network analyser - if you find that

it is included on actual packets, you need to talk to your networking people and get that fixed.

It is very unlikely that a NAT device sends anything other than synthesised RST packets. It certainly won’t be generating close notify TLS alerts - I’m not actually sure that it can, they might need to be authenticated.

If you are seeing a close notify, you should capture between the UAC and the NAT device - I believe you will see the close notify TLS alert coming from the UAC. If that is the case, you need to look at the UAC for why it’s doing that. Perhaps your UAC does not support TCP keepalives properly.

-- Nathan Ward

---

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

On Wed, Apr 05, 2017 at 02:25:29PM +0200, Abdoul Osséni wrote:

The advantage of the SIP ping options is a bidirectional traffic through NAT. I think in this case, my issue will be solved.

Due to some limitations of the nat helper pinger (3 backends, one should ping at hh:mm:00, the other at hh:mm:20 and last at hh:mm:40) I decided to run my own external pinger process that sends OPTIONS to all registered users via kamailio (in my case via a loadbalancer based on path headers). Based on the $fU and source ip these requests are forwarded to the endpoints (in my example from path received header, in your case that may be just received (and transport for the tcp/tls clients) in contact).

kamailio.cfg option forwarding:

if(is_method("OPTIONS") && $fU=="pinger" && is_in_subnet($si, "127.0.0.0/8")) { record_route(); remove_hf("Route");

$avp(route)=$(hdr(Route)[0]); $avp(route)=$(avp(route){s.strip,1}); $avp(route)=$(avp(route){s.striptail,1}); $avp(received)=$(avp(route){uri.param,received}); $avp(received)=$(avp(received){s.unescape.param});

$du=$avp(received);

route(RELAY); exit; }

The options are generated with a php script:

if($res=mysql_query("select * from location order by rand()")) { while($row=mysql_fetch_assoc($res)) { usleep(1000); $branch=uniqid(); $dst=preg_replace('/.*@([^;]+);.*/',"$1",$row['path']); $dst=explode(':',$dst); if(count($dst)<2) { $dst[1]=5060; } $str=<<<EOS OPTIONS {$row['contact']} SIP/2.0\r Via: SIP/2.0/UDP 127.0.1.1:$listenport;branch=$branch;rport;alias\r Route: {$row['path']}\r From: sip:pinger@my.doma.in;tag={$row['ruid']}\r To: {$row['contact']}\r Call-ID: {$row['id']}-$listenport-$uid@localhost\r CSeq: 1 OPTIONS\r Content-Length: 0\r \r

EOS; socket_sendto($sock,$str,strlen($str),MSG_EOR,$dst[0],$dst[1]); } }