idnits 2.17.1 draft-ietf-sip-cc-transfer-03.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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-sip-cc-transfer-03', but the file name used is 'draft-ietf-sip-cc-transfer-03' == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of too long lines in the document, the longest one being 37 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 134: '... A REFER method MUST contain exactly ...' RFC 2119 keyword, line 136: '... Refer-To header MAY be encrypted as p...' RFC 2119 keyword, line 175: '... MUST be escaped. The ref-signature ...' RFC 2119 keyword, line 179: '... A REFER request MUST contain exactly ...' RFC 2119 keyword, line 182: '...ferred-By header SHOULD be signed to h...' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 2, 2001) is 8484 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. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Normative reference to a draft: ref. '2' -- No information found for draft-roach-sip-subscibe-notify - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' -- No information found for draft-ietf-sip-cc - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Sparks 3 Internet-Draft dynamicsoft 4 Expires: August 3, 2001 February 2, 2001 6 SIP Call Control - Transfer 7 draft-sip-cc-transfer-03 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 3, 2001. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 This document defines a SIP extension within the Call Control 39 Framework and demonstrates its use to provide Call Transfer 40 capabilities. 42 Table of Contents 44 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Changes from draft-sparks-sip-cc-transfer-02 . . . . . . . . 3 46 3. The REFER Method . . . . . . . . . . . . . . . . . . . . . . 3 47 3.1 The Refer-To Header . . . . . . . . . . . . . . . . . . . . 3 48 3.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3.2 The Referred-By Header . . . . . . . . . . . . . . . . . . . 4 50 3.2.1 A PGP based signature-scheme . . . . . . . . . . . . . . . . 5 51 3.2.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3.3 Header Field Support for the REFER Method . . . . . . . . . 6 53 3.4 Message Body Inclusion . . . . . . . . . . . . . . . . . . . 7 54 3.5 Responses within the REFER transaction . . . . . . . . . . . 7 55 3.6 Behavior of SIP User Agents . . . . . . . . . . . . . . . . 7 56 3.6.1 Accessing the referred-to resource . . . . . . . . . . . . . 7 57 3.6.2 Reporting on the results of the reference . . . . . . . . . 8 58 3.7 Behavior of SIP Registrars/Redirect Servers . . . . . . . . 8 59 3.8 Behavior of SIP Proxies . . . . . . . . . . . . . . . . . . 8 60 3.9 Prototypical REFER callflow . . . . . . . . . . . . . . . . 9 61 3.10 Security Considerations . . . . . . . . . . . . . . . . . . 9 62 4. Call Transfer . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.1 Actors and Roles . . . . . . . . . . . . . . . . . . . . . . 9 64 4.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.3 Using REFER to achieve Call Transfer . . . . . . . . . . . . 10 66 4.4 Unattended Transfer . . . . . . . . . . . . . . . . . . . . 11 67 4.4.1 Successful Unattended Transfer . . . . . . . . . . . . . . . 12 68 4.4.2 Failed Unattended Transfer . . . . . . . . . . . . . . . . . 13 69 4.5 Unattended Transfer with Consultation Hold . . . . . . . . . 13 70 4.5.1 Variation 1 : Exposes transfer target . . . . . . . . . . . 14 71 4.5.2 Variation 2 : Protects transfer target . . . . . . . . . . . 15 72 4.5.3 Consultation Hold in the presence of forking proxies . . . . 15 73 4.6 Attended Transfer . . . . . . . . . . . . . . . . . . . . . 16 74 4.7 Transfer with multiple parties . . . . . . . . . . . . . . . 16 75 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 17 76 5.1 200 vs 202 . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 5.2 Should REFER expire? . . . . . . . . . . . . . . . . . . . . 17 78 5.3 REFER is now dependent on sip-events . . . . . . . . . . . . 17 79 5.4 Registering the events with IANA . . . . . . . . . . . . . . 18 80 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 81 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18 83 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 85 1. Overview 87 This document defines a SIP[1] extension and details its use to 88 provide Call Transfer capabilities. This is part of a family of Call 89 Control extensions described in the Call Control Framework[2] 90 document. 92 The mechanisms discussed here are most closely related to 93 traditional unattended and consultation hold transfers. Discussion 94 of attended transfer (where all parties are briefly in a conference) 95 is deferred until the conferencing features in this framework are 96 addressed. 98 This work has roots in draft-ietf-sip-cc-01[4] but some basic 99 semantics are different. In particular, transfers are achieved 100 through a new method that does not terminate the original signaling 101 relationship. By disassociating transfers from the processing of 102 BYE, these changes facilitate recovery of failed transfers and 103 clarify state management in the participating entities. 105 2. Changes from draft-sparks-sip-cc-transfer-02 106 o Changed the REFER response to be immediate instead of waiting for 107 the referred action to complete 108 o Added use of NOTIFY to deliver the result of the referred action 109 o Removed the claim of easy migration from BYE/ALSO 111 3. The REFER Method 113 REFER is a SIP method as defined by RFC2543[1]. The REFER method 114 indicates that the recipient should contact a third party using the 115 contact information provided in the method. A success response 116 indicates that the recipient was able to contact the third party. 117 The REFER method follows the session's current signaling path. In 118 particular, the Request-URI of the REFER method identifies the 119 recipient. 121 Unless stated otherwise, the protocol for emitting and responding to 122 a REFER request are identical to those for a BYE request in [1]. The 123 behavior of SIP entities not implementing the REFER (or any other 124 unknown) method is explicitly defined in [1] and is not discussed 125 further here. 127 3.1 The Refer-To Header 129 Refer-To is a request-header as defined by [1]. It may only appear 130 in a REFER request. 132 Refer-To = ("Refer-To" | "r") ":" URL 134 A REFER method MUST contain exactly one Refer-To header. 136 The Refer-To header MAY be encrypted as part of end-end encryption. 138 The Contact header is an important part of the 139 Route/Record-Route mechanism and is not available 140 for this task. 142 3.1.1 Examples 144 Refer-To: sip:alice@atlanta.com 146 Refer-To: 147 sip:bob@biloxi.com?Accept-Contact=sip:bobsdesk.biloxi.com?Ca 148 ll-ID=55432@alicepc.atlanta.com 150 Refer-To: sip:carol@cleveland.com;method=SUBSCRIBE 152 Refer-To: http://www.ietf.org 154 3.2 The Referred-By Header 156 Referred-By is a request-header as defined by [1]. It can appear in 157 any request. It conveys the identity of the original REFERrer to the 158 referred-to party, optionally proving the identity and that the 159 REFERrer actually issued this reference. 161 Referred-By = ("Referred-By" | "b") ":" referrer-url ";" 162 ( referenced-url 163 | ( referenced-url ";" ref-signature ) 164 | ( ref-signature ";" referenced-url ) 165 ) 166 referrer-url = ( name-addr | addr-spec ) 167 referenced-url = "ref" "=" "<" URL ">" 168 ref-signature = signature-scheme *( ";" sig-scheme-params ) 169 signature-scheme = "scheme" "=" token 170 sig-scheme-parms = token "=" ( token | quoted-string ) 172 The referrer-url contains the SIP URL of the party sending the REFER 173 request. The referenced-url contains a copy of the URL placed in the 174 Refer-To: header. Any occurrences of < or > in the referenced-url 175 MUST be escaped. The ref-signature contains a signature over the 176 concatenation of referrer-url and referenced-url. An example 177 signature scheme is given in section 3.1.2. 179 A REFER request MUST contain exactly one Referred-By header. 181 (Open Issue: Should Refer Expire? (Section 5.2).) 182 The Referred-By header SHOULD be signed to help detection of REFERs 183 from unauthorized third parties. A signed Referred-By header SHOULD 184 include a Date header in the referrer-url to facilitate detection of 185 replay attacks. 187 A UA MAY reject a request containing an unsigned Referred-By header. 188 A UA SHOULD verify the signature on any Referred-By header it 189 receives. 191 The Referred-By header MAY be encrypted as part of end-end 192 encryption. 194 3.2.1 A PGP based signature-scheme 196 One signature-scheme for Referred-By headers uses PGP as follows: 198 signature-scheme = "scheme" "=" "pgp" 199 sig-scheme-parms = pgp-version | signed-by | pgp-signature 201 pgp-version, signed-by and pgp-signature are defined in section 15.1 202 of RFC2543, with the modification that the signature is computed 203 across the concatenation of the referrer-url and the referenced-url. 205 3.2.2 Examples 207 Referred-By: sip:alice@atlanta.com;ref= 209 Referred-By: "Bob" 210 ;ref=;scheme=pgp;pgp-version="5.0";signature="the signature" 212 (Note that in the last example, the signature would be over the 213 string "sip:bob@biloxi.comsip:alice@atlanta.com") 215 3.3 Header Field Support for the REFER Method 217 This table adds a column to tables 4 and 5 in [1], describing header 218 presence in a REFER method. See [1] for a key for the symbols used. 219 A row for the Refer-To: and Referred-By request-header should be 220 inferred, each mandatory for REFER. Refer-To is not applicable for 221 all other methods. Referred-By is a general Request header. The enc 222 and e-e columns in [1] apply to the REFER method unmodified. 224 Header Where REFER 225 Accept R - 226 Accept-Encoding R - 227 Accept-Language R o 228 Allow R - 229 Allow 405 m 230 Authorization R o 231 Call-ID gc m 232 Contact R o 233 Contact 1xx - 234 Contact 2-6xx o 235 Content-Encoding e - 236 Content-Length e o 237 Content-Type e - 238 CSeq gc m 239 Date g o 240 Encryption g o 241 Expires R o 242 From gc m 243 Hide R o 244 Max-Forwards R o 245 Organization g o 246 Priority R - 247 Proxy-Authenticate 407 o 248 Proxy-Authorization R o 249 Proxy-Require R o 250 Require R o 251 Retry-After R - 252 Retry-After 404,480,486 o 253 Retry-After 503 o 254 Retry-After 600,603 o 255 Response-Key R o 256 Record-Route R o 257 Record-Route 2xx o 258 Route R o 259 Server r o 260 Subject R - 261 Timestamp g o 262 To gc(1) m 263 Unsupported 420 o 264 User-Agent g o 265 Via gc(2) m 266 Warning r o 267 WWW-Authenticate 401 o 269 3.4 Message Body Inclusion 271 A REFER method may contain a body which SHOULD be processed 272 according to its Content-Type. 274 3.5 Responses within the REFER transaction 276 An agent responding to a REFER Method MUST return a 400 Bad Request 277 if the request contained zero or more than one Refer-To headers. An 278 agent responding to a REFER Method MUST return a 400 Bad Request if 279 the request contained zero or more than one Referred-By headers. An 280 agent (including proxies generating local responses) MAY return a 281 100 Trying or any appropriate 400-600 class response as prescribed 282 by [1]. If the recipient's agent decides to contact the resource in 283 the Refer-To header, a 200 OK response MUST be returned before the 284 REFER transaction expires. (Open Issue: Should this be a 202 285 Accepted?) (Section 5.1) 287 Editor's note - The previous version of this draft required the 288 agent responding to REFER to wait until the referred action 289 completed before sending a final response to the REFER. That final 290 response reflected the success or failure of the referred action. 291 This was infeasible due to the transaction timeout rules defined for 292 non-INVITE requests in [1]. A REFER must always receive an immediate 293 (within the lifetime of a non-INVITE transaction) final response. 295 3.6 Behavior of SIP User Agents 297 3.6.1 Accessing the referred-to resource 299 A UA receiving a well-formed REFER request SHOULD request approval 300 from the user to proceed (this request could be interactive or 301 through configuration). Upon receiving approval from the user, the 302 UA MUST contact the resource identified by the URL in the Refer-To: 303 header. Note that if the URL is a SIP URL, it could contain header 304 fields such as Call-Id that will be used to form the resulting 305 request. If the URL is a SIP URL, the Referred-By header in the 306 REFER request should be copied into the request sent to the 307 referred-to resource. 309 3.6.2 Reporting on the results of the reference 311 Once it is known whether the reference succeeded or failed, the UA 312 receiving the REFER SHOULD notify the agent sending the refer using 313 the NOTIFY mechanism defined in Event Notification in SIP[3] as if 314 the the REFER had established a subscription. In particular: 316 o The NOTIFY should reflect the To:, From:, and Call-ID headers 317 from the REFER as if they had arrived in a SUBSCRIBE. 319 o If the reference succeeded, the NOTIFY MUST contain Event: 320 refersuccess 322 o If the reference failed for any reason, or was not attempted 323 after being accepted, the NOTIFY MUST contain Event: referfailure 325 o The notifying UA SHOULD send exactly one NOTIFY with an event 326 from the profile {refersuccess,referfailure}. If multiple 327 notifications are sent, perhaps including events from other 328 extension drafts, the UA MUST NOT send both refersuccess and 329 referfailure events. 331 o Analogous to the case for SUBSCRIBE described in [3], the agent 332 that issued the REFER MUST be prepared to receive a NOTIFY before 333 the REFER transaction completes. 335 Open Issue: This makes REFER dependent on sip-events (Section 5.3) 337 Open Issue: The events will need to be registered with IANA (Section 338 5.4) 340 3.7 Behavior of SIP Registrars/Redirect Servers 342 Registrars and Redirect Servers SHOULD return a 603 to a REFER 343 request, unless they are also playing some other SIP role. 345 3.8 Behavior of SIP Proxies 347 SIP Proxies do not require modification to support the REFER method. 348 Specifically, as required by [1], a proxy should process a REFER 349 request the same way it processes an OPTIONS request. 351 3.9 Prototypical REFER callflow 353 Agent A Agent B 354 | | 355 | REFER | 356 |----------------------->| 357 | 200 OK | 358 |<-----------------------| 359 | | 360 | |-------> 361 | | (whatever) 362 | |<------ 363 | | 364 | NOTIFY | 365 |<-----------------------| 366 | 200 OK | 367 |----------------------->| 368 | | 369 | | 371 3.10 Security Considerations 373 The security requirements of [1] apply to the REFER method. 375 This mechanism relies on providing contact information for the 376 referred-to resource to the party being referred. Care should be 377 taken to provide a suitably restricted URI if the referred to 378 resource should be protected. 380 Care should be taken when implementing the logic that determines 381 whether or not to accept the REFER request. A UA not capable of 382 accessing non-SIP URLs SHOULD NOT accept REFER requests to them. 384 4. Call Transfer 386 4.1 Actors and Roles 388 There are three actors in a given transfer event, each playing one 389 of the following roles: 391 Transferee - the party being transferred to the Transfer 392 Target. 394 Transferor - the party initiating the transfer 396 Transfer Target - the new party being introduced into a call with 397 the Transferee. 399 The following roles are used to describe transfer requirements and 400 scenarios: 402 Originator - wishes to place a call to the Recipient. This actor 403 is the source of the first INVITE in a session, to 404 either a Facilitator or a Screener. 406 Facilitator - receives a call or out-of-band request from the 407 Originator, establishes a call to the Recipient 408 through the Screener, and connects the Originator to 409 the Recipient. 411 Screener - receives a call ultimately intended for the Recipient 412 and transfers the calling party to the Recipient if 413 appropriate. 415 Recipient - the party the Originator is ultimately connected to. 417 4.2 Requirements 418 1. Any party in a SIP session MUST be able to transfer any other 419 party in that session at any point in that session. 420 2. The Transferor and the Transferee MUST NOT be removed from a 421 session as part of a transfer transaction. 423 At first glance, requirement 2 may seem to indicate 424 that the user experience in a transfer must be 425 significantly different from what a current PBX or 426 Centrex user expects. As the call-flows in this 427 document show, this is not the case. A client MAY 428 preserve the current experience. In fact, without 429 this requirement, some forms of the current 430 experience (ringback on unattended transfer failure 431 for instance) will be lost. 433 3. The Transferor MUST know whether or not the transfer was 434 successful (this is significantly different from the 435 requirements of draft-ietf-sip-cc-01). 437 4.3 Using REFER to achieve Call Transfer 439 A REFER can be issued by the Transferor to cause the Transferee to 440 issue an INVITE to the Transfer-Target. Note that a successful REFER 441 transaction does not terminate the session between the Transferor 442 and the Transferee. If those parties wish to terminate their 443 session, they must do so with a subsequent BYE request. The media 444 negotiated between the transferee and the transfer target is not 445 affected by the media that had been negotiated between the 446 transferor and the transferee. In particular, the INVITE issued by 447 the Transferee will have the same SDP body it would have if he 448 Transferee had initiated that INVITE on its own. Further, the 449 disposition of the media streams between the Transferor and the 450 Transferee is not altered by the REFER method. Agents may alter a 451 session's media through additional signaling. For example, they may 452 make use of the SIP hold re-INVITE [1] or the conferencing 453 extensions provided by this framework. 455 4.4 Unattended Transfer 457 Unattended Transfer consists of the Transferor providing the 458 Transfer Target's contact to the Transferee. The Transferee attempts 459 to establish a session using that contact and reports the results of 460 that attempt to the Transferor. The signaling relationship between 461 the Transferor and Transferee is not terminated, so the call is 462 recoverable if the Transfer Target cannot be reached. Note that the 463 Transfer Target's contact information has been exposed to the 464 Transferee. The provided contact can be used to make new calls in 465 the future. The diagrams below show indicate the first line of each 466 message. All messages in a particular diagram share the same 467 Call-ID. In these diagrams, media is managed through reINVITE holds, 468 but other mechanisms (mixing multiple media streams at the UA or 469 using the conferencing extensions for example) are valid. 471 4.4.1 Successful Unattended Transfer 473 Transferor Transferee Transfer 474 | | Target 475 | INVITE | | 476 |<-------------------| | 477 | 200 OK | | 478 |------------------->| | 479 | ACK | | 480 |<-------------------| | 481 | INVITE (hold) | | 482 |------------------->| | 483 | 200 OK | | 484 |<-------------------| | 485 | ACK | | 486 |------------------->| | 487 | REFER | | 488 |------------------->| | 489 | 200 OK | | 490 |<-------------------| | 491 | | INVITE | 492 | |------------------->| 493 | | 200 OK | 494 | |<-------------------| 495 | | ACK | 496 | |------------------->| 497 | NOTIFY (refersuccess) | 498 |<-------------------| | 499 | 200 OK | | 500 |------------------->| | 501 | BYE | | 502 |------------------->| | 503 | 200 OK | | 504 |<-------------------| | 505 | | BYE | 506 | |<-------------------| 507 | | 200 OK | 508 | |------------------->| 510 4.4.2 Failed Unattended Transfer 512 Transferor Transferee Transfer 513 | | Target 514 | | | 515 | INVITE | | 516 |<-------------------| | 517 | 200 OK | | 518 |------------------->| | 519 | ACK | | 520 |<-------------------| | 521 | INVITE (hold) | | 522 |------------------->| | 523 | 200 OK | | 524 |<-------------------| | 525 | ACK | | 526 |------------------->| | 527 | REFER | | 528 |------------------->| | 529 | 200 OK | | 530 |<-------------------| | 531 | | INVITE | 532 | |------------------->| 533 | | 486 Busy Here | 534 | |<-------------------| 535 | | ACK | 536 | |------------------->| 537 | NOTIFY (referfailure) | 538 |<-------------------| | 539 | 200 OK | | 540 |------------------->| | 541 | INVITE (unhold) | | 542 |------------------->| | 543 | 200 OK | | 544 |<-------------------| | 545 | ACK | | 546 |------------------->| | 547 | BYE | | 548 |------------------->| | 549 | 200 OK | | 550 |<-------------------| | 552 4.5 Unattended Transfer with Consultation Hold 554 Transfer with Consultation Hold involves a session between the 555 transferor and the transfer target before the transfer actually 556 takes place. This is implemented with SIP Hold and Unattended 557 Transfer as described above. 559 4.5.1 Variation 1 : Exposes transfer target 561 The transferor places the transferee on hold, establishes a call 562 with the transfer target to alert them to the impending transfer, 563 terminates the connection with the transfer target, then proceeds 564 with unattended transfer as above. This variation can be used to 565 provide an experience similar to that expected by current PBX and 566 Centrex users. 568 To (hopefully) improve clarity, non-REFER transactions have been 569 collapsed into one indicator with the arrow showing the direction of 570 the request. 572 Transferor Transferee Transfer 573 | | Target 574 | | | 575 Call-ID:1 | INVITE/200 OK/ACK | | 576 |<-------------------| | 577 Call-ID:1 | INVITE (hold)/200 OK/ACK | 578 |------------------->| | 579 Call-ID:2 | INVITE/200 OK/ACK | | 580 |---------------------------------------->| 581 Call-ID:2 | BYE/200 OK | | 582 |---------------------------------------->| 583 Call-ID:1 | REFER | | 584 |------------------->| | 585 | 200 OK | | 586 |<-------------------| | 587 Call-ID:1 | | INVITE/200 OK/ACK | 588 | |------------------->| 589 Call-ID:1 | NOTIFY (refersuccess) | 590 |<-------------------| | 591 | 200 OK | | 592 |------------------->| | 593 Call-ID:1 | BYE/200 OK | | 594 |------------------->| | 595 Call-ID:1 | | BYE/200 OK | 596 | |<-------------------| 598 4.5.2 Variation 2 : Protects transfer target 600 The transferor places the transferee on hold, establishes a call 601 with the transfer target and then reverses their roles, transferring 602 the original transfer target to the original transferee. This has 603 the advantage of hiding information about the original transfer 604 target from the original transferee. On the other hand, the 605 Transferee's experience is different that in current systems. The 606 Transferee is effectively "called back" by the Transfer Target. 608 Transferor Transferee Transfer 609 | | Target 610 | | | 611 Call-ID:1 | INVITE/200 OK/ACK | | 612 |<-------------------| | 613 Call-ID:1 | INVITE (hold)/200 OK/ACK | 614 |------------------->| | 615 Call-ID:2 | INVITE/200 OK/ACK | | 616 |---------------------------------------->| 617 Call-ID:2 | INVITE (hold)/200 OK/ACK | 618 |---------------------------------------->| 619 Call-ID:2 | REFER | | 620 |---------------------------------------->| 621 | 200 Trying | | 622 |<----------------------------------------| 623 Call-ID:2 | | INVITE/200 OK/ACK | 624 | |<-------------------| 625 Call-ID:2 | NOTIFY (refersuccess) | 626 |<----------------------------------------| 627 | 200 OK | | 628 |------------------->| | 629 Call-ID:1 | BYE/200 OK | | 630 |------------------->| | 631 Call-ID:2 | BYE/200 OK | | 632 |---------------------------------------->| 633 Call-ID:2 | | BYE/200 OK | 634 | |------------------->| 636 4.5.3 Consultation Hold in the presence of forking proxies 638 It is worth noting that the examples given above abstract away any 639 proxies that might be between the three parties. In 4.5.1 for 640 example, the URL used to reach the Transfer Target may go through a 641 forking proxy. There is no guarantee that the Transferee's and 642 Transferor's invitations to the Transfer Target will reach the same 643 endpoint. If the proxy forked in parallel, both invitations could 644 cause multiple endpoints to ring. To increase the probability of the 645 desired behavior of having the referred invite reach and ring only 646 the same endpoint as the consultation invite, the Transferor SHOULD 647 issue the REFER request with the Refer-To: header containing the 648 Contact the Transfer Target provided in its 200 OK to the 649 Transferor's INVITE. If that REFER fails, the Transferor SHOULD 650 issue another REFER with the Refer-To: header containing the URL it 651 used to reach the Transfer Target, augmented with an Accept-Contact 652 header containing the Contact the Transfer Target provided. 654 4.6 Attended Transfer 656 In an attended transfer, the three actors participate in an ad-hoc 657 conference as part of the event. Discussion of the implementation of 658 attended transfer is thus deferred until the conferencing portion of 659 the Call Control framework has been addressed. 661 4.7 Transfer with multiple parties 663 In this example the Originator places call to the Facilitator who 664 reaches the Recipient through the Screener. The Recipient's contact 665 information is exposed to the Facilitator and the Originator. This 666 example is provided for clarification of the semantics of the REFER 667 method only and should not be used as the design of an 668 implementation. 670 Originator Facilitator Screener Recipient 671 Call-ID | | | | 672 1 |INVITE/200 OK/ACK | |"Get Fred for me!" 673 |----------->| | | "Right away!" 674 1 |INVITE (hold)/200 OK/ACK | | 675 |<-----------| | | 676 2 | |INVITE/200 OK/ACK |"I have a call 677 | |----------->| |from Mary for Fred" 678 2 | |INVITE (hold)/200 OK/ACK "Hold please" 679 | |<-----------| | 680 3 | | |INVITE/200 OK/ACK 681 | | |--------->|"You have a call 682 | | | |from Mary" 683 | | | | "Put her through" 684 3 | | |INVITE (hold)/200 OK/ACK 685 | | |--------->| 686 2 | |REFER | | 687 | |<-----------| | 688 | |200 OK | | 689 | |----------->| | 690 2 | |INVITE/200 OK/ACK | 691 | |---------------------->|"This is Fred" 692 2 | |NOTIFY (refersuccess) | "Please hold for 693 | |----------->| | Mary" 694 | |200 OK | | 695 | |<-----------| | 697 2 | |BYE/200 OK | | 698 | |<-----------| | 699 3 | | |BYE/200 OK| 700 | | |--------->| 701 2 | |INVITE (hold)/200 OK/ACK 702 | |---------------------->| 703 1 |REFER | | | 704 |<-----------| | | 705 |200 OK | | | 706 |----------->| | | 707 1 |INVITE/200 OK/ACK | | 708 |----------------------------------->| "Hey Fred" 709 1 |NOTIFY (refersuccess) | | "Hello Mary" 710 |----------->| | | 711 |200 OK | | | 712 |<-----------| | | 713 1 |BYE/200 OK | | | 714 |<-----------| | | 715 2 | |BYE/200 OK | | 716 | |---------------------->| 717 1 |BYE/200 OK | | | 718 |<-----------------------------------| "See you later" 720 5. Open Issues 722 5.1 200 vs 202 724 Should an agent accepting a NOTIFY request return a 200 OK or a 202 725 Accepted? 727 5.2 Should REFER expire? 729 Since REFER is effectively establishing a Subscription per [3], 730 should the REFER request be required to contain an Expires: header? 731 This would allow REFERer to specify how long he's willing to wait 732 for the reference to complete. If the referred action exceeds that 733 time, the agent processing the refer could return referfailure, stop 734 trying, and free the state it needed for that processing. Without 735 this or a similar mechanism, both agents involved in a REFER 736 transaction could be forced to hold state indefinitely. 738 5.3 REFER is now dependent on sip-events 740 By introducing NOTIFY, this work is prevented from moving to RFC 741 until the sip-events draft moves to that level (that work is 742 currently an individual submission). What needs to happen to our 743 deliverable schedule to allow for completing the sip-events work? 745 5.4 Registering the events with IANA 747 When we near the end of the process, the events we agree to use for 748 this purpose (currently proposed as refersuccess and referfailure) 749 will need to be registered with IANA per [3]. 751 6. Acknowledgments 753 This draft is a collaborative product of the SIP working group. The 754 editor thanks the following for their early contributions to this 755 work: Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston, 756 Kevin Summers and Dean Willis. 758 References 760 [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 761 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 763 [2] Campbell, B., "Framework for SIP Call Control Extensions", 764 draft-ietf-sip-cc-framework-00 (work in progress), March 2000. 766 [3] Roach, A., "Event Notification in SIP", 767 draft-roach-sip-subscibe-notify-02 (work in progress), November 768 2000. 770 [4] Schulzrinne, H. and J. Rosenberg, "SIP Call Control Services", 771 draft-ietf-sip-cc-01 (work in progress - expired), June 1999. 773 Author's Address 775 Robert J. Sparks 776 dynamicsoft 777 5100 Tennyson Parkway 778 Suite 1200 779 Plano, TX 75024 781 email: rsparks@dynamicsoft.com 783 Full Copyright Statement 785 Copyright (C) The Internet Society (2001). All Rights Reserved. 787 This document and translations of it may be copied and furnished to 788 others, and derivative works that comment on or otherwise explain it 789 or assist in its implementation may be prepared, copied, published 790 and distributed, in whole or in part, without restriction of any 791 kind, provided that the above copyright notice and this paragraph 792 are included on all such copies and derivative works. However, this 793 document itself may not be modified in any way, such as by removing 794 the copyright notice or references to the Internet Society or other 795 Internet organizations, except as needed for the purpose of 796 developing Internet standards in which case the procedures for 797 copyrights defined in the Internet Standards process must be 798 followed, or as required to translate it into languages other than 799 English. 801 The limited permissions granted above are perpetual and will not be 802 revoked by the Internet Society or its successors or assigns. 804 This document and the information contained herein is provided on an 805 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 806 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 807 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 808 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 809 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 811 Acknowledgement 813 Funding for the RFC editor function is currently provided by the 814 Internet Society.