10.7.6 Call transfer for MCPTT private calls

23.3793GPPFunctional architecture and information flows to support Mission Critical Push To Talk (MCPTT)Release 18Stage 2TS

10.7.6.1 General

Call transfer of MCPTT private calls allows users to relocate an existing MCPTT private call to another MCPTT user.

10.7.6.1.1 MCPTT private call transfer request (MCPTT client to MCPTT server)

Table 10.7.6.1.1-1 describes the information flow MCPTT private call transfer request from the MCPTT client to the MCPTT server.

Table 10.7.6.1.1-1: MCPTT private call transfer request (MCPTT client to MCPTT server) information elements

Information Element

Status

Description

MCPTT ID

M

The MCPTT ID of the party requesting the transfer

MCPTT ID (see NOTE)

O

The MCPTT ID of the target of the transfer

Functional alias (see NOTE)

O

The functional alias of the target of the transfer

NOTE: One identity shall be present

10.7.6.1.2 MCPTT private call transfer request (MCPTT server to MCPTT client and MCPTT server to MCPTT server)

Table 10.7.6.1.2-1 describes the information flow MCPTT private call transfer request from the MCPTT server to the MCPTT client and from the MCPTT server to the MCPTT server.

Table 10.7.6.1.2-1: MCPTT private call transfer request (MCPTT server to MCPTT client and from the MCPTT server to the MCPTT server) information elements

Information Element

Status

Description

MCPTT ID

M

The MCPTT ID of the party to be transferred

MCPTT ID

M

The MCPTT ID of the target of the transfer

10.7.6.1.3 MCPTT private call transfer response (MCPTT server to MCPTT client and MCPTT server to MCPTT server)

Table 10.7.6.1.3-1 describes the information flow MCPTT private call transfer response from the MCPTT server to the MCPTT client and from the MCPTT server to the MCPTT server.

Table 10.7.6.1.3-1: MCPTT private call transfer response (MCPTT server to MCPTT client and MCPTT server to MCPTT server) information elements

Information Element

Status

Description

MCPTT ID

M

The MCPTT ID of the party requesting the transfer

MCPTT ID

M

The MCPTT ID of the target of the transfer

Result

M

Result of the transfer request – success or fail.

10.7.6.1.4 MCPTT private call transfer response (MCPTT client to MCPTT server)

Table 10.7.6.1.4-1 describes the information flow MCPTT private call transfer response from the MCPTT client to the MCPTT server.

Table 10.7.6.1.4-1: MCPTT private call transfer response (MCPTT client to MCPTT server) information elements

Information Element

Status

Description

MCPTT ID

M

The MCPTT ID of the party to be transferred (original calling party)

MCPTT ID

M

The MCPTT ID of the target of the transfer

Result

M

Result of the server initiated transfer request – success or fail.

10.7.6.2 Procedures

10.7.6.2.1 MCPTT private call unannounced transfer in a single MCPTT system

The procedure for MCPTT private call unannounced transfer covers the case where an MCPTT client requests an ongoing MCPTT private call (with or without floor control) to be transferred to another MCPTT user without prior announcement.

Figure 10.7.6.2.1-1 below illustrates the procedure for MCPTT private call unannounced transfer.

Pre-conditions:

1. MCPTT client 2 is authorized to use call transfer.

2. MCPTT client 1 is authorized to make private calls to MCPTT client 2.

3. MCPTT client 2 is authorized to transfer private calls to MCPTT client 3.

4. MCPTT client 1 has the necessary security information to initiate a private call with MCPTT client 2 and MCPTT client 3 if end2end encryption is required for the private call.

Figure 10.7.6.2.1-1: MCPTT private call unannounced transfer

1. MCPTT client 1 initiates an MCPTT private call to MCPTT client 2 using the normal MCPTT call establishment as described in subclause 10.7.2.2. The MCPTT private call is established, and the user at MCPTT client 1 can talk with the user at MCPTT client 2.

2. Now the MCPTT user at MCPTT client 2 decides to perform a call transfer.

