L.3 Application usage of SIP

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

L.3.1 Procedures at the UE

L.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.

NOTE 1: This document does not specify how the UE detects that the used IP-CAN has changed. The information that is forcing the reregistration is also used to generate the content for the P-Access-Network-Info header field.

NOTE 2: The UE will send the reregistration irrespective of whether it has a SIP dialog or not.

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 [62], for the IMS communication services it intends to use.

If the UE is registered, and the 3GPP PS data off status is changed or the UE is provided by the network with a new list of 3GPP PS data off exempt services while the 3GPP PS data off status is "active", then the UE shall perform a reregistration of the previously registered public user identity.

A UE supporting ANBR as specified in 3GPP TS 26.114 [9B] shall also support RAN-assisted codec adaptation as specified in 3GPP TS 36.300 [268] and 3GPP TS 36.321 [269].

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 3GPP TS 36.300 [268] and 3GPP TS 36.321 [269]. The UE is allowed to include the SDP ‘anbr’ attribute during session establishment as specified in 3GPP TS 26.114 [9B].

L.3.1.0a IMS_Registration_handling policy

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:

a) the IMS_Registration_Policy node of the EF_{IMSConfigData} file described in 3GPP TS 31.102 [15C];

b) the IMS_Registration_Policy node of the EF_{IMSConfigData} file described in 3GPP TS 31.103 [15B]; and

c) the IMS_Registration_Policy node of 3GPP TS 24.167 [8G].

If the UE is configured with both the IMS_Registration_Policy node of 3GPP TS 24.167 [8G] and the IMS_Registration_Policy node of the EF_{IMSConfigData} file described in 3GPP TS 31.102 [15C] or 3GPP TS 31.103 [15B], then the IMS_Registration_Policy node of the EF_{IMSConfigData} file shall take precedence.

NOTE 1: Precedence for files configured on both the USIM and ISIM is defined in 3GPP TS 31.103 [15B].

If the UE is registered with IMS and the IMSVoPS indicator, provided by the lower layers (see 3GPP TS 24.301 [8J]), indicates voice is not supported, the UE shall:

A) 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

NOTE 2: The UE will periodically refresh the registration when needed.

B) 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:

a) 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

i) 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

ii) 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

NOTE 3: How the UE selects reregistration or deregistration is implementation dependent (e.g., SMS service)

b) 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.

L.3.1.1 P-Access-Network-Info header field

The UE shall always include the P-Access-Network-Info header field where indicated in subclause 5.1.

NOTE: If the P-Access-Network-Info header field includes radio cell identity, the P-Access-Network-Info header field populated by the UE that supports Multi-RAT Dual Connectivity with the EPC as described in 3GPP TS 37.340 [264] will contain the information about the radio cell identity of the Master RAN node that is serving the UE.

L.3.1.1A Cellular-Network-Info header field

Not applicable.

L.3.1.2 Availability for calls

This subclause documents the minimal requirements for being available for voice communication services when using EPS.

A UE shall perform an initial registration as specified in subclause 5.1.1.2 using an EPS bearer context for SIP signalling (see annex L.2.2.1), if all the following conditions are met:

1) if the UE is operating in one of the following modes of operation (see 3GPP TS 24.301 [8J]):

a) PS mode 1;

b) CS/PS mode 1 and the UE is attached for EPS-Services only;

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 the current IP-CAN;

3) if:

a) the media type of item 2 is an "audio" media type

b) the UE supports codecs suitable for (conversational) speech; and

c) 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:

a) 3GPP PS data off status is "inactive";

b) 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

c) 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 (see 3GPP TS 24.301 [8J]), indicates voice is supported;

6) if the procedures to perform the initial registration are enabled (see 3GPP TS 24.305 [8T]); and

7) if the EPS bearer context used for SIP signalling is:

a) available; or

b) not available, and the UE:

i. is allowed to send a PDN CONNECTIVITY REQUEST message to establish an EPS bearer context that is needed for performing the initial registration; or

ii. is allowed to send a BEARER RESOURCE ALLOCATION REQUEST message, wishes to establish an EPS bearer with the correct QCI and TFT for performing the initial registration, and a default EPS bearer context for the APN exists.

NOTE 1: 3GPP TS 24.301 [8J] specifies conditions that prevent the UE from sending a PDN CONNECTIVITY REQUEST message or a BEARER RESOURCE ALLOCATION REQUEST message.

NOTE 2: Regardless of any of the above conditions, a UE might attempt to register with the IM CN subsystem at any time.

EXAMPLE: As an example of the note, a UE configured to preferably attempt to use the EPS 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:

I) 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 the current IP-CAN;

II) 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:

a) 3GPP PS data off status is "inactive";

b) 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

III) 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:

I) 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

II) the conditions for indicating the status of being available for voice over PS are no longer met.

NOTE 3: The status of being not available for voice over PS is used for domain selection for UE originating sessions / calls specified in 3GPP TS 23.221 [6] subclause 7.2a.

L.3.1.2A Availability for SMS

The UE determines that the UE is able to use SMS using IMS if the UE:

I) is capable of using the MIME type "application/vnd.3gpp.sms" (see 3GPP TS 24.341 [8L]), such that the MIME type can also be used when accessing the IM CN subsystem using the current IP-CAN;

II) supports the role of an SM-over-IP sender (see 3GPP TS 24.341 [8L]);

IIA) determines the EPS bearer context used for SIP signalling exists;

III) 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;

IV) the UE does not determine that SMS over IP is restricted in 3GPP TS 24.341 [8L] subclause 5.2.1.3; and

V) 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 exempt service in a VPLMN, and SMS over IMS is a 3GPP PS data off roaming exempt service.

When above criteria are not matched, the UE determines that SMS using IMS is unavailable.

NOTE: The status that SMS using IMS is unavailable is used for domain selection for UE originating SMS specified in 3GPP TS 23.221 [6] subclause 7.2c.

L.3.1.3 Authorization header field

Void.

L.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 UE

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:

a) shall not alert the user; and

b) 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:

a) shall generate an SDP offer;

b) if the local resources required at the terminating UE for the generated SDP offer are not available:

A) shall not alert the user; and

B) 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.

L.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;

NOTE: These services are specified in 3GPP TS 22.011 [1C], and enforcement of 3GPP PS data off is described in the respective service specifications.

2) are associated with an emergency service;

3) are associated with access to RLOS; or

4) 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 3GPP TS 24.167 [8G], 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 3GPP TS 24.167 [8G] is not configured;

– the non_3GPP_ICSIs_roaming_exempt node specified in 3GPP TS 24.167 [8G], if the UE is in the VPLMN;

– the non_3GPP_ICSIs_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], 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 EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C] is not configured; or

– the non_3GPP_ICSIs_roaming_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], if the UE is in the VPLMN.

If the UE is configured with both the non_3GPP_ICSIs_exempt node of 3GPP TS 24.167 [8G] and the non_3GPP_ICSIs_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], then the non_3GPP_ICSIs_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C] shall take precedence.

If the UE is configured with both the non_3GPP_ICSIs_roaming_exempt node of 3GPP TS 24.167 [8G] and the non_3GPP_ICSIs_roaming_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], then the non_3GPP_ICSIs_roaming_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C] 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;

NOTE: These services are specified in 3GPP TS 22.011 [1C], and enforcement of 3GPP PS data off is described in the respective service specifications.

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_roaming_exempt node specified in 3GPP TS 24.167 [8G], if the UE is in the VPLMN;

– the non_3GPP_ICSIs_roaming_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], if the UE is in the VPLMN.

L.3.1.6 Transport mechanisms

No additional requirements are defined.

L.3.1.7 RLOS

L.3.1.7.1 General

The support for RLOS as described in this subclause is optional for the UE.

L.3.1.7.2 Registration

A UE containing a UICC on sending an unprotected REGISTER request for RLOS, shall perform the actions as specified in subclause 5.1.1.2 wih the following additions:

a) the UE shall in the REGISTER request include a "+g.3gpp.rlos" Contact header field parameter, as defined in subclause 7.9.9.

NOTE: The UE can choose to use initial registration using IMS AKA or initial registration using GPRS-IMS bundled authentication.

A UE not containing a UICC on sending an uprotected REGISTER request for RLOS shall perform the actions as specified in subclause 5.1.1.2 for registration using GPRS-IMS bundled authentication with the following additions:

a) the UE shall generate a home network domain name according to the rules specified in 3GPP TS 23.003 [3] using the PLMN to which the UE is currently attached and set the Request-URI to the SIP URI of the so generated home network domain name;

b) the UE shall include a To header field set to "sip:unavailable@unknown.invalid" (specified in 3GPP TS 23.003 [3]);

c) the UE shall include a From header field set to "sip:unavailable@unknown.invalid" (specified in 3GPP TS 23.003 [3]); and

d) the UE shall in the REGISTER request include a "+g.3gpp.rlos" Contact header field parameter, as defined in subclause 7.9.9

On reception of a 200 (OK) response to the REGISTER request for RLOS, the UE shall perform the actions as specified in subclause 5.1.1.2 and shall locally store an indication that RLOS session setup is possible. The indication is valid for an implementation specific time.

On receiving a 403 (Forbidden) response containing a Response-Source header field with a "fe" header field parameter set to "<urn:3gpp:fe:s-cscf>" for an initial registration that included a "+g.3gpp.rlos" Contact header field parameter in the REGISTER request, then the UE shall locally store an indication that setup of a RLOS session is possible. The indication is stored for an implementation dependent time.

L.3.1.7.3 Session Setup

L.3.1.7.3.1 Void

L.3.1.7.3.2 RLOS session set-up in case of unsuccessful registration

The UE shall establish a RLOS session as described in this sub-clause only after it has initiated a RLOS registration and has received a 403 (Forbidden) response sent from an S-CSCF.

When establishing a RLOS session in case of an unregistered user, the UE is allowed to receive responses to RLOS requests and requests inside an established RLOS session on the unprotected ports. The UE shall reject or silently discard all other messages. Additionally, the UE shall transmit signalling packets pertaining to the RLOS session from the same IP address and unprotected port on which it expects to receive signalling packets containing the responses to RLOS requests and the requests inside the established RLOS session.

When establishing a RLOS session for an unregistered user, the UE shall use the local IP address and P-CSCF address as used when sending the RLOS registration. The UE shall send only the initial INVITE 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, the UE shall send the initial INVITE request to the SIP default port values as specified in RFC 3261 [26].

