The year 2015 is definitely a year of VoLTE. VoLTE is everywhere and operators are rolling out as crazy. There are plenty of articles describing how the LTE or LTE-A do work. We’ll put the ePC part aside and take a look on the IMS flows.

We’ve already discussed VoLTE a bit in the VoLTE or RCS voice call post, so we know that the most important specifications are the GSMA IR.92 and IR.94 which are then referencing other documents. If you think it seriously with VoLTE, don’t waste your time on any blog and read the VoLTE Service Description and Implementation Guide. On the other hand for real beginners we have VoLTE Illustrated: Beginners Guide.

The very basic architecture of IMS for VoLTE can look like this:



Except the I/S-CSCF, which cares about authentication, session routing and management, we need an Application Server for voice and video telephony. This application server is called TAS – Telephony Application Server or MMTel AS – Multimedia Telephony AS. The application server is responsible for all the services which can be applied – as address normalization, call diverting, call forwarding, barring, etc. In a nutshell TAS is what makes the VoLTE enhancements on top of the pure VoIP.

Other IMS elements are:

MRF – Media Resource Function – can be used as a media mixer or as a media server for playing of tones and announcements.

MGCF – Media Gateway Control Function – is used for the breakout to and from CS network. Usually the MGCF and MGW – Media GW is a part of enhanced MSC.

BGCF – Breakout Gateway Control Function – might be used in case when S-CSCF is not able to find the routing based on ENUM/DNS (e.g. PSTN number). Usually it is a part of IMS Core (along with S-CSCF and I-CSCF).

The IMS definition is very broad and flexible. GSMA VoLTE standard restricts it and defines what services are mandatory and how we should implement them. E.g. it defines how to implement Emergency Services, SRVCC, Roaming, SMS interworking, etc. In our post we will go through the basic VoLTE to VoLTE callflow.


IMS Network

IMS Network for T1 Operators

In the introduction into IMS we said that S-CSCF is a heart of the IMS. The TAS (MMTel) is the brain. There are always at least two telephony application servers and two S-CSCFs involved on a path from originator to recipient. One which applies originating and one which applies terminating services. (Physically the O-TAS and T-TAS can be one server. The same applies for the other network elements.)

volte flow, volte call

VoLTE Call-Flow

What particular services will be applied is driven by the configuration of a TAS/MMTel and by subscriber and non-subscriber data which is stored in HSS.

Before a subscriber can place a receive any call, he has to register himself in the IMS network. We went through the registration in several posts (Registration, 3rd party registration, How to read tcpdump – Registration). Once the user is successfully registered, the S-CSCF is able to route the incoming calls to the user. This S-CSCF also knows which TAS did the 3rd party registration and maintains a binding between the IMPU (user) and the TAS. This information is a part of the user’s context.

When a user (Johan) wants to initiate a new call he sends a SIP INVITE message to the recipient (Rory). The basic flow looks like this:


VoLTE SIP signalling

VoLTE subscribers use SIP protocol in order to negotiate the parameters of a multimedia (RTP) session. The SIP signalling also allows the IMS network to secure sufficient resources for the requested Quality of Service.

In IMS the SIP INVITE message is firstly sent to P-CSCF which was assigned to the user during the registration. The P-CSCF has a binding with the S-CSCF which is responsible for the originator.

The S-CSCF routes the SIP INVITE to the O-TAS which applies originating services (e.g. Outgoing Call Barring, triggering of playing announcements, Conferencing, etc.) and can modify the recipient’s address (based on translation rules, ENUM response, CAMEL triggering, etc.) Remember that TAS acts as a B2BUA and can change any SIP header including the Call-ID.

From O-TAS the SIP INVITE is sent back to the S-CSCF of the originator. The S-CSCF finds a routing to the network of the recipient (e.g. with help of DNS or ENUM). In our case (recipient is registered in IMS) S-CSCF forwards the message to I-CSCF in the terminating network.

I-CSCF will locate the S-CSCF which handles the context for the recipient. S-CSCF triggers T-TAS for terminating services (e.g. Incoming Call Barring, Call Forwading, etc.)

Finally the T-TAS forwards the SIP INVITE to the S-CSCF of the recipient. The S-CSCF knows which P-CSCF maintains a dialog with the recipient.

When the recipient receives the SIP INVITE he will respond and the response backtracks all the way to the originator.

lte-lte flow

lte-lte flow


In order to establish the media path the body of the SIP INVITE and other signaling messages carries Session Description Protocol (SDP) data.

o=volte-0-349-1 0346136471fad35443 1660635443 IN IP4
i=A VoLTE Session
c=IN IP4
t=0 0
m=audio 23448 RTP/AVP 116 118 111 110 8 0
a=rtpmap:116 AMR-WB/16000
a=fmtp:116 mode-change-capability=2;max-red=220
a=rtpmap:118 AMR/8000
a=fmtp:118 mode-change-capability=2;max-red=220
a=rtpmap:111 telephone-event/16000
a=fmtp:111 0-15
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000

Via SDP the originator and recipient exchange IP addresses ( and ports (23448) for the media stream (RTP) and sets of supported codecs (AMR-WB, AMR, DTFM – telephone-event,..). There are many more parameters, for now it is important that once originator and recipient know the IP:Port and codecs to be used, they can start to communicate over the RTP protocol.

Later when one of the call parties wants to close the RTP stream (hang-up), the client sends a SIP BYE message. After the 200 OK response the session is finished.

Maybe you ask why is the signalling so complex? That is because the IMS is very general. E.g. in case of roaming this simple scenario can go across four different IMS networks:

volte roaming

VoLTE Call with Roaming

Although currently nearly no operators support IMS-based roaming and mostly they are not connected to any other IMS networks at all, still the network architecture can be quite complicated. Operators have multiple sites and there can be several different types of sites (E.g. Access site, Core IMS site, Maintenance Site, Failover Site, RCS Site, …)

volte network architecture

VoLTE architecture for multiple sites.

Now we know the very basic VoLTE-VoLTE flow. More detail flows are described in VoLTE flows – close encounters. SIP headers and routing is then explained in SIP Illustrated: SIP by sip. Basic VoLTE validation procedures are described at Validating VoLTE document.

Other posts related to VoLTE:


21 thoughts on “VoLTE in IMS

  1. Pingback: VoLTE or RCS Voice Call? | Real Time Communication

  2. Pingback: You are running low on credit! | Real Time Communication

  3. Pingback: A magic box called SBC – introduction | Real Time Communication

  4. Pingback: A magic box called SBC | Real Time Communication

  5. Pingback: RCS – Rich Communication Services | Real Time Communication

  6. Pingback: Mind the coverage hole! | Real Time Communication

  7. Pingback: VoLTE flows – close encounters | Real Time Communication

  8. Pingback: Much Ado about Registration | Real Time Communication

  9. Pingback: At your service.. | Real Time Communication

  10. Pingback: Summer & IMS | Real Time Communication

  11. Pingback: IP-SM-GW Transport Level Interworking | Real Time Communication

  12. Pingback: VoWifi Overview | Real Time Communication

  13. Pingback: WebRTC and IMS | Real Time Communication

  14. Pingback: VoLTE Illustrated: Beginners Guide | Real Time Communication

  15. Pingback: OTT and VoLTE Calls | Real Time Communication

  16. Pingback: News: Finally 4G? | Real Time Communication

  17. Pingback: GSMA Advanced Messaging – RCS Universal Profile | Real Time Communication

  18. Pingback: SIP Illustrated 4: SIP Session | Real Time Communication

  19. Pingback: SIP Illustrated 5: SIP Session Routing | Real Time Communication

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 )

Google+ photo

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

Connecting to %s