3. The MCPTT client 2 sends an MCPTT call transfer request to the MCPTT server.

4. The MCPTT server verifies that MCPTT client 2 is authorized to transfer the MCPTT private call to MCPTT client 3. This check is based on entries in the user profile of the user at MCPTT client 2. First, the MCPTT server checks the value of the "Allow private call transfer" entry. If it is false, the authorization check has failed, and the procedure continues with step 5. Otherwise the MCPTT server checks if the "Authorised to transfer private calls to any MCPTT user" entry is true. If this is the case the check has passed, and for target type of MCPTT ID the procedure continues with step 5 and for target ID type of functional alias the procedure continues with step 4a. The subsequent checking depends on the type of target ID. If the target ID is a MCPTT ID, the MCPTT server checks for a matching entry of the target MCPTT ID in the "List of MCPTT users that the MCPTT user is authorised to use as targets for call transfer" list. If a matching entry is found, the check has passed, if no matching entry is found the check has failed, for any outcome the procedure continues with step 5. If the target ID is a functional alias, the MCPTT server checks for a matching entry of the target functional alias in the "List of functional aliases that the MCPTT user is authorised to use as targets for call transfer" list. If a matching entry is found, the check has passed, and the procedure continues with step 4a. If no matching entry is found, the authorization check has failed and the procedure continues with step 5.

4a. If the target of the MCPTT private call transfer is a functional alias instead of an MCPTT ID the MCPTT server resolves the functional alias to the corresponding MCPTT ID for which the functional alias is active.

NOTE 1: Depending on implementation the MCPTT server can apply additional call restrictions and decide whether the call is allowed to proceed with the resolved MCPTT ID(s) (e.g. whether the MCPTT ID is within the allowed area of the functional alias). If the MCPTT server detects that the functional alias used as the target of the MCPTT private call transfer is simultaneously active for multiple MCPTT users, then the MCPTT server can proceed by selecting an appropriate MCPTT ID based on some selection criteria. The selection of an appropriate MCPTT ID is left to implementation. The selection criteria can include rejection of the call, if no suitable MCPTT ID is selected.

5. If the authorization check has failed, or the target of the transfer is a functional alias that is not active, or the target of the transfer is a functional alias that is simultaneously active by multiple users and the outcome of the selection is a rejection, the MCPTT private call transfer is cancelled, and the MCPTT server sends an MCPTT private call transfer response with result "fail" back to MCPTT client 2. The MCPTT private call between MCPTT client 1 and MCPTT client 2 remains up, and the procedure stops. Otherwise, the procedure continues.

6. MCPTT client 2 initiates release of the private call between MCPTT client 1 and MCPTT client 2 as described in subclause 10.7.2.2.3.1. This step can occur at any time after step 5, since a new private call between MCPTT client 1 and MCPTT client 3 is independent of the private call between MCPTT client 1 and MCPTT client 2.

7. The MCPTT server sends an MCPTT call transfer request towards the MCPTT client 1.

8. Optionally the user at MCPTT client 1 is notified that a call transfer is in progress.

9. MCPTT client 1 sends an MCPTT call transfer response back to the MCPTT server.

10. MCPTT client 1 sends an MCPTT private call request towards the MCPTT server that includes a call transfer indication set to true.

11. The MCPTT server verifies that MCPTT client 1 is authorized to perform the MCPTT private call as a result of the MCPTT private call transfer request based on the fact that the transfer indication is present and set to true in the MCPTT private call request.

NOTE 2: For call transfer the MCPTT server does not check if the initial originating MCPTT user at MCPTT client 1 is authorized to make an MCPTT private call to the final target MCPTT user at MCPTT client 3.

12. The MCPTT server sends an MCPTT call request to MCPTT client 3.

13. The user at MCPTT client 3 is notified about the incoming call.

14. MCPTT client 3 sends an MCPTT private call response back to the MCPTT server.

15. The MCPTT server forwards the MCPTT private call response towards MCPTT client 1.

16. The media plane for communication between MCPTT client 1 and MCPTT client 3 is established.

10.7.6.2.2 MCPTT private call announced transfer in a single MCPTT system

The procedure for MCPTT private call announced transfer covers the case where an MCPTT client requests an ongoing MCPTT private call (with or without floor control) to be transferred to another MCPTT user with prior announcement.

Figure 10.7.6.2.2-1 below illustrates the procedure for MCPTT private call announced transfer.

Pre-conditions:

1. MCPTT client 2 is authorized to use call transfer.

2. MCPTT client 1 is authorized to make private calls to MCPTT client 2.

3. MCPTT client 2 is authorized to make private calls to MCPTT client 3.

4. MCPTT client 2 is authorized to transfer private calls to MCPTT client 3.

5. MCPTT client 2 supports simultaneous sessions for MCPTT private calls (10.8).

6. MCPTT client 1 has the necessary security information to initiate a private call with MCPTT client 2 and MCPTT client 3, and MCPTT client 2 has the necessary security information to initiate a private call with MCPTT client 3 if end2end encryption is required for the private call.

Figure 10.7.6.2.2-1: MCPTT private call announced transfer

1. MCPTT client 1 initiates an MCPTT private call to MCPTT client 2 using the normal MCPTT call establishment as described in subclause 10.7.2.2. The MCPTT private call is established, and the user at MCPTT client 1 can talk with the user at MCPTT client 2. The user at MCPTT client 2 decides to transfer the call.

2. The MCPTT user at MCPTT client 2 puts the call on hold.

3. MCPTT client 2 initiates an MCPTT private call to MCPTT client 3 using the normal MCPTT call establishment procedures as described in subclause 10.7.2.2. The MCPTT private call is established, and the user at MCPTT client 2 can talk with the user at MCPTT client 3.

4. The user at MCPTT client 2 can talk with the user at MCPTT client 3 and announce the call transfer.

5. The MCPTT client 2 releases the MCPTT private call with MCPTT client 3 using the normal MCPTT call release procedure as described in subclause 10.7.2.2.3.1. This step can occur at any time after step 4.

6. Optionally the MCPTT user at MCPTT client 2 puts the call with MCPTT client 1 off hold and confirms that the call will be transferred.

7. The MCPTT client 2 sends an MCPTT call transfer request to the MCPTT server.

8. The MCPTT server verifies that MCPTT client 2 is authorized to transfer the MCPTT private call to MCPTT client 3. This check is based on entries in the user profile of the user at MCPTT client 2. First, the MCPTT server checks the value of the "Allow private call transfer" entry. If it is false, the authorization check has failed, and the procedure continues with step 10. Otherwise the MCPTT server checks if the "Authorised to transfer private calls to any MCPTT user" entry is true. If this is the case the check has passed, and for target type of MCPTT ID the procedure continues with step 10 and for target ID type of functional alias the procedure continues with step 9. The subsequent checking depends on the type of target ID. If the target ID is a MCPTT ID, the MCPTT server checks for a matching entry of the target MCPTT ID in the "List of MCPTT users that the MCPTT user is authorised to use as targets for call transfer" list. If a matching entry is found, the check has passed, if no matching entry is found the check has failed, for any outcome the procedure continues with step 10. If the target ID is a functional alias, the MCPTT server checks for a matching entry of the target functional alias in the "List of functional aliases that the MCPTT user is authorised to use as targets for call transfer" list. If a matching entry is found, the check has passed, and the procedure continues with step 9. If no matching entry is found, the authorization check has failed and the procedure continues with step 10.

9. If the target of the MCPTT private call transfer is a functional alias instead of an MCPTT ID the MCPTT server resolves the functional alias to the corresponding MCPTT ID for which the functional alias is active.

NOTE 1: Depending on implementation the MCPTT server can apply additional call restrictions and decide whether the call is allowed to proceed with the resolved MCPTT ID(s) (e.g. whether the MCPTT ID is within the allowed area of the functional alias). If the MCPTT server detects that the functional alias used as the target of the MCPTT private call transfer is simultaneously active for multiple MCPTT users, then the MCPTT server can proceed by selecting an appropriate MCPTT ID based on some selection criteria. The selection of an appropriate MCPTT ID is left to implementation. The selection criteria can include rejection of the call, if no suitable MCPTT ID is selected.

