Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  17.4.0

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

 

5.4.3  General treatment for all dialogs and standalone transactions excluding requests terminated by the S-CSCFWord‑p. 265

5.4.3.1  Determination of UE-originated or UE-terminated caseWord‑p. 265

Upon receipt of an initial request or a stand-alone transaction, the S-CSCF shall:
  • perform the procedures for the UE-originating case as described in subclause 5.4.3.2 if the request makes use of the information for UE-originating calls, which was added to the Service-Route header field entry of the S-CSCF during registration (see subclause 5.4.1.2.2F), e.g. the message is received at a certain port or the topmost Route header field contains a specific user part or parameter; or,
  • perform the procedures for the UE-originating case as described in subclause 5.4.3.2 if the topmost Route header field of the request contains the "orig" parameter. The S-CSCF shall remove the "orig" parameter from the topmost Route header field; or,
  • perform the procedures for the UE-terminating case as described in subclause 5.4.3.3 if this information is not used by the request.
Up

5.4.3.2  Requests initiated by the served userWord‑p. 265

For all SIP transactions identified:
  • if priority is supported, as containing an authorised Resource-Priority header field or a temporarily authorised Resource-Priority header field, or, if such an option is supported, relating to a dialog which previously contained an authorised Resource-Priority header field;
the S-CSCF shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs. If priority is supported, the S-CSCF shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field or backwards indication value.
When the S-CSCF receives from the UE an initial request for a dialog, which contains a GRUU and an "ob" SIP URI parameter in the Contact header field, and multiple contact addresses have been registered for the specific GRUU, then for all subsequent in-dialog requests sent toward the UE's, the S-CSCF shall populate the Request-URI with the registered contact address from which the UE sent the initial request for the dialog.
When performing SIP digest without TLS, when the S-CSCF receives from the served user an initial request for a dialog or a request for a standalone transaction, the S-CSCF may perform the steps in subclause 5.4.3.6 to challenge the request based on local policy.
When performing GPRS-IMS-Bundled authentication, when the S-CSCF receives from the served user an initial request for a dialog or a request for a standalone transaction, the S-CSCF shall check whether a "received" header field parameter exists in the Via header field provided by the UE. If a "received" header field parameter exists, S-CSCF shall compare the (prefix of the) IP address received in the "received" header field parameter against the UE's IP address (or prefix) stored during registration. If no "received" header field parameter exists in the Via header field provided by the UE, then S-CSCF shall compare the (prefix of the) IP address received in the "sent-by" parameter against the IP address (or prefix) stored during registration. If the stored IP address (or prefix) and the (prefix of the) IP address in the "received" Via header field parameter provided by the UE do not match, the S-CSCF shall reject the request with a 403 (Forbidden) response. In case the stored IP address (or prefix) and the (prefix of the) IP address in the "received" Via header field parameter provided by the UE do match, the S-CSCF shall proceed as described in the remainder of this subclause.
If the S-CSCF supports HSS based P-CSCF restoration, and receives a request from a P-CSCF that the S-CSCF considers is not reachable, the S-CSCF shall consider this P-CSCF as being reachable.
If the S-CSCF supports PCRF based P-CSCF restoration, and receives a request from a P-CSCF that the S-CSCF considers is in a not reachable, the S-CSCF shall consider this P-CSCF as being reachable.
When the S-CSCF receives from the served user or from a PSI an initial request for a dialog or a request for a standalone transaction, and the request is received either from a functional entity within the same trust domain or contains a valid original dialog identifier (see step 3) or the dialog identifier (From, To and Call-ID header fields) relates to an existing request processed by the S-CSCF, then prior to forwarding the request, the S-CSCF shall:
0)
if the request is received from a P-CSCF that does not support the trust domain handling of the P-Served-User header field then remove any P-Served-User header fields;
1)
determine the served user as follows:
  1. if the request contains a P-Served-User header field then
    1. determine the served user by taking the identity contained in a P-Served-User header field as defined in RFC 5502. Then check whether the determined served user is a barred public user identity. In case the said header field contains the served user identity is a barred public user identity for the user, then the S-CSCF shall reject the request by generating a 403 (Forbidden) response. Otherwise, the S-CSCF shall save the public user identity of the served user and continue with the rest of the steps;
  2. if the request does not contain a P-Served-User header field then
    1. determine the served user by taking the identity contained in one of the URI(s) of the P-Asserted-Identity header field. In case the determined served user is a barred public user identity, then the S-CSCF shall reject the request by generating a 403 (Forbidden) response. Otherwise, the S-CSCF shall save the public user identity of the served user and continue with the rest of the steps; and
    2. if the P-Asserted-Identity header field contains two URIs and the URI other than the determined served user is not an alias of the determined served user or is barred then act based on local policy, e.g. reject the request by generating a 403 (Forbidden) response or remove the URI not identifying the determined served user from the P-Asserted-Identity header field;
