10.2 Private call in on-network

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

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

10.2.1 General

For on-network, the procedures for private call with transmission control are specified in clause 10.2.2.

For on-network, the procedures for private call without transmission control are specified in clause 10.2.3.

For on-network, the procedures for ending the private call initiated by MCVideo client are specified in clause 10.2.4.

For on-network, the procedures for ending the private call initiated by MCVideo server are specified in clause 10.2.5.

10.2.2 Private call with transmission control

10.2.2.1 General

Clause 10.2.2 specifies the MCVideo client procedures, participating MCVideo function procedures and controlling MCVideo function procedures for on-network private calls with transmission control. The procedures cover on-demand session establishment.

For a private call, the MCVideo client shall initiate the call to one MCVideo user

10.2.2.2 MCVideo client procedures

10.2.2.2.1 Client originating procedures

Upon receiving a request from an MCVideo user to establish an MCVideo private call the MCVideo client shall generate an initial SIP INVITE request by following the UE originating session procedures specified in 3GPP TS 24.229 [11], with the clarifications given below.

The MCVideo client:

1) shall set the Request-URI of the SIP INVITE request to a public service identity of the participating MCVideo function serving the MCVideo user;

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

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

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

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

7) for the establishment of a private call shall insert in the SIP INVITE request an application/resource-lists+xml MIME body with the MCVideo ID of the invited MCVideo user or the functional alias to be called 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, according to the rules and procedures of IETF RFC 5366 [37];

NOTE 1: The MCVideo client indicates whether an MCVideo ID or a functional alias is to be called as specified in step 11) c).

8) if an end-to-end security context needs to be established and if the MCVideo user is initiating a private call then:

a) if necessary, shall instruct the key management client to request keying material from the key management server as described in 3GPP TS 33.180 [8];

b) shall use the keying material to generate a PCK as described in 3GPP TS 33.180 [8];

c) shall use the PCK to generate a PCK-ID with the four most significant bits set to "0001" to indicate that the purpose of the PCK is to protect private call communications and with the remaining twenty eight bits being randomly generated as described in 3GPP TS 33.180 [8];

d) shall encrypt the PCK to a UID associated to the MCVideo client using the MCVideo ID and KMS URI of the invited user as determined by the procedures of clause 6.2.8.3.9 and a time related parameter as described in 3GPP TS 33.180 [8];

e) shall generate a MIKEY-SAKKE I_MESSAGE using the encapsulated PCK and PCK-ID as specified in 3GPP TS 33.180 [8];

g) shall add the MCVideo ID of the originating MCVideo to the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [8]; and

f) shall sign the MIKEY-SAKKE I_MESSAGE using the originating MCVideo user’s signing key provided in the keying material together with a time related parameter, and add this to the MIKEY-SAKKE payload, as described in 3GPP TS 33.180 [8];

9) shall include an SDP offer according to 3GPP TS 24.229 [11] with the clarification given in clause 6.2.1 and with a media stream of the offered media-transmission control entity;

10) if implicit transmission control is required, shall comply with the conditions specified in clause 6.4;

11) if the MCVideo user is initiating a private call then:

a) if force of automatic commencement mode at the invited MCVideo client is requested by the MCVideo user, shall include in the SIP INVITE request a Priv-Answer-Mode header field with the value "Auto" according to the rules and procedures of IETF RFC 5373 [27];

b) if force of automatic commencement mode at the invited MCVideo client is not requested by the MCVideo user and:

i) if automatic commencement mode at the invited MCVideo client is requested by the MCVideo user, shall include in the SIP INVITE request an Answer-Mode header field with the value "Auto" according to the rules and procedures of IETF RFC 5373 [27]; and

ii) if manual commencement mode at the invited MCVideo client is requested by the MCVideo user, shall include in the SIP INVITE request an Answer-Mode header field with the value "Manual" according to the rules and procedures of IETF RFC 5373 [27]; and

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

i) the <session-type> element set to a value of "private"; and

ii) an <anyExt> element containing:

A) the <call-to-functional-alias-ind> element set to "true" if the functional alias is used as a target of the call request;

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

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

C) if the MCVideo user has requested an application priority, the <user-requested-priority> element set to the user provided value;

12) if the MCVideo emergency private call state is set to either "MVEPC 2: emergency-pc-requested" or "MVEPC 3: emergency-pc-granted" or the MCVideo emergency private priority state for this private call is set to "MVEPP 2: in-progress", the MCVideo client shall comply with the procedures in clause 6.2.8.3.3; and

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

Upon receiving a SIP 183(Session Progress) response to the SIP INVITE request the MCVideo client:

1) may indicate the progress of the session establishment to the inviting MCVideo user.

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

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

2) if the MCVideo emergency private call state is set to "MVEPC 2: emergency-pc-requested" or "MVEPC 3: emergency-pc-granted", shall perform the actions specified in clause 6.2.8.3.4; and

3) shall notify the user that the call has been successfully established.

Upon receiving a SIP 300 (Multiple Choices) response to the SIP INVITE request the MCVideo client shall use the MCVideo ID of the MCVideo user contained in the <mcvideo-request-uri> element of the received application/vnd.3gpp.mcvideo-info MIME body as the MCVideo ID of the invited MCVideo user and shall generate an initial SIP INVITE request by following the UE originating session procedures specified in 3GPP TS 24.229 [11], with the clarifications given in this clause and with the following additional clarifications:

1) shall insert in the newly generated SIP INVITE request 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 in the application/resource-lists+xml MIME body, where the MCVideo ID is found in the <mcvideo-request-uri> element of the application/vnd.3gpp.mcvideo-info MIME body in the received SIP 300 (Multiple Choices) response;

2) shall not include a <call-to-functional-alias-ind> element into the <anyExt> element of the <mcvideo-Params> element of the <mcvideoinfo> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

3) shall include a <called-functional-alias-URI> element into the <anyExt> element of the <mcvideo-Params> element of the <mcvideoinfo> element of the application/vnd.3gpp.mcvideo-info+xml MIME body with the target functional alias URI used in the initial SIP INVITE request for establishing a private call.

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

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

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

the MCVideo client shall perform the actions specified in clause 6.2.8.3.5.

On receiving a SIP INFO request where the Request-URI contains an MCVideo session ID identifying an ongoing session, the MCVideo client shall follow the actions specified in clause 6.2.8.3.7.

10.2.2.2.2 Client terminating procedures

Upon receipt of an initial SIP INVITE request, the MCVideo client shall follow the procedures for termination of multimedia sessions in the IM CN subsystem as specified in 3GPP TS 24.229 [11] with the clarifications below.

The MCVideo client:

1) may reject the SIP INVITE request if any of the following conditions are met:

a) MCVideo client is already occupied in another session and the number of simultaneous sessions exceeds the value of the <Max-Simul-Call-Nc10> element of the <MCVideo-Private-Call> element of the <Common> element of the MCVideo UE profile document, the maximum simultaneous MCVideo session for private call, as specified in TS 24.484 [25];

b) MCVideo client does not have enough resources to handle the call; or

c) any other reason outside the scope of this specification;

otherwise, continue with the rest of the steps.

NOTE 1: If the SIP INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <emergency-ind> element set to a value of "true", the participating MCVideo function can choose to accept the request.

2) if the SIP INVITE request is rejected in step 1), shall respond toward participating MCVideo function either with appropriate reject code as specified in 3GPP TS 24.229 [11] and warning texts as specified in clause 4.4.2 or with SIP 480 (Temporarily unavailable) response not including warning texts if the user is authorised to restrict the reason for failure according to <allow-failure-restriction> as specified in 3GPP TS 24.484 [25] and skip the rest of the steps of this clause;

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

a) should display to the MCVideo user an indication that this is a SIP INVITE request for an MCVideo emergency private call and:

i) should display the MCVideo ID of the originator of the MCVideo emergency private call contained in the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

ii) if the <alert-ind> element is set to "true", should display to the MCVideo user an indication of the MCVideo emergency alert and associated information; and

b) shall set the MCVideo emergency private priority state to "MVEPP 2: in-progress" for this private call;

4) if the SDP offer of the SIP INVITE request contains an "a=key-mgmt" attribute field with a "mikey" attribute value containing a MIKEY-SAKKE I_MESSAGE:

a) shall extract the MCVideo ID of the originating MCVideo client from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [8];

b) shall convert the MCVideo ID to a UID as described in 3GPP TS 33.180 [8];

c) shall use the UID to validate the signature of the MIKEY-SAKKE I_MESSAGE as described in 3GPP TS 33.180 [8];

d) if authentication verification of the MIKEY-SAKKE I_MESSAGE fails, shall reject the SIP INVITE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [6], and include warning text set to "136 authentication of the MIKEY-SAKE I_MESSAGE failed" in a Warning header field as specified in clause 4.4; and

