idnits 2.17.1 draft-ietf-sip-gruu-00.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 2 instances of too long lines in the document, the longest one being 8 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 82 has weird spacing: '...rencing frame...' == Line 737 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 (January 6, 2004) is 7413 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 (-03) exists of draft-ietf-sip-callee-caps-02 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-01 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIP J. Rosenberg 2 Internet-Draft dynamicsoft 3 Expires: July 6, 2004 January 6, 2004 5 Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in 6 the Session Initiation Protocol (SIP) 7 draft-ietf-sip-gruu-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on July 6, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 Several applications of the Session Initiation Protocol (SIP) require 38 a user agent (UA) to construct and distribute a URI which can be used 39 by anyone on the Internet to route a call to that specific UA 40 instance. A URI which routes to a specific UA instance is called a 41 Globally Routable UA URI (GRUU). This document describes an extension 42 to SIP for obtaining a GRUU from a server, and for communicating a 43 GRUU to a peer within a dialog. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Defining a GRUU . . . . . . . . . . . . . . . . . . . . . . 3 50 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 4.1 REFER . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 4.2 Conferencing . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4.3 Presence . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Overview of Operation . . . . . . . . . . . . . . . . . . . 5 55 6. User Agent Behavior . . . . . . . . . . . . . . . . . . . . 6 56 6.1 REGISTER Processing . . . . . . . . . . . . . . . . . . . . 6 57 6.2 Using the GRUU . . . . . . . . . . . . . . . . . . . . . . . 7 58 7. Registrar Behavior . . . . . . . . . . . . . . . . . . . . . 8 59 7.1 Creation and Maintenance of GRUUs . . . . . . . . . . . . . 8 60 7.2 Providing GRUUs to User Agents . . . . . . . . . . . . . . . 9 61 8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 10 62 9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 10. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11 64 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 12. Security Considerations . . . . . . . . . . . . . . . . . . 15 66 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 67 13.1 Header Field Parameter . . . . . . . . . . . . . . . . . . . 16 68 13.2 URI Parameter . . . . . . . . . . . . . . . . . . . . . . . 16 69 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 70 Normative References . . . . . . . . . . . . . . . . . . . . 16 71 Informative References . . . . . . . . . . . . . . . . . . . 17 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18 73 Intellectual Property and Copyright Statements . . . . . . . 19 75 1. Introduction 77 Several applications of the Session Initiation Protocol (SIP) [1] 78 require a user agent (UA) to construct and distribute a URI which can 79 be used by anyone on the Internet to route a call to that specific UA 80 instance. An example of such an application is call transfer, based 81 on the REFER method [4]. Another application is the usage of 82 endpoint-hosted conferences within the conferencing framework [8]. 83 We call these URIs Globally Routable UA URIs (GRUU). This 84 specification provides a mechanism for obtaining and using GRUUs. 86 2. Terminology 88 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 89 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 90 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and 91 indicate requirement levels for compliant implementations. 93 3. Defining a GRUU 95 A GRUU is a SIP URI which has a specific set of characteristics: 97 Global: It can be used by any UAC connected to the Internet. In 98 that regard, it is like an address-of-record (AOR) for a user. The 99 address-of-record for a user, sip:joe@example.com, is meant to be 100 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 may or may not be valid once 113 more. Furthermore, it will frequently be the case that the GRUU 114 has a lifetime shorter than the duration of the registration. 116 Instance Routing: It routes to a specific UA instance, and never 117 forks. In that regard, it is unlike an address-of-record. When a 118 call is made to a normal AOR which represents a user, routing 119 logic is applied in proxies to deliver the call to one or more 120 UAs. That logic can result in a different routing decision based 121 on the time-of-day, or the identity of the caller. However, when a 122 call is made to a GRUU, the routing logic is much more static. It 123 has to cause the call to be delivered to a very specific UA 124 instance. That UA instance has to be the same UA instance 125 throughout the lifetime of the GRUU. This does not mean that a 126 GRUU represents a fundamentally different type of URI; it only 127 means that the logic a proxy applies to a GRUU is going to 128 generally be simpler than that it applies to a normal AOR. 130 4. Use Cases 132 We have encountered several use cases for a GRUU. 134 4.1 REFER 136 Consider a blind transfer application [12]. User A is talking to user 137 B. A wants to transfer the call to user C. So, it sends a REFER to 138 user C. That REFER looks like, in part: 140 REFER sip:C@example.com SIP/2.0 141 From: sip:A@example.com;tag=99asd 142 To: sip:C@example.com 143 Refer-To: (URI that identifiers B's UA) 145 The Refer-To header needs to contain a URI that can be used by C to 146 place a call to B. However, this call needs to route to the specific 147 UA which B is using to talk to A. If it didn't, the transfer service 148 would not execute. This URI is provided to A by B. Because B doesn't 149 know who A will transfer the call to, the URI has to be usable by 150 anyone. Therefore, it is a GRUU. 152 4.2 Conferencing 154 A similar need arises in conferencing [8]. In that framework, a 155 conference is described by a URI which identifies the focus of the 156 conference. The focus is a SIP UA at the center of a conference. Each 157 conference participant has a dialog with the focus. One case 158 described in the framework is where a user A has made a call to B. 159 They then put B on hold, and call C. Now, A has two separate dialogs 160 for two separate calls - one to B, and one to C. A would like to 161 conference them. One model is that A morphs itself into a focus. It 162 sends a re-INVITE on each existing dialog, and provides both B and C 163 with an updated URI that now holds the conference URI. It also has a 164 callee capabilities [10] parameter which indicates that this URI is a 165 conference URI. A proceeds to mix the media streams from B and C. 166 This is called an ad-hoc conference. 168 At this point, normal conferencing features can be applied. That 169 means that B can send another user, D, the conference URI, perhaps in 170 an email. D can send an INVITE to that URI, and join the conference. 171 For this to work, the conference URI used by A in its re-INVITE has 172 to be usable by anyone, and it has to route to the specific UA 173 instance of A that is acting as the focus. If it didn't, basic 174 conferencing features would fail. Therefore, it is a GRUU. 176 4.3 Presence 178 In a SIP-based presence [13] system, the presence agent (PA) 179 generates notifications about the state of a user. This state is 180 represented with the Presence Information Document Format (PIDF) 181 [11]. In a PIDF document, a user is represented by a series of 182 tuples, each of which identifies the devices that the user has and 183 provides information about them. Each tuple also has a contact URI, 184 which is a SIP URI representing that device. A watcher can make a 185 call to that URI, with the expectation that the call is routed to the 186 device whose presence is represented in the tuple. 188 The URI in the presence document therefore has to route to the 189 specific UA instance whose presence was reported. Furthermore, since 190 the presence document could be used by anyone who subscribes to the 191 user, the URI has to be usable by anyone. As a result, it is a GRUU. 193 It is interesting to note that, in this case, the GRUU needs to be 194 constructed by a presence agent. This may be a server in the network, 195 or may be on an end-device, such as a PC. 197 5. Overview of Operation 199 This section is tutorial in nature, and does not specify any 200 normative behavior. 202 This extension allows a UA to obtain a GRUU, and to use a GRUU. These 203 two mechanisms are separate, in that a UA can obtain a GRUU in any 204 way it likes, and use the mechanisms in this specification to use 205 them. Similarly, a UA can obtain a GRUU but never use it. 207 A UA can obtain a GRUU by generating a normal REGISTER request, as 208 specified in RFC 3261 [1]. This request contains a Supported header 209 field with the value "gruu", indicating to the registrar that the UA 210 supports this extension. If the domain that the user is registering 211 against also supports GRUU, the REGISTER responses will contain the 212 "gruu" parameter in each Contact header field. This parameter 213 contains a GRUU which the domain guarantees will route to that 214 specific Contact URI. That GRUU is guaranteed to remain valid for the 215 duration of the registration. 217 Since the GRUU is a URI like any other, it can be handed out by a UA 218 by placing it in any header field which can contain a GRUU. A UA will 219 normally place the GRUU into the Contact header field of dialog 220 creating requests and responses it generates. However, it is 221 important for the UA receiving the message to know whether the 222 Contact URI is a GRUU or not. To make this determination, the UA 223 looks for the presence of the Supported header field in the request 224 or response. If it is present with a value of "gruu", it means that 225 the Contact URI is a GRUU. 227 When a UA uses a GRUU, it has the option of adding the "grid" URI 228 parameter to the GRUU. This parameter is opaque to the proxy server 229 handling the domain. However, when the server maps the GRUU to the 230 corresponding Contact URI, the server will copy the grid parameter 231 into the Contact URI. As a result, when the UA receives the request, 232 the Request URI will contain the grid parameter it placed in the 233 corresponding GRUU. 235 6. User Agent Behavior 237 User agent behavior is divided into two separate parts - REGISTER 238 processing, and GRUU usage. 240 6.1 REGISTER Processing 242 When a UA wishes to obtain a GRUU within the domain of its AOR, when 243 it generates a REGISTER request (initial or refresh), it MUST include 244 the Supported header field in the request. The value of that header 245 field MUST include "gruu" as one of the option tags. This alerts the 246 registrar for the domain that the UA supports the GRUU mechanism. 247 Besides the presence of this option tag in the Supported header 248 field, the REGISTER request is constructed identically to the case 249 where this extension was not understood. Specifically, the Contact 250 URI in the REGISTER request SHOULD NOT contain the gruu Contact 251 header field parameter. Any such parameters are ignored by the 252 registrar, as the UA cannot propose a GRUU for usage with the Contact 253 URI. 255 If a UA wishes to guarantee that the request is not processed unless 256 the domain supports and uses this extension, it MAY include a Require 257 header field in the request with a value that contains the "gruu" 258 option tag. 260 If the response is a 2xx, each Contact header field may contain a 261 "gruu" parameter. This parameter contains a SIP URI that represents a 262 GRUU corresponding to that Contact URI. Any requests sent to the GRUU 263 URI will be routed by the domain to the Contact URI. The GRUU will 264 not change in subsequent 2xx responses to REGISTER as long as the UA 265 does not let the registration expire. However, if the UA waits until 266 the last moment to refresh its registration, it may cause a race 267 condition where the registration expires while the registration is in 268 transit. The resulting 200 OK might then contain a different GRUU. 269 Since "last moment" is ill defined, it is RECOMMENDED that a UA be 270 prepared to handle a change in the GRUU during a registration. 271 Handling a change depends on the way in which it has been used. In 272 the case where it is included in the Contact URI of a dialog 273 initiating request or response, the UA would update the Contact URI 274 with a target refresh request. 276 6.2 Using the GRUU 278 A UA first obtains a GRUU using the procedures of Section 6.1. 280 A UA can use the GRUU in the same way it would use any other SIP URI. 281 However, a UA compliant to this specification MUST use a GRUU when 282 populating the Contact header field of dialog-creating requests and 283 responses. This includes the INVITE request and its 2xx response, the 284 SUBSCRIBE [3] request, its 2xx response, and the NOTIFY request, and 285 the REFER [4] request and its 2xx response. Similarly, in those 286 requests and responses where the GRUU is used in the Contact header 287 field, the UA MUST include a Supported header field that contains the 288 option tag "gruu". However, it is not necessary for a UA to know 289 whether or not its peer in the dialog uses a GRUU before inserting 290 one into the Contact header field. 292 When placing a GRUU into the Contact header field of a request or 293 response, a UA MAY add the "grid" URI parameter to the GRUU. This 294 parameter MAY take on any value permitted by the grammar for the 295 parameter. Note that there are no limitations on the size of this 296 parameter. When a UA sends a request to the GRUU, the proxy for the 297 domain that owns the GRUU will translate the GRUU in the Request-URI, 298 replacing it with the corresponding Contact URI. However, it will 299 retain the "grid" parameter when this translation is performed. As a 300 result, when the UA receives the request, the Request-URI will 301 contain the "grid" created by the UA. This allows the UA to 302 effectively manufacture an infinite supply of GRUU, each of which 303 differs by the value of the "grid" parameter. When a UA receives a 304 request that was sent to the GRUU, it will be able to tell which GRUU 305 was invoked by the "grid" parameter. 307 An implication of this behavior is that all mid-dialog requests will 308 be routed through intermediate proxies. There will never be direct, 309 UA to UA signaling. It is anticipated that this limitation will be 310 addressed in future specifications. 312 Once a UA knows that the Contact URI provided by its peer is a GRUU, 313 it can use it in any application or SIP extension which requires a 314 globally routable URI to operate. One such example is assisted call 315 transfer. 317 7. Registrar Behavior 319 A registrar compliant to this specification is responsible for the 320 creation and maintenance of GRUUs, and for providing those GRUU's to 321 a UA in response to a REGISTER request. 323 7.1 Creation and Maintenance of GRUUs 325 There is a one-to-one mapping between a Contact URI for a particular 326 AOR, and a GRUU. As a result, if two Contact/AOR pairs are different, 327 the GRUU for each MUST be different. If two GRUUs are different, the 328 Contact/AOR pair for those MUST be different. It is important to 329 understand that this uniqueness is over the Contact/AOR pair, not 330 just the Contact. For example, if a user registered the Contact 331 sip:ua@pc.example.com to the AOR sip:user@example.com, and also 332 registered the same Contact - sip:ua@pc.example.com to a second AOR, 333 say sip:boss@example.com, each of those Contacts would have a 334 different GRUU, since they belong to different AORs. 336 A registrar MAY create a GRUU for a particular AOR/Contact pair at 337 any time. Of course, if a UA requests a GRUU in a registration, and 338 the registrar has not yet created one, it will need to do so in order 339 to respond to the registration request. However, the registrar can 340 create the GRUU in advance of any request from a UA. 342 This specification does not mandate a particular mechanism for 343 construction of the GRUU. However, the GRUU MUST exhibit the 344 following properties: 346 o The domain part of the URI is an IP address present on the public 347 Internet, or, if it is a host name, exists in the global DNS and 348 corresponds to an IP address present on the public Internet. 350 o When a request is sent to this URI, it routes to a proxy server in 351 the same domain as that of the registrar. 353 o A proxy server in the domain can determine that the URI is a GRUU. 355 o When a proxy server in this domain translates this URI, the result 356 is equal to the Contact URI corresponding to the GRUU. 358 o It MUST NOT be possible, based on inspection of the URI, to 359 determine the associated Contact URI or Address of Record. 361 With these rules, it is possible, though not required, to construct a 362 GRUU without requiring the maintenance of any additional state. To do 363 that, the URI would be constructed in the following fashion: 365 user-part = "GRUU" + BASE64(E(K, (salt + Contact URI + AOR))) 367 Where E(K,X) represents a suitable encryption function (such as AES 368 with 128 bit keys) with key K applied to data block X, and the "+" 369 operator implies concatenation. Salt represents a random string that 370 prevents a client from obtaining pairs of known plaintext and 371 ciphertext. A good choice would be at least 128 bits of randomness in 372 the salt. 374 The benefit of this mechanism is that a server need not store 375 additional information on mapping a GRUU to its corresponding Contact 376 URI. The user part of the GRUU can itself contain the Contact URI. 377 Encryption is needed to prevent attacks whereby the server is sent 378 requests with faked GRUU, causing the server to direct requests to 379 any named URI. Even with encryption, the proxy should validate the 380 user part after decryption. In particular, the AOR should be one 381 managed by the proxy in that domain. Should a UA send a request with 382 a fake GRUU, the proxy would decrypt and then discard it because 383 there would be no URI or an invalid URI inside. 385 Once created, the registrar MUST maintain that GRUU for the duration 386 over which that Contact remains registered to that AOR at the 387 registrar. Furthermore, the registrar MUST NOT change the gruu during 388 that duration. This is true even if the Contact is refreshed from a 389 rebooted or different UA (known by a change in the Call-ID of the 390 REGISTER request). After the Contact expires, the registrar ceases to 391 maintain the binding. The registrar is under no obligation to use the 392 same GRUU should that Contact be re-registered at a later time. Of 393 course, it MAY create the same GRUU if it likes, but this would be an 394 implementation choice. 396 The implication of these rules is that a registrar is responsible for 397 reliable storage of the GRUU for the duration of a registration. 399 7.2 Providing GRUUs to User Agents 401 When a registrar compliant to this specification receives a REGISTER 402 request, it checks for the presence of the Require header field in 403 the request. If present, and if it contains the "gruu" option tag, 404 the registrar MUST follow the procedures in the next paragraph for 405 inclusion of the "gruu" parameter in a 2xx response to REGISTER. If 406 not present, but a Supported header field was present with the "gruu" 407 option tag, the registrar SHOULD follow the procedures in the next 408 paragraph for inclusion of the "gruu" parameter in a 2xx response to 409 REGISTER. If the Supported header field was not present, or it if was 410 present but did not contain the value "gruu", the registrar SHOULD 411 NOT follow the procedures of the next paragraph for inclusion of the 412 "gruu" parameter in a 2xx response to REGISTER. 414 If the register request contained any "gruu" Contact header field 415 parameters, these MUST be ignored by the registrar. A UA cannot 416 suggest or otherwise provide a GRUU to the registrar. 418 A GRUU is provided to a UA by including it in the "gruu" Contact 419 header field parameter for a particular Contact URI. The value of 420 this parameter is a quoted string containing the URI that is the GRUU 421 for the associated Contact URI/AOR pair. If the server does not 422 currently have a GRUU associated with the Contact URI, either because 423 the Contact URI is being newly registered, or because it is being 424 refreshed, but the registrar has not yet computed a GRUU for that 425 Contact, one is created according to the procedures of Section 7.1. 426 Otherwise, if a GRUU already exists for that AOR/Contact pair, the 427 GRUU associated with that pair MUST be placed into the "gruu" Contact 428 header field parameter of the REGISTER response. 430 Inclusion of a GRUU in the "gruu" Contact header field parameter of a 431 REGISTER response is separate from the computation and storage of the 432 GRUU. It is possible that the registrar has computed a GRUU for a 433 contact at the request of one UA, but a different UA that queries for 434 the current set of registrations doesn't understand GRUU. In that 435 case, the REGISTER response sent to that second UA would not contain 436 the "gruu" Contact header field parameter, even though the UA has a 437 GRUU for that Contact. 439 8. Proxy Behavior 441 When a proxy server receives a request, and the proxy owns the domain 442 in the Request URI, and the proxy is supposed to access a Location 443 Service in order to compute request targets (as specified in Section 444 16.5 of RFC 3261 [1]), the proxy MUST check if the Request URI is a 445 GRUU created by that domain. 447 If the URI is a GRUU, the proxy MUST determine if the Contact URI 448 associated with the GRUU is still registered to the AOR it was 449 registered to when the GRUU was constructed. If that AOR no longer 450 has any registered contacts, or if it does have registered contacts, 451 but none of them equal the Contact URI associated with the GRUU, the 452 proxy MUST generate a 404 (Not Found) response to the request. 454 Otherwise, the proxy MUST populate the target set with a single URI. 455 This URI MUST be equal to the Contact URI associated with that GRUU. 456 Furthermore, if the GRUU contained a "grid" URI parameter, the URI in 457 the target set MUST also contain the same parameter with the same 458 value. 460 A proxy MAY apply other processing to the request, such as execution 461 of called party features. In particular, it is RECOMMENDED that 462 non-routing called party features, such as call logging and 463 screening, that are associated with the AOR are also applied to 464 requests for the GRUU. 466 In many cases, a proxy will record-route an initial INVITE request, 467 and the user agents will insert a GRUU into the Contact header field. 468 When this happens, a mid-dialog request will arrive at the proxy with 469 a Route header field that was inserted by the proxy, and a 470 Request-URI that represents a GRUU. Proxies follow normal processing 471 in this case; they will strip the Route header field, and then 472 process the Request URI as described above. 474 The procedures of RFC 3261 are then followed to proxy the request. 475 The request SHOULD NOT be redirected in this case. In many instances, 476 a GRUU is used by a UA in order to assist in the traversal of NATs, 477 and a redirection may prevent such a case from working. 479 9. Grammar 481 This specification defines a new Contact header field parameter, 482 gruu, and a new URI parameter, grid. 484 contact-params = c-p-q / c-p-expires / c-p-gruu 485 / contact-extension 486 c-p-gruu = "gruu" EQUAL SWS DQUOTE SIP-URI DQUOTE 487 uri-parameter = transport-param / user-param / method-param 488 / ttl-param / maddr-param / lr-param / grid-param 489 / other-param 490 grid-param = "grid=" pvalue 492 10. Requirements 494 This specification was created in order to meet the following 495 requirements: 497 REQ 1: When a UA invokes a GRUU, it MUST cause the request to be 498 routed to the specific UA instance to which the GRUU refers. 500 REQ 2: It MUST be possible for a GRUU to be invoked from anywhere on 501 the Internet, and still cause the request to be routed 502 appropriately. That is, a GRUU MUST NOT be restricted to use 503 within a specific addressing realm. 505 REQ 3: It MUST be possible for a GRUU to be constructed without 506 requiring the network to store additional state. 508 REQ 4: It MUST be possible for a UA to obtain a multiplicity of 509 GRUUs, each one of which routes to that UA instance. This is 510 needed to support ad-hoc conferencing, for example, where a a UA 511 instance needs a different URI for each conference it is hosting. 513 REQ 5: When a UA receives a request sent to a GRUU, it MUST be 514 possible for the UA to know the GRUU which was used to invoke the 515 request. This is necessary as a consequence of requirement 4. 517 REQ 6: It MUST be possible for a UA to add opaque content to a GRUU, 518 which is not interpreted or altered by the network, and used only 519 by the UA instance to whom the GRUU refers. This provides a basic 520 cookie type of functionality, allowing a UA to build a GRUU with 521 state embedded within it. 523 REQ 7: It MUST be possible for a proxy to execute services and 524 features on behalf of a UA instace represented by a GRUU. As an 525 example, if a user has call blocking features, a proxy may want to 526 apply those call blocking features to calls made to the GRUU in 527 addition to calls made to the user's AOR. 529 REQ 8: It MUST be possible for a UA in a dialog to inform its peer of 530 its GRUU, and for the peer to know that the URI represents a GRUU. 531 This is needed for the conferencing and dialog reuse applications 532 of GRUUs, where the URIs are transferred within a dialog. 534 REQ 9: When transferring a GRUU per requirement 8, it MUST be 535 possible for the UA receiving the GRUU to be assured of its 536 integrity and authenticity. 538 REQ 10: It MUST be possible for a server, authoritative for a domain, 539 to construct a GRUU which routes to a UA instace bound to an AOR 540 in that domain. In other words, the proxy can construct a GRUU 541 too. This is needed for the presence application. 543 11. Examples 545 The following call flow shows a basic registration and call setup, 546 followed by a subscription directed to the GRUU. 548 Caller Proxy Callee 549 | |(1) REGISTER | 550 | |<--------------------| 551 | |(2) 200 OK | 552 | |-------------------->| 553 |(3) INVITE | | 554 |-------------------->| | 555 | |(4) INVITE | 556 | |-------------------->| 557 | |(5) 200 OK | 558 | |<--------------------| 559 |(6) 200 OK | | 560 |<--------------------| | 561 |(7) ACK | | 562 |-------------------->| | 563 | |(8) ACK | 564 | |-------------------->| 565 |(9) SUBSCRIBE | | 566 |-------------------->| | 567 | |(10) SUBSCRIBE | 568 | |-------------------->| 569 | |(11) 200 OK | 570 | |<--------------------| 571 |(12) 200 OK | | 572 |<--------------------| | 573 | |(13) NOTIFY | 574 | |<--------------------| 575 |(14) NOTIFY | | 576 |<--------------------| | 577 |(15) 200 OK | | 578 |-------------------->| | 579 | |(16) 200 OK | 580 | |-------------------->| 582 The Callee supports the GRUU extension. As such, its REGISTER (1) 583 looks like: 585 REGISTER sip:example.com SIP/2.0 586 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bKnashds7 587 Max-Forwards: 70 588 From: Callee ;tag=a73kszlfl 589 Supported: gruu 590 To: Callee 591 Call-ID: 1j9FpLxk3uxtm8tn@client.example.com 592 CSeq: 1 REGISTER 593 Contact: 594 Content-Length: 0 595 The REGISTER response would look like: 597 SIP/2.0 200 OK 598 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bKnashds7 599 From: Callee ;tag=a73kszlfl 600 To: Callee ;tag=b88sn 601 Call-ID: 1j9FpLxk3uxtm8tn@client.example.com 602 CSeq: 1 REGISTER 603 Contact: ;gruu="sip:hha9s8d=-999a@example.com" 604 Content-Length: 0 606 Note how the Contact header field in the REGISTER response contains 607 the gruu parameter with the URI sip:hha9s8d=-999a@example.com. This 608 represents a GRUU associated with the Contact URI 609 sip:callee@client.example.com. 611 The INVITE from the caller is a normal SIP INVITE. The 200 OK 612 generated by the callee, however, now contains a GRUU in the Contact 613 header field. The UA has also chosen to include a grid URI parameter 614 into the GRUU. 616 SIP/2.0 200 OK 617 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8 618 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a 619 From: Caller ;tag=n88ah 620 To: Callee ;tag=a0z8 621 Call-ID: 1j9FpLxk3uxtma7@host.example.com 622 CSeq: 1 INVITE 623 Supported: gruu 624 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 625 Contact: 626 Content-Length: -- 627 Content-Type: application/sdp 629 [SDP Not shown] 631 At some point later in the call, the caller decides to subscribe to 632 the dialog event package [9] at that specific UA. To do that, it 633 generates a SUBSCRIBE request (message 9), but directs it towards the 634 GRUU contained in the Contact header field. 636 SUBSCRIBE sip:hha9s8d=-999a@example.com;grid=99a SIP/2.0 637 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 638 From: Caller ;tag=kkaz- 639 To: Callee 640 Call-ID: faif9a@host.example.com 641 CSeq: 2 SUBSCRIBE 642 Supported: gruu 643 Event: dialog 644 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 645 Contact: 646 Content-Length: 0 648 In this example, the caller itself supports the GRUU extension, and 649 is using its own GRUU to populate the Contact header field of the 650 SUBSCRIBE. 652 This request is routed to the proxy, which proceeds to perform a 653 location lookup on the request URI. It is translated into the Contact 654 URI bound to that GRUU, and then proxied there (message 10). Note how 655 the grid parameter is maintained. 657 SUBSCRIBE sip:callee@client.example.com;grid=99a SIP/2.0 658 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK9555 659 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 660 From: Caller ;tag=kkaz- 661 To: Callee 662 Call-ID: faif9a@host.example.com 663 CSeq: 2 SUBSCRIBE 664 Supported: gruu 665 Event: dialog 666 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 667 Contact: 668 Content-Length: 0 670 12. Security Considerations 672 Since GRUUs do not reveal information about the identity of the 673 associated address-of-record or Contact URI, they provide routability 674 without identity. However, GRUUs do not provide a complete or 675 reliable solution for privacy. In particular, since the GRUU does not 676 change during the lifetime of a registration, an attacker could 677 correlate two calls as coming from the same source, which in and of 678 itself reveals information about the caller. Furthermore, GRUUs do 679 not address other aspects of privacy, such as the addresses used for 680 media transport. For a discussion of how privacy services are 681 provided in SIP, see RFC 3323 [7]. 683 It is important for a UA to be assured of the integrity of a GRUU 684 when it is given one in a REGISTER response. If the GRUU is tampered 685 with by an attacker, the result could be denial of service to the UA. 686 As a result, it is RECOMMENDED that a UA use the SIPS URI scheme when 687 registering. 689 13. IANA Considerations 691 This specification defines a new Contact header field parameter and 692 URI parameter. 694 13.1 Header Field Parameter 696 This specification defines a new header field parameter, as per the 697 registry created by [5]. The required information is as follows: 699 Header field in which the parameter can appear: Contact 701 Name of the Parameter gruu 703 RFC Reference RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 704 RFC number of this specification.]] 706 13.2 URI Parameter 708 This specification defines a new SIP URI parameter, as per the 709 registry created by [6]. 711 Name of the Parameter grid 713 RFC Reference RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 714 RFC number of this specification.]] 716 14. Acknowledgements 718 The author would like to thank Rohan Mahy, Paul Kyzivat, Alan 719 Johnston, and Cullen Jennings for their contributions to this work. 721 Normative References 723 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 724 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 725 Session Initiation Protocol", RFC 3261, June 2002. 727 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 728 Levels", BCP 14, RFC 2119, March 1997. 730 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 731 Notification", RFC 3265, June 2002. 733 [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer 734 Method", RFC 3515, April 2003. 736 [5] Camarillo, G., "The Internet Assigned Number Authority Header 737 Field Parameter Registry for the Session Initiation Protocol", 738 draft-ietf-sip-parameter-registry-01 (work in progress), 739 November 2003. 741 [6] Camarillo, G., "The Internet Assigned Number Authority Universal 742 Resource Identifier Parameter Registry for the Session 743 Initiation Protocol", draft-ietf-sip-uri-parameter-reg-01 (work 744 in progress), November 2003. 746 Informative References 748 [7] Peterson, J., "A Privacy Mechanism for the Session Initiation 749 Protocol (SIP)", RFC 3323, November 2002. 751 [8] Rosenberg, J., "A Framework for Conferencing with the Session 752 Initiation Protocol", 753 draft-ietf-sipping-conferencing-framework-01 (work in 754 progress), October 2003. 756 [9] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog 757 Event Package for the Session Initiation Protocol (SIP)", 758 draft-ietf-sipping-dialog-package-03 (work in progress), 759 October 2003. 761 [10] Rosenberg, J., "Indicating User Agent Capabilities in the 762 Session Initiation Protocol (SIP)", 763 draft-ietf-sip-callee-caps-02 (work in progress), December 764 2003. 766 [11] Sugano, H. and S. Fujimoto, "Presence Information Data Format 767 (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 768 2003. 770 [12] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 771 Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in 772 progress), February 2003. 774 [13] Rosenberg, J., "A Presence Event Package for the Session 775 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 776 in progress), January 2003. 778 Author's Address 780 Jonathan Rosenberg 781 dynamicsoft 782 600 Lanidex Plaza 783 Parsippany, NJ 07054 784 US 786 Phone: +1 973 952-5000 787 EMail: jdrosen@dynamicsoft.com 788 URI: http://www.jdrosen.net 790 Intellectual Property Statement 792 The IETF takes no position regarding the validity or scope of any 793 intellectual property or other rights that might be claimed to 794 pertain to the implementation or use of the technology described in 795 this document or the extent to which any license under such rights 796 might or might not be available; neither does it represent that it 797 has made any effort to identify any such rights. Information on the 798 IETF's procedures with respect to rights in standards-track and 799 standards-related documentation can be found in BCP-11. Copies of 800 claims of rights made available for publication and any assurances of 801 licenses to be made available, or the result of an attempt made to 802 obtain a general license or permission for the use of such 803 proprietary rights by implementors or users of this specification can 804 be obtained from the IETF Secretariat. 806 The IETF invites any interested party to bring to its attention any 807 copyrights, patents or patent applications, or other proprietary 808 rights which may cover technology that may be required to practice 809 this standard. Please address the information to the IETF Executive 810 Director. 812 Full Copyright Statement 814 Copyright (C) The Internet Society (2004). All Rights Reserved. 816 This document and translations of it may be copied and furnished to 817 others, and derivative works that comment on or otherwise explain it 818 or assist in its implementation may be prepared, copied, published 819 and distributed, in whole or in part, without restriction of any 820 kind, provided that the above copyright notice and this paragraph are 821 included on all such copies and derivative works. However, this 822 document itself may not be modified in any way, such as by removing 823 the copyright notice or references to the Internet Society or other 824 Internet organizations, except as needed for the purpose of 825 developing Internet standards in which case the procedures for 826 copyrights defined in the Internet Standards process must be 827 followed, or as required to translate it into languages other than 828 English. 830 The limited permissions granted above are perpetual and will not be 831 revoked by the Internet Society or its successors or assignees. 833 This document and the information contained herein is provided on an 834 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 835 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 836 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 837 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 838 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 840 Acknowledgement 842 Funding for the RFC Editor function is currently provided by the 843 Internet Society.