[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Nits]
Versions: 00                                                            
PINT Working Group                                             J. Buller
INTERNET-DRAFT                          Siemens Roke Manor Research Ltd.
Category: Informational
Expires: 22nd September 1999

                  A proposal for the provisioning of PSTN
                 initiated services running on the Internet


   Status of this Memo

   This  is an Internet-Draft  and is  in full conformance with all  the
   provisions of section 10 of RFC2026.

   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.

   Copyright Notice

   Copyright (c) The Internet Society (1999). All rights reserved.


   This  Internet Draft has arisen  out of  work  concentrating  on  the
   interconnection  of IP  and the  Public  Switched  Telephone  Network
   (PSTN) undertaken within the PINT working group.  Efforts within this
   group have,  to date, concentrated on the initiation of PSTN services
   from the Internet.

   This Internet Draft aims  to describe a possible architecture for the
   implementation of services initiated from  the PSTN such as,  but not
   limited  to,  Internet Call Waiting  (ICW).  It also  identifies  the
   possibility  of using this class of service,  in conjunction with the
   PINT work already undertaken,  in order to provide a third flavour of

Buller                                                          [Page 1]

<draft-ietf-pint-saint-00.txt>   PSTN Initiated Services     March, 1999

   This Internet Draft deliberately does not to define the protocols for
   these kinds of services, although descriptions contained within it do
   use Session Initiation Protocol (SIP) terminology.

   The purpose  of this  Internet Draft  is to  ascertain  the level  of
   interest in pursuing this area of work. It is submitted with the goal
   of forming the basis of an Informational RFC and thereby further work
   on the standardisation of the  provision of  these kinds of services.


   The contents of the rest of this document is as follows:

   Section 2
   Acts as an introduction and defines the scope of this Internet  Draft
   in relation to PINT.

   Section 3
   Specifies the perceived requirements  for any  implementation of  the
   group of services identified in Section 2.

   Section 4
   Identifies  an initial  architecture to  fulfill requirements of  the
   class of service identified in this Internet Draft.

   Section 5
   Describes an  implementation of an  example service (ICW)  using this

   Section 6
   Discusses initially  identified security considerations  which relate
   to the kind of service discussed in this Internet Draft.

   Section 7
   Conclusions and identified further future study areas.

   Section 8
   References and Glossary.

   Section 9
   Acknowledges individuals providing assistance in the creation of this

   Section 10
   Author's address.

2. Introduction

   In its charter, the description of the PINT working group states that
   it  aims to address  connection arrangements  through which  Internet
   applications can request and enrich PSTN services.

   Work to date has produced a  proposal based on the use of the Session

Buller                                                          [Page 2]

<draft-ietf-pint-saint-00.txt>   PSTN Initiated Services     March, 1999

   Initiation Protocol (SIP) [2] and  Session Description Protocol (SDP)
   [3] to achieve these objectives in respect  of Internet initiation of
   PSTN services (as shown in Figure 1).

                     : PINT area of interest    :
                     :                          :
                     :                PINT      :
                     : +----------+   REQUEST   :+----------+
                     : | Internet |------------>:|   PSTN   |
                     : +----------+             :| Services |
                     :                          :+----------+

                              Figure 1.

   As a result  of this work  the group has  identified a need,  and has
   begun  discussions  on,  the  possibility of using  SIP and  SDP in a
   similar  manner in order to perform the reverse of this function i.e.
   initiating  Internet  services from  the PSTN  using some  yet to  be
   defined protocol (initially called TNIP, it being the reverse of PINT
   [4]) as shown in Figure 2.

                     :                          :
                     : +----------+   REQUEST   :+----------+
                     : | Internet |<------------:|   PSTN   |
                     : +----------+    TNIP     :| Services |
                     :                          :+----------+

                              Figure 2.

   The service  initially identified  for this scenario is the  Internet
   Call Waiting (ICW) Service,  also known  as Call  Completion Internet
   Busy (CCIB).  In this service,  a PSTN user attempts  to make a Plain
   Old Telephone Service (POTS)  call in a traditional manner to another
   number. This second number is engaged, possibly because the person is
   presently  connected to the Internet.  The service should identify if
   this user is indeed connected, and if so,  a message is sent over the
   Internet to  inform this person about the call attempt.  The user may
   then decide  what action to take, dependent on  what  service options
   are  provided  by the service  provider.  This might  be to  drop the
   current Internet connection and take the call in the normal way, take
   the call as a Voice Over IP (VOIP) call, decline and give the calling
   party the option to leave a voice message or simply decline the call.

   Of course this is not the only service which could be deployed, other
   services, such as :

      o Remote Activation
        Using a  telephone a user could request actions  to be performed
        at some remote location.

