H.12 Call Control

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.12.1 Originating – 503 Service Unavailable / Fixed Broadband Access

H.12.1.1 Definition

When a server is temporarily unable to process an INVITE request due to a temporary overloading or maintenance of the server sends a 503 Service Unavailable response. The server may indicate when the service will be available again in a Retry-After header field. This process is described in 3GPP TS 24.229 [10], clause 5.1.3.1.

H.12.1.2 Conformance requirement

Upon receiving a 503 (Service Unavailable) response to an initial INVITE request containing a Retry-After header, then the originating UE shall not automatically reattempt the request until after the period indicated by the Retry-After header contents.

Reference(s)

3GPP TS 24.229 [10], clause 5.1.3.1.

H.12.1.3 Test purpose

Verify that UE does not automatically reattempt the request until the period indicated by the Retry-After header contents. When a server is temporarily unable to process an INVITE request due to a temporary overloading or maintenance of the server, sends a 503 Service Unavailable response. The server may indicate when the service will be available again in a Retry-After header field.

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

For value of T see specific message content for 503 (Service Unavailable) message specified in Annex A.4.2.

1) The UE initiates and successfully completes IMS registration. as per Annex C.2b.

2) Steps 1-3 of expected sequence as defined in Annex C.21c.

5) The SS responds with a 503 (Service Unavailable) response with the Retry-After header set to T.

6) The SS waits for the UE to send an ACK to acknowledge the reception of the 503 (Service Unavailable) response.

7) SS waits for a duration of time T and checks that the UE does not reattempt sending the INVITE request.

8) After the time T the UE may reattempt sending the INVITE.

Expected sequence

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

Step	Direction		Message	Comment
	UE	SS
1-3			Steps 1, 2 and 3 defined in annex C.21c	Originating MTSI voice call over Fixed Broadband Access
4	🡨		503 Service Unavailable	Including Retry-After header with period set to T
5	🡪		ACK	The UE acknowledges the reception of the 503 (Service Unavailable) response
6				The SS waits for a duration of time T and checks that the UE does not re-send the INVITE request
7			Step 2 defined in annex C.21c	Optional

Specific Message Contents

Steps 1 – 3 as specified in annex C.21c

503 Service Unavailable (Step 4)

Use the default message “503 Service Unavailable” in annex A.4.2.

H.12.1.5 Test requirements

At step 6 the UE shall not reattempt the INVITE request before time T from the time the SS receives the ACK from the UE in step 5.

H.12.2 Originating – 504 Server Time-out / Fixed Broadband Access

H.12.2.1 Definition

When the S-CSCF is temporarily unable to process an INVITE as the S-CSCF does not have the user profile or does not trust the data that it has (e.g. due to restart), the S-CSCF can reject the request by returning a 504 (Server Time-out) response to the UE with specific content as specified in [10] clause 5.4.3.2. As a result the UE will initiate restoration procedures by performing an initial registration.

H.12.2.2 Conformance requirement

In the event the UE receives a 504 (Server Time-out) response containing:

1) a P-Asserted-Identity header field set to a value equal to a URI:

a) from the Service-Route header field value received during registration; or

b) from the Path header field value received during registration; and

2) a Content-Type header field set according to subclause 7.6 (i.e. "application/3gpp-ims+xml"), independent of the value or presence of the Content-Disposition header field, independent of the value or presence of Content-Disposition parameters, then the default content disposition, identified as "3gpp-alternative-service", is applied as follows:

a) if the 504 (Server Time-out) response includes an IM CN subsystem XML body as described in subclause 7.6 with the <ims-3gpp> element, including a version attribute, with the <alternative-service> child element:

a) with the <type> child element set to "restoration" (see table 7.7AA); and

b) with the <action> child element set to "initial-registration" (see table 7.7AB);

then the UE:

– shall initiate restoration procedures by performing an initial registration as specified in subclause 5.1.1.2; and

– may provide an indication to the user based on the text string contained in the <reason> child element of the <alternative-service> child element of the <ims-3gpp> element.

Reference(s)

3GPP TS 24.229[10], clause 5.1.2A.1.6

H.12.2.3 Test purpose

To verify that when the UE receives a 504 (Server Time-out) response to an INVITE request containing a P-Asserted-Identity header field set to a value equal to a URI from the Service-Route header field value received during registration and the rest of the message is set as described in [10] subclause 5.1.2A.1.6, then the UE initiates restoration procedures by performing an initial registration as specified in [10] subclause 5.1.1.2.

H.12.2.4 Method of test

Initial conditions

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

Test procedure applicable

1) The UE initiates and successfully completes IMS registration. as per Annex C.2b.

2) Steps 1-3 of expected sequence as defined in Annex C.21b.

5) The SS responds with a 504 (Server Time-out) response.

6) The SS waits for the UE to send an ACK to acknowledge the reception of the 504 (Server Time-out) response.

7-14) As specified in steps 4-11 annex C.2b.

Expected sequence

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

Step	Direction		Message	Comment
	UE	SS
1-2			Steps 1-2 defined in annex C.21b	Originating MTSI voice call over Fixed Broadband Access
3	🡨		504 Server Time-out	Set as per the specific message contents.
4	🡪		ACK	The UE acknowledges the reception of the 504 (Server Time-out) response
5-12			Step 2 defined in annex C.2b	The UE performs an initial registration

Specific Message Contents

Steps 1 – 2 as specified in annex C.21b

504 Server Time-out (Step 3)

Use the default message “504 Server Time-out” in Annex A.4.6

ACK (Step 4)

As specified in annex A.2.7.

Steps 5-12

As specified in annex C.2b

H.12.2.5 Test requirements

After step 3 the UE shall perform an initial registration.

H.12.3 Originating MTSI Voice Call Successful with preconditions / Fixed Broadband Access

H.12.3.1 Definition

Test to verify that the UE correctly performs IMS UE originated voice call setup and release when using IMS Multimedia Telephony with preconditions.

H.12.3.2 Conformance requirement

[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 subclause 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 subclause 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 "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the precondition mechanism" and is defined in RFC 3312 as updated by RFC 4032.

The precondition mechanism should be supported by the originating UE.

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

NOTE 1: The originating UE can decide if local resource reservation is required based on e.g. application requirements, current access network capabilities, local configuration, etc.

In order to allow the peer entity to reserve its required resources, an originating UE supporting the precondition mechanism should make use of the precondition mechanism, even if it 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.

Upon generating an initial INVITE request using the precondition mechanism, the UE should not indicate the requirement for the precondition mechanism by using the Require header mechanism.

NOTE 2: If an UE chooses to require the precondition mechanism, i.e. if it indicates the "precondition" option tag within the Require header, the interworking with a remote UE, that does not support the precondition mechanism, is not described in this specification.

NOTE 3: Table A.4 specifies that UE support of forking is required in accordance with RFC 3261. The UE can accept or reject any of the forked responses, for example, if the UE is capable of supporting a limited number of simultaneous transactions or early dialogs.

Upon successful reservation of local resources the UE shall confirm the successful resource reservation (see subclause 6.1.2) within the next SIP request.

NOTE 4: In case of the precondition mechanism being used on both sides, this confirmation will be sent in either a PRACK request or an UPDATE request. In case of the precondition mechanism not being supported on one or both sides, alternatively a reINVITE request can be used for this confirmation, in case the terminating UE does not support the PRACK request (as described in RFC 3262) and does not support the UPDATE request (as described in RFC 3311).

….

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.

[TS 24.229, clause 6.1.1]:

The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the precondition mechanism" and is defined in RFC 3312 as updated by RFC 4032.

In order to authorize the media streams, the P-CSCF and S-CSCF have to be able to inspect the SDP payloads. Hence, the UE shall not encrypt the SDP payloads.

During session establishment procedure, SIP messages shall only contain SDP payload if that is intended to modify the session description, or when the SDP payload must be included in the message because of SIP rules described in RFC 3261.

…

For "video" and "audio" media types that utilize the RTP/RTCP, the UE shall specify the proposed bandwidth for each media stream utilizing the "b=" media descriptor and the "AS" bandwidth modifier in the SDP.

…

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 3GPP TS 29.208.

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.

The UE shall include the MIME subtype "telephone-event" in the "m=" media descriptor in the SDP for audio media flows that support both audio codec and DTMF payloads in RTP packets as described in RFC 4733.

The UE shall inspect the SDP contained in any SIP request or response, looking for possible indications of grouping of media streams according to RFC 3524 and perform the appropriate actions for IP-CAN bearer establishment for media according to IP-CAN specific procedures (see subclause B.2.2.5 for IP-CAN implemented using GPRS).

If resource reservation is needed, the UE shall start reserving its local resources whenever it has sufficient information about the media streams, media authorization and used codecs available.

NOTE 2: Based on this resource reservation can, in certain cases, be initiated immediately after the sending or receiving of the initial SDP offer.

…

[TS 24.229, clause 6.1.2]:

An INVITE request generated by a UE shall contain a SDP offer and at least one media description. The SDP offer shall reflect the calling user’s terminal capabilities and user preferences for the session.

If the desired QoS resources for one or more media streams have not been reserved at the UE when constructing the SDP offer, the UE shall:

– indicate the related local preconditions for QoS as not met, using the segmented status type, as defined in RFC 3312 and RFC 4032, as well as the strength-tag value "mandatory" for the local segment and the strength-tag value "optional" for the remote segment, if the UE supports the precondition mechanism (see subclause 5.1.3.1); and,

– set the related media streams to inactive, by including an "a=inactive" line, according to the procedures described in RFC 4566, unless the UE knows that the precondition mechanism is supported by the remote UE.

NOTE 1: When setting the media streams to the inactive mode, the UE can include in the first SDP offer the proper values for the RS and RR modifiers and associate bandwidths to prevent the receiving of the RTCP packets, and not send any RTCP packets.

If the desired QoS resources for one or more media streams are available at the UE when the initial SDP offer is sent, the UE shall indicate the related local preconditions as met, using the segmented status type, as defined in RFC 3312 and RFC 4032, as well as the strength-tag value "mandatory" for the local segment and the strength-tag value "optional" for the remote segment, if the UE supports the precondition mechanism (see subclause 5.1.3.1).

NOTE 2: If the originating UE does not support the precondition mechanism it will not include any precondition information in SDP.

…

Upon generating the SDP offer for an INVITE request generated after receiving a 488 (Not Acceptable Here) response, as described in subclause 5.1.3.1, the UE shall include SDP payload containing a subset of the allowed media types, codecs and other parameters from the SDP payload of all 488 (Not Acceptable Here) responses related to the same session establishment attempt (i.e. a set of INVITE requests used for the same session establishment). The UE shall order the codecs in the SDP payload according to the order of the codecs in the SDP payload of the 488 (Not Acceptable Here) response.

NOTE 3: The UE can attempt a session establishment through multiple networks with different policies and potentially can need to send multiple INVITE requests and receive multiple 488 (Not Acceptable Here) responses from different CSCF nodes. The UE therefore takes into account the SDP contents of all the 488 (Not Acceptable Here) responses received related to the same session establishment when building a new INVITE request.

Upon confirming successful local resource reservation, the UE shall create a SDP offer in which:

– the related local preconditions are set to met, using the segmented status type, as defined in RFC 3312 and RFC 4032; and

– the media streams previously set to inactive mode are set to active (sendrecv, sendonly or recvonly) mode.

Upon receiving an SDP answer, which includes more than one codec for one or more media streams, the UE shall send an SDP offer at the first possible time, selecting only one codec per media stream.

Reference(s)

3GPP TS 24.229[10], clauses 5.1.2A.1, 5.1.2A.1.2, 5.1.2A.1.5, 5.1.3.1, 6.1.1 and 6.12.

H.12.3.3 Test purpose

1) To verify that when Originating a Voice call the UE performs correct exchange of SIP protocol signalling messages for setting up the session; and

2) To verify that within SIP signalling the UE performs the correct exchange of SDP messages for negotiating media and indicating preconditions for optional resource reservation (as described by 3GPP TS 24.229 [10], clause 6.1).

3) To verify that the UE is able to release the call.

H.12.3.4 Method of test

Initial conditions

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

Expected sequence

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

Step	Direction		Message	Comment
	UE	SS
1-13			Steps defined in annex C.21b	MTSI Originating speech call.
13A			The UE is triggered by MMI to release the call
14	🡪		BYE	The UE releases the call with BYE
15	🡨		200 OK	The SS sends 200 OK for BYE

Specific Message Contents

Steps 1 – 13 as specified in annex C.21b

BYE (Step 14)

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

200 OK for BYE (Step 15)

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

H.12.3.5 Test requirements

SS must check that if the UE uses SIP Digest and it sends all the requests in accordance to 3GPP TS 24.229 [10], clause 5.1.1.5.1.

Step 14: the UE shall send a BYE request with the correct content, according to common message definitions.

H.12.4 Originating MTSI Voice call without preconditions / Fixed Broadband Access

H.12.4.1 Definition

Test to verify that the UE correctly performs IMS UE originated voice call setup and release when using IMS Multimedia Telephony without preconditions.

H.12.4.2 Conformance requirement

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

– 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:

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.

….

1) acknowledge the response with an ACK request; and

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

[TS 24.229, clause 6.1.1]:

In order to authorize the media streams, the P-CSCF and S-CSCF have to be able to inspect the SDP payloads. Hence, the UE shall not encrypt the SDP payloads.

…

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 3GPP TS 29.208.

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.

If resource reservation is needed, the UE shall start reserving its local resources whenever it has sufficient information about the media streams, media authorization and used codecs available.

NOTE 2: Based on this resource reservation can, in certain cases, be initiated immediately after the sending or receiving of the initial SDP offer.

…

[TS 24.229, clause 6.1.2]:

…

NOTE 2: If the originating UE does not support the precondition mechanism it will not include any precondition information in SDP.

…

Reference(s)

3GPP TS 24.229[10], clauses 5.1.2A.1, 5.1.2A.1.2, 5.1.2A.1.5, 5.1.3.1, 6.1.1 and 6.12.

H.12.4.3 Test purpose

1) To verify that when Originating a Voice call the UE performs correct exchange of SIP protocol signalling messages for setting up the session; and

2) To verify that within SIP signalling the UE performs the correct exchange of SDP messages for negotiating media (as described by 3GPP TS 24.229 [10], clause 6.1).

3) To verify that the UE is able to release the call.

H.12.4.4 Method of test

Initial conditions

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

Test procedure

1-9) UE executes the procedures defined in annex C.2b steps 1 to 9.

Expected sequence

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

Step	Direction		Message	Comment
	UE	SS
1-8			Steps defined in annex C.21c	MTSI Originating speech call.
9			The UE is triggered by MMI to release the call
10	🡪		BYE	The UE releases the call with BYE
11	🡨		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

Steps 1 – 8 as specified in annex C.21c

BYE (Step 10)

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

200 OK for BYE (Step 11)

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

H.12.4.5 Test requirements

SS must check that if the UE uses SIP Digest and it sends all the requests in accordance to 3GPP TS 24.229 [10], clause 5.1.1.5.1.

Step 10: the UE shall send a BYE request with the correct content, according to common message definitions.

H.12.5 Terminating MTSI Voice call with preconditions / Fixed Broadband Access

H.12.5.1 Definition and applicability

Test to verify that the UE correctly performs IMS mobile terminated speech call setup when using IMS Multimedia Telephony with preconditions. This process is described in 3GPP TS 24.229 [10], clauses 5.1.2A.2 and 5.1.4.1. The test case is applicable for Fixed Broadband Access.

H.12.5.2 Conformance requirement

[TS 24.229, clause 5.1.2A.2]:

The procedures of this subclause are general to all requests and responses, except those for the REGISTER method.

Where a security association or TLS session exists, the UE shall discard any SIP request that is not protected by the security association or TLS session and is received from the P-CSCF outside of the registration and authentication procedures. The requirements on the UE within the registration and authentication procedures are defined in subclause 5.1.1.

If an initial request contains an Accept-Contact header field containing the g.3gpp.icsi-ref media feature tag with an ICSI value, the UE should invoke the IMS application that is the best match for the ICSI value.

If an initial request contains an Accept-Contact header field containing the g.3gpp.iari-ref media feature tag with an IARI value the UE should invoke the IMS application that is the best match for the IARI value.

The UE can receive multiple ICSI values, IARI values or both in an Accept-Contact header field. In this case it is up to the implementation which of the multiple ICSI values or IARI values the UE takes action on.

NOTE 1: The application verifies that the contents of the request (e.g. SDP media capabilities, Content-Type header field) are consistent with the ICSI value in the g.3gpp.icsi-ref media feature tag and IARI value contained in the g.3gpp.iari-ref media feature tag.

If an initial request does not contain an Accept-Contact header field containing a g.3gpp.icsi-ref media feature tag or a g.3gpp.iari-ref media feature tag the UE shall invoke the application that is the best match based on the contents of the request (e.g. SDP media capabilities, Content-Type header field, media feature tag).

The UE can indicate privacy of the P-Asserted-Identity that will be generated by the P-CSCF in accordance with RFC 3323 [33], and the additional requirements contained within RFC 3325 [34].

