Im currently using cassandra with kamailio I need something thats highly available and partition tolerant, consistency is a secondary requirement for most of the data.

Im really not sure that restful web services are the right way here, that seems like a LOT of overhead at high cps.

Sorry I forgot to add, that this is for a provider network, not a corporate / pbx implementation. I need to be able to handle hundreds / thousands of invites per second, with minimal latency.

Jay

On 4 September 2015 at 10:43, Brandon Armstead brandon@cryy.com wrote:

I would use some kind of RESTFUL service implementation, various transport mediums are avail i.e. RPC etc. What database are you currently using ?

Sincerely, Brandon Armstead

...

On Sep 3, 2015, at 5:19 PM, jay binks jaybinks@gmail.com wrote:

Hey all,

So I have a cluster of Kamailio servers ( 4 servers currently, soon to

be 8 ),

...

I'm looking for suggestions about the BEST way to achieve concurrent

call limiting on a per customer basis, across the whole cluster.

...

Initially I mis-read the dialog module documentation and assumed that

dialog would provide me this ability, when used with a database. however it seems that the dialog module does not pull data from the DB after the initial startup.

...

I know I can use sql ops to increment and decrement using

event_route[dialog:start] and event_route[dialog:end]. however the database I've chosen ( for other valid reasons ) does not have an atomic increment and decrement. I could add yet another DB, but that just adds more failure points.

...

so lets forget my setup, Im wanting suggestions about the BEST setup

for this sort of thing. while remaining fault tolerant, and preferably without relying on any single point of failure.

...

Sincerely

Jay _______________________________________________ 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

---

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

On Friday 04 September 2015 10:15:29 Daniel Tryba wrote:

But isn't the easiest/best solution to just use sqlops to count the number of dialogs for the current endpoints? select count(id) from dialog where xdata like '"name":"maxchannels","value":"$dlg_var(key)"' where the dialog var contains callid.

That makes no sense.... the key should be a unique identifier for the caller/callee (resp. $au and $rU (and taking the domain in consideration if you use multi domain))

On Friday 04 September 2015 10:56:21 Carsten Bock wrote:

i did implement such mechanism once using a htable and DMQ, that worked like a charm.

Sound good, my current solution misses concurrent call setup that happen withing the dialog db_update_period timeout.

Hello,

some of my thoughts on the topic, presented as concepts ...

There is a function dlg_remote_profile() that can be used to mirror only profiles from one sip server to another:

- http://kamailio.org/docs/modules/stable/modules/dialog.html#dialog.f.dlg_rem...

The idea is that when you add a dialog on a local profile, trigger an action to the other server to add a remote profile. It can be done via uac_req_send() or some http query to the other server.

This is one way to go, ans should work fine (maybe a bit more testing needed) for few nodes, but I am actually not using this one, because it is a matter of what kind of routing architecture you go for. Lately I found that replication can bring lots of headaches when dealing with a lot of traffic and having lots of nodes. You can't replicate everything everywhere (usrloc, dialog, etc...), because then practically you have only HA, no scalability -- each node has the same data, so when one node is full, all are full (expecting to be same hardware capacity more or less with each node).

The architecture I am going lately is sort of hierarchical nodes, with edge nodes (EN) keeping all the information, and next layer (let's name it super node/SN) retrieving far more less information and very rare. Like when alice registers to edge node A, A will inform few supper nodes that alice is with it. This is done only at first registration (when alice is not registered when processing REGISTER). When bob is calling alice via its EN B, then B routes to a SN because alice is not found locally. The SN sends to EN A -- after answer, based on record routing, the singaling can end up bob-ENB-ENA-alice. If alice unregistered meanwhile, EN A can return 404, if it didn't removed info from SN. Instead of replicating a location record every 10minutes, an invite is routed only when needed.

More or less same architecture I use for dialog profiles. I leverage event routes from dialog module to know when a dialog ended to remove information from a storage engine. The storage engine can be sql or nosql database, which has HA by itself (when needed, with replication) -- you can use modules such as sqlops, ndb_redis, ndb_cassandra, ndb_mongodb, memchaced. The logic is:

- when dialog is initiated, verify if the number of active calls for the user has a limit (select/find by userid) - add data for the new dialog - when dialog is cancelled or ended, remove the data for the dialog

Data to be stored: userid, profile name, call-id (+fromtag/totag) or/and dialog id+label.

If there are lots of active calls, I use few storage systems, partitioning the profiles by userid, so all records of active calls for a user are in the same storage system.

Everything above should need only config file scripting, no c coding.

Cheers, Daniel

On 04/09/15 15:18, José Seabra wrote:

Hi,

I'm also using the same mechanism that Carsten is using(htable and DMQ), the only issue about this solution is when one of your kamailio instances goes down and up, this instance looses the number of current calls.

Regards José Seabra

2015-09-04 13:53 GMT+01:00 Daniel Tryba <d.tryba@pocos.nl mailto:d.tryba@pocos.nl>:

On Friday 04 September 2015 10:56:21 Carsten Bock wrote:
> i did implement such mechanism once using a htable and DMQ, that
> worked like a charm.

Sound good, my current solution misses concurrent call setup that
happen
withing the dialog db_update_period timeout.

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Cumprimentos José Seabra

---

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

On 07/09/15 19:36, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

This is one way to go, ans should work fine (maybe a bit more testing needed) for few nodes, but I am actually not using this one, because it is a matter of what kind of routing architecture you go for. Lately I found that replication can bring lots of headaches when dealing with a lot of traffic and having lots of nodes. You can't replicate everything everywhere (usrloc, dialog, etc...), because then practically you have only HA, no scalability -- each node has the same data, so when one node is full, all are full (expecting to be same hardware capacity more or less with each node).

If usrloc subscriber table is kept in database (db_only mode), it does not become "full" very easily.

True, just that is no longer memory states replication, but more like the concept I talked about with an external storage system.

However, even in this case, when the subscriber base is really huge, single mysql system can become slow, so there needs to be some partitioning of the users, relying on several mysql systems.

Cheers, Daniel

On 08/09/15 12:00, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

However, even in this case, when the subscriber base is really huge, single mysql system can become slow, so there needs to be some partitioning of the users, relying on several mysql systems.

In that case partitioning could be done also based on userid or phone number pattern rather than complicating the server setup.

Are you referring to the hierarchical architecture I plugged in as example for usrloc, or about the topic of limiting the concurrent calls using a backend system?

The later is nothing that complex to be added and is more or less what you are saying.

For the former, it depends on the topology of the service and distribution of subscribers.

For example, if you have the sip server nodes close to each other, then you can do partitioning directly to few backends and access them/do queries from all sip nodes.

But if you have the nodes across the world, replicating to all nodes or querying the other site is adding a lot of overhead and latency. For example, if you have 1 000 000 subscribers on each of 4 nodes (say Dallas, Frankfurt, Singapore and Sidney), then accessing from one site the backend of each other site can be costly (time) and replication of location records will generate a lot of traffic (no matter is mysql layer or sip layer). Being expected that most of the subscribers have contacts in their region, having all records locally makes less sense as well.

The hierarchical model is not the only one, for 4 nodes over all, one can do parallel forking to the other 3 if the target is not online in the respective node.

From my point of view, the architecture to deploy is really a matter of

different metrics, such as subscribers base and geographical distribution as well as calling patterns. It is not a single best solution.

Cheers, Daniel