Re: [SR-Users] [sr-dev] rfc: distributing dialog profiles

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-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev