Content for  TS 24.229  Word version:  19.0.0

In addition to following the procedures for initial requests defined in subclause 5.2.6, initial INVITE requests also follow the procedures of this subclause.

When the P-CSCF receives from the UE an INVITE request for which resource authorization procedure is required, if it receives from the IP-CAN (e.g. via PCRF) an indication that the requested resources for the multimedia session being established cannot be granted and this indication does not provide an acceptable bandwidth information:

• if the P-CSCF is unable to handle further requests from the UE (i.e. P-CSCF is overloaded by SIP requests), the P-CSCF shall return a 503 (Service Unavailable) response to the received INVITE request. Depending on local operator policy, the 503 (Service Unavailable) response may include a Retry-After header field; and
• if the P-CSCF is able to handle further requests from the UE (i.e. P-CSCF is not overloaded by SIP requests), the P-CSCF shall return a 500 (Server Internal Error) response to the received INVITE request. Depending on local operator policy, the 500 (Server Internal Error) response may include a Retry-After header field.

When the P-CSCF receives from the UE an INVITE request, the P-CSCF may require the periodic refreshment of the session to avoid hung states in the P-CSCF. If the P-CSCF requires the session to be refreshed, then the P-CSCF shall apply the procedures described in Section 8 of RFC 4028. The P-CSCF shall respond to all INVITE requests with a 100 (Trying) provisional response. If received from the IP-CAN, the P-CSCF shall also include the access-network-charging-info parameter (e.g. received via the PCRF, over the Rx or Gx interfaces) in the P-Charging-Vector header field in the first request originated by the UE that traverses the P-CSCF, as soon as the charging information is available in the P-CSCF, e.g., after the local resource reservation is complete. Typically, this first request is an UPDATE request if the remote UA supports the "integration of resource management in SIP" extension or a re-INVITE request if the remote UA does not support the "integration of resource management in SIP" extension. See subclause 5.2.7.4 for further information on the access network charging information. If:

• the UE is roaming;
• the P-CSCF is not in the home network; and
• an agreement exists with the home network operator (as identified by the bottom most URI in the list of URIs received in the Service-Route header field during the last successful registration or reregistration) to support Roaming Architecture for Voice over IMS with Local Breakout;

the P-CSCF may:

• insert into the request a Feature-Caps header field with the "+g.3gpp.trf" header field parameter as specified in RFC 6809. Based on local policy the P-CSCF shall insert the "+g.3gpp.trf" header field parameter with the parameter value set to the URI of the desired TRF; and
• if a TRF URI is included in the "+g.3gpp.trf" header field parameter and the P-CSCF supports indicating the traffic leg associated with a URI as specified in RFC 7549 and if required by local policy, append an "iotl" SIP URI parameter with a value set to "homeA-visitedA" to the TRF URI.

If:

• the UE is roaming;
• the P-CSCF is not in the home network; and
• the visited network supports MRB functionality for the allocation of MRF resources and if an agreement exists with the home operator (identified by the bottom most URI in the list of URIs received in the Service-Route header field during the last successful registration or reregistration) to provide access to MRF resources from the visited network;

the P-CSCF may insert into the request a Feature-Caps header field with the "+g.3gpp.mrb" header field parameter, as specified in RFC 6809. Based on local policy the P-CSCF shall insert the "+g.3gpp.mrb" header field parameter with the parameter value set to the URI of the desired MRB. The P-CSCF (IMS-ALG) shall transparently forward a received Contact header field towards the UE when the Contact header field contains a GRUU or a media feature tag indicating a capability for which the URI can be used. Based on the alternative mechanism to recognize the need for priority treatment, the P-CSCF shall insert the temporarily authorised Resource-Priority header field with appropriate namespace and priority value in the INVITE request. When the P-CSCF responds to the UE with a 500 (Server Internal Error) response after receiving an indication that radio/bearer resources are not available, then based on operator policy, the P-CSCF may include a Reason header field with a protocol value set to "FAILURE_CAUSE" and a "cause" header field parameter set to "1" as specified in subclause 7.2A.18.12.2 and a Response-Source header field with a "fe" header field parameter set to "<urn:3gpp:fe:p-cscf.orig>". If the P-CSCF supports the in-call access update procedure and if a received response to the INVITE request contains a Feature-Caps header field with a g.3gpp.in-call-access-update feature capability indicator, the P-CSCF shall store the value of this feature capability indicator.

