31 Aug
2015
31 Aug
'15
1:52 p.m.
I have 3 registrars being replicated to each other using dmq_usrloc. These registrars sit
behind proxy servers. I use the path header to specify the received address. When the
nathelper module is enabled, the nathelper then sends keep alive options messages from all
three registrars for the same contact instead of the node that processed the original
registration.
I am using in-memory replication (db_mode = 0), so the server_id core parameter does not
seem to be taking affect for in-memory replication, i believe this is only for database
mode only. I currently have server_id set differently for each registrar, to no effect.
nathelper module configuration parameters are as follows:
```
modparam("nathelper", "natping_interval", 20)
modparam("nathelper", "natping_processes", 4)
modparam("nathelper", "ping_nated_only", 1)
modparam("nathelper", "sipping_from",
"sip:keepalive@domain.com")
modparam("nathelper", "sipping_method", "OPTIONS")
modparam("nathelper", "force_socket", NAT_PING_SOCKET)
```
NAT_PING_SOCKET is set to the local interface of each registrar where I want the message
to originate from:
```
# Registrar01
#!define NAT_PING_SOCKET "10.7.0.170:5060"
# Registrar02
#!define NAT_PING_SOCKET "10.7.0.171:5060"
# Registrar03
#!define NAT_PING_SOCKET "10.7.0.172:5060"
```
server_id is set for each registrar
```
# Registrar01
server_id=001
# Registrar02
server_id=002
# Registrar03
server_id=003
```
I noticed that when the force_socket is set and a registration is sent from a node that
did not process the request, then an options messages is sent via the forced_socket but
the originating IP is that of the primary interface of the node, in this case, the
kamailio listening address on the 10.6.0.0/24 segment, and example message follows:
```
12:42:13.320519 00:50:56:91:5e:77 > 00:50:56:91:64:fe, ethertype IPv4 (0x0800), length
455: (tos 0x60, ttl 64, id 62009, offset 0, flags [none], proto UDP (17), length 441)
10.6.0.170.sip > 10.7.0.109.sip: [udp sum ok] SIP, length: 413
OPTIONS sip:subscriber01@172.16.0.138:5060;alias=78.143.152.30~49233~1 SIP/2.0
Via: SIP/2.0/UDP 10.6.0.170:5060;branch=0
Route: <sip:10.7.0.109;lr;received=sip:78.143.152.30:49233>
From: sip:keepalive@domain.com;tag=uloc-3-55e0473b-1503-af38-6cf5fbae-864c1976
To: sip:subscriber01@172.16.0.138:5060;alias=78.143.152.30~49233~1
Call-ID: 9f855711-a24ef866-112a3d5(a)10.6.0.170
CSeq: 1 OPTIONS
Content-Length: 0
```
The MAC address above confirms that the sending interface is that of force_socket for
nathelper, but the source IP address is that of the primary interface of the registrar.
This results in martian source messages on the target proxy server:
```
Aug 31 12:42:13 proxy01 kernel: martian source 10.7.0.109 from 10.6.0.170, on dev eth1
Aug 31 12:42:13 proxy01 kernel: ll header: 00:50:56:91:64:fe:00:50:56:91:5e:77:08:00
```
I suspect the latter issue (martian source) will resolve itself if the registrar not
processing the registration stops sending nathelper keep alive messages for contacts it
did not itself process.
Please let me know if you require any additional information from me to debug this issue
further.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/310