H.8 Registration

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.8.1 Initial registration / Fixed Broadband Access

H.8.1.1 Definition

Test to verify that the UE can correctly register to IMS services. The process consists of sending initial registration to S-CSCF via the P-CSCF discovered, authenticating the user and finally subscribing the registration event package for the registered default public user identity.

H.8.1.2 Conformance requirement

[TS 24.229, 5.1.1.1B.1]:

In case the UE contains neither an ISIM nor a USIM, but IMC is present the UE shall use preconfigured parameters in the IMC to initiate the registration to the IM CN subsystem and for authentication.

The following IMS parameters are assumed to be available to the UE:

– a private user identity;

– a public user identity; and

– a home network domain name to address the SIP REGISTER request to.

These parameters may not necessarily reside in a UICC.

The first public user identity in the list stored in the IMC is used in emergency registration requests.

[TS 24.229 Rel-12, clause 5.1.1.2.1]:

The initial registration procedure consists of the UE sending an unprotected REGISTER request and, if challenged depending on the security mechanism supported for this UE, sending the integrity-protected REGISTER request or other appropriate response to the challenge. The UE can register a public user identity with any of its contact addresses at any time after it has acquired an IP address, discovered a P-CSCF, and established an IP-CAN bearer that can be used for SIP signalling. However, the UE shall only initiate a new registration procedure when it has received a final response from the registrar for the ongoing registration, or the previous REGISTER request has timed out.

When registering any public user identity belonging to the UE, the UE shall either use an already active pair of security associations or a TLS session to protect the REGISTER requests, or register the public user identity via a new initial registration procedure.

When binding any one of its public user identities to an additional contact address via a new initial registration procedure, the UE shall follow the procedures described in RFC 5626 [92]. The set of security associations or a TLS session resulting from this initial registration procedure will have no impact on the existing set of security associations or TLS sessions that have been established as a result of previous initial registration procedures. However, if the UE registers any one of its public user identities with a new contact address via a new initial registration procedure and does not employ the procedures described in RFC 5626 [92], then the new set of security associations or TLS session shall replace any existing set of security association or TLS session.

If the UE detects that the existing security associations or TLS sessions associated with a given contact address are no longer active (e.g., after receiving no response to several protected messages), the UE shall:

– consider all previously registered public user identities bound to this security associations or TLS session that are only associated with this contact address as deregistered; and

– stop processing all associated ongoing dialogs and transactions that were using the security associations or TLS session associated with this contact address, if any (i.e. no further SIP signalling will be sent by the UE on behalf of these transactions or dialogs).

The UE shall send the unprotected REGISTER requests to the port advertised to the UE during the P-CSCF discovery procedure. If the UE does not receive any specific port information during the P-CSCF discovery procedure, or if the UE was pre-configured with the P-CSCF’s IP address or domain name and was unable to obtain specific port information, the UE shall send the unprotected REGISTER request to the SIP default port values as specified in RFC 3261 [26].

NOTE 1: The UE will only send further registration and subsequent SIP messages towards the same port of the P-CSCF for security mechanisms that do not require using negotiated ports for exchanging protected messages.

The UE shall extract or derive a public user identity, the private user identity, and the domain name to be used in the Request-URI in the registration, according to the procedures described in subclause 5.1.1.1A or subclause 5.1.1.1B. A public user identity may be input by the end user.

On sending an unprotected REGISTER request, the UE shall populate the header fields as follows:

a) a From header field set to the SIP URI that contains:

1) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, the main URI of the UE; else

2) the public user identity to be registered;

b) a To header field set to the SIP URI that contains:

1) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, the main URI of the UE; else

2) the public user identity to be registered;

c) a Contact header field set to include SIP URI(s) containing the IP address or FQDN of the UE in the hostport parameter. If the UE:

1) supports GRUU (see table A.4, item A.4/53);

2) supports multiple registrations;

3) has an IMEI available; or

4) has an MEID available;

the UE shall include a "+sip.instance" header field parameter containing the instance ID. Only the IMEI shall be used for generating an instance ID for a multi-mode UE that supports both 3GPP and 3GPP2 defined radio access networks.

NOTE 2: The requirement placed on the UE to include an instance ID based on the IMEI or the MEID when the UE does not support GRUU and does not support multiple registrations does not imply any additional requirements on the network.

If the UE supports multiple registrations it shall include "reg-id" header field parameter as described in RFC 5626 [92]. The UE shall include all supported ICSI values (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 and RFC 3840 [62] for the IMS communication services it intends to use, and IARI values (coded as specified in subclause 7.2A.9.2), for the IMS applications it intends to use in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3840 [62].

if the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Contact URI without a user portion and containing the "bnc" URI parameter;

d) a Via header field set to include the sent-by field containing the IP address or FQDN of the UE and the port number where the UE expects to receive the response to this request when UDPis used. For TCP, the response is received on the TCP connection on which the request was sent. For the UDP, the UE shall also include a "rport" header field parameter with no value in the Via header field. Unless the UE has been configured to not send keep-alives, and unless the UE is directly connected to an IP-CAN for which usage of NAT is not defined, it shall include a "keep" header field parameter with no value in the Via header field, in order to indicate support of sending keep-alives associated with the registration, as described in RFC 6223 [143];

NOTE 3: When sending the unprotected REGISTER request using UDP, the UE transmit the request from the same IP address and port on which it expects to receive the response to this request.

e) a registration expiration interval value of 600 000 seconds as the value desired for the duration of the registration;

NOTE 4: The registrar (S-CSCF) might decrease the duration of the registration in accordance with network policy. Registration attempts with a registration period of less than a predefined minimum value defined in the registrar will be rejected with a 423 (Interval Too Brief) response.

f) a Request-URI set to the SIP URI of the domain name of the home network used to address the REGISTER request;

g) the Supported header field containing the option-tag "path", and

1) if GRUU is supported, the option-tag "gruu"; and

2) if multiple registrations is supported, the option-tag "outbound".

h) if a security association or TLS session exists, and if available to the UE (as defined in the access technology specific annexes for each access technology), a P-Access-Network-Info header field set as specified for the access network technology (see subclause 7.2A.4);

i) a Security-Client header field to announce the media plane security mechanisms the UE supports, if any, labelled with the "mediasec" header field parameter specified in subclause 7.2A.7;

NOTE 5: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

j) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Require header field containing the option-tag "gin"; and

k) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Proxy-Require header field containing the option-tag "gin".

On receiving a 401 (Unauthorized) response to the REGISTER request, the UE shall:

a) if available, store the announcement of media plane security mechanisms the P-CSCF (IMS-ALG) supports labelled with the "mediasec" header field parameter specified in subclause 7.2A.7 and received in the Security-Server header field, if any. Once the UE chooses a media security mechanism from the list received in the Security-Server header field from the server, the UE may initiate that mechanism on a media level when it initiates new media in an existing session.

NOTE 6: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

On receiving the 200 (OK) response to the REGISTER request, the UE shall:

a) store the expiration time of the registration for the public user identities found in the To header field value and bind it either to the respective contact address of the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used);

NOTE 7: If the UE supports RFC 6140 [191] and performs the functions of an external attached network, the To header field will contain the main URI of the UE.

b) store as the default public user identity the first URI on the list of URIs present in the P-Associated-URI header field and bind it to the respective contact address of the UE and the associated set of security associations or TLS session;

NOTE 8: When using the respective contact address and associated set of security associations or TLS session, the UE can utilize additional URIs contained in the P-Associated-URI header field and bound it to the respective contact address of the UE and the associated set of security associations or TLS session, e.g. for application purposes.

c) treat the identity under registration as a barred public user identity, if it is not included in the P-Associated-URI header field;

d) store the list of service route values contained in the Service-Route header field and bind the list either to the contact address or to the registration flow and the associated contact address (if the multiple registration mechanism is used), and the associated set of security associations or TLS session over which the REGISTER request was sent;

NOTE 9: When multiple registration mechanism is not used, there will be only one list of service route values bound to a contact address. However, when multiple registration mechanism is used, there will be different list of service route values bound to each registration flow and the associated contact address.

NOTE 10: The UE will use the stored list of service route values to build a proper preloaded Route header field for new dialogs and standalone transactions (other than REGISTER method) when using either the respective contact address or to the registration flow and the associated contact address (if the multiple registration mechanism is used), and the associated set of security associations or TLS session.

e) if the UE indicated support for GRUU in the Supported header field of the REGISTER request then:

– if the UE did not use the procedures specified in RFC 6140 [191] for registration, find the Contact header field within the response that matches the one included in the REGISTER request. If this contains a "pub-gruu" header field parameter or a "temp-gruu" header field parameter or both, then store the value of those parameters as the GRUUs for the UE in association with the public user identity and the contact address that was registered; and

– if the UE used the procedures specified in RFC 6140 [191] for registration then find the Contact header field within the response that matches the one included in the REGISTER request. If this contains a "pub-gruu" header field parameter then store the value of the "pub-gruu" header field parameter for use for generating public GRUUs for registering UAs as specified in RFC 6140 [191]. If this contains a "temp-gruu-cookie" header field parameter then store the value of the "temp-gruu-cookie" header field parameter for use for generating temporary GRUUs for registering UAs as specified in RFC 6140 [191];

NOTE 11: When allocating public GRUUs to registering UAs the functionality within the UE that performs the role of registrar will add an "sg" SIP URI parameter that uniquely identifies that UA to the public GRUU it received in the "pub-gruu" header field parameter. The procedures for generating a temporary GRUU using the "temp-gruu-cookie" header field parameter are specified in subclause 7.1.2.2 of RFC 6140 [191].

f) if the REGISTER request contained the "reg-id" and "+sip.instance" Contact header field parameter and the "outbound" option tag in a Supported header field, the UE shall check whether the option-tag "outbound" is present in the Require header field:

– if no option-tag "outbound" is present, the UE shall conclude that the S-CSCF does not support the registration procedure as described in RFC 5626 [92], and the S-CSCF has followed the registration procedure as described in RFC 5627 [93] or RFC 3261 [26], i.e., if there is a previously registered contact address, the S-CSCF replaced the old contact address and associated information with the new contact address and associated information (see bullet e) above). Upon detecting that the S-CSCF does not support the registration procedure as defined in RFC 5626 [92], the UE shall refrain from registering any additional IMS flows for the same private identity as described in RFC 5626 [92]; or

NOTE 12: Upon replaces the old contact address with the new contact address, the S-CSCF performs the network initiated deregistration procedure for the previously registered public user identities and the associated old contact address as described in subclause 5.4.1.5. Hence, the UE will receive a NOTIFY request informing the UE about the deregistration of the old contact address.

– if an option-tag "outbound" is present, the UE may establish additional IMS flows for the same private identity, as defined in RFC 5626 [92];

g) if available, store the announcement of media plane security mechanisms the P-CSCF (IMS-ALG) supports labelled with the "mediasec" header field parameter specified in subclause 7.2A.7 and received in the Security-Server header field, if any. Once the UE chooses a media security mechanism from the list received in the Security-Server header field from the server, it may initiate that mechanism on a media level when it initiates new media in an existing session;

NOTE 13: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

h) if the Via header field contains a "keep" header field parameter with a value, unless the UE detects that it is not behind a NAT, start to send keep-alives associated with the registration towards the P-CSCF, as described in RFC 6223 [143];

i) if the 200 (OK) response includes a Feature-Caps header field, as specified in RFC 6809°[190], with "+g.3gpp.icsi-ref" header field parameter, then the UE may consider the values included in the "+g.3gpp.icsi-ref" header field parameter of the Feature-Caps header field of 200 (OK) response as supported by the IM subsystem for the established registration or registration flow (if the multiple registration mechanism is used); and

NOTE 14: The UE and related applications can use the ICSI values received in the Feature-Caps header field of 200 (OK) response to improve the user experience.

j) if the 200 (OK) response includes one or more Feature-Caps header fields containing the capability indicators listed in subclause 7.9A.7 that indicate the media capabilities supported by the IMS-AGW then the UE may consider this information when providing media options to the user or determining whether an application communication capability will be successful (e.g. if "sip.video" is not indicated then the UE might not offer the user the option to attempt to add video to the session).

NOTE 15: If media capability indication is not supported, no capability indicators listed in subclause 7.9A.7 are included and it can be assumed that all the media capabilities are supported.

On receiving a 305 (Use Proxy) response to the unprotected REGISTER request, unless otherwise specified in access specific annexes (as described in Annex B or Annex L), the UE shall:

a) ignore the contents of the Contact header field if it is included in the received message;

NOTE 16: The 305 response is not expected to contain a Contact header field.

b) release all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2;

c) initiate either a new P-CSCF discovery procedure as described in subclause 9.2.1, or select a new P-CSCF, if the UE was pre-configured with more than one P-CSCF’s IP addresses or domain names;

d) select a P-CSCF address, which is different from the previously used address, from the address list; and

e) perform the procedures for initial registration as described in subclause 5.1.1.2.

On receiving a 423 (Interval Too Brief) response to the REGISTER request, the UE shall:

– send another REGISTER request populating the registration expiration interval value with an expiration timer of at least the value received in the Min-Expires header field of the 423 (Interval Too Brief) response.

On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) or 600 (Busy Everywhere) response for an initial registration, the UE may attempt to perform initial registration again.

When the timer F expires at the UE, the UE may:

a) select a different P-CSCF address from the list of P-CSCF addresses discovered during the procedures described in subclause 9.2.1 or from its pre-configured list of P-CSCF’s IP addresses or domain names;

b) if no response has been received when attempting to contact all P-CSCFs known by the UE, get a new set of P-CSCF-addresses as described in subclause 9.2.1 unless otherwise specified in the access specific annexes (as described in Annex B or Annex L); and

c) perform the procedures for initial registration as described in subclause 5.1.1.2.

NOTE 17: It is an implementation option whether these actions are also triggered by other means than expiration of timer F, e.g. based on ICMP messages.

On receiving a 4xx, 5xx or 6xx response to the REGISTER request, whereby the response contains a Retry-After header field, the UE shall not automatically attempt an initial registration via the same IP-CAN and the same P-CSCF for the amount of time indicated in the Retry-After header field. If the UE is power cycled, the UE can attempt an initial registration. If no initial registration occurs within the time period indicated by the Retry-After header field, the counter of unsuccessful initial registration attempts is reset.

