RFC2995 日本語訳
2995 Pre-Spirits Implementations of PSTN-initiated Services. H. Lu,Ed., I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S. Rhim, J.Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J. Yoakum,L. Robart. November 2000. (Format: TXT=96427 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループH.Lu、コメントを求めるエディタ要求をネットワークでつないでください: 2995年のI.Faynbergカテゴリ: 情報のJ.のS.Rhim J.ファン韓国Voelker M.ワイズマンW.チャンルーセントテクノロジーズテレコムS.前、S.Moeenuddin S.Hadvani NEC S.Nyckelgard Telia J.Yoakum L.Robartノーテルは2000年11月をネットワークでつなぎます。
Pre-SPIRITS Implementations of PSTN-initiated Services
PSTNによって開始されたサービスのプレスピリッツ実装
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document contains information relevant to the work underway in The Services in the PSTN/IN Requesting InTernet Services (SPIRITS) Working Group. It describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN.
このドキュメントはPSTN/IN Requesting InTernet Services(SPIRITS)作業部会でServicesの進行中の仕事に関連している情報を含んでいます。 それはノーテルNetworksと提携して韓国テレコム、ルーセントテクノロジーズ、日本電気、およびTeliaから4つの既存のSPIRITSのようにサービスの実装について説明します。 SPIRITSのようなサービスはPublic Switched Telephone Network(PSTN)で起こって、インターネットとPSTNの相互作用を必要とするものです。
Lu, et al. Informational [Page 1] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[1ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
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 ベースコミュニケーションがPSTNとインターネットの間で議定書を作るとき、セッションInitiationプロトコル(SIP)は実装の大部分に使用されます。 (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サービスの実装のinteroperationをサポートするインターネットワーキングインタフェースを定義するSPIRITS作業部会に関するタスクです。
Table of Contents
目次
1. Introduction ................................................ 3 2. Service Description of Internet Call Waiting ................ 4 3. Korea Telecom's ICW Implementation .......................... 5 3.1. Overview .................................................. 5 3.2. Network Architecture ...................................... 6 3.3. Network Entities .......................................... 7 3.3.1. SSP ..................................................... 7 3.3.2. SCP ..................................................... 7 3.3.3. IP ...................................................... 7 3.3.4. ICW Server System ....................................... 7 3.3.5. ICW Client System ....................................... 8 3.3.6. Firewall ................................................ 9 3.4. Network Interfaces ........................................ 9 3.5. Protocols ................................................. 9 3.5.1. Intelligent Network Application Part Protocol (INAP) .... 9 3.5.2. PINT Protocol ........................................... 9 3.6. Example Scenarios ........................................ 11 3.6.1. ICW Service Subscription ................................ 11 3.6.2. ICW Client Installation ................................. 11 3.6.3. ICW Service Activation .................................. 12 3.6.4. Incoming Call Notification .............................. 14 3.6.5. Incoming Call Processing ................................ 15 3.6.5.1. Accept the Call ....................................... 16
1. 序論… 3 2. インターネットキャッチホンの記述を修理してください… 4 3. 韓国テレコムのICW実装… 5 3.1. 概要… 5 3.2. ネットワークアーキテクチャ… 6 3.3. 実体をネットワークでつないでください… 7 3.3.1. SSP… 7 3.3.2. SCP… 7 3.3.3. IP… 7 3.3.4. ICWサーバシステム… 7 3.3.5. ICWクライアントシステム… 8 3.3.6. ファイアウォール… 9 3.4. インタフェースをネットワークでつないでください… 9 3.5. プロトコル… 9 3.5.1. インテリジェントネットワークアプリケーション部分プロトコル(INAP)… 9 3.5.2. パイントプロトコル… 9 3.6. 例のシナリオ… 11 3.6.1. ICWは購読を修理します… 11 3.6.2. ICWクライアントインストール… 11 3.6.3. ICWは起動を修理します… 12 3.6.4. かかってきた電話通知… 14 3.6.5. かかってきた電話処理… 15 3.6.5.1. 呼び出しを受け入れてください… 16
Lu, et al. Informational [Page 2] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[2ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
3.6.5.2. Forward the Call to Another Number .................... 18 3.6.6. ICW service De-activation ............................... 20 4. The Lucent Technologies Online Communications Center ........ 21 4.1 Overview ................................................... 21 4.2. Architecture .............................................. 22 4.3. Protocol and Operations Considerations .................... 25 5. NEC's Implementation ........................................ 28 5.1. Overview .................................................. 28 5.2. Architecture and Overall Call Flow ........................ 29 5.3. Interfaces and Protocols .................................. 31 5.3.1. SCP (SPIRITS Client)-SPIRITS Server Interface ........... 31 5.3.1.1. Connecting to SPIRITS Services ........................ 31 5.3.1.2. Message Types ......................................... 31 5.3.1.2.1 Connection Management Message Type ................... 31 5.3.1.2.2. Data Message Type ................................... 33 5.3.2. SPIRITS Server-ICW Client Application Interface ......... 34 5.3.3. Secure Reliable Hybrid Datagram Session Protocol (SRHDSP) for Use .............................................. 35 5.3.3.1. Overview .............................................. 35 5.3.3.2. Session Initiation .................................... 35 5.3.3.3. Secure Reliable Datagram Transport .................... 36 5.3.3.4. Session closure ....................................... 36 6. Telia/Nortel's Implementation ............................... 36 6.1. Overview .................................................. 36 6.2. Architecture and Protocols ................................ 37 6.3. Security .................................................. 39 7. Security Considerations ..................................... 40 8. Conclusion .................................................. 40 9. References .................................................. 41 10. Authors' Addresses ......................................... 41 11. Full Copyright Statement ................................... 44
3.6.5.2. もう1つの数に呼び出しを送ってください… 18 3.6.6. ICWはDe-起動を修理します… 20 4. ルーセントテクノロジーズのオンラインコミュニケーションセンター… 21 4.1概要… 21 4.2. アーキテクチャ… 22 4.3. プロトコルと操作問題… 25 5. NECの実装… 28 5.1. 概要… 28 5.2. アーキテクチャと総合的な呼び出しは流れます… 29 5.3. インタフェースとプロトコル… 31 5.3.1. SCP(スピリッツクライアント)はサーバインタフェースに生気を与えさせます… 31 5.3.1.1. スピリッツサービスに接続します… 31 5.3.1.2. メッセージタイプ… 31 5.3 .1 .2 .1 接続管理メッセージタイプ… 31 5.3.1.2.2. データメッセージタイプ… 33 5.3.2. スピリッツサーバ-ICWクライアントHTTPサーバとNETSCAPE間のインタフェース… 34 5.3.3. 使用のために信頼できるハイブリッドデータグラムがセッションプロトコル(SRHDSP)であると機密保護してください… 35 5.3.3.1. 概要… 35 5.3.3.2. セッション開始… 35 5.3.3.3. 信頼できるデータグラムが輸送であると機密保護してください… 36 5.3.3.4. セッション閉鎖… 36 6. 冬胞子堆/ノーテルの実装… 36 6.1. 概要… 36 6.2. アーキテクチャとプロトコル… 37 6.3. セキュリティ… 39 7. セキュリティ問題… 40 8. 結論… 40 9. 参照… 41 10. 作者のアドレス… 41 11. 完全な著作権宣言文… 44
1. Introduction
1. 序論
This document contains information relevant to the work underway in The Services in the PSTN/IN Requesting InTernet Services (SPIRITS) Working Group. It describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN.
このドキュメントはPSTN/IN Requesting InTernet Services(SPIRITS)作業部会でServicesの進行中の仕事に関連している情報を含んでいます。 それはノーテルNetworksと提携して韓国テレコム、ルーセントテクノロジーズ、日本電気、およびTeliaから4つの既存のSPIRITSのようにサービスの実装について説明します。 SPIRITSのようなサービスはPublic Switched Telephone Network(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.
不変的に実装によって本書では調べられた状態でサポートされているのは、インターネットCall Waiting(ICW)サービスです。 サービス加入者は、インターネット・アクセスに彼らの電話回線を使用している間、ICWと共に、入って来る音声通話について通知されて、同じ電話回線の上に呼び出しを扱う方法を指定できます。
Lu, et al. Informational [Page 3] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[3ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
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サーバ」という用語がドキュメント中で使用されますが、それにはどんな普遍的な意味もないことに注意するのは重要です。 含蓄は、文脈によって、実装によって異なります。
2. Service Description of Internet Call Waiting
2. インターネットキャッチホンのサービス記述
Internet call waiting is the single service that is specifically supported by all the implementations in question. In a nutshell, the service enables a subscriber engaged in an Internet dial-up session to
インターネットキャッチホンは問題のすべての実装で明確に後押しされているただ一つのサービスです。 殻では、サービスはインターネットダイヤルアップセッションに従事している加入者を可能にします。
o be notified of an incoming call to the very same telephone line
that is being used for the Internet connection;
o かかってきた電話についてインターネット接続に使用されている全く同じ電話回線に通知されてください。
o specify the desirable treatment of the call; and
o 呼び出しの望ましい処理を指定してください。 そして
o have the call handled as specified.
o 指定されるとして呼び出しを扱わせてください。
The details of the ICW service lie in the ways that a waiting call can be treated, which vary from implementation to implementation. In this section, we describe the features that are supported by at least one of the implementations. They are as follows:
ICWサービスの詳細が待ち呼び出しを扱うことができる方法であります。(実装によって方法は異なります)。 このセクションで、私たちは少なくとも実装の1つによってサポートされる特徴について説明します。 それらは以下の通りです:
o Incoming Call Notification - The subscriber is notified of an
incoming call over the Internet, without having any effect on the
telephone line that is being used by the modem. When a call comes
in, the subscriber is presented with a pop-up dialog box on the
PC. The dialog box may display any combination of the calling
party number, calling party name, and calling time. Note that the
display of the calling party name (or number) requires the
availability of the caller name (or number) delivery feature.
o 入って来るCall Notification--加入者はインターネットの上のかかってきた電話について通知されます、モデムによって使用されている電話回線にどんな影響も与えないで。 呼び出しが入るとき、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 オンラインIncoming Call Disposition--かかってきた電話についていったん知らされると、加入者には、様々なオプションが、呼び出しを扱うためにあります(ポップアップウィンドウでは、示されます)。 可能なオプションは以下の通りです。
+ 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
+ 呼び出しを拒絶すること。
Lu, et al. Informational [Page 4] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[4ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
+ 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
+ もう1つの数に呼び出しを送ること。
+ 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.
+ ダイアログボックスを表示して、加入者によって事前に定義された処理に基づいてかかってきた電話を拒絶されるか、または扱われることができた後に加入者が、ある期間の時以内に応じないなら、どんなResponseでも拒絶しません(または、Forwarding)。
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 自動Incoming Call Disposition--かかってきた電話はその人のリアルタイムの介入なしで加入者によって事前に定義された気質に基づいて自動的に扱われます。 加入者は呼び出しのためのカスタム設計された気質と同様に一般通話のために、特定の数からデフォルト気質(例えば、ボイスメールに再向けられる)を事前に定義できます。 後者の場合では、加入者は、それぞれのために数を溯源しながら特定の気質を選択して、プロフィールにこの情報を保存します。 呼び出しが入ると、加入者は、呼び出しが提示されませんが、訪問者ログから呼び出しの処理と結果を調べることができます(通話記録弾丸で説明されるように)。 また、当然、この特徴で、加入者は個人的であるか未発表の数から発する呼び出しに関する必要な処理を指定できます。
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 複数のCall Handling--複数の呼び出しが呼び出し気質処理の間、到着できます。 複数の呼び出し取り扱いで、加入者は複数の呼び出しについてひとつずつ通知されます。
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 Loggingに電話をしてください--ICWサービスの間に処理されたかかってきた電話に関する詳細な航海日誌は保たれます。 丸太のままで記録された典型的な情報はかかってきた電話日時、起呼側番号、起呼側名、および呼び出し気質を含んでいます。
3. Korea Telecom's ICW Implementation
3. 韓国テレコムのICW実装
3.1. Overview
3.1. 概要
Korea Telecom's ICW implementation supports most of the features described in Section 2. (The major exception is the feature of receiving the incoming call over the Internet using voice over IP.) In addition, the Korea Telecom implementation supports flexible activation and de-activation of the ICW service:
韓国テレコムのICW実装はセクション2で説明された特徴の大部分をサポートします。 (主要な例外はIPの上で声を使用することでインターネットの上にかかってきた電話を受ける特徴です。) さらに、韓国テレコム実装はICWサービスのフレキシブルな起動と非活性化をサポートします:
Lu, et al. Informational [Page 5] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[5ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
o Automatic Activation/De-activation - When Internet dial-up
connection is set up, the ICW service is activated or de-activated
automatically.
o 自動Activation/非活性化--インターネットダイアルアップ接続がセットアップされるとき、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 手動のActivation/非活性化--必要であると、加入者は、呼び出し通知がインターネットダイヤルアップセッションの間望まれていないとき、反-手動でICWサービスを起動して、それを動かすことができます。
3.2. Network Architecture
3.2. ネットワークアーキテクチャ
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サービスのネットワークアーキテクチャについて表現します。 Service Switching Point(SSP)、Service Control Point(SCP)、およびIntelligent Peripheral(IP)はIN CS-1に基づくレガシーPSTN IN要素です。 対照的に、ICW Server SystemとICW Client Systemの両方がサポートするインターネットドメインにインストールされるICWサービスの新しいネットワーク要素です。
+---------------------------+ | +--------------+
|+--------+propr-+---------+| PINT | |(Proxy Server)| PINT
||(ICW SL)|ietary|(UAC/UAS)||--- -||-----| ICW |----+
||SCF/SDF |------| SCGF || firewall |Server System | |
|+--------+ i/f +---------+| | +------------- + |
| SCP | | |
+------+--------------+-----+ | |
|INAP |INAP | firewall=====
| | | |
+---+---+ +---+---+ |
| IP | | SSP | |
+-------+ +---+---+ +-------------+
| +---+ | (UAC/UAS) |
+---+---+ || || | ICW |
|---------| LEX |-------------- + + |Client System|
+---+ +-------+ +++++----+-------------+
|| || (callee)
+ + ICW Subscriber's Phone and PC
+++++
(caller)
+---------------------------+ | +--------------+ |+--------+ propr-+---------+| パイント| |(Proxyサーバ)| パイント||(ICW SL)|ietary|(UAC/UAS)||--- -||-----| ICW|----+ ||SCF/SDF|------| SCGF|| ファイアウォール|サーバシステム| | |+--------+ i/f+---------+| | +------------- + | | SCP| | | +------+--------------+-----+ | | |INAP|INAP| ファイアウォール===== | | | | +---+---+ +---+---+ | | IP| | SSP| | +-------+ +---+---+ +-------------+ | +---+ | (UAC/UAS) | +---+---+ || || | ICW| |---------| 法|-------------- + + |クライアントシステム| +---+ +-------+ +++++----+-------------+ || || (訪問される人) + + ICW加入者電話とPC++の+++(訪問者)
INAP : Intelligent Network Application Protocol
PINT : PSTN/Internet Interworking Protocol
SL : Service Logic
UAS : User Agent Server
UAC : User Agent Client
INAP: インテリジェントネットワークアプリケーション・プロトコルパイント: プロトコルSLを織り込むPSTN/インターネット: 論理UASを調整してください: ユーザエージェントサーバUAC: ユーザエージェントのクライアント
Figure 1: Network Architecture of the Korea Telecom ICW Service
図1: 韓国テレコムICWサービスのネットワークアーキテクチャ
Lu, et al. Informational [Page 6] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[6ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
3.3. Network Entities
3.3. ネットワーク実体
3.3.1. SSP
3.3.1. SSP
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はService Switching Function(SSF)とCall Control Function(CCF)を実行します。 それを検出して、被呼者が忙しいときに(T_Busy)、SSPは質問をSCPに送って、SCPのコントロールの下で呼び出しを処理します。
3.3.2. SCP
3.3.2. 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はService Control Function(SCF)とService Data Function(SDF)を実行します。 質問されると、それは、サービス論理に基づく呼び出しを処理するようSSPに命令します。 ICWサービスの場合では、サービス論理は結局、オンラインICW加入者と呼び出しの気質に待ち呼び出しの通知を支配します。 さらに、SCPはPSTN/INとインターネットの間のプロトコルの織り込むために、Service ControlゲートウェイFunction(SCGF)を実行します。 それはICW Serverからサービス制御インタフェースメッセージと万力versaまでSIPメッセージを翻訳します。 SCGFはIPエンドポイントであり、UAS(ユーザエージェントサーバ)かUAC(ユーザエージェントのクライアント)として振る舞います。
3.3.3. IP
3.3.3. IP
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はService Resource Function(SRF)を含んでいます。 それは、必要であるときに、ICW加入者から応答を受けた後の/の前にICWサービスの間、起呼側に発表をプレーして、VoiceメールSystem(VMS)に呼び出しを送るとき、起呼側から起呼側番号か音声メールを記録します。
3.3.4. ICW Server System
3.3.4. ICWサーバシステム
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システムはICW ClientとSCGFの間のメッセージルーティングのためのSIPプロキシか再直接のサーバとして勤めます。 また、ICW Serverもそれに接続されるICW Clientsを管理するのに責任があります。 ICW Client(加入者)がICWサービスを求める登録要求を送るとき、ICW Serverはその要求をSCPにリレーして、SCPから承認の結果を待っていて、データベースの中に認可された加入者を登録します。 さらに、ICW Serverは登録されたICW Clientsの接続形態をモニターします。 クライアントがICWサービスを非活性化するか、またはインターネット接続を終えるとすぐに、ICW Serverは状態変化を検出して、クライアントのためにICWサービスを非活性化します。 最終的に、ICW Serverは各ICWのためのプロフィールを管理します。すべての呼び出し処理を登録するとき、また、加入者は結果になります。
Lu, et al. Informational [Page 7] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[7ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
3.3.5. ICW Client System
3.3.5. 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 Client Systemは加入者のPCの上で作業するアプリケーション・プログラムです。 PCの上の加入者強国の次第進水して、それはPC(または、加入者)のインターネット接続形態をモニターします。 インターネットとの加入者の接続のときに、ICW Clientは結局、次に、ICW Serverを通してSCGFへのREGISTRATION要求をSCPに送ります。 この容量では、ICW ClientはUACとしてSCGFに機能します。(SCGFはUASとして機能します)。 その後、それは定期的に加入者の接続形態について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にAccept、Reject、Forwardを含めて)。 加入者がオプションを選択した後に、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 Service Profileによって、加入者に通知する前に、ICW Clientはかかってきた電話を上映するかもしれません。
The ICW Client manages the ICW Service Profile, which contains the following fields:
ICW ClientはICW Service Profileを管理します:(ICW Service Profileは以下の分野を含みます)。
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.
Answer(廃棄物/フォワード/VMS)の上の+呼び出しProcessing Method--加入者が事前に定義された期間の後に応じないなら、呼び出しはメソッドで自動的に扱われます。
+ Do Not Disturb Mode (On/Off) - When this is set on, the subscriber
won't be notified of the incoming calls.
+はNot Disturb Mode(オンであるかオフな)をします--これが設定されるとき、オンであることで、加入者はかかってきた電話について通知されないでしょう。
+ 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.
+はCallingパーティ民数記でProcessing Listを呼びます(/廃棄物/フォワード/VMSを受け入れてください)--リストの数から溯源された呼び出しは関連呼び出し処理メソッドで扱われます。
o The ICW Client records the call processing method and the result
for each incoming call in a log file on the subscriber's PC. The
o ICW Clientはログファイルにおける各かかってきた電話のために呼び出し処理メソッドと結果を加入者のPCに記録します。 The
Lu, et al. Informational [Page 8] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[8ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
call record in the call log contains the following information:
通話記録での呼び出し記録は以下の情報を含んでいます:
- Calling Time - Calling Party Number - Calling Party Name (optional) - Call Processing Method (Accept/Reject/Forward/Forward to VMS) - Result (Success/Fail)
- パーティを数と呼ぶという起呼側が命名する(任意の)時間(呼び出し処理メソッド(VMSに受け入れるか、拒絶する、送る、または送る))を結果と呼びます。(/が失敗する成功)
3.3.6. Firewall
3.3.6. ファイアウォール
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サーバの間には、パケットFiltering Firewall Systemsは、韓国テレコムIN Nodesにアクセスするためにあります。
3.4. Network Interfaces
3.4. ネットワーク・インターフェース
o The SCF-SDF, SCF-SSF, and SCF-SRF interfaces are the same as
existing PSTN IN Interfaces based on the KT INAP CS-1.
o SCF-SDF、SCF-SSF、およびSCF-SRFインタフェースはKT INAP CS-1に基づく既存のPSTN IN Interfacesと同じです。
o The SCGF-SCF interface relays requests either from the IN or the
Internet and is implemented based on the internal API of the SCP.
o SCGF-SCFインタフェースは、INかインターネットから要求をリレーして、SCPの内部のAPIに基づいて実装されます。
o The SCGF-ICW Server and ICW Server-ICW Client interfaces are
implemented based on the PINT Service Protocol V.1. We adopted
UAS-Proxy-UAC relationships as shown in Figure 2.
o SCGF-ICW ServerとICW Server-ICW ClientインタフェースはPINT ServiceプロトコルV.1に基づいて実装されます。 私たちは図2に示されるようにUASプロキシUAC関係を採用しました。
+---------+ +-------------+ +---------+
|(UAC/UAS)|PINT 1.0| (Proxy) |PINT 1.0|(UAC/UAS)|
| |--------| ICW |--------| ICW |
| SCGF | | Server | | Client |
+---------+ +-------------+ +---------+
+---------+ +-------------+ +---------+ |(UAC/UAS)|パイント1.0| (プロキシ) |パイント1.0|(UAC/UAS)| | |--------| ICW|--------| ICW| | SCGF| | サーバ| | クライアント| +---------+ +-------------+ +---------+
Figure 2: PINT Protocol Architecture
図2: パイントプロトコルアーキテクチャ
3.5. Protocols
3.5. プロトコル
3.5.1. Intelligent Network Application Part Protocol (INAP)
3.5.1. インテリジェントネットワークアプリケーション部分プロトコル(INAP)
The SCP, SSP, and IP support the KT INAP V1.0, which is based on ITU-T INAP CS-1 with the incorporation of two INAP CS-2 messages [PRM (PromptAndReceiveMessage) and EM (EraseMessage)] for recording the voice message.
SCP、SSP、およびIPはKT INAP V1.0をサポートします。(KT INAP V1.0は音声メールを記録することへの2つのINAP CS-2メッセージ[PRM(PromptAndReceiveMessage)とEM(EraseMessage)]の編入があるITU-T INAP CS-1に基づいています)。
3.5.2. PINT Protocol
3.5.2. パイントプロトコル
The ICW service uses the PINT Service Protocol 1.0 [1] for communications between the SCP and the ICW Server System, and between the ICW Server System and the ICW Client System. Developed in the
ICWサービスはPINT Serviceプロトコルを使用します。SCPとICW Server Systemと、ICW Server SystemとICW Client Systemとのコミュニケーションのための1.0[1]。 展開します。
Lu, et al. Informational [Page 9] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[9ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
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.
IPネットワークから電話サービスを呼び出すためのIETF PINT作業部会、PINT Serviceプロトコル1.0はSIP2.0とSDPに1セットの増進を指定します。
Summarized below are the elements of the PINT Service Protocol 1.0 relevant to the Korea Telecom ICW implementation:
以下へまとめられているのは、韓国テレコムICW実装に関連しているPINT Serviceプロトコル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は加入者のIPアドレス(PCの)と電話番号をICW Serverに送ります。 ICWサーバは、データベース(加入者が認可されているなら)をアップデートするSCPへの情報をリレーして、結局、ICW Serverと次に、Clientに登録承認を送ります。 加入者がインターネットに接続された後に、ICW Clientは、接続形態を示すために定期的に事前に定義された間隔(例えば、20秒)で、REGISTER要求をICW Serverに送ります。 要求はSCPにリレーされません。 ICW Serverは、それが認可された加入者から来ているかをチェックするだけです。 最終的に、加入者がインターネット接続を終えると、ClientはICW Serverを通して最後のREGISTER要求をSCPに送ります。また、REGISTER要求が事前に定義された間隔の間、到着しないなら、ICW ServerはICW Clientの接続形態の変化を検出できます。
o INVITE
o 招待
The SCP uses the INVITE method to notify the ICW Client, via the
ICW Server, of an incoming call.
SCPはICW Serverを通してかかってきた電話についてICW Clientに通知するINVITEメソッドを使用します。
o ACK
o ACK
Both the SCP and the ICW Server use the ACK method to confirm the
receipt of the final responses to their requests.
SCPとICW Serverの両方が彼らの要求への最終的な応答の領収書を確認するACKメソッドを使用します。
o BYE
o さようなら
The BYE method terminates a service session. In addition to this
original usage, we use the value (success or failure) of the
Subject header to indicate the result of the desired disposition
of an incoming call in the PSTN.
BYEメソッドはサービスセッションを終えます。 このオリジナルの用法に加えて、私たちは、PSTNのかかってきた電話の必要な気質の結果を示すのに、Subjectヘッダーの値(成否)を使用します。
Lu, et al. Informational [Page 10] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[10ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
o CANCEL
o キャンセル
When the calling party releases the call before the called party
responds, the SCP sends a CANCEL request to the ICW Client to
cancel the INVITE request that it sent previously.
被呼者が応じる前に起呼側が呼び出しをリリースするとき、SCPは、以前に発信したというINVITE要求を中止するためにキャンセル要求をICW Clientに送ります。
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はREGISTER要求に以下でのステータスコードと関連コメントの1つで応じます:
. 100 Trying: Trying
. 200 OK: Registered
.100 試みます: トライ. 200は以下を承認します。 登録されます。
The ICW Client responds to an INVITE request with one of the
status codes and associated comments below:
ICW ClientはINVITE要求に以下でのステータスコードと関連コメントの1つで応じます:
. 100 Trying: Trying
. 200 OK: Accept the Call
. 303 see other: Forward the Call to Another Number
. 380 alternative service: Forward the Call to the VMS
. 603 decline: Reject the Call
.100 試みます: トライ. 200は以下を承認します。 .303が他であるのを見るCallを受け入れてください: Another Number. 380の代替のサービスにCallを送ってください: 前方に、VMS. 603へのCallは減退します: 呼び出しを拒絶してください。
3.6. Example Scenarios
3.6. 例のシナリオ
3.6.1. ICW Service Subscription
3.6.1. ICWサービス購読
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サービスプロバイダーに役立ちます。 購読データが、関連SSPsにロードされる必要に注意してください、韓国テレコムによって運用されないかもしれない地方のものを含んでいて。
3.6.2. ICW Client Installation
3.6.2. ICWクライアントインストール
An ICW subscriber should install the ICW Client program in his or her PC. The ICW Client is automatically activated to run as a daemon process when the subscriber's PC is turned on. The Client monitors the Internet connection status of the subscriber.
ICW加入者はICW Clientプログラムをその人のPCにインストールするべきです。 ICW Clientは、加入者のPCがつけられているとき、デーモンプロセスとして稼働するために自動的に動きます。 Clientは加入者のインターネット接続形態をモニターします。
Lu, et al. Informational [Page 11] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[11ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
3.6.3. ICW Service Activation
3.6.3. ICWサービス起動
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を通してディレクトリ番号とIPアドレスでREGISTER要求を送ることによって、ICW ClientからSCPまでそれをします。
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling
ICW Client party
(DN1/IP1) (IP2) (IP3) (DN2)
| | | | | |
0A | | | | |
0BREG(DN1,IP1)| | | | |
1 |----------->|REG(DN1,IP1)| | | |
2 | |----------->| | | |
| | 2A | | |
| | |reg(DN1,IP1)| | |
3 | | |-.-.-.-.-.->| | |
| | | 3A | |
| | | reg ok 3B | |
4 | | |<-.-.-.-.-.-| | |
| | 200 OK 4A | | |
5 | |<-----------| | | |
| 200 OK 5A | | | |
6 |<-----------| | | | |
6A | | | | |
| | | | | |
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling ICW Clientパーティー(DN1/IP1)(IP2)(IP3)(DN2)| | | | | | 0A| | | | | 0BREG(DN1、IP1)| | | | | 1 |、-、-、-、-、-、-、-、-、-、--、>|レッジ(DN1、IP1)| | | | 2 | |、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| 2A| | | | | |reg(DN1、IP1)| | | 3 | | |-.-.-.-.-.->|、|、|、|、|、| 3A| | | | | regの間違いない3B| | 4 | | | <、-.-.-.-.-.-| | | | | 200 OK4A| | | 5 | | <、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| 200 OK5A| | | | 6 | <、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| 6A| | | | | | | | | | |
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> Bearer
----->のパイントのプロトコルの-.-.>SCP内部のアピ--、-->INAPが+ + + + + >ISUPプロトコルについて議定書の中で述べる=====>運搬人
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.
(ICW加入者の0A)は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 Serverに送ります。
2. The ICW Server relays registration request to the SCGF.
2. ICW Serverは登録要求をSCGFにリレーします。
Lu, et al. Informational [Page 12] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[12ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
2A. The SCGF translates the user registration information from the SIP message to the SCP internal API message.
2A。 SCGFはSIPメッセージから内部のSCP APIメッセージまでユーザレジスト情報を翻訳します。
3. The SCGF relays the user registration message to the SCF/SDF.
3. SCGFはユーザ登録メッセージをSCF/SDFにリレーします。
3A. The SCF/SDF authorizes the subscriber with the directory number based on the user registration information.
3A。 SCF/SDFはユーザレジスト情報に基づくディレクトリ番号で加入者に権限を与えます。
3B. The SCF/SDF stores the IP address of the ICW Client and sets the status to "Internet on-line."
3B。 SCF/SDFはICW ClientのIPアドレスを保存して、「オンラインインターネット」に状態を設定します。
4. The SCF/SDF sends the result of registration to the SCF/SCGF.
4. SCF/SDFは登録の結果をSCF/SCGFに送ります。
4A. The SCGF translates the user registration response of the SCP internal API message to the PINT message.
4A。 SCGFはSCPの内部のAPIメッセージのPINTメッセージへのユーザ登録応答を翻訳します。
5. The SCGF relays the user registration response to the ICW Server.
5. SCGFはICW Serverへのユーザ登録応答をリレーします。
5A. The ICW Server records the user registration information and the Internet on-line status for the subscriber in the data base.
5A。 ICW Serverはデータベースの中の加入者のためにユーザレジスト情報とインターネットのオンライン状態を記録します。
6. The ICW Server sends the user registration response to the ICW Client.
6. ICW Serverはユーザ登録応答をICW Clientに送ります。
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サービスが活動的な状態にあるように加入者に通知します。
Lu, et al. Informational [Page 13] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[13ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
3.5.4. Incoming Call Notification
3.5.4. かかってきた電話通知
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 Clientに通知して、加入者の応答を待っています。
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling
ICW Client party
(DN1/IP1) (IP2) (IP3) (DN2)
| | | | | |
| | | | setup(DN1,DN2)|
1 | | | | |<+++++++++++|
| | | | 1A |
| | | IDP(T-busy,DN1)| |
2 | | | |<--.--.--.--| |
| | | 2A | |
| | | 2B | |
| | | 2C | |
| | noti(DN1,IP1,DN2)| | |
3 | | |<-.-.-.-.-.-| | |
| | 3A | | |
| INV(DN1,IP1,DN2)| | | |
4 | |<-----------| | | |
| 4A | | | |
| | 100 Trying | | | |
5 | |----------->| | | |
INV(DN1,IP1,DN2)| | | | |
6 |<-----------| | | | |
6A | | | | |
| 100 Trying | | | | |
7 |----------->| | | | |
| | | | | |
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling ICW Clientパーティー(DN1/IP1)(IP2)(IP3)(DN2)| | | | | | | | | | セットアップ(DN1、DN2)| 1 | | | | |<+++++++++++| | | | | 1A| | | | IDP、(T忙しい、DN1)| | 2 | | | | <--.--.--.--| | | | | 2A| | | | | 2B| | | | | 2C| | | | noti(DN1、IP1、DN2)| | | 3 | | | <、-.-.-.-.-.-| | | | | 3A| | | | INV(DN1、IP1、DN2)| | | | 4 | | <、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| 4A| | | | | | 100 トライ| | | | 5 | |、-、-、-、-、-、-、-、-、-、--、>|、|、|、| INV(DN1、IP1、DN2)| | | | | 6 | <、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| 6A| | | | | | 100 トライ| | | | | 7 |、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、|、|、|、|、|
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> Bearer
----->のパイントのプロトコルの-.-.>SCP内部のアピ--、-->INAPが+ + + + + >ISUPプロトコルについて議定書の中で述べる=====>運搬人
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加入者)は忙しいです。
Lu, et al. Informational [Page 14] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[14ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
2. The SSF/CCF sends InitialDP (T_Busy) to the SCF/SDF.
2. SSF/CCFはInitialDP(T_Busy)をSCF/SDFに送ります。
2A. The SCF/SDF determines whether the user at DN1 is PSTN on-line or Internet on-line. (The SCF/SDF executes the KT Telephone Mail Service logic in the PSTN on-line case and the ICW service Logic in the Internet on-line case.)
2A。 SCF/SDFはオンラインでDN1のユーザがオンラインでPSTNであるか、そして、インターネットを決定します。 (SCF/SDFはインターネットのオンライン場合でPSTNのオンラインケースとICWサービスLogicにおけるKT TelephoneメールService論理を実行します。)
2B. The SCF/SDF retrieves the IP address corresponding to DN1.
2B。 SCF/SDFはDN1に対応するIPアドレスを検索します。
2C. The SCF/SDF may play an announcement to the calling party, while waiting for the response of the called party.
2C。 SCF/SDFは被呼者の応答を待っている間、起呼側に発表をプレーするかもしれません。
3. The SCF sends an incoming call notification to the SCGF.
3. SCFはかかってきた電話通知をSCGFに送ります。
3A. The SCGF translates the incoming call notification from the SCP internal format to the PINT format.
3A。 SCGFはSCPの内部の形式からPINT形式までのかかってきた電話通知を翻訳します。
4. The SCGF relays the notification to the ICW Server.
4. SCGFはICW Serverに通知をリレーします。
4A. The ICW Server double-checks the subscriber's status using the ICW subscribers profile in its own data base.
4A。 ICW Serverは、それ自身のデータベースでICW加入者プロフィールを使用することで加入者の状態を再確認します。
5. The ICW Server sends trying message to the SCGF.
5. ICW Serverは骨の折れるメッセージをSCGFに送ります。
6. The ICW Server relays the notification to the ICW Client.
6. ICW ServerはICW Clientに通知をリレーします。
6A. The ICW Client consults the ICW service profile to see if there is a pre-defined call disposition for the incoming call. If so, then the procedure for automatic call processing is performed.
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。 かかってきた電話のための事前に定義された呼び出し気質が全くなければ、加入者はポップアップダイアログボックスを通して呼び出しについて通知されます。
7. The ICW Client sends trying message to the ICW Server.
7. ICW Clientは骨の折れるメッセージをICW Serverに送ります。
3.6.5. Incoming Call Processing
3.6.5. かかってきた電話処理
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."
かかってきた電話を受け入れるか、拒絶するか、もう1つの数に送るか、または加入者の飛行中の、または、あらかじめ定義された選択によるVMSに送ることができます。 このセクションは、「呼び出しを受け入れてください」に関するケースのために情報流れについて説明して、「もう1つの数に呼び出しを送ります」。
Lu, et al. Informational [Page 15] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[15ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
3.5.5.1. Accept the Call
3.5.5.1. 呼び出しを受け入れてください。
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling
ICW Client party
(DN1/IP1) (IP2) (IP3) (DN2)
| | | | | |
0A 200 OK | | | | |
1 |----------->| | | | |
1A | | | | |
1B | 200 OK | | | |
2 | |----------->| | | |
| | ACK 2A | | |
3 | |<-----------| | | |
| | |Accept(DN1,IP1,DN2) | |
4 | | |-.-.-.-.-.->| | |
| | | |Connect(DN1,DN2) |
5 | | | |--.--.--.-->| |
| | | Setup(DN1,DN2)| |
6 |<++++++++++++++++++++++++++++++++++++++++++++++++++| |
|<==============================6A==============================>|
| | | | ERB | |
7 | | | |<--.--.--.--| |
| | | ok | | |
8 | | |<-.-.-.-.-.-| | |
| | 8A | | |
| | BYE | | | |
9 | |<-----------| | | |
| 9A | | | |
| | | | | |
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling ICW Clientパーティー(DN1/IP1)(IP2)(IP3)(DN2)| | | | | | 0A200OK| | | | | 1 |、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 1A| | | | | 1B| 200 OK| | | | 2 | |、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| ACK 2A| | | 3 | | <、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、| |(DN1、IP1、DN2)を受け入れてください。| | 4 | | |-.-.-.-.-.->|、|、|、|、|、| |(DN1、DN2)を接続してください。| 5 | | | |--.--.--.-->|、|、|、|、| セットアップ(DN1、DN2)| | 6 |<++++++++++++++++++++++++++++++++++++++++++++++++++| | |<===============6A==============================>|、|、|、|、| エルプ| | 7 | | | | <--.--.--.--| | | | | OK| | | 8 | | | <、-.-.-.-.-.-| | | | | 8A| | | | | さようなら| | | | 9 | | <、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| 9A| | | | | | | | | |
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> Bearer
----->のパイントのプロトコルの-.-.>SCP内部のアピ--、-->INAPが+ + + + + >ISUPプロトコルについて議定書の中で述べる=====>運搬人
Figure 5: Incoming Call Processing - Accept the Call
図5: かかってきた電話処理--呼び出しを受け入れてください。
As depicted in Figure 5, the relevant information flows are as follows:
図5に表現されるように、関連情報流れは以下の通りです:
0A. The ICW subscriber chooses to "Accept" the incoming call.
0A。 ICW加入者は、かかってきた電話を「受け入れること」を選びます。
1. The ICW Client sends the "Accept" indication to the ICW Server.
1. ICW Clientは「受け入れてください」という指示をICW Serverに送ります。
1A. The ICW Client records the subscriber's selection for the incoming call in the call log.
1A。 ICW Clientは通話記録におけるかかってきた電話のための加入者の選択を記録します。
Lu, et al. Informational [Page 16] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[16ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
1B. The ICW Client terminates the subscriber's Internet connection.
1B。 ICW Clientは加入者のインターネット接続を終えます。
2. The ICW Server sends an "Accept" message to the SCGF.
2. ICW Serverは「受け入れてください」というメッセージをSCGFに送ります。
2A. The SCGF translates the "Accept" message to an SCP internal API message.
2A。 SCGFは「受け入れてください」というメッセージをSCPの内部のAPIメッセージに翻訳します。
3. The SCGF sends an "ACK" message to the ICW Server.
3. SCGFは"ACK"メッセージをICWサーバに送ります。
4. The SCGF sends the "Accept" message to the SCF.
4. SCGFは「受け入れてください」というメッセージをSCFに送ります。
5. The SCF instructs the SSF/CCF to route the call to DN1.
5. SCFは、呼び出しをDN1に発送するようSSF/CCFに命令します。
6. The SSF/CCF initiates the connection setup to DN1.
6. SSF/CCFは接続設定にDN1に着手します。
6A. The bearer connection between the calling party (DN2) and the ICW subscriber(DN1) is set up.
6A。 起呼側(DN2)とICW加入者(DN1)との運搬人接続はセットアップされます。
7. The connection result is returned to the SCF through ERB.
7. 接続結果はERBを通してSCFに返されます。
8. The SCF sends a call completion message to the SCGF.
8. SCFは呼び出し完了メッセージをSCGFに送ります。
8A. The SCGF translates the call completion message to a PINT message.
8A。 SCGFは呼び出し完了メッセージをPINTメッセージに翻訳します。
9. The SCGF sends a "BYE" message to the ICW Server.
9. SCGFは「さようなら」メッセージをICWサーバに送ります。
9A. The ICW Server records the call completion result in the log file.
9A。 ICW Serverは呼び出し完成結果をログファイルに記録します。
Lu, et al. Informational [Page 17] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[17ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
3.5.5.2. Forward the Call to Another Number
3.5.5.2. もう1つの数に呼び出しを送ってください。
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling Another
ICW Client party Phone
(DN1/IP1) (IP2) (IP3) (DN2) (DN3)
| | | | | | |
0A | | | | | |
|303 SeeOther | | | | |
1 |--------->| | | | | |
1A ACK | | | | | |
2 |<---------|303 SeeOther | | | |
3 | |--------->| | | | |
| | ACK 3A | | | |
4 | |<---------|Connect(DN2,DN3) | | |
5 | | |-.-.-.-.->| | | |
| | | |Connect(DN2,DN3) | |
6 | | | |.--.--.-->| | |
| | | | |Setup(DN2,DN3) |
7 | | | | ++++++++++++++++++++>|
8 | | | | ERB | |<===5A==>|
| | | |<--.--.--.| | |
| | | ok | | | |
9 | | |<-.-.-.-.-| | | |
| | BYE 9A | | | |
10 | |<---------| | | | |
| BYE 10A | | | | |
11 |<---------| | | | | |
11A | | | | | |
| | | | | | |
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling Another ICW Clientパーティー電話(DN1/IP1)(IP2)(IP3)(DN2)(DN3)| | | | | | | 0A| | | | | | |303 SeeOther| | | | | 1 |、-、-、-、-、-、-、-、--、>|、|、|、|、|、| 1A ACK| | | | | | 2 | <、-、-、-、-、-、-、-、--、|303 SeeOther| | | | 3 | |、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、| ACK 3A| | | | 4 | | <、-、-、-、-、-、-、-、--、|(DN2、DN3)を接続してください。| | | 5 | | |-.-.-.-.->|、|、|、|、|、|、| |(DN2、DN3)を接続してください。| | 6 | | | |.--.--.-->|、|、|、|、|、|、| |セットアップ(DN2、DN3)| 7 | | | | ++++++++++++++++++++>| 8 | | | | エルプ| |<==5A=>|、|、|、| | <--.--.--.| | | | | | OK| | | | 9 | | | <、-.-.-.-.-| | | | | | さようなら9A| | | | 10 | | <、-、-、-、-、-、-、-、--、|、|、|、|、|、| さようなら10A| | | | | 11 | <、-、-、-、-、-、-、-、--、|、|、|、|、|、| 11A| | | | | | | | | | | | |
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> Bearer
----->のパイントのプロトコルの-.-.>SCP内部のアピ--、-->INAPが+ + + + + >ISUPプロトコルについて議定書の中で述べる=====>運搬人
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つの数に送ること」を選びます。
1. The ICW Client sends the "Forward to another number" indication to the ICW Server.
1. ICW Clientは「もう1つの数へのフォワード」指示をICW Serverに送ります。
1A. The ICW Client records the subscriber's selection for the incoming call in the call log.
1A。 ICW Clientは通話記録におけるかかってきた電話のための加入者の選択を記録します。
Lu, et al. Informational [Page 18] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[18ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
2. The ICW Server sends an "ACK" message to the ICW Client.
2. ICW Serverは"ACK"メッセージをICWクライアントに送ります。
3. The ICW Server relays the "Forward to another number" message to the SCGF.
3. ICW Serverは「もう1つの数へのフォワード」メッセージをSCGFにリレーします。
3A. The SCGF translates the "Forward to another number" message to an SCP internal API message.
3A。 SCGFは「もう1つの数へのフォワード」メッセージをSCPの内部のAPIメッセージに翻訳します。
4. The SCGF sends an "ACK" message to the ICW Server.
4. SCGFは"ACK"メッセージをICWサーバに送ります。
5. The SCGF sends the "Forward to another number" message to the SCF.
5. SCGFは「もう1つの数へのフォワード」メッセージをSCFに送ります。
6. The SCF instructs the SSF/CCF to route the call to DN3.
6. SCFは、呼び出しをDN3に発送するようSSF/CCFに命令します。
7. The SSF/CCF initiates the connection setup to DN3.
7. SSF/CCFは接続設定にDN3に着手します。
7A. The bearer connection between the calling party (DN2) and the new termination number (DN3) is set up.
7A。 起呼側(DN2)と新しい終了番号(DN3)との運搬人関係はセットアップされます。
8. The connection result is returned to the SCF through ERB.
8. 接続結果はERBを通してSCFに返されます。
9. The SCF sends a call completion message to the SCGF.
9. SCFは呼び出し完了メッセージをSCGFに送ります。
9A. The SCGF translates the call completion message to a PINT message.
9A。 SCGFは呼び出し完了メッセージをPINTメッセージに翻訳します。
10. The SCGF sends the call completion message to the ICW Server.
10. SCGFは呼び出し完了メッセージをICW Serverに送ります。
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は「もう1つの数への推進」の成功をICW Clientに送ります。
11A. The ICW Client records the call completion result in the log file.
11A。 ICW Clientは呼び出し完成結果をログファイルに記録します。
Lu, et al. Informational [Page 19] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[19ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
3.6.6. ICW service De-activation
3.6.6. ICWサービスDe-起動
The SCP de-activates the ICW service for a subscriber either upon the termination of the subscriber's Internet connection or upon the subscriber's manual request. In this section, we illustrate the former scenario.
SCPは加入者のインターネット接続の終了か加入者の手動要求のときに加入者のために反-ICWサービスを起動します。 このセクションでは、私たちは前のシナリオを例証します。
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling
ICW Client party
(DN1/IP1) (IP2) (IP3) (DN2)
| | | | | |
0A | | | | |
| 0B | | | |
| |Unreg(DN1,IP1) | | |
1 | |----------->| | | |
| | 1A | | |
| | |Unreg(DN1,IP1) | |
2 | | |-.-.-.-.-.->| | |
| | | 2A | |
| | | ok 2B | |
3 | | |<-.-.-.-.-.-| | |
| | 3A | | |
| | 200 OK | | | |
4 | |<-----------| | | |
| 4A | | | |
| | | | | |
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling ICW Clientパーティー(DN1/IP1)(IP2)(IP3)(DN2)| | | | | | 0A| | | | | | 0B| | | | | |Unreg(DN1、IP1)| | | 1 | |、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| 1A| | | | | |Unreg(DN1、IP1)| | 2 | | |-.-.-.-.-.->|、|、|、|、|、| 2A| | | | | 間違いない2B| | 3 | | | <、-.-.-.-.-.-| | | | | 3A| | | | | 200 OK| | | | 4 | | <、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| 4A| | | | | | | | | |
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> Bearer
----->のパイントのプロトコルの-.-.>SCP内部のアピ--、-->INAPが+ + + + + >ISUPプロトコルについて議定書の中で述べる=====>運搬人
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 Clientから周期的なオンライン通知を受け取らないとき、インターネット接続が終えられたことを決定します。
1. The ICW Server sends an un-register message to the SCGF.
1. ICW Serverは不-レジスタメッセージをSCGFに送ります。
1A. The SCGF translates the un-register message to an SCP internal API message.
1A。 SCGFはSCPの内部のAPIメッセージに不-レジスタメッセージを翻訳します。
Lu, et al. Informational [Page 20] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[20ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
2. The SCGF sends the un-register message to the SCF.
2. SCGFは不-レジスタメッセージをSCFに送ります。
2A. The SCF/SDF authorizes the subscriber with the directory number based on the un-registration information.
2A。 SCF/SDFは不-レジスト情報に基づくディレクトリ番号で加入者に権限を与えます。
2B. The SCF/SDF records the Internet off-line status for that ICW Client.
2B。 SCF/SDFはそのICW Clientのためにインターネットのオフライン状態を記録します。
3. The SCF/SDF sends a user un-registration response to the SCF/SCGF.
3. SCF/SDFはユーザ不-登録応答をSCF/SCGFに送ります。
3B. The SCGF translates the user un-registration response to a PINT message.
3B。 SCGFはPINTメッセージへのユーザ不-登録応答を翻訳します。
4. The SCGF relays the user un-registration response to the ICW Server.
4. SCGFはICW Serverへのユーザ不-登録応答をリレーします。
4A. The ICW Server records the Internet off-line status for the ICW Client (subscriber) in the data base.
4A。 ICW Serverはデータベースの中のICW Client(加入者)のためにインターネットのオフライン状態を記録します。
4. The Lucent Technologies Online Communications Center
4. ルーセントテクノロジーズのオンラインコミュニケーションセンター
4.1 Overview
4.1 概要
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.
ルーセントテクノロジーズOnline Communicationsセンター(OCC)はインターネットキャッチホンサービスをサポートするIntelligent Networkの(IN)ベースのプラットホームです。 基本的なコンポーネントは、OCC ServerとOCC Clientです。(そのOCC ClientはArchitecture部で詳細に説明されます)。 OCC Serverは安全なイントラネットの上でプレーンテキストSession Initiationプロトコル(SIP)メッセージ[2]でPSTN実体と対話します。 PC Clientと共に、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ランタイム環境はCall Registrationに原因となる2つのマルチスレッド化されたプロセスとCall Notificationサービスからそれぞれ成ります。
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
すべてのOCC呼び出し通知サービスがPSTNによって開始されています。 これらのサービスの1つの共通点がインターネットを通して入って来る通話についてユーザに知らせるものです、モデムによって既に使用された系列にどんな影響も与えないで。 (典型的なキャッチホントーンはインターネット接続を遮って、それは「古い」PSTNキャッチホンサービスを無効にする標準的技法です。
Lu, et al. Informational [Page 21] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[21ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
duration of the call in support of the Internet connection between the end-user and the ISP.)
エンドユーザとISPとのインターネット接続を支持した呼び出しの持続時間。)
When a call comes in, the user is presented with a pop-up dialog box, which displays the caller's number (if available), name (again, if available), as well as the time of the call. If the called party does not initiate an action within a specified period of time the call is rejected.
呼び出しが入るとき、訪問者の番号を表示するポップアップダイアログボックスをユーザに与えます(利用可能であるなら)、名前(再び利用可能であるなら)、呼び出しの時間と同様に。 被呼者が指定された期間以内に動作を開始しないなら、呼び出しは拒絶されます。
As far as the disposition of the call is concerned, OCC supports all the features described in Section 2.
呼び出しの気質に関する限り、OCCはセクション2で説明されたすべての特徴をサポートします。
4.2. Architecture
4.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 |
| |
+-------------------+
+------------+ | コンパクト| +-------------+ | サービス| | サービス| +-----| ノード(CSN)| | 管理| | | OCCサーバ| | システム(SMS)| | | OCC CSN鉱泉| +-------------+ | +-------:--|-+ | | | +-------------[IPイントラネット]---------+ ===== ファイアウォール: | | | | | +-------+ +-------+ | |中央|-..-..-..-..-..-..-..-..-..-..-|サービス| | +-%-|オフィス|-..-..-: |コントロール| | | +---|---+ | |ポイント| | % | : | (SCP) | | | +--|---+ +-------+ +----------+ |OCC SCP| | % | PC| | VoIP| | VoIP| | 鉱泉| | | |OCC Cl| |ゲートウェイ| |門番| +-------+ | % +------+ +---|---+ +-----|----+ | | ===== ファイアウォール===== | % | | | | +---------------|---+ | | +-%-| |----------+ +----------| N I T EのR N E T| | | +-------------------+
Figure 8: The Lucent OCC Physical Architecture
エイト環: 透明な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
エイト環はOCC操作に関連している共同PSTN/インターネット物理的なアーキテクチャについて表現します。 Compact Service Node(CSN)とSCPはLucentのBellcoreのAdvancedの要件によって増大させられるITU-T IN Recommendations(特にこれらの実体が定義されるRecommendation Q.1205)の実装です。
Lu, et al. Informational [Page 22] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[22ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
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.
知的なNetwork(AIN)リリース1.0) そして、他の特徴を備えています。 セントラルオフィス(CO)はIntegrated Services Digital Network(ISDN)をサポートするどんなスイッチであるかもしれません。 それがCSNと共にそれで織り込むことができるプライマリRate Interface(PRI)と自動転送機能。 代わりに、織り込む、SCPと共に、それは、IN Service Switching Point(SSP)である必要があります。 後者の場合では、電話局は応用層でシグナリングシステムのNo.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.
Service Management System(SMS)はSCPs、CSNs、および電話局の食糧を供給するのに責任があります。 インターネットCall WaitingのINサポートのための事項では、それは、Termination Attempt Trigger(TAT)に基づくOCC SCP SPAに対応するサブシステム番号への試み質問を終えながらaを指示するためにセントラルオフィスに食糧を供給しなければなりません。 さらに、SubscriberディレクトリNumber(DN)、パーソナルIdentification Number(暗証番号)、およびLanguage IDは各加入者のためにSCPレアルTime Data基地(RTDB)のOCC Subscriberエントリーに食糧を供給されます。 図9はRTDBエントリーの構造を示しています。
+-------------------------------------------------------+
|DN | PIN | IP Address | Session Key | CNF | Language ID|
+-------------------------------------------------------+
+-------------------------------------------------------+ |DN| 暗証番号| IPアドレス| セッションキー| CNF| 言語ID| +-------------------------------------------------------+
Field Descriptions:
記述をさばいてください:
(DN) Directory Number - the subscriber's telephone number
(DN)ディレクトリNumber--加入者の電話番号
(PIN) Personal Identification Number - the subscriber's password
(暗証番号)個人的なIdentification Number--加入者のパスワード
IP Address - Internet Protocol Address of the subscriber
IP Address--加入者の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)呼び出しNotification In Progress Flag(論理演算子)--呼び出しについて加入者に通知する試みが現在進行しているかどうかを示す旗
Session Key - unique identifier for the current registration session
of the subscriber
セッションKey--加入者の現金書留セッションのためのユニークな識別子
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 Recommendation H.323で定義されたVoIPゲートウェイとGatekeeperです。 を通してセントラルオフィスが明らかにVoIPゲートウェイに接続される。
Lu, et al. Informational [Page 23] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[23ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
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 Gatekeeperはインターネットに関連づけられた唯一の実体です、それぞれのそれぞれの接続がファイアウォールによって保護されている状態で。 CSNとSCPは安全なIPイントラネットでインタコネクトされます。 ネットワークには1CSNかSCP(ともに)があるかもしれませんが(SCPsはX.25によってとにかくインタコネクトされたメーテッド・ペアに入ります)、これらの詳細はこのドキュメントに選ばれた記述のレベルに不可欠ではありません。 しかしながら、私たちは、ロードバランシングと代替のノードの使用による失敗への適合がアーキテクチャに組み入れられることに注意します。
When someone attempts to call the subscriber, the central office serving that subscriber interrupts normal termination processing and notifies the SCP which, in turn, can check whether that subscriber has registered that he (or she) is logged onto the Internet. Exploiting the standardized layering of service logic that characterizes the intelligent network, the central office will do this without requiring the installation or development of any central office software specific to OCC. The central office is simply provisioned to query the SCP when there is a termination attempt (i.e., TAT) directed to the subscriber's directory number. (Note that the Central Office has no bearer circuit connection to the SCP, only a signaling one over SS7).
だれかが、加入者に電話をするのを試みるとき、その加入者に飲食物を出す電話局は、正常終了処理を中断して、彼(または、彼女)がインターネットに登録されるようにその加入者が登録したかどうか順番にチェックできるSCPに通知します。 OCCに特定のどんな電話局ソフトウェアのインストールか開発も必要としないで、インテリジェントネットワークを特徴付けるサービス論理の標準化されたレイヤリングを利用して、電話局はこれをするでしょう。 電話局は、加入者のディレクトリ番号に向けられた終了試み(すなわち、TAT)があるとき、SCPについて質問するために単に食糧を供給されます。 (セントラルオフィスにはSCPとの運搬人回路接続ではなく、SS7の上のシグナリング1しかないことに注意します。)
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からの入って来るCall Notification(TCP/IP)メッセージの聞こうとします。
o De-multiplexing/multiplexing incoming Call Notification messages
sent from the SCP SPA.
o 入って来るCall Notificationメッセージを反-多重送信するか、または多重送信するのがSCP SPAから発信しました。
o Relaying messages between the OCC Client and the SCP SPA.
o OCC ClientとSCP SPAの間のメッセージをリレーします。
o Listening for and authentication of OCC Client requests for
service registration.
o OCC Clientの聴取と認証はサービスのために登録を要求します。
Lu, et al. Informational [Page 24] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[24ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
o Handling encryption/decryption of messages exchanged with the OCC
Client, and generating session-specific encryption/decryption
keys.
o OCC Clientと共に交換されたメッセージの暗号化/復号化を扱って、セッション特有の暗号化/復号化キーを生成します。
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はSubscriberのPCで動くソフトウェアコンポーネントの収集です。 コンポーネントはSIP UserエージェントServer(OCC ServerとのSIPメッセージの交換を扱って、Call Notificationポップアップウィンドウを呼び出す)とPointからポイントへのプロトコル(PPP)動作をモニターしている、始まって、SIP UserエージェントServerを止めるのに原因となるデーモンプロセスを含んでいます。
4.3. Protocol and Operations Considerations
4.3. プロトコルと操作問題
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 Clientから送られた入って来るSIP REGISTERメッセージ(登録サービスを支持した)の聞こうとしてください。
o Listen for incoming SIP INVITE messages (in support of call
notification service) sent from the SCP.
o SCPから送られた入って来るSIP INVITEメッセージ(呼び出し通知サービスを支持した)の聞こうとしてください。
During call notification, the SCP SPA is the client and thus is started after the OCC Server has been started. The SCP SPA and OCC Server exchange SIP messages over TCP/IP (via the Secure Intranet) using a "nailed-up" connection which is initiated by the SCP SPA. This connection is initiated at the time the SCP SPA receives the very first SIP REGISTER request from the OCC Server, and must prevail for as long as the SPA is in the in-service state. The SCP SPA also supports restarting the connection after any failure condition.
呼び出し通知の間、OCC Serverが始動された後に、SCP SPAはクライアントであり、その結果、始動されます。 SCP SPAとOCC Serverは、SCP SPAによって開始される「打ち付けられて上がっている」接続を使用することでTCP/IP(Secureイントラネットを通した)の上と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はマルチスレッド化をサポートします。 それぞれのCall Notification/呼び出しDispositionイベントにおいて、別々のスレッドは、呼び出しを扱うのに使用されます。 このモデルはSCP SPAから受け取られたあらゆる開始メッセージ(SIP INVITE)が呼び出しを扱うのにコントロールの別々のスレッドを使用するところで「メッセージ」ベースでのマルチスレッド化をサポートします。 オリジナルの開始メッセージがそんなに以前に同じスレッドに発送されるような同じセッションCall-ID(「呼び出し_インデックス」とSCPホスト名として知られているSPAのインスタンスを含んでいる)を含むその後のメッセージがそれぞれの開始メッセージを扱いました。
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はそれぞれのCall Notification/呼び出しDispositionセッションのためにOCC Clientと共に新しいTCP/IPソケットをダイナミックに開けます。 このソケット接続は、OCC Clientソフトウェアを動かしながら、PCの上でIPアドレスとあらかじめ設定されたポートを使用します。
For session registration, the OCC Server dynamically opens TCP/IP sessions with the SCP SPA. The SCP SPA listens at a pre-configured port to incoming SIP REGISTER messages sent by OCC Clients via the
セッション登録のために、OCC ServerはダイナミックにSCP SPAとのTCP/IPセッションを開きます。 を通してSCP SPAがあらかじめ設定されたポートでOCC Clientsによって送られた入って来るSIP REGISTERメッセージを聴く。
Lu, et al. Informational [Page 25] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[25ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
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 Server SIPメッセージをOCC Serverと交換するために、OCC ClientはダイナミックにCSNであらかじめ設定されたポートナンバーを使用するOCC ServerとのTCP/IPソケット接続とCSNの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 Scenarioに関しては、クライアントとして機能して、CSN SPAはダイナミックに初期のTAT質問を扱ったSCPとのTCP/IPセッションを開きます。 CSN SPAが首尾よく相関関係を作って、VoIP呼び出しに関係する2本のかかってきた電話脚を接続し返すとすぐに、CallerをCSNに送るようSSPに命令した実際のSCPの上で作業するSCP SPAはSIP180RINGINGメッセージに送り返されるでしょう。 このSIPメッセージ(ブリッジしている呼び出し脚の1つによってダイヤルされるVoIP Call Back DNを含む)はSCP SPAへのVoIP Call Back DNが開けられるという指示です。
A typical subscription scenario works like as follows:
典型的な購読シナリオは以下の通りであることのように働いています:
1. Each VoIP Gateway is provisioned with a list of authorized VoIP
Call Back DNs, each terminating on a particular CSN. These
special DNs are used when an on-line subscriber elects to receive
an incoming call via VoIP. In particular, they assist in routing
an outgoing call from the subscriber's NetMeeting to the
particular CSN to which the SCP is (roughly concurrently)
forwarding the incoming call. (These two calls are joined in the
CSN to connect the incoming call to the subscriber's Netmeeting
client.) Furthermore, these special DNs permits that CSN to
associate, and hence bridge, the correct pair of call legs to join
the party calling the subscriber to the call from the subscriber's
NetMeeting client.
1. 特定のCSNでそれぞれ終わって、それぞれのVoIPゲートウェイは認可されたVoIP Call Back DNsのリストで食糧を供給されます。 オンライン加入者が、VoIPを通してかかってきた電話を受けるのを選ぶとき、これらの特別なDNsは使用されています。 特に、彼らがSCPがそうである加入者のNetMeetingから特定のCSNまでの発信電話をルーティングに助ける、(およそ、同時に)、かかってきた電話を進めます。 (これらの2つの呼び出しが加入者のNetmeetingクライアントにかかってきた電話に接するためにCSNに参加されます。) その上、これらの特別なDNsは、加入者のNetMeetingクライアントから加入者を呼び出しに電話をするパーティーに加わるためにそのCSNが呼び出し脚の正しい組を関連づけて、したがって、ブリッジするのを可能にします。
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. アクティブなTerminating Attempt Trigger(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サービスプロバイダーは、OCC RTDBのSubscriber DNと暗証番号がSCPで見送る加入者と支給のための記録を作成するのにSMSを使用します。
5. The subscriber is provided with the OCC Client software, a PIN and
a file containing the OCC Server IP Addresses.
5. OCC Server IP Addressesを入れてあるOCC Clientソフトウェア、暗証番号、およびファイルを加入者に提供します。
Finally, we describe the particular scenario of the OCC Call Disposition that involves voice over IP, which proceeds as follows:
最終的に、私たちは以下の通り続くIPの上で声にかかわるOCC Call Dispositionの特定のシナリオについて説明します:
1. The OCC subscriber clicks on "Accept VoIP".
1. OCC加入者は「VoIPを受け入れてください」をクリックします。
Lu, et al. Informational [Page 26] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[26ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
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は「一口の380の代替のサービス」メッセージをOCC Serverに送ります。このメッセージは結局PSTN呼び出し脚が起呼側に接している状態で加入者(VoIPゲートウェイを通した)に接しながら呼び出し脚(すぐ加入者のNetMeetingによって開始される)を関連づけるのにCSNによって使用されるCall Back 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 Clientと共にTCP/IPセッションを終えて、Call Back DNを含んでいる「一口の380の代替のサービス」メッセージをSCP SPAに送ります。
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への加入者に送るようセントラルオフィスに命令します。 この指示はCall Back 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はCall Back DNに参照をつけるCSNにCallerを送ります。 クライアントが、VoIPを通して呼び出しを受けるのを選んだとき、加入者が元々かかってきた電話試みの存在に注意を喚起されたとき、SCPによってOCCクライアントに割り当てられたCall Back DNがOCCサーバの横で流れたことにそして、SCPと、そして、CSNでその進められた呼び出しと関連してCSNと、そして、そして、OCCサーバにかかってきた電話を送る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 Client抽出1) Call Notificationと2の間に受け取られたSIP INVITEメッセージ) H323UIDとH323PINからのVoIP Call Back DNはその特性のファイルとアップデートから'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ゲートウェイの間でいったん確立されると、目的地DNとしてVoIPゲートウェイにCall Back DNを渡して、NetMeetingは電話を開始します。
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. H323UIDとH323PIN値について確かめて、呼ばれたDN(すなわち、Call Back DN)が使用のために認可されるのを確実にすることによって、VoIPゲートウェイは、VoIP Gatekeeperに相談して、NetMeeting呼び出しを認証します。
10. After passing the authentication step, the VoIP Gateway dials
(via PSTN) the Call Back DN and gets connected to the CSN. The
CSN notes that it was reached by the particular Call Back DN.
10. 認証ステップを通り過ぎた後に、VoIPゲートウェイは、Call Back DNにダイヤルして(PSTNを通して)、CSNに接続されます。 CSNは、それが特定のCall Back DNによって達せられたことに注意します。
11. The CSN bridges the Calling and Called parties together by
matching on the basis of the Call Back DN.
11. CSNは、CallingとCalledが一緒にパーティーであるとCall Back DNに基づいて合っていることによって、ブリッジします。
Lu, et al. Informational [Page 27] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[27ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
12. The CSN notifies the SCP (SIP 180 Ringing) of status and
references the Call Back DN so that the SCP can reuse it for
other calls.
12. CSNは、状態についてSCP(SIP180Ringing)に通知して、SCPが他の呼び出しのためにそれを再利用できるように、Call Back 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. 電話局が、その2Bチャネルが転送であるとサポートするなら(透明です、ノーテル、および恐らくベンダーの他の電話局ものはそうします)、最適化は可能です。 CSNは電話局に新たに接続された呼び出しのトポロジーを電話局を通ってだけもういずれのCSNを通しても流れないような方法で再配列させることができます。
5. NEC's Implementation
5. NECの実装
5.1. Overview
5.1. 概要
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.
他の特徴はそれぞれの新しい呼び出し到着がそれ自身のポップアップダイアログボックスと可聴表示を生成するMultiple呼び出し到着管理を含んでいます。
Lu, et al. Informational [Page 28] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[28ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
5.2. Architecture and Overall Call Flow
5.2. アーキテクチャと総合的な呼び出し流動
Figure 10 depicts the NEC ICW system.
図10はNEC ICWシステムについて表現します。
====================================
|| I n t e r n e t ||
|| ||
====================================
/ | \
: (p1) : : (p2)
/ | \
+-------+ +------------+ +-----+
|SPIRITS| | ISP | | W3S |
|Server | | ISP | | W3S |
+-------+ +------------+ +-----+
: :
Internet | :
PSTN/IN |(p0) :
: :
| ============:======
+------+ (p3) || +-----+ : ||
| SCP |-..-..-..-| SSP | : ||
+------+ || +-----+ : ||
|| (p4)| : ||
+-------+ || : : ||
| ICW | (p1)+-----+ || | : ||
|Client |.....| M/D |............+------+ ||
+-------+ (p2)+-----+ || | CO | ||
--------------------| |-------
/ || +------+ || \
/--\ / || P S T N || \ /--\
()/\() / =================== \ ()/\()
_/__\___/ \______/__\_
==================================== || I n t e r n e t|| || || ==================================== / | \ : (p1) : : (p2) / | \ +-------+ +------------+ +-----+ |スピリッツ| | ISP| | W3S| |サーバ| | ISP| | W3S| +-------+ +------------+ +-----+ : : インターネット| : PSTN/IN|(p0) : : : | ============:====== +------+ (p3)|| +-----+ : || | SCP|-..-..-..-| SSP| : || +------+ || +-----+ : || || (p4)| : || +-------+ || : : || | ICW| (p1)+-----+ || | : || |クライアント|.....| M/D|............+------+ || +-------+ (p2)+-----+ || | CO| || --------------------| |------- / || +------+ || \ /--\ / || P S T N|| \ /--\ ()/\() / =================== \ ()/\() _/__\___/ \______/__\_
ICW Subscriber Calling Party
ICW加入者起呼側
Legend:
ISP : Internet Service Provider
W3S : WWW Server
SCP : Service Control Point(acts as SPIRITS Client)
SSP : Service Switching Point
CO : Central Office
M/D : Modem
伝説: ISP: インターネットサービスプロバイダW3S: WWWサーバSCP: 制御点(スピリッツクライアントとして、機能する)SSPを調整してください: 切り換えPoint COを修理してください: 電話局M/D: モデム
Traffic:
--- : PSTN Voice Traffic
... : PPP(IP traffic)
-..-: Signaling Traffic
トラフィック: --- : PSTNはトラフィックを声に出します… : PPP(IPトラフィック)、--: シグナリングトラフィック
Lu, et al. Informational [Page 29] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[29ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
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 Server-SCP(SPIRITS Client)はp1を連結します: SPIRITS Server-ICW Clientはp2を連結します: ICW Client-W3Sインタフェース(HTTPを通したウェブアクセス)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.
1. 顧客が特別な起動コード(例えば、*54)接頭語をISPディレクトリNumberの正面に挿入することによってそれらのISPに接続すると、CO線はICWサービスのために用意されます。
2. The ICW service is activated when the user opens a secured
session from an ICW client to the SPIRITS server. Once a session
is open, the SPIRITS server will know the relationship between the
line and the PC (i.e., it will know the Directory Number of the
user's Internet line and the user's IP Address).
2. ユーザが機密保護しているICWクライアントからSPIRITSサーバまでのセッションを開くとき、ICWサービスは活性です。セッションがいったん開くようになると、SPIRITSサーバは系列とPCとの関係を知るでしょう(すなわち、それはユーザのインターネット回線とユーザのIP AddressについてディレクトリNumberを知るでしょう)。
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サーバに知らせるでしょう。 メッセージはCalling線の発信番号表示、起呼側のIdentify Restriction(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. ICWセッションが話中回線に確立されたなら、SPIRITSサーバはそれについて確かめるでしょう。 そうだとすれば、SPIRITSサーバはユーザのICWクライアントアプリケーションとコミュニケートするでしょう。 利用可能であるなら、ユーザはCallingパーティのCalling NameとNumberを含むリアルタイムのポップアップダイアログボックスを受けるでしょう。 次に、ユーザは以下の呼び出し管理オプションの1つを選択するでしょう:
- 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
- 電話口に出てください(インターネット接続は自動的に下げられるでしょう、そして、電話は鳴るでしょう)--Voiceメールに呼び出しを送ってください--別の目的地に呼び出しを送ってください--呼び出しを無視してください。
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に呼び出しを扱う方法を命令するでしょう。
Lu, et al. Informational [Page 30] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[30ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
5.3. Interfaces and Protocols
5.3. インタフェースとプロトコル
5.3.1. SCP (SPIRITS Client)-SPIRITS Server Interface
5.3.1. SCP(スピリッツクライアント)スピリッツサーバインタフェース
5.3.1.1. Connecting to SPIRITS Services
5.3.1.1. スピリッツサービスに接続すること。
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でいるでしょう。 論理的な接続はRFC768とRFC1122で定義されるようにUDP/IPコミュニケーションを使用するでしょう。
If a socket connection is not currently established, the SCP will periodically try to open a connection. The SCP routing tables will be configured so that all available connections to a SPIRITS server are used.
ソケット接続が現在確立されないと、SCPは定期的に接続を開こうとするでしょう。 SCP経路指定テーブルが構成されるので、SPIRITSサーバとのすべての手があいている接続が使用されています。
5.3.1.2. Message Types
5.3.1.2. メッセージタイプ
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には、近い将来スピールITSクライアント/サーバインタフェースにSIP/SDPベースのプロトコルをサポートする計画があります。
5.3.1.2.1 Connection Management Message Type
5.3.1.2.1 接続管理メッセージタイプ
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
- 最もactivitytestにscfBindします(scfUnbind)。
Opening a Connection
接続を開きます。
If a connection is not open to an SPIRITS server, the SCP will periodically try to open a connection until it is opened. If after a pre-determined number of attempts the connection is not opened, the socket connection will be released and then re-established and then the attempt to open the connection will be repeated.
接続がSPIRITSサーバにオープンでないなら、それが開かれるまで、SCPは接続を定期的に開こうとするでしょう。 接続が予定された数の試みの後に開かれないと、ソケット接続は、リリースされて、復職するでしょう、そして、次に、接続を開く試みは繰り返されるでしょう。
Lu, et al. Informational [Page 31] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[31ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
The sequence for opening a connection is:
接続を開くための系列は以下の通りです。
1. SCP will transmit a scfBind invokation message to the SPIRITS server. This message also carries the version information and activity test interval.
1. SCPはscfBind invokationメッセージをSPIRITSサーバに送るでしょう。また、このメッセージはバージョン情報と活動テスト間隔を運びます。
2. The SPIRITS server, upon receiving an invokation of the scfBind from a particular SCP, will reset all the data concerning the connection and then responds with either a return result containing the Web Server Identification number or a return error with a reason.
2. SPIRITSサーバは、特定のSCPからscfBindのinvokationを受けるとき接続に関してすべてのデータをリセットして、次に、ウェブServer Identification番号を含むリターン結果か理由があるリターン誤りのどちらかで反応します。
3. When the SCP receives a return result, if the ID number does not match the number configured in the SCP, then a scfUnbind will be sent indicating the wrong ID number. If the SCP receives nothing or a return error is received, then the scfBind will be retried after a pre-determined period of time.
3. SCPがリターン結果を受けるとき、ID番号がSCPで構成された数に合っていないと、scfUnbindに間違ったID番号を示させるでしょう。 SCPが何も受けないか、またはリターン誤りが受け取られていると、scfBindは予定された期間の後に再試行されるでしょう。
4. Once the SCP has received a return result, the SCP will send Handling Information Request or Activity Test.
4. SCPがいったんリターン結果を受けると、SCPはHandling情報のRequestかActivity Testを送るでしょう。
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サーバがActivity Test Interval値の4倍のためにSCPからミリセカンドでHandling情報のRequestかActivity Testに関するどんな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.
接続を終えるために、SCPかSPIRITSサーバはscfUnbindのinvokationをリモートエンドに送ります。 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は、協会を証明するためにscfBindのinvokationをSPIRITSサーバに送るでしょう。 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サーバが要求を扱う準備ができないことができませんし、バージョンを扱うことができないなら、それはリターン誤りで応じるべきです。
Lu, et al. Informational [Page 32] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[32ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
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が「活動テスト間隔」で指定された期間のためのData Messageを送らないと、それは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サーバによって保有されるべきです。彼らは、メッセージ回答時間について計算できるようにリターン結果でecho backであることになっています。
5.3.1.2.2. Data Message Type
5.3.1.2.2. データメッセージタイプ
SCPs use the following operations, which are sent to the SPIRITS server via a Data-Message-Type message, to request execution of some service procedure or notification of an event that takes place at the SCPs:
SCPsは以下の操作を使用します:(操作は、何らかのサービス手順の実行かSCPsで行われるイベントの通知を要求するためにDataメッセージタイプメッセージでSPIRITSサーバに送られます)。
o handlingInformationRequest
o handlingInformationRequest
The handlingInformationRequest message will request a SPIRITS
server the execution of some service procedure.
handlingInformationRequestメッセージは要求a SPIRITSサーバに何らかのサービス手順の実行を望んでいます。
o handlingInformationResult
o handlingInformationResult
The handlingInformationResult message will show the SCP the result
of the execution, which was carried out by the SPIRITS server.
handlingInformationResultメッセージは実行の結果をSCPに示すでしょう。(実行がSPIRITSサーバによって行われました)。
o confirmedNotificationProvided
o 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に送るでしょう。
Lu, et al. Informational [Page 33] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[33ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
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.
予定されたタイムアウトの期間以内にData Messageについて答えないと、指定された何回もメッセージに再送するでしょう。 別のノードが存在するならいったん回数を超えていると、それが利用可能であるなら、別のノードにメッセージを送るでしょう。 すべての利用可能なSPIRITSサーバについて質問したなら、Message Timeアウトを呼び出しプロセスに返すでしょう。
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.
原因=63(利用可能でないサービス)でhandlingInformationResultのinvokationを受け取ると、それが利用可能であるなら、別のノードにhandlingInformationRequestを送るでしょう。 利用可能なSPIRITSが断ち切るすべてについて質問したなら、原因=63を呼び出しプロセスに返すでしょう。
5.3.2. SPIRITS Server-ICW Client Application Interface
5.3.2. スピリッツサーバ-ICWクライアントアプリケーションインタフェース
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サーバに示すなら、より新しいバージョンをダウンロードすることにおける使用へのVersionInfoAckメッセージの中でURL情報を返します。 クライアントソフトウェアが最新であるなら、メッセージは、少しの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.
この呼び出しのための識別子。 このクライアント/サーバセッションのドメインでは、ユニークです。
Lu, et al. Informational [Page 34] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[34ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
o CallingNumber
o CallingNumber
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サーバからClient Applicationに送ります。利用可能であるときに、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.
CallArrivalを送った後に対応するCallConnectが、ある期間以内に受け取られないと、まるでCallConnectが受け取られていたかのようにHandling=が、無視するSPIRITSサーバは振る舞うでしょう。
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クライアントアプリケーションとスピリッツサーバの間の使用のための安全な信頼できるハイブリッドデータグラムセッションプロトコル(SRHDSP)
5.3.3.1. Overview
5.3.3.1. 概要
In principle the solution involves session initiation over SSL (meeting requirements for standards based security) after which the SSL session is closed, thereby reducing the number of simultaneous TCP/IP sessions. The rest of the session is communicated over UDP/IP, secured using keys and other parameters exchanged securely during the SSL session.
原則として、ソリューションはSSLセッションが閉じられるSSL(規格のためのミーティング要件はセキュリティを基礎づけた)の上のセッション開始にかかわります、その結果、同時のTCP/IPセッションの数を減少させます。 セッションの残りはキーを使用して、SSLセッションの間にしっかりと交換された他のパラメタであると機密保護されたUDP/IPの上で伝えられます。
5.3.3.2. Session Initiation
5.3.3.2. セッション開始
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クライアントはSRHDSPセッションを開始して、サービス(例えば、ICW)とのUDP/IPポート、および始まりを予約するのによるサービスの井戸のSSLセッションは知られているSSL/TCPポートです。 SSL Sessionを設立した後に、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ポート、鼓動の期間、および値で反応します。
Lu, et al. Informational [Page 35] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[35ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
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セッションは開くと考えられます。
5.3.3.3. Secure Reliable Datagram Transport
5.3.3.3. 安全な信頼できるデータグラム輸送
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.
メッセージパケットはしっかりと伝えられます。 プロトコルが修正する、コピーされて、失われていて、系列パケットから。
5.3.3.4. Session closure
5.3.3.4. セッション閉鎖
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.
セッションは、次の一連番号を含むCloseメッセージを使用することで終えられて、同意されたキーで暗号化されます。
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.
Closeメッセージを処理するとき(受信と対照的に)、受信機はタイマを設定するはずであり、タイマが期限が切れるとき、セッションのすべての詳細が忘れられるべきです。 Ackが失せるなら、タイマは閉鎖の「再-トランスミッション」を考慮することになっていて、私たちは、まだその後の「再-トランスミッション」と再承認を解読することができる必要があります。
If any message other than a close is received after a close is processed, it is ignored.
閉鎖が処理された後に閉鎖以外の何かメッセージが受信されているなら、それは無視されます。
6. Telia/Nortel's Implementation
6. 冬胞子堆/ノーテルの実装
6.1. Overview
6.1. 概要
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:
ノーテルNetworksと提携してTeliaによって導入されたシステムはサポートに設計されていて、終わりから終わりへのメディアの前でセッションを実行するサービスが確立されるということです。 例えば、これらのサービスは以下を含んでいます。
- call transfer and number portability for redirecting calls
- call waiting and call offering for announcing a pending call
- call screening and don't disturb for filtering incoming calls
- automatic call distribution and 800-services for selecting
termination point
- 呼び出しを向け直すための呼び出し転送とナンバーポータビリティ(未定の呼び出しを発表するために提供されるキャッチホンと呼び出し)は、選別と呼んで、かかってきた電話をフィルターにかけるために擾乱されません--終了を選択するための自動呼び出し分配と800サービスが指します。
The Telia/Nortel system aims to allow service providers to develop the services mentioned above. Presently, prototypes for online incoming call disposition and automatic incoming call disposition (described in Section 2) have been developed to prove the concept.
Telia/ノーテルシステムは、サービスプロバイダーが前記のようにサービスを開発するのを許容することを目指します。 現在、オンラインかかってきた電話気質と自動かかってきた電話気質(セクション2では、説明される)のためのプロトタイプは、概念を証明するために発生しました。
Lu, et al. Informational [Page 36] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[36ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
In the Telia/Nortel architecture, services run on top of SIP Redirect Servers. The distributed nature of SIP enables these servers to be hosted, for example, by an enterprise server, a Service Provider's server cluster, a user's desktop PC, or even by a hand-held cordless device.
Telia/ノーテルアーキテクチャでは、サービスはSIP Redirect Serversの上で稼働しています。 SIPの分配された自然は、これらのサーバが企業サーバ、Service Providerのサーバクラスタ、例えばユーザのデスクトップパソコンか携帯用のコードレスのデバイスによってさえホスティングされるのを可能にします。
The SIP Redirect Server receives a SIP INVITE message for each call regardless of which network the call is being set up in. The server MAY apply any kind of service logic in order to decide on how to respond to the invitation. Service logic may interact with the user to allow the user to specify how to handle a call such as described in Section 2. This, however, is not the focus of the Telia/Nortel system.
呼び出しがどのネットワークにセットアップされているかにかかわらずSIP Redirect Serverは各呼び出しへのSIP INVITEメッセージを受け取ります。 サーバは、招待に応じる方法を決めるためにどんな種類のサービス論理も当てはまるかもしれません。 サービス論理は、ユーザがセクション2で説明されるように呼び出しを扱う方法を指定するのを許容するためにユーザと対話するかもしれません。 しかしながら、これはTelia/ノーテルシステムの焦点ではありません。
6.2. Architecture and Protocols
6.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.
アーキテクチャの後ろの概念がまるですべてのコミュニケーションがIPに基づくかのようにサービスを作成することであり、すべてのクライアントとサーバは有効にされたSIPでした。 原因のこれは既存のテレコミュニケーションネットワークで本当ではありません。 したがって、新しいタイプのネットワーク要素、Service Control Gateways(SCG)は本当の状況をサービスから隠します。
SCGs convert network-specific call control signaling to SIP messages and vice versa. A SCG behaves as a regular SIP User Agent (UA) towards the services and as a network-specific service control node in the network where the call is being set up. For example, when connecting to a GSM network, the SCG can play the role of an SCP or a MAP or an ISUP proxy. The specific role depends on what service triggers are being used in the GSM network.
SCGsは逆もまた同様にSIPメッセージに合図するネットワーク特有の呼び出しコントロールを変換します。 サービスと、そして、ネットワークにおけるネットワーク特有のサービス制御ノードとしたレギュラーのSIP Userエージェント(UA)が呼び出しが存在であるところでセットアップしたので、SCGは振る舞います。 GSMネットワークに接続するとき、例えば、SCGはSCP、MAPまたはISUPプロキシの役割を果たすことができます。 特定の役割はどんなサービス引き金がGSMネットワークに使用されているかによります。
SCGs handle protocol conversions but not address translation, such as telephone number to SIP URL, which is handled by a regular SIP Server to keep the SCG as simple as possible.
SCGsはアドレス変換ではなく、プロトコル変換を扱います、SIP URLへの電話番号などのように。(SIP URLは、できるだけ簡単にSCGを保つために通常のSIP Serverによって扱われます)。
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.)
ナンバーポータビリティに関するサービスの例を考えてください。 モバイルCircuit Switched Network(CSN)の従来のナンバーポータビリティ実装はネットワーク内部のデータベースアプリケーションまで数の質問を運ぶINAPメッセージを使用します。 ここと、Number Server(NS)と呼ばれたSCGと高性能SIP Redirect ServerはSCPに通常位置するデータベースを取り替えました。 (図11を参照してください。)
Lu, et al. Informational [Page 37] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[37ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
+-----------+ INAP +-----+ SIP +--------------------------+ | CSN node |--------| SCG |-------| NS (SIP Redirect Server) | +-----------+ +-----+ +--------------------------+
+-----------+ INAP+-----+ 一口+--------------------------+ | CSNノード|--------| SCG|-------| ナノ秒(一口の再直接のサーバ)| +-----------+ +-----+ +--------------------------+
Figure 11: An Architecture for Number Portability
図11: ナンバーポータビリティのためのアーキテクチャ
The INAP IDP message that carries the number query is converted to a SIP INVITE message by the SCG and is then forwarded to the NS (SIP Redirect Server).
数の質問を運ぶINAP IDPメッセージは、SCGによってSIP INVITEメッセージに変換されて、NS(SIP Redirect Server)に送られたその時です。
If the called number is not registered, then the NS will return "404 Not Found". The SCG interprets this as "non ported number" and returns a CON message to the CSN network, making it connect the call to the called number.
呼ばれた数が登録されていないと、NSは「見つけられなかった404」を返すでしょう。 SCGは「非移植された数」としてこれを解釈して、CONメッセージをCSNネットワークに返します、呼ばれた数に呼び出しを関連づけさせて。
If the number is ported and hence registered, then the NS will return "301 Moved Permanently" with a TEL URL (routing number) in the contact field. The SCG then returns a CON message to the CSN network, making it connect the call to the number that was conveyed in the contact field.
数が移植されて、したがって、示されるなら、TEL URL(ルーティング番号)が接触分野にある状態でNSが「301は永久に、移行したこと」を返すその時です。 次に、SCGはCONメッセージをCSNネットワークに返します、接触分野で伝えられた数に呼び出しを関連づけさせて。
The solution above enables the same Number Server to provide Number Portability to multiple networks by means of using multiple SCGs.
上のソリューションは、複数のSCGsを使用することによって同じNumber Serverが複数のネットワークにNumber Portabilityを提供するのを可能にします。
If we make the SIP server in the number portability example operate in proxy mode for selected numbers, then it will become a kind of service router, able to relay number queries to any SIP-Redirect- Server-based service anywhere, provided there is an IP connection to the host in concern. Figure 12 shows the arrangement.
私たちが選択された数のためにプロキシモードでナンバーポータビリティの例のSIPサーバを作動させると、一種のサービスルータになるでしょう、どこでもどんなSIP再直接のサーバベースのサービスにも数の質問をリレーできます、ホストとのIP接続が関心であれば。 図12はアレンジメントを示しています。
+------+ INAP +-----+ SIP +----------------+ SIP +----------+ | CSN |------| SCG |-----| NS |-----| Service | | node | | | |(redirect/proxy)| |(redirect)| +------+ +-----+ +----------------+ +----------+
+------+ INAP+-----+ 一口+----------------+ 一口+----------+ | CSN|------| SCG|-----| ナノ秒|-----| サービス| | ノード| | | |(再直接の/プロキシ)| |(再直接)です。| +------+ +-----+ +----------------+ +----------+
Figure 12: SIP-Based Service Router
図12: 一口ベースのサービスルータ
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.
私たちが付加価値が付いたサービスを接続すると仮定してください、ユーザのデスクトップパソコンによって主催されたパーソナルCall Filteringサービスのように、ある電話番号に。 INAP IDPメッセージは、SCGによってSIP INVITEメッセージに変換されて、NSに送られたその時です、ちょうど前の例のように。 しかしながら、この場合、数はSIP URLの参照に示されます。 これは登録されたURLへのSIP INVITEメッセージをNumber Serverプロキシに作ります。(URLはサービスのアドレスです)。
Lu, et al. Informational [Page 38] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[38ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
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 Redirect ServerとパーソナルCall Filteringサービス論理が応答を決定するとき、サービスは応じます。 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であるなら、電話番号は接触分野で運ばれます。 ユーザがそうすることができるなら、次に、いくつかの異なったアドレス、それらのSHOULDを通して達してください。複数の接触分野による応答に加えられます。 そして、SCGはノードに、有効なアドレスか数の質問を発行したアプリケーションを選択します。
As illustrated by the service examples, the Telia/Nortel system aims to allow the introduction of multi-network services without requiring multi-protocol support. The services hence operate in the same way regardless of in which network the call is made and common IP services can be shared across heterogeneous networks.
サービスの例によって例証されるように、Telia/ノーテルシステムは、マルチプロトコルサポートを必要としないでマルチネットワークサービスの導入を許すことを目指します。 同様に、どのネットワークに電話をかけて、異機種ネットワークの向こう側に一般的な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 |
+--------+ '......' +-----------+
+-----------+ +-------+ 一口+----+ ...... 一口+-----------+ | ネットワーク1|---| SCG1|-----| |---: :-----| サービスA| +-----------+ +-------+ | | : : +-----------+ | | : : +-----------+ +-------+ 一口| | : : 一口+-----------+ | ネットワーク2|---| SCG2|-----| ナノ秒|---: :-----| サービスB| +-----------+ +-------+ | | : いくらか: +-----------+ | | : IP: +-----------+ +-------+ 一口| | : ネット: 一口+-----------+ | ネットワークn|---| SCG n|-----| |---: 仕事:-----| サービスC| +-----------+ +-------+ +----+ : : +-----------+ : : +--------+ 一口: : 一口+-----------+ | Uaをちびちび飲んでください。|-----------------------------: :-----| サービスx| +--------+ '......' +-----------+
Figure 13: Interconnecting Heterogeneous Networks via SIP
図13: SIPを通してHeterogeneous Networksとインタコネクトします。
6.3. Security
6.3. セキュリティ
The Telia/Nortel architecture uses security mechanisms available to ordinary SIP services, implemented as they would be in a pure SIP network. The architecture described here does not impose any additional security considerations.
Telia/ノーテルアーキテクチャは純粋な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
考えなければならない総合証券問題は2つの異なったネットワークのインタコネクトを含んでいます。 したがって、SCGsは破壊的なサービス制御が1つのネットワークからもう片方まで合図するのを防ぐメカニズムを含まなければなりません。 例えば、ファイアウォールタイプ
Lu, et al. Informational [Page 39] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[39ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
mechanism that can block a denial-of- service attack from an Internet user toward the PSTN.
それは否定を妨げることができます。メカニズム、-サービスでは、インターネットユーザから、PSTNに向かって攻撃してください。
7. Security Considerations
7. セキュリティ問題
Overall, the SPIRITS security requirements are essentially the same as those for PINT [3, 4], which include, for example:
全体的に見て、SPIRITSセキュリティ要件はPINT[3、4]のためのそれらと本質的には同じです。(例えば、PINTは以下を含んでいます)。
+ 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.
前項で見られるように、本書では調べられたほとんどの実装がこれらの必要条件を満たす手段(例えば、ファイアウォールと暗号化)を使いました。 しかしながら、実装によって手段は異なっています。
8. Conclusion
8. 結論
This document has provided information relevant to the development of inter-networking interfaces between the PSTN and Internet for supporting SPIRITS services. Specifically, it described four existing implementations of SPIRITS-like services. Surveying these implementations, we can make the following observations:
このドキュメントはSPIRITSがサービスであるとサポートするのにおいて、PSTNとインターネットとのインターネットワーキングインタフェースの開発に関連している情報を提供しました。 明確に、それは4つの既存のSPIRITSのようにサービスの実装について説明しました。 これらの実装について調査して、私たちは以下の観測をすることができます:
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 ベースのコミュニケーションがPSTNとインターネットの間で議定書を作るとき、SIPは実装の大部分に使用されます。 (NECの実装は固有のプロトコルを使用する唯一の例外です。 それにもかかわらず、NECには、SPIRITSサービスのための拡大と共にSIPをサポートする計画があります。)
o All implementations use IN-based solutions for the PSTN part.
o すべての実装がPSTN部分にINベースのソリューションを使用します。
Lu, et al. Informational [Page 40] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[40ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
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作業部会に関するタスクです。
9. References
9. 参照
[1] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions
to SIP and SDP for IP Access to Telephone Call Services", RFC
2848, June 2000.
[1] Petrack、S.、およびL.コンロイ、「パイントサービスは議定書を作ります」。 「通話サービスへのIPアクセスのための一口とSDPへの拡大」、RFC2848、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.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、1999年3月。
[3] Lu, H. (Ed.), Krishnaswamy, M., Conroy, L., Bellovin, S., Burg,
F., DeSimone, A., Tewani, F., Davidson, D., Schulzrinne, H. and
K. Vishwanathan, "Toward the PSTN/Internet Inter-Networking--
Pre-PINT Implementations", RFC 2458, November 1998.
[3]Lu、H.編(Krishnaswamy、M.、コンロイ、L.、Bellovin、S.、町、F.、DeSimone、A.、Tewani、F.、ディヴィッドソン、D.、Schulzrinne、H.、およびK.ウィシュワナタン)、「パイントプレPSTN/インターネットインターネットワーキング、実装、」、RFC2458(1998年11月)
10. Authors' Addresses
10. 作者のアドレス
Igor Faynberg Lucent Technologies Room 4L-334 101 Crawfords Corner Road Holmdel, NJ, USA 07733-3030
イーゴリFaynbergルーセントテクノロジーズ余地の4L-334 101 Crawfordsコーナー道路Holmdel、ニュージャージー、米国07733-3030
Phone: +1 732 949 0137 EMail: faynberg@lucent.com
以下に電話をしてください。 +1 0137年の732 949メール: faynberg@lucent.com
Hui-Lan Lu Lucent Technologies Room 4L-317 101 Crawfords Corner Road Holmdel, NJ, USA 07733-3030
余地の4L-317 101 Crawfordsコーナー道路Holmdel、ニュージャージー、ホイ-ランLuルーセントテクノロジーズ米国07733-3030
Phone: +1 732 949 0321 EMail: huilanlu@lucent.com
以下に電話をしてください。 +1 0321年の732 949メール: huilanlu@lucent.com
Lu, et al. Informational [Page 41] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[41ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
John Voelker Lucent Technologies Room 1A-417 263 Shuman Blvd PO Box 3050 Naperville, IL, USA 60566-7050
ナパービル、IL、ジョンVoelkerルーセントテクノロジーズ余地の1A-417 263シューマンBlvd PO Box3050米国60566-7050
Phone: +1 630 713 5538 EMail: jvoelker@lucent.com
以下に電話をしてください。 +1 5538年の630 713メール: jvoelker@lucent.com
Mark Weissman Lucent Technologies Room NE406B 200 Lucent Lane Cary, NC, USA 27511-6035
マークワイズマンルーセントテクノロジーズ余地のNE406B200の透明なLaneケーリー、NC、米国27511-6035
Phone: +1 919 463 3258 EMail: maw1@lucent.com
以下に電話をしてください。 +1 3258年の919 463メール: maw1@lucent.com
Weizhong Zhang Lucent Technologies Room 01-A5-17 2000 Regency Parkway Cary, NC, USA 27511-8506
Weizhongチャンルーセントテクノロジーズの余地の01-A5-17 2000リージェンシーのParkwayケーリー(NC)、米国27511-8506
Phone: +1 919 380-6638 EMail: wzz@lucent.com
以下に電話をしてください。 +1 919 380-6638 メールしてください: wzz@lucent.com
Sung-Yurn Rhim Korea Telecom 17 Woomyun-dong Seocho-gu, Seoul, Korea
Seocho-gu、歌われたYurn Rhim韓国テレコム17Woomyun-ドングソウル(韓国)
Phone: +82 2 526 6172 EMail: syrhim@kt.co.kr
以下に電話をしてください。 +82 2 526 6172はメールされます: syrhim@kt.co.kr
Jinkyung Hwang Korea Telecom 17 Woomyun-dong Seocho-gu, Seoul, Korea
Seocho-gu、Jinkyungファン韓国テレコム17Woomyun-ドングソウル(韓国)
Phone: +82 2 526 6830 EMail: jkhwang@kt.co.kr
以下に電話をしてください。 +82 2 526 6830はメールされます: jkhwang@kt.co.kr
Lu, et al. Informational [Page 42] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[42ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
Shinji. Ago NEC Corporation 1131, Hinode, Abiko, Chiba, 270-1198, Japan
宍道。 前、NEC1131、日の出、千葉我孫子、270-1198、日本
Phone: +81 471 85 7412 EMail: ago@ssf.abk.nec.co.jp
以下に電話をしてください。 +81 471 85 7412はメールされます: ago@ssf.abk.nec.co.jp
S. Moeenuddin NEC America, Inc 1525 Walnut Hill Lane, Irving, TX, USA 75038
S.Moeenuddin NECアメリカ、Inc1525クルミヒルレーン、アービング、テキサス、米国75038
Phone: +1 972 518 5102 EMail: moeen@asl.dl.nec.com
以下に電話をしてください。 +1 5102年の972 518メール: moeen@asl.dl.nec.com
S. Hadvani NEC America, Inc 1525 Walnut Hill Lane, Irving, TX, USA 75038
S.Hadvani NECアメリカ、Inc1525クルミヒルレーン、アービング、テキサス、米国75038
Phone: +1 972 518 3628 EMail: hadvani@asl.dl.nec.com
以下に電話をしてください。 +1 3628年の972 518メール: hadvani@asl.dl.nec.com
Soren Nyckelgard Telia Research Chalmers Teknikpark 41288 Gothenburg Sweden
ゾーレンNyckelgard冬胞子堆研究チャーマーズTeknikpark41288イェーテボリスウェーデン
EMail: soren.m.nyckelgard@telia.se
メール: soren.m.nyckelgard@telia.se
John Yoakum Nortel Networks 507 Airport Blvd, Suite 115, Morrisville, NC, USA 27560
ジョンYoakumノーテルはMorrisville、NC米国 507空港Blvd、スイート115、27560をネットワークでつなぎます。
EMail: yoakum@nortelnetworks.com
メール: yoakum@nortelnetworks.com
Lewis Robart Nortel Networks P.O. Box 402 Ogdensburg, NY, USA 13669
ルイスRobartノーテルはOgdensburg、ニューヨーク米国 私書箱402 13669をネットワークでつなぎます。
EMail: robart@nortelnetworks.com
メール: robart@nortelnetworks.com
Lu, et al. Informational [Page 43] RFC 2995 Pre-SPIRITS Implementations November 2000
Lu、他 情報[43ページ]のRFC2995は2000年11月に実装にあらかじめ生気を与えさせます。
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Lu, et al. Informational [Page 44]
Lu、他 情報[44ページ]
一覧
スポンサーリンク
