I'd vote for dmq and 'request-for-update'. As a mechanism to reject calls I'd suggest exporting the "status" function giving 1\-1 depending on whether we've received the latest state or not.
Couple of notes though: 1. All updates should have some sort of sequence numbers(?) otherwise there could appear conflicts. 2. During the 'getting the state' time kamailio should queue new messages or we'll never have a consistent data across the servers. So after all the best option looks like the hardest one =) BTW, why not relying on some 3rd party DB's replication for syncing profiles and data? So each kamailio works with local storage and the storage solves the master-master replication. 2014-08-22 18:52 GMT+04:00 Daniel-Constantin Mierla <mico...@gmail.com>: > Hello, > > if you are on sr-dev list, you should have seen the last commits to dialog > module, which add support for remote profiles. > > As most of you know (or at least the users of dialog module), profiles are > used to group active calls, their main purposes being counting dialogs > belonging to a profile for implementing active call limits (e.g., all calls > in the system, call from/to a specif user/address). > > It was working on a single Kamailio instance, but one could use other > meanings to interact with other kamailio instance to get the number of > calls across multiple instances. > > The purpose of remote profiles is to make the whole process easier and > more transparent for config file, simplifying the maintenance. > > A remote profile is an item stored in local profile list not bound to a > local dialog. At this moment, dialog module in master branch exports a > function dlg_remote_profile() that allows to add/remove a remote profile. > > The next step is to build the notification system between kamailio > instances. There are couple of options, as well as questions, that I want > to discuss before going to implement the mechanism. There are two major > aspects to care of: > > A) Distribution, I thought of two options for it: > > 1) using dmq module to publish the operations done with local profiles > (add/remove) -- this seems to be the natural choice right now, Charles > Chance is also willing to put effort in this direction > > This will be coded inside the module, so config won't be affected much > (eventually some extra parameters of dialog flags). > > 2) add event routes for adding/removing a local profile. The attributes of > the profile can be made available via some PV, then in config use what so > ever option (e.g., http query, json rpc, etc) for distributing the > information. > > This will require changes in config file and might not be trivial for new > users > > B) Persistence, with the options: > > 1) store remote profiles in local database. > > It is good for restart, but if there is big downtime, then some > notifications can be lost and the list of remote profiles might be > inaccurate > > 2) keep in memory only and at startup send a 'request-for-update' to the > other instances -- these instances will send the list of their local > profiles. > > It can take a bit between request-for-update and receiving data from the > other servers -- during this interval, the checks of overall call limits > might not give the desired answer > > Of course, there can be enhancements/combinations, but it has to be > analysed if the benefit worth the complexity. For 1), store also the IP of > each remote profile and then interrogate for each profile to see if its > still active. For 2), add a mechanism to reject new calls until the > request-for-update is completed. > > Anyone having other ideas or comments to the above? > > Note that each profile got a unique id, so if you upgrade your dialog > module, profiles for existing active calls will not be loaded. Also, the > code was barely tested, report here any issue you have with dialog from > master branch. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > Next Kamailio Advanced Trainings 2014 - http://www.asipto.com > Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA > > > _______________________________________________ > sr-dev mailing list > sr-...@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > -- Best regards, Alekzander Spiridonov
_______________________________________________ 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
