6.3 MCVideo server procedures

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

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

6.3.1 Distinction of requests sent to the MCVideo server

6.3.1.1 SIP INVITE request

The MCVideo server needs to distinguish between the following initial SIP INVITE requests for originations and terminations:

– SIP INVITE requests routed to the participating MCVideo function and the Request-URI is set to a public service identity of the participating MCVideo function that does not identify the pre-established session set-up. Such requests are known as "SIP INVITE request for originating participating MCVideo function" in the procedures in the present document;

– SIP INVITE requests routed to the participating MCVideo function and the Request-URI contains a PSI of the terminating participating MCVideo function. Such requests are known as "SIP INVITE request for terminating participating MCVideo function" in the procedures in the present document;

– SIP INVITE requests routed to the controlling MCVideo function, the Request-URI is set to a public service identity for MCVideo private call and the Contact header field does not contain the isfocus media feature tag specified in IETF RFC 3840 [22]. Such requests are known as "SIP INVITE request for controlling MCVideo function of a private call" in the procedures in the present document;

– SIP INVITE requests routed to the controlling MCVideo function, the Request-URI is set to a public service identity serving an MCVideo group and the Contact header field does not contain the isfocus media feature tag specified in IETF RFC 3840 [22]. Such requests are known as "SIP INVITE request for controlling MCVideo function of an MCVideo group" in the procedures in the present document;

– SIP INVITE requests routed to the controlling MCVideo function, the Request-URI is set to a public service identity for MCVideo ambient viewing call and the Contact header field does not contain the isfocus media feature tag specified in IETF RFC 3840 [22]. Such requests are known as "SIP INVITE request for controlling MCVideo function of an ambient viewing call" in the procedures in the present document;

– SIP INVITE requests routed to the non-controlling MCVideo function of an MCVideo group, the Request-URI is set to a public service identity serving an MCVideo group and the Contact header field contains the isfocus media feature tag specified in IETF RFC 3840 [22]. Such requests are known as "SIP INVITE request for non-controlling MCVideo function of an MCVideo group" in the procedures in the present document; and

– SIP INVITE requests routed to the non-controlling MCVideo function of an MCVideo group, the Request-URI is set to a public service identity serving an MCVideo group and the Contact header field does not contain the isfocus media feature tag specified in IETF RFC 3840 [22]. Such requests are known as "SIP INVITE request from participating MCVideo function for non-controlling MCVideo function of an MCVideo group" in the procedures in the present document.

6.3.1.2 SIP MESSAGE request

The MCVideo server needs to distinguish between the following SIP MESSAGE request for originations and terminations:

– SIP MESSAGE requests routed to the participating MCVideo function with the Request-URI set to the MBMS public service identity of the participating MCVideo function. Such requests are known as "SIP MESSAGE request for an MBMS listening status update" in the procedures in the present document;

– SIP MESSAGE request routed to the participating MCVideo function 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 Report element. Such requests are known as "SIP MESSAGE request for location reporting" in the present document;

– SIP MESSAGE requests routed to the originating participating MCVideo function with the Request-URI set to the public service identity of the participating MCVideo function and containing a Content-Type header field set to "application/vnd.3gpp.mcvideo-info+xml" and includes an XML body containing a <mcvideoinfo> root element containing a <mcvideo-Params> element containing an <emergency-ind> element or an <alert-ind> element. Such requests are known as "SIP MESSAGE requests for emergency notification for originating participating MCVideo function" in the procedures in the present document;

– SIP MESSAGE requests routed to the terminating participating MCVideo function with the Request-URI set to the public service identity of the terminating participating MCVideo function and containing a Content-Type header field set to "application/vnd.3gpp.mcvideo-info+xml" and includes an XML body containing a <mcvideoinfo> root element containing a <mcvideo-Params> element containing an <emergency-ind> element or an <alert-ind> element. Such requests are known as "SIP MESSAGE requests for emergency notification for terminating participating MCVideo function" in the procedures in the present document;

– SIP MESSAGE requests routed to the controlling MCVideo function with the Request-URI set to the public service identity of the controlling MCVideo function and containing a Content-Type header field set to "application/vnd.3gpp.mcvideo-info+xml" and includes an XML body containing a <mcvideoinfo> root element containing a <mcvideo-Params> element containing an <emergency-ind> element or an <alert-ind> element. Such requests are known as "SIP MESSAGE requests for emergency notification for controlling MCVideo function" in the procedures 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 Configuration element. Such requests are known as "SIP MESSAGE request for location report configuration" in the present document; and

– 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 requests routed to the originating participating MCVideo function with the Request-URI set to the public service identity of the participating MCVideo function and containing a Content-Type header field set to "application/vnd.3gpp.mcvideo-info+xml" and includes an XML body containing a <mcvideoinfo> root element with a <mcvideo-Params> element containing an <anyExt> element with the <request-type> element set to a value of "group-selection-change-request" or with 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 for originating participating MCVideo function";

– SIP MESSAGE requests routed to the terminating participating MCVideo function with the Request-URI set to the public service identity of the participating MCVideo function and containing a Content-Type header field set to "application/vnd.3gpp.mcvideo-info+xml" and includes an XML body containing a <mcvideoinfo> root element with a <mcvideo-Params> element containing an <anyExt> element with the <request-type> element set to a value of "group-selection-change-request" or with 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 for terminating participating MCVideo function";

– SIP MESSAGE requests routed to the controlling MCVideo function with the Request-URI set to the public service identity of the controlling MCVideo function and containing a Content-Type header field set to "application/vnd.3gpp.mcvideo-info+xml" and includes an XML body containing a <mcvideoinfo> root element with a <mcvideo-Params> element containing an <anyExt> element with 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 controlling MCVideo function";

– SIP MESSAGE requests routed to the controlling MCVideo function with the Request-URI set to the public service identity of the controlling MCVideo function and containing a Content-Type header field set to "application/vnd.3gpp.mcvideo-info+xml" and includes an XML body containing a <mcvideoinfo> root element with a <mcvideo-Params> element containing an <anyExt> element with 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 controlling MCVideo function";

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

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

– SIP MESSAGE requests routed to the originating participating MCVideo function and the Request-URI is set to a public service identity of the originating participating MCVideo function 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 originating participating MCVideo function to remove a regroup using preconfigured group" in the procedures in the present document;

– SIP MESSAGE requests routed to the terminating participating MCVideo function and the Request-URI is set to a public service identity of the participating MCVideo function that contains a <preconfigured-group> element in an application/vnd.3gpp.mcvideo-regroup+xml MIME body, a <regroup-action> element set to "create", and a non-empty <groups-for-regroup> element. Such requests are known as "SIP MESSAGE request to the terminating participating MCVideo function to create a group regroup using preconfigured group" in the procedures in the present document;

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

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

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

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

– SIP MESSAGE requests routed to the controlling MCVideo function and the Request-URI is set to a public service identity of the controlling MCVideo function 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 controlling MCVideo function to remove a regroup using preconfigured group" in the procedures in the present document;

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

– SIP MESSAGE requests routed to the non-controlling MCVideo function and the Request-URI is set to a public service identity of the non-controlling MCVideo function 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 non-controlling MCVideo function to remove a group regroup using preconfigured group" in the procedures in the present document;

– SIP MESSAGE requests routed to the originating participating MCVideo function with the Request-URI set to the public service identity of the participating MCVideo function and containing a Content-Type header field set to "application/vnd.3gpp.mcvideo-info+xml" and including an XML body containing a <mcvideoinfo> root element containing a <mcvideo-Params> element containing an <anyExt> element with the <request-type> element set to a value of "fa-group-binding-req". Such requests are known as "SIP MESSAGE request for binding of a functional alias with the MCVideo group(s) for the MCVideo user for originating participating MCVideo function" in the procedures in the present document; and

– SIP MESSAGE requests routed to the controlling participating MCVideo function with the Request-URI set to the public service identity of the participating MCVideo function and containing a Content-Type header field set to "application/vnd.3gpp.mcvideo-info+xml" and including an XML body containing a <mcvideoinfo> root element containing a <mcvideo-Params> element containing an <anyExt> element with the <request-type> element set to a value of "fa-group-binding-req". Such requests are known as "SIP MESSAGE request for binding of a functional alias with the MCVideo group(s) for the MCVideo user for controlling MCVideo function" in the procedures in the present document.

If a SIP MESSAGE request is received at an MCVideo server that is not in accordance with the SIP MESSAGE requests listed above, then the MCVideo server shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response.

6.3.1.3 SIP SUBSCRIBE request

The MCVideo server needs to distinguish between the following SIP SUBSCRIBE request for originations and terminations:

– SIP SUBSCRIBE requests routed to the participating MCVideo function with the Request-URI set to the MCVideo session identity identifying the participating MCVideo function and the Event header field set to "conference". Such requests are known as "SIP SUBSCRIBE request for conference event status subscription in the participating MCVideo function" in the procedures in the present document;

– SIP SUBSCRIBE requests routed to the controlling MCVideo function with the Request-URI set to the MCVideo session identity identifying the controlling MCVideo function and containing an Event header field set to "conference". Such requests are known as "SIP SUBSCRIBE request for conference event status subscription in the controlling MCVideo function" in the procedures in the present document; and

– SIP SUBSCRIBE requests routed to the non-controlling MCVideo function with the Request-URI set to the MCVideo session identity identifying the non-controlling MCVideo function and containing an Event header field set to "conference". Such requests are known as "SIP SUBSCRIBE request for conference event status subscription in the non-controlling MCVideo function" in the procedures in the present document.

6.3.2 Participating MCVideo Function

6.3.2.1 Requests initiated by the served MCVideo user

6.3.2.1.1 SDP offer generation

6.3.2.1.1.1 On-demand session

This clause is referenced from other clauses.

The SDP offer is generated based on the received SDP offer. The SDP offer generated by the participating MCVideo function:

1) shall contain two SDP media-level sections for MCVideo video media as contained in the received SDP offer; and

2) shall contain an SDP media-level section for one media-transmission control entity, if present in the received SDP offer.

When composing the SDP offer according to 3GPP TS 24.229 [11], the participating MCVideo function:

1) shall replace the IP address and port number for the offered media stream in the received SDP offer with the IP address and port number of the participating MCVideo function, if required;

NOTE 1: Requirements can exist for the participating MCVideo function to be always included in the path of the offered media stream, for example: for the support of features such as MBMS, lawful interception and recording. Other examples can exist.

2) shall replace the IP address and port number for the offered media transmission control entity, if any, in the received SDP offer with the IP address and port number of the participating MCVideo function; and

NOTE 2: If the participating MCVideo function and the controlling MCVideo function are in the same MCVideo server, and the participating MCVideo function does not have a dedicated IP address or a dedicated port number for media transmission control or media stream, the replacement of the IP address or the port number is omitted.

3) shall contain an "a=key-mgmt" attribute field with a "mikey" attribute value, if present in the received SDP offer.

6.3.2.1.2 SDP answer generation

6.3.2.1.2.1 On-demand session

When composing the SDP answer according to 3GPP TS 24.229 [11], the participating MCVideo function:

1) shall replace the IP address and port number in the received SDP answer with the IP address and port number of the participating MCVideo function, for the accepted media stream in the received SDP offer, if required; and

2) shall replace the IP address and port number in the received SDP answer with the IP address and port number of the participating MCVideo function, for the accepted media-transmission control entity, if present in the received SDP offer.

6.3.2.1.3 Sending an INVITE request on receipt of an INVITE request

This clause is referenced from other procedures.

When generating an initial SIP INVITE request according to 3GPP TS 24.229 [11], on receipt of an incoming SIP INVITE request, the participating MCVideo function:

1) shall include in the SIP INVITE 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 the rules and procedures of IETF RFC 3841 [20] if included in the incoming SIP INVITE request;

2) should include the Session-Expires header field according to IETF RFC 4028 [23]. It is recommended that the "refresher" header field parameter is omitted. If included, the "refresher" header field parameter shall be set to "uac";

3) shall include the option tag "timer" in the Supported header field;

4) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP INVITE request to the P-Asserted-Identity header field of the outgoing SIP INVITE request;

5) shall include the g.3gpp.mcvideo media feature tag into the Contact header field of the outgoing SIP INVITE request;

6) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcvideo" (coded as specified in 3GPP TS 24.229 [11]), into the P-Asserted-Service header field of the outgoing SIP INVITE request;

7) if the incoming SIP INVITE request contained an application/resource-lists+xml MIME body with the MCVideo ID of the invited MCVideo user in a "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body, shall copy the application/resource-lists+xml MIME body, according to the rules and procedures of IETF RFC 5366 [37];

8) if the incoming SIP INVITE request contained an application/vnd.3gpp.mcvideo-info+xml MIME body, shall copy the contents of the application/vnd.3gpp.mcvideo-info+xml MIME body of the incoming SIP INVITE request to the outgoing SIP INVITE request; and

9) if the incoming SIP INVITE request contained an application/vnd.3gpp.location-info+xml MIME body, shall copy the contents of the application/vnd.3gpp.location-info+xml MIME body of the incoming SIP INVITE request to the outgoing SIP INVITE request.

6.3.2.1.4 Response to an INVITE request

6.3.2.1.4.1 Provisional responses

NOTE: This clause is referenced from other procedures

When sending SIP provisional responses other than the SIP 100 (Trying) response, the participating MCVideo function shall generate a SIP provisional response according to 3GPP TS 24.229 [11] and:

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

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

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

c) the isfocus media feature tag; and

d) an MCVideo session identity mapped to the MCVideo session identity if provided in the Contact header field of the incoming provisional response;

2) shall include the "norefersub" option tag in a Supported header field in accordance with 3GPP TS 24.229 [11];

3) may include a Resource-Share header field in accordance with clause 5.7.1.20.2 in 3GPP TS 24.229 [11]; and

4) if the incoming SIP provisional response contained an application/vnd.3gpp.mcvideo-info+xml MIME body, shall copy the application/vnd.3gpp.mcvideo-info+xml MIME body to the outgoing SIP provisional response.

6.3.2.1.4.2 Final response

This clause is referenced from other procedures.

When sending SIP 200 (OK) responses, the participating MCVideo function shall generate a SIP 200 (OK) response according to 3GPP TS 24.229 [11] and:

1) shall include the option tag "timer" in a Require header field;

2) shall include the Session-Expires header field according to rules and procedures of IETF RFC 4028 [23], "UAS Behavior". If the "refresher" parameter is not included in the received request, the "refresher" parameter in the Session-Expires header field shall be set to "uac";

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

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

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

c) the isfocus media feature tag;

4) shall include the option tag "tdialog" in a Supported header field according to rules and procedures of IETF RFC 4538 [32];