e) if the signature of the MIKEY-SAKKE I_MESSAGE was successfully validated:

i) shall extract and decrypt the encapsulated PCK using the terminating user’s (KMS provisioned) UID key as described in 3GPP TS 33.180 [8]; and

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

NOTE 2: With the PCK successfully shared between the originating MCVideo client and the terminating MCVideo client, both clients are able to use SRTP/SRTCP to create an end-to-end secure session.

5) may check if a Resource-Priority header field is included in the incoming SIP INVITE request and may perform further actions outside the scope of this specification to act upon an included Resource-Priority header field as specified in 3GPP TS 24.229 [11];

6) may display to the MCVideo user the MCVideo ID of the inviting MCVideo user;

6A) may display to the MCVideo user the functional alias of the inviting MCVideo user, if provided;

7) shall perform the automatic commencement procedures specified in clause 6.2.3.1.1 if one of the following conditions are met:

a) SIP INVITE request contains an Answer-Mode header field with the value "Auto" and the MCVideo service setting at the invited MCVideo client for answering the call is set to automatic commencement mode;

b) SIP INVITE request contains an Answer-Mode header field with the value "Auto" and the MCVideo service setting at the invited MCVideo client for answering the call is set to manual commencement mode, yet the invited MCVideo client is willing to answer the call with automatic commencement mode; or

c) SIP INVITE request contains a Priv-Answer-Mode header field with the value of "Auto"; and

8) shall perform the manual commencement procedures specified in clause 6.2.3.2.1 if either of the following conditions are met:

a) SIP INVITE request contains an Answer-Mode header field with the value "Manual" and the MCVideo service setting at the invited MCVideo client for answering the call is set to manual commencement mode;

b) SIP INVITE request contains an Answer-Mode header field with the value "Manual" and the MCVideo service setting at the invited MCVideo client for answering the call is set to automatic commencement mode, yet the invited MCVideo client allows the call to be answered with manual commencement mode; or

c) SIP INVITE request contains a Priv-Answer-Mode header field with the value of "Manual".

Upon receiving the SIP CANCEL request cancelling a SIP INVITE request for which a dialog exists at the MCVideo client and a SIP 200 (OK) response has not yet been sent to the SIP INVITE request then the MCVideo client:

1) shall send a SIP 200 (OK) response to the SIP CANCEL request according to 3GPP TS 24.229 [11]; and

2) shall send a SIP 487 (Request Terminated) response to the SIP INVITE request according to 3GPP TS 24.229 [11].

Upon receiving a SIP BYE request for an established dialog, the MCVideo client:

1) shall follow the procedures in clause 10.2.5.2.

10.2.2.2.3 Client terminating procedures for reception of SIP re-INVITE request

This clause covers on-demand session.

Upon receipt of a SIP re-INVITE request for an existing private call session, the MCVideo client shall:

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

a) should display to the MCVideo user an indication that this is a SIP re-INVITE request to upgrade this call to an MCVideo emergency private call and:

i) should display the MCVideo ID of the originator of the MCVideo emergency private call contained in the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

ii) if the <alert-ind> element is set to "true", should display to the MCVideo user an indication of the MCVideo emergency alert and associated information; and

b) shall set the MCVideo emergency private priority state to "MVEPP 2: in-progress" for this private call;

2) if the SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <emergency-ind> element set to a value of "false":

a) should display to the MCVideo user an indication that this is a SIP re-INVITE request to downgrade this emergency private call to a normal priority private call and:

i) should display the MCVideo ID of the sender of the SIP re-INVITE request contained in the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

ii) if the <alert-ind> element is set to "false" should display to the MCVideo user an indication that the MCVideo emergency alert is cancelled;

iii) if the SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body including an <originated-by> element:

A) should display to the MCVideo user the MCVideo ID contained in the <originated-by> element of the MCVideo user that originated the MCVideo emergency alert; and

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

b) shall set the MCVideo emergency private priority state to "MVEPP 1: no-emergency" for this private call; and

c) if the MCVideo emergency private call state of the call is set to "MVEPC 3: emergency-call-granted", shall set the MCVideo emergency private call state of the call to "MVEPC 1: emergency-pc-capable";

3) may check if a Resource-Priority header field is included in the incoming SIP INVITE request and may perform further actions outside the scope of this specification to act upon an included Resource-Priority header field as specified in 3GPP TS 24.229 [11];

4) may display to the MCVideo user the MCVideo ID of the inviting MCVideo user;

NOTE 1: As this is a re-INVITE for an existing MCVideo private call session, there is no attempt made to change the answer-mode from its current state.

4A) may display to the MCVideo user the functional alias of the inviting MCVideo user, if provided;

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

6) if the SIP re-INVITE request was received within an on-demand session, shall include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP INVITE request according to 3GPP TS 24.229 [11] with the clarifications given in clause 6.2.2;

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

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

10.2.2.2.4 MCVideo in-progress emergency cancel

This clause covers on-demand session.

Upon receiving a request from an MCVideo user to cancel the in-progress emergency condition on an MCVideo emergency private call, the MCVideo client shall generate a SIP re-INVITE request by following the UE session procedures specified in 3GPP TS 24.229 [11], with the clarifications given below.

The MCVideo client:

1) if the MCVideo user is not authorised to cancel the in-progress emergency condition on an MCVideo emergency private call as determined by the procedures of clause 6.2.8.3.1.2, the MCVideo client:

a) should indicate to the MCVideo user that they are not authorised to cancel the in-progress emergency condition on an MCVideo emergency private call; and

b) shall skip the remaining steps of the current clause;

2) shall, if the MCVideo user is cancelling an in-progress emergency condition and optionally an MCVideo emergency alert originated by the MCVideo user, include an application/vnd.3gpp.mcvideo-info+xml MIME body populated as specified in clause 6.2.8.3.6;

3) shall, if the MCVideo user is cancelling an in-progress emergency condition and optionally an MCVideo emergency alert originated by another MCVideo user, include an application/vnd.3gpp.mcvideo-info+xml MIME body populated as specified in clause 6.2.8.3.8;

4) shall include a Resource-Priority header field and comply with the procedures in clause 6.2.8.3.3;

5) shall include in the SIP re-INVITE request an SDP offer the media parameters as currently established;

NOTE 1: The SIP re-INVITE request can be sent within an on-demand session or a pre-established session associated with an MCVideo group session. If the SIP re-INVITE request is sent within a pre-established session, the media-level section for the offered MCVideo video media stream and the media-level section of the offered media-transmission control entity are expected to be the same as was negotiated in the existing pre-established session.

6) if an implicit transmission request is required, shall indicate this as specified in clause 6.4; and

7) shall send the SIP re-INVITE request according to 3GPP TS 24.229 [11].

On receiving a SIP 2xx response to the SIP re-INVITE request, the MCVideo client:

1) shall interact with the user plane as specified in 3GPP TS 24.380 [79];

2) shall set the MCVideo emergency private priority state of the MCVideo private call to "MVEPP 1: no-emergency";

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

4) if the MCVideo emergency alert state is set to "MVPEA 4: Emergency-alert-cancel-pending", the sent SIP re-INVITE request did not contain an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body and the SIP 2xx response to the SIP request for a priority group call does not contain a Warning header field as specified in clause 4.4 with the warning text containing the mcvideo-warn-code set to "149", shall set the MCVideo emergency alert state to "MVPEA 1: no-alert".

On receiving a SIP 4xx response, SIP 5xx response or SIP 6xx response to the SIP re-INVITE request:

1) if the SIP 4xx response, SIP 5xx response or SIP 6xx response contains an application/vnd.3gpp.mcvideo-info+xml MIME body with an <emergency-ind> element set to a value of "true", the MCVideo client shall set the MCVideo emergency private priority state as "MVEPP 2: in-progress";

2) if the SIP 4xx response, SIP 5xx response or SIP 6xx response contains an application/vnd.3gpp.mcvideo-info+xml MIME body with an <alert-ind> element set to a value of "true" and the sent SIP re-INVITE request did not contain an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body, the MCVideo client shall set the MCVideo emergency alert state to "MVPEA 3: emergency-alert-initiated"; and

3) if the SIP 4xx response, SIP 5xx response or SIP 6xx response did not contain an application/vnd.3gpp.mcvideo-info+xml MIME body, shall set the MCVideo emergency private priority state as "MVEPP 2: in-progress" and the MCVideo emergency alert (MPEA) state shall revert to its value prior to entering the current procedure.

NOTE 2: If the in-progress emergency private priority state cancel request is rejected, the state of the session does not change, i.e. continues with MCVideo emergency private call level priority.

On receiving a SIP INFO request where the Request-URI contains an MCVideo session ID identifying an ongoing group session, the MCVideo client shall follow the actions specified in clause 6.2.8.3.7.

