Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  18.5.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.5…   5…   5.1.1.4…   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4…   5.4.1.2.2…   5.4.1.3…   5.4.2   5.4.3…   5.4.3.3…   5.4.4…   5.5…   5.7…   5.7.2…   5.8…   5.11…   6…   6.6…   7…   7.2A…   7.2A.6…   7.3…   7.9A…   8…   A…   A.2…   A.2.1.4…   A.2.1.4.7…   A.2.1.4.8…   A.2.1.4.10A…   A.2.1.4.12…   A.2.2…   A.2.2.4…   A.2.2.4.7…   A.2.2.4.8…   A.2.2.4.10A…   A.2.2.4.12…   A.3…   A.3.3…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…

 

5.2.7  Initial INVITEp. 205

5.2.7.1  Introductionp. 205

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.

5.2.7.2  UE-originating casep. 205

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

5.2.7.3  UE-terminating casep. 207

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

5.2.7.4  Access network charging informationp. 207

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.

5.2.8  Call releasep. 207

5.2.8.1  P-CSCF-initiated call releasep. 207

5.2.8.1.1  Cancellation of a session currently being establishedp. 207
Upon receipt of an indication that the signalling bearer is no longer available (e.g. an Rx interface message from PCRF), the P-CSCF shall cancel that dialog by applying the following steps:
  1. if the P-CSCF serves the calling user of the session, send out a CANCEL request to cancel the INVITE request towards the terminating UE that includes:
    1. if a cause or error code was received from the entity controlling radio/bearer resources, a Reason header field, with an appropriate protocol value in the protocol field, and the "cause" header field parameter set to the received cause or error code; and
    2. if:
      • no cause or error code was received from the entity controlling radio/bearer resources; or
      • if the abort cause PS_TO_CS_HANDOVER was received over Rx from the entity controlling radio/bearer resources;
      a Reason header field containing a 503 (Service Unavailable) status code according to the procedures described in RFC 3261 and RFC 3326; and
  2. if the P-CSCF serves the called user of the session, send out a 500 (Server Internal Error) response to the received INVITE request. If a cause or error code was received from the entity controlling radio/bearer resources the P-CSCF shall include a Reason header field, with a protocol value set to "FAILURE_CAUSE" in the "protocol" header field parameter as described in subclause 7.2A.18.12.2, and the "cause" header field parameter set to "2" as described in subclause 7.2A.18.12.2.
Upon receipt of an indication that QoS or bearer resources are no longer available for a media negotiated in a multimedia session currently being established (e.g. an Rx interface message from PCRF) and if no SIP message removing the media for which resources are no longer available is received within an operator defined time after the reception of the indication, the P-CSCF shall:
  1. cancel that dialog by responding to the original INVITE request with a 500 (Server Internal Error) response. If a cause or error code was received from the entity controlling radio/bearer resources the P-CSCF shall include a Reason header field, with a protocol value set to "FAILURE_CAUSE" in the "protocol" header field parameter as described in subclause 7.2A.18.12.2, and the "cause" header field parameter set to "1" as described in subclause 7.2A.18.12.2; and
  2. by sending out a CANCEL request to the INVITE request towards the terminating UE that includes a Reason header field containing a 503 (Service Unavailable) status code according to the procedures described in RFC 3261 and RFC 3326.
Up
5.2.8.1.2  Release of an existing sessionp. 208
Upon:
  1. receipt of an indication that the radio/bearer resources are no longer available for a media negotiated in a session (e.g. an Rx interface message from PCRF) and if no SIP message removing the media for which resources are no longer available is received within an operator defined time after the reception of the indication;
  2. receipt of an indication that the signalling bearer is no longer available (e.g. an Rx interface message from PCRF); or
  3. detecting that the SDP offer conveyed in a SIP response contained parameters which are not allowed according to the local policy (as specified in the subclause 6.2);
the P-CSCF shall release the respective dialog by applying the following steps:
  1. if the P-CSCF serves the calling user of the session, then the P-CSCF shall generate a BYE request destined for the called user based on the information saved for the related dialog, including:
    • a Request-URI, set to the stored Contact header field provided by the called user;
    • a To header field, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;
    • a From header field, set to the From header field value as received in the initial INVITE request;
    • a Call-ID header field, set to the Call-Id header field value as received in the initial INVITE request;
    • a CSeq header field, set to the current CSeq value stored for the direction from the calling to the called user, incremented by one;
    • a Route header field, set to the routeing information towards the called user as stored for the dialog;
    • a Reason header field or Reason header fields that contains:
      1. if a cause or error code was received from the entity controlling radio/bearer resources, an appropriate protocol value in the protocol field, and the "cause" header field parameter set to the received cause or error code;
      2. if no cause or error code was received from the entity controlling radio/bearer resources, and if radio/bearer interface resources are no longer available, a 503 (Service Unavailable) response code;
      3. if no cause or error code was received from the entity controlling radio/bearer resources, and if the signalling bearer is no longer available, a 503 (Service Unavailable) response code;
      4. if no cause or error code was received from the entity controlling radio/bearer resources, and if a SDP offer conveyed in a SIP response contained parameters which are not allowed according to the local policy, a 488 (Not Acceptable Here) response code; and
      5. if the abort cause PS_TO_CS_HANDOVER was received over Rx from the entity controlling radio/bearer resources, a 503 (Service Unavailable) response code;
    • further header fields, based on local policy; and
    • send the generated BYE requests towards the called user;
  2. if the P-CSCF serves the calling user of the session and upon detecting that the SDP offer conveyed in a SIP response contained parameters which are not allowed according to the local policy (as specified in the subclause 6.2), then the P-CSCF shall generate an additional BYE request destined for the calling user based on the information saved for the related dialog, including:
    • a Request-URI, set to a contact address obtained from the stored Contact header field if provided by the calling user. If the stored Contact header field contains either a public or a temporary GRUU, the P-CSCF shall set the Request-URI either to:
      1. the stored UE IP address and the UE port associated with the respective GRUU, if the stored Contact header field contains either a public or a temporary GRUU and the bidirectional flow as defined in RFC 5626 is not used for this session; or
      2. the UE IP address and UE port associated with the bidirectional flow that the P-CSCF uses to send the in-dialog requests toward the UE as defined in RFC 5626;
    • a To header field, set to the From header field value as received in the initial INVITE request;
    • a From header field, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;
    • a Call-ID header field, set to the Call-Id header field value as received in the initial INVITE request;
    • a CSeq header field, set to the current CSeq value stored for the direction from the called to the calling user, incremented by one;
    • a Route header field, set to the routeing information towards the calling user as stored for the dialog;
    • a Reason header field that contains a 488 (Not Acceptable Here) response code;
    • further header fields, based on local policy; and
    • send the BYE request either:
      1. to the contact address indicated in the Request-URI, if the dialog being released did not use the bidirectional flow to send the requests to the UE as defined in RFC 5626; or
      2. over the same flow that the P-CSCF uses to send the in-dialog requests toward the UE as defined in RFC 5626;
  3. If the P-CSCF serves the called user of the session, then the P-CSCF shall generate a BYE request destined for the calling user based on the information saved for the related dialog, including:
    • a Request-URI, set to the stored Contact header field provided by the calling user;
    • a To header field, set to the From header field value as received in the initial INVITE request;
    • a From header field, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;
    • a Call-ID header field, set to the Call-Id header field value as received in the initial INVITE request;
    • a CSeq header field, set to the current CSeq value stored for the direction from the called to the calling user, incremented by one;
    • a Route header field, set to the routeing information towards the calling user as stored for the dialog;
    • a Reason header field or Reason header fields that contains:
      1. if a cause or error code was received from the entity controlling radio/bearer resources, an appropriate protocol value in the protocol field, and the "cause" header field parameter set to the received cause or error code;
      2. if no cause or error code was received from the entity controlling radio/bearer resources, and if radio/bearer interface resources are no longer available, a 503 (Service Unavailable) response code;
      3. if no cause or error code was received from the entity controlling radio/bearer resources, and if a SDP offer conveyed in a SIP response contained parameters which are not allowed according to the local policy, a 488 (Not Acceptable Here) response code; and
      4. if the abort cause PS_TO_CS_HANDOVER was received over Rx from the entity controlling radio/bearer resources, a 503 (Service Unavailable) response code;
    • further header fields, based on local policy; and
    • send the generated BYE requests towards the calling user;
  4. if the P-CSCF serves the called user of the session and upon detecting that the SDP offer conveyed in a SIP response contained parameters which are not allowed according to the local policy (as specified in the subclause 6.2), then the P-CSCF shall generate an additional BYE request destined for the called user based on the information saved for the related dialog, including:
    • a Request-URI, set to a contact address obtained from the stored Contact header field if provided by the called user. If the stored Contact header field contains either a public or a temporary GRUU, the P-CSCF shall set the Request-URI either to:
      1. the stored UE IP address and the UE port associated with the respective GRUU, if the stored Contact header field contains either a public or a temporary GRUU and the bidirectional flow as defined in RFC 5626 is not used for this session; or
      2. the UE IP address and the UE port associated with the bidirectional flow that the P-CSCF uses to send the in-dialog requests toward the UE as defined in RFC 5626;
    • a To header field, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;
    • a From header field, set to the From header field value as received in the initial INVITE request;
    • a Call-ID header field, set to the Call-Id header field value as received in the initial INVITE request;
    • a CSeq header field, set to the current CSeq value stored for the direction from the calling to the called user, incremented by one;
    • a Route header field, set to the routeing information towards the called user as stored for the dialog;
    • a Reason header field that contains a 488 (Not Acceptable Here) response code;
    • further header fields, based on local policy; and
    • send the BYE request either:
      1. to the contact address indicated in the Request-URI, if the dialog being released did not use t the bidirectional flow to send the requests to the UE as defined in RFC 5626; or
      2. over the same flow that the P-CSCF uses to send the in-dialog requests toward the UE as defined in RFC 5626.
