SIPPING J. Hwang Internet Draft KT Document: draft-hwang-sipping-midcall-reqs- A. Tripathi 00.txt Expires: July 20, 2004 Huawei Technologies V. Vinit Hughes Software Systems January 20, 2004 Requirements for Mid Call Communication in the SIP draft-hwang-sipping-midcall-reqs-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 July 20, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In its current form, Session Initiation Protocol (SIP) allows session invitations, instant messages, and other requests to be delivered from one party to another. However it doesnot explicitly permit midcall events such as hook/flash from the user to be passed on to the network application server. Without such ability, it is not clear how SIP can be used to provide certain network controlled services. This document identifies a set of requirements for extensions to SIP to provide a MidCall-based communications framework. Hwang Informational - Expires July 2004 1 Requirements for Midcall Communication in SIP January 2005 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction....................................................3 2. Problem Statement...............................................4 3. Requirements....................................................4 4. Security Considerations.........................................4 5. IANA Considerations.............................................4 6. Informative References..........................................5 Author's Addresses.................................................5 Intellectual Property Statement....................................5 Hwang Informational - Expires July 2005 2 Requirements for Midcall Communication in SIP January 2005 1. Introduction The Session Initiation Protocol (SIP) [1] supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. This communication is established by the transmission of various SIP requests (such as INVITE and MESSAGE [4]) from an initiator to the recipient, with whom communication is desired. Softswitches, or IP-based voice switches, are fast replacing expensive, proprietary telecom circuit switches as the primary switching elements in wireline carrier networks. SIP has been widely accepted as the main signalling protocol in the Next Generation wireline and wireless networks. This is reflected in the endorsement of SIP by IPCC and 3GPP. SIP is used for softswitch-to-softswitch signaling, as well as softswitch-to-application server and application server-to-media server signaling. +--------+ | SCP | +-------------------+ +--------+ | Application Server| | | /Media Server | INAP | /+-------------------+ | /SIP +--------+ +-----------+ +---------+ | |Megaco| | ISUP| SSP/ | | MG |------| SoftSwitch|-----| PSTN | | | | | +---------+ +--------+ +-----------+ | | | | | | |Trunks | SIP/H.323/MGCP/Megaco | | | | +-------+ |IAD/PBX| +-------+ ^ ^ ^ ^ FXS| | | |FXO | | | | Black Phones Figure 1. A Typical SoftSwitch Platform End users connect to the SIP based softswitch platform through a SIP- based Integrated Access Device (IAD) or SIP Phone, which hooks into their broadband modem. However usage of SIP in the access network of a wireline carrier network has raised some new requirements about communicating mid-call events to the softswitch platform. Hwang Informational - Expires July 2005 3 Requirements for Midcall Communication in SIP January 2005 This document defines the requirement for adding a MidCall framework to SIP. 2. Problem Statement To provide a uniform service behavior to different kinds of Access end points like MGCP, H.248/Megaco, there is a requirement that SIP based softswitch platforms be able detect and then process mid call event from the SIP end points. However there is lack of clarity as to how to use SIP end points can be made to provide the same service behavior as that provided by the ordinary POTS terminal. The reason is that SIP doesnot provide any mechanism to transfer the hook/flash event from the user's end-point to the softswitch. SIP is a powerful and flexible protocol and provides many mechanisms [5] to provide supplementary services to the SIP end points. However if the same service behavior, as a POTS terminal, is desired then SIP should provide extensions to report any mid-call events like hook/flash to the central softswitch platform. 3. Requirements The following description identifies requirements for a solution that provides MidCall-based communication in SIP. REQ 1: The solution must enable SIP based IADs or PBXs to provide the same POTS interface to the end user. REQ 2: The solution shall try to provide a generic framework for reporting mid-call events which is extensible. REQ 3: The solution shall provide the flexibility in service mapping and preferenecs and based on the following assumptions 1) Predefined mapping between the terminal and the service 2) User's configuration of the preferred mid-call service (for example, through web page) 3) Network application service provides full options to choose by prompting user to select call waiting, call transfer, etc when user provides a mid-call hook/flash indication. REQ 4: The solution should require the SIP Phone to have only one HOOK/FLASH button, similar to the POTS phone. This is required to provide SIP based VOIP connectivity in the greenfield areas. 4. Security Considerations There are no specific Requirements related to Security. 5. IANA Considerations This document introduces no new considerations for IANA. Hwang Informational - Expires July 2005 4 Requirements for Midcall Communication in SIP January 2005 6. 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] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [4] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [5] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", draft-ietf-sipping-cc-transfer-03 (work in progress), October 2004. Author's Addresses Dr. Jinkyung Hwang KT 17 Woomyun-dong Phone: +82-2-526-6830 Seocho-gu, Seoul, Korea Email: jkhwang@kt.co.kr Alok Tripathi Huawei Technologies Phone: +86-755-28789400 Bantian, Shenzhen, China Email: alokt@huawei.com Vikas Vinit Hughes Software Systems Email: vikasvinit@hssworld.com Bangalore, India 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. Hwang Informational - Expires July 2005 5 Requirements for Midcall Communication in SIP January 2005 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Hwang Informational - Expires July 2005 6