Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 24.229  Word version:  19.0.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.6 General treatment for all dialogs and standalone transactions excluding the REGISTER method  5.2.6.1 Introduction  5.2.6.2 Determination of UE-originated or UE-terminated case  5.2.6.3 Requests initiated by the UE  5.2.6.4 Requests terminated by the UE 
...

 

5.2.6  General treatment for all dialogs and standalone transactions excluding the REGISTER method  p. 189

5.2.6.1  Introduction  p. 189

The procedures of subclause 5.2.6 and its subclauses are general to all requests and responses, except those for the REGISTER method.

5.2.6.2  Determination of UE-originated or UE-terminated case  p. 189

Upon receipt of an initial request or a target refresh request or a stand-alone transaction, the P-CSCF shall:
  • perform the procedures for the UE-terminating case as described in subclause 5.2.6.4 if the request makes use of the information for UE-terminating calls, which was added to the Path header field entry of the P-CSCF during registration (see subclause 5.2.2), e.g. the message is received at a certain port or the topmost Route header field contains a specific user part or parameter;
  • perform the procedures for the UE-originating case as described in subclause 5.2.6.3 if this information is not used by the request.
Up

5.2.6.3  Requests initiated by the UE  p. 190

5.2.6.3.1  General for all requests |R8|  p. 190
When the P-CSCF receives an initial request for a dialog or a request for a standalone transaction from a UE that is not considered as privileged sender, and:
  • the request does not include any P-Preferred-Identity header field or none of the P-Preferred-Identity header fields included in the request matches any of the registered public user identities or any of the registered wildcarded public user identities, then the P-CSCF shall identify the originator and the served user of the request by the default public user identity;
  • the request includes one or two P-Preferred-Identity header field(s) each of which matches one of the registered public user identity or a registered wildcarded public user identity, the P-CSCF shall identify the originator and the served user of the request by the public user identity from the first such P-Preferred-Identity header field; and
  • the request includes two P-Preferred-Identity header fields, each of which matches a registered public user identity or a registered wildcarded public user identity, the P-CSCF shall identify the alternative identity of the originator of the request by the public user identity from the second such P-Preferred-Identity header field.
When the P-CSCF receives an initial request for a dialog or a request for a standalone transaction from a UE that is considered as privileged sender, and the request:
  1. does not include any P-Preferred-Identity header field, then the P-CSCF shall identify the served user of the request by the default public user identity;
  2. includes a P-Preferred-Identity header field that does not match one of the registered public user identities or wildcarded public user identities, then the P-CSCF shall identify the served user of the request by the default public user identity; or
  3. includes a P-Preferred-Identity header field that matches one of the registered public user identities or wildcarded public user identities, then the P-CSCF shall identify the served user of the request by the public user identity from the P-Preferred-Identity header field.
If a P-Preferred-Identity header field value is a SIP URI with the user part starting with a "+", and a "user" SIP URI parameter with a "phone" value, then the P-CSCF shall translate the SIP URI to a tel URI with the user part of the SIP URI in the telephone-subscriber element in the tel URI when checking whether the header field value matches any of the registered public user identities. The P-CSCF shall not modify the header field value within the P-Preferred-Identity header field.
In addition, if the request from a UE that is considered as privileged sender:
  1. includes one or two P-Asserted-Identity header field(s) then the P-CSCF shall identify the originator of that request by the public user identity from the first P-Asserted-Identity header field; or
  2. does not include a P-Asserted-Identity header field then the P-CSCF shall identify the originator of that request by the same identity that has been determined for the served user according to steps a), b), and c) above.
When the P-CSCF receives from the UE an initial request for a dialog or a request for a standalone transaction, if the host portion of the sent-by field in the topmost Via header field contains a FQDN, or if it contains an IP address that differs from the source address of the IP packet, the P-CSCF shall add a "received" header field parameter in accordance with the procedure defined in RFC 3261.
If the P-CSCF adds a "received" header field parameter and UDP is being used, the P-CSCF shall also add an "rport" header field parameter. If IMS AKA is used, the parameter value shall contain the UEs protected server port. Otherwise the parameter value shall contain the IP source of the request.
When the P-CSCF receives from the UE an initial request for a dialog or a request for a standalone transaction, and the request matches a trigger for starting logging of SIP signalling, as described in RFC 8497 and configured in the trace management object defined in TS 24.323, the P-CSCF shall treat the dialog as one for which logging of signalling is in progress and start to log SIP signalling for this dialog according to its trace configuration.
When the P-CSCF receives from the UE a request sent on a dialog for which logging of signalling is in progress, the P-CSCF shall check whether a trigger for stopping logging of SIP signalling has occurred, as described in RFC 8497 and configured in the trace management object defined in TS 24.323. If a stop trigger event has occurred then the P-CSCF shall stop treating the dialog as one for which logging of signalling is in progress, else the P-CSCF shall append a "logme" header field parameter to the SIP Session-ID header field if the parameter is missing and determine, by checking its trace configuration, whether to log the request.
If:
  • the P-CSCF supports indicating the traffic leg as specified in RFC 7459;
  • the UE is roaming;
  • the P-CSCF is not in the home network; and
  • required by local policy;
then the P-CSCF shall:
  • if the bottommost Route header field does not contain the "tokenized-by" header field parameter and an "iotl" SIP URI parameter is not already included, append the "iotl" SIP URI parameter with a value set to "visitedA-homeA" to the URI of the bottommost Route header field; and
  • if the bottommost Route header field contains the "tokenized-by" header field parameter and an "iotl" SIP URI parameter is not already included, append the "iotl" SIP URI parameter with a value set to "visitedA-homeA" to the URI of the second Route header field from the bottom.