Buller                                                          [Page 3]

<draft-ietf-pint-saint-00.txt>   PSTN Initiated Services     March, 1999

      o Remote Data Setting
        Using a telephone a user could create or modify information held
        on a remote machine.

      o Paging
        A paging service could send a text message to the user logged on
        to the Internet using voice to text conversion software.

      o Voice Messaging
        A voice message service, whereby a voice message could  be taken
        and  converted to an audio  format which could be played  on the
        users machine.

      o Voice to Email.

   could also be deployed.

   However, the real benefits of this class of service (PSTN activation)
   will be in its use,  in conjunction with the work  already undertaken
   within the PINT group,  to provide a further completely  new class of
   Intelligent Network  (IN) 'like' services.  This scenario is depicted
   in Figure 3 :
                     :                          :
                     : +----------+   REQUEST   :+----------+
                     : |          |<------------:|          |
                     : | Internet |             :|   PSTN   |
                     : | services |             :| Services |
                     : |          |------------>:|          |
                     : +----------+   PINT      :+----------+
                     :                REQUEST   :

                              Figure 3.

   The scenario of these kinds of services would be that a user uses the
   PSTN  to initiate an  Internet service.  This Internet service  could
   then either :

       Store information which  could be used  during an initation of an
       Internet Service at a some later time.
       Initiate a PSTN service directly.

   A simple  example of a service using both of these facets might  be a
   number portability service. A user  could use a telephone to  specify
   the telephone number at their current location (perhaps using Calling
   Line Identity CLI) this is sent over the Internet (using the protocol
   which would  come out of any  future work)  to a repository.  Another
   user could then attempt to telephone the  first  user.  This  call is
   intercepted and the number called checked  against the  current known
   location by a request (using the protocol or profile which would come
   out of any  future work)  to ascertain the  number registered  by the
   first user.  If the  number is  different,  a PINT  request  could be

Buller                                                          [Page 4]

<draft-ietf-pint-saint-00.txt>   PSTN Initiated Services     March, 1999

   issued back to the PSTN to connect the call to the new number.

   For the purposes of this Internet Draft and  identifying what kind of
   services  are being  disussed  this  Internet Draft identifies  three
   groups of service which could be provided :

     1. PINT    Internet initiation of PSTN servives.

     2. TNIP    The  reverse of PINT  i.e.  PSTN  Initiation of Internet
                services and the protocol or profile which could provide
                these services.

     3. SAINT   Service Activation and the INTernet. An all encompassing
                classification which  contains services provided  by the
                previous  two groups,  plus  any  combination  of  these
                services, used to provide further services.

   Figure 4. provides a schematic of the different kinds of service.

                   Service Activation on the INTernet
                  |                                 |
                 PINT                              TNIP
             PSTN INTernet                  Telephony iNitiation
             Interworking                     of IP services

                              Figure 4.

   So,  in the number  portability serice  described above,  the service
   components would break down as follows :

     o The  ability to call and set current  location (telephone number)
       would be a TNIP  flavour of SAINT which could be used in multiple

     o Similarly, the ability to look up the present location would also
       be a TNIP flavour of SAINT, as this would have been initiated via
       the PSTN. This also could be used in multiple services.

     o The ability to forward the  call would be a PINT flavour of SAINT
       because  this would  be initiated from  the Internet. Again, this
       functionality could be used in multiple services.

     o The whole combination of the above would be a SAINT service.

   Eventually,  if further  work  in  this area  is undertaken,  what is
   presently  considered to be independent services within the  PINT and
   TNIP class of service,  might be seen  more as functional  components
   within a SAINT architecture of service provision.

   This Internet Draft will not consider the potential for PINT and TNIP
   combination  kinds  of  SAINT  services  further.  The mechanism  for

Buller                                                          [Page 5]

<draft-ietf-pint-saint-00.txt>   PSTN Initiated Services     March, 1999

   providing  these  should 'fall  out'  of any work  undertaken  in the
   standardisation of PSTN initiated or TNIP services.

3. General Requirements For PSTN Initiation Of Internet Services

   This section  aims to specify an  initial set of requirements for any
   future work in the specification of a protocol, or implementation of,
   the group of PSTN initiated services identified in Section 2.

     o The profile should provide the service in a secure manner.

     o Any profile defined for PSTN initiation  of services should reuse
       where possible  existing IETF protocols. In particular, a profile
       for the PSTN  initiation of  services should be aligned with  the
       PINT profile work undertaken to date.

     o The  identification of  any equipment (external to the  Internet)
       within the  specification  of the protocol,  or, service  defined
       using  this protocol  SHOULD NOT  be required. This  would  be in
       accordance  with  the  PINT  approach to  date  which  places  no
       requirements and identifies no specific equipment beyond the PINT

     o Provide the possibility for a service to be activated in a manner
       which  is  independent in  both  location  of  service and  user.
       Section 5 describes  one possible ICW implementation which allows
       a user to use the ICW  service in a portable manner  without that
       service being  tied to a  specific telephone  number (and thereby
       service location).  User (the caller) location  can be considered
       to be location independent for this service.

4. Proposed Architecture

   The proposed architecture contains three main elements :

     1) The user's machine.
        This contains  a TNIP  Server to  receive INVITE  and/ or NOTIFY
        messages.  What action occurs  next can be either  predetermined
        by the service provider or dictated by the user themselves.

     2) Information/ Service Repository.
        This  could  contain  the  service provider's services,  service
        related  information,  subscriber related information  or indeed
        accounting information. In Figure 5 this element is indicated as
        a single entity,  where in fact, it may be comprised of  several
        servers working together to provide the overall service.

        These  functions  receive INVITEs  from the  TNIP client,  check
        where  to  send  the  message  and  perform  any  other  service
        functionality.  Next, the INVITE is forwarded to the TNIP server
        on the user's machine. These functions also receive REGISTRATION
        messages sent  from the TNIP  Server on  the user's  machine and
        maintain/store  any  relevent  information  contained  in  these

Buller                                                          [Page 6]

<draft-ietf-pint-saint-00.txt>   PSTN Initiated Services     March, 1999

     3) TNIP Gateway.
        This  'could'  receive  service   requests  from  the  PSTN  and
        formulates TNIP messages  to be  forwarded to  the  Information/
        Service Repository  or directly to the TNIP Server  on the users
        machine. In so doing it acts as a TNIP client.

   A simplistic schematic of these  elements is shown in Figure 5 below.

           : Scope of interest                                 :
           :                                                   :
           : +------------------+                              :
           : | Users Machine    |                              :
           : |                  |                              :
           : | +--------------+ |                              :
           : | | TNIP Client/ | |                              :
           : | | Server       | |                              :
           : | +--------------+ |                              :
           : +--------:---------+                              :
           :          |                   +------------------+ :
           :          :                   | Information/     | :
           :          |                   | Service          | :
           :          :                   | Repository       | :
           :          |                   | +--------------+ | :
           :          :-..-..-..-..-..-..-..| TNIP Server  | | :
           :          |                   | +--------------+ | :
           :          :                   |                  | :
           :          |                   +------------------+ :
           :          :                                        :
           :          |                                        :
           :   +--------------+                                :
           :   |   TNIP       |        -..-..- TNIP Protocol   :
           :...|   Gateway    |................................:
               |              |
               |     PSTN     |

                              Figure 5.

   One  thing to note about this  architecture is that the  Information/
   Service Repository is not necessarily required.  A User machine could
   handle  a service itself if the TNIP client were to issue INVITEs and
   NOTIFYs to it directly.

   The function of the information/service repository itself could exist
   outside of  the scope of interest demarcation indicated,  as proposed
   in [5].

   Maintaining  the information/ service repository  within the Internet

Buller                                                          [Page 7]

