15 Supplementary Services

34.229-13GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 1: Protocol conformance specificationRelease 16TSUser Equipment (UE) conformance specification

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

15.1 Originating Identification Presentation

15.1.1 Definition

Test to verify that the UE activates and deactivates IMS Multimedia Telephony Originating Identification Presentation. This process is described in 3GPP TS 24.607 [102].

15.1.2 Conformance requirement

Generic requirements for Originating Identification Presentation can be found from Annexes F.1 and F.2.

[TS 24.607 clause 4.2.1]:

The OIP service provides the terminating user with the possibility of receiving trusted (i.e. network provided) identity information in order to identify the originating user.

In addition to the trusted identity information, the identity information from the originating user can include identity information generated by the originating user and in general transparently transported by the network. In the particular case where the "no screening" special arrangement does not apply, the originating network shall verify the content of this user generated identity information. The terminating network cannot be responsible for the content of this user generated identity information.

[TS 24.607 clause 4.10.1]:

The OIP service can be activated/deactivated using the active attribute of the <originating‑identity‑presentation> service element.

Reference(s)

3GPP TS 24.607[102], clauses 4.2.1 and 4.10.1.

15.1.3 Test purpose

1) To verify that the UE can request activation of Originating Identification Presentation with a correctly composed HTTP PUT request; and

2) To verify that the UE can request deactivation of Originating Identification Presentation; and

3) To verify that the UE can authenticate its HTTP requests by including a correctly composed Authorization header with credentials of the user to the request. The UE may either include the Authorization header to its initial request or when sending the request again after receiving 401 response from SS.

15.1.4 Method of test

Initial conditions

UE contains either ISIM and USIM applications or only USIM application on UICC. UE is configured with the name of the XCAP root directory on the XCAP server and the user’s directory name. If needed the UE is also configured with the HTTP Digest password to be used for XCAP. UE has activated an IPCAN bearer (e.g. PDP context or EPS bearer) with SS.

SS is configured with the HTTP Digest password for XCAP or shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE.

If the UE uses GAA as XCAP authentication scheme, GAA bootstrapping exchange has been performed according to Annex C.29.2.

Test procedure

The generic test procedure according to annex C.29.1 is applied: At step 1 activation of Originating Identification Presentation, at step 7 deactivation of Originating Identification Presentation is respectively triggered at the UE.

15.1.5 Test requirements

1. SS shall check that the UE can authenticate itself correctly with the authentication scheme that the UE supports:

– HTTP Digest authentication (see Annex C.29.1 step 2, NOTE 1) or

– GAA based authentication as specified in TS 33.222 [121] and TS 24.109 [119] (see Annex C.29.2).

2. SS shall check that after Annex C.29.1 step 6 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <originating-identity-presentation> element with "active" attribute set as "true" or with “active” attribute not present.

3. SS shall check that after step 9 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <originating-identity-presentation> element with "active" attribute being set "false"

15.2 Originating Identification Restriction

15.2.1 Definition

Test to verify that the UE activates and deactivates IMS Multimedia Telephony Originating Identification Restriction. This process is described in 3GPP TS 24.607 [102].

15.2.2 Conformance requirement

Generic requirements for Originating Identification Restriction can be found from Annexes F.1 and F.2.

[TS 24.607 clause 4.2.1]:

The OIR service is a service offered to the originating user. It restricts presentation of the originating user’s identity information to the terminating user.

When the OIR service is applicable and activated, the originating network provides the destination network with the indication that the originating user’s identity information is not allowed to be presented to the terminating user. In this case, no originating user’s identity information shall be included in the requests sent to the terminating user. The presentation restriction function shall not influence the forwarding of the originating user’s identity information within the network as part of the simulation service procedures.

[TS 24.607 clause 4.10.1]:

The OIR service can be activated/deactivated using the active attribute of the <originating‑identity‑presentation‑restriction> service element. Activating the OIR service this way activates the temporary mode OIR service. When deactivated and not overruled by operator settings, basic communication procedures apply.

Reference(s)

3GPP TS 24.607 [102], clauses 4.2.1 and 4.10.1.

15.2.3 Test purpose

1) To verify that the UE can request activation of Originating Identification Restriction with a correctly composed HTTP PUT request; and

2) To verify that the UE can request deactivation of Originating Identification Restriction; and

15.2.4 Method of test

Initial conditions

SS is configured with the HTTP Digest password for XCAP or shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE.

If the UE uses GAA as XCAP authentication scheme, GAA bootstrapping exchange has been performed according to annex C.29.2.

Test procedure

The generic test procedure according to annex C.29.1 is applied: At step 1 activation of Originating Identification Restriction, at step 7 deactivation of Originating Identification Restriction is respectively triggered at the UE.

15.2.5 Test requirements

1. SS shall check that the UE can authenticate itself correctly with the authentication scheme that the UE supports:

– HTTP Digest authentication (see Annex C.29.1 step 2 NOTE 1) or

– GAA based authentication as specified in TS 33.222 [121] and TS 24.109 [119] (see Annex C.29.2).

2. SS shall check that after Annex C.29.1 step 6 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <originating-identity-presentation-restriction> element with "active" attribute set as "true" or with “active” attribute not present.

3. SS shall check that after step 9 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <originating-identity-presentation-restriction> element with "active" attribute being set "false"

15.2a Originating Identification Restriction / Signalling

15.2a.1 Definition

Test to verify that the UE correctly invokes the IMS Multimedia Telephony Originating Identification Restriction in temporary mode. This process is described in 3GPP TS 24.607 [102].

15.2a.2 Conformance requirement

Generic requirements for Originating Identification Restriction can be found in Annex F.2.

[TS 24.607 clause 4.5.2.1]:

If the originating user wishes to override the default setting of "presentation not restricted" of the OIR service in temporary mode:

– The originating UE shall include an "anonymous" From header field. The convention for configuring an anonymous From header field described in IETF RFC 3323 [6] should be followed; i.e. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag= xxxxxxx.

– If only the P‑Asserted‑Identity needs to be restricted the originating UE shall include a Privacy header field [6] set to "id" in accordance with IETF RFC 3325 [7].

– If all headers containing private information that the UE cannot anonymize itself need to be restricted, the originating UE shall include a Privacy header field set to "header" in accordance with IETF RFC 3323 [6].

NOTE 2: The Privacy header field value "header" does not apply to the identity in the From header field.

Reference(s)

3GPP TS 24.607 [102], clause 4.5.2.1.

15.2a.3 Test purpose

To verify that the UE sends an INVITE with the correct headers when initiating an IMS call with originating identification restriction in temporary mode and wanting to restrict presentation of

– the From and P-Asserted-Identity headers., or

– all headers containing private information that the UE cannot anonymize itself

15.2a.4 Method of test

Same as clause 12.12 with the following exceptions.

Initial conditions

Same as clause 12.12 with the following addition:

The UE is configured to use Originating Identification Restriction in temporary mode. The corresponding default is set to “presentation not restricted”

Expected sequence

NOTE: Only the IMS procedure relevant to the test purpose is described below.

Step	Direction		Message	Comment
	UE	SS
1			Make the UE attempt an IMS speech call with originating identification restriction
2-13			Steps 2 to 13 defined in annex C.21	MTSI MO speech call. Referred from 36.508 [94] table 4.5A.6.3-1 for a UE with E-UTRA support.
14			Steps defined in annex C.32	Generic test procedure for MO release of IMS call

Specific Message Contents

Steps 2 – 13 as specified in annex C.21 with the following exceptions:

INVITE (Step 2)

Header/param	Value/remark	Reference
From
addr-spec	“Anonymous" <sip:anonymous@anonymous.invalid>
Privacy	id or header (mutually exclusive)	RFC 3323 [135] RFC 3325 [89]

Header/param

Value/remark

Reference

From

addr-spec

“Anonymous" <sip:anonymous@anonymous.invalid>

Privacy

id or header (mutually exclusive)

RFC 3323 [135]

RFC 3325 [89]

15.2a.5 Test requirements

Step 2: The UE shall send the INVITE request including the following headers:

From header: “Anonymous" <sip:anonymous@anonymous.invalid>

Privacy header: id or header

15.3 Terminating Identification Presentation

15.3.1 Definition

Test to verify that the UE activates and deactivates IMS Multimedia Telephony Terminating Identification Presentation. This process is described in 3GPP TS 24.608 [103].

15.3.2 Conformance requirement

[TS 24.608 clause 4.2.1]:

The Terminating Identification Presentation (TIP) service provides the originating party with the possibility of receiving trusted information in order to identify the terminating party.

[TS 24.608 clause 4.9.1]:

The TIP service can be activated/deactivated using the active attribute of the <terminating‑identity‑presentation> service element.

Reference(s)

3GPP TS 24.608 [103 ], clauses 4.2.1 and 4.9.1.

15.3.3 Test purpose

1) To verify that the UE can request activation of Terminating Identification Presentation with a correctly composed HTTP PUT request; and

2) To verify that the UE can request deactivation of Terminating Identification Presentation; and

15.3.4 Method of test

Initial conditions

SS is configured with the HTTP Digest password for XCAP or shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE.

If the UE uses GAA as XCAP authentication scheme, GAA bootstrapping exchange has been performed according to annex C.29.2.

Test procedure

The generic test procedure according to annex C.29.1 is applied: At step 1 activation of Terminating Identification Presentation, at step 7 deactivation of Terminating Identification Presentation is respectively triggered at the UE.

15.3.5 Test requirements

1. SS shall check that the UE can authenticate itself correctly with the authentication scheme that the UE supports:

– HTTP Digest authentication (see Annex C.29.1 step 2 NOTE 1) or

– GAA based authentication as specified in TS 33.222 [121] and TS 24.109 [119] (see Annex C.29.2).

2. SS shall check that after Annex C.29.1 step 6 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <terminating-identity-presentation> element with "active" attribute set as "true" or with “active” attribute not present.

3. SS shall check that after step 9 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <terminating-identity-presentation> element with "active" attribute being set "false"

15.4 Terminating Identification Restriction

15.4.1 Definition

Test to verify that the UE activates and deactivates IMS Multimedia Telephony Terminating Identification Restriction. This process is described in 3GPP TS 24.608 [103].

15.4.2 Conformance requirement

[TS 24.608 clause 4.2.1]:

The Terminating Identification Restriction (TIR) is a service offered to the terminating party which enables the terminating party to prevent presentation of the terminating identity information to originating party.

[TS 24.608 clause 4.9.1]:

The TIR service can be activated/deactivated using the active attribute of the <terminating‑identity‑presentation‑restriction> service element. Activating the TIR service this way activates the temporary mode TIR service. When deactivated and not overruled by operator settings, basic communication procedures apply.

Reference(s)

3GPP TS 24.608 [103], clauses 4.2.1 and 4.9.1.

15.4.3 Test purpose

1) To verify that the UE can request activation of Terminating Identification Restriction with a correctly composed HTTP PUT request; and

2) To verify that the UE can request deactivation of Terminating Identification Restriction; and

15.4.4 Method of test

Initial conditions

SS is configured with the HTTP Digest password for XCAP or shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE.

If the UE uses GAA as XCAP authentication scheme, GAA bootstrapping exchange has been performed according to annex C.29.2.

Test procedure

The generic test procedure according to annex C.29.1 is applied: At step 1 activation of Terminating Identification Restriction, at step 7 deactivation of Terminating Identification Restriction is respectively triggered at the UE.

15.4.5 Test requirements

1. SS shall check that the UE can authenticate itself correctly with the authentication scheme that the UE supports:

– HTTP Digest authentication (see Annex C.29.1 step 2 NOTE 1) or

– GAA based authentication as specified in TS 33.222 [121] and TS 24.109 [119] (see Annex C.29.2).

2. SS shall check that after Annex C.29.1 step 6 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <terminating-identity-presentation-restriction> element with "active" attribute set as "true" or with “active” attribute not present.

3. SS shall check that after step 9 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <terminating-identity-presentation-restriction> element with "active" attribute being set "false"

