Guidelines for Implementing the GRUU Support in User Agents

(This section is largely copied from .) 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 be able to construct 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. 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 various 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.

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

GRUUs that are issued by proxies represent a combination of a specific user agent and a specific AOR. A UA can possess one GRUU for each AOR that it services, and each UA that services a particular AOR will have a distinct GRUU for that AOR. GRUUs conceptually 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 or all of those contacts according to policies that are not fixed by .

GRUUs can be constructed by proxies according to any number of methods. Some of them will be largely opaque to an outside observer, whereas some of them will be more transparent in regard to the AOR or UA to which they refer. Some examples of possible GRUUs are: sip:gruu~456163682055412069@example.com sip:foo@example.com;opaque=RWFjaCBVQSBpbnN sip:foo@example.com ;opaque="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" Guideline 1: 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 degree that they are capable of processing any contact URIs in those schemes). Each UA is identified by an "instance ID". Guideline 2: Each UA instance has an "instance ID" which is globally unique and persists through all space and time. An instance ID is a URN . Guideline 3: It is convenient for hosts that are dedicated UAs ("SIP phones") to use for their instance IDs Version 1 of the UUID URN, which is derived from the MAC address of the UA's network interface . As only one instance ID is needed for all time, a suitable UUID can be constructed with fixed "time" and "clock sequence" values. Guideline 4: 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 sophisticated use of Version 1 UUIDs, a name-based UUID derived from a suitable identification string, or an object-id assigned administratively .) The "tel" and similar namespaces should not be used, as conceptually they are AORs, not unique identifiers for swarms of user agents. In principle, the registrar should compare an instance ID string with other instance ID strings using the proper comparison method for their URN scheme, but in practice the UA cannot depend on the registrar knowing the proper comparison method for the URN scheme of its instance ID. Guideline 5: The UA should always use the same character string to represent its instance ID, even if the URN scheme permits several different character strings to represent the same URN. Guideline 6: 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, its response will: (3) contain a "Require: gruu" header, and (4) append to the returned Contact the same "instance" media feature tag and a "gruu" field parameter giving the 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 suitable response would look like: 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="sips:callee@example.com;opaque=RWFjaCBVQSBpbnN" ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" ;expires=3600 Require: gruu Content-Length: 0 Guideline 7: The UA must be prepared to receive responses to REGISTERs that contain "Require: gruu", and not reject them as an unsupported extension. The UA should accept "Require: gruu" on all requests and responses. For obtaining GRUUs, the contact URI is treated opaquely, and so can be any URI that the UA chooses. Guideline 8: The UA should not attempt to recommend a GRUU to the registrar by providing a "gruu" field parameter on the Contact header in the request. The registrar is free to construct the GRUU as it chooses. Guideline 9: The GRUU should be treated opaquely by the UA, except for the use of the "grid" parameter described below. 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 usually not an AOR, of course. And the From header cannot be depended upon, as may not contain an AOR for this UA. Guideline 10: The UA should register distinct contact URIs for each AOR it services. Note that it is not sufficient 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 domains.

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. The base requirement is that the UA must not attempt to resolve the GRUU via DNS and route the request elsewhere: Guideline 11: The UA should recognize the GRUU (in either the request-URI or a Route header) as a "resource that it is responsible for", just as it would one of its contact URIs, and process the request (if it is examining the request-URI) or examine the next element of the route set (if it is examining a Route header). This recognition should be done by URI equality testing with the GRUUs that have been issued to the UA before any attempt is made to resolve the URI through DNS. For ordinary requests and responses, that is, those that would in the absence of GRUUs be made using the pre-existing contact addresses, the rules only involve identifying the correct GRUU to use in each circumstance: Guideline 12: 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 13: 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 the GRUU corresponding to that AOR as Contact. In-dialog requests and responses will use the existing route set, which will guarantee that they follow the same rules as for out-of-dialog requests and responses. There is an additional mechanism that allows the UA to create from its assigned GRUU an infinite supply of GRUUs: The UA may attach to the GRUU a "grid" parameter ("GRUU identifier") with an arbitrary value. If the UA passes this derived URI to an agent, the agent may use it to send a request. (Agents should not add "grid" parameters to GRUUs that they are not registered for, but only copy them from URIs received from other agents, which ultimately come from the UA which is assigned the GRUU.) When the proxy is resolving the GRUU with the grid parameter, it is required to copy the grid parameter from the GRUU to the associated contact URI. Thus, the UA can create an infinite number of different URIs, all of which are GRUUs and all of which route to its contact address, but each carries different grid parameters, which allows the UA to assign different meanings to them. Note that in the absence of a grid parameter, if a request was sent to the GRUU, it arrives at the UA with the same request-URI as it would if it were sent to the corresponding AOR. Thus, it is impossible for the UA to tell the difference between a request that was routed through the AOR and a request that was routed through the GRUU. But a request that is routed through the GRUU with a grid parameter is distinguishable, as a request routed through the AOR will not have a grid parameter. Conceptually, a request that is sent to a GRUU is intended to be "to the user agent, as an agent for its user", whereas a request to an AOR is intended to be "to the user", and the two may need to be processed differently at times. (Think of requests to the GRUU as being a conversation with the secretary which is about a conversation that is being contemplated with the boss.) In order to ensure that this distinction can always be made, the UA when using the GRUU should always add a grid parameter, even if it has just a null value. Guideline 14: When the UA is inserting the GRUU into a Contact field, it should always add a grid parameter. If the UA has no particular data to specify, it should give the parameter a null value by appending ';grid=""'. Guideline 15: When a UA receives an out-of-dialog request to one of its contact addresses with a grid parameter, it should understand that it is receiving the request in its capacity as an agent (possibly one of many) for its user, and not a request for its user per se. Call control features may not apply to such a request in the same way as for a request for its user. E.g., call diversion from its AOR to another destination probably should not be applied. The feature tag for the GRUU extension is "gruu". Guideline 16: The UA should add "Supported: gruu" to its requests and responses, and accept "Require: gruu" in requests and responses.

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.

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. Users should be aware that 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 and 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 a target.