XCAP Protocol

The more protocols you know, the more of the IMS you are. Right, the IMS is not only about SIP, Diameter or RTP. There are many various protocols involved. This time we’ll take a look at self-provisioning and configuration of services via http, more specifically XML Configuration Access Protocol (XCAP). We have seen it already in the posts about Ut Interface and Aggregation Gateway.

XCAP protocol is a kind of RESTful protocol. If you know a bit about the RESTfull approach, then you should easily become familiar with XCAP.

However the XCAP was created separately and has its own specifics. It was designed as a dedicated protocol for telecommunication environment as a set of conventions for mapping XML documents and document components into HTTP URIs, along with operations allowing to read/write/modify/delete these documents. That means it is not a general purpose XML search protocol. Still the XCAP is meant to support the configuration needs for a multiple applications such as supplementary services, capabilities, resource lists, presence rules and others.

Let’s take as an example the management of VoLTE supplementary services. XCAP allows an user to retrieve the information about the provisioned services and manage the content.

 

XCAP

 

As we want to limit the amount of the exchanged data, XCAP allows to define the scope of the document we are working with. The scope can be the whole document, or an xml element or even only an attribute.

 

From the practical point of view we need mainly to understand the way how we create the URL for a particular xml document.

URL of a simservs document (document for the supplementary services) can look like this:

/simservs.ngn.etsi.org/users/sip:+123456789012@ims.mnc000.mcc000.3gppnetwork.org/simservs.xml/~~/simservs/communication-diversion/cp:ruleset/cp:rule%5B@id=%22cfu%22%5D?xmlns(cp=urn:ietf:params:xml:ns:common-policy)

The first element is referencing the application by Application Unique ID (AUID). The name uniquely identifies the application usage. In our example the auid is

 /simservs.ngn.etsi.org

and it is given by IETF tree. The application usages are documented in specifications. In particular, an application usage specification must provide the following information:

• AUID: If the application usage is meant for general use on the Internet, the application usage must register the AUID into the IETF tree using the IANA procedures.
• XML Schema
• Default Document Namespace
• MIME Type
• Validation Constraint
• Data Semantics
• Naming Conventions
• Resource Interdependencies
• Authorization Policies

(List of all the auids supported for RCS can be found at http://technical.openmobilealliance.org/Technical/technical-information/omna/omna-xcap-auid-registry.)

 

Then we can select if we want to retrieve global information (global) or for a particular user only (users).

users/sip:+123456789012@ims.mnc000.mcc000.3gppnetwork.org

XDMS and TAS typically use the X-XCAP-Asserted-Indentity or x-3gpp-asserted-identity in order to find out if the user is allowed to work with the document. The header is inserted by Authentication/Aggregation Proxy as described in previous posts.

The document we want to work with is the

simservs

for the management of supplementary services.

As we don’t want to work with the whole document, we  can select an element

 communication-diversion/cp:ruleset

And within the element we can select an attribute

 cp:rule%5B@id=%22cfu%22%5D

If the UE will send HTTP GET request to the url from our example the 200 OK will contain an XML body which can look like

<cp:rule id="cfu">
  <cp:conditions>
  </cp:conditions>
  <cp:actions>
    <forward-to>
       <target>sip:+123456789013@ims.mnc000.mcc000.eps.3gppnetwork.org;user=phone</target>
    </forward-to>
  </cp:actions>
</cp:rule>

If we’d change the url to

/simservs.ngn.etsi.org/users/sip:+123456789012@ims.mnc000.mcc000.3gppnetwork.org/simservs.xml/~~/simservs/communication-diversion/

we’d get a document with all the configured communication-diversion services

<communication-diversion active="true">
  <NoReplyTimer>30</NoReplyTimer>
  <cp:ruleset><cp:rule id="cfu">
    <cp:conditions><rule-deactivated/>
    </cp:conditions>
    <cp:actions></cp:actions>
  </cp:rule>
  <cp:rule id="cfb">
     <cp:conditions><rule-deactivated/><busy/></cp:conditions>
     <cp:actions><forward-to><target>tel:+123456789013</target></forward-to>
     </cp:actions>
  </cp:rule>
  <cp:rule id="cfnr">
...
</communication-diversion>

For the

/simservs.ngn.etsi.org/users/sip:+123456789012@ims.mnc000.mcc000.3gppnetwork.org/simservs.xml/~~/simservs/

we’d get the whole simservs document.

 

In case of presence and XMDS we would just use a different auid and document:

GET /xdms/pidf-manipulation/users/sip:123456789012@ims.mnc000.mcc000.3gppnetwork.org/hardstate HTTP/1.1

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" entity="sip:123456789012@ims.mnc000.mcc000.3gppnetwork.org" xmlns="urn:ietf:params:xml:ns:pidf">
 <person id="that-guy" xmlns="urn:ietf:params:xml:ns:pidf:data-model">
    <status-icon xmlns="urn:ietf:params:xml:ns:pidf:rpid">      http://cs01.operator.com:1023/xdms/org.openmobilealliance.pres-content/users/sip:123456789012@ims.mnc000.mcc000.3gppnetwork.org/iconimage&amp;ts=124356
    </status-icon>
    <note xmlns="urn:ietf:params:xml:ns:pidf:rpid">Some information</note>
 </person>
</presence>

or

PUT /xdms/org.openmobilealliance.pres-rules/users/sip:123456789012@ims.mnc000.mcc000.3gppnetwork.org/pres-rules

<?xml version="1.0" encoding="UTF-8"?>
<cr:ruleset xmlns="urn:ietf:params:xml:ns:common-policy" xmlns:cr="urn:ietf:params:xml:ns:common-policy" xmlns:op="urn:oma:xml:prs:pres-rules" xmlns:pr="urn:ietf:params:xml:ns:pres-rules">
 <cr:rule id="1234">
    <cr:conditions>
 <op:external-list xmlns:op="urn:oma:xml:prs:pres-rules">
 <op:entry anc="http://10.10.11.206:7077/xdms/resource-lists/users/123456789012@ims.mnc000.mcc000.3gppnetwork.org/phbk/~~/resource-lists/list%5b@name=%22rcs-list%22%5d"/>
 </op:external-list>
 </cr:conditions>
 <cr:actions>
 <pr:sub-handling xmlns:pr="urn:ietf:params:xml:ns:pres-rules">allow</pr:sub-handling>
 </cr:actions>
 <cr:transformations>
 <pr:provide-services xmlns:pr="urn:ietf:params:xml:ns:pres-rules">
 <pr:all-services/>
 </pr:provide-services>
 <pr:provide-devices xmlns:pr="urn:ietf:params:xml:ns:pres-rules">
 <pr:all-devices/>
 </pr:provide-devices>
 ...

With just a little practice we can start with the troubleshooting of the Ut interface. XCAP is very straight-forward and we shouldn’t get lost. For the details refer the IETF RFCs 4825, 4826, 4827, and 5025.