[sr-dev] [kamailio] nathelper sending keep alives on nodes where contact replicated using dmq_usrloc (#310)

[00Asgaroth00]

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 at 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 at 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 at domain.com;tag=uloc-3-55e0473b-1503-af38-6cf5fbae-864c1976
        To: sip:subscriber01 at 172.16.0.138:5060;alias=78.143.152.30~49233~1
        Call-ID: 9f855711-a24ef866-112a3d5 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20150831/05813d5b/attachment.html>