Content for TS 23.283 Word version: 19.0.0
1…
10…
10.2…
10.3…
10.3.2
10.3.3…
10.3.4…
10.3.5…
10.3.6…
10.3.7…
10.3.8…
10.4…
10.5…
10.6…
10.6.2…
10.6.3…
10.7…
10.8…
10.11…
10.12…
10.14…
10.15…
10.17…
10.4 Private call
10.4.1 Information flows for private calls
10.4.2 Private call setup in automatic commencement mode
10.4.2.1 MCPTT user initiating an MCPTT private call
10.4.2.2 LMR user initiating a private call with MCPTT user
10.4.3 Private call setup in manual commencement mode
10.4.3.1 MCPTT user is initiating an MCPTT private call
10.4.3.2 LMR user initiating a private call with MCPTT user
10.4.4 Private call release
10.4.4.1 MCPTT client initiated
10.4.4.2 MCPTT server initiated
10.4.4.3 LMR user initiated
10.4.5 Encryption of private calls
...
...
10.4 Private call p. 89
10.4.1 Information flows for private calls p. 89
10.4.1.1 General p. 89
The following subclauses define information flows for private calls on the IWF-1 interface. Private call related information flows on reference points other than IWF-1 are defined in TS 23.379.
10.4.1.2 IWF private call request p. 90
Table 10.4.1.2-1 describes the information flow IWF private call request from the MCPTT server to the IWF and from the IWF to the MCPTT server.
| Information element | Status | Description |
|---|---|---|
| MCPTT ID | M | The MCPTT ID of the calling party |
| Functional alias | O | The functional alias associated with the MCPTT ID of the calling party. |
| MCPTT ID (see NOTE 1) | O | The MCPTT ID of the called party |
| Functional alias (see NOTE 1) | 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. |
| Encryption Algorithm | O | Encryption algorithm to use for the call. The field can also indicate whether the encryption algorithm choice is determined from information in the media stream. |
| Encryption mode | M | Whether E2EE will be used. |
| Requested commencement mode | O | An indication of the commencement mode to be used. |
| Implicit floor request
(see NOTE 2) | O | An indication that the user is also requesting the floor. |
| Location | 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. |
| Additional application specific data (see NOTE 3) | O | Some LMR systems use additional information at the application layer. |
|
NOTE 1:
At least one identity shall be present. If both elements are present, the MCPTT ID is used to route the call.
NOTE 2:
This element shall be included only when the originating client requests the floor.
NOTE 3:
This element can be present if the LMR system uses it (like GSM-R). GSM-R uses for example UUI as defined in ETSI TS 103 389 [10] and ETSI TS 102 610 [11].
|
||
10.4.1.3 IWF private call response p. 90
Table 10.4.1.3-1 describes the information flow IWF private call response from the MCPTT server to the IWF and from the IWF to the MCPTT server.
| Information element | Status | Description |
|---|---|---|
| MCPTT ID | M | The MCPTT ID of the calling party |
| MCPTT ID | O | The MCPTT ID of the called party |
| Acceptance confirmation | O | An indication whether the user has positively accepted the call. |
| SDP answer | M | Media parameters selected |
| Result | M | Result of the IWF private call request: success or failure |
| Encryption Algorithm(s) response | O | A list of one or more alternative encryption algorithm(s) to use for the call. |
| Use floor control indication response | O | This element indicates whether the floor control indication in the request is acceptable. |
| Implicit floor request response | O | This element indicates whether the indication that the user is also requesting the floor in the request is acceptable. |
| Additional application specific data (see NOTE) | O | Some LMR systems use additional information at the application layer. |
|
NOTE:
This element can be present if the LMR system uses it (like GSM-R). GSM-R uses for example UUI as defined in ETSI TS 103 389 [10] and ETSI TS 102 610 [11].
|
||
10.4.1.4 IWF ringing p. 91
Table 10.4.1.4-1 describes the information flow IWF ringing from the MCPTT server to the IWF and from the IWF to the MCPTT server.
| 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.4.1.5 IWF call end request p. 91
Table 10.4.1.5-1 describes the information flow IWF call end request from the MCPTT server to the IWF and from the IWF to the MCPTT server.
| Information element | Status | Description |
|---|---|---|
| MCPTT ID | M | The MCPTT ID of the calling party |
| MCPTT ID | M | The MCPTT ID of the called party |
| Additional application specific data (see NOTE) | O | Some LMR systems use additional information at the application layer. |
|
NOTE:
This element can be present if the LMR system uses it (like GSM-R). GSM-R uses for example UUI as defined in ETSI TS 103 389 [10] and ETSI TS 102 610 [11].
|
||
10.4.1.6 IWF call end response p. 92
Table 10.4.1.6-1 describes the information flow IWF call end response from the IWF to the MCPTT server.
| Information element | Status | Description |
|---|---|---|
| MCPTT ID | M | The MCPTT ID of the responding party |
10.4.2 Private call setup in automatic commencement mode p. 92
10.4.2.1 MCPTT user initiating an MCPTT private call p. 92
In this procedure, an MCPTT user is initiating an MCPTT private call (automatic commencement mode) for communicating with a user in an LMR system, with or without floor control enabled.
This subclause is based on the procedure for private call setup in automatic commencement mode - MCPTT users in multiple MCPTT systems described in subclause 10.7.2.3.1 of TS 23.379.
In Figure 10.4.2.1-1, an MCPTT client initiates establishment of an MCPTT private call with an LMR user.
Pre-conditions:
- The calling MCPTT user has selected automatic commencement mode for the call;
- The MCPTT client is registered to the MCPTT service, as per procedure in subclause 10.2 in TS 23.379.
- Optionally, MCPTT client may use an activated functional alias for the call.
- The MCPTT server has subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Step 1.
The MCPTT user at the MCPTT client initiates an MCPTT private call. The MCPTT client sends an MCPTT private call request towards the MCPTT server. The MCPTT private call request contains the MCPTT IDs corresponding to the calling MCPTT party and called LMR party and an SDP offer containing one or more media types. If available, the MCPTT user at the MCPTT client may also include a functional alias. The following parameters are also included that describe the MCPTT client's choices:
Step 2.
- the encryption algorithm;
- the encryption mode (encrypted or not);
- an indication of whether the MCPTT client is requesting the floor, and if the MCPTT client is requesting the floor, location information of the calling MCPTT client may be provided;
- requested commencement mode (automatic in this case); and
- an indication of whether the call is to be full or half duplex (whether to establish floor control).
The MCPTT server checks whether the MCPTT user at the MCPTT client is authorized to initiate the private call and whether the provided functional alias, if present, can be used and has been activated for the user. Because the IWF private call request is requesting automatic commencement mode, the MCPTT server also checks whether the MCPTT user at the MCPTT client is authorized to initiate a call in automatic commencement mode. 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 the MCPTT server proceeds with step 3. If location information was included in the MCPTT private call request, the MCPTT server also checks the privacy policy (authorisation to provide location information to other MCPTT users on a call when talking, as defined in TS 23.379 Annex A.3) of the requesting MCPTT user to decide if the user's location information may be provided to other MCPTT users on the call and the IWF.
Step 3a.
The MCPTT server responds with a functional alias resolution response message that contains the resolved MCPTT ID back to MCPTT client.
Step 3b.
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 1 and sends a new MCPTT private call request towards the resolved MCPTT ID.
Step 4.
If authorized, the MCPTT server sends the IWF private call request that may or may not include location of the requestor, depending on the outcome of the privacy check towards the IWF, including the original parameters and offering the same media types or a subset of the media types contained in the initial received request as per TS 23.379.
Step 5.
The IWF sends an IWF private call response to the MCPTT server, indicating that the IWF does support one of the requested media types. The response indicates success or failure. If the indication is failure, the response may include one or more alternatives to the parameter values contained in step 3.
Step 6.
The MCPTT server forwards the MCPTT private call response to the MCPTT client. If the result parameter indicates success, then the MCPTT client proceeds to step 6. Otherwise, if the parameters returned in the MCPTT private call response are acceptable to the MCPTT client, then the MCPTT client can send a new MCPTT private call request with the new parameters and behaves according to those parameters. The calling MCPTT user may be notified of the change in parameters, for example, that the call is to be without floor control. The MCPTT user can choose to end the call rather than continue with the new parameters. If the parameters returned are not acceptable to the MCPTT client, then the call fails.
Step 7.
The MCPTT client has successfully established media plane for communication to the IWF and either end can transmit media. The MCPTT system initiating the call is responsible of granting the floor, solving competing floor requests and issuing floor revoked indications.
10.4.2.2 LMR user initiating a private call with MCPTT user p. 94
In this procedure, an LMR user is initiating a private call (in automatic commencement mode) for communicating with a user in MCPTT system, with or without floor control enabled.
This subclause is based on the procedure for private call setup in automatic commencement mode - MCPTT users in multiple MCPTT systems described in subclause 10.7.2.3.1 of TS 23.379.
In Figure 10.4.2.2-1, an LMR user initiates establishment of a private call with an MCPTT user.
Pre-conditions:
- The calling LMR user has selected automatic commencement mode for the call;
- The MCPTT client is registered to the MCPTT service, as per procedure in subclause 10.2 in TS 23.379.
- The LMR user at the LMR system has initiated a private call towards an MCPTT user.
- Optionally, LMR user may use an activated functional alias (homed in the MCPTT system) for the call.
- The MCPTT server has subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Step 1.
The IWF sends an IWF private call request towards the MCPTT server. The IWF private call request contains the MCPTT IDs corresponding to the calling LMR party and the called MCPTT party and an SDP offer containing one or more media types. If available, the LMR party homed in the IWF may also include a functional alias. The following parameters are also included that describe the MCPTT client's choices:
Step 2.
- the encryption algorithm;
- the encryption mode (encrypted or not);
- an indication of whether the LMR user is requesting the floor, and if the MCPTT client is requesting the floor, location information of the calling MCPTT client may be provided;
- requested commencement mode (automatic in this case); and
- an indication of whether the call is to be full or half duplex (whether to establish floor control).
The MCPTT server checks whether the MCPTT user at the MCPTT client is authorized and able to receive the private call. Because the IWF private call request is requesting automatic commencement mode, the MCPTT server also checks whether the MCPTT user at the MCPTT client is authorized to receive a call in automatic commencement mode. 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 for which the functional alias is active. The MCPTT server shall also check whether MCPTT client 1 is allowed to use the target functional alias to setup a private call and whether the MCPTT client is allowed to receive a private call from the IWF using the functional alias. If authorized the MCPTT server proceeds with step 3.
Step 3a.
The MCPTT server responds with a functional alias resolution response message that contains the resolved MCPTT ID back to the IWF.
Step 3b.
If the MCPTT server replies with a MCPTT functional alias resolution response message, the IWF abandons the first MCPTT private call request in step 1 and sends a new MCPTT private call request towards the resolved MCPTT ID.
Step 4.
If authorized, the MCPTT server sends the MCPTT private call request towards the MCPTT client, including the original parameters with or without the location of the calling party and offering the same media types or a subset of the media types contained in the initial received request as per TS 23.379.
Step 5.
The MCPTT client sends an MCPTT private call response to the MCPTT server indicating that the MCPTT client does support one of the requested media types. The response indicates success or failure. If the indication is failure, the response may also include one or more alternatives to the parameter values contained in step 3.
Step 6.
The MCPTT server sends the IWF private call response to the IWF offering the same media type as that sent in step 4. If the parameters returned are not acceptable to the IWF, then the call fails. If the parameters returned in the IWF private call response are different but acceptable to the IWF, then the IWF can send a new IWF private call request with the new parameters starting with step 1, which is to essentially restart the call. If there is no change of parameter, then the call proceeds to step 6.
Step 7.
The MCPTT client has successfully established media plane for communication to the IWF and either end can transmit media. The LMR system initiating the call is responsible of granting the floor, solving competing floor requests and issuing floor revoked indications.
10.4.3 Private call setup in manual commencement mode p. 95
10.4.3.1 MCPTT user is initiating an MCPTT private call p. 95
In this procedure, an MCPTT user is initiating an MCPTT private call (manual commencement mode) for communicating with an LMR user via an IWF, with or without floor control enabled.
This subclause is based on the procedure for private call setup in manual commencement mode - MCPTT users in multiple MCPTT systems described in subclause 10.7.2.3.2 of TS 23.379.
In Figure 10.4.3.1-1, an MCPTT client initiates establishment of an MCPTT private call with an LMR user.
Pre-conditions:
- The calling MCPTT user has selected manual commencement mode for the call.
- The MCPTT client is registered to the MCPTT service, as per procedure in subclause 10.2 in TS 23.379.
- Optionally, MCPTT client may use an activated functional alias (homed in the MCPTT system) for the call.
- The MCPTT server has subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Step 1.
The MCPTT user at the MCPTT client would like to initiate an MCPTT private call. The MCPTT client sends an MCPTT private call request towards the MCPTT server. The MCPTT private call request contains the MCPTT IDs corresponding to the calling MCPTT party and called LMR party and an SDP offer containing one or more media types. If available, the MCPTT user at the MCPTT client may also include a functional alias. The following parameters are also included that describe the MCPTT client's choices:
Step 2.
- the encryption algorithm;
- the encryption mode (encrypted or not)
- an indication of whether the MCPTT client is requesting the floor;
- requested commencement mode (manual in this case), and if the MCPTT client is requesting the floor, location information of the calling MCPTT client may be provided; and
- an indication of whether the call is to be full or half duplex (whether to establish floor control).
The MCPTT server checks whether the MCPTT user at the MCPTT client is authorized to initiate the private call and whether the provided functional alias, if present, can be used and has been activated for the user. Because the IWF private call request is requesting manual commencement mode, the MCPTT server also checks whether the MCPTT user at the MCPTT client is authorized to initiate a call in manual commencement mode. 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 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 the MCPTT server proceeds with step 3. If location information was included in the MCPTT private call request, the MCPTT server also checks the privacy policy (authorisation to provide location information to other MCPTT users on a call when talking, as defined in TS 23.379 Annex A.3) of the requesting MCPTT user to decide if the user's location information may be provided to other MCPTT users on the call and the IWF.
Step 3a.
The MCPTT server responds with a functional alias resolution response message that contains the resolved MCPTT ID back to MCPTT client 1.
Step 3b.
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 1 and sends a new MCPTT private call request towards the resolved MCPTT ID.
Step 4.
If authorized, the MCPTT server sends the IWF private call request towards the IWF, including the original parameters that may or may not include location of the requestor, depending on the outcome of the privacy check, and offering the same media types or a subset of the media types contained in the initial received request as per TS 23.379.
Step 5.
The IWF may report failure with an IWF private call response to the MCPTT server. The response may include one or more alternatives to the parameter values contained in step 3. If the IWF does not report failure, the process proceeds with step 6.
Step 6.
The MCPTT server forwards the MCPTT private call response to the MCPTT client. If the result parameter indicates failure, the MCPTT client may abandon the call. If the parameters in the MCPTT private call response are acceptable to the MCPTT client, then the MCPTT client can send a new MCPTT private call request with the new parameters to the MCPTT server and behaves according to those parameters. The calling user may be notified of the change in parameters, for example, that the call is to be without floor control. The calling user may choose to end the call rather than continue with the new parameters.
Step 7.
The receiving IWF sends an IWF ringing to the MCPTT server while waiting for the call to be accepted.
Step 8.
The MCPTT server forwards the MCPTT ringing to the MCPTT client. The MCPTT client may indicate to the MCPTT user that the LMR user has been notified, e.g. by producing ringback audio.
Step 9.
Once the call has been accepted by the called user, the IWF sends an IWF private call response to the MCPTT server. The IWF private call response indicates that the IWF does support one of the requested media types.
Step 10.
The MCPTT server forwards the MCPTT private call response to the MCPTT client. The MCPTT client may indicate to the MCPTT user that the call is connected, e.g. by stopping the ringback audio.
Step 11.
The MCPTT client has successfully established media plane for communication to the IWF. The MCPTT system initiating the call is responsible of granting the floor and solving the competing floor requests, and floor revoked indications.
10.4.3.2 LMR user initiating a private call with MCPTT user p. 97
In this procedure, an LMR user is initiating a private call (in manual commencement mode) for communicating with an MCPTT user via an IWF, with or without floor control enabled.
This subclause is based on the procedure for private call setup in manual commencement mode - MCPTT users in multiple MCPTT systems described in subclause 10.7.2.3.2 of TS 23.379.
In Figure 10.4.3.2-1, an LMR user initiates establishment of a private call with an MCPTT user.
Pre-conditions:
- The calling LMR user has selected manual commencement mode for the call.
- The MCPTT client is registered to the MCPTT service, as per procedure in subclause 10.2 in TS 23.379.
- The LMR user at the LMR system has initiated a private call towards an MCPTT user.
- Optionally, LMR user may use an activated functional alias (homed in the MCPTT system) for the call.
- The MCPTT server has subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Step 1.
The IWF sends an IWF private call request towards the MCPTT server. The IWF private call request contains the MCPTT IDs corresponding to the calling LMR party and called MCPTT party and an SDP offer containing one or more media types. If available, the LMR party homed in the IWF may also include a functional alias. The following parameters are also included that describe the IWF's choices:
Step 2.
- the encryption algorithm;
- the encryption mode (encrypted or not)
- an indication of whether the LMR user is requesting the floor, and if the MCPTT client is requesting the floor, location information of the calling MCPTT client may be provided;
- requested commencement mode (manual in this case); and
- an indication of whether the call is to be full or half duplex (whether to establish floor control).
The MCPTT server checks whether the MCPTT user at the MCPTT client is authorized and able to receive the private call. Because the IWF private call request is requesting manual commencement mode, the MCPTT server also checks whether the MCPTT user at the MCPTT client is authorized to receive a call in manual commencement mode. 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, the MCPTT server proceeds with step 3.
Step 3a.
The MCPTT server responds with a functional alias resolution response message that contains the resolved MCPTT ID back to the IWF.
Step 3b.
If the MCPTT server replies with a MCPTT functional alias resolution response message, the IWF abandons the first MCPTT private call request in step 1 and sends a new MCPTT private call request towards the resolved MCPTT ID.
Step 4.
If authorized, the MCPTT server sends the MCPTT private call request towards the MCPTT client, including the original parameters with or without the location of the calling party and offering the same media types or a subset of the media types contained in the initial received request as per TS 23.379.
Step 5.
The MCPTT client may report failure with an MCPTT private call response to the MCPTT server. The response may include one or more alternatives to the parameter values contained in step 3. If the MCPTT client does not report failure, the process proceeds with step 6.
Step 6.
The MCPTT server forwards the MCPTT private call response to the IWF. If the result parameter indicates failure, the IWF may abandon the call. If the parameters in the IWF private call response are acceptable to the IWF, then the IWF can send a new IWF private call request with the new parameters to the MCPTT server and behaves according to those parameters. The IWF may choose to end the call rather than continue with the new parameters.
Step 7.
The MCPTT client sends an MCPTT ringing to the MCPTT server while waiting for the call to be accepted by the MCPTT user.
Step 8.
The MCPTT server sends an IWF ringing to IWF the while waiting for the call to be accepted.
Step 9.
Once the call has been accepted by the called user, the MCPTT client sends an MCPTT private call response to the MCPTT server. The IWF private call response indicates that the IWF does support one of the requested media types.
Step 10.
The MCPTT sends the IWF private call response to the IWF.
Step 11.
The MCPTT client has successfully established media plane for communication to the IWF. The LMR system initiating the call is responsible of granting the floor, solving competing floor requests and issuing floor revoked indications.
10.4.4 Private call release p. 99
10.4.4.1 MCPTT client initiated p. 99
The procedure describes the case where an MCPTT client requests release of an ongoing MCPTT private call (with or without floor control) that was established in either of the two commencement modes (manual or automatic). This subclause is based upon the subclauses for MCPTT private call release in subclauses 10.7.2.2.3.1 and 10.7.2.3.3 of TS 23.379.
Procedures in Figure 10.4.4.1-1 are the basic signalling control plane procedures for the MCPTT client initiating the release of an ongoing interworked private call.
Pre-conditions:
- The MCPTT user on the MCPTT client is already registered for receiving MCPTT service and is involved in a private call with an LMR user via the IWF with or without floor control and established either in manual or automatic commencement mode, as described in subclause 10.4.2 and subclause 10.4.3.
Step 1.
The user at the MCPTT client would like to release an ongoing interworked private call with the LMR user.
Step 2.
The MCPTT client sends an MCPTT private call end request towards the MCPTT server (via SIP core) for tearing down the private call with the other client. Depending on the reason of the release, the MCPTT client may include additional application specific data in the MCPTT private call end request.
Step 3.
The MCPTT server sends the corresponding IWF call end request towards the IWF, addressed to the MCPTT client ID specified in the original MCPTT private call end request.
Step 4.
The IWF acknowledges the IWF call end request with an IWF call end response sent towards the MCPTT server.
Step 5.
After receiving the MCPTT private call end request acknowledgement from the IWF, the MCPTT server generates an acknowledgement for the MCPTT client's MCPTT private call end request.
Step 6.
The MCPTT client and the IWF 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 the MCPTT client cannot make further requests for floor control or send media.
10.4.4.2 MCPTT server initiated p. 100
The procedure describes the case where an MCPTT server terminates an ongoing interworked private call (with or without floor control) that was established in either of the two commencement modes (manual or automatic). The conditions causing the MCPTT server to terminate the call could include expiry of the MCPTT administrator configured maximum duration for MCPTT private calls or expiry of the maximum time permitted for an MCPTT private call without transmission/reception. This subclause is based upon the subclauses for MCPTT private call release in subclauses 10.7.2.2.3.2 and 10.7.2.3.3 of TS 23.379.
Procedures in Figure 10.4.4.2-1 are the basic signalling control plane procedures for the MCPTT server initiating termination of an ongoing interworked private call.
Pre-conditions:
- The MCPTT user on the MCPTT client is already registered for receiving MCPTT service and is involved in a private call with an LMR user via the IWF with or without floor control and established either in manual or automatic commencement mode, as described in subclause 10.4.2 and subclause 10.4.3.
Step 1.
Upon conditions to terminate call e.g., MCPTT administrator configured maximum duration for MCPTT private calls expiry or time out due to MCPTT private call without transmission/reception, the MCPTT server decides to initiate termination of an ongoing interworking private call between the MCPTT client and the LMR user.
Step 2a.
The MCPTT server sends an MCPTT private call end request towards the MCPTT client (via SIP core) for tearing down the private call.
Step 2b.
The MCPTT server sends a corresponding IWF call end request towards the MCPTT client identity associated with the LMR user
Step 3.
The MCPTT user at the MCPTT client is notified about the termination of the private call.
Step 4.
The MCPTT client and the IWF acknowledge the request.
Step 5.
The MCPTT client and the IWF 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 the MCPTT client cannot make further requests for floor control or send media.
10.4.4.3 LMR user initiated p. 101
The procedure describes the case where either an LMR user or the LMR system is requesting to release an ongoing interworked private call (with or without floor control) and the call established in either of the two commencement modes (manual or automatic). This subclause is based upon the subclauses for MCPTT private call release in subclauses 10.7.2.2.3.1 and 10.7.2.3.3 of TS 23.379.
Procedures in Figure 10.4.4.3-1 are the basic signalling control plane procedures for the LMR user, via the IWF, initiating the release of an ongoing interworked private call.
Pre-conditions:
- The MCPTT user on the MCPTT client is already registered for receiving MCPTT service and is involved in a private call with an LMR user via the IWF with or without floor control and established either in manual or automatic commencement mode, as described in subclause 10.4.2 and subclause 10.4.3.
Step 1.
The LMR system would like to release an ongoing interworked private call with the MCPTT user.
Step 2.
The IWF sends an IWF call end request towards the MCPTT server for tearing down the private call with the MCPTT client. Depending on the reason of the release, the IWF may include additional application specific data in the IWF private call end request.
Step 3.
The MCPTT server sends the corresponding MCPTT private call end request towards the MCPTT client specified in the original IWF call end request.
Step 4.
The MCPTT user is notified about the release of the private call. If additional application specific data is present in the MCPTT private call end request the MCPTT client may react depending on the content of the additional application specific data.
Step 5.
The MCPTT client acknowledges the MCPTT private call end request.
Step 6.
After receiving the MCPTT private call end request acknowledgement from the MCPTT client, the MCPTT server generates an acknowledgement for the IWF's IWF call end request.
Step 7.
The MCPTT client and the IWF 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 the MCPTT client cannot make further requests for floor control or send media.
10.4.5 Encryption of private calls p. 102
Private calls can use MC media encryption (see TS 33.180) between the IWF and the MCPTT client. A private call that uses an LMR vocoder may use LMR E2EE if the calling and called parties have previously been provisioned with the appropriate LMR E2EE keys.
