Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  17.1.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…

 

U.2A  Usage of SDPWord‑p. 954

U.2A.0  General

No additional procedures defined.

U.2A.1  Impact on SDP offer / answer of activation or modification of IP-CAN for media by the network

If, due to the activation of 5GS QoS flow from the network the related SDP media description needs to be changed, the UE shall update the related SDP information by sending a new SDP offer within a SIP request, which is sent over the existing SIP dialog.
If the UE receives a modification request from the network for a 5GS QoS flow that is used for one or more media streams in an ongoing SIP session, the UE shall:
  1. if, due to the modification of the 5GS QoS flow, the related SDP media description need to be changed, update the related SDP information by sending a new SDP offer within a SIP request, that is sent over the existing SIP dialog, and respond to the 5GS QoS flow modification request.
Up

U.2A.2  Handling of SDP at the terminating UE when originating UE has resources available and IP-CAN performs network-initiated resource reservation for terminating UE

If the UE receives an SDP offer where the SDP offer includes all media streams for which the originating side indicated its local preconditions as met, if the precondition mechanism is supported by the terminating UE and the IP-CAN performs network-initiated resource reservation for the terminating UE and the available resources are not sufficient for the received offer, the terminating UE shall indicate its local preconditions and provide the SDP answer to the originating side without waiting for resource reservation.
Up

U.2A.3  Emergency service

U.3  Application usage of SIP

U.3.1  Procedures at the UE

U.3.1.0  Registration and authentication

The UE shall perform reregistration of a previously registered public user identity bound to any one of its contact addresses when changing to an IP-CAN for which usage is specified in annex R or annex W. The reregistration is performed using the new IP-CAN.
If the UE supports the 3GPP PS data off, then the UE shall in all REGISTER requests include the "+g.3gpp.ps-data-off" header field parameter defined in subclause 7.9.8 set to a value indicating the 3GPP PS data off status.
When the UE sends a REGISTER request, if the 3GPP PS data off status is "active", then the UE shall only include media feature tags associated with services that are 3GPP PS data off exempt services in the 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.
If the UE is registered, and the 3GPP PS data off status is changed, then the UE shall perform a reregistration of the previously registered public user identity.
A UE supporting ANBR as specified in TS 26.114 shall also support RAN-assisted codec adaptation as specified in TS 38.300 and TS 38.321.
If the UE supports ANBR, upon receiving a 200 (OK) response to the REGISTER request and if the 200 (OK) response contains a Feature-Caps header field with the g.3gpp.anbr feature-capability indicator the UE shall assume that the Network supports RAN-assisted codec adaptation as specified in TS 38.300 and TS 38.321. The UE is allowed to include the SDP 'anbr' attribute during session establishment as specified in TS 26.114.
Up

U.3.1.0A  IMS_Registration_handling policy |R16|Word‑p. 955
The IMS_Registration_handling policy indicates whether the UE deregisters from IMS after a configured amount of time after receiving an indication that the IMS Voice over PS Session is not supported.
The UE may support the IMS_Registration_handling policy.
If the UE supports the IMS_Registration_handling policy, the UE may support being configured with the IMS_Registration_handling policy using one or more of the following methods:
  1. the IMS_Registration_Policy node of the EFIMSConfigData file described in TS 31.102;
  2. the IMS_Registration_Policy node of the EFIMSConfigData file described in TS 31.103; and
  3. the IMS_Registration_Policy node of TS 24.167.
If the UE is configured with both the IMS_Registration_Policy node of TS 24.167 and the IMS_Registration_Policy node of the EFIMSConfigData file described in TS 31.102 or TS 31.103, then the IMS_Registration_Policy node of the EFIMSConfigData file shall take precedence.
If the UE is registered with IMS and the IMSVoPS indicator, provided by the lower layers (see TS 24.501), indicates voice is not supported, the UE shall:
  1. if the Stay_Registered_When_VoPS_Not_Supported leaf indicates requirement to stay registered, the UE needs not to deregister and maintains the registration as required for IMS services; or
  2. if the Stay_Registered_When_VoPS_Not_Supported leaf indicates requirement to deregister and the Deregistration_Timer leaf used to configure the NoVoPS-dereg timer defined in table 7.8.1 contains a timer value for the time to wait before deregistrerting from IMS, start a timer with the value indicated in the policy and:
    1. if the timer expires before the UE receives an indication from the lower layers that IMS voice is supported:
      1. if there is no ongoing IMS session, the UE either performs reregistration as specified in subclause 5.1.1.4 and shall only include feature tags associated with services that are independent of IMSVoPS indicator or deregister from the IMS following the procedures specified in subclause 5.1.1.6; or
      2. if there is ongoing IMS session, and
        1. if the UE does not receive indication from the lower layer that the IMS voice is supported before the ongoing IMS session is terminated, the UE either performs reregistration as specified in subclause 5.1.1.4 and shall only include feature tags associated with services that are independent of IMSVoPS indicator or deregister from the IMS following the procedures specified in subclause 5.1.1.6 as soon as the ongoing IMS based service is terminated; or
        2. if the UE receives indication from the lower layer that the IMS voice is supported before the ongoing IMS session is terminated, cancel the timer; or
    2. if the UE receives an indication from the lower layers that IMS voice is supported before the timer expires, cancel the timer.
If the IMS_Registration_handling policy is not configured, the UE behaviour is implementation specific.
Up

U.3.1.1  P-Access-Network-Info header fieldWord‑p. 956
The UE shall always include the P-Access-Network-Info header field where indicated in subclause 5.1.

U.3.1.1A  Cellular-Network-Info header field

Not applicable.

U.3.1.2  Availability for calls

This subclause documents the minimal requirements for being available for voice communication services when using 5GS.
A UE shall perform an initial registration as specified in subclause 5.1.1.2 using a QoS flow for SIP signalling (see annex U.2.2.1), if all the following conditions are met:
  1. if the UE is operating in the "voice centric" way;
  2. if the UE is capable of receiving any (but not necessarily all) of the media types which the CS domain supports, such that the media type can also be used when accessing the IM CN subsystem using:
    1. the 5GS IP-CAN via NR;
    2. the 5GS IP-CAN via E-UTRA; or
    3. the EPS IP-CAN;
  3. if:
    1. the media type of item 2 is an "audio" media type;
    2. the UE supports codecs suitable for (conversational) speech; and
    3. the "audio" media type is not restricted from inclusion in an SDP message according to the media type restriction policy as specified in subclause 6.1.1;
    and one of the following is true:
    1. 3GPP PS data off status is "inactive";
    2. 3GPP PS data off status is "active", the UE is in the HPLMN or the EHPLMN, and MMTEL voice is a 3GPP PS data off exempt service; or
    3. 3GPP PS data off status is "active", the UE is in the VPLMN, the UE is configured with an indication that MMTEL voice is a 3GPP PS data off exempt service in a VPLMN, and MMTEL voice is a 3GPP PS data off roaming exempt service;
  4. if the UE determines that its contact has not been bound to a public user identity using the IP-CAN, such that the contact is expected to be used for the delivery of incoming requests in the IM CN subsystem relating to the media of item 2 and item 3;
  5. if the IMSVoPS indicator, provided by the lower layers indicates voice is supported;
  6. if the procedures to perform the initial registration are enabled (see TS 24.305); and
  7. if the PDU session used for IMS is:
    1. available; or
    2. not available, and the UE is allowed to send a PDU SESSION ESTABLISHMENT REQUEST message to establish a PDU session with 5GS QoS flow that is needed for performing the initial registration as described in U.2.2.1.
EXAMPLE:
As an example of the note, a UE configured to preferably attempt to use the 5GS to access IM CN subsystem can perform an initial registration as specified in subclause 5.1.1.2, if the conditions in items 2, 3, 4, 5, 6 and 7 in this subclause, evaluate to true.
The UE indicates to the non-access stratum the status of being available for voice over PS when:
  1. the UE is capable of receiving any (but not necessarily all) of the media types which the CS domain supports, such that the media type can also be used when accessing the IM CN subsystem using:
    1. the 5GS IP-CAN via NR;b) the 5GS IP-CAN via E-UTRA; or
    2. the EPS IP-CAN;
  2. if the media type of item I is an "audio" media type, the UE supports codecs suitable for (conversational) speech, the "audio" media type is not restricted from inclusion in an SDP message according to the media type restriction policy as specified in subclause 6.1.1; and:
    1. 3GPP PS data off status is "inactive";
    2. 3GPP PS data off status is "active", the UE is in the HPLMN or the EHPLMN, and MMTEL voice is a 3GPP PS data off exempt service; or
    3. 3GPP PS data off status is "active", the UE is in the VPLMN, the UE is configured with an indication that MMTEL voice is a 3GPP PS data off exempt service in a VPLMN, and MMTEL voice is a 3GPP PS data off roaming exempt service; and
  3. the UE determines a contact has been bound to a public user identity using the IP-CAN, such that this contact is expected to be used for the delivery of incoming requests in the IM CN subsystem relating to such media.
The UE indicates to the non-access stratum the status of being not available for voice over PS when:
  1. in response to receiving the IMSVoPS indicator indicating voice is supported, the UE:
    • initiated an initial registration as specified in subclause 5.1.1.2, received a final response to the REGISTER request sent, but the conditions for indicating the status of being available for voice over PS are not met; or
    • did not initiate an initial registration as specified in subclause 5.1.1.2 and, these conditions for indicating the status of being available for voice over PS are not met; or
  2. the conditions for indicating the status of being available for voice over PS are no longer met.
Up

U.3.1.2A  Availability for SMSWord‑p. 958
The UE determines that the UE is able to use SMS using IMS if the UE:
  1. is capable of using the MIME type "application/vnd.3gpp.sms" (see TS 24.341), such that the MIME type can also be used when accessing the IM CN subsystem using the current IP-CAN;
  2. supports the role of an SM-over-IP sender (see TS 24.341);
  3. determines the PDU session used for IMS exists;
  4. determines a contact has been bound to a public user identity using the IP-CAN, such that this contact is expected to be used for the delivery of incoming requests in the IM CN subsystem relating to such media; and
  5. the UE does not determine that SMS over IP is restricted in TS 24.341 subclause 5.2.1.3; and
  6. the 3GPP PS data off status is:
    • "inactive";
    • "active", the UE is in the HPLMN or the EHPLMN, and SMS over IMS is a 3GPP PS data off exempt service; or
    • "active", the UE is in the VPLMN, the UE is configured with an indication that SMS over IMS is a 3GPP PS data off roaming exempt service in a VPLMN, and SMS over IMS is a 3GPP PS data off roaming exempt service.
When above criteria are not met, the UE determines that SMS using IMS is unavailable.
Up

U.3.1.3  Authorization header field

Void.

U.3.1.4  SIP handling at the terminating UE when precondition is not supported in the received INVITE request, the terminating UE does not have resources available and IP-CAN performs network-initiated resource reservation for the terminating UEWord‑p. 959
Upon receiving an INVITE request not including the "precondition" option-tag in the Supported header field and not including the "precondition" option-tag in the Require header field, and the IP-CAN performs network-initiated resource reservation for the UE, the UE:
  1. if the INVITE request contains an SDP offer and the local resources required at the terminating UE for the received SDP offer are not available:
    1. shall not alert the user; and
    2. shall send 183 (Session Progress) response to the INVITE request without waiting for resource reservation and without alerting the user. If the INVITE request includes a Supported header field indicating support of reliable provisional responses, the UE shall send the 183 (Session Progress) response reliably. In the 183 (Session Progres) response, the UE shall include an SDP answer; and
  2. if the INVITE request does not contain an SDP offer and the INVITE request includes a Supported header field indicating support of reliable provisional responses:
    1. shall generate an SDP offer;
    2. if the local resources required at the terminating UE for the generated SDP offer are not available:
      1. shall not alert the user; and
      2. shall reliably send 183 (Session Progress) response to the INVITE request without waiting for resource reservation and without alerting the user. In the 183 (Session Progres) response, the UE shall include the generated SDP offer.
Upon successful reservation of local resources, if the precondition mechanism is not used by the terminating UE, the UE can send 180 (Ringing) response to the INVITE request and can alert the user.
Up

U.3.1.5  3GPP PS data off

If the 3GPP PS data off status is "active" the UE shall only send initial requests that:
  1. are associated with a 3GPP IMS service which enforces 3GPP PS data off;
  2. are associated with an emergency service; or
  3. are associated with 3GPP PS data off exempt services configured in the UE using one or more of the following methods:
    • the non_3GPP_ICSIs_exempt node specified in TS 24.167, if the UE is in the HPLMN or the EHPLMN, or if the UE is in the VPLMN and the non_3GPP_ICSIs_roaming_exempt node specified in TS 24.167 is not configured;
    • the non_3GPP_ICSIs_roaming_exempt node specified in TS 24.167, if the UE is in the VPLMN;
    • the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, if the UE is in the HPLMN or the EHPLMN, or if the UE is in the VPLMN and the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 is not configured; or
    • the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, if the UE is in the VPLMN.
    If the UE is configured with both the non_3GPP_ICSIs_exempt node of TS 24.167 and the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 shall take precedence.
    If the UE is configured with both the non_3GPP_ICSIs_roaming_exempt node of TS 24.167 and the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 shall take precedence.
If the 3GPP PS data off status changes from "inactive" to "active" the UE shall release all dialogs that
  1. are not associated with a 3GPP IMS service which enforces 3GPP PS data off;
  2. are not associated with an emergency service; and
  3. are not associated with 3GPP data off exempt services configured in the UE using one or more of the following methods:
    • the non_3GPP_ICSIs_exempt node specified in TS 24.167, if the UE is in the HPLMN or the EHPLMN, or if the UE is in the VPLMN and the non_3GPP_ICSIs_roaming_exempt node specified in TS 24.167 is not configured;
    • the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, if the UE is in the VPLMN;
    • the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, if the UE is in the HPLMN or the EHPLMN, or if the UE is in the VPLMN and the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 is not configured; or
    • the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, if the UE is in the VPLMN.
    If the UE is configured with both the non_3GPP_ICSIs_exempt node of TS 24.167 and the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 shall take precedence.
    If the UE is configured with both the non_3GPP_ICSIs_roaming_exempt node of TS 24.167 and the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 shall take precedence.
Up

U.3.1.6  RLOS |R16|Word‑p. 960
Not applicable.

U.3.1.7  SIP handling at the originating UE when redirecting the UE from NG-RAN to E-UTRAN fails |R16|

When a failure occurs in the process of redirecting the UE from NG-RAN to E-UTRAN and the UE is aware of the failure, the UE shall send out a CANCEL request to cancel the INVITE request that includes a Reason header field with a protocol value set to "RELEASE_CAUSE" and a "cause" header field parameter with the value of "7" as specified in subclause 7.2A.18.11.2.

U.3.1.8  Unified Access Control |R16|

The following information is provided to the non-access stratum:
  • MO--IMS-registration-related-signalling-started; and
  • MO-IMS-registration-related-signalling-ended;
Prior to sending a REGISTER request which is not for emergency registration, the UE sends the MO-IMS-registration-related-signalling-started to the non-access stratum and
  1. if the barring result is "not-barred", continues with registration procedure as described in subclause 5.1.1; and
  2. if the barring result is "barred", aborts the registration procedure;
When the UE needs to send SUBSCRIBE request for the reg event package, then the UE sends the MO-IMS-registration-related-signalling-started to the non-access stratum before sending SUBSCRIBE request and
  1. if the barring result is "not-barred", continues with subscribe procedure as described in subclause 5.1.1.3; and
  2. if the barring result is "barred", aborts the subscribe procedure;
When a procedure for MO IMS registration related signalling ends, i.e.
  • a final response to the REGISTER request which is not for emergency registration is received;
  • a final response to the SUBSCRIBE request for the reg event package is received;
  • timer F expires at the UE; or
  • a fatal transport error for sending the REGISTER request or the SUBSCRIBE request is reported by the transport layer, as desribed in RFC 3261;
the UE sends the MO-IMS-registration-related-signalling-ended to the non-access stratum.
Up

U.3.1.9  Abnormal cases |R16|Word‑p. 961
Upon sending MO-IMS-registration-related-signalling-started indication to the non-access stratum as described in subclause U.3.1.8, if:
  1. the UE receives, from the lower layers, a notification that the service request
    1. was not accepted due to congestion; or
    2. resulted in starting timer T3525 (see TS 24.501); and
  2. a procedure for MO IMS registration related signalling has not ended;
then:
  1. the UE shall abort the procedure for MO-IMS-registration-related-signalling and send MO-IMS-registration-related-signalling-ended indication to the non-access stratum; and
  2. if an alternative radio access network is available, the UE may attempt the procedure for MO-IMS-registration-related signalling on the alternative radio access network.
Up

U.3.2  Procedures at the P-CSCF

U.3.2.0  Registration and authentication

Void.

U.3.2.1  Determining network to which the originating user is attached

If the P-CSCF is configured to handle emergency requests, in order to determine from which network the request was originated the P-CSCF shall check the MCC and MNC fields received:
  • during the registration procedure from the Rx interface as defined in TS 29.214 (e.g. used for deployments without IMS-level roaming interfaces where the P-CSCF is located in the home network); or
  • from the P-Access-Network-Info header field.
Up

U.3.2.2  Location information handlingWord‑p. 962
Void.

U.3.2.3  Prohibited usage of PDU session for emergency services

If the P-CSCF detects that a UE uses a PDU session for emergency services for a non-emergency REGISTER request, the P-CSCF shall reject that request by a 403 (Forbidden) response.

U.3.2.4  Support for paging policy differentiation

The P-CSCF may support paging policy differentiation by marking packet(s) to be sent towards the UE related to that IMS capability. A specific DSCP (IPv4) value and/or a specific Traffic Class (IPv6) value are assigned by local configuration in the P-CSCF.
If local policy requires to provide such marking, the P-CSCF shall identify terminating requests which:
  1. contain SDP with an "audio" media line and which are related to a IMS multimedia telephony service session specified in TS 24.173; or
  2. do not contain an SDP offer but some indication, e.g. a feature capability indicator, indicates that an "audio" media line that would meet network policy for such differentiation, could form part of the subsequent SDP offer.
For such identified requests:
  1. where an unreliable transport mechanism is used as the transport protocol for SIP, the P-CSCF shall mark packets containing an INVITE request; and
  2. if a reliable transport mechanism is used as the transport protocol for SIP:
    1. if a new reliable transport connection needs to be established, the P-CSCF shall turn on the marking of packets within the reliable transport connection in advance of sending an INVITE request; and
    2. if there is an existing reliable transport connection, the P-CSCF may turn on the marking of packets within the reliable transport connection in advance of sending an INVITE request.
    In both these cases for a reliable transport connection, the P-CSCF shall turn off the marking of packets within the reliable transport connection at an appropriate time.
Up

U.3.2.5Void

U.3.2.6  Resource sharing

This feature is not supported in this release.

U.3.2.7  Priority sharingWord‑p. 963
This feature is not supported in this release.

U.3.2.8  RLOS |R16|

Not applicable.

U.3.2.9  Support of ANBR and RAN-assisted codec adaptation |R16|

If the network supports ANBR as specified in TS 26.114 and RAN-assisted codec adaptation as specified in TS 38.300 and TS 38.321, then the P-CSCF might be configured to indicate ANBR support.
If the P-CSCF is configured to indicate ANBR support, when the P-CSCF receives the 200 (OK) response to the REGISTER request the P-CSCF shall include the "g.3gpp.anbr" feature-capability indicator in the Feature-Caps header field of the 200 (OK) response to the REGISTER request.
Up

U.3.3  Procedures at the S-CSCF

U.4  3GPP specific encoding for SIP header field extensions

U.5  Use of circuit-switched domain

There is no CS domain in this access technology.

Up   Top   ToC