1A)
if the Contact is a GRUU, but is not valid as defined in subclause 5.4.7A.4, then return a 4xx response as specified in RFC 5627;
2)
store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field if present, and remove it from any forwarded request;
3)
check if an original dialog identifier that the S-CSCF previously placed in a Route header field is present in the topmost Route header field of the incoming request.
  • If not present, the S-CSCF shall build an ordered list of initial filter criteria based on the public user identity of the served user (as determined in step 1) of the received request as described in TS 23.218.
  • If present, the request has been sent from an AS in response to a previously sent request, an ordered list of initial filter criteria already exists and the S-CSCF shall not change the ordered list of initial filter criteria even if the AS has changed the P-Served-User header field or the P-Asserted-Identity header field;
4)
remove its own SIP URI from the topmost Route header field;
4A)
if a reference location was received from the HSS at registration as part of the user profile and the request does not contain a message body with the content type application/pidf+xml in accordance with RFC 6442 and does not contain a P-Access-Network-Info header field containing the "network-provided" parameter, the S-CSCF shall insert a P-Access-Network-Info header field constructed according to the reference location received from the HSS and containing the "network-provided" parameter. The access type information received from the HSS shall be mapped into the corresponding access-type parameter of the P-Access-Network-Info header field and the location information shall be mapped into the location parameter corresponding to the access-type parameter, i.e. into "dsl-location" parameter, "fiber-location" parameter or "eth-location" parameter;
4B)
if there was an original dialog identifier present in the topmost Route header field of the incoming request and the request is received from a functional entity within the same trust domain and contains a P-Asserted-Service header field, continue the procedure with step 5;
4C)
if the request contains a P-Preferred-Service header field, check whether the ICSI value contained in the P-Preferred-Service header field is part of the set of the subscribed services for the served user and determine, using operator-configured data, whether the contents of the request match the ICSI for the subscribed service. The operator-configured data used to determine if there is a matching between the request and the ICSI value may be based on any information in the request (e.g. SDP media capabilities, Content-Type header field, request method). Then:
  1. if there is no match between the request and the ICSI value, as an operator option, the S-CSCF may reject the request by generating a 403 (Forbidden) response. Otherwise remove the P-Preferred-Service header field and continue with the rest of the steps; and
  2. if there is a match between the request and the ICSI value, then include a P-Asserted-Service header field in the request containing the ICSI value contained in the P-Preferred-Service header field, remove the P-Preferred-Service header field, and continue the procedure with step 5;
4D)
if the request does not contain a P-Preferred-Service header field, check, using operator-configured data, whether the contents of the request match a subscribed service for each and any of the subscribed services for the served user:
  1. if not, as an operator option, the S-CSCF may reject the request by generating a 403 (Forbidden) response; and
  2. if so, and if the request is related to an IMS communication service and the IMS communication service requires the use of an ICSI value then select an ICSI value for the related IMS communication service and include a P-Asserted-Service header field in the request containing the selected ICSI value; and
  3. if so, and if the request is related to an IMS communication service and the IMS communication service does not require the use of an ICSI value then continue without including an ICSI value; and
  4. if so, and if the request does not relate to an IMS communication service (or if the S-CSCF is unable to unambiguously determine the service being requested but decides to allow the session to continue) then continue without including an ICSI value;
