idnits 2.17.1 draft-ietf-sip-gruu-02.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1324. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1340), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 3 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 97 has weird spacing: '...rencing frame...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2, 2004) is 7238 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. '4') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 2396 (ref. '7') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2141 (ref. '8') (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 3188 (ref. '13') (Obsoleted by RFC 8458) == 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-04 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-02 == Outdated reference: A later version (-05) exists of draft-mealling-uuid-urn-03 Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 9 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: December 31, 2004 July 2, 2004 5 Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in 6 the Session Initiation Protocol (SIP) 7 draft-ietf-sip-gruu-02 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 31, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 Several applications of the Session Initiation Protocol (SIP) require 41 a user agent (UA) to construct and distribute a URI which can be used 42 by anyone on the Internet to route a call to that specific UA 43 instance. A URI which routes to a specific UA instance is called a 44 Globally Routable UA URI (GRUU). This document describes an 45 extension to SIP for obtaining a GRUU from a server, and for 46 communicating a GRUU to a peer within a dialog. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Defining a GRUU . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4.1 REFER . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4.2 Conferencing . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.3 Presence . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 58 6. Creation of a GRUU . . . . . . . . . . . . . . . . . . . . . . 6 59 7. Obtaining a GRUU . . . . . . . . . . . . . . . . . . . . . . . 9 60 7.1 Through Registrations . . . . . . . . . . . . . . . . . . 9 61 7.1.1 User Agent Behavior . . . . . . . . . . . . . . . . . 9 62 7.1.2 Registrar Behavior . . . . . . . . . . . . . . . . . . 11 63 7.2 Administratively . . . . . . . . . . . . . . . . . . . . . 12 64 8. Using the GRUU . . . . . . . . . . . . . . . . . . . . . . . . 13 65 8.1 Sending a Message Containing a GRUU . . . . . . . . . . . 13 66 8.2 Sending a Message to a GRUU . . . . . . . . . . . . . . . 14 67 8.3 Receiving a Request Sent to a GRUU . . . . . . . . . . . . 14 68 8.4 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 15 69 9. 425 (Instance Conflict) Response Code . . . . . . . . . . . . 15 70 10. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 11. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 16 72 12. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 17 73 13. Security Considerations . . . . . . . . . . . . . . . . . . 23 74 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 75 14.1 Header Field Parameter . . . . . . . . . . . . . . . . . . 23 76 14.2 Response Code . . . . . . . . . . . . . . . . . . . . . . 23 77 14.3 URI Parameter . . . . . . . . . . . . . . . . . . . . . . 24 78 14.4 Media Feature Tag . . . . . . . . . . . . . . . . . . . . 24 79 14.5 SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 25 80 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 81 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 82 16.1 Normative References . . . . . . . . . . . . . . . . . . . . 25 83 16.2 Informative References . . . . . . . . . . . . . . . . . . . 26 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 27 85 A. Example GRUU Construction Algorithms . . . . . . . . . . . . . 27 86 A.1 Encrypted Instance ID and AOR . . . . . . . . . . . . . . 27 87 A.2 Hashed Indices . . . . . . . . . . . . . . . . . . . . . . 28 88 Intellectual Property and Copyright Statements . . . . . . . . 29 90 1. Introduction 92 Several applications of the Session Initiation Protocol (SIP) [1] 93 require a user agent (UA) to construct and distribute a URI which can 94 be used by anyone on the Internet to route a call to that specific UA 95 instance. An example of such an application is call transfer [18], 96 based on the REFER method [5]. Another application is the usage of 97 endpoint-hosted conferences within the conferencing framework [14]. 98 We call these URIs Globally Routable UA URIs (GRUU). This 99 specification provides a mechanism for obtaining and using GRUUs. 101 2. Terminology 103 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 104 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 105 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and 106 indicate requirement levels for compliant implementations. 108 3. Defining a GRUU 110 A GRUU is a SIP URI which has two characteristics: 111 Global: It can be used by any UAC connected to the Internet. In that 112 regard, it is like an address-of-record (AOR) for a user. The 113 address-of-record for a user, sip:joe@example.com, is meant to be 114 used by anyone to reach that user. The same is true for a GRUU. 116 Routes to a Single Instance: It routes to a specific UA instance, and 117 never forks. In that regard, it is unlike an address-of-record. 118 When a request is sent to a normal AOR which represents a user, 119 routing logic is applied in proxies to deliver the request to one 120 or more UAs. That logic can result in a different routing 121 decision based on the time-of-day, or the identity of the caller. 122 However, when a request is made to a GRUU, the routing logic is 123 dictated by the properties of a GRUU. The request has to be 124 delivered to a very specific UA instance. That UA instance has to 125 be the same UA instance for all requests sent to that GRUU. This 126 does not mean that a GRUU represents a fundamentally different 127 type of URI; it only means that the logic a proxy applies to a 128 GRUU is going to generally be simpler than that it applies to a 129 normal AOR. 131 4. Use Cases 133 We have encountered several use cases for a GRUU. 135 4.1 REFER 137 Consider a blind transfer application [18]. User A is talking to 138 user B. User A wants to transfer the call to user C. So, user A 139 sends a REFER to user C. That REFER looks like, in part: 141 REFER sip:C@example.com SIP/2.0 142 From: sip:A@example.com;tag=99asd 143 To: sip:C@example.com 144 Refer-To: (URI that identifiers B's UA) 146 The Refer-To header field needs to contain a URI that can be used by 147 user C to place a call to user B. However, this call needs to route 148 to the specific UA instance which user B is using to talk to user A. 149 If it didn't, the transfer service would not execute properly. This 150 URI is provided to user A by user B. Because user B doesn't know who 151 user A will transfer the call to, the URI has to be usable by anyone. 152 Therefore, it is a GRUU. 154 4.2 Conferencing 156 A similar need arises in conferencing [14]. In that framework, a 157 conference is described by a URI which identifies the focus of the 158 conference. The focus is a SIP UA that acts as the signaling hub for 159 the conference. Each conference participant has a dialog with the 160 focus. One case described in the framework is where a user A has 161 made a call to user B. User A puts user B on hold, and calls user C. 162 Now, user A has two separate dialogs for two separate calls - one to 163 user B, and one to user C. User A would like to conference them. To 164 do this, user A's user agent morphs itself into a focus. It sends a 165 re-INVITE or UPDATE [2] on both dialogs, and provides user B and user 166 C with an updated Contact URI that now holds the conference URI. The 167 Contact URI also has a callee capabilities [9] parameter which 168 indicates that this URI is a conference URI. User A proceeds to mix 169 the media streams received from user B and user C. This is called an 170 ad-hoc conference. 172 At this point, normal conferencing features can be applied. That 173 means that user B can send another user, user D, the conference URI, 174 perhaps in an email. User D can send an INVITE to that URI, and join 175 the conference. For this to work, the conference URI used by user A 176 in its re-INVITE or UPDATE has to be usable by anyone, and it has to 177 route to the specific UA instance of user A that is acting as the 178 focus. If it didn't, basic conferencing features would fail. 179 Therefore, this URI is a GRUU. 181 4.3 Presence 183 In a SIP-based presence [19] system, the Presence Agent (PA) 184 generates notifications about the state of a user. This state is 185 represented with the Presence Information Document Format (PIDF) 187 [17]. In a PIDF document, a user is represented by a series of 188 tuples, each of which describes the services that the user has. Each 189 tuple also has a contact URI, which is a SIP URI representing that 190 device. A watcher can make a call to that URI, with the expectation 191 that the call is routed to the service whose presence is represented 192 in the tuple. 194 In some cases, the service represented by a tuple may exist on only a 195 single user agent associated with a user. In such a case, the URI in 196 the presence document has to route to that specific UA instance. 197 Furthermore, since the presence document could be used by anyone who 198 subscribes to the user, the URI has to be usable by anyone. As a 199 result, it is a GRUU. 201 It is interesting to note that the GRUU may need to be constructed by 202 a presence agent, depending on how the presence document is computed 203 by the server. 205 5. Overview of Operation 207 This section is tutorial in nature, and does not specify any 208 normative behavior. 210 This extension allows a UA to obtain a GRUU, and to use a GRUU. 211 These two mechanisms are separate, in that a UA can obtain a GRUU in 212 any way it likes, and use the mechanisms in this specification to use 213 them. Similarly, a UA can obtain a GRUU but never use it. This 214 specification defines two mechanisms for obtaining a GRUU - through 215 registrations, and through administrative operation. Only the former 216 requires protocol operations. 218 A UA can obtain a GRUU by generating a normal REGISTER request, as 219 specified in RFC 3261 [1]. This request contains a Supported header 220 field with the value "gruu", indicating to the registrar that the UA 221 supports this extension. The UA includes a "sip.instance" media 222 feature tag in the Contact header field of each Contact for which a 223 GRUU is desired. This media feature tag contains a globally unique 224 ID that identifies the UA instance. If the domain that the user is 225 registering against also supports GRUU, the REGISTER responses will 226 contain the "gruu" parameter in each Contact header field. This 227 parameter contains a GRUU which the domain guarantees will route to 228 that UA instace. That GRUU is guaranteed to remain valid for the 229 duration of the registration. The GRUU is bound to the UA instace. 230 Should the client change its Contact URI, but indicate that it 231 represents the same instance ID, the server would provide the same 232 GRUU. Furthermore, if the registration for the Contact expires, and 233 the UA registers the Contact at a later time with the same instance 234 identifier, the server would provide the same GRUU. 236 Since the GRUU is a URI like any other, it can be handed out by a UA 237 by placing it in any header field which can contain a URI. A UA will 238 normally place the GRUU into the Contact header field of dialog 239 creating requests and responses it generates. However, it is 240 important for the UA receiving the message to know whether the 241 Contact URI is a GRUU or not. To make this determination, the UA 242 looks for the presence of the Supported header field in the request 243 or response. If it is present with a value of "gruu", it means that 244 the Contact URI is a GRUU. 246 When a UA uses a GRUU, it has the option of adding the "grid" URI 247 parameter to the GRUU. This parameter is opaque to the proxy server 248 handling the domain. However, when the server maps the GRUU to the 249 corresponding Contact URI, the server will copy the grid parameter 250 into the Contact URI. As a result, when the UA receives the request, 251 the Request URI will contain the grid parameter it placed in the 252 corresponding GRUU. 254 6. Creation of a GRUU 256 A GRUU is a URI that is created and maintained by a server 257 authoritative for the domain in which the GRUU resides. 258 Independently of whether the GRUU is created as a result of a 259 registration or some other means, a server MUST maintain certain 260 information associated with the GRUU. This information, and its 261 relationship with the GRUU, are modeled in Figure 2. 263 +-------------+ 264 | | 265 | | 266 | GRUU |----------------------+ 267 | | | 268 | | | 269 +-------------+ | 270 | 0..1 | 271 | | 272 | associated-with | 273 | | 274 | | 275 | 1 | 276 +----------------+ | 277 | | | 278 +--------| instance ID/ |------+ | 279 | | AOR Pair | | | 280 | | | | | 281 | +----------------+ | | 282 | | | 283 | | | 284 | | |translates 285 V V |to 286 +--------------+ +-----------+ | 287 | | | | | 288 | instance | | AOR | | 289 | ID | | | | 290 | | +-----------+ | 291 +--------------+ | | 292 ^ | | 293 | | | 294 | | | 295 | |is-bound-to | 296 | +----------------+ | | 297 | | | | | 298 | | | | | 299 +--------| Contact URI |<-----+ | 300 | | 0..* | 301 | | | 302 +----------------+ | 303 0..1 ^ | 304 | | 305 +-----------------------------+ 307 Figure 2 309 The instance ID plays a key role in this specification. It is an 310 indentifier, represented by a URI, that uniquely identifies a SIP 311 user agent amongst all other user agents with a Contact URI bound to 312 an Address of Record (AOR). The instance ID allows a domain to 313 create a GRUU that maps to the same UA instance, even if the Contact 314 URI of that instance changes. Furthermore, the instance ID allows a 315 domain to enforce the restriction that a specific UA instance can 316 only be registered once against an AOR. When elements compliant to 317 this specification compare two instance IDs for equality, the 318 comparison is done using the equality rules for the scheme associated 319 with that URI. 321 A GRUU is associated, in a one-to-one fashion, with the combination 322 of an Address of Record (AOR) and instance ID. The GRUU is said to 323 be associated with the combination, and the combination is associated 324 with the GRUU. This combination is referred to as an instance ID/AOR 325 pair. The instance ID/AOR pair serve to uniquely identify a user 326 agent instance servicing a specific AOR. The AOR identifies a 327 resource, such as a user or service within a domain, and the instance 328 ID identifies a specific UA instance servicing requests for that 329 resource. 331 It is important to understand that this uniqueness is over the 332 instance ID/AOR pair, not just the instance ID. For example, if a 333 user registered the Contact 334 sip:ua@pc.example.com;+sip.instance="urn:foo:1", representing a 335 device with instance ID urn:foo:1, to the AOR sip:user@example.com, 336 and also registered the same Contact, representing the same instance 337 ID - sip:ua@pc.example.com;+sip.instance="urn:foo:1" to a second AOR, 338 say sip:boss@example.com, each of those UA instances would have a 339 different GRUU, since they belong to different AORs. 341 A GRUU translates to zero or one Contact URIs. The Contact URI is a 342 temporary URI that can be used to reach the instance ID/AOR pair. 343 This URI can change due to changes in the IP address associated with 344 the instance ID/AOR pair. If the instance ID associated with the 345 GRUU is the instance ID of a Contact URI currently bound to the AOR 346 associated with that GRUU, then the GRUU translates to that Contact 347 URI. If, however, the instance ID associated with the GRUU is not an 348 instance ID of a Contact URI currently bound to the AOR associated 349 with the GRUU (possibly because there are no Contact URIs bound to 350 the AOR), the GRUU maps to no Contact URI, and the GRUU is said to be 351 invalid. 353 This specification does not mandate a particular mechanism for 354 construction of the GRUU. Several example approaches are given in 355 Appendix A. However, the GRUU MUST exhibit the following properties: 356 o The domain part of the URI is an IP address present on the public 357 Internet, or, if it is a host name, exists in the global DNS and 358 corresponds to an IP address present on the public Internet. 359 o When a request is sent to this URI, it routes to a proxy server in 360 the same domain as that of the registrar. 361 o A proxy server in the domain can determine that the URI is a GRUU. 362 o When a proxy server in this domain receives a request sent to a 363 URI that is a GRUU, that URI MUST be translated to the Contact URI 364 currently bound to the AOR associated with that GRUU whose 365 instance ID is the one associated with the GRUU. 367 Once an association from an instance ID/AOR to a GRUU is created, 368 that mapping MUST remain in existence, and valid, as long as there 369 exists any Contact bound to that AOR whose instance ID is that 370 instance ID. If, through a de-registration or expiration, there is 371 no longer any Contact bound to that AOR whose instance ID is that 372 instance ID, the registrar MUST remove the mapping, and invalidate 373 the GRUU. However, at any time in the future, should a Contact 374 become bound to that same AOR, and that Contact is associated with 375 the same instance ID, the domain SHOULD create the same GRUU that was 376 previously associated with that instance ID/AOR pair. Indeed, this 377 requirement would ideally be a MUST if it was achieveable, but even 378 with the stateless algorithm described above, key rotation or server 379 failures may cause the GRUU associated with an instance ID/AOR pair 380 to change. The value of associating the GRUU with an instance ID/AOR 381 pair, as opposed to a Contact URI/AOR pair, is that the association 382 can transcend changes in IP address. As a result, domains SHOULD 383 make every effort possible to maintain the association for as long as 384 possible. 386 7. Obtaining a GRUU 388 A GRUU can be obtained in many ways. This document defines two - 389 through registrations, and through administrative operation. 391 7.1 Through Registrations 393 When a GRUU is associated with a user agent that comes and goes, and 394 therefore registers to the network to bind itself to an AOR, a GRUU 395 is provided to the user agent through SIP REGISTER messages. 397 7.1.1 User Agent Behavior 399 When a UA compliant to this specification generates a REGISTER 400 request (initial or refresh), it MUST include the Supported header 401 field in the request. The value of that header field MUST include 402 "gruu" as one of the option tags. This alerts the registrar for the 403 domain that the UA supports the GRUU mechanism. 405 Furthermore, for each Contact for which the UA desires to obtain a 406 GRUU, the UA MUST include a "sip.instance" media feature tag as a UA 407 characteristic [9]. As described in [9], this media feature tag will 408 be encoded in the Contact header field as the "+sip.instance" Contact 409 header field parameter. The value of this parameter MUST be a URI 410 [7]. [9] defines equality rules for callee capabilities parameters, 411 and according to that specification, the "sip.instance" media feature 412 tag will be compared by case sensitive string comparison. Those 413 equality rules apply only to the generic usages defined there and in 414 the caller preferences specification [16]. When the instance ID is 415 used in this specification, it is effectively "extracted" from the 416 value in the "sip.instance" media feature tag, and thus equality 417 comparisons are performed using the rules for URI equality specific 418 to the scheme in the URI. 420 It is RECOMMENDED that the URI be a Uniform Resource Name (URN) [8]. 421 This specification makes no normative recommendation on the specific 422 URI or URN that is to be used. However, the URI MUST be selected 423 such that the instance can be certain that no other instance 424 registering against the same AOR would choose the same URI value. 425 Usage of a URN is RECOMMENDED since it provides a persistent and 426 unique name for the UA instance, allowing it to obtain the same GRUU 427 over time. It also provides an easy way to guarantee uniquess within 428 the AOR. However, this specification does not require a long-lived 429 and persistent instance identifier to properly function, and in some 430 cases, there may be cause to use an identifier with weaker temporal 431 persistence. 433 One URN that readily meets the requirements of this specification is 434 the UUID URN [20], which allows for non-centralized computation of a 435 URN based on time, unique names (such as a MAC address) or a random 436 number generator. An example of a URN that would not meet the 437 requirements of this specification is the national bibliographic 438 number [13]. Since there is no clear relationship between an SIP UA 439 instance and a URN in this namespace, there is no way a selection of 440 a value can be performed that guarantees that another UA instance 441 doesn't choose the same value. 443 Besides the presence of the "gruu" option tag in the Supported header 444 field and the "+sip.instance" Contact header field parameter, the 445 REGISTER request is constructed identically to the case where this 446 extension was not understood. Specifically, the Contact URI in the 447 REGISTER request SHOULD NOT contain the gruu Contact header field 448 parameter. Any such parameters are ignored by the registrar, as the 449 UA cannot propose a GRUU for usage with the Contact URI. 451 If a UA wishes to guarantee that the request is not processed unless 452 the domain supports and uses this extension, it MAY include a Require 453 header field in the request with a value that contains the "gruu" 454 option tag. 456 If the response is a 2xx, each Contact header field that contained 457 the "+sip.instance" Contact header field parameter may also contain a 458 "gruu" parameter. This parameter contains a SIP URI that represents 459 a GRUU corresponding to the UA instance that registered the contact. 460 Any requests sent to the GRUU URI will be routed by the domain to the 461 Contact URI currently bound to that instance ID. The GRUU will not 462 normally change in subsequent 2xx responses to REGISTER. Indeed, 463 even if the UA lets the contact expire, when it re-registers it at 464 any later time, the registrar will normally provide the same GRUU for 465 the same address-of-record and instance ID. However, this property 466 cannot be completely guaranteed, as network failures may make it 467 impossible to provide an identifier that persists for all time. As a 468 result, a UA MUST be prepared to receive a different GRUU in a 469 subsequent registration response. 471 A non-2xx response to the REGISTER request has no impact on any 472 existing GRUU previously provided to the UA. Specifically, if a 473 previously successful REGISTER request provided the UA with a GRUU, a 474 subsequent failed request does not remove, delete, or otherwise 475 invalidate the GRUU. 477 If the response to the REGISTER request was a 425, it means that one 478 of the Contact URI in the REGISTER request contained an instance ID 479 that was already associated with a different registered Contact. It 480 is up to the client to resolve this conflict. The conflict normally 481 arises when a client registers a Contact with its instance ID, 482 crashes, and reboots. After reboot, it obtains a new IP address, and 483 attempts to register a Contact for that address, containing the same 484 instance ID. In such a case, the proper course of action is to 485 remove the old registration. To do that, the client can send a 486 REGISTER request with no Contacts. The 200 OK contains the list of 487 currently registered Contacts, including their instance IDs. The 488 client can find the existing contact that matches its instance ID, 489 and then send a new REGISTER request. This request would include the 490 old Contact, with the instance ID, and an expires value of 0. Then, 491 the client can retry its failed registration. 493 7.1.2 Registrar Behavior 495 A registrar MAY create a GRUU for a particular instance ID/AOR pair 496 at any time. Of course, if a UA requests a GRUU in a registration, 497 and the registrar has not yet created one, it will need to do so in 498 order to respond to the registration request. However, the registrar 499 can create the GRUU in advance of any request from a UA. 501 When a registrar compliant to this specification receives a REGISTER 502 request, it checks for the presence of the Require header field in 503 the request. If present, and if it contains the "gruu" option tag, 504 the registrar MUST follow the procedures in the remainder of this 505 section (that is, the procedures which result in the creation of new 506 GRUUs for Contacts indicating an instance ID, and the listing of 507 GRUUs in the REGISTER response). If not present, but a Supported 508 header field was present with the "gruu" option tag, the registrar 509 SHOULD follow the procedures in the remainder of this section. If 510 the Supported header field was not present, or it if was present but 511 did not contain the value "gruu", the registrar SHOULD NOT follow the 512 procedures in the remainder of this section. 514 As the registrar is processing the Contacts in the REGISTER request 515 according to the procedures of step 7 in Section 10.3 of RFC 3261, 516 the registrar additionally checks whether each contact contains a 517 "+sip.instance" header field parameter. If it does, the registrar 518 takes the value of that parameter as an instance ID. The registrar 519 checks to see if there is any other contact bound to the same AOR 520 with the same instance ID (recall that equality is computed using URI 521 equality for the scheme in question). If there is, this is an error 522 condition. Only a single Contact URI at a time can be registered for 523 each instance ID. As a result, the registrar MUST reject the request 524 with a 425 (Instance Conflict) error response. This response code 525 informs the client that its registration failed because the instance 526 ID provided in the request is already registered to a different 527 Contact. It is up to the client to decide how to proceed. 529 If there is no other contact bound to the same AOR with the same 530 instance ID, the server allocates and/or creates a GRUU for that 531 instance ID/AOR pair according to the procedures of Section 6. If 532 the contact contained a "gruu" Contact header field parameter, it 533 MUST be ignored by the registrar. A UA cannot suggest or otherwise 534 provide a GRUU to the registrar. In addition to storing the contact 535 URI, the server MUST store the instance ID. 537 When generating the 200 (OK) response to the REGISTER request, the 538 procedures of step 8 of Section 10.3 of RFC 3261 are followed. 539 Furthermore, for each Contact header field value placed in the 540 response, if the registrar has stored an instance ID associated with 541 that contact URI, the server MUST add a "gruu" Contact header field 542 parameter. This parameter contains the instance ID for the user 543 agent. The value of the gruu parameter is a quoted string containing 544 the URI that is the GRUU for the associated instance ID/AOR pair. 546 Note that handling of a REGISTER request containing a Contact header 547 field with value "*" and an expiration of 0 still retains the meaning 548 defined in RFC 3261 - all Contacts, not just ones with a specific 549 instance ID, are deleted. 551 Inclusion of a GRUU in the "gruu" Contact header field parameter of a 552 REGISTER response is separate from the computation and storage of the 553 GRUU. It is possible that the registrar has computed a GRUU for one 554 UA, but a different UA that queries for the current set of 555 registrations doesn't understand GRUU. In that case, the REGISTER 556 response sent to that second UA would not contain the "gruu" Contact 557 header field parameter, even though the UA has a GRUU for that 558 Contact. 560 7.2 Administratively 562 Administrative creation of GRUUs is useful when a UA instance is a 563 network server that is always available, and therefore doesn't 564 register to the network. Examples of such servers are voicemail 565 servers, application servers, and gateways. 567 There are no protocol operations required to administratively create 568 a GRUU. The proxy serving the domain is configured with the GRUU, 569 and with the Contact URI it should be translated to. It is not 570 strictly necessary to also configure the instance ID and AOR, since 571 the translation can be done directly. However, they serve as a 572 useful tool for determining which resource and UA instance the GRUU 573 is supposed to map to. 575 In addition to configuring the GRUU and its associated Contact URI in 576 the proxy serving the domain, the GRUU will also need to be 577 configured into the UA instance associated with the GRUU. 579 8. Using the GRUU 581 8.1 Sending a Message Containing a GRUU 583 A UA first obtains a GRUU using the procedures of Section 7, or by 584 other means outside the scope of this specification. 586 A UA can use the GRUU in the same way it would use any other SIP URI. 587 However, a UA compliant to this specification MUST use a GRUU when 588 populating the Contact header field of dialog-creating requests and 589 responses. This includes the INVITE request and its 2xx response, 590 the SUBSCRIBE [4] request, its 2xx response, the NOTIFY request, and 591 the REFER [5] request and its 2xx response. Similarly, in those 592 requests and responses where the GRUU is used in the Contact header 593 field, the UA MUST include a Supported header field that contains the 594 option tag "gruu". However, it is not necessary for a UA to know 595 whether or not its peer in the dialog uses a GRUU before inserting 596 one into the Contact header field. 598 When placing a GRUU into the Contact header field of a request or 599 response, a UA MAY add the "grid" URI parameter to the GRUU. This 600 parameter MAY take on any value permitted by the grammar for the 601 parameter. Note that there are no limitations on the size of this 602 parameter. When a UA sends a request to the GRUU, the proxy for the 603 domain that owns the GRUU will translate the GRUU in the Request-URI, 604 replacing it with the corresponding Contact URI. However, it will 605 retain the "grid" parameter when this translation is performed. As a 606 result, when the UA receives the request, the Request-URI will 607 contain the "grid" created by the UA. This allows the UA to 608 effectively manufacture an infinite supply of GRUU, each of which 609 differs by the value of the "grid" parameter. When a UA receives a 610 request that was sent to the GRUU, it will be able to tell which GRUU 611 was invoked by the "grid" parameter. 613 An implication of this behavior is that all mid-dialog requests will 614 be routed through intermediate proxies. There will never be direct, 615 UA to UA signaling. It is anticipated that this limitation will be 616 addressed in future specifications. 618 Once a UA knows that the Contact URI provided by its peer is a GRUU, 619 it can use it in any application or SIP extension which requires a 620 globally routable URI to operate. One such example is assisted call 621 transfer. 623 8.2 Sending a Message to a GRUU 625 There is no new behavior associated with sending a request to a GRUU. 626 A GRUU is a URI like any other. When a UA receives a request or 627 response, it will know that the Contact header field contained a GRUU 628 if the request or response had a Supported header field that included 629 the value "gruu". The UA can take the GRUU, and send a request to 630 it, and then be sure that it is delivered to the UA instance which 631 sent the request or response. 633 Since the instance ID is a callee capabilities parameter, a UA might 634 be tempted to send a request to the AOR of a user, and include an 635 Accept-Contact header field [16] which indicates a preference for 636 routing the request to a UA with a specific instance ID. Although 637 this would appear to have the same effect as sending a request to the 638 GRUU, it does not. The caller preferences expressed in the 639 Accept-Contact header field are just preferences, and do not work 640 with the some reliability as GRUU. However, this specification does 641 not forbid a client from attempting such a request, as there may be 642 cases where the desired operation truly is a preferential routing 643 request. 645 8.3 Receiving a Request Sent to a GRUU 647 When a UAS receives a request sent to its GRUU, the incoming request 648 URI will be equal to the Contact URI that was registered (through 649 REGISTER or some other action) by that UA instance. If the user 650 agent had previously handed out its GRUU with a grid parameter, the 651 incoming request URI may contain that parameter. This indicates to 652 the UAS that the request is being received as a result of a request 653 sent by the UAC to that GRUU/grid combination. This specification 654 makes no normative statements about when to use a grid parameter, or 655 what to do when receiving a request made to a GRUU/grid combination. 656 Generally, any differing behaviors are a matter of local policy. 658 It is important to note that, when a user agent receives a request, 659 and the request URI does not have a grid parameter, the user agent 660 cannot tell whether the request was sent to the AOR or to the GRUU. 661 As such, the UAS will process such requests identically. If a user 662 agent needs to differentiate its behavior based on these cases, it 663 will need to use a grid parameter. 665 8.4 Proxy Behavior 667 When a proxy server receives a request, and the proxy owns the domain 668 in the Request URI, and the proxy is supposed to access a Location 669 Service in order to compute request targets (as specified in Section 670 16.5 of RFC 3261 [1]), the proxy MUST check if the Request URI is a 671 GRUU created by that domain. 673 If the URI is a GRUU, the proxy MUST determine if there is still a 674 Contact URI bound to AOR associated with the GRUU, whose instance ID 675 is the instance ID associated with the GRUU. If that AOR no longer 676 has any contacts bound to it, or if it does have contacts bound to 677 it, but none of them have an instance ID equal to the instance ID 678 associated with the GRUU, the proxy MUST generate a 480 (Temorarily 679 Unavailable) response to the request. If, however, the proxy does 680 not recognize the GRUU as one it had constructed previously for the 681 domain, the proxy MUST generate a 404 (Not Found) response to the 682 request. 684 Otherwise, the proxy MUST populate the target set with a single URI. 685 This URI MUST be equal to the Contact URI that is translated from the 686 GRUU. Furthermore, if the GRUU contained a "grid" URI parameter, the 687 URI in the target set MUST also contain the same parameter with the 688 same value. 690 A proxy MAY apply other processing to the request, such as execution 691 of called party features. In particular, it is RECOMMENDED that 692 non-routing called party features, such as call logging and 693 screening, that are associated with the AOR are also applied to 694 requests for all GRUUs associated with that AOR. 696 In many cases, a proxy will record-route an initial INVITE request, 697 and the user agents will insert a GRUU into the Contact header field. 698 When this happens, a mid-dialog request will arrive at the proxy with 699 a Route header field that was inserted by the proxy, and a 700 Request-URI that represents a GRUU. Proxies follow normal processing 701 in this case; they will strip the Route header field, and then 702 process the Request URI as described above. 704 The procedures of RFC 3261 are then followed to proxy the request. 705 The request SHOULD NOT be redirected in this case. In many 706 instances, a GRUU is used by a UA in order to assist in the traversal 707 of NATs and firewalls, and a redirection may prevent such a case from 708 working. 710 9. 425 (Instance Conflict) Response Code 712 This specification defines a new response code for SIP. The response 713 code is 425, and it has a default reason phrase of "Instance 714 Conflict". This response code is valid only for REGISTER responses. 715 It informs the UA that its registration failed because the instance 716 ID provided in the request is already registered to a different 717 Contact. 719 10. Grammar 721 This specification defines two new Contact header field parameters, 722 gruu and +sip.instance, and a new URI parameter, grid. The grammar 723 for string-value is obtained from [9], and the grammar for uric is 724 defined in RFC 2396 [7]. 726 contact-params = c-p-q / c-p-expires / c-p-gruu / cp-instance 727 / contact-extension 728 c-p-gruu = "gruu" EQUAL DQUOTE SIP-URI DQUOTE 729 cp-instance = "+sip.instance" EQUAL LDQUOT instance-val RDQUOT 730 uri-parameter = transport-param / user-param / method-param 731 / ttl-param / maddr-param / lr-param / grid-param 732 / other-param 733 grid-param = "grid=" pvalue ; defined in RFC3261 734 instance-val = uric ; defined in RFC 2396 736 11. Requirements 738 This specification was created in order to meet the following 739 requirements: 740 REQ 1: When a UA invokes a GRUU, it MUST cause the request to be 741 routed to the specific UA instance to which the GRUU refers. 742 REQ 2: It MUST be possible for a GRUU to be invoked from anywhere on 743 the Internet, and still cause the request to be routed 744 appropriately. That is, a GRUU MUST NOT be restricted to use 745 within a specific addressing realm. 746 REQ 3: It MUST be possible for a GRUU to be constructed without 747 requiring the network to store additional state. 748 REQ 4: It MUST be possible for a UA to obtain a multiplicity of 749 GRUUs, each one of which routes to that UA instance. This is 750 needed to support ad-hoc conferencing, for example, where a a UA 751 instance needs a different URI for each conference it is hosting. 752 REQ 5: When a UA receives a request sent to a GRUU, it MUST be 753 possible for the UA to know the GRUU which was used to invoke the 754 request. This is necessary as a consequence of requirement 4. 755 REQ 6: It MUST be possible for a UA to add opaque content to a GRUU, 756 which is not interpreted or altered by the network, and used only 757 by the UA instance to whom the GRUU refers. This provides a basic 758 cookie type of functionality, allowing a UA to build a GRUU with 759 state embedded within it. 760 REQ 7: It MUST be possible for a proxy to execute services and 761 features on behalf of a UA instace represented by a GRUU. As an 762 example, if a user has call blocking features, a proxy may want to 763 apply those call blocking features to calls made to the GRUU in 764 addition to calls made to the user's AOR. 765 REQ 8: It MUST be possible for a UA in a dialog to inform its peer of 766 its GRUU, and for the peer to know that the URI represents a GRUU. 767 This is needed for the conferencing and dialog reuse applications 768 of GRUUs, where the URIs are transferred within a dialog. 769 REQ 9: When transferring a GRUU per requirement 8, it MUST be 770 possible for the UA receiving the GRUU to be assured of its 771 integrity and authenticity. 772 REQ 10: It MUST be possible for a server, authoritative for a domain, 773 to construct a GRUU which routes to a UA instace bound to an AOR 774 in that domain. In other words, the proxy can construct a GRUU 775 too. This is needed for the presence application. 777 12. Example Call Flow 779 The following call flow shows a basic registration and call setup, 780 followed by a subscription directed to the GRUU. It then shows a 781 failure of the callee, followed by a re-registration. 783 Caller Proxy Callee 784 | |(1) REGISTER | 785 | |<--------------------| 786 | |(2) 200 OK | 787 | |-------------------->| 788 |(3) INVITE | | 789 |-------------------->| | 790 | |(4) INVITE | 791 | |-------------------->| 792 | |(5) 200 OK | 793 | |<--------------------| 794 |(6) 200 OK | | 795 |<--------------------| | 796 |(7) ACK | | 797 |-------------------->| | 798 | |(8) ACK | 799 | |-------------------->| 800 |(9) SUBSCRIBE | | 801 |-------------------->| | 802 | |(10) SUBSCRIBE | 803 | |-------------------->| 804 | |(11) 200 OK | 805 | |<--------------------| 806 |(12) 200 OK | | 807 |<--------------------| | 808 | |(13) NOTIFY | 809 | |<--------------------| 810 |(14) NOTIFY | | 811 |<--------------------| | 812 |(15) 200 OK | | 813 |-------------------->| | 814 | |(16) 200 OK | 815 | |-------------------->| 816 | | |Crashes, Reboots 817 | |(17) REGISTER | 818 | |<--------------------| 819 | |(18) 425 | 820 | |-------------------->| 821 | |(19) REGISTER | 822 | |<--------------------| 823 | |(20) 200 OK | 824 | |-------------------->| 825 | |(21) REGISTER | 826 | |<--------------------| 827 | |(22) 200 OK | 828 | |-------------------->| 829 | |(23) REGISTER | 830 | |<--------------------| 831 | |(24) 200 OK | 832 | |-------------------->| 834 The Callee supports the GRUU extension. As such, its REGISTER (1) 835 looks like: 837 REGISTER sip:example.com SIP/2.0 838 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 839 Max-Forwards: 70 840 From: Callee ;tag=a73kszlfl 841 Supported: gruu 842 To: Callee 843 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 844 CSeq: 1 REGISTER 845 Contact: 846 ;+sip.instance="" 847 Content-Length: 0 849 The REGISTER response would look like: 851 SIP/2.0 200 OK 852 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 853 From: Callee ;tag=a73kszlfl 854 To: Callee ;tag=b88sn 855 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 856 CSeq: 1 REGISTER 857 Contact: 858 ;gruu="sip:hha9s8d=-999a@example.com" 859 ;+sip.instance="" 860 ;expires=3600 861 Content-Length: 0 863 Note how the Contact header field in the REGISTER response contains 864 the gruu parameter with the URI sip:hha9s8d=-999a@example.com. This 865 represents a GRUU that translates to the Contact URI 866 sip:callee@192.0.2.1. 868 The INVITE from the caller is a normal SIP INVITE. The 200 OK 869 generated by the callee, however, now contains a GRUU in the Contact 870 header field. The UA has also chosen to include a grid URI parameter 871 into the GRUU. 873 SIP/2.0 200 OK 874 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8 875 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a 876 From: Caller ;tag=n88ah 877 To: Callee ;tag=a0z8 878 Call-ID: 1j9FpLxk3uxtma7@host.example.com 879 CSeq: 1 INVITE 880 Supported: gruu 881 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 882 Contact: 883 Content-Length: -- 884 Content-Type: application/sdp 886 [SDP Not shown] 888 At some point later in the call, the caller decides to subscribe to 889 the dialog event package [15] at that specific UA. To do that, it 890 generates a SUBSCRIBE request (message 9), but directs it towards the 891 GRUU contained in the Contact header field. 893 SUBSCRIBE sip:hha9s8d=-999a@example.com;grid=99a SIP/2.0 894 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 895 From: Caller ;tag=kkaz- 896 To: Callee 897 Call-ID: faif9a@host.example.com 898 CSeq: 2 SUBSCRIBE 899 Supported: gruu 900 Event: dialog 901 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 902 Contact: 903 Content-Length: 0 905 In this example, the caller itself supports the GRUU extension, and 906 is using its own GRUU to populate the Contact header field of the 907 SUBSCRIBE. 909 This request is routed to the proxy, which proceeds to perform a 910 location lookup on the request URI. It is translated into the 911 Contact URI of that GRUU, and then proxied there (message 10 below). 912 Note how the grid parameter is maintained. 914 SUBSCRIBE sip:callee@192.0.2.1;grid=99a SIP/2.0 915 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK9555 916 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 917 From: Caller ;tag=kkaz- 918 To: Callee 919 Call-ID: faif9a@host.example.com 920 CSeq: 2 SUBSCRIBE 921 Supported: gruu 922 Event: dialog 923 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 924 Contact: 925 Content-Length: 0 927 At some point after message 16 is received, the callee's machine 928 crashes and recovers. It obtains a new IP address, 192.0.2.2. 929 Unaware that it had previously had an active registration, it creates 930 a new one (message 17 below). Notice how the instance ID remains the 931 same, as it persists across reboot cycles: 933 REGISTER sip:example.com SIP/2.0 934 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba 935 Max-Forwards: 70 936 From: Callee ;tag=ha8d777f0 937 Supported: gruu 938 To: Callee 939 Call-ID: hf8asxzff8s7f@192.0.2.2 940 CSeq: 1 REGISTER 941 Contact: 942 ;+sip.instance="" 943 Content-Length: 0 945 The registrar notices that a different contact, sip:callee@192.0.2.1, 946 is already associated with the same instance ID. Thus, it rejects 947 the request in message 18, below: 949 SIP/2.0 425 Instance Conflict 950 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba 951 From: Callee ;tag=ha8d777f0 952 To: Callee ;tag=776554 953 Call-ID: hf8asxzff8s7f@192.0.2.2 954 CSeq: 1 REGISTER 956 Next, the client formulates a new REGISTER request, to query for the 957 existing set of registrations (message 19, below): 959 REGISTER sip:example.com SIP/2.0 960 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbbb 961 Max-Forwards: 70 962 From: Callee ;tag=ha8d777f1 963 Supported: gruu 964 To: Callee 965 Call-ID: hf8asxzff8s7g@192.0.2.2 966 CSeq: 2 REGISTER 968 This generates a 200 (OK) response (message 20, below) that includes 969 the existing contact: 971 SIP/2.0 200 OK 972 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbbb 973 From: Callee ;tag=ha8d777f1 974 To: Callee ;tag=8asd7d666 975 Call-ID: hf8asxzff8s7g@192.0.2.2 976 CSeq: 2 REGISTER 977 Contact: 978 ;gruu="sip:hha9s8d=-999a@example.com" 979 ;+sip.instance="" 980 ;expires=2000 982 The client realizes that a different IP address is registered with 983 the same instance ID. Since the client knows that its instance ID is 984 globally unique, it deletes that registration (message 21, below): 986 REGISTER sip:example.com SIP/2.0 987 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbbc 988 Max-Forwards: 70 989 From: Callee ;tag=ha8d777f2 990 Supported: gruu 991 To: Callee 992 Call-ID: hf8asxzff8s7g@192.0.2.2 993 CSeq: 3 REGISTER 994 Contact: 995 ;+sip.instance="" 996 ;expires=0 998 This deletes the contact, as indicated by the lack of of the Contact 999 header field in the resulting 200 OK (message 22, below): 1001 SIP/2.0 200 OK 1002 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbbc 1003 From: Callee ;tag=ha8d777f2 1004 To: Callee ;tag=7asdnj7d6f 1005 Call-ID: hf8asxzff8s7g@192.0.2.2 1006 CSeq: 3 REGISTER 1008 Finally, the client can retry its original registration (message 23, 1009 below): 1011 REGISTER sip:example.com SIP/2.0 1012 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbbd 1013 Max-Forwards: 70 1014 From: Callee ;tag=ha8d777f3 1015 Supported: gruu 1016 To: Callee 1017 Call-ID: hf8asxzff8s7g@192.0.2.2 1018 CSeq: 4 REGISTER 1019 Contact: 1020 ;+sip.instance="" 1022 This time, the registration succeeds, and the client is registered. 1024 The response, message 24, is shown below: 1026 REGISTER sip:example.com SIP/2.0 1027 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbbd 1028 From: Callee ;tag=ha8d777f3 1029 To: Callee ;tag=asd7salll 1030 Call-ID: hf8asxzff8s7g@192.0.2.2 1031 CSeq: 4 REGISTER 1032 Contact: 1033 ;+sip.instance="" 1034 ;expires=3600 1036 13. Security Considerations 1038 GRUUs do not provide a complete or reliable solution for privacy. In 1039 particular, since the GRUU does not change during the lifetime of a 1040 registration, an attacker could correlate two calls as coming from 1041 the same source, which in and of itself reveals information about the 1042 caller. Furthermore, GRUUs do not address other aspects of privacy, 1043 such as the addresses used for media transport. For a discussion of 1044 how privacy services are provided in SIP, see RFC 3323 [12]. 1046 It is important for a UA to be assured of the integrity of a GRUU 1047 when it is given one in a REGISTER response. If the GRUU is tampered 1048 with by an attacker, the result could be denial of service to the UA. 1049 As a result, it is RECOMMENDED that a UA use the SIPS URI scheme when 1050 registering. 1052 14. IANA Considerations 1054 This specification defines a new Contact header field parameter, a 1055 new SIP response code, a SIP URI parameter, a media feature tag and a 1056 SIP option tag. 1058 14.1 Header Field Parameter 1060 This specification defines a new header field parameter, as per the 1061 registry created by [10]. The required information is as follows: 1062 Header field in which the parameter can appear: Contact 1063 Name of the Parameter gruu 1064 RFC Reference RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1065 RFC number of this specification.]] 1067 14.2 Response Code 1069 This specification defines the new SIP response code, 425, per the 1070 guidelines in Section 27.4 of RFC 3261. 1071 RFC Number: This specification, RFC XXXX [[NOTE to IANA: Please 1072 replace XXXX with the RFC number for this specification.]]. 1073 Response Code Number: 425 1074 Default Reason Phrase: Instance Conflict 1076 14.3 URI Parameter 1078 This specification defines a new SIP URI parameter, as per the 1079 registry created by [11]. 1080 Name of the Parameter grid 1081 RFC Reference RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1082 RFC number of this specification.]] 1084 14.4 Media Feature Tag 1086 This section registers a new media feature tag, per the procedures 1087 defined in RFC 2506 [6]. The tag is placed into the sip tree, which 1088 is defined in [9]. 1089 Media feature tag name: sip.instance 1090 ASN.1 Identifier: New assignment by IANA. 1091 Summary of the media feature indicated by this tag: This feature tag 1092 contains a string containing a URI, and ideally a URN, that 1093 indicates a unique identifier associated with the UA instance 1094 registering the Contact. 1095 Values appropriate for use with this feature tag: String. 1096 The feature tag is intended primarily for use in the following 1097 applications, protocols, services, or negotiation mechanisms: This 1098 feature tag is most useful in a communications application, for 1099 describing the capabilities of a device, such as a phone or PDA. 1100 Examples of typical use: Routing a call to a specific device. 1101 Related standards or documents: RFC XXXX [[Note to IANA: Please 1102 replace XXXX with the RFC number of this specification.]] 1103 Security Considerations: This media feature tag can be used in ways 1104 which affect application behaviors. For example, the SIP caller 1105 preferences extension [16] allows for call routing decisions to be 1106 based on the values of these parameters. Therefore, if an 1107 attacker can modify the values of this tag, they may be able to 1108 affect the behavior of applications. As a result of this, 1109 applications which utilize this media feature tag SHOULD provide a 1110 means for ensuring its integrity. Similarly, this feature tag 1111 should only be trusted as valid when it comes from the user or 1112 user agent described by the tag. As a result, protocols for 1113 conveying this feature tag SHOULD provide a mechanism for 1114 guaranteeing authenticity. 1116 14.5 SIP Option Tag 1118 This specification registers a new SIP option tag, as per the 1119 guidelines in Section 27.1 of RFC 3261. 1120 Name: gruu 1121 Description: This option tag is used to identify the Globally 1122 Routable User Agent URI (GRUU) extension. When used in a 1123 Supported header, it indicates that a User Agent understands the 1124 extension, and has included a GRUU in the Contact header field of 1125 its dialog initiating requests and responses. When used in a 1126 Require header field of a REGISTER request, it indicates that the 1127 registrar should assign a GRUU to the Contact URI. 1129 15. Acknowledgements 1131 The author would like to thank Rohan Mahy, Paul Kyzivat, Alan 1132 Johnston, and Cullen Jennings for their contributions to this work. 1134 16. References 1136 16.1 Normative References 1138 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1139 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1140 Session Initiation Protocol", RFC 3261, June 2002. 1142 [2] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1143 Method", RFC 3311, October 2002. 1145 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1146 Levels", BCP 14, RFC 2119, March 1997. 1148 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1149 Notification", RFC 3265, June 2002. 1151 [5] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1152 Method", RFC 3515, April 2003. 1154 [6] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag 1155 Registration Procedure", BCP 31, RFC 2506, March 1999. 1157 [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1158 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1159 1998. 1161 [8] Moats, R., "URN Syntax", RFC 2141, May 1997. 1163 [9] Rosenberg, J., "Indicating User Agent Capabilities in the 1164 Session Initiation Protocol (SIP)", 1165 draft-ietf-sip-callee-caps-03 (work in progress), January 2004. 1167 [10] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1168 Header Field Parameter Registry for the Session Initiation 1169 Protocol (SIP)", draft-ietf-sip-parameter-registry-02 (work in 1170 progress), June 2004. 1172 [11] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1173 Universal Resource Identifier (URI) Parameter Registry for the 1174 Session Initiation Protocol (SIP)", 1175 draft-ietf-sip-uri-parameter-reg-02 (work in progress), June 1176 2004. 1178 16.2 Informative References 1180 [12] Peterson, J., "A Privacy Mechanism for the Session Initiation 1181 Protocol (SIP)", RFC 3323, November 2002. 1183 [13] Hakala, J., "Using National Bibliography Numbers as Uniform 1184 Resource Names", RFC 3188, October 2001. 1186 [14] Rosenberg, J., "A Framework for Conferencing with the Session 1187 Initiation Protocol", 1188 draft-ietf-sipping-conferencing-framework-01 (work in 1189 progress), October 2003. 1191 [15] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog 1192 Event Package for the Session Initiation Protocol (SIP)", 1193 draft-ietf-sipping-dialog-package-04 (work in progress), 1194 February 2004. 1196 [16] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller 1197 Preferences for the Session Initiation Protocol (SIP)", 1198 draft-ietf-sip-callerprefs-10 (work in progress), October 2003. 1200 [17] Sugano, H. and S. Fujimoto, "Presence Information Data Format 1201 (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 1202 2003. 1204 [18] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 1205 Control - Transfer", draft-ietf-sipping-cc-transfer-02 (work in 1206 progress), February 2004. 1208 [19] Rosenberg, J., "A Presence Event Package for the Session 1209 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 1210 in progress), January 2003. 1212 [20] Mealling, M., "A UUID URN Namespace", 1213 draft-mealling-uuid-urn-03 (work in progress), March 2004. 1215 Author's Address 1217 Jonathan Rosenberg 1218 dynamicsoft 1219 600 Lanidex Plaza 1220 Parsippany, NJ 07054 1221 US 1223 Phone: +1 973 952-5000 1224 EMail: jdrosen@dynamicsoft.com 1225 URI: http://www.jdrosen.net 1227 Appendix A. Example GRUU Construction Algorithms 1229 The mechanism for constructing a GRUU is not subject to 1230 specification. This appendix provides two examples that can be used 1231 by a registar. Others are, of course, permitted, as long as they 1232 meet the constraints defined for a GRUU. 1234 A.1 Encrypted Instance ID and AOR 1236 In many cases, it will be desirable to construct the GRUU in such a 1237 way that it will not be possible, based on inspection of the URI, to 1238 determine the Contact URI that the GRUU translates to. It may also 1239 be desirable to construct it so that it will not be possible to 1240 determine the instance ID/AOR pair associated with the GRUU. Whether 1241 or not a GRUU should be constructed with this property is a local 1242 policy decision. 1244 With these rules, it is possible to construct a GRUU without 1245 requiring the maintenance of any additional state. To do that, the 1246 URI would be constructed in the following fashion: 1247 user-part = "GRUU" + BASE64(E(K, (salt + " " + AOR + " " + 1248 instance ID))) 1250 Where E(K,X) represents a suitable encryption function (such as AES 1251 with 128 bit keys) with key K applied to data block X, and the "+" 1252 operator implies concatenation. The single space (" ") between 1253 components is used as a delimeter, so that the components can easily 1254 be extracted after decryption. Salt represents a random string that 1255 prevents a client from obtaining pairs of known plaintext and 1256 ciphertext. A good choice would be at least 128 bits of randomness 1257 in the salt. 1259 The benefit of this mechanism is that a server need not store 1260 additional information on mapping a GRUU to its corresponding Contact 1261 URI. The user part of the GRUU contains the instance ID and AOR. 1262 Assuming that the domain stores registrations in a database indexed 1263 by the AOR, the proxy processing the GRUU would look up the AOR, 1264 extract the currently registered Contacts, and find the one matching 1265 the instance ID encoded in the request URI. The Contact URI whose 1266 instance ID is that instance ID is then used as the translated 1267 version of the URI. Encryption is needed to prevent attacks whereby 1268 the server is sent requests with faked GRUU, causing the server to 1269 direct requests to any named URI. Even with encryption, the proxy 1270 should validate the user part after decryption. In particular, the 1271 AOR should be one managed by the proxy in that domain. Should a UA 1272 send a request with a fake GRUU, the proxy would decrypt and then 1273 discard it because there would be no URI or an invalid URI inside. 1275 While this approach has many benefits, it has the drawback of 1276 producing fairly long GRUUs. The approach in the following section 1277 produces smaller results, at the cost of additional structures in the 1278 database. 1280 A.2 Hashed Indices 1282 As an alternative approach, the server can construct the GRUU by 1283 computing a cryptographic hash of the AOR and instance ID, taking 64 1284 bits of the result, and placing a string representation of those 64 1285 bits into the user part of the URI. 1287 When a GRUU is created through registration or administrative action, 1288 the server computes this hash and stores the hash in the database. 1289 This hash acts the primary key, with the columns of the table 1290 providing the instance ID, AOR and Contact. When the registration is 1291 deleted, the corresponding row from the table is removed. When a 1292 request arrives to a proxy, the user part of the URI is looked up in 1293 the database, and the Contact, AOR and instance ID can be extracted. 1295 This approach produces GRUUs of relatively short length. However, it 1296 requires additional structures to be created and stored in a database 1297 that would be used by the registrar (at least, new structures are 1298 needed for efficient operation). However, it does not require the 1299 registrar to store anything for longer than the duration of the 1300 registration. 1302 Intellectual Property Statement 1304 The IETF takes no position regarding the validity or scope of any 1305 Intellectual Property Rights or other rights that might be claimed to 1306 pertain to the implementation or use of the technology described in 1307 this document or the extent to which any license under such rights 1308 might or might not be available; nor does it represent that it has 1309 made any independent effort to identify any such rights. Information 1310 on the procedures with respect to rights in RFC documents can be 1311 found in BCP 78 and BCP 79. 1313 Copies of IPR disclosures made to the IETF Secretariat and any 1314 assurances of licenses to be made available, or the result of an 1315 attempt made to obtain a general license or permission for the use of 1316 such proprietary rights by implementers or users of this 1317 specification can be obtained from the IETF on-line IPR repository at 1318 http://www.ietf.org/ipr. 1320 The IETF invites any interested party to bring to its attention any 1321 copyrights, patents or patent applications, or other proprietary 1322 rights that may cover technology that may be required to implement 1323 this standard. Please address the information to the IETF at 1324 ietf-ipr@ietf.org. 1326 Disclaimer of Validity 1328 This document and the information contained herein are provided on an 1329 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1330 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1331 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1332 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1333 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1334 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1336 Copyright Statement 1338 Copyright (C) The Internet Society (2004). This document is subject 1339 to the rights, licenses and restrictions contained in BCP 78, and 1340 except as set forth therein, the authors retain all their rights. 1342 Acknowledgment 1344 Funding for the RFC Editor function is currently provided by the 1345 Internet Society.