Page History

Overview

In SIP a single user can have a number of user agents (handsets, softphones, voicemail accounts, etc.) that are all referenced by the same AOR. The

A user agent can obtain a GRUU in one of several ways:

• as part of its REGISTER transaction.
• via some locally specified administrative mechanism.
• by constructing a self-made GRUU locally using the IP address or hostname of the user agent instance as the domain part of the URI. Self-made GRUUs are actual GRUUs only when constructed by UAs that know they are globally reachable using their IP address or hostname.

As per GRUU procedures, when the UE registers, UE is allocated a GRUU. The same GRUU is used as a Contact header in subsequent dialog-creating request messages. Registrar binds GRUU to AOR and instance. A GRUU is simply a URI; a UA dereferences it in exactly the same way as it would any other URI. The registrar/proxy maps the GRUU to the AOR and determines the set of contacts that the particular UA instance has registered. The GRUU is then mapped to those contacts and the request is routed towards the UA.

A UA that wants to obtain a GRUU via its REGISTER request does so by providing an instance ID in the "+sip.instance" Contact header field parameter. When a UA sends a REGISTER request, it includes Supported header field with “gruu” as one of the option tags. This signifies the registrar  that the UA supports the GRUU mechanism. For each contact, the UA includes a "sip.instance" media feature tag whose value will be the instance ID that identifies the UA instance being registered. When a REGISTER is received the registrar checks if there is already a valid public GRUU for the AOR (present in the To header field of the REGISTER request) and the instance ID (present as the content of the "+sip.instance" Contact header field parameter). If there is no valid public GRUU, the registrar constructs a public GRUU. While sending  2xx REGISTER response, Contact header field that contains the "+sip.instance" Contact header field parameter can contain a "pub-gruu" and "temp-gruu" Contact header field parameter. These header field parameters convey the public and a temporary GRUU for the UA instance.

GRUUs are distinguished from other URIs by the presence of a "gr" SIP URI parameter. There are two types of GRUUs; Public GRUUs (P‑GRUUs) and Temporary GRUUs (T‑GRUUs). The user agent uses one of its temporary GRUUs for anonymous calls and public GRUUs for other types of calls. Public GRUUs are distinguished from temporary GRUUs by the presence of a value for the "gr" SIP URI parameter.

Public GRUU

• P‑GRUUs are GRUUs that reveal the Public User Identity of the user and are very long lived. The  public GRUU persists across registrations
• The public GRUU is constructed by adding the "gr" URI parameter, with a value, to the  AOR. 

 Temporary GRUU

•  T‑GRUUs are GRUUs that contain a URI that do not reveal the Public User Identity of the user. The UA will receive a new temporary GRUU in each successful REGISTER response, while the public GRUU will typically be the same.
• The temporary GRUU will be valid for the duration of the registration (that is, through refreshes). Temporary GRUUs "accumulate" during the lifetime of a registration and valid until the contact is explicitly de-registered or the current registration expires

Example of public and temporary GRUU:

SBC Functionality Using GRUU

Overview

The

• Pass option-tag with GRUU in Supported header with in REGISTER.

• Pass option-tag with GRUU in Require header in  REGISTER.

• Pass received GRUU parameters in 200 OK response to REGISTER  (Enable

• passCompleteContactHeader transparency or

• contactHeader transparency)

The

• Pass the contact header transparently in 200 OK for INVITE, SUBSCRIBE, REFER if contact contains GRUU parameters

• Pass option-tag with GRUU in Supported header of INVITE, SUBSCRIBE, REFER, NOTIFY, MESSAGE, PUBLISH, OPTIONS and in their 2XX responses

• Pass GRUU parameters in the Notify message body

When

the

• Spacevars
  0 product

   as

• IBCF: When sending Locally generated BYE on both ingress and egress sides,

• the

  Spacevars
  0 product

   sends the Request-Uri with GRUU.

• Spacevars
  0 product

   as P-CSCF: The

  Spacevars
  0 product

   uses the Contact of the last REGISTER as the Request-URI for the BYE sent to the UE.

Registration Timeout

When a registered contact expires (either due to timeout or explicit de-registration), its binding to the AOR is removed. In addition, its binding to its GRUUs are removed at the same time. If, as a consequence of the expiration of the contact, a particular temporary GRUU no longer has any registered contacts bound to it, then GRUU is invalidated. All of the accumulated temporary GRUUs get invalidated once the last contact for a given instance ID expires.

On Registration timeout, if there is no contact bound to a Public GRUU, the registrar continues to treat the GRUU as valid. Subsequent requests targeted to the GRUU, prior to re-registration of a contact to the GRUU, return a 480 (Temporarily Unavailable) response. Since the GRUU remains valid, it is retained when a contact with that instance ID is once again registered to the AOR. When registrars forcefully shorten registration intervals, the registration event package is used by user agents to learn of these changes.

Refresh Registration

When a user agent refreshes registration prior to its expiration, the registrar returns back the same public GRUU but creates a new temporary GRUU. All of the temporary GRUUs learned from previous REGISTER responses during the lifetime of a contact remain valid as long as a contact with that instance ID remains registered and the UA does not change the Call-ID in its REGISTER request compared to previous ones. If any dialogs are in progress that utilize a temporary GRUU as a remote target, and a UA performs a registration refresh with a change in Call-ID the temporary GRUUs that were allocated earlier become invalid and the UA is not reachable for subsequent mid-dialog messages. If the Call-ID changes in a register refresh, the server invalidates all temporary GRUUs associated with that UA instance; the only valid one is the new one returned in that REGISTER response. The temporary GRUU is new, and is the only valid temporary GRUU for the instance until the next refresh. When the user agent later creates a new registration with the same instance ID, the public GRUU is the same. A non-2xx response to the REGISTER request has no impact on any existing GRUUs previously provided to the UA.

Multiple Registrations

In SIP networks, a user agent can have multiple AORs either in different domains or within the same domain. When UE supports outbound and the UA is utilizing multiple flows (for purposes of redundancy), the temporary GRUUs remain valid as long as at least one flow is registered. Thus, even if the registration of one flow expires, the temporary GRUUs learned previously remain valid. When the last contact for the instance expires either through explicit de-registration or timeout all of the temporary GRUUs become invalidated.

If the Call-ID changes in a register refresh, the server invalidates all temporary GRUUs associated with that UA instance. If RFC 5626 is in use, this rule applies to the reg-ids: If the Call-ID changes for the registration refresh for a particular reg-id, the server will invalidate all temporary GRUUs associated with that UA instance as a whole. The Registrar checks for any existing contacts registered to the same AOR instance ID. If the contact in the REGISTER request is registering a flow (reg-id), and if there is at least one contact, the registrar finds the one that was most recently registered and examines the Call-ID value associated with that registered contact. If it differs from the one in the REGISTER request, the registrar invalidates all previously generated temporary GRUUs for the AOR, instance ID. Registrar creates a new temporary GRUU for the AOR and instance ID. Every GRUU is associated with a single AOR and a single instance ID. While the AOR resolves to all registered contacts for an AOR, a GRUU resolves only to those contacts whose instance ID matches the one associated with the GRUU. For this reason, a contact with an instance ID is always bound to both a GRUU and its AOR

Call Establishment

Once a user agent obtains GRUUs from the registrar, it uses them as the contents of the Contact header field in non-REGISTER requests and responses. The user and host parts of the GRUU learned by the UA in the REGISTER response will be treated opaquely by the UA.

• A UA does not modify or remove URI parameters it does not recognize.
• The UA does not add, remove, or modify URI parameters relevant for receipt and processing of request at the proxy, including the transport, lr, maddr, ttl, user, and comp URI parameters.
• A UA uses  GRUU when populating the Contact header field of dialog-forming and target refresh requests and responses. The UA MAY use either the public or one of its temporary GRUUs provided by its registrar.
• When a UA sends a request, the request will be sent using one of its AORs.  The GRUU placed into the Contact header field of a request is associated with the AOR used to send the request.  If the UA uses a tel URI, there would be a SIP AOR that is treated as an alias for the tel URI. 
• The GRUU associated with that SIP AOR is used in the Contact header field. When a UA receives a request, the GRUU placed into the Contact header field of a 2xx response is associated with the AOR or GRUU to which the request was most recently targeted.
• If

• the

  Spacevars
  0 product

   is acting as Access

• Spacevars
  0 product

  , and If the Contact header field in the INVITE request contains a GRUU but does not include an "ob" SIP URI parameter,

• the

  Spacevars
  0 product

   saves the GRUU received in the Contact header field of the request and associates that GRUU with the UE IP address and the UE port such that the

• Spacevars
  0 product

   is able to release the session, if needed.

SBC Initiated Termination

Access Trunk

If the

The

• The

  Spacevars
  0 product

   generates a BYE request sends Request towards core/peer, a Request-URI, set to the stored Contact header field.

• The

  Spacevars
  0 product

   sends

• the BYE request to the stored Route.

IMS Deployment

In an IMS deployment, public user identities are used to reach the recipient and single public user identity can be shared among a number of devices under single subscription. It is not possible to identify a specific device when more than one device has been registered with the same public user identity. A Globally Routable User Agent URI (GRUU) is an identity that identifies a unique combination of Public User Identity and UE instance that allows a UE to address a SIP request to a specific Public User Identity UE combination instance.

The S-CSCF provides a service of assigning and translating GRUUs for use by registered UEs. Each assigned GRUU represents an association between a public user identity and an instance ID provided by a registering UE. It is used to address a particular UE that possesses the instance ID and registers with the public user identity. The GRUU also denotes a contact address registered with a public user identity when the contact address has a "+sip.instance" header field parameter containing the GRUU instance ID. The S-CSCF issues GRUUs as part of the registration process, and also reports GRUUs as part of notifications for subscriptions to the "reg" event package.

If a UE supports GRUU, it indicates support for a GRUU that is associated with a specific Public User Identity at the time of registration of the Public User Identity. The UE uses the same instance ID for all registration requests regardless of the access network used for registration. When the S-CSCF receives indication of GRUU support for a specific Public User Identity from the UE during a registration request, it also generates P‑GRUU's and T‑GRUU's for all implicitly registered Public User Identities belonging to the same implicit registration set. The IMS network communicates all these other GRUUs to the UE.

The S-CSCF always issues GRUUs in pairs – a public GRUU and a temporary GRUU. In case of implicit registration the S-CSCF assigns a unique public GRUU and a unique temporary GRUU for each public user identity. The "gr" SIP URI parameter serves as an indicator that the URI is in fact a GRUU. The public GRUU for a particular association of public user identity and instance ID is persistent. The same public GRUU will be returned each time a registration is performed with a particular pair of public user identity and instance ID.

The lifetime of a temporary GRUU is limited, hence the S-CSCF only understands how to translate temporary GRUU to the corresponding public user identity and instance ID. The S-CSCF can recognize a public GRUU as valid if the derived instance ID is a syntactically correct URN and the derived public user identity compares equal, according to the comparison rules of RFC3261, to a public user identity active within the S-CSCF. The public user identity and instance ID are derived from a temporary GRUU via implementation specific means consistent with the way temporary GRUUs are constructed.

If a UE registers (explicitly or implicitly) with multiple Public User Identities, a separate GRUU set is associated with each. If different UEs register with the same Public User Identity, a different GRUU set is associated with each. The IMS network generates the same P‑GRUU for a given Public User Identity and Instance Identifier combination. The IMS network generates a different T‑GRUU for a given Public User Identity and Instance Identifier combination for each registration and re-registration.

In an IMS deployment, the SBC provides the following functionality:

• When GRUU is generated by SCSCF and used by UE, the SBC transparently passes the received parameters in 2xx response of REGISTER to the UE if passCompleteContactHeader transparency flag is enabled on both Ingress and Egress trunk group (

• refer to Transparency Flags - CLI).
  
  
• For dialog creating INVITE/SUBSCRIBE or OOD request, the SBC is able to transparently pass the GRUU received in the contact header from UE to the core.
  
  
• OOD dialog REFER is relayed to the core using Stored/Received route set. Hence no special processing is done at SBC (Refer-To containing GRUU is transparently passed since Refer is being Relayed)
  
  
• P-Called-Party-Id support