5) shall include the option tag "norefersub" in a Supported header field according to rules and procedures of IETF RFC 4488 [31];

6) may include a Resource-Share header field in accordance with clause 5.7.1.20.2 in 3GPP TS 24.229 [11]; and

7) if the incoming SIP 200 (OK) response contained an application/vnd.3gpp.mcvideo-info+xml MIME body, shall copy the application/vnd.3gpp.mcvideo-info+xml MIME body to the outgoing SIP 200 (OK) response.

6.3.2.1.5 Sending a SIP BYE request on receipt of a SIP BYE request

Upon receiving a SIP BYE request from the MCVideo client, the participating MCVideo function:

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

2) shall generate a SIP BYE request as specified in 3GPP TS 24.229 [11];

3) shall set the Request-URI to the MCVideo session identity as included in the received SIP BYE request;

4) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP BYE request to the P-Asserted-Identity header field of the outgoing SIP BYE request;

5) if the received SIP BYE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body, shall copy the application/vnd.3gpp.mcvideo-info+xml MIME body into the outgoing SIP BYE request; and

6) shall send the SIP BYE request toward the controlling MCVideo function, according to 3GPP TS 24.229 [11].

Upon receiving a SIP 200 (OK) response to the SIP BYE request the terminating MCVideo function shall forward a SIP 200 (OK) response to the MCVideo client and shall interact with the media plane as specified in 3GPP TS 24.581 [5] for releasing media plane resources associated with the SIP session with the controlling MCVideo function.

6.3.2.1.6 Priority call conditions

6.3.2.1.6.0 General

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

6.3.2.1.6.1 Determining authorisation for originating a priority group call

When the participating MCVideo function receives a request from the MCVideo client to originate an MCVideo emergency group call and needs to determine if the request is an authorised request for an MCVideo emergency call, the participating MCVideo function 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 participating MCVideo function shall consider the MCVideo emergency group call request to be an authorised request for an MCVideo emergency group call;

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

When the participating MCVideo function receives a request from the MCVideo client to originate an MCVideo imminent peril group call and needs to determine if the request is an authorised request for an MCVideo imminent peril group call the participating MCVideo function 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 <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 <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 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 participating MCVideo function shall consider the MCVideo imminent peril group call request to be an authorised request for an MCVideo emergency group call;

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

6.3.2.1.6.2 Determining authorisation for initiating or cancelling an MCVideo emergency alert

If the participating MCVideo function receives a SIP request from the MCVideo client including a request for an MCVideo emergency alert and:

1) if the <allow-activate-emergency-alert> element of the <actions> element of the <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 (see the MCVideo user profile document in 3GPP TS 24.484 [25]) 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 participating MCVideo function receives a SIP request from the MCVideo client including a request 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.3.2.1.6.3 Validate priority request parameters

This clause is referenced from other procedures.

To validate the combinations of <emergency-ind>, <imminentperil-ind> and <alert-ind> which are received in SIP requests, the participating MCVideo function shall follow the procedures specified in clause 6.3.3.1.17.

6.3.2.1.6.4 Retrieving Resource-Priority header field values

This clause is referenced from other procedures.

The participating MCVideo function shall follow the procedures specified in clause 6.3.3.1.19 with the clarification that references in that procedure to the controlling MCVideo function should be replaced with references to the participating MCVideo function.

6.3.2.1.7 Generating a SIP re-INVITE request on receipt of a SIP re-INVITE request

This clause is referenced from other procedures.

When generating a SIP re-INVITE request according to 3GPP TS 24.229 [11] on receipt of an incoming SIP re-INVITE request, the participating MCVideo function:

1) if the incoming SIP re-INVITE request contained an application/resource-lists+xml MIME body with the MCVideo ID of the invited MCVideo user in a "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body, shall copy the application/resource-lists+xml MIME body, according to the rules and procedures of IETF RFC 5366 [37];

2) if the incoming SIP re-INVITE request contained an application/vnd.3gpp.mcvideo-info+xml MIME body, shall copy the application/vnd.3gpp.mcvideo-info+xml MIME body; and

3) if the incoming SIP re-INVITE request contained an application/vnd.3gpp.location-info+xml MIME body, shall copy the application/vnd.3gpp.location-info+xml MIME body.

6.3.2.1.8 Sending a SIP INVITE request towards the non-controlling MCVideo function

This clause is referenced from other procedures.

The participating MCVideo function shall generate a SIP INVITE request according to rules and procedures of 3GPP TS 24.229 [11].

The participating MCVideo function:

1) shall determine the public service identity of the non-controlling MCVideo function associated with the group identity of the constituent group contained in the <associated-group-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body in the received SIP INVITE request. If the participating MCVideo function is unable to identify the non-controlling MCVideo function for the on demand prearranged group call, it shall reject the SIP INVITE request with a SIP 404 (Not Found) response with the warning text "142 unable to determine the controlling function" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;

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

NOTE 2: If the non-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 3: If the non-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 4: How the participating MCVideo function determines the public service identity of the non-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 5: How the local MCVideo system routes the SIP request through an exit MCVideo gateway server is out of the scope of the present document.

2) shall set the Request-URI set of the generated SIP INVITE request to the public service identity determined in step 1;

3) shall include in the SIP INVITE 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] if included in the original incoming SIP INVITE request from the MCVideo client;

4) should include the Session-Expires header field according to IETF RFC 4028 [23]. It is recommended that the "refresher" header field parameter is omitted. If included, the "refresher" header field parameter shall be set to "uac";

5) shall include the option tag "timer" in the Supported header field;

6) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP INVITE request from the client to the P-Asserted-Identity header field of the outgoing SIP INVITE request;

7) shall include the g.3gpp.mcvideo media feature tag into the Contact header field of the outgoing SIP INVITE request;

8) 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 outgoing SIP INVITE request;

9) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcvideo" (coded as specified in 3GPP TS 24.229 [11]), into the P-Asserted-Service header field of the outgoing SIP INVITE request;

10) if a SIP INVITE request was received from the client containing an application/vnd.3gpp.mcvideo-info+xml MIME body, shall copy the contents of the application/vnd.3gpp.mcvideo-info+xml MIME body of the original incoming SIP INVITE request to the outgoing SIP INVITE request; and

11) shall set the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the SIP INVITE request to the MCVideo ID of the calling user that was determined when the participating MCVideo function received the SIP INVITE request request from the client.

6.3.2.2 Requests terminated to the served MCVideo user

6.3.2.2.1 SDP offer generation

The participating MCVideo function shall follow the procedures in clause 6.3.2.1.1.

6.3.2.2.2 SDP answer generation

6.3.2.2.2.1 On-demand session

The participating MCVideo function shall follow the procedures in clause 6.3.2.1.2.1.

6.3.2.2.3 SIP INVITE request towards the terminating MCVideo client

The participating MCVideo function shall generate an initial SIP INVITE request according to 3GPP TS 24.229 [11] and:

1) shall include in the SIP INVITE 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] if included in the incoming SIP INVITE request;

3) shall include the option tag "timer" in the Supported header field;

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

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

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

c) the isfocus media feature tag;

d) an MCVideo session identity mapped to the MCVideo session identity provided in the Contact header field of the incoming SIP INVITE request; and

e) any other uri-parameter provided in the Contact header field of the incoming SIP INVITE request;

5) shall include the option tag "tdialog" in a Supported header field according to rules and procedures of IETF RFC 4538 [32];

6) shall include the option tag "norefersub" in a Supported header field according to rules and procedures of IETF RFC 4488 [31];

7) may include a Resource-Share header field in accordance with clause 5.7.1.20.3 in 3GPP TS 24.229 [11]; and

8) if the incoming SIP INVITE request contained an application/vnd.3gpp.mcvideo-info+xml MIME body, shall copy the application/vnd.3gpp.mcvideo-info+xml MIME body to the outgoing SIP INVITE request.

6.3.2.2.4 Response to a SIP INVITE request

6.3.2.2.4.1 Provisional response

This clause is referenced from other procedures.

When sending a SIP provisional response other than the SIP 100 (Trying) response to the SIP INVITE request, the participating MCVideo function shall generate a SIP provisional response according to 3GPP TS 24.229 [11] and:

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";

2) if the outgoing SIP provisional response is to be sent in response to the receipt of a SIP provisional response and the response contains an application/vnd.3gpp.mcvideo-info+xml MIME body, shall copy the application/vnd.3gpp.mcvideo-info+xml MIME body to the outgoing SIP provisional response; and

3) if the incoming SIP INVITE request included the Supported header field with the value "100rel" and according to local policy, may include the Require header field with the value "100rel".

6.3.2.2.4.2 Final response

This clause is referenced from other procedures.

When sending SIP 200 (OK) responses, the participating MCVideo function shall generate a SIP 200 (OK) response according to 3GPP TS 24.229 [11] and:

1) shall include the option tag "timer" in a Require header field;

2) shall include the Session-Expires header field according to rules and procedures of IETF RFC 4028 [23], "UAS Behavior". If no "refresher" parameter was included in the SIP INVITE request, the "refresher" parameter in the Session-Expires header field shall be set to "uas";

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

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

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

c) an MCVideo session identity mapped to the MCVideo session identity provided in the Contact header field of the received SIP INVITE request from the controlling MCVideo function;

4) shall include the option tag "tdialog" in a Supported header field according to rules and procedures of IETF RFC 4538 [32]; and

5) if the incoming SIP response contained an application/vnd.3gpp.mcvideo-info+xml MIME body, shall copy the application/vnd.3gpp.mcvideo-info+xml MIME body to the outgoing SIP 200 (OK) response.

6.3.2.2.5 Automatic Commencement Mode

6.3.2.2.5.1 General

When receiving a "SIP INVITE request for terminating participating MCVideo function" that requires automatic commencement mode:

1) if:

a) the invited MCVideo client has one or more pre-established sessions without an associated MCVideo session;

b) the media-level sections for the offered MCVideo video media stream are the same as the media-level sections for MCVideo video media stream in an existing pre-established session; and

c) the media-level section of the offered media-transmission control entity is the same as the media-level section for media-transmission control entity in an existing pre-established session;

then the participating MCVideo function shall perform the actions specified in clause 6.3.2.2.5.3; or

2) otherwise the participating MCVideo function shall perform the actions specified in clause 6.3.2.2.5.2.

6.3.2.2.5.2 Automatic commencement for On-Demand session

When receiving a "SIP INVITE request for terminating participating MCVideo function" for an on-demand session that requires automatic commencement mode the participating MCVideo function:

1) if:

a) the incoming SIP INVITE request contained a Priv-Answer-Mode header field set to the value of "Auto";

b) no Answer-Mode header field or Priv-Answer-Mode header field were received in the incoming SIP INVITE request and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCVideo client as defined in clause 7.3.3 or clause 7.3.4 is set to "auto-answer"; or

c) the incoming SIP INVITE request contained an Answer-Mode header field set to "Auto" and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCVideo client as defined in clause 7.3.3 or clause 7.3.4 is set to "auto-answer";

then:

a) shall generate a SIP 183 (Session Progress) response to the "SIP INVITE request for terminating participating MCVideo function" as specified in clause 6.3.2.2.4.1; and

NOTE: The SIP 183 (session Progress) response can be sent reliably or unreliably depending on the content of the received SIP INVITE request. Regardless of if the SIP 183 (Session Progress) response is sent reliably or unreliably, SDP is not included in the SIP 183 (Session Progress) response.

b) shall set the P-Answer-State header field to "Unconfirmed" in the SIP 183 (Session Progress) response;

2) shall copy the public user identity contained in the Request-URI of the incoming "SIP INVITE request for terminating participating MCVideo function" to the P-Asserted-Identity header field of the SIP 183 (Session Progress) response;

3) shall generate a SIP INVITE request as specified in clause 6.3.2.2.3;

4) shall set the Request-URI to the public user identity associated to the MCVideo ID of the MCVideo user to be invited;

5) shall perform the procedures specified in clause 6.3.2.2.9 to include any MIME bodies in the received SIP INVITE request, into the outgoing SIP INVITE request;

6) shall copy the contents of the P-Asserted-Identity header field of the incoming "SIP INVITE request for terminating participating MCVideo function" to the P-Asserted-Identity header field of the outgoing SIP INVITE request;

7) if the Priv-Answer-Mode header field is present in the incoming SIP INVITE request with a value of "Auto", shall include a Priv-Answer-Mode header field with the value "Auto" in the outgoing SIP INVITE request. Otherwise, if the Answer-Mode header field is present in the incoming SIP INVITE request, the participating MCVideo function shall include an Answer-Mode header field with the value "Auto" in the outgoing SIP INVITE request;

8) if no Answer-Mode header field or Priv-Answer-Mode header field were received in the incoming SIP INVITE request and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCVideo client as defined in clause 7.3.3 or clause 7.3.4 is set to "auto-answer", shall set the Answer-Mode header field to "Auto" in the outgoing SIP INVITE request;

9) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received "SIP INVITE request for terminating participating MCVideo function" as specified in clause 6.3.2.2.1;

10) if the received SIP INVITE request contains a Resource-Priority header field, shall include a Resource-Priority header field with the contents set as in the received Resource-Priority header field; and

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

If the SIP 183 (Session Progress) response was sent reliably, then upon receiving a SIP PRACK request, the participating MCVideo function shall generate a SIP 200 (OK) response to the SIP PRACK request and forward the SIP 200 (OK) response, according to 3GPP TS 24.229 [11].

Upon receiving a SIP 200 (OK) response to the above SIP INVITE request sent to the MCVideo client, the participating MCVideo function:

1) if the SIP 183 (Session Progress) was sent unreliably, shall send the SIP 200 (OK) response immediately; and

2) if the SIP 183 (Session Progress) was sent reliably and,

a) if the SIP PRACK request to the SIP 183 (Session Progress) response has been received by the participating MCVideo function and the SIP 200 (OK) response to the SIP PRACK request has been sent, shall send the SIP 200 (OK) response immediately;

b) if the SIP PRACK request to the SIP 183 (Session Progress) response has not yet been received, then upon receipt of the SIP PRACK request, the participating MCVideo function shall generate a SIP 200 (OK) response to the SIP PRACK request and forward the SIP 200 (OK) response, according to 3GPP TS 24.229 [11], before sending the SIP 200 (OK) response to the "SIP INVITE request for terminating participating MCVideo function".

When the participating MCVideo function sends the SIP 200 (OK) response to the "SIP INVITE request for terminating participating MCVideo function", the participating MCVideo function:

1) shall generate a SIP 200 (OK) response as described in the clause 6.3.2.2.4.2;

