7 Registration and service authorisation

24.2813GPPMission Critical Video (MCVideo) signalling 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 MCVideo service authorization for the MCVideo client and the MCVideo service. The MCVideo UE can use SIP REGISTER or SIP PUBLISH for MCVideo service settings to perform service authorization for MCVideo. 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 [52].

If another MC service client (e.g. MCPTT, MCData) is operating at the same time on the same MC UE as the MCVideo client, then the MCVideo 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 MCVideo 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 MCVideo service as for other MC services when performing service authorization for MCVideo along with other MC services using SIP REGISTER multipart MIME bodies for each MC service are included in the SIP REGISTER request. The MCVideo 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 [11] for further details of including multiple contact addresses in a single SIP REGISTER request).

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

7.2 MCVideo client procedures

7.2.1 SIP REGISTER request for service authorisation

When the MCVideo client performs SIP registration for service authorization the MCVideo client shall perform the registration procedures as specified in 3GPP TS 24.229 [11].

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

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

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

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

If the MCVideo client, upon performing SIP registration:

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

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 MCVideo client shall include in the SIP REGISTER request an application/vnd.3gpp.mcvideo-info+xml MIME body as defined in Annex F.1 with:

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

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

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

If the MCVideo client, upon performing SIP registration:

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

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 MCVideo client:

1) shall include an application/mikey MIME body with the CSK as MIKEY-SAKKE I_MESSAGE as specified in 3GPP TS 33.180 [8] 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.mcvideo-info+xml MIME body with the following clarifications:

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

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

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

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

b) the <mcvideo-client-id> element set to the value of the MCVideo client ID of the originating MCVideo 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.mcvideo-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 MCVideo client performs SIP registration without service authorisation the MCVideo client shall perform the registration procedures as specified in 3GPP TS 24.229 [11].

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

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

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

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

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

7.2.1A Common SIP PUBLISH procedure

This procedure is only referenced from other procedures.

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

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

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

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 [12], to 4294967295, if the MCVideo user is not removing the MCVideo service settings, otherwise to remove the MCVideo service settings the MCVideo 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 [15].

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

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

7.2.2 SIP PUBLISH request for service authorisation and MCVideo service settings

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

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

2) has available an access-token;

then the MCVideo 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.mcvideo-info+xml MIME body as specified in Annex F.1 with the <mcvideo-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 [8] 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.mcvideo-info+xml MIME body with:

a) the <mcvideo-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 <mcvideo-client-id> element set to the encrypted MCVideo client ID of the originating MCVideo 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.mcvideo-info+xml MIME body as specified in Annex F.1 with:

a) the <mcvideo-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 <mcvideo-client-id> element set to the value of the MCVideo client ID of the originating MCVideo client;

6) shall include an application/poc-settings+xml MIME body as defined in 3GPP TS 24.379 [40] 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 MCVideo client according to IETF RFC 4354 [53]; and

b) the <selected-user-profile-index> element set to the value contained in the "user-profile-index" attribute of the selected MCVideo user profile as defined in 3GPP TS 24.484 [25]; 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.mcvideo-info+xml MIME body and application/poc-settings+xml MIME body by following the procedures in clause 6.6.3.3.3.

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

7.2.3 Sending SIP PUBLISH for MCVideo service settings only

To set, update, remove or refresh the MCVideo service settings, the MCVideo client shall generate a SIP PUBLISH request according 3GPP TS 24.229 [11], IETF RFC 3903 [12] and IETF RFC 4354 [53]. In the SIP PUBLISH request, the MCVideo 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.mcvideo-info+xml MIME body with:

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

b) the <mcvideo-client-id> element set to the encrypted MCVideo client ID of the originating MCVideo 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.mcvideo-info+xml MIME body as specified in Annex F.1 with:

a) the <mcvideo-request-uri> set to the cleartext targeted MCVideo ID; and

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

4) shall include an application/poc-settings+xml MIME body as defined in 3GPP TS 24.379 [40] containing:

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

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.mcvideo-info+xml MIME body and application/poc-settings+xml MIME body by following the procedures in clause 6.6.3.3.3.

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

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

7.2.4 Determination of MCVideo service settings

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

In the SIP SUBSCRIBE request, the MCVideo client:

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

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

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

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 MCVideo client wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [16], 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 [15].

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

In order to re-subscribe or de-subscribe, the MCVideo client shall generate an in-dialog SIP SUBSCRIBE request according to 3GPP TS 24.229 [11], IETF RFC 6665 [16], IETF RFC 4354 [53]. In the SIP SUBSCRIBE request, the MCVideo client:

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 MCVideo client wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [16], 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 [15].

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

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

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

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

