11 Emergency Alert

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

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

11.1 General

This clause describes the emergency alert procedures for on-network and off-network.

For on-network emergency alert, the procedures for originating and terminating MCVideo clients, participating MCVideo functions and controlling MCVideo function are specified in clause 11.2. MCVideo emergency call procedures that have emergency alerts as an optional capability shall be performed as defined in clause 9.2 for on-network group call and defined in clause 10.2 for on-network private call.

For off-network emergency alert, the procedures for each functional entity is specified in clause 11.3.

11.2 On-network emergency alert

11.2.1 Client procedures

11.2.1.1 Emergency alert origination

Upon receiving a request from the MCVideo user to send an MCVideo emergency alert to the indicated MCVideo group shall determine whether the group document contains a <list-service> element that contains a <preconfigured-group-use-only> element. If a <preconfigured-group-use-only> element exists and is set to the value "true", then the MCVideo client:

1) should indicate to the MCVideo user that alerts are not allowed on the indicated group; and

2) shall skip the remainder of this procedure.

If this is an authorised request for an MCVideo emergency alert as determined by clause 6.2.8.1.6, the MCVideo client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [11] and IETF RFC 3428 [17] with the clarifications given below.

NOTE 1: this SIP MESSAGE request is assumed to be sent out-of-dialog.

The MCVideo client:

1) 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] in the SIP MESSAGE request;

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

3) may include a P-Preferred-Identity header field in the SIP MESSAGE request containing a public user identity as specified in 3GPP TS 24.229 [11];

4) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body as specified in clause F.1 with the <mcvideoinfo> element containing the <mcvideo-Params> element with:

a) the <mcvideo-request-uri> element set to the group identity;

b) the <alert-ind> element set to a value of "true";

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

d) if the MCVideo client needs to include an active functional alias in the SIP MESSAGE request, the <anyExt> element with the <functional-alias-URI> element set to the URI of the used functional alias; and

f) if the MCVideo user has requested an application priority, the <anyExt> element with the <user-requested-priority> element set to the user provided value.

NOTE 1A: The MCVideo client learns the functional aliases that are activated for an MCVideo ID from procedures specified in clause 20.2.1.3.

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

6) shall include in the <Report> element the specific location information configured for the MCVideo emergency alert location trigger;

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

8) shall set the MCVideo emergency alert state to "MVEA 2: emergency-alert-confirm-pending";

9) shall set the Request-URI to the public service identity identifying the participating MCVideo function serving the group identity; and

10) shall send the SIP MESSAGE request according to rules and procedures of 3GPP TS 24.229 [11].

On receiving a SIP 2xx response to the SIP MESSAGE request, the MCVideo client shall set the MCVideo emergency alert state to "MVEA 3: emergency-alert-initiated".

On receiving a SIP 4xx response a SIP 5xx response or a SIP 6xx response to the SIP MESSAGE request, the MCVideo client shall set the MCVideo emergency alert state to "MVEA 1: no-alert".

NOTE 2: the MCVideo emergency state is left set in this case as the MCVideo user presumably is in the best position to determine whether or not they are in a life-threatening condition. The assumption is that the MCVideo user can clear the MCVideo emergency state manually if need be.

11.2.1.2 Emergency alert cancellation

Upon receiving a request from the MCVideo user to send an MCVideo emergency alert cancellation to the indicated MCVideo group and this is an authorised request for an MCVideo emergency alert cancellation as determined by clause 6.2.8.1.6, the MCVideo client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [11] and IETF RFC 3428 [17] with the clarifications given below.

NOTE 1: This SIP MESSAGE request is assumed to be sent out-of-dialog.

The MCVideo client:

3) may include a P-Preferred-Identity header field in the SIP MESSAGE request containing the public user identity of the originator as specified in 3GPP TS 24.229 [11];

4) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body as specified in clause F.1 with the <mcvideoinfo> element containing the <mcvideo-Params> element with:

a) the <mcvideo-request-uri> element set to the MCVideo group identity;

b) the <alert-ind> element set to a value of "false";

c) if the MCVideo user is cancelling an MCVideo emergency alert originated by another MCVideo user, include the <originated-by> element set to the MCVideo ID of the MCVideo user who originated the MCVideo emergency alert; and

5) if the MCVideo user has additionally requested the cancellation of the in-progress emergency state of the MCVideo group and this is an authorised request for an in-progress emergency group state cancellation as determined by clause 6.2.8.1.7, shall include an <emergency-ind> element set to a value of "false" in the <mcvideoinfo> element containing the <mcvideo-Params> element;

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

7) if the generated SIP MESSAGE request does not contain an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body, shall set the MCVideo emergency alert state to "MVEA 4: Emergency-alert-cancel-pending"; and

8) shall send the SIP MESSAGE request according to rules and procedures of 3GPP TS 24.229 [11].

On receipt of a SIP MESSAGE request containing an application/vnd.3gpp.mcvideo-info+xml MIME body with an <alert-ind-rcvd> element set to true and an <mcvideo-client-id> matching the MCVideo client ID included in the sent SIP MESSAGE request:

1) if the <alert-ind> element is set to a value of "false" in the application/vnd.3gpp.mcvideo-info+xml MIME body of the received SIP MESSAGE request and the sent SIP MESSAGE request did not contain an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body, shall:

a) set the MCVideo emergency alert state to "MVEA 1: no-alert"; and

b) clear the MCVideo emergency state if not already cleared;

2) if the <alert-ind> element in the application/vnd.3gpp.mcvideo-info+xml MIME body of the received SIP MESSAGE request is set to a value of "true" and if the MCVideo emergency alert state is set to "MVEA 4: Emergency-alert-cancel-pending" and the sent SIP MESSAGE request did not contain an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body, shall set the MCVideo emergency alert state to "MVEA 3: emergency-alert-initiated"; and

NOTE 2: It would appear to be an unusual situation for the initiator of an MCVideo emergency alert to not be able to clear their own alert. Nevertheless, an MCVideo user can be configured to be authorised to initiate MCVideo emergency alerts but not have the authority to clear them. Hence, the case is covered here.

3) if an <emergency-ind> element is present in the application/vnd.3gpp.mcvideo-info+xml MIME body of received SIP MESSAGE request and is set to a value of "false":

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

b) shall set the MCVideo emergency group state of the group to "MVEG 1: no-emergency".

NOTE 3: The case where an <emergency-ind> element is set to true is possible but not handled specifically above as it results in no state changes.

On receiving a SIP 4xx response, SIP 5xx response or SIP 6xx response to the sent SIP MESSAGE request:

1) if the received SIP 4xx response, SIP 5xx response or SIP 6xx response contains an application/vnd.3gpp.mcvideo-info+xml MIME body as specified in clause F.1 with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <alert-ind> element set to a value of "true", the sent SIP MESSAGE request did not contain an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body and the MCVideo emergency alert state is set to "MVEA 4: Emergency-alert-cancel-pending", shall set the MCVideo emergency alert state to "MVEA 3: emergency-alert-initiated"; and

NOTE 4: In this case, an <emergency-ind> element would either not be present or would be set to true. In either case, no change in state would result. Hence, this case is not specified above.

2) if the received SIP 4xx response, SIP 5xx response or a SIP 6xx response to the SIP MESSAGE request does not contain an application/vnd.3gpp.mcvideo-info+xml MIME body with an <alert-ind> element, the sent SIP MESSAGE request does not contain an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body and the MCVideo emergency alert state is set to "MVEA 4: Emergency-alert-cancel-pending", shall set the MCVideo emergency alert state to "MVEA 3: emergency-alert-initiated".

11.2.1.3 MCVideo client receives an MCVideo emergency alert or call notification

Upon receipt of a "SIP MESSAGE request for emergency notification", the MCVideo client:

1) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <alert-ind> element set to a value of "true", should display to the MCVideo user an indication of the MCVideo emergency alert and associated information, including:

a) the MCVideo group identity contained in <mcvideo-calling-group-id> element application/vnd.3gpp.mcvideo-info+xml MIME body;

b) the originator of the MCVideo emergency alert contained in the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

c) the mission critical organization of the MCVideo emergency alert originator contained in the <mc-org> element of the application/vnd.3gpp.mcvideo-info+xml MIME body;

NOTE 1: This is the case of the MCVideo client receiving the notification of another MCVideo user’s emergency alert.

2) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <alert-ind> element set to a value of "false":

a) should display to the MCVideo user an indication of the MCVideo emergency alert cancellation and associated information, including:

i) the MCVideo group identity contained in the <mcvideo-calling-group-id> element application/vnd.3gpp.mcvideo-info+xml MIME body;

ii) the originator of the MCVideo emergency alert contained in:

A) if present, the <originated-by> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; or

B) the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

b) if the MCVideo ID contained in the <originated-by> element is the MCVideo ID of the receiving MCVideo user, shall set the MCVideo emergency alert state to "MVEA 1: no-alert"; and

c) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <emergency-ind> element is set to a value of "false":

i) shall set the MCVideo emergency group state to "MVEG 1: no-emergency"; and

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

NOTE 2: This is the case of the MCVideo client receiving the notification of the cancellation by a third party of an MCVideo emergency alert. This can be the MCVideo emergency alert of another MCVideo user or the MCVideo emergency alert of the recipient, as determined by the contents of the <originated-by> element. Optionally, notification of the cancellation of the in-progress emergency state of the MCVideo group can be included.

3) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <emergency-ind> element set to a value of "true":

a) should display to the MCVideo user an indication of the additional emergency MCVideo user participating in the MCVideo emergency group call including the following if not already displayed as part of step 1):

i) the MCVideo group identity contained in the <mcvideo-calling-group-id> element application/vnd.3gpp.mcvideo-info+xml MIME body; and

ii) the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body;

b) shall set the MCVideo emergency group state to "MVEG 2: in-progress" if not already set to that value;

NOTE 3: This is the case of the MCVideo client receiving notification of an additional MCVideo user in an MCVideo emergency state (i.e., not the MCVideo user that originally triggered the in-progress emergency state of the group) joining the in-progress emergency group call. An emergency alert indication, if included, is handled in step 1).

4) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <emergency-ind> element set to a value of "false":

a) should display to the MCVideo user an indication of the cancellation of the in-progress emergency state of the MCVideo group call including the following if not already displayed as part of step 2):

i) the MCVideo group identity contained in the <mcvideo-calling-group-id> element application/vnd.3gpp.mcvideo-info+xml MIME body; and

ii) the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body;

b) shall set the MCVideo emergency group state to "MVEG 1: no-emergency"; and

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

NOTE 4: This is the case of the MCVideo client receiving the notification of the cancellation of the in-progress emergency state of the MCVideo group. In this case, the receiving MCVideo client is affiliated with the MCVideo group but not participating in the session. An emergency alert cancellation, if included, is handled in step 2).

5) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <imminentperil-ind> element set to a value of "true":

a) should display to the MCVideo user an indication of the MCVideo user participating in the MCVideo imminent peril group call including the following if not already displayed as part of step 1):

i) the MCVideo group identity contained in the <mcvideo-calling-group-id> element application/vnd.3gpp.mcvideo-info+xml MIME body; and

ii) the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

b) shall set the MCVideo imminent peril group state to "MVIG 2: in-progress" if not already set to that value;

NOTE 5: This is the case of the MCVideo client receiving notification of an additional MCVideo user initiating an imminent peril group call when there is already an in-progress imminent peril state in effect on the group.

6) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <imminentperil-ind> element set to a value of "false":

a) should display to the MCVideo user an indication of the cancellation of the in-progress imminent peril state of the MCVideo group including the following if not already displayed as part of step 2):

i) the MCVideo group identity contained in the <mcvideo-calling-group-id> element application/vnd.3gpp.mcvideo-info+xml MIME body; and

ii) the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body;

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

c) shall set the MCVideo imminent peril group call state to "MVIGC 1: imminent-peril-gc-capable";

NOTE 6: This is the case of the MCVideo client receiving notification of the cancellation of the in-progress imminent peril state of the group.

7) shall generate a SIP 200 (OK) response according to rules and procedures of 3GPP TS 24.229 [11]; and

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

11.2.1.4 MCVideo client receives notification of entry into or exit from a group geographic area

Upon receipt of a "SIP MESSAGE request for notification of entry into or exit from a group geographic area", the MCVideo client;

1) shall send a SIP 200 (OK) to the participating MCVideo function that sent the SIP MESSAGE request; and

2) if the <group-geo-area-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body is:

a) set to "true":

i) may display to the MCVideo user an indication that a group geographic area has been entered; and

ii) shall execute the procedure in clause 8.2.1.2 to affiliate to the group indicated by the participating MCVideo function; and

b) set to "false":

i) may display to the MCVideo user an indication that a group geographic area has been exited; and

ii) shall execute the procedure in clause 8.2.1.2 to de-affiliate from the group indicated by the participating MCVideo function.

11.2.1.5 MCVideo client receives notification of entry into or exit from an emergency alert area

Upon receipt of a "SIP MESSAGE request for notification of entry into or exit from an emergency alert area", the MCVideo client:

1) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <emergency-alert-area-ind> element of the value:

a) set to "true":

i) may display to the MCVideo user an indication that MCVideo client has entered a pre-defined emergency alert area; and

ii) if the MCVideo user is not in emergency state, shall initiate the emergency alert origination procedure as specified in clause 12.1.1.1; or

b) set to "false":

i) may display to the MCVideo user an indication that MCVideo client has exited a pre-defined emergency alert area.

NOTE: In this case, the MCVideo emergency state remains set, as the MCVideo user is in the best position to determine whether or not they are in a life-threatening condition. The MCVideo user can clear the MCVideo emergency state manually, if needed.

2) shall generate a SIP 200 (OK) response according to rules and procedures of 3GPP TS 24.229 [11]; and

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

11.2.2 Participating MCVideo function procedures

11.2.2.1 Receipt of a SIP MESSAGE request for emergency notification from the served MCVideo client

Upon receipt of a "SIP MESSAGE request for emergency notification for originating participating MCVideo function", the participating MCVideo function:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response. The participating MCVideo function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [15] and skip the rest of the steps;

NOTE 1: if the SIP MESSAGE request contains an emergency indication set to a value of "true" or an alert indication set to a value of "true", the participating MCVideo function can, according to local policy, choose to accept the request.

2) shall determine the MCVideo ID of the calling user from the public user identity in the P-Asserted-Identity header field of the SIP MESSAGE request, and shall authorise the calling user;

NOTE 2: The MCVideo ID of the calling user is bound to the public user identity at the time of service authorisation, as documented in clause 7.3.

3) if the MCVideo user is not affiliated with the MCVideo group as determined by clause 9.2.2.2.11, shall perform the actions specified in clause 9.2.2.2.12 for implicit affiliation;