2) shall include in the SIP 200 (OK) response an SDP answer based on the SDP answer in the received SIP 200 (OK) response as specified in clause 6.3.2.2.2.1;

3) shall copy the P-Asserted-Identity header field from the incoming SIP 200 (OK) response to the outgoing SIP 200 (OK) response;

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

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

The participating MCVideo function shall forward any other SIP response that does not contain SDP along the signalling path to the originating network according to 3GPP TS 24.229 [11].

6.3.2.2.6 Manual Commencement Mode

6.3.2.2.6.1 General

When receiving a "SIP INVITE request for terminating participating MCVideo function" that requires manual commencement mode:

1) if:

a) the invited MCVideo client has one or more pre-established sessions without an associated MCVideo session;

b) the media-level sections for the offered MCVideo video media stream are the same as the media-level section for MCVideo video media stream in the existing pre-established session; and

c) the media-level section of the offered media-transmission control entity is the same as the media-level section for media-transmission control entity in the existing pre-established session;

then the participating MCVideo function shall perform the actions specified in clause 6.3.2.2.6.3; or

2) otherwise the participating MCVideo function shall perform the actions specified in clause 6.3.2.2.6.2.

6.3.2.2.6.2 Manual commencement for On-Demand session

When receiving a "SIP INVITE request for terminating participating MCVideo function" for an on-demand session that requires manual commencement mode the participating MCVideo function:

1) shall generate a SIP INVITE request as specified in clause 6.3.2.2.3;

2) shall set the Request-URI to the public user identity associated to the MCVideo ID of the MCVideo user to be invited;

3) shall perform the procedures specified in clause 6.3.2.2.9 to include any MIME bodies in the received SIP INVITE request;

4) if the Answer-Mode header field is present in the incoming SIP INVITE request, participating MCVideo function, shall include an Answer-Mode header field with the value "Manual";

5) if no Answer-Mode header field was received in the incoming SIP INVITE request and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCVideo client as defined in clause 7.3.3 or clause 7.3.4 is set to "manual-answer", shall set the Answer-Mode header field to "Manual" in the outgoing SIP INVITE request;

6) if the Priv-Answer-Mode header field is present in the incoming SIP INVITE request, the participating MCVideo function shall include a Priv-Answer-Mode header field with the value "Manual";

7) shall copy the contents of the P-Asserted-Identity header field of the incoming "SIP INVITE request for terminating participating MCVideo function" to the P-Asserted-Identity header field of the outgoing SIP INVITE request;

8) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received "SIP INVITE request for terminating participating MCVideo function" as specified in clause 6.3.2.2.1;

9) if the received SIP INVITE request contains a Resource-Priority header field, shall include a Resource-Priority header field with the contents set as in the received Resource-Priority header field; and

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

Upon receiving a SIP 180 (Ringing) response to the above SIP INVITE request, the participating MCVideo function:

NOTE 1: A SIP 180 (Ringing) response is received from a terminating MCVideo client in the case of a private call.

1) shall generate a SIP 180 (Ringing) response as specified in clause 6.3.2.2.4.1;

2) shall include the P-Asserted-Identity header field as received in the incoming SIP 180 (Ringing) response; and

3) shall forward the SIP 180 (Ringing) response according to 3GPP TS 24.229 [11].

Upon receiving a SIP 183 (Session Progress) response to the above SIP INVITE request, the participating MCVideo function:

NOTE 2: A SIP 183 (Session Progress) response can be received from a terminating MCVideo client in the case of a group call.

1) shall generate a SIP 183 (Session Progress) response as specified in clause 6.3.2.2.4.1;

2) shall include the P-Asserted-Identity header field as received in the incoming SIP 183 (Session Progress) response;

3) shall include the P-Answer-State header field if received in the incoming SIP 183 (Session Progress) request; and

4) shall forward the SIP 183 (Session Progress) response according to 3GPP TS 24.229 [11].

Upon receiving a SIP 200 (OK) response to the SIP INVITE request sent to the MCVideo client, the participating MCVideo function:

When the participating MCVideo function sends the SIP 200 (OK) response the participating MCVideo function:

1) shall generate a SIP 200 (OK) response as described in the clause 6.3.2.2.4.2;

2) shall include in the SIP 200 (OK) response an SDP answer based on the SDP answer in the received SIP 200 (OK) response as specified in clause 6.3.2.2.2.1;

3) shall copy the P-Asserted-Identity header field from the incoming SIP 200 (OK) response to the outgoing SIP 200 (OK) response;

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

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

The participating MCVideo function shall forward any other SIP response that does not contain SDP along the signalling path to the originating network according to 3GPP TS 24.229 [11].

6.3.2.2.7 Void

6.3.2.2.8 SIP BYE request towards the terminating MCVideo client

6.3.2.2.8.1 On-demand

Upon receiving a SIP BYE request from the controlling MCVideo function, the participating MCVideo function:

1) shall interact with the media plane as specified in clause 6.4 in 3GPP TS 24.581 [5] for releasing media plane resource associated with the SIP session with the controlling MCVideo function;

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

3) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP BYE request to the P-Asserted-Identity header field of the outgoing SIP BYE request;

4) if the received SIP BYE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body, shall copy the application/vnd.3gpp.mcvideo-info+xml MIME body into the outgoing SIP BYE request; and

5) shall send the SIP BYE request to the MCVideo client according to 3GPP TS 24.229 [11].

Upon receiving a SIP 200 (OK) response to the SIP BYE request the participating MCVideo function:

1) shall send a SIP 200 (OK) response to the SIP BYE request received from the controlling MCVideo function according to 3GPP TS 24.229 [11]; and

2) shall interact with the media plane as specified in 3GPP TS 24.581 [5] for releasing media plane resources associated with the SIP session with the MCVideo client.

6.3.2.2.9 Populate MIME bodies

This clause is referenced from other procedures.

If the incoming SIP request contains an application/vnd.3gpp.mcvideo-info+xml MIME body, the participating MCVideo function:

1) if not already copied, shall copy the contents of the application/vnd.3gpp.mcvideo-info+xml MIME body received in the SIP request into an application/vnd.3gpp.mcvideo-info+xml MIME body included in the outgoing SIP request.

If the received SIP request contains an application/vnd.3gpp.location-info+xml MIME body as specified in Annex F.3:

1) if not already copied, shall copy the contents of the application/vnd.3gpp.location-info+xml MIME body received in the SIP request into an application/vnd.3gpp.location-info+xml MIME body included in the outgoing SIP request.

If the received SIP request contains an application/resource-lists+xml MIME body:

1) if not already copied, shall copy the contents of the application/resource-lists+xml MIME body received in the SIP request into an application/resource-lists+xml MIME body included in the outgoing SIP request.

6.3.2.2.10 Generating a SIP re-INVITE request towards the terminating MCVideo client

This clause is referenced from other procedures.

The participating MCVideo function shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [11] and:

1) shall include the option tag "tdialog" in a Supported header field according to rules and procedures of IETF RFC 4538 [32];

2) may include a Resource-Share header field in accordance with clause 5.7.1.20.3 in 3GPP TS 24.229 [11];

3) shall perform the procedures specified in clause 6.3.2.2.9 to copy any MIME bodies in the received SIP re-INVITE request to the outgoing SIP re-INVITE request; and

4) if the received SIP re-INVITE request contains a Resource-Priority header field, shall include a Resource-Priority header field with the contents set as in the received Resource-Priority header field.

6.3.2.2.11 Generating a SIP MESSAGE request towards the terminating MCVideo client

This clause is referenced from other procedures.

The participating MCVideo function shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [11] and IETF RFC 3428 [17] and:

1) 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;

2) 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;

3) shall populate the outgoing SIP MESSAGE request MIME bodies as specified in clause 6.3.2.2.9; and

4) 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.

6.3.2.3 Processing I_MESSAGEs containing MKFC and MKFC-ID

6.3.2.3.1 General

The procedures in this clause are executed by:

– the originating participating MCVideo function as a result of receiving a SIP 200 (OK) response to a SIP INVITE request targeted to a group identity, where the SIP 200 (OK) response contains an application/vnd.3gpp.mcvideo-info+xml MIME body containing an <MKFC-GKTPs> element; and

– the terminating participating MCVideo function as a result of receiving a SIP INVITE requested targeted to an MCVideo ID as part of a group call, where the SIP INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body containing an <MKFC-GKTPs> element.

The <MKFC-GKTPs> element contains one or more <GKTP> elements where each <GKTP> element represents an I_MESSAGE(s) containing an MKFC and MKFC-ID, as specified in 3GPP TS 24.481 [24].

The participating MCVideo function validates each I_MESSAGE and if validation is successful, decrypts the I_MESSAGE, extracts the MKFC and MKFC-ID and transfers the MKFC and MKFC-ID to the media-transmission control entity.

6.3.2.3.2 Processing an I_MESSAGE containing MKFC and MKFC-ID

The participating MCVideo function:

1) shall extract the URI from the initiator field (IDRi) of the I_MESSAGE and use it together with the timer related parameter to check the signature of the I_MESSAGE as described in 3GPP TS 33.180 [8];

NOTE: If the terminating participating MCVideo function receives the SIP INVITE request from a controlling MCVideo function, then the URI in the IDRi is the controlling MCVideo function URI. If the terminating participating MCVideo function receives the SIP INVITE request from a non-controlling MCVideo function, then the URI in the IDRi is the non-controlling MCVideo function URI.

2) if the signature is not valid, shall exit this procedure. Otherwise shall validate that the contents of the recipient field (IDRr) of the I_MESSAGE to ensure it matches to the URI of the participating MCVideo function; and

3) if the contents of the IDRr do not match to the participating MCVideo function URI, shall exit this procedure. Otherwise, shall use the contents of the IDRr to decrypt the I_MESSAGE and extract the MKFC and MKFC-ID.

After the MKFC(s) and MKFC-ID(s) have been extracted from the I_MESSAGE(s), the participating MCVideo function shall provide the media-transmission control entity with the MKFC(s) and MKFC-ID(s), by interacting with the media plane as specified in 3GPP TS 24.581 [5].

6.3.3 Controlling MCVideo function

6.3.3.1 Request initiated by the controlling MCVideo function

6.3.3.1.1 SDP offer generation

The SDP offer is generated based on the received SDP offer. The SDP offer generated by the controlling MCVideo function:

1) when initiating a new MCVideo session the SDP offer;

a) shall contain only one SDP media-level section for MCVideo video media stream as contained in the received SDP offer; and

b) shall contain an SDP media-level section for one media-transmission control entity, if present in the received SDP offer; and

2) when adding a new MCVideo user to an existing MCVideo Session, the SDP offer shall contain the media stream currently used in the MCVideo session.

When composing the SDP offer according to 3GPP TS 24.229 [11], the controlling MCVideo function:

1) shall replace the IP address and port number for the offered media stream in the received SDP offer with the IP address and port number of the controlling MCVideo function;

2) for the MCVideo video media stream, shall include all media-level attributes from the received SDP offer;

3) shall replace the IP address and port number for the offered media transmission control entity, if any, in the received SDP offer with the IP address and port number of the controlling MCVideo function; and

4) for the offered media transmission control entity, shall include the offered media transmission control entity ‘fmtp’ attributes as specified in 3GPP TS 24.581 [5] clause 14.

6.3.3.1.2 Sending an INVITE request

This clause is referenced from other procedures.

The controlling MCVideo function shall generate an initial SIP INVITE request according to 3GPP TS 24.229 [11].

The controlling MCVideo function:

1) shall include in the Contact header field an MCVideo session identity for the MCVideo session with the g.3gpp.mcvideo media feature tag, the isfocus media feature tag and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo" according to IETF RFC 3840 [22];

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

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

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

5) shall include a Referred-By header field with the public user identity of the inviting MCVideo client;

6) should include the Session-Expires header field according to rules and procedures of IETF RFC 4028 [23]. The refresher parameter shall be omitted;

7) shall include the Supported header field set to "timer";

8) if the incoming SIP INVITE request contained an application/vnd.3gpp.mcvideo-info+xml MIME body, shall copy the application/vnd.3gpp.mcvideo-info+xml MIME body to the outgoing INVITE request;

9) if the received SIP INVITE request contained an application/vnd.3gpp.mcvideo-info+xml MIME body containing an <ambient-viewing-type> element and:

a) if the Priv-Answer-Mode header field specified in IETF RFC 5373 [27] was included in the received SIP INVITE request with a value of "Auto" or if no Priv-Answer-Mode header field was received in the received SIP INVITE request; or

b) a Priv-Answer-Mode header field was received containing a value other than "Auto";

shall include a Priv-Answer-Mode header field set to a value of "Auto" in the outgoing SIP INVITE request; and

10) if the received SIP INVITE request did not contain an application/vnd.3gpp.mcvideo-info+xml MIME body containing an <ambient-viewing-type> element, shall include an unmodified Answer-Mode header field if present in the incoming SIP INVITE request.

6.3.3.1.3 Receipt of a SIP response to a SIP INVITE request

6.3.3.1.3.1 Final response

On receipt of the SIP 200 (OK) response to the initial outgoing SIP INVITE request the controlling MCVideo function:

1) shall start the SIP session timer according to rules and procedures of IETF RFC 4028 [23]; and

2) shall cache SIP feature tags, if received in the Contact header field, and if the specific feature tags are supported.

6.3.3.1.4 Sending a SIP BYE request

When a participant needs to be removed from the MCVideo session, the controlling MCVideo function:

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

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

3) shall send the SIP BYE request to the MCVideo clients according to3GPP TS 24.229 [11].

If timer TNG3 (group call timer) has not expired, then when the last MCVideo client is removed from the MCVideo session, the controlling MCVideo function shall stop timer TNG3 (group call timer).

When the MCVideo group session needs to be released, the controlling MCVideo function shall send SIP BYE requests as described in this clause, to all participants of the group session.

Upon receiving a SIP 200 (OK) response to a SIP BYE request the controlling MCVideo function shall interact with the media plane as specified in clause 6.3 in 3GPP TS 24.581 [5] for releasing media plane resources associated with the SIP session with the MCVideo clients.

6.3.3.1.5 Sending a SIP re-INVITE request for MCVideo emergency group call

This clause is referenced from other procedures.

The controlling MCVideo function shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [11].

The controlling MCVideo function:

1) shall include an SDP offer with the media parameters as currently established with the terminating MCVideo client according to 3GPP TS 24.229 [11];

2) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideo-calling-user-id> element set to the MCVideo ID of the initiating MCVideo user;

3) if the in-progress emergency group state of the group is set to a value of "true" the controlling MCVideo function:

a) shall include a Resource-Priority header field with the namespace populated with the values for an MCVideo emergency group call as specified in clause 6.3.3.1.18;

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

c) if the <alert-ind> element is set to "true" in the received SIP re-INVITE request and MCVideo emergency alerts are authorised for this group and MCVideo user as determined by the procedures of clause 6.3.3.1.12.1, shall populate the application/vnd.3gpp.mcvideo-info+xml MIME body and application/vnd.3gpp.mcvideo-location-info+xml MIME body as specified in clause 6.3.3.1.11. Otherwise, shall set the <alert-ind> element to a value of "false" in the application/vnd.3gpp.mcvideo-info+xml MIME body; and

d) if the in-progress imminent peril state of the group is set to a value of "true" shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body an <imminentperil-ind> element set to a value of "false"; and

NOTE: If the imminent peril state of the group is true at this point, the controlling function will be setting it to false as part of the calling procedure. This is in effect an upgrade of an MCVideo imminent peril group call to an MCVideo emergency group call.

4) if the in-progress emergency group state of the group is set to a value of "false":

a) shall include a Resource-Priority header field populated with the values for a normal MCVideo group call as specified in clause 6.3.3.1.18; and

b) if the received SIP re-INVITE request contained an application/vnd.3gpp.mcvideo-info+xml MIME body with the <emergency-ind> element set to a value of "false" and this is an authorised request to cancel an MCVideo emergency group call as determined by the procedures of clause 6.3.3.1.12.4:

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

ii) if the received SIP re-INVITE request contained an application/vnd.3gpp.mcvideo-info+xml MIME body with the <alert-ind> element set to a value of "false" and this is an authorised request to cancel an MCVideo emergency alert as determined by the procedures of clause 6.3.3.1.14, shall:

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

B) if the received SIP 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 re-INVITE request.

6.3.3.1.6 Sending a SIP INVITE request for MCVideo emergency group call

This clause is referenced from other procedures.

This clause describes the procedures for inviting an MCVideo user to an MCVideo session associated with an MCVideo emergency group call or MCVideo imminent peril group call. The procedure is initiated by the controlling MCVideo function as the result of an action in clause 9.2.2.4.1.1.

The controlling MCVideo function:

1) shall generate a SIP INVITE request as specified in clause 6.3.3.1.2;

2) shall set the Request-URI to the public service identity of the terminating participating MCVideo function associated with the MCVideo ID of the targeted MCVideo user;

NOTE 1: The public service identity can identify the terminating participating MCVideo function in the local MCVideo system or in an interconnected MCVideo system.

NOTE 2: If the terminating participating 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 3: If the terminating participating 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 4: How the controlling MCVideo function determines the public service identity of the terminating participating MCVideo function associated with the targeted MCVideo user or of the MCVideo gateway server in the interconnected MCVideo system is out of the scope of the present document.

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

3) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element populated as follows:

a) the <mcvideo-request-uri> element set to the value of the MCVideo ID of the targeted MCVideo user;

b) the <mcvideo-calling-user-id> element set to the value of the MCVideo ID of the calling MCVideo user; and

c) the <mcvideo-calling-group-id> element set to the value of the MCVideo group ID of the emergency group call.

4) shall include in the P-Asserted-Identity header field the public service identity of the controlling MCVideo function;

5) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request from the originating network according to the procedures specified in clause 6.3.3.1.1; and

6) if the in-progress emergency group state of the group is set to a value of "true" the controlling MCVideo function:

a) shall include a Resource-Priority header field populated with the values for an MCVideo emergency group call as specified in clause 6.3.3.1.18;

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

c) if the <alert-ind> element is set to "true" in the received SIP INVITE request and the requesting MCVideo user and MCVideo group are authorised for the initiation of MCVideo emergency alerts as determined by the procedures of clause 6.3.3.1.12.1, shall populate the application/vnd.3gpp.mcvideo-info+xml MIME body and the application/vnd.3gpp.mcvideo-location-info+xml MIME body as specified in clause 6.3.3.1.11. Otherwise, shall set the <alert-ind> element to a value of "false" in the application/vnd.3gpp.mcvideo-info+xml MIME body; and

NOTE 6: If the imminent peril state of the group is true at this point, the controlling function will set it to false as part of the calling procedure.

7) if the in-progress emergency state of the group is set to a value of "false" and the in-progress imminent peril state of the group is set to a value of "true", the controlling MCVideo function:

a) shall include a Resource-Priority header field populated with the values for an MCVideo imminent peril group call as specified in clause 6.3.3.1.18; and

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

8) if:

a) an MCVideo GKTP document exists for the group identity contained in the <mcvideo-request-uri> element in the application/vnd.3gpp.mcvideo-info+xml MIME body of the incoming SIP INVITE request; and

b) the MCVideo GKTP document contains an <MKFC-GKTPs> element;

then:

a) for each instance of <GKTP> element of the <MKFC-GKTPs> element of the MCVideo GKTP document:

i) shall perform the procedure in clause 6.3.3.6.2 to re-generate an I_MESSAGE; and

ii) if the procedure in clause 6.3.3.6.2 was successful, shall include the I_MESSAGE in a <GKTP> element of the <MKFC-GKTPs> element of an application/vnd.3gpp.mcvideo-info+xml MIME body included in the outgoing SIP INVITE request.

6.3.3.1.7 Sending a SIP UPDATE request for Resource-Priority header field correction

This clause is referenced from other procedures.

This clause describes the procedures for updating an MCVideo session associated with an MCVideo emergency group call or MCVideo imminent peril group call when the received SIP INVITE request did not include a correctly populated Resource-Priority header field. The procedure is initiated by the controlling MCVideo function for the purpose of providing the correct Resource-Priority header field.

1) shall generate a SIP 183 (Session Progress) response according to 3GPP TS 24.229 [11] with the clarifications provided specified in clause 6.3.3.2.3.1;

2) shall include the option tag "100rel" in a Require header field in the SIP 183 (Session Progress) response;

3) shall include in the SIP 183 (Session Progress) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the clause 6.3.3.2.1; and

4) shall send the SIP 183 (Session Progress) response towards the MCVideo client according to 3GPP TS 24.229 [11].

Upon receiving a SIP PRACK request to the SIP 183 (Session Progress) response the controlling MCVideo function:

1) shall send the SIP 200 (OK) response to the SIP PRACK request according to 3GPP TS 24.229 [11].

2) shall generate a SIP UPDATE request according to 3GPP TS 24.229 [11] with the following clarifications:

3) shall include in the SIP UPDATE request an SDP offer based on the SDP offer in the received SIP INVITE request from the originating network according to the procedures specified in clause 6.3.3.1.1;

4) if the in-progress emergency group state of the group is set to a value of "true" the controlling MCVideo function shall include a Resource-Priority header field populated for an MCVideo emergency group call as specified in clause 6.3.3.1.18; and

NOTE 1: This is the case when the sending MCVideo client did not send a Resource-Priority header field populated appropriately to receive emergency-level priority. In this case, the Resource-Priority header field is populated appropriately to provide emergency-level priority.

5) if the in-progress emergency group state of the group is set to a value of "false" the controlling MCVideo function:

a) if the in-progress imminent peril state of the group is set to a value of "false", shall include a Resource-Priority header field populated for a normal priority MCVideo group call as specified in clause 6.3.3.1.18; and

b) if the in-progress imminent peril state of the group is set to a value of "true", shall include a Resource-Priority header field populated for an MCVideo imminent peril group call as specified in clause 6.3.3.1.18.

NOTE 2: This is the case when the sending MCVideo client incorrectly populated a Resource-Priority header field for emergency-level or imminent peril-level priority and the controlling MCVideo function re-populates it as appropriate to an imminent peril level priority or normal priority level.

6.3.3.1.8 Generating a SIP re-INVITE request

This clause is referenced from other procedures.

This clause describes the procedures for generating a SIP re-INVITE request to be sent by the controlling MCVideo function.

The controlling MCVideo function:

1) shall generate an SIP re-INVITE request according to 3GPP TS 24.229 [11]; and

2) shall include an SDP offer with the media parameters as currently established with the terminating MCVideo client according to 3GPP TS 24.229 [11] with the clarifications specified in clause 6.3.3.1.1.

6.3.3.1.9 Generating a SIP re-INVITE request to cancel an in-progress emergency

This clause is referenced from other procedures.

This clause describes the procedures for generating a SIP re-INVITE request to cancel the in-progress emergency state of an MCVideo group. The procedure is initiated by the controlling MCVideo function when it determines the cancellation of the in-progress emergency state of an MCVideo group is required.

The controlling MCVideo function:

1) shall generate a SIP re-INVITE request as specified in 3GPP TS 24.229 [11] with the clarifications specified in clause 6.3.3.1.8;

2) shall include a Resource-Priority header field populated with the values for a normal MCVideo group call as specified in clause 6.3.3.1.18; and

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

6.3.3.1.10 Generating a SIP MESSAGE request for notification of in-progress emergency or imminent peril status change

This clause is referenced from other procedures.

This clause describes the procedures for generating a SIP MESSAGE request to notify affiliated but not participating members of an MCVideo group of the change of status of the in-progress emergency state, imminent peril state or emergency alert status of an MCVideo group. The procedure is initiated by the controlling MCVideo function when there has been a change of in-progress imminent peril, in-progress emergency or the emergency alert status of an MCVideo group.

The controlling MCVideo function:

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

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

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

4) shall set the Request-URI to the public service identity of the terminating participating function associated with the MCVideo ID of the targeted MCVideo user;

NOTE 1: The public service identity can identify the terminating participating MCVideo function in the local MCVideo system or in an interconnected MCVideo system.

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

5) shall include a P-Asserted-Identity header field set to the public service identity of controlling MCVideo function;

6) 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-Asserted-Service-Id header field according to IETF RFC 6050 [14];

7) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <mcvideo-request-uri> element set to the value of the MCVideo ID of the targeted MCVideo user; and

8) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body an <mcvideo-calling-group-id> element set to the MCVideo group ID of the MCVideo group on which the MCVideo emergency call, imminent peril call or the emergency alert state has changed.

6.3.3.1.11 Populate mcvideo-info and location-info MIME bodies for emergency alert

This clause is referenced from other procedures.

This clause describes the procedures for populating the application/vnd.3gpp.mcvideo-info+xml and application/vnd.3gpp.mcvideo-location-info+xml MIME bodies for an MCVideo emergency alert. The procedure is initiated by the controlling MCVideo function when it has received a SIP request initiating an MCVideo emergency alert and generates a message containing the MCVideo emergency alert information required by 3GPP TS 23.281 [26].

The controlling MCVideo function:

1) shall include, if not already present, an application/vnd.3gpp.mcvideo-info+xml MIME body as specified in Annex F.1, and set the <alert-ind> element to a value of "true";

2) shall determine the value of the MCVideo user’s Mission Critical Organization from the <MissionCriticalOrganization> element, of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]);

3) shall include in the <mcvideoinfo> element containing the <mcvideo-Params> element containing an <mc-org> element set to the value of the MCVideo user’s Mission Critical Organization; and

4) shall copy the contents of the application/vnd.3gpp.mcvideo-location-info+xml MIME body in the received SIP request into an application/vnd.3gpp.mcvideo-location-info+xml MIME body included in the outgoing SIP request.

6.3.3.1.12 Authorisations

6.3.3.1.12.1 Determining authorisation for initiating an MCVideo emergency alert

If the controlling MCVideo function has received a SIP request targeted to an MCVideo group with the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body set to a value of "true", the controlling MCVideo function shall check the following conditions:

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 user (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "true";

a) 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 (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "DedicatedGroup" and:

i) if the MCVideo group identity targeted for the emergency alert is contained in the <uri-entry> element of the <entry> element of the <EmergencyAlert> 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]); and

ii) if 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 is set to a value of "true" as specified in 3GPP TS 24.481 [24]; or

b) 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 (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "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 targeted to a MCVideo group. In all other cases, the MCVideo emergency alert request shall be considered to be an unauthorised request for an MCVideo emergency alert targeted to an MCVideo group.

If the controlling MCVideo function has received a SIP request targeted to an MCVideo user with the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body set to a value of "true", the controlling MCVideo function shall check the following conditions:

1) if the <allow-activate-emergency-alert> element of the <actions> element of the <rule> 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 <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 "UsePreConfigured" and the MCVideo ID of the MCVideo user targeted for the call is contained in the <uri-entry> element of the <entry> element of the <PrivateEmergencyAlert> element contained within the <OnNetwork> element (see the MCVideo user profile document in 3GPP TS 24.484 [25]); or

b) 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 "LocallyDetermined";

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

6.3.3.1.12.2 Determining authorisation for initiating an MCVideo emergency group or private call

If the controlling MCVideo function has received a SIP request for an MCVideo group call with the <emergency-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body set to a value of "true" and:

i) if the <uri-entry> element 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]) contains the identity of the MCVideo group targeted by the calling MCVideo user; and

ii) if the <allow-MCVideo-emergency-call> element of the <list-service> element of the group document identified by the targeted MCVideo group identity is set to a value of "true" as specified in 3GPP TS 24.481 [24];

then the controlling MCVideo function shall consider the MCVideo emergency group call request to be an authorised request for an MCVideo emergency group call and skip the remaining steps; or;

b) 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 "UseCurrentlySelectedGroup" and if the <allow-MCVideo-emergency-call> element of the <list-service> element of the group document identified by the targeted MCVideo group identity is set to a value of "true" as specified in 3GPP TS 24.481 [24];

then the controlling MCVideo function shall consider the MCVideo emergency group call request to be an authorised request for an MCVideo emergency group call and skip the remaining steps; or

2) if the controlling MCVideo function does not consider the MCVideo emergency group call request to be an authorised request for an MCVideo emergency group call by step 1) above, then the controlling MCVideo function shall consider the MCVideo emergency group call request to be an unauthorised request for an MCVideo emergency group call.

If the controlling MCVideo function has received a SIP request for an MCVideo private call with the <emergency-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body set to a value of "true" 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 MCVideo ID targeted for the call is contained in the <uri-entry> element of the <entry> element of the <MCVideoPrivateRecipient> element of the <EmergencyCall> element contained within the <PrivateCall> element (see the MCVideo user profile document in 3GPP TS 24.484 [25]); 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 controlling MCVideo function shall consider the MCVideo emergency private call request to be an authorised request for an MCVideo emergency private call and skip step 2) below; or

2) if the controlling MCVideo function does not consider the MCVideo emergency private call request to be an authorised request for an MCVideo emergency private call by step 1) above, then the controlling MCVideo function shall consider the MCVideo emergency private call request to be an unauthorised request for an MCVideo emergency private call.

6.3.3.1.12.3 Determining authorisation for cancelling an MCVideo emergency alert

If the controlling MCVideo function has received a SIP request with the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body set to a value of "false" and:

1) 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 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 for an MCVideo emergency alert cancellation; and

2) 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 user (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "false", then the MCVideo emergency alert cancellation request shall be considered to be an unauthorised request for an MCVideo emergency alert cancellation.

6.3.3.1.12.4 Determining authorisation for cancelling an MCVideo emergency call

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 user (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "true", then the MCVideo emergency call cancellation request shall be considered to be an authorised request for an MCVideo emergency group call cancellation; and

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 user (see the MCVideo user profile document in 3GPP TS 24.484 [25]) is set to a value of "false", then the MCVideo emergency group call cancellation request shall be considered to be an unauthorised request for an MCVideo emergency group call cancellation.

1) 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; and

2) 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 "false" or not present, then the MCVideo emergency private call cancellation request shall be considered to be an unauthorised request for an MCVideo emergency private call cancellation.

6.3.3.1.12.5 Determining authorisation for initiating an MCVideo imminent peril call

If the controlling MCVideo function has received a SIP request with the <imminentperil-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body set to a value of "true" and:

1) if the <allow-imminent-peril-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 other than "true" the request for initiating an MCVideo imminent peril call shall be considered to be an unauthorised request for an MCVideo imminent peril call and skip the remaining steps;

2) if the <allow-imminent-peril-call> element of the <list-service> element of the group document identified by the targeted MCVideo group identity is set to a value other than "true" as specified in 3GPP TS 24.481 [24], the request for initiating an MCVideo imminent peril call shall be considered to be an unauthorised request for an MCVideo imminent peril call and skip the remaining steps;

3) 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 MCVideo group identity targeted for the call is contained in the <uri-entry> element of the <entry> element of the <MCVideoGroupInitiation> element contained within the <ImminentPerilCall> element (see the MCVideo user profile document in 3GPP TS 24.484 [25]); or

4) 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 call request shall be considered to be an authorised request for an MCVideo imminent peril call. In all other cases, it shall be considered to be an unauthorised request for an MCVideo imminent peril call.

6.3.3.1.12.6 Determining authorisation for cancelling an MCVideo imminent peril call

If the controlling MCVideo function has received a SIP request with the <imminentperil-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body set to a value of "false" and:

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", then the MCVideo emergency call cancellation request shall be considered to be an authorised request for an MCVideo imminent peril call cancellation; and

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" or not present, then the MCVideo emergency call cancellation request shall be considered to be an unauthorised request for an MCVideo imminent peril call cancellation.

6.3.3.1.13 Generating a SIP 403 response for priority call request rejection

If the controlling MCVideo function has received a SIP request with the <emergency-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body is set to "true" and this is an unauthorised request for an MCVideo emergency call as determined by the procedures of clause 6.3.3.1.12.2, the controlling MCVideo function shall:

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

6.3.3.1.14 Sending a SIP re-INVITE request for MCVideo imminent peril group call

This clause is referenced from other procedures.

The controlling MCVideo function shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [11].

The controlling MCVideo function:

1) shall include in the Contact header field an MCVideo session identity for the MCVideo session with the g.3gpp.mcvideo media feature tag and the isfocus media feature tag according to IETF RFC 3840 [22];

2) shall include an SDP offer with the media parameters as currently established with the terminating MCVideo client according to 3GPP TS 24.229 [11];

3) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideo-calling-user-id> element set to the MCVideo ID of the initiating MCVideo user;

4) if the in-progress imminent peril state of the group is set to a value of "true" the controlling MCVideo function:

a) shall include a Resource-Priority header field populated with the values for an MCVideo imminent peril group call as specified in clause 6.3.3.1.18; and

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

5) if the in-progress imminent peril state of the group is set to a value of "false":

a) shall include a Resource-Priority header field populated with the values for a normal MCVideo group call as specified in clause 6.3.3.1.18; and

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

6.3.3.1.15 Handling the expiry of timer TNG2 (in-progress emergency group call timer)

Upon expiry of timer TNG2 (in-progress emergency group call timer) for an MCVideo group, the controlling MCVideo function:

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

2) shall, if an MCVideo group call or MCVideo group session is in progress on the indicated group, for each of the participating members:

a) generate a SIP re-INVITE request as specified in clause 6.3.3.1.9; and

b) send the SIP re-INVITE request towards the MCVideo client according to 3GPP TS 24.229 [11]; and

3) shall for each affiliated but non-participating members member of the group:

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

b) shall include in the P-Asserted-Identity header field the public service identity of the controlling MCVideo function;

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

d) send the SIP MESSAGE request towards the MCVideo client according to rules and procedures of 3GPP TS 24.229 [11].

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

6.3.3.1.16 Validate priority request parameters

This clause is referenced from other procedures. This procedure validates the combinations of <emergency-ind>, <imminentperil-ind> and <alert-ind> in the application/vnd.3gpp.mcvideo-info+xml MIME body included in:

1) a SIP INVITE request or SIP re-INVITE request; or

2) the body "URI" header field of the SIP URI included in a "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element in the application/resource-lists+xml MIME body which is pointed to by a "cid" URL located in the Refer-To header of a SIP REFER request;

Upon receiving a SIP request as specified above with the <emergency-ind> element set to a value of "true", the controlling MCVideo function shall only consider the following as valid combinations:

1) <imminentperil-ind> not included and <alert-ind> included.

Upon receiving a SIP request as specified above with the <emergency-ind> element set to a value of "false", the controlling MCVideo function shall only consider the following as valid combinations:

1) <imminentperil-ind> not included and <alert-ind> not included; or

2) <imminentperil-ind> not included and <alert-ind> included.

Upon receiving a SIP request as specified above with the <imminentperil-ind> element included the controlling MCVideo function shall only consider the request as valid if both the <emergency-ind> and <alert-ind> are not included.

If the combination of the <emergency-ind>, <imminentperil-ind> or <alert-ind> indicators is invalid, the controlling MCVideo function shall send a SIP 403 (Forbidden) response with the warning text set to "150 invalid combinations of data received in MIME body" in a Warning header field as specified in clause 4.4.

6.3.3.1.17 Sending a SIP INFO request in the dialog of a SIP request for a priority call

This clause is referenced from other procedures and describes how the controlling MCVideo function generates a SIP INFO request due to the receipt of a SIP request for a priority call.

The controlling MCVideo function:

1) shall generate a SIP INFO request according to rules and procedures of 3GPP TS 24.229 [11] and IETF RFC 6086 [21];

2) shall include the Info-Package header field set to g.3gpp.mcvideo-info in the SIP INFO request;

3) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body in the SIP INFO request and:

a) if the received SIP request contained application/vnd.3gpp.mcvideo-info+xml MIME body with the <alert-ind> element set to a value of "true" and this is an unauthorised request for an MCVideo emergency alert as specified in clause 6.3.3.1.12.1, shall set the <emergency-ind> element to a value of "true" and the <alert-ind> element to a value of "false";

b) if the received SIP request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <alert-ind> element set to a value of "false" and if this is an unauthorised request for an MCVideo emergency alert cancellation, shall set <alert-ind> element to a value of "true"; and

c) if the received SIP request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <imminentperil-ind> element set to a value of "true", this is an authorised request for an MCVideo imminent peril group call and the in-progress emergency state of the group is set to a value of "true", shall set the <imminentperil-ind> element to a value of "false" and the <emergency-ind> element set to a value of "true"; and

4) shall send the SIP INFO request towards the inviting MCVideo client in the dialog created by the SIP request from the inviting MCVideo client, as specified in 3GPP TS 24.229 [11].

6.3.3.1.18 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 controlling MCVideo function:

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 (see the service configuration document in 3GPP TS 24.484 [25]); 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 (see the service configuration document in 3GPP TS 24.484 [25]).

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 controlling MCVideo function:

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 (see the service configuration document in 3GPP TS 24.484 [25]); 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 (see the service configuration document in 3GPP TS 24.484 [25])

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 controlling MCVideo function:

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 (see the service configuration document in 3GPP TS 24.484 [25]); 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 (see the service configuration document in 3GPP TS 24.484 [25]).

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.3.3.1.19 Generating a SIP MESSAGE request to indicate successful receipt of an emergency alert or emergency cancellation

This clause is referenced from other procedures.

This clause describes the procedures for generating a SIP MESSAGE request to notify the originator of an emergency alert or emergency cancellation that the request was successfully received.

The controlling MCVideo function:

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

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

4) shall set the Request-URI to the public service identity of the terminating participating function associated with the MCVideo ID of the targeted MCVideo user;

NOTE 1: The public service identity can identify the terminating participating MCVideo function in the local MCVideo system or in an interconnected MCVideo system.

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

5) shall include a P-Asserted-Identity header field set to the public service identity of controlling MCVideo function; and

6) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <mcvideo-request-uri> element set to the value of the MCVideo ID of the targeted MCVideo user.

6.3.3.1.20 Generating a SIP MESSAGE request for notification of entry into or exit from an emergency alert area

This clause describes the procedures for generating a SIP MESSAGE request to notify an MCVideo client that it has entered a pre-defined emergency alert area or exited from a pre-defined emergency alert area. The procedure is initiated by the participating MCVideo function when the participating MCVideo function determines that the MCVideo client has entered a pre-defined emergency alert area or exited from a pre-defined emergency alert area.

NOTE: The participating MCVideo function can use additional implementation-specific selection criteria to decide the recipients of the notification, i.e., whether and when an entry/exit notification is sent. The additional criteria can be the activated functional alias, ongoing emergency or conditions related to position such as speed, heading etc. The determination of the specific region is left to implementation.

The participating MCVideo function:

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

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

4) shall set the Request-URI to the public user identity associated to the MCVideo ID of the targeted MCVideo user;

5) shall include a P-Asserted-Identity header field set to the public service identity of the participating MCVideo function;

6) 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-Asserted-Service-Id header field according to IETF RFC 6050 [14];

8) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body an <emergency-alert-area-ind> element:

a) set to a value of "true", if the MCVideo client has entered a pre-defined emergency alert area; or

b) set to a value of "false", if the MCVideo client has exited from a pre-defined emergency alert area; and

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

Upon receiving a SIP 200 (OK) response to the SIP MESSAGE request, if the <emergency-alert-area-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body in the SIP MESSAGE request was:

1) set to a value of "true", shall record that the MCVideo client has received the notification that it has entered the pre-defined emergency alert area; and

2) set to a value of "false", shall record that the MCVideo client has received the notification that it has exited the pre-defined emergency alert area.

6.3.3.1.21 Generating a SIP MESSAGE request for notification of entry into or exit from a group geographic area

This clause describes the procedures for generating a SIP MESSAGE request to notify an MCVideo client that it has entered a pre-defined group geographic area or exited from a pre-defined group geographic area requiring affiliation to or de-affiliation from a group. The procedure is initiated by the participating MCVideo function when the participating MCVideo function determines that the MCVideo client has entered a pre-defined group geographic area or exited from a pre-defined group geographic area.

The participating MCVideo function:

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

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

4) shall set the Request-URI to the public user identity associated to the MCVideo ID of the targeted MCVideo user;

5) shall include a P-Asserted-Identity header field set to the public service identity of the participating MCVideo function;

6) 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-Asserted-Service-Id header field according to IETF RFC 6050 [14];

7) void;

8) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body with an <mcvideoinfo> element containing the <mcvideo-Params> element with:

a) an <mcvideo-request-uri> element set to the value of the MCVideo ID of the targeted MCVideo user;

b) an <associated-group-id> element set to the MCVideo group ID of the group for which a pre-defined group geographic area has been entered or exited; and

c) a <group-geo-area-ind> element:

i) set to a value of "true", if the MCVideo client has entered a pre-defined group geographic area; or

ii) set to a value of "false", if the MCVideo client has exited from a pre-defined group geographic area; and

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

Upon receiving a SIP 200 (OK) response to the SIP MESSAGE request, if the <group-geo-area-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body in the SIP MESSAGE request was:

1) set to a value of "true", shall record that the MCVideo client has received the notification that it has entered the pre-defined group geographic area; and

2) set to a value of "false", shall record that the MCVideo client has received the notification that it has exited the pre-defined group geographic area.

6.3.3.2 Requests terminated by the controlling MCVideo function

6.3.3.2.1 SDP answer generation

When composing the SDP answer according to 3GPP TS 24.229 [11], the controlling MCVideo function:

1) for the accepted media stream in the received SDP offer:

a) shall replace the IP address and port number in the received SDP offer with the IP address and port number of the controlling MCVideo function; and

2) for the accepted media-transmission control entity, if present in the received SDP offer:

a) shall replace the IP address and port number in the received SDP offer with the IP address and port number of the controlling MCVideo function, for the accepted media-transmission control entity, if present in the received SDP offer; and

b) shall include ‘fmtp’ attributes as specified in 3GPP TS 24.581 clause 14.

6.3.3.2.2 Receipt of a SIP INVITE request

On receipt of an initial SIP INVITE request the controlling MCVideo function shall cache SIP feature tags, if received in the Contact header field and if the specific feature tags are supported.

6.3.3.2.3 Sending a SIP response to a SIP INVITE request

6.3.3.2.3.1 Provisional response

When sending SIP provisional responses with the exception of the SIP 100 (Trying) response to the SIP INVITE request the controlling MCVideo function:

1) shall generate the SIP provisional response;

2) shall include a P-Asserted-Identity header field with the public service identity of the controlling MCVideo function;

3) shall include an MCVideo session identity in the Contact header field; and

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

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

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

c) the isfocus media feature tag.

6.3.3.2.3.2 Final response

When sending a SIP 200 (OK) response to the initial SIP INVITE request, the controlling MCVideo function:

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

2) shall include the Session-Expires header field and start supervising the SIP session according to rules and procedures of IETF RFC 4028 [23], "UAS Behavior". The "refresher" parameter in the Session-Expires header field shall be set to "uac";

3) shall include the option tag "timer" in a Require header field;

4) shall include a P-Asserted-Identity header field with the public service identity of the controlling MCVideo function;

5) shall include a SIP URI for the MCVideo session identity in the Contact header field identifying the MCVideo session at the controlling MCVideo function;

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

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

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

c) the isfocus media feature tag;

7) shall include Warning header field(s) received in incoming responses to the SIP INVITE request;

8) shall include the option tag "tdialog" in a Supported header field according to rules and procedures of IETF RFC 4538 [32];

9) shall include the "norefersub" option tag in a Supported header field according to IETF RFC 4488 [31];

