You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
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, view it on GitHub, or mute the thread.