nathelper always sends SIP pings when ping_nated_only is set to 0

[SipSeb]

Description

We upgraded from Kamailio 4.4.5 to 5.1.4 today. We have a IPv6-to-v4 loadbalancer which sends out NAT pings to keep the connection through routers alive. So it is not a real NAT scenario.

Kamailio 4.4.5 sent out dummy 4-byte UDP packets. Kamailio 5.1.4 sends out SIP OPTIONS although we didn't even configure sipping_from.

Our configuration:

loadmodule "nathelper.so"
modparam("nathelper", "received_avp", "$(avp(i:801))")
modparam("nathelper", "natping_interval" , 14)
modparam("nathelper", "ping_nated_only" , 0)

When looking into the code, Kamailio should not even be able to send out OPTIONS without sipping_from being configured. It does anyhow. This results in broken keepalive packets.

OPTIONS sip:foobar@[2003:a:c6b:8400:204:aaaa:bbbb:cccc]:6060;transport=udp;line=s4cqtu SIP/2.0.
Via: SIP/2.0/UDP [2001:AB7:0:0:0:0:0:1]:5060;branch=z9hG4bK9474521.
From: ;tag=uloc-5b2b6211-355f-81fc4-3f1f9b57-6a9dc2.
To: sip:foobar@[2003:a:c6b:8400:204:aaaa:bbbb:cccc]:6060;transport=udp;line=s4cqtu.
Call-ID: -6a9dc2-cac4404@2001:AB7:0:0:0:0:0:1.
CSeq: 1 OPTIONS.
Content-Length: 0.
.

Those packets get rejected by some clients, bringing them offline, effectively.

After adding the sipping_from modparam, those OPTIONS get sent with a correct From header.

Troubleshooting

Reproduction

Our v4-only SIP proxies don't show the behavior, our v6-to-v4 loadbalancers do. I don't know if this can be reproduced with a default installation on a IPv6 setup.

Possible Solutions

Setting the sipping_from parameter at least fixes the OPTIONS packet. But we found no way to send those dummy UDP packets instead of full OPTIONS.

Additional Information

Kamailio branch 5.1 pulled yesterday, 5.1.4

• Kamailio Version - output of kamailio -v

version: kamailio 5.1.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 4.7.2

• Operating System:

Debian Wheezy,  Linux hostname 3.2.0-5-amd64 #1 SMP Debian 3.2.96-3 x86_64 GNU/Linux

[miconda]

I added a safety check for sipping_from with the commit referenced above, to be protected better in the future.

The sending of SIP request NAT pings for ping_nated_only=0 seems to be a side effect of commit b34cf58, I guess it was designed only for the 4-bytes pings. I am thinking of a solution where one can have either SIP messages or the 4-bytes pings when ping_nated_only=0.

[miconda]

I ended up by using the combination of ping_nated_only being 0 and setting sipping_flag, assuming that if one wants to ping all contacts with 4-bytes, it doesn't need to set sipping_flag parameter at all.

If anyone has another suggestion, just write here.

An option that I am somehow considering is to add a new one or rename this parameter for controlling the ping mode, like ping_mode: 0 - use message/branch flags to decide, 1 - all contacts with 4 bytes, 2 - all contacts with sip requests

Testing and reporting the behaviour with the above patch is appreciated. If all ok, then I will backport.

[SipSeb]

Hi Daniel, thanks for the quick fix. I just backported those two patches from yesterday and the affected loadbalancers immediately stopped sending out OPTIONS and started sending out 4 bytes packets instead. From my point of view everything is working again as expected.

I agree, that the addition of a mode parameter would help understanding the functionality.