7 Registration and service authorisation

24.3793GPPMission Critical Push To Talk (MCPTT) call controlProtocol specificationRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.1 General

This clause describes the procedures for SIP registration and MCPTT service authorization for the MCPTT client and the MCPTT service. The MCPTT UE can use SIP REGISTER or SIP PUBLISH for MCPTT service settings to perform service authorization for MCPTT. The decision which method to use is based on implementation and on availability of an access-token received as outcome of the user authentication procedure as described in 3GPP TS 24.482 [49].

If another MC service client (e.g. MCVideo, MCData) is operating at the same time on the same MC UE as the MCPTT client, then the MCPTT client shares the same SIP registration as the other MC service clients. The SIP REGISTER procedures in this clause are combined with the SIP REGISTER procedures for the other operating MC service clients to create a single SIP REGISTER request. If other MC service clients are already operating when the MCPTT client registers, then a re-registration is performed containing the parameters for the other operating MC services.

Although the access-token can be the same for the MCPTT service as for other MC services when performing service authorization for MCPTT along with other MC services using SIP REGISTER multipart MIME bodies for each MC service are included in the SIP REGISTER request. The MCPTT server can therefore receive multipart MIME bodies in the SIP REGISTER request. Multiple contact addresses (one per MC service client) can be included in a SIP REGISTER request provided they all contain the same IP address and port number (see 3GPP TS 24.229 [4] for further details of including multiple contact addresses in a single SIP REGISTER request).

If the MCPTT client logs off from the MCPTT service but other MC service clients are to remain registered the MC UE performs a re-registration as specified in 3GPP TS 24.229 [4] without the g.3gpp.mcptt media feature tag and the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" in the Contact header field of the SIP REGISTER request but with the parameters for the remaining operating MC service clients.

7.2 MCPTT client procedures

7.2.1 SIP REGISTER request for service authorisation

When the MCPTT client performs SIP registration for service authorisation the MCPTT client shall perform the registration procedures as specified in 3GPP TS 24.229 [4].

The MCPTT client shall include the following media feature tags in the Contact header field of the SIP REGISTER request:

1) the g.3gpp.mcptt media feature tag; and

2) the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt".

NOTE 1: If the MCPTT client logs off from the MCPTT service but the MCPTT UE remains registered the MCPTT UE performs a re-registration as specified in 3GPP TS 24.229 [4] without both the g.3gpp.mcptt media feature tag and the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" in the Contact header field of the SIP REGISTER request.

If the MCPTT client supports MCPTT service continuity, then the MCPTT client shall follow the IMS registration procedures for PS to PS service continuity as specified in clause 6.2.2 of 3GPP TS 24.237 [58].

If the MCPTT client, upon performing SIP registration:

1) has successfully finished the user authentication procedure as described in 3GPP TS 24.482 [49];

2) has available an access-token;

3) based on implementation decides to use SIP REGISTER for service authorization;

4) confidentiality protection is disabled as specified in clause 6.6.2.3.1; and

5) integrity protection is disabled as specified in clause 6.6.3.3.1;

then the MCPTT client shall include in the SIP REGISTER request an application/vnd.3gpp.mcptt-info+xml MIME body as defined in Annex F.1 with:

1) the <mcptt-access-token> element set to the value of the access token received during the user authentication procedures; and

2) the <mcptt-client-id> element set to the value of the MCPTT client ID of the originating MCPTT client.

NOTE 2: The access-token contains the MCPTT ID of the user.

If the MCPTT client, upon performing SIP registration:

1) has successfully finished the user authentication procedure as described in 3GPP TS 24.482 [49];

2) has an available access-token;

3) based on implementation decides to use SIP REGISTER for service authorization; and

4) either confidentiality protection is enabled as specified in clause 6.6.2.3.1 or integrity protection is enabled as specified in clause 6.6.3.3.1;

then the MCPTT client:

1) shall include an application/mikey MIME body with the CSK as MIKEY-SAKKE I_MESSAGE as specified in 3GPP TS 33.180 [78] in the body of the SIP REGISTER request;

2) if confidentiality protection is enabled as specified in clause 6.6.2.3.1, shall include in the body of the SIP REGISTER request, an application/vnd.3gpp.mcptt-info+xml MIME body with the following clarifications:

a) shall encrypt the received access-token using the client server key (CSK) and include the <mcptt-access-token> element set to the encrypted access-token, as specified in clause 6.6.2.3.3; and

b) shall encrypt the MCPTT client ID of the originating MCPTT client and include the <mcptt-client-id> element set to the encrypted MCPTT client ID;

3) if confidentiality protection is disabled as specified in clause 6.6.2.3.1, shall include an application/vnd.3gpp.mcptt-info+xml MIME body as defined in Annex F.1 with:

a) the <mcptt-access-token> element set to the value of the access token received during the user authentication procedures; and

b) the <mcptt-client-id> element set to the value of the MCPTT client ID of the originating MCPTT client; and

4) if integrity protection is enabled as specified in clause 6.6.3.3.1, shall use the CSK to integrity protect the application/vnd.3gpp.mcptt-info+xml MIME body by following the procedures in clause 6.6.3.3.3.

