SIPPING WG A. Johnston, Ed. Internet-Draft J. McMillen Intended status: Informational Avaya Expires: March 16, 2007 September 12, 2006 Transporting User to User Information for Call Centers using SIP draft-johnston-sipping-cc-uui-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 March 16, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Several approaches to transporting User to User Information (UUI) in Contact Center scenarios have been implemented. This document discusses the approaches and recommends a single approach for standardization. Johnston & McMillen Expires March 16, 2007 [Page 1] Internet-Draft SIP UUI for CC September 2006 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Call Flows . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. MIME body Approach . . . . . . . . . . . . . . . . . . . . 6 3.3. Header Field Approach . . . . . . . . . . . . . . . . . . 6 3.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 7 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Appendix - Syntax for UUI Header Field . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Informative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Johnston & McMillen Expires March 16, 2007 [Page 2] Internet-Draft SIP UUI for CC September 2006 1. Overview This document describes the transport of User to User Information (UUI) in Contact Center secnarios using SIP [1]. 2. Roles There are three roles in a typical Call Center scenario: Originator - The party generating the call destined for the contact center. ACD - The automatic call distributer which performs database queries and determines proper routing for the call. Terminator - The destination of the call as determined by the ACD. 3. Approaches Three approaches will be described: MIME body, header field, and URI parameter transport. 3.1. Call Flows All three approaches use the same call flows, shown in Figures 1, 2, and 4 below. Figure 1 shows the ACD redirecting the call prior to it being answered using a 302 Moved Temporarily response. User to user information (UUI) is added by the ACD which is then included in the INVITE sent to the Terminator. The URI of the terminator is contained in the Contact header field of message F2. Originator ACD Terminator | | | | INVITE F1 | | |------------------->| | | 302 Moved (UUI) F2 | | |<-------------------| | | ACK F3 | | |------------------->| | | INVITE (UUI) F4 | | |---------------------------------------->| | 200 OK F5 | |<----------------------------------------| | ACK F6 | Johnston & McMillen Expires March 16, 2007 [Page 3] Internet-Draft SIP UUI for CC September 2006 |---------------------------------------->| Figure 1. Call flow with redirection prior to answer. Figure 2 shows a call flow in which the call is answered by the ACD and then the call is transferred using a REFER. If the ACD does not care to receive notification of the outcome of the transfer, the BYE could be sent immediately, or the Refer-Sub: false header field added to the REFER. If the REFER is sent out of dialog, the Target-Dialog header field will need to be present. Originator ACD Terminator | | | | INVITE F1 | | |------------------->| | | 200 OK F2 | | |<-------------------| | | ACK F3 | | |------------------->| | | REFER (UUI) F4 | | |<-------------------| | | 202 Accepted F5 | | |------------------->| | | NOTIFY (100 Trying) F6 | |------------------->| | | 200 OK F7 | | |<-------------------| | | INVITE (UUI) F8 | | |---------------------------------------->| | 200 OK F9 | |<----------------------------------------| | ACK F10 | |---------------------------------------->| | NOTIFY (200 OK) F11| | |------------------->| | | 200 OK F12 | | |<-------------------| | | BYE F13 | | |<-------------------| | | 200 OK F14 | | |------------------->| | Figure 2. Call flow with transfer after answer. Note that there have been some proposals to use REFER for scenario of Figure 1. In this case, a REFER is sent by the ACD during the early dialog. This NOT RECOMMENDED call flow is shown in Figure 3. This flow is not recommended due to the number of messages exchanged (due Johnston & McMillen Expires March 16, 2007 [Page 4] Internet-Draft SIP UUI for CC September 2006 to the REFER, CANCEL, and 487 responses) and the sending of the REFER in the early dialog. Originator ACD Terminator | | | | INVITE F1 | | |------------------->| | | 180 Ringing F2 | | |<-------------------| | | REFER (UUI) F3 | | |<-------------------| | | 202 Accepted F4 | | |------------------->| | | NOTIFY (100 Trying) F5 | |------------------->| | | 200 OK F6 | | |<-------------------| | | INVITE (UUI) F7 | | |---------------------------------------->| | 200 OK F8 | |<----------------------------------------| | ACK F9 | |---------------------------------------->| | NOTIFY (200 OK) F10| | |------------------->| | | 200 OK F11 | | |<-------------------| | | CANCEL F12 | | |------------------->| | | 200 OK F13 | | |<-------------------| | | 487 Request Terminated F14 | |<-------------------| | | ACK F15 | | |------------------->| | Figure 3. NOT RECOMMENDED call flow showing REFER prior to answer. In Figure 4, the ACD is shown proxying the INVITE to the terminator instead of redirecting as in Figure 1. Johnston & McMillen Expires March 16, 2007 [Page 5] Internet-Draft SIP UUI for CC September 2006 Originator ACD Terminator | | | | INVITE F1 | | |------------------->| INVITE (UUI) F2 | | 100 Trying F3 |------------------->| |<-------------------| 200 OK F4 | | 200 OK F5 |<-------------------| |<-------------------| | | ACK F6 | | |------------------->| ACK F7 | | |------------------->| Figure 4. Call flow with proxying. 3.2. MIME body Approach One method of transport is to transport the UUI information as a MIME body. This is in keeping with the SIP-T architecture in which MIME bodies are used to transport ISUP information. However, in the SIP-T example, the body is added by the originator and used by the terminator. The insertion of the UUI by an intermediary, the ACD, is difficult. The body would need to be encoded in the Contact URI of Figure 1 or the Refer-To URI of Figure 2. For example, if the application/acd MIME type were defined: Contact: The resulting INVITE would then have two message bodies, one SDP, the other being the MIME object. In addition to the body, the escaped Content-Type header field should also be included in the resulting INVITE. While the body approach would work with the redirection and REFER call flows, but does not work with the proxy call flow of Figure 4. 3.3. Header Field Approach Another approach that has been proposed is to use a header field to tranport the UUI information. The header field would be excaped into the Contact or Refer-To URI. The header field approach will work with the redirection, REFER, and proxy call flows. The Call-Info header field is related to the UUI information. However, there are a number of important differences: Call-Info is for rendering to the user. While some of the UUI information may ultimately be rendered to the user, most of the UUI information will be consumed by the end device. Johnston & McMillen Expires March 16, 2007 [Page 6] Internet-Draft SIP UUI for CC September 2006 Call-Info contains a URI pointer the information instead of the actual information itself. The use of the data URI scheme [6] could be used to overcome the second issue, i.e.: Call-Info: For these reasons, a separate header field needs to be defined, described here as User-to-User: Contact: The resulting INVITE would contain the User-to-User header field. 3.4. URI Parameter Another proposed approach is to encode the UUI as a URI parameter into the Contact or Refer-To URI. Contact: The resulting INVITE would contain UUI in the Request-URI of the INVITE. The URI parameter has a drawback in that a URI parameter will not survive retargeting by a proxy. That is, if the URI is an Address of Record instead of a Contact URI, the URI parameter will not be copied over the Contact URI, resulting in the loss of the information. 4. Recommendation The recommendation is to define a new SIP header field User-to-User to transport UUI information in Contact Center applications. 5. Appendix - Syntax for UUI Header Field Editor's Note: Eventually this text will move to a SIP Working Group document to define the new header field. The User-to-User header field can be present in INVITE requests and responses only. The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 2234 and extends RFC 3261. UUI = "User-to-User" HCOLON uuidata *(SEMI generic-param) Johnston & McMillen Expires March 16, 2007 [Page 7] Internet-Draft SIP UUI for CC September 2006 uuidata = token 6. IANA Considerations TBD. 7. Security Considerations TBD. 8. Informative 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] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002. [3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [5] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, May 2006. [6] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998. [7] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", draft-ietf-sip-target-dialog-03 (work in progress), December 2005. Authors' Addresses Alan Johnston (editor) Avaya St. Louis, MO 63124 Email: alan@sisptation.com Johnston & McMillen Expires March 16, 2007 [Page 8] Internet-Draft SIP UUI for CC September 2006 Joanne McMillen Avaya Email: joanne@avaya.com Johnston & McMillen Expires March 16, 2007 [Page 9] Internet-Draft SIP UUI for CC September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Johnston & McMillen Expires March 16, 2007 [Page 10]