10.2.2.2.5 Upgrade to MCVideo emergency private call

This clause covers both on-demand session and pre-established sessions.

Upon receiving a request from an MCVideo user to upgrade the ongoing MCVideo private call to an MCVideo emergency private call, the MCVideo client shall generate a SIP re-INVITE request as specified in 3GPP TS 24.229 [11], with the clarifications given below.

1) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body populated as specified in clause 6.2.8.3.2;

2) shall include a Resource-Priority header field and comply with the procedures in clause 6.2.8.3.3.

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

NOTE: The SIP re-INVITE request can be sent within an on-demand session or a pre-established session associated with an MCVideo private call. If the SIP re-INVITE request is sent within a pre-established session, the media-level section for the offered MCVideo video media stream and the media-level section of the offered media-transmission control entity are expected to be the same as was negotiated in the existing pre-established session.

4) if an implicit transmission request is required, shall indicate this as specified in clause 6.4; and

5) shall send the SIP re-INVITE request according to 3GPP TS 24.229 [11].

On receiving a SIP 2xx response to the SIP re-INVITE request the MCVideo client:

1) shall interact with the user plane as specified in 3GPP TS 24.380 [79]; and

2) shall perform the actions specified in clause 6.2.8.3.4.

On receiving a SIP 4xx response, SIP 5xx response or SIP 6xx response to the SIP re-INVITE request, the MCVideo client shall perform the actions specified in clause 6.2.8.3.5.

On receiving a SIP INFO request where the Request-URI contains an MCVideo session ID identifying an ongoing group session, the MCVideo client shall follow the actions specified in clause 6.2.8.3.7

10.2.2.3 Participating MCVideo function procedures

10.2.2.3.1 Originating procedures

10.2.2.3.1.1 On-demand private call

Upon receipt of a "SIP INVITE request for originating participating MCVideo function" containing an application/vnd.3gpp.mcvideo-info+xml MIME body with the <session-type> element set to a value of "private", the participating MCVideo function:

1) may reject the SIP INVITE request depending on the value of the Resource-Priority header field if the Resource-Priority header field is included in the received SIP INVITE request according to the rules and procedures specified in IETF RFC 4412 [33] and shall not continue with the rest of the steps;

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

NOTE 1: If the received SIP INVITE request contains an emergency indication set to a value of "true", the participating MCVideo function can choose to accept the request.

NOTE 2: If the received SIP INVITE request contains an emergency indication set to a value of "true", the participating MCVideo function can choose to allow an exception to the limit on the number of private calls and accept the request.

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

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

4) if the participating MCVideo function cannot find a binding between the public user identity and an MCVideo ID or if the validity period of an existing binding has expired, then the participating MCVideo function shall reject the SIP INVITE request with a SIP 404 (Not Found) response with the warning text set to "141 user unknown to the participating function" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;

5) shall:

a) if the <session-type> is set to "private", determine that the call is a private call;

6) if the call is a:

a) private call, determine the public service identity of the controlling MCVideo function for the private call service associated with the originating user’s MCVideo ID identity;

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

NOTE 5: 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 6: 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 7: How the participating MCVideo function determines the public service identity of the controlling MCVideo function for the private call service or first-to-answer call service associated with the originating user or of the MCVideo gateway server in the interconnected MCVideo system is out of the scope of the present document.

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

7) if the participating MCVideo function is unable to identify the controlling MCVideo function for the private call service, 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;

8) if the incoming SIP INVITE request does not contain an application/resource-lists+xml MIME body, shall reject the "SIP INVITE request for originating participating MCVideo function" with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

9) if the call is a private call and the incoming SIP INVITE request contains an application/resource-lists+xml MIME body with a total of more than one <entry> element in the <list> elements in the <resource-lists> element, shall reject the "SIP INVITE request for originating participating MCVideo function" with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

10) if the <allow-private-call> element of the <ruleset> element is not present in the MCVideo user profile document on the participating MCVideo function or is present with the value "false" (see the MCVideo user profile document in 3GPP TS 24.484 [25]), indicating that the user identified by the MCVideo ID is not authorised to initiate private calls, shall reject the "SIP INVITE request for originating participating MCVideo function" with a SIP 403 (Forbidden) response, with warning text set to "107 user not authorised to make private calls" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

11) if the call is a private call and:

a) if the received SIP INVITE request includes an Answer-Mode header field as specified in IETF RFC 5373 [27] with the value "Auto" and the <allow-automatic-commencement> element of the <ruleset> element is not present in the MCVideo user profile document on the participating MCVideo function or is present with the value "false" (see the MCVideo user profile document in 3GPP TS 24.484 [25]) indicating that the user identified by the MCVideo ID is not authorised to initiate private call with automatic commencement, shall reject the "SIP INVITE request for originating participating MCVideo function" with a SIP 403 (Forbidden) response including warning text set to "125 user not authorised to make private call with automatic commencement" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

b) if the received SIP INVITE request includes an Answer-Mode header field as specified in IETF RFC 5373 [27] with the value "Manual" and the <allow-manual-commencement> element of the <ruleset> element is not present in the MCVideo user profile document on the participating MCVideo function or is present with the value "false" (see the MCVideo user profile document in 3GPP TS 24.484 [25]), indicating that the user identified by the MCVideo ID is not authorised to initiate private call with manual commencement, shall reject the "SIP INVITE request for originating participating MCVideo function" with a SIP 403 (Forbidden) response including warning text set to "126 user not authorised to make private call with manual commencement" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

c) if the <PrivateCall> element exists in the MCVideo user profile document with one more <entry> elements (see the MCVideo user profile document in 3GPP TS 24.484 [25]) and:

i) if the "uri" attribute of the <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body does not match with one of the <entry> elements of the <PrivateCall> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]); and

ii) if configuration is not set in the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) that allows the MCVideo user to make a private call to users not contained within the <entry> elements of the <PrivateCall> element;

then:

i) shall reject the "SIP INVITE request for originating participating MCVideo function" with a SIP 403 (Forbidden) response including warning text set to "144 user not authorised to call this particular user" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

11A) if the call is a first-to-answer call or a private call, the received SIP INVITE request contains the application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element containing the <anyExt> element with the <call-to-functional-alias-ind> element set to "true" and a <functional-alias-URI> element, and the <ListOfAllowedFAsToCall> element exists with one or more <entry> elements within the entry of the FunctionalAliasList element corresponding to the calling <functional-alias-URI> element in the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) and:

a) if the "uri" attribute of the <entry> element of a <list> element of the <resource-lists> of the application/resource-lists+xml MIME body does not match with any of the <entry> elements of the <ListOfAllowedFAsToCall> element of the entry within the FunctionalAliasList element corresponding to the calling <functional-alias-URI> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]);

then:

a) shall reject the "SIP INVITE request for originating participating MCVideo function" with a SIP 403 (Forbidden) response including warning text set to "171 functional alias not allowed to call this particular functional alias" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

12) shall validate the media parameters and if the MCVideo video media codec is not offered in the "SIP INVITE request for originating participating MCVideo function" shall reject the request with a SIP 488 (Not Acceptable Here) response. Otherwise, continue with the rest of the steps;

13) shall generate a SIP INVITE request as specified in clause 6.3.2.1.3 with the following clarifications:

a) if the conditions in step 12) above were executed and the participating MCVideo function determined that the "uri" attribute of only one of the <entry> elements a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body matched with an <entry> element of the <PrivateCall> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) then the <session-type> in the application/vnd.3gpp.mcvideo-info+xml MIME body of the SIP INVITE request generated in clause 6.3.2.1.3 is set to "private"; and

b) if the conditions in step 12) above were executed, then only the <entry> element(s) of the <list> elements of the <resource-lists> element of the application/resource-lists+xml MIME body that have a "uri" attribute that matched with an <entry> elements of the <PrivateCall> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) are included in the application/resource-lists+xml MIME body in the SIP INVITE request generated in clause 6.3.2.1.3;

14) shall set the Request-URI to the public service identity of the controlling MCVideo function hosting the private call service as determined by step 6);

15) shall set the <mcvideo-calling-user-id> element in an application/vnd.3gpp.mcvideo-info+xml MIME body of the SIP INVITE request to the MCVideo ID of the calling user;

16) if the call is a private call and:

a) if a Priv-Answer-Mode header field specified in IETF RFC 5373 [27] was received in the incoming SIP INVITE request with a value of "Manual", shall not include a Priv-Answer-Mode header field in the outgoing SIP INVITE request;

