Subject: PSTN Internet Notification (PIN) Framework I-D is available

From: Alec Brusilovsky <[email-masked]>
Date: Tue, 29 Jun 1999 07:56:51 -0400

Please note:

PSTN Internet Notification (PIN) Framework Internet-Draft is available
from the official IETF directory at:

http://search.ietf.org/internet-drafts/draft-brusilovsky-pin-framework-00.txt

Regards,
Alec Brusilovsky
 PSTN Internet Notification (PIN) Framework                 [Page 1]

                                                          A. Brusilovsky
Internet Draft                                            J. Buller
                                                          L. Conroy
                                                          V. Gurbani
                                                          L. Slutsman

Expires: December 1999

                    PSTN Internet Notification (PIN)
                  Architecture, Services and Protocols
                       (A Provisional Framework)

                <draft-brusilovsky-pin-framework-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.  

1. Abstract 
   
   The  purpose  of this Internet Draft is to continue discussion on the
   issues involved in PSTN  Internet  Notification  (PIN),  as  part  of
   interconnecting  IP and Public Switched Telephone Network (PSTN) with
   the intent of converging existing and creating new hybrid PSTN and IP 
   services.   PSTN  initiated   Service   Requests,   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: 
   
   Section 2 briefly describes the PIN concept.  

<draft-brusilovsky-pin-framework-00.txt>                   June 1999

 PSTN Internet Notification (PIN) Framework                 [Page 2]

   Section 3 addresses Pre-PIN services and implementations.  
   
   Section 4 gives comparative analysis of PINT  and  PIN  architecture,
   focusing   on   similarities   and   differences   of  PINT  and  PIN
   architecture.  
   
   Section 5 describes the scope of the proposed project by  introducing
   its   overall   architecture,   identifying   the  interfaces  to  be
   standardized and specifying the terminology definitions.  
   
   Section 6 addresses PIN Protocol profile.  
   
   Sections 7, 8, and 9 respectively  address  security  considerations,
   supply  references, and provide the authors addresses, as required by
   [11, 12].  
   
   Section 10  acknowledges  individuals  providing  assistance  in  the
   creation of this document.  

2. PIN Description 
   
   The  current  PSTN/Internet Interfaces (PINT) WG addresses connection
   arrangements through which  Internet  applications  can  be  used  to
   enrich PSTN (Public Switched Telephone Network) telephony services.   
   
   Some  Interworking  services  require requests for services that come
   from the PSTN/IN. Essentially,  these  requests  will  be  a  "mirror
   image" of PINT requests.   
   
   To  provide  interworking  between  PSTN  and IP networks, it is very
   useful to use notifications of events happening within  the  PSTN  to
   generate  service  requests  that  may  then  be  passed on to the IP
   network for execution.  This next  section  describes  the  kinds  of
   events  within  the  PSTN  which initiate the process that results in
   making IP network service requests.  It is included for  information;
   this  behavior  does  not  have  a  direct impact on any resulting IP
   network  protocol,  giving  only  the  reasons  why  an  IP  protocol
   exchange may be initiated.  
   
2.1 PSTN/IN Events and Procedures 
   
   PSTN/IN  Call  Flows  are  organized around actions or collections of
   actions called Point-In-Call (PIC). Detection Points (DPs), which are 
   associated with the PICs, operate between the PICs, and  can  be  the
   basis  that  can in turn be used to generate service requests for the
   IP network.  
   
   IN furnishes "Network Intelligence" to the PSTN. Similarly, it can be 
   utilized to initiate Service Requests to the IP network.  There is an 

