SIPPING WG R. Sparks Internet-Draft dynamicsoft Expires: April 25, 2003 A. Johnston WorldCom October 25, 2002 Session Initiation Protocol Call Control - Transfer draft-ietf-sipping-cc-transfer-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 25, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). This work is part of the SIP Multiparty Call Control Framework. Sparks & Johnston Expires April 25, 2003 [Page 1] Internet-Draft SIP CC Transfer October 2002 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Changes from draft-sparks-sip-cc-transfer-06 . . . . . . . . 3 3. Actors and Roles . . . . . . . . . . . . . . . . . . . . . . 3 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Using REFER to achieve Call Transfer . . . . . . . . . . . . 5 6. Basic Transfer . . . . . . . . . . . . . . . . . . . . . . . 5 6.1 Successful Transfer . . . . . . . . . . . . . . . . . . . . 6 6.2 Failed Transfer . . . . . . . . . . . . . . . . . . . . . . 7 6.2.1 Target Busy . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2.2 Transfer Target does not answer . . . . . . . . . . . . . . 8 7. Transfer with Consultation Hold . . . . . . . . . . . . . . 9 7.1 Exposing transfer target . . . . . . . . . . . . . . . . . . 9 7.2 Protecting transfer target . . . . . . . . . . . . . . . . . 11 7.3 Attended Transfer . . . . . . . . . . . . . . . . . . . . . 12 7.4 Recovery when one party does not support REFER . . . . . . . 13 7.5 Consultation Hold in the presence of forking proxies . . . . 14 7.6 Aborting a Consultation Hold . . . . . . . . . . . . . . . . 16 8. Transfer with multiple parties . . . . . . . . . . . . . . . 16 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 18 10. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 Full Copyright Statement . . . . . . . . . . . . . . . . . . 20 Sparks & Johnston Expires April 25, 2003 [Page 2] Internet-Draft SIP CC Transfer October 2002 1. Overview This document describes providing Call Transfer capabilities and requirements in SIP [1]. This work is part of the Multiparty Call Control Framework [2]. The mechanisms discussed here are most closely related to traditional basic and consultation hold transfers. This document does not discuss transfer scenarios involving ad-hoc conferences (where all parties involved are briefly in a conference until this transferor drops out). This document details the use of REFER method [3] and Replaces [4] header field to achieve call transfer. 2. Changes from draft-sparks-sip-cc-transfer-06 o Fixed Call-ID errors o Added Replaces requirement o Added Supported, Allow, etc requirement o Removed use of Accept-Contact header o Added language about creation of routable Contact URI o Updated flows for refer-06 behavior o Editorial cleanup 3. Actors and Roles There are three actors in a given transfer event, each playing one of the following roles: Transferee - the party being transferred to the Transfer Target. Transferor - the party initiating the transfer Transfer Target - the new party being introduced into a call with the Transferee. The following roles are used to describe transfer requirements and scenarios: Sparks & Johnston Expires April 25, 2003 [Page 3] Internet-Draft SIP CC Transfer October 2002 Originator - wishes to place a call to the Recipient. This actor is the source of the first INVITE in a session, to either a Facilitator or a Screener. Facilitator - receives a call or out-of-band request from the Originator, establishes a call to the Recipient through the Screener, and connects the Originator to the Recipient. Screener - receives a call ultimately intended for the Recipient and transfers the calling party to the Recipient if appropriate. Recipient - the party the Originator is ultimately connected to. 4. Requirements 1. Any party in a SIP session MUST be able to transfer any other party in that session at any point in that session. 2. The Transferor and the Transferee MUST NOT be removed from a session as part of a transfer transaction. At first glance, requirement 2 may seem to indicate that the user experience in a transfer must be significantly different from what a current PBX or Centrex user expects. As the call-flows in this document show, this is not the case. A client MAY preserve the current experience. In fact, without this requirement, some forms of the current experience (ringback on transfer failure for instance) will be lost. 3. The Transferor MUST know whether or not the transfer was successful (this is significantly different from the requirements of the earlier BYE-Also approach to transfer). 4. The Transferee MUST be able to replace an existing dialog with a new dialog. 5. The Transferor and Transferee SHOULD indicate their support for the primitives required to achieve transfer. Sparks & Johnston Expires April 25, 2003 [Page 4] Internet-Draft SIP CC Transfer October 2002 5. Using REFER to achieve Call Transfer A REFER [3] can be issued by the Transferor to cause the Transferee to issue an INVITE to the Transfer-Target. Note that a successful REFER transaction does not terminate the session between the Transferor and the Transferee. If those parties wish to terminate their session, they must do so with a subsequent BYE request. The media negotiated between the transferee and the transfer target is not affected by the media that had been negotiated between the transferor and the transferee. In particular, the INVITE issued by the Transferee will have the same SDP body it would have if he Transferee had initiated that INVITE on its own. Further, the disposition of the media streams between the Transferor and the Transferee is not altered by the REFER method. Agents may alter a session's media through additional signaling. For example, they may make use of the SIP hold re-INVITE [1] or the conferencing extensions provided by this framework. 6. Basic Transfer Basic Transfer consists of the Transferor providing the Transfer Target's contact to the Transferee. The Transferee attempts to establish a session using that contact and reports the results of that attempt to the Transferor. The signaling relationship between the Transferor and Transferee is not terminated, so the call is recoverable if the Transfer Target cannot be reached. Note that the Transfer Target's contact information has been exposed to the Transferee. The provided contact can be used to make new calls in the future. The participants in a basic transfer should indicate support for the REFER and NOTIFY methods in Allow header fields in INVITE, 200 OK to INVITE, and OPTIONS. The diagrams below show indicate the first line of each message. The first column of the figure shows the Call-ID used in that particular message. In these diagrams, media is managed through re-INVITE holds, but other mechanisms (mixing multiple media streams at the UA or using the conferencing extensions for example) are valid. Each of the flows below shows the dialog between the Transferor and the Transferee remaining connected (on hold) during the REFER process. While this provides the greatest flexibility for recovery from failure, it is not necessary. If the Transferor's agent does not wish to participate in the remainder of the REFER process and has no intention of assisting with recovery from transfer failure, it could emit a BYE to the Transferee as soon as the REFER transaction completes. This flow is sometimes known as "unattended transfer". Sparks & Johnston Expires April 25, 2003 [Page 5] Internet-Draft SIP CC Transfer October 2002 6.1 Successful Transfer Transferor Transferee Transfer | | Target | INVITE | | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | ACK | | Call-ID:1 |<-------------------| | | INVITE (hold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Call-ID:1 |------------------->| | | REFER | | Call-ID:1 |------------------->| | | 202 Accepted | | Call-ID:1 |<-------------------| | | NOTIFY (100 Trying)| | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | | INVITE | Call-ID:2 | |------------------->| | | 200 OK | Call-ID:2 | |<-------------------| | | ACK | Call-ID:2 | |------------------->| | NOTIFY (200 OK) | | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | BYE | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | | BYE | Call-ID:2 | |<-------------------| | | 200 OK | Call-ID:2 | |------------------->| Figure 1. Basic Transfer Call Flow. Sparks & Johnston Expires April 25, 2003 [Page 6] Internet-Draft SIP CC Transfer October 2002 6.2 Failed Transfer This section shows examples of failed transfer attempts. After the transfer failure occurs, the Transferor takes the Transferee off hold and resumes the session. 6.2.1 Target Busy Transferor Transferee Transfer | | Target | | | | INVITE | | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | ACK | | Call-ID:1 |<-------------------| | | INVITE (hold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Call-ID:1 |------------------->| | | REFER | | Call-ID:1 |------------------->| | | 202 Accepted | | Call-ID:1 |<-------------------| | | NOTIFY (100 Trying)| | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | | INVITE | Call-ID:2 | |------------------->| | | 486 Busy Here | Call-ID:2 | |<-------------------| | | ACK | Call-ID:2 | |------------------->| | NOTIFY (503 Service Unavailable) | | or NOTIFY (486 Busy Here) | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | INVITE (unhold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Sparks & Johnston Expires April 25, 2003 [Page 7] Internet-Draft SIP CC Transfer October 2002 Call-ID:1 |------------------->| | | BYE | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | Figure 2. Failed Transfer - Target Busy 6.2.2 Transfer Target does not answer Transferor Transferee Transfer | | Target | INVITE | | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | ACK | | Call-ID:1 |<-------------------| | | INVITE (hold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Call-ID:1 |------------------->| | | REFER | | Call-ID:1 |------------------->| | | 202 Accepted | | Call-ID:1 |<-------------------| | | NOTIFY (100 Trying)| | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | | INVITE | Call-ID:2 | |------------------->| | | 180 Ringing | Call-ID:2 | |<-------------------| | | (Transferee gets tired of waiting) | | CANCEL | Call-ID:2 | |------------------->| | | 200 OK (CANCEL) | Call-ID:2 | |<-------------------| | | 487 Request Cancelled (INVITE) Call-ID:2 | |<-------------------| | | ACK | Call-ID:2 | |------------------->| | NOTIFY (487 Request Cancelled) | Sparks & Johnston Expires April 25, 2003 [Page 8] Internet-Draft SIP CC Transfer October 2002 Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | INVITE (unhold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Call-ID:1 |------------------->| | | BYE | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | Figure 3. Failed Transfer - Target Does Not Answer. 7. Transfer with Consultation Hold Transfer with Consultation Hold involves a session between the transferor and the transfer target before the transfer actually takes place. This is implemented with SIP Hold and Transfer as described above. 7.1 Exposing transfer target The transferor places the transferee on hold, establishes a call with the transfer target to alert them to the impending transfer, terminates the connection with the transfer target, then proceeds with transfer as above. This variation can be used to provide an experience similar to that expected by current PBX and Centrex users. To (hopefully) improve clarity, non-REFER transactions have been collapsed into one indicator with the arrow showing the direction of the request. Sparks & Johnston Expires April 25, 2003 [Page 9] Internet-Draft SIP CC Transfer October 2002 Transferor Transferee Transfer | | Target | | | Call-ID:1 | INVITE/200 OK/ACK | | |<-------------------| | Call-ID:1 | INVITE (hold)/200 OK/ACK | |------------------->| | Call-ID:2 | INVITE/200 OK/ACK | | |---------------------------------------->| Call-ID:2 | BYE/200 OK | | |---------------------------------------->| Call-ID:1 | REFER | | |------------------->| | Call-ID:1 | 202 Accepted | | |<-------------------| | Call-ID:1 | NOTIFY (100 Trying)| | |<-------------------| | Call-ID:1 | 200 OK | | |------------------->| | Call-ID:3 | | INVITE/200 OK/ACK | | |------------------->| Call-ID:1 | NOTIFY (200 OK) | | |<-------------------| | Call-ID:1 | 200 OK | | |------------------->| | Call-ID:1 | BYE/200 OK | | |------------------->| | Call-ID:3 | | BYE/200 OK | | |<-------------------| Figure 4. Transfer with Consultation Hold - Exposing Transfer Target. Sparks & Johnston Expires April 25, 2003 [Page 10] Internet-Draft SIP CC Transfer October 2002 7.2 Protecting transfer target The transferor places the transferee on hold, establishes a call with the transfer target and then reverses their roles, transferring the original transfer target to the original transferee. This has the advantage of hiding information about the original transfer target from the original transferee. On the other hand, the Transferee's experience is different that in current systems. The Transferee is effectively "called back" by the Transfer Target. One of the problems with this simplest implementation of a target protecting transfer is that the transferee is receiving a new call from the transfer-target. Unless the transferee's agent has a reliable way to associate this new call with the call it already has with the transferor, it will have to alert the new call on another appearance. If this, or some other call-waiting-like UI were not available, the transferee might be stuck returning a Busy-Here to the transfer target, effectively preventing the transfer. There are many ways that that correlation could be provided. The dialog parameters could be provided directly as header parameters in the Refer-To: URI for example. The Replaces mechanism [4] uses this approach and solves this problem nicely. For the flow below, dialog1 means dialog identifier 1, and consists of the parameters of the Replaces header for dialog 1. In [4] this is the Call-ID, To-tag and From-tag. Note that the transferee's agent emits a BYE to the transferor's agent as an immediate consequence of processing the Replaces header. The Transferor knows that both the Transferee and the Transfer Target support the Replaces header from the Supported: replaces header contained in the 200 OK responses from both. Sparks & Johnston Expires April 25, 2003 [Page 11] Internet-Draft SIP CC Transfer October 2002 Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK | | |<-------------------| | dialog1 | INVITE (hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE/200 OK/ACK | | |---------------------------------------->| dialog2 | INVITE (hold)/200 OK/ACK | |---------------------------------------->| dialog2 | REFER (Refer-To:sip:Transferee?Replaces=dialog1) |---------------------------------------->| dialog2 | 202 Accepted | | |<----------------------------------------| dialog2 | NOTIFY (100 Trying)| | |<----------------------------------------| dialog2 | | 200 OK | |---------------------------------------->| dialog3 | | INVITE (Replaces:dialog1)/200 OK/ACK | |<-------------------| dialog1 | BYE/200 OK | | |<-------------------| | dialog2 | NOTIFY (200 OK) | | |<----------------------------------------| dialog2 | | 200 OK | |---------------------------------------->| dialog2 | BYE/200 OK | | |---------------------------------------->| | | (transferee and target converse) dialog3 | | BYE/200 OK | | |------------------->| Figure 5. Transfer Protecting Transfer Target. 7.3 Attended Transfer The transferor places the transferee on hold, establishes a call with the transfer target to alert them to the impending transfer, places the target on hold, then proceeds with transfer using an escaped Replaces header field in the Refer-To header. This is another common service expected by current PBX and Centrex users. Sparks & Johnston Expires April 25, 2003 [Page 12] Internet-Draft SIP CC Transfer October 2002 Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK | | |<-------------------| | dialog1 | INVITE (hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE/200 OK/ACK | | |---------------------------------------->| dialog2 | INVITE (hold)/200 OK/ACK | |---------------------------------------->| dialog1 | REFER (Refer-To:sip:TransferTarget?Replaces=dialog2) |------------------->| | dialog1 | 202 Accepted | | |<-------------------| | dialog1 | NOTIFY (100 Trying)| | |<-------------------| | dialog1 | 200 OK | | |------------------->| | dialog3 | | INVITE (Replaces:dialog2)/200 OK/ACK | |------------------->| dialog2 | BYE/200 OK | | |<----------------------------------------| dialog1 | NOTIFY (200 OK) | | |<-------------------| | dialog1 | 200 OK | | |------------------->| | dialog1 | BYE/200 OK | | |------------------->| | dialog3 | | BYE/200 OK | | |<-------------------| Figure 6. Attended Transfer Call Flow. 7.4 Recovery when one party does not support REFER If protecting or exposing the transfer target is not a concern, it is possible to complete a transfer with consultation hold when only the transferor and one other party support REFER. Note that a 405 Method Not Allowed might be returned instead of the 501 Not Implemented response. Sparks & Johnston Expires April 25, 2003 [Page 13] Internet-Draft SIP CC Transfer October 2002 Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK | | |<-------------------| | dialog1 | INVITE (hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE/200 OK/ACK | | |---------------------------------------->| dialog2 | INVITE (hold)/200 OK/ACK | |---------------------------------------->| dialog1 | REFER (Refer-To:sip:TransferTarget?Replaces=dialog2) |------------------->| | dialog1 | 501 Not Implemented | |<-------------------| | dialog2 | REFER (Refer-To:sip:Transferee?Replaces=dialog1) |---------------------------------------->| dialog2 | 202 Accepted | | |<----------------------------------------| dialog2 | NOTIFY (100 Trying)| | |<----------------------------------------| dialog2 | | 200 OK | |---------------------------------------->| dialog3 | | INVITE (Replaces:dialog1)/200 OK/ACK | |<-------------------| dialog2 | NOTIFY (200 OK) | | |<----------------------------------------| | | 200 OK | |---------------------------------------->| dialog1 | BYE/200 OK | | |<-------------------| | dialog2 | BYE/200 OK | | |---------------------------------------->| dialog3 | | BYE/200 OK | | |------------------->| Figure 7. Recovery when one party does not support REFER. 7.5 Consultation Hold in the presence of forking proxies It is worth noting that the examples given above abstract away any proxies that might be between the three parties. In the examples of Figures 4, 5, and 6, the URI used to reach the Transfer Target may go through a forking proxy. There is no guarantee that the Transferee's and Transferor's invitations to the Transfer Target will reach the same endpoint. If the proxy forked in parallel, both invitations could cause multiple endpoints to ring. Sparks & Johnston Expires April 25, 2003 [Page 14] Internet-Draft SIP CC Transfer October 2002 To increase the probability of the desired behavior of having the referred invite reach and ring only the same endpoint as the consultation invite, the Transferor SHOULD issue the REFER request with the Refer-To: header containing the Contact URI the Transfer Target provided in its 200 OK to the Transferor's INVITE. If that REFER fails, the Transferor SHOULD issue another REFER with the Refer-To: header containing the URI it used to reach the Transfer Target, augmented with a Require: replaces header field. This ensures that only the endpoint which has the active dialog will accept the INVITE request. Note that the Require:replaces header is necessary so that a if the request is forked to a different endpoint which does not support Replaces, the endpoint will respond with a 420 Bad Extension instead of accepting the INVITE. Note that any RFC 3261 compliant will generate a Contact URI which is routable outside a dialog as per Section 8.1.1.8 of RFC 3261. For a UA which requires all request to be routed through a proxy (such as for NAT/firewall traversal or screening/feature reasons), special care must be taken in constructing the Contact URI. One approach is to construct a URI which is unique for the device which resolves to the proxy. A registration would then be required to bind this URI to a URI which resolves directly to the device. For example, consider a UA with a username carol and a hostname server51.chicago.com. A normal Contact would be automatically generated in the form: Contact: sip:carol@serv51.chicago.com However, if this UA requires that all requests come through a proxy server at p1.chicago.com then this Contact will not work as the proxy will be bypassed. Another approach would involve a Contact of the form: Contact: sip:serv51@chicago.com in which this sip:serv51@chicago.com URI would be registered by the UA against a Contact: Contact: sip:carol@serv51.chicago.com which resolves directly to the UA. This means that a UA would first register a URI that corresponds to Sparks & Johnston Expires April 25, 2003 [Page 15] Internet-Draft SIP CC Transfer October 2002 the device. Then, it would register a users URI (AOR) and use the device URI that it registered as the Contact URI. An alternative approach (which is not compatible with unextended RFC 2543 or 3261) would be to include an escaped loose Route header field in the Contact URI: Contact: sip:carol@serv51.chicago.com?Route=sip:p1.chicago.com;lr This would result in a request being sent to sip:carol@serv51.chicago.com with a loose Route header forcing routing to sip:p1.chicago.com first. Open Issue: This syntax, while allowed in a redirection, is not permitted in an INVITE or 200 OK response per Table 1 in RFC 3261. Other approaches may also be used to generate this globally routable Contact URI. 7.6 Aborting a Consultation Hold In any of the consultation hold flows above, the Transferor may decide to terminate its attempt to contact the Transfer target before that session is established. Most frequently, that will be the end of the scenario, but in some circumstances, the transferor may wish to proceed with the transfer action. For example, he may wish to complete the transfer knowing that the transferee will end up eventually talking to the transfer-target's voice-mail service. Some PBX systems support this feature, sometimes called "semi-attended transfer", that is effectively a hybrid between a fully attended transfer and an unattended transfer. A true implementation of this feature requires a short ad-hoc conference between all parties, which ensures that no media clipping occurs. This flow is outside the scope of this document. For flows that expose the transfer target, this simply becomes a basic transfer. This scenario is far more complicated for flows that protect the transfer target. Since no session is established between the transferor and the transfer target, the transfer target's agent would have to honor out-of-session REFERs, and somehow indicate what's happening via its user interface (this scenario is most likely to occur when the transfer-target is away from his agent). 8. Transfer with multiple parties In this example the Originator places call to the Facilitator who Sparks & Johnston Expires April 25, 2003 [Page 16] Internet-Draft SIP CC Transfer October 2002 reaches the Recipient through the Screener. The Recipient's contact information is exposed to the Facilitator and the Originator. This example is provided for clarification of the semantics of the REFER method only and should not be used as the design of an implementation. Originator Facilitator Screener Recipient Call-ID | | | | 1 |INVITE/200 OK/ACK | |"Get Fred for me!" |----------->| | | "Right away!" 1 |INVITE (hold)/200 OK/ACK | | |<-----------| | | 2 | |INVITE/200 OK/ACK |"I have a call | |----------->| |from Mary for Fred" 2 | |INVITE (hold)/200 OK/ACK "Hold please" | |<-----------| | 3 | | |INVITE/200 OK/ACK | | |--------->|"You have a call | | | |from Mary" | | | | "Put her through" 3 | | |INVITE (hold)/200 OK/ACK | | |--------->| 2 | |REFER | | | |<-----------| | 2 | |202 Accepted| | | |----------->| | 2 | |NOTIFY (100 Trying) | | |----------->| | 2 | |200 OK | | | |<-----------| | 2 | |INVITE/200 OK/ACK | | |---------------------->|"This is Fred" 2 | |NOTIFY (200 OK) | "Please hold for | |----------->| | Mary" 2 | |200 OK | | | |<-----------| | 2 | |BYE/200 OK | | | |<-----------| | 3 | | |BYE/200 OK| | | |--------->| 2 | |INVITE (hold)/200 OK/ACK | |---------------------->| 1 |REFER | | | |<-----------| | | 1 |202 Accepted| | | |----------->| | | 1 |NOTIFY (100 Trying) | | |----------->| | | Sparks & Johnston Expires April 25, 2003 [Page 17] Internet-Draft SIP CC Transfer October 2002 1 |200 OK | | | |<-----------| | | 1 |INVITE/200 OK/ACK | | |----------------------------------->| "Hey Fred" 1 |NOTIFY (200 OK) | | "Hello Mary" |----------->| | | 1 |200 OK | | | |<-----------| | | 1 |BYE/200 OK | | | |<-----------| | | 2 | |BYE/200 OK | | | |---------------------->| 1 |BYE/200 OK | | | |<-----------------------------------| "See you later" Figure 8. Transfer with Multiple Parties Example. 9. Open Issues The creation of globally routable Contact URIs and the use of escaped Route headers in Contact header fields in INVITE and 200 OK responses. 10. To Do Add message details to all the call flows. 11. Acknowledgments This draft is a collaborative product of the SIP working group. Thanks to Rohan Mahy for his input on the use of Replaces in transfer. References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Mahy, R., Campbell, B., Johnston, A., Petrie, D., Rosenberg, J. and R. Sparks, "A Multi-party Application Framework for SIP", draft-ietf-sipping-cc-framework-01 (work in progress), June 2002. [3] Sparks, R., "The REFER Method", draft-ietf-sip-refer-06 (work in progress), July 2002. [4] Mahy, R., Biggs, B. and R. Dean, "The SIP Replaces Header", Sparks & Johnston Expires April 25, 2003 [Page 18] Internet-Draft SIP CC Transfer October 2002 draft-ietf-sipping-replaces-02 (work in progress), April 2002. Authors' Addresses Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: rsparks@dynamicsoft.com Alan Johnston WorldCom 100 South 4th Street St. Louis, MO 63104 EMail: alan.johnston@wcom.com Sparks & Johnston Expires April 25, 2003 [Page 19] Internet-Draft SIP CC Transfer October 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Sparks & Johnston Expires April 25, 2003 [Page 20]