Subject: [PINT] Sorry for filling your other mailbox...

From: Lawrence Conroy <[email-masked]>
Date: Fri, 28 Jul 2000 16:00:07 +0100

Hi Folks,
  Due to the format of the draft(s) being mangled in transit to
Internet-Drafts, the things I want to talk about on Monday won't
appear in the I-D archive until after the meeting :(.
Sorry for this, but here follows the PINT draft. Note that it's
pretty much a mirror image of the SPIRITS one, but the implications
are a little different, and some things have been specified already
in PSP (RFC 2848):
------------------------------------------------------------
PINT Working Group                                             L. Conroy
INTERNET-DRAFT                               Siemens Roke Manor Research
Category: Informational                                        J. Buller
Expires:  January 2001                               Unisphere Solutions

             A list of possible PINT functions

               <draft-conroy-pint-act-00.txt>

   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 (2000). All rights reserved.

Abstract

   This  Internet Draft is one of a pair written at the  request of one
   of the SPIRITS Working Group co-chairs in order to elicit discussion
   on what extended functionality SPIRITS may be used to provide; the
   PINT work has similar requirements for a definition of the building
   blocks that might be used in future services (and so need to be
   supported by the protocol). This note provides the "mirror image" of
   the associated SPIRITS draft, listing functional building blocks that
   may be executed in response to future PINT protocol requests.

Conroy, Buller                                                  [Page 1]

<draft-conroy-pint-act-00.txt>                                July, 2000

Contents of the rest of this document are as follows:

   Section 1...................................................... 2
   Introduction

   Section 2...................................................... 2
   PINT functions

   Section 3...................................................... 5
   Security

   Section 4...................................................... 5
   Summary

   Section 5...................................................... 6
   References

   Section 6...................................................... 6
   Authors' addresses

1.  Introduction

This document lists 'possible' extensions of functionality ("building
blocks") to PINT to aid discussion. It should be read in conjunction
with the equivalent SPIRITS document ("draft-conroy-spirits-act-00.txt").
It is expected that future extensions to PINT services will use more
of the features available within the PSTN/IN, and so these functions
might be expected to be exposed to requesting clients; this will almost
certainly be reflected in future use of the PINT Service Protocol.

2.  PINT functions

  1) Registrations/ Deregistrations of an PSTN entity 
     to the Internet entity (getting trusted entities 'known' 
     to the Internet entity)

This is done already in PINT Service Protocol, using REGISTER
messages.

  2) Registration of available services in the PSTN domain
  
This is done already in the PINT Service Protocol (PSP). Note that
in PSP, this is carried out at the same time as registering an entity;
both are requested in a single REGISTER message. The entity registers
not only the service (the user-part) but also the address to which such
requests should be sent (the host-part).

  3) Request service handling by entity in PSTN domain

This is part of the normal PINT request processing, and as such is
defined in PSP already.

Conroy, Buller                                                  [Page 2]

<draft-ietf-pint-act-00.txt>                                  July, 2000

  4) Service Handling terminated by entity in PSTN domain and 
     handed back to entity in Internet domain for resumption. 
     PSTN domain Service handler takes no further interest in 
     service
This appears to be the normal PINT service processing. However, it
may be extended as a function that has the effect of "handing off"
responsibility for processing a PSTN service to the Internet. Whilst
it is not clear quite how such an arrangement could be arranged in
practice, it is nevertheless a pattern that we may want to consider.

  5) Service handling passed back to entity in Internet domain. 
     However, an interest (perhaps implemented as some kind of 
     monitoring function) is maintained by service handler in the 
     PSTN domain relating to 'this' instance of service

This potential function has the effect of "handing off" responsibility
for processing a PSTN service call to the Internet, whilst allowing the
PSTN service processing to "maintain an interest" in the disposition of
the service processing (possibly by the Internet entity returning status
information to the PSTN entity. Again, this relationship is not covered
in the existing PINT architecture, but could be appropriate for some
complex services. For example, a PINT executive system may have been
asked to make a call leg from a gateway onwards to a PSTN end user
(see next function, for example), with the Internet entity continuing
execution of the overall service by joining a different call leg from
an Internet user to that call leg within the gateway.

  6) Entity in the Internet domain requests an initial PSTN call
This building block can be seen as a re-statement of the existing PINT
service requests.

  7) Entity in the Internet requests a PSTN call leg
This is a building block that is a primitive that might be viewed as
part of the implementation of a PINT Click-to-Dial service. It differs
in that, as only one call leg is requested, and the PINT model implies
a third-party call control model is used in the execution of the
service, there will have to be a subsequent "join leg" primitive action.

  8) Entity in the Internet requests deletion of a PSTN call leg

To ensure widest possible implementation, the existing PINT architecture
does not assume that any existing Service call can be terminated on
request from an Internet entity. However, it is at least possible that
PINT Executive Systems that implement CS-2 call leg manipulation actions
can process such requests.

  9) Entity in the Internet requests a connection of 2 or more PSTN call
     legs

