rfc2995.txt

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

   establish and provide the part of the voice path over IP.  The
   Central Office is explicitly connected to the VoIP Gateway via the



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


   ISDN PRI connection.  In this architecture, CSN, VoIP Gateway, and
   VoIP Gatekeeper are the only entities connected to the Internet, with
   each respective connection protected by a firewall.  The CSN and SCP
   are interconnected via a secure IP Intranet.  There may be more than
   one CSN or SCP (or both) (and the SCPs come in mated pairs
   interconnected by X.25, anyway) in a network, but these details are
   not essential to the level of description chosen for this document.
   However, we note that load balancing and adaptation to failures by
   the use of alternative nodes is incorporated into the architecture.

   When someone attempts to call the subscriber, the central office
   serving that subscriber interrupts normal termination processing and
   notifies the SCP which, in turn, can check whether that subscriber
   has registered that he (or she) is logged onto the Internet.
   Exploiting the standardized layering of service logic that
   characterizes the intelligent network, the central office will do
   this without requiring the installation or development of any central
   office software specific to OCC.  The central office is simply
   provisioned to query the SCP when there is a termination attempt
   (i.e., TAT) directed to the subscriber's directory number.  (Note
   that the Central Office has no bearer circuit connection to the SCP,
   only a signaling one over SS7).

   TCP/IP communication between the SCP and CSN utilizes a secure
   intranet.  The subscriber, of course, is assumed to have access only
   to the Internet.

   The intelligent network entities, the SCP and CSN, do have OCC
   related software.  The OCC server is implemented on the CSN.  In
   addition, one service package application (SPA) is installed on the
   SCP.  Another SPA is located in the CSN and is needed only when the
   subscriber elects to accept an incoming call using voice over IP.

   The OCC Server is a collection of Java servers on the CSN whose
   responsibilities include:

   o  Listening for incoming Call Notification (TCP/IP) messages from
      the SCP SPA.

   o  De-multiplexing/multiplexing incoming Call Notification messages
      sent from the SCP SPA.

   o  Relaying messages between the OCC Client and the SCP SPA.

   o  Listening for and authentication of OCC Client requests for
      service registration.





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


   o  Handling encryption/decryption of messages exchanged with the OCC
      Client, and generating session-specific encryption/decryption
      keys.

   The OCC Client is a collection of software components that run on the
   Subscriber's PC.  Its components include the SIP User Agent Server
   (which handles the exchange of SIP messages with the OCC Server and
   invokes the Call Notification pop-up window) and a daemon process
   that monitors the Point-to-Point Protocol (PPP) actions and is
   responsible for starting and stopping the SIP User Agent Server.

4.3. Protocol and Operations Considerations

   The OCC Server uses distinct TCP/IP ports configured on the CSN to

   o  Listen for incoming SIP REGISTER messages (in support of
      registration service) sent from the OCC Client.

   o  Listen for incoming SIP INVITE messages (in support of call
      notification service) sent from the SCP.

   During call notification, the SCP SPA is the client and thus is
   started after the OCC Server has been started.  The SCP SPA and OCC
   Server exchange SIP messages over TCP/IP (via the Secure Intranet)
   using a "nailed-up" connection which is initiated by the SCP SPA.
   This connection is initiated at the time the SCP SPA receives the
   very first SIP REGISTER request from the OCC Server, and must prevail
   for as long as the SPA is in the in-service state.  The SCP SPA also
   supports restarting the connection after any failure condition.

   The OCC Server supports multithreading.  For each Call
   Notification/Call Disposition event, a separate thread is used to
   handle the call.  This model supports multi-threading on a "per
   message" basis where every start message (SIP INVITE) received from
   the SCP SPA uses a separate thread of control to handle the call.
   Subsequent messages containing the same session Call-ID (which
   includes the SPA's instance known as "call_index" and the SCP
   hostname) as the original start message is routed to the same thread
   that previously handled the respective initiating message.

   The OCC Server dynamically opens a new TCP/IP socket with the OCC
   Client for each Call Notification/Call Disposition session.  This
   socket connection uses the IP address and a pre-configured port on
   the PC running the OCC Client software.

   For session registration, the OCC Server dynamically opens TCP/IP
   sessions with the SCP SPA.  The SCP SPA listens at a pre-configured
   port to incoming SIP REGISTER messages sent by OCC Clients via the



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


   OCC Server.  To exchange SIP messages with the OCC Server, the OCC
   Client dynamically opens a TCP/IP socket connection with the OCC
   Server using a pre-configured port number on the CSN and the CSN's IP
   address.

   For the VoIP Scenario, the CSN SPA, acting as a client, dynamically
   opens TCP/IP sessions with the SCP that handled the initial TAT
   query.  As soon as the CSN SPA has successfully made the correlation
   and connected the two incoming call legs pertaining to a VoIP call
   back, the SIP 180 RINGING message will be sent back to the SCP SPA
   running on the actual SCP that instructed the SSP to forward the
   Caller to the CSN.  This SIP message, which contains the VoIP Call
   Back DN dialed by one of the bridged call legs, is an indication to
   the SCP SPA that the VoIP Call Back DN is freed up.

   A typical subscription scenario works like as follows:

   1. Each VoIP Gateway is provisioned with a list of authorized VoIP
      Call Back DNs, each terminating on a particular CSN.  These
      special DNs are used when an on-line subscriber elects to receive
      an incoming call via VoIP.  In particular, they assist in routing
      an outgoing call from the subscriber's NetMeeting to the
      particular CSN to which the SCP is (roughly concurrently)
      forwarding the incoming call.  (These two calls are joined in the
      CSN to connect the incoming call to the subscriber's Netmeeting
      client.)  Furthermore, these special DNs permits that CSN to
      associate, and hence bridge, the correct pair of call legs to join
      the party calling the subscriber to the call from the subscriber's
      NetMeeting client.

   2. The subscriber calls a PSTN service provider and signs up for the
      service.

   3. An active Terminating Attempt Trigger (TAT) is assigned to the
      subscriber's DN at the subscriber's central office.

   4. The PSTN service provider uses the SMS to create a record for the
      subscriber and provision the Subscriber DN and PIN in the OCC RTDB
      table in the SCP.

   5. The subscriber is provided with the OCC Client software, a PIN and
      a file containing the OCC Server IP Addresses.

   Finally, we describe the particular scenario of the OCC Call
   Disposition that involves voice over IP, which proceeds as follows:

   1. The OCC subscriber clicks on "Accept VoIP".




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


   2.  The OCC Client sends a "SIP 380 Alternative Service" message to
       the OCC Server.  This message includes a reference to the Call
       Back DN which will ultimately be used by the CSN to associate the
       call leg (soon to be initiated by the subscriber's NetMeeting)
       connecting to the subscriber (via the VoIP gateway) with the PSTN
       call leg connecting to the calling party.

   3.  The OCC Server closes the TCP/IP session with the OCC Client and
       sends to the SCP SPA the "SIP 380 Alternative Service" message
       which includes the Call Back DN.

   4.  The SCP SPA instructs the Central Office to forward the call
       incoming to the subscriber to the CSN.  This instruction includes
       the Call Back DN.

   5.  The SSP forwards the Caller to the CSN referencing the Call Back
       DN.  Note that the Call Back DN, originally assigned to the OCC
       client by the SCP when the subscriber was alerted to the presence
       of an incoming call attempt, flowed next to the OCC server when
       the client elected to receive the call via VoIP, then to the SCP,
       then to the central office in association with a SCP command to
       forward the incoming call to the CSN, then to the OCC server on
       the CSN in association with that forwarded call.

   6.  Meanwhile, the OCC Client extracts 1) the VoIP Call Back DN from
       the SIP INVITE message received during Call Notification and 2)
       the H323UID and H323PIN values from its properties file and
       updates the 'netmtg.cnf' file.

   7.  The NetMeeting application is launched and sets up a connection
       with the VoIP Gateway.

   8.  Once a connection is established between NetMeeting and the VoIP
       Gateway, NetMeeting initiates a phone call - passing to the VoIP
       Gateway the Call Back DN as the destination DN.

   9.  The VoIP Gateway consults the VoIP Gatekeeper and authenticates
       the NetMeeting call by verifying the H323UID and H323PIN values,
       and by ensuring the called DN (i.e., Call Back DN) is authorized
       for use.

   10. After passing the authentication step, the VoIP Gateway dials
       (via PSTN) the Call Back DN and gets connected to the CSN.  The
       CSN notes that it was reached by the particular Call Back DN.

   11. The CSN bridges the Calling and Called parties together by
       matching on the basis of the Call Back DN.




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


   12. The CSN notifies the SCP (SIP 180 Ringing) of status and
       references the Call Back DN so that the SCP can reuse it for
       other calls.

   13. If the central office supports that two B-channel transfer
       (Lucent, Nortel, and perhaps other central office vender's do),
       an optimization is possible.  The CSN can have the central office
       rearrange the topology of the newly connected call in such a way
       that it flows only through the central office and no longer
       through the CSN.

5. NEC's Implementation

5.1. Overview

   The NEC implementation of the ICW service is based on IN.  Via a
   SPIRITS server and an ICW client, incoming calls will be presented to
   the user via a pop-up screen dialogue box.  This dialogue box informs
   the user of the call arrival time and the calling party's number and
   name (if available).  The arrival of the call is also indicated with
   an accompanied audible indication.

   The pop-up dialogue box offers the user various call management
   options.  Selecting a call management option allows the user to
   answer the call, forward it to another destination or to  voice mail,
   or ignore it.

   The user will be able to customize their service through various
   service set-up options.  All calls presented to the user during an
   Internet session will be recorded in a call log.

   Other features include Multiple call arrival management with which
   each new call arrival will generate its own pop-up dialogue box and
   audible indication.

















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


5.2. Architecture and Overall Call Flow

   Figure 10 depicts the NEC ICW system.

                    ====================================
                    ||         I n t e r n e t         ||
                    ||                                 ||
                    ====================================
                     /                    |        \
                    : (p1)                :         : (p2)
                   /                      |          \
                +-------+             +------------+   +-----+
                |SPIRITS|             |    ISP     |   | W3S |
                |Server |             |    ISP     |   | W3S |
                +-------+             +------------+   +-----+
                   :                      :
   Internet        |                      :
   PSTN/IN         |(p0)                  :
                   :                      :
                   |          ============:======
                +------+ (p3) ||  +-----+ :     ||
                |  SCP |-..-..-..-| SSP | :     ||
                +------+      ||  +-----+ :     ||
                              || (p4)|    :     ||
   +-------+                  ||     :    :     ||
   | ICW   | (p1)+-----+      ||     |    :     ||
   |Client |.....| M/D |............+------+    ||
   +-------+ (p2)+---