If a P-CSCF supporting barring of premium numbers when roaming receives a request from a roaming UE and the Request-URI contains an E.164 number encoded as described in subclause 5.1.2A.1.2 which the P-CSCF is able to identify as a premium rate number in the country of the served network, the P-CSCF shall, based on local policy, add the "premium-rate" tel URI parameter specified in subclause 7.2A.17 set to a value "information" or "entertainment" as appropriate.
Up
5.2.6.3.2  General for all responses |R14|  p. 192
The P-CSCF shall log all SIP responses destined for the UE that contain a "logme" Session-ID header field parameter based on local policy.
5.2.6.3.2A  Abnormal cases |R8|  p. 192
When the P-CSCF is unable to forward the request to the next hop by the Route header fields, as determined by one of the following:
  • there is no response to the service request and its retransmissions by the P-CSCF; or
  • by unspecified means available to the P-CSCF;
and:
  • the P-CSCF supports S-CSCF restoration procedures;
then the P-CSCF:
  1. shall reject the request by returning a 504 (Server Time-out) response to the UE;
  2. shall assume that the UE supports version 1 of the XML Schema for the 3GPP IM CN subsystem XML body if support for the 3GPP IM CN subsystem XML body as described in subclause 7.6 in the Accept header field is not indicated; and
  3. shall include in the 504 (Server Time-out) response:
    • 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;
    • 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
    • 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 "restoration" (see table 7.6.2) to indicate that S-CSCF restoration procedures are supported;
        2. a <reason> child element, set to an operator configurable reason; and
        3. an <action> child element, set to "initial-registration" (see table 7.6.3).
If the P-CSCF receives a SIP request different from REGISTER that does not map to an existing IP association and unless the P-CSCF detects that the request is related to an emergency communication that is to be handled according to subclause 5.2.10.2 and if the request is not received from a UE performing the functions of an external attached network using static mode of operation, the P-CSCF shall discard this SIP request, i.e. it shall not send back a 100 Trying SIP response to the UE and shall not try to forward the request to the S-CSCF.
Up
5.2.6.3.3  Initial request for a dialog |R8|  p. 193
When the P-CSCF receives from the UE an initial request for a dialog, and a service route value list exists for the served user of the request, the P-CSCF shall:
1)
remove its own SIP URI from the top of the list of Route header fields;
2)
if the UE is performing the functions of an external attached network using static mode of operation:
  1. select an I-CSCF and insert a Route header field with the URI of the I-CSCF as the topmost Route header field; otherwise
  2. verify that the resulting list of Route header fields matches the list of URIs received in the Service-Route header field (during the last successful registration or reregistration). This verification is done on a per URI basis, not as a whole string. If the verification fails, then the P-CSCF shall either:
    1. return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with the execution of steps 2 onwards; or
    2. replace the preloaded Route header field value in the request with the value of the Service-Route header field received during the last 200 (OK) response for the last successful registration or reregistration;
3)
if the 200 (OK) response to the last REGISTER request, which created or refreshed the binding of the contact address from which the request is received, has not contained a Feature-Caps header field, specified in RFC 6809 with a "+g.3gpp.atcf" header field parameter, then:
  1. if the P-CSCF is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, select an IBCF in the visited network and add the URI of the selected IBCF to the topmost Route header field;
3A)
if the 200 (OK) response to the last REGISTER request, which created or refreshed the binding of the contact address from which the request is received, contained a Feature-Caps header field with a "+g.3gpp.atcf" header field parameter, then:
  1. add the ATCF URI for originating requests that the P-CSCF used to forward the last REGISTER request which created or refreshed the binding of the contact address from which the request is received, to the topmost Route header field;
4)
add its own address to the Via header field. The P-CSCF Via header field entry is built in a format that contains the port number of the P-CSCF in accordance with the procedures of RFC 3261, and either:
  1. the P-CSCF FQDN that resolves to the IP address, or
  2. the P-CSCF IP address;
5)
when adding its own SIP URI to the Record-Route header field, build the P-CSCF SIP URI in a format that contains the port number of the P-CSCF where it awaits subsequent requests from the called party, and either:
  1. the P-CSCF FQDN that resolves to the IP address; or
  2. the P-CSCF IP address.
If the Contact header field in the request contains an "ob" SIP URI parameter, the P-CSCF shall add a flow token and the "ob" SIP URI parameter to its SIP URI;
5A)
if a P-Private-Network-Indication header field is included in the request, check whether the information saved during registration or from configuration allows the receipt of private network traffic from this source. If private network traffic is allowed, the P-CSCF shall check whether the received domain name in any included P-Private-Network-Indication header field in the request is the same as the domain name associated with that saved information. If private network traffic is not allowed, or the received domain name does not match, then the P-CSCF shall remove the P-Private-Network-Indication header field;
5B)
if the served user of the request is understood from information saved during registration or from configuration to always send and receive private network traffic from this source, insert a P-Private-Network-Indication header field containing the domain name associated with that saved information;
5C)
if the request is originated from a UE which the P-CSCF considers as privileged sender (including one which is also a UE performing the functions of an external attached network using static mode of operation), keep the P-Asserted-Identity header field unchanged if one was received, or include the originator of the request in the P-Asserted-Identity header field if no P-Asserted-Identity header field was received. In addition remove any P-Preferred-Identity header field, include the served user of the request in the P-Served-User header field as specified in RFC 5502 and skip step 6) below;
5D)
if the request is originated from a UE performing the functions of an external attached network using static mode of operation and which the P-CSCF considers as is not a privileged sender, include the served user of the request in the P-Served-User header field as specified in RFC 5502 and skip step 6) below;
6)
remove any P-Preferred-Identity header field or P-Asserted-Identity header field, if present, and insert a P-Asserted-Identity header field with the value identifying the originator of the request and the value of the alternative identity of the originator of the request, if identified (see subclause 5.2.6.3.1), including the display name if previously stored during registration representing the served user of the request;
6A)
if the identity of the served user of the request was taken from P-Preferred-Identity header field by matching a registered wildcarded public user identity, and the identity of the served user is not a distinct identity within the range of the wildcarded public user identity, include the wildcarded public user identity value in the P-Profile-Key header field as defined in RFC 5002;
7)
add a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260 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. Based on local policy, the P-CSCF shall add an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier;
7A)
if the request comes from a UE performing the functions of an external attached network using static mode of operation add the "orig" parameter to the dialog request to indicate that this is an originating request; and
8)
if the request is an INVITE request, save the Contact, CSeq and Record-Route header field values received in the request such that the P-CSCF is able to release the session if needed. If the Contact header field in the INVITE request contains a GRUU, the P-CSCF shall save the GRUU received in the Contact header field of the request and associate that GRUU with the UE contact address used during registration or with the registration flow and the associated UE contact address used over which the INVITE request was received such that the P-CSCF is able to release the session if needed
before forwarding the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261.
If the request comes from a UE performing the functions of an external attached network using static mode of operation:
  • no response is received to the initial request for dialog and its retransmissions by the P-CSCF; or
  • a 3xx response or 480 (Temporarily Unavailable) response is received,