When the P-CSCF receives an INVITE request destined for the UE the P-CSCF may require the periodic refreshment of the session to avoid hung states in the P-CSCF. If the P-CSCF requires the session to be refreshed, then the P-CSCF shall apply the procedures described in Section 8 of RFC 4028. When the P-CSCF receives an initial INVITE request destined for the UE, it will have a list of Record-Route header fields. Prior to forwarding the initial INVITE request, the P-CSCF shall respond to all INVITE requests with a 100 (Trying) provisional response. If received from the IP-CAN, the P-CSCF shall also include the access-network-charging-info parameter (e.g. received via the PCRF, over the Rx or Gx interfaces) in the P-Charging-Vector header field in the first request or reliable response originated by the UE that traverses the P-CSCF, as soon as the charging information is available in the P-CSCF e.g., after the local resource reservation is complete. When the P-CSCF sends the response including P-Charging-Vector header field, the P-CSCF shall set the "icid-value" header field parameter to the previously received value of "icid-value" header field parameter in the request. See subclause 5.2.7.4 for further information on the access network charging information. The P-CSCF (IMS-ALG) shall transparently forward a received Contact header field towards the UE when the Contact header field contains a GRUU or a media feature tag indicating a capability for which the URI can be used. If the P-CSCF supports the in-call access update procedure and if the received INVITE request contains a Feature-Caps header field with a g.3gpp.in-call-access-update feature capability indicator, the P-CSCF shall store the value of this feature capability indicator.

The P-CSCF shall include the "access-network-charging-info" header field parameter within the P-Charging-Vector header field as described in subclause 7.2A.5.

When the P-CSCF receives a 2xx response for a BYE request matching an existing dialog, then the P-CSCF shall delete all the stored information related to the dialog.

If the P-CSCF requested the session to be refreshed periodically, and the P-CSCF got the indication that the session will be refreshed, when the session timer expires, the P-CSCF shall delete all the stored information related to the dialog.

The P-CSCF shall respond to all reINVITE requests with a 100 (Trying) provisional response. For a reINVITE request or UPDATE request from the UE within the same dialog, the P-CSCF shall include the updated access-network-charging-info parameter from P-Charging-Vector header field when sending the SIP request to the S-CSCF. See subclause 5.2.7.4 for further information on the access network charging information. For an ACK request from the UE sent on a dialog where a 200 (OK) has been received, the P-CSCF shall include the access-network-charging-info parameter from the P-Charging-Vector header field when updated access-network-charging-info is available when sending the ACK request to the S-CSCF. See subclause 5.2.7.4 for further information on the access network charging information. If priority is supported, the P-CSCF shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field value.

The P-CSCF shall respond to all reINVITE requests with a 100 (Trying) provisional response. For a reINVITE request or UPDATE request destined towards the UE within the same dialog, when the P-CSCF sends 200 (OK) response (to the INVITE request or UPDATE request) towards the S-CSCF, the P-CSCF shall include the updated access-network-charging-info parameter in the P-Charging-Vector header field. See subclause 5.2.7.4 for further information on the access network charging information. If priority is supported, the P-CSCF shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field value and set the backwards indication accordingly.

If the P-CSCF belongs to a network where the registration is not required to obtain emergency service, the P-CSCF shall accept any unprotected request on the IP address and port advertised to the UE during the P-CSCF discovery procedure. The P-CSCF shall also accept any unprotected request on the same IP address and the default port as specified in RFC 3261. 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. The P-CSCF can handle emergency session and other requests from both a registered user as well as an unregistered user. Certain networks only allow emergency session from registered users. The P-CSCF can handle emergency session establishment within a non-emergency registration, i.e. one that did not contain the "sos" SIP URI parameter in the Contact header field of the 200 (OK) response. If the network uses the Resource-Priority header field to control the priority of emergency calls, and the P-CSCF receives a REGISTER request containing an "sos" SIP URI parameter in the Contact header field, the P-CSCF shall, in addition to the normal handling of the REGISTER request, add a Resource-Priority header field containing a namespace of "esnet" as defined in RFC 7135 to the REGISTER request. Upon receiving the 200 (OK) response to the REGISTER request that completes the emergency registration, as identified by the presence of the "sos" SIP URI parameter in the Contact header field of the 200 (OK) response, the P-CSCF shall not subscribe to the registration event package for any emergency public user identity specified in the REGISTER request. Upon reception of a REGISTER request containing an "sos" SIP URI parameter in the Contact header field and not containing an Authorization header field, if:

1. the network supports IMS Services for roaming users in deployments without IMS-level roaming interfaces;
2. the UE is roaming;
3. there is no II-NNI to the HPLMN of the served user; and
4. the access type is not set to "3GPP-NR-ProSe-L3UNR";

or:

1. if required by operator policy; and
2. the UE is not roaming;

the P-CSCF:

1. shall not forward the REGISTER request; and
2. if the PCRF is used to retrieve the EPS-level identities (i.e., IMSI, IMEI(SV)) as specified in TS 29.214 and IMSI is retrieved:
   1. if the P-CSCF supports IMSI or IMEI verification upon reception of a REGISTER request without Authorization header;
      1. if the IMSI derived from public user identity conveyed in To header is different from the IMSI received from PCRF, shall reject the REGISTER request by returning a 403 (Forbidden) response and shall not perform the rest of steps; and
      2. if the IMEI(SV) is retrieved from the PCRF and the TAC and SNR portions of the IMEI obtained from instance ID conveyed in Contact header field are different from the TAC and SNR portions of IMEI(SV) received from PCRF, reject the REGISTER request by returning a 403 (Forbidden) response and shall not perform the rest of steps;
   2. if MSISDN is retrieved:
      1. shall generate:
         • a SIP URI with user=phone for the retrieved MSISDN; and
         • a tel URI for the retrieved MSISDN;
         and shall include the URIs in the associated set of implicitly registered public user identities bound to the contact address from which the REGISTER request was received; and
      2. shall treat the SIP URI with user=phone for the retrieved MSISDN as the default public user identity for requests received from the contact address from which the REGISTER request was received;
   3. if MSISDN is not retrieved:
      1. shall generate a temporary public user identity for the IMSI retrieved from the PCRF as specified in TS 29.214 and shall include the temporary public user identity in the associated set of implicitly registered public user identities bound to the contact address from which the REGISTER request was received; and
      2. shall treat the temporary public user identity for the retrieved IMSI as the default public user identity for requests received from the contact address from which the REGISTER request was received; and
   4. shall send a 200 (OK) response for the REGISTER request. In the 200 (OK) response, the P-CSCF shall include a P-Associated-URI header field containing the list of the implicitly registered public user identities bound to the contact address from which the REGISTER request was received. The first URI in the list of public user identities will indicate the default public user identity.

The P-CSCF shall store a configurable list of local emergency service identifiers, i.e. emergency numbers (the emergency numbers that can be resolved in the network to which the P-CSCF belongs) and emergency service URNs (i.e. emergency service URNs identifying emergency services that can be resolved in the network to which the P-CSCF belongs). In addition to the configurable list of local emergency service identifiers, the P-CSCF shall store a configurable list of roaming partners' emergency service identifiers (i.e. the emergency service numbers or the emergency service URNs identifying emergency services, which can be resolved in the roaming partners' network). Each emergency number in a configurable list is mapped to an emergency service URN if the network is configured, for the emergency number, to:

• accept a received request including the emergency number; or
• reject, using a 380 (Alternative Service) response, a received request including the emergency number, and include in the response a Contact header field with the emergency service URN.

Access technology specific procedures are described in each access technology specific annex to determine the originating network of the requests.

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 emergency service identifiers. The P-CSCF shall consider the Request URI of the initial request as an emergency service identifier, if it is an emergency number or an emergency service URN in the list of local emergency service identifiers or in the list of roaming partners emergency service identifiers. If the Request-URI is a service URN with a top-level service type of "sos" as specified in RFC 5031 and the P-CSCF does not consider the Request URI of the initial request as an emergency service identifier, the P-CSCF may:

• remove the right most service identifier and re-inspect the Request-URI for emergency service identifiers; or
• set the Request-URI to an operator defined emergency service URN that matches one of the emergency service identifiers.