After a first unsuccessful initial registration attempt, if the Retry-After header field was not present and the initial registration was not performed as a consequence of a failed reregistration, the UE shall not wait more than 5 minutes before attempting a new registration.

After a maximum of 2 consecutive unsuccessful initial registration attempts, if the Retry-After header field was not present in failure responses of those unsuccessful initial registration attempts, the UE shall implement the mechanism defined in subclause 4.5 of RFC 5626 [92] for new registration attempts. The UE shall use the values of the parameters max-time and base-time, of the algorithm defined in subclause 4.5 of RFC 5626 [92]. If no values of the parameters max-time and base-time have been provided to the UE by the network, the default values defined in subclause 4.5 of RFC 5626 [92] shall be used.

The values of max-time and base-time may be provided by the network to the UE using OMA-DM with the management objects specified in 3GPP TS 24.167 [8G]. Other mechanisms may be used as well and are outside the scope of the present specification.

[TS 24.229, clause 5.1.1.2.3]:

On sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field as defined in RFC 2617 [21] unless otherwise specified in the access specific annexes, with:

– the "username" header field parameter, set to the value of the private user identity;

– the "realm" header field parameter, set to the domain name of the home network;

– the "uri" header field directive, set to the SIP URI of the domain name of the home network;

– the "nonce" header field parameter, set to an empty value; and

– the "response" header field parameter, set to an empty value;

b) the hostport parameter in the Contact header field with the port value of an unprotected port where the UE expects to receive subsequent requests; and

c) the sent-by field in the Via header field with the port value of an unprotected port where the UE expects to receive responses to the request.

The UE shall use the locally available public user identity, the private user identity, and the domain name to be used in the Request-URI in the registration. The method whereby the public user identity and private user identity are made available to the UE is outside the scope of this document (e.g. a public user identity could be input by the end user).

When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in subclause 5.1.1.5.4.

[TS 24.229, clause 5.1.1.5.4]:

On receiving a 401 (Unauthorized) response to the REGISTER request, and where the "algorithm" Authorization header field parameter is "MD5", the UE shall:

1) extract the digest-challenge parameters as indicated in RFC 2617 [21] from the WWW-Authenticate header field;

2) store the contained nonce value as the nonce for authentication associated to the same registration or registration flow (if the multiple registration mechanism is used) and delete any other previously stored nonce value for authentication for this registration or registration flow (if the multiple registration mechanism is used);

NOTE: The related registration flow or registration is identified by the couple instance-id and reg-id if the multiple registration mechanism is used or by contact address if not.

3) calculate digest-response parameters as indicated in RFC 2617 [21];

4) send another REGISTER request containing an Authorization header field. The header fields are populated as defined in subclause 5.1.1.2.3, with the addition that the UE shall include an Authorization header field containing a challenge response, constructed using the stored nonce value for authentication for the same registration or registration flow (if the multiple registration mechanism is used) "cnonce", "qop", and "nonce-count" header field parameters as indicated in RFC 2617 [21]. The UE shall set the Call-ID of the REGISTER request which carries the authentication challenge response to the same value as the Call-ID of the 401 (Unauthorized) response which carried the challenge. If SIP digest without TLS is used, the UE shall not include RFC 3329 [48] header fields with this REGISTER.

On receiving the 200 (OK) response for the REGISTER request, if the "algorithm" Authentication-Info header field parameter is "MD5", the UE shall authenticate the S-CSCF using the "rspauth" Authentication-Info header field parameter as described in RFC 2617 [21]. If the nextnonce field is present in the Authentication-Info header field the UE shall store the contained nonce value as the nonce for 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 authentication for this registration or registration flow (if the multiple registration mechanism is used).

[TS 24.229 Rel-12, clause 5.1.1.3]:

Upon receipt of a 2xx response to the initial registration, the UE shall subscribe to the reg event package for the public user identity registered at the user’s registrar (S-CSCF) as described in RFC 3680 [43] and RFC 6665 [28].

NOTE 1: If the UE supports RFC 6140 [191] and performs the functions of an external attached network, the subscription will be directed to the main URI, as described in RFC 6140 [191].

The UE shall subscribe to the reg event package upon registering a new contact address via an initial registration procedure. If the UE receives a NOTIFY request via the newly established subscription dialog and via the previously established subscription dialogs (there will be at least one), the UE may terminate the previously established subscription dialogs and keep only the newly established subscription dialog.

The UE shall use the default public user identity for subscription to the registration-state event package.

NOTE 2: The subscription information stored in the HSS ensures that the default public user identity is a SIP URI.

On sending a SUBSCRIBE request, the UE shall populate the header fields as follows:

a) a Request-URI set to the resource to which the UE wants to be subscribed to, i.e. to the SIP URI that is the default public user identity used for subscription;

b) a From header field set to the SIP URI that is the default public user identity used for subscription;

c) a To header field set to the SIP URI that is the default public user identity used for subscription;

d) an Event header field set to the "reg" event package;

e) an Expires header field set to 600 000 seconds as the value desired for the duration of the subscription;

f) void; and

g) void.

Upon receipt of a dialog establishing NOTIFY request, as specified in RFC 6665 [28], associated with the SUBSCRIBE request, the UE shall:

1) store the information for the established dialog;

2) store the expiration time as indicated in the "expires" header field parameter of the Subscription-State header field, if present, of the NOTIFY request. Otherwise the expiration time is retrieved from the Expires header field of the 2xx response to SUBSCRIBE request; and

3) follow the procedures specified in RFC 6665 [28].

If continued subscription is required, the UE shall automatically refresh the subscription by the reg event package, for a previously registered public user identity, either 600 seconds before the expiration time if the initial subscription was for greater than 1200 seconds, or when half of the time has expired if the initial subscription was for 1200 seconds or less. If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the UE shall still consider the original subscription valid for the duration of the most recently known "Expires" value according to RFC 6665 [28]. Otherwise, the UE shall consider the subscription invalid and start a new initial subscription according to RFC 6665 [28].

[TS 24.229, clause 5.1.2.1]:

Upon receipt of a 2xx response to the SUBSCRIBE request the UE shall maintain the generated dialog (identified by the values of the Call-ID header field, and the values of tags in To and From header fields).

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package the UE shall perform the following actions:

– if a state attribute "active", i.e. registered is received for one or more public user identities, the UE shall store the indicated public user identities as registered;

– if a state attribute "active" is received, and the UE supports GRUU (see table A.4, item A.4/53), then for each public user identity indicated in the notification that contains a <pub-gruu> element or a <temp-gruu> element or both (as defined in RFC 5628) then the UE shall store the value of those elements in association with the public user identity;

– if a state attribute "terminated", i.e. deregistered is received for one or more public user identities, the UE shall store the indicated public user identities as deregistered and shall remove any associated GRUUs.

NOTE 1: There may be public user identities which are automatically registered within the registrar (S-CSCF) of the user upon registration of one public user identity or when S-CSCF receives a Push-Profile-Request (PPR) from the HSS (as described in 3GPP TS 29.228) changing the status of a public user identity associated with a registered implicit set from barred to non-barred. Usually these automatically or implicitly registered public user identities belong to the same service profile of the user and they might not be available within the UE. The implicitly registered public user identities may also belong to different service profiles. The here-described procedures provide a different mechanism (to the 200 (OK) response to the REGISTER request) to inform the UE about these automatically registered public user identities.

NOTE 2: RFC 5628 provides guidance on the management of temporary GRUUs, utilizing information provided in the reg event notification.

[TS 24.229, clause 5.1.2A.1.1]:

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

When the UE sends any request using either a given contact address, or to the registration flow and the associated contact address the UE shall:

– if IMS AKA is in use as a security mechanism:

a) if the UE has not obtained a GRUU, populate the Contact header field of the request with the protected server port and the respective contact address; and

b) include the protected server port and the respective contact address in the Via header field entry relating to the UE;

– if SIP digest without TLS is in use as a security mechanism:

a) if the UE has not obtained a GRUU, populate the Contact header field of the request with the port value of an unprotected port and the contact address where the UE expects to receive subsequent mid-dialog requests; and

b) populate the Via header field of the request with the port value of an unprotected port and the respective contact address where the UE expects to receive responses to the request;

…

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 request for a dialog, any subsequent request (except ACK requests and CANCEL requests) or response (except CANCEL responses) within a dialog or any request for a standalone method (see subclause 7.2A.4).

NOTE 13: During the dialog, the points of attachment to the IP-CAN of the UE may change (e.g. UE connects to different cells). The UE will populate the P-Access-Network-Info header field in any request or response within a dialog with the current point of attachment to the IP-CAN (e.g. the current cell information).

The UE shall build a proper preloaded Route header field value for all new dialogs and standalone transactions. The UE shall build a list of Route header field values made out of the following, in this order:

a) the P-CSCF URI containing the IP address or the FQDN learnt through the P-CSCF discovery procedures; and

b) the P-CSCF port based on the security mechanism in use:

– if IMS AKA or SIP digest with TLS is in use as a security mechanism, the protected server port learnt during the registration procedure;

– if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled authentication is in use as a security mechanism, the unprotected server port used during the registration procedure;

c) and the values received in the Service-Route header field saved from the 200 (OK) response to the last registration or re-registration of the public user identity with associated contact address.

[TS 24.229, clause E.3.1.0]:

In order to reach IMS in some access networks, the UE may support:

– address and/or port number conversions provided by a NA(P)T or NA(P)T-PT as described in annex F and annex K; and

– UE requested FTT-IMS establishment procedure specified in 3GPP TS 24.322 [8Y].

If a UE supports one or both of these capabilities then a UE may progressively try them to overcome failure to reach the IMS. Use of these capabilities shall have the following priority order:

1) UE uses neither capability because reaching the IMS without an intervening NA(P)T, NA(P)T-PT, or tunnel is preferred.

2) UE may use address and/or port number conversions provided by a NA(P)T or NA(P)T-PT as described in either annex F or annex K.

3) UE may use the UE requested FTT-IMS establishment procedure specified in 3GPP TS 24.322 [8Y]. If the UE uses the UE-requested FTT-IMS establishment procedure specified in 3GPP TS 24.322 [8Y], the UE considers itself to:

– be configured to send keep-alives;

– be directly connected to an IP-CAN for which usage of NAT is defined; and

– be behind a NAT.

Optional procedures apply when the UE is supporting traversal of restrictive non-3GPP access network using STUN/TURN/ICE, as follows:

a) the protection of SIP messages is provided by utilizing TLS as defined in 3GPP TS 33.203 [19];

b) the mechanisms specified in this annex shall only be applicable when the IP traffic to the IMS core does not traverse through the Evolved Packet Core (EPC);

c) the UE shall establish the TLS connection to the P-CSCF on port 443. The UE shall use SIP digest with TLS for registration as specified in subclause 5.1. If the TLS connection is established successfully, the UE sends SIP signalling over the TLS connection to the P-CSCF;

d) the UE shall support the keep-alive procedures described in RFC 6223 [143];

NOTE 1: If the UE is configured to use an HTTP proxy, the UE use the HTTP CONNECT method specified in RFC 2817 [220] to request the HTTP proxy to establish the TCP connection with the P-CSCF. Once the UE has received a positive reply from the proxy that the TCP connection has been established, the UE initiates the TLS handshake with the P-CSCF and establishes the TLS connection.

e) the procedures described in subclause K.5.2 apply with the additional procedures described in the present subclause;

f) when using the ICE procedures for traversal of restrictive non-3GPP access network, the UE shall support the ICE TCP as specified in RFC 6544 [131] and TURN TCP as specified in RFC 6062 [221].

g) if the UE is configured to use TURN over TCP on port 80, the UE shall establish the TCP connection to TURN server on port 80. If the UE is configured to use TURN over TLS on port 443, the UE shall establish the TLS connection to the TURN server on port 443. If the UE is configured to use both, the UE should prefer to use TURN over TCP on port 80 to avoid TLS overhead;

h) if the connection is established successfully, the UE sends TURN control messages and media packets over the connection as defined in RFC 5766 [101].

NOTE 2: If the UE is configured to use an HTTP proxy, the UE use the HTTP CONNECT method specified in RFC 2817 [220] to request the HTTP proxy to establish the TCP connection with the TURN server. Then, if the UE is configured to use TURN over TLS on port 443 and the UE has received a positive reply from the proxy that the TCP connection has been established, the UE initiates the TLS handshake with the TURN server and establishes the TLS connection.

Reference(s)

3GPP TS 24.229[10], clauses 5.1.1.1B.1, 5.1.1.2.1, 5.1.1.2.3, 5.1.1.5.4, 5.1.1.3, 5.1.2.1, 5.1.2A.1.1 and E.3.1.0.

H.8.1.3 Test purpose

1) To verify that the UE sends a correctly composed initial REGISTER request to S-CSCF via the discovered P-CSCF, according to 3GPP TS 24.229 [10] clause 5.1.1.3;

2) To verify that after receiving a valid 401 (Unauthorized) response from S-CSCF for the initial REGISTER sent, the UE correctly authenticates itself by sending another REGISTER request with correctly composed Authorization header using MD5 algorithm (as described in RFC 3310 [17]); and

3) To verify that after receiving a valid 200 OK response from S-CSCF for the REGISTER sent for authentication, the UE stores the default public user identity and information about barred user identities; and

4) To verify that after receiving a valid 200 OK response from S-CSCF for the REGISTER sent for authentication, the UE subscribes to the reg event package for the public user identity registered at the users registrar (S-CSCF) as described in RFC 3680 [22]; and

5) To verify that the UE uses the default public user identity for subscription to the registration-state event package, when the public user identity that was used for initial registration is a barred public user identity; and

6) To verify that the UE uses the stored service route for routing the SUBSCRIBE sent; and

7) To verify that after receiving a valid 200 OK response from S-CSCF to the SUBSCRIBE sent for registration event package, the UE maintains the generated dialog; and

8) To verify that after receiving a valid NOTIFY for the registration event package, the UE will update and store the registration state of the indicated public user identities accordingly (as specified in RFC 3680 [22] clause 5); and

9) To verify that the UE responds the received valid NOTIFY with 200 OK.

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

Test procedure

1) IMS registration is initiated on the UE. SS waits for the UE to send an initial REGISTER request.

2) SS responds to the initial REGISTER request with a valid 401 Unauthorized response, headers populated according to the 401 response common message definition.

3) SS waits for the UE to another REGISTER request.

