rfc2995.txt

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

  4  |            |            |<-.-.-.-.-.-|            |            |
     |            |   200 OK  4A            |            |            |
  5  |            |<-----------|            |            |            |
     |   200 OK  5A            |            |            |            |
  6  |<-----------|            |            |            |            |
    6A            |            |            |            |            |
     |            |            |            |            |            |

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

                  Figure 3: ICW Service Activation

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

   (0A) The ICW subscriber dials the ISP access number and establishes a
   PPP connection.

   (0B) The ICW Client detects the PPP connection.

   1. The ICW Client sends a registration request to the ICW Server in
   order to register the IP address-DN relationship for the dial-up
   connection.

   2. The ICW Server relays registration request to the SCGF.




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


   2A. The SCGF translates the user registration information from the
   SIP message to the SCP internal API message.

   3. The SCGF relays the user registration message to the SCF/SDF.

   3A. The SCF/SDF authorizes the subscriber with the directory number
   based on the user registration information.

   3B. The SCF/SDF stores the IP address of the ICW Client and sets the
   status to "Internet on-line."

   4. The SCF/SDF sends the result of registration to the SCF/SCGF.

   4A. The SCGF translates the user registration response of the SCP
   internal API message to the PINT message.

   5. The SCGF relays the user registration response to the ICW Server.

   5A. The ICW Server records the user registration information and the
   Internet on-line status for the subscriber in the data base.

   6. The ICW Server sends the user registration response to the ICW
   Client.

   6A. The ICW Client notifies the subscriber that the registration is
   completed successfully and the ICW service is in the active state.

























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


3.5.4. Incoming Call Notification

   When a calling party makes a call to the ICW subscriber, the SCP
   notifies the ICW Client of the incoming call and waits for the
   subscriber's response.

ICW Subscriber ICW Server    SCGF        SCF/SDF     SSF/CCF    Calling
ICW Client                                                        party
 (DN1/IP1)      (IP2)        (IP3)                                 (DN2)
     |            |            |            |            |            |
     |            |            |            |           setup(DN1,DN2)|
  1  |            |            |            |            |<+++++++++++|
     |            |            |            |           1A            |
     |            |            |          IDP(T-busy,DN1)|            |
  2  |            |            |            |<--.--.--.--|            |
     |            |            |           2A            |            |
     |            |            |           2B            |            |
     |            |            |           2C            |            |
     |            |        noti(DN1,IP1,DN2)|            |            |
  3  |            |            |<-.-.-.-.-.-|            |            |
     |            |           3A            |            |            |
     |         INV(DN1,IP1,DN2)|            |            |            |
  4  |            |<-----------|            |            |            |
     |           4A            |            |            |            |
     |            | 100 Trying |            |            |            |
  5  |            |----------->|            |            |            |
  INV(DN1,IP1,DN2)|            |            |            |            |
  6  |<-----------|            |            |            |            |
    6A            |            |            |            |            |
     | 100 Trying |            |            |            |            |
  7  |----------->|            |            |            |            |
     |            |            |            |            |            |

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

                  Figure 4: Incoming Call Notification

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

   1. The calling party at DN2 (a telephone user) makes a call to the
   ICW subscriber (PC user) at DN1.  The connection is set up using the
   existing ISDN signaling.

   1A. The SSF/CCF detects that the callee (the ICW subscriber) is busy.




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


   2. The SSF/CCF sends InitialDP (T_Busy) to the SCF/SDF.

   2A. The SCF/SDF determines whether the user at DN1 is PSTN on-line or
   Internet on-line.  (The SCF/SDF executes the KT Telephone Mail
   Service logic in the PSTN on-line case and the ICW service Logic in
   the Internet on-line case.)

   2B. The SCF/SDF retrieves the IP address corresponding to DN1.

   2C. The SCF/SDF may play an announcement to the calling party, while
   waiting for the response of the called party.

   3. The SCF sends an incoming call notification to the SCGF.

   3A. The SCGF translates the incoming call notification from the SCP
   internal format to the PINT format.

   4. The SCGF relays the notification to the ICW Server.

   4A. The ICW Server double-checks the subscriber's status using the
   ICW subscribers profile in its own data base.

   5. The ICW Server sends trying message to the SCGF.

   6. The ICW Server relays the notification to the ICW Client.

   6A. The ICW Client consults the ICW service profile to see if there
   is a pre-defined call disposition for the incoming call.  If so, then
   the procedure for automatic call processing is performed.

   6B. If there is no pre-defined call disposition for the incoming
   call, the subscriber is notified of the call via a pop-up dialog box.

   7. The ICW Client sends trying message to the ICW Server.

3.6.5. Incoming Call Processing

   The incoming call can be accepted, rejected, forwarded to another
   number, or forwarded to the VMS depending on the on-the-fly or pre-
   defined choice of the subscriber.  This section describes the
   information flows for the cases of "Accept the call" and "Forward the
   call to another number."









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


3.5.5.1. Accept the Call

ICW Subscriber ICW Server    SCGF        SCF/SDF     SSF/CCF    Calling
ICW Client                                                        party
 (DN1/IP1)      (IP2)        (IP3)                                 (DN2)
     |            |            |            |            |            |
    0A   200 OK   |            |            |            |            |
  1  |----------->|            |            |            |            |
    1A            |            |            |            |            |
    1B            |   200 OK   |            |            |            |
  2  |            |----------->|            |            |            |
     |            |    ACK    2A            |            |            |
  3  |            |<-----------|            |            |            |
     |            |            |Accept(DN1,IP1,DN2)      |            |
  4  |            |            |-.-.-.-.-.->|            |            |
     |            |            |            |Connect(DN1,DN2)         |
  5  |            |            |            |--.--.--.-->|            |
     |            |            |           Setup(DN1,DN2)|            |
  6  |<++++++++++++++++++++++++++++++++++++++++++++++++++|            |
     |<==============================6A==============================>|
     |            |            |            |    ERB     |            |
  7  |            |            |            |<--.--.--.--|            |
     |            |            |     ok     |            |            |
  8  |            |            |<-.-.-.-.-.-|            |            |
     |            |           8A            |            |            |
     |            |    BYE     |            |            |            |
  9  |            |<-----------|            |            |            |
     |           9A            |            |            |            |
     |            |            |            |            |            |



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

           Figure 5: Incoming Call Processing - Accept the Call

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

   0A. The ICW subscriber chooses to "Accept" the incoming call.

   1. The ICW Client sends the "Accept" 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 16]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   1B. The ICW Client terminates the subscriber's Internet connection.

   2. The ICW Server sends an "Accept" message to the SCGF.

   2A. The SCGF translates the "Accept" message to an SCP internal API
   message.

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

   4. The SCGF sends the "Accept" message to the SCF.

   5. The SCF instructs the SSF/CCF to route the call to DN1.

   6. The SSF/CCF initiates the connection setup to DN1.

   6A. The bearer connection between the calling party (DN2) and the ICW
   subscriber(DN1) is set up.

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

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

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

   9. The SCGF sends a "BYE" message to the ICW Server.

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






















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


3.5.5.2. Forward the Call to Another Number

ICW Subscriber ICW Server SCGF     SCF/SDF    SSF/CCF    Calling Another
ICW Client                                                party   Phone
 (DN1/IP1)     (IP2)      (IP3)                           (DN2)    (DN3)