Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  17.1.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…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…

 

5.4.3.3  Requests terminated at the served userWord‑p. 275

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 for 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, destined for a registered served user, 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 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:
1)
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 present, the request has been sent from an AS in response to a previously sent request.
  • If not present, it indicates that the request is visiting the S-CSCF for the first time and in this case the S-CSCF shall determine the served user by taking the identity contained in the Request-URI. If the Request-URI is a temporary GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.3, then take the public user identity that is associated with the temporary GRUU to be the served user identity. Then check whether the determined served user identity is a barred public user identity. In case the served user identity is a barred public user identity for the user, then the S-CSCF shall reject the request by generating a 404 (Not Found) response. Otherwise, the S-CSCF shall save the Request-URI from the request, the served user identity and the public user identity of the served user and continue with the rest of the steps;
2)
remove its own URI from the topmost Route header field;
2A)
if there was no original dialog identifier present in the topmost Route header field of the incoming request build an ordered list of initial filter criteria based on the public user identity in the Request-URI of the received request as described in TS 23.218.
3)
if there was an original dialog identifier present in the topmost Route header field of the incoming request then check whether the Request-URI matches the saved Request-URI. The Request-URI and saved Request-URI are considered a match:
  1. if the canonical forms of the two Request-URI are equal to the saved value of the Request-URI;
  2. if the Request-URI is a GRUU (public or temporary) and the saved value of the Request-URI is a GRUU (public or temporary) and both GRUUs represent the same public user identity or represent public user identities that are alias SIP URIs of each other; or
  3. if the Request-URI is an alias SIP URI of the saved value of the Request-URI.
If there is no match, then the S-CSCF shall decide whether to trigger the originating services to be executed after retargeting. The decision is configured in the S-CSCF and may use any information in the received request that is used for the initial filter criteria or an operator policy. The S-CSCF shall decide either to:
  1. stop evaluating current iFC. In that case, 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, forward the request based on the topmost Route header field or if not available forward the request based on the Request-URI (routeing based on Request-URI is specified in steps 2, 7 and 10 through 14a from subclause 5.4.3.2) and skip the following steps; or
  2. stop evaluating current iFC and build an ordered list of iFC with the originating services to be executed after retargeting as described in TS 23.218 criteria based on the public user identity of the served user and start the evaluation of that iFC as described in subclause 5.4.3.2 starting at step 4B of subclause 5.4.3.2;
3A)
if the Request-URI 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;
3B)
if the Request-URI contains a public GRUU and the saved value of the Request-URI is a temporary GRUU, then replace the Request-URI with the saved value of the Request-URI;
3C)
if the request contains a P-Asserted-Service header field check whether the IMS communication service identified by the ICSI value contained in the P-Asserted-Service header field is allowed by the subscribed services for the served user:
  1. if so, continue from step 4; and
  2. if not, as an operator option, the S-CSCF may reject the request by generating a 403 (Forbidden) response. Otherwise, remove the P-Asserted-Service header field and continue with the rest of the steps;
3D)
if the request does not contain a P-Asserted-Service header field check if the contents of the request matches a subscribed service (e.g. SDP media capabilities, Content-Type header field) 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. Otherwise, continue with the rest of the steps; and
    b) 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 include a P-Asserted-Service header field in the request containing the ICSI value for the related IMS communication service, and use it as a header field in the initial request when matching initial filter criteria in step 4; and
  2. 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
  3. 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 inclding an ICSI value;