b) if the <allow-force-auto-answer> element of the <ruleset> element is not present in the MCVideo user profile document on the participating MCVideo function or is present with the value "false" (see the MCVideo user profile document in 3GPP TS 24.484 [25]), and the Priv-Answer-Mode header field specified in IETF RFC 5373 [27] was received in the incoming SIP INVITE request with a value of "Auto", shall reject the "SIP INVITE request for originating participating MCVideo function" with a SIP 403 (Forbidden) response including warning text set to "143 not authorised to force auto answer" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

c) if the <allow-force-auto-answer> element of the <ruleset> element is present in the MCVideo user profile document with the value "true" (see the MCVideo user profile document in 3GPP TS 24.484 [25]) on the participating MCVideo function, and the Priv-Answer-Mode header field specified in IETF RFC 5373 [27] was received in the incoming SIP INVITE request with a value of "Auto", shall include the Priv-Answer-Mode header field set to a value of "Auto" in the outgoing SIP INVITE request;

d) if a Priv-Answer-Mode header field containing the value of "Auto" has not been included in the outgoing SIP INVITE request as specified in step 17) above and the incoming "SIP INVITE request for originating participating MCVideo function" contained an Answer-Mode header field as specified in IETF RFC 5373 [27], then shall populate the Answer-Mode header field of the outgoing SIP INVITE request with the contents of the Answer-Mode header field from the incoming "SIP INVITE request for originating participating MCVideo function";

17) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received "SIP INVITE request for originating participating MCVideo function", as specified in clause 6.3.2.1.1.1;

17a) if the received SIP INVITE request contains a <functional-alias-URI> element of the <anyExt> element of the <mcvideo-Params> element of the <mcvideoinfo> element of the application/vnd.3gpp.mcvideo-info+xml MIME body, then shall check if the status of the functional alias is activated for the MCVideo ID. If the functional alias status is activated, then the participating MCVideo function shall set the <functional-alias-URI> element of the <anyExt> element of the <mcvideo-Params> element of the <mcvideoinfo> element of the application/vnd.3gpp.mcvideo-info+xml MIME body in the outgoing SIP INVITE request to the received value, otherwise shall not include a <functional-alias-URI> element;

NOTE 9: The participating MCVideo server learns the functional alias state for an MCVideo ID from procedures specified in clause 20.2.2.2.7.

18) shall include a Resource-Priority header field according to the rules and procedures of 3GPP TS 24.229 [11] set to the value indicated in the Resource-Priority header field if included in the SIP INVITE request from the MCVideo client; and

19) shall forward the SIP INVITE request, according to 3GPP TS 24.229 [11].

Upon receiving a SIP 180 (Ringing) response, the participating MCVideo function:

1) shall generate a SIP 180 (Ringing) response to the SIP INVITE request as specified in the clause 6.3.2.1.5.1;

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

3) shall include Warning header field(s) received in the incoming SIP 180 (Ringing) response; and

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

Upon receiving a SIP 200 (OK) response, the participating MCVideo function:

1) shall generate a SIP 200 (OK) response as specified in the clause 6.3.2.1.5.2;

2) shall include in the SIP 200 (OK) response an SDP answer as specified in the clause 6.3.2.1.2.1;

3) shall include Warning header field(s) received in the incoming SIP 200 (OK) response;

4) shall include the P-Asserted-Identity header field received in the incoming SIP 200 (OK) response into the outgoing SIP 200 (OK) response;

5) shall include an MCVideo session identity mapped to the MCVideo session identity provided in the Contact header field of the received SIP 200 (OK) response;

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

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

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

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

10.2.2.3.1.2 Private call initiation using pre-established session

Upon receipt of a "SIP REFER request for a pre-established session", with:

1) the Refer-To header field containing a Content-ID ("cid") Uniform Resource Locator (URL) as specified in IETF RFC 2392 [49] that points to an application/resource-lists+xml MIME body as specified in IETF RFC 5366 [37] containing one or more <entry> element(s) in one or more <list> elements in the <resource-lists> elment, where the <entry> elements contain a "uri" attribute containing a SIP URI set to the MCVideo ID of the called user(s);

2) an hname "body" parameter in the headers portion of the SIP URI specified above containing an application/vnd.3gpp.mcvideo-info MIME body with the <session-type> element set to "private"; and

3) a Content-ID header field set to the "cid" URL;

the participating function:

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

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

3) if the participating MCVideo function cannot find a binding between the public user identity and an MCVideo ID or if the validity period of an existing binding has expired, then the participating MCVideo function shall reject the SIP REFER request with a SIP 404 (Not Found) response with the warning text set to "141 user unknown to the participating function" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;

4) if the received SIP REFER request does not contain an application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field, shall reject the "SIP REFER request for pre-established session" with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

5) if the received SIP REFER request contains an application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field with more than one <entry> element in one or more<list> elements in the <resource-lists> element where these <entry> elements each contain an application/vnd.3gpp.mcvideo-info MIME body with the <session-type> element:

a) set to "private", shall reject the "SIP REFER request for pre-established session" with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;

6) if the received SIP REFER request contains an application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field with only one <entry> element in a <list> element in the <resource-lists> element containing an application/vnd.3gpp.mcvideo-info MIME body with the <session-type> element:

a) not set to "private", shall reject the "SIP REFER request for pre-established session" with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps; or

b) set to "private", determine that the call is a private call;

7) if the call is a:

a) private call, shall determine the public service identity of the controlling MCVideo function for the private call service associated with the originating user’s MCVideo ID; or

NOTE 1: The public service identity can identify the controlling 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 participating MCVideo function determines the public service identity of the controlling MCVideo function for the private call service or first-to-answer call service associated with the originating 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.

8) if the participating MCVideo function is unable to identify the controlling MCVideo function for the private call service associated with the originating user’s MCVideo ID, it shall reject the REFER 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;

9) if the <allow-private-call> element of the <ruleset> element is not present in the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) on the participating MCVideo function or is present with the value "false", indicating that the user identified by the MCVideo ID is not authorised to initiate private calls, shall reject the "SIP REFER request for pre-established session" with a SIP 403 (Forbidden) response to the SIP INVITE request, with warning text set to "107 user not authorised to make private calls" in a Warning header field as specified in clause 4.4;

10) if the call is a private call:

a) if the received SIP REFER request includes an Answer-Mode header field as specified in IETF RFC 5373 [27] set to "Auto" contained in the header portion of the SIP URI present in the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field, and the <allow-automatic-commencement> element of the <ruleset> element is not present in the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) on the participating MCVideo function or is present with the value "false" (indicating that the user identified by the MCVideo ID is not authorised to initiate a private call with automatic commencement), shall reject the "SIP REFER request for pre-established session" with a SIP 403 (Forbidden) response including warning text set to "125 user not authorised to make private call with automatic commencement" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

b) if the received SIP REFER request includes an Answer-Mode header field as specified in IETF RFC 5373 [27] set to "Manual" contained in the header portion of the SIP URI present in the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field, and the <allow-manual-commencement> element of the <ruleset> element is not present in the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) on the participating MCVideo function or is present with the value "false" (indicating that the user identified by the MCVideo ID is not authorised to initiate private call with manual commencement), shall reject the "SIP REFER request for pre-established session" with a SIP 403 (Forbidden) response including warning text set to "126 user not authorised to make private call with manual commencement" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

c) if the <allow-force-auto-answer> element of the <ruleset> element is not present in the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) on the participating MCVideo function or is present with the value "false", and the SIP REFER request contained a Priv-Answer-Mode header field as specified in IETF RFC 5373 [27] set to "Auto" in the header portion of the SIP URI in the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field, shall reject the "SIP INVITE request for originating participating MCVideo function" with a SIP 403 (Forbidden) response including warning text set to "143 not authorised to force auto answer" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

d) if the <PrivateCall> element exists in the MCVideo user profile document with one more <entry> elements (see the MCVideo user profile document in 3GPP TS 24.484 [25]) and:

i) if the SIP URI in the "uri" attribute of an <entry> element in a <list> element in the <resource-lists> element of the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field not match with one of the <entry> elements of the <PrivateCall> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]); and

then:

10A) if the call is a first-to-answer call or a private call, the received SIP REFER request contains the application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element containing the <anyExt> element with the <call-to-functional-alias-ind> element set to "true" and a <functional-alias-URI> element, the <ListOfAllowedFAsToCall> element exists with one or more <entry> elements within the entry of the FunctionalAliasList element corresponding to the calling <functional-alias-URI> element in the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) and:

a) if the "uri" attribute of the <entry> element in a <list> element in the <resource-lists> element of the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field does not match with any of the <entry> elements of the <ListOfAllowedFAsToCall> element of the entry within the FunctionalAliasList element corresponding to the calling <functional-alias-URI> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]);

then:

a) shall reject the "SIP REFER request for originating participating MCVideo function" with a SIP 403 (Forbidden) response including warning text set to "171 functional alias not allowed to call this particular functional alias" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