4) if the actions for implicit affiliation specified in step 3) above were performed but not successful in affiliating the MCVideo user due to the MCVideo user already having N2 simultaneous affiliations (specified in the <MaxAffiliationsN2> element of the <Common> element of the corresponding MCVideo user profile of the served MCVideo ID), shall reject the "SIP MESSAGE request for emergency notification for originating participating MCVideo function" with a SIP 486 (Busy Here) response with the warning text set to "102 too many simultaneous affiliations" in a Warning header field as specified in clause 4.4. and skip the rest of the steps.

NOTE 3: N2 is the total number of MCVideo groups that an MCVideo user can be affiliated to simultaneously as specified in 3GPP TS 23.379 [78].

NOTE 4: As this is a request for MCVideo emergency services, the participating MCVideo function can choose to accept the request.

5) shall determine the public service identity of the controlling MCVideo function associated with the group identity in the received SIP MESSAGE request;

NOTE 5: The public service identity can identify the controlling MCVideo function in the local MCVideo system or in an interconnected MCVideo system.

NOTE 6: If the controlling MCVideo function is in an interconnected MCVideo system in a different trust domain, then the public service identity can identify the MCVideo gateway server that acts as an entry point in the interconnected MCVideo system from the local MCVideo system.

NOTE 7: If the controlling MCVideo function is in an interconnected MCVideo system in a different trust domain, then the local MCVideo system can route the SIP request through an MCVideo gateway server that acts as an exit point from the local MCVideo system to the interconnected MCVideo system.

NOTE 8: How the participating MCVideo function determines the public service identity of the controlling MCVideo function associated with the group identity or of the MCVideo gateway server in the interconnected MCVideo system is out of the scope of the present document.

NOTE 9: How the local MCVideo system routes the SIP request through an exit MCVideo gateway server is out of the scope of the present document.

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

7) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the controlling MCVideo function determined in step 5) above;

8) shall copy the contents of the application/vnd.3gpp.mcvideo-info+xml MIME body in the received SIP MESSAGE request into an application/vnd.3gpp.mcvideo-info+xml MIME body as specified in clause F.1 included in the outgoing SIP MESSAGE request;

8a) if the received SIP MESSAGE request contains a <functional-alias-URI> element of the application/vnd.3gpp.mcvideo-info+xml MIME body, shall check the status of the functional alias for the MCVideo ID. If the functional alias status is activated, then the participating MCVideo function shall set the <functional-alias-URI> element of the application/vnd.3gpp.mcvideo-info+xml MIME body in the outgoing SIP MESSAGE request to the received value, otherwise it shall not include a <functional-alias-URI> element;9) shall set the <mcvideo-calling-user-id> element of the <mcvideoinfo> element containing the <mcvideo-Params> element to the MCVideo ID determined in step 2) above;

10) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcvideo-location-info+xml MIME body as specified in clause F.3 shall copy the contents of the application/vnd.3gpp.mcvideo-location-info+xml MIME body in the received SIP MESSAGE request into an application/vnd.3gpp.mcvideo-location-info+xml MIME body included in the outgoing SIP MESSAGE request;

11) shall set the P-Asserted-Identity in the outgoing SIP MESSAGE request to the public user identity in the P-Asserted-Identity header field contained in the received SIP MESSAGE request; and

12) shall send the SIP MESSAGE request as specified to 3GPP TS 24.229 [11].

Upon receipt of a SIP 2xx response in response to the SIP MESSAGE request sent in step 10):

1) shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [11] with the follow clarifications:

a) shall include the public user identity received in the P-Asserted-Identity header field of the incoming SIP 200 (OK) response into the P-Asserted-Identity header field of the outgoing SIP 200 (OK) response;

2) if the procedures of clause 9.2.2.2.12 for implicit affiliation were performed in the present clause, shall complete the implicit affiliation by performing the procedures of clause 9.2.2.2.13; and

3) shall send the SIP 200 (OK) response to the MCVideo client according to 3GPP TS 24.229 [11].

Upon receipt of a SIP 4xx, 5xx or 6xx response to the sent SIP MESSAGE request and if the implicit affiliation procedures of clause 9.2.2.2.12 were invoked in the present clause, the participating MCVideo function shall perform the procedures of clause 9.2.2.2.14.

11.2.2.2 Receipt of a SIP MESSAGE request for emergency notification for terminating MCVideo client

In the procedures in this clause:

1) emergency indication in an incoming SIP MESSAGE request refers to the <emergency-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

2) alert indication in an incoming SIP MESSAGE request refers to the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body.

Upon receipt of a "SIP MESSAGE requests for emergency notification for terminating participating MCVideo function", the participating MCVideo function:

NOTE 1: if the SIP MESSAGE request contains an emergency indication set to a value of "true" or an alert indication set to a value of "true", the participating MCVideo function can by means beyond the scope of this specification choose to accept the request.

2) shall use the MCVideo ID present in the <mcvideo-request-uri> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the incoming SIP MESSAGE request to retrieve the binding between the MCVideo ID and public user identity;

3) if the binding between the MCVideo ID and public user identity does not exist, then the participating MCVideo function shall reject the SIP MESSAGE request with a SIP 404 (Not Found) response. Otherwise, continue with the rest of the steps;

4) shall generate an outgoing SIP MESSAGE request as specified in clause 6.3.2.2.11; and

5) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [11].

Upon receipt of SIP 2xx responses to the outgoing SIP MESSAGE requests, the participating MCVideo function shall follow the procedures specified in 3GPP TS 24.229 [11].

11.2.2.3 Receipt of a SIP MESSAGE request indicating successful delivery of emergency notification

Upon receipt of a SIP MESSAGE request routed to the terminating participating MCVideo function with the Request-URI set to the public service identity of the terminating participating MCVideo function and the SIP MESSAGE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with an <alert-ind-rcvd> element present, the participating MCVideo function:

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

a) shall include in the SIP MESSAGE request all Accept-Contact header fields and all Reject-Contact header fields, with their feature tags and their corresponding values along with parameters according to rules and procedures of IETF RFC 3841 [20] that were received (if any) in the incoming SIP MESSAGE request;

b) shall set the Request-URI of the outgoing SIP MESSAGE request to the public user identity associated to the MCVideo ID of the MCVideo user that was in the Request-URI of the incoming SIP MESSAGE request;

c) shall copy the contents of the application/vnd.3gpp.mcvideo-info+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcvideo-info+xml MIME body included in the outgoing SIP MESSAGE request; and

d) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP MESSAGE request to the P-Asserted-Identity header field of the outgoing SIP MESSAGE request; and

5) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [11].

Upon receipt of SIP 2xx responses to the outgoing SIP MESSAGE requests, the participating MCVideo function shall follow the procedures specified in 3GPP TS 24.229 [11].

11.2.3 Controlling MCVideo function procedures

11.2.3.1 Handling of a SIP MESSAGE request for emergency notification

Upon receipt of a "SIP MESSAGE request for emergency notification for controlling MCVideo function", the controlling MCVideo function:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response. The controlling MCVideo function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [15]. Otherwise, continue with the rest of the steps;

NOTE: If the SIP MESSAGE request contains an alert indication set to a value of "true", the controlling MCVideo function can, according to local policy, choose to accept the request.

2) shall reject the SIP request with a SIP 403 (Forbidden) response and not process the remaining steps if an Accept-Contact header field does not include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo";

2A) if the group document contains a <list-service> element that contains a <preconfigured-group-use-only> element that is set to the value "true", shall reject the SIP request with a SIP 403 (Forbidden) response with the warning text set to "168 alert is not allowed on the preconfigured group" as specified in clause 4.4 "Warning header field" and skip the rest of the steps;

3) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <alert-ind> element set to a value of "false", shall perform the procedures specified in clause 11.2.3.2 and skip the rest of the steps;

4) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <alert-ind> element set to a value of "true":

a) if the received SIP MESSAGE request is an unauthorised request for an MCVideo emergency alert as specified in clause 6.3.3.1.13.1 shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response to the SIP MESSAGE request as specified in 3GPP TS 24.229 [11] with the following clarifications:

i) shall include in the SIP 403 (Forbidden) response an application/vnd.3gpp.mcvideo-info+xml MIME body as specified in clause F.1 with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <alert-ind> element set to a value of "false"; and

ii) shall send the SIP 403 (Forbidden) response as specified in 3GPP TS 24.229 [11] and skip the rest of the steps; and

b) if the received SIP MESSAGE request is an authorised request for an MCVideo emergency alert as specified in clause 6.3.3.1.13.1:

i) if the sending MCVideo user identified by the <mcvideo-calling-user-id> element included in the application/vnd.3gpp.mcvideo-info+xml MIME body is not affiliated with the MCVideo group identified by the <mcvideo-request-uri> element of the MIME body as determined by the procedures of clause 6.3.6:

I) shall check if the MCVideo user is eligible to be implicitly affiliated with the MCVideo group as determined by clause 9.2.2.3.6;

II) if the MCVideo user is determined not to be eligible to be implicitly affiliated to the MCVideo group shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response with the warning text set to "120 user is not affiliated to this group" in a Warning header field as specified in clause 4.4 and skip the rest of the steps below; or

III) if the procedures of clause 9.2.2.3.6 determined the MCVideo user to be eligible to be implicitly affiliated to the MCVideo group shall, perform the implicit affiliation as specified in clause 9.2.2.3.7;

ii) for each of the other affiliated members of the group:

A) generate an outgoing SIP MESSAGE request notification of the MCVideo user’s emergency alert indication as specified in clause 6.3.3.1.11 with the clarifications of clause 6.3.3.1.12;

B) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <mcvideo-calling-user-id> element set to the value of the <mcvideo-calling-user-id> element in the received SIP MESSAGE request; and

C) send the SIP MESSAGE request according to according to rules and procedures of 3GPP TS 24.229 [11];

iii) shall generate a SIP 200 (OK) response to the received SIP MESSAGE request as specified in 3GPP TS 24.229 [11] with the following clarifications:

A) shall cache the information that the MCVideo user has initiated an MCVideo emergency alert;

iv) shall send the SIP 200 (OK) response to the received SIP MESSAGE according to rules and procedures of 3GPP TS 24.229 [11].

v) shall generate a SIP MESSAGE request as described in clause 6.3.3.1.20 to indicate successful receipt of an emergency alert, and shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body:

A) the <alert-ind> element set to a value of "true";

B) the <alert-ind-rcvd> element set to a value of true; and

C) the <mcvideo-client-id> element with the MCVideo client ID that was included in the incoming SIP MESSAGE request; and

vi) shall send the SIP MESSAGE request according to according to rules and procedures of 3GPP TS 24.229 [11].

Upon receipt of SIP 2xx responses to the outgoing SIP MESSAGE requests, the controlling MCVideo function shall follow the procedures specified in 3GPP TS 24.229 [11].

11.2.3.2 Handling of a SIP MESSAGE request for emergency alert cancellation

Upon receipt of a "SIP MESSAGE request for emergency notification for controlling MCVideo function" containing an application/vnd.3gpp.mcvideo-info+xml MIME body with the <alert-ind> element set to a value of "false", the controlling MCVideo function:

1) if the received SIP MESSAGE request is an unauthorised request for an MCVideo emergency alert cancellation as specified in clause 6.3.3.1.13.1:

a) and if the received SIP MESSAGE request does not contain an <emergency-ind> element or is an unauthorised request for an MCVideo emergency call cancellation as specified in clause 6.3.3.1.13.4, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response to the SIP MESSAGE request as specified in 3GPP TS 24.229 [11] with the following clarifications:

ii) if the received SIP MESSAGE request contains an <emergency-ind> element of the <mcvideoinfo> element set to a value of "false" and if the in-progress emergency state of the group is set to a value of "true" and this is an unauthorised request for an MCVideo emergency call cancellation as determined in step i) above, shall include an <emergency-ind> element set to a value of "true" in the application/vnd.3gpp.mcvideo-info+xml MIME body in the SIP 403 (Forbidden) response; and

iii) shall send the SIP 403 (Forbidden) response according to rules and procedures of 3GPP TS 24.229 [11] and skip the rest of the steps; and

b) and if the received SIP MESSAGE request contains an <emergency-ind> element and is an authorised request for an MCVideo emergency call cancellation as specified in clause 6.3.3.1.13.4 and the in-progress emergency state of the MCVideo group is set to a value of "true":

i) shall set the in-progress emergency state of the group to a value of "false";

ii) shall clear the cache of the MCVideo ID of the MCVideo user that triggered the setting of the in-progress emergency state of the MCVideo group to "true";

iii) shall generate SIP re-INVITE requests to the other affiliated and joined members of the MCVideo group as specified in clause 6.3.3.1.6. The MCVideo controlling function:

A) for each affiliated and joined member shall send the SIP re-INVITE request towards the MCVideo client as specified in 3GPP TS 24.229 [11]; and

B) Upon receiving a SIP 200 (OK) response to the SIP re-INVITE request the controlling MCVideo function shall interact with the media plane as specified in 3GPP TS 24.380 [79];

iv) for each of the affiliated but not joined members of the group shall:

A) generate a SIP MESSAGE request notification of the cancellation of the MCVideo user’s emergency call as specified in clause 6.3.3.1.11;

C) shall include an <emergency-ind> element set to a value of "false" in the application/vnd.3gpp.mcvideo-info+xml MIME body in the outgoing SIP MESSAGE request;

v) shall generate a SIP 200 (OK) response to the received SIP MESSAGE request as specified in 3GPP TS 24.229 [11];

vi) shall send the SIP 200 (OK) response to the received SIP MESSAGE as specified in 3GPP TS 24.229 [11] and skip the rest of the steps;

vii) shall generate a SIP MESSAGE request as described in clause 6.3.3.1.20 to indicate successful receipt of the request for emergency alert cancellation

viii) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body of the SIP MESSAGE request:

A) the <alert-ind> element set to a value of "true";

B) the <alert-ind-rcvd> element set to a value of true;

C) the <emergency-ind> element set to a value of "false"; and

D) the <mcvideo-client-id> element with the MCVideo client ID that was included in the incoming SIP MESSAGE request; and

ix) shall send the SIP MESSAGE request according to according to rules and procedures of 3GPP TS 24.229 [11]; and

2) if the received SIP MESSAGE request is an authorised request for an MCVideo emergency alert cancellation as specified in clause 6.3.3.1.13.1:

a) if the received SIP MESSAGE request contains an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body, shall clear the cache of the MCVideo ID of the MCVideo user identified by the <originated-by> element as having an outstanding MCVideo emergency alert;

b) if the received SIP MESSAGE request does not contain an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body, clear the cache of the MCVideo ID of the sender of the SIP MESSAGE request as having an outstanding MCVideo emergency alert;

c) if the received SIP MESSAGE request does not contain an <emergency-ind> element or is an unauthorised request for an MCVideo emergency call cancellation as specified in clause 6.3.3.1.13.4, for each of the affiliated but not joined members of the group shall:

i) generate a SIP MESSAGE request notification of the cancellation of the MCVideo user’s emergency alert as specified in clause 6.3.3.1.11;

ii) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <mcvideo-calling-user-id> element set to the value of the <mcvideo-calling-user-id> element in the received SIP MESSAGE request;

