H.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

H.15.1 Originating Identification Presentation / Fixed Broadband Access

H.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].

H.15.1.2 Conformance requirement

As described in clause 15.1.2.

H.15.1.3 Test purpose

As described in clause 15.1.3.

H.15.1.4 Method of test

Initial conditions

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 the IP-CAN with xDSL, Fiber or Ethernet with SS. SS is configured with the HTTP Digest password for XCAP, related to the IMS private user identity (IMPI) configured on 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.

H.15.1.5 Test requirements

As described in clause 15.1.5.

H.15.2 Originating Identification Restriction / Fixed Broadband Access

H.15.2.1 Definition

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

H.15.2.2 Conformance requirement

As described in clause 15.2a.2.

H.15.2.3 Test purpose

As described in clause 15.2a.3.

H.15.2.4 Method of test

Initial conditions

Same as clause H.12.1 with the following addition:

The UE is configured for Originating Identification Restriction

Test procedure

As described in clause 15.2a.4, steps 1-14. Except, steps 2-13 replaced by steps 1-8 in C.21b.

H.15.2.5 Test requirements

As described in clause 15.2a.5.

H.15.3 Terminating Identification Presentation / Fixed Broadband Access

H.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].

H.15.3.2 Conformance requirement

As described in clause 15.3.2.

H.15.3.3 Test purpose

As described in clause 15.3.3.

H.15.3.4 Method of test

Initial conditions

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.

H.15.3.5 Test requirements

As described in clause 15.3.5.

H.15.4 Terminating Identification Restriction / Fixed Broadband Access

H.15.4.1 Definition

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

H.15.4.2 Conformance requirement

As described in clause 15.4a.2.

H.15.4.3 Test purpose

As described in clause 15.4a.3.

H.15.4.4 Method of test

Initial conditions

Same as clause H.12.6 with the following addition:

The UE is configured for Terminating Identification Restriction

Test procedure

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

Step	Direction		Message	Comment
	UE	SS
1-5			Steps 1-5 defined in annex C.11c	MTSI MT speech call.
6				Make UE accept the speech offer with Terminating Identification Restriction
7-8			Steps 7-8 defined in annex C.11c	MTSI MT speech call.

Specific Message Contents

180 Ringing (Step 3)

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 [136]

200 Ok (Step 7)

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 [136]

H.15.4.5 Test requirements

The UE shall send requests and responses as described in clause H.15.4.4.

H.15.5 Communication Forwarding unconditional / Fixed Broadband Access

H.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].

H.15.5.2 Conformance requirement

As described in clause 15.5.2.

H.15.5.3 Test purpose

As described in clause 15.5.3.

H.15.5.4 Method of test

Initial conditions

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 7 deactivation of Communication Forwarding unconditional is respectively triggered at the UE.

H.15.5.5 Test requirements

As described in clause 15.5.5.

H.15.6 Communication Forwarding on non Reply: activation / Fixed Broadband Access

H.15.6.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].

H.15.6.2 Conformance requirement

As described in clause 15.7.2.

H.15.6.3 Test purpose

As described in clause 15.7.3.

H.15.6.4 Method of test

Initial conditions

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 7 deactivation of Communication Forwarding on non Reply is respectively triggered at the UE.

H.15.6.5 Test requirements

As described in clause 15.7.5.

H.15.7 Communication Forwarding on non reply: Originating call initiation / Fixed Broadband Access

H.15.7.1 Definition

Test to verify that the MTSI UE Originating 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

H.15.7.2 Conformance requirement

As described in clause 15.8.2.

H.15.7.3 Test purpose

As described in clause 15.8.3.

H.15.7.4 Method of test

Initial conditions

UE is configured with the home domain name, public and private user identities and SIP Digest Credentials.

SS is configured with the home domain name, public and private user identities and SIP Digest Credentials. SS is listening to SIP default port 5060 for both UDP and TCP protocols. SS is able to perform MD5 authentication algorithm for that IMPI, according to 3GPP TS 33.203 [14] clause 6.1 and RFC 3310 [17]. SS has performed MD5 authentication with the UE and accepted the registration.

Test procedure

1-6) Steps 1-6, procedure C.21c.

7) SS responds to the INVITE with a valid 181 Call Is Being Forwarded response (simulate the UE to which call was forwarded)

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

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

10) SS responds to PRACK with 200 OK.

11) SS responds to the INVITE request with a 200 OK response.

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

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

14) SS responds to the BYE request with a 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-6			Steps 1-6 as defined in Annex C.21c
7	🡨		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
8	🡨		180 Ringing	The SS sends 180 Ringing response to the UE
9	🡪		PRACK	UE acknowledges the receipt of 180 response by sending PRACK.
10	🡨		200 OK	The SS responds PRACK with 200 OK.
11	🡨		200 OK	The SS responds INVITE with 200 OK to indicate that the virtual remote UE had answered the call
12	🡪		ACK	The UE acknowledges the receipt of 200 OK for INVITE
13	🡪		BYE	The UE releases the call with BYE
14	🡨		200 OK	The SS sends 200 OK for BYE

