6 Procedures

24.4843GPPMission Critical Services (MCS) configuration managementProtocol specificationRelease 18TS

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

6.1 Introduction

This clause specifies procedures enabling a configuration management client (CMC) and an MCS server to have the MCS configuration managed using the configuration management server (CMS).

The following procedures are defined for management of configuration management documents:

– configuration management document creation procedure;

– configuration management document retrieval procedure;

– configuration management document update procedure;

– configuration management document deletion procedure;

– configuration management document element creation or replacement procedure;

– configuration management document element deletion procedure;

– configuration management document element fetching procedure;

– configuration management document attribute creation or replacement procedure;

– configuration management document attribute deletion procedure;

– configuration management document attribute fetching procedure;

– configuration management document namespace binding fetching procedure; and

– configuration management document subscription and notification procedure.

6.2 Common procedures

6.2.1 General

This clause contains common procedures applied on HTTP signalling specified in this document.

6.2.2 Client procedures

The CMC shall send the HTTP request over TLS connection as specified for the HTTP client in the UE in annex A of 3GPP TS 24.482 [6].

6.2.3 MCS server procedures

The MCS server shall send the HTTP request as specified for the HTTP client in the network entity in annex A of 3GPP TS 24.482 [6].

6.2.4 Configuration management server procedures

6.2.4.1 General

The CMS shall handle the HTTP request as specified for the HTTP server in annex A of 3GPP TS 24.482 [6].

The CMS shall be configured with an authorized MCS server list, containing public service identities of MCS servers of the MCS provider of the CMS.

When handling an HTTP request, the CMS shall determine the identity of the sender of the HTTP request as specified in 3GPP TS 24.482 [6], and shall use the identity of the sender of the HTTP request as an authenticated identity when performing the authorization.

The CMS shall handle SIP requests and SIP responses as specified in 3GPP TS 24.229 [22].

6.2.4.2 SIP failure case

When initiating a SIP failure response to any received SIP request, depending on operator policy, the CMS may insert a SIP Response-Source header field in accordance with the procedures in clause 5.7.1.0 of 3GPP TS 24.229 [22], where the "role" header field parameter is set to "cms".

6.3 Configuration management procedures

6.3.1 General

6.3.1.1 Client procedures

A CMC shall support clause 6.1.1 "Document Management" of OMA OMA-TS-XDM_Core-V2_1 [2] and clause 6.3.13.2.2 for subscribing to configuration management documents.

6.3.1.2 Configuration management server procedures

A CMS shall support clause 6.2.1 "Document Management", and clause 6.2.4 "Access Permissions" of OMA OMA-TS-XDM_Core-V2_1 [2] and clause 6.3.13.3 for accepting subscriptions to configuration management documents.

6.3.2 Configuration management document creation procedure

6.3.2.1 General

This clause addresses the scenario for configuration management creation by administrators as described in 3GPP TS 23.280 [8A].

6.3.2.2 Configuration management client (CMC) procedures

In order to create a configuration management document, a CMC shall create an XML document of one of the appropriate application usages, and shall send the XML document to the network according to procedures specified in IETF RFC 4825 [14] "Create or Replace a Document". The CMC shall set the Request-URI of the HTTP PUT request to the "CMSXCAPRootURI" configured as per 3GPP TS 24.483 [4] and include the "auid" as per the appropriate application usage in clause 7.

6.3.2.3 Configuration management server (CMS) procedures

A CMS shall support receiving XML documents of the application usages according to procedures specified in IETF RFC 4825 [14] "PUT Handling" where the Request-URI of the HTTP PUT request identifies an XML document and include the "auid" as per the appropriate application usage in clause 7.

6.3.3 Configuration management document retrieval procedure

6.3.3.1 General

This clause describes how retrieval of a configuration management document takes place.

6.3.3.2 Client procedures

6.3.3.2.1 General client (GC) procedures

In order to retrieve a configuration management document, a GC shall send an HTTP GET request with the Request URI that references the document to be updated to the network according to procedures specified in IETF RFC 4825 [14] "Retrieve a Document".

6.3.3.2.2 Configuration management client (CMC) procedures

In order to retrieve a configuration management document, a CMC shall perform the procedures in clause 6.3.3.2.1 specified for GC. The CMC shall set the Request-URI of the HTTP GET request to the "CMSXCAPRootURI" configured as per 3GPP TS 24.483 [4] and include the "auid" as per the appropriate application usage.

6.3.3.2.3 MCS server procedures

In order to retrieve a configuration management document via the CSC-5 reference point, an MCS Server shall perform the procedures in clause 6.3.3.2.1 specified for GC. The MCS server shall set the Request-URI of the HTTP GET request to identify the XML document based on configuration and include the "auid" as per the appropriate application usage.

6.3.3.3 Configuration management server procedures

A CMS shall support handling an HTTP GET request from a CMC and an MCS Server according to procedures specified in IETF RFC 4825 [14]"GET Handling" where the Request-URI of the HTTP GET request identifies an XML document and include the "auid" as per with the "auid" parameter set to the appropriate application usage.

6.3.4 Configuration management document update procedure

6.3.4.1 General

This clause describes the procedures for updating of a configuration management document.

6.3.4.2 Configuration management client procedures

In order to update a configuration management document, a CMC shall create an XML document of one of the appropriate application usages, and shall send the XML document to the network according to procedures specified in IETF RFC 4825 [14] "Create or Replace a Document". The CMC shall set the Request-URI of the HTTP PUT request to the "CMSXCAPRootURI" configured as per 3GPP TS 24.483 [4] and include the "auid" as per the appropriate application usage.

6.3.4.3 Configuration management server procedures

A CMS shall support receiving an XML document of the application usages according to the procedures specified in IETF RFC 4825 [14] "PUT Handling" where the Request-URI of the HTTP PUT request identifies an XML document and include the "auid" as per to the appropriate application usage.

6.3.5 Configuration management document deletion procedure

6.3.5.1 General

This clause describes deletion of a configuration management document.

6.3.5.2 Configuration management Client (CMC) procedures

In order to delete a configuration management document, a CMC shall send an HTTP DELETE request with the Request-URI of the HTTP DELETE request set to the "CMSXCAPRootURI" configured as per 3GPP TS 24.483 [4] along with the "auid" as per the appropriate application usage for the XML document to be deleted to the network according to procedures specified in IETF RFC 4825 [14] "Delete a Document".

6.3.5.3 Configuration management server (CMS) procedures

A CMS shall support handling an HTTP DELETE request from a CMC according to procedures specified in IETF RFC 4825 [14] "DELETE Handling" where the Request-URI of the HTTP DELETE request identifies an XML document using the "auid" as per the appropriate application usage.

6.3.6 Configuration management document element creation or replacement procedure

6.3.6.1 General

This procedure enables the CMC to create or replace an element of a configuration management document from CMS.

6.3.6.2 Client procedures

6.3.6.2.1 General client procedures

In order to create or replace an element of a configuration management document, a GC shall send an HTTP PUT request with the Request URI that references the element of the document to be created or replaced to the network according to procedures specified in IETF RFC 4825 [14] "Create or Replace an Element".

6.3.6.2.2 Configuration management client procedures

In order to create or replace an element of a configuration management document, a CMC shall perform the procedures in clause 6.3.6.2.1 specified for GC. The CMC shall construct the Request-URI of the HTTP PUT request using the "CMSXCAPRootURI" configured as per 3GPP TS 24.483 [4] as the root of the relative path along with the "auid" as per the appropriate application usage.

6.3.6.3 Configuration management server procedures

A CMS shall support handling an HTTP PUT request from a CMC according to procedures specified in IETF RFC 4825 [14] "PUT Handling" where the Request-URI of the HTTP PUT request identifies an element of XML document using the "auid" as per the appropriate application usage.

6.3.7 Configuration management document element deletion procedure

6.3.7.1 General

This procedure enables the CMC to delete an element of a configuration management document from CMS.

6.3.7.2 Client procedures

6.3.7.2.1 General client procedures

In order to delete an element of a configuration management document, a GC shall send an HTTP DELETE request with the Request URI that references the element of the document to be deleted to the network according to procedures specified in IETF RFC 4825 [14] "Delete an Element".

6.3.7.2.2 Configuration management client procedures

In order to delete an element of a configuration management document, a CMC shall perform the procedures in clause 6.3.7.2.1 specified for GC. The CMC shall construct the Request-URI of the HTTP DELETE request using the "CMSXCAPRootURI" configured as per 3GPP TS 24.483 [4] as the root of the relative path and include the "auid" as per the appropriate application usage.

6.3.7.3 Configuration management server procedures

A CMS shall support handling an HTTP DELETE request from a CMC according to procedures specified in IETF RFC 4825 [14] "DELETE Handling" where the Request-URI of the HTTP DELETE request identifies an element of XML document along with the "auid" as per the appropriate application usage.

6.3.8 Configuration management document element fetching procedure

6.3.8.1 General

This procedure enables the CMC or the MCS server to fetch an element of a configuration management document from the CMS.

6.3.8.2 Client procedures

6.3.8.2.1 General client procedures

In order to fetch an element of a configuration management document, a GC shall send an HTTP GET request with the Request URI that references the element of the document to be fetched to the network according to procedures specified in IETF RFC 4825 [14] "Fetch an Element".

6.3.8.2.2 Configuration management client procedures

In order to fetch an element of a configuration management document, a CMC shall perform the procedures in clause 6.3.8.2.1 specified for GC. The CMC shall construct the Request-URI of the HTTP GET request using the "CMSXCAPRootURI" configured as per 3GPP TS 24.483 [4] as the root of the relative path along with the "auid" as per the appropriate application usage.

6.3.8.2.3 MCS server procedures

In order to fetch an element of a configuration management document, an MCS server shall perform the procedures in clause 6.3.8.2.1 specified for GC. The MCPTT sserver shall set the Request-URI of the HTTP GET request to identify the XML document based on configuration with the "auid" as per the appropriate application usage.

6.3.8.3 Configuration management server procedures

A CMS shall support handling an HTTP GET request from CMC according to procedures specified in IETF RFC 4825 [14]"GET Handling" where the Request-URI of the HTTP GET request identifies an element of XML document with the "auid" as per the appropriate application usage.

6.3.9 Configuration management document attribute creation or replacement procedure

6.3.9.1 General

This procedure enables the CMC to create or replace an attribute of a configuration management document from CMS.

6.3.9.2 Client procedures

6.3.9.2.1 General client procedures

In order to create or replace an attribute of a configuration management document, a GC shall send an HTTP PUT request with the Request URI that references the element of the document to be created or replaced to the network according to procedures specified in IETF RFC 4825 [14] "Create or Replace an Attribute".

6.3.9.2.2 Configuration management client procedures

In order to create or replace an attribute of a configuration management document, a CMC shall perform the procedures in clause 6.3.9.2.1 specified for GC. The CMC shall construct the Request-URI of the HTTP PUT request using the "CMSXCAPRootURI" configured as per 3GPP TS 24.483 [4] as the root of the relative path along with the "auid" per the appropriate application usage.

6.3.9.3 Configuration management server procedures

A CMS shall support handling an HTTP PUT request from a CMC according to procedures specified in IETF RFC 4825 [14] "PUT Handling" where the Request-URI of the HTTP PUT request identifies an attribute of XML document with the "auid" per the appropriate application usage in clause 7.

6.3.10 Configuration management document attribute deletion procedure

6.3.10.1 General

This procedure enables the CMC to delete an attribute of a configuration management document from the CMS.

6.3.10.2 Client procedures

6.3.10.2.1 General client procedures

In order to delete an attribute of a configuration management document, a GC shall send an HTTP DELETE request with the Request URI that references the attribute of the document to be deleted to the network according to procedures specified in IETF RFC 4825 [14] "Delete an Attribute".

6.3.10.2.2 Configuration management client procedures

In order to delete an attribute of a configuration management document, a CMC shall perform the procedures in clause 6.3.10.2.1 specified for GC. The CMC shall construct the Request-URI of the HTTP DELETE request using the "CMSXCAPRootURI" configured as per 3GPP TS 24.483 [4] as the root of the relative path along with the "auid" per the appropriate application usage.

6.3.10.3 Configuration management server procedures

A CMS shall support handling an HTTP DELETE request from CMC according to procedures specified in IETF RFC 4825 [14] "DELETE Handling" where the Request-URI of the HTTP DELETE request identifies an attribute of XML document along with the "auid" perthe appropriate application usage in clause 7.

6.3.11 Configuration management document attribute fetching procedure

6.3.11.1 General

This procedure enables the CMC or the MCS server to fetch an attribute of a configuration management document from the CMS.

6.3.11.2 Client procedures

6.3.11.2.1 General client procedures

In order to fetch an attribute of a configuration management document, a GC shall send an HTTP GET request with the Request URI that references the attribute of the document to be fetched to the network according to procedures specified in IETF RFC 4825 [14] "Fetch an Attribute".

6.3.11.2.2 Configuration management client procedures