4)
check whether the initial request matches any unexecuted initial filter criteria based on the public user identity of the served user in the priority order and apply the filter criteria on the SIP method as described in TS 23.218 subclause 6.5. If there is a match, then the S-CSCF shall select the first matching unexecuted initial filter criteria and:
  1. if the Request-URI is a temporary GRUU as defined in subclause 5.4.7A.3, then replace the Request-URI with the public GRUU that is associated with the temporary GRUU (i.e. the public GRUU representing the same public user identity and instance ID as the temporary GRUU);
  2. 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;
  3. if the S-CSCF supports the P-Served-User extension as specified in RFC 5502, insert the 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 "Terminating" as specified in TS 29.228, include the sescase header field parameter set to "term" and the regstate header field parameter set to "reg";
    • if the associated session case is "Terminating_Unregistered" as specified in TS 29.228, include the sescase header field parameter set to "term" and the regstate header field parameter set to "unreg";
  4. insert a type 3 "orig-ioi" header field parameter replacing any received "orig-ioi" header field parameter in the P-Charging-Vector header field. The type 3 "orig-ioi" header field parameter identifies the sending network of the request message. The S-CSCF shall not include the type 3 "term-ioi" header field parameter;
  5. 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;
  6. remove the "transit-ioi" header field parameter, if received;
  7. based on operator policy insert a Relayed-Charge header field containing the value of the received "transit-ioi" header field parameter in the P-Charging-Vector header field; and
  8. 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;
5)
if there was no original dialog identifier present in the topmost Route header field of the incoming request insert a P-Charging-Function-Addresses header field, if not present, populated with values received from the HSS if the message is forwarded within the S-CSCF home network, including towards AS;
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;
7)
if there was no original dialog identifier present in the topmost Route header field of the incoming request:
  • store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field, if present;
  • remove received "orig-ioi", "term-ioi" and "transit-ioi" header field parameters from the forwarded request if next hop is not an AS; and
  • include a type 1 "orig-ioi" header field parameter if next hop is not an AS;
7A)
if there was an original dialog identifier present in the topmost Route header field of the incoming request:
  • store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field, if present;
  • remove the received "orig-ioi" header field parameter if next hop is not an AS;
  • include a type 1 "orig-ioi" header field parameter if next hop is not an AS;
  • 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 if not already available; and
  • remove any received Relayed-Charge header field if next hop is not an AS;
8)
in the case:
  1. there are no Route header fields in the request; and
  2. there are bindings saved during registration or re-registration as described in subclause 5.4.1.2 which are not marked as created by an emergency registration as described in subclause 5.4.8.2;
then, create a target set of potential routes from the list of preloaded routes associated with the bindings in item 8) ii), as follows:
  1. if the Request-URI contains a valid GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.4 that does not contain a "bnc" URI parameter, then the target set is determined by following the procedures for Request Targeting specified in RFC 5627, using the public user identity and instance ID derived from the GRUU using the procedures of subclause 5.4.7A;
  2. if the Request-URI contains a valid public GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.4 that contains a "bnc" URI parameter then the target set is determined by following the procedures for routeing of public GRUUs specified in RFC 6140.
  3. if the Request-URI contains a temporary GRUU not assigned by the S-CSCF but that contains "temp-gruu-cookie" information provided by the S-CSCF to the UE in a "temp-gruu-cookie" header field parameter as specified in RFC 6140 then the target set is determined by following the procedures for Request Targeting for temporary GRUUs specified in RFC 6140; or
  4. if the Request-URI contains a public user identity or a GRUU not assigned by the S-CSCF, then the target set is all the registered contacts saved for the destination public user identity;
