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…

 

L.2A  Usage of SDPp. 892

L.2A.0  General |R9|p. 892

Up

L.2A.1  Impact on SDP offer / answer of activation or modification of EPS bearer context for media by the networkp. 892

If, due to the activation of EPS bearer context from the network the related SDP media description needs to be changed, the UE shall update the related SDP information by sending, within a SIP request, a new SDP offer for each of the existing SIP dialogs,
If the UE receives a modification request from the network for a EPS bearer context 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 EPS bearer context, the related SDP media description need to be changed, update the related SDP information by sending, within a SIP request, a new SDP offer for each of the existing SIP dialogs, and respond to the EPS bearer context modification request.
Up

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

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

L.2A.3  Emergency service |R11|p. 893

L.3  Application usage of SIPp. 893

L.3.1  Procedures at the UEp. 893

L.3.1.0  Registration and authentication |R13|p. 893

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 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 TS 26.114 shall also support RAN-assisted codec adaptation as specified in TS 36.300 and TS 36.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 36.300 and TS 36.321. The UE is allowed to include the SDP 'anbr' attribute during session establishment as specified in TS 26.114.
Up

L.3.1.0a  IMS_Registration_handling policy |R15|p. 893

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.301), 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

L.3.1.1  P-Access-Network-Info header fieldp. 894

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

L.3.1.1A  Cellular-Network-Info header field |R13|p. 894

Not applicable.

L.3.1.2  Availability for callsp. 894

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 TS 24.301):
    1. PS mode 1;
    2. 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:
    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 (see TS 24.301), indicates voice is supported;
  6. if the procedures to perform the initial registration are enabled (see TS 24.305); and
  7. if the EPS bearer context used for SIP signalling is:
    1. available; or
    2. not available, and the UE:
      1. is allowed to send a PDN CONNECTIVITY REQUEST message to establish an EPS bearer context that is needed for performing the initial registration; or
      2. 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.
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:
  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 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:
    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
  2. 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

L.3.1.2A  Availability for SMS |R11|p. 896

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 TS 24.341), 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 TS 24.341);
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 TS 24.341 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.
Up

L.3.1.3  Authorization header field |R10|p. 896

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 |R10|p. 897

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

L.3.1.5  3GPP PS data off |R14|p. 897

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;
  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 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 EF 3GPPPSDATAOFFservicelist 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 EF 3GPPPSDATAOFFservicelist file described in TS 31.102 is not configured; or
    • the non_3GPP_ICSIs_roaming_exempt node in the EF 3GPPPSDATAOFFservicelist 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 EF 3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_exempt node in the EF 3GPPPSDATAOFFservicelist 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 EF 3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_roaming_exempt node in the EF 3GPPPSDATAOFFservicelist 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_roaming_exempt node specified in TS 24.167, if the UE is in the VPLMN;
    • the non_3GPP_ICSIs_exempt node in the EF 3GPPPSDATAOFFservicelist 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 EF 3GPPPSDATAOFFservicelist file described in TS 31.102 is not configured; or
    • the non_3GPP_ICSIs_roaming_exempt node in the EF 3GPPPSDATAOFFservicelist 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 EF 3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_exempt node in the EF 3GPPPSDATAOFFservicelist 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 EF 3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_roaming_exempt node in the EF 3GPPPSDATAOFFservicelist file described in TS 31.102 shall take precedence.
Up

L.3.1.6  Transport mechanisms |R15|p. 898

No additional requirements are defined.

L.3.1.7  RLOS |R16|p. 898

L.3.1.7.1  Generalp. 898
The support for RLOS as described in this subclause is optional for the UE.
L.3.1.7.2  Registrationp. 898
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:
  1. the UE shall in the REGISTER request include a "+g.3gpp.rlos" Contact header field parameter, as defined in subclause 7.9.9.
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:
  1. the UE shall generate a home network domain name according to the rules specified in TS 23.003 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;
  2. the UE shall include a To header field set to "sip:unavailable@unknown.invalid" (specified in TS 23.003);
  3. the UE shall include a From header field set to "sip:unavailable@unknown.invalid" (specified in TS 23.003); and
  4. 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.
Up
L.3.1.7.3.1Void
L.3.1.7.3.2  RLOS session set-up in case of unsuccessful registrationp. 899
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.
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:
    1. 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
    2. if no dial string for a specific RLOS service is available in the UE use the dummy MSISDN value as defined in TS 23.003 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 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 subclause 13.13 of TS 23.003;
  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. 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.;
  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; or
    • if the UE is aware of its location information, include the location information in a PIDF location object, in accordance with RFC 4119, 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, 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;
  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; 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.