In order to fetch an attribute of a configuration management document, a CMC shall perform the procedures in clause 6.3.11.2.1 specified for GC. The CMC shall construct the Request-URI of the HTTP GET request using the "CMSXCAPRootURI" configured as per 3GPP TS 24.483 [4] as the root of the relative path along with the "auid" per the appropriate application usage .

6.3.11.2.3 MCS server procedures

In order to fetch an attribute of a configuration management document, an MCS server shall perform the procedures in clause 6.3.11.2.1 specified for GC. The MCS sserver shall set the Request-URI of the HTTP GET request to identify the XML document based on configuration with the "auid" per the appropriate application usage.

6.3.11.3 Configuration management server procedures

A CMS shall support handling an HTTP GET request from a CMC according to procedures specified in IETF RFC 4825 [14] "GET Handling" where the Request-URI of the HTTP GET request identifies an attribute of XML document with the "auid" per the appropriate application usagein clause 7.

6.3.12 Configuration management document namespace binding fetching procedure

6.3.12.1 General

This procedure enables the CMC or the MCS server to fetch a namespace binding of a configuration management document from the CMS.

6.3.12.2 Client procedures

6.3.12.2.1 General client procedures

In order to fetch a namespace binding of a configuration management document, a GC shall send an HTTP GET request according to procedures specified in IETF RFC 4825 [14] "Fetch Namespace Bindings".

6.3.12.2.2 Configuration management client procedures

In order to fetch a namespace binding of a configuration management document, a CMC shall perform the procedures in clause 6.3.12.2.1 specified for GC. The CMC shall construct the Request-URI of the HTTP GET request to identify a namespace binding of the XML document along with the "auid" per the appropriate application usage .

6.3.12.2.3 MCS server procedures

In order to fetch a namespace binding of a configuration management document, an MCS server shall perform the procedures in clause 6.3.12.2.1 specified for GC. The MCS sserver shall set the Request-URI of the HTTP GET request to identify a namespace binding of the XML document with the "auid" per the appropriate application usage.

6.3.12.3 Configuration management server procedures

A CMS shall support handling an HTTP GET request from a CMC according to procedures specified in IETF RFC 4825 [14] "GET Handling" where the Request-URI of the HTTP GET request identifies a namespace binding of XML document of the appropriate application usage.

6.3.13 Configuration management subscription and notification procedure

6.3.13.1 General

This clause describes subscription to a configuration management document.

6.3.13.2 Client procedures

6.3.13.2.1 General client (GC) procedures

This procedure enables the CMC to subscribe to notification of changes of one or more configuration management documents defined.

This procedure enables the MCS server to subscribe to notification of changes of the MCPTT service configuration document.

6.3.13.2.2 Configuration management client procedures

In order to subscribe to Configuration management document, a CMC shall send an initial SIP SUBSCRIBE request to the network according to the UE originating procedures specified in 3GPP TS 24.229 [22] and IETF RFC 5875 [11]. In the initial SIP SUBSCRIBE request, the CMC:

a) if direct subscription is used, shall set the Request URI to a SIP URI containing:

1) the base URI being equal to the "CMSXCAPRootURI" configured in the CMC as per 3GPP TS 24.483 [4]; and

2) the "auid" parameter set to the appropriate application usage identifying a configuration management document;

b) if subscription to multiple documents simultaneously using the subscription proxy function is used:

1) shall include an application/resource-lists+xml MIME body. In the application/resource-lists+xml MIME body, the CMC shall include one <entry> element for each document or element to be subscribed to, such that the "uri" attribute of the <entry> element contains a relative path reference to document in the format specified by IETF RFC 5875 [11]; and

2) shall set the Request-URI to the configured public service identity for performing subscription proxy function of the CMS;

c) shall include an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcptt-access-token> element set to the value of the access token received during authentication procedure as described in 3GPP TS 24.482 [6];

d) if identity hiding is required:

1) shall perform the confidentiality protection procedures and integrity protection procedures defined in 3GPP TS 24.379 [9] for MCPTT client on the application/vnd.3gpp.mcptt-info+xml MIME body and on the application/resource-lists+xml MIME body; and

2) shall include an application/mikey MIME body with the CSK as specified in 3GPP TS 24.379 [9];

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

f) shall include 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.

Upon receiving a SIP NOTIFY request associated with a subscription created as result of the sent initial SIP SUBSCRIBE request:

1) if identity hiding is required, the CMC shall perform the confidentiality protection procedures and integrity protection procedures defined in 3GPP TS 24.379 [9] for MC client; and

2) shall handle the SIP NOTIFY request according to IETF RFC 5875 [11].

In order to re-subscribe to notification of changes of a modified list of one or more configuration management documents; a CMC shall send a SIP re-SUBSCRIBE request to the network according to the UE originating procedures specified in 3GPP TS 24.229 [22] and IETF RFC 5875 [11]. In the SIP re-SUBSCRIBE request, the CMC:

a) if direct subscription is used, shall set the Request URI to a SIP URI containing:

1) the base URI being equal to the "CMSXCAPRootURI" configured in the CMC as per 3GPP TS 24.483 [4]; and

2) the "auid" parameter set to the appropriate application usage identifying a configuration management document as described in clause 7;

b) if subscription to multiple documents simultaneously using the subscription proxy function is used:

c) if identity hiding is required, shall perform the confidentiality protection procedures and integrity protection procedures defined in 3GPP TS 24.379 [9] for MC client on the application/vnd.3gpp.mcptt-info+xml MIME body and on the application/resource-lists+xml MIME body using the CSK included in the initial SIP SUBSCRIBE request; and

d) shall include 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.

6.3.13.2.3 MCS server procedures

In order to subscribe to an MCS service configuration document, an MCS server shall send an initial SIP SUBSCRIBE request to the network according to the originating AS procedures specified in 3GPP TS 24.229 [22] and IETF RFC 5875 [11]. In the initial SIP SUBSCRIBE request, MCS server:

a) shall set the Request URI to a SIP URI containing:

1) the base URI being equal to the public service identity of the CMS configured in the MCS server; and

2) the "auid" parameter set to the application usage identifying th MCS service configuration document;

b) shall include a P-Asserted-Identity header field containing the public service identity of the MCS server;

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

d) shall include 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.

Upon receiving a SIP NOTIFY request associated with a subscription created as result of the sent initial SIP SUBSCRIBE request, the MCS server shall handle the SIP NOTIFY request according to IETF RFC 5875 [11].

In order to re-subscribe to notification of changes to an MCS service configuration document, an MCS server shall send a SIP re-SUBSCRIBE request to the network according to the originating AS procedures specified in 3GPP TS 24.229 [22] and IETF RFC 5875 [11]. In the SIP re-SUBSCRIBE request, MCS server:

a) shall set the Request URI to a SIP URI containing:

1) the base URI being equal to the public service identity of the CMS configured in the MCS server; and

2) the "auid" parameter set to the application usage identifying an MCS service configuration document; and

b) shall include 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.

6.3.13.3 Configuration management server procedures

6.3.13.3.1 General

The CMS procedures consist of:

a) procedures for CMS performing the subscription proxy function; and

b) procedures for CMS storing configuration management documents.

The CMS shall be configured with own public service identity for performing subscription proxy function of the CMS.

The CMS shall be configured with own public service identity for accessing documents.

6.3.13.3.2 Procedures for CMS performing the subscription function

6.3.13.3.2.1 General

The procedures for the CMS performing the subscription function.

6.3.13.3.2.2 CMC originated subscription proxy procedure

Upon reception of an initial SIP SUBSCRIBE request:

a) with the Event header field set to xcap-diff;

b) with the Request-URI set to own public service identity for performing subscription proxy function of the CMS;

c) with a P-Asserted-Identity header field not containing an identity listed in the authorized MCS server list specified in clause 6.2.4;

d) with an application/vnd.3gpp.mcptt-info+xml MIME body containing the <mcptt-access-token> element;

e) with an application/resource-lists+xml MIME body; and

f) with the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24 229 [12]), in a P-Asserted-Service header field according to IETF RFC 6050 [23];

the CMS:

a) if an <EncryptedData> XML tag is included in the application/vnd.3gpp.mcptt-info+xml MIME body and the CSK is received in an application/mikey MIME body of the initial SIP SUBSCRIBE request, shall decrypt the application/vnd.3gpp.mcptt-info+xml MIME body;

b) if an <EncryptedData> XML tag is included in the application/resource-lists+xml MIME body and the CSK is received in an application/mikey MIME body of the initial SIP SUBSCRIBE request, shall decrypt the application/resource-lists+xml MIME body;

c) shall identify the originating MCPTT ID from <mcptt-access-token> element received in the application/vnd.3gpp.mcpttinfo+xml MIME body and shall use the originating MCPTT ID as an authenticated identity when performing the authorization;

d) if the authenticated identity is not authorized to subscribe to notification of changes of any resource in the application/resource-lists+xml MIME body, shall reject the request with a SIP 403 (Forbidden) response and shall not continue with rest of the steps;

e) act as a notifier according to IETF RFC 5875 [11]. Additionally, if an XCAP URI in the "uri" attribute of the <entry> element of the application/resource-lists+xml MIME body of the initial SIP SUBSCRIBE request contains an "auid" parameter set to an application usage identifying a configuration management document as described in clause 7;

shall return the XCAP URI identifying the configuration management document in SIP NOTIFY requests associated with a subscription created as result of the received initial SIP SUBSCRIBE request.

Upon sending a SIP NOTIFY request associated with a subscription created as result of the received initial SIP SUBSCRIBE request, if the CSK is received in an application/mikey MIME body of the initial SIP SUBSCRIBE request, the CMS shall perform the confidentiality protection procedures and integrity protection procedures defined in 3GPP TS 24.379 [9] for MCPTT server.

Upon reception of a SIP re-SUBSCRIBE request:

a) with the Event header field set to xcap-diff; and

b) with an application/resource-lists+xml MIME body;

the CMS:

a) if an <EncryptedData> XML tag is included in the application/resource-lists+xml MIME body of the received SIP re-SUBSCRIBE request and the CSK was received in an application/mikey MIME body of the initial SIP SUBSCRIBE request, shall decrypt the application/resource-lists+xml MIME body; and

b) act as a notifier according to IETF RFC 5875 [11]. Additionally, if an XCAP URI in the "uri" attribute of the <entry> element of the application/resource-lists+xml MIME body of the SIP re-SUBSCRIBE request contains an "auid" parameter set to an application usage identifying a configuration management document:

and for which there is no related subscription established according to the clause 6.3.13.3.2.3, shall return the XCAP URI identifying the configuration management document in SIP NOTIFY requests associated with a subscription created as result of the received initial SIP SUBSCRIBE request.

6.3.13.3.2.3 CMC originated subscription procedure

Upon reception of an initial SIP SUBSCRIBE request:

a) with the Event header field set to xcap-diff;

b) with the Request-URI having the base URI equal to the XCAP root URI of the CMS;

c) with a P-Asserted-Identity header field containing an identity listed in the authorized MCS server list specified in clause 6.2.4; and

d) with the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24 229 [12]), in a P-Asserted-Service header field according to IETF RFC 6050 [23];

the CMS shall act as a notifier according to IETF RFC 5875 [11].

Upon reception of a SIP re-SUBSCRIBE request with the Event header field set to xcap-diff, the CMS:

a) if the <mcptt-calling-user-id> element is included in the application/vnd.3gpp.mcptt-info+xml MIME body:

1) shall use the <mcptt-calling-user-id> element value as an authenticated identity when performing the authorization; and

2) if the authenticated identity is not authorized to subscribe to notification of changes of any document, shall reject the request with a SIP 403 (Forbidden) response and shall not continue with rest of the steps;

b) if the authenticated identity is not authorized to subscribe to notification of changes of any document, shall reject the request with a SIP 403 (Forbidden) response and shall not continue with rest of the steps; and

c) shall act as a notifier according to IETF RFC 5875 [11].

6.3.13.3.2.4 MCS server originated subscription procedure

Upon reception of an initial SIP SUBSCRIBE request:

a) with the Event header field set to xcap-diff;

b) with the Request-URI having the base URI equal to the public service identity of the CMS;

c) with a P-Asserted-Identity header field containing an identity listed in the authorized MCS server list specified in clause 6.2.4; and

d) with the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24 229 [12]), in a P-Asserted-Service header field according to IETF RFC 6050 [23];

the CMS shall act as a notifier according to IETF RFC 5875 [11].

Upon reception of a SIP re-SUBSCRIBE request:

a) with the Event header field set to xcap-diff; and

b) with an application/resource-lists+xml MIME body;

the CMS:

a) shall use URI of the P-Asserted-Identity header field as an authenticated identity when performing the authorization;

b) if the authenticated identity is not authorized to subscribe to notification of changes of any document or element in the application/resource-lists+xml MIME body, shall reject the request with a SIP 403 (Forbidden) response and shall not continue with rest of the steps; and

c) shall act as a notifier according to IETF RFC 5875 [11].