Best practices

Contents

Experience gained during interoperability tests and field deployments show that while SIP SIMPLE IETF related protocols are defined to be flexible they do not specify how they should be used in practice. XCAP is no exception. This section is meant to help people reuse experiences gained by others and save time with configuring properly the server and the clients.

General

  • Do not use plain IP addresses in any configurations, this includes XML documents or XCAP ROOT settings. Use only domain/hostnames and let the application do address resolution using DNS or other address resolution protocol designed for the application. Using IP addresses makes it difficult to migrate the server from one address to the other or move the documents from one server to another.
  • When using OpenSIPS, chose for the integrated version of XCAP client that reads the data directly from the database rather then doing HTTP requests to the XCAP server. The current design of OpenSIPS is blocking, which means that an incorrectly configured XCAP URL can lead to blockage of the child handling the SIP request. Also by choosing the non-integrated mode you are not able to synchronize the changes in the pres-rules document with the NOTIFY sending towards the qualified watchers. This means that whenever a presentity changes its policy about a given watcher, the NOTIFY will be sent out only when the next SUBSCRIBE arrives to the server.
  • An XCAP client must use sip:user@domain to identify the subscriber. By assuming that only the username part is required makes it impossible for such client to operate in a multi-domain environment.
  • An XCAP client must include a User-Agent header in its XCAP requests, it helps troubleshooting and finding the request in the server logs is easier.
  • A SIP client that SUBSCRIBEs to a rls services document must add a 'Supported: eventlist' header.
  • An XCAP client must use TLS to connect to an XCAP server.
  • An XCAP client must use digest algorithm to authenticate to an XCAP server.

RLS services checks

As XCAP rls documents are expanded by the Presence agent is important to prevent end users provision unsafe data in the Presence server. This is to avoid pointing the server to external documents that might open the door for indirect Denial of Service attacks (the proxy will do an HTTP request for every SUBSCRIBE message). An OpenXCAP server configuration option called 'check_rls_documents' should enable sanity checks for the content of RLS documents based as following rules:

If a <resource-list> element exists:

http://xcap.example.com/xcap-root/resource-lists/users/sip:username@domain/index/-/resource-lists/list[@name="id"]

  • The XCAP root part of a resource list element must match the XCAP root used to access this rls-services document
  • If <resource-list> points to a resource list with name=id, a resource list with this id must exist on the server
  • The SIP URI in the resource list URL must be the same with the username used for accessing the rls services document
  • The Presence Agent must combine the individual sip uri entries with the the list expanded from <resource-list> elements
  • XCAP Server must check if in the expanded list of SIP URIs there is no pointer to the lists itself or other RLS lists on the server
  • If the Presence agent reads data directly from a database (like OpenSIPS does) it should not use HTTP get to fetch the document as the database is common for both rls-services and resource list documents are hosted on the same physical server

Preventing Loops

When using RLS is very easy to create loops. As a list expands into discrete URIs, is easy to add an URI that points to the original list URI. This situation is imposible to detect when involving separate servers from different domains as all original subscription dialog information is lost during RLS translation. So signaling-wise is not possible to know that a Subscribe has been generated as a result of another Subscribe that hit an RLS.

There is a very simply way to prevent against this by simply not allowing subscribers from outside domains hosted on the RLS platform to subscribe to RLS services provisioned by local users. If only local users can subscribe to their own buddy lists (which is sane and safe policy) it is imposible to create loops as long as the XCAP server checks the integrity of the RLS list content.

Multiple realms on the same server

If you run an OpenXCAP server for multiple domains you must inform the server under which domain you want to be authenticated otherwise the authentication will be performed under the default realm defined in the server configuration. The IETF has specified a special host name for the XCAP server (xcap.example.com) in order to detect the domain name. In the real-world, for a multi domain environment it is likely that the same server using the same hostname will serve XCAP documents for subscribers under multiple domains. Following the IETF recommendation, when using TLS one should purchase certificates for each domain it serves and should have in DNS for each domain it hosts an A record for the XCAP server address, which is not efficient.

We have solved this problem in the following way:

If the client is using user@domain notation in the XCAP URLs, OpenXCAP it will work out of the box. We have noticed however that this functionality is not always available in today's clients. To fix the problem so that the server works for for any client you must indicate in the client xcap-root url URL the domain your belong to as follows:

https://xcap.example.com/xcap-root@example.com/