15.4a Terminating Identification Restriction / Signalling

15.4a.1 Definition

Test to verify that the UE correctly invokes the IMS Multimedia Telephony Terminating Identification Restriction in temporary mode. This process is described in 3GPP TS 24.608 [103].

15.4a.2 Conformance requirement

Generic requirements for Originating Identification Restriction can be found in Annex F.3.

[TS 24.608 clause 4.2.1]:

[TS 24.608 clause 4.5.2.12]:

The destination UE, if the terminating user wishes to override the default setting of "presentation not restricted" of the TIR service in temporary mode, shall include a Privacy header with privacy type of "id" in any non-100 responses it sends upon receipt of a SIP request.

….NOTE: It is assumed that TIR subscribers support IETF RFC 3325.

Reference(s)

3GPP TS 24.608 [103], clauses 4.2.1 and 4.5.2.12.

15.4a.3 Test purpose

To verify that the UE includes a Privacy header with privacy type of "id" in any non-100 responses it sends upon receipt of a SIP request when using the TIR service in temporary mode and the terminating user wishing to override the default setting currently set to “not restricted”

15.4a.4 Method of test

Same as clause 12.13 with the following exceptions.

Initial conditions

Same as clause 12.13 with the following addition:

The UE is configured to use Terminating Identification Restriction in temporary mode. The corresponding default is currently set to “presentation not restricted”.

Expected sequence

NOTE: Only the IMS procedure relevant to the test purpose is described below.

Step	Direction		Message	Comment
	UE	SS
1-11			Steps 1-11 defined in annex C.11	MTSI MT speech call. Referred from 36.508 [94] table 4.5A.7.3-1 for a UE with E-UTRA support.
12				Make UE accept the MTSI MT speech offer with Terminating Identification Restriction
13-16			Steps 12-15 defined in annex C.11	MTSI MT speech call. Referred from 36.508 [94] table 4.5A.7.3-1 for a UE with E-UTRA support.

Specific Message Contents

Steps 1-11 and 13-16 as specified in annex C.11 with the following exceptions:

183 Session Progress (Step 4)

Use the default message "183 Session Progress" in annex A.2.3 with the following exceptions:

Header/param

Value/remark

Reference

Privacy

RFC 3323 [135]

RFC 3325 [89]

180 Ringing (Step 9)

Use the default message “180 Ringing for INVITE” in annex A.2.6 with the following exceptions:

Header/param

Value/remark

Reference

Privacy

RFC 3323 [135]

RFC 3325 [89]

200 Ok (Step 12)

Use the default message “200 OK for other requests than REGISTER or SUBSCRIBE” in annex A.3.1 with the following exceptions:

Header/param

Value/remark

Reference

Privacy

RFC 3323 [135]

RFC 3325 [89]

15.4a.5 Test requirements

Steps 4, 9 and 12: The UE shall include a Privacy header with privacy type set to "id".

15.5 Communication Forwarding unconditional

15.5.1 Definition

Test to verify that the UE activates and deactivates IMS Multimedia Telephony Communication Forwarding unconditional. This process is described in 3GPP TS 24.604 [106].

15.5.2 Conformance requirement

Generic requirements for Communication Forwarding can be found from Annexes F.1 and F.4.

[TS 24.604, clause 4.2.1.2]:

The CFU service enables a served user to have the network redirect to another user communications which are addressed to the served user’s address. The CFU service may operate on all communication, or just those associated with specified services. The served user’s ability to originate communications is unaffected by the CFU supplementary service. After the CFU service has been activated, communications are forwarded independent of the status of the served user.

As a service provider option, a subscription option can be provided to enable the served user to receive an indication that the CFU service has been activated. This indication shall be provided when the served user originates a communication if the CFU service has been activated for the served user’s address and for the service requested for the communication.

The maximum number of diversions permitted for each communication is a service provider option. The service provider shall define the upper limit of diversions. When counting the number of diversions, all types of diversion are included.

Reference(s)

3GPP TS 24.604 [106].

15.5.3 Test purpose

1) To verify that the UE can request activation of Communication Forwarding unconditional with a correctly composed HTTP PUT request; and

2) To verify that the UE can request deactivation of Communication Forwarding unconditional; and

15.5.4 Method of test

Initial conditions

SS is configured with the HTTP Digest password for XCAP or shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE.

If the UE uses GAA as XCAP authentication scheme, GAA bootstrapping exchange has been performed according to annex C.29.2.

Test procedure

The generic test procedure according to annex C.29.1 is applied:

At step 1 activation of Communication Forwarding unconditional;

At step 5b, when sending 200 OK for GET, SS delivers a simservs document as specified in TS 24.604 [106] cl 4.9, including a non-empty rule set. Specifically, the SS includes the following:

<?xml version="1.0" encoding="UTF-8"?>

<simservs

xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap"

xmlns:cp="urn:ietf:params:xml:ns:common-policy"

xmlns:ocp="urn:oma:xml:xdm:common-policy">

<communication-diversion active="true">

<cp:ruleset>

<cp:rule id="rule1">

<cp:conditions>

<rule-deactivated/>

</cp:conditions>

<cp:actions>

<forward-to>

px_XCAP_TargetUri

</target>

<notify-caller>true</notify-caller>

</forward-to>

</cp:actions>

</cp:rule>

</cp:ruleset>

</communication-diversion>

</simservs>

At step 7 deactivation of Communication Forwarding unconditional is respectively triggered at the UE.

15.5.5 Test requirements

1. SS shall check that the UE can authenticate itself correctly with the authentication scheme it supports:

– HTTP Digest authentication (see Annex C.29.1 step 2 NOTE 1) or

– GAA based authentication as specified in TS 33.222 [121] and TS 24.109 [119] (see Annex C.29.2).

2. SS shall check that after Annex C.29.1 step 6 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <communication-diversion> element with "active" attribute set as "true" or with “active” attribute not present.

– within <cp:ruleset> one <cp:rule> element for communication forwarding as follows:

– <cp:conditions> element missing or empty as forwarding is supposed to be unconditional and not containing a <rule-deactivated> element

