Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.379  Word version:  17.5.0

Top   Top   Up   Prev   Next
1…   4…   7…   7.4…   10…   10.5…   10.6…   10.6.2.2.18…   10.6.2.2.34…   10.6.2.3…   10.6.2.3.2…   10.6.2.4…   10.6.2.5…   10.6.2.6…   10.6.2.7…   10.6.2.9…   10.6.2.10…   10.6.3…   10.7…   10.7.2.2   10.7.2.3…   10.7.3…   10.7.4…   10.7.5…   10.7.6…   10.9…   10.9.1.3…   10.9.2…   10.10…   10.14…   A…   A.4…   B…

 

10.7.6  Call transfer for MCPTT private calls |R17|

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 - 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.
Information Element Status Description
MCPTT IDMThe MCPTT ID of the party requesting the transfer
MCPTT ID (see NOTE)OThe MCPTT ID of the target of the transfer
Functional alias (see NOTE)OThe functional alias of the target of the transfer
Up
10.7.6.1.2  MCPTT private call transfer request (MCPTT server - MCPTT client)
Table 10.7.6.1.2-1 describes the information flow MCPTT private call transfer request from the MCPTT server to the MCPTT client.
Information Element Status Description
MCPTT IDMThe MCPTT ID of the party to be transferred
MCPTT IDMThe MCPTT ID of the target of the transfer
Up
10.7.6.1.3  MCPTT private call transfer response (MCPTT server - MCPTT client)Word‑p. 164
Table 10.7.6.1.3-1 describes the information flow MCPTT private call transfer response from the MCPTT server to the MCPTT client.
Information Element Status Description
MCPTT IDMThe MCPTT ID of the party requesting the transfer
MCPTT IDMThe MCPTT ID of the target of the transfer
ResultMResult of the transfer request - success or fail
Up
10.7.6.1.4  MCPTT private call transfer response (MCPTT client - 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.
Information Element Status Description
MCPTT IDMThe MCPTT ID of the party to be transferred (original calling party)
MCPTT IDMThe MCPTT ID of the target of the transfer
ResultMResult of the server initiated transfer request - success or fail
Up

10.7.6.2  Procedures

10.7.6.2.1  MCPTT private call unannounced transfer
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 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.
(not reproduced yet)
Figure 10.7.6.2.1-1: MCPTT private call unannounced transfer
Up
Step 1.
MCPTT client 1 initiates an MCPTT private call to MCPTT client 2 using the normal MCPTT call establishment procedures (10.7.2.2). The user at MCPTT client 1 can talk with the user at MCPTT client 2.
Step 2.
Now the MCPTT user at MCPTT client 2 decides to perform a call transfer.
Step 3.
The MCPTT client 2 sends an MCPTT call transfer request to the MCPTT server.
Step 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.
Step 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.
Step 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. Otherwise the MCPTT server sends an MCPTT private call transfer response with result "success" back to MCPTT client 2, and the procedure continues.
Step 6.
If authorized, the MCPTT server performs a server initiated private call release of the call between MCPTT client 1 and MCPTT client 2 (10.7.2.2.3.2).
Step 7.
The MCPTT server sends an MCPTT call transfer request towards the MCPTT client 1.
Step 8.
The user at MCPTT client 1 is notified that a call transfer is in progress.
Step 9.
MCPTT client 1 sends an MCPTT call transfer response back to the MCPTT server.
Step 10.
MCPTT client 1 sends an MCPTT private call request towards the MCPTT server that includes a call transfer indication set to true.
Step 11.
The MCPTT server verifies that 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.
Step 12.
The MCPTT server sends an MCPTT call request to MCPTT client 3.
Step 13.
The user at MCPTT client 3 is notified about the incoming call.
Step 14.
MCPTT client 3 sends an MCPTT private call response back to the MCPTT server.
Step 15.
The MCPTT server forwards the MCPTT private call response towards client 1.
Step 16.
The media plane for communication between client 1 and 3 is established.
Up
10.7.6.2.2  MCPTT private call announced transferWord‑p. 167
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 client 2.
  3. MCPTT client 2 is authorized to make private calls to 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 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.
(not reproduced yet)
Figure 10.7.6.2.2-1: MCPTT private call announced transfer
Up
Step 1.
MCPTT client 1 initiates an MCPTT private call to MCPTT client 2 using the normal MCPTT call establishment procedures (10.7.2.2). 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.
Step 2.
The MCPTT user at MCPTT client 2 puts the call locally on hold.
Step 3.
MCPTT client 2 initiates an MCPTT private call to MCPTT client 3 using the normal MCPTT call establishment procedures (10.7.2.2).
Step 4.
The user at MCPTT client 2 can talk with the user at MCPTT client 3 and announce the call transfer.
Step 5.
The MCPTT client 2 releases the MCPTT private call with MCPTT client 3 using the normal MCPTT call release procedure (10.7.2.2.3.1).
Step 6.
Optionally the MCPTT user at MCPTT client 2 puts the call with client 1 locally off hold and confirms that the call will be transfer.
Step 7.
Now the MCPTT user at MCPTT client 2 decides to perform a call transfer.
Step 8.
The MCPTT client 2 sends an MCPTT call transfer request to the MCPTT server.
Step 9.
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 9a. 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 9a. If no matching entry is found, the authorization check has failed and the procedure continues with step 10.
Step 9a.
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.
Step 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. Otherwise the MCPTT server sends an MCPTT private call transfer response with result "success" back to MCPTT client 2, and the procedure continues.
Step 11.
If authorized, the MCPTT server performs a server initiated private call release of the call between MCPTT client 1 and MCPTT client 2 (10.7.2.2.3.2).
Step 12.
The MCPTT server sends an MCPTT call transfer request towards the MCPTT client 1.
Step 13.
The user at MCPTT client 1 is notified that a call transfer is in progress.
Step 14.
MCPTT client 1 sends an MCPTT call transfer response back to the MCPTT server.
Step 15.
MCPTT client 1 sends an MCPTT private call request towards the MCPTT server that includes a call transfer indication set to true.
Step 16.
The MCPTT server verifies that 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.
Step 17.
The MCPTT server sends an MCPTT call request to MCPTT client 3.
Step 18.
The user at MCPTT client 3 is notified about the incoming call.
Step 19.
MCPTT client 3 sends an MCPTT private call response back to the MCPTT server.
Step 20.
The MCPTT server forwards the MCPTT private call response towards client 1.
Step 21.
The media plane for communication between client 1 and 3 is established.
Up

10.8  Simultaneous session for MCPTT calls (on-network)Word‑p. 170

10.8.1  General

An MCPTT client and MCPTT server may use a simultaneous session as defined in TS 23.280 for MCPTT calls. The MCPTT client becomes involved in a simultaneous session for MCPTT calls by inviting, joining or accepting more than one MCPTT call, or affiliating to a group.
The MCPTT client can also still handle multiple MCPTT calls in parallel at the same time i.e. using multiple dialogs.
The simultaneous session is established during either an originating on-demand call establishment or during pre-established session establishment or a modification of an already established pre-established session or on-demand call.
It is possible to change the prioritisation while the MCPTT client is engaged in multiple MCPTT calls. The setting of the priority can be made at MCPTT call setup or by performing a modification after the MCPTT call is established. This may result in more than one media bearer.
Up


Up   Top   ToC