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.4  Call initiation

5.4.4.1  Initial INVITE

When the S-CSCF receives an INVITE request, either from the served user or destined to the served user, the S-CSCF may require the periodic refreshment of the session to avoid hung states in the S-CSCF. If the S-CSCF requires the session to be refreshed, the S-CSCF shall apply the procedures described in RFC 4028 clause 8.
For interworking with a visiting network, where the P-CSCF of the visiting network does not support priority but it is intended or required to give users of that P-CSCF priority in the home network, the S-CSCF in the home network shall recognize the need for priority treatment if such detection is not alternately provided via an IBCF in the home network.
When an S-CSCF interworks with a visiting network that does not support priority, and the S-CSCF recognizes the need for priority treatment, the S-CSCF shall insert the temporarily authorised Resource-Priority header field with appropriate namespace and priority value in the INVITE request.
When the S-CSCF receives an initial INVITE request destined for the served user, the S-CSCF shall either:
  1. examine the SDP offer (the "c=" parameter) to detect if it contains an IP address type that is not supported by the IM CN subsystem; or
  2. process the initial INVITE request without examining the SDP.
Subsequently, when the S-CSCF detects that the SDP offer contained an IP address type that is not supported by the IM CN subsystem (i.e., either case a) or b)), the S-CSCF shall either:
  • return a 305 (Use Proxy) response to the I-CSCF with the Contact field containing the SIP URI of the IBCF, or
  • forward the initial INVITE request to the IBCF. When forwarding the initial INVITE request, the S-CSCF shall not insert its SIP URI into the Record-Route header field.
If overlap signalling using the multiple-INVITE method is supported as a network option, several INVITE requests with the same Call ID and the same From header field (including "tag" header field parameter) can be received outside of an existing dialog. Such INVITE requests relate to the same call. If the S-CSCF receives an INVITE request from the served user outside an existing dialog with the same Call ID and From header field as a previous INVITE request during a certain period of time, it shall route the new INVITE request to the same next hop as the previous INVITE request.
Up

5.4.4.2  Subsequent requestsWord‑p. 290

5.4.4.2.1  UE-originating case
When the S-CSCF receives the request containing the access-network-charging-info parameter in the P-Charging-Vector, the S-CSCF shall store the access-network-charging-info parameter from the P-Charging-Vector header field. The S-CSCF shall retain access-network-charging-info parameter in the P-Charging-Vector header field when the request is forwarded to an AS. However, the S-CSCF shall not include the access-network-charging-info parameter in the P-Charging-Vector header field when the request is forwarded outside the home network of the S-CSCF.
When the S-CSCF receives any request or response (excluding CANCEL requests and responses) related to a UE-originated dialog or standalone transaction, the S-CSCF shall insert previously saved values into the P-Charging-Vector header field before forwarding the message within the S-CSCF home network, including towards AS.
When the S-CSCF receives any request or response (excluding ACK requests and CANCEL requests and responses) related to a UE-originated dialog or standalone transaction, the S-CSCF may insert previously saved values into the P-Charging-Function-Addresses header field before forwarding the message within the S-CSCF home network, including towards AS.
Up
5.4.4.2.2  UE-terminating case
When the S-CSCF receives 180 (Ringing) or 200 (OK) (to INVITE) responses containing the access-network-charging-info parameter in the P-Charging-Vector, the S-CSCF shall store the access-network-charging-info parameter from the P-Charging-Vector header field. The S-CSCF shall retain the access-network-charging-info parameter in the P-Charging-Vector header field when the response is forwarded to an AS. However, the S-CSCF shall not include the access-network-charging-info parameter in the P-Charging-Vector header field when the response is forwarded outside the home network of the S-CSCF.
When the S-CSCF receives any request or response (excluding CANCEL requests and responses) related to a UE-terminated dialog or standalone transaction, the S-CSCF shall insert previously saved values into the P-Charging-Vector header field before forwarding the message within the S-CSCF home network, including towards AS.
When the S-CSCF receives any request or response (excluding ACK requests and CANCEL requests and responses) related to a UE-terminated dialog or standalone transaction, the S-CSCF may insert previously saved values into the P-Charging-Function-Addresses header field before forwarding the message within the S-CSCF home network, including towards AS.
When the S-CSCF receives an error response (to INVITE) for an existing early dialog, and if the S-CSCF does not forward the response immediately (if the S-CSCF forked the INVITE request it may wait for additional final responses), the S-CSCF does not have knowledge of having received an 199 (Early Dialog Terminated) provisional response on the same early dialog, and the associated INVITE request included the "199" option-tag in the Supported header field, and the INVITE request did not include the "100rel" option tag in the Require header field, the S-CSCF shall trigger and send an unreliable 199 (Early Dialog Terminated) provisional response, using the same "tag" To header field parameter value as the error response, as specified in RFC 6228.
When the S-CSCF has forked an initial INVITE request, and it has received:
  • a 2xx response associated with one of the early dialogs, the S-CSCF shall in each CANCEL request it generates as specified in RFC 3261 insert a Reason header field with a "SIP" protocol header field parameter value, a "200" cause header field parameter value, and a "Call completed elsewhere" text header field parameter value, as specified in RFC 3326; or
  • a 6xx response associated with one of the early dialogs, the S-CSCF shall, in each CANCEL request it generates as specified in RFC 3261 insert a Reason header field with "SIP" protocol header field parameter value, a cause header field parameter value representing the response code (e.g. "603") in the received response, and a text header field parameter with a value associated with the response code (e.g. a "Declined" value in the case of a "603" response code), as specified in RFC 3326.
