idnits 2.17.1 draft-ietf-sip-cc-transfer-00.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 135: '...in a SIP session MUST be able to trans...' RFC 2119 keyword, line 138: '...d the Transferee MUST NOT be removed f...' RFC 2119 keyword, line 145: '...ow, this is not the case. A client MAY...' RFC 2119 keyword, line 151: '.... The Transferor MUST know whether or ...' RFC 2119 keyword, line 177: '... A REFER method MUST contain exactly ...' (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 (February 2001) is 8463 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-00.txt 4 July 2000 5 Expires February 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 new Call Control 33 Framework to provide Call Transfer capabilities. 35 1 Overview...........................................................3 36 2 Changes from draft-sparks-sip-cc-transfer-00.......................3 37 3 Actors and Roles...................................................4 38 4 Requirements.......................................................5 39 5 The REFER Method...................................................6 40 5.1 The Refer-To Header............................................6 41 5.2 The Referred-By Header.........................................7 42 5.2.1 A PGP based signature-scheme.................................7 43 5.3 Header Field Support for the REFER Method......................8 44 5.4 Message Body Inclusion.........................................9 45 5.5 Responses to the REFER Method..................................9 46 5.6 Behavior of SIP User Agents...................................10 47 5.7 Behavior of SIP Registrars/Redirect Servers...................10 48 5.8 Behavior of SIP Proxies.......................................10 49 5.9 Security Considerations.......................................11 50 6 Using REFER to achieve Call Transfer..............................11 51 6.1 Unattended Transfer...........................................11 52 6.1.1 Successful Unattended Transfer..............................12 53 6.1.2 Failed Unattended Transfer..................................13 54 6.2 Unattended Transfer with Consultation Hold....................14 55 6.2.1 Variation 1 : Exposes transfer target.......................14 56 6.3 Attended Transfer.............................................15 57 6.4 Transfer with multiple parties................................16 58 7 Author's Addresses................................................17 59 8 Acknowledgments...................................................17 60 9 References........................................................17 61 1 Overview 63 This document defines a SIP [2] extension and details its use to 64 provide Call Transfer capabilities. This is part of a family of Call 65 Control extensions described in the Call Control Framework document 66 [3]. 68 The mechanisms discussed here are most closely related to traditional 69 unattended and consultation hold transfers. Discussion of attended 70 transfer (where all parties are briefly in a conference) is deferred 71 until the conferencing features in this framework are addressed. 73 This work has roots in draft-ietf-sip-cc-01 [4] but some basic 74 semantics are different. In particular, transfers are achieved through 75 a new method that does not terminate the original signaling 76 relationship. By disassociating transfers from the processing of BYE, 77 these changes facilitate recovery of failed transfers and clarify 78 state management in the participating entities. 80 Implementers that started with the sip-cc-01 BYE-ALSO technique for 81 blind-transfer should find it straightforward to migrate to the 82 mechanisms set forth here. 84 2 Changes from draft-sparks-sip-cc-transfer-00 86 . The method was renamed to reflect its function instead of this 87 particular application of its function. TRANSFER and Transfer-To 88 became REFER and Refer-To. REFER was generalized to support URLs 89 beyond those indicating SIP INVITEs. 90 . A Require header is no longer required. Bodies are allowed. 91 . Copying Call-ID from the request was replaced by using a Refer-To: 92 URL containing any headers that should be use. 93 . Added a way for the identity specified in Refer-To: to know it has 94 been referred to. 95 . Added a mechanism to prove the identity of the issuer of the REFER 96 to the identity specified in Refer-To. 97 . The failure response returned to an attempted REFER has been 98 changed from 603 to 503 to facilitate different behavior in the 99 cases of "I won't accept that REFER" and "I tried that REFER and it 100 failed" with Retry-After: support for the later. 102 3 Actors and Roles 104 There are three actors in a given transfer event, each playing one of 105 the following roles: 107 Transferee - the party being transferred to the Transfer 108 Target. 110 Transferor - the party initiating the transfer 112 Transfer Target - the new party being introduced into a call with 113 the Transferee. 115 The following roles are used to describe transfer requirements and 116 scenarios: 118 Originator - wishes to place a call to the Recipient. This actor 119 is the source of the first INVITE in a session, to 120 either a Facilitator or a Screener. 122 Facilitator - receives a call or out-of-band request from the 123 Originator, establishes a call to the Recipient 124 through the Screener, and connects the Originator to 125 the Recipient. 127 Screener - receives a call ultimately intended for the Recipient 128 and transfers the calling party to the Recipient if 129 appropriate. 131 Recipient - the party the Originator is ultimately connected to. 133 4 Requirements 135 1. Any party in a SIP session MUST be able to transfer any other 136 party in that session at any point in that session. 138 2. The Transferor and the Transferee MUST NOT be removed from a 139 session as part of a transfer transaction. 141 At first glance, requirement 2 may seem to indicate 142 that the user experience in a transfer must be 143 significantly different from what a current PBX or 144 Centrex user expects. As the call-flows in this 145 document show, this is not the case. A client MAY 146 preserve the current experience. In fact, without 147 this requirement, some forms of the current 148 experience (ringback on unattended transfer failure 149 for instance) will be lost. 151 3. The Transferor MUST know whether or not the transfer was 152 successful (this is significantly different from the requirements 153 of draft-ietf-sip-cc-01). 155 5 The REFER Method 157 REFER is a SIP method as defined by [2]. The REFER method indicates 158 that the recipient should contact a third party using the contact 159 information provided in the method. A success response indicates that 160 the recipient was able to contact the third party. The REFER method 161 follows the session's current signaling path. In particular, the 162 Request-URI of the REFER method identifies the recipient. 164 Unless stated otherwise, the protocol for emitting and responding to a 165 REFER request are identical to those for a BYE request in [2]. The 166 behavior of SIP entities not implementing the REFER (or any other 167 unknown) method is explicitly defined in [2] and is not discussed 168 further here. 170 5.1 The Refer-To Header 172 Refer-To is a request-header as defined by [2]. It may only appear in 173 a REFER request. It identifies the transfer target. 175 Refer-To = "Refer-To" ":" URL 177 A REFER method MUST contain exactly one Refer-To header. 179 The Refer-To header MAY be encrypted as part of end-end encryption. 181 The Refer-To header has no short form. 183 The Contact header is an important part of the 184 Route/Record-Route mechanism and is not available 185 for this task. 187 5.2 The Referred-By Header 189 Referred-By is a request-header as defined by [2]. It can appear in 190 any request. It conveys the identity of the original REFERrer to the 191 referred-to party, optionally proving the identity and that the 192 REFERrer actually issued this reference. 194 Referred-By = "Referred-By" ":" referrer-url referenced-url 195 [ref-signature] 196 referrer-url = SIP-URL 197 referenced-url = URL 198 ref-signature = signature-scheme #sig-scheme-params 199 signature-scheme = token 200 sig-scheme-parms = token "=" ( token | quoted-string ) 202 The referrer-url contains the SIP URL of the party sending the REFER 203 request. The referenced-url contains a copy of the URL placed in the 204 Refer-To: header. The ref-signature contains a signature over the 205 concatenation of referrer-url and referenced-url. An example 206 signature scheme is given in section 5.2.1. 208 A REFER request MUST contain exactly one Referred-By header. 210 The Referred-By header SHOULD be signed to help detection of REFERs 211 from unauthorized third parties. A signed Referred-By header SHOULD 212 include a Date header in the referrer-url to facilitate detection of 213 replay attacks. 215 A UA MAY reject a request containing an unsigned Referred-By header. A 216 UA SHOULD verify the signature on any Referred-By header it receives. 218 The Referred-By header MAY be encrypted as part of end-end encryption. 220 The Referred-By header has no short form. 222 5.2.1 A PGP based signature-scheme 224 One signature-scheme for Referred-By headers uses PGP as follows: 226 Referred-By = "Referred-By" ":" referrer-url 227 referenced-url "pgp" pgp-sig-scheme-parms 228 pgp-sig-scheme-parms = pgp-version | signed-by | pgp-signature 230 pgp-version, signed-by and pgp-signature are defined in section 15.1.2 231 of RFC2543, with the modification that the signature is computed 232 across the concatenation of the referrer-url and the referenced-url. 234 5.3 Header Field Support for the REFER Method 236 This table adds a column to tables 4 and 5 in [2], describing header 237 presence in a REFER method. See [2] for a key for the symbols used. A 238 row for the Refer-To: and Referred-By request-header should be 239 inferred, each mandatory for REFER. Refer-To is not applicable for all 240 other methods. Referred-By is a general Request header. The enc and e- 241 e columns in [2] apply to the REFER method unmodified. 243 Header Where REFER 244 Accept R - 245 Accept-Encoding R - 246 Accept-Language R o 247 Allow R - 248 Allow 405 m 249 Authorization R o 250 Call-ID gc m 251 Contact R o 252 Contact 1xx - 253 Contact 2-6xx o 254 Content-Encoding e - 255 Content-Length e o <-SHOULD be present and 256 Content-Type e - have a value of zero 257 CSeq gc m 258 Date g o 259 Encryption g o 260 Expires R o 261 From gc m 262 Hide R o 263 Max-Forwards R o 264 Organization g o 265 Priority R - 266 Proxy-Authenticate 407 o 267 Proxy-Authorization R o 268 Proxy-Require R o 269 Require R o 270 Retry-After R - 271 Retry-After 404,480,486 o 272 Retry-After 503 o 273 Retry-After 600,603 o 274 Response-Key R o 275 Record-Route R o 276 Record-Route 2xx o 277 Route R o 278 Server r o 279 Subject R - 280 Timestamp g o 281 To gc(1) m 282 Unsupported 420 o 283 User-Agent g o 284 Via gc(2) m 285 Warning r o 286 WWW-Authenticate 401 o 288 5.4 Message Body Inclusion 290 A REFER method may contain a body which SHOULD be processed according 291 to its Content-Type. 293 5.5 Responses to the REFER Method 295 An agent responding to a REFER Method MUST return a 400 Bad Request if 296 the request contained zero or more than one Refer-To headers. An agent 297 responding to a REFER Method MUST return a 400 Bad Request if the 298 request contained zero or more than one Referred-By headers. An agent 299 (including proxies generating local responses) MAY return a 100 Trying 300 or any appropriate 400-600 class response as prescribed by [2]. If the 301 recipient's agent decides to contact the resource in the Refer-To 302 header, a 200 OK response MUST be returned if it the contact was 303 successful, otherwise a 503 Service Unavailable MUST be returned. The 304 503 response MAY contain a Retry-After: header indicating when the 305 REFER may be attempted again. 307 The original proposal called for a 603 response if 308 the REFER was attempted but failed. This left no way 309 for the referrer to tell whether the recipient tried 310 and failed, or just refused to try. A 603 Decline 311 now means the recipient refuses to try. A 503 can 312 mean either "I tried and failed" or "I'm broken and 313 couldn't try". In either case, if a Retry-After 314 header is present, the request can be attempted 315 again. 317 5.6 Behavior of SIP User Agents 319 A UA receiving a well-formed REFER request SHOULD request approval 320 from the user to proceed (this request could be interactive or through 321 configuration). Upon receiving approval from the user, the UA MUST 322 contact the resource identified by the URL in the Refer-To: header. 323 Note that if the URL is a SIP URL, it could contain header fields such 324 as Call-Id that will be used to form the resulting request. If the URL 325 is a SIP URL, the Referred-By header in the REFER request should be 326 copied into the request sent to the referred-to resource. In 327 accordance with [2], the UA SHOULD issue a provisional response to the 328 REFER method if it cannot issue a final response within 200ms of its 329 receipt. The appropriate response to issue to the REFER on receipt of 330 a final response from the referred-to resource is discussed in 331 "Responses to the REFER Method". 333 A REFER request is meaningful only in the context of an existing 334 session. A UA receiving a REFER request for an unknown call leg MUST 335 return a 481 Call Leg/Transaction Does Not Exist and MUST NOT contact 336 the resource identified by that request's Refer-To header as part of 337 the REFER transaction. 339 5.7 Behavior of SIP Registrars/Redirect Servers 341 Since REFER has meaning only in the context of an existing session, a 342 Registrar or Redirect Server that is not also playing the role of a 343 User Agent (never issues a 200 OK in response to an INVITE) MUST 344 respond to a REFER request with a 481 Call Leg/Transaction Does Not 345 Exist. 347 5.8 Behavior of SIP Proxies 349 SIP Proxies do not require modification to support the REFER method. 350 Specifically, as required by [2], a proxy should process a REFER 351 request the same way it processes an OPTIONS request. 353 5.9 Security Considerations 355 The security requirements of [2] apply to the REFER method. 357 This mechanism relies on providing contact information for the 358 referred-to resource to the party being referred (the transfer-target 359 and transferee in a transfer). Care should be taken to provide a 360 suitably restricted URI if the referred to resource should be 361 protected. 363 Care should be taken when implementing the logic that determines 364 whether or not to accept the REFER request. A UA not capable of 365 accessing non-SIP URLs SHOULD NOT accept REFER requests to them. 366 Unless the UA has good reason (perhaps as part of an as yet undefined 367 application), it SHOULD NOT accept REFERences to SIP URLs for methods 368 other than INVITE. 370 6 Using REFER to achieve Call Transfer 372 A REFER can be issued by the Transferor to cause the Transferee to 373 issue an INVITE to the Transfer-Target. Note that a successful REFER 374 transaction does not terminate the session between the Transferor and 375 the Transferee. If those parties wish to terminate their session, they 376 must do so with a subsequent BYE request. The media negotiated between 377 the transferee and the transfer target is not affected by the media 378 that had been negotiated between the transferor and the transferee. In 379 particular, the INVITE issued by the Transferee will have the same SDP 380 body it would have if he Transferee had initiated that INVITE on its 381 own. Further, the disposition of the media streams between the 382 Transferor and the Transferee is not altered by the REFER method. 383 Agents may alter a session's media through additional signaling. For 384 example, they may make use of the SIP hold re-INVITE [2] or the 385 conferencing extensions provided by this framework. 387 6.1 Unattended Transfer 389 Unattended Transfer consists of the Transferor providing the Transfer 390 Target's contact to the Transferee. The Transferee attempts to 391 establish a session using that contact and reports the results of that 392 attempt to the Transferor. The signaling relationship between the 393 Transferor and Transferee is not terminated, so the call is 394 recoverable if the Transfer Target cannot be reached. Note that the 395 Transfer Target's contact information has been exposed to the 396 Transferee. The provided contact can be used to make new calls in the 397 future. 399 The diagrams below show indicate the first line of each message. All 400 messages in a particular diagram share the same Call-ID. In these 401 diagrams, media is managed through reINVITE holds, but using other 402 mechanisms (mixing multiple media streams at the UA or using the 403 conferencing extensions for example) are valid. 405 6.1.1 Successful Unattended Transfer 407 Transferor Transferee Transfer 408 | | Target 409 | INVITE | | 410 |<-------------------| | 411 | 200 OK | | 412 |------------------->| | 413 | ACK | | 414 |<-------------------| | 415 | INVITE (hold) | | 416 |------------------->| | 417 | 200 OK | | 418 |<-------------------| | 419 | ACK | | 420 |------------------->| | 421 | REFER | | 422 |------------------->| | 423 | 100 Trying | | 424 |<-------------------| | 425 | | INVITE | 426 | |------------------->| 427 | | 200 OK | 428 | |<-------------------| 429 | | ACK | 430 | |------------------->| 431 | 200 OK | | 432 |<-------------------| | 433 | BYE | | 434 |------------------->| | 435 | 200 OK | | 436 |<-------------------| | 437 | | BYE | 438 | |<-------------------| 439 | | 200 OK | 440 | |------------------->| 442 6.1.2 Failed Unattended Transfer 444 Transferor Transferee Transfer 445 | | Target 446 | | | 447 | INVITE | | 448 |<-------------------| | 449 | 200 OK | | 450 |------------------->| | 451 | ACK | | 452 |<-------------------| | 453 | INVITE (hold) | | 454 |------------------->| | 455 | 200 OK | | 456 |<-------------------| | 457 | ACK | | 458 |------------------->| | 459 | REFER | | 460 |------------------->| | 461 | 100 Trying | | 462 |<-------------------| | 463 | | INVITE | 464 | |------------------->| 465 | | 486 Busy Here | 466 | |<-------------------| 467 | | ACK | 468 | |------------------->| 469 | 503 Service Unavailable | 470 |<-------------------| | 471 | INVITE (unhold) | | 472 |------------------->| | 473 | 200 OK | | 474 |<-------------------| | 475 | ACK | | 476 |------------------->| | 477 | BYE | | 478 |------------------->| | 479 | 200 OK | | 480 |<-------------------| | 482 6.2 Unattended Transfer with Consultation Hold 484 Transfer with Consultation Hold involves a session between the 485 transferor and the transfer target before the transfer actually takes 486 place. This is implemented with SIP Hold and Unattended Transfer as 487 described above. 489 6.2.1 Variation 1 : Exposes transfer target 491 The transferor places the transferee on hold, establishes a call with 492 the transfer target to alert them to the impending transfer, 493 terminates the connection with the transfer target, then proceeds with 494 unattended transfer as above. This variation can be used to provide an 495 experience similar to that expected by current PBX and Centrex users. 497 To (hopefully) improve clarity, non-REFER transactions have been 498 collapsed into one indicator with the arrow showing the direction of 499 the request. 501 Transferor Transferee Transfer 502 | | Target 503 | | | 504 Call-ID:1 | INVITE/200 OK/ACK | | 505 |<-------------------| | 506 Call-ID:1 | INVITE (hold)/200 OK/ACK | 507 |------------------->| | 508 Call-ID:2 | INVITE/200 OK/ACK | | 509 |---------------------------------------->| 510 Call-ID:2 | BYE/200 OK | | 511 |---------------------------------------->| 512 Call-ID:1 | REFER | | 513 |------------------->| | 514 | 100 Trying | | 515 |<-------------------| | 516 Call-ID:1 | | INVITE/200 OK/ACK | 517 | |------------------->| 518 | 200 OK | | 519 |<-------------------| | 520 Call-ID:1 | BYE/200 OK | | 521 |------------------->| | 522 Call-ID:1 | | BYE/200 OK | 523 | |<-------------------| 525 5.2.2 Variation 2 : Protects transfer target 527 The transferor places the transferee on hold, establishes a call with 528 the transfer target and then reverses their roles, transferring the 529 original transfer target to the original transferee. This has the 530 advantage of hiding information about the original transfer target 531 from the original transferee. On the other hand, the Transferee's 532 experience is different that in current systems. The Transferee is 533 effectively "called back" by the Transfer Target. 535 Transferor Transferee Transfer 536 | | Target 537 | | | 538 Call-ID:1 | INVITE/200 OK/ACK | | 539 |<-------------------| | 540 Call-ID:1 | INVITE (hold)/200 OK/ACK | 541 |------------------->| | 542 Call-ID:2 | INVITE/200 OK/ACK | | 543 |---------------------------------------->| 544 Call-ID:2 | INVITE (hold)/200 OK/ACK | 545 |---------------------------------------->| 546 Call-ID:2 | REFER | | 547 |---------------------------------------->| 548 | 100 Trying | | 549 |<----------------------------------------| 550 Call-ID:2 | | INVITE/200 OK/ACK | 551 | |<-------------------| 552 | 200 OK | | 553 |<----------------------------------------| 554 Call-ID:1 | BYE/200 OK | | 555 |------------------->| | 556 Call-ID:2 | BYE/200 OK | | 557 |---------------------------------------->| 558 Call-ID:2 | | BYE/200 OK | 559 | |------------------->| 561 6.3 Attended Transfer 563 In an attended transfer, the three actors participate in an ad-hoc 564 conference as part of the event. Discussion of the implementation of 565 attended transfer is thus deferred until the conferencing portion of 566 the Call Control framework has been addressed. 568 6.4 Transfer with multiple parties 570 In this example the Originator places call to the Facilitator who 571 reaches the Recipient through the Screener. The Recipient's contact 572 information is exposed to the Facilitator and the Originator. This 573 example is provided for clarification of the semantics of the REFER 574 method only and should not be used as the design of an 575 implementation. 577 Originator Facilitator Screener Recipient 578 Call-ID | | | | 579 1 |INVITE/200 OK/ACK | |"Get Fred for me!" 580 |----------->| | | "Right away!" 581 1 |INVITE (hold)/200 OK/ACK | | 582 |<-----------| | | 583 2 | |INVITE/200 OK/ACK |"I have a call 584 | |----------->| |from Mary for Fred" 585 2 | |INVITE (hold)/200 OK/ACK "Hold please" 586 | |<-----------| | 587 3 | | |INVITE/200 OK/ACK 588 | | |--------->|"You have a call 589 | | | |from Mary" 590 | | | | "Put her through" 591 3 | | |INVITE (hold)/200 OK/ACK 592 | | |--------->| 593 2 | |REFER | | 594 | |<-----------| | 595 | |100 Trying | | 596 | |----------->| | 597 2 | |INVITE/200 OK/ACK | 598 | |---------------------->|"This is Fred" 599 | |200 OK | | "Please hold for 600 | |----------->| | Mary" 601 2 | |BYE/200 OK | | 602 | |<-----------| | 603 3 | | |BYE/200 OK| 604 | | |--------->| 605 2 | |INVITE (hold)/200 OK/ACK 606 | |---------------------->| 607 1 |REFER | | | 608 |<-----------| | | 609 |100 Trying | | | 610 |----------->| | | 611 1 |INVITE/200 OK/ACK | | 612 |----------------------------------->| "Hey Fred" 613 |200 OK | | | "Hello Mary" 614 |----------->| | | 616 1 |BYE/200 OK | | | 617 |<-----------| | | 618 2 | |BYE/200 OK | | 619 | |---------------------->| 620 1 |BYE/200 OK | | | 621 |<-----------------------------------| "See you later" 623 7 Author's Addresses 625 Robert Sparks 626 dynamicsoft 627 200 Executive Drive 628 Suite 120 629 West Orange, NJ 07052 630 email: rsparks@dynamicsoft.com 632 8 Acknowledgments 634 This draft is a collaborative product of the SIP working group. The 635 author thanks the following for their early contributions to this 636 work: Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston, 637 Kevin Summers and Dean Willis. 639 9 References 641 [1] S. Bradner, "The Internet Standards Process -- Revision 3", 642 BCP9, RFC2026, October 1996. 644 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, 645 "SIP:Session Initiation Protocol", RFC 2543, March 1999. 647 [3] B. Campbell, "Framework for SIP Call Control Extensions", 648 Internet Draft draft-ietf-sip-cc-framework-00, Internet 649 Engineering Task Force, March 2000. Work in Progress. 651 [4] H. Schulzrinne, J. Rosenberg, "SIP Call Control Services", 652 Internet Draft draft-ietf-sip-cc-01, Internet Engineering Task 653 Force, June 17, 1999 Work in Progress (expired).