9)
if necessary perform the caller preferences to callee capabilities matching according to RFC 3841 to the target set;
10)
in case there are no Route header fields in the request:
  1. if there is more than one route in the target set determined in steps 8) and 9) above:
    • if the fork directive in the Request-Disposition header field was set to "no-fork", use the contact with the highest qvalue parameter to build the target URI. In case no qvalue parameters were provided, the S-CSCF shall decide locally what contact address to be used to build the target URI;
    • if the fork directive in the Request-Disposition header field was not set to "no-fork", fork the request or perform sequential search based on the relative preference indicated by the qvalue parameter of the Contact header field in the REGISTER request, as described in RFC 3261. In case no qvalue parameters were provided, then the S-CSCF determine the contact address to be used to build the target URI as directed by the Request-Disposition header field as described in RFC 3841. If the Request-Disposition header field is not present, the S-CSCF shall decide locally whether to fork or perform sequential search among the contact addresses;
    • in case that no route is chosen, return a 480 (Temporarily unavailable) response or another appropriate unsuccessful SIP response and terminate these procedures; and
    • per the rules defined in RFC 5626, the S-SCSF shall not populate the target set with more than one contact with the same public user identity and instance-id at a time. If a request for a particular public user identity and instance-id fails with a 430 response, the S-CSCF shall replace the failed branch with another target with the same public user identity and instance-id, but a different reg-id;
  2. If no "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in TS 29.228 has been received, in the service profile of the served public user identity, from the HSS during registration, build the Request-URI with the contents of the target URI determined in the previous step, otherwise the Request-URI is retained as received;
  3. insert a P-Called-Party-ID SIP header field containing the contents of the Request-URI (if no "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in TS 29.228 has been received, in the service profile of the served public user identity, from the HSS during registration, then exclude "rn" tel-URI parameter and "npdi" tel-URI parameter as defined in RFC 4694) received in the request unless the Request-URI contains a temporary GRUU in which case insert the public GRUU in the P-Called-Party-ID;
  4. build the Route header field with the Path values from the chosen route and if "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in TS 29.228 has been received, in the service profile of the served user identity, from the HSS during registration and the selected contact address was not registered as described in RFC 5626, add the content of the target URI determined in step a), as last URI of the route. If the selected contact address was registered as described in RFC 5626, the target URI determined in step a) is not added to the Route header field; and
  5. save the Request-URI and the total number of Record-Route header fields as part of the dialog request state.
11)
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;
12)
optionally, apply any privacy required by RFC 3323 and RFC 3325 to the P-Asserted-Identity header field and privacy required by RFC 7044. The S-CSCF shall not remove any priv-value from the Privacy header field;
13)
in case of an initial request for a dialog, either:
  • 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; or
  • if the request is routed elsewhere, create a Record-Route header field containing its own SIP URI;
13A)
if the request is routed towards the UE remove the P-User-Database header field and P-Served-User header field if present;
13B)
void
13C)
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 treating the dialog as one for which logging of signalling is in progress, else 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;
13D)
if the request is routed towards the UE,
  • the S-CSCF supports indicating the traffic leg as specified in RFC 7549;
  • the UE is roaming; and
  • required by local policy;
then:
  • 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 an "iotl" SIP URI parameter set to "homeB-visitedB" 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 an "iotl" SIP URI parameter set to "homeB-visitedB" to the URI of the second Route header field from the bottom;
13E)
if the S-CSCF supports HSS based P-CSCF restoration and the S-CSCF considers the P-CSCF, identified by the bottommost Route header field, is not reachable:
  • reject the request with a 480 (Temporarily Unavailable) response; and
  • initiate the HSS based P-CSCF restoration procedure towards the served user as specified in TS 23.380;
13F)
if the S-CSCF supports PCRF based P-CSCF restoration procedures, insert a Restoration-Info header field including the IMSI value contained in the user profile of the registered served user as a quoted string defined in TS 29.228;
13G)
if the S-CSCF supports PCRF based P-CSCF restoration procedures,
  • the request contains a topmost Route header field pointing to a P-CSCF, and
  • the S-CSCF considers the P-CSCF is in a non-working state,
remove all entries in the Route header field and add a Route header field set to the URI associated with an alternative P-CSCF; and
14)
forward the request based on the topmost Route header field.
If the S-CSCF receives any response to the above request, the S-CSCF shall:
  1. If the response contains a "logme" header field parameter in the SIP Session-ID header field then log the response based on local policy.
If the S-CSCF supports HSS based P-CSCF restoration and
  1. receives a 404 (Not Found) response;
  2. fails to receive any SIP response from a P-CSCF serving a non-roaming user within a configurable time; or
  3. receives a 408 (Request Timeout) response or a 504 (Server Time-out) response:
    • including a Restoration-Info header field defined in subclause 7.2.11 set to "noresponse"; and
    • the "+g.3gpp.ics" Contact header field parameter with a value set to "server" was not included in the REGISTER request when the UE registered;
the S-CSCF shall:
  • send a 480 (Temporarily Unavailable) response;
  • initiate the HSS based P-CSCF restoration procedure towards the served user as specified in TS 23.380; and
  • if b) or c) above applied consider the P-CSCF as not reachable.