the P-CSCF shall repeat the actions of the above bullets with a different I-CSCF.
If the P-CSCF fails to forward the initial request for dialog to any I-CSCF, the P-CSCF shall send back a 504 (Server Time-Out) response to the UE performing the functions of an external attached network, in accordance with the procedures in RFC 3261.
Up
5.2.6.3.4  Responses to an initial request for a dialog |R8|  p. 195
When the P-CSCF receives any 1xx or 2xx response to the above request, the P-CSCF shall:
  1. store the values received in the P-Charging-Function-Addresses header field;
  2. store the list of Record-Route header fields from the received response;
  3. store the dialog ID and associate it with the private user identity and public user identity involved in the session;
  4. if a security association or TLS session exists, in the response rewrite its own Record Route entry to its own SIP URI that contains the protected server port number of the security association or TLS session established from the UE to the P-CSCF and either:
    1. the P-CSCF FQDN that resolves to the IP address of the security association or TLS session established from the UE to the P-CSCF; or
    2. the P-CSCF IP address of the security association or TLS session established from the UE to the P-CSCF;
  5. if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled authentication is used, in the response rewrite its own Record-Route entry to its own SIP URI that contains an unprotected server port number where the P-CSCF expects subsequent requests from the UE; and
  6. if the response corresponds to an INVITE request, save the Contact, From, To and Record-Route header field values received in the response such that the P-CSCF is able to release the session if needed;
before forwarding the response to the UE in accordance with the procedures of RFC 3261.
The P-CSCF shall forward the response to the UE using the mechanisms described in RFC 3261 and RFC 3581, i.e. the P-CSCF shall send the response to the IP address indicated in the "received" header field parameter and, in case UDP is used, to the port indicated in the "rport" header field parameter (if present) of the Via header field associated with the UE. In case TCP is used, the P-CSCF shall use the TCP connection on which the REGISTER request was received for sending the response back to the UE.
Up
5.2.6.3.5  Target refresh request for a dialog |R8|  p. 196
When the P-CSCF receives from the UE a target refresh request for a dialog, the P-CSCF shall:
1)
verify if the request relates to a dialog in which the originator of the request is involved:
  1. if the request does not relates to an existing dialog in which the originator is involved, then the P-CSCF shall answer the request by sending a 403 (Forbidden) response back to the originator. The P-CSCF will not forward the request. No other actions are required; or
  2. if the request relates to an existing dialog in which the originator is involved, then the P-CSCF shall continue with the following steps;
1A)
remove its own SIP URI from the top of the list of Route header fields;
2)
verify that the resulting list of Route header fields matches the list of Record-Route header fields constructed by inverting the order of the stored list of Record-Route header fields and removing its Record-Route header field value from the list. This verification is done on a per URI basis, not as a whole string. If the verification fails, then the P-CSCF shall either:
  1. return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with the execution of steps 3 onwards; or
  2. replace the Route header field value in the request with the list of Record-Route header fields constructed by inverting the order of the stored list of Record-Route header fields and removing its Record-Route header value from the list;
3)
add its own address to the Via header field. The P-CSCF Via header field entry is built in a format that contains the port number of the P-CSCF where it awaits the responses to come, and either:
  1. the P-CSCF FQDN that resolves to the IP address, or
  2. the P-CSCF IP address;
4)
void
5)
for INVITE dialogs (i.e. dialogs initiated by an INVITE request), replace the saved Contact and CSeq header field values received in the request such that the P-CSCF is able to release the session if needed. If the Contact header field in the INVITE request contains a GRUU, the P-CSCF shall save the GRUU received in the Contact header field of the request and associate that GRUU with the UE contact address used during session establishment or with the registration flow and the associated UE contact address used during session establishment such that the P-CSCF is able to release the session if needed;
6)
if the P-CSCF inserted the header field parameters into the Feature-Caps header field of the initial request for the dialog then when the target refresh request is forwarded in the same direction, the P-CSCF shall insert the header field parameters with the same parameter values in the Feature-Caps header field; and
7)
add a P-Charging-Vector header field with the "icid-value" header field parameter set to the value populated in the initial request for the dialog 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;
before forwarding the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261.
Up
5.2.6.3.6  Responses to a target refresh request for a dialog |R8|  p. 196
When the P-CSCF receives a 1xx or 2xx response to the above request, the P-CSCF shall:
  1. if a security association or TLS session exists, rewrite the address and port number of its own Record Route entry to the same value as for the response to the initial request for the dialog; and
  2. replace the saved Contact header field value received in the response such that the P-CSCF is able to release the session if needed;
before forwarding the response to the UE in accordance with the procedures of RFC 3261.
Up
5.2.6.3.7  Request for a standalone transaction |R8|  p. 197
When the P-CSCF receives from the UE the request for a standalone transaction, and a service route value list exists for the served user of the request, the P-CSCF shall:
1)
remove its own SIP URI from the top of the list of Route header fields;
2)
if the UE is performing the functions of an external attached network using static mode of operation:
  1. select an I-CSCF and insert a Route header field with the URI of the I-CSCF as the topmost Route header field; otherwise
  2. verify that the resulting list of Route header fields matches the list of URIs received in the Service-Route header field (during the last successful registration or reregistration). This verification is done on a per URI basis, not as a whole string. If the verification fails, then the P-CSCF shall either:
    1. return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with the execution of steps 3 onwards; or
    2. replace the preloaded Route header field value in the request with the one received during the last registration in the Service-Route header field of the 200 (OK) response;
3)
if the 200 (OK) response to the last REGISTER request, which created or refreshed the binding of the contact address from which the request is received, has not contained a Feature-Caps header field, specified in RFC 6809 with a "+g.3gpp.atcf" header field parameter, then:
  1. if the P-CSCF is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, select an IBCF in the visited network and add the URI of the selected IBCF to the topmost Route header field;
3A)
if the 200 (OK) response to the last REGISTER request, which created or refreshed the binding of the contact address from which the request is received, contained a Feature-Caps header field with a "+g.3gpp.atcf" header field parameter, then:
  1. add the ATCF URI for originating requests, that the P-CSCF used to forward the last REGISTER request which created or refreshed the binding of the contact address from which the request is received, to the topmost Route header field;
3B)
if the request is originated from a UE which the P-CSCF considers as privileged sender (including one which is also a UE performing the functions of an external attached network using static mode of operation), keep the P-Asserted-Identity header field unchanged if one was received, or include the originator of the request in the P-Asserted-Identity header field if no P-Asserted-Identity header field was received. In addition remove any P-Preferred-Identity header field, include the served user of the request in the P-Served-User header field as specified in RFC 5502 and skip step 4) below;
3D)
if the request is originated from a UE performing the functions of an external attached network using static mode of operation and which the P-CSCF considers as is not a privileged sender, include the served user of the request in the P-Served-User header field as specified in RFC 5502 and skip step 4) below;
4)
remove any P-Preferred-Identity header field or P-Asserted-Identity header field, if present, and insert P-Asserted-Identity header fields the value identifying the served user of the request and the value of the alternative identity of the originator of the request, if identified (see subclause 5.2.6.3.1), including the display name if previously stored during registration, representing the served user of the request;
4A)
if the identity of the served user of the request was taken from P-Preferred-Identity header field by matching a registered wildcarded public user identity, and the identity of the served user is not a distinct identity within the range of the wildcarded public user identity, include the wildcarded public user identity value in the P-Profile-Key header field as defined in RFC 5002;
4B)
if a P-Private-Network-Indication header field is included in the request, check whether the information saved during registration or from configuration allows the receipt of private network traffic from this source. If private network traffic is allowed, the P-CSCF shall check whether the received domain name in any included P-Private-Network-Indication header field in the request is the same as the domain name associated with that saved information. If private network traffic is not allowed, or the received domain name does not match, then the P-CSCF shall remove the P-Private-Network-Indication header field;
4C)
if the served user of the request is understood from information saved during registration or from configuration to always send and receive private network traffic from this source, insert a P-Private-Network-Indication header field containing the domain name associated with that saved information; and
4D)
if the request comes from a UE performing the functions of an external attached network using static mode of operation add the "orig" parameter to the dialog request to indicate that this is an originating request; and
5)
add a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260 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. Based on local policy, the P-CSCF shall add an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier;
before forwarding the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261.
If the request comes from a UE performing the functions of an external attached network using static mode of operation:
  • no response is received to the standalone SIP request and its retransmissions by the P-CSCF; or
  • a 3xx response or 480 (Temporarily Unavailable) response is received,
the P-CSCF shall repeat the actions of the above bullets with a different I-CSCF.
If the P-CSCF fails to forward the standalone SIP request to any I-CSCF, the P-CSCF shall send back a 504 (Server Time-Out) response to the UE performing the functions of an external attached network, in accordance with the procedures in RFC 3261.
Up
5.2.6.3.8  Responses to a request for a standalone transaction |R8|  p. 198
When the P-CSCF receives any response to the above request, the P-CSCF shall:
  1. store the values received in the P-Charging-Function-Addresses header field;
    before forwarding the response to the UE in accordance with the procedures of RFC 3261.
The P-CSCF shall forward the response to the UE using the mechanisms described in RFC 3261 and RFC 3581, i.e. the P-CSCF shall send the response to the IP address indicated in the "received" header field parameter and, in case UDP is used, to the port indicated in the "rport" header field parameter (if present) of the Via header field associated with the UE. In case TCP is used, the P-CSCF shall use the TCP connection on which the REGISTER request was received for sending the response back to the UE.
Up
5.2.6.3.9  Subsequent request other than a target refresh request |R8|  p. 199
When the P-CSCF receives from the UE a subsequent request other than a target refresh request (including requests relating to an existing dialog where the method is unknown), the P-CSCF shall:
1)
verify if the request relates to a dialog in which the originator of the request is involved:
  1. if the request does not relates to an existing dialog in which the originator is involved, then the P-CSCF shall answer the request by sending a 403 (Forbidden) response back to the originator. The P-CSCF will not forward the request. No other actions are required; or
  2. if the request relates to an existing dialog in which the originator is involved, then the P-CSCF shall continue with the following steps;
1A)
remove its own SIP URI from the top of the list of Route header fields;
2)
verify that the resulting list of Route header fields matches the list of Record-Route header fields constructed by inverting the order of the stored list of Record-Route header fields and removing its Record-Route header field from the list. This verification is done on a per URI basis, not as a whole string. If the verification fails, then the P-CSCF shall either:
  1. return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with the execution of steps 3 onwards; or
  2. replace the Route header field value in the request with the list of Record-Route header fields constructed by inverting the order of the stored list of Record-Route header fields and removing its Record-Route header field from the list;
3)
add a P-Charging-Vector header field with the "icid-value" header field parameter set to the value populated in the initial request for the dialog 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; and
4)
for INVITE dialogs, replace the saved CSeq header field value received in the request such that the P-CSCF is able to release the session if needed;
before forwarding the request (based on the topmost Route header field), in accordance with the procedures of RFC 3261.
Up
5.2.6.3.10  Responses to a subsequent request other than a target refresh request |R8|  p. 199
Void
5.2.6.3.11  Request for an unknown method that does not relate to an existing dialog |R8|  p. 199
When the P-CSCF receives from the UE the request for an unknown method (that does not relate to an existing dialog), and a service route value list exists for the served user of the request, the P-CSCF shall:
1)
if the UE performing the functions of an external attached network using static mode of operation:
  1. select an I-CSCF and insert a Route header field with the URI of the I-CSCF as the topmost Route header field; otherwise
  2. verify that the list of URIs received in the Service-Route header field (during the last successful registration or reregistration) is included, preserving the same order, as a subset of the preloaded Route header fields in the received request. This verification is done on a per URI basis, not as a whole string. If the verification fails, then the P-CSCF shall either:
    1. return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with the execution of steps 2 onwards; or
    2. replace the Route header field value in the request with the one received during the last registration in the Service-Route header field of the 200 (OK) response;
2)
if the 200 (OK) response to the last REGISTER request, which created or refreshed the binding of the contact address from which the request is received, has not contained a Feature-Caps header field, specified in RFC 6809 with a "+g.3gpp.atcf" header field parameter, then:
  1. if the P-CSCF is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, then the P-CSCF shall select an IBCF in the visited network and add the URI of the selected IBCF to the topmost Route header field;
2A)
if the 200 (OK) response to the last REGISTER request, which created or refreshed the binding of the contact address from which the request is received, contained a Feature-Caps header field with a "+g.3gpp.atcf" header field parameter, then:
  1. add the ATCF URI for originating requests, that the P-CSCF used to forward the last REGISTER request which created or refreshed the binding of the contact address from which the request is received, to the topmost Route header field;
2B)
if the request is originated from a UE which the P-CSCF considers as privileged sender (including one which is also a UE performing the functions of an external attached network using static mode of operation), keep the P-Asserted-Identity header field unchanged if one was received, or include the originator of the request in the P-Asserted-Identity header field if no P-Asserted-Identity header field was received. In addition remove any P-Preferred-Identity header field, include the served user of the request in the P-Served-User header field as specified in RFC 5502 and skip step 3) below;
2C)
if the request is originated from a UE performing the functions of an external attached network using static mode of operation and which the P-CSCF considers as is not a privileged sender, include the served user of the request in the P-Served-User header field as specified in RFC 5502 and skip step 3) below;
3)
remove any P-Preferred-Identity header field or P-Asserted-Identity header field, if present, and insert a P-Asserted-Identity header fields the value identifying the originator of the request and the value of the alternative identity of the originator of the request, if identified (see subclause 5.2.6.3.1), including the display name if previously stored during registration, representing the served user of the request;
3A)
if the identity of the served user of the request was taken from P-Preferred-Identity header field by matching a registered wildcarded public user identity, and the identity of the served user is not a distinct identity within the range of the wildcarded public user identity, include the wildcarded public user identity value in the P-Profile-Key header field as defined in RFC 5002; and
3B)
if the request comes from a UE performing the functions of an external attached network using static mode of operation add the "orig" parameter to the dialog request to indicate that this is an originating request; and
4)
add a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260 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. Based on local policy, the P-CSCF shall add an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier;
before forwarding the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261.
If the request comes from a UE performing the functions of an external attached network using static mode of operation:
  • no response is received to the standalone SIP request and its retransmissions by the P-CSCF; or
  • a 3xx response or 480 (Temporarily Unavailable) response is received,
the P-CSCF shall repeat the actions of the above bullets with a different I-CSCF.
If the P-CSCF fails to forward the unknown SIP request to any I-CSCF, the P-CSCF shall send back a 504 (Server Time-Out) response to the UE performing the functions of an external attached network using static mode of operation, in accordance with the procedures in RFC 3261.
Up
5.2.6.3.12  Responses to a request for an unknown method that does not relate to an existing dialog |R8|  p. 201

5.2.6.4  Requests terminated by the UE  p. 201

5.2.6.4.1  General for all requests |R12|  p. 201
The P-CSCF shall log all SIP requests destined for the UE that contain a "logme" Session-ID header field parameter based on local policy.
If the serving network supports PCRF based P-CSCF restoration and the Restoration-Info header field is included in the incoming request, and the P-CSCF has no binding for the identity in the Request-URI, the P-CSCF shall:
  • initiate the PCRF based P-CSCF restoration procedure as specified in TS 23.380 using the IMSI value contained in the Restoration-Info header field; and
  • reject the request with a 404 (Not Found) response.
If the P-CSCF supports PCRF based P-CSCF restoration procedures, the P-CSCF shall remove the Restoration-Info header field, if included in the incoming request.
If the serving network supports HSS based P-CSCF restoration procedures and the P-CSCF has no binding for the identity in the Request-URI, the P-CSCF shall reject the request with a 404 (Not Found) response.
If the user-related policies provisioned to the P-CSCF (see subclause 5.2.1) do not indicate that the served UE is authorized to send early media, the P-CSCF shall not allow media flows in forward and backward direction before the 200 (OK) response to the initial INVITE is received. Based on operator policy the P-CSCF shall either remove the P-Early-Media header field or replace the value of the P-Early-Media header field with "inactive", if received from the terminating UE.
If the user-related policies provisioned to the P-CSCF (see subclause 5.2.1) indicate that the served UE is authorized to send early media, the P-CSCF shall not remove or modify the P-Early-Media header field if received in an UPDATE request.
Up
5.2.6.4.2  General for all responses |R9|  p. 202
When the P-CSCF receives, destined for the UE, a response sent on a dialog for which logging of signalling is in progress, the P-CSCF shall check whether a trigger for stopping logging of SIP signalling has occurred, as described in RFC 8497 and configured in the trace management object defined in TS 24.323. If a stop trigger event has occurred then the P-CSCF shall stop treating the dialog as one for which logging of signalling is in progress, else the P-CSCF shall append a "logme" header field parameter to the SIP Session-ID header field if the parameter is missing and determine, by checking its trace configuration, whether to log the request.
If the user-related policies provisioned to the P-CSCF (see subclause 5.2.1) do not indicate that the served UE is authorized to send early media, the P-CSCF shall not allow media flows in forward and backward direction before the 200 (OK) response to the initial INVITE is received. Based on operator policy the P-CSCF shall either remove the P-Early-Media header field or replace the value of the P-Early-Media header field with "inactive", if received from the terminating UE.
If the user-related policies provisioned to the P-CSCF (see subclause 5.2.1) indicate that the served UE is authorized to send early media, the P-CSCF shall not remove or modify the P-Early-Media header field if received in a 18x provisional response.
Up
5.2.6.4.3  Initial request for a dialog |R8|  p. 202
When the P-CSCF receives, destined for the UE, an initial request for a dialog, prior to forwarding the request, the P-CSCF shall:
1)
if an indication has been received from the PCRF that the signalling bearer to the UE is lost, and has not recovered, reject the request by sending 500 (Server Internal Error) response;
2)
convert the list of Record-Route header field values into a list of Route header field values and save this list of Route header fields;
3)
if the request is an INVITE request, save a copy of the Contact, CSeq and Record-Route header field values received in the request such that the P-CSCF is able to release the session if needed;
4)
if a security association or TLS session exists, when adding its own SIP URI to the top of the list of Record-Route header fields and save the list, build the P-CSCF SIP URI in a format that contains the protected server port number of the security association or TLS session established from the UE to the P-CSCF and either:
  1. the P-CSCF FQDN that resolves to the IP address of the security association or TLS session established from the UE to the P-CSCF; or
  2. the P-CSCF IP address of the security association or TLS session established from the UE to the P-CSCF;