<draft-ietf-pint-saint-00.txt>   PSTN Initiated Services     March, 1999

   as  indicated however,  would permit  interoperability  with the work
   presently  being undertaken  within the IP Telephony  (IPTEL) working
   group, specifically the proposed Call Processing Language [6].

   Another point of  note is that the TNIP boxes on the user machine and
   connected to  the Gateway Function  are indicated  as Client/ Server.
   This is because the description of the implementation falls  into two
   parts  (see Section 5) and the  behaviour of these TNIP boxes is more
   client or server like in each phase.

5. Implementation Scenarios

   This section describes  how services might be implemented  within the
   architecture described in the previous section. The order of flows is
   identified  though the specific  contents is not.  As has been stated
   previously, this  draft  aims to  ascertain the level of interest  in
   this architecture and  the services it  could provide,  prior to work
   on any  actual specification of a protocol  which will be required to
   support them.

   To reduce complexity the description is in two parts.  First the user
   registers for the service. Secondly, a call attempt is made.

5.1. Service Registration Phase

                         User Machine
                        | TNIP Client |
                            |     ^
                            |     |
                            |     |
                          1 |   3 |
                            |     |                 +--------------+
                            |     |                 | Information  |
                            v     |                 | Service      | 2
                           .........                | Repository   |
                       .../         \...            |              |
                    ../                 \..     1   |  +--------+  |
                   /                       \---------->| TNIP   |  |
                  |         Internet        |       |  | Server |  |
                   \..                   ../<----------|        |  |
                      \...           .../       3   |  +--------+  |
                          \........./               +--------------+

                            Figure 6.

    1. User submits a Registration message containing IP Address and any
       other  information,  such  as in  the case of ICW (if CLI  is not
       available), their telephone number.

    2. User details provided are registered.

Buller                                                          [Page 8]

<draft-ietf-pint-saint-00.txt>   PSTN Initiated Services     March, 1999

    3. Response message  constructed and returned to registering Client.

5.1.1 Other issues

  As previously stated messages 1 and 3, and the function performed by 2
  do not  need to be located in what  is called in this  description the
  Information/ Service repository. These flows and the  registration may
  be undertaken within the telephony network using IN [5].

  The implemenation  scenario described assumes that TNIP  functionality
  has at some  previous time been downloaded to the user's machine. This
  need  not be  the case.  If it were  required  that a user  could gain
  access to  the Internet using  any machine  and still  have access  to
  these services, an implementation similar to that identified in Figure
  7. and the following paragraph could be employed.

                              User Machine
                             || Thin TNIP ||
                             ||  Server   ||
                                 |     |
                               1 |   6 |
                                 |     |
                                 v     |
                          ...../         \.....
                    ...../                     \.....
                   /                                 \
                  |             Internet              |
                   \.....                       ...../
                  |    ^ \.....           ...../     ^
                  |    |       \........./      |    |
                  |    |         ^    |         |    |
                1 |  6 |       2 |  4 |       2 |  4 |
                  v    |         |    v         v    |
                +--------+  5  +--------+     +--------+
                |        |<----|        |     |        |
                |  Web   |     |  TNIP  |     |  TNIP  |
                | Server |  1  | Client |     | Server |
                |        |---->|        |     |        |
                +--------+     +--------+     +--------+
                                                3 |
                                             | Database |

                              Figure 7.

Buller                                                          [Page 9]

<draft-ietf-pint-saint-00.txt>   PSTN Initiated Services     March, 1999

    1. The user  goes to a  service  providers  URL using a  browser and
       specifies the information requested such as, in the case  of ICW,
       telephone number.

    2. The  service provider  constructs and issues  a SIP  registration
       message on behalf of the user.

    3. User details provided are registered.

    4. A response  message is  constructed  and returned to  registering

    5. Response message returned to service provider's Web Server.

    6. A 'thin' TNIP User Server Agent is sent to the user machine. This
       can then be used in the service activation phase.

       The term 'thin' means that a full implementation of a TNIP server
       need not be required in order to handle  specific requests.  This
       is because  of two  main reasons.  Firstly,  the exact  format of
       messages which may be sent by the service provider to offer  this
       service  is known. Secondly,  only a subset of  the full protocol
       need be required to provide the service.

