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.6.2.3  Group call within one MCPTT system

10.6.2.3.1  Group call models
10.6.2.3.1.1  Pre-arranged group call
10.6.2.3.1.1.1  General
A pre-arranged group call is initiated by one of the affiliated group members. The initiation of a pre-arranged group call results in all other affiliated group members being invited. Media plane resources are reserved (on-demand) or a pre-established session is associated during the group call setup procedure and released (if on-demand session) or de-associated (if pre-established session) when the call is released. SIP signalling is used to setup and release pre-arranged group calls.
10.6.2.3.1.1.2  Pre-arranged group call setup
The procedure focuses on the case where an MCPTT client is initiating an MCPTT group call with unicast signalling for communicating with the affiliated MCPTT members of that group.
Procedures in Figure 10.6.2.3.1.1.2-1 are the signalling control plane procedures for the MCPTT client initiating establishment of an MCPTT group call with a pre-arranged group i.e., MCPTT users on client 1, client 2 and client 3 belong to the same group which is defined in the MCPTT group management server.
Pre-conditions:
  1. A pre-arranged group is an MCPTT group that is pre-defined with MCPTT group ID and member list in the group management server. All members of the group belong to the same MCPTT system.
  2. It is assumed that MCPTT users on MCPTT client 1, MCPTT client 2 and MCPTT client 3 are already registered for receiving MCPTT service and affiliated. Optionally, they may have an activated functional alias to be used during the group communication.
  3. Optionally the MCPTT server has subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.
  4. Optionally the MCPTT user on MCPTT client 1 has bound a functional alias to the MCPTT group ID (TS 23.280).