– <cp:actions> element containing <forward-to> element containing <target> element

– value of target address to be px_XCAP_TargetUri

3. SS shall check that after step 9 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <communication-diversion> element with "active" attribute being set "false"

– <communication-diversion> element with "active" attribute set as "true" or with “active” attribute not present.

– within <cp:ruleset> one <cp:rule> element found at step 2 for Communication Forwarding unconditional as follows:

– <cp:conditions> element containing a <rule-deactivated> element

15.6 Void

15.7 Communication Forwarding on non Reply: activation

15.7.1 Definition

Test to verify that the UE activates and deactivates IMS Multimedia Telephony Communication Forwarding for the case when user does not answer to the phone. This process is described in 3GPP TS 24.604 [106].

15.7.2 Conformance requirement

Generic requirements for Communication Forwarding can be found from Annexes F.1 and F.4.

[TS 24.604, clause 4.2.1.4]:

The CFNR service enables a served user to have the network redirect to another user communications which are addressed to the served user’s address, and for which the connection is not established within a defined period of time. The CFNR service may operate on all communications, or just those associated with specified services. The served user’s ability to originate communications is unaffected by the CFNR supplementary service.

The CFNR service can only be invoked by the network after the communication has been offered to the served user and an indication that the called user is being informed of the communication has been received.

As a service provider option, a subscription option can be provided to enable the served user to receive an indication that the CFNR service has been activated. This indication shall be provided when the served user originates a communication if the CFNR service has been activated for the served user’s address and for the service requested for the communication.

Reference(s)

3GPP TS 24.604 [106]

15.7.3 Test purpose

1) To verify that the UE can request activation of Communication Forwarding (when the called user does not answer) with a correctly composed HTTP PUT request; and

2) To verify that the UE can request deactivation of Communication Forwarding; and

15.7.4 Method of test

Initial conditions

SS is configured with the HTTP Digest password for XCAP or shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE.

If the UE uses GAA as XCAP authentication scheme, GAA bootstrapping exchange has been performed according to annex C.29.2.

Test procedure

The generic test procedure according to annex C.29.1 is applied:

At step 1 activation of Communication Forwarding on non Reply;

At step 5b, SS delivers a simservs document as specified in TS 24.604 [106] cl 4.9, including a non-empty rule set. Specifically, the SS includes the following:

<?xml version="1.0" encoding="UTF-8"?>

<simservs

xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap"

xmlns:cp="urn:ietf:params:xml:ns:common-policy"

xmlns:ocp="urn:oma:xml:xdm:common-policy">

<communication-diversion active="true">

<cp:ruleset>

<cp:rule id="rule1">

<cp:conditions>

<no-answer/>

<rule-deactivated/>

</cp:conditions>

<cp:actions>

<forward-to>

px_XCAP_TargetUri

</target>

<notify-caller>true</notify-caller>

</forward-to>

</cp:actions>

</cp:rule>

</cp:ruleset>

</communication-diversion>

</simservs>

At step 7 deactivation of Communication Forwarding on non Reply is respectively triggered at the UE.

15.7.5 Test requirements

1. SS shall check that the UE can authenticate itself correctly with the authentication scheme that the UE supports:

– HTTP Digest authentication (see Annex C.29.1 step 2, NOTE 1) or

– GAA based authentication as specified in TS 33.222 [121] and TS 24.109 [119] (see Annex C.29.2).-

2. SS shall check that after Annex C.29.1 step 6 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <communication-diversion> element with "active" attribute set as "true" or with “active” attribute not present.

– within <cp:ruleset> one <cp:rule> element for communication forwarding as follows:

– <cp:conditions> element containing a <no-answer> element and not containing a <rule-deactivated> element

– <cp:actions> element containing <forward-to> element containing <target> element. Additionally <NoReplyTimer> element shall be included, if the UE supports no reply timer setting.

– value of target address to be px_XCAP_TargetUri

– value of NoReplyTimer (if included) to be 10 seconds

3. SS shall check that after step 9 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <communication-diversion> element with "active" attribute being set "false"

– <communication-diversion> element with "active" attribute set as "true" or with “active” attribute not present.

– within <cp:ruleset> one <cp:rule> element found at step 2 for communication forwarding as follows:

– <cp:conditions> element containing a <rule-deactivated> element

15.8 Communication Forwarding on non reply: MO call initiation

15.8.1 Definition

Test to verify that the MTSI MO UE correctly handles session setup where call is being forwarded due to no reply. This process is described in 3GPP TS 24.604 [106], clauses 4.2.1, 4.5.2.1 and A.1.3 and 3GPP TS 24.229 [10], clause 9.2.3.

15.8.2 Conformance requirement

[TS 24.604, clause 4.2.1.4]:

[TS 24.604, clause 4.5.2.1]:

When communication diversion has occurred on the served user side and the network option "Originating" user receives notification that his communication has been diverted (forwarded or deflected)" is set to true, the originating UA may receive a 181 (Call is being forwarded) response according to the procedures described in 3GPP TS 24.229.

The Information given by the History header could be displayed by the UA if it is a UE.

[TS 24.229, clause 9.2.3]:

Since the UE does not know that forking has occurred until a second provisional response arrives, the UE will request the radio/bearer resources as required by the first provisional response. For each subsequent provisional response that may be received, different alternative actions may be performed depending on the requirements in the SDP answer:

– the UE has sufficient radio/bearer resources to handle the media specified in the SDP of the subsequent provisional response, or

– the UE must request additional radio/bearer resources to accommodate the media specified in the SDP of the subsequent provisional response.

NOTE 1: When several forked responses are received, the resources requested by the UE is the "logical OR" of the resources indicated in the multiple responses to avoid allocation of unnecessary resources. The UE does not request more resources than proposed in the original INVITE request.

NOTE 2: When service-based local policy is applied, the UE receives the same authorization token for all forked requests/responses related to the same SIP session.

When an 199 (Early Dialog Terminated) response for the INVITE request is received for an early dialogue, the UE shall release reserved radio/bearer resources associated with that early dialogue.