Specific Message Contents

181 Call is being forwarded (Step 7)

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

180 Ringing (Step 8)

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
To
tag	different tag must be used than the one used in steps 3-7 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 (8-14) in this test case.
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 (8-14) in this test case.
History-Info
hi-targeted-to-uri	Same value as in the 181 response of step 7
hi-index	Same value as in the 181 response of step 7
Content-Type
media-type	application/sdp
Message-body	Same contents as specified in step 4 annex C.21c. except for o-line: o=- 22222222 22222222 IN (addrtype) (unicast-address for new remote UE).

200 OK (Step 11)

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 180 response of step 8
History-Info
hi-targeted-to-uri	Same value as in the 181 response of step 7
hi-index	Same value as in the 181 response of step 7

H.15.7.5 Test requirements

The UE shall send requests and responses as described in clause H.15.7.4.

H.15.8 Communication Forwarding on Busy / Fixed Broadband Access

H.15.8.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].

H.15.8.2 Conformance requirement

As described in clause 15.9.2.

H.15.8.3 Test purpose

As described in clause 15.9.3.

H.15.8.4 Method of test

Initial conditions

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 7 deactivation of Communication Forwarding on Busy is respectively triggered at the UE.

H.15.8.5 Test requirements

As described in clause 15.9.5.

H.15.9 Communication Forwarding on Not logged-in / Fixed Broadband Access

H.15.9.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].

H.15.9.2 Conformance requirement

As described in clause 15.10.2.

H.15.9.3 Test purpose

As described in clause 15.10.3.

H.15.9.4 Method of test

Initial conditions

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 7 deactivation of Communication Forwarding on Not logged-in is respectively triggered at the UE.

H.15.9.5 Test requirements

As described in clause 15.10.5.

H.15.10 Communication Forwarding on Not reachable / Fixed Broadband Access

H.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 reachable. This process is described in 3GPP TS 24.604 [106].

H.15.10.2 Conformance requirement

As described in clause 15.10a.2.

H.15.10.3 Test purpose

As described in clause 15.10a.3.

H.15.10.4 Method of test

Initial conditions

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 7 deactivation of Communication Forwarding on Not reachable is respectively triggered at the UE.

H.15.10.5 Test requirements

As described in clause 15.10a.5.

H.15.11 Self-Configuration via SIP based procedure / Fixed Broadband Access

H.15.11.1 Definition

Test to verify that the UE correctly performs SIP-based user configuration. This process is described in 3GPP TS 24.238 [142].

H.15.11.2 Conformance requirement

[TS 24.238, clause 4.3.2]:

When performing SIP-based user configuration, the UE shall create a SIP URI, as described in RFC 4967 [4], with:

a) a dialstring, set to either the concatenation of feature code and the number to be provisioned or the feature code alone if no number information needs to be provided for the service; and

b) a "phone-context" parameter, set to the home network domain name.

The UE shall construct and initiate an appropriate INVITE in accordance with TS 24.229 [3] with the Request-URI set to the URI created above.

[TS 24.229, clause 5.1.2A.1]:

If SIP digest without TLS is used, the UE shall not include RFC 3329 [48] header field s in any SIP messages.

When SIP digest is in use, upon receiving a 407 (Proxy Authentication Required) response to an initial request, the originating UE shall:

– extract the digest-challenge parameters as indicated in RFC 2617 [21] from the Proxy-Authenticate header field;

– if the contained nonce value is associated to the realm used for the related REGISTER request authentication, store the contained nonce as a nonce value for proxy authentication associated to the same registration or registration flow (if the multiple registration mechanism is used) and shall delete any other previously stored nonce value for proxy authentication for this registration or registration flow;

– calculate the response as described in RFC 2617 [21] using the stored nonce value for proxy authentication associated to the same registration or registration flow (if the multiple registration mechanism is used); and

– send a new request containing a Proxy-Authorization header field in which the header field parameters are populated as defined in RFC 2617 [21] using the calculated response.

[TS 24.229, clause 5.1.2A.1.2]:

The UE may use non-international formats of E.164 addresses, including geo-local numbers and home-local numbers and other local numbers (e.g. private number), in the Request-URI.

Local numbering information is sent in the Request-URI in initials requests or stand alone transaction, using one of the following formats:

1) a tel-URI, complying with RFC 3966, with a local number followed by a "phone-context" tel URI parameter value.

2) a SIP URI, complying with RFC 3261, with the "user" SIP URI parameter set to "phone".

3) a SIP URI, complying with RFC 3261 and RFC 4967, with the "user" SIP URI parameter set to "dialstring".

The actual value of the URI depends on whether user equipment performs an analysis of the dial string input by the end user or not.

[TS 24.229, clause 5.1.2A.1.5]:

When the UE uses home-local number, the UE shall include in the "phone-context" tel URI parameter the home domain name in accordance with RFC 3966.

When the UE uses geo-local number, the UE shall:

– if access technology information available to the UE (i.e., the UE can insert P-Access-Network-Info header field into the request), include the access technology information in the "phone-context" tel URI parameter according to RFC 3966 as defined in clause 7.2A.10; and

