6 MCPTT Server – MCPTT Client operation
36.579-33GPPMission Critical (MC) services over LTEPart 3: Mission Critical Push To Talk (MCPTT) Server Application conformance specificationRelease 13TS
6.1 MCPTT Server – MCPTT Client / On-demand Pre-arranged Group Call / Automatic Commencement Mode / Floor Control
6.1.1 Test Purpose (TP)
(1)
with { IUT (MCPTT Server) connected to PLMN1 }
ensure that {
when { the SS-UE1 (MCPTT client ) or SS-UE2 (MCPTT client) initiates registration }
then { IUT (MCPTT Server) initially responds with a SIP 401 Unauthorized message and continues the process by responding to the SS-UE1 (MCPTT client) or SS-UE2 (MCPTT client) with SIP 200 (OK) messages }
}
(2)
with { IUT (MCPTT Server) having registered the clients}
ensure that {
when { the SS (MCPTT Client) initiates a pre-arranged group call with automatic commencement mode }
then { IUT (MCPTT Server) accepts the call from the initiator and establishes the call with all registered users of the group }
}
(3)
with { IUT (MCPTT Server) having established an MCPTT On-demand Pre-arranged Group Call with Automatic Commencement Mode }
ensure that {
when { the SS-UE1 (MCPTT client) or SS-UE2 (MCPTT client) engages in communication }
then { IUT (MCPTT Server) enforces floor control (Floor Taken, Floor Ack, Floor Idle, Floor Granted, Floor Queue Position Info, Floor Deny, Floor Revoke) }
}
(4)
with { IUT (MCPTT Server) having established an MCPTT On-demand Pre-arranged Group Call with Automatic Commencement Mode }
ensure that {
when { the SS-UE1 (MCPTT client) ends the pre-arranged group call }
then { IUT (MCPTT Server) responds by sending a SIP 200 (OK) message to the client ending the call and sends a SIP BYE message to the other participants }
}
6.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 24.379 clause 10.1.1.3.1.1, 10.1.1.3.2, 6.3.2.1.6, 6.3.2.2.8.1, TS 24.380 clause 6.3.2.2, 6.3.5.2.2, 6.3.5.3.3, 6.3.5.5.3, 6.3.5.5.4, 6.3.5.3.5, 6.3.5.5.5, 6.3.5.4.4, 6.3.5.4.7. Unless otherwise stated these are Rel-13 requirements.
[TS 24.379 clause 10.1.1.3.1.1]
In the procedures in this subclause:
1) group identity in an incoming SIP INVITE request refers to the group identity from the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request;
2) emergency indication in an incoming SIP INVITE request refers to the <emergency-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body; and
3) imminent peril indication in an incoming SIP INVITE request refers to the <imminentperil-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body.
Upon receipt of a "SIP INVITE request for originating participating MCPTT function" containing an application/vnd.3gpp.mcptt-info+xml MIME body with the <session-type> element set to a value of "prearranged", the participating MCPTT function:
1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP INVITE request with a SIP 500 (Server Internal Error) response. The participating MCPTT function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24]. Otherwise, continue with the rest of the steps;
NOTE 1: if the SIP INVITE request contains an emergency indication or an imminent peril indication set to a value of "true" and this is an authorised request for originating a priority call as determined by subclause 6.3.2.1.8.1, the participating MCPTT function can according to local policy choose to accept the request.
2) shall determine the MCPTT ID of the calling user from public user identity in the P-Asserted-Identity header field of the SIP INVITE request, and shall authorise the calling user;
NOTE 2: The MCPTT ID of the calling user is bound to the public user identity at the time of service authorisation, as documented in subclause 7.3.
3) if through local policy in the participating MCPTT function, the user identified by the MCPTT ID is not authorised to initiate prearranged group calls, shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response to the SIP INVITE request, with warning text set to "109 user not authorised to make prearranged group calls" in a Warning header field as specified in subclause 4.4;
4) shall validate the media parameters and if the MCPTT speech codec is not offered in the SIP INVITE request shall reject the request with a SIP 488 (Not Acceptable Here) response. Otherwise, continue with the rest of the steps;
5) shall check if the number of maximum simultaneous MCPTT group calls supported for the MCPTT user as specified in the <MaxSimultaneousCallsN6> element of the <MCPTT-group-call> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.384 [50]) has been exceeded. If exceeded, the participating MCPTT function shall respond with a SIP 486 (Busy Here) response with the warning text set to "103 maximum simultaneous MCPTT group calls reached" in a Warning header field as specified in subclause 4.4. Otherwise, continue with the rest of the steps;
NOTE 3: If the SIP INVITE request contains an emergency indication or an imminent peril indication, the participating MCPTT function can by means beyond the scope of this specification choose to allow for an exception to the limit for the maximum simultaneous MCPTT sessions supported for the MCPTT user. Alternatively, a lower priority session of the MCPTT user could be terminated to allow for the new session.
6) if the user identified by the MCPTT ID is not affiliated to the group identified in the "SIP INVITE request for originating participating MCPTT function" as determined by subclause 9.2.2.2.11 and this is an authorised request for originating a priority call as determined by subclause 6.3.2.1.8.1, shall perform the actions specified in subclause 9.2.2.2.12 for implicit affiliation;
7) if the actions for implicit affiliation specified in step 6) above were performed but not successful in affiliating the MCPTT user due to the MCPTT user already having N2 simultaneous affiliations, shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 486 (Busy Here) response with the warning text set to "102 too many simultaneous affiliations" in a Warning header field as specified in subclause 4.4. and skip the rest of the steps.
NOTE 4: N2 is the total number of MCPTT groups that an MCPTT user can be affiliated to simultaneously as specified in 3GPP TS 23.179 [3].
NOTE 5: if the SIP INVITE request contains an emergency indication set to a value of "true" or an imminent peril indication set to a value of "true" and this is an authorised request for originating a priority call as determined by subclause 6.3.2.1.8.1, the participating MCPTT function can according to local policy choose to allow an exception to the N2 limit. Alternatively, a lower priority affiliation of the MCPTT user could be cancelled to allow for the new affiliation.
8) shall determine the public service identity of the controlling MCPTT function associated with the group identity in the SIP INVITE request;
NOTE 6: The public service identity can identify the controlling MCPTT function in the primary MCPTT system or a partner MCPTT system.
NOTE 7: How the participating MCPTT server discovers the public service identity of the controlling MCPTT function associated with the group identity is out of scope of the current release.
9) shall generate a SIP INVITE request as specified in subclause 6.3.2.1.3;
10) shall set the Request-URI to the public service identity of the controlling MCPTT function associated with the group identity which was present in the incoming SIP INVITE request;
11) shall not copy the following header fields from the incoming SIP INVITE request to the outgoing SIP INVITE request, if they were present in the incoming SIP INVITE request:
a) Answer-Mode header field as specified in IETF RFC 5373 [18]; and
b) Priv-Answer-Mode header field as specified in IETF RFC 5373 [18];
12) shall set the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP INVITE request to the MCPTT ID of the calling user;
13) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request from the MCPTT client as specified in subclause 6.3.2.1.1.1;
14) if the received SIP INVITE request contains an application/vnd.3gpp.mcptt-location-info+xml MIME body as specified in clause F.3 and if not already copied, shall copy the contents of the application/vnd.3gpp.mcptt-location-info+xml MIME body received in the SIP INVITE request into an application/vnd.3gpp.mcptt-location-info+xml MIME body included in the outgoing SIP request;
15) if a Resource-Priority header field was included in the received SIP INVITE request, shall include a Resource-Priority header field according to rules and procedures of 3GPP TS 24.229 [4] set to the value indicated in the Resource-Priority header field of the SIP INVITE request from the MCPTT client; and
NOTE 8: The participating MCPTT function will leave verification of the Resource-Priority header field to the controlling MCPTT function.
16) shall forward the SIP INVITE request, according to 3GPP TS 24.229 [4].
Upon receipt of a SIP 302 (Moved Temporarily) response to the above SIP INVITE request, the participating MCPTT function:
1) shall generate a SIP INVITE request as specified in subclause 6.3.2.1.10;
2) shall include an SDP offer based upon the SDP offer in the received SIP INVITE request from the MCPTT client as specified in subclause 6.3.2.1.1.1; and
3) shall forward the SIP INVITE request according to 3GPP TS 24.229 [4].
Upon receipt of a SIP 2xx response in response to the above SIP INVITE request, the participating MCPTT function:
1) if the received SIP 2xx response contains an application/vnd.3gpp.mcptt-info+xml MIME body with an <MKFC-GKTPs> element, shall perform the procedures in subclause 6.3.2.3.2;
2) shall generate a SIP 200 (OK) response as in subclause 6.3.2.1.5.2;
3) shall include in the SIP 200 (OK) response an SDP answer as specified in the subclause 6.3.2.1.2.1;
4) shall include Warning header field(s) that were received in the incoming SIP 200 (OK) response;
5) shall include the public service identity received in the P-Asserted-Identity header field of the incoming SIP 200 (OK) response into the P-Asserted-Identity header field of the outgoing SIP 200 (OK) response;
6) shall include an MCPTT session identity mapped to the MCPTT session identity provided in the Contact header field of the received SIP 200 (OK) response;
7) if the procedures of subclause 9.2.2.2.12 for implicit affiliation were performed in the present subclause, shall complete the implicit affiliation by performing the procedures of subclause 9.2.2.2.13;
8) shall send the SIP 200 (OK) response to the MCPTT client according to 3GPP TS 24.229 [4];
9) shall interact with Media Plane as specified in 3GPP TS 24.380 [5]; and
10) shall start the SIP Session timer according to rules and procedures of IETF RFC 4028 [7].
Upon receipt of a SIP 4xx, 5xx or 6xx response to the above SIP INVITE request, the participating MCPTT function:
1) shall generate a SIP response according to 3GPP TS 24.229 [4];
2) shall include Warning header field(s) that were received in the incoming SIP response;
3) shall forward the SIP response to the MCPTT client according to 3GPP TS 24.229 [4]; and
4) if the implicit affiliation procedures of subclause 9.2.2.2.12 were invoked in this procedure, shall perform the procedures of subclause 9.2.2.2.14;
[TS 24.379 clause 10.1.1.3.2]
In the procedures in this subclause:
1) emergency indication in an incoming SIP INVITE request refers to the <emergency-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body; and
2) imminent peril indication in an incoming SIP INVITE request refers to the <imminentperil-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body.
This subclause covers both on-demand session and pre-established sessions.
Upon receipt of a "SIP INVITE request for terminating participating MCPTT function", the participating MCPTT function:
1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP INVITE request with a SIP 500 (Server Internal Error) response. The participating MCPTT function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24], and shall not continue with the rest of the steps;
NOTE: if the SIP INVITE request contains an emergency indication or an imminent peril indication set to a value of "true" and this is an authorised request for originating a priority call as determined by subclause 6.3.2.1.8.1, the participating MCPTT function can according to local policy choose to accept the request.
2) shall check the presence of the isfocus media feature tag in the URI of the Contact header field and if it is not present then the participating MCPTT function shall reject the request with a SIP 403 (Forbidden) response with the warning text set to "104 isfocus not assigned" in a Warning header field as specified in subclause 4.4, and shall not continue with the rest of the steps;
3) if the Answer-Mode Indication in the application/poc-settings+xml MIME body has not yet been received from the invited MCPTT client as defined in subclause 7.3.3 or subclause 7.3.4, shall reject the request with a SIP 480 (Temporarily Unavailable) response with the warning text set to "146 T-PF unable to determine the service settings for the called user" in a Warning header field as specified in subclause 4.4, and shall not continue with the rest of the steps;
4) shall use the MCPTT ID present in the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request to retrieve the binding between the MCPTT ID and public user identity;
5) if the binding between the MCPTT ID and public user identity does not exist, then the participating MCPTT function shall reject the SIP INVITE request with a SIP 404 (Not Found) response. Otherwise, continue with the rest of the steps;
6) if the SIP INVITE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with an <MKFC-GKTPs> element, shall perform the procedures in subclause 6.3.2.3.2;
7) shall perform the automatic commencement procedures specified in subclause 6.3.2.2.5.1 and according to IETF RFC 5373 [18] if the "SIP INVITE request for terminating participating MCPTT function" does not contain an Answer-Mode header field and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCPTT client as per subclause 7.3.3 or subclause 7.3.4 is set to "auto-answer"; and
8) shall perform the manual commencement procedures specified in subclause 6.3.2.2.6.1 and according to IETF RFC 5373 [18] if the "SIP INVITE request for terminating participating MCPTT function" does not contain an Answer-Mode header field and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCPTT client as per subclause 7.3.3 or subclause 7.3.4 is set to "manual-answer".
[TS 24.379 clause 6.3.2.1.6]
Upon receiving a SIP BYE request from the MCPTT client, the participating MCPTT function:
1) shall interact with the media plane as specified in subclause 6.4 in 3GPP TS 24.380 [5];
2) shall generate a SIP BYE request as specified in 3GPP TS 24.229 [4];
3) shall set the Request-URI to the MCPTT session identity as included in the received SIP BYE request;
4) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP BYE request to the P-Asserted-Identity header field of the outgoing SIP BYE request; and
5) shall send the SIP BYE request toward the controlling MCPTT function, according to 3GPP TS 24.229 [4].
Upon receiving a SIP 200 (OK) response to the SIP BYE request the terminating MCPTT function shall forward a SIP 200 (OK) response to the MCPTT client and shall interact with the media plane as specified in subclause 6.4 in 3GPP TS 24.380 [5] for releasing media plane resources associated with the SIP session with the controlling MCPTT function.
[TS 24.379 clause 6.3.2.2.8.1]
Upon receiving a SIP BYE request from the controlling MCPTT function, the participating MCPTT function:
1) shall interact with the media plane as specified in subclause 6.4 in 3GPP TS 24.380 [5] for releasing media plane resource associated with the SIP session with the controlling MCPTT function;
2) shall generate a SIP BYE request according to 3GPP TS 24.229 [4];
3) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP BYE request to the P-Asserted-Identity header field of the outgoing SIP BYE request; and
4) shall send the SIP BYE request to the MCPTT client according to 3GPP TS 24.229 [4].
Upon receiving a SIP 200 (OK) response to the SIP BYE request the participating MCPTT function:
1) shall send a SIP 200 (OK) response to the SIP BYE request received from the controlling MCPTT function according to 3GPP TS 24.229 [4]; and
2) shall interact with the media plane as specified in 3GPP TS 24.380 [5] for releasing media plane resources associated with the SIP session with the MCPTT client.
[TS 24.380, clause 6.3.2.2]
When an MCPTT call is established a new instance of the floor control server state machine for ‘general floor control operation’ is created.
For each MCPTT client added to the MCPTT call, a new instance of the floor control server state machine for ‘basic floor control operation towards the floor participant’ is added.
If the optional "mc_queueing" feature is supported and has been negotiated as specified in clause 14, the floor control server could queue the implicit floor control request for the media-floor control entity.
The original initial SIP INVITE request or SIP REFER request to establish an MCPTT chat group call or to rejoin an ongoing MCPTT call is not handled as an implicit floor control request message by the floor control server unless explicitly stated in the SIP INVITE request or in the SIP REFER request.
The permission to send media to the inviting MCPTT client due to implicit floor control request is applicable to both confirmed indication and unconfirmed indication.
When the first unconfirmed indication is received from the invited participating MCPTT function (see 3GPP TS 24.379 [2]) the floor control server optionally can give an early indication to send RTP media packets, to the inviting MCPTT client.
If an early indication to send RTP media packets is given to the inviting MCPTT client, the floor participant is granted the permission to send media and the MCPTT server buffers RTP media packets received from the MCPTT client at least until the first invited MCPTT client accepts the invitation or until the RTP media packet buffer exceeds it maximum limit to store RTP media packets.
If the MCPTT server does not support or does not allow media buffering then when an early indication to send RTP media packets is not given to the inviting MCPTT client, the floor participant is granted the permission to send media when the first invited MCPTT client accepts the media.
Before the floor control server sends the first floor control message in the MCPTT call, the floor control server has to assign itself a SSRC identifier to be included in media floor control messages and quality feedback messages if the MCPTT server is supporting that option. A suitable algorithm to generate the SSRC identifier is described in IETF RFC 3550 [3].
The floor participant and the floor control server can negotiate the maximum priority level that the floor participant is permitted to request. The floor control server can pre-empt the current sender based on the negotiated maximum priority level that the floor participant is permitted to request and the priority level included in the Floor Request message.
NOTE: The maximum priority level that a floor participant can use is negotiated as specified in subclause 14.3.3 and is based on group configuration data retrieved by the controlling MCPTT function from the group management server as described in 3GPP TS 24.381 [12] and service configuration data retrieved by the controlling MCPTT function from the configuration management server as described in 3GPP TS 24.384 [13].
The floor participant and the floor control server can negotiate queuing of floor requests using the "mc_queueing" fmtp attribute as described in clause 14. If queuing is supported and negotiated, the floor control server queues the floor control request if a Floor Request message is received when another floor participant has the floor and the priority of the current speaker is the same or higher.
[TS 24.380, clause 6.3.5.2.2]
When a SIP Session is established and if the session is not a temporary group call session or if the session is a temporary group call session and the associated floor participant is an invited MCPTT client (i.e. not a constituent MCPTT group):
NOTE 1: A MCPTT group call is a temporary group session when the <on-network-temporary> element is present in the <list-service> element as specified in 3GPP TS 24.381 [12].
1. if an MCPTT client initiates an MCPTT call with an implicit floor request, and the MCPTT call does not exist yet, the floor control interface towards the MCPTT client in the floor control server:
a. shall initialize a general state machine as specified in subclause 6.3.4.2.2; and
NOTE 2: In the subclause 6.3.4.2.2 the ‘general floor control operation’ state machine will continue with the initialization of the ‘general floor control operation’ state machine.
b. shall enter the state ‘U: permitted’ as specified in the subclause 6.3.5.5.2;
2. if the associated MCPTT client rejoins an ongoing MCPTT call without an implicit floor request or initiates or joins a chat group call without an implicit floor request or attempts to initiate an already existing MCPTT call without an implicit floor request, and
a. if an MCPTT call already exists but no MCPTT client has the permission to send a media, the floor control interface towards the MCPTT client in the floor control server:
i. should send a Floor Idle message to the MCPTT client. The Floor Idle message:
A. shall include a Message Sequence Number field with a Message Sequence Number value increased with 1; and
B. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and
ii. shall enter the state ‘U: not permitted and Floor Idle’ as specified in the subclause 6.3.5.5.2;
b. if an MCPTT call is initiated, the floor control interface towards the MCPTT client in the floor control server:
i. shall enter the state ‘U: not permitted and Floor Idle’ as specified in the subclause 6.3.5.5.2; and
ii. shall initialize a general state machine as specified in subclause 6.3.4.2.2; and
NOTE 3: In the subclause 6.3.4.2.2 the general state machine will continue with the initialization of the general state machine.
c. if another MCPTT client has the permission to send a media, the floor control interface towards the MCPTT client in the floor control server:
i. should send a Floor Taken message to the MCPTT client. The Floor Taken message:
A. shall include the granted MCPTT users MCPTT ID in the Granted Party’s Identity field, if privacy is not requested;
B. shall include a Message Sequence Number field with a <Message Sequence Number> value increased with 1;
C. if the session is a broadcast group call, shall include the Permission to Request the floor field set to ‘0’;
D. if the session is not a broadcast group call, may include the Permission to Request the floor field set to ‘1’; and
E. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications
ii. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the subclause 6.3.5.4.2;
3. if the associated floor participant attempts to initiate an already existing MCPTT call with an implicit floor request, and
a. if no MCPTT client has the permission to send media, the floor control interface towards the MCPTT client in the floor control server:
i. shall processes the implicit floor request as if a Floor Request message was receive as specified in subclause 6.3.4.3.3; and
ii. shall enter the state ‘U: permitted’ as specified in the subclause 6.3.5.5.2;
b. if the MCPTT client negotiated support of queuing floor requests as specified in clause 14 and if another MCPTT client has the permission to send media, the floor control interface towards the MCPTT client in the floor control server:
i. shall set the priority level to the negotiated maximum priority level that the MCPTT client is permitted to request, except for pre-emptive priority, when high priority is used;
NOTE 4: The maximum floor priority the floor participant is permitted to request is negotiated in the "mc_priority" fmtp attribute as specified in clause 14.
NOTE 5: The initial implicit floor request will not result in pre-emption when an MCPTT client is joining an ongoing MCPTT call. If the MCPTT client wants to pre-empt the current MCPTT client that are sending media, an explicit floor request with pre-emptive floor priority is required.
ii. shall insert the MCPTT client into the active floor request queue to the position immediately following all queued floor requests with the same floor priority;
iii. shall send a Floor Queue Position Info message to the MCPTT client. The Floor Queue Position Info message:
A shall include the queue position and floor priority in the Queue Info field; and
B. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications;
iv. should send a Floor Queue Position Info message with the updated status to the MCPTT clients in the active floor request queue which negotiated queuing of floor requests as specified in clause 14, which have requested the queue status, whose queue position has been changed since the previous Floor Queue Position Info message and which is not the joining MCPTT client. The Floor Queue Position Info message:
A shall include the queue position and floor priority in the Queue Info field; and
B. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and
v. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the subclause 6.3.5.4.2; and
c. if the MCPTT client did not negotiate queuing of floor requests and if another MCPTT client has the permission to send a media, the floor control interface towards the MCPTT client in the floor control server:
i. shall send a Floor Taken message to the MCPTT client. The Floor Taken message:
A. shall include the granted MCPTT users MCPTT ID in the Granted Party’s Identity field, if privacy is not requested;
B. shall include a Message Sequence Number field with a Message Sequence Number value increased with 1;
C. if the session is a broadcast group call, shall include the Permission to Request the floor field set to ‘0’;
D. if the session is not a broadcast group call, may include the Permission to Request the floor field set to ‘1’; and
E. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and
ii. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the subclause 6.3.5.4.2; and
4. if the MCPTT client is invited to the MCPTT call and
a. if another MCPTT client has permission to send a media, the floor control interface towards the MCPTT client in the floor control server:
i. should send a Floor Taken message to the MCPTT client. The Floor Taken message:
A. shall include the granted MCPTT users MCPTT ID in the Granted Party’s Identity field, if privacy is not requested;
B. shall include a Message Sequence Number field with a Message Sequence Number value increased with 1;
C. if the session is a broadcast group call, shall include the Permission to Request the floor field set to ‘0’;
D. if the session is not a broadcast group call, may include the Permission to Request the floor field set to ‘1’; and
E. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and
ii. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the subclause 6.3.5.4.2; and
b. if no other MCPTT client has the permission to send a media; the floor control interface towards the MCPTT client in the floor control server:
i. should send a Floor Idle message to the MCPTT client. The Floor Idle message:
A. shall include a Message Sequence Number field with a <Message Sequence Number> value increased with 1; and
B. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and
ii. shall enter the ‘U: not permitted and Floor Idle’ state as specified in the subclause 6.3.5.3.2.
When a SIP Session is established and if the session is a temporary group call session and,
1. if the associated floor participant is a constituent MCPTT group; or
2. if the associated floor participant is the initiator of the temporary group session;
then the floor control interface towards the MCPTT client:
1. shall initialize a general state machine as specified in subclause 6.3.4.2.2, if not already initiated; and
2. shall enter the ‘U: not permitted and initiating’ state as specified in subclause 6.3.5.10.2.
[TS 24.380, clause 6.3.5.3.3]
When a Floor Taken message is received from the floor control server arbitration logic, the floor control interface towards the MCPTT client in the floor control server:
1. shall forward the Floor Taken message to the associated floor participant;
2. may set the first bit in the subtype of the Floor Taken message to ‘1’ (Acknowledgment is required) as described in subclause 8.3.2, and
NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.
3. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the subclause 6.3.5.4.2.
[TS 24.380, clause 6.3.5.5.3]
Upon receiving a Floor Release message from the associated floor participant, the floor control interface towards the MCPTT client in the floor control server:
1. if the first bit in the subtype of the Floor Release message is set to ‘1’ (Acknowledgment is required) as described in subclause 8.3.2, shall send a Floor Ack message. The Floor Ack message:
a. shall include the Message Type field set to ‘4’ (Floor Release); and
b. shall include the Source field set to ‘2’ (the controlling MCPTT function is the source);
2. if an indication that the participant is overriding without revoke is stored,
a. shall forward the Floor Release message to the dual floor control operation state machine of the floor control arbitration logic in the MCPTT server with the first bit in the subtype of the Floor Release message set to ‘0’ (Acknowledgment is not required), if not already set;
b. shall remove the indication that the participant is overriding without revoke; and
c. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the subclause 6.3.5.4.2;
3. if an indication that the participant is overridden without revoke is stored,
a. shall forward the Floor Release message to the general floor control operation state machine of the floor control arbitration logic in the MCPTT server with the first bit in the subtype of the Floor Release message set to ‘0’ (Acknowledgment is not required), if not already set;
b. shall remove the indication that the participant is overridden without revoke; and
c. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the subclause 6.3.5.4.2; and
4. if no indication is stored:
a. shall forward the Floor Release message to the general floor control operation state machine of the floor control arbitration logic in the MCPTT server with the first bit in the subtype of the Floor Release message set to ‘0’ (Acknowledgment is not required), if not already set; and
b. shall remain in the ‘U: permitted’ state.
[TS 24.380, clause 6.3.5.5.4]
Upon receiving the Floor Idle message from the floor control server arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:
1. if the G-bit in the Floor Indicator is set to ‘1’ (Dual Floor) and an indication that the participant is overridden without revoke is stored
a. shall send Floor Idle message to the associated floor participant;
b. shall remove the indication that a participant is overridden without revoke; and
c. shall remain in ‘U: permitted state’;
2. if no indication is stored shall enter the ‘U: not permitted and Floor Idle’ state as specified in the subclause 6.3.5.3.2; and
3. if an indication that the participant is overriding without revoke is stored
a. shall send Floor Idle message to the associated floor participant;
b. shall remove the indication that a participant is overriding without revoke; and
c. shall remain in ‘U: permitted state’.
[TS 24.380, clause 6.3.5.3.5]
When a Floor Granted message is received from the floor control arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:
1. shall forward the Floor Granted messages to the associated floor participant;
2. may set the first bit in the subtype of the Floor Granted message to ‘1’ (Acknowledgment is required) as described in subclause 8.3.2; and
NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.
3. shall enter the state ‘U: permitted’ as specified in subclause 6.3.5.5.2.
[TS 24.380, clause 6.3.5.5.5]
When receiving the Floor Revoke message from the floor control server arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:
1. shall forward the Floor Revoke message to the floor participant;
2. if the Floor Revoke message includes the Track Info field, shall store the Track Info field; and
3. shall enter the state ‘U pending Floor Revoke’ as specified in the subclause 6.3.5.6.2.
[TS 24.380, clause 6.3.5.4.4]
Upon receiving a Floor Request message, without a Floor Indicator field or with the Floor Indicator field included where the D-bit (Emergency call) and the E-bit (Imminent peril call) are set to ‘0’, from the associated floor participant, and if the MCPTT client did not negotiate queuing of floor requests or did not include a priority in the "mc_priority" fmtp attribute as specified in clause 14, the floor control interface towards the MCPTT client in the floor control server:
1. shall send a Floor Deny message to the associated floor participant. The Floor Deny message:
a. shall include in the Reject Cause field the <Reject Cause> value cause #1 (Another MCPTT client has permission);
b. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value;
c. if the Floor Request included a Track Info field, shall include the received Track Info field; and
d. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications;
2. may set the first bit in the subtype of the Floor Deny message to ‘1’ (Acknowledgment is required) as described in subclause 8.3.2; and
NOTE 1: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.
3. shall remain in the ‘U: not permitted and Floor Taken’ state.
Upon receiving a Floor Request message from the associated floor participant and the session is a broadcast group call, the floor control interface towards the MCPTT client in the floor control server:
1. shall send a Floor Deny message to the associated floor participant. The Floor Deny message:
a. shall include in the Reject Cause field the <Reject Cause> value cause #5 (Receive only);
b. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value; and
c. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications;
2. may set the first bit in the subtype of the Floor Deny message to ‘1’ (Acknowledgment is required) as described in subclause 8.3.2; and
NOTE 2: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.
3. shall remain in the ‘U: not permitted and Floor Taken’ state.
Upon receiving a Floor Request message from the associated floor participant and if the MCPTT client negotiated support of queuing of floor requests or included a floor priority in the "mc_priority" or both as described in specified in clause 14 and according to local policy, the floor control interface towards the MCPTT client in the floor control server:
1. shall determine the effective priority level as described in subclause 4.1.1.4 by using the following parameters:
a. the floor priority shall be:
i. the lower of the floor priority included in Floor Request message and the negotiated maximum floor priority that the MCPTT client is permitted to request, if the MCPTT client negotiated floor priority "mc_priority" and floor priority is included in the Floor Request message;
ii. the receive only floor priority, if the MCPTT client negotiated floor priority in the "mc_priority" fmtp attribute and if the negotiated maximum floor priority that the MCPTT client is permitted to request is "receive only";
iii. the default priority, if the MCPTT client negotiated floor priority in the "mc_priority" fmtp attribute, if the negotiated maximum floor priority that the MCPTT client is permitted to request is not receive only and if the floor priority is not included in the Floor Request message; and
iv. the default priority, if the MCPTT client did not negotiate floor priority in the "mc_priority" fmtp attribute; and
b. the type of the call shall be
i. if the Floor Indicator field is included in the message and the D-bit (Emergency call bit) is set to ‘1’, determined to be an emergency call;
ii. if the Floor Indicator field is included in the message and the E-bit (Imminent peril call) is set to ‘1’, determined to be an imminent peril call; and
iii. if the Floor Indicator field is not included in the message or the Floor Indicator field is included and neither the D-bit (Emergency call bit) nor the E-bit (Imminent peril call) is set to ‘1’, determined to be a normal call;
2. if the effective priority is "receive only", the floor control interface towards the MCPTT client in the floor control server:
a. shall send a Floor Deny message to the floor participant. The Floor Deny message:
i. shall include in the Reject Cause field the <Reject Cause> value cause #5 (Receive only) ;
ii. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value;
iii. if the Floor Request included a Track Info field, shall include the received Track Info field; and
iv. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and
b. shall remain in the ‘U: not permitted and Floor Taken’ state;
3. if
a. a Track Info field is included in the Floor Request message, shall use the topmost <Participant Reference> value and the SSRC in the received Floor Request message to check if the floor participant has a queued floor request; or
b. a Track Info field is not included in the Floor Request message, shall use the SSRC in the received Floor Request message to check if the floor participant has a queued floor request;
4. if the floor participant already has a queued floor request with the same effective priority level, the floor control interface towards the MCPTT client in the floor control server:
a. shall send a Floor Queue Position Info message to the requesting MCPTT client, if the MCPTT client negotiated support of queuing of floor requests as specified in clause 14. The Floor Queue Position Info message:
i. shall include the queue position and floor priority in the Queue Info field;
ii. if the Floor Request included a Track Info field, shall include the received Track Info field; and
iii. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and
b. shall remain in the ‘U: not permitted and Floor Taken’ state
5. if the effective priority level is pre-emptive and there are no other pre-emptive requests in the active floor request queue and the effective priority level of the current MCPTT client with permission to send a media is not the pre-emptive priority, the floor control interface towards the MCPTT client in the floor control server:
a. shall forward the Floor Request message to the floor control server arbitration logic indicating that a Floor Request message with pre-emptive priority is received; and
b. shall remain in the ‘U: not permitted and Floor Taken’ state
NOTE 3: The Floor control server arbitration logic initiates revoking the permission to send media towards the current MCPTT client with the permission to send media as specified in the subclause 6.3.4.4.7;
6. if the MCPTT client did not negotiate support of queuing of floor requests as specified in clause 14, the effective priority level is pre-emptive and either other pre-emptive request is queued or the effective priority level of the current MCPTT client with permission to send a media is the pre-emptive priority, the floor control interface towards the MCPTT client in the floor control server:
a. shall send a Floor Deny message to the associated floor participant. The Floor Deny message:
i. shall include in the Reject Cause field the <Reject Cause> value cause #1 (Another MCPTT client has permission);
ii. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value;
iii. if the Floor Request included a Track Info field, shall include the received Track Info field; and
iv. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and
b. shall remain in the ‘U: not permitted and Floor Taken’ state;
7. if the MCPTT client did not negotiate "queuing" and the effective priority level is not pre-emptive, the floor control interface towards the MCPTT client in the floor control server:
a. shall send a Floor Deny message to the associated floor participant. The Floor Deny message:
i. shall include in the Reject Cause field the <Reject Cause> value cause #1 (Another MCPTT client has permission);
ii. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value;
iii. if the Floor Request included a Track Info field, shall include the received Track Info field; and
iv. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and
b. shall remain in the ‘U: not permitted and Floor Taken’ state; and
8. if the MCPTT client negotiated support of queuing of floor requests as specified in clause 14 and the effective priority level is not pre-emptive, the floor control interface towards the MCPTT client in the floor control server:
a. shall insert the MCPTT client into the active floor request queue, if not inserted yet, or update the position of the MCPTT client in the active floor request queue, if already inserted, to the position immediately following all queued requests at the same effective priority level;
b. the floor control server shall send a Floor Queue Position Info message to the floor participant. The Floor Queue Position Info message:
i. shall include the queue position and floor priority in the Queue Info field;
ii. if the Floor Request included a Track Info field, shall include the received Track Info field; and
iii. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications;
c. shall remain in the ‘U: not permitted and Floor Taken’ state; and
d. may set the first bit in the subtype of the Floor Queue Position message to ‘1’ (Acknowledgment is required) as described in subclause 8.3.2.
NOTE 4: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.
[TS 24.380, clause 6.3.5.4.7]
Upon receiving a Floor Queue Position Request message from the associated floor participant, the floor control interface towards the MCPTT client in the floor control server:
1. shall send the Floor Queue Position Info message. The Floor Queue Position Info message:
a. shall include the queue position and floor priority in the Queue Info field;
b. if a Track Info field is included in the Floor Queue Position Info message, shall include the received Track Info field;
c. may include the first bit in the subtype of the Floor Queue Position Info message set to ‘1’ (Acknowledgment is required) as described in subclause 8.3.2; and
NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.
d. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and
3. shall remain in the ‘U: not permitted and Floor Taken’ state.
6.1.3 Test description
6.1.3.1 Pre-test conditions
System Simulator:
– SS-UE1 (MCPTT client)
– SS-UE2 (MCPTT client)
– For the underlying "transport bearer" over which the SS-UE1 (MCPTT client) and SS-UE2 (MCPTT client) and the MCPTT Server will communicate, Parameters are set to the default parameters for the basic E-UTRA Single cell network scenarios, as defined in 3GPP TS 36.508 [22] clause 4.4. The simulated Cell 1 shall belong to PLMN1 (the PLMN specified for MCPTT operation in the MCPTT configuration document).
IUT:
– IUT (MCPTT Server)
– The IUT (MCPTT Server) consists of all sub-systems of the Common Services Core, including the Group Management Server, the Configuration Management Server, the Key Management Server, the Identity Management Server, the HTTP Server, and the SIP AS. The IUT (MCPTT Server) also consists of all sub-systems of the MCPTT Server, including the Media Distribution Function, the MCPTT User Database, the SIP AS, the HTPP Server, the HTTP Client, and the Floor Control Server.
– The IUT (MCPTT Server) is the acting Participating Server and Controlling Server
Preamble:
– The IUT (MCPTT Server) is connected to PLMN1
– The IUT (MCPTT Server) is connected to the SS-UE1 (MCPTT client) and the SS-UE2 (MCPTT client) as defined in TS 36.579-1 [2], Figure 4.2.4.
– SS-UE1 (MCPTT client) and SS-UE2 (MCPTT client) are affiliated with Group A
– The IUT (MCPTT Server) is the controlling server for Group A
6.1.3.2 Test procedure sequence
Table 6.1.3.2-1: Main behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
– |
EXCEPTION: In parallel to the event described in steps 1 to 4 below the SS-UE1 (MCPTT client) user authentication, authorization, and configuration as according to Table 5.1.3.2-1 takes place. |
– |
– |
– |
– |
|
1 |
The SS-UE1 (MCPTT client) sends initial registration for IMS services. |
<– |
SIP REGISTER |
– |
– |
|
2 |
Check: Does the IUT (MCPTT Server) respond with a valid AKAv1-MD5 authentication challenge and security mechanisms supported by the network? |
–> |
SIP 401 Unauthorized |
1 |
P |
|
3 |
The SS-UE1 (MCPTT client) completes the security negotiation procedures, sets up a temporary set of SAs and uses those for sending another REGISTER with AKAv1-MD5 credentials. |
<– |
SIP REGISTER |
– |
– |
|
4 |
Check: Does the IUT (MCPTT Server) send a SIP 200 (OK) to the SS-UE1 (MCPTT client)? |
–> |
SIP 200 (OK) |
1 |
P |
|
5-6 |
Void |
– |
– |
– |
– |
|
– |
EXCEPTION: In parallel to the event described in steps 7 to 10 below the SS-UE2 (MCPTT client) user authentication, authorization, and configuration as according to Table 5.1.3.2-1 takes place. |
– |
– |
– |
– |
|
7 |
The SS-UE2 (MCPTT client) sends initial registration for IMS services. |
<– |
SIP REGISTER |
– |
– |
|
8 |
Check: Does the IUT (MCPTT Server) respond with a valid AKAv1-MD5 authentication challenge and security mechanisms supported by the network? |
–> |
SIP 401 Unauthorized |
1 |
P |
|
9 |
The SS-UE2 (MCPTT client) completes the security negotiation procedures, sets up a temporary set of SAs and uses those for sending another REGISTER with AKAv1-MD5 credentials. |
<– |
SIP REGISTER |
– |
– |
|
10 |
Check: Does the IUT (MCPTT Server) send a SIP 200 (OK) to the SS-UE2 (MCPTT client)? |
–> |
SIP 200 (OK) |
1 |
P |
|
11-12 |
Void |
– |
– |
– |
– |
|
13 |
The SS-UE1 (MCPTT client) initiates an on-demand pre-arranged group call with automatic commencement mode and implicit floor control. |
<– |
SIP INVITE |
– |
– |
|
14 |
Check: Does the IUT (MCPTT Server) send a SIP 100 Trying message to the SS-UE1 (MCPTT client)? |
–> |
SIP 100 Trying |
2 |
P |
|
15 |
Check: Does the IUT (MCPTT Server) send a SIP INVITE to the SS-UE2 (MCPTT client)? |
–> |
SIP INVITE |
2 |
P |
|
16 |
The SS-UE2 (MCPTT client) responds with a SIP 200 (OK) message |
<– |
SIP 200 (OK) |
– |
– |
|
17 |
Check: Does the IUT (MCPTT Server) send a SIP ACK to the SS-UE2 (MCPTT client)? |
–> |
SIP ACK |
2 |
P |
|
18 |
Check: Does the IUT (MCPTT Server) send a SIP 200 (OK) to the SS-UE1 (MCPTT client)? |
–> |
SIP 200 (OK) |
2 |
P |
|
19 |
The SS-UE1 (MCPTT client) responds with a SIP 200 (OK) message |
<– |
SIP ACK |
– |
– |
|
20 |
Check: Does the IUT (MCPTT Server) send a Floor Taken message to the SS-UE2 (MCPTT client) informing the SS-UE2 (MCPTT client) that the floor is taken by SS-UE1 (MCPTT client)? |
–> |
Floor Taken |
3 |
P |
|
21 |
The SS-UE1 (MCPTT client) sends a Floor Release message with an acknowledgement required to release the floor |
<– |
Floor Release |
– |
– |
|
22 |
Check: Does the IUT (MCPTT Server) send a Floor Ack message to the SS-UE1 (MCPTT client) to acknowledge the Floor Release message? |
–> |
Floor Ack |
3 |
P |
|
23 |
Check: Does the IUT (MCPTT Server) send a Floor Idle message to the SS-UE2 (MCPTT client)? |
–> |
Floor Idle |
3 |
P |
|
24 |
Check: Does the IUT (MCPTT Server) send a Floor Idle message to the SS-UE1 (MCPTT client)? |
–> |
Floor Idle |
3 |
P |
|
25 |
The SS-UE1 (MCPTT client) sends a Floor Request message |
<– |
Floor Request |
– |
– |
|
26 |
Check: Does the IUT (MCPTT Server) send a Floor Granted message to the SS-UE1 (MCPTT client) with no acknowledgement required? |
–> |
Floor Granted |
3 |
P |
|
27 |
Check: Does the IUT (MCPTT Server) send a Floor Taken message to the SS-UE2 (MCPTT client) informing the SS-UE2 (MCPTT client) that the floor is taken by SS-UE1 (MCPTT client)? |
–> |
Floor Taken |
3 |
P |
|
28 |
The SS-UE2 (MCPTT client) sends a Floor Request message with a higher priority than SS-UE1 (MCPTT client) |
<– |
Floor Request |
– |
– |
|
29 |
Check: Does the IUT (MCPTT Server) send a Floor Revoke message to the SS-UE1 (MCPTT client)? |
–> |
Floor Revoke |
3 |
P |
|
30 |
The SS-UE1 (MCPTT client) sends a Floor Release message |
<– |
Floor Release |
– |
– |
|
31 |
Check: Does the IUT (MCPTT Server) send a Floor Granted message to the SS-UE2 (MCPTT client) with no acknowledgement required? |
–> |
Floor Granted |
3 |
P |
|
32 |
Check: Does the IUT (MCPTT Server) send a Floor Taken message to the SS-UE1 (MCPTT client) informing the SS-UE1 (MCPTT client) that the floor is taken by SS-UE2 (MCPTT client)? |
–> |
Floor Taken |
3 |
P |
|
33 |
The SS-UE1 (MCPTT client) sends a Floor Request message with a lower priority than SS-UE2 (MCPTT client) and the Floor Indicator F-bit set to 0. |
<– |
Floor Request |
– |
– |
|
34 |
Check: Does the IUT (MCPTT Server) send a Floor Deny message to the SS-UE1 (MCPTT client)? |
–> |
Floor Deny |
3 |
P |
|
35 |
The SS-UE1 (MCPTT client) sends a Floor Request message with a lower priority than SS-UE2 (MCPTT client) and the Floor Indicator F-bit set to 1. |
<– |
Floor Request |
– |
– |
|
36 |
Check: Does the IUT (MCPTT Server) send a Floor Queue Position Info message to the SS-UE1 (MCPTT client)? |
–> |
Floor Queue Position Info |
3 |
P |
|
37 |
The SS-UE1 (MCPTT client) sends a Floor Queue Position Request |
<– |
Floor Queue Position Request |
– |
– |
|
38 |
Check: Does the IUT (MCPTT Server) send a Floor Queue Position Info message to the SS-UE1 (MCPTT client)? |
–> |
Floor Queue Position Info |
3 |
P |
|
39 |
The SS-UE2 (MCPTT client) sends a Floor Release message with no acknowledgement required |
<– |
Floor Release |
– |
– |
|
40 |
Check: Does the IUT (MCPTT Server) send a Floor Granted message to the SS-UE1 (MCPTT client) with no acknowledgement required? |
–> |
Floor Granted |
3 |
P |
|
41 |
Check: Does the IUT (MCPTT Server) send a Floor Taken message to the SS-UE2 (MCPTT client) informing the SS-UE2 (MCPTT client) that the floor is taken by SS-UE1 (MCPTT client)? |
–> |
Floor Taken |
3 |
P |
|
42 |
The SS-UE1 (MCPTT client) sends a Floor Release message with an acknowledgement required to release the floor |
<– |
Floor Release |
– |
– |
|
43 |
Check: Does the IUT (MCPTT Server) send a Floor Ack message to the SS-UE1 (MCPTT client) to acknowledge the Floor Release message? |
–> |
Floor Ack |
3 |
P |
|
44 |
Check: Does the IUT (MCPTT Server) send a Floor Idle message to the SS-UE2 (MCPTT client)? |
–> |
Floor Idle |
3 |
P |
|
45 |
Check: Does the IUT (MCPTT Server) send a Floor Idle message to the SS-UE1 (MCPTT client)? |
–> |
Floor Idle |
3 |
P |
|
46 |
The SS-UE1 (MCPTT client) sends a SIP BYE request |
<– |
SIP BYE |
– |
– |
|
47 |
Check: Does the IUT (MCPTT Server) respond with a SIP 200 (OK) message |
–> |
SIP 200 (OK) |
4 |
P |
|
48 |
Check: Does the IUT (MCPTT Server) send a SIP BYE message to the SS-UE2 (MCPTT client) to end the call? |
–> |
SIP BYE |
4 |
P |
|
49 |
SS-UE2 (MCPTT client) responds with a SIP 200 (OK) message |
<– |
SIP 200 (OK) |
– |
– |
6.1.3.3 Specific message contents
Table 6.1.3.3-1: SIP REGISTER (Step 1, Table 6.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.13-1 condition SIP_REGISTER_INITIAL |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Request-Line |
||||
|
Request-URI |
tsc_MCPTT_PublicServiceId_B |
SIP URI of the home domain name |
||
Table 6.1.3.3-2: SIP REGISTER (Steps 3, 9, Table 6.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.13-1 |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Request-Line |
||||
|
Request-URI |
tsc_MCPTT_PublicServiceId_B |
SIP URI of the home domain name |
||
Table 6.1.3.3-3: SIP REGISTER (Step 7, Table 6.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.13-1 condition SIP_REGISTER_INITIAL |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Request-Line |
||||
|
Request-URI |
tsc_MCPTT_PublicServiceId_B |
The public service identity of the MCPTT server under test |
||
|
From |
||||
|
addr-spec |
||||
|
user-info and host |
px_MCX_SIP_PublicUserId_B_1 |
|||
|
Authorization |
||||
|
username |
px_MCX_SIP_PrivateUserId_B |
|||
Table 6.1.3.3-4: Void
Table 6.1.3.3-5: SIP 200 (OK) (Step 4, Table 6.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1 condition REGISTER-RSP |
Table 6.1.3.3-6: SIP 200 (OK) (Step 10, Table 6.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1 condition REGISTER-RSP |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
P-Associated-URI |
||||
|
addr-spec[1] |
SIP URI |
|||
|
host |
px_MCX_SIP_PublicUserId_B_1 |
|||
Table 6.1.3.3-7: SIP 200 (OK) (Step 16, Table 6.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1 condition INVITE-RSP |
||||||||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
||||||
|
Message-body |
||||||||||
|
MIME body part |
SDP message |
|||||||||
|
MIME-part-body |
SDP message as described in Table 6.1.3.3-7A |
|||||||||
|
MIME body part |
MCPTT-Info |
|||||||||
|
MIME-part-body |
MCPTT-Info message as described in Table 6.1.3.3-7B |
|||||||||
Table 6.1.3.3-7A: SDP in SIP 200 (OK) (Table 6.1.3.3-7)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.1-1 condition SDP_ANSWER |
Table 6.1.3.3-7B: MCPTT-Info in SIP 200 (OK) (Table 6.1.3.3-7)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1 conditions GROUP-CALL, INVITE-RSP |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
mcpttinfo |
||||
|
mcptt-Params |
||||
|
mcptt-calling-user-id |
not present |
|||
|
mcptt-called-party-id |
encrypted <mcptt-called-party-id> with mcpttURI set to px_MCPTT_ID_User_B |
Encrypted element as described in TS 36.579-1 [2] Table 5.5.3.2.1-1A |
||
Table 6.1.3.3-8: SIP 200 (OK) (Step 18, Table 6.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1 condition INVITE-RSP |
||||||||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
||||||
|
Contact |
||||||||||
|
addr-spec |
||||||||||
|
user-info and host |
tsc_MCPTT_PublicServiceId_B |
|||||||||
|
Message-body |
||||||||||
|
MIME body part |
SDP message |
|||||||||
|
MIME-part-body |
SDP message as described in Table 6.1.3.3-8A |
|||||||||
Table 6.1.3.3-8A: SDP in SIP 200 (OK) (Table 6.1.3.3-8)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-1 conditions SDP_ANSWER, IMPLICIT_FLOOR_GRANTED, IMPLICIT_GRANT_REQUESTED |
Table 6.1.3.3-9: Void
Table 6.1.3.3-10: SIP INVITE (Step 13, Table 6.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1 condition MCPTT |
||||||||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
||||||
|
Request-Line |
||||||||||
|
Request-URI |
tsc_MCPTT_PublicServiceId_B |
The public service identity of the MCPTT server under test |
||||||||
|
Session-Expires |
RFC 4028 [30] |
|||||||||
|
generic-param |
"1800" |
The recommended initial value is 1800 in RFC 4028 [30]. |
||||||||
|
Message-body |
||||||||||
|
MIME body part |
SDP message |
|||||||||
|
MIME-part-body |
SDP message as described in Table 6.1.3.3-10A |
|||||||||
|
MIME body part |
MCPTT-Info |
|||||||||
|
MIME-part-body |
MCPTT-Info message as described in Table 6.1.3.3-10B |
|||||||||
Table 6.1.3.3-10A: SDP in SIP 200 (OK) (Table 6.1.3.3-10)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.1-1 conditions SDP_OFFER, IMPLICIT_GRANT_REQUESTED |
Table 6.1.3.3-10B: MCPTT-Info in SIP 200 (OK) (Table 6.1.3.3-10)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1 conditions GROUP-CALL, INVITE_REFER |
Table 6.1.3.3-11: SIP INVITE (Step 15, Table 6.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.2-1 condition MCPTT |
||||||||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
||||||
|
From |
||||||||||
|
addr-spec |
tsc_MCPTT_PublicServiceId_B |
|||||||||
|
To |
||||||||||
|
addr-spec |
px_MCX_SIP_PublicUserId_B_1 |
Default public user ID (IMPU) as stored in the UICC |
||||||||
|
Contact |
||||||||||
|
addr-spec |
||||||||||
|
user-info and host |
tsc_MCPTT_PublicServiceId_B |
|||||||||
|
Message-body |
||||||||||
|
MIME body part |
SDP message |
|||||||||
|
MIME-part-body |
SDP message as described in Table 6.1.3.3-11A |
|||||||||
|
MIME body part |
MCPTT-Info |
|||||||||
|
MIME-part-body |
MCPTT-Info message as described in Table 6.1.3.3-11B |
|||||||||
Table 6.1.3.3-11A: SDP in SIP 200 (OK) (Table 6.1.3.3-11)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-1 conditions INITIAL_SDP_OFFER, SDP_OFFER |
Table 6.1.3.3-11B: MCPTT_Info in SIP 200 (OK) (Table 6.1.3.3-11)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.2-1 conditions GRPUP-CALL |
Table 6.1.3.3-11C: SIP BYE (Step 46, Table 6.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.2.1-1 condition MO_CALL |
Table 6.1.3.3-11D: SIP BYE (Step 48, Table 6.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.2.2-1 condition MT_CALL |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
P-Asserted-Identity |
||||
|
addr-spec |
||||
|
user-info and host |
tsc_MCPTT_PublicServiceId_B |
The URI of the SS |
||
Table 6.1.3.3-12: Floor Taken (Steps 20, 27, 41, Table 6.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.7-1 condition ON-NETWORK |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
Granted Party’s Identity |
|||
|
Granted Party’s Identity |
px_MCPTT_ID_User_A |
||
Table 6.1.3.3-13: Floor Taken (Step 32, Table 6.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.7-1 condition ON-NETWORK |
Table 6.1.3.3-14: Floor Release (Steps 21, 42, Table 6.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.5-1 condition ON-NETWORK, ACK |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
Table 6.1.3.3-14A: Floor Ack (Steps 22, 43, Table 6.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.5-1 condition DOWNLINK |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
Message Type |
|||
|
Message Type |
"00010100" |
Acknowledgement for Floor Release message |
|
Table 6.1.3.3-15: Floor Release (Steps 30, 39, Table 6.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.5-1 condition ON-NETWORK |
Table 6.1.3.3-16: Void
Table 6.1.3.3-17: Floor Request (Steps 25, 35, Table 6.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.2-1 condition ON-NETWORK |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
Floor priority |
"0" |
The lowest priority |
|
Table 6.1.3.3-18: Floor Request (Step 33, Table 6.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.2-1 condition ON-NETWORK |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
Floor priority |
"0" |
The lowest priority |
|
|
Floor Indicator |
|||
|
Floor Indicator |
"1000000000000000" |
bit A=1 (Normal call) bit F=0 (Queuing not supported) |
|
Table 6.1.3.3-19: Floor Request (Step 28, Table 6.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.2-1 condition ON-NETWORK |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
Floor priority |
"12" |
||
Table 6.1.3.3-20: Floor Granted (Steps 26, 40, Table 6.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.3-1 condition ON-NETWORK |
Table 6.1.3.3-21: Floor Granted (Step 31, Table 6.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.3-1 condition ON-NETWORK |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
Floor priority |
"12" |
||
Table 6.1.3.3-22: Void
Table 6.1.3.3-23: Floor Deny (Step 34, Table 6.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.4-1 condition ON-NETWORK |
Table 6.1.3.3-24: Floor Queue Position Info (Steps 36, 38, Table 6.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.10-1 condition ON-NETWORK |
Table 6.1.3.3-25: Floor Queue Position Request (Step 37, Table 6.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.9-1 condition ON-NETWORK |