When the first final 200 (OK) response for the INVITE request is received for one of the early dialogues, the UE proceeds to set up the SIP session using the radio/bearer resources required for this session. Upon the reception of the first final 200 (OK) response for the INVITE request, the UE shall release all unneeded radio/bearer resources.

GIBA:

NOTE 1: GIBA does not allow SIP requests to be protected using an IPsec security association because it does not perform a key agreement procedure.

Reference(s)

3GPP TS 24.604 [106], clauses 4.2.1 and 4.5.2.1; 3GPP TS 24.229 [10], clause 9.2.3

15.8.3 Test purpose

1) To verify that when initiating MO call the UE handles correctly the successive 180 and 181 provisional responses received during call setup.

15.8.4 Method of test

Initial conditions

UE contains either SIM application (GIBA), ISIM and USIM applications or only USIM application on UICC. UE has discovered P-CSCF and registered to IMS services, by executing the generic test procedure in Annex C.2 or C.2a (GIBA only) up to the last step.

SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE. SS has performed AKAv1-MD5 authentication with the UE and accepted the registration (IMS security).

Test procedure applicable for a UE with E-UTRA support (TS 34.229-2 [5] A.18/1)

1-9B) UE executes the procedures described in TS 36.508 [94] table 4.5A.6.3-1 steps 1 to 14 but only steps 1 to 11 of Annex C.21 in the parallel behaviour to steps 13-14 of table 4.5A.6.3-1.

10) SS responds to the INVITE with a valid 181 Call Is Being Forwarded response.

11) SS (now starting to simulate the UE to which call was forwarded) sends another 183 Session in Progress response to the INVITE request. As this response contains an SDP answer it is sent reliably.

12) SS waits for the UE to send a PRACK request, containing an SDP offer in which the UE tells to have reserved the local resources.

13) SS responds to the PRACK request with valid 200 OK response. The response contains an SDP answer which tells that SS has reserved its local resources as well.

13A) UE may send an UPDATE request.

13B) If UE sent and UPDATE request, SS responds with 200 OK.

14) SS responds to the INVITE request with 180 Ringing response.

14A) As the 180 Ringing response was sent reliably, UE sends a PRACK request.

14B) SS responds to PRACK with 200 OK.

15) SS responds to the INVITE request with valid 200 OK response.

16) SS waits for the UE to send an ACK to acknowledge receipt of the 200 OK for INVITE.

17) Call is released on the UE. SS waits the UE to send a BYE request.

18) SS responds to the BYE request with valid 200 OK response.

Expected sequence

NOTE: Only the IMS procedure relevant to the test purpose is described below.

Step	Direction		Message	Comment
	UE	SS
1-9B			Steps 1-11 as defined in Annex C.21	The same messages as in steps 2 – 11 of Annex C.21 are used. Referred from 36.508 [94] table 4.5A.6.3-1 for a UE with E-UTRA support.
10	🡨		181 Call is being forwarded	SS sends 181 response to indicate that call forwarding has been started as the user did not answer to the phone
11	🡨		183 Session Progress	SS (simulating the phone to which the call was forwarded) responds with 183 Session Progress containing an SDP answer indicating support for AMR-WB codec and state of the local preconditions. UE will consider this response as forked one since it has different To tag this time compared to step 8.
12-13B			Steps 5-8 as defined in Annex C.21	The same messages as specified in steps 5 – 8 of Annex C.21 are used with To-tag and Contact Address as in the 183 response of step 11
14	🡨		180 Ringing	The SS sends 180 Ringing response to the UE
14A	🡪		PRACK	UE acknowledges the receipt of 180 response by sending PRACK.
14B	🡨		200 OK	The SS responds PRACK with 200 OK.
15	🡨		200 OK	The SS responds INVITE with 200 OK to indicate that the virtual remote UE had answered the call
16	🡪		ACK	The UE acknowledges the receipt of 200 OK for INVITE
17	🡪		BYE	The UE releases the call with BYE
18	🡨		200 OK	The SS sends 200 OK for BYE

NOTE: The default messages contents in annex A are used with condition “IMS security“ or “GIBA” when applicable

Specific Message Contents

181 Call is being forwarded for INVITE (Step 10)

Use the default message “181 Call is being forwarded” in annex A.2.14

183 Session Progress for INVITE (Step 11)

Use the default message “183 Session in Progress for INVITE” in annex A.2.3 with the following exceptions:

Header/param	Value/remark
To
tag	different tag must be used than the one used in steps 3-9 as this response is now from another UE and belongs to another dialog instance. Note that this new tag must be used within the rest of the steps (10-17) in this test case instead of the tag used within steps 3-9.
Contact
addr-spec	different URI must be used than the one used in step 3 as this is supposed now to represent another UE to which the call is being forwarded.. Note that this new Contact must be used within the rest of the steps (13-14) in this test case.
Require
option-tag	precondition
Message-body	Same contents as specified in step 4 annex C.21. except for o-line: o=- 22222222 22222222 IN (addrtype) (unicast-address for new remote UE).

PRACK or UPDATE (Step 12 or 13A)

The UE shall include an SDP body as described in C.21, Step 5 , but with the following exceptions:

– Contents of o= line is not checked

180 Ringing for INVITE (Step 14)

Use the default message “180 Ringing for INVITE” in annex A.2.6 applying condition A3 (Response sent reliably) and with the following exceptions:

Header/param	Value/remark
Contact
addr-spec	Same value as in the 183 response of step 11
History-Info
hi-targeted-to-uri	Same value as in the 181 response of step 10
hi-index	Same value as in the 181 response of step 10

PRACK (Step 14A)

Use the default message “PRACK” in annex A.2.4.

200 OK for PRACK (Step 14B)

Use the default message "200 OK for other requests than REGISTER or SUBSCRIBE" in annex A.3.1.

200 OK for INVITE (Step 15)

Use the default message “200 OK for other requests than REGISTER or SUBSCRIBE” in annex A.3.1 with the following exceptions:

Header/param	Value/remark
Contact
addr-spec	Same value as in the 183 response of step 11
History-Info
hi-targeted-to-uri	Same value as in the 181 response of step 10
hi-index	Same value as in the 181 response of step 10

ACK (Step 16)

Use the default message “ACK” in annex A.2.7.

BYE (Step 17)

Use the default message “BYE” in annex A.2.8.

200 OK for BYE (Step 18)

Use the default message “200 OK for other requests than REGISTER or SUBSCRIBE” in annex A.3.1.

15.8.5 Test requirements

SS must check that if the UE uses IMS security, it sends all the requests over the security associations set up during registration, in accordance to 3GPP TS 24.229 [10], clause 5.1.1.5.1.

15.9 Communication Forwarding on Busy

15.9.1 Definition

Test to verify that the UE activates and deactivates IMS Multimedia Telephony Communication Forwarding for the case when user is busy. This process is described in 3GPP TS 24.604 [106].

15.9.2 Conformance requirement

Generic requirements for Communication Forwarding can be found from Annexes F.1 and F.4.

[TS 24.604, clause 4.2.1.3]:

The CFB service enables a served user to have the network redirect to another user communications which are addressed to the served user’s address and meet busy. The CFB service may operate on all communications, or just those associated with specified services. The served user’s ability to originate communications is unaffected by the CFB supplementary service.

As a service provider option, a subscription option can be provided to enable the served user to receive an indication that the CFB service has been activated. This indication shall be provided when the served user originates a communication if the CFB service has been activated for the served user’s address and for the service requested for the communication.

Reference(s)

3GPP TS 24.604 [106]

15.9.3 Test purpose

1) To verify that the UE can request activation of Communication Forwarding (when the called user is busy) with a correctly composed HTTP PUT request; and

2) To verify that the UE can request deactivation of Communication Forwarding; and

15.9.4 Method of test

Initial conditions

SS is configured with the HTTP Digest password for XCAP or shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE.

If the UE uses GAA as XCAP authentication scheme, GAA bootstrapping exchange has been performed according to annex C.29.2.

Test procedure

The generic test procedure according to annex C.29.1 is applied:

At step 1 activation of Communication Forwarding on Busy;

At step 5b, SS delivers a simservs document as specified in TS 24.604 [106] cl 4.9, including a non-empty rule set. Specifically, the SS includes the following:

<?xml version="1.0" encoding="UTF-8"?>

<simservs

xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap"

xmlns:cp="urn:ietf:params:xml:ns:common-policy"

xmlns:ocp="urn:oma:xml:xdm:common-policy">

<communication-diversion active="true">

<cp:ruleset>

<cp:rule id="rule1">

<cp:conditions>

<busy/>

<rule-deactivated/>

</cp:conditions>

<cp:actions>

<forward-to>

px_XCAP_TargetUri

</target>

<notify-caller>true</notify-caller>

</forward-to>

</cp:actions>

</cp:rule>

</cp:ruleset>

</communication-diversion>

</simservs>

At step 7 deactivation of Communication Forwarding on Busy is respectively triggered at the UE.

15.9.5 Test requirements

1. SS shall check that the UE can authenticate itself correctly with the authentication scheme that the UE supports:

– HTTP Digest authentication (see Annex C.29.1 step 2 NOTE 1) or

– GAA based authentication as specified in TS 33.222 [121] and TS 24.109 [119] (see Annex C.29.2).

2. SS shall check that after Annex C.29.1 step 6 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <communication-diversion> element with "active" attribute set as "true" or with “active” attribute not present.

– within <cp:ruleset> one <cp:rule> element for communication forwarding as follows:

– <cp:conditions> element containing a <busy> element and not containing a <rule-deactivated>

– <cp:actions> element containing <forward-to> element containing <target> element

– value of target address to be px_XCAP_TargetUri

3. SS shall check that after step 9 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <communication-diversion> element with "active" attribute being set "false"

– <communication-diversion> element with "active" attribute set as "true" or with “active” attribute not present.

– within <cp:ruleset> one <cp:rule> element found at step 2 for communication forwarding as follows:

– <cp:conditions> element containing a <rule-deactivated> element

15.10 Communication Forwarding on Not logged-in

15.10.1 Definition

Test to verify that the UE activates and deactivates IMS Multimedia Telephony Communication Forwarding for the case when user is not registered to IMS service. This process is described in 3GPP TS 24.604 [106].

15.10.2 Conformance requirement

Generic requirements for Communication Forwarding can be found from Annexes F.1 and F.4.

[TS 24.604, clause 4.2.1.7]:

The Communication Forwarding on Not Logged-in (CFNL) service enables a served user to redirect incoming communications which are addressed to the served user’s address, to another user (forwarded-to address) in case the served user is not registered (logged-in). The CFNL service may operate on all communications, or just those associated with specified basic services.

As a service provider option, a subscription option can be provided to enable the served user to receive an indication that the CFNL service has been activated. This indication shall be provided when the served user logs out according to procedures described in RFC 3261

Reference(s)

3GPP TS 24.604 [106]

15.10.3 Test purpose

1) To verify that the UE can request activation of Communication Forwarding (when the called user is not logged in) with a correctly composed HTTP PUT request; and

2) To verify that the UE can request deactivation of Communication Forwarding; and

15.10.4 Method of test

Initial conditions

SS is configured with the HTTP Digest password for XCAP or shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE.

If the UE uses GAA as XCAP authentication scheme, GAA bootstrapping exchange has been performed according to annex C.29.2.

Test procedure

The generic test procedure according to annex C.29.1 is applied:

At step 1 activation of Communication Forwarding on Not logged-in;

At step 5b, SS delivers a simservs document as specified in TS 24.604 [106] cl 4.9, including a non-empty rule set. Specifically, the SS includes the following:

<?xml version="1.0" encoding="UTF-8"?>

<simservs

xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap"

xmlns:cp="urn:ietf:params:xml:ns:common-policy"

xmlns:ocp="urn:oma:xml:xdm:common-policy">

<communication-diversion active="true">

<cp:ruleset>

<cp:rule id="rule1">

<cp:conditions>

<not-registered/>

<rule-deactivated/>

