idnits 2.17.1 draft-ietf-sip-gruu-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 84 has weird spacing: '...rencing frame...' == Line 861 has weird spacing: '...try for the S...' == 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 (February 15, 2004) is 7376 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. '3') (Obsoleted by RFC 6665) == Outdated reference: A later version (-02) exists of draft-ietf-sip-parameter-registry-01 == Outdated reference: A later version (-02) exists of draft-ietf-sip-uri-parameter-reg-01 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-01 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-03 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-01 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Rosenberg 3 Internet-Draft dynamicsoft 4 Expires: August 15, 2004 February 15, 2004 6 Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in 7 the Session Initiation Protocol (SIP) 8 draft-ietf-sip-gruu-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 15, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 Several applications of the Session Initiation Protocol (SIP) require 39 a user agent (UA) to construct and distribute a URI which can be used 40 by anyone on the Internet to route a call to that specific UA 41 instance. A URI which routes to a specific UA instance is called a 42 Globally Routable UA URI (GRUU). This document describes an extension 43 to SIP for obtaining a GRUU from a server, and for communicating a 44 GRUU to a peer within a dialog. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Defining a GRUU . . . . . . . . . . . . . . . . . . . . . . 3 51 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 4.1 REFER . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4.2 Conferencing . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4.3 Presence . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Overview of Operation . . . . . . . . . . . . . . . . . . . 5 56 6. User Agent Behavior . . . . . . . . . . . . . . . . . . . . 6 57 6.1 REGISTER Processing . . . . . . . . . . . . . . . . . . . . 6 58 6.2 Using the GRUU . . . . . . . . . . . . . . . . . . . . . . . 7 59 7. Registrar Behavior . . . . . . . . . . . . . . . . . . . . . 8 60 7.1 Creation and Maintenance of GRUUs . . . . . . . . . . . . . 8 61 7.2 Providing GRUUs to User Agents . . . . . . . . . . . . . . . 11 62 8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 63 9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 10. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 13 65 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 12. Security Considerations . . . . . . . . . . . . . . . . . . 17 67 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 68 13.1 Header Field Parameter . . . . . . . . . . . . . . . . . . . 18 69 13.2 URI Parameter . . . . . . . . . . . . . . . . . . . . . . . 18 70 13.3 Media Feature Tag . . . . . . . . . . . . . . . . . . . . . 18 71 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 72 Normative References . . . . . . . . . . . . . . . . . . . . 19 73 Informative References . . . . . . . . . . . . . . . . . . . 20 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . 21 75 Intellectual Property and Copyright Statements . . . . . . . 22 77 1. Introduction 79 Several applications of the Session Initiation Protocol (SIP) [1] 80 require a user agent (UA) to construct and distribute a URI which can 81 be used by anyone on the Internet to route a call to that specific UA 82 instance. An example of such an application is call transfer, based 83 on the REFER method [4]. Another application is the usage of 84 endpoint-hosted conferences within the conferencing framework [10]. 85 We call these URIs Globally Routable UA URIs (GRUU). This 86 specification provides a mechanism for obtaining and using GRUUs. 88 2. Terminology 90 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 91 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 92 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and 93 indicate requirement levels for compliant implementations. 95 3. Defining a GRUU 97 A GRUU is a SIP URI which has a specific set of characteristics: 98 Global: It can be used by any UAC connected to the Internet. In 99 that regard, it is like an address-of-record (AOR) for a user. The 100 address-of-record for a user, sip:joe@example.com, is meant to be 101 used by anyone to call that user. The same is true for a GRUU. 102 Temporally Scoped: It may be temporally scoped. In that regard, 103 its not like an AOR for a user. The general assumption is that an 104 AOR for a user is valid so long as the user resides within that 105 domain (of course, policies can be imposed to limit its validity, 106 but that is not the default case). However, a GRUU has a limited 107 lifetime by default. It can never be valid for longer than the 108 duration of the registration of the UA to which it is bound. For 109 example, if my PC registers to the SIP network, a GRUU for my PC 110 is only valid as long as my PC is registered. If the PC 111 unregisters, the GRUU is invalid; calls to it would result in a 112 404. If the PC comes back, the GRUU will be valid once more. 113 Furthermore, it will frequently be the case that the GRUU has a 114 lifetime shorter than the duration of the registration. 115 Instance Routing: It routes to a specific UA instance, and never 116 forks. In that regard, it is unlike an address-of-record. When a 117 call is made to a normal AOR which represents a user, routing 118 logic is applied in proxies to deliver the call to one or more 119 UAs. That logic can result in a different routing decision based 120 on the time-of-day, or the identity of the caller. However, when a 121 call is made to a GRUU, the routing logic is much more static. It 122 has to cause the call to be delivered to a very specific UA 123 instance. That UA instance has to be the same UA instance for any 124 request sent to that GRUU. This does not mean that a GRUU 125 represents a fundamentally different type of URI; it only means 126 that the logic a proxy applies to a GRUU is going to generally be 127 simpler than that it applies to a normal AOR. 129 4. Use Cases 131 We have encountered several use cases for a GRUU. 133 4.1 REFER 135 Consider a blind transfer application [14]. User A is talking to user 136 B. A wants to transfer the call to user C. So, it sends a REFER to 137 user C. That REFER looks like, in part: 139 REFER sip:C@example.com SIP/2.0 140 From: sip:A@example.com;tag=99asd 141 To: sip:C@example.com 142 Refer-To: (URI that identifiers B's UA) 144 The Refer-To header needs to contain a URI that can be used by C to 145 place a call to B. However, this call needs to route to the specific 146 UA instace which B is using to talk to A. If it didn't, the transfer 147 service would not execute. This URI is provided to A by B. Because B 148 doesn't know who A will transfer the call to, the URI has to be 149 usable by anyone. Therefore, it is a GRUU. 151 4.2 Conferencing 153 A similar need arises in conferencing [10]. In that framework, a 154 conference is described by a URI which identifies the focus of the 155 conference. The focus is a SIP UA at the center of a conference. Each 156 conference participant has a dialog with the focus. One case 157 described in the framework is where a user A has made a call to B. 158 They then put B on hold, and call C. Now, A has two separate dialogs 159 for two separate calls - one to B, and one to C. A would like to 160 conference them. One model is that A morphs itself into a focus. It 161 sends a re-INVITE on each existing dialog, and provides both B and C 162 with an updated URI that now holds the conference URI. It also has a 163 callee capabilities [6] parameter which indicates that this URI is a 164 conference URI. A proceeds to mix the media streams from B and C. 165 This is called an ad-hoc conference. 167 At this point, normal conferencing features can be applied. That 168 means that B can send another user, D, the conference URI, perhaps in 169 an email. D can send an INVITE to that URI, and join the conference. 170 For this to work, the conference URI used by A in its re-INVITE has 171 to be usable by anyone, and it has to route to the specific UA 172 instance of A that is acting as the focus. If it didn't, basic 173 conferencing features would fail. Therefore, it is a GRUU. 175 4.3 Presence 177 In a SIP-based presence [15] system, the presence agent (PA) 178 generates notifications about the state of a user. This state is 179 represented with the Presence Information Document Format (PIDF) 180 [13]. In a PIDF document, a user is represented by a series of 181 tuples, each of which identifies the devices that the user has and 182 provides information about them. Each tuple also has a contact URI, 183 which is a SIP URI representing that device. A watcher can make a 184 call to that URI, with the expectation that the call is routed to the 185 device whose presence is represented in the tuple. 187 The URI in the presence document therefore has to route to the 188 specific UA instance whose presence was reported. Furthermore, since 189 the presence document could be used by anyone who subscribes to the 190 user, the URI has to be usable by anyone. As a result, it is a GRUU. 192 It is interesting to note that the GRUU may need to be constructed by 193 a presence agent, depending on how the presence document is computed 194 by the server. 196 5. Overview of Operation 198 This section is tutorial in nature, and does not specify any 199 normative behavior. 201 This extension allows a UA to obtain a GRUU, and to use a GRUU. These 202 two mechanisms are separate, in that a UA can obtain a GRUU in any 203 way it likes, and use the mechanisms in this specification to use 204 them. Similarly, a UA can obtain a GRUU but never use it. 206 A UA can obtain a GRUU by generating a normal REGISTER request, as 207 specified in RFC 3261 [1]. This request contains a Supported header 208 field with the value "gruu", indicating to the registrar that the UA 209 supports this extension. The UA includes a "sip.instance" media 210 feature tag in the Contact header field of each Contact for which a 211 GRUU is desired. This media feature tag contains a globally unique ID 212 that identifies the UA instance. If the domain that the user is 213 registering against also supports GRUU, the REGISTER responses will 214 contain the "gruu" parameter in each Contact header field. This 215 parameter contains a GRUU which the domain guarantees will route to 216 that UA instace. That GRUU is guaranteed to remain valid for the 217 duration of the registration. The GRUU is bound to the UA instace. 218 Should the client change its Contact URI, but indicate that it 219 represents the same instance ID, the server would provide the same 220 GRUU. Furthermore, if the registration for the Contact expires, and 221 the UA registers the Contact at a later time with the same instance 222 identifier, the server would provide the same GRUU. 224 Since the GRUU is a URI like any other, it can be handed out by a UA 225 by placing it in any header field which can contain a URI. A UA will 226 normally place the GRUU into the Contact header field of dialog 227 creating requests and responses it generates. However, it is 228 important for the UA receiving the message to know whether the 229 Contact URI is a GRUU or not. To make this determination, the UA 230 looks for the presence of the Supported header field in the request 231 or response. If it is present with a value of "gruu", it means that 232 the Contact URI is a GRUU. 234 When a UA uses a GRUU, it has the option of adding the "grid" URI 235 parameter to the GRUU. This parameter is opaque to the proxy server 236 handling the domain. However, when the server maps the GRUU to the 237 corresponding Contact URI, the server will copy the grid parameter 238 into the Contact URI. As a result, when the UA receives the request, 239 the Request URI will contain the grid parameter it placed in the 240 corresponding GRUU. 242 6. User Agent Behavior 244 User agent behavior is divided into two separate parts - REGISTER 245 processing, and GRUU usage. 247 6.1 REGISTER Processing 249 When a UA wishes to obtain a GRUU within the domain of its AOR, when 250 it generates a REGISTER request (initial or refresh), it MUST include 251 the Supported header field in the request. The value of that header 252 field MUST include "gruu" as one of the option tags. This alerts the 253 registrar for the domain that the UA supports the GRUU mechanism. 255 Furthermore, for each Contact for which the UA desires to obtain a 256 GRUU, the UA MUST include a "sip.instance" media feature tag as a UA 257 characteristic [6]. As described in [6], this media feature tag will 258 be encoded in the Contact header field as the "+sip.instance" Contact 259 header field parameter. The value of this parameter, as described in 260 Section 13.3, MUST be a globally unique identifier, and SHOULD remain 261 the same across all registrations generated from that particular UA 262 instance. 264 Besides the presence of the "gruu" option tag in the Supported header 265 field and the "+sip.instance" Contact header field parameter, the 266 REGISTER request is constructed identically to the case where this 267 extension was not understood. Specifically, the Contact URI in the 268 REGISTER request SHOULD NOT contain the gruu Contact header field 269 parameter. Any such parameters are ignored by the registrar, as the 270 UA cannot propose a GRUU for usage with the Contact URI. 272 If a UA wishes to guarantee that the request is not processed unless 273 the domain supports and uses this extension, it MAY include a Require 274 header field in the request with a value that contains the "gruu" 275 option tag. 277 If the response is a 2xx, each Contact header that contained the 278 "+sip.instance" Contact header field parameter may also contain a 279 "gruu" parameter. This parameter contains a SIP URI that represents a 280 GRUU corresponding to that UA instance. Any requests sent to the GRUU 281 URI will be routed by the domain to the Contact URI bound currently 282 bound to that instance ID. The GRUU will not change in subsequent 2xx 283 responses to REGISTER. Indeed, even if the UA lets the contact 284 expire, when it re-registers it at any later time, the registrar will 285 normally provide the same GRUU for the same address-of-record and the 286 UA instance ID. However, this property cannot be guaranteed, and a UA 287 MUST be prepared to receive a different GRUU in a subsequent 288 registration. 290 6.2 Using the GRUU 292 A UA first obtains a GRUU using the procedures of Section 6.1, or by 293 other means outside the scope of this specification. 295 A UA can use the GRUU in the same way it would use any other SIP URI. 296 However, a UA compliant to this specification MUST use a GRUU when 297 populating the Contact header field of dialog-creating requests and 298 responses. This includes the INVITE request and its 2xx response, the 299 SUBSCRIBE [3] request, its 2xx response, and the NOTIFY request, and 300 the REFER [4] request and its 2xx response. Similarly, in those 301 requests and responses where the GRUU is used in the Contact header 302 field, the UA MUST include a Supported header field that contains the 303 option tag "gruu". However, it is not necessary for a UA to know 304 whether or not its peer in the dialog uses a GRUU before inserting 305 one into the Contact header field. 307 When placing a GRUU into the Contact header field of a request or 308 response, a UA MAY add the "grid" URI parameter to the GRUU. This 309 parameter MAY take on any value permitted by the grammar for the 310 parameter. Note that there are no limitations on the size of this 311 parameter. When a UA sends a request to the GRUU, the proxy for the 312 domain that owns the GRUU will translate the GRUU in the Request-URI, 313 replacing it with the corresponding Contact URI. However, it will 314 retain the "grid" parameter when this translation is performed. As a 315 result, when the UA receives the request, the Request-URI will 316 contain the "grid" created by the UA. This allows the UA to 317 effectively manufacture an infinite supply of GRUU, each of which 318 differs by the value of the "grid" parameter. When a UA receives a 319 request that was sent to the GRUU, it will be able to tell which GRUU 320 was invoked by the "grid" parameter. 322 An implication of this behavior is that all mid-dialog requests will 323 be routed through intermediate proxies. There will never be direct, 324 UA to UA signaling. It is anticipated that this limitation will be 325 addressed in future specifications. 327 Once a UA knows that the Contact URI provided by its peer is a GRUU, 328 it can use it in any application or SIP extension which requires a 329 globally routable URI to operate. One such example is assisted call 330 transfer. 332 7. Registrar Behavior 334 A registrar compliant to this specification is responsible for the 335 creation and maintenance of GRUUs, and for providing those GRUU's to 336 a UA in response to a REGISTER request. 338 7.1 Creation and Maintenance of GRUUs 340 A domain is responsible for creation and maintenance of a GRUU, along 341 with its association to instance IDs, AORs and Contact URIs. These 342 associations are modeled in the UML diagram in Figure 2. 344 +-------------+ 345 | | 346 | | 347 | GRUU |----------------------+ 348 | | | 349 | | | 350 +-------------+ | 351 | 1 | 352 | | 353 | associated-with | 354 | | 355 | | 356 | 1 | 357 +----------------+ | 358 | | | 359 +--------| instance ID/ |------+ | 360 | | AOR Pair | | | 361 | | | | | 362 | +----------------+ | | 363 | | | 364 | | | 365 | | |translates 366 V V |to 367 +--------------+ +-----------+ | 368 | | | | | 369 | instance | | AOR | | 370 | ID | | | | 371 | | +-----------+ | 372 +--------------+ | | 373 ^ | | 374 | | | 375 | | | 376 | |is-bound-to | 377 | +----------------+ | | 378 | | | | | 379 | | | | | 380 +--------| Contact URI |<-----+ | 381 | | 0..* | 382 | | | 383 +----------------+ | 384 0..1 ^ | 385 | | 386 +-----------------------------+ 388 Figure 2 390 The combination of a UA instance ID and an AOR is referred to as an 391 instance ID/AOR pair. There is a one-to-one mapping between such a 392 pair and a GRUU; the GRUU is said to be associated with the pair, and 393 the pair is associated with the GRUU. As a result, if two instance 394 ID/AOR pairs are different, they each must be associated with a 395 different GRUU. If two GRUUs are different, they each must be 396 associated with a different instance ID/AOR pair. It is important to 397 understand that this uniqueness is over the instance ID/AOR pair, not 398 just the instance ID. For example, if a user registered the Contact 399 sip:ua@pc.example.com;+sip.instance="1", representing a device with 400 instance ID 1, to the AOR sip:user@example.com, and also registered 401 the same Contact, representing the same instance ID - 402 sip:ua@pc.example.com;+sip.instance="1" to a second AOR, say 403 sip:boss@example.com, each of those UA instances would have a 404 different GRUU, since they belong to different AORs. 406 A GRUU translates to zero or one Contact URIs. If the instance ID 407 associated with the GRUU is the instance ID of a Contact URI 408 currently bound to the AOR associated with that GRUU, then the GRUU 409 translates to that Contact URI. If, however, the instance ID 410 associated with the GRUU is not an instance ID of a Contact URI 411 currently bound to the AOR associated with the GRUU (possibly because 412 there are no Contact URIs bound to the AOR), the GRUU maps to no 413 Contact URI, and the GRUU is said to be invalid. 415 A registrar MAY create a GRUU for a particular instance ID/AOR pair 416 at any time. Of course, if a UA requests a GRUU in a registration, 417 and the registrar has not yet created one, it will need to do so in 418 order to respond to the registration request. However, the registrar 419 can create the GRUU in advance of any request from a UA. 421 This specification does not mandate a particular mechanism for 422 construction of the GRUU. However, the GRUU MUST exhibit the 423 following properties: 424 o The domain part of the URI is an IP address present on the public 425 Internet, or, if it is a host name, exists in the global DNS and 426 corresponds to an IP address present on the public Internet. 427 o When a request is sent to this URI, it routes to a proxy server in 428 the same domain as that of the registrar. 429 o A proxy server in the domain can determine that the URI is a GRUU. 430 o When a proxy server in this domain receives a request sent to a 431 URI that is a GRUU, that URI MUST be translated to the Contact URI 432 currently bound to the AOR associated with that GRUU whose 433 instance ID is the one associated with the GRUU. 435 In many cases, it will be desirable to construct the GRUU in such a 436 way that it will not be possible, based on inspection of the URI, to 437 determine the Contact URI that the GRUU translates to. It may also be 438 desirable to construct it so that it will not be possible to 439 determine the instance ID/AOR pair associated with the GRUU. Whether 440 or not a GRUU should be constructed with this property is a local 441 policy decision. 443 With these rules, it is possible, though not required, to construct a 444 GRUU without requiring the maintenance of any additional state. To do 445 that, the URI would be constructed in the following fashion: 446 user-part = "GRUU" + BASE64(E(K, (salt + instance ID + AOR))) 448 Where E(K,X) represents a suitable encryption function (such as AES 449 with 128 bit keys) with key K applied to data block X, and the "+" 450 operator implies concatenation. Salt represents a random string that 451 prevents a client from obtaining pairs of known plaintext and 452 ciphertext. A good choice would be at least 128 bits of randomness in 453 the salt. 455 The benefit of this mechanism is that a server need not store 456 additional information on mapping a GRUU to its corresponding Contact 457 URI. The user part of the GRUU contains the instance ID and AOR. 458 Assuming that the domain stores registrations in a database indexed 459 by the AOR, the proxy processing the GRUU would look up the AOR, 460 extract the currently registered Contacts, and find the one matching 461 the instance ID encoded in the request URI. The Contact URI whose 462 instance ID is that instance ID is then used as the translated 463 version of the URI. Encryption is needed to prevent attacks whereby 464 the server is sent requests with faked GRUU, causing the server to 465 direct requests to any named URI. Even with encryption, the proxy 466 should validate the user part after decryption. In particular, the 467 AOR should be one managed by the proxy in that domain. Should a UA 468 send a request with a fake GRUU, the proxy would decrypt and then 469 discard it because there would be no URI or an invalid URI inside. 471 Once an association from an instance ID/AOR to a GRUU is created, 472 that mapping MUST remain in existence, and valid, as long as there 473 exists any Contact bound to that AOR whose instance ID is that 474 instance ID. If, through a de-registration or expiration, there is no 475 longer any Contact bound to that AOR whose instance ID is that 476 instance ID, the registrar MUST remove the mapping, and invalidate 477 the GRUU. However, at any time in the future, should a UA register a 478 Contact to that same AOR indicating that it represents that same 479 instance ID, the registrar SHOULD provide the UA the same GRUU 480 provided previously. Indeed, this requirement would ideally be a MUST 481 if it was achieveable, but even with the stateless algorithm 482 described above, key rotation or server failures may cause the GRUU 483 associated with an instance ID/AOR pair to change. The value of 484 associatig the GRUU with an instance ID/AOR pair, as opposed to a 485 Contact URI/AOR pair, is that the association can transcend 486 registrations. As a result, registrars SHOULD make every effort 487 possible to maintain the association for as long as possible. 489 7.2 Providing GRUUs to User Agents 491 When a registrar compliant to this specification receives a REGISTER 492 request, it checks for the presence of the Require header field in 493 the request. If present, and if it contains the "gruu" option tag, 494 the registrar MUST follow the procedures in the next paragraph for 495 inclusion of the "gruu" parameter in a 2xx response to REGISTER. If 496 not present, but a Supported header field was present with the "gruu" 497 option tag, the registrar SHOULD follow the procedures in the next 498 paragraph for inclusion of the "gruu" parameter in a 2xx response to 499 REGISTER. If the Supported header field was not present, or it if was 500 present but did not contain the value "gruu", the registrar SHOULD 501 NOT follow the procedures of the next paragraph for inclusion of the 502 "gruu" parameter in a 2xx response to REGISTER. 504 If the register request contained any "gruu" Contact header field 505 parameters, these MUST be ignored by the registrar. A UA cannot 506 suggest or otherwise provide a GRUU to the registrar. 508 A GRUU is provided to a UA by including it in the "gruu" Contact 509 header field parameter for each Contact URI that contains a 510 "+sip.instance" Contact header field parameter. The value of the gruu 511 parameter is a quoted string containing the URI that is the GRUU for 512 the associated instance ID/AOR pair. If the server does not currently 513 have a GRUU associated with the instance ID/AOR, one is created 514 according to the procedures of Section 7.1. Otherwise, if a GRUU 515 already exists for that instance ID/AOR pair, the GRUU associated 516 with that pair MUST be placed into the "gruu" Contact header field 517 parameter of the REGISTER response. 519 Inclusion of a GRUU in the "gruu" Contact header field parameter of a 520 REGISTER response is separate from the computation and storage of the 521 GRUU. It is possible that the registrar has computed a GRUU for one 522 UA, but a different UA that queries for the current set of 523 registrations doesn't understand GRUU. In that case, the REGISTER 524 response sent to that second UA would not contain the "gruu" Contact 525 header field parameter, even though the UA has a GRUU for that 526 Contact. 528 8. Proxy Behavior 530 When a proxy server receives a request, and the proxy owns the domain 531 in the Request URI, and the proxy is supposed to access a Location 532 Service in order to compute request targets (as specified in Section 533 16.5 of RFC 3261 [1]), the proxy MUST check if the Request URI is a 534 GRUU created by that domain. 536 If the URI is a GRUU, the proxy MUST determine if there is still a 537 Contact URI bound to AOR associated with the GRUU, whose instance ID 538 is the instance ID associated with the GRUU. If that AOR no longer 539 has any contacts bound to it, or if it does have contacts bound to 540 it, but none of them have an instance ID equal to the instance ID 541 associated with the GRUU, the proxy MUST generate a 404 (Not Found) 542 response to the request. 544 Otherwise, the proxy MUST populate the target set with a single URI. 545 This URI MUST be equal to the Contact URI that is translated from the 546 GRUU. Furthermore, if the GRUU contained a "grid" URI parameter, the 547 URI in the target set MUST also contain the same parameter with the 548 same value. 550 A proxy MAY apply other processing to the request, such as execution 551 of called party features. In particular, it is RECOMMENDED that 552 non-routing called party features, such as call logging and 553 screening, that are associated with the AOR are also applied to 554 requests for all GRUUs associated with that AOR. 556 In many cases, a proxy will record-route an initial INVITE request, 557 and the user agents will insert a GRUU into the Contact header field. 558 When this happens, a mid-dialog request will arrive at the proxy with 559 a Route header field that was inserted by the proxy, and a 560 Request-URI that represents a GRUU. Proxies follow normal processing 561 in this case; they will strip the Route header field, and then 562 process the Request URI as described above. 564 The procedures of RFC 3261 are then followed to proxy the request. 565 The request SHOULD NOT be redirected in this case. In many instances, 566 a GRUU is used by a UA in order to assist in the traversal of NATs, 567 and a redirection may prevent such a case from working. 569 9. Grammar 571 This specification defines two new Contact header field parameters, 572 gruu and +sip.instance, and a new URI parameter, grid. The grammar 573 for string-value is obtained from [6]. 575 contact-params = c-p-q / c-p-expires / c-p-gruu / cp-instance 576 / contact-extension 577 c-p-gruu = "gruu" EQUAL DQUOTE SIP-URI DQUOTE 578 cp-instance = "+sip.instance" EQUAL LDQUOT string-value RDQUOT 579 uri-parameter = transport-param / user-param / method-param 580 / ttl-param / maddr-param / lr-param / grid-param 581 / other-param 582 grid-param = "grid=" pvalue 584 10. Requirements 586 This specification was created in order to meet the following 587 requirements: 588 REQ 1: When a UA invokes a GRUU, it MUST cause the request to be 589 routed to the specific UA instance to which the GRUU refers. 590 REQ 2: It MUST be possible for a GRUU to be invoked from anywhere on 591 the Internet, and still cause the request to be routed 592 appropriately. That is, a GRUU MUST NOT be restricted to use 593 within a specific addressing realm. 594 REQ 3: It MUST be possible for a GRUU to be constructed without 595 requiring the network to store additional state. 596 REQ 4: It MUST be possible for a UA to obtain a multiplicity of 597 GRUUs, each one of which routes to that UA instance. This is 598 needed to support ad-hoc conferencing, for example, where a a UA 599 instance needs a different URI for each conference it is hosting. 601 REQ 5: When a UA receives a request sent to a GRUU, it MUST be 602 possible for the UA to know the GRUU which was used to invoke the 603 request. This is necessary as a consequence of requirement 4. 604 REQ 6: It MUST be possible for a UA to add opaque content to a GRUU, 605 which is not interpreted or altered by the network, and used only 606 by the UA instance to whom the GRUU refers. This provides a basic 607 cookie type of functionality, allowing a UA to build a GRUU with 608 state embedded within it. 609 REQ 7: It MUST be possible for a proxy to execute services and 610 features on behalf of a UA instace represented by a GRUU. As an 611 example, if a user has call blocking features, a proxy may want to 612 apply those call blocking features to calls made to the GRUU in 613 addition to calls made to the user's AOR. 614 REQ 8: It MUST be possible for a UA in a dialog to inform its peer of 615 its GRUU, and for the peer to know that the URI represents a GRUU. 616 This is needed for the conferencing and dialog reuse applications 617 of GRUUs, where the URIs are transferred within a dialog. 618 REQ 9: When transferring a GRUU per requirement 8, it MUST be 619 possible for the UA receiving the GRUU to be assured of its 620 integrity and authenticity. 621 REQ 10: It MUST be possible for a server, authoritative for a domain, 622 to construct a GRUU which routes to a UA instace bound to an AOR 623 in that domain. In other words, the proxy can construct a GRUU 624 too. This is needed for the presence application. 626 11. Examples 628 The following call flow shows a basic registration and call setup, 629 followed by a subscription directed to the GRUU. 631 Caller Proxy Callee 632 | |(1) REGISTER | 633 | |<--------------------| 634 | |(2) 200 OK | 635 | |-------------------->| 636 |(3) INVITE | | 637 |-------------------->| | 638 | |(4) INVITE | 639 | |-------------------->| 640 | |(5) 200 OK | 641 | |<--------------------| 642 |(6) 200 OK | | 643 |<--------------------| | 644 |(7) ACK | | 645 |-------------------->| | 646 | |(8) ACK | 647 | |-------------------->| 648 |(9) SUBSCRIBE | | 649 |-------------------->| | 650 | |(10) SUBSCRIBE | 651 | |-------------------->| 652 | |(11) 200 OK | 653 | |<--------------------| 654 |(12) 200 OK | | 655 |<--------------------| | 656 | |(13) NOTIFY | 657 | |<--------------------| 658 |(14) NOTIFY | | 659 |<--------------------| | 660 |(15) 200 OK | | 661 |-------------------->| | 662 | |(16) 200 OK | 663 | |-------------------->| 665 The Callee supports the GRUU extension. As such, its REGISTER (1) 666 looks like: 668 REGISTER sip:example.com SIP/2.0 669 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bKnashds7 670 Max-Forwards: 70 671 From: Callee ;tag=a73kszlfl 672 Supported: gruu 673 To: Callee 674 Call-ID: 1j9FpLxk3uxtm8tn@client.example.com 675 CSeq: 1 REGISTER 676 Contact: ;+sip.instance="" 677 Content-Length: 0 678 The REGISTER response would look like: 680 SIP/2.0 200 OK 681 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bKnashds7 682 From: Callee ;tag=a73kszlfl 683 To: Callee ;tag=b88sn 684 Call-ID: 1j9FpLxk3uxtm8tn@client.example.com 685 CSeq: 1 REGISTER 686 Contact: 687 ;gruu="sip:hha9s8d=-999a@example.com" 688 ;+sip.instance="" 689 Content-Length: 0 691 Note how the Contact header field in the REGISTER response contains 692 the gruu parameter with the URI sip:hha9s8d=-999a@example.com. This 693 represents a GRUU that translates to the Contact URI 694 sip:callee@client.example.com. 696 The INVITE from the caller is a normal SIP INVITE. The 200 OK 697 generated by the callee, however, now contains a GRUU in the Contact 698 header field. The UA has also chosen to include a grid URI parameter 699 into the GRUU. 701 SIP/2.0 200 OK 702 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8 703 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a 704 From: Caller ;tag=n88ah 705 To: Callee ;tag=a0z8 706 Call-ID: 1j9FpLxk3uxtma7@host.example.com 707 CSeq: 1 INVITE 708 Supported: gruu 709 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 710 Contact: 711 Content-Length: -- 712 Content-Type: application/sdp 714 [SDP Not shown] 716 At some point later in the call, the caller decides to subscribe to 717 the dialog event package [11] at that specific UA. To do that, it 718 generates a SUBSCRIBE request (message 9), but directs it towards the 719 GRUU contained in the Contact header field. 721 SUBSCRIBE sip:hha9s8d=-999a@example.com;grid=99a SIP/2.0 722 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 723 From: Caller ;tag=kkaz- 724 To: Callee 725 Call-ID: faif9a@host.example.com 726 CSeq: 2 SUBSCRIBE 727 Supported: gruu 728 Event: dialog 729 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 730 Contact: 731 Content-Length: 0 733 In this example, the caller itself supports the GRUU extension, and 734 is using its own GRUU to populate the Contact header field of the 735 SUBSCRIBE. 737 This request is routed to the proxy, which proceeds to perform a 738 location lookup on the request URI. It is translated into the Contact 739 URI of that GRUU, and then proxied there (message 10). Note how the 740 grid parameter is maintained. 742 SUBSCRIBE sip:callee@client.example.com;grid=99a SIP/2.0 743 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK9555 744 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 745 From: Caller ;tag=kkaz- 746 To: Callee 747 Call-ID: faif9a@host.example.com 748 CSeq: 2 SUBSCRIBE 749 Supported: gruu 750 Event: dialog 751 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 752 Contact: 753 Content-Length: 0 755 12. Security Considerations 757 Since GRUUs do not reveal information about the identity of the 758 associated address-of-record or Contact URI, they provide routability 759 without identity. However, GRUUs do not provide a complete or 760 reliable solution for privacy. In particular, since the GRUU does not 761 change during the lifetime of a registration, an attacker could 762 correlate two calls as coming from the same source, which in and of 763 itself reveals information about the caller. Furthermore, GRUUs do 764 not address other aspects of privacy, such as the addresses used for 765 media transport. For a discussion of how privacy services are 766 provided in SIP, see RFC 3323 [9]. 768 It is important for a UA to be assured of the integrity of a GRUU 769 when it is given one in a REGISTER response. If the GRUU is tampered 770 with by an attacker, the result could be denial of service to the UA. 771 As a result, it is RECOMMENDED that a UA use the SIPS URI scheme when 772 registering. 774 13. IANA Considerations 776 This specification defines a new Contact header field parameter, URI 777 parameter and media feature tag. 779 13.1 Header Field Parameter 781 This specification defines a new header field parameter, as per the 782 registry created by [7]. The required information is as follows: 783 Header field in which the parameter can appear: Contact 784 Name of the Parameter gruu 785 RFC Reference RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 786 RFC number of this specification.]] 788 13.2 URI Parameter 790 This specification defines a new SIP URI parameter, as per the 791 registry created by [8]. 792 Name of the Parameter grid 793 RFC Reference RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 794 RFC number of this specification.]] 796 13.3 Media Feature Tag 798 This section registers a new media feature tag, per the procedures 799 defined in RFC 2506 [5]. The tag is placed into the sip tree, which 800 is defined in [6]. 801 Media feature tag name: sip.instance 802 ASN.1 Identifier: New assignment by IANA. 803 Summary of the media feature indicated by this tag: This feature tag 804 contains a string that indicates a unique identifier associated 805 with the UA instance registering the Contact. This identifier is 806 globally unique, and remains bound to the UA instance for as long 807 as is achievable. For UA instances that are implemented as 808 hardware, such as an IP phone, the instance ID would ideally be 809 burned into firmware when the device is manufactured. For 810 software, the instance ID would generally be randomly created at 811 installation time. 812 Values appropriate for use with this feature tag: String. 814 The feature tag is intended primarily for use in the following 815 applications, protocols, services, or negotiation mechanisms: This 816 feature tag is most useful in a communications application, for 817 describing the capabilities of a device, such as a phone or PDA. 818 Examples of typical use: Routing a call to a specific device. 819 Related standards or documents: RFC XXXX [[Note to IANA: Please 820 replace XXXX with the RFC number of this specification.]] 821 Security Considerations: This media feature tag can be used in ways 822 which affect application behaviors. For example, the SIP caller 823 preferences extension [12] allows for call routing decisions to be 824 based on the values of these parameters. Therefore, if an attacker 825 can modify the values of this tag, they may be able to affect the 826 behavior of applications. As a result of this, applications which 827 utilize this media feature tag SHOULD provide a means for ensuring 828 its integrity. Similarly, this feature tag should only be trusted 829 as valid when it comes from the user or user agent described by 830 the tag. As a result, protocols for conveying this feature tag 831 SHOULD provide a mechanism for guaranteeing authenticity. 833 14. Acknowledgements 835 The author would like to thank Rohan Mahy, Paul Kyzivat, Alan 836 Johnston, and Cullen Jennings for their contributions to this work. 838 Normative References 840 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 841 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 842 Session Initiation Protocol", RFC 3261, June 2002. 844 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 845 Levels", BCP 14, RFC 2119, March 1997. 847 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 848 Notification", RFC 3265, June 2002. 850 [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer 851 Method", RFC 3515, April 2003. 853 [5] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag 854 Registration Procedure", BCP 31, RFC 2506, March 1999. 856 [6] Rosenberg, J., "Indicating User Agent Capabilities in the 857 Session Initiation Protocol (SIP)", 858 draft-ietf-sip-callee-caps-03 (work in progress), January 2004. 860 [7] Camarillo, G., "The Internet Assigned Number Authority Header 861 Field Parameter Registry for the Session Initiation Protocol", 862 draft-ietf-sip-parameter-registry-01 (work in progress), 863 November 2003. 865 [8] Camarillo, G., "The Internet Assigned Number Authority Universal 866 Resource Identifier Parameter Registry for the Session 867 Initiation Protocol", draft-ietf-sip-uri-parameter-reg-01 (work 868 in progress), November 2003. 870 Informative References 872 [9] Peterson, J., "A Privacy Mechanism for the Session Initiation 873 Protocol (SIP)", RFC 3323, November 2002. 875 [10] Rosenberg, J., "A Framework for Conferencing with the Session 876 Initiation Protocol", 877 draft-ietf-sipping-conferencing-framework-01 (work in 878 progress), October 2003. 880 [11] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog 881 Event Package for the Session Initiation Protocol (SIP)", 882 draft-ietf-sipping-dialog-package-03 (work in progress), 883 October 2003. 885 [12] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller 886 Preferences for the Session Initiation Protocol (SIP)", 887 draft-ietf-sip-callerprefs-10 (work in progress), October 2003. 889 [13] Sugano, H. and S. Fujimoto, "Presence Information Data Format 890 (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 891 2003. 893 [14] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 894 Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in 895 progress), February 2003. 897 [15] Rosenberg, J., "A Presence Event Package for the Session 898 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 899 in progress), January 2003. 901 Author's Address 903 Jonathan Rosenberg 904 dynamicsoft 905 600 Lanidex Plaza 906 Parsippany, NJ 07054 907 US 909 Phone: +1 973 952-5000 910 EMail: jdrosen@dynamicsoft.com 911 URI: http://www.jdrosen.net 913 Intellectual Property Statement 915 The IETF takes no position regarding the validity or scope of any 916 intellectual property or other rights that might be claimed to 917 pertain to the implementation or use of the technology described in 918 this document or the extent to which any license under such rights 919 might or might not be available; neither does it represent that it 920 has made any effort to identify any such rights. Information on the 921 IETF's procedures with respect to rights in standards-track and 922 standards-related documentation can be found in BCP-11. Copies of 923 claims of rights made available for publication and any assurances of 924 licenses to be made available, or the result of an attempt made to 925 obtain a general license or permission for the use of such 926 proprietary rights by implementors or users of this specification can 927 be obtained from the IETF Secretariat. 929 The IETF invites any interested party to bring to its attention any 930 copyrights, patents or patent applications, or other proprietary 931 rights which may cover technology that may be required to practice 932 this standard. Please address the information to the IETF Executive 933 Director. 935 Full Copyright Statement 937 Copyright (C) The Internet Society (2004). All Rights Reserved. 939 This document and translations of it may be copied and furnished to 940 others, and derivative works that comment on or otherwise explain it 941 or assist in its implementation may be prepared, copied, published 942 and distributed, in whole or in part, without restriction of any 943 kind, provided that the above copyright notice and this paragraph are 944 included on all such copies and derivative works. However, this 945 document itself may not be modified in any way, such as by removing 946 the copyright notice or references to the Internet Society or other 947 Internet organizations, except as needed for the purpose of 948 developing Internet standards in which case the procedures for 949 copyrights defined in the Internet Standards process must be 950 followed, or as required to translate it into languages other than 951 English. 953 The limited permissions granted above are perpetual and will not be 954 revoked by the Internet Society or its successors or assignees. 956 This document and the information contained herein is provided on an 957 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 958 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 959 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 960 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 961 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 963 Acknowledgment 965 Funding for the RFC Editor function is currently provided by the 966 Internet Society.