Network Working Group H. Lu, Editor
Request for Comments: 2995 I. Faynberg
Category: Informational J. Voelker
M. Weissman
W. Zhang
Lucent Technologies
S. Rhim
J. Hwang
Korea Telecom
S. Ago
S. Moeenuddin
S. Hadvani
NEC
S. Nyckelgard
Telia
J. Yoakum
L. Robart
Nortel Networks
November 2000
Network Working Group H. Lu, Editor
Request for Comments: 2995 I. Faynberg
Category: Informational J. Voelker
M. Weissman
W. Zhang
Lucent Technologies
S. Rhim
J. Hwang
Korea Telecom
S. Ago
S. Moeenuddin
S. Hadvani
NEC
S. Nyckelgard
Telia
J. Yoakum
L. Robart
Nortel Networks
November 2000
Pre-SPIRITS Implementations of PSTN-initiated Services
PSTN发起业务的预处理实现
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document contains information relevant to the work underway in The Services in the PSTN/IN Requesting InTernet Services (SPIRITS) Working Group. It describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN.
本文件包含与PSTN/in请求互联网服务（SPIRITS）工作组服务中正在进行的工作相关的信息。它描述了韩国电信、朗讯科技、NEC和Telia与北电网络合作提供的四种现有的SPIRITS服务实现。类似幽灵的服务是源自公共交换电话网（PSTN）并需要互联网和PSTN交互的服务。
Surveying the implementations, we can make the following observations:
通过调查实施情况，我们可以得出以下观察结果：
o The ICW service plays the role of a benchmark service. All four implementations can support ICW, with three specifically designed for it.
o ICW服务扮演着基准服务的角色。所有四种实现都可以支持ICW，其中三种是专门为ICW设计的。
o Session Initiation Protocol (SIP) is used in most of the implementations as the base communications protocol between the PSTN and Internet. (NEC's implementation is the only exception that uses a proprietary protocol. Nevertheless, NEC has a plan to support SIP together with the extensions for SPIRITS services.)
o 会话发起协议（SIP）在大多数实现中用作PSTN和Internet之间的基本通信协议。（NEC的实现是唯一使用专有协议的例外。尽管如此，NEC计划支持SIP和SPIRITS服务的扩展。）
o All implementations use IN-based solutions for the PSTN part.
o 所有实现都使用PSTN部分基于IN的解决方案。
It is clear that not all pre-SPIRITS implementations inter-operate with each other. It is also clear that not all SIP-based implementations inter-operate with each other given that they do not support the same version of SIP. It is a task of the SPIRITS Working Group to define the inter-networking interfaces that will support interoperation of the future implementations of SPIRITS services.
很明显，并非所有的预处理实现都是相互作用的。同样清楚的是，并非所有基于SIP的实现都相互操作，因为它们不支持相同版本的SIP。SPIRITS工作组的任务是定义支持SPIRITS服务未来实现互操作的互联接口。
Table of Contents
目录
1. Introduction ................................................ 3
2. Service Description of Internet Call Waiting ................ 4
3. Korea Telecom's ICW Implementation .......................... 5
3.1. Overview .................................................. 5
3.2. Network Architecture ...................................... 6
3.3. Network Entities .......................................... 7
3.3.1. SSP ..................................................... 7
3.3.2. SCP ..................................................... 7
3.3.3. IP ...................................................... 7
3.3.4. ICW Server System ....................................... 7
3.3.5. ICW Client System ....................................... 8
3.3.6. Firewall ................................................ 9
3.4. Network Interfaces ........................................ 9
3.5. Protocols ................................................. 9
3.5.1. Intelligent Network Application Part Protocol (INAP) .... 9
3.5.2. PINT Protocol ........................................... 9
3.6. Example Scenarios ........................................ 11
3.6.1. ICW Service Subscription ................................ 11
3.6.2. ICW Client Installation ................................. 11
3.6.3. ICW Service Activation .................................. 12
3.6.4. Incoming Call Notification .............................. 14
3.6.5. Incoming Call Processing ................................ 15
3.6.5.1. Accept the Call ....................................... 16
1. Introduction ................................................ 3
2. Service Description of Internet Call Waiting ................ 4
3. Korea Telecom's ICW Implementation .......................... 5
3.1. Overview .................................................. 5
3.2. Network Architecture ...................................... 6
3.3. Network Entities .......................................... 7
3.3.1. SSP ..................................................... 7
3.3.2. SCP ..................................................... 7
3.3.3. IP ...................................................... 7
3.3.4. ICW Server System ....................................... 7
3.3.5. ICW Client System ....................................... 8
3.3.6. Firewall ................................................ 9
3.4. Network Interfaces ........................................ 9
3.5. Protocols ................................................. 9
3.5.1. Intelligent Network Application Part Protocol (INAP) .... 9
3.5.2. PINT Protocol ........................................... 9
3.6. Example Scenarios ........................................ 11
3.6.1. ICW Service Subscription ................................ 11
3.6.2. ICW Client Installation ................................. 11
3.6.3. ICW Service Activation .................................. 12
3.6.4. Incoming Call Notification .............................. 14
3.6.5. Incoming Call Processing ................................ 15
3.6.5.1. Accept the Call ....................................... 16
3.6.5.2. Forward the Call to Another Number .................... 18
3.6.6. ICW service De-activation ............................... 20
4. The Lucent Technologies Online Communications Center ........ 21
4.1 Overview ................................................... 21
4.2. Architecture .............................................. 22
4.3. Protocol and Operations Considerations .................... 25
5. NEC's Implementation ........................................ 28
5.1. Overview .................................................. 28
5.2. Architecture and Overall Call Flow ........................ 29
5.3. Interfaces and Protocols .................................. 31
5.3.1. SCP (SPIRITS Client)-SPIRITS Server Interface ........... 31
5.3.1.1. Connecting to SPIRITS Services ........................ 31
5.3.1.2. Message Types ......................................... 31
5.3.1.2.1 Connection Management Message Type ................... 31
5.3.1.2.2. Data Message Type ................................... 33
5.3.2. SPIRITS Server-ICW Client Application Interface ......... 34
5.3.3. Secure Reliable Hybrid Datagram Session Protocol
(SRHDSP) for Use .............................................. 35
5.3.3.1. Overview .............................................. 35
5.3.3.2. Session Initiation .................................... 35
5.3.3.3. Secure Reliable Datagram Transport .................... 36
5.3.3.4. Session closure ....................................... 36
6. Telia/Nortel's Implementation ............................... 36
6.1. Overview .................................................. 36
6.2. Architecture and Protocols ................................ 37
6.3. Security .................................................. 39
7. Security Considerations ..................................... 40
8. Conclusion .................................................. 40
9. References .................................................. 41
10. Authors' Addresses ......................................... 41
11. Full Copyright Statement ................................... 44
3.6.5.2. Forward the Call to Another Number .................... 18
3.6.6. ICW service De-activation ............................... 20
4. The Lucent Technologies Online Communications Center ........ 21
4.1 Overview ................................................... 21
4.2. Architecture .............................................. 22
4.3. Protocol and Operations Considerations .................... 25
5. NEC's Implementation ........................................ 28
5.1. Overview .................................................. 28
5.2. Architecture and Overall Call Flow ........................ 29
5.3. Interfaces and Protocols .................................. 31
5.3.1. SCP (SPIRITS Client)-SPIRITS Server Interface ........... 31
5.3.1.1. Connecting to SPIRITS Services ........................ 31
5.3.1.2. Message Types ......................................... 31
5.3.1.2.1 Connection Management Message Type ................... 31
5.3.1.2.2. Data Message Type ................................... 33
5.3.2. SPIRITS Server-ICW Client Application Interface ......... 34
5.3.3. Secure Reliable Hybrid Datagram Session Protocol
(SRHDSP) for Use .............................................. 35
5.3.3.1. Overview .............................................. 35
5.3.3.2. Session Initiation .................................... 35
5.3.3.3. Secure Reliable Datagram Transport .................... 36
5.3.3.4. Session closure ....................................... 36
6. Telia/Nortel's Implementation ............................... 36
6.1. Overview .................................................. 36
6.2. Architecture and Protocols ................................ 37
6.3. Security .................................................. 39
7. Security Considerations ..................................... 40
8. Conclusion .................................................. 40
9. References .................................................. 41
10. Authors' Addresses ......................................... 41
11. Full Copyright Statement ................................... 44
This document contains information relevant to the work underway in The Services in the PSTN/IN Requesting InTernet Services (SPIRITS) Working Group. It describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN.
本文件包含与PSTN/in请求互联网服务（SPIRITS）工作组服务中正在进行的工作相关的信息。它描述了韩国电信、朗讯科技、NEC和Telia与北电网络合作提供的四种现有的SPIRITS服务实现。类似幽灵的服务是源自公共交换电话网（PSTN）并需要互联网和PSTN交互的服务。
Invariably supported by the implementations examined in this document is the Internet Call Waiting (ICW) service. With ICW, service subscribers, while using their telephone lines for Internet access, can be notified of incoming voice calls and specify how to handle the calls over the same telephone lines.
本文档中检查的实现始终支持Internet呼叫等待（ICW）服务。有了ICW，服务用户在使用电话线接入互联网时，可以收到语音来电通知，并指定如何通过相同的电话线处理来电。
The document first gives a detailed description of the ICW service. Then it proceeds to discuss each of the four implementations. The final sections of the document contains security considerations, the conclusion and references.
本文件首先对ICW服务进行了详细说明。然后继续讨论这四种实现中的每一种。文件的最后部分包含安全注意事项、结论和参考资料。
It is important to note that even though the term "SPIRITS server" is used throughout the document, it has no universal meaning. Its connotation depends on the context and varies from implementation to implementation.
需要注意的是，尽管在整个文档中使用了术语“SPIRITS服务器”，但它并没有普遍意义。其内涵取决于上下文，并因实施而异。
Internet call waiting is the single service that is specifically supported by all the implementations in question. In a nutshell, the service enables a subscriber engaged in an Internet dial-up session to
Internet呼叫等待是所有相关实现都特别支持的单一服务。简而言之，该服务使参与Internet拨号会话的用户能够
o be notified of an incoming call to the very same telephone line that is being used for the Internet connection;
o 接到与互联网连接使用的电话线相同的来电通知；
o specify the desirable treatment of the call; and
o 指定呼叫的理想处理方式；和
o have the call handled as specified.
o 按规定处理呼叫。
The details of the ICW service lie in the ways that a waiting call can be treated, which vary from implementation to implementation. In this section, we describe the features that are supported by at least one of the implementations. They are as follows:
ICW服务的细节在于处理等待呼叫的方式，这些方式因实现而异。在本节中，我们将描述至少一个实现所支持的功能。详情如下:
o Incoming Call Notification - The subscriber is notified of an incoming call over the Internet, without having any effect on the telephone line that is being used by the modem. When a call comes in, the subscriber is presented with a pop-up dialog box on the PC. The dialog box may display any combination of the calling party number, calling party name, and calling time. Note that the display of the calling party name (or number) requires the availability of the caller name (or number) delivery feature.
o 来电通知-用户通过互联网收到来电通知，而不会对调制解调器使用的电话线产生任何影响。当来电时，PC上会向用户显示一个弹出对话框。该对话框可以显示主叫方号码、主叫方名称和主叫时间的任意组合。请注意，主叫方名称（或号码）的显示需要主叫方名称（或号码）传递功能的可用性。
o Online Incoming Call Disposition - Once informed of the incoming call, the subscriber has various options (indicated in the pop-up window) for handling the call. Possible options are:
o 在线来电处理-一旦接到来电通知，用户就有各种选项（在弹出窗口中指示）来处理来电。可能的选择包括：
+ Accepting the call over the PSTN line, thus terminating the Internet (modem) connection
+ 通过PSTN线路接受呼叫，从而终止Internet（调制解调器）连接
+ Accepting the call over the Internet using Voice over IP (VoIP)
+ 使用IP语音（VoIP）通过Internet接受呼叫
+ Rejecting the call
+ 拒绝电话
+ Playing a pre-recorded message to the calling party and disconnecting the call
+ 向呼叫方播放预先录制的信息并断开呼叫
+ Forwarding the call to voice mail
+ 将呼叫转发到语音邮件
+ Forwarding the call to another number
+ 将呼叫转接到其他号码
+ Rejecting (or Forwarding) on no Response - If the subscriber fails to respond within a certain period time after the dialog box has been displayed, the incoming call can be either rejected or handled based on the treatment pre-defined by the subscriber.
+ 拒绝（或转发）无响应-如果用户在显示对话框后的特定时间段内没有响应，则可以拒绝来电或根据用户预定义的处理方式处理来电。
o Automatic Incoming Call Disposition - Incoming calls are automatically handled based on dispositions pre-defined by the subscriber without his or her real-time intervention. The subscriber can pre-define the default disposition (e.g., re-directed to voice mail) for general calls as well as customized dispositions for calls from specific numbers. In the latter case, the subscriber selects a particular disposition for each originating number and stores this information in a profile. When a call comes in, the subscriber won't be presented the call but can examine the treatment and outcome of the call from the caller log (as described in the call logging bullet). Naturally, this feature also allows the subscriber to specify the desired treatment for calls originating from private or unpublished numbers.
o 自动来电处理-根据用户预先定义的处理方式自动处理来电，无需用户实时干预。订户可以预先定义常规呼叫的默认配置（例如，重新定向到语音邮件）以及特定号码呼叫的自定义配置。在后一种情况下，订户为每个原始号码选择特定的配置，并将该信息存储在配置文件中。当一个呼叫进入时，用户将不会收到该呼叫，但可以从呼叫者日志中检查呼叫的处理和结果（如呼叫记录项目符号中所述）。当然，此功能还允许订户为来自私人或未公开号码的呼叫指定所需的处理方式。
o Multiple Call Handling - Multiple calls can arrive during call disposition processing. With multiple call handling, the subscriber is notified of the multiple calls one by one.
o 多个呼叫处理-在呼叫处理过程中可能会有多个呼叫到达。通过多个呼叫处理，用户将一个接一个地收到多个呼叫的通知。
o Call Logging - A detailed log of the incoming calls processed during the ICW service is kept. Typical information recorded in the log include the incoming call date and time, calling party number, calling party name, and call disposition.
o 呼叫记录-保留ICW服务期间处理的传入呼叫的详细日志。日志中记录的典型信息包括来电日期和时间、主叫方号码、主叫方名称和呼叫处理。
Korea Telecom's ICW implementation supports most of the features described in Section 2. (The major exception is the feature of receiving the incoming call over the Internet using voice over IP.) In addition, the Korea Telecom implementation supports flexible activation and de-activation of the ICW service:
韩国电信的ICW实施支持第2节中描述的大部分功能。（主要例外是使用IP语音通过互联网接收来电的功能。）此外，韩国电信实施支持灵活激活和取消激活ICW服务：
o Automatic Activation/De-activation - When Internet dial-up connection is set up, the ICW service is activated or de-activated automatically.
o 自动激活/取消激活-设置Internet拨号连接时，ICW服务将自动激活或取消激活。
o Manual Activation/De-activation - The subscriber can de-activate the ICW service manually when call notification is not desired during the Internet dial-up session and activate it when needed.
o 手动激活/取消激活-当互联网拨号会话期间不需要呼叫通知时，用户可以手动取消激活ICW服务，并在需要时激活。
Figure 1 depicts the network architecture of the Korea Telecom ICW service. The Service Switching Point (SSP), Service Control Point (SCP), and Intelligent Peripheral (IP) are legacy PSTN IN elements based on IN CS-1. In contrast, both the ICW Server System and the ICW Client System are new network elements that are installed in the Internet domain to support of the ICW service.
图1描述了韩国电信ICW服务的网络架构。服务交换点（SSP）、服务控制点（SCP）和智能外围设备（IP）是基于CS-1的传统PSTN元件。相反，ICW服务器系统和ICW客户端系统都是安装在Internet域中以支持ICW服务的新网元。
+---------------------------+ | +--------------+
|+--------+propr-+---------+| PINT | |(Proxy Server)| PINT
||(ICW SL)|ietary|(UAC/UAS)||--- -||-----| ICW |----+
||SCF/SDF |------| SCGF || firewall |Server System | |
|+--------+ i/f +---------+| | +------------- + |
| SCP | | |
+------+--------------+-----+ | |
|INAP |INAP | firewall=====
| | | |
+---+---+ +---+---+ |
| IP | | SSP | |
+-------+ +---+---+ +-------------+
| +---+ | (UAC/UAS) |
+---+---+ || || | ICW |
|---------| LEX |-------------- + + |Client System|
+---+ +-------+ +++++----+-------------+
|| || (callee)
+ + ICW Subscriber's Phone and PC
+++++
(caller)
+---------------------------+ | +--------------+
|+--------+propr-+---------+| PINT | |(Proxy Server)| PINT
||(ICW SL)|ietary|(UAC/UAS)||--- -||-----| ICW |----+
||SCF/SDF |------| SCGF || firewall |Server System | |
|+--------+ i/f +---------+| | +------------- + |
| SCP | | |
+------+--------------+-----+ | |
|INAP |INAP | firewall=====
| | | |
+---+---+ +---+---+ |
| IP | | SSP | |
+-------+ +---+---+ +-------------+
| +---+ | (UAC/UAS) |
+---+---+ || || | ICW |
|---------| LEX |-------------- + + |Client System|
+---+ +-------+ +++++----+-------------+
|| || (callee)
+ + ICW Subscriber's Phone and PC
+++++
(caller)
INAP : Intelligent Network Application Protocol PINT : PSTN/Internet Interworking Protocol SL : Service Logic UAS : User Agent Server UAC : User Agent Client
INAP：智能网应用协议PINT:PSTN/互联网互通协议SL:服务逻辑UAS:用户代理服务器UAC:用户代理客户端
Figure 1: Network Architecture of the Korea Telecom ICW Service
图1：韩国电信ICW服务的网络架构
The SSP performs the Service Switching Function (SSF) and Call Control Function (CCF). When detecting that the called party is busy (T_Busy), the SSP sends a query to the SCP and processes the call under the control of the SCP.
SSP执行服务切换功能（SSF）和呼叫控制功能（CCF）。当检测到被叫方正忙（T_busy）时，SSP向SCP发送查询，并在SCP的控制下处理呼叫。
The SCP performs the Service Control Function (SCF) and Service Data Function (SDF). It, when queried, instructs the SSP to process the call based on the service logic. In the case of the ICW service, the service logic ultimately governs the notification of a waiting call to an online ICW subscriber and the disposition of the call. In addition, the SCP performs the Service Control Gateway Function (SCGF) for protocol inter-working between the PSTN/IN and Internet. It translates the SIP message from the ICW Server to the service control interface message and vise versa. The SCGF is an IP end point and behaves as a UAS (User Agent server) or UAC (User Agent client).
SCP执行服务控制功能（SCF）和服务数据功能（SDF）。当被查询时，它指示SSP根据服务逻辑处理呼叫。在ICW服务的情况下，服务逻辑最终控制对在线ICW订户的等待呼叫的通知和呼叫的处理。此外，SCP执行PSTN/In和Internet之间协议互通的服务控制网关功能（SCGF）。它将SIP消息从ICW服务器转换为服务控制接口消息，反之亦然。SCGF是一个IP端点，其行为类似于UAS（用户代理服务器）或UAC（用户代理客户端）。
The IP contains Service Resource Function (SRF). It, when necessary, plays announcements to the calling party during the ICW service before/after receiving the response from the ICW subscriber and records the calling party number or voice message from the calling party when the call is forwarded to the Voice Mail System (VMS).
IP包含服务资源功能（SRF）。必要时，在ICW服务期间，在接收到ICW用户的响应之前/之后向主叫方播放通知，并在将呼叫转发到语音邮件系统（VMS）时记录主叫方号码或主叫方的语音消息。
The ICW Server system serves as a SIP proxy or a redirect server for message routing between the ICW Client and SCGF. The ICW Server is also responsible for managing the ICW Clients that are connected to it. When an ICW Client (subscriber) sends a registration request for the ICW service, the ICW Server relays that request to the SCP, waits for the result of authorization from the SCP, and registers the authorized subscriber in its data base. In addition, the ICW Server monitors the connection status of the registered ICW Clients. As soon as a client deactivates the ICW service or terminates the Internet connection, the ICW Server detects the status change and deactivates the ICW service for the client. Finally, the ICW Server manages profiles for each ICW subscribers as well as logs all the call processing results.
ICW服务器系统用作SIP代理或重定向服务器，用于ICW客户端和SCGF之间的消息路由。ICW服务器还负责管理与其连接的ICW客户端。当ICW客户端（订户）发送ICW服务的注册请求时，ICW服务器将该请求转发给SCP，等待来自SCP的授权结果，并在其数据库中注册授权订户。此外，ICW服务器监视已注册ICW客户端的连接状态。一旦客户端停用ICW服务或终止Internet连接，ICW服务器就会检测到状态更改并停用客户端的ICW服务。最后，ICW服务器管理每个ICW订户的配置文件，并记录所有呼叫处理结果。
The ICW Client System is an application program running on the subscriber's PC. Launched as soon as the subscriber powers on the PC, it monitors the Internet connection status of the PC (or subscriber). Upon the subscriber's connection to the Internet, the ICW Client sends a REGISTRATION request to the SCGF via the ICW Server and then eventually to the SCP. In this capacity, the ICW Client acts as a UAC to the SCGF, which acts as a UAS. Thereafter it notifies the ICW Server periodically of the connection status of the subscriber.
ICW客户端系统是一个在用户PC上运行的应用程序。一旦用户在PC上通电，它就会启动，监视PC（或用户）的Internet连接状态。当用户连接到互联网时，ICW客户端通过ICW服务器向SCGF发送注册请求，然后最终发送到SCP。在这种情况下，ICW客户端充当SCGF的UAC，SCGF充当UAS。此后，它定期通知ICW服务器订户的连接状态。
The ICW Client is also responsible for popping up a dialog box on the subscriber's PC to announce an incoming call. The dialog box displays the number and name of calling party, calling time, and the call processing options (including Accept, Reject, Forward to another number or VMS). After the subscriber selects the option, the ICW Client sends it to the SCP. In this capacity, the ICW Client acts as a UAS.
ICW客户端还负责在用户的PC上弹出一个对话框来宣布来电。该对话框显示呼叫方的号码和名称、呼叫时间以及呼叫处理选项（包括接受、拒绝、转发到其他号码或虚拟机）。订户选择该选项后，ICW客户端将其发送给SCP。在这种情况下，ICW客户端充当UAS。
Depending on the pre-defined ICW Service Profile, the ICW Client may screen the incoming call before notifying the subscriber.
根据预定义的ICW服务配置文件，ICW客户端可以在通知订户之前屏蔽传入呼叫。
The ICW Client manages the ICW Service Profile, which contains the following fields:
ICW客户端管理ICW服务配置文件，其中包含以下字段：
o Subscriber Information (including, Name, Directory Number, Password)
o 订户信息（包括名称、目录号、密码）
o Service Status (Activation/De-activation)
o 服务状态（激活/取消激活）
o Automatic Call Processing Method
o 自动呼叫处理方法
+ Call Processing Method on No Answer (Reject/Forward/VMS) - The call is automatically handled by the method if the subscriber doesn't respond after a pre-defined period of time.
+ 无应答呼叫处理方法（拒绝/转发/VMS）-如果用户在预定义的时间段后没有响应，则该方法会自动处理呼叫。
+ Do Not Disturb Mode (On/Off) - When this is set on, the subscriber won't be notified of the incoming calls.
+ 请勿打扰模式（开/关）-当此模式设置为开时，用户不会收到来电通知。
+ Call Processing Method on Do Not Disturb (Reject/Forward/VMS)
+ 请勿打扰（拒绝/转发/VMS）上的呼叫处理方法
+ Call Processing List by Calling Party Numbers (Accept/Reject/Forward/VMS) - Calls originated from a number on the list are handled by the associated call processing method.
+ 按主叫方号码列出的呼叫处理列表（接受/拒绝/转发/VMS）-来自列表上号码的呼叫由关联的呼叫处理方法处理。
o The ICW Client records the call processing method and the result for each incoming call in a log file on the subscriber's PC. The
o ICW客户端在用户PC上的日志文件中记录每个传入呼叫的呼叫处理方法和结果
call record in the call log contains the following information:
呼叫日志中的呼叫记录包含以下信息：
- Calling Time - Calling Party Number - Calling Party Name (optional) - Call Processing Method (Accept/Reject/Forward/Forward to VMS) - Result (Success/Fail)
- 呼叫时间-呼叫方号码-呼叫方名称（可选）-呼叫处理方法（接受/拒绝/转发/转发至虚拟机）-结果（成功/失败）
Packet Filtering Firewall Systems are between the ICW server and clients as well as between the SCGF and ICW server for accessing the Korea Telecom IN Nodes.
包过滤防火墙系统位于ICW服务器和客户端之间以及SCGF和ICW服务器之间，用于访问韩国电信IN节点。
o The SCF-SDF, SCF-SSF, and SCF-SRF interfaces are the same as existing PSTN IN Interfaces based on the KT INAP CS-1.
o SCF-SDF、SCF-SSF和SCF-SRF接口与基于KT INAP CS-1的现有PSTN接口相同。
o The SCGF-SCF interface relays requests either from the IN or the Internet and is implemented based on the internal API of the SCP.
o SCGF-SCF接口中继来自IN或Internet的请求，并基于SCP的内部API实现。
o The SCGF-ICW Server and ICW Server-ICW Client interfaces are implemented based on the PINT Service Protocol V.1. We adopted UAS-Proxy-UAC relationships as shown in Figure 2.
o SCGF-ICW服务器和ICW服务器ICW客户端接口基于PINT服务协议V.1实现。我们采用了UAS代理UAC关系，如图2所示。
+---------+ +-------------+ +---------+
|(UAC/UAS)|PINT 1.0| (Proxy) |PINT 1.0|(UAC/UAS)|
| |--------| ICW |--------| ICW |
| SCGF | | Server | | Client |
+---------+ +-------------+ +---------+
+---------+ +-------------+ +---------+
|(UAC/UAS)|PINT 1.0| (Proxy) |PINT 1.0|(UAC/UAS)|
| |--------| ICW |--------| ICW |
| SCGF | | Server | | Client |
+---------+ +-------------+ +---------+
Figure 2: PINT Protocol Architecture
图2:PINT协议体系结构
The SCP, SSP, and IP support the KT INAP V1.0, which is based on ITU-T INAP CS-1 with the incorporation of two INAP CS-2 messages [PRM (PromptAndReceiveMessage) and EM (EraseMessage)] for recording the voice message.
SCP、SSP和IP支持KT INAP V1.0，该版本基于ITU-T INAP CS-1，包含两条INAP CS-2消息[PRM（PromptAndReceiveMessage）和EM（橡皮擦消息）]，用于记录语音消息。
The ICW service uses the PINT Service Protocol 1.0 [1] for communications between the SCP and the ICW Server System, and between the ICW Server System and the ICW Client System. Developed in the
ICW服务使用PINT服务协议1.0[1]在SCP和ICW服务器系统之间以及ICW服务器系统和ICW客户端系统之间进行通信。在
IETF PINT Working Group for invoking telephone services from an IP network, the PINT Service Protocol 1.0 specifies a set of enhancements to SIP 2.0 and SDP.
IETF PINT工作组为从IP网络调用电话服务，PINT服务协议1.0规定了对SIP 2.0和SDP的一组增强。
Summarized below are the elements of the PINT Service Protocol 1.0 relevant to the Korea Telecom ICW implementation:
以下总结了与韩国电信ICW实施相关的PINT服务协议1.0的要素：
o REGISTER
o 登记
The REGISTER method is used to inform the SCP of the connection status of an ICW subscriber. With this method, the ICW Client sends to the ICW Server the IP address (of the PC) and phone number of the subscriber when the subscriber is first connected to the Internet. The ICW server relays the information to the SCP, which updates the data base (if the subscriber is authorized), and in the end sends a registration acknowledgment to the ICW Server and then the Client. After the subscriber is connected to the Internet, the ICW Client sends a REGISTER request to the ICW Server periodically at a pre-defined interval (e.g., 20 seconds) to indicate its connection status. The request is not relayed to the SCP. The ICW Server only checks if it is from the authorized subscriber. Finally, when the subscriber terminates the Internet connection, the Client sends the last REGISTER request to the SCP via the ICW Server. If the REGISTER request does not arrive during the pre-defined interval, the ICW Server can also detect the change of the connection status of the ICW Client.
寄存器方法用于通知SCP ICW用户的连接状态。使用此方法，当用户首次连接到Internet时，ICW客户端向ICW服务器发送（PC的）IP地址和用户的电话号码。ICW服务器将信息转发给SCP，SCP更新数据库（如果订户获得授权），并最终向ICW服务器发送注册确认，然后发送给客户端。在订户连接到因特网之后，ICW客户端以预定义的间隔（例如，20秒）周期性地向ICW服务器发送注册请求，以指示其连接状态。请求不会中继到SCP。ICW服务器仅检查它是否来自授权订户。最后，当订户终止Internet连接时，客户端通过ICW服务器向SCP发送最后一个注册请求。如果注册请求没有在预定义的时间间隔内到达，ICW服务器还可以检测ICW客户端连接状态的变化。
o INVITE
o 邀请
The SCP uses the INVITE method to notify the ICW Client, via the ICW Server, of an incoming call.
SCP使用INVITE方法通过ICW服务器通知ICW客户端传入呼叫。
o ACK
o 阿克
Both the SCP and the ICW Server use the ACK method to confirm the receipt of the final responses to their requests.
SCP和ICW服务器都使用ACK方法确认收到对其请求的最终响应。
o BYE
o 再见
The BYE method terminates a service session. In addition to this original usage, we use the value (success or failure) of the Subject header to indicate the result of the desired disposition of an incoming call in the PSTN.
BYE方法终止服务会话。除了这个最初的用法之外，我们还使用Subject报头的值（success或failure）来指示PSTN中传入呼叫的期望处理结果。
o CANCEL
o 取消
When the calling party releases the call before the called party responds, the SCP sends a CANCEL request to the ICW Client to cancel the INVITE request that it sent previously.
当主叫方在被叫方响应之前释放呼叫时，SCP向ICW客户端发送取消请求，以取消其先前发送的INVITE请求。
o OPTION
o 选项
This method is not used in the KT implementation.
KT实现中未使用此方法。
o Responses
o 响应
The SCP responds to a REGISTER request with one of the status codes and associated comments below:
SCP使用以下状态代码和相关注释之一响应注册请求：
. 100 Trying: Trying . 200 OK: Registered
. 100努力：努力。200行：已注册
The ICW Client responds to an INVITE request with one of the status codes and associated comments below:
ICW客户端使用以下状态代码和相关注释之一响应INVITE请求：
. 100 Trying: Trying . 200 OK: Accept the Call . 303 see other: Forward the Call to Another Number . 380 alternative service: Forward the Call to the VMS . 603 decline: Reject the Call
. 100努力：努力。200好：接受电话。303参见其他：将呼叫转接至其他号码。380备用服务：将呼叫转发给虚拟机。603拒绝：拒绝呼叫
Access to the Korea Telecom ICW service is by subscription. Here Korea Telecom serves as both the PSTN operator and IN-based ICW service provider. Note that the subscription data need to be loaded onto the relevant SSPs, including the local ones that may not be operated by Korea Telecom.
可通过订阅方式访问韩国电信ICW服务。韩国电信是PSTN运营商和基于IN的ICW服务提供商。请注意，订阅数据需要加载到相关SSP上，包括可能不由韩国电信运营的本地SSP。
An ICW subscriber should install the ICW Client program in his or her PC. The ICW Client is automatically activated to run as a daemon process when the subscriber's PC is turned on. The Client monitors the Internet connection status of the subscriber.
ICW订阅者应在其PC中安装ICW客户端程序。当订阅者的PC打开时，ICW客户端将自动激活以作为守护进程运行。客户端监视订阅服务器的Internet连接状态。
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.
当用户启动Internet连接或手动激活ICW服务时，ICW服务被激活。这是通过从ICW客户端通过ICW服务器向SCP发送带有目录号和IP地址的注册请求来完成的。
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 | | | | |
| | | | | |
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
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> Bearer
Figure 3: ICW Service Activation
图3:ICW服务激活
As depicted in Figure 3, the relevant information flows are as follows:
如图3所示，相关信息流如下所示：
(0A) The ICW subscriber dials the ISP access number and establishes a PPP connection.
（0A）ICW用户拨打ISP接入号码并建立PPP连接。
(0B) The ICW Client detects the PPP connection.
（0B）ICW客户端检测到PPP连接。
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.
1. ICW客户端向ICW服务器发送注册请求，以便注册拨号连接的IP地址DN关系。
2. The ICW Server relays registration request to the SCGF.
2. ICW服务器将注册请求转发给SCGF。
2A. The SCGF translates the user registration information from the SIP message to the SCP internal API message.
2A。SCGF将用户注册信息从SIP消息转换为SCP内部API消息。
3. The SCGF relays the user registration message to the SCF/SDF.
3. SCGF将用户注册消息转发给SCF/SDF。
3A. The SCF/SDF authorizes the subscriber with the directory number based on the user registration information.
3A。SCF/SDF根据用户注册信息使用目录号授权订户。
3B. The SCF/SDF stores the IP address of the ICW Client and sets the status to "Internet on-line."
3B。SCF/SDF存储ICW客户端的IP地址，并将状态设置为“Internet联机”
4. The SCF/SDF sends the result of registration to the SCF/SCGF.
4. SCF/SDF将注册结果发送给SCF/SCGF。
4A. The SCGF translates the user registration response of the SCP internal API message to the PINT message.
4A。SCGF将SCP内部API消息的用户注册响应转换为PINT消息。
5. The SCGF relays the user registration response to the ICW Server.
5. SCGF将用户注册响应转发给ICW服务器。
5A. The ICW Server records the user registration information and the Internet on-line status for the subscriber in the data base.
5A。ICW服务器在数据库中记录用户注册信息和用户的互联网在线状态。
6. The ICW Server sends the user registration response to the ICW Client.
6. ICW服务器向ICW客户端发送用户注册响应。
6A. The ICW Client notifies the subscriber that the registration is completed successfully and the ICW service is in the active state.
6A。ICW客户端通知订户注册已成功完成，ICW服务处于活动状态。
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用户时，SCP将传入呼叫通知ICW客户端并等待用户的响应。
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 |----------->| | | | |
| | | | | |
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
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> Bearer
Figure 4: Incoming Call Notification
图4：来电通知
As depicted in Figure 4, the relevant information flows are as follows:
如图4所示，相关信息流如下所示：
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.
1. DN2的主叫方（电话用户）拨打DN1的ICW用户（PC用户）。使用现有ISDN信令建立连接。
1A. The SSF/CCF detects that the callee (the ICW subscriber) is busy.
1A。SSF/CCF检测到被叫方（ICW用户）正忙。
2. The SSF/CCF sends InitialDP (T_Busy) to the SCF/SDF.
2. SSF/CCF向SCF/SDF发送初始DP（T_Busy）。
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.)
2A。SCF/SDF确定DN1处的用户是PSTN在线用户还是Internet在线用户。（SCF/SDF在PSTN在线情况下执行KT电话邮件服务逻辑，在互联网在线情况下执行ICW服务逻辑。）
2B. The SCF/SDF retrieves the IP address corresponding to DN1.
2B。SCF/SDF检索与DN1对应的IP地址。
2C. The SCF/SDF may play an announcement to the calling party, while waiting for the response of the called party.
2C。SCF/SDF可以在等待被叫方响应的同时向主叫方播放公告。
3. The SCF sends an incoming call notification to the SCGF.
3. SCF向SCGF发送传入呼叫通知。
3A. The SCGF translates the incoming call notification from the SCP internal format to the PINT format.
3A。SCGF将来电通知从SCP内部格式转换为PINT格式。
4. The SCGF relays the notification to the ICW Server.
4. SCGF将通知转发给ICW服务器。
4A. The ICW Server double-checks the subscriber's status using the ICW subscribers profile in its own data base.
4A。ICW服务器在其自己的数据库中使用ICW订阅者配置文件双重检查订阅者的状态。
5. The ICW Server sends trying message to the SCGF.
5. ICW服务器向SCGF发送尝试消息。
6. The ICW Server relays the notification to the ICW Client.
6. ICW服务器将通知转发给ICW客户端。
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.
6A。ICW客户端咨询ICW服务配置文件，查看传入呼叫是否有预定义的呼叫处理。如果是，则执行自动呼叫处理程序。
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.
6B。如果传入呼叫没有预定义的呼叫处理，则会通过弹出对话框通知用户该呼叫。
7. The ICW Client sends trying message to the ICW Server.
7. ICW客户端向ICW服务器发送尝试消息。
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."
根据用户的动态或预定义选择，可以接受、拒绝、转发到其他号码或转发到虚拟机。本节描述了“接受呼叫”和“将呼叫转接到其他号码”情况下的信息流
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 | | | |
| | | | | |
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
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> Bearer
Figure 5: Incoming Call Processing - Accept the Call
图5：来电处理-接受来电
As depicted in Figure 5, the relevant information flows are as follows:
如图5所示，相关信息流如下所示：
0A. The ICW subscriber chooses to "Accept" the incoming call.
0A。ICW用户选择“接受”传入呼叫。
1. The ICW Client sends the "Accept" indication to the ICW Server.
1. ICW客户端向ICW服务器发送“接受”指示。
1A. The ICW Client records the subscriber's selection for the incoming call in the call log.
1A。ICW客户端在呼叫日志中记录用户对传入呼叫的选择。
1B. The ICW Client terminates the subscriber's Internet connection.
1B。ICW客户端终止订户的Internet连接。
2. The ICW Server sends an "Accept" message to the SCGF.
2. ICW服务器向SCGF发送“接受”消息。
2A. The SCGF translates the "Accept" message to an SCP internal API message.
2A。SCGF将“接受”消息转换为SCP内部API消息。
3. The SCGF sends an "ACK" message to the ICW Server.
3. SCGF向ICW服务器发送“ACK”消息。
4. The SCGF sends the "Accept" message to the SCF.
4. SCGF向SCF发送“接受”消息。
5. The SCF instructs the SSF/CCF to route the call to DN1.
5. SCF指示SSF/CCF将呼叫路由至DN1。
6. The SSF/CCF initiates the connection setup to DN1.
6. SSF/CCF启动到DN1的连接设置。
6A. The bearer connection between the calling party (DN2) and the ICW subscriber(DN1) is set up.
6A。建立主叫方（DN2）与ICW用户（DN1）之间的承载连接。
7. The connection result is returned to the SCF through ERB.
7. 连接结果通过ERB返回给SCF。
8. The SCF sends a call completion message to the SCGF.
8. SCF向SCGF发送呼叫完成消息。
8A. The SCGF translates the call completion message to a PINT message.
8A。SCGF将呼叫完成消息转换为PINT消息。
9. The SCGF sends a "BYE" message to the ICW Server.
9. SCGF向ICW服务器发送“再见”消息。
9A. The ICW Server records the call completion result in the log file.
9A。ICW服务器在日志文件中记录呼叫完成结果。
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 | | | | | |
| | | | | | |
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
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> Bearer
Figure 6: Incoming Call Processing - Forward the Call to Another
图6：传入呼叫处理-将呼叫转发给另一个
As depicted in Figure 6, the relevant information flows are as follows:
如图6所示，相关信息流如下所示：
0A. The ICW subscriber chooses to "Forward to another number (DN3)" for the incoming call.
0A。ICW用户选择“转发到另一个号码（DN3）”进行传入呼叫。
1. The ICW Client sends the "Forward to another number" indication to the ICW Server.
1. ICW客户端向ICW服务器发送“转发到另一个号码”指示。
1A. The ICW Client records the subscriber's selection for the incoming call in the call log.
1A。ICW客户端在呼叫日志中记录用户对传入呼叫的选择。
2. The ICW Server sends an "ACK" message to the ICW Client.
2. ICW服务器向ICW客户端发送“ACK”消息。
3. The ICW Server relays the "Forward to another number" message to the SCGF.
3. ICW服务器将“转发到另一个号码”消息中继到SCGF。
3A. The SCGF translates the "Forward to another number" message to an SCP internal API message.
3A。SCGF将“转发到另一个号码”消息转换为SCP内部API消息。
4. The SCGF sends an "ACK" message to the ICW Server.
4. SCGF向ICW服务器发送“ACK”消息。
5. The SCGF sends the "Forward to another number" message to the SCF.
5. SCGF向SCF发送“转发到另一个号码”消息。
6. The SCF instructs the SSF/CCF to route the call to DN3.
6. SCF指示SSF/CCF将呼叫路由至DN3。
7. The SSF/CCF initiates the connection setup to DN3.
7. SSF/CCF启动到DN3的连接设置。
7A. The bearer connection between the calling party (DN2) and the new termination number (DN3) is set up.
7A。在主叫方（DN2）和新的终端号码（DN3）之间建立承载连接。
8. The connection result is returned to the SCF through ERB.
8. 连接结果通过ERB返回给SCF。
9. The SCF sends a call completion message to the SCGF.
9. SCF向SCGF发送呼叫完成消息。
9A. The SCGF translates the call completion message to a PINT message.
9A。SCGF将呼叫完成消息转换为PINT消息。
10. The SCGF sends the call completion message to the ICW Server.
10. SCGF向ICW服务器发送呼叫完成消息。
10A. The ICW Server records the call completion result in the log file.
10A。ICW服务器在日志文件中记录呼叫完成结果。
11. The ICW Server sends the success of "Forwarding to another number" to the ICW Client.
11. ICW服务器向ICW客户端发送“转发到另一个号码”的成功消息。
11A. The ICW Client records the call completion result in the log file.
11A。ICW客户端在日志文件中记录呼叫完成结果。
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.
SCP在用户的互联网连接终止或用户的手动请求时为用户停用ICW服务。在本节中，我们将说明前一种情况。
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 | | | |
| | | | | |
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
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> Bearer
Figure 7: ICW Service De-activation
图7:ICW服务停用
As depicted in Figure 7, the relevant information flows are as follows:
如图7所示，相关信息流如下所示：
0A. The ICW subscriber terminates the Internet connection.
0A。ICW用户终止Internet连接。
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.
0B。当ICW服务器没有收到来自ICW客户端的定期在线通知时，它确定Internet连接已终止。
1. The ICW Server sends an un-register message to the SCGF.
1. ICW服务器向SCGF发送取消注册消息。
1A. The SCGF translates the un-register message to an SCP internal API message.
1A。SCGF将un register消息转换为SCP内部API消息。
2. The SCGF sends the un-register message to the SCF.
2. SCGF向SCF发送取消注册消息。
2A. The SCF/SDF authorizes the subscriber with the directory number based on the un-registration information.
2A。SCF/SDF根据未注册信息使用目录号授权订户。
2B. The SCF/SDF records the Internet off-line status for that ICW Client.
2B。SCF/SDF记录该ICW客户端的Internet脱机状态。
3. The SCF/SDF sends a user un-registration response to the SCF/SCGF.
3. SCF/SDF向SCF/SCGF发送用户取消注册响应。
3B. The SCGF translates the user un-registration response to a PINT message.
3B。SCGF将用户取消注册响应转换为PINT消息。
4. The SCGF relays the user un-registration response to the ICW Server.
4. SCGF将用户取消注册响应转发给ICW服务器。
4A. The ICW Server records the Internet off-line status for the ICW Client (subscriber) in the data base.
4A。ICW服务器在数据库中记录ICW客户端（订户）的Internet脱机状态。
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.
朗讯技术在线通信中心（OCC）是一个基于智能网（IN）的平台，支持互联网呼叫等待服务。其基本组件是OCC服务器和OCC客户端，在体系结构一节中有详细描述。OCC服务器通过明文会话发起协议（SIP）消息通过安全内部网与PSTN实体进行交互[2]。OCC服务器通过加密的SIP消息与PC客户端进行交互。
The OCC Server run-time environment effectively consists of two multi-threaded processes responsible for Call Registration and Call Notification services, respectively.
OCC服务器运行时环境实际上由两个多线程进程组成，分别负责呼叫注册和呼叫通知服务。
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.)
OCC呼叫登记服务由最终用户的PC（或互联网设备）启动。通过这些，订户注册他或她的端点并激活通知服务。（严格来说，注册服务不是烈酒服务，而是一种品脱服务。）
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
所有OCC呼叫通知服务均由PSTN发起。这些服务的一个共同特点是通过互联网通知用户来电，而不影响调制解调器已经使用的线路。（典型的呼叫等待音会中断互联网连接，标准做法是为用户禁用“旧”PSTN呼叫等待服务
duration of the call in support of the Internet connection between the end-user and the ISP.)
支持最终用户和ISP之间Internet连接的呼叫持续时间。）
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.
就呼叫处理而言，OCC支持第2节所述的所有功能。
+------------+
| 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 |
| |
+-------------------+
+------------+
| 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
图8：朗讯OCC物理架构
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
图8描述了与OCC操作相关的联合PSTN/互联网物理架构。紧凑型服务节点（CSN）和SCP是朗讯对ITU-T IN建议（特别是定义了这些实体的建议Q.1205）的实施，并根据Bellcore的高级
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.
智能网络（AIN）1.0版），并配备其他功能。中央局（CO）可以是支持综合业务数字网（ISDN）主速率接口（PRI）和允许其与CSN互通的呼叫转发功能的任何交换机。或者，为了与SCP互通，它需要是一个服务内交换点（SSP）。在后一种情况下，中央局通过应用层的7号信令系统（SS7）和INAP连接到SCP。
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.
服务管理系统（SMS）负责供应SCP、CSN和中央办公室。特别是，为了支持互联网呼叫等待，必须规定中央办公室根据终止尝试触发器（TAT）将终止尝试查询定向至OCC SCP SPA对应的子系统号码。此外，每个用户的用户目录号（DN）、个人识别号（PIN）和语言ID都被设置到SCP实时数据库（RTDB）的OCC用户条目中。图9显示了RTDB条目的结构。
+-------------------------------------------------------+
|DN | PIN | IP Address | Session Key | CNF | Language ID|
+-------------------------------------------------------+
+-------------------------------------------------------+
|DN | PIN | IP Address | Session Key | CNF | Language ID|
+-------------------------------------------------------+
Field Descriptions:
字段说明：
(DN) Directory Number - the subscriber's telephone number
（DN）目录号-用户的电话号码
(PIN) Personal Identification Number - the subscriber's password
（PIN）个人识别号-用户密码
IP Address - Internet Protocol Address of the subscriber
IP地址-订阅服务器的Internet协议地址
(CNF) Call Notification In Progress Flag (boolean) - the flag indicating if an attempt to notify the subscriber of a call is currently in progress
（CNF）呼叫通知进行中标志（布尔）-指示当前是否正在尝试通知用户呼叫的标志
Session Key - unique identifier for the current registration session of the subscriber
会话密钥-订阅服务器当前注册会话的唯一标识符
Language ID - language identifier for the subscriber
Language ID—订阅服务器的语言标识符
Figure 9: Structure of the RTDB Subscriber Record
图9:RTDB订户记录的结构
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 establish and provide the part of the voice path over IP. The Central Office is explicitly connected to the VoIP Gateway via the
中心局、SMS、CSN和SCP是架构中唯一的PSTN元素。其他要素是ITU-T建议H.323中定义的VoIP网关和网守，其作用是建立和提供IP语音路径的一部分。中央办公室通过网络连接到VoIP网关
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.
ISDN PRI连接。在此体系结构中，CSN、VoIP网关和VoIP网守是唯一连接到Internet的实体，每个连接都受到防火墙的保护。CSN和SCP通过安全的IP内联网互连。网络中可能有多个CSN或SCP（或两者都有）（而且SCP是成对的，通过X.25互连），但这些细节对于为本文档选择的描述级别并不重要。然而，我们注意到，通过使用备用节点来实现负载平衡和故障适应已被纳入该体系结构。
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).
当有人试图呼叫该用户时，服务于该用户的中央局中断正常的终止处理，并通知SCP，SCP反过来可以检查该用户是否已注册他（或她）已登录到Internet。利用智能网络所特有的服务逻辑的标准化分层，中央办公室将做到这一点，而无需安装或开发OCC专用的任何中央办公室软件。当存在指向订阅者的目录号的终止尝试（即，TAT）时，中央局被简单地设置为查询SCP。（请注意，中央局没有到SCP的承载电路连接，只有通过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.
SCP和CSN之间的TCP/IP通信利用安全的内部网。当然，假定订户只能访问互联网。
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.
智能网络实体SCP和CSN确实有OCC相关软件。OCC服务器在CSN上实现。此外，SCP上还安装了一个服务包应用程序（SPA）。另一个SPA位于CSN中，仅当用户选择使用IP语音接受传入呼叫时才需要。
The OCC Server is a collection of Java servers on the CSN whose responsibilities include:
OCC服务器是CSN上Java服务器的集合，其职责包括：
o Listening for incoming Call Notification (TCP/IP) messages from the SCP SPA.
o 侦听来自SCP SPA的传入呼叫通知（TCP/IP）消息。
o De-multiplexing/multiplexing incoming Call Notification messages sent from the SCP SPA.
o 解复用/复用从SCP SPA发送的传入呼叫通知消息。
o Relaying messages between the OCC Client and the SCP SPA.
o 在OCC客户端和SCP SPA之间中继消息。
o Listening for and authentication of OCC Client requests for service registration.
o 监听和验证OCC客户端的服务注册请求。
o Handling encryption/decryption of messages exchanged with the OCC Client, and generating session-specific encryption/decryption keys.
o 处理与OCC客户端交换的消息的加密/解密，并生成特定于会话的加密/解密密钥。
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.
OCC客户端是在用户PC上运行的软件组件的集合。其组件包括SIP用户代理服务器（处理与OCC服务器的SIP消息交换并调用呼叫通知弹出窗口）和监控点对点协议（PPP）的守护进程操作，并负责启动和停止SIP用户代理服务器。
The OCC Server uses distinct TCP/IP ports configured on the CSN to
OCC服务器使用CSN上配置的不同TCP/IP端口来
o Listen for incoming SIP REGISTER messages (in support of registration service) sent from the OCC Client.
o 侦听从OCC客户端发送的传入SIP注册消息（支持注册服务）。
o Listen for incoming SIP INVITE messages (in support of call notification service) sent from the SCP.
o 侦听从SCP发送的传入SIP INVITE消息（支持呼叫通知服务）。
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.
在呼叫通知期间，SCP SPA是客户端，因此在OCC服务器启动后启动。SCP SPA和OCC服务器使用由SCP SPA启动的“固定”连接通过TCP/IP（通过安全内部网）交换SIP消息。此连接在SCP SPA从OCC服务器收到第一个SIP注册请求时启动，并且必须在SPA处于服务状态时保持优先。SCP SPA还支持在出现任何故障情况后重新启动连接。
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.
OCC服务器支持多线程。对于每个调用通知/调用处置事件，使用单独的线程来处理调用。此模型支持基于“每条消息”的多线程，其中从SCP SPA接收的每个启动消息（SIP INVITE）都使用单独的控制线程来处理调用。包含与原始启动消息相同的会话调用ID（包括称为“Call_index”的SPA实例和SCP主机名）的后续消息被路由到先前处理相应启动消息的同一线程。
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.
OCC服务器为每个呼叫通知/呼叫处理会话与OCC客户端动态打开一个新的TCP/IP套接字。此套接字连接使用运行OCC客户端软件的PC上的IP地址和预配置端口。
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
对于会话注册，OCC服务器动态打开与SCP SPA的TCP/IP会话。SCP SPA在预先配置的端口侦听OCC客户端通过发送的传入SIP寄存器消息
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.
OCC服务器。为了与OCC服务器交换SIP消息，OCC客户端使用CSN上预先配置的端口号和CSN的IP地址动态打开与OCC服务器的TCP/IP套接字连接。
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.
对于VoIP场景，CSN SPA作为客户端，与处理初始TAT查询的SCP动态打开TCP/IP会话。一旦CSN SPA成功进行关联并连接与VoIP回拨有关的两个传入呼叫分支，SIP 180振铃消息将被发送回实际SCP上运行的SCP SPA，该SCP SPA指示SSP将呼叫者转发到CSN。此SIP消息包含一个桥接呼叫分支拨打的VoIP回拨DN，向SCP SPA指示VoIP回拨DN已释放。
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.
1. 每个VoIP网关都配置有授权VoIP回拨DNs的列表，每个DNs在特定CSN上终止。当在线用户选择通过VoIP接收传入呼叫时，将使用这些特殊的DNs。特别是，它们帮助将呼出呼叫从订户的NetMeeting路由到SCP（大致同时）将呼入呼叫转发到的特定CSN。（这两个呼叫在CSN中加入，以将传入呼叫连接到订阅者的Netmeeting客户端。）此外，这些特殊DNs允许CSN关联并桥接正确的一对呼叫分支，以将呼叫订阅者的一方加入到来自订阅者Netmeeting客户端的呼叫中。
2. The subscriber calls a PSTN service provider and signs up for the service.
2. 用户呼叫PSTN服务提供商并注册该服务。
3. An active Terminating Attempt Trigger (TAT) is assigned to the subscriber's DN at the subscriber's central office.
3. 主动终止尝试触发器（TAT）分配给订阅服务器中央办公室的订阅服务器DN。
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.
4. PSTN服务提供商使用SMS为用户创建记录，并在SCP的OCC RTDB表中提供用户DN和PIN。
5. The subscriber is provided with the OCC Client software, a PIN and a file containing the OCC Server IP Addresses.
5. 向用户提供OCC客户端软件、PIN和包含OCC服务器IP地址的文件。
Finally, we describe the particular scenario of the OCC Call Disposition that involves voice over IP, which proceeds as follows:
最后，我们描述了OCC呼叫处理的特定场景，该场景涉及IP语音，具体如下：
1. The OCC subscriber clicks on "Accept VoIP".
1. OCC用户点击“接受VoIP”。
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.
2. OCC客户端向OCC服务器发送“SIP 380替代服务”消息。该消息包括对回拨DN的引用，该回拨DN最终将由CSN用于将连接到用户（通过VoIP网关）的呼叫分支（即将由用户的NetMeeting发起）与连接到呼叫方的PSTN呼叫分支相关联。
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.
3. OCC服务器关闭与OCC客户端的TCP/IP会话，并向SCP SPA发送包含回拨DN的“SIP 380替代服务”消息。
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.
4. SCP SPA指示中央局将传入用户的呼叫转发到CSN。此指令包括回调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.
5. SSP将调用方转发到引用回拨DN的CSN。请注意，当用户收到来电尝试的警报时，最初由SCP分配给OCC客户端的回拨DN，在客户端选择通过VoIP接收呼叫时，流向OCC服务器旁边，然后流向SCP，然后，与SCP命令关联到中央局，将传入呼叫转发到CSN，然后与该转发呼叫关联到CSN上的OCC服务器。
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.
6. 同时，OCC客户端从呼叫通知期间接收的SIP INVITE消息中提取1）VoIP回拨DN，并从其属性文件中提取H323UID和H323PIN值，并更新“netmtg.cnf”文件。
7. The NetMeeting application is launched and sets up a connection with the VoIP Gateway.
7. NetMeeting应用程序启动并与VoIP网关建立连接。
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.
8. 一旦NetMeeting和VoIP网关之间建立了连接，NetMeeting将发起一个电话呼叫，并将回拨DN作为目标DN传递给VoIP网关。
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.
9. VoIP网关咨询VoIP网关管理员，并通过验证H323UID和H323PIN值以及确保被调用的DN（即回拨DN）被授权使用来验证NetMeeting呼叫。
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.
10. 通过身份验证步骤后，VoIP网关（通过PSTN）拨打回拨DN并连接到CSN。CSN注意到它是由特定的回调DN到达的。
11. The CSN bridges the Calling and Called parties together by matching on the basis of the Call Back DN.
11. CSN通过基于回拨DN的匹配将主叫方和被叫方连接在一起。
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.
12. CSN通知SCP（SIP 180振铃）状态并引用回拨DN，以便SCP可以将其重新用于其他呼叫。
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.
13. 如果中央局支持这两个B通道传输（朗讯、北电，或许还有其他中央局供应商的传输），则可以进行优化。CSN可以让中心局重新安排新连接呼叫的拓扑结构，使其仅流经中心局，而不再流经CSN。
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.
ICW服务的NEC实现基于。通过SPIRITS服务器和ICW客户端，来电将通过弹出屏幕对话框呈现给用户。此对话框通知用户呼叫到达时间以及主叫方的号码和名称（如果可用）。呼叫到达时也会伴有声音指示。
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.
用户将能够通过各种服务设置选项自定义其服务。在Internet会话期间向用户提供的所有呼叫都将记录在呼叫日志中。
Other features include Multiple call arrival management with which each new call arrival will generate its own pop-up dialogue box and audible indication.
其他功能包括多个呼叫到达管理，每个新呼叫到达将生成自己的弹出对话框和声音指示。
Figure 10 depicts the NEC ICW system.
图10描述了NEC ICW系统。
====================================
|| 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)+-----+ || | CO | ||
--------------------| |-------
/ || +------+ || \
/--\ / || P S T N || \ /--\
()/\() / =================== \ ()/\()
_/__\___/ \______/__\_
====================================
|| 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)+-----+ || | CO | ||
--------------------| |-------
/ || +------+ || \
/--\ / || P S T N || \ /--\
()/\() / =================== \ ()/\()
_/__\___/ \______/__\_
ICW Subscriber Calling Party
ICW用户呼叫方
Legend:
ISP : Internet Service Provider
W3S : WWW Server
SCP : Service Control Point(acts as SPIRITS Client)
SSP : Service Switching Point
CO : Central Office
M/D : Modem
Legend:
ISP : Internet Service Provider
W3S : WWW Server
SCP : Service Control Point(acts as SPIRITS Client)
SSP : Service Switching Point
CO : Central Office
M/D : Modem
Traffic:
--- : PSTN Voice Traffic
... : PPP(IP traffic)
-..-: Signaling Traffic
Traffic:
--- : PSTN Voice Traffic
... : PPP(IP traffic)
-..-: Signaling Traffic
Interfaces:
p0 : SPIRITS Server-SCP(SPIRITS Client) interface
p1 : SPIRITS Server-ICW Client interface
p2 : ICW Client-W3S interface
(Web access through HTTP)
p3 : SCP-SSP interface(INAP)
p4 : SSP-CO interface(ISUP)
Interfaces:
p0 : SPIRITS Server-SCP(SPIRITS Client) interface
p1 : SPIRITS Server-ICW Client interface
p2 : ICW Client-W3S interface
(Web access through HTTP)
p3 : SCP-SSP interface(INAP)
p4 : SSP-CO interface(ISUP)
Figure 10: the NEC ICW system
图10:NEC ICW系统
The description below provides the necessary steps to initiate the ICW service on a CO line, and how the ICW service is applied to an incoming call based on the above architecture:
下面的描述提供了在同一线路上启动ICW服务的必要步骤，以及如何基于上述体系结构将ICW服务应用于传入呼叫：
1. The CO line is primed for the ICW service when the customer connects to their ISP by inserting a special activation code (e.g., *54) prefix in front of the ISP Directory Number.
1. 当客户通过在ISP目录号前插入一个特殊的激活码（例如，*54）前缀连接到他们的ISP时，CO线路为ICW服务准备就绪。
2. The ICW service is activated when the user opens a secured session from an ICW client to the SPIRITS server. Once a session is open, the SPIRITS server will know the relationship between the line and the PC (i.e., it will know the Directory Number of the user's Internet line and the user's IP Address).
2. 当用户打开从ICW客户端到服务器的安全会话时，ICW服务被激活。一旦会话打开，SPIRITS服务器将知道线路和PC之间的关系（即，它将知道用户互联网线路的目录号和用户的IP地址）。
3. When a call arrives at a busy Internet line, the SSP will trigger the ICW service. The SCP which acts as the SPIRITS client will inform the SPIRITS server that a call is terminating to a busy Internet line. The message will include the Caller ID and Calling Line Identify Restriction (CLIR) Status of the calling party, and DN of the busy line.
3. 当呼叫到达繁忙的互联网线路时，SSP将触发ICW服务。充当SPIRITS客户端的SCP将通知SPIRITS服务器呼叫正在终止至繁忙的互联网线路。消息将包括主叫方的主叫ID和主叫线路标识限制（CLIR）状态，以及占线的DN。
4. The SPIRITS server will verify that if an ICW session has been established for the busy line. If so, the SPIRITS server will communicate with the user's ICW client application. The user will receive a real-time pop-up dialogue box including the Calling Name and Number of the Calling Party if available. The user will then select one of the following call management options:
4. SPIRITS服务器将验证是否已为繁忙线路建立ICW会话。如果是这样，SPIRITS服务器将与用户的ICW客户端应用程序通信。用户将收到一个实时弹出对话框，其中包括主叫姓名和主叫方号码（如果可用）。然后，用户将选择以下呼叫管理选项之一：
- Answer the call (the Internet connection will be automatically dropped and the phone will ring) - Send the call to Voice Mail - Forward the call to another destination - Ignore the call
- 接听电话（Internet连接将自动断开，电话将响起）-将电话发送到语音邮件-将电话转接到其他目的地-忽略电话
5. When the Internet user has made a selection, the ICW client application will transmit this to the SPIRITS server. The SPIRITS server will instruct the PSTN via the SCP how to handle the call.
5. 当互联网用户做出选择时，ICW客户端应用程序将把它传输到服务器。SPIRITS服务器将通过SCP指示PSTN如何处理呼叫。
The physical connection between the SCP and the SPIRITS server will be via a LAN/WAN. The logical connection will use the UDP/IP communications as defined in RFC 768 and RFC 1122.
SCP和SPIRITS服务器之间的物理连接将通过LAN/WAN实现。逻辑连接将使用RFC 768和RFC 1122中定义的UDP/IP通信。
If a socket connection is not currently established, the SCP will periodically try to open a connection. The SCP routing tables will be configured so that all available connections to a SPIRITS server are used.
如果当前未建立套接字连接，SCP将定期尝试打开连接。将配置SCP路由表，以便使用到服务器的所有可用连接。
Two different types of message are used between the SCP and the SPIRITS server: "Connection Management Message Type" and the "Data Message Type". These messages will carry the remote operation messages which are based on ITU-T Q.1228 SCF-SCF interface with some NEC proprietary extensions.
SCP和SPIRITS服务器之间使用两种不同类型的消息：“连接管理消息类型”和“数据消息类型”。这些信息将携带基于ITU-T Q.1228 SCF-SCF接口和一些NEC专有扩展的远程操作信息。
NEC also has a plan to support SIP/SDP-based protocols for the SPIR-ITS client-server interface in the near future.
NEC还计划在不久的将来为SPIR-ITS客户机-服务器接口支持基于SIP/SDP的协议。
Connection management messages are to support functions related to the opening and closing of connections and monitoring connections to ensure reliable communications are maintained between the SCP and a SPIRITS server. The SCP is responsible for establishing a connection to a SPIRITS server. A connection can be closed by either the SCP or the SPIRITS server.
连接管理消息用于支持与连接的打开和关闭以及监控连接相关的功能，以确保SCP和服务器之间保持可靠的通信。SCP负责建立与服务器的连接。SCP或SPIRITS服务器都可以关闭连接。
The "Connection Management Message Type" includes the following operations:
“连接管理消息类型”包括以下操作：
- scfBind - scfUnbind - activitytest
- scfBind-scfUnbind-活性测试
Opening a Connection
打开连接
If a connection is not open to an SPIRITS server, the SCP will periodically try to open a connection until it is opened. If after a pre-determined number of attempts the connection is not opened, the socket connection will be released and then re-established and then the attempt to open the connection will be repeated.
如果与SPIRITS服务器的连接未打开，SCP将定期尝试打开连接，直到打开为止。如果在预先确定的尝试次数后连接未打开，则将释放套接字连接，然后重新建立，然后将重复尝试打开连接。
The sequence for opening a connection is:
打开连接的顺序是：
1. SCP will transmit a scfBind invokation message to the SPIRITS server. This message also carries the version information and activity test interval.
1. SCP将向服务器发送scfBind调用消息。此消息还包含版本信息和活动测试间隔。
2. The SPIRITS server, upon receiving an invokation of the scfBind from a particular SCP, will reset all the data concerning the connection and then responds with either a return result containing the Web Server Identification number or a return error with a reason.
2. SPIRITS服务器在收到来自特定SCP的scfBind调用后，将重置与连接有关的所有数据，然后以包含Web服务器标识号的返回结果或带有原因的返回错误进行响应。
3. When the SCP receives a return result, if the ID number does not match the number configured in the SCP, then a scfUnbind will be sent indicating the wrong ID number. If the SCP receives nothing or a return error is received, then the scfBind will be retried after a pre-determined period of time.
3. 当SCP收到返回结果时，如果ID号与SCP中配置的编号不匹配，则将发送scfUnbind，指示错误的ID号。如果SCP未收到任何信息或收到返回错误，则将在预定时间段后重试scfBind。
4. Once the SCP has received a return result, the SCP will send Handling Information Request or Activity Test.
4. 一旦SCP收到返回结果，SCP将发送处理信息请求或活动测试。
Upon receiving an invokation of activityTest, the SPIRITS server should reply with a return result of activityTest. If the SPIRITS server does not receive any invokation messages of Handling Information Request or Activity Test from the SCP for four times the Activity Test Interval value in milliseconds, the SPIRITS server should then close the connection.
收到activityTest调用后，SPIRITS服务器应返回activityTest的结果。如果SPIRITS服务器在活动测试间隔值的四倍（以毫秒为单位）内没有从SCP接收任何处理信息请求或活动测试的调用消息，则SPIRITS服务器应关闭连接。
To close a connection an invokation of the scfUnbind is sent by either the SCP or SPIRITS server to the remote end. When an invokation message of the scfUnbind is received, the receiving end should terminate the connection.
要关闭连接，SCP或SPIRITS服务器将调用scfUnbind发送到远程端。当接收到scfUnbind的调用消息时，接收端应终止连接。
scfBind
scfBind
The scfBind operation is used to open the connection between the SCP and the SPIRITS server. The SCP will send the SPIRITS server an invokation of the scfBind to establish an association. If the SPIRITS server is ready to handle the request then it should respond with a return result.
scfBind操作用于打开SCP和服务器之间的连接。SCP将向SPIRITS服务器发送scfBind调用以建立关联。如果SPIRITS服务器已经准备好处理请求，那么它应该以返回结果进行响应。
The return result of scfBind contains the identifier of the SPIRITS server. If the SCP receives the return result where the identification of the SPIRITS server does not match that registered against the SPIRITS server, then the SCP will send an invokation of the scfUnbind indicating an incorrect identifier was received.
scfBind的返回结果包含服务器的标识符。如果SCP接收到返回结果，其中SPIRITS服务器的标识与针对SPIRITS服务器注册的标识不匹配，则SCP将发送scfUnbind调用，指示接收到错误的标识符。
If the SPIRITS server is not ready to handle the request or cannot handle the version, then it should respond with a return error.
如果SPIRITS服务器没有准备好处理请求或无法处理版本，那么它应该以返回错误进行响应。
scfUnbind
scfUnbind
The scfUnbind operation is used to close the connection between the SCP and the SPIRITS server. Either the SCP or the SPIRITS server can invoke this operation.
scfUnbind操作用于关闭SCP和服务器之间的连接。SCP或SPIRITS服务器都可以调用此操作。
Upon receiving an invokation message the receiving end should terminate the connection.
接收到调用消息后，接收端应终止连接。
activityTest
活动测试
If the SCP has not sent a Data Message for the time period specified by the "Activity Test Interval", it will send an invokation message of activityTest. When the SPIRITS server receives such an invokation, it will reply with a return result message of activityTest.
如果SCP在“活动测试间隔”指定的时间段内未发送数据消息，它将发送activityTest的调用消息。当SPIRITS服务器接收到这样的调用时，它将用返回结果消息activityTest进行响应。
Its contents should be retained by the SPIRITS server. They are to be echoed back in the return result so that the message reply time can be calculated.
其内容应由SPIRITS服务器保留。它们将在返回结果中回显，以便计算消息回复时间。
SCPs use the following operations, which are sent to the SPIRITS server via a Data-Message-Type message, to request execution of some service procedure or notification of an event that takes place at the SCPs:
SCP使用以下操作（通过数据消息类型消息发送至SPIRITS服务器）请求执行某些服务过程或通知SCP上发生的事件：
o handlingInformationRequest
o 处理信息请求
The handlingInformationRequest message will request a SPIRITS server the execution of some service procedure.
handlingInformationRequest消息将请求SPIRITS服务器执行某些服务过程。
o handlingInformationResult
o 处理信息结果
The handlingInformationResult message will show the SCP the result of the execution, which was carried out by the SPIRITS server.
handlingInformationResult消息将向SCP显示由SPIRITS服务器执行的执行结果。
o confirmedNotificationProvided
o 已提供确认通知
The confirmedNotificationProvided message will indicate to the SPIRITS server of an event, which takes place at the SCP. If the confirmedNotificationProvided indicating 'caller abandon' is received, the SPIRITS server will inform the client of the caller abandon and send the SCP a return result for the confirmedNotificationProvided.
confirmedNotificationProvided消息将向SPIRITS服务器指示在SCP发生的事件。如果收到指示“呼叫者放弃”的确认通知，SPIRITS服务器将通知客户端呼叫者放弃，并向SCP发送所提供确认通知的返回结果。
The invoked operation has always a response which is either a return result of the operation or an invokation of another operation.
被调用的操作总是有一个响应，它要么是该操作的返回结果，要么是另一个操作的调用。
If a Data Message is not replied to within a pre-determined time out period then the message will be resent a number of specified times. Once the number of times has been exceeded, if another node exists, the message will be sent to another node if it is available. If all available SPIRITS servers have been queried then Message Time out will be returned to the calling process.
如果在预先确定的超时时间内未回复数据消息，则该消息将重新发送指定次数。一旦超过次数，如果存在另一个节点，则消息将被发送到另一个节点（如果该节点可用）。如果查询了所有可用的服务器，则消息超时将返回到调用进程。
If an invokation of the handlingInformationResult is received with the cause=63 (Service not available), the handlingInformationRequest will be sent to another node if it is available. If all available SPIRITS severs have been queried then cause=63 will be returned to the calling process.
如果接收到调用handlingInformationResult的原因=63（服务不可用），handlingInformationRequest将被发送到另一个节点（如果可用）。如果查询了所有可用服务器，则cause=63将返回到调用进程。
The following is a list of the application messages that are sent via the secure protocol (refer to section 5.3.3):
以下是通过安全协议发送的应用程序消息列表（请参阅第5.3.3节）：
o VersionInfo (ICW client -> SPIRITS server)
o VersionInfo（ICW客户端->服务器）
Indicate the current version of ICW client software. The SPIRITS server uses this information to determine if the client software is out of date.
指示ICW客户端软件的当前版本。SPIRITS服务器使用此信息确定客户端软件是否过期。
o VersionInfoAck (SPIRITS server -> ICW client)
o VersionInfoAck（服务器->ICW客户端）
If the VersionInfo message from an ICW client indicates to a SPIRITS server that it is an out of date version, the URL information is returned within the VersionInfoAck message for use in downloading the newer version. If the client software is up to date, the message simply indicates so and does not include any URL information.
如果来自ICW客户端的VersionInfo消息向SPIRITS服务器指示该版本已过期，则会在VersionInfo确认消息中返回URL信息，以用于下载较新版本。如果客户机软件是最新的，则消息仅表明是最新的，并且不包括任何URL信息。
o CallArrival (SPIRITS server -> ICW client)
o CallArrival（服务器->ICW客户端）
Sent by the server to tell the client someone has called the DN.
由服务器发送，告知客户端有人调用了DN。
o CallID
o 呼唤
An identifier for this call. Unique in the domain of this client/server session.
此呼叫的标识符。此客户端/服务器会话的域中唯一。
o CallingNumber
o 呼叫号码
o CallingName
o 叫名字
The name of the calling party is sent to the Client Application from the SPIRITS server. When available, the name is sent as a 15-character string. If the name is unavailable it is sent as "Name Unavailable". If the calling party has CLIR set, it is sent as empty (" ").
调用方的名称将从服务器发送到客户端应用程序。如果可用，名称将作为15个字符的字符串发送。如果名称不可用，则将其作为“名称不可用”发送。如果呼叫方设置了CLIR，则将以空（“”）的形式发送。
o CallConnect (ICW client -> SPIRITS server)
o CallConnect（ICW客户端->服务器）
If a corresponding CallConnect is not received within a certain period after sending a CallArrival, the SPIRITS server will behave as though a CallConnect, Handling=Ignore had been received.
如果在发送CallArrival后的特定时间段内未收到相应的CallConnect，则SPIRITS服务器将表现为收到CallConnect，Handling=Ignore。
o CallLost (SPIRITS server -> ICW client)
o CallLost（服务器->ICW客户端）
Sent by server to cancel a CallArrival before a CallConnect is received by the server.
由服务器发送以在服务器接收CallConnect之前取消CallArrival。
5.3.3. Secure Reliable Hybrid Datagram Session Protocol (SRHDSP) for Use Between ICW Client Application and SPIRITS Server
5.3.3. ICW客户端应用程序和服务器之间使用的安全可靠的混合数据报会话协议（SRHDSP）
In principle the solution involves session initiation over SSL (meeting requirements for standards based security) after which the SSL session is closed, thereby reducing the number of simultaneous TCP/IP sessions. The rest of the session is communicated over UDP/IP, secured using keys and other parameters exchanged securely during the SSL session.
原则上，该解决方案涉及通过SSL启动会话（满足基于标准的安全性要求），然后关闭SSL会话，从而减少同时TCP/IP会话的数量。会话的其余部分通过UDP/IP进行通信，使用SSL会话期间安全交换的密钥和其他参数进行保护。
The ICW client initiates an SRHDSP session, by reserving a UDP/IP port, and opening an SSL session with the service (e.g., ICW) on the service's well known SSL/TCP port. After establishing the SSL Session, the ICW client sends the server its IP address, the reserved UDP port number, and the set of supported symmetric key algorithms.
ICW客户端通过保留UDP/IP端口并在服务的已知SSL/TCP端口上打开与服务（例如ICW）的SSL会话来启动SRHDSP会话。建立SSL会话后，ICW客户端向服务器发送其IP地址、保留的UDP端口号和支持的对称密钥算法集。
The server responds with a symmetric key algorithm chosen from the set, the server's UDP port for further communication, heartbeat period, and the value to use for the sequencing window.
服务器使用从集合中选择的对称密钥算法、用于进一步通信的服务器UDP端口、心跳周期和用于排序窗口的值进行响应。
The client then generates a symmetric key using the selected algorithm and transmits this to the server. The SSL session is then closed and the SRHDSP session is considered open.
然后，客户端使用所选算法生成对称密钥，并将其传输到服务器。然后关闭SSL会话，并将SRHDSP会话视为打开。
Application, and subsequent session management messages use symmetric signaling. That is, the signaling is the same whether the client is sending a message or the server is sending a message.
应用程序和后续会话管理消息使用对称信令。也就是说，无论客户端正在发送消息还是服务器正在发送消息，信令都是相同的。
The message packets are transmitted securely. The protocol corrects for lost, duplicated and out of sequence packets.
消息包被安全地传输。该协议纠正丢失、重复和无序数据包。
The client or server may close the session.
客户端或服务器可能会关闭会话。
A session is closed using a Close message including the next sequence number, and encrypted with the agreed key.
使用包含下一个序列号的关闭消息关闭会话，并使用约定的密钥进行加密。
The receiver, on processing (as opposed to receiving) a Close message, should set a timer, when the timer expires all details of the session should be forgotten. The timer is to allow for retransmission of the close if the Ack gets lost, we still need to be able to decrypt the subsequent retransmission and re-acknowledgment.
接收方在处理（而不是接收）关闭消息时，应设置计时器，当计时器过期时，应忘记会话的所有细节。计时器是为了允许重新传输关闭消息。如果Ack丢失，我们仍然需要能够解密随后的重新传输和重新确认。
If any message other than a close is received after a close is processed, it is ignored.
如果在处理关闭后收到除关闭以外的任何消息，则忽略该消息。
The system implemented by Telia in cooperation with Nortel Networks is designed to support services that execute before the end-to-end media sessions are established. These services include, for example:
Telia与北电网络合作实施的系统旨在支持在建立端到端媒体会话之前执行的服务。这些服务包括，例如：
- call transfer and number portability for redirecting calls - call waiting and call offering for announcing a pending call - call screening and don't disturb for filtering incoming calls - automatic call distribution and 800-services for selecting termination point
- 呼叫转移和号码转移功能，用于重定向呼叫-呼叫等待和呼叫服务，用于宣布挂起的呼叫-呼叫屏蔽和无干扰，用于过滤传入呼叫-自动呼叫分配和800服务，用于选择终止点
The Telia/Nortel system aims to allow service providers to develop the services mentioned above. Presently, prototypes for online incoming call disposition and automatic incoming call disposition (described in Section 2) have been developed to prove the concept.
Telia/Nortel系统旨在让服务提供商开发上述服务。目前，已经开发了在线来电处理和自动来电处理的原型（第2节中描述）来证明这一概念。
In the Telia/Nortel architecture, services run on top of SIP Redirect Servers. The distributed nature of SIP enables these servers to be hosted, for example, by an enterprise server, a Service Provider's server cluster, a user's desktop PC, or even by a hand-held cordless device.
在Telia/Nortel体系结构中，服务运行在SIP重定向服务器之上。SIP的分布式特性使这些服务器能够由企业服务器、服务提供商的服务器集群、用户的台式PC甚至手持无绳设备托管。
The SIP Redirect Server receives a SIP INVITE message for each call regardless of which network the call is being set up in. The server MAY apply any kind of service logic in order to decide on how to respond to the invitation. Service logic may interact with the user to allow the user to specify how to handle a call such as described in Section 2. This, however, is not the focus of the Telia/Nortel system.
SIP重定向服务器为每个呼叫接收SIP INVITE消息，而不管呼叫在哪个网络中设置。服务器可以应用任何类型的服务逻辑来决定如何响应邀请。服务逻辑可与用户交互以允许用户指定如何处理如第2节所述的呼叫。然而，这并不是Telia/Nortel系统的重点。
The general idea behind the architecture is to create services as if all communication was based on IP and all clients and servers were SIP enabled. This of cause is not true in existing telecommunications networks. Hence, a new type of network element, the Service Control Gateways (SCG) hides the true situation from the services.
该体系结构背后的总体思想是创建服务，就好像所有通信都基于IP，所有客户端和服务器都支持SIP一样。当然，这在现有的电信网络中是不正确的。因此，一种新型的网元，即服务控制网关（SCG），对服务隐藏了真实情况。
SCGs convert network-specific call control signaling to SIP messages and vice versa. A SCG behaves as a regular SIP User Agent (UA) towards the services and as a network-specific service control node in the network where the call is being set up. For example, when connecting to a GSM network, the SCG can play the role of an SCP or a MAP or an ISUP proxy. The specific role depends on what service triggers are being used in the GSM network.
SCG将特定于网络的呼叫控制信令转换为SIP消息，反之亦然。SCG充当针对服务的常规SIP用户代理（UA）以及正在建立呼叫的网络中的特定于网络的服务控制节点。例如，当连接到GSM网络时，SCG可以扮演SCP、MAP或ISUP代理的角色。具体角色取决于GSM网络中使用的服务触发器。
SCGs handle protocol conversions but not address translation, such as telephone number to SIP URL, which is handled by a regular SIP Server to keep the SCG as simple as possible.
SCG处理协议转换，但不处理地址转换，例如从电话号码到SIPURL的转换，这由常规SIP服务器处理，以使SCG尽可能简单。
Consider a service example of number portability. A conventional number portability implementation in a mobile Circuit Switched Network (CSN) uses INAP messages to carry number queries to a network-internal data base application. Here, a SCG and a high-performance SIP Redirect Server, referred to as the Number Server (NS), have replaced the data base typically located in an SCP. (See Figure 11.)
考虑一个数字便携性服务示例。移动电路交换网络（CSN）中的传统号码可移植性实现使用INAP消息将号码查询传送到网络内部数据库应用程序。这里，SCG和高性能SIP重定向服务器（称为数字服务器（NS））已经取代了通常位于SCP中的数据库。（参见图11。）
+-----------+ INAP +-----+ SIP +--------------------------+
| CSN node |--------| SCG |-------| NS (SIP Redirect Server) |
+-----------+ +-----+ +--------------------------+
+-----------+ INAP +-----+ SIP +--------------------------+
| CSN node |--------| SCG |-------| NS (SIP Redirect Server) |
+-----------+ +-----+ +--------------------------+
Figure 11: An Architecture for Number Portability
图11：数字可移植性的体系结构
The INAP IDP message that carries the number query is converted to a SIP INVITE message by the SCG and is then forwarded to the NS (SIP Redirect Server).
携带号码查询的INAP IDP消息由SCG转换为SIP INVITE消息，然后转发到NS（SIP重定向服务器）。
If the called number is not registered, then the NS will return "404 Not Found". The SCG interprets this as "non ported number" and returns a CON message to the CSN network, making it connect the call to the called number.
如果被叫号码未注册，则NS将返回“404未找到”。SCG将其解释为“非端口号码”，并向CSN网络返回CON消息，使其将呼叫连接到被叫号码。
If the number is ported and hence registered, then the NS will return "301 Moved Permanently" with a TEL URL (routing number) in the contact field. The SCG then returns a CON message to the CSN network, making it connect the call to the number that was conveyed in the contact field.
如果号码被移植并因此注册，则NS将在联系人字段中返回“301永久移动”，并带有电话URL（路由号码）。然后，SCG向CSN网络返回CON消息，使其将呼叫连接到联系人字段中传送的号码。
The solution above enables the same Number Server to provide Number Portability to multiple networks by means of using multiple SCGs.
上述解决方案使同一号码服务器能够通过使用多个SCG向多个网络提供号码可移植性。
If we make the SIP server in the number portability example operate in proxy mode for selected numbers, then it will become a kind of service router, able to relay number queries to any SIP-Redirect-Server-based service anywhere, provided there is an IP connection to the host in concern. Figure 12 shows the arrangement.
如果我们让号码可移植性示例中的SIP服务器在选定号码的代理模式下运行，那么它将成为一种服务路由器，能够在任何地方将号码查询中继到任何基于SIP重定向服务器的服务，前提是存在到相关主机的IP连接。图12显示了这种安排。
+------+ INAP +-----+ SIP +----------------+ SIP +----------+
| CSN |------| SCG |-----| NS |-----| Service |
| node | | | |(redirect/proxy)| |(redirect)|
+------+ +-----+ +----------------+ +----------+
+------+ INAP +-----+ SIP +----------------+ SIP +----------+
| CSN |------| SCG |-----| NS |-----| Service |
| node | | | |(redirect/proxy)| |(redirect)|
+------+ +-----+ +----------------+ +----------+
Figure 12: SIP-Based Service Router
图12：基于SIP的服务路由器
Suppose that we connect a value-added service, such as a Personal Call Filtering service hosted by a user's desktop PC, to a certain telephone number. The INAP IDP message is converted to a SIP INVITE message by the SCG and is then forwarded to the NS, just as in the previous example. However, in this case, the number is registered with a reference to a SIP URL. This makes the Number Server proxy the SIP INVITE message to the registered URL, which is the address of the service.
假设我们将一个增值服务（例如由用户的台式PC托管的个人电话过滤服务）连接到某个电话号码。INAP IDP消息由SCG转换为SIP INVITE消息，然后转发到NS，如前一示例所示。但是，在这种情况下，该号码是通过对SIPURL的引用注册的。这使得Number Server将SIP INVITE消息代理到注册的URL，该URL是服务的地址。
The service responds as a SIP Redirect Server and the Personal Call Filtering service logic determines the response. The NS sends the response back to the SCG which converts the response to an appropriate INAP message. The response from the service is typically "302 Moved Temporarily" with a telephone number in the Contact field.
服务作为SIP重定向服务器响应，个人呼叫过滤服务逻辑确定响应。NS将响应发送回SCG，SCG将响应转换为适当的INAP消息。来自服务的响应通常是“302临时移动”，联系人字段中有电话号码。
If the response is 301 or 302, as the examples above suggest, then a telephone number is carried in the contact field. If the user can be reached via several different addresses, then all of them SHOULD be added to the response by means of multiple contact fields. The SCG then selects an address that is valid for the node or application that issued the number query.
如上述示例所示，如果响应为301或302，则在联系人字段中携带电话号码。如果可以通过几个不同的地址联系到用户，则应通过多个联系人字段将所有地址添加到响应中。然后，SCG选择对发出号码查询的节点或应用程序有效的地址。
As illustrated by the service examples, the Telia/Nortel system aims to allow the introduction of multi-network services without requiring multi-protocol support. The services hence operate in the same way regardless of in which network the call is made and common IP services can be shared across heterogeneous networks.
如服务示例所示，Telia/Nortel系统旨在允许在不需要多协议支持的情况下引入多网络服务。因此，无论在哪个网络中进行呼叫，服务都以相同的方式运行，并且公共IP服务可以在异构网络中共享。
+-----------+ +-------+ SIP +----+ ...... SIP +-----------+
| Network 1 |---| SCG 1 |-----| |---: :-----| Service A |
+-----------+ +-------+ | | : : +-----------+
| | : :
+-----------+ +-------+ SIP | | : : SIP +-----------+
| Network 2 |---| SCG 2 |-----| NS |---: :-----| Service B |
+-----------+ +-------+ | | : Any : +-----------+
| | : IP :
+-----------+ +-------+ SIP | | : net- : SIP +-----------+
| Network n |---| SCG n |-----| |---: work :-----| Service C |
+-----------+ +-------+ +----+ : : +-----------+
: :
+--------+ SIP : : SIP +-----------+
| SIP UA |-----------------------------: :-----| Service x |
+--------+ '......' +-----------+
+-----------+ +-------+ SIP +----+ ...... SIP +-----------+
| Network 1 |---| SCG 1 |-----| |---: :-----| Service A |
+-----------+ +-------+ | | : : +-----------+
| | : :
+-----------+ +-------+ SIP | | : : SIP +-----------+
| Network 2 |---| SCG 2 |-----| NS |---: :-----| Service B |
+-----------+ +-------+ | | : Any : +-----------+
| | : IP :
+-----------+ +-------+ SIP | | : net- : SIP +-----------+
| Network n |---| SCG n |-----| |---: work :-----| Service C |
+-----------+ +-------+ +----+ : : +-----------+
: :
+--------+ SIP : : SIP +-----------+
| SIP UA |-----------------------------: :-----| Service x |
+--------+ '......' +-----------+
Figure 13: Interconnecting Heterogeneous Networks via SIP
图13：通过SIP互连异构网络
The Telia/Nortel architecture uses security mechanisms available to ordinary SIP services, implemented as they would be in a pure SIP network. The architecture described here does not impose any additional security considerations.
Telia/Nortel体系结构使用普通SIP服务可用的安全机制，在纯SIP网络中实现。这里描述的体系结构没有强加任何额外的安全考虑。
General security issues that must be considered include interconnection of two different networks. SCGs must therefore include mechanisms that prevent destructive service control signaling from one network to the other. For example, a firewall-type
必须考虑的一般安全问题包括两个不同网络的互连。因此，SCG必须包括防止从一个网络到另一个网络的破坏性服务控制信令的机制。例如，防火墙类型
mechanism that can block a denial-of- service attack from an Internet user toward the PSTN.
阻止Internet用户向PSTN发起拒绝服务攻击的机制。
Overall, the SPIRITS security requirements are essentially the same as those for PINT [3, 4], which include, for example:
总的来说，烈酒的安全要求基本上与品脱酒相同[3,4]，其中包括，例如：
+ Protection of the PSTN from attacks from the Internet.
+ 保护PSTN免受来自Internet的攻击。
+ Peer entity authentication to allow a communicating entity to prove its identity to another in the network.
+ 对等实体身份验证，允许通信实体向网络中的另一个实体证明其身份。
+ Authorization and access control to verify if a network entity is allowed to use a network resource.
+ 验证是否允许网络实体使用网络资源的授权和访问控制。
+ Confidentiality to avoid disclosure of information (e.g., the end user profile information and data) without the permission of its owner.
+ 保密性，以避免未经所有者许可披露信息（例如，最终用户档案信息和数据）。
+ Non-repudiation to account for all operations in case of doubt or dispute.
+ 不可抵赖性，在出现疑问或争议时，对所有操作负责。
As seen in the previous sections, most implementations examined in this document have employed means (e.g., firewalls and encryption) to meet these requirements. The means are, however, different from implementation to implementation.
如前几节所述，本文档中检查的大多数实现都采用了一些方法（如防火墙和加密）来满足这些要求。然而，实施的手段各不相同。
This document has provided information relevant to the development of inter-networking interfaces between the PSTN and Internet for supporting SPIRITS services. Specifically, it described four existing implementations of SPIRITS-like services. Surveying these implementations, we can make the following observations:
本文件提供了PSTN和Internet之间用于支持服务的互联接口开发的相关信息。具体地说，它描述了四种现有的Spirit类服务的实现。考察这些实现，我们可以得出以下观察结果：
o The ICW service plays the role of a benchmark service. All four implementations can support ICW, with three specifically designed for it.
o ICW服务扮演着基准服务的角色。所有四种实现都可以支持ICW，其中三种是专门为ICW设计的。
o SIP is used in most of the implementations as the based communications protocol between the PSTN and Internet. (NEC's implementation is the only exception that uses a proprietary protocol. Nevertheless, NEC has a plan to support SIP together with the extensions for SPIRITS services.)
o SIP在大多数实现中用作PSTN和Internet之间基于IP的通信协议。（NEC的实现是唯一使用专有协议的例外。尽管如此，NEC计划支持SIP和SPIRITS服务的扩展。）
o All implementations use IN-based solutions for the PSTN part.
o 所有实现都使用PSTN部分基于IN的解决方案。
It is clear that not all pre-SPIRITS implementations inter-operate with each other. It is also clear that not all SIP-based implementations inter-operate with each other given that they do not support the same version of SIP. It is a task of the SPIRITS Working Group to define the inter-networking interfaces that will support inter-operation of the future implementations of SPIRITS services.
很明显，并非所有的预处理实现都是相互作用的。同样清楚的是，并非所有基于SIP的实现都相互操作，因为它们不支持相同版本的SIP。SPIRITS工作组的任务是定义将支持SPIRITS服务未来实现的互操作的互连接口。
[1] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, June 2000.
[1] Petrack，S.和L.Conroy，“PINT服务协议：电话呼叫服务IP接入的SIP和SDP扩展”，RFC 28482000年6月。
[2] Handley, H., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[2] Handley，H.，Schulzrinne，H.，Schooler，E.和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[3] Lu, H. (Ed.), Krishnaswamy, M., Conroy, L., Bellovin, S., Burg, F., DeSimone, A., Tewani, F., Davidson, D., Schulzrinne, H. and K. Vishwanathan, "Toward the PSTN/Internet Inter-Networking-- Pre-PINT Implementations", RFC 2458, November 1998.
[3] 卢，H.（编著），克里希纳斯瓦米，M.，康罗伊，L.，贝洛文，S.，伯格，F.，德西莫内，A.，特瓦尼，F.，戴维森，D.，舒尔兹林内，H.和K.维什瓦纳坦，“走向PSTN/互联网互联——PINT前的实施”，RFC 2458，1998年11月。
Igor Faynberg Lucent Technologies Room 4L-334 101 Crawfords Corner Road Holmdel, NJ, USA 07733-3030
Igor Faynberg-Lucent Technologies 4L-334室美国新泽西州霍姆德尔克劳福德角路101号07733-3030
Phone: +1 732 949 0137
EMail: faynberg@lucent.com
Phone: +1 732 949 0137
EMail: faynberg@lucent.com
Hui-Lan Lu Lucent Technologies Room 4L-317 101 Crawfords Corner Road Holmdel, NJ, USA 07733-3030
美国新泽西州霍姆德尔克劳福德角路101号惠兰路朗讯科技4L-317室07733-3030
Phone: +1 732 949 0321
EMail: huilanlu@lucent.com
Phone: +1 732 949 0321
EMail: huilanlu@lucent.com
John Voelker Lucent Technologies Room 1A-417 263 Shuman Blvd PO Box 3050 Naperville, IL, USA 60566-7050
约翰·沃克尔·朗讯科技公司1A-417室美国伊利诺伊州纳珀维尔市舒曼大道263号邮政信箱3050号60566-7050
Phone: +1 630 713 5538
EMail: jvoelker@lucent.com
Phone: +1 630 713 5538
EMail: jvoelker@lucent.com
Mark Weissman Lucent Technologies Room NE406B 200 Lucent Lane Cary, NC, USA 27511-6035
马克·韦斯曼·朗讯科技公司NE406B室，美国北卡罗来纳州朗讯巷200号，邮编27511-6035
Phone: +1 919 463 3258
EMail: maw1@lucent.com
Phone: +1 919 463 3258
EMail: maw1@lucent.com
Weizhong Zhang Lucent Technologies Room 01-A5-17 2000 Regency Parkway Cary, NC, USA 27511-8506
张伟忠朗讯科技有限公司01-A5-17室，美国北卡罗来纳州摄政公园路2000号，邮编27511-8506
Phone: +1 919 380-6638
EMail: wzz@lucent.com
Phone: +1 919 380-6638
EMail: wzz@lucent.com
Sung-Yurn Rhim Korea Telecom 17 Woomyun-dong Seocho-gu, Seoul, Korea
Sung Yurn Rhim韩国电信17号，韩国首尔吴明洞Seocho gu
Phone: +82 2 526 6172
EMail: syrhim@kt.co.kr
Phone: +82 2 526 6172
EMail: syrhim@kt.co.kr
Jinkyung Hwang Korea Telecom 17 Woomyun-dong Seocho-gu, Seoul, Korea
韩国首尔Woomyun dong Seocho gu 17号Jinkyung Hwang韩国电信
Phone: +82 2 526 6830
EMail: jkhwang@kt.co.kr
Phone: +82 2 526 6830
EMail: jkhwang@kt.co.kr
Shinji. Ago NEC Corporation 1131, Hinode, Abiko, Chiba, 270-1198, Japan
真嗣。Ago NEC Corporation 1131，日本千叶市阿比科市日野区，270-1198
Phone: +81 471 85 7412
EMail: ago@ssf.abk.nec.co.jp
Phone: +81 471 85 7412
EMail: ago@ssf.abk.nec.co.jp
S. Moeenuddin NEC America, Inc 1525 Walnut Hill Lane, Irving, TX, USA 75038
美国德克萨斯州欧文胡桃山巷1525号S.Moeenuddin NEC America，Inc.75038
Phone: +1 972 518 5102
EMail: moeen@asl.dl.nec.com
Phone: +1 972 518 5102
EMail: moeen@asl.dl.nec.com
S. Hadvani NEC America, Inc 1525 Walnut Hill Lane, Irving, TX, USA 75038
美国德克萨斯州欧文胡桃山巷1525号S.Hadvani NEC America，Inc.75038
Phone: +1 972 518 3628
EMail: hadvani@asl.dl.nec.com
Phone: +1 972 518 3628
EMail: hadvani@asl.dl.nec.com
Soren Nyckelgard Telia Research Chalmers Teknikpark 41288 Gothenburg Sweden
Soren Nyckelgard Telia Research Chalmers Teknikpark 41288瑞典哥德堡
EMail: soren.m.nyckelgard@telia.se
EMail: soren.m.nyckelgard@telia.se
John Yoakum Nortel Networks 507 Airport Blvd, Suite 115, Morrisville, NC, USA 27560
John Yoakum Nortel Networks美国北卡罗来纳州莫里斯维尔机场大道507号115室27560
EMail: yoakum@nortelnetworks.com
EMail: yoakum@nortelnetworks.com
Lewis Robart Nortel Networks P.O. Box 402 Ogdensburg, NY, USA 13669
美国纽约州奥格登斯堡市北电网络公司邮箱402号，邮编13669
EMail: robart@nortelnetworks.com
EMail: robart@nortelnetworks.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。