NOTE 2: In the UE-terminating case, this version of the document makes no provision for the UE to provide a P-Preferred-Identity in the form of a hint.

NOTE 3: A number of header fields can reveal information about the identity of the user. Where, privacy is required, implementers should also give consideration to other header fields that can reveal identity information. RFC 3323 [33] subclause 4.1 gives considerations relating to a number of header fields.

The UE shall not include its "+sip.instance" header field parameter in the Contact header field in its non-register requests and responses except when the request or response is guaranteed to be sent to a trusted intermediary that will remove the "+sip.instance" header field parameter prior to forwarding the request or response to the destination.

NOTE 4: Such trusted intermediaries include an AS that all such requests as part of an application or service traverse. In order to ensure that all requests or responses containing the "+sip.instance" header field parameter are forwarded via the trusted intermediary the UE needs to have first verified that the trusted intermediary is present (e.g. first contacted via a registration or configuration procedure). Including the "+sip.instance" header field parameter containing an IMEI URN does not violate RFC 7254 [153] even when the UE requests privacy using RFC 3323 [33].

If the response includes a Contact header field, and the response is sent within an existing dialog, and the Contact address previously used in the dialog was a GRUU, then the UE should insert the previously used GRUU value in the Contact header field as specified in RFC 5627 [93].

…

NOTE 5: The above items 1 and 2 are mutually exclusive.

3) if the request is related to an IMS communication service that requires the use of an ICSI then the UE shall include in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 and RFC 3841 [56B] the ICSI value (coded as specified in subclause 7.2A.8.2), for the IMS communication service and then the UE may include the IARI value for any IMS application that applies for the dialog, (coded as specified in subclause 7.2A.9.2), that is related to the request in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3841 [56B]. The UE may also include other ICSI values that the UE is prepared to use for all dialogs with the originating UE(s) and other IARI values for the IMS application that is related to the IMS communication service; and

4) if the request is related to an IMS application that is supported by the UE when the use of an ICSI is not needed, then the UE may include the IARI value (coded as specified in subclause 7.2A.9.2), that is related to any IMS application and that applies for the dialog, in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3841 [56B].

After the dialog is established the UE may change the dialog capabilities (e.g. add a media or request a supplementary service) if defined for the IMS communication service as identified by the ICSI value using the same dialog. Otherwise, the UE shall initiate a new initial request to the other user.

If the UE did not insert a GRUU in the Contact header field then the UE shall include a port in the address in the Contact header field as follows:

– if IMS AKA or SIP digest with TLS is being used as a security mechanism, the protected server port value as in the initial registration; or

– if SIP digest without TLS is being used as a security mechanism, the port value of an unprotected port where the UE expects to receive subsequent mid-dialog requests. The UE shall set the unprotected port value to the port value used in the initial registration.

If the UE receives a Resource-Priority header field in accordance with RFC 4412 [16] in an initial request for a dialog, then the UE shall include the Resource-Priority header field in all requests associated with that dialog.

NOTE 6: For certain national implementations, signalling of a Resource-Priority header field to and from a UE is not required.

If available to the UE (as defined in the access technology specific annexes for each access technology), the UE shall insert a P-Access-Network-Info header field into any response to a request for a dialog, any subsequent request (except CANCEL requests) or response (except CANCEL responses) within a dialog or any response to a standalone method (see subclause 7.2A.4).

The UE shall not support RFC 7090 [209] (see table A.4, item A.4/116) and, in this version of the specification, the UE shall not perform any specific procedures beyond those defined in RFC 3261 [26] for the Priority header field.

NOTE 7: The mechanism specified in RFC 7090 [209] is based on the presence of a trust domain for the Priority header field in the operator’s network. The UE is not aware whether a trust domain for the Priority header field exists in the operator’s network.

[TS 24.229, clause 5.1.4.1]:

The preconditions mechanism should be supported by the terminating UE.

The handling of incoming initial INVITE requests at the terminating UE is mainly dependent on the following conditions:

– the specific service requirements for "integration of resource management and SIP" extension (hereafter in this subclause known as the precondition mechanism and defined in RFC 3312 [30] as updated by RFC 4032 [64], and with the request for such a mechanism known as a precondition); and

– the UEs configuration for the case when the specific service does not require the precondition mechanism.

