idnits 2.17.1 draft-ietf-sip-gruu-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1500. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 2 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 134 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 (February 21, 2005) is 6997 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3265 (ref. '6') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 2141 (ref. '10') (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '15') (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 3188 (ref. '16') (Obsoleted by RFC 8458) == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-03 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-05 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-03 Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: August 22, 2005 February 21, 2005 6 Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in 7 the Session Initiation Protocol (SIP) 8 draft-ietf-sip-gruu-03 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 22, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 Several applications of the Session Initiation Protocol (SIP) require 44 a user agent (UA) to construct and distribute a URI which can be used 45 by anyone on the Internet to route a call to that specific UA 46 instance. A URI which routes to a specific UA instance is called a 47 Globally Routable UA URI (GRUU). This document describes an 48 extension to SIP for obtaining a GRUU from a server, and for 49 communicating a GRUU to a peer within a dialog. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Defining a GRUU . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.1 REFER . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.2 Conferencing . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.3 Presence . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 61 6. Creation of a GRUU . . . . . . . . . . . . . . . . . . . . . . 8 62 7. Obtaining a GRUU . . . . . . . . . . . . . . . . . . . . . . . 10 63 7.1 Through Registrations . . . . . . . . . . . . . . . . . . 10 64 7.1.1 User Agent Behavior . . . . . . . . . . . . . . . . . 10 65 7.1.2 Registrar Behavior . . . . . . . . . . . . . . . . . . 12 66 7.2 Administratively . . . . . . . . . . . . . . . . . . . . . 15 67 8. Using the GRUU . . . . . . . . . . . . . . . . . . . . . . . . 15 68 8.1 Sending a Message Containing a GRUU . . . . . . . . . . . 15 69 8.2 Sending a Message to a GRUU . . . . . . . . . . . . . . . 16 70 8.3 Receiving a Request Sent to a GRUU . . . . . . . . . . . . 16 71 8.4 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 17 72 8.4.1 Request Targeting . . . . . . . . . . . . . . . . . . 17 73 8.4.2 Record Routing . . . . . . . . . . . . . . . . . . . . 18 74 9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 75 10. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 22 76 11. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 23 77 12. Security Considerations . . . . . . . . . . . . . . . . . . 27 78 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 79 13.1 Header Field Parameter . . . . . . . . . . . . . . . . . . 27 80 13.2 URI Parameter . . . . . . . . . . . . . . . . . . . . . . 27 81 13.3 Media Feature Tag . . . . . . . . . . . . . . . . . . . . 27 82 13.4 SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 28 83 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 84 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 85 15.1 Normative References . . . . . . . . . . . . . . . . . . . . 29 86 15.2 Informative References . . . . . . . . . . . . . . . . . . . 30 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31 88 A. Example GRUU Construction Algorithms . . . . . . . . . . . . . 31 89 A.1 Encrypted Instance ID and AOR . . . . . . . . . . . . . . 31 90 A.2 Hashed Indices . . . . . . . . . . . . . . . . . . . . . . 32 91 Intellectual Property and Copyright Statements . . . . . . . . 33 93 1. Introduction 95 The Session Initiation Protocol, RFC 3261 [1] is used to establish 96 and maintain a dialog between a pair of user agents in order to 97 manage a communications session. Messages within the dialog are sent 98 from one user agent to another using a series of proxy hops called 99 the route set, eventually being delivered to the remote target - the 100 user agent on the other side of the dialog. This remote target is a 101 SIP URI obtained from the value of the Contact header field in INVITE 102 requests and responses. 104 RFC 3261 mandates that a user agent populate the Contact header field 105 in INVITE requests and responses with a URI that is global (meaning 106 that it can be used from any element connected to the Internet), and 107 that routes to the user agent which inserted it. RFC 3261 also 108 mandates that this URI be valid for requests sent outside of the 109 dialog in which the Contact URI was inserted. 111 In practice, these requirements have proven very difficult to meet. 112 Endpoints often have only an IP address and not a hostname that is 113 present in DNS, and this IP address is frequently a private address, 114 because the client is behind a NAT. Techniques like the Simple 115 Traversal of UDP Through NAT (STUN) [15] can be used to obtain IP 116 addresses on the public Internet. However, many firewalls will 117 prohibit incoming SIP requests from reaching a client unless they 118 first pass through a proxy sitting in the DMZ of the network. Thus 119 URIs using STUN-obtained IP addresses often do not work. 121 Because of these difficulties, most clients have actually been 122 inserting URIs into the Contact header field of requests and 123 responses with the form sip:. These have the property of 124 routing to the client, but they are generally only reachable from the 125 proxy to which the user is directly connected. This limitation does 126 not prevent normal SIP calls from proceeding, since the user's proxy 127 can usually reach these private addresses, in addition to being 128 reachable over the public network. However, this issue has impacted 129 the ability of several other SIP mechanisms and applications to work 130 properly. 132 An example of such an application is call transfer [21], based on the 133 REFER method [7]. Another application is the usage of 134 endpoint-hosted conferences within the conferencing framework [17]. 135 Both of these mechanisms require the endpoint to be able to construct 136 a URI that not only routes to that user agent, but is usable by other 137 entities anywhere on the Internet as a target for new SIP requests. 139 This specification formally defines a type of URI called a Globally 140 Routable User Agent URI (GRUU) which has the properties of routing to 141 the UA and being reachable from anywhere. Furthermore, it defines a 142 new mechanism by which a client can obtain a GRUU from its SIP 143 provider, allowing it to use that URI in the Contact header fields of 144 its dialog forming requests and responses. Since the GRUU is 145 provided by the user's SIP provider, the GRUU properties can be 146 guaranteed by the provider. As a result, the various applications 147 which require the GRUU property, including transfer, presence, and 148 conferencing, can work reliably. 150 2. Terminology 152 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 153 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 154 and "OPTIONAL" are to be interpreted as described in RFC 2119 [5] and 155 indicate requirement levels for compliant implementations. 157 This specification also defines the following additional terms: 159 contact: The term "contact", when used in all lowercase, refers to a 160 URI that is bound to an AOR or GRUU by means of a registration. A 161 contact is usually a SIP URI, and is bound to the AOR and GRUU 162 through a REGISTER request by appearing as the value of the 163 Contact header field. 165 remote target: The term "remote target" refers to a URI that a user 166 agent uses to identify itself for receipt of subsequent requests 167 mid-dialog. A remote target is established by placing a URI in 168 the Contact header field of a dialog forming request or response. 170 Contact header field: The term "Contact header field", with a 171 capitalized C, refers to the header field which can appear in 172 REGISTER requests and responses, redirects, or in dialog creating 173 requests and responses. Depending on the semantics, the Contact 174 header field sometimes conveys a contact, and sometimes conveys a 175 remote target. 177 3. Defining a GRUU 179 A GRUU is a SIP URI which has three characteristics: 181 Global: It can be used by any UAC connected to the Internet. In that 182 regard, it is like an address-of-record (AOR) for a user. The 183 address-of-record for a user, sip:joe@example.com, is meant to be 184 used by anyone to reach that user. The same is true for a GRUU. 186 Routes to a Single Instance: It routes to a specific UA instance. In 187 that regard, it is unlike an address-of-record. When a request is 188 sent to a normal AOR which represents a user, routing logic is 189 applied in proxies to deliver the request to one or more UAs. 190 That logic can result in a different routing decision based on the 191 time-of-day, or the identity of the caller. However, when a 192 request is made to a GRUU, the routing logic is dictated by the 193 properties of a GRUU. The request has to be delivered to a very 194 specific UA instance. That UA instance has to be the same UA 195 instance for all requests sent to that GRUU. This does not mean 196 that a GRUU represents a fundamentally different type of URI; it 197 only means that the logic a proxy applies to a GRUU is going to 198 generally be simpler than that it applies to a normal AOR. 200 Long Lived: The GRUU persists for relatively long periods of time, 201 ideally being valid for the duration of existence of the AOR 202 itself. This property cannot be completely guaranteed, but 203 providers are supposed to do their best to make sure that a GRUU 204 remains viable indefinitely. 206 4. Use Cases 208 There are several use cases where the GRUU properties are truly 209 needed in order for a SIP application to operate. 211 4.1 REFER 213 Consider a blind transfer application [21]. User A is talking to 214 user B. User A wants to transfer the call to user C. So, user A 215 sends a REFER to user C. That REFER looks like, in part: 217 REFER sip:C@example.com SIP/2.0 218 From: sip:A@example.com;tag=99asd 219 To: sip:C@example.com 220 Refer-To: (URI that identifiers B's UA) 222 The Refer-To header field needs to contain a URI that can be used by 223 user C to place a call to user B. However, this call needs to route 224 to the specific UA instance which user B is using to talk to user A. 225 If it didn't, the transfer service would not execute properly. This 226 URI is provided to user A by user B. Because user B doesn't know who 227 user A will transfer the call to, the URI has to be usable by anyone. 228 Therefore, it needs to be a GRUU. 230 4.2 Conferencing 232 A similar need arises in conferencing [17]. In that framework, a 233 conference is described by a URI which identifies the focus of the 234 conference. The focus is a SIP UA that acts as the signaling hub for 235 the conference. Each conference participant has a dialog with the 236 focus. One case described in the framework is where a user A has 237 made a call to user B. User A puts user B on hold, and calls user C. 238 Now, user A has two separate dialogs for two separate calls - one to 239 user B, and one to user C. User A would like to conference them. To 240 do this, user A's user agent morphs itself into a focus. It sends a 241 re-INVITE or UPDATE [4] on both dialogs, and provides user B and user 242 C with an updated remote target that now holds the conference URI. 243 The URI in the Contact header field also has a callee capabilities 244 [11] parameter which indicates that this URI is a conference URI. 245 User A proceeds to mix the media streams received from user B and 246 user C. This is called an ad-hoc conference. 248 At this point, normal conferencing features can be applied. That 249 means that user B can send another user, user D, the conference URI, 250 perhaps in an email. User D can send an INVITE to that URI, and join 251 the conference. For this to work, the conference URI used by user A 252 in its re-INVITE or UPDATE has to be usable by anyone, and it has to 253 route to the specific UA instance of user A that is acting as the 254 focus. If it didn't, basic conferencing features would fail. 255 Therefore, this URI has to be a GRUU. 257 4.3 Presence 259 In a SIP-based presence [22] system, the Presence Agent (PA) 260 generates notifications about the state of a user. This state is 261 represented with the Presence Information Document Format (PIDF) 262 [20]. In a PIDF document, a user is represented by a series of 263 tuples, each of which describes the services that the user has. Each 264 tuple also has a URI in the element, which is a SIP URI 265 representing that device. A watcher can make a call to that URI, 266 with the expectation that the call is routed to the service whose 267 presence is represented in the tuple. 269 In some cases, the service represented by a tuple may exist on only a 270 single user agent associated with a user. In such a case, the URI in 271 the presence document has to route to that specific UA instance. 272 Furthermore, since the presence document could be used by anyone who 273 subscribes to the user, the URI has to be usable by anyone. As a 274 result, it has to be a GRUU. 276 It is interesting to note that the GRUU may need to be constructed by 277 a presence agent, depending on how the presence document is computed 278 by the server. 280 5. Overview of Operation 282 This section is tutorial in nature, and does not specify any 283 normative behavior. 285 This extension allows a UA to obtain a GRUU, and to use a GRUU. 286 These two mechanisms are separate, in that a UA can obtain a GRUU in 287 any way it likes, and use the mechanisms in this specification to use 288 them. Similarly, a UA can obtain a GRUU but never use it. This 289 specification defines two mechanisms for obtaining a GRUU - through 290 registrations, and through administrative operation. Only the former 291 requires protocol operations. 293 A UA can obtain a GRUU by generating a normal REGISTER request, as 294 specified in RFC 3261 [1]. This request contains a Supported header 295 field with the value "gruu", indicating to the registrar that the UA 296 supports this extension. The UA includes a "sip.instance" media 297 feature tag in the Contact header field of each contact for which a 298 GRUU is desired. This media feature tag contains a globally unique 299 ID that identifies the UA instance. If the domain that the user is 300 registering against also supports GRUU, the REGISTER responses will 301 contain the "gruu" parameter in each Contact header field. This 302 parameter contains a GRUU which the domain guarantees will route to 303 that UA instace. The GRUU is associated with the UA instace. Should 304 the client change its contact, but indicate that it represents the 305 same instance ID, the server would provide the same GRUU. 306 Furthermore, if the registration for the contact expires, and the UA 307 registers the contact at a later time with the same instance 308 identifier, the server would provide the same GRUU. 310 Since the GRUU is a URI like any other, it can be handed out by a UA 311 by placing it in any header field which can contain a URI. A UA will 312 normally place the GRUU into the Contact header field of dialog 313 creating requests and responses it generates; RFC 3261 mandates that 314 the Contact header field have the GRUU property, and this 315 specification provides a reliable way for a UA to obtain one. In 316 other words, clients can use the GRUU as a remote target. However, 317 since the remote target used by clients to date has typically not had 318 the GRUU properties, implementations have adapted their behaviors 319 (oftentimes in proprietary ways) to compensate. To facilitate a 320 transition away from these behaviors, it is necessary for a UA 321 receiving the message to know whether the remote target is a GRUU or 322 not. To make this determination, the UA looks for the presence of 323 the Supported header field in the request or response. If it is 324 present with a value of "gruu", it means that the remote target is a 325 GRUU. 327 When a UA uses a GRUU, it has the option of adding the "grid" URI 328 parameter to the GRUU. This parameter is opaque to the proxy server 329 handling the domain. However, when the server maps the GRUU to the 330 contact bound to it, the server will copy the grid parameter into the 331 contact. As a result, when the UA receives the request, the Request 332 URI will contain the grid parameter it placed in the corresponding 333 GRUU. 335 6. Creation of a GRUU 337 A GRUU is a URI that is created and maintained by a server 338 authoritative for the domain in which the GRUU resides. 339 Independently of whether the GRUU is created as a result of a 340 registration or some other means, a server maintains certain 341 information associated with the GRUU. This information, and its 342 relationship with the GRUU, is modeled in Figure 2. 344 +-----------+ +-----------+ 345 | | associated | | 346 | |1 with 1| | 347 | AOR |<----------------| GRUU | 348 | | | | 349 | | | | 350 +-----------+ +-----------+ 351 ^1 is ^^ |1 352 | bound // | 353 is| to// |associated 354 bound| // |with 355 to| // | 356 | // | 357 |0..n // V1 358 +-----------+ // +-----------+ 359 | | / 0..1 | | 360 | | | | 361 | contact |---------------->| Instance | 362 | |1 has 1| ID | 363 | | | | 364 +-----------+ +-----------+ 366 Figure 2 368 The instance ID plays a key role in this specification. It is an 369 indentifier, represented by a URI, that uniquely identifies a SIP 370 user agent amongst all other user agents associated with an AOR. The 371 instance ID allows a domain to create a GRUU that maps to the same UA 372 instance, even if the contact of that instance changes. Furthermore, 373 the instance ID allows a domain to enforce the restriction that a 374 specific UA instance can only be registered once against an AOR. 376 When elements compliant to this specification compare two instance 377 IDs for equality, the comparison is done using the equality rules for 378 the scheme associated with that URI. 380 A GRUU is associated, in a one-to-one fashion, with the an AOR and an 381 instance ID. This combination is referred to as an instance ID/AOR 382 pair. For each GRUU, there is one instance ID/AOR pair, and for each 383 instance ID/AOR pair, there is one GRUU. The instance ID/AOR pair 384 serves to uniquely identify a user agent instance servicing a 385 specific AOR. The AOR identifies a resource, such as a user or 386 service within a domain, and the instance ID identifies a specific UA 387 instance servicing requests for that resource. For each GRUU, both 388 the SIP and SIPS versions MUST exist. 390 It is important to understand that GRUU is associated with the 391 instance ID/AOR pair, not just the instance ID. For example, if a 392 user registered the contact sip:ua@pc.example.com to the AOR 393 sip:user@example.com, and included a +sip.instance="urn:foo:1" 394 parameter in the Contact header field, and also registered the same 395 contact with the same +sip.instance Contact header field parameter to 396 a second AOR, say sip:boss@example.com, each of those UA instances 397 would have a different GRUU, since they belong to different AORs. 399 In many ways, a GRUU is a parallel to an AOR. Just as a contact can 400 be bound to an AOR, a contact can be bound to a GRUU. However, any 401 number of contacts can be bound to an AOR; only zero or one can be 402 bound to a GRUU. The contact that is bound to the GRUU is always the 403 one that has the instance ID associated with that GRUU. If none of 404 the contacts bound to the AOR have the instance ID associated with 405 the GRUU, then there are no contacts bound to the GRUU. If a contact 406 should become registered to the AOR that has an instance ID equal to 407 the one associated with the GRUU, that contact also becomes bound to 408 the GRUU. If that contact should expire, it will no longer be bound 409 to the AOR, and similarly, it will no longer be bound to the GRUU. 410 The URI of the contact is irrelevant in determining whether it is 411 bound to a particular GRUU; only the instance ID and AOR are 412 important. 414 Because only a single contact with a particular instance ID can be 415 bound to an AOR at a time, no more than one contact can be bound to a 416 GRUU at a time. 418 This specification does not mandate a particular mechanism for 419 construction of the GRUU. Several example approaches are given in 420 Appendix A. However, the GRUU MUST exhibit the following properties: 422 o The domain part of the URI is an IP address present on the public 423 Internet, or, if it is a host name, the resolution procedures of 424 RFC 3263 [2], once applied, result in an IP address on the public 425 Internet. 427 o When a request is sent to the GRUU, it routes to a proxy server in 428 the same domain as that of the registrar. 430 o A proxy server in the domain can determine that the URI is a GRUU. 432 o When a proxy server in this domain receives a request sent to a 433 URI that is a GRUU, that URI MUST be translated to the contact 434 bound to that GRUU, if there is one. 436 Since the GRUU is associated with both the instance ID and AOR, for 437 any particular AOR there can be a potentially infinite number of 438 GRUU, one for each instance ID. Ideally, each of these GRUUs exist 439 in a domain for as long as the AOR exists in a domain. In this 440 context, the GRUU exists if the domain, upon receiving a request for 441 that GRUU, recognizes it as a GRUU, can determine the AOR and 442 instance ID associated with it, and translate the GRUU to a contact 443 if there is one with that instance ID currently registered. However, 444 for some mechanisms of GRUU construction, the GRUU for a particular 445 instance ID may not exist until a registration of a contact with that 446 instance ID occurs, and certain failure conditions may cause the GRUU 447 to be forgotten. As a result, it is RECOMMENDED that a GRUU exist 448 from the time a contact with an instance ID is first registered to an 449 AOR, until the time that the AOR is no longer valid in the domain. 450 This requirement is at RECOMMENDED strength, and not MUST, due solely 451 to the difficulty in meeting this requirement. 453 7. Obtaining a GRUU 455 A GRUU can be obtained in many ways. This document defines two - 456 through registrations, and through administrative operation. 458 7.1 Through Registrations 460 When a GRUU is associated with a user agent that comes and goes, and 461 therefore registers to the network to bind itself to an AOR, a GRUU 462 is provided to the user agent through SIP REGISTER messages. 464 7.1.1 User Agent Behavior 466 7.1.1.1 Generating a REGISTER Request 468 When a UA compliant to this specification generates a REGISTER 469 request (initial or refresh), it MUST include the Supported header 470 field in the request. The value of that header field MUST include 471 "gruu" as one of the option tags. This alerts the registrar for the 472 domain that the UA supports the GRUU mechanism. 474 Furthermore, for each contact for which the UA desires to obtain a 475 GRUU, the UA MUST include a "sip.instance" media feature tag as a UA 476 characteristic [11]. As described in [11], this media feature tag 477 will be encoded in the Contact header field as the "+sip.instance" 478 Contact header field parameter. The value of this parameter MUST be 479 a URN [10]. [11] defines equality rules for callee capabilities 480 parameters, and according to that specification, the "sip.instance" 481 media feature tag will be compared by case sensitive string 482 comparison. Those equality rules apply only to the generic usages 483 defined there and in the caller preferences specification [19]. When 484 the instance ID is used in this specification, it is effectively 485 "extracted" from the value in the "sip.instance" media feature tag, 486 and thus equality comparisons are performed using the rules for URN 487 equality specific to the scheme in the URN. If the element 488 performing the comparisons does not understand the URN scheme, it 489 performs the comparisons using the lexical equality rules defined in 490 RFC 2141. Lexical equality may result in two URN being considered 491 unequal when they are actually equal. In this specific usage of 492 URNs, the only element which provides the URN is the SIP UA instance 493 identified by that URN. As a result, the UA instance SHOULD provide 494 lexically equivalent URNs in each registration it generates. This is 495 likely to be normal behavior in any case; clients are not likely to 496 modify the value of the instance ID so that it remains functionally 497 equivalent to previous registrations, but lexigraphically different. 499 This specification makes no normative recommendation on the specific 500 URN that is to be used in the "+sip.instance" Contact header field 501 parameter. However, the URI MUST be selected such that the instance 502 can be certain that no other instance registering against the same 503 AOR would choose the same URI value. Usage of a URN is a MUST since 504 it provides a persistent and unique name for the UA instance, 505 allowing it to obtain the same GRUU over time. It also provides an 506 easy way to guarantee uniquess within the AOR. However, this 507 specification does not require a long-lived and persistent instance 508 identifier to properly function, and in some cases, there may be 509 cause to use an identifier with weaker temporal persistence. 511 One URN that readily meets the requirements of this specification is 512 the UUID URN [23], which allows for non-centralized computation of a 513 URN based on time, unique names (such as a MAC address) or a random 514 number generator. An example of a URN that would not meet the 515 requirements of this specification is the national bibliographic 516 number [16]. Since there is no clear relationship between an SIP UA 517 instance and a URN in this namespace, there is no way a selection of 518 a value can be performed that guarantees that another UA instance 519 doesn't choose the same value. 521 Besides the presence of the "gruu" option tag in the Supported header 522 field and the "+sip.instance" Contact header field parameter, the 523 REGISTER request is constructed identically to the case where this 524 extension was not understood. Specifically, the contact in the 525 REGISTER request SHOULD NOT contain the gruu Contact header field 526 parameter, and the contact URI itself SHOULD NOT contain the grid 527 parameter defined below. Any such parameters are ignored by the 528 registrar, as the UA cannot propose a GRUU for usage with the 529 contact. 531 If a UA wishes to guarantee that the request is not processed unless 532 the domain supports and uses this extension, it MAY include a Require 533 header field in the request with a value that contains the "gruu" 534 option tag. 536 7.1.1.2 Processing the REGISTER Response 538 If the response is a 2xx, each Contact header field that contained 539 the "+sip.instance" Contact header field parameter may also contain a 540 "gruu" parameter. This parameter contains a SIP or SIPS URI that 541 represents a GRUU corresponding to the UA instance that registered 542 the contact. The URI will be a SIP URI if the To header field in the 543 REGISTER request contained a SIP URI, else it will be a SIPS URI if 544 the To header field in the REGISTER request contained a SIPS URI. 545 Any requests sent to the GRUU URI will be routed by the domain to the 546 contact with that instance ID. The GRUU will not normally change in 547 subsequent 2xx responses to REGISTER. Indeed, even if the UA lets 548 the contact expire, when it re-registers it at any later time, the 549 registrar will normally provide the same GRUU for the same 550 address-of-record and instance ID. However, as discussed above, this 551 property cannot be completely guaranteed, as network failures may 552 make it impossible to provide an identifier that persists for all 553 time. As a result, a UA MUST be prepared to receive a different GRUU 554 for the same instance ID/AOR pair in a subsequent registration 555 response. 557 A non-2xx response to the REGISTER request has no impact on any 558 existing GRUU previously provided to the UA. Specifically, if a 559 previously successful REGISTER request provided the UA with a GRUU, a 560 subsequent failed request does not remove, delete, or otherwise 561 invalidate the GRUU. 563 7.1.2 Registrar Behavior 565 A registrar MAY create a GRUU for a particular instance ID/AOR pair 566 at any time. Of course, if a UA requests a GRUU in a registration, 567 and the registrar has not yet created one, it will need to do so in 568 order to respond to the registration request. However, the registrar 569 can create the GRUU in advance of any request from a UA. 571 A registrar MUST create both the SIP and SIPS versions of the GRUU, 572 such that if the GRUU exists, both URI are exist. 574 7.1.2.1 Processing a REGISTER Request 576 When a registrar compliant to this specification receives a REGISTER 577 request, it checks for the presence of the Require header field in 578 the request. If present, and if it contains the "gruu" option tag, 579 the registrar MUST follow the procedures in the remainder of this 580 section and Section 7.1.2.2 (that is, the procedures which result in 581 the creation of new GRUUs for contacts indicating an instance ID, and 582 the listing of GRUUs in the REGISTER response). If not present, but 583 a Supported header field was present with the "gruu" option tag, the 584 registrar SHOULD follow the procedures in the remainder of this 585 section and Section 7.1.2.2. If the Supported header field was not 586 present, or it if was present but did not contain the value "gruu", 587 the registrar SHOULD NOT follow the procedures in the remainder of 588 this section or Section 7.1.2.2. 590 As the registrar is processing the contacts in the REGISTER request 591 according to the procedures of step 7 in Section 10.3 of RFC 3261, 592 the registrar additionally checks whether each Contact header field 593 in the REGISTER message contains a "+sip.instance" header field 594 parameter. If it does, the registrar takes the value of that 595 parameter as an instance ID. The registrar checks to see if there is 596 any other contact bound to the same AOR with the same instance ID 597 (recall that equality is computed using URN equality for the scheme 598 in question if the scheme is known to the registrar, else using the 599 URN lexigraphic equality rules). If there is, that contact MUST be 600 removed as if it was de-registered by the REGISTER request, and 601 processing continues. 603 If the registrar had not yet created a GRUU for that instance ID/AOR 604 pair, it MUST do so at this time according to the procedures of 605 Section 6. If the contact contained a "gruu" Contact header field 606 parameter, it MUST be ignored by the registrar. A UA cannot suggest 607 or otherwise provide a GRUU to the registrar. 609 Registration processing then continues as defined in RFC 3261. If, 610 after that processing, that contact is bound to the AOR, it also 611 becomes bound to the GRUU associated with that instance ID/AOR pair. 612 If, after that processing, the contact was not bound to the AOR (due, 613 for example, to an expires value of zero), the contact is not bound 614 to the GRUU either. The registrar MUST store the instance ID along 615 with the contact. 617 When generating the 200 (OK) response to the REGISTER request, the 618 procedures of step 8 of Section 10.3 of RFC 3261 are followed. 619 Furthermore, for each Contact header field value placed in the 620 response, if the registrar has stored an instance ID associated with 621 that contact, that instance ID is returned as a Contact header field 622 parameter, and furthermore, the server MUST add a "gruu" Contact 623 header field parameter. The value of the gruu parameter is a quoted 624 string containing the URI that is the GRUU for the associated 625 instance ID/AOR pair. If the To header field in the REGISTER request 626 had contained a SIP URI, the SIP version of the GRUU is returned. If 627 the To header field in the REGISTER request had contained a SIPS URI, 628 the SIPS version of the GRUU is returned. 630 The REGISTER response does not need to contain a Require header field 631 with the value "gruu". This is because client is not required to 632 utilize the semantics of this specification to process a registration 633 response. 635 Note that handling of a REGISTER request containing a Contact header 636 field with value "*" and an expiration of 0 still retains the meaning 637 defined in RFC 3261 - all contacts, not just ones with a specific 638 instance ID, are deleted. This removes their binding to the AOR and 639 to any GRUU. 641 Note that the behavior described here means that a transient 642 registration of a contact with an instance ID will remove an existing 643 registered contact with that instance ID. In other words, if an AOR 644 has a contact registered to it with a particular instance ID, and a 645 REGISTER request arrives with a contact that differs from the current 646 registration, but with the same instance ID, and the contact in the 647 REGISTER request has an expires value of zero, after processing of 648 the REGISTER, no contacts with that instance ID will be registered to 649 the AOR (or to the GRUU). This provides a convenient way to 650 unregister any contact for a specific instance ID. 652 Inclusion of a GRUU in the "gruu" Contact header field parameter of a 653 REGISTER response is separate from the computation and storage of the 654 GRUU. It is possible that the registrar has computed a GRUU for one 655 UA, but a different UA that queries for the current set of 656 registrations doesn't understand GRUU. In that case, the REGISTER 657 response sent to that second UA would not contain the "gruu" Contact 658 header field parameter, even though the UA has a GRUU for that 659 contact. 661 7.1.2.2 Timing Out a Registration 663 When a registered contact expires, its binding to the AOR is removed 664 as normal. In addition, its binding to the GRUU is removed at the 665 same time. 667 7.2 Administratively 669 Administrative creation of GRUUs is useful when a UA instance is a 670 network server that is always available, and therefore doesn't 671 register to the network. Examples of such servers are voicemail 672 servers, application servers, and gateways. 674 There are no protocol operations required to administratively create 675 a GRUU. The proxy serving the domain is configured with the GRUU, 676 and with the contact it should be translated to. It is not strictly 677 necessary to also configure the instance ID and AOR, since the 678 translation can be done directly. However, they serve as a useful 679 tool for determining which resource and UA instance the GRUU is 680 supposed to map to. 682 In addition to configuring the GRUU and its associated contact in the 683 proxy serving the domain, the GRUU will also need to be configured 684 into the UA instance associated with the GRUU. 686 8. Using the GRUU 688 8.1 Sending a Message Containing a GRUU 690 A UA first obtains a GRUU using the procedures of Section 7, or by 691 other means outside the scope of this specification. 693 A UA can use the GRUU in the same way it would use any other SIP or 694 SIPS URI. However, a UA compliant to this specification MUST use a 695 GRUU when populating the Contact header field of dialog-creating 696 requests and responses. In other words, a UA compliant to this 697 specification MUST use its GRUU as its remote target. This includes 698 the INVITE request and its 2xx response, the SUBSCRIBE [6] request, 699 its 2xx response, the NOTIFY request, and the REFER [7] request and 700 its 2xx response. Similarly, in those requests and responses where 701 the GRUU is used as the remote target, the UA MUST include a 702 Supported header field that contains the option tag "gruu". However, 703 it is not necessary for a UA to know whether or not its peer in the 704 dialog supports this specification before using one as a remote 705 target. 707 When using the GRUU as a remote target, a UA MAY add the "grid" URI 708 parameter to the GRUU. This parameter MAY take on any value 709 permitted by the grammar for the parameter. Note that there are no 710 limitations on the size of this parameter. When a UA sends a request 711 to the GRUU, the proxy for the domain that owns the GRUU will 712 translate the GRUU in the Request-URI, replacing it with the URI 713 bound to that GRUU. However, it will retain the "grid" parameter 714 when this translation is performed. As a result, when the UA 715 receives the request, the Request-URI will contain the "grid" created 716 by the UA. This allows the UA to effectively manufacture an infinite 717 supply of GRUU, each of which differs by the value of the "grid" 718 parameter. When a UA receives a request that was sent to the GRUU, 719 it will be able to tell which GRUU was invoked by the "grid" 720 parameter. 722 An implication of this behavior is that all mid-dialog requests will 723 be routed through intermediate proxies. There will never be direct, 724 UA to UA signaling. It is anticipated that this limitation will be 725 addressed in future specifications. 727 Once a UA knows that the remote target provided by its peer is a 728 GRUU, it can use it in any application or SIP extension which 729 requires a globally routable URI to operate. One such example is 730 assisted call transfer. 732 8.2 Sending a Message to a GRUU 734 There is no new behavior associated with sending a request to a GRUU. 735 A GRUU is a URI like any other. When a UA receives a request or 736 response, it can know that the remote target is a GRUU if the request 737 or response had a Supported header field that included the value 738 "gruu". The UA can take the GRUU, and send a request to it, and then 739 be sure that it is delivered to the UA instance which sent the 740 request or response. 742 Since the instance ID is a callee capabilities parameter, a UA might 743 be tempted to send a request to the AOR of a user, and include an 744 Accept-Contact header field [19] which indicates a preference for 745 routing the request to a UA with a specific instance ID. Although 746 this would appear to have the same effect as sending a request to the 747 GRUU, it does not. The caller preferences expressed in the 748 Accept-Contact header field are just preferences, and do not work 749 with anywhere near the same reliability as GRUU. However, this 750 specification does not forbid a client from attempting such a 751 request, as there may be cases where the desired operation truly is a 752 preferential routing request. 754 8.3 Receiving a Request Sent to a GRUU 756 When a UAS receives a request sent to its GRUU, the incoming request 757 URI will be equal to the contact that was registered (through 758 REGISTER or some other action) by that UA instance. If the user 759 agent had previously handed out its GRUU with a grid parameter, the 760 incoming request URI may contain that parameter. This indicates to 761 the UAS that the request is being received as a result of a request 762 sent by the UAC to that GRUU/grid combination. This specification 763 makes no normative statements about when to use a grid parameter, or 764 what to do when receiving a request made to a GRUU/grid combination. 765 Generally, any differing behaviors are a matter of local policy. 767 It is important to note that, when a user agent receives a request, 768 and the request URI does not have a grid parameter, the user agent 769 cannot tell whether the request was sent to the AOR or to the GRUU. 770 As such, the UAS will process such requests identically. If a user 771 agent needs to differentiate its behavior based on these cases, it 772 will need to use a grid parameter. 774 8.4 Proxy Behavior 776 Proxy behavior is fully defined in Section 16 of RFC 3261. GRUU 777 processing impacts that processing in two places - request targeting 778 and record-routing. 780 8.4.1 Request Targeting 782 When a proxy server receives a request, and the proxy owns the domain 783 in the Request URI, and the proxy is supposed to access a Location 784 Service in order to compute request targets (as specified in Section 785 16.5 of RFC 3261 [1]), the proxy MUST check if the Request URI is a 786 GRUU created by that domain. 788 If the GRUU does not exist within the domain, the proxy MUST generate 789 a 404 (Not Found) response to the request. 791 If the GRUU does exist, handling of the GRUU proceeds as specified in 792 RFC 3261 Section 16. For GRUUs, the abstract location service 793 described in Section 16.5 is utilized, and a lookup of the GRUU will 794 provide either zero or one request targets. If a contact was bound 795 to the GRUU, the request target MUST be obtained by taking that 796 contact, and if the GRUU contained a "grid" URI parameter, adding 797 that parameter to the request target. If the grid was already 798 present in the contact bound to the GRUU, it is overwritten in this 799 process. If no contacts were bound to the GRUU, the lookup of the 800 GRUU in the abstract location service will result in zero target URI, 801 eventually causing the proxy to reject the request with a 480 802 (Temorarily Unavailable) response. 804 If the contact had been registered using a Path header field [3], 805 then that Path is used to construct the route set for reaching that 806 contact through the GRUU as well as through the AOR, using the 807 procedures specified in RFC 3327. 809 A proxy MAY apply other processing to the request, such as execution 810 of called party features. In particular, it is RECOMMENDED that 811 non-routing called party features, such as call logging and 812 screening, that are associated with the AOR are also applied to 813 requests for all GRUUs associated with that AOR. 815 A request sent to a GRUU request SHOULD NOT be redirected. In many 816 instances, a GRUU is used by a UA in order to assist in the traversal 817 of NATs and firewalls, and a redirection may prevent such a case from 818 working. 820 8.4.2 Record Routing 822 As described above, a user agent use its GRUU as a remote target. 823 This has an impact on the path taken by subsequent mid-dialog 824 requests. Depending on the desires of the proxies involved, this may 825 impact record route processing. 827 Two cases can be considered. The first is shown in Figure 3. In 828 this case, there is a single proxy in the user's domain. An incoming 829 INVITE request arrives for the users AOR (1) and is forwarded to the 830 user agent at its registered contact C1 (2). The proxy inserts a 831 Record-Route header field into the proxied reuqest, with a value of 832 R1. The user agent generates a 200 OK to the request, using its GRUU 833 G1 as the remote target. 835 (1) + (2): initial INVITE 836 (2) + (3): mid-dialog request 838 (1) +-----------+ (2) +-----------+ 839 ------>| |--------------->| | 840 | | | | 841 (3) | Proxy | (4) | User | 842 ------>| |--------------->| Agent | 843 | | | | 844 +-----------+ +-----------+ 846 Figure 3 848 When a mid-dialog request shows up destined for the user agent 849 (message 3), it will arrive at the proxy in the following form: 851 INVITE G1 852 Route: R1 854 Since the top Route header field value identifies the proxy, the 855 proxy removes it. As there are no more Route header field values, 856 the proxy processes the request URI. However, the request URI is a 857 GRUU, and is therefore a domain under the control of the proxy. The 858 proxy will need to perform the processing of Section 8.4.1, which 859 will result in the translation of the GRUU into the contact C1, 860 followed by transmission of the request to the user agent (message 861 4). 863 This sequence of processing in the proxy is somewhat unusual, in that 864 mid-dialog requests (that is, requests with a Route header field that 865 a proxy inserted as a result of a Record-Route operation) do not 866 normally cause a proxy to have to invoke a location service to 867 process the request URI. It is for this reason that this is called 868 out here. 870 The previous case assumed that there was a single proxy in the 871 domain. In more complicated cases, there can be two or more proxies 872 within a domain on the initial request path. This is shown in Figure 873 5. In this figure, there is a home proxy, to which requests targeted 874 to the AOR are sent. The home proxy executes the abstract location 875 service and runs user features. The edge proxy acts as the outbound 876 proxy for users, performs authentication, manages TCP/TLS connections 877 to the client, and does other functions associated with the 878 transition from the provider proxy network to the client. This 879 specific division of responsibilities between home and edge proxy is 880 just for the purposes of illustration; the discussion applies to a 881 disaggregation of proxy logic into any number of proxies. In such a 882 configuration, registrations from the user agent would pass through 883 the edge proxy, which would insert a Path header field [3] for 884 itself. 886 (1) + (2) + (3): initial INVITE 887 (4) - (9): mid-dialog request 889 (1) +-----------+ (2) +-----------+ (3) +-----------+ 890 ---->| |------->| |-------->| | 891 (4) | | (5) | | | | 892 ---->| Home |------->| Edge | | User | 893 | Proxy | (7) | Proxy | (8) | Agent | 894 +-->| |------->| |-------->| | 895 | +-----------+ +-----------+ +-----------+ 896 | | 897 | | 898 +------------------------------+ 899 (6) 901 Figure 5 903 When an incoming request arrives for the AOR (message 1), the home 904 proxy would look it up, discover the registered contact and Path, and 905 then send the request to the edge proxy as a result of the Route 906 header field inserted with the Path value. The home proxy record 907 routes with the URI H1. The edge proxy would forward the request to 908 the request URI (which points to the client), and insert a 909 Record-Route header field value with the URI E1 (message 2). This 910 request is accepted by the user agent, which inserts its GRUU G1 as 911 the remote target. 913 When the peer in the dialog sends a mid-dialog request, it will have 914 the following form: 916 INVITE G1 917 Route: H1, E1 919 This request will arrive at the home proxy (due to H1 in the Route 920 header field) (message 4). The home proxy will forward it to the 921 edge proxy (due to E1 in the Route header field) (message 5). The 922 edge proxy, seeing no more Route header field values, sends the 923 request to the Request URI. This is a GRUU, and like an AOR, will 924 route to the home proxy. This causes the request to loop back around 925 (message 6). The home proxy performs the GRUU processing of Section 926 8.4.1, causing the request to be forwarded to the edge proxy a second 927 time (this time, as a result of a Route header field value obtained 928 from the Path header in the registration) (message 7), and then 929 delivered to the client (message 8). 931 While this flow works, it is highly inefficient, as it causes each 932 mid-dialog request to spiral route. If this behavior is not 933 desirable, it is RECOMMENDED that, when the response to the initial 934 mid-dialog request arrives at the edge proxy, the edge proxy inspect 935 the response to see if it contains a Supported header field that 936 includes the value "gruu". If it does, the edge proxy knows that the 937 UA inserted its GRUU as the remote target. In such a case, there is 938 no need for the proxy to retain its record-route in the response. 939 The proxy MAY remove its record-route value from the 200 OK response 940 in this case. This will result in a different route set as seen by 941 the caller and callee; the callee (which is the user agent in the 942 figure) will have a route set entry for the edge proxy, while the 943 caller will not. 945 In such a case, a mid-dialog request that arrives at the home proxy 946 will be of the form: 948 INVITE G1 949 Route: H1 951 This does the "right thing" and causes the request to be routed from 952 the home proxy to the edge proxy to the client, without the 953 additional spiral. 955 9. Grammar 957 This specification defines two new Contact header field parameters, 958 gruu and +sip.instance, and a new URI parameter, grid. The grammar 959 for string-value is obtained from [11], and the grammar for uric is 960 defined in RFC 3986 [9]. 962 contact-params = c-p-q / c-p-expires / c-p-gruu / cp-instance 963 / contact-extension 964 c-p-gruu = "gruu" EQUAL DQUOTE SIP-URI DQUOTE 965 cp-instance = "+sip.instance" EQUAL LDQUOT instance-val RDQUOT 966 uri-parameter = transport-param / user-param / method-param 967 / ttl-param / maddr-param / lr-param / grid-param 968 / other-param 969 grid-param = "grid=" pvalue ; defined in RFC3261 970 instance-val = *uric ; defined in RFC 2396 972 10. Requirements 974 This specification was created in order to meet the following 975 requirements: 977 REQ 1: When a UA invokes a GRUU, it MUST cause the request to be 978 routed to the specific UA instance to which the GRUU refers. 980 REQ 2: It MUST be possible for a GRUU to be invoked from anywhere on 981 the Internet, and still cause the request to be routed 982 appropriately. That is, a GRUU MUST NOT be restricted to use 983 within a specific addressing realm. 985 REQ 3: It MUST be possible for a GRUU to be constructed without 986 requiring the network to store additional state. 988 REQ 4: It MUST be possible for a UA to obtain a multiplicity of 989 GRUUs, each one of which routes to that UA instance. This is 990 needed to support ad-hoc conferencing, for example, where a a UA 991 instance needs a different URI for each conference it is hosting. 993 REQ 5: When a UA receives a request sent to a GRUU, it MUST be 994 possible for the UA to know the GRUU which was used to invoke the 995 request. This is necessary as a consequence of requirement 4. 997 REQ 6: It MUST be possible for a UA to add opaque content to a GRUU, 998 which is not interpreted or altered by the network, and used only 999 by the UA instance to whom the GRUU refers. This provides a basic 1000 cookie type of functionality, allowing a UA to build a GRUU with 1001 state embedded within it. 1003 REQ 7: It MUST be possible for a proxy to execute services and 1004 features on behalf of a UA instace represented by a GRUU. As an 1005 example, if a user has call blocking features, a proxy may want to 1006 apply those call blocking features to calls made to the GRUU in 1007 addition to calls made to the user's AOR. 1009 REQ 8: It MUST be possible for a UA in a dialog to inform its peer of 1010 its GRUU, and for the peer to know that the URI represents a GRUU. 1011 This is needed for the conferencing and dialog reuse applications 1012 of GRUUs, where the URIs are transferred within a dialog. 1014 REQ 9: When transferring a GRUU per requirement 8, it MUST be 1015 possible for the UA receiving the GRUU to be assured of its 1016 integrity and authenticity. 1018 REQ 10: It MUST be possible for a server, authoritative for a domain, 1019 to construct a GRUU which routes to a UA instace bound to an AOR 1020 in that domain. In other words, the proxy can construct a GRUU 1021 too. This is needed for the presence application. 1023 11. Example Call Flow 1025 The following call flow shows a basic registration and call setup, 1026 followed by a subscription directed to the GRUU. It then shows a 1027 failure of the callee, followed by a re-registration. 1029 Caller Proxy Callee 1030 | |(1) REGISTER | 1031 | |<--------------------| 1032 | |(2) 200 OK | 1033 | |-------------------->| 1034 |(3) INVITE | | 1035 |-------------------->| | 1036 | |(4) INVITE | 1037 | |-------------------->| 1038 | |(5) 200 OK | 1039 | |<--------------------| 1040 |(6) 200 OK | | 1041 |<--------------------| | 1042 |(7) ACK | | 1043 |-------------------->| | 1044 | |(8) ACK | 1045 | |-------------------->| 1046 |(9) SUBSCRIBE | | 1047 |-------------------->| | 1048 | |(10) SUBSCRIBE | 1049 | |-------------------->| 1050 | |(11) 200 OK | 1051 | |<--------------------| 1052 |(12) 200 OK | | 1053 |<--------------------| | 1054 | |(13) NOTIFY | 1055 | |<--------------------| 1056 |(14) NOTIFY | | 1057 |<--------------------| | 1058 |(15) 200 OK | | 1059 |-------------------->| | 1060 | |(16) 200 OK | 1061 | |-------------------->| 1062 | | |Crashes, Reboots 1063 | |(17) REGISTER | 1064 | |<--------------------| 1065 | |(18) 200 OK | 1066 | |-------------------->| 1068 The Callee supports the GRUU extension. As such, its REGISTER (1) 1069 looks like: 1071 REGISTER sip:example.com SIP/2.0 1072 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 1073 Max-Forwards: 70 1074 From: Callee ;tag=a73kszlfl 1075 Supported: gruu 1076 To: Callee 1077 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 1078 CSeq: 1 REGISTER 1079 Contact: 1080 ;+sip.instance="" 1081 Content-Length: 0 1083 The REGISTER response would look like: 1085 SIP/2.0 200 OK 1086 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 1087 From: Callee ;tag=a73kszlfl 1088 To: Callee ;tag=b88sn 1089 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 1090 CSeq: 1 REGISTER 1091 Contact: 1092 ;gruu="sip:hha9s8d=-999a@example.com" 1093 ;+sip.instance="" 1094 ;expires=3600 1095 Content-Length: 0 1097 Note how the Contact header field in the REGISTER response contains 1098 the gruu parameter with the URI sip:hha9s8d=-999a@example.com. This 1099 represents a GRUU that translates to the contact 1100 sip:callee@192.0.2.1. 1102 The INVITE from the caller is a normal SIP INVITE. The 200 OK 1103 generated by the callee (message 5), however, now contains a GRUU as 1104 the remote target. The UA has also chosen to include a grid URI 1105 parameter into the GRUU. 1107 SIP/2.0 200 OK 1108 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8 1109 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a 1110 From: Caller ;tag=n88ah 1111 To: Callee ;tag=a0z8 1112 Call-ID: 1j9FpLxk3uxtma7@host.example.com 1113 CSeq: 1 INVITE 1114 Supported: gruu 1115 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 1116 Contact: 1117 Content-Length: -- 1118 Content-Type: application/sdp 1120 [SDP Not shown] 1122 At some point later in the call, the caller decides to subscribe to 1123 the dialog event package [18] at that specific UA. To do that, it 1124 generates a SUBSCRIBE request (message 9), but directs it towards the 1125 remote target, which is a GRUU: 1127 SUBSCRIBE sip:hha9s8d=-999a@example.com;grid=99a SIP/2.0 1128 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 1129 From: Caller ;tag=kkaz- 1130 To: Callee 1131 Call-ID: faif9a@host.example.com 1132 CSeq: 2 SUBSCRIBE 1133 Supported: gruu 1134 Event: dialog 1135 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 1136 Contact: 1137 Content-Length: 0 1139 In this example, the caller itself supports the GRUU extension, and 1140 is using its own GRUU to populate its remote target. 1142 This request is routed to the proxy, which proceeds to perform a 1143 location lookup on the request URI. It is translated into the 1144 contact for that instance, and then proxied there (message 10 below). 1145 Note how the grid parameter is maintained. 1147 SUBSCRIBE sip:callee@192.0.2.1;grid=99a SIP/2.0 1148 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK9555 1149 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 1150 From: Caller ;tag=kkaz- 1151 To: Callee 1152 Call-ID: faif9a@host.example.com 1153 CSeq: 2 SUBSCRIBE 1154 Supported: gruu 1155 Event: dialog 1156 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK 1157 Contact: 1158 Content-Length: 0 1160 At some point after message 16 is received, the callee's machine 1161 crashes and recovers. It obtains a new IP address, 192.0.2.2. 1162 Unaware that it had previously had an active registration, it creates 1163 a new one (message 17 below). Notice how the instance ID remains the 1164 same, as it persists across reboot cycles: 1166 REGISTER sip:example.com SIP/2.0 1167 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba 1168 Max-Forwards: 70 1169 From: Callee ;tag=ha8d777f0 1170 Supported: gruu 1171 To: Callee 1172 Call-ID: hf8asxzff8s7f@192.0.2.2 1173 CSeq: 1 REGISTER 1174 Contact: 1175 ;+sip.instance="" 1176 Content-Length: 0 1178 The registrar notices that a different contact, sip:callee@192.0.2.1, 1179 is already associated with the same instance ID. Thus, it removes 1180 that old contact, and proceeds to register the new one, generating 1181 the following response: 1183 SIP/2.0 200 OK 1184 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba 1185 From: Callee ;tag=ha8d777f0 1186 To: Callee ;tag=99f8f7 1187 Call-ID: hf8asxzff8s7f@192.0.2.2 1188 CSeq: 1 REGISTER 1189 Contact: 1190 ;+sip.instance="" 1191 ;expires=3600 1192 Content-Length: 0 1194 12. Security Considerations 1196 GRUUs do not provide a solution for privacy. In particular, since 1197 the GRUU does not change during the lifetime of a registration, an 1198 attacker could correlate two calls as coming from the same source, 1199 which in and of itself reveals information about the caller. 1200 Furthermore, GRUUs do not address other aspects of privacy, such as 1201 the addresses used for media transport. For a discussion of how 1202 privacy services are provided in SIP, see RFC 3323 [14]. 1204 It is important for a UA to be assured of the integrity of a GRUU 1205 when it is given one in a REGISTER response. If the GRUU is tampered 1206 with by an attacker, the result could be denial of service to the UA. 1207 As a result, it is RECOMMENDED that a UA use the SIPS URI scheme in 1208 the Request-URI when registering. 1210 13. IANA Considerations 1212 This specification defines a new Contact header field parameter, a 1213 SIP URI parameter, a media feature tag and a SIP option tag. 1215 13.1 Header Field Parameter 1217 This specification defines a new header field parameter, as per the 1218 registry created by [12]. The required information is as follows: 1220 Header field in which the parameter can appear: Contact 1222 Name of the Parameter gruu 1224 RFC Reference RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1225 RFC number of this specification.]] 1227 13.2 URI Parameter 1229 This specification defines a new SIP URI parameter, as per the 1230 registry created by [13]. 1232 Name of the Parameter grid 1234 RFC Reference RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1235 RFC number of this specification.]] 1237 13.3 Media Feature Tag 1239 This section registers a new media feature tag, per the procedures 1240 defined in RFC 2506 [8]. The tag is placed into the sip tree, which 1241 is defined in [11]. 1243 Media feature tag name: sip.instance 1245 ASN.1 Identifier: New assignment by IANA. 1247 Summary of the media feature indicated by this tag: This feature tag 1248 contains a string containing a URI, and ideally a URN, that 1249 indicates a unique identifier associated with the UA instance 1250 registering the Contact. 1252 Values appropriate for use with this feature tag: String. 1254 The feature tag is intended primarily for use in the following 1255 applications, protocols, services, or negotiation mechanisms: This 1256 feature tag is most useful in a communications application, for 1257 describing the capabilities of a device, such as a phone or PDA. 1259 Examples of typical use: Routing a call to a specific device. 1261 Related standards or documents: RFC XXXX [[Note to IANA: Please 1262 replace XXXX with the RFC number of this specification.]] 1264 Security Considerations: This media feature tag can be used in ways 1265 which affect application behaviors. For example, the SIP caller 1266 preferences extension [19] allows for call routing decisions to be 1267 based on the values of these parameters. Therefore, if an 1268 attacker can modify the values of this tag, they may be able to 1269 affect the behavior of applications. As a result of this, 1270 applications which utilize this media feature tag SHOULD provide a 1271 means for ensuring its integrity. Similarly, this feature tag 1272 should only be trusted as valid when it comes from the user or 1273 user agent described by the tag. As a result, protocols for 1274 conveying this feature tag SHOULD provide a mechanism for 1275 guaranteeing authenticity. 1277 13.4 SIP Option Tag 1279 This specification registers a new SIP option tag, as per the 1280 guidelines in Section 27.1 of RFC 3261. 1282 Name: gruu 1284 Description: This option tag is used to identify the Globally 1285 Routable User Agent URI (GRUU) extension. When used in a 1286 Supported header, it indicates that a User Agent understands the 1287 extension, and has included a GRUU in the Contact header field of 1288 its dialog initiating requests and responses. When used in a 1289 Require header field of a REGISTER request, it indicates that the 1290 registrar should assign a GRUU to the Contact URI. 1292 14. Acknowledgements 1294 The author would like to thank Rohan Mahy, Paul Kyzivat, Alan 1295 Johnston, and Cullen Jennings for their contributions to this work. 1297 15. References 1299 15.1 Normative References 1301 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1302 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1303 Session Initiation Protocol", RFC 3261, June 2002. 1305 [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1306 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1308 [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 1309 Extension Header Field for Registering Non-Adjacent Contacts", 1310 RFC 3327, December 2002. 1312 [4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1313 Method", RFC 3311, October 2002. 1315 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1316 Levels", BCP 14, RFC 2119, March 1997. 1318 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1319 Notification", RFC 3265, June 2002. 1321 [7] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1322 Method", RFC 3515, April 2003. 1324 [8] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag 1325 Registration Procedure", BCP 31, RFC 2506, March 1999. 1327 [9] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1328 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 1329 January 2005. 1331 [10] Moats, R., "URN Syntax", RFC 2141, May 1997. 1333 [11] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User 1334 Agent Capabilities in the Session Initiation Protocol (SIP)", 1335 RFC 3840, August 2004. 1337 [12] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1338 Header Field Parameter Registry for the Session Initiation 1339 Protocol (SIP)", BCP 98, RFC 3968, December 2004. 1341 [13] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1342 Uniform Resource Identifier (URI) Parameter Registry for the 1343 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 1344 2004. 1346 15.2 Informative References 1348 [14] Peterson, J., "A Privacy Mechanism for the Session Initiation 1349 Protocol (SIP)", RFC 3323, November 2002. 1351 [15] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 1352 Simple Traversal of User Datagram Protocol (UDP) Through 1353 Network Address Translators (NATs)", RFC 3489, March 2003. 1355 [16] Hakala, J., "Using National Bibliography Numbers as Uniform 1356 Resource Names", RFC 3188, October 2001. 1358 [17] Rosenberg, J., "A Framework for Conferencing with the Session 1359 Initiation Protocol", 1360 draft-ietf-sipping-conferencing-framework-03 (work in 1361 progress), October 2004. 1363 [18] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for 1364 the Session Initiation Protocol (SIP)", 1365 draft-ietf-sipping-dialog-package-05 (work in progress), 1366 November 2004. 1368 [19] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller 1369 Preferences for the Session Initiation Protocol (SIP)", RFC 1370 3841, August 2004. 1372 [20] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 1373 J. Peterson, "Presence Information Data Format (PIDF)", RFC 1374 3863, August 2004. 1376 [21] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 1377 Control - Transfer", draft-ietf-sipping-cc-transfer-03 (work in 1378 progress), October 2004. 1380 [22] Rosenberg, J., "A Presence Event Package for the Session 1381 Initiation Protocol (SIP)", RFC 3856, August 2004. 1383 [23] Mealling, M., "A UUID URN Namespace", 1384 draft-mealling-uuid-urn-05 (work in progress), January 2005. 1386 Author's Address 1388 Jonathan Rosenberg 1389 Cisco Systems 1390 600 Lanidex Plaza 1391 Parsippany, NJ 07054 1392 US 1394 Phone: +1 973 952-5000 1395 EMail: jdrosen@cisco.com 1396 URI: http://www.jdrosen.net 1398 Appendix A. Example GRUU Construction Algorithms 1400 The mechanism for constructing a GRUU is not subject to 1401 specification. This appendix provides two examples that can be used 1402 by a registar. Others are, of course, permitted, as long as they 1403 meet the constraints defined for a GRUU. 1405 A.1 Encrypted Instance ID and AOR 1407 In many cases, it will be desirable to construct the GRUU in such a 1408 way that it will not be possible, based on inspection of the URI, to 1409 determine the Contact URI that the GRUU translates to. It may also 1410 be desirable to construct it so that it will not be possible to 1411 determine the instance ID/AOR pair associated with the GRUU. Whether 1412 or not a GRUU should be constructed with this property is a local 1413 policy decision. 1415 With these rules, it is possible to construct a GRUU without 1416 requiring the maintenance of any additional state. To do that, the 1417 URI would be constructed in the following fashion: 1419 user-part = "GRUU" + BASE64(E(K, (salt + " " + AOR + " " + 1420 instance ID))) 1422 Where E(K,X) represents a suitable encryption function (such as AES 1423 with 128 bit keys) with key K applied to data block X, and the "+" 1424 operator implies concatenation. The single space (" ") between 1425 components is used as a delimeter, so that the components can easily 1426 be extracted after decryption. Salt represents a random string that 1427 prevents a client from obtaining pairs of known plaintext and 1428 ciphertext. A good choice would be at least 128 bits of randomness 1429 in the salt. 1431 The benefit of this mechanism is that a server need not store 1432 additional information on mapping a GRUU to its corresponding 1433 contact. The user part of the GRUU contains the instance ID and AOR. 1434 Assuming that the domain stores registrations in a database indexed 1435 by the AOR, the proxy processing the GRUU would look up the AOR, 1436 extract the currently registered contacts, and find the one matching 1437 the instance ID encoded in the request URI. The contact whose 1438 instance ID is that instance ID is then used as the translated 1439 version of the GRUU. Encryption is needed to prevent attacks whereby 1440 the server is sent requests with faked GRUU, causing the server to 1441 direct requests to any named URI. Even with encryption, the proxy 1442 should validate the user part after decryption. In particular, the 1443 AOR should be managed by the proxy in that domain. Should a UA send 1444 a request with a fake GRUU, the proxy would decrypt and then discard 1445 it because there would be no URI or an invalid URI inside. 1447 While this approach has many benefits, it has the drawback of 1448 producing fairly long GRUUs. The approach in the following section 1449 produces smaller results, at the cost of additional structures in the 1450 database. 1452 A.2 Hashed Indices 1454 As an alternative approach, the server can construct the GRUU by 1455 computing a cryptographic hash of the AOR and instance ID, taking 64 1456 bits of the result, and placing a string representation of those 64 1457 bits into the user part of the URI. 1459 When a GRUU is created through registration or administrative action, 1460 the server computes this hash and stores the hash in the database. 1461 This hash acts the primary key, with the columns of the table 1462 providing the instance ID, AOR and contact. When the registration is 1463 deleted, the corresponding row from the table is removed. When a 1464 request arrives to a proxy, the user part of the URI is looked up in 1465 the database, and the Contact, AOR and instance ID can be extracted. 1467 This approach produces GRUUs of relatively short length. However, it 1468 requires additional structures to be created and stored in a database 1469 that would be used by the registrar (at least, new structures are 1470 needed for efficient operation). However, it does not require the 1471 registrar to store anything for longer than the duration of the 1472 registration. 1474 OPEN ISSUE: this algorithm doesn't really work, since the proxy has 1475 no way to know whether a GRUU doesn't exist or just doesnt have 1476 contacts registered against it. Does it matter? 1478 Intellectual Property Statement 1480 The IETF takes no position regarding the validity or scope of any 1481 Intellectual Property Rights or other rights that might be claimed to 1482 pertain to the implementation or use of the technology described in 1483 this document or the extent to which any license under such rights 1484 might or might not be available; nor does it represent that it has 1485 made any independent effort to identify any such rights. Information 1486 on the procedures with respect to rights in RFC documents can be 1487 found in BCP 78 and BCP 79. 1489 Copies of IPR disclosures made to the IETF Secretariat and any 1490 assurances of licenses to be made available, or the result of an 1491 attempt made to obtain a general license or permission for the use of 1492 such proprietary rights by implementers or users of this 1493 specification can be obtained from the IETF on-line IPR repository at 1494 http://www.ietf.org/ipr. 1496 The IETF invites any interested party to bring to its attention any 1497 copyrights, patents or patent applications, or other proprietary 1498 rights that may cover technology that may be required to implement 1499 this standard. Please address the information to the IETF at 1500 ietf-ipr@ietf.org. 1502 Disclaimer of Validity 1504 This document and the information contained herein are provided on an 1505 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1506 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1507 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1508 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1509 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1510 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1512 Copyright Statement 1514 Copyright (C) The Internet Society (2005). This document is subject 1515 to the rights, licenses and restrictions contained in BCP 78, and 1516 except as set forth therein, the authors retain all their rights. 1518 Acknowledgment 1520 Funding for the RFC Editor function is currently provided by the 1521 Internet Society.