[SR-Users] rfc: distributing dialog profiles

Daniel-Constantin Mierla miconda at gmail.com
Fri Aug 22 16:52:59 CEST 2014


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




More information about the sr-users mailing list