Up

5.4.5  Call releaseWord‑p. 291

5.4.5.1  S-CSCF-initiated session release

5.4.5.1.1  Cancellation of a session currently being established
Upon receipt of a network internal indication to release a session which is currently being established, the S-CSCF shall:
  1. cancel the related dialogs by sending the CANCEL request according to the procedures described in RFC 3261; and
  2. send an appropriate response to the sender of the original INVITE request.
5.4.5.1.2  Release of an existing session
Upon receipt of a network internal indication to release an existing multimedia session, the S-CSCF shall:
  1. if the S-CSCF serves the calling user of the session, generate a BYE request destined for the called user based on the information saved for the related dialog, including:
    • a Request-URI, set to the stored Contact header field provided by the called user;
    • a To header field, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;
    • a From header field, set to the From header field value as received in the initial INVITE request;
    • a Call-ID header field, set to the Call-Id header field value as received in the initial INVITE request;
    • a CSeq header field, set to the CSeq value that was stored for the direction from the calling to the called user, incremented by one;
    • a Route header field, set to the routeing information towards the called user as stored for the dialog;
    • a Reason header field that contains proper SIP response code;
    • further header fields, based on local policy;
    • treat the BYE request as if received directly from the calling user, i.e. the S-CSCF shall send the BYE request to the internal service control and based on the outcome further on towards the called user; and
  2. if the S-CSCF serves the calling user of the session, generate an additional BYE request destined for the calling user based on the information saved for the related dialog, including:
    • a Request-URI, set to a contact address obtained from the stored Contact header field if provided by the calling user. If the stored Contact header field contained either a public or a temporary GRUU, the S-CSCF shall set the Request-URI either to:
      1. the contact address bound to the respective GRUU, if the stored Contact header field did not include an "ob" SIP URI parameter; or
      2. the contact address that the UE used to send the initial INVITE request, if the stored Contact header field included an "ob" SIP URI parameter;
    • a To header field, set to the From header field value as received in the initial INVITE request;
    • a From header field, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;
    • a Call-ID header field, set to the Call-Id header field value as received in the initial INVITE request;
    • a CSeq header field, set to the CSeq value that was stored for the direction from the called to the calling user, incremented by one - if no CSeq value was stored for that session the S-CSCF shall generate and apply a random number within the valid range for CSeqs;
    • a Route header field, set to the routeing information towards the calling user as stored for the dialog;
    • a Reason header field that contains proper SIP response code;
    • further header fields, based on local policy;
    • send the BYE request directly to the calling user.
  3. if the S-CSCF serves the called user of the session, generate a BYE request destined for the called user based on the information saved for the related dialog, including:
    • a Request-URI, set to a contact address that the S-CSCF uses to send the in-dialog requests towards the called UE as defined in RFC 5626 and RFC 5627;
    • a To header, set to the To header value as received in the 200 (OK) response for the initial INVITE request;
    • a From header, set to the From header value as received in the initial INVITE request;
    • a Call-ID header, set to the Call-Id header value as received in the initial INVITE request;
    • a CSeq header, set to the CSeq value that was stored for the direction from the calling to the called user, incremented by one;
    • a Route header, set to the routeing information towards the called user as stored for the dialog;
    • a Reason header that contains proper SIP response code;
    • further headers, based on local policy;
    • send the BYE request directly to the called user; and
  4. if the S-CSCF serves the called user of the session, generate an additional BYE request destined for the calling user based on the information saved for the related dialog, including:
    • a Request-URI, set to the stored Contact header field provided by the calling user;
    • a To header, set to the From header field value as received in the initial INVITE request;
    • a From header, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;
    • a Call-ID header, set to the Call-Id header field value as received in the initial INVITE request;
    • a CSeq header, set to the CSeq value that was stored for the direction from the called to the calling user, incremented by one - if no CSeq value was stored for that session the BYE shall generate and apply a random number within the valid range for CSeqs;
    • a Route header field, set to the routeing information towards the calling user as stored for the dialog;
    • a Reason header field that contains proper SIP response code;
    • further headers, based on local policy;
    • treat the BYE request as if received directly from the called user, i.e. the S-CSCF shall send the BYE request to the internal service control and based on the outcome further on towards the calling user..