5.2. Service Activation Phase

                         User Machine
                        | TNIP Server | 5
                        4a ^     6 |                +--------------+
                           |       v                | Information  |
                           .........                | Service      | 3
                       .../         \...            | Repository   |
                    ../                 \..     2   |  +--------+  |
                   /                       \---------->| TNIP   |  |
                  |         Internet        |       |  | Server |  |
                   \..                   ../<----------|        |  |
                      \...           .../     4a/4b |  +--------+  |
                          \........./               +--------------+
                           ^       |
                         2 |       v 4b/ 6
                          | TNIP    |
                          | Gateway |
                             1 |
                          | PSTN    |

                              Figure 8.

Buller                                                         [Page 10]

<draft-ietf-pint-saint-00.txt>   PSTN Initiated Services     March, 1999

    1.  A service activation request. For example an ICW service request
        is  made  after a  call  has been  attempted and  the  PSTN  has
        recognised  that the number  is engaged.   An announcement could
        be played  and a request sent from the  Gateway to  establish if
        the  user is currently registered as wanting to receive  INVITEs
        for a particular service.  This will not be discussed further as
        it is outside the scope of this Internet Draft.

    2.  A TNIP  invitation message  is constructed and  sent to the TNIP
        Server on the information/ service handler.

    3.  The TNIP  server in the information/ service repository looks up
        the registration details of the user. Two things may then occur.
        If the user  has registered  details a  TNIP invitation could be
        forwarded to the  TNIP server on the user's machine (see 4a). In
        this  case  the information/ service  repository  performs  as a
        redirection  server or proxy.  If the  user has no  registration
        information in  the  database  (either  because  they  have  not
        registered or the  registration has expired)  a failure response
        is sent to the requesting TNIP client (see 4b).

    4a. A TNIP  invitation message  is sent  by the  TNIP Server  on the
        information/ service  repository.  This  invitation  contains  a
        combination of  information contained within the  repository and
        information contained in the original request.

    4b. A TNIP  failure  response  is returned  to the  requesting  TNIP
        client as no current regration information could be found.

    5.  User  or  service action  to  dictate  what should  happen  as a
        result of the receipt the TNIP request.  In ICW this might be to
        provide the user with the following options :

            Take telephony call
            Take VOIP call
            Send to voice mail
            Refuse connection

    6.  The user sends a response to the INVITE,  a final timeout occurs
        or the client gives up.

5.2.1 Other issues

   As with  the Service  Registration Phase  the flows  to and  from the
   information/ service repository  and the actions it performs could be
   undertaken within the telephony network using IN [5].  The only flows
   in this  scenario would be the invite 4a and the response 6.

6. Security Considerations

   Security  issues are  still an  open issue  within the PINT  Internet
   Draft itself.  It is expected that much of the  security arrangements
   finally proposed by the PINT Internet Draft will be replicated within

Buller                                                         [Page 11]

<draft-ietf-pint-saint-00.txt>   PSTN Initiated Services     March, 1999

   any  further work  undertaken to provide the  services identified  in
   this Internet Draft.

   However,  due to the nature of implementation of these services there
   are a number of security issues that need to be addressed. These are:

     o De-registration.

     o Claiming another number (somebody else's) by accident or design.

6.1. De-registration
   The de-registration problem would arise if a user did not de-register
   themselves before  they finished  using the Internet,  likely to be a
   common  occurrence e.g.  users turning  off their  machines or modems
   without de-registering. It is expected that any implementation builds
   in a mechanism to handle this scenario.  Authenticators could be used
   and passed in  responses to the  REGISTER  messages sent  to the TNIP
   service  on the  users machine.  Alternatively,  these authenticators
   could be  placed directly  in the TNIP  server when  it is  initially

   When the user  logs off the  Internet, without de-registering,  there
   are  three scenarios which could  happen when  an attempt is made  to
   place a call to the number the user specified as their location :

     1) The line  is not busy,  therefore place the call and  remove any
        previously held registrations.

     2) The line  is busy on a voice call.  An attempt to send a  INVITE
        message from the Information/ Service Repository fails (as there
        would be no receiving client).  Any previously held registration
        for this number is removed.

     3) Another user (or the same user on a different  Internet session)
        has registered  for receipt of  calls on this number.  There are
        two solution possibilities :

          a) When  the  new  registration is  made the  old  is replaced


          b) The new  registration is kept until an  Authenticator fails
             on  the  TNIP server  of the  new  registrand  when a  call
             attempt is made.  When  the Authenticator  fails the INVITE
             fails and  the  original  registration can  be removed  and
             replaced with the new. The INVITE is then resent to the new