<draft-brusilovsky-pin-framework-00.txt>                   June 1999

 PSTN Internet Notification (PIN) Framework                 [Page 3]

   important difference between the IN and  IP:  while  a  PSTN  switch,
   designed to support IN PICs and DPs, can send messages to IN (this is 
   because  of  the  high  performance  of the dedicated SS7 network and
   associated protocols), it is highly unlikely, for  reasons  of  cost,
   performance and security, that a PSTN switch will be able to exchange 
   messages with the IP network.  It 
 is more realistic to use the SCP as the contact point with IP.  
   
   In certain cases, for example (PSTN to PSTN transport via IP backbone 
   with  MEGACO Call Controller and SIGTRAN transport protocol) the Call
   Controller can talk to the PSTN. For that kind of architecture, it is 
   possible to use call  signaling  messages/events  such  as  Off-hook,
   On-hook directly for the IP interaction.   
   
   As  in  the  PINT milestone services [1], PIN studies atomic actions.
   These may be utilized as explicit services in  their  own  right,  as
   well  as building blocks in the realization of more complex services.
   PINT and PIN complement  each  other,  providing  developers  with  a
   comprehensive  set  of  "LEGO" type building blocks for these complex
   services that can deal not only with IP-initiated  services  in  PSTN
   networks   [1],   but,  also,  with  PSTN-initiated  services  in  IP
   networks.  
   
   Examples of services that that may  be  realized  by  these  building
   blocks are: 
   
      1. Internet Call Waiting (ICW).  
      ICW  is  the  capability to provide incoming call notification and
      completion  options  when  the  Subscriber  is  on  a  dial-up  IP
      connection [8].  
      
      2. Internet Call Management.  
      PSTN   call   notification  and  control  options  (flexible  call
      screening, forwarding, etc.), delivered to an IP client [8].  
      
      3. Internet Conference Management.  
      PSTN Teleconference notification and management from an IP  Client
      [6].  
      
      4. Internet Conference Mediation.  
      Pre-Teleconference   (before   an   actual   connection  is  made)
      management service from an IP client.  
      
      5. Advanced Caller ID Delivery [4].  
      Ordered  incoming  call  notification  to  multiple   Subscriber's
      dial-up IP connections.  
      
      6. Queue Management.  
      Notification  of  the  status  and  events of the call queue, much
      needed for the  IP-based  Automatic  Call  Distribution  and  Call
      Center applications [5].  

<draft-brusilovsky-pin-framework-00.txt>                   June 1999

 PSTN Internet Notification (PIN) Framework                 [Page 4]

      7. Internet Call Routing (ICR).  
      Flexible  routing  and control over a dial up PSTN call from an IP
      host.  
      
      8. Hybrid Network ACD [9] 

   3. Pre-PIN services and implementations.  
   
   3.1 Internet Call Waiting (ICW). Providing incoming call notification 
   and completion options  when  the  Subscriber  is  on  a  dial-up  IP
   connection - Lucent [8].  
   
   Service Description 
   
   When  a call attempt is made to a service Subscriber who is presently
   on a dial up connection, they (the service Subscriber) are  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,  graphically-oriented  way  to  notify  subscribers  while
   connected to  the  Internet,  of  incoming  calls.    It  allows  the
   subscriber to accept or reject the call.   
   
   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 providers can offer the following important benefits to
      subscribers through the use of Internet Call Waiting Service:  
      
        ¸ 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.   

<draft-brusilovsky-pin-framework-00.txt>                   June 1999

 PSTN Internet Notification (PIN) Framework                 [Page 5]

   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  specified
   treatment.  Subscriber treatment options and Calling Party experience 
   are: 
   
      o  Refuse  Call:  Calling  Party hears ringing until Calling Party
      abandons.  
      
      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.  
      
      o Send to Voice Mail/third party  number.    Calling  Party  hears
      voice mail system announcements.  
      
      o Accept Call: Calling Party hears ringing until they connected to 
      the Subscriber.  
      
   3.2 Call Completion Internet Busy (CCIB) - Siemens.  
   
   3.2.1 Service Description 
   
   The  CCIB  service allows subscribers to determine completion actions
   for telephony calls to a number which is currently  in  use  (because
   the  subscriber is logged on to the Internet) using the proposed PINT
   and PIN protocols.  Completion actions could be, for example: 
   
      o Refuse the call.  
      
      o Forward the call to Voice Mail.  
      
      o Forward the call to another number.  
      
      o Drop Internet connection and take the telephony call.  
      
      o Establish VoIP connection on terminating side to take the call.  
      
      o Take details of the callee for later connection.  
      
      o  Take  a  voice  message  which  can  then  be  relayed  to  the
      terminating ends device.  
      
   In  an  implementation  of this service the subscriber would register
   for this service using the PINT protocol each  time  they  wished  to
   receive messages.    This  could  be  each  time  they  log  onto the
   Internet. This registration is stored either within the  Internet  or
   the PSTN/IN domains for later reference by a PIN CCIB service.  
   
   Note   that  this  mechanism  inherently  provides  mobility  as  the