If the S-CSCF supports PCRF based P-CSCF restoration and receives a 404 (Not Found) response, the S-CSCF shall consider the P-CSCF to be in a non-working state and shall initiate the PCRF based P-CSCF restoration procedure towards the served user as specified in TS 23.380.
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 4; 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 originating 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 originating 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 and forwards it to an AS, the S-CSCF shall remove any "orig-ioi", "term-ioi" and "transit-ioi" header field parameter if received in a P-Charging-Vector header field, insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the request, a type 3 "term-ioi" header field parameter, and based on operator option insert a Relayed-Charge header field in the response. The S-CSCF shall set the type 3 "term-ioi" header field parameter to a value that identifies the sending network of the response, the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter and include in the Relayed-Charge header field the received "transit-ioi" header field parameter from the P-Charging-Vector header field.
When the S-CSCF receives, destined for an unregistered served user or a statically pre-configured PSI, an initial request for a dialog or a request for a standalone transaction, the S-CSCF shall:
  1. Void.
  2. execute the procedures described in 1, 2, 3, 3C, 3D, 4, 5, 6, 7, 11, 13, 13B, 13C and 14 in the above paragraph (when the S-CSCF receives, destined for the registered served user, an initial request for a dialog or a request for a standalone transaction).
  3. In case that no more AS needs to be contacted, then S-CSCF shall return an appropriate unsuccessful SIP response. This response may be a 480 (Temporarily unavailable) and terminate these procedures.
Prior to performing S-CSCF Registration/Deregistration procedure with the HSS, the S-CSCF decides which HSS to query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in TS 29.228 or use the value as received in the P-User-Database header field in the initial request for a dialog or a request for a standalone transaction as defined in RFC 4457. The HSS address received in the response to SLF query can be used to address the HSS of the public user identity with further queries.
If the HSS indicates to the S-CSCF that there is already another S-CSCF assigned for the user, the S-CSCF shall return a 305 (Use Proxy) response containing the SIP URI of the assigned S-CSCF received from the HSS in the Contact header field.
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.
When the S-CSCF receives any 1xx or 2xx response to the initial request for a dialog (whether the user is registered or not), the S-CSCF shall:
  1. if the response corresponds to an INVITE request, save the Contact and Record-Route header field values in the response such that the S-CSCF is able to release the session if needed;
  2. if the response is not forwarded to an AS (i.e. the response is related to a request that was matched to the first executed initial filter criteria):
    1. remove the received "transit-ioi" header field parameter if present and insert a type 2 "term-ioi" header field parameter in the P-Charging-Vector header field of the outgoing response. The type 2 "term-ioi" header field is set to a value that identifies the sending network of the response and the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter. Values of "orig-ioi" and "term-ioi" header field parameters in the received response are removed; and
    2. if the S-CSCF supports using a token to identify the registration, remove the "+g.3gpp.registration-token" Feature-Caps header field parameter, defined in subclause 7.9A.8, if received in the response;
  3. in case the served user is not considered a privileged sender then:
    1. if the P-Asserted-Identity header field contains only a SIP URI and in the case where 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, the S-CSCF shall 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;
  4. in case the response is sent towards the originating user, the S-CSCF may retain the P-Access-Network-Info header field based on local policy rules and the destination user (Request-URI);
  5. save an indication that GRUU routeing is to be performed for subsequent requests sent within this same dialog if:
    1. there is a record-route position saved as part of the initial dialog request state; and
    2. the contact address in the response is a valid GRUU assigned by the S-CSCF as specified in subclause 5.4.7A.4 or a temporary GRUU self assigned by the UE based on the "temp-gruu-cookie" header field parameter provided to the UE;
  6. if the S-CSCF supports using a token to identify the registration and if a registration exists, add 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
  7. if the response is forwarded within the S-CSCF home network and not to an AS, insert a P-Charging-Function-Addresses header field populated with values received from the HSS.
When the S-CSCF receives a response to a request for a standalone transaction (whether the user is registered or not), then:
  1. in case the served user is not considered a privileged sender then:
    1. if the P-Asserted-Identity header field contains only a SIP URI and in the case where 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, the S-CSCF shall 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; and
  2. in case the response is forwarded to an AS that is located within the trust domain, the S-CSCF shall retain the access-network-charging-info parameter in the P-Charging-Vector header field; otherwise, the S-CSCF shall remove the access-network-charging-info parameter in the P-Charging-Vector header field.