Upon receipt of the 2xx responses for the BYE requests, the P-CSCF shall delete all information related to the dialog and the related multimedia session.
Up
5.2.8.1.3  Abnormal casesp. 211
Upon receipt of a request on a dialog for which the P-CSCF initiated session release, the P-CSCF shall terminate this received request and answer it with a 481 (Call/Transaction Does Not Exist) response.
5.2.8.1.4  Release of the existing dialogs due to registration expiration and deletion of the security association, IP association or TLS sessionp. 211
If there are still active dialogs associated with the user after the security associations, IP association or TLS sessions were deleted, the P-CSCF shall discard all information pertaining to these dialogs without performing any further SIP transactions with the peer entities of the P-CSCF.

5.2.8.2  Call release initiated by any other entityp. 211

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.

5.2.8.3  Session expiration |R6|p. 211

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.

5.2.9  Subsequent requestsp. 211

5.2.9.1  UE-originating casep. 211

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

5.2.9.2  UE-terminating casep. 211

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

5.2.10  Emergency servicep. 212

5.2.10.1  General |R7|p. 212

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

5.2.10.2  General treatment for all dialogs and standalone transactions excluding the REGISTER method - requests from an unregistered user |R7|p. 214

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:
1)
shall include in the Request-URI an emergency service URN, i.e. a service URN with a top-level service type of "sos" in accordance with RFC 5031:
  1. if the received Request-URI matches an emergency service URN, as received in the Request-URI from the UE; and
  2. if the received Request-URI does not match an emergency service URN, as deduced from the Request-URI received from the UE;
2)
shall include a topmost Route header field set to the URI associated with an E-CSCF;
3)
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;
  • removing the P-Preferred-Identity header field;
  • inserting a P-Asserted-Identity header field; and
  • inserting a type 1 "orig-ioi" header field parameter in the P-Charging-Vector header field;