Upon receipt of the 2xx responses for both BYE requests, the S-CSCF shall release all information related to the dialog and the related multimedia session.
Up
5.4.5.1.2A  Release of the existing dialogs due to registration expirationWord‑p. 293
When:
  1. the registration lifetime of the only public user identity currently registered with its associated set of implicitly registered public user identities (i.e. no other is registered) and bound either to the contact address of the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used) expires;
  2. there are still active multimedia sessions that includes either this user's contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used);
  3. the session was initiated by or terminated towards the user using the public user identity currently registered or with one of the implicitly registered public used identities bound either to the contact addressof the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used);
then the S-CSCF shall:
  • release each of these multimedia sessions by applying the steps listed in the subclause 5.4.5.1.2. The S-CSCF shall only release dialogs associated with the multi media sessions originated or terminated towards the registered user's contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used).
Up
5.4.5.1.3  Abnormal cases
Upon receipt of a request on a dialog for which the S-CSCF initiated session release, the S-CSCF shall terminate the received request and answer it with a 481 (Call/Transaction Does Not Exist) response.

5.4.5.2  Session release initiated by any other entityWord‑p. 294

Upon receipt of a 2xx response for a BYE request matching an existing dialog, the S-CSCF shall delete all the stored information related to the dialog.

5.4.5.3  Session expiration |R6|

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

5.4.6  Call-related requests

5.4.6.1  ReINVITE

5.4.6.1.1  Determination of served user
Void.
5.4.6.1.2  UE-originating case
For a reINVITE request or UPDATE request from the UE within the same dialog, the S-CSCF shall store the updated access-network-charging-info parameter from P-Charging-Vector header field in the received SIP request. The S-CSCF shall retain the access-network-charging-info parameter in the P-Charging-Vector header field when the request is forwarded to an AS. However, the S-CSCF shall not include the access-network-charging-info parameter in the P-Charging-Vector header field when the request is forwarded outside the home network of the S-CSCF.
For a reINVITE request from the UE, if the request is to be 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.
Up
5.4.6.1.3  UE-terminating case
For a reINVITE request or UPDATE request destined towards the UE within the same dialog, when the S-CSCF receives the 200 (OK) response (to the INVITE request or UPDATE request), the S-CSCF shall store the updated access-network-charging-info parameter from the P-Charging-Vector header field. The S-CSCF shall retain the access-network-charging-info parameter in the P-Charging-Vector header field when the response is forwarded to the AS. However, the S-CSCF shall not include the access-network-charging-info parameter in the P-Charging-Vector header field when the 200 (OK) response is forwarded outside the home network of the S-CSCF.
For any SIP response to an INVITE request, if the response is to be 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.
Up

5.4.7Void

5.4.7A  GRUU management |R7|

5.4.7A.1  Overview of GRUU operation

The S-CSCF provides a service of assigning and translating GRUUs for use by registered UEs, unless "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in TS 29.228 has been provisioned in the service profile of the registered public user identity. This is conducted as specified in RFC 5627 and RFC 5628. Two kinds of GRUUs are assigned: public GRUUs and temporary GRUUs.
Each assigned GRUU represents an association between a public user identity and an instance ID provided by a registering UE. It is used to address a particular UE that possesses the instance ID and registers with the public user identity. The GRUU also denotes a contact address registered with a public user identity when the contact address has a "+sip.instance" header field parameter containing the GRUU instance ID.
The S-CSCF issues GRUUs as part of the registration process, and also reports GRUUs as part of notifications for subscriptions to the "reg" event package. The S-CSCF always issues GRUUs in pairs - a public GRUU and a temporary GRUU. In case of implicit registration the S-CSCF assigns a unique public GRUU and a unique temporary GRUU for each public user identity.
The S-CSCF may also support the procedures for allocating public GRUUs and supporting the generation of temporary GRUUs by the functionality within the UE that performs the role of registrar as specified in RFC 6140 as well as the procedures to route requests containing such GRUUs.
Up

5.4.7A.2  Representation of public GRUUsWord‑p. 295

Each public GRUU shall conform to all requirements specified in RFC 5627.
If the Contact URI in the Contact header field does not contain a "bnc" URI parameter, then the S-CSCF constructs a public GRUU by adding a "gr" SIP URI parameter to the canonical for m of the SIP URI which contains a public user identity.
If the Contact URI in the Contact header field contains a "bnc" URI parameter and if the S-CSCF supports RFC 6140, then the S-CSCF constructs a public GRUU by adding both "bnc" and "gr" SIP URI parameters to the canonical form of the SIP URI from the To header field of the REGISTER request
The "gr" SIP URI parameter serves as an indicator that the URI is in fact a GRUU and if the "+sip.instance" header field parameter from the Contact address contains an IMEI URN or a MEID URN then it carries a value that encodes the IMEI based instance ID that is defined in TS 23.003 or the MEID based instance ID which is defined in RFC 8464 otherwise it carries the value received in the "+sip.instance" header field parameter.
By default, the value of the "gr" SIP URI parameter is a copy of the value of the "+sip.instance" header field parameter from a Contact address registered with the S-CSCF, with escaping of special characters as specified in RFC 3261.
The public GRUU that is returned in the "pub-gruu" parameter in the 200 (OK) response to the REGISTER request is constructed using the canonical form of the SIP URI of the public user identity from the To header field of the REGISTER request provided that public user identity is not barred. If the public user identity from the To header field of the REGISTER request is barred then the public GRUU that is returned in the "pub-gruu" parameter in the 200 (OK) response to the REGISTER request is constructed using the canonical form of the SIP URI of the default public user identity.
If the "+sip.instance" header field parameter from the Contact address contains an IMEI URN, as specified in RFC 7254 or an MEID URN, as specified in RFC 8464, then the value of the "gr" SIP URI parameter is generated by the S-CSCF using the name-based UUID algorithm defined in RFC 4122. The following applies to the algorithm:
  1. the "name space ID" shall be a UUID generated for use across the administrative domain and shall use the algorithm for creating a UUID from truly random numbers specified in RFC 4122;
  2. SHA-1 shall be used as the hash algorithm; and
  3. the "name" is made up of a concatenation of the ASCII representation (see RFC 20) of:
    1. if IMEI, the TAC and SNR portions of the IMEI; or
    2. if MEID, the Manufacturer Code and the Serial Number portions of the MEID;
    from the "+sip.instance" header field parameter.
Only the IMEI shall be use for generating an instance ID for a multi-mode UE that supports both 3GPP and 3GPP2 defined radio access networks, and the S-CSCF shall follow the procedures for an IMEI as described above.
The S-CSCF shall store the "gr" parameter used in a public GRUU and the associated value received in a "+sip.instance" header field parameter.
The public GRUU for a particular association of public user identity and instance ID is persistent. The same public GRUU will be returned each time a registration is performed with a particular pair of public user identity and instance ID.
Up

5.4.7A.3  Representation of temporary GRUUsWord‑p. 296

Each temporary GRUU shall conform to all requirements specified in RFC 5627.
Because of the limited lifetime of an temporary GRUU, only the S-CSCF that created a temporary GRUU is required to understand how to translate that GRUU to the corresponsing public user identity and instance ID.
The temporary GRUU that is returned in the "temp-gruu" parameter in the 200 (OK) response to the REGISTER request is mapped to the public user identity from the To header field of the REGISTER request provided that public user identity is not barred. If the public user identity from the To header field of the REGISTER request is barred then the temporary GRUU that is returned in the "temp-gruu" parameter in the 200 (OK) response to the REGISTER request is mapped to the default public user identity.
The specific representation of a temporary GRUU may be decided by each S-CSCF implementation. Temporary GRUUs must route to the assigning S-CSCF without requiring each assigned GRUU to be stored in the HSS.
The S-CSCF may choose a representation of temporary GRUUs that requires no extra state to be retained, such as that specified in RFC 5627. Alternatively, the S-CSCF may choose a stateful representation. This is an implementation choice.
Up

5.4.7A.4  GRUU recognition and validity

The S-CSCF shall recognize those GRUUs it has assigned, verify their validity, and extract the associated public user identity or stored identity of the UE that represents the functionality within the UE that performs the role of registrar and instance ID. This is true for both public GRUUs and temporary GRUUs.
GRUUs are distinguished from other URIs by the presence of a "gr" SIP URI parameter. Public GRUUs are distinguished from temporary GRUUs by the presence of a value for the "gr" SIP URI parameter.
The instance ID is obtained from a public GRUU by using the "gr" parameter to retrieve the stored associated instance ID. The public user identity or stored identity of the UE that represents the functionality within the UE that performs the role of registrar is extracted from a public GRUU by removing the "gr" SIP URI parameter.
The S-CSCF can recognize a public GRUU as valid if the "gr" parameter contains a value that was stored in the S-CSCF during generation of the public GRUU, and the derived public user identity compares equal, according to the comparison rules of RFC 3261, to a public user identity active within the S-CSCF or a stored identity of the UE that represents the functionality within the UE that performs the role of registrar from which a public GRUU was created. When validating public GRUUs the S-CSCF shall ignore the presence of any "sg" SIP URI parameter when determining if a public GRUU is one allocated by the S-CSCF.
The public user identity and instance ID are derived from a temporary GRUU via implementation specific means consistent with the way temporary GRUUs are constructed. The S-CSCF shall determine the validity of a temporary GRUU in conformance with RFC 5627, and if the GRUU was allocated using RFC 6140 procedures then in conformance with RFC 6140 or using implementation specific means.
The S-CSCF regards a UE self-allocated public GRUU as valid if "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in TS 29.228 is provisioned in the service profile of the served public user identity.
Up

5.4.8  Emergency service |R7|Word‑p. 297

5.4.8.1  General

The S-CSCF shall handle the emergency registration as per the needs of the normal registration.

5.4.8.2  Initial emergency registration or user-initiated emergency reregistration

When the S-CSCF receives a REGISTER request; and the Contact header field includes a "sos" SIP URI parameter that indicates that this is an emergency registration, the S-CSCF shall perform the actions as specified in subclause 5.4.1.1 with the following additions:
  1. when handling unprotected REGISTER request or protected REGISTER request, the S-CSCF:
    1. shall deregister only contacts that were registered as part of emergency registration; and
    2. shall not deregister contacts that were registered as part of non-emergency registration;
  2. for the protected REGISTER request, when the S-CSCF receives a REGISTER request with the "integrity-protected" header field parameter in the Authorization header field set to "yes", "tls-yes" or "ip-assoc-yes", i.e. for the protected REGISTER request, and the Contact header field includes a "sos" SIP URI parameter that indicates that this is an emergency registration, the S-CSCF shall identify the user by the public user identity as received in the To header field and the private user identity as received in the Authorization header field of the REGISTER request;
  3. if operator policy does not require that emergency service requests are forwarded to the S-CSCF, the S-CSCF shall not include a Service-Route header field in the 200 (OK) response to the REGISTER request;
  4. the S-CSCF shall not include a temporary GRUU in the 200 (OK) response to the REGISTER request;
  5. the S-CSCF shall in the Contact header field of the 200 (OK) response to the REGISTER request include only the URI that was successfully emergency registered and in this URI include the "sos" SIP URI parameter;
  6. store the Path header field and the contact information including all header field parameters contained in the Contact header field;
  7. the S-CSCF shall not send any third-party REGISTER requests to any AS;
  8. void
  9. determine the duration of the registration by checking the value of the registration expiration interval value in the received REGISTER request and based on local policy; and
  10. for any bindings created by the emergency registration, mark those bindings as created by an emergency registration.
Up

5.4.8.3  User-initiated emergency deregistrationWord‑p. 298

When S-CSCF receives a REGISTER request with the registration expiration interval value containing zero and the Contact header field contains a contact address that has been registered for emergency service (i.e. the "sos" SIP URI parameter that indicates that this is an emergency registration is included in the Contact header field), the S-CSCF shall reject the REGISTER request by sending a 501 (Not Implemented) response.

5.4.8.4  Network-initiated emergency deregistration

The S-CSCF shall not perform a network-initiated emergency deregistration.

5.4.8.5  Network-initiated emergency reauthentication

If a given public user identity and the associated contact address have been registered via emergency registration, the S-CSCF shall not reauthenticate this public user identity.

5.4.8.6  Subscription to the event providing registration state

If a S-CSCF receives a SUBSCRIBE request addressed to S-CSCF containing the Event header field with the reg event package with the Contact header field that contains a contact address that has been registered for emergency service, the S-CSCF shall reject the SUBSCRIBE request for the reg-event package by sending a 489 (Bad Event) response.

5.4.8.7  Notification of the registration stateWord‑p. 299

When the user performs an emergency registration or when the emergency registration expires, the S-CSCF shall not send a NOTIFY request to the subscribers to the reg event package of the respective user.
The contact address that has been registered for emergency service shall not be included in the NOTIFY requests sent to the subscribers to the reg event package of the user.

Up   Top   ToC