10. If the authorization check has failed, or the target of the transfer is a functional alias that is not active, or the target of the transfer is a functional alias that is simultaneously active by multiple users and the outcome of the selection is a rejection, the MCPTT private call transfer is cancelled, and the MCPTT server sends an MCPTT private call transfer response with result "fail" back to MCPTT client 2. The MCPTT private call between MCPTT client 1 and MCPTT client 2 remains up, and the procedure stops. Otherwise, the procedure continues.

11. MCPTT client 2 initiates release of the private call between MCPTT client 1 and MCPTT client 2 as described in subclause 10.7.2.2.3.1. This step can occur at any time after step 10, since a new private call between MCPTT client 1 and MCPTT client 3 is independent of the private call between MCPTT client 1 and MCPTT client 2.

12. The MCPTT server sends an MCPTT call transfer request towards the MCPTT client 1.

13. Optionally the user at MCPTT client 1 is notified that a call transfer is in progress.

14. MCPTT client 1 sends an MCPTT call transfer response back to the MCPTT server.

15. MCPTT client 1 sends an MCPTT private call request towards the MCPTT server that includes a call transfer indication set to true.

16. The MCPTT server verifies that MCPTT client 1 is authorized to perform the MCPTT private call as a result of the MCPTT private call transfer request based on the fact that the transfer indication is present and set to true in the MCPTT private call request.

NOTE 2: For call transfer the MCPTT server does not check if the initial originating MCPTT user at MCPTT client 1 is authorized to make an MCPTT private call to the final target MCPTT user at MCPTT client 3.

17. The MCPTT server sends an MCPTT call request to MCPTT client 3.

18. The user at MCPTT client 3 is notified about the incoming call.

19. MCPTT client 3 sends an MCPTT private call response back to the MCPTT server.

20. The MCPTT server forwards the MCPTT private call response towards MCPTT client 1.

21. The media plane for communication between MCPTT client 1 and MCPTT client 3 is established.

10.7.6.2.3 MCPTT private call announced transfer with target in partner MCPTT system

The procedure for MCPTT private call announced transfer covers the case where an MCPTT client requests an ongoing MCPTT private call (with or without floor control) to be transferred to another MCPTT user with prior announcement.

Figure 10.7.6.2.3-1 below illustrates the procedure for MCPTT private call announced transfer with target in partner MCPTT system.

NOTE 1: The procedure for MCPTT private call unannounced transfer is very similar, the only difference is that steps 2-6 are skipped.

Pre-conditions:

1. MCPTT client 2 is authorized to use call transfer.

2. MCPTT client 1 is authorized to make private calls to MCPTT client 2.

3. MCPTT client 2 is authorized to make private calls to MCPTT client 3.

4. MCPTT client 2 is authorized to transfer private calls to MCPTT client 3.

5. MCPTT client 2 supports simultaneous sessions for MCPTT private calls (10.8).

6. MCPTT client 1 has the necessary security information to initiate a private call with MCPTT client 2 and MCPTT client 3, and MCPTT client 2 has the necessary security information to initiate a private call with MCPTT client 3 if end2end encryption is required for the private call.

Figure 10.7.6.2.3-1: MCPTT private call announced transfer with target in partner MCPTT system

1. MCPTT client 1 initiates an MCPTT private call to MCPTT client 2 using the normal MCPTT call establishment as described in subclause 10.7.2.2. The MCPTT private call is established, and the user at MCPTT client 1 can talk with the user at MCPTT client 2. The user at MCPTT client 2 decides to transfer the call.

2. The MCPTT user at MCPTT client 2 puts the call with MCPTT user at MCPTT client 1 on hold.

