6.2 MCVideo client procedures

24.2813GPPMission Critical Video (MCVideo) signalling controlProtocol specificationRelease 18TS

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

6.2.0 Distinction of requests at the MCVideo client

6.2.0.1 SIP MESSAGE request

The MCVideo client needs to distinguish between the following SIP MESSAGE requests:

– SIP MESSAGE request routed to the MCVideo client containing a Content-Type header field set to "application/vnd.3gpp.mcvideo-location-info+xml" and includes an XML body containing a Location root element containing a Configuration element. Such requests are known as "SIP MESSAGE request for location report configuration" in the present document;

– SIP MESSAGE request routed to the MCVideo client containing a Content-Type header field set to "application/vnd.3gpp.mcvideo-location-info+xml" and includes an XML body containing a Location root element containing a Request element. Such requests are known as "SIP MESSAGE request for location report request" in the present document.

– SIP MESSAGE request routed to the MCVideo client containing a Content-Type header field set to "application/vnd.3gpp.mcvideo -info+xml" and includes an XML body containing a <mcvideo-info> root element containing the <mcvideo-Params> element and an <anyExt> element containing the <request-type> element set to a value of "group-selection-change-request". Such requests are known as "SIP MESSAGE request for group selection change request for terminating client";

– SIP MESSAGE request routed to the MCVideo client containing a Content-Type header field set to "application/vnd.3gpp.mcvideo -info+xml" and includes an XML body containing a <mcvideo-info> root element containing the <mcvideo-Params> element and an <anyExt> element containing the <response-type> element set to a value of "group-selection-change-response". Such requests are known as "SIP MESSAGE request for group selection change response for terminating client";

– SIP MESSAGE request routed to the MCVideo client containing a Content-Type header field set to "application/mikey" and a CSB-ID containing a CSK-ID. Such requests are known as "SIP MESSAGE request for CSK download for terminating client";

– SIP MESSAGE requests routed to the MCVideo client with the Request-URI set to a public user identity of the MCVideo user that contains a <preconfigured-group> element in an application/vnd.3gpp.mcvideo-regroup+xml MIME body and a <regroup-action> element set to "create". Such requests are known as "SIP MESSAGE request to the MCVideo client to request creation of a regroup using preconfigured group" in the procedures in the present document;

– SIP MESSAGE requests routed to the MCVideo client with the Request-URI set to a public user identity of the MCVideo user that contains a <preconfigured-group> element in an application/vnd.3gpp.mcvideo-regroup+xml MIME body and a <regroup-action> element set to "remove". Such requests are known as "SIP MESSAGE request to the MCVideo client to request removal of a regroup using preconfigured group" in the procedures in the present document.

– SIP MESSAGE requests routed to the MCVideo client containing a Content-Type header field set to "application/vnd.3gpp.mcvideo-info+xml" and including an XML body containing a <mcvideo-info> root element containing the <mcvideo-Params> element and an <emergency-alert-area-ind> element. Such requests are known as "SIP MESSAGE request for notification of entry into or exit from an emergency alert area"; and

– SIP MESSAGE requests routed to the MCVideo client containing a Content-Type header field set to "application/vnd.3gpp.mcvideo-info+xml" and including an XML body containing a <mcvideo-info> root element containing the <mcvideo-Params> element and an <group-geo-area-ind> element. Such requests are known as "SIP MESSAGE request for notification of entry into or exit from a group geographic area".

6.2.1 SDP offer generation

The SDP offer shall contain two SDP media-level sections for MCVideo video media according to 3GPP TS 24.229 [11] and, if transmission control shall be used during the session, shall contain one SDP media-level section for a media- transmission control entity according to 3GPP TS 24.581 [5].

When composing an SDP offer according to 3GPP TS 24.229 [11] the MCVideo client:

1) shall set the IP address of the MCVideo client for the offered MCVideo video media stream and, if transmission control shall be used, for the offered media-transmission control entity;

NOTE: If the MCVideo client is behind a NAT the IP address and port included in the SDP offer can be a different IP address and port than the actual IP address and port of the MCVideo client depending on the NAT traversal method used by the SIP/IP Core.

2) shall include an "m=audio" media-level section for the MCVideo media stream consisting of:

a) the port number for the media stream selected; and

b) the codec(s) and media parameters and attributes with the following clarification:

i) if the MCVideo client is initiating a call to a group identity;

ii) if the <preferred-voice-encodings> element is present in the group document retrieved by the group management client as specified in 3GPP TS 24.481 [24] containing an <encoding> element with a "name" attribute; and

iii) if the MCVideo client supports the encoding name indicated in the value of the "name" attribute;

then the MCVideo client:

i) shall insert the value of the "name" attribute in the <encoding name> field of the "a=rtpmap" attribute as defined in IETF RFC 4566 [2]; and

c) "i=" field set to "audio component of MCVideo" according to 3GPP TS 24.229 [11];

3) shall include an "m=video" media-level section for the MCVideo media stream consisting of:

a) the port number for the media stream selected; and

b) the codec(s) and media parameters and attributes with the following clarification:

i) if the MCVideo client is initiating a call to a group identity;

ii) if the <preferred-video-encodings> element is present in the group document retrieved by the group management client as specified in 3GPP TS 24.481 [24] containing an <encoding> element with a "name" attribute; and

iii) if the MCVideo client supports the encoding name indicated in the value of the "name" attribute;

then the MCVideo client:

i) shall insert the value of the "name" attribute in the <encoding name> field of the "a=rtpmap" attribute as defined in IETF RFC 4566 [2];

c) if the SDP offer is for an ambient viewing call:

i) if this is a remotely initiated ambient viewing call, include an "a=recvonly" attribute; or

ii) if this is a locally initiated ambient viewing call, include an "a=sendonly" attribute; and

d) "i=" field set to "video component of MCVideo" according to 3GPP TS 24.229 [11];

4) if transmission control shall be used during the session, shall include an "m=application" media-level section as specified in 3GPP TS 24.581 [5] clause 12 for a media-transmission control entity, consisting of:

a) the port number for the media-transmission control entity selected as specified in 3GPP TS 24.581 [5]; and

b) the ‘fmtp’ attributes as specified in 3GPP TS 24.581 [5] clause 14; and

5) if end-to-end security is required for a private call and the SDP offer is not for establishing a pre-established session, shall include the MIKEY-SAKKE I_MESSAGE in an "a=key-mgmt" attribute as a "mikey" attribute value in the SDP offer as specified in IETF RFC 4567 [6].

6.2.2 SDP answer generation

When the MCVideo client receives an initial SDP offer for an MCVideo session, the MCVideo client shall process the SDP offer and shall compose an SDP answer according to 3GPP TS 24.229 [11].

When composing an SDP answer, the MCVideo client:

1) shall accept the MCVideo video media stream in the SDP offer;

2) shall set the IP address of the MCVideo client for the accepted MCVideo video media stream and, if included in the SDP offer, for the accepted media- transmission control entity;

NOTE: If the MCVideo client is behind a NAT the IP address and port included in the SDP answer can be a different IP address and port than the actual IP address and port of the MCVideo client depending on the NAT traversal method used by the SIP/IP Core.

3) shall include an "m=audio" media-level section for the accepted MCVideo video media stream consisting of:

a) the port number for the media stream;

b) media-level attributes as specified in 3GPP TS 24.229 [11]; and

c) "i=" field set to "audio component of MCVideo" according to 3GPP TS 24.229 [11]; and

4) shall include an "m=video" media-level section for the accepted MCVideo video media stream consisting of:

a) the port number for the media stream;

b) media-level attributes as specified in 3GPP TS 24.229 [11]; and

c) "i=" field set to "video component of MCVideo" according to 3GPP TS 24.229 [11]; and

5) if included in the SDP offer, shall include the media-level section of the offered media-transmission control entity consisting of:

a) an "m=application" media-level section as specified in 3GPP TS 24.581 [5] clause 12; and

b) ‘fmtp’ attributes as specified in 3GPP TS 24.581 [5] clause 14.

6.2.3 Commencement modes

6.2.3.1 Automatic commencement mode

6.2.3.1.1 Automatic commencement mode for private calls

When performing the automatic commencement mode procedures, the MCVideo client:

1) shall accept the SIP INVITE request and generate a SIP 200 (OK) response according to rules and procedures of 3GPP TS 24.229 [11];

2) shall include the option tag "timer" in a Require header field of the SIP 200 (OK) response;

3) shall include the g.3gpp.mcvideo media feature tag in the Contact header field of the SIP 200 (OK) response;

4) shall include 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 200 (OK) response;

5) shall include the Session-Expires header field in the SIP 200 (OK) response and start the SIP session timer according to IETF RFC 4028 [23]. The "refresher" parameter in the Session-Expires header field shall be set to "uas";

6) shall, if the incoming SIP INVITE request contains a Replaces header field, include in the SDP answer in the SIP 200 (OK) response to the SDP offer the parameters used for the pre-established session identified by the contents of the Replaces header field;

7) shall, if the incoming SIP INVITE request does not contain a Replaces header field, include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP INVITE request according to 3GPP TS 24.229 [11] with the clarifications given in clause 6.2.2;

NOTE: In the case of a new emergency call where the terminating client is using a pre-established session, the SIP INVITE request containing a Replaces header is used to replace the pre-established session.

8) shall send the SIP 200 (OK) response towards the MCVideo server according to rules and procedures of 3GPP TS 24.229 [11];

9) shall, if the incoming SIP INVITE request contains a Replaces header field, release the pre-established session identified by the contents of the Replaces header field; and

10) shall interact with the media plane as specified in 3GPP TS 24.581 [5].

When NAT traversal is supported by the MCVideo client and when the MCVideo client is behind a NAT, generation of SIP responses is done as specified in this clause and as specified in IETF RFC 5626 [35].

6.2.3.1.2 Automatic commencement mode for group calls

When performing the automatic commencement mode procedures, the MCVideo client shall follow the procedures in clause 6.2.3.1.1 with the following clarification:

– The MCVideo client may include a P-Answer-State header field with the value "Confirmed" as specified in IETF RFC 4964 [30] in the SIP 200 (OK) response.

6.2.3.2 Manual commencement mode

6.2.3.2.1 Manual commencement mode for private calls

When performing the manual commencement mode procedures:

1) if the MCVideo user declines the MCVideo session invitation the MCVideo client shall send a SIP 480 (Temporarily Unavailable) response towards the MCVideo server with the warning text set to: "110 user declined the call invitation" in a Warning header field as specified in clause 4.4, and not continue with the rest of the steps in this clause.

The MCVideo client:

1) shall accept the SIP INVITE request and generate a SIP 180 (Ringing) response according to rules and procedures of 3GPP TS 24.229 [11];

2) shall include the option tag "timer" in a Require header field of the SIP 180 (Ringing) response;

3) shall include the g.3gpp.mcvideo media feature tag in the Contact header field of the SIP 180 (Ringing) response;

4) shall include 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 180 (Ringing) response; and

5) shall send the SIP 180 (Ringing) response to the MCVideo server.

When sending the SIP 200 (OK) response to the incoming SIP INVITE request, the MCVideo client shall follow the procedures in clause 6.2.3.1.1.

6.2.3.2.2 Manual commencement mode for group calls

When performing the manual commencement mode procedures:

1) the terminating MCVideo client may automatically generate a SIP 183 (Session Progress) in accordance with 3GPP TS 24.229 [11], prior to the MCVideo user’s acknowledgement; and

2) if the MCVideo user declines the MCVideo session invitation the MCVideo client shall send a SIP 480 (Temporarily Unavailable) response towards the MCVideo server with the warning text set to: "110 user declined the call invitation" in a Warning header field as specified in clause 4.4, and not continue with the rest of the steps in this clause.

When generating a SIP 183 (Session Progress) response, the MCVideo client:

1) shall include the following in the Contact header field:

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

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

2) may include a P-Answer-State header field with the value "Unconfirmed" as specified in IETF RFC 4964 [30];

When sending the SIP 200 (OK) response to the incoming SIP INVITE request, the MCVideo client shall follow the procedures in clause 6.2.3.1.2.

6.2.4 Leaving an MCVideo session initiated by MCVideo client

6.2.4.1 On-demand session case

Upon receiving a request from an MCVideo user to leave an MCVideo session established using on-demand session signalling, the MCVideo client:

1) shall interact with the media plane as specified in 3GPP TS 24.581 [5];

2) shall generate a SIP BYE request according to 3GPP TS 24.229 [11];

3) shall set the Request-URI to the MCVideo session identity to leave; and

4) shall send a SIP BYE request towards MCVideo server according to 3GPP TS 24.229 [11].

Upon receiving a SIP 200 (OK) response to the SIP BYE request, the MCVideo client shall interact with the media plane as specified in 3GPP TS 24.581 [5].

6.2.5 Releasing an MCVideo session initiated by MCVideo client

6.2.5.1 On-demand session case

When the MCVideo client wants to release an MCVideo session established using on-demand session signalling, the MCVideo client:

1) shall interact with the media plane as specified in 3GPP TS 24.581 [5];

2) shall generate a SIP BYE request according to 3GPP TS 24.229 [11];

3) shall set the Request-URI to the MCVideo session identity to release; and

4) shall send a SIP BYE request towards MCVideo server according to 3GPP TS 24.229 [11].

Upon receiving a SIP 200 (OK) response to the SIP BYE request, the MCVideo client shall interact with the media plane as specified in 3GPP TS 24.581 [5].

6.2.6 Receiving an MCVideo session release request

Upon receiving a SIP BYE request, the MCVideo client:

1) shall interact with the media plane as specified in 3GPP TS 24.581[5]; and

2) shall send SIP 200 (OK) response towards MCVideo server according to 3GPP TS 24.229 [11].

6.2.7 Void

6.2.8 Priority call conditions

6.2.8.0 General

This clause contains common procedures to be used for MCVideo emergency group calls and MCVideo imminent peril group calls.

6.2.8.1 MCVideo emergency group call conditions

6.2.8.1.1 SIP INVITE request for originating MCVideo emergency group calls

This clause is referenced from other procedures.

When the MCVideo emergency state is set and this MCVideo user and MCVideo group are authorised to initiate MCVideo emergency group calls as determined by the procedures of clause 6.2.8.1.8, the MCVideo client:

1) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body in the SIP INVITE request, an <emergency-ind> element set to "true" and if the MCVideo emergency group call state is set to "MVEGC 1: emergency-gc-capable", shall set the MCVideo emergency group call state to "MVEGC 2: emergency-call-requested";

2) if the MCVideo user has also requested an MCVideo emergency alert to be sent and this is an authorised request for MCVideo emergency alert as determined by the procedures of clause 6.2.8.1.6, and the MCVideo emergency alert state is set to "MVEA 1: no-alert", shall:

a) set the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to "true" and set the MCVideo emergency alert state to "MVEA 2: emergency-alert-confirm-pending"; and

b) perform the procedures specified in clause 6.2.9.1 for the MCVideo emergency alert trigger;

3) if the MCVideo user has not requested an MCVideo emergency alert to be sent and the MCVideo emergency alert state is set to "MVEA 1: no-alert", shall set the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to "false"; and

4) if the MCVideo client emergency group state of the group is set to a value other than "MVEG 2: in-progress" set the MCVideo client emergency group state of the MCVideo group to "MVEG 3: confirm-pending".

NOTE 1: This is the case of an MCVideo user already being in the MCVideo emergency state it initiated previously while originating an MCVideo emergency group call or MCVideo emergency alert. All group calls the MCVideo user originates while in MCVideo emergency state will be MCVideo emergency group calls.

When the MCVideo emergency state is clear and the MCVideo emergency group call state is set to "MVEGC 1: emergency-gc-capable" and the MCVideo user is authorised to initiate an MCVideo emergency group call on the targetted MCVideo group as determined by the procedures of clause 6.2.8.1.8, the MCVideo client shall set the MCVideo emergency state and perform the following actions:

1) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body in the SIP INVITE request an <emergency-ind> element set to "true" and set the MCVideo emergency group call state to "MVEGC 2: emergency-call-requested" state;

a) include in the application/vnd.3gpp.mcvideo-info+xml MIME body the <alert-ind> element set to "true" and set the MCVideo emergency alert state to "MVEA 2: emergency-alert-confirm-pending"; and

b) perform the procedures specified in clause 6.2.9.1 for the MCVideo emergency alert trigger;

3) if the MCVideo user has not requested an MCVideo emergency alert to be sent, shall set the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to "false"; and

4) if the MCVideo client emergency group state of the group is set to a value other than "MVEG 2: in-progress" shall set the MCVideo client emergency group state of the MCVideo group to "MVEG 3: confirm-pending".

NOTE 2: This is the case of an initial MCVideo emergency group call and optionally an MCVideo emergency alert being sent. As the MCVideo emergency state is not sent, there is no MCVideo emergency alert outstanding.

NOTE 3: An MCVideo group call originated by an affiliated member of an MCVideo group which is in an in-progress emergency state (as tracked on the MCVideo client by the MCVideo client emergency group state) but is not in an MCVideo emergency state of their own will also be an MCVideo emergency group call. The <emergency-ind> and <alert-ind> elements of the application/vnd.3gpp.mcvideo-info+xml MIME body do not need to be included in this case and hence no action needs to be taken in this clause.

6.2.8.1.2 Resource-Priority header field for MCVideo emergency group calls

This clause is referenced from other procedures.

If the MCVideo emergency group call state is set to either "MVEGC 2: emergency-call-requested" or "MVEGC 3: emergency-call-granted" and this is an authorised request for an MCVideo emergency group call as determined by the procedures of clause 6.2.8.1.8, or the MCVideo client emergency group state of the group is set to "MVEG 2: in-progress", the MCVideo client shall include in the SIP INVITE request a Resource-Priority header field populated with the values for an MCVideo emergency group call as specified in clause 6.2.8.1.15.

NOTE: The MCVideo client ideally would not need to maintain knowledge of the in-progress emergency state of the group (as tracked on the MCVideo client by the MCVideo client emergency group state) but can use this knowledge to provide a Resource-Priority header field set to emergency level priority, which starts the infrastructure priority adjustment process sooner than otherwise would be the case.

If this is an authorised request to cancel the MCVideo emergency group call as determined by the procedures of clause 6.2.8.1.7, and the MCVideo client emergency group state of the group is "no-emergency" or "cancel-pending", the MCVideo client shall include in the SIP INVITE request a Resource-Priority header field populated with the values for a normal MCVideo group call as specified in clause 6.2.8.1.15.

6.2.8.1.3 SIP re-INVITE request for cancelling MCVideo in-progress emergency group state

This clause is referenced from other procedures.

If the MCVideo emergency group call state is set to "MVEGC 3: emergency-call-granted" and the MCVideo emergency alert state is set to "MVEA 1: no-alert", the MCVideo client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [11] with the clarifications given below.

NOTE 1: This procedure assumes that the calling procedure has verified that the MCVideo user has made an authorised request for cancelling MCVideo in-progress emergency group state of the group.

The MCVideo client:

1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcvideo-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false";

2) shall clear the MCVideo emergency state; and

3) shall set MCVideo emergency group state of the MCVideo group to "MVEG 3: cancel-pending"

NOTE 2: This is the case of an MCVideo user who has initiated an MCVideo emergency group call and wants to cancel it.

If the MCVideo emergency group call state is set to "MVEGC 3: emergency-call-granted" and the MCVideo emergency alert state is set to a value other than "MVEA 1: no-alert" and the MCVideo user has indicated only the MCVideo emergency group call should be cancelled, the MCVideo client:

1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcvideo-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false"; and

2) shall set the MCVideo emergency group state of the MCVideo group to "MVEG 3: cancel-pending".

NOTE 3: This is the case of an MCVideo user has initiated both an MCVideo emergency group call and an MCVideo emergency alert and wishes to only cancel the MCVideo emergency group call. This leaves the MCVideo emergency state set.

If the MCVideo emergency group call state is set to "MVEGC 3: emergency-call-granted" and the MCVideo emergency alert state is set to a value other than "MVEA 1: no-alert" and the MCVideo user has indicated that the MCVideo emergency alert on the MCVideo group should be cancelled in addition to the MCVideo emergency group call, the MCVideo client:

1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcvideo-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false";

2) shall if this is an authorised request to cancel an MCVideo emergency alert as determined by the procedures of clause 6.2.8.1.6:

a) include in the application/vnd.3gpp.mcvideo-info+xml MIME body an <alert-ind> element set to "false";

b) set the MCVideo emergency alert state to "MVEA 4: Emergency-alert-cancel-pending"; and

c) clear the MCVideo emergency state;

3) should, if this is not an authorised request to cancel an MCVideo emergency alert as determined by the procedures of clause 6.2.8.1.6, indicate to the MCVideo user that they are not authorised to cancel the MCVideo emergency alert; and

4) shall set the MCVideo emergency group state of the MCVideo group to "MVEG 3: cancel-pending".

NOTE 4: This is the case of an MCVideo user that has initiated both an MCVideo emergency group call and an MCVideo emergency alert and wishes to cancel both.

6.2.8.1.4 Receiving a SIP 2xx response to a SIP request for a priority call

In the procedures in this clause, a priority group call refers to an MCVideo emergency group call or an MCVideo imminent peril group call.

On receiving a SIP 2xx response to a SIP request for a priority group call, the MCVideo client:

1) if the MCVideo emergency group call state is set to "MVEGC 2: emergency-call-requested" or "MVEGC 3: emergency-call-granted":

a) shall set the MCVideo client emergency group state of the group to "MVEG 2: in-progress" if it was not already set;

b) if the MCVideo emergency alert state is set to "MVEA 2: emergency-alert-confirm-pending" and the SIP 2xx response to the SIP request for a priority group call does not contain a Warning header field as specified in clause 4.4 with the warning text containing the mcvideo-warn-code set to "149", shall set the MCVideo emergency alert state to "MVEA 3: emergency-alert-initiated;

c) shall set the MCVideo emergency group call state to "MVEGC 3: emergency-call-granted"; and

d) shall set the MCVideo imminent peril group call state to "MVIGC 1: imminent-peril-capable" and the MCVideo imminent peril group state to "MVIG 1: no-imminent-peril"; or

2) if the MCVideo imminent peril group call state is set to "MVIGC 2: imminent-peril-call-requested" or "MVIGC 3: imminent-peril-call-granted" and the SIP 2xx response to the SIP request for an imminent peril group call does not contain a Warning header field as specified in clause 4.4 with the warning text containing the mcvideo-warn-code set to "149":

a) set the MCVideo imminent peril group call state to "MVIGC 3: imminent-peril-call-granted"; and

b) set the MCVideo imminent peril group state to "MVIG 2: in-progress".

6.2.8.1.5 Receiving a SIP 4xx response, SIP 5xx response or SIP 6xx response to a SIP request for a priority group call

In the procedures in this clause, a priority group call refers to an MCVideo emergency group call or an MCVideo imminent peril group call.

Upon receiving a SIP 4xx response, SIP 5xx response or a SIP 6xx response to a SIP request for a priority group call the MCVideo client:

1) if the MCVideo emergency group call state is set to "MVEGC 2: emergency-call-requested" or "MVEGC 3: emergency-call-granted":

a) shall set the MCVideo emergency group call state to "MVEGC 1: emergency-gc-capable";

b) if the MCVideo client emergency group state of the group is "MVEG 3: confirm-pending" shall set the MCVideo client emergency group state of the group to "MVEG 1: no-emergency"; and

c) if the sent SIP request for a priority group call contained an application/vnd.3gpp.mcvideo-info+xml MIME body with an <alert-ind> element set to a value of "true", shall set the MCVideo emergency alert state to "MVEA 1: "no-alert"; and

2) if the MCVideo imminent peril group call state is set to "MVIGC 2: imminent-peril-call-requested" or "MVIGC 3: imminent-peril-call-granted":

a) shall set the MCVideo imminent peril group state to "MVIG 1: no-imminent-peril"; and

b) shall set the MCVideo imminent peril group call state to "MVIGC 1: imminent-peril-capable".

6.2.8.1.6 Determining authorisation for initiating or cancelling an MCVideo emergency alert

If the MCVideo client receives a request from the MCVideo user to send an MCVideo emergency alert and:

1) if the <allow-activate-emergency-alert> element of the <actions> element of a <rule> element of the <ruleset> element of the MCVideo user profile document identified by the MCVideo ID of the calling MCVideo user (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "true"; and

2) if the "entry-info" attribute of the <entry> element of the <EmergencyAlert> element contained within the <MCVideo-group-call> element of the MCVideo user profile document is set to a value of:

a) "DedicatedGroup", and if the <uri-entry> element of the <entry> element of the <EmergencyAlert> element of the <MCVideo-group-call> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) contains the MCVideo group identity of the MCVideo group targeted by the calling MCVideo user; or

b) "UseCurrentlySelectedGroup" and the <MCVideo-allow-emergency-alert> element of the <actions> element of a <rule> element of the <ruleset> element of the <list-service> element of the group document identified by the MCVideo group identity targeted for the emergency alert is set to a value of "true" as specified in 3GPP TS 24.481 [24];

then the MCVideo emergency alert request shall be considered to be an authorised request for an MCVideo emergency alert. In all other cases, it shall be considered to be an unauthorised request for an MCVideo emergency alert.

If the MCVideo client receives a request from the MCVideo user to cancel an MCVideo emergency alert to an MCVideo group, and if the <allow-cancel-emergency-alert> element of the <actions> element of a <rule> element of the <ruleset> element of the MCVideo user profile document identified by the MCVideo ID of the calling MCVideo user (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "true", then the MCVideo emergency alert cancellation request shall be considered to be an authorised request to cancel an MCVideo emergency alert. In all other cases, it shall be considered to be an unauthorised request to cancel an MCVideo emergency alert.

6.2.8.1.7 Determining authorisation for cancelling the in-progress emergency state of an MCVideo group

When the MCVideo client receives a request from the MCVideo user to cancel the in-progress emergency state of a group the MCVideo client and:

1) if the <allow-cancel-group-emergency> element of the <ruleset> element of the MCVideo user profile document identified by the MCVideo ID of the calling MCVideo user (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "true", then the in-progress emergency group state cancel request shall be considered to be an authorised request for in-progress emergency group state cancellation; or

2) if the <allow-cancel-group-emergency> element of the <ruleset> element of the MCVideo user profile document identified by the MCVideo ID of the calling MCVideo user (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "false", then the in-progress emergency group state cancel request shall be considered to be an unauthorised request for in-progress emergency group state cancellation.

6.2.8.1.8 Determining authorisation for originating a priority group call

When the MCVideo client receives a request from the MCVideo user to originate an MCVideo emergency group call the MCVideo client shall check the following:

1) if the <allow-emergency-group-call> element of the <ruleset> element of the MCVideo user profile document identified by the MCVideo ID of the calling user (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "true" and

a) if the "entry-info" attribute of the <entry> element of the <MCVideoGroupInitiation> element of the <EmergencyCall> element contained within the <MCVideo-group-call> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "DedicatedGroup" and if the <uri-entry> element of the <entry> element of the <MCVideoGroupInitiation> element contains the identity of the MCVideo group targeted by the calling MCVideo user; or

b) if the "entry-info" attribute of the <entry> element of the <MCVideoGroupInitiation> element of the <EmergencyCall> contained within the <MCVideo-group-call> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "UseCurrentlySelectedGroup";

then the MCVideo emergency group call request shall be considered to be an authorised request for an MCVideo emergency group call;

In all other cases, the request to originate an MCVideo emergency group call shall be considered to be an unauthorised request to originate an MCVideo emergency group call.

When the MCVideo client receives a request from the MCVideo user to originate an MCVideo imminent peril group call the MCVideo client shall check the following:

1 if the <allow-imminent-peril-call> element of <ruleset> element of the MCVideo user profile document identified by the MCVideo ID of the calling user (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "true" and:

a) if the "entry-info" attribute of the <entry> element of the <MCVideoGroupInitiation> element contained within the <ImminentPerilCall> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "DedicatedGroup" and if the <MCVideoGroupInitiation> element contains the identity of the MCVideo group targeted by the calling MCVideo user; or

b) if the "entry-info" attribute of the <entry> element of the <MCVideoGroupInitiation> element contained within the <ImminentPerilCall> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "UseCurrentlySelectedGroup";

then the MCVideo imminent peril group call request shall be considered to be an authorised request for an MCVideo imminent peril group call;

In all other cases, the request to originate an MCVideo imminent peril group call shall be considered to be an unauthorised request to originate an MCVideo imminent peril group call.

