Figure 10.6.2.4.1.1.1-1 illustrates the originating side group call involving groups from multiple MCPTT systems. It considers the scenario for group hierarchies and non-broadcast temporary groups formed by group regroup. The protocol followed may be SIP.
Pre-conditions:
-
The security aspects of sharing the user information between primary and partner MCPTT systems shall be governed as per the service provider agreement between them. In this case, we consider the partner MCPTT system does not share their users' information to the primary MCPTT system.
-
The MCPTT user belongs to an MCPTT group hosted by the primary MCPTT system.
-
A non-broadcast temporary group is formed by authorized MCPTT user/dispatcher by the group regroup procedure (subclause 10.2.4.2 in TS 23.280) and identified via a temporary MCPTT group ID.
-
The affiliated MCPTT group members of the constituent MCPTT groups have been implicitly affiliated to the temporary group.
-
The authorized MCPTT user/dispatcher created the temporary group on the MCPTT server of the primary MCPTT system.
-
The constituent groups of the temporary group may belong to MCPTT servers of the partner MCPTT systems.
Step 1.
The affiliated MCPTT user via MCPTT client initiates a group call with an MCPTT group ID. A group call request message with the MCPTT group ID is routed to the MCPTT server of the primary MCPTT system, which owns the group and is where the authorized MCPTT user/dispatcher created the temporary group. If the group call is for a temporary group formed by the group regroup procedure, the MCPTT group ID will be a temporary MCPTT group ID.
Step 2.
The MCPTT server of the primary MCPTT system gets the group information (either from group management server or itself) including the constituent MCPTT groups' identities, accessible group members list of the constituent groups, and other related data.
Step 3.
The MCPTT server of the primary MCPTT system initiates directly a call request to the accessible group members using the detailed user information and/or location information. The group members upon receipt of the call request may accept or reject the call.
Step 4.
The MCPTT server of the primary MCPTT system may not have access to group members' information of the constituent group belonging to the partner MCPTT system. For such group members, the MCPTT server of the primary MCPTT system initiates a group call request message to the MCPTT server of the partner MCPTT system with the target group's MCPTT group ID information.
Step 5.
The MCPTT server of the partner MCPTT system further initiates a call request to the constituent group's members as described in step 3.
Step 6.
The MCPTT server of the partner MCPTT system provides a group call response to the MCPTT server of the primary MCPTT system with success or failure result and/or detailed reason information if there is a failure.
Step 7.
The MCPTT server of the primary MCPTT system provides a group call response message to the MCPTT client of the affiliated MCPTT user upon receiving responses to the call requests sent to members of primary and partner MCPTT systems. The group call response message will consist of the success or failure result and/or detailed reason information if there is a failure.
Step 8.
Upon successful call setup completion a group call is established for the group members from constituent groups of multiple MCPTT servers.
The procedure in
Figure 10.6.2.4.1.1.2-1 illustrates the terminating side group call involving groups from multiple MCPTT systems. It considers the scenario for group hierarchies and non-broadcast temporary groups formed by group regroup. The protocol followed may be SIP.
Step 1.
The MCPTT server of the primary MCPTT system sends the group call request message to the MCPTT server(s) of the partner MCPTT system.
Step 2.
The MCPTT server of the partner MCPTT system determines whether to forward the group call request message to the MCPTT client(s) based on the user affiliation.
Step 3.
The MCPTT server of the partner MCPTT system forwards the group call request message to MCPTT client(s). The MCPTT server indicates whether acknowledgement is required for the call.
Step 4.
The MCPTT user is notified about the incoming MCPTT group call.
Step 5.
The receiving MCPTT client(s) accept the group call request and a group call response message is sent to the MCPTT server of the partner MCPTT system. This response may contain an acknowledgement. The conditions for sending acknowledgement may be based on configuration.
Step 6.
The MCPTT server of the partner MCPTT system forwards the group call response message to the MCPTT server of the primary MCPTT system (i.e. group hosting MCPTT server for the group call involving groups from multiple MCPTT systems).