If the P-CSCF detects that the Request-URI of the initial request for a dialog or a standalone transaction, or an unknown method matches one of the emergency service identifiers, the P-CSCF: 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. If the P-CSCF does not receive any response to the initial request for a dialog or standalone transaction or unknown method (including its retransmissions); or receives a 3xx response or 480 (Temporarily Unavailable) response to an initial request for a dialog or standalone transaction or an unknown method, the P-CSCF shall include a URI associated with a different E-CSCF in the topmost Route header field and forward the request. When the P-CSCF received a subsequent request in the dialog from the UE, and the network uses the Resource-Priority header field to control the priority of emergency calls, the P-CSCF shall add a Resource-Priority header field containing a namespace of "esnet" as defined in RFC 7135. 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.

When the P-CSCF receives, destined for the UE, a target refresh request for a dialog, prior to forwarding the request, the P-CSCF shall execute the procedure described in step 5, the paragraph of subclause 5.2.6.4.5. When the P-CSCF receives a 1xx or 2xx response to the above request the P-CSCF shall execute the procedure described in subclause 5.2.6.4.6, except for inserting type 1 "orig-ioi" and "term-ioi" header field parameters in the P-Charging-Vector header field. When the P-CSCF receives any other response to the above request the P-CSCF shall execute the procedure described in steps in the paragraph of subclause 5.2.6.4.6 describing when the P-CSCF receives any other response to a target request, except for inserting type 1 "orig-ioi" and "term-ioi" header field parameters in the P-Charging-Vector header field. When the P-CSCF receives, destined for the UE, a subsequent request for a dialog that is not a target refresh request (including requests relating to an existing dialog where the method is unknown), prior to forwarding the request, the P-CSCF shall execute the procedure described in steps 3 and 4 of subclause 5.2.6.4.9 describing when a P-CSCF receives a subsequent request. When the P-CSCF receives any other response to the above request the P-CSCF shall execute the procedure described in steps in the paragraph of subclause 5.2.6.4.10 describing when the P-CSCF receives any other response to a subsequent request, except for inserting type 1 "orig-ioi" and "term-ioi" header field parameters in the P-Charging-Vector header field.

If the P-CSCF receives an initial request for a dialog, or a standalone transaction, or an unknown method, for a registered user over the security association, TLS session, or IP association that was created during the emergency registration, as identified by the presence of the "sos" SIP URI parameter in the Contact header field of the 200 (OK) response, the P-CSCF shall inspect the Request-URI independent of values of possible entries in the received Route header fields for emergency service identifiers. The P-CSCF shall consider the Request URI of the initial request as an emergency service identifier, if it is an emergency number or an emergency service URN from the configurable lists that are associated with:

• the country of the operator to which the P-CSCF belongs to; and
• for inbound roamers, the country from which the UE is roaming from. The P-CSCF determines the country to which the UE is belonging to based on the content of the P-Assserted-Identity header field which contains the home network domain name in a SIP URI belonging to the user.

If the P-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone transaction, or an unknown method does not match any one of the emergency service identifiers in the associated lists, the P-CSCF shall either:

• reject the request by returning a 403 (Forbidden) response to the UE; or
• if the Request-URI is a service URN with a top-level service type of "sos" as specified in RFC 5031:
  1. the P-CSCF sets the Request-URI to an operator defined emergency service URN that matches one of the emergency service identifiers; or
  2. remove the right most service identifier and re-inspect the Request-URI for emergency service identifiers.

If the P-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone transaction, or an unknown method matches one of the emergency service identifiers in the associated lists, the P-CSCF shall: If the P-CSCF does not receive any response to an initial request for a dialog or standalone transaction or an unknown method sent to an E-CSCF (including its retransmissions); or receives a 480 (Temporarily Unavailable) response to an initial request for a dialog or standalone transaction or an unknown method sent to an E-CSCF, the P-CSCF shall include a URI, associated with a different E-CSCF, in the topmost Route header field and forward the request. If the P-CSCF does not receive any response to an initial request for a dialog or standalone transaction or an unknown method sent to a S-CSCF (including its retransmissions); or receives a 480 (Temporarily Unavailable) response to an initial request for a dialog or standalone transaction or an unknown method sent to a S-CSCF, the P-CSCF shall include a URI, associated with a different E-CSCF, in the topmost Route header field of the initial request for a dialog or standalone transaction or an unknown method, and forward the request. When the P-CSCF received a subsequent request in the dialog from the UE, and the network uses the Resource-Priority header field to control the priority of emergency calls, the P-CSCF shall add a Resource-Priority header field containing a namespace of "esnet" as defined in RFC 7135. When the P-CSCF receives a target refresh request for a dialog with the Request-URI containing a GRUU the P-CSCF shall:

• obtain the UE IP address and UE port associated to the GRUU contained in the Request-URI and rewrite the Request-URI with that UE IP address and UE port; and
• perform the steps in subclause 5.2.6.4.5 for when the P-CSCF receives, destined for the UE, a target refresh request for a dialog.

If the P-CSCF receives an initial request for a dialog, or a standalone transaction, or an unknown method, for a registered user, and the request is:

1. understood from saved or included information to relate to private network traffic (see subclause 5.2.6.3), and operator policy requires the P-CSCF to detect an emergency session request relating to private network traffic; or
2. not understood from saved or included information to relate to private network traffic (see subclause 5.2.6.3);

then the P-CSCF shall inspect the Request-URI independent of values of possible entries in the received Route header fields for emergency service identifiers. The P-CSCF shall consider the Request URI of the initial request as an emergency service identifier, if it is an emergency numbers or an emergency service URN from the configurable lists that are associated with:

• the country of the operator to which the P-CSCF belongs to;
• for inbound roamers, the country from which the UE is roaming from. The P-CSCF determines the country to which the UE is belonging to based on the content of the P-Assserted-Identity header field which contains the home network domain name in a SIP URI belonging to the user; and
• the country of roaming partners, if the request originates from a different country then the country of the network to which the P-CSCF belongs to. Access technology specific procedures are described in each access technology specific annex to determine from which country and roaming partner the request was originated. If the country from which the request originates can not be determined all lists are associated.

If the P-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone transaction, or an unknown method matches one of the emergency service identifiers in the associated lists, the P-CSCF shall: If the P-CSCF does not receive any response to the initial request for a dialog or standalone transaction or an unknown method sent to an E-CSCF (including its retransmissions); or receives a 480 (Temporarily Unavailable) response to an initial request for a dialog or standalone transaction or an unknown method sent to an E-CSCF, the P-CSCF shall include a URI, associated with a different E-CSCF that has not been tried before for this initial request for the dialog or standalone transaction (including its retransmissions), in the topmost Route header field and forward the request. If the P-CSCF does not receive any response to the initial request for a dialog or standalone transaction or an unknown method sent to a S-CSCF (including its retransmissions); or receives a 480 (Temporarily Unavailable) response to an initial request for a dialog or standalone transaction or an unknown method sent to a S-CSCF, the P-CSCF shall include a URI, associated with a different E-CSCF that has not been tried before for this initial request for the dialog or standalone transaction (including its retransmissions), in the topmost Route header field of the initial request for a dialog or standalone transaction or an unknown method, and forward the request. If the P-CSCF:

• does not receive any response to this initial request for a dialog or standalone transaction or an unknown method (including its retransmissions); or receives a 3xx response or 480 (Temporarily Unavailable) response to an initial request for a dialog or standalone transaction or an unknown method, and if all E-CSCFs have been tried before for this initial request for the dialog or standalone transaction (including its retransmissions), the P-CSCF shall reject this request as specified in subclause 5.2.10.5;
• receives:
  1. any 4xx response other than a 480 (Temporarily Unavailable) response;
  2. any 5xx response;
  3. any 6xx response,
  and the entry in the Request-URI as received from the UE is not in accordance with RFC 5031, then the P-CSCF shall reject this request as specified in subclause 5.2.10.5.

If the P-CSCF receives from the IP-CAN (e.g. via PCRF) an indication that the requested resources for the multimedia session being established cannot be granted and the entry in the Request-URI as received from the UE is not in accordance with RFC 5031, then the P-CSCF shall:

• send a CANCEL request to cancel the request forwarded to the selected E-CSCF; and
• reject this request as specified in subclause 5.2.10.5.

