Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.5…   5…   5.1.1.4…   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4…   5.4.1.2.2…   5.4.1.3…   5.4.2   5.4.3…   5.4.3.3…   5.4.4…   5.5…   5.7…   5.7.2…   5.8…   5.11…   6…   6.6…   7…   7.2A…   7.2A.6…   7.3…   7.9A…   8…   A…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…

 

5  Application usage of SIP

5.1  Procedures at the UE

5.1.0  General |R8|

The UE procedures for UE detectable emergency calls are defined in subclause 5.1.6. Exceptions to UE procedures for SIP that do not relate to emergency, are documented in subclause 5.1.6 and shall apply. These exceptions include handling of a response to a request not detected by the UE as relating to an emergency.
When sending a failure response to any received request, depending on operator policy, the UE may insert a Response-Source header field with an "fe" header field parameter constructed with the URN namespace "urn:3gpp:fe", the fe-id part of the URN set to "ue" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17. A UE when sending a failure response will add in the URN the "side" header field parameter set to:
  • "orig" for a UE-originating case; and
  • "term" for a UE-terminating case.
Up

5.1.1  Registration and authenticationWord‑p. 98

5.1.1.1  General

The UE shall register public user identities (see table A.4/1 and dependencies on that major capability).
In case a UE registers several public user identities at different points in time, the procedures to re-register, deregister and subscribe to the registration-state event package for these public user identities can remain uncoordinated in time.
The UE can register any one of its public user identities with any IP address acquired by the UE. The same public user identity can be bound to more than one IP address of the UE. While having valid registrations of previously registered public user identities, the UE can register any additional public user identity with any of its IP addresses. When binding any one of its public user identities to an additional contact address, the UE shall follow the procedures described in RFC 5626.
If SIP digest without TLS is used, the UE shall not include signalling plane security mechanisms in the header fields defined in RFC 3329 in any SIP messages.
SIP requests that indicate security mechanisms for both the signalling plane and the media plane can contain multiple instances or a single instance of the Security-Client, Security-Verify, or Security-Server header fields defined in RFC 3329.
In case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT, the UE may need to modify the SIP contents according to the procedures described in either annex F or annex K.
Up

5.1.1.1A  Parameters contained in the ISIM

This subclause applies when a UE contains either an ISIM or a USIM.
The ISIM shall always be used for authentication to the IM CN subsystem, if it is present, as described in TS 33.203.
The ISIM is preconfigured with all the necessary parameters to initiate the registration to the IM CN subsystem. These parameters include:
  • the private user identity;
  • one or more public user identities; and
  • the home network domain name used to address the SIP REGISTER request
The first public user identity in the list stored in the ISIM is used in emergency registration requests.
In case the UE does not contain an ISIM, the UE shall:
  • generate a private user identity;
  • generate a temporary public user identity; and
  • generate a home network domain name to address the SIP REGISTER request to;
in accordance with the procedures in clause C.2.
The temporary public user identity is only used in REGISTER requests, i.e. initial registration, re-registration, UE-initiated deregistration.
The UE shall not reveal to the user the temporary public user identity if the temporary public user identity is barred. The temporary public user identity is not barred if received by the UE in the P-Associated-URI header field.
If the UE is unable to derive the parameters in this subclause for any reason, then the UE shall not proceed with the request associated with the use of these parameters and will not be able to register to the IM CN subsystem.
Up

5.1.1.1B  Parameters provisioned to a UE without ISIM or USIM |R8|Word‑p. 99
5.1.1.1B.1  Parameters provisioned in the IMC
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.
Up
5.1.1.1B.2  Parameters when UE does not contain ISIM, USIM or IMC
If the UE contains neither ISIM, nor USIM nor IMC, the UE shall generate a temporary public user identity, a private user identity and a home network domain name to address the SIP REGISTER request to, according TS 23.003.

5.1.1.2  Initial registration

5.1.1.2.1  General |R8|
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. 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, 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.
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:
  1. a From header field set to the SIP URI that contains:
    1. if the UE supports RFC 6140 and performs the functions of an external attached network, the main URI of the UE; else
    2. the public user identity to be registered;
  2. a To header field set to the SIP URI that contains:
    1. if the UE supports RFC 6140 and performs the functions of an external attached network, the main URI of the UE; else
    2. the public user identity to be registered;
  3. 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.
      If the UE supports multiple registrations it shall include a "reg-id" header field parameter 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 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.
      The UE shall include the media feature tags defined in RFC 3840 and RFC 5688 for all supported streaming media types.
      If the UE supports RFC 6140 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.
      If the UE has no specific reason not to include a user part in the URI of the contact address (eg. some UE performing the functions of an external attached network), the UE should include a user part in the URI of the contact address such that the user part is globally unique and does not reveal any private information;
  4. 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 UDP is 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;
  5. a registration expiration interval value of 600 000 seconds as the value desired for the duration of the registration;
  6. a Request-URI set to the SIP URI of the domain name of the home network used to address the REGISTER request;
  7. 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".
  8. 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);
  9. 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;
  10. if the UE supports RFC 6140 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
  11. if the UE supports RFC 6140 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:
  1. 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.
On receiving the 200 (OK) response to the REGISTER request, the UE shall:
  1. 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);
  2. 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;
  3. treat the identity under registration as a barred public user identity, if it is not included in the P-Associated-URI header field;
  4. 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;
  5. 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 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 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. 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;
  6. 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, and the S-CSCF has followed the registration procedure as described in RFC 5627 or RFC 3261, 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, the UE shall refrain from registering any additional IMS flows for the same private identity as described in RFC 5626; or
    • if an option-tag "outbound" is present, the UE may establish additional IMS flows for the same private identity, as defined in RFC 5626;
  7. 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;
  8. 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;
  9. if a Feature-Caps header field, as specified in RFC 6809 is received, a UE supporting the Feature-Caps header field shall consider the ICSI values received in 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);
  10. void; and
  11. if the 200 (OK) response includes a Feature-Caps header field, as specified in RFC 6809, with a "+g.3gpp.verstat" header field parameter and if the UE supports calling number verification status determination, determine that the home network supports calling number verification using signature verification and attestation information, as defined in subclause 3.1.
On receiving a 305 (Use Proxy) response to the unprotected REGISTER request, unless otherwise specified in access specific annexes (as described in annex B, annex L or annex U), the UE shall:
  1. ignore the contents of the Contact header field if it is included in the received message;
  2. release all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2;
  3. 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;
  4. select a P-CSCF address, which is different from the previously used address, from the address list; and
  5. 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 or 403 (Forbidden) response for an initial registration, the UE may attempt to perform initial registration again.
When the timer F expires at the UE, the UE:
  1. shall mark the currently used P-CSCF address as unavailable for the last duration of the retry delay time computed by the algorithm defined in subclause 4.5 of RFC 5626 plus 5 minutes;
  2. if there is a locally stored P-CSCF address as specified in subclause 5.1.9 which is different than the currently used P-CSCF address and which is not marked as unavailable, may initiate an initial registration as specified in subclause 5.1.1.2 using that P-CSCF; and
  3. if there is no locally stored P-CSCF address as specified in subclause 5.1.9 which is different than the currently used P-CSCF address and which is not marked as unavailable, may 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, annex L or annex U) and initiate an initial registration as specified in subclause 5.1.1.2.
On receiving a 4xx, 5xx (except 503) 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.
On receiving a 503 response with a Retry-After header field to the REGISTER request and the Retry-After header field indicates time bigger than the value for timer F as specified in table 7.7.1, the UE:
  1. shall mark the currently used P-CSCF address as unavailable for the time indicated by the Retry-After header field;
  2. if there is a locally stored P-CSCF address as specified in subclause 5.1.9 which is different than the currently used P-CSCF address and which is not marked as unavailable, may initiate an initial registration as specified in subclause 5.1.1.2 using that P-CSCF; and
  3. if there is no locally stored P-CSCF address as specified in subclause 5.1.9 which is different than the currently used P-CSCF address and which is not marked as unavailable, may 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, annex L or annex U) and initiate an initial registration as specified in subclause 5.1.1.2.
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 start to implement the mechanism defined in subclause 4.5 of RFC 5626 for determination of the retry delay time before each new registration attempt. 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. If no values of the parameters max-time and base-time (if all failed) have been provided to the UE by the network, the default values defined in subclause 4.5 of RFC 5626 shall be used.
The values of max-time and base-time (if all failed) may be provided by the network to the UE using OMA-DM with the management objects specified in TS 24.167. Other mechanisms may be used as well and are outside the scope of the present specification.
For each 4xx, 5xx or 6xx response received without a Retry-After header field to the REGISTER request, the UE shall:
  1. mark the currently used P-CSCF address as unavailable for the last duration of the retry delay time computed by the algorithm defined in subclause 4.5 of RFC 5626 plus 5 minutes; and
  2. initiate an initial registration as specified in subclause 5.1.1.2 after the amount of time of the last retry delay time computed by the algorithm defined in subclause 4.5 of RFC 5626; and
  3. if there is a locally stored P-CSCF address as specified in subclause 5.1.9 which is different than the currently used P-CSCF address and which is not marked as unavailable, may initiate the initial registration using that P-CSCF; and
  4. if there is no locally stored P-CSCF address as specified in subclause 5.1.9 which is different than the currently used P-CSCF address and which is not marked as unavailable, may 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, annex L or annex U) and initiate the initial registration as specified in subclause 5.1.1.2.
Up
5.1.1.2.2  Initial registration using IMS AKA |R8|Word‑p. 105
On sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE shall additionally populate the header fields as follows:
  1. 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 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 an empty value; and
    • the "response" header field parameter, set to an empty value;
  2. additionally for the Contact header field, if the REGISTER request is protected by a security association, include the protected server port value in the hostport parameter;
  3. additionally for the Via header field, for UDP, if the REGISTER request is protected by a security association, include the protected server port value in the sent-by field; and
  4. a Security-Client header field set to specify the signalling plane security mechanism the UE supports, the IPsec layer algorithms the UE supports and the parameters needed for the security association setup. The UE shall support the setup of two pairs of security associations as defined in TS 33.203. The syntax of the parameters needed for the security association setup is specified in annex H of TS 33.203. The UE shall support the "ipsec-3gpp" security mechanism, as specified in RFC 3329. The UE shall support the IPsec layer algorithms for integrity and confidentiality protection as defined in TS 33.203, and shall announce support for them according to the procedures defined in RFC 3329.