4) SS responds to the second REGISTER request with valid 200 OK response. SS shall populate the headers of the 200 OK response according to the 200 response for REGISTER common message definition.

5) SS waits for the UE to send a SUBSCRIBE.

6) SS responds to the SUBSCRIBE request with a valid 200 OK response, headers populated according to the 200 response for SUBSCRIBE common message definition.

7) SS sends UE a NOTIFY request for the subscribed registration event package. In the request the Request URI, headers and the request body shall be populated according to the NOTIFY common message definition.

8) SS waits for the UE to respond the NOTIFY with 200 OK response.

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1	🡪		REGISTER	UE sends initial registration for IMS services.
2	🡨		401 Unauthorized	The SS responds with a valid MD5 authentication challenge
3	🡪		REGISTER	SS sends another REGISTER with MD5 valid credentials.
4	🡨		200 OK	The SS responds with 200 OK.
5	🡪		SUBSCRIBE	UE subscribes to its registration event package.
6	🡨		200 OK	The SS responds SUBSCRIBE with 200 OK
7	🡨		NOTIFY	The SS sends initial NOTIFY for registration event package, containing full registration state information for the registered public user identity in the XML body
8	🡪		200 OK	The UE responds the NOTIFY with 200 OK

Specific Message Contents

Use the default message “REGISTER” in annex A.1.1 with condition A14 "Initial REGISTER over Fixed Access Broadband"

401 Unauthorized for REGISTER (Step 2)

Use the default message “401 Unauthorized for REGISTER” in annex A.1.2 with condition A2 " SIP Digest without TLS for Fixed Broadband Access "

Use the default message “REGISTER” in annex A.1.1 with condition A15 "Subsequent REGISTER over Fixed Access Broadband”

200 OK for REGISTER (Step 4)

Use the default message “200 OK for REGISTER” in annex A.1.3 with condition A5 " SIP Digest without TLS for Fixed Broadband Access "

SUBSCRIBE (Step 5)

Use the default message “SUBSCRIBE for reg-event package” in annex A.1.4 with condition A5 " SIP Digest without TLS for Fixed Broadband Access "

200 OK for SUBSCRIBE (Step 6)

Use the default message “200 OK for SUBSCRIBE” in annex A.1.5 with condition A3 " SIP Digest without TLS for Fixed Broadband Access "

NOTIFY (Step 7)

Use the default message “NOTIFY for reg-event package” in annex A.1.6 with condition A5 " SIP Digest without TLS for Fixed Broadband Access "

200 OK for NOTIFY (Step 8)

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

H.8.1.5 Test requirements

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

Step 1: SS shall check that in accordance to the 3GPP TS 24.229 [10] clause 5.1.1.3 the UE sends a REGISTER.

Step 3: SS shall check that in accordance to the 3GPP TS 24.229 [10] clause 5.1.1.5 the UE sends another REGISTER request.

Step 5: SS shall check that, in accordance to the 3GPP TS 24.229 [10] clause 5.1.1.3, the UE sends a SUBSCRIBE request for registration event package.

H.8.2 User Initiated Re-Registration / Fixed Broadband Access

H.8.2.1 Definition

Test to verify that the UE can re-register a previously registered public user identity at any time. This process is described in 3GPP TS 24.229 [10], clause 5.1.1.4. The test case is applicable for IMS security.

H.8.2.2 Conformance requirement

[TS 24.229, clause 5.1.1.4.1]:

The UE can perform the reregistration of a previously registered public user identity bound to any one of its contact addresses and the associated set of security associations or TLS sessions at any time after the initial registration has been completed.

The UE can perform the reregistration of a previously registered public user identity over any existing set of security associations or TLS session that is associated with the related contact address.

The UE can perform the reregistration of a previously registered public user identity via an initial registration as specified in subclause 5.1.1.2, when binding the previously registered public user identity to new contact address.

The UE can perform registration of additional public user identities at any time after the initial registration has been completed. The UE shall perform the registration of additional public user identities either:

– over the existing set of security associations or TLS sessions, if appropriate to the security mechanism in use, that is associated with the related contact address; or

– via an initial registration as specified in subclause 5.1.1.2.

The UE can fetch bindings as defined in RFC 3261 at any time after the initial registration has been completed. The procedure for fetching bindings is the same as for a reregistration except that the REGISTER request does not contain a Contact header field.

Unless either the user or the application within the UE has determined that a continued registration is not required the UE shall reregister an already registered public user identity either 600 seconds before the expiration time if the previous registration was for greater than 1200 seconds, or when half of the time has expired if the previous registration was for 1200 seconds or less, or when the UE intends to update its capabilities according to RFC 3840 or when the UE needs to modify the ICSI values that the UE intends to use in a g.3gpp.icsi-ref media feature tag or IARI values that the UE intends to use in the g.3gpp.iari-ref media feature tag.

When sending a protected REGISTER request, the UE shall use a security association or TLS session associated with the contact address used to send the request, see 3GPP TS 33.203, established as a result of an earlier initial registration.

On sending a REGISTER request that does not contain a challenge response, the UE shall populate the header fields as follows:

a) a From header field set to the SIP URI that contains the public user identity to be registered;

b) a To header field set to the SIP URI that contains the public user identity to be registered;

c) a Contact header field set to include SIP URI(s) that contain(s) in the hostport parameter the IP address or FQDN of the UE, and containing the instance ID of the UE in the "+sip.instance" header field parameter, if the UE supports GRUU (see table A.4, item A.4/53) or multiple registrations. If the UE support multiple registrations, it shall include "reg-id" header field as described in RFC 5626. The UE shall include all supported ICSI values (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 and RFC 3840 for the IMS communication it intends to use, and IARI values (coded as specified in subclause 7.2A.9.2), for the IMS applications it intends to use in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3840;

d) a Via header field set to include the IP address or FQDN of the UE in the sent-by field. For the TCP, the response is received on the TCP connection on which the request was sent. If the UE previously has previously negotiated sending of keep-alives associated with the registration, it shall include a "keep" header field parameter with no value in the Via header field, in order to indicate continuous support to send keep-alives, as described in draft-ietf-sipcore-keep;

e) a registration expiration interval value, set to 600 000 seconds as the value desired for the duration of the registration;

NOTE 1: The registrar (S-CSCF) might decrease the duration of the registration in accordance with network policy. Registration attempts with a registration period of less than a predefined minimum value defined in the registrar will be rejected with a 423 (Interval Too Brief) response.

f) a Request-URI set to the SIP URI of the domain name of the home network used to address the REGISTER request;

g) the Supported header field containing the option-tag "path", and if GRUU is supported, the option-tag "gruu";

h) if available to the UE (as defined in the access technology specific annexes for each access technology), a P-Access-Network-Info header field set as specified for the access network technology (see subclause 7.2A.4); and

i) a Security-Client header field to announce the media plane security mechanisms the UE supports, if any, according to the procedures described in draft-dawes-dispatch-mediasec-parameter.

NOTE 2: Security mechanisms that apply to the media plane are distinguished by the "mediasec" header field parameter.

On receiving the 200 (OK) response to the REGISTER request, the UE shall:

a) bind the new expiration time of the registration for this public user identity found in the To header field value to the contact address used in this registration;

