VoLTE or RCS Voice Call?

Update: The information in this post became obsolete over the time. Recently we’ve got RCS Universal Profile standard, which defines Green Button Promise for Voice and Green Button Promise for IP Video Call Services and Enriched Voice Calling. I’m working on an updated material, which will compare RCS IP Calls and VoLTE/VoWifi calling and describe RCS Network Architecture.


It is similar with many OTT applications for calls and massaging. Which one is the right or at least decent one? The big advantage is that usually we can try it for free.  Anyway what is the difference between a voice call performed as VoLTE (or VoWiFi) and voice call which is transmitted via RCS?

The 4G networks were originally designed for pure data traffic. But the voice service is a must have feature and right now it can’t be fully replaced by VoIP. The voice service has to be reliable and fully compatible with the service from 3G (Blacklisting, Call diverting, Lawful intercept, Emergency calls, DTFM, etc.) and has to allow seamless fallback in case the 4G coverage is lost (eSRVCC). This new service is called VoLTE.


VoLTE is a very young technology. It was announced in the beginning of 2010 by  GSMA. The aim was to create a standard way of delivering voice and messaging services for Long-Term Evolution (LTE).  Using IMS specifications developed by 3GPP as its basis, GSMA have expanded upon the original scope of One Voice work to address the entire end-to-end voice and SMS ecosystem by also focusing on Roaming and Interconnect interfaces. This is comprised of three sets of interfaces

  • The User Network interface (UNI) between the user’s equipment and the operators network.
  • The Roaming Network Network Interface (R-NNI) between the Home and Visited Network.
  • The Interconnect Network Network Interface (I-NNI) between the networks of the two parties making a call.

The work of GSMA VoLTE will also encompass

  • the continuity of Voice calls when a customer moves from LTE coverage to an area where LTE coverage is not available, achieved through Single Radio Voice Call Continuity (SRVCC).
  • Optimal Routing of bearers for Voice calls when customers are Roaming.
  • Capabilities associated with the model of Roaming Hubbing.
  • Security and fraud threat audit.

The basic VoLTE standard is described in FCM.01 – VoLTE Service Description and Implementation Guide and GSMA IR.92.

The RCS service and relation to VoLTE/ViLTE is described in the North America RCS Common Implementation Guidelines and also in the Enriched Calling Technical Specification.  Please check these documents as some information in this post is maybe already outdated.

Last but not least the GSMA specifies IMS Profile for Converged IP Communications in NG.102.

The most important IMS network elements are Telephony Application Server (TAS), Breakout Gateway Control function (BGCF), Media Resource Function (MRF), Media Gateway Control Function (MGCF) and Media Gateway (MGW).




The TAS is an IMS Application Server providing support for a minimum set of mandatory MultiMedia Telephony (MMTel) services as defined by 3GPP e.g. supplementary service functionality, and profiled within GSMA IR.92.


The BGCF is responsible for determining the next hop for routing of SIP messages. This determination may be based on information received within the SIP/SDP, internal configuration, and/or ENUM/DNS lookup. For CS Domain terminations, the BGCF determines the network in which CS domain breakout is to occur and selects the appropriate MGCF. For terminations in peer IMS networks, the BGCF selects the appropriate IBCF to handle the interconnect to the peer IMS domain.


The MRF is a common media resource function, for use by IMS Application Servers and I/S-CSCFs, to provide media plane processing independent of application types, e.g. transcoding, multiparty conferencing, network announcements/tones,  etc. under the control of TAS as well as basic media processing functions to CSCFs. The media plane interfaces to MRFs are defined by 3GPP reference Mb for RTP/RTCP transport.

ALG/AGW (IMS Application Level Gateway/IMS Access Gateway)

The IMS-ALG/IMS-AGW is responsible for the control/media plane at the access point to the IMS network.  It provides functions for Gate Control & Local NAT, IP realm indication and availability, Remote NAT traversal support, Traffic Policing, QoS Packet Marking, IMS Media Plane Security, etc.  The IMS-ALG/IMS-AGW may be implemented in an Access Session Border Controller which may also incorporate the P-CSCF.