</cp:conditions>

<cp:actions>

<forward-to>

px_XCAP_TargetUri

</target>

<notify-caller>true</notify-caller>

</forward-to>

</cp:actions>

</cp:rule>

</cp:ruleset>

</communication-diversion>

</simservs>

At step 7 deactivation of Communication Forwarding on Not logged-in is respectively triggered at the UE.

15.10.5 Test requirements

1. SS shall check that the UE can authenticate itself correctly with the authentication scheme that the UE supports:

– HTTP Digest authentication (see Annex C.29.1 step 2 NOTE 1) or

– GAA based authentication as specified in TS 33.222 [121] and TS 24.109 [119] (see Annex C.29.2).

2. SS shall check that after Annex C.29.1 step 6 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <communication-diversion> element with "active" attribute set as "true" or with “active” attribute not present.

– within <cp:ruleset> one <cp:rule> element for communication forwarding as follows:

– <cp:conditions> element containing a <not-registered> element and not containing a <rule-deactivated> element

– <cp:actions> element containing <forward-to> element containing <target> element

– value of target address to be px_XCAP_TargetUri

3. SS shall check that after step 9 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <communication-diversion> element with "active" attribute being set "false"

– <communication-diversion> element with "active" attribute being set "true" or with “active” attribute not present.

– within <cp:ruleset> one <cp:rule> element found at step 2 for Communication Diversion as follows:

– <cp:conditions> element containing a <rule-deactivated> element

15.10a Communication Forwarding on Not reachable

15.10a.1 Definition

Test to verify that the UE activates and deactivates IMS Multimedia Telephony Communication Forwarding for the case when user is not reachable. This process is described in 3GPP TS 24.604 [106].

15.10a.2 Conformance requirement

Generic requirements for Communication Forwarding can be found from Annexes F.1 and F.4.

[TS 24.604]:

Communication Forwarding on Subscriber Not Reachable (CFNRc)

The CFNRc service enables an user to have the network redirect all incoming communications, when the user is not reachable (e.g. there is no IP connectivity to the user’s terminal), to another user. The CFNRc service may operate on all communications, or just those associated with specified services. The user’s ability to originate communications is unaffected by the CFNRc simulation service.

As a service provider option, a subscription option can be provided to enable the user to receive an indication that the CFNRc service has been activated. This indication may be provided when the user originates a communication if the CFNRc service has been activated for the user and for the service requested for the communication.

Reference(s)

3GPP TS 24.604 [106]

15.10a.3 Test purpose

1) To verify that the UE can request activation of Communication Forwarding (when the called user is not reachable) with a correctly composed HTTP PUT request; and

2) To verify that the UE can request deactivation of Communication Forwarding; and

15.10a.4 Method of test

Initial conditions

SS is configured with the HTTP Digest password for XCAP or shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE.

If the UE uses GAA as XCAP authentication scheme, GAA bootstrapping exchange has been performed according to annex C.29.2.

Test procedure

The generic test procedure according to annex C.29.1 is applied:

At step 1 activation of Communication Forwarding on Not reachable;

At step 5b, SS delivers a simservs document as specified in TS 24.604 [106] cl 4.9, including a non-empty rule set. Specifically, the SS includes the following:

<?xml version="1.0" encoding="UTF-8"?>

<simservs

xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap"

xmlns:cp="urn:ietf:params:xml:ns:common-policy"

xmlns:ocp="urn:oma:xml:xdm:common-policy">

<communication-diversion active="true">

<cp:ruleset>

<cp:rule id="rule1">

<cp:conditions>

<not-reachable/>

<rule-deactivated/>

</cp:conditions>

<cp:actions>

<forward-to>

px_XCAP_TargetUri

</target>

<notify-caller>true</notify-caller>

</forward-to>

</cp:actions>

</cp:rule>

</cp:ruleset>

</communication-diversion>

</simservs>

At step 7 deactivation of Communication Forwarding on Not reachable is respectively triggered at the UE.

15.10a.5 Test requirements

1. SS shall check that the UE can authenticate itself correctly with the authentication scheme that the UE supports:

– HTTP Digest authentication (see Annex C.29.1 step 2 NOTE 1) or

– GAA based authentication as specified in TS 33.222 [121] and TS 24.109 [119] (see Annex C.29.2).

2. SS shall check that after Annex C.29.1 step 6 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <communication-diversion> element with "active" attribute set as "true" or with “active” attribute not present.

– within <cp:ruleset> one <cp:rule> element for communication forwarding as follows:

– <cp:conditions> element containing a <not-reachable> element and not containing a <rule-deactivated> element

– <cp:actions> element containing <forward-to> element containing <target> element

– value of target address to be px_XCAP_TargetUri

3. SS shall check that after step 9 the simservs document stored in the SS contains the following pieces of information supplied by the UE:

– <communication-diversion> element with "active" attribute being set "false"

– <communication-diversion> element with "active" attribute set as "true" or with “active” attribute not present.

– within <cp:ruleset> one <cp:rule> element found at step 2 for communication forwarding as follows:

– <cp:conditions> element containing a <rule-deactivated> element

15.11 MO Call Hold without announcement

15.11.1 Definition

Test to verify that the UE correctly performs IMS mobile originated call hold and resume. This process is described in 3GPP TS 24.610 [108].

15.11.2 Conformance requirement

[TS 24.610 clause 4.5.2.1]:

In addition to the application of procedures according to 3GPP TS 24.229, the following procedures shall be applied at the invoking UE in accordance with RFC 3264.

If individual media streams are affected, the invoking UE shall generate a new SDP offer where:

– for each media stream that is to be held, the SDP offer that contains:

– an "inactive" SDP attribute if the stream was previously set to "recvonly" media stream; or

– a "sendonly" SDP attribute if the stream was previously set to "sendrecv" media stream;

– for each media stream that is to be resumed, the SDP offer contains:

– a "recvonly" SDP attribute if the stream was previously an inactive media stream; or

– a "sendrecv" SDP attribute if the stream was previously a sendonly media stream, or the attribute may be omitted, since sendrecv is the default; or