7.2.5 Receiving a CSK key download message

When the MCVideo client receives a SIP MESSAGE request containing:

1) a P-Asserted-Service header field containing the "urn:urn-7:3gpp-service.ims.icsi.mcvideo"; 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 MCVideo client:

1) shall follow the security procedures in clause 9.2.1 of 3GPP TS 33.180 [8] 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 [8]. If the initiator URI deviates from the public service identity of the participating MCVideo function serving the MCVideo user, shall reject the SIP MESSAGE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [6], 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 [8];

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

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

ii) shall compare the generated UID with the UID in the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [8]. 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 [6], 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 [8];

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 [6], 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 MCVideo function’s (KMS provisioned) UID key as described in 3GPP TS 33.180 [8]; and

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

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

7.3 MCVideo server procedures

7.3.1 General

The MCVideo 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 [11]. The body will carry the SIP REGISTER request as sent by the MCVideo client and may contain information needed for service authorization; or

b) any received SIP PUBLISH request for MCVideo server settings containing the g.3gpp.mcvideo 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 MCVideo server receives a SIP REGISTER request sent from the MCVideo 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 MCVideo 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 MCVideo server then determines whether the content in specific XML elements is confidentiality protected. If XML content is confidentiality protected, the MCVideo server decrypts the protected content.

Upon receiving:

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

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

the MCVideo 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.mcvideo-info+xml MIME body with an <mcvideo-access-token> element and an <mcvideo-client-id> element within a message/sip MIME body of the SIP REGISTER request sent from the MCVideo client; or

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

the MCVideo server:

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

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

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

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

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

b) if the decryption procedure succeeds, shall identify the MCVideo ID and the MCVideo 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 <mcvideo-access-token> element or the <mcvideo-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 MCVideo ID from <mcvideo-access-token> element received in the application/vnd.3gpp.mcvideo-info+xml MIME body; and

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

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

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

2) if confidentiality protection has been applied to the <mcvideo-request-uri> element and the <mcvideo-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 MCVideo ID in the <mcvideo-request-uri> element in the application/vnd.3gpp.mcvideo-info+xml MIME body; and

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

b) if all decryption procedures succeed, shall identify the MCVideo ID and MCVideo 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 <mcvideo-request-uri> element or <mcvideo-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 MCVideo ID from the contents of the <mcvideo-request-uri> element in the application/vnd.3gpp.mcvideo-info+xml MIME body;and

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

7.3.2 SIP REGISTER request for service authorisation

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

NOTE 1: 3GPP TS 24.229 [11] 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 MCVideo client containing an application/vnd.3gpp.mcvideo-info+xml MIME body with an <mcvideo-access-token> element and an <mcvideo-client-id> element within a message/sip MIME body of the SIP REGISTER request sent from the MCVideo client, the MCVideo server:

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

2) shall identify the MCVideo ID from the SIP REGISTER request sent from the MCVideo 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 MCVideo user is specified in the <user-max-simultaneous-authorizations> element of the <anyExt> element contained in the <OnNetwork> element of the MCVideo user profile (see the user profile configuration document in 3GPP TS 24.484 [25]) and if present shall check whether it has been reached. If the number of maximum simultaneous authorizations has been reached, the MCVideo 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 MCVideo user profile (see the user profile configuration document in 3GPP TS 24.484 [25]), shall check if the number of maximum simultaneous authorizations supported for any MCVideo user as specified in the <max-simultaneous-authorizations> element of the <anyExt> element contained in the <OnNetwork> element of the MCVideo service configuration document (see the service configuration document in 3GPP TS 24.484 [25]) has been reached. If the number of maximum simultaneous authorizations has been reached, the MCVideo server shall not continue with the rest of the steps in this clause;

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

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

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

NOTE 2: The MCVideo server will store the binding MCVideo ID, MCVideo client ID, IMS public user identity and an identifier addressing the MCVideo 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 MCVideo ID and the MCVideo client ID to the identity of the MCVideo 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 MCVideo ID, shall include in the SIP 200 (OK) response an application/vnd.3gpp.mcvideo-info+xml MIME body as specified in annex F.1 with an <multiple-devices-ind> element set to a value of "true".

7.3.3 SIP PUBLISH request for service authorisation and service settings

