Many modules in Kamailio have a couple of operational modes for its storage, like using in-memory caching only or the external storage engine only, or hybrid.

The presence server implementation needs a storage engine (e.g., sql or no-sql database) to keep the data related to active subscriptions (active watchers), the permanent watcher details and published information (presentity data). These are corresponding to database tables active_watchers, watchers and presentity.

For active watchers there were already options to keep them in memory only, go always to the database or use a mixed mode. But the presentity records had to be in database always, with a mode to do in-memory indexing. The reason of using the external storage was that each record had to store a rather large XML document sent via PUBLISH requests. The development of the module was started about 15 years ago, keeping data of significant size on external backend was natural at the moment.

Nowadays more deployments are leveraging the elasticity of cloud infrastructure, when at least several nodes are always up and any new ones joining the grid are syncronizying using replication mechanisms (e.g., dmq, messaging queues (rabbitmq, nsq, …), evapi — to name a few available in Kamailio). Published data is also ephemeral, the presentity periodically sends updates of its presence state.

The master branch introduced recently a new operational mode for presentity records controlled by:

modparam(“presence”, “publ_cache”, 2)

making the presence module to keep presentity records in memory only. Combined with:

modparam(“presence”, “subs_db_mode”, 0)

everything stored by presence module is in memory, no external usage is needed. This can simplify the architecture of specific VoIP platforms, removing the need of deploying an external storage engine as well as increase the overall performances of presentity records management operations.

The presentity records in memory can be now monitored via RPC command:

# kamctl rpc presence.presentity_list

{
  "jsonrpc":  "2.0",
  "result": [
    {
      "user": "1002",
      "domain": "192.168.188.20",
      "event":  "presence",
      "etag": "a.1588662772.69311.2.0",
      "sender": "",
      "expires":  1588662974
    }, {
      "user": "1001",
      "domain": "192.168.188.20",
      "event":  "presence",
      "etag": "a.1588662772.69312.1.0",
      "sender": "",
      "expires":  1588662967
    }
  ],
  "id": 69371
}

That returns a selected set of attributes, to get all of them use “full” parameter to the RPC command:

# kamctl rpc presence.presentity_list full

{
  "jsonrpc":  "2.0",
  "result": [
    {
      "user": "1002",
      "domain": "192.168.188.20",
      "event":  "presence",
      "etag": "a.1588662772.69314.3.0",
      "sender": "",
      "expires":  1588663220,
      "received_time":  1588663040,
      "priority": 0,
      "ruid": "pres-5eb111f4-10ec2-1",
      "body": "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\r\n<presence xmlns=\"urn:ietf:params:xml:ns:pidf\"\r\n    xmlns:dm=\"urn:ietf:params:xml:ns:pidf:data-model\"\r\n    xmlns:rpid=\"urn:ietf:params:xml:ns:pidf:rpid\"\r\n    entity=\"sip:1002@192.168.188.20\">\r\n  <dm:person id=\"p4159\"><rpid:activities/></dm:person>\r\n  <tuple id=\"t4109\">\r\n    <status>\r\n      <basic>open</basic>\r\n    </status>\r\n    <contact>sip:1002@192.168.188.20</contact>\r\n  </tuple>\r\n</presence>\r\n",
      "hashid": -595120417
    }
  ],
  "id": 69434
}

The presence extensions in SIP are know to be complex, handling a new PUBLISH triggers a lot of internal processing to update watchers, apply XCAP rules if set, a.s.o. Therefore even this may sound like a small enhancement, a lot of code was updated. The implementation is young, so we call the community members to test the new operational mode if they need it, but also the old ones, to be sure nothing there was broken.

Any issue that is discovered should be reported to Kamailio bug tracker:

Special credits to Fred Posner and LOD.com for supporting the development of this feature and to Emmanuel Schmidbauer for helping to test and troubleshoot in the early phase of the development.

If you are looking to enable presence services on your Kamailio platform, here is a rather old but still a good starting point tutorial:

Enjoy! Stay safe and healthy!

Thanks for flying Kamailio!