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@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
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@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
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi All,
Just to continue on on this particular issue, we are now testing kamailio v5.0.3 and I are still experiencing the same issue.
We run 3 registrar servers which run with user location "in-memory" (db_mode 0). These registrar's are configured to replicate registrations using the dmg_usrloc module. All works well except for when nat pinging is enabled.
When nat ping is enabled, it appears that the nathelper sends options pings from all 3 servers, and not only the server that processed the registration request. I have tried setting the server_id core parameter on all three of these servers in an attempt to ensure their uniqness, but still, the options pings are being sent from all 3 systems.
What I was expecting to see happen was that the registrar that processed/saved the registration, would be the only registrar performing the sip options ping, and the remaining two only have a replicated "copy" of the registration.
I'm not sure if this is meant to be classified as a bug or a feature request, seeing that the feature appears to be available when running with an sql database (I've not tested with usloc in database, we require usrloc to be in memory). Do I need to log a bug on github for this issue?
I've attached a copy of the aor (usrlock_dump.txt) as dumped by "kamctl ul show" on each of the registrars, and also a sip capture where you can see the options being sent by 3 registrars, but only 1 being responded to.
I've attached "sip_capture.txt" to show the options messages being sent by the 3 registrars. I've attached "module_settings.txt" to show the settings for the usrloc/registrar/nathelper modules in case there is a mishap there.
An additional observation is that when the registrars that did not process the registration (the ones replicated to), try to send their "ping", they send it over the incorrect interface (ignoring the nathelper parameter "force_socket" which has been set for all 3 registrars). I guess, in this circumstance, this is also a blessing in disguise or else the endpoint would have received 3 options pings to reply to every ping interval. However, I'm not sure if this is the expected bahaviour when setting force_socket for natping module.
Any thoughts/tips would be much appreciated.
Thanks