Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  18.4.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…   A.2…   A.2.1.4…   A.2.1.4.7…   A.2.1.4.8…   A.2.1.4.10A…   A.2.1.4.12…   A.2.2…   A.2.2.4…   A.2.2.4.7…   A.2.2.4.8…   A.2.2.4.10A…   A.2.2.4.12…   A.3…   A.3.3…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…

 

5.1.2  Subscription and notificationp. 128

5.1.2.1  Notification about multiple registered public user identitiesp. 128

Upon receipt of a NOTIFY request for the dialog associated with the subscription to the reg event package the UE shall perform the following actions:
  • store the information for the established dialog;
  • 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;
  • if a <registration> element with 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 <registration> element with 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), the UE shall store the value of those elements in association with the public user identity;
  • if a <registration> element with 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; and
  • follow the procedures specified in RFC 6665.
Up

5.1.2.2  General SUBSCRIBE requirementsp. 129

If the UE receives a 503 (Service Unavailable) response to an initial SUBSCRIBE request containing a Retry-After header field, then the UE shall not automatically reattempt the request until after the period indicated by the Retry-After header field contents.

5.1.2A  Generic procedures applicable to all methods excluding the REGISTER methodp. 129

5.1.2A.1  UE-originating casep. 129

5.1.2A.1.1  General |R8|p. 129
The procedures of this subclause are general to all requests and responses, except those for the REGISTER method.
When the UE re-uses a previously registered contact address, the UE shall remove any parameters dedicated to registration from the Contact header field (e.g. "expires").
When the UE sends any request, the UE shall use either a given contact address that has been previously registered or a registration flow and the associated contact address (if the multiple registration mechanism is used) and shall:
  • if IMS AKA is in use as a security mechanism:
    1. 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
    2. 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:
    1. 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;
    2. 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; and
    3. if a nonce value for proxy authentication is stored for the related registration or registration flow (if the multiple registration mechanism is used), insert a Proxy-Authorization header field containing a challenge response, constructed using the stored nonce value for proxy authentication for the same registration or registration flow (if the multiple registration mechanism is used), "algorithm", "cnonce", "qop", and "nc" header field parameters as specified in RFC 7616 and RFC 8760;
  • if SIP digest with TLS is in use as a security mechanism:
    1. if the UE has not obtained a GRUU, populate the Contact header field of the request with the protected server port;
    2. include the protected server port in the Via header field entry relating to the UE; and
    3. if a nonce value for proxy authentication is stored for the related registration or registration flow (if the multiple registration mechanism is used), insert a Proxy-Authorization header field containing a challenge response, constructed using the stored nonce value for proxy authentication for the same registration or registration flow (if the multiple registration mechanism is used), "algorithm", "cnonce", "qop", and "nc" header field parameters as specified in RFC 7616 and RFC 8760;
  • if NASS-IMS bundled authentication is in use as a security mechanism, and therefore no port is provided for subsequent SIP messages by the P-CSCF during registration, the UE shall send any request to the same port used for the initial registration as described in subclause 5.1.1.2;
  • if GPRS-IMS-Bundled authentication is in use as a security mechanism, and therefore no port is provided for subsequent SIP messages by the P-CSCF during registration, the UE shall send any request to the same port used for the initial registration as described in subclause 5.1.1.2.
If SIP digest without TLS is used, the UE shall not include RFC 3329 header field s in any SIP messages.
When SIP digest is in use, upon receiving a 407 (Proxy Authentication Required) response to an initial request, the originating UE shall:
  • extract the digest-challenge parameters as indicated in RFC 7616 and RFC 8760 from the Proxy-Authenticate header field;
  • if the contained nonce value is associated to the realm used for the related REGISTER request authentication, store the contained nonce as a nonce value for proxy authentication associated to the same registration or registration flow (if the multiple registration mechanism is used) and shall delete any other previously stored nonce value for proxy authentication for this registration or registration flow;
  • calculate the response as described in RFC 7616 and RFC 8760 using the stored nonce value for proxy authentication associated to the same registration or registration flow (if the multiple registration mechanism is used); and
  • send a new request containing a Proxy-Authorization header field in which the header field parameters are populated as defined in RFC 7616 and RFC 8760 using the calculated response.