If an initial INVITE request is received the terminating UE shall check whether the terminating UE requires local resource reservation.

NOTE 1: The terminating UE can decide if local resource reservation is required based on e.g. application requirements, current access network capabilities, local configuration, etc.

If local resource reservation is required at the terminating UE and the terminating UE supports the precondition mechanism, and:

a) the received INVITE request includes the "precondition" option-tag in the Supported header field or Require header field, the terminating UE shall make use of the precondition mechanism and shall indicate a Require header field with the "precondition" option-tag in responses that include SDP body or subsequent requests that include SDP body that it sends towards to the originating UE; or

b) the received INVITE request does not include the "precondition" option-tag in the Supported header field or Require header field, the terminating UE shall not make use of the precondition mechanism.

If local resource reservation is not required by the terminating UE and the terminating UE supports the precondition mechanism and:

a) the received INVITE request includes the "precondition" option-tag in the Supported header field and:

– the required resources at the originating UE are not reserved, the terminating UE shall use the precondition mechanism and shall indicate a Require header field with the "precondition" option-tag in responses that include SDP body or subsequent requests that include SDP body that it sends towards to the originating UE; or

– the required local resources at the originating UE and the terminating UE are available, the terminating UE may use the precondition mechanism;

c) the received INVITE request includes the "precondition" option-tag in the Require header field, the terminating UE shall use the precondition mechanism.

NOTE 2: Table A.4 specifies that UE support of forking is required in accordance with RFC 3261 [26].

NOTE 3: If the terminating UE does not support the precondition mechanism it will apply regular SIP session initiation procedures.

If the terminating UE requires a reliable alerting indication at the originating side, the UE shall send the 180 (Ringing) response reliably. If the received INVITE request indicated support for reliable provisional responses, but did not require their use, the terminating UE shall send provisional responses reliably only if the provisional response carries SDP or for other application related purposes that requires its reliable transport.

NOTE 4: Certain applications, services and operator policies might mandate the terminating UE to send a 199 (Early Dialog Terminated) provisional response (see RFC 6228 [142]) prior to sending a non-2xx final response to the INVITE request.

If the terminating UE uses the precondition mechanism, upon successful reservation of local resources:

– if the originating side requested confirmation for the result of the resource reservation (as defined in RFC 3312 [30]) at the terminating UE, the terminating UE shall confirm the successful resource reservation (see subclause 6.1.3) within an SIP UPDATE request; and

NOTE 5: Originating side requests confirmation for the result of the resource reservation at the terminating UE e.g. when an application server performs 3rd party call control. The request for confirmation for the result of the resource reservation at the terminating UE can be included e.g. in the SDP answer in the PRACK request.

– if the originating side did not request confirmation for the result of the resource reservation (as defined in RFC 3312 [30]) at the terminating UE, the terminating UE shall not confirm the successful resource reservation (see subclause 6.1.3) within an UPDATE request.

NOTE 6: The terminating UE can send an UPDATE request for reasons other than confirmation of the successful resource reservation.

If the terminating UE included an SDP offer or an SDP answer in a reliable provisional response to the INVITE request and both the terminating UE and the originating UE support UPDATE method, then in order to remove one or more media streams negotiated in the session for which a final response to the INVITE request has not been sent yet, the terminating UE sends an UPDATE request with a new SDP offer and delays sending of 200 (OK) response to the INVITE request till after reception of 200 (OK) response to the UPDATE request.

[TS 24.229, clause 6.1.1]:

The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the precondition mechanism" and is defined in RFC 3312 as updated by RFC 4032.

In order to authorize the media streams, the P-CSCF and S-CSCF have to be able to inspect the SDP payloads. Hence, the UE shall not encrypt the SDP payloads.

…

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 3GPP TS 29.208.

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.

If resource reservation is needed, the UE shall start reserving its local resources whenever it has sufficient information about the media streams, media authorization and used codecs available.

NOTE 2: Based on this resource reservation can, in certain cases, be initiated immediately after the sending or receiving of the initial SDP offer.

…

[TS 24.229, clause 6.1.3]:

When the BGCF receives an INVITE request that contains a Feature-Caps header field with the "+g.3gpp.home-visited" header field parameter, the BGCF shall decide based on local policy whether to perform loopback routeing for this request. The BGCF shall:

a) if loopback routeing is not to be performed for this request remove any "+g.3gpp.trf" or "+g.3gpp.home-visited" header field parameter from the Feature-Caps header field of the outgoing request;

