Guidelines for Implementing the GRUU Support in User Agents

(This section is largely copied from an earlier version of .) 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 requests. Many of these applications require that dialog event packages can report globally routable contact URIs. The GRUU features proposed in 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 . 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 . It does not address the use of "temporary GRUUs" to provide enhanced privacy; it only discusses use of "public GRUUs".

A URI is said to be "globally routable" if it can be resolved using the standard rules for resolving SIP URIs 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 URI. "GRUU" also refers to the SIP extension defined in , 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.

The feature tag for the GRUU extension is "gruu". The UA should add "Supported: gruu" to its requests and responses, and accept "Require: gruu" in requests.

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 and .

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: sip:gruu~foo@example.com;gr=RWFjaCBVQSBpbnN sip:foo@example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 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. 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 schemes). Each UA is identified by an "instance ID". 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 . 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 (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 provisioning. 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 . 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 .) The "tel" namespace and similar namespaces should not be used, as conceptually they are AORs, not unique identifiers for swarms of user agents. 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. 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. 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 , the syntax of the "instance" tag is a field parameter '+sip.instance="<{instance ID URN}>"'. As '<' cannot appear in a "token" , 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 . In addition, due to the syntax of "quoted-string" in and "qdtext-no-abkt" in , any occurrence of '"', '<', '>', or '\' in the instance ID must be quoted by preceding it with '\'. Using '\' to quote other characters, while allowed by , should be avoided to ensure unique representation of instance IDs.

A typical registration request is: REGISTER sips:example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Callee <sips:callee@example.com>;tag=a73kszlfl To: Callee <sips:callee@example.com> Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 CSeq: 1 REGISTER Contact: <sips:callee@192.0.2.1> ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" Supported: gruu Content-Length: 0

A possible response is: SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 From: Callee <sips:callee@example.com>;tag=a73kszlfl To: Callee <sips:callee@example.com> ;tag=b88sn Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 CSeq: 1 REGISTER Contact: <sips:callee@192.0.2.1> ;gruu="sip:callee@example.com;gr=RWFjaCBVQSBpbnN" ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" ;expires=3600 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.) 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 request). The registrar constructs the GRUU by appending a "gr" parameter that it chooses. However, for robustness: 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. 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 scheme. 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. 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.

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 circumstance: 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. 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. 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.

As stated in : 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. 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.

Replace reference to draft-ietf-sip-gruu-05.txt with draft-ietf-sip-gruu-06.txt. 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 topologies. 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 recommendations.

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. 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 usage. 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 , RFC 4235 , and sip-outbound . 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 changes. 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.

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