11) if the "SIP REFER request for a pre-established session" contained a Refer-Sub header field containing "false" value and a Supported header field containing "norefersub" value, shall handle the SIP REFER request as specified in 3GPP TS 24.229 [11], IETF RFC 3515 [64] as updated by IETF RFC 6665 [16], and IETF RFC 4488 [31] without establishing an implicit subscription;

12) shall generate a final SIP 200 (OK) response to the "SIP REFER request for a pre-established session" according to 3GPP TS 24.229 [11];

NOTE 6: In accordance with IETF RFC 4488 [31], the participating MCVideo function inserts the Refer-Sub header field containing the value "false" in the SIP 200 (OK) response to the SIP REFER request to indicate that it has not created an implicit subscription.

13) shall send the response to the "SIP REFER request for a pre-established session" towards the MCVideo client according to 3GPP TS 24.229 [11];

14) shall generate a SIP INVITE request as specified in clause 6.3.2.1.4 with the following clarifications:

a) if the conditions in step 11) above were executed and the participating MCVideo function determined that the "uri" attribute of only one of the <entry> elements in the <lists> elements in the <resource-lists> element of the application/resource-lists+xml MIME body matched with an <entry> element of the <PrivateCall> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) then the <session-type> in the application/vnd.3gpp.mcvideo-info+xml MIME body of the SIP INVITE request generated in clause 6.3.2.1.4 is set to "private"; and

b) if the conditions in step 11) above were executed, then only the <entry> element(s) in the <list> elements in the <resource-lists> element of the application/resource-lists+xml MIME body that have a "uri" attribute that matched with an <entry> element of the <PrivateCall> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) are included in the application/resource-lists+xml MIME body in the SIP INVITE request generated in clause 6.3.2.1.3;

15) shall set the Request-URI of the SIP INVITE request to the public service identity of the controlling MCVideo function hosting the private call service for the calling MCVideo user as determined above in step 7);

16) if the call is a private call:

a) if the SIP REFER request contained a Priv-Answer-Mode header field as specified in IETF RFC 5373 [27] set to "Manual" in the header portion of the SIP URI in the "uri" attribute of a <list> element in the <resource-lists> element in the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field, shall copy the Priv-Answer-Mode header field from the incoming SIP REFER request to the outgoing SIP INVITE request;

b) if the <allow-force-auto-answer> element of the <ruleset> element is present in the MCVideo user profile document with the value "true" (see the MCVideo user profile document in 3GPP TS 24.484 [25]) on the participating MCVideo function, and the Priv-Answer-Mode header field specified in IETF RFC 5373 [27] was received in the header portion of the SIP URI in the "uri" attribute of a <list> element in the <resource-lists> element in the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field, with a value set to "Auto", shall copy the Priv-Answer-Mode header field to the outgoing SIP INVITE request; and

c) if a Priv-Answer-Mode header field containing the value of "Auto" has not been copied to the outgoing SIP INVITE request as specified in step 16) above, and the incoming SIP REFER request contained an Answer-Mode header field in the headers portion of the SIP URI in the "uri" attribute of a <list> element in the <resource-lists> element in the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field, then copy the Answer-Mode header field to the outgoing SIP INVITE request;

17) if the received SIP REFER request contained a Resource-Priority header field, shall include in the outgoing SIP INVITE request a Resource-Priority header field according to the rules and procedures of 3GPP TS 24.229 [11] set to the value indicated in the Resource-Priority header field of the received SIP REFER request;

17a) if the call is a private call and if the received SIP REFER request contains a <functional-alias-URI> element of the <anyExt> element of the <mcvideo-Params> element of the <mcvideoinfo> element of the application/vnd.3gpp.mcvideo-info+xml MIME body, then shall check if the status of the functional alias is activated for the MCVideo ID. If the functional alias status is activated, then the participating MCVideo function shall set the <functional-alias-URI> element of the <anyExt> element of the <mcvideo-Params> element of the <mcvideoinfo> element of the application/vnd.3gpp.mcvideo-info+xml MIME body in the outgoing SIP INVITE request to the received value, otherwise shall not include a <functional-alias-URI> element; and

NOTE 7: The participating MCVideo function will leave verification of the Resource-Priority header field to the controlling MCVideo function.

18) shall forward the SIP INVITE request according to 3GPP TS 24.229 [11].

Upon receiving SIP provisional responses for the SIP INVITE request the participating MCVideo function:

1) shall discard the received SIP responses without forwarding them.

Upon receiving a SIP 200 (OK) response for the SIP INVITE request the participating MCVideo function:

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

Upon receipt of a SIP 4xx, 5xx or 6xx response to the above SIP INVITE request the participating MCVideo function:

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

10.2.2.3.1.3 Receipt of SIP re-INVITE for MCVideo private call from the served user

This clause covers both on-demand session and pre-established sessions.

Upon receipt of a SIP re-INVITE request for an existing MCVideo private call session the participating MCVideo function:

1) may reject the SIP re-INVITE request depending on the value of the Resource-Priority header field if the Resource-Priority header field is included in the received SIP re-INVITE request according to rules and procedures specified in IETF RFC 4412 [33] and skip the rest of the steps;

NOTE 1: If the SIP re-INVITE request contains an emergency indication, the participating MCVideo function can choose to accept the request.

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

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

4) shall validate the media parameters and if the MCVideo video media codec is not offered in the SIP re-INVITE request shall reject the request with a SIP 488 (Not Acceptable Here) response and skip the rest of the steps;

NOTE 3: If the received SIP re-INVITE request is received within a pre-established session, associated with an MCVideo private call, the media-level section for the offered MCVideo video media stream and the media-level section of the offered media-transmission control entity are expected to be the same as was negotiated in the existing pre-established session.

5) shall generate a SIP re-INVITE request as specified in clause 6.3.2.1.9;

6) shall set the <mcvideo-calling-user-id> element in an application/vnd.3gpp.mcvideo-info+xml MIME body of the SIP re-INVITE request to the MCVideo ID of the calling user;

7) shall, if the SIP re-INVITE request was received within an on-demand session include in the SIP re-INVITE request an SDP containing the current media parameters used by the existing session;

8) shall, if the SIP re-INVITE request was received within a pre-established session, include in the SIP re-INVITE request an SDP offer based upon the previously negotiated SDP for the pre-established session as specified in clause 6.3.2.1.1.2;

9) shall include a Resource-Priority header field according to rules and procedures of 3GPP TS 24.229 [11] set to the value indicated in the Resource-Priority header field if included in the SIP re-INVITE request from the MCVideo client; and

10) shall forward the SIP re-INVITE request, according to 3GPP TS 24.229 [11].

Upon receiving a SIP 200 (OK) response, the participating MCVideo function:

1) shall generate a SIP 200 (OK) response as specified in the clause 6.3.2.1.5.2;

2) if the SIP 200 (OK) response is to be sent within an on-demand session shall include in the SIP 200 (OK) response an SDP answer as specified in the clause 6.3.2.1.2.1;

3) if the SIP 200 (OK) response is to be sent within a pre-established session shall include in the SIP 200 (OK) response an SDP answer based upon the previously negotiated SDP for the pre-established session;

4) shall include Warning header field(s) received in the incoming SIP 200 (OK) response;

5) shall include the P-Asserted-Identity header field received in the incoming SIP 200 (OK) response into the outgoing SIP 200 (OK) response;

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

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

10.2.2.3.2 Terminating procedures

This clause covers both on demand session and pre-established session.

Upon receipt of a "SIP INVITE request for terminating participating MCVideo function", the participating MCVideo function:

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

2) shall check the presence of the isfocus media feature tag in the URI of the Contact header field and if it is not present then the participating MCVideo function shall reject the request with a SIP 403 (Forbidden) response with the warning text set to "104 isfocus not assigned" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

3) if the <session-type> element of the application/vnd.3gpp.mcvideo-info+xml MIME body is set to "private" and the Answer-Mode Indication in the application/poc-settings+xml MIME body has not yet been received from the invited MCVideo client as defined in clause 7.3.3 or clause 7.3.4, shall reject the request with a SIP 480 (Temporarily Unavailable) response with the warning text set to "146 T-PF unable to determine the service settings for the called user" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

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

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

6) when the called user identified by the MCVideo ID is unable to participate in private calls as identified in the called user’s MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) on the terminating participating MCVideo function, shall reject the "SIP INVITE request for terminating participating MCVideo function" with a SIP 403 (Forbidden) response including warning text set to "127 user not authorised to be called in private call" in a Warning header field as specified in clause 4.4;

6A) if the <session-type> element of the application/vnd.3gpp.mcvideo-info+xml MIME body is set to "private" and if the <IncomingPrivateCallList> element exists in the MCVideo user profile document with one or more <entry> elements (see the MCVideo user profile document in 3GPP TS 24.484 [25]) and:

i) if the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the incoming SIP INVITE request does not match with one of the <entry> elements of the <IncomingPrivateCallList> element of the MCVideo user profile document; and

ii) if configuration is not set in the MCVideo user profile document that allows the MCVideo user to receive a private call by users not contained within the <entry> elements of the <IncomingPrivateCallList> element (see <allow-to-receive-private-call-from-any-user> element in MCVideo user profile document in 3GPP TS 24.484 [25]);

then:

i) shall reject the "SIP INVITE request for terminating participating MCVideo function" with a SIP 403 (Forbidden) response including warning text set to "159 user not authorised to be called by this originating user" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

6B) if the call is a first-to-answer call or a private call, the received SIP INVITE request contains the application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element containing the <anyExt> element with the <call-to-functional-alias-ind> element set to "true" and a <functional-alias-URI> element, the <ListOfAllowedFAsToBeCalledFrom> element exists in the MCVideo user profile document with one or more <entry> elements (see the MCVideo user profile document in 3GPP TS 24.484 [25]) and:

a) if the <called-functional-alias-URI> element of the <anyExt> element of the <mcvideo-Params> element of the <mcvideoinfo> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the incoming SIP INVITE request does not match with any of the <entry> elements of the <ListOfAllowedFAsToBeCalledFrom> element of the entry within the FunctionalAliasList element corresponding to the called functional alias of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]); and

then:

a) shall reject the "SIP INVITE request for originating participating MCVideo function" with a SIP 403 (Forbidden) response including warning text set to "172 functional alias not allowed to be called from this functional alias" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

7) shall perform the automatic commencement procedures specified in clause 6.3.2.2.5.1 and according to IETF RFC 5373 [27] if one of the following conditions are met:

a) "SIP INVITE request for terminating participating MCVideo function" contains an Answer-Mode header field with the value "Auto";

b) "SIP INVITE request for terminating participating MCVideo function" does not contain an Answer-Mode header field and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCVideo client as per clause 7.3.3 or clause 7.3.4 is set to "auto-answer"; or

c) "SIP INVITE request for terminating participating MCVideo function" contains a Priv-Answer-Mode header field with the value "Auto"; and

8) shall perform the manual commencement procedures specified in clause 6.3.2.2.6.1 and according to IETF RFC 5373 [27] if either of the following conditions are met:

a) "SIP INVITE request for terminating participating MCVideo function" contains an Answer-Mode header field with the value "Manual";

b) "SIP INVITE request for terminating participating MCVideo function" does not contain an Answer-Mode header field and Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCVideo client as per clause 7.3.3 or clause 7.3.4 is set to "manual-answer"; or

c) "SIP INVITE request for terminating participating MCVideo function" contains a Priv-Answer-Mode header field with the value "Manual".

10.2.2.3.3 Receipt of SIP re-INVITE request by terminating participating function

This clause covers the on-demand session case only.

Upon receipt of a SIP re-INVITE request for an existing MCVideo private call session the participating MCVideo function:

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

NOTE 1: If the SIP re-INVITE request contains an emergency indication, the participating MCVideo function can choose to accept the request.

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

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

4) shall generate a SIP re-INVITE as specified in clause 6.3.2.2.10;

NOTE 2: As this is the modification of an in-progress MCVideo private call, this procedure does not attempt modification of the existing answer-mode of the call.

5) shall include in the SIP re-INVITE request an SDP offer containing the current media parameters used by the existing session; and

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

Upon receiving the SIP 200 (OK) response to the SIP re-INVITE request, 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].

10.2.2.4 Controlling MCVideo function procedures

10.2.2.4.1 Originating procedures

This clause describes the procedures for inviting an MCVideo user to an MCVideo session. The procedure is initiated by the controlling MCVideo function as the result of an action in clause 10.2.2.4.2

The controlling MCVideo function:

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

NOTE 1: As a result of calling clause 6.3.3.1.2, the <mcvideo-calling-user-id> containing the calling user’s MCVideo ID is copied into the outgoing SIP INVITE.

2) if the received SIP INVITE request contains an authorised request for an MCVideo emergency private call as determined by clause 6.3.3.1.13.2:

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

b) if the received SIP INVITE request contains an alert indication set to a value of "true" and this is an authorised request for an MCVideo emergency alert meeting the conditions specified in clause 6.3.3.1.13.1, perform the procedures specified in clause 6.3.3.1.12; and

c) if the received SIP INVITE request did not contain an alert indication or contains an alert indication set to a value of "true" and is not an authorised request for an MCVideo emergency alert meeting the conditions specified in clause 6.3.3.1.13.1, shall set the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to a value of "false";

3) shall copy the MCVideo ID of the MCVideo user listed in the MIME resources body of the incoming SIP INVITE request, into the <mcvideo-request-uri> element in the application/vnd.3gpp.mcvideo-info+xml MIME body of the outgoing SIP INVITE request;

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

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

NOTE 3: 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 4: 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 5: How the controlling MCVideo function determines the public service identity of the terminating participating MCVideo function for the private call service or first-to-answer call service associated with the originating user or of the MCVideo gateway server in the interconnected MCVideo system is out of the scope of the present document.

NOTE 6: 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 copy the public user identity of the calling MCVideo user from the P-Asserted-Identity header field of the incoming SIP INVITE request into the P-Asserted-Identity header field of the SIP INVITE request;

6) shall include a Resource-Priority header field populated with the values for an MCVideo emergency private call as specified in clause 6.3.3.1.19, if either of the following conditions is met:

a) if the received SIP INVITE request contains an authorised request for an MCVideo emergency private call as determined in step 2 above; or

b) the originating MCVideo user is in an in-progress emergency private call state with the targeted MCVideo user;

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

8) shall send the SIP INVITE request towards the core network according to 3GPP TS 24.229 [11]; and

9) shall start a private call timer with a value set to the configured max private call duration for the user.

Upon receiving SIP 200 (OK) response for the SIP INVITE request the controlling MCVideo function:

1) shall cache the contact received in the Contact header field; and

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

Upon expiry of the private call timer, the controlling MCVideo function shall follow the procedure for releasing private call session as specified in clause 10.2.5.4.

10.2.2.4.2 Terminating procedures

In the procedures in this clause:

1) <emergency–ind> refers to the <emergency-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body;

2) <alert–ind> refers to the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

3) <session-type> refers to the <session-type> element of an application/vnd.3gpp.mcvideo-info+xml MIME body.

Upon receipt of:

– a "SIP INVITE request for controlling MCVideo function of a private call"; or

the controlling MCVideo function:

1) if the <session-type> in the SIP INVITE request is set to "private":

a) shall check whether the public service identity contained in the Request-URI is allocated for private call and perform the actions specified in clause 6.3.7.1 if it is not allocated and skip the rest of the steps; and

b) shall perform actions to verify the MCVideo ID of the inviting MCVideo user in the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the SIP INVITE request, and authorise the request according to local policy, and if it is not authorised the controlling MCVideo function shall return a SIP 403 (Forbidden) response with the warning text as specified in "Warning header field" and skip the rest of the steps;

2) if the incoming SIP INVITE request does not contain an application/resource-lists+xml MIME body shall reject the SIP INVITE request with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

3) if the <session-type> is set to "private" and the application/resource-lists+xml MIME body contains more than one <entry> element in one or more <list> elements in the <resource-lists>element, shall reject the "SIP INVITE request for originating participating MCVideo function" with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

4) shall validate that the received SDP offer includes at least one media stream for which the media parameters and at least one codec or media format is acceptable by the controlling MCVideo function and if not, reject the request with a SIP 488 (Not Acceptable Here) response and skip the rest of the steps;

5) if received SIP INVITE request includes an <emergency-ind>, shall validate the request as described in clause 6.3.3.1.17;

6) if the received SIP INVITE request contains an unauthorised request for an MCVideo emergency private call as determined by clause 6.3.3.1.13.2:

a) shall reject the SIP INVITE request with a SIP 403 (Forbidden) response as specified in clause 6.3.3.1.14; and

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

7) if a Resource-Priority header field is included in the received SIP INVITE request and if the Resource-Priority header field is set to the value indicated for emergency calls, shall reject the SIP INVITE request with a SIP 403 (Forbidden) response and skip the remaining steps if neither one of the following conditions are true:

a) the SIP INVITE request does not contain an authorised request for an MCVideo emergency call as determined in step 4 above; or

b) the originating MCVideo user is not in an in-progress emergency private call state with the targeted MCVideo user;

7a) if the <session-type> in the received SIP INVITE request is set to "private" and if the SIP INVITE request contained an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element containing the <anyExt> element with the <call-to-functional-alias-ind> element set to a value of "true":