The UE shall apply the procedures as specified in subclause 5.1.2A.1 and subclause 5.1.3 with the following additions:

1) the UE shall set the From header field of the INVITE request to the public user identity as used in the RLOS registration;

2) the UE shall:

a) if a dial string for a specific RLOS service is available in the UE, use the dial string to build the Request-URI as specified in subclause 5.1.2A.1.3; and

b) if no dial string for a specific RLOS service is available in the UE use the dummy MSISDN value as defined in 3GPP TS 23.003 [3] to build the Request-URI as specified in subclause 5.1.2A.1.3;

3) the UE shall insert in the INVITE request, a To header field with the same value as in the Request-URI;

4) The UE shall insert a P-Preferred-Service header field according to RFC 6050 [121] set to "urn:urn-7:3gpp-service.ims.icsi.rlos";

5) The UE shall insert an Accept-Contact header field field containing the "+g.3gpp.icsi-ref" header field parameter containing an ICSI value set to "urn:urn-7:3gpp-service.ims.icsi.rlos";

6) the UE shall include in the P-Access-Network-Info header field in any request for a dialog, any subsequent request (except CANCEL requests) or response (except CANCEL responses) within a dialog or any request. Insertion of the P-Access-Network-Info header field into the ACK request is optional. The UE shall populate the P-Access-Network-Info header field with the current point of attachment to the IP-CAN as specified for the access network technology (see subclause 7.2A.4).;

7) The UE shall populate the P-Preferred-Identity header field in the INVITE request with an IMEI based identity in the form of a SIP URI as specified in 3GPP TS 23.003 [3] subclause 13.13;

8) a Contact header field set to include SIP URI that contains in the hostport parameter the IP address of the UE and an unprotected port where the UE will receive incoming requests belonging to this dialog. The UE shall also include a "sip.instance" media feature tag containing Instance ID as described in RFC 5626 [92]. The UE shall also include the "+g.3gpp. icsi-ref" header field parameter containing an ICSI value set to "urn:urn-7:3gpp-service.ims.icsi.rlos" . The UE shall not include either the public or temporary GRUU in the Contact header field;

9) a Via header field set to include the IP address of the UE in the sent-by field and for the UDP the unprotected server port value where the UE will receive responses, while for the TCP, the response is received on the TCP connection on which the RLOS request was sent. For the UDP, the UE shall also include "rport" header field parameter with no value in the top Via header field.;

NOTE 1: The UE inserts the same IP address and port number into the Contact header field and the Via header field, and sends all IP packets to the P-CSCF from this IP address and port number.

10) if the UE has its location information available, or a URI that points to the location information, the UE shall include a Geolocation header field in the INVITE request in the following way:

– if the UE is aware of the URI that points to where the UE’s location is stored, include the URI as the Geolocation header field value, as described in RFC 6442 [89]; or

– if the UE is aware of its location information, include the location information in a PIDF location object, in accordance with RFC 4119 [90], include the location object in a message body with the content type application/pidf+xml, and include a Content ID URL, referring to the message body, as the Geolocation header field value, as described RFC 6442 [89], and include a Content-Disposition header field with a disposition type "render" value and a "handling" header field parameter with an "optional" value, as described in RFC 3261 [26];

NOTE 2: If the location information is old or inaccurate, the UE does not consider location information to be available.

11) if the UE includes a Geolocation header field, the UE shall also include a Geolocation-Routing header field with a "yes" header field value, which indicates that the location of the UE can be used by other entities to make routing decisions, as described in RFC 6442 [89]; and

12) if the UE has neither geographical location information available, nor a URI that points to the location information, the UE shall not insert a Geolocation header field in the INVITE request.

The UE shall build a proper preloaded Route header field value for all new dialogs. The UE shall build a Route header field value containing only the P-CSCF URI which was used in the RLOS registration.

When a SIP transaction times out, i.e. timer B, timer F or timer H expires at the UE, the UE may behave as if timer F expired, as described in subclause 5.1.1.4.

If the response for the initial INVITE request indicates that the UE is behind NAT, and the INVITE request was sent over TCP connection, the UE shall keep the TCP connection during the entire duration of the emergency session. In this case the UE will receive all responses to the emergency requests and the requests inside the established emergency session over this TCP connection.

If the Via header field of any provisional response, or of the final 200 (OK) response, for the initial INVITE request contains a "keep" header field parameter with a value, unless the UE detects that it is not behind a NAT, the UE shall start to send keep-alives associated with the session towards the P-CSCF, as described in RFC 6223 [143].

L.3.1.7.3.3 RLOS session set-up in case of successful registration

The UE shall apply the procedures as specified in subclauses 5.1.2A and 5.1.3 with the following additions:

1) the UE shall include in the Request-URI of the initial INVITE request the dummy MSISDN value as defined in 3GPP TS 23.003 [3];

2) the UE shall insert in the INVITE request, a To header field with the same value as in the Request-URI;

3) The UE shall insert a P-Preferred-Service header field according to RFC 6050 [121] set to "urn:urn-7:3gpp-service.ims.icsi.rlos"; and

