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

Content for  TS 24.229  Word version:  18.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.1.3 Authentication and re-authentication  5.4.1.4 User-initiated deregistration  5.4.1.5 Network-initiated deregistration  5.4.1.6 Network-initiated re-authentication  5.4.1.7 Notification of Application Servers about registration status  5.4.1.7A Including contents in the body of the third-party REGISTER request  5.4.1.8 Service profile updates 
...

 

5.4.1.3  Authentication and re-authentication  p. 255

Authentication and re-authentication is performed by the registration procedures as described in subclause 5.4.1.2.

5.4.1.4  User-initiated deregistration  p. 255

5.4.1.4.1  Normal cases |R8|  p. 255
When S-CSCF receives a REGISTER request with the registration expiration interval value containing the value zero, the S-CSCF shall:
1)
verify that the REGISTER request is associated with an existing registered contact or an existing flow or, if the S-CSCF restoration procedures are supported by this S-CSCF, attempt to restore a contact or flow from HSS associated with the REGISTER request. If no associated contact or flow exists then the S-CSCF shall send a 481 (Call Leg/Transaction Does Not Exist) response to the UE and skip the remaining procedures in this subclause;
2)
if IMS AKA is in use as the security mechanism, check whether the "integrity-protected" header field parameter in the Authorization header field set to "yes", indicating that the REGISTER request was received integrity protected. The S-CSCF shall only proceed with the following steps if the "integrity-protected" header field parameter is set to "yes";
3)
if SIP digest without TLS or SIP digest with TLS is in use as a security mechanism, check whether the "integrity-protected" header field parameter in the Authorization header field set to "tls-yes" or "ip-assoc-yes", indicating that the REGISTER request was received from a previously registered user. If the "integrity-protected" header field parameter is set to "tls-pending", "ip-assoc-pending" or is not present the S-CSCF shall ensure authentication is performed as described in subclause 5.4.1.2.1 (and consequently subclause 5.4.1.2.1B or 5.4.1.2.1C) if local policy requires. The S-CSCF shall only proceed with the following steps if the "integrity-protected" header field parameter is set to "tls-yes", "ip-assoc-yes", or the required authentication is successfully performed if required by local policy;
4)
if NASS-IMS bundled authentication is in use as a security mechanism, only proceed with the following steps if the "integrity-protected" header field parameter in the Authorization header field does not exist or without an Authorization header field, and one or more Line-Identifiers previously received over the Cx interface, stored as a result of an Authentication procedure with the HSS, as described in TS 29.228, are available for the user;
4A)
if the security mechanism as described in subclause 5.4.1.2.2E is in use, check whether the "integrity-protected" header field parameter in the Authorization header field set to "auth-done". The S-CSCF shall only proceed with the following steps if the "integrity-protected" header field parameter is set to "auth-done";
5)
release all INVITE dialogs that include this user's contact addresses or the flows that are being deregistered, and where these dialogs were initiated by or terminated towards these contact addresses and the same public user identity found that was To header field that was received REGISTER request or with one of the implicitly registered public user identities by applying the steps listed in subclause 5.4.5.1.2;
6)
examine the Contact header field in the REGISTER request, and:
  1. if the value "*" is not included in the Contact header field and:
    1. if the "reg-id" header field parameter is not included in the Contact header field, then:
      • remove the binding (i.e. deregister) between the public user identity found in the To header field together with the implicitly registered public user identities and the contact addresses specified in the REGISTER request. The S-CSCF shall only remove the contact addresses that were registered by this UE;
    2. if the "reg-id" header field parameter and "+sip.instance" header field parameter are included in the Contact header field, and the UE supports multiple registrations (i.e. the "outbound" option tag is included in the Supported header field), then:
      • remove the binding (i.e. deregister) between the public user identity indicated in the To header field (together with the associated implicitly registered public user identities) and the flow identified by the "reg-id" header field parameter;
7)
if the S-CSCF receives a REGISTER request with the value "*" in the Contact header field and the value zero in the Expires header field, remove all contact addresses that were bound to the public user identity found in the To header field and have been registered by this UE identified with its private user identity;
8)
for all service profiles in the implicit registration set send a third-party REGISTER request, as described in subclause 5.4.1.7, to each AS that matches the Filter Criteria of the service profile from the HSS for the REGISTER event;
9)
if this is a deregistration request for the only public user identity currently registered with its associated set of implicitly registered public user identities (i.e. no other is registered) and there are still active multimedia sessions that includes this user's registered contact address, where the session was initiated by or terminated towards the contact with the registered contact address for that public user identity which is currently registered or with one of the implicitly registered public user identities, release only each of these multimedia sessions associated with the registered contact address by applying the steps listed in subclause 5.4.5.1.2. The S-CSCF shall only release dialogs associated to the multimedia sessions originated or terminated towards the registered user's contact address; and
10)
send a 200 (OK) response to a REGISTER request that contains a list of Contact header fields enumerating all contacts and flows that are currently registered, and all contacts that have been deregistered. For each contact address and the flow that has been deregistered, the Contact header field shall contain the contact address and the "reg-id" header field parameter that identifies the flow, if a flow was deregistered, and the associated information, and the registration expiration interval value shall be set to zero.
If all public user identities of the UE are deregistered, then the S-CSCF may consider the UE and P-CSCF subscriptions to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires header field containing a value of zero).
If the Authorization header field of the REGISTER request contained an "integrity-protected" header field parameter set to the value "no", the S-CSCF shall apply the procedures described in subclause 5.4.1.2.1.
On completion of the above procedures in this subclause and of the S-CSCF Registration/deregistration notification procedure with the HSS, as described in TS 29.228, for one or more public user identities, the S-CSCF shall:
  1. update or remove those public user identities, their registration state and the associated service profiles from the local data; and
  2. if all the contacts bound to the public user identities have been deregistered and there is no ongoing session due to the public user identities, then remove all the stored AS IP addresses which are associated with those public user identities.
Based on operators' policy the S-CSCF can request the HSS to either be kept or cleared as the S-CSCF allocated to this subscriber. If emergency contacts are still registered for this subscriber, the S-CSCF requests the HSS to be kept as the S-CSCF allocated to this subscriber.
Up
5.4.1.4.2  Abnormal cases - IMS AKA as security mechanism |R8|  p. 256
If case that the S-CSCF receives a REGISTER request with the "integrity-protected" header field parameter in the Authorization header set to "yes" or to "tls-connected", for which the public user identity received in the To header and the private user identity received in the Authorization header of the REGISTER request do not match to any registered user at this S-CSCF, if the S-CSCF supports S-CSCF restoration procedures as specified in TS 23.380, the S-CSCF shall behave as described in subclause 5.4.1.4.1, otherwise the S-CSCF shall:
  • respond with a 500 (Server Internal Error) response to the UE.
Up
5.4.1.4.4  Abnormal cases - SIP digest with TLS as security mechanism |R8|  p. 257
The procedures for subclause 5.4.1.4.2 apply.
5.4.1.4.5  Abnormal cases - NASS-IMS bundled authentication as security mechanism |R8|  p. 257
There are no abnormal cases for NASS-IMS bundled authentication.
5.4.1.4.6  Abnormal cases - GPRS-IMS-Bundled authentication as security mechanism |R8|  p. 257
There are no abnormal cases for GPRS-IMS-Bundled authentication.

5.4.1.5  Network-initiated deregistration  p. 257

For any registered public user identity, the S-CSCF can deregister:
  • all contact addresses bound to the indicated public user identity (i.e. deregister the respective public user identity);
  • some contact addresses bound to the indicated public user identity;
  • a particular contact address bound to the indicated public user identity; or
  • one or more registration flows and the associated contact address bound to the indicated public user identity, when the UE supports multiple registration procedure;
by sending a single NOTIFY request.
Prior to initiating the network-initiated deregistration for the only currently registered public user identity and its associated set of implicitly registered public user identities and wildcarded public user identities that have been registered either with the same contact address of the UE or the same registration flow and the associated contact address (if the multiple registration mechanism is used), i.e. there are no other public user identities registered either with this contact address or with this registration flow and the associated contact address (if the multiple registration mechanism is used), and there are still active multimedia sessions belonging either to this contact address or to this registration flow and the associated contact address (if the multiple registration mechanism is used), the S-CSCF shall release only multimedia sessions belonging to this contact address or to this registration flow and the associated contact address (if the multiple registration mechanism is used) as described in the following paragraph. The multimedia sessions for the same public user identity, if registered either with another contact address or another registration flow and the associated contact address (if the multiple registration mechanism is used) remain unchanged.
Prior to initiating the network-initiated deregistration while there are still active multimedia sessions that are associated with this user and contact, the S-CSCF shall release none, some or all of these multimedia sessions by applying the steps listed in subclause 5.4.5.1.2 under the following conditions:
  • when the S-CSCF does not expect the UE to reregister a given public user identity and its associated set of implicitly registered public user identities that have been registered with respective contact address (i.e. S-CSCF will set the event attribute within the respective <contact> element to "rejected" for the NOTIFY request, as described below), the S-CSCF shall release all sessions that are associated with the registered contact address for the public user identities using the contact address that is being deregistered, which includes the implicitly registered public user identities.
  • when the S-CSCF expects the UE to reregister a given public user identity and its associated set of implicitly registered public user identities that have been registered with respective contact address (i.e. S-CSCF will set the event attribute within the respective <contact> element to "deactivated" for the NOTIFY request, as described below), the S-CSCF shall only release sessions that currently include the user's contact address, where the session was initiated by or terminated towards the user with the contact address registered to one of the public user identities using the contact address that is being deregistered, which includes the implicitly registered public user identities.
When a network-initiated deregistration event occurs for one or more public user identities that are bound either to one or more contact addresses or registration flows and the associated contact addresses (if the multiple registration mechanism is used), the S-CSCF shall send a NOTIFY request to all subscribers that have subscribed to the respective reg event package. For each NOTIFY request, the S-CSCF shall:
  1. set the Request-URI and Route header field to the saved route information during subscription;
  2. set the Event header field to the "reg" value;
  3. in the body of the NOTIFY request, include as many <registration> elements as many public user identities the S-CSCF is aware of the user owns;
  4. set the aor attribute within each <registration> element to one public user identity:
    1. set the <uri> sub-element inside each <contact> sub-element of each <registration> element to the respective contact address provided by the UE;
    2. if the public user identity:
      1. has been deregistered (i.e. all contact addresses and all registration flows and associated contact addresses bound to the indicated public user identity are removed) then:
        • set the state attribute within the <registration> element to "terminated";
        • set the state attribute within each <contact> element belonging to this UE to "terminated"; and
        • set the event attribute within each <contact> element belonging to this UE to either "unregistered", or "deactivated" if the S-CSCF expects the UE to reregister or "rejected" if the S-CSCF does not expect the UE to reregister; or
      2. has been kept registered then:
        1. set the state attribute within the <registration> element to "active";
        2. set the state attribute within each <contact> element to:
          • for the binding between the public user identity and either the contact address or a registration flow and associated contact addresses (if the multiple registration mechanism is used) to be removed set the state attribute within the <contact> element to "terminated", and event attribute element to either "unregistered", or "deactivated" if the S-CSCF expects the UE to reregister or "rejected" if the S-CSCF does not expect the UE to reregister; or
          • for the binding between the public user identity and either the contact address or the registration flow and associated contact addresses (if the multiple registration mechanism is used) which remain unchanged, if any, leave the <contact> element unmodified, and if the contact has been assigned GRUUs and the Contact URI did not contain a "bnc" SIP URI parameter then set the <pub-gruu> and <temp-gruu> sub-elements of the <contact> element as specified in RFC 5628 and include the <unknown-param> sub-element within each <contact> to any additional header field parameters contained in the Contact header field of the REGISTER request according to RFC 3680; and
  5. add a P-Charging-Vector header field with the "icid-value" header field parameter set to the value populated in the initial request for the dialog and a type 1 "orig-ioi" header field parameter. The S-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The S-CSCF shall not include the type 1 "term-ioi" header field parameter.
The S-CSCF shall only include the non-barred public user identities in the NOTIFY request.
When sending a final NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" (i.e. all public user identities have been deregistered or expired), the S-CSCF shall also terminate the subscription to the registration event package by setting the Subscription-State header field to the value of "terminated".
Also, for all service profiles in the implicit registration set the S-CSCF shall send a third-party REGISTER request, as described in subclause 5.4.1.7, to each AS that matches the Filter Criteria of the service profile from the HSS as if a equivalent REGISTER request had been received from the user deregistering that public user identity, or combination of public user identities.
On completion of the above procedures for one or more public user identities linked to the same private user identity, the S-CSCF shall consider those public user identities and the associated implicitly registered public user identities which have no contact address or a registration flow and associated contact addresses (if the multiple registration mechanism is used) bound to them as deregistered. On completion of the S-CSCF Registration/deregistration notification procedure with the HSS, as described in TS 29.228, the S-CSCF shall:
  1. update or remove those public user identities linked to the same private user identity, their registration state and the associated service profiles from the local data (based on operators' policy the S-CSCF can request of the HSS to either be kept or cleared as the S-CSCF allocated to this subscriber); and
  2. if all the contacts bound to the public user identities have been deregistered and there is no ongoing session due to the public user identities, then remove all the stored AS IP addresses which are associated with those public user identities.
On the completion of the network-initiated de-registration by the HSS procedure, as described in TS 29.228, the S-CSCF shall remove:
  1. those public user identities, their registration state and the associated service profiles from the local data; and
  2. if all the contacts bound to the public user identities have been deregistered and there is no ongoing session due to the public user identities, then remove all the stored AS IP addresses which are associated with those public user identities.
Up

5.4.1.6  Network-initiated re-authentication  p. 259

The S-CSCF may request a subscriber to re-authenticate at any time, based on a number of possible operator settable triggers.
If the S-CSCF is informed that a private user identity needs to be re-authenticated, the S-CSCF shall generate a NOTIFY request on all dialogs which have been established due to subscription to the reg event package of that user. For each NOTIFY request the S-CSCF shall:
  1. set the Request-URI and Route header field to the saved route information during subscription;
  2. set the Event header field to the "reg" value;
  3. in the body of the NOTIFY request, include as many <registration> elements as many public user identities the S-CSCF is aware of the user owns:
    1. set the <uri> sub-element inside the <contact> sub-element of each <registration> element to the contact address provided by the UE;
    2. set the aor attribute within each <registration> element to one public user identity;
    3. set the state attribute within each <registration> element to "active";
    4. set the state attribute within each <contact> element to "active";
    5. set the event attribute within each <contact> element that was registered by this UE to "shortened";
    6. set the expiry attribute within each <contact> element that was registered by this UE to an operator defined value; and
    7. if the Contact URI did not contain a "bnc" SIP URI parameter then set the <pub-gruu> and <temp-gruu> sub-elements within each <contact> element as specified in subclause 5.4.2.1.2; and
  4. set a P-Charging-Vector header field with the "icid-value" header field parameter set to the value populated in the initial request for the dialog and a type 1 "orig-ioi" header field parameter. The S-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The S-CSCF shall not include the type 1 "term-ioi" header field parameter.
Afterwards the S-CSCF shall wait for the user to re-authenticate (see subclause 5.4.1.2).
The S-CSCF shall only include the non-barred public user identities in the NOTIFY request.
When generating the NOTIFY request, the S-CSCF shall shorten the validity of all registration lifetimes associated with this private user identity to an operator defined value that will allow the user to be re-authenticated.
Up

5.4.1.7  Notification of Application Servers about registration status  p. 260

During registration, the S-CSCF shall include the P-Access-Network-Info header fields (as received in the REGISTER request from the UE and the P-CSCF) and a P-Visited-Network-ID header field (as received in the REGISTER request from the UE) in the third-party REGISTER request sent towards the ASs, if the AS is part of the trust domain. If the AS is not part of the trust domain, the S-CSCF shall not include any P-Access-Network-Info header field or P-Visited-Network-ID header field. The S-CSCF shall not include a P-Access-Network-Info header field in any responses to the REGISTER request.
If the registration procedure described in subclauses 5.4.1.2, 5.4.1.4 or 5.4.1.5 (as appropriate) was successful, the S-CSCF shall send a third-party REGISTER request to each AS with the following information:
a)
the Request-URI, which shall contain the AS's SIP URI;
b)
the From header field, which shall contain the S-CSCF's SIP URI;
c)
the To header field, which shall contain a non-barred public user identity belonging to the service profile of the processed Filter Criteria. It may be either a public user identity as contained in the REGISTER request received from the UE or one of the implicitly registered public user identities in the service profile, as configured by the operator;
d)
the Contact header field, which shall contain the S-CSCF's SIP URI;
e)
for initial registration and user-initiated reregistration (subclause 5.4.1.2), the registration expiration interval value, which shall contain the same value that the S-CSCF returned in the 200 (OK) response for the REGISTER request received from the UE;
f)
for user-initiated deregistration (subclause 5.4.1.4) and network-initiated deregistration (subclause 5.4.1.5), the registration expiration interval value, which shall contain the value zero;
g)
for initial registration and user-initiated reregistration (subclause 5.4.1.2), a message body, if there is Filter Criteria indicating the need to include HSS provided data for the REGISTER event (e.g. HSS may provide AS specific data to be included in the third-party REGISTER) or if there is Filter Criteria indicating the need to include the contents of the incoming REGISTER request or the contents of the 200 (OK) response to the incoming REGISTER request in the body of the third-party REGISTER. The S-CSCF shall format the MIME body and set the value of the Content-Type header field to include the MIME type specified in subclause 5.4.1.7A;
h)
for initial registration and user-initiated reregistration, the P-Charging-Vector header field, which shall contain the same "icid-value" header field parameter that the S-CSCF received in the REGISTER request from the UE. The S-CSCF shall insert a type 3 orig-ioi parameter in place of any received "orig-ioi" header field parameter and 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;
i)
for initial registration and user-initiated reregistration, a P-Charging-Function-Addresses header field, which shall contain the values received from the HSS if the message is forwarded within the S-CSCF home network;
j)
in case the received REGISTER request contained a P-User-Database header field and the AS belongs to the same operator as the S-CSCF, optionally a P-User-Database header field which shall contain the received value; and
k)
void
l)
if the S-CSCF supports using a token to identify the registration for initial registration and user initiated reregistration, a "+g.3gpp.registration-token" Contact header field parameter, as defined in subclause 7.9.7, set to a value identifying this registration among the set of registrations for the registered URI. The value shall be the same until the UE is deregistered.
For third-party REGISTER upon user-initiated reregistration, user-initiated deregistration or network-initiated deregistration, the S-CSCF shall send SIP REGISTER request towards the IP address associated with the corresponding registered public user identity stored as described in subclause 5.4.0.
When the S-CSCF receives any response to a third-party REGISTER request, the S-CSCF shall store the value of the "term-ioi" header field parameter received in the P-Charging-Vector header field, if present.
If the S-CSCF fails to receive a SIP response or receives a 408 (Request Timeout) response or a 5xx response to a third-party REGISTER, 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, no further action is needed; and
  • if the default handling defined in the filter criteria indicates the value "SESSION_TERMINATED" as specified in TS 29.228, initiate the network-initiated deregistration as described in subclause 5.4.1.5 for the currently registered public user identity and its associated set of implicitly registered non-barred public user identities bound to the contact(s) registered in the REGISTER request causing the third-party REGISTER request.
Up

5.4.1.7A  Including contents in the body of the third-party REGISTER request |R8|  p. 262

If there is a service information XML element provided in the HSS Filter Criteria for an AS (see TS 29.228), then in the third-party REGISTER request the S-CSCF shall:
  • include in the message body the service information within the <service-info> XML which is a child XML element of an <ims-3gpp> element with the "version" attribute set to "1" element as described in subclause 7.6; and
  • set the value of the content type to the MIME type specified in subclause 7.6.
If there is an Include Register Request XML element provided in the HSS Filter Criteria for an AS (see TS 29.228), then in the third-party REGISTER request the S-CSCF shall:
  • include in the message body the incoming SIP REGISTER request within a "message/sip" MIME body as defined in RFC 3261; and
  • set the value of the content type to "message/sip".
If there is an Include Register Response XML element provided in the HSS Filter Criteria for an AS (see TS 29.228), then in the third-party REGISTER request, the S-CSCF shall:
  • include in the message body the 200 (OK) response to the incoming SIP REGISTER request within a "message/sip" MIME body as defined in RFC 3261; and
  • set the value of the content type to "message/sip".
If there is more than one message body to be included in the third-party REGISTER request then in the third-party REGISTER request the S-CSCF shall:
  • include a multipart message body and set the value of the Content-Type header field to "multipart/mixed" as specified in RFC 2046 and RFC 5621; and
  • set the Content-Type of the elements of the MIME body to the content type specified for the body.
If there is only one message body to be included in the third-party REGISTER request then the S-CSCF sets the Content-Type header field to the content type specified for the body.
Up

5.4.1.8  Service profile updates |R7|  p. 262

When receiving a Push-Profile-Request (PPR) from the HSS (as described in TS 29.228), modifying the service profile of served public user identities, the S-CSCF shall:
  1. if the modification consists in the addition of a new non-barred public user identity to an implicit set, or in the change of status from barred to non-barred for a public user identity already in the implicit set, add the public user identity to the list of registered, non-barred public user identities;
  2. if the modification consists in the deletion of a public user identity while there are no active multimedia session belonging to this public user identity, or in the change of status from non-barred to barred of a public user identity in an implicit set, remove the public user identity from the list of registered, non-barred public user identities;
  3. if the modification consists of deletion of a public user identity from an implicit registration set while there are active multimedia session belonging to this public user identity and contact, release these multimedia sessions as described in subclause 5.4.5.1.2 and after all multimedia sessions are released, remove the public user identity from the list of registered, non-barred public user identities; and
  4. synchronize with the UE and IM CN entities, by either:
    • performing the procedures for notification of the reg-event subscribers about registration state, as described in subclause 5.4.2.1.2; or
    • triggering the UE to reregister, by:
      1. depending on operator configuration, rejecting a request from the UE using a 504 (Server Time-out) response and indicating in the response that S-CSCF restoration procedures are supported, in accordance with subclause 5.4.3.2; or
      2. shortening the life time of the current registration, as described in subclause 5.4.1.6, e.g. when a new trigger point of Register method is added in the iFCs.
Up

Up   Top   ToC