# &adminguide;

## Overview

The Presence module implements the core functionality of SIP event notification. It handles PUBLISH and SUBSCRIBE messages and generates NOTIFY messages in a general, event independent way. It is extensible and allows registering events to it from other &kamailio; modules. Supported SIP event packages are presence, presence.winfo, dialog;sla from the presence_xml module and message-summary from the presence_mwi module.

The module can use database and memory storage (to improve performance). For subscriptions it supports the 4 storage modes: Memory Only, Write Back, Write Through and DB Only. For publishes, it stores the state documents in database only (because of the large size) and it can store a publish cache in memory to avoid unnecessary database queries. Read the subs_db_mode and publ_cache parameter sections to decide which is the best storage configuration for you.

The module implements several API functions, that can be used by other modules. In fact, it can be used only as a resource module, or "library". This mode of operation is enabled if the db_url parameter is not set to any value.

The &kamailio; Presence module implements the specifications in: RFC3265, RFC3856, RFC3857, RFC3858.

## Dependencies

### &kamailio; Modules

The following modules must be loaded before this module:

- a database module.

- sl.

- tm.

- dmq (only if replication is enabled).

### External Libraries or Applications

- libxml.

## Parameters

### `db_url`(str)

The database url.

If set, the module is a fully operational presence server. Otherwise, it is used as a 'library', for its exported functions.

Default value is NULL.

#### Set `db_url` parameter

    ...
    modparam("presence", "db_url",
    	"&defaultdb;")
    ...

### `presentity_table`(str)

The name of the db table where PUBLISH presence information is stored.

Default value is presentity.

#### Set `presentity_table` parameter

    ...
    modparam("presence", "presentity_table", "presentity")
    ...

### `active_watchers_table`(str)

The name of the db table where active subscription information is stored.

Default value is active_watchers.

#### Set `active_watchers_table` parameter

    ...
    modparam("presence", "active_watchers_table", "active_watchers")
    ...

### `watchers_table`(str)

The name of the db table where subscription states are stored.

Default value is watchers.

#### Set `watchers_table` parameter

    ...
    modparam("presence", "watchers_table", "watchers")
    ...

### `clean_period` (int)

The period in seconds between checks if there are expired messages stored in the database.

Default value is 100. A zero or negative value disables this activity.

#### Set `clean_period` parameter

    ...
    modparam("presence", "clean_period", 100)
    ...

### `cseq_offset` (int)

The allowed offset between server and client cseq.

Default value is 0.

#### Set `cseq_offset` parameter

    ...
    modparam("presence", "cseq_offset", 1)
    ...

### `db_update_period` (int)

The period at which to synchronize cached subscriber info with the database.

Default value is 100. A zero or negative value disables synchronization.

#### Set `db_update_period` parameter

    ...
    modparam("presence", "db_update_period", 100)
    ...

### `waitn_time` (int)

The maximum time period that NOTIFY requests will be buffered for. The server will attempt to send NOTIFY requests within many seconds of a change occurring.

Note: this parameter is only used when notifier_processes is greater than 0. When notifier_processes is less than or equal to 0 NOTIFY requests are sent immediately.

Default value is 5.

#### Set `waitn_time` parameter

    ...
    modparam("presence", "waitn_time", 10)
    ...

### `notifier_poll_rate` (int)

The number of times per second that the notifier processes should check for work. Approximately 1/(waitn_time * notifier_poll_rate * notifier_processes) of the pending updates will be sent each time a notifier process runs.

Separate notifier processes are only run when subs_db_mode is 3 (DB only mode).

Default value is 10.

#### Set `notifier_poll_rate` parameter

    ...
    modparam("presence", "notifier_poll_rate", 20)
    ...

### `notifier_processes` (int)

The number of notifier processes that should be started.

Separate notifier processes are only run when subs_db_mode is 3 (DB only mode).

Note: setting this parameter to 0 when subs_db_mode is 3 keeps the old behaviour (sending NOTIFY requests immediately). This (old) behaviour is disabled by default in DB only mode because under load, when lots of NOTIFY requests can be sent on a dialog at the same time, there are race conditions which result in CSeq re-use.

Default value is 1.

#### Set `notifier_processes` parameter

    ...
    modparam("presence", "notifier_processes", 2)
    ...

### `force_delete` (int)

Enabling this parameter will delete expired presentity records without updating watchers.

Set this parameter to 1 to enable.

