idnits 2.17.1 draft-ietf-sip-cc-transfer-04.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 : ---------------------------------------------------------------------------- ** 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 3 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 126: '...tated that REFER MAY occur outside an ...' RFC 2119 keyword, line 147: '... A REFER request MAY be placed outside...' RFC 2119 keyword, line 148: '...an INVITE. REFER MAY be Record-Routed,...' RFC 2119 keyword, line 150: '... call-leg MUST follow the Route/Reco...' RFC 2119 keyword, line 161: '... A REFER method MUST contain exactly ...' (31 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 2001) is 8452 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 (~~), 2 warnings (==), 7 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 27, 2001 February 26, 2001 6 SIP Call Control - Transfer 7 draft-ietf-sip-cc-transfer-04 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 27, 2001. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 This document defines a SIP extension, REFER, and demonstrates its 39 use to provide Call Transfer capabilities. This work is part of the 40 Call Control Framework. 42 Table of Contents 44 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Changes from draft-sparks-sip-cc-transfer-03 . . . . . . . 3 46 3. The REFER Method . . . . . . . . . . . . . . . . . . . . . 4 47 3.1 The Refer-To Header . . . . . . . . . . . . . . . . . . . 4 48 3.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3.2 The Referred-By Header . . . . . . . . . . . . . . . . . . 5 50 3.2.1 A PGP based signature-scheme . . . . . . . . . . . . . . . 5 51 3.2.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . 8 56 3.6.1 Accessing the referred-to resource . . . . . . . . . . . . 8 57 3.6.2 Reporting on the results of the reference . . . . . . . . 8 58 3.6.2.1 Using NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 8 59 3.6.2.2 The body of the NOTIFY . . . . . . . . . . . . . . . . . . 8 60 3.7 Behavior of SIP Registrars/Redirect Servers . . . . . . . 9 61 3.8 Behavior of SIP Proxies . . . . . . . . . . . . . . . . . 9 62 3.9 Prototypical REFER callflow . . . . . . . . . . . . . . . 10 63 3.10 Security Considerations . . . . . . . . . . . . . . . . . 11 64 3.10.1 Circumventing privacy . . . . . . . . . . . . . . . . . . 11 65 3.10.2 Circumventing security . . . . . . . . . . . . . . . . . . 12 66 3.10.3 Limiting the breach . . . . . . . . . . . . . . . . . . . 12 67 4. Call Transfer . . . . . . . . . . . . . . . . . . . . . . 13 68 4.1 Actors and Roles . . . . . . . . . . . . . . . . . . . . . 13 69 4.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . 13 70 4.3 Using REFER to achieve Call Transfer . . . . . . . . . . . 14 71 4.4 Unattended Transfer . . . . . . . . . . . . . . . . . . . 14 72 4.4.1 Successful Unattended Transfer . . . . . . . . . . . . . . 15 73 4.4.2 Failed Unattended Transfer . . . . . . . . . . . . . . . . 16 74 4.5 Unattended Transfer with Consultation Hold . . . . . . . . 16 75 4.5.1 Variation 1 : Exposes transfer target . . . . . . . . . . 17 76 4.5.2 Variation 2 : Protects transfer target . . . . . . . . . . 18 77 4.5.3 Consultation Hold in the presence of forking proxies . . . 18 78 4.6 Attended Transfer . . . . . . . . . . . . . . . . . . . . 19 79 4.7 Transfer with multiple parties . . . . . . . . . . . . . . 19 80 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 20 81 5.1 REFER is now dependent on sip-events . . . . . . . . . . . 20 82 5.2 Registering the events with IANA . . . . . . . . . . . . . 20 83 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 20 84 References . . . . . . . . . . . . . . . . . . . . . . . . 20 85 Author's Address . . . . . . . . . . . . . . . . . . . . . 21 86 Full Copyright Statement . . . . . . . . . . . . . . . . . 22 88 1. Overview 90 This document defines a SIP[1] extension, REFER, and details its use 91 to provide Call Transfer capabilities. This is part of a family of 92 Call Control extensions described in the Call Control Framework[2] 93 document. 95 Editor's note: Per consensus at the February interim WG meeting, the 96 two parts of this document, the definition of REFER and its use to 97 achieve transfer, will be separated into separate documents. That 98 separation will take place with the next revision of this document. 100 The mechanisms discussed here are most closely related to 101 traditional unattended and consultation hold transfers. Discussion 102 of attended transfer (where all parties are briefly in a conference) 103 is deferred until the conferencing features in this framework are 104 addressed. 106 This work has roots in draft-ietf-sip-cc-01[4] but some basic 107 semantics are different. In particular, transfers are achieved 108 through a new method that does not terminate the original signaling 109 relationship. By disassociating transfers from the processing of 110 BYE, these changes facilitate recovery of failed transfers and 111 clarify state management in the participating entities. 113 2. Changes from draft-sparks-sip-cc-transfer-03 115 Editor's note: The changes for this revision focused on the changes 116 to the NOTIFY response mechanism discussed at February's interim 117 meeting, and clarification to the REFER method itself. As mentioned 118 above, the intent is to separate this document into two. The split 119 was postponed a version to ensure the edits to REFER/NOTIFY would be 120 reflected in the ID repository in time for discussion at IETF 50. 122 o Modified contents of NOTIFYs to reflect the consensus at the 123 interim meeting. One event type, with an application/sip body 124 representing the information to be returned. 125 o Added message detail to the prototypical flow 126 o More explicitly stated that REFER MAY occur outside an existing 127 call-leg 128 o Reinforced that REFER can be record-routed 129 o Made the presence of a Contact header mandatory 130 o Changed the positive response to a REFER request to 202 Accepted 131 instead of 200 OK 132 o Corrected editing errors in examples and message diagrams 134 3. The REFER Method 136 REFER is a SIP method as defined by RFC2543[1]. The REFER method 137 indicates that the recipient (identified by the Request-URI) should 138 contact a third party using the contact information provided in the 139 method. A success response indicates that the recipient was able to 140 contact the third party. 142 Unless stated otherwise, the protocol for emitting and responding to 143 a REFER request are identical to those for a BYE request in [1]. The 144 behavior of SIP entities not implementing the REFER (or any other 145 unknown) method is explicitly defined in [1]. 147 A REFER request MAY be placed outside the scope of a call-leg 148 created with an INVITE. REFER MAY be Record-Routed, hence MUST 149 contain a single Contact header. REFERs occurring inside an existing 150 call-leg MUST follow the Route/Record-Route logic of that call-leg. 151 REFERs occurring outside an existing call-leg effectively create a 152 new call-leg following the behavior of SUBSCRIBE specified [3]. 154 3.1 The Refer-To Header 156 Refer-To is a request-header as defined by [1]. It may only appear 157 in a REFER request. 159 Refer-To = ("Refer-To" | "r") ":" URL 161 A REFER method MUST contain exactly one Refer-To header. 163 The Refer-To header MAY be encrypted as part of end-end encryption. 165 The Contact header is an important part of the Route/Record-Route 166 mechanism and is not available for this task. 168 3.1.1 Examples 170 Refer-To: sip:alice@atlanta.com 172 Refer-To: sip:bob@biloxi.com?Accept-Contact=sip:bobsdesk. 173 biloxi.com&Call-ID=55432@alicepc.atlanta.com 175 Refer-To: sip:carol@cleveland.com;method=SUBSCRIBE 177 Refer-To: http://www.ietf.org 179 Long headers are line-wrapped here for clarity only. 181 3.2 The Referred-By Header 183 Referred-By is a request-header as defined by [1]. It can appear in 184 any request. It conveys the identity of the original REFERrer to the 185 referred-to party, optionally proving the identity and that the 186 REFERrer actually issued this reference. 188 Referred-By = ("Referred-By" | "b") ":" referrer-url ";" 189 ( referenced-url 190 | ( referenced-url ";" ref-signature ) 191 | ( ref-signature ";" referenced-url ) 192 ) 193 referrer-url = ( name-addr | addr-spec ) 194 referenced-url = "ref" "=" "<" URL ">" 195 ref-signature = signature-scheme *( ";" sig-scheme-params ) 196 signature-scheme = "scheme" "=" token 197 sig-scheme-parms = token "=" ( token | quoted-string ) 199 The referrer-url contains the SIP URL of the party sending the REFER 200 request. The referenced-url contains a copy of the URL placed in the 201 Refer-To: header. Any occurrences of < or > in the referenced-url 202 MUST be escaped. The ref-signature contains a signature over the 203 concatenation of referrer-url and referenced-url. An example 204 signature scheme is given in section 3.1.2. 206 A REFER request MUST contain exactly one Referred-By header. 208 The Referred-By header SHOULD be signed to help detection of REFERs 209 from unauthorized third parties. A signed Referred-By header SHOULD 210 include a Date header in the referrer-url to facilitate detection of 211 replay attacks. 213 A UA MAY reject a request containing an unsigned Referred-By header. 214 A UA SHOULD verify the signature on any Referred-By header it 215 receives. 217 The Referred-By header MAY be encrypted as part of end-end 218 encryption. 220 3.2.1 A PGP based signature-scheme 222 One signature-scheme for Referred-By headers uses PGP as follows: 224 signature-scheme = "scheme" "=" "pgp" 225 sig-scheme-parms = pgp-version | signed-by | pgp-signature 227 pgp-version, signed-by and pgp-signature are defined in section 15.1 228 of RFC2543, with the modification that the signature is computed 229 across the concatenation of the referrer-url and the referenced-url. 231 3.2.2 Examples 233 Referred-By: sip:alice@atlanta.com;ref= 235 Referred-By: "Bob" ; 236 ref=;scheme=pgp; 237 pgp-version="5.0";signature="the signature" 239 (Note that in the last example, the signature would be over the 240 string "sip:bob@biloxi.comsip:alice@atlanta.com") 242 3.3 Header Field Support for the REFER Method 244 This table adds a column to tables 4 and 5 in [1], describing header 245 presence in a REFER method. See [1] for a key for the symbols used. 246 A row for the Refer-To: and Referred-By request-header should be 247 inferred, each mandatory for REFER. Refer-To is not applicable for 248 all other methods. Referred-By is a general Request header. The enc 249 and e-e columns in [1] apply to the REFER method unmodified. 251 Header Where REFER 252 Accept R - 253 Accept-Encoding R - 254 Accept-Language R o 255 Allow R - 256 Allow 405 m 257 Authorization R o 258 Call-ID gc m 259 Contact R m 260 Contact 1xx - 261 Contact 2-6xx o 262 Content-Encoding e - 263 Content-Length e o 264 Content-Type e - 265 CSeq gc m 266 Date g o 267 Encryption g o 268 Expires R o 269 From gc m 270 Hide R o 271 Max-Forwards R o 272 Organization g o 273 Priority R - 274 Proxy-Authenticate 407 o 275 Proxy-Authorization R o 276 Proxy-Require R o 277 Require R o 278 Retry-After R - 279 Retry-After 404,480,486 o 280 Retry-After 503 o 281 Retry-After 600,603 o 282 Response-Key R o 283 Record-Route R o 284 Record-Route 2xx o 285 Route R o 286 Server r o 287 Subject R - 288 Timestamp g o 289 To gc(1) m 290 Unsupported 420 o 291 User-Agent g o 292 Via gc(2) m 293 Warning r o 294 WWW-Authenticate 401 o 296 3.4 Message Body Inclusion 298 A REFER method may contain a body which SHOULD be processed 299 according to its Content-Type. 301 3.5 Responses within the REFER transaction 303 An agent responding to a REFER Method MUST return a 400 Bad Request 304 if the request contained zero or more than one Refer-To headers. An 305 agent responding to a REFER Method MUST return a 400 Bad Request if 306 the request contained zero or more than one Referred-By headers. An 307 agent (including proxies generating local responses) MAY return a 308 100 Trying or any appropriate 400-600 class response as prescribed 309 by [1]. If the recipient's agent decides to contact the resource in 310 the Refer-To header, a 202 Accepted response MUST be returned before 311 the REFER transaction expires. 313 Editor's note - earlier versions of this draft required the agent 314 responding to REFER to wait until the referred action completed 315 before sending a final response to the REFER. That final response 316 reflected the success or failure of the referred action. This was 317 infeasible due to the transaction timeout rules defined for 318 non-INVITE requests in [1]. A REFER must always receive an immediate 319 (within the lifetime of a non-INVITE transaction) final response. 321 3.6 Behavior of SIP User Agents 323 3.6.1 Accessing the referred-to resource 325 A UA receiving a well-formed REFER request SHOULD request approval 326 from the user to proceed (this request could be interactive or 327 through configuration). Upon receiving approval from the user, the 328 UA MUST contact the resource identified by the URL in the Refer-To: 329 header. Note that if the URL is a SIP URL, it could contain header 330 fields such as Call-Id that will be used to form the resulting 331 request. If the URL is a SIP URL, the Referred-By header in the 332 REFER request should be copied into the request sent to the 333 referred-to resource. 335 3.6.2 Reporting on the results of the reference 337 3.6.2.1 Using NOTIFY 339 Once it is known whether the reference succeeded or failed, the UA 340 receiving the REFER SHOULD notify the agent sending the refer using 341 the NOTIFY mechanism defined in Event Notification in SIP[3] as if 342 the the REFER had established a subscription. In particular: 344 o Each NOTIFY should reflect the To:, From:, and Call-ID headers 345 from the REFER as if they had arrived in a SUBSCRIBE. 347 o Each NOTIFY MUST contain an event header of Event: refer 349 o Each NOTIFY MUST contain a body of type "application/sip". The 350 contents of this body are detailed in Section 3.6.2.2 352 o Analogous to the case for SUBSCRIBE described in [3], the agent 353 that issued the REFER MUST be prepared to receive a NOTIFY before 354 the REFER transaction completes. 356 Open Issue: This makes REFER dependent on sip-events (Section 5.1) 358 Open Issue: The refer event will need to be registered with IANA 359 (Section 5.2) 361 3.6.2.2 The body of the NOTIFY 363 Each NOTIFY MUST contain a body of type "application/sip". This body 364 MUST begin with a SIP Response Status-Line as defined in [1]. The 365 response class in this status line indicates the success of the 366 referred action. The body MAY contain other SIP headers to provide 367 information about the outcome of the referenced action. 369 A minimal, but complete, implementation can respond with a single 370 NOTIFY containing either the body: 372 SIP/2.0 200 OK 374 if the reference was successful or the body: 376 SIP/2.0 503 Service Unavailable 378 if the reference failed. 380 An implementation MAY include more of a SIP message in that body to 381 convey more information. Warning headers received in responses to 382 the referred action are good candidates. In fact, if the reference 383 was to a SIP URL, entire response to the referenced action could be 384 returned. However, doing so could have grave security repercussions 385 (see Section 3.10). Implementers must carefully consider what they 386 choose to include. 388 Note that if the reference was to a non-SIP URL, status in any 389 NOTIFYs to the referrer must still be in the form of SIP Response 390 Status-Lines. The minimal implementation discussed above is 391 sufficient to provide a basic indication of success or failure. For 392 example, if a client receives a REFER to a HTTP URL, and is 393 successful in accessing the resource, its NOTIFY to the referrer can 394 contain the application/sip body of "SIP/2.0 200 OK" 396 3.7 Behavior of SIP Registrars/Redirect Servers 398 Registrars and Redirect Servers SHOULD return a 603 to a REFER 399 request, unless they are also playing some other SIP role. 401 3.8 Behavior of SIP Proxies 403 SIP Proxies do not require modification to support the REFER method. 404 Specifically, as required by [1], a proxy should process a REFER 405 request the same way it processes an OPTIONS request. 407 3.9 Prototypical REFER callflow 409 Agent A Agent B 410 | | 411 | REFER | 412 |----------------------->| 413 | 202 Accepted | 414 |<-----------------------| 415 | | 416 | |-------> 417 | | (whatever) 418 | |<------ 419 | | 420 | NOTIFY | 421 |<-----------------------| 422 | 200 OK | 423 |----------------------->| 424 | | 425 | | 427 Here are examples of what the four messages between Agent A and 428 Agent B might look like if the reference to (whatever) that Agent B 429 makes is successful: 430 Message One 432 REFER sip:b@agentland SIP/2.0 433 Via: SIP/2.0/UDP agenta.agentland 434 To: sip:b@agentland 435 From: sip:a@agentland;tag=193402342 436 Call-ID: 898234234@agenta.agentland 437 CSeq: 93809823 REFER 438 Refer-To: (whatever URL) 439 Referred-By: ;ref=; 440 scheme=pgp;pgp-version="5.0";signature="signature goes here" 441 Contact: sip:a@agentland 442 Content-Length: 0 444 Message Two 446 SIP/2.0 202 Accepted 447 Via: SIP/2.0/UDP agenta.agentland 448 To: sip:b@agentland;tag=4992881234 449 From: sip:a@agentland;tag=193402342 450 Call-ID: 898234234@agenta.agentland 451 CSeq: 93809823 REFER 452 Contact: sip:b@agentland 453 Content-Length: 0 455 Message Three 456 NOTIFY sip:a@agentland SIP/2.0 457 Via: SIP/2.0/UDP agentb.agentland 458 To: sip:a@agentland;tag=193402342 459 From: sip:b@agentland;tag=4992881234 460 Call-ID: 898234234@agenta.agentland 461 CSeq: 1993402 NOTIFY 462 Event: refer 463 Contact: sip:b@agentland 464 Content-Type: application/sip 465 Content-Length: 16 467 SIP/2.0 200 OK 469 Message Four 471 SIP/2.0 200 OK 472 Via: SIP/2.0/UDP agentb.agentland 473 To: sip:a@agentland;tag=193402342 474 From: sip:b@agentland;tag=4992881234 475 Call-ID: 898234234@agenta.agentland 476 CSeq: 1993402 NOTIFY 477 Contact: sip:a@agentland 478 Content-Length: 0 480 3.10 Security Considerations 482 The security requirements of [1] apply to the REFER method. 484 This mechanism relies on providing contact information for the 485 referred-to resource to the party being referred. Care should be 486 taken to provide a suitably restricted URI if the referred to 487 resource should be protected. 489 Care should be taken when implementing the logic that determines 490 whether or not to accept the REFER request. A UA not capable of 491 accessing non-SIP URLs SHOULD NOT accept REFER requests to them. 493 Using application/sip bodies to return the progress and results of a 494 REFER request is extremely powerful. Careless use of that capability 495 will compromise security and privacy. Here are a couple of simple, 496 somewhat contrived, examples to demonstrate the potential for harm. 498 3.10.1 Circumventing privacy 500 Suppose Alice has a user-agent that accepts REFER requests to SIP 501 INVITE URLs, and NOTIFYs the referrer of the progress of the INVITE 502 by copying each response to the INVITE into the body of a NOTIFY. 504 Suppose further that Carol has a reason to avoid Mallory and has 505 configured her system at her proxy to only accept calls from a 506 certain set of people she trusts (including Alice), so that Mallory 507 doesn't learn when she's around, or what user agent she's actually 508 using. 510 Mallory can send a REFER to Alice, with a Refer-To: indicating 511 Carol. If Alice can reach Carol, the 200 OK Carol sends gets 512 returned to Mallory in a NOTIFY, letting him know not only that 513 Carol is around, but also the IP address of the agent she's using. 515 3.10.2 Circumventing security 517 Suppose Alice, with the same user agent as above, is working at a 518 company that is working on the greatest SIP device ever invented - 519 the SIP FOO. The company has been working for months building the 520 device and the marketing materials, carefully keeping the idea, even 521 the name of the idea secret (since a FOO is one of those things that 522 anybody could do if they'd just had the idea first). FOO is up and 523 running, and anyone at the company can use it, but it's not 524 available outside the company firewall. 526 Mallory has heard rumor that Alice's company is onto something big, 527 and has even managed to get his hands on a URL that he suspects 528 might have something to do with it. He sends a REFER to ALICE with 529 the mysterious URL and as Alice connects to the FOO, Mallory gets 530 NOTIFYs with bodies containing 532 Server: FOO/v0.9.7 534 3.10.3 Limiting the breach 536 For each of these cases, and in general, returning a carefully 537 selected subset of the information available about the progress of 538 the reference through the NOTIFYs mitigates risk. The minimal 539 implementation described in Section 3.6.2.2 exposes the least 540 information about what the agent operating on the REFER request has 541 done, and is least likely to be a useful tool for malicious users. 543 4. Call Transfer 545 4.1 Actors and Roles 547 There are three actors in a given transfer event, each playing one 548 of the following roles: 550 Transferee - the party being transferred to the Transfer 551 Target. 553 Transferor - the party initiating the transfer 555 Transfer Target - the new party being introduced into a call with 556 the Transferee. 558 The following roles are used to describe transfer requirements and 559 scenarios: 561 Originator - wishes to place a call to the Recipient. This actor 562 is the source of the first INVITE in a session, to 563 either a Facilitator or a Screener. 565 Facilitator - receives a call or out-of-band request from the 566 Originator, establishes a call to the Recipient 567 through the Screener, and connects the Originator to 568 the Recipient. 570 Screener - receives a call ultimately intended for the Recipient 571 and transfers the calling party to the Recipient if 572 appropriate. 574 Recipient - the party the Originator is ultimately connected to. 576 4.2 Requirements 577 1. Any party in a SIP session MUST be able to transfer any other 578 party in that session at any point in that session. 579 2. The Transferor and the Transferee MUST NOT be removed from a 580 session as part of a transfer transaction. 582 At first glance, requirement 2 may seem to indicate 583 that the user experience in a transfer must be 584 significantly different from what a current PBX or 585 Centrex user expects. As the call-flows in this 586 document show, this is not the case. A client MAY 587 preserve the current experience. In fact, without 588 this requirement, some forms of the current 589 experience (ringback on unattended transfer failure 590 for instance) will be lost. 592 3. The Transferor MUST know whether or not the transfer was 593 successful (this is significantly different from the 594 requirements of draft-ietf-sip-cc-01). 596 4.3 Using REFER to achieve Call Transfer 598 A REFER can be issued by the Transferor to cause the Transferee to 599 issue an INVITE to the Transfer-Target. Note that a successful REFER 600 transaction does not terminate the session between the Transferor 601 and the Transferee. If those parties wish to terminate their 602 session, they must do so with a subsequent BYE request. The media 603 negotiated between the transferee and the transfer target is not 604 affected by the media that had been negotiated between the 605 transferor and the transferee. In particular, the INVITE issued by 606 the Transferee will have the same SDP body it would have if he 607 Transferee had initiated that INVITE on its own. Further, the 608 disposition of the media streams between the Transferor and the 609 Transferee is not altered by the REFER method. Agents may alter a 610 session's media through additional signaling. For example, they may 611 make use of the SIP hold re-INVITE [1] or the conferencing 612 extensions provided by this framework. 614 4.4 Unattended Transfer 616 Unattended Transfer consists of the Transferor providing the 617 Transfer Target's contact to the Transferee. The Transferee attempts 618 to establish a session using that contact and reports the results of 619 that attempt to the Transferor. The signaling relationship between 620 the Transferor and Transferee is not terminated, so the call is 621 recoverable if the Transfer Target cannot be reached. Note that the 622 Transfer Target's contact information has been exposed to the 623 Transferee. The provided contact can be used to make new calls in 624 the future. The diagrams below show indicate the first line of each 625 message. All messages in a particular diagram share the same 626 Call-ID. In these diagrams, media is managed through reINVITE holds, 627 but other mechanisms (mixing multiple media streams at the UA or 628 using the conferencing extensions for example) are valid. 630 4.4.1 Successful Unattended Transfer 632 Transferor Transferee Transfer 633 | | Target 634 | INVITE | | 635 |<-------------------| | 636 | 200 OK | | 637 |------------------->| | 638 | ACK | | 639 |<-------------------| | 640 | INVITE (hold) | | 641 |------------------->| | 642 | 200 OK | | 643 |<-------------------| | 644 | ACK | | 645 |------------------->| | 646 | REFER | | 647 |------------------->| | 648 | 202 Accepted | | 649 |<-------------------| | 650 | | INVITE | 651 | |------------------->| 652 | | 200 OK | 653 | |<-------------------| 654 | | ACK | 655 | |------------------->| 656 | NOTIFY (200 OK) | | 657 |<-------------------| | 658 | 200 OK | | 659 |------------------->| | 660 | BYE | | 661 |------------------->| | 662 | 200 OK | | 663 |<-------------------| | 664 | | BYE | 665 | |<-------------------| 666 | | 200 OK | 667 | |------------------->| 669 4.4.2 Failed Unattended Transfer 671 Transferor Transferee Transfer 672 | | Target 673 | | | 674 | INVITE | | 675 |<-------------------| | 676 | 200 OK | | 677 |------------------->| | 678 | ACK | | 679 |<-------------------| | 680 | INVITE (hold) | | 681 |------------------->| | 682 | 200 OK | | 683 |<-------------------| | 684 | ACK | | 685 |------------------->| | 686 | REFER | | 687 |------------------->| | 688 | 202 Accepted | | 689 |<-------------------| | 690 | | INVITE | 691 | |------------------->| 692 | | 486 Busy Here | 693 | |<-------------------| 694 | | ACK | 695 | |------------------->| 696 | NOTIFY (503 Service Unavailable) | 697 | or NOTIFY (486 Busy Here) | 698 |<-------------------| | 699 | 200 OK | | 700 |------------------->| | 701 | INVITE (unhold) | | 702 |------------------->| | 703 | 200 OK | | 704 |<-------------------| | 705 | ACK | | 706 |------------------->| | 707 | BYE | | 708 |------------------->| | 709 | 200 OK | | 710 |<-------------------| | 712 4.5 Unattended Transfer with Consultation Hold 714 Transfer with Consultation Hold involves a session between the 715 transferor and the transfer target before the transfer actually 716 takes place. This is implemented with SIP Hold and Unattended 717 Transfer as described above. 719 4.5.1 Variation 1 : Exposes transfer target 721 The transferor places the transferee on hold, establishes a call 722 with the transfer target to alert them to the impending transfer, 723 terminates the connection with the transfer target, then proceeds 724 with unattended transfer as above. This variation can be used to 725 provide an experience similar to that expected by current PBX and 726 Centrex users. 728 To (hopefully) improve clarity, non-REFER transactions have been 729 collapsed into one indicator with the arrow showing the direction of 730 the request. 732 Transferor Transferee Transfer 733 | | Target 734 | | | 735 Call-ID:1 | INVITE/200 OK/ACK | | 736 |<-------------------| | 737 Call-ID:1 | INVITE (hold)/200 OK/ACK | 738 |------------------->| | 739 Call-ID:2 | INVITE/200 OK/ACK | | 740 |---------------------------------------->| 741 Call-ID:2 | BYE/200 OK | | 742 |---------------------------------------->| 743 Call-ID:1 | REFER | | 744 |------------------->| | 745 | 202 Accepted | | 746 |<-------------------| | 747 Call-ID:1 | | INVITE/200 OK/ACK | 748 | |------------------->| 749 Call-ID:1 | NOTIFY (200 OK) | | 750 |<-------------------| | 751 | 200 OK | | 752 |------------------->| | 753 Call-ID:1 | BYE/200 OK | | 754 |------------------->| | 755 Call-ID:1 | | BYE/200 OK | 756 | |<-------------------| 758 4.5.2 Variation 2 : Protects transfer target 760 The transferor places the transferee on hold, establishes a call 761 with the transfer target and then reverses their roles, transferring 762 the original transfer target to the original transferee. This has 763 the advantage of hiding information about the original transfer 764 target from the original transferee. On the other hand, the 765 Transferee's experience is different that in current systems. The 766 Transferee is effectively "called back" by the Transfer Target. 768 Transferor Transferee Transfer 769 | | Target 770 | | | 771 Call-ID:1 | INVITE/200 OK/ACK | | 772 |<-------------------| | 773 Call-ID:1 | INVITE (hold)/200 OK/ACK | 774 |------------------->| | 775 Call-ID:2 | INVITE/200 OK/ACK | | 776 |---------------------------------------->| 777 Call-ID:2 | INVITE (hold)/200 OK/ACK | 778 |---------------------------------------->| 779 Call-ID:2 | REFER | | 780 |---------------------------------------->| 781 | 202 Accepted | | 782 |<----------------------------------------| 783 Call-ID:2 | | INVITE/200 OK/ACK | 784 | |<-------------------| 785 Call-ID:2 | NOTIFY (200 OK) | | 786 |<----------------------------------------| 787 | | 200 OK | 788 |---------------------------------------->| 789 Call-ID:1 | BYE/200 OK | | 790 |------------------->| | 791 Call-ID:2 | BYE/200 OK | | 792 |---------------------------------------->| 793 Call-ID:2 | | BYE/200 OK | 794 | |------------------->| 796 4.5.3 Consultation Hold in the presence of forking proxies 798 It is worth noting that the examples given above abstract away any 799 proxies that might be between the three parties. In 4.5.1 for 800 example, the URL used to reach the Transfer Target may go through a 801 forking proxy. There is no guarantee that the Transferee's and 802 Transferor's invitations to the Transfer Target will reach the same 803 endpoint. If the proxy forked in parallel, both invitations could 804 cause multiple endpoints to ring. To increase the probability of the 805 desired behavior of having the referred invite reach and ring only 806 the same endpoint as the consultation invite, the Transferor SHOULD 807 issue the REFER request with the Refer-To: header containing the 808 Contact the Transfer Target provided in its 200 OK to the 809 Transferor's INVITE. If that REFER fails, the Transferor SHOULD 810 issue another REFER with the Refer-To: header containing the URL it 811 used to reach the Transfer Target, augmented with an Accept-Contact 812 header containing the Contact the Transfer Target provided. 814 4.6 Attended Transfer 816 In an attended transfer, the three actors participate in an ad-hoc 817 conference as part of the event. Discussion of the implementation of 818 attended transfer is thus deferred until the conferencing portion of 819 the Call Control framework has been addressed. 821 4.7 Transfer with multiple parties 823 In this example the Originator places call to the Facilitator who 824 reaches the Recipient through the Screener. The Recipient's contact 825 information is exposed to the Facilitator and the Originator. This 826 example is provided for clarification of the semantics of the REFER 827 method only and should not be used as the design of an 828 implementation. 830 Originator Facilitator Screener Recipient 831 Call-ID | | | | 832 1 |INVITE/200 OK/ACK | |"Get Fred for me!" 833 |----------->| | | "Right away!" 834 1 |INVITE (hold)/200 OK/ACK | | 835 |<-----------| | | 836 2 | |INVITE/200 OK/ACK |"I have a call 837 | |----------->| |from Mary for Fred" 838 2 | |INVITE (hold)/200 OK/ACK "Hold please" 839 | |<-----------| | 840 3 | | |INVITE/200 OK/ACK 841 | | |--------->|"You have a call 842 | | | |from Mary" 843 | | | | "Put her through" 844 3 | | |INVITE (hold)/200 OK/ACK 845 | | |--------->| 846 2 | |REFER | | 847 | |<-----------| | 848 | |202 Accepted| | 849 | |----------->| | 850 2 | |INVITE/200 OK/ACK | 851 | |---------------------->|"This is Fred" 852 2 | |NOTIFY (200 OK) | "Please hold for 853 | |----------->| | Mary" 854 | |200 OK | | 855 | |<-----------| | 857 2 | |BYE/200 OK | | 858 | |<-----------| | 859 3 | | |BYE/200 OK| 860 | | |--------->| 861 2 | |INVITE (hold)/200 OK/ACK 862 | |---------------------->| 863 1 |REFER | | | 864 |<-----------| | | 865 |202 Accepted| | | 866 |----------->| | | 867 1 |INVITE/200 OK/ACK | | 868 |----------------------------------->| "Hey Fred" 869 1 |NOTIFY (200 OK) | | "Hello Mary" 870 |----------->| | | 871 |200 OK | | | 872 |<-----------| | | 873 1 |BYE/200 OK | | | 874 |<-----------| | | 875 2 | |BYE/200 OK | | 876 | |---------------------->| 877 1 |BYE/200 OK | | | 878 |<-----------------------------------| "See you later" 880 5. Open Issues 882 5.1 REFER is now dependent on sip-events 884 By introducing NOTIFY, this work is prevented from moving to RFC 885 until the sip-events draft moves to that level (that work is 886 currently an individual submission). What needs to happen to our 887 deliverable schedule to allow for completing the sip-events work? 889 5.2 Registering the events with IANA 891 When we near the end of the process, the refer event will need to be 892 registered with IANA per [3]. 894 6. Acknowledgments 896 This draft is a collaborative product of the SIP working group. The 897 editor thanks the following for their early contributions to this 898 work: Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston, 899 Kevin Summers and Dean Willis. 901 References 903 [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 904 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 906 [2] Campbell, B., "Framework for SIP Call Control Extensions", 907 draft-ietf-sip-cc-framework-00 (work in progress), March 2000. 909 [3] Roach, A., "Event Notification in SIP", 910 draft-roach-sip-subscibe-notify-03 (work in progress), February 911 2001. 913 [4] Schulzrinne, H. and J. Rosenberg, "SIP Call Control Services", 914 draft-ietf-sip-cc-01 (work in progress - expired), June 1999. 916 Author's Address 918 Robert J. Sparks 919 dynamicsoft 920 5100 Tennyson Parkway 921 Suite 1200 922 Plano, TX 75024 924 email: rsparks@dynamicsoft.com 926 Full Copyright Statement 928 Copyright (C) The Internet Society (2001). All Rights Reserved. 930 This document and translations of it may be copied and furnished to 931 others, and derivative works that comment on or otherwise explain it 932 or assist in its implementation may be prepared, copied, published 933 and distributed, in whole or in part, without restriction of any 934 kind, provided that the above copyright notice and this paragraph 935 are included on all such copies and derivative works. However, this 936 document itself may not be modified in any way, such as by removing 937 the copyright notice or references to the Internet Society or other 938 Internet organizations, except as needed for the purpose of 939 developing Internet standards in which case the procedures for 940 copyrights defined in the Internet Standards process must be 941 followed, or as required to translate it into languages other than 942 English. 944 The limited permissions granted above are perpetual and will not be 945 revoked by the Internet Society or its successors or assigns. 947 This document and the information contained herein is provided on an 948 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 949 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 950 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 951 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 952 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 954 Acknowledgement 956 Funding for the RFC editor function is currently provided by the 957 Internet Society.