5)
check whether the initial request matches any unexecuted initial filter criteria. If there is a match, then the S-CSCF shall select the first matching unexecuted initial filter criteria from the ordered list of initial filter criteria and the S-CSCF shall:
  1. insert the AS URI to be contacted into the Route header field as the topmost entry followed by its own URI populated as specified in the subclause 5.4.3.4;
  2. if the S-CSCF supports the P-Served-User extension as specified in RFC 5502 and RFC 8498 insert P-Served-User header field populated with the served user identity as determined in step 1. If required by operator policy, the S-CSCF shall:
    • if the associated session case is "Originating" as specified in TS 29.228, include the sescase header field parameter set to "orig" and the regstate header field parameter set to "reg";
    • if the associated session case is "Originating_Unregistered" as specified in TS 29.228, include the sescase header field parameter set to "orig" and the regstate header field parameter set to "unreg";
    • if the associated session case is "Originating_CDIV" as specified in TS 29.228, include the "orig-cdiv" header field parameter, defined in RFC 8498; and
  3. if the AS is located outside the trust domain then the S-CSCF shall remove the access-network-charging-info parameter in the P-Charging-Vector header field from the request that is forwarded to the AS; if the AS is located within the trust domain, then the S-CSCF shall retain the access-network-charging-info parameter in the P-Charging-Vector header field in the request that is forwarded to the AS;
  4. insert a type 3 "orig-ioi" header field parameter in place of any received "orig-ioi" header field parameters in the P-Charging-Vector header field. The S-CSCF shall set the type 3 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The S-CSCF shall not include the type 3 "term-ioi" header field parameter;
  5. remove the "transit-ioi" header field parameter, if received;
  6. based on operator policy insert in a Relayed-Charge header field the value of the received "transit-ioi" header field parameter in the P-Charging-Vector header field;
  7. based on local policy, the S-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;
  8. if the S-CSCF supports using a token to identify the registration and if a registration exists, insert a "+g.3gpp.registration-token" Feature-Caps header field parameter, as defined in subclause 7.9A.8, set to the same value as included in the "+g.3gpp.registration-token" Contact header field parameter of the third party REGISTER request sent to the AS when the UE registered; and
  9. if an IP address associated with the served user and the AS SIP URI is stored as described in subclause 5.4.0 exists, then the S-CSCF forwards the SIP message to the IP address associated with the served user and the AS SIP URI;
6)
if there was no original dialog identifier present in the topmost Route header field of the incoming request store the value of the "icid-value" header field parameter received in the P-Charging-Vector header field and retain the "icid-value" header field parameter in the P-Charging-Vector header field. Optionally, the S-CSCF may generate a new, globally unique ICID and insert the new value in the "icid-value" header field parameter of the P-Charging-Vector header field when forwarding the message. If the S-CSCF creates a new ICID, then it is responsible for maintaining the two ICID values in the subsequent messaging. Based on local policy, the S-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 if not already available;
7)
in step 5, if the initial request did not match any unexecuted initial filter criteria (i.e. the request is not forwarded to an AS):
  1. remove the received "transit-ioi" from the P-Charging-Vector header field, if present;
  2. insert a type 2 "orig-ioi" header field parameter into the P-Charging-Vector header field. The S-CSCF shall set the type 2 "orig-ioi" header field parameter to a value that identifies the sending network. The S-CSCF shall not include the type 2 "term-ioi" header field parameter; and
  3. remove the Relayed-Charge header field, if present;
8)
insert a P-Charging-Function-Addresses header field populated with values received from the HSS if the request does not contain a P-Charging-Function-Addresses header field and the message is forwarded within the S-CSCF home network, including towards AS;
9)
if there was no original dialog identifier present in the topmost Route header field of the incoming request and if the served user is not considered a privileged sender then:
  1. if the P-Asserted-Identity header field contains only a SIP URI and if the S-CSCF has knowledge that the SIP URI contained in the received P-Asserted-Identity header field is an alias SIP URI for a tel URI, add a second P-Asserted-Identity header field containing this tel-URI, including the display name associated with the tel URI, if available; and
  2. if the P-Asserted-Identity header field contains only a tel URI, the S-CSCF shall add a second P-Asserted-Identity header field containing a SIP URI. The added SIP URI shall contain in the user part a "+" followed by the international public telecommunication number contained in tel URI, and user's home network domain name in the hostport part. The added SIP URI shall contain the same value in the display name as contained in the tel URI. The S-CSCF shall also add a "user" SIP URI parameter equals "phone" to the SIP URI;
10)
if the request is not forwarded to an AS and if the outgoing Request-URI is:
  • a SIP URI with the user part starting with a + and the "user" SIP URI parameter equals "phone", and if configured per local operator policy, the S-CSCF shall perform the procedure described here. Local policy can dictate whether this procedure is performed for all domains of the SIP URI, only if the domain belongs to the home network, or not at all. If local policy indicates that the procedure is to be performed, then the S-CSCF shall translate the international public telecommunications number contained in the user part of the SIP URI (see RFC 3966) to a globally routeable SIP URI using either an ENUM/DNS translation mechanism with the format specified in RFC 6116, or any other available database. Database aspects of ENUM are outside the scope of the present document. An S-CSCF that implements the additional routeing functionality described in annex I may forward the request without attempting translation. If an agreement exists between the home network and the visited network to support roaming architecture for voice over IMS with local breakout, the S-CSCF does not enable NP capabilities, and the S-CSCF decides to loopback the call to the visited network, the S-CSCF may forward the request without attempting translation. If a translation is in fact performed and it succeeds, the S-CSCF shall update the Request-URI with the globally routeable SIP URI either returned by ENUM/DNS or obtained from any other available database. If this translation fails, the request may be forwarded to a BGCF or any other appropriate entity (e.g. a MRFC to play an announcement) in the originator's home network or the S-CSCF may send an appropriate SIP response to the originator. When forwarding the request to a BGCF or any other appropriate entity, the S-CSCF shall leave the original Request-URI containing the SIP URI with "user" SIP URI parameter equals phone unmodified. If the request is forwarded, the S-CSCF shall remove the access-network-charging-info parameter from the P-Charging-Vector header field prior to forwarding the message;
  • a SIP URI with a "user" SIP URI parameter equals "dialstring" and the domain name of the SIP URI belongs to the home network (i.e. the local number analysis and handling is either failed in the appropriate AS or the request has not been forwarded to AS for local number analysis and handling at all), either forward the request to any appropriate entity (e.g a MRFC to play an announcement) in the originator's home network or send an appropriate SIP response to the originator;
  • a SIP URI with a local number (see RFC 3966) in the user part and a "user" SIP URI parameter equals "phone" and the domain name of the SIP URI belongs to the home network (i.e. the local number analysis and handling is either failed in the appropriate AS or the request has not been forwarded to AS for local number analysis and handling at all), either forward the request to to a BGCFor any appropriate entity (e.g a MRFC to play an announcement) in the originator's home network or send an appropriate SIP response to the originator;
  • a tel URI containing a global number (see RFC 3966) in the international format, the S-CSCF shall translate the E.164 address to a globally routeable SIP URI using either an ENUM/DNS translation mechanism with the format specified in RFC 6116, or any other available database. Database aspects of ENUM are outside the scope of the present document. An S-CSCF that implements the additional routeing functionality described in annex I may forward the request without attempting translation. If an agreement exists between the home network and the visited network to support roaming architecture for voice over IMS with local breakout, the S-CSCF does not enable NP capabilities, and the S-CSCF decides to loopback the call to the visited network, the S-CSCF may forward the request without attempting translation. If this translation is in fact performed and it succeeds, the S-CSCF shall update the Request-URI with the globally routeable SIP URI returned by ENUM/DNS or any other available database. If this translation fails, the request may be forwarded to a BGCF or any other appropriate entity (e.g a MRFC to play an announcement) in the originator's home network or the S-CSCF may send an appropriate SIP response to the originator. When forwarding the request to a BGCF or any other appropriate entity, the S-CSCF shall leave the original Request-URI containing the tel URI unmodified. If the request is forwarded, the S-CSCF shall remove the access-network-charging-info parameter from the P-Charging-Vector header field prior to forwarding the message;
  • a tel URI containing a local number (see RFC 3966) (i.e. the local number analysis and handling is either failed in the appropriate AS or the request has not been forwarded to AS for local number analysis and handling at all), either forward the request to a BGCF or any other appropriate entity (e.g. a MRFC to play an announcement) in the originator's home network or send an appropriate SIP response to the originator;
  • a pres URI or an im URI, the S-CSCF shall forward the request as specified in RFC 3861. In this case, the S-CSCF shall not modify the received Request-URI: and
  • a service URN, e.g. a service URN with a top-level service type of "sos" as specified in RFC 5031. In this case the S-CSCF shall not modify the received Request-URI.