6.2.8.1.9 SIP request for originating MCVideo imminent peril group calls

This clause is referenced from other procedures.

When the MCVideo client receives a request from the MCVideo user to originate an MCVideo imminent peril group call, and this is an authorised request for an MCVideo imminent peril group call as determined by the procedures of clause 6.2.8.1.8, the MCVideo client:

1) if the MCVideo client imminent peril group state is set to "MVIGC 1: imminent-peril-capable" and the in-progress emergency state of the group is set to a value of "false":

a) shall include in the SIP request a MIME mcvideoinfo body as defined in Annex F.1 with the <imminentperil-ind> element set to "true" and set the MCVideo emergency group call state to "MVIGC 2: imminent-peril-call-requested" state; and

b) if the MCVideo client imminent peril group state of the group is set to a value other than "MVIG 2: in-progress" shall set the MCVideo client emergency group state of the MCVideo group to "MVIG 3: confirm-pending".

NOTE: An MCVideo group call originated by an affiliated member of an MCVideo group which is in an in-progress imminent peril state (as tracked on the MCVideo client by the MCVideo client imminent peril group state) will also have the priority associated with MCVideo imminent peril group calls. The <imminentperil-ind> element of the MIME mcvideoinfo body does not need to be included in this case, nor do any state changes result and hence no action needs to be taken in this clause.

6.2.8.1.10 Determining authorisation for cancelling an imminent peril group call

When the MCVideo client receives a request from the MCVideo user to cancel an MCVideo imminent peril group call the MCVideo client shall:

1) if the <allow-cancel-imminent-peril> element of the <ruleset> element of the MCVideo user profile document identified by the MCVideo ID of the calling user (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "true" the MCVideo imminent peril call cancellation request shall be considered to be an authorised request to cancel the MCVideo imminent peril group call; or

2) if the <allow-cancel-imminent-peril> element of the <ruleset> element of the MCVideo user profile document identified by the MCVideo ID of the calling user (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "false" the MCVideo imminent peril call cancellation request shall be considered to be an unauthorised request to cancel the MCVideo imminent peril group call.

6.2.8.1.11 SIP re-INVITE request for cancelling MCVideo in-progress imminent peril group state

This clause is referenced from other procedures.

If the MCVideo imminent peril group call state is set to "MVIGC 3: imminent-peril-call-granted" or the MCVideo imminent peril group state of the MCVideo group is set to "MVIG 2: in-progress", the MCVideo client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [11] with the clarifications given below.

NOTE 1: This procedure assumes that the calling procedure has verified that the MCVideo user has made an authorised request for cancelling the in-progress imminent peril group state of the group.

The MCVideo client:

1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcvideo-info+xml MIME body as defined in clause F.1 with the <imminentperil-ind> element set to "false"; and

2) shall set MCVideo imminent peril group state of the MCVideo group to "MVIG 3: cancel-pending".

NOTE 2: This is the case of an MCVideo user who has initiated an MCVideo imminent peril group call and wants to cancel it, or another authorised member of the group who wishes to cancel the in-progress imminent peril state of the group.

6.2.8.1.12 Resource-Priority header field for MCVideo imminent peril group calls

This clause is referenced from other procedures.

When the MCVideo imminent peril group call state is set "MVIGC 2: imminent-peril-call-requested" or "MVIGC 3: imminent-peril-call-granted" and this MCVideo user and group is authorised to originate MCVideo imminent peril group calls as determined by the procedures of clause 6.2.8.1.8, or the MCVideo client imminent peril state of the group is set to "MVIG 2: in-progress", the MCVideo client:

1) shall include in the SIP INVITE request a Resource-Priority header field populated with the values for an MCVideo imminent peril group call as specified in clause 6.2.8.1.15.

NOTE: The MCVideo client ideally would not need to maintain knowledge of the in-progress imminent peril state of the group (as tracked on the MCVideo client by the MCVideo client imminent peril group state) but can use this knowledge to provide a Resource-Priority header field set to imminent peril level priority, which starts the infrastructure priority adjustment process sooner than otherwise would be the case.

When the MCVideo imminent peril group call state is set to "MVIGC 1: imminent-peril-gc-capable" and the MCVideo user is authorised to cancel MCVideo imminent peril group calls as determined by the procedures of clause 6.2.8.1.10, or the MCVideo client imminent peril group state of the group is "MVIG 1: no-imminent-peril" or "MVIG 3: cancel-pending", the MCVideo client:

1) shall include in the SIP INVITE request a Resource-Priority header field populated with the values for a normal MCVideo group call as specified in clause 6.2.8.1.15.

6.2.8.1.13 Receiving a SIP INFO request in the dialog of a SIP request for a priority group call

This clause is referenced from other procedures.

Upon receiving a SIP INFO request within the dialog of the SIP request for a priority group call:

– with the Info-Package header field containing the g.3gpp.mcvideo-info package name;

– with the application/vnd.3gpp.mcvideo-info+xml MIME body associated with the info package according to IETF RFC 6086 [21]; and

– with one or more of the <alert-ind>, <imminentperil-ind> and <emergency-ind> elements set in the application/vnd.3gpp.mcvideo-info+xml MIME body;

the MCVideo client:

1) shall send a SIP 200 (OK) response to the SIP INFO request as specified in 3GPP TS 24.229 [11];

2) if the MCVideo emergency group call state is set to "MVEGC 3: emergency-call-granted":

a) if the MCVideo emergency alert state is set to "MVEA 2: emergency-alert-confirm-pending":

i) if the <alert-ind> element is set to a value of "false", shall set the MCVideo emergency alert state to "MVEA 1: no-alert"; and

ii) if the <alert-ind> element is set to a value of "true", shall set the MCVideo emergency alert state to "MVEA 3: emergency-alert-initiated";

3) if the MCVideo imminent peril group call state is set to "MVIGC 2: imminent-peril-call-requested" or "MVIGC 3: imminent-peril-call-granted":

a) if the <imminentperil-ind> element is set to a value of "false" and an <emergency-ind> element is set to a value of "true", shall:

i) set the MCVideo imminent peril group state to "MVIG 1: no-imminent-peril";

ii) set the MCVideo imminent peril group call state to "MVIGC 1: imminent-peril-capable"; and

iii) set the MCVideo client emergency group state of the group to "MVEG 2: in-progress"; and

NOTE 1: This is the case of an MCVideo client attempting to make an imminent peril group call when the group is in an in-progress emergency group state. The MCVideo client will then receive a notification that the imminent peril call request was denied, however they will be participating at the emergency level priority of the group. This could occur for example when an MCVideo client requests an imminent peril call to a group that they are not currently affiliated with.

NOTE 2: the MCVideo client emergency group state above is the MCVideo client’s view of the in-progress emergency state of the group.

4) if the SIP request for a priority group call sent by the MCVideo client did not contain an <originated-by> element and if the MCVideo emergency alert state is set to "MVEA 4: Emergency-alert-cancel-pending":

a) if the <alert-ind> element contained in the SIP INFO request is set to a value of "true", shall set the MCVideo emergency alert state to "MVEA 3: emergency-alert-initiated"; and

b) if the <alert-ind> element contained in the SIP INFO request is set to a value of "false", shall set the MCVideo emergency alert state to "MVEA 1: no-alert".

