J. Hwang Internet Draft Document: draft-hwang-sipping-infomidcall- KT 00.txt Expires: July 2004 February 2004 INFO Usage Examples for Network-based Mid-Call Service draft-hwang-sipping-infomidcall-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. Abstract This document describes the INFO usage examples for network based mid-call service. Mid-call based services are for example, Call Transfer, Call Waiting, and Three-Way Calling. Other possible mid- call services are useful and important, even more in IP multimedia network. The cases described in SIP service examples (draft-ietf- sipping-service-examples-05) are Terminal-basis. Since the service procedures are fixed in the Terminal, the features are not extensible. This document propose network-based mid-call control mechanism with INFO and show examples that simple mid-call request (INFO) from the Terminal, the network application server provide various mid-call services by prompting user through the Media Server, according to the subscription information of the user. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction....................................................3 2. Network-based Mid-Call Service Examples.........................3 2.1 Call Transfer..................................................5 Hwang Informational - Expires July 2004 1 INFO usage examples for Network based February 2004 mid-call control 2.2 Call Waiting...................................................6 3. Other Possible Examples.........................................8 4. Proposed INFO format............................................8 5. Security Considerations.........................................9 6. IANA Considerations.............................................9 References........................................................10 Author's Addresses................................................10 Intellectual Property Statement...................................10 Full Copyright Statement..........................................10 Hwang Informational - Expires July 2004 2 INFO usage examples for Network based February 2004 mid-call control 1. Introduction The SIP INFO method [1] is defined for carrying application level information along the session signaling path during the call session. The main purpose of INFO is the mid-call information delivery, especially PSTN signaling messages between PSTN gateways through SIP- T [2]. Mid-Call services are for example, call transfer, call waiting, three-way calling and etc. Mid-call feature is for calling or called party to request the services in the middle of the call. As this is useful and essential feature in PSTN, the IP-based Next Generation Network (NGN) where various multimedia services are to be provided even more requires the enhanced mid-call services. In [3], several mid call service examples are described. The cases are terminal-basis. Since the service procedures are fixed and the buttons are predefined in the terminal, the features are not extensible. This document proposes network-based mid-call control mechanism with INFO. Two examples are described that simple mid-call request (INFO) from the Terminal, the network application server provide various mid-call services by prompting user through the Media Server, according to the subscription information of the user or predefined configuration. Addition of media type to Content-Type header in INFO is also proposed. 2. Network-based Mid-Call Service Examples To provide network-based mid-call services, the terminal only has a mid-call request function (INFO) and the services are on the application server side. Binding between the terminal and the services are possible in several ways. 1) Predefined mapping 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 requests a mid-call. The examples in this document assume 1) or 2). Network architecture for network-based mid-call service is depicted in Figure 1. o Softswitch includes two interfaces to the subscriber side: one is SIP interface to SIP phone and the other is MEGACO interface to POTS phone. Softswitch has the trigger function that routing requests from the terminal to appropriate application service. For mid-call requests, SIP phone SHOULD have mid-call button that initiate INFO message; From POTS phone, user makes 'hook-flash', then AGW notify to Softswitch and the Softswitch generates INFO message to Application Hwang Informational - Expires July 2004 3 INFO usage examples for Network based February 2004 mid-call control server. This contribution only concerns the SIP interface between Application server and Softswitch(SIP block mapped on MGC) or Application server and the terminal. The MEGACO interface is shown here for general mid-call environment including POTS phone. o Application server includes several mid-call services. It has SIP interfaces to Softswitch and Media Server. We assume that the service model in Application server is B2BUA. Since the mid-call is requested from the terminal and the Application server receives and processes it, the mid-call INFO request is ended at the Application server. Therefore the UAC of the INFO is terminal (or SIP block mapped on MGC in the Softswitch) and the UAS of the INFO is Application server. o Media Server includes prompting and announcement functions. It interfaces to Application server with SIP and provides media control and processing resources controlled by the Application server. Mid-call services +----+ +----+ +----+ +---+ +-| CW |-| CT |-| TWC|-|...|-+ | +----+ +----+ +----+ +---+ | SIP | Application Server +--------+ | /-------\ | | | |UAS/UAC| | | | \-------/ | | +------------+---------------+ | | | SIP | +----+----+ | | Media | +------------+---------------+ | Server | | SIP Proxy Server | +----+----+ | (Softswitch) | ** | /-------\ | ** | |UAC/UAS| | ** | \-------/ | ** | +--------+ | ** | | MGC | | ** +---+-----------+----+---+---+ ** | MEGACO | ** | +----+---+ ** SIP| | AGW |************** RTP | +----+---+ * /-------\ | * |UAC/UAS| | * \-------/ | * +---+ +---+ * || || || || * + + + + * +++++ +++++ * * * Hwang Informational - Expires July 2004 4 INFO usage examples for Network based February 2004 mid-call control ************************************ (SIP phone) (POTS phone) CW: Call Waiting service CT: Call Transfer service TWC: Three Way Calling service MGC: Media Gateway Controller AGW: Access Gateway POTS: Plain Old Telephone Service Figure 1: Network Architecture for network-based Mid-call services 2.1 Call Transfer Call transfer is the service that during a call between two parties, transferor initiates a mid-call and input the 2nd callee's (transfer target) number, then the transferee and the 2nd callee (transfer target) are connected. Network based call transfer flow is presented in Figure 2. (Transferor)(Transferee)(Transfer Target) Original Original 2nd Softswitch Application Media Caller Callee Callee (SIP Proxy) Server Server (A) (B) (C) | RTP F1 | | | | | |<==========>| | | | | | 'Hook | INFO(mid-call) F2 | | | |--Flash'------------------------------o----------->| | | | 200 OK F3 | | | |<-------------------------------------o------------| | | | INVITE (hold) F4 | | | | |<------------------------o------------| | | | 200 OK F5 | | | | |-------------------------o----------->| | | | ACK F6 | | | | | RTP hold |<------------------------o------------|INVITE(noSDP)F7 || | | |----------->| | | | | |200OK(SDP MS)F8 | | reINVITE(SDP MS) F9 | |<-----------| |<-------------------------------------o------------| | | | 200 OK (SDP A) F10 | | | |--------------------------------------o----------->| | | | | | |ACK(SDP A)F11 | | ACK F12 | | |----------->| |<-------------------------------------o------------| | | | RTP F13 | | | | |<==============================================================>| | | | | |INFO(pc) F14| | | | | |----------->| | | | | |200 OK F15 | | |"Please input transferring number" F16|<-----------| Hwang Informational - Expires July 2004 5 INFO usage examples for Network based February 2004 mid-call control |<**************************************************************>| | | (user input C's digit number) |INFO(oc,C)F17 | | | | |<-----------| | | | | | 200 OK F18 | | | | | |----------->| | | | | | BYE F19 | | | | | |----------->| | | | | | 200 OK F20 | | | | INVITE (no SDP) F21 |<-----------| | | |<-----------o------------| | | | | 200 OK (SDP C) F22 | | | | |------------o----------->| | | | reINVITE(SDP C) F23 | | | | |<------------------------o------------| | | | 200 OK (SDP B) F24 | | | | |-------------------------o----------->| | | | ACK F25 | | | | | |<------------------------o------------| | | | | ACK (SDP B) F26 | | | | RTP F27 |<-----------o------------| | | |<==========>| | | | | | BYE F28| | | | |<-------------------------------------o------------| | Figure 2. Call Transfer Scenario - F1: User A and B have conversation with the RTP connection. - F2~F3: User A decides to transfer the call to User C. He pushes the 'mid-call' button in the phone. Then INFO request is delivered to Application server through Softswitch (SIP Proxy). Application server decides that the request comes from Call Transfer subscriber. It answers with 200 OK. (As we mentioned in the head of the Section 2, the decision can be made in several ways) - F4~F6: Application server holds the phone of User B to suspend RTP packets. - F7~F16: Application server connects User A and Media Server, and prompt and collect user information the transferring number. User A inputs User C's phone number. In this case, we assume that the MCGP Audio package [4] is used to control the Media Server play announcement and collect digits and as the transport, INFO method is used. - F17~F20: Media server sends the collected number (C) to Application Server. Application server disconnect with Media server. - F21~F27: Application server connects User C and User B by 3PCC. The RTP connection is established. - F28: Application server sends BYE to User A. The RTP connection between User A and User B finally released. 2.2 Call Waiting Call Waiting is the feature that during a call, the subscriber to be notified another incoming call arrival to his phone. Network based call waiting scenario is depicted in Figure 3. Hwang Informational - Expires July 2004 6 INFO usage examples for Network based February 2004 mid-call control (Call Waiting Subscriber) Original Original 2nd Softswitch Application Media Caller Callee Caller (SIP Proxy) Server Server (A) (B) (C) | RTP F1 | | | | | |<==========>| | | | | | | | INVITE B (SDP C) F2 | | | | |------------o----------->| | | | | 180 Ringing F3 | | | | |<-----------o------------| | | | | | |INVITE(noSDP)F4 | | | | |-----------> | | | | |200OK(SDP MS)F5 | | INVITE (SDP MS) F6 | |<-----------| | |<------------------------o------------| | | | 200 OK (SDP B) F7 | | | | |-------------------------o----------->| | | | ACK F8 | | | | | |<------------------------o------------| | | | | | |ACK(SDP B)F9| | | RTP F10 | | |----------->| | |<=================================================>| | | | | INVITE(noSDP)F11 | | | | |-----------> | | | | 200OK(SDP MS)F12 | | INVITE (SDP MS) F13 | |<-----------| |<-------------------------------------o------------| | | | 200 OK (SDP A) F14 | | | |--------------------------------------o----------->| | | | ACK F15 | | | | |<-------------------------------------o------------|ACK(SDP B)F16 | | RTP F17 | | |----------->| |<==============================================================>| | | | | |INFO(pa) F18| | | | | |----------->| | | | | |200 OK F19 | | | 'Waiting Tone' F20 | |<-----------| | |<**************************************************| | "Hook | INFO (mid-call) F21 | | | | Flash" |-------------------------o----------->| | | | 200 OK F22 | | | | |<------------------------o------------INVITE(hold)F23 | | | | |----------->| | | | | | 200 OK F24 | | | | | |<-----------| | | | | | ACK F25 | | | RTP hold| | |----------->| || | | | | INVITE(noSDP)F26 | | | | |----------->| Hwang Informational - Expires July 2004 7 INFO usage examples for Network based February 2004 mid-call control | | | | 200OK(SDP MS)F27 | | | 200 OK (SDP B) F28 |<-----------| | | |<-----------o------------| | | | | ACK F29 | | | | | |------------o----------->|ACK(SDP B)F30 | | | RTP F31 | |----------->| | | |<====================================>| Figure 3. Call Waiting Scenario - F1: User A and B have conversation with the RTP connection. - F2~F3: User C calls to User B. Application server receives the INVITE through the Softswitch (SIP Proxy) and know that the called party (User B) is the Call Waiting subscriber and he is busy now. It sends 180 Ringing to calling User C - F4~F10: Application server connects User B with the switching resource in Media Server. With this, bridging between two party among three can be established efficiently. - F11~F17: Application server connects User A and Media Server and make a bridge between A and B by the switch in Media Server. - F18~F22: To provide 'Call Waiting Tone' to the subscriber B, Application server sends INFO with play announcement event and the tone parameter [4]. Notified by the call waiting tone, User B requests the mid-call by pushing mid-call button in the phone. - F23~F25: Application server sends hold INVITE to Media server to suspend RTP packets between User A and User B. - F26~F31: Application Server adds the User C to the switch in Media Server and connects between User B and User C. RTP connection is established and User B and C can talk each other. When User B push mid-call button (or Hook Flash), the switch between User B and C is disconnected, and the User A and B is reconnected and resume the conversation. 3. Other Possible Examples Allowing service interactions between user and the services during the call, the application of the mid-call feature is broad depending on the applicable service domains. Other than the scenarios in Section 2, possible mid-call examples are: - Attendant connection in IP-PBX - Call disposition (such as forwarding to Voicemail) during the call - Any user-service interaction services during the call. 4. Proposed INFO format We propose that for the INFO message format to be used in mid-call request, use the media type "midcall" as follows: Hwang Informational - Expires July 2004 8 INFO usage examples for Network based February 2004 mid-call control Content-Type: application/midcall Content-Length:0 5. Security Considerations This document introduces no new considerations for Security. 6. IANA Considerations This document introduces no new considerations for IANA. Hwang Informational - Expires July 2004 9 INFO usage examples for Network based February 2004 mid-call control References [1] Donovan, S., "The SIP INFO Method" RFC 2976, October 2000 [2] Vemuri. A., Peterson, J., "SIP-T: Context and Architecture" RFC 3372, September 2002 [3] Johnston, A., Sparks R., Cunningham C. Donovan S., Summers K. "Session Initiation Protocol Service Examples" draft-ietf-sipping- service-examples-05 (work in progress), August 29, 2003 [4] Cromwell, D., "Proposal for an MGCP Advanced Audio Package" RFC 2897, August 2000 Author's Addresses Jinkyung Hwang KT 17 Woomyun-dong Phone: 82-2-526-6830 Seocho-gu, Seoul Korea Email: jkhwang@kt.co.kr 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. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 Hwang Informational - Expires July 2004 10 INFO usage examples for Network based February 2004 mid-call control 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. 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. Hwang Informational - Expires July 2004 11