Up
L.3.1.7.3.3  RLOS session set-up in case of successful registrationp. 901
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 TS 23.003;
  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 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";
Up

L.3.2  Procedures at the P-CSCFp. 901

L.3.2.0  Registration and authentication |R12|p. 901

Void.

L.3.2.1  Determining network to which the originating user is attachedp. 901

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

L.3.2.2  Location information handlingp. 901

Void.

L.3.2.3  Prohibited usage of PDN connection for emergency bearer services |R9|p. 901

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.

L.3.2.4  Support for paging policy differentiation |R13|p. 901

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

L.3.2.5Void

L.3.2.6  Resource sharing |R13|p. 902

L.3.2.6.1  Registrationp. 902
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 casep. 902
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:
    1. 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;
    2. directionality is included according to local policy; and
    3. 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 TS 29.214 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 TS 29.214 using the stored sharing rules.
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.
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.
Up
L.3.2.6.3  UE-terminating casep. 903
L.3.2.6.3.1  The initial INVITE request contains an initial SDP offerp. 903
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 TS 29.214 using the stored resource sharing rules.
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 TS 29.214 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.
Up
L.3.2.6.3.2  The 18x response or the 2xx responses contains an initial SDP offerp. 903
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 TS 29.214 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 TS 29.214 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.
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.
Up
L.3.2.6.4  Abnormal casesp. 904
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 TS 29.214; 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.
The P-CSCF shall remove the Resource-Share header field from the request or response received from a served user.
Up
L.3.2.6.5  Resource sharing options updated by ASp. 904
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 TS 29.214.

L.3.2.7  Priority sharing |R13|p. 904

L.3.2.7.1  Generalp. 904
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 procedurep. 905
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 procedurep. 905
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 TS 29.214 based on the value of the Priority-Share header field.
L.3.2.7.4  Subsequent request procedurep. 905
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 TS 29.214 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 TS 29.214, based on the value of the Priority-Share header field.
Up

L.3.2.8  RLOS |R16|p. 905

L.3.2.8.1  Generalp. 905
The support for RLOS as described in this subclause is optional for the P-CSCF.
L.3.2.8.2  Registrationp. 905
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:
    1. 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
    2. the IP address and APN check, as defined in section Z3.3 of TS 23.228 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
  6. void.
Up
L.3.2.8.3.1  Generalp. 906
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 userp. 906
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;
  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.
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.
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.5 or subclause 5.2.6.3.9.
Up
L.3.2.8.3.3  General treatment for RLOS session setup - requests from a registered userp. 907
The P-CSCF shall follow procedures specified subclause 5.2.6.

L.3.2.9  Support of ANBR and RAN-assisted codec adaptation |R16|p. 907

If the network supports ANBR as specified in TS 26.114 and RAN-assisted codec adaptation as specified in TS 36.300 and TS 36.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

L.3.3  Procedures at the S-CSCFp. 907

L.3.3.1  Notification of AS about registration statusp. 907

Not applicable.

L.3.3.2  RLOS |R16|p. 907

L.3.3.2.1  Generalp. 907
The support for RLOS as described in this subclause is optional.
L.3.3.2.2  Registrationp. 907
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:
    1. 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
    2. 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 TS 29.228 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 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:
    1. the private user identity of the user in the "username" header field parameter;
    2. if the "integrity-protected" header field parameter is set to "yes", the "algorithm" header field parameter set to "AKAv1-MD5" or "AKAv2-SHA-256";
    3. 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
    4. 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 when AKAv1 is used or as described in RFC 4169 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:
    1. 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;
    2. 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
    3. delete all information associated with the previously registered public user identities;
  6. store the following information in the local data:
    1. 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;
    2. a default service profile that indicates that the public user identity is registered for RLOS;
    3. if S-CSCF restoration procedures are supported, the restoration information if received as specified in TS 29.228; and
    4. 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
    1. 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
    2. 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:
        1. refreshes an existing registration flow, then the S-CSCF shall leave the flow intact; or
        2. replaces the existing registration flow with a new flow, then the S-CSCF shall:
          1. 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
          2. 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.
Up
L.3.3.2.3  Session Setup |R17|p. 910
L.3.3.2.3.1  General p. 910
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 TS 23.003 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).
Up

L.4  3GPP specific encoding for SIP header field extensionsp. 910

L.5  Use of circuit-switched domainp. 910

There is no CS domain in this access technology.
Up

Up   Top   ToC