Subject: [SPIRITS] Minor modifications to Joined PINT-SPIRITS architecture

From: "Slutsman, Lev A, ALSVC" <[email-masked]>
Date: Sun, 2 Jul 2000 18:30:32 -0400

Dear Team,
After reviewing the joined PINT-SPIRIT architecture and Jorgen, Naoto, and
Alec responses I came with minor modification and hope it will satisfy all.

 Figure-1. PINT-SIP Architecture
     Subscriber PC        INTERNET CORE
    _______________    ....................
   | _____________ | A . ________________ .
   | |PINT Client|*******| PINT Server  |******* .
   | |___________| |   . |______________| .     *
   | ____________  |   .        *         .     *
   | |  SPIRITS  | | B . _______*________ .     *
   | |  SERVER   |*******|SPIRITS Proxy | .     *
   | |___________| |   . |______________| .     *
   |_______________|   .........*...........    *
                                *C              *
   _________________     _______*_________      *
  |  Subscriber     |    |SPRITS Client  |      *
  |  Telephone           |               |      *
  |_________________|    |_______________|      *
           *                    *               *E
           *Trunk               *D              *
 ++++++++++*+++++++++++PSTN+++++*+++++++++++++++*++
   ________*_________    _______*_______________*__
   |  SSP(Switch)   |***| SERVICE CONTROL FUNCTIOC|
   |________________|SS7_________________________|

1. Explanations.

2. The Service Descriptions from the Customer Point of view.
The purpose of this section is to provide a generic description for each of 
SPIRITS milestone services: Internet Call Waiting (ICW), Internet Caller-ID
Delivery;
(CNAME), and Internet Call Forwarding. We assume that:
 o.  The service subscriber has a single telephone line and a PC, which may
be, via modem, connected to an ISP, using the same telephone line.
 o. The user's PC is loaded with the service provider software, which
performs a number of functions, such subscription, "dynamic registration",
enables the users to provide his/her choice of service/disposition, etc.
 o. Incoming calls are "trapped" on the subscriber's terminating Local Area
Exchange Switch (LEC) that must implement the Termination Attempt Trigger
(TAT).
 o. Service Control Function (SCF), implemented as Service Control Point
(SCP), or Service Node (SN), or a combination of both SCP and SN; will grant
or reject the termination attempt, and play an announcement for the 
Subscriber' disposition towards incoming call.
We also assume that the SPIRITS services go though the following stages:
 + Service subscription/cancellation.
 + "Dynamic" service registration in order to eliminate:  1)
feature-interaction with traditional telephone services such as a standard
call waiting that allows switching between calling parties; 2) provide extra
security, for example providing the new IP address for each session and
verification of user's PIN.
+ Receiving incoming calls. The duration of the session may be defined by an
"Expiration" parameter, defined during the "dynamic" service registration.
+ "Dynamic" service cancellation. This may be done to avoid the interactions
between "standard" telephony and the Internet base services.
2.1 SPIRITS ICW Overview.
 While the specific implementation details my differ from vendor to vendor,
the main frame-work of the service must confirmed to the following phases.
1. Service Subscription. The service subscription may be implemented in
variety of ways including registration by telephone, registration by mailing
an appropriate application, and an registration via the Internet
Subscription page provided by the service provider.
2. Dynamic Registration. As the result of the service subscription, the
service subscriber will receive/download the appropriate software and
install it on his PC. If PIN number is used, the subscriber's PIN will be
installed in the local PC database. 
3. Session Initiation. The session initiation (see above)is required for two
main reasons: 1)to prevent feature interactions, and to provide the extra
level of security protection. It is strongly recommended to assign a new
user's IP address for each session, and to request a subscriber's
confirmation of his/her PIN. In addition, the subscriber may specify the
"expiration" time for the new session in the range of 0 to infinity.
4. Handling Incoming Calls. (The user's telephone line is connected to the
Internet).
++Call Notification. Normally, upon arrival an incoming call, the subscriber
will see a pop-up window on his PC and will need to provide his
disposition/choice on how to handle this call. As an alternative, the
subscriber may configure his software to send a pre-defined disposition
without a pop-up window. The generic subscriber's Choices are listed below.
 ++Accept Incoming call via the PSTN. This implies that the subscriber is
willing to terminate the Internet connection and receive the incoming call
over the telephone line. As switching can not be done immediately, and
depending on the specific implementation, the caller may hear an opening
announcement followed by the "ringing" tone.
++ Reject Incoming Call.
The subscriber choose to reject the incoming call. In this case he remains
connected to the Internet. The caller will hear the Rejection announcement.
++ Redirection the Incoming call to Voicemail.
In this scenario, the subscriber will remain connected to the Internet. One
suggested implementation is that SCF granted the Termination Attempt
permission to the LEC, and, the switch may use a call forwarding on busy to
relay the incoming call to Voicemail. The Caller may hear the opening
announcement (music for example), followed by the Specific Voicemail
announcement.
++Call Forwarding. To implement this feature, the subscriber should provide
in his/her disposition
a telephone number to which the incoming call will be transferred. The
subscriber remains connected to the Internet. The caller may here an opening
announcement, followed by a specific call forwarding announcement.
++ Accept Call by Voice over IP.
This very useful feature will allow the subscriber to answer the incoming
call via the Internet connection, without disconnecting from ISP. The
current SPIRITS architecture has no provisioning for this feature.
   2.2 The Internet Call Forwarding Service.
