idnits 2.17.1 draft-ietf-sip-cc-transfer-02.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. ** 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 123: '... A REFER method MUST contain exactly ...' RFC 2119 keyword, line 125: '... Refer-To header MAY be encrypted as p...' RFC 2119 keyword, line 160: '...s of < or > in the referenced-url MUST...' RFC 2119 keyword, line 165: '... A REFER request MUST contain exactly ...' RFC 2119 keyword, line 167: '...ferred-By header SHOULD be signed to h...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 2001) is 8376 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. '2') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- 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: 5 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Robert Sparks 2 Internet Draft dynamicsoft 3 draft-ietf-sip-cc-transfer-02.txt 4 November 2000 5 Expires May 2001 7 SIP Call Control 8 Transfer 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 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 Abstract 32 This document defines a SIP extension within the Call Control 33 Framework to provide Call Transfer capabilities. 35 1 Overview...........................................................3 36 2 Changes from draft-sparks-sip-cc-transfer-01.......................4 37 3 The REFER Method...................................................5 38 3.1 The Refer-To Header............................................5 39 3.1.1 Examples.....................................................5 40 3.1.2 A PGP based signature-scheme.................................6 41 3.1.3 Examples.....................................................7 42 3.2 Header Field Support for the REFER Method......................7 43 3.3 Message Body Inclusion.........................................8 44 3.4 Responses to the REFER Method..................................8 45 3.5 Behavior of SIP User Agents....................................8 46 3.6 Behavior of SIP Registrars/Redirect Servers....................9 47 3.7 Behavior of SIP Proxies........................................9 48 3.8 Security Considerations........................................9 49 4 Call Transfer.....................................................10 50 4.1 Actors and Roles..............................................10 51 4.2 Requirements..................................................11 52 4.3 Using REFER to achieve Call Transfer..........................12 53 4.4 Unattended Transfer...........................................12 54 4.4.1 Successful Unattended Transfer..............................13 55 4.4.2 Failed Unattended Transfer..................................14 56 4.5 Unattended Transfer with Consultation Hold....................14 57 4.5.1 Variation 1 : Exposes transfer target.......................15 58 4.5.2 Variation 2 : Protects transfer target......................15 59 4.5.3 Consultation Hold in the presence of forking proxies........16 60 4.6 Attended Transfer.............................................17 61 4.7 Transfer with multiple parties................................17 62 5 Editor's Address..................................................18 63 6 Acknowledgments...................................................18 64 7 References........................................................18 65 1 Overview 67 This document defines a SIP [2] extension and details its use to 68 provide Call Transfer capabilities. This is part of a family of Call 69 Control extensions described in the Call Control Framework document 70 [3]. 72 The mechanisms discussed here are most closely related to traditional 73 unattended and consultation hold transfers. Discussion of attended 74 transfer (where all parties are briefly in a conference) is deferred 75 until the conferencing features in this framework are addressed. 77 This work has roots in draft-ietf-sip-cc-01 [4] but some basic 78 semantics are different. In particular, transfers are achieved through 79 a new method that does not terminate the original signaling 80 relationship. By disassociating transfers from the processing of BYE, 81 these changes facilitate recovery of failed transfers and clarify 82 state management in the participating entities. 84 Implementers that started with the sip-cc-01 BYE-ALSO technique for 85 blind-transfer should find it straightforward to migrate to the 86 mechanisms set forth here. 88 2 Changes from draft-sparks-sip-cc-transfer-01 90 . Allowed the ref= parameter in the Referred-By header to occur 91 either before or after the optional signature. 92 . Allowed name-addr|addr-spec for the referrer-url in a Referred-By 93 header 94 . Quoted the referenced-url with <> and required escaping <> if 95 they occur within the referenced-url 96 . Captured the results of the list discussion on having the REFERed 97 invite reach a particular endpoint in the presence of forking 98 proxies. 99 . Added example Refer-To: and Referred-By: headers. 101 3 The REFER Method 103 REFER is a SIP method as defined by [2]. The REFER method indicates 104 that the recipient should contact a third party using the contact 105 information provided in the method. A success response indicates that 106 the recipient was able to contact the third party. The REFER method 107 follows the session's current signaling path. In particular, the 108 Request-URI of the REFER method identifies the recipient. 110 Unless stated otherwise, the protocol for emitting and responding to a 111 REFER request are identical to those for a BYE request in [2]. The 112 behavior of SIP entities not implementing the REFER (or any other 113 unknown) method is explicitly defined in [2] and is not discussed 114 further here. 116 3.1 The Refer-To Header 118 Refer-To is a request-header as defined by [2]. It may only appear in 119 a REFER request. 121 Refer-To = ("Refer-To" | "r") ":" URL 123 A REFER method MUST contain exactly one Refer-To header. 125 The Refer-To header MAY be encrypted as part of end-end encryption. 127 The Contact header is an important part of the 128 Route/Record-Route mechanism and is not available 129 for this task. 131 3.1.1 Examples 132 Refer-To: sip:alice@atlanta.com 134 Refer-To: sip:bob@biloxi.com?Accept-Contact=sip:bobsdesk.biloxi.com?Ca 135 ll-ID=55432@alicepc.atlanta.com 137 Refer-To: sip:carol@cleveland.com;method=SUBSCRIBE 139 Refer-To: http://www.ietf.org 140 The Referred-By Header 142 Referred-By is a request-header as defined by [2]. It can appear in 143 any request. It conveys the identity of the original REFERrer to the 144 referred-to party, optionally proving the identity and that the 145 REFERrer actually issued this reference. 147 Referred-By = ("Referred-By" | "b") ":" referrer-url ";" 148 ( referenced-url 149 | ( referenced-url ";" ref-signature ) 150 | ( ref-signature ";" referenced-url ) 151 ) 152 referrer-url = ( name-addr | addr-spec ) 153 referenced-url = "ref" "=" "<" URL ">" 154 ref-signature = signature-scheme *( ";" sig-scheme-params ) 155 signature-scheme = "scheme" "=" token 156 sig-scheme-parms = token "=" ( token | quoted-string ) 158 The referrer-url contains the SIP URL of the party sending the REFER 159 request. The referenced-url contains a copy of the URL placed in the 160 Refer-To: header. Any occurrences of < or > in the referenced-url MUST 161 be escaped. The ref-signature contains a signature over the 162 concatenation of referrer-url and referenced-url. An example 163 signature scheme is given in section 3.1.2. 165 A REFER request MUST contain exactly one Referred-By header. 167 The Referred-By header SHOULD be signed to help detection of REFERs 168 from unauthorized third parties. A signed Referred-By header SHOULD 169 include a Date header in the referrer-url to facilitate detection of 170 replay attacks. 172 A UA MAY reject a request containing an unsigned Referred-By header. A 173 UA SHOULD verify the signature on any Referred-By header it receives. 175 The Referred-By header MAY be encrypted as part of end-end encryption. 177 3.1.2 A PGP based signature-scheme 179 One signature-scheme for Referred-By headers uses PGP as follows: 180 signature-scheme = "scheme" "=" "pgp" 181 sig-scheme-parms = pgp-version | signed-by | pgp-signature 183 pgp-version, signed-by and pgp-signature are defined in section 15.1 184 of RFC2543, with the modification that the signature is computed 185 across the concatenation of the referrer-url and the referenced-url. 187 3.1.3 Examples 189 Referred-By: sip:alice@atlanta.com;ref= 191 Referred-By: "Bob" ;ref=; 192 scheme=pgp;pgp-version="5.0";signature="the signature" 194 (Note that in the last example, the signature would be over the 195 string "sip:bob@biloxi.comsip:alice@atlanta.com") 197 3.2 Header Field Support for the REFER Method 199 This table adds a column to tables 4 and 5 in [2], describing header 200 presence in a REFER method. See [2] for a key for the symbols used. A 201 row for the Refer-To: and Referred-By request-header should be 202 inferred, each mandatory for REFER. Refer-To is not applicable for all 203 other methods. Referred-By is a general Request header. The enc and e- 204 e columns in [2] apply to the REFER method unmodified. 206 Header Where REFER 207 Accept R - 208 Accept-Encoding R - 209 Accept-Language R o 210 Allow R - 211 Allow 405 m 212 Authorization R o 213 Call-ID gc m 214 Contact R o 215 Contact 1xx - 216 Contact 2-6xx o 217 Content-Encoding e - 218 Content-Length e o 219 Content-Type e - 220 CSeq gc m 221 Date g o 222 Encryption g o 223 Expires R o 224 From gc m 225 Hide R o 226 Max-Forwards R o 227 Organization g o 228 Priority R - 229 Proxy-Authenticate 407 o 230 Proxy-Authorization R o 231 Proxy-Require R o 232 Require R o 233 Retry-After R - 234 Retry-After 404,480,486 o 235 Retry-After 503 o 236 Retry-After 600,603 o 237 Response-Key R o 238 Record-Route R o 239 Record-Route 2xx o 240 Route R o 241 Server r o 242 Subject R - 243 Timestamp g o 244 To gc(1) m 245 Unsupported 420 o 246 User-Agent g o 247 Via gc(2) m 248 Warning r o 249 WWW-Authenticate 401 o 251 3.3 Message Body Inclusion 253 A REFER method may contain a body which SHOULD be processed according 254 to its Content-Type. 256 3.4 Responses to the REFER Method 258 An agent responding to a REFER Method MUST return a 400 Bad Request if 259 the request contained zero or more than one Refer-To headers. An agent 260 responding to a REFER Method MUST return a 400 Bad Request if the 261 request contained zero or more than one Referred-By headers. An agent 262 (including proxies generating local responses) MAY return a 100 Trying 263 or any appropriate 400-600 class response as prescribed by [2]. If the 264 recipient's agent decides to contact the resource in the Refer-To 265 header, a 200 OK response MUST be returned if it the contact was 266 successful, otherwise a 503 Service Unavailable MUST be returned. The 267 503 response MAY contain a Retry-After: header indicating when the 268 REFER may be attempted again. 270 3.5 Behavior of SIP User Agents 272 A UA receiving a well-formed REFER request SHOULD request approval 273 from the user to proceed (this request could be interactive or through 274 configuration). Upon receiving approval from the user, the UA MUST 275 contact the resource identified by the URL in the Refer-To: header. 277 Note that if the URL is a SIP URL, it could contain header fields such 278 as Call-Id that will be used to form the resulting request. If the URL 279 is a SIP URL, the Referred-By header in the REFER request should be 280 copied into the request sent to the referred-to resource. In 281 accordance with [2], the UA SHOULD issue a provisional response to the 282 REFER method if it cannot issue a final response within 200ms of its 283 receipt. The appropriate response to issue to the REFER on receipt of 284 a final response from the referred-to resource is discussed in 285 "Responses to the REFER Method". 287 3.6 Behavior of SIP Registrars/Redirect Servers 289 Registrars and Redirect Servers SHOULD return a 603 to a REFER 290 request, unless they are also playing some other SIP role. 292 3.7 Behavior of SIP Proxies 294 SIP Proxies do not require modification to support the REFER method. 295 Specifically, as required by [2], a proxy should process a REFER 296 request the same way it processes an OPTIONS request. 298 3.8 Security Considerations 300 The security requirements of [2] apply to the REFER method. 302 This mechanism relies on providing contact information for the 303 referred-to resource to the party being referred. Care should be taken 304 to provide a suitably restricted URI if the referred to resource 305 should be protected. 307 Care should be taken when implementing the logic that determines 308 whether or not to accept the REFER request. A UA not capable of 309 accessing non-SIP URLs SHOULD NOT accept REFER requests to them. 311 4 Call Transfer 313 4.1 Actors and Roles 315 There are three actors in a given transfer event, each playing one of 316 the following roles: 318 Transferee - the party being transferred to the Transfer 319 Target. 321 Transferor - the party initiating the transfer 323 Transfer Target - the new party being introduced into a call with 324 the Transferee. 326 The following roles are used to describe transfer requirements and 327 scenarios: 329 Originator - wishes to place a call to the Recipient. This actor 330 is the source of the first INVITE in a session, to 331 either a Facilitator or a Screener. 333 Facilitator - receives a call or out-of-band request from the 334 Originator, establishes a call to the Recipient 335 through the Screener, and connects the Originator to 336 the Recipient. 338 Screener - receives a call ultimately intended for the Recipient 339 and transfers the calling party to the Recipient if 340 appropriate. 342 Recipient - the party the Originator is ultimately connected to. 344 4.2 Requirements 346 1. Any party in a SIP session MUST be able to transfer any other 347 party in that session at any point in that session. 349 2. The Transferor and the Transferee MUST NOT be removed from a 350 session as part of a transfer transaction. 352 At first glance, requirement 2 may seem to indicate 353 that the user experience in a transfer must be 354 significantly different from what a current PBX or 355 Centrex user expects. As the call-flows in this 356 document show, this is not the case. A client MAY 357 preserve the current experience. In fact, without 358 this requirement, some forms of the current 359 experience (ringback on unattended transfer failure 360 for instance) will be lost. 362 3. The Transferor MUST know whether or not the transfer was 363 successful (this is significantly different from the requirements 364 of draft-ietf-sip-cc-01). 366 4.3 Using REFER to achieve Call Transfer 368 A REFER can be issued by the Transferor to cause the Transferee to 369 issue an INVITE to the Transfer-Target. Note that a successful REFER 370 transaction does not terminate the session between the Transferor and 371 the Transferee. If those parties wish to terminate their session, they 372 must do so with a subsequent BYE request. The media negotiated between 373 the transferee and the transfer target is not affected by the media 374 that had been negotiated between the transferor and the transferee. In 375 particular, the INVITE issued by the Transferee will have the same SDP 376 body it would have if he Transferee had initiated that INVITE on its 377 own. Further, the disposition of the media streams between the 378 Transferor and the Transferee is not altered by the REFER method. 379 Agents may alter a session's media through additional signaling. For 380 example, they may make use of the SIP hold re-INVITE [2] or the 381 conferencing extensions provided by this framework. 383 4.4 Unattended Transfer 385 Unattended Transfer consists of the Transferor providing the Transfer 386 Target's contact to the Transferee. The Transferee attempts to 387 establish a session using that contact and reports the results of that 388 attempt to the Transferor. The signaling relationship between the 389 Transferor and Transferee is not terminated, so the call is 390 recoverable if the Transfer Target cannot be reached. Note that the 391 Transfer Target's contact information has been exposed to the 392 Transferee. The provided contact can be used to make new calls in the 393 future. 395 The diagrams below show indicate the first line of each message. All 396 messages in a particular diagram share the same Call-ID. In these 397 diagrams, media is managed through reINVITE holds, but other 398 mechanisms (mixing multiple media streams at the UA or using the 399 conferencing extensions for example) are valid. 401 4.4.1 Successful Unattended Transfer 403 Transferor Transferee Transfer 404 | | Target 405 | INVITE | | 406 |<-------------------| | 407 | 200 OK | | 408 |------------------->| | 409 | ACK | | 410 |<-------------------| | 411 | INVITE (hold) | | 412 |------------------->| | 413 | 200 OK | | 414 |<-------------------| | 415 | ACK | | 416 |------------------->| | 417 | REFER | | 418 |------------------->| | 419 | 100 Trying | | 420 |<-------------------| | 421 | | INVITE | 422 | |------------------->| 423 | | 200 OK | 424 | |<-------------------| 425 | | ACK | 426 | |------------------->| 427 | 200 OK | | 428 |<-------------------| | 429 | BYE | | 430 |------------------->| | 431 | 200 OK | | 432 |<-------------------| | 433 | | BYE | 434 | |<-------------------| 435 | | 200 OK | 436 | |------------------->| 438 4.4.2 Failed Unattended Transfer 440 Transferor Transferee Transfer 441 | | Target 442 | | | 443 | INVITE | | 444 |<-------------------| | 445 | 200 OK | | 446 |------------------->| | 447 | ACK | | 448 |<-------------------| | 449 | INVITE (hold) | | 450 |------------------->| | 451 | 200 OK | | 452 |<-------------------| | 453 | ACK | | 454 |------------------->| | 455 | REFER | | 456 |------------------->| | 457 | 100 Trying | | 458 |<-------------------| | 459 | | INVITE | 460 | |------------------->| 461 | | 486 Busy Here | 462 | |<-------------------| 463 | | ACK | 464 | |------------------->| 465 | 503 Service Unavailable | 466 |<-------------------| | 467 | INVITE (unhold) | | 468 |------------------->| | 469 | 200 OK | | 470 |<-------------------| | 471 | ACK | | 472 |------------------->| | 473 | BYE | | 474 |------------------->| | 475 | 200 OK | | 476 |<-------------------| | 478 4.5 Unattended Transfer with Consultation Hold 480 Transfer with Consultation Hold involves a session between the 481 transferor and the transfer target before the transfer actually takes 482 place. This is implemented with SIP Hold and Unattended Transfer as 483 described above. 485 4.5.1 Variation 1 : Exposes transfer target 487 The transferor places the transferee on hold, establishes a call with 488 the transfer target to alert them to the impending transfer, 489 terminates the connection with the transfer target, then proceeds with 490 unattended transfer as above. This variation can be used to provide an 491 experience similar to that expected by current PBX and Centrex users. 493 To (hopefully) improve clarity, non-REFER transactions have been 494 collapsed into one indicator with the arrow showing the direction of 495 the request. 497 Transferor Transferee Transfer 498 | | Target 499 | | | 500 Call-ID:1 | INVITE/200 OK/ACK | | 501 |<-------------------| | 502 Call-ID:1 | INVITE (hold)/200 OK/ACK | 503 |------------------->| | 504 Call-ID:2 | INVITE/200 OK/ACK | | 505 |---------------------------------------->| 506 Call-ID:2 | BYE/200 OK | | 507 |---------------------------------------->| 508 Call-ID:1 | REFER | | 509 |------------------->| | 510 | 100 Trying | | 511 |<-------------------| | 512 Call-ID:1 | | INVITE/200 OK/ACK | 513 | |------------------->| 514 | 200 OK | | 515 |<-------------------| | 516 Call-ID:1 | BYE/200 OK | | 517 |------------------->| | 518 Call-ID:1 | | BYE/200 OK | 519 | |<-------------------| 521 4.5.2 Variation 2 : Protects transfer target 523 The transferor places the transferee on hold, establishes a call with 524 the transfer target and then reverses their roles, transferring the 525 original transfer target to the original transferee. This has the 526 advantage of hiding information about the original transfer target 527 from the original transferee. On the other hand, the Transferee's 528 experience is different that in current systems. The Transferee is 529 effectively "called back" by the Transfer Target. 531 Transferor Transferee Transfer 532 | | Target 533 | | | 534 Call-ID:1 | INVITE/200 OK/ACK | | 535 |<-------------------| | 536 Call-ID:1 | INVITE (hold)/200 OK/ACK | 537 |------------------->| | 538 Call-ID:2 | INVITE/200 OK/ACK | | 539 |---------------------------------------->| 540 Call-ID:2 | INVITE (hold)/200 OK/ACK | 541 |---------------------------------------->| 542 Call-ID:2 | REFER | | 543 |---------------------------------------->| 544 | 100 Trying | | 545 |<----------------------------------------| 546 Call-ID:2 | | INVITE/200 OK/ACK | 547 | |<-------------------| 548 | 200 OK | | 549 |<----------------------------------------| 550 Call-ID:1 | BYE/200 OK | | 551 |------------------->| | 552 Call-ID:2 | BYE/200 OK | | 553 |---------------------------------------->| 554 Call-ID:2 | | BYE/200 OK | 555 | |------------------->| 557 4.5.3 Consultation Hold in the presence of forking proxies 559 It is worth noting that the examples given above abstract away any 560 proxies that might be between the three parties. In 4.5.1 for example, 561 the URL used to reach the Transfer Target may go through a forking 562 proxy. There is no guarantee that the Transferee's and Transferor's 563 invitations to the Transfer Target will reach the same endpoint. If 564 the proxy forked in parallel, both invitations could cause multiple 565 endpoints to ring. To increase the probability of the desired behavior 566 of having the referred invite reach and ring only the same endpoint as 567 the consultation invite, the Transferor SHOULD issue the REFER request 568 with the Refer-To: header containing the Contact the Transfer Target 569 provided in its 200 OK to the Transferor's INVITE. If that REFER 570 fails, the Transferor SHOULD issue another REFER with the Refer-To: 571 header containing the URL it used to reach the Transfer Target, 572 augmented with an Accept-Contact header containing the Contact the 573 Transfer Target provided. 575 4.6 Attended Transfer 577 In an attended transfer, the three actors participate in an ad-hoc 578 conference as part of the event. Discussion of the implementation of 579 attended transfer is thus deferred until the conferencing portion of 580 the Call Control framework has been addressed. 582 4.7 Transfer with multiple parties 584 In this example the Originator places call to the Facilitator who 585 reaches the Recipient through the Screener. The Recipient's contact 586 information is exposed to the Facilitator and the Originator. This 587 example is provided for clarification of the semantics of the REFER 588 method only and should not be used as the design of an 589 implementation. 591 Originator Facilitator Screener Recipient 592 Call-ID | | | | 593 1 |INVITE/200 OK/ACK | |"Get Fred for me!" 594 |----------->| | | "Right away!" 595 1 |INVITE (hold)/200 OK/ACK | | 596 |<-----------| | | 597 2 | |INVITE/200 OK/ACK |"I have a call 598 | |----------->| |from Mary for Fred" 599 2 | |INVITE (hold)/200 OK/ACK "Hold please" 600 | |<-----------| | 601 3 | | |INVITE/200 OK/ACK 602 | | |--------->|"You have a call 603 | | | |from Mary" 604 | | | | "Put her through" 605 3 | | |INVITE (hold)/200 OK/ACK 606 | | |--------->| 607 2 | |REFER | | 608 | |<-----------| | 609 | |100 Trying | | 610 | |----------->| | 611 2 | |INVITE/200 OK/ACK | 612 | |---------------------->|"This is Fred" 613 | |200 OK | | "Please hold for 614 | |----------->| | Mary" 615 2 | |BYE/200 OK | | 616 | |<-----------| | 618 3 | | |BYE/200 OK| 619 | | |--------->| 620 2 | |INVITE (hold)/200 OK/ACK 621 | |---------------------->| 622 1 |REFER | | | 623 |<-----------| | | 624 |100 Trying | | | 625 |----------->| | | 626 1 |INVITE/200 OK/ACK | | 627 |----------------------------------->| "Hey Fred" 628 |200 OK | | | "Hello Mary" 629 |----------->| | | 630 1 |BYE/200 OK | | | 631 |<-----------| | | 632 2 | |BYE/200 OK | | 633 | |---------------------->| 634 1 |BYE/200 OK | | | 635 |<-----------------------------------| "See you later" 637 5 Editor's Address 639 Robert Sparks 640 dynamicsoft 641 200 Executive Drive 642 Suite 120 643 West Orange, NJ 07052 644 email: rsparks@dynamicsoft.com 646 6 Acknowledgments 648 This draft is a collaborative product of the SIP working group. The 649 editor thanks the following for their early contributions to this 650 work: Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston, 651 Kevin Summers and Dean Willis. 653 7 References 655 [1] S. Bradner, "The Internet Standards Process -- Revision 3", 656 BCP9, RFC2026, October 1996. 658 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, 659 "SIP:Session Initiation Protocol", RFC 2543, March 1999. 661 [3] B. Campbell, "Framework for SIP Call Control Extensions", 662 Internet Draft draft-ietf-sip-cc-framework-00, Internet 663 Engineering Task Force, March 2000. Work in Progress. 665 [4] H. Schulzrinne, J. Rosenberg, "SIP Call Control Services", 666 Internet Draft draft-ietf-sip-cc-01, Internet Engineering Task 667 Force, June 17, 1999 Work in Progress (expired).