<draft-brusilovsky-pin-framework-00.txt>                   June 1999

 PSTN Internet Notification (PIN) Framework                 [Page 6]

   subscriber may  register  their  location  on  any   number.      The
   registration process could be undertaken either : 
   
      1) With the help of the underlying PINT executive system providing 
      the actual telephony number.  
      
      2) By the register message containing the telephony number.  It is 
      accepted   this   scenario   has   inherently   greater   security
      implications,  which  will  need  to  be   resolved   during   any
      implementation.   
      
   Upon  successful  registration  a  'thin' PIN server is activated, or
   downloaded to and then activated on, the subscriber's machine.  
   
   When a call attempt is made to the  telephony  number  on  which  the
   subscriber  has  registered their current connection to the Internet,
   the PSTN/IN detects this.  
   
   Upon such a call attempt detection the PSTN/IN PIN gateway issues  an
   invitation to the subscriber to take the call.  The 'thin' PIN server 
   on  the  subscribers  machine  receives the invitation and allows the
   subscriber to decide (from the list  of  possible  options  indicated
   above) how  to handle the call.  This choice is relayed in a response
   to the invitation  in  order  that  the  PSTN/IN  can  act  upon  the
   subscriber's choice.  
   
   3.3 Advanced Caller ID Delivery - AT&T [7].  
   
   3.3.1 Service Description 
   The  "Advanced  Internet  Caller-ID  Delivery"  service described, we
   envision being owned by a long-distance carrier provider (LDCP)  such
   as AT&T, to which we refer as the service provider (SP).  
   
   The  subscriber to the service may have one or more Internet accounts
   (at home, at the office, etc.) and one or more telephone  numbers  on
   which they  may  be  reached.    One  telephone  number  (normally  a
   residential number) will  be  designated  as  the  Primary  Telephone
   Number  (PTN).  The PTN must be registered with the SP, and the table
   of alternative telephone numbers  (in  the  order  desired)  will  be
   stored in  the  SCP  database where the PTN is the primary key.  When
   the PTN is  dialed,  the  list  of  provided   telephone  numbers  is
   retrieved from the SCP, and the service performs the following steps: 

      o  Each  provided  telephone  number,  starting  with  the  PTN is
      dialed.  A line is considered to be unavailable if the call is not 
      answered after a specified number of rings.  
      
      o The call will be connected to the first available line.  
      
      o Otherwise, the SCP sends a notification to  the  IP  domain  and