a) shall identify the MCVideo ID(s) of the MCVideo user(s) that have activated the received called functional alias in the application/resource-lists+xml MIME body of the SIP INVITE request by performing the actions specified in clause 20.2.2.2.8;

b) if unable to determine any MCVideo ID that has activated the received called functional alias in the "uri" attribute of an <entry> element in a <list> element in the <resource-lists> element in the application/resource-lists+xml MIME body of the SIP INVITE request, shall reject the "SIP INVITE request for controlling MCVideo function of a private call" with a SIP 403 (Forbidden) response including a warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps; and

c) selects one of the identified MCVideo IDs, and shall send a SIP 300 (Multiple Choices) response to the "SIP INVITE request for controlling MCVideo function of a private call" populated according to 3GPP TS 24.229 [11], IETF RFC 3261 [15] with:

A) a Contact header field containing a SIP URI for the MCVideo session identity; and

B) an application/vnd.3gpp.mcvideo-info MIME body with an <mcvideo-request-uri> element set to the selected MCVideo ID and shall not continue with the rest of the steps in this clause;

NOTE 1: How the controlling MCVideo function selects the appropriate MCVideo ID is implementation specific.

8) if:

a) the received SIP INVITE request contains an emergency indication set to a value of "true";

b) the originating MCVideo user is not in an in-progress emergency private call state with the targeted MCVideo user; and

c) if the <session-type> in the SIP INVITE request is set to "private";

then:

a) shall cache the information that the MCVideo user has initiated an MCVideo emergency private call to the targeted user; and

b) shall cache the information that the MCVideo user is in an in-progress emergency private call state with the targeted MCVideo user;

9) shall perform actions as described in clause 6.3.3.2.2;

10) shall allocate an MCVideo session identity for the MCVideo session; and

11) shall invite the MCVideo user(s) listed in the "uri" attribute of <entry> elements in the <list> elements in the <resource-lists> element in the application/resource-lists+xml MIME body of received SIP INVITE request as specified in clause 10.2.2.4.1.

Upon receiving a SIP 180 (Ringing) response and if the SIP 180 (Ringing) response or the SIP final response has not yet been sent to the inviting MCVideo client, the controlling MCVideo function:

1) if the SIP 180 (Ringing) response is associated with a SIP INVITE that contained a <session-type> set to "private", shall generate a SIP 180 (Ringing) response to the SIP INVITE request and send the SIP 180 (Ringing) response towards the inviting MCVideo client according to 3GPP TS 24.229 [11]; and

Upon receiving a SIP 200 (OK) response for the SIP INVITE request, the SIP dialog was established as a result of receiving a SIP INVITE request with a <session-type> element set to the value of "private" and the SIP final response has not yet been sent to the inviting MCVideo client, the controlling MCVideo function:

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

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

3) if the received SIP INVITE request contains an alert indication 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.13.1, shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

NOTE 2: This is the case when the MCVideo user’s request for an MCVideo emergency private call was granted but the request for the MCVideo emergency alert was denied.

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

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

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

Upon receiving a SIP 200 (OK) response for the SIP INVITE request, the SIP dialog was established as a result of receiving a SIP INVITE request with a <session-type> element set to the value of "first-to-answer" and the SIP final response has not yet been sent to the inviting MCVideo client the controlling MCVideo function:

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

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

3) the received SIP INVITE request contains an emergency indication set to a value of "true":

a) shall cache the information that the MCVideo user has initiated an MCVideo emergency private call to the targeted user; and

b) shall cache the information that the MCVideo user is in an in-progress emergency private call state with the targeted MCVideo user;

4) if the received SIP INVITE request contains an alert indication 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.13.1, shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

NOTE 3: This is the case when the MCVideo user’s request for an MCVideo emergency private call was granted but the request for the MCVideo emergency alert was denied.

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

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

6) shall send a SIP 200 (OK) response towards the inviting MCVideo client according to 3GPP TS 24.229 [4]; and

7) if not successful in cancelling or terminating SIP dialogs in step 6) above, may repeat the SIP CANCEL and SIP BYE requests.

Upon receiving a SIP ACK to the SIP 200 (OK) response sent towards the inviting MCVideo client, where the SIP 200 (OK) response was sent with a Warning header field as specified in clause 4.4 with the warning text containing the mcvideo-warn-code set to "149", the controlling MCVideo function shall follow the procedures in clause 6.3.3.1.18.

The controlling MCVideo function shall forward any other SIP response that does not contain SDP, including any MIME bodies contained therein, along the signalling path to the originating network according to 3GPP TS 24.229 [11].

10.2.2.4.3 Receiving a SIP re-INVITE for upgrade to emergency private call

In the procedures in this clause:

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

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

Upon receiving a SIP re-INVITE request with an emergency indication set to a value of "true", the controlling MCVideo function:

1) shall validate that the received SDP offer includes at least one media stream for which the media parameters and at least one codec or media format is acceptable by the controlling MCVideo function and if not, reject the request with a SIP 488 (Not Acceptable Here) response and skip the rest of the steps;

2) shall validate the request as described in clause 6.3.3.1.17;

3) if the SIP re-INVITE request contains an unauthorised request for an MCVideo emergency private call as determined by clause 6.3.3.1.13.2:

a) shall reject the SIP INVITE request with a SIP 403 (Forbidden) response as specified in clause 6.3.3.1.14; and

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

4) if a Resource-Priority header field is included in the received SIP re-INVITE request and if the Resource-Priority header field is set to the value indicated for emergency calls, shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response and skip the remaining steps if neither of the following conditions are true:

a) the SIP re-INVITE request does contains an authorised request for an MCVideo emergency call as determined in step 2 above; or

b) the originating MCVideo user is in an in-progress emergency private call state with the targeted MCVideo user;

5) if the SIP re-INVITE request contains an emergency indication set to a value of "true" and the originating MCVideo user is not in an in-progress emergency private call state with the targeted MCVideo user:

a) shall cache the information that the MCVideo user is in an in-progress emergency private call state with the targeted MCVideo user; and

b) if the SIP re-INVITE request contains an alert indication set to "true" and this is an authorised request for an MCVideo emergency alert as specified in clause 6.3.3.1.13.1, shall cache the information that the MCVideo user has sent an MCVideo emergency alert to the targeted user; and

6) shall send a SIP re-INVITE invite towards the MCVideo user listed in the "uri" attribute of an <entry> element in a <list> element in the <resource-lists> element in the application/resource-lists+xml MIME body of received SIP re-INVITE request as specified in clause 11.1.1.4.5.

Upon receiving a SIP 200 (OK) response for the SIP re-INVITE request and if the SIP response has not yet been sent to the inviting MCVideo client, the controlling MCVideo function:

1) shall generate a SIP 200 (OK) response to the SIP re-INVITE request as specified in the clause 6.3.3.2.3 before continuing with the rest of the steps;

2) shall include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP re-INVITE request containing the current media parameters used by the existing session;

3) if the received SIP re-INVITE request contains an alert indication 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.13.1, shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4.

NOTE: When a SIP 200 (OK) response sent to the originator as a response to a SIP INVITE request that contained authorised request(s) for an MCVideo emergency private call and optionally an MCVideo emergency alert, the originator will consider a SIP 200 (OK) response populated in this manner as confirmation that its request(s) for an upgrade to an MCVideo emergency private call and optionally an MCVideo emergency alert were accepted by the controlling function.

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

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

Upon receiving a SIP ACK to the SIP 200 (OK) response sent towards the inviting MCVideo client, and the SIP 200 (OK) response was sent with the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4, the controlling MCVideo function shall follow the procedures in clause 6.3.3.1.18:

10.2.2.4.4 Receiving a SIP re-INVITE for cancellation of emergency private call

In the procedures in this clause:

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

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

Upon receiving a SIP re-INVITE request with an emergency indication set to a value of "false", the controlling MCVideo function:

2) shall validate the request as described in clause 6.3.3.1.17;

3) if the SIP re-INVITE request contains an unauthorised request for an MCVideo emergency private call cancellation as determined by clause 6.3.3.1.13.4:

a) shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response;

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

c) if the SIP re-INVITE request contains an alert indication set to "false" and this is an unauthorised request for an MCVideo emergency alert cancellation as specified in clause 6.3.3.1.13.3, shall include in the SIP 403 (Forbidden) response an application/vnd.3gpp.mcvideo-info+xml MIME body with an <alert-ind> element set to "true; and

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

4) shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response if a Resource-Priority header field is included in the received SIP re-INVITE request set to the value configured for emergency calls, and skip the remaining steps; and

5 if the SIP re-INVITE request contains an authorised request for an MCVideo emergency private call cancellation as determined by clause 6.3.3.1.13.4:

a) shall clear the cache of the MCVideo ID of the originator of the MCVideo emergency private call that is no longer in an in-progress emergency private call state with the targeted MCVideo user; and