(not reproduced yet)
Figure 10.6.2.3.1.1.2-1: Pre-arranged group call setup
Up
Step 1.
User at MCPTT client 1 would like to initiate an MCPTT group call with a selected group (identified by MCPTT group ID). The MC service user may select a functional alias.
Step 2.
MCPTT client 1 sends a group call request towards the MCPTT server via the SIP core, which hosts the group selected by the user and identified by MCPTT group ID. The group call request also contains the MCPTT group ID and an SDP offer containing the MCPTT client media parameters. If there is a floor request to transmit, then the group call request contains an indication of an implicit floor request. If the MC service user of MCPTT client 1 has selected a functional alias, then the group call request contains that functional alias. If the group call request contains an implicit floor request it may also include location information.
Step 3.
The MCPTT server checks whether the user of MCPTT client 1 is authorized to initiate a group call for the selected group. If authorized and the group call is ongoing for that MCPTT group ID, the MCPTT server adds the requesting MCPTT client 1 to the existing MCPTT group call and notifies the MCPTT client 1 that the MCPTT group call is already in progress. Otherwise, MCPTT server resolves the MCPTT group ID to determine the members of that group and their affiliation status, based on the information from the group management server. The MCPTT server evaluates the applicable group call start criteria defined for this group (e.g. minimum number of affiliated members, specific members affiliated) and determines whether the group call setup can proceed.
If the functional alias is provided only in the group call request, or via binding, the MCPTT server proceeds with the value that is provided. If the functional alias is provided in both the group call request and via binding, it is up to the MCPTT server implementation to determine a value for the functional alias to be used.
If present, the MCPTT server checks whether the provided functional alias is allowed to be used and has been activated for the user.
If location information was included in the group 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 other users on the call (refer to Annex A.3 "Authorisation to provide location information to other MCPTT users on a call when talking").
Step 4.
MCPTT server includes information that it communicates using MCPTT service, offers the same media parameters or a subset of the media parameters contained in the initial received request and sends the corresponding group call request via the SIP core towards the MCPTT clients of each of those affiliated group members. MCPTT users are notified about the incoming group call and the functional alias of the group call initiating user is displayed if present. The MCPTT server indicates whether acknowledgement is required for the call and the functional alias of the group call initiating MC service user may be displayed.
Step 5.
The receiving MCPTT clients accept the group call request, and a group call response is sent to the group host MCPTT server. This response may contain an acknowledgement. The conditions for sending acknowledgement may be based on configuration. The response may also contain a functional alias of the responding MC service user, which is verified (valid and activated for the user) by the MCPTT server.
Step 6.
MCPTT server sends the group call response including the selected media parameters to the MCPTT client 1 through the signalling path to inform about successful call establishment. The response may contain the functional alias, which may be displayed.
Step 7.
If the initiating MCPTT user requires the acknowledgement from affiliated MCPTT group members, and the required MCPTT group members do not acknowledge the call setup within a configured time (the "acknowledged call setup timeout"), then the MCPTT server may proceed with or abandon the call and then notify the initiating MCPTT user that the acknowledgements did not include all required members according to group policy from the group configuration. The MCPTT server may notify the initiating MCPTT user of all MCPTT group members who did not acknowledge the group call request within the configured time. This notification may be sent to the initiating MCPTT user by the MCPTT server more than once during the call when MCPTT users join or leave the MCPTT group call.
Step 8.
MCPTT client 1, client 2 and client 3 have successfully established media plane for communication. MCPTT floor participant 1, floor participant 2 and floor participant 3 exchange floor control information e.g., MCPTT client 1 receives the floor granted information over the established media plane assuming implicit floor control request from MCPTT client 1 while at the same time floor participants at other MCPTT client's receive floor taken information. MCPTT client 1 indicates to the MCPTT user that the floor is available to send media, while the other MCPTT clients in the group call will be receiving that media. If audio cut-in policy is enabled for the MCPTT group, floor arbitration follows the logic defined in subclause 10.9.1.5.
Up
10.6.2.3.1.1.3  Release pre-arranged group callWord‑p. 54
The procedure focuses on the case where an MCPTT server initiates the termination of an ongoing MCPTT group call for all the participants of that group call, since at least one of the termination conditions are met e.g., due to hang time expiry, last participant leaving, second last participant leaving, initiator leaving, or minimum number of affiliated MCPTT group members are not present.
Procedures in Figure 10.6.2.3.1.1.3-1 are the signalling control plane procedures for the MCPTT server initiating termination of an ongoing MCPTT group call.
(not reproduced yet)
Figure 10.6.2.3.1.1.3-1: Release pre-arranged group call
Up
Step 1.
It is assumed that MCPTT users on MCPTT client 1, client 2 and client 3 are already part of the ongoing group call (e.g., as a result of pre-arranged group call setup).
Step 2.
MCPTT server would like to release the MCPTT group call which is ongoing e.g., due to hang time expiry, last participant leaving, second last participant leaving, initiator leaving, or minimum number of affiliated MCPTT group members are not present.
Step 3.
MCPTT server identifies the participants of the ongoing group call and generates group call release request to release ongoing session.
Step 4.
MCPTT server sends a group call release request via SIP core towards each participant of the ongoing group call.
Step 5.
MCPTT users are notified about the release of the group call.
Step 6.
MCPTT client(s) receiving group call release request, acknowledge towards the MCPTT server by sending a group call release response.
Step 7.
MCPTT client 1, client 2 and client 3 have successfully released the floor control and media plane resources associated with the group call that is terminated.
Up
10.6.2.3.1.1.4  Late entry pre-arranged group callWord‑p. 55
Procedures in Figure 10.6.2.3.1.1.4-1 are the signalling control plane procedures for the MCPTT server requesting a newly affiliated member or a member coming back from out of coverage to join an ongoing MCPTT group call.
Pre-condition:
  1. MCPTT group is previously defined on the group management server with MCPTT users affiliated to that group. All members of the group belong to the same MCPTT system.
  2. It is assumed that MCPTT users on MCPTT client 2 to MCPTT client n are on an ongoing call. Optionally, the MCPTT users may use activated functional aliases.
(not reproduced yet)
Figure 10.6.2.3.1.1.4-1: Late entry pre-arranged group call
Up
Step 1.
MCPTT server determines that MCPTT client 1 which is newly affiliated or coming back from out of coverage has to be invited to join an ongoing group call (late entry).
Step 2.
MCPTT server generates group call request including the information such as MCPTT service identifier (possible for the SIP core to route the request to the MCPTT server), MCPTT group ID of the group invited to join, offer one or more media types and sends towards the MCPTT client 1 via SIP core.
Step 3.
MCPTT user at MCPTT client 1 is notified about the incoming group call.
Step 4.
Upon MCPTT user at MCPTT client 1 accepting the incoming group call request, MCPTT client 1 sends the group call response including the selected media types to the MCPTT server through the signalling path. If the incoming group call request is rejected by the MCPTT client 1, the MCPTT server should not resend the group call request. The group call response may also contain a functional alias of MCPTT client 1.
Step 5.
MCPTT client 1 is successfully added to the ongoing group call and MCPTT users at MCPTT client 1 to MCPTT client n may be notified about the MCPTT client 1 joining the group call and the functional alias of MCPTT client 1 may be displayed.
Step 6.
The floor taken with the information of the current talker is sent to MCPTT client 1.
Up
10.6.2.3.1.1.5  Rejoining callWord‑p. 56
Procedures in Figure 10.6.2.3.1.1.5-1 are the signalling control plane procedures for the MCPTT client to rejoin an ongoing MCPTT group call (e.g. coming back from out of coverage).
Pre-conditions:
  • It is assumed that MCPTT users on MCPTT client 2 to MCPTT client n are on an ongoing call. Optionally, the MCPTT users may use activated functional aliases.
