idnits 2.17.1 draft-ietf-sip-replaces-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 110 has weird spacing: '...r field whe...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2002) is 8136 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 2543 (ref. 'SIP') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. 'REFER' -- Possible downref: Non-RFC (?) normative reference: ref. '3pcc' ** Obsolete normative reference: RFC 2234 (ref. 'BNF') (Obsoleted by RFC 4234) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group B. Biggs 3 Internet Draft R. Dean 4 Document: draft-ietf-sip-replaces-00.txt R. Mahy 5 (editor) 6 Expires: July 2002 January 2002 8 The SIP Replaces Header 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [RFC2026]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- Drafts 21 as reference material or to cite them other than as "work in 22 progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 1. Abstract 30 This document proposes a new header for use with the SIP call 31 control architecture. The Replaces header is used in peer-to-peer 32 call control to logically replace an existing SIP dialog with a new 33 SIP dialog. This primitive can be used to enable a variety of 34 features, for example: "Attended Transfer" and "Retrieve from Call 35 Park". Note that definition of these example features is non- 36 normative. 38 2. Conventions used in this document 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 42 this document are to be interpreted as described in RFC-2119 43 [RFC2119]. 45 Throughout this document, an "established dialog" means an active 46 SIP dialog in which the request that created the dialog has received 47 a successful final response (200 OK). An "early dialog" means 48 transaction and dialog state that exists after a request is sent 49 which would create a new dialog, but before a final response is 50 received for the initial request. 52 SIP Replaces Header 54 3. Overview 56 This document describes a [SIP] extension for distributed call 57 control as part of the SIP call control architecture [framework]. 58 The Replaces header is used in peer-to-peer call control to 59 logically replace an existing SIP dialog with a new SIP dialog. 61 INVITEs are requests which can be accepted, rejected or declined. A 62 User Agent that accepts a request with call-control semantics agrees 63 to take responsibility for setting up the appropriate requested 64 media relationships. 66 In the parlance of the SIP Call Control Model document [cc-models], 67 the "Replaces" header is used to replace one participant with 68 another in a conversation space. This functionality is already 69 available using 3rd party call control [3pcc] style call control. 70 The 3pcc model requires a central point of control which may not be 71 desirable in many environments. As such, a method of performing 72 these same call control primitives in a distributed, peer-to-peer 73 fashion is very desirable. 75 Use of a new INVITE with a new header for dialog matching was chosen 76 over making implicit associations in an incoming INVITE based on 77 call-id or other fields for the following reasons: 79 - An INVITE already has the correct semantics for a new call 81 - Using an explicit Replaces header in a new request makes the 82 intent of the request obvious. 84 - A unique call-id may be given to the replacement call. This 85 avoids call-leg matching problems in any of the clients. 87 - There are no adverse effects if the header is unsupported. 89 The Replaces header enables services such as attended call transfer, 90 retrieve from park, and transition from locally mixed conferences to 91 two party calls in a distributed peer-to-peer way. This list of 92 services is not exhaustive. Although the Replaces header is 93 frequently used in combination with the [REFER] method as used in 94 [cc-transfer], they may be used independently. 96 4. Syntax 98 4.1. The Replaces Header 100 The Replaces header indicates that the dialog identified by the 101 header is to be shut down and logically replaced by the incoming 102 INVITE in which it is contained. It is a request header only, and 103 defined here only for INVITE requests. The Replaces header MAY be 104 encrypted as part of end-to-end encryption. 106 This document adds the following entry to Table 3 of [bis]: 108 SIP Replaces Header 110 Header field where proxy ACK BYE CAN INV OPT REG 111 ------------ ----- ----- --- --- --- --- --- --- 112 Replaces R - - - o - - 114 Note that the Replaces header has specific call control semantics. 115 If both a Replaces header and another header with contradictory 116 semantics are present in a request, the request MUST be rejected 117 with a 400 "Bad Request" response. 119 4.1.1. Formal Syntax 121 The following syntax specification uses the augmented Backus-Naur 122 Form (BNF) as described in RFC-2234 [BNF]. 124 Replaces = "Replaces" ":" 1#replaces-values 125 replaces-values = callid *( ";" replaces-param ) 126 callid = token [ "@" token ] 127 replaces-param = to-tag | from-tag | extension-param 128 to-tag = "to-tag=" UUID 129 from-tag = "from-tag=" UUID 130 extension-param = token [ "=" ( token | quoted-string ) ] 132 A Replaces header MUST contain exactly one to-tag and exactly one 133 from-tag, as they are required for unique dialog matching. Since we 134 rely on the tags for matching purposes, implementations which 135 support Replaces MUST support the SIP [bis] specification, which 136 requires tags. For compatibility with early dialogs and dialogs 137 initiated by RFC2543 compliant UAs, a tag of zero must match both 138 tags of zero and null tags. 140 4.1.2. Examples 142 Replaces: 98732@sip.billybiggs.com 143 ;from-tag=r33th4x0r 144 ;to-tag=ff87ff 146 Replaces: 12345@149.112.118.3;to-tag=12345;from-tag=54321 148 Replaces: 87134@171.161.34.23;to-tag=24796;from-tag=0 150 4.2 New option tag for Require and Supported headers 152 This specification defines a new Require/Supported header option tag 153 "replaces". UAs which support the Replaces header MUST include the 154 "replaces" option in the Supported header. UAs that want explicit 155 failure notification if Replaces is not supported MAY send include 156 the "replaces" option in the Require header. 158 Example: 160 SIP Replaces Header 162 Require: replaces, 100rel 164 4.3 687 Response Code: "Dialog Terminated" 166 This specification defines a new SIP response code. The 687 "Dialog 167 Terminated" response code indicates that an early dialog has been 168 completely replaced by a new dialog. A new response code was chosen 169 from the 6xx class to prevent intervening proxies from attempting to 170 fork additional branches of the replaced dialog. 172 5. User Agent Behavior: Receiving a Replaces Header 174 5.1 Matching Dialogs 176 The Replaces header contains information used to match an existing 177 SIP dialog (call-id, to-tag, and from-tag). Upon receiving an 178 INVITE with the Replaces header, the UA MUST attempt to match this 179 information with an established or early dialog. The to-tag and 180 from-tag are matched as if they were present in an incoming request. 181 In other words the to-tag is compared to the local tag, and the 182 from-tag is compared to the remote tag. 184 If the Replaces header matches more than one dialog, the UA MAY use 185 other headers if present (ex: the Referred-By header) to attempt to 186 match a single dialog. If a single matching dialog is not found, 187 the UA MUST act as if no match is found. 189 If no match is found, the UAS MUST ignore the header and process the 190 INVITE normally. 192 OPEN ISSUE: If no match is found, should the UAS ignore the 193 header and process normally, or return a 481? 195 If the Replaces header matches a dialog which was not created with 196 an INVITE, the UAS MUST reject the request with an appropriate 197 response. 199 If the Replaces header matches a dialog which has already 200 terminated, the UA SHOULD decline the request with a 603 Declined 201 response. This prevents phantom ringing in cases like example 6.4. 203 Once a matching call-leg is found, the UAS MAY authenticate the 204 INVITE request. If the request is successfully authenticated or 205 already preauthorized, the UAS SHOULD proceed with processing. The 206 UAS MAY prompt the user to accept or reject unauthenticated 207 requests. The UAS MAY reject the request with any appropriate 208 response (for example: 603 "Decline", 403 "Forbidden", or 488 "Not 209 Acceptable Here") 211 5.2. Replaces Semantics 212 SIP Replaces Header 214 If the Replaces header matches an established active dialog, the UA 215 SHOULD attempt to accept the new INVITE, reassign the user interface 216 and other resources of the matched dialog to the new INVITE, and 217 shut down the replaced dialog by sending a BYE. If the UA cannot 218 accept the new INVITE (for example: it cannot establish required QoS 219 or keying, or it has incompatible media), the UA MUST return an 220 appropriate response and leave the matched dialog unchanged. 222 If the Replaces header matches an early dialog that was initiated by 223 the UA, the UA SHOULD attempt to accept the new INVITE. If the UA 224 cannot accept the new INVITE, the UA MUST return an appropriate 225 response and leave the matched dialog unchanged. If the UA 226 successfully accepts the new INVITE, the UA MUST reassign the 227 resources of the early dialog to the new INVITE, and CANCEL the 228 replaced early dialog. 230 If the Replaces header matches an early dialog that was not 231 initiated by the UA, the UA SHOULD attempt to provisionally accept 232 the new INVITE. In other words, the UA should attempt whatever 233 steps are necessary to return a provisional or final response 234 suitable for the state of the resources used by the matched dialog. 236 If this is successful, the UA MUST reassign the resources of the 237 early dialog to the new INVITE, and respond to the replaced early 238 dialog with a 687 "Transaction Terminated" response (defined later 239 in this document). 241 6. Usage Examples 243 The following non-normative examples are not intended to enumerate 244 all the possibilities for the usage of these extensions, but rather 245 to provide examples or ideas only. For more examples, please see 246 [service-examples]. 248 6.1. Replacing an Active Dialog 250 In this example, Alice is talking to Bob from phone1. She transfers 251 Bob to a Parking Place while she goes to the lab. When she gets 252 there she retrieves the "parked" call from phone2 by sending an 253 INVITE with Replaces to Bob with the dialog information Bob shared 254 with the Parking Place. How did Alice get this information? Maybe 255 she subscribed to this information from the Parking Place, or went 256 to a website and clicked on a URL. 258 Alice Alice Parking 259 phone1 phone2 Bob Place 260 | | | | 261 |<===============================>| | 262 | | | | 263 | Alice transfers Bob to Parking Place | 264 | | | | 265 |------------REFER/200----------->| *1 *2 | 266 SIP Replaces Header 268 | | |--INVITE/200/ACK-->| 269 |<-----------NOTIFY/200-----------|<=================>| 270 |------------BYE/200------------->| | 271 | | | | 272 | | | | 273 | Alice later retrieves call from another phone | 274 | | | | 275 | *3 |-INV w/Replaces->| | 276 | *4 |<--200-----------| *5 | 277 | |---ACK---------->|----BYE/200------->| 278 | |<===============>| | 279 | | | | 281 Message *1: Bob-> Parking Place 283 INVITE sip:parkingplace@sip.org SIP/2.0 284 To: 285 From: ;tag=7743 286 Call-ID: 425928@bobster.sip.org 287 CSeq: 1 INVITE 288 Contact: 289 Referred-By: 291 Message *2: Parking Place -> Bob 293 SIP/2.0 200 OK 294 To: ;tag=6472 295 From: ;tag=7743 296 Call-ID: 425928@bobster.sip.org 297 CSeq: 1 INVITE 298 Contact: 300 Message *3: Alice@phone2 -> Bob 302 INVITE sip:bob@bobster.sip.org 303 To: 304 From: ;tag=8983 305 Call-ID: 09870@phone2.sip.org 306 CSeq: 1 INVITE 307 Contact: 308 Replaces: 425928@bobster.sip.org;to-tag=7743;from-tag=6472 310 Message *4: Bob -> Alice@phone2 312 SIP/2.0 200 OK 313 To: ;tag=9343 314 From: ;tag=8983 315 Call-ID: 09870@phone2.sip.org 316 CSeq: 1 INVITE 317 Contact: 318 SIP Replaces Header 320 Message *5: Bob -> Parking Place 322 BYE sip:parkingplace@sip.org SIP/2.0 323 To: ;tag=6472 324 From: ;tag=7743 325 Call-ID: 425928@bobster.sip.org 326 CSeq: 2 BYE 327 Contact: 329 6.2 Replacing an Early Dialog initiated by someone else 331 In this example, a Customer tries calling a call center and for some 332 reason cannot get through properly. The customer calls an Operator 333 and asks for help. The operator calls the contact center, and upon 334 receiving a provisional response, assumes that everything is OK and 335 transfers the Customer to the Call Center, replacing the operator's 336 place in the queue. 338 Call 339 Operator Customer Center 340 | | | 341 |<--INVITE/180/200/ACK--| | 342 |<=====================>| "Hello, I'm having | 343 | | trouble calling ..." | 344 |"OK, I'll try it and | | 345 | transfer you if it | | 346 | works for me" | | 347 | | | 348 *1 |-----INVITE ----------------------------------->| 349 *2 |<----182: You are caller number 7---------------| 350 | | | 351 | completes transfer | | 352 | | | 353 |---REFER/200---------->| | 354 | |--INVITE with Replaces->| *3 355 | |<----182: caller #7-----| *4 356 |<----687 Dialog Terminated----------------------| *5 357 |-----ACK--------------------------------------->| 358 |<--NOTIFY/200----------| | 359 |---BYE/200------------>| | 360 | | ...time passes.. | 361 | | | 362 | | | 363 | | | 364 | |<---200 OK--------------| 365 |<--NOTIFY/200----------|----ACK---------------->| 366 | | | 367 | | | 369 Message *1: Operator -> Call Center 371 INVITE sip:helpdesk@clueless.org SIP/2.0 372 To: 373 SIP Replaces Header 375 From: ;tag=7743 376 Call-ID: 425928@dhcp23311.acme.com 377 CSeq: 1 INVITE 378 Contact: 379 Accept-Language: en 381 Message *2: Call Center -> Operator 383 SIP/2.0 182 You are 7th in Queue 384 To: ;tag=6472 385 From: ;tag=7743 386 Call-ID: 425928@dhcp23311.acme.com 387 CSeq: 1 INVITE 388 Contact: 390 Message *3: Customer -> Call Center 392 INVITE sip:helpdesk@frontline.clueless.org 393 To: 394 From: ;tag=8983 395 Call-ID: 09870@lobby12.acme.com 396 CSeq: 1 INVITE 397 Contact: 398 Replaces: 425928@dhcp23311.acme.com;to-tag=7743;from-tag=6472 399 Accept-Language: en 400 Referred-By: 402 Message *4: Call Center -> Customer 404 SIP/2.0 182 You are 7th in Queue 405 To: 406 From: ;tag=8983 407 Call-ID: 09870@lobby12.acme.com 408 CSeq: 1 INVITE 409 Contact: 411 Message *5: Call Center -> Operator 413 SIP/2.0 687 Dialog Terminated 414 To: ;tag=6472 415 From: ;tag=7743 416 Call-ID: 425928@dhcp23311.acme.com 417 CSeq: 1 INVITE 418 Contact: 420 6.3. Replacing an Early Dialog you initiated 422 In this example, Bob just arrived in the lab and hasn't registered 423 there yet. He hears his desk phone ring. He quickly logs into a 424 software UA on a nearby computer. Among other things, the software 425 SIP Replaces Header 427 UA subscribes to the call-state of his desk phone. When it notices 428 that his phone is ringing it offers him the choice to take the call 429 there. The software UA sends an INVITE with Replaces to Alice. 430 When Alice's UA receives this new INVITE, it CANCELs her original 431 INVITE and connects Alice to Bob. 433 Bob Bob 434 Alice desk lab 435 | | | 436 *1 |-----INVITE----------->| | 437 *2 |<----180---------------| Bob hears desk phone | 438 | | ringing from lab but | 439 | | isn't REGISTERed yet | 440 | | | 441 | |<--SUB callpackage/200--| 442 | |---NOTIFY/200---------->| 443 *3/4 |<-----INVITE with Replaces/200/ACK--------------| 444 *5/6 |------CANCEL/200------>| | 445 *7 |<-----487--------------| | 446 |------ACK------------->| | 447 | | | 448 | | | 450 Message *1: Alice -> Bob's desk phone 452 INVITE sip:bob@sip.org SIP/2.0 453 To: 454 From: ;tag=7743 455 Call-ID: 425928@phone.sip.org 456 CSeq: 1 INVITE 457 Contact: 459 Message *2: Bob's desk phone -> Alice 461 SIP/2.0 180 Ringing 462 To: ;tag=6472 463 From: ;tag=7743 464 Call-ID: 425928@phone.sip.org 465 CSeq: 1 INVITE 466 Contact: 468 Message *3: Bob in lab -> Alice 470 INVITE sip:alice@phone.sip.org 471 To: 472 From: ;tag=8983 473 Call-ID: 09870@labpc.sip.org 474 CSeq: 1 INVITE 475 Contact: 476 Replaces: 425928@phone.sip.org;to-tag=7743;from-tag=6472 478 Message *4: Alice -> Bob in lab 479 SIP Replaces Header 481 SIP/2.0 200 OK 482 To: ;tag=9232 483 From: ;tag=8983 484 Call-ID: 09870@labpc.sip.org 485 CSeq: 1 INVITE 486 Contact: 488 Message *5: Alice -> Bob's desk 490 CANCEL sip:bob@sip.org SIP/2.0 491 To: 492 From: ;tag=7743 493 Call-ID: 425928@phone.sip.org 494 CSeq: 1 CANCEL 495 Contact: 497 Message *6: Bob's desk -> Alice 499 SIP/2.0 200 OK 500 To: 501 From: ;tag=7743 502 Call-ID: 425928@phone.sip.org 503 CSeq: 1 CANCEL 504 Contact: 506 Message *7: Bob's desk -> Alice 508 SIP/2.0 487 Request Terminated 509 To: ;tag=6472 510 From: ;tag=7743 511 Call-ID: 425928@phone.sip.org 512 CSeq: 1 INVITE 513 Contact: 515 6.4. Handling Replaces for a Terminated Dialog 517 In this example, Alice, Bob, and Cathy participate in a 3-way call 518 mixed locally by Bob's UA. Bob's UA is programmed to revert to a 519 simple 2-party call when any party hangs up (including Bob). 520 Ordinarily this would be a very polite feature--Cathy and Alice 521 could continue to talk after Bob hangsup. If all three hang up at 522 about the same time, but Bob hangs up first (this will happen about 523 one-third of the time), an INVITE with Replaces header can arrive at 524 Cathy's UA shortly after she has hung up. Because Cathy's UA needs 525 to keep transaction state around for a while anyway (typically 32 526 seconds), the dialog information in the Replaces header should match 527 a terminated dialog. Cathy declines the INVITE, and cleanup 528 proceeds normally. 530 Alice Bob Cathy 531 | | 532 | Alice, Bob, and Cathy are participants in | 533 SIP Replaces Header 535 | a 3-way call mixed by Bob | 536 | | 537 |<=====================>#<======================>| 538 | | | 539 | All three hang up at | | 540 | about the same time | | 541 | | | 542 | Bob's UA tries to | | 543 | setup a 2-way call | | 544 | btwn Alice and Cathy | | 545 | | | 546 |<---REFER--------------| | 547 |----INVITE with Replaces--->XX (lost or late) | 548 | | | 549 | |<-----BYE/200-----------| the dialog is 550 | | | already dead 551 |----INVITE with Replaces----------------------->| so 552 |<---603 Declined--------------------------------| Cathy Declines 553 |----ACK---------------------------------------->| 554 |----NOTIFY/200-------->| | 555 | | | 556 |<-----BYE/200--------->| | 557 | (either side sends) | | 558 | | | 559 | | | 561 6.5. An Error Case 563 The following example illustrates one reason an INVITE with Replaces 564 may fail. In this example, both Bob and Cathy have a common audio 565 codec with Alice, but Bob and Cathy do not share a common codec. 566 When Cathy receives an INVITE from Bob with the Replaces header, 567 Cathy determines she cannot communicate, sends a 488 response to 568 Bob, and maintains her session with Alice. 570 Alice Bob Cathy 571 | | | 572 |--INVITE/200/ACK------>| | 573 | | | 574 |<=audio w/GSM codec===>| | 575 | | | 576 |----INVITE/200/ACK-------------------------------->| 577 | | | 578 |<===audio with G.729 codec========================>| 579 | | | 580 | | | 581 |--REFER/200----------->| | 582 | |--INVITE w/Replaces------->| 583 | | | 584 | | no codec in common! | 585 | | | 586 | |<-488 Not Acceptable Here--| 587 SIP Replaces Header 589 |<--NOTIFY/200----------|--ACK--------------------->| 590 | | | 591 |<=====================>| | 592 |<=================================================>| 593 | | | 595 6.6. Backwards compatibility with RFC2543 User Agents 597 In this example, both Alice and Bob use tags, but Alice wishes to 598 replace a dialog at Bob that was initiated by a User Agent that does 599 not support tags. 601 RFC2543 602 User Agent 603 Alice Bob (no tags) 604 | | | 605 | |<---------INVITE-----------| *1 606 | |----------200--------------| *2 607 | |<---------ACK--------------| 608 | | | 609 | |<=========================>| 610 | | | 611 | | | 612 *3 |--INVITE w/Replaces--->| | 613 *4 |<----200 OK------------|----------BYE------------->| *5 614 |-----ACK-------------->|<---------200--------------| 615 | | | 616 |<=====================>| | 617 | | | 619 Message *1: Oldtimer (RFC 2543 User Agent)-> Bob 621 INVITE sip:bob@sip.org SIP/2.0 622 To: 623 From: 624 Call-ID: 425928@test-ua.sip.org 625 CSeq: 1 INVITE 626 Contact: 628 Message *2: Bob -> Oldtimer 630 SIP/2.0 200 OK 631 To: ;tag=3245 632 From: 633 Call-ID: 425928@test-ua.sip.org 634 CSeq: 1 INVITE 635 Contact: 637 Message *3: Alice -> Bob 639 INVITE sip:bob@bobster.sip.org 640 To: 641 SIP Replaces Header 643 From: ;tag=8983 644 Call-ID: 09870@phone2.sip.org 645 CSeq: 1 INVITE 646 Contact: 647 Replaces: 425928@test-ua.sip.org;to-tag=3245;from-tag=0 649 Message *4: Bob -> Alice 651 SIP/2.0 200 OK 652 To: ;tag=9343 653 From: ;tag=8983 654 Call-ID: 09870@phone2.sip.org 655 CSeq: 1 INVITE 656 Contact: 658 Message *5: Bob -> Oldtimer 660 BYE sip:oldtimer@test-ua.sip.org SIP/2.0 661 To: 662 From: ;tag=3245 663 Call-ID: 425928@test-ua.sip.org 664 CSeq: 2 BYE 665 Contact: 667 7. Security Considerations 669 This extension can be used to disconnect or replace participants of 670 a multimedia conversation with an attacker. As such, invitations 671 with the Replaces header SHOULD only be accepted in a dialog in 672 which the peer has been properly authenticated using a standard SIP 673 mechanism, and for which message integrity is checked so that the 674 header cannot be added or modified in transit. 676 The extensions proposed in this document do not significantly change 677 the relative security of SIP devices. Currently in SIP, an 678 eavesdropper who learns the Call-ID, To, and From headers can easily 679 modify or destroy a dialog using a reINVITE. In practice, dialog 680 information (Call-ID, to-tag, and from-tag) for most uses of 681 Replaces is obtained via subscription to a "call-package" event 682 package or via transitivity using the REFER method. Encryption of 683 SIP signaling to insure confidentiality of this information is 684 RECOMMENDED. 686 This extension was designed to take advantage of future signature 687 parameters or authorization tokens defined by the SIP Working Group. 688 In general, call control features would benefit considerably from 689 such work. 691 8. IANA Considerations 693 8.1 Registration of "Replaces" SIP header 694 SIP Replaces Header 696 Name of Header: Replaces 698 Short form: none 700 Registrant: Rohan Mahy 701 rohan@cisco.com 703 Normative description: section 4.1 of this document 705 8.2 Registration of "replaces" SIP Option-tag 707 Name of option: replaces 709 Description: Support for the SIP Replaces header 711 SIP headers defined: Replaces 713 Normative description: This document 715 Registrant: Rohan Mahy 716 rohan@cisco.com 718 8.3 Registration of "687" SIP Response code 720 Number of response code: 687 722 Default reason phrase: Dialog Terminated 724 Registrant: Rohan Mahy 725 rohan@cisco.com 727 Normative description: section 4.3 of this document 729 9. To Do and Open Issues 731 Open Issues: 733 - MAJOR OPEN ISSUE: When no matching dialog is found should we 734 ignore the Replaces header and accept the INVITE, or reject the 735 INVITE? 737 - Are the proposals for early dialog and terminated dialog matching 738 acceptable? 740 - Is the proposed tag matching scheme for pre-bis UAs acceptable? 742 To Do: 744 - Update references 745 10. References 747 [SIP] M. Handley, E. Schooler, and H. Schulzrinne, "SIP: Session 748 Initiation Protocol", RFC2543, Internet Engineering Task Force, 749 Nov 1998. 751 [bis] Rosenberg, Schulzrinne, Camarillo, Johnston, Peterson, Sparks, 752 Handley, and Schooler, "SIP: Session Initiation Protocol", Internet- 753 Draft , IETF, Oct 2001. 755 [cc-framework] B. Campbell, "SIP Call Control - Framework ", 756 Internet Draft , IETF, 757 Mar 2001. Work in progress. 759 [cc-models] R. Mahy, "A Call Control Model for SIP", Internet Draft 760 , IETF; July 2001. Work in 761 progress. 763 [REFER] R. Sparks, "The REFER Method", Internet Draft , IETF; Oct 2001. Work in progress. 766 [cc-transfer] R. Sparks, "SIP Call Control - Transfer", Internet 767 Draft , IETF; July 2001. Work in 768 progress. 770 [3pcc] J. Rosenberg, J. Peterson, H. Schulzrinne, "Third Party Call 771 Control in SIP", Internet Draft , 772 IETF; Nov. 2000. Work in progress 774 [service-examples] A. Johnston, et al., "SIP Service Examples", 775 Internet Draft , IETF; 776 Nov 2001. Work in progress. 778 [RFC2026] S Bradner, "The Internet Standards Process -- Revision 3", 779 RFC2026 (BCP), IETF, October 1996. 781 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 782 requirement levels," Request for Comments (Best Current Practice) 783 2119, Internet Engineering Task Force, Mar. 1997. 785 [BNF] D Crocker, P Overell, "Augmented BNF for Syntax 786 Specifications: ABNF", RFC2234, IETF, Nov 1997. 788 11. Acknowledgments 790 Thanks to Robert Sparks, Alan Johnston, and Ben Campbell and many 791 other members of the SIP WG for their continued support of the cause 792 of distributed call control in SIP. 794 12. Author's Addresses 795 SIP Replaces Header 797 Billy Biggs 798 bbiggs@dumbterm.net 800 Rick Dean 801 rfc@fdd.com 803 Rohan Mahy 804 Cisco Systems 805 170 West Tasman Dr, MS: SJC-21/3/3 806 Phone: +1 408 526 8570 807 Email: rohan@cisco.com 809 Full Copyright Statement 811 "Copyright (C) The Internet Society 2002. All Rights Reserved. This 812 document and translations of it may be copied and furnished to 813 others, and derivative works that comment on or otherwise explain it 814 or assist in its implmentation may be prepared, copied, published 815 and distributed, in whole or in part, without restriction of any 816 kind, provided that the above copyright notice and this paragraph 817 are included on all such copies and derivative works. However, this 818 document itself may not be modified in any way, such as by removing 819 the copyright notice or references to the Internet Society or other 820 Internet organizations, except as needed for the purpose of 821 developing Internet standards in which case the procedures for 822 copyrights defined in the Internet Standards process must be 823 followed, or as required to translate it into languages other than 824 English. 826 The limited permissions granted above are perpetual and will not be 827 revoked by the Internet Society or its successors or assigns. 828 This document and the information contained herein is provided on an 829 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 830 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 831 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 832 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 833 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.