idnits 2.17.1 draft-mahy-sipping-herfp-fix-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 643. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2006) is 6619 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) == Unused Reference: '4' is defined on line 517, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-06 -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '6') (Obsoleted by RFC 6665) -- Duplicate reference: draft-rosenberg-sip-unify, mentioned in '8', was also mentioned in '7'. Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG R. Mahy 3 Internet-Draft Plantronics 4 Expires: September 6, 2006 March 5, 2006 6 A Solution to the Heterogeneous Error Response Forking Problem (HERFP) 7 in the Session Initiation Protocol (SIP) 8 draft-mahy-sipping-herfp-fix-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 6, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 The SIP protocol defines a role for proxy servers which can forward 42 requests to multiple contacts associated with a specific resource or 43 person. While each of these contacts is expected to send a response 44 of some kind, responses for each branch are not necessarily sent back 45 to the original requester. The proxy server forwards only the "best" 46 final response back to the original request. This behavior causes a 47 situation known as the Herterogeneous Error Response Forking Problem 48 (HERFP) in which the original requester has no opportunity to see or 49 fix a variety of potentially repairable errors. This document 50 describes a backwards compatible solution to the HERFP problem for 51 INVITE transactions. 53 Table of Contents 55 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Overview of Solution . . . . . . . . . . . . . . . . . . . . 5 58 4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1 Handling repairable errors . . . . . . . . . . . . . . . . 6 60 4.2 Receiving subsequent requests with the single-branch 61 property . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 5. User Agent Client Behavior . . . . . . . . . . . . . . . . . 9 63 6. User Agent Server Behavior . . . . . . . . . . . . . . . . . 10 64 7. Security Considerations . . . . . . . . . . . . . . . . . . 10 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 66 8.1 The "herf" option-tag . . . . . . . . . . . . . . . . . . 11 67 8.2 The "130 Repairable Error" response-code . . . . . . . . . 11 68 8.3 The "DECLINE" method . . . . . . . . . . . . . . . . . . . 11 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 10.1 Normative References . . . . . . . . . . . . . . . . . . 12 72 10.2 Informational References . . . . . . . . . . . . . . . . 12 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 74 A. Historical Context . . . . . . . . . . . . . . . . . . . . . 13 75 Intellectual Property and Copyright Statements . . . . . . . 15 77 1. Conventions 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC-2119 [3]. 83 2. Background 85 The Session Initiation Protocol (SIP) [1] defines several logical 86 roles, including proxy servers (which forward requests toward their 87 destination), and User Agents (which originate and respond to 88 requests). In addition to transparently forwarding requests, SIP 89 proxy servers can also "fork" requests to multiple User Agent Servers 90 (UAS) if the proxy is authoritative for the domain portion of the 91 Request URI. When forking, proxies forward the same request to 92 multiple contacts which typically have registered as instances of a 93 particular user or service. A proxy can forward requests 94 simultaneously (parallel forking), in series (serial forking), or in 95 combination. As a request is forwarded to a set of contacts, each 96 UAS that receives the request is expected to send a response. 98 When a proxy forks, it first builds a "target set", a list of User 99 Agent Servers to whom requests will be forwarded. Once forwarding a 100 request, the proxy collects responses from each UAS in a "response 101 context". For INVITE requests, proxies immediately forward all 102 provisional responses and 200-class (success) final responses back to 103 the UAC. For other final responses (regardless of the method of the 104 request), only a single "best" response is sent back to the UAC. The 105 proxy has to delay sending the final response until all branches have 106 completed. This is especially problematic for INVITE transactions, 107 since they can theoretically pend for several minutes, after which 108 most humans have given up attempting communication. In addition, 109 many common SIP error responses are automatically repairable and are 110 used extensively to allow User Agents to negotiate capabilities. 111 These repairable errors are often completely lost if another User 112 Agent finds the request acceptable or returns a "better" error 113 response. 114 For non-INVITE requests (for example, a SUBSCRIBE request) 115 provisional responses are practically non-existent and only one 116 final response is sent, even if multiple branches returned a 200 117 response. The SIP events framework (RFC 3265 [6]) effectively 118 deals with HERFP by using NOTIFY requests to convey the success or 119 failure of a SUBSCRIBE request. The single response to a 120 SUBSCRIBE might even arrive after the corresponding NOTIFY request 121 making it effectively redundant. Consequently, this document only 122 addresses HERFP for INVITE transactions. Sending requests other 123 than INVITE and SUBSCRIBE in a manner which causes them to fork is 124 contraindicated. 126 To illustrate a simple case of HERFP, the UAC below sends a request 127 which includes a body format which is understood by UAS2, but not by 128 UAS1. For example, the UAC might have used a multipart/mixed with a 129 session description and an optional image or sound. UAC1 does not 130 support multipart/mixed, so it returns a 415 response. The UAC can 131 trivially repair this 415 response by resending the request with just 132 the session description. Unfortunately, the proxy has to wait until 133 all branches generate a final response before forwarding the best 134 response. Since the request was acceptable to UAS2, the proxy waits 135 for that branch to finish before it can repair the error. In many 136 cases, the proxy will wait for a long enough amount of time that the 137 human operating the UAC gives up and abandons the call. 139 UAC Proxy UAS1 UAS2 140 |INVITE | | | 141 |---------->| | | 142 | | INVITE | | 143 | |---------->| | 144 | | INVITE | | 145 | |-------------------->| 146 | | 415 | | 147 | |<----------| | 148 | | ACK | | 149 | |---------->| | 150 | | 180 | | 151 | 180 |<--------------------| 152 |<----------| time passes... | 153 | | | | 154 | CANCEL | | | 155 |---------->| | | 156 | 200 OK | | | 157 |<----------| | | 158 | | CANCEL | | 159 | |-------------------->| 160 | | 200 OK | 161 | |<--------------------| 162 | | 487 | | 163 | |<--------------------| 164 | | ACK | | 165 | |-------------------->| 166 | 415 | | | 167 |<----------| | | 168 | ACK | | | 169 |---------->| | | 171 3. Overview of Solution 173 HERFP was first described in late 2001. It has remained one of the 174 most challenging problems remaining for the SIP protocol. To 175 effectively address the problem, it is useful to examine the overall 176 goals for a solution to HERFP. 177 o Convey the semantics of repairable error responses directly to the 178 sender of a (dialog-forming) INVITE request. 179 o Provide an opportunity for a UAC to retry an INVITE to one branch 180 without canceling other pending branches. 181 o Do not require modification of the SIP transaction state machine. 182 o Work through existing RFC 3261 compliant proxy servers. 183 o Allow the forking proxy to still add or cancel branches. 184 o Work consistently with unmodified User Agent Servers. 186 A previous attempt [7] to solve HERFP required each UAS to generate a 187 new provisional response encapsulating the actual final response. 188 However the entire HERFP problem stems from the fact that different 189 UAS implementations will behave differently and frequently implement 190 different sets of extensions. The last goal reflects that a 191 satisfactory solution should work with unmodified User Agent Servers. 193 Instead of requiring new UAS behavior, this solution enlists the 194 services of the proxy to generate a provisional response of its own 195 (a 130 Repairable Error response) for each branch. Each 130 response 196 encapsulates the repairable final response from one branch. The 197 proxy acts temporarily as a UAS to send these provisional responses. 198 The proxy generates and provides a new URI that the UAC will contact 199 after repairing the error. This URI is similar in spirit to a 200 Globally Routable UA URI (GRUU) [5], except that the URI refers to a 201 specific branch of a specific target set only. Each new URI refers 202 only to one specific failed branch, but is still associated with the 203 list of candidate recipients of the original transaction (the target 204 set). 206 A UAC which supports this extension reacts to a 130 response by 207 sending a new INVITE request (with the same Call-ID) to the URI in 208 the Contact header of the 130 response. This new request is 209 generated in the same context as the original INVITE request, which 210 is unaffected by the new request. The proxy can still try new 211 branches in the candidate set or cancel old ones. Using this 212 technique, the original requester can immediately fix repairable 213 error responses. If the UAC decides it cannot repair an error, it 214 sends a DECLINE request (a new method defined here) to indicate to 215 the Proxy that it can eliminate the corresponding branch from best- 216 response matching. 218 Now consider the same example described above but employing the 219 solution described in this document. The UAC sends a request with a 220 multipart/mixed body. The Proxy forwards this request to UAS1 and 221 UAS2. UAS1 sends the proxy a 415 response. The proxy generates a 222 URI with the appropriate properties, and generates a 130 Repairable 223 Error response with the 415 response embedded as a message/sip body. 224 The UAC sends a new INVITE to the URI that the proxy generated with 225 only a session description in the body. The proxy forwards the 226 INVITE to UAS1, but manages the forking logic as if the new request 227 was in the original target set. When UAS1 sends a 200 OK, the proxy 228 cancels the branch with UAS2. 230 UAC Proxy UAS1 UAS2 231 | | | | 232 |--INVITE-->| | | 233 | |--INVITE-->| | 234 | |--INVITE------------->| 235 | |<-------------180-----| 236 |<-----180--| | | 237 | |<---415----| | 238 | |----ACK--->| | 239 |<-----130--| | | 240 |--INVITE-->| | | 241 | |--INVITE-->| | 242 | |<---180----| | 243 |<-----180--| | | 244 | | | | 245 | | | | 246 | |<---200----| | 247 |<---200 OK-| | | 248 |----ACK--------------->| | 249 | |--CANCEL------------->| 250 | |<--------200 (CANCEL)-| 251 | |<---------------487---| 252 | |-----ACK------------->| 253 | | | | 255 4. Proxy Behavior 257 4.1 Handling repairable errors 259 A proxy which supports this extension performs the following steps 260 when receiving a repairable error: 261 o Determine if the UAC supports this extension 262 o Determine if the proxy is awaiting pending responses to complete 263 the response context. 265 o Generate a URI which identifies this specific branch 266 o Encapsulate the original response in a message/sip body 267 o Generate a 130 Repairable Error provisional response 268 o Add an Identity header or its equivalent for responses 269 o Send the 130 response appropriately 271 To determine if the UAC supports this extension, the proxy needs to 272 check for the presence of the "herf" option-tag in the original 273 INVITE request (typically in a Supported header). If the UAC does 274 not advertise support for this option, response processing continues 275 normally. The proxy also checks the response context of the request. 276 If there are no more branches pending in the response context of this 277 transaction, processing continues normally. The rest of this section 278 assumes that the UAC supports this extension, and that there are 279 pending branches remaining in the response context. 281 When a proxy receives a 400-class or 500-class response other than a 282 503, 487, or 408, the proxy SHOULD generate a 130 Repairable Error 283 response as a User Agent Server. If the proxy receives a 300-class 284 response, the proxy can decide based on local policy whether to 285 recurse, or generate a 130 Repairable Error response. 287 To generate a 130 response, the proxy first creates a message/sip 288 body containing the original (3xx, 4xx, or 5xx) response. The 289 Content-Disposition header for this for this body MUST be "signal" 290 [or we could define a new disposition called "error"]. The proxy 291 does not add the response to the response context for the purpose of 292 returning the best response. The proxy generates a unique To tag for 293 the response. The response context continues to pend until the proxy 294 has positive knowledge that the 130 response was successfully 295 received by the UAC (either the corresponding 130 response is 296 acknowledged or the single-branch URI is contacted). 298 Next, the proxy generates a "single-branch" URI which corresponds to 299 this branch of this target set. The hostport production of the 300 single-branch URI MUST be identical to the hostport production from 301 the Request URI of the original request. If the Request URI of the 302 original request was a SIPS URI, the single-branch URI MUST be a SIPS 303 URI as well unless the error response was a 416 Unsupported URI 304 Scheme, in which case the proxy SHOULD generate a single-branch URI 305 using the SIP scheme. Otherwise the construction of a single-branch 306 URI is local policy of the proxy and is not subject to 307 standardization. 309 The proxy SHOULD embed a To header in the single-branch URI that 310 corresponds to the Identity of the branch. Typically, this identity 311 is the same identity which was in the original request. The scheme 312 of the embedded To URI MUST match the scheme of the single-branch 313 URI. The hostport of the embedded To URI MUST be a domain for which 314 the proxy can provide the Identity service. 316 The proxy now generates a 130 Repairable Error provisional response 317 and adds a Contact header field containing the single-branch URI 318 (including the embedded To header), and the message/sip body 319 containing the original response. 321 The proxy SHOULD add an Identity header or its equivalent used for 322 response identity. This insures the integrity and authenticity of 323 the 130 response and protects from tampering the linkage between the 324 URI provided in the Contact header of the 130 response and the 325 original request. 327 At this point, the proxy is ready to send the provisional response. 328 If the original INVITE included the 100rel option-tag, the proxy 329 temporarily acts as a UAS and sends the 130 response reliably 330 according to the rules in RFC 3262 [2]. Whether the 130 was sent 331 reliably or unreliably, the proxy MUST retransmit the 130 response 332 every 60 seconds until the proxy has positive knowledge that the 130 333 response was successfully received by the UAC (either the 334 corresponding 130 response is acknowledged or the single-branch URI 335 is contacted). 336 Note that provisional responses in SIP can be sent reliably or 337 unreliably. This mechanism can be used in either case. The proxy 338 MUST support the ability to send provisional reliable responses 339 (RFC 3262). Whether the proxy sends 130 Repairable Error 340 responses reliably or unreliably is up to the UAC. If the UAC 341 indicates that it supports reliable provisional responses, the 342 proxy server sends them reliably. Otherwise the proxy sends them 343 unreliably. In most networks the unreliable provisionals will 344 arrive and provide the desired behavior. This represents a 345 significant improvement over current behavior. If the unreliable 346 provisionals do not arrive, we have not solved HERFP, but the 347 situation is no worse than with existing implementations. 349 If the proxy responds reliably it MUST include an answer (if the 350 INVITE contained an offer) or an offer (otherwise) in the 130 351 response. The proxy can satisfy this requirement by generating a 352 minimal offer or answer. A minimally appropriate answer declines all 353 media lines in the offer. A minimally appropriate offer includes no 354 media lines. When a 130 is sent reliably, the message/sip body 355 containing the error and the session description are placed into a 356 multipart/mixed body in the 130 response. UACs which support this 357 extension and provisional reliability MUST support the multipart/ 358 mixed MIME type. 360 4.2 Receiving subsequent requests with the single-branch property 362 As soon as the proxy is contacted at a single-branch URI for the 363 first time, the proxy tries to find the appropriate branch. If the 364 proxy cannot find the appropriate branch it MUST return a 481 365 response. If the proxy finds the branch, it marks the original 366 response context for that branch as if the branch returned a 487 367 response. If the request is a PRACK, the proxy returns a 200 OK 368 response to the PRACK with an appropriate RAck header. If the 369 request is a DECLINE, the proxy returns a 200 OK response to the 370 DECLINE and notes that this branch has been terminated. If the 371 request is an INVITE, the proxy generates a response context for the 372 new request consisting of one target and forwards the INVITE to the 373 UAS for that target. 375 The proxy forwards provisional response for the new response context 376 normally. When a final response to the new request is received it is 377 forwarded immediately since the new response context consists of only 378 one branch. If the final response to the new INVITE request is a 379 200-class or 600-class response, the proxy MUST CANCEL all other 380 pending branches which were created from or related to the original 381 INVITE request. In other words, the proxy must find all pending 382 branches of both the "parent" transaction and all pending "sibling" 383 transactions. In addition, the proxy MUST invalidate all the single- 384 branch URIs associated with the original request. 385 Note that for a particular branch, the proxy might receive a new 386 INVITE request which repairs one error, but for which there are 387 other unresolved, but repairable error responses. While this 388 situation is currently rare, proxy server MUST NOT invalidate 389 single-branch URIs until Timer C expires for that branch, the 390 branch is cancelled by the UAC, or a 200-class or 600-class 391 response has been received on a parent or sibling transaction. 393 5. User Agent Client Behavior 395 A User Agent Client which supports this extension SHOULD advertise 396 for this extension by including the "herf" option-tag in a Supported 397 header field value in dialog-forming INVITE requests. The UAC needs 398 the ability to send multiple invitations in the same user interface 399 context, for example as if the UAC tried multiple contacts from a 400 300-class response simultaneously. 402 When a User Agent which supports this extension receives a 130 403 Repairable Error response to an INVITE request, it performs the 404 following steps. 405 o Verify the validity of the Identity headers (if present) 406 o Send a PRACK request if reliability was requested 407 o Determine if the error is repairable 408 o Either generate a new INVITE to repair the error, or generate a 409 DECLINE request to acknowledge receipt of the 130 response. 411 The UAC SHOULD first verify that the 130 response was sent by a host 412 which is authoritative for the domain of the original request and 413 that the 130 response was not tampered with en route. The UAC checks 414 that the Identity hash verifies and that the signer of the Identity 415 header corresponds to the hostport production from the Request URI of 416 the original request. 418 If the 130 response was sent reliably, the UAC MUST send a PRACK 419 request to the URI in the Contact header field of the 130 response. 421 Next the UAC determines if it can and is willing to repair the error 422 by examining the message/sip body (which may be a MIME part inside a 423 multipart/mixed body). UACs which support this extension and 424 provisional reliability MUST support the multipart/mixed MIME type. 425 The UAC MAY decide based on local policy not to repair the error or 426 it may be unable to do so. In that case, the UAC MUST send a DECLINE 427 request to the URI in the Contact header field of the 130 response. 428 Note that this DECLINE only terminates a single branch. 430 If the UAC is willing and able to repair the error, it generates a 431 new INVITE request using the same Call-ID, but a different from-tag. 432 It then sends this new INVITE to the URI in the Contact header field 433 of the 130 response. If an embedded To header is present in the 434 Contact URI, the UAC MUST override the To header of the new INVITE to 435 use the value provided in the Contact header. 437 6. User Agent Server Behavior 439 This document requires no new behavior by User Agent Servers. It was 440 designed to work only if the User Agent Client and the Proxy support 441 this extension. There is an opportunity to improve the current 442 situation when only the UAC and one UAS cooperate. Such behavior is 443 potentially complimentary, but out of scope of this document. 445 7. Security Considerations 447 An attacker that maliciously injects 130 responses could 448 theoretically direct a large number of new requests towards a 449 specific proxy. To prevent this attack, the UAC SHOULD verify that a 450 130 response has a valid Identity header (or its response equivalent) 451 signed using a key from a certificate whose subjectAltName is 452 equivalent to the hostport production from the Request URI, and that 453 the certificate is rooted in a trusted certificate chain. The 454 security considerations of a 130 response in this context are 455 identical to injecting a malicious 300-class response. 457 A UAS that maliciously injects a 130 could theoretically downgrade 458 the security of a dialog from SIPS to SIP. The UAC SHOULD include 459 configurable policy to automatically repair or ignore 416 responses 460 or to prompt the user. 462 A UAS that maliciously injects a 130 could selectively disable 463 capabilities or extensions. The security considerations of such an 464 attack are similar to injecting the corresponding 400-class response. 466 8. IANA Considerations 468 The following entries should be added to the registries for SIP 469 option-tags and response-codes, respectively. 471 8.1 The "herf" option-tag 473 Name of option: herf 475 Description: Support for safe forking in the face 476 of heterogeneous error responses 478 SIP headers defined: none 480 Normative description: This document 482 8.2 The "130 Repairable Error" response-code 484 Response Code Number: 130 485 Default Reason Phrase: Repairable Error 487 8.3 The "DECLINE" method 489 Method Name: DECLINE 491 9. Acknowledgments 493 This idea was the result of 1) participating in discussions with 494 Jonathan Rosenberg, Paul Kyzivat, Jon Peterson, and Cullen Jennings 495 on the properties of URIs in conjunction with the GRUU extension; 2) 496 thoughts I had while implementing best response matching in the repro 497 open-source SIP proxy, 3) numerous discussions about response 498 Identity with Jon Peterson and Cullen Jennings, 4) and a discussion 499 with Mark Eastman about a solution to the Early Attended Transfer 500 problem. 502 10. References 504 10.1 Normative References 506 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 507 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 508 Session Initiation Protocol", RFC 3261, June 2002. 510 [2] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 511 Responses in Session Initiation Protocol (SIP)", RFC 3262, 512 June 2002. 514 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 515 Levels", BCP 14, RFC 2119, March 1997. 517 [4] Peterson, J. and C. Jennings, "Enhancements for Authenticated 518 Identity Management in the Session Initiation Protocol (SIP)", 519 draft-ietf-sip-identity-06 (work in progress), October 2005. 521 10.2 Informational References 523 [5] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 524 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", 525 draft-ietf-sip-gruu-06 (work in progress), October 2005. 527 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 528 Notification", RFC 3265, June 2002. 530 URIs 532 [7] 535 [8] 538 Author's Address 540 Rohan Mahy 541 Plantronics 542 345 Encincal Street 543 Santa Cruz, CA 544 USA 546 Email: rohan@ekabal.com 548 Appendix A. Historical Context 550 The Heterogeneous Error Response Forking Problem (HERFP) was 551 described in various SIP working group mailing list threads in late 552 2001 and then described more formally in a long expired Internet 553 Draft (draft-rosenberg-sip-unify-00.txt [8]) in January of 2002. The 554 problem description from the draft is copied here: 556 HERFP, as it is called, is, in our opinion, the most complex 557 remaining problem with the SIP specification. 559 It relates to the rules for response processing at a forking proxy. 560 A proxy never forwards more than one error response back to the [User 561 Agent Client (UAC)]. This is needed to prevent response implosion, 562 but more importantly, to support services at proxies. A forking 563 proxy only returns an error response upstream if all forked requests 564 generate an error response. However, a 200 OK [to an INVITE] is 565 always forwarded upstream immediately. 567 The problem is that if a request forks, and one UAS generates an 568 error because the INVITE is not acceptable for some reason (no 569 credentials, bad , bad body type, unsupported extension, etc.), that 570 response is held at the forking proxy until the other forks respond. 571 Of course, another branch may find the request acceptable, and 572 therefore never generate an error response. The effect is to cancel 573 out the benefits of forking. 575 uac p1 uas1 uas2 576 |(1) INVITE | | 577 |-------->| | | 578 | |(2) INVITE | 579 | |-------->| | 580 | |(3) INVITE | 581 | |------------------>| 582 | |(4) 401 | | 583 | |<--------| | 584 | |(5) ACK | | 585 | |-------->| | 586 | |(6) 180 | | 587 | |<------------------| 588 | |(7) 180 | | 589 | |<------------------| 590 |(8) CANCEL | | 591 |-------->| | | 592 |(9) 200 OK | | 593 |<--------| | | 594 | |(10) CANCEL | 595 | |------------------>| 596 | |(11) 200 OK | 597 | |<------------------| 598 | |(12) 487 | | 599 | |<------------------| 600 | |(13) ACK | | 601 | |------------------>| 602 |(14) 401 | | | 603 |<--------| | | 604 |(15) ACK | | | 605 |-------->| | | 607 Figure 2: Basic HERFP Case 609 Figure 2 shows the simplest form of the problem. In this flow, the 610 UAC sends an INVITE to proxy P1, which forks to UAS1 and UAS2. UAS1 611 might be a cell phone, and UAS2 a business phone. UAS1 rejects with 612 a 401, and so never rings. However, UAS2 does not require 613 credentials (or the request already had them), and therefore it 614 rings. However, the user is not at their business phone, although 615 they are available at the cell phone. After ringing for 20s, the 616 caller gives up, and therefore sends CANCEL. This stops UAS2 from 617 ringing, and results in the proxy forwarding the now-old 401 to the 618 UAC. The UAC is not likely to retry, since the user just hung up. 619 Thus, no call is setup. 621 Intellectual Property Statement 623 The IETF takes no position regarding the validity or scope of any 624 Intellectual Property Rights or other rights that might be claimed to 625 pertain to the implementation or use of the technology described in 626 this document or the extent to which any license under such rights 627 might or might not be available; nor does it represent that it has 628 made any independent effort to identify any such rights. Information 629 on the procedures with respect to rights in RFC documents can be 630 found in BCP 78 and BCP 79. 632 Copies of IPR disclosures made to the IETF Secretariat and any 633 assurances of licenses to be made available, or the result of an 634 attempt made to obtain a general license or permission for the use of 635 such proprietary rights by implementers or users of this 636 specification can be obtained from the IETF on-line IPR repository at 637 http://www.ietf.org/ipr. 639 The IETF invites any interested party to bring to its attention any 640 copyrights, patents or patent applications, or other proprietary 641 rights that may cover technology that may be required to implement 642 this standard. Please address the information to the IETF at 643 ietf-ipr@ietf.org. 645 Disclaimer of Validity 647 This document and the information contained herein are provided on an 648 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 649 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 650 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 651 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 652 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 653 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 655 Copyright Statement 657 Copyright (C) The Internet Society (2006). This document is subject 658 to the rights, licenses and restrictions contained in BCP 78, and 659 except as set forth therein, the authors retain all their rights. 661 Acknowledgment 663 Funding for the RFC Editor function is currently provided by the 664 Internet Society.