A Proposal for Internet Call Waiting Service using SIP [Page 1]
PINT Working Group A. Brusilovsky
Internet Draft E. Gausmann
V. Gurbani
A. Jain
Lucent Technologies
Expires: July 1999
A Proposal for Internet Call Waiting Service using SIP
An Implementation Report
<draft-brusilovsky-icw-00.txt>
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
The purpose of this Internet Draft is to start discussion on the
issues involved in Internet Call Waiting Service (ICW), as part of
interconnecting IP and Global Switched Telephone Network (GSTN) with
the intent of providing ICW service that is much needed by numerous
dial-up Internet users. Interworking of the IP network and GSTN,
based on open well-defined protocols, will promote interoperability
of both the networks and systems built by different vendors. This
Internet Draft is submitted with the goal of becoming an
informational RFC.
The rest of this document is as follows:
<draft-brusilovsky-icw-00.txt> January 1999
A Proposal for Internet Call Waiting Service using SIP [Page 2]
Section 2 briefly describes the services offered to the end
Subscriber. It is the support of these services that necessitates the
proposed internetworking project.
Section 3 describes the scope of the proposed project by introducing
its overall architecture, identifying the interfaces to be
standardized, describing experience with SIP for ICW.
Sections 4, 5, and 6 respectively address security considerations,
supply references, and provide the authors address, as required by
[1].
Section 7 acknowledges individuals providing assistance in the
creation of this document.
Section 8 is the Appendix, which contains IN Tutorial and Figure A.
2. Service Description
It is a well-known problem that call waiting tone interferes with the
operation of a modem. Anyone using the telephone for a modem
connection to a host computer can not gracefully deal with incoming
call waiting calls. Internet Call Waiting is the capability to
provide incoming call notification and completion options when the
Subscriber is on a dial-up IP connection. When a call comes in the
Subscriber is presented with a pop-up dialog box, that presents the
caller's number and, optionally, his or her name. Internet Call
Waiting solution provides a simple, graphical-oriented way to notify
subscribers while connected to the Internet, of incoming calls. It
allows the subscriber to accept or reject the call.
Benefits
Service providers can achieve the following important benefits
through the use of Internet Call Waiting Service:
o More calls completed. Call completion is an important aspect of
the service provided by telecommunication operators. Calls that end
in busy or no- answer, consume network resources. Solution like
Internet Call Waiting contributes to greater call completion which
lowers expense and provides value to both the consumer and service
provider.
o The ICW platform is the foundation to offer services: The service
provider has the opportunity to enhance Internet Call Waiting with
other services like Internet Follow-me, personalized call management,
unified messaging service, click to return (dial) an important call,
and other call management functions which integrate voice and data
services.
o Service provider can offer the following important benefits to the
subscribers through the use Internet Call Waiting Service:
<draft-brusilovsky-icw-00.txt> January 1999
A Proposal for Internet Call Waiting Service using SIP [Page 3]
· Simple way to manage voice and data calls over a single telephone
line.
· Ability to track all incoming calls while the service is active
· PC Graphical Subscriber Interface provides a simple intuitive
Subscriber interface and also allows easy customization.
3. Scope of the Proposed Project
Figure A illustrates the hardware architecture that will support ICW
Service. The lines indicate the control and/or voice paths. Control
paths are labeled by the protocol that will be used over them.
IN elements (SCP, SMS, SSP) are specialized servers, connected to
switches and other network elements. They handle data queries and
updates, specialized call routing and other advanced telecom
services. For more information on Intelligent Network please see our
IN Tutorial in the Appendix of this Internet Draft.
The following software components make up the ICW architecture.
o ICW User Agent Server (UAS) - The ICW UAS (SIP Client) and server
communicate via the SIP protocol over TCP/IP. The ICW UAS can start
up automatically as soon as a PPP connection is established. It also
responds to the incoming request for call treatment by popping up the
dialog box to the subscriber presenting information about the
Calling Party and asking for an Accept or Reject decision. The UAS
sends the resulting choice back to the ICW server. In the case of a
accepted call, the UAS drops the modem connection to the ISP to allow
the incoming call to complete.
o ICW server - a SIP proxy server that perform the following
functions. The SCP is not being used as a general-purpose database
host. Thus, SIP-related database dips are envisioned to be in the
domain of a generic ICW server which can interface with any
commercial-grade database engine or any LDAP-enabled database. The
SCP is free to provide telecommunication intensive tasks that it was
designed for.
- Listening for incoming messages from the application running on
SCP
- Providing a data store mechanism for ICW applications
- Handling Web-based GUI (Applet) requests for subscriber
provisioning on the ICW server
o SCP platform software - The ICW APPLICATION runs on SCP
- ICW Application runs on SCP - The AIN 0.1 Terminating Attempt
Trigger (TAT) is used to enable PSTN call handling. Thus, the
Application responds to an AIN message for every call to the
subscriber. For each call, the Application either returns a
request for normal routing, if the subscriber is no longer active,
<draft-brusilovsky-icw-00.txt> January 1999
A Proposal for Internet Call Waiting Service using SIP [Page 4]
or sends a message to the ICW server passing along the calling
number. Based upon the reply from the ICW server, which may be
Accepted or Rejected, the SCP sends the appropriate instructions ba
ck to the SSP.
Various alternatives exist for firewall support. The ICW
UAS-to-ICW server firewall could be standard corporate security
firewall. However, the security policy would need to allow
TCP-based SIP messages to flow between the ICW UAS and server over
the standard SIP port 5060. The ICW server-to-SCP firewall is
optional and could be used to provide an extra level of protection
for the SCP by restricting Intranet access or by enforcing a more
restrictive security policy than the outer firewall. General and
ICW specific security considerations are covered in Section 4.
Other components in the diagram are part of the standard Internet
and PSTN and include the Internet Service Provider (ISP), ISP
modems and web servers, the Service Switching Point (SSP) and the
Signal Transfer Point (STP). The SSPs must be provisioned with the
necessary trigger for the ICW service, the AIN 0.1 Terminating
Attempt Trigger.
When the Calling Party dials the ICW Subscriber's Destination Number,
the Calling Party experiences the standard Call Waiting treatment,
ringing, until Calling Party abandons or the Subscriber specifies
treatment: Subscriber treatment options and Calling Party experience
are:
o Refuse Call: Calling Party hears ringing until Calling Party
abandons. In SIP terms, this results in the SIP UAS sending a "603
Decline" message to the ICW server.
o Hold Call: Calling Party hears [optional] announcement to hold
while "other" call in progress is completed. The intent is that the
Subscriber will accept the call momentarily. (Another possibility
would be to tell the Calling Party that you'll call them back in a
few minutes, etc) In SIP terms, this results in the SIP UAS sending a
"182 Queued" message to the ICW server.
o Send to Voice Mail (assuming Subscriber has a Voice Mail service):
Calling Party hears voice mail system announcements. (This
redirection to voice mail could, as well, have been redirection to
some other DN, e.g. cell phone, second line, secretary, etc) In SIP
terms, this results in the SIP UAS sending a "380 Alternative
Service" to the ICW server.
o Accept Call: Calling Party hears ringing until is connected to
Subscriber. In SIP terms, this results in the SIP UAS sending a "200
OK" to the ICW server.
Note: Optional treatment options can include taking call via VoIP and
route call to a third party number.
In the proposed Architecture, the Subscriber is assumed to have PPP
service through their ISP. They are surfing the Internet or working
at home, connected to a corporate intranet. Two components of ICW
<draft-brusilovsky-icw-00.txt> January 1999
A Proposal for Internet Call Waiting Service using SIP [Page 5]
reside on their PC; an H.323 client for VoIP and an ICW UAS to drive
the presentation to the Subscriber of Setup and Notification.
Controlling the ICW service is the ICW server for Internet related
control and the combination of the SCP and SSP via AIN functionality
providing PSTN control via SS7. There is an ICW control session
between the PC and the ICW server. Controlling the VoIP aspect is
the H.323 client at the PC and the H.323 gateway with H.323 packets
going between them via the internet. The SCP controls the IP via
Bellcore's GR-1129. The SCP and ICW server have a TCP/IP connection.
The call path of the accepted call consists of the Calling Party
being routed to the IP (intelligent peripheral) and bridged to the
ICW Subscriber from the H.323 gateway. Firewall appliances are
placed on all IP connections of the service provider. A call
scenario below walks through this architecture. Integration of the
H.323 GW and IP as well as the SCP and ICW server is a possibility
for future enhancements.
Call Scenario
Subscription to the service.
o Subscriber signs up for the service.
o Subscriber downloads and installs the ICW UAS software.
o Subscriber Information is provisioned in the SMS (and SCP).
Activation of the service and coordination with the ICW Server
(Transparent for the ICW User)
o ICW UAS establishes TCP connection.
o Subscriber authenticates himself/herself and Register with ICW
Server using the encrypted password and phone number.
o ICW Server stores information in database.
Call Arrival
o Calling Party initiates call to Subscriber.
o SSP (Switch) encounters TAT.
o SCP query launched.
o SCP determines if call is for an ICW subscriber (if not then other
service logic applies).
o SCP sends a SIP "INVITE" message with Calling Number, optional
Calling Name and Called Number (and receives a SIP acknowledgement
from the ICW Server)
o If ICW is activated for the called subscriber, ICW Server returns
"TRYING" to SCP. The SCP instructs SSP to play an announcment, e.g.
ringing. ICW Server determines, based on the Called Number and the
IP Address of the ICW UAS and sends the SIP INVITE message to the ICW
UAS.
o If ICW is not activated ICW Server returns "NOT FOUND" to SCP. SCP
returns an Authorize Term message to the SSP so call proceeds as
normal.
Communicating subscriber's choice to the SCP.
o ICW UAS returns a SIP "DECLINE" (for normal SSP treatment) or "OK"
<draft-brusilovsky-icw-00.txt> January 1999
A Proposal for Internet Call Waiting Service using SIP [Page 6]
(for connecting the call).
o ICW Server passes along the SIP message to the SCP
Choice: Drop Modem, take call.
o ICW UAS causes Modem to drop.
o SCP instructs switch to continue with the call (Authorize Term).
o Switch connects Calling Party to Subscriber line causing the phone
to ring.
Choice: Send to Voice Mail.
o SCP sends Authorize Term message to switch to deliver the call to
the subscriber's line.
o SSP detects Busy and uses standard Call Forwarding on Busy to send
to Voice Mail
Experiences in using SIP for ICW Project
The biggest advantage to using SIP in the ICW project was its
ASCII-based nature and a concise set of messages. We were able to
get a bare-bones SIP server running in a good part of a week. SIP is
geared towards Internet protocol services; ICW is a prime example of
such a service. SIP's semantics lend themselves very efficiently to
the semantics of the ICW service. SIP has a very rich set of
response codes that we were able to tailor to the various ICW states,
such as the user accepting a call, declining a call, redirecting a
call to a new location, or simply not being on the PC when the call
notification arrived. Another advantage of SIP is that a SIP-based
architecture is easily explained to even those who do not possess an
in-depth understanding of Internet in general and IP protocols in
particular. Various SIP entities like SIP User Agent Server, Proxy
Server, Redirect Server, etc. lend themselves to a very extensible
architecture.
The disadvantages of SIP are few; one of them being its constant
state of flux. During ICW development, the SIP draft RFC changed no
less then 3 minor versions. This made it somewhat difficult to agree
on a standard. However, this disadvantage will be mitigated in the
future when the SIP draft becomes a Draft Standard. The other big
disadvantage was driven by the general lack of support for database
queries. For instance, an SCP would like to authoritatively know if
a user was on the Internet before sending him/her the call
notification. However, the SIP message set did not support general
querying capabilities for this purpose. We ended up using the SIP
OPTIONS message for this purpose, even though the draft mandates that
OPTIONS message is used primarily for capability set negotiations.
Finally, the SIP RFCs are becoming more complex with each new
revision. We believe that while adding features is critical, it
would be in the best interest to maintain the simplicity of SIP for
rapid development, debugging, and deployment.
Security Considerations
<draft-brusilovsky-icw-00.txt> January 1999
A Proposal for Internet Call Waiting Service using SIP [Page 7]
ICW communications between the PC and the ICW Server may travel over
the Internet. Thus it is essential to provide encryption for the
communications. In addition to encryption, and to make sure that the
PC belongs to a registered subscriber, it is also necessary to
provide authentication of both the end points; i.e. ICW Server and
the PC. ICW security has been designed to authenticate both end
points and if the authentication succeeded, encrypt the
communications (control channel) using a symmetric key. This key is
provisioned in the ICW Server database as well as generated at the
subscriber's end-point (the PC) when the software is initially
installed. In the future, migration of the ICW security
infrastructure to SSL is envisioned.
ICW Security Requirements are, assentially, the same as PINT Security
Requirements outlined in [4]:
o Peer entity authentication to allow a communicating entity to prove
its identity to another in the network. Two types of peers should be
recognized for the purposes of this project: end-user and the Web
server, and Web server and SN. Between the end-user and Web server
the authentication could be accomplished by means of the user name
and password combination. In addition, encrypted communications
could be used in this case. Same could be used between the Web
server and SN, but it is proposed that additional security be
accomplished by replicating a part of the server's data base relevant
to the business providing the service.
o Non-repudiation to account for all operations in case of doubt or
dispute. This could be achieved by logging all the information
pertinent to the Web transaction. In addition, the PSTN network will
maintain its own account of the transaction for generating bills.
o Confidentiality to avoid disclosure of information without the
permission of its owner. Although this is an essential requirement,
it is not particular to the proposed project.
o End-user profile verification to verify if the end user is
authorised to use a service.
In the course of the project execution, additional requirements are
likely to arise and many more specific security work items are likely
to be proposed and implemented.
Some of the ICW-specific security considerations:
o Hacking is a threat to any Service Provider (PSTN, Intranet,
Internet). It is real danger - phone companies are common targets
o Strong Firewall solutions are needed
o Fraudulent Subscription is one of the threats
o Existing mechanisms applied to the Internet can be implemented
o Stealing a Call is a new type of security threat
<draft-brusilovsky-icw-00.txt> January 1999
A Proposal for Internet Call Waiting Service using SIP [Page 8]
o Denial of telephone service attack is possible
o Encrypted password protection can be used as one of the possible
solutions.
5. References
[1] J. Postel, RFC 1543, "Instruction to RFC Authors". October 1993
[2] ITU-T Q.12xx Recommendation Series, Geneva, 1995.
[3] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The
Intelligent Network Standards, their Application to Services".
McGraw-Hill, 1996.
[4] M. Krishnaswamy, "PSTN-Internet Internetworking - An Architecture
Overview", Internet Draft
[5] H. Schulzrinne, "SIP for Click-To-Dial-Back and Third-Party
Control", Internet Draft
[6] S. Petrack, "IP Access to PSTN Services: Basic Service
Requirements, Definitions, and Architecture", Internet Draft
[7] Handley, Schulzrinne, Schooler, Rosenberg, "SIP: Session
Initiation Protocol", Internet Draft
6. Authors' Address
Alec Brusilovsky
E-mail: abrusilovsky@lucent.com
Telephone: +1-630-713-8401
Fax: +1-630-713-5840
Lucent Technologies
263 Shuman Blvd.
Naperville, IL 60566 USA
Eric Gausmann
E-mail: egausmann@lucent.com
Telephone: +1-630-713-5361
Fax: +1-630-713-5840
Lucent Technologies
263 Shuman Blvd.
Naperville, IL 60566 USA
Vijay Gurbani
E-mail: vkg@lucent.com
Telephone: +1-630-224-0216
Fax: +1-630-713-5840
Lucent Technologies
263 Shuman Blvd.
<draft-brusilovsky-icw-00.txt> January 1999
A Proposal for Internet Call Waiting Service using SIP [Page 9]
Naperville, IL 60566 USA
Ajay Jain
E-mail: ajayjain@lucent.com
Telephone: +1-630-979-5218
Fax: +1-630-713-5840
Lucent Technologies
263 Shuman Blvd.
Naperville, IL 60566 USA
Glossary
AIN Advanced Intelligent Network
API Application Program Interface
DN Destination Number
GSTN Global Switched Telephone Network
ICW Internet Call Waiting
IN Intelligent Network
IP Intelligent Peripheral
PSTN Public Switched Telephone Network
POTS Plain Old Telephone Service
SCP Service Control Point
SIP Session Initiation Protocol
SN Service Node
SMS Service Management System
TAT Terminating Attempt Trigger
UAS User Agent Server (SIP Terminology)
VoIP Voice over IP (Internet Protocol)
7. Acknowledgments
The authors would like to acknowledge Igor Faynberg, Jenny Huang,
Jack Kozik, Hui-Lan Lu, Bill Opdyke, Jonathan Rosenberg, Henry
Sinnreich, Doug Varney and Kumar Vemuri for their insightful comments
presented at the working discussions that lead to the creation of
this document. Our special thank you is going to John Stanaway for
being instrumental in utilizing SIP for the ICW project.
8. Appendix (IN Tutorial and Figure A)
Intelligent Network (IN), excerpt from [4]
IN ([2], [3]) is an architectural concept that provides for the
real-time execution of network services and customer applications in
a distributed environment consisting of interconnected computers and
switching systems. Also included in the scope of IN are systems and
technologies required for the creation and management of services in
this distributed environment.
<draft-brusilovsky-icw-00.txt> January 1999
A Proposal for Internet Call Waiting Service using SIP [Page 10]
In PSTNs, user's telephone terminals and fax machines are connected
to telephone switches. The switches (which can be Central
Offices--for wireline communications and Mobile Switching Centers
(MSCs)--for wireless communications) are specialized computers
engineered for provision of services to the users. The switches
themselves are interconnected in two ways: 1) through trunks on which
the voice is carried and 2) through a specialized fault-tolerant data
communications network, which is (principally) used for call setup
and maintenance. This network is called (after the ITU-T standard
protocol suite that it uses) Signalling System No. 7 (SS7). In
addition, the switches are connected to general purpose computers
that support specialized applications (called Operations Systems)
whose role includes network management, administrative functions
(e.g., billing), maintenance, etc. Operation systems are not
connected to the switches through the SS7 network, which is, again,
engineered only for set-up and real time maintenance of calls. In
most cases, X.25 protocol is used for communications between
operations systems and switches. Even a simple two-party call in
most cases involves several switches, which may also be located in
different PSTNs. To this end, the switches alone comprise a complex
distributed processing environment. As far as the end users are
concerned, the switches are ultimately responsible for delivering
telecommunications services. Certain elementary services (such as
provision of the dial tone, ringing the called line, and establishing
a connection between two users) are called basic services, and all
switches can presently cooperate in delivering them to end users.
In addition, a multitude of services (such as Freephone [a.k.a. 800
number in North America], Conference Calling, Call Forwarding, and
many others) require much more than basic call processing. Such
services are called Supplementary Services, and their implementation
requires that specialized applications (called Service Logic) be
developed. Developing switch-based service logic for each
supplementary service would be an extremely expensive (if at all
possible) task, which--in the presence of multiple switch
vendors--would also require an extensive standardization effort.
The IN architecture is the alternative which, in a nutshell,
postulates using a network-wide server (called Service Control
Function [SCF]). The SCF executes service logic and instructs the
switches on how to complete the call. A switch is involved only in
executing the basic call process, which is interrupted (at
standardized breakpoints called triggers) when specialized service
logic needs be executed. On encountering such a breakpoint, the
switch issues a query to the SCF and waits for its instruction. In
addition (and this is essential for supporting the services described
in section 2), the SCF may initiate a call on its own by instructing
switches to establish necessary connections among themselves and to
the call parties.
<draft-brusilovsky-icw-00.txt> January 1999
A Proposal for Internet Call Waiting Service using SIP [Page 11]
Physically, the SCF may be located in either stand-alone general
purpose computers called Service Control Points (SCPs) or specialized
pieces of equipment called Service Nodes (SNs). In addition to
executing service logic, a service node can perform certain
switching functions (such as bridging of calls)as well as a set of
specialized functions (such as playing announcements, voice
recognition and text-to-speech conversion). An important distinction
between an SCP and SN is that the former is connected to switches via
the SS7 network while the latter communicates with the switch via
Integrated Services Digital Network (ISDN) Primary or Basic Rate
Interfaces (PRI or BRI), which combine both the signaling and voice
paths. With the present state of IN standardization, in principle,
either an SCP or SN could be connected to an Internet server in order
to support the services outlined in section two. To further narrow
the scope of work so as to produce tangible results as soon as
possible, the proposed project specifically addresses only
interconnection between a server and SN.
Within the IN architecture, the relevant administration of the
network entities (i.e., setting the triggers in the switches,
transferring externally developed service logic to SCPs and SNs, and
maintaining the network databases with the customer-related data) is
performed by a specialize Operation System called Service Management
System (SMS).
<draft-brusilovsky-icw-00.txt> January 1999
A Proposal for Internet Call Waiting Service using SIP [Page 12]
Figure A
|F|
|i|
+---------------------+ ============= |r|
| +-------+| || || SIP |e| +--------+
| PC Access | ICW || || Internet |+-..-..|w|-..-..-| ICW |
| o..........+ UAS || || || |a| | Server |
| +--+----+| =========+=== |l| +---+----+
| Voice Access : | | |l| |
| 0------------I: | : _____:_____
| I: | | SIP Firewall
| I: | : -----------
| I: | | |
| I: | +---+---+ :
| I: | | ISP | |
|ICW I: | +---+---+ :
|Subscriber I: | | +-------+ +---+---+
+--------------I:-----+ PPP : | SMS |---| SCP |
I:......................+ | +-------+ +---+---+
L----------------------+: : s
POTS =======I:=|========== |
|| I: : || =====s====
|| I: | || || ||
|| +++-+---+ || || SS7 ||
o---------------------------++-----| SSP | || ||Network||
Calling Party || +---+---+ || =====s====
(Voice Access) || s P S T N || |
========= | ========= SS7 s
s-s-s-s-s-s-s-s-s-s-s-s-s+
Legend: Signaling
..-..- - SIP (over IP)
s-s-s - SS7 signaling links
----- - POTS connection
..... - PPP connection
draft-brusilovsky-icw-00.txt> Expires: May 1999