(not reproduced yet)
Figure 10.6.2.3.1.1.5-1: Rejoin call
Up
Step 1.
MCPTT client 1 has necessary information for rejoining an ongoing group call, then the MCPTT client 1 initiates group call rejoin request including the ongoing group call information. The group call rejoin request may contain a functional alias of MCPTT client 1 as selected by the MC service user.
Step 2.
MCPTT server checks whether the MCPTT client 1 can rejoin the ongoing call (e.g. based upon affiliation status) and checks the functional alias, if present.
Step 3.
MCPTT client 1 is informed that the group call rejoin is successful by sending a group call rejoin response. If the ongoing group call is emergency or imminent peril group call, the response shall contain emergency or imminent peril indicator.
Step 4.
MCPTT client 1 is successfully added to the ongoing group call and MCPTT users at MCPTT client 1 to MCPTT client n may be notified about the MCPTT client 1 joining the group call and the functional alias of MCPTT client 1 may be displayed.
Step 5.
The floor taken with the information of the current talker is sent to MCPTT client 1.
Up
10.6.2.3.1.2  Chat group callWord‑p. 57
10.6.2.3.1.2.1  General
In a chat group (restricted) call model, the MCPTT user individually joins a group call without being invited. The establishment of a chat group (restricted) call does not result in other group members being invited.
Figure 10.6.2.3.1.2.2-1 describes the basic procedure for the MCPTT client initiating an MCPTT group call which uses the chat group (restricted) call model. Restricted means that only users that have been configured as members of the given group are allowed to join the group communications for the given group.
Chat group join mechanism:
  • Each MCPTT client sends a group join request when the MCPTT user wants to participate in the group communication for the group. (This message does not impact the MCPTT user's membership in the group; the MCPTT server will verify that the MCPTT user is an authorized member of the group.)
  • The group join request may include a request to transmit. If the group join request includes a request to transmit it may also include location information. It is assumed that the group join request will be delivered from MCPTT client to MCPTT server using SIP.
  • If location information was included in the group join 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 other users on the call (refer to Annex A.3 "Authorisation to provide location information to other MCPTT users on a call when talking").
  • The group join request is used to indicate to the MCPTT server that the MCPTT user associated with the given MCPTT client wishes to participate i.e. begin to receive media from or send media to the group.
  • The group join request shall cause the MCPTT server to generate an implicit affiliation for the MCPTT user to the group, if the user is not already affiliated to the group.
  • The group join request contains the information needed to negotiate media parameters (on demand) or to associate a pre-established session between MCPTT server and MCPTT client for the group call. The group join request can take the form of a SIP invite.
  • A selected functional alias is not changed by a MCPTT client during the whole participation within a chat group call, i.e. a MCPTT client uses the same functional alias selected when joining the chat group call until the chat group call is released or the MCPTT client leaves the chat group call.
Subsequent participation in a group call when the group is using the chat model:
  • Once an MCPTT client successfully joins a group call which is using the chat model, the MCPTT client connects to the media plane for the call if the call is currently ongoing.
  • If the MCPTT group call is not currently ongoing (i.e.: when MCPTT clients on the group call are not sending or receiving media, and the time out between floor control exchanges has expired) then the newly joined MCPTT client will only have pre-established its media parameters for the call.
  • If the newly joined MCPTT user wishes to transmit media (start or re-start the call) to the other joined users of the group using the chat model, then the MCPTT client shall use a normal floor control procedure for requesting the floor.
  • Since subsequent group call media transmissions are controlled using floor control signalling, additional SIP signalling messages may not be required for subsequent call stop and start.
  • Each request to transmit from an MCPTT user could be viewed as a new instance of a group call for the given group when the floor idle timer expires and no media is present for an extended time.
  • The MCPTT server may tear down the media plane between successive group calls using the chat model, or the MCPTT server may allow the media plane to remain up between successive group calls using the chat model depending on resources.
Leaving and releasing a chat group:
  • When a user wants to leave a chat group call, the client shall send a group call leave request to the server and release the media plane.
  • The server can release a chat group call by sending a group call release to all joined clients. A server initiated release also releases the media plane for all joined clients.
Up
10.6.2.3.1.2.2  Chat group call setupWord‑p. 58
MCPTT client 1, client 2, and client 3 are served by the home MCPTT service provider in Figure 10.6.2.3.1.2.2-1.
Pre-condition:
  1. MCPTT user 2 and MCPTT user 3 have previously joined (affiliated) to the group. MCPTT client 1, client 2, and client 3 are registered and all users (MCPTT user 1, user 2, and user 3) have been authenticated and authorized to use the MCPTT service.
  2. MCPTT client 1, MCPTT client 2 and MCPTT client 3 may have activated functional alias(es) configured to be used during the group call communication. No call is currently in progress for the group.
  3. Optionally the MCPTT user on MCPTT client 1 has bound a functional alias to the MCPTT group ID (TS 23.280).
(not reproduced yet)
Figure 10.6.2.3.1.2.2-1: MCPTT chat group call
Up
Step 1.
MCPTT user 1 indicates to join the group communication for the group. This may include a request to transmit.
Step 1a.
MCPTT client 1 sends a group join request with the MCPTT group ID of the desired group. It contains the MCPTT user's MCPTT ID, the MCPTT client media parameters and optionally a functional alias. If there is a request to transmit, then the group joint request contains an indication of an implicit floor request. If the group join request includes an implicit floor request it may also include location information.
Step 1b.
The MCPTT server receives the group join request. MCPTT server generates an implicit affiliation (if the MCPTT user is not already affiliated to the group) and verifies that MCPTT user 1 is authorized to affiliate to the group by following the affiliation procedure (subclause 10.8.3 in TS 23.280).
If the functional alias is provided only in the group call request, or via binding, the MCPTT server proceeds with the value that is provided. If the functional alias is provided in both the group call request and via binding, it is up to the MCPTT server implementation to determine a value for the functional alias to be used.
If present, the MCPTT server checks whether the provided functional alias is allowed to be used and has been activated for the user.
If location information was included in the group join 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 other users on the call (refer to Annex A.3 "Authorisation to provide location information to other MCPTT users on a call when talking").
Step 1c.
The MCPTT server replies with a group join response indicating the acceptance of the group join request and also returns the MCPTT server selected media parameters for the group call in the group join response.
Step 2.
If MCPTT user 1 requests to transmit, the MCPTT server establishes the media plane (if not already established) for the call. The associated floor participants for MCPTT client 1, client 2, and client 3 use the floor control procedure to initiate the call. E.g., the floor participant for MCPTT client 1 receives the MCPTT floor grant. The corresponding floor participants for MCPTT client 2 and MCPTT client 3 receive the MCPTT floor taken. If present, the functional alias of MCPTT client 1, MCPTT client 2 and MCPTT client 3 are displayed where appropriate.
Step 3.
Floor control will continue to be used by the floor participants associated with MCPTT client 1, MCPTT client 2 and MCPTT client 3 for the duration of the call. Media plane signalling using floor control will be used for subsequent calls for the group as long as one or more users are affiliated. If audio cut-in policy is enabled for the MCPTT group, floor arbitration follows the logic defined in subclause 10.9.1.5.
Up
10.6.2.3.1.2.3  Release chat group callWord‑p. 60
The procedure describes the case where the MCPTT server releases an ongoing MCPTT group call for all the participants of that group call, since at least one of the conditions for release are met e.g. due to hang time expiry, last participant leaving, second last participant leaving, initiator leaving, or the number of affiliated MCPTT group members is below the minimum number permitted.
Procedures in Figure 10.6.2.3.1.2.3-1 are the procedures for the MCPTT server initiating the release of an ongoing MCPTT group call.
The following precondition applies:
    - A group call is ongoing between MCPTT clients 1, 2 and 3
(not reproduced yet)
Figure 10.6.2.3.1.2.3-1: Release chat group call
Up
Step 1.
MCPTT server would like to release the MCPTT group call which is ongoing e.g., due to hang time expiry, last participant leaving, second last participant leaving, initiator leaving, or minimum number of affiliated MCPTT group members are not present.
Step 2.
MCPTT server identifies the participants of the ongoing group call and generates group call release request to release the ongoing session.
Step 3.
MCPTT server sends a group call release request towards each participant of the ongoing group call.
Step 4.
MCPTT users are notified about the release of the group call.
Step 5.
Optionally the MCPTT client(s) receiving group call release request, may send a group call release response to the MCPTT server.
Step 6.
MCPTT client 1, client 2 and client 3 release the floor control and media plane resources associated with the group call that is released. Successful release of the group call does not affect the status of affiliation of any of the clients.
Up
10.6.2.3.1.2.4  Late entry chat group call, newly joined group memberWord‑p. 61
Procedures in Figure 10.6.2.3.1.2.4-1 are those for a group member entering an ongoing MCPTT group call, i.e. performing a late entry.
Pre-conditions:
  1. MCPTT user 2 and MCPTT user 3 have previously joined to the group. MCPTT client 1, client 2, and client 3 are registered and all users (MCPTT user 1, user 2, and user 3) have been authenticated and authorized to use the MCPTT service.
  2. MCPTT client 1, MCPTT client 2 and MCPTT client 3 may have activated functional alias(es) configured to be used during the group call communication. MCPTT users using MCPTT client 2 and MCPTT client 3 are in an ongoing group call. MCPTT client 1 has not yet joined the group call. Optionally, the MCPTT users may use activated functional aliases.
  3. MCPTT user 1 indicates to join the group communication for the group.
  4. Optionally the MCPTT user on MCPTT client 1 has bound a functional alias to the MCPTT group ID (TS 23.280).
(not reproduced yet)
Figure 10.6.2.3.1.2.4-1: Late entry of a newly joined group member
Up
Step 1.
MCPTT client 1 sends a group join request with the MCPTT group ID of the desired group. It contains the MCPTT user's MCPTT ID, the MCPTT client media parameters and optionally a functional alias. If there is a request to transmit, then the group joint request contains an indication of an implicit floor request.
Step 2.
The MCPTT server receives the group join request. MCPTT server generates an implicit affiliation (if the MCPTT user is not already affiliated to the group) and verifies that MCPTT user 1 is authorized to affiliate to the group.
If the functional alias is provided only in the group call request, or via binding, the MCPTT server proceeds with the value that is provided. If the functional alias is provided in both the group call request and via binding, it is up to the MCPTT server implementation to determine a value for the functional alias to be used.
If present, the MCPTT server checks whether the provided functional alias is allowed to be used and has been activated for the user.
Step 3.
The MCPTT server replies with a group join response indicating the acceptance of the group join request.
Step 4.
Media plane between MCPTT client 1 and MCPTT server is established using media plane control signalling.
Step 5.
MCPTT users at MCPTT client 2 and MCPTT client 3 may be notified about the MCPTT client 1 joining the group call. The functional aliases of MCPTT client 1 is displayed, if present.
Step 6.
The MCPTT server sends a floor taken (for the current talker) to MCPTT client 1.
Step 7.
Floor control will continue to be used by the floor participants associated with MCPTT client 1, MCPTT client 2 and MCPTT client 3.
Up
10.6.2.3.1.2.4aVoid
10.6.2.3.1.2.4bVoid
10.6.2.3.1.2.5  Late entry chat group call, MCPTT client coming back from out of coverageWord‑p. 63
Procedures in Figure 10.6.2.3.1.2.5-1 are those for an MCPTT client coming back from out of coverage during an ongoing MCPTT group call.
Pre-conditions:
  1. MCPTT client 1, MCPTT client 2 and MCPTT client 3 may have activated functional alias(es) configured to be used during the group call communication. MCPTT users using MCPTT client 1, MCPTT client 2 and MCPTT client 3 are in an ongoing group call when MCPTT client1 goes out of radio coverage.
  2. MCPTT client1 returns from out of coverage while the group call is still ongoing.
(not reproduced yet)
Figure 10.6.2.3.1.2.5-1: Late entry of a MCPTT client returning from out of coverage
Up
Step 1.
MCPTT client 1 or MCPTT server detects that MCPTT client 1 has returned from out of coverage.
Step 2.
Media plane between MCPTT client 1 and MCPTT server is re-established using media plane control signalling.
Step 3.
MCPTT server sends a floor taken (for the current talker) to MCPTT client 1.
Step 4.
MCPTT users at MCPTT client 2 and MCPTT client 3 may be notified about the MCPTT client 1 returning to the group call. The functional aliases of MCPTT client 1 is displayed, if present.
Step 5.
Floor control will continue to be used by the floor participants associated with MCPTT client 1, MCPTT client 2 and MCPTT client 3.
Up

Up   Top   ToC