When the S-CSCF receives the 200 (OK) response for a standalone transaction request, the S-CSCF shall:
1)
insert a P-Charging-Function-Addresses header field populated with values received from the HSS if the message is forwarded within the S-CSCF home network, including towards an AS;
1A)
if the S-CSCF supports using a token to identify the registration and if a registration exists, add 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;
1B)
if the S-CSCF supports using a token to identify the registration in case the response is not forwarded to an AS the S-CSCF shall remove the "+g.3gpp.registration-token" Feature-Caps header field parameter, defined in subclause 7.9A.8, if received in the response; and
2)
if the response is not forwarded to an AS (i.e. the response is related to a request that was matched to the first executed initial filter criteria), remove the received "orig-ioi", "term-ioi" and "transit-ioi" header field parameter if present and insert a type 2 "term-ioi" header field parameter in the P-Charging-Vector header field of the outgoing response. The type 2 "term-ioi" header field parameter is set to a value that identifies the sending network of the response and the type 2 "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter.
When the S-CSCF receives, destined for a served user, a target refresh request for a dialog, prior to forwarding the request, the S-CSCF shall:
0)
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)
if the incoming request is received on a dialog for which GRUU routeing is to be performed and the Request-URI is not the GRUU for this dialog, then return a response of 400 (Bad Request).
2)
if the incoming request is received on a dialog for which GRUU routeing is to be performed and the Request-URI contains the GRUU for this dialog then:
  1. if the Request-URI contains a valid GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.4 that does not contain a "bnc" URI parameter, then perform the procedures for Request Targeting specified in RFC 5627, using the public user identity and instance ID derived from the Request-URI, as specified in subclause 5.4.7A;
  2. if the Request-URI contains a valid public GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.4 that contains a "bnc" URI parameter then the target set is determined by following the procedures for routeing of public GRUUs specified in RFC 6140. or
  3. if the Request-URI contains a temporary GRUU not assigned by the S-CSCF but that contains "temp-gruu-cookie" information provided by the S-CSCF to the UE in a "temp-gruu-cookie" header field parameter as specified in RFC 6140 then the target set is determined by following the procedures for routeing of temporary GRUUs specified in RFC 6140;
  4. if no contact can be selected, return a response of 480 (Temporarily Unavailable);
3)
remove its own URI from the topmost Route header field;
4)
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;
5)
create a Record-Route header field containing its own SIP URI;
5A)
void
5B)
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 treating the dialog as one for which logging of signalling is in progress, else 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; and
6)
forward the request based on the topmost Route header field.
When the S-CSCF receives any response to the above request, the S-CSCF shall:
1)
If the response contains a "logme" header field parameter in the SIP Session-ID header field then log the response based on local policy.
When the S-CSCF receives any 1xx or 2xx response to the target refresh request for a dialog (whether the user is registered or not), the S-CSCF shall:
1)
for INVITE dialogs, replace the saved Contact header field values in the response such that the S-CSCF is able to release the session if needed; and
2)
in case the response is forwarded to an AS that is located within the trust domain, the S-CSCF shall retain the access-network-charging-info parameter in the P-Charging-Vector header field; otherwise, the S-CSCF shall remove the access-network-charging-info parameter in the P-Charging-Vector header field.
When the S-CSCF receives, destined for the served user, a subsequent request other than target refresh request for a dialog, prior to forwarding the request, the S-CSCF shall:
1)
if the incoming request is received on a dialog for which GRUU routeing is to be performed and the Request-URI is not the GRUU for this dialog, then return a response of 400 (Bad Request).
2)
if the incoming request is received on a dialog for which GRUU routeing is to be performed and the Request-URI contains the GRUU for this dialog then:
  1. if the Request-URI contains a valid GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.4 that does not contain a "bnc" URI parameter, then perform the procedures for Request Targeting specified in RFC 5627, using the public user identity and instance ID derived from the Request-URI, as specified in subclause 5.4.7A;
  2. if the Request-URI contains a valid public GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.4 that contains a "bnc" URI parameter then the target set is determined by following the procedures for routeing of public GRUUs specified in RFC 6140; or
  3. if the Request-URI contains a temporary GRUU not assigned by the S-CSCF but that contains "temp-gruu-cookie" information provided by the S-CSCF to the UE in a "temp-gruu-cookie" header field parameter as specified in RFC 6140 then the target set is determined by following the procedures for routeing of temporary GRUUs specified in RFC 6140.
  4. if no contact can be selected, return a response of 480 (Temporarily Unavailable).
