VoLTE and RCS support plenty of services – e.g. Call Forwarding, Call Barring or Presence. Some of these services can’t be pre-configured for the subscribers as each of them wants to provision his/her own forwarding/barred numbers or maybe doesn’t want to use the functionality at all. That means we need to have a way how to do a self-provisioning. In IMS we have a dedicated Ut interface and network functionalities which allow to modify the setting of Supplementary Services and Presence Information directly from client (UE) via http/XCAP protocol. For VoLTE this is defined in the GSMA IR.92 and 3GPP TS 24.623, TS 24.423 and 3GPP TS 33.222. GSMA IR.92 directly says:
For supplementary service configuration, the UE and IMS core network must support XCAP at the Ut reference point as defined in 3GPP TS 24.623.
Wow – this is very important! There is not only the SIP/RTP between UE and IMS network but there can be also http (xcap)! Unlike SIP, HTTP is designed as a general-purpose data transport protocol. The purpose of SIP is mainly to create, modify, or terminate multimedia sessions. But sometimes we want to work with other types of data (e.g. configuration data, presence data, ..) which could easily overwhelm intermediate SIP proxies. HTTP is a good choice how to solve this issue.
What is the network architecture then?
As we can see the http traffic does’t go through the SBC but through an Authentication Proxy (AP) instead. Its main purpose is to authenticate user requests. It is also used to separate the authentication procedure and the Application Server (AS) specific logic (e.g. Supplementary Service provisioning) to different network entities.
(In case of presence and OMA XDMS architecture we talk about so-called Aggregation Proxy, which is described in its own post.)