5.20 Procedures for Assigning, Using, and Processing GRUUs

23.2283GPPIP Multimedia Subsystem (IMS)Release 18Stage 2TS

5.20.1 UE

5.20.1.1 Obtaining a GRUU during registration

A UE shall indicate its support for the GRUU mechanism in the registration request and retain the GRUU set (P‑GRUU and T‑GRUU) in the registration response. The UE may retain some or all of the previous T‑GRUUs obtained during the initial registration or previous re-registrations along with the new T‑GRUU or the UE may replace some or all of the previous T‑GRUUs with the new T‑GRUU. The UE shall generate an instance identifier that is a unique identifier for that UE. The UE shall include an instance identifier in all registration requests. Instance identifiers shall conform to the mandatory requirements for instance identifiers specified in RFC 5627 [49] and RFC 5626 [48].

If the registered Public User Identity is part of an implicit registration set, the UE shall obtain and retain the GRUU sets for each implicitly registered SIP URI sent by the S‑CSCF in accordance to RFC 5628 [50].

5.20.1.2 Using a GRUU

When sending SIP requests from an explicitly or implicitly registered Public User Identity for which a UE obtained P‑GRUU and at least one T‑GRUU, the UE should use the corresponding retained P‑GRUU or a T‑GRUU as a Contact address.

When responding to SIP requests where the identification of the called party is a registered Public User Identity for which a UE obtained a GRUU, the UE shall use the corresponding retained P‑GRUU or T‑GRUU as the Contact address when addressing that UE.

If the UE has obtained GRUUs for its Public User Identity being used in a request or response and the user does not require privacy the UE should use the P‑GRUU as the Contact address.

A UE may learn a GRUU of another UE using mechanisms that are outside the scope of this specification, (e.g. a UE may learn a GRUU from the contact header of a request, from presence information, or by other mechanisms).

If a UE that receives a notification from the S‑CSCF indicating that an implicit registration has occurred for a contact the UE has registered, then the UE shall retain the GRUUs included in the notification for future use.

5.20.1.3 Using a GRUU while requesting Privacy

When a UE sends a request or response containing a GRUU, and it wishes to block the delivery of its Public User Identity to an untrusted destination, the UE shall use a T-GRUU as the Contact address.

5.20.2 Serving‑CSCF

5.20.2.1 Allocating a GRUU during registration

The S‑CSCF, when receiving a registration request from a UE that includes an instance id, shall allocate a GRUU set. If the UE indicates support of GRUU in the REGISTER request, then the S‑CSCF shall return the GRUU set in the registration response and associate that GRUU set with the registered contact information for that UE.

NOTE: As long as the instance id provided in the register request is the same, the resulting P‑GRUU in the GRUU set will always be the same for a given Public User Identity. The T‑GRUU will be different from those returned during previous re-registrations. All T‑GRUUs that are allocated continue to remain valid until that UE Instance ID and Public User Identity pair are deregistered.

If there are implicitly registered Public User Identities, the S‑CSCF shall generate a GRUU set for each implicitly registered Public User Identity and include the corresponding GRUU set with the notification of each implicitly registered Public User Identity

5.20.2.2 Using a GRUU

The filter criteria in the service profile may check for the presence of a GRUU in the Request URI or related parameters of a request.

For originations, the S‑CSCF shall validate the GRUU conveyed in the contact header of the SIP request and pass the SIP request with the validated GRUU to Application Servers based on the filter criteria.

For terminations, the S‑CSCF may validate the GRUU conveyed in the Request URI header of the SIP request and pass the SIP request with the validated GRUU to Application Servers based on filter criteria.

Application servers may then apply services to the GRUU.

If the SIP message is destined to a GRUU, then the S‑CSCF shall associate the request with the corresponding Public User Identity. The S‑CSCF will not fork this request, but will direct the call to the identified instance.

S‑CSCF shall provide an indication to UE that the SIP request was targeted to a GRUU.

5.20.3 Interrogating‑CSCF

When routing requests addressed to a GRUU to the terminating S‑CSCF, the I‑CSCF uses the contents of the Request URI when querying the HSS. Requests routed to the terminating S‑CSCF are addressed to the GRUU.

5.20.3a HSS

The HSS shall remove the P‑GRUU as part of the canonicalization process of SIP URIs, to obtain the Public User Identity for identity look-up as it is defined in TS 29.228 [30].

5.20.4 Elements other than UE acting as a UA

5.20.4.1 Using a GRUU

It shall be possible for other IMS elements other than UEs, that act as UAs (e.g. MGCF, Application Server) to use a GRUU referring to itself when inserting a contact address in a SIP message. The MGCF and MRF are not required to store GRUUs beyond a session. If the incoming contact address that is being replaced by the B2BUA functionality contains a GRUU, then the replacement URI in the outgoing SIP message should also contain a GRUU.

If an element so uses a GRUU, it shall handle requests received outside of the session in which the contact was provided.

Routing procedures amongst IMS elements other than UEs that act as UAs are unchanged when GRUUs are in use.

5.20.4.2 Assigning a GRUU

The GRUUs shall either be provisioned by the operator or obtained by any other mechanism. The GRUU shall remain valid for the time period in which features addressed to this URI remains meaningful.