3)
remove its own URI from the topmost Route header field;
3A)
void
3B)
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 treating the dialog as one for which logging of signalling is in progress, else 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; and
4)
forward the request based on the topmost Route header field.
When the S-CSCF receives any response to the above request, the S-CSCF shall:
1)
If the response contains a "logme" header field parameter in the SIP Session-ID header field then log the response based on local policy.
When the S-CSCF receives a response to a a subsequent request other than target refresh request for a dialog, in case the response is forwarded to an AS that is located within the trust domain, the S-CSCF shall retain the access-network-charging-info parameter from the P-Charging-Vector header field; otherwise, the S-CSCF shall remove the access-network-charging-info parameter from the P-Charging-Vector header field.
With the exception of 305 (Use Proxy) responses, the S-CSCF shall not recurse on 3xx responses.
Up

5.4.3.4  Original dialog identifierWord‑p. 287

The original dialog identifier is an implementation specific token that the S-CSCF encodes into the own S-CSCF URI in a Route header field, prior to forwarding the request to an AS. This is possible because the S-CSCF is the only entity that creates and consumes the value.
The token may identify the original dialog of the request, so in case an AS acting as a B2BUA changes the dialog, the S-CSCF is able to identify the original dialog when the request returns to the S-CSCF. In a case of a standalone transaction, the token indicates that the request has been sent to the S-CSCF from an AS in response to a previously sent request. The token can be encoded in different ways, such as e.g., a character string in the user-part of the S-CSCF URI, a parameter in the S CSCF URI or port number in the S-CSCF URI.
The S-CSCF shall ensure that the value chosen is unique so that the S-CSCF may recognize the value when received in a subsequent message of one or more dialogs and make the proper association between related dialogs that pass through an AS.
An original dialog identifier is sent to each AS invoked due to iFC evaluation such that the S-CSCF can associate requests as part of the same sequence that trigger iFC evaluation in priority order (and not rely on SIP dialog information that may change due to B2BUA AS).
Up

5.4.3.5Void

5.4.3.6  SIP digest authentication procedures for all SIP request methods initiated by the UE excluding REGISTER |R8|

5.4.3.6.1  General
When the S-CSCF receives from the UE a request (excluding REGISTER), and SIP digest without TLS or SIP digest with TLS is supported and in use for this UE, the S-CSCF may perform the following steps if authentication of SIP request methods initiated by the UE excluding REGISTER is desired:
1)
The S-CSCF shall identify the user by the public user identity as received in the P-Asserted-Identity header field;
2)
If the public user identity does not match one of the registered public user identities, and the public user identity does not match one of the registered wildcarded public user identities, the S-CSCF may reject the request with a 400 (Bad Request) response or silently discard the request;
3)
If the request does not contain a Proxy-Authorization header field or the Proxy-Authorization header field does not contain a digest response, the S-CSCF shall:
  1. challenge the user by generating a 407 (Proxy Authentication Required) response for the received request, including a Proxy-Authenticate header field as defined in RFC 2617, which includes:
    • a "realm" header field parameter;
    • a "nonce" header field parameter, with a newly generated value by the S-CSCF;
    • an "algorithm" header field parameter; if the algorithm value is not provided in the authentication vector, it shall have the value "MD5"; and
    • a "qop" header field parameter; if the qop value is not provided in the authentication vector, it shall have the value "auth".
    The challenge parameters, with the exception of the "nonce" header field parameter, shall be the same as the ones used for the last successful registration.
  2. send the so generated 407 (Proxy Authentication Required) response towards the UE;
  3. retain the nonce and initialize the corresponding nonce count to a value of 1; and
  4. start timer request-await-auth.