This function differs from the existing PINT Click-to-Dial service in
that there may be more than two call legs that are to be connected (or
joined), the way in which the call legs are referred to may differ, and
that this would normally consist of joining a set of call legs that have
been created previously using a number of separate "add leg" primitives.

Conroy, Buller                                                  [Page 3]

<draft-conroy-pint-act-00.txt>                                July, 2000

 10) Entity in the Internet domain requests transfer of a PSTN call leg

At present, PINT does not define a service to transfer a call leg from
one association to another. However, this is a useful service, and so
should be considered.

 11) Entity in Internet domain requests a Hold/Resume for PSTN-based
     call leg

The existing PINT services do not define a mechanism to change a service
call once in place. This function is another primitive that would let
an Internet entity to manipulate an existing service call, and so extend
more features of the I.N. service processing "upwards".

 12) Event Notification requests sent from Internet to PSTN domain
This function is defined already within the PINT Service Protocol (PSP),
using the Subscribe method. However, its use might be extended to cover
a request for status on a wider range of entities than a PINT service.

 13) Event Notification responses sent from PSTN domain to Internet 
     domain

This function is defined already within PSP (using the Notify method).

 14) Event Notification Session Termination

This function is defined already within PSP (in the Unsubscribe method).

 15) The ability to request an entity in the PSTN domain to Output 
     tones or play announcements or messages

As before, this primitive extends commands that exist in the PSTN 
"upwards" to the Internet. This function would allow a PSTN call leg
associated with an Intelligent Peripheral to have tones or announcements
(or voice prompts) played out to it.

 16) The ability for an entity in the Internet domain to collect 
     information from the PSTN domain (e.g. DTMF)

This primitive reflects the "collect" command that exists within the
Intelligent Network. In the PINT case, the collected digits would be
returned to the Internet entity that made the service primitive request.

 17) The ability to set service data and user data in the PSTN domain 
     from the Internet domain

This is a major function indeed. It might enable I.N. triggers to be set
or PSTN customer service status (i.e. whether or not a PSTN user is
subscribed to a service) to be changed, and might also allow current
PSTN status to be returned. In its latter guise it is similar to the
Subscribe/Notify mechanism that exists within PSP already, but in this
case there is no prior PINT service on which status notifications are
to be returned. The details of this primitive warrant further discussion.

Conroy, Buller                                                  [Page 4]

<draft-conroy-pint-act-00.txt>                                July, 2000

3. Security

   Security issues are for further discussion. This document is only 
   intended to provide the basis for such discussion.

4.  Summary
This note has described some functional building blocks for PINT
services.
The functional building blocks were:

*   Registrations/ Deregistrations of an PSTN entity 
    to the Internet entity (getting trusted entities 'known' 
    to the Internet entity)

*   Registration of available services in the PSTN domain

*   Request service handling by entity in PSTN domain

*   Service Handling terminated by entity in PSTN domain and 
    handed back to entity in Internet domain for resumption. 
    PSTN domain Service handler takes no further interest in 
    service

*   Service handling passed back to entity in Internet domain. 
    However, an interest (perhaps implemented as some kind of 
    monitoring function) is maintained by service handler in the 
    PSTN domain relating to 'this' instance of service

*   Entity in the Internet domain requests an initial PSTN call

*   Entity in the Internet requests a PSTN call leg

*   Entity in the Internet requests deletion of a PSTN call leg

*   Entity in the Internet requests a connection of 2 or more PSTN call
    legs

*   Entity in the Internet domain requests transfer of a PSTN call leg

*   Entity in Internet domain requests a Hold/Resume for PSTN-based 
    call leg

*   Event Notification requests sent from Internet domain to PSTN 
    domain

*   Event Notification responses sent from PSTN domain to Internet 
    domain

*   Event Notification session termination

*   The ability to request an entity in the PSTN domain to Output 
    tones or play announcements or messages
 
Conroy, Buller                                                  [Page 5]

<draft-conroy-pint-act-00.txt>                                July, 2000

*   The ability for an entity in the Internet domain to collect 
    information from the PSTN domain (e.g. DTMF)

*   The ability to set service data and user data in the PSTN domain 
    from the Internet domain

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

   [2] Petrack, S., Conroy, L., "The PINT Service Protocol: Extensions
       to SIP and SDP for IP access to Telephone Call Services", 
       RFC 2848, June 2000.

6. Authors' Addresses 
   Lawrence Conroy
   Siemens Roke Manor Research
   Roke Manor
   Old Salisbury Lane
   Romsey, Hampshire
   U.K.    SO51 0ZN

   Phone: +44 (1794) 833666
   EMail: [email-masked]

   Jim Buller
   Unisphere Solutions,
   900 Broken Sound Parkway, B12S
   Boca Raton, FL 33487. USA

   Phone: +1 561 923 3132
   EMail: [email-masked]

Conroy, Buller                                                  [Page 6]
-- 
All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd pay me for them"    |
|- [email-masked]  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|

_______________________________________________
PINT mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/pint