3A)
void;
3B)
where the network uses the Resource-Priority header field to control the priority of emergency calls, shall add a Resource-Priority header field containing a namespace of "esnet" as defined in RFC 7135;
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; and
5)
if required by operator policy (e.g. when the network supports IMS services for roaming users in deployments without IMS-level roaming interfaces), and the P-CSCF supports including EPS-level identities (i.e. IMSI, IMEI(SV)) and MSISDN in a request from an unregistered user:
  1. shall attempt to retrieve from PCRF the EPS-level identities and MSISDN available for the IP-CAN session of the request:
  2. if a Subscription-Id AVP(s) as specified in TS 29.214 with an MSISDN, an IMSI or both is(are) retrieved:
    1. shall remove from the request any P-Preferred-Identity header field;
    2. if an MSISDN is retrieved, shall insert in the request a P-Asserted-Identity header field set to a tel URI carrying the MSISDN; and
    3. if an IMSI is retrieved, shall insert in the request a P-Asserted-Identity header field set to a temporary public user identity derived from the IMSI, as defined in TS 23.003; and
  3. if a User-Equipment-Info-Type AVP or a User-Equipment-Info-Extension AVP as specified in TS 29.214 with an IMEI(SV) is retrieved where the TAC and SNR portions are different from the TAC and SNR portions of the IMEI received in the "+sip.instance" header field parameter of the Contact header field of the request and if according to operator policy, shall reject the request with 403 (Forbidden) response.
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.
Up

5.2.10.2A  General treatment for all dialogs and standalone transactions excluding the REGISTER method - requests to an unregistered user |R8|p. 215

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

5.2.10.3  General treatment for all dialogs and standalone transactions excluding the REGISTER method after emergency registration |R7|p. 216

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:
1)
include in the Request-URI an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031:
  1. if the received Request-URI matches an emergency service URN, as received from the UE in the Request-URI; and
  2. if the received Request-URI does not match an emergency service URN, as deduced from the Request-URI received from the UE.
1A)
if the operator policy requires that emergency service requests are forwarded to the S-CSCF and the P-CSCF determines that the network to which the originating user is attached (see the IP-CAN specific annexes for the detailed procedure) is the network the P-CSCF is in and if the user is not roaming, then:
  1. 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 routing to IBCF;
  2. before the request is forwarded in the referenced procedures, include a bottom most Route header field set to the URI associated with an E-CSCF;
  3. afterwards upon receipt of a target refresh request or a subsequent request other than a target refresh request (including requests relating to an existing dialog where the method is unknown) for a dialog from the UE, execute the procedure described in subclause 5.2.6.3.5 and subclause 5.2.6.3.9; and
  4. afterwards upon receipt of any response from the UE to a target refresh request or a subsequent request other than a target refresh request (including requests relating to an existing dialog where the method is unknown) for a dialog, execute the procedure described in subclause 5.2.6.4.6 and subclause 5.2.6.4.10;
1B)
if the condition for 1A) is not fulfilled then:
  1. 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;
  2. before the request is forwarded in the referenced procedures, remove all Route header fields and include a Route header field set to the URI associated with an E-CSCF;
  3. afterwards upon receipt of a target refresh request or a subsequent request other than a target refresh request (including requests relating to an existing dialog where the method is unknown) for a dialog from the UE, execute the procedure described in subclause 5.2.6.3.5 and subclause 5.2.6.3.9, except for inserting a type 1 "orig-ioi" header field parameter in the P-Charging-Vector header field; and
  4. afterwards upon receipt of any response from the UE to a target refresh request or a subsequent request other than a target refresh request (including requests relating to an existing dialog where the method is unknown) for a dialog, execute the procedure described in subclause 5.2.6.4.6 and subclause 5.2.6.4.10, except for inserting type 1 "orig-ioi" and "term-ioi" header field parameters in the P-Charging-Vector header field;
1C)
if the request is from a UE that is not considered as privileged sender and if the alternative identity of the originator of the request was not identified (see subclause 5.2.6.3.1):
  1. if the P-Asserted-Identity header field in the request to be sent contains a SIP URI and if a tel URI belongs to the set of implicitly registered public user identities that contains the SIP URI, add a second P-Asserted-Identity header field that contains the first tel URI of the implicitly registered public user identities; and
  2. if the P-Asserted-Identity header field in the request to be sent contains a tel URI, add a second P-Asserted-Identity header field that contains the first SIP URI of the implicitly registered public user identities that contains the tel URI;
