idnits 2.17.1 draft-ietf-sip-gruu-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1816. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1822. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 133 has weird spacing: '...rencing frame...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 28, 2005) is 6756 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3265 (ref. '6') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 2141 (ref. '10') (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '15') (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 3188 (ref. '16') (Obsoleted by RFC 8458) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-00 == Outdated reference: A later version (-03) exists of draft-ietf-sip-target-dialog-01 == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-05 == Outdated reference: A later version (-09) exists of draft-ietf-sipping-torture-tests-07 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-05 == Outdated reference: A later version (-07) exists of draft-ietf-simple-presence-data-model-04 Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: April 1, 2006 September 28, 2005 6 Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the 7 Session Initiation Protocol (SIP) 8 draft-ietf-sip-gruu-05 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 1, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 Several applications of the Session Initiation Protocol (SIP) require 42 a user agent (UA) to construct and distribute a URI which can be used 43 by anyone on the Internet to route a call to that specific UA 44 instance. A URI which routes to a specific UA instance is called a 45 Globally Routable UA URI (GRUU). This document describes an 46 extension to SIP for obtaining a GRUU from a server, and for 47 communicating a GRUU to a peer within a dialog. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Defining a GRUU . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 4.1 REFER . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4.2 Conferencing . . . . . . . . . . . . . . . . . . . . . . . 6 57 4.3 Presence . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 59 6. Creation of a GRUU . . . . . . . . . . . . . . . . . . . . . . 9 60 7. Obtaining a GRUU . . . . . . . . . . . . . . . . . . . . . . . 13 61 7.1 Through Registrations . . . . . . . . . . . . . . . . . . 13 62 7.1.1 User Agent Behavior . . . . . . . . . . . . . . . . . 13 63 7.1.2 Registrar Behavior . . . . . . . . . . . . . . . . . . 15 64 7.2 Administratively . . . . . . . . . . . . . . . . . . . . . 17 65 8. Using the GRUU . . . . . . . . . . . . . . . . . . . . . . . . 18 66 8.1 Sending a Message Containing a GRUU . . . . . . . . . . . 18 67 8.2 Sending a Message to a GRUU . . . . . . . . . . . . . . . 19 68 8.3 Receiving a Request Sent to a GRUU . . . . . . . . . . . . 20 69 8.4 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 20 70 8.4.1 Request Targeting . . . . . . . . . . . . . . . . . . 20 71 8.4.2 Record Routing . . . . . . . . . . . . . . . . . . . . 22 72 9. The opaque SIP URI Parameter . . . . . . . . . . . . . . . . . 25 73 10. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 27 74 11. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 27 75 12. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 28 76 13. Security Considerations . . . . . . . . . . . . . . . . . . 33 77 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 78 14.1 Header Field Parameter . . . . . . . . . . . . . . . . . . 34 79 14.2 URI Parameters . . . . . . . . . . . . . . . . . . . . . . 34 80 14.3 Media Feature Tag . . . . . . . . . . . . . . . . . . . . 35 81 14.4 SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 35 82 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 83 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 84 16.1 Normative References . . . . . . . . . . . . . . . . . . . 36 85 16.2 Informative References . . . . . . . . . . . . . . . . . . 37 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 39 87 A. Example GRUU Construction Algorithms . . . . . . . . . . . . . 39 88 A.1 Instance ID in opaque URI Parameter . . . . . . . . . . . 39 89 A.2 Encrypted Instance ID and AOR . . . . . . . . . . . . . . 39 90 Intellectual Property and Copyright Statements . . . . . . . . 41 92 1. Introduction 94 The Session Initiation Protocol, RFC 3261 [1] is used to establish 95 and maintain a dialog between a pair of user agents in order to 96 manage a communications session. Messages within the dialog are sent 97 from one user agent to another using a series of proxy hops called 98 the route set, eventually being delivered to the remote target - the 99 user agent on the other side of the dialog. This remote target is 100 identified by a SIP URI obtained from the value of the Contact header 101 field in INVITE requests and responses. 103 RFC 3261 mandates that a user agent populate the Contact header field 104 in INVITE requests and responses with a URI that is global (meaning 105 that it can be used from any element connected to the Internet), and 106 that routes to the user agent which inserted it. RFC 3261 also 107 mandates that this URI be valid for requests sent outside of the 108 dialog in which the Contact URI was inserted. 110 In practice, these requirements have proven very difficult to meet. 111 Few endpoints have a hostname that is is present in DNS. Many 112 endpoints have an IP address that is private because the client is 113 behind a NAT. Techniques like the Simple Traversal of UDP Through 114 NAT (STUN) [15] can be used to obtain IP addresses on the public 115 Internet. However, many firewalls will prohibit incoming SIP 116 requests from reaching a client unless they first pass through a 117 proxy sitting in the DMZ of the network. Thus URIs using STUN- 118 obtained IP addresses often do not work. 120 Because of these difficulties, most clients have actually been 121 inserting URIs into the Contact header field of requests and 122 responses with the form sip:. These have the property of 123 routing to the client, but they are generally only reachable from the 124 proxy to which the user is directly connected. This limitation does 125 not prevent SIP calls to an Address-of-Record (AOR) from proceeding, 126 since the user's proxy can usually reach these private addresses, and 127 the proxy itself is generally reachable over the public network. 128 However, this issue has impacted the ability of several other SIP 129 mechanisms and applications to work properly. 131 An example of such an application is call transfer [25], based on the 132 REFER method [7]. Another application is the usage of endpoint- 133 hosted conferences within the conferencing framework [17]. Both of 134 these mechanisms require the endpoint to be able to construct a URI 135 that not only routes to that user agent, but is usable by other 136 entities anywhere on the Internet as a target for new SIP requests. 138 This specification formally defines a type of URI called a Globally 139 Routable User Agent URI (GRUU) which has the properties of routing to 140 the UA and being reachable from anywhere. Furthermore, it defines a 141 new mechanism by which a client can obtain a GRUU from its SIP 142 provider, allowing it to use that URI in the Contact header fields of 143 its dialog forming requests and responses. Since the GRUU is 144 provided by the user's SIP provider, the GRUU properties can be 145 guaranteed by the provider. As a result, the various applications 146 which require the GRUU property, including transfer, presence, and 147 conferencing, can work reliably. 149 2. Terminology 151 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 152 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 153 and "OPTIONAL" are to be interpreted as described in RFC 2119 [5] and 154 indicate requirement levels for compliant implementations. 156 This specification also defines the following additional terms: 158 contact: The term "contact", when used in all lowercase, refers to a 159 URI that is bound to an AOR or GRUU by means of a registration. A 160 contact is usually a SIP URI, and is bound to the AOR and GRUU 161 through a REGISTER request by appearing as the value of the 162 Contact header field. 164 remote target: The term "remote target" refers to a URI that a user 165 agent uses to identify itself for receipt of both mid-dialog and 166 out-of-dialog requests. A remote target is established by placing 167 a URI in the Contact header field of a dialog forming request or 168 response. 170 Contact header field: The term "Contact header field", with a 171 capitalized C, refers to the header field which can appear in 172 REGISTER requests and responses, redirects, or in dialog creating 173 requests and responses. Depending on the semantics, the Contact 174 header field sometimes conveys a contact, and sometimes conveys a 175 remote target. 177 3. Defining a GRUU 179 URIs have properties. Those properties are granted to the URI based 180 on the policies of the domain that owns the URI, and those properties 181 are not visible by inspection of the URI. In this context, the 182 domain that owns the URI is the one indicated in the host part of the 183 SIP URI. Some of the properties that a domain can confer upon a URI 184 are: 186 The AOR property: A URI has the Address of Record (AOR) property if a 187 domain will allow it to appear in the To header field of REGISTER 188 request. 190 The alias property: A URI is an alias if its treatment by the domain 191 is identical to another URI. 193 The service treatment property: A URI has the service treatment 194 property if the domain will apply applications, features, and 195 services to calls made by, or made to, that URI, possibly based on 196 associating that URI with a user that has "subscribed" to various 197 features. 199 The anonymous property: A URI has the anonymous property when it is 200 not possible, by inspection of the URI, to discern the user with 201 whom the URI is associated. 203 The identity property: A URI is considered an identity when it is one 204 that the domain will authorize as a valid value in the From header 205 field of a request, such that an authentication service will sign 206 a request with that URI [20]. 208 This specification focuses on a property, called the Globally 209 Routable User Agent URI (GRUU) property. A URI possesses this 210 property when the following is true: 212 Global: It can be used by any UAC connected to the Internet. In that 213 regard, it is like the address-of-record (AOR) property. A URI 214 with the AOR property (for example, sip:joe@example.com), is meant 215 to be used by anyone to reach that user. The same is true for a 216 URI with the GRUU property. 218 Routes to a Single Instance: A request sent to that URI will be 219 routed to a specific UA instance. In that regard, it is unlike 220 the address-of-record property. When a request is sent to a URI 221 with the AOR property, routing logic is applied in proxies to 222 deliver the request to one or more UAs. That logic can result in 223 a different routing decision based on the time-of-day, or the 224 identity of the caller. However, when a request is made to a URI 225 with the GRUU property, the routing logic is dictated by the GRUU 226 property. The request has to be delivered to a very specific UA 227 instance. That UA instance has to be the same UA instance for all 228 requests sent to that URI. 230 Long Lived: The URI with the GRUU property persists for relatively 231 long periods of time, ideally being valid for the duration of 232 existence of the AOR itself. This property cannot be completely 233 guaranteed, but providers are supposed to do their best to make 234 sure that a GRUU remains viable indefinitely. 236 A URI can have any combination of these properties. It is the 237 responsibility of the domain which mints the URI to determine what 238 properties are conferred upon that URI. This specification imposes 239 requirements on a domain that mints a URI with the GRUU property. 241 For convenience, a URI that possesses the GRUU property is also 242 referred to as a GRUU. 244 4. Use Cases 246 There are several use cases where the GRUU properties are truly 247 needed in order for a SIP application to operate. 249 4.1 REFER 251 Consider a blind transfer application [25]. User A is talking to 252 user B. User A wants to transfer the call to user C. So, user A 253 sends a REFER to user C. That REFER looks like, in part: 255 REFER sip:C@example.com SIP/2.0 256 From: sip:A@example.com;tag=99asd 257 To: sip:C@example.com 258 Refer-To: (URI that identifiers B's UA) 260 The Refer-To header field needs to contain a URI that can be used by 261 user C to place a call to user B. However, this call needs to route 262 to the specific UA instance which user B is using to talk to user A. 263 If it didn't, the transfer service would not execute properly. This 264 URI is provided to user A by user B. Because user B doesn't know who 265 user A will transfer the call to, the URI has to be usable by anyone. 266 Therefore, it needs to be a GRUU. 268 4.2 Conferencing 270 A similar need arises in conferencing [17]. In that framework, a 271 conference is described by a URI which identifies the focus of the 272 conference. The focus is a SIP UA that acts as the signaling hub for 273 the conference. Each conference participant has a dialog with the 274 focus. One case described in the framework is where a user A has 275 made a call to user B. User A puts user B on hold, and calls user C. 276 Now, user A has two separate dialogs for two separate calls - one to 277 user B, and one to user C. User A would like to conference them. To 278 do this, user A's user agent morphs itself into a focus. It sends a 279 re-INVITE or UPDATE [4] on both dialogs, and provides user B and user 280 C with an updated remote target that now holds the conference URI. 281 The URI in the Contact header field also has a callee capabilities 283 [11] parameter which indicates that this URI is a conference URI. 284 User A proceeds to mix the media streams received from user B and 285 user C. This is called an ad-hoc conference. 287 At this point, normal conferencing features can be applied. That 288 means that user B can send another user, user D, the conference URI, 289 perhaps in an email. User D can send an INVITE to that URI, and join 290 the conference. For this to work, the conference URI used by user A 291 in its re-INVITE or UPDATE has to be usable by anyone, and it has to 292 route to the specific UA instance of user A that is acting as the 293 focus. If it didn't, basic conferencing features would fail. 294 Therefore, this URI has to be a GRUU. 296 4.3 Presence 298 In a SIP-based presence [27] system, the Presence Agent (PA) 299 generates notifications about the state of a user. This state is 300 represented with the Presence Information Document Format (PIDF) 301 [24]. In a PIDF document, a user is represented by a series of 302 tuples, each of which describes the services that the user has. Each 303 tuple also has a URI in the element, which is a SIP URI 304 representing that service. A watcher can make a call to that URI, 305 with the expectation that the call is routed to the service whose 306 presence is represented in the tuple. 308 In some cases, the service represented by a tuple may exist on only a 309 single user agent associated with a user. In such a case, the URI in 310 the presence document has to route to that specific UA instance. 311 Furthermore, since the presence document could be used by anyone who 312 subscribes to the user, the URI has to be usable by anyone. As a 313 result, it has to be a GRUU. 315 It is interesting to note that the GRUU may need to be constructed by 316 a presence agent, depending on how the presence document is computed 317 by the server. 319 5. Overview of Operation 321 This section is tutorial in nature, and does not specify any 322 normative behavior. 324 This extension allows a UA to obtain a GRUU, and to use a GRUU. 325 These two mechanisms are separate, in that a UA can obtain a GRUU in 326 any way it likes, and use the mechanisms in this specification to use 327 it. This specification defines two mechanisms for obtaining a GRUU - 328 through registrations, and through administrative operation. Only 329 the former requires protocol operations. 331 A UA can obtain a GRUU by generating a normal REGISTER request, as 332 specified in RFC 3261 [1]. This request contains a Supported header 333 field with the value "gruu", indicating to the registrar that the UA 334 supports this extension. The UA includes a "+sip.instance" Contact 335 header field parameter of each contact for which a GRUU is desired. 336 This Contact parameter contains a globally unique ID that identifies 337 the UA instance. If the domain that the user is registering against 338 also supports GRUU, the REGISTER responses will contain the "gruu" 339 parameter in each Contact header field. This parameter contains a 340 GRUU which the domain guarantees will route to that UA instance. The 341 GRUU is associated with the UA instance. Should the client change 342 its contact, but indicate that it represents the same instance ID, 343 the server would provide the same GRUU. Furthermore, if the 344 registration for the contact expires, and the UA registers the 345 contact at a later time with the same instance identifier, the server 346 would provide the same GRUU. 348 Since the GRUU is a URI like any other, it can be handed out by a UA 349 by placing it in any header field which can contain a URI. A UA will 350 place the GRUU into the Contact header field of dialog creating 351 requests and responses it generates; RFC 3261 mandates that the 352 Contact header field have the GRUU property, and this specification 353 provides a reliable way for a UA to obtain one. In other words, 354 clients use the GRUU as a remote target. However, since the remote 355 target used by clients to date has typically not had the GRUU 356 properties, implementations have adapted their behaviors (oftentimes 357 in proprietary ways) to compensate. To facilitate a transition away 358 from these behaviors, it is necessary for a UA receiving the message 359 to know whether the remote target is a GRUU or not. To make this 360 determination, the UA looks for the presence of the Supported header 361 field in the request or response. If it is present with a value of 362 "gruu", it means that the remote target is a GRUU. 364 A domain can construct a GRUU in any way it chooses. However, it is 365 sometimes desirable to construct them in a way which allows for any 366 entity that receives the GRUU to determine the AOR for the subscriber 367 associated with the UA instance. To facilitate that, the GRUU can be 368 constructed such that it is identical to the subscribers AOR, but 369 includes the "opaque" URI parameter. The "opaque" URI parameter 370 provides a general facility to construct a URI (such as a GRUU or a 371 voicemail inbox for a user) that is related to an AOR, such that any 372 element can extract the AOR from the constructed URI by removing the 373 "opaque" parameter. For example: 375 AOR: sip:alice@example.com 376 GRUU: sip:alice@example.com;opaque="kjh29x97us97d" 378 When a proxy in the domain constructs the GRUU, it would set the 379 value of the "opaque" URI parameter such that it includes the 380 instance ID. As such, when that proxy receives a request sent to the 381 GRUU, it can extract the AOR and instance ID, both of which are 382 needed to process the request. 384 When a UA uses a GRUU, it has the option of adding the "grid" URI 385 parameter to the GRUU. This parameter is opaque to the proxy server 386 handling the domain. However, when the server maps the GRUU to the 387 contact bound to it, the server will add the grid parameter into the 388 registered contact, and use the result in the Request URI. As a 389 result, when the UA receives the request, the Request URI will 390 contain the grid parameter it placed in the corresponding GRUU. 392 The "grid" and "opaque" URI parameters play similar roles, but 393 complement each other. The "opaque" parameter is added by the owner 394 of the domain to correlate the GRUU to its instance ID, and to easily 395 recognize that the URI has the GRUU property. The "grid" parameter 396 is added by the UA instance so that, when a request is received by 397 that instance, it can determine the context of the request. 399 6. Creation of a GRUU 401 A GRUU is a URI that is created and maintained by a server 402 authoritative for the domain in which the GRUU resides. 403 Independently of whether the GRUU is created as a result of a 404 registration or some other means, a server maintains certain 405 information associated with the GRUU. This information, and its 406 relationship with the GRUU, is modeled in Figure 3. 408 +-----------+ +-----------+ 409 | | associated | | 410 | |1 with n| | 411 | AOR |<----------------| GRUU | 412 | | | | 413 | | | | 414 +-----------+ +-----------+ 415 ^1 is ^^ |n 416 | bound //0..1 | 417 is| to// |associated 418 bound| // |with 419 to| // | 420 | // | 421 |0..n // V1 422 +-----------+ // +-----------+ 423 | | / 0..n | | 424 | | | | 425 | contact |---------------->| Instance | 426 | |1 has 0..1| ID | 427 | | | | 428 +-----------+ +-----------+ 430 Figure 3 432 The instance ID plays a key role in this specification. It is an 433 identifier, represented with a URN, that uniquely identifies a SIP 434 user agent amongst all other user agents associated with an AOR. For 435 hardware-based user agents, the instance ID would typically be burned 436 into the device at the factory, similar to the way a unique serial 437 number is encoded into each device. For software-based user agents, 438 each installation represents a unique instance. As such, the 439 identifier could be generated on installation and then stored on disk 440 for persistence. 442 A GRUU is associated, in a many-to-one fashion, with the combination 443 of an AOR and instance ID. This combination is referred to as an 444 instance ID/AOR pair. For each GRUU, there is one instance ID/AOR 445 pair, and for each instance ID/AOR pair, there can be one or more 446 GRUU. More than one GRUU might be defined in order to have aliases 447 or URI that are anonymous or have other URI properties. However, 448 this specification doesn't define any way for the client to learn 449 about or use more than a single GRUU for each instance ID/AOR pair. 450 The instance ID/AOR pair serves to uniquely identify a user agent 451 instance servicing a specific AOR. The AOR identifies a resource, 452 such as a user or service within a domain, and the instance ID 453 identifies a specific UA instance servicing requests for that 454 resource. 456 It is important to understand that GRUU is associated with the 457 instance ID/AOR pair, not just the instance ID. For example, if a 458 user registered the contact sip:ua@pc.example.com to the AOR 459 sip:user@example.com, and included a +sip.instance="urn:foo:1" 460 parameter in the Contact header field, and also registered the 461 contact sip:ua-112@pc.example.com with the same +sip.instance Contact 462 header field parameter to a second AOR, say sip:boss@example.com, 463 each of those UA instances would have a different GRUU, since they 464 belong to different AORs. That is the reason why a single instance 465 ID can be associated with multiple GRUU; there would be one such 466 association for each AOR. The same goes for the association of AOR 467 to GRUU; there would be one such association for each instance ID. 469 The contacts that are bound to the GRUU are always the ones that have 470 an instance ID associated with that GRUU. If none of the contacts 471 bound to the AOR have the instance ID associated with the GRUU, then 472 there are no contacts bound to the GRUU. If a contact should become 473 registered to the AOR that has an instance ID equal to the one 474 associated with the GRUU, that contact also becomes bound to the 475 GRUU. If that contact should expire, it will no longer be bound to 476 the AOR, and similarly, it will no longer be bound to the GRUU. The 477 URI of the contact is irrelevant in determining whether it is bound 478 to a particular GRUU; only the instance ID and AOR are important. 480 This specification does not mandate a particular mechanism for 481 construction of the GRUU. Several example approaches are given in 482 Appendix A. However, the GRUU MUST exhibit the following properties: 484 o The domain part of the URI is an IP address present on the public 485 Internet, or, if it is a host name, the resolution procedures of 486 RFC 3263 [2], once applied, result in an IP address on the public 487 Internet. 489 o When a request is sent to the GRUU, it routes to a server that can 490 make sure the request is delivered to the UA instance. For GRUU 491 created through registrations, this means that the GRUU has to 492 route to a proxy server with access to registration data. 494 o A server in the domain can determine that the URI is a GRUU. 496 o For each GRUU, both the SIP and SIPS versions MUST exist. The 497 SIPS URI may not always work, particularly if the proxy cannot 498 establish a secure connection to the client. However, the SIPS 499 URI always exists. 501 Section 8.4 defines additional behaviors that a proxy must exhibit on 502 receipt of a GRUU. 504 When a domain constructs a URI with the GRUU properties, it MAY 505 confer other properties upon this URI as a matter of domain policy. 506 A domain can elect to confer properties like identity, anonymity, and 507 service treatment. There is nothing in this specification that can 508 allow the recipient of the GRUU to determine which of these 509 properties besides the GRUU property itself have been conferred to 510 the URI. 512 The service treatment property merits further discussion. Typically, 513 the services a proxy executes upon receipt of a request sent to a 514 GRUU will be a subset of those executed when a request is sent to the 515 AOR. For requests that are outside of a dialog, it is RECOMMENDED to 516 apply screening types of functions, both automated (such as black and 517 white list screening) and interactive (such as interactive voice 518 response (IVR) applications which confer with the user to determine 519 whether to accept a call). In many cases, the new request is related 520 to an existing dialog, and may be an attempt to join it (using the 521 Join header field [30]) or replace it (using the Replaces header 522 field [31]). In such cases, the UA will typically make its own 523 authorization decisions, allowing the reuqest if the sender can prove 524 it knows the dialog identifiers [19]. In such cases, it might make 525 sense to bypass screening services, but network designers need to 526 carefully consider this, as it depends on the specific type of 527 screening service. 529 However, forwarding services, such as call forwarding, SHOULD NOT be 530 provided for requests sent to a GRUU. The intent of the GRUU is to 531 target a specific UA instance, and this is incompatible with 532 forwarding operations. 534 Mid-dialog requests will also be sent to GRUUs, as they are included 535 as the remote-target in dialog forming requests and responses. In 536 those cases, however, a proxy SHOULD only apply services that are 537 meaningful for mid-dialog requests generally speaking. This excludes 538 screening functions, as well as forwarding ones. 540 The "opaque" URI parameter, defined in Section 9, provides a means 541 for a domain to construct a GRUU such that the AOR associated with 542 the GRUU is readily extractable from the GRUU. Unless the GRUU is 543 meant to also possess the anonymity property, it is RECOMMENDED that 544 GRUUs be constructed using this parameter. 546 Since the GRUU is associated with both the instance ID and AOR, for 547 any particular AOR there can be a potentially infinite number of 548 GRUU, and potentially more than one for each instance ID. However, 549 the instance IDs are only known to the network when an instance 550 actually registers with one. As a result, it is RECOMMENDED that a 551 GRUU be created at the time a contact with an instance ID is first 552 registered to an AOR (even if that registration indicates that the 553 registering UA doesnt even support GRUU), until the time that the AOR 554 is no longer valid in the domain. In this context, the GRUU exists 555 if the domain, upon receiving a request for that GRUU, recognizes it 556 as a GRUU, can determine the AOR and instance ID associated with it, 557 and translate the GRUU to a contact if there is one with that 558 instance ID currently registered. This property of the GRUU can be 559 difficult to achieve through software failures and power outages 560 within a network, and for this reason, the requirement is at 561 RECOMMENDED strength, and not MUST. 563 7. Obtaining a GRUU 565 A GRUU can be obtained in many ways. This document defines two - 566 through registrations, and through administrative operation. 568 7.1 Through Registrations 570 When a GRUU is associated with a user agent that comes and goes, and 571 therefore registers to the network to bind itself to an AOR, a GRUU 572 is provided to the user agent through SIP REGISTER messages. 574 7.1.1 User Agent Behavior 576 7.1.1.1 Generating a REGISTER Request 578 When a UA compliant to this specification generates a REGISTER 579 request (initial or refresh), it MUST include the Supported header 580 field in the request. The value of that header field MUST include 581 "gruu" as one of the option tags. This alerts the registrar for the 582 domain that the UA supports the GRUU mechanism. 584 Furthermore, for each contact for which the UA desires to obtain a 585 GRUU, the UA MUST include a "sip.instance" media feature tag as a UA 586 characteristic [11]. The instance ID MUST identify the UA that is 587 performing the registration. As described in [11], this media 588 feature tag will be encoded in the Contact header field as the 589 "+sip.instance" Contact header field parameter. The value of this 590 parameter MUST be a URN [10]. Usage of a URN is a MUST since it 591 provides a persistent and unique name for the UA instance, allowing 592 it to obtain the same GRUU over time. It also provides an easy way 593 to guarantee uniquess within the AOR. However, this specification 594 does not require a long-lived and persistent instance identifier to 595 properly function, and in some cases, there may be cause to use an 596 identifier with weaker temporal persistence. 598 [11] defines equality rules for callee capabilities parameters, and 599 according to that specification, the "sip.instance" media feature tag 600 will be compared by case sensitive string comparison. This means 601 that the URN will be encapsulated by angle brackets "<" and ">" when 602 it is placed within the quoted string value of the +sip.instance 603 Contact header field parameter. The case sensitive matching rules 604 apply only to the generic usages defined there and in the caller 605 preferences specification [23]. When the instance ID is used in this 606 specification, it is effectively "extracted" from the value in the 607 "sip.instance" media feature tag, and thus equality comparisons are 608 performed using the rules for URN equality specific to the scheme in 609 the URN. If the element performing the comparisons does not 610 understand the URN scheme, it performs the comparisons using the 611 lexical equality rules defined in RFC 2141. Lexical equality may 612 result in two URN being considered unequal when they are actually 613 equal. In this specific usage of URNs, the only element which 614 provides the URN is the SIP UA instance identified by that URN. As a 615 result, the UA instance SHOULD provide lexically equivalent URNs in 616 each registration it generates. This is likely to be normal behavior 617 in any case; clients are not likely to modify the value of the 618 instance ID so that it remains functionally equivalent to previous 619 registrations, but lexigraphically different. 621 A registering UAC SHOULD use a UUID URN [28] in its "+sip.instance" 622 Contact header field parameter. The UUID URN allows for non- 623 centralized computation of a URN based on time, unique names (such as 624 a MAC address) or a random number generator. However, if a different 625 URN scheme is used, the URN MUST be selected such that the instance 626 can be certain that no other instance registering against the same 627 AOR would choose the same URN value. An example of a URN that would 628 not meet the requirements of this specification is the national 629 bibliographic number [16]. Since there is no clear relationship 630 between an SIP UA instance and a URN in this namespace, there is no 631 way a selection of a value can be performed that guarantees that 632 another UA instance doesn't choose the same value. 634 If a UA instance is registering against multiple AOR, it is 635 RECOMMENDED that a UA instance provide a different contact URI for 636 each AOR. This is needed for the UA to determine which GRUU to use 637 as the remote target in responses to incoming dialog forming 638 requests, as discussed in Section 8.1. 640 Besides the procedures discussed above, the REGISTER request is 641 constructed identically to the case where this extension was not 642 understood. Specifically, the contact in the REGISTER request SHOULD 643 NOT contain the gruu Contact header field parameter, and the contact 644 URI itself SHOULD NOT contain the grid parameter defined below. Any 645 such parameters are ignored by the registrar, as the UA cannot 646 propose a GRUU for usage with the contact. 648 If a UA wishes to guarantee that the request is not processed unless 649 the domain supports and uses this extension, it MAY include a Require 650 header field in the request with a value that contains the "gruu" 651 option tag. 653 7.1.1.2 Processing the REGISTER Response 655 If the response is a 2xx, each Contact header field that contained 656 the "+sip.instance" Contact header field parameter may also contain a 657 "gruu" parameter. This parameter contains a SIP or SIPS URI that 658 represents a GRUU corresponding to the UA instance that registered 659 the contact. The URI will be a SIP URI if the To header field in the 660 REGISTER request contained a SIP URI, else it will be a SIPS URI if 661 the To header field in the REGISTER request contained a SIPS URI. 662 Any requests sent to the GRUU URI will be routed by the domain to a 663 contact with that instance ID. The GRUU will not normally change in 664 subsequent 2xx responses to REGISTER. Indeed, even if the UA lets 665 the contact expire, when it re-registers it at any later time, the 666 registrar will normally provide the same GRUU for the same address- 667 of-record and instance ID. However, as discussed above, this 668 property cannot be completely guaranteed, as network failures may 669 make it impossible to provide an identifier that persists for all 670 time. As a result, a UA MUST be prepared to receive a different GRUU 671 for the same instance ID/AOR pair in a subsequent registration 672 response. 674 A non-2xx response to the REGISTER request has no impact on any 675 existing GRUU previously provided to the UA. Specifically, if a 676 previously successful REGISTER request provided the UA with a GRUU, a 677 subsequent failed request does not remove, delete, or otherwise 678 invalidate the GRUU. 680 7.1.2 Registrar Behavior 682 A registrar MAY create a GRUU for a particular instance ID/AOR pair 683 at any time. Of course, if a UA requests a GRUU in a registration, 684 and the registrar has not yet created one, it will need to do so in 685 order to respond to the registration request. However, the registrar 686 can create the GRUU in advance of any request from a UA. 688 A registrar MUST create both the SIP and SIPS versions of the GRUU, 689 such that if the GRUU exists, both URI exist. 691 7.1.2.1 Processing a REGISTER Request 693 A REGISTER request might contain a Require header field; this 694 indicates that the registration has to understand this extension in 695 order to process the request. 697 As the registrar is processing the contacts in the REGISTER request 698 according to the procedures of step 7 in Section 10.3 of RFC 3261, 699 the registrar checks whether each Contact header field in the 700 REGISTER message contains a "+sip.instance" header field parameter. 701 If present, the contact is processed further. If the registrar had 702 not yet created a GRUU for that instance ID/AOR pair, it MUST do so 703 at this time according to the procedures of Section 6. If the 704 contact contained a "gruu" Contact header field parameter, it MUST be 705 ignored by the registrar. A UA cannot suggest or otherwise provide a 706 GRUU to the registrar. 708 Registration processing then continues as defined in RFC 3261. If, 709 after that processing, that contact is bound to the AOR, it also 710 becomes bound to the GRUU associated with that instance ID/AOR pair. 711 If, after that processing, the contact was not bound to the AOR (due, 712 for example, to an expires value of zero), the contact is not bound 713 to the GRUU either. The registrar MUST store the instance ID along 714 with the contact. 716 When generating the 200 (OK) response to the REGISTER request, the 717 procedures of step 8 of Section 10.3 of RFC 3261 are followed. 718 Furthermore, for each Contact header field value placed in the 719 response, if the registrar has stored an instance ID associated with 720 that contact, that instance ID is returned as a Contact header field 721 parameter. If the REGISTER request contained a Supported header 722 field that included the "gruu" option tag, the server MUST add a 723 "gruu" Contact header field parameter to that Contact header field. 724 The value of the gruu parameter is a quoted string containing the URI 725 that is the GRUU for the associated instance ID/AOR pair. If the To 726 header field in the REGISTER request had contained a SIP URI, the SIP 727 version of the GRUU is returned. If the To header field in the 728 REGISTER request had contained a SIPS URI, the SIPS version of the 729 GRUU is returned. 731 If the REGISTER response contains a gruu Contact header field 732 parameter in any of the contacts, the REGISTER response MUST contain 733 a Require header field with the value "gruu". This is because the 734 client needs to extract its GRUU from the REGISTER response, and 735 utilize a GRUU as the remote target of dialog initiating requests and 736 responses. 738 Note that handling of a REGISTER request containing a Contact header 739 field with value "*" and an expiration of 0 still retains the meaning 740 defined in RFC 3261 - all contacts, not just ones with a specific 741 instance ID, are deleted. This removes their binding to the AOR and 742 to any GRUU. 744 Inclusion of a GRUU in the "gruu" Contact header field parameter of a 745 REGISTER response is separate from the computation and storage of the 746 GRUU. It is possible that the registrar has computed a GRUU for one 747 UA, but a different UA that queries for the current set of 748 registrations doesn't understand GRUU. In that case, the REGISTER 749 response sent to that second UA would not contain the "gruu" Contact 750 header field parameter, even though the UA has a GRUU for that 751 contact. 753 7.1.2.2 Timing Out a Registration 755 When a registered contact expires, its binding to the AOR is removed 756 as normal. In addition, its binding to the GRUU is removed at the 757 same time. 759 7.2 Administratively 761 Administrative creation of GRUUs is useful when a UA instance is a 762 network server that is always available, and therefore doesn't 763 register to the network. Examples of such servers are voicemail 764 servers, application servers, and gateways. 766 There are no protocol operations required to administratively create 767 a GRUU. The proxy serving the domain is configured with the GRUU, 768 and with the contact it should be translated to. It is not strictly 769 necessary to also configure the instance ID and AOR, since the 770 translation can be done directly. However, they serve as a useful 771 tool for determining which resource and UA instance the GRUU is 772 supposed to map to. 774 In addition to configuring the GRUU and its associated contact in the 775 proxy serving the domain, the GRUU will also need to be configured 776 into the UA instance associated with the GRUU. 778 It is also reasonable to model certain network servers as logically 779 containing both a proxy and a UA instance. The proxy receives the 780 request from the network, and passes it internally to the UA 781 instance. In such a case, the GRUU routes directly to the server, 782 and there is no need for a translation of the GRUU to a contact. The 783 server itself would construct its own GRUU. 785 8. Using the GRUU 787 8.1 Sending a Message Containing a GRUU 789 A UA first obtains a GRUU using the procedures of Section 7, or by 790 other means outside the scope of this specification. 792 A UA can use the GRUU in the same way it would use any other SIP or 793 SIPS URI. However, a UA compliant to this specification MUST use a 794 GRUU when populating the Contact header field of dialog-creating 795 requests and responses. In other words, a UA compliant to this 796 specification MUST use its GRUU as its remote target. This includes 797 the INVITE request and its 2xx response, the SUBSCRIBE [6] request, 798 its 2xx response, the NOTIFY request, and the REFER [7] request and 799 its 2xx response. 801 If the UA instance has obtained multiple GRUUs for different AOR as a 802 result of a registration, it MUST use one corresponding to the AOR 803 used to send or receive the request. For sending a request, this 804 means that the GRUU corresponds to the AOR present in the From header 805 field, and furthermore the credentials used for authentication of the 806 request correspond to the ones associated with that AOR. When 807 receiving a request, the GRUU in the response corresponds to the AOR 808 to which the original request was targeted. That AOR, however, will 809 be rewritten by the proxy to correspond to the UA's registered 810 contact. It is for this reason that different contacts are needed 811 for each AOR that an instance registers against. In this way, when 812 an incoming request arrives, the Request URI can be examined. It 813 will be equal to a registered contact. That contact can be used to 814 map directly to the AOR, and from there, the correct GRUU can be 815 selected. 817 In those requests and responses where a GRUU is used as the remote 818 target, the UA MUST include a Supported header field that contains 819 the option tag "gruu". However, it is not necessary for a UA to know 820 whether or not its peer in the dialog supports this specification 821 before using one as a remote target. 823 When using a GRUU as a remote target, a UA MAY add the "grid" URI 824 parameter to the GRUU. This parameter MAY take on any value 825 permitted by the grammar for the parameter. When a UA sends a 826 request to the GRUU, the proxy for the domain that owns the GRUU will 827 translate the GRUU in the Request-URI, replacing it with the contact 828 bound to that GRUU. However, it will retain the "grid" parameter 829 when this translation is performed. As a result, when the UA 830 receives the request, the Request-URI will contain the "grid" created 831 by the UA. This allows the UA to effectively manufacture an infinite 832 supply of GRUU, each of which differs by the value of the "grid" 833 parameter. When a UA receives a request that was sent to the GRUU, 834 it will be able to tell which GRUU was invoked by looking at the 835 "grid" parameter. 837 An implication of this behavior is that all mid-dialog requests will 838 be routed through intermediate proxies. There will never be direct, 839 UA to UA signaling unless the UA is co-resident with the proxy (which 840 is the case for administratively constructed GRUU). It is 841 anticipated that this limitation will be addressed in future 842 specifications. 844 Once a UA knows that the remote target provided by its peer is a 845 GRUU, it can use it in any application or SIP extension which 846 requires a globally routable URI to operate. One such example is 847 assisted call transfer. 849 8.2 Sending a Message to a GRUU 851 There is no new behavior associated with sending a request to a GRUU. 852 A GRUU is a URI like any other. When a UA receives a request or 853 response, it can know that the remote target is a GRUU if the request 854 or response had a Supported header field that included the value 855 "gruu". The UA can take the GRUU, and send a request to it, and then 856 be sure that it is delivered to the UA instance which sent the 857 request or response. 859 If the GRUU contains the "opaque" URI parameter, a UA can obtain the 860 AOR for the user by stripping the parameter. The resulting URI is 861 the AOR. If the GRUU does not have the "opaque" URI parameter, there 862 is no mechanism defined for determining the AOR from the GRUU. 863 Extraction of the AOR from the GRUU is useful for call logs and other 864 accounting functions, where it is desirable to know the user to whom 865 the request was directed. 867 Since the instance ID is a callee capabilities parameter, a UA might 868 be tempted to send a request to the AOR of a user, and include an 869 Accept-Contact header field [23] which indicates a preference for 870 routing the request to a UA with a specific instance ID. Although 871 this would appear to have the same effect as sending a request to the 872 GRUU, it does not. The caller preferences expressed in the Accept- 873 Contact header field are just preferences. Its efficacy depends on a 874 UA constructing an Accept-Contact header field that interacts with 875 domain processing logic for an AOR, to cause it to route to a 876 particular instance. Given the variability in routing logic in a 877 domain (for example, time based routing to only selected contacts), 878 this doesn't work for many domain routing policies. However, this 879 specification does not forbid a client from attempting such a 880 request, as there may be cases where the desired operation truly is a 881 preferential routing request. 883 8.3 Receiving a Request Sent to a GRUU 885 When a UAS receives a request sent to its GRUU, the incoming request 886 URI will be equal to the contact that was registered (through 887 REGISTER or some other action) by that UA instance. If the user 888 agent had previously handed out its GRUU with a grid parameter, the 889 incoming request URI may contain that parameter. This indicates to 890 the UAS that the request is being received as a result of a request 891 sent by the UAC to that GRUU/grid combination. This specification 892 makes no normative statements about when to use a grid parameter, or 893 what to do when receiving a request made to a GRUU/grid combination. 894 Generally, any differing behaviors are a matter of local policy. 896 It is important to note that, when a user agent receives a request, 897 and the request URI does not have a grid parameter, the user agent 898 cannot tell by inspection of the Request URI whether the request was 899 sent to the AOR or to the GRUU. The To header field might be 900 different, but due to forwarding cannot be depended on as a 901 differentiator. As such, the UAS will process such requests 902 identically. If a user agent needs to differentiate its behavior 903 based on these cases, it will need to use a grid parameter. 905 8.4 Proxy Behavior 907 Proxy behavior is fully defined in Section 16 of RFC 3261. GRUU 908 processing impacts that processing in two places - request targeting 909 and record-routing. 911 8.4.1 Request Targeting 913 When a proxy server receives a request, and the proxy owns the domain 914 in the Request URI, and the proxy is supposed to access a Location 915 Service in order to compute request targets (as specified in Section 916 16.5 of RFC 3261 [1]), the proxy examines the Request URI. If the 917 Request URI is an AOR against which there are multiple registered 918 contacts with the same instance ID parameter, the proxy MUST populate 919 the target set such that there is never more than one contact at a 920 time with a given instance ID. It is RECOMMENDED that the most 921 recently registered contact be used. It is expected that standards 922 track extensions will be developed that provide additional criteria 923 for selecting which contact to use [18]. 925 The contact that is the most recently registered is the one that 926 has been bound to the AOR is the shortest period of time. This 927 corresponds to the minimum value for the "duration-registered" 928 attribute from the registration event package [29]. It is 929 important to note that a refresh of the contact in a REGISTER 930 message does not reset the duration it has been registered to 931 zero. For example, if a softphone is started at 9am when a user 932 logs into their computer, and the softphone refreshes its 933 registration every hour, by 1230pm the contact has been registered 934 for three and a half hours. 936 If the request URI is within the domain of the proxy, and the URI has 937 been constructed by the domain such that the proxy is able to 938 determine that it has the form of a GRUU for an AOR that is unknown 939 within the domain, the proxy rejects the request with a 404. If the 940 request URI is within the domain of the proxy, and the URI has been 941 constructed by the domain such that the proxy is able to determine 942 that it has the form of a GRUU for an AOR that known within the 943 domain, but the instance ID is unknown, the proxy SHOULD generate a 944 480. 946 If the GRUU does exist, handling of the GRUU proceeds as specified in 947 RFC 3261 Section 16. For GRUUs, the abstract location service 948 described in Section 16.5 is utilized, producing a set of zero or 949 more contacts, each of which is associated with the same instance ID. 950 If there is more than one contact bound to the GRUU, the proxy MUST 951 populate the target set such that there is never more than one 952 contact at a time. It is RECOMMENDED that the most recently 953 registered contact be used. This produces zero or one contacts. The 954 server MUST copy the grid parameter from the Request URI, if present, 955 into the new target URI obtained from the registered contact. If the 956 grid was already present in the contact bound to the GRUU, it is 957 overwritten in this process. If no contacts were bound to the GRUU, 958 the lookup of the GRUU in the abstract location service will result 959 in zero target URI, eventually causing the proxy to reject the 960 request with a 480 (Temorarily Unavailable) response. 962 If the contact had been registered using a Path header field [3], 963 then that Path is used to construct the route set for reaching that 964 contact through the GRUU as well as through the AOR, using the 965 procedures specified in RFC 3327. Support for GRUU at a registrar 966 does not require support for RFC 3327, however. 968 A proxy MAY apply other processing to the request, such as execution 969 of called party features, as discussed in Section 6. 971 A request sent to a GRUU SHOULD NOT be redirected. In many 972 instances, a GRUU is used by a UA in order to assist in the traversal 973 of NATs and firewalls, and a redirection may prevent such a case from 974 working. 976 8.4.2 Record Routing 978 As described above, a user agent uses its GRUU as a remote target. 979 This has an impact on the path taken by subsequent mid-dialog 980 requests. Depending on the desires of the proxies involved, this may 981 impact record route processing. 983 Two cases can be considered. The first is shown in Figure 4. In 984 this case, there is a single proxy in the user's domain. An incoming 985 INVITE request arrives for the users AOR (1) and is forwarded to the 986 user agent at its registered contact C1 (2). The proxy inserts a 987 Record-Route header field into the proxied request, with a value of 988 R1. The user agent generates a 200 OK to the request, using its GRUU 989 G1 as the remote target. 991 (1) + (2): initial INVITE 992 (2) + (3): mid-dialog request 994 (1) +-----------+ (2) +-----------+ 995 ------>| Proxy |--------------->| User | 996 | | | Agent | 997 (3) | | (4) | | 998 ------>|R1 |--------------->|G1 | 999 | | | | 1000 +-----------+ +-----------+ 1002 Figure 4 1004 When a mid-dialog request shows up destined for the user agent 1005 (message 3), it will arrive at the proxy in the following form: 1007 INVITE G1 1008 Route: R1 1010 Since the top Route header field value identifies the proxy, the 1011 proxy removes it. As there are no more Route header field values, 1012 the proxy processes the request URI. However, the request URI is a 1013 GRUU, and is therefore a domain under the control of the proxy. The 1014 proxy will need to perform the processing of Section 8.4.1, which 1015 will result in the translation of the GRUU into the contact C1, 1016 followed by transmission of the request to the user agent (message 1017 4). 1019 This sequence of processing in the proxy is somewhat unusual, in that 1020 mid-dialog requests (that is, requests with a Route header field that 1021 a proxy inserted as a result of a Record-Route operation) do not 1022 normally cause a proxy to have to invoke a location service to 1023 process the request URI. It is for this reason that this is called 1024 out here. 1026 The previous case assumed that there was a single proxy in the 1027 domain. In more complicated cases, there can be two or more proxies 1028 within a domain on the initial request path. This is shown in 1029 Figure 6. In this figure, there is a home proxy, to which requests 1030 targeted to the AOR are sent. The home proxy executes the abstract 1031 location service and runs user features. The edge proxy acts as the 1032 outbound proxy for users, performs authentication, manages TCP/TLS 1033 connections to the client, and does other functions associated with 1034 the transition from the provider proxy network to the client. This 1035 specific division of responsibilities between home and edge proxy is 1036 just for the purposes of illustration; the discussion applies to a 1037 disaggregation of proxy logic into any number of proxies. In such a 1038 configuration, registrations from the user agent would pass through 1039 the edge proxy, which would insert a Path header field [3] for 1040 itself. 1042 (1) + (2) + (3): initial INVITE 1043 (4) - (9): mid-dialog request 1045 (1) +-----------+ (2) +-----------+ (3) +-----------+ 1046 ---->| |------->| |-------->| | 1047 (4) | | (5) | | | | 1048 ---->|H1 Home |------->|E1 Edge | | User | 1049 (7) | Proxy | (8) | Proxy | (9) | Agent | 1050 +-->|G1 |------->| |-------->| | 1051 | +-----------+ +-----------+ +-----------+ 1052 | | 1053 | | 1054 +------------------------------+ 1055 (6) 1057 Figure 6 1059 When an incoming request arrives for the AOR (message 1), the home 1060 proxy would look it up, discover the registered contact and Path, and 1061 then send the request to the edge proxy as a result of the Route 1062 header field inserted with the Path value. The home proxy record 1063 routes with the URI H1. The edge proxy would forward the request to 1064 the request URI (which points to the client), and insert a Record- 1065 Route header field value with the URI E1 (message 2). This request 1066 is accepted by the user agent, which inserts its GRUU G1 as the 1067 remote target. 1069 When the peer in the dialog sends a mid-dialog request, it will have 1070 the following form: 1072 INVITE G1 1073 Route: H1, E1 1075 This request will arrive at the home proxy (due to H1 in the Route 1076 header field) (message 4). The home proxy will forward it to the 1077 edge proxy (due to E1 in the Route header field) (message 5). The 1078 edge proxy, seeing no more Route header field values, sends the 1079 request to the Request URI. This is a GRUU, and like an AOR, will 1080 route to the home proxy. This causes the request to loop back around 1081 (message 6). The home proxy performs the GRUU processing of 1082 Section 8.4.1, causing the request to be forwarded to the edge proxy 1083 a second time (this time, as a result of a Route header field value 1084 obtained from the Path header in the registration) (message 7), and 1085 then delivered to the client (message 8). 1087 While this flow works, it is highly inefficient, as it causes each 1088 mid-dialog request to spiral route. This behavior is not desirable. 1089 To prevent it, the following procedures SHOULD be followed. When a 1090 client generates a REGISTER request, this request passes through the 1091 edge proxy on its way to the home proxy. The REGISTER request will 1092 contain the AOR of the user (in the To header field). If the client 1093 is registering an instance, there will be one or more Contact header 1094 field values with the +sip.instance Contact header field parameter, 1095 and a Supported header field that includes the value "gruu". 1096 Normally there would be just one Contact header field value with an 1097 instance ID, but it is possible for there to be more than one. All, 1098 however, are required to identify the instance performing the 1099 registration. 1101 The proxy can decide to insert itself on the Path for a particular 1102 AOR on a case by case basis. However, if it does so for one 1103 registration, it SHOULD do so for all registrations for the same AOR 1104 that contain an instance ID in the contact. The value of the Path 1105 header field inserted by the proxy SHOULD be constructed so that it 1106 indicates whether or not the proxy inserted itself on the Path for 1107 this AOR. 1109 When a request arrives from the home proxy towards the client, the 1110 proxy inspects the Route header field. This header field will 1111 contain the URI the edge proxy had placed into the Path. If the 1112 value indicates that the edge proxy had put itself on the Path for 1113 the registration from this client, there is no need for the proxy to 1114 retain its record-route in the response. The proxy MAY remove its 1115 record-route value from the 200 OK response in this case. If the 1116 value indicates that the proxy had not put itself on the Path, it 1117 would retain the Record-Route in the response. 1119 Similarly, if a request arrives from the client towards the home 1120 proxy, the edge proxy would look at the identity of the sender of the 1121 request. If the proxy knows that it is placing itself on the Path 1122 for registrations from that AOR, and the request contains a Supported 1123 header field with the value "gruu", the edge proxy would insert a 1124 Record-Route into the request, and then remove it in the response. 1125 Similarly, if the identity of the sender of the request is one for 1126 which the client has not put itself on the Path, the edge proxy would 1127 keep its Record-Route in the response. 1129 Removing its Record-Route value from the response will result in a 1130 different route set as seen by the caller and callee; the callee 1131 (which is the user agent in the figure) will have a route set entry 1132 for its edge proxy, while the caller will not. The caller will have 1133 a route set entry for its edge proxy, while the callee will not. 1135 In such a case, a mid-dialog request that arrives at the home proxy 1136 will be of the form: 1138 INVITE G1 1139 Route: H1 1141 This does the "right thing" and causes the request to be routed from 1142 the home proxy to the edge proxy to the client, without the 1143 additional spiral. 1145 9. The opaque SIP URI Parameter 1147 This specification defines a new SIP URI parameter, "opaque". The 1148 "opaque" URI parameter is used to construct a URI (called the derived 1149 URI) that is related to another URI (called the base URI, frequently 1150 an AOR) in some way. In this specification, the parameter is used to 1151 construct the GRUU (which is the derived URI) from the AOR (which is 1152 the base URI). However, there are many other applications outside of 1153 GRUU. It can be used, for example, to construct a URI for a 1154 voicemail inbox (the derived URI) from a subscribers AOR (the base 1155 URI), or the URI for a video service advertised via presence [26] 1156 (the derived URI) from the subscribers AOR (the base URI). 1158 To construct a derived URI, the owner of the domain adds the "opaque" 1159 URI parameter to the base URI, resulting in the derived URI. In 1160 fact, these are the only semantics associated with the "opaque" URI 1161 parameter: a URI containing the parameter MUST be related to another 1162 URI, obtained by stripping the "opaque" URI parameter. Because the 1163 "opaque" URI parameter implies a relationship, any element (including 1164 ones outside of the domain that owns the URI) that receives a URI 1165 with the "opaque" URI parameter will know definitively that it is a 1166 derived URI, and can strip it to obtain the base URI. 1168 The value of the "opaque" URI parameter is not relevant to anyone 1169 except for the owner of the domain. It typically contains 1170 information needed by the owner of the domain to correctly process a 1171 request targeted to that URI according to the desired semantics of 1172 the URI. As such, the parameter is a form of cookie. In the case of 1173 a GRUU, the "opaque" URI parameter contains enough information for 1174 the owner of the domain to determine the instance ID. Since the 1175 structure of its value is not subject to standardization, it can only 1176 be interpreted by the same proxy or cluster of proxies that created 1177 the derived URI. For this reason, a proxy or cluster of proxies MUST 1178 NOT create a derived URI unless a request sent to the base URI (and 1179 consequently the derived URI) will be routed back to that same proxy 1180 or cluster of proxies without any upstream proxies requiring 1181 interpretation of the "opaque" URI parameter. Simply put, a request 1182 sent to a derived URI has to get back to the same proxy farm that 1183 created the derived URI. 1185 The presence of the "opaque" URI parameter in a URI implies a 1186 relationship between that URI and its base URI. However, the nature 1187 of that relationship cannot be determined from inspection of the URI 1188 alone. In some cases, there may be no way to know the relationship 1189 outside of the domain that constructed the URI. In other cases, the 1190 nature of the relationship is determined from the context in which 1191 the URI was obtained. When used to construct a GRUU, it means that 1192 the URI formed by stripping the "opaque" parameter corresponds to the 1193 AOR associated with the GRUU. The recipient of a GRUU cannot 1194 determine that it is a GRUU by direct examination of the URI. 1195 However, the recipient may know if it received the GRUU in the 1196 Contact header field of a SIP request or response that contained a 1197 Supported header field with the option tag "gruu". If it knows its a 1198 GRUU through such context, and the GRUU contains the "opaque" 1199 parameter, the UA knows it can obtain the AOR by removing the 1200 "opaque" parameter. 1202 10. Grammar 1204 This specification defines two new Contact header field parameters, 1205 gruu and +sip.instance, and two new URI parameters, "grid" and 1206 "opaque". The grammar for string-value is obtained from [11], and 1207 the grammar for uric is defined in RFC 3986 [9]. 1209 contact-params = c-p-q / c-p-expires / c-p-gruu / cp-instance 1210 / contact-extension 1211 c-p-gruu = "gruu" EQUAL DQUOTE (SIP-URI / SIPS-URI) DQUOTE 1212 cp-instance = "+sip.instance" EQUAL LDQUOT "<" 1213 instance-val ">" RDQUOT 1214 uri-parameter = transport-param / user-param / method-param 1215 / ttl-param / maddr-param / lr-param / grid-param 1216 / opaque-param / other-param 1217 grid-param = "grid=" pvalue ; defined in RFC3261 1218 opaque-param = "opaque=" pvalue ; defined in RFC3261 1219 instance-val = *uric ; defined in RFC 2396 1221 11. Requirements 1223 This specification was created in order to meet the following 1224 requirements: 1226 REQ 1: When a UA invokes a GRUU, it MUST cause the request to be 1227 routed to the specific UA instance to which the GRUU refers. 1229 REQ 2: It MUST be possible for a GRUU to be invoked from anywhere on 1230 the Internet, and still cause the request to be routed 1231 appropriately. That is, a GRUU MUST NOT be restricted to use 1232 within a specific addressing realm. 1234 REQ 3: It MUST be possible for a GRUU to be constructed without 1235 requiring the network to store additional state. 1237 REQ 4: It MUST be possible for a UA to obtain a multiplicity of 1238 GRUUs, each one of which routes to that UA instance. This is 1239 needed to support ad-hoc conferencing, for example, where a UA 1240 instance needs a different URI for each conference it is hosting. 1242 REQ 5: When a UA receives a request sent to a GRUU, it MUST be 1243 possible for the UA to know the GRUU which was used to invoke the 1244 request. This is necessary as a consequence of requirement 4. 1246 REQ 6: It MUST be possible for a UA to add opaque content to a GRUU, 1247 which is not interpreted or altered by the network, and used only 1248 by the UA instance to whom the GRUU refers. This provides a basic 1249 cookie type of functionality, allowing a UA to build a GRUU with 1250 state embedded within it. 1252 REQ 7: It MUST be possible for a proxy to execute services and 1253 features on behalf of a UA instance represented by a GRUU. As an 1254 example, if a user has call blocking features, a proxy may want to 1255 apply those call blocking features to calls made to the GRUU in 1256 addition to calls made to the user's AOR. 1258 REQ 8: It MUST be possible for a UA in a dialog to inform its peer of 1259 its GRUU, and for the peer to know that the URI represents a GRUU. 1260 This is needed for the conferencing and dialog reuse applications 1261 of GRUUs, where the URIs are transferred within a dialog. 1263 REQ 9: When transferring a GRUU per requirement 8, it MUST be 1264 possible for the UA receiving the GRUU to be assured of its 1265 integrity and authenticity. 1267 REQ 10: It MUST be possible for a server, authoritative for a domain, 1268 to construct a GRUU which routes to a UA instance bound to an AOR 1269 in that domain. In other words, the proxy can construct a GRUU 1270 too. This is needed for the presence application. 1272 12. Example Call Flow 1274 The following call flow shows a basic registration and call setup, 1275 followed by a subscription directed to the GRUU. It then shows a 1276 failure of the callee, followed by a re-registration. The 1277 conventions of [22] are used to describe representation of long 1278 message lines. 1280 Caller Proxy Callee 1281 | |(1) REGISTER | 1282 | |<--------------------| 1283 | |(2) 200 OK | 1284 | |-------------------->| 1285 |(3) INVITE | | 1286 |-------------------->| | 1287 | |(4) INVITE | 1288 | |-------------------->| 1289 | |(5) 200 OK | 1290 | |<--------------------| 1291 |(6) 200 OK | | 1292 |<--------------------| | 1293 |(7) ACK | | 1294 |-------------------->| | 1295 | |(8) ACK | 1296 | |-------------------->| 1297 |(9) SUBSCRIBE | | 1298 |-------------------->| | 1299 | |(10) SUBSCRIBE | 1300 | |-------------------->| 1301 | |(11) 200 OK | 1302 | |<--------------------| 1303 |(12) 200 OK | | 1304 |<--------------------| | 1305 | |(13) NOTIFY | 1306 | |<--------------------| 1307 |(14) NOTIFY | | 1308 |<--------------------| | 1309 |(15) 200 OK | | 1310 |-------------------->| | 1311 | |(16) 200 OK | 1312 | |-------------------->| 1313 | | |Crashes, 1314 | |(17) REGISTER | Reboots 1315 | |<--------------------| 1316 | |(18) 200 OK | 1317 | |-------------------->| 1319 The Callee supports the GRUU extension. As such, its REGISTER (1) 1320 looks like: 1322 REGISTER sip:example.com SIP/2.0 1323 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 1324 Max-Forwards: 70 1325 From: Callee ;tag=a73kszlfl 1326 Supported: gruu 1327 To: Callee 1328 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 1329 CSeq: 1 REGISTER 1330 Contact: 1331 ;+sip.instance="" 1332 Content-Length: 0 1334 The REGISTER response would look like: 1336 SIP/2.0 200 OK 1337 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 1338 From: Callee ;tag=a73kszlfl 1339 To: Callee ;tag=b88sn 1340 Require: gruu 1341 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 1342 CSeq: 1 REGISTER 1343 1344 Contact: 1345 ;gruu="sip:callee@example.com; 1346 opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 1347 ;+sip.instance="" 1348 ;expires=3600 1349 1350 Content-Length: 0 1352 Note how the Contact header field in the REGISTER response contains 1353 the gruu parameter with the URI sip:callee@ 1354 example.com;opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6. 1355 This represents a GRUU that translates to the contact 1356 sip:callee@192.0.2.1. 1358 The INVITE from the caller is a normal SIP INVITE. The 200 OK 1359 generated by the callee (message 5), however, now contains a GRUU as 1360 the remote target. The UA has also chosen to include a grid URI 1361 parameter into the GRUU. 1363 SIP/2.0 200 OK 1364 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8 1365 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a 1366 From: Caller ;tag=n88ah 1367 To: Callee ;tag=a0z8 1368 Call-ID: 1j9FpLxk3uxtma7@host.example.com 1369 CSeq: 1 INVITE 1370 Supported: gruu 1371 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 1372 1373 Contact: 1374 1376 1377 Content-Length: -- 1378 Content-Type: application/sdp 1380 [SDP Not shown] 1382 At some point later in the call, the caller decides to subscribe to 1383 the dialog event package [21] at that specific UA. To do that, it 1384 generates a SUBSCRIBE request (message 9), but directs it towards the 1385 remote target, which is a GRUU: 1387 1388 SUBSCRIBE sip:callee@example.com;opaque=urn:uuid:f8 1389 1d4fae-7dec-11d0-a765-00a0c91e6bf6;grid=99a 1390 SIP/2.0 1391 1392 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 1393 From: Caller ;tag=kkaz- 1394 1395 To: sip:callee@example.com;opaque=urn:uuid:f8 1396 1d4fae-7dec-11d0-a765-00a0c91e6bf6;grid=99a 1397 1398 Call-ID: faif9a@host.example.com 1399 CSeq: 2 SUBSCRIBE 1400 Supported: gruu 1401 Event: dialog 1402 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 1403 Contact: 1404 Content-Length: 0 1406 In this example, the caller itself supports the GRUU extension, and 1407 is using its own GRUU to populate its remote target. 1409 This request is routed to the proxy, which proceeds to perform a 1410 location lookup on the request URI. It is translated into the 1411 contact for that instance, and then proxied there (message 10 below). 1412 Note how the grid parameter is maintained. 1414 SUBSCRIBE sip:callee@192.0.2.1;grid=99a SIP/2.0 1415 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK9555 1416 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 1417 From: Caller ;tag=kkaz- 1418 1419 To: sip:callee@example.com;opaque=urn:uuid:f8 1420 1d4fae-7dec-11d0-a765-00a0c91e6bf6;grid=99a 1421 1422 Call-ID: faif9a@host.example.com 1423 CSeq: 2 SUBSCRIBE 1424 Supported: gruu 1425 Event: dialog 1426 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 1427 Contact: 1428 Content-Length: 0 1430 At some point after message 16 is received, the callee's machine 1431 crashes and recovers. It obtains a new IP address, 192.0.2.2. 1432 Unaware that it had previously had an active registration, it creates 1433 a new one (message 17 below). Notice how the instance ID remains the 1434 same, as it persists across reboot cycles: 1436 REGISTER sip:example.com SIP/2.0 1437 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba 1438 Max-Forwards: 70 1439 From: Callee ;tag=ha8d777f0 1440 Supported: gruu 1441 To: Callee 1442 Call-ID: hf8asxzff8s7f@192.0.2.2 1443 CSeq: 1 REGISTER 1444 Contact: 1445 ;+sip.instance="" 1446 Content-Length: 0 1448 The registrar notices that a different contact, sip:callee@192.0.2.1, 1449 is already associated with the same instance ID. It registers the 1450 new one too and returns both in the REGISTER response. Both have the 1451 same GRUU. However, only this new contact (the most recently 1452 registered one) will be used by the proxy for population in the 1453 target set. It then generates the following response: 1455 SIP/2.0 200 OK 1456 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba 1457 From: Callee ;tag=ha8d777f0 1458 To: Callee ;tag=99f8f7 1459 Require: gruu 1460 Call-ID: hf8asxzff8s7f@192.0.2.2 1461 CSeq: 1 REGISTER 1462 1463 Contact: 1464 ;gruu="sip:callee@example.com;opaque=urn: 1465 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 1466 ;+sip.instance="" 1467 ;expires=3600 1468 1469 Contact: 1470 ;gruu="sip:callee@example.com;opaque=urn: 1471 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 1472 ;+sip.instance="" 1473 ;expires=400 1474 1475 Content-Length: 0 1477 13. Security Considerations 1479 It is important for a UA to be assured of the integrity of a GRUU 1480 when it is given one in a REGISTER response. If the GRUU is tampered 1481 with by an attacker, the result could be denial of service to the UA. 1482 As a result, it is RECOMMENDED that a UA use the SIPS URI scheme in 1483 the Request-URI when registering. Proxies and registrars MUST 1484 support the sips URI and MUST support TLS. Note that this does not 1485 represent a change from the requirements in RFC 3261. 1487 The example GRUU construction algorithm in Appendix A.1 makes no 1488 attempt to create a GRUU that hides the AOR and instance ID 1489 associated with the GRUU. In general, determination of the AOR 1490 associated with a GRUU is considered a good property, since it allows 1491 for easy tracking of the target of a particular call. Learning the 1492 instance ID provides little benefit to an attacker. To register or 1493 otherwise impact registrations for the user, an attacker would need 1494 to obtain the credentials for the user. Knowing the instance ID is 1495 insufficient. 1497 The example GRUU construction algorithm in Appendix A.1 makes no 1498 attempt to create a GRUU that prevents users from guessing a GRUU 1499 based on knowledge of the AOR and instance ID. A user that is able 1500 to do that will be able to direct a new request at a particular 1501 instance. However, this specification recommends that service 1502 treatment be given to requests that are sent to a GRUU, including 1503 screening features in particular. That treatment will make sure that 1504 the GRUU does not provide a back door for attackers to contact a user 1505 that has tried to block the attacker. 1507 GRUUs do not provide a solution for privacy. In particular, since 1508 the GRUU does not change during the lifetime of a registration, an 1509 attacker could correlate two calls as coming from the same source, 1510 which in and of itself reveals information about the caller. 1511 Furthermore, GRUUs do not address other aspects of privacy, such as 1512 the addresses used for media transport. For a discussion of how 1513 privacy services are provided in SIP, see RFC 3323 [14]. 1515 14. IANA Considerations 1517 This specification defines a new Contact header field parameter, two 1518 SIP URI parameters, a media feature tag and a SIP option tag. 1520 14.1 Header Field Parameter 1522 This specification defines a new header field parameter, as per the 1523 registry created by [12]. The required information is as follows: 1525 Header field in which the parameter can appear: Contact 1527 Name of the Parameter: gruu 1529 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1530 RFC number of this specification.]] 1532 14.2 URI Parameters 1534 This specification defines two new SIP URI parameters, as per the 1535 registry created by [13]. 1537 Name of the Parameter: grid 1539 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1540 RFC number of this specification.]] 1542 Name of the Parameter: opaque 1544 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1545 RFC number of this specification.]] 1547 14.3 Media Feature Tag 1549 This section registers a new media feature tag, per the procedures 1550 defined in RFC 2506 [8]. The tag is placed into the sip tree, which 1551 is defined in [11]. 1553 Media feature tag name: sip.instance 1555 ASN.1 Identifier: New assignment by IANA. 1557 Summary of the media feature indicated by this tag: This feature tag 1558 contains a string containing a URN that indicates a unique 1559 identifier associated with the UA instance registering the 1560 Contact. 1562 Values appropriate for use with this feature tag: String. 1564 The feature tag is intended primarily for use in the following 1565 applications, protocols, services, or negotiation mechanisms: This 1566 feature tag is most useful in a communications application, for 1567 describing the capabilities of a device, such as a phone or PDA. 1569 Examples of typical use: Routing a call to a specific device. 1571 Related standards or documents: RFC XXXX [[Note to IANA: Please 1572 replace XXXX with the RFC number of this specification.]] 1574 Security Considerations: This media feature tag can be used in ways 1575 which affect application behaviors. For example, the SIP caller 1576 preferences extension [23] allows for call routing decisions to be 1577 based on the values of these parameters. Therefore, if an 1578 attacker can modify the values of this tag, they may be able to 1579 affect the behavior of applications. As a result of this, 1580 applications which utilize this media feature tag SHOULD provide a 1581 means for ensuring its integrity. Similarly, this feature tag 1582 should only be trusted as valid when it comes from the user or 1583 user agent described by the tag. As a result, protocols for 1584 conveying this feature tag SHOULD provide a mechanism for 1585 guaranteeing authenticity. 1587 14.4 SIP Option Tag 1589 This specification registers a new SIP option tag, as per the 1590 guidelines in Section 27.1 of RFC 3261. 1592 Name: gruu 1594 Description: This option tag is used to identify the Globally 1595 Routable User Agent URI (GRUU) extension. When used in a 1596 Supported header, it indicates that a User Agent understands the 1597 extension, and has included a GRUU in the Contact header field of 1598 its dialog initiating requests and responses. When used in a 1599 Require header field of a REGISTER request, it indicates that the 1600 registrar should assign a GRUU to the Contact URI. 1602 15. Acknowledgements 1604 The author would like to thank Rohan Mahy, Paul Kyzivat, Alan 1605 Johnston, and Cullen Jennings for their contributions to this work. 1607 16. References 1609 16.1 Normative References 1611 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1612 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1613 Session Initiation Protocol", RFC 3261, June 2002. 1615 [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1616 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1618 [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 1619 Extension Header Field for Registering Non-Adjacent Contacts", 1620 RFC 3327, December 2002. 1622 [4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1623 Method", RFC 3311, October 2002. 1625 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1626 Levels", BCP 14, RFC 2119, March 1997. 1628 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1629 Notification", RFC 3265, June 2002. 1631 [7] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1632 Method", RFC 3515, April 2003. 1634 [8] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 1635 Registration Procedure", BCP 31, RFC 2506, March 1999. 1637 [9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1638 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 1639 January 2005. 1641 [10] Moats, R., "URN Syntax", RFC 2141, May 1997. 1643 [11] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1644 User Agent Capabilities in the Session Initiation Protocol 1645 (SIP)", RFC 3840, August 2004. 1647 [12] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1648 Header Field Parameter Registry for the Session Initiation 1649 Protocol (SIP)", BCP 98, RFC 3968, December 2004. 1651 [13] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1652 Uniform Resource Identifier (URI) Parameter Registry for the 1653 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, 1654 December 2004. 1656 16.2 Informative References 1658 [14] Peterson, J., "A Privacy Mechanism for the Session Initiation 1659 Protocol (SIP)", RFC 3323, November 2002. 1661 [15] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 1662 - Simple Traversal of User Datagram Protocol (UDP) Through 1663 Network Address Translators (NATs)", RFC 3489, March 2003. 1665 [16] Hakala, J., "Using National Bibliography Numbers as Uniform 1666 Resource Names", RFC 3188, October 2001. 1668 [17] Rosenberg, J., "A Framework for Conferencing with the Session 1669 Initiation Protocol", 1670 draft-ietf-sipping-conferencing-framework-05 (work in 1671 progress), May 2005. 1673 [18] Jennings, C. and R. Mahy, "Managing Client Initiated 1674 Connections in the Session Initiation Protocol (SIP)", 1675 draft-ietf-sip-outbound-00 (work in progress), July 2005. 1677 [19] Rosenberg, J., "Request Authorization through Dialog 1678 Identification in the Session Initiation Protocol (SIP)", 1679 draft-ietf-sip-target-dialog-01 (work in progress), July 2005. 1681 [20] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1682 Identity Management in the Session Initiation Protocol (SIP)", 1683 draft-ietf-sip-identity-05 (work in progress), May 2005. 1685 [21] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for 1686 the Session Initiation Protocol (SIP)", 1687 draft-ietf-sipping-dialog-package-06 (work in progress), 1688 April 2005. 1690 [22] Sparks, R., "Session Initiation Protocol Torture Test 1691 Messages", draft-ietf-sipping-torture-tests-07 (work in 1692 progress), May 2005. 1694 [23] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1695 Preferences for the Session Initiation Protocol (SIP)", 1696 RFC 3841, August 2004. 1698 [24] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and 1699 J. Peterson, "Presence Information Data Format (PIDF)", 1700 RFC 3863, August 2004. 1702 [25] Sparks, R., "Session Initiation Protocol Call Control - 1703 Transfer", draft-ietf-sipping-cc-transfer-05 (work in 1704 progress), July 2005. 1706 [26] Rosenberg, J., "A Data Model for Presence", 1707 draft-ietf-simple-presence-data-model-04 (work in progress), 1708 August 2005. 1710 [27] Rosenberg, J., "A Presence Event Package for the Session 1711 Initiation Protocol (SIP)", RFC 3856, August 2004. 1713 [28] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 1714 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 1716 [29] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1717 Package for Registrations", RFC 3680, March 2004. 1719 [30] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) 1720 "Join" Header", RFC 3911, October 2004. 1722 [31] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1723 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 1725 Author's Address 1727 Jonathan Rosenberg 1728 Cisco Systems 1729 600 Lanidex Plaza 1730 Parsippany, NJ 07054 1731 US 1733 Phone: +1 973 952-5000 1734 Email: jdrosen@cisco.com 1735 URI: http://www.jdrosen.net 1737 Appendix A. Example GRUU Construction Algorithms 1739 The mechanism for constructing a GRUU is not subject to 1740 specification. This appendix provides two examples that can be used 1741 by a registar. Others are, of course, permitted, as long as they 1742 meet the constraints defined for a GRUU. 1744 A.1 Instance ID in opaque URI Parameter 1746 The most basic approach for constructing a GRUU is to utilize the 1747 "opaque" URI parameter. The user and domain portions of the URI are 1748 equal to the AOR, and the "opaque" parameter is populated with the 1749 instance ID. 1751 A.2 Encrypted Instance ID and AOR 1753 In many cases, it will be desirable to construct the GRUU in such a 1754 way that it will not be possible, based on inspection of the URI, to 1755 determine the Contact URI that the GRUU translates to. It may also 1756 be desirable to construct it so that it will not be possible to 1757 determine the instance ID/AOR pair associated with the GRUU. Whether 1758 or not a GRUU should be constructed with this property is a local 1759 policy decision. 1761 With these rules, it is possible to construct a GRUU without 1762 requiring the maintenance of any additional state. To do that, the 1763 URI would be constructed in the following fashion: 1765 user-part = "GRUU" | BASE64(E(K, (salt | " " | AOR | " " | 1766 instance ID))) 1768 Where E(K,X) represents a suitable encryption function (such as AES 1769 with 128 bit keys) with key K applied to data block X, and the "|" 1770 operator implies concatenation. The single space (" ") between 1771 components is used as a delimeter, so that the components can easily 1772 be extracted after decryption. Salt represents a random string that 1773 prevents a client from obtaining pairs of known plaintext and 1774 ciphertext. A good choice would be at least 128 bits of randomness 1775 in the salt. 1777 This mechanism uses the user-part of the SIP URI to convey the 1778 encrypted AOR and instance ID. The user-part is used instead of the 1779 "opaque" URI parameter because of the desired anonymity properties. 1781 The benefit of this mechanism is that a server need not store 1782 additional information on mapping a GRUU to its corresponding 1783 contact. The user part of the GRUU contains the instance ID and AOR. 1784 Assuming that the domain stores registrations in a database indexed 1785 by the AOR, the proxy processing the GRUU would look up the AOR, 1786 extract the currently registered contacts, and find the one matching 1787 the instance ID encoded in the request URI. The contact whose 1788 instance ID is that instance ID is then used as the translated 1789 version of the GRUU. Encryption is needed to prevent attacks whereby 1790 the server is sent requests with faked GRUU, causing the server to 1791 direct requests to any named URI. Even with encryption, the proxy 1792 should validate the user part after decryption. In particular, the 1793 AOR should be managed by the proxy in that domain. Should a UA send 1794 a request with a fake GRUU, the proxy would decrypt and then discard 1795 it because there would be no URI or an invalid URI inside. 1797 While this approach has many benefits, it has the drawback of 1798 producing fairly long GRUUs. 1800 Intellectual Property Statement 1802 The IETF takes no position regarding the validity or scope of any 1803 Intellectual Property Rights or other rights that might be claimed to 1804 pertain to the implementation or use of the technology described in 1805 this document or the extent to which any license under such rights 1806 might or might not be available; nor does it represent that it has 1807 made any independent effort to identify any such rights. Information 1808 on the procedures with respect to rights in RFC documents can be 1809 found in BCP 78 and BCP 79. 1811 Copies of IPR disclosures made to the IETF Secretariat and any 1812 assurances of licenses to be made available, or the result of an 1813 attempt made to obtain a general license or permission for the use of 1814 such proprietary rights by implementers or users of this 1815 specification can be obtained from the IETF on-line IPR repository at 1816 http://www.ietf.org/ipr. 1818 The IETF invites any interested party to bring to its attention any 1819 copyrights, patents or patent applications, or other proprietary 1820 rights that may cover technology that may be required to implement 1821 this standard. Please address the information to the IETF at 1822 ietf-ipr@ietf.org. 1824 Disclaimer of Validity 1826 This document and the information contained herein are provided on an 1827 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1828 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1829 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1830 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1831 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1832 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1834 Copyright Statement 1836 Copyright (C) The Internet Society (2005). This document is subject 1837 to the rights, licenses and restrictions contained in BCP 78, and 1838 except as set forth therein, the authors retain all their rights. 1840 Acknowledgment 1842 Funding for the RFC Editor function is currently provided by the 1843 Internet Society.