Content for TS 24.229 Word version: 19.0.0

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.2 Subscription and notification
...

5.4.2 Subscription and notification p. 267

5.4.2.1 Subscriptions to S-CSCF events p. 267

5.4.2.1.1 Subscription to the event providing registration state p. 267

When an incoming SUBSCRIBE request addressed to S-CSCF arrives containing the Event header field with the reg event package, the S-CSCF shall:

if the Request-URI of the SUBSCRIBE request contains a URI for which currently no binding exists, then send a 480 (Temporarily Unavailable) response indicating that the subscription was not successful and skip the remainder of the steps;

check if, based on the local policy, the request was generated by a subscriber who is authorised to subscribe to the registration state of this particular user. The authorized subscribers include:

all public user identities this particular user owns, that the S-CSCF is aware of, and which are not-barred;
all the entities identified by the Path header field (i.e. the P-CSCF to which this user is attached to or the IBCF which encrypted the Path header field); and
all the ASs listed in the initial filter criteria that are part of the trust domain;

if the request is received from a subscriber which is not auhorized to subscribe to the registration state of this particular user, then send a 403 (Forbidden) response indicating that the subscription was not successful and skip the remainder of the steps;

1A)

if the Request-URI of the SUBSCRIBE request identifies a public user identity that was implicitly registered using the registration procedures defined in RFC 6140 and performs the functions of an external attached network, and the registration is currently active, then skip the remainder of the procedure in this subclause and route the SUBSCRIBE request to the UE performing the functions of an externally attached network using the procedures defined in subclause 5.4.3.3;

1B)

store the "icid-value" header field parameter received in the P-Charging-Vector header field;

store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field if present;

generate a 200 (OK) response acknowledging the SUBSCRIBE request and indicating that the authorised subscription was successful as described in RFC 3680 and RFC 6665. The S-CSCF shall populate the header fields as follows:

an Expires header field, set to either the same or a decreased value as the Expires header field in SUBSCRIBE request;
if the request originated from an ASs listed in the initial filter criteria, a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the SUBSCRIBE request, a type 3 "term-ioi" header field parameter and the "icid-value" header field parameter. 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 the "icid-value" header field parameter is set to the previously received value of "icid-value" header field parameter in the request; and
if the request originated from a public user identity this particular user owns, or any of the entities identified by the Path header field, a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the SUBSCRIBE request, a type 1 "term-ioi" header field parameter, and the "icid-value" header field parameter. The S-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.

The S-CSCF may set the Contact header field to an identifier uniquely associated to the SUBSCRIBE request and generated within the S-CSCF, that may help the S-CSCF to correlate refreshes for the SUBSCRIBE dialog; and

determine the applicable private user identity as the private user identity included in a REGISTER request:

which created (implicitly or explictly) a binding of the public user identity in the Request-URI of the SUBSCRIBE request to an contact address; and
for which one of the following is true:
1. the 200 (OK) response to the REGISTER request contained the Service-Route header field with the S-CSCF URI matching the URI in the top Route header field of the SUBSCRIBE request (i.e. the SUBSCRIBE request originated by a served UE); or
2. the 200 (OK) response to the REGISTER request contained a Path header field with a URI matching the URI in the P-Asserted-Identity header field of the SUBSCRIBE request (i.e. the SUBSCRIBE request originated by a P-CSCF serving a UE).

Afterwards the S-CSCF shall perform the procedures for notification about registration state as described in subclause 5.4.2.1.2.

If the SUBSCRIBE request originated from an AS listed in the initial filter criteria, for any response that is not a 2xx response, the S-CSCF shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the SUBSCRIBE request, a type 3 "term-ioi" header field parameter and the "icid-value" header field parameter. 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 the "icid-value" header field parameter is set to the previously received value of "icid-value" header field parameter in the request.

If the SUBSCRIBE request originated from a public user identity this particular user owns, or any of the entities identified by the Path header field, for any response that is not a 2xx response, the S-CSCF shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the SUBSCRIBE request, a type 1 "term-ioi" header field parameter and the "icid-value" header field parameter. The S-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.

When the S-CSCF receives a subscription refresh request for a dialog that was established by the UE subscribing to the reg event package, the S-CSCF shall accept the request irrespective if the user's public user identity specified in the SUBSCRIBE request is either registered or has been deregistered.

5.4.2.1.2 Notification about registration state p. 268

The UE can bind any one of its public user identities either to its contact address or to a registration flow and the associated contact address (if the multiple registration mechanism is used) via a single registration procedure. When multiple registrations mechanism is used to register a public user identity and bind it to a registration flow and the associated contact address, the S-CSCF shall generate a NOTIFY request that includes one <contact> element for each binding between a public user identity and a registration flow and the associated contact address.

For every successful registration that creates a new binding between a public user identity and either its contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used, the NOTIFY request shall always include a new <contact> element containing new value in the "id" sub-element, the state attribute set to "active", and event attribute set to either "registered" or "created".

Any successful registration (that creates a new binding between a public user identity and either its contact address or a registration flow and associated contact address) may additionally replace or remove one or more existing bindings. In the NOTIFY request, for each replaced or removed binding, the <contact> element shall have the state attribute set to "terminated" and the event attribute set to "unregistered", "deactivated", or "rejected".

The S-CSCF shall send a NOTIFY request:

when an event pertaining to the user occurs. In this case the NOTIFY request is sent on all dialogs which have been established due to subscription to the reg event package of that user; and
as specified in RFC 6665.

When sending a NOTIFY request, the S-CSCF shall not use the default filtering policy as specified in RFC 3680, i.e. the S-CSCF shall always include in every NOTIFY request the state information of all registered public user identities of the user (i.e. the full state information).

When generating NOTIFY requests, the S-CSCF shall not preclude any valid reg event package parameters in accordance with RFC 3680.

For each NOTIFY request triggered by an event and on all dialogs which have been established due to subscription to the reg event package of that user, the S-CSCF shall:

set the Request-URI and Route header field to the saved route information during subscription;

set the Event header field to the "reg" value;

in the body of the NOTIFY request, include one <registration> elements for each public user identity that the S-CSCF is aware the user owns.

If the user shares one or more public user identities with other users, the S-CSCF shall include any contact addresses registered by other users of the shared public user identity in the NOTIFY request;

for each <registration> element:

set the aor attribute to one public user identity or if the public user identity of this <registration> element is a wildcarded public user identity, then choose arbitrarily a public user identity that matches the wildcarded public user identity and the service profile of the wildcarded public user identity and set the aor attribute to this public user identity;

NOTE 5:
If the public user identity of this <registration> element is a wildcarded public user identity, the value of the aor attribute will not be used by the receiver of the NOTIFY.
set the <uri> sub-element inside each <contact> sub-element of the <registration> element to the contact address provided by the respective UE as follows:
1. if the aor attribute of the <registration> element contains a SIP URI and if the Contact URI did not contain a "bnc" SIP URI parameter, then for each contact address that contains a "+sip.instance" Contact header field parameter, include <pub-gruu> and <temp-gruu> sub-elements within the corresponding <contact> element. The S-CSCF shall set the contents of these elements as specified in RFC 5628; or
2. if the aor attribute of the <registration> element contains a tel-URI, determine its alias SIP URI and if the Contact URI did not contain a "bnc" SIP URI parameter then include a copy of the <pub-gruu> and <temp-gruu> sub-elements from that equivalent element;
if the respective UE has provided a display-name in a Contact header field, set the <display-name> sub-element inside the respective <contact> sub-element of the <registration> element to the value provided by the UE according to RFC 3680;
if the user owns a wildcarded public user identity then include a <wildcardedIdentity> sub-element as described in subclause 7.10.2;
if the public user identity set in step a):
1. has been deregistered either by the UE or the S-CSCF (i.e. upon the deregistration, there are no binding left between this public user identity and either a contact address or a registration flows and associated contact addresses that belong to this user) then:
  - set the state attribute within the <registration> element to "terminated";
  - set the state attribute within each <contact> element belonging to this user to "terminated"; and
  - set the event attribute within each <contact> element to "deactivated", "expired", "unregistered", "rejected" or "probation" according to RFC 3680.
  If the public user identity has been deregistered for this user and this deregistration has already been indicated in the NOTIFY request, and no new registration for this user has occurred, its <registration> element shall not be included in the subsequent NOTIFY requests;
2. has been registered by the UE (i.e. the public user identity has not been previously bound either to a contact address or to a registration flow and the associated contact address (if the multiple registration mechanism is used)) then:
  - set the <unknown-param> element to any additional header field parameters contained in the Contact header field of the REGISTER request according to RFC 3680;
    
    NOTE 6:
    If the multiple registration mechanism is used, then the reg-id header field parameter will be included as an <unknown-param> element.
  - if the subscription contains, for the applicable private user identity (determined as described in subclause 5.4.2.1.1) and the public user identity, any of the policies described in subclause 7.10.3, then include the policy associated with the applicable private user identity and the public user identity using coding described in subclause 7.10.3;
  - set the state attribute within the <registration> element to "active"; and:
  - set the state attribute within the <contact> element belonging to this user to "active", include new value for the "id" attribute within the <contact> sub-element, and set the event attribute within this <contact> element to "registered";
    
    NOTE 7:
    If this registration, that created new binding, additionally replaces or removes one or more existing registrations, then for the replaced or removed registrations the respective <registration> elements and <contact> elements will be modified accordingly.
3. has been reregistered (i.e. it has been previously registered) then:
  - set the state attribute within the <registration> element to "active";
  - if the subscription contains, for the applicable private user identity (determined as described in subclause 5.4.2.1.1) and the public user identity, any of the policies described in subclause 7.10.3, then include the policy associated with the applicable private user identity and the public user identity using coding described in subclause 7.10.3;
  - set the <unknown-param> element to any additional header field parameters contained in the Contact header field of the REGISTER request according to RFC 3680;
  - for contact addresses to be registered: set the state attribute within the <contact> element to "active"; and set the event attribute within the <contact> element to "registered";
  - for contact addresses to be reregistered, set the state attribute within the <contact> element to "active"; and set the event attribute within the <contact> element to "refreshed" or "shortened" according to RFC 3680; and
  - for contact addresses that remain unchanged, if any, leave the <contact> element unmodified (i.e. the event attribute within the <contact> element includes the last event that caused the transition to the respective state);
4. has been automatically registered or registered by the S-CSCF, and has not been previously automatically registered:
  - set the <unknown-param> element to any additional header field parameters contained in the Contact header field of the REGISTER request according to RFC 3680;
  - set the state attribute within the <registration> element to "active";
  - set the state attribute within the <contact> element to "active"; and
  - set the event attribute within the <contact> element to "created"; or
5. is hosted (unregistered case) at the S-CSCF:
  - set the state attribute within the <registration> element to "terminated";
  - set the state attribute within each <contact> element to "terminated"; and
  - set the event attribute within each <contact> element to "unregistered".
  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"; and
NOTE 8:
The value of "init" for the state attribute within the <registration> element is not used.
set the callid and cseq attributes for the <contact> as specified in RFC 3680, and the first-cseq attribute as specified in RFC 5628; and

NOTE 9:
Errata of RFC 5628 clarifies the usage of the first-cseq attribute of the <temp-gruu> element.

set the 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

if the NOTIFY request is sent towards an AS listed in the initial filter criteria a type 3 "orig-ioi" header field parameter. The S-CSCF 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; and
if the NOTIFY request is sent towards a public user identity this particular user owns, or any of the entities identified by the Path header field, 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.

EXAMPLE 1:

If sip:user1_public1@home1.net is registered, the public user identity sip:user1_public2@home1.net can automatically be registered. Therefore the entries in the body of the NOTIFY request look like:

                     <?xml version="1.0"?>
                     <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
                                  xmlns:cp="urn:ietf:params:xml:ns:common-policy"
                                  xmlns:eri="urn:3gpp:ns:extRegInfo:1.0"
                                  version="0" state="full">
                       <registration aor="sip:user1_public1@home1.net" id="as9"
                                     state="active">
                         <contact id="76" state="active" event="registered">
                                <uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>
                                <unknown-param name="audio"/>
                         </contact>
                       </registration>
                       <registration aor="sip:user1_public2@home1.net" id="as10"
                                     state="active">
                         <contact id="86" state="active" event="created">
                                <uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>
                                <unknown-param name="audio"/>
                         </contact>
                         <cp:actions>
                                <eri:rph ns="wps" val="1"/>
                                <eri:privSender/>
                         </cp:actions>
                       </registration>
                     </reginfo>

EXAMPLE 2:

If sip:user1_public1@home1.net is registered, the public user identity sip:ep_user1@home1.net can automatically be registered. sip:ep_user1@home1.net is a dedicated identity out of the related range indicated in the <wildcardedIdentity> element. Therefore the entries in the body of the NOTIFY request look like:

                     <?xml version="1.0"?>
                     <reginfo xmlns="urn:ietf:params:xmlns:reginfo"
                                  xmlns:ere="urn:3gpp:ns:extRegExp:1.0"
                                  version="0" state="full">
                       <registration aor="sip:user1_public1@home1.net" id="as10"
                                      state="active">
                          <contact id="86" state="active" event="created">
                                 <uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>
                          </contact>
                        </registration>
                        <registration aor="sip:ep_user1@home1.net" id="as11"
                                       state="active">
                          <contact id="86" state="active" event="created">
                                 <uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>
                          </contact>
                          <ere:wildcardedIdentity>sip:ep_user!.*!@home1.net
                          </ere:wildcardedIdentity>
                        </registration>
                     </reginfo>

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, expired or are hosted (unregistered case) at the S-CSCF), 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".

When all of a UE's contact addresses have been deregistered (i.e. there is no <contact> element set to "active" for this UE), the S-CSCF shall consider subscription to the reg event package belonging to the UE cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires header field containing a value of zero).

The S-CSCF shall only include the non-barred public user identities in the NOTIFY request.

When the S-CSCF receives any response to the NOTIFY 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.

5.4.2.1.3 Void

5.4.2.1.4 Void

5.4.2.1A Outgoing subscriptions to load-control event |R11| p. 273

Based on operator policy, the S-CSCF may subscribe to the load-control event package with one or more target SIP entities. The list of target SIP entities is provisioned.

Subscription to the load-control event package is triggered by internal events (e.g. the physical device hosting the SIP entity is power-cycled) or through a management interface.

The S-CSCF shall perform subscriptions to the load-control event package to a target entity in accordance with RFC 6665 and with RFC 7200. When subscribing to the load-control event, the S-CSCF shall:

Send a SUBSCRIBE request in accordance with RFC 6665 and with RFC 7200 to the target entity, with the following elements:
- an Expires header field set to a network specific value;
If the target entity is located in a different network and local policy requires the application of IBCF capabilities, forward the request to an IBCF acting as an exit point.

The S-CSCF shall automatically refresh ongoing subscription to the load-control event package 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.

The S-CSCF can terminate a subscription according to RFC 6665.

5.4.2.2 Other subscriptions |R9| p. 273

Upon receipt of a NOTIFY request with the Subscription-State header field set to "terminated" and the S-CSCF has retained the SIP dialog state information for the associated subscription, once the NOTIFY transaction is terminated, the S-CSCF can remove all the stored information related to the associated subscription.