VoLTE Conference Call

Maybe you remember what I said about Group Messaging. That all the RCS deployments would be done faster without this feature. A similar thing we can say about VoLTE Conferencing. Ad-Hoc Multi Party Conference Call (CONF) is one of the basic requirements we have on VoLTE calling. Simply put each VoLTE network has to support conference calling. But to troubleshoot this great functionality can be a nightmare.

Ad-Hoc Multi Party Conference is one of the Supplementary Services supported by Telephony Application Server (TAS) (a dedicated Conference AS is an option too) and it is described in GSMA IR.92, which then refers to 3GPP TS 24.605 and 24.147. Today we’ll take a look at the conference call flow, along with the Mr’ interface between TAS and Media Resource Function (MRF).

Add participant button

Although we talk about conferencing, in fact it’s just a multi-party call. We don’t schedule any conference call for a given list of participants. We can only add additional numbers to an existing call. That’s why we describe the service as an ad-hoc conference. From the mobile operator point of view the conferencing service provides the means for a user to create, manage, terminate, join and leave conferences as well as the ability to update the involved parties. But most of the stuff is truly hidden to the end subscribers.

In general both voice and video conference can be supported, but only the support of audio media is required by VoLTE standard. The maximum number of participants differs network to network, usually it is between 6 and 10. Note, that the functionality is not limited to VoLTE users only, we can add to the call the CS users too.

Advertisement

Ut interface – what is it for?

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 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?

Ut Reference Point

As we can see the http traffic does’t go through the SBC but either directly or through an Authentication Proxy (AP) instead. The interface uses in cellular access the HOS APN (Home Operator Services) as defined in GSMA PRD IR.88 (in Wi-Fi either the HOS APN or a different APN as defined in of GSMA PRD IR.51). The usage of AP depends on the HOS APN (Home Operator Services) value. The Network Identifier (NI) part of the APN is undefined and must be set by the operator. The operators can choose to reuse an APN for already deployed services (e.g. Internet access, MMS, etc.) or choose a new, specific APN for the APN for Home Operator Services.

As the HOS APN is often using the standard Internet access, we’ll take a look at the flows with AP. The main purpose of AP 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.)

At your service..

VoLTE in GSMA IR.92 is defining a set of standard Supplementary Services:

• Originating Identification Presentation 3GPP TS 24.607
• Terminating Identification Presentation 3GPP TS 24.608
• Originating Identification Restriction 3GPP TS 24.607
• Terminating Identification Restriction 3GPP TS 24.608
• Communication Forwarding Unconditional 3GPP TS 24.604
• Communication Forwarding on not Logged in 3GPP TS 24.604
• Communication Forwarding on Busy 3GPP TS 24.604
• Communication Forwarding on not Reachable 3GPP TS 24.604
• Communication Forwarding on No Reply 3GPP TS 24.604
• Barring of All Incoming Calls 3GPP TS 24.611
• Barring of All Outgoing Calls 3GPP TS 24.611
• Barring of Outgoing International Calls 3GPP TS 24.611
• Barring of Outgoing International Calls – ex Home Country 3GPP TS 24.611
• Barring of Incoming Calls – When Roaming 3GPP TS 24.611
• Communication Hold 3GPP TS 24.610
• Message Waiting Indication 3GPP TS 24.606
• Communication Waiting 3GPP TS 24.615
• Ad-Hoc Multi Party Conference 3GPP TS 24.605
• Explicit Communication Transfer – Consultative 3GPP TS 24.629 (5G)

Update:

There is not much different in VoNR (5G), the same 3GPP documents are referred by GSMA NG.114. Explicit Communication Transfer is explicitly listed as one of the services. 

IR.92 also says that 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.

The supplementary services are applied on the traffic by application server (MMTel) based on the information received from HSS/CNTDB (Sh/LDAP). Note we distinguish the originating and terminating services (based on presence of the ‘orig’ tag in the top-most Route header). We also distinguish weather or not is the user currently registered in the LTE network (based on the ‘regstate’ tag in the P-Served-User). E.g. some services are applied for recipients (terminating service) who are not present in the LTE (regstate=unreg) – as voice mail. More details can be found in the 3GPP TS 24.229.

Route: <sip:mmtel@mmtel01.operator.com;lr;orig>,sip:1.2.3.44.50678.0.9000.@10.22.1.2:5070;lr;OdiPsi=mmtel>

P-Served-User: <sip:+123456789123@operator.com>;sescase=orig;regstate=reg

VoLTE Supplementary Services