4) The UE shall insert an Accept-Contact header field field containing the "+g.3gpp.icsi-ref" header field parameter containing an ICSI value set to "urn:urn-7:3gpp-service.ims.icsi.rlos";

L.3.2 Procedures at the P-CSCF

L.3.2.0 Registration and authentication

Void.

L.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 3GPP°TS°29.214 [13D] (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.

NOTE: The above check can be against more than one MNC code stored in the P-CSCF.

L.3.2.2 Location information handling

Void.

L.3.2.3 Prohibited usage of PDN connection for emergency bearer services

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

NOTE: By assigning specific IP address ranges for a PDN connection for emergency bearer services and configuring those ranges in P-CSCF, the P-CSCF can detect based on the registered Contact address if UE uses an emergency PDN connection for initial registration.

L.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:

a) contain SDP with an "audio" media line and which are related to a IMS multimedia telephony service session specified in TS 24.173 [8H]; or

b) 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.

NOTE 1: Precise details of such indications, if any, are subject to operator policy. Alternatively the operator policy can be to not preferentially page requests without an SDP offer.

For such identified requests:

a) where an unreliable transport mechanism is used as the transport protocol for SIP, the P-CSCF shall mark packets containing an INVITE request; and

b) 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.

L.3.2.5 Void

L.3.2.6 Resource sharing

L.3.2.6.1 Registration

If PCC is supported for this access technology a P-CSCF supporting resource sharing shall insert a Resource-Share header field with the value set to "supported" as described in subclause 7.2.13 and perform the actions in the following subclauses.

L.3.2.6.2 UE-originating case

Upon receiveing an initial INVITE request from a served UE, if the P-CSCF supports resource sharing and local policy requires that resources are reserved already on the SDP offer in the initial INVITE request, the P-CSCF can:

1) for each m-line in the SDP offer, internally generate a set of temporary resource sharing rules where:

a) if the media line is not subject to resouce sharing according to local policies, each resource sharing rule contains a sharing key with a value that is unique and not used by any another media stream in any ongoing session involving the UE;

b) directionality is included according to local policy; and

c) if the media line is subject to resouce sharing according to local policies, each resource sharing rule contains a sharing key with the value as assigned to other ongoing media stream(s) of some ongoing session(s) involving the UE that also use the shared resources; and

2) apply resource-sharing as specified in 3GPP TS 29.214 [13D] using the temporary resource sharing rules.

When the P-CSCF supporting resource receives a 18x response or a 2xx response containing the initial SDP answer, a Resource-Share header field with the value "media-sharing" and the "origin" header field parameter set to "session-initiator", the P-CSCF:

1) shall store resource sharing rules and the value of the corresponding sharing key as described in subclause 7.2.13.5 and use the stored sharing keys to identify resource sharing rules for the media streams in this session; and

2) will apply resource sharing as specified in 3GPP TS 29.214 [13D] using the stored sharing rules.

NOTE 1: If a Resource-Share header field containing the same stored sharing key values and updated resource sharing rules are received in any other session involving the served UE, the updated resource sharing rules overrides the resource sharing rules received in this session.

If P-CSCF supports resource sharing and when the first response to the initial INVITE request (with the exception of the 100 (Trying) response) contains a Resource-Share header field with the value "no-media-sharing" and the "origin" header field parameter set to the value "session-initiator", the P-CSCF shall not share media in this session.

NOTE 2: When resource sharing is not possible, sharing keys identifying the temporary set of resource sharing rules used over the Rx interface if resources were reserved using the SDP offer can still be kept but can never be used in any other session involving this UE as long as this session is ongoing.

If P-CSCF supports resource sharing and when the first response to the initial INVITE request (with the exception of the 100 (Trying) response) containing the initial SDP answer does not contain a Resource-Share header field, the P-CSCF may apply resource sharing using local configuration.

L.3.2.6.3 UE-terminating case

L.3.2.6.3.1 The initial INVITE request contains an initial SDP offer

If P-CSCF supports resource sharing and when P-CSCF receives an initial INVITE request destined to the served user containg the Resource-Share header field parameter with the value "media-sharing" and the "origin" header field parameter set to the value "session-receiver" and if local policy requires resource reservation using the initial SDP offer the P-CSCF shall:

1) store resource sharing rules and corresponding sharing key values as described in subclause 7.2.13.5 and use each stored sharing key to identify resource sharing rules for media streams in this session; and

2) apply resource sharing as specified in 3GPP TS 29.214 [13D] using the stored resource sharing rules.

NOTE: If a Resource-Share header field containing the stored sharing key are received in any other session involving the served UE, the updated resource sharing rules overrides the resource sharing rules received in this session.

Upon receiving a response to the above INVITE request containing an initial SDP answer, if the initial INVITE request containging the initial SDP offer contained the Resource-Share header field set to the value "media-sharing" and the "origin" header field parameter set to "session-receiver" and if local policy requires resource reservation on the initial SDP answer, the P-CSCF shall:

1) store resource sharing rules and corresponding sharing key values as described in subclause 7.2.13.5 and use the stored sharing keys to identify resource sharing rules for media streams in this session; and

2) apply resource sharing as specified in 3GPP TS 29.214 [13D] using the stored resource sharing rules.

If P-CSCF supports resource sharing and when P-CSCF receives an initial INVITE request containg the Resource-Share header field with the value "no-media-sharing" and the "origin" header field parameter set to the value "session-receiver", the P-CSCF shall not share media in this session.

If P-CSCF supports resource sharing and when P-CSCF receives an initial INVITE request not containing a Resource-Share header field, the P-CSCF may apply resource sharing using local configuration.

If the P-CSCF supporting resource sharing receives a request or response from the home network destined to the served user containing a Resource-Share header field with the "origin" header field parameter set to the value "session-initiator" or without the "origin header field parameter, the P-CSCF shall not use the content of the header field and remove the header field from the outgoing response or request.

L.3.2.6.3.2 The 18x response or the 2xx responses contains an initial SDP offer

When the P-CSCF supporting resource sharing receives an 18x response or a 2xx response from a served UE and the response contains an initial SDP offer and local policy requires resource reservation using the initial SDP offer, the P-CSCF shall :

1) for each m-line in the SDP offer, internally generate a set of temporary resource sharing rules where:

– each resource sharing rule contains a sharing key with a value that is unique and not used by any another media stream in any ongoing session involving the UE; and

– directionality is included according to local policy; and

2) apply resource-sharing as specified in 3GPP TS 29.214 [13D] using the temporary resource sharing rules.

Upon receiving a PRACK request or an ACK request containing the initial SDP answer and a Resource-Share header field with the value "media-sharing" and the "origin" header field parameter set to "session-receiver", the P-CSCF shall:

1) store resource sharing rules and the value of the corresponding sharing key as described in subclause 7.2.13.5 and use stored sharing key to identify resource sharing rules for the media streams in this session; and

2) apply resource sharing rules as specified in 3GPP TS 29.214 [13D] using the stored sharing rules.

Upon receiving a PRACK request or an ACK request containing the initial SDP answer and a Resource-Share header field with the value "no-media-sharing", the P-CSCF shall not share resources in this session.

NOTE: If resources can’t be shared the temporary set of resource sharing rules used over Rx interface when reserving resources using the initial SDP offer can still be kept but can never be used in any other session involving this UE as long as this dialog is ongoing.

Upon receiving a PRACK request or an ACK request containing the initial SDP answer and the response does not contain a Resource-Share header field, the P-CSCF may apply resource sharing using local configuration.

L.3.2.6.4 Abnormal cases

If P-CSCF receives a request or response from the served UE and there is a conflict with the given instructions over Rx and the UE behaviour, the P-CSCF shall:

– immediately stop resource sharing for all media streams in this session as described in 3GPP TS 29.214 [13D]; and

– if resource sharing options is determined by an AS, include the Resource-Share header field set to the value "no-media-sharing" along with the "origin" header field set to "session-initiator" or "session-receiver" as appropriate in the outgoing request or response.

NOTE 1: How P-CSCF detects that there is a conflict with the given instruction over Rx and the UE behaviour is implementation dependent and not further described.

NOTE 2: A typical example of a conflict between a given instruction over Rx and the UE behaviour is if media sharing is allowed in both uplink and downlink direction and if in the communication waiting use case, the UE sends a 200 (OK) response to the INVITE request without putting the first call on hold. The UE’s behaviour is then regarded as unpredictable and resource sharing cannot be used for any session using the stored sharing key value involving that UE.

The P-CSCF shall remove the Resource-Share header field from the request or response received from a served user.

L.3.2.6.5 Resource sharing options updated by AS

At any point in an ongoing session the AS in the home network can include in an subsequent request or response a Resource-Share header field containing updated resource sharing options and when such an update is received the P-CSCF shall store the new sharing rules as described in subclause 7.2.13.8.4 and apply any change as described in 3GPP TS 29.214 [13D].

L.3.2.7 Priority sharing

L.3.2.7.1 General

If P-CSCF supports priority sharing, PCC is supported for this access technology and if according to operator policy, the P-CSCF shall apply the procedures in the following subclauses.

If P-CSCF supports priority sharing, the P-CSCF shall remove the Priority-Share header field from outgoing requests or responses destined to the served UE.

L.3.2.7.2 Registration procedure

The P-CSCF supporting priority sharing and if according to operator policy shall include the g.3gpp.priority-share feature-capability indicator defined in subclause 7.9A.10 in a Feature-Caps header field in the SIP REGISTER request.

L.3.2.7.3 Session establishment procedure

When receiving the Priority-Share header field defined in subclause 7.2.16 in an initial INVITE request or in a 18x or a 2xx response to the initial INVITE request destined to the served UE and if according to operator policy, the P-CSCF shall apply priority sharing according to 3GPP TS 29.214 [13D] based on the value of the Priority-Share header field.

L.3.2.7.4 Subsequent request procedure

When receiving the Priority-Share header field in a re-INVITE request, in a18x or in a 2xx responses to the re-INVITE request destined to the served UE and if according to operator policy, the P-CSCF shall apply priority sharing according to 3GPP TS 29.214 [13D] based on the value of the Priority-Share header field.

When receiving the Priority-Share header field in an subsequent request or in a 2xx responses to the subsequent request destined to the served UE and if according to operator policy, the P-CSCF shall apply priority sharing according to 3GPP TS 29.214 [13D], based on the value of the Priority-Share header field.

L.3.2.8 RLOS

L.3.2.8.1 General