7.2.1AA SIP REGISTER request without service authorisation

When the MCPTT client performs SIP registration without service authorisation the MCPTT client shall perform the registration procedures as specified in 3GPP TS 24.229 [4].

The MCPTT client shall include the following media feature tags in the Contact header field of the SIP REGISTER request:

1) the g.3gpp.mcptt media feature tag; and

2) the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt".

NOTE: If the MCPTT client logs off from the MCPTT service but the MCPTT UE remains registered the MCPTT UE performs a re-registration as specified in 3GPP TS 24.229 [4] without both the g.3gpp.mcptt media feature tag and the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" in the Contact header field of the SIP REGISTER request.

7.2.1A Common SIP PUBLISH procedure

This procedure is only referenced from other procedures.

When populating the SIP PUBLISH request, the MCPTT client shall:

1) shall set the Request-URI to the public service identity identifying the participating MCPTT function serving the MCPTT user;

2) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), in a P-Preferred-Service header field according to IETF RFC 6050 [9];

3) shall set the Event header field to the "poc-settings" value; and

4) shall set the Expires header field according to IETF RFC 3903 [37], to 4294967295, if the MCPTT user is not removing the MCPTT service settings, otherwise to remove the MCPTT service settings the MCPTT client shall set the Expires header field to zero.

NOTE 1: 4294967295, which is equal to 2³²-1, is the highest value defined for Expires header field in IETF RFC 3261 [24].

NOTE 2: The expiration timer of the MCPTT client service settings is only applicable for the MCPTT client service settings from the MCPTT client that matches the Instance Identifier URN. The expiration timer of MCPTT user service settings is also updated in the MCPTT server if expiration timer of MCPTT client service settings is updated in the MCPTT server.

NOTE 3: Removing the MCPTT service settings by setting the Expires header field to zero, logs off the MCPTT client from the MCPTT service.

7.2.2 SIP PUBLISH request for service authorisation and MCPTT service settings

If based on implementation the MCPTT client decides to use SIP PUBLISH for MCPTT server settings to also perform service authorization and

1) has successfully finished the user authentication procedure as described in 3GPP TS 24.482 [49]; and

2) has available an access-token;

then the MCPTT client:

1) shall perform the procedures in clause 7.2.1A;

2) if confidentiality protection is disabled as specified in clause 6.6.2.3.1 and integrity protection is disabled, shall include in the body of the SIP PUBLISH request, an application/vnd.3gpp.mcptt-info+xml MIME body as specified in Annex F.1 with the <mcptt-access-token> element set to the value of the access token received during the user authentication procedures;

3) if either confidentiality protection is enabled as specified in clause 6.6.2.3.1 or integrity protection is enabled as specified in clause 6.6.3.3.1 shall include an application/mikey MIME body with the CSK as MIKEY-SAKKE I_MESSAGE as specified in 3GPP TS 33.180 [78] in the body of the SIP PUBLISH request;

4) if confidentiality protection is enabled as specified in clause 6.6.2.3.1, shall include in the body of the SIP PUBLISH request an application/vnd.3gpp.mcptt-info+xml MIME body with:

a) the <mcptt-access-token> element set to the received access-token encrypted using the CSK, as specified in clause 6.6.2.3.3; and

b) the <mcptt-client-id> element set to the encrypted MCPTT client ID of the originating MCPTT client, as specified in clause 6.6.2.3.3;

5) if confidentiality protection is disabled as specified in clause 6.6.2.3.1, shall include in the body of the SIP PUBLISH request, an application/vnd.3gpp.mcptt-info+xml MIME body as specified in Annex F.1 with:

a) the <mcptt-access-token> element set to the value of the access token received during the user authentication procedures in the body of the SIP PUBLISH request; and

b) the <mcptt-client-id> element set to the value of the MCPTT client ID of the originating MCPTT client;

6) shall include an application/poc-settings+xml MIME body containing:

a) the Answer-Mode Indication setting in the <am-settings> element of the poc-settings event package set to the current answer mode setting ("auto-answer" or "manual-answer") of the MCPTT client according to IETF RFC 4354 [55]; and

b) the <selected-user-profile-index> element as defined in clause 7.4.1.2.2 set to the value contained in the "user-profile-index" attribute of the selected MCPTT user profile as defined in 3GPP TS 24.484 [50]; and

7) if integrity protection is enabled as specified in clause 6.6.3.3.1, shall use the CSK to integrity protect the application/vnd.3gpp.mcptt-info+xml MIME body and application/poc-settings+xml MIME body by following the procedures in clause 6.6.3.3.3.

The MCPTT client shall send the SIP PUBLISH request according to 3GPP TS 24.229 [4].

Upon receiving a SIP 200 (OK) response to the above SIP PUBLISH request, the MCPTT client:

1) may notify the MCPTT user of the successful MCPTT service authorisation and service settings.

Upon receiving a SIP 3xx, SIP 4xx, or SIP 5xx response to the above SIP PUBLISH request, the MCPTT client:

1) should notify the MCPTT user of the unsuccessful MCPTT service authorisation and service setting, possibly taking into account Warning header information for the failure reason; and

2) shall consider that the MCPTT client is not authorised.