10) shall include the "explicitsub" and "nosub" option tags in a Supported header field according to IETF RFC 7614 [81];

11) if:

a) an MCVideo GKTP document exists for the group identity contained in the <mcvideo-request-uri> element in the application/vnd.3gpp.mcvideo-info+xml MIME body of the initial SIP INVITE request; and

b) the MCVideo GKTP document contains an <MKFC-GKTPs> element;

then:

a) for each instance of <GKTP> element of the <MKFC-GKTPs> element of the MCVideo GKTP document:

i) shall perform the procedure in clause 6.3.3.6.2 to re-generate an I_MESSAGE; and

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

6.3.3.2.4 Receiving a SIP BYE request

Upon receiving a SIP BYE request the controlling MCVideo function:

1) shall interact with the media plane as specified in clause 6.3 in 3GPP TS 24.581 [5] for releasing the media plane resource associated with the SIP session towards the MCVideo client;

NOTE: The non-controlling MCVideo function is also regarded as a MCVideo client in a temporary MCVideo group session.

2) shall generate a SIP 200 (OK) response and send the SIP response towards the MCVideo client according to 3GPP TS 24.229 [11];

3) shall check the MCVideo session release policy as specified in clause 6.3.8.1 and clause 6.3.8.2 whether the MCVideo session needs to be released for each participant of the MCVideo session;

4) if release of the MCVideo session is required:

a) shall perform the procedures as specified in the clause 6.3.3.1.4 with the clarification that if the received SIP BYE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body, copy the application/vnd.3gpp.mcvideo-info+xml MIME body into the outgoing SIP BYE request; and

5) if a release of the MCVideo session is not required, shall send a SIP NOTIFY request to all remaining MCVideo clients in the MCVideo session with a subscription to the conference event package as specified in clause 9.2.3.4.2.

Upon receiving a SIP 200 (OK) response to the SIP BYE request the controlling MCVideo function shall interact with the media plane as specified in clause 6.3 in 3GPP TS 24.581 [5] for releasing media plane resources associated with the SIP session with the MCVideo participant.

6.3.3.3 Handling of the acknowledged call setup timer (TNG1)

When the controlling MCVideo function receives a SIP INVITE request to initiate a group session and there are members of the group document retrieved from the group management server that are affiliated and are marked as <on-network-required> as specified in 3GPP TS 24.481 [24], then the controlling MCVideo function shall start timer TNG1 (acknowledged call setup timer) with a timer value as described in Annex B.2.1, prior to sending out SIP INVITE requests inviting group members to the group session.

When the controlling MCVideo function receives all SIP 200 (OK) responses to the SIP INVITE requests, from all affiliated and <on-network-required> members then the controlling MCVideo function shall stop timer TNG1 (acknowledged call setup timer) and if the local counter of the number of SIP 200 (OK) responses received from invited members is greater than or equal to the value of the <on-network-minimum-number-to-start> element of the group document, the controlling MCVideo function shall send a SIP 200 (OK) response to the initiating MCVideo client.

NOTE 1: MCVideo clients that are affiliated but are not <on-network-required> members that have not yet responded will be considered as joining an ongoing session when the controlling MCVideo function receives SIP 200 (OK) responses from these MCVideo clients.

After expiry of timer TNG1 (acknowledged call setup timer) and the local counter of the number of SIP 200 (OK) responses received from invited members is less than the value of the <on-network-minimum-number-to-start> element of the group document, then the controlling MCVideo function shall wait until further responses have been received from invited clients and the value of the local counter of the number of SIP 200 (OK) responses received from invited members is equal to the <on-network-minimum-number-to-start>, before continuing with the timer TNG1 expiry procedures in this clause.

After expiry of timer TNG1 (acknowledged call setup timer) and the local counter of the number of SIP 200 (OK) responses received from invited members is greater or equal to the value of the <on-network-minimum-number-to-start> element of the group document, the controlling MCVideo function shall execute the steps described below:

1) if the <on-network-action-upon-expiration-of-timeout-for-acknowledgement-of-required-members> element configured in the group document for the action on expiry of the timer is set to "proceed" indicating that the controlling MCVideo function should proceed with the setup of the group call, then the controlling MCVideo function:

a) shall perform the following actions:

i) generate a SIP 200 (OK) response to the SIP INVITE request as specified in the clause 6.3.3.2.2 before continuing with the rest of the steps;

ii) include in the SIP 200 (OK) response the warning text set to "111 group call proceeded without all required group members" in a Warning header field as specified in clause 4.4;

iii) include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the clause 6.3.3.2.1;

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

NOTE 2: Resulting media plane processing is completed before the next step is performed.

v) send a SIP 200 (OK) response to the inviting MCVideo client according to 3GPP TS 24.229 [11];

b) when a SIP 200 (OK) response to a SIP INVITE request is received from an invited MCVideo client the controlling MCVideo function may send an in-dialog SIP MESSAGE request to the MCVideo client that originated the group session with the text "group call proceeded without all required group members";

c) when the controlling MCVideo function receives a SIP BYE request from an invited MCVideo client, shall take the actions specified in clause 6.3.3.2.4 and may send an in-dialog SIP MESSAGE request to the MCVideo client that originated the group session with the text "group call proceeded without all required group members"; and

d) shall generate a notification package as specified in clause 6.3.3.4 and send a SIP NOTIFY request according to 3GPP TS 24.229 [11] to the MCVideo clients which have subscribed to the conference state event; and

2) if the <on-network-action-upon-expiration-of-timeout-for-acknowledgement-of-required-members> element configured in the group document for the action on expiry of the timer is set to "abandon" indicating that the controlling MCVideo function should abandon the setup of the group call, then the controlling MCVideo function shall:

a) send a SIP 480 (Temporarily Unavailable) response to the MCVideo client that originated the group session with the warning text set to "112 group call abandoned due to required group members not part of the group session" in a Warning header field as specified in clause 4.4;

b) for each confirmed dialog at the controlling MCVideo function, send a SIP BYE request towards the MCVideo clients invited to the group session in accordance with 3GPP TS 24.229 [11] and interact with the media plane as specified in 3GPP TS 24.581 [5]; and

c) for each non-confirmed dialog at the controlling MCVideo function, send a SIP CANCEL request towards the MCVideo clients invited to the group session in accordance with 3GPP TS 24.229 [11].

If the controlling MCVideo function receives a final SIP 4xx, 5xx or 6xx response from an affiliated and <on-network-required> group member prior to expiry of timer TNG1 (acknowledged call setup timer) and based on policy, the controlling MCVideo function decides not to continue with the establishment of the group call without the affiliated and <on-network-required> group member, then the controlling MCVideo function:

NOTE 3: It is expected that this action is taken if the policy is to abandon the call on expiry of timer TNG1 (acknowledged call setup timer).

1) shall stop timer TNG1 (acknowledged call setup timer); and

2) shall forward the final SIP 4xx, 5xx or 6xx response towards the inviting MCVideo client with the warning text set to "112 group call abandoned due to required group member not part of the group session" in a Warning header field as specified in clause 4.4.

If:

1) the controlling MCVideo function receives a final SIP 4xx, 5xx or 6xx response from an affiliated and <on-network-required> group member prior to expiry of timer TNG1 (acknowledged call setup timer);

2) the local counter of the number of SIP 200 (OK) responses received from invited members is greater than or equal to the value of the <on-network-minimum-number-to-start> element of the group document; and

3) based on policy, the controlling MCVideo function decides to continue with the establishment of the group call without the affiliated and <on-network-required> group member;

then the controlling MCVideo function:

NOTE 4: It is expected that this action is taken if the policy is to proceed with the call on expiry of timer TNG1 (acknowledged call setup timer).

1) if all other invited clients have not yet responded, shall continue running timer TNG1 (acknowledged call setup timer); and

2) if all other invited clients have responded with SIP 200 (OK) responses, shall

a) stop timer TNG1 (acknowledged call setup timer);

b) generate SIP 200 (OK) response to the SIP INVITE request as specified in the clause 6.3.3.2.2 before continuing with the rest of the steps;

c) include in the SIP 200 (OK) response the warning text set to "111 group call proceeded without all required group members" in a Warning header field as specified in clause 4.4;

d) include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the clause 6.3.3.2.1;

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

NOTE 5: Resulting media plane processing is completed before the next step is performed.

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

6.3.3.4 Generating a SIP NOTIFY request

The controlling MCVideo function shall generate a SIP NOTIFY request according to 3GPP TS 24.229 [11] with the clarification in this clause.

In the SIP NOTIFY request, the controlling MCVideo function:

1) shall set the P-Asserted-Identity header field to the public service identity of the controlling MCVideo function;

2) shall include an Event header field set to the "conference" event package;

3) shall include an Expires header field set to 3600 seconds according to IETF RFC 4575 [57], as default value;

4) 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]; and

5) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with:

a) the <mcvideo-calling-group-id> set to the value of the MCVideo group ID;

b) if the target is a MCVideo user, the value of <mcvideo-request-uri> element set to the value of MCVideo ID of the targeted MCVideo user; and

c) if the target is the non-controlling MCVideo function, the value of <mcvideo-request-uri> element set to the constituent MCVideo group ID.

In the SIP NOTIFY request, the controlling MCVideo function shall include an application/conference-info+xml MIME body according to IETF RFC 4575 [57] with the following limitations:

1) the controlling MCVideo function shall include the MCVideo group ID of the MCVideo group in the "entity" attribute of the <conference-info> element;

2) for each participant in the MCVideo session with the exception of non-controlling MCVideo functions, the controlling MCVideo function shall include a <user> element. The <user> element shall:

NOTE: Non-controlling MCVideo functions will appear as a participant in temporary group sessions.

a) include the "entity" attribute. The "entity" attribute:

i) shall for the MCVideo client, which initiated, joined or re-joined an MCVideo session, include the MCVideo ID of the MCVideo user which originates SIP INVITE request; and

ii) shall for an invited MCVideo client include the MCVideo ID of the invited MCVideo user in case of a prearranged group call or chat group call;

b) shall include a single <endpoint> element. The <endpoint> element:

i) shall include the "entity" attribute;

ii) shall include the <status> element indicating the status of the MCVideo session according to IETF RFC 4575 [57]; and

iii) may include one <functional-alias> element indicating the functional alias bound by the MCVideo user with the MCVideo group for which the notification is being sent as defined in the XML schema of clause 9.2.3.6.1; and

NOTE 1: The functional alias binding by the MCVideo user with the MCVideo group is done through either using an explicit procedure or as a part of call setup procedure.

c) may include <roles> element.

NOTE: The usage of <roles> is only applicable for human consumption.

6.3.3.5 Handling of the group call timer (TNG3)

6.3.3.5.1 General

When the controlling MCVideo function receives a SIP INVITE request to initiate a group session, then after an MCVideo session identity has been allocated for the group session and if the <on-network-maximum-duration> element is present in the group document as specified in 3GPP TS 24.481 [24], the controlling MCVideo function: shall start timer TNG3 (group call timer) with the value obtained from the <on-network-maximum-duration> element of the group document as specified in 3GPP TS 24.481 [24].

If the <on-network-maximum-duration> element is not present in the group document as specified in 3GPP TS 24.481 [24], then the controlling MCVideo function shall not start timer TNG3 (group call timer).

NOTE 1: The configuration of <on-network-maximum-duration> element in 3GPP TS 24.481 [24] is mandated for a pre-arranged group and is optional for a chat group.

When merging two or more active group calls into a temporary group call, the controlling MCVideo function(s) hosting the active group calls shall stop timer TNG3 (group call timer) for each group call, and the controlling MCVideo function hosting the temporary group call shall start timer TNG3 (group call timer) for the temporary group call.

NOTE 2: If the MCVideo server(s) hosting the independent active group calls are different to the MCVideo server that will host the temporary group call, then the MCVideo server(s) hosting the independent active group calls become non-controlling MCVideo function(s) of an MCVideo group, for the temporary group call.

When splitting a temporary group call into independent group calls, the controlling MCVideo function hosting the temporary group call shall stop timer TNG3 (group call timer) and the controlling MCVideo function(s) hosting the independent group calls shall start TNG3 (group call timer) for each group call.

When the last MCVideo client leaves the MCVideo session, the controlling MCVideo function shall stop timer TNG3 (group call timer).

On expiry of timer (group call timer), the controlling MCVideo function shall release the MCVideo session by following the procedures in clause 6.3.3.1.4;

6.3.3.5.2 Interaction with the in-progress emergency group call timer (TNG2)

If the controlling MCVideo function starts timer TNG2 (in-progress emergency group call timer), it shall not start timer TNG3 (group call timer).

If timer TNG3 (group call timer) is running and the MCVideo group call is upgraded to an MCVideo emergency group call, then the controlling MCVideo function shall stop timer TNG3 (group call timer) and shall start timer TNG2 (in-progress emergency group call timer) with the value obtained from the <group-time-limit> element of the <emergency-call> element of the <on-network> element of the service configuration document as specified in 3GPP TS 24.484 [25].If timer TNG2 (in-progress emergency group call timer) is running and the MCVideo emergency group call is cancelled, then the controlling MCVideo function shall stop timer TNG2 (in-progress emergency group call timer) and shall start timer TNG3 (group call timer) with the value obtained from the <on-network-maximum-duration> element of the group document as specified in 3GPP TS 24.481 [24].

If timer TNG2 (in-progress emergency group call timer) is running and subsequently expires, then the controlling MCVideo function shall start timer TNG3 (group call timer) with the value obtained from the <on-network-maximum-duration> element of the group document as specified in 3GPP TS 24.481 [24].

NOTE: The above conditions for starting timer TNG2 (in-progress emergency group call timer) and timer TNG3 (group call timer) also apply in the case that these timers are re-started. For example: the case where the timer TNG3 was initially running, the MCVideo group call is upgraded to an MCVideo emergency group call and then the MCVideo emergency group call is cancelled.

6.3.3.6 Generation of I_MESSAGEs containing MKFC and MKFC-ID

6.3.3.6.1 General

This procedures in this clause are executed by the controlling MCVideo function as a result of receiving SIP INVITE requests targeted to a group identity, where the controlling MCVideo function has subscribed to the MCVideo group key transport payloads (GKTP) document as specified in 3GPP TS 24.481 [24] for the group identity and the controlling MCVideo function has been notified of the GKTP document for the group identity containing a <MKFC-GKTPs> element.

The <MKFC-GKTPs> element contains one or more <GKTP> elements where each <GKTP> element represents an I_MESSAGE(s) containing an MKFC and MKFC-ID, as specified in 3GPP TS 24.481 [24].

6.3.3.6.2 Creation of an I_MESSAGE containing MKFC