Where a security association or TLS session exists, the UE shall discard any SIP response that is not protected by the security association or TLS session and is received from the P-CSCF outside of the registration and authentication procedures. The requirements on the UE within the registration and authentication procedures are defined in subclause 5.1.1.
For a UE performing the functions of an external attached network operating in static mode, authentication can take place without a registration based on TLS client certificate. Before any originating or terminating procedures can take place between the UE performing the functions of an external attached operating in static mode and the P-CSCF or between the UE performing the functions of an external attached network operating in static mode and the IBCF of the IMS network, for security and authentication between the UE performing the functions of an external attached network operating in static mode and the IMS network, the UE performing the functions of an external attached network operating in static mode shall use the TLS procedures according to TS 33.310 using certificates.
In accordance with RFC 3325 the UE may insert a P-Preferred-Identity header field in any initial request for a dialog or request for a standalone transaction as a hint for creation of an asserted identity (contained in the P-Asserted-Identity header field) within the IM CN subsystem.
When sending any initial request for a dialog or request for a standalone transaction using either a given contact address that has been previously registered or a registration flow and the associated contact address (if the multiple registration mechanism is used), the UE may include any of the following in the P-Preferred-Identity header field:
  • a public user identity which has been registered by the user with the respective contact address;
  • an implicitly registered public user identity returned in a registration-state event package of a NOTIFY request whose <uri> sub-element inside the <contact> sub-element of the <registration> element is the same as the contact address being used for this request and was not subsequently deregistered or that has not expired; or
  • any other public user identity which the user has assumed by mechanisms outside the scope of this specification to have a current registration.
Where privacy is required, in any initial request for a dialog or request for a standalone transaction, the UE shall set a display-name of the From header field to "Anonymous" as specified in RFC 3261 and set an addr-spec of the From header field to Anonymous User Identity as specified in TS 23.003.
The UE shall determine the public user identity to be used for this request as follows:
  1. if a P-Preferred-Identity was included, then use that as the public user identity for this request; or
  2. if no P-Preferred-Identity was included, then use the default public user identity for the security association or TLS session and the associated contact address as the public user identity for this request;
The UE shall not include its "+sip.instance" header field parameter in the Contact header field in its non-register requests and responses except when the request or response is guaranteed to be sent to a trusted intermediary that will remove the "+sip.instance" header field parameter prior to forwarding the request or response to the destination.
If this is a request for a new dialog, the Contact header field is populated as follows:
  1. a contact header value which is one of:
    • if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user identity to be used for this request, and the UE does not indicate privacy of the P-Asserted-Identity, then the UE should insert the public GRUU ("pub-gruu" header field parameter) value as specified in RFC 5627; or
    • if a temporary GRUU value ("temp-gruu" header field parameter) has been saved associated with the public user identity to be used for this request, and the UE does indicate privacy of the P-Asserted-Identity, then the UE should insert the temporary GRUU ("temp-gruu" header field parameter) value as specified in RFC 5627;
    • otherwise, a SIP URI containing the contact address of the UE that has been previously registered without any contact parameters dedicated to registration procedure;
  2. include an "ob" SIP URI parameter, if the UE supports multiple registrations, and the UE wants all subsequent requests in the dialog to arrive over the same flow identified by the flow token as described in RFC 5626;
  3. if the request is related to an IMS communication service that requires the use of an ICSI then the UE shall include in a g.3gpp.icsi-ref media feature tag, as defined in subclause 7.9.2 and RFC 3841, the ICSI value (coded as specified in subclause 7.2A.8.2) for the IMS communication service. The UE may also include other ICSI values that the UE is prepared to use for all dialogs with the terminating UE(s); and
  4. if the request is related to an IMS application that is supported by the UE, then the UE may include in a g.3gpp.iari-ref media feature tag, as defined in subclause 7.9.3 and RFC 3841, the IARI value (coded as specified in subclause 7.2A.9.2) that is related to the IMS application and that applies for the dialog.
If this is a request within an existing dialog, and the request includes a Contact header field, then the UE should insert the previously used Contact header field.
If the UE support multiple registrations as specified in RFC 5626, the UE should include option-tag "outbound" in the Supported header field.
If this is a request for a new dialog or standalone transaction and the request is related to an IMS communication service that requires the use of an ICSI then the UE:
  1. shall include the ICSI value (coded as specified in subclause 7.2A.8.2), for the IMS communication service that is related to the request in a P-Preferred-Service header field according to RFC 6050. If a list of network supported ICSI values was received as specified in TS 24.167, the UE shall only include an ICSI value that is in the received list;
  2. may include an Accept-Contact header field containing an ICSI value (coded as specified in subclause 7.2A.8.2) that is related to the request in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 if the ICSI for the IMS communication service is known. The UE may remove one or more subclasses from an ICSI when including it in an Accept-Contact header field provided that the included ICSI corresponds to an IMS communication service.
If an IMS application indicates that an IARI is to be included in a request for a new dialog or standalone transaction, the UE shall include an Accept-Contact header field containing an IARI value (coded as specified in subclause 7.2A.9.2) that is related to the request in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3841.
After the dialog is established the UE may change the dialog capabilities (e.g. add a media or request a supplementary service) if defined for the IMS communication service as identified by the ICSI value using the same dialog. Otherwise, the UE shall initiate a new initial request to the other user.
The UE can indicate privacy of the P-Asserted-Identity that will be generated by the P-CSCF in accordance with RFC 3323, and the additional requirements contained within RFC 3325.
If resource priority in accordance with RFC 4412 is required for a dialog, then the UE shall include the Resource-Priority header field in all requests associated with that dialog.
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 CANCEL requests) or response (except CANCEL responses) within a dialog or any request for a standalone method (see subclause 7.2A.4). Insertion of the P-Access-Network-Info header field into the ACK request is optional.
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:
  1. the P-CSCF URI containing the IP address acquired at the time of the P-CSCF discovery procedures which was used in registration of the contact address (or registration flow); and
  2. 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;
  3. and the values received in the Service-Route header field saved from the 200 (OK) response to the last registration or reregistration of the public user identity with associated contact address.
The UE may indicate that proxies should not fork the request by including a "no-fork" directive within the Request-Disposition header field in the request as described in RFC 3841.
If a request is for a new dialog or standalone transaction, and the request matches a trigger for starting logging of SIP signalling, as described in RFC 8497 and configured in the trace management object defined in TS 24.323, the UE shall:
  • start to log SIP signalling for this dialog; and
  • in any requests or responses sent on this dialog, append a "logme" header field parameter to the SIP Session-ID header field.
If a request or response is sent on a dialog for which logging of signalling is in progress, the UE shall check whether a trigger for stopping logging of SIP signalling has occurred, as described in RFC 8497 and configured in the trace management object defined in TS 24.323.
  1. If a stop trigger event has occurred, the UE shall stop logging of signalling; or
  2. if a stop trigger event has not occurred, the UE shall:
    • in any requests or responses sent on this dialog, append a "logme" header field parameter to the SIP Session-ID header field; and
    • log the request.
If the UE receives a 1xx or 200 (OK) response to an initial request for a dialog, the response containing a P-Asserted-Identity header field set to an emergency number as specified in TS 22.101, the UE procedures in subclause 5.1.6.10 apply.
If the UE receives a 3xx response containing a Contact header field:
  1. if the 3xx response is a 380 (Alternative Service) response to an INVITE request the response containing a P-Asserted-Identity header field with a value equal to the value of the last entry of the Path header field value received during registration and the response contains a 3GPP IM CN subsystem XML body that includes an <ims-3gpp> element, including a version attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see Table 7.6.2) then the UE shall select a domain in accordance with the conventions and rules specified in TS 22.101 and TS 23.167, and:
    • if the CS domain is selected, the UE behavior is defined in subclause 7.1.2 of TS 23.167 and, where appropriate, in the access technology specific annex;
    • if the IM CN subsystem is selected, the UE shall apply the procedures in subclause 5.1.6 with the exception of selecting a domain for the emergency call attempt; and
  2. if the response is:
    • not a 380 (Alternative Service) response; or
    • a 380 (Alternative Service) response, and the response:
      1. does not contain a 3GPP IM CN subsystem XML body that includes an <ims-3gpp> element, including a version attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see Table 7.6.2); or
      2. does contain a 3GPP IM CN subsystem XML body that includes an <ims-3gpp> element, including a version attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see Table 7.6.2), and the response;
        1. does not contain a P-Asserted-Identity header field; or
        2. does contain a P-Asserted-Identity header field with a value not equal to the value of the last entry of the Path header field value received during registration;
    the UE should not automatically recurse on the Contact header field without first indicating the identity of the user to which a request will be sent and obtaining authorisation of the served user.
The UE performing the functions of an external attached network operating in static mode shall send all requests using the already established TLS session as described in this subclause.
A UE supporting RFC 4028, when it receives a 422 (Session Interval Too Small) to an INVITE request where the response contains a Min-SE header field, shall retry the request in accordance with Section 7.4 of RFC 4028.
Up
5.1.2A.1.2  Structure of Request-URI |R8|p. 135
The UE may include a SIP URI complying with RFC 3261, a tel URI complying with RFC 3966, a pres URI complying with RFC 3859, an im URI complying with RFC 3860 or a mailto URI complying with RFC 2368.
The UE may use non-international formats of E.164 numbers or non-E.164 numbers, including geo-local numbers and home-local numbers and other local numbers (e.g. private number), in the Request-URI.
The actual value of the URI depends on whether user equipment performs an analysis of the dial string input by the end user or not, see subclauses 5.1.2A.1.3 and 5.1.2A.1.4.
Up
5.1.2A.1.3  UE without dial string processing capabilities |R8|p. 135
In this case the UE does not perform any analysis of the dial string. This requires that the dialling plan is designed so it enables the network to differentiate local numbers from other numbers.
The dial string is sent to the network, in the Request-URI of a initial request or a stand alone transaction, using one of the following formats:
  1. a tel-URI, syntactically complying with RFC 3966, with the dial string encoded as a local number followed by a "phone-context" tel URI parameter value;
    EXAMPLE:
    tel:00447700900123;phone-context=example.com
  2. a SIP URI, syntactically complying with RFC 3261, with the user=phone parameter, embedding a tel-URI with a "phone-context" tel URI parameter value;
    EXAMPLE:
    sip:00447700900123;
    phone-context=example.com@example.com;user=phone
  3. a SIP URI, complying with RFC 3261 and RFC 4967, with the user=dialstring parameter and with a "phone-context" tel-URI parameter value in the user part; or
    EXAMPLE:
    sip:00447700900123;
    phone-context=example.com@example.com;user=dialstring
  4. a SIP URI syntactically complying with RFC 3261, where the user part contains the dial string and the domain name is specific enough to enable to network to understand that the user part contains a dial string.
    EXAMPLE:
    sip:00447700900123@dialstrings.entreprise.com
For cases 1), 2), and 3) the UE shall set the "phone-context" tel URI parameter in accordance with subclause 5.1.2A.1.5.
Up
5.1.2A.1.4  UE with dial string processing capabilities |R8|p. 135
In this case the UE performs sufficient dial string analysis (or receives an explicit indication from the user) to identify the type of numbering that is used and processes the dial string accordingly before building the Request-URI.
If the UE detects that a local dialling plan is being used, where the UE is able to identify a global telephone number, the UE shall translate the number into E.164 international format after removing all dial string elements used for local numbering detection purposes (e.g. escape codes).
If the UE detects that a local (private or public) dialling plan is being used and the UE is not able to identify a global number, it may decide to send the dial string unchanged to the network as described in subclause 5.1.2A.1.3 or the UE may decide to alter it to comply with the local numbering plan (e.g. remove all dial string elements used for local numbering detection).
In the latter case the local numbering information is sent using one of the following formats:
  1. a tel-URI, complying with RFC 3966, with a local number followed by a "phone-context" tel-URI parameter value;
  2. a SIP URI, complying with RFC 3261, with the "user" SIP URI parameter set to "phone" and a user part embedding a local number with a phone-context parameter; and
  3. if the UE intends to send information related to supplementary services, a SIP URI, complying with RFC 3261 and RFC 4967, with the "user" SIP URI parameter set to "dialstring" and with a "phone-context" tel URI parameter value in the user part.
The UE shall set the "phone-context" tel URI parameter in accordance with subclause 5.1.2A.1.5.
As a general rule, recognition of special service numbers shall take priority over other dialling plan issues. If the dial string equates to a pre-configured service URN as specified in RFC 5031) then the service-urn should be sent.
Up
5.1.2A.1.5  Setting the "phone-context" tel URI parameter |R8|p. 136
When the UE uses home-local number, the UE shall include in the "phone-context" tel URI parameter the home network domain name in accordance with RFC 3966.
When the UE uses geo-local number, the UE shall:
  • if access technology information available to the UE (i.e., the UE can insert P-Access-Network-Info header field into the request), include the access technology information in the "phone-context" tel URI parameter according to RFC 3966 as defined in subclause 7.2A.10; and
  • if access technology information is not available to the UE (i.e., the UE cannot insert P-Access-Network-Info header field into the request), include in the "phone-context" tel URI parameter the home network domain name prefixed by the "geo-local." string according to RFC 3966 as defined in subclause 7.2A.10.
When the UE uses other local numbers, than geo-local number or home local numbers, e.g. private numbers that are different from home-local number or the UE is unable to determine the type of the dialled number, the UE shall include a "phone-context" tel URI parameter set according to RFC 3966, e.g. if private numbers are used a domain name to which the private addressing plan is associated. The "phone-context" value used in the case of other local numbers shall be different from "phone-context" values used with geo-local numbers and home-local numbers.
Up
5.1.2A.1.5A  Policy on local numbers |R14|p. 136
Policy on local numbers consists of zero or more parts of policy on local numbers
A part of policy on local numbers indicates an IMS communication service (identified by an ICSI) in which the UE is to use a number in non-international format without associated "phone-context" value as:
  1. a geo-local number; or
  2. a home-local number.
The UE may support the policy on local numbers.
If the UE supports the policy on local numbers:
  1. if:
    1. the upper layers provide a number in non-international format to be included in Request-URI of a SIP request;
    2. the upper layers do not provide a "phone-context" value associated with the number;
    3. the UE is not configured to associate a particular "phone-context" value with the number; and
    4. the SIP request is related to an IMS communication service (identified by an ICSI) indicated in a part of the policy on local numbers such that:
      1. the part of the policy on local numbers indicates to use the number as a geo-local number, then the UE shall use the number as a geo-local number in subclause 5.1.2A.1.5; and
      2. the part of the policy on local numbers indicates to use the number as a home-local number, then the UE shall use the number as a home-local number in subclause 5.1.2A.1.5; and
  2. the UE may support being configured with the policy on local numbers using one or more of the following methods:
    1. the Policy_on_local_numbers node of the EF IMSConfigData file described in TS 31.102;
    2. the Policy_on_local_numbers node of the EF IMSConfigData file described in TS 31.103; and
    3. the Policy_on_local_numbers node of TS 24.167.
    If the UE is configured with both the Policy_on_local_numbers node of TS 24.167 and the Policy_on_local_numbers node of the EF IMSConfigData file described in TS 31.102 or the Policy_on_local_numbers node of the EF IMSConfigData file described in TS 31.103, then the Policy_on_local_numbers node of the EF IMSConfigData file shall take precedence.
Up
5.1.2A.1.6  Abnormal cases |R8|p. 137
In the event the UE receives a 504 (Server Time-out) response containing:
  1. a P-Asserted-Identity header field set to a value equal to a URI:
    1. from the Service-Route header field value received during registration; or
    2. from the Path header field value received during registration; and
  2. a Content-Type header field set according to subclause 7.6 (i.e. "application/3gpp-ims+xml"), independent of the value or presence of the Content-Disposition header field, independent of the value or presence of Content-Disposition parameters,
then the following treatment is applied:
  1. if the 504 (Server Time-out) response includes an IM CN subsystem XML body as described in subclause 7.6 with the <ims-3gpp> element, including a version attribute, with the <alternative-service> child element:
    1. with the <type> child element set to "restoration" (see Table 7.6.2); and
    2. with the <action> child element set to "initial-registration" (see Table 7.6.3);
    then the UE:
    • shall initiate S-CSCF restoration procedures by performing an initial registration as specified in subclause 5.1.1.2; and
    • may provide an indication to the user based on the text string contained in the <reason> child element of the <alternative-service> child element of the <ims-3gpp> element.
When sending a request from a contact address that has been previously registered (or via a registration flow if the multiple registration mechanism is used) which is bound to a public user identity by registration which used a P-CSCF address, and:
  • if timer F expires in the "Trying" state of non-INVITE client transaction as described in RFC 3261;
  • if a fatal transport error is reported by the transport layer in the "Trying" state of non-INVITE client transaction as described in RFC 3261;
  • if timer B expires in the "Calling" state of INVITE client transaction as described in RFC 6026; or
  • if a fatal transport error is reported by the transport layer in "Calling" state of INVITE client transaction as described in RFC 6026;
then the UE shall:
  1. if the multiple registration mechanism is not used:
    1. consider the contact address as not bound to any public user identity;
    2. mark the currently used P-CSCF address (i.e. P-CSCF address using which the contact address was registered) as unavailable;
    3. if there is a locally stored P-CSCF addressas specified in subclause 5.1.9 which is different than thecurrently used P-CSCF address and which is not marked as unavailable, initiate an initial registration as specified in subclause 5.1.1.2 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, 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; and
  2. if the multiple registration mechanism is used, declare the registration flow dead as defined in RFC 5626 and mark the currently used P-CSCF address as unavailable.
When sending a request from a contact address that has been previously registered (or via a registration flow if the multiple registration mechanism is used) which is bound to a public user identity by registration which used a P-CSCF address, and if a 503 (Service Unavailable) response without a Retry-After header field is received for request as described in RFC 3261, the UE shall:
  1. if the multiple registration mechanism is not used:
    1. consider the contact address as not bound to any public user identity;
    2. mark the currently used P-CSCF address (i.e. P-CSCF address using which the contact address was registered) as unavailable;
    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, initiate an initial registration as specified in subclause 5.1.1.2 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, 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; and
  2. if the multiple registration mechanism is used, declare the registration flow dead as defined in RFC 5626 and mark the currently used P-CSCF address as unavailable.
When sending a request from a contact address that has been previously registered (or via a registration flow if the multiple registration mechanism is used) which is bound to a public user identity by registration which used a P-CSCF address, and if a 503 (Service Unavailable) response with a Retry-After header field is received for request as described in RFC 3261 and :
  • if the request was a non-INVITE request, the Retry-After header field indicates a time bigger than value for timer F as specified in Table 7.7.1; and
  • if the request was an INVITE request, the Retry-After header field indicates a time bigger than value for timer B as specified in Table 7.7.1;
the UE shall:
  1. if the multiple registration mechanism is not used:
    1. consider the contact address as not bound to any public user identity;
    2. mark the currently used P-CSCF address (i.e. P-CSCF address using which the contact address was registered) as unavailable for the time indicated by the Retry-After header field;
    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, initiate an initial registration as specified in subclause 5.1.1.2 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, 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; and
  2. if the multiple registration mechanism is used, declare the registration flow dead as defined in RFC 5626 and mark the currently used P-CSCF address as unavailable for the time indicated by the Retry-After header field.
Up

5.1.2A.2  UE-terminating casep. 139

The procedures of this subclause are general to all requests and responses, except those for the REGISTER method.
Where a security association or TLS session exists, the UE shall discard any SIP request that is not protected by the security association or TLS session and is received from the P-CSCF outside of the registration and authentication procedures. The requirements on the UE within the registration and authentication procedures are defined in subclause 5.1.1.
If an initial request contains an Accept-Contact header field containing the g.3gpp.icsi-ref media feature tag with an ICSI value, the UE should invoke the IMS application that is the best match for the ICSI value.
If an initial request contains an Accept-Contact header field containing the g.3gpp.iari-ref media feature tag with an IARI value the UE should invoke the IMS application that is the best match for the IARI value.
The UE can receive multiple ICSI values, IARI values or both in an Accept-Contact header field. In this case it is up to the implementation which of the multiple ICSI values or IARI values the UE takes action on.
If an initial request does not contain an Accept-Contact header field containing a g.3gpp.icsi-ref media feature tag or a g.3gpp.iari-ref media feature tag the UE shall invoke the application that is the best match based on the contents of the request (e.g. SDP media capabilities, Content-Type header field, media feature tag).
The UE can indicate privacy of the P-Asserted-Identity that will be generated by the P-CSCF in accordance with RFC 3323, and the additional requirements contained within RFC 3325.
The UE shall not include its "+sip.instance" header field parameter in the Contact header field in its non-register requests and responses except when the request or response is guaranteed to be sent to a trusted intermediary that will remove the "+sip.instance" header field parameter prior to forwarding the request or response to the destination.
If the response includes a Contact header field, and the response is sent within an existing dialog, and the Contact address previously used in the dialog was a GRUU, then the UE should insert the previously used GRUU value in the Contact header field as specified in RFC 5627.
If the response includes a Contact header field, and the response is not sent within an existing dialog, the Contact header field is populated as follows:
  1. if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user identity from the P-Called-Party-ID header field, and the UE does not indicate privacy of the contents of the P-Asserted-Identity header field, then the UE should insert the public GRUU ("pub-gruu" header field parameter) value as specified in RFC 5627;
  2. if a temporary GRUU value ("temp-gruu" header field parameter) has been saved associated with the public user identity from the P-Called-Party-ID header field, and the UE does indicate privacy of the P-Asserted-Identity, then should insert the temporary GRUU ("temp-gruu" header field parameter) value in the Contact header field as specified in RFC 5627;
  3. if the request is related to an IMS communication service that requires the use of an ICSI then the UE shall include in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 and RFC 3841 the ICSI value (coded as specified in subclause 7.2A.8.2), for the IMS communication service and then the UE may include the IARI value for any IMS application that applies for the dialog, (coded as specified in subclause 7.2A.9.2), that is related to the request in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3841. The UE may also include other ICSI values that the UE is prepared to use for all dialogs with the originating UE(s) and other IARI values for the IMS application that is related to the IMS communication service; and
  4. if the request is related to an IMS application that is supported by the UE when the use of an ICSI is not needed, then the UE may include the IARI value (coded as specified in subclause 7.2A.9.2), that is related to any IMS application and that applies for the dialog, in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3841.
After the dialog is established the UE may change the dialog capabilities (e.g. add a media or request a supplementary service) if defined for the IMS communication service as identified by the ICSI value using the same dialog. Otherwise, the UE shall initiate a new initial request to the other user.
If the UE did not insert a GRUU in the Contact header field then the UE shall include a contact address that has been previously registered with contact parameters used for registration removed and a port in the address in the Contact header field as follows:
  • if IMS AKA or SIP digest with TLS is being used as a security mechanism, the protected server port value as in the initial registration; or
  • if SIP digest without TLS is being used as a security mechanism, the port value of an unprotected port where the UE expects to receive subsequent mid-dialog requests. The UE shall set the unprotected port value to the port value used in the initial registration.
If the UE receives a Resource-Priority header field in accordance with RFC 4412 in an initial request for a dialog, then the UE shall include the Resource-Priority header field in all requests associated with that dialog.
If available to the UE (as defined in the access technology specific annexes for each access technology), the UE shall insert a P-Access-Network-Info header field into any response to a request for a dialog, any subsequent request (except CANCEL requests) or response (except CANCEL responses) within a dialog or any response to a standalone method (see subclause 7.2A.4).
The terminating UE shall not include the P-Early-Media header field in any SIP messages, unless the terminating UE is a UE performing the functions of an external attached network that is allowed to send early media.
If a request or response is sent on a dialog for which logging of signalling is in progress, the UE shall check whether a trigger for stopping logging of SIP signalling has occurred, as described in RFC 8497 and configured in the trace management object defined in TS 24.323.
  1. If a stop trigger event has occurred, the UE shall stop logging of signalling; or
  2. if a stop trigger event has not occurred, the UE shall:
    • in any requests or responses sent on this dialog, append a "logme" header field parameter to the SIP Session-ID header field; and
    • log the request or response.
The UE shall not support RFC 7090 (see Table A.4, item A.4/116) and, in this version of the specification, the UE shall not perform any specific procedures beyond those defined in RFC 3261 for the Priority header field.
If the terminating UE needs to retrieve the last service access number when the AS applies a number translation as described in subclause 5.7.1.22; the terminating UE can find the requested service access number in the hi-entry within the History-Info header field having a hi-index that match the "mp" or "rc" header field parameter value of the last hi-entry containing a "cause" SIP URI parameter, defined in RFC 4458, set to the value "380" defined in RFC 8119. If no "mp" or "rc" header field parameter is received in the concerned hi-entry, the service access number can be found in the hi-entry preceding the hi-entry with the "cause" SIP URI parameter set to "380".
If the terminating UE
  1. supports calling number verification status determination;
  2. during registration determined that the home network supports calling number verification using signature verification as and attestation information, as defined in subclause 3.1; and
  3. receives initial INVITE request for a dialog or a MESSAGE request containing a P-Asserted-Identity header field or a From header field with a "verstat" tel URI parameter in a tel URI or a SIP URI with a user=phone parameter;
then the terminating UE shall:
  1. determine the calling number verification status based on the "verstat" tel URI parameter value; and
  2. if unable to determine the calling number verification status based on the "verstat" parameter value, discard the parameter and treat the P-Asserted-Identity header field and the From header field in the same way as if the parameter would not have been included.
Up

5.1.3  Call initiation - UE-originating casep. 142

5.1.3.1  Initial INVITE requestp. 142

Where multiple domains exist for initiating a call/session, before sending an initial INVITE request, the UE shall perform access domain selection in accordance with the appropriate specification for the IP-CAN in use, taking into account the media to be requested. Access domain selection allows the policy of the network operator to be taken into account before the initial INVITE request is sent. Access dependent aspects of access domain selection are defined in the access technology specific annexes for each access technology.
Upon generating an initial INVITE request, the UE shall include the Accept header field with "application/sdp", the MIME type associated with the 3GPP IM CN subsystem XML body (see subclause 7.6.1) and any other MIME type the UE is willing and capable to accept.
The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the precondition mechanism" and is defined in RFC 3312 as updated by RFC 4032.
The preconditions mechanism should be supported by the originating UE.
If the precondition mechanism is disabled as specified in subclause 5.1.5A, the UE shall not use the precondition mechanism.
The UE may initiate a session without the precondition mechanism if the originating UE does not require local resource reservation.
In order to allow the peer entity to reserve its required resources, if the precondition mechanism is enabled as specified in subclause 5.1.5A; the originating UE supporting the precondition mechanism should make use of the precondition mechanism, even if it does not require local resource reservation.
Upon generating an initial INVITE request using the precondition mechanism, the UE shall:
  • indicate the support for reliable provisional responses and specify it using the Supported header field; and
  • indicate the support for the preconditions mechanism and specify it using the Supported header field.
Upon generating an initial INVITE request using the precondition mechanism, the UE shall not indicate the requirement for the precondition mechanism by using the Require header field.
During the session initiation, if the originating UE indicated the support for the precondition mechanism in the initial INVITE request and:
  1. the received response with an SDP body includes a Require header field with "precondition" option-tag, the originating UE shall include a Require header field with the "precondition" option-tag:
    • in subsequent requests that include an SDP body, that the originating UE sends in the same dialog as the response is received from; and
    • in responses with an SDP body to subsequent requests that include an SDP body and include "precondition" option-tag in Supported header field or Require header field received in-dialog; or
  2. the received response with an SDP body does not include the "precondition" option-tag in the Require header field,
    • in subsequent requests that include an SDP body, the originating UE shall not include a Require or Supported header field with "precondition" option-tag in the same dialog;
    • in responses with an SDP body to subsequent requests with an SDP body but without "precondition" option-tag in the Require or Supported header field, the originating UE shall not include a Require or Supported header field with "precondition" option-tag in the same dialog; and
    • in responses with an SDP body to subsequent requests with an SDP body and with "precondition" option-tag in the Require or Supported header field, the originating UE shall include a Require header field with "precondition" option-tag in the same dialog.
If the precondition mechanism is used, the UE shall, upon successful reservation of local resources, confirm the successful resource reservation (see subclause 6.1.2) within the next SIP request.
If the UE wishes to receive early media authorization indications, as described in RFC 5009, the UE shall add the P-Early-Media header field with the "supported" parameter to the initial INVITE request.
A UE supporting the Session Timer extension as described in RFC 4028 may support the extension being configured using Session_Timer_Support node specified in TS 24.167.
If the UE supports the Session Timer extension, the UE shall include the option-tag "timer" in the Supported header field and should either insert a Session-Expires header field with the header field value set to the configured session timer interval value, or should not include the Session-Expires header field in the initial INVITE request. The header field value of the Session-Expires header field may be configured using local configuration or using the Session_Timer_Initial_Interval node specified in TS 24.167. If the UE is configured with both the local configuration and the Session_Timer_Initial_Interval node specified in TS 24.167, then the local configuration shall take precedence.
If the UE inserts the Session-Expires header field in the initial INVITE request, the UE may also include the "refresher" parameter with the "refresher" parameter value set to "uac".
When a final answer is received for one of the early dialogs, the UE proceeds to set up the SIP session. The UE shall not progress any remaining early dialogs to established dialogs. Therefore, upon the reception of a subsequent final 200 (OK) response for an INVITE request (e.g., due to forking), the UE shall:
  1. acknowledge the response with an ACK request; and
  2. send a BYE request to this dialog in order to terminate it.
Upon receiving a 488 (Not Acceptable Here) response to an initial INVITE request, the originating UE should send a new INVITE request containing SDP according to the procedures defined in subclause 6.1.
Upon receiving a 421 (Extension Required) response to an initial INVITE request in which the precondition mechanism was not used, including the "precondition" option-tag in the Require header field, if the UE supports the precondition mechanism and the precondition mechanism is enabled as specified in subclause 5.1.5A, the originating UE shall:
  • send a new INVITE request using the precondition mechanism; and
  • send an UPDATE request as soon as the necessary resources are available and a 200 (OK) response for the first PRACK request has been received.
Upon receiving a 503 (Service Unavailable) response to an initial INVITE request containing a Retry-After header field, then the originating UE shall not automatically reattempt the request via the same P-CSCF until after the period indicated by the Retry-After header field contents.
The UE may include a "cic" tel URI parameter in a tel URI, or in the userinfo part of a SIP URI with user=phone, in the Request-URI of an initial INVITE request if the UE wants to identify a user-dialed carrier, as described in RFC 4694.
In the event the UE receives a 380 (Alternative Service) response to an initial INVITE request the response containing a P-Asserted-Identity header field with a value equal to the value of the last entry of the Path header field value received during registration and the response containing a 3GPP IM CN subsystem XML body that includes an <ims-3gpp> element, including a version attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see Table 7.6.2), the UE shall select a domain in accordance with the conventions and rules specified in TS 22.101 and TS 23.167, and:
  • if the CS domain is selected, the UE behavior is defined in subclause 7.1.2 of TS 23.167 and, where appropriate, in the access technology specific annex; and
  • if the IM CN subsystem is selected, the UE shall apply the procedures in subclause 5.1.6 with the exception of selecting a domain for the emergency call attempt.
Upon receiving a 199 (Early Dialog Terminated) provisional response to an established early dialog the UE shall release resources specifically related to that early dialog.
The UE shall include the media feature tags defined in RFC 3840 and RFC 5688] for all supported streaming media types in the initial INVITE request.
If the UE sends a CANCEL request to cancel an initial INVITE request, the UE shall when applicable include in the CANCEL request a Reason header field with a protocol value set to "RELEASE_CAUSE" and a "cause" header field parameter as specified in subclause 7.2A.18.11.2. The UE may also include the "text" header field parameter with reason-text as specified in subclause 7.2A.18.11.2.
Upon receiving a 500 (Server Internal Error) response to an initial INVITE request including a Reason header field with a protocol value set to "FAILURE_CAUSE" and a cause header field parameter value set to "1" as specified in subclause 7.2A.18.12.2 and a Response-Source header field with a "fe" header field parameter set to "<urn:3gpp:fe:p-cscf.orig>", the UE can determine that the QoS or bearer resources in the originating IP-CAN is not available.
Up

Up   Top   ToC