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

[Alekzander Spiridonov]

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



-- 
Best regards,
Alekzander Spiridonov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140822/05ae2718/attachment.html>