Additional procedures apply if the S-CSCF supports NP capabilities and these capabilities are enabled by local policy, and the database used for translation from an international public telecommunications number to a SIP URI also provides NP data (for example, based on the PSTN Enumservice as defined by RFC 4769 or other appropriate data bases). If the above translation from an international public telecommunications number to a SIP URI failed, but NP data was obtained from the database and there is no "npdi" parameter in the received request, then the S-CSCF shall, based on operator policy, replace the URI in the Request-URI with the obtained NP data, prior to forwarding the request to the BGCF or other appropriate entity. If the received request already contains a tel-URI "npdi" parameter, then the S-CSCF may update the URI with the obtained NP data. The URI is updated by the S-CSCF by adding NP parameters defined by RFC 4694. If the Request-URI is a tel-URI, then an "npdi" tel-URI parameter is added to indicate that NP data retrieval has been performed, and if the number is ported, an "rn" tel-URI parameter is added to identify the ported-to routeing number. If the Request-URI is in the form of a SIP URI user=phone, the "npdi" and "rn" tel-URI parameters are added as described above to the userinfo part of the SIP URI;
10A)
if the request is not forwarded to an AS and if local policy requires the application of additional routeing capabilities, as defined in annex I, the S-CSCF shall apply the additional routeing capabilities if they are locally available or forward the request to an entity that implements the additional routeing capabilities;
10B)
if an agreement exists between the home network and the visited network to support Roaming Architecture for Voice over IMS with Local Breakout then continue with the following steps. Otherwise continue with step 11. If:
  • the top most Route header contains an indication that this is the UE-originating case;
  • the UE is roaming (as identified by the P-Visited-Network-ID header field value in the original REGISTER request); and
  • the request is an INVITE request;
determine if loopback routeing is applicable for this request using local policy, and save this decision for subsequent processing along with the following information:
  1. any URI representing the TRF address preference received from the visited network; and
  2. the ICID received in the request.
In addition, the S-CSCF shall also include in the request a Feature-Caps header field with the "+g.3gpp.home-visited" header field parameter according to RFC 6809 with the "+g.3gpp.home-visited" header field parameter set to the identifier of the visited network received in the P-Visited-Network-ID header field in the original registration request;
10C)
if the request is an INVITE request, then determine whether loopback is applied for this request. The information saved in step 10B, and the presence or absence of the Feature-Caps header field with the "+g.3gpp.home-visited" header field parameter in the received INVITE request are taken into account in making this decision:
  1. if loopback routeing is not to be performed for this request remove any "+g.3gpp.trf" header field parameter or "+g.3gpp.home-visited" header field parameter from the Feature-Caps header field of the outgoing request;
  2. if loopback routeing is applied for this request;
    1. remove all entries in the Route header field;
    2. if a "+g.3gpp.trf" header field parameter with a parameter value containing a valid URI, is included in the Feature-Caps header field of the request, insert the URI in a Route header field;
    3. if a "+g.3gpp.trf" header field parameter, with a parameter value containing a valid URI is not included in the Feature-Caps header field of the request, insert a locally configured TRF address, associated with the visited network for this call, in the Route header field;
    4. remove any "+g.3gpp.home-visited" header field parameter from the Feature-Caps header field of the outgoing request;
    5. insert the "+g.3gpp.loopback" header field parameter as specified in subclause 7.9A.4 in the Feature-Caps header field of the request, in accordance with the RFC 6809. If providing the identifier of the home network is supported by the S-CSCF and the visited network, the S CSCF may based on operator agreement insert the "+g.3gpp.loopback" header field parameter set to the identifier of the home network;
    6. if included in the incoming request, remove the "+g.3gpp.trf" header field parameter from the Feature-Caps header field from the outgoing request;
    7. remove a type 2 "orig-ioi" header field parameter that was added in step 7 from the P-Charging-Vector header field and insert a type 1 "orig-ioi" header field parameter into the P-Charging-Vector header field. The S-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the network in which the S-CSCF resides. The S-CSCF shall not include the "term-ioi" header field parameter; and
    8. if the S-CSCF supports indicating the traffic leg associated with a URI as specified in RFC 7549 and if an "iotl" SIP URI parameter is not included in the TRF URI in the Route header field and if required by local policy, append an "iotl" URI parameter with a value set to "homeA-visitedA" to the URI in the Route header field; and
  3. if the final decision on loopback routeing is deferred to a subsequent entity in the home network, the BGCF, then the S-CSCF includes, if absent, in the request a Feature-Caps header field with the "+g.3gpp.home-visited" header field parameter, with the parameter value set to the identifier of the visited network received in the P-Visited-Network-ID header field in the original registration request. The S-CSCF is expected to know by means of network configuration that such a subsequent entity exists; and