b) if loopback routeing is applied for this request:

i) remove all entries in the Route header field;

ii) if a "+g.3gpp.trf" header field parameter with a parameter value containing a valid URI, is included in the Feature-Caps header field of the request, insert the URI in a Route header field;

iii) if a "+g.3gpp.trf" header field parameter, with a parameter value containing a valid URI is not included in the Feature-Caps header field of the request, insert a locally configured TRF address, associated with the visited network for this call (as identified in the "+g.3gpp.home-visited" header field parameter), in the Route header field;

iv) remove any "+g.3gpp.home-visited" header field parameter from the Feature-Caps header field of the outgoing request;

v) if included in the incoming request, remove the "+g.3gpp.trf" header field parameter from the Feature-Caps header field from the outgoing request;

vi) insert the "+g.3gpp.loopback" header field parameter, as specified in subclause 7.9A.4 in the Feature-Caps header field of the request, in accordance with RFC 6809 [190]. If providing the identifier of the home network is supported by the BGCF and the visited network, the BGCF may based on operator agreement insert the "+g.3gpp.loopback" header field parameter set to the identifier of the home network;

vii) remove the "orig-ioi" header field parameter received in the P-Charging-Vector header field, if present. The BGCF shall insert a type 1 "orig-ioi" header field parameter into the P-Charging-Vector header field and shall set the type 1 "orig-ioi" header field parameter to a value that identifies the home network of the served user (i.e. the network in which the BGCF resides). The BGCF shall not include the "term-ioi" header field parameter; and

viii) if the BGCF supports indicating the traffic leg associated with a URI as specified in RFC 7549 [225] and if an "iotl" SIP URI parameter is not included in the TRF URI in the Route header field, the BGCF if required by local policy, append an "iotl" URI parameter with a value set to "homeA-visitedA" to the URI in the Route header field; and

c) if the final decision on loopback routeing is deferred to a subsequent entity in the home network, a further BGCF, then, retain in the request a Feature-Caps header field with the "+g.3gpp.home-visited" header field parameter with the parameter value set to the identifier of the visited network. The BGCF is expected to know by means of network configuration that such a subsequent entity exists;

If the BGCF inserts its own Record-Route header field, the BGCF may require the periodic refreshment of the session to avoid hung states in the BGCF. If the BGCF requires the session to be refreshed, the BGCF shall apply the procedures described in RFC 4028 [58] clause 8.

NOTE: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality cannot automatically be granted, i.e. at least one of the involved UEs needs to support it.

If overlap signalling using the multiple-INVITE method is supported as a network option, several INVITE requests with the same Call ID and the same From header field (including "tag" header field parameter) can be received outside of an existing dialog. Such INVITE requests relate to the same call and the BGCF shall route such INVITE request received during a certain period of time to the same next hop.

If the BGCF inserted in the initial request for the dialog the header field parameters into the Feature-Caps header field then the BGCF shall include the header field parameters with the same parameter values into the Feature-Caps header field in any target refresh request for the dialog, and in each 1xx or 2xx response to target refresh request sent in the same direction.

Reference(s)

3GPP TS 24.229[10], clauses 5.1.2A.2, 5.1.4.1, 6.1.1 and 6.1.3.

H.12.5.3 Test purpose

1) To verify that, when initiating Terminating MTSI Voice call and UE needs to reserve resources, the UE performs correct exchange of SIP protocol signalling messages for setting up the session.

2) To verify that within SIP signalling the UE performs the correct exchange of SIP header and parameter contents.

3) To verify that within SIP signalling the UE performs the correct exchange of SDP contents.

4) To verify that the UE is able to release the call.

H.12.5.4 Method of test

Initial conditions

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

Test procedure

1-9) UE executes the procedures defined in annex C.2b steps 1 to 9.

Expected sequence

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

Step	Direction		Message	Comment
	UE	SS
1-15			Steps defined in annex C.11b	MTSI Terminating speech call over Fixed Broadband Access.

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

Specific Message Content

None.

H.12.5.5 Test requirements

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

H.12.6 Terminating MTSI Voice call without preconditions / Fixed Broadband Access

H.12.6.1 Definition

Test to verify that the UE correctly performs IMS fixed access terminated voice call setup when using IMS Multimedia Telephony without preconditions.

H.12.6.2 Conformance requirement