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(a)cryy.com> wrote: -- Sincerely Jay

On Friday 04 September 2015 10:15:29 Daniel Tryba wrote: 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: 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_re… 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: -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com Kamailio Advanced Training, Sep 28-30, 2015, in Berlin - http://asipto.com/u/kat

On 07/09/15 19:36, Juha Heinanen wrote: 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 -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com Kamailio Advanced Training, Sep 28-30, 2015, in Berlin - http://asipto.com/u/kat

On 08/09/15 12:00, Juha Heinanen wrote: 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. different metrics, such as subscribers base and geographical distribution as well as calling patterns. It is not a single best solution. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com Kamailio Advanced Training, Sep 28-30, 2015, in Berlin - http://asipto.com/u/kat