10.7.2 Private call in on-network
23.3793GPPFunctional architecture and information flows to support Mission Critical Push To Talk (MCPTT)Release 18Stage 2TS
10.7.2.1 Information flows for private call in on-network
10.7.2.1.1 MCPTT private call request (MCPTT client to MCPTT server)
Table 10.7.2.1.1-1 describes the information flow MCPTT private call request from the MCPTT client to the MCPTT server.
Table 10.7.2.1.1-1: MCPTT private call request (MCPTT client to MCPTT server) information elements
|
Information Element |
Status |
Description |
|
MCPTT ID |
M |
The MCPTT ID of the calling party |
|
Functional alias |
O |
The functional alias of the calling party |
|
MCPTT ID (see NOTE) |
O |
The MCPTT ID of the called party |
|
Functional alias (see NOTE) |
O |
The functional alias of the called party |
|
Use floor control indication |
M |
This element indicates whether floor control will be used for the private call. |
|
SDP offer |
O |
Media parameters of MCPTT client. |
|
Requested commencement mode |
O |
An indication that is included if the user is requesting a particular commencement mode |
|
Implicit floor request |
O |
An indication that the user is also requesting the floor. |
|
Location information |
O |
Location of the calling party |
|
Requested priority |
O |
Application priority level requested for this call |
|
Transfer indicator |
O |
Indicates that the MCPTT private call request is a result of a call transfer (true/false) |
|
Forwarding indicator |
O |
Indicates that the MCPTT private call request is a result of a call forwarding.(true/false) |
|
Remotely initiated call request indicator |
O |
Indicates that the MCPTT private call request is a result of receiving of a remotely initiated call request and may be included only for remotely initiated call |
|
NOTE: At least one identity must be present. |
||
10.7.2.1.2 MCPTT private call request (MCPTT server to MCPTT server)
Table 10.7.2.1.2-1 describes the information flow MCPTT private call request from the MCPTT server to the MCPTT server.
Table 10.7.2.1.2-1: MCPTT private call request (MCPTT server to MCPTT server) information elements
|
Information Element |
Status |
Description |
|
MCPTT ID |
M |
The MCPTT ID of the calling party |
|
Functional alias |
O |
The functional alias of the calling party |
|
MCPTT ID |
M |
The MCPTT ID of the called party |
|
Functional alias |
O |
The functional alias of the called party |
|
Use floor control indication |
M |
This element indicates whether floor control will be used for the private call. |
|
SDP offer |
M |
Media parameters of MCPTT client. |
|
Requested commencement mode |
O |
An indication of the commencement mode to be used. |
|
Implicit floor request |
O |
An indication that the user is also requesting the floor. |
|
Requested priority |
O |
Priority level requested for the call. |
|
Forwarding indicator |
O |
Indicates whether the MCPTT private call request is a result of a call forwarding. (true/false) |
|
Transfer indicator |
O |
Indicates that the MCPTT private call request is a result of a call transfer (true/false) |
|
Location information |
O |
Location of the calling party |
|
Remotely initiated call request indicator |
O |
Indicates that the MCPTT private call request is a result of receiving of a remotely initiated call request and may be included only for remotely initiated call |
10.7.2.1.2a MCPTT private call request (MCPTT server to MCPTT client)
Table 10.7.2.1.2a describes the information flow MCPTT private call request from the MCPTT server to the MCPTT client.
Table 10.7.2.1.2a: MCPTT private call request (MCPTT server to MCPTT client) information elements
|
Information Element |
Status |
Description |
|
MCPTT ID |
M |
The MCPTT ID of the calling party |
|
Functional alias |
O |
The functional alias of the calling party |
|
MCPTT ID |
M |
The MCPTT ID of the called party |
|
Functional alias |
O |
The functional alias of the called party |
|
Use floor control indication |
M |
This element indicates whether floor control will be used for the private call. |
|
SDP offer |
M |
Media parameters of MCPTT client. |
|
Requested commencement mode |
O |
An indication of the commencement mode to be used. |
|
Implicit floor request |
O |
An indication that the user is also requesting the floor. |
|
Remotely initiated call request indicator |
O |
Indicates that the MCPTT private call request is a result of receiving of a remotely initiated call request and may be included only for remotely initiated call |
10.7.2.1.3 MCPTT private call response (MCPTT client to MCPTT server)
Table 10.7.2.1.3-1 describes the information flow MCPTT private call response from the MCPTT client to the MCPTT server.
Table 10.7.2.1.3-1: MCPTT private call response (MCPTT client to MCPTT server) information elements
|
Information Element |
Status |
Description |
|
MCPTT ID |
M |
The MCPTT ID of the calling party |
|
Functional alias |
O |
The functional alias of the calling party |
|
MCPTT ID |
O |
The MCPTT ID of the called party |
|
Functional alias |
O |
The functional alias of the called party |
|
SDP answer |
M |
Media parameters selected |
|
Requested commencement mode |
O |
An indication of the commencement mode to be used. |
10.7.2.1.4 MCPTT private call response
Table 10.7.2.1.4-1 describes the information flow MCPTT private call response from the MCPTT server to the MCPTT server and the MCPTT server to the MCPTT client.
Table 10.7.2.1.4-1: MCPTT private call response information elements
|
Information Element |
Status |
Description |
|
MCPTT ID |
M |
The MCPTT ID of the calling party |
|
Functional alias |
O |
The functional alias of the calling party |
|
MCPTT ID |
O |
The MCPTT ID of the called party |
|
Functional alias |
O |
The functional alias of the called party |
|
Acceptance confirmation |
O |
An indication whether the user has positively accepted the call. |
|
SDP answer |
M |
Media parameters selected |
10.7.2.1.4a MCPTT private call end request
Table 10.7.2.1.4a-1 describes the information flow MCPTT private call end request from the MCPTT client to the MCPTT server and from the MCPTT server to the MCPTT client.
Table 10.7.2.1.4a-1: MCPTT private call end request information elements
|
Information Element |
Status |
Description |
|
MCPTT ID |
M |
The MCPTT ID of the calling party |
|
MCPTT ID |
M |
The MCPTT ID of the called party |
|
Private call end reason |
O |
Indicate that the reason to end the call, e.g., due to migration, or due to user request. |
10.7.2.1.4b MCPTT private call end response
Table 10.7.2.1.4b-1 describes the information flow MCPTT private call end response from the MCPTT client to the MCPTT server and from the MCPTT server to the MCPTT client.
Table 10.7.2.1.4b-1: MCPTT private call end response information elements
|
Information Element |
Status |
Description |
|
MCPTT ID |
M |
In the direction MCPTT client to MCPTT server this shall be the MCPTT ID of the responding MCPTT client. In the direction MCPTT server to MCPTT client this shall be the MCPTT ID of the destination MCPTT client |
10.7.2.1.5 MCPTT emergency private call request (MCPTT client to MCPTT server)
Table 10.7.2.1.5-1 describes the information flow MCPTT emergency private call request from the MCPTT client to the MCPTT server.
Table 10.7.2.1.5-1: MCPTT emergency private call request (MCPTT client to MCPTT server) information elements
|
Information Element |
Status |
Description |
|
MCPTT ID |
M |
The MCPTT ID of the calling party |
|
Functional alias |
O |
The functional alias of the calling party |
|
MCPTT ID (see NOTE) |
O |
The MCPTT ID of the called party |
|
Functional alias (see NOTE) |
O |
The functional alias of the called party |
|
Emergency indicator |
M |
Indicates that the private call request is an MCPTT emergency call |
|
Alert indicator |
M |
Indicates whether an emergency alert is to be sent |
|
Requested commencement mode |
O |
An indication of the commencement mode to be used. |
|
Implicit floor request |
O |
An indication that the user is also requesting the floor. |
|
SDP offer |
M |
Media parameters of MCPTT client. |
|
Requested priority |
O |
Priority level requested for the call. |
|
Location information |
O |
Location of the calling party |
|
NOTE: Only one identity shall be present. |
||
10.7.2.1.5a MCPTT emergency private call request (MCPTT server to MCPTT client)
Table 10.7.2.1.5a-1 describes the information flow MCPTT emergency private call request from the MCPTT server to the MCPTT client.
Table 10.7.2.1.5a-1: MCPTT emergency private call request (MCPTT server to MCPTT client) information elements
|
Information Element |
Status |
Description |
|
MCPTT ID |
M |
The MCPTT ID of the calling party |
|
Functional alias |
O |
The functional alias of the calling party |
|
MCPTT ID |
M |
The MCPTT ID of the called party |
|
Emergency indicator |
M |
Indicates that the private call request is an MCPTT emergency call |
|
Alert indicator |
M |
Indicates whether an emergency alert is to be sent |
|
Requested commencement mode |
O |
An indication of the commencement mode to be used. |
|
Implicit floor request |
O |
An indication that the user is also requesting the floor. |
|
SDP offer |
M |
Media parameters of MCPTT client. |
10.7.2.1.6 MCPTT progress indication
Table 10.7.2.1.6-1 describes the information flow MCPTT progress indication from the MCPTT server to the MCPTT client.
Table 10.7.2.1.6-1: MCPTT progress indication information elements
|
Information Element |
Status |
Description |
|
MCPTT ID |
M |
The MCPTT ID of the calling party |
|
MCPTT ID |
M |
The MCPTT ID of the called party |
|
Progress indication |
O |
Indication to the caller. |
10.7.2.1.7 MCPTT ringing
Table 10.7.2.1.7-1 describes the information flow MCPTT ringing from the MCPTT client to the MCPTT server, from the MCPTT server to the MCPTT server, and from the MCPTT server to the MCPTT client.
Table 10.7.2.1.7-1: MCPTT ringing information elements
|
Information Element |
Status |
Description |
|
MCPTT ID |
M |
The MCPTT ID of the calling party |
|
MCPTT ID |
M |
The MCPTT ID of the called party |
|
Ringing indication |
O |
Indication to the caller. |
10.7.2.1.8 MCPTT functional alias resolution response
Table 10.7.2.1.8-1 describes the information flow MCPTT functional alias resolution response from the MCPTT server to the MCPTT client.
Table 10.7.2.1.8-1: MCPTT functional alias resolution response information elements
|
Information Element |
Status |
Description |
|
MCPTT ID |
M |
The MCPTT ID of the calling party |
|
MCPTT ID |
M |
The corresponding MCPTT ID of the called functional alias |
10.7.2.1.9 MCPTT private call cancel request (MCPTT server to MCPTT client)
Table 10.7.2.1.9-1 describes the information flow MCPTT private call cancel request from the MCPTT server to the MCPTT client.
Table 10.7.2.1.9-1: MCPTT private call cancel request (MCPTT server to MCPTT client)
information elements
|
Information Element |
Status |
Description |
|
MCPTT ID |
M |
The MCPTT ID of the calling party |
|
MCPTT ID |
M |
The MCPTT ID of the called party |
10.7.2.1.10 MCPTT private call cancel response (MCPTT client to MCPTT server)
Table 10.7.2.1.10-1 describes the information flow MCPTT private call cancel response from the MCPTT client to the MCPTT server.
Table 10.7.2.1.10-1: MCPTT private call cancel response (MCPTT client to MCPTT server)
information elements
|
Information Element |
Status |
Description |
|
MCPTT ID |
M |
The MCPTT ID of the called party |
10.7.2.2 Private call within one MCPTT system
10.7.2.2.1 Private call setup in automatic commencement mode
The procedure focuses on the case where an MCPTT user is initiating an MCPTT private call for communicating with another MCPTT user, with or without floor control enabled, in an automatic commencement mode.
Procedures in figure 10.7.2.2.1-1 are the basic signalling control plane procedures for the MCPTT client initiating establishment of MCPTT private call with the chosen MCPTT user.
Pre-conditions:
1. The calling MCPTT user has selected automatic commencement mode for the call; or
2. The called MCPTT client is set to automatic commencement mode.
3. Optionally, MCPTT client 1 may use an activated functional alias for the call.
4. The MCPTT server has subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Figure 10.7.2.2.1-1: Private call setup in automatic commencement mode– MCPTT users in the same MCPTT system
1. MCPTT users on MCPTT client 1 and MCPTT client 2 are already registered for receiving MCPTT service, as per procedure in subclause 10.2.
2. User at MCPTT client 1 would like to initiate an MCPTT private call for the chosen MCPTT user. The MCPTT user at MCPTT client 1 may include a functional alias used within the MCPTT private call. For a private call with floor control, floor control is to be established.
3. MCPTT client 1 sends an MCPTT private call request towards the MCPTT server (via SIP core) using a service identifier as defined in 3GPP TS 23.228 [5] for MCPTT, for establishing a private call with the chosen MCPTT user. The MCPTT private call request contains the MCPTT ID or the functional alias of the invited user, an SDP offer containing one or more media types. For a private call with floor control, the MCPTT private call request also contains an element that indicates that MCPTT client 1 is requesting the floor. The MCPTT client 1 may include a Requested commencement mode that indicates that the call is to be established in automatic commencement mode if automatic commencement mode is requested by the initiating user.
NOTE 1: As part of this step, MCPTT client 1 and MCPTT client 2 set up a security association (when no functional alias is present), if end-to-end encryption is used for this call.
4. If the MCPTT private call request contains a functional alias instead of an MCPTT ID as called party, the MCPTT server shall resolve the functional alias to the corresponding MCPTT ID(s) for which the functional alias is active. The MCPTT server shall also check whether MCPTT client 1 is allowed to use the functional alias of MCPTT client 2 to setup a private call and whether MCPTT client 2 is allowed to receive a private call from MCPTT client 1 using the functional alias. If authorized, proceed with step 5. Otherwise the MCPTT server checks whether the MCPTT user at MCPTT client 1 is authorized to initiate the private call, and that MCPTT user at MCPTT client 2 is authorized to receive the private call. If the MCPTT private call request requested automatic commencement mode then the MCPTT server also checks whether the MCPTT user at MCPTT client 1 is authorized to initiate a private call in automatic commencement mode and proceed with step 6.
NOTE 2: 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 private call request 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. This selection criteria can include rejection of the call, if no suitable MCPTT ID is selected.
5a. The MCPTT server responds with a functional alias resolution response message that contains the resolved MCPTT ID back to MCPTT client 1.
5b. If the MCPTT server replies with a MCPTT functional alias resolution response message, the MCPTT client 1 abandons the first MCPTT private call request in step 3 and sends a new MCPTT private call request towards the resolved MCPTT ID.
NOTE 3: MCPTT client 1 and MCPTT client 2 set up a security association for the media, if end-to-end encryption is used for this call.
6. MCPTT server may provide a progress indication to MCPTT client 1 to indicate progress in the call setup process.
NOTE 4: Step 6 can occur at any time following step 5b, and prior to step 10.
7. If authorized, MCPTT server includes information that it communicates using MCPTT service, offers the same media types or a subset of the media types contained in the initial received request, includes the requested automatic commencement mode indication based on a requested automatic commencement mode by the calling user or based upon the setting of the called MCPTT client and sends the corresponding MCPTT private call request towards the MCPTT client 2, including the MCPTT ID and, if available, the functional alias of the calling MCPTT user 1. If the called MCPTT user has registered to the MCPTT service with multiple MCPTT UEs and has designated the MCPTT UE for receiving the private calls, then the incoming MCPTT private call request is delivered only to the designated MCPTT UE.
8. The receiving MCPTT client 2 notifies the user about the incoming private call and displays the functional alias of calling MCPTT user 1.
9. The receiving MCPTT client 2 accepts the private call automatically, and an MCPTT private call response is sent to the MCPTT server (via SIP core).
10. Upon receiving the MCPTT private call response from MCPTT client 2 accepting the private call request, the MCPTT server informs the MCPTT client 1 about successful call establishment.
11. MCPTT client 1 and MCPTT client 2 have successfully established media plane for communication and either user can transmit media. For successful call establishment for private call with floor control request from MCPTT client 1, floor participant at MCPTT client 1 is granted floor by the floor control server, giving it permission to transmit. At the same time floor participant at MCPTT client 2 is informed by the floor control server that floor is taken.
10.7.2.2.2 Private call setup in manual commencement mode
10.7.2.2.2.1 Description
Figure 10.7.2.2.2.2-1 describes the basic procedure for the MCPTT client initiating an MCPTT private call that uses manual commencement mode. The flow may use a floor request in the MCPTT private call request indicating that the originator will be given the floor when the call starts and eliminates the need for a separate initial floor request message during media plane establishment. Alternatively the call initiation may be sent without the floor request, which allows the called party to request the floor first.
10.7.2.2.2.2 Procedure
Both clients are served by the primary MCPTT service provider in figure 10.7.2.2.2.2-1.
Pre-conditions:
1. The calling MCPTT user has selected manual commencement mode or has not specified a commencement mode for the call; and
2. The called MCPTT client is set to manual commencement mode.
3. Optionally, MCPTT client 1 may use an activated functional alias for the call.
4. The MCPTT server has subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Figure 10.7.2.2.2.2-1: MCPTT private call in manual commencement mode– MCPTT users in the same MCPTT system
1. MCPTT client 1 and MCPTT client 2 are both registered and their respective users, MCPTT user 1 and MCPTT user 2, are authenticated and authorized to use the MCPTT service, as per procedure in subclause 10.2.
2. MCPTT user at MCPTT client 1 would like to initiate an MCPTT private call for the selected MCPTT user. The MCPTT user at MCPTT client 1 may include a functional alias used within the MCPTT private call. For a private call with floor control, floor control is to be established. For private call without floor control, both users will have the ability to transmit without floor arbitration.
3. MCPTT client 1 sends an MCPTT private call request addressed to the MCPTT ID of MCPTT user 2 using an MCPTT service identifier as defined in 3GPP TS 23.228 [5] (possible for the SIP core to route the request to the MCPTT server). The MCPTT private call request contains the MCPTT ID or the functional alias of invited user and an SDP offer containing one or more media types. The MCPTT private call request may also contain a data element that indicates that MCPTT client 1 is requesting the floor, for a private call with floor control. The MCPTT client 1 may include a requested commencement mode that indicates that the call is to be established in manual commencement mode if manual commencement mode is requested by the initiating user.
NOTE 1: As part of this step, MCPTT client 1 and MCPTT client 2 set up a security association (when no functional alias is present), if end-to-end encryption is used for this call.
4. The MCPTT server confirms that both MCPTT users are authorized for the private call. MCPTT server verifies whether the provided functional alias, if present, can be used and has been activated for the user. The MCPTT server shall resolve the functional alias to the corresponding MCPTT ID(s) for which the functional alias is active. The MCPTT server shall also check whether MCPTT client 1 is allowed to use the functional alias of MCPTT client 2 to setup a private call and whether MCPTT client 2 is allowed to receive a private call from MCPTT client 1 using the functional alias. The MCPTT server checks the commencement mode setting of the called MCPTT client and also checks whether the MCPTT user at MCPTT client 1 is authorized to initiate a call in manual commencement mode.
NOTE 2: 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 private call request 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. This selection criteria can include rejection of the call, if no suitable MCPTT ID is selected.
5a. If the MCPTT private call request contains a functional alias instead of an MCPTT ID as called party, the MCPTT server responds with a functional alias resolution response message that contains the resolved MCPTT ID back to MCPTT client 1.
5b. If the MCPTT server replies with a MCPTT functional alias resolution response message, the MCPTT client 1 abandons the first MCPTT private call request in step 3 and sends a new MCPTT private call request towards the resolved MCPTT ID.
NOTE 3: MCPTT client 1 and MCPTT client 2 set up a security association for the media, if end-to-end encryption is used for this call.
6. The MCPTT server includes information that it communicates using MCPTT service, offers the same media types or a subset of the media types contained in the initial received request and sends an MCPTT private call request for the call to MCPTT client 2, including the MCPTT ID and, if available, the functional alias of the calling MCPTT user 1. If the called MCPTT user has registered to the MCPTT service with multiple MCPTT UEs and has designated the MCPTT UE for receiving the private calls, then the incoming MCPTT private call request is delivered only to the designated MCPTT UE.
7. MCPTT server may provide a progress indication to MCPTT client 1 to indicate progress in the call setup process.
NOTE 4: Step 7 can occur at any time following step 5b, and prior to step 8b.
8a. The MCPTT user is alerted and may display the functional alias of calling MCPTT user 1. MCPTT client 2 sends an MCPTT ringing to the MCPTT server.
8b. The MCPTT server sends an MCPTT ringing to MCPTT client 1, indicating that MCPTT client 2 is being alerted.
9. MCPTT user 2 has accepted the call using manual commencement mode (i.e., has taken some action to accept via the user interface) which causes MCPTT client 2 to send an MCPTT private call response to the MCPTT server. If MCPTT user 2 has not accepted the incoming call, the MCPTT client 2 sends a call failure response to the MCPTT server without adding reason for call failure.
10. The MCPTT server sends an MCPTT private call response to MCPTT client 1 indicating that MCPTT user 2 has accepted the call, including the accepted media parameters.
11. The media plane for communication is established. Either user can transmit media individually when using floor control. For successful call establishment for private call with floor request from MCPTT client 1, the floor participant associated with MCPTT client 1 is granted the floor initially. At the same time the floor participant associated with MCPTT client 2 is informed that the floor is taken. The meaning of the floor request (give floor initially to originator [client 1], or give floor initially to target [client 2]) may be configurable. For a private call without floor control both users are allowed to transmit simultaneously.
10.7.2.2.3 Private call release
10.7.2.2.3.1 Client initiated
The procedure focuses on the case where an MCPTT client is requesting to release an ongoing MCPTT private call (with or without floor control) and the call established in either of the two commencement modes (manual or automatic).
Procedures in figure 10.7.2.2.3.1-1 are the basic signalling control plane procedures for the MCPTT client initiating the release of an ongoing MCPTT private call.
Figure 10.7.2.2.3.1-1: Private call release – client initiated
1. It is assumed that MCPTT users on MCPTT client 1 and MCPTT client 2 are already registered for receiving MCPTT service and are involved in private call with or without floor control established either in manual or automatic commencement mode, as described in subclause 10.7.2.2.1 and subclause 10.7.2.2.2.
2. User at MCPTT client 1 would like to release an ongoing MCPTT private call with MCPTT client 2.
3. MCPTT client 1 sends an MCPTT private call end request towards the MCPTT server (via SIP core), for tearing down the private call with the other client.
4. MCPTT server sends the corresponding MCPTT private call end request towards the MCPTT client specified in the original MCPTT private call end request.
5. MCPTT user is notified about the release of the private call.
6. The receiving MCPTT client 2 acknowledges the MCPTT private call end request with an MCPTT private call end response.
7. After receiving the MCPTT private call end response from MCPTT client 2, the MCPTT server generates an acknowledgement for the MCPTT client 1’s MCPTT private call end request.
8. MCPTT clients release all the media plane resources used for the private call. Further, if the private call was established with floor control, floor control resources are released and MCPTT clients cannot make further requests for floor control or send media.
10.7.2.2.3.2 Server initiated
The procedure focuses on the case where an MCPTT server is terminating an ongoing MCPTT private call (with or without floor control) and the call established in either of the two commencement modes (manual or automatic), upon conditions to terminate call e.g., MCPTT administrator configured maximum duration for MCPTT private calls has expired or timed out due to MCPTT private call without transmission/reception.
Procedures in figure 10.7.2.2.3.2-1 are the basic signalling control plane procedures for the MCPTT server initiating termination of an ongoing MCPTT private call.
Figure 10.7.2.2.3.2-1: End private call – server initiated
1. It is assumed that MCPTT users on MCPTT client 1 and MCPTT client 2 are already registered for receiving MCPTT service and are involved in private call with or without floor control established either in manual or automatic commencement mode.
2. Upon conditions to terminate call e.g., MCPTT administrator configured maximum duration for MCPTT private calls has expired or timed out due to MCPTT private call without transmission/reception, the MCPTT server decides to initiate termination of an ongoing MCPTT private call between MCPTT client 1 and MCPTT client 2.
3. MCPTT server sends an MCPTT private call end request towards the MCPTT clients 1 and 2 (via SIP core), for tearing down the private call between them.
4. MCPTT users at client 1 and client 2 are notified about the termination of the private call.
5. The MCPTT private call end request receiving MCPTT clients 1 and 2 acknowledge the request with an MCPTT private call end response.
6. MCPTT clients release all the media plane resources used for the private call. Further, if the private call was established with floor control, floor control resources are released and MCPTT clients cannot make further requests for floor control or send media.
10.7.2.3 Private call within several MCPTT systems
10.7.2.3.1 Private call setup in automatic commencement mode – MCPTT users in multiple MCPTT systems
The procedure focuses on the case where an MCPTT user is initiating an MCPTT private call (automatic commencement mode) for communicating with MCPTT user in another MCPTT system with or without floor control enabled.
Procedures in figure 10.7.2.3.1-1 are the procedures for the MCPTT client initiating establishment of MCPTT private call with the chosen MCPTT user.
Pre-conditions:
1. The calling MCPTT user has selected automatic commencement mode for the call; or
2. The called MCPTT client is set to automatic commencement mode.
Figure 10.7.2.3.1-1: Private call setup in automatic commencement mode – users in multiple MCPTT systems
1. It is assumed that MCPTT users on MCPTT client 1 and MCPTT client 2 are already registered for receiving MCPTT service to their respective MCPTT service provider, as per procedure in subclause 10.2.
2. MCPTT user at MCPTT client 1 would like to initiate an MCPTT private call for the chosen MCPTT user. For a private call with floor control, floor control is to be established.
3. MCPTT client 1 sends an MCPTT private call request towards the home MCPTT server 1 (via SIP core) using a service identifier as defined in 3GPP TS 23.228 [5] for MCPTT, for establishing private call with the MCPTT client 2 registered at MCPTT service provider 2. The MCPTT private call request contains the MCPTT id of invited user and an SDP offer containing one or more media types. For a private call with floor control, the MCPTT private call request also contains an element that indicates that MCPTT client 1 is requesting the floor. If the private call request request the floor it may include location information. The MCPTT client 1 may include a requested commencement mode that indicates that the call is to be established in automatic commencement mode if automatic commencement mode is requested by the initiating user.
4. MCPTT server 1 checks whether the MCPTT user at MCPTT client 1 is authorized to initiate the private call. If the MCPTT private call request requested automatic commencement mode then the MCPTT server 1 also checks whether the MCPTT user at MCPTT client 1 is authorized to initiate a call in automatic commencement mode.
5. MCPTT server 1 may provide a progress indication to MCPTT client 1 to indicate progress in the call setup process.
NOTE: Step 5 can occur at any time following step 4, and prior to step 11.
6. If authorized, MCPTT server 1 includes information that it communicates using MCPTT service, offers the same media types or a subset of the media types contained in the initial received request, includes an automatic commencement mode indication if automatic commencement mode was requested by and authorised for the calling user and sends the corresponding MCPTT private call request towards the MCPTT system (via SIP core) of the MCPTT client specified in the original MCPTT private call request (MCPTT client 2) i.e., MCPTT server 2. If location information was included in the private call request, the MCPTT server checks the privacy policy of the MCPTT user to decide if the location information of MCPTT client 1 can be provided to the other user on the call (refer to Annex A.3 "Authorisation to provide location information to other MCPTT users on a call when talking").
7. MCPTT server 2 checks whether the MCPTT user at MCPTT client 2 is authorized to receive a private call.
8. MCPTT server 2 includes information that it communicates using MCPTT service, offers the same media types or a subset of the media types contained in the initial received request, includes a requested automatic commencement mode indication based on a requested automatic commencement mode by the calling user or based upon the setting of the called MCPTT client and sends the received MCPTT private call request towards the MCPTT client specified in the received MCPTT private call request (i.e., MCPTT client 2). If the called MCPTT user has registered to the MCPTT service with multiple MCPTT UEs and has designated the MCPTT UE for receiving the private calls, then the incoming MCPTT private call request is delivered only to the designated MCPTT UE.
9. The receiving MCPTT client 2 notifies the user about the incoming private call.
10. The receiving MCPTT client 2 accepts the private call automatically, and an acknowledgement is sent to the MCPTT server 1 (via SIP core and MCPTT server 2).
11. Upon receiving the MCPTT private call response from MCPTT client 2 accepting the private call request, MCPTT client 1 is informed about successful call establishment.
12. MCPTT client 1 and MCPTT client 2 have successfully established media plane for communication and either user can transmit media. For successful call establishment of a private call with implicit floor control request from MCPTT client 1, floor participant at MCPTT client 1 is granted floor by the floor control server at MCPTT service provider 1, giving it permission to transmit. At the same time floor participant at MCPTT client 2 is informed by the floor control server at MCPTT service provider 1 that the floor is taken.
10.7.2.3.2 Private call setup in manual commencement mode – MCPTT users in multiple MCPTT systems
The procedure focuses on the case where an MCPTT user is initiating an MCPTT private call (manual commencement mode) for communicating with MCPTT user in another MCPTT system with or without floor control enabled.
Procedures in figure 10.7.2.3.2-1 are the procedures for the MCPTT client initiating establishment of MCPTT private call with the selected MCPTT user.
Pre-conditions:
1. The calling MCPTT user has selected manual commencement mode or has not specified a commencement mode for the call; and
2. The called MCPTT client is set to manual commencement mode.
Figure 10.7.2.3.2-1: Private call setup in manual commencement mode – users in multiple MCPTT systems
1. It is assumed that MCPTT users on MCPTT client 1 and MCPTT client 2 are already registered for receiving MCPTT service to their respective MCPTT service provider, as per procedure in subclause 10.2.
2. MCPTT user at MCPTT client 1 would like to initiate an MCPTT private call for the selected MCPTT user. For a private call with floor control, floor control is to be established.
3. MCPTT client 1 sends an MCPTT private call request towards the home MCPTT server 1 (via SIP core), for establishing private call with the MCPTT client 2 registered at MCPTT service provider 2. For a private call with floor control, the MCPTT private call request contains an element that indicates that MCPTT client 1 is requesting the floor. If the call request requests the floor the call request may include location information. The MCPTT client 1 may include a requested commencement mode that indicates that the call is to be established in manual commencement mode if manual commencement mode is requested by the initiating user.
4. MCPTT server 1 checks whether the MCPTT user at MCPTT client 1 is authorized to initiate the private call. The MCPTT server 1 also checks whether the MCPTT user at MCPTT client 1 is authorized to initiate a call in manual commencement mode.
5. If authorized, MCPTT server 1 sends the corresponding MCPTT private call request towards the MCPTT system (via SIP core) of the MCPTT client specified in the original MCPTT private call request (MCPTT client 2) i.e., MCPTT server 2. If location information was included in the private call request, the MCPTT server checks the privacy policy of the MCPTT user to decide if the location information of MCPTT client 1 can be provided to the other user on the call (refer to Annex A.3 "Authorisation to provide location information to other MCPTT users on a call when talking").
6. MCPTT server may provide a progress indication to MCPTT client 1 to indicate progress in the call setup process.
NOTE: Step 6 can occur at any time following step 4, and prior to step 10.
7. The MCPTT server 2 checks whether the MCPTT user at MCPTT client 2 is authorized to receive a private call and also checks the commencement mode setting of MCPTT client 2.
8. The MCPTT server 2 offers the same media types or a subset of the media types contained in the initial received request and sends an MCPTT private call request towards the MCPTT client specified in the received MCPTT private call request (i.e., MCPTT client 2). If the called MCPTT user has registered to the MCPTT service with multiple MCPTT UEs and has designated the MCPTT UE for receiving the private calls, then the incoming MCPTT private call request is delivered only to the designated MCPTT UE.
9. The MCPTT user is alerted. MCPTT client 2 sends an MCPTT ringing to the MCPTT server 1 (via server 2).
10. The MCPTT server 1 sends an MCPTT ringing to MCPTT client 1, indicating that MCPTT client 2 is being alerted.
11. MCPTT user 2 has accepted the call using manual commencement mode (i.e. has taken some action to accept via the user interface) which causes MCPTT client 2 to send an MCPTT private call response to the MCPTT server 1 (via SIP core and MCPTT server 2)
12. Upon receiving the MCPTT private call response from MCPTT client 2 accepting the private call request, MCPTT client 1 is informed about successful call establishment.
13. MCPTT client 1 and client 2 have successfully established media plane for communication and either user can transmit media. For successful call establishment of a private call with implicit floor control request from MCPTT client 1, floor participant at MCPTT client 1 is granted the floor by the floor control server at MCPTT service provider 1, giving it permission to transmit. At the same time floor participant at MCPTT client 2 is informed by the floor control server at MCPTT service provider 1 that the floor is taken.
10.7.2.3.3 Private call release – MCPTT users in multiple MCPTT systems
The procedure in this subclause is for the case where an MCPTT client is requesting to release an ongoing MCPTT private call (with or without floor control) established in either of the two commencement modes (manual or automatic), and the MCPTT users are in multiple MCPTT systems.
Procedures are similar to those described for private call release when MCPTT users are in single MCPTT system as in subclause 10.7.2.2.3.1, with the addition that the MCPTT call end request and the corresponding acknowledgement are routed through the MCPTT server in partner MCPTT system.
10.7.2.4 MCPTT emergency private call
10.7.2.4.1 MCPTT emergency private call commencement
This procedure focuses on the case where an authorized MCPTT user is initiating an MCPTT emergency private call with unicast signalling for communicating with another MCPTT user. An MCPTT client in the MCPTT emergency state gains elevated access privilege for all of the MCPTT user’s mission critical applications.
Procedures in figure 10.7.2.4.1-1 are the procedures for the MCPTT client initiating establishment of an MCPTT emergency private call.
Pre-conditions:
1. Both members of the MCPTT private call belong to the same MCPTT system.
2. The initiating MCPTT client 1 has been configured to send an MCPTT emergency alert prior to initiating an MCPTT emergency private call.
3. Optionally, MCPTT client 1 may use an activated functional alias for the call.
4. The MCPTT server has subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Figure 10.7.2.4.1-1 MCPTT emergency private call
1. The user at the MCPTT client 1 initiates an MCPTT emergency private call. MCPTT client 1 sets its MCPTT emergency state. MCPTT client 1 retains the MCPTT emergency state until explicitly cancelled by the user of MCPTT client 1.
NOTE 1: While MCPTT client 1 is in the emergency state, all MCPTT group and private calls initiated by MCPTT client 1 are initiated as MCPTT emergency calls.
2. MCPTT client 1 sends an MCPTT emergency private call request towards the MCPTT server. The request contains an indication of the MCPTT emergency. MCPTT user at MCPTT client 1 may select a functional alias as calling party address and the MCPTT server verifies whether the provided functional alias can be used. Instead of an MCPTT ID the MCPTT user at MCPTT client 1 may also select a functional alias as called party address, which the MCPTT server replaces by an appropriate MCPTT ID. The MCPTT server records the identity of the MCPTT user that initiated the MCPTT emergency private call until the MCPTT emergency is cancelled. If the MCPTT client is configured to send an MCPTT emergency alert when initiating an MCPTT emergency private call, the request also contains an indication that an MCPTT emergency alert is to be initiated.
NOTE 2: If the MCPTT server detects that the functional alias used as the target of the private call request is simultaneously active for multiple MCPTT users, then the MCPTT server can proceed by selecting an appropriate MCPTT ID based on some selection criteria. This selection of an appropriate MCPTT ID is left to implementation.
3. MCPTT server sends the MCPTT emergency private call request towards the target MCPTT client. The request contains an indication of the in-progress emergency. The request contains an indication of an MCPTT emergency alert if the request from the originator indicated MCPTT emergency alert.
4. The MCPTT user on MCPTT client 2 is notified of the incoming MCPTT emergency private call and may display the functional alias of MCPTT client 1.
NOTE 3: MCPTT client 2 does not set its emergency state as a result of receiving the MCPTT emergency private call.
5. The receiving MCPTT client acknowledges the MCPTT emergency private call request to the MCPTT server.
6. The MCPTT server adjusts the priority of the underlying bearer.
7. The MCPTT server informs MCPTT client 1 about the successful MCPTT emergency private call establishment.
8. MCPTT client 1 and MCPTT client 2 establish the media plane for communication. The MCPTT client 1 can override MCPTT client 2 unless MCPTT client 2 is also in the MCPTT emergency state.
NOTE 4: The priority for the MCPTT emergency private call is retained until cancelled according to system policy (e.g. timeout or call end) or cancelled by an authorized MCPTT user.
NOTE 5: The initiating MCPTT user’s MCPTT emergency state is retained by the system until cancelled as in subclause 10.6.2.6.1.3, or by the emergency alert cancellation procedure specified in 3GPP TS 23.280 subclause 10.10.1.2.2.2. The initiating MCPTT user’s MCPTT emergency state is also retained locally by the MCPTT client until explicitly cancelled by the MCPTT user.
10.7.2.4.2 MCPTT private call emergency upgrade
This procedure describes the case where an authorized MCPTT user is upgrading a private call to an MCPTT emergency private call while the private call is already in progress.
Procedures in figure 10.7.2.4.2-1 are the signalling procedures for the MCPTT client upgrading a private call to an MCPTT emergency private call.
Pre-conditions:
1. Both members of the private call belong to the same MCPTT system.
2. A private call is already in progress.
Figure 10.7.2.4.2-1: MCPTT private call upgrade
1. The MCPTT user at MCPTT client 1 initiates an emergency. MCPTT client 1 sets its MCPTT emergency state. MCPTT client 1 retains the MCPTT emergency state until explicitly cancelled by the user of MCPTT client 1.
NOTE 1: While MCPTT client 1 is in the emergency state, all MCPTT group and private calls initiated by MCPTT client 1 are initiated as MCPTT emergency calls.
2. MCPTT client 1 requests the MCPTT server to upgrade the private call to in-progress emergency by sending an MCPTT emergency request. If configured to send an MCPTT alert when initiating an MCPTT emergency upgrade, the request also contains an indication that an MCPTT alert is to be initiated. The request may contain an indication of an implicit floor request. If the emergency private call request includes an implicit floor reques it may also include location information.
3. The MCPTT server sends the MCPTT emergency request towards MCPTT client 2, the MCPTT client of the other participant. If location information was included in the emergency private call request, the MCPTT server checks the privacy policy of the MCPTT user to decide if the location information of MCPTT client 1 can be provided to the other user on the call (refer to Annex A.3 "Authorisation to provide location information to other MCPTT users on a call when talking").
4. The MCPTT user of MCPTT client 2 is notified of the in-progress emergency of the MCPTT emergency private call.
NOTE 2: MCPTT client 2 does not set its emergency state as a result of receiving the MCPTT emergency private call upgrade.
5. The receiving MCPTT client acknowledges the MCPTT emergency request to the MCPTT server.
6. The MCPTT server adjusts the priority of the underlying bearer for both participants in the private call. The priority is retained until the call ends.
7. The MCPTT server confirms the upgrade request to MCPTT client 1.
8. MCPTT client 1 and MCPTT client 2 continue with the private call, which has been transformed into an MCPTT emergency private call. MCPTT client 1 can override MCPTT client 2 unless MCPTT client 2 is also in the MCPTT emergency state.