iii) if the received SIP MESSAGE request contains an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body, copy the contents of the received <originated-by> element to an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body in the outgoing SIP MESSAGE request;

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

v) send the SIP MESSAGE request as specified in 3GPP TS 24.229 [11];

d) if the received SIP MESSAGE request contains an <emergency-ind> element and is an authorised request for an MCVideo emergency call cancellation as specified in clause 6.3.3.1.13.4 and the in-progress emergency state of the MCVideo group is set to a value of "true":

i) shall set the in-progress emergency state of the group to a value of "false";

ii) cache the information that the MCVideo user has cancelled the outstanding in-progress emergency state of the group;

iii) shall generate SIP re-INVITES requests to the other affiliated and joined members of the MCVideo group as specified in clause 6.3.3.1.6. The MCVideo controlling function:

A) for each affiliated and joined member shall send the SIP re-INVITE request towards the MCVideo client as specified in 3GPP TS 24.229 [11]; and

B) Upon receiving a SIP 200 (OK) response to the SIP re-INVITE request the controlling MCVideo function shall interact with the media plane as specified in 3GPP TS 24.380 [79]; and

iv) for each of the affiliated but not joined members of the group shall:

A) generate a SIP MESSAGE request notification of the cancellation of the MCVideo user’s emergency call as specified in clause 6.3.3.1.11;

B) include in the application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <mcvideo-calling-user-id> element set to the value of the <mcvideo-calling-user-id> element in the received SIP MESSAGE request;

C) if the received SIP MESSAGE request contains an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body, copy the contents of the received <originated-by> element to an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body in the outgoing SIP MESSAGE request;

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

E) shall include an <emergency-ind> element set to a value of "false" in the application/vnd.3gpp.mcvideo-info+xml MIME body in the outgoing SIP MESSAGE request;

e) shall generate a SIP 200 (OK) response to the received SIP MESSAGE request as specified in 3GPP TS 24.229 [11];

f) shall send the SIP 200 (OK) response to the received SIP MESSAGE as specified in 3GPP TS 24.229 [11].

g) shall generate a SIP MESSAGE request as described in clause 6.3.3.1.20 to indicate successful receipt of the request for emergency alert cancellation;

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

i) shall populate the <mcvideo-client-id> element with the MCVideo client ID that was included in the incoming SIP MESSAGE request;

j) if the received SIP MESSAGE request contains an <emergency-ind> element of the <mcvideoinfo> element set to a value of "false":

i) if this is an authorised request for an MCVideo emergency call cancellation as specified in clause 6.3.3.1.13.4, shall include an <emergency-ind> element set to a value of "false" in the application/vnd.3gpp.mcvideo-info+xml MIME body in the outgoing SIP MESSAGE request; and

B) otherwise, if this is an unauthorised request for an MCVideo emergency call cancellation as specified in clause 6.3.3.1.13.4, and the in-progress emergency state of the group is set to a value of "true", shall include an <emergency-ind> element set to a value of "true" in the application/vnd.3gpp.mcvideo-info+xml MIME body in the outgoing SIP MESSAGE request; and

k) shall send the SIP MESSAGE request according to according to the rules and procedures of 3GPP TS 24.229 [11].

Upon receipt of SIP 2xx responses to the outgoing SIP MESSAGE requests, the controlling MCVideo function shall follow the procedures specified in 3GPP TS 24.229 [11].

11.3 Off-network emergency alert

11.3.1 General

11.3.2 Basic state machine

11.3.2.1 General

11.3.2.2 Emergency alert state machine

The figure 11.3.2.2-1 gives an overview of the main states and transitions on the UE for emergency alert.

Each emergency alert state machine is per MCVideo group.

Figure 11.3.2.2-1: Emergency alert state machine

The following piece of information is associated with the emergency alert state machine:

a) the stored emergency state of the MCVideo group.

NOTE: The emergency alert state machine is referred by the MCVideo off-network group call and MCVideo off-network private call procedures.

11.3.2.3 Emergency alert states

11.3.2.3.1 E1: Not in emergency state

This state is the start state of this state machine.

The UE stays in this state while not in emergency state.

11.3.2.3.2 E2: Emergency state

This state exists for UE, when the UE has sent a GROUP EMERGENCY ALERT message.

11.3.3 Procedures

11.3.3.1 Originating user sending emergency alert

When in state "E1: Not in emergency state", upon receiving an indication from the MCVideo user to transmit an emergency alert for an MCVideo group ID and the value of "/<x>/<x>/Common/AllowedActivateAlert" leaf node present in the user profile as specified in 3GPP TS 24.483 [4] is set to "true", the MCVideo client:

1) shall set the stored emergency state as "true";

2) shall set the stored MCVideo group ID to the indicated MCVideo group ID;

3) shall generate a GROUP EMERGENCY ALERT message as specified in clause 17.1.14. In the GROUP EMERGENCY ALERT message, the MCVideo client:

a) shall set the MCVideo group ID IE to the stored MCVideo group ID;

b) shall set the Originating MCVideo user ID IE to own MCVideo user ID;

c) shall set the Organization name IE to own organization name; and

