[SR-Users] Best practise for limiting concurrent calls across a cluster

[Daniel-Constantin Mierla]

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
>
>
>
> 2015-09-04 13:53 GMT+01:00 Daniel Tryba <d.tryba at pocos.nl
> <mailto:d.tryba at 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 at lists.sip-router.org <mailto:sr-users at 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150907/2327e13c/attachment.html>