The controlling MCVideo function:

1) shall extract the GMS URI from the initiator field (IDRi) of the I_MESSAGE and use it together with the timer related parameter to check the signature of the I_MESSAGE as described in 3GPP TS 33.180 [8];

3) if the contents of the IDRr do not match to the controlling MCVideo function URI, shall exit this procedure. Otherwise, shall use the contents of the IDRr to decrypt the I_MESSAGE and extract the MKFC and MKFC-ID;

4) shall re-generate the I_MESSAGE containing a common header payload, a timestamp payload, an IDRi payload, an IDRr payload, an IDRkmsi payload, an IDRkmsr payload, a SAKKE payload, a SIGN payload, a security policy payload and a general extension payload containing the MKFC and MKFC-ID, as specified in the group key transport payload structure in clause 7.4.2 in 3GPP TS 24.481 [24], but with the following clarifications:

NOTE: The MKFC is treated as a GMK for transport, using the security procedures defined in clause 7.3.1 of 3GPP TS 33.180 [8] and the encapsulation procedures of Annex E.2 of 3GPP TS 33.180 [8].

a) the IDRi payload (or ID payload with ID role field set to the ‘IDRuidi’) contains the URI of the controlling MCVideo function;

b) if the I_MESSAGE is to be sent to the participating MCVideo function, the IDRr payload (or ID payload with ID role fields set to ‘IDRuidr’) contains the URI of the participating MCVideo function;

c) if the I_MESSAGE is to be sent to the non-controlling MCVideo function, the IDRr payload (or ID payload with ID role fields set to ‘IDRuidr’) contains the URI of the non-controlling MCVideo function;

d) the ID data field of the IDRkmsi payload is set to the URI of the MCVideo KMS used by the controlling MCVideo function;

e) if the I_MESSAGE is to be sent to the participating MCVideo function, then the ID data field of the IDRkmsr is set to URI of the MCVideo KMS used by the participating MCVideo function; and

f) if the I_MESSAGE is to be sent to the non-controlling MCVideo function, then the ID data field of the IDRkmsr is set to URI of the MCVideo KMS used by the participating MCVideo function;

5) shall sign the I_MESSAGE using the controlling MCVideo function URI;

6) if the I_MESSAGE is to be sent to the participating MCVideo function, shall encrypt the I_MESSAGE using the participating MCVideo function URI; and

7) if the I_MESSAGE is to be sent to the non-controlling MCVideo function, shall encrypt the I_MESSAGE using the non-controlling MCVideo function URI.

6.3.4 Non-controlling MCVideo function of an MCVideo group

6.3.4.1 Request initiated by the non-controlling MCVideo function of an MCVideo group

6.3.4.1.1 SDP offer generation

The SDP offer is generated based on the received SDP offer. The SDP offer generated by the non-controlling MCVideo function of an MCVideo group:

1) shall include only one SDP media-level section for the MCVideo video media stream according to 3GPP TS 24.229 [11], as contained in the received SDP offer;

2) shall include only one SDP media-level section for the MCVideo audio media stream according to 3GPP TS 24.229 [11], as contained in the received SDP offer; and

3) shall contain one SDP media-level section for a media transmission control entity according to 3GPP TS 24.229 [11], if present in the received SDP offer.

When composing the SDP offer according to 3GPP TS 24.229 [11], the non-controlling MCVideo function of an MCVideo group:

1) shall replace the IP address and port number for the offered audio media stream in the "m=audio" media-level section with an IP address and port number of the non-controlling MCVideo function;

2) for the MCVideo audio media stream, shall include all media-level attributes from the received SDP offer;

3) shall replace the IP address and port number for the offered video media stream in the "m=video" media-level section with an IP address and port number of the non-controlling MCVideo function;

4) for the MCVideo video media stream, shall include all media-level attributes from the received SDP offer;

5) shall replace the IP address and port number for the offered media transmission control entity, if any, in the received SDP offer with an IP address and port number of the non-controlling MCVideo function; and

6) shall include the offered media transmission control entity ‘fmtp’ attributes as specified in 3GPP TS 24.581 [5].

6.3.4.1.2 Sending an INVITE request towards the MCVideo client

This clause is referenced from other procedures.

The non-controlling MCVideo function of an MCVideo group shall generate initial SIP INVITE requests according to 3GPP TS 24.229 [11].

For each SIP INVITE request, the non-controlling MCVideo function of an MCVideo group:

1) shall generate a new MCVideo session identity for the MCVideo session with the invited MCVideo client and include it in the Contact header field together with the g.3gpp.mcvideo media feature tag, the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo", and the isfocus media feature tag according to IETF RFC 3840 [22];

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

5) shall set the Request-URI to the public service identity of the terminating participating MCVideo function associated to the MCVideo ID of the MCVideo user to be invited;

NOTE 1: The public service identity can identify the terminating participating MCVideo function in the local MCVideo system or in an interconnected MCVideo system.

NOTE 4: How the non-controlling MCVideo function determines the public service identity of the terminating participating MCVideo function associated with the MCVideo ID of the MCVideo user to be invited or of the MCVideo gateway server in the interconnected MCVideo system is out of the scope of the present document.

NOTE 5: 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 copy the application/vnd.3gpp.mcvideo-info+xml MIME body in the received SIP INVITE request to the outgoing SIP INVITE request;

6a) shall update the application/vnd.3gpp.mcvideo-info+xml MIME body with an <mcvideo-calling-group-id> element set to the identity of the TGI or of the group regroup based on a preconfigured group;

6b) shall update the application/vnd.3gpp.mcvideo-info+xml MIME body with an <associated-group-id> element set to the identity of the constituent group;

7) shall update the application/vnd.3gpp.mcvideo-info+xml MIME body with an <mcvideo-request-uri> element set to the MCVideo ID of the invited MCVideo user;

8) shall include the public service identity of the non-controlling MCVideo function in the P-Asserted-Identity header field;

9) shall include the received Referred-By header field with the public user identity of the inviting MCVideo client;

10) should include the Session-Expires header field according to rules and procedures of IETF RFC 4028 [23]. The refresher parameter shall be omitted;

11) shall include the Supported header field set to "timer";

12) shall include an unmodified Answer-Mode header field, if present in the incoming SIP INVITE request; and

13)void.

6.3.4.1.3 Sending a SIP INFO request

This clause is referenced from other procedures.

The non-controlling MCVideo function shall generate a SIP INFO request according to rules and procedures of 3GPP TS 24.229 [11] and IETF RFC 6086 [21].

The non-controlling MCVideo function:

1) shall include the Info-Package header field set to "g.3gpp.mcvideo-transmission-request";

2) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideo-request-uri> set to the temporary MCVideo group ID and the <mcvideo-calling-group-id> element with the constituent MCVideo group ID;

3) shall include an application/vnd.3gpp.mcvideo-transmission-request+xml MIME body with the Content-Disposition header field set to "Info-Package". For each currently transmitting MCVideo client the application/vnd.3gpp.mcvideo-transmission-request+xml MIME body shall be populated as follows:

a) the SSRC of the MCVideo client with the permission to send media in the <ssrc> element;

b) the actual transmission priority in the <transmission-priority> element;

c) the MCVideo ID of the MCVideo user with the permission to send media in the <user-id> element;

d) the queueing capability in the <queueing-capability> element of the <track-info> element;

e) the participant type in the <participant-type> in the <track-info> element;

f) one or more <transmission-participant-reference> elements in the <track-info> element in the same order as the would appear in the Track Info field as specified in 3GPP TS 24.581 [5] clause 9.2.3.13; and

g) if available, additional information in the <transmission-indicator> element.

6.3.4.1.4 Sending an INVITE request towards the controlling MCVideo function

This clause is referenced from other procedures.

The non-controlling MCVideo function shall generate a SIP INVITE request according to rules and procedures of 3GPP TS 24.229 [11].

The non-controlling MCVideo function:

1) shall include in the Contact header field the g.3gpp.mcvideo media feature tag, the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo", and the isfocus media feature tag according to IETF RFC 3840 [22];

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

3) shall set the Request-URI to the public service identity of the controlling MCVideo function based on the <mcvideo-request-uri> element received in the "SIP INVITE request from participating MCVideo function for non-controlling MCVideo function of an MCVideo group";

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

NOTE 2: 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 3: 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 4: How the non-controlling MCVideo function determines the public service identity of the controlling MCVideo function based on the <mcvideo-request-uri> element received in the "SIP INVITE request for controlling MCVideo function of an MCVideo group" or of the MCVideo gateway server in the interconnected MCVideo system is out of the scope of the present document.

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

4) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body with:

a) the <session-type> element set to "prearranged";

NOTE 6: The <session-type> element is set to "prearranged" regardless of which type of group the constituent MCVideo group is.

b) the <mcvideo-request-uri> element set to the identity of the TGI or of the group regroup based on a preconfigured group received in the <mcvideo-request-uri> element of the received SIP INVITE;

c) the <mcvideo-calling-group-id> element set to the identity of the constituent group received in the <associated-group-id> element of the received SIP INVITE;

d) the <mcvideo-calling-user-id> element set to the identity of the calling user received in the <mcvideo-calling-user-id> element of the received SIP INVITE; and

e the <required> element set to "true", if the group document retrieved from the group management server contains <on-network-required> group members as specified in 3GPP TS 24.481 [24];

5) shall include the public service identity of the non-controlling MCVideo function in the P-Asserted-Identity header field;

6) should include the Session-Expires header field according to rules and procedures of IETF RFC 4028 [23]. The refresher parameter shall be omitted; and

7) shall include the Supported header field set to "timer".

6.3.4.2 Requests terminated by the non-controlling MCVideo function of an MCVideo group

6.3.4.2.1 SDP answer generation

When composing the SDP answer according to 3GPP TS 24.229 [11], the non-controlling MCVideo function of an MCVideo group:

1) for the accepted audio media stream in the received SDP offer:

a) shall set the IP address and port number to the IP address and port number of the non-controlling MCVideo function;

2) for the accepted video media stream in the received SDP offer:

a) shall set the IP address and port number to the IP address and port number of the non-controlling MCVideo function; and

3) for the accepted media transmission control entity, if present in the received SDP offer:

a) shall set the IP address and port number to the IP address and port number of the non-controlling MCVideo function; and

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

6.3.4.2.2 Sending a SIP response to the SIP INVITE request

6.3.4.2.2.1 Sending a SIP 183 (Session Progress) response

When sending a SIP 183 (Session Progress) the non-controlling MCVideo function of an MCVideo group:

1) shall generate a SIP 183 (Session Progress) response according to 3GPP TS 24.229 [11];

2) 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";

3) shall include the public service identity of the non-controlling MCVideo function in the P-Asserted-Identity header field; and

4) shall include the option tag "tdialog" in a Supported header field according to rules and procedures of IETF RFC 4538 [32];

6.3.4.2.2.2 Sending a SIP 200 (OK) response

When sending a SIP 200 (OK) response, the non-controlling MCVideo function of an MCVideo group:

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

3) shall include the option tag "timer" in a Require header field;

4) shall include the public service identity of the non-controlling MCVideo function in the P-Asserted-Identity header field;

5) shall include a SIP URI for the MCVideo session identity in the Contact header field identifying the MCVideo session at the non-controlling MCVideo function;

6) 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";

7) if allowed by local policy and if Warning header field(s) were received in incoming responses to SIP INVITE requests that were sent as a result of following the procedures of clause 6.3.4.1.2, shall include those Warning header field(s);

8) shall include the option tag "tdialog" in a Supported header field according to rules and procedures of IETF RFC 4538 [32];

9) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideo-called-party-id> element set to the constituent MCVideo group ID and the <transmission-state> element set to the state of the transmission; and

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

6.3.4.3 Generating a SIP NOTIFY request

The non-controlling MCVideo function shall generate a SIP NOTIFY request according to 3GPP TS 24.229 [11] with the clarification in this clause.

In the SIP NOTIFY request, the non-controlling MCVideo function:

1) shall set the P-Asserted-Identity header field to the public service identity of the non-controlling MCVideo function;

2) shall include an Event header field set to "conference";

3) shall include an Expires header field set to 3600 seconds according to IETF RFC 4575 [57], as default value;

4) 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]; and

5) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with:

a) the <mcvideo-calling-group-id> set to the value of the constituent MCVideo group ID;

b) if the target is an MCVideo user, the value of <mcvideo-request-uri> element set to the MCVideo ID of the targeted MCVideo user; and

c) if the target is the controlling MCVideo function the value of <mcvideo-request-uri> element set to the temporary MCVideo group ID.

In the SIP NOTIFY request, the non-controlling MCVideo function shall include application/conference-info+xml MIME body according to IETF RFC 4575 [57] as specified in clause 6.3.3.4 with the following exceptions:

1) the non-controlling MCVideo function shall not regard the controlling MCVideo function as a participant and not include the controlling MCVideo function in a <user> element; and

NOTE: The controlling MCVideo function initiated the temporary group call and will appear as a participant in the group session.

2) the non-controlling MCVideo function shall include stored conference status information received in SIP NOTIFY requests from the controlling MCVideo function in clause 9.2.3.5.3 and status information about own participants.

6.3.5 Retrieving and processing a group document

6.3.5.1 General

This clause describes how an MCVideo server accesses a group document from a group management server.

NOTE 1: The group document for a user or group regroup based on a preconfigured group is the group document for the preconfigured group restricted to the users or groups included in the regroup stored by the MCVideo server at the time of the regroup creation and does not include a <preconfigured-group-use-only> element.

The MCVideo server which accesses a group document performs the role of a controlling MCVideo function or performs the role of a non-controlling MCVideo function of an MCVideo group when accessing a group document. In such cases, for a group call:

– the controlling MCVideo function and group management server are both located in the primary MCVideo system;

– the controlling MCVideo function and group management server are both located in a partner MCVideo system;

– the controlling MCVideo function is located in the primary MCVideo system and accesses a group management server in the primary MCVideo system and a non-controlling MCVideo function of an MCVideo group is located in a partner MCVideo system and accesses a group management server in the partner MCVideo system; or

– the controlling MCVideo function and non-controlling MCVideo function(s) of an MCVideo group are located in the primary MCVideo system and access group management servers in the primary MCVideo system.

When the MCVideo server receives a SIP INVITE request that requires it to access a group document, it uses an MCVideo group ID or a temporary MCVideo group identity (TGI) which was created by the group regrouping operation as specified in 3GPP TS 24.481 [24].

The MCVideo server can cache the group document associated with an MCVideo group or temporary group, and can subscribe to be notified of changes to the group document associated with an MCVideo group or temporary group as specified in 3GPP TS 24.481 [24].