<draft-brusilovsky-pin-framework-00.txt>                   June 1999

 PSTN Internet Notification (PIN) Framework                 [Page 7]

      terminates the incoming call.  
      
      o  Each IP account is analyzed to determine whether the subscriber
      is on-line.  If they are, a  pop-up  window  will  appear  on  the
      screen  with  the  "clickable"  Caller-ID  number;  therefore, the
      subscriber may input a phone number to receive the call  and  then
      click-to-dial the Caller-ID number.  
      
      o  Otherwise,  if the subscriber is not on the Internet, they will
      be sent the email with the Caller-ID and the time of the call.  

   4. Similarities and differences of PIN and PINT architecture.  
   
   Just like in PINT, as described in [1], in which the PINT protocol is 
   a protocol between PINT Client and PINT  Gateway  (server),  the  PIN
   protocol addresses the interface between the PIN Executive System and 
   IP-based PIN Servers.  
   
   Unlike  PINT,  the  PIN Executive System acts as a client, generating
   requests to be sent to the PIN Servers.  
   
   It is useful to consider, in the first instance, how a  PIN  protocol
   would  exist  in relation to the work presently being undertaken with
   the  PSTN/Internet  Interfaces  (PINT)  WG.  The  PINT  WG  addresses
   connection  arrangements  through  which  Internet  applications  can
   request and enrich PSTN (Public Switched Telephone Network) telephony 
   services.  As such the PIN WG aims to perform a similar  function  in
   reverse,  namely;  address  the connection arrangements through which
   the PSTN/IN can request and be enriched by services  executing in the 
   Internet domain.  Figure 1. details this relationship  schematically.
   PINT  deals with requests for a service within the PSTN/IN domain and
   receives responses back from the PSTN/IN  domain.    PIN  deals  with
   requests from the PSTN/IN domain for a service in the Internet domain 
   and receives responses back from the Internet domain.  
   
   5. Proposed Architecture.  
   
   With  the proliferation and wide acceptance of the Internet, and more
   so with the convergence  of  the  Internet  and  PSTN,  there  is  an
   increasing  desire  for  events  occurring  on  the PSTN domain to be
   propagated to the Internet domain.  The PIN protocol attempts to fill 
   this void.  Entities in the Internet domain can  receive  the  events
   generated by the PSTN domain and act appropriately.   
   
   Since  the  PIN  BOF  the  PIN  architecture is often thought of as a
   mirror image of the PINT architecture and, we think,  there  is  some
   truth in  this statement.  The basic motivation for PINT is to invoke
   telephony services from the Internet. To implement this the following 

<draft-brusilovsky-pin-framework-00.txt>                   June 1999

 PSTN Internet Notification (PIN) Framework                 [Page 8]

   chain of events should take place: 
   
      o an IP host sends a request to a server on a boundary  of  an  IP
      network (PINT Gateway); 
      
      o  the  Gateway  relays  the  request to a telephone network, more
      precisely, to a PSTN Intelligence Node(SCP or Service Node) ;  
      
      o triggered by this request, the intelligence  node  executes  the
      service  logic  that controls the PSTN Switches that in turn carry
      out the desired telephony service.  
      
   In the proposed PIN scenario the  PSTN  requests  an  entity  in  the
   Internet   domain  to  carry  out  certain  Internet  based  services
   (normally these services  will  involve  interactions  with  Internet
   hosts and Gateways). The generic scenario is as follows: 
   
      o a PSTN host (switch) triggers the execution of the service logic 
      in  a PSTN Intelligent node (Requesting System) on the boundary of
      PSTN and IP domains; 
      
      o at a certain point of executing the service  program,  the  PSTN
      Intelligence  node  (Requesting  System)  sends  a  request to the
      Internet (using protocol A in Figure 1, which is  outside  of  the
      scope of this WG) PIN Executive System.  
      
      o  triggered  by  this  (PSTN)  request,  the PIN Executive System
      invokes some service logic (q.v.) that instructs  (using  the  PIN
      protocol) the PIN servers to carry out the desired PIN service.  
      
   While  we defer the discussion of PIN "milestone services" for later,
   one point may be made: these  services  do  not  have  to  mimic  the
   telephony primitives like Call Forwarding, Call Waiting, etc.  
   
   The  PIN architecture is depicted in Figure 1. Certain basic call and
   connection events are detected at armed DPs and become visible to the 
   IN service  logic.    The  IN  service  logic  program  in  the  PSTN
   Requesting  System  identifies  the need to request an Internet (PIN)
   service.  
   
   As previously stated.  protocol A in Figure 1 is outside of the scope 
   of this WG. The specifications of protocol A may be better  addressed
   in ITU-T. These requests are sent to the PIN Executive System.  
   
   The  PIN  Executive  System  executes  the  appropriate service logic
   program; the program, acting  as  a  PIN  Client,  communicates  with
   appropriate  PIN  Servers. PIN requests may pass through zero or more
   PIN servers to take advantage of location service,  redirection,  and
   registration capabilities of the PIN protocol.  
   
   The  comparison  of PIN and PINT architectures, depicted in Figure 1,