The support for RLOS as described in this subclause is optional for the P-CSCF.

L.3.2.8.2 Registration

A P-CSCF supporting RLOS shall perform the procedures as specified in subclause 5.2.2 and in addition shall perform the procedures specified in this sublclause.

When the P-CSCF receives a REGISTER request from the UE and the REGISTER request contains a "+g.3gpp.rlos" Contact header field parameter, and:

1) if:

a) the P-Access-Network-Info header field in REGISTER request indicates an IP-CAN for which procedures are defined in an Annex different than Annex L; or

b) the IP address and APN check, as defined in section Z3.3 of 3GPP TS 23.228 [7] fail;

then the P-CSCF shall reject the REGISTER request by sending a 403 response including a Response-Source header field with an "fe" header field parameter set to "<urn:3gpp:fe:p-cscf.orig>"; or

2) if the public user identity in the REGISTER request indicates a user for which the operator of the P-CSCF does not have a roaming agreement, then the P-CSCF shall select a preconfigured S-CSCF and insert a Route header field with the S-CSCF URI for originating requests and forward the request to the selected S-CSCF.

When the P-CSCF receives a 403 (Forbidden) response to a REGISTER request that contained a "+g.3gpp.rlos" Contact header field parameter, the P-CSCF shall:

1) create a temporary unauthenticated subscriber record for the registered public user identity;

2) associate the S-CSCF with the registered public user identity and associated contact address;

3) store the registered public user identity as a default public user identity for use with procedures for the P-Asserted-Identity header field for requests received from the UE;

4) store the values received in the P-Charging-Function-Addresses header field;

5) if a "term-ioi" header field parameter is received in the P-Charging-Vector header field, store the value of the received "term-ioi" header field parameter; and

NOTE: Any received "term-ioi" header field parameter will contain a type 1 IOI. The type 1 IOI identifies the home network of the registered user.

6) void.

L.3.2.8.3 Session Setup

L.3.2.8.3.1 General

If the P-CSCF supports RLOS, the P‑CSCF shall accept unprotected requests on the IP address and the unprotected port advertised to the UE during the P-CSCF discovery or the SIP default port.

When the P-CSCF sends unprotected responses to the UE, it shall use the same IP address and port where the corresponding request was received.

L.3.2.8.3.2 General treatment for RLOS session setup – requests from an unregistered user

If the P-CSCF receives an initial request for a dialog or standalone transaction, or an unknown method from an unregistered user on the IP address and the unprotected port advertised to the UE during the P-CSCF discovery or the SIP default port,

The P-CSCF shall inspect the Request-URI independent of values of possible entries in the received Route header fields for the presence of the dummy MSISDN or a RLOS service specific dial string. The P-CSCF shall consider the Request URI of the initial request as indicating RLOS, if the Request-URI contains the dummy URI or a RLOS service specific dial string and if the request contains a P-Preferred-Service header field according to RFC 6050 [121] set to "urn:urn-7:3gpp-service.ims.icsi.rlos".

If the P-CSCF detects that the initial request for a dialog or a standalone transaction, or an unknown method indicates RLOS, and the P-CSCF has previously stored a temporary unauthenticated subscriber record for the public user identity contained in the From header field of the request:

1) shall include a topmost Route header field set to the URI of the S-CSCF as stored in the unauthenticated subscriber record;

NOTE 2: How the list of E-CSCF is obtained by the P-CSCF is implementation dependent.

2) shall execute the procedure described in subclause 5.2.6.3.3, subclause 5.2.6.3.7, subclause 5.2.6.3.11 and subclause 5.2.7.2, as appropriate except for:

– verifying the preloaded route against the received Service-Route header field;

– routing to IBCF; and

– inserting a type 1 "orig-ioi" header field parameter in the P-Charging-Vector header field;

3) shall insert a P-Asserted-Identity header field set to the public user identity as stored in the unauthenticated subscriber record; and

4) if the P-CSCF detects that the UE is behind a NAT, and the UE’s Via header field contains a "keep" header field parameter, shall add a value to the parameter, to indicate that it is willing to receive keep-alives associated with the dialog from the UE, as defined in RFC 6223 [143].

When the P-CSCF receives any 1xx or 2xx response to the above requests, the P-CSCF shall execute the appropriate procedure for the type of request described in subclause 5.2.6.3.4, subclause 5.2.6.3.8, and subclause 5.2.6.3.12, except that the P-CSCF may rewrite the port number of its own Record-Route entry to an unprotected port where the P-CSCF wants to receive the subsequent incoming requests from the UE belonging to this dialog.

When the P-CSCF receives a target refresh request from the UE for a dialog, the P-CSCF shall execute the procedure described in subclause 5.2.6.3.5, except for inserting a type 1 "orig-ioi" header field parameter in the P-Charging-Vector header field.

When the P-CSCF receives from the UE subsequent requests other than a target refresh request (including requests relating to an existing dialog where the method is unknown), the P-CSCF shall execute the procedure described in subclause 5.2.6.3.9, except for inserting a type 1 "orig-ioi" header field parameter in the P-Charging-Vector header field.

L.3.2.8.3.3 General treatment for RLOS session setup – requests from a registered user

The P-CSCF shall follow procedures specified subclause 5.2.6.