NOTE 2: During the group regrouping operation as specified in 3GPP TS 24.481 [24], the controlling MCVideo function is notified of the constituent MCVideo group identities associated with the TGI.

If the group data associated with an MCVideo group ID or TGI cached in the MCVideo server is removed, the MCVideo server re-subscribes for changes in the group information associated with the MCVideo group ID or TGI.

NOTE 3: Re-subscription can occur prior to the receipt of an SIP INVITE request containing an MCVideo group ID or TGI of a group document which is no longer cached on the MCVideo server.

6.3.5.2 Rules for retrieving Group Document(s)

NOTE 1: In this clause, "MCVideo server" can refer to either the controlling MCVideo function of an MCVideo group or the non-controlling MCVideo function of an MCVideo group.

When the group document is retrieved for the controlling MCVideo function procedures (clause 9.2.1.4) or for the non-controlling MCVideo function terminating procedures (clause 9.2.1.5.2), the requested group identity refers to the group identity in the <mcvideo-request-uri> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the SIP INVITE request.

When the group document is retrieved for the non-controlling MCVideo function to initiate a temporary group session (clause 9.2.1.5.5), the requested group identity refers to the group identity of the constituent group contained in the <associated-group-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the SIP INVITE request.

Upon receipt of a SIP INVITE request:

1) if the MCVideo server is not yet subscribed to the group document for the requested group identity, the MCVideo server shall subscribe to the "xcap-diff" event-package for the group document of this group identity as specified in 3GPP TS 24.481 [24];

NOTE 2: The requested group identity is either an MCVideo group ID or a temporary MCVideo group identity (TGI).

NOTE 3: As a group document can potentially have a large content, the controlling MCVideo function of an MCVideo group can subscribe to the group document indicating support of content-indirection as defined in IETF RFC 4483 [29], by following the procedures in 3GPP TS 24.481 [24].

2) upon receipt of a SIP 404 (Not Found) response as a result of attempting to subscribe to the "xcap-diff" event-package for the group document of the requested group identity as specified in 3GPP TS 24.481 [24], the MCVideo server shall send the SIP 404 (Not Found) response with the warning text set to "113 group document does not exist" in a Warning header field as specified in clause 4.4. Otherwise, continue with the rest of the steps;

3) upon receipt of any other SIP 4xx, SIP 5xx or SIP 6xx response as a result of attempting to subscribe to the "xcap-diff" event-package for the group document of the requested group identity as specified in 3GPP TS 24.481 [24], the MCVideo server shall send the SIP final response with the warning text set to "114 unable to retrieve group document" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

4) upon receipt of a notification from the group management server containing the group document for the requested group identity, or if the group document is already cached:

a) if the MCVideo server is a non-controlling function of an MCVideo group, then the MCVideo server shall exit this clause; and

b) if the MCVideo server is a controlling function of an MCVideo group, then the MCVideo server shall determine if the group document is for a TGI or an MCVideo group ID as follows:

i) if the group document includes an <on-network-temporary> element, then the group document is associated with a TGI;

ii) if the group document does not include an <on-network-temporary> element or an <on-network-regrouped> element, then the group document is associated with an MCVideo ID that has not been regrouped; and

iii) if the group document does not include an <on-network-temporary> element but includes an <on-network-regrouped> element, then the group document is associated with an MCVideo ID that has been regrouped;

5) if the SIP INVITE request is a "SIP INVITE request for controlling function of an MCVideo group" and the requested group identity is an MCVideo group ID that has not been re-grouped, then:

a) if the <on-network-disabled> element is present in the group document, shall send a SIP 403 (Forbidden) response with the warning text set to "115 group is disabled" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

b) if the <list> element of the <list-service> element does not contain an entry matching the MCVideo ID of the user in the SIP INVITE request, shall send a SIP 403 (Forbidden) response with the warning text set to "116 user is not part of the MCVideo group" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

c) if the <on-network-invite-members> element is set to "true" and if the SIP INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <session-type> element containing a value not set to "prearranged", shall return a SIP 404 (Not Found) response with the warning text set to "117 the group identity indicated in the request is a prearranged group" as specified in clause 4.4 "Warning header field" and shall not continue with the rest of the steps; and

d) if the <on-network-invite-members> element is set to "false" and if the SIP INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <session-type> element containing a value not set to "chat" shall return a SIP 404 (Not Found) response with the warning text set to "118 the group identity indicated in the request is a chat group" as specified in clause 4.4 "Warning header field" and shall not continue with the rest of the steps; and

6) if the SIP INVITE request is a "SIP INVITE request for controlling function of an MCVideo group" and the group document for the requested group identity is an MCVideo group ID that has been regrouped, then the MCVideo server:

a) shall reject the SIP INVITE request with a SIP 403 (Forbidden) response with the warning text set to "148 group is regrouped" as specified in clause 4.4 "Warning header field".

6.3.5.3 Rules for joining a group session

The following conditions shall be met for the controlling MCVideo function to allow an MCVideo user to join an existing group session:

1) an <entry> element exists in the <list> element of the group document for the MCVideo user;

2) a <rule> exists in the group document with:

a) the <is-list-member> element of the <conditions> element present and with the <join-handling> element of the corresponding <actions> element set to "true"; or

b) the <identity> element of the <conditions> element containing an entry matching the MCVideo ID in the SIP INVITE request, with the <join-handling> element of the <actions> element set to "true"; and

3) if the <supported-services> element is present, it contains:

a) a <service> element containing an "enabler" attribute which is set to the MCVideo ICSI; and

b) if a <group-media> element is present, an entry set to "MCVideo video media".

If all of the above conditions are not met, then the MCVideo user shall not be authorised to join the group session.

6.3.5.4 Rules for initiating a prearranged group session

When the non-controlling MCVideo function of an MCivdeo group receives a request to intiate a group session for the calling MCVideo user, if:

1) one of the following conditions is met:

a) the <on-network-regrouped> element in the <list-service> element is present in the group document associated with the MCVideo group ID identified in the <associated-group-id> element of the incoming SIP INVITE and if the MCVideo ID indicated in the incoming INVITE request is the same as the MCVideo group ID in the "temporary-MCVideo-group-ID" attribute of the <on-network-regrouped> element; or

b) according to the information stored per procedures of clause 21, the group identified in the <mcvideo-request-uri> of the incoming SIP INVITE is a group regroup based on a preconfigured group and if the group identified in the <associated-group-id> of the incoming SIP INVITE is a constituent group of that group regroup based on a preconfigured group;

NOTE 1: In this step 1), the non-controlling MCVideo function checks the consistency of the constituent group with the called group regroup.

2) an <entry> element set to the MCVideo ID of the calling MCVideo user exists in the <list> element of the group document associated with the MCVideo group ID identified in the <associated-group-id> element of the incoming SIP INVITE;

NOTE 2: In this step 2), the non-controlling MCVideo function checks that the calling MCVideo user is a member of the constituent group.

3) a <rule> exists in the group document with:

a) the <is-list-member> element of the <conditions> element present and with the <allow-initiate-conference> element of the corresponding <actions> element set to "true"; or

b) the <identity> element of the <conditions> element containing an entry matching the MCVideo ID of the calling MCVideo user identified in the <mcvideo-calling-user-id> element of the SIP INVITE request, with the <allow-initiate-conference> element of the <actions> element is set to "true"; and

4) the <supported-services> element exists in the group document with

a) a <service> element containing an "enabler" attribute which is set to the MCVideo ICSI; and

b) a <group-media> element containing, an entry set to "MCVideo video media".

NOTE 3: In these steps 2) and 3), the non-controlling MCVideo function checks that the calling MCVideo user is allowed to initiate the group call per the rules in the group document, and that the group is supporting MCVideo services.

then the calling MCVideo user shall be authorised by the non-controlling MCVideo function to initiate the group session. Otherwise the calling MCVideo user shall not be authorised by the non-controlling MCVideo function to initiate the group session.

When the controlling MCVideo function of an MCvideo group receives a request to intiate a group session for the calling MCVideo user, if:

NOTE 4: The check that the MCVideo group has not been regrouped (is not a constituent group) is already done in the parent procedure and in clause 6.3.5.2.

1) the MCVideo group ID identified in the <mcvideo-request-uri> element of the incoming SIP INVITE is a temporary group or a group regroup based on preconfigured group then the calling MCVideo user shall be authorised by the controlling MCVideo function to initiate the group session and the rest of the steps in this clause shall be skipped;

NOTE 5: The consistency of the constituent group with the called regroup has already been checked at the non-controlling MCVideo function.

NOTE 6: The check that the requesting user is authorised to initiate the group call has already been done at the non-controlling MCVideo function of the constituent group.

2) one of the following condition is met:a) an <entry> element set to the MCVideo ID of the calling MCVideo user exists in the <list> element of the group document associated with the MCVideo group ID identified in the <mcvideo-request-uri > element of the incoming SIP INVITE; or

b) the group is a user regroup based on a preconfigured group and the MCVideo ID contained in the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body in the SIP INVITE request is included in the list of users that was stored during successful processing of the creation of the user regroup per clause 21;

NOTE 7: In this step 2), the controlling MCVideo function checks that the calling MCVideo user is a member of the normal group (i.e. not a constituent group nor a regroup) or a user regroup.

3) a <rule> exists in the group document with:

a) the <is-list-member> element of the <conditions> element present and with the <allow-initiate-conference> element of the corresponding <actions> element set to "true"; or

4) the <supported-services> element exists in the group document with:

a) a <service> element containing an "enabler" attribute which is set to the MCVideo ICSI; and

b) a <group-media> element containing an entry set to " MCVideo video media".

NOTE 8: In these steps 3) and 4), the controlling MCVideo function checks that the calling MCVideo user is allowed to initiate the group call per the rules in the group document, and that the group is supporting MCVideo services.

then the calling MCVideo user shall be authorised by the controlling MCVideo function to initiate the group session. Otherwise the calling MCVideo user shall not be authorised by the controlling MCVideo function to initiate the group session.

6.3.5.5 Determining the group members to invite

The MCVideo server shall only invite affiliated group members to a group session. The MCVideo server determines the affiliated members from the entries contained in the <list> element of the group document by following the procedures specified in clause 6.3.6.

If the group is not a regroup based on a preconfigured group, the MCVideo server determines the affiliated members from the entries contained in the <list> element of the group document by following the procedures specified in clause 6.3.6.

If the group is a regroup based on a preconfigured group, the MCVideo server determines the affiliated members from the list of users that was stored during successful processing of the creation of the regroup per clause 21 by following the procedures specified in clause 6.3.6.

NOTE 1: The term "affiliated group members" used above also includes those members that are implicitly affiliated by the controlling MCVideo function.

If the number of members of the MCVideo group exceeds the value contained in the <on-network-max-participant-count> element the MCVideo server shall invite only <on-network-max-participant-count> members from the list, but shall prioritise inviting those group members to the group session that have an <entry> element in the <list> element with a <on-network-required> element present.

NOTE 2: The <on-network-max-participant-count> element indicates the maximum number of participants allowed in the group session. The <on-network-required> element is used to determine which group members need to acknowledge the group call before audio transmission can proceed.

NOTE 3: Other requirements for how the controlling MCVideo function selects which of the <on-network-max-participant-count> members to invite is outside the scope of this specification.

NOTE 4: It is assumed that validation checks are performed at the group management server to ensure that the <on-network-max-participant-count> cannot be less than the number of <on-network-required> users.

6.3.6 Affiliation check

The MCVideo server checks if an MCVideo user is affiliated to an MCVideo group at an MCVideo client by following the procedures specified below:

1. the MCVideo server shall find the applicable MCVideo group information entry as an MCVideo group information entry of the list of MCVideo group information entries described in clause 8.2.2.3.2, such that the MCVideo group ID of the MCVideo group information entry is equal to the MCVideo group identity of the MCVideo group. If the applicable MCVideo group information entry cannot be found, then the MCVideo server shall determine that the MCVideo user is not affiliated to the MCVideo group at the MCVideo client and the MCVideo server shall not continue with rest of the steps;

2. the MCVideo server shall find the applicable MCVideo user information entry as an MCVideo user information entry of the list of MCVideo user information entries of the applicable MCVideo group information entry, such that the MCVideo ID of the MCVideo user information entry is equal to the MCVideo ID of the MCVideo user. If the applicable MCVideo user information entry cannot be found, then the MCVideo server shall determine that the MCVideo user is not affiliated to the MCVideo group at the MCVideo client and the MCVideo server shall not continue with rest of the steps;

3. if the MCVideo client ID of the MCVideo client cannot be found in the list of MCVideo client information entries of the applicable MCVideo user information entry, then the MCVideo server shall determine that the MCVideo user is not affiliated to the MCVideo group at the MCVideo client and the MCVideo server shall not continue with rest of the steps;

NOTE: the MCVideo client ID of the originating MCVideo client can be found in the <mcvideo-client-id> element contained in the application/vnd.3gpp.mcvideo-info+xml MIME body of a SIP INVITE request, SIP REFER request or SIP MESSAGE request originated by the MCVideo client.

4. if the expiration time of the applicable MCVideo user information entry has been reached, then the MCVideo server shall determine that the MCVideo user is not affiliated to the MCVideo group at the MCVideo client and the MCVideo server shall not continue with rest of the steps; and

5. the MCVideo server shall determine that the MCVideo user is affiliated to the MCVideo group at the MCVideo client.

6.3.7 Error handling

6.3.7.1 Public service identity does not exist

Upon receiving a request that includes the Request-URI set to a public service identity that is not allocated in the participating or the controlling MCVideo function, the participating or the controlling MCVideo function shall return a SIP 404 (Not Found) response.

6.3.8 Session release policy

6.3.8.1 Session release policy for group call

If:

1) the call is a pre-arranged group call and if the controlling MCVideo function receives an indication from the media plane that the T4 (Inactivity) timer specified in 3GPP TS 24.581 [5] expired;

2) there are only one or no participants in the MCVideo session;

3) if the call is a pre-arranged group call and if it is according to local policy, the initiator of the group call leaves the MCVideo session;

4) the minimum number of affiliated MCVideo group members is not present; or

5) timer TNG3 (group call timer) expires;

the controlling MCVideo function shall release the MCVideo session for the group call.

6.3.8.2 Session release policy for private call

If:

1) the controlling MCVideo function receives an indication from the media plane that the T4 (Inactivity) timer specified in 3GPP TS 24.581 [5] expired;

2) the MCVideo session has lasted longer than the maximum of duration of private call; or

3) there are only one or no participants in the MCVideo session;

the controlling MCVideo function shall release the MCVideo session for a private call.