3. MCPTT client 2 initiates an MCPTT private call to MCPTT client 3 using the normal MCPTT call establishment procedures as described in subclause 10.7.2.3. The MCPTT private call is established, and the user at MCPTT client 2 can talk with the user at MCPTT client 3.

NOTE 2: The procedure for private call using functional alias towards a partner MC system is defined in clause 10.16.3 in 3GPP TS 23.280[16].

4. The user at MCPTT client 2 can talk with the user at MCPTT client 3 and announces the call transfer.

5. The MCPTT client 2 releases the MCPTT private call with MCPTT client 3 using the normal MCPTT call release procedure as described in subclause 10.7.2.3. This step can occur at any time after step 4.

6. The MCPTT user at MCPTT client 2 puts the call with MCPTT client 1 off hold and confirms that the call will be transferred.

7. The MCPTT client 2 sends an MCPTT call transfer request to the MCPTT server 1.

8. The MCPTT server 1 verifies that MCPTT client 2 is authorized to transfer the MCPTT private call to MCPTT client 3. This check is based on entries in the user profile of the user at MCPTT client 2. First, the MCPTT server 1 checks the value of the "Allow private call transfer" entry. If it is false, the authorization check has failed, and the procedure continues with step 10. Otherwise, the MCPTT server 1 checks if the "Authorised to transfer private calls to any MCPTT user" entry is true. If this is the case the check has passed, and for target type of MCPTT ID the procedure continues with step 10 and for target ID type of functional alias the procedure continues with step 9. The subsequent checking depends on the type of target ID. If the target ID is a MCPTT ID, the MCPTT server 1 checks for a matching entry of the target MCPTT ID in the "List of MCPTT users that the MCPTT user is authorised to use as targets for call transfer" list. If a matching entry is found, the check has passed, if no matching entry is found the check has failed, for any outcome the procedure continues with step 10. If the target ID is a functional alias, the MCPTT server 1 checks for a matching entry of the target functional alias in the "List of functional aliases that the MCPTT user is authorised to use as targets for call transfer" list. If a matching entry is found, the check has passed, and the procedure continues with step 9. If no matching entry is found, the authorization check has failed and the procedure continues with step 10.

9. If the target of the MCPTT private call transfer is a functional alias instead of an MCPTT ID the MCPTT server 1 resolves the functional alias to the corresponding MCPTT ID for which the functional alias is active.

NOTE 3: Depending on implementation the MCPTT server can apply additional call restrictions and decide whether the call is allowed to proceed with the resolved MCPTT ID(s) (e.g. whether the MCPTT ID is within the allowed area of the functional alias). If the MCPTT server detects that the functional alias used as the target of the MCPTT private call transfer is simultaneously active for multiple MCPTT users, then the MCPTT server can proceed by selecting an appropriate MCPTT ID based on some selection criteria. The selection of an appropriate MCPTT ID is left to implementation. The selection criteria can include rejection of the call, if no suitable MCPTT ID is selected.

10. If the authorization check has failed, or the target of the transfer is a functional alias that is not active, or the target of the transfer is a functional alias that is simultaneously active by multiple users and the outcome of the selection is a rejection, the MCPTT private call transfer is cancelled, and the MCPTT server 1 sends an MCPTT private call transfer response with result "fail" back to MCPTT client 2. The MCPTT private call between MCPTT client 1 and MCPTT client 2 remains up, and the procedure stops. Otherwise the procedure continues.

11. The MCPTT server 1 sends an MCPTT call transfer request towards the MCPTT client 1.

12. Optionally the user at MCPTT client 1 is notified that a call transfer is in progress.

13. MCPTT client 1 sends an MCPTT private call request towards the MCPTT server 1 that includes a call transfer indication set to true.

14. The MCPTT server 1 verifies that MCPTT client 1 is authorized to perform the MCPTT private call as a result of the MCPTT private call transfer request based on the fact that the transfer indication is present and set to true in the MCPTT private call request.

NOTE 4: For call transfer the MCPTT server does not check if the initial originating MCPTT user at MCPTT client 1 is authorized to make an MCPTT private call to the final target MCPTT user at MCPTT client 3.

