[要約] RFC 2995は、PSTNによって開始されるサービスの事前スピリット実装に関する要約です。その目的は、PSTNベースのサービスをIPネットワークに移行するためのガイドラインを提供することです。
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.
Copyright（c）The Internet Society（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/のサービスで進行中の作業に関連する情報が含まれています。Nortel Networksと協力して、韓国テレコム、Lucent Technologies、NEC、およびTeliaからのスピリッツのようなサービスの4つの既存の実装について説明しています。スピリッツのようなサービスは、公共の切り替えの電話ネットワーク（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サービスは、ベンチマークサービスの役割を果たします。4つの実装はすべて、ICWをサポートでき、3つは特別に設計されています。
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とインターネットの間の基本通信プロトコルとして使用されます。（NECの実装は、独自のプロトコルを使用する唯一の例外です。それでも、NECにはSPIRITSサービスの拡張機能と一緒にSIPをサポートする計画があります。）
o All implementations use IN-based solutions for the PSTN part.
o すべての実装は、PSTNパーツのベースで使用されます。
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 Working Groupのタスクは、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
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/のサービスで進行中の作業に関連する情報が含まれています。Nortel Networksと協力して、韓国テレコム、Lucent Technologies、NEC、およびTeliaからのスピリッツのようなサービスの4つの既存の実装について説明しています。スピリッツのようなサービスは、公共の切り替えの電話ネットワーク（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.
このドキュメントで検討した実装で常にサポートされているのは、インターネットコールウェイティング（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サービスの詳細な説明を提供します。次に、4つの実装のそれぞれについて議論します。ドキュメントの最後のセクションには、セキュリティ上の考慮事項、結論、参照が含まれています。
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
インターネットコールウェイティングは、問題のすべての実装によって特別にサポートされている単一サービスです。一言で言えば、このサービスは、インターネットのダイヤルアップセッションに従事するサブスクライバーを有効にします
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サービスの詳細は、実装から実装までさまざまな待機コールを扱う方法にあります。このセクションでは、実装の少なくとも1つによってサポートされている機能について説明します。彼らは次のとおりです：
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ラインを介したコールを受け入れ、インターネット（モデム）接続を終了する
+ Accepting the call over the Internet using Voice over IP (VoIP)
+ Voice Over IP（VoIP）を使用してインターネット経由でコールを受け入れる
+ 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 複数の通話処理 - コール処分処理中に複数の通話が届くことがあります。複数のコール処理により、サブスクライバーには複数の呼び出しが1つずつ通知されます。
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: o Automatic Activation/De-activation - When Internet dial-up connection is set up, the ICW service is activated or de-activated automatically.
韓国テレコムのICW実装は、セクション2で説明されている機能のほとんどをサポートしています（主要な例外は、IPの音声を使用してインターネット上の着信コールを受信する機能です。）さらに、韓国のテレコム実装は柔軟なアクティベーションと脱アクティブ化をサポートしています。ICWサービス：o自動アクティベーション/脱アクティベーション - インターネットダイヤルアップ接続がセットアップされると、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クライアントシステムの両方は、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)
INAP : Intelligent Network Application Protocol PINT : PSTN/Internet Interworking Protocol SL : Service Logic UAS : User Agent Server UAC : User Agent Client
INAP：インテリジェントネットワークアプリケーションプロトコルパイント：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）を実行します。呼び出されたパーティーが忙しいことを検出すると、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とインターネットの間のプロトコル相互作用のために、Service Control Gateway関数（SCGF）を実行します。ICWサーバーからのSIPメッセージをサービスコントロールインターフェイスメッセージに変換し、Vise Versaに翻訳します。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に転送されたときに呼び出し当事者からの呼び出し政党番号または音声メッセージを記録します（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サーバーシステムは、ICWクライアントとSCGF間のメッセージルーティング用のSIPプロキシまたはリダイレクトサーバーとして機能します。ICWサーバーは、ICWクライアントに接続されているICWクライアントの管理も担当しています。ICWクライアント（サブスクライバー）がICWサービスの登録リクエストを送信すると、ICWサーバーはSCPにリクエストをリレーし、SCPからの承認の結果を待ち、データベースに認可されたサブスクライバーを登録します。さらに、ICWサーバーは、登録されたICWクライアントの接続ステータスを監視します。クライアントがICWサービスを無効にするか、インターネット接続を終了するとすぐに、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（またはサブスクライバー）のインターネット接続ステータスを監視します。サブスクライバーがインターネットに接続すると、ICWクライアントはICWサーバーを介してSCGFに登録リクエストを送信し、最終的にSCPに送信します。この能力では、ICWクライアントはSCGFのUACとして機能し、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にダイアログボックスをポップアップして、着信を発表する責任があります。ダイアログボックスには、呼び出しパーティー、通話時間、および通話処理オプションの番号と名前（受け入れ、拒否、別の番号またはVMへの転送を含む）が表示されます。サブスクライバーがオプションを選択した後、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)
+ 邪魔しないでのコール処理方法（拒否/フォワード/VM）
+ 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.
+ パーティー番号（Accept/relject/Forward/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 call record in the call log contains the following information:
o ICWクライアントは、サブスクライバーのPC上のログファイルにコール処理方法と結果を記録します。コールログのコールレコードには、次の情報が含まれています。
- Calling Time - Calling Party Number - Calling Party Name (optional) - Call Processing Method (Accept/Reject/Forward/Forward to VMS) - Result (Success/Fail)
- 呼び出し時間 - パーティー番号の呼び出し - パーティー名（オプション） - 通話処理方法（VMSへの受け入れ/拒否/フォワード/フォワード） - 結果（成功/失敗）
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サーバーの間にあります。
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またはインターネットからリクエストし、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 ServerおよびICW Server-ICWクライアントインターフェイスは、PINTサービスプロトコルv.1に基づいて実装されています。図2に示すように、UAS-Proxy-UAC関係を採用しました。
+---------+ +-------------+ +---------+
|(UAC/UAS)|PINT 1.0| (Proxy) |PINT 1.0|(UAC/UAS)|
| |--------| ICW |--------| ICW |
| SCGF | | Server | | Client |
+---------+ +-------------+ +---------+
Figure 2: PINT Protocol Architecture
図2：パイントプロトコルアーキテクチャ
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をサポートします。これは、2つのINAP CS-2メッセージ[PRM（PRONTANDRECEIVEMESSAGE）とEM（ERASEMESSAGE）]を組み込んだITU-T INAP CS-1に基づいています。ボイスメッセージ。
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 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.
ICWサービスは、SCPとICWサーバーシステム間の通信、およびICWサーバーシステムとICWクライアントシステム間の通信にPINTサービスプロトコル1.0 [1]を使用します。ITFパイントワーキンググループで開発されたIPネットワークから電話サービスを呼び出すために、Pint Service Protocol 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の実装に関連するパイントサービスプロトコル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.
登録法は、ICWサブスクライバーの接続ステータスをSCPに通知するために使用されます。この方法を使用すると、ICWクライアントは、サブスクライバーが最初にインターネットに接続されているときに、ICWサーバーにIPアドレス（PCの）およびサブスクライバーの電話番号を送信します。ICWサーバーは情報をSCPにリリーします。SCPはデータベースを更新し（サブスクライバーが承認されている場合）、最終的にはICWサーバーに登録承認を送信し、次にクライアントに送信します。サブスクライバーがインターネットに接続された後、ICWクライアントは、事前定義されたインターバル（20秒）で定期的に登録リクエストをICWサーバーに送信して、接続ステータスを示します。リクエストはSCPに中継されません。ICWサーバーは、承認されたサブスクライバーからのものであるかどうかのみをチェックします。最後に、サブスクライバーがインターネット接続を終了すると、クライアントは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 Ack
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.
さようならメソッドはサービスセッションを終了します。この元の使用法に加えて、被験者ヘッダーの値（成功または失敗）を使用して、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クライアントにキャンセルリクエストを送信して、以前に送信した招待リクエストをキャンセルします。
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は、以下のステータスコードと関連するコメントの1つでレジスタリクエストに応答します。
. 100 Trying: Trying . 200 OK: Registered
。100試行：試行。200 OK：登録
The ICW Client responds to an INVITE request with one of the status codes and associated comments below:
ICWクライアントは、以下のステータスコードと関連するコメントの1つを使用して、招待リクエストに応答します。
. 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 OK：電話を受け入れます。303その他を参照してください：呼び出しを別の番号に転送します。380代替サービス：VMSへの呼び出しを転送します。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オペレーターとインベーシングの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サブスクライバーは、ICWクライアントプログラムを自分のPCにインストールする必要があります。ICWクライアントは、サブスクライバーのPCがオンになったときにデーモンプロセスとして実行されるように自動的にアクティブ化されます。クライアントは、サブスクライバーのインターネット接続ステータスを監視します。
When the subscriber initiates the Internet connection or activates the ICW service manually, the ICW service is activated. That is done by sending a REGISTER request with the directory number and IP address from the ICW Client to the SCP through the ICW Server.
サブスクライバーがインターネット接続を開始するか、ICWサービスを手動でアクティブにすると、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 | | | | |
| | | | | |
-----> 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クライアントは、ダイヤルアップ接続のIPアドレス-DN関係を登録するために、ICWサーバーに登録リクエストを送信します。
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アドレスを保存し、ステータスを「インターネットオンライン」に設定します。
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メッセージのユーザー登録応答をパイントメッセージに変換します。
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 |----------->| | | | |
| | | | | |
-----> 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は、Callee（ICWサブスクライバー）が忙しいことを検出します。
2. The SSF/CCF sends InitialDP (T_Busy) to the SCF/SDF.
2. SSF/CCFは、SCF/SDFにInitialDP（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のユーザーがオンラインオンラインまたはインターネットオンラインであるかどうかを決定します。（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内部形式からパイント形式に着信コール通知を翻訳します。
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."
着信コールは、サブスクライバーのフライまたは事前に定義された選択に応じて、受け入れられたり、拒否されたり、別の番号に転送されたり、VMに転送されたりすることができます。このセクションでは、「コールを受け入れる」と「別の番号に電話を転送する」というケースの情報フローについて説明します。
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling
ICW Client party
(DN1/IP1) (IP2) (IP3) (DN2)
| | | | | |
0A 200 OK | | | | |
1 |----------->| | | | |
1A | | | | |
1B | 200 OK | | | |
2 | |----------->| | | |
| | ACK 2A | | |
3 | |<-----------| | | |
| | |Accept(DN1,IP1,DN2) | |
4 | | |-.-.-.-.-.->| | |
| | | |Connect(DN1,DN2) |
5 | | | |--.--.--.-->| |
| | | Setup(DN1,DN2)| |
6 |<++++++++++++++++++++++++++++++++++++++++++++++++++| |
|<==============================6A==============================>|
| | | | ERB | |
7 | | | |<--.--.--.--| |
| | | ok | | |
8 | | |<-.-.-.-.-.-| | |
| | 8A | | |
| | BYE | | | |
9 | |<-----------| | | |
| 9A | | | |
| | | | | |
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> Bearer
Figure 5: Incoming Call Processing - Accept the Call
図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サーバーに「Accept」表示を送信します。
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クライアントは、サブスクライバーのインターネット接続を終了します。
2. The ICW Server sends an "Accept" message to the SCGF.
2. ICWサーバーは、SCGFに「Accept」メッセージを送信します。
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は、コール完了メッセージをパイントメッセージに変換します。
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 | | | | | |
| | | | | | |
-----> 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は、コール完了メッセージをパイントメッセージに変換します。
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 | | | |
| | | | | |
-----> 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サブスクライバーは、インターネット接続を終了します。
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クライアントから定期的なオンライン通知を受け取らない場合、インターネット接続が終了したと判断します。
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クライアントのインターネットオフラインステータスを記録します。
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は、ユーザーの登録応答をパイントメッセージに変換します。
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クライアント（サブスクライバー）のインターネットオフラインステータスを記録します。
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.
Lucent Technologies Online Communications Center（OCC）は、インターネットコールウェイティングサービスをサポートするインテリジェントネットワーク（IN）ベースのプラットフォームです。その基本的なコンポーネントは、アーキテクチャセクションで詳細に説明されているOCCサーバーとOCCクライアントです。OCCサーバーは、プレーンテキストセッション開始プロトコル（SIP）メッセージ[2]を介して、安全なイントラネットを介してPSTNエンティティと相互作用します。PCクライアントを使用すると、OCCサーバーは暗号化されたSIPメッセージを介して相互作用します。
The OCC Server run-time environment effectively consists of two multi-threaded processes responsible for Call Registration and Call Notification services, respectively.
OCCサーバーランタイム環境は、それぞれコール登録と通話通知サービスを担当する2つのマルチスレッドプロセスで構成されています。
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 duration of the call in support of the Internet connection between the end-user and the ISP.)
すべてのOCC呼び出し通知サービスはPSTN開始です。これらのサービスの一般的な特徴の1つは、モデムで既に使用されているラインに影響を与えることなく、インターネット経由で入ってくる電話をユーザーに通知することです。（典型的なコール待機トーンはインターネット接続を中断し、エンドユーザーとISPの間のインターネット接続をサポートするために、「古い」PSTNコール待機サービスを無効にすることが標準的な慣行です。）
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 |
| |
+-------------------+
Figure 8: The Lucent OCC Physical Architecture
図8：Lucent OCC Physical Architecture
Figure 8 depicts the joint PSTN/Internet physical architecture relevant to the OCC operation. The Compact Service Node (CSN) and SCP are Lucent's implementations of the ITU-T IN Recommendations (in particular, the Recommendation Q.1205 where these entities are defined) augmented by the requirements of Bellcore's Advanced 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.
図8は、OCC操作に関連するジョイントPSTN/インターネットの物理アーキテクチャを示しています。Compact Serviceノード（CSN）とSCPは、BellcoreのAdvanced Intelligent Network（AIN）リリース1.0）の要件によって補強されている推奨事項（特に、これらのエンティティが定義されているQ.1205の推奨Q.1205）のLucentの実装です。他の機能が装備されています。セントラルオフィス（CO）は、統合サービスデジタルネットワーク（ISDN）プライマリレートインターフェイス（PRI）をサポートするスイッチと、CSNとのインターワークを可能にするコール転送機能です。あるいは、SCPと連携するには、サービススイッチングポイント（SSP）である必要があります。後者の場合、中央のオフィスは、シグナリングシステムNo. 7（SS7）を介してSCPに接続され、アプリケーション層でのINAPです。
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）は、SCPS、CSNS、および中央オフィスのプロビジョニングを担当しています。特に、インターネットのチャープ待機をサポートするためには、終端試行トリガー（TAT）に基づいてOCC SCP SPAに対応するサブシステム番号に終了試行クエリを指示するために中央オフィスにプロビジョニングする必要があります。さらに、サブスクライバーディレクトリ番号（DN）、個人識別番号（PIN）、および言語IDは、各サブスクライバーに対してSCPリアルタイムデータベース（RTDB）のOCCサブスクライバーエントリにプロビジョニングされます。図9は、RTDBエントリの構造を示しています。
+-------------------------------------------------------+
|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アドレス - サブスクライバーのインターネットプロトコルアドレス
(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）通話通知In Progress Flag（boolean） - コールのサブスクライバーに通知しようとする試みが現在進行中であるかどうかを示すフラグ
Session Key - unique identifier for the current registration session of the subscriber
セッションキー - サブスクライバーの現在の登録セッションのための一意の識別子
Language ID - language identifier for the subscriber
言語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 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.
中央オフィス、SMS、CSN、およびSCPは、アーキテクチャの唯一のPSTN要素です。他の要素は、VoIPゲートウェイとGateKeeperがITU-Tの推奨H.323で定義されています。中央オフィスは、ISDN PRI接続を介してVoIPゲートウェイに明示的に接続されています。このアーキテクチャでは、CSN、VoIP Gateway、およびVoIP GateKeeperがインターネットに接続されている唯一のエンティティであり、それぞれの接続がそれぞれファイアウォールで保護されています。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に通知する中央のオフィスは、そのサブスクライバーが彼（または彼女）がインターネットにログインしていることを登録したかどうかを確認できます。インテリジェントネットワークを特徴付けるサービスロジックの標準化されたレイヤー化を活用すると、中央オフィスは、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に1つのサービスパッケージアプリケーション（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スパの間でメッセージを中継します。
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メッセージを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招待）が個別のコントロールスレッドを使用してコールを処理する「メッセージごとのメッセージ」ベースでマルチスレッドをサポートします。元の開始メッセージとして同じセッションCall-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 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サーバーはSCP SPAでTCP/IPセッションを動的に開きます。SCP SPAは、OCCサーバーを介してOCCクライアントが送信した、事前に構成されたポートに耳を傾けます。SIPメッセージをOCCサーバーと交換するために、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コールバックに関連する2つの着信コール脚を接続するとすぐに、SIP 180リンギングメッセージは、SSPに実行されているSCP SPAに送り返され、SSPがSSPに転送するように指示しました。CSNへの発信者。このSIPメッセージには、ブリッジ付きコール脚の1つによってダイヤルされたVoIPコールバックDNを含むこのメッセージは、VoIPコールバックDNが解放されることをSCP SPAの兆候です。
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ゲートウェイには、特定のCSNで終了する承認されたVOIPコールバックDNSのリストがプロビジョニングされています。これらの特別なDNは、オンラインのサブスクライバーがVOIPを介して着信コールを受信することを選択したときに使用されます。特に、サブスクライバーのネットミートから発信コールを、SCPが（ほぼ同時に）着信コールを転送している特定のCSNへの発信コールをルーティングするのに役立ちます。（これらの2つの呼び出しは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:
最後に、次のように進行するIPの音声を含むOCCコールの処分の特定のシナリオについて説明します。
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代替サービス」メッセージを送信します。このメッセージには、最終的にCSNによって使用されるコールバックDNへの参照が含まれています。これは、サブスクライバーに接続する（VoIPゲートウェイを介して）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に「SIP 380オルタナティブサービス」メッセージをコールバックDNを含むメッセージを送信します。
4. The SCP SPA instructs the Central Office to forward the call incoming to the subscriber to the CSN. This instruction includes the Call Back DN.
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クライアントは1）コール通知中に受信したSIP招待メッセージからVOIPコールバックDN、2）プロパティファイルから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 Gatewayの間に接続が確立されると、NetMeetingは電話を開始します - VoIPゲートウェイに宛先DNを宛先DNとしてバックバックします。
9. The VoIP Gateway consults the VoIP Gatekeeper and authenticates the NetMeeting call by verifying the H323UID and H323PIN values, and by ensuring the called DN (i.e., Call Back DN) is authorized for use.
9. VoIP GatewayはVoIP GateKeeperに相談し、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ゲートウェイは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. 中央のオフィスが2つのBチャンネル転送（Lucent、Nortel、およびおそらく他の中央オフィスのVenderのDO）をサポートしている場合、最適化が可能です。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実装は、inに基づいています。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.
ユーザーは、さまざまなサービスセットアップオプションを使用してサービスをカスタマイズできます。インターネットセッション中にユーザーに提示されるすべての呼び出しは、呼び出しログに記録されます。
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 || \ /--\
()/\() / =================== \ ()/\()
_/__\___/ \______/__\_
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
伝説：ISP：インターネットサービスプロバイダーW3S：WWWサーバーSCP：サービスコントロールポイント（スピリッツとして機能する）SSP：サービススイッチングポイントCO：中央オフィスM/D：モデム
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)
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:
以下の説明は、COラインで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. COラインは、ISPディレクトリ番号の前に特別なアクティベーションコード（ *54）のプレフィックスを挿入することにより、顧客がISPに接続するときに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サーバーまでの安全なセッションを開くとアクティブになります。セッションが開かれると、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は、スピリッツサーバーに、通話が忙しいインターネットラインに終了していることを通知します。メッセージには、発信者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
- 通話に応答します（インターネット接続が自動的にドロップされ、電話が鳴ります） - コールをボイスメールに送信します - 電話を別の宛先に転送 - 通話を無視します
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サーバーに送信します。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ルーティングテーブルは、Spiritsサーバーへのすべての使用可能な接続が使用されるように構成されます。
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サーバーの間で2つの異なるタイプのメッセージが使用されます：「接続管理メッセージタイプ」と「データメッセージタイプ」。これらのメッセージには、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とSpiritsサーバーの間で信頼できる通信が維持されるようにします。SCPは、Spiritsサーバーへの接続を確立する責任があります。SCPまたはSpiritsサーバーのいずれかによって接続を閉じることができます。
The "Connection Management Message Type" includes the following operations:
「接続管理メッセージタイプ」には、次の操作が含まれます。
- scfBind - scfUnbind - activitytest
- scfbind -scfunbind -ActivityTest
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 InvokationメッセージをSpiritsサーバーに送信します。このメッセージには、バージョン情報とアクティビティテストの間隔も含まれています。
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サーバーの識別番号を含むRETURN結果または理由で返されるエラーのいずれかで応答します。
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のInvokationを受信すると、SpiritsサーバーはActivityTestの返された結果で返信する必要があります。Spirits Serverが、Millisecondsでアクティビティテスト間隔値の4倍の情報要求またはアクティビティテストのInvokationメッセージを受信しない場合、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.
接続を閉じるために、SCFunbindの呼び出しは、SCPまたはSpiritsサーバーのいずれかによってリモートエンドに送信されます。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とSpiritsサーバーの間の接続を開くために使用されます。SCPは、Spirits Serverに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の返品結果には、Spiritsサーバーの識別子が含まれています。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とSpiritsサーバーの間の接続を閉じるために使用されます。SCPまたはSpiritsサーバーのいずれかがこの操作を呼び出すことができます。
Upon receiving an invokation message the receiving end should terminate the connection.
Invokationメッセージを受信すると、受信側は接続を終了する必要があります。
activityTest
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のInvokationメッセージが送信されます。Spiritsサーバーがそのような呼び出しを受信すると、ActivityTestのRECORNING RECOUNTメッセージで返信します。
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:
SCPSは、データメサージタイプのメッセージを介してSpiritsサーバーに送信される次の操作を使用して、SCPSで行われるイベントのいくつかのサービス手順または通知の実行を要求します。
o handlingInformationRequest
o HandlingInformationRequest
The handlingInformationRequest message will request a SPIRITS server the execution of some service procedure.
HandlingInformationRrequestメッセージは、Spiritsサーバーにいくつかのサービス手順の実行を要求します。
o handlingInformationResult
o HandlingInformationResult
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 cunmednotificationProvided
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メッセージは、SCPで行われるイベントのSpiritsサーバーに示されます。「発信者の放棄」が受信されることを示す確認された確認が提供された場合、Spiritsサーバーは、CONRERSの放棄をクライアントに通知し、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.
データメッセージが事前に決定されたタイムアウト期間内に返信されない場合、メッセージは指定された時間をいくつかresします。回数を超えたら、別のノードが存在する場合、使用可能な場合はメッセージが別のノードに送信されます。利用可能なすべてのスピリッツサーバーが質問されている場合、メッセージタイムアウトは呼び出しプロセスに返されます。
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（サービスは利用できない）で受信された場合、HandlingInformationRrequestが利用可能な場合は別のノードに送信されます。利用可能なすべてのスピリッツセバーが照会されている場合、原因= 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クライアント - > Spirits Server）
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（Spirits Server-> 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サーバーに時代遅れのバージョンであることを示している場合、URL情報は、新しいバージョンのダウンロードで使用するVersionInFoackメッセージ内で返されます。クライアントソフトウェアが最新の場合、メッセージは単にそのように示され、URL情報が含まれていません。
o CallArrival (SPIRITS server -> ICW client)
o CallArrival（Spirits Server-> ICWクライアント）
Sent by the server to tell the client someone has called the DN.
サーバーによって送信されて、クライアントに誰かがDNに電話したことを伝えます。
o CallID
o callid
An identifier for this call. Unique in the domain of this client/server session.
この呼び出しの識別子。このクライアント/サーバーセッションのドメインでユニーク。
o CallingNumber
o CallingNumber
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 (" ").
呼び出しパーティーの名前は、Spiritsサーバーからクライアントアプリケーションに送信されます。利用可能な場合、名前は15文字の文字列として送信されます。名前が利用できない場合、「名前は利用できない」と送信されます。呼び出し政党にCLIRセットがある場合、それは空（ ""）として送られます。
o CallConnect (ICW client -> SPIRITS server)
o CallConnect（ICWクライアント - > Spirits Server）
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 = Ingroreが受信されたかのように動作します。
o CallLost (SPIRITS server -> ICW client)
o CallLost（Spirits Server-> ICWクライアント）
Sent by server to cancel a CallArrival before a CallConnect is received by the server.
サーバーがCallConnectが受信する前に、CallRarivalをキャンセルするためにサーバーによって送信されます。
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セッションの数が減少します。セッションの残りの部分は、SSLセッション中に安全に交換されたキーやその他のパラメーターを使用して保護されているUDP/IPを介して通信されます。
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ポートでサービスとSSLセッション（ICWなど）を開設することにより、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:
Nortel Networksと協力して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 Architectureでは、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 Redirect Serverは、コールがセットアップされているネットワークに関係なく、各コールのSIP招待メッセージを受信します。サーバーは、招待状に応答する方法を決定するために、あらゆる種類のサービスロジックを適用できます。サービスロジックは、ユーザーと対話して、ユーザーがセクション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.
SCGSは、ネットワーク固有のコールコントロールシグナルを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.
SCGSはプロトコルの変換を処理しますが、SIP URLへの電話番号などの翻訳には対処しません。これは、SCGを可能な限り簡単に保つために通常のSIPサーバーによって処理されます。
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と数字サーバー（NS）と呼ばれる高性能SIPリダイレクトサーバーが、通常SCPにあるデータベースを置き換えました。（図11を参照してください。）
+-----------+ 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 Redirect Server）に転送されます。
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はこれを「非移植されていない番号」として解釈し、CONメッセージをCSNネットワークに返し、呼び出しを呼び出した番号に接続します。
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は接触フィールドにTel URL（ルーティング番号）を使用して「301移動」を「永続的に移動」します。次に、SCGはCONメッセージをCSNネットワークに返し、接触フィールドに伝えられた数値に呼び出しを接続します。
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 Redirect-Serverベースのサービスに番号クエリをリレーできます。懸念されるホストへのIP接続。図12は配置を示しています。
+------+ 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に転送されます。ただし、この場合、数値はSIP URLへの参照とともに登録されます。これにより、SIPが登録された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は、応答を適切なINAPメッセージに変換するSCGに応答を送り返します。サービスからの応答は、通常、コンタクトフィールドに電話番号を使用して「一時的に移動」します。
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 Systemは、マルチプロトコルサポートを必要とせずにマルチネットワークサービスの導入を許可することを目指しています。したがって、このサービスは、どのネットワークが通話が行われ、一般的な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 |
+--------+ '......' +-----------+
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 Architectureは、純粋な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 mechanism that can block a denial-of- service attack from an Internet user toward the PSTN.
考慮しなければならない一般的なセキュリティの問題には、2つの異なるネットワークの相互接続が含まれます。したがって、SCGには、あるネットワークから他のネットワークへの破壊的なサービス制御シグナル伝達を防ぐメカニズムを含める必要があります。たとえば、インターネットユーザーからPSTNへのサービス拒否攻撃をブロックできるファイアウォールタイプのメカニズム。
Overall, the SPIRITS security requirements are essentially the same as those for PINT [3, 4], which include, for example:
全体として、Spiritsのセキュリティ要件は、基本的にパイントの要件と同じです[3、4]。
+ Protection of the PSTN from attacks from the Internet.
+ インターネットからの攻撃からのPSTNの保護。
+ 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:
このドキュメントは、Spiritsサービスをサポートするために、PSTNとインターネット間のネットワーキング間インターフェイスの開発に関連する情報を提供しています。具体的には、スピリッツのようなサービスの4つの既存の実装を説明しました。これらの実装を調査すると、次の観察を行うことができます。
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サービスは、ベンチマークサービスの役割を果たします。4つの実装はすべて、ICWをサポートでき、3つは特別に設計されています。
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とインターネットの間のベースの通信プロトコルとして使用されます。（NECの実装は、独自のプロトコルを使用する唯一の例外です。それでも、NECにはSPIRITSサービスの拡張機能と一緒にSIPをサポートする計画があります。）
o All implementations use IN-based solutions for the PSTN part.
o すべての実装は、PSTNパーツのベースで使用されます。
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 Working Groupのタスクは、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。and L. Conroy、「The Pint Service Protocol：SIPおよびSDPへの拡張電話への電話サービスへのアクセスのためのSDP」、RFC 2848、2000年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。and J. Rosenberg、「SIP：セッション開始プロトコル」、RFC 2543、1999年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] Lu、H。（ed。）、Krishnaswamy、M.、Conroy、L.、Bellovin、S.、Burg、F.、Desimone、A.、Tewani、F.、Davidson、D.、Schulzrinne、H。and K。Vishwanathan、「PSTN/INTERNTER INTER-NETWORKING-PRE-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 Room 4L-334 101 Crawfords Corner Road Holmdel、NJ、USA 07733-3030
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
Hui-Lan Lu Lucent Technologies Room 4L-317 101 Crawfords Corner Road Holmdel、NJ、USA 07733-3030
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
電話：1 732 949 0321メール：huilanlu@lucent.com John Voelker Lucent Technologies Room 1A-417 263 Shuman Blvd PO Box 3050 Naperville、イリノイ州60566-7050
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
Weizhong Zhang Lucent Technologies Room 01-A5-17 2000 Regency Parkway Cary, NC, USA 27511-8506
Weizhong Zhang Lucent Technologies Room 01-A5-17 2000リージェンシーパークウェイCary、NC、USA 27511-8506
Phone: +1 919 380-6638
EMail: wzz@lucent.com
Sung-Yurn Rhim Korea Telecom 17 Woomyun-dong Seocho-gu, Seoul, Korea
Sung-Yurn Rhim Korea Telecom 17 Woomyun-Dong Seocho-gu、ソウル、韓国
Phone: +82 2 526 6172
EMail: syrhim@kt.co.kr
Jinkyung Hwang Korea Telecom 17 Woomyun-dong Seocho-gu, Seoul, Korea
Jinkyung Hwang Korea Telecom 17 Woomyun-Dong Seocho-gu、ソウル、韓国
Phone: +82 2 526 6830 EMail: jkhwang@kt.co.kr Shinji. Ago NEC Corporation 1131, Hinode, Abiko, Chiba, 270-1198, Japan
電話：82 2 526 6830メール：jkhwang@kt.co.kr shinji。Ago Nec Corporation 1131、Hinode、Abiko、Chiba、270-1198、日本
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
S. Moeenuddin Nec America、Inc 1525 Walnut Hill Lane、Irving、TX、USA 75038
Phone: +1 972 518 5102
EMail: moeen@asl.dl.nec.com
S. Hadvani NEC America, Inc 1525 Walnut Hill Lane, Irving, TX, USA 75038
S. Hadvani Nec America、Inc 1525 Walnut Hill Lane、Irving、TX、USA 75038
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 Gothenburg Sweden
EMail: soren.m.nyckelgard@telia.se
John Yoakum Nortel Networks 507 Airport Blvd, Suite 115, Morrisville, NC, USA 27560
John Yoakum Nortel Networks 507 Airport Blvd、Suite 115、Morrisville、NC、USA 27560
EMail: yoakum@nortelnetworks.com
Lewis Robart Nortel Networks P.O. Box 402 Ogdensburg, NY, USA 13669
ルイス・ロバート・ノーテルネットワークP.O.ボックス402オグデンズバーグ、ニューヨーク州、米国13669
EMail: robart@nortelnetworks.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。