[SR-Users] NatHelper ignoring force_socket module parameter

[Asgaroth]

I've been toying with this a little more now, and I have now set 
server_id to different values for each of my registrars, but I still see 
each of them attempting to send options messages to contacts that have 
not been processed by the server locally (these aor's have been 
replicated using dmq_replicate from the server that originally processed 
the request). What I can see is that if an aor has been replicated to 
the local registrar, then the "Socket::" value is not propogated, which 
makes sense, however, the "Socket::" value does exist on the registrar 
that actually processed the registration request.

My configuration here sits behind loadbalancers, and I use the path 
header to store the recieved details for each nat'ed contact, this 
"Recieved::" value is set, even when replicating and I think the 
nathelper module may be assuming that it therefor needs to ping this 
replicated contact.

My registrar's have 2 interfaces, the primary interface is not on the 
same lan as the loadbalancers, so what happens in this instance is that 
nathelper tries to send an options to a contact that has been 
replicated, I presume, it then looks at the socket info to see which 
socket to send the request out of, doesnt find any for a replicated 
contact, and then proceeds to send it out of the primary interface.

Is there any other way that I could try to get the nathelper module to 
ignore contacts thats have not been processed by the local kamailio 
instance.

I am running in memory mode only, I do not use the database for usrloc 
entries, I keep the location "database" in memory only, and I sync the 
database using the dmq_usrloc module, which works beautifully btw :)

Any tips/suggestions would be greatly appreciated.

Thanks
Bruce

On 10/08/2015 13:43, Asgaroth wrote:
> Hi Daniel,
>
> Thanks for that information, I had a look at registrar/nathelper and usrloc
> module documentation, and I do see the server_id parameter in the usrloc
> module docs for v4.3.x. This appears to be a database only column, I am
> running in memory only mode using dmq_usrloc to replicate the registrations,
> in this particular instance, how would I go about setting the server_id
> parameter when running in memory mode (db_mode 0).
>
> Thanks
>
> -----Original Message-----
> From: sr-users [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of
> Daniel-Constantin Mierla
> Sent: Friday 7 August 2015 18:37
> To: Kamailio (SER) - Users Mailing List <sr-users at lists.sip-router.org>
> Subject: Re: [SR-Users] NatHelper ignoring force_socket module parameter
>
> You have to set server_id to be different for each node in order to send
> keepalive only for registration received directly, however, iirc, this
> feature is only in master branch.
>
> Cheers,
> Daniel
>
> On 23/07/15 15:19, Asgaroth wrote:
>> some more info on this one, it looks like this is only happening on
>> nodes that have been replicated to, for example,
>>
>> If a registration is processed on node 1, then the nathelper send the
>> locally generated options message out of the correct socket, I presume
>> it gets the sending socket details from the socket information stored
>> by the registrar. (Socket:: udp:10.7.0.175:5060)
>>
>> However, when this registration is replicated (via dmq_usrloc), there
>> is no local socket information for the particular contact, the
>> nathelper module seems to think that it needs to ping this
>> registration contact (it is natted) and sends it out of the wrong
>> interface even if the force_socket module parameter is set for the
>> nathelper module.
>>
>> That brings me on to my next question, why is the nathelper module
>> attempting to ping natted contacts from all registrar's, should it not
>> ping from the registrar that processed the last registration attempt?
>>
>> I had a read of the nathelper module documentation, but I cannot see
>> any obvious setting that would tell nathelper to only ping from the
>> registrar processing the request.
>>
>> Is my understanding of how nathelper is supposed to work correct when
>> it comes to multiple registrar's with registration replication? Myabe
>> I am missing something here, any tips/tricks/suggestions/beatings most
>> welcome
>>
>> Thanks
>>
>> On 23/07/2015 12:14, Asgaroth wrote:
>>> Hi All,
>>>
>>> I have a strange issue, I have set the module parameter for
>>> nathelper's force_socket to a specfic ip/port, however, when I
>>> perform a sip trace I can see that all locally generated options
>>> messages are not sent from the socket defined in the modules parameters.
>>>
>>> I am not setting $fs anywhere in the script, so I am not over-writing
>>> it. Do any of the other module parameters have a bearing on if
>>> nathelper uses the force_socket parameter?
>>>
>>> My current nathelper settings are:
>>>
>>> modparam("nathelper", "received_avp",      "$avp(RECEIVED)")
>>> 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", "sipping_bflag",           NAT_BFLAG)
>>> modparam("nathelper", "force_socket",            "1.2.3.4:5060")
>>>
>>> I am using kamailio v4.3.1:
>>>
>>> # kamailio -V
>>> version: kamailio 4.3.1 (x86_64/linux) f38e67
>>> 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, F_MALLOC, DBG_F_MALLOC, 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: f38e67
>>> compiled on 18:15:23 Jul 20 2015 with gcc 4.4.7
>>>
>>> Thanks
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>> list sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Book: SIP Routing With Kamailio - http://www.asipto.com
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>