L.3.2.9 Support of ANBR and RAN-assisted codec adaptation

If the network supports ANBR as specified in 3GPP TS 26.114 [9B] and RAN-assisted codec adaptation as specified in 3GPP TS 36.300 [268] and 3GPP TS 36.321 [269], 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.

L.3.3 Procedures at the S-CSCF

L.3.3.1 Notification of AS about registration status

Not applicable.

L.3.3.2 RLOS

L.3.3.2.1 General

The support for RLOS as described in this subclause is optional.

L.3.3.2.2 Registration

A S-CSCF supporting RLOS shall perform the procedures as specified in subclause 5.4.1.2 and in addition shall perform the procedures specified in this subclause.

Upon receipt of a REGISTER request that is part of an initial registration as described in subclause 5.4.1.2.1

1) if REGISTER request contains a "+g.3gpp.rlos" Contact header field parameter, the S-CSCF:

a) if the S-CSCF supports GPRS-IMS-Bundled authentication and the public user identity in the REGISTER request indicates a user for which the operators of the S-CSCF does not have a roaming agreement with the home network operator, shall reject the request by returning a 420 (Bad Extension) response in which the Unsupported header field contains the value "sec-agree"; and

b) if the S-CSCF does not support GPRS-IMS-Bundled authentication and the public user identity in the REGISTER request indicates a user for which the operators of the S-CSCF does not have a roaming agreement with the home network operator, shall reject the request by returning a 403 (Forbidden) response and include a Response-Source header field with a "fe" header field parameter set to "<urn:3gpp:fe:s-cscf>". The S-CSCF shall create a temporary record for the public user identity which is registered with a default service profile which is valid for an implementation specific time; and

Upon receipt of a REGISTER request without an Authorization header field as described in subclause 5.4.1.2.1E and the REGISTER request contains a "+g.3gpp.rlos" Contact header field paramete, the S-CSCF shall skip the procedures in subclause 5.4.1.2.1E and shall

1) identify the user by the public user identity as received in the To header field of the REGISTER request. The S-CSCF shall derive the private user identity from the public user identity being registered by removing URI scheme and the following parts of the URI if present: port number, URI parameters, and To header field parameters;

2) check if the P-Visited-Network-ID header field is included in the REGISTER request, and if it is included identify the visited network by the value of this header field;

3) check whether a "received" header field parameter exists in the Via header field provided by the UE. If a "received" header field parameter exists, the S-CSCF shall compare the IP address recorded in the "received" header field parameter against the UE’s IP address stored during registration. In case of IPv6 stateless autoconfiguration, the S-CSCF shall compare the prefix of the IP address recorded in the "received" header field parameter against the UE’s IP address prefix stored during registration. If no "received" header field parameter exists in the Via header field provided by the UE, then the S-CSCF shall compare IP address recorded in the "sent-by" parameter against the stored UE IP address. In case of IPv6 stateless autoconfiguration, S-CSCF shall compare the prefix of the IP address recorded in the "sent-by" parameter against the UE’s IP address prefix stored during registration. In any case, if the stored IP address (or prefix) and the (prefix of the) IP address recorded in the Via header field provided by the UE do not match, the S‑CSCF shall query the HSS as described in 3GPP TS 29.228 [14] with the derived private user identity and the public user identity as input and store the received IP address (or prefix) of the UE. If the stored IP address (or prefix) and the (prefix of the) IP address recorded in the Via header field provided by the UE still do not match the S-CSCF shall reject the registration with a 403 (Forbidden) response and skip the following steps;

4) determine the duration of the registration by checking the registration expiration interval value in the received REGISTER request 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). Based on local policy, the S-CSCF may reduce the duration of the registration or send back a 423 (Interval Too Brief) response specifying the minimum allowed time for registration;

5) update registration bindings;

6) create a temporary record for the public user identity being registered with a default service profile;

7) store the "icid-value" header field parameter received in the P-Charging-Vector header field;

8) if an "orig-ioi" header field parameter is received in the P-Charging-Vector header field, store the value of the received "orig-ioi" header field parameter;

9) check whether a Path header field was included in the REGISTER request and construct a list of preloaded Route header fields from the list of entries in the received Path header field. The S-CSCF shall preserve the order of the preloaded Route header fields and bind them either to the contact address of the UE and the contact information that was received in the REGISTER request; and

10) create and send a 200 (OK) response for the REGISTER request as specified in subclause 5.4.1.2.2F;

In case the timer reg-await-auth is running for this user, S-CSCF supports RLOS as specified in TS 23.228 [7] and the REGISTER request contains a "+g.3gpp.rlos" Contact header field parameter, the S-CSCF shall:

1) check if the Call-ID of the request matches with the Call-ID of the 401 (Unauthorized) response which carried the last challenge. The S-CSCF shall only proceed further if the Call-IDs match;

2) stop timer reg-await-auth;

3) check whether an Authorization header field is included, containing:

a) the private user identity of the user in the "username" header field parameter;

b) if the "integrity-protected" header field parameter is set to "yes", the "algorithm" header field parameter set to "AKAv1-MD5" or "AKAv2-SHA-256";

NOTE: The "AKAv1-MD5" algorithm is only supported for backward compatibility.