5)
if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled authentication is used, when adding its own SIP URI to the top of the list of Record-Route header fields and saving the list, build the P-CSCF URI in a format that contains an unprotected server port number where the P-CSCF expects subsequent requests from the UE;
6)
if a security association or TLS session exists, when adding its own address to the top of the received list of Via header fields and save the list, build the P-CSCF Via header field entry in a format that contains the protected server port number of the security association or TLS session established from the UE to the P-CSCF and either:
  1. the P-CSCF FQDN that resolves to the IP address of the security association or TLS session established from the UE to the P-CSCF; or
  2. the P-CSCF IP address of the security association or TLS session established from the UE to the P-CSCF;
7)
if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled athentication is used, when adding its own address to the top of the received list of Via header fields and saving the list, build the P-CSCF Via header field entry in a format that contains an unprotected server port number where the P-CSCF expects responses to the current request from the UE;
7A)
if the recipient of the request is understood from information saved during registration or from configuration to always send and receive private network traffic from this source, remove the P-Private-Network-Indication header field containing the domain name associated with that saved information;
8)
store the values received in the P-Charging-Function-Addresses header field;
9)
store the "icid-value" header field parameter and if present, the "orig-ioi" header field parameter received in the P-Charging-Vector header field;
10)
if the request contains an "fe-identifier" header field parameter, based on local policy, store the content of the "fe-identifier" header field parameter of the P-Charging-Vector header field; and
11)
save a copy of the P-Called-Party-ID header field;
before forwarding the request to the UE either in accordance with the procedures of RFC 3261 or as specified in RFC 5626.
If no security association exists between the P-CSCF and the UE performing the functions of an external attached network operating in static mode, the P-CSCF shall initiate a TLS session towards the UE performing the functions of an external attached network operating in static mode before sending the initial request in accordance with TS 33.310.
Once the TLS session is set up (using the certificates) the P-CSCF shall send the initial request for dialog over the secure connection to the UE performing the functions of an external attached network operating in static mode.
Up
5.2.6.4.4  Responses to an initial request for a dialog |R8|  p. 203
When the P-CSCF receives any 1xx or 2xx response to the above request, the P-CSCF shall:
0A)
if the response is originated from a UE which the P-CSCF considers as privileged sender, remove any P-Preferred-Identity header field, and skip step 1) below;
1)
remove any P-Preferred-Identity header field or P-Asserted-Identity header field, if present, and insert a P-Asserted-Identity header field with the saved public user identity from the P-Called-Party-ID header field that was received in the request, plus the display name if previously stored during registration, representing the originator of the response;
2)
verify that the list of Via header fields matches the saved list of Via header fields received in the request corresponding to the same dialog, including the P-CSCF Via header field value. This verification is done on a per Via header field value basis, not as a whole string. If the verification fails, then the P-CSCF shall either:
  1. discard the response; or
  2. replace the Via header field values with those received in the request;
3)
verify that the list of URIs received in the Record-Route header field of the request corresponding to the same dialog is included, preserving the same order, as a subset of the Record-Route header field list of this response. This verification is done on a per URI basis, not as a whole string.
If the verification fails, then the P-CSCF shall either:
  1. discard the response; or
  2. replace the Record-Route header field values with those received in the request, and if a security association or TLS session exists, add its own Record-Route entry with its own SIP URI with the port number where it awaits subsequent requests from the calling party. The P-CSCF shall include in the Record-Route header field either:
    • the P-CSCF FQDN that resolves to its IP address; or
    • the P-CSCF IP address.
    The P-CSCF shall remove the "comp" SIP URI parameter from the Record-Route header field.
If the verification is successful, the P-CSCF shall rewrite its own Record-Route entry to its SIP URI in a format that contains the port number where it awaits subsequent requests from the calling party. The P-CSCF shall include in the Record-Route header field either:
  1. the P-CSCF FQDN that resolves to its IP address; or
  2. the P-CSCF IP address.
