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 and RFC 5626.
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.
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.
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.
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
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.
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.
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.
The IMS Multimedia Priority Service provides Service Users access to IMS services in a prioritised manner.
The P-CSCF shall control the priority of IMS based MPS sessions, using PCC procedures. The P-CSCF shall permit any authorised UE to originate an IMS based MPS session. The detection of MPS sessions is handled by the P-CSCF at the originating network.
PCC shall always be enabled in a network supporting IMS Multimedia Priority Services.
HSS shall store IMS Priority Indication and Priority Level as part of the subscription information.
The P-CSCF at the originating end shall determine whether the INVITE message requires priority handling based on user profile stored during the registration procedure and/or MPS code/identifier provided by the INVITE message. If the session is determined to require priority handling, then P-CSCF inserts/replaces the MPS priority indication in the INVITE and, if the Service User's priority level is known, may include it and forward the INVITE to the S-CSCF. If the Service User's priority level is not known, the P-CSCF includes the priority indication without the Service User's priority level. The S-CSCF routes (using initial Filter Criteria set for the MPS code/identifier) the INVITE to the AS for authentication/authorization for MPS (if needed), and the AS adds the Service User's priority level if it is not in the INVITE already. The AS then forwards the INVITE (with MPS priority indication and the Service User's priority level) to the next entity in the network via the S-CSCF as part of the normal IMS routing. All subsequent SIP messages carry both MPS priority indication and the Service User's priority level.
When the P-CSCF at the originating end determines that priority handling is required, the P-CSCF shall derive session information and interact with the PCRF/PCF providing the session information. The derived session information shall indicate the priority of the MPS session which depends if the Service User's priority level is known at this stage. The PCC interaction between the P-CSCF and the PCRF/PCF is described in TS 23.203 and TS 23.503.
The P-CSCF at the terminating end shall determine whether the INVITE message requires priority handling based on MPS priority indication and the originating Service User's priority level received from the originating network. If priority handling is required, P-CSCF shall derive the session information based on the Service User's priority level to indicate the priority of the MPS session and interact with the PCRF/PCF providing the session information,
When the terminating user is a Service User, while the session request is from a normal user, the IMS signalling bearer may be given priority treatment when operator policy and MPS (IMS) priority subscription indicates so. For a Service User originating a non-priority session, the IMS signalling bearer may be given priority treatment when operator policy and MPS (IMS) priority subscription indicates so. For IMS media, priority treatment is not required in these cases.
If so configured by the operator, a P-CSCF or an IBCF shall prohibit the negotiation of ECN during SDP offer/answer exchanges and shall not invoke ECN (as described in clause 4.22) for IMS based MPS sessions.
For E-UTRAN access, priority support for EPS bearer is described in TS 23.401.
For 5GS, support Multimedia Priority Service is described in TS 23.501.