Discussion:
[SR-Users] rfc: distributing dialog profiles
Daniel-Constantin Mierla
2014-08-22 14:52:59 UTC
Permalink
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
Alex Hermann
2014-08-22 15:46:59 UTC
Permalink
Post by Daniel-Constantin Mierla
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
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).
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.
--
Alex Hermann
Charles Chance
2014-08-22 16:57:43 UTC
Permalink
Hi,
Post by Alex Hermann
Post by Daniel-Constantin Mierla
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
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).
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"?
Post by Alex Hermann
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 :)
Post by Alex Hermann
--
Alex Hermann
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
*Charles Chance*
--
www.sipcentric.com

Follow us on twitter @sipcentric <http://twitter.com/sipcentric>

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
Wiel Maessen
2014-08-22 17:23:31 UTC
Permalink
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
Alekzander Spiridonov
2014-08-22 15:19:29 UTC
Permalink
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.
Post by Daniel-Constantin Mierla
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
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
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
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Best regards,
Alekzander Spiridonov
Alex Hermann
2014-08-25 09:11:17 UTC
Permalink
Post by Charles Chance
Post by Alex Hermann
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.
Post by Charles Chance
Post by Alex Hermann
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
Charles Chance
2014-08-25 10:42:58 UTC
Permalink
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
Post by Alex Hermann
Post by Charles Chance
Post by Alex Hermann
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
- 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.
Post by Charles Chance
Post by Alex Hermann
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.
- Sync get off under load, cause unknown yet, but probably because of out-
of-order sync messages.
- 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
--
www.sipcentric.com

Follow us on twitter @sipcentric <http://twitter.com/sipcentric>

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
Daniel-Constantin Mierla
2014-08-25 11:35:46 UTC
Permalink
Are these patches on top of latest version of dialog module (the ones
with unique id per profile)?

Daniel
Post by Alex Hermann
Post by Charles Chance
Post by Alex Hermann
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
- 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.
Post by Charles Chance
Post by Alex Hermann
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.
- Sync get off under load, cause unknown yet, but probably because of out-
of-order sync messages.
- 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.
--
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
Alex Hermann
2014-08-25 12:02:49 UTC
Permalink
Post by Daniel-Constantin Mierla
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.
--
Alex.
Daniel-Constantin Mierla
2014-08-28 11:18:24 UTC
Permalink
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
Post by Alex Hermann
Post by Daniel-Constantin Mierla
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.
--
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
Continue reading on narkive:
Search results for '[SR-Users] rfc: distributing dialog profiles' (Questions and Answers)
5
replies
Internet Networking?
started 2006-05-06 20:47:15 UTC
computer networking
Loading...