b) if the SIP re-INVITE request contains an alert indication set to "false" and this is an authorised request for an MCVideo emergency alert cancellation meeting the conditions specified in clause 6.3.3.1.13.3:

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

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

6) shall send a SIP re-INVITE request towards the MCVideo user listed in the "uri" attribute of an <entry> element in a <list> element in the <resource-lists> element in the application/resource-lists+xml MIME body of received SIP re-INVITE request as specified in clause 11.1.1.4.6.

Upon receiving a SIP 200 (OK) response for the SIP re-INVITE request and if the SIP response has not yet been sent to the inviting MCVideo client, the controlling MCVideo function:

1) shall generate a SIP 200 (OK) response to the SIP re-INVITE request as specified in the clause 6.3.3.2.3 before continuing with the rest of the steps;

2) shall include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP re-INVITE request as specified in the clause 6.3.3.2.2;

3) if the received SIP re-INVITE request contains an alert indication set to a value of "false" and this is an unauthorised request for an MCVideo emergency alert cancellation as specified in clause 6.3.3.1.13.3, shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

NOTE: When a SIP 200 (OK) response sent to the originator as a response to a SIP INVITE request that contained authorised request(s) for an MCVideo emergency private call cancellation and optionally an MCVideo emergency alert cancellation, the originator will consider a SIP 200 (OK) response populated in this manner as confirmation that its request(s) for cancellation of an MCVideo emergency private call and optionally an MCVideo emergency alert were accepted by the controlling function.

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

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

10.2.2.4.5 Sending a SIP re-INVITE for upgrade to emergency private call

This clause describes the procedures for sending a re-INVITE request to an MCVideo user in an MCVideo private call for the purpose of upgrading the session to an emergency private call session. The procedure is initiated by the controlling MCVideo function as the result of an action in clause 11.1.1.4.3.

The controlling MCVideo function:

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

2) if the received 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 to the outgoing re-INVITE request;

3) if the received SIP re-INVITE request contains an authorised request for an MCVideo emergency private call as determined by clause 6.3.3.1.13.2:

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

4) shall include a Resource-Priority header field populated with the values for an MCVideo emergency private call as specified in clause 6.3.3.1.19, if the received SIP re-INVITE request contains an authorised request for an MCVideo emergency private call as determined in step 2 above; and

5) shall send the SIP re-INVITE request towards the core network according to 3GPP TS 24.229 [11].

Upon receiving SIP 200 (OK) response for the SIP re-INVITE request the controlling MCVideo function:

1) shall cache the contact received in the Contact header field.

10.2.2.4.6 Sending a SIP re-INVITE for cancellation of emergency private call

This clause describes the procedures for sending a re-INVITE request to an MCVideo user in an MCVideo emergency private call for the purpose of downgrading the session to a normal priority private call session. The procedure is initiated by the controlling MCVideo function as the result of an action in clause 11.1.1.4.4.

The controlling MCVideo function:

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

3) if the received SIP re-INVITE request contains an authorised request for an MCVideo emergency private call cancellation as determined by clause 6.3.3.1.13.4:

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

b) if the received SIP INVITE request contains an alert indication set to a value of "false" and this is an authorised request for an MCVideo emergency alert cancellation meeting the conditions specified in clause 6.3.3.1.13.3:

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

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

c) if the received SIP INVITE request contains an alert indication set to a value of "false" and is not an authorised request for an MCVideo emergency alert cancellation meeting the conditions specified in clause 6.3.3.1.13.3, shall set the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to a value of "true";

4) shall include a Resource-Priority header field populated with the values for a normal MCVideo private call as specified in clause 6.3.3.1.19, if the received SIP re-INVITE request contains an authorised request for an MCVideo emergency private call cancellation as determined in step 3 above; and

5) shall send the SIP re-INVITE request towards the core network according to 3GPP TS 24.229 [11].

Upon receiving SIP 200 (OK) response for the SIP re-INVITE request the controlling MCVideo function:

1) shall cache the contact received in the Contact header field.

10.2.3 Private call without transmission control

10.2.3.1 MCVideo client procedures

When the MCVideo user wants to make an on-demand private call without transmission control or first-to-answer call without transmission control, the MCVideo client shall follow the procedures in clause 10.2.2.1.1 with the following exceptions:

1) in step 8) of clause 10.2.2.1.1, the MCVideo client shall not offer a media-level section for a media-transmission control entity; and

2) step 9) of clause 10.2.2.1.1 shall be ignored.

Upon receipt of an initial SIP INVITE request for the private call an SDP offer not including a media-level section for a media-transmission control entity, the MCVideo client shall consider it as the request for private call without transmission control and shall follow the procedures as specified in clause 10.2.2.1.2 for on-demand session.

10.2.3.2 Participating MCVideo function procedures

10.2.3.2.1 Originating procedures

Upon receipt of a "SIP INVITE request for originating participating MCVideo function" or "SIP REFER request for a pre-established session" for the private call or first-to-answer call with SDP offer not including media-level section for media-transmission control entity, the participating MCVideo function shall consider it as the request for the private call without transmission control or first-to-answer call without transmission control and shall follow the procedures as specified in clause 10.2.2.4.1.1 for an on-demand session and shall follow the procedures as specified in clause 10.2.2.4.1.2 for initiation using a pre-established session.

10.2.3.2.2 Terminating procedures

Upon receipt of a "SIP INVITE request for terminating participating MCVideo function" for the private call or first-to-answer call with SDP offer not including media-level section for media-transmission control entity, the participating MCVideo shall consider it as the request for the private call without transmission control or first-to-answer call without transmission control and shall follow the procedures as specified in clause 10.2.2.4.2.

10.2.3.3 Controlling MCVideo function procedures

10.2.3.3.1 Originating procedures

The controlling MCVideo function shall follow the procedures as specified in clause 10.2.2.4.

10.2.3.3.2 Terminating procedures

Upon receiving of a "SIP INVITE request for controlling MCVideo function of a private call" or a "SIP INVITE request for controlling MCVideo function of a first-to-answer call", with SDP offer not including media-level section for media-transmission control entity, the controlling MCVideo function shall consider it as the request for the private call without transmission control or first-to-answer call without transmission control, and shall follow the procedures as specified in clause 10.2.2.4.2.

10.2.4 Ending the private call initiated by MCVideo client

10.2.4.1 MCVideo client procedures

10.2.4.1.1 On-demand private call

10.2.4.1.1.1 Client originating procedures

Upon receiving a request from an MCVideo user to release an MCVideo private call session established using on-demand session signalling, the MCVideo client shall follow the procedures as specified in clause 6.2.5.1.

10.2.4.1.1.2 Client terminating procedures

Upon receiving a SIP BYE request for private call session, the MCVideo client shall follow the procedures as specified in clause 6.2.6.

10.2.4.2 Participating MCVideo function procedures

10.2.4.2.1 Originating procedures

10.2.4.2.1.1 Receipt of SIP BYE request for on-demand private call

Upon receiving from the MCVideo client a SIP BYE request the participating MCVideo function shall follow the procedures as specified in clause 6.3.2.1.6.

10.2.4.2.2 Terminating procedures

10.2.4.2.2.1 Receipt of SIP BYE request for private call on-demand

Upon receiving a SIP BYE request from the controlling MCVideo function, the participating MCVideo function shall follow the procedures as specified in clause 6.3.2.2.8.1.

10.2.4.3 Controlling MCVideo function procedures

10.2.4.3.1 Terminating procedures

Upon receiving a SIP BYE request the controlling MCVideo function shall follow the procedures as specified in clause 6.3.3.2.4.

10.2.5 Ending the private call initiated by the MCVideo server

10.2.5.1 General

This clause describes the procedures of each functional entity for ending the private call initiated by the MCVideo server.

NOTE: For private call without transmission control, ending the private call is initiated only by the MCVideo client.

10.2.5.2 MCVideo client procedures

Upon receiving a SIP BYE request for private call session, the MCVideo client shall follow the procedures as specified in clause 6.2.6.

10.2.5.3 Participating MCVideo function procedures

10.2.5.3.1 Originating procedures

When the MCVideo session for private call needs to be released as specified in clause 6.3.8.2, the participating MCVideo function shall follow the procedures in clause 6.3.3.1.5.

10.2.5.3.2 Terminating procedures

10.2.5.3.2.1 Receipt of SIP BYE request for private call on-demand

Upon receiving a SIP BYE request from the controlling MCVideo function, the participating MCVideo function shall follow the procedures as specified in clause 6.3.2.2.8.1.

10.2.5.4 Controlling MCVideo function procedures

When the MCVideo session for private call needs to be released as specified in clause 6.3.8.2, the controlling MCVideo function shall follow the procedures in clause 6.3.3.1.5.