15. The MCPTT server 1 sends an MCPTT call request to MCPTT server 2.

16. The MCPTT server 2 sends an MCPTT call request to MCPTT client 3.

NOTE 5: MCPTT server 2 detects that the private call request contains a transfer indication set to true and therefore skips the authorization checking.

17. The user at MCPTT client 3 is notified about the incoming call.

18. MCPTT client 3 sends an MCPTT private call response back to the MCPTT server 2.

19. MCPTT server 2 sends an MCPTT private call response back to the MCPTT server 1.

20. The MCPTT server 1 forwards the MCPTT private call response towards MCPTT client 1.

21. MCPTT client 1 sends an MCPTT call transfer response back to MCPTT server 1.

22. The MCPTT server 1 forwards the MCPTT private transfer response towards MCPTT client 2.

23. MCPTT client 2 initiates release of the private call between MCPTT client 1 and MCPTT client 2 as described in subclause 10.7.2.3.

24. The media plane for communication between MCPTT client 1 and MCPTT client 3 is established.

10.7.6.2.4 MCPTT private call announced transfer with transferring MCPTT user in partner MCPTT system

The procedure for MCPTT private call announced transfer covers the case where an MCPTT client requests an ongoing MCPTT private call (with or without floor control) to be transferred to another MCPTT user with prior announcement.

Figure 10.7.6.2.4-1 below illustrates the procedure for MCPTT private call announced transfer with transferring MCPTT user in partner MCPTT system.

NOTE 1: The procedure for MCPTT private call unannounced transfer is very similar, the only difference is that steps 2-6 are skipped.

Pre-conditions:

1. MCPTT client 3 is authorized to use call transfer.

2. MCPTT client 1 is authorized to make private calls to MCPTT client 3.

3. MCPTT client 3 is authorized to make private calls to MCPTT client 2.

4. MCPTT client 3 is authorized to transfer private calls to MCPTT client 2.

5. MCPTT client 3 supports simultaneous sessions for MCPTT private calls (10.8).

6. MCPTT client 1 has the necessary security information to initiate a private call with MCPTT client 2 and MCPTT client 3, and MCPTT client 3 has the necessary security information to initiate a private call with MCPTT client 2 if end2end encryption is required for the private call.

Figure 10.7.6.2.4-1: MCPTT private call announced transfer transferring MCPTT user in partner MCPTT system

1. MCPTT client 1 initiates an MCPTT private call to MCPTT client 3 using the normal MCPTT call establishment as described in subclause 10.7.2.3. The MCPTT private call is established, and the user at MCPTT client 1 can talk with the user at MCPTT client 3. The user at MCPTT client 3 decides to transfer the call.

NOTE 2: The procedure for private call using functional alias towards a partner MC system is defined in clause 10.16.3 in 3GPP TS 23.280[16].

2. The MCPTT user at MCPTT client 3 puts the call with MCPTT user at MCPTT client 1 on hold.

3. MCPTT client 3 initiates an MCPTT private call to MCPTT client 2 using the normal MCPTT call establishment procedures as described in subclause 10.7.2.3. The MCPTT privat call is established, and the user at MCPTT client 3 can talk with the user at MCPTT client 2.

NOTE 3: The procedure for private call using functional alias towards a partner MC system is defined in clause 10.16.3 in 3GPP TS 23.280[16].

4. The user at MCPTT client 3 can talk with the user at MCPTT client 2 and announce the call transfer.

5. The MCPTT client 3 releases the MCPTT private call with MCPTT client 2 using the normal MCPTT call release procedure as described in subclause 10.7.2.3. This step can occur at any time after step 4.

6. The MCPTT user at MCPTT client 3 puts the call with MCPTT client 1 off hold and confirms that the call will be transferred.

7. The MCPTT client 3 sends an MCPTT call transfer request to the MCPTT server 2.