11)
determine the destination address (e.g. DNS access) using the URI placed in the topmost Route header field if present, otherwise based on the Request-URI. If the destination requires interconnect functionalities (e.g. the destination address is of an IP address type other than the IP address type used in the IM CN subsystem), the S-CSCF shall forward the request to the destination address via an IBCF in the same network;
12)
if network hiding is needed due to local policy, put the address of the IBCF to the topmost Route header field;
13)
in case of an initial request for a dialog:
  1. determine the need for GRUU processing. GRUU processing is required if:
    • an original dialog identifier that the S-CSCF previously placed in a Route header field is not present in the topmost Route header field of the incoming request (this means the request is not returning after having been sent to an AS), and
    • the contact address contains a GRUU that was either assigned by the S-CSCF that is valid as specified in subclause 5.4.7A.4 or a temporary GRUU self assigned by the UE based on the "temp-gruu-cookie" header parameter provided to the UE;
  2. if GRUU processing is not required and the initial request originated from a served user, then determine the need to record-route for other reasons:
    • if the request is routed to an AS which is part of the trust domain, the S-CSCF shall decide, based on operator policy, whether to record-route or not. The decision is configured in the S-CSCF using any information in the received request that may otherwise be used for the initial filter criteria. If the request is record-routed the S-CSCF shall create a Record-Route header field containing its own SIP URI;
    • if the request is a SUBSCRIBE request and routed elsewhere, the S-CSCF shall decide, based on operator policy, whether to record-route or not. The decision is configured in the S-CSCF using any information in the received request (e.g. event package name). If the request is record-routed the S-CSCF shall create a Record-Route header field containing its own SIP URI; or
    • if the request not a SUBSCRIBE request and is routed elsewhere, create a Record-Route header field containing its own SIP URI;
  3. if GRUU processing is required, the S-CSCF shall create a Record-Route header field containing its own SIP URI;
  4. if GRUU processing is required, the S-CSCF shall save an indication that GRUU-routeing is to be performed for in-dialog requests that reach the S-CSCF because of the Record-route header field added in step c);
14)
based on the destination user (Request-URI), remove any P-Access-Network-Info header field and the access-network-charging-info parameter in the P-Charging-Vector header field prior to forwarding the message;
14A)
if the request is not routed to an AS, to a BGCF or to an entity that implements the additional routeing functionality, remove the P-Served-User header field prior to forwarding the request;
14B)
if the S-CSCF supports indicating the traffic leg as specified in RFC 7549, the request is not routed to an AS, to a BGCF or to an entity that implements the additional routeing functionality, loopback routeing is not to be performed for this request, required by local policy and the Request-URI contains a SIP URI, append the "iotl" SIP URI parameter set to "homeA-homeB" to the Request-URI;
15)
route the request based on SIP routeing procedures;
16)
if the request is an INVITE request, save the Contact, CSeq and Record-Route header field values received in the request such that the S-CSCF is able to release the session if needed;
17)
if the request contains a "logme"parameter in the Session-ID header field, treat this dialog as one for which logging is in progress and log SIP signalling for this dialog according to its trace configuration;
18)
if the S-CSCF supports using a token to identify the registration and if the request is not forwarded to an AS, remove the "+g.3gpp.registration-token" Feature-Caps header field parameter, defined in subclause 7.9A.8, if received in the request; and
19)
if the received request is an INVITE request or a MESSAGE request and the S-CSCF supports calling number verification using signature verification and attestation information as specified in subclause 3.1, the S-CSCF shall based on local policy 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 Origination-Id header field, specified in subclause 7.2.19, set to a UUID identifying the S-CSCF which is configured based on local policy and requirements from national regulation: and
  • an Attestation-Info header field, specified in subclause 7.2.18, set to the value "A".