The MCVideo server shall support obtaining service authorization specific information from a SIP PUBLISH request for MCVideo 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.mcvideo-info+xml MIME body containing an <mcvideo-access-token> element and an <mcvideo-client-id> element;

the MCVideo 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 MCVideo 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 MCVideo user is specified in the <user-max-simultaneous-authorizations> element of the <anyExt> element contained in the <OnNetwork> element of the MCVideo user profile (see the user profile configuration document in 3GPP TS 24.484 [25]) if present shall check whether it has been reached. If reached, the MCVideo server shall send a SIP 486 (Busy Here) response towards the MCVideo client with the warning text set to: "166 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 MCVideo user profile (see the user profile configuration document in 3GPP TS 24.484 [25]), shall check if the number of maximum simultaneous authorizations supported for any MCVideo user as specified in the <max-simultaneous-authorizations> element of the <anyExt> element contained in the <OnNetwork> element of the MCVideo service configuration document (see the service configuration document in 3GPP TS 24.484 [25]) has been reached. If reached, the MCVideo server shall send a SIP 486 (Busy Here) response towards the MCVideo client with the warning text set to: "166 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 MCVideo ID as described in 3GPP TS 33.180 [8];

5) if service authorization was successful:

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

b) if the service authorization request was from an MCVideo user who is previously MCVideo service authorized on another MCVideo client (as determined by a comparison of the received MCVideo client ID with the MCVideo client ID of existing bindings), keep the current bindings and create a new binding between the MCVideo ID, MCVideo 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 MCVideo ID to the identity of the MCVideo 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 MCVideo server will store the binding MCVideo ID, MCVideo client ID, IMS public user identity and an identifier addressing the MCVideo server in an external database.

6) if service authorization was not successful, shall send a SIP 403 (Forbidden) response towards the MCVideo 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 [12] and if processing of the SIP request was not successful, do not continue with the rest of the steps;

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

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

a) if more than one binding exists for the MCVideo ID, an application/vnd.3gpp.mcvideo-info+xml MIME body as specified in annex F.1 with an <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 MCVideo client.

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

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

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

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

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

7.3.4 Receiving SIP PUBLISH request for MCVideo 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.mcvideo-info+xml MIME body containing an <mcvideo-request-uri> element and an <mcvideo-client-id> element;

The MCVideo 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 MCVideo 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 MCVideo ID in the <mcvideo-request-uri> element of the application/vnd.3gpp.mcvideo-info+xml exists at the MCVideo server;

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

6) if a binding does not exist between the IMS public user identity and the MCVideo 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 and not continue with any of the remaining steps;

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

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

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

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 MCVideo client.

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

NOTE 2: If only one MCVideo user profile is stored at the MCVideo server or only one MCVideo user profile is downloaded from the MCVideo user database, then by default this MCVideo user profile is the pre-selected MCVideo 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 MCVideo 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 [12] and if processing of the SIP request was successful, continue with the rest of the steps;

3) shall remove the MCVideo service settings;

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

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

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

7.3.6 Subscription to and notification of MCVideo service settings

7.3.6.1 Receiving subscription to MCVideo 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 MCVideo function of the served MCVideo user;

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

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

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

the MCVideo server:

1) shall identify the served MCVideo ID in the <mcvideo-request-uri> element of the application/vnd.3gpp.mcvideo-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 MCVideo function serving the MCVideo user, shall identify the originating MCVideo ID from public user identity in the P-Asserted-Identity header field of the SIP SUBSCRIBE request;

3) if the originating MCVideo ID is different than the served MCVideo 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 [11], IETF RFC 6665 [16] and IETF RFC 4354 [53].

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

7.3.6.2 Sending notification of change of MCVideo service settings

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

1) shall generate an application/poc-settings+xml MIME body as defined in 3GPP TS 24.379 [40] containing:

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

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

2) send a SIP NOTIFY request according to 3GPP TS 24.229 [11], IETF RFC 6665 [16] and IETF RFC 4354 [53] 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 MCVideo function received a Client Server Key (CSK) within a SIP REGISTER request for service authorisation or SIP PUBLISH request for service authorisation, the participating MCVideo function may decide to update the CSK. In this case, the participating MCVideo function shall perform a key download procedure for the CSK. The participating MCVideo function:

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

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.mcvideo" along with parameters "require" and "explicit" according to IETF RFC 3841 [20];

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

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 [8] in the body of the SIP MESSAGE request;

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

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 [53]. 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 [53] and:

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

2) contains one or more <entity> child element according to IETF RFC 4354 [53] 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>