Default value is 0.

#### Set `force_delete` parameter

    ...
    modparam("presence", "force_delete", 1)
    ...

### `startup_mode` (int)

Setting this parameter to 0 will provide startup related backward compatibility for some modules. Setting to 0 fixes presentity requests with low expires (e.g. time() + 1)

Set this parameter to 0 to enable backward compatibility.

Default value is 1.

#### Set `startup_mode` parameter

    ...
    modparam("presence", "startup_mode", 0)
    ...

### `expires_offset` (int)

The value in seconds that should be subtracted from the expires value when sending a 200OK for a publish. It is used for forcing the client to send an update before the old publish expires.

Default value is 0.

#### Set `expires_offset` parameter

    ...
    modparam("presence", "expires_offset", 10)
    ...

### `max_expires` (int)

The maximum admissible expires value for PUBLISH/SUBSCRIBE message (in seconds).

Default value is 3600.

#### Set `max_expires` parameter

    ...
    modparam("presence", "max_expires", 3600)
    ...

### `min_expires` (int)

The minimum admissible expires value for PUBLISH/SUBSCRIBE message (in seconds).

If > 0 then min_expires_action parameter determines the response.

Default value is 0.

#### Set `min_expires` parameter

    ...
    modparam("presence", "min_expires", 1800)
    ...

### `min_expires_action` (int)

The action to take when UA sends an expires value less than min_expires.

#### Possible Values

- 1 : RFC Compliant, returns 423 Interval Too Brief

- 2 : forces the min_expires value in the subscription

If > 0 then min_expires_action parameter determines the response.

Default value is 1.

#### Set `min_expires` parameter

                ...
                modparam("presence", "min_expires", 1800)
                ...

### `server_address` (str)

The presence server address which will become the value of Contact header filed for 200 OK replies to SUBSCRIBE and PUBLISH and in NOTIFY messages.

#### Set `server_address` parameter

    ...
    modparam("presence", "server_address", "sip:10.10.10.10:5060")
    ...

### `subs_db_mode` (int)

The presence module can utilize database for persistent subscription storage. If you use database, your subscriptions will survive machine restarts or SW crashes. The disadvantage is that accessing the database can be time consuming. Therefore, presence module implements four database accessing modes:

- 0 - This disables database completely. Only memory will be used. Subscriptions will not survive restart. Use this value if you need a really fast presence module and subscription persistence is not necessary or is provided by other means.

- 1 - Write-Through scheme. Subscriptions are updated synchronously in database and in memory(used for read operations). Use this scheme if speed is not top priority, but it's important that no subscriptions will be lost during crash or reboot or if you have an external application that reads the state of the subscriptions from database and they need to be updated synchronously.

- 2 - Write-Back scheme. This is a combination of previous two schemes. All changes are made to memory and database synchronization is done in the timer. The timer deletes all expired contacts and flushes all modified or new subscriptions to database. Use this scheme if you encounter high-load peaks and want them to process as fast as possible. Latency of this mode is much lower than latency of mode 1, but slightly higher than latency of mode 0. To control the interval at which data is flushed to database, set the db_update_period parameter.

- 3 - DB-Only scheme. No memory cache is kept, all operations being directly performed with the database. The timer deletes all expired subscriptions from database. The mode is useful if you configure more servers sharing the same DB without any replication at SIP level. The mode may be slower due the high number of DB operation.

Default value is 2 (Write-Back scheme).

#### Set `subs_db_mode` parameter

    ...
    modparam("presence", "subs_db_mode", 1)
    ...

### `publ_cache` (int)

To improve performance, the presence module can operate in a couple of modes related to how PUBLISH data is stored. If publ_cache is 0, then no information is stored in memory.

If publ_cache is 1, then the module keeps in memory an index of the records stored in database, In this mode it keeps only the list of URIs and events, so it does not use much memory. The cache is used when a Subscription is received to check if there is any published state in database. This way unnecessary queries in presentity table are avoided.

If publ_cache is 2, then the module keeps everything related to PUBLISH requests in memory, not storing anything in the database.

Setting this parameter to 0 will disable the usage of the publish cache. This is desirable when you have more servers sharing the same database or there are other external entities inserting data into the presentity table.

Default value is 1.

#### Set `publ_cache` parameter

    ...
    modparam("presence", "publ_cache", 0)
    ...

### `subs_htable_size` (int)

The size of the in-memory hash table to store subscription dialogs. This parameter will be used as the power of 2 when computing table size.

Default value is 9 (512).

#### Set `subs_htable_size` parameter

    ...
    modparam("presence", "subs_htable_size", 11)
    ...

### `pres_htable_size` (int)

The size of the in-memory hash table to store publish records. This parameter will be used as the power of 2 when computing table size.

Default value is 9 (512).

#### Set `pres_htable_size` parameter

    ...
    modparam("presence", "pres_htable_size", 11)
    ...

### `send_fast_notify` (int)

This parameter enables or disables the sending of an initial empty NOTIFY after a SUBSCRIBE/reSUBSCRIBE. This caused problems for MWI application, because some CPEs (like Samsung) fail to understand an empty NOTIFY to a message-summary event. This parameter is enabled by default, thus adhering to the standard.

Default value is 1 .

#### Set `send_fast_notify` parameter

    ...
    modparam("presence", "send_fast_notify", 0)
    ...

### `enable_sphere_check` (int)

This parameter is a flag that should be set if permission rules include sphere checking. The sphere information is expected to be present in the RPID body published by the presentity. The flag is introduced as this check requires extra processing that should be avoided if this feature is not supported by the clients.

Default value is 0 .

#### Set `enable_sphere_check` parameter

    ...
    modparam("presence", "enable_sphere_check", 1)
    ...

### `timeout_rm_subs` (int)

This parameter is a flag that should be set if subscriptions should be removed from the active_watchers when a NOTIFY times out. RFC3265 section 3.2.2 defines this behaviour as a SHOULD, so by default it is on. Disabling this will keep subscriptions active on unreliable networks.

Default value is 1.

#### Set `timeout_rm_subs` parameter

    ...
    modparam("presence", "timeout_rm_subs", 0)
    ...

### `fetch_rows` (integer)

Number of rows to be loaded in one step from database.

Default value is 500.

#### Set `fetch_rows` parameter

    ...
    modparam("presence", "fetch_rows", 1000)
    ...

### `db_table_lock_type` (integer)

Enable (=1) or disable (=0) the Locks for table during a transaction. Locking only the "current" table causes problems with a MySQL-Databases in "DB-Only" mode.

In order to use the Presence-Module in "DB_ONLY"-mode with a MySQL-Backend, set this parameter to "0", otherwise the MySQL-Operations will fail. The Presence-Module will generate a "500 Server error" due to the failed MySQL-queries.

Default value is 1 (Write Lock for the Tables).

#### Set `db_table_lock_type` parameter

    ...
    modparam("presence", "db_table_lock_type", 0)
    ...

### `local_log_level` (int)

Control log level for some debug messages inside the module.

Default value is 2 (L_INFO).

#### Set `local_log_level` parameter

    ...
    modparam("presence", "local_log_level", 3)
    ...

### `local_log_facility` (int)

Control syslog facility for some debug messages inside the module.

Default value is taken from the core log_facility configuration parameter.

#### Set `local_log_facility` parameter

    ...
    modparam("presence", "local_log_facility", "LOG_LOCAL3")
    ...

### `subs_remove_match` (int)

Control how to match the subscriptions to remove from memory. If set to 0, then the match is done on To-Tag (local generated), if set to 1, then the match is done on all dialog attributes (Call-Id, From-Tag, To-Tag).

Default value is 0.

#### Set `subs_remove_match` parameter

    ...
    modparam("presence", "subs_remove_match", 1)
    ...

### `xavp_cfg` (str)

The name of the xavp to be used to specify attributes for internal processing of presence module.

Inner attributes inside xavp can be:

- priority - integer value to set the priority of the presence document (higher value, higher priority). It can set the order of the aggregated presence documents sent by NOTIFY (first the document with higher priority). If xavp_cfg parameter is set but this attribute is not in the avp, the priority of the presence document is based on timestamp, so newer documents have higher priority.

- delete_subscription - integer value to give extra control of deleting the subscription after processing of event_route[presence:notify-reply]. If value = 1, it deletes the subscription. If xavp_cfg parameter is set but this attribute is not in the avp, the subscription is not deleted. This does not apply for codes 404, 481 and 408 (when timeout_rm_subs = 1) where subscription is deleted.

Default value is empty (not set).

#### Set `xavp_cfg` parameter

    ...
    modparam("presence", "xavp_cfg", "pres")
    ...
    if(is_method("PUBLISH")) {
        $xavp(pres=>priority) = 100;
    }
    ...

### `retrieve_order` (int)

If set to 0, presentity records are retrieved by received_time order. If set to 1, presentity records are retrieved by the value of retrieve_order_by parameter.

Default value is 0.

#### Set `retrieve_order` parameter

    ...
    modparam("presence", "retrieve_order", 1)
    ...

### `retrieve_order_by` (str)

Used to set the order-by of the db query for fetching the presence records when retrieve_order is set to 1.

Default value is priority.

#### Set `retrieve_order_by` parameter

    ...
    modparam("presence", "retrieve_order_by", "priority, received_time")
    ...

### `sip_uri_match` (int)

The mode used when comparing uris.

#### Possible Values

- 0 : case sensitive

- 1 : case insensitive

Default value is 0.

#### Set `sip_uri_match` parameter

    ...
    modparam("presence", "sip_uri_match", 1)
    ...

### `enable_dmq` (integer)

If set to 1, will enable DMQ replication of presence data between nodes. Use this instead of a shared DB to share state across a cluster and update local watchers in realtime (subs_db_mode < 3) or on next notifier run (subs_db_mode = 3).

If this parameter is enabled, the DMQ module must be loaded first - otherwise, startup will fail.

Default value is 0.

#### Set `enable_dmq` parameter

    ...
    modparam("presence", "enable_dmq", 1)
    ...

### `enable_pres_dmq` (integer)

If set to 1, will enable DMQ replication of presentities.

Make sure that enable_dmq is set to 1.

Default value is 1.

#### Set `enable_pres_dmq` parameter

    ...
    modparam("presence", "enable_pres_dmq", 1)
    ...

### `enable_pres_sync_dmq` (integer)

If set to 1, will enable initial synchronization of presentities state.

Make sure that enable_dmq and enable_pres_dmq are set to 1.

Default value is 1.

#### Set `enable_pres_sync_dmq` parameter

    ...
    modparam("presence", "enable_pres_sync_dmq", 1)
    ...

### `enable_subs_dmq` (integer)

If set to 1, will enable DMQ replication of subscriptions.

Make sure that enable_dmq is set to 1.

Default value is 0.

#### Set `enable_subs_dmq` parameter

    ...
    modparam("presence", "enable_subs_dmq", 1)
    ...

### `enable_subs_sync_dmq` (integer)

If set to 1, will enable initial synchronization of subscriptions state.

Make sure that enable_dmq and enable_subs_dmq are set to 1.

Default value is 1.

#### Set `enable_subs_sync_dmq` parameter

    ...
    modparam("presence", "enable_subs_sync_dmq", 1)
    ...

### `skip_notify_dmq` (integer)

Skip sending Notify messages if presentity was received by DMQ.

Default value is 0.

#### Set `skip_notify_dmq` parameter

    ...
    modparam("presence", "skip_notify_dmq", 1)
    ...

### `default_socket` (str)

Default socket name to rewrite socket info in subcription that was received by DMQ.

By default is not defined. Socket info will be original value from DMQ message.

#### Set `default_socket` parameter

    ...
    modparam("presence", "default_socket", "udp:192.168.0.125:5060")
    ...

### `pres_subs_mode` (integer)

Allow disabling cloning subscription structure for pv $subs(...), saving the pkg memory and copy operations for all its fields. If 1 the cloning is done; if 0, no cloning and $subs(...) returns $null.

Default value is 1.

#### Set `pres_subs_mode` parameter

    ...
    modparam("presence", "pres_subs_mode", 0)
    ...

### `delete_same_subs` (integer)

Enable deleting of subscriptions with the same presence uri and callid.

Default value is 0 (disabled behavior).

#### Set `delete_same_subs` parameter

    ...
    modparam("presence", "delete_same_subs", 1)
    ...

### `timer_mode` (integer)

Specify what timer process to be used. If set to 0, the core main timer is used. If set to 1, the core secondary timer is used.

Default value is 1.

#### Set `timer_mode` parameter

    ...
    modparam("presence", "timer_mode", 0)
    ...

### `subs_respond_200` (integer)

Specify the response code for accepted SUBSCRIBE requests. If set to 0, "202 Accepted" will be returned (default behaviour till version 5.5). If set to 1, "200 OK" will be returned instead, in conformance to RFC6665, which prohibits 202 responses.

Default value is 1.

#### Set `subs_respond_200` parameter

    ...
    modparam("presence", "subs_respond_200", 0)
    ...

## Functions

### `handle_publish([sender_uri])`

Handles PUBLISH requests by storing and updating published information in memory cache and database, then calls functions to send NOTIFY messages when changes in the published information occur. It takes one argument -> sender_uri. The parameter was added for enabling BLA implementation. If present, notification of a change in published state is not sent to the respective uri even though a subscription exists. It should be taken from the Sender header. It was left at the decision of the administrator whether or not to transmit the content of this header as parameter for handle_publish, to prevent security problems.

This function can be used from REQUEST_ROUTE.

Return code:

- 1 - if success.

- -1 - if error.

The module sends an appropriate stateless reply in all cases.

#### `handle_publish` usage

    ...
    	if(is_method("PUBLISH"))
    	{
    		if($hdr(Sender)!= NULL)
    			handle_publish("$hdr(Sender)");
    		else
    			handle_publish();
    		t_release();
    	}
    ...

### `handle_subscribe([watcher_uri])`

The function which handles SUBSCRIBE requests. It stores or updates information in memory and database and calls functions to send NOTIFY messages when a SUBSCRIBE which initiate a dialog is received.

By default this function uses the From: URI from the SUBSCRIBE request as the Watcher URI. The optional watcher_uri parameter can be used to specify a different Watcher URI, possibly taken from a SIP header like P-Asserted-Identity:.

This function can be used from REQUEST_ROUTE.

Return code:

- 1 - if success.

- -1 - if error.

The module sends an appropriate stateless reply in all cases.

#### `handle_subscribe` usage

    ...
    if(method=="SUBSCRIBE")
        handle_subscribe();
    ...

### `pres_auth_status(watcher_uri, presentity_uri)`

The function checks if watcher URI is authorized to subscribe event 'presence' of presentity URI. Both watcher_uri and presentity_uri can be static strings or contain pseudo variables.

The function returns ACTIVE_STATUS, if subscription is allowed, and PENDING_STATUS, TERMINATED_STATUS, or WAITING_STATUS otherwise. See presence/subscribe.h for the corresponding integer codes. In case of error, function returns -1.

This function can be used from REQUEST_ROUTE.

#### `pres_auth_status` usage

    ...
    if (method=="MESSAGE") {
        pres_auth_status("$fu", $ru");
        if ($retcode == 1) {
            t_relay();
        } else {
            send_reply("403", "Forbidden");
        }
    }
    ...

### `pres_has_subscribers(presentity_uri, event)`

Allows to check if presentity has any subscribers of event.

This function can be used from ANY_ROUTE.

#### `pres_has_subscribers` usage

    ...
    if(pres_has_subscribers($var(uri), "message-summary"))
        # do something...;
    ...

### `pres_refresh_watchers(uri, event, type[, file_uri, filename])`

The function can be used in configuration to trigger notifies to watchers if a change in watchers authorization or in published state occurred (i.e., updates of xcap documents).

Parameters:

- uri - the uri of the user who made the change and whose watchers should be informed.

- event - the event package.

- type - it distinguishes between the three different types of events that can trigger the refresh, depending on its value:

  - 0 - a change in watchers authentication.

  - 1 - a statical update in published state through direct update in db table.

  - 2 - a statical update in published state by modifying the pidf manipulation document.

- file_uri - the uri of the pidf-manipulation file on the XCAP server (only used for type 2).

- filename - the name of the pidf-manipulation file on the XCAP server (only used for type 2).

This function can be used from ANY_ROUTE.

#### `pres_refresh_watchers` usage

    ...
    pres_refresh_watchers("sip:test@kamailio.org", "presence", 1);
    ...

### `pres_update_watchers(uri, event)`

The function can be used in configuration to trigger updates to watchers status if a change in watchers authorization state occurred (i.e., updates of xcap documents change state from pending to active).

Parameters:

- uri - the uri of the user who made the change and whose watchers should be informed. Can be PV.

- event - the event package (e.g., presence).

This function can be used from ANY_ROUTE.

#### `pres_update_watchers` usage

    ...
    pres_update_watchers("sip:test@kamailio.org", "presence");
    ...

## RPC Commands

### presence.cleanup

Manually triggers the cleanup functions for the active_watchers, presentity, and watchers tables. Useful if you have set `clean_period` and/or `db_update_period` to zero or less.

Name: presence.cleanup

Parameters: none

RPC Command Format:

    ...
    &kamctl; rpc presence.cleanup
    ...

### presence.publish_cache_sync

Synchronize changes made to the presentity table with the publish cache.

Name: presence.publish_cache_sync

Parameters: none

RPC Command Format:

    ...
    &kamctl; rpc presence.publish_cache_sync
    ...

### presence.refreshWatchers

Triggers sending Notify messages to watchers if a change in watchers authorization or in published state occurred.

Name: presence.refreshWatchers

Parameters:

- uri - the uri of the user who made the change and whose watchers should be informed

- event - the event package.

- type - it distinguishes between the three different types of events that can trigger the refresh, depending on its value:

  - 0 - a change in watchers authentication.

  - 1 - a statical update in published state through direct update in db table.

  - 2 - a statical update in published state by modifying the pidf manipulation document.

- file_uri - the uri of the pidf-manipulation file on the XCAP server (only used for type 2).

- filename - the name of the pidf-manipulation file on the XCAP server (only used for type 2).

RPC Command Format:

    ...
    &kamctl; rpc presence.refreshWatchers sip:test@kamailio.org presence 1
    ...

### presence.updateWatchers

Manually triggers updates to watchers (for example, after the contents of XCAP docs has been updated).

Name: presence.updateWatchers

Parameters:

- uri - the uri of the user who made the changes and whose watchers should be updated.

- event - the event package (e.g. presence).

RPC Command Format:

    ...
    &kamctl; rpc presence.updateWatchers sip:alice@domain.com presence
    ...

### presence.presentity_list

List the presentity records stored in memory.

Name: presence.presentity_list

Parameters:

- mode - (optional) it can be 'full' to print all the fields of presentity record. If missing, only a selected set of fields are printed in the response.

RPC Command Format:

    ...
    kamctl rpc presence.presentity_list
    kamctl rpc presence.presentity_list full
    ...

### presence.presentity_show

Return the presentity records stored in memory by filtering with username and/or domain.

Name: presence.presentity_show

Parameters:

- mode - it can be 'basic' or 'full' to print a selection or all the fields of presentity record.

- user - username to match presentity records, use '*' to match any username.

- domain - the value to match the domain of the presentity records, use '*' to match any domain.

RPC Command Format:

    ...
    kamctl rpc presence.presentity_show basic alice sipserver.com
    kamctl rpc presence.presentity_show full * sipserver.com
    ...

### presence.watcher_list

Return the watcher records for a specific presentity uri.

Name: presence.watcher_list

Parameters:

- mode - it can be 'basic' or 'full' to print a selection or all the fields of watcher record.

- uri - the presentity uri.

RPC Command Format:

    ...
    kamctl rpc presence.watcher_list basic sip:alice@sipserver.com
    ...

## Exported Variables

### `$subs(attr)`

Access the attributes of handled subscription. It must be used after a successful call of handle_subscription() or in the following events.

- tm:local-request - before notify is sent

- presence:notify-reply - after notify is sent

The attr can be:

- uri - subscription presentity uri

- pres_uri - alias for presentity uri

- to_user

- to_domain

- from_user

- from_domain

- watcher_username

- watcher_domain

- event

- event_id

- to_tag

- from_tag

- callid

- remote_cseq

- local_cseq

- contact

- local_contact

- record_route

- expires

- status

- reason

- version

- flags

- user_agent

#### `$subs(name)` usage

    ...
    if(handle_subscription())
    {
      xlog("presentity=$subs(uri)\n");
    }
    ...

### `$notify_reply(attr)`

Access the reply message received when notifying subscriber. It must be used in the following events.

- presence:notify-reply - after notify is sent

The attr can be any pseudo var that accesses attributes of msg

#### `$notify_reply(name)` usage

    ...
    event_route[presence:notify-reply]
    {
      xlog("received message = $notify_reply($mb)\n");
    }
    ...

## Events

### `presence:notify-reply`

Fired after notify reply is received or timeout.

#### `$notify_reply(name)` usage

    ...
    event_route[presence:notify-reply]
    {
      xlog("received message = $notify_reply($mb)\n");
    }
    ...

## Installation

The module requires 3 tables in the &kamailio; database: "presentity", "active_watchers" and "watchers". The SQL syntax to create them can be found in presence-create.sql script in the database directories in the kamailio/scripts folder. You can also find the complete database documentation on the project webpage, &kamailiodbdocslink;.