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