7.2.3 Sending SIP PUBLISH for MCPTT service settings only

To set, update, remove or refresh the MCPTT service settings, the MCPTT client shall generate a SIP PUBLISH request according 3GPP TS 24.229 [4], IETF RFC 3903 [37] and IETF RFC 4354 [55]. In the SIP PUBLISH request, the MCPTT client:

1) shall perform the procedures in clause 7.2.1A;

2) if confidentiality protection is enabled as specified in clause 6.6.2.3.1, shall include in the body of the SIP PUBLISH request, an application/vnd.3gpp.mcptt-info+xml MIME body with:

a) the <mcptt-request-uri> element set to the targeted MCPTT ID encrypted using the CSK, as specified in clause 6.6.2.3.3; and

b) the <mcptt-client-id> element set to the encrypted MCPTT client ID of the originating MCPTT client, as specified in clause 6.6.2.3.3;

3) if confidentiality protection is disabled as specified in clause 6.6.2.3.1, shall include an application/vnd.3gpp.mcptt-info+xml MIME body as specified in Annex F.1 with:

a) the <mcptt-request-uri> set to the cleartext targeted MCPTT ID; and

b) the <mcptt-client-id> element set to the value of the MCPTT client ID of the originating MCPTT client;

4) shall include an application/poc-settings+xml MIME body containing:

5) if integrity protection is enabled as specified in clause 6.6.3.3.1, shall use the CSK to integrity protect the application/vnd.3gpp.mcptt-info+xml MIME body and application/poc-settings+xml MIME body by following the procedures in clause 6.6.3.3.3.

The MCPTT client shall send the SIP PUBLISH request according to 3GPP TS 24.229 [4].

Upon receiving the SIP 200 (OK) response to the SIP PUBLISH request the MCPTT client may indicate to the MCPTT User the successful communication of the MCPTT service settings to the MCPTT server.

Upon receiving a SIP 3xx, SIP 4xx, or SIP 5xx response to the above SIP PUBLISH request, the MCPTT client:

1) should notify the MCPTT user of the unsuccessful communication of the MCPTT service settings to the MCPTT server, possibly taking into account Warning header information for the failure reason; and

2) shall consider that the MCPTT service settings attempted in the SIP PUBLISH request has not been successful.

7.2.4 Determination of MCPTT service settings

In order to discover MCPTT service settings of another MCPTT client of the same MCPTT user or to verify the currently active MCPTT service settings of this MCPTT client, the MCPTT client shall generate an initial SIP SUBSCRIBE request according to 3GPP TS 24.229 [4], IETF RFC 6665 [26], and IETF RFC 4354 [55].

In the SIP SUBSCRIBE request, the MCPTT client:

1) shall set the Request-URI to the public service identity identifying the originating participating MCPTT function serving the MCPTT user;

2) shall include an application/vnd.3gpp.mcptt-info+xml MIME body. In the application/vnd.3gpp.mcptt-info+xml MIME body, the MCPTT client shall include the <mcptt-request-uri> element set to the MCPTT ID of the MCPTT user;

3) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), in a P-Preferred-Service header field according to IETF RFC 6050 [9];

4) shall set the Event header field to the ‘poc-settings’ value;

5) shall include an Accept header field containing the "application/poc-settings+xml" MIME type;

6) if the MCPTT client wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [26], to 4294967295; and

NOTE 1: 4294967295, which is equal to 2³²-1, is the highest value defined for Expires header field in IETF RFC 3261 [24].

7) if the MCPTT client wants to fetch the current state only, shall set the Expires header field according to IETF RFC 6665 [26], to zero.

In order to re-subscribe or de-subscribe, the MCPTT client shall generate and send an in-dialog SIP SUBSCRIBE request according to 3GPP TS 24.229 [4], IETF RFC 6665 [26], IETF RFC 4354 [55]. In the SIP SUBSCRIBE request, the MCPTT client with the following clarifications:

1) shall set the Event header field to the ‘poc-settings’ value;

2) shall include an Accept header field containing the "application/poc-settings+xml" MIME type;

3) if the MCPTT client wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [26], to 4294967295; and

NOTE 2: 4294967295, which is equal to 2³²-1, is the highest value defined for Expires header field in IETF RFC 3261 [24].

4) if the MCPTT client wants to de-subscribe, shall set the Expires header field according to IETF RFC 6665 [26], to zero.

Upon receiving a SIP NOTIFY request according to 3GPP TS 24.229 [4], IETF RFC 6665 [26] and IETF RFC 4354 [55], that contains an application/poc-settings+xml MIME body the MCPTT client shall cache:

1) the <am-settings> element of the poc-settings+xml MIME body for each MCPTT client identified by the "id" attribute according to IETF RFC 4354 [55] as the current Answer-mode indication of that MPCTT client; and

2) the <selected-user-profile-index> element of the poc-settings+xml MIME body for each MCPTT client identified by the "id" attribute according to IETF RFC 4354 [55] as the active MCPTT service user profile of that MCPTT client.

7.2.5 Receiving a CSK key download message

When the MCPTT client receives a SIP MESSAGE request containing:

1) a P-Asserted-Service header field containing the "urn:urn-7:3gpp-service.ims.icsi.mcptt"; and