When the S-CSCF receives, an initial request for a dialog or a request for a standalone transaction, from an AS acting on behalf of an unregistered user, the S-CSCF shall:
1)
execute the procedures described in the steps 1, 2, 3, 4, 4B, 4C, 4D, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 and 16 in the above paragraph (when the S-CSCF receives, from a registered served user, an initial request for a dialog or a request for a standalone transaction).
When the S-CSCF receives a request initiated by the served user for which the S-CSCF does not have the user profile or does not trust the data that it has (e.g. due to restart), the S-CSCF shall attempt to retrieve the user profile from the HSS. If the S-CSCF receives a Diameter result code of DIAMETER_UNABLE_TO_COMPLY as defined in TS 29.228, the S-CSCF supports S-CSCF restoration procedures, and the Request-URI of the request does not match an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031, then the S-CSCF shall:
  1. reject the request by returning a 504 (Server Time-out) response to the UE;
  2. 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. 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 S-CSCF included in the Service-Route header field (see subclause 5.4.1.2.2F) during the registration of the user whose UE sent the request causing this response; and
    • a 3GPP IM CN subsystem XML body:
      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).
Depending on operator configuration (see subclause 5.4.1.8), when the S-CSCF receives a request with a Request-URI that does not match an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031, the request initiated by the served user for which the S-CSCF has modified but not synchronized the service profile for the served user and the S-CSCF supports S-CSCF restoration procedures, then the S-CSCF shall reject the request as described in items I), II) and III).
If the S-CSCF:
  1. fails to receive a SIP response within a configurable time; or
  2. receives a 408 (Request Timeout) response or a 5xx response from the AS without previously receiving a 1xx response to the original SIP request, and without previously receiving a SIP request from the AS that contained the same original dialog identifier as the original request;
the S-CSCF shall:
  • if the default handling defined in the filter criteria indicates the value "SESSION_CONTINUED" as specified in TS 29.228 or no default handling is indicated, execute the procedure from step 5; and
  • if the default handling defined in the filter criteria indicates the value "SESSION_TERMINATED" as specified in TS 29.228, either forward the received response or, if the request is an initial INVITE request, send a 408 (Request Timeout) response or a 5xx response towards the served UE as appropriate (without verifying the matching of filter criteria of lower priority and without proceeding for further steps).