d) may set the User location IE with client’s current location, if requested;

4) shall send the GROUP EMERGENCY ALERT message as specified in clause 9.3.1.1.1;

5) shall start timer TFE2 (emergency alert retransmission); and

6) shall enter "E2: Emergency state" state.

11.3.3.2 Emergency alert retransmission

When in state "E2: Emergency state", upon expiry of timer TFE2 (emergency alert retransmission), the MCVideo client:

1) shall generate a GROUP EMERGENCY ALERT message as specified in clause 17.1.14. In the GROUP EMERGENCY ALERT message, the MCVideo client:

a) shall set the MCVideo group ID IE to the stored MCVideo group ID;

b) shall set the originating MCVideo user ID IE to own MCVideo user ID;

c) shall set the Organization name IE to own organization name; and

d) may set the Location IE with client’s current location, if requested; and

2) shall send the GROUP EMERGENCY ALERT message as specified in clause 9.3.1.1.1;

3) shall start the timer TFE2 (emergency alert retransmission); and

4) shall remain in the current state.

11.3.3.3 Terminating user receiving emergency alert

When in state "E1: Not in emergency state" or in "E2: Emergency state", upon receiving a GROUP EMERGENCY ALERT message with the Originating MCVideo user ID IE not stored in the list of users in emergency, the MCVideo client:

1) shall store the Originating MCVideo user ID IE and location IE in the list of users in emergency;

2) shall generate a GROUP EMERGENCY ALERT ACK message as specified in clause 17.1.15. In the GROUP EMERGENCY ALERT ACK message, the MCVideo client:

a) shall set the MCVideo group ID IE to the MCVideo group ID IE of the received GROUP EMERGENCY ALERT message;

b) shall set the Sending MCVideo user ID IE to own MCVideo user ID; and

c) shall set the Originating MCVideo user ID IE to the Originating MCVideo user ID IE of the received GROUP EMERGENCY ALERT message; and

3) shall send the GROUP EMERGENCY ALERT ACK message as specified in clause 9.3.1.1.1;

4) shall start timer TFE1 (Emergency Alert); and

5) shall remain in the current state.

NOTE: Each instance of timer TFE1 is per MCVideo user ID.

11.3.3.4 Terminating user receiving retransmitted emergency alert

When in state "E1: Not in emergency state" or in "E2: Emergency state", upon receiving a GROUP EMERGENCY ALERT message with the Originating MCVideo user ID IE stored in the list of users in emergency and Location IE different than the stored location of the user, the MCVideo client:

1) may update the stored location of the user with the received Location IE;

2) shall restart the associated timer TFE1 (Emergency Alert); and

3) shall remain in the current state.

11.3.3.5 Originating user cancels emergency alert

When in "E2: Emergency state", upon receiving an indication from the MCVideo user to cancel an emergency alert and the value of "/<x>/<x>/Common/AllowedCancelAlert" leaf node present in the user profile as specified in 3GPP TS 24.483 [4] is set to "true", the MCVideo client:

1) shall set the stored emergency state as "false";

2) shall generate a GROUP EMERGENCY ALERT CANCEL message as specified in clause 17.1.16. In the GROUP EMERGENCY ALERT CANCEL message, the MCVideo client:

a) shall set the MCVideo group ID IE to the stored MCVideo group ID; and

b) shall set the Originating MCVideo user ID IE to own MCVideo user ID; and

3) shall send the GROUP EMERGENCY ALERT CANCEL message as specified in clause 9.3.1.1.1;

4) shall stop timer TFE2 (emergency alert retransmission); and

5) shall enter "E1: Not in emergency state" state.

11.3.3.6 Terminating user receives GROUP EMERGENCY ALERT CANCEL message

When in state "E1: Not in emergency state" or in "E2: Emergency state", upon receiving a GROUP EMERGENCY ALERT CANCEL message with the Originating MCVideo user ID IE stored in the list of users in emergency, the MCVideo client:

1) shall remove the MCVideo user ID and associated location information from the stored list of users in emergency;

2) shall generate a GROUP EMERGENCY ALERT CANCEL ACK message as specified in clause 17.1.17. In the GROUP EMERGENCY ALERT CANCEL ACK message, the MCVideo client:

a) shall set the MCVideo group ID IE to the MCVideo group ID IE of the received GROUP EMERGENCY ALERT CANCEL message; and

b) shall set the Sending MCVideo user ID IE to own MCVideo user ID; and

c) shall set the Originating MCVideo user ID IE to the Originating MCVideo user ID IE of the received GROUP EMERGENCY ALERT message;

3) shall send the GROUP EMERGENCY ALERT CANCEL ACK message as specified in clause 9.3.1.1.1;

4) shall stop the associated timer TFE1 (Emergency Alert); and

5) shall remain in the current state.

11.3.3.7 Implicit emergency alert cancel

When in state "E1: Not in emergency state" or in "E2: Emergency state", upon expiry of timer TFE1 (Emergency Alert) associated with a stored MCVideo user ID, the MCVideo client:

1) shall remove the MCVideo user ID and associated location information from the stored list of users in emergency; and

2) shall remain in the current state.