6.2. Claiming another number by accident or design.

   In this scenario  a user may attempt to use ICW to claim notification
   on a line they have no right to,  and possibly handle that call using
   VoIP,  if the actual line is engaged. Consider the potential criminal

Buller                                                         [Page 12]

<draft-ietf-pint-saint-00.txt>   PSTN Initiated Services     March, 1999

   activities of claiming the telephone number of a Bank.  This security
   issue is  much more complex.  The following options are  suggested as
   possible solutions :

     1) Only allow this kind of access from the user's own phone.

     2) Provide functionality at the ISP to get the  CLI and implement a
        SIP based mechanism to request this from the ISP.

     3) Good accounting to track down offenders.

     4) Only provide  the option  to drop  the Internet  connection  and
        establish  a POTS  call on  untrusted (e.g.  not home)  numbers.
        Normal Bank authentication procedeures could then be used.

7. Conclusions

   There is a perceived requirement for the provision of services which,
   whilst  running over the Internet, would be initiated from the  PSTN.
   This Internet  Draft has proposed  an initial attempt at  defining an
   architecture for the provision of such services.

   This Internet Draft  has also identified  that these services  may be
   used in conjunction with PINT services in order to provide a new kind
   of IN 'like' services with their logic operating within  the Internet

   It has also been  identified that  the architecture  outlined in this
   Internet  Draft permits service users to specify data which can  then
   be used by  services during execution. An extension to this approach,
   and a  possible area of further work would be to  investigate how the
   ability of users to define their services as proposed in [6] could be
   integrated with the initiation of a service from the PSTN.

   Much further work would be required in defining a TNIP style protocol
   or profile and  identifying  possible services  for this  protocol or
   profile. Identfying and specifying  candidate services which use both
   the  TNIP  and  PINT  protocols,  such  as  the  portability  service
   described earlier, would also require further work.

   Finally,  neither PINT nor this proposal  for a TNIP protocol address
   the issue  of generalised/spontaneous notifications  between the PSTN
   and IP domains.  These notifications may be  in the form service data
   or status information. Further work is required to identify how these
   notifications are sent,  what handles these messages and how they are
   handled. It may be that PINT can be used to forward these messages to
   a TNIP server and vice versa.

8. References

   [1] Postel, J., "Instruction to RFC Authors", RFC 1543, October 1993.

   [2] Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J.,
       "SIP Session Initiation Protocol", RFC 2543, March 1999.

Buller                                                         [Page 13]

<draft-ietf-pint-saint-00.txt>   PSTN Initiated Services     March, 1999

   [3] Handley, M., Jacobson, V., "SDP Session Description Protocol"
       RFC 2327, April 1998.

   [4] Petrack, S., Conroy, L., "The PINT profile of SIP and SDP: a
       Protocol for IP access to Telephone Call Services", Internet
       Draft, November 1998.

   [5] Brusilowsky, A. et al, "A proposal for Internet Call Waiting
       Service using SIP. An implementation Report", Internet Draft,
       January 1999.

   [6] Lennox, J., Schulzrinne, H., "Call Processing Language
       Requirements", Internet Draft, July 1998.


   CCIB      Call Completion Internet Busy
   ICW       Internet Call Waiting
   IN        Intelligent Network
   IP        Intelligent Peripheral
   POTS      Plain Old Telephone Service
   PSTN      Public Switched Telephone Network
   SDP       Session Description Protocol
   SIP       Session Initiation Protocol
   VoIP      Voice over IP (Internet Protocol)

9. Acknowledgments

   The author would like to acknowledge the following people.

   Lawrence Conroy  for proof reading this document and pointing out the
   'thin ice' in  relation  to this topic.  I hope I have distributed my
   weight accordingly.

   Igor Faynberg for his encouragement to write this Internet Draft.

   Guenther Murphys in Munich for the Dunkles.

10. Author's Address

   Jim Buller
   Siemens Roke Manor Research Ltd.,
   Roke Manor,
   Old Salisbury Lane,
   SO51 0ZN.
   United Kingdom.

   Telephone: +44 (0)1794833666
   Fax:       +44 (0)1794833434
   E-mail:    jim.buller@roke.co.uk

Buller                                                         [Page 14]