b) store the list of service route values contained in the Service-Route header field and bind the list to the contact address used in registration, in order to build a proper preloaded Route header field value for new dialogs and standalone transactions when using the respective contact address;

NOTE 3: If the list of Service-Route headers saved from a previous registration and bound to this contact address and the associated set of security associations or TLS session already exist, then the received list of Service-Route headers replaces the old list.

NOTE 4: The UE can utilize additional URIs contained in the P-Associated-URI header field, e.g. for application purposes.

c) find the Contact header field within the response that matches the one included in the REGISTER request. If this contains a "pub-gruu" header field parameter or a "temp-gruu" header field parameter or both, and the UE supports GRUU (see table A.4, item A.4/53), then store the value of those parameters as the GRUUs for the UE in association with the public user identity and the contact address that was registered;

d) store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports received in the Security-Server header field, if any, according to the procedures described in draft-dawes-dispatch-mediasec-parameter; and

NOTE 5: Security mechanisms that apply to the media plane are distinguished by the "mediasec" header field parameter.

e) if the Via header field contains a "keep" header field parameter with a value, continue to send keep-alives as described in draft-ietf-sipcore-keep, towards the P-CSCF.

When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in subclause 5.1.1.5.1.

[TS 24.229, clause 5.1.1.4.3]:

On sending a REGISTER request, as defined in subclause 5.1.1.4.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field as defined in RFC 2617 [21], including:

– the "username" header field parameter, set to the value of the private user identity;

– the "realm" header field parameter, set to the domain name of the home network;

– the "uri" header field parameter, set to the SIP URI of the domain name of the home network;

– the "nonce" header field parameter, set to the stored nonce value for authentication for the related registration or registration flow (if the multiple registration mechanism is used); and

NOTE: The related registration flow or registration is identified by the couple instance-id and reg-id if the multiple registration mechanism is used or by contact address if not.

– the "response" header field parameter, set to the challenge response, constructed using the stored nonce value for authentication for the same registration or registration flow ( if the multiple registration mechanism is used), along with "cnonce", "qop", and "nonce-count" header field parameters as specified in RFC 2617 [21];

b) the Contact header field with the port value of an unprotected port where the UE expects to receive subsequent requests; and

c) the Via header field with the port value of an unprotected port where the UE expects to receive responses to the request.

Reference(s)

3GPP TS 24.229[10], clauses 5.1.1.4.1 and 5.1.1.4.3.

H.8.2.3 Test purpose

1) To verify that the UE can re-register a previously registered public user identity at either 600 seconds before the expiration time if the initial registration was for greater than 1200 seconds, or when half of the time has expired if the initial registration was for 1200 seconds or less; and

2) Extract or derive a public user identity, the private user identity, and the domain name to be used in the Request-URI in the registration; and

3) To verify that the UE populates the header field in the REGISTER request with From, To, Via, Contact, Authorization, Expires, Supported, and P-Access-Network-Info headers; and

4) Upon receiving 200 OK for REGISTER, the UE shall store the new expiration time of the registration for this public user identity, the list of URIs contained in the P-Associated-URI header value and use these values in the next re-register request.

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

1-8) The same procedure as in subclause H.8.1.4 are used with the exception that the SS sets the expiration time to 120 seconds in Step 4.

9) Before half of the time has expired from the initial registration SS receives re-register message request with the From, To, Via, Contact, Authorization, Expires, Supported, and P-Access-Network-Info header fields.

10) SS responds to the REGISTER request with valid 200 OK response with the list of URIs contained in the P-Associated-URI header value, the new expiration time (1200 seconds) of the registration for this public user identity.

11) SS waits for the REGISTER request and verifies it is received at least 600 seconds before the expected expiration time.

12) SS responds to the REGISTER request with valid 200 OK response with the list of URIs contained in the P-Associated-URI header value, the new expiration time (1800 seconds) of the registration for this public user identity.

13) SS waits for the REGISTER request and verifies it is received at least 600 seconds before the expected expiration time.

14) SS responds to the REGISTER request with valid 200 OK response. SS shall populate the headers of the 200 OK response according to the 200 response for REGISTER common message definition.

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1-8			Messages in Initial Registration Test case (subclause H.8.1.4)	The same messages as in subclause H.8.1.4 are used with the exception that in Step 4, the SS responds with 200 OK indicating 120 seconds expiration time.
9	🡪		REGISTER	The SS receives REGISTER from the UE 60 seconds before the expiration time set in the initial registration request.
10	🡨		200 OK	The SS responds with 200 OK indicating 1200 seconds expiration time.
11	🡪		REGISTER	The SS receives REGISTER from the UE 600 seconds before the expiration time set in step 10.
12	🡨		200 OK	The SS responds with 200 OK indicating 1800 seconds expiration time.
13	🡪		REGISTER	The SS receives REGISTER from the UE 600 seconds before the expiration time set in step 12
14	🡨		200 OK	The SS responds with 200 OK indicating the default expiration time.

Specific Message Contents

Messages in Step 1-8

Messages in Step 1-8 are the same as those specified in subclause 8.1.4 with the following exception for the 200 OK for REGISTER in Step 4:

Use the default message “200 OK for REGISTER” in annex A.1.3 with the following exceptions:

Header/param	Value/remark
Contact
expires	120

Use the default message “REGISTER” in annex A.1.1 with condition A15 "Subsequent REGISTER over Fixed Access Broadband”

200 OK for REGISTER (Step 10)

Use the default message “200 OK for REGISTER” in annex A.1.3 with condition A5 "SIP Digest without TLS for Fixed Broadband Access" and with the following exceptions:

Header/param	Value/remark
Contact
expires	1200

Use the default message “REGISTER” in annex A.1.1 with condition A15 "Subsequent REGISTER over Fixed Access Broadband”

200 OK for REGISTER (Step 12)

Use the default message “200 OK for REGISTER” in annex A.1.3 with condition A5 "SIP Digest without TLS for Fixed Broadband Access"

Use the default message “REGISTER” in annex A.1.1 with condition A15 "Subsequent REGISTER over Fixed Access Broadband”

200 OK for REGISTER (Step 14)

Use the default message “200 OK for REGISTER” in annex A.1.3 with condition A5 "SIP Digest without TLS for Fixed Broadband Access"

H.8.2.5 Test requirements

1. The UE shall in step 9 send the REGISTER request within 60 seconds from the time instant that it receives 200 OK in step 4 from the SS.

2. The UE shall in step 11 send the REGISTER request within 600 seconds from the time instant that it receives 200 OK from the SS in step 10.

3. The UE shall in step 13 send the REGISTER request within 1200 seconds from the time instant that it receives 200 OK from the SS in step 12.

H.8.3 User Initiated Deregistration / Fixed Broadband Access

H.8.3.1 Definition

Test to verify that the UE can perform a correct de-registration procedure. This process is described in 3GPP TS 24.229 [10], clause 5.1.1.6.

H.8.3.2 Conformance requirement

[TS 24.229, clause 5.1.1.6.1]:

The UE can deregister a public user identity that it has previously registered with its contact address at any time. The UE shall protect the REGISTER request using a security association or TLS session that is associated with contact address, see 3GPP TS 33.203, established as a result of an earlier registration, if one is available.

Prior to sending a REGISTER request for deregistration, the UE shall release all dialogs that were using the contact addresses that is going to be deregistered and related to the public user identity that is going to be deregistered or to one of the implicitly registered public user identities. However:

– if the dialog that was established by the UE subscribing to the reg event package used the public user identity that is going to be deregistered; and

– this dialog is the only remaining dialog used for subscription to reg event package of the user, i.e. there are no other contact addresses registered with associated subscription to the reg event package of the user;

then the UE shall not release this dialog.

On sending a REGISTER request that will remove the binding between the public user identity and one of its contact addresses, the UE shall populate the header fields as follows:

a) a From header field set to the SIP URI that contains the public user identity to be deregistered;

b) a To header field set to the SIP URI that contains the public user identity to be deregistered;

c) a Contact header field set to the SIP URI(s) that contain(s) in the hostport parameter the IP address of the UE or FQDN, and containing the Instance ID of the UE in the "+sip.instance" header field parameter, if the UE supports GRUU (see table A.4, item A.4/53) or multiple registrations. If the UE supports multiple registrations, it shall include "reg-id" header field parameter as described in RFC 5626;

d) a Via header field set to include the IP address or FQDN of the UE in the sent-by field;

e) a registration expiration interval value set to the value of zero, appropriate to the deregistration requirements of the user;

f) a Request-URI set to the SIP URI of the domain name of the home network used to address the REGISTER request;

g) if available to the UE (as defined in the access technology specific annexes for each access technology), a P-Access-Network-Info header field set as specified for the access network technology (see subclause 7.2A.4); and

h) a Security-Client header field to announce the media plane security mechanisms the UE supports, if any, according to the procedures described in draft-dawes-dispatch-mediasec-parameter.

NOTE 1: Security mechanisms that apply to the media plane are distinguished by the "mediasec" header field parameter.

For a public user identity that the UE has registered with multiple contact addresses (e.g. via different P-CSCFs), the UE shall also be able to deregister multiple contact addresses, bound to its public user identity, via single deregistration procedure as specified in RFC 3261. The UE shall send a single REGISTER request, using one of its contact addresses and the associated set of security associations or TLS session, containing a list of Contact headers. Each Contact header in the list shall contain the contact addresses that the UE wants to deregister with the "expires" parameter containing the value equal zero.

The UE can deregister all contact addresses bound to its public user identity and associated with its private user identity. The UE shall send a single REGISTER request, using one of its contact addresses and the associated set of security associations or TLS session, containing a public user identity that is being deregistered in the To header field, and a single Contact header field with value of "*" and the Expires header field with a value of "0".

NOTE 2: All entities subscribed to the reg event package of the user will be inform via NOTIFY request which contact addresses bound to the public user identity have been deregistered.

When a 401 (Unauthorized) response to a REGISTER request is received the UE shall behave as described in subclause 5.1.1.5.1.

On receiving the 200 (OK) response to the REGISTER request, the UE shall:

– remove all registration details relating to this public user identity and the associated contact address.

– store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports received in the Security-Server header field, if any, according to the procedures described in draft-dawes-dispatch-mediasec-parameter.

NOTE 9: Security mechanisms that apply to the media plane are distinguished by the "mediasec" header field parameter.

If there are no more public user identities registered with this contact address, the UE shall delete any stored media plane security mechanisms and related keys and any security associations or TLS sessions and related keys it may have towards the IM CN subsystem.

If all public user identities are deregistered and all security association or TLS session is removed, then the UE shall consider subscription to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires header field containing a value of zero).

[TS 24.229, clause 5.1.1.6.2]:

On sending a REGISTER request, as defined in subclause 5.1.1.6.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field, with:

– the "username" header field parameter, set to the value of the private user identity;

– the "realm" header field parameter, set to the value as received in the "realm" WWW-Authenticate header field parameter;

– the "uri" header field parameter, set to the SIP URI of the domain name of the home network;

– the "nonce" header field parameter, set to last received nonce value; and

– the response directive, set to the last calculated response value;

b) additionally for each Contact header field and associated contact address, include the associated protected server port value in the hostport parameter;

c) additionally for the Via header field, include the protected server port value bound to the security association in the sent-by field;

NOTE 1: If the UE specifies its FQDN in the hostport parameter in the Contact header field and in the sent-by field in the Via header field, then it has to ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP address that is bound to the security association.

d) a Security-Client header field, set to specify the signalling plane security mechanisms it supports, the IPsec layer algorithms for integrity and confidentiality protection it supports and the new parameter values needed for the setup of two new pairs of security associations. For further details see 3GPP TS 33.203 and RFC 3329; and

e) a Security-Verify header field that contains the content of the Security-Server header field received in the 401 (Unauthorized) response of the last successful authentication.

NOTE 2: When the UE has received the 200 (OK) response for the REGISTER request of the only public user identity currently registered with this contact address and its associated set of implicitly registered public user identities (i.e. no other public user identity is registered), the UE removes the security association (between the P-CSCF and the UE) that were using this contact address. Therefore further SIP signalling using this security association (e.g. the NOTIFY request containing the deregistration event) will not reach the UE.

[TS 24.229, clause E.3.1.0]:

In order to reach IMS in some access networks, the UE may support:

– address and/or port number conversions provided by a NA(P)T or NA(P)T-PT as described in annex F and annex K; and

– UE requested FTT-IMS establishment procedure specified in 3GPP TS 24.322 [8Y].

If a UE supports one or both of these capabilities then a UE may progressively try them to overcome failure to reach the IMS. Use of these capabilities shall have the following priority order:

1) UE uses neither capability because reaching the IMS without an intervening NA(P)T, NA(P)T-PT, or tunnel is preferred.

2) UE may use address and/or port number conversions provided by a NA(P)T or NA(P)T-PT as described in either annex F or annex K.

– be configured to send keep-alives;

– be directly connected to an IP-CAN for which usage of NAT is defined; and

– be behind a NAT.

Optional procedures apply when the UE is supporting traversal of restrictive non-3GPP access network using STUN/TURN/ICE, as follows:

a) the protection of SIP messages is provided by utilizing TLS as defined in 3GPP TS 33.203 [19];

b) the mechanisms specified in this annex shall only be applicable when the IP traffic to the IMS core does not traverse through the Evolved Packet Core (EPC);

d) the UE shall support the keep-alive procedures described in RFC 6223 [143];

e) the procedures described in subclause K.5.2 apply with the additional procedures described in the present subclause;

f) when using the ICE procedures for traversal of restrictive non-3GPP access network, the UE shall support the ICE TCP as specified in RFC 6544 [131] and TURN TCP as specified in RFC 6062 [221].

h) if the connection is established successfully, the UE sends TURN control messages and media packets over the connection as defined in RFC 5766 [101].

Reference(s)

3GPP TS 24.229[10], clauses 5.1.1.6.1, 5.1.1.6.2 and E.3.1.0.

H.8.3.3 Test purpose

1) To verify that the UE sends a correctly composed initial REGISTER request with an expiration interval value set to 0 to S-CSCF via the discovered P-CSCF, according to 3GPP TS 24.229 [10] clause 5.1.1.6.

2) To verify that the UE sends correctly composed unsubscriptions, in case the UE unsubscribes from its event packages.

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

0) The UE is triggered by MMI to initiate a deregistration procedure.

0A-0D) UE optionally unsubscribes from event packages it had subscribed to.