The MGCF/MGW is responsible for the control/media plane interworking at the network interconnect point to circuit-switched networks. This includes interworking to CS Networks based on BICC/ISUP/SIP-I and may include transcoding of the media plane.

That was an overview of VoLTE very basic architecture (we’re focused on IMS only). The call flow is what we expect in IMS – SIP Invite sent via TAS for signalling and RTP via SBC for media. And it is more or less the stuff with which operators have in their networks right now (end of 2014).

However there are just a very few RCS trials now. So what is the difference? RCS defines  several types of voice and video calls:

IP Voice Call (IR.92)
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel
Media capabilities: audio, duplex
Contact address type: tel / SIP URI
IP Video Call (IR.94)
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel
Media capabilities: audio, video, duplex
Contact address type: tel/ SIP URI

RCS IP Voice Call (strong preference for no breakout (IP end to end))
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel.gsma.ipcall
Media capabilities: audio, duplex
Contact address type: tel / SIP URI
RCS IP Video Call (strong preference for no breakout (IP end to end))
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel.gsma.ipcall
Version: 1.0
Media capabilities: audio, video, duplex
Contact address type: tel/ SIP URI
RCS IP Video Call (strong preference for no breakout (IP end to end) and video media cannot be dropped)
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel.gsma.ipcall.ipvideocallonly
Media capabilities: audio, video, duplex
Contact address type: tel/ SIP URI

NOTE: RCS IP Calls and IP Calls per IR.92/IR.94 can technically interoperate. Whether such interoperability is provided is based on Service Provider decision. In those cases the Service Provider should ensure that all relevant capabilities are provided in the capability exchange (e.g. if IP Voice Call (as per MMTEL) capability is provided, the RCS IP Voice Call capability should be provided also).

What it means? It means that the voice service defined for VoLTE (IR.92) is a subset of (greedy!) RCS. Although sometimes the RCS based voice calls are presented as something completely else which has nothing to do with traditional voice service, the standard says otherwise. On the other hand standard is not producing any code and the trials mostly implement the RCS IP Video Call as a separate service which doesn’t reuse the existing TAS/MMTEL. Hence at least for some transition period we can’t expect all the features which are supported by VoLTE already.

One of the reasons is the amount RCS clients. Not all clients are compatible with a particular RCS deployment. There can be also a need to combine a native handset client and RCS specific client. The standard is partially aware of initial difficulties and defines modes of devices for the telephony service:

RCS-VoLTE mode: A device in RCS-VoLTE mode uses VoLTE to provide the telephony service. When a device capable of VoLTE uses CS to provide telephony service it is in RCS-CS mode (see below). RCS IP Voice/Video Calls are not allowed for devices in RCS-VoLTE mode.

RCS-VoHSPA mode: A device in RCS-VoHSPA mode uses VoHSPA to provide the telephony service. When a device capable of VoHSPA uses CS to provide telephony service it is in RCS-CS mode (see below). RCS IP Voice/Video Calls are not allowed for devices in RCS-VoHSPA mode;

RCS-AA mode: The mode of operation of an access agnostic RCS device using RCS IP Voice/Video Call that cannot provide 3GPP/3GPP2 calls (e.g. a PC notebook with an LTE stick or broadband access network connection, or a tablet);

RCS-CS mode: The mode of operation of a device using CS voice as the telephony service (e.g. a 2G/3G/HSPA smart phone without VoHSPA support attached to the CS network for telephony, a CSFB attached RCS smart phone in LTE, and RCS smart phone with CS and Wi-Fi connectivity). RCS IP Voice/Video Calls are possible if available. NOTE: If during a transition period a device provides both RCS and VoLTE clients as completely separate implementations, the RCS client shall behave as a non-embedded client and shall consider the device to be in RCS-CS mode whenever in cellular coverage.

To sum this up, technically the RCS is covering also the VoLTE.

More details about VoLTE can be found in VoLTE in IMS post.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s