2) an application/mikey MIME body;

Then, if the key identifier within the CSB-ID of the MIKEY payload is a CSK-ID (4 most-significant bits have the value ‘2’), the MCPTT client:

1) shall follow the security procedures in clause 9.2.1 of 3GPP TS 33.180 [78] to extract the CSK. The client:

a) if the initiator field (IDRi) has type ‘URI’ (identity hiding is not used), the client:

i) shall extract the initiator URI from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [78]. If the initiator URI deviates from the public service identity of the participating MCPTT function serving the MCPTT user, shall reject the SIP MESSAGE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [47], and include warning text set to "136 authentication of the MIKEY-SAKKE I_MESSAGE failed" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

ii) shall convert the initiator URI to a UID as described in 3GPP TS 33.180 [78];

b) if the initiator field (IDRi) has type ‘UID’ (identity hiding in use), the client:

ii) shall convert the public service identity of participating MCPTT function serving the MCPTT user to a UID as described in 3GPP TS 33.180 [78];

i) shall compare the generated UID with the UID in the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [78]. If the two initiator UIDs deviate from each other, shall reject the SIP MESSAGE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [47], and include warning text set to "136 authentication of the MIKEY-SAKKE I_MESSAGE failed" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

c) shall use the UID to validate the signature of the I_MESSAGE as described in 3GPP TS 33.180 [78];

d) if authentication verification of the I_MESSAGE fails, shall reject the SIP MESSAGE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [47], and include warning text set to "136 authentication of the MIKEY-SAKKE I_MESSAGE failed" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

e) shall extract and decrypt the encapsulated CSK using the participating MCPTT function’s (KMS provisioned) UID key as described in 3GPP TS 33.180 [78]; and

f) shall extract the CSK-ID, from the payload as specified in 3GPP TS 33.180 [78];

2) Upon successful extraction, the client shall replace the existing CSK and CSK-ID associated with the participating MCPTT function, with the extracted CSK and CSK-ID in the ‘key download’ message.

7.3 MCPTT server procedures

7.3.1 General

The MCPTT server obtains information that it needs to implement service authorization specific requirements from:

a) any received third-party SIP REGISTER request (e.g. including information contained in the body of the third-party SIP REGISTER request) as specified in 3GPP TS 24.229 [4]. The body will carry the SIP REGISTER request as sent by the MCPTT client and may contain information needed for service authorization; or

b) any received SIP PUBLISH request for MCPTT server settings containing the g.3gpp.mcptt media feature tag along with the "require" and "explicit" header field parameters. The body of the SIP PUBLISH request will contain information needed for service authorization.

7.3.1A Confidentiality and Integrity Protection

When the MCPTT server receives a SIP REGISTER request sent from the MCPTT client contained within a message/sip MIME body of a received third-party SIP REGISTER request or a SIP PUBLISH request, it first determines whether XML MIME bodies included in the request are integrity protected. If XML MIME bodies are integrity protected the MCPTT server validates the signature of each of the XML MIME bodies. If the integrity protection check(s) pass or the XML MIME bodies are not integrity protected, the MCPTT server then determines whether the content in specific XML elements is confidentiality protected. If XML content is confidentiality protected, the MCPTT server decrypts the protected content.

Upon receiving:

– a SIP REGISTER request containing an application/vnd.3gpp.mcptt-info+xml MIME body within a message/sip MIME body of the SIP REGISTER request sent from the MCPTT client; or

– a SIP PUBLISH request containing an application/vnd.3gpp.mcptt-info+xml MIME body and an application/poc-settings+xml MIME body;

the MCPTT server:

1) shall determine if integrity protection has been applied to XML MIME bodies in the SIP request by following the procedures in clause 6.6.3.4.1 for each XML MIME body;

2) if integrity protection has been applied, shall use the keying data described in clause 6.6.3.2 and the procedures described in clause 6.6.3.4.2 to verify the integrity of each of the XML MIME bodies; and

3) if all integrity protection checks succeed, shall continue with the remaining steps of this clause.

Upon receiving:

– a SIP REGISTER request containing an application/vnd.3gpp.mcptt-info+xml MIME body with an <mcptt-access-token> element and an <mcptt-client-id> element within a message/sip MIME body of the SIP REGISTER request sent from the MCPTT client; or

– a SIP PUBLISH request containing an application/vnd.3gpp.mcptt-info+xml MIME body with an <mcptt-access-token> element and an <mcptt-client-id> element, and an application/poc-settings+xml MIME body;

the MCPTT server:

1) shall determine if confidentiality protection has been applied to the <mcptt-access-token> element and the <mcptt-client-id> element in the application/vnd.3gpp.mcptt-info+xml MIME body, by following the procedures in clause 6.6.2.4.1;

2) if confidentiality protection has been applied to the <mcptt-access-token> element and <mcptt-client-id> element:

a) shall use the keying information received in the MIKEY-SAKKE I_MESSAGE as specified in 3GPP TS 33.180 [78], along with the procedures described in clause 6.6.2.4.2 to:

i) decrypt the received access token in the <mcptt-access-token> element in the application/vnd.3gpp.mcptt-info+xml MIME body; and

