There is no need for a generic timer callback option without good
typing, as we can just subclass the timer class and use our own fire()
method and whatever other class members are needed.
Change-Id: I95cd60277b5b4d3f492389958fa7f2ead921479e
This commit takes care of this:
../../core/log.h:143:30: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Wformat=]
143 | _LOG(L_DBG, error_category " " fmt, ##args)
../../core/log.h:121:45: note: in definition of macro '_LOG'
121 | int n_ = snprintf(msg_, sizeof(msg_), fmt, ##args); \
| ^~~
../../core/log.h:166:29: note: in expansion of macro 'CAT_DBG'
166 | #define DBG(fmt, args...) CAT_DBG(ERROR_CATEGORY_DGENERAL, fmt, ##args)
| ^~~~~~~
DBRegAgent.cpp:298:4: note: in expansion of macro 'DBG'
298 | DBG("REGISTER: Triggering for subscriber with object_id=<%d>\n", object_id);
| ^~~
DBRegAgent.cpp:298:62: note: format string is defined here
298 | DBG("REGISTER: Triggering for subscriber with object_id=<%d>\n", object_id);
| ~^
| |
| int
| %ld
../../core/log.h:143:30: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Wformat=]
143 | _LOG(L_DBG, error_category " " fmt, ##args)
../../core/log.h:121:45: note: in definition of macro '_LOG'
121 | int n_ = snprintf(msg_, sizeof(msg_), fmt, ##args); \
| ^~~
../../core/log.h:166:29: note: in expansion of macro 'CAT_DBG'
166 | #define DBG(fmt, args...) CAT_DBG(ERROR_CATEGORY_DGENERAL, fmt, ##args)
| ^~~~~~~
DBRegAgent.cpp:423:7: note: in expansion of macro 'DBG'
423 | DBG("REGISTER: Triggering for peering with object_id=<%d>\n", object_id);
| ^~~
DBRegAgent.cpp:423:62: note: format string is defined here
423 | DBG("REGISTER: Triggering for peering with object_id=<%d>\n", object_id);
| ~^
| |
| int
| %ld
Change-Id: I088f9a1a2861d1f7aae7b7cab84ce0e66b3127c2
This commit takes care of this:
DBRegAgent.cpp: In member function 'bool DBRegAgent::loadRegistrations()':
DBRegAgent.cpp:293:24: warning: NULL used in arithmetic [-Wpointer-arith]
293 | if (object_id == NULL || object_id == 0) {
It makes no sense to compare the `object_id` of type long against
the NULL.
Change-Id: I60cdde2dd459dbfa9c7c942cd8f0d111096411e7
We need to add a possibility to control (add/modify/delete) registrations
for SIP peerings using NGCP-panel. For that to work NGCP-panel uses XMLRPC
requests being sent towards SEMS, which in its turn takes care of work with:
- locally cached map structures:
* registrations / registrations_peers
* registration_ltags / registration_ltags_peers
* registration_timers / registration_timers_peers
- MySQL database (our scope of interest is 'sems_registrations')
- triggering events
Main amount of work is concentrated on interaction with map structures which keep
an actual information on registrations of either subscribers and peerings,
and less amount of work is related to the SQL side.
Basically, the main idea is to add an identifier, which will be used by
NGCP-panel when sending XMLRPC messages to SEMS, which will let SEMS know,
whether it's an event for a usual subscriber or a SIP peering.
Also we take care of loading time, when SEMS retrieves all previously saved data
from the DB using: peer / subscriber auth preferences and loads this to be usable.
A new query has been added for peering type, to let peerings be loadable after restart.
(real ticket number: TT#66577)
Change-Id: I0a815d50dd2728f2fa1411d21adfb084434766b2
add username_with_domain option to use auth user with domain part
(real ticket number: MT#9306)
implements M758
Change-Id: Ib482d4f1d49d291cab39add1b6a61c02c36bdbe4
Purpose
-------
The db_reg_agent module allows SEMS to read SIP accounts from a database
and register the accounts to SIP a registrar. In that it serves a similar
purpose as the reg_agent/registrar_client modules, with the differences
that it reads accounts from mysql DB instead of the file system, and that
it is built to support many (up to several 10k) subscription. Additionally,
accounts may be added, changed and removed while SEMS is running; the
db_reg_agent then can be triggered via DI interface (XMLRPC/json-rpc) to
pick up the new registration.
Features
- configurable subscription query
- configurable desired expires
- flatten out re-register spikes by intelligently planning registration refresh
- ratelimiting (x new REGISTER requests per y seconds)
- seamless restart of SEMS server possible; registration status is restored from DB.
Richard Fuchs
Donat Zenichev
Fabricio Santolin
Stefan Sayer
Roman Romanchenko
Victor Seva
Stefan Sayer