idnits 2.17.1 draft-ietf-sip-replaces-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 325 has weird spacing: '...r field whe...' == Line 526 has weird spacing: '...ication for r...' -- 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 16, 2004) is 7367 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 2234 (ref. '3') (Obsoleted by RFC 4234) == Outdated reference: A later version (-05) exists of draft-ietf-sip-referredby-01 == Outdated reference: A later version (-03) exists of draft-ietf-sip-authid-body-01 ** Obsolete normative reference: RFC 2617 (ref. '6') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2633 (ref. '7') (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2543 (ref. '9') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-framework-02 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-3pcc-03 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-01 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-01 == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-04 -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '16') (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 2976 (ref. '17') (Obsoleted by RFC 6086) == Outdated reference: A later version (-01) exists of draft-ietf-simple-publish-00 Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG R. Mahy 3 Internet-Draft Cisco Systems, Inc. 4 Expires: August 16, 2004 B. Biggs 5 R. Dean 6 February 16, 2004 8 The Session Inititation Protocol (SIP) "Replaces" Header 9 draft-ietf-sip-replaces-05.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 16, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document defines a new header for use with SIP multi-party 40 applications and call control. The Replaces header is used to 41 logically replace an existing SIP dialog with a new SIP dialog. This 42 primitive can be used to enable a variety of features, for example: 43 "Attended Transfer" and "Call Pickup". Note that definition of these 44 example features is non-normative. 46 Table of Contents 48 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. User Agent Server Behavior: Receiving a Replaces Header . . 5 51 4. User Agent Client Behavior: Sending a Replaces header . . . 7 52 5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . 7 53 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 6.1 The Replaces Header . . . . . . . . . . . . . . . . . . . . 7 55 6.2 New option tag for Require and Supported headers . . . . . . 9 56 7. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 9 57 7.1 Replacing an Early Dialog at the originator . . . . . . . . 9 58 8. Security Considerations . . . . . . . . . . . . . . . . . . 11 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 60 9.1 Registration of "Replaces" SIP header . . . . . . . . . . . 13 61 9.2 Registration of "replaces" SIP Option-tag . . . . . . . . . 13 62 10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 10.1 Changes Since -04 . . . . . . . . . . . . . . . . . . . . . 13 64 10.2 Changes Since -03 . . . . . . . . . . . . . . . . . . . . . 13 65 10.3 Changes Since -02 . . . . . . . . . . . . . . . . . . . . . 14 66 10.4 Changes Since -01 . . . . . . . . . . . . . . . . . . . . . 14 67 10.5 Changes Since -00 . . . . . . . . . . . . . . . . . . . . . 14 68 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 69 Normative References . . . . . . . . . . . . . . . . . . . . 15 70 Informational References . . . . . . . . . . . . . . . . . . 15 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 72 Intellectual Property and Copyright Statements . . . . . . . 18 74 1. Conventions 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC-2119 [2]. 80 This document refers frequently to the terms "confirmed dialog" and 81 "early dialog". These are defined in Section 12 of SIP [1]. 83 2. Overview 85 This document describes a SIP [1] extension header field as part of 86 the SIP multiparty applications architecture framework [10]. The 87 Replaces header is used to logically replace an existing SIP dialog 88 with a new SIP dialog. This is especially useful in peer-to-peer call 89 control environments. 91 One use of the "Replaces" header is to replace one participant with 92 another in a multimedia conversation. While this functionality is 93 already available using 3rd party call control [11] style call 94 control, the 3pcc model requires a central point of control which may 95 not be desirable in many environments. As such, a method of 96 performing these same call control primitives in a distributed, 97 peer-to-peer fashion is very desirable. 99 Use of a new INVITE with a new header for dialog matching was chosen 100 over making implicit associations in an incoming INVITE based on 101 call-id or other fields for the following reasons: 103 o An INVITE already has the correct semantics for a new call 105 o Using an explicit Replaces header in a new request makes the 106 intent of the request obvious. 108 o A unique call-id may be given to the replacement call. This 109 avoids dialog matching problems in any of the related User Agents. 111 o There are no adverse effects if the header is unsupported. 113 The Replaces header enables services such as attended call transfer, 114 retrieve from park, and transition from locally mixed conferences to 115 two party calls in a distributed peer-to-peer way. This list of 116 services is not exhaustive. Although the Replaces header is 117 frequently used in combination with the REFER [8] method as used in 118 cc-transfer [12], they may be used independently. 120 For example, Alice is talking to Bob from phone1. She transfers Bob 121 to a Parking Place while she goes to the lab. When she gets there 122 she retrieves the "parked" call from phone2 by sending an INVITE with 123 a Replaces header field to Bob with the dialog information Bob shared 124 with the Parking Place. Alice got this information using some out of 125 band mechansim. Perhaps she subscribed to this information from the 126 Parking Place (using the session dialog package [13]), or went to a 127 website and clicked on a URI. A short call flow for this example 128 follows. (Via and Max-Forwards headers are omitted for clarity.) 130 Alice Alice Parking 131 phone1 phone2 Bob Place 132 | | | | 133 |<===============================>| | 134 | | | | 135 | Alice transfers Bob to Parking Place | 136 | | | | 137 |------------REFER/200----------->| *1 *2 | 138 | | |--INVITE/200/ACK-->| 139 |<-----------NOTIFY/200-----------|<=================>| 140 |------------BYE/200------------->| | 141 | | | | 142 | | | | 143 | Alice later retrieves call from another phone | 144 | | | | 145 | *3 |-INV w/Replaces->| | 146 | |<--200-----------| | 147 | |---ACK---------->|----BYE/200------->| 148 | |<===============>| | 149 | | | | 151 Message *1: Bob-> Parking Place 153 INVITE sip:parkingplace@example.org SIP/2.0 154 To: 155 From: ;tag=7743 156 Call-ID: 425928@bobster.example.org 157 CSeq: 1 INVITE 158 Contact: 159 Referred-By: 161 Message *2: Parking Place -> Bob 163 SIP/2.0 200 OK 164 To: ;tag=6472 165 From: ;tag=7743 166 Call-ID: 425928@bobster.example.org 167 CSeq: 1 INVITE 168 Contact: 169 Message *3: Alice@phone2 -> Bob 171 INVITE sip:bob@bobster.example.org 172 To: 173 From: ;tag=8983 174 Call-ID: 09870@phone2.example.org 175 CSeq: 1 INVITE 176 Contact: 177 Require: replaces 178 Replaces: 425928@bobster.example.org;to-tag=7743;from-tag=6472 180 3. User Agent Server Behavior: Receiving a Replaces Header 182 The Replaces header contains information used to match an existing 183 SIP dialog (call-id, to-tag, and from-tag). Upon receiving an INVITE 184 with a Replaces header, the UA attempts to match this information 185 with a confirmed or early dialog. The to-tag and from-tag parameters 186 are matched as if they were tags present in an incoming request. In 187 other words the to-tag parameter is compared to the local tag, and 188 the from-tag parameter is compared to the remote tag. 190 If more than one Replaces header field is present in an INVITE, or if 191 a Replaces header field is present in a request other than INVITE, 192 the UAS MUST reject the request with a 400 Bad Request response. 194 The Replaces header has specific call control semantics. If both a 195 Replaces header field and another header field with contradictory 196 semantics are present in a request, the request MUST be rejected with 197 a 400 "Bad Request" response. 199 If the Replaces header field matches more than one dialog, the UA 200 MUST act as if no match is found. 202 If no match is found, the UAS rejects the INVITE and returns a 481 203 Call/Transaction Does Not Exist response. Likewise, if the Replaces 204 header field matches a dialog which was not created with an INVITE, 205 the UAS MUST reject the request with a 481 response. 207 If the Replaces header field matches a dialog which has already 208 terminated, the UA SHOULD decline the request with a 603 Declined 209 response. 211 If the Replaces header field matches an active dialog, the UA MUST 212 verify that the initiator of the new INVITE is authorized to replace 213 the matched dialog. If the initiator of the new INVITE has 214 authenticated successfully as equivalent to the user who is being 215 replaced, then the replacement is authorized. For example, if the 216 user being replaced and the initator of the replacement dialog share 217 the same credentials for Digest authentication [6], or they sign the 218 replacement request with S/MIME [7] with the same private key and 219 present the (same) corresponding certificate used in the original 220 dialog, then the replacement is authorized. 222 Alternatively, the Referred-By mechanism [4] defines a mechanism that 223 the UAS can use to verify that a replacement request was sent on 224 behalf of the other participant in the matched dialog (in this case, 225 triggered by a REFER request). If the replacement request contains a 226 Referred-By header which corresponds to the user being replaced, the 227 UA SHOULD treat the replacement as if the replacement was authorized 228 by the replaced party. The Referred-By header SHOULD reference a 229 corresponding, valid Refererred-By Authenticated Identity Body [5]. 230 The UA MAY apply other local policy to authorize the remainder of the 231 request. In other words the UAS may apply different policy to the 232 replacement dialog than was applied to the replaced dialog. 234 In addition, the UA MAY use other authorization mechanisms defined 235 for this purpose in standards track extensions. Extensions could 236 define other mechanisms for transitively asserting authorization of a 237 replacement. 239 If authorization is successful, the UA attempts to accept the new 240 INVITE, reassign the user interface and other resources of the 241 matched dialog to the new INVITE, and shut down the replaced dialog. 242 If the UA cannot accept the new INVITE (for example: it cannot 243 establish required QoS or keying, or it has incompatible media), the 244 UA MUST return an appropriate error response and MUST leave the 245 matched dialog unchanged. 247 If the Replaces header field matches a confirmed dialog, it checks 248 for the presence of the "early-only" flag in the Replaces header 249 field. (This flag allows the UAC to prevent a potentially undesirable 250 race condition desribed in Section 7.1.) If the flag is present, the 251 UA rejects the request with a 486 Busy response. Otherwise it accepts 252 the new INVITE by sending a 200-class response, and shuts down the 253 replaced dialog by sending a BYE. If the Replaces header field 254 matches an early dialog that was initiated by the UA, it accepts the 255 new INVITE by sending a 200-class response, and shuts down the 256 replaced dialog by sending a CANCEL. 258 If the Replaces header field matches an early dialog that was not 259 initiated by this UA, it returns a 481 (Call/Transaction Does Not 260 Exist) response to the new INVITE, and leaves the matched dialog 261 unchanged. Note that since Replaces matches only a single dialog, the 262 replacement dialog will not be retargeted according to the same 263 forking logic as the original request which created the early dialog. 265 (Currently no use cases have been identified for replacing just a 266 single dialog in this circumstance.) 268 4. User Agent Client Behavior: Sending a Replaces header 270 A User Agent that wishes to replace a single existing early or 271 confirmed dialog with a new dialog of its own, MAY send the target 272 User Agent an INVITE request containing a Replaces header field. The 273 UAC places the Call-ID, to-tag, and from-tag information for the 274 target dialog in a single Replaces header field and sends the new 275 INVITE to the target. If the user agent only wishes to replace an 276 early dialog (as in the Call Pickup example in Section 7.1), the UAC 277 MAY also include the "early-only" parameter in the Replaces header 278 field. A UAC MUST NOT send an INVITE with Replaces header field which 279 attempts to replace an early dialog which was not originated by the 280 target of the INVITE with Replaces header field. 282 Note that use of this mechanism does not provide a way to match 283 multiple dialogs, nor does it provide a way to match an entire call, 284 an entire transaction, or to follow a chain of proxy forking logic. 285 For example, if Alice replaces Cathy in an early dialog with Bob, but 286 he does not answer, Alice's replacement request will not match other 287 dialogs to which Bob's UA redirects, nor other branches to which his 288 proxy forwards. Although this specification takes reasonable 289 precautions to prevent unexpected behavior in the face of forking, 290 implementations SHOULD only address replacement requests (i.e. set 291 the Request-URI of the replacement request) to the SIP Contact URI of 292 the target. 294 5. Proxy behavior 296 Proxy Servers do not require any new behavior to support this 297 extension. They simply pass the Replaces header field transparently 298 as described in the SIP specification. 300 Note that it is possible for a proxy (especially when forking based 301 on some application layer logic, such as caller screening or 302 time-of-day routing) to forward an INVITE request containing a 303 Replaces header field to a completely orthogonal set of Contacts than 304 the original request it was intended to replace. In this case, the 305 INVITE request with the Replaces header field will fail. 307 6. Syntax 309 6.1 The Replaces Header 311 The Replaces header field indicates that a single dialog identified 312 by the header field is to be shut down and logically replaced by the 313 incoming INVITE in which it is contained. It is a request header 314 only, and defined only for INVITE requests. The Replaces header 315 field MAY be encrypted as part of end-to-end encryption. Only a 316 single Replaces header field value may be present in a SIP request 318 This document adds the following entry to Table 2 of [1]. Additions 319 to this table are also provided for extension methods defined at the 320 time of publication of this document. This is provided as a courtesy 321 to the reader and is not normative in any way. MESSAGE, SUBSCRIBE and 322 NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are defined 323 respectively in [15], [16], [8], [17], [18], [19], and [20]. 325 Header field where proxy ACK BYE CAN INV OPT REG MSG 326 ------------ ----- ----- --- --- --- --- --- --- --- 327 Replaces R - - - o - - - 329 SUB NOT REF INF UPD PRA PUB 330 --- --- --- --- --- --- --- 331 Replaces R - - - - - - - 333 The following syntax specification uses the augmented Backus-Naur 334 Form (BNF) as described in RFC-2234 [3]. 336 Replaces = "Replaces" HCOLON callid *(SEMI replaces-param) 337 replaces-param = to-tag / from-tag / early-flag / generic-param 338 to-tag = "to-tag" EQUAL token 339 from-tag = "from-tag" EQUAL token 340 early-flag = "early-only" 342 A Replaces header field MUST contain exactly one to-tag and exactly 343 one from-tag, as they are required for unique dialog matching. For 344 compatibility with dialogs initiated by RFC2543 [9] compliant UAs, a 345 tag of zero matches both tags of zero and null tags. A Replaces 346 header field MAY contain the early-flag. 348 Examples: 350 Replaces: 98732@sip.billybiggs.com 351 ;from-tag=r33th4x0r 352 ;to-tag=ff87ff 354 Replaces: 12adf2f34456gs5;to-tag=12345;from-tag=54321;early-only 356 Replaces: 87134@171.161.34.23;to-tag=24796;from-tag=0 358 6.2 New option tag for Require and Supported headers 360 This specification defines a new Require/Supported header option tag 361 "replaces". UAs which support the Replaces header MUST include the 362 "replaces" option tag in a Supported header field. UAs that want 363 explicit failure notification if Replaces is not supported MAY 364 include the "replaces" option in a Require header field. 366 Example: 368 Require: replaces, 100rel 370 7. Usage Examples 372 The following non-normative examples are not intended to enumerate 373 all the possibilities for the usage of this extension, but rather to 374 provide examples or ideas only. For more examples, please see 375 service-examples [14]. Via and Max-Forwards headers are omitted for 376 clarity and brevity. 378 7.1 Replacing an Early Dialog at the originator 380 In this example, Bob just arrived in the lab and hasn't registered 381 there yet. He hears his desk phone ring. He quickly logs into a 382 software UA on a nearby computer. Among other things, the software UA 383 has access to the dialog state of his desk phone. When it notices 384 that his phone is ringing it offers him the choice to take the call 385 there. The software UA sends an INVITE with Replaces to Alice. When 386 Alice's UA receives this new INVITE, it CANCELs her original INVITE 387 and connects Alice to Bob. 389 Bob Bob 390 Alice desk lab 391 | | | 392 *1 |-----INVITE----------->| | 393 *2 |<----180---------------| Bob hears desk phone | 394 | | ringing from lab but | 395 | | isn't REGISTERed yet | 396 | | | 397 | |<--fetch dialog state --| 398 | |---response ----------->| 399 *3/4 |<-----INVITE with Replaces/200/ACK--------------| 400 *5/6 |------CANCEL/200------>| | 401 *7 |<-----487--------------| | 402 |------ACK------------->| | 403 | | | 404 | | | 406 Message *1: Alice -> Bob's desk phone 408 INVITE sip:bob@example.org SIP/2.0 409 To: 410 From: ;tag=7743 411 Call-ID: 425928@phone.example.org 412 CSeq: 1 INVITE 413 Contact: 415 Message *2: Bob's desk phone -> Alice 417 SIP/2.0 180 Ringing 418 To: ;tag=6472 419 From: ;tag=7743 420 Call-ID: 425928@phone.example.org 421 CSeq: 1 INVITE 422 Contact: 424 Message *3: Bob in lab -> Alice 426 INVITE sip:alice@phone.example.org 427 To: 428 From: ;tag=8983 429 Call-ID: 09870@labpc.example.org 430 CSeq: 1 INVITE 431 Contact: 432 Replaces: 425928@phone.example.org 433 ;to-tag=7743;from-tag=6472;early-only 435 Message *4: Alice -> Bob in lab 437 SIP/2.0 200 OK 438 To: ;tag=9232 439 From: ;tag=8983 440 Call-ID: 09870@labpc.example.org 441 CSeq: 1 INVITE 442 Contact: 444 Message *5: Alice -> Bob's desk 446 CANCEL sip:bob@example.org SIP/2.0 447 To: 448 From: ;tag=7743 449 Call-ID: 425928@phone.example.org 450 CSeq: 1 CANCEL 451 Contact: 453 Message *6: Bob's desk -> Alice 454 SIP/2.0 200 OK 455 To: 456 From: ;tag=7743 457 Call-ID: 425928@phone.example.org 458 CSeq: 1 CANCEL 459 Contact: 461 Message *7: Bob's desk -> Alice 463 SIP/2.0 487 Request Terminated 464 To: ;tag=6472 465 From: ;tag=7743 466 Call-ID: 425928@phone.example.org 467 CSeq: 1 INVITE 469 8. Security Considerations 471 The extension specified in this document significantly changes the 472 relative security of SIP devices. Currently in SIP, even if an 473 eavesdropper learns the Call-ID, To, and From headers of a dialog, 474 they cannot easily modify or destroy that dialog if Digest 475 authentication or end-to-end message integrity are used. 477 This extension can be used to disconnect participants or replace 478 participants in a multimedia conversation. As such, invitations with 479 the Replaces header MUST only be accepted if the peer requesting 480 replacement has been properly authenticated using a standard SIP 481 mechanism (Digest or S/MIME), and authorized to request a replacement 482 of the target dialog. All SIP implementations are already required 483 to support Digest Authentication. In addition, implementations which 484 support the Replaces header SHOULD also implement the Referred-By 485 mechanism. 487 How a User Agent determines which requests are legitimately 488 authorized to make dialog replacements is non-trivial and depends on 489 a considerable amount of local policy configuration. In general, 490 there are four cases when a authorization for a replacement is 491 reasonable or warranted. 493 1. Replacement made by a party considered equivalent to the replaced 494 party 496 2. Replacement made on behalf of the replaced party (perhaps 497 transitively) 499 3. Replacement made by a former participant 500 4. Replacement made by a specifically authorized party 502 Starting with #1 for example, if an executive and an assistant both 503 receive requests for a shared address-of-record, if so configured, 504 either should be able to replace dialogs of the other for the shared 505 identity. Both could even share the same keying material (Digest or 506 S/MIME), or one could hold an authorization document signed by the 507 other expressing this relationship. Likewise in a call center 508 environment, each call center agent could possess credentials which 509 supervisors also have access to. 511 The most common use case of a replacement is on the request of the 512 replaced participant (who no longer wants to be involved). This is 513 the case in many features such as completing an Attended Transfer and 514 converting a 3-way call to a point-to-point call. Such replacements 515 are typically triggered by a REFER [8] request from the replaced 516 participant. The Referred-By [4] mechanism defines one way to 517 identify the apparent original requester and can point to a SIP 518 Authenticated Identity Body [5] (an S/MIME-based signed assertion) to 519 secure this information. 521 In the example in section 2, Alice sends an INVITE with Replaces to 522 Bob. Alice was a former participant in the conversation and had a 523 previous dialog relationship with Bob. Alice can use the same Digest 524 or SMIME credentials she used to authenticate with Bob during the 525 original call to prove that she was a former participant. Note that 526 this justification for replacing calls is more dangerous than the 527 others, and in most cases another way to authorize the replacing 528 participant is available. Implementations SHOULD NOT rely on this 529 method as an authorization mechanism. 531 The last scenario is the easiest to secure but the least likely to be 532 useful in practice. It is unlikely that an arbitrary host in the 533 Internet is aware of any special authorization relationship between 534 the replaced and the replacing parties. However, this use case may 535 be useful in some environments. Since this usage does not 536 effectively degrade the security of the solution it is still allowed. 538 Some mechanisms for obtaining the dialog information needed by the 539 Replaces header (Call-ID, to-tag, and from-tag) include URIs on a web 540 page, subscriptions to an appropriate event package, and notifcations 541 after a REFER request. Since manipulating this dialog information 542 could cause User Agents to replace the wrong dialog, use of message 543 integrity protection for this information is STRONGLY RECOMMENDED, 544 Use of end-to-end security mechanisms to encrypt this information is 545 also RECOMMENDED. 547 This extension was designed to take advantage of future signature or 548 authorization schemes defined in standards track extensions. In 549 general, call control features benefit considerably from such work. 551 9. IANA Considerations 553 9.1 Registration of "Replaces" SIP header 555 Name of Header: Replaces 557 Short form: none 559 Normative description: section 6.1 of this document 561 9.2 Registration of "replaces" SIP Option-tag 563 Name of option: replaces 565 Description: Support for the SIP Replaces header 567 SIP headers defined: Replaces 569 Normative description: This document 571 10. Changes 573 *** [Note to RFC editor. Please remove this entire section when this 574 draft is published as an RFC.] *** 576 10.1 Changes Since -04 578 Upgraded authorization from SHOULD to MUST. Reminded implementors 579 that Digest is MUST to implement for baseline SIP. Made 580 implementation of Referred-By a SHOULD. 582 10.2 Changes Since -03 584 o Added the "early-only" parameter to prevent a race condition 585 during Call Pickup and related features. 587 o Made Referred-By and Auth-ID Body normative references, and 588 generally improved the strength of the authorization section based 589 on comments during AD review. 591 o Updated references and added reference for the PUBLISH method. 593 10.3 Changes Since -02 595 o Removed the ability to match an early dialog at the receiver of 596 the matching dialog, since all the use cases apparently needing 597 this feature actually need to match an entire set of targets in a 598 chain of proxy forking logic. Also removed all references to the 599 687 response code which was only used for this purpose. 601 o Added more detail in section 3 and section 8 about how to 602 authorize replacements. 604 10.4 Changes Since -01 606 o Removed the to-tag=* matching mechanism, and related proxy 607 requirements and examples based on WG consensus at interim meeting 608 and on the mailing list. 610 o Reorganized motivational overview material 612 o Moved extra examples to service-flows 614 o Added authorization language in UAS behavior section 616 o Removed allowance to match on one of multiple matching dialogs 617 with no tags 619 o Updated references 621 10.5 Changes Since -00 623 o When no dialog matches the Call-ID and tags in a Replaces header, 624 the UAS now returns a 481 instead of silently accepting the 625 INVITE. 627 o Changed the BNF to match the explicit whitespace BNF now used by 628 SIP. 630 o Added the to-tag=* matching mechanism. 632 o Added requirements for forking proxies and a discussion of the 633 consequences if forking proxies do not support Replaces. 635 o Added last two examples. 637 o Split normative and non-normative references 639 11. Acknowledgments 641 Thanks to Robert Sparks, Alan Johnston, Dan Petrie, and Ben Campbell 642 and many other members of the SIP WG for their continued support of 643 the cause of distributed call control in SIP. 645 Normative References 647 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 648 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 649 Session Initiation Protocol", RFC 3261, June 2002. 651 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 652 Levels", BCP 14, RFC 2119, March 1997. 654 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 655 Specifications: ABNF", RFC 2234, November 1997. 657 [4] Sparks, R., "The SIP Referred-By Mechanism", 658 draft-ietf-sip-referredby-01 (work in progress), February 2003. 660 [5] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", 661 draft-ietf-sip-authid-body-01 (work in progress), March 2003. 663 [6] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 664 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 665 Basic and Digest Access Authentication", RFC 2617, June 1999. 667 [7] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 668 2633, June 1999. 670 Informational References 672 [8] Sparks, R., "The Session Initiation Protocol (SIP) Refer 673 Method", RFC 3515, April 2003. 675 [9] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 676 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 678 [10] Mahy, R., "A Call Control and Multi-party usage framework for 679 the Session Initiation Protocol (SIP)", 680 draft-ietf-sipping-cc-framework-02 (work in progress), March 681 2003. 683 [11] Rosenberg, J., Schulzrinne, H., Camarillo, G. and J. Peterson, 684 "Best Current Practices for Third Party Call Control in the 685 Session Initiation Protocol", draft-ietf-sipping-3pcc-03 (work 686 in progress), March 2003. 688 [12] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 689 Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in 690 progress), February 2003. 692 [13] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog 693 Event Package for the Session Initiation Protocol (SIP", 694 draft-ietf-sipping-dialog-package-01 (work in progress), March 695 2003. 697 [14] Johnston, A. and S. Donovan, "Session Initiation Protocol 698 Service Examples", draft-ietf-sipping-service-examples-04 (work 699 in progress), March 2003. 701 [15] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 702 D. Gurle, "Session Initiation Protocol (SIP) Extension for 703 Instant Messaging", RFC 3428, December 2002. 705 [16] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 706 Notification", RFC 3265, June 2002. 708 [17] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 710 [18] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 711 Method", RFC 3311, October 2002. 713 [19] jdrosen@dynamicsoft.com and schulzrinne@cs.columbia.edu, 714 "Reliability of Provisional Responses in Session Initiation 715 Protocol (SIP)", RFC 3262, June 2002. 717 [20] Campbell, B., "SIMPLE Presence Publication Mechanism", 718 draft-ietf-simple-publish-00 (work in progress), February 2003. 720 Authors' Addresses 722 Rohan Mahy 723 Cisco Systems, Inc. 724 5617 Scotts Valley Dr 725 Scotts Valley, CA 95066 726 USA 728 EMail: rohan@cisco.com 730 Billy Biggs 732 EMail: bbiggs@dumbterm.net 733 Rick Dean 735 EMail: rfc@fdd.com 737 Intellectual Property Statement 739 The IETF takes no position regarding the validity or scope of any 740 intellectual property or other rights that might be claimed to 741 pertain to the implementation or use of the technology described in 742 this document or the extent to which any license under such rights 743 might or might not be available; neither does it represent that it 744 has made any effort to identify any such rights. Information on the 745 IETF's procedures with respect to rights in standards-track and 746 standards-related documentation can be found in BCP-11. Copies of 747 claims of rights made available for publication and any assurances of 748 licenses to be made available, or the result of an attempt made to 749 obtain a general license or permission for the use of such 750 proprietary rights by implementors or users of this specification can 751 be obtained from the IETF Secretariat. 753 The IETF invites any interested party to bring to its attention any 754 copyrights, patents or patent applications, or other proprietary 755 rights which may cover technology that may be required to practice 756 this standard. Please address the information to the IETF Executive 757 Director. 759 Full Copyright Statement 761 Copyright (C) The Internet Society (2004). All Rights Reserved. 763 This document and translations of it may be copied and furnished to 764 others, and derivative works that comment on or otherwise explain it 765 or assist in its implementation may be prepared, copied, published 766 and distributed, in whole or in part, without restriction of any 767 kind, provided that the above copyright notice and this paragraph are 768 included on all such copies and derivative works. However, this 769 document itself may not be modified in any way, such as by removing 770 the copyright notice or references to the Internet Society or other 771 Internet organizations, except as needed for the purpose of 772 developing Internet standards in which case the procedures for 773 copyrights defined in the Internet Standards process must be 774 followed, or as required to translate it into languages other than 775 English. 777 The limited permissions granted above are perpetual and will not be 778 revoked by the Internet Society or its successors or assignees. 780 This document and the information contained herein is provided on an 781 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 782 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 783 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 784 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 785 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 787 Acknowledgement 789 Funding for the RFC Editor function is currently provided by the 790 Internet Society.