5.4.2 Subscription and notification

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.4.2.1 Subscriptions to S-CSCF events

5.4.2.1.1 Subscription to the event providing registration state

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

0) 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;

1) 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;

NOTE 1: The S-CSCF finds the identity for authentication of the subscription in the P-Asserted-Identity header field received in the SUBSCRIBE request.

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 [191] 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;

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

NOTE 2: Any received "orig-ioi" header field parameter will be either a type 1 IOI or a type 3 IOI. The type 1 IOI identifies the sending network and the type 3 IOI identifies the service provider from which the request was sent.

3) generate a 200 (OK) response acknowledging the SUBSCRIBE request and indicating that the authorised subscription was successful as described in RFC 3680 [43] and RFC 6665 [28]. 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

NOTE 3: The S-CSCF could use such unique identifiers to distinguish between UEs, when two or more users, holding a shared subscription, register under the same public user identity.

4) 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:

a) 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

b) 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).

NOTE 4: If the URI in the P-Asserted-Identity header field of the initial SUBSCRIBE request matches URIs of several Path header fields (e.g. the SUBSCRIBE request is originated by Rel-7 P-CSCF), the applicable private user identity is not determined.

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

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.

NOTE 1: If the UE binds a given public user identity to the same contact address but several registration flows and the associated contact address (via several registrations), then the NOTIFY request will contain one <contact> element for each registration flow and the associated contact address. Each respective <contact> elements will contain the same contact address in the <uri> sub-element, but different value in the "id" attribute and different "reg-id" value included in the respective <unknown-param> element.

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

NOTE 2: When multiple registrations mechanism is not used, if the UE registers new contact address then all registrations, if any, using an old contact address are deregistered, i.e. the new registration replaces the old registrations. Hence, for each deregistered public user identity, the NOTIFY request will have the state attribute within the <registration> element set to "terminated" and the state attribute in the <contact> element set to "terminated" and the event attribute set to "unregistered", "deactivated", or "rejected".

NOTE 3: If the UE uses a multiple registrations mechanism to bind a public user identity to a new registration flow the registration flow and the associated contact address, and if the new registration flow replaces an existing registration flow, then for the registration flow and the associated contact address being replaced, the respective <contact> element in the NOTIFY request will 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 [28].

When sending a NOTIFY request, the S-CSCF shall not use the default filtering policy as specified in RFC 3680 [43], 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).

NOTE 4: Contact information related to emergency registration is not included.

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

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:

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 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;

4) for each <registration> element:

a) 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.

b) 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:

I) 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 [94]; or

II) 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;

c) 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 RFC3680 [43];

d) if the user owns a wildcarded public user identity then include a <wildcardedIdentity> sub-element as described in subclause 7.10.2;

e) if the public user identity set in step a):

I) 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 [43].

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;

II) 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 [43];

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.

III) has been re-registered (i.e. it has been previously registered) then:

– set the state attribute within the <registration> element to "active";

– 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 [43];

– 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 re-registered, 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 [43]; 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);

IV) 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 [43];

– 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

V) 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.

f) set the callid and cseq attributes for the <contact> as specified in RFC 3680 [43], and the first-cseq attribute as specified in RFC 5628 [94]; and

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

5) 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.

NOTE 10: When sending a NOTIFY request to a subscriber subscribing or unsubscribing to the reg event package, or when the S-CSCF terminates the subscription, the event attribute within the <contact> element includes the last event that caused the transition to the respective state.

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">

<unknown-param name="audio"/>

</contact>

</registration>

<registration aor="sip:user1_public2@home1.net" id="as10"

state="active">

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

</registration>

<registration aor="sip:ep_user1@home1.net" id="as11"

state="active">

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

NOTE 11: Any received "term-ioi" header field parameter will be a type 3 IOI if received from an AS or a type 1 IOI if received from a public user identity this particular user owns, or any of the entities identified by the Path header field. The type 3 IOI identifies the service provider from which the response was sent and the type 1 IOI identifies the network from which the response was sent.

5.4.2.1.3 Void

5.4.2.1.4 Void

5.4.2.1A Outgoing subscriptions to load-control event

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 [28] and with RFC 7200 [201]. When subscribing to the load-control event, the S-CSCF shall:

1) Send a SUBSCRIBE request in accordance with RFC 6665 [28] and with RFC 7200 [201] to the target entity, with the following elements:

– an Expires header field set to a network specific value;

2) 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 [28].

5.4.2.2 Other subscriptions

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.