Obtaining and Using Globally
Routable User Agent (UA) URIs (GRUU) in the Session Initiation
Protocol (SIP)CiscoEdisonNJUSjdrosen@cisco.comhttp://www.jdrosen.net
RAI
SIPSeveral 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). This document describes an
extension to SIP for obtaining a GRUU from a registrar and for
communicating a GRUU to a peer within a dialog.In the Session Initiation Protocol (SIP), RFC 3261 , the basic unit of reference is the
Address-Of-Record (AOR). However, in SIP systems a single user can
have a number of user agents (handsets, softphones, voicemail
accounts, etc.) which are all referenced by the same AOR. There are a
number of contexts in which it is desirable to have an identifier
which addresses a single user agent rather than the group of user
agents indicated by an AOR.
As an example, consider a blind transfer application (see
draft-ietf-sipping-cc-transfer ). 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:
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 voice mail 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 only the user agent B is currently using
and can be provided to user C. Because user B doesn't know in advance
who user A will transfer the call to, the URI has to be usable by
anyone.
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. Similarly, 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.
This specification describes a mechanism for providing a unique
user-agent identifier which is still globally routable. This
identifier is called a Globally Routable User Agent (UA) URI
(GRUU).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119.
This specification defines the following additional terms:
The term "contact", when used in all
lowercase, refers to a URI that is bound to an AOR and GRUU by
means of a registration. A contact is usually a SIP URI, and
is bound to the AOR and GRUU through a REGISTER request by
appearing as a value of the Contact header field. The contact URI
identifies a specific UA.
The term "remote target" refers
to a URI that a user agent uses to identify itself for receipt
of both mid-dialog and out-of-dialog requests. A remote target
is established by placing a URI in the Contact header field of
a dialog-forming request or response and updated by target
refresh requests or responses. The term "Contact header
field", with a capitalized C, refers to the header field which
can appear in REGISTER requests and responses, redirects, or
in dialog-creating requests and responses. Depending on the
semantics, the Contact header field sometimes conveys a
contact, and sometimes conveys a remote target.
The basic idea behind a GRUU is simple. GRUUs are issued by SIP
domains and always route back to a proxy in that domain. The domain in turn
maintains the binding between the GRUU and the particular UA
instance. When a GRUU is de-referenced when sending a SIP request,
that request arrives at the proxy. It maps the GRUU to the contact for
the particular UA instance, and sends the request there.
A GRUU is a SIP URI that has two properties:
It routes to a specific UA instance.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:
GRUUs which expose the underlying AORGRUUs which hide the underlying AORIn many cases it is desirable to construct the GRUU in such
a way that the mapping to the AOR is apparent. For example, many user
agents retain call logs, which keep track of incoming and outgoing
call attempts. If the UA had made a call to a GRUU (perhaps as a
consequence of a transfer request), the call log will contain the
GRUU. Since the call log is rendered to the user, it would be useful
to be able to present the user with the AOR instead, since the AOR is
meaningful to users as an identifier.
This type of GRUU is called a public GRUU. It is constructed by taking
the AOR, and adding the "gr" URI parameter with a value chosen by the
registrar in the domain. The value of the "gr" URI parameter contains a
representation of the UA instance. For instance, if the AOR was
"sip:alice@example.com", the GRUU might be:
If a UA removes the "gr" URI parameter, the result is the AOR. Since many
systems ignore unknown parameters anyway, a public GRUU will "look"
like the AOR to those systems.
In other cases it is desirable to construct a GRUU that obfuscates the
AOR such that it cannot be extracted by a recipient of the GRUU.
Such a GRUU is called a temporary GRUU. The most
obvious reason to do this is to protect the
user's privacy. In such cases, the GRUU can have any content provided
that it meets the requirements in and
, and
the AOR cannot be readily determined from the GRUU. The GRUU will have
the "gr" URI parameter, either with or without a value. In
order to avoid
creating excessive state in the registrar, it is often desirable to
construct cryptographically protected "stateless" GRUUs using an
algorithm like that described in Appendix A.
An example of a temporary GRUU constructed using a stateful algorithm
would be:
A User Agent can obtain a GRUU in one of several ways:
As part of its REGISTER transaction.By constructing one locally, using the IP address or hostname of
the user agent instance as the domain part of the URI. These are
called self-made GRUUs, and are only really GRUUs when constructed by UA
that know they are globally reachable using their IP address or
hostname.
Via some locally-specified Administrative mechanism.A UA which wants to obtain a GRUU via its REGISTER request does so
by providing an instance ID in the "+sip.instance" Contact header
field parameter, defined in draft-ietf-sip-outbound . For
example:
The registrar detects this header field parameter and provides two
GRUUs in the
REGISTER response. One of these is a temporary GRUU, and the other is
the public GRUU. These two GRUUs are returned in the "temp-gruu"
and "pub-gruu" Contact header field parameters in the response,
respectively. For example:
When a user agent refreshes this registration prior to its expiration,
the registrar will return back the same public GRUU, but will create a
new temporary GRUU. Despite the fact that each refresh provides the UA
with 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 (1) that contact remains registered, and (2) the UA
doesn't change the Call-ID in its REGISTER request compared to
previous ones. When the contact expires, either through explicit
de-registration or timeout, all of the temporary GRUUs be
invalidated. Similarly, if a register refresh changes the Call-ID
compared to previous register refreshes, all of the previous temporary
GRUUs are invalidated. When the user agent later creates a new
registration with the same instance ID, the public GRUU is the
same. The temporary GRUU will be new (as it is with refreshes), and it
will be the only valid temporary GRUU for the instance until the next
refresh, at which point a second one becomes valid too. Consequently,
temporary GRUUs "accumulate" during the lifetime of a registration.
Once a user agent obtains GRUUs from the registrar, it uses
them in several ways. First, it uses them as the contents of the
Contact header field in non-REGISTER requests and responses that it
emits (for example, an INVITE request and 200 OK response). According
to RFC 3261 , the Contact header field is supposed to
contain a URI that routes to that user agent. Prior to this
specification, there hasn't been a way to really meet that
requirement. The user agent would use one of its temporary GRUUs for
anonymous calls, and use its public GRUU otherwise.
Second, the UA can use the GRUU in any other place it needs to
use a URI that resolves to itself, such as a webpage.
Because a GRUU is simply a URI, a UA dereferences it in exactly
the same way as it would any other URI. However, once the request
has been routed to the appropriate proxy, the behavior is slightly
different. The proxy will map the GRUU to the AOR and determine 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.
This section defines the normative behavior for user agents.
When a UA compliant to this specification generates a REGISTER request
(initial or refresh), it MUST include the Supported header field in
the request. The value of that header field MUST include "gruu" as one
of the option tags. This alerts the registrar for the domain that the
UA supports the GRUU mechanism.
Furthermore, for each contact for which the UA desires to obtain a
GRUU, the UA MUST include a "sip.instance" media feature tag (see
draft-ietf-sip-outbound ) as a
UA characteristic (see ), whose value MUST be
the instance ID that
identifies the UA instance being registered. Each such Contact header
field SHOULD NOT contain a "pub-gruu" or "temp-gruu" header field. The
contact URI MUST NOT be equivalent, based on the URI equality rules in
RFC 3261 , to the AOR in the To header field. If the contact URI is a
GRUU, it MUST NOT be a GRUU for the AOR in the To header field.
As in RFC 3261 , the Call-ID in a REGISTER
refresh SHOULD be identical
to the Call-ID used to previously register a contact. With GRUU, an
additional consideration applies. If the Call-ID changes in a register
refresh, the server will invalidate all temp-gruu associated with that
UA instance; the only valid one will be the new one returned in that
REGISTER response. Consequently, if a UA wishes its previously obtained
temporary GRUUs to remain valid, it MUST utilize the same Call-ID in
REGISTER refreshes. However, it MAY change the Call-ID in a refresh if
invalidation is the desired objective.
Note that, 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, those temporary GRUU
become invalid, and the UA will not be reachable for subsequent
mid-dialog messages.
If a UA instance is trying to register multiple contacts for the same
instance for the purposes of redundancy, it MUST use the procedures
defined in draft-ietf-sip-outbound .
A UA utilizing GRUUs can still perform third party registrations and
can include contacts which omit the "+sip.instance" Contact header
field parameter.
If a UA wishes to guarantee that the REGISTER request is not processed unless
the domain supports and uses this extension, it MAY include a Require
header field in the request with a value that contains the "gruu"
option tag. This is in addition to the presence of the Supported
header field also containing the "gruu" option tag. The use of
Proxy-Require is not necessary and is NOT RECOMMENDED.
If the REGISTER response is a 2xx, each Contact header field that
contains the "+sip.instance" Contact header field parameter can also
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, respectively. A UA MUST be prepared for a Contact
header field to contain just a "pub-gruu", just a "temp-gruu",
neither, or both. The temporary GRUU will be valid for the duration of
the registration (that is, through refreshes) , while the public GRUU
persists across registrations. The UA will receive a new temporary
GRUU in each successful REGISTER response, while the public GRUU will
typically be the same. However, a UA MUST be prepared for the public
GRUU to change from a previous one, since the persistence property is
not guaranteed with complete certainty. If a UA changed its Call-ID in
this REGISTER request compared to a previous REGISTER request for the
same contact, the UA MUST discard all temporary GRUU learned through
prior REGISTER responses. A UA MAY retain zero, one, some, or all of
the temporary GRUUs that it is provided during the time over which its
contact remains registered. If a UA stores any temporary GRUUs for use
during its registration, it needs to be certain that the registration
does not accidentally lapse due to clock skew between the UA and
registrar. Consequently, the UA MUST refresh its registration such
that the REGISTER refresh transaction will either complete or timeout
prior to the expiration of the registration. For default transaction
timers, this would be at least 32 seconds prior to expiration, assuming the
registration expiration is larger than 64 seconds. If the registration
expiration is less than 64 seconds, the UA SHOULD refresh its
registration halfway prior to expiration.
In cases where registrars forcefully shorten
registration intervals, the registration event package, RFC 3860 is used by user agents to learn of these changes. A
user agent implementing both RFC 3680 and
GRUU MUST also implement the
extensions to RFC 3680 for conveying
information on GRUU, as defined in draft-ietf-sipping-reg-event , as these are necessary to
keep the set of temporary GRUU synchronized between the UA and the
registrar. More generally, the utility of temporary GRUU depends on
the UA and registrar being in sync on the set of valid temporary GRUU
at any time. Without support of RFC 3680 and
its extension for GRUU,
the client will remain in sync only as long as it always re-registers
well before the registration expiration. Besides forceful
de-registrations, other events, such as network outages, connection
failures, and short refresh intervals, can lead to potential
inconsistencies about the set of valid temporary GRUU. For this
reason, it is RECOMMENDED that a UA that utilizes temporary GRUU
implement RFC 3680 and
draft-ietf-sipping-gruu-reg-event .
A non-2xx response to the REGISTER request has no impact on any
existing GRUUs previously provided to the UA. Specifically, if a
previously successful REGISTER request provided the UA with a GRUU, a
subsequent failed request does not remove, delete, or otherwise
invalidate the GRUU.
The user and host parts of the GRUU learned by the UA in the REGISTER response
MUST be treated opaquely by the UA. That is, the UA MUST NOT modify them
in any way. A UA MUST NOT modify or remove URI parameters it does not
recognize. Furthermore, the UA MUST 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 (see RFC 3486 )
URI parameters. The other URI parameter defined in RFC 3261 - method, would
not typically be present in a GRUU delivered from a registrar, and a
UA MAY add a method URI parameter to the GRUU before handing it out to
another entity. Similarly, the URI parameters defined in RFC 4240 and RFC 4458 are meant for
consumption by the UA. These would not be included in the GRUU
returned by a registrar and MAY be added by a UA wishing to provide
services associated with those URI parameters.
Note, however, that should
another UA dereference the GRUU, the parameters will be lost at the
proxy when the Request-URI is translated into the registered contact,
unless some other means is provided for the attributes to be delivered
to the UA. Mechanisms for such delivery are currently the subject of
future standardization activity (see
draft-rosenberg-sip-ua-loose-route ).
Many user agents, such as gateways to the Public Switched Telephone
Network (PSTN), conferencing servers and media servers, do not perform
registrations, and cannot obtain GRUUs through that mechanism. These
types of user agents can be publicly reachable. This would mean that
the policy of the domain is that requests can come from anywhere on
the public Internet and be delivered to the user agent without
requiring processing by intervening proxies within the
domain. Furthermore, firewall and NAT policies administered by the
domain would allow such requests into the network. When a user agent
is certain that these conditions are met, a UA MAY construct a
self-made GRUU. Of course, a user agent which does REGISTER, but for
whom these conditions are met regardless, MAY also construct a
self-made GRUU. However, usage of GRUUs obtained by the registrar is
RECOMMENDED instead.
A self-made GRUU is one whose domain part equals the IP address or
hostname of the user agent. The user part of the SIP URI is chosen
arbitrarily by the user agent. Like all other GRUUs, the URI MUST
contain the "gr" URI parameter, with or without a value, indicating it
is a GRUU.
If a user agent does not register, but it is not publicly reachable,
it would need to obtain a GRUU through some other means. Typically,
the UA would be configured with a GRUU, and the GRUU would also be
configured into the proxy which will receive requests targeted to the
GRUU, along with a static mapping to the IP address and port of the
UA.
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 compliant to this specification SHOULD use one of its
GRUUs as its remote target. This includes the INVITE request, its 2xx
response or 18x response with a To tag, the SUBSCRIBE request (see
), its 2xx response with a To tag, the NOTIFY
request, the REFER request (see ), its 2xx
response, and the UPDATE request and its 2xx response. The only reason
not to use a GRUU would be privacy considerations; see .
When using a GRUU obtained through registrations, a UA MUST have an
active registration prior to using a GRUU, and MUST use a GRUU learned
through that registration. It MUST NOT reuse a GRUU learned through a
previous registration which has lapsed (in other words, one obtained
when registering a contact which has expired). The UA MAY use either
the public or one of its temporary GRUUs provided by its registrar. A
UA MUST NOT use a temporary GRUU learned in a REGISTER response whose
Call-ID differs from the one in the most recent REGISTER request
generated by the UA for the same AOR and instance ID. When
a UA wishes to construct an anonymous request as described in RFC 3323
, it SHOULD use a temporary GRUU. See for a more complete discussion on the level of
privacy afforded by temporary GRUUs.
As per RFC 3261 , a UA SHOULD include a
Supported header with the
option tag "gruu" in requests and responses it generates.
In some SIP networks, a user agent can have a multiplicity of AOR,
either in different domains, or within the same domain. In such cases,
additional considerations apply.
When a UA sends a request, the request will be sent 'using' one of its
AOR. This AOR will typically show up in the From header field of the
request, and credentials unique to that AOR will be used to
authenticate the request. The GRUU placed into the Contact header
field of such a request SHOULD be one that is associated with the AOR
used to send the request. In cases where the UA uses a tel URI (as
defiend in ) to
populate the From header field, the UA typically has a SIP AOR that is
treated as an alias for the tel URI. The GRUU associated with that SIP
AOR SHOULD be used in the Contact header field.
When a UA receives a request, the GRUU placed into the Contact header
field of a 2xx response SHOULD be the one associated with the AOR or
GRUU to which the request was most recently targeted. There are
several ways to determine the AOR or GRUU to which a request was
sent. For example, if a UA registered a different contact to each AOR
(by using a different user part of the URI), the Request-URI (which
contains that contact) will indicate the AOR.
A GRUU is identified by the presence of the "gr" URI parameter, and
this URI parameter might or might not have a value. A
UA that wishes to send a request to a URI that contains a GRUU knows
that the request will be delivered to a specific UA instance without
further action on the part of the requestor.
Some UAs implement non-standard mechanisms for handling
URIs that compensate for the fact that heretofore many
contact URIs have not been globally routable. Since
any URI containing the "gr" URI parameter is known to be
globally routable, a UA SHOULD NOT apply such
mechanisms when contact URI contain the "gr" URI parameter.
Because the instance ID is a callee
capabilities parameter, a UA might be tempted to send a request to the
AOR of a user, and include an Accept-Contact header field (defined in
) that indicates a preference for routing the
request to a UA with a specific instance ID. Although this would
appear to have the same effect as sending a request to the GRUU, it
does not. The caller preferences expressed in the Accept-Contact
header field are just preferences. Their efficacy depends on a UA
constructing an Accept-Contact header field that interacts with
domain-processing logic for an AOR, to cause a request to route to a
particular instance. Given the variability in routing logic in a
domain (for example, time-based routing to only selected contacts),
this doesn't work for many domain-routing policies. However, this
specification does not forbid a client from attempting such a request,
as there can be cases where the desired operation truly is a
preferential routing request.
When rendering a GRUU to a user through a user interface, it is
RECOMMENDED that the "gr" URI parameter be removed. For public GRUUs, this
will produce the AOR, as desired. For temporary GRUUs, the resulting
URI will be seemingly random. Future work might provide improved
mechanisms that would allow an automaton to know that a URI is
anonymized and therefore inappropriate to render.
A REGISTER request might contain a Require header field with the
"gruu" option tag; this indicates that the registrar has to
understand this extension in order to process the request. It does not
require the registrar to create GRUUs, however.
As the registrar is processing the contacts in the REGISTER
request according to the procedures of step 7 in Section 10.3 of RFC
3261 , the registrar checks whether each Contact header field in the
REGISTER message contains a "+sip.instance" header field parameter. If
present with a non-zero expiration, the contact is processed further
based on the rules in the remainder of this section. Otherwise, the
contact is processed based on normal RFC 3261 rules.
Note that handling of a REGISTER request
containing a Contact header field with value "*" and an expiration of
0 still retains the meaning defined in RFC 3261 -- all contacts, not
just those with a specific instance ID, are deleted. As described in
, this removes the
binding of each contact to the AOR and the binding of each contact to
its GRUUs.
If the contact URI is
equivalent (based on URI equivalence in RFC 3261 ) to the AOR, the
registrar MUST reject the request with a 403, since this would cause a
routing loop. If the contact URI is a GRUU for the AOR in the To
header field of the REGISTER request, the registrar MUST reject the
request with a 403, for the same reason. If the contact is not a SIP
URI, the REGISTER request MUST be rejected with a 403.
Next, 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 SHOULD construct a public GRUU at this time according to the
procedures of . The public GRUU MUST be
constructed by adding the "gr" URI parameter, with a value, to the AOR. If the
contact contained a "pub-gruu" Contact header field parameter, the
header field parameter MUST be ignored by the registrar. A UA cannot
suggest or otherwise provide a public GRUU to the registrar.
Next, the registrar checks for any existing contacts registered to the
AOR and instance ID. If there is at least one, 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 MUST invalidate all previously
generated temporary GRUU for the AOR and instance ID. A consequence of this
invalidation is that requests addressed to those GRUU will be rejected by
the domain with a 404 from this point forward.
Next, the registrar SHOULD create a new temporary GRUU for the AOR and
instance ID with the characteristics described in . The temporary GRUU construction algorithm
MUST have the following two properties:
The likelihood that the temporary GRUU is equal to another GRUU
which the registrar has created MUST be vanishingly small.
Given a pair of GRUUs, it MUST be computationally infeasible to determine
whether they were issued for the same AOR or instance ID or
different AORs and instance IDs.
If the contact contained
a "temp-gruu" Contact header field parameter, the header field
parameter MUST be ignored by
the registrar. A UA cannot suggest or otherwise provide a temporary GRUU
to the registrar.
When generating the 200 (OK) response to the REGISTER request, the
procedures of step 8 of Section 10.3 of RFC 3261 are
followed. Furthermore, for each Contact header field value placed in
the response, if the registrar has stored an instance ID associated
with that contact, that instance ID is returned as a Contact header
field parameter. If the REGISTER request contained a Supported header
field that included the "gruu" option tag, and the registrar has at least
one temporary GRUU assigned to the instance ID and AOR, the registrar
MUST add an
"temp-gruu" Contact header field parameter to that Contact header
field. The value of the "temp-gruu" parameter is a quoted string, and
MUST contain the mostly recently created temporary GRUU for that AOR
and instance ID. In addition, if the registrar has a
public GRUU assigned to the instance ID and AOR (and the client
supports GRUUs), the registrar MUST add a "pub-gruu" Contact header field
parameter to that Contact header field. The value of the "pub-gruu"
Contact header field parameter is the public GRUU.
The registrar SHOULD NOT include the "gruu" option tag in the Require
or Supported header field of the response.
When a registered contact expires (either due to timeout or explicit
de-registration), its binding to the AOR is removed
as usual. In addition, its binding to its GRUUs are removed at the same
time as a consequence of the relationships described in
If, as a consequence of the expiration of the contact, a particular
GRUU no longer has any registered contacts bound to it, and the GRUU is a
temporary GRUU, the GRUU MUST be invalidated. This means that all of the
accumulated temporary GRUUs get invalidated once the last contact for a
given instance ID expires.
If, however, the GRUU
was a public GRUU, the registrar SHOULD continue to treat the GRUU as
valid. Consequently, subsequent requests targeted to the GRUU, prior
to re-registration of a contact to the GRUU, SHOULD return a 480
(Temporarily Unavailable) response. In
addition, since the GRUU remains valid, the rules in will cause it to be retained when a contact
with that instance ID is once again registered to the AOR.
These rules give a public GRUU a
semi-permanent property. The intent is that the registrar make every
attempt to retain validity of the GRUU for as long as the AOR itself
is known within the domain. The requirements for doing so are at
SHOULD strength and not MUST strength because of the difficulty in
meeting a MUST strength requirement; registrar failures could cause the
set of valid GRUUs to be lost and this specification requires the UA to
be robust against such cases. That said, it is possible for a public GRUU to
be constructed such that a registrar does not need to retain any
additional state for it, yet the GRUU still meets the requirements
described here.
This section defines additional behaviors associated with the
construction and maintenance of a GRUU which are specific to a
registrar. These rules do not apply to self-made GRUU or GRUU not
obtained through registrations.
When a registrar creates a GRUU, it is required to maintain certain
information associated with the GRUU, regardless of whether it is a
public or temporary GRUU. Every GRUU is associated with a single AOR
and a single instance ID. A registrar MUST be able to determine the
instance ID and AOR when presented with a GRUU. In addition, the GRUU,
like an AOR, resolves to zero or more contacts. 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, never just an AOR or just a GRUU. This is
shown pictorially in . The figure shows
three contacts registered to a single AOR. One of the contacts has an
instance ID of 1, and the other two have an instance ID of 2. There
are two GRUUs for this AOR. One is associated with instance ID 1, and
the other with instance ID 2. The first GRUU resolves only to contacts
whose instance ID is one, and the second resolves only to contacts
whose instance ID is two. There will typically be multiple contacts
for a given instance ID if a UA has crashed, rebooted and
re-registered with the same instance ID, or is using the mechanisms of
draft-ietf-sip-outbound to have multiple registrations
for redundancy. If the contact for instance ID 1 expires, the AOR
would resolve to two contacts, but the GRUU associated
with instance ID 1 would resolve to zero.
There can be multiple GRUUs with the same instance ID and
AOR. Indeed, this specification requires registrars to maintain many -
one that is public, and several that are temporary. However, if two GRUUs
are associated with different AOR or different instance IDs or both,
the GRUUs MUST be different based on URI equality comparison. A GRUU in
a domain MUST NOT be equivalent, based on URI comparison, to any AOR
in a domain except for the one associated with the GRUU.
A public GRUU will always be equivalent to the AOR based on URI
equality rules. The reason is that the rules in RFC 3261 cause URI
parameters that are in one URI, but not in the other, to be ignored
for equality purposes. Since a public GRUU differs from an AOR only by
the presence of the "gr" URI parameter, the two URI are equivalent
based on those rules.
Once a temporary GRUU is constructed, it MUST be considered valid by
the registrar until invalidated based on the rules described
previously. Once a public GRUU is constructed, it MUST be
considered valid for the duration that the AOR itself is valid. Once
an AOR is no longer valid within a domain, any of its GRUU MUST be
considered invalid as well.
This specification does not mandate a particular
mechanism for construction of the GRUU. Example algorithms for public
and temporary GRUU that work well are given in . However,
in addition to the properties described in , a GRUU constructed by a registrar MUST
exhibit the following properties:
The domain part of the URI is an IP address present on the public
Internet, or, if it is a host name, the resolution procedures of RFC
3263 , once applied, result in an IP address
on the public Internet. When a request is sent to the GRUU, it routes to a
proxy that can access the registration data generated by the
registrar. Such a proxy is called a authoritative proxy, defined in
draft-ietf-sip-outbound .
RFC 3680 defines an event package that allows
a client to learn about registration events at the registrar. This
package allows registrars to alter registrations forcefully (for
example, shortening them to force a re-registration). If a registrar is
supporting RFC 3680 and GRUU, it MUST also
support draft-ietf-sipping-gruu-reg-event .
Proxy behavior is fully defined in Section 16 of RFC 3261 . GRUU processing impacts that processing in two
places -- request targeting at the authoritative proxy and record routing.
When a proxy receives a request, owns the domain in the
Request-URI, and is supposed to access a Location Service in order to
compute request targets (as specified in Section 16.5 of RFC 3261), the proxy examines the
Request-URI. If it contains the "gr" URI parameter but is not
equivalent, based on URI comparison, to a currently valid GRUU within
the domain, it SHOULD be rejected with a 404 (Not Found) response;
this is the same
behavior a proxy would exhibit for any other URI within the domain
that is not valid.
If the Request-URI contains a the "gr" URI parameter and is
equivalent, based on URI comparison, to a GRUU which is currently
valid within the domain, processing proceeds as it would for any other
URI present in the location service, as defined in Section 16.5 of RFC
3261 , except that the "gr" URI parameter is
not removed as part of the
canonicalization process. This is the case for both out-of-dialog
requests targeted to the GRUU, and mid-dialog requests targeted to the
GRUU (in which case the incoming request would have a Route header
field value containing the URI that the proxy Record-Routed
with).Note that the "gr" URI parameter is retained just for the purposes
of finding the GRUU in the location service; If a match is found, the
Request-URI will be rewritten with the registered contacts, replacing
the GRUU and its "gr" URI parameter. The "gr" URI parameter is not carried
forward into the rewritten Request-URI.
If there are no registered contacts bound to the GRUU, the server MUST
return a 480 (Temporarily Unavailable) response. If there are more
than one, there are two cases:
The client is using draft-ietf-sip-outbound and registering multiple contacts for
redundancy. In that case, these contacts contain reg-id Contact header
field parameters, and the rules
described in Section 7 of draft-ietf-sip-outbound for selecting a
single registered contact apply. The client was not using SIP outbound, in which case there would
only be multiple contacts with the same instance ID if the client had
rebooted, restarted and re-registered. In this case, these contacts
would not contain the reg-id Contact header field parameter. The proxy
MUST select the most recently refreshed contact. As with
draft-ietf-sip-outbound, if a request to this target fails with a 408
(Request Timeout) or 430 (Flow Failed) response, the proxy SHOULD
retry with the next most recently refreshed contact. Furthermore, if
the request fails with any other response, the proxy MUST NOT retry on
any other contacts for this instance.
Any caller preferences in the request
(as defined in RFC 3841 ) SHOULD be processed
against the contacts bound to the GRUU.
In essence, to select a registered contact, the GRUU is processed just
like it was the AOR, but with only a subset of the contacts bound to
the AOR.
Special considerations apply to processing of any Path headers stored
in the registration (see RFC 3327 ). If the
received request has Route header field values beyond the one pointing
to the authoritative proxy itself (this will happen when the request
is a mid-dialog request), the Path URI MUST be discarded. This is
permitted by RFC 3327 as a matter of local
policy; usage of GRUUs will
require this policy in order to avoid call spirals and likely call
failures.
A proxy MAY apply other processing to the request, such as execution
of called party features, as it might do for requests targeted to an
AOR. For requests that are outside of a dialog, it is RECOMMENDED to
apply screening types of functions, both automated (such as black and
white list screening) and interactive (such as interactive voice
response (IVR) applications that confer with the user to determine
whether to accept a call). In many cases, the new request is related
to an existing dialog, and might be an attempt to join it (using the
Join header field defined in RFC 3911 ) or
replace it (using the
Replaces header field defined in RFC 3891 ). In such cases, the UA
will typically make its own authorization decisions. In such cases,
bypassing screening services might make sense, but it needs to be
carefully considered by network designers, as it depends on the
specific type of screening service.
However, forwarding services, such as call forwarding, SHOULD NOT
be provided for requests sent to a GRUU. The intent of the GRUU is to
target a specific UA instance, and this is incompatible with
forwarding operations.
If the request is a mid-dialog request, a proxy SHOULD only
apply services that are meaningful for mid-dialog requests, generally
speaking. This excludes screening functions, as well as forwarding
ones.
In addition, a request sent to a GRUU SHOULD NOT be redirected. In
many instances, a GRUU is used by a UA in order to assist in the
traversal of NATs and firewalls, and a redirection might prevent such a
case from working.
There are two distinct requirements for record-routing
- in the originating domain and in the terminating
domain. These requirements avoid unnecessary and possibly problematic
spirals of requests.
If:
an originating authoritative proxy receives a dialog-forming
request,AND the Contact header field contains a GRUU in the domain of the
proxy,AND that GRUU is a valid one in the domain of the proxy, AND that GRUU is associated with the AOR matching the authenticated
identity of the requestor (assuming such authentication has been
performed),AND the request contains Record-Route header fields,
then the authoritative proxy MUST record route. If all of these
conditions is true, except that the GRUU is associated with an AOR
which did not match the authenticated identity of the requestor, it is
RECOMMENDED that the proxy reject the request with a 403 (Forbidden)
response.
If:
a terminating authoritative proxy receives a dialog-forming
request, AND the Request-URI contains a URI in the location service (either a GRUU or
an AOR), AND the contact selected for sending the request has an
instance ID and is bound to a GRUU, AND the registration contain Path URI, then the authoritative proxy MUST record route.
If a proxy in either the originating or terminating domains but is
not an authoritative proxy, the proxy MAY record route.
If a proxy in the terminating domain requires mid-dialog requests
to pass through it for whatever reason (firewall traversal,
accounting, etc.), the proxy MUST still record route, and MUST NOT
assume that a UA will utilize its GRUU in the Contact header field of
its response (which would cause mid-dialog requests to pass through
the proxy without record-routing).
Implementors should note that, if a UA uses a GRUU in its contact, and
a proxy inserted itself into the Path header field of a
registration, that proxy will be receiving mid-dialog requests
regardless of whether it record routes or not. The only distinction is
what URI the proxy will see in the topmost Route header field of
mid-dialog requests. If the proxy record-routes, it will see that
URI. If it does not, it will see the Path URI it inserted.
This specification defines two new Contact header field parameters
("temp-gruu" and "pub-gruu") by extending the grammar for
"contact-params" as defined in RFC 3261 . It also defines a new SIP
URI parameter ("gr") by extending the grammar
for "uri-parameter" as defined in RFC 3261 .
The quoted strings for temp-gruu and pub-gruu MUST contain a
SIP URI. However, they are encoded like all other quoted strings and
can therefore contain quoted-pair escapes when represented this way.
This specification was created in order to meet the following
requirements:
When a UA invokes a GRUU, it must cause the
request to be routed to the specific UA instance to which the GRUU
refers.
It must be possible for a GRUU to be invoked from
anywhere on the Internet, and still cause the request to be routed
appropriately. That is, a GRUU must not be restricted to use within a
specific addressing realm.
It must be possible for a GRUU to be constructed
without requiring the network to store additional state.
It must be possible for a UA to obtain a
multiplicity of GRUUs that each route to that UA
instance. For example, this is needed to support ad-hoc conferencing
where a UA instance needs a different URI for each conference it is
hosting. NOTE: This requirement is not met by this specification, and
is being addressed in a separate specification.
When a UA receives a request sent to a GRUU, it
must be possible for the UA to know the GRUU that was used to invoke
the request. This is necessary as a consequence of REQ 4. NOTE: This
requirement is not met by this specification, and is being addressed
in a separate specification.
It must be possible for a UA to add opaque content
to a GRUU. This content is not interpreted or altered by the network, and
is used only by the UA instance to whom the GRUU refers. This provides a
basic cookie type of functionality, allowing a UA to build a GRUU with
the state embedded. NOTE: This requirement is not met by this specification, and
is being addressed in a separate specification.
It must be possible for a proxy to execute
services and features on behalf of a UA instance represented by a
GRUU. As an example, if a user has call blocking features, a proxy might
want to apply those call blocking features to calls made to the GRUU,
in addition to calls made to the user's AOR.
It must be possible for a UA in a dialog to
inform its peer of its GRUU, and for the peer to know that the URI
represents a GRUU. This is needed for the conferencing and dialog
reuse applications of GRUUs, where the URIs are transferred within a
dialog.
When transferring a GRUU per REQ 8, it must be
possible for the UA receiving the GRUU to be assured of its integrity
and authenticity.
It must be possible for a server that is
authoritative for a domain to construct a GRUU which routes to a UA
instance bound to an AOR in that domain. In other words, the proxy can
construct a GRUU, too. This is needed for the presence application.
The following call flow, shown in , shows a
basic registration and call setup, followed by a subscription directed
to the GRUU. It then shows a failure of the callee, followed by a
re-registration. The conventions of RFC 4475
are used to describe representation of long message lines.
The Callee supports the GRUU extension. As such, its REGISTER (1) looks
like:
The registrar assigns a temporary and a public GRUU. The REGISTER
response (message 2) would look like:
The Contact header field in the REGISTER response contains
the pub-gruu Contact header field parameter with the public GRUU
sip:callee@example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6,
and the
temp-gruu header field parameter with the temporary GRUU
sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr. Both
are valid GRUUs for the AOR and
instance ID, and both translate to the contact sip:callee@192.0.2.1.
The INVITE from the caller (message 3) is a normal SIP
INVITE. However, the 200 OK generated by the callee (message 5) now
contains a GRUU as the remote target. The UA has chosen to use its
public GRUU.
At some point later in the call, the caller decides to subscribe to
the dialog event package (defined in ) at that
specific UA. To do that, it generates a SUBSCRIBE request (message 9),
but directs it towards the remote target, which is a GRUU:
In this example, the caller itself supports the GRUU extension, and is
using its own GRUU to populate its remote target.
This request is routed to the proxy, which proceeds to perform a
location lookup on the Request-URI. It is translated into the contact
for that instance, and then proxied to that contact.
The SUBSCRIBE generates a 200 response (message 11), which is followed
by a NOTIFY (message 13 and 14) and its response (message 15 and 16).
At some point after message 16 is received, the callee's machine
crashes and recovers. It obtains a new IP address, 192.0.2.2. Unaware
that it had previously had an active registration, it creates a new
one (message 17 below). Notice how the instance ID remains the same,
as it persists across reboot cycles:
The registrar notices that a different contact,
sip:callee@192.0.2.1, is already associated with the same instance
ID. It registers the new one too and returns both in the REGISTER
response. Both have the same public GRUUs, but the registrar has
generated a second temporary GRUU for this AOR and instance ID
combination. Both contacts are included in the REGISTER response, and
the temporary GRUU for each is the same - the most recently created
one for the instance ID and AOR. The registrar then generates the
following response:
There is no need for the UA to remove the stale registered contact;
the request targeting rules in
will cause the request to be delivered to the most recent one.
Attacks in SIP networks using GRUUs can be divided into inside attacks
(where the attacker is a valid participant in the system but is
malicious), and outside attacks, where a third party is trying to
attack the system. In addition, there are privacy considerations with
using GRUUs.
It is important for a UA to be assured of the integrity of a GRUU
given in a REGISTER response. If the GRUU is tampered with
by an attacker, the result could be denial of service to the UA. As a
result, it is RECOMMENDED that a UA use the SIPS URI scheme in the
Request-URI when registering. Proxies and registrars MUST support the
sips URI and MUST support TLS. This does not represent a
change from the requirements in RFC 3261 .
The example GRUU construction algorithm in makes no attempt to create a GRUU that
hides the AOR and instance ID associated with the GRUU. In general,
determination of the AOR associated with a GRUU is considered a good
property, since it allows for easy tracking of the target of a
particular call. Learning the instance ID provides little benefit to
an attacker. To register or otherwise impact registrations for the
user, an attacker would need to obtain the credentials for the
user. Knowing the instance ID is insufficient.
The example GRUU construction algorithm in makes no attempt to create a GRUU that
prevents users from guessing a GRUU based on knowledge of
the AOR and instance ID. A user that is able to do that will be able
to direct a new request at a particular instance. However, this
specification recommends that service treatment (in particular,
screening features) be given to requests
that are sent to a GRUU. That treatment will make sure that the GRUU does not
provide a back door for attackers to contact a user that has tried to
block the attacker.
As a consequence of this specification, a UA will begin using GRUUs
in the dialog forming and target refresh requests and responses it
emits. These GRUUs will be passed to other UA (called the
correspondent), which then use them in requests that they emit.
If a malicious correspondent removes the "gr" URI parameter, the
request will be routed to the authoritative proxy. If the GRUU had been
temporary, removal of the "gr" URI parameter produces a URI that is not
recognized as a GRUU and not equal to any AOR. The request will be
rejected. If the GRUU had been public, the resulting of removing the
"gr" URI parameter produces the AOR. Therefore, the request is treated
like a call to the AOR. Since it is a desired goal to allow users to
extract the AOR from the GRUU, this is not an attack and the call will
be handled normally.
A malicious user in the system might try to use a GRUU for launching a
DoS attack against another SIP UA. To do that, it would wait for a
call from that UA, from it, observe their GRUU. Once obtained, the UA
would launch a SIP request to an entity, such as a presence server,
which will generate many requests back towards the UA. However, the
attacker will use the target's GRUU in the Contact header field of
that SUBSCRIBE request. This will cause the traffic to be directed
towards the target instead. Since the GRUU is globally routable, such
traffic is more likely to be delivered to the target than traffic sent
to its IP address. This specification helps mitigate this attack by
requiring proxies to validate that the GRUU in the Contact of a
request matches the authenticated identity of the sender of the
request. This check requires the use of an outbound proxy. SIP does
not require outbound proxies, and this does leave a potential area of
vulnerability. However, in practice, nearly all deployments of SIP
utilize an outbound proxy, and therefore this vulnerability is not
likely to be a concern.
RFC 3323 defines mechanisms for privacy. It
distinguishes between
user-provided privacy and network-provided privacy. In the latter, the
user requests privacy services from the network by including a Privacy
header field in the request. In the former, the UA follows a basic set
of guidelines for construction of its request so let a certain level
of privacy is afforded.
The guidelines in Section 4.1 of RFC 3323 for
user-provided privacy
request that a UA construct its Contact header field with a URI that
omits a user part, and utilizes the IP address or hostname of the
UA. Such recommendations are in conflict with the rules defined in
this specification, which require the usage of a GRUU in the Contact
header field.
However, the temporary GRUUs provided by the registrar can be used in
place of the Contact URI format described in RFC 3323 . A user agent would
gather the temporary GRUU returned in each REGISTER responses, and keep
a small number of them cached. When it makes or receives a call, a
temporary GRUU is used to populate the Contact header field.
A UA can either elect to use the same temporary GRUU in each call, or
it can use a different temporary GRUU in each call. The choice depends
on the level of privacy desired:
A UA utilizing the same temporary URI for each call will allow a
correspondent, based solely on investigation of the Contact header
field, to correlate calls as coming from the same UA. This
is also true for the user provided privacy procedures in RFC 3323
,
since the IP address or hostname in the Contact URI provides a similar
correlator.
A UA utilizing a different temporary URI for each call will not allow
a correspondent, based solely on investigation of the Contact header
field, to correlate calls as coming from the same UA.
In both cases, absent network-provided privacy, IP address and port
information in the Session Description Protocol (SDP) (defined in ) will allow a correspondent to correlate calls as
coming from the same UA.
In both cases, if a user makes a call, the correspondent will be able
to call back by directing requests towards the GRUU in the Contact
header field. Similarly, features such as transfer and digit
collection by network application servers (see RFC 4730 ), which depend on a Contact with the
GRUU property, will also be possible. These kinds of inbound requests
will be possible until the registration for that UA lapses. A UA that
wishes to invalidate its previous temporary GRUU in order to limit
reachability MAY do so by generating a REGISTER refresh with a Call-ID
that differs from ones used previously. A UA SHOULD NOT forcefully
expire its registration and then re-register in order to invalidate
a temporary GRUU; this results in a brief period of unreachability and
will often produce excess load on the network. Refreshing with a new
Call-ID is more efficient and is meant as the technique for
coarse-grained control over the validity of temporary GRUU. A UA
wishing to not be disturbed by a specific call back will need to
implement manual or automated call handling procedures to reject
it. This specification does not provide the UA the ability to manually
invalidate individual temporary GRUU. If a UA insists on not receiving
any such inbound requests (including ones generated by network
applications, such as those used for collecting digits), the UA can
place a non-GRUU into the Contact header field. However, this is NOT
RECOMMENDED. Usage of a GRUU coupled with automated call rejection
features is far superior.
As long as a temporary GRUU is used to populate the Contact
header field, a correspondent will not be able to ascertain any
information about the AOR or instance ID of the UA by inspection of
the Contact header field. However, absent a network-provided privacy
service, the IP address in the SDP can be used to determine
information about the UA, such as its geographic location and ISP.
In all cases, regardless of whether the UA uses a temporary or
public GRUU in the Contact, regardless of whether it utilizes GRUU at
all, and regardless of whether it invokes a network-provided privacy
service, a correspondent will be able to determine the SIP service
provider of the UA.
This specification defines two new Contact header field parameters, one SIP
URI parameter, and a SIP option tag.
This specification defines two new header field parameters, as per the
registry created by RFC 3968 . The required information
is as follows:
Contactpub-gruuRFC XXXX [[NOTE TO IANA: Please replace
XXXX with the RFC number of this specification.]]Contacttemp-gruuRFC XXXX [[NOTE TO IANA: Please replace
XXXX with the RFC number of this specification.]]
This specification defines one new SIP URI parameter, as per the
registry created by RFC 3969 .
grnoneRFC XXXX [[NOTE TO IANA: Please replace
XXXX with the RFC number of this specification.]]
This specification registers a new SIP option tag, as per the
guidelines in Section 27.1 of RFC 3261 .
gruu This option tag is used to identify the
Globally Routable User Agent URI (GRUU) extension. When used in a
Supported header, it indicates that a User Agent understands the
extension. When used in a Require header field of a REGISTER request,
it indicates that the registrar is not expected to process the registration
unless it supports the GRUU extension.
The author would like to thank Eric Rescorla, Robert Sparks, Rohan
Mahy, Paul Kyzivat, Alan Johnston, Ya-Ching Tan, Dale Worley, Jeroen
van Bemmel, Vijay Gurbani, Andrew Allen, Alan Hawrylyshen, Francois
Audet, Fredrik Thulin, Dean Willis, David Hancock, Keith Drage, and
Cullen Jennings for their comments and contributions to this
work. Eric Rescorla provided the text for the introduction and the
GRUU construction algorithm in the appendix.
The mechanism for constructing a GRUU is not subject to
specification. This appendix provides an example that can be used by a
registrar to construct a public and a temporary GRUU. Of course,
others are permitted, as long as they meet the constraints defined for
a GRUU.
The most basic approach for constructing a public GRUU is to take the
AOR, and place the actual value of the instance ID into the contents
of the "gr" URI parameter.
This specification requires a registrar to create a new temporary GRUU
on each registration refresh. If a registration is very long lived,
this can quickly result in hundreds or even thousands of temporary
GRUUs being created and allocated to a UA. Consequently, it is
important to have an algorithm for constructing temporary GRUUs which
does not require additional storage that grows in size with the number
of temporary GRUUs. The following algorithm meets this goal.
The registrar maintains a counter, I. This counter is 48 bits, and is
initialized to zero. The counter is persistently stored, using a
backend database or other similar technique. When the registrar
creates the first temporary GRUU for a particular AOR and instance ID,
the registrar notes the current value of the counter, I_i, and
increments the counter in the database. The registrar then maps I_i to
the AOR and instance ID using the database, a persistent hashmap or
similar technology. If the registration expires such that there are no
longer any contacts with that particular instance ID bound to the
GRUU, the registrar removes the mapping. Similarly, if the temporary
GRUU are invalidated due to a change in Call-ID, the registrar removes
the current mapping from I_i to the AOR and instance ID, notes the
current value of the counter I_j, and stores a mapping from I_j to the
AOR and instance ID. Based on these rules, the hashmap will contain a
single mapping for each AOR and instance ID for which there is a
currently valid registration.
The usage of a counter in a 48 bit space with sequential assignment
allows for a compact representation of the hashmap key, which is
important for generating GRUUs of reasonable size. The counter starts
at zero when the system is initialized. Persistent and reliable
storage of the counter is required to avoid misrouting of a GRUU to
the wrong AOR and instance ID. Similarly, persistent storage of the
hashmap is required, even through proxy and registrar restarts. If the
hashmap is reset, all previous temporary GRUU become invalidated. This
might cause dialogs in progress to fail, or future requests towards a
temporary GRUU to fail when they normally would not. The same hashmap
needs to be accessible by all proxies and registrars that can field requests
for a particular AOR and instance ID.
The registrar maintains a pair of local symmetric keys K_e and
K_a. These are re-generated every time the counter is reset. When the
counter rolls over or is reset, the registrar remembers the old values
of K_e and K_a for a time. Like the hashmap itself, these keys need to
be shared across all proxy and registrars that can service requests
for a particular AOR and instance ID.
To generate a new temporary GRUU, the registrar generates a random
80-bit distinguisher value D. It then computes:
Where || denotes concatenation, AES-ECB-Encrypt represents AES
encryption in electronic codebook mode. M will be 128 bits long,
producing a value of E that is 128 bits and A that is 80 bits. This
produces a user part which has 42 characters.
When a proxy receives a request whose user part begins with "tgruu.",
it extracts the remaining portion, and splits it into 22 characters E' and
the remaining 14 characters A'. It then computes A and E by performing
a base64 decode of A' and E' respectively. Next, it computes:
If the counter has rolled over or reset, this computation is performed
with the current and previous K_a. If the Ac value(s) that are
computed do not match the value of A extracted from the GRUU, the GRUU
is rejected as invalid. Next, the proxy computes:
If the counter had rolled over, this computation is done using the
value of K_e that goes with the value of K_a which produced a valid Ac
in the previous HMAC validation. The leading 80 bits (the
distinguisher D) are discarded, leaving an index I_i in the
hashmap. This index is looked up. If it exists, the proxy now has the
AOR and instance ID corresponding to this temporary GRUU. If there is
nothing in the hashmap for the key I_i, the GRUU is no longer valid and the
request is rejected.
The usage of a 48 bit counter allows for the registrar to have as many
as a billion AORs, with 10 instances per each AOR, and cycle through
10,000 Call-ID changes for each instance through the duration of a
single registration. These numbers reflect the average; the system
works fine if a particular AOR has more than 10 instances or a
particular instance cycles through more than 10,000 Call-IDs in its
registration, as long as the average meets these
constraints.
The GRUU specification works properly based on logic implemented at
the user agents and in the authoritative proxies on both sides of a
call. Consequently, it is possible to construct network deployments in
which GRUUs will not work properly.
One important assumption made by the GRUU mechanism is that, if a
request passes through any proxies in the originating domain prior to
visiting the terminating domain, one of those proxies will be the authoritative
proxy for the UAC. Administrators of SIP networks will need to make
sure that this property is retained. There are several ways it can be
accomplished:
If the user agents support the service route mechanism , the registrar can implement it and return a
service route that points to the authoritative proxy. This will cause requests
originated by the user agent to pass through the authoritative proxy.
The user agents can be configured to never use an outbound proxy, and
send requests directly to the domain of the terminating
party. This configuration is not practical in many use cases but it is
a solution to this requirement.
The user agents can be configured with an outbound proxy in the same
domain as the authoritative proxy, and this outbound proxy forwards requests to
the authoritative proxy by default. This works very well in cases where the
clients are not roaming; in such cases the outbound proxy in a visited
network may be discovered dynamically through DHCP .
In cases where the client discovers a local outbound proxy via a
mechanism such as DHCP, and is not implementing service route, the UA
can be configured to automatically add an additional Route header
field after the outbound proxy, which points to a proxy in the home
network. This has the same net effect of service route, but is
accomplished through static configuration.