Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU).

Many current clients attempt to meet the need for an instance-specific identifier by using explicit IP addresses in the values they provide in the Contact header field. However, this interacts poorly with NATs and firewalls, and as a practical matter, these URIs cannot be used by arbitrary external clients. The usage of hostnames has proven problematic for similar reasons. In addition, many SIP clients do not have or cannot obtain a hostname for themselves at all. The Globally Routable User Agent URI is a URI that is capable of reaching a particular contact.

The GRUUs assigned by the registrar represent an additional registration state. However, GRUUs assigned by the registrar are not included in the notifications for reg event

For many applications of the registration event package, a GRUU is needed, and not the registered contact.

A GRUU is a SIP URI that has two properties:

1. It routes to a specific UA instance.
2. It can be successfully de-referenced by any user agent on the Internet, not just ones in the same domain or IP network as the UA instance to which the GRUU points.

In principle, a GRUU can be constructed in any way the domain chooses, as long as it meets the criteria above. However, all GRUUs contain the “gr” URI parameter (either with or without a value), so that a recipient of a GRUU can tell that it has these two properties.

In practice, there are two different types of GRUUs:

1. GRUUs that expose the underlying AOR (AOR standing for address of record)
2. GRUUs that hide the underlying AOR

Example :

Consider a blind transfer application. User A is talking to user B. User A wants to transfer the call to user C. So, user A sends a REFER to user C. That REFER looks like, in part:

1. REFER sip:C@example.com SIP/2.0

1. From: sip: A@example.com;tag=99asd

1. To: sip:C@example.com

Refer-To: (URI that identifies B`s UA)

The Refer-To header field needs to contain a URI that can be used by user C to place a call to user B. However, this call needs to route to the specific UA instance that user B is using to talk to user A. If it doesn`t, the transfer service will not execute properly. For example, if A provides C with B`s AOR, the call might be routed to B`s voicemail rather than B`s current handset.

In order to enable this functionality, user B provides an instance-specific URI to user A in the Contact header of their SIP exchange. This URI refers to the user agent that B is currently using, and it can be de-referenced by C`s user agent. Because user B doesn`t know in advance who user A will transfer the call to, the URI has to be usable by anyone.

How to support in a UE:

The steps to implement:

1. UE will add the +sip.instance parameter of Contact of REGISTER with Instance Id.Parameter name=”+sip.instance” value=””<urn:gsm:imei:012541006775828>””
2. UE will add GRUU in the Supported header of REGISTER. Supported: gruu
3. UE will store the “pub-gruu” and “temp-gruu” obtained in the Contact header of 200 REGISTER. The contact header of 200-Register will look like:
   1. Contact: <sip:callee@192.0.2.1>

    

   1. 1. ;pub-gruu=”sip:callee@example.com
   1. 1. ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6″
   1. 1. ;temp-gruu=”sip:tgruu.7hs==
   1. 1. jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr”
   1. 1. ;+sip.instance=””
   1. 1. ;expires=3600

    

   </sip:callee@192.0.2.1>
4. Handling the GRUUs in UE obtained in the reginfo+xml of NOTIFY and passing the pub-gruu and temp-gruu associated with current contact and instance-idIf UA received NOTIFY request with Content-Type: application/reginfo+xml, and the message body is constructed with pub-gruu and temp-gruu associated with current contact address, then these need to be parsed and stored as mentioned in item 4. An example of the NOTIFY message body is as follows: 
5. UE will add pub-gruu/temp-gruu in the Contact header of INVITE, 18x/2xx INVITE response, SUBSCRIBE, 2xx response NOTIFY, REFER, UPDATE. (For anonymous calls temp-gruu is used).
6. A UA SHOULD use a GRUU when populating the Contact header field of dialog-forming and target refresh requests and responses. In other words, a UA SHOULD use one of its GRUUs as its remote target. This includes:
   1. The INVITE request
   2. A 2xx or 18x response to an INVITE which contains a To tag
   3. The SUBSCRIBE request
   4. A 2xx response to a SUBSCRIBE which contains a To tag
   5. The NOTIFY request
   6. The REFER request
   7. A 2xx response to NOTIFY
   8. The UPDATE request

References:

1. RFC 3680

1. RFC 5627

RFC 5628

Authors: Bidyut Maji and Anupam Bera