The P-CSCF shall remove the "comp" SIP URI parameter from the Record-Route header field;
When adding its SIP URI to the Record-Route header field, the P-CSCF shall also copy the flow token and the "ob" SIP URI parameter from the Route header field of the initial dialog-forming request destined for the UE to its SIP URI, if the Route header field contained these values;
4)
store the dialog ID and associate it with the private user identity and public user identity involved in the session;
5)
if the response corresponds to an INVITE request, save the Contact, To, From and Record-Route header field value received in the response such that the P-CSCF is able to release the session if needed. If the Contact header field in the response to the INVITE request contains a GRUU, the P-CSCF shall save the GRUU received in the Contact header field of the response and associate that GRUU with the contact address which was used to send the INVITE request or with the registration flow and the associated UE contact address which was used to send on which the INVITE request such that the P-CSCF is able to release the session if needed; and
6)
include in the P-Charging-Vector header field:
  • an "icid-value" header field parameter set to the value received in the request;
  • the "orig-ioi" header field parameter, if received in the request; and
  • a type 1 "term-ioi" header field parameter that identifies the sending network;
  • if the P-CSCF has stored an "fe-identifier" header field parameter of the P-Charging-Vector header field, based on local policy, the stored "fe-identifier" header field parameter and include its own address or identifier in the "fe-addr" element of the "fe-identifier" header field parameter of the P-Charging-Vector header field.
before forwarding the response in accordance with the procedures of RFC 3261.
When the P-CSCF receives any other response to the above request, the P-CSCF shall:
  1. verify that the list of Via header fields matches the saved list of Via header fields received in the request corresponding to the same dialog, including the P-CSCF Via header field value. This verification is done on a per Via header field value basis, not as a whole string. If these lists do not match, then the P-CSCF shall either:
    1. discard the response; or
    2. replace the Via header field values with those received in the request; and
  2. include in the P-Charging-Vector header field:
    1. an "icid-value" header field parameter set to the value received in the request;
    2. the "orig-ioi" header field parameter, if received in the request; and
    3. a type 1 "term-ioi" header field parameter that identifies the sending network;
before forwarding the response in accordance with the procedures of RFC 3261.
Up
5.2.6.4.5  Target refresh request for a dialog |R8|  p. 205
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:
  1. if a security association or TLS session exists, add its own address to the top of the received list of Via header fields and save the list. The P-CSCF Via header field entry is built in a format that contains the protected server port number of the security association or TLS session established from the UE to the P-CSCF and either:
    1. the P-CSCF FQDN that resolves to the IP address of the security association or TLS session established from the UE to the P-CSCF; or
    2. the P-CSCF IP address of the security association or TLS session established from the UE to the P-CSCF;
  2. if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled authentication is used, when adding its own address to the top of the received list of Via header fields and saving the list, build the P-CSCF Via header field entry in a format that contains an unprotected server port number where the P-CSCF expects responses to the current request from the UE;
  3. if a security association or TLS session exists, when adding its own SIP URI to the top of the list of Record-Route header fields and save the list, build the P-CSCF SIP URI in a format that contains the protected server port number of the security association or TLS session established from the UE to the P-CSCF and either:
    1. the P-CSCF FQDN that resolves to the IP address of the security association or TLS session established from the UE to the P-CSCF; or
    2. the P-CSCF IP address of the security association or TLS session established from the UE to the P-CSCF;
  4. if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled authentication is used, when adding its own SIP URI to the top of the list of Record-Route header fields and saving the list, build the P-CSCF URI in a format that contains an unprotected server port number where the P-CSCF expects subsequent requests from the UE;
  5. for INVITE dialogs, replace the saved Contact and CSeq header field values received in the request such that the P-CSCF is able to release the session if needed;
  6. if the request is destined to a UE performing the functions of an external attached network operating in static mode, send the request using the already established TLS session as described in subclause 5.2.6.4.3; and
  7. store the "orig-ioi" header field parameter received in the P-Charging-Vector header field if present;
before forwarding the request to the UE in accordance with the procedures of either RFC 3261 or RFC 5626.
Up
5.2.6.4.6  Responses to a target refresh request for a dialog |R8|  p. 205
When the P-CSCF receives a 1xx or 2xx response to the above request, the P-CSCF shall:
  1. verify that the list of Via header fields matches the saved list of Via header fields received in the request corresponding to the same dialog, including the P-CSCF Via header field value. This verification is done on a per Via header field value basis, not as a whole string. If the verification fails, then the P-CSCF shall either:
    1. discard the response; or
    2. replace the Via header field values with those received in the request;
  2. if a security association or TLS session exists, rewrite its own Record-Route entry to the same value as for the response to the initial request for the dialog and remove the "comp" SIP URI parameter;
  3. replace the saved Contact header field value received in the response such that the P-CSCF is able to release the session if needed. If the Contact header field in the response to the target refresh request for a dialog contains a GRUU, the P-CSCF shall save the GRUU received in the Contact header field of the response and associate that GRUU with the contact address which was used to send the target refresh request or with the registration flow and the associated UE contact address which was used to send the target refresh request such that the P-CSCF is able to release the session if needed;
  4. if the P-CSCF inserted the header field parameters into the Feature-Caps header field of the initial request for the dialog then when the response is forwarded in the same direction, the P-CSCF shall insert the header field parameters with the same parameter values in the Feature-Caps header field; and
  5. include in the P-Charging-Vector header field:
    • an "icid-value" header field parameter set to the value populated in the initial request for the dialog;
    • the "orig-ioi" header field parameter, if received in the request; and
    • a type 1 "term-ioi" header field parameter that identifies the sending network;
before forwarding the response in accordance with the procedures of RFC 3261.
When the P-CSCF receives any other response to the above request, the P-CSCF shall:
  1. verify that the list of Via header fields matches the saved list of Via header fields received in the request corresponding to the same dialog, including the P-CSCF Via header field value. This verification is done on a per Via header field value basis, not as a whole string. If the verification fails, then the P-CSCF shall either:
    1. discard the response; or
    2. replace the Via header field values with those received in the request; and
  2. if a security association or TLS session exists, rewrite the IP address and the port number of its own Record-Route entry to the IP address and the port number where it awaits subsequent requests from the calling party and remove the "comp" SIP URI parameter;
  3. include in the P-Charging-Vector header field:
    1. an "icid-value" header field parameter set to the value populated in the initial request for the dialog;
    2. the "orig-ioi" header field parameter, if received in the request; and
    3. a type 1 "term-ioi" header field parameter that identifies the sending network;