If the S-CSCF receives any final response from the AS, the S-CSCF shall forward the response towards the served UE (without verifying the matching of filter criteria of lower priority and without proceeding for further steps).
When the S-CSCF receives any response to the above request containing a Relayed-Charge header field, and the next hop is not an AS, the S-CSCF shall remove the Relayed-Charge header field from the forwarded response.
When the S-CSCF receives any response to the above request, the S-CSCF may:
1)
apply any privacy required by RFC 3323 and RFC 3325 to the P-Asserted-Identity header field.
When the S-CSCF receives any response to the above request, the S-CSCF shall:
1)
If logging is in progress for this dialog, 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 stop treating this as a dialog for which logging is in progress, else the S-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 response.
When the S-CSCF receives any response to the above request containing a "term-ioi" header field parameter in the P-Charging-Vector header field, the S-CSCF shall:
1)
store the value of the received "term-ioi" header field parameter if present;
2)
remove all received "orig-ioi", "term-ioi" and "transit-ioi" header field parameters from the forwarded response;
3)
include the stored "orig-ioi" header field parameter if received in the request;
4)
include a type 1 "term-ioi" header field parameter if next hop is not an AS, or a type 3 "term-ioi" header field parameter. The "term-ioi" header field parameter is set to a value that identifies the sending network of the response
5)
based on operator policy include any received "transit-ioi" header field parameter, from the P-Charging-Vector header field, in a Relayed-Charge header field, if the next hop is an AS.
When the S-CSCF receives any 1xx or 2xx response to the initial request for a dialog, if the response corresponds to an INVITE request, the S-CSCF shall save the Contact and Record-Route header field values in the response in order to be able to release the session if needed.
When the S-CSCF receives any 1xx or 2xx response to an initial request for a dialog or a request for a standalone transaction, if the response is forwarded within the S-CSCF home network and not to an AS, the S-CSCF shall insert a P-Charging-Function-Addresses header field populated with values received from the HSS.
When the S-CSCF, upon sending an initial INVITE request that includes an IP address in the SDP offer (in "c=" parameter), receives an error response indicating that the IP address type is not supported, (e.g., the S-CSCF receives the 488 (Not Acceptable Here) with 301 Warning header field indicating "incompatible network address format"), the S-CSCF shall either:
  • fork the initial INVITE request to the IBCF; or
  • process the error response and forward it using the Via header field.
When the S-CSCF receives from the served user a target refresh request for a dialog, prior to forwarding the request the S-CSCF shall:
0A)
if the dialog is related to an IMS communication service determine whether the contents of the request (e.g. SDP media capabilities, Content-Type header field) match the IMS communication service as received as the ICSI value in the P-Asserted-Service header field in the initial request. As an operator option, if the contents of the request do not match the IMS communication service the S-CSCF may reject the request by generating a status code reflecting which added contents are not matching. Otherwise, continue with the rest of the steps;
1)
remove its own URI from the topmost Route header field;
2)
create a Record-Route header field containing its own SIP URI;
3)
for INVITE dialogs (i.e. dialogs initiated by an INVITE request), save the Contact and CSeq header field values received in the request such that the S-CSCF is able to release the session if needed;
4)
in case the request is routed towards the destination user (Request-URI) or in case the request is routed to an AS located outside the trust domain, remove the access-network-charging-info parameter in the P-Charging-Vector header field;
5)
route the request based on the topmost Route header field; and
6)
if the request was sent on a dialog for which logging of signalling is in progress, 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 stop logging of signalling, else determine, by checking its trace configuration, whether to log the response.
When the S-CSCF receives any response to the above request, the S-CSCF shall:
1)
If logging is in progress for this dialog, 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 stop logging of signalling, else determine, by checking its trace configuration, whether to log the response.
When the S-CSCF receives any 1xx or 2xx response to the target refresh request for an INVITE dialog, the S-CSCF shall replace the saved Contact header field values in the response such that the S-CSCF is able to release the session if needed.
If the S-CSCF inserted in the initial request for the dialog the header field parameters into the Feature-Caps header field then the S-CSCF shall include the header field parameters with the same parameter values into the Feature-Caps header field in any target refresh request for the dialog, and in each 1xx or 2xx response to target refresh request sent in the same direction.
When the S-CSCF receives from the served user a subsequent request other than a target refresh request for a dialog, prior to forwarding the request the S-CSCF shall:
1)
remove its own URI from the topmost Route header field;
2)
in case the request is routed towards the destination user (Request-URI) or in case the request is routed to an AS located outside the trust domain, remove the access-network-charging-info parameter in the P-Charging-Vector header field; and
3)
route the request based on the topmost Route header field; and
4)
if the request was sent on a dialog for which logging of signalling is in progress, 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, stop logging of signalling, else determine, by checking its trace configuration, whether to log the request.
When the S-CSCF receives any response to the above request, the S-CSCF shall:
1)
If logging is in progress for this dialog, 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 stop logging of signalling, else determine, by checking its trace configuration, whether to log the response.
With the exception of 305 (Use Proxy) responses, the S-CSCF shall not recurse on 3xx responses.
Up

Up   Top   ToC