rfc2995.txt

中、英文RFC文档大全打包下载完全版 .

     |          |          |          |          |          |         |
    0A          |          |          |          |          |         |
     |303 SeeOther         |          |          |          |         |
  1  |--------->|          |          |          |          |         |
    1A    ACK   |          |          |          |          |         |
  2  |<---------|303 SeeOther         |          |          |         |
  3  |          |--------->|          |          |          |         |
     |          |    ACK  3A          |          |          |         |
  4  |          |<---------|Connect(DN2,DN3)     |          |         |
  5  |          |          |-.-.-.-.->|          |          |         |
     |          |          |          |Connect(DN2,DN3)     |         |
  6  |          |          |          |.--.--.-->|          |         |
     |          |          |          |          |Setup(DN2,DN3)      |
  7  |          |          |          |          ++++++++++++++++++++>|
  8  |          |          |          |   ERB    |          |<===5A==>|
     |          |          |          |<--.--.--.|          |         |
     |          |          |    ok    |          |          |         |
  9  |          |          |<-.-.-.-.-|          |          |         |
     |          |   BYE   9A          |          |          |         |
 10  |          |<---------|          |          |          |         |
     |  BYE    10A         |          |          |          |         |
 11  |<---------|          |          |          |          |         |
    11A         |          |          |          |          |         |
     |          |          |          |          |          |         |

       -----> PINT Protocol             -.-.-> SCP Internal API
       --.--> INAP Protocol             +++++> ISUP Protocol
       =====> Bearer

  Figure 6: Incoming Call Processing - Forward the Call to Another

   As depicted in Figure 6, the relevant information flows are as
   follows:

   0A. The ICW subscriber chooses to "Forward to another number (DN3)"
   for the incoming call.

   1. The ICW Client sends the "Forward to another number" indication to
   the ICW Server.

   1A. The ICW Client records the subscriber's selection for the
   incoming call in the call log.




Lu, et al.                   Informational                     [Page 18]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   2. The ICW Server sends an "ACK" message to the ICW Client.

   3. The ICW Server relays the "Forward to another number" message to
   the SCGF.

   3A. The SCGF translates the "Forward to another number" message to an
   SCP internal API message.

   4. The SCGF sends an "ACK" message to the ICW Server.

   5. The SCGF sends the "Forward to another number" message to the SCF.

   6. The SCF instructs the SSF/CCF to route the call to DN3.

   7. The SSF/CCF initiates the connection setup to DN3.

   7A. The bearer connection between the calling party (DN2) and the new
   termination number (DN3) is set up.

   8. The connection result is returned to the SCF through ERB.

   9. The SCF sends a call completion message to the SCGF.

   9A. The SCGF translates the call completion message to a PINT
   message.

   10. The SCGF sends the call completion message to the ICW Server.

   10A. The ICW Server records the call completion result in the log
   file.

   11. The ICW Server sends the success of "Forwarding to another
   number" to the ICW Client.

   11A. The ICW Client records the call completion result in the log
   file.















Lu, et al.                   Informational                     [Page 19]

RFC 2995              Pre-SPIRITS Implementations          November 2000


3.6.6. ICW service De-activation

   The SCP de-activates the ICW service for a subscriber either upon the
   termination of the subscriber's Internet connection or upon the
   subscriber's manual request.  In this section, we illustrate the
   former scenario.

ICW Subscriber ICW Server    SCGF        SCF/SDF     SSF/CCF    Calling
ICW Client                                                        party
 (DN1/IP1)      (IP2)        (IP3)                                (DN2)
     |            |            |            |            |            |
    0A            |            |            |            |            |
     |           0B            |            |            |            |
     |            |Unreg(DN1,IP1)           |            |            |
  1  |            |----------->|            |            |            |
     |            |           1A            |            |            |
     |            |            |Unreg(DN1,IP1)           |            |
  2  |            |            |-.-.-.-.-.->|            |            |
     |            |            |           2A            |            |
     |            |            |     ok    2B            |            |
  3  |            |            |<-.-.-.-.-.-|            |            |
     |            |           3A            |            |            |
     |            |   200 OK   |            |            |            |
  4  |            |<-----------|            |            |            |
     |           4A            |            |            |            |
     |            |            |            |            |            |


       -----> PINT Protocol             -.-.-> SCP Internal API
       --.--> INAP Protocol             +++++> ISUP Protocol
       =====> Bearer

                 Figure 7: ICW Service De-activation

   As depicted in Figure 7, the relevant information flows are as
   follows:

   0A. The ICW subscriber terminates the Internet connection.

   0B. The ICW Server determines that the Internet connection has been
   terminated when it does not receive the periodic on-line notification
   from the ICW Client.

   1. The ICW Server sends an un-register message to the SCGF.

   1A. The SCGF translates the un-register message to an SCP internal
   API message.




Lu, et al.                   Informational                     [Page 20]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   2. The SCGF sends the un-register message to the SCF.

   2A. The SCF/SDF authorizes the subscriber with the directory number
   based on the un-registration information.

   2B. The SCF/SDF records the Internet off-line status for that ICW
   Client.

   3. The SCF/SDF sends a user un-registration response to the SCF/SCGF.

   3B. The SCGF translates the user un-registration response to a PINT
   message.

   4. The SCGF relays the user un-registration response to the ICW
   Server.

   4A. The ICW Server records the Internet off-line status for the ICW
   Client (subscriber) in the data base.

