### 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. #### Log Messages <!-- Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site). --> ``` (paste your log messages here) ``` #### SIP Traffic <!-- If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site). --> ``` (paste your sip traffic here) ``` ### 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**: <!-- Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...; Kernel details (output of `uname -a`) --> ``` Debian Wheezy, Linux hostname 3.2.0-5-amd64 #1 SMP Debian 3.2.96-3 x86_64 GNU/Linux ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1587