[SR-Users] how approach nathelper when using usrloc db_mode 3?

Albert Petit albertpetit at gmail.com
Thu Dec 1 13:43:22 CET 2011


Hello,

We found an issue when using nat pinger

Previously our system had 1 Kamailio as entry point and we were using
usrloc in mode  2 so:
modparam("usrloc", "db_mode",2)
modparam("usrloc", "db_url",
        "mysql://openser:openserrw@<DB_IP>/openser")

On our system we like to use the pinger NAT_HELPER module to keep the
connections alive for the users of our system.

 Now we're trying to configure two Kamailio K1 and K2 as entry point of the
system and having both of them active at the same time with a virtual IP as
common entry point for both.
I believe this approach requires to flush information on the usrloc
immediately because following use case can happen and needs to work:
- A registers on K1 server
- B registers on K2 server
-After 5 seg  B makes an INVITE to A through K2=>  we need K2 kamailio
instance to be able to locate A immediately and not wait until the first
Kamailio flushes the info to the db. (it looks to be around 20/30 seg by
default  on mode 2 I think , correct so this looks to be  too much time)

So to improve this we tried to change to use usrloc in mode 3 instead of
mode 2. But then we've a big issue: when enabling the pinger module for
NATted users we see  it opens a new connection to the db for each OPTIONS
ping we want to send.  That looks too many connections for our MySQL server
because for eg if I leave two users registered for 1 hour after some time I
start to see errors like:
13(5292) ERROR: <core> [db_query.c:130]: error while submitting query
13(5292) ERROR: usrloc [dlist.c:151]: raw_query failed
13(5292) ERROR: nathelper [nathelper.c:3459]: failed to fetch contacts
13(5292) ERROR: db_mysql [km_dbase.c:117]: driver error on query: Too many
conne


How should this problem be approached? Could this be due to wrong mysql
configuration? But anyway if for each ping done by NAT_PINGER we make a
query to the db I think this is a lot of "noise" for the db as pings happen
often!
Thanks

BR
Albert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20111201/a0bdb5ee/attachment.htm>


More information about the sr-users mailing list