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.
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.
Sometimes people wonder why it takes so much time and effort to make the RCS working when LINE, Whatsapp, Viber, Skype, Lync and others just work and they are (nearly) for free. One of the reasons is the enormous amount of standards and specifications for SIP/IMS/RCS. Just take a look on RFC 4480 where we can find ridiculous definitions like:
Activities such as <appointment>, <breakfast>, <dinner>, <holiday>, <lunch>, <meal>, <meeting>, <performance>, <travel>, or <vacation> can often be derived from calendar information.
dinner: The person is having his or her main meal of the day, eaten in the evening or at midday.
holiday: This is a scheduled national or local holiday.
in-transit: The person is riding in a vehicle, such as a car, but not steering. The <place-type> element provides more specific information about the type of conveyance the person is using.
looking-for-work: The presentity is looking for (paid) work.
lunch: The person is eating his or her midday meal.
“RCS standardized itself to death” – I’m not sure who said it first but there is definitely something about it 🙂
We have already seen a bit of presence in the post Is the Presence Social? This time we’ll extend our framework with other nodes from OMA specification.
There are also some other network elements and interfaces but for now it is more than enough. Just think about it – we need all these servers and databases for a simple information whether is our friend present or not and maybe some tag line or avatar. No wonder that many OTTs use either very simple or proprietary presence solution. Even the RCS doesn’t rely on the full presence implementation and only SIP OPTIONS support is mandatory.