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
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document contains information relevant to the work underway in The Services in the PSTN/IN Requesting InTernet Services (SPIRITS) Working Group. It describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN.
この文書では、PSTNで/インターネットサービス（SPIRITS）作業部会を要求する際にサービスで進行中の作業に関連する情報が含まれています。これは、ノーテルネットワークスと共同で、韓国テレコム、ルーセント・テクノロジー、NEC、およびテリアからSPIRITSのようなサービスの4既存の実装について説明します。 SPIRITSのようなサービスは、公開に起因するものを交換電話網（PSTN）とインターネットとPSTNの相互作用を必要としています。
Surveying the implementations, we can make the following observations:
実装を測量、我々は以下の観察を行うことができます。
o The ICW service plays the role of a benchmark service. All four implementations can support ICW, with three specifically designed for it.
O ICWサービスは、ベンチマークサービスの役割を果たしています。すべての4つの実装では、具体的には、それ用に設計された3で、ICWをサポートすることができます。
o Session Initiation Protocol (SIP) is used in most of the implementations as the base communications protocol between the PSTN and Internet. (NEC's implementation is the only exception that uses a proprietary protocol. Nevertheless, NEC has a plan to support SIP together with the extensions for SPIRITS services.)
Oセッション開始プロトコル（SIP）は、PSTNとインターネットとの間のベースの通信プロトコルとして実装のほとんどで使用されています。 （NECの実装では、独自のプロトコルを使用しています唯一の例外である。それにもかかわらず、NECはSPIRITSサービスのための拡張機能と一緒にSIPをサポートするための計画を持っています。）
o All implementations use IN-based solutions for the PSTN part.
Oすべての実装は、PSTN部分のIN-ベースのソリューションを使用しています。
It is clear that not all pre-SPIRITS implementations inter-operate with each other. It is also clear that not all SIP-based implementations inter-operate with each other given that they do not support the same version of SIP. It is a task of the SPIRITS Working Group to define the inter-networking interfaces that will support interoperation of the future implementations of SPIRITS services.
ないすべての前SPIRITS実装がお互いに相互運用することは明らかです。ないすべてのSIPベースの実装は、彼らがSIPの同じバージョンをサポートしていないことを考えるとお互いに相互動作することも明らかです。 SPIRITSサービスの将来の実装の相互運用をサポートする間のネットワーク・インタフェースを定義するSPIRITS作業部会の作業です。
Table of Contents
目次
1. Introduction ................................................ 3
2. Service Description of Internet Call Waiting ................ 4
3. Korea Telecom's ICW Implementation .......................... 5
3.1. Overview .................................................. 5
3.2. Network Architecture ...................................... 6
3.3. Network Entities .......................................... 7
3.3.1. SSP ..................................................... 7
3.3.2. SCP ..................................................... 7
3.3.3. IP ...................................................... 7
3.3.4. ICW Server System ....................................... 7
3.3.5. ICW Client System ....................................... 8
3.3.6. Firewall ................................................ 9
3.4. Network Interfaces ........................................ 9
3.5. Protocols ................................................. 9
3.5.1. Intelligent Network Application Part Protocol (INAP) .... 9
3.5.2. PINT Protocol ........................................... 9
3.6. Example Scenarios ........................................ 11
3.6.1. ICW Service Subscription ................................ 11
3.6.2. ICW Client Installation ................................. 11
3.6.3. ICW Service Activation .................................. 12
3.6.4. Incoming Call Notification .............................. 14
3.6.5. Incoming Call Processing ................................ 15
3.6.5.1. Accept the Call ....................................... 16
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で/インターネットサービス（SPIRITS）作業部会を要求する際にサービスで進行中の作業に関連する情報が含まれています。これは、ノーテルネットワークスと共同で、韓国テレコム、ルーセント・テクノロジー、NEC、およびテリアからSPIRITSのようなサービスの4既存の実装について説明します。 SPIRITSのようなサービスは、公開に起因するものを交換電話網（PSTN）とインターネットとPSTNの相互作用を必要としています。
Invariably supported by the implementations examined in this document is the Internet Call Waiting (ICW) service. With ICW, service subscribers, while using their telephone lines for Internet access, can be notified of incoming voice calls and specify how to handle the calls over the same telephone lines.
必ずこの文書で検討の実装でサポートされているインターネットコールウェイティング（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.
着信通知○ - 加入者はモデムによって使用されている電話回線上の任意の効果を有することなく、インターネットを介して着信が通知されます。電話がかかってきた場合、加入者は、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)
ボイスオーバー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 Multiple Call Handling - Multiple calls can arrive during call disposition processing. With multiple call handling, the subscriber is notified of the multiple calls one by one.
O複数のコール処理 - 複数のコールは、コールの配置処理中に到着することができます。複数のコール処理を使用すると、加入者は、複数の呼び出し一つ一つが通知されます。
o Call Logging - A detailed log of the incoming calls processed during the ICW service is kept. Typical information recorded in the log include the incoming call date and time, calling party number, calling party name, and call disposition.
Oログを呼び出し - ICWサービス中に処理着信コールの詳細なログが保たれています。ログに記録された典型的な情報は、パーティの番号を発信者の名前を呼んで、着信日時が含まれ、処分を呼び出します。
Korea Telecom's ICW implementation supports most of the features described in Section 2. (The major exception is the feature of receiving the incoming call over the Internet using voice over IP.) In addition, the Korea Telecom implementation supports flexible activation and de-activation of the ICW service: o Automatic Activation/De-activation - When Internet dial-up connection is set up, the ICW service is activated or de-activated automatically.
韓国テレコムのICWの実装はまた、（主な例外は、IP上の音声を使用して、インターネット経由で着信コールを受信する機能です。）第2節で説明する機能のほとんどをサポートし、韓国通信の実装は柔軟活性化との非活性化をサポートしています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）をスイッチングサービスは、IN CS-1に基づいて要素における従来のPSTNあります。これとは対照的に、ICW Serverシステムと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
Figure 1: Network Architecture of the Korea Telecom ICW Service
図1：コリアテレコムICWサービスのネットワークアーキテクチャ
The SSP performs the Service Switching Function (SSF) and Call Control Function (CCF). When detecting that the called party is busy (T_Busy), the SSP sends a query to the SCP and processes the call under the control of the SCP.
SSPは、サービス交換機能（SSF）と呼制御機能（CCF）を実行します。着信側が（T_Busy）ビジー状態であることを検出すると、SSPは、SCPにクエリを送信し、SCPの制御下でコールを処理します。
The SCP performs the Service Control Function (SCF) and Service Data Function (SDF). It, when queried, instructs the SSP to process the call based on the service logic. In the case of the ICW service, the service logic ultimately governs the notification of a waiting call to an online ICW subscriber and the disposition of the call. In addition, the SCP performs the Service Control Gateway Function (SCGF) for protocol inter-working between the PSTN/IN and Internet. It translates the SIP message from the ICW Server to the service control interface message and vise versa. The SCGF is an IP end point and behaves as a UAS (User Agent server) or UAC (User Agent client).
SCPは、サービス制御機能（SCF）とサービスデータ機能（SDF）を行います。これは、照会時に、サービスロジックに基づいてコールを処理するために、SSPに指示します。 ICWサービスの場合は、サービスロジックは、最終的にはオンラインICW加入者に待機コールとコールの処分の通知を支配します。加えて、SCPは、プロトコルは、PSTN / INとインターネットとの間でインターワーキングするためのサービス制御ゲートウェイ機能（SCGF）を行います。これは、サービス制御インターフェースメッセージにICWサーバからSIPメッセージを変換し、その逆。 SCGFはIPエンドポイントであるとUAS（ユーザエージェントサーバ）またはUAC（ユーザエージェントクライアント）として動作します。
The IP contains Service Resource Function (SRF). It, when necessary, plays announcements to the calling party during the ICW service before/after receiving the response from the ICW subscriber and records the calling party number or voice message from the calling party when the call is forwarded to the Voice Mail System (VMS).
IPは、サービスリソース機能（SRF）が含まれています。また、必要に応じて、前/ ICW加入者からの応答を受信した後、ICWサービス中に発呼者にアナウンスを再生し、コールがボイスメールシステムに転送されたときに、発呼者から発信者番号や音声メッセージを記録する（VMS ）。
The ICW Server system serves as a SIP proxy or a redirect server for message routing between the ICW Client and SCGF. The ICW Server is also responsible for managing the ICW Clients that are connected to it. When an ICW Client (subscriber) sends a registration request for the ICW service, the ICW Server relays that request to the SCP, waits for the result of authorization from the SCP, and registers the authorized subscriber in its data base. In addition, the ICW Server monitors the connection status of the registered ICW Clients. As soon as a client deactivates the ICW service or terminates the Internet connection, the ICW Server detects the status change and deactivates the ICW service for the client. Finally, the ICW Server manages profiles for each ICW subscribers as well as logs all the call processing results.
ICW Serverシステムは、SIPプロキシまたはICWクライアントとSCGF間のルーティングメッセージのリダイレクトサーバとして機能します。 ICW Serverには、それに接続されているICWクライアントを管理する責任があります。 ICWクライアント（加入者）がICWサービスの登録要求を送信すると、SCPへの要求ICWサーバリレーは、SCPからの認可の結果を待ち、そのデータベースに許可された加入者を登録します。また、ICW Serverは、登録されたICWクライアントの接続状態を監視します。すぐに、クライアントがICWサービスを無効にしたり、インターネット接続を終了して、ICW Serverは、ステータスの変更を検出し、クライアントのためにICWサービスを無効にします。最後に、ICW Serverは、各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 ClientはSCPに最終的にはその後、ICWサーバを経由してSCGFに登録要求を送信します。この容量では、ICWクライアントはUASとして動作するSCGFにUACとして動作します。その後、それは定期的に加入者の接続状態のICW Serverに通知します。
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 Clientはまた、着信コールを発表するために、加入者のPC上でダイアログボックスをポップアップする責任があります。ダイアログボックスには、時間を呼び出し、発呼側の番号と名前を表示し、（フォワード別の番号またはVMSに、受け入れ拒否を含む）呼処理オプションを設定します。加入者がオプションを選択した後、ICW ClientはSCPに送信します。この容量では、ICW ClientはUASとして機能します。
Depending on the pre-defined ICW Service Profile, the ICW Client may screen the incoming call before notifying the subscriber.
事前に定義されたICWサービスプロファイルに応じて、ICW Clientは、加入者に通知する前に、着信コールをスクリーニングすることができます。
The ICW Client manages the ICW Service Profile, which contains the following fields:
ICW Clientは、以下のフィールドが含まれてICWサービスプロファイルを、管理します。
o Subscriber Information (including, Name, Directory Number, Password)
O加入者情報（含む、名前、ディレクトリ番号、パスワード）
o Service Status (Activation/De-activation)
Oサービスの状態（活性化/非活性化）
o Automatic Call Processing Method
自動呼処理方法O
+ Call Processing Method on No Answer (Reject/Forward/VMS) - The call is automatically handled by the method if the subscriber doesn't respond after a pre-defined period of time.
+（/フォワード/ VMSを拒否）無応答時の処理メソッドを呼び出す - 加入者が時間の事前定義された期間の後に応答しない場合、コールは自動的にメソッドによって処理されます。
+ Do Not Disturb Mode (On/Off) - When this is set on, the subscriber won't be notified of the incoming calls.
+（オン/オフ）モードを着信拒否 - これがオンに設定されている場合、加入者は、着信コールが通知されることはありません。
+ Call Processing Method on Do Not Disturb (Reject/Forward/VMS)
+サイレントに処理メソッドを呼び出す（/フォワード/ VMSを拒否）
+ Call Processing List by Calling Party Numbers (Accept/Reject/Forward/VMS) - Calls originated from a number on the list are handled by the associated call processing method.
+コール処理一覧パーティー番号（受け入れ/拒否/フォワード/ VMS）を呼び出すことによって - コールは、リスト上の番号から発信関連する呼処理方法によって処理されます。
o The ICW Client records the call processing method and the result for each incoming call in a log file on the subscriber's PC. The call record in the call log contains the following information:
O ICW Clientは呼処理方法及び加入者の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.
SCF-SDF、SCF-SSF、およびSCF-SRFインタフェースoを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インタフェースは、どちらかまたはインターネットからの要求を中継し、SCPの内部のAPIに基づいて実装されています。
o The SCGF-ICW Server and ICW Server-ICW Client interfaces are implemented based on the PINT Service Protocol V.1. We adopted UAS-Proxy-UAC relationships as shown in Figure 2.
O SCGF-ICWサーバとICWサーバICWクライアントインタフェースはパイントサービスプロトコルV.1に基づいて実装されています。図2に示すように、我々は、UAS-プロキシUAC関係を採用しました。
+---------+ +-------------+ +---------+
|(UAC/UAS)|PINT 1.0| (Proxy) |PINT 1.0|(UAC/UAS)|
| |--------| ICW |--------| ICW |
| SCGF | | Server | | Client |
+---------+ +-------------+ +---------+
Figure 2: PINT Protocol Architecture
図2：PINTプロトコルアーキテクチャ
The SCP, SSP, and IP support the KT INAP V1.0, which is based on ITU-T INAP CS-1 with the incorporation of two INAP CS-2 messages [PRM (PromptAndReceiveMessage) and EM (EraseMessage)] for recording the voice message.
SCP、SSP、およびIPを記録するための2つのINAP CS-2メッセージ[PRM（PromptAndReceiveMessage）とEM（EraseMessage）]の取り込みとITU-T INAP CS-1に基づいているKT INAP V1.0をサポートボイスメッセージ。
The ICW service uses the PINT Service Protocol 1.0 [1] for communications between the SCP and the ICW Server System, and between the ICW Server System and the ICW Client System. Developed in the
ICWサービスは、SCPとICW Server Systemの間、およびICW ServerシステムとICWクライアントのシステムとの間の通信のために[1]パイントサービスプロトコル1.0を使用しています。で開発されました
IETF PINT Working Group for invoking telephone services from an IP network, the PINT Service Protocol 1.0 specifies a set of enhancements to SIP 2.0 and SDP.
IETF PINTワーキンググループIPネットワークからの電話サービスを呼び出すための、パイントサービスプロトコル1.0は、SIP 2.0とSDPへの機能拡張のセットを指定します。
Summarized below are the elements of the PINT Service Protocol 1.0 relevant to the Korea Telecom ICW implementation:
韓国通信ICW実装に関連するPINTサービスプロトコル1.0の要素を以下にまとめました。
o REGISTER
Oレジスタ
The REGISTER method is used to inform the SCP of the connection status of an ICW subscriber. With this method, the ICW Client sends to the ICW Server the IP address (of the PC) and phone number of the subscriber when the subscriber is first connected to the Internet. The ICW server relays the information to the SCP, which updates the data base (if the subscriber is authorized), and in the end sends a registration acknowledgment to the ICW Server and then the Client. After the subscriber is connected to the Internet, the ICW Client sends a REGISTER request to the ICW Server periodically at a pre-defined interval (e.g., 20 seconds) to indicate its connection status. The request is not relayed to the SCP. The ICW Server only checks if it is from the authorized subscriber. Finally, when the subscriber terminates the Internet connection, the Client sends the last REGISTER request to the SCP via the ICW Server. If the REGISTER request does not arrive during the pre-defined interval, the ICW Server can also detect the change of the connection status of the ICW Client.
REGISTERメソッドはICW加入者の接続状態のSCPに通知するために使用されます。この方法では、ICW ClientはICW Serverに（PCの）IPアドレスと加入者が最初にインターネットに接続された加入者の電話番号を送信します。 ICWサーバ（加入者が許可されている場合）データベースを更新SCPに情報を中継し、最後にICWサーバとクライアントに登録応答を送信します。加入者がインターネットに接続された後、ICWクライアントは、その接続状態を示すために、事前定義された間隔（例えば、20秒）で周期的ICWサーバにREGISTER要求を送信します。要求は、SCPに中継されていません。それが許可された加入者からのものである場合ICWサーバにのみチェックされます。加入者がインターネット接続を終了するときに最後に、クライアントは、ICWサーバを経由してSCPへの最後のREGISTERリクエストを送信します。 REGISTERリクエストは、事前に定義された間隔の間に到着しない場合、ICW ServerはICWクライアントの接続状態の変化を検出することができます。
o INVITE
お いんゔぃて
The SCP uses the INVITE method to notify the ICW Client, via the ICW Server, of an incoming call.
SCPは、着信、ICWサーバを経由して、ICWクライアントに通知するためにINVITEメソッドを使用しています。
o ACK
ACK O
Both the SCP and the ICW Server use the ACK method to confirm the receipt of the final responses to their requests.
SCPとICWサーバの両方が彼らの要求への最終応答の受信を確認するACKメソッドを使用します。
o BYE
O BYE
The BYE method terminates a service session. In addition to this original usage, we use the value (success or failure) of the Subject header to indicate the result of the desired disposition of an incoming call in the PSTN.
BYEメソッドは、サービスセッションを終了します。この元の使用に加えて、我々は、PSTNに着信呼の所望の配置の結果を示すために、件名ヘッダの値（成功または失敗）を使用します。
o CANCEL
O CANCEL
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は、それが以前に送信されたINVITEリクエストをキャンセルするICW ClientにCANCELリクエストを送信します。
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つとREGISTER要求に応答します。
. 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 Clientはステータスコードと下記の関連するコメントの一つでINVITE要求に応答します。
. 100 Trying: Trying . 200 OK: Accept the Call . 303 see other: Forward the Call to Another Number . 380 alternative service: Forward the Call to the VMS . 603 decline: Reject the Call
。 100はしよう：しようとしています。 200 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オペレータとINベースのICWサービスプロバイダの両方として機能します。サブスクリプションデータは、韓国テレコムが運営することはできません地元のものを含め、関連のSSPにロードする必要があることに注意してください。
An ICW subscriber should install the ICW Client program in his or her PC. The ICW Client is automatically activated to run as a daemon process when the subscriber's PC is turned on. The Client monitors the Internet connection status of the subscriber.
ICW加入者は、自分のPCにICWクライアントプログラムをインストールする必要があります。 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 Serverを介してSCPにICWクライアントからの電話番号とIPアドレスを持つREGISTERリクエストを送信することにより行われます。
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 Clientは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 Clientは、ダイヤルアップ接続のためのIPアドレス-DNの関係を登録するためにICWサーバに登録要求を送信します。
2A. The SCGF translates the user registration information from the SIP message to the SCP internal API message.
図2（a）。 SCGFはSCP内部APIメッセージにSIPメッセージからユーザ登録情報を変換します。
3A. The SCF/SDF authorizes the subscriber with the directory number based on the user registration information.
図3（a）。 SCF / SDFは、ユーザ登録情報に基づいて電話番号と加入者を許可します。
3B. The SCF/SDF stores the IP address of the ICW Client and sets the status to "Internet on-line."
図3（b）。 SCF / SDF店ICWクライアントのIPアドレスとする状態に設定「のオンラインインターネットを。」
4A. The SCGF translates the user registration response of the SCP internal API message to the PINT message.
図4（a）。 SCGFはPINTメッセージへのSCPの内部のAPIメッセージのユーザ登録応答を変換します。
5A. The ICW Server records the user registration information and the Internet on-line status for the subscriber in the data base.
図5（a）。 ICW Serverは、ユーザ登録情報とデータベース内の加入者のためのインターネット上のオンライン状態を記録します。
6. The ICW Server sends the user registration response to the ICW Client.
6. ICW Serverは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 Clientは登録が正常に完了している加入者に通知し、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は、呼び出し先（ICW加入者）がビジー状態であることを検出しました。
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.)
図2（a）。 SCF / SDFは、DN1のユーザがオンラインオンラインまたはインターネットPSTNであるか否かを判定する。 （SCF / SDFは、PSTNのオンライン場合KT電話メールサービスロジックと、インターネット上のオンライン場合にICWサービスロジックを実行します）。
2B. The SCF/SDF retrieves the IP address corresponding to DN1.
図2（b）。 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は、発呼者に告知を再生することができます。
3A. The SCGF translates the incoming call notification from the SCP internal format to the PINT format.
図3（a）。 SCGFはPINT形式にSCP内部フォーマットから着信通知を変換します。
4A. The ICW Server double-checks the subscriber's status using the ICW subscribers profile in its own data base.
図4（a）。 ICW Serverのダブルチェック加入者の地位独自のデータベースで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 Clientは着信コールのための事前定義されたコールの処分があるかどうかを確認するために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。着信コールのための事前定義されたコールの処分が存在しない場合、加入者は、ポップアップダイアログボックスを介してコールが通知されます。
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."
着信コールが別の番号に転送され、拒否され、受け入れられ、または加入者のオンザフライまたは事前定義された選択肢に応じVMSに転送することができます。このセクションでは、情報は、「コールを受け入れる」との例のための流れを説明し、「別の番号にコールを転送します。」
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加入者は、着信呼を「受け入れる」ことを選択しました。
1A. The ICW Client records the subscriber's selection for the incoming call in the call log.
1A。 ICW Clientは、コールログに着信呼のための加入者の選択を記録します。
1B. The ICW Client terminates the subscriber's Internet connection.
1B。 ICW Clientは、加入者のインターネット接続を終了します。
2A. The SCGF translates the "Accept" message to an SCP internal API message.
図2（a）。 SCGFはSCPの内部のAPIメッセージに「同意する」メッセージを変換します。
6A. The bearer connection between the calling party (DN2) and the ICW subscriber(DN1) is set up.
6A。発信側（DN2）とICW加入者（DN1）との間のベアラ接続が設定されています。
8A. The SCGF translates the call completion message to a PINT message.
図8（a）。 SCGFはPINTメッセージへの呼び出し完了メッセージを変換します。
9A. The ICW Server records the call completion result in the log file.
9A。 ICW Serverは、ログファイルにコール完了結果を記録します。
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 ClientはICW Serverに表示「別の番号に転送」を送信します。
1A. The ICW Client records the subscriber's selection for the incoming call in the call log.
1A。 ICW Clientは、コールログに着信呼のための加入者の選択を記録します。
3. The ICW Server relays the "Forward to another number" message to the SCGF.
3. ICW Serverは、SCGFにメッセージ「別の番号に転送」中継します。
3A. The SCGF translates the "Forward to another number" message to an SCP internal API message.
図3（a）。 SCGFはSCP内部のAPIメッセージにメッセージ「別の番号に転送」に変換します。
7A. The bearer connection between the calling party (DN2) and the new termination number (DN3) is set up.
7A。発信側（DN2）と新しい終了番号（DN3）との間のベアラ接続が設定されています。
9A. The SCGF translates the call completion message to a PINT message.
9A。 SCGFはPINTメッセージへの呼び出し完了メッセージを変換します。
10A. The ICW Server records the call completion result in the log file.
10A。 ICW Serverは、ログファイルにコール完了結果を記録します。
11. The ICW Server sends the success of "Forwarding to another number" to the ICW Client.
11. ICW ServerはICW Clientに「別の番号に転送」の成功を送信します。
11A. The ICW Client records the call completion result in the log file.
11A。 ICW Clientは、ログファイルのコール完了結果を記録します。
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 ServerはICWクライアントから定期的にオンライン通知を受信しない場合、インターネット接続が終了したと判断しました。
1A. The SCGF translates the un-register message to an SCP internal API message.
1A。 SCGFはSCP内部のAPIメッセージに登録解除メッセージを変換します。
2A. The SCF/SDF authorizes the subscriber with the directory number based on the un-registration information.
図2（a）。 SCF / SDFは、未登録情報に基づいて電話番号と加入者を許可します。
2B. The SCF/SDF records the Internet off-line status for that ICW Client.
図2（b）。 SCF / SDFは、ICWクライアントのインターネットオフラインの状態を記録します。
3B. The SCGF translates the user un-registration response to a PINT message.
図3（b）。 SCGFはPINTメッセージへのユーザ未登録応答を変換します。
4. The SCGF relays the user un-registration response to the ICW Server.
4. SCGFはICW Serverへのユーザー登録解除応答を中継します。
4A. The ICW Server records the Internet off-line status for the ICW Client (subscriber) in the data base.
図4（a）。 ICW Serverは、データベースに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.
ルーセント・テクノロジーズオンラインコミュニケーション・センター（OCC）のサービスを待っているインターネット通話をサポートしてインテリジェントネットワーク（IN）ベースのプラットフォームです。その基本的なコンポーネントは、アーキテクチャセクションに詳細に記載されているOCC ServerとOCCクライアント、です。 OCC Serverは、[2]プレーンテキストのセッション開始プロトコル（SIP）メッセージを介してセキュアなイントラネットPSTNエンティティと対話します。 PCクライアントと、OCC Serverは、暗号化されたSIPメッセージを介して対話します。
The OCC Server run-time environment effectively consists of two multi-threaded processes responsible for Call Registration and Call Notification services, respectively.
OCC Serverのランタイム環境は、効果的に呼び登録を担当する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（またはインターネットアプライアンス）から開始されます。これらを使用すると、加入者は、彼または彼女のエンドポイントを登録し、通知サービスをアクティブにします。 （登録サービスは、厳密に言えば、SPIRITSサービス、されるのではなく、PINTサービスの風味を持っています。）
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：ルーセントOCC物理アーキテクチャ
Figure 8 depicts the joint PSTN/Internet physical architecture relevant to the OCC operation. The Compact Service Node (CSN) and SCP are Lucent's implementations of the ITU-T IN Recommendations (in particular, the Recommendation Q.1205 where these entities are defined) augmented by the requirements of Bellcore's Advanced
図8は、OCCの動作に関連する関節PSTN /インターネット物理的アーキテクチャを示します。コンパクトなサービスノード（CSN）とSCPはBellcore社のAdvancedの要件によって増大（特に、これらのエンティティが定義されている勧告Q.1205）お勧めITU-TのLucentの実装であります
Intelligent Network (AIN) Release 1.0) and equipped with other features. The Central Office (CO) may be any switch supporting the Integrated Services Digital Network (ISDN) Primary Rate Interface (PRI) and the call forwarding feature that would allow it to interwork with the CSN. Alternatively, in order to interwork with the SCP, it needs to be an IN Service Switching Point (SSP). In the latter case, the central office is connected to the SCP via the signaling system No. 7 (SS7) and INAP at the application layer.
インテリジェントネットワーク（AIN）リリース1.0）およびその他の機能を装備。セントラルオフィス（CO）は、総合デジタル通信網（ISDN）一次群速度インターフェイス（PRI）と、それはCSNと相互作用することができるようになる通話転送機能をサポートしている任意のスイッチであってもよいです。また、SCPと相互作用するためには、ポイント（SSP）を切り替える際にサービスする必要があります。後者の場合、中央局は、アプリケーション層におけるシグナリングシステム第7号（SS7）とINAPを介してSCPに接続されています。
The Service Management System (SMS) is responsible for provisioning of the SCPs, CSNs, and central offices. In particular, for IN support of the Internet Call Waiting, it must provision the Central Office to direct a terminating attempt query to the subsystem number corresponding to the OCC SCP SPA based on the Termination Attempt Trigger (TAT). In addition, the Subscriber Directory Number (DN), Personal Identification Number (PIN) and Language ID are provisioned for each subscriber into the OCC Subscriber entry of the SCP Real Time Data Base (RTDB). Figure 9 shows the structure of an RTDB entry.
サービス管理システム（SMS）は、SCPの、のCSN、および中央オフィスのプロビジョニングを担当しています。特に、インターネットキャッチホンのIN支援のために、それは規定セントラルオフィスは終了しようとしましトリガー（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）着信通知（ブーリアン） - フラグコールの加入者に通知する試みが現在進行中であるかどうかを示します
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
セントラルオフィス、SMS、CSN、およびSCPは、アーキテクチャの唯一のPSTN要素です。他の要素は、その役割を確立し、IP上の音声経路の一部を提供するためであるITU-T勧告H.323で規定されたVoIPゲートウェイとゲートキーパーです。セントラルオフィスは、明示的に介して、VoIPゲートウェイに接続されています
ISDN PRI connection. In this architecture, CSN, VoIP Gateway, and VoIP Gatekeeper are the only entities connected to the Internet, with each respective connection protected by a firewall. The CSN and SCP are interconnected via a secure IP Intranet. There may be more than one CSN or SCP (or both) (and the SCPs come in mated pairs interconnected by X.25, anyway) in a network, but these details are not essential to the level of description chosen for this document. However, we note that load balancing and adaptation to failures by the use of alternative nodes is incorporated into the architecture.
ISDN PRI接続。このアーキテクチャでは、CSN、VoIPゲートウェイ、およびVoIPゲートキーパーは、ファイアウォールで保護されたそれぞれの接続で、インターネットに接続されている唯一のエンティティです。 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を照会するようにプロビジョニングされています。 （セントラルオフィスSS7上のみシグナル1 SCP、へのベアラ回路接続を有していないことに留意されたいです）。
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に実装されています。さらに、1つのサービスパッケージアプリケーション（SPA）は、SCPにインストールされています。別のSPAは、CSNに位置し、加入者がIP上で音声を使用して、着信コールを受け入れることを選択した場合にのみ必要とされています。
The OCC Server is a collection of Java servers on the CSN whose responsibilities include:
OCC Serverは責任含ま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.
SCPのSPAから送信されたOデ多重化/多重着信通知メッセージ。
o Relaying messages between the OCC Client and the SCP SPA.
OCCクライアントとSCP SPA間でメッセージを中継O。
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 Clientは、加入者のPC上で動作するソフトウェアコンポーネントの集まりです。その構成要素は、（OCC ServerとのSIPメッセージの交換を処理し、着信通知ポップアップウィンドウを呼び出します）SIPユーザエージェントサーバとポイントツーポイントプロトコル（PPP）の行動を監視し、責任あるデーモンプロセスが含まれますSIPユーザエージェントサーバの起動と停止のため。
The OCC Server uses distinct TCP/IP ports configured on the CSN to
OCC ServerはCSNに上に構成の異なるTCP / IPポートを使用しています
o Listen for incoming SIP REGISTER messages (in support of registration service) sent from the OCC Client.
O OCCクライアントから送信された（登録サービスのサポートで）着信SIP REGISTERメッセージのために聞きます。
o Listen for incoming SIP INVITE messages (in support of call notification service) sent from the SCP.
O SCPから送信された（着信通知サービスのサポートで）メッセージを着信INVITE SIPの音を聞きます。
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 Serverが開始された後に開始されます。 SCP SPAによって開始された「専用線」の接続を使用して（セキュア・イントラネット経由）TCP / IP経由SCP SPAとOCC Serverの交換SIPメッセージ。この接続は、SCP SPAは、OCC Serverからの非常に最初のSIP REGISTER要求を受信し、限り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 Serverは、マルチスレッドをサポートしています。各着信通知のために/処分イベントを呼び出し、別のスレッドは、コールを処理するために使用されます。このモデルは、（SIP招待）SCP SPAから受信したすべてのメッセージを開始「メッセージごと」に基づいて、マルチスレッドをサポートする呼び出しを処理するための制御の別のスレッドを使用します。元の開始メッセージとして（「call_index」とSCPホスト名として知られているSPAのインスタンスを含む）は、同じセッションのCall-IDを含む後続のメッセージは、以前はそれぞれ、開始メッセージを処理し、同じスレッドにルーティングされます。
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 Serverは、動的に各着信通知/コール処分セッションのためのOCCクライアントで新しいTCP / IPソケットを開きます。このソケット接続は、IPアドレスとOCC Clientソフトウェアを実行しているPC上であらかじめ設定されたポートを使用しています。
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は動的にSCP SPAとのTCP / IPセッションを開きます。 SCP SPAを介しOCCクライアントによって送信された着信SIP REGISTERメッセージに予め設定されたポートでリッスン
OCC Server. To exchange SIP messages with the OCC Server, the OCC Client dynamically opens a TCP/IP socket connection with the OCC Server using a pre-configured port number on the CSN and the CSN's IP address.
OCCサーバー。 OCC ServerとのSIPメッセージを交換するには、OCC Clientは、動的にCSNとCSNのIPアドレスで事前設定されたポート番号を使用してOCC Serverとの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 RINGINGメッセージが戻って転送するようにSSPを指示し、実際のSCP上で実行されているSCPのSPAに送信されますCSNへ発信者。ブリッジコールレッグの一つがダイヤルのVoIPコールバックDNが含まれています。このSIPメッセージは、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コールバックDNのリストがプロビジョニングされています。オンラインの加入者は、VoIP経由で着信を受けることを選択したときにこれらの特別なDNSが使用されています。特に、それらは特定のCSNへの加入者のNetMeetingから発信コールをルーティングするのを助けるために、SCPは、着信呼を転送する（略同時）です。 （これらの二つの呼び出しは、加入者のNetMeetingクライアントに着信呼を接続するためにCSNに結合されている。）さらに、これらの特別なDNがに加入者を呼び出してパーティーに参加するために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サービスプロバイダはSCPにOCC RTDBテーブルに加入者およびプロビジョニング、加入者DNおよびPINの記録を作成するためにSMSを使用します。
5. The subscriber is provided with the OCC Client software, a PIN and a file containing the OCC Server IP Addresses.
5.加入者は、OCC Clientソフトウェア、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コール処分の特定のシナリオを説明します。
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 ClientはOCC Serverに「380代替サービスをSIP」メッセージを送信します。このメッセージは、最終的に接続するPSTNコールレッグで（VoIPゲートウェイを経由して）加入者に接続するコールレッグを（すぐに加入者のNetMeetingによって開始される）を関連付けるためにCSNによって使用されるコールバックDNへの参照を含んでいます発信者。
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 Serverは、OCCのクライアントでTCP / IPセッションを閉じ、SCP SPAへのコールバックDNを含む「380代替サービスをSIP」メッセージを送信します。
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へ発信者を転送します。クライアントは、VoIP経由で電話を受けることを選択したときにコールバックDNことに注意してください、加入者が着信試みの存在に警告されたときに元々SCPによってOCCクライアントに割り当てられ、その後に、OCCサーバの隣に流れましたSCP、その転送されたコールに関連してCSNにOCCサーバに、その後、CSNへの着信呼を転送するSCPコマンドに関連して中央オフィスへ。
6. Meanwhile, the OCC Client extracts 1) the VoIP Call Back DN from the SIP INVITE message received during Call Notification and 2) the H323UID and H323PIN values from its properties file and updates the 'netmtg.cnf' file.
6.一方、OCCクライアントは、SIP呼通知中に受信INVITEメッセージから1）のVoIPコールバックDNを抽出し、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ゲートウェイの間で確立されると、NetMeetingは携帯電話の通話を開始 - 先DNとしてVoIPゲートウェイにコールバック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ゲートウェイは、VoIPゲートキーパーを参照して、H323UIDとH323PIN値を検証することにより、呼び出されたDNを確保することにより、NetMeetingの呼び出しを認証に使用するために許可されている（すなわち、DNをコールバック）。
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.
前記認証ステップ、（PSTNを介して）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.
SCPは、他のコールのためにそれを再利用できるように12. CSNは、ステータスおよび参照のSCP（SIP 180呼び出し音）コールバックDNを通知します。
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チャネル転送（ルーセント、ノーテル、そしておそらく他の中央オフィスベンダーの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：サービスコントロールポイント（SPIRITSクライアントとして機能）SSP：セントラルオフィスM / D：サービスはポイントCOスイッチングモデム
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)
インターフェース：P0：SPIRITSサーバ-SCP（SPIRITSクライアント）インタフェースP1：SPIRITSサーバICWクライアント・インターフェース・P2：ICWクライアントW3Sインターフェイス（HTTPを介してWebアクセス）P3：SCP-SSPインターフェイス（INAP）P4：SSP-COインタフェース（ 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.
顧客が特別なアクティベーションコードを挿入することによって、それらのISPに接続したときに1 COラインがICWサービスのためにプライミングされる（例えば、* 54）ISP電話番号の前に接頭辞。
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).
ユーザーがICWクライアントからSPIRITSサーバへのセキュアなセッションを開いたとき2. ICWサービスが起動されます。セッションが開いたら、SPIRITSサーバは（すなわち、それはユーザーのインターネット回線の電話番号とユーザーのIPアドレスを知っているだろう）ラインとPCとの間の関係を知ることができます。
3. When a call arrives at a busy Internet line, the SSP will trigger the ICW service. The SCP which acts as the SPIRITS client will inform the SPIRITS server that a call is terminating to a busy Internet line. The message will include the Caller ID and Calling Line Identify Restriction (CLIR) Status of the calling party, and DN of the busy line.
3.コールがビジーインターネット回線に到着すると、SSPは、ICWサービスをトリガします。 SPIRITSクライアントとして動作するSCPは、コールがビジーインターネット回線に終了しSPIRITSサーバに通知します。メッセージには、発信者IDが含まれており、回線がビジーラインの制限（CLIR）発信者の状況、およびDNを特定の呼び出します。
4. The SPIRITS server will verify that if an ICW session has been established for the busy line. If so, the SPIRITS server will communicate with the user's ICW client application. The user will receive a real-time pop-up dialogue box including the Calling Name and Number of the Calling Party if available. The user will then select one of the following call management options:
4. SPIRITSサーバは、ICWセッションがビジーラインのために確立された場合ことを確認します。もしそうなら、SPIRITSサーバは、ユーザのICWクライアントアプリケーションと通信します。利用可能な場合、ユーザーは発信者名およびコーリングパーティの数を含む、リアルタイムのポップアップダイアログボックスが表示されます。その後、ユーザは、次のコール管理オプションのいずれかを選択します：
- Answer the call (the Internet connection will be automatically dropped and the phone will ring) - Send the call to Voice Mail - Forward the call to another destination - Ignore the call
- （インターネット接続が自動的に削除され、電話が鳴ります）の呼び出しに応答する - ボイスメールにコールを送信する - 別の宛先にコールを転送 - コールを無視
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は、定期的に接続を開こうとします。 SPIRITSサーバに利用可能なすべての接続が使用されているように、SCPルーティングテーブルを構成します。
Two different types of message are used between the SCP and the SPIRITS server: "Connection Management Message Type" and the "Data Message Type". These messages will carry the remote operation messages which are based on ITU-T Q.1228 SCF-SCF interface with some NEC proprietary extensions.
「接続管理メッセージタイプ」と「データメッセージタイプ」：メッセージの2種類がSCPとSPIRITSサーバとの間で使用されています。これらのメッセージは、一部のNEC独自の拡張機能を持つITU-T Q.1228 SCF-SCFインタフェースに基づいており、遠隔操作メッセージを運ぶでしょう。
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
- SCFバインド - SCFアンバインド - 活性試験
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はSPIRITSサーバにscfBindのinvokationメッセージを送信します。このメッセージは、バージョン情報及び活動テスト間隔を運びます。
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のinvokationを受信すると、接続に関するすべてのデータがリセットされ、次いで、ウェブサーバ識別番号又は理由とリターンエラーを含む返信結果のいずれかで応答します。
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.
SCPにリターン結果を受信3.、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サーバは、ミリ秒単位で4回の活動テスト間隔値のためにSCPからの情報要求または活性試験の取り扱いの任意の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のinvokationがリモートエンドのいずれかSCPまたはSPIRITSサーバによって送信された接続を閉じます。 scfUnbindのinvokationメッセージを受信すると、受信端は、接続を終了すべきです。
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サーバにscfBindのinvokationを送信します。 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のinvokationを送信します。
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サーバはそのようなinvokationを受信すると、activityTestのリターン結果メッセージで応答します。
Its contents should be retained by the SPIRITS server. They are to be echoed back in the return result so that the message reply time can be calculated.
その内容はSPIRITSサーバによって保持されるべきです。彼らは、メッセージ応答時間を算出することができるように、戻り結果にエコーバックされることになります。
SCPs use the following operations, which are sent to the SPIRITS server via a Data-Message-Type message, to request execution of some service procedure or notification of an event that takes place at the SCPs:
SCPは、SCPので行われたイベントのいくつかのサービス手順や通知の実行を要求するために、データ・メッセージ・タイプのメッセージを介してSPIRITSサーバに送信され、次の操作を、使用します。
o handlingInformationRequest
O handlingInformationRequest
The handlingInformationRequest message will request a SPIRITS server the execution of some service procedure.
handlingInformationRequestメッセージがSPIRITSサーバにいくつかのサービス手順の実行を要求します。
o handlingInformationResult
その結果、O文書情報
The handlingInformationResult message will show the SCP the result of the execution, which was carried out by the SPIRITS server.
handlingInformationResultメッセージがSPIRITSサーバによって行われた実行、結果SCPが表示されます。
o confirmedNotificationProvided
O confirmedNotificationProvided
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サーバに指示します。 confirmedNotificationProvidedは「呼び出し側が放棄」を示すが受信された場合、SPIRITSサーバはconfirmedNotificationProvidedのためのSCPリターン結果を放棄し、送信呼び出し側のクライアントに通知します。
The invoked operation has always a response which is either a return result of the operation or an invokation of another operation.
呼び出されたオペレーションは、常に操作の戻り結果または別の動作のinvokationのいずれかである応答を有します。
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.
データメッセージが所定のタイムアウト期間内に回答されていない場合、メッセージは指定された回数を再送されます。回数を超えていたら、別のノードが存在する場合、それが利用可能な場合、メッセージは別のノードに送信されます。使用可能なすべてのSPIRITSサーバが照会されている場合は、メッセージタイムアウトは、呼び出しプロセスに返されます。
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のinvokationが原因= 63（サービス利用不可）で受信された場合、それが利用可能な場合、handlingInformationRequestは別のノードに送信されます。利用可能なすべてのSPIRITSの切断が原因その後、照会されている場合= 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サーバ）
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サーバ - > 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サーバ - > 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
ああkallinganumber
o CallingName
O CallingName
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サーバ）
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.
対応CallConnectがCallArrivalを送信した後、一定期間内に受信されない場合は、SPIRITSサーバはCallConnectかのように振る舞うだろう、取り扱い=無視が受信されていました。
o CallLost (SPIRITS server -> ICW client)
O CallLost（SPIRITSサーバ - > ICWクライアント）
Sent by server to cancel a CallArrival before a CallConnect is received by the server.
CallConnectがサーバによって受信される前にCallArrivalをキャンセルするためにサーバーによって送信されます。
5.3.3. Secure Reliable Hybrid Datagram Session Protocol (SRHDSP) for Use Between ICW Client Application and SPIRITS Server
5.3.3. ICWクライアントアプリケーションとSPIRITSサーバとの間で使用するための信頼性の高いハイブリッドデータグラムセッションプロトコル（SRHDSP）を確保
In principle the solution involves session initiation over SSL (meeting requirements for standards based security) after which the SSL session is closed, thereby reducing the number of simultaneous TCP/IP sessions. The rest of the session is communicated over UDP/IP, secured using keys and other parameters exchanged securely during the SSL session.
原則的には解決策は、SSL経由でセッション開始SSLセッションが、これにより、同時TCP / IPセッションの数を減らし、閉鎖された後（標準ベースのセキュリティのための会議の要件）を必要とします。セッションの残りの部分は、UDP / IPを介して通信のキーを使用して固定し、他のパラメータは、SSLセッション中に安全に交換されます。
The ICW client initiates an SRHDSP session, by reserving a UDP/IP port, and opening an SSL session with the service (e.g., ICW) on the service's well known SSL/TCP port. After establishing the SSL Session, the ICW client sends the server its IP address, the reserved UDP port number, and the set of supported symmetric key algorithms.
ICWクライアントは、UDP / IPポートを予約し、サービスの良く知られたSSL / TCPポート上のサービス（例えば、ICW）とSSLセッションを開くことで、SRHDSPセッションを開始します。 SSLセッションを確立した後、ICWクライアントは、サーバのIPアドレス、予約UDPポート番号、およびサポートされている対称鍵アルゴリズムのセットを送信します。
The server responds with a symmetric key algorithm chosen from the set, the server's UDP port for further communication, heartbeat period, and the value to use for the sequencing window.
サーバーはセット、さらに通信、ハートビート期間のためのサーバのUDPポート、およびシーケンシング・ウィンドウに使用する値から選ばれた共通鍵暗号で応答します。
The client then generates a symmetric key using the selected algorithm and transmits this to the server. The SSL session is then closed and the SRHDSP session is considered open.
クライアントは、選択されたアルゴリズムを使用して対称鍵を生成し、サーバに送信します。 SSLセッションが閉じられ、SRHDSPセッションを開いたと考えられています。
Application, and subsequent session management messages use symmetric signaling. That is, the signaling is the same whether the client is sending a message or the server is sending a message.
アプリケーション、およびその後のセッション管理メッセージは、対称シグナリングを使用しています。つまり、シグナリングは、クライアントがメッセージを送信しているか、サーバーがメッセージを送信しているかどうかと同じです。
The message packets are transmitted securely. The protocol corrects for lost, duplicated and out of sequence packets.
メッセージ・パケットを確実に送信されます。プロトコルは失われ、複製され、外のシーケンスパケットを補正します。
The client or server may close the session.
クライアントまたはサーバがセッションを閉じることができます。
A session is closed using a Close message including the next sequence number, and encrypted with the agreed key.
セッションは、次のシーケンス番号を含む閉じるメッセージを使用して閉じて、合意された鍵で暗号化されています。
The receiver, on processing (as opposed to receiving) a Close message, should set a timer, when the timer expires all details of the session should be forgotten. The timer is to allow for retransmission of the close if the Ack gets lost, we still need to be able to decrypt the subsequent retransmission and re-acknowledgment.
タイマーは、セッションのすべての詳細を忘れなければならない期限が切れる場合の処理で受信機（受信とは対照的に）閉じるメッセージは、タイマーを設定しなければなりません。タイマーは、ACKが失われた場合に近いの再送信を可能にすることで、我々はまだ、その後の再送信と再確認を解読できるようにする必要があります。
If any message other than a close is received after a close is processed, it is ignored.
近くには、処理された後にクローズ以外の任意のメッセージを受信した場合、それは無視されます。
The system implemented by Telia in cooperation with Nortel Networks is designed to support services that execute before the end-to-end media sessions are established. These services include, for example:
ノーテルネットワークスと協力しテリアによって実装されたシステムは、エンドツーエンドのメディアセッションが確立される前に実行するサービスをサポートするように設計されています。これらのサービスは、例えば：
- 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.
テリア/ノーテル・システムは、サービスプロバイダは、上記のサービスを開発することを可能にすることを目指しています。現在、オンラインの着信処分と（第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.
テリア/ノーテルのアーキテクチャでは、サービスは、SIPリダイレクトサーバー上で実行します。 SIPの分散性は、これらのサーバは、例えば、エンタープライズサーバ、サービスプロバイダのサーバ・クラスタ、ユーザのデスクトップPCで、あるいは手持ちコードレスデバイスで、ホストすることができます。
The SIP Redirect Server receives a SIP INVITE message for each call regardless of which network the call is being set up in. The server MAY apply any kind of service logic in order to decide on how to respond to the invitation. Service logic may interact with the user to allow the user to specify how to handle a call such as described in Section 2. This, however, is not the focus of the Telia/Nortel system.
SIPリダイレクトサーバは、SIPに関係なく、各コールのためのINVITEメッセージを受信するネットワークコールがで設定されている。サーバは、招待状に応答する方法を決定するために、サービスロジックのいずれかの種類を適用することができます。サービスロジックは、ユーザが第2節これに記載されているようなコールの処理方法を指定できるようにするために、ユーザと相互作用することができる、しかし、テリア/ノーテルシステムの焦点ではありません。
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.
アーキテクチャの背後にある一般的な考え方は、SIPが有効になったすべての通信は、IPおよびすべてのクライアントとサーバーに基づいていたかのようなサービスを作成することです。原因のこれは、既存の通信ネットワークでは真実ではありません。したがって、ネットワーク要素の新しいタイプは、サービスコントロールゲートウェイ（SCG）は、サービスからの真の状況を隠します。
SCGs convert network-specific call control signaling to SIP messages and vice versa. A SCG behaves as a regular SIP User Agent (UA) towards the services and as a network-specific service control node in the network where the call is being set up. For example, when connecting to a GSM network, the SCG can play the role of an SCP or a MAP or an ISUP proxy. The specific role depends on what service triggers are being used in the GSM network.
SCGのその逆メッセージをSIPとするネットワーク固有の呼制御シグナリングを変換します。 SCGは、サービスに向かって正規SIPユーザエージェント（UA）として、呼が設定されているネットワーク内のネットワーク固有のサービス制御ノードとして振る舞います。 GSMネットワークに接続する場合、例えば、SCGはSCPまたはMAPまたはISUPプロキシの役割を果たすことができます。具体的な役割は、サービスのトリガーはGSMネットワークで使用されているかに依存します。
SCGs handle protocol conversions but not address translation, such as telephone number to SIP URL, which is handled by a regular SIP Server to keep the SCG as simple as possible.
SCGのは、プロトコル変換を処理が、可能な限りシンプルなSCGを維持するために定期的なSIPサーバーによって処理されたURLを、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及び高性能SIPリダイレクトサーバは、数サーバ（NS）と呼ばれる、典型的には、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リダイレクトサーバ）に転送されます。
If the called number is not registered, then the NS will return "404 Not Found". The SCG interprets this as "non ported number" and returns a CON message to the CSN network, making it connect the call to the called number.
着信番号が登録されていない場合は、NSは「404が見つかりません」が返されます。 SCGは「非移植数」としてこれを解釈し、それが呼び出された番号に電話を接続して行う、CSNネットワークにCONメッセージを返します。
If the number is ported and hence registered, then the NS will return "301 Moved Permanently" with a TEL URL (routing number) in the contact field. The SCG then returns a CON message to the CSN network, making it connect the call to the number that was conveyed in the contact field.
数が移植され、したがって、登録されている場合、次にNSは、コンタクトフィールドにおけるTELのURL（ルーティング番号）と「301恒久的に移動」が返されます。 SCGは、それが接触フィールドで搬送された番号に呼を接続作り、CSNネットワークにCONメッセージを返します。
The solution above enables the same Number Server to provide Number Portability to multiple networks by means of using multiple SCGs.
上記溶液は、複数のSCGのを用いることによって複数のネットワークに番号ポータビリティを提供するために、同じ数のサーバーを可能にします。
If we make the SIP server in the number portability example operate in proxy mode for selected numbers, then it will become a kind of service router, able to relay number queries to any SIP-Redirect-Server-based service anywhere, provided there is an IP connection to the host in concern. Figure 12 shows the arrangement.
私たちは番号ポータビリティの例のSIPサーバは、選択された数字のプロキシモードで動作させる場合、それは存在して、任意の場所に任意のSIP-リダイレクト-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を参照して登録されています。これは、Number ServerプロキシSIPは、サービスのアドレスで登録したURLにINVITEメッセージを作ります。
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に応答を送信します。サービスからの応答は、Contactフィールドにおける電話番号と「302一時的に移動」は、典型的です。
If the response is 301 or 302, as the examples above suggest, then a telephone number is carried in the contact field. If the user can be reached via several different addresses, then all of them SHOULD be added to the response by means of multiple contact fields. The SCG then selects an address that is valid for the node or application that issued the number query.
応答が301または302である場合の例は、上記の示唆としては、電話番号を連絡先フィールドで搬送されます。ユーザーは、いくつかの異なるアドレスを介して到達することができた場合は、それらのすべては、複数の連絡先フィールドによって応答に追加する必要があります。 SCGはその後数のクエリを発行したノードまたはアプリケーションのための有効なアドレスを選択します。
As illustrated by the service examples, the Telia/Nortel system aims to allow the introduction of multi-network services without requiring multi-protocol support. The services hence operate in the same way regardless of in which network the call is made and common IP services can be shared across heterogeneous networks.
サービスの例によって示されるように、テリア/ノーテル・システムは、マルチプロトコルサポートを必要とすることなく、マルチネットワークサービスの導入を可能にすることを目的とします。サービスは、それゆえに関係なく、どのネットワークに呼び出しが行われると、共通の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.
テリア/ノーテル・アーキテクチャは、彼らは純粋な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のは、したがって、他の1つのネットワークからのシグナリング破壊サービス制御を防止する機構を含んでいなければなりません。例えば、PSTNに向かってインターネットユーザからのサービス拒否攻撃をブロックすることができ、ファイアウォール型機構。
Overall, the SPIRITS security requirements are essentially the same as those for PINT [3, 4], which include, for example:
全体として、SPIRITSセキュリティ要件は、本質的に、例えば、含まPINT [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とインターネットの間の相互のネットワークインターフェースの開発に関連する情報を提供してきました。具体的には、SPIRITSのようなサービスの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つの実装では、具体的には、それ用に設計された3で、ICWをサポートすることができます。
o SIP is used in most of the implementations as the based communications protocol between the PSTN and Internet. (NEC's implementation is the only exception that uses a proprietary protocol. Nevertheless, NEC has a plan to support SIP together with the extensions for SPIRITS services.)
O SIPは、PSTNとインターネットとの間のベースの通信プロトコルとして実装のほとんどで使用されています。 （NECの実装では、独自のプロトコルを使用しています唯一の例外である。それにもかかわらず、NECはSPIRITSサービスのための拡張機能と一緒にSIPをサポートするための計画を持っています。）
o All implementations use IN-based solutions for the PSTN part.
Oすべての実装は、PSTN部分のIN-ベースのソリューションを使用しています。
It is clear that not all pre-SPIRITS implementations inter-operate with each other. It is also clear that not all SIP-based implementations inter-operate with each other given that they do not support the same version of SIP. It is a task of the SPIRITS Working Group to define the inter-networking interfaces that will support inter-operation of the future implementations of SPIRITS services.
ないすべての前SPIRITS実装がお互いに相互運用することは明らかです。ないすべてのSIPベースの実装は、彼らがSIPの同じバージョンをサポートしていないことを考えるとお互いに相互動作することも明らかです。 SPIRITSサービスの将来の実装の相互運用をサポートする間のネットワーク・インタフェースを定義するSPIRITS作業部会の作業です。
[1] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, June 2000.
[1] 2000 Petrackと、S.とL.コンロイ、 "パイントサービスプロトコル：電話コールサービスへのIPアクセスのためのSIPとSDPへの拡張"、RFC 2848、2000年6月を。
[2] Handley, H., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[2]ハンドレー、H.、Schulzrinneと、H.、学生はE.およびJ.ローゼンバーグ、 "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]呂、H.（編）、Krishnaswamy、M.、コンロイ、L.、Bellovin氏、S.、ブルグ、F.、DeSimoneさん、A.、Tewani、F.、ダビッドソン、D.、Schulzrinneと、H 。そしてK. Vishwanathan、 "PSTNに向けて/インターネット間Networking--プリPINTの実装"、RFC 2458、1998年11月。
Igor Faynberg Lucent Technologies Room 4L-334 101 Crawfords Corner Road Holmdel, NJ, USA 07733-3030
イゴールFaynbergルーセント・テクノロジーズルーム4L-334 101 Crawfordsコーナー道路ホルムデル、NJ、USA 07733から3030
Phone: +1 732 949 0137 EMail: faynberg@lucent.com
電話：+1 732 949 0137 Eメール：faynberg@lucent.com
Hui-Lan Lu Lucent Technologies Room 4L-317 101 Crawfords Corner Road Holmdel, NJ, USA 07733-3030
ホイ-LAN呂ルーセント・テクノロジーズルーム4L-317 101 Crawfordsコーナー道路ホルムデル、NJ、USA 07733から3030
Phone: +1 732 949 0321 EMail: huilanlu@lucent.com
電話：+1 732 949 0321 Eメール：huilanlu@lucent.com
John Voelker Lucent Technologies Room 1A-417 263 Shuman Blvd PO Box 3050 Naperville, IL, USA 60566-7050
ジョンVoelkerルーセント・テクノロジーズルーム1A-417 263シューマンブルバード私書箱3050ネーパーヴィル、IL、USA 60566から7050
Phone: +1 630 713 5538 EMail: jvoelker@lucent.com
電話：+1 630 713 5538 Eメール：jvoelker@lucent.com
Mark Weissman Lucent Technologies Room NE406B 200 Lucent Lane Cary, NC, USA 27511-6035
マーク・ワイスマンルーセント・テクノロジーズルームNE406B 200ルーセントレーンカリー、NC、USA 27511から6035
Phone: +1 919 463 3258 EMail: maw1@lucent.com
電話：+1 919 463 3258 Eメール：maw1@lucent.com
Weizhong Zhang Lucent Technologies Room 01-A5-17 2000 Regency Parkway Cary, NC, USA 27511-8506
Weizhong張ルーセント・テクノロジーズルーム01-A5-17 2000リージェンシーパークウェイカリー、NC、USA 27511から8506
Phone: +1 919 380-6638 EMail: wzz@lucent.com
電話：+1 919 380-6638 Eメール：wzz@lucent.com
Sung-Yurn Rhim Korea Telecom 17 Woomyun-dong Seocho-gu, Seoul, Korea
宋-Yurn Rhim韓国通信17 Woomyun洞瑞草区、ソウル、韓国
Phone: +82 2 526 6172 EMail: syrhim@kt.co.kr
電話：+82 2 526 6172 Eメール：syrhim@kt.co.kr
Jinkyung Hwang Korea Telecom 17 Woomyun-dong Seocho-gu, Seoul, Korea
Jinkyungファン・韓国通信17 Woomyun洞瑞草区、ソウル、韓国
Phone: +82 2 526 6830 EMail: jkhwang@kt.co.kr
電話：+82 2 526 6830 Eメール：jkhwang@kt.co.kr
Shinji. Ago NEC Corporation 1131, Hinode, Abiko, Chiba, 270-1198, Japan
しんじ。 あご ねＣ こｒぽらちおん １１３１、 ひので、 あびこ、 ちば、 ２７０ー１１９８、 じゃぱん
Phone: +81 471 85 7412 EMail: ago@ssf.abk.nec.co.jp
電話：+81 471 85 7412 Eメール：ago@ssf.abk.nec.co.jp
S. Moeenuddin NEC America, Inc 1525 Walnut Hill Lane, Irving, TX, USA 75038
S. Moeenuddin NECアメリカ社1525ウォルナットヒルレーン、アーヴィング、TX、USA 75038
Phone: +1 972 518 5102 EMail: moeen@asl.dl.nec.com
電話：+1 972 518 5102 Eメール：moeen@asl.dl.nec.com
S. Hadvani NEC America, Inc 1525 Walnut Hill Lane, Irving, TX, USA 75038
S. Hadvani NECアメリカ社1525ウォルナットヒルレーン、アーヴィング、TX、USA 75038
Phone: +1 972 518 3628 EMail: hadvani@asl.dl.nec.com
電話：+1 972 518 3628 Eメール：hadvani@asl.dl.nec.com
Soren Nyckelgard Telia Research Chalmers Teknikpark 41288 Gothenburg Sweden
ソレンキーガールテリア研究チャルマーズの科学41288ヨーテボリスウェーデン
EMail: soren.m.nyckelgard@telia.se
メールアドレス：soren.m.nyckelgard@telia.se
John Yoakum Nortel Networks 507 Airport Blvd, Suite 115, Morrisville, NC, USA 27560
ジョン・ヨーカムノーテルネットワーク507エアポートブルバード、スイート115、モリスビル、NC、USA 27560
EMail: yoakum@nortelnetworks.com
メールアドレス：yoakum@nortelnetworks.com
Lewis Robart Nortel Networks P.O. Box 402 Ogdensburg, NY, USA 13669
ルイスROBART Nortel Networksの私書箱ボックス402オグデンズバーグ、NY、USA 13669
EMail: robart@nortelnetworks.com
メールアドレス：robart@nortelnetworks.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。