2)
if the request contains a Contact header field containing a GRUU the P-CSCF shall save the GRUU received in the Contact header field of the request and associate it with the UE IP address and UE port such that the P-CSCF is able to route target refresh request containing that GRUU in the Request-URI. The UE port used for the association is determined as follows:
  • if IMS AKA or SIP digest with TLS is being used as a security mechanism, the UE protected server port for the security association on which the request was received; or
  • if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled Authentication is being used as a security mechanism, the UE unprotected port on which the request was received;
3)
where the network uses the Resource-Priority header field to control the priority of emergency calls, add a Resource-Priority header field containing a namespace of "esnet" as defined in RFC 7135; and
4)
if the P-CSCF supports calling number verification using signature verification and attestation information as specified in subclause 3.1 and if required by operator policy, the P-CSCF shall perform attestation of the user identity by inserting:
  • a "verstat" tel URI parameter, specified in subclause 7.2A.20, to the tel URI or SIP URI with a user=phone parameter in the From header field or the P-Asserted-Identity header field;
  • an Attestation-Info header field specified in subclause 7.2.18; and
  • an Origination-Id header field, specified in subclause 7.2.19, set to a UUID identifying the P-CSCF which is configured based on local policy;
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.
Up

5.2.10.4  General treatment for all dialogs and standalone transactions excluding the REGISTER method - non-emergency registration |R7|p. 218

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:
0A)
determine the geographical location of the UE. Access technology specific procedures are described in each access technology specific annex:
  1. if the UE is roaming and the P-CSCF is in the home operator's network, or the SDP of the request describes CS media (see TS 24.292), then the P-CSCF:
    1. shall reject the request as specified in subclause 5.2.10.5;
  2. if the UE is roaming and the P-CSCF is in the same network where the UE is roaming, or the UE is not roaming, then the P-CSCF, depending on operator policies:
    1. may reject the request as specified in subclause 5.2.10.5; or
    2. may continue with the next steps;
1)
include in the Request-URI an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031, if necessary. If information on the type of emergency service is known include a sub-service type. The entry in the Request-URI that the P-CSCF includes shall be:
  • if the received Request-URI matches an emergency service URN, as received from the UE in the Request-URI; and
  • if the received Request-URI does not match an emergency service URN, as deduced from the Request-URI received from the UE;
1A)
if operator policy requires that emergency service requests are forwarded to the S-CSCF and the P-CSCF determines that the network to which the originating user is attached (see the IP-CAN specific annexes for the detailed procedure) is the network the P-CSCF is in then:
  1. 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 routing to IBCF;
  2. before the request is forwarded in the referenced procedures, include a bottom most Route header field set to the URI associated with an E-CSCF;
  3. afterwards upon receipt of a target refresh request or a subsequent request other than a target refresh request (including requests relating to an existing dialog where the method is unknown) for a dialog from the UE, execute the procedure described in subclause 5.2.6.3.5 and subclause 5.2.6.3.9; and
  4. afterwards upon receipt of any response from the UE to a target refresh request or a subsequent request other than a target refresh request (including requests relating to an existing dialog where the method is unknown) for a dialog, execute the procedure described in subclause 5.2.6.4.6 and subclause 5.2.6.4.10;
1B)
if the condition for 1A) is not fulfilled then:
  1. 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;
  2. before the request is forwarded in the referenced procedures, remove all Route header fields and include a Route header field set to the URI associated with an E-CSCF;
  3. afterwards upon receipt of a target refresh request or a subsequent request other than a target refresh request (including requests relating to an existing dialog where the method is unknown) for a dialog from the UE, execute the procedure described in subclause 5.2.6.3.5 and subclause 5.2.6.3.9, except for inserting a type 1 "orig-ioi" header field parameter in the P-Charging-Vector header field; and
  4. afterwards upon receipt of any response from the UE to a target refresh request or a subsequent request other than a target refresh request (including requests relating to an existing dialog where the method is unknown) for a dialog, execute the procedure described in subclause 5.2.6.4.6 and subclause 5.2.6.4.10, except for inserting type 1 "orig-ioi" and "term-ioi" header field parameters in the P-Charging-Vector header field;