<draft-brusilovsky-pin-framework-00.txt>                   June 1999

 PSTN Internet Notification (PIN) Framework                 [Page 9]

   demonstrates the similarity and symmetry between  PIN  and  PINT  and
   reveals the data flows 
   
   5.1 Terminology  definitions.    This  section provides more detailed
   definitions of the terminology used in this document.  
   
      Service: 
      A  high  level  behavior  performed  within  either  the  PSTN/IN,
      Internet or  in  conjunction  in  both  domains.    This  behavior
      incorporates, as part of its expression, PINT and/or PIN  protocol
      message  flows,  between  these  domains,  in order to achieve the
      objectives of its function.  
      
      Requesting Entity/Requestor: 
      The entity (either a user or the equipment and programs  that  act
      as  their  agent)  that  constructs and sends a message requesting
      some action on the part of the recipient.  In the context of  PIN,
      the Requesting Entity is usually a component within the PSTN/I.N., 
      and the recipient will be an Executive System (q.v.) within the IP 
      network.  
      
      Executive System: 
      The entity that performs actions.  In the PIN context, this entity 
      will  exist  within the IP network, and will execute these actions
      in response to requests it receives  from  an  entity  within  the
      PSTN/I.N.  
      
      Requesting System: 
      The  entity that performs actions on behalf of PSTN/IN. In the PIN
      context, this entity will exist within the  PSTN/IN  network,  and
      will  execute  these  actions  in response to requests it receives
      from the PSTN/I.N.  
      
      Invocation/Request: 
      The procedure by which a Requesting Entity can ask for  an  action
      to be executed by another (Internet Intelligence Node) entity.  In 
      the  case  of  PIN, the Request will be initiated from a PSTN/I.N.
      entity, and the resulting action will be executed by an IP network 
      entity.  
      
      Reply/Response: 
      The procedure by which an entity that has received a prior request 
      for action can return information on the status of  that  request,
      or the  disposition  of the requested action.  In the case of PIN,
      the Response will be generated by the IP Network-based PIN Gateway 
      that received a request, and will be returned  to  the  Requesting
      Entity within the PSTN/I.N.  
      
      Service Subscription: 
      The  procedure  by which a Requesting Entity can request (and gain
      approval  for)  the  right  to  send  subsequent  Invocations   of

<draft-brusilovsky-pin-framework-00.txt>                   June 1999

 PSTN Internet Notification (PIN) Framework                 [Page 10]

      particular actions.    Note  that  this procedure may be implicit;
      there may not be a need for prior subscription for some  requests,
      whilst  for others there may be a required "pre-service" procedure
      (such as setting up accounts and security relationships).  
      
      Service Unsubscription: 
      The procedure by which a Requesting Entity can  request  that  any
      long   term   relationship  entered  into  by  means  of  a  prior
      subscription be dissolved.  
      
      There can be many reasons for taking this  step;  for  example,  a
      recurring   charge   might   be   applied  for  the  period  of  a
      subscription, or it may be that a subscriber is not going to be in 
      a  position  to  make  requests  (such  as  no  longer  having  an
      appropriate terminal).  
      
      Note  that  there  can  be  circumstances in which the entity with
      which the subscription has been  made  is  no  longer  willing  to
      maintain the relationship with the subscriber (for example, on non 
      payment, or usage breaches).  As such, the "subscribee" may inform 
      the subscriber  that  their  relationship  has been dissolved.  In
      other words, subscription requests are said to be idimportant.  
      
      Service Activation/Enabling: 
      The  procedure  by  which  a  Requesting  Entity  can  inform  the
      recipient  that  it  is  now  willing  to  engage  in transactions
      associated  with  a  long  term  relationship  to  which  it   has
      previously subscribed.  
      
      Service Deactivation/Disabling: 
      The  procedure  by  which  an  Requesting  Entity  can  inform the
      recipient  that  it  is  temporarily  unwilling   to   engage   in
      transactions  associated  with  a  relationship  to  which  it has
      previously subscribed.  
      
      Registration of Interest (in an event or entity status or  service
      status or disposition): 
      The  procedure by which a Requesting Entity can ask to be informed
      of events that occur in  the  domain  of  the  recipient  of  this
      request.   The events of interest can be classified in a number of
      ways.  They may constitute changes of status of an Invoked Action, 
      or in its disposition on completion, or  in  the  status  of  some
      entity  with  which  an  Invocation association is not directly in
      place (e.g. the appearance of a user on the IP network,  or  their
      availability).  
      This procedure can be considered to open a monitoring relationship 
      between  the  requesting  entity  and  the  entity  receiving  the
      request.  Where the events of interest involve other  entities  in
      addition  to  the  receiving  entity,  then  this  will act as the
      representative; any procedure needed for it to  glean  information
      on the events of interest is hidden.  

