idnits 2.17.1 draft-ietf-sip-gruu-09.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 1693. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1683. ** 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 -- 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 (June 19, 2006) is 6520 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) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-03 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '13') (Obsoleted by RFC 5389) == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-06 == Outdated reference: A later version (-09) exists of draft-ietf-sipping-gruu-reg-event-06 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 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: December 21, 2006 June 19, 2006 6 Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the 7 Session Initiation Protocol (SIP) 8 draft-ietf-sip-gruu-09 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 December 21, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 Several applications of the Session Initiation Protocol (SIP) require 42 a user agent (UA) to construct and distribute a URI that can be used 43 by anyone on the Internet to route a call to that specific UA 44 instance. A URI that 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.1.1. Generating a REGISTER Request . . . . . . . . . . 13 64 7.1.1.2. Processing the REGISTER Response . . . . . . . . . 14 65 7.1.2. Registrar Behavior . . . . . . . . . . . . . . . . . . 15 66 7.1.2.1. Processing a REGISTER Request . . . . . . . . . . 15 67 7.1.2.2. Timing Out a Registration . . . . . . . . . . . . 16 68 7.2. Through Administrative Operation . . . . . . . . . . . . . 17 69 8. Using the GRUU . . . . . . . . . . . . . . . . . . . . . . . . 17 70 8.1. UA Behavior . . . . . . . . . . . . . . . . . . . . . . . 17 71 8.1.1. Sending a Message Containing a GRUU . . . . . . . . . 17 72 8.1.2. Sending a Message to a GRUU . . . . . . . . . . . . . 18 73 8.1.3. Receiving a Request Sent to a GRUU . . . . . . . . . . 19 74 8.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 20 75 8.2.1. Request Targeting for Requests Outside of a Dialog . . 20 76 8.2.2. Record-Routing . . . . . . . . . . . . . . . . . . . . 21 77 8.2.3. Request Targeting for Mid-Dialog Requests . . . . . . 21 78 9. The opaque SIP URI Parameter . . . . . . . . . . . . . . . . . 22 79 10. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 80 11. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 24 81 12. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 25 82 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 83 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 84 14.1. Header Field Parameter . . . . . . . . . . . . . . . . . . 32 85 14.2. URI Parameters . . . . . . . . . . . . . . . . . . . . . . 32 86 14.3. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 32 87 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 89 16.1. Normative References . . . . . . . . . . . . . . . . . . . 33 90 16.2. Informative References . . . . . . . . . . . . . . . . . . 34 91 Appendix A. Example GRUU Construction Algorithms . . . . . . . . 35 92 A.1. Instance ID in "opaque" URI Parameter . . . . . . . . . . 35 93 A.2. Encrypted Instance ID and AOR . . . . . . . . . . . . . . 35 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 95 Intellectual Property and Copyright Statements . . . . . . . . . . 38 97 1. Introduction 99 The Session Initiation Protocol, RFC 3261 [1], is used to establish 100 and maintain a dialog between a pair of user agents in order to 101 manage a communications session. Messages within the dialog are sent 102 from one user agent to another using a series of proxy hops called 103 the route set. They are eventually delivered to the remote target 104 (the user agent on the other side of the dialog). This remote target 105 is identified by a SIP URI obtained from the value of the Contact 106 header field in INVITE requests and responses. 108 RFC 3261 mandates that a user agent populate the Contact header field 109 in INVITE requests and responses with a URI that is global (meaning 110 that it can be used from any element connected to the Internet) and 111 that routes to the user agent which inserted it. RFC 3261 also 112 mandates that this URI be valid for requests sent outside of the 113 dialog in which the Contact URI was inserted. 115 In practice, these requirements have proven very difficult to meet. 116 Few endpoints have a hostname that is present in DNS. Many endpoints 117 have an IP address that is private because the client is behind a 118 NAT. Techniques like the Simple Traversal of UDP Through NAT (STUN) 119 [13] can be used to obtain IP addresses on the public Internet. 120 However, many firewalls will prohibit incoming SIP requests from 121 reaching a client unless they first pass through a proxy sitting in 122 the DMZ of the network. Thus, URIs using STUN-obtained IP addresses 123 often do not work. 125 Because of these difficulties, most clients have actually been 126 inserting URIs into the Contact header field of requests and 127 responses with the form sip:. These have the property of 128 routing to the client, but they are generally only reachable from the 129 proxy to which the user is directly connected. This limitation does 130 not prevent SIP calls to an Address-of-Record (AOR) from proceeding 131 because the user's proxy can usually reach these private addresses, 132 and the proxy itself is generally reachable over the public network. 133 However, this issue has impacted the ability of several other SIP 134 mechanisms and applications to work properly. 136 An example of such an application is call transfer [21], based on the 137 REFER method [7]. Another application is the usage of endpoint- 138 hosted conferences within the conferencing framework [14]. Both of 139 these mechanisms require that the endpoint be able to construct a URI 140 that not only routes to that user agent, but is usable by entities 141 anywhere on the Internet as a target for new SIP requests. 143 This specification formally defines a type of URI called a Globally 144 Routable User Agent URI (GRUU) which has the properties of routing to 145 the UA and being reachable from anywhere. Furthermore, it defines a 146 new mechanism by which a client can obtain a GRUU from its SIP 147 provider, allowing it to use that URI in the Contact header fields of 148 its dialog-forming or target refresh requests and responses. Because 149 the GRUU is provided by the user's SIP provider, the GRUU properties 150 can be guaranteed by the provider. As a result, the various 151 applications which require the GRUU property, including transfer, 152 presence, and conferencing, can work reliably. 154 2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [5]. 160 This specification defines the following additional terms: 162 contact: The term "contact", when used in all lowercase, refers to a 163 URI that is bound to an AOR or GRUU by means of a registration. A 164 contact is usually a SIP URI, and is bound to the AOR and GRUU 165 through a REGISTER request by appearing as the value of the 166 Contact header field. 168 remote target: The term "remote target" refers to a URI that a user 169 agent uses to identify itself for receipt of both mid-dialog and 170 out-of-dialog requests. A remote target is established by placing 171 a URI in the Contact header field of a dialog-forming request or 172 response and updated by target refresh requests. 174 Contact header field: The term "Contact header field", with a 175 capitalized C, refers to the header field which can appear in 176 REGISTER requests and responses, redirects, or in dialog-creating 177 requests and responses. Depending on the semantics, the Contact 178 header field sometimes conveys a contact, and sometimes conveys a 179 remote target. 181 3. Defining a GRUU 183 URIs have properties, which are granted to the URI based on the 184 policies of the domain that owns the URI. Those properties are not 185 necessarily visible by inspection of the URI. In this context, the 186 domain that owns the URI is the one indicated in the host part of the 187 SIP URI. Some of the properties that a domain can confer upon a URI 188 are: 190 The AOR property: A URI has the Address of Record (AOR) property if a 191 domain will allow it to appear in the To header field of REGISTER 192 request. 194 The alias property: A URI is an alias if its treatment by the domain 195 is identical to another URI. 197 The service treatment property: A URI has the service treatment 198 property if the domain will apply applications, features, and 199 services to calls made by, or made to, that URI, possibly based on 200 associating that URI with a user that has "subscribed" to various 201 features. 203 The anonymous property: A URI has the anonymous property when it is 204 not possible, by inspection of the URI, to discern the user with 205 whom the URI is associated. 207 The identity property: A URI is considered an identity when the 208 domain will authorize it as a valid value in the From header field 209 of a request, such that an authentication service will sign a 210 request with that URI [16]. 212 This specification focuses on a property, called the Globally 213 Routable User Agent URI (GRUU) property. A URI possesses this 214 property when the following is true: 216 Global: It can be used by any User Agent Client (UAC) connected to 217 the Internet. In that regard, it is like the address-of-record 218 (AOR) property. A URI with the AOR property (for example, 219 sip:joe@example.com), is meant to be used by anyone to reach that 220 user. The same is true for a URI with the GRUU property. 222 Routes to a Single Instance: A request sent to that URI will be 223 routed to a specific UA instance. In that regard, it is unlike 224 the address-of-record property. When a request is sent to a URI 225 with the AOR property, routing logic is applied in proxies to 226 deliver the request to one or more UAs. That logic can result in 227 a different routing decision based on the time of day, or the 228 identity of the caller. However, when a request is made to a URI 229 with the GRUU property, the routing logic is dictated by the GRUU 230 property. The request has to be delivered to a very specific UA 231 instance. That UA instance has to be the same UA instance for all 232 requests sent to that URI. 234 Long Lived: The URI with the GRUU property persists for relatively 235 long periods of time, ideally being valid for the duration of 236 existence of the AOR itself. This property cannot be completely 237 guaranteed, but providers are supposed to do their best to make 238 sure that a GRUU remains viable indefinitely. 240 A URI can have any combination of these properties. It is the 241 responsibility of the domain which mints the URI to determine what 242 properties are conferred upon that URI. This specification imposes 243 requirements on a domain that mints a URI with the GRUU property. 245 For convenience, a URI that possesses the GRUU property is also 246 referred to as a GRUU. 248 4. Use Cases 250 There are several use cases where the GRUU properties are truly 251 needed in order for a SIP application to operate. 253 4.1. REFER 255 Consider a blind transfer application [21]. User A is talking to 256 user B. User A wants to transfer the call to user C. So, user A sends 257 a REFER to user C. That REFER looks like, in part: 259 REFER sip:C@example.com SIP/2.0 260 From: sip:A@example.com;tag=99asd 261 To: sip:C@example.com 262 Refer-To: (URI that identifies B's UA) 264 The Refer-To header field needs to contain a URI that can be used by 265 user C to place a call to user B. However, this call needs to route 266 to the specific UA instance that user B is using to talk to user A. 267 If it doesn't, the transfer service will not execute properly. This 268 URI is provided to user A by user B. Because user B doesn't know who 269 user A will transfer the call to, the URI has to be usable by anyone. 270 Therefore, it needs to be a GRUU. 272 4.2. Conferencing 274 A similar need arises in conferencing [14]. In that framework, a 275 conference is described by a URI that identifies the focus of the 276 conference. The focus is a SIP UA that acts as the signaling hub for 277 the conference. Each conference participant has a dialog with the 278 focus. One case described in the framework is where a user A has 279 made a call to user B. User A puts user B on hold, and calls user C. 280 Now, user A has two separate dialogs for two separate calls -- one to 281 user B, and one to user C. User A would like to conference them. To 282 do this, user A's user agent morphs itself into a focus. It sends a 283 re-INVITE or UPDATE [4] on both dialogs, and provides user B and user 284 C with an updated remote target that now holds the conference URI. 286 The URI in the Contact header field also has a callee capabilities 287 [8] parameter which indicates that this URI is a conference URI. 288 User A proceeds to mix the media streams received from user B and 289 user C. This is called an ad-hoc conference. 291 At this point, normal conferencing features can be applied. That 292 means that user B can send another user, user D, the conference URI, 293 perhaps in an email. User D can send an INVITE to that URI, and join 294 the conference. For this to work, the conference URI used by user A 295 in its re-INVITE or UPDATE has to be usable by anyone, and it has to 296 route to the specific UA instance of user A that is acting as the 297 focus. If it doesn't, basic conferencing features will fail. 298 Therefore, this URI has to be a GRUU. 300 4.3. Presence 302 In a SIP-based presence [23] system, the Presence Agent (PA) 303 generates notifications about the state of a user. This state is 304 represented with the Presence Information Document Format (PIDF) 305 [20]. In a PIDF document, a user is represented by a series of 306 tuples, each of which describes the services that the user has. Each 307 tuple also has a URI in the element, which is a SIP URI 308 representing that service. A watcher can make a call to that URI, 309 with the expectation that the call is routed to the service whose 310 presence is represented in the tuple. 312 In some cases, the service represented by a tuple may exist on only a 313 single user agent associated with a user. In such a case, the URI in 314 the presence document has to route to that specific UA instance. 315 Furthermore, since the presence document could be used by anyone who 316 subscribes to the user, the URI has to be usable by anyone. As a 317 result, it has to be a GRUU. 319 It is interesting to note that the GRUU may need to be constructed by 320 a presence agent, depending on how the presence document is computed 321 by the server. 323 5. Overview of Operation 325 This section is tutorial in nature, and does not specify any 326 normative behavior. 328 This extension allows a UA to obtain a GRUU, and to use a GRUU. 329 These two mechanisms are separate, in that a UA can obtain a GRUU in 330 any way it likes, and use the mechanisms in this specification to use 331 it. This specification defines two mechanisms for obtaining a GRUU 332 -- through registrations and through administrative operation. Only 333 the former requires protocol operations. 335 A UA can obtain a GRUU by generating a normal REGISTER request, as 336 specified in RFC 3261 [1]. This request contains a Supported header 337 field with the value "gruu", indicating to the registrar that the UA 338 supports this extension. The UA includes a "+sip.instance" Contact 339 header field parameter of each contact for which a GRUU is desired. 340 This parameter, defined in [11], contains a globally unique ID that 341 identifies the UA instance. If the domain that the user is 342 registering against also supports GRUU, the REGISTER responses will 343 contain the "gruu" parameter in each Contact header field. This 344 parameter contains a URI which the domain guarantees will route to 345 that UA instance. This URI is tagged as a GRUU through the inclusion 346 of a "gruu" URI parameter, similar to the way loose route URIs are 347 tagged with the "lr" URI parameter. This GRUU is associated with the 348 UA instance. Should the client change its contact, but indicate that 349 it represents the same instance ID, the server would provide the same 350 GRUU. Furthermore, if the registration for the contact expires, and 351 the UA registers the contact at a later time with the same instance 352 identifier, the server would provide the same GRUU. 354 Since the GRUU is a URI like any other, it can be handed out by a UA 355 by placing it in any header field which can contain a URI. A UA will 356 place the GRUU into the Contact header field of dialog forming and 357 target refresh requests and responses it generates. RFC 3261 358 mandates that the Contact header field have the GRUU property, and 359 this specification provides a reliable way for a UA to obtain one. 360 In other words, clients use the GRUU as a remote target. However, 361 since the remote target used by clients to date has typically not had 362 the GRUU properties, implementations have adapted their behaviors 363 (oftentimes in proprietary ways) to compensate. To facilitate a 364 transition away from these behaviors, it is helpful for a UA 365 receiving the message to know whether the remote target is a GRUU or 366 not. This can be known to a remote target through the presence of 367 the "gruu" URI parameter. 369 A domain can construct a GRUU in any way it chooses. However, it is 370 sometimes desirable to construct GRUUs so that any entity that 371 receives a GRUU can determine the AOR for the subscriber associated 372 with the UA instance. To facilitate that, the GRUU can be 373 constructed such that it is identical to the subscriber's AOR, but 374 includes the "opaque" and "gruu" URI parameters. The "opaque" URI 375 parameter provides a general facility to construct a URI (such as a 376 GRUU or a voicemail inbox for a user) that is related to an AOR, so 377 that any element can extract the AOR from the constructed URI by 378 removing the "opaque" parameter. It is because of the desire to use 379 "opaque" for reasons besides GRUU, that both a "gruu" flag and an 380 "opaque" URI parameter are defined. For example: 382 AOR: sip:alice@example.com 383 GRUU: sip:alice@example.com;opaque="kjh29x97us97d";gruu 385 When a proxy in the domain constructs the GRUU, it would set the 386 value of the "opaque" URI parameter such that it includes the 387 instance ID. As such, when that proxy receives a request sent to the 388 GRUU, it can determine that the request is a GRUU by the presence of 389 the "gruu" parameter, and then it can extract the AOR and instance 390 ID, both of which are needed to process the request. 392 When a UA uses a GRUU that routes to itself, it has the option of 393 adding the "grid" URI parameter to the GRUU. This parameter is 394 opaque to the proxy server handling the domain. However, when the 395 server maps the GRUU to the contact bound to it, the server will copy 396 the "grid" parameter and its value into the registered contact, and 397 use the result in the Request-URI. As a result, when the UA receives 398 the request, the Request-URI will contain the "grid" parameter it 399 placed in the corresponding GRUU. If the GRUU did not contain a 400 "grid" URI parameter, the server will insert a "grid" parameter into 401 the Request-URI, but with no value. This signals to the UA that the 402 request was sent to a GRUU. 404 The "grid" and "opaque" URI parameters play similar roles, but 405 complement each other. The "opaque" parameter is added by the owner 406 of the domain to correlate the GRUU to its instance ID, and to easily 407 recognize that the URI has the GRUU property. The "grid" parameter 408 is added by the UA instance so that, when a request is received by 409 that instance, it can determine the context of the request. 411 6. Creation of a GRUU 413 A GRUU is a URI that is created and maintained by a server 414 authoritative for the domain in which the GRUU resides. 415 Independently of whether the GRUU is created as a result of a 416 registration or some other means, a server maintains certain 417 information associated with the GRUU. This information, and its 418 relationship with the GRUU, is modeled in Figure 1. 420 +-----------+ +-----------+ 421 | | associated | | 422 | |1 with n| | 423 | AOR |<----------------| GRUU | 424 | | | | 425 | | | | 426 +-----------+ +-----------+ 427 ^1 is ^^ |n 428 | bound //0..1 | 429 is| to// |associated 430 bound| // |with 431 to| // | 432 | // | 433 |0..n // V1 434 +-----------+ // +-----------+ 435 | | / 0..n | | 436 | | | | 437 | contact |---------------->| Instance | 438 | |1 has 0..1| ID | 439 | | | | 440 +-----------+ +-----------+ 442 Figure 1 444 The instance ID plays a key role in this specification. The instance 445 ID is defined in [11]. It is an identifier, represented with a URN, 446 that uniquely identifies a SIP user agent amongst all other user 447 agents associated with an AOR. 449 A GRUU is associated, in a many-to-one fashion, with the combination 450 of an instance ID and an AOR. This combination is referred to as an 451 instance ID/AOR pair. For each GRUU, there is one instance ID/AOR 452 pair, and for each instance ID/AOR pair, there can be one or more 453 GRUU. More than one GRUU might be defined in order to have aliases 454 or URI that are anonymous or have other URI properties. However, 455 this specification doesn't define any way for the client to learn 456 about or use more than a single GRUU for each instance ID/AOR pair. 457 The instance ID/AOR pair serves to uniquely identify a user agent 458 instance servicing a specific AOR. The AOR identifies a resource, 459 such as a user or service within a domain, and the instance ID 460 identifies a specific UA instance servicing requests for that 461 resource. 463 It is important to understand that GRUU is associated with the 464 instance ID/AOR pair, not just the instance ID. For example, let's 465 say a user registered the contact sip:ua@pc.example.com to the AOR 466 sip:user@example.com, and included a +sip.instance="urn:foo:1" 467 parameter in the Contact header field. If the user also registered 468 the contact sip:ua-112@pc.example.com with the same +sip.instance 469 Contact header field parameter to a second AOR (say 470 sip:boss@example.com), each of those UA instances would have a 471 different GRUU because they belong to different AORs. That is the 472 reason why a single instance ID can be associated with multiple GRUU; 473 there would be one such association for each AOR. The same goes for 474 the association of AOR to GRUU; there would be one such association 475 for each instance ID. 477 The contacts that are bound to the GRUU are always the ones that have 478 the instance ID that is associated with that GRUU. If none of the 479 contacts bound to the AOR have the instance ID associated with the 480 GRUU, then there are no contacts bound to the GRUU. If a contact 481 should become registered to the AOR that has an instance ID equal to 482 the one associated with the GRUU, that contact also becomes bound to 483 the GRUU. If that contact should expire, it will no longer be bound 484 to the AOR, and similarly, it will no longer be bound to the GRUU. 485 The URI of the contact is irrelevant in determining whether it is 486 bound to a particular GRUU; only the instance ID and AOR are 487 important. 489 This specification does not mandate a particular mechanism for 490 construction of the GRUU. Several example approaches are given in 491 Appendix A. However, the GRUU MUST exhibit the following properties: 493 o The domain part of the URI is an IP address present on the public 494 Internet, or, if it is a host name, the resolution procedures of 495 RFC 3263 [2], once applied, result in an IP address on the public 496 Internet. 498 o When a request is sent to the GRUU, it routes to a server that can 499 make sure the request is delivered to the UA instance. For GRUUs 500 created through registrations, this means that the GRUU has to 501 route to a proxy server with access to registration data. 503 o The URI MUST include the "gruu" URI parameter. 505 o For each GRUU, both the SIP and Session Initiation Protocol Secure 506 (SIPS) versions MUST exist. The SIPS URI may not always work, 507 particularly if the proxy cannot establish a secure connection to 508 the client. However, the SIPS URI always exists. 510 o If the GRUU contains an "opaque" URI parameter, the URI that 511 results from stripping out the "opaque" URI parameter MUST be 512 equivalent to the AOR associated with the GRUU. 514 Section 8.2 defines additional behaviors that a proxy must exhibit on 515 receipt of a GRUU. 517 When a domain constructs a URI with the GRUU properties, it MAY 518 confer other properties upon this URI as a matter of domain policy. 519 A domain can elect to confer properties like identity, anonymity, and 520 service treatment. There is nothing in this specification that can 521 allow the recipient of the GRUU to determine which of these 522 properties (besides the GRUU property itself) have been conferred to 523 the URI. 525 The service treatment property merits further discussion. Typically, 526 the services a proxy executes upon receipt of a request sent to a 527 GRUU will be a subset of those executed when a request is sent to the 528 AOR. For requests that are outside of a dialog, it is RECOMMENDED to 529 apply screening types of functions, both automated (such as black and 530 white list screening) and interactive (such as interactive voice 531 response (IVR) applications that confer with the user to determine 532 whether to accept a call). In many cases, the new request is related 533 to an existing dialog, and may be an attempt to join it (using the 534 Join header field [24]) or replace it (using the Replaces header 535 field [25]). In such cases, the UA will typically make its own 536 authorization decisions, allowing the request if the sender can prove 537 it knows the dialog identifiers [15]. In such cases, bypassing 538 screening services might make sense, but it needs to be carefully 539 considered by network designers, as it depends on the specific type 540 of screening service. 542 However, forwarding services, such as call forwarding, SHOULD NOT be 543 provided for requests sent to a GRUU. The intent of the GRUU is to 544 target a specific UA instance, and this is incompatible with 545 forwarding operations. 547 Mid-dialog requests will also be sent to GRUUs, as they are included 548 as the remote-target in dialog-forming and target refresh requests 549 and responses. However, in those cases, a proxy SHOULD only apply 550 services that are meaningful for mid-dialog requests, generally 551 speaking. This excludes screening functions, as well as forwarding 552 ones. 554 The "opaque" URI parameter, defined in Section 9, provides a means 555 for a domain to construct a GRUU such that the AOR associated with 556 the GRUU is readily extractable from the GRUU. Unless the GRUU is 557 meant to also possess the anonymity property, it is RECOMMENDED that 558 GRUUs be constructed using this parameter. 560 Because the GRUU is associated with both the instance ID and AOR, for 561 any particular AOR there can be a potentially infinite number of 562 GRUUs, and potentially more than one for each instance ID. However, 563 the instance IDs are only known to the network when an instance 564 actually registers with one. As a result, it is RECOMMENDED that a 565 GRUU be created at the time a contact with an instance ID is first 566 registered to an AOR (even if that registration indicates that the 567 registering UA doesn't even support GRUUs), until the time that the 568 AOR is no longer valid in the domain. In this context, the GRUU 569 exists if the domain, upon receiving a request for that GRUU, 570 recognizes it as a GRUU, can determine the AOR and instance ID 571 associated with it, and translate the GRUU to a contact if there is 572 one with that instance ID currently registered. This property of the 573 GRUU (existing from the time the first registration until removal of 574 the AOR) can be difficult to achieve through software failures and 575 power outages within a network, and for this reason, providing the 576 property is at RECOMMENDED strength, and not MUST. 578 7. Obtaining a GRUU 580 A GRUU can be obtained in many ways. This document defines two -- 581 through registrations and through administrative operation. 583 7.1. Through Registrations 585 When a GRUU is associated with a user agent that comes and goes, and 586 registers itself to the network to bind a contact to an AOR, a GRUU 587 is provided to the user agent through SIP REGISTER messages. 589 7.1.1. User Agent Behavior 591 7.1.1.1. Generating a REGISTER Request 593 When a UA compliant to this specification generates a REGISTER 594 request (initial or refresh), it MUST include the Supported header 595 field in the request. The value of that header field MUST include 596 "gruu" as one of the option tags. This alerts the registrar for the 597 domain that the UA supports the GRUU mechanism. 599 Furthermore, for each contact for which the UA desires to obtain a 600 GRUU, the UA MUST include a "sip.instance" media feature tag [11] as 601 a UA characteristic [8]. The instance ID MUST identify the UA that 602 is performing the registration. 604 If a UA instance is registering against multiple AORs, it is 605 RECOMMENDED that a UA instance provide a different contact URI for 606 each AOR. This is needed for the UA to determine which GRUU to use 607 as the remote target in responses to incoming dialog-forming 608 requests, as discussed in Section 8.1.1. 610 If a UA instance is trying to register multiple contacts for the same 611 instance for the purposes of redundancy, it MUST use the procedures 612 defined in [11]. 614 Besides the procedures discussed above, the REGISTER request is 615 constructed as it is in the case where this extension was not 616 understood. Specifically, the contact in the REGISTER request SHOULD 617 NOT contain the gruu Contact header field parameter, and the contact 618 URI itself SHOULD NOT contain the "grid" URI parameter defined below. 619 Any such parameters are ignored by the registrar, as the UA cannot 620 propose a GRUU for usage with the contact. Typically, the contact 621 URI will not contain the "gruu" URI parameter. However, it is 622 permitted for a UA to register any kind of contact it wishes, 623 including a GRUU. A typical use case for registering a GRUU is if a 624 user wanted calls to one AOR to be delivered to a specific UA 625 instance associated with another AOR. If a client does include a 626 contact which contains a GRUU, that GRUU MUST NOT be associated with 627 the AOR in the To header field of the REGISTER request. Doing so 628 would result in a recursive definition for the GRUU and likely cause 629 an infinite loop. 631 A UA MAY perform third party registrations (registrations where the 632 entity performing the registration is not the same as the AOR in the 633 To header field of the registration), and as in the above paragraph, 634 MAY register contacts that do not point to the UA performing the 635 registration. In addition, a UA MAY register contacts which omit the 636 "+sip.instance" Contact header field parameter, in which case they 637 would not be associated with any GRUU. 639 If a UA wishes to guarantee that the request is not processed unless 640 the domain supports and uses this extension, it MAY include a Require 641 header field in the request with a value that contains the "gruu" 642 option tag. This is in addition to the presence of the Supported 643 header field. 645 7.1.1.2. Processing the REGISTER Response 647 If the response is a 2xx, each Contact header field that contained 648 the "+sip.instance" Contact header field parameter may also contain a 649 "gruu" Contact header field parameter (which is distinct from the 650 "gruu" URI parameter). This parameter contains a SIP or SIPS URI 651 that represents a GRUU corresponding to the UA instance that 652 registered the contact. The URI will be a SIP URI if the To header 653 field in the REGISTER request contained a SIP URI, else (if the To 654 header field in the REGISTER request contained a SIPS URI) it will be 655 a SIPS URI. Any requests sent to the GRUU URI will be routed by the 656 domain to a contact with that instance ID. Normally, the GRUU will 657 not change in subsequent 2xx responses to REGISTER. Indeed, even if 658 the UA lets the contact expire, when it re-registers it at any later 659 time, the registrar will normally provide the same GRUU for the same 660 address-of-record and instance ID. However, as discussed above, this 661 property cannot be completely guaranteed, as network failures may 662 make it impossible to provide an identifier that persists for all 663 time. As a result, a UA MUST be prepared to receive a different GRUU 664 for the same instance ID/AOR pair in a subsequent registration 665 response. 667 A non-2xx response to the REGISTER request has no impact on any 668 existing GRUU previously provided to the UA. Specifically, if a 669 previously successful REGISTER request provided the UA with a GRUU, a 670 subsequent failed request does not remove, delete, or otherwise 671 invalidate the GRUU. 673 7.1.2. Registrar Behavior 675 A registrar MAY create a GRUU for a particular instance ID/AOR pair 676 at any time. Of course, if a UA requests a GRUU in a registration, 677 and the registrar has not yet created one, it will need to do so in 678 order to respond to the registration request. However, the registrar 679 can create the GRUU in advance of any request from a UA. 681 A registrar MUST create both the SIP and SIPS versions of the GRUU, 682 such that if the GRUU exists, both URI exist. 684 7.1.2.1. Processing a REGISTER Request 686 A REGISTER request might contain a Require header field; this 687 indicates that the registration has to understand this extension in 688 order to process the request. 690 As the registrar is processing the contacts in the REGISTER request 691 according to the procedures of step 7 in Section 10.3 of RFC 3261, 692 the registrar checks whether each Contact header field in the 693 REGISTER message contains a "+sip.instance" header field parameter. 694 If present, the contact is processed further. If the registrar had 695 not yet created a GRUU for that instance ID/AOR pair, it MUST do so 696 at this time according to the procedures of Section 6. If the 697 contact contained a "gruu" Contact header field parameter, it MUST be 698 ignored by the registrar. A UA cannot suggest or otherwise provide a 699 GRUU to the registrar. 701 Next, the registrar checks if the contact URI is itself a GRUU 702 associated with the AOR in the To header field of the registration. 703 If it is, the registrar MUST reject the request with a 403 704 (Forbidden) error response. 706 Registration processing then continues as defined in RFC 3261. If, 707 after that processing, that contact is bound to the AOR, it also 708 becomes bound to the GRUU associated with that instance ID/AOR pair. 709 If, after that processing, the contact was not bound to the AOR (due, 710 for example, to an expiration of zero), the contact is not bound to 711 the GRUU either. 713 When generating the 200 (OK) response to the REGISTER request, the 714 procedures of step 8 of Section 10.3 of RFC 3261 are followed. 715 Furthermore, for each Contact header field value placed in the 716 response, if the registrar has stored an instance ID associated with 717 that contact, that instance ID is returned as a Contact header field 718 parameter. If the REGISTER request contained a Supported header 719 field that included the "gruu" option tag, the server MUST add a 720 "gruu" Contact header field parameter to that Contact header field. 721 The value of the gruu parameter is a quoted string containing the URI 722 that is the GRUU for the associated instance ID/AOR pair. If the To 723 header field in the REGISTER request contains a SIP URI, the SIP 724 version of the GRUU is returned. If the To header field in the 725 REGISTER request contains a SIPS URI, the SIPS version of the GRUU is 726 returned. 728 Note that handling of a REGISTER request containing a Contact header 729 field with value "*" and an expiration of 0 still retains the meaning 730 defined in RFC 3261 -- all contacts, not just those with a specific 731 instance ID, are deleted. This removes the binding of each contact 732 to the AOR and the binding of each contact to a GRUU. 734 Inclusion of a GRUU in the "gruu" Contact header field parameter of a 735 REGISTER response is separate from the computation and storage of the 736 GRUU. It is possible that the registrar has computed a GRUU for one 737 UA, but a different UA that queries for the current set of 738 registrations doesn't understand GRUU. In that case, the REGISTER 739 response sent to that second UA would not contain the "gruu" Contact 740 header field parameter, even though the UA has a GRUU for that 741 contact. Similarly, a UA might send a REGISTER request with a 742 contact containing a "+sip.instance" Contact header field but no 743 "gruu" option tag in the Supported header field. The registrar can 744 still assign a GRUU, and indeed, a subscriber to the registration 745 event package could learn the GRUU from the notification [26] [27]. 747 There is no need for inclusion of either a Require or Supported 748 header field in the response with the "gruu" option tag. 750 7.1.2.2. Timing Out a Registration 752 When a registered contact expires, its binding to the AOR is removed 753 as usual. In addition, its binding to the GRUU is removed at the 754 same time. 756 7.2. Through Administrative Operation 758 Administrative creation of GRUUs is useful when a UA instance is a 759 network server that is always available, and therefore doesn't 760 register to the network. Examples of such servers are voicemail 761 servers, application servers, and gateways. 763 There are no protocol operations required to administratively create 764 a GRUU. The proxy serving the domain is configured with the GRUU, 765 and with the contact to which it should be translated. It is not 766 strictly necessary to also configure the instance ID and AOR, since 767 the translation can be done directly. However, they serve as useful 768 tools for determining to which resource and UA instance the GRUU is 769 supposed to map. 771 In addition to configuring the GRUU and its associated contact in the 772 proxy serving the domain, the GRUU will also need to be configured 773 into the UA instance associated with the GRUU. 775 It is also reasonable to model certain network servers (such as PSTN 776 gateways and media servers) as logically containing both a proxy and 777 a UA instance. The proxy receives the request from the network, and 778 passes it internally to the UA instance. In such a case, the GRUU 779 routes directly to the server, and there is no need for a translation 780 of the GRUU to a contact. The server itself would construct its own 781 GRUU. When such a server constructs a GRUU, it MUST include the 782 "gruu" URI parameter in it. 784 8. Using the GRUU 786 8.1. UA Behavior 788 8.1.1. Sending a Message Containing a GRUU 790 A UA first obtains a GRUU using the procedures of Section 7, or by 791 other means outside the scope of this specification. 793 A UA can use the GRUU in the same way it would use any other SIP or 794 SIPS URI. However, a UA compliant to this specification SHOULD use a 795 GRUU when populating the Contact header field of dialog-forming and 796 target refresh requests and responses. In other words, a UA 797 compliant to this specification SHOULD use its GRUU as its remote 798 target. This includes the INVITE request, its 2xx response, the 799 SUBSCRIBE [6] request, its 2xx response, the NOTIFY request, and the 800 REFER [7] request, and its 2xx response. 802 If the UA instance has obtained multiple GRUUs for different AORs as 803 a result of a registration, it SHOULD use one corresponding to the 804 AOR used to send or receive the request. For sending a request, this 805 means that the GRUU corresponds to the AOR present in the From header 806 field. Furthermore, this means that the credentials used for 807 authentication of the request correspond to the ones associated with 808 that AOR. When receiving a request, the GRUU in the response 809 corresponds to the AOR to which the original request was targeted. 810 However, that AOR will be rewritten by the proxy to correspond to the 811 UA's registered contact. It is for this reason that different 812 contacts are needed for each AOR that an instance registers against. 813 In this way, when an incoming request arrives, the Request URI can be 814 examined. It will be equal to a registered contact. That contact 815 can be used to map directly to the AOR, and from there, the correct 816 GRUU can be selected. 818 When using a GRUU as a remote target, a UA MAY add the "grid" URI 819 parameter to the GRUU, and if one is added, MUST include a value for 820 it. This parameter MAY take any value permitted by the grammar for 821 the parameter. When a UA sends a request to the GRUU, the proxy for 822 the domain that owns the GRUU will translate the GRUU in the Request- 823 URI, replacing it with the contact bound to that GRUU. However, the 824 proxy will retain the "grid" parameter and its value when this 825 translation is performed. As a result, when the UA receives the 826 request, the Request-URI will contain the "grid" created by the UA. 827 This allows the UA to effectively manufacture an infinite supply of 828 GRUU, each of which differs by the value of the "grid" parameter. 829 When a UA receives a request that was sent to the GRUU, it will be 830 able to tell which GRUU was invoked by looking at the "grid" 831 parameter. 833 An implication of this behavior is that all mid-dialog requests will 834 be routed through intermediate proxies. There will never be direct, 835 UA-to-UA signaling unless the UA is co-resident with the proxy (which 836 is the case for administratively constructed GRUUs). 838 When a UA requires a URI with the GRUU properties in order to reach a 839 peer for a particular SIP application (such as assisted call 840 transfer), it uses the URI in the Contact header field of a request 841 or response from that peer if it contains a GRUU. This is trivially 842 determined by the presence of the "gruu" URI parameter. 844 As per RFC 3261, a UA SHOULD include a Supported header with the 845 option tag "gruu" in requests it generates. 847 8.1.2. Sending a Message to a GRUU 849 There is no new behavior associated with sending a request to a GRUU. 851 A GRUU is a URI like any other. When a UA receives a request or 852 response, it knows that the remote target is a GRUU by the presence 853 of the "gruu" URI parameter. The UA can take the GRUU, send a 854 request to it, and then be sure that the request is delivered to the 855 UA instance which sent the request or response. 857 If the GRUU contains the "opaque" URI parameter, a UA can obtain the 858 AOR for the user by stripping the "opaque" and "gruu" URI parameters. 859 The resulting URI is the AOR. If the GRUU does not have the "opaque" 860 URI parameter, there is no mechanism defined for determining the AOR 861 from the GRUU. Extraction of the AOR from the GRUU is useful for 862 call logs and other accounting functions where it is desirable to 863 know the user to whom the request was directed. 865 Because the instance ID is a callee capabilities parameter, a UA 866 might be tempted to send a request to the AOR of a user, and include 867 an Accept-Contact header field [19] that indicates a preference for 868 routing the request to a UA with a specific instance ID. Although 869 this would appear to have the same effect as sending a request to the 870 GRUU, it does not. The caller preferences expressed in the Accept- 871 Contact header field are just preferences. Its efficacy depends on a 872 UA constructing an Accept-Contact header field that interacts with 873 domain-processing logic for an AOR, to cause a request to route to a 874 particular instance. Given the variability in routing logic in a 875 domain (for example, time-based routing to only selected contacts), 876 this doesn't work for many domain-routing policies. However, this 877 specification does not forbid a client from attempting such a 878 request, as there may be cases where the desired operation truly is a 879 preferential routing request. 881 8.1.3. Receiving a Request Sent to a GRUU 883 When a User Agent Server (UAS) receives a request sent to its GRUU, 884 the incoming request URI will be equal to the contact that was 885 registered (through REGISTER or some other action) by that UA 886 instance. If the user agent had previously handed out its GRUU with 887 a "grid" parameter, the incoming Request-URI may contain that 888 parameter. This indicates to the UAS that the request is being 889 received as a result of a request sent by the UAC to that GRUU/grid 890 combination. This specification makes no normative statements about 891 when to use a "grid" parameter, or what to do when receiving a 892 request made to a GRUU/grid combination. Generally, any differing 893 behaviors are a matter of local policy. If the UA had not included a 894 "grid" parameter in the GRUU, the incoming request will still have a 895 "grid" parameter, but with no value. 897 It is important to note that, when a user agent receives a request, 898 the presence or absence of the "grid" parameter will inform the user 899 agent whether the request was sent to the AOR or to the GRUU. If the 900 parameter is absent, it means that the request was sent to the AOR. 901 If present, it means that the request was sent to the GRUU. This is 902 true regardless of whether the UA itself uses the "grid" parameter, 903 since the home proxy will insert one into the Request-URI when 904 receiving a request sent to a GRUU. 906 8.2. Proxy Behavior 908 Proxy behavior is fully defined in Section 16 of RFC 3261 [1]. GRUU 909 processing impacts that processing in two places -- request targeting 910 and record routing. 912 8.2.1. Request Targeting for Requests Outside of a Dialog 914 When a proxy server receives a request, owns the domain in the 915 Request-URI, and is supposed to access a Location Service in order to 916 compute request targets (as specified in Section 16.5 of RFC 3261 917 [1]), the proxy examines the Request-URI. If the Request-URI is an 918 AOR against which there are multiple registered contacts with the 919 same instance ID parameter (allowing multiple flows, as defined in 920 [11]), the proxy MUST follow the procedures defined there and 921 populate the target set so that there is never more than one contact 922 at a time with a given instance ID. 924 If the Request-URI is within the domain of the proxy, and the URI 925 contains the "gruu" URI parameter, but the URI does not refer to a 926 GRUU known within the domain, the proxy rejects the request with a 927 404 (Not Found). If the Request-URI is within the domain of the 928 proxy, contains a "gruu" URI parameter, and the GRUU is known within 929 the domain and refers to a valid AOR within the domain, but the 930 instance ID is unknown, the proxy SHOULD generate a 480 (Temporarily 931 Unavailable). 933 Otherwise, handling of the GRUU proceeds as specified in RFC 3261 934 Section 16. For GRUUs, the abstract location service described in 935 Section 16.5 is utilized, producing a set of zero or more contacts, 936 each of which is associated with the same instance ID. If there are 937 more than one contact with the same instance ID, and those contact 938 were registered using the procedures of [11], those procedures are 939 used to select one. Otherwise, the most recently updated contact is 940 used. This produces zero or one contacts. The server MUST copy the 941 "grid" parameter from the Request-URI (if present) into the new 942 target URI obtained from the registered contact. If there was no 943 "grid" parameter in the Request-URI, the proxy MUST insert a "grid" 944 parameter into the new target URI obtained from the registered 945 contact, and MUST omit a value for the parameter. Note that the 946 "gruu" URI parameter is not copied. If the grid was already present 947 in the contact bound to the GRUU, it is overwritten in this process. 948 If no contacts were bound to the GRUU, the lookup of the GRUU in the 949 abstract location service will result in zero target URIs, eventually 950 causing the proxy to reject the request with a 480 (Temporarily 951 Unavailable) response. 953 If the contact was registered using a Path header field [3], then 954 that Path is used to construct the route set for reaching the contact 955 through the GRUU, as well as through the AOR, using the procedures 956 specified in RFC 3327 [3]. However, support for GRUU at a registrar 957 does not require support for RFC 3327. 959 A proxy MAY apply other processing to the request, such as execution 960 of called party features, as discussed in Section 6. 962 A request sent to a GRUU SHOULD NOT be redirected. In many 963 instances, a GRUU is used by a UA in order to assist in the traversal 964 of NATs and firewalls, and a redirection may prevent such a case from 965 working. 967 8.2.2. Record-Routing 969 The proxy that accesses the location service (called the home proxy 970 here) MUST record-route under two circumstances. Firstly, if the 971 home proxy receives a dialog forming request from a UA in its own 972 domain (an originating request) whose Contact header field contains a 973 GRUU (indicated by the presence of the "gruu" URI parameter), the 974 proxy MUST record-route. Secondly, if the home proxy receives a 975 dialog-forming request targeted to an AOR or GRUU within the domain 976 of the home proxy (a terminating request), and it translates the 977 Request URI into a contact that is associated with an instance ID to 978 which a GRUU has been assigned, the proxy MUST record-route. The URI 979 placed into the record-route MUST cause the request to be routed to a 980 proxy that can access the location service for that user. 982 8.2.3. Request Targeting for Mid-Dialog Requests 984 When a mid-dialog request is sent to a UA which used its GRUU as the 985 remote target, this mid-dialog request will arrive at the home proxy. 986 As a consequence of the record-routing procedures in Section 8.2.2, 987 this request will arrive with a Request-URI equal to the GRUU, and 988 the topmost Route header field equal to the URI placed into the 989 Record-Route previously. 991 Proxy processing of this request is nearly identical to that of 992 Section 8.2.1. The proxy MUST look up the GRUU in the location 993 service, and translate it to the registered contacts. If, based on 994 the procedures of Section 8.2.1, this lookup fails or produces no 995 contacts, the request MUST be rejected as described there. If the 996 lookup produces a single registered contact, that contact is placed 997 into the Request-URI. As with requests outside of a dialog, the 998 "grid" URI parameter is placed into the translated URI (having either 999 been copied from the Request-URI or placed there with no value 1000 otherwise). If there are multiple registered contacts (which happens 1001 when the client registers multiple flows using [11]), the proxy 1002 chooses one arbitrarily. The actual one that is chosen is not 1003 relevant; the Request-URI will not be used by an edge proxy compliant 1004 to [11] to deliver the request to the UA. 1006 Once the proxy finishes its processing, it will pop the topmost Route 1007 header field value. If there were additional Route header field 1008 values beyond the one pointing to the home proxy, these are not 1009 touched or modified in any way by the procedures defined here. Any 1010 Path values that may have been registered are not used. If there 1011 were no additional Route header field values beyond the one pointing 1012 to the home proxy, any Path values that were registered MUST be used 1013 as if this was a request sent outside of any existing dialog. 1015 The request is then forwarded based on the rules in RFC 3261. This 1016 will use any Route header field values if present, else will use the 1017 Request-URI. If the Request-URI is being used, the request gets 1018 delivered using the procedures of [11] if the contact was registered 1019 using those mechanisms. 1021 9. The opaque SIP URI Parameter 1023 This specification defines a new SIP URI parameter, "opaque". The 1024 "opaque" URI parameter is used to construct a URI (called the derived 1025 URI) that is related to another URI (called the base URI, frequently 1026 an AOR) in some way. In this specification, the parameter is used to 1027 construct the GRUU (the derived URI) from the AOR (the base URI). 1028 However, there are many other applications outside of GRUU. It can 1029 be used, for example, to construct a URI for a voicemail inbox (the 1030 derived URI) from a subscriber's AOR (the base URI), or the URI for a 1031 video service advertised via presence [22] (the derived URI) from the 1032 subscriber's AOR (the base URI). 1034 To construct a derived URI, the owner of the domain adds the "opaque" 1035 URI parameter to the base URI, resulting in the derived URI. In 1036 fact, these are the only semantics associated with the "opaque" URI 1037 parameter: a URI containing the parameter MUST be related to another 1038 URI, obtained by stripping the "opaque" URI parameter. Because the 1039 "opaque" URI parameter implies a relationship, any element (including 1040 those outside the domain that owns the URI) that receives a URI with 1041 the "opaque" URI parameter will know definitively that it is a 1042 derived URI, and can strip it to obtain the base URI. 1044 The value of the "opaque" URI parameter is not relevant to anyone 1045 except for the owner of the domain. It typically contains 1046 information needed by the owner of the domain to correctly process a 1047 request targeted to that URI according to the desired semantics of 1048 the URI. As such, the parameter is a form of cookie. In the case of 1049 a GRUU, the "opaque" URI parameter contains enough information for 1050 the owner of the domain to determine the instance ID. Since the 1051 structure of its value is not subject to standardization, it can only 1052 be interpreted by the same proxy or cluster of proxies that created 1053 the derived URI. For this reason, a proxy or cluster of proxies MUST 1054 NOT create a derived URI unless a request sent to the base URI (and 1055 consequently the derived URI) will be routed back to that same proxy 1056 or cluster of proxies without any upstream proxies requiring 1057 interpretation of the "opaque" URI parameter. Simply put, a request 1058 sent to a derived URI has to get back to the same proxy farm that 1059 created the derived URI. 1061 The presence of the "opaque" URI parameter in a URI implies a 1062 relationship between that URI and its base URI. However, the nature 1063 of that relationship cannot be determined from inspection of the URI 1064 alone. In some cases, there may be no way to know the relationship 1065 outside of the domain that constructed the URI. In other cases, as 1066 with GRUU, the nature of the relationship can be determined from the 1067 URI. When any element receives a URI with the "gruu" URI parameter, 1068 and that URI contains the "opaque" URI parameter, the URI formed by 1069 stripping the "opaque" and "gruu" URI parameter is the AOR associated 1070 with the GRUU. 1072 10. Grammar 1074 This specification defines one new Contact header field parameter 1075 ("gruu") by extending the grammar for "contact-params" as defined in 1076 RFC 3261. It also defines three new SIP URI parameters ("grid", 1077 "gruu" and "opaque") by extending the grammar for "uri-parameter" as 1078 defined in RFC 3261. The grammar for string-value is obtained from 1079 [8]. 1081 contact-params =/ c-p-gruu 1082 c-p-gruu = "gruu" EQUAL LDQUOT (SIP-URI / SIPS-URI) RDQUOT 1083 uri-parameter =/ grid-param / opaque-param / gruu-param 1084 grid-param = "grid" ["=" pvalue] ; defined in RFC3261 1085 opaque-param = "opaque=" pvalue ; defined in RFC3261 1086 gruu-param = "gruu" 1088 11. Requirements 1090 This specification was created in order to meet the following 1091 requirements: 1093 REQ 1: When a UA invokes a GRUU, it MUST cause the request to be 1094 routed to the specific UA instance to which the GRUU refers. 1096 REQ 2: It MUST be possible for a GRUU to be invoked from anywhere on 1097 the Internet, and still cause the request to be routed 1098 appropriately. That is, a GRUU MUST NOT be restricted to use 1099 within a specific addressing realm. 1101 REQ 3: It MUST be possible for a GRUU to be constructed without 1102 requiring the network to store additional state. 1104 REQ 4: It MUST be possible for a UA to obtain a multiplicity of GRUUs 1105 that each route to that UA instance. For example, this is needed 1106 to support ad-hoc conferencing where a UA instance needs a 1107 different URI for each conference it is hosting. 1109 REQ 5: When a UA receives a request sent to a GRUU, it MUST be 1110 possible for the UA to know the GRUU that was used to invoke the 1111 request. This is necessary as a consequence of REQ 4. 1113 REQ 6: It MUST be possible for a UA to add opaque content to a GRUU. 1114 This content is not interpreted or altered by the network, and is 1115 used only by the UA instance to whom the GRUU refers. This 1116 provides a basic cookie type of functionality, allowing a UA to 1117 build a GRUU with the state embedded. 1119 REQ 7: It MUST be possible for a proxy to execute services and 1120 features on behalf of a UA instance represented by a GRUU. As an 1121 example, if a user has call blocking features, a proxy may want to 1122 apply those call blocking features to calls made to the GRUU, in 1123 addition to calls made to the user's AOR. 1125 REQ 8: It MUST be possible for a UA in a dialog to inform its peer of 1126 its GRUU, and for the peer to know that the URI represents a GRUU. 1127 This is needed for the conferencing and dialog reuse applications 1128 of GRUUs, where the URIs are transferred within a dialog. 1130 REQ 9: When transferring a GRUU per REQ 8, it MUST be possible for 1131 the UA receiving the GRUU to be assured of its integrity and 1132 authenticity. 1134 REQ 10: It MUST be possible for a server that is authoritative for a 1135 domain to construct a GRUU which routes to a UA instance bound to 1136 an AOR in that domain. In other words, the proxy can construct a 1137 GRUU, too. This is needed for the presence application. 1139 12. Example Call Flow 1141 The following call flow, shown in Figure 2, shows a basic 1142 registration and call setup, followed by a subscription directed to 1143 the GRUU. It then shows a failure of the callee, followed by a re- 1144 registration. The conventions of [18] are used to describe 1145 representation of long message lines. 1147 Caller Proxy Callee 1148 | |(1) REGISTER | 1149 | |<--------------------| 1150 | |(2) 200 OK | 1151 | |-------------------->| 1152 |(3) INVITE | | 1153 |-------------------->| | 1154 | |(4) INVITE | 1155 | |-------------------->| 1156 | |(5) 200 OK | 1157 | |<--------------------| 1158 |(6) 200 OK | | 1159 |<--------------------| | 1160 |(7) ACK | | 1161 |-------------------->| | 1162 | |(8) ACK | 1163 | |-------------------->| 1164 |(9) SUBSCRIBE | | 1165 |-------------------->| | 1166 | |(10) SUBSCRIBE | 1167 | |-------------------->| 1168 | |(11) 200 OK | 1169 | |<--------------------| 1170 |(12) 200 OK | | 1171 |<--------------------| | 1172 | |(13) NOTIFY | 1173 | |<--------------------| 1174 |(14) NOTIFY | | 1175 |<--------------------| | 1176 |(15) 200 OK | | 1177 |-------------------->| | 1178 | |(16) 200 OK | 1179 | |-------------------->| 1180 | | |Crashes, 1181 | |(17) REGISTER | Reboots 1182 | |<--------------------| 1183 | |(18) 200 OK | 1184 | |-------------------->| 1186 Figure 2 1188 The Callee supports the GRUU extension. As such, its REGISTER (1) 1189 looks like: 1191 REGISTER sip:example.com SIP/2.0 1192 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 1193 Max-Forwards: 70 1194 From: Callee ;tag=a73kszlfl 1195 Supported: gruu 1196 To: Callee 1197 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 1198 CSeq: 1 REGISTER 1199 Contact: 1200 ;+sip.instance="" 1201 Content-Length: 0 1203 The REGISTER response would look like: 1205 SIP/2.0 200 OK 1206 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 1207 From: Callee ;tag=a73kszlfl 1208 To: Callee ;tag=b88sn 1209 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 1210 CSeq: 1 REGISTER 1211 1212 Contact: 1213 ;gruu="sip:callee@example.com;gruu; 1214 opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 1215 ;+sip.instance="" 1216 ;expires=3600 1217 1218 Content-Length: 0 1220 Note how the Contact header field in the REGISTER response contains 1221 the gruu parameter with the URI sip:callee@example.com;gruu; 1222 opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6. This 1223 represents a GRUU that translates to the contact 1224 sip:callee@192.0.2.1. 1226 The INVITE from the caller is a normal SIP INVITE. However, the 200 1227 OK generated by the callee (message 5) now contains a GRUU as the 1228 remote target. The UA has also chosen to include a "grid" URI 1229 parameter into the GRUU. 1231 SIP/2.0 200 OK 1232 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8 1233 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a 1234 From: Caller ;tag=n88ah 1235 To: Callee ;tag=a0z8 1236 Call-ID: 1j9FpLxk3uxtma7@host.example.com 1237 CSeq: 1 INVITE 1238 Supported: gruu 1239 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, SUBSCRIBE 1240 1241 Contact: 1242 1244 1245 Content-Length: -- 1246 Content-Type: application/sdp 1248 [SDP Not shown] 1250 At some point later in the call, the caller decides to subscribe to 1251 the dialog event package [17] at that specific UA. To do that, it 1252 generates a SUBSCRIBE request (message 9), but directs it towards the 1253 remote target, which is a GRUU: 1255 1256 SUBSCRIBE sip:callee@example.com;gruu;opaque=urn:uuid:f8 1257 1d4fae-7dec-11d0-a765-00a0c91e6bf6;grid=99a 1258 SIP/2.0 1259 1260 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 1261 From: Caller ;tag=kkaz- 1262 1263 To: 1265 1266 Call-ID: faif9a@host.example.com 1267 CSeq: 2 SUBSCRIBE 1268 Supported: gruu 1269 Event: dialog 1270 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY 1271 Contact: 1272 Content-Length: 0 1274 In this example, the caller itself supports the GRUU extension, and 1275 is using its own GRUU to populate its remote target. 1277 This request is routed to the proxy, which proceeds to perform a 1278 location lookup on the Request-URI. It is translated into the 1279 contact for that instance, and then proxied to that contact. Note 1280 how the "grid" parameter is maintained, and the "gruu" parameter is 1281 no longer present. 1283 SUBSCRIBE sip:callee@192.0.2.1;grid=99a SIP/2.0 1284 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK9555 1285 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 1286 From: Caller ;tag=kkaz- 1287 1288 To: 1290 1291 Call-ID: faif9a@host.example.com 1292 CSeq: 2 SUBSCRIBE 1293 Supported: gruu 1294 Event: dialog 1295 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY 1296 Contact: 1297 Content-Length: 0 1299 At some point after message 16 is received, the callee's machine 1300 crashes and recovers. It obtains a new IP address, 192.0.2.2. 1301 Unaware that it had previously had an active registration, it creates 1302 a new one (message 17 below). Notice how the instance ID remains the 1303 same, as it persists across reboot cycles: 1305 REGISTER sip:example.com SIP/2.0 1306 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba 1307 Max-Forwards: 70 1308 From: Callee ;tag=ha8d777f0 1309 Supported: gruu 1310 To: Callee 1311 Call-ID: hf8asxzff8s7f@192.0.2.2 1312 CSeq: 1 REGISTER 1313 Contact: 1314 ;+sip.instance="" 1315 Content-Length: 0 1317 The registrar notices that a different contact, sip:callee@192.0.2.1, 1318 is already associated with the same instance ID. It registers the 1319 new one too and returns both in the REGISTER response. Both have the 1320 same GRUU. However, only this new contact (the most recently 1321 registered one) will be used by the proxy for population in the 1322 target set. The registrar then generates the following response: 1324 SIP/2.0 200 OK 1325 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba 1326 From: Callee ;tag=ha8d777f0 1327 To: Callee ;tag=99f8f7 1328 Call-ID: hf8asxzff8s7f@192.0.2.2 1329 CSeq: 1 REGISTER 1330 1331 Contact: 1332 ;gruu="sip:callee@example.com;gruu;opaque=urn: 1333 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 1334 ;+sip.instance="" 1335 ;expires=3600 1336 1337 1338 Contact: 1339 ;gruu="sip:callee@example.com;gruu;opaque=urn: 1340 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 1341 ;+sip.instance="" 1342 ;expires=400 1343 1344 Content-Length: 0 1346 13. Security Considerations 1348 It is important for a UA to be assured of the integrity of a GRUU 1349 given in a REGISTER response. If the GRUU is tampered with by an 1350 attacker, the result could be denial of service to the UA. As a 1351 result, it is RECOMMENDED that a UA use the SIPS URI scheme in the 1352 Request-URI when registering. Proxies and registrars MUST support 1353 the sips URI and MUST support TLS. Note that this does not represent 1354 a change from the requirements in RFC 3261. 1356 The example GRUU construction algorithm in Appendix A.1 makes no 1357 attempt to create a GRUU that hides the AOR and instance ID 1358 associated with the GRUU. In general, determination of the AOR 1359 associated with a GRUU is considered a good property, since it allows 1360 for easy tracking of the target of a particular call. Learning the 1361 instance ID provides little benefit to an attacker. To register or 1362 otherwise impact registrations for the user, an attacker would need 1363 to obtain the credentials for the user. Knowing the instance ID is 1364 insufficient. 1366 The example GRUU construction algorithm in Appendix A.1 makes no 1367 attempt to create a GRUU that prevents users from guessing a GRUU 1368 based on knowledge of the AOR and instance ID. A user that is able 1369 to do that will be able to direct a new request at a particular 1370 instance. However, this specification recommends that service 1371 treatment (in particular, screening features) be given to requests 1372 that are sent to a GRUU. That treatment will make sure that the GRUU 1373 does not provide a back door for attackers to contact a user that has 1374 tried to block the attacker. 1376 GRUUs do not provide a solution for privacy. In particular, since 1377 the GRUU does not change during the lifetime of a registration, an 1378 attacker could correlate two calls as coming from the same source, 1379 which in and of itself reveals information about the caller. 1380 Furthermore, GRUUs do not address other aspects of privacy, such as 1381 the addresses used for media transport. For a discussion of how 1382 privacy services are provided in SIP, see RFC 3323 [12]. 1384 As a consequence of this specification, a UA will begin using GRUU in 1385 the dialog forming and target refresh requests and responses it 1386 emits. These GRUU will be passed to other UA (called the 1387 correspondent), which then use them in requests that they emit. 1388 These UA might be malicious, and attempt to remove the "gruu", 1389 "grid", or "opaque" parameters from the URI before using it. 1390 Consequently, consideration must be given to the effect of such 1391 removal. 1393 If a malicious correspondent removes the "gruu" URI parameter, the 1394 request will be routed to the home proxy. Despite the absence of the 1395 "gruu" parameter, the home proxy will still recognize the URI as a 1396 GRUU, based on the presence and value of the "opaque" parameter. 1397 Consequently, a home proxy SHOULD NOT rely solely on the presence of 1398 the "gruu" parameter to determine that a URI is a GRUU. If a 1399 malicious correspondent removes both the "gruu" and "opaque" URI 1400 parameters, the resulting URI will, in many cases, look identical to 1401 an AOR, and thus receive the same treatment as an AOR. If this is 1402 done in a mid-dialog request, the proxy might translate the AOR to a 1403 registered contact. If this registered contact points to a different 1404 UA instance than the one in the dialog, the request might be 1405 misrouted to that instance. Since the dialog doesn't exist there, 1406 the request is rejected. This has no harmful effects to anyone 1407 except for the malicious correspondent. If a malicious correspondent 1408 removes the "grid" parameter, the request will be delivered to the 1409 UA, but contain an empty "grid" parameter inserted by the home proxy. 1410 If a UA requires the "grid" parameter to process the request, then it 1411 SHOULD always insert a "grid" parameter into all GRUU it hands out, 1412 with a different value for each. Consequently, if a request should 1413 arrive with an empty "grid" parameter, the UA will know that the 1414 parameter had been stripped by a malicious correspondent, and it can 1415 reject the request if desired. 1417 14. IANA Considerations 1419 This specification defines a new Contact header field parameter, 1420 three SIP URI parameters, and a SIP option tag. 1422 14.1. Header Field Parameter 1424 This specification defines a new header field parameter, as per the 1425 registry created by [9]. The required information is as follows: 1427 Header field in which the parameter can appear: Contact 1429 Name of the Parameter: gruu 1431 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1432 RFC number of this specification.]] 1434 14.2. URI Parameters 1436 This specification defines three new SIP URI parameters, as per the 1437 registry created by [10]. 1439 Name of the Parameter: grid 1441 Predefined Values: none 1443 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1444 RFC number of this specification.]] 1446 Name of the Parameter: opaque 1448 Predefined Values: none 1450 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1451 RFC number of this specification.]] 1453 Name of the Parameter: gruu 1455 Predefined Values: none 1457 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1458 RFC number of this specification.]] 1460 14.3. SIP Option Tag 1462 This specification registers a new SIP option tag, as per the 1463 guidelines in Section 27.1 of RFC 3261. 1465 Name: gruu 1467 Description: This option tag is used to identify the Globally 1468 Routable User Agent URI (GRUU) extension. When used in a 1469 Supported header, it indicates that a User Agent understands the 1470 extension. When used in a Require header field of a REGISTER 1471 request, it indicates that the registrar shouldn't process the 1472 registration unless it supports the GRUU extension. 1474 15. Acknowledgements 1476 The author would like to thank Rohan Mahy, Paul Kyzivat, Alan 1477 Johnston, Ya-Ching Tan, Jeroen van Bemmel, Fredrik Thulin and Cullen 1478 Jennings for their comments and contributions to this work. 1480 16. References 1482 16.1. Normative References 1484 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1485 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1486 Session Initiation Protocol", RFC 3261, June 2002. 1488 [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1489 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1491 [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 1492 Extension Header Field for Registering Non-Adjacent Contacts", 1493 RFC 3327, December 2002. 1495 [4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1496 Method", RFC 3311, October 2002. 1498 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1499 Levels", BCP 14, RFC 2119, March 1997. 1501 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1502 Notification", RFC 3265, June 2002. 1504 [7] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1505 Method", RFC 3515, April 2003. 1507 [8] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1508 User Agent Capabilities in the Session Initiation Protocol 1509 (SIP)", RFC 3840, August 2004. 1511 [9] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1512 Header Field Parameter Registry for the Session Initiation 1513 Protocol (SIP)", BCP 98, RFC 3968, December 2004. 1515 [10] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1516 Uniform Resource Identifier (URI) Parameter Registry for the 1517 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, 1518 December 2004. 1520 [11] Jennings, C. and R. Mahy, "Managing Client Initiated 1521 Connections in the Session Initiation Protocol (SIP)", 1522 draft-ietf-sip-outbound-03 (work in progress), March 2006. 1524 16.2. Informative References 1526 [12] Peterson, J., "A Privacy Mechanism for the Session Initiation 1527 Protocol (SIP)", RFC 3323, November 2002. 1529 [13] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 1530 - Simple Traversal of User Datagram Protocol (UDP) Through 1531 Network Address Translators (NATs)", RFC 3489, March 2003. 1533 [14] Rosenberg, J., "A Framework for Conferencing with the Session 1534 Initiation Protocol (SIP)", RFC 4353, February 2006. 1536 [15] Rosenberg, J., "Request Authorization through Dialog 1537 Identification in the Session Initiation Protocol (SIP)", 1538 RFC 4538, June 2006. 1540 [16] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1541 Identity Management in the Session Initiation Protocol (SIP)", 1542 draft-ietf-sip-identity-06 (work in progress), October 2005. 1544 [17] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 1545 Initiated Dialog Event Package for the Session Initiation 1546 Protocol (SIP)", RFC 4235, November 2005. 1548 [18] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and 1549 H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test 1550 Messages", RFC 4475, May 2006. 1552 [19] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1553 Preferences for the Session Initiation Protocol (SIP)", 1554 RFC 3841, August 2004. 1556 [20] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and 1557 J. Peterson, "Presence Information Data Format (PIDF)", 1558 RFC 3863, August 2004. 1560 [21] Sparks, R., "Session Initiation Protocol Call Control - 1561 Transfer", draft-ietf-sipping-cc-transfer-06 (work in 1562 progress), March 2006. 1564 [22] Rosenberg, J., "A Data Model for Presence", 1565 draft-ietf-simple-presence-data-model-07 (work in progress), 1566 January 2006. 1568 [23] Rosenberg, J., "A Presence Event Package for the Session 1569 Initiation Protocol (SIP)", RFC 3856, August 2004. 1571 [24] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) 1572 "Join" Header", RFC 3911, October 2004. 1574 [25] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1575 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 1577 [26] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1578 Package for Registrations", RFC 3680, March 2004. 1580 [27] Kyzivat, P., "Registration Event Package Extension for Session 1581 Initiation Protocol (SIP) Globally Routable User Agent URIs 1582 (GRUU)", draft-ietf-sipping-gruu-reg-event-06 (work in 1583 progress), May 2006. 1585 Appendix A. Example GRUU Construction Algorithms 1587 The mechanism for constructing a GRUU is not subject to 1588 specification. This appendix provides two examples that can be used 1589 by a registar. Of course, others are permitted, as long as they meet 1590 the constraints defined for a GRUU. 1592 A.1. Instance ID in "opaque" URI Parameter 1594 The most basic approach for constructing a GRUU is to utilize the 1595 "opaque" URI parameter. The user and domain portions of the URI are 1596 equal to the AOR, and the "opaque" parameter is populated with the 1597 instance ID. 1599 A.2. Encrypted Instance ID and AOR 1601 In many cases, it will be desirable to construct the GRUU in such a 1602 way that it will not be possible, based on inspection of the URI, to 1603 determine the Contact URI that the GRUU translates to. It may also 1604 be desirable to construct it so that it will not be possible to 1605 determine the instance ID/AOR pair associated with the GRUU. Whether 1606 a GRUU should be constructed with this property is a local policy 1607 decision. 1609 With these rules, it is possible to construct a GRUU without 1610 requiring the maintenance of any additional state. To do that, the 1611 URI would be constructed in the following fashion: 1613 user-part = "GRUU" | BASE64(E(K, (salt | " " | AOR | " " | 1614 instance ID))) 1616 Where E(K,X) represents a suitable encryption function (such as AES 1617 with 128-bit keys) with key K applied to data block X, and the "|" 1618 operator signifies concatenation. The single space (" ") between 1619 components is used as a delimiter, so that the components can easily 1620 be extracted after decryption. Salt represents a random string that 1621 prevents a client from obtaining pairs of known plaintext and 1622 ciphertext. A good choice would be at least 128 bits of randomness 1623 in the salt. 1625 This mechanism uses the user-part of the SIP URI to convey the 1626 encrypted AOR and instance ID. The user-part is used instead of the 1627 "opaque" URI parameter because it has the desired anonymity 1628 properties. 1630 The benefit of this mechanism is that a server need not store 1631 additional information on mapping a GRUU to its corresponding 1632 contact. The user-part of the GRUU contains the instance ID and AOR. 1633 Assuming that the domain stores registrations in a database indexed 1634 by the AOR, the proxy processing the GRUU would look up the AOR, 1635 extract the currently registered contacts, and find the one that 1636 matches the instance ID encoded in the Request-URI. The contact 1637 whose instance ID is that instance ID is then used as the translated 1638 version of the GRUU. Encryption is needed to prevent attacks whereby 1639 the server is sent requests with fake GRUUs, causing the server to 1640 direct requests to any named URI. Even with encryption, the proxy 1641 should validate the user part after decryption. In particular, the 1642 AOR should be managed by the proxy in that domain. Should a UA send 1643 a request with a fake GRUU, the proxy would decrypt and then discard 1644 it because there would be no URI or an invalid URI inside. 1646 While this approach has many benefits, it has the drawback of 1647 producing fairly long GRUUs. 1649 Author's Address 1651 Jonathan Rosenberg 1652 Cisco Systems 1653 600 Lanidex Plaza 1654 Parsippany, NJ 07054 1655 US 1657 Phone: +1 973 952-5000 1658 Email: jdrosen@cisco.com 1659 URI: http://www.jdrosen.net 1661 Intellectual Property Statement 1663 The IETF takes no position regarding the validity or scope of any 1664 Intellectual Property Rights or other rights that might be claimed to 1665 pertain to the implementation or use of the technology described in 1666 this document or the extent to which any license under such rights 1667 might or might not be available; nor does it represent that it has 1668 made any independent effort to identify any such rights. Information 1669 on the procedures with respect to rights in RFC documents can be 1670 found in BCP 78 and BCP 79. 1672 Copies of IPR disclosures made to the IETF Secretariat and any 1673 assurances of licenses to be made available, or the result of an 1674 attempt made to obtain a general license or permission for the use of 1675 such proprietary rights by implementers or users of this 1676 specification can be obtained from the IETF on-line IPR repository at 1677 http://www.ietf.org/ipr. 1679 The IETF invites any interested party to bring to its attention any 1680 copyrights, patents or patent applications, or other proprietary 1681 rights that may cover technology that may be required to implement 1682 this standard. Please address the information to the IETF at 1683 ietf-ipr@ietf.org. 1685 Disclaimer of Validity 1687 This document and the information contained herein are provided on an 1688 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1689 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1690 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1691 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1692 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1693 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1695 Copyright Statement 1697 Copyright (C) The Internet Society (2006). This document is subject 1698 to the rights, licenses and restrictions contained in BCP 78, and 1699 except as set forth therein, the authors retain all their rights. 1701 Acknowledgment 1703 Funding for the RFC Editor function is currently provided by the 1704 Internet Society.