[SR-Users] Guidance on using Kamailio as Presence Server and Scalability issues for millions of subsribers

[Klaus Darilion]

On 15.10.2012 23:36, Thomas Hoffman wrote:
> We’re trying to determine how best to design/architect a solution where
> we use Kamailio as a Presence/XCAP server and be scalable to support
> millions of subscribers.
>
> I see the Dispatcher module, but it appears that requires having
> dedicated instances of the server running just in Dispatcher mode – then
> you can load balance across the actual instances of the presence
> servers.

Yes, it is typical to use a dispatcher to dispatch the load over several 
servers which do the real stuff (presence, gateways ...), eg:

clients <--Internet-----> dispatcher <------- server 1
                                      \------- server 2
                                       \------ server X

Dispatching (eg. Kamailio with dispatcher module) is much less resource 
intensive (e.g. no DB lookups, just stateless forwarding), thus a single 
dispatcher can handle the load for several backend servers.

If the load is too big for a single dispatcher node, then you need more 
dispatcher nodes. You can use for example multiple SRV records for the 
SIP domain, or provision the clients with different IP addresses (of the 
respective dispatcher nodes). Then, every dispatcher sends the traffic 
to a certain partition of the backend servers, or you distribute the 
traffic over all backend servers.

 > It’s not clear if a server can be configured to work as a
> dispatcher and a presence server at the same time.

Yes you can but it does not make sense - if a node itself is a presence 
server it does not make sense to dispatch the request to other presence 
servers. One if the main advantages of having a dispatcher in front of 
the cluster is to have a single border element (single IP address) which 
eases problems like NAT traversal.

> Does anyone have any high-level guidance how to approach this problem?

Presence requires, that a presence server which receives a subscription 
for a presentity, also knows the status of this presentity. There are 2 
approaches to handle this problem:

a) make sure to send PUBLISH requests from a certain presentity, and the 
SUBSCRIBE requests to this presentity, to the same presence backend. In 
this setup, every presence server uses its own database (or just memory 
without a DB). In case a presence server is removed (crash, maintenace), 
all traffic needs to be moved to other nodes and the current state is 
usually lost. Further you have to be sure to have the XCAP data 
available to all nodes.

b) all presence servers use the same database. In this case, the 
presence servers can not do any caching and have to query the DB for 
every operation. This setup simplifies the SIP setup, but increases the 
load on the DB and you may need a fast DB cluster. There were recently 
much changes to the presence modules for such a DB-only mode.


regards
Klaus