ii) decrypt the received MCPTT client ID in the <mcptt-client-id> element in the application/vnd.3gpp.mcptt-info+xml MIME body;

b) if the decryption procedure succeeds, shall identify the MCPTT ID and the MCPTT client ID from the decrypted values; and

c) if the decryption procedure fails, shall determine that confidentiality protection has not been successful;

3) if confidentiality protection has been applied to only one of the <mcptt-access-token> element or the <mcptt-client-id> element:

a) shall determine that confidentiality protection has not been successful;

4) if confidentiality protection has not been applied:

a) shall identify the MCPTT ID from <mcptt-access-token> element received in the application/vnd.3gpp.mcptt-info+xml MIME body; and

b) shall identify the MCPTT client ID from the <mcptt-client-id> element received in the application/vnd.3gpp.mcptt-info+xml MIME body.

Upon receiving a SIP PUBLISH request containing an application/vnd.3gpp.mcptt-info+xml MIME body with an <mcptt-request-uri> element, an <mcptt-client-id> element, and an application/poc-settings+xml MIME body, the MCPTT server:

1) shall determine if confidentiality protection has been applied to the <mcptt-request-uri> element and the <mcptt-client-id> element in the application/vnd.3gpp.mcptt-info+xml MIME body by following the procedures in clause 6.6.2.4.1;

2) if confidentiality protection has been applied to the <mcptt-request-uri> element and the <mcptt-client-id> element:

a) shall use the keying information described in clause 6.6.2.2 along with the procedures described in clause 6.6.2.4.2 to:

i) decrypt the received encrypted MCPTT ID in the <mcptt-request-uri> element in the application/vnd.3gpp.mcptt-info+xml MIME body; and

ii) decrypt the received encrypted MCPTT client ID in the <mcptt-client-id> element in the application/vnd.3gpp.mcptt-info+xml MIME body;

b) if all decryption procedures succeed, shall identify the MCPTT ID and MCPTT client ID from the decrypted values; and

c) if the decryption procedure fails, shall determine that confidentiality protection has not been successful;

3) if confidentiality protection has been applied to only one of the <mcptt-request-uri> element or <mcptt-client-id> element:

a) shall determine that confidentiality protection has not been successful;

4) if confidentiality protection has not been applied:

a) shall identify the MCPTT ID from the contents of the <mcptt-request-uri> element in the application/vnd.3gpp.mcptt-info+xml MIME body; and

b) shall identify the MCPTT client ID from the <mcptt-client-id> element received in the application/vnd.3gpp.mcptt-info+xml MIME body.

7.3.2 SIP REGISTER request for service authorisation

The MCPTT server shall support obtaining service authorization specific information from the SIP REGISTER request sent from the MCPTT client and included in the body of a third-party SIP REGISTER request.

NOTE 1: 3GPP TS 24.229 [4] defines how based on initial filter criteria the SIP REGISTER request sent from the UE is included in the body of the third-party SIP REGISTER request.

Upon receiving a third party SIP REGISTER request with a message/sip MIME body containing the SIP REGISTER request sent from the MCPTT client containing an application/vnd.3gpp.mcptt-info+xml MIME body with an <mcptt-access-token> element and an <mcptt-client-id> element within a message/sip MIME body of the SIP REGISTER request sent from the MCPTT client, the MCPTT server:

1) shall identify the IMS public user identity from the third-party SIP REGISTER request;

2) shall identify the MCPTT ID from the SIP REGISTER request sent from the MCPTT client and included in the message/sip MIME body of the third-party SIP REGISTER request by following the procedures in clause 7.3.1A;

2a) shall check if the number of maximum simultaneous authorizations supported for the MCPTT user is specified in the <user-max-simultaneous-authorizations> element of the <anyExt> element contained in the <OnNetwork> element of the MCPTT user profile (see the MCPTT user profile configuration document in 3GPP TS 24.484 [50]), and if present, shall check whether it has been reached. If reached, the MCPTT server shall not continue with the rest of the steps in this clause;

2b) if the <user-max-simultaneous-authorizations> element of the <anyExt> element is not present in the <OnNetwork> element of the MCPTT user profile (see the MCPTT user profile configuration document in 3GPP TS 24.484 [50]), shall check if the number of maximum simultaneous authorizations supported for any MCPTT user as specified in the <max-simultaneous-authorizations> element of the <anyExt> element contained in the <OnNetwork> element of the MCPTT service configuration document (see the service configuration document in 3GPP TS 24.484 [50]) has been reached. If reached, the MCPTT server shall not continue with the rest of the steps in this clause;

3) shall perform service authorization for the identified MCPTT ID as described in 3GPP TS 33.180 [78];

4) if service authorization was successful, shall bind the MCPTT ID and the MCPTT ID to the IMS public user identity;

4a) if service authorization was successful and if the service authorization request was from an MCPTT user who is previously MCPTT service authorized on another MCPTT client (as determined by a comparison of the received MCPTT client ID with the MCPTT client ID of existing bindings), keep the current bindings and create a new binding between the MCPTT ID and the IMS public user identity;

