Hello All,
I have One HA proxy server which have public ip. HA proxy server can load
balance between two kamailio instances installed in Server1 and Server2.
How to configure kamailio server such that If user registered on Server2
then server1 will redirect INVITE to server2.
user1 --> server1 --> server2 --> user2
Can anyone please help please?
--
Thanks & Regards
Kaushik Parmar
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
I've found some strange cdr records produced by kamailio. Haven't experienced this before in earlier versions.
One example (last field is kamailios call duration):
1442923048|1442923184|136298900000.000000
The duration of this call is in reality ~136 seconds. This matches the first three digits of the duration-field. Is this just a coincidence?
Another example:
1443011985|1443012286|301148.400000
This call has a duration of 301 seconds. Same as the first three digits.
I haven't found anything special with these calls, and it doesn't seem possible to reproduce. Just happens sometimes.
Settings for acc module:
modparam("acc", "db_url", "flatstore:/accounting")
modparam("acc", "log_level", 3)
modparam("acc", "cdr_enable", 1)
modparam("acc", "cdr_start_on_confirmed", 1)
modparam("acc", "cdr_extra", "anum=$dlg_var(caller);bnum=$dlg_var(callee);dlg_start_time=$dlg_var(inv_start);cancel_time=$dlg_var(cancel);account=$dlg_var(account);calltype=$dlg_var(calltype);callid=$dlg_var(callid);callid_system=$dlg_var(callid_system);trunk_id=$dlg_var(trunk_id)")
modparam("dialog", "dlg_flag", 4)
modparam("acc", "cdrs_table", "cdr")
modparam("acc", "cdr_on_failed", 0)
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/350