Really call conferencing is not a feature that I am going to spend time on it to introduce to you or count its pros. We live in the web and cloud era and call/video conferencing, especially over WebRTC is mature enough. But again when you want to touch any feature like this in the 3GPP territory, might it be a little confusing. The idea is simple but it is a habit for some people that make the story complicated when they relate it.
So in this blog post, I wanna share some technical points that I learned from implementing this feature for our IMS core over AWS. Aha, I should mention also that IMS (VoLTE/VoNR) call conferencing is actually a 3-way call, which means you would be on a call with two other subscribers, NOT more. They call it Ad-Hoc Multi Party Conference, means subscriber creates conference room/call on the fly.
Some of useful resources around IMS call conf if you want to get more details:
Let me make it very simple for you. UE-A is in call with UE-B, then puts call on hold and calls UE-C; then seems they need to talk to UE-B together, so UE-A puts UE-C on hold and sends a request for creating a conference room. X-CSCF gets this new INVITE which its To header includes conference URI and forwards it to correct application server (TAS) to handle it. This is how call conferencing begins in IMS; like below call flow diagram:
Do not confuse by naming. TAS or Conference AS, focus or conference factory all are the same and it is actually the element that manages the conferencing creation, moving parties to it, and then removing it. Whatever you want, just name it :)
The INVITE RURI could be like this:
When AS accepts this request, it provides a media path via SIP 200 OK SDP. Note that AS might not handle media itself and works with another element as MRF (Media Resource Function). Actually, MRF mixes the media for the conference. When UE-A receives this OK and gets into the conference, it starts to ask AS to move UE-B and UE-C to the conference. For this purpose, UE-A uses SIP REFER message to address AS about call parties.
Ok, so you need to handle REFER correctly. the Refer-To header is the place including info that AS needs to know.
Refer-To: <sip:1XXX4292400;phone-context=ims.mncXXX.mccZZZ.3gppnetwork.org@ims.mncXXX.mccZZZ.3gppnetwork.org;user=phone;method=INVITE?Replaces=wooY93GbgDHgH7zV7xXS6g..%402001:56f:f800:117d:0:2a:002d:1c01%3Bto-tag%3D20132573814420238217146%3Bfrom-tag%3D43f1826a>
This header includes Call-ID, from-tag, and to-tag of the original calls. So UE-A sends separate REFER for each UE-B and UE-C.
But how UE-A understands that other parties have been moved to the conference? with SIP NOTIFY. UE-A subscribes itself to notifications for conference dialog and then TAS keeps it updated about the steps that it does.
First TAS says I am trying to move party to conference. So SIP NOTIFY has Sipfrag SDP with Trying state:
When UE moved to conf, TAS sends NOTIFY with OK 200 in the Sipfrag SDP:
At this point, all parties are in the conference, and from a signaling point of view, flow is normal to finish the call for all legs, except if the conference initiator (UE-A) wants to drop other parties from the conference, it sends another SIP REFER message that in Refer-To header it says that party’s URI with method BYE. If UE-A terminates the call, the whole conference call will be terminated.
Refer-To: <sip:1XXXY292400;phone-context=ims.mncXXX.mccZZZ.3gppnetwork.org@ims.mncXXX.mccZZZ.3gppnetwork.org;user=phone;method=BYE>
This was a simple overview of the IMS call conferencing feature. But if you want to implement it I have some hints here:
-
Handle REFER message correctly. This is the only message that carries information about other parties.
-
NOTIFY messages that you send to the conference initiator are implementation keys. When UE-A gets the correct
Sipfraginfo for UE-B, it sends a second REFER for UE-C, otherwise, UE-A sends a BYE and terminates the calls. -
TAS or conference AS is a simple B2BUA telephony server with media mixing capability. So a FreeSwitch or maybe Asterisk server can do the job for you. As we developed most of our services on AWS, using the FreeSwitch on ECS or EC2 instances was the first option. But later we decided to put the maintenance responsibility on AWS’s shoulder and moved our conferencing factory to AWS Chime. Although AWS Chime also is using the FreeSwitch, at least we don’t care about the maintenance and other server stuff.
More idea: https://docs.aws.amazon.com/chime-sdk/latest/dg/mtgs-sdk-cvc.html
- Wirehark is your only friend on this path, hug it :)
I will be really happy to help whoever wants to implement this feature or who is interested in getting more info about our IMS core. Just reach out to me with my contact info !