Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  18.5.0

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

 

5.2.3  Subscription to the user's registration-state event packagep. 181

Upon receipt of a 200 (OK) response to the first initial REGISTER request (i.e. this was the first initial REGISTER request that the P-CSCF received from the user identified with its private user identity), the P-CSCF shall:
1)
generate a SUBSCRIBE request in accordance with RFC 3680 and RFC 6665, with the following elements:
  1. a Request-URI set to the resource to which the P-CSCF wants to be subscribed to, i.e. to the SIP URI that is the default public user identity of the user;
  2. a From header field set to the P-CSCF's SIP URI;
  3. a To header field, set to the SIP URI that is the default public user identity of the user;
  4. an Event header field set to the "reg" event package;
  5. an Expires header field set to a value higher than the registration expiration interval value indicated in the 200 (OK) response to the REGISTER request;
  6. a P-Asserted-Identity header field:
    • if the received 200 (OK) response to the REGISTER request contained a "+g.3gpp.thig-path" Feature-Caps header field parameter, as defined in subclause 7.9A.9, and if the P-CSCF is located in the visited network, set to the value of the received "+g.3gpp.thig-path" Feature-Caps header field parameter; or
    • set to the SIP URI of the P-CSCF, which was inserted into the Path header field during the registration of the user to whose registration state the P-CSCF subscribes to; and
  7. a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260 and a type 1 "orig-ioi" header field parameter. The P-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The P-CSCF shall not include the type 1 "term-ioi" header field parameter;
1A)
if
  1. the P-CSCF supports indicating the traffic leg as specified in RFC 7549;
  2. the SIP URI used in the Request-URI of the SUBSCRIBE request belongs to a UE that is roaming;
  3. the P-CSCF is not in the home network; and
  4. if required by local policy;
then append the "iotl" SIP URI parameter set to "visitedA-homeA" to the Request-URI;
1B)
if required by local policy, then insert a Route header field in the SUBSCRIBE request with the list of service route values saved from the Service-Route header field received in the 200 (OK) response to the last registration of the public user identity with associated contact address and skip steps 2 to 4;
2)
if the P-CSCF is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, then the P-CSCF shall forward the request to an IBCF in the visited network;
3)
if the P-CSCF is located in the visited network and local policy does not require the application of IBCF capabilities in the visited network towards the home network, determine the entry point of the home network (e.g., by using DNS services) and send the SUBSCRIBE request to that entry point, according to the procedures of RFC 3261; and
4)
if the P-CSCF is located in the home network, then the P-CSCF shall forward the request to an I-CSCF in the home network.
Upon receipt of a dialog establishing NOTIFY request, as specified in RFC 6665, associated with the SUBSCRIBE request, the P-CSCF shall:
  1. store the information for the so established dialog;
  2. store the expiration time as indicated in the "expires" header field parameter of the Subscription-State header field, if present, of the received NOTIFY request. Otherwise the expiration time is retrieved from the Expires header field of the 2xx response to SUBSCRIBE request;
  3. follow the procedures specified in RFC 6665; and
  4. store the "icid-value" header field parameter and the "orig-ioi" header field parameter if present in the received P-Charging-Vector header field.
When sending a response to the NOTIFY request, the P-CSCF shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the NOTIFY request, a type 1 "term-ioi" header field parameter and the "icid-value" header field parameter. The P-CSCF shall set the type 1 "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 the "icid-value" header field parameter is set to the previously received value of "icid-value" header field parameter in the request.
If continued subscription is required the P-CSCF shall automatically refresh the subscription by the reg event package 600 seconds before the expiration time for a previously registered public user identity, either 600 seconds before the expiration time if the initial subscription was for greater than 1200 seconds, or when half of the time has expired if the initial subscription was for 1200 seconds or less. If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the P-CSCF shall still consider the original subscription valid for the duration of the most recently known "Expires" value according to RFC 6665. Otherwise, the P-CSCF shall consider the subscription invalid and start a new initial subscription according to RFC 6665.
Up

5.2.3AVoid

5.2.3B  SUBSCRIBE request |R9|p. 183

Upon receipt of a NOTIFY request with the Subscription-State header field set to "terminated", once the NOTIFY transaction is terminated, the P-CSCF can remove all the stored information related to the associated subscription.

5.2.4  Registration of multiple public user identitiesp. 183

Upon receipt of a NOTIFY request for the dialog associated with the subscription to the reg event package of the user, the P-CSCF shall:
  • store the information for the established dialog;
  • store the expiration time as indicated in the "expires" header field parameter of the Subscription-State header field, if present, of the SIP NOTIFY request. Otherwise the expiration time is retrieved from the Expires header field of the 2xx response to SIP SUBSCRIBE request;
  • identify the public user identity as follows:
    1. if no <wildcardedIdentity> subelement is included in the <registration> element, the public user identity is taken from the 'aor' attribute of the registration element; or
    2. if a <wildcardedIdentity> sub element is included in the <registration> element, the wildcarded public user identity is taken from the <wildcardedIdentity> sub element. The wildcarded public user identity is treated as a public user identity in the procedures of this subclause;
    3. for each public user identity whose state attribute in the <registration> element is set to "active", i.e. registered; and
      1. the state attribute within the <contact> sub-element is set to "active";
      2. the value of the <uri> sub-element inside the <contact> sub-element is set to the contact address of the user's UE; and
      3. the event attribute of that <contact> sub-element(s) is set to "registered" or "created";
      the P-CSCF shall:
      1. bind the indicated public user identity as registered to the contact address of the respective user, including any associated display names, and any parameters associated with either the user or the identities of the user;
      2. add the public user identity to the list of the public user identities that are registered for the user saved against the contact address;
      3. if the <actions> child element is included in the <registration> element, bind the policy received in the <actions> child element of the <registration> element to each contact address of the public user identity; and
      4. if the <actions> child element is not included in the <registration> element, remove the policy bound to each contact address of the public user identity;
    4. for each public user identity whose state attribute in the <registration> element is set to "active", i.e. registered: and
      1. the state attribute within the <contact> sub-element is set to "terminated";
      2. the value of the <uri> sub-element inside the <contact> sub-element is set to the contact address of the user's UE; and
      3. the event attribute of that <contact> sub-element(s) is set to "deactivated", "expired", "probation", "unregistered", or "rejected";
      the P-CSCF shall consider the binding between the indicated public user identity and the contact address and its related information as deregistered for this user, and shall release all stored information associated with the deregistered contact address and related information associated with this contact address; and
    5. for each public user identity whose state attribute in the <registration> element is set to "terminated", i.e. deregistered; and for each <contact> sub-element, if
      1. the value of the <uri> sub-element inside each <contact> sub-element is set to the respective contact address of the user's UE; and
      2. the event attribute of each <contact> sub-element(s) is set to "deactivated", "expired", "probation", "unregistered", or "rejected";
      the P-CSCF shall consider the indicated public user identity and all its contact addresses as deregistered for this UE, and shall release all stored information for these public user identity bound to the respective user and remove the public user identity from the list of the public user identities that are registered for the user;
  • shall store the "orig-ioi" header field parameter if present in the received P-Charging-Vector header field; and
  • follow the procedures specified in RFC 6665.
When sending a response to the NOTIFY request, the P-CSCF shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the NOTIFY request, a type 1 "term-ioi" header field parameter and the "icid-value" header field parameter. The P-CSCF shall set the type 1 "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 the "icid-value" header field parameter is set to the value populated in the initial request for the dialog.
If the P-CSCF is informed that all contact addresses that are registered with this P-CSCF and belonging to the user using its private user identity have been deregistered, i.e. the state attribute within each <contact> sub-element is set to "terminated", the P-CSCF shall either unsubscribe to the reg event package or let the subscription expire.
If all public user identities, that were registered by the user using its private user identity, have been deregistered, the P-CSCF, will receive from the S-CSCF a NOTIFY request that may include the Subscription-State header field set to "terminated", as described in subclause 5.4.2.1.2. If the Subscription-State header field was not set to "terminated", the P-CSCF may either unsubscribe to the reg event package of the user or let the subscription expire.
Up

5.2.5  Deregistrationp. 184

5.2.5.1  User-initiated deregistrationp. 184

When the P-CSCF receives a 200 (OK) response to a REGISTER request (sent according to subclause 5.2.2) sent by this UE, then the P-CSCF shall check each Contact header field included in the response. If there is a Contact header field that contains the contact address registered via this P-CSCF via the respective security associations or TLS sessions, and the value of the registration expiration interval value equals zero, then the P-CSCF shall:
1)
if the "reg-id" header field parameter is not included in the Contact header field, remove the binding between the public user identity found in the To header field (together with the implicitly registered public user identities) and the contact address indicated in the Contact header field, from the registered public user identities list belonging to this UE and all related stored information;
1A)
if the "reg-id" header field parameter is included in the Contact header field, remove the public user identity found in the To header field (together with the implicitly registered public user identities) and the flow identified by the "reg-id" header field parameter and all its related stored information belonging to this UE;
2)
if multiple registrations is not used, check if the UE has left any other registered public user identity. When all of the public user identities that were registered by this UE are deregistered, the P-CSCF shall delete any security associations, TLS sessions or IP associations towards the UE, after the server transaction (as defined in RFC 3261) pertaining to this deregistration terminates; and
2A)
if multiple registrations is used, check if the UE has left any other registered public user identity that is bound to this flow. When all of the public user identities that were registered and are bound to this flow are deregistered, the P-CSCF shall delete any security associations or TLS sessions associated with this flow, after the server transaction (as defined in RFC 3261) pertaining to this deregistration terminates.
Up

5.2.5.2  Network-initiated deregistrationp. 185

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package of the UE, as described in subclause 5.2.3, including one or more <registration> element(s) which were registered by the UE with either:
  • the state attribute within the <registration> element set to "terminated"; or
  • the state attribute within the <registration> element set to "active" and the state attribute within the <contact> sub-element belonging to this UE and registered via this P-CSCF set to "terminated", and the event attribute within the <contact> sub-element belonging to this UE set either to "unregistered", or "rejected" or "deactivated";
the P-CSCF shall remove all stored information for these public user identities for this UE and remove these public user identities from the list of the public user identities that are registered for the user.
Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" (i.e. all public user identities are deregistered) and the Subscription-State header field set to "terminated" or when all public user identities of the UE have been deregistered, the P-CSCF shall shorten any security associations or TLS sessions towards the UE.
Upon receipt of a NOTIFY request for the dialog associated with the subscription to the reg event package of the user the P-CSCF shall store the "orig-ioi" header field parameter if present in the received P-Charging-Vector header field.
When sending a response to the NOTIFY request, the P-CSCF shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the NOTIFY request, a type 1 "term-ioi" header field parameter and the "icid-value" header field parameter. The P-CSCF shall set the type 1 "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 the "icid-value" header field parameter is set to the value populated in the initial request for the dialog.
Up

Up   Top   ToC