A.2 Call flow for 3PTY CONF

24.6053GPPConference (CONF) using IP Multimedia (IM) Core Network (CN) subsystemProtocol specificationRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

A.2.1 Invite other user to 3PTY CONF by sending REFER request

Figure A.2 depictures a flow where two UEs, 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 toward UE-3 to get the user’s permission to start 3PTY call, creates the conference, and moves the original communication with both UE-2 and UE-3 to the conference server.

Figure A.2: Call flow for 3PTY conference

UE-1 and UE-2 are in an active call. UE-1 decides to add UE-3 to make it a 3-way conferencing call.

1. UE-1 and UE-2 are in an active call.

2. UE-1 puts UE-2 on hold before invoking the 3-Way Calling with UE-3.

3~11. UE-1 establishes a call with UE-3 following normal call setup procedure and gets UE-3’s permission to start the 3-Way Calling.

12~14. UE-1 sends an INVITE request to the conference server to establish a conference session.

15. The CS coordinates with MRFP to allocate conference resources.

16~21. The CS sends a 200 (OK) response and receives an ACK request from UE-1.

22~27. UE-1 sends a REFER request to UE-2 with the Refer-To header set to the address of the CS; UE-2 accepts the REFER request.

28~33. UE-2 sends a NOTIFY request to UE-1 to indicate that UE-2 is acting on the REFER request.

34~35. UE-2 sends an INVITE request to the CS to join the conference.

36. The CS coordinates with MRFP to allocate more resources.

37~40. The CS sends a 200 (OK) response to UE-2 and receives an ACK request.

41~46. UE-2 sends a NOTIFY request to UE-1 to indicate that it has finished action required by the REFER request.

47~52. UE-1 sends a BYE request to terminate the call between itself and UE-2.

53~58. In parallel to step 22~52, UE-1 sends a REFER request to UE-3 with the Refer-To header set to the address of the CS; UE-3 accepts the REFER request.

59~64. UE-3 sends a NOTIFY request to UE-1 to indicate that UE-3 is acting on the REFER request.

65~66. UE-3 sends an INVITE request to the CS to join the conference.

67. The CS coordinates with MRFP to allocate more resources.

68~71. The CS sends a 200 (OK) response to UE-3 and receives an ACK request.

72~77. UE-3 sends a NOTIFY request to UE-1 to indicate that it has finished action required by the REFER request.

78~83. UE-1 sends a BYE request to terminate the call between itself and UE-3.

A.2.2 Invite other user to 3PTY CONF by sending INVITE request with URI list

Figure A.3 depictures a flow where UA-A is involved in 2 communications with UA-B and UA-C, both 2 communications are on-hold. The AS is involved in both 2 communications as a B2BUA.

When user A intends to start the 3PTY conference, UA-A sends an INVITE request to the AS to create the conference and indicates that certain dialogs will be re-used for this conference, The AS sends re-INVITEs in the indicated dialogs and connects the media to the conference bridge. The dialogs can be indicated by adding the Call-ID header field, the From header field and the To header field to the entries in the URI list of the initial INVITE request.

Figure A.3: Call flow for 3PTY conference

1: Both dialogs are in the held condition. This assumes that the AS has the correct interactions between the services call HOLD and CONF i.e. when the conference is finished the origin dialogs 1c and 2c with Session-ID 1 and Session-ID 2 will be resumed. This is needed to allow resuming the held dialogs.

2: UA-A creates a conference and invites user B and user C to the conference by sending an INVITE request to the Conference Factory URI and including URI list in the INVITE request, UA-A indicates the dialogs which be re-used for this conference in the uri list by the mechanism described in 3GPP TS 24.147 [7].

INVITE CONF AS

To: CONF AS

From: A

Require: recipient-list-invite

Content-Type: application/resource-lists+xml

Content-Disposition: recipient-list

<?xml version="1.0" encoding="UTF-8"?>

<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"

xmlns:cp="urn:ietf:params:xml:ns:copyControl">

<list>

</list>

</resource-lists>

2: AS verifies if the dialogs in URI list matches to a partial dialog which AS already involved, In the case of a match the AS use this dialog ID information to send re-INVITE request to UA-B and UA-C in the partial dialogs between the AS and the invited users in order to connect the media of the invited users to the MRFP.

3: After the establishment of the conference a couple of possibilities exist:

– Release the two held and the active dialogs.

– Release the active dialog between UA-A and the AS and resume one of the held dialogs to active. And let the other dialog either to user B or C in status HOLD.

– Release one of the connections either to user B or user C. Which includes the release of the UA-A to AS dialog and resume the held connection.

NOTE: There are different behaviours between mobile and fixed access devices. While mobile devices are not able to provide more than two dialogs (e.g. one held one active) while the fixed line access has no restrictions. TISPAN defined in ETSI TS 183 043 [10] the IMS-based PSTN/ISDN emulation where a couple of examples are given.