📄 rfc2995.txt
字号:
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)
| | | | | | |
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -