Internet DRAFT - draft-worley-sip-gruu-implement


SIP                                                            D. Worley
Internet-Draft                                                   Pingtel
Expires: August 23, 2007                               February 19, 2007

      Guidelines for Implementing the GRUU Support in User Agents

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 23, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Worley                   Expires August 23, 2007                [Page 1]
Internet-Draft         Guidelines for GRUU Support         February 2007


   Several applications of the Session Initiation Protocol (SIP) require
   a user agent (UA) to construct and distribute a URI which can be used
   by anyone on the Internet to route a request to that specific UA
   instance.  A URI which routes to a specific UA instance is called a
   Globally Routable UA URI (GRUU).  An Internet-Draft is progressing
   toward standardization that specifies procedures for proxies and UAs
   by which proxies can construct and delver GRUUs to UAs that request
   them.  This document summarizes for UA implementors how to obtain
   "public" GRUUs and gives guidance on effectively using public GRUUs.

Table of Contents

   1.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Feature Tag  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Requesting and Receiving a GRUU  . . . . . . . . . . . . . . .  7
   5.  Using a GRUU . . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  Revision history . . . . . . . . . . . . . . . . . . . . . . . 13
     7.1.  Changes from -00 to -01  . . . . . . . . . . . . . . . . . 13
     7.2.  Changes from -01 to -02  . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18

Worley                   Expires August 23, 2007                [Page 2]
Internet-Draft         Guidelines for GRUU Support         February 2007

1.  Background

   (This section is largely copied from an earlier version of [1].)

      The Session Initiation Protocol, RFC 3261 is used to establish and
      maintain a dialog between a pair of user agents in order to manage
      a communications session.  Messages within the dialog are sent
      from one user agent to another using a series of proxy hops called
      the route set, eventually being delivered to the remote target -
      the user agent on the other side of the dialog.  This remote
      target is identified by a SIP URI obtained from the value of the
      Contact header field in INVITE requests and responses.

      RFC 3261 mandates that a user agent populate the Contact header
      field in INVITE requests and responses with a URI that is global
      (meaning that it can be used from any element connected to the
      Internet), and that routes to the user agent which inserted it.
      RFC 3261 also mandates that this URI be valid for requests sent
      outside of the dialog in which the Contact URI was inserted.

      In practice, these requirements have proven very difficult to
      meet.  Few endpoints have a hostname that is is present in DNS.
      Many endpoints have an IP address that is private because the user
      agent is behind a NAT.  Techniques like the Simple Traversal of
      UDP Through NAT (STUN) can be used to obtain IP addresses on the
      public Internet.  However, many firewalls will prohibit incoming
      SIP requests from reaching a user agent unless they first pass
      through a proxy sitting in the DMZ of the network.  Thus URIs
      using STUN-obtained IP addresses often do not work.

      Because of these difficulties, most UAs have actually been
      inserting URIs into the Contact header field of requests and
      responses with the form sip:{IP-address}.  These have the property
      of routing to the UA, but they are generally only reachable from
      the proxy to which the user is directly connected.  This
      limitation does not prevent SIP calls to an Address-of-Record
      (AOR) from proceeding, since the user's proxy can usually reach
      these private addresses, and the proxy itself is generally
      reachable over the public network.  However, this issue has
      adversely affected several other SIP mechanisms and applications.

   A number of important applications depend on contact URIs being
   globally routable, including call transfer (via REFER or INVITE with
   the Replaces header), conferencing, presence applications, and end-
   point call control (EPCC) features (call pick-up, call park, etc.).
   All of these applications require a user agent to present a URI that
   not only routes solely to that user agent, but is usable by other
   entities anywhere on the Internet as a target for further SIP

Worley                   Expires August 23, 2007                [Page 3]
Internet-Draft         Guidelines for GRUU Support         February 2007

   requests.  Many of these applications require that dialog event
   packages [8] can report globally routable contact URIs.

   The GRUU features proposed in [1] alleviate these problems by
   providing a method for UAs to obtain globally routable URIs from the
   registrars for the AORs they serve.  At first sight, achieving this
   seems improbable, but of necessity (1) a proxy is globally routable
   from the Internet, and (2) a proxy knows how to reach any UA
   registered for an AOR in its domain.  Together, these facts allow the
   proxy to construct URIs which globally route to it, and allow the
   proxy to forward requests to those URIs to the corresponding UAs.

   Because of the importance of the GRUU mechanism for implementing
   features that are of great practical value, this memo summarizes the
   requirements for a UA to support and exploit GRUUs as an aid to UA
   implementers.  This memo is specialized for the commonest case, where
   a UA with one IP address services one or more AORs.  Except for some
   tightening of optional behaviors, it is entirely derived from [1].

   This document is not intended to advance toward standardization.
   However, if it proves valuable to implementors, it may evolve into a
   statement of best common practice.

   This document is revised to align with version 11 of the GRUU draft
   [1].  It does not address the use of "temporary GRUUs" to provide
   enhanced privacy; it only discusses use of "public GRUUs".

Worley                   Expires August 23, 2007                [Page 4]
Internet-Draft         Guidelines for GRUU Support         February 2007

2.  Terminology

   A URI is said to be "globally routable" if it can be resolved using
   the standard rules for resolving SIP URIs [9] by any host on the
   public Internet to reach a proxy that knows how to route requests for
   that URI to their intended destination.

   A URI is a "user agent URI" if it routes to only one user agent, and
   if it continues to route to that user agent even if the UA changes
   its contact address.

   A URI is a "GRUU" if it is both globally routable and is a user agent

   "GRUU" also refers to the SIP extension defined in [1], and to the
   GRUU URIs that UAs obtain via that extension.

   There are two types of GRUUs issued by proxies: "public GRUUs" which
   are intended to have an indefinite lifetime and manifest the AOR that
   they are associated with, and "temporary GRUUs" which are intended to
   be difficult to associate with their underlying AOR and to have a
   limited lifetime.  The use of temporary GRUUs is outside the scope of
   this document.

Worley                   Expires August 23, 2007                [Page 5]
Internet-Draft         Guidelines for GRUU Support         February 2007

3.  Feature Tag

   The feature tag for the GRUU extension is "gruu".

   Guideline 1:  The UA should add "Supported: gruu" to its requests and
                 responses, and accept "Require: gruu" in requests.

Worley                   Expires August 23, 2007                [Page 6]
Internet-Draft         Guidelines for GRUU Support         February 2007

4.  Requesting and Receiving a GRUU

   GRUUs that are issued by proxies represent a combination of a
   specific user agent and a specific AOR.  A UA can possess one
   (public) GRUU for each AOR that it services, and each UA that
   services a particular AOR will have a distinct GRUU for that AOR.

   Conceptually, GRUUs have an unlimited lifetime.  When a GRUU's UA has
   a contact registered for the GRUU's AOR, the GRUU routes to that
   contact.  Less commonly, a UA may have more than one contact for an
   AOR, in which case the GRUU can route to any of those contacts
   according to the policies in [1] and [7].

   GRUUs are constructed by proxies by attaching the "gr" URI-parameter
   to the GRUU's AOR.  The value of the "gr" parameter is determined by
   the proxy.  Some examples of possible GRUUs are:;gr=RWFjaCBVQSBpbnN;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

   Guideline 2:  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" parameter is known to be
                 globally routable, a UA should not apply such
                 mechanisms to any URI containing the "gr" parameter.

   Guideline 3:  All GRUUs exist both in the "sip" and the "sips" URI
                 schemes, and UAs must be capable of processing both
                 varieties of their GRUUs (to the extent that they are
                 capable of processing any contact URIs in those

   Each UA is identified by an "instance ID".

   Guideline 4:  Each UA instance has an "instance ID" which is globally
                 unique through all space and time.  An instance ID
                 persists through all ordinary operations, especially
                 restarting and changes in network connectivity.  An
                 instance ID is a URN [2].

   URNs can be created and assigned by many mechanisms.  For a network
   host that is a dedicated UA ("SIP phone"), it is recommended that it
   uses "version 1" of the UUID URN [3] (which contains the UA's MAC
   address) as an instance ID.  Because the UA's instance ID is sent in
   its REGISTER requests, it makes it possible for the proxy to
   correlate the UA's contact URI with its MAC address, which in many
   environments is used as the UA's identifier for configuration and

Worley                   Expires August 23, 2007                [Page 7]
Internet-Draft         Guidelines for GRUU Support         February 2007


   Guideline 5:  Hosts that are dedicated UAs should use as their
                 instance IDs Version 1 of the UUID URN, which is
                 derived from the MAC address of the UA's network
                 interface [3].

   Guideline 6:  UAs that are not embodied in dedicated UA devices must
                 generate their instance IDs in a manner that guarantees
                 global uniqueness.  (E.g., a more complex use of
                 Version 1 UUIDs, a name-based UUID derived from a
                 suitable identification string, or an object-id
                 assigned administratively [4].)  The "tel" namespace
                 and similar namespaces should not be used, as
                 conceptually they are AORs, not unique identifiers for
                 swarms of user agents.

   Guideline 7:  As other SIP agents may use the instance ID and/or GRUU
                 as a key to cache information about the UA and its
                 capabilities, it is recommended that when a new version
                 of software is installed into the UA, the UA should
                 obtain a new instance ID.

   (Do we really want to do that?)

   In principle, the registrar should compare an instance ID string with
   other instance ID strings using the proper comparison method for the
   URN scheme of the instance IDs, but in practice the UA cannot depend
   on the registrar knowing the proper comparison method for the URN
   scheme of its instance ID.

   Guideline 8:  The UA should always use the same character string to
                 represent its instance ID (e.g., normalizing the case
                 of letters), even if the URN scheme permits several
                 different character strings to represent the same URN.

   Guideline 9:  A UA requests a GRUU for its instance ID and a
                 particular AOR by extending its ordinary REGISTER
                 requests for that AOR by: (1) adding a "Supported:
                 gruu" header, and (2) adding an "instance" media
                 feature tag to the Contact giving the UA's instance ID
                 as its value.  If the registrar understands the GRUU
                 extension, it may (but is not guaranteed to): (3)
                 append to the returned Contact the same "instance"
                 media feature tag and/or a "pub-gruu" field parameter
                 giving the assigned GRUU.

   Note that due to the format requirements for media feature tags [5],

Worley                   Expires August 23, 2007                [Page 8]
Internet-Draft         Guidelines for GRUU Support         February 2007

   the syntax of the "instance" tag is a field parameter
   '+sip.instance="<{instance ID URN}>"'.  As '<' cannot appear in a
   "token" [6], the value of the '+sip.instance' parameter must be
   quoted with '"'.  The instance ID value itself must be contained
   between '<' and '>' due to the rules of [5].  In addition, due to the
   syntax of "quoted-string" in [6] and "qdtext-no-abkt" in [5], any
   occurrence of '"', '<', '>', or '\' in the instance ID must be quoted
   by preceding it with '\'.  Using '\' to quote other characters, while
   allowed by [6], should be avoided to ensure unique representation of
   instance IDs.

   A typical registration request is:

   Via: SIP/2.0/UDP;branch=z9hG4bKnashds7
   Max-Forwards: 70
   From: Callee <>;tag=a73kszlfl
   To: Callee <>
   Call-ID: 1j9FpLxk3uxtm8tn@
   Contact: <sips:callee@>
   Supported: gruu
   Content-Length: 0

   A possible response is:

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP;branch=z9hG4bKnashds7
   From: Callee <>;tag=a73kszlfl
   To: Callee <> ;tag=b88sn
   Call-ID: 1j9FpLxk3uxtm8tn@
   Contact: <sips:callee@>
   Supported: gruu
   Content-Length: 0

   For obtaining GRUUs, the contact URI is treated nearly opaquely.  The
   contact URI can even be a GRUU itself, if that is what is appropriate
   for the application.  (But the contact URI must not be a GRUU for the
   AOR for which it is being registered, as that would guarantee a
   routing loop.  The registrar is required to reject such registrations
   with a 403 response.)

Worley                   Expires August 23, 2007                [Page 9]
Internet-Draft         Guidelines for GRUU Support         February 2007

   Guideline 10:  The UA should not attempt to recommend a GRUU to the
                  registrar (by providing a "gr", "pub-gruu", or "temp-
                  gruu" field parameter on the Contact header in the

   The registrar constructs the GRUU by appending a "gr" parameter that
   it chooses.  However, for robustness:

   Guideline 11:  The GRUU should be treated opaquely by the UA.

   The proxy should construct GRUUs in a way that ensures that every
   time a registration is done for a particular AOR with a particular
   instance ID, the same GRUU will be returned.  But as it is impossible
   to guarantee this behavior, a UA should be prepared for the returned
   GRUU to change.

   Guideline 12:  If a REGISTER returns a new GRUU for an AOR/instance
                  ID combination, the UA must use the new GRUU.

   The GRUU will be returned with the "sip" or "sips" scheme as
   specified in the registered AOR (in the To header).  Nonetheless,
   registration associates both versions of the GRUU with the contact
   address and each version will route to the contact address using its

   As detailed below, when responding to requests, the UA should use as
   its contact URI the GRUU associated with the AOR through which the
   request was routed to the UA.  The request-URI is almost never this
   AOR, of course.  And the From header cannot be depended upon to
   supply the AOR, as the From header may contain a URI that routed to
   the AOR in a complex way.

   Guideline 13:  The UA should register distinct contact URIs for each
                  AOR it services, so that incoming request-URIs
                  uniquely identify the AOR through which the request
                  was routed.  Note that it is not a sufficient policy
                  to generate from each AOR a contact 'sips:{user-part}@
                  {IP-address}', since it is common for a UA to service
                  two AORs with the same user part but different host
                  parts.  One common method to construct multiple
                  contact addresses is to use the "line" URI-parameter
                  to apply a unique value to what would otherwise be
                  identical contact URIs.

Worley                   Expires August 23, 2007               [Page 10]
Internet-Draft         Guidelines for GRUU Support         February 2007

5.  Using a GRUU

   Since the GRUU is routable by the ordinary SIP mechanisms, the GRUU
   may be used just like any other SIP URI.  But to gain the benefits of
   GRUUs, the UA needs to use GRUUs in particular ways.

   For ordinary requests and responses, that is, those that would in the
   absence of GRUUs be made using pre-existing contact addresses, the
   rules only involve identifying the correct GRUU to use in each

   Guideline 14:  When making an out-of-dialog request, the UA should
                  use as Contact the GRUU corresponding to the AOR that
                  it places in the To header.

   Guideline 15:  When responding to an out-of-dialog request, the UA
                  should determine, based on the request-URI, the AOR
                  through which the request was routed, and use as
                  Contact the GRUU corresponding to that AOR.

   Non-target-refresh in-dialog requests and responses will use the
   existing route set, so their Contacts will automatically adhere to
   these guidelines.

   Guideline 16:  If a Contact value is a GRUU, target refresh requests
                  will not change it, because the routing changes that
                  would be otherwise be effected by modifying the target
                  URI are effected by the proxy modifying how it routes
                  requests addressed to the GRUU. [1] [7]

Worley                   Expires August 23, 2007               [Page 11]
Internet-Draft         Guidelines for GRUU Support         February 2007

6.  Security Considerations

   As stated in [1]:

   Guideline 17:  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.  Note that this does not represent a change from
                  the requirements in RFC 3261.

   UAs' instance IDs and GRUUs are not hidden from the public.  This
   does not present a security risk, as an instance ID is not
   authentication credentials.  But it does represent a reduction in
   privacy, as instance IDs and GRUUs may be more specific or more
   persistent over time than AORs and the IP-based URIs that have
   previously been used as contact URIs.

   Guideline 18:  Since GRUUs are publicly visible, any screening of
                  unwanted communications which is applied to an AOR
                  must be applied to its GRUUs.  In addition, since an
                  AOR's forking may be used to implicitly screen
                  requests for one of its targets, it may be desirable
                  to apply additional screening for requests to a GRUU
                  for such an AOR.

   If the user of the UA desires a degree of anonymity, the UA should
   use the "temporary GRUU" mechanism, rather than the "global GRUU"
   mechanism described here. [1]

Worley                   Expires August 23, 2007               [Page 12]
Internet-Draft         Guidelines for GRUU Support         February 2007

7.  Revision history

7.1.  Changes from -00 to -01

   Replace reference to draft-ietf-sip-gruu-05.txt with

   Add a statement regarding the intended future of this draft.

   Made allowances for UAs that cannot process one of the "sip" or
   "sips" URI schemes.

   Number the guidelines for ease of reference.

   Promote some statements from commentary to guidelines.

   Relax the requirements on Supported and Require headers per changes
   in the GRUU I-D.

   Various edits to improve clarity.

   Removed the section "Avoiding routing circularity", which dealt with
   the "edge router problem".  This is per (1) revised solutions to the
   edge router problem to appear in the GRUU I-D, and (2) the
   observation by Rohan Mahy that in complex networks without global
   routability, the burden should be placed on the routers, as they are
   aware of the network topology, rather than the end devices, which
   would otherwise have to be capable of dealing with all such network

   Clarify that more than one contact may be associated with a GRUU, per
   the latest GRUU I-D.

   Added "Security Considerations" section.

   Show REGISTER examples using sips: URIs, to conform with the security

7.2.  Changes from -01 to -02

   Replace reference to draft-ietf-sip-gruu-06.txt with
   draft-ietf-sip-gruu-09.txt.  Correct reference to RFC 3261.

   Moved "Revision History" below "Security Considerations".

   Use <list style='format Guideline %d:' counter='guidelines'> to
   number the guidelines automatically.

Worley                   Expires August 23, 2007               [Page 13]
Internet-Draft         Guidelines for GRUU Support         February 2007

   Use the current definition of "opaque" and "gruu" URI-parameters.

   Note that non-standard mechanisms to cope with non-global-routability
   should not be applied to URIs with "gruu" parameter.

   Revised discussion of Require and Supported headers to the current

   Added discussion that the contact URI can itself be a GRUU.

   Removed requirement that UA recognize its GRUUs as request-URIs or
   Route values, as this circumstance should not be seen now.

   Update discussion of "grid" parameter.

   Split Using a GRUU section into several sections.

   Marked advice in Security Considerations section as guidelines.

   Updated contact information.

   Added references to RFC 3263 [9], RFC 4235 [8], and sip-outbound [7].

   Separated into its own guideline advice that a UA should change
   instance IDs when its software is updated.  Added question as to
   whether this is a good idea.

   Detailed that target refresh requests will not modify a GRUU target
   because such routing changes are done by modifying how the proxy
   routes to the GRUU.

   State that the UA must provide a value for the grid parameter.

   Update reference to version 11 (draft-ietf-sip-gruu-11).

   Update to match version 11, especially using the term "public GRUU",
   ensuring the AOR is visible in public GRUUs, and using the new
   parameter names.

   Add guideline about what to do if the GRUU returned by a REGISTER

   Delete the "grid" URI-parameter.

   Delete the discussion of call processing in re calls directed to
   GRUUs, as call processing is expected to be done at the proxy.  Call
   processing done at the UA is expected to be done in the same way as
   to requests made to the AOR or contact address.

Worley                   Expires August 23, 2007               [Page 14]
Internet-Draft         Guidelines for GRUU Support         February 2007

8.  Acknowledgements

   The author would like to thank Michael Procter for his comments and
   contributions to this work.

Worley                   Expires August 23, 2007               [Page 15]
Internet-Draft         Guidelines for GRUU Support         February 2007

9.  Normative References

   [1]  Rosenberg, J., "Obtaining and Using Globally Routable User Agent
        (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
        draft-ietf-sip-gruu-11 (work in progress), October 2006.

   [2]  Moats, R., "URN Syntax", RFC 2141, May 1997.

   [3]  Leach, P., Mealling, M., and R. Salz, "A Universally Unique
        IDentifier (UUID) URN Namespace", RFC 4122, July 2005.

   [4]  Mealling, M., "A URN Namespace of Object Identifiers", RFC 4122,
        February 2001.

   [5]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User
        Agent Capabilities in the Session Initiation Protocol (SIP)",
        RFC 3840, August 2004.

   [6]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [7]  Jennings, C. and R. Mahy, "Managing Client Initiated Connections
        in the Session Initiation Protocol (SIP)",
        draft-ietf-sip-outbound-07 (work in progress), January 2007.

   [8]  Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
        Initiated Dialog Event Package for the Session Initiation
        Protocol (SIP)", RFC 4235, November 2005.

   [9]  Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
        (SIP): Locating SIP Servers", RFC 3263, June 2002.

Worley                   Expires August 23, 2007               [Page 16]
Internet-Draft         Guidelines for GRUU Support         February 2007

Author's Address

   Dale R. Worley
   Pingtel Corp.
   400 West Cummings Park, Suite 2200
   Woburn, MA  01801

   Phone: +1 781 938 5306 x173

Worley                   Expires August 23, 2007               [Page 17]
Internet-Draft         Guidelines for GRUU Support         February 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Worley                   Expires August 23, 2007               [Page 18]