1C)
if the request is from a UE that is not considered as privileged sender and if the alternative identity of the originator of the request was not identified (see subclause 5.2.6.3.1):
  1. if the P-Asserted-Identity header field in the request to be sent contains a SIP URI and if a tel URI belongs to the set of implicitly registered public user identities that contains the SIP URI, add a second P-Asserted-Identity header field that contains the first tel URI of the implicitly registered public user identities; and
  2. if the P-Asserted-Identity header field in the request to be sent contains a tel URI, add a second P-Asserted-Identity header field that contains the first SIP URI of the implicitly registered public user identities that contains the tel URI;
2)
if the request contains a Contact header field containing a GRUU the P-CSCF shall save the GRUU received in the Contact header field of the request and associate it with the UE IP address and UE port such that the P-CSCF is able to route target refresh request containing that GRUU in the Request-URI. The UE port used for the association is determined as follows:
  • if IMS AKA or SIP digest with TLS is being used as a security mechanism, the UE protected server port for the security association on which the request was received; or
  • if SIP digest without TLS is being used as a security mechanism, the UE unprotected port on which the request was received; and
3)
where the network uses the Resource-Priority header field to control the priority of emergency calls, add a Resource-Priority header field containing a namespace of "esnet" as defined in RFC 7135.
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.
Up

5.2.10.5  Abnormal and rejection cases |R7|p. 221

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

5.2.11Void

5.2.12  Resource sharing |R13|p. 223

The P-CSCF supporting resource sharing shall perform the actions defined in access technology specific annexes.

5.2.13  Priority sharing |R13|p. 223

The P-CSCF supporting priority sharing shall perform the actions defined in access technology specific annexes.

5.2.14  Access update |R17|p. 223

This subclause specifies procedures for the P-CSCF to inform the S-CSCF and any AS as applicable that the UE has changed access and possibly PLMN. This includes access update when the UE is not in a call and an in-call access update procedure when the access change happens when the UE is involved in an IMS session.
If the P-CSCF is aware that the UE has changed PLMN, and the P-CSCF has a policy to require a different encryption for the new PLMN than what the UE currently uses, the P-CSCF shall send a MESSAGE request towards the S-CSCF populated as follows:
  1. the Request-URI set to the URI of the S-CSCF as received in the Service-Route header field during the registration of the served UE;
  2. a From header field set to the FQDN of the P-CSCF sending the request;
  3. a To header field, set to the same value as the Request-URI;
  4. a P-Asserted-Identity header field set to the default public user identity of the served user;
  5. a P-Charging-Vector header field with the "icid-value" header field parameter populated with the ICID value used for the dialog related to the access change and a type 1 "orig-ioi" header field parameter. The P-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The P-CSCF shall not include the type 1 "term-ioi" header field parameter;
  6. a P-Access-Network-Info header field including network-provided location information;
  7. a P-Visited-Network-ID header field; and
  8. based on network configuration a Handover-Info header field, defined in subclause 7.2.15, set to "authentication-needed";
When the UE is in a call,if the P-CSCF supports the in-call access update procedure, has received the g.3gpp.in-call-access-update feature-capability indicator during session set-up, and determines that the UE has changed access or PLMN, then the P-CSCF shall generate a MESSAGE request populated as follows:
  1. the Request URI set to the stored value of the g.3gpp.in-call-access-update feature-capability indicator;
  2. a From header field set to the FQDN of the P-CSCF sending the request;
  3. a To header field, set to the same value as the Request-URI;
  4. a P-Asserted-Identity header field set to the default public user identity of the served user;
  5. a P-Charging-Vector header field with the "icid-value" header field parameter populated with the ICID value used for the dialog related to the access change and a type 1 "orig-ioi" header field parameter. The P-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The P-CSCF shall not include the type 1 "term-ioi" header field parameter;
  6. a P-Access-Network-Info header field including network-provided location information;
  7. a P-Visited-Network-ID header field; and
  8. if the MESSAGE request is to be sent via the S-CSCF, a Route header field with the S-CSCF address as received in the Service-Route header field during registration.
If the procedure above leads to a re-authentication from the user and no encryption of the signalling is used, the P-CSCF shall after a successful re-authentication, i.e. on receipt of the 200 (OK) response to the REGISTER request, send a MESSAGE request populated as above and including a Handover-Info header field set to "handover-completed".
Up

Up   Top   ToC