kamailio doesn't provide number of registered users stat when usrloc in db_mode=3

[mading087]

Running latest 4.2 with usrloc in db_mode=3. It seems "kamctl stats usrloc" or "kamctl ul show" always shows 0 registered users even when there are registered users (location table has entries). Also, the SNMP KAMAILIO-SIP-SERVER-MIB::kamailioSIPRegAcceptedRegistrations.0 value is 0.
This looks like a bug?

[charlesrchance]

It is not a bug. From the docs:

3.20. db_mode (integer)

...

3 - DB-Only scheme. No memory cache is kept, all operations being directly
performed with the database...

...The lack of memory caching also disable the statistics exports.
On 19 Mar 2015 15:38, "mading087" notifications@github.com wrote:

Running latest 4.2 with usrloc in db_mode=3. It seems "kamctl stats
usrloc" or "kamctl ul show" always shows 0 registered users even when there
are registered users (location table has entries).
This looks like a bug?

—
Reply to this email directly or view it on GitHub
#113.

---

sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

www.sipcentric.com

Follow us on twitter @sipcentric http://twitter.com/sipcentric

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.

[mading087]

Thanks for the info. The same text is in the 4.2 usrloc doc as well.
Stats are important in some business cases. Guess we can consider this an enhancement. Wonder what is the best way to maintain the stats in db only mode.

1. change snmpstats to read from db instead of memory
2. maybe something easier than snmp, like acc/cdr from db?
   Just look for some recommendations. Thanks,

[oej]

On 19 Mar 2015, at 17:10, mading087 notifications@github.com wrote:

Thanks for the info. The same text is in the 4.2 usrloc doc as well.
Stats are important in some business cases. Guess we can consider this an enhancement. Wonder what is the best way to maintain the stats in db only mode.

1. change snmpstats to read from db instead of memory

That would not be smart - the number of hits on the database would not be low. I don't
see this as a snmpstats function - could be a usrloc function.
2. maybe something easier than snmp, like acc/cdr from db?

Counters are cool. Adding counters that keep track is propably the best way forward.
But that will be confusing if you are using db-only mode with multiple servers, since
there are additions done somewhere else.

In the end if you want to check this with snmp I suggest you write your own scripts and
add to the MIB using the custom options in snmpd.conf - its' quite easy and would solve
your problem.

As an alternative you can define your own script counter and have a background script
that runs your SQL query every X minutes and updates a counter that you can watch
with kamcmd and the old kamctl.

/O

[juha-h]

mading087 writes:

Thanks for the info. The same text is in the 4.2 usrloc doc as well. Stats are important in some business cases. Guess we can consider this an enhancement. Wonder what is the best way to maintain the stats in db only mode. 1. change snmpstats to read from db instead of memory 2. maybe something easier than snmp, like acc/cdr from db? Just look for some recommendations. Thanks,

it would, of course, be possible to implement the stat exports for db_mode=3 too. just execute in the module a suitable db query.

…

-- juha

[juha-h]

Olle E. Johansson writes:

As an alternative you can define your own script counter and have a background script that runs your SQL query every X minutes and updates a counter that you can watch with kamcmd and the old kamctl.

why would you need to run the query every X minutes instead of on demand when the relevant kamctl command is given?

…

-- juha

[mading087]

The script option with snmpd.conf seems ideal for my need. Thanks a lot for pointing that out.
Think I'll give it try using python snmp-passpersist module.
Guess X minutes cron job would be easier for straight snmp calls like get, walk etc.
And the same python script can be hooked up with kamctl for on demand query as well.

[kamailio-sync]

mading087 writes:

Guess X minutes cron job would be easier for straight snmp calls like get, walk etc. And the same python script can be hooked up with kamctl for on demand query as well.

i don't like the idea of kamctl being dependent on python. best would be adding sql queries to the module code. then the starts could be fetched also via xmlrpc, etc.

…

-- juha

[kamailio-sync]

On 19 Mar 2015, at 17:22, juha-h notifications@github.com wrote:

Olle E. Johansson writes:

As an alternative you can define your own script counter and have a
background script
that runs your SQL query every X minutes and updates a counter that
you can watch
with kamcmd and the old kamctl.

why would you need to run the query every X minutes instead of on demand
when the relevant kamctl command is given?

If one for some reason wants the counter available at all times in Kamailio...
But I agree with you that it's not a good solution at all. Just brainstorming.

/O

[kamailio-sync]

Charles Chance writes:

It is not a bug. From the docs: 3.20. db_mode (integer) ... 3 - DB-Only scheme. No memory cache is kept, all operations being directly performed with the database... <snip> ...The lack of memory caching also disable the statistics exports.

i would just like to add that there exists ul.db_users and ul.db_contacts rpc commands that provide similar info than users and contacts statistics.

…

-- juha

[miconda]

I don't think it worth adding C code for external SQL query needs. IIRC, during early SER times there was a command to execute any sql query via mi/fifo, but wasn't feasible and easy to maintain, therefore removed.

I kamctl can be added using db cli application (e.g., mysql) with a bit of grep/sed/awk will print only the value.

Fetching the value via xmlrpc should be possible via a bit of config scripting, inside route[XMLRPC] intercept the command before dispatch_rpc() (search over the body or using xmlops), do appropriate sql_query(...) via sqlops and push back a reply with a body in xmlrpc format.

I would propose to close this item here.