Internet DRAFT - draft-hwang-sipping-midcall-reqs
draft-hwang-sipping-midcall-reqs
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