8. The MCPTT server 2 verifies that MCPTT client 3 is authorized to transfer the MCPTT private call to MCPTT client 2. This check is based on entries in the user profile of the user at MCPTT client 3. First, the MCPTT server 2 checks the value of the "Allow private call transfer" entry. If it is false, the authorization check has failed, and the procedure continues with step 10. Otherwise, the MCPTT server 2 checks if the "Authorised to transfer private calls to any MCPTT user" entry is true. If this is the case the check has passed, and for target type of MCPTT ID the procedure continues with step 10 and for target ID type of functional alias the procedure continues with step 9. The subsequent checking depends on the type of target ID. If the target ID is an MCPTT ID, the MCPTT server 2 checks for a matching entry of the target MCPTT ID in the "List of MCPTT users that the MCPTT user is authorised to use as targets for call transfer" list. If a matching entry is found, the check has passed, if no matching entry is found the check has failed, for any outcome the procedure continues with step 10. If the target ID is a functional alias, the MCPTT server 2 checks for a matching entry of the target functional alias in the "List of functional aliases that the MCPTT user is authorised to use as targets for call transfer" list. If a matching entry is found, the check has passed, and the procedure continues with step 9. If no matching entry is found, the authorization check has failed and the procedure continues with step 10.

9. If the target of the MCPTT private call transfer is a functional alias instead of an MCPTT ID the MCPTT server 2 resolves the functional alias to the corresponding MCPTT ID for which the functional alias is active.

NOTE 4: Depending on implementation the MCPTT server can apply additional call restrictions and decide whether the call is allowed to proceed with the resolved MCPTT ID(s) (e.g. whether the MCPTT ID is within the allowed area of the functional alias). If the MCPTT server detects that the functional alias used as the target of the MCPTT private call transfer is simultaneously active for multiple MCPTT users, then the MCPTT server can proceed by selecting an appropriate MCPTT ID based on some selection criteria. The selection of an appropriate MCPTT ID is left to implementation. The selection criteria can include rejection of the call, if no suitable MCPTT ID is selected.

10. If the authorization check has failed, or the target of the transfer is a functional alias that is not active, or the target of the transfer is a functional alias that is simultaneously active by multiple users and the outcome of the selection is a rejection, the MCPTT private call transfer is cancelled, and the MCPTT server 2 sends an MCPTT private call transfer response with result "fail" back to MCPTT client 3. The MCPTT private call between MCPTT client 3 and MCPTT client 2 remains up, and the procedure stops. Otherwise the procedure continues.

11. The MCPTT server 2 sends an MCPTT call transfer request towards the MCPTT server 1.

12. The MCPTT server 1 sends an MCPTT call transfer request towards the MCPTT client 1.

13. Optionally the user at MCPTT client 1 is notified that a call transfer is in progress.

14. MCPTT client 1 sends an MCPTT private call request towards the MCPTT server 1 that includes a call transfer indication set to true.

15. The MCPTT server 1 verifies that MCPTT client 1 is authorized to perform the MCPTT private call as a result of the MCPTT private call transfer request based on the fact that the transfer indication is present and set to true in the MCPTT private call request.

NOTE 5: For call transfer the MCPTT server does not check if the initial originating MCPTT user at MCPTT client 1 is authorized to make an MCPTT private call to the final target MCPTT user at MCPTT client 2.

16. The MCPTT server 1 sends an MCPTT private call request to MCPTT client 2.

17. The user at MCPTT client 2 is notified about the incoming call.

18. MCPTT client 2 sends an MCPTT private call response back to the MCPTT server 1.

19. The MCPTT server 1 forwards the MCPTT private call response towards MCPTT client 1.

20. MCPTT client 1 sends an MCPTT call transfer response back to the MCPTT server 1.

21. The MCPTT server 1 sends an MCPTT call transfer response back to the MCPTT server 2.

22. The MCPTT server 2 sends an MCPTT call transfer response back to the MCPTT client 3.

23. MCPTT client 3 initiates release of the private call between MCPTT client 3 and MCPTT client 1 as described in subclause 10.7.2.3.

24. The media plane for communication between MCPTT client 1 and MCPTT client 2 is established.