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).
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.
VoLTE Conference Flow
The conference creation is quite complex and we refer to it as a Three Way Session creation. In a nutshell ad-hoc conference means to add a user to an existing call. The steps are
- UE-1 is in a call with UE-2
- UE-1 decides to add UE-3 in the call. So it puts UE-2 on-hold and starts a new call with UE-3.
- UE-1 merges the two calls into a conference. To create a conference call UE-1 asks Conference AS (TAS) to create a new conference and Refers the existing calls to the conference.
- UEs can subscribe to a Conference package.
For simplicity we won’t talk about preconditions, early-media, SIP PRACK etc. Sure, you’ll find the related SIP messages in your pcap.
So let’s say that UE-1 and UE-2 are engaged in a call. At some point in time UE-1 decides to involve UE-3 into the communication and activate the 3PTY CONF service.
UE-1 puts UE-2 on hold, initiates a session towards UE-3 to get the user’s permission to start 3PTY call.
Then UE-1 creates the conference initiating a call to Conference Factory URI. Conference factory URI points to so-called focus – a central hub which handles all the conference signalling. In a standard deployment TAS equals focus.
So to create a conference means that TAS applying Originating services for UE-1 recognizes a pre-defined Conference Factory URI e.g. sip:email@example.com and triggers MRF.
MRF acts as a media mixer. It allocates the resources and provides its SDP. TAS then generates a conference specific identifier – conf-uri – which we can found in the Contact header of 200 OK response along with the isfocus tag and SDP of MRF.
When the CONF service is invoked, conference resources are allocated to the served user UE-1. Once a conference is active, users can join and leave a conference, and remote users can be added to or removed from the conference.
To add the other two users into the conference the UE-1 moves the original communication with both UE-2 and UE-3 to the conference server (TAS). To do that UE-1 does use a SIP REFER method (SIP REFER is generally used for call transfer scenarios).
Technically there are two options how to use SIP REFER. Either it can be send to a particular user or to the focus. In case of VoLTE the standard allows only the SIP REFER sent to the focus (TAS).
Upon generating a REFER request that is destined to the conference focus in order to invite a user to the conference, the participant has to:
- set the request URI to the conference URI to which the user is invited to (conf-uri);
- set the Refer-To header to the SIP URI or tel URL of the user who is invited to the conference; in our case UE-2 or UE-3
- either include the “method” URI parameter with the value “INVITE” or omit the “method” URI parameter in the Refer-To header; and
- use Replaces tag in Refer-to header to refer to the active dialog that is replaced by the ad-hoc conference.
The UE may additionally include the Refered-By header to the REFER request and set it to the URI of the conference participant that is sending the REFER request (UE-1).
Afterwards the UE-1 receives incoming NOTIFY requests which are related to the previously sent REFER request – event package refer.
Additionally the conference participants can also subscribe to the conference event package, as described in RFC 4575. The UE can and the IMS core network must support the conference event package. As a minimum, the IMS core network must support the following elements and attributes:
- Conference-info: entity
- User: entity
- Endpoint: entity
- Status (supported values: connected, disconnected, on-hold)
Note that the Floor control for conferencing is only optional. Also Consent procedures for list server distribution are not required.
Conference Factory URI
3GPP TS 24.166 provides a standard mechanism for the UE how to discover the Conference Factory URI to be used for the CONF service using the Management Object. The Management Object Identifier is: urn:oma:mo:ext-3gpp-conf:1.0 and the parameter is defined as /<X>/Conf_Factory_URI.
If the UE has not been configured with Conf_Factory_URI parameter, then it constructs the “Default Conference Factory URI for MMTel” as a SIP URI with a host portion set to the home network domain name prefixed with “conf-factory.” The user portion should be set to “mmtel“. Examples:
In general mobile operators can use various mechanisms to discover the Conference Factory URI. A derived Conference Factory URI might not be a valid URI.
Mind that as the Conference URI differs from other URIs, which we use for routing towards TAS, we shouldn’t forget to provision the related IFC.
When leaving a conference, the user generates a SIP BYE request on the dialog that was established when joining or creating the conference (dialog with focus).
The participant leaving the conference will also trigger the conference notification service to send a NOTIFY request with updated conference state information to all conference participants, including itself. (Therefore the participant does not immediately unsubscribe from the conference event package in order not to cause unnecessary traffic on the air interface.)
The conference can be also terminated by the focus or by the conference initiator (UE-1). To remove someone from the conference the initiator sends a SIP REFER request to the focus, where
- the request URI is set to conference URI (conf-uri) from which the conference participant is to be removed;
- the Refer-To header is set to the address of the conference participant who should be removed from the conference (e.g. UE-2), including the “method” parameter set to “BYE“
Note, that the removal of all conference participants from the conference will terminate the conference if the conference policy is set accordingly.
In practice I’ve seen many different implementations of the conference service. These implementations were using different SIP headers, even strange tags as “is-focus”, they differed in the way they were handling conference event package, how they communicated with MRF (or even with a CS media server!) or in rules how to terminate conference (e.g. what happens if the initiator leaves the conference). Last but not least, there can be some early media played, conference call can be also a subject to Access Transfer or we may need to think about online charging (what if the recipient is the charged party?). It’s a great thing we can do a conference call, but the price is sometimes high.