📄 rfc2995.txt
字号:
3.6.3. ICW Service Activation
When the subscriber initiates the Internet connection or activates
the ICW service manually, the ICW service is activated. That is done
by sending a REGISTER request with the directory number and IP
address from the ICW Client to the SCP through the ICW Server.
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling
ICW Client party
(DN1/IP1) (IP2) (IP3) (DN2)
| | | | | |
0A | | | | |
0BREG(DN1,IP1)| | | | |
1 |----------->|REG(DN1,IP1)| | | |
2 | |----------->| | | |
| | 2A | | |
| | |reg(DN1,IP1)| | |
3 | | |-.-.-.-.-.->| | |
| | | 3A | |
| | | reg ok 3B | |
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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -