Internet DRAFT - draft-ietf-pint-icw

draft-ietf-pint-icw



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: May 1999


         A Proposal for Internet Call Waiting Service using SIP
                        An Implementation Report

                      <draft-ietf-pint-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-ietf-pint-icw-00.txt>                             November 1998

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-ietf-pint-icw-00.txt>                             November 1998

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  UAS - The ICW UAS 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,
     or  sends  a  message  to  the ICW server passing along the calling


<draft-ietf-pint-icw-00.txt>                             November 1998

A Proposal for Internet Call Waiting Service using SIP        [Page 4]


     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
   reside  on their PC; an H.323 client for VoIP and an ICW UAS to drive


<draft-ietf-pint-icw-00.txt>                             November 1998

A Proposal for Internet Call Waiting Service using SIP        [Page 5]


   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"
   (for connecting the call).  


<draft-ietf-pint-icw-00.txt>                             November 1998

A Proposal for Internet Call Waiting Service using SIP        [Page 6]


   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-ietf-pint-icw-00.txt>                             November 1998

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 
   o Denial of telephone service attack is possible 


<draft-ietf-pint-icw-00.txt>                             November 1998

A Proposal for Internet Call Waiting Service using SIP        [Page 8]


   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.
   Naperville, IL 60566 USA


<draft-ietf-pint-icw-00.txt>                             November 1998

A Proposal for Internet Call Waiting Service using SIP        [Page 9]


   
   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, 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-ietf-pint-icw-00.txt>                             November 1998

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.  
   
   Physically, the SCF may be  located  in  either  stand-alone  general


<draft-ietf-pint-icw-00.txt>                             November 1998

A Proposal for Internet Call Waiting Service using SIP        [Page 11]


   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-ietf-pint-icw-00.txt>                             November 1998

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-ietf-pint-icw-00.txt>                    Expires: May 1999