4)
If the request contains a Proxy-Authorization header field, the S-CSCF shall:
  1. check whether the Proxy-Authorization header field contains:
    • the private user identity of the user in the "username" header field parameter;
    • an "algorithm" header field parameter value which matches the "algorithm" header field parameter in the authentication challenge (i.e. "MD5");
    • a "response" header field parameter with the authentication challenge response;
    • a "realm" header field parameter matching the "realm" header field parameter in the authentication challenge;
    • "nonce" header field parameter matching a nonce that is deemed valid by the S-CSCF for the related registration or registration flow (i.e. a nonce that was set in a a Proxy-Authenticate header field of a 407 (Proxy Authentication Required) response to a non-REGISTER request for which the associated validity duration has not expired or in a WWW-Authenticate header field of a 401 (Unauthorized) response to a REGISTER request for which the associated validity duration has not expired, a nonce sent in a "nextnonce" header field parameter sent in a Authentication-Info header field of a 200 OK (OK) to REGISTER request ) or if an authentication is ongoing for this request (i.e. a associated "req-await-auth" is running) matching the nonce that was sent in a Proxy-Authenticate header field of the 407 (Proxy Authentication Required) response to this request;
    • a "uri" header field parameter matching the SIP Request-URI;
    • a "cnonce" header field parameter; and
    • a "nonce-count" header field parameter with a value that equals the nonce-count expected by the S-CSCF. The S-CSCF may choose to accept a nonce-count which is greater than the expected nonce-count. If the S-CSCF uses this nonce-count and authentication is successful and the S-CSCF increments it for any subsequent authentication responses.
    If any of the above checks do not succeed, the S-CSCF shall proceed as described in subclause 5.4.3.6.2, and skip the remainder of this procedure; and
  2. check whether the received authentication challenge response and the expected authentication challenge response match. The S-CSCF shall compute the expected digest response as described in RFC 2617 using the H(A1) value contained within the authentication vector, and other digest parameters (i.e. nonce, cnonce, nonce-count, qop).
In the case where the digest response does not match the expected digest response calculated by the S-CSCF, the S-CSCF shall consider the authentication attempt as failed and do one of the following:
  1. rechallenge the user by issuing a 407 (Proxy Authentication Required) response including a challenge as per procedures described in this subclause; or
  2. reject the request by issuing a 403 (Forbidden) response; or
  3. reject the request without sending a response.
In the case where the digest response matches the expected digest response calculated by the S-CSCF, the S-CSCF shall:
  1. consider the identity of the user verified and the request authenticated and continue with the procedures as described in subclause 5.4.3;
  2. if the used nonce was not considered valid before the authentication succed (i.e a "req-await-auth" was running), add this nonce to the list of the valid nonces for the related registration or registration flow (if multiple registration mechanism is used) for an operator configured duration; and
  3. stop the related "request-await-auth" running if any.
If the timer request-await-auth expires, the S-CSCF shall consider the authentication to have failed.
Up
5.4.3.6.2  Abnormal casesWord‑p. 289
In the case that SIP digest is used and the request from the UE contains an invalid "nonce" Authorization header field parameter with a valid challenge response for that nonce (indicating that the client knows the correct username/password), or when the "nonce-count" Authorization header field parameter value sent by the UE is not the expected value, or when the Proxy-Authorization header field does not include the correct parameters, the S-CSCF shall:
  • send a 407 (Proxy Authentication Required) response to initiate a further authentication attempt with a fresh nonce and the "stale" header field parameter set to "true" in the Proxy-Authenticate header field.
When the S-CSCF cannot forward an initial incoming request to an Application Server due to overload control mechanism, it shall either
  • 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 in subclause 5.4.3.2 or from step 4 in subclause 5.4.3.3 depending on the type of request; and
  • if the default handling defined in the filter criteria indicates the value "SESSION_TERMINATED" as specified in TS 29.228, reject the request as specified in RFC 7339 and RFC 7200 (without verifying the matching of filter criteria of lower priority and without proceeding for further steps).
Up

Up   Top   ToC