10 Commits (mr11.5)

Author	SHA1	Message	Date
Donat Zenichev	178a5ad36d	MT#55831 add support of SIP peering registrations based on XMLRPC requests ... 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	4 years ago
Victor Seva	ff47897962	Imported Upstream version 1.6.0~20140516~eaa616	12 years ago
Victor Seva	d8b3cbf475	Imported Upstream version 1.4.3	13 years ago
Stefan Sayer	08c13de634	b/f: db_reg_agent: also stop RegistrationTimer thread on unclean shutdown	14 years ago
Stefan Sayer	04039d909d	b/f: cleaner shutdown of registration timer thread	15 years ago
Stefan Sayer	015c2e3f3c	b/f: further safety precautions on timer buckets	15 years ago
Stefan Sayer	7a6126210d	b/f: fix index search for search from the past	15 years ago
Stefan Sayer	526678f013	b/f: fix registration refresh if calculated in the past ... for restarts with expired registrations and with minimum_register_interval set, this could lead to lost registrations	15 years ago
Stefan Sayer	acb2338dff	b/f: deadlock on timer too far in the future	15 years ago
Stefan Sayer	7ae3ca4d4d	initial checkin of db_reg_agent module ... 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.	15 years ago