SIPPING D. Petrie Internet-Draft Pingtel Corp. Expires: April 17, 2004 October 18, 2003 SIP Transfer Issues draft-petrie-sipping-xfer-issues-00.txt 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 17, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Transfer features in SIP have been enabled via the REFER method and Replaces header. These constructs have been around for a while now with stable definitions for how they work. However, there appear to be a small set of edge cases and requirements that are not yet satisfied. This draft attempts to define some of those cases and requirements. This is intended to spark discussion to whether these are legitimate requirements on which further standards work is appropriate. Petrie Expires April 17, 2004 [Page 1] Internet-Draft SIP Transfer Issues October 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Definitions of Transfer Terminology . . . . . . . . . . . . 3 1.2 Requirements Terminology . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Consultative Transfer to Lost Target . . . . . . . . . . . . 4 2.2 Consultative Transfer User Experience . . . . . . . . . . . 5 2.2.1 Consultative Call Prompting . . . . . . . . . . . . . . . . 5 2.2.2 Consultative Turned Blind Double Ring . . . . . . . . . . . 6 2.3 Gateway Issues . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1 Coerce Gateway Hairpins to the Same Gateway . . . . . . . . 6 2.3.2 Consultative Turned Blind Gateway Glare . . . . . . . . . . 7 2.4 Common Implementation Issues . . . . . . . . . . . . . . . . 8 2.4.1 Consultative with Single Line UA . . . . . . . . . . . . . . 8 2.4.2 Consultative Turned Blind Cancel Issues . . . . . . . . . . 8 3. Solutions and Directions to Consider . . . . . . . . . . . . 9 3.1 Use of Option Tokens . . . . . . . . . . . . . . . . . . . . 9 3.2 New Header for Related Dialog . . . . . . . . . . . . . . . 9 3.3 Transfer on the TDM Side of Gateways . . . . . . . . . . . . 10 3.4 Transfer on the TDM Side of Gateways . . . . . . . . . . . . 10 3.5 New Header for Actors . . . . . . . . . . . . . . . . . . . 11 3.6 Use a Target URI . . . . . . . . . . . . . . . . . . . . . . 11 3.7 Disallow Transition from Consultative to Blind Transfer . . 11 3.8 Continue Ringing after CANCEL of Consult . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . 12 References . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 14 Petrie Expires April 17, 2004 [Page 2] Internet-Draft SIP Transfer Issues October 2003 1. Introduction Transfer features in SIP [RFC3261] can be accomplished using the primitives based upon the REFER method [RFC3515] and the Replaces header [I-D.ietf-sip-replaces] as described in [I-D.ietf-sipping-cc-transfer]. Further examples of the signaling involved in transfer are demonstrated in [I-D.ietf-sipping-service-examples]. There are a few problems which come up in the field that are not obviously solvable by these constructs. In this draft some of the requirements and problems are described so that they can be categorized as: solved by existing protocol, implementation issues, desirable to solve with new protocol, or not a requirement desirable to solve. Also an attempt was made to propose some directions that can be pursued in fulfilling these requirements. 1.1 Definitions of Transfer Terminology transferor - the user agent initiating the transfer. transferee - the user agent to be transferred to the third party. transfer target - the third party to which the transferee is to be connected. original call - the dialog between the transferor and the transferee which is setup before initiating the transfer. consultative call - the dialog between the transferor and the transfer target which is setup before completing the transfer. target call - the dialog between the transferee and the transfer target which is the final outcome of the transfer. 1.2 Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in RFC 2119[RFC2119]. 2. Requirements The following define requirements, problems and issues seen in current transfer implementations. Some of these simply reflect the need for a better understanding of how transfer [I-D.ietf-sipping-cc-transfer], REFER [RFC3515] and replaces [I-D.ietf-sip-replaces] should be used. Others may require new application of existing protocol constructs. Some may require new Petrie Expires April 17, 2004 [Page 3] Internet-Draft SIP Transfer Issues October 2003 protocol constructs. 2.1 Consultative Transfer to Lost Target In many cases of general call setup, the routing functions that determine how to route a SIP request to a target user agent are not static. The routing may be influenced by the time of day, dialog state on the target, availability of the call agent, etc. For this reason, SIP requests sent to the same address of record will not necessarily be routed to the same target user agent. This causes a problem for consultative transfer. The consultative INVITE is sent and the dialog is setup with the transfer target prime (TT'). When the consultation is complete the transferor (TC) sends a REFER to the transferee (TE). The transferee in turn sends an INVITE with Replaces to the transfer target (TT). The INVITE with Replaces does not land on the correct transfer target prime (TT') where the dialog in the Replaces header matches. The transfer target (TT) then according to [I-D.ietf-sip-replaces] sends a 481 and thus the transfer fails. What is really needed is a globally routable means for the transferor to address the correct target TT' in the Refer-To header of the REFER (which is used as the URI for the INVITE with Replaces). For a more concrete example (See Figure 1) assume that the transfer target (TT) is forwarding calls when busy to TT'. When the consultative INVITE gets to the transfer target it is redirected via a 302 to TT'. Note that a proxy (P) is inserted below to illustrate that the transferor (TC) may have no way of knowing that the consultative call was forwarded from TT to TT'. Petrie Expires April 17, 2004 [Page 4] Internet-Draft SIP Transfer Issues October 2003 TC TE P TT TT' <=talking=> ---I(hold)---> <---100,200--- -----ACK-----> (busy) --------I(consult)-------> -I(consult)-> <----302----- -----ACK----> -------I(consult)---------> <-------100,180,200-------- <-------100,180,200------- -----------------------ACK-------------------------> <================(consultation)====================> (not busy) ----REFER---> <----202----- -I(replaces)-> -I(replaces)-> <-----481----- <----481----- -----ACK----> <---N(503)--- -----200----> Consultative Transfer to the Wrong Target Figure 1 2.2 Consultative Transfer User Experience The following set of issues and requirements relate to undesirable user experiences in consultative transfer scenarios. 2.2.1 Consultative Call Prompting Currently when a transfer target receives a consultative call it looks like any other independent INVITE. The user agent cannot give the user any sort of hint that this is related to a transfer or that it is a consultation. At best a user answering the consultative call is presented with the caller ID of the transferor. It would be desirable to improve this user experience. For example it might be better to be able to provide the user on the transfer target with Petrie Expires April 17, 2004 [Page 5] Internet-Draft SIP Transfer Issues October 2003 information of the form: "Incoming consultation from: with intent to transfer: ". The transferee Id is not present in the consultative INVITE. 2.2.2 Consultative Turned Blind Double Ring In the consultative turned blind case the transfer controller initiates a consultative INVITE to the transfer target, sends a CANCEL and then a REFER (to the transferee) to perform the blind transfer. This sometimes creates an awkward experience on the transfer target. The consultative INVITE comes in and rings for a short period of time. Then that call is CANCELed. Afterwards the transferee receives the REFERred INVITE and starts ringing again. The transfer target hears the phone ring twice and may see two different caller Ids. It is probably not desirable to change the signaling approach (i.e. INVITE, CANCEL, REFER) at this point. However if the transfer target user agent were given more hints as to what was going on, it could potentially hide the double ring and changing caller Ids. 2.3 Gateway Issues The following set of requirements relate to SIP signaling gateways (PSTN and others). 2.3.1 Coerce Gateway Hairpins to the Same Gateway To illustrate how a hairpin situation can occur in transfer, consider this example. The original call dialog is setup with the transferee residing on the TDM side of a SIP gateway. The transferor is a SIP phone purely in the IP space. The transfer target is on the TDM side of a SIP gateway as well. After completing the transfer, (regardless of consultative or blind) the transferee is in a call with the transfer target (both on the TDM side of a gateway). It is often desirable to remove the gateway(s) out of the loop. This is likely to only be possible if both legs of the target call are on the same gateway. With both legs on the same gateway, it may be able to invoke the analogous transfer on the TDM side. Then the target call would not involve the gateway. Gateway ports can be expensive or limited resources. It is therefore desirable to keep their utilization to a minimum. For example, in a hybrid situation a SIP to PSTN gateway may be used to extend the life of a TDM switch that is at its maximum for line and trunk cards. The last few valuable trunk cards are used to glue in the gateway with the desire of using SIP (proxy, etc.) to get a higher density of utilization from the trunk lines. A hairpin through the gateway consumes two ports that could be switched in the TDM switch, freeing Petrie Expires April 17, 2004 [Page 6] Internet-Draft SIP Transfer Issues October 2003 both gateway ports. This is easier to accomplish if the hairpin is on the same T1. It is certainly very difficult to accomplish if the hairpin is across two different gateways. Even if the hairpin cannot be eliminated by being pushed to the other side of the gateway, there are other scenarios where coercing the two legs of a hairpin onto the same gateway is very desirable for network traffic optimization (e.g. avoiding the traffic in and out over two limited WAN connections if the gateways are at different sites.). So the problem is how to give the proxy enough information so that it knows to route the call to the same gateway. With a simple single call that hairpins, the incoming and outgoing leg have the same dialog. The proxy should have enough information to optimize the routing. In the consultative transfer scenario, it is desirable to coerce the consultative INVITE out the same gateway as the original call to be transferred. However there is no way to relate the consultation with the original call. In the consultative case the target call INVITE includes the Replaces header which contains dialog information that can be used to relate it to the consultation. However there is no information that relates the target call to the original. In the blind transfer scenario, it is desirable to coerce the target call onto the same gateway as the original call. However the same problem exists in that the target dialog cannot be related to the original dialog. In either transfer scenario, it may be desirable to push the transfer operation onto the non-SIP side of the gateway. Presumably this is not possible unless all of the legs go out the same gateway. If the gateway supports more than one truck group, it might also be necessary to get all of the legs on the same trunk group in order to perform the transfer on the non-SIP side of the gateway. 2.3.2 Consultative Turned Blind Gateway Glare In the consultative transfer case turned blind, there is a glare-like problem. The transferor initiates the consultation INVITE, the user gets impatient and hangs up, transitioning this to a blind transfer. The transfer target on the gateway (connected through a TDM switch to a single line or dumb analog phone) rings. The user answers the phone just after the CANCEL is received by the transfer target. The REFER and INVITE for the target call are sent. The transferee attempts to setup the call on the TDM side, but gets either a busy or lands in the users voicemail as the user has the handset in hand and off hook. Petrie Expires April 17, 2004 [Page 7] Internet-Draft SIP Transfer Issues October 2003 In this scenario the simplest requirement, might be to disallow consultative transfer. An alternative requirement might be to disallow the transition from consultative to blind transfer. Either way the transferor needs to know ahead of time what the transfer target can and cannot do. 2.4 Common Implementation Issues The following are mostly implementation oversights or misunderstandings that are commonly seen in the field and at SIPit events. These are just a few examples. Transfer is very complicated and too few implementations get it right or are robust. The robustness problem is probably largely due to the number of points of failure. In the consultative case there are three dialogs among three user agents and it takes 8 or more transactions to complete it all. Each transaction can fail for various reasons, etc. [Should these be here at all? Is it worth writing these up into a more expanded list in the next revision?] 2.4.1 Consultative with Single Line UA Some SIP user agents only support blind transfer. This may be because the user agent only supports a single dialog or line or it may simply be a business decision. The problem is that this is not typically discovered until the INVITE with Replaces header is sent. This is probably more a best current practices issue rather than a protocol issue. If in the consultative INVITE, the transferor includes a Requires header with the "replaces" token in the value AND the transfer target correctly observes the Requires header, this would not be a problem. The transferor would get a 420 Bad Extension response. It could then try a blind transfer using REFER. 2.4.2 Consultative Turned Blind Cancel Issues Two common mistakes are made when a consultative transfer transitions to a blind transfer. Some implementations of the transferor do not send a CANCEL. They try to use Replaces to replace the early dialog. This is documented in Replaces [I-D.ietf-sip-replaces] as not supported because it just does not work. You cannot reliably replace a dialog on the user agent server side because (due to forking )it is a moving target. The other common mistake is to not wait for the outcome of the CANCEL. The transferor MUST CANCEL the consultative INVITE, wait for the CANCEL to succeed, then send the REFER without Replaces. If the CANCEL fails (as the dialog was setup with a 200 response), the transferor can then send the REFER with Replaces as the consultative Petrie Expires April 17, 2004 [Page 8] Internet-Draft SIP Transfer Issues October 2003 call is no longer an early dialog. 3. Solutions and Directions to Consider This section contains some initial thoughts on ways to resolve the requirements in Section 2. The following are at least preliminary approaches to resolving the requirements identified in this draft. They are mostly independent and can be used separately or all together. These solutions are not intended to be complete. The descriptions are here for discussion on how to proceed. 3.1 Use of Option Tokens Applicable to: Section 2.2.2, Section 2.3.1, Section 2.3.2, Section 2.4.1 In the consultative INVITE, the transferor MUST put the replaces token in the Requires header. In common practice this is often not done. Even if it was used in practice, it is probably not sufficient to completely solve the double ring (see Section 2.2.2) and gateway glare (see Section 2.3.2) problems. It will allow a gateway or user agent acting as the role of transfer target to say "I do not want to perform a consultative transfer". Often the only problem or limitation is the troublesome transition from consultative to blind transfer. To avoid restricting the use of a pure consultative transfer, one could instead restrict the use of the transition from consultative to blind. This can be accomplished by creating a new options token consult2blind. The transferor MUST put this token in the Requires header if it allows the user to back out of the consultation and transition to a blind transfer. 3.2 New Header for Related Dialog Applicable to: Section 2.2.2, Section 2.2.1, Section 2.3.1 Create a new header 'Related' to generally relate a request to another dialog. Create tokens for that header that define the type of relationship between the message containing the Related header and the referenced dialog. The syntax specifies a dialog similar to the Replaces [I-D.ietf-sip-replaces] syntax. However the Related header specifies a relationship as opposed to a specific operation as the Replaces header does. In addition the relationship is abstract for the header and specified by the relationship token. Petrie Expires April 17, 2004 [Page 9] Internet-Draft SIP Transfer Issues October 2003 "Related" HCOLON relation SEMI dialog-param *(SEMI generic-param) relation = ("consult" / token) dialog-param = callid SEMI to-param SEMI from-param to-param = to-tag / early-flag tfrom-param = from-tag / early-flag to-tag = "to-tag" EQUAL token from-tag = "from-tag" EQUAL token early-flag = "early-only" Example: Related: consult; 8719100197@10.1.1.123; to-tag=98748; from-tag=99173 In the context of transfer this can be used to relate the consultative INVITE request with the original dialog between the transferor and the transferee. This is useful to the transfer target's user agent. The consultative INVITE should contain the Related header with the consult token and the dialog information of the original call. In the gateway context it is useful to the location server in deciding which gateway to route the request to. The location server can use the dialog package [I-D.ietf-sipping-dialog-package] or any maintained call state to find which gateway is currently servicing the original call and attempt to use the same gateway for the consultation and target calls. This also has the side effect of specifying that this INVITE is a consultation. 3.3 Transfer on the TDM Side of Gateways A proposal exists for conveying trunk group information [I-D.ietf-iptel-trunk-group]. This may be useful in helping to get all of the legs in the transfer on to the same gateway and trunk group. 3.4 Transfer on the TDM Side of Gateways By putting all of the TDM legs of the transfer parties on the same gateway and providing the gateway with the ability to disallow consultative transfer, it should be possible to perform the transfer on the TDM side. The consultative dialog can be disallowed by the gateway as described in Section 3.1. All of the transfer dialogs can be associated by the gateway as described in Section 3.2. This also gives the gateway enough information to selectively decide when to disallow consultative transfer (i.e. if it knows it has one leg of the original call related to the consultation). This also assumes the gateway location service has dialog state awareness of the original transfer dialog and can route the consultation to the same gateway. If the gateway uses more than one trunk group it may be Petrie Expires April 17, 2004 [Page 10] Internet-Draft SIP Transfer Issues October 2003 necessary to apply [I-D.ietf-iptel-trunk-group] as well to get all of the TDM legs of the transfer out the same trunk group. 3.5 New Header for Actors Applicable to: Section 2.2.2, Section 2.2.1 Create a new header to relate address of records outside of a dialog. Create named tokens to label the type of relationship of the AOR to this dialog or transaction. This could be thought of as a general purpose Referred-By header [I-D.ietf-sip-referredby]. This is useful in the consultative INVITE request to allow the transferor to say this consultation is with regards to transferring the given AOR who is the transferee. "Actor" HCOLON acttoken SEMI name-addr *(SEMI generic-param) acttoken = "transferee" / token Example: Actor: transferee; Joe Transferee This syntax could be combined with that in Section 3.2. However they seem more broadly applicable to other SIP features if they are useable independently. 3.6 Use a Target URI Applicable to: Section 2.1 Create a transfer target URI analogous to the Conference URI in [I-D.ietf-sipping-cc-conferencing]. This URI needs to be globally routable such that the transferor and the transferee (potentially in different domains) can both reach the transfer target via the URI. The URI must be unique to the consultative dialog residing on the transfer target. It cannot be the same for other dialogs (early or established) created as a result of the consultation. 3.7 Disallow Transition from Consultative to Blind Transfer Applicable to: Section 2.2.2, Section 2.3.2 A more drastic approach to the problems associated with transitioning from consultative to blind transfer would be to simply disallow it completely. This would require that the transferor hang on to and complete the consultation dialog until it was setup or failed. This might make it impossible for some user agents to do consultative transfer due to limitations of having only one active dialog at a Petrie Expires April 17, 2004 [Page 11] Internet-Draft SIP Transfer Issues October 2003 time. This solution does not seem very desirable from a market requirements and end user expectations perspective. 3.8 Continue Ringing after CANCEL of Consult Applicable to: Section 2.2.2, Section 2.3.2 An implementation approach to solving some problems on the transfer target caused by the transition from consultative to blind transfer is to hold on to the resources on the far end a little longer. That is, on a phone user agent, hold on to the ringer resource a little longer (e.g. 5 seconds) in the hopes that the blind transfer will come in that can be associated with the CANCELed consultation. If it does, then the blind transfer INVITE gets the ringer resource - covering up the audio artifact that the consultation was CANCELed. In the case where a PSTN gateway is the transfer target, it could hold on to the PSTN resource in an analogous way to the ringer on the phone. 4. Security Considerations TBD References [I-D.ietf-iptel-trunk-group] Gurbani, V., "Representing trunk groups in sip/tel Uniform Resource Identifiers (URIs)", draft-ietf-iptel-trunk-group-00 (work in progress), November 2002. [I-D.ietf-sip-referredby] Sparks, R., "The SIP Referred-By Mechanism", draft-ietf-sip-referredby-03 (work in progress), August 2003. [I-D.ietf-sip-replaces] Biggs, B., Dean, R. and R. Mahy, "The Session Inititation Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-04 (work in progress), August 2003. [I-D.ietf-sipping-cc-conferencing] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", draft-ietf-sipping-cc-conferencing-01 (work in progress), July 2003. Petrie Expires April 17, 2004 [Page 12] Internet-Draft SIP Transfer Issues October 2003 [I-D.ietf-sipping-cc-transfer] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in progress), February 2003. [I-D.ietf-sipping-dialog-package] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog Event Package for the Session Initiation Protocol (SIP", draft-ietf-sipping-dialog-package-02 (work in progress), July 2003. [I-D.ietf-sipping-service-examples] Johnston, A. and R. Sparks, "Session Initiation Protocol Service Examples", draft-ietf-sipping-service-examples-05 (work in progress), September 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997. [RFC3261] 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. [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. Author's Address Daniel Petrie Pingtel Corp. 400 W. Cummings Park Suite 2200 Woburn, MA 02476 US Phone: "Dan Petrie (+1 781 970 0111)" EMail: dpetrie@pingtel.com URI: http://www.pingtel.com/ Appendix A. Acknowledgments Petrie Expires April 17, 2004 [Page 13] Internet-Draft SIP Transfer Issues October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 assignees. Petrie Expires April 17, 2004 [Page 14] Internet-Draft SIP Transfer Issues October 2003 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Petrie Expires April 17, 2004 [Page 15]