When the P-CSCF received a subsequent request in the dialog from the UE, and the network uses the Resource-Priority header field to control the priority of emergency calls, the P-CSCF shall add a Resource-Priority header field containing a namespace of "esnet" as defined in RFC 7135. When the P-CSCF receives a target refresh request for a dialog with the Request-URI containing a GRUU the P-CSCF shall:

• obtain the UE IP address and UE port associated to the GRUU contained in the Request-URI and rewrite the Request-URI with that UE IP address and UE port; and
• perform the steps in subclause 5.2.6.4 for when the P-CSCF receives, destined for the UE, a target refresh request for a dialog.

If the IM CN subsystem to where the P-CSCF belongs to is not capable to handle emergency sessions or due to local policy does not handle emergency sessions or only handles certain type of emergency session request or does not support emergency sessions for either the geographical location of the UE is located or the IP-CAN to which the UE is attached, or the SDP of the request describes CS media (see TS 24.292), or for reasons described in subclause 5.2.10.4, the P-CSCF shall not forward the initial request for a dialog or standalone transaction or an unknown method. The P-CSCF:

1. shall reject the request by returning a 380 (Alternative Service) response;
2. if:
   • support for the 3GPP IM CN subsystem XML body as described in subclause 7.6 in the Accept header field is not indicated, the P-CSCF shall assume that the UE supports version 1 of the 3GPP XML Schema for the IM CN subsystem XML; or
   • if both the "sv" and "schemaversion" parameters are present, then the P-CSCF shall ignore the value of the "schemaversion" parameter;
3. shall include in the 380 (Alternative Service) response:
   1. a Content-Type header field with the value set to associated MIME type of the 3GPP IM CN subsystem XML body as described in subclause 7.6.1;
   2. a P-Asserted-Identity header field set to the value of the SIP URI of the P-CSCF included in the Path header field during the registration of the user whose UE sent the request causing this response (see subclause 5.2.2.1); and
   3. if required by operator policy implementing national regulatory requirements, a Contact header field with an emergency service URN (i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031). If a type of emergency service can be deduced from the Request-URI received from the UE and if required by operator policy implementing national regulatory requirements, the P-CSCF shall include in the emergency service URN a sub-service type deduced from the Request-URI received from the UE; and
4. shall include an IM CN subsystem XML body with the following elements:
   1. an <ims-3gpp> element with the "version" attribute set to "1" and with an <alternative-service> child element, set to the parameters of the alternative service;
      1. a <type> child element, set to "emergency" (see table 7.6.2) to indicate that it was an emergency call;
      2. a <reason> child element, set to an operator configurable reason; and
      3. an <action> child element, set to "emergency-registration" (see table 7.6.3) if the P-CSCF is accordingly configured by the operator.

Upon reception of a REGISTER request containing an "sos" SIP URI parameter in the Contact header field and containing an Authorization header field, if:

1. the network supports IMS Services for roaming users in deployments without IMS-level roaming interfaces;
2. required by operator policy;
3. the UE is roaming; and
4. there is no II-NNI to the HPLMN of the served user;

or:

1. if required by operator policy; and
2. the UE is not roaming;

the P-CSCF:

1. if the P-CSCF supports GPRS-IMS-Bundled authentication, 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 P-CSCF does not support GPRS-IMS-Bundled authentication, shall reject the request by returning a 403 (Forbidden) response.

When the P-CSCF responds 420 (Bad Extension) or 403 (Forbidden) response, if required by operator policy implementing national regulatory requirements (i.e., the network support an emergency session for an unregistered user as described in subclause 5.2.10.2), the P-CSCF shall include:

1. a Content-Type header field with the value set to associated MIME type of the 3GPP IM CN subsystem XML body as described in subclause 7.6.1;
2. 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;
3. a P-Asserted-Identity header field set to the value of the SIP URI of the P-CSCF; and
4. a 3GPP IM CN subsystem XML body containing:
   1. an <ims-3gpp> element with the "version" attribute set to "1" and with an <alternative-service> child element, set to the parameters of the alternative service:
      1. a <type> child element, set to "emergency" (see table 7.6.2) to indicate that it was an emergency call;
      2. a <reason> child element, set to an operator configurable reason; and
      3. an <action> child element, set to "anonymous-emergencycall" (see table 7.6.3) if the P-CSCF is accordingly configured by the operator.