NOTE 2: The MCPTT server will store the binding MCPTT ID, MCPTT client ID, IMS public user identity and an identifier addressing the MCPTT server in an external database.

5) if a Resource-Share header field with the value "supported" is contained in the "message/sip" MIME body of the third-party REGISTER request, shall bind the MCPTT ID and the MCPTT client ID to the identity of the MCPTT UE contained in the "+g.3gpp.registration-token" header field parameter in the Contact header field of the incoming third-party REGISTER request; and

6) if more than one binding exists for the MCPTT ID, shall include in the SIP 200 (OK) response an application/vnd.3gpp.mcptt-info+xml MIME body as specified in annex F.1 with an <multiple-devices-ind> element set to the value "true".

7.3.3 SIP PUBLISH request for service authorisation and service settings

The MCPTT server shall support obtaining service authorization specific information from a SIP PUBLISH request for MCPTT server settings.

Upon receiving a SIP PUBLISH request containing:

1) an Event header field set to the "poc-settings" value;

2) an application/poc-settings+xml MIME body; and

3) an application/vnd.3gpp.mcptt-info+xml MIME body containing an <mcptt-access-token> element and an <mcptt-client-id> element;

the MCPTT server:

1) shall identify the IMS public user identity from the P-Asserted-Identity header field;

2) shall perform the procedures in clause 7.3.1A;

3) if the procedures in clause 7.3.1A were not successful shall send a SIP 403 (Forbidden) response towards the MCPTT client with the warning text set to: "140 unable to decrypt XML content " in a Warning header field as specified in clause 4.4, and not continue with the rest of the steps in this clause;

3a) shall check if the number of maximum simultaneous authorizations supported for the MCPTT user is specified in the <user-max-simultaneous-authorizations> element of the <anyExt> element contained in the <OnNetwork> element of the MCPTT user profile (see the MCPTT user profile configuration document in 3GPP TS 24.484 [50]) and if present, shall check whether it has been reached. If reached, the MCPTT server shall send a SIP 486 (Busy Here) response towards the MCPTT client with the warning text set to: "164 maximum number of service authorizations reached" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps in this clause;

3b) if the <user-max-simultaneous-authorizations> element of the <anyExt> element is not present in the <OnNetwork> element of the MCPTT user profile (see the MCPTT user profile configuration document in 3GPP TS 24.484 [50]), shall check if the number of maximum simultaneous authorizations supported for any MCPTT user as specified in the <max-simultaneous-authorizations> element of the <anyExt> element contained in the <OnNetwork> element of the MCPTT service configuration document (see the service configuration document in 3GPP TS 24.484 [50]) has been reached. If reached, the MCPTT server shall send a SIP 486 (Busy Here) response towards the MCPTT client with the warning text set to: "164 maximum number of service authorizations reached" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps in this clause;

4) shall perform service authorization for the identified MCPTT ID as described in 3GPP TS 33.180 [78];

5) if service authorization was successful:

a) shall bind the MCPTT ID and MCPTT client ID to the IMS public user identity;

b) if the service authorization request was from an MCPTT user who is previously MCPTT service authorized on another MCPTT client (as determined by a comparison of the received MCPTT client ID with the MCPTT client ID of existing bindings), keep the current bindings and create a new binding between the MCPTT ID, MCPTT client ID and the IMS public user identity; and

c) if a Resource-Share header field with the value "supported" was included in the "message/sip" MIME body of the third-party REGISTER request, shall bind the MCPTT ID to the identity of the MCPTT UE contained in the "+g.3gpp.registration-token" header field parameter in the Contact header field of the third-party REGISTER request that contained this IMS public user identity;

NOTE 1: The MCPTT server will store the binding MCPTT ID, MCPTT client ID, IMS public user identity and an identifier addressing the MCPTT server in an external database.

6) if service authorization was not successful, shall send a SIP 403 (Forbidden) response towards the MCPTT client with the warning text set to: "101 service authorisation failed" in a Warning header field as specified in clause 4.4, and not continue with the rest of the steps in this clause;

7) shall process the SIP PUBLISH request according to rules and procedures of IETF RFC 3903 [37] and if processing of the SIP request was not successful, do not continue with the rest of the steps;

8) shall cache the received MCPTT service settings until the MCPTT service settings expiration timer expires;

9) shall send a SIP 200 (OK) response according 3GPP TS 24.229 [4] with:

a) if more than one binding exists for the MCPTT ID, an application/vnd.3gpp.mcptt-info+xml MIME body as specified in annex F.1 with a <multiple-devices-ind> element set to the value "true";

10) shall use the Answer-Mode Indication setting in the <am-settings> element of the poc-settings event package as the current Answer-Mode Indication of the MCPTT client.

11) shall download the MCPTT user profile from the MCPTT user database as defined in 3GPP TS 29.283 [73] if not already stored at the MCPTT server and use the <selected-user-profile-index> element of the poc-settings event package if included to identify the active MCPTT user profile for the MCPTT client;

NOTE 2: If the <selected-user-profile-index> element of the poc-settings event package is included then only that MCPTT user profile is needed to be downloaded from the MCPTT user database.

