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
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@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:
- 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).
- 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:
- 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
- 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On Friday 22 August 2014 16:52:59 Daniel-Constantin Mierla wrote:
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:
- 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).
Last week, i just built profile synchronisation in the dialog module, based on dmq. It took quite a bit of debugging time because of the state dmq was in.
It still has some rough edges, but i'll try to push a branch (shortly after) this weekend for review.
Hi,
On 22 August 2014 16:46, Alex Hermann alex@speakup.nl wrote:
On Friday 22 August 2014 16:52:59 Daniel-Constantin Mierla wrote:
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:
- 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).
Last week, i just built profile synchronisation in the dialog module, based on dmq. It took quite a bit of debugging time because of the state dmq was in.
Can you expand a little on "the state dmq was in"?
It still has some rough edges, but i'll try to push a branch (shortly after) this weekend for review.
Looking forward to seeing it - may save me the time :)
-- Alex Hermann
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
Hello,
I am a newbie for Kamailio: I installed it on my Ubuntu server yesterday. Now I am running the server it seems that the client cannot be answered. In tcpdump I see that the call to port 5060 on the server is reached by the client, but the answer from the server is not:
[..] ICMP xx.yyyyyyy.net udp port is unreachable, length 556
I included tsl and nat in the make config. RSP proxy is also installed. So what else do I need to configure?
Cheers, \Wiel
--- Dit e-mailbericht bevat geen virussen en malware omdat avast! Antivirus-bescherming actief is. http://www.avast.com
On Friday 22 August 2014, Charles Chance wrote:
On 22 August 2014 16:46, Alex Hermann alex@speakup.nl wrote:
Last week, i just built profile synchronisation in the dialog module, based on dmq. It took quite a bit of debugging time because of the state dmq was in.
Can you expand a little on "the state dmq was in"?
I was hoping to use it as-is, but i encountered issues which had to be resolved before i could even use the module:
- As soon as i enabled the dmq module, i experienced segfaults. - It had bad interaction with the maxfwd module - Status updates between hosts were largely ignored. - The configured server_address wasn't used to send messages.
It still has some rough edges, but i'll try to push a branch (shortly after) this weekend for review.
Looking forward to seeing it - may save me the time :)
I pushed my WIP to the branch alexh/dialog-sync-wip which also contains dialog and dmq fixes and cleanups.
It's WIP, so it might still change. This branch is only compile-tested so far, because i normally develop against 3.2. I just cherry-picked most of my patches to master.
Known issues: - Sync get off under load, cause unknown yet, but probably because of out- of-order sync messages.
Still on the TODO list: - Delete 'disabled' dmq hosts - Cope better with out-of-order sync messages - Sync initial state - Clean shutdown of DMQ, free all memory - More efficient protocol instead of JSON. Probably just write raw data in the packet, so the receiving side can just use a pointer into the buf instead of having to copy everything.
Alex,
Thanks for expanding in such detail. I appreciate you taking the time to fix the things that I missed. Sometimes I think it may have been easier to start from scratch ;)
Best regards,
Charles On 25 Aug 2014 10:11, "Alex Hermann" alex@speakup.nl wrote:
On Friday 22 August 2014, Charles Chance wrote:
On 22 August 2014 16:46, Alex Hermann alex@speakup.nl wrote:
Last week, i just built profile synchronisation in the dialog module, based on dmq. It took quite a bit of debugging time because of the state dmq was in.
Can you expand a little on "the state dmq was in"?
I was hoping to use it as-is, but i encountered issues which had to be resolved before i could even use the module:
- As soon as i enabled the dmq module, i experienced segfaults.
- It had bad interaction with the maxfwd module
- Status updates between hosts were largely ignored.
- The configured server_address wasn't used to send messages.
It still has some rough edges, but i'll try to push a branch (shortly after) this weekend for review.
Looking forward to seeing it - may save me the time :)
I pushed my WIP to the branch alexh/dialog-sync-wip which also contains dialog and dmq fixes and cleanups.
It's WIP, so it might still change. This branch is only compile-tested so far, because i normally develop against 3.2. I just cherry-picked most of my patches to master.
Known issues:
- Sync get off under load, cause unknown yet, but probably because of out-
of-order sync messages.
Still on the TODO list:
- Delete 'disabled' dmq hosts
- Cope better with out-of-order sync messages
- Sync initial state
- Clean shutdown of DMQ, free all memory
- More efficient protocol instead of JSON. Probably just write raw data in
the packet, so the receiving side can just use a pointer into the buf instead of having to copy everything.
-- Alex
-- Alex Hermann
Are these patches on top of latest version of dialog module (the ones with unique id per profile)?
Daniel
On 25/08/14 11:11, Alex Hermann wrote:
On Friday 22 August 2014, Charles Chance wrote:
On 22 August 2014 16:46, Alex Hermann alex@speakup.nl wrote:
Last week, i just built profile synchronisation in the dialog module, based on dmq. It took quite a bit of debugging time because of the state dmq was in.
Can you expand a little on "the state dmq was in"?
I was hoping to use it as-is, but i encountered issues which had to be resolved before i could even use the module:
- As soon as i enabled the dmq module, i experienced segfaults.
- It had bad interaction with the maxfwd module
- Status updates between hosts were largely ignored.
- The configured server_address wasn't used to send messages.
It still has some rough edges, but i'll try to push a branch (shortly after) this weekend for review.
Looking forward to seeing it - may save me the time :)
I pushed my WIP to the branch alexh/dialog-sync-wip which also contains dialog and dmq fixes and cleanups.
It's WIP, so it might still change. This branch is only compile-tested so far, because i normally develop against 3.2. I just cherry-picked most of my patches to master.
Known issues:
- Sync get off under load, cause unknown yet, but probably because of out-
of-order sync messages.
Still on the TODO list:
- Delete 'disabled' dmq hosts
- Cope better with out-of-order sync messages
- Sync initial state
- Clean shutdown of DMQ, free all memory
- More efficient protocol instead of JSON. Probably just write raw data in
the packet, so the receiving side can just use a pointer into the buf instead of having to copy everything.
On Monday 25 August 2014, Daniel-Constantin Mierla wrote:
Are these patches on top of latest version of dialog module (the ones with unique id per profile)?
They're against a1b6093aaee, which includes some commits mentioning a unique id for profiles. I don't know if they interfere during runtime, because i only compile-tested it before pushing.
Indeed it seems to be after dlg profile structure changes.
Then I suggest to merge your branch into master so everyone can easily continue to work on it, if needed. As you already did it with dmq, makes this option selected for now. Also, I noticed other fixes/enhancements to dialog (e.g., rpc output with arrays, which was also pending on my list).
Thanks, Daniel
On 25/08/14 14:02, Alex Hermann wrote:
On Monday 25 August 2014, Daniel-Constantin Mierla wrote:
Are these patches on top of latest version of dialog module (the ones with unique id per profile)?
They're against a1b6093aaee, which includes some commits mentioning a unique id for profiles. I don't know if they interfere during runtime, because i only compile-tested it before pushing.
-
Alekzander Spiridonov -
Alex Hermann -
Charles Chance -
Daniel-Constantin Mierla -
Wiel Maessen