In this scenario, the service subscriber shall provide the telephone number
to transfer as his disposition on the incoming call notification.  This
service is actually a subset of the ICW service.
2.3 Internet Caller-ID.
 In this scenario the subscriber should be able to see both the caller
number and his name. The difficulty arises from the limitation of TAT
trigger. The AIN does not allow to send the Caller CNAME as a parameter of
TAT. One possible implementation of this feature requires the use of
database. Thus the SSP will send a message to the SCF to provide the
Caller's CNAME and store it locally. The subscriber software will send a
request to deliver the CNAME to the user's PC.

3. SPITIS Interfaces.  
   The SPIRITS architecture and interfaces are
   Depicted in Figure 1 of the Appendix. The following is the list of
architectural components:
    PSTN Domain
1. SSP(subscriber termination LEC office)that implements the TAT trigger.
2. The SCF will typically resides on SCP. It services a dual purpose: 1)to
control the switch via SS7 interface; and to control the Internet core
elements of the architecture via interfaces D and E.
  IN Domain
3. Spirits Client. This element is responsible for receiving PSTN request,
as well as sending responses back to SCF.
4. The Internet Core consisting of two collocated elements: PINT Server and
SPIRITS-Proxy. The PINT Server receives the PINT-like commands from the PINT
Client and send them to PSTN for execution via E-interface. The SPIRITS
Proxy, that relays the SPRITS request, generated within PSTN to SPRITS
Server.
5. PINT Server. This element resides on the subscriber's PC and used for
generation PINT like request.
6. SPIRITS Server. This element terminates PSTN requests, provides incoming
call notifications, and sends the subscriber choice/disposition back to the
SPIRITS Proxy.
 The rest of this section describes each required interface in more details.

3.1 Interface "A".
This interface is used for sending unsolicited PINT request to PINT Server.
The principal use of this interface is to "dynamically" register the
subscriber (see section 2). As a result of this registration, a)the user's
PIN (if used) is verified; b)the user's PC gets a unique IN address which is
valid for the duration of the session as define by the user; c)the receiving
of incoming calls is enabled.
 In addition this interface may be used for service subscription.
 
  3.2 Interface "B"
This interface is used to notify the subscriber about incoming calls via
pop-up window on the subscriber's PC. In addition, the relevant information
such as Calling number and CNAME will be displayed on the PC.
In the opposite direction, the subscriber choice/disposition is send down to
the SPRITS Proxy.
 
3.3 Interface  "C"
 This interface is used to communicate information
from SPIRITS Client to SPIRITS Proxy and vice versa. The SPIRITS Proxy may
communicate with the SPRITS SERVER, or it may act as a virtual server,
without sending the messages down to the SPIRITS Sever.

3.4 Interface "D".
This interface is used to communicate information between SPIRITS Client and
SCF. In the direction from SCF to SPIRITS Client. Specifically, the
parameters detected in TAT trigger are sent to the SPIRITS Client. The  most
important  for  the  ICW  service  are  "Call ID" (a mandatory parameters,
which specifies the PSTN CALL),  and  "Alerting Pattern" (an  optional
parameter  specifying  how to "ring" the end user).  Thus for ICW, it may be
desirable to 
 use the PC for "ringing" rather than applying the ringing tone to its line,
in order not to interface with standard telephony services such as Voice
Call  Waiting.    
In the direction from SPIRITS Client to SCF, the service subscriber
choices/Disposition are sent. The SCF "transform" the user's disposition
into an appropriate actions, such plying appropriate announcement to the
Caller; resuming the suspended call processing in the SSP, etc.

3.5 Interface "E"
This interface is provided to send PINT request to SCF for execution.

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

---

From: [email-masked]
Date: Mon, 03 Jul 2000 20:36:51 -0400

I am jibing. With a few editorial changes (like PINT-SIP is of course
PINT-SPIRITS, Subscriber PC changed to IP Host, and Internet Core changed IP
Network), we are encorporating this figure in the requirements draft.

Let us keep the picture unchanged for the moment.

Igor

---

From: Alec Brusilovsky <[email-masked]>
Date: Mon, 03 Jul 2000 22:28:11 -0500

Dear Team,

During our meeting in Adelaide some participants responded to our call for
Requirements RFC volunteers.
So far, those who responded were REALLY quiet.
It is, definitely, time to speak up.

Regards,
Alec

P.S. Please have a safe and happy Fourth of July! (Those of us who celebrate it.)