1) IMS deregistration is initiated on the UE. SS waits the UE to send a REGISTER request, in accordance to 3GPP TS 24.229 [10], clause 5.1.1.6.

2) SS responds to REGISTER with a correctly composed 200 OK message.

Expected sequence

Step	Direction		Message	Comment
	UE	SS
0			Make the UE deregister from IMS
0A-2			Steps 0A-2 defined in Annex C.30b

H.8.3.5 Test Requirements

SS shall check in steps 0A-0D that the UE uses headers as described in C.30 in case it unsubscribes from event packages.

SS shall check in step 1 that the de-register request sent by the UE has the headers correctly populated as per the default message “REGISTER” in annex A.1.1condition A15.

H.8.4 Invalid behaviour- 423 Interval too brief / Fixed Broadband Access

H.8.4.1 Definition

As described in clause 8.4.1.

H.8.4.2 Conformance requirement

As described in clause 8.4.2.

H.8.4.3 Test purpose

As described in clause 8.4.3.

H.8.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 IMS registration is initiated on the UE. SS waits for the UE to send an initial REGISTER request.

2 SS responds to the initial REGISTER request with a 423 (Interval Too Brief) response.

3 SS waits for the UE to send another REGISTER request populating the Expires header or the expires parameter in the Contact header with an expiration timer of at least the value received in the Min-Expires header of the 423 (Interval Too Brief) response.

4 Continue test execution with the Generic test procedure in Annex C.2b, step 3, with the modifications listed below.

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1	🡪		REGISTER	UE sends initial registration for IMS services.
2	🡨		423 Interval Too Brief	The SS responds with a 423 (Interval Too Brief) too brief response to the REGISTER request with T value in Min-Expires header.
3	🡪		REGISTER	UE sends a new REGISTER request with expires parameter value set to Tmod (equal or greater to T value in Min-Expires header of 423 (Interval Too Brief)).
4	🡨🡪		Continue with Annex C.2b step 3	Execute the Generic test procedure Annex C.2b steps 3-9 in order to get the UE in a stable registered state.

Specific Message Contents

Use the default message “REGISTER” in annex A.1.1 with condition A14 “Initial REGISTER SIP Digest without TLS for Fixed Broadband Access”.

423 Interval Too Brief for REGISTER (Step 2)

Use the default message “423 Interval Too Brief for REGISTER” in annex A.1.7 with the following exception:

Header/param	Value/remark
Min-Expires
delta-seconds	800000 (referred to as T in the test procedure and test requirement)

Use the default message “REGISTER” in annex A.1.1 with condition A14 “Initial REGISTER SIP Digest without TLS for Fixed Broadband Access” with the following exceptions:

Header/param	Value/remark
Contact
expires	800000 (referred to as Tmod in the expected sequence) (if present, see Rule 1)
Expires	(if present, see Rule 1)
delta-seconds	800000 (referred to as Tmod in the expected sequence)
CSeq
value	must be incremented from the previous REGISTER

Rule 1: The REGISTER request must contain either an Expires header or an expires parameter in the Contact header. If both are present the value of Expires header is not important.

Modifications to steps detailed in Appendix C.2b:

Header/param	Value/remark
Contact
expires	800000 (if present)
Expires	(if present)
delta-seconds	800000

200 OK (Step 5)

Header/param	Value/remark
Contact
expires	800000

H.8.4.5 Test requirements

Step 3: The UE shall send another REGISTER request populating the Expires header or the expires parameter in the Contact header with an expiration timer of at least the value received in the Min-Expires header of the 423 (Interval Too Brief) response.

H.8.5 User initiated re-registration – 423 Interval Too Brief / Fixed Broadband Access

H.8.5.1 Definition

As described in clause 8.16.1.

H.8.5.2 Conformance requirement

As described in clause 8.16.2.

H.8.5.3 Test purpose

As described in clause 8.16.3.

H.8.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-8) The same procedures as in subclause H.8.1.4 are used with the exception that the SS sets the expiration time to 120 seconds in Step 4.

9) Before half of the time has expired from the initial registration SS receives re-register message request with the From, To, Via, Contact, Authorization, Expires, Security-Client, Security-verify, Supported, and P-Access-Network-Info header fields.

10) SS responds to the re-register message request with a 423 (Interval Too Brief) response.

11) SS waits for the UE to send another REGISTER request populating the Expires header or the expires parameter in the Contact header with an expiration timer of at least the value received in the Min-Expires header of the 423 (Interval Too Brief) response.

12) The SS responds to the REGISTER request with a valid 200 OK response indicating the default expiration timeout.

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1-8	🡨🡪		Messages in Initial Registration Test case (subclause H.8.1.4)	The same messages as in subclause H.8.1.4 are used with the exception that in Step 4, the SS responds with 200 OK indicating 120 seconds expiration time.
9	🡪		REGISTER	The SS receives REGISTER from the UE 60 seconds before the expiration time set in the initial registration request.
10	🡨		423 Interval Too Brief	The SS responds with a 423 (Interval Too Brief) too brief response to the REGISTER request with T value in Min-Expires header.
11	🡪		REGISTER	UE sends a new REGISTER request with expires parameter value set to Tmod (equal or greater to T value in Min-Expires header of 423 (Interval Too Brief)).
12	🡨		200 OK	The SS responds with 200 OK indicating the default expiration time.

Specific Message Contents

Messages in Step 1-8

Messages in Step 1-8 are the same as those specified in subclause H.8.1.4 with the following exception for the 200 OK for REGISTER in Step 4:

Use the default message “200 OK for REGISTER” in annex A.1.3 with the following exceptions:

Header/param	Value/remark
Contact
expires	120

Use the default message “REGISTER” in annex A.1.1 with condition A15 "Subsequent REGISTER SIP Digest without TLS for Fixed Broadband Access" and with the following exceptions:

Header/param	Value/remark
Security-Client
spi-c	new SPI number of the inbound SA at the protected client port, shall be different than in step 3
spi-s	new SPI number of the inbound SA at the protected server port, shall be different than in step 3
port-c	new protected client port, shall be different than in step 3
port-s	Same value as in the previous REGISTER

423 Interval Too Brief for REGISTER (Step 10)

Use the default message “423 Interval Too Brief for REGISTER” in annex A.1.7 with the following exception:

Header/param	Value/remark
Min-Expires
delta-seconds	800000 (referred to as T in the test procedure and test requirement)

Use the default message “REGISTER” in annex A.1.1 with condition A14 "Initial REGISTER SIP Digest without TLS for Fixed Broadband Access" with the following exceptions:

Header/param	Value/remark
Contact
expires	800000 (referred to as Tmod in the expected sequence) (if present, see Rule 1)
Expires	(if present, see Rule 1)
delta-seconds	800000 (referred to as Tmod in the expected sequence)
CSeq
value	must be incremented from the previous REGISTER

Rule 1: The REGISTER request must contain either an Expires header or an expires parameter in the Contact header. If both are present the value of Expires header is not important.

200 OK (Step 12)

Header/param	Value/remark
Contact
expires	800000

H.8.5.5 Test requirements

Step 11: The UE shall send another REGISTER request populating the Expires header or the expires parameter in the Contact header with an expiration timer of at least the value received in the Min-Expires header of the 423 (Interval Too Brief) response.