12) if there is no <selected-user-profile-index> element included in the poc-settings event package then if multiple MCPTT user profiles are stored at the MCPTT server or downloaded for the MCPTT user from the MCPTT user database, shall determine the pre-selected MCPTT user profile to be used as the active MCPTT user profile by identifying the MCPTT user profile (see the MCPTT user profile document in 3GPP TS 24.484 [50]) in the collection of MCPTT user profiles that contains a <Pre-selected-indication> element; and

NOTE 3: If only one MCPTT user profile is stored at the MCPTT server or only one MCPTT user profile is downloaded from the MCPTT user database, then by default this MCPTT user profile is the pre-selected MCPTT user profile.

13) if an <ImplicitAffiliations> element is contained in the <OnNetwork> element of the MCPTT user profile document with one or more <entry> elements containing an MCPTT group ID (see the MCPTT user profile document in 3GPP TS 24.484 [50]) for the served MCPTT ID, shall perform implicit affiliation as specified in clause 9.2.2.2.15

7.3.4 Receiving SIP PUBLISH request for MCPTT service settings only

Upon receiving a SIP PUBLISH request containing:

1) an Event header field set to the "poc-settings" value;

2) an application/poc-settings+xml MIME body; and

3) an application/vnd.3gpp.mcptt-info+xml MIME body containing an <mcptt-request-uri> element and an <mcptt-client-id> element;

The MCPTT server:

1) shall identify the IMS public user identity from the P-Asserted-Identity header field;

2) shall perform the procedures in clause 7.3.1A;

3) if the procedures in clause 7.3.1A were not successful, shall send a SIP 403 (Forbidden) response towards the MCPTT client with the warning text set to: "140 unable to decrypt XML content" in a Warning header field as specified in clause 4.4, and not continue with the rest of the steps in this clause;

4) shall verify that a binding between the IMS public user identity in the Request-URI and the MCPTT ID in the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml exists at the MCPTT server;

5) if a binding exists between the IMS public user identity and the MCPTT ID in the request and the validity period of the binding has not expired shall download the MCPTT user profile from the MCPTT user database as defined in 3GPP TS 29.283 [73] if not already stored at the MCPTT server;

6) if a binding does not exist between the IMS public user identity and the MCPTT ID in the request or the binding exists, but the validity period of the binding has expired, shall reject the SIP PUBLISH request with a SIP 404 (Not Found) response with the warning text set to "141 user unknown to the participating function" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;

7) shall process the SIP PUBLISH request according to rules and procedures of IETF RFC 3903 [37] and if processing of the SIP request was not successful, do not continue with the rest of the steps;

8) shall cache the received MCPTT service settings until the MCPTT service settings expiration timer expires;

9) shall send a SIP 200 (OK) response according 3GPP TS 24.229 [4];

10) shall use the Answer-Mode Indication setting in the <am-settings> element of the poc-settings event package as the current Answer-Mode Indication of the MCPTT client.

NOTE 1: If the <selected-user-profile-index> element of the poc-settings event package is included then only that MCPTT user profile is needed to be downloaded from the MCPTT user database.

NOTE 2: If only one MCPTT user profile is stored at the MCPTT server or only one MCPTT user profile is downloaded from the MCPTT user database, then by default this MCPTT user profile is the pre-selected MCPTT user profile.

7.3.5 Receiving SIP PUBLISH request with "Expires=0"

Upon receiving a SIP PUBLISH request containing:

1) an Event header field set to the "poc-settings" value; and

2) an Expires header field set to 0;

the MCPTT server:

1) shall identify the IMS public user identity from the P-Asserted-Identity header field;

2) shall process the SIP PUBLISH request according to rules and procedures of IETF RFC 3903 [37] and if processing of the SIP request was successful, continue with the rest of the steps;

3) shall remove the MCPTT service settings;

NOTE: Removal of MCPTT service settings includes removal of all group affiliations.

4) shall remove the binding between the MCPTT ID and public user identity; and

5) shall send a SIP 200 (OK) response according to 3GPP TS 24.229 [4].

7.3.6 Subscription to and notification of MCPTT service settings

7.3.6.1 Receiving subscription to MCPTT service settings

Upon receiving a SIP SUBSCRIBE request such that:

1) Request-URI of the SIP SUBSCRIBE request contains the public service identity identifying the participating MCPTT function of the served MCPTT user;

2) the SIP SUBSCRIBE request contains an application/vnd.3gpp.mcptt-info+xml MIME body containing the<mcptt-request-uri> element which identifies an MCPTT ID served by the MCPTT server;

3) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), in a P-Asserted-Service header field according to IETF RFC 6050 [9]; and

3) the Event header field of the SIP SUBSCRIBE request contains the ‘poc-settings’ event type.

the MCPTT server:

1) shall identify the served MCPTT ID in the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP SUBSCRIBE request;

2) if the Request-URI of the SIP SUBSCRIBE request contains the public service identity identifying the participating MCPTT function serving the MCPTT user, shall identify the originating MCPTT ID from public user identity in the P-Asserted-Identity header field of the SIP SUBSCRIBE request;

3) if the originating MCPTT ID is different than the served MCPTT ID, shall send a 403 (Forbidden) response and shall not continue with the rest of the steps; and