– for each media stream that is unaffected, the media parameters in the SDP offer remain unchanged from the previous SDP offer.

If all the media streams are to be held, the invoking UE shall generate an SDP offer containing a session level direction attribute, or separate media level direction attributes, in the SDP that is set to:

– "inactive" if the streams were previously set to "recvonly" media streams; or

– "sendonly" if the streams were previously set to "sendrecv" media streams; or

If all the media streams that shall be resumed, the invoking UE shall generate a session level direction attribute, or separate media level direction attributes, in the SDP that is set to:

– "recvonly" if the streams were previously inactive media streams; or

– "sendrecv" if the streams were previously sendonly media streams, or the attribute may be omitted, since sendrecv is the default.

Then the UE shall send the generated SDP offer in a re-INVITE request (or UPDATE request) to the remote UE.

[TS 26.114 clause 7.3.1]:

RTCP packets should be sent for all types of multimedia sessions to enable synchronization with other RTP transported media, remote end-point aliveness information, monitoring of the transmission quality, and carriage of feedback messages such as TMMBR for video and RTCP APP for speech. Point-to-point speech only sessions may not require these functionalities and may therefore turn off RTCP by setting the SDP bandwidth modifiers (RR and RS) to zero. When RTCP is turned off (for point-to-point speech only sessions) and the media is put on hold, the MTSI client should re-negotiate the RTCP bandwidth with SDP bandwidth modifiers values greater than zero, and send RTCP packets to the other end. This allows the remote end to detect link aliveness during hold. When media is resumed, the resuming MTSI client should turn off the RTCP sending again through a re-negotiation of the RTCP bandwidth with SDP bandwidth modifiers equal to zero.

[TS 24.229 clause 6.1.1]:

If the media line in the SDP indicates the usage of RTP/RTCP, and if the UE is configured to request an RTCP bandwidth level for the session is different than the default RTCP bandwidth as specified in RFC 3556, then in addition to the "AS" bandwidth modifier in the media-level "b=" line, the UE shall include two media-level "b=" lines, one with the "RS" bandwidth modifier and the other with the "RR" bandwidth modifier as described in RFC 3556 to specify the required bandwidth allocation for RTCP. The bandwidth-value in the b=RS: and b=RR: lines may include transport overhead as described in subclause 6.1 of RFC 3890.

For other media streams the "b=" media descriptor may be included. The value or absence of the "b=" parameter will affect the assigned QoS which is defined in or 3GPP 29.213.

NOTE 1: In a two-party session where both participants are active, the RTCP receiver reports are not sent, therefore, the RR bandwidth modifier will typically get the value of zero.

Reference(s)

3GPP TS 24.610 [108], 3GPP TS 24.229 [10]

15.11.3 Test purpose

1) To verify that the invoking UE puts the call on hold with a correct exchange of SIP/SDP protocol signalling messages; and

2) To verify that the invoking UE is able to resume the call with a correct exchange of SIP/SDP protocol signalling messages.

15.11.4 Method of test

Initial conditions

UE contains either ISIM and USIM applications or only USIM application on UICC. UE has discovered P-CSCF, registered to IMS services and set up the MO call, by executing the generic test procedure in Annex C.2 or C.2a (GIBA only) up to the last step and thereafter executing the generic test procedure in TS 36.508 [94] table 4.5A.6.3-1 steps 1 to 14 for a UE with E-UTRA support (TS 34.229-2 [5] A.18/1).

Test procedure

1) Call hold is initiated on the UE. SS waits for the UE to send an INVITE or UPDATE request with a SDP offer

2) If the UE sent an INVITE request in step 1, SS responds to it with a 100 Trying response. No such response is sent for UPDATE.

3) SS responds to the INVITE or UPDATE request with a valid 200 OK response.

4) If the UE sent an INVITE request in step 1, SS waits for the UE to send an ACK to acknowledge receipt of the 200 OK for INVITE.

5) Call resume is initiated on the UE. SS waits for the UE to send an INVITE or UPDATE request with a SDP offer

6) If the UE sent an INVITE request in step 5, SS responds to it with a 100 Trying response. No such response is sent for UPDATE.

7) SS responds to the INVITE or UPDATE request with a valid 200 OK response.

8) If the UE sent an INVITE in step 5, SS waits for the UE to send an ACK to acknowledge receipt of the 200 OK for INVITE.

9) Call is released on the UE. SS waits for the UE to send a BYE request.

10) SS responds to the BYE request with valid a 200 OK response.

Expected sequence

Step	Direction		Message	Comment
	UE	SS
			User initiates holding the call
1-4			Steps 1-4 specified in annex C.8 to hold the call
			User initiates resuming the call
5-8			Steps 1-4 specified in annex C.8 to resume the call
			User initiates releasing the call
9	🡪		BYE	The UE releases the call with BYE
10	🡨		200 OK	The SS sends 200 OK for BYE

Specific Message Contents

Messages in Step 1-4

Use messages according to annex C.8 to put the call on hold.

Messages in Step 5-8

Use messages according to annex C.8 to resume the call.

15.11.5 Test requirements

SS must check that if the UE uses IMS security, it sends all the requests over the security associations set up during registration, in accordance to 3GPP TS 24.229 [10], clause 5.1.1.5.1.

Step 1: the UE shall send an INVITE or UPDATE request with correct content. The UE shall include the same lines in the SDP body as specified call hold in step 1 of annex C.8.

Step 5: the UE shall send an INVITE or UPDATE request with correct content. The UE shall include the same lines in the SDP body as specified for call resume in step 1 of annex C.8.

15.11a MO Video Call Hold without announcement

15.11a.1 Definition

Test to verify that the UE correctly performs IMS mobile originated video call hold and resume. This process is described in 3GPP TS 24.610 [108].

15.11a.2 Conformance requirement

[TS 24.610 clause 4.5.2.1]:

In addition to the application of procedures according to 3GPP TS 24.229 [1] , the following procedures shall be applied at the invoking UE in accordance with RFC 3264 [4].

A UE shall not invoke the HOLD service on a dialog associated with an emergency call the UE has initiated.