Chapter 18
Service Configuration in the IMS
Chapter 17 provided a description of the protocols at the user’s disposal for configuring
services on the Internet. We saw that the service configuration architecture assumes an XML
document stored on a server. The client retrieves a copy of the XML document, makes
changes to it, and sends the delta back to the server.
In IMS, the architecture for service configuration architecture is developed around the
XML Document Management (XDM) architecture created by the Open Mobile Alliance
(OMA) in the XDM [244] set of specifications. XDM allows a user to modify XML
documents stored in remote network servers. It also allows the local copy of those XML
documents in the IMS terminal to be synchronized with the copy stored in network servers,
so that if the user makes changes to one XML document from a given IMS terminal, other
terminals are updated with the latest changes. Last, the XDM architecture also provides
limited support for searches of information stored in these XML documents.
18.1 XDM architecture
Let us describe the XDM architecture with the help of Figure 18.1. The XDM architecture
assumes a terminal that implements the role of an XCAP client, and one or more servers,
called XDM servers, that implement the role of XCAP servers. XML documents are stored
in any of the servers and kept synchronized with the copy in the client. When a user wants to
change a configuration setting in a service, such as adding a friend to a presence list, the user
changes the local copy of the XML document in the client and sends the change to the server,
which applies it, and stores an updated version of the XML configuration document.
The XDM architecture introduces the following concepts.
XDM client (XDMC). This is an XCAP client running in the IMS terminal. The XDMC
implements the core XDM features and some application-specific features.
Aggregation proxy. This is an HTTP proxy that is configured as an HTTP reverse proxy.
The Aggregation Proxy authenticates the XDMC towards an XDMS. It may also route
XCAP requests towards an XDMS or towards an Aggregation Proxy located in remote
network. It also routes search requests towards the Search proxy. When receiving
responses, it can compress the body of the response.
´ıa- M ar t´ın
The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition
Gonzalo Camarillo and Miguel A. Garc
© 2008 John Wiley & Sons, Ltd. ISBN: 978- 0- 470- 51662- 1
390
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS
Figure 18.1: XDM architecture
Search proxy. This is an HTTP proxy that processes search requests received from XDMCs
towards XDMSs or remote Aggregation Proxies. On received responses, the Search
proxy combines the results of the responses received from XDMSs and remote
Aggregation Proxies before forwarding them to the XDMC.
Shared XDM servers. XDM servers (XMDSs) that are used by several applications. Shared
XDMSs are effectively XCAP servers. There are specialized shared XDMSs: shared
list XDMS, shared group XDMS, shared profile XDMS, and shared policy XDMS.
XDMSs. This is an application-specific server for service configuration purposes. Effec-
tively, XDMSs are XCAP servers that serve a single application.
Most of the interfaces of the XDM architecture are implemented with XCAP. This is the
case of the interfaces XDM-3,XDM-4,XDM-8. However, interfaces XDM-1 and XDM-2 are
used for subscription to changes in XML documents, based on the XCAP event package for
SIP. Consequently, XDM-1 and XDM-2 are SIP interfaces. Interfaces XDM-5,XDM-6,XDM-
7,andXDM-9 implement the Limited XQuery over HTTP protocol. Unnamed interfaces in
Figure 18.1 are defined by their respective applications, but they typically consist of XCAP,
SIP for subscriptions to XCAP event packages, and Limited XQuery over HTTP.
The XDM architecture considers different applications that can be customers of the XDM
service (or enabler, as it is called by the OMA). For example, the presence service is a
customer of XDM, because the list of watchers, the authorization policies, etc., are all stored
in XML documents managed by XDM. Other services that use XDM include Push-to-talk
18.2. DOWNLOADING AN XML DOCUMENT, ATTRIBUTE, OR ELEMENT
391
over Cellular and PSTN/ISDN simulation services. Owing to this diversity of customers of
XDM, the XDM architecture considers the existence of different XDM servers, each one
perhaps specialized in serving a given application. An XDMS is a logical representation of
the service configuration aspects of a service or application. In real products, it is expected
that XDM servers are integrated into the specific server (e.g., presence server, PoC server,
etc.).
Similarly, XDMCs are not really new entities, but just the logical representation of an
XDM client in an IMS terminal.
18.2 Downloading an XML Document, Attribute, or Element
When an XDMC wants to receive an XML document, or a part of it, e.g., an attribute
or element, it invokes the HTTP GET request in XCAP. The basic HTTP GET operation
according to the XDM architecture is shown with the help of Figure 18.2. The XDMC
sends an HTTP GET request (1) to the Aggregation Proxy. It is assumed that the address
of the Aggregation Proxy is pre-provisioned in the IMS terminal. An example of this
HTTP GET request (1) is shown in Figure 18.3. The Request-URI is set to the part of the
XCAP URI that is identified in HTTP, thus, excluding the host name. Of relevance in the
HTTP GET request is the inclusion of an X-3GPP-Intended-Identity header field that
is populated with the identity that the user wants to present to the Aggregation Proxy. The
HTTP X-3GPP-Intended-Identity header field is specified in 3GPP TS 24.109 [9] and
contains a SIP Public User Identity of the user. This Public User Identity is also present as a
username in the XCAP URI of the GET request.
Figure 18.2: XDM: basic GET operation
GET /resource-lists/users/sip:alice@home1.com/index HTTP/1.1
Host: xdm.home1.com
User-Agent: XDM-client/OMA2.0
Date: Thu, 04 Mar 2008 22:10:45 GMT
X-3GPP-Intended-Identity: "sip:alice@home1.com"
Accept-Encoding: gzip
Figure 18.3: HTTP GET request (1)
392
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS
The Aggregation Proxy first needs to authenticate the user. There are several approaches
to authenticate a user. One of them consist of using the Generic Authentication Architecture
(GAA, specified in 3GPP TS 33.222 [15]). Essentially, GAA uses HTTP over TLS (specified
in RFC 4346 [121]), for security purposes, and then either a certificate in the client or a share
password. So, if GAA is used, all of the authentication takes place at the TLS level and not
at the HTTP level.
However, Figure 18.2 shows another authentication mechanism based on HTTP Digest
Authentication (specified in RFC 2617 [145]). The Aggregation Proxy receives an HTTP
GET request (1) and issues a 401 (Unauthorized) response (2) that contains a challenge in the
WWW-Authenticate header field. As a minimum, the challenge contains the realm where the
user will be authenticated, and a nonce, which is a random value that prevents against replay
attacks. An example of this 401 (Unauthorized) response is shown in Figure 18.4.
HTTP/1.1 401 Unauthorized
Server: XDM-proxy/OMA2.0
Date: Thu, 04 Mar 2008 22:10:46 GMT
WWW-Authenticate: Digest realm="home1.com", qop=auth-int,
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093"
Content-Length: 0
Figure 18.4: HTTP 401 (Unauthorized) response (2)
The IMS terminal receives the 401 (Unauthorized) response (2), extracts the challenge,
computes the response to that challenge (considering the username, realm, password, and
nonce), and generates a second HTTP GET request (3) that contains that response to the
challenge in the Authorization header field. An example of this HTTP GET request (3) is
shown in Figure 18.5.
GET /resource-lists/users/sip:alice@home1.com/index HTTP/1.1
Host: xdm.home1.com
User-Agent: XDM-client/OMA2.0
Date: Thu, 04 Mar 2008 22:10:49 GMT
X-3GPP-Intended-Identity: "sip:alice@home1.com"
Authorization: Digest realm="home1.com", qop=auth-int,
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
username="sip:alice@home1.com", nc=00000001,
uri="/resource-lists/users/sip:alice@home1.com/index",
response="2c8ee200cec7f6e966c932a9242554e4",
cnonce="3bb96fe6e98a02ccb4555609c1b1bb56"
Figure 18.5: HTTP GET request (3)
The Aggregation Proxy, upon receiving of this new HTTP GET request (3) that
contains the credentials, first evaluates the response to the presented challenge and computes
if it matches the response provided by the XDMC. If the response to the challenge
is correct, then it removes the Authorization header field and continues processing
the request. The Aggregation Proxy adds its own Via header field, and preserves the
X-3GPP-Intended-Identity header field. Then it inspects the Request-URI, determines,
18.3. DIRECTORY RETRIEVAL
393
based on the Application Unique ID (AUID), the actual server that is responsible for serving
the request, and forwards the HTTP GET request (4) to that server. In the example, the AUID
is set to resource-list; the Shared List XDMS is responsible for that application, thus is
the recipient of the HTTP GET request (4). An example of the forwarded request is shown in
Figure 18.6.
GET /resource-lists/users/sip:alice@home1.com/index HTTP/1.1
Host: xdm.home1.com
Via: HTTP/1.1 proxy.home1.com
User-Agent: XDM-client/OMA2.0
Date: Thu, 04 Mar 2008 22:10:50 GMT
X-3GPP-Intended-Identity: "sip:alice@home1.com"
Figure 18.6: HTTP GET request (4)
The Shared List XDMS then provides the requested XML document, element, or attribute
in a 200 (OK) response (5), and forwards the response back to the Aggregation Proxy. An
example of this response is shown in Figure 18.7.
HTTP/1.1 200 OK
Server: XDM-serv/OMA2.0
Date: Thu, 04 Mar 2008 22:10:50 GMT
Etag: "asd92d092"
Content-Type: application/resource-lists+xml
Content-Length: 238
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list name="family">
<entry uri="sip:daddy.joe@home1.com"/>
<entry uri="sip:mom.berta@home1.com/>
</list>
</resource-lists>
Figure 18.7: 200 (OK) response (5)
The Aggregation Proxy then compresses the body of the 200 (OK) response, i.e., the
XML document, according to any of the supported algorithms specified by the XDMC in the
HTTP GET request (3). It also adds an Authentication-Info header field that contains the
next nonce that the XDMC can use in a future HTTP request (so, future requests can directly
include the response to a challenge and avoid one round trip). Then it forwards it back to the
XDMC. An example of this response is shown in Figure 18.8.
18.3 Directory Retrieval
Sometimes users may need to retrieve all of their XML configuration documents that pertain
to one or more application usages. This might be the case, for example, if the user is
configuring a new IMS terminal. The XDM architecture offers a mechanism to do perform