4. The Lucent Technologies Online Communications Center

4.1 Overview

   The Lucent Technologies Online Communications Center (OCC) is an
   Intelligent Network (IN)-based platform that supports the Internet
   call waiting service.  Its basic components are the OCC Server and
   OCC Client, which are described in detail in the Architecture
   section.  The OCC Server interacts with the PSTN entities over the
   secure intranet via plain-text Session Initiation Protocol (SIP)
   messages [2].  With the PC Client, the OCC Server interacts via
   encrypted SIP messages.

   The OCC Server run-time environment effectively consists of two
   multi-threaded processes responsible for Call Registration and Call
   Notification services, respectively.

   OCC call registration services are initiated from an end-user's PC
   (or Internet appliance).  With those, a subscriber registers his or
   her end-points and activates the notification services.  (The
   registration services are not, strictly speaking, SPIRITS services
   but rather have a flavor of PINT services.)

   All OCC call notification services are PSTN-initiated.  One common
   feature of these services is that of informing the user of the
   incoming telephone call via the Internet, without having any effect
   on the line already used by the modem.  (A typical call waiting tone
   would interrupt the Internet connection, and it is a standard
   practice to disable the  "old" PSTN call waiting service for the



Lu, et al.                   Informational                     [Page 21]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   duration of the call in support of the Internet connection between
   the end-user and the ISP.)

   When a call comes in, the user is presented with a pop-up dialog box,
   which displays the caller's number (if available), name (again, if
   available), as well as the time of the call.  If the called party
   does not initiate an action within a specified period of time the
   call is rejected.

   As far as the disposition of the call is concerned, OCC supports all
   the features described in Section 2.

4.2. Architecture

               +------------+
               | Compact    |            +-------------+
               | Service    |            | Service     |
         +-----| Node (CSN) |            | Management  |
         |     | OCC Server |            | System (SMS)|
         |     | OCC CSN SPA|            +-------------+
         |     +-------:--|-+                   |
         |             |  +-------------[ IP INTRANET ]---------+
       ===== firewall  :                                        |
         |             |                                        |
         |          +-------+                               +-------+
         |          |Central|-..-..-..-..-..-..-..-..-..-..-|Service|
         |      +-%-|Office |-..-..-:                       |Control|
         |      |   +---|---+       |                       |Point  |
         |      %       |           :                       | (SCP) |
         |      |    +--|---+   +-------+    +----------+   |OCC SCP|
         |      %    |  PC  |   | VoIP  |    | VoIP     |   |  SPA  |
         |      |    |OCC Cl|   |Gateway|    |Gatekeeper|   +-------+
         |      %    +------+   +---|---+    +-----|----+
         |      |                 ===== firewall =====
         |      %                   |              |
         |      |   +---------------|---+          |
         |      +-%-|                   |----------+
         +----------|  I N T E R N E T  |
                    |                   |
                    +-------------------+

               Figure 8: The Lucent OCC Physical Architecture

   Figure 8 depicts the joint PSTN/Internet physical architecture
   relevant to the OCC operation.  The Compact Service Node (CSN) and
   SCP are Lucent's implementations of the ITU-T IN Recommendations (in
   particular, the Recommendation Q.1205 where these entities are
   defined) augmented by the requirements of Bellcore's Advanced



Lu, et al.                   Informational                     [Page 22]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   Intelligent Network (AIN) Release 1.0) and equipped with other
   features.  The Central Office (CO) may be any switch supporting the
   Integrated Services Digital Network (ISDN) Primary Rate Interface
   (PRI) and the call forwarding feature that would allow it to
   interwork with the CSN.  Alternatively, in order to interwork with
   the SCP, it needs to be an IN Service Switching Point (SSP).  In the
   latter case, the central office is connected to the SCP via the
   signaling system No. 7 (SS7) and INAP at the application layer.

   The Service Management System (SMS) is responsible for provisioning
   of the SCPs, CSNs, and central offices.  In particular, for IN
   support of the Internet Call Waiting, it must provision the Central
   Office to direct a terminating attempt query to the subsystem number
   corresponding to the OCC SCP SPA based on the Termination Attempt
   Trigger (TAT).  In addition, the Subscriber Directory Number (DN),
   Personal Identification Number (PIN) and Language ID are provisioned
   for each subscriber into the OCC Subscriber entry of the SCP Real
   Time Data Base (RTDB).  Figure 9 shows the structure of an RTDB
   entry.

      +-------------------------------------------------------+
      |DN | PIN | IP Address | Session Key | CNF | Language ID|
      +-------------------------------------------------------+

      Field Descriptions:

      (DN) Directory Number - the subscriber's telephone number

      (PIN) Personal Identification Number - the subscriber's password

      IP Address - Internet Protocol Address of the subscriber

      (CNF) Call Notification In Progress Flag (boolean) - the flag
      indicating if an attempt to notify the subscriber of a call is
      currently in progress

      Session Key - unique identifier for the current registration session
      of the subscriber

      Language ID - language identifier for the subscriber

          Figure 9: Structure of the RTDB Subscriber Record

   The Central Office, SMS, CSN, and SCP are the only PSTN elements of
   the architecture.  The other elements are VoIP Gateway and Gatekeeper
   defined in the ITU-T Recommendation H.323, whose roles are to