[要約] RFC 2458は、PSTNとインターネットの相互接続に向けた事前の実装についてのガイドラインです。その目的は、PINT（PSTN/Internet Inter-Networking）の実現に向けた準備を支援し、相互接続の実装に関する情報を提供することです。
Netowrk Working Group H. Lu
Request for Comments: 2458 Editor
Category: Informational M. Krishnaswamy
Lucent Technologies
L. Conroy
Roke Manor Research
S. Bellovin
F. Burg
A. DeSimone
K. Tewani
AT&T Labs
P. Davidson
Nortel
H. Schulzrinne
Columbia University
K. Vishwanathan
Isochrome
November 1998
Toward the PSTN/Internet Inter-Networking --Pre-PINT Implementations
PSTN /インターネットインターネットワーキングに向けて-PINT前の実装
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document contains the information relevant to the development of the inter-networking interfaces underway in the Public Switched Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Group. It addresses technologies, architectures, and several (but by no means all) existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services. The common denominator of the enriched services (a.k.a. PINT services) is that they combine the Internet and PSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over the PSTN. One key observation is that the pre-PINT implementations, being developed independently, do not inter-operate. It is a task of the PINT Working Group to define the inter-networking interfaces that will support inter-operation of the future implementations of PINT services.
このドキュメントには、公衆交換電話網（PSTN）/インターネットインターネットワーキング（PINT）ワーキンググループで進行中のインターネットワーキングインターフェースの開発に関連する情報が含まれています。それは、テクノロジ、アーキテクチャ、およびインターネットアプリケーションがPSTN通信サービスを要求および強化するための配置のいくつかの（ただし、すべてではない）既存のPINT実装に対応しています。エンリッチサービス（別名PINTサービス）の共通点は、インターネットとPSTNサービスを組み合わせて、音声以外のやり取りにインターネットを使用し、音声（およびFAX）を完全にPSTN経由で伝送することです。重要な観察結果の1つは、PINT前の実装は独立して開発されており、相互運用できないことです。 PINTサービスの将来の実装の相互運用をサポートする内部ネットワークインターフェイスを定義することは、PINTワーキンググループのタスクです。
Table of Contents
目次
1. Introduction ....................................... 3
2. Terminology ....................................... 3
3. PINT Services ....................................... 4
4. Architectural Overview ............................... 5
4.1 Public Switched Telephone Network ............... 5
4.2 Pre-PINT Systems ............................... 9
5. IN-Based Solutions ............................... 20
5.1 The Lucent System ............................... 20
5.1.1 Roles of the Web Server, Service Node, and SMS ....... 20
5.1.2 A Click-to-Dial-Back Service Scenario ............... 21
5.1.3 Web Server-Service Node Interface ............... 22
5.1.4 Web Server-SMS Interface and SNMP MIB ............... 24
5.1.5 Security Considerations ........................... 26
5.2 Siemens Web Call Center ........................... 27
5.2.1 Service Description ............................... 27
5.2.2 Implementation ................................... 29
5.2.3 Derived Requirements/Lessons ..................... 35
6. Alternative Solutions ............................... 37
6.1 The AT&T System ..................................... 37
6.1.1 High Level Architecture ............................ 38
6.1.2 IP Client to CallBroker Interface .................. 39
6.1.3 Protocol ........................................... 40
6.1.4 APIs Exposed to the IP Client ..................... 41
6.1.5 Voice-Bridge Control API ........................ 41
6.2 Simple Computer Telephony Protocol ............... 41
6.2.1 Overview ........................................... 41
6.2.2 How SCTP Fits in with the Reference PINT Services .. 42
7. Session Initiation Protocol--An Emerging Standard .. 43
7.1 Overview ....................................... 43
7.2 SIP Protocol ....................................... 44
7.3 SIP Entities ....................................... 45
7.4 Providing Call Control Functionality ............... 46
8. Overall Security Considerations ..................... 47
9. Conclusion ....................................... 48
10. Acknowledgments ................................... 48
11. Appendix ....................................... 49
11.1 PSTN/IN 101 ....................................... 49
11.1.1 Public Switched Telephone Network ............... 49
11.1.2 Intelligent Network ............................... 51
11.2 Call Center Features ............................. 54
12. References ....................................... 56
Authors' Addresses ......................................... 57
Full Copyright Statement .................................. 60
This document contains the information relevant to the development of the inter-networking interfaces underway in the Public Switched Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Group. It addresses technologies, architectures, and several (but by no means all) existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services. The common denominator of the enriched services (a.k.a. PINT services) is that they combine the Internet and PSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over the PSTN.
このドキュメントには、公衆交換電話網（PSTN）/インターネットインターネットワーキング（PINT）ワーキンググループで進行中のインターネットワーキングインターフェースの開発に関連する情報が含まれています。それは、テクノロジ、アーキテクチャ、およびインターネットアプリケーションがPSTN通信サービスを要求および強化するための配置のいくつかの（ただし、すべてではない）既存のPINT実装に対応しています。エンリッチサービス（別名PINTサービス）の共通点は、インターネットとPSTNサービスを組み合わせて、音声以外のやり取りにインターネットを使用し、音声（およびFAX）を完全にPSTN経由で伝送することです。
The organization of the document is as follows. First, the basic terminology and a short "intuitive" description of the PINT services are provided. The rest of the information deals, in one way or the other, with the pre-PINT support of these services where they are used as a benchmark. Thus, an architectural overview common to all present solutions is presented. The flow of the document then divides into two streams: one is dedicated to the Intelligent Network (IN)-based solutions; the other explores alternative means (i.e., CallBroker and Computer-Telephony Integration (CTI) approach). At this point, the emerging standards are explored, in particular, the Session Initiation Protocol (SIP), which promises an elegant solution to the PINT problem. Each of the above developments is addressed in a respective section. The final sections of the document contain the overall security considerations, conclusion, acknowledgments, appendix, and a set of references. The security section summarizes the PINT security requirements derived from the pre-PINT experiences and the appendix presents a tutorial on the PSTN, IN, and Call Center functions.
ドキュメントの構成は次のとおりです。最初に、PINTサービスの基本的な用語と短い「直感的な」説明が提供されます。残りの情報は、これらのサービスがベンチマークとして使用される場合、これらのサービスの事前PINTサポートを何らかの方法で扱います。したがって、現在のすべてのソリューションに共通するアーキテクチャの概要が提示されます。その後、ドキュメントのフローは2つのストリームに分かれます。1つはインテリジェントネットワーク（IN）ベースのソリューション専用です。もう1つは、代替手段（つまり、CallBrokerおよびComputer-Telephony Integration（CTI）アプローチ）を探ります。この時点で、新たな標準、特にPINT問題のエレガントなソリューションを約束するセッション開始プロトコル（SIP）が検討されています。上記の開発のそれぞれは、それぞれのセクションで説明されています。ドキュメントの最後のセクションには、全体的なセキュリティの考慮事項、結論、謝辞、付録、および参照のセットが含まれています。セキュリティセクションでは、PINT前のエクスペリエンスから得られたPINTセキュリティ要件を要約し、付録では、PSTN、IN、およびコールセンター機能に関するチュートリアルを示します。
This document uses the following terminology:
このドキュメントでは、次の用語を使用しています。
Authentication -- verification of the identity of a party.
認証-当事者の身元の確認。
Authorization -- determination of whether or not a party has the right to perform certain activities.
承認-当事者が特定の活動を実行する権利を持っているかどうかの決定。
PINT Gateway -- the PSTN node that interacts with the Internet.
PINTゲートウェイ-インターネットと対話するPSTNノード。
User or Customer -- the person who asks for a service request to be issued. In the context of PINT Services, this person will use an Internet host to make his or her request. The term "user" is also used to describe a host originating the PINT service request on behalf of this person.
ユーザーまたは顧客-サービス要求の発行を要求する人。 PINTサービスのコンテキストでは、この人物はインターネットホストを使用してリクエストを行います。 「ユーザー」という用語は、このユーザーに代わってPINTサービス要求を発信するホストを表すためにも使用されます。
This document addresses four services initially identified by the PINT Working Group and presently supported by pre-PINT implementations. These services are: click-to-dial-back, click-to-fax, click-to-fax-back and voice-access-to-content.
このドキュメントは、PINTワーキンググループによって最初に識別され、PINT以前の実装によって現在サポートされている4つのサービスを扱います。これらのサービスは、クリックからダイヤルバック、クリックからFAX、クリックからFAXバック、音声アクセスからコンテンツです。
Note that the word "click" should not be taken literally. It is rather used to point out that initiation of the related services takes place on the Internet, where point and click are the most prevalent user actions. In other words, a service request could originate from any type of IP-based platforms. There is no implication that these services must be implemented by a device within the PSTN or the Internet running a Web server.
「クリック」という言葉は文字どおりに解釈されるべきではないことに注意してください。むしろ、関連サービスの開始がインターネット上で行われることを指摘するために使用されます。この場合、ポイントアンドクリックが最も一般的なユーザーアクションです。つまり、サービス要求は、あらゆるタイプのIPベースのプラットフォームから発生する可能性があります。これらのサービスは、PSTN内のデバイスまたはWebサーバーを実行しているインターネットによって実装する必要があるという意味ではありません。
The common denominator of the PINT services is that they combine the Internet and PSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over the PSTN. (An example of such a service is combination of a Web-based Yellow Pages service with the ability to initiate PSTN calls between customers and suppliers in a manner described in what follows.)
PINTサービスの共通点は、インターネットとPSTNサービスを組み合わせて、インターネットが音声以外の対話に使用される一方で、音声（およびFAX）が完全にPSTNを介して伝送されることです。 （このようなサービスの例は、Webベースのイエローページサービスと、以下に説明する方法で顧客とサプライヤの間のPSTNコールを開始する機能の組み合わせです。）
Some of the benefits of using the PSTN are high quality of the voice, an ability to route the call to different locations depending on pre-set criteria (for example, time of the day, day of the week, and geographic location), outstanding security and reliability, and access to flexible, low cost, and secure billing and charging systems. The benefits of using the Internet are the uniform, well-defined, and widely-used interfaces available anywhere, anytime.
PSTNを使用する利点のいくつかは、高品質の音声、事前に設定された基準（たとえば、時刻、曜日、地理的な場所など）に応じて通話をさまざまな場所にルーティングする機能、卓越したものです。セキュリティと信頼性、そして柔軟で低コストで安全な請求および課金システムへのアクセス。インターネットを使用する利点は、どこでも、いつでも利用できる、統一された、明確に定義された、広く使用されているインターフェイスです。
Click-to-Dial-Back
Click-to-Dial-Back
With this service, a user requests (through an IP host) that the PSTN call be established between another party and himself or herself. An important pre-requisite for using this service is that the user has simultaneous access to both the PSTN and Internet.
このサービスを使用すると、ユーザーは（IPホスト経由で）PSTN通話が他の当事者との間に確立されることを要求します。このサービスを使用するための重要な前提条件は、ユーザーがPSTNとインターネットの両方に同時にアクセスできることです。
One example of an application of this service is on-line shopping: a user browsing through an on-line catalogue, clicks a button thus inviting a call from a sales representative. Note that (as is the case with the all-PSTN Free-Phone, or "800", service) flexible billing arrangements can be implemented here on behalf of the service provider. In addition (and also similarly to the Free-Phone/800), the PSTN could route the call depending on the time of day, day of week, availability of agents in different locations, and so on.
このサービスのアプリケーションの1つの例は、オンラインショッピングです。ユーザーがオンラインカタログを閲覧し、ボタンをクリックして、営業担当者からの電話を招待します。 （すべてのPSTNフリーフォン、つまり「800」サービスの場合と同様に）ここでは、サービスプロバイダーに代わって柔軟な課金の仕組みを実装できます。さらに（また、Free-Phone / 800と同様に）、PSTNは、時刻、曜日、さまざまな場所でのエージェントの対応状況などに応じて、コールをルーティングできます。
Click-to-Fax
Click-to-Fax
With this service, a user at an IP host requests that a fax be sent to a particular fax number. In particular this service is especially meaningful when the fax is to be sent to someone who has only a fax machine (but no access to the Internet). Consider, as an example, a service scenario in which a Web user makes a reservation for a hotel room in Beijing from a travel service page containing hotel information of major cities around the world. Suppose a specific Beijing hotel chosen by the user does not have Internet connection but has a fax machine. The user fills out the hotel reservation form and then clicks a button sending out the form to the travel service provider, which in turn generates a fax request and sends it together with the hotel reservation form to the PSTN. Upon receiving the request and the associated data, the PSTN translates the data into the proper facsimile format and delivers it to the Beijing hotel as specified in the fax request.
このサービスを使用すると、IPホストのユーザーは、特定のFAX番号にFAXを送信するように要求します。特に、このサービスは、ファックスがファックス機だけを持っている（インターネットにはアクセスできない）誰かに送信される場合に特に意味があります。例として、世界中の主要都市のホテル情報を含む旅行サービスページから、Webユーザーが北京のホテルの部屋を予約するサービスシナリオを考えてみます。ユーザーが選択した特定の北京のホテルにインターネット接続はなく、ファックスがあるとします。ユーザーはホテル予約フォームに記入し、フォームを旅行サービスプロバイダーに送信するボタンをクリックすると、FAX要求が生成され、ホテル予約フォームと共にPSTNに送信されます。 PSTNは、要求と関連データを受信すると、データを適切なファクシミリ形式に変換し、FAX要求で指定されたとおりに北京のホテルに配信します。
Click-to-Fax-Back
Click-to-Fax-Back
With this service, a user at an IP host can request that a fax be sent to him or her. (Consider the user of the previous example, who now requests the confirmation from the Beijing Hotel. Another useful application of the service is when size of the information that a user intends to get is so large that downloading it to the user's PC over the Internet will require a long time and a lot of disk space.)
このサービスを使用すると、IPホストのユーザーは、ファックスの送信を要求できます。 （今、北京ホテルに確認を要求する前の例のユーザーを考えてください。このサービスのもう1つの有用なアプリケーションは、ユーザーが取得しようとしている情報のサイズが大きすぎて、インターネットを介してユーザーのPCにダウンロードする場合です。長時間と多くのディスク容量が必要になります。）
Voice-Access-to-Content
コンテンツへの音声アクセス
With this service, a user at an IP host requests that certain information on the Internet be accessed (and delivered) in an audio form over the PSTN, using the telephone as an informational appliance. One application of this service is to provide Web access to the blind. (This may require special resources--available in the PSTN--to convert the Web data into speech.)
このサービスでは、IPホストのユーザーが、電話を情報機器として使用して、インターネット上の特定の情報に音声形式でPSTN経由でアクセス（および配信）することを要求します。このサービスの1つのアプリケーションは、視覚障害者にWebアクセスを提供することです。 （これには、Webデータを音声に変換するためにPSTNで利用可能な特別なリソースが必要になる場合があります。）
From an application perspective, Internet nodes are interconnected directly, as shown in Figure 1. When two machines are to communicate, they will have the address of the destination end system, and will send network level datagrams, assuming that the underlying infrastructure will deliver them as required.
アプリケーションの観点から見ると、図1に示すように、インターネットノードは直接相互接続されています。2台のマシンが通信する場合、それらは宛先エンドシステムのアドレスを持ち、ネットワークレベルのデータグラムを送信します。要求に応じ。
_____
__ _____/ \_____
[__] / \
[----]-.-.-.-. Internet .-.
\_____ _______/ |
__ \__./ __ .
[__] / [__] |
[----]-. [----]-.
Key: .-.-. Internet Access Link
キー：.-.-。インターネットアクセスリンク
Figure 1
図1
Where all nodes are on the same (broadcast) network, there is no need for intervening routers; they can send and deliver packets to one another directly. The Internet nodes are responsible for their own communications requests, and act as peers in the communication sessions that result.
すべてのノードが同じ（ブロードキャスト）ネットワーク上にある場合、介在するルーターは必要ありません。パケットを直接相互に送信および配信できます。インターネットノードは自身の通信要求を担当し、結果として生じる通信セッションでピアとして機能します。
This contrasts with the situation in the PSTN. There, the end systems are configured as shown in Figure 2. The end systems tend to be specific to a particular type of traffic, so that, for example, the majority of terminals are dedicated to carrying speech traffic (telephones) or to carrying facsimile data (fax machines). The terminals all connect to Central Offices (COs) via access lines, and these COs are interconnected into a network.
これは、PSTNの状況とは対照的です。そこでは、エンドシステムは図2に示すように構成されます。エンドシステムは特定のタイプのトラフィックに固有である傾向があるため、たとえば、端末の大部分は音声トラフィック（電話）の伝送またはファクシミリの伝送に専用されます。データ（ファックス機）。端末はすべて、アクセス回線を介して中央局（CO）に接続し、これらのCOはネットワークに相互接続されます。
/--\
()/\()__
/__\ \ .................................
\ ! ! ! /--\
__ \ [-!-] [-!-] ! ()/\()
\ \ \__[CO ]=========[CO ]==\\ ! ___/__\
[Fax]________[---] [---] \\ [-!-] / __
\\=======[CO ]____/ \ \
[---]________[Fax]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
Figure 2
図2
Communications between the terminals are all "circuit switched", so a dedicated synchronous data path (or circuit) needs to be placed between the end terminals for carrying all communications. Arranging for such a circuit to be made or removed (cleared) is the responsibility of the Central Offices in the network. A user makes a request via his or her terminal, and this request is passed on to the "local" Central Office. The relationship between the terminals and the local Central Offices to which they are connected is strictly Client/Server.
端末間の通信はすべて「回線交換」であるため、すべての通信を行うために専用の同期データパス（または回線）を端末間に配置する必要があります。このような回線の作成または削除（クリア）の手配は、ネットワーク内の中央局の責任です。ユーザーが自分の端末を介して要求を行い、この要求は「ローカル」の中央局に渡されます。ターミナルとターミナルが接続されているローカルセントラルオフィス間の関係は、厳密にクライアント/サーバーです。
The COs are interconnected using two different types of connections. One of these is called a trunk connection (shown as a double line in the above figure) and is used to carry the data traffic generated by the terminals. The other connection acts as part of a separate network (and is shown as a dotted line in the above figure). This is the signaling network, and is used by the Central Offices to request a connection to be made between themselves and the destination of the required circuit. This will be carried across the trunk link to the "next" Central Office in the path. The path, once in place through the PSTN, always takes the same route. This contrasts with the Internet, where the underlying datagram nature of the infrastructure means that data packets are carried over different routes, depending on the combined traffic flows through the network at the time.
COは、2つの異なるタイプの接続を使用して相互接続されます。これらの1つはトランク接続と呼ばれ（上の図では二重線で示されています）、端末によって生成されたデータトラフィックを伝送するために使用されます。他の接続は、別のネットワークの一部として機能します（上図では点線で示されています）。これはシグナリングネットワークであり、セントラルオフィスが自身と必要な回線の宛先との間の接続を要求するために使用します。これは、パスの「次の」セントラルオフィスへのトランクリンクを介して伝送されます。パスは、PSTNを通過すると、常に同じルートを使用します。これは、インフラストラクチャの基礎となるデータグラムの性質が、その時点でネットワークを通過する結合トラフィックフローに応じて、データパケットが異なるルートを介して伝送されることを意味するインターネットとは対照的です。
The call set up process can be viewed as having two parts: one in which a request for connection is made, and the other in which the circuit is made across the PSTN and call data flows between the communicating parties. This is shown in the next pair of figures (3a and 3b).
コールセットアッププロセスは、2つの部分で構成されていると見なすことができます。1つは接続の要求が行われる部分、もう1つはPSTN全体で回線が作成され、通信相手間のコールデータフローです。これは、次のペアの図（3aおよび3b）に示されています。
/--\
() ()
--____
/++\ \
/----\ \
A \ [-!-]
\->[CO ]
[---]
Time = 13:55
Figure 3a
図3a
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
/--\
() ()
-- .................................
/ \<--- ^ ! ! /--\
/----\ \ ! v ! () ()
A' \ [-!-] [-!-] ! --
\__[CO ]=========[CO ]==\\ v ->-/ \
[---] [---] \\ [-!-] / /----\
\\=======[CO ]____/ B'
Time = 14:00 [---]
Figure 3b
フィギュアコレクション
Figure 3 shows a particular kind of service that can be provided; call booking. With this service, a request is sent for a connection to be made between the A and B telephones at a specified time. The telephone is then replaced (the request phase is terminated). At the specified time, the CO will make a connection across the network in the normal way, but will, first, ring the "local" or A' telephone to inform the user that his or her call is now about to be made.
図3は、提供できる特定の種類のサービスを示しています。予約を呼び出します。このサービスでは、指定された時刻にA電話とB電話の間で行われる接続の要求が送信されます。その後、電話が交換されます（要求フェーズは終了します）。指定された時間に、COは通常の方法でネットワークを介して接続を行いますが、最初に「ローカル」またはA '電話を呼び出して、ユーザーに通話が発信されることを通知します。
For more complex services, the requesting telephone is often connected via its "local" CO to a Service Node (SN), where the user can be played prompts and can specify the parameters of his or her request in a more flexible manner. This is shown below, in Figures 4a and 4b. For more details of the operation of the Service Node (and other Intelligent Network units), see the Appendix.
より複雑なサービスの場合、要求元の電話は、その「ローカル」COを介してサービスノード（SN）に接続されることが多く、ユーザーはプロンプトを再生して、より柔軟な方法で要求のパラメーターを指定できます。これを以下の図4aおよび4bに示します。サービスノード（およびその他のインテリジェントネットワークユニット）の動作の詳細については、付録を参照してください。
When the SN is involved in the request and in the call setup process, it appears, to the CO, to be another PSTN terminal. As such, the initial request is routed to the Service Node, which, as an end system, then makes two independent calls "out" to A' and B'.
SNが要求およびコールセットアッププロセスに含まれている場合、COには、別のPSTN端末のように見えます。そのため、最初の要求はサービスノードにルーティングされます。サービスノードは、エンドシステムとして、A 'およびB'に対して2つの独立した呼び出しを「発信」します。
/--\ [---]
() () [SN ]
--___ [|--]
/++\ \ |
/----\ \ |
\ |
A \ [|-!]
\->[CO ]
[---]
Time = 13:55
Figure 4a
フィギュアーチャ
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
SN Service Node
/--\ [---]
() () [SN ]
-- [|--] /--\
/ \<-- | ............................... () ()
/----\ \ | ^ ! ! --
\ | / v v / \
A' \ [|-!] [-!-] [-!-] ->-/----\
\--[CO ] [CO ] [CO ] /
[---] [---] [---]___/ B'
Time = 14:00
Figure 4b
黒と白の図
Note that in both cases as shown in Figures 3 and 4 a similar service can be provided in which the B' telephone is replaced by an Intelligent Peripheral (or an Special Resource Functional entity within a Service Node), playing an announcement. This allows a "wake up" call to be requested, with the Intelligent Peripheral or Service Node Special Resource playing a suitable message to telephone A' at the specified time. Again, for more details of the operation of the Special Resources (and other Intelligent Network units), see the Appendix.
図3および4に示すように、どちらの場合でも、B '電話がインテリジェントペリフェラル（またはサービスノード内の特殊リソース機能エンティティ）に置き換えられ、アナウンスを再生する同様のサービスを提供できます。これにより、インテリジェントペリフェラルまたはサービスノードの特殊リソースが指定された時間に電話A 'に適切なメッセージを再生することで、「ウェイクアップ」コールを要求できます。ここでも、特殊リソース（およびその他のインテリジェントネットワークユニット）の操作の詳細については、付録を参照してください。
Although the pre-PINT systems reported here (i.e., those developed by AT&T, Lucent, Siemens and Nortel) vary in the details of their operation, they exhibit similarities in the architecture. This section highlights the common features. Specific descriptions of these systems will follow.
ここで報告されているPINT以前のシステム（AT＆T、Lucent、Siemens、Nortelによって開発されたもの）は、動作の詳細が異なりますが、アーキテクチャは類似しています。このセクションでは、一般的な機能について説明します。これらのシステムの具体的な説明は次のとおりです。
All of the systems can be seen as being quite similar to that shown in the following diagram. In each case, the service is separated into two parts; one for the request and another for execution of the service. Figure 5 summarizes the process.
すべてのシステムは、次の図に示すものと非常に似ていると見なすことができます。いずれの場合も、サービスは2つの部分に分かれています。 1つは要求用で、もう1つはサービスの実行用です。図5はプロセスを要約したものです。
_____
__ _____/ \_____
[__] / \
[-++-]-.-.>.-. Internet .-.-
\_____ _______/ .
\___/ v
[----] .
[PINT]-.-
[----]
%
v
[---]
[SN ]
[|--]
Figure 5a
図5a
Key: CO Central Office (Telephone Exchange)
SN Service Node
PINT PSTN/Internet Gateway
.-.-. Internet Access Link
%%% Gateway/Service Node Link
___ PSTN Access Lines
=== PSTN Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
_____
__ _____/ \_____
[__] / \
[----]-.-.-.-. Internet .-.-
\_____ _______/ .
\___/ |
[----] .
[PINT]-.-
[-%--]
%
%
/--\ [-%-]
() () [SN ]
-- [|--] /--\
/ \<-- | .................... () ()
/----\ \ | ^ ! ! --
\ | / v v / \
A' \ [|-!] [-!-] [-!-] ->-/----\
\--[CO ]=======[CO ]======[CO ] /
[---] [---] [---]__/ B'
Figure 5b
図5b
Comparing Figure 4a with Figure 5a, the differences lie in the way that the information specifying the request is delivered to the Service Node. In the PSTN/IN method shown in the earlier diagram, the user connects to the SN from the telephone labeled A, with the connection being routed via the CO. In the latter case, the request is delivered from an Internet node, via the PINT gateway, and thence to the Service Node over a "private" link. The effect is identical, in that the request for service is specified (although the actual parameters used to specify the service required may differ somewhat).
図4aと図5aを比較すると、要求を指定する情報がサービスノードに配信される方法に違いがあります。前の図に示したPSTN / INメソッドでは、ユーザーはAというラベルの付いた電話からSNに接続し、接続はCO経由でルーティングされます。後者の場合、リクエストはPINT経由でインターネットノードから配信されます。ゲートウェイ、そしてそこから「プライベート」リンクを介してサービスノードへ。サービスの要求が指定されるという点で、効果は同じです（ただし、必要なサービスを指定するために使用される実際のパラメーターは多少異なる場合があります）。
The figures depicting the respective service execution phases (Figures 4b and 5b) show that the operation, from the IN/PSTN perspective, is again identical. The Service Node appears to initiate two independent calls "out" to telephones A' and B'.
それぞれのサービス実行フェーズを示す図（図4bおよび5b）は、IN / PSTNの観点から見ると、操作が同じであることを示しています。サービスノードは、電話A 'とB'に2つの独立したコールを「発信」するように見えます。
The alternative systems developed by AT&T and by Nortel allow another option to be used in which the PINT Gateway does not have to connect to the PSTN via a Service Node (or other Intelligent Network component), but can instead connect directly to Central Offices that support the actions requested by the gateway. In these alternatives, the commands are couched at a "lower level", specifying the call states required for the intended service connection rather than the service identifier and the addresses involved (leaving the Intelligent Network components to coordinate the details of the service call on the gateway's behalf). In this way the vocabulary of the commands is closer to that used to control Central Offices. The difference really lies in the language used for the services specification, and all systems can use the overall architecture depicted in Figure 5; the only question remains whether the Intelligent Network components are actually needed in these other approaches.
AT＆TおよびNortelによって開発された代替システムでは、PINTゲートウェイがサービスノード（または他のインテリジェントネットワークコンポーネント）を介してPSTNに接続する必要がなく、代わりにサポートするセントラルオフィスに直接接続できる別のオプションを使用できますゲートウェイによって要求されたアクション。これらの代替案では、コマンドは「低レベル」で処理され、サービス識別子と関連アドレスではなく、目的のサービス接続に必要な呼び出し状態を指定します（インテリジェントネットワークコンポーネントは、サービス呼び出しの詳細を調整するために残します）ゲートウェイの代理）。このように、コマンドの語彙は、セントラルオフィスを制御するために使用される語彙に近くなります。実際の違いは、サービス仕様に使用される言語にあり、すべてのシステムは、図5に示すアーキテクチャ全体を使用できます。唯一の問題は、インテリジェントネットワークコンポーネントがこれらの他のアプローチで実際に必要かどうかということです。
The following diagram (Figure 6) shows the interface architecture involved in providing the kind of service mentioned above.
次の図（図6）は、上記のようなサービスの提供に関連するインターフェースアーキテクチャを示しています。
Internet __ __
Server [__] _______ [__]
[W3S-]-. ___/ .-.-.-[W3C-] Internet
_________________|/.-.-.-.-. \ Terminal
/ .. . \
| Internet / . \ |
\___________ . . . /
\/___|____\_________/
. . .
/ | \
(A) (B) (E)
. . .
_|_ _|_ _|_
[SN ]<-(D)--[SMS]--(H)->[SCP]
[|-|] --- [-!-]
/ \ !
(C) (I) ...........(F)...!.(G).
/ \ ! !
[--|] [|-!] [-!-]
[CO ] [MSC] [SSP]
[---] [---] \|/ [---]
/--\ | |____| | /--\
()/\() | | ()/\()
/--\___| 1 |___/--\
Fixed PSTN Terminal [] Fixed PSTN Terminal
Mobile Terminal
Key: W3S HTTP (Web) Server
W3C HTTP (Web) Client/Browser
CO Central Office (Telephone Exchange)
MSC Mobile Switching Center (Mobile Network Telephone
Exchange)
SN Service Node
SSP Service Switching Point
SCP Service Control Point
SMS Service Management System
.-.-. Internet relationship
___ PSTN Access relationship
... PSTN "core" signaling relationship
Figure 6
図6
The interfaces are:
インターフェイスは次のとおりです。
A The interface over which Internet requests for service are delivered to the Service Node B The interface over which Service Management requests are sent from the Internet to the Service Management System C The interface over which the Service Node sends call control requests to a connected Central Office D The interface over which the Service Management System manages the Service Node E The interface over which Internet requests for service are delivered to the Service Control Point F The interface over which the Service Control Point sends service call control requests to the Mobile Switching Center G The interface over which the Service Control Point sends service control requests to the Service Switching Point H The interface over which the Service Management System manages the Service Control Point I The interface over which the Service Node sends service call control requests to the Mobile Switching Center
Aインターネットへのサービス要求がサービスノードに配信されるインターフェイスBサービス管理要求がインターネットからサービス管理システムに送信されるインターフェイスCサービスノードが接続されているセントラルオフィスに通話制御要求を送信するインターフェイスDサービス管理システムがサービスノードを管理するインターフェイスEサービスのインターネット要求がサービスコントロールポイントに配信されるインターフェイスFサービスコントロールポイントがサービスコール制御要求をモバイルスイッチングセンターに送信するインターフェイスGサービスコントロールポイントがサービススイッチング要求をサービススイッチングポイントに送信するインターフェイスHサービス管理システムがサービスコントロールポイントを管理するインターフェイスIサービスノードがサービスコール制御要求をモバイルスイッチングセンターに送信するインターフェイス
In practice, a number of the interfaces have very similar purposes to one another. The means by which these purposes are achieved differ, in that some of the interfaces (C and I) reflect access arrangements, whilst others (F and G) imply a "core" signaling relationship. However, it is possible to categorize them in terms of the "intent" of messages sent across the interfaces.
実際には、多くのインターフェースは互いに非常によく似た目的を持っています。これらの目的が達成される手段は異なります。インターフェイスの一部（CおよびI）はアクセスの配置を反映し、その他のインターフェイス（FおよびG）は「コア」シグナリング関係を意味します。ただし、インターフェースを介して送信されるメッセージの「意図」に関してそれらを分類することは可能です。
For example, Interfaces A and E are similar; one of the main aims of PINT work is to ensure that they are the same. Similarly, Interfaces D and H imply similar actions and are likely to carry similar messages. Interfaces C, F, G, and I are all used to request that a call be initiated, albeit via access or core signaling relationships.
たとえば、インターフェイスAとEは似ています。 PINT作業の主な目的の1つは、それらが同じであることを確認することです。同様に、インターフェイスDとHは同様のアクションを意味し、同様のメッセージを運ぶ可能性があります。インターフェイスC、F、G、およびIはすべて、アクセスまたはコアシグナリング関係を介しても、コールの開始を要求するために使用されます。
The interfaces can also be viewed in terms of the kind of components that are involved and the bodies by which they are codified. Interfaces A, B, and E are all going to be realized as Internet Protocols. All of the others use existing protocols in the PSTN/IN. Traditionally, these have been codified by different groups, and this is likely to be the case in the PINT work.
インターフェースは、関連するコンポーネントの種類と、それらが成文化されるボディの観点からも見ることができます。インターフェイスA、B、Eはすべてインターネットプロトコルとして実現されます。他のすべては、PSTN / INの既存のプロトコルを使用します。伝統的に、これらはさまざまなグループによって成文化されており、これはPINT作業のケースに当てはまる可能性があります。
The general arrangements for the different systems are shown below (Figures 7, 8, 9, and 10). They differ in the details of their configurations, but the main tasks they perform are very similar, and so the overall operation is similar to the generic architecture shown in Figures 5 and 6.
さまざまなシステムの一般的な配置を以下に示します（図7、8、9、および10）。構成の詳細は異なりますが、実行する主なタスクは非常に似ているため、全体的な動作は図5および6に示す一般的なアーキテクチャーと同様です。
Key for following diagrams:
次の図の要点：
Components:
コンポーネント：
W3C World Wide Web Client W3S World Wide Web Server WSA Web Server "Back End Program" Interface (CGI or Servlet interface) Srvlt Servlet "back end" program/objects FS Finger Server SCTPC Simple Computer Telephony Protocol Client SCTPS Simple Computer Telephony Protocol Server CBC CallBroker Client CBS CallBroker Server SSTPC Service Support Transport Protocol Client SSF Service Switching Function SCF Service Control Function SRF Special Resource Function CO Central Office/ Public Telephone Exchange SSP Service Switching Point SCP Service Control Point SR/I.IP Special Resource/ "Internet" Intelligent Peripheral SMS Service Management System INAPAd Intelligent Network Application Part Adaptor PktFlt Packet Filter (Firewall) SNMPAg Simple Network Management Protocol Agent
W3CワールドワイドウェブクライアントW3SワールドワイドウェブサーバーWSAウェブサーバー "バックエンドプログラム"インターフェイス（CGIまたはサーブレットインターフェイス）Srvltサーブレット "バックエンド"プログラム/オブジェクトFS FingerサーバーSCTPCシンプルコンピュータテレフォニープロトコルクライアントSCTPSシンプルコンピュータテレフォニープロトコルサーバーCBC CallBrokerクライアントCBS CallBrokerサーバーSSTPCサービスサポートトランスポートプロトコルクライアントSSFサービススイッチング機能SCFサービスコントロール機能SRF特殊リソース機能COセントラルオフィス/公衆電話交換SSPサービススイッチングポイントSCPサービスコントロールポイントSR / I.IP特殊リソース/「インターネット」インテリジェントペリフェラルSMSサービス管理システムINAPAdインテリジェントネットワークアプリケーションパーツアダプターPktFltパケットフィルター（ファイアウォール）SNMPAgシンプルネットワーク管理プロトコルエージェント
Protocols:
プロトコル：
P0 HyperText Transfer Protocol P1 HTTP Server <-> "Back End Program" internal protocol P2 CallBroker Client <-> CallBroker Server protocol (AT&T system), or SCTP Client <-> Server protocol (Nortel system) P3 PINT User Agent <-> PINT Gateway protocol P4 Intra-Intelligent Network protocol (e.g., INAP) P5 Proprietary (INAP-based) Gateway-> I.IP protocol P6 Finger protocol P7 Digital Subscriber Signaling 1 protocol P8 Simple Network Management Protocol P9 SMS <-> Service Control Point/Service Node protocol
P0ハイパーテキスト転送プロトコルP1 HTTPサーバー<->「バックエンドプログラム」内部プロトコルP2 CallBrokerクライアント<-> CallBrokerサーバープロトコル（AT＆Tシステム）、またはSCTPクライアント<->サーバープロトコル（Nortelシステム）P3 PINTユーザーエージェント<-> PINTゲートウェイプロトコルP4インテリジェントネットワークプロトコル（例、INAP）P5独自（INAPベース）ゲートウェイ-> I.IPプロトコルP6フィンガープロトコルP7デジタルサブスクライバーシグナリング1プロトコルP8シンプルネットワーク管理プロトコルP9 SMS <->サービスコントロールポイント/ Service Nodeプロトコル
_____ _______ _____
|[W3C]|----(p0)-->| [W3S] |<--(p0)----|[W3C]|
|[---]| | [WSA] | |[FS.]|
|-----| | ! | |[-!-]|
| (p1) | |--\--|
| ! | ^
| ! | (p6)
| ! | \
| (p1) | \
| ! | \
|[Srvlt]| \
|___!___| \
! \
(p3) \
Internet ! !
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.!.+.+.+.+.+.
PSTN/IN _______________!_________________ ____!_____ __________
|I [PktFlt] I| |[PktFlt]| |[PktFlt]|
|N Gateway N| | ! | | ! |
|A ___________________________ A| | ! | | ! |
|P | | P| | ! | |[SNMPAg]|
-(p4)-- |A | <-(p4)-> [SCP] <-(p4)-> | A|-(p5)->|[SR/IIP]| | [SMS] |
\ |d | [-^-] | d| |[------]| | [-^-] |
\ |__| ! |__| |________| |___!____|
\ ! !
[-v-] !-----------------(p9)-----------------!
[SSP]
[---]
___| |______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\
Figure 7: The Siemens Web Call Center
図7：シーメンスWebコールセンター
_____ _______
|[W3C]|----(p0)-->| [W3S] |
|[---]| | [WSA] |
|-----| | ! |
| (p1) |
| ! |
| ! |
| ! |
| (p1) |
| ! |
|[SSTPC]|-<----------------------------------
|___!___| !
! (p8)
(p3) !
Internet ! v
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+
PSTN/IN _______________!__________________________________ ____!_____
| [PktFlt] Service [PktFlt]| |[PktFlt]|
| ! Node | | ! |
| [SCF Adaptor] | | ! |
| ! | |[SNMPAg]|
|[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] |
|[|--] [-^-] [---] | | [-^-] |
|_|_____________!________________________________| |___!____|
| ! !
[-v-] (p7) !-----------------(p9)-----------------!
[CO.]____|
[---]
___| |_______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\
Figure 8: The Lucent System
図8：Lucentシステム
_____ ________
|[W3C]|----(p0)-->| [W3S] |
|[---]| | [WSA] |
|-----| | ! |
| (p1) |
| ! |
|[WS/CBS]|
|[Adaptr]|
|___!____|
^
(p2)
_____ ___v____
|[CBC]| | [CBS] |
|[---]|<---(p2)-->| [---] |-<---------------------------------
|-----| |___!____| !
! (p8)
(p3) !
Internet ! v
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+
PSTN/IN _______________!__________________________________ ____!_____
| [PktFlt] Service [PktFlt]| |[PktFlt]|
| ! Node | | ! |
| [SCF Adaptor] | | ! |
| ! | |[SNMPAg]|
|[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] |
|[|--] [-^-] [---] | | [-^-] |
|_|_____________!________________________________| |___!____|
| ! !
[---] (p7) !-----------------(p9)-----------------!
[CO.]____|
[---]
___| |_______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\
Figure 9: The AT&T System
図9：AT＆Tシステム
_____ ________
|[W3C]|----(p0)-->| [W3S] |
|[---]| | [WSA] |
|-----| | ! |
| (p1) |
| ! |
|[WS/ ]|
|[ SCTPS]|
|[Adaptr]|
|___!____|
^
(p2)
_______ ___v___
|[SCTPC]| |[SCTPS]|
|[-----]| <-(p2)--> |[-----]|-<----------------------------------
|-------| |___!___| !
! (p8)
(p3) !
Internet ! v
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+.
PSTN/IN _______________!__________________________________ ____!_____
| [PktFlt] Service [PktFlt]| |[PktFlt]|
| ! Node | | ! |
| [SCF Adaptor] | | ! |
| ! | |[SNMPAg]|
|[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] |
|[|--] [-^-] [---] | | [-^-] |
|_|_____________!________________________________| |___!____|
| ! !
[---] (p7) !-----------------(p9)-----------------!
[CO.]____|
[---]
___| |_______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\
Figure 10: The Nortel System
図10：Nortelシステム
As these are independent systems developed by different groups, the names of the components, unsurprisingly, don't match. Some features are offered by one of the systems, while they aren't by others. However, there are a number of common features. All of the systems provide a Web-based interface (at least as an option), using "back end" programs to construct protocols to pass onwards to the Intelligent Network system.
これらは異なるグループによって開発された独立したシステムであるため、当然のことながら、コンポーネントの名前は一致しません。一部の機能はシステムの1つによって提供されますが、他のシステムでは提供されません。ただし、多くの共通機能があります。すべてのシステムは、（少なくともオプションとして）Webベースのインターフェースを提供し、「バックエンド」プログラムを使用して、インテリジェントネットワークシステムに転送するプロトコルを構築します。
Several Intelligent Network Functional Entities are combined into a Service Node in the Lucent, AT&T , and Nortel systems, while in the Siemens scheme they are separate units. However, this is not particularly important for the provision of the services they offer.
いくつかのインテリジェントネットワーク機能エンティティは、Lucent、AT＆T、Nortelシステムのサービスノードに統合されていますが、Siemensスキームでは、それらは別個のユニットです。ただし、これは彼らが提供するサービスの提供にとっては特に重要ではありません。
The main difference lies in whether or not the SCF is "aware" of the Internet interface and has been modified to be "complicit" in supporting these Internet requests. The Siemens approach was to re-use an existing SCP, providing a gateway function to translate as needed. The Lucent system used a "lighter weight" SCF adapter to terminate the Internet protocols, as the SCF was modified to support the Internet interface directly.
主な違いは、SCFがインターネットインターフェイスを「認識」しているかどうか、およびこれらのインターネット要求をサポートする際に「複雑」になるように変更されているかどうかです。シーメンスのアプローチは、既存のSCPを再利用して、必要に応じて変換するゲートウェイ機能を提供することでした。 SCFがインターネットインターフェイスを直接サポートするように変更されたため、ルーセントシステムは「軽量」のSCFアダプタを使用してインターネットプロトコルを終了しました。
The AT&T CallBroker and Nortel SCTP Servers introduce an intermediate protocol (labeled p2) that allows an alternative to the Web based interface supported by the others. This protocol matches the "CallBroker Client API", or the "SCTP Client API". These options provide for a bi-directional protocol, with indications sent from the Call Broker or SCTP Server to the Client as needed. This is not easily possible using an HTTP-based scheme (and in the Siemens case, a dedicated Finger client/server pair was used to emulate such an interface)
AT＆T CallBrokerおよびNortel SCTP Serverは、他の人がサポートするWebベースのインターフェースの代替となる中間プロトコル（p2とラベル付け）を導入しています。このプロトコルは、「CallBrokerクライアントAPI」または「SCTPクライアントAPI」と一致します。これらのオプションは、必要に応じてCall BrokerまたはSCTPサーバーからクライアントに送信される指示とともに、双方向プロトコルを提供します。これは、HTTPベースのスキームを使用して簡単に行うことはできません（シーメンスの場合、専用のFingerクライアント/サーバーのペアを使用して、このようなインターフェースをエミュレートしました）。
The protocol between the Internet server and the Intelligent Network (labeled p3 in the above diagrams) differs in each of the systems. One of the main aims of future work will be to develop a common protocol that will support the services offered, so that the p3 interface will allow different implementations to inter-operate. In the Lucent, Siemens, and Nortel systems, this was an "internal" protocol, as it was carried between entities within the Service Node or Gateway.
インターネットサーバーとインテリジェントネットワーク（上の図でp3とラベル付けされている）間のプロトコルは、システムごとに異なります。将来の作業の主な目的の1つは、提供されるサービスをサポートする共通プロトコルを開発し、p3インターフェイスが異なる実装で相互運用できるようにすることです。 Lucent、Siemens、Nortelシステムでは、これは「内部」プロトコルであり、サービスノードまたはゲートウェイ内のエンティティ間で伝送されていました。
Other contrasts between the systems lie in the support for Internet access to Service Management, and access to the Internet by Special Resources. Internet Management access was most developed in the Lucent system, in which a Simple Network Management Protocol (SNMP) agent was provided to allow inter-operation with the SMS controlling the Service Node. In the Siemens scheme, the SMS had no direct Internet access; any management actions were carried out within the normal PSTN management activities. As for Internet access to special resources, this was only required by the Siemens system as part of its support for Call Center agent notification. Equivalent functionality would be provided in the AT&T and Nortel systems as mentioned above, and this would in turn be associated with event notifications being sent as part of their (p3) Internet/IN protocol. These differences reflect the different emphases in the products as they were developed; again, future work will have to ensure that common protocols can be used to support the chosen services fully.
システム間の他の対照は、サービス管理へのインターネットアクセスのサポートと、特別なリソースによるインターネットへのアクセスにあります。インターネット管理アクセスは、ルーセントシステムで最も開発されました。このシステムでは、サービスノードを制御するSMSとの相互運用を可能にするために、簡易ネットワーク管理プロトコル（SNMP）エージェントが提供されていました。シーメンスのスキームでは、SMSはインターネットに直接アクセスできませんでした。管理アクションは通常のPSTN管理アクティビティ内で実行されました。特別なリソースへのインターネットアクセスに関しては、これはコールセンターエージェント通知のサポートの一部としてSiemensシステムでのみ必要でした。上記のAT＆TおよびNortelシステムでは同等の機能が提供され、これは（p3）インターネット/ INプロトコルの一部として送信されるイベント通知に関連付けられます。これらの違いは、開発された製品のさまざまな強調を反映しています。繰り返しますが、今後の作業では、選択したサービスを完全にサポートするために共通のプロトコルを使用できるようにする必要があります。
Figure 11 depicts the overall interconnection architecture of the Lucent prototype in support of the four PINT services. The IN-based architecture utilizes the Service Node and Service Management System in addition to the Web server, which enables Web-based access to the PINT services. This section summarizes the roles of these elements (complemented by a click-to-dial-back service scenario), outlines the interfaces of Web Server-Service Node and Web Server-Service Management System (i.e., the interfaces A & B), and addresses the common security concerns.
図11は、4つのPINTサービスをサポートするLucentプロトタイプの全体的な相互接続アーキテクチャーを示しています。 INベースのアーキテクチャは、PINTサービスへのWebベースのアクセスを可能にするWebサーバーに加えて、サービスノードとサービス管理システムを利用します。このセクションでは、これらの要素の役割（クリックからダイヤルバックのサービスシナリオによって補完される）の概要を示し、WebサーバーサービスノードとWebサーバーサービス管理システムのインターフェイス（つまり、インターフェイスAとB）の概要を示します。一般的なセキュリティの問題に対処します。
5.1.1 Roles of the Web Server, Service Node, and Service Management System
5.1.1 Webサーバー、サービスノード、およびサービス管理システムの役割
Web Server
ウェブサーバー
The Web Server stores the profiles of content providers as well as pre-registered users. The content provider profile contains information such as content provider ID, telephone number, and fax number. In addition, the profile may also include service logic that specifies, for example, the telephone (or fax) number to be reached based on time of the day, day of the week, or geographical location of the user, and the conditions to accept the charge of the calls.
Webサーバーは、コンテンツプロバイダーのプロファイルと事前登録されたユーザーを保存します。コンテンツプロバイダープロファイルには、コンテンツプロバイダーID、電話番号、ファックス番号などの情報が含まれています。さらに、プロファイルには、たとえば、時刻、曜日、またはユーザーの地理的な場所、および受け入れる条件に基づいて到達する電話（またはFAX）番号を指定するサービスロジックも含まれます。通話料。
Similar to the content provider profile, the pre-registered user profile contains information such as user name, password, telephone number, and fax number. The last two pieces of information can also be linked to time of the day and day of the week so the user can be reached at the appropriate telephone (or fax) number accordingly.
コンテンツプロバイダープロファイルと同様に、事前登録されたユーザープロファイルには、ユーザー名、パスワード、電話番号、ファックス番号などの情報が含まれています。最後の2つの情報は、時刻と曜日にリンクすることもできるため、ユーザーは適切な電話（またはFAX）番号に適宜連絡できます。
Service Node
サービスノード
Situated in the PSTN, the SN, like the SCP, performs the service control function [1, 2, 3]. It executes service logic and instructs switches on how to complete a call. The SN also performs certain switching functions (like bridging of calls) as well as a set of specialized functions (like playing announcements, voice recognition and text-to-speech conversion).
PSTNにあるSNは、SCPと同様に、サービスコントロール機能を実行します[1、2、3]。サービスロジックを実行し、スイッチに呼び出しの完了方法を指示します。 SNは、特定のスイッチング機能（コールのブリッジングなど）と一連の特殊機能（アナウンスの再生、音声認識、テキストから音声への変換など）も実行します。
Service Management System
サービス管理システム
The SMS performs administration and management of service logic and customer-related data on the SN. It is responsible for the replication of content provider profiles and provision of these data on the SN. These functions are non-real time.
SMSは、SN上のサービスロジックと顧客関連データの管理を行います。コンテンツプロバイダープロファイルの複製とSNでのこれらのデータのプロビジョニングを担当します。これらの関数は非リアルタイムです。
Web Users
____________
O -------------------------- | Internet |-------------------
------------ |
|
|
---------------- -------------- ------------
| Service Node | D | Service | B |Web Server|
| (SN) |------------| Management |---------------| |
| | |System (SMS)| | |
| | A -------------- | |
| |-----------------------------------------| |
---------------- ------------
| |
| I | C
| |
----------- ---------
|Mobile | |Central|
|Switching| |Office |
| Center | ---------
----------- |
| |
| |
O O
Mobile Wireline PSTN Users Users
モバイル有線PSTNユーザーユーザー
Figure 11: Overall Interconnection Architecture of the Lucent System
図11：Lucentシステムの全体的な相互接続アーキテクチャ
A Web user, who has simultaneous access to the Web and telephone services (this can be achieved, for example, by having an ISDN connection), is browsing through a sales catalogue and deciding to speak to a sales representative.
Webサービスと電話サービスに同時にアクセスできるWebユーザー（これは、ISDN接続を使用することで実現できます）は、販売カタログを閲覧して、営業担当者と話すことを決定しています。
When the Web user clicks a button inviting a telephone call from the sales office, the Web Server sends a message to the SN over the A interface, thus crossing the Internet-to-PSTN boundary. By matching the information received from the Web Server with the content provider profile that had been previously loaded and activated by the SMS over the D interface, the SN recognizes the signal.
Webユーザーが営業所からの電話を招くボタンをクリックすると、WebサーバーはAインターフェイスを介してメッセージをSNに送信し、インターネットとPSTNの境界を越えます。 Webサーバーから受信した情報を、Dインターフェイスを介してSMSによって以前にロードおよびアクティブ化されたコンテンツプロバイダープロファイルと照合することにより、SNは信号を認識します。
At this point, the SN calls the Web user. The user answers the call, hears an announcement, e.g., "Please wait, while we are connecting you to the sale agent", and is waiting to be connected to the sale agent. Then the SN invokes service logic as indicated in the profile.
この時点で、SNはWebユーザーを呼び出します。ユーザーは通話に応答し、「販売代理店に接続しています。しばらくお待ちください」などのアナウンスが聞こえ、販売代理店への接続を待機しています。次に、SNはプロファイルに示されているサービスロジックを呼び出します。
The execution of this logic selects an appropriate sales agent to call based on the time of the day. It is 8 P.M. in New York where the Web user is located, and the New York sales office has closed. The San Francisco office, however, is still open, and so the SN makes a call to an agent in that office. Finally, the SN bridges the two calls and establishes a two-party call between the sales agent and the Web user.
このロジックの実行により、時刻に基づいて、呼び出す適切なセールスエージェントが選択されます。午後8時です。 Webユーザーがいるニューヨークにあり、ニューヨークの営業所は閉鎖されています。ただし、サンフランシスコのオフィスはまだ開いているため、SNはそのオフィスのエージェントに電話をかけます。最後に、SNは2つのコールをブリッジし、販売代理店とWebユーザー間の2者間のコールを確立します。
Lucent developed the Service Support Transfer Protocol (SSTP) for communications between the SN and Web Server. SSTP is of a request/response type running on top of a reliable transport layer, such as TCP. The Web Server sends a request to the SN to invoke a service and the SN responds with a message indicating either success or failure. Note that SSTP engages only the service control function [1, 2, 3] of the SN.
Lucentは、SNとWebサーバー間の通信用にService Support Transfer Protocol（SSTP）を開発しました。 SSTPは、TCPなどの信頼性の高いトランスポート層の上で実行される要求/応答タイプです。 WebサーバーはSNにサービスを呼び出す要求を送信し、SNは成功または失敗を示すメッセージで応答します。 SSTPはSNのサービス制御機能[1、2、3]のみを使用することに注意してください。
In this direction, three kinds of messages may be sent: the Transaction Initiator message, the Data Message, and the End of Data message.
この方向では、トランザクションイニシエーターメッセージ、データメッセージ、およびデータの終わりメッセージの3種類のメッセージが送信されます。
The latter two messages are needed if the service to be invoked involves data (such as the case in click-to-fax, click-to-fax-back and voice-access-to-content). This was so designed to handle the varying size of data and to ensure that the size of each stream is within the allowable size of the underlying transport packet data unit (imposed by some implementations of TCP/IP).
後者の2つのメッセージは、呼び出されるサービスにデータが含まれている場合に必要です（クリックからFAX、クリックからFAXへの返信、コンテンツへの音声アクセスなど）。これは、さまざまなサイズのデータを処理し、各ストリームのサイズが基になるトランスポートパケットデータユニット（TCP / IPの一部の実装によって課せられる）の許容サイズ内に収まるように設計されています。
a. Transaction Initiator
a. トランザクションイニシエーター
This message provides all the necessary information but data for invoking a service. It includes the following information elements:
このメッセージは、必要なすべての情報を提供しますが、サービスを呼び出すためのデータを提供します。次の情報要素が含まれます。
+ Transaction ID, which uniquely specifies a service request. The same transaction ID should be used for all the accompanying data-related messages, if the service request involves data. One way for generating unique transaction IDs is to concatenate the information: date, time, Web Server ID (uniquely assigned for each one connected to the SN), and transaction sequence number (a cyclic counter incremented for each service request).
+ サービスリクエストを一意に指定するトランザクションID。サービス要求にデータが含まれる場合、付随するすべてのデータ関連メッセージに同じトランザクションIDを使用する必要があります。一意のトランザクションIDを生成する1つの方法は、情報を連結することです。日付、時刻、WebサーバーID（SNに接続されているIDごとに一意に割り当てられます）、トランザクションシーケンス番号（サービスリクエストごとに増分される循環カウンター）。
+ Service ID, which specifies the service to be invoked. The service may be click-to-dial-back, click-to-fax, click-to-fax-back or voice-access-to-content.
+ 呼び出されるサービスを指定するサービスID。サービスには、クリックツーダイヤルバック、クリックツーファクス、クリックツーファクスバック、または音声アクセスツーコンテンツがあります。
+ Content Provider ID, which uniquely represents the content provider. This information is the key to accessing the content provider's service logic and data on the SN.
+ コンテンツプロバイダーを一意に表すコンテンツプロバイダーID。この情報は、コンテンツプロバイダーのサービスロジックとSN上のデータにアクセスするための鍵です。
+ Content Provider Directory Number, which is the telephone or fax number of the content provider to be called through the PSTN.
+ コンテンツプロバイダーの電話番号。これは、PSTNを通じて呼び出されるコンテンツプロバイダーの電話番号またはFAX番号です。
+ User Directory Number, which is the telephone or fax number of the user requesting the service.
+ サービスを要求するユーザーの電話番号またはFAX番号であるユーザーディレクトリ番号。
+ Billed Party, which specifies the party (either the user or content provider), to be billed.
+ 請求先となるパーティ（ユーザーまたはコンテンツプロバイダー）を指定する請求先パーティ。
In addition, optional parameters may be sent from the Web Server to the SN. For example, a retry parameter may be sent to specify the number of times the SN will attempt to complete a service request upon failure before the transport connection times out.
さらに、オプションのパラメーターをWebサーバーからSNに送信できます。たとえば、トランスポート接続がタイムアウトする前に、SNが障害時にサービス要求の完了を試行する回数を指定するために、再試行パラメータが送信される場合があります。
b. Data Message
b. データメッセージ
This message provides the (encapsulated) user data part of a service request. For example, in the case of click-to-fax-back such data are the content to be faxed to the user. Each message is composed of the transaction ID and a data segment. The transaction ID must be the same as that of the transaction initiator part first invoking the service.
このメッセージは、サービス要求の（カプセル化された）ユーザーデータ部分を提供します。たとえば、クリックしてファックスする場合、そのようなデータはユーザーにファックス送信されるコンテンツです。各メッセージは、トランザクションIDとデータセグメントで構成されます。トランザクションIDは、最初にサービスを呼び出すトランザクションイニシエーターパートのIDと同じである必要があります。
c. End of Data Message
c. データメッセージの終わり
This message contains the transaction ID and the end of data delimiter. The transaction ID is the same as that of the relevant transaction initiator message.
このメッセージには、トランザクションIDとデータ区切り文字の終わりが含まれています。トランザクションIDは、関連するトランザクション開始メッセージのIDと同じです。
The SN must respond to a service request from the Web Server. The response message consists of the information elements:
SNは、Webサーバーからのサービス要求に応答する必要があります。応答メッセージは、情報要素で構成されています。
transaction ID, service type, result, time, and error code.
トランザクションID、サービスタイプ、結果、時間、エラーコード。
+ Transaction ID, which is the same as that of the original service request.
+ 元のサービスリクエストのトランザクションIDと同じです。
+ Service Type, which is the same as that of the original service request.
+ サービスタイプ。元のサービスリクエストと同じです。
+ Result, which is either success or failure.
+ 結果。成功または失敗のいずれかです。
+ Time, which indicates the time of the day completing the request.
+ 時間。リクエストを完了した時刻を示します。
+ Error Code, which gives the reason for failure. Possible reasons for failure are content provider telephone (or fax) busy, content provider telephone (or fax) no answer, user telephone busy, user refusal to complete, user no answer, nuisance control limit reached, and content provider telephone (or fax) not in the SN database.
+ 失敗の理由を示すエラーコード。考えられる失敗の理由は、コンテンツプロバイダーの電話（またはFAX）がビジー、コンテンツプロバイダーの電話（またはFAX）が無応答、ユーザーの電話がビジー、ユーザーが応答を拒否、ユーザーが無応答、迷惑な管理制限に達した、およびコンテンツプロバイダーの電話（またはFAX）です。 SNデータベースにはありません。
For the click-to-fax and click-to-fax-back services, the Lucent system implemented only the case where the data to be sent as facsimile reside in the Web server. There are at least three messages that need to be sent from the Web server to the Service Node for these services.
クリックツーファクスおよびクリックツーファクスバックサービスの場合、ルーセントシステムは、ファクシミリとして送信されるデータがWebサーバーにある場合のみを実装しました。これらのサービスのために、Webサーバーからサービスノードに送信する必要があるメッセージが少なくとも3つあります。
The first message is the Transaction Initiator that identifies the service type as well as a unique Transaction ID. It also includes the sender/receiver fax number.
最初のメッセージは、サービスタイプと一意のトランザクションIDを識別するトランザクションイニシエーターです。また、送信者/受信者のFAX番号も含まれます。
The next is one or more messages of the data to be faxed. Each message carries the same unique Transaction ID as the above.
次は、ファックスされるデータの1つ以上のメッセージです。各メッセージには、上記と同じ一意のトランザクションIDが含まれます。
Last comes the end of message. It consists of the Transaction ID (again, the same as that of the messages preceding it) and the end of data delimiter.
最後はメッセージの終わりです。これは、トランザクションID（これも、その前のメッセージのIDと同じです）とデータ区切り文字の終わりで構成されます。
Upon receiving these messages, the Service Node, equipped with the special resource of a fax card, converts the data into the G3 format, calls the receiver fax, and sends back the result to the Web server immediately. Note that the receiver fax busy or no answer is interpreted as failure. Further, while the receiver fax answering the call is interpreted as success, it does not necessarily mean that the fax would go through successfully.
これらのメッセージを受信すると、ファックスカードの特別なリソースを備えたサービスノードがデータをG3形式に変換し、受信者のファックスを呼び出し、その結果をすぐにWebサーバーに送り返します。受信者のFAXがビジーであるか、応答がない場合は、失敗と解釈されることに注意してください。さらに、呼び出しに応答する受信者のFAXは成功と解釈されますが、必ずしもFAXが正常に処理されるとは限りません。
This interface is responsible for uploading the content provider profile from the Web Server to the SMS and for managing the information against any possible corruption. The SN verifies the Content Provider ID and the Content Provider Directory Number sent by the Web Server with the content provider profile pre-loaded from the SMS.
このインターフェイスは、WebサーバーからSMSへのコンテンツプロバイダープロファイルのアップロードと、起こりうる破損に対する情報の管理を担当します。 SNは、SMSからプリロードされたコンテンツプロバイダープロファイルを使用して、Webサーバーから送信されたコンテンツプロバイダーIDおよびコンテンツプロバイダーの電話番号を確認します。
The content provider profile was based on ASN.1 [4] structure and SNMP [5] was used to set/get the object identifiers in the SMS database.
コンテンツプロバイダープロファイルはASN.1 [4]構造に基づいており、SNMP [5]はSMSデータベース内のオブジェクト識別子の設定/取得に使用されました。
Following is an example of the simple MIB available on the SMS.
以下は、SMSで使用可能な単純なMIBの例です。
inwebContProviderTable OBJECT-TYPE
SYNTAX SEQUENCE OF InwebContProviderEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" A table containing Content Provider profiles "
:= { inweb 1}
inwebContProviderEntry OBJECT-TYPE
SYNTAX InwebContProviderEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" A conceptual row of the inweb. Each row
contains profile of one Content Provider"
INDEX { inwebSmsNumber }
:= { inwebContProviderTable 1 }
InwebContProviderEntry := SEQUENCE {
inwebSmsNumber Integer32,
inwebContentProviderId Integer32,
inwebContentProviderPhoneNumber Integer32,
inwebContentProviderFaxNumber Integer32
}
inwebSmsNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" Serial number of the SMS - used for SNMP indexing "
:= { inwebContProviderEntry 1 }
inwebContentProviderId OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" A number that uniquely identifies each Content
Provider "
:= { inwebContProviderEntry 2 }
inwebContentProviderPhoneNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" Content Provider's Phone Number "
:= { inwebContProviderEntry 3 }
inwebContentProviderFaxNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" Content Provider's Fax Number "
:= { inwebContProviderEntry 4 }
The Lucent prototype addressed the security issues concerning the interface between the Web Server and the SN. Those concerning the interface between the Web Server and SMS, which was based in SNMP, were handled by the built-in security features of SNMP.
Lucentプロトタイプは、WebサーバーとSN間のインターフェースに関するセキュリティ問題に対処しました。 SNMPに基づくWebサーバーとSMS間のインターフェースに関する問題は、SNMPの組み込みのセキュリティ機能によって処理されました。
+ Secure Communication Links
+ 安全な通信リンク
If the Network Operator (PSTN provider) is also the Web Service provider, the Web Server and SN/SMS will communicate over a corporate intranet. This network is almost always protected by the corporation's firewall and so can be deemed secure. This was the case handled by the Lucent prototype.
ネットワークオペレーター（PSTNプロバイダー）がWebサービスプロバイダーでもある場合、WebサーバーとSN / SMSは企業イントラネットを介して通信します。このネットワークはほとんどの場合、企業のファイアウォールによって保護されているため、安全であると見なすことができます。これは、Lucentプロトタイプによって処理されたケースです。
Nevertheless, if different corporations serve as the Network Operator and the Web Service Provider, then it is likely that there may not exist a dedicated secure communication link between the Web Server and SN/SMS. This raises serious security considerations. One possible solution is to use Virtual Private Networks (VPN). VPN features support authentication of the calling and called parties and encryption of the messages sent over insecure links (such as those on the Internet).
それでも、異なる企業がネットワークオペレーターとWebサービスプロバイダーの役割を果たす場合は、WebサーバーとSN / SMSの間に専用の安全な通信リンクが存在しない可能性があります。これにより、深刻なセキュリティ上の考慮事項が発生します。 1つの可能なソリューションは、仮想プライベートネットワーク（VPN）を使用することです。 VPN機能は、発信者と着信者の認証、および安全でないリンク（インターネット上のリンクなど）を介して送信されるメッセージの暗号化をサポートします。
+ Non-Repudiation
+ 否認防止
All transactions were logged on both the Web Server and the Service Node to account for all operations in case of doubt or dispute. The log information on the SN may also be used to generate bills.
すべてのトランザクションは、Webサーバーとサービスノードの両方に記録され、疑わしい場合や問題が発生した場合に備えて、すべての操作が考慮されます。 SNのログ情報は、請求書の生成にも使用できます。
+ Malicious Requests of Users
+ ユーザーの悪意のあるリクエスト
A user may make repeated requests to a content provider directory number maliciously. This scenario was handled by setting a Nuisance Control Limit (NCL) on either the SN or the Web Server or both. The NCL has two parameters: one defining the number of requests from a user and the other the period over which these requests takes place.
ユーザーは悪意を持ってコンテンツプロバイダーの電話番号に繰り返しリクエストを行う可能性があります。このシナリオは、SNまたはWebサーバー、あるいはその両方で迷惑管理制限（NCL）を設定することによって処理されました。 NCLには2つのパラメーターがあります。1つはユーザーからの要求の数を定義し、もう1つはこれらの要求が発生する期間です。
A user may also attempt to request a call from a directory number other than that of a content provider. This scenario was handled by verifying the directory number (and the content provider ID) against the database on the SN containing all the content provider information. If the directory number (or the content provider ID) was not in the database, the request would be rejected.
ユーザーは、コンテンツプロバイダーの電話番号以外の電話番号からの呼び出しを要求することもできます。このシナリオは、すべてのコンテンツプロバイダー情報を含むSN上のデータベースに対して電話番号（およびコンテンツプロバイダーID）を検証することによって処理されました。電話番号（またはコンテンツプロバイダーID）がデータベースになかった場合、要求は拒否されます。
The Web Call Center is an Intelligent Network System that accepts requests from Internet nodes for services to be provided on the PSTN. As the name suggests, it was designed to support a cluster of services that, taken together, provide a subset of the features of a Call Center, with almost all user interactions provided via World Wide Web requests and responses. See the appendix for a background description of Call Center Features.
Webコールセンターは、PSTNで提供されるサービスに対するインターネットノードからの要求を受け入れるインテリジェントネットワークシステムです。名前が示すように、このサービスは、コールセンターの機能のサブセットを提供するサービスのクラスターをサポートするように設計されており、ほとんどすべてのユーザーインタラクションがWorld Wide Web要求と応答を介して提供されます。コールセンター機能の背景説明については、付録を参照してください。
From an Intelligent Network perspective, there are a number of services that, when combined, provide the Call Center features. The Call Center features as implemented supported the scenario in which a customer makes a request to be called back by an agent at a time of the customer's choosing to discuss an item of interest to him or her. The agent will be selected based on his or her availability and expertise in this topic; the agent will be told whom he or she is calling and the topic of interest, and then the agent will be connected to the customer.
インテリジェントネットワークの観点から見ると、組み合わせるとコールセンター機能を提供する多くのサービスがあります。実装されたコールセンター機能は、顧客が関心のあるアイテムについて話し合うことを選択したときに、顧客がエージェントからのコールバックを要求するシナリオをサポートしました。エージェントは、彼または彼女の可用性とこのトピックの専門知識に基づいて選択されます。エージェントには、誰が電話をかけているか、関心のあるトピックが通知され、その後、エージェントは顧客につながります。
In addition, the individual services that were deployed to support this scenario provided support for management of the list of available agents as well. This involved allowing the agent to "log into" and "out of" the system and to indicate whether the agent was then ready to handle calls to the customer. The list of services, as seen from a user perspective, follows.
さらに、このシナリオをサポートするために展開された個々のサービスは、利用可能なエージェントのリストの管理もサポートしました。これには、エージェントがシステムに「ログイン」および「ログアウト」し、エージェントが顧客へのコールを処理する準備ができたかどうかを示すことができるようにすることが含まれます。ユーザーの観点から見たサービスのリストは次のとおりです。
The services support:
サービスは以下をサポートします：
i) Customer Request service - the customer explores a corporate Web site, selects a link that offers to request an agent to call the customer back and then is redirected to the Web Call Center server. This presents customer with a form asking for name, the telephone number at which he or she wishes to be called, and the time at which the call is to be made. Note will also be made of the page to which the customer was referred to when he or she was redirected. Once the form has been returned, the customer receives an acknowledgment page listing the parameters he or she has entered.
i）顧客要求サービス-顧客は企業のWebサイトを探索し、顧客に電話をかけるようにエージェントに要求することを提案するリンクを選択してから、Webコールセンターサーバーにリダイレクトされます。これにより、名前、電話を希望する電話番号、電話をかける時間を尋ねるフォームが顧客に提示されます。また、お客様がリダイレクトされたときに参照されたページも記録されます。フォームが返送されると、顧客は自分が入力したパラメーターをリストした確認ページを受け取ります。
ii) Agent Registration/Logon - An agent requests a "login" page on the Web Call Center server. The service checks whether it has a record of an agent present at the Internet node from which th call is made. If not, then the caller will be sent a form allowing him or her to enter the service identity, the company's agent identifier and password. On return, the service identity and company agent identifier will be checked against a list of known identities. If found, the password will be checked, and if this matches the record held by the service then a new session record is made of this identity and the Internet node from which the call has been made.
ii）エージェント登録/ログオン-エージェントがWebコールセンターサーバーの「ログイン」ページをリクエストします。サービスは、呼び出しが行われたインターネットノードにエージェントのレコードが存在するかどうかを確認します。そうでない場合、発信者には、サービスID、会社のエージェントID、およびパスワードを入力できるフォームが送信されます。戻ったとき、サービスIDと会社のエージェントIDが既知のIDのリストと照合されます。見つかった場合、パスワードがチェックされ、サービスによって保持されているレコードと一致する場合、このIDと、呼び出し元のインターネットノードから新しいセッションレコードが作成されます。
NB: This is very similar to the Universal Personal Telecommunications (UPT) service feature "register for incoming calls". It implies that the identified person has exclusive use of the Internet node from that point onwards, so messages for them can be directed there.
注意：これは、Universal Personal Telecommunications（UPT）サービスの機能である「着信の登録」と非常に似ています。それは、識別された人物がその時点からインターネットノードを独占的に使用していることを意味し、そのため、彼らへのメッセージをそこに送ることができます。
iii) Agent Ready - an agent who has already logged on can indicate that he or she is ready by requesting an appropriate "ready" page on the Web Call Center Server. The service will match the agent by the Internet node Identifier and Agent Identity passed along with the Web request against its list of "active" agents. It will mark them as being ready to handle calls in its list of available agents (with their pre-defined skill set).
iii）エージェント準備完了-すでにログオンしているエージェントは、Webコールセンターサーバーの適切な「準備完了」ページを要求することで、準備ができていることを示すことができます。サービスは、「アクティブな」エージェントのリストに対してWebリクエストと共に渡されたインターネットノード識別子とエージェントIDによってエージェントを照合します。利用可能なエージェントのリスト（事前に定義されたスキルセットを含む）で、コールを処理する準備ができていることをマークします。
iv) Agent Not Ready - an agent can request an appropriate "ready" page on the Web Call Center Server to indicate that he or she is temporarily not ready to handle calls.
iv）エージェントの準備ができていません-エージェントは、Webコールセンターサーバーの適切な「準備完了」ページをリクエストして、一時的に通話を処理する準備ができていないことを示すことができます。
v) Agent Logoff - an agent can request an appropriate "Logout" page on the Web Call Center Server to indicate that he or she is no longer associated with a particular Internet node. The service will match the agent by the Internet Node Identifier and Agent Identity passed along with the Web request against its list of "active" agents. Once found, the session record for that agent is removed and the caller is notified of this with an acknowledgment page.
v) エージェントのログオフ-エージェントは、Webコールセンターサーバーの適切な「ログアウト」ページをリクエストして、特定のインターネットノードに関連付けられていないことを示すことができます。サービスは、「アクティブな」エージェントのリストに対してWebリクエストと共に渡されたインターネットノード識別子とエージェントIDによってエージェントを照合します。見つかったら、そのエージェントのセッションレコードが削除され、発信者には確認ページでこのことが通知されます。
NB: This is very similar to the UPT "unregister" service feature.
注意：これは、UPTの「登録解除」サービス機能とよく似ています。
vi) Call Center Agent Selection and Notification - When the time that the customer selected has arrived and an available agent with the right skills has been selected from the appropriate list, this service will send a notification to the Internet node associated with that agent. A dedicated server is assumed to be running on the agent's machine that, on receiving the notification, triggers the agent's browser into requesting a "Agent Call In" page from the Web Call Center Server. Once the agent's machine has made this request, he or she will be told that there is a customer to call.
vi）コールセンターエージェントの選択と通知-顧客が選択した時間に到着し、適切なスキルを持つ対応可能なエージェントが適切なリストから選択されると、このサービスはそのエージェントに関連付けられたインターネットノードに通知を送信します。専用サーバーは、エージェントのマシンで実行されていると想定され、通知を受信すると、エージェントのブラウザーをトリガーして、Webコールセンターサーバーからの[エージェントの呼び出し]ページを要求します。エージェントのマシンがこの要求を行うと、電話をかける顧客がいることがエージェントに通知されます。
NB: This is similar to a "Message Waiting" or "Wake Up Call" service.
注意：これは、「メッセージ待機」または「ウェイクアップコール」サービスに似ています。
Note: As implemented, the agent is led automatically into the following service (the returned Web page includes an automatic reload command).
注：実装されると、エージェントは自動的に次のサービスに誘導されます（返されるWebページには自動再読み込みコマンドが含まれます）。
vii) Agent Instruction - a selected agent makes a request of the "Customer Processing" page on the Web Call Center Server. The Internet node Identifier and Agent Identity the agent uses will be matched against a list of agents expected to handle calls, and the instructions for the calls will be returned to the agent.
vii）エージェントの指示-選択したエージェントが、Webコールセンターサーバーの「顧客の処理」ページをリクエストします。エージェントが使用するインターネットノードIDとエージェントIDは、コールを処理することが予想されるエージェントのリストと照合され、コールの指示がエージェントに返されます。
NB: This is similar to a "Voice Mail Replay" message service, but in this case the message is automatically generated; there is no associated voice mail record feature accessible.
注意：これは「ボイスメールの再生」メッセージサービスに似ていますが、この場合、メッセージは自動的に生成されます。関連するボイスメールレコード機能にアクセスできません。
Note: As implemented, the instructions page will include a number of buttons, allowing the agent to view the page the customer was looking at when he or she made the request, and to trigger the customer callback (as described next).
注：実装されると、指示ページにはいくつかのボタンが含まれ、エージェントが顧客がリクエストを行ったときに見ていたページを表示し、顧客のコールバックをトリガーできます（次で説明します）。
ix) Agent/Customer Telephony Callback - the agent will make a request of a "dial-back" page on the Web Call Center Server. The Internet node Identifier and Agent Identity he or she uses will be matched against a list of agents expected to handle calls, and, when the appropriate records have been found, the service will make the telephone call through to the customer and then connect the agent to this telephone call (using the telephone number registered in the respective Call Center service record).
ix）エージェント/カスタマーテレフォニーコールバック-エージェントは、Webコールセンターサーバーの「ダイヤルバック」ページを要求します。彼または彼女が使用するインターネットノードIDとエージェントIDは、通話を処理することが予想されるエージェントのリストと照合され、適切なレコードが見つかると、サービスは顧客に電話をかけてエージェントを接続します。この電話の呼び出し（それぞれのコールセンターのサービスレコードに登録されている電話番号を使用）。
The Siemens Web Call Center used an existing IN system and service logic that supported Call Center features. The scenario it supports is very similar to the Siemens IN-based Call Center on which it was based; one of the goals was to minimize changes to the service offered. It is also virtually identical to the service "Internet Requested Telephony Dial-back" provided by the Lucent system.
シーメンスWebコールセンターは、コールセンター機能をサポートする既存のINシステムとサービスロジックを使用していました。それがサポートするシナリオは、そのベースとなったSiemens INベースのコールセンターと非常によく似ています。目標の1つは、提供されるサービスへの変更を最小限に抑えることでした。また、Lucentシステムによって提供されるサービス「Internet Requested Telephony Dial-back」と実質的に同じです。
As provided via the Internet, the services involved are mostly the same as those provided via the PSTN and IN alone. The main differences lie in the use of the World Wide Web as an interface to the services rather than a telephone, SSP, and Intelligent Peripheral. Also, the feature by which a telephone call is made between the agent and the customer is implemented within the IN system in a different way; this is the only element in which the PSTN is involved.
インターネットを介して提供されるように、関連するサービスは、PSTNおよびINのみを介して提供されるサービスとほとんど同じです。主な違いは、電話、SSP、インテリジェントペリフェラルではなく、サービスへのインターフェースとしてのワールドワイドウェブの使用にあります。また、エージェントと顧客の間で電話をかける機能は、INシステム内で別の方法で実装されます。これは、PSTNが関与する唯一の要素です。
The general arrangement for the Web Call Center system is shown in Figure 7. The components that were added to an existing IN system to deal with the Internet interface are described next.
Webコールセンターシステムの一般的な配置を図7に示します。次に、インターネットインターフェイスを処理するために既存のINシステムに追加されたコンポーネントについて説明します。
In addition to the SCP, SSP and SMS that were part of the original IN-based system, another unit was included to send notification messages to agents; in the IN system the agents were sent "wake up" telephone calls when they were required to handle their next customers' call back. This unit is called the "Internet Intelligent Peripheral", and its use is described later under "Non-World Wide Web Interactions".
元のINベースのシステムの一部であったSCP、SSP、およびSMSに加えて、エージェントに通知メッセージを送信するための別のユニットが含まれていました。 INシステムでは、エージェントは次の顧客のコールバックを処理する必要があるときに「ウェイクアップ」電話を送信されました。このユニットは「インターネットインテリジェントペリフェラル」と呼ばれ、その使用については「非ワールドワイドウェブインタラクション」で後述します。
As there was a need to re-use as many of the existing IN components unchanged, a Gateway unit to deal with the interface between the Internet and the SCP was provided. This injected INAP (Intelligent Network Application Protocol) messages into the SCP, making it think that it had received an Initial DP trigger from an SSP. It also intercepted the "Connect To Resource" and "Prompt and Collect" INAP messages sent from the SCP, acting on these to return the parameters generated by the Internet users when they filled in the forms that triggered the service transaction. It also translated the "Play Announcement" message sent to the Intelligent Peripheral into a form that it could use. Finally, it passed on the INAP message used by the SCP to trigger SSP into making the telephone call back.
既存のINコンポーネントの多くを変更せずに再利用する必要があったため、インターネットとSCP間のインターフェースを処理するゲートウェイユニットが提供されました。これにより、SCPにINAP（インテリジェントネットワークアプリケーションプロトコル）メッセージが挿入され、SSPから初期DPトリガーを受信したと考えられます。また、SCPから送信された「リソースへの接続」および「プロンプトと収集」のINAPメッセージをインターセプトし、サービストランザクションをトリガーするフォームに入力したときに、インターネットユーザーが生成したパラメーターを返すように動作しました。また、インテリジェントペリフェラルに送信された「Play Announcement」メッセージを、使用可能な形式に変換しました。最後に、SCPがSNAPをトリガーして電話をかけ直すために使用するINAPメッセージを渡しました。
In the IN/PSTN-based system, the services have contact with the customers and agents via their telephones, SSPs, and Intelligent Peripherals programmed to play announcements to them and to capture their responses. These responses are indicated by DTMF tones sent by pressing keys on the telephones.
IN / PSTNベースのシステムでは、サービスは、電話、SSP、およびアナウンスを再生して応答をキャプチャするようにプログラムされたインテリジェントペリフェラルを介して、顧客およびエージェントと連絡を取ります。これらの応答は、電話のキーを押すことによって送信されるDTMFトーンによって示されます。
In this case, almost all interactions are provided via World Wide Web requests and responses. The sequence of announcements and responses for each service are "collapsed" into individual form filling transactions, and the requests are not limited to digits (or "star" and "hash"). The implications of the use of forms on service operation are covered in more detail later (under HTTP/IN Service mapping).
この場合、ほとんどすべての対話は、World Wide Web要求と応答を介して提供されます。各サービスのアナウンスとレスポンスのシーケンスは、個々のフォーム入力トランザクションに「折りたたまれ」、リクエストは数字（または「スター」と「ハッシュ」）に限定されません。サービス操作でのフォームの使用の影響については、後で詳しく説明します（HTTP / INサービスマッピングの下）。
When provided via the IN/PSTN-based system, the services are passed the Calling Line Identity (CLI) of the caller and the number the caller dials (the DN). The CLI value is used extensively to identify the caller and (in the case of the agent) to index into service data tables to decide what to do next. While an equivalent value to the DN is passed to the Web-based transactions as the requested Universal Resource Locator (URL), the CLI cannot be given reliably. The nearest equivalent caller identifier is the IP Address of the customer or agent's machine. However, the use of HTTP proxies means that this "original" Internet node Address may not be available; if a proxy is used then its IP Address will be associated with the request.
IN / PSTNベースのシステムを介して提供される場合、サービスには発信者のCalling Line Identity（CLI）と発信者がダイヤルする番号（DN）が渡されます。 CLI値は、発信者を識別するため、および（エージェントの場合）サービスデータテーブルにインデックスを付けて次に何をするかを決定するために広く使用されます。 DNと同等の値が、要求されたUniversal Resource Locator（URL）としてWebベースのトランザクションに渡されますが、CLIを確実に提供することはできません。同等の最も近い発信者識別子は、顧客またはエージェントのマシンのIPアドレスです。ただし、HTTPプロキシを使用すると、この「元の」インターネットノードアドレスを使用できない場合があります。プロキシが使用されている場合、そのIPアドレスはリクエストに関連付けられます。
In providing these Call Center features the customer only has one Web-based transaction; that of providing the initial request for a PSTN telephone callback. To do so he or she will have to fill in a form so as to specify not only the time to be called back, but also the telephone number to be reached. These values can be used if needed to identify the customer, and so the problem of originating Internet Node ambiguity is not relevant.
これらのコールセンター機能を提供することで、顧客はWebベースのトランザクションを1つだけ持つことができます。 PSTN電話コールバックの最初のリクエストを提供すること。そのためには、電話をかける時間だけでなく、連絡先の電話番号も指定するように、フォームに記入する必要があります。これらの値は、必要に応じて顧客を識別するために使用できるため、インターネットノードのあいまいさの原因となる問題は関係ありません。
With the agents, however, there are sequences of coupled transactions, and the particular sequence must be identified. There will be a number of such transactions being carried out at once, and there needs to be some identifier to show which agent is being handled in each case.
ただし、エージェントの場合、トランザクションの結合のシーケンスがあり、特定のシーケンスを識別する必要があります。一度に実行されるそのようなトランザクションの数が多くなり、どの場合にどのエージェントが処理されているかを示すために何らかの識別子が必要になります。
Such an identifier is not part of a sequence of basic Web transactions. In a Web transaction, the HTTP Client/Web Browser makes a request, and the HTTP Server will respond to this, normally including some content in its reply message that will be processed by the browser, after which it closes the TCP connection. That's the end of the transaction; the HTTP client and server cannot normally maintain state information beyond this point. Any sequence is reduced to a set of unrelated transactions.
このような識別子は、一連の基本的なWebトランザクションの一部ではありません。 Webトランザクションでは、HTTPクライアント/ Webブラウザーが要求を行い、HTTPサーバーはこれに応答します。通常、ブラウザーによって処理される応答メッセージにコンテンツが含まれ、その後TCP接続を閉じます。これでトランザクションは終了です。 HTTPクライアントとサーバーは通常、この時点を超えて状態情報を維持できません。シーケンスは、一連の無関係なトランザクションに削減されます。
A result of this simple pattern is that any state information reflecting longer or more complex interactions must be stored (at least partially) in the client system. One approach is the use of cookies [6]. These can be set by HTTP servers as part of their response to a request, and will be sent back with all subsequent requests for appropriate URLs as extra HTTP headers. These cookies allow the HTTP server to identify the client in the following requests, so that it can continue an extended session with the client.
この単純なパターンの結果として、より長いまたはより複雑な対話を反映する状態情報は、クライアントシステムに（少なくとも部分的に）保存する必要があります。 1つのアプローチはCookieの使用です[6]。これらは、要求に対する応答の一部としてHTTPサーバーによって設定でき、追加のHTTPヘッダーとして適切なURLに対する後続のすべての要求とともに返送されます。これらのCookieにより、HTTPサーバーは次の要求でクライアントを識別できるため、クライアントとの拡張セッションを継続できます。
Cookies are used in providing the Internet Call Center. Persistent cookies are installed into the Web Browser on machines that are to be used by call center agents as a service management (pre-service) task. The cookie value is unique to the machine and is used to index into a list of machine IP addresses that is stored as part of the service data.
Cookieは、インターネットコールセンターの提供に使用されます。永続的なCookieは、コールセンターエージェントがサービス管理（プリサービス）タスクとして使用するマシンのWebブラウザにインストールされます。 Cookie値はマシンに固有であり、サービスデータの一部として保存されているマシンIPアドレスのリストにインデックスを付けるために使用されます。
Also, a session cookie is stored onto the agent's machine when the agent registers, and is cleared when he or she de-registers. This is used to identify the agent and so the IP address of the node with which the agent is associated (and from which the agent's subsequent requests should originate). The services that interact with Call Center agents use the agent session cookie value as an identifier; in principle this is unnecessary but it does simplify the session data lookup procedure. The rest of the services use the persistent machine identifier in place of the CLI, indexing into their service data using it. Both cookies are sent with each agent request; if they are not present, then the request is redirected to other services (for example to the agent Logon service).
また、セッションCookieは、エージェントの登録時にエージェントのマシンに保存され、エージェントの登録を解除するとクリアされます。これは、エージェントを識別するために使用されるため、エージェントが関連付けられている（およびエージェントの後続の要求の発信元である）ノードのIPアドレスです。コールセンターエージェントと対話するサービスは、エージェントセッションCookie値を識別子として使用します。原則としてこれは不要ですが、セッションデータのルックアップ手順を簡素化します。残りのサービスは、CLIの代わりに永続的なマシン識別子を使用し、それを使用してサービスデータにインデックスを付けます。両方のCookieは、エージェント要求ごとに送信されます。それらが存在しない場合、要求は他のサービス（エージェントのログオンサービスなど）にリダイレクトされます。
All of the client-initiated services require user interaction. With the IN/PSTN-based system, the majority of the services are typified by the callers being connected to an announcement unit that plays them a list of choices and captures their selection. The caller can pre-dial the digits needed; in this case the prompts are not needed and are not made.
クライアントが開始するサービスはすべて、ユーザーの操作が必要です。 IN / PSTNベースのシステムでは、サービスの大部分は、発信者が選択肢のリストを再生してその選択を取得するアナウンスメントユニットに接続されているという特徴があります。発信者は必要な数字を事前にダイヤルできます。この場合、プロンプトは不要であり、作成されません。
The pattern of operation is somewhat different in the Internet case, as the initial HTTP request returns a response, after which the Web transaction has ended. Where that initial response returns a form to be filled in by the caller, subsequently submitting the form initiates a new HTTP transaction. This is all part of one instance of service, however. The service consists of two request/response pairs in tandem.
最初のHTTPリクエストが応答を返し、その後Webトランザクションが終了するため、操作のパターンはインターネットの場合とは多少異なります。その初期応答が呼び出し元が入力するフォームを返す場合、その後フォームを送信すると、新しいHTTPトランザクションが開始されます。ただし、これはすべて1つのサービスインスタンスの一部です。このサービスは、2つのリクエスト/レスポンスのペアで構成されています。
Although it is possible to design a service to handle this pair of Web transactions as a single unit, it may be better to reconfigure it. The design of a service that deals with two Web exchanges as a single extended transaction is quite complex. It must maintain state across the pair of Web exchanges, and it has to handle a number of failure cases including dealing with time-outs and "out of time" submission of forms. The alternative is to split the service into two sub-features. The first of these reflects the initial request and delivery of the form by return, with the second one dealing with processing of the submitted form and returning any confirmation by reply.
このWebトランザクションのペアを1つの単位として処理するようにサービスを設計することは可能ですが、サービスを再構成することをお勧めします。 2つのWeb交換を1つの拡張トランザクションとして処理するサービスの設計は非常に複雑です。 Web交換のペア全体で状態を維持する必要があり、タイムアウトや "時間外"のフォーム送信の処理を含む多くの失敗のケースを処理する必要があります。別の方法は、サービスを2つのサブ機能に分割することです。これらの最初のリクエストは、フォームの最初のリクエストと返信による配信を反映し、2番目のリクエストは、送信されたフォームの処理と返信による確認の返信を処理します。
The services offered don't all require form-filling, and so can be treated as a single IN feature. There are two cases where forms are required. The first of these is the Customer Request service, while the other one is the "Agent Registration" service. In both cases the initial Web transaction (by which the form is requested and returned to the client) need not involve specific service logic processing; the initial delivery of the form to a customer or agent can be handled by a "normal" Web Server. In both cases the service logic is only triggered when the form is submitted; this means that, again, each of the services can be treated as a single IN feature.
提供されるサービスはすべてフォーム入力を必要としないため、単一のIN機能として扱うことができます。フォームが必要なケースは2つあります。 1つ目はカスタマーリクエストサービス、もう1つは「エージェント登録」サービスです。どちらの場合も、最初のWebトランザクション（フォームが要求されてクライアントに返される）には、特定のサービスロジック処理を含める必要はありません。顧客またはエージェントへのフォームの最初の配信は、「通常の」Webサーバーで処理できます。どちらの場合も、サービスロジックはフォームが送信されたときにのみトリガーされます。つまり、ここでも各サービスを1つのIN機能として扱うことができます。
The IN service logic that deals with these requests has a general pattern of action. An HTTP request is received, and this triggers the IN service logic into action. The service logic "sees" this as an Initial DP message and starts its processing as if it had been sent from an SSF. The SCF uses what appears to it to be an Intelligent Peripheral to collect the parameters of the request, and then to send back final announcements to the requesting entity.
これらの要求を処理するINサービスロジックには、一般的なアクションパターンがあります。 HTTPリクエストが受信され、これによりINサービスロジックが実行されます。サービスロジックは、これを初期DPメッセージとして「認識」し、SSFから送信されたかのように処理を開始します。 SCFは、インテリジェントペリフェラルのように見えるものを使用して、要求のパラメーターを収集し、最終的なアナウンスを要求エンティティに送り返します。
The main difference, from the perspective of the IN service logic running on the SCF, is that the service does not need to instruct the SSF to make a temporary connection to the Intelligent Peripheral. It is as if this connection had already been made. Similarly, there is no need to close the service transaction by sending an explicit "Continue Execution" message to the SSF.
SCFで実行されるINサービスロジックの観点からの主な違いは、サービスはSSFにインテリジェントペリフェラルへの一時的な接続を行うように指示する必要がないことです。この接続はすでに行われているようです。同様に、明示的な「実行継続」メッセージをSSFに送信して、サービストランザクションを閉じる必要はありません。
The sequence of "prompt/collect" instructions used to collect service parameters from a caller in an IN service maps quite well to a sequence of requests to extract a data value from the HTTP request, based on a tag. This is a fairly standard feature of Web Server CGI or Servlet processing. Using this mapping minimizes the changes to the service design, in that the service logic "sees" an Intelligent Peripheral to which it sends normal "Request Report Prompt & Collect" messages, and from which it receives data values in response.
INサービスの呼び出し元からサービスパラメータを収集するために使用される「プロンプト/収集」命令のシーケンスは、タグに基づいて、HTTPリクエストからデータ値を抽出するリクエストのシーケンスに非常によく対応します。これは、WebサーバーCGIまたはサーブレット処理のかなり標準的な機能です。このマッピングを使用すると、サービスロジックが通常の「リクエストレポートプロンプトと収集」メッセージを送信し、そこからデータ値を受信するインテリジェントペリフェラルを「認識」するため、サービス設計への変更が最小限に抑えられます。
All services have to fit in with the underlying HTTP interaction pattern, and so will be expected to send a final "Announce" instruction to the Intelligent Peripheral at the end of the service; this is done in many IN services anyway and in all of the service features described here. These announcements form the content returned to the Web Client.
すべてのサービスは、基礎となるHTTP対話パターンに適合している必要があるため、サービスの最後にインテリジェントペリフェラルに最終的な「アナウンス」命令を送信することが期待されます。とにかく、これは多くのINサービスで行われ、ここで説明するすべてのサービス機能で行われます。これらのアナウンスは、Webクライアントに返されるコンテンツを形成します。
There are two exceptions to the sole use of the World Wide Web for interaction. The first one occurs in the "Message Waiting"/"Wake Up Call" service by which the selected agent is informed of a callback request. World Wide Web transactions are very simple; the client browser makes a request for content associated with a particular HTTP URL, and the server sends a response, marking the end of the transaction. The server cannot make a spontaneous association with a client; it must be initiated by the client request.
インタラクションにWorld Wide Webを単独で使用する場合、2つの例外があります。 1つ目は、「メッセージ待機」/「ウェイクアップコール」サービスで発生し、選択したエージェントにコールバック要求が通知されます。 World Wide Webトランザクションは非常に単純です。クライアントブラウザーは特定のHTTP URLに関連付けられたコンテンツを要求し、サーバーは応答を送信して、トランザクションの終了をマークします。サーバーはクライアントと自発的に関連付けることはできません。クライアントの要求によって開始される必要があります。
While it would be possible for the server to defer closing an earlier transaction (by not sending back all of the content specified and leaving the TCP connection open) it was decided that an alternative scheme would be more convenient. The "wake up call" was arranged by an "Internet Intelligent Peripheral" sending a request to a daemon process running on the selected agent's machine, using the Finger protocol [7]. The daemon sent back a standard response, but in addition the Web Browser on the agent's machine was triggered into making a further HTTP request of the server. In this way the "Agent Instruction" transaction is started automatically, while still allowing it to use a normal HTTP request/response pattern.
サーバーが以前のトランザクションのクローズを延期することは可能ですが（指定されたすべてのコンテンツを返送せず、TCP接続を開いたままにすることにより）、別のスキームの方が便利だと判断しました。 「ウェイクアップコール」は、Fingerプロトコルを使用して、選択したエージェントのマシンで実行されているデーモンプロセスにリクエストを送信する「インターネットインテリジェントペリフェラル」によって調整されました[7]。デーモンは標準の応答を返しましたが、さらにエージェントのマシンのWebブラウザーがトリガーされ、サーバーのHTTP要求がさらに行われました。このようにして、「エージェント命令」トランザクションは自動的に開始されますが、通常のHTTP要求/応答パターンを使用できます。
The second exception occurs in the final "Agent/Customer Telephony Callback" service. While this transaction is initiated by the agent selecting a link on the "call instructions page" returned to them, and includes a "confirmation" page being sent back to them in an HTTP response, the purpose of this service is to make a telephone connection via the PSTN between the agent's telephone and the customer's telephone. It is the only service element that involves the PSTN directly. From an IN/PSTN perspective, the resulting telephone connection is different from that provided in the scheme using the IN and PSTN alone. In this case, a PSTN call is made out to the agent's telephone, another call is made out to the customer's telephone, and these calls are bridged. This differs from the earlier scheme, in which the agent originated a call to the voice mail replay system, and this call was redirected to a new destination (the customer's telephone). As this feature differs in purpose from the other services, and it requires a different implementation within the IN and PSTN system, it was organized as a separate service in this case.
2番目の例外は、最後の「エージェント/カスタマーテレフォニーコールバック」サービスで発生します。このトランザクションは、エージェントに返された「通話手順ページ」でリンクを選択することによって開始され、「確認」ページがHTTP応答で送信されますが、このサービスの目的は電話接続を確立することですエージェントの電話と顧客の電話の間のPSTNを介して。これは、PSTNを直接含む唯一のサービス要素です。 IN / PSTNの観点からは、結果として生じる電話接続は、INおよびPSTNのみを使用するスキームで提供されるものとは異なります。この場合、PSTNコールがエージェントの電話に発信され、別のコールが顧客の電話に発信され、これらのコールがブリッジされます。これは、エージェントがボイスメール再生システムへのコールを発信し、このコールが新しい宛先（顧客の電話）にリダイレクトされるという以前の方式とは異なります。この機能は他のサービスと目的が異なり、INおよびPSTNシステム内で異なる実装が必要であるため、この場合は別のサービスとして編成されました。
In the case of this system, assumptions were made that the interface presented to requesting agents and customers was provided via a fire wall to deal with most attacks on the IN components. The interface appeared as a Web Server, and there was no direct access to the HTTP documents served, nor to the servlets providing the service logic.
このシステムの場合、INコンポーネントへのほとんどの攻撃に対処するために、要求側のエージェントと顧客に提示されるインターフェースがファイアウォールを介して提供されるという想定が行われました。インターフェースはWebサーバーのように見え、提供されるHTTPドキュメントや、サービスロジックを提供するサーブレットへの直接アクセスはありませんでした。
The Callback service was deemed to have simpler security requirements than other IN services as it was akin to a free phone "1-800" service access number; the agents work for the service subscriber and are not charged directly. Similarly, the requesting customer is not charged for his or her request, nor for the resulting call back. Service subscribers would be willing to pay the costs of telephone calls generated as a result of this cluster of services, and the costs of running the agent services could be charged directly to them. As such the authorization for service is defined by the contract between the service subscriber and the service provider.
コールバックサービスは、無料の電話「1-800」サービスアクセス番号に似ているため、他のINサービスよりもセキュリティ要件が単純であると見なされていました。エージェントはサービスサブスクライバーのために働き、直接請求されません。同様に、要求している顧客は、彼または彼女の要求に対しても、結果として生じるコールバックに対しても請求されません。サービスの加入者は、このサービスのクラスターの結果として生成された電話の費用を喜んで支払うことになり、エージェントサービスの実行の費用はそれらに直接請求される可能性があります。したがって、サービスの承認は、サービスサブスクライバーとサービスプロバイダーの間の契約によって定義されます。
Authentication of agents was seen as a problem. As an interim measure, cookies were used, but this scheme delivers the cookie data as a plain text item (a header of the Web request). Secure Socket Layer connections were required for communication with the agent services, and this had an impact on the performance of the IN system.
エージェントの認証が問題と見なされました。暫定的な対策として、Cookieが使用されましたが、このスキームはCookieデータをプレーンテキストアイテム（Webリクエストのヘッダー）として配信します。エージェントサービスとの通信にはSecure Socket Layer接続が必要であり、これがINシステムのパフォーマンスに影響を与えていました。
Security is seen as a major issue. A firewall was used to control access to the IN Components. Similarly, SSL was used for communication with the Agents, so as to protect the cookie values that they were sending with their requests.
セキュリティは大きな問題と見なされています。 INコンポーネントへのアクセスを制御するためにファイアウォールが使用されました。同様に、SSLはエージェントとの通信に使用され、エージェントが要求とともに送信していたCookie値を保護しました。
For other services, it is likely that the entity from which requests appear to originate will be charged for the service to be rendered. This has implications in terms of authentication and authorization of service provision at the time of the request. It is necessary for the service to be authorized in such a way that non-repudiation is ensured; this is likely to mean that a certificate of identity be provided from the person making the request, and that this can be tied in with a financial account that that person has with the service provider. The certificate can then be stored as part of the billing record. While the process of electronic commerce is outside of the scope of this work, the mechanism by which a request for confirmation of identity is passed out to the requesting user and is delivered back to the service logic must be considered.
他のサービスの場合、リクエストの発信元と思われるエンティティが、サービスの提供に対して課金される可能性があります。これは、リクエスト時のサービス提供の認証と承認に影響を与えます。サービスは、否認防止が保証されるような方法で承認される必要があります。これは、IDの証明書が要求を行った人から提供され、その人がサービスプロバイダーと持っている金融アカウントに関連付けられることを意味する可能性があります。その後、証明書を請求レコードの一部として保存できます。電子商取引のプロセスはこの作業の範囲外ですが、IDの確認要求が要求元ユーザーに渡され、サービスロジックに返送されるメカニズムを考慮する必要があります。
When changing from a "pure" IN/PSTN system to one supporting requests via the Internet, the differences in the way that clients interacted with the services meant that the service logic had to be redesigned. It was realized that maintaining the state of a service during its processing was going to be a problem; this problem was side-stepped by re-engineering the services as form processors, allowing them to deal with fully specified requests as a single (Web) transaction. In addition, a "normal" Web Server was used to deliver the forms to the users. This is a change from the IN system, where the equivalent of the form (the prompts) were sent in sequence as part of the same service process.
「純粋な」IN / PSTNシステムからインターネット経由のサポートリクエストシステムに変更する場合、クライアントがサービスと対話する方法が異なるため、サービスロジックを再設計する必要がありました。処理中にサービスの状態を維持することが問題になることがわかった。この問題は、サービスをフォームプロセッサとして再設計し、完全に指定されたリクエストを単一の（Web）トランザクションとして処理できるようにすることで回避されました。さらに、フォームをユーザーに配信するために「通常の」Webサーバーが使用されました。これは、同じサービスプロセスの一部としてフォーム（プロンプト）に相当するものが順番に送信されたINシステムからの変更点です。
The Call Center features provided suited this change. However, this may not be the case for other IN services. It is quite common for services to be designed such that the user is prompted for a response, and the service continues dependent on this response. The Web form presents all of the options at once, so this kind of variant prompt/collect sequence is not possible. From this, it is difficult to see how an IN service could be reused without some degree of modification.
提供されたコールセンター機能は、この変更に適しています。ただし、これは他のINサービスには当てはまらない場合があります。ユーザーが応答を求められ、サービスがこの応答に依存し続けるようにサービスを設計することは非常に一般的です。 Webフォームはすべてのオプションを一度に表示するため、この種のバリアントプロンプト/収集シーケンスは不可能です。このことから、ある程度の変更を加えずにINサービスを再利用する方法を理解することは困難です。
An intermediate "gateway" system was provided to "cocoon" the service logic as far as possible from the details of the components with which it was working. Where needed, this unit translated calls from the service logic into commands that operated with the Internet (and the Web Server that acted as the interface). Our experience was that an SCP could be "spoofed" into thinking that it was operating with other IN components in the normal way. Within the limits of the service used, this proved simpler than was originally expected.
中間の「ゲートウェイ」システムが提供され、サービスロジックが機能していたコンポーネントの詳細から可能な限りサービスロジックを「繭」化しました。このユニットは、必要に応じて、サービスロジックからの呼び出しを、インターネット（およびインターフェイスとして機能するWebサーバー）で動作するコマンドに変換しました。私たちの経験では、SCPは通常の方法で他のINコンポーネントと共に動作していると考えるように「なりすまし」される可能性があります。使用されるサービスの制限内で、これは当初予想されていたよりも簡単であることがわかりました。
Selecting this simple approach still allows a considerable range of services to be provided while maintaining any investment in existing IN systems. Modification of existing IN service logic was also easier than feared. All of the services examined provided announcements at the end of the service transaction, and this could be used to trigger a Web response to be sent back to the requesting Internet user. The changes to the Call Center service logic turned out to be minor; it took as long to analyze the service and see how it could be arranged as a sequence of "form processing" transactions as it did to make the changes to the service logic.
この単純なアプローチを選択しても、既存のINシステムへの投資を維持しながら、かなりの範囲のサービスを提供できます。既存のINサービスロジックの変更も、恐れられていたよりも簡単でした。調査されたすべてのサービスは、サービストランザクションの最後に提供されたアナウンスを提供し、これを使用して、要求しているインターネットユーザーにWeb応答を送り返すことができます。コールセンターサービスロジックへの変更は、小さなものであることが判明しました。サービスロジックを変更するのと同じように、サービスを分析して「フォーム処理」トランザクションのシーケンスとしてどのように配置できるかを確認するのに長い時間がかかりました。
In the Siemens Web Call Center, the "Internet Intelligent Peripheral" with which the service logic communicated was running as a separate program on the same node. Where more complex behavior is required of it (such as conversion of text to speech data and interface with the PSTN) then it would almost certainly be on a separate node. If data is transferred from the Internet in such a scheme, any intermediate gateway would be involved in relaying the data to this node.
シーメンスWebコールセンターでは、サービスロジックが通信する「インターネットインテリジェントペリフェラル」が、同じノード上で個別のプログラムとして実行されていました。より複雑な動作が必要な場合（テキストから音声データへの変換やPSTNとのインターフェイスなど）、ほぼ確実に別のノードに存在します。このようなスキームでインターネットからデータが転送される場合、中間ゲートウェイはこのノードへのデータの中継に関与します。
AT&T developed a framework for controlling voice and voice-band data (e.g., fax) and for providing PINT services. Key to the framework is CallBroker, a logical entity that acts on behalf of a user to set up sessions and make requests for PSTN resources. The sessions typically include initiation of calls between two or more end points specified by the user. In addition to its interactions with the PSTN for call setup, the CallBroker is responsible for other functions, when necessary, such as authentication and usage recording.
AT＆Tは、音声および音声帯域データ（FAXなど）を制御し、PINTサービスを提供するためのフレームワークを開発しました。フレームワークの鍵はCallBrokerです。CallBrokerは、ユーザーに代わってセッションをセットアップし、PSTNリソースを要求する論理エンティティです。セッションには通常、ユーザーが指定した2つ以上のエンドポイント間の通話の開始が含まれます。コールセットアップのためのPSTNとの相互作用に加えて、CallBrokerは、必要に応じて、認証や使用状況の記録などの他の機能を担当します。
This section briefly discusses the protocol at the two interfaces that need to be defined and the corresponding APIs to provide the above services. The two interfaces are (1) the one between the CallBroker (or Web Server) and the Service Control Function in the Service Node in the PSTN and (2) the one between the IP client and the CallBroker. The latter interface, in particular, will enable service providers to extend the architecture defined here to serve as a platform for other advanced/value-added services (to be identified later). In addition, the view taken here is that the IP client is more general, and implements a protocol for communication with the CallBroker that allows full two-way communications. For example, this is required for the cases where a called party hangs up and an indication may be necessary to be given to the IP Client about this status/progress. This is also necessary when conferencing to give an indication/status of various parties joining the call.
このセクションでは、定義する必要がある2つのインターフェースのプロトコルと、上記のサービスを提供するための対応するAPIについて簡単に説明します。 2つのインターフェースは、（1）CallBroker（またはWebサーバー）とPSTNのサービスノードのサービスコントロール機能の間のインターフェース、および（2）IPクライアントとCallBrokerの間のインターフェースです。特に後者のインターフェイスにより、サービスプロバイダーは、ここで定義されたアーキテクチャを拡張して、他の高度なサービスや付加価値サービス（後で特定）のプラットフォームとして機能させることができます。さらに、ここでの見方は、IPクライアントがより一般的であり、完全な双方向通信を可能にするCallBrokerとの通信用のプロトコルを実装しているというものです。たとえば、これは、着信側が電話を切り、IPクライアントにこのステータス/進行状況を示す必要がある場合に必要です。これは、会議に参加するときに、通話に参加しているさまざまな関係者の指示/ステータスを提供するためにも必要です。
A high level architecture depicting various logical entities and the Interfaces among these logical Entities and the IP Client is shown in Figure 12.
図12に、さまざまな論理エンティティと、これらの論理エンティティとIPクライアント間のインターフェースを表す高レベルのアーキテクチャを示します。
________________
/
1 _____ / 2 _____
/|________________| |________| | PSTN
|____| \ |____|
Call \ / SCF\
Broker \ / SN \
\_____________
/ \
/ \
/ \
__ __
/\ /\
Calling Participant Party (Called Party)
Calling Participant Party（被呼者）
Figure 12: The CallBroker Architecture
図12：CallBrokerアーキテクチャ
The CallBroker, in addition to the initiation and control of calls on behalf of the user, performs additional functions. These functions include authenticating the IP Client, usage recording, and management of the session for the IP Client for the telephony call. The notion of the session requires that a client state machine be maintained in the CallBroker. This also helps in notifying the IP Client about the status/progress of the requests generated from the IP Client.
CallBrokerは、ユーザーに代わって呼び出しを開始および制御することに加えて、追加の機能を実行します。これらの機能には、IPクライアントの認証、使用状況の記録、テレフォニーコール用のIPクライアントのセッションの管理が含まれます。セッションの概念では、クライアントステートマシンがCallBrokerで維持される必要があります。これは、IPクライアントから生成されたリクエストのステータス/進行状況をIPクライアントに通知するのにも役立ちます。
From the perspective of the IP Client, the logical entities needed for the above functions are within the CallBroker and are as shown in Figure 13 below. These correspond to the functions already discussed: Usage Recording Function, Session Management Function, Voice Bridge, and the Authentication Function. The fact that some of these functions may be physically separate from the CallBroker (such as the Voice Bridge being in the PSTN) is not inconsistent with the general view adopted here. Thus, the CallBroker Model mediates requests for network services and enables us to define various value added services in the future.
IPクライアントの観点から見ると、上記の機能に必要な論理エンティティはCallBroker内にあり、以下の図13に示すとおりです。これらは、すでに説明した機能（使用記録機能、セッション管理機能、ボイスブリッジ、認証機能）に対応しています。これらの機能の一部がCallBrokerから物理的に分離されている可能性があるという事実（PSTNにあるボイスブリッジなど）は、ここで採用されている一般的なビューと矛盾していません。したがって、CallBrokerモデルはネットワークサービスの要求を仲介し、将来的にさまざまな付加価値サービスを定義できるようにします。
llllllllllllllll
l l
l Call Broker l Authentication
l Server l Function
l ______ l Interface 2a ______
l | |x x xlx x x x x x x x x | |
l |______|x l |____|
l x x l
l x xl Interface 2b
lSession State lx
l Mnmgt. x l x Usage Recording
l Function l x Function
l _______ x l x ______
l | | l x x x | |
l |_____| xl |____|
llllllllllllllll
x
x Interface 2c
x
_______
| |
|_____|
Bridge
ブリッジ
Figure 13: Functional Entities in the Call Broker
図13：コールブローカーの機能エンティティ
Various interfaces (i.e., 2a, 2b, 2c in Figure 13) between different functional entities in the CallBroker may also be standardized. The Session State Management Function may be physically realized as part of the CallBroker Server.
CallBrokerの異なる機能エンティティ間のさまざまなインターフェース（つまり、図13の2a、2b、2c）も標準化できます。セッション状態管理機能は、物理的にCallBrokerサーバーの一部として実現できます。
Communication on the IP Client to CallBroker Interface (Interface 1 in Figure 12) is a simple ASCII based protocol running directly on TCP. The messages on this interface are primarily requests from the client to the CallBroker, responses from the CallBroker to the IP client responding to the requests and unsolicited events from the CallBroker to the IP client. Since the communication is not strictly transaction oriented, traditional encapsulation protocols like HTTP cannot be used. There has been some ongoing work attempting to use multiple concurrent HTTP POST requests to support event delivery but, without too much difficulty, the ASCII protocol specified here can easily be mapped to the POST payload of the HTTP protocol.
IPクライアントからCallBrokerインターフェイスへの通信（図12のインターフェイス1）は、TCP上で直接実行される単純なASCIIベースのプロトコルです。このインターフェイスのメッセージは、主にクライアントからCallBrokerへの要求、CallBrokerからIPクライアントへの応答、および要求に応答するCallBrokerからIPクライアントへの非請求イベントです。通信は厳密にトランザクション指向ではないため、HTTPなどの従来のカプセル化プロトコルは使用できません。複数の同時HTTP POST要求を使用してイベント配信をサポートしようとするいくつかの作業が進行中ですが、それほど困難なく、ここで指定されたASCIIプロトコルはHTTPプロトコルのPOSTペイロードに簡単にマップできます。
Basic Format
基本フォーマット
The basic format of the protocol is as follows:
プロトコルの基本的な形式は次のとおりです。
[header]<<LF>
<<LF>
[body]<<LF>
<<LF>
<<LF>
The header and body of the protocol are separated by 2 line feed characters. The format of the header and the body is described below. Line feed characters in the header or body will be escaped using simple URL encoding.
プロトコルのヘッダーと本文は、2つの改行文字で区切られています。ヘッダーと本文の形式を以下に示します。ヘッダーまたは本文の改行文字は、単純なURLエンコーディングを使用してエスケープされます。
Header
ヘッダ
[session-id | 0]<<LF>
[message-id]<<LF>
[version-info]<<LF>
All CallBroker transactions are identified by sessions. A session does not necessarily correspond one-to-one to a TCP session. If the IP client is attempting to initiate a new session with the CallBroker the session-id field is populated with '0' to indicate session creation request. Every session request needs to be accompanied by sufficient information regarding authentication for the CallBroker to create the session.
すべてのCallBrokerトランザクションはセッションによって識別されます。セッションは、必ずしもTCPセッションに1対1で対応するわけではありません。 IPクライアントがCallBrokerを使用して新しいセッションを開始しようとしている場合、session-idフィールドには「0」が入力され、セッション作成要求を示します。すべてのセッション要求には、CallBrokerがセッションを作成するための認証に関する十分な情報が必要です。
Message-id represents the operation of the message.
Message-idは、メッセージの操作を表します。
Version-info contains optional version information of the protocol. This is to aid possible version mismatch detection and graceful error recovery.
バージョン情報には、プロトコルのオプションのバージョン情報が含まれています。これは、バージョンの不一致の検出と適切なエラー回復を支援するためです。
Body
体
The body of the protocol messages consists of name value pairs. These name-value pairs are interpreted with reference to the message-id which signifies the operation to be performed by the CallBroker.
プロトコルメッセージの本文は、名前と値のペアで構成されます。これらの名前と値のペアは、CallBrokerによって実行される操作を示すメッセージIDを参照して解釈されます。
The APIs of the CallBroker exposed to the IP client are distinct and different from the APIs that the CallBroker uses from the different supporting subsystems including the authentication subsystem and the usage recording subsystem. The IP client APIs enable clients to effectively control voice conferencing.
IPクライアントに公開されたCallBrokerのAPIは、CallBrokerが認証サブシステムや使用状況記録サブシステムを含むさまざまなサポートサブシステムから使用するAPIとは異なり、異なります。 IPクライアントAPIにより、クライアントは音声会議を効果的に制御できます。
The Voice Bridge Control API is used by CallBroker applications to access voice bridging functionality. The API distinguishes between sessions and calls. Calls represent actual voice calls placed from/to the voice bridge. These calls can be grouped together in sessions. All the calls that belong to a session are bridged. Calls have a significance outside the scope of sessions. Every call can be associated with multiple sessions with different weights at the same time. The advantage of this approach is the ability to support concepts like whispering in a conference call. Calls can also be dropped from a conference session and bridged together in a new session to give the notion of a sub-conference. These calls can later be re-added to the main conference session.
Voice Bridge Control APIは、CallBrokerアプリケーションが音声ブリッジ機能にアクセスするために使用されます。 APIはセッションと呼び出しを区別します。コールは、音声ブリッジとの間で行われた実際の音声コールを表します。これらの呼び出しは、セッションでグループ化できます。セッションに属するすべての呼び出しがブリッジされます。呼び出しには、セッションの範囲外の意味があります。すべてのコールは、重みが異なる複数のセッションに同時に関連付けることができます。このアプローチの利点は、電話会議でのささやきなどの概念をサポートできることです。会議セッションからコールをドロップし、新しいセッションでブリッジして、サブ会議の概念を提供することもできます。これらの通話は、後でメインの会議セッションに再度追加できます。
The Simple Computer Telephony Protocol (SCTP) is a third party call control protocol and as such does not comply with the PINT charter. SCTP is described in this section to show how PINT services could be implemented using SCTP, and where SCTP fits into the PINT architecture.
Simple Computer Telephony Protocol（SCTP）はサードパーティの呼制御プロトコルであり、PINT憲章に準拠していません。このセクションではSCTPについて説明し、SCTPを使用してPINTサービスを実装する方法と、SCTPがPINTアーキテクチャに適合する場所を示します。
In addition to third party call control, SCTP also provides subscriber (i.e., user) feature management (e.g., allows a user to set do not disturb, call forwarding parameters), and subscriber monitoring of terminal, line and address status. SCTP is strictly client/server-based. It has no provisions for peer to peer communications. SCTP runs as a TCP application protocol. It is ASCII-based and uses sockets. The SCTP Server is usually connected to a switch via a CTI (Computer-Telephony Integration) connection. Because of this, feature interactions are limited to those within the context of a single call, and not between PSTN services. The SCTP Server within a PINT Gateway could also be connected to an SN, or an SCP. See figures below. SCTP does NOT carry media.
サードパーティの呼制御に加えて、SCTPはサブスクライバー（つまり、ユーザー）の機能管理（たとえば、ユーザーがサイレントモード、着信転送パラメーターを設定できるようにする）、および端末、回線、アドレスのステータスのサブスクライバーモニタリングも提供します。 SCTPは厳密にクライアント/サーバーベースです。ピアツーピア通信の規定はありません。 SCTPはTCPアプリケーションプロトコルとして実行されます。これはASCIIベースで、ソケットを使用します。 SCTPサーバーは通常、CTI（Computer-Telephony Integration）接続を介してスイッチに接続されます。このため、機能の相互作用は、PSTNサービス間ではなく、単一のコールのコンテキスト内での相互作用に限定されます。 PINTゲートウェイ内のSCTPサーバーは、SNまたはSCPにも接続できます。下の図を参照してください。 SCTPはメディアを伝送しません。
SCTP Client as Part of a Web Server
Webサーバーの一部としてのSCTPクライアント
+------+ +--------+ +--------+ +------+
| | | | SCTP | | | |
| |----| |-------| |----| |
| | | | | | | |
+------+ +--------+ +--------+ +------+
User's PC Web Server/ PINT Gateway SN/SCP/Switch
CGI
Figure 14: SCTP Client as Part of a Web Server
図14：Webサーバーの一部としてのSCTPクライアント
In this architecture, the SCTP Client is embedded in the Web Server. It is there for the specific purpose of initiating calls to the PSTN based on user requests. The SCTP Server is within the PINT Gateway. We go through the classic PINT examples:
このアーキテクチャでは、SCTPクライアントはWebサーバーに組み込まれています。これは、ユーザーの要求に基づいてPSTNへの呼び出しを開始するという特定の目的のためにあります。 SCTPサーバーはPINTゲートウェイ内にあります。従来のPINTの例を見てみましょう。
Click-to-dial-back: The SCTP Client issues an SCTP MakeCall to the SCTP Server with the calling number supplied by Web page, and called number supplied by the user.
Click-to-dial-back：SCTPクライアントは、Webページから提供された発番号とユーザーから提供された着番号を使用して、SCTPサーバーにSCTP MakeCallを発行します。
Click-to-fax-back: SCTP Client issues an SCTP MakeCall to the SCTP Server with called number set to user's fax machine, and calling number set to Web Server's fax machine, and treatment set to the URI for the file to be faxed. The SCTP Server takes the file and feeds it into the call just as a fax machine would.
Click-to-fax-back：SCTPクライアントは、SCTPサーバーにSCTP MakeCallを発行し、着信番号をユーザーのファックスマシンに設定し、発信番号をWebサーバーのファックスマシンに設定し、処理をファックスするファイルのURIに設定します。 SCTPサーバーは、ファクス機と同じように、ファイルを受け取って通話に送ります。
Click-to-fax: SCTP Client issues an SCTP MakeCall with calling number set to user's fax machine, and called number set to Web Server's fax machine. How the file is supplied to the user's fax machine is outside the scope of SCTP.
Click-to-fax：SCTPクライアントは、ユーザーのFAXマシンに設定された発信者番号とWebサーバーのFAXマシンに設定された着信者番号を使用してSCTP MakeCallを発行します。ファイルがユーザーのFAXマシンに提供される方法は、SCTPの範囲外です。
Voice-access-to-content: SCTP Client issues an SCTP MakeCall with called number set to user's telephone number, and calling number set to Web Server and treatment set to a URI for the file of the particular Web page to be read to the called number. The SCTP Server takes care of the file to voice conversion and this is fed into the call as if it were voice.
コンテンツへの音声アクセス：SCTPクライアントは、着信番号をユーザーの電話番号に設定し、発信番号をWebサーバーに設定し、特定のWebページのファイルをURIに設定して、着信先に読み取られるSCTP MakeCallを発行します。数。 SCTPサーバーがファイルから音声への変換を処理し、これが音声であるかのように通話に送られます。
In all of the above cases, the SCTP Client can generate a variety of different Web pages to send to the Web Server via CGI (Common Gateway Interface). The content of these pages is based on the call completion status of the CallMake SCTP action.
上記のすべてのケースで、SCTPクライアントはさまざまな異なるWebページを生成して、CGI（Common Gateway Interface）経由でWebサーバーに送信できます。これらのページの内容は、CallMake SCTPアクションの通話完了ステータスに基づいています。
SCTP Client Running on the User's PC
ユーザーのPCで実行されているSCTPクライアント
+------+
HTML | | INTERNET
+-----+ /--------------| |
| |---/ +------+
| | Web Server
| |---\
+-----+ \
User's PC \ SCTP +------+ +------+
\------------| |-------| | PSTN
| | | |
+------+ +------+
PINT Gateway SN/SCP/Switch
Figure 15: SCTP Client Running on the User's PC
図15：ユーザーのPCで実行されているSCTPクライアント
In this architecture, the user has an SCTP Client co-located with it. If the user is using the telephone line for connection to a Web Server and there is an incoming call, then the SCTP Server in the PINT Gateway will post this event to the SCTP Client. A window will pop up on the user's screen with options available to the user for handling of the incoming call. The user can choose to take the call, send it to voice mail, or send it to another number.
このアーキテクチャでは、ユーザーはSCTPクライアントを同じ場所に配置します。ユーザーがWebサーバーへの接続に電話回線を使用していて、着信コールがある場合、PINTゲートウェイのSCTPサーバーはこのイベントをSCTPクライアントに送信します。ウィンドウがユーザーの画面にポップアップし、ユーザーが着信通話を処理するために使用できるオプションが表示されます。ユーザーは、電話を受ける、ボイスメールに送信する、または別の番号に送信することを選択できます。
For the Fax back service, for example, if the user had a separate fax machine from his or her PC, then the SCTP Server would tell the SCTP Client there is an incoming fax. The user would end or suspend his or her Internet connection, the fax would come in, and the user could then resume the Internet connection.
たとえば、ファックスバックサービスの場合、ユーザーが自分のPCとは別のファックス機を持っている場合、SCTPサーバーは着信ファックスがあることをSCTPクライアントに通知します。ユーザーはインターネット接続を終了または一時停止し、FAXが着信し、ユーザーはインターネット接続を再開できます。
SIP, the Session Initiation Protocol, is a simple signaling protocol for Internet conferencing and telephony. It is currently under development within the IETF MMUSIC (Multiparty Multimedia Session Control) Working Group.
SIP（Session Initiation Protocol）は、インターネット会議およびテレフォニー用のシンプルなシグナリングプロトコルです。現在、IETF MMUSIC（マルチパーティマルチメディアセッションコントロール）ワーキンググループ内で開発中です。
SIP provides the necessary mechanisms to support the following services:
SIPは、次のサービスをサポートするために必要なメカニズムを提供します。
- call forwarding, including the equivalent of 700-, 800- and 900- type calls; - call-forwarding no answer;
- 700、800、および900タイプのコールに相当するものを含むコール転送。 -応答のないコール転送。
- call-forwarding busy; - call-forwarding unconditional; - other address-translation services; - callee and calling "numbers" delivery, where the numbers can be of any (preferably unique) naming scheme; - personal mobility, i.e., the ability to reach a called party under a single, location-independent address, even when the user changes terminals; - terminal-type negotiation and selection: a caller can be given a choice of how to reach a party, e.g., via Internet telephony, mobile, phone, and an answering service; - caller and callee authentication; - blind and supervised call transfer; - user location; and - invitation to multicast conferences.
- 通話転送ビジー。 -無条件のコール転送。 -その他のアドレス変換サービス。 -着信者と発信者の「番号」配信。番号は、任意の（できれば一意の）命名体系にすることができます。 -パーソナルモビリティ、つまり、ユーザーが端末を変更した場合でも、場所に依存しない単一のアドレスで着信側に到達する機能。 -端末タイプのネゴシエーションと選択：発信者は、たとえば、インターネット電話、携帯電話、電話、および応答サービスを介して、パーティに到達する方法を選択できます。 -呼び出し元と呼び出し先の認証。 -ブラインドおよび監視付きコール転送。 -ユーザーの場所。および-マルチキャスト会議への招待。
Extensions of SIP to allow third-party signaling (e.g., for click-to-dial-back services, fully meshed conferences and connections to Multipoint Control Units (MCUs), as well as mixed modes and the transition between those) have been specified.
サードパーティのシグナリングを可能にするSIPの拡張機能（クリックツーダイヤルバックサービス、完全メッシュ会議、マルチポイントコントロールユニット（MCU）への接続、および混合モードとそれらの間の移行など）が指定されています。
SIP addresses (URLs) can be embedded in Web pages. SIP is addressing-neutral, with addresses expressed as URLs of various types such as SIP, H.323 or telephone (E.164). A purely representational example of a SIP URL might be sip:+12125551212@foo.example.com, where foo.example.com is the host serving as a gateway into the PSTN.
SIPアドレス（URL）をWebページに埋め込むことができます。 SIPはアドレスに中立であり、アドレスはSIP、H.323、電話（E.164）などのさまざまなタイプのURLとして表現されます。 SIP URLの純粋に表現的な例は、sip：+12125551212@foo.example.comです。foo.example.comは、PSTNへのゲートウェイとして機能するホストです。
SIP is independent of the packet layer and only requires an unreliable datagram service, as it provides its own reliability mechanism. While SIP typically is used over UDP or TCP, it could, without technical changes, be run over IPX, or carrier pigeons, ATM AAL5 or X.25, in rough order of desirability.
SIPはパケットレイヤーに依存せず、独自の信頼性メカニズムを提供するため、信頼性の低いデータグラムサービスのみが必要です。 SIPは通常、UDPまたはTCPを介して使用されますが、技術的な変更なしに、IPX、またはキャリアピジョン、ATM AAL5またはX.25を大まかな順序で実行できます。
SIP can set up calls "out-of-band". For example, while the SIP protocol exchanges use IP, plus UDP or TCP, the actual data transport can take place via the PSTN. This feature makes it possible to use SIP to control a PBX or send requests to a Service Control Point. The PINT services make use of this flexibility.
SIPは「アウトオブバンド」でコールをセットアップできます。たとえば、SIPプロトコル交換ではIPとUDPまたはTCPを使用しますが、実際のデータ転送はPSTNを介して行うことができます。この機能により、SIPを使用してPBXを制御したり、サービスコントロールポイントに要求を送信したりできます。 PINTサービスはこの柔軟性を利用します。
SIP is a textual client-server protocol, similar in syntax to HTTP and RTSP. Requests consist of a method (INVITE, BYE, ACK, or REGISTER), a list of parameter-value pairs describing the request and an optional request body. Parameters include the origin and destination of the call and a unique call identifier. They may indicate the caller's organization as well as the call's subject and priority. The request body contains a description of the call to be established or the conference to be joined. The description format is not prescribed by SIP; SDP is one possibility being standardized within the IETF. For the purposes of providing PINT services, an additional phone number address format is to be added to SDP.
SIPは、HTTPおよびRTSPと構文が似ているテキストクライアントサーバープロトコルです。リクエストは、メソッド（INVITE、BYE、ACK、またはREGISTER）、リクエストを説明するパラメーターと値のペアのリスト、およびオプションのリクエスト本文で構成されます。パラメータには、コールの発信元と宛先、および一意のコールIDが含まれます。これらは、発信者の組織、およびコールの件名と優先度を示す場合があります。リクエストの本文には、確立するコールまたは参加する会議の説明が含まれています。記述形式はSIPでは規定されていません。 SDPは、IETF内で標準化されている1つの可能性です。 PINTサービスを提供する目的で、追加の電話番号アドレス形式がSDPに追加されます。
Responses indicate whether a request is still being processed, was successful, can possibly be satisfied by another node or failed. When a call is redirected, the response indicates the name of the node to be tried. Unsuccessful calls may also return a better time to try again.
応答は、要求がまだ処理中であるか、成功したか、別のノードによって満たされるか、失敗したかを示します。コールがリダイレクトされると、応答は試行されるノードの名前を示します。失敗した呼び出しは、再試行するためにより良い時間を返すかもしれません。
In a typical successful call, the caller sends an INVITE request to the callee. The callee accepts the call by returning a response code to the callee, which then confirms the receipt of that acceptance with an ACK request. Either side can terminate the call by sending a BYE request.
典型的な成功した呼び出しでは、呼び出し元は呼び出し先にINVITE要求を送信します。呼び出し先は、呼び出し先に応答コードを返すことで呼び出しを受け入れます。呼び出し先は、ACK要求でその受け入れの受信を確認します。どちらの側も、BYEリクエストを送信することで通話を終了できます。
Requests can be authenticated using standard HTTP password and challenge-response mechanisms. Requests and responses may also be signed and encrypted.
リクエストは、標準のHTTPパスワードとチャレンジ/レスポンスメカニズムを使用して認証できます。リクエストとレスポンスも署名され、暗号化されます。
SIP distinguishes three kinds of entities:
SIPは3種類のエンティティを区別します。
User agents receive and initiate calls and may forward the call.
ユーザーエージェントは、通話を受信して開始し、通話を転送できます。
A proxy server is an intermediary program that acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, possibly after translation, to other servers. A proxy must interpret, and, if necessary, rewrite a request message before forwarding it. A proxy server may, for example, locate a user and then attempt one or more possible network addresses.
プロキシサーバーは、他のクライアントに代わってリクエストを行う目的でサーバーとクライアントの両方として機能する中間プログラムです。リクエストは内部的に処理されるか、おそらく変換後に他のサーバーに渡されます。プロキシは要求メッセージを解釈し、必要に応じて転送する前に書き換える必要があります。プロキシサーバーは、たとえば、ユーザーの位置を特定し、1つまたは複数の可能なネットワークアドレスを試行します。
Redirect server accepts a SIP request, maps the address into zero or more new addresses and returns these addresses to the client. Unlike a proxy server, it does not initiate its own SIP request. Unlike a user agent server, it does not accept calls.
リダイレクトサーバーはSIP要求を受け入れ、アドレスを0個以上の新しいアドレスにマップし、これらのアドレスをクライアントに返します。プロキシサーバーとは異なり、独自のSIPリクエストを開始しません。ユーザーエージェントサーバーとは異なり、呼び出しを受け付けません。
Proxy and redirect servers may make use of location servers that determine the current likely location of the callee.
プロキシサーバーとリダイレクトサーバーは、呼び出し先の現在可能性の高い場所を決定するロケーションサーバーを利用する場合があります。
A PSTN gateway initiates phone calls between two parties. This may be a server that sends requests to an SCP in an IN environment or it may be a CTI-controlled PBX.
PSTNゲートウェイは、2者間の通話を開始します。これは、IN環境のSCPに要求を送信するサーバーの場合もあれば、CTI制御のPBXの場合もあります。
A SIP call may traverse one or more proxy servers.
SIPコールは、1つ以上のプロキシサーバーを通過できます。
The servers that control a PBX or an SCP act as user agents. A Web server may also act as a SIP user agent.
PBXまたはSCPを制御するサーバーは、ユーザーエージェントとして機能します。 WebサーバーはSIPユーザーエージェントとしても機能します。
The SIP for PINT specification provides details on how to use SIP to initiate phone calls between two PSTN end points. (SIP can also initiate calls between Internet end points and between an Internet and PSTN end point, but this is beyond the scope of this document.)
SIP for PINT仕様は、SIPを使用して2つのPSTNエンドポイント間で通話を開始する方法の詳細を提供します。 （SIPは、インターネットエンドポイント間およびインターネットとPSTNエンドポイント間の通話も開始できますが、これはこのドキュメントの範囲外です。）
It should be noted that the SIP client for initiating such phone calls can be either at the user's location (his/her workstation) or can be a Web server that calls up a SIP client via a CGI program. There is no difference in operation or functionality, except that the owner of the Web server may be legally responsible for the calls made.
このような通話を開始するためのSIPクライアントは、ユーザーの場所（彼/彼女のワークステーション）にあるか、CGIプログラムを介してSIPクライアントを呼び出すWebサーバーのいずれかであることに注意してください。 Webサーバーの所有者が行われた呼び出しに対して法的に責任がある場合を除いて、操作や機能に違いはありません。
A SIP client needs to convey two addresses to the PSTN gateway: the party making the call and the party to be called. (The party to be billed also needs to be identified; this can either be done by a SIP header or by having the server look up the appropriate party based on the two parties. This aspect is for further study.)
SIPクライアントは、PSTNゲートウェイに2つのアドレスを伝達する必要があります。呼び出しを行う側と呼び出される側です。 （請求されるパーティーも識別される必要があります。これは、SIPヘッダーによって、またはサーバーに2つのパーティーに基づいて適切なパーティーを検索させることによって行うことができます。この側面は、さらに調査する必要があります。）
Described below are three ways these addresses can be conveyed in SIP. In the example, the address of party A is +1-212-555-1234 and that of party B is +1-415-555-1200. (The URL types in this and other examples are representational; they may but do not have to exist.)
以下では、これらのアドレスをSIPで伝達する3つの方法について説明します。この例では、パーティAのアドレスは+ 1-212-555-1234であり、パーティBのアドレスは+ 1-415-555-1200です。 （この例および他の例のURLタイプは代表的なものであり、存在する必要はありませんが。）
(1) The two PSTN addresses are contained in the To header (and request-URI) and an Also header. For example:
（1）2つのPSTNアドレスがToヘッダー（およびrequest-URI）とAlsoヘッダーに含まれています。例えば：
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0
To: phone:1-212-555-1234
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
Also: phone:+1-415-555-1200
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
c=PSTN E.164 +1-415-555-1200
t=0 0
m=audio 0 RTP/AVP 0
In that case, the gateway first connects to party A and then party B, but without waiting for A to accept the call before calling B.
その場合、ゲートウェイは最初にパーティAに接続し、次にパーティBに接続しますが、Aがコールを受け入れる前にBを呼び出すことはありません。
(2) Parties A and B are indicated by separate invitations. This allows the gateway to make sure that party A is indeed available before calling party B. After calling party A, the gateway could play an announcement indicating that the call is being connected using, for example, RTSP with appropriate Conference header indicating the call.
（2）パーティAとBは別々の招待状で示されます。これにより、ゲートウェイは、通話者Bを呼び出す前に通話者Aが実際に利用可能であることを確認できます。通話者Aを呼び出した後、ゲートウェイは、適切な会議ヘッダーを含むRTSPなどを使用して通話が接続されていることを示すアナウンスを再生できます。
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0 To: phone:1-212-555-1234 From: sip:j.doe@example.com Content-type: application/sdp Call-ID: 19970721T135107.25.181@foo.bar.com ... INVITE sip:+1-415-555-1200@pbx.example.com SIP/2.0 To: phone:+1-415-555-1200 From: sip:j.doe@example.com Content-type: application/sdp Call-ID: 19970721T135107.25.181@foo.bar.com ...
INVITE sip：+1-212-555-1234@pbx.example.com SIP / 2.0 To：phone：1-212-555-1234 From：sip：j.doe@example.com Content-type：application / sdp Call -ID：19970721T135107.25.181@foo.bar.com ... INVITE sip：+1-415-555-1200@pbx.example.com SIP / 2.0 To：phone：+ 1-415-555-1200 From：sip ：j.doe@example.com Content-type：application / sdp Call-ID：19970721T135107.25.181@foo.bar.com ...
(3) The two PSTN addresses are conveyed in the To header of the SIP request and the address in the SDP media description. Thus, a request may look as follows:
（3）2つのPSTNアドレスは、SIP要求のToヘッダーとSDPメディア記述のアドレスで伝達されます。したがって、リクエストは次のようになります。
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0
To: phone:1-212-555-1234
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
c=PSTN E.164 +1-415-555-1200
t=0 0
m=audio 0 RTP/AVP 0
Here, pbx.example.com is the name of the PSTN gateway; the call will be established between 1-212-555-1234 and +1-415-555-1200.
ここで、pbx.example.comはPSTNゲートウェイの名前です。電話は1-212-555-1234と+ 1-415-555-1200の間に確立されます。
Users can be added to an existing call by method (1) or (2).
メソッド（1）または（2）を使用して、ユーザーを既存の呼び出しに追加できます。
Inter-networking of the Internet and PSTN necessitates the introduction of new interfaces (e.g., the A, B and E interfaces in Figure 6). To ensure that their use does not put the networks, in particular the PSTN, at additional security risk, these interfaces need to be designed with proper security considerations. Sections 5.1.5 and 5.2.2.7 describe how two of the pre-PINT implementations, the Lucent and Siemens systems, handle the security aspect, respectively.
インターネットとPSTNのインターネットワーキングでは、新しいインターフェイス（図6のA、B、Eインターフェイスなど）を導入する必要があります。それらの使用がネットワーク、特にPSTNを追加のセキュリティリスクに置かないようにするために、これらのインターフェイスは適切なセキュリティを考慮して設計する必要があります。セクション5.1.5と5.2.2.7では、PINT導入前の2つの実装であるLucentシステムとSiemensシステムがそれぞれセキュリティの側面をどのように処理するかについて説明します。
Worth noting are the security requirements suggested by pre-PINT experiences. They are:
注目に値するのは、PINT前のエクスペリエンスで提案されているセキュリティ要件です。彼らです：
+Peer entity authentication to allow a communicating entity to prove its identity to another in the network (e.g., the requesting IP-host to the PINT gateway, and the PINT gateway to the PSTN node providing the service control function).
+通信エンティティがそのアイデンティティをネットワーク内の別のエンティティに証明できるようにするピアエンティティ認証（例：PINTゲートウェイへの要求IPホスト、およびサービス制御機能を提供するPSTNノードへのPINTゲートウェイ）。
+Authorization and access control to verify if a network entity (e.g., the requesting IP-host) is allowed to use a network resource (e.g., requesting services from the PINT gateway).
+ネットワークエンティティ（要求元のIPホストなど）がネットワークリソース（PINTゲートウェイからのサービスの要求など）の使用を許可されているかどうかを確認するための承認とアクセス制御。
+Non-repudiation to account for all operations in case of doubt or dispute.
+否認防止は、疑義または紛争の場合にすべての操作を説明します。
+Confidentiality to avoid disclosure of information (e.g., the end user profile information and data) without the permission of its owner.
+所有者の許可なしに情報（エンドユーザーのプロファイル情報やデータなど）の開示を回避するための機密保持。
In the course of the PINT interface development, additional requirements are likely to arise. It is imperative that the resultant interfaces include specific means to meet all the security requirements.
PINTインターフェース開発の過程で、追加の要件が発生する可能性があります。結果のインターフェイスには、すべてのセキュリティ要件を満たすための特定の手段が含まれていることが不可欠です。
This document has provided the information relevant to the development of inter-networking interfaces between the PSTN and Internet for supporting PINT services. Specifically, it addressed technologies, architectures, and several existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services. One key observation is that the pre-PINT implementations, being developed independently, do not inter-operate. It is a task of the PINT Working Group to define the inter-networking interfaces that will support inter-operation of the future implementations of PINT services.
このドキュメントでは、PSINTとインターネット間のPINTサービスをサポートするためのインターネットワークインターフェイスの開発に関連する情報を提供しています。具体的には、テクノロジ、アーキテクチャ、およびインターネットアプリケーションがPSTNテレコミュニケーションサービスを要求および強化するための配置のいくつかの既存のPINT前の実装に対処しました。重要な観察結果の1つは、PINT前の実装は独立して開発されており、相互運用できないことです。 PINTサービスの将来の実装の相互運用をサポートする内部ネットワークインターフェイスを定義することは、PINTワーキンググループのタスクです。
The authors would like to acknowledge Scott Bradner, Igor Faynberg, Dave Oran, Scott Petrack, Allyn Romanow for their insightful comments presented to the discussions in the PINT Working Group that lead to the creation of this document.
この文書の作成につながったPINTワーキンググループでの議論に提示された洞察に満ちたコメントについて、著者はスコットブラドナー、イゴールファインバーグ、デイブオラン、スコットピートラック、アリンロマノウに感謝します。
What is normally considered as "the Telephone Network" consists of a set of interconnected networks. Potentially, each of these networks could be owned by a different Network Operator. The official name for such a network is Public Switched Telecommunications Network (PSTN). A simple PSTN consists of a set of Switches (called Central Offices or Telephone Exchanges) with links interconnecting them to make up the network, along with a set of access connections by which terminals are attached. The PSTN is used to deliver calls between terminals connected to itself or to other PSTNs with which it is interconnected. Calls on the PSTN are circuit switched; that is, a bi-directional connection is made between the calling and called terminals for the duration of the call. In PSTNs the connection is usually carried through the network in digital format occupying a fixed bandwidth; this is usually 56 or 64 Kbps. The overall configuration of the PSTN is shown in Figure 16.
通常「電話ネットワーク」と見なされるものは、相互接続されたネットワークのセットで構成されます。潜在的に、これらのネットワークのそれぞれが異なるネットワークオペレーターによって所有されている可能性があります。このようなネットワークの正式名称は、Public Switched Telecommunications Network（PSTN）です。単純なPSTNは、ネットワークを構成するために相互接続するリンクを備えた一連のスイッチ（Central OfficesまたはTelephone Exchangesと呼ばれる）と、端末が接続される一連のアクセス接続で構成されます。 PSTNは、それ自体または相互接続されている他のPSTNに接続された端末間でコールを配信するために使用されます。 PSTNのコールは回線交換です。つまり、通話の間、発信端末と着信端末の間に双方向接続が確立されます。 PSTNでは、接続は通常、固定帯域幅を占有するデジタル形式でネットワークを介して行われます。これは通常56または64 Kbpsです。 PSTNの全体的な構成を図16に示します。
/--\
()/\()__
/__\ \ .................................
\ ! ! ! /--\
__ \ [-!-] [-!-] ! ()/\()
\ \ \__[CO ]=========[CO ]==\\ ! ___/__\
[Fax]________[---] [---] \\ [-!-] / __
\\=======[CO ]____/ \ \
[---]________[Fax]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
Figure 16
図16
Messages are sent between the Switches to make and dissolve connections through the network on demand and to indicate the status of terminals involved in a call; these "signaling" messages are carried over a separate (resilient) data network dedicated to this purpose. This signaling network is also known as the Common Channel Signaling (CCS) or Signaling System Number 7 (or SS7) network after the names of the signaling protocol suite used.
スイッチを介してメッセージが送信され、オンデマンドでネットワークを介して接続を確立および解消し、通話に関与する端末のステータスを示します。これらの「シグナリング」メッセージは、この目的専用の別個の（復元力のある）データネットワークを介して伝送されます。このシグナリングネットワークは、使用されるシグナリングプロトコルスイートの名前にちなんで、Common Channel Signaling（CCS）またはSignaling System Number 7（またはSS7）ネットワークとも呼ばれます。
As yet, the majority of access connections to a PSTN carry analogue signals, with simple (analogue) telephones or Facsimile machines as terminals. Call requests are indicated to the Central Office to which a telephone is connected either by a sequence of pulses or tone pairs being sent. Notifications on the status of the request are sent back to the telephone in the form of tones. Indication from a Central Office that a call is being offered to a telephone is arranged by sending an alternating voltage down the access connection which in turn causes the ringer in the telephone to sound. These access lines have a unique address associated with them and can support a single call.
今のところ、PSTNへのアクセス接続の大部分はアナログ信号を伝送し、単純な（アナログ）電話またはファクシミリ装置を端末として使用します。通話要求は、一連のパルスまたは送信されるトーンペアのいずれかによって、電話が接続されているセントラルオフィスに示されます。リクエストのステータスに関する通知は、トーンの形で電話に返送されます。コールが電話に提供されていることの中央局からの表示は、アクセス接続を介して交流電圧を送信することにより調整され、これにより電話の呼び出し音が鳴ります。これらのアクセス回線には固有のアドレスが関連付けられており、1つのコールをサポートできます。
However, with analogue or digital multi-line connections, or Integrated Service Digital Network (ISDN) Basic or Primary Rate Interfaces (BRI or PRI), several concurrent calls are possible and a set of addresses are associated with them. The new ISDN access connections are designed so that data exchanged with the network is in multiplexed digital form, and there is an individual channel for each of the potential connections, together with a separate channel dedicated to sending and receiving call request and call alert data as well as carrying packet switched user data. These call request and call alert messages act as the equivalent of the pulses or tones that are sent when dialing, and the ringing signal that is sent to a telephone when a call is being made to it.
ただし、アナログまたはデジタルの複数回線接続、または統合サービスデジタルネットワーク（ISDN）ベーシックまたはプライマリレートインターフェイス（BRIまたはPRI）では、複数の同時呼び出しが可能であり、それらに一連のアドレスが関連付けられます。新しいISDNアクセス接続は、ネットワークと交換されるデータが多重化されたデジタル形式になるように設計されており、潜在的な接続ごとに個別のチャネルがあり、呼び出し要求と呼び出しアラートデータの送受信専用の個別のチャネルがあります。パケット交換されたユーザーデータを運ぶだけでなく。これらの通話要求メッセージと通話警告メッセージは、ダイヤル時に送信されるパルスまたはトーン、および電話がかけられたときに電話に送信される呼び出し信号と同等の働きをします。
The operation of the call request is fairly simple in most cases and is shown in Figure 17.
呼び出し要求の操作はほとんどの場合かなり単純であり、図17に示されています。
/--\
() ()
--____
/++\ \ ................................. /--\
/----\ \ ^ v ! () ()
A \ [-!-] [-!-] ! --
\->[CO ]=========[CO ]==\\ v ->-/ \
[---] [---] \\ [-!-] / /----\
\\=======[CO ]____/ B
[---]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
Figure 17
図17
The user presses a sequence of numbers on a telephone handset (labeled A), and the telephone passes a sequence of digits (either as pulses or tone pairs) to the Central Office via the access line. The Central Office contains a processor that will be notified that the user has made a request and the digit string that is the sole parameter of the request. This digit string is taken to be the unique address of an access line connected either to itself or to another Central Office. There is a hierarchical addressing scheme, so that the digit string can be parsed easily. A call request to a terminal (labeled B) connected to a remote Central Office can be routed by examining the digit string passed; the Central Office will extract the part of the passed address that corresponds to the remote Central Office in question, and can route the request onward, forming an inter-Switch call request and passing it via the signaling network. At the same time it will allocate one of its available transmission channels towards the remote Central Office.
ユーザーは電話の受話器（Aというラベルが付いている）の一連の番号を押し、電話は一連の数字を（パルスまたはトーンペアとして）アクセス回線経由で中央局に渡します。セントラルオフィスには、ユーザーが要求を行ったことを通知されるプロセッサと、要求の唯一のパラメーターである数字列が含まれています。この数字列は、それ自体または別のセントラルオフィスに接続されているアクセス回線の一意のアドレスと見なされます。階層的なアドレス指定スキームがあり、数字列を簡単に解析できます。リモートの中央局に接続された端末（ラベルB）への呼び出し要求は、渡された数字列を調べることによってルーティングできます。セントラルオフィスは、問題のリモートセントラルオフィスに対応する渡されたアドレスの一部を抽出し、要求を先にルーティングして、スイッチ間コール要求を形成し、それをシグナリングネットワーク経由で渡すことができます。同時に、利用可能な伝送チャネルの1つをリモートのセントラルオフィスに割り当てます。
This scheme has been used since the 1950s, and suffices for the majority of calls. However, there are a range of other services that can be (and have been) provided, enhancing this basic call processing. Freephone or Premium Rate services (1-800 or 1-900 services) are good examples of the supplementary services that have been introduced. Apart from the important feature that the cost of these calls is varied so that the caller does not pay for a free-phone call, or pays an extra charge for a premium rate call, they have the similarity that the number dialed must be translated to arrive at the "real" address of the destination terminal. They are known as number translation services, and make up the bulk of all supplementary services delivered today.
このスキームは1950年代から使用されており、大部分の呼び出しには十分です。ただし、この基本的な呼処理を強化するために提供できる（提供されている）他のさまざまなサービスがあります。無料電話またはプレミアムレートサービス（1-800または1-900サービス）は、導入されている補足サービスの良い例です。これらの通話のコストは変動するため、発信者が無料通話の料金を支払ったり、プレミアムレートの通話に追加料金を支払ったりするという重要な機能を除いて、ダイヤルした番号を変換する必要があるという点で類似しています。宛先端末の「実際の」アドレスに到着します。これらは番号変換サービスとして知られており、今日提供されるすべての補足サービスの大部分を占めています。
These were originally programmed into each Central Office, but the complexity of maintaining the data tables on each processor grew cumbersome, so a more general solution was sought. After a considerable gestation period, the eventual solution was the Intelligent Network. This takes the separation of Central Offices and the network links interconnecting them a stage further.
これらはもともと各中央局にプログラムされていましたが、各プロセッサでデータテーブルを維持する複雑さが煩雑になったため、より一般的な解決策が求められていました。かなりの妊娠期間の後、最終的な解決策はインテリジェントネットワークでした。これにより、セントラルオフィスとそれらを相互接続するネットワークリンクの分離がさらに進んでいきます。
The Central Offices are considered to provide the Call Control Function (CCF). In addition, the Service Switching Function (SSF) is provided to "enhance" the operation of these Switches by detecting when a particular request has been made (such as by dialing 1-800). If this pattern is detected, the equipment implementing the SSF will send a specialized request message over the signaling network to a separate computer that implements the Service Control Function (SCF). This entity is responsible for querying service specific data (held in a unit providing the Service Data Function, or SDF), performing any digit translations necessary, and sending the details of how to proceed back to the SSF, where they are obeyed and the call is put through to the "real" destination. In many implementations, the SDF is closely coupled to the SCF. This configuration is shown in Figure 18.
中央局は、呼制御機能（CCF）を提供すると見なされます。さらに、サービススイッチング機能（SSF）は、特定の要求が行われたとき（1-800をダイヤルするなど）を検出することにより、これらのスイッチの動作を「強化」するために提供されています。このパターンが検出された場合、SSFを実装する機器は、サービス制御機能（SCF）を実装する別のコンピューターに、シグナリングネットワークを介して特殊な要求メッセージを送信します。このエンティティは、サービス固有のデータ（サービスデータ機能（SDF）を提供するユニットに保持されている）にクエリを実行し、必要な数字変換を実行し、従う方法の詳細をSSFに送り返します。 「本当の」目的地に通されます。多くの実装では、SDFはSCFに密接に結合されています。この構成を図18に示します。
[---] [---] [---]
/--\ [SRF] [SCF] [SDF]
()/\()__ [|-!] [-!-] [-!-]
/__\ \ || \.............!......!........
\ || / ! ! /--\
__ \ [|-!] [-!-] ! ()/\()
\ \ \__[SSF] [CCF] ! ___/__\
[Fax]________[CCF]=========[---]==\\ [!--] / __
\\========[CCF]__/ \ \
[---]_______[Fax]
Key: ___ access relationship
=== trunk relationship
... signaling relationship
Figure 18
図18
The advantage is that there can be a much smaller number of physical units dedicated to the SCF, and as they are connected to the signaling network they can be contacted by, and can send instructions back to, all of the units providing the SSF and thus the CCF.
利点は、SCF専用の物理ユニットの数がはるかに少なくなる可能性があり、それらがシグナリングネットワークに接続されると、SSFを提供するすべてのユニットが接続し、それらに指示を送信できるようになるためです。 CCF。
In another enhancement, a separate entity called the Special Resource Function (SRF) was defined. Equipment implementing this function includes announcement units to play recorded messages (for example, prompts to enter digits) to callers. It will also include the tone decoders needed to capture any digits pressed by the caller in response to the prompts. It is connected to the rest of the PSTN usually via trunk data links. It will also include a signaling connection (directly or indirectly) back to the SCF, via the PSTN's core signaling network.
別の拡張機能では、特殊リソース機能（SRF）と呼ばれる別個のエンティティーが定義されました。この機能を実装する機器には、録音されたメッセージ（数字を入力するプロンプトなど）を発信者に再生するアナウンスユニットが含まれています。また、プロンプトに応答して発信者が押した数字をキャプチャするために必要なトーンデコーダも含まれます。通常はトランクデータリンクを介してPSTNの残りの部分に接続されます。また、PSTNのコアシグナリングネットワークを介して、SCFに（直接または間接的に）戻るシグナリング接続も含まれます。
As an example of the way that these different functional entities interact, the SCF can ask an SSF handling a call to route the caller temporarily through to an SRF. In response to instructions sent to it from the SCF over the signaling network, the SRF can play announcements and can collect digits that the user presses on their terminal in response to prompts they are played. Once these digits have been collected they can be passed on to the SCF via a signaling message for further processing. In normal operation, the SCF would then ask the SSF to dissolve the temporary connection between the user's terminal and the SRF. This allows the collection of account numbers or passwords (or PINs) and forms the heart of many "Calling Card" services.
これらのさまざまな機能エンティティが相互作用する方法の例として、SCFは、呼び出しを処理するSSFに、呼び出し元を一時的にSRFにルーティングするように要求できます。信号ネットワークを介してSCFから送信された指示に応答して、SRFはアナウンスを再生し、再生されたプロンプトに応答してユーザーが端末で押す数字を収集できます。これらの数字が収集されると、さらに処理するために、シグナリングメッセージを介してSCFに渡すことができます。通常の操作では、SCFはSSFにユーザーの端末とSRFの間の一時的な接続を解除するように要求します。これにより、アカウント番号またはパスワード（またはPIN）の収集が可能になり、多くの「通話カード」サービスの中心となります。
This pattern of user interaction is also used in a wide variety of other services where extra account information and PINs are needed. They are collected as just described and can be checked against the correct values stored in the service database prior to allowing the call to proceed.
このユーザーインタラクションのパターンは、追加のアカウント情報とPINが必要な他のさまざまなサービスでも使用されます。これらは前述のように収集され、コールを続行する前に、サービスデータベースに保存されている正しい値と照合できます。
The Intelligent Network functional entities can be realized as physical units in a number of different combinations. A common configuration is shown in Figure 19.
インテリジェントネットワーク機能エンティティは、さまざまな組み合わせの物理ユニットとして実現できます。一般的な構成を図19に示します。
[---] [---] [---] [---]
/--\ [I.P] [SCP] [SDP] [SN ]
()/\()__ [|-!] [-!-] [-!-] [--|]
/__\ \ || \.............!.....!..... |
\ || / ! \ | /--\
__ \ [|-!] [-!-] \ | ()/\()
\ \ \__[SSP]=========[CO ]==\\ \ | ___/__\
[Fax]________[---] [---] \\ [!-|] / __
\\=======[CO ]__/ \ \
[---]_______[Fax]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
SSP Service Switching Point - a unit that implements the
Service Switching Function
CCP Call Control Point - a unit that performs call control
functions.
This is normally a kind of Central Office (shown as CO
above)
SCP Service Control Point - a unit implementing the Service
Control Function. NOTE that this is connected to the SS7
Network and uses this connection for all of its
communications.
I.P Intelligent Peripheral - a unit that contains specialized
resources (like announcement units, tone decoders).
In effect, it implements Special Resource Functions.
SN Service Node
Figure 19
図19
This diagram also shows a unit called a Service Node, or SN. This contains components that realize all of the operational Intelligent Network functions (SSF, SCF, SDF, and SRF). It is sometimes more convenient to have all of these elements in one node (for example, for operations and maintenance reasons), particularly within smaller PSTNs or where there is a relatively low level of requests for particular services. Another difference is that, as they are all co-located, proprietary protocols can be used for internal communication, rather than the full Intelligent Network Application Part (INAP) protocol used over the core signaling network between discrete units. It also differs from the "unbundled" approach in that it is connected to the COs within a PSTN as a peripheral, having only an access connection to a Central Office; there is no connection to the core signaling network. Other than this, it operates in a similar way, and can provide the same kinds of services. Information on the specification of the Intelligent Network can be found in the ITU recommendations [1], while two books ([2] and [3]) describe the system, its history, operation, and the philosophy behind it.
この図には、サービスノード（SN）と呼ばれるユニットも示されています。これには、インテリジェントネットワーク機能のすべての機能（SSF、SCF、SDF、およびSRF）を実現するコンポーネントが含まれています。特に小さいPSTN内または特定のサービスに対する要求のレベルが比較的低い場所では、これらの要素すべてを1つのノードに（たとえば、運用や保守の理由で）持つと便利な場合があります。別の違いは、それらがすべて同じ場所にあるため、ディスクリートユニット間のコアシグナリングネットワークで使用される完全なインテリジェントネットワークアプリケーションパーツ（INAP）プロトコルではなく、独自のプロトコルを内部通信に使用できることです。また、セントラルオフィスへのアクセス接続のみを持ち、ペリフェラルとしてPSTN内のCOに接続されているという点で、「バンドルされていない」アプローチとは異なります。コアシグナリングネットワークへの接続はありません。それ以外は同様に動作し、同種のサービスを提供できます。インテリジェントネットワークの仕様に関する情報は、ITUの推奨事項[1]にあります。2冊の本（[2]および[3]）には、システム、その歴史、運用、およびその背後にある哲学が記載されています。
A Call Center is a system that allows a company to be organized with a group of similar individuals (agents), all of whom can either make calls to, or take calls from, customers. The system distributes incoming calls to the agents based on their availability and automates the placement of outgoing calls, selecting an agent to handle the call and routing the call to them only once the call request has been made of the PSTN.
コールセンターとは、顧客に電話をかけたり、顧客から電話をかけたりできる、同様の個人（エージェント）のグループで企業を編成できるシステムです。システムは、アベイラビリティに基づいて着信コールをエージェントに配信し、発信コールの配置を自動化して、コールを処理するエージェントを選択し、PSTNに対してコール要求が行われた場合にのみコールをルーティングします。
The incoming call distribution feature ("automatic call distribution", or ACD) is usually coupled with a call queuing scheme. In this scheme, the callers are connected temporarily with an announcement unit that normally plays music. The calls are treated in sequence so that (once the caller is at the front of the queue) the ACD system selects the next available agent and routes the call through to them.
着信コール分配機能（「自動コール分配」、またはACD）は、通常、コールキューイングスキームと組み合わされています。この方式では、発信者は通常音楽を再生するアナウンスユニットに一時的に接続されます。コールは順番に処理されるため、（発信者がキューの先頭に来ると）ACDシステムは次に応答可能なエージェントを選択し、それらを介してコールをルーティングします。
Another feature connects a customer making an incoming call to a unit that asks them for some information on the purpose of their call, selecting the agent to handle the call based on the particular area of expertise needed; to do this, the agents are further categorized by their knowledge (or "Skill Set"). If this skill set categorization is used then by implication there will be separate queues for each of the skill sets. This user selection scheme can be used independently of the others. For example these so-called "voice navigation systems" can be used to select a particular department extension number, based on the function required by the customer; as such, they can automate the job of company telephone receptionist in routing incoming calls.
別の機能は、電話をかける顧客を、通話の目的に関するいくつかの情報を要求するユニットに接続し、必要な専門分野に基づいて通話を処理するエージェントを選択します。これを行うには、エージェントを知識（または「スキルセット」）によってさらに分類します。このスキルセットの分類が使用されている場合、暗黙的に、スキルセットごとに個別のキューが存在します。このユーザー選択スキーマは、他のスキーマから独立して使用できます。たとえば、これらのいわゆる「音声ナビゲーションシステム」を使用して、顧客が必要とする機能に基づいて、特定の部門内線番号を選択できます。そのため、着信コールのルーティングにおける会社の電話受付の仕事を自動化できます。
Where possible, the information gleaned from the customer can be provided to the selected agent, usually via a separate networked computer connection. Similarly, if an outgoing call is being made to one of a list of customers, information on the customer and the purpose of the call can be provided to the agent selected to handle the call. Such configurations are generally called "Computer Telephony Integration" or CTI systems. Strictly, a CTI system can be arranged to handle routing of incoming calls and automation of outgoing calls only (also known as computer integrated telephony features), without the agents having access to a network of computers. However, the business case for combining the telephony functions of the call center with provision to the agents of computers with customer information can be compelling.
可能であれば、顧客から収集した情報を、通常は別のネットワークコンピュータ接続を介して、選択したエージェントに提供できます。同様に、顧客のリストの1つに発信通話が行われている場合、顧客と通話の目的に関する情報を、通話を処理するために選択されたエージェントに提供できます。このような構成は、一般に「コンピュータテレフォニーインテグレーション」またはCTIシステムと呼ばれます。厳密には、CTIシステムは、エージェントがコンピュータのネットワークにアクセスすることなく、着信コールのルーティングと発信コールの自動化のみを処理するように構成できます（コンピュータ統合テレフォニー機能とも呼ばれます）。ただし、コールセンターのテレフォニー機能と、コンピューターのエージェントへの顧客情報の提供を組み合わせるビジネスケースは、説得力のあるものになる可能性があります。
This is often further combined with a company's order and service processing computer system. In this case, a call is treated as part of a business transaction, with the information to be exchanged captured as fields of a computer form. While such a computer system is not, strictly, part of a call center, integrating the company computer system with the call center is very common. This allows the details of the call to be stored on a centralized database, allowing further automated order processing, for example. It also allows the call to be transferred from one agent to another where needed, ensuring that the new agent has the information already captured. This might be useful if someone with a different area of expertise were to be needed to handle the customer's requirements.
これは多くの場合、会社の注文およびサービス処理コンピューターシステムとさらに組み合わされます。この場合、通話はビジネストランザクションの一部として扱われ、交換される情報はコンピューターフォームのフィールドとしてキャプチャされます。このようなコンピュータシステムは厳密にはコールセンターの一部ではありませんが、会社のコンピュータシステムをコールセンターと統合することは非常に一般的です。これにより、通話の詳細を一元化されたデータベースに保存できるため、たとえば、さらに自動化された注文処理が可能になります。また、必要に応じて、あるエージェントから別のエージェントに通話を転送できるため、新しいエージェントが情報をすでに取得していることを確認できます。これは、顧客の要件を処理するために専門分野の異なる人が必要になる場合に役立ちます。
Traditionally, Call Centers have been used to support teams of agents working at a single site (or a small number of sites, with private telephony trunks interconnecting them). The site Private Automatic Branch eXchange (PABX) was integrated with a computer system to provide these features to people at that site. There can be a business case for provision of such features to distributed teams of workers as well. In particular, the possibility of providing support for people working from home has been seen as important. Some of the Call Center features have been incorporated into public telephone exchanges or Central Offices (COs) from many manufacturers as part of their "Centrex" service offerings.
従来、コールセンターは、単一のサイト（または少数のサイト、およびそれらを相互接続するプライベートテレフォニートランク）で作業するエージェントのチームをサポートするために使用されてきました。サイトのPrivate Automatic Branch eXchange（PABX）はコンピューターシステムと統合され、そのサイトの人々にこれらの機能を提供しました。そのような機能を分散した労働者のチームに提供するビジネスケースも存在します。特に在宅勤務者への支援の可能性は重要視されてきた。コールセンターの機能の一部は、「Centrex」サービスの一部として、多くのメーカーの公衆電話交換局または中央局（CO）に組み込まれています。
There are practical limitations in providing such features on COs. Apart from the procedures needed to configure these features for any telephone line that is to use them, the basic requirement that every agent must have a connection to the supporting CO can limit its usefulness. Another approach is to provide Call Center features via the Intelligent Network. The features might thus be provided over a Telephone Operator's entire network, and would mean that the Call Center could be configured centrally while still allowing agents to be located anywhere within the telephone network. It also means that the supported company can pay for the Call Center features "as they go" rather than having a high "up front" cost.
COにそのような機能を提供することには、実際的な制限があります。これらの機能を使用する電話回線用にこれらの機能を構成するために必要な手順とは別に、すべてのエージェントがサポートCOに接続する必要があるという基本要件により、その有用性が制限される場合があります。別のアプローチは、インテリジェントネットワークを介してコールセンター機能を提供することです。したがって、これらの機能は電話オペレーターのネットワーク全体に提供される可能性があり、コールセンターを一元的に構成しながら、エージェントを電話ネットワーク内のどこにでも配置できるようにすることができます。また、サポート対象の企業は、「前払い」コストが高いのではなく、「そのまま」のコールセンター機能の料金を支払うことができることも意味します。
[1] ITU-T Q.12xx Recommendation Series, Geneva, 1995.
[1] ITU-T Q.12xx推奨シリーズ、ジュネーブ、1995年。
[2] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The Intelligent Network Standards, their Application to Services", McGraw-Hill, 1996.
[2] I.ファインバーグ、L。R.ガブズダ、M。P.カプラン、およびN. J.シャー、「インテリジェントネットワーク標準、サービスへの応用」、McGraw-Hill、1996年。
[3] T. Magedanz and R. Popesku-Zeletin, "Intelligent Networks: Basic Technology, Standards and Evolution", Intl. Thomson Computer Press, 1996.
[3] T. MagedanzとR. Popesku-Zeletin、「インテリジェントネットワーク：基本技術、標準と進化」、Intl。 Thomson Computer Press、1996年。
[4] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December, 1987.
[4] 情報処理システム-オープンシステム相互接続-抽象構文記法1（ASN.1）の仕様、国際標準化機構、国際標準8824、1987年12月。
[5] McCloghrie, K., Editor, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
[5] McCloghrie、K.、編集者、「Simple Network Management Protocol（SNMPv2）バージョン2の管理情報の構造」、RFC 1902、1996年1月。
[6] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, February 1997.
[6] Kristol、D.およびL. Montulli、「HTTP State Management Mechanism」、RFC 2109、1997年2月。
[7] Zimmerman, D., "The Finger User Information Protocol", RFC 1288 December 1991.
[7] ジマーマン、D。、「The Finger User Information Protocol」、RFC 1288、1991年12月。
Authors' Addresses
著者のアドレス
Steve Bellovin AT&T Labs Room E-215 180 Park Ave. Bldg. 103 Florham Park, NJ 07932-0000 USA
Steve Bellovin AT＆T Labs Room E-215 180 Park Ave. Bldg。 103フローハムパーク、NJ 07932-0000米国
Phone: +1 973 360 8656
Fax: +1 973 360 8077
EMail: smb@research.att.com
Fred M. Burg AT&T Labs Room 1N-117 307 Middletown Lincroft Road Lincroft, NJ 07738 USA
Fred M. Burg AT＆T Labs Room 1N-117 307 Middletown Lincroft Road Lincroft、NJ 07738 USA
Phone: +1 732 576 4322
Fax: +1 732 576 4317
EMail: fburg@hogpb.att.com
Lawrence Conroy Roke Manor Research Limited IT&N-INIA Group Roke Manor, Old Salisbury Lane, Romsey, Hampshire SO51 0ZN U.K.
ローレンスコンロイロークマナーリサーチリミテッドIT＆N-INIAグループロークマナー、オールドソールズベリーレーン、ロムジー、ハンプシャーSO51 0ZNイギリス
Phone: +44 1794 833666
Fax: +44 1794 833434
EMail: lwc@roke.co.uk
Paul Davidson Nortel P.O.Box 3511 Station "C" Mail Stop 242 Ottawa, Ontario, Canada K1Y 4H7
Paul Davidson Nortel P.O. Box 3511 Station "C" Mail Stop 242 Ottawa、Ontario、Canada K1Y 4H7
Phone: +1 613 763 4234 EMail: pauldav@nortel.ca A. DeSimone Lucent Technologies Room 6H510 600-700 Mountain Avenue Murray Hill, NJ 07974-0636 USA
電話：+1 613 763 4234 Eメール：pauldav@nortel.ca A. DeSimone Lucent Technologies Room 6H510 600-700 Mountain Avenue Murray Hill、NJ 07974-0636 USA
Phone: +1 908 582 2382
Fax: +1 908 582 1086
E-Mail:tds@lucent.com
Murali Krishnaswamy Bell Laboratories Lucent Technologies Room 2G-527a 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA
Murali Krishnaswamy Bell Laboratories Lucent Technologies Room 2G-527a 101 Crawfords Corner Road Holmdel、NJ 07733-3030 USA
Phone: +1 732 949 3611
Fax: +1 732 949 3210
EMail: murali@bell-labs.com
Hui-Lan Lu Bell Laboratories Lucent Technologies Room 4K-309 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA
Hui-Lan Lu Bell Laboratories Lucent Technologies Room 4K-309 101 Crawfords Corner Road Holmdel、NJ 07733-3030 USA
Phone: +1 732 949 0321
Fax: +1 732 949 1196
EMail: hui-lan.lu@bell-labs.com
Henning Schulzrinne Dept. of Computer Science Columbia University New York, NY 10027 USA
ヘニングシュルズリンネコロンビア大学コンピュータサイエンス学部10027アメリカ合衆国
Phone: +1 212 939 7042 (@Bell Labs: 732 949 8344) Fax: +1 212 666 0140 EMail: schulzrinne@cs.columbia.edu Kamlesh T. Tewani AT&T Labs Room 1K-334 101, Crawfords Corner Rd. Holmdel, NJ 07733 USA
電話：+1 212 939 7042（@Bell Labs：732 949 8344）ファックス：+1 212 666 0140メール：schulzrinne@cs.columbia.edu Kamlesh T. Tewani AT＆T Labs Room 1K-334 101、Crawfords Corner Rd。 Holmdel、NJ 07733 USA
Phone: +1 732 949 5369
Fax: +1 732 949 8569
EMail: tewani@att.com
Kumar Vishwanathan Isochrone EMail: kumar@isochrone.com
Kumar Vishwanatham Isokroneメール：kumar@ischronne.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。