Content for  TS 24.229  Word version:  19.0.0

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: 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.

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.

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.