<draft-brusilovsky-pin-framework-00.txt>                   June 1999

 PSTN Internet Notification (PIN) Framework                 [Page 11]

      Notification/Indication: 
      The  procedure  by  which  an  entity  that  has  received a prior
      registration of interest can inform the requesting entity  of  the
      events for which it has asked to be notified.  
      
   6. PIN Protocol profile 
   
   At  this  early  stage  it  is  felt  that  there  is  some  merit in
   abstraction away from explicit message  flows  (and  their  potential
   contents) to  be  used  in  the  provision  of  services.    We shall
   initially identify the atomic  actions  between  each  domain,  which
   could  be required to provide a basis for the production of practical
   services.  
   
   There are five such generic actions, which could exist  in  order  to
   provide the proposed services.  These are : 
   
      1) Initiation actions.  
      A  request  is  sent  from  one  domain to the other to initiate a
      service in that domain.  In the case of PIN this request  is  sent
      from the PSTN/IN domain to Internet domain.  A response message is 
      returned  to  indicate the status or disposition of this requested
      action.  
      
      2) Data set action.  
      A message is sent from one domain  to  the  other  which  contains
      information, which should be stored in the other domain.  
      
      3) Data request action.  
      A  message  is  sent  which requests information held in the other
      domain.  This data is returned in the response message.  
      
      4) Subscription to/or Registration of interest action.  
      A message is sent from one domain to another to  request  that  an
      entity  in  the  subscribing  domain  (PSTN/IN in the PIN case) be
      informed in the event of some  future  change  in  state  of  some
      entity in the other domain (Internet in the PIN case).  
      
      5) Notification action.  
      A  notification  message is sent from the domain where a change in
      state of some entity has occurred, to  the  entity  in  the  other
      domain,    which    has    expressed    an    interest    (via   a
      subscription/registration mechanism) in these events.  Note that a 
      Notification is only sent  within  the  context  of  a  monitoring
      relationship  that  has been opened by prior EXPLICIT registration
      of interest; there should therefore exist  NO  possibility  of  an
      'unsolicited' notification message being sent.  

   Some  readers  may consider the actions described above to themselves