– if access technology information is not available to the UE (i.e., the UE cannot insert P-Access-Network-Info header field into the request), include in the "phone-context" tel URI parameter the home domain name prefixed by the "geo-local" string according to RFC 3966 as defined in clause 7.2A.10.

When the UE uses other local numbers, than geo-local number or home local numbers , e.g. private numbers that are different from home-local number, the UE shall include a "phone-context" tel URI parameter set according to RFC 3966, e.g. if private numbers are used a domain name to which the private addressing plan is associated.

NOTE 1: The "phone-context" tel URI parameter value can be entered or selected by the subscriber, or can be a "pre-configured" value inserted by the UE, based on implementation.

NOTE 2: The way how the UE determines whether numbers in a non-international format are geo-local, home-local or relating to another network, is implementation specific.

NOTE 3: Home operator’s local policy can define a prefix string(s) to enable subscribers to differentiate dialling a geo-local number and/or a home-local number.

[TS 24.229, clause 5.1.3.1]:

The UE may initiate a session without the precondition mechanism if the originating UE does not require local resource reservation.

Upon generating an initial INVITE request using the precondition mechanism, the UE shall:

– indicate the support for reliable provisional responses and specify it using the Supported header mechanism; and

– indicate the support for the preconditions mechanism and specify it using the Supported header mechanism.

…

When a final answer is received for one of the early dialogues, the UE proceeds to set up the SIP session. The UE shall not progress any remaining early dialogues to established dialogs. Therefore, upon the reception of a subsequent final 200 (OK) response for an INVITE request (e.g., due to forking), the UE shall:

1) acknowledge the response with an ACK request; and

2) send a BYE request to this dialog in order to terminate it.

Reference(s)

TS 24.238[142], clause 4.3.2, TS 24.229[10], clause 5.1.2A.1, 5.1.2A.1.2, 5.1.2A.1.5, 5.1.3.1.

H.15.11.3 Test purpose

To verify that the UE can request activation of Communication Forwarding (unconditional) with a correctly composed INVITE request.

H.15.11.4 Method of test

Initial conditions

UE is configured with the home domain name, public and private user identities and SIP Digest Credentials.

SS is configured with the home domain name, public and private user identities and SIP Digest Credentials. SS is listening to SIP default port 5060 for both UDP and TCP protocols. SS is able to perform MD5 authentication algorithm for that IMPI, according to TS 33.203 [14] clause 6.1 and RFC 3310 [17]. SS has performed MD5 authentication with the UE and accepted the registration.

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 start SIP-based user configuration
2	->		INVITE	UE sends INVITE with Request-URI set as “*21#”
3	<-		200 OK	SS responds INVITE with 200 OK
4	->		ACK	UE acknowledges
5	->		BYE	The UE releases the call with BYE
6	<-		200 OK	The SS sends 200 OK for BYE

NOTE: The default messages contents in annex A are used with condition "SIP Digest without TLS for Fixed Broadband Access" when applicable.

Specific Message Contents

INVITE (Step 2)

Use the default message "INVITE for Originating Call" in annex A.2.1 with the following exceptions:

Header/param	Value/Remark
Request-Line
Method	INVITE
Request-URI	“*21#”
Message-body	The following SDP types and values. Session description: – v=0 – o=(username) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE) – s=(session name) – c=IN (addrtype) (connection-address for UE) [Note 1] – b=AS: (bandwidth-value) Time description: – t= (start-time) (stop-time) Media description: – m=audio (transport port) RTP/AVP (fmt) – c=IN (addrtype) (connection-address for UE) [Note 1] – b=AS: (bandwidth-value) – b=RS: (bandwidth-value) [Note 5] – b=RR: (bandwidth-value) [Note 5] Attributes for media: – a=rtpmap: (payload type) AMR/8000 [Note 6] – a=fmtp: (format) mode-change-capability=2; max-red= (att-field) [Note 7] – a=rtpmap: (payload type) telephone-event [Note 4] – a=ecn-capable-rtp: leap ect=0 [Note 2] – a=rtcp-fb: nack ecn* [Note 2] – a=rtcp-xr:ecn-sum [Note 2] – a=rtcp-rsize [Note 2] – a=ptime:20 – a=maxptime:240 Attributes for media security mechanism: – a=3ge2ae: requested [Note 3] – a=crypto:1 AES_CM_128_HMAC_SHA1_80inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz\|2^20\| 1:4FEC_ORDER=FEC_SRTP" [Note 3] Note 1: At least one "c=" field shall be present. Note 2: Attributes for ECN Capability may be present if the UE supports Explicit Congestion Notification. Note 3: Attributes for media plane security are present if the use of end-to-access-edge security is supported by UE. Note 4: a rate may be added to the “telephone-event” separated by “/” (e.g. “telephone-event/8000”) Note 5: The RR value must be greater than 0. The RS value can be any value. Note 6: The AMR channel number shall be “/1” or omitted. Note 7: values from 0 to 220 are allowed

H.15.11.5 Test requirements

The UE shall send requests and responses as described in clause H.15.11.4.