c) if the "integrity-protected" header field parameter is set to "tls-connected", the "algorithm" header field parameter set to "AKAv2-SHA-256" if the S-CSCF supports the IMS AKA using HTTP Digest AKAv2 without IPSec security association; and

d) the authentication challenge response needed for the authentication procedure in the "response" header field parameter.

The S-CSCF shall only proceed with the following steps in this paragraph if the authentication challenge response was included;

4) check whether the received authentication challenge response and the expected authentication challenge response (calculated by the S-CSCF using XRES and other parameters as described in RFC 3310 [49] when AKAv1 is used or as described in RFC 4169 [227] when AKAv2 is used) match. The XRES parameter was received from the HSS as part of the Authentication Vector. The S-CSCF shall only proceed with the following steps if the challenge response received from the UE and the expected response calculated by the S-CSCF do not match;

5) if there are public user identities (including the public user identity being registered, if previously registered) that belong to this user that have been previously registered with the same private user identity, and with an old contact address different from the one received in the REGISTER request and if the previous registrations have not expired:

a) terminate all dialogs, associated with the previously registered public user identities (including the public user identity being registered, if previously registered), with a status code 480 (Temporarily Unavailable) in the Reason header field of the BYE request, as specified in subclause 5.4.5.1.2;

b) send a NOTIFY request, to the subscribers to the registration event package of the previously registered public user identities, that indicates that all previously registered public user identities (excluding the public user identity being registered) belonging to this user identified with its private user identity, have been deregistered, as described in subclause 5.4.2.1.2. For the public user identity being registered, the NOTIFY request contains the new contact information; and

c) delete all information associated with the previously registered public user identities;

6) store the following information in the local data:

a) the public user identities due to the received REGISTER request which is set to the public user identity as received in the REGISTER request. The public user identity is identified as non-barred;

b) a default service profile that indicates that the public user identity is registered for RLOS;

c) if S-CSCF restoration procedures are supported, the restoration information if received as specified in 3GPP TS 29.228 [14]; and

d) if PCRF based P-CSCF restoration procedures are supported, all the user profile(s) corresponding to the public user identities being registered (explicitly or implicitly), including the IMSI, if available;

7) update registration bindings and

a) bind to each non-barred registered public user identity the registered contact information including all header field parameters contained in the Contact header field and all associated SIP URI parameters, and

b) if the Contact header field of the REGISTER request contained a "+sip.instance" and a "reg-id" header field parameter, and the SIP URI in the Path header field inserted by the P-CSCF contained an "ob" SIP URI parameter header field, and:

– if the public user identity has not previously been registered with the same "+sip.instance" and "reg-id" Contact header field parameter values, then create the registration flow in addition to any existing registration flow; or

– if the public user identity has previously been registered with the same "+sip.instance" and "reg-id" header field parameter values, then determine whether the request refreshes or replaces an existing registration flow. If the request:

i) refreshes an existing registration flow, then the S-CSCF shall leave the flow intact; or

ii) replaces the existing registration flow with a new flow, then the S-CSCF shall:

a) terminate any dialog, as specified in subclause 5.4.5.1.2, with a status code 480 (Temporarily Unavailable) in the Reason header field of the BYE request, associated with the registration flow being replaced; and

b) send a NOTIFY request to the subscribers to the registration event package for the public user identity indicated in the REGISTER request, as described in subclause 5.4.2.1.2;

8) check whether a Path header field was included in the REGISTER request and construct a list of preloaded Route header fields from the list of entries in the received Path header field. The S-CSCF shall preserve the order of the preloaded Route header fields and bind them either to the contact address of the UE or the registration flow and the associated contact address (if the multiple registration mechanism is used) and the contact information that was received in the REGISTER request;

9) determine the duration of the registration by checking the value of the registration expiration interval value in the received REGISTER request 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). Based on local policy, the S-CSCF may reduce the duration of the registration or send back a 423 (Interval Too Brief) response specifying the minimum allowed time for registration.;

10) store the "icid-value" header field parameter received in the P-Charging-Vector header field;

11) if an "orig-ioi" header field parameter is received in the P-Charging-Vector header field, store the value of the received "orig-ioi" header field parameter; and

12) create a 403 (Forbidden) response for the REGISTER request including a Response-Source header field with a "fe" header field parameter set to "<urn:3gpp:fe:s-cscf >" and send the so generated response.

L.3.3.2.3 Session Setup

L.3.3.2.3.1 General

A S-CSCF supporting RLOS shall perform the procedures as specified in subclause 5.4.3.2 and in addition shall perform the procedures specified in this subclause.

When the S-CSCF receives from the served user from an initial request for a dialog or a request for a standalone transaction and performing the procedures in subclause 5.4.3.2 and:

1) if there is no original dialog identifier that the S-CSCF previously placed in a Route header field is present in the topmost Route header field of the incoming request; and

2) if the Request-URI contains the dummy MSISDN value as defined in 3GPP TS 23.003 [3] or a RLOS service specific dial string and a P-Preferred-Service header set to "urn:urn-7:3gpp-service.ims.icsi.rlos" is included in the request;

the S-CSCF shall build an ordered list of initial filter criteria based on the temporary unauthenticated subscriber record for the public user identiy of the served user instead of building the ordered list of initial filter criteria as described in bullet 3).