6.2.8.1.14 SIP re-INVITE request for cancelling the in-progress emergency group state of a group by a third-party

This clause is referenced from other procedures.

Upon receiving an authorised request to cancel an in-progress emergency group state of a group as determined by the procedures of clause 6.2.8.1.7 from an MCVideo user, the MCVideo client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [11] with the clarifications given below.

The MCVideo client:

1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcvideo-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false";

2) shall set MCVideo emergency group state of the MCVideo group to "MVEG 3: cancel-pending"; and

3) if the MCVideo user has indicated that an MCVideo emergency alert on the MCVideo group originated by another MCVideo user should be cancelled and this is an authorised request for an MCVideo emergency alert cancellation as determined by the procedures of clause 6.2.8.1.6:

a) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body an <alert-ind> element set a value of "false"; and

b) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body an <originated-by> element set to the MCVideo ID of the MCVideo user who originated the MCVideo emergency alert.

NOTE: When an MCVideo emergency alert is cancelled by a MCVideo user other than its originator, the <originated-by> element is needed to identify which MCVideo emergency alert is being cancelled, as more than one MCVideo user could have originated emergency alerts to the same group.

6.2.8.1.15 Retrieving Resource-Priority header field values

This clause is referenced from other procedures.

When determining the Resource-Priority header field namespace and priority values as specified in IETF RFC 8101 [38] for an MCVideo emergency group call or MCVideo emergency private call the MCVideo client:

1) shall retrieve the value of the <resource-priority-namespace> element contained in the <emergency-resource-priority> element contained in the <OnNetwork> element of the MCVideo service configuration document ; and

2) shall retrieve the value of the <resource-priority-priority> element contained in the <emergency-resource-priority> element contained in the <OnNetwork> element of the MCVideo service configuration document .

When determining the Resource-Priority header field namespace and priority values as specified in IETF RFC 8101 [38] for an MCVideo imminent peril group call the MCVideo client:

1) shall retrieve the value of the <resource-priority-namespace> element contained in the <imminent-peril-resource-priority> element contained in the <OnNetwork> element of the MCVideo service configuration document; and

2) shall retrieve the value of the <resource-priority-priority> element contained in the <imminent-peril-resource-priority> element contained in the <OnNetwork> element of the MCVideo service configuration document.

When determining the Resource-Priority header field namespace and priority values as specified in IETF RFC 8101 [38] for a normal MCVideo group or private call the MCVideo client:

1) shall retrieve the value of the <resource-priority-namespace> element contained in the <normal-resource-priority> element contained in the <OnNetwork> element of the MCVideo service configuration document ; and

2) shall retrieve the value of the <resource-priority-priority> element contained in the <normal-resource-priority> element contained in the <OnNetwork> element of the MCVideo service configuration document .

NOTE: The "normal" Resource-Priority header field value is needed to return to a normal priority value from a priority value adjusted for an MCVideo emergency group or private call or an MCVideo imminent peril group call. The "normal" priority received from the EPS by use of the "normal" Resource-Priority header field value is expected to be the same as the "normal" priority received from the EPS when initiating a call with no Resource-Priority header field included.

6.2.8.1.16 Resource-priority header field namespaces for MCVideo

The Resource-Priority header field is specified as per IETF RFC 4412 [33]. The Resource-Priority namespace for MCVideo emergency group call, MCVideo emergency private call, MCVideo imminent peril group call, normal MCVideo group or private call, shall reuse the namespace for Mission Critical Push-to-Talk, which is specified in IETF RFC 8101 [38].

6.2.8.1.17 Priority group call conditions upon receiving call release

This clause is referenced from other procedures.

Upon receiving a request to release the MCVideo emergency group call or an MCVideo imminent peril group call in an MCVideo group session is in-progress or is in the process of being established:

1) if the MCVideo emergency group call state is set to "MVEGC 2: emergency-call-requested":

a) shall set the MCVideo emergency group call state to "MVEGC 1: emergency-gc-capable";

b) if the MCVideo client emergency group state of the group is "MVEG 3: confirm-pending" shall set the MCVideo client emergency group state of the group to "MVEG 1: no-emergency"; and

c) if the MCVideo emergency alert state is set to "MVEA 2: emergency-alert-confirm-pending" shall set the MCVideo emergency alert state to "MVEA 1: "no-alert"; and

2) if the MCVideo imminent peril group call state is set to "MVIGC 2: imminent-peril-call-requested":

a) if the MCVideo imminent peril group call state of the group is "MVIG 3: confirm-pending", shall set the MCVideo imminent peril group state to "MVIG 1: no-imminent-peril"; and

b) shall set the MCVideo imminent peril group call state to "MVIGC 1: imminent-peril-capable".

6.2.8.1.18 Emergency private call conditions upon receiving call release

This clause is referenced from other procedures.

Upon receiving a request to release the MCVideo session when an MCVideo emergency private call is in-progress or is in the process of being established:

1) if the MCVideo emergency private call state is set to "MVEPC 2: emergency-call-requested":

a) shall set the MCVideo emergency private call state to "MVEPC 1: emergency-pc-capable";

b) if the MCVideo emergency private priority state of the private call is "MVEPP 3: confirm-pending" shall set the MCVideo emergency private priority state of the private call to "MVEPP 1: no-emergency"; and

c) if the MCVideo private emergency alert state is set to "MVPEA 2: emergency-alert-confirm-pending shall set the MCVideo private emergency alert state to "MVPEA 1: no-alert".

6.2.8.2 Request for an originating broadcast group call

NOTE: This clause is referenced from other procedures.

When the MCVideo user initiates a broadcast group call, the MCVideo client:

1) in the case of the prearranged group call is initiated on-demand, shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body the <broadcast-ind> element set to "true" as defined in clause F.1; and

2) in the case the prearranged group call is initiated using a pre-established session, shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body in the hname "body" parameter in the headers portion of the SIP URI in the Refer-To header field the <broadcast-ind> element set to "true" as defined in clause F.1.

6.2.8.3 MCVideo emergency private call conditions

6.2.8.3.1 Authorisations

6.2.8.3.1.1 Determining authorisation for initiating an MCVideo emergency private call

If the MCVideo client receives a request from the MCVideo user to originate an MCVideo emergency private call and:

1) if the <allow-emergency-private-call> element of the <ruleset> element of the MCVideo user profile document identified by the MCVideo ID of the calling user (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "true"; and

a) if the "entry-info" attribute of the <entry> element of the <MCVideoPrivateRecipient> element of the <EmergencyCall> element contained within the <PrivateCall> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "UsePreConfigured" and if the <uri-entry> element of the <entry> element of the <MCVideoPrivateRecipient> element contains the MCVideo ID of the MCVideo user targeted by the calling MCVideo user; or

b) if the "entry-info" attribute of the <entry> element of the <MCVideoPrivateRecipient> element of the <EmergencyCall> element contained within the <PrivateCall> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "LocallyDetermined";

then the MCVideo client shall consider the MCVideo emergency private call request to be an authorised request for an MCVideo emergency private call. In all other cases the MCVideo client shall consider the MCVideo emergency private call request to be an unauthorised request for an MCVideo emergency private call.

6.2.8.3.1.2 Determining authorisation for cancelling an MCVideo emergency private call