On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.2.1, the UE shall additionally:
  1. If the UE supports multiple registrations and the REGISTER request contained the "+sip.instance" header field parameter and the "reg-id" header field parameter in the Contact header field, and the "outbound" option-tag in the Supported header field, the UE shall check whether the option-tag "outbound" is present in the Require header field. If the option-tag "outbound" is present, then the UE shall use the bidirectional flow as defined in RFC 5626 as follows:
    1. for UDP, the bidirectional flow consists of two unidirectional flows, i.e. the first unidirectional flow is identified with the UE's protected client port, the P-CSCF's protected server port, and the respective IP addresses. The UE uses this flow to send the requests and responses to the P-CSCF. The second unidirectional flow is identified with the P-CSCF's protected client port, the UE's protected server port and the IP addresses. The second unidirectional flow is used by the UE to receive the requests and responses from the P-CSCF; or
    2. for TCP, the bidirectional flow is the TCP connection between the UE and the P-CSCF. This TCP connection was established by the UE, i.e. from the UE's protected client port and the UE's IP address to the P-CSCF's protected server port and the P-CSCF's IP address. This TCP connection is used to exchange SIP messages between the UE and the P-CSCF; and
  2. set the security association lifetime to the longest of either the previously existing security association lifetime (if available), or the lifetime of the just completed registration plus 30 seconds.
When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in subclause 5.1.1.5.1.
Up
5.1.1.2.3  Initial registration using SIP digest without TLS |R8|Word‑p. 106
On sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE shall additionally populate the header fields as follows:
  1. an Authorization header field as defined in RFC 2617 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;
  2. 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
  3. 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.
Up
5.1.1.2.4  Initial registration using SIP digest with TLS |R8|
On sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE shall additionally populate the header fields as follows:
  1. an Authorization header field set in accordance with subclause 5.1.1.2.3 unless otherwise specified in the access specific annexes; and
  2. a Security-Client header field set to specify the signalling plane security mechanism the UE supports. The UE shall support the setup of a TLS session as defined in TS 33.203. The UE shall support the "tls" security mechanism, as specified in RFC 3329. The UE shall support TLS for integrity and confidentiality protection as defined in RFC 3261, and shall announce support for them according to the procedures defined in RFC 3329.
On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.2.1, the UE shall additionally:
  1. set the TLS session lifetime to the longest of either the previously existing TLS session lifetime (if available), or the lifetime of the just completed registration plus 30 seconds.
If a UE supports TLS, then the UE shall support TLS ciphersuites as described in TS 33.203. TLS session lifetime is determined by local configuration of the UE.
For SIP digest with TLS, the UE associates a protected server port with the TLS session port on the UE.
When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in subclause 5.1.1.5.6.
Up
5.1.1.2.5  Initial registration using NASS-IMS bundled authentication |R8|Word‑p. 107
On sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE shall additionally populate the header fields as follows:
  1. optionally, an Authorization header field, with the "username" header field parameter, set to the value of the private user identity;
On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.2.1, there are no additional requirements for the UE.
Up
5.1.1.2.6  Initial registration using GPRS-IMS-Bundled authentication |R8|
On sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE shall additionally populate the header fields as follows:
  1. an Authorization header field as defined in RFC 2617 shall not be included, in order to indicate support for GPRS-IMS-Bundled authentication.
  2. the Security-Client header field as defined in RFC 3329 shall not contain signalling plane security mechanisms;
  3. a From header field set to a temporary public user identity derived from the IMSI, as defined in TS 23.003, as the public user identity to be registered;
  4. a To header field set to a temporary public user identity derived from the IMSI, as defined in TS 23.003, as the public user identity to be registered;
  5. the Contact header field with the port value of an unprotected port where the UE expects to receive subsequent mid-dialog requests; and
  6. the Via header field with the port value of an unprotected port where the UE expects to receive responses to the request.
On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.2.1, there are no additional requirements for the UE.
Up

5.1.1.3  Subscription to the registration-state event package

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] and RFC 6665.
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.
On sending a SUBSCRIBE request, the UE shall populate the header fields as follows:
  1. 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;
  2. a From header field set to the SIP URI that is the default public user identity used for subscription;
  3. a To header field set to the SIP URI that is the default public user identity used for subscription;
  4. an Event header field set to the "reg" event package;
  5. an Expires header field set to 600 000 seconds as the value desired for the duration of the subscription;
  6. void; and
  7. void.
Upon receipt of a dialog establishing NOTIFY request, as specified in RFC 6665, 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.
If continued subscription is required, the UE shall automatically refresh the subscription to 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. Otherwise, the UE shall consider the subscription invalid and start a new initial subscription according to RFC 6665.
Up

5.1.1.3AVoid


Up   Top   ToC