before forwarding the response in accordance with the procedures of RFC 3261.
Up
5.2.6.4.7  Request for a standalone transaction |R8|  p. 206
When the P-CSCF receives, destined for the UE, a request for a standalone transaction, or a request for an unknown method (that does not relate to an existing dialog), prior to forwarding the request, the P-CSCF shall:
1)
if an indication has been received from the PCRF that the signalling bearer to the UE is lost, and has not recovered, reject the request by sending 500 (Server Internal Error) response;
2)
if a security association or TLS session exists, add its own address to the top of the received list of Via header fields and save the list. The P-CSCF Via header field entry is built in a format that contains the protected server port number of the security association or TLS session established from the UE to the P-CSCF and either:
  1. the P-CSCF FQDN that resolves to the IP address of the security association or TLS session established from the UE to the P-CSCF; or
  2. the P-CSCF IP address of the security association or TLS session established from the UE to the P-CSCF;
3)
if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled authentication is used, when adding its own address to the top of the received list of Via header fields and saving the list, build the P-CSCF Via header field entry in a format that contains an unprotected server port number where the P-CSCF expects responses to the current request from the UE;
3A)
if the recipient of the request is understood from information saved during registration or from configuration to always send and receive private network traffic from this source, remove the P-Private-Network-Indication header field containing the domain name associated with that saved information;
4)
store the values received in the P-Charging-Function-Addresses header field;
5)
store the "icid-value" header field parameter and if present, the "orig-ioi" header field parameter received in the P-Charging-Vector header field;
6)
if the request contains an "fe-identifier" header field parameter, based on local policy, store the content of the "fe-identifier" header field parameter of the P-Charging-Vector header field; and
7)
save a copy of the P-Called-Party-ID header field;
before forwarding the request to the UE either in accordance with the procedures of RFC 3261 or as specified in RFC 5626.
If no security association exists between the P-CSCF and the UE performing the functions of an external attached network operating in static mode, the P-CSCF shall initiate a TLS session towards the UE performing the functions of an external attached network operating in static mode before sending the standalone SIP request in accordance with TS 33.310.
Once the TLS session is set up (using the certificates) the P-CSCF shall send the standalone SIP request over the secure connection to the UE performing the functions of an external attached network operating in static mode.
Up
5.2.6.4.8  Responses to a request for a standalone transaction |R8|  p. 207
When the P-CSCF receives any response to the above request, the P-CSCF shall:
1)
verify that the list of Via header fields matches the saved list of Via header fields received in the request corresponding to the same dialog, including the P-CSCF Via header field value. This verification is done on a per Via header field value basis, not as a whole string. If these lists do not match, then the P-CSCF shall either:
  1. discard the response; or
  2. replace the Via header field values with those received in the request;
1A)
if the response is originated from a UE which the P-CSCF considers as privileged sender, remove any P-Preferred-Identity header field, and skip step 2) below;
2)
remove any P-Preferred-Identity header field or P-Asserted-Identity header field, if present, and insert an P-Asserted-Identity header field with the saved public user identity from the P-Called-Party-ID header field of the request, plus the display name if previously stored during registration, representing the originator of the response; and
3)
include in the P-Charging-Vector header field:
  • an "icid-value" header field parameter set to the value received in the request;
  • the "orig-ioi" header field parameter, if received in the request;
  • a type 1 "term-ioi" header field parameter that identifies the sending network; and
  • if the P-CSCF has stored an "fe-identifier" header field parameter of the P-Charging-Vector header field, based on local policy, the stored "fe-identifier" header field parameter and include its own address or identifier in the "fe-addr" element of the "fe-identifier" header field parameter of the P-Charging-Vector header field.
before forwarding the response in accordance with the procedures of RFC 3261.
Up
5.2.6.4.9  Subsequent request other than a target refresh request |R8|  p. 208
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:
  1. if a security association or TLS session exists, add its own address to the top of the received list of Via header fields and save the list The P-CSCF Via header field entry is built in a format that contains the protected server port number of the security association or TLS session established from the UE to the P-CSCF and either:
    1. the P-CSCF FQDN that resolves to the IP address of the security association or TLS session established from the UE to the P-CSCF; or
    2. the P-CSCF IP address of the security association or TLS session established from the UE to the P-CSCF;
  2. if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled authentication is used, when adding its own address to the top of the received list of Via header fields and saving the list, build the P-CSCF Via header field entry in a format that contains an unprotected server port number where the P-CSCF expects responses to the current request from the UE;
  3. void;
  4. for INVITE dialogs, replace the saved CSeq header field value received in the request such that the P-CSCF is able to release the session if needed;
  5. if the request is destined to a UE performing the functions of an external attached network operating in static mode, send the request using the already established TLS session as described in subclause 5.2.6.4.3; and
  6. store the "orig-ioi" header field parameter received in the P-Charging-Vector header field if present;
before forwarding the request to the UE either in accordance with the procedures of RFC 3261 or as specified in RFC 5626.
Up
5.2.6.4.10  Responses to a subsequent request other than a target refresh request |R8|  p. 208
When the P-CSCF receives any response to the above request, the P-CSCF shall:
  1. verify that the list of Via header fields matches the saved list of Via header fields received in the request corresponding to the same dialog, including the P-CSCF Via header field value. This verification is done on a per Via header field value basis, not as a whole string. If these lists do not match, then the P-CSCF shall either:
    1. discard the response; or
    2. replace the Via header field values with those received in the request; and
  2. include in the P-Charging-Vector header field:
    1. an "icid-value" header field parameter set to the value received in the initial request for the dialog;
    2. the "orig-ioi" header field parameter, if received in the request; and
    3. a type 1 "term-ioi" header field parameter that identifies the sending network;
before forwarding the response in accordance with the procedures of RFC 3261.
Up
5.2.6.4.11  Request for an unknown method that does not relate to an existing dialog |R8|  p. 209
Void.
5.2.6.4.12  Responses to a request for an unknown method that does not relate to an existing dialog |R8|  p. 209
Void.

Up   Top   ToC