4) shall generate a 200 (OK) response to the SIP SUBSCRIBE request according to 3GPP TS 24.229 [4], IETF RFC 6665 [26] and IETF RFC 4354 [55].

For the duration of the subscription, the MCPTT server shall notify subscriber about changes of the MCPTT service settings of the subscribed MCPTT user, as described in clause 7.3.6.2.

7.3.6.2 Sending notification of change of MCPTT service settings

In order to notify the subscriber about changes of the MCPTT service settings of the subscribed MCPTT client of the subscribed MCPTT user, the MCPTT server:

1) shall generate an application/poc-settings+xml MIME body containing:

a) the <am-settings> element of the poc-settings event package set to the current answer mode setting of the MCPTT client according to IETF RFC 4354 [55]; and

b) the <selected-user-profile-index> element as defined in clause 7.4.1.2.2 identifying the active MCPTT user profile; and

2) send a SIP NOTIFY request according to 3GPP TS 24.229 [4], IETF RFC 6665 [26] and IETF RFC 4354 [55] with the constructed application/poc-settings+xml MIME body.

7.3.7 Sending a CSK key download message

If confidentiality protection is enabled as specified in clause 6.6.2.3.1, and if the participating MCPTT function received a Client Server Key (CSK) within a SIP REGISTER request for service authorisation or SIP PUBLISH request for service authorisation, the participating MCPTT function may decide to update the CSK. In this case, the participating MCPTT function shall perform a key download procedure for the CSK. The participating MCPTT function:

1) shall generate an SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

2) shall set the Request-URI to the URI received in the To header field in a third-party SIP REGISTER request;

3) shall include an Accept-Contact header field with the g.3gpp.icsi-ref media-feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" along with parameters "require" and "explicit" according to IETF RFC 3841 [6];

4) shall include a P-Asserted-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.mcptt";

5) shall include an application/mikey MIME body containing the CSK-ID and the CSK encrypted within a MIKEY message to the MC client as specified in clause 9.2.1 of 3GPP TS 33.180 [78] in the body of the SIP MESSAGE request;

6) shall send the SIP MESSAGE request towards the MCPTT client according to 3GPP TS 24.229 [4].

7.4 Coding

7.4.1 Extension of MIME types

7.4.1.1 General

The parent clause of this clause defines extensions of MIME type defined in other documents.

7.4.1.2 Extension of application/poc-settings+xml MIME type

7.4.1.2.1 Introduction

The parent clause of this clause describes extension of the application/poc-settings+xml MIME body specified in IETF RFC 4354 [55]. The extension is used to indicate the selected MCS user profile at an MC client.

7.4.1.2.2 Syntax

The application/poc-settings+xml MIME body indicating the selected MCS user profile at an MC client is constructed according to IETF RFC 4354 [55] and:

1) contains a <poc-settings> root element according to IETF RFC 4354 [55];

2) contains one or more <entity> child element according to IETF RFC 4354 [55] of the <poc-settings> element;

3) contains one <selected-user-profile-index> child element defined in the XML schema defined in table 7.4.1.2.2-2, of the <entity> element;

NOTE: The <selected-user-profile-index> element is validated by the <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> particle of the <entity> element.

The application/poc-settings+xml MIME body refers to namespaces using prefixes specified in table 7.4.1.2.2-1.

Table 7.4.1.2.2-1: Assignment of prefixes to namespace names in the application/poc-settings+xml MIME body

Prefix	Namespace
PoC1Set	urn:oma:params:xml:ns:poc:poc-settings
mcs10Set	urn:3gpp:mcsSettings:1.0

Table 7.4.1.2.2-2: XML schema with elements and attributes extending the application/poc-settings+xml MIME body

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema

targetNamespace="urn:3gpp:mcsSettings:1.0"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:mcs10Set="urn:3gpp:mcsSettings:1.0"

elementFormDefault="qualified" attributeFormDefault="unqualified">

<!– MCS specific "entity" child elements –>

<xs:element name="selected-user-profile-index" type="mcs10Set:selected-user-profile-indexType"/>

<xs:complexType name="selected-user-profile-indexType">

<xs:sequence>

<xs:element name="user-profile-index" type="xs:nonNegativeInteger"/>

<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute namespace="##any" processContents="lax"/>

</xs:complexType>

</xs:schema>

An example application/poc-settings+xml MIME body showing the MC service settings for two MC clients as might be included in the body of a SIP NOTIFY request is shown in table 7.4.1.2.2-3.

Table 7.4.1.2.2-3: Example application/poc-settings+xml MIME body showing the MC service settings for two MC clients as might be included in the body of a SIP NOTIFY request

<?xml version="1.0" encoding="UTF-8"?>

<poc-settings xmlns="urn:oma:params:xml:ns:poc:poc-settings">

<am-settings>

<answer-mode>automatic</answer-mode>

</am-settings>

<selected-user-profile-index>

<user-profile-index>1</user-profile-index>

</selected-user-profile-index>

</entity>

<am-settings>

<answer-mode>manual</answer-mode>

</am-settings>

<selected-user-profile-index>

<user-profile-index>2</user-profile-index>

</selected-user-profile-index>

</entity>

</poc-settings>