If the MCVideo client receives a request from the MCVideo user to cancel an MCVideo emergency private call and if the <allow-cancel-private-emergency-call> element of the <ruleset> element of the MCVideo user profile document identified by the MCVideo ID of the calling user (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "true", then the MCVideo emergency private call cancellation request shall be considered to be an authorised request for an MCVideo emergency private call cancellation.

In all other cases, the MCVideo emergency private call cancellation request shall be considered to be an unauthorised request for an MCVideo emergency private call cancellation.

6.2.8.3.1.3 Determining authorisation for initiating or cancelling an MCVideo emergency alert to a MCVideo user

If the MCVideo client receives a request from the MCVideo user to send an MCVideo emergency alert to an MCVideo user and:

1) if the <allow-activate-emergency-alert> element of the <ruleset> element of the MCVideo user profile document identified by the MCVideo ID of the calling MCVideo user as specified in 3GPP TS 24.484 [25] is set to a value of "true"; and

2) if the "entry-info" attribute of the <entry> element of the <PrivateEmergencyAlert> element contained within the <OnNetwork> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of:

a) "UsePreConfigured", and if the <uri-entry> element of the <entry> element of the <PrivateEmergencyAlert> element of the <OnNetwork> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) contains the MCVideo ID of the targeted MCVideo user; or

b) "LocallyDetermined";

If the MCVideo client receives a request from the MCVideo user to cancel an MCVideo emergency alert to an MCVideo user, and if the <allow-cancel-emergency-alert> element of the <ruleset> element of the MCVideo user profile document identified by the MCVideo ID of the calling MCVideo user as specified in 3GPP TS 24.484 [25] is set to a value of "true", then the MCVideo emergency alert cancellation request shall be considered to be an authorised request to cancel an MCVideo emergency alert. In all other cases, it shall be considered to be an unauthorised request to cancel an MCVideo emergency alert.

6.2.8.3.2 SIP request for originating MCVideo emergency private calls

This clause is referenced from other procedures.

When the MCVideo emergency private call state is set to "MVEPC 1: emergency-pc-capable" and this is an authorised request for an MCVideo emergency private call as determined by the procedures of clause 6.2.8.3.1.1, the MCVideo client:

1) shall set the MCVideo emergency state if not already set;

2) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body in the SIP request an <emergency-ind> element set to "true" and set the MCVideo emergency private call state to "MVEPC 2: emergency-pc-requested";

3) if the MCVideo user has also requested an MCVideo emergency alert to be sent and this is an authorised request for MCVideo emergency alert as determined by the procedures of clause 6.2.8.3.1.3, shall:

a) include in the application/vnd.3gpp.mcvideo-info+xml MIME body the <alert-ind> element set to "true" and set the MCVideo private emergency alert state to "MVPEA 2: emergency-alert-confirm-pending"; and

b) perform the procedures specified in clause 6.2.9.1 for the MCVideo emergency alert trigger;

4) if the MCVideo user has not requested an MCVideo emergency alert to be sent, shall set the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to "false"; and

5) if the MCVideo emergency private priority state of this private call is set to a value other than "MVEPP 2: in-progress" shall set the MCVideo emergency private priority state to "MVEPP 3: confirm-pending".

6.2.8.3.3 Resource-Priority header field for MCVideo emergency private calls

This clause is referenced from other procedures.

If the MCVideo emergency private call state is set to either "MVEPC 2: emergency-pc-requested" or "MVEPC 3: emergency-pc-granted" and this is an authorised request for an MCVideo emergency private call as determined by the procedures of clause 6.2.8.3.1.1, or the MCVideo emergency private priority state of the call is set to "MVEPP 2: in-progress", the MCVideo client shall include in the SIP request a Resource-Priority header field populated with the values for an MCVideo emergency private call as specified in clause 6.2.8.1.15.

NOTE: The MCVideo client ideally would not need to maintain knowledge of the in-progress emergency state of the call (as tracked on the MCVideo client by the MCVideo client emergency private state) but can use this knowledge to provide a Resource-Priority header field set to emergency level priority, which starts the infrastructure priority adjustment process sooner than otherwise would be the case.

If this is an authorised request to cancel the MCVideo emergency private call as determined by the procedures of clause 6.2.8.3.1.2, or the MCVideo emergency private priority state of the private call is "MVEPP 1: no-emergency" or "MVEPP 3: cancel-pending", the MCVideo client shall include in the SIP request a Resource-Priority header field populated with the values for a normal MCVideo private call as specified in clause 6.2.8.1.15.

6.2.8.3.4 Receiving a SIP 2xx response to a SIP request for an MCVideo emergency private call

This clause is referenced from other procedures.

On receiving a SIP 2xx response to a SIP request for an MCVideo emergency private call and if the MCVideo emergency private call state is set to "MVEPC 2: emergency-pc-requested" or "MVEPC 3: emergency-pc-granted", the MCVideo client:

1) shall set the MCVideo emergency private priority state of the call to "MVEPP 2: in-progress" if it was not already set;

2) shall set the MCVideo emergency private call state to "MVEPC 3: emergency-pc-granted"; and

3) if the MCVideo private emergency alert state is set to "MVPEA 2: emergency-alert-confirm-pending" and the SIP 2xx response to the SIP request for a priority private call does not contain a Warning header field as specified in clause 4.4 with the warning text containing the mcvideo-warn-code set to "149", shall set the MCVideo private emergency alert state to "MVPEA 3: emergency-alert-initiated".

6.2.8.3.5 Receiving a SIP 4xx response, SIP 5xx response or SIP 6xx response to a SIP request for an MCVideo emergency private call

Upon receiving a SIP 4xx response, SIP 5xx response or a SIP 6xx response to a SIP request for an MCVideo emergency private call and if the MCVideo emergency private call state is set to "MVEPC 2: emergency-pc-requested" or "MVEPC 3: emergency-pc-granted", the MCVideo client:

1) shall set the MCVideo emergency private call state to "MVEPC 1: emergency-pc-capable";

2) if the MCVideo emergency private priority state of the private call is "MVEPP 3: confirm-pending" shall set the MCVideo emergency private priority state of the private call to "MVEPP 1: no-emergency"; and

3) if the sent SIP request for an MCVideo emergency private call contained an application/vnd.3gpp.mcvideo-info+xml MIME body with an <alert-ind> element set to a value of "true", shall set the MCVideo private emergency alert state to "MVPEA 1: no-alert".

6.2.8.3.6 SIP re-INVITE request for cancelling MCVideo emergency private call state

This clause is referenced from other procedures.

When the MCVideo emergency private call state is set to "MVEPC 3: emergency-pc-granted" and the MCVideo emergency alert state is set to "MVPEA 1: no-alert", the MCVideo client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [11] with the clarifications given below.

NOTE 1: This procedure assumes that the MCVideo client in the calling procedure has verified that the MCVideo user has made an authorised request for cancelling MCVideo the in-progress emergency private call state of the call.

The MCVideo client:

1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcvideo-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false";

2) shall clear the MCVideo emergency state; and

3) shall set MCVideo emergency private priority state of the MCVideo emergency private call to "MVEPP 3: cancel-pending".

NOTE 2: This is the case of an MCVideo user who has initiated an MCVideo emergency private call and wants to cancel it.

When the MCVideo emergency private call state is set to "MVEPPC 3: emergency-pc-granted" and the MCVideo emergency alert state is set to a value other than "MVPEA 1: no-alert" and the MCVideo user has indicated only the MCVideo emergency private call should be cancelled, the MCVideo client:

1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcvideo-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false"; and

2) shall set the MCVideo emergency private priority state of the MCVideo emergency private call to "MVEPP 3: cancel-pending";

NOTE 3: This is the case of an MCVideo user has initiated both an MCVideo emergency private call and an MCVideo emergency alert and wishes to only cancel the MCVideo emergency private call. This leaves the MCVideo emergency state set.

When the MCVideo emergency private call state is set to "MVEPC 3: emergency-pc-granted" and the MCVideo emergency alert state is set to a value other than "MVPEA 1: no-alert" and the MCVideo user has indicated that the MCVideo emergency alert on the MCVideo private call should be cancelled in addition to the MCVideo emergency private call, the MCVideo client:

1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcvideo-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false";

2) shall, if this is an authorised request to cancel an MCVideo emergency alert as determined by the procedures of clause 6.2.8.3.1.3:

a) include in the application/vnd.3gpp.mcvideo-info+xml MIME body an <alert-ind> element set to "false"; and

b) set the MCVideo private emergency alert state to "MVPEA 4: emergency-alert-cancel-pending";

3) if this is not an authorised request to cancel an MCVideo emergency alert as determined by the procedures of clause 6.2.8.3.1.3, should indicate to the MCVideo user they are not authorised to cancel the MCVideo emergency alert;

4) shall set the MCVideo emergency private priority state of the MCVideo to "MVEPP 3: cancel-pending"; and

5) shall clear the MCVideo emergency state.

NOTE 4: This is the case of an MCVideo user that has initiated both an MCVideo emergency private call and an MCVideo emergency alert and wishes to cancel both.

6.2.8.3.7 Receiving a SIP INFO request in the dialog of a SIP request for a priority private call

This clause is referenced from other procedures.

Upon receiving a SIP INFO request within the dialog of the SIP request for a priority private call:

– with the Info-Package header field containing the g.3gpp.mcvideo-info package name;

– with the application/vnd.3gpp.mcvideo-info+xml MIME body associated with the info package according to IETF RFC 6086 [21]; and

– with one or more of the <alert-ind>, <imminentperil-ind> and <emergency-ind> elements set in the application/vnd.3gpp.mcvideo-info+xml MIME body;

the MCVideo client:

1) if the MCVideo private emergency alert state is set to "MVPEA 2: emergency-alert-confirm-pending":

a) if the <alert-ind> element is set to a value of "false", shall set the MCVideo private emergency alert state to "MVPEA 1: no-alert"; and

b) if the <alert-ind> element set to a value of "true", shall set the MCVideo private emergency alert state to "MVPEA 3: emergency-alert-initiated"; and

2) if the MCVideo private emergency alert state is set to "MVPEA 4: Emergency-alert-cancel-pending":

a) if the <alert-ind> element is set to a value of "true", shall set the MCVideo private emergency alert state to "MVPEA 3: emergency-alert-initiated"; and

b) if the <alert-ind> element is set to a value of "false", shall set the MCVideo private emergency alert state to "MVPEA 1: no-alert".

6.2.8.3.8 SIP re-INVITE request for cancelling the MCVideo emergency private call state by a third-party

This clause is referenced from other procedures.

Upon receiving a request to cancel the MCVideo emergency private call state from an MCVideo user other than the originator of the MCVideo emergency private call, the MCVideo client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [11] with the clarifications given below.

The MCVideo client:

NOTE 1: This procedure assumes that the calling procedure has verified that the MCVideo user has made an authorised request for cancelling the MCVideo emergency private call state of the call.

1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcvideo-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false";

2) shall set the MCVideo emergency private priority state of the MCVideo emergency private call to "MVEPP 3: cancel-pending"; and

3) if the MCVideo user has indicated that an MCVideo emergency alert associated with the MCVideo emergency private call originated by another MCVideo user should be cancelled and this is an authorised request for an MCVideo emergency alert cancellation as determined by the procedures of clause 6.2.8.3.1.3:

a) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body an <alert-ind> element set to a value of "false"; and

b) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body an <originated-by> element set to the MCVideo ID of the MCVideo user who originated the MCVideo emergency alert.

NOTE 2: When an MCVideo emergency alert is cancelled by a MCVideo user other than its originator, the <originated-by> element is needed to identify which MCVideo emergency alert is being cancelled, as conceivably each participant in the MCVideo emergency private call could have originated an MCVideo emergency alert.

6.2.8.3.9 Retrieving a KMS URI associated with an MCVideo ID

If the MCVideo client needs to retrieve a KMS URI associated to an identified MCVideo ID for on network operation, the MCVideo client:

1) shall search for the <entry> element of the <PrivateCallURI> element of the <PrivateCallOnNetwork> element of the <PrivateCallList> element entry of the <Common> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) containing the identified MCVideo ID;

a) if the identified MCVideo ID is found and if the <entry> element of the <PrivateCallKMSURI> element of the <PrivateCallOnNetwork> element of the <PrivateCallList> element entry identified is not empty, shall retrieve the KMS URI contained therein; or

b) if the identified MCVideo ID is not found or the <entry> element of the <PrivateCallKMSURI> element is empty, shall retrieve the <kms> element of the <App-Server-Info> element of the <on-network> element of the MCVideo UE initial configuration document (see the MCVideo UE initial configuration document in 3GPP TS 24.484 [25]) and consider that to be the KMS URI associated with the MCVideo ID.

If the MCVideo client needs to retrieve a KMS URI associated to an identified MCVideo ID for off network operation, the MCVideo client:

1) shall search for /<x>/<x>/Common/PrivateCall/UserList/<x>/Entry/MCVideoID leaf node containing the identified MCVideo ID (see the MCVideo user profile MO in 3GPP TS 24.483 [4]);

a) if the identified MCVideo ID is found:

i) shall retrieve the /<x>/<x>/Common/PrivateCall/UserList/<x>/Entry/PrivateCallKMSURI leaf node (see the MCVideo user profile MO in 3GPP TS 24.483 [4]); and

ii) if the PrivateCallKMSURI leaf node in the same /<x>/<x>/Common/PrivateCall/UserList/<x>/Entry/ interior node as the MCVideoID leaf node containing the identified MCVideo ID is not empty, shall consider its value to be the KMS URI associated with the MCVideo ID; and

b) if the identified MCVideo ID is not found or if the /<x>/<x>/Common/PrivateCall/UserList/<x>/Entry/PrivateCallKMSURI leaf node is empty:

i) shall retrieve /<x>/OnNetwork/AppServerInfo/KMS leaf node (see the MCVideo UE initial configuration document in 3GPP TS 24.483 [4]); and

ii) shall consider the value of the /<x>/OnNetwork/AppServerInfo/KMS leaf node to be the KMS URI associated with the MCVideo ID.

6.2.9 Location information

6.2.9.1 Location information for location reporting

This procedure is initiated by the MCVideo client when it is including location report information as part of a SIP request for a specified location trigger.

The MCVideo client:

1) shall include an application/vnd.3gpp.location-info+xml MIME body as specified in Annex F.3 with a <Report> element included in the <location-info> root element; and

2) shall include in the <Report> element the specific location information configured for the specified location trigger.