Table of Contents
db_url(str)
xcap_table(str)
rlsubs_table(str)
rlpres_table(str)
clean_period (int)
waitn_time (int)
max_expires (int)
hash_size (int)
xcap_root (str)
integrated_xcap_server (int)
to_presence_code (int)
rls_event (str)
outbound_proxy (str)
server_address (str)
max_notify_body_length (int)
List of Examples
db_url parameterxcap_table parameterrlsubs_table parameterrlpres_table parameterclean_period parameterwaitn_time parametermax_expires parameterhash_size parameterhash_size parameterintegrated_xcap_server parameterto_presence_code parameterrls_event parameteroutbound_proxy parameterserver_address parametermax_notify_body_length parameterrls_handle_subscribe usagerls_handle_notify usagerls_update_subs usageTable of Contents
db_url(str)
xcap_table(str)
rlsubs_table(str)
rlpres_table(str)
clean_period (int)
waitn_time (int)
max_expires (int)
hash_size (int)
xcap_root (str)
integrated_xcap_server (int)
to_presence_code (int)
rls_event (str)
outbound_proxy (str)
server_address (str)
max_notify_body_length (int)
The modules is a Resource List Server implementation following the specification in RFC 4662 and RFC 4826.
The server is independent from local presence servers, retrieving presence information with Subscribe-Notify messages.
The module uses the presence module as a library, as it requires a resembling mechanism for handling Subscribe. Therefore, in case the local presence server is not collocated on the same machine with the RL server, the presence module should be loaded in a library mode only (see doc for presence module).
It handles subscription to lists in an event independent way.The default event is presence, but if some other events are to be handled by the server, they should be added using the module parameter "rls_events".
It works with XCAP server for storage. There is also the possibility to configure it to work in an integrated_xcap server mode, when it only queries database for the resource lists documents. This is useful in a small architecture when all the clients use an integrated server and there are no references to exterior documents in their lists.
The same as presence module, it has a caching mode with periodical update in database for subscribe information. The information retrieved with Notify messages is stored in database only.
The following modules must be loaded before this module:
a database module.
sl.
tm.
presence- in a library mode.
pua.
The database url.
Default value is “mysql://openser:openserrw@localhost/openser”.
Example 1.1. Set db_url parameter
...
modparam("rls", "db_url", "dbdriver://username:password@dbhost/dbname")
...
The name of the xcap table in which the integrated server or the xcap_client module writes. If integrated_xcap_server parameter not set, the name of the table must be the same as the one set for the xcap_client module.
Default value is “xcap”.
The name of the db table where resource lists subscription information is stored.
Default value is “rls_watchers”.
Example 1.3. Set rlsubs_table parameter
...
modparam("rls", "rlsubs_table", "rls_subscriptions")
...
The name of the db table where notified event specific information is stored.
Default value is “rls_presentity”.
The period at which to check for expired information.
Default value is “100”.
The timer period at which the server should attempt to send Notifies with the updated presence state of the subscribed list or watcher information.
Default value is “50”.
The maximum accepted expires for a subscription to a list.
Default value is “7200”.
The dimension of the hash table used to store subscription to a list. This parameter will be used as the power of 2 when computing table size.
Default value is “9 (512)”.
The address of the xcap server.
Default value is “NULL”.
Example 1.9. Set hash_size parameter
...
modparam("rls", "xcap_root", "http://192.168.2.132/xcap-root:800")
...
This parameter should be set if only integrated xcap servers are used to store resource lists.
Default value is “0”.
Example 1.10. Set integrated_xcap_server parameter
...
modparam("rls", "integrated_xcap_server", 1)
...
The code to be returned by rls_handle_subscribe function if the processed Subscribe is not a resource list Subscribe. This code can be used in an architecture with presence and rls servers collocated on the same machine, to call handle_subscribe on the message causing this code.
Default value is “0”.
The default event that RLS handles is presence. If some other events should also be handled by RLS they should be added using this parameter. It can be set more than once.
Default value is “"presence"”.
The SIP address where to send RLS subscriptions (outbound proxy address as SIP URI).
Default value is “NULL”.
Example 1.13. Set outbound_proxy parameter
...
modparam("rls", "outbound_proxy", "sip:presence.kamailio.org")
...
The address of the server that will be used as a contact in sent Subscribe requests and 200 OK replies for Subscribe requests for RLS. It is a mandatory parameter.
Example 1.14. Set server_address parameter
...
modparam("rls", "server_address", "sip:rls@ip.address.ofyour.proxy:5060")
...
This function detects if a Subscribe message should be handled by RLS. If not it replies with the configured to_presence_code. If it is, it extracts the dialog info and sends aggregate Notify requests with information for the list.
This function can be used from REQUEST_ROUTE.
Example 1.16. rls_handle_subscribe usage
...
For presence and rls on the same machine:
modparam("rls", "to_presence_code", 10)
if(is_method("SUBSCRIBE"))
{
$var(ret_code)= rls_handle_subscribe();
if($var(ret_code)== 10)
handle_subscribe();
t_release();
}
For rls only:
if(is_method("SUBSCRIBE"))
{
rls_handle_subscribe();
t_release();
}
...
This function can be used from REQUEST_ROUTE.
This function can be used in configuration to trigger updates to resource list subscriptions (for example, after the contents of a resource list has changes).
Parameters:
uri - the uri of the user who made the change and whose resource list subscriptions should be updated
event - the event package (e.g. presence).
This function can be used from ANY_ROUTE.
Example 1.18. rls_update_subs usage
...
Within event_route[xhttp:request]:
case "PUT":
xcaps_put("$var(uri)", "$var(doc_uri)", "$rb");
if($xcapuri(u=>auid)=~"pres-rules") {
pres_update_watchers("$var(uri)", "presence");
pres_refresh_watchers("$var(uri)", "presence", 1);
} else if ($xcapuri(u=>auid)=~"resource-lists"
|| $xcapuri(u=>auid)=~"rls-services") {
rls_update_subs("$var(uri)", "presence");
}
exit;
break;
...
The module requires 2 tables in Kamailio database: rls_presentity and rls_watchers.The SQL syntax to create them can be found in rls-create.sql script in the database directories in the kamailio/scripts folder. You can also find the complete database documentation on the project webpage, http://www.kamailio.org/docs/db-tables/kamailio-db-devel.html.