<draft-brusilovsky-pin-framework-00.txt>                   June 1999

 PSTN Internet Notification (PIN) Framework                 [Page 12]

   be 'services'. In the interests of  clarity  the  term  'service'  is
   defined as in the terminology section.  

   7. Security Considerations 
   PIN Security Requirements are much more stringent than those in PINT. 
   The reason for this is twofold: 
   
      o  A  subscriber  has  to  prove  their  "ownership" of a specific
      telephone line.    This  is   important   for   privacy   reasons.
      Unauthorized  entities should know as little as possible about the
      activities on the subscriber's line.  
      
      o The subscriber has to prove some ownership of their IP addresses 
      (this is complicated because of the transient  nature  of  the  IP
      address,  especially  for  dialup  clients, while PIN requests may
      persist).  Two questions should be asked: when a PIN server should 
      stop sending messages to a  particular,  and  possibly  stale,  IP
      address?;  should  the  PIN  messages  be encrypted to protect the
      privacy of the client from the next 'owner' of the IP address?  
      
   On the other hand there are PIN services  that  may  have  a  similar
   security  model to PINT. For such services the requirements stated in
   [1] should apply.  
   
      o Peer entity authentication to allow a  communicating  entity  to
      prove its identity to another in the network.  
      
      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 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  PIN  Client  profile  verification to verify if the end user is
      authorized 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 PIN-specific security considerations: 
      
      o  Cracking  is  a threat to any Service Provider (PSTN, Intranet,
      Internet). It is real danger - phone companies are common targets 
      
      o Notification spoofing is one of the threats 

<draft-brusilovsky-pin-framework-00.txt>                   June 1999

 PSTN Internet Notification (PIN) Framework                 [Page 13]

      o Existing mechanisms applied to the Internet can be implemented 
      
      o Stealing a Notification is a new type of security threat 
      
8. References 
   
        [1] S. Petrack  &  L.  Conroy,  "  The  PINT  Service  Protocol:
        Extensions  to  SIP  and  SDP  for  IP  Access to Telephone Call
        Services" Internet Draft, Internet Engineering Task Force,  June
        1999.  
        
        [2]  M.  Handley,  E.  Schooler, H. Schulzrinne, & J. Rosenberg,
        "SIP:   Session   Initiation   Protocol",   RFC2543,    Internet
        Engineering Task Force, March 1999.  
        
        [3]  H.  Lu et al, "Inter-Networking--Pre-PINT Implementations",
        Informational RFC2458,  Internet  Engineering  Task  Force,  Nov
        1998.  
        
        [4]  L.  Slutsman, "Advance Internet Caller-ID Delivery Service"
        Internet Draft, Internet Engineering Task Force, March 1999.  
        
        [5] L. Slutsman, "On Call Queuing in PINT" PINT WG presentation, 
        December 7-11, 1998 
        
        [6] L. Slutsman, "Conference Call Services  for  PINT"  Internet
        Draft, Internet Engineering Task Force, April, 1999 
        
        [7]  A.  Brusilovsky,  V. Gurbani, A. Jain, D. Varney, "Need for
        PSTN Internet Notification (PIN) Services. A Proposal for a  new
        Working  Group"  Internet Draft, Internet Engineering Task Force,
        February 1999.  
        
        [8] A.  Brusilovsky,  E.  Gausmann,  V.  Gurbani,  A.  Jain,  "A
        Proposal  for  Internet  Call  Waiting  Service  using  SIP.  An
        Implementation Report."    Internet  Draft, Internet  Engineering
        Task Force, January 1999.  
        
        [9]  C.  Gao,  A.  Brusilovsky, J. Swinger, "Hybrid Network ACD"
        Intelligent Network Forum, IN/IP Working Group, London, May 1999 
        
        10] J.Rosenberg, H.Schulzrinne, "SIP For  Presence",    Internet
        Draft, Internet Engineering Task Force, March, 1999 
        
        [11] S.Bradner, "The Internet Standards Process", RFC2026 
        
        [12] J. Postel, "Instruction to RFC Authors", RFC 2223 
        
        [13]  S.  Petrack,    "IP Access to PSTN Services: Basic Service
        Requirements,  Definitions,   and   Architecture",      Internet
        Draft, Internet Engineering Task Force 

<draft-brusilovsky-pin-framework-00.txt>                   June 1999

 PSTN Internet Notification (PIN) Framework                 [Page 14]

9. Authors' Addresses 
   
   Alec Brusilovsky                                
   E-mail: [email-masked]
   Telephone: +1-630-713-8401              
   Fax: +1-630-713-5840                  
   Lucent Technologies
   263 Shuman Blvd.
   Naperville, IL 60566 USA

   Jim Buller
   E-mail:    [email-masked]
   Telephone: +44 (0)1794833666         
   Fax:       +44 (0)1794833434  
   Siemens Roke Manor Research Ltd.,
   Roke Manor,
   Old Salisbury Lane
   Romsey, Hampshire
   U.K.    SO51 0ZN

   Lawrence Conroy
   E-mail: [email-masked]
   Telephone: +44 (1794) 833666
   Fax: +44 (1794) 833434
   Siemens Roke Manor Research
   Roke Manor
   Old Salisbury Lane
   Romsey, Hampshire
   U.K.    SO51 0ZN

   Vijay Gurbani                   
   E-mail: [email-masked]  
   Telephone: +1-630-224-0216              
   Fax: +1-630-713-5840                  
   Lucent Technologies
   263 Shuman Blvd.
   Naperville, IL 60566 USA

   Lev Slutsman
   E-mail: [email-masked]
   Telephone: 732-420-3756
   Fax:
   AT&T Labs 
   Room D5-3D26 

<draft-brusilovsky-pin-framework-00.txt>                   June 1999

 PSTN Internet Notification (PIN) Framework                 [Page 15]

   200 Laurel Avenue S, 
   Middletown, NJ, USA 07748  

   
Glossary
   
   ACD                  Automatic Call Distribution
   ACID                 Advanced Caller Identification Delivery
   CCIB                 Call Completion Internet Busy
   DN                   Destination Number
   DP                   Detection Point
   ICR                  Internet Call Routing
   ICW                  Internet Call Waiting
   IN                   Intelligent Network
   LDCP                 Long Distance Carrier Provider
   MGCP                 Media Gateway Control Protocol
   NPL                  Notification Processing Language
   PIC                  Point-In-Call
   PTN                  Principal Telephone Number
   PSTN                 Public Switched Telephone Network
   SCP                  Service Control Point
   SN                   Service Node
   SP                   Service Provider
   VoIP                 Voice over IP (Internet Protocol)

10. Acknowledgments
   
   The  authors  would like to acknowledge Igor Faynberg, Hui-Lan Lu and
   Jonathan Rosenberg for their contributions to the  creation  of  this
   document.  
   Our  special  thanks to Steve Bellovin (AT&T), Corrado Moiso (CSELT),
   Lyndon Ong (Nortel) and Henry Sinnreich (MCI)  for  their  insightful
   comments and help with this Internet Draft.  

<draft-brusilovsky-pin-framework-00.txt>                   June 1999

 PSTN Internet Notification (PIN) Framework                 [Page 16]

Figures: 

                       /\/\/\/\/\/\/\          /\/\/\/\/\/\/\/\/\/\
___________            \          __/___    ___\_______           \
|  PINT   |    PINT    \   PINT  | PINT |   |  Exec   | Telephone /
| client  |<---------->|  server |gatewy|===| System  | Network   \
|_________|  protocol  /  cloud  |______|   |_________|  Cloud    /
                       \            \          /                  \
                       /\/\/\/\/\/\/\          \/\/\/\/\/\/\/\/\/\/

                       /\/\/\/\/\/\/\           /\/\/\/\/\/\/\/\/\/\
___________            \          __/___    ____\_______           \
|  PIN    |    PIN     \   PIN   |Exec  |   |Requesting| Telephone /
| server  |<---------->| gateway |System|=A=|  System  | Network   \
|_________|  protocol  /  cloud  |______|   |__________|  Cloud    /
                       \            \          /                   \
                       /\/\/\/\/\/\/\          \/\/\/\/\/\/\/\/\/\/\

            /-----------------------------------<
           <  Direction of the PIN Service Flow <
            \-----------------------------------<
Figure 1

<draft-brusilovsky-pin-framework-00.txt>                   June 1999