[要約] RFC 2805は、メディアゲートウェイ制御プロトコル(MGCP)のアーキテクチャと要件に関するものです。このRFCの目的は、MGCPの機能と特性を定義し、異なるベンダー間での相互運用性を確保することです。

Network Working Group                                          N. Greene
Request for Comments: 2805                               Nortel Networks
Category: Informational                                       M. Ramalho
                                                           Cisco Systems
                                                                B. Rosen
                                                                 Marconi
                                                              April 2000
        

Media Gateway Control Protocol Architecture and Requirements

メディアゲートウェイ制御プロトコルアーキテクチャと要件

Status of this Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2000). All Rights Reserved.

Copyright(c)The Internet Society(2000)。無断転載を禁じます。

Abstract

概要

This document describes protocol requirements for the Media Gateway Control Protocol between a Media Gateway Controller and a Media Gateway.

このドキュメントは、メディアゲートウェイコントローラーとメディアゲートウェイの間のメディアゲートウェイ制御プロトコルのプロトコル要件について説明します。

Table of Contents

目次

   1.  Introduction ..............................................  3
   2.  Terminology ...............................................  3
   3.  Definitions ...............................................  3
   4.  Specific functions assumed within the MG ..................  5
   5.  Per-Call Requirements .....................................  6
      5.1.  Resource Reservation .................................  6
      5.2.  Connection Requirements ..............................  7
      5.3.  Media Transformations ................................  8
      5.4.  Signal/Event Processing and Scripting ................  9
      5.5.  QoS/CoS .............................................. 10
      5.6.  Test Support ......................................... 11
      5.7.  Accounting ........................................... 11
      5.8.  Signalling Control ................................... 11
   6.  Resource Control .......................................... 12
      6.1.  Resource Status Management ........................... 12
      6.2.  Resource Assignment .................................. 13
   7.  Operational/Management Requirements ....................... 13
      7.1.  Assurance of Control/Connectivity .................... 13
      7.2.  Error Control ........................................ 14
      7.3.  MIB Requirements ..................................... 15
   8.  General Protocol Requirements ............................. 15
      8.1.  MG-MGC Association Requirements ...................... 16
      8.2.  Performance Requirements ............................. 17
   9.  Transport ................................................. 17
      9.1.  Assumptions made for underlying network .............. 17
      9.2.  Transport Requirements ............................... 18
   10.  Security Requirements .................................... 18
   11.  Requirements specific to particular bearer types ......... 19
      11.1.  Media-specific Bearer types ......................... 20
         11.1.1.  Requirements for TDM PSTN (Circuit) ............ 20
         11.1.2.  Packet Bearer type ............................. 22
         11.1.3.  Bearer type requirements for ATM ............... 23
      11.2.  Application-Specific Requirements ................... 26
         11.2.1.  Trunking Gateway ............................... 26
         11.2.2.  Access Gateway ................................. 27
         11.2.3.  Trunking/Access Gateway with fax ports ......... 27
         11.2.4.  Trunking/Access Gateway with text telephone .... 28
         11.2.5.  Network Access Server .......................... 29
         11.2.6.  Restricted Capability Gateway .................. 30
         11.2.7.  Multimedia Gateway ............................. 31
         11.2.8.  Audio Resource Function ........................ 32
         11.2.9. Multipoint Control Units ........................ 42
   12.  References ............................................... 43
   13.  Acknowledgements ......................................... 43
   14.  Authors' Addresses ....................................... 44
   15.  Full Copyright Statement ................................. 45
        
1. Introduction
1. はじめに

This document describes requirements to be placed on the Media Gateway Control Protocol. When the word protocol is used on its own in this document it implicitly means the Media Gateway Control Protocol.

このドキュメントでは、メディアゲートウェイ制御プロトコルに配置される要件について説明します。このドキュメントで単語プロトコルが独自に使用される場合、それは暗黙的にメディアゲートウェイ制御プロトコルを意味します。

2. Terminology
2. 用語

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for the protocol.

このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"RFC 2119 [1]で説明されているように解釈され、プロトコルの要件レベルを示します。

3. Definitions
3. 定義

* Connection

* 繋がり

Under the control of a Media Gateway Controller (MGC), the Media Gateway (MG) realizes connections. In this document, connections are associations of resources hosted by the MG. They typically involve two terminations, but may involve more.

メディアゲートウェイコントローラー(MGC)の制御下で、メディアゲートウェイ(MG)は接続を実現します。このドキュメントでは、接続はMGがホストするリソースの関連付けです。それらは通常、2つの終了を伴いますが、より多くを含む場合があります。

* Line or Loop

* ラインまたはループ

An analogue or digital access connection from a user terminal which carries user media content and telephony access signalling (DP, DTMF, BRI, proprietary business set).

ユーザーメディアコンテンツとテレフォニーアクセスシグナリング(DP、DTMF、BRI、独自のビジネスセット)を搭載したユーザー端末からのアナログまたはデジタルアクセス接続。

* Media Gateway (MG) function

* メディアゲートウェイ(MG)関数

A Media Gateway (MG) function provides the media mapping and/or transcoding functions between potentially dissimilar networks, one of which is presumed to be a packet, frame or cell network. For example, an MG might terminate switched circuit network (SCN) facilities (trunks, loops), packetize the media stream, if it is not already packetized, and deliver packetized traffic to a packet network. It would perform these functions in the reverse order for media streams flowing from the packet network to the SCN.

メディアゲートウェイ(MG)関数は、潜在的に異なるネットワーク間のメディアマッピングおよび/またはトランスコーディング関数を提供します。たとえば、MGは、Switched Circuit Network(SCN)施設(トランク、ループ)を終了し、メディアストリームがまだパケット化されていない場合は、メディアストリームをパケット化し、パケット化されたトラフィックをパケットネットワークに配信する場合があります。これらの機能は、パケットネットワークからSCNに流れるメディアストリームの逆の順序で実行されます。

Media Gateways are not limited to SCN <-> packet/frame/cell functions: A conference bridge with all packet interfaces could be an MG, as well as an (IVR) interactive voice recognition unit, an audio resource function, or a voice recognition system with a cell interface.

メディアゲートウェイはSCN <->パケット/フレーム/セル機能に限定されません:すべてのパケットインターフェイスを備えた会議ブリッジは、MG、(IVR)インタラクティブな音声認識ユニット、オーディオリソース機能、または音声認識である可能性があります。セルインターフェイスを備えたシステム。

* Media Gateway unit (MG-unit)

* メディアゲートウェイユニット(MGユニット)

An MG-unit is a physical entity that contains an MG function and may also contain other functions, e.g. an SG function.

MGユニットは、MG関数を含む物理エンティティであり、他の機能も含む可能性があります。SG関数。

* Media Gateway Controller (MGC) function

* メディアゲートウェイコントローラー(MGC)関数

A Media Gateway Controller (MGC) function controls a MG.

メディアゲートウェイコントローラー(MGC)関数はMgを制御します。

* Media Resource

* メディアリソース

Examples of media resources are codecs, announcements, tones, and modems, interactive voice response (IVR) units, bridges, etc.

メディアリソースの例は、コーデック、アナウンス、トーン、モデム、インタラクティブな音声応答(IVR)ユニット、ブリッジなどです。

* Signaling Gateway (SG) function

* シグナリングゲートウェイ(SG)関数

An SG function receives/sends SCN native signalling at the edge of a data network. For example the SG function may relay, translate or terminate SS7 signaling in an SS7-Internet Gateway. The SG function may also be co-resident with the MG function to process SCN signalling associated with line or trunk terminations controlled by the MG, such as the "D" channel of an ISDN PRI trunk.

SG関数は、データネットワークの端でSCNネイティブシグナル伝達を受信/送信します。たとえば、SG機能は、SS7インターネットゲートウェイでSS7シグナル伝達を中継、翻訳、または終了する場合があります。SG関数は、ISDN PRIトランクの「D」チャネルなど、MGによって制御されるラインまたはトランク終端に関連するSCNシグナル伝達を処理するMG関数の共同住宅でもあります。

* Termination

* 終了

A termination is a point of entry and/or exit of media flows relative to the MG. When an MG is asked to connect two or more terminations, it understands how the flows entering and leaving each termination are related to each other.

終了は、MGに対するメディアフローの入力および/または出口のポイントです。MGが2つ以上の終端を接続するように求められると、各終了が互いにどのように関連しているかを理解します。

Terminations are, for instance, DS0's, ATM VCs and RTP ports. Another word for this is bearer point.

たとえば、終了はDS0、ATM VCS、RTPポートです。これのもう一つの言葉は、ベアラーポイントです。

* Trunk

* トランク

An analog or digital connection from a circuit switch which carries user media content and may carry telephony signalling (MF, R2, etc.). Digital trunks may be transported and may appear at the Media Gateway as channels within a framed bit stream, or as an ATM cell stream. Trunks are typically provisioned in groups, each member of which provides equivalent routing and service.

ユーザーメディアコンテンツを運ぶ回路スイッチからのアナログまたはデジタル接続は、テレフォニーシグナリング(MF、R2など)を運ぶ可能性があります。デジタルトランクは輸送される場合があり、メディアゲートウェイにフレーム付きビットストリーム内のチャネルとして、またはATMセルストリームとして表示される場合があります。トランクは通常、グループでプロビジョニングされ、各メンバーは同等のルーティングとサービスを提供します。

* Type of Bearer

* ベアラーのタイプ

A Type of Bearer definition provides the detailed requirements for its particular application/bearer type. A particular class of Media Gateway, for example, would support a particular set of Bearer types.

ベアラー定義のタイプは、特定のアプリケーション/ベアラータイプの詳細な要件を提供します。たとえば、特定のクラスのメディアゲートウェイは、ベアラータイプの特定のセットをサポートします。

4. Specific functions assumed within the MG
4. mg内で想定される特定の関数

This section provides an environment for the definition of the general Media Gateway Control Protocol requirements.

このセクションでは、一般的なメディアゲートウェイ制御プロトコル要件の定義の環境を提供します。

MGs can be architected in many different ways depending where the media conversions and transcoding (if required) are performed, the level of programmability of resources, how conferences are supported, and how associated signalling is treated. The functions assumed to be within the MG must not be biased towards a particular architecture.

MGは、メディアの変換とトランスコーディング(必要に応じて)が実行される場所、リソースのプログラム性のレベル、会議のサポート方法、および関連するシグナル伝達の扱い方に応じて、さまざまな方法でアーキテクチャできます。MG内にあると想定される関数は、特定のアーキテクチャに偏ってはなりません。

For instance, announcements in a MG could be provided by media resources or by the bearer point resource or termination itself. Further, this difference must not be visible to MGC: The MGC must be able to issue the identical request to two different implementations and achieve the identical functionality.

たとえば、MGの発表は、メディアリソースまたはBearer Pointリソースまたは終了自体によって提供される可能性があります。さらに、この違いがMGCに表示されてはなりません。MGCは、2つの異なる実装に同一の要求を発行し、同一の機能を達成できる必要があります。

Depending on the application of the MG (e.g., trunking, residential), some functions listed below will be more prominent than others, and in some cases, functions may even disappear.

MGの適用(トランク、住宅など)の適用に応じて、以下にリストされているいくつかの機能は他の機能よりも顕著であり、場合によっては機能が消えることさえあります。

Although media adaptation is the essence of the MG, it is not necessary for it to be involved every time. An MG may join two terminations/resources of the same type (i.e., the MG behaves as a switch). The required media conversion depends on the media type supported by the resources being joined together.

メディアの適応はMGの本質ですが、毎回関与する必要はありません。MGは、同じタイプの2つの終端/リソースを結合できます(つまり、MGはスイッチとして動作します)。必要なメディア変換は、結合されるリソースによってサポートされるメディアタイプに依存します。

In addition to media adaptation function, resources have a number of unique properties, for instance:

メディア適応機能に加えて、リソースには、たとえば、多くの一意のプロパティがあります。

* certain types of resources have associated signalling capabilities (e.g., PRI signalling, DTMF),

* 特定の種類のリソースには、関連するシグナル伝達機能(例:PRIシグナル伝達、DTMF)があります。

* some resources perform maintenance functions (e.g., continuity tests),

* 一部のリソースは、メンテナンス機能を実行します(例:連続性テスト)、

* the MGC needs to know the state changes of resources (e.g., a trunk group going out of service),

* MGCは、リソースの状態の変化を知る必要があります(たとえば、稼働しているトランクグループなど)、

* the MG retains some control over the allocation and control of some resources (e.g., resource name space: RTP port numbers).

* MGは、いくつかのリソースの割り当てと制御に対するある程度の制御を保持します(例:リソース名スペース:RTPポート番号)。

Therefore, an MG realizes point-to-point connections and conferences, and supports several resource functions. These functions include media conversion, resource allocation and management, and event notifications. Handling termination associated signalling is either done using event notifications, or is handled by the signalling backhaul part of a MG-unit (i.e. NOT directly handled by the MG).

したがって、MGはポイントツーポイント接続と会議を実現し、いくつかのリソース機能をサポートします。これらの機能には、メディア変換、リソースの割り当てと管理、イベント通知が含まれます。処理された終了関連シグナル伝達は、イベント通知を使用して行われるか、MGユニットのシグナリングバックホール部分によって処理されます(つまり、MGによって直接処理されません)。

MGs must also support some level of system related functions, such as establishing and maintaining some kind of MG-MGC association. This is essential for MGC redundancy, fail-over and resource sharing.

MGSは、ある種のMG-MGC協会の確立と維持など、何らかのレベルのシステム関連機能もサポートする必要があります。これは、MGCの冗長性、フェイルオーバー、リソース共有に不可欠です。

Therefore, an MG is assumed to contain these functions:

したがって、Mgはこれらの機能を含むと想定されています。

* Reservation and release, of resources

* リソースの予約とリリース

* Ability to provide state of resources

* リソースの状態を提供する能力

* Maintenance of resources - It must be possible to make maintenance operations independent of other termination functions, for instance, some maintenance states should not affect the resources associated with that resource . Examples of maintenance functions are loopbacks and continuity tests.

* リソースのメンテナンス - たとえば、一部のメンテナンス状態は、そのリソースに関連するリソースに影響を与えるべきではない、他の終了関数とは独立してメンテナンス操作を行うことができなければなりません。メンテナンス機能の例は、ループバックと連続性テストです。

* Connection management, including connection state.

* 接続管理、接続状態を含む。

* Media processing, using media resources: these provide services such as transcoding, conferencing, interactive voice recognition units, audio resource function units. Media resources may or may not be directly part of other resources.

* メディアリソースを使用したメディア処理:これらは、トランスコーディング、会議、インタラクティブな音声認識ユニット、オーディオリソース機能ユニットなどのサービスを提供します。メディアリソースは、他のリソースの一部である場合とそうでない場合があります。

* Incoming digit analysis for terminations, interpretation of scripts for terminations

* 終了の着信桁分析、終了のスクリプトの解釈

* Event detection and signal insertion for per-channel signalling

* チャネルごとのシグナル伝達のためのイベント検出と信号挿入

* Ability to configure signalling backhauls (for example, a Sigtran backhaul)

* シグナリングバックホールを構成する機能(たとえば、シグトランバックホール)

* Management of the association between the MGC and MG, or between the MGC and MG resources.

* MGCとMGの間、またはMGCとMGのリソース間の関連性の管理。

5. Per-Call Requirements
5. コールごとの要件
5.1. Resource Reservation
5.1. リソース予約

The protocol must:

プロトコルは次のとおりです。

a. Support reservation of bearer terminations and media resources for use by a particular call and support their subsequent release (which may be implicit or explicit).

a. 特定の呼び出しで使用するためのベアラーの終了とメディアリソースの留保をサポートし、その後のリリースをサポートします(これは暗黙的または明示的かもしれません)。

b. Allow release in a single exchange of messages, of all resources associated with a particular set of connectivity and/or associations between a given number terminations.

b. 特定の接続セットに関連するすべてのリソースおよび/または特定の数値終了間の関連性に関連するすべてのリソースの単一のメッセージ交換でのリリースを許可します。

c. The MG is not required (or allowed) by the protocol to maintain a sense of future time: a reservation remains in effect until explicitly released by the MGC.

c. MGは、将来の時間の感覚を維持するためにプロトコルによって必要ではありません(または許可されていません)。MGCによって明示的に解放されるまで予約は有効です。

5.2. Connection Requirements
5.2. 接続要件

The protocol must:

プロトコルは次のとおりです。

a. Support connections involving packet and circuit bearer terminations in any combination, including "hairpin" connections (connections between two circuit connections within the same MG).

a. 「ヘアピン」接続(同じMG内の2つの回路接続間の接続)を含む、任意の組み合わせでパケットと回路のベアラーの終端を含むサポート接続。

b. Support connections involving TDM, Analogue, ATM, IP or FR transport in any combination.

b. 任意の組み合わせでTDM、アナログ、ATM、IP、またはFRトランスポートを含むサポート接続。

c. Allow the specification of bearer plane (e.g. Frame Relay, IP, etc.) on a call by call basis.

c. コールバイコールベースで、ベアラープレーン(例:フレームリレー、IPなど)の仕様を許可します。

d. Support unidirectional, symmetric bi-directional, and asymmetric bi-directional flows of media.

d. 培地の単方向、対称性双方向、および非対称の双方向流量をサポートします。

e. Support multiple media types (e.g. audio, text, video, T.120).

e. 複数のメディアタイプ(オーディオ、テキスト、ビデオ、T.120など)をサポートします。

f. Support point-to-point and point-to-multipoint connections.

f. ポイントツーポイントおよびポイントツーマルチポイント接続をサポートします。

g. Support creation and modification of more complex flow topologies e.g. conference bridge capabilities. Be able to add or delete media streams during a call or session, and be able to add or subtract participants to/from a call or session.

g. より複雑なフロートポロジの作成と変更をサポートします。カンファレンスブリッジ機能。通話またはセッション中にメディアストリームを追加または削除し、コールまたはセッションに参加者と削除することができます。

h. Support inclusion of media resources into call or session as required. Depending on the protocol and resource type, media resources may be implicitly included, class-assigned, or individually assigned.

h. 必要に応じて、メディアリソースを通話またはセッションに含めることをサポートします。プロトコルとリソースの種類に応じて、メディアリソースは暗黙的に含まれる、クラス割り当て、または個別に割り当てられます。

i. Provide unambiguous specification of which media flows pass through a point and which are blocked at a given point in time, if the protocol permits multiple flows to pass through the same point.

i. プロトコルで複数のフローが同じポイントを通過することを許可する場合、どのメディアが特定の時点でブロックされるかを明確に仕様を提供します。

j. Allow modifications of an existing termination, for example, use of higher compression to compensate for insufficient bandwidth or changing transport network connections.

j. 既存の終了の変更を許可します。たとえば、より高い圧縮を使用して、帯域幅が不十分または輸送ネットワーク接続の変更を補正します。

k. Allow the MGC to specify that a given connection has higher priority than other connections.

k. MGCが、特定の接続が他の接続よりも優先度が高いことを指定できるようにします。

l. Allow a reference to a port/termination on the MG to be a logical identifier,

l. MGのポート/終了への参照を論理識別子にすることを許可します。

with a one-to-one mapping between a logical identifier and a physical port.

論理識別子と物理ポートの間に1対1のマッピングがあります。

m. Allow the MG to report events such as resource reservation and connection completion.

m. MGがリソースの予約や接続の完了などのイベントを報告できるようにします。

5.3. Media Transformations
5.3. メディアの変革

The Protocol must:

プロトコルは次のとおりです。

a. Support mediation/adaptation of flows between different types of transport

a. さまざまな種類の輸送間のフローの調停/適応をサポートする

b. Support invocation of additional processing such as echo cancellation.

b. エコーキャンセルなどの追加処理の呼び出しをサポートします。

c. Support mediation of flows between different content encoding (codecs, encryption/decryption)

c. 異なるコンテンツエンコード間のフローの調停をサポートします(コーデック、暗号化/復号化)

d. Allow the MGC to specify whether text telephony/FAX/data modem traffic is to be terminated at the MG, modulated/demodulated, and converted to packets or forwarded by the MG in the media flow as voice band traffic.

d. MGCが、テキストテレフォニー/FAX/データモデムトラフィックをMGで終了し、変調/復調し、パケットに変換するか、メディアフローのMGによってボイスバンドトラフィックとして転送されるかを指定できるようにします。

e. Allow the MGC to specify that Dual-Tone MultiFrequency (DTMF) digits or other line and trunk signals and general Multi-Frequency (MF) tones are to be processed in the MG and how these digits/signals/tones are to be handled. The MGC must be able to specify any of the following handling of such digits/signals/tones:

e. MGCは、デュアルトーンの多面(DTMF)数字またはその他のラインとトランク信号と一般的な多周波(MF)トーンをMGで処理すること、およびこれらの数字/信号/トーンを処理する方法を指定できるようにします。MGCは、このような数字/信号/トーンの以下の処理のいずれかを指定できる必要があります。

1. The digits/signals/tones are to be encoded normally in the audio RTP stream (e.g., no analysis of the digits/signals/tones).

1. 数字/信号/トーンは、通常、オーディオRTPストリームでエンコードされます(たとえば、数字/信号/トーンの分析なし)。

2. Analyzed and sent to the MGC.

2. 分析され、MGCに送信されました。

3. Received from the MGC and inserted in the line-side audio stream.

3. MGCから受信し、ラインサイドのオーディオストリームに挿入されました。

4. Analyzed and sent as part of a separate RTP stream (e.g., DTMF digits sent via a RTP payload separate from the audio RTP stream).

4. 別のRTPストリームの一部として分析および送信されました(たとえば、Audio RTPストリームとは別のRTPペイロードを介して送信されます)。

5. Taken from a separate RTP stream and inserted in the line-side audio stream.

5. 別のRTPストリームから採取され、ラインサイドのオーディオストリームに挿入されます。

6. Handled according to a script of instructions. For all but the first case, an option to mute the digits/signals/tones with silence, comfort noise, or other means (e.g., notch filtering of some telephony tones) must be provided. As detection of these events may take up to tens of milliseconds, the first few milliseconds of such digit/signal/tone may be encoded and sent in the audio RTP stream before the digit/signal/tone can be verified. Therefore muting of such digits/signals/tones in the audio RTP stream with silence or comfort noise is understood to occur at the earliest opportunity after the digit/signal/tone is verified.

6. 指示のスクリプトに従って処理されます。最初のケースを除くすべての場合、沈黙、快適なノイズ、またはその他の手段で数字/信号/トーンをミュートするオプション(たとえば、いくつかのテレフォニートーンのノッチフィルタリング)を提供する必要があります。これらのイベントの検出が数十ミリ秒かかる場合があるため、そのような数ミリ秒の数ミリ秒/シグナル/トーンをエンコードして、桁/信号/トーンを検証する前にオーディオRTPストリームに送信できます。したがって、沈黙または快適なノイズを備えたオーディオRTPストリームにおけるそのような数字/信号/トーンのミュートは、数字/信号/トーンが検証された後、最も早い機会に発生すると理解されます。

f. Allow the MGC to specify signalled flow characteristics on circuit as well as on packet bearer connections, e.g. u-law/a-law.

f. MGCが、回路およびパケットベアラーの接続でシグナル付きフロー特性を指定できるようにします。u-law/a-law。

g. Allow for packet/cell transport adaptation only (no media adaptation) e.g. mid-stream (packet-to-packet) transpacketization/transcoding, or ATM AAL5 to and from ATM AAL2 adaptation.

g. パケット/セル輸送の適応のみを許可します(メディア適応なし)ミッドストリーム(パケットからパケット)トランスパケット化/トランスコーディング、またはATM AAL5へのATM AAL2適応とatm。

h. Allow the transport of audio normalization levels as a setup parameter, e.g., for conference bridging.

h. 会議ブリッジングの場合、セットアップパラメーターとしてオーディオ正規化レベルの輸送を許可します。

i. Allow conversion to take place between media types e.g., text to speech and speech to text.

i. メディアタイプの間でコンバージョンを行うことを許可します。たとえば、テキストからスピーチ、スピーチからテキストへ。

5.4. Signal/Event Processing and Scripting
5.4. 信号/イベント処理とスクリプト

The Protocol must:

プロトコルは次のとおりです。

a. Allow the MGC to enable/disable monitoring for specific supervision events at specific circuit terminations

a. MGCが特定の回路終端で特定の監督イベントの監視を有効/無効にすることを許可します

b. Allow the MGC to enable/disable monitoring for specific events within specified media streams

b. MGCが指定されたメディアストリーム内の特定のイベントの監視を有効/無効にすることを許可します

c. Allow reporting of detected events on the MG to the MGC. The protocol should provide the means to minimize the messaging required to report commonly-occurring event sequences.

c. MGで検出されたイベントの報告をMGCに許可します。プロトコルは、一般的に発生するイベントシーケンスを報告するために必要なメッセージングを最小限に抑える手段を提供する必要があります。

d. Allow the MGC to specify other actions (besides reporting) that the MG should take upon detection of specified events.

d. MGCが、MGが指定されたイベントの検出時に取る必要がある他のアクション(レポート以外)を指定できるようにします。

e. Allow the MGC to enable and/or mask events.

e. MGCがイベントを有効および/またはマスクするようにします。

f. Provide a way for MGC to positively acknowledge event notification.

f. MGCがイベント通知を積極的に認める方法を提供します。

g. Allow the MGC to specify signals (e.g., supervision, ringing) to be applied at circuit terminations.

g. MGCが、回路終端で適用される信号(監督、鳴り響きなど)を指定するようにします。

h. Allow the MGC to specify content of extended duration (announcements, continuous tones) to be inserted into specified media flows.

h. MGCが、指定されたメディアフローに挿入される拡張期間(アナウンス、連続トーン)のコンテンツを指定できるようにします。

i. Allow the MGC to specify alternative conditions (detection of specific events, timeouts) under which the insertion of extended-duration signals should cease.

i. MGCが、延長期間信号の挿入が中止される代替条件(特定のイベントの検出、タイムアウト)を指定できるようにします。

j. Allow the MGC to download, and specify a script to be invoked on the occurrence of an event.

j. MGCをダウンロードし、イベントの発生時に呼び出されるスクリプトを指定します。

k. Specify common events and signals to maximize MG/MGC interworking.

k. MG/MGCインターワーキングを最大化するために、一般的なイベントと信号を指定します。

l. Provide an extension mechanism for implementation defined events and signals with, for example, IANA registration procedures. It may be useful to have an Organizational Identifier (i.e. ITU, ETSI, ANSI, ) as part of the registration mechanism.

l. たとえば、IANA登録手順を使用して、実装されたイベントと信号を実装するための拡張メカニズムを提供します。登録メカニズムの一部として、組織識別子(つまり、ITU、ETSI、ANSI、ANSI)を持つことが有用かもしれません。

m. The protocol shall allow the MGC to request the arming of a mid-call trigger even after the call has been set up.

m. プロトコルは、MGCがコールが設定された後でもミッドコールトリガーの武装を要求できるようにするものとします。

5.5. QoS/CoS
5.5. qos/cos

The Protocol must:

プロトコルは次のとおりです。

a. Support the establishment of a bearer channel with a specified QoS/CoS.

a. 指定されたQOS/COSでベアラーチャネルの確立をサポートします。

b. Support the ability to specify QoS for the connection between MGs, and by direction.

b. MG間と方向ごとにQoSを指定する機能をサポートします。

c. Support a means to change QoS during a connection, as a whole and by direction.

c. 接続中にQoSを変更する手段をサポートします。

d. Allow the MGC to set QOS thresholds and receive notification when such thresholds cannot be maintained.

d. MGCがQoSしきい値を設定し、そのようなしきい値を維持できない場合に通知を受信できるようにします。

e. Allow the jitter buffer parameters on RTP channels to be specified at connection setup.

e. RTPチャネルのジッターバッファーパラメーターを、接続セットアップ時に指定します。

5.6. Test Support
5.6. テストサポート

The protocol must:

プロトコルは次のとおりです。

a. Support of the different types of PSTN Continuity Testing (COT) for both the originating and terminating ends of the circuit connection (2-wire and 4- wire).

a. 回路接続の発信端と終端の両方の両方のために、さまざまなタイプのPSTN連続テスト(COT)のサポート(2ワイヤと4ワイヤ)。

b. Specifically support test line operation (e.g. 103, 105, 108).

b. 具体的には、テストラインの操作をサポートします(例:103、105、108)。

5.7. Accounting
5.7. 会計

The protocol must:

プロトコルは次のとおりです。

a. Support a common identifier to mark resources related to one connection.

a. 共通の識別子をサポートして、1つの接続に関連するリソースをマークします。

b. Support collection of specified accounting information from MGs.

b. MGSからの指定された会計情報のサポートコレクション。

c. Provide the mechanism for the MGC to specify that the MG report accounting information automatically at end of call, in mid-call upon request, at specific time intervals as specified by the MGC and at unit usage thresholds as specified by the MGC.

c. MGCのメカニズムを提供して、MGCで指定されている特定の時間間隔およびMGCで指定された単位使用しきい値で、コールの終了時に、MGレポートアカウンティング情報がコールの終了時に自動的にコールの終了時に自動的に自動的にアカウンティング情報を報告することを指定します。

d. Specifically support collection of:

d. 具体的には次のようにサポートしています。

* start and stop time, by media flow,

* メディアフローによる開始時間と停止時間、

* volume of content carried (e.g. number of packets/cells transmitted, number received with and without error, inter-arrival jitter), by media flow,

* 運ばれたコンテンツの量(たとえば、送信されたパケット/セルの数、エラーなしの有無にかかわらず受け取った数、攻撃間ジッター)、メディアフローによる、

* QOS statistics, by media flow.

* QoS統計、メディアフローによる。

e. Allow the MGC to have some control over which statistics are reported, to enable it to manage the amount of information transferred.

e. MGCが報告される統計を何らかの制御できるようにして、転送される情報の量を管理できるようにします。

5.8. Signalling Control
5.8. 信号制御

Establishment and provisioning of signalling backhaul channels (via SIGTRAN for example) is out of scope. However, the MG must be capable of supporting detection of events, and application of signals associated with basic analogue line, and CAS type signalling. The protocol must:

シグナリングバックホールチャネルの確立とプロビジョニング(たとえば、Sigtranを介して)は範囲外です。ただし、MGは、イベントの検出、および基本的なアナログラインに関連する信号の適用、およびCASタイプのシグナルをサポートできる必要があります。プロトコルは次のとおりです。

a. Support the signalling requirements of analogue lines and Channel Associated Signaling (CAS).

a. アナログラインとチャネル関連シグナル伝達(CAS)のシグナリング要件をサポートします。

b. Support national variations of such signalling.

b. このようなシグナル伝達の国家的バリエーションをサポートします。

c. Provide mechanisms to support signalling without requiring MG-MGC timing constraints beyond that specified in this document.

c. このドキュメントで指定されているものを超えて、MGCタイミングの制約を必要とせずに信号をサポートするメカニズムを提供します。

d. Must not create a situation where the MGC and the MG must be homologated together as a mandatory requirement of using the protocol;

d. プロトコルを使用するための必須要件として、MGCとMGが一緒に同社をソコールする必要がある状況を作成してはなりません。

i.e. it must be possible to optionally conceal signaling type variation from the MGC.

つまり、MGCからのシグナリングタイプの変動をオプションで隠すことが可能である必要があります。

6. Resource Control
6. リソース制御
6.1. Resource Status Management
6.1. リソースステータス管理

The protocol must:

プロトコルは次のとおりです。

a. Allow the MG to report changes in status of physical entities supporting bearer terminations, media resources, and facility-associated signalling channels, due to failures, recovery, or administrative action. It must be able to report whether a termination is in service or out of service.

a. MGが、障害、回復、または管理措置により、ベアラーの終了、メディアリソース、および施設関連のシグナリングチャネルをサポートする物理エンティティの状況の変化を報告できるようにします。終了が使用されているのか、それとも使用されていないのかを報告できる必要があります。

b. Support administrative blocking and release of TDM circuit terminations.

b. TDM回路終了の管理ブロッキングとリリースをサポートします。

Note: as the above point only relates to ISUP-controlled circuits, it may be unnecessary to require this since the MGC controls their use. However, it may be meaningful for MF and R2-signalled trunks, where supervisory states are set to make the trunks unavailable at the far end.

注:上記のポイントはISUP制御回路にのみ関連しているため、MGCが使用を制御しているため、これを要求する必要はありません。ただし、MFおよびR2署名のトランクにとって意味のあるものである可能性があります。このトランクでは、監督状態が遠端でトランクを利用できないように設定されています。

c. Provide a method for the MGC to request that the MG release all resources under the control of a particular MGC currently in use, or reserved, for any or all connections.

c. MGCが、現在使用されている特定のMGCまたは予約されているすべてのリソースを、いずれかまたはすべての接続に対して制御するすべてのリソースをリリースすることを要求する方法を提供します。

d. Provide an MG Resource Discovery mechanism which must allow an MGC to discover what resources the MG has. Expressing resources can be an arbitrarily difficult problem and the initial release of the protocol may have a simplistic view of resource discovery.

d. MGCがMGのリソースを発見できるようにする必要があるMGリソース発見メカニズムを提供します。リソースを表現することは任意に困難な問題になる可能性があり、プロトコルの最初のリリースは、リソースの発見の単純な見解を持っている可能性があります。

At a minimum, resource discovery must enumerate the names of available circuit terminations and the allowed values for parameters supported by terminations.

少なくとも、リソースの発見は、利用可能な回路終了の名前と、終端によってサポートされるパラメーターの許可された値を列挙する必要があります。

The protocol should be defined so that simple gateways could respond with a relatively short, pre-stored response to the discovery request mechanism. In general, if the protocol defines a mechanism that allows the MGC to specify a setting or parameter for a resource or connection in the MG, and MGs are not required to support all possible values for that setting or parameter, then the discovery mechanism should provide the MGC with a method to determine what possible values such settings or parameters are supported in a particular MG.

単純なゲートウェイが、発見要求メカニズムに対する比較的短い事前に保存された応答で応答できるように、プロトコルを定義する必要があります。一般に、プロトコルがMGCがMGのリソースまたは接続の設定またはパラメーターを指定できるメカニズムを定義し、MGSがその設定またはパラメーターのすべての可能な値をサポートするために必要ではない場合、ディスカバリーメカニズムは提供する必要があります。特定のMgでこのような設定またはパラメーターがサポートされる可能性のある値を決定する方法を備えたMGC。

e. Provide a mechanism to discover the current available resources in the MG, where resources are dynamically consumed by connections and the MGC cannot reasonably or reliably track the consumption of such resources. It should also be possible to discover resources currently in use, in order to reconcile inconsistencies between the MGC and the MG.

e. MGで現在の利用可能なリソースを発見するメカニズムを提供します。ここでは、リソースが接続によって動的に消費され、MGCはそのようなリソースの消費を合理的または確実に追跡できません。また、MGCとMGの間の矛盾を調整するために、現在使用されているリソースを発見することも可能です。

f. Not require an MGC to implement an SNMP manager function in order to discover capabilities of an MG that may be specified during context establishment.

f. コンテキスト確立中に指定される可能性のあるMGの機能を発見するために、SNMPマネージャー関数を実装するためにMGCを要求しません。

6.2. Resource Assignment
6.2. リソースの割り当て

The protocol must:

プロトコルは次のとおりです。

a. Provide a way for the MG to indicate that it was unable to perform a requested action because of resource exhaustion, or because of temporary resource unavailability.

a. MGが、リソースの疲労、または一時的なリソースの利用不能のために、要求されたアクションを実行できないことを示す方法を提供します。

b. Provide an ability for the MGC to indicate to an MG the resource to use for a call (e.g. DS0) exactly, or indicate a set of resources (e.g. pick a DS0 on a T1 line or a list of codec types) via a "wild card" mechanism from which the MG can select a specific resource for a call (e.g. the 16th timeslot, or G.723).

b. MGCがMGに呼び出しに使用するリソース(DS0など)を正確に示す能力を提供するか、「Wild LineでDS0を選択したり、コーデックタイプのリストを選択したりする)のセットを示します。カード「MGが呼び出しの特定のリソースを選択できるメカニズム(例:16th Timeslot、またはG.723)。

c. Allow the use of DNS names and IP addresses to identify MGs and MGCs. This shall not preclude using other identifiers for MGs or MGCs when other non IP transport technologies for the protocol are used.

c. DNS名とIPアドレスの使用を許可して、MGSとMGCを識別します。これは、プロトコルの他の非IP輸送技術を使用する場合、MGまたはMGCの他の識別子を使用することを排除してはなりません。

7. Operational/Management Requirements
7. 運用/管理要件
7.1. Assurance of Control/Connectivity
7.1. 制御/接続の保証

To provide assurance of control and connectivity, the protocol must provide the means to minimize duration of loss of control due to loss of contact, or state mismatches.

制御と接続の保証を提供するために、プロトコルは、接触の喪失または状態の不一致により、制御の喪失期間を最小限に抑える手段を提供する必要があります。

The protocol must:

プロトコルは次のとおりです。

a. Support detection and recovery from loss of contact due to failure/congestion of communication links or due to MG or MGC failure.

a. 通信リンクの障害/混雑による接触の喪失、またはMGまたはMGCの障害によるサポートの検出と回復。

Note that failover arrangements are one of the mechanisms which could be used to meet this requirement.

フェイルオーバー配置は、この要件を満たすために使用できるメカニズムの1つであることに注意してください。

b. Support detection and recovery from loss of synchronized view of resource and connection states between MGCs and MGs. (e.g. through the use of audits).

b. MGCとMGS間のリソースと接続状態の同期ビューの喪失からのサポート検出と回復。(例:監査の使用による)。

c. Provide a means for MGC and MG to provide each other with booting and reboot indications, and what the MG's configuration is.

c. MGCとMGが互いに起動と再起動の表示を提供し、MGの構成とは何かを提供する手段を提供します。

d. Permit more than one backup MGC and provide an orderly way for the MG to contact one of its backups.

d. 複数のバックアップMGCを許可し、MGがバックアップの1つに連絡するための整然とした方法を提供します。

e. Provide for an orderly switchback to the primary MGC after it recovers. How MGCs coordinate resources between themselves is outside the scope of the protocol.

e. 回復後、プライマリMGCへの整然としたスイッチバックを提供します。MGCが自分自身の間でリソースを調整する方法は、プロトコルの範囲外です。

f. Provide a mechanism so that when an MGC fails, connections already established can be maintained. The protocol does not have to provide a capability to maintain connections in the process of being connected, but not actually connected when the failure occurs.

f. MGCが故障した場合、すでに確立された接続を維持できるようにメカニズムを提供します。プロトコルは、接続の過程で接続を維持する機能を提供する必要はありませんが、障害が発生したときに実際に接続されていません。

g. The Protocol must allow the recovery or redistribution of traffic without call loss.

g. プロトコルは、コールロスなしでトラフィックの回復または再分配を可能にする必要があります。

7.2. Error Control
7.2. エラー制御

The protocol must:

プロトコルは次のとおりです。

a. Allow for the MG to report reasons for abnormal failure of lower layer connections e.g. TDM circuit failure, ATM VCC failure.

a. MGが低層接続の異常な障害の理由を報告することを許可します。TDM回路障害、ATM VCC障害。

b. Allow for the MG to report Usage Parameter Control (UPC) events.

b. MGが使用状況パラメーターコントロール(UPC)イベントを報告するようにしてください。

c. Provide means to ameliorate potential synchronization or focused overload of supervisory/signaling events that can be detrimental to either MG or MGC operation. Power restoration or signaling transport re-establishment are typical sources of potentially detrimental signaling showers from MG to MGC or vice-versa.

c. MGまたはMGC操作に有害な可能性のある監督/シグナル伝達イベントの潜在的な同期または集中的な過負荷を改善する手段を提供します。電力回復または信号輸送の再確立は、MGからMGC、またはその逆の潜在的に有害なシグナリングシャワーの典型的なソースです。

d. Allow the MG to notify the MGC that a termination was terminated and communicate a reason when a terminations is taken out-of-service unilaterally by the MG due to abnormal events.

d. MGにMGCに終了が終了されたことを通知し、異常なイベントのためにMGによって終端が一方的に停止された場合の理由を伝えます。

e. Allow the MGC to acknowledge that a termination has been taken out-of-service.

e. MGCが終了がサービス外に採取されたことを認めることを許可します。

f. Allow the MG to request the MGC to release a termination and communicate a reason.

f. MGがMGCに要求して終了を解放し、理由を伝えるようにします。

g. Allow the MGC to specify, as a result of such a request its decision to take termination down, leave it as is or modify it.

g. そのような要求の結果として、MGCが終了を下げるか、そのままにしておくか、修正するかという決定の結果として、MGCを指定させます。

7.3. MIB Requirements
7.3. MIB要件

The Protocol must define a common MG MIB, which must be extensible, but must:

プロトコルは、拡張可能でなければならない一般的なMg MIBを定義する必要がありますが、次のことが必要です。

a. Provide information on:

a. 情報を提供してください:

* mapping between resources and supporting physical entities.

* リソース間のマッピングと物理エンティティのサポート。

* statistics on quality of service on the control and signalling backhaul interfaces.

* 制御およびシグナリングバックホールインターフェイス上のサービス品質に関する統計。

* statistics required for traffic engineering within the MG.

* MG内の交通工学に必要な統計。

b. The protocol must allow the MG to provide to the MGC all information the MGC needs to provide in its MIB.

b. プロトコルは、MGCがMGCがMIBで提供するために必要なすべての情報をMGCに提供できるようにする必要があります。

c. MG MIB must support implementation of H.341 by either the MG, MGC, or both acting together.

c. MG MIBは、MG、MGC、または両方が一緒に作用することにより、H.341の実装をサポートする必要があります。

8. General Protocol Requirements
8. 一般的なプロトコル要件

The protocol must:

プロトコルは次のとおりです。

a. Support multiple operations to be invoked in one message and treated as a single transaction.

a. 複数の操作を1つのメッセージで呼び出し、単一のトランザクションとして扱うようにサポートします。

b. Be both modular and extensible. Not all implementations may wish to support all of the possible extensions for the protocol. This will permit lightweight implementations for specialized tasks where processing resources are constrained. This could be accomplished by defining particular profiles for particular uses of the protocol.

b. モジュラーで拡張可能である。すべての実装が、プロトコルの可能なすべての拡張機能をサポートしたいとは限りません。これにより、処理リソースが制約されている特殊なタスクの軽量実装が可能になります。これは、プロトコルの特定の使用のために特定のプロファイルを定義することで実現できます。

c. Be flexible in allocation of intelligence between MG and MGC. For example, an MGC may want to allow the MG to assign particular MG resources in some implementations, while in others, the MGC may want to be the one to assign MG resources for use.

c. MGとMGC間のインテリジェンスの割り当てに柔軟になります。たとえば、MGCはMGが一部の実装で特定のMGリソースを割り当てることを許可する場合がありますが、他の実装では、MGCは使用するMGリソースを割り当てるものになりたい場合があります。

d. Support scalability from very small to very large MGs: The protocol must support MGs with capacities ranging from one to millions of terminations.

d. 非常に小さいMGから非常に大きなMGからスケーラビリティをサポートします。プロトコルは、1つの終了から数百万の終了容量を持つMGSをサポートする必要があります。

e. Support scalability from very small to very large MGC span of control: The protocol should support MGCs that control from one MG to a few tens of thousands of MGs.

e. 非常に小さいMGCから非常に大きなMGCスパンの制御スパンからスケーラビリティをサポートします。プロトコルは、1 mgから数万Mgを制御するMGCをサポートする必要があります。

f. Support the needs of a residential gateway that supports one to a few lines, and the needs of a large PSTN gateway supporting tens of thousands of lines. Protocol mechanisms favoring one extreme or the other should be minimized in favor of more general purpose mechanism applicable to a wide range of MGs. Where special purpose mechanisms are proposed to optimize a subset of implementations, such mechanisms should be defined as optional, and should have minimal impact on the rest of the protocol.

f. 1列から数行の1行をサポートする住宅のゲートウェイのニーズと、数万回のラインをサポートする大きなPSTNゲートウェイのニーズをサポートします。極端なものを支持するプロトコルメカニズムは、広範囲のMGに適用されるより汎用メカニズムを支持して最小限に抑える必要があります。実装のサブセットを最適化するために特別な目的メカニズムが提案されている場合、そのようなメカニズムはオプションとして定義され、プロトコルの残りの部分に最小限の影響を与える必要があります。

g. Facilitate MG and MGC version upgrades independently of one another. The protocol must include a version identifier in the initial message exchange.

g. MGおよびMGCバージョンを互いに独立してアップグレードします。プロトコルには、最初のメッセージ交換にバージョン識別子を含める必要があります。

h. Facilitate the discovery of the protocol capabilities of the one entity to the other.

h. あるエンティティのプロトコル機能の発見を他のエンティティに促進します。

i. Specify commands as optional (they can be ignored) or mandatory (the command must be rejected), and within a command, to specify parameters as optional (they can be ignored) or mandatory (the command must be rejected).

i. コマンドをオプション(無視できる)または必須(コマンドを拒否する必要がある)、およびコマンド内で、パラメーターをオプション(無視できる)または必須(コマンドを拒否する必要がある)として指定するように指定します。

8.1. MG-MGC Association Requirements
8.1. MG-MGC関連要件

The Protocol must:

プロトコルは次のとおりです。

a. Support the establishment of a control relationship between an MGC and an MG.

a. MGCとMGの間の制御関係の確立をサポートします。

b. Allow multiple MGCs to send control messages to an MG. Thus, the protocol must allow control messages from multiple signalling addresses to a single MG.

b. 複数のMGCがmgに制御メッセージを送信できるようにします。したがって、プロトコルは、複数のシグナル伝達アドレスから単一のmgへの制御メッセージを許可する必要があります。

c. Provide a method for the MG to tell an MGC that the MG received a command for a resource that is under the control of a different MGC.

c. MGがMGCが異なるMGCの制御下にあるリソースのコマンドを受け取ったことをMGCに伝える方法を提供します。

d. Support a method for the MG to control the rate of requests it receives from the MGC (e.g. windowing techniques, exponential back-off).

d. MGがMGCから受け取るリクエストレートを制御する方法をサポートします(例:ウィンドウィングテクニック、指数関数的なバックオフ)。

e. Support a method for the MG to tell an MGC that it cannot handle any more requests.

e. MGがMGCにこれ以上のリクエストを処理できないことを指示する方法をサポートします。

8.2. Performance Requirements
8.2. 性能要件

The protocol must:

プロトコルは次のとおりです。

a. Minimize message exchanges between MG and MGC, for example during boot/reboot, and during continuity tests.

a. MGとMGCの間のメッセージ交換を最小化します。たとえば、ブート/リブート中、および連続性テスト中に。

b. Support Continuity test constraints which are a maximum of 200ms cross-MGC IAM (IAM is the name given to an SS7 connection setup msg) propagation delay, and a maximum of 200ms from end of dialing to IAM emission.

b. 最大200msのクロスMGC IAM(IAMはSS7接続セットアップMSGに与えられた名前)の伝播遅延であり、IAM排出の終わりからIAM排出までの最大200msをサポートする継続性テスト制約をサポートします。

c. Make efficient use of the underlying transport mechanism. For example, protocol PDU sizes vs. transport MTU sizes needs to be considered in designing the protocol.

c. 基礎となる輸送メカニズムを効率的に使用します。たとえば、プロトコルのPDUサイズとトランスポートMTUサイズをプロトコルの設計で考慮する必要があります。

d. Not contain inherent architectural or signaling constraints that would prohibit peak calling rates on the order of 140 calls/second on a moderately loaded network.

d. 適度にロードされたネットワークで140通話/秒でピークコールレートを禁止する固有のアーキテクチャまたはシグナル伝達の制約は含まれていません。

e. Allow for default/provisioned settings so that commands need only contain non-default parameters.

e. コマンドが非デフォルトパラメーターのみを含める必要があるように、デフォルト/プロビジョニング設定を許可します。

9. Transport
9. 輸送
9.1. Assumptions made for underlying network
9.1. 基礎となるネットワークのために行われた仮定

The protocol must assume that the underlying network:

プロトコルは、基礎となるネットワークを想定する必要があります。

a. May be over large shared networks: proximity assumptions are not allowed.

a. 大規模な共有ネットワークを超えている可能性があります:近接仮定は許可されていません。

b. Does not assure reliable delivery of messages.

b. 信頼できるメッセージの配信を保証しません。

c. Does not guarantee ordering of messages: Sequenced delivery of messages associated with the same source of events is not assumed.

c. メッセージの注文を保証するものではありません:同じイベントのソースに関連付けられたメッセージのシーケンスされた配信は想定されていません。

d. Does not prevent duplicate transmissions.

d. 複製トランスミッションを妨げません。

9.2. Transport Requirements
9.2. 輸送要件

The protocol must:

プロトコルは次のとおりです。

a. Provide the ability to abort delivery of obsolete messages at the sending end if their transmission has not been successfully completed. For example, aborting a command that has been overtaken by events.

a. 送信が正常に完了していない場合、送信端で時代遅れのメッセージの配信を中止する機能を提供します。たとえば、イベントによって追い抜かれたコマンドを中止します。

b. Support priority messages: The protocol shall allow a command precedence to allow priority messages to supercede non-priority messages.

b. サポート優先メッセージ:プロトコルは、コマンドの優先順位を許可して、優先順位のないメッセージをスーパーセイクドしていないメッセージを許可するものとします。

c. Support of large fan-out at the MGC.

c. MGCでの大ファンアウトのサポート。

d. Provide a way for one entity to correlate commands and responses with the other entity.

d. 1つのエンティティがコマンドと応答を他のエンティティと相関させる方法を提供します。

e. Provide a reason for any command failure.

e. コマンド障害の理由を提供します。

f. Provide that loss of a packet not stall messages not related to the message(s) contained in the packet lost.

f. 失われたパケットに含まれるメッセージに関連しないメッセージを失速させないパケットの損失を提供します。

Note that there may be enough protocol reliability requirements here to warrant a separate reliable transport layer be written apart from the Media Gateway Control Protocol. Also need to compare Megaco reliable transport requirements with similar Sigtran requirements.

ここには、メディアゲートウェイコントロールプロトコルとは別に、別の信頼できる輸送層を正当化するのに十分なプロトコルの信頼性要件があるかもしれないことに注意してください。また、メガコの信頼できる輸送要件を同様のシグトラン要件と比較する必要があります。

10. Security Requirements
10. セキュリティ要件

Security mechanisms may be specified as provided in underlying transport mechanisms, such as IPSEC. The protocol, or such mechanisms, must:

セキュリティメカニズムは、IPSECなどの基礎となる輸送メカニズムで提供されるように指定される場合があります。プロトコル、またはそのようなメカニズムは、次のことをしなければなりません。

a. Allow for mutual authentication at the start of an MGC-MG association

a. MGC-MG協会の開始時に相互認証を可能にします

b. Allow for preservation of the of control messages once the association has been established.

b. 協会が確立されたら、制御メッセージの保存を許可します。

c. Allow for optional confidentiality protection of control messages. The mechanism should allow a choice in the algorithm to be used.

c. 制御メッセージのオプションの機密保護を許可します。メカニズムにより、アルゴリズムの選択を使用できるようにする必要があります。

d. Operate across untrusted domains in a secure fashion.

d. 信頼されていないドメイン全体で安全な方法で動作します。

e. Support non-repudiation for a customer-located MG talking to a network operator's MGC.

e. ネットワークオペレーターのMGCと話す顧客に配置されたMGの非繰り返しをサポートします。

f. Define mechanisms to mitigate denial of service attacks

f. サービス拒否攻撃を緩和するメカニズムを定義します

Note: the protocol document will need to include an extended discussion of security requirements, offering more precision on each threat and giving a complete picture of the defense including non-protocol measures such as configuration.

注:プロトコルドキュメントには、セキュリティ要件の拡張された議論、各脅威の精度を高め、構成などの非プロトコル測定を含む防衛の完全な画像を提供する必要があります。

g. It would be desirable for the protocol to be able to pass through commonly-used firewalls.

g. プロトコルが一般的に使用されるファイアウォールを通過できることが望ましいでしょう。

11. Requirements specific to particular bearer types
11. 特定のベアラータイプに固有の要件

The bearer types listed in Table 1 can be packaged into different types of MGs. Examples are listed in the following sections. How they are packaged is outside the scope of the general Media Gateway control protocol. The protocol must support all types of bearer types listed in Table 1.

表1にリストされているベアラーの種類は、さまざまなタイプのMGにパッケージ化できます。例を次のセクションに示します。それらのパッケージ化は、一般的なメディアゲートウェイ制御プロトコルの範囲外です。プロトコルは、表1にリストされているすべてのタイプのベアラータイプをサポートする必要があります。

Table 1: Bearer Types and Applications

表1:ベアラーの種類とアプリケーション

     Bearer Type                   Applications       Transit Network
     ================================================================
     Trunk+ISUP                    trunking/access    IP, ATM, FR
                                   Voice,Fax,NAS,
                                   Multimedia
        

Trunk+MF trunking/access IP, ATM, FR Voice,Fax,NAS, Multimedia

トランクMFトランキング/アクセスIP、ATM、FRボイス、ファックス、NAS、マルチメディア

ISDN trunking/access IP, ATM, FR Voice,Fax,NAS, Multimedia

ISDNトランキング/アクセスIP、ATM、FRボイス、ファックス、NAS、マルチメディア

Analogue Voice,Fax, IP, ATM, FR Text Telephony

アナログの音声、FAX、IP、ATM、FRテキストテレフォニー

Termination in a Restricted Voice,Fax, IP, ATM, FR Capability Gateway Text Telephony

制限された音声、FAX、IP、ATM、FR機能ゲートウェイテキストテレフォニーの終了

Application Termination IVR,ARF, Announcement Server, Voice Recognition Server,...

アプリケーション終了IVR、ARF、アナウンスサーバー、音声認識サーバー、...

Multimedia H.323 H.323 Multimedia IP, ATM, FR Gateway and MCU

マルチメディアH.323 H.323マルチメディアIP、ATM、FRゲートウェイ、MCU

Multimedia H.320 H.323 GW and MCU ISDN, IP, ATM, FR

マルチメディアH.320 H.323 GWおよびMCU ISDN、IP、ATM、FR

11.1. Media-specific Bearer Types
11.1. メディア固有のベアラータイプ

This section describes requirements for handling terminations attached to specific types of networks.

このセクションでは、特定の種類のネットワークに添付された終端を処理するための要件について説明します。

11.1.1. Requirements for TDM PSTN (Circuit)
11.1.1. TDM PSTN(回路)の要件

This bearer type is applicable to a Trunking GW, Access GW, ...

このベアラーのタイプは、トランキングGW、アクセスGW、...に適用できます。

The protocol must allow:

プロトコルは許可する必要があります。

a. the MGC to specify the encoding to use on the attached circuit.

a. 接続された回路で使用するエンコードを指定するMGC。

b. In general, if something is set by a global signalling protocol (e.g. ISUP allows mu-Law or A-Law to be signaled using ISUP) then it must be settable by the protocol.

b. 一般に、何かがグローバルなシグナル伝達プロトコルによって設定されている場合(たとえば、ISUPにより、MU-LAWまたはA-LAWをISUPを使用して信号することができます)、プロトコルによって設定可能でなければなりません。

c. TDM attributes:

c. TDM属性:

* Echo cancellation,

* エコー・キャンセリング、

* PCM encoding or other voice compression (e.g. mu-law or A-law),

* PCMエンコーディングまたはその他の音声圧縮(例:MU-LAWまたはA-LAW)、

* encryption,

* 暗号化、

* rate adaptation (e.g. V.110, or V.120).

* レート適応(v.110、またはv.120)。

d. for incoming calls, identification of a specific TDM circuit (timeslot and facility).

d. 着信の場合、特定のTDM回路(タイムスロットと施設)の識別。

e. for calls outgoing to the circuit network, identification of a specific circuit or identification of a circuit group with the indication that the MG must select and return the identification of an available member of that group.

e. 回路ネットワークに発信するコールの場合、特定の回路の識別または回路グループの識別を使用して、MGがそのグループの利用可能なメンバーの識別を選択して返す必要があることを示しています。

f. specification of the default encoding of content passing to and from a given circuit, possibly on a logical or physical circuit group basis.

f. おそらく論理または物理的な回路グループベースで、特定の回路との間で通過するコンテンツのデフォルトのエンコードの指定。

g. specification at any point during the life of a connection of variable aspects of the content encoding, particularly including channel information capacity.

g. 特にチャネル情報容量を含む、コンテンツエンコーディングのさまざまな側面の接続の任意の時点での仕様。

h. specification at any point during the life of a connection of loss padding to be applied to incoming and outgoing media streams at the circuit termination.

h. 回路終了時に着信および発信メディアストリームに適用される損失パディングの接続の任意の時点での仕様。

i. specification at any point during the life of a connection of the applicability of echo cancellation to the outgoing media stream.

i. エコーキャンセルの適用可能性を発信されるメディアストリームに接続する任意の時点での仕様。

j. Multi-rate calls to/from the SCN.

j. SCNへのとfromへの多額の呼び出し。

k. H-channel (n x 64K) calls to/from the SCN.

k. h-channel(n x 64k)は、SCNに出会います。

l. B channel aggregation protocols for creating high speed channels for multimedia over the SCN.

l. Bチャネル集約プロトコルSCNを介したマルチメディア用の高速チャネルを作成するためのプロトコル。

m. Modem terminations and negotiations.

m. モデムの終了と交渉。

The protocol may also allow:

プロトコルも許可する場合があります。

n. specification of sub-channel media streams,

n. サブチャネルメディアストリームの仕様、

o. specification of multi-channel media streams.

o. マルチチャネルメディアストリームの仕様。

11.1.2. Packet Bearer Type
11.1.2. パケットベアラータイプ

The protocol must be able to specify:

プロトコルは次の指定できる必要があります。

a. ingress and egress coding (i.e. the way packets coming in and out are encoded) (including encryption).

a. イングレスと出口コーディング(つまり、パケットが出入りする方法がエンコードされている方法)(暗号化を含む)。

b. near and far-end ports and other session parameters for RTP and RTCP.

b. RTPおよびRTCPの近くおよびファーエンドポートおよびその他のセッションパラメーター。

The protocol must support reporting of:

プロトコルは次のレポートをサポートする必要があります。

c. re-negotiation of codec for cause - for further study

c. 原因のためのコーデックの再交渉 - さらなる研究のため

d. on Trunking and Access Gateways, resources capable of more than one active connection at a time must also be capable of mixing and packet duplication.

d. トランキングおよびアクセスゲートウェイでは、一度に複数のアクティブな接続が可能なリソースも混合とパケットの複製を可能にする必要があります。

The protocol must allow:

プロトコルは許可する必要があります。

e. specification of parameters for outgoing and incoming packet flows at separate points in the life of the connection (because far-end port addresses are typically obtained through a separate signalling exchange before or after the near-end port addresses are assigned).

e. 接続の寿命の別々のポイントで発信および着信パケットが流れるためのパラメーターの仕様(通常、近い端のポートアドレスが割り当てられる前または後に別のシグナリング交換を通じて、ファーエンドポートアドレスが取得されるため)。

f. the possibility for each Media Gateway to allocate the ports on which it will receive packet flows (including RTCP as well as media streams) and report its allocations to the Media Gateway Controller for signalling to the far end. Note that support of different IP backbone providers on a per call basis would require that the ports on which packets flow be selected by the MGC. (but only if the IP address of the MG is different for each backbone provider).

f. 各メディアゲートウェイの可能性は、パケットフロー(RTCPやメディアストリームを含む)を受け取るポートを割り当て、その割り当てをメディアゲートウェイコントローラーに報告して、遠端にシグナリングします。通話ごとに異なるIPバックボーンプロバイダーのサポートには、パケットがMGCによってフローが選択されるポートが必要であることに注意してください。(ただし、MGのIPアドレスがバックボーンプロバイダーごとに異なる場合のみ)。

g. the specification at any point during the life of a connection of RTP payload type and RTP session number for each RTP-encapsulated media flow.

g. 各RTPにカプセル化されたメディアフローのRTPペイロードタイプとRTPセッション番号の接続の任意の時点での仕様。

h. the ability to specify whether outgoing flows are to be uni-cast or multi-cast. Note that on an IP network this information is implicit in the destination address, but in other networks this is a connection parameter.

h. 発信フローがUNI-CASTまたはマルチキャストであるかどうかを指定する機能。IPネットワークでは、この情報は宛先アドレスに暗黙的であるが、他のネットワークではこれは接続パラメーターであることに注意してください。

i. invoking of encryption/decryption on media flows and specification of the associated algorithm and key.

i. メディアフローの暗号化/復号化の呼び出しと、関連するアルゴリズムとキーの仕様。

The protocol should also allow:

プロトコルも許可する必要があります。

j. the MGC to configure non-RTP (proprietary or other) encapsulated packet flows.

j. 非RTP(独自またはその他)カプセル化されたパケットフローを構成するMGC。

11.1.3. Bearer type requirements for ATM
11.1.3. ATMのベアラータイプ要件
   This bearer type is applicable to Trunking GW, Access GW, ....
        
11.1.3.1. Addressing
11.1.3.1. アドレッシング

a. The protocol must be able to specify the following termination attributes:

a. プロトコルは、次の終了属性を指定できる必要があります。

* VC identifier,

* VC識別子、

* VC identifier plus AAL2 slot, and variant of these allowing the gateway to choose (part of) the identifier,

* VC識別子とAAL2スロット、およびこれらのバリアントにより、ゲートウェイが識別子を選択できます。

* remote termination network address, remote MG name.

* リモート終端ネットワークアドレス、リモートMG名。

b. Allow specification of an ATM termination which is to be assigned to an MG connection as a VC identifier, a VC identifier plus AAL2 slot, a wild-carded variant of either of these. A remote termination network address, or a remote MG name could also be used when the MG can select the VC and change the VC during the life of the connection by using ATM signalling.

b. VC識別子としてMG接続に割り当てられるATM終端の指定、VC識別子とAAL2スロット、これらのいずれかのワイルドカードバリアントを許可します。MGがVCを選択して、ATMシグナルを使用して接続の寿命中にVCを変更できる場合、リモート終了ネットワークアドレス、またはリモートMG名も使用できます。

c. Provide an indication by the MG of the VC identifier and possibly AAL2 slot of the termination actually assigned to a connection.

c. VC識別子のMgと、実際に接続に割り当てられた終了のAAL2スロットの兆候を提供します。

d. Provide a means to refer subsequently to that termination.

d. その後、その終了を参照する手段を提供します。

e. Refer to an existing VCC as the physical interface + Virtual Path Identifier (VPI) + Virtual Circuit Identifier (VCI).

e. 既存のVCCを物理インターフェイス仮想パス識別子(VPI)仮想回路識別子(VCI)として参照してください。

f. Where the VCC is locally established (SVCs signalled by the Gateway through UNI or PNNI signalling or similar), the VCC must be indirectly referred to in terms which are of significance to both ends of the VCC. For example, a global name or the ATM address of the ATM devices at each end of the VCC. However, it is possible/probable that there may be several VCCs between a given pair of ATM devices. Therefore the ATM address pair must be further resolved by a VCC identifier unambiguous within the context of the ATM address pair.

f. VCCがローカルに確立されている場合(UNIまたはPNNIシグナル伝達などを介したゲートウェイによってシグナルがあります)、VCCは、VCCの両端に重要な用語で間接的に言及する必要があります。たとえば、VCCの両端にあるATMデバイスのグローバル名またはATMアドレス。ただし、特定のATMデバイスの間にいくつかのVCCが存在する可能性があります。したがって、ATMアドレスペアは、ATMアドレスペアのコンテキスト内で明確なVCC識別子によってさらに解決する必要があります。

g. refer to a VCC as the Remote GW ATM End System Address + VCCI.

g. VCCをリモートGW ATMエンドシステムアドレスVCCIとして参照してください。

h. allow the VCCI to be selected by the MG or imposed on the MG.

h. VCCIをMGで選択するか、Mgに課されます。

i. support all ATM addressing variants (e.g. ATM End System Address (AESA) and E.164).

i. すべてのATMアドレス指定バリアント(例:ATMエンドシステムアドレス(AESA)およびE.164)をサポートします。

11.1.3.2. 接続関連要件

The protocol must:

プロトコルは次のとおりです。

a. Allow for the de-coupling of creation/deletion of the narrow-band connection from the creation/deletion of the underlying VCC.

a. 基礎となるVCCの作成/削除からの狭帯域接続の作成/削除のカップリングを可能にします。

b. Allow for efficient disconnection of all connections associated with a physical port or VCC. As an example, this could aggregate disconnections across a broadband circuit which experienced a physical error.

b. 物理ポートまたはVCCに関連付けられたすべての接続の効率的な切断を可能にします。例として、これにより、物理的なエラーが発生したブロードバンド回路全体に切断が集まる可能性があります。

c. Allow the connection established using this protocol to be carried over a VCC, which may be a:

c. このプロトコルを使用して確立された接続がVCCの上に運ばれるようにします。これは次のとおりです。

* PVC or SPVC,

* PVCまたはSPVC、

* an SVC established on demand, either by the MGC itself or by a broker acting on its behalf or,

* MGC自体またはその代わりに行動するブローカーによって、オンデマンドで確立されたSVCまたは

* an SVC originated as required by the local MG, or by the remote end to the local MG through UNI or PNNI signalling.

* SVCは、ローカルMGの要求に応じて、またはUNIまたはPNNIシグナルを介してローカルMGにリモートエンドから発信されました。

d. Allow ATM transport parameters and QoS parameters to be passed to the MG.

d. ATM輸送パラメーターとQoSパラメーターをMGに渡すことを許可します。

e. Allow blocking and unblocking of a physical interface, a VCC or an AAL1/AAL2 channel.

e. 物理インターフェイス、VCC、またはAAL1/AAL2チャネルのブロッキングとブロッキングを許可します。

The protocol should:

プロトコルは次のようにする必要があります。

f. Where a VCC is required to be established on a per narrow-band call basis, allow all necessary information to be passed in one message.

f. VCCが狭帯域ごとの呼び出しベースで確立される必要がある場合、必要なすべての情報を1つのメッセージに渡すことができます。

11.1.3.3. Media adaptation
11.1.3.3. メディアの適応

The protocol must:

プロトコルは次のとおりです。

a. Allow AAL parameters to be passed to the MG.

a. AALパラメーターをMgに渡すことを許可します。

b. Allow AAL1/AAL2 multiple narrow-band calls to be mapped to a single VCC. For AAL2, these calls are differentiated within each VCC by a AAL2 channel identifier. An AAL2 connection may span more than 1 VCC and transit AAL2 switching devices. ITU Q.2630.1 [2] defines an end-to-end identifier called the Served User Generated Reference (SUGR). It carries information from the originating user of the AAL2 signalling protocol to the terminating user transparently and unmodified.

b. AAL1/AAL2複数の狭帯域呼び出しを単一のVCCにマッピングできるようにします。AAL2の場合、これらの呼び出しは、各VCC内でAAL2チャネル識別子によって区別されます。AAL2接続は、1つ以上のVCCおよびTransit AAL2スイッチングデバイスにまたがる場合があります。ITU Q.2630.1 [2]は、SERTユーザー生成リファレンス(SUGR)と呼ばれるエンドツーエンド識別子を定義します。AAL2シグナル伝達プロトコルの発信元ユーザーから、終了ユーザーに透過的かつ変更されていない情報を提供します。

c. Allow unambiguous binding of a narrow band call to an AAL2 connection identifier, or AAL1 channel, within the specified VCC.

c. 指定されたVCC内で、AAL2接続識別子またはAAL1チャネルへの狭いバンドコールの明確なバインディングを許可します。

d. Allow the AAL2 connection identifier, or AAL1 channel, to be selected by the MG or imposed on the MG.

d. AAL2接続識別子、またはAAL1チャネルをMGによって選択するか、Mgに課されるようにします。

e. Allow the use of the AAL2 channel identifier (cid) instead of the AAL2 connection identifier.

e. AAL2接続識別子の代わりに、AAL2チャネル識別子(CID)の使用を許可します。

f. Allow the AAL2 voice profile to be imposed or negotiated before the start of the connection. AAL2 allows for variable length packets and varying packet rates, with multiple codecs possible within a given profile. Thus a given call may upgrade or downgrade the codec within the lifetime of the call. Idle channels may generate zero bandwidth. Thus an AAL2 VCC may vary in bandwidth and possibly exceed its contract. Congestion controls within a gateway may react to congestion by modifying codec rates/types.

f. 接続の開始前にAAL2音声プロファイルを課したり交渉したりします。AAL2は、特定のプロファイル内で複数のコーデックを可能にする可変長さパケットとさまざまなパケットレートを可能にします。したがって、特定の呼び出しは、コールの寿命以内にコーデックをアップグレードまたはダウングレードする場合があります。アイドルチャネルは、帯域幅ゼロを生成する場合があります。したがって、AAL2 VCCの帯域幅は異なり、契約を超える可能性があります。ゲートウェイ内の輻輳制御は、コーデックレート/タイプを変更することにより、うっ血に反応する場合があります。

g. Allow the MGC to instruct the MG on how individual narrow-band calls behave under congestion.

g. MGCが、個々の狭帯域の呼び出しが混雑の下でどのように動作するかについてMGに指示できるようにします。

h. Allow for the MGC to specify an AAL5 bearer, with the following choices:

h. MGCがAAL5ベアラーを指定し、次の選択肢を許可します。

* Per ATM Forum standard AF-VTOA-0083 [4],

* ATMフォーラム標準AF-VTOA-0083 [4]、

* RTP with IP/UDP,

* IP/UDPを備えたRTP、

* RTP without IP/IDP per H.323v2 Annex C [5],

* H.323v2 Annex C [5]あたりIP/IDPなしのRTP、

* Compressed RTP per ATM Forum AF-SAA-0124.000 [6].

* ATMフォーラムあたりの圧縮RTP AF-SAA-0124.000 [6]。

i. Allow unambiguous binding of a narrow band call to an AAL1 channel within the specified VCC. (In AAL1, multiple narrow-band calls may be mapped to a single VCC.)

i. 指定されたVCC内のAAL1チャネルへの狭いバンドコールの明確な結合を許可します。(AAL1では、複数の狭帯域呼び出しが単一のVCCにマッピングされる場合があります。)

11.1.3.4. Reporting requirements
11.1.3.4. 報告要件

The protocol should:

プロトコルは次のようにする必要があります。

a. Allow any end-of-call statistics to show loss/restoration of underlying VCC within the calls duration, together with duration of loss.

a. コールの終了統計が、コール期間内に基礎となるVCCの損失/回復を、損失の期間とともに示すことを許可します。

b. Allow notification, as requested by MGC, of any congestion avoidance actions taken by the MG.

b. MGCが要求したように、MGが取った混雑回避措置の通知を許可します。

The protocol must:

プロトコルは次のとおりです。

c. Allow for ATM VCCs or AAL2 channels to be audited by the MGC.

c. ATM VCCSまたはAAL2チャネルをMGCによって監査することを許可します。

d. Allow changes in status of ATM VCCs or AAL2 channels to be notified as requested by the MGC.

d. ATM VCCSまたはAAL2チャネルのステータスの変更が、MGCの要求に応じて通知されるようにします。

e. Allow the MGC to query the resource and endpoint availability. Resources may include VCCs, and DSPs. VCCs may be up or down. End-points may be connection-free, connected or unavailable.

e. MGCがリソースとエンドポイントの可用性を照会できるようにします。リソースには、VCCとDSPが含まれる場合があります。VCCは上下になっている可能性があります。エンドポイントは、接続なし、接続、または利用できない場合があります。

11.1.3.5. Functional requirements
11.1.3.5. 機能要件

The protocol must:

プロトコルは次のとおりです。

a. Allow an MGC to reserve a bearer, and specify a route for it through the network.

a. MGCがベアラーを予約できるようにし、ネットワークを介してそのルートを指定します。

11.2. Application-Specific Requirements
11.2. アプリケーション固有の要件
11.2.1. Trunking Gateway
11.2.1. トランキングゲートウェイ

A Trunking Gateway is an interface between SCN networks and Voice over IP or Voice over ATM networks. Such gateways typically interface to SS7 or other NNI signalling on the SCN and manage a large number of digital circuits.

トランキングゲートウェイは、SCNネットワークとVoice over IPまたはVoice over ATMネットワークの間のインターフェイスです。このようなゲートウェイは通常、SS7またはSCNでの他のNNIシグナル伝達にインターフェイスし、多数のデジタル回路を管理します。

The protocol must:

プロトコルは次のとおりです。

a. Provide circuit and packet-side loopback.

a. 回路とパケットサイドのループバックを提供します。

b. Provide circuit-side n x 64kbs connections.

b. 回路側n x 64kbs接続を提供します。

c. Provide subrate and multirate connections for further study.

c. さらなる研究のために、サブレートとマルチレートの接続を提供します。

d. Provide the capability to support Reporting/generation of per-trunk CAS signalling (DP, DTMF, MF, R2, J2, and national variants).

d. トランクごとのCASシグナル伝達の報告/生成(DP、DTMF、MF、R2、J2、および国家バリアント)をサポートする機能を提供します。

e. Provide the capability to support reporting of detected DTMF events either digit-by-digit, as a sequence of detected digits with a flexible mechanism For the MG to determine the likely end of dial string, or in a separate RTP stream.

e. 検出されたDTMFイベントのレポートをサポートする機能を提供します。MGがダイヤルストリングの可能性のある端を決定する柔軟なメカニズムを備えた一連の検出された数字として、または別のRTPストリームで検出された数字のシーケンスとして提供します。

f. Provide the capability to support ANI and DNIS generation and reception.

f. ANIおよびDNISの生成とレセプションをサポートする機能を提供します。

11.2.2. Access Gateway
11.2.2. アクセスゲートウェイ

An Access Gateway connects UNI interfaces like ISDN (PRI and BRI) or traditional analog voice terminal interfaces, to a Voice over IP or Voice over ATM network, or Voice over Frame Relay network.

アクセスゲートウェイは、ISDN(PRIやBRI)や従来のアナログ音声端子インターフェイスなどのUNIインターフェイスを、IPオーバーボイスオーバーATMネットワークまたはボイスオーバーフレームリレーネットワークに接続します。

The Protocol must:

プロトコルは次のとおりです。

a. Support detection and generation of analog line signaling (hook-state, ring generation).

a. サポート検出とアナログラインシグナル伝達の生成(フック状態、リング生成)。

b. Provide the capability to support reporting of detected DTMF events either digit-by-digit, as a sequence of detected digits with a flexible mechanism For the MG to determine the likely end of dial string, or in a separate RTP stream.

b. 検出されたDTMFイベントのレポートをサポートする機能を提供します。MGがダイヤルストリングの可能性のある端を決定する柔軟なメカニズムを備えた一連の検出された数字として、または別のRTPストリームで検出された数字のシーケンスとして提供します。

c. Not require scripting mechanisms, event buffering, digit map storage when implementing restricted function (1-2 line) gateways with very limited capabilities.

c. スクリプトメカニズム、イベントバッファリング、デジットマップストレージは、非常に限られた機能を備えた制限機能(1-2ライン)ゲートウェイを実装するときに必要ありません。

d. Provide the capability to support CallerID generation and reception.

d. Calleridの生成と受信をサポートする機能を提供します。

Proxying of the protocol is for further study.

プロトコルのプロキシは、さらなる研究のためです。

11.2.3. Trunking/Access Gateway with fax ports
11.2.3. ファックスポート付きのトランキング/アクセスゲートウェイ

a. the protocol must be able to indicate detection of fax media.

a. プロトコルは、ファックスメディアの検出を示すことができなければなりません。

b. the protocol must be able to specify T.38 for the transport of the fax.

b. プロトコルは、FAXの輸送にT.38を指定できる必要があります。

c. the protocol must be able to specify G.711 encoding for transport of fax tones across a packet network.

c. プロトコルは、パケットネットワークを介したファックストーンの輸送のためにG.711エンコードを指定できる必要があります。

11.2.4. Trunking/Access Gateway with text telephone access ports
11.2.4. テキスト電話アクセスポートを備えたトランキング/アクセスゲートウェイ

An access gateway with ports capable of text telephone communication, must provide communication between text telephones in the SCN and text conversation channels in the packet network.

テキスト電話通信が可能なポートを備えたアクセスゲートウェイは、SCNのテキスト電話とパケットネットワークのテキスト会話チャネル間の通信を提供する必要があります。

Text telephone capability of ports is assumed to be possible to combine with other options for calls as described in section 11.2.6 (e.) on "Adaptable NASes".

ポートのテキスト電話能力は、「Adaptable Nases」に関するセクション11.2.6(e。)で説明されているように、呼び出しの他のオプションと組み合わせることができると想定されています。

The port is assumed to adjust for the differences in the supported text telephone protocols, so that the text media stream can be communicated T.140 coded in the packet network without further transcoding [7].

ポートは、サポートされているテキスト電話プロトコルの違いを調整すると想定されているため、テキストメディアストリームは、パケットネットワークでコード化されたT.140をさらにトランスコードせずに通信できます[7]。

The protocol must be capable of reporting the type of text telephone that is connected to the SCN port. The foreseen types are the same as the ones supported by ITU-T V.18: DTMF, EDT, Baudot-45, Baudot-50, Bell, V.21, Minitel and V.18. It should be possible to control which protocols are supported. The SCN port is assumed to contain ITU-T V.18 functionality [8].

プロトコルは、SCNポートに接続されているテキスト電話の種類を報告できる必要があります。予見されるタイプは、ITU-T V.18:DTMF、EDT、Baudot-45、Baudot-50、Bell、V.21、Minitel、V.18でサポートされているタイプと同じです。どのプロトコルがサポートされているかを制御できるはずです。SCNポートには、ITU-T V.18機能が含まれていると想定されています[8]。

The protocol must be able to control the following functionality levels of text telephone support:

プロトコルは、テキスト電話サポートの次の機能レベルを制御できる必要があります。

a. Simple text-only support: The call is set into text mode from the beginning of the call, in order to conduct a text-only conversation.

a. シンプルなテキストのみのサポート:テキストのみの会話を実施するために、通話が通話の先頭からテキストモードに設定されます。

b. Alternating text-voice support: The call may begin in voice mode or text mode and, at any moment during the call, change mode on request by the SCN user. On the packet side, the two media streams for voice and text must be opened, and it must be possible to control the feeding of each stream by the protocol.

b. 交互のテキストボイスサポート:コールは、音声モードまたはテキストモードで開始され、CALL中のいつでもSCNユーザーによるリクエストに応じてモードを変更します。パケット側では、音声とテキスト用の2つのメディアストリームを開く必要があり、プロトコルによって各ストリームの給餌を制御することが可能でなければなりません。

c. Simultaneous text and voice support: The call is performed in a mode when simultaneous text and voice streams are supported. The call may start in voice mode and during the call change state to a text-and-voice call.

c. 同時テキストと音声サポート:コールは、同時テキストと音声ストリームがサポートされているときにモードで実行されます。コールは、音声モードで開始され、コール変更中にテキストとボイスの呼び出しに変更されます。

A port may implement only level a, or any level combination of a, b and c, always including level a.

ポートは、常にレベルAを含むレベルA、またはA、B、Cの任意のレベルの組み合わせのみを実装できます。

The protocol must support:

プロトコルはサポートする必要があります。

d. A text based alternative to the interactive voice response, or audio resource functionality of the gateway when the port is used in text telephone mode.

d. インタラクティブな音声応答に代わるテキストベースの代替、またはポートがテキスト電話モードで使用される場合のゲートウェイのオーディオリソース機能。

e. Selection of what national translation table to be used between the Unicode based T.140 and the 5-7 bit based text telephone protocols.

e. UnicodeベースのT.140と5-7ビットベースのテキスト電話プロトコルの間で使用される国家翻訳テーブルの選択。

f. Control of the V.18 probe message to be used on incoming calls.

f. 着信コールで使用するV.18プローブメッセージの制御。

11.2.5. Network Access Server
11.2.5. ネットワークアクセスサーバー

A NAS is an access gateway, or Media Gateway (MG), which terminates modem signals or synchronous HDLC connections from a network (e.g. SCN or xDSL network) and provides data access to the packet network. Only those requirements specific to a NAS are described here.

NASは、ネットワーク(SCNやXDSLネットワークなど)からモデム信号または同期HDLC接続を終了し、パケットネットワークへのデータアクセスを提供するアクセスゲートウェイ、またはメディアゲートウェイ(MG)です。NASに固有の要件のみがここで説明されています。

Figure 1 provides a reference architecture for a Network Access Server (NAS). Signaling comes into the MGC and the MGC controls the NAS.

図1は、ネットワークアクセスサーバー(NAS)の参照アーキテクチャを示しています。シグナル伝達がMGCに入り、MGCがNASを制御します。

                          +-------+        +-------+
               Signaling  |       |        |       |
               -----------+  MGC  +        |  AAA  |
                          |       |        |       |
                          +---+---+        +--+----+
                              |               |
                        Megaco|_______________|
                                              |
                                              |
                          +---+---+         ~~|~~~
                Bearer    |       |        (      )
               -----------+  NAS  +-------(   IP   )
                          |       |        (      )
                          +-------+         ~~~~~~
        

Figure 1: NAS reference architecture

図1:NASリファレンスアーキテクチャ

The Protocol must support:

プロトコルはサポートする必要があります。

a. Callback capabilities:

a. コールバック機能:

* Callback

* 折り返し電話

b. Modem calls. The protocol must be able to specify the modem type(s) to be used for the call.

b. モデム呼び出し。プロトコルは、呼び出しに使用するモデムタイプを指定できる必要があります。

c. Carriage of bearer information. The protocol must be able to specify the data rate of the TDM connection (e.g., 64 kbit/s, 56 kbit/s, 384 kbit/s), if this is available from the SCN.

c. ベアラー情報のキャリッジ。このプロトコルは、SCNから利用可能な場合、TDM接続のデータレート(たとえば、64 kbit/s、56 kbit/s、384 kbit/s)を指定できる必要があります。

d. Rate Adaptation: The protocol must be able to specify the type of rate adaptation to be used for the call including indicating the subrate, if this is available from the SCN (e.g. 56K, or V.110 signaled in Bearer capabilities with subrate connection of 19.2kbit/s).

d. レートの適応:プロトコルは、SCNから利用可能である場合、サブレートを示すことを含むコールに使用するレート適応のタイプを指定できる必要があります(例:56K、またはv.110は、19.2のサブレート接続を伴うベアラー機能でシグナルkbit/s)。

e. Adaptable NASes: The protocol must be able to support multiple options for an incoming call to allow the NAS to dynamically select the proper type of call. For example, an incoming ISDN call coded for "Speech" Bearer Capability could actually be a voice, modem, fax, text telephone, or 56 kbit/s synchronous call. The protocol should allow the NAS to report back to the MGC the actual type of call once it is detected.

e. 適応性のあるNase:プロトコルは、NASが適切なタイプの呼び出しを動的に選択できるようにするために、着信コールの複数のオプションをサポートできる必要があります。たとえば、「スピーチ」ベアラーの機能にコード化された着信ISDNコールは、実際には音声、モデム、ファックス、テキスト電話、または56 Kbit/s同期コールになる可能性があります。このプロトコルにより、NASは、検出されたら実際のタイプの呼び出しをMGCに報告できるようにする必要があります。

The 4 basic types of bearer for a NAS are:

NASの4つの基本的なタイプのベアラーは次のとおりです。

1. Circuit Mode, 64-kbps, 8-khz structured, Speech

1. 回路モード、64 kbps、8 kHz構造、音声

2. Circuit Mode, 64-kbps, 8-khz structured, 3.1-khz, Audio

2. 回路モード、64-kbps、8 kHz構造、3.1-kHz、オーディオ

3. Circuit Mode, 64-kbps, 8-khz structured, Unrestricted Digital Transmission-Rate Adapted from 56-kbps

3. 回路モード、64 kbps、8 kHz構造、56 kbpsから適応

4. Circuit Mode, 64-kbps, 8-khz structure, Unrestricted Digital Transmission

4. 回路モード、64-kbps、8 kHz構造、無制限のデジタル伝送

f. Passage of Called and Calling Party Number information to the NAS from the MGC. Also, passage of Charge Number/Billing Number, Redirecting Number, and Original Call Number, if known, to the NAS from the MGC. If there are other Q.931 fields that need to be passed from the MGC to the MG, then it should be possible to pass them [9].

f. MGCからのNASへの呼び出しおよび呼び出し党番号情報の通過。また、MGCのNASに、請求番号/請求番号、リダイレクト番号、および元のコール番号の通話番号の通過。MGCからMGに渡す必要がある他のQ.931フィールドがある場合、それらを渡すことができるはずです[9]。

g. Ability for the MGC to direct the NAS to connect to a specific tunnel, for example to an LNS, or to an AAA server.

g. MGCがNASに特定のトンネル、たとえばLNSまたはAAAサーバーに接続するように指示する能力。

h. When asked by the MGC, be able to report capability information, for example, connection types (V.34/V90/Synch ISDN..), AAA mechanism (RADIUS/DIAMETER/..), access type (PPP/SLIP/..) after restart or upgrade.

h. MGCから尋ねられたら、たとえば接続タイプ(v.34/v90/同期isdn ..)、AAAメカニズム(半径/直径/..)、アクセスタイプ(PPP/スリップ/)など、機能情報を報告できます。。)再起動またはアップグレード後。

11.2.6. Restricted Capability Gateway
11.2.6. 制限された機能ゲートウェイ

The requirements here may also be applied to small analog gateways, and to cable/xDSL modems. See also the section on access gateways.

ここでの要件は、小さなアナログゲートウェイ、およびケーブル/XDSLモデムにも適用できます。アクセスゲートウェイのセクションも参照してください。

The Protocol must support:

プロトコルはサポートする必要があります。

a. The ability to provide a scaled down version of the protocol. When features of the protocol are not supported, an appropriate error message must be sent. Appropriate default action must be defined. Where this is defined may be outside the scope of the protocol.

a. スケーリングされたバージョンのプロトコルを提供する機能。プロトコルの機能がサポートされていない場合、適切なエラーメッセージを送信する必要があります。適切なデフォルトアクションを定義する必要があります。これが定義されている場合、プロトコルの範囲外にある場合があります。

b. The ability to provide device capability information to the MGC with respect to the use of the protocol.

b. プロトコルの使用に関して、デバイス機能情報をMGCに提供する機能。

11.2.7. Multimedia Gateway
11.2.7. マルチメディアゲートウェイ

The protocol must have sufficient capability to support a multimedia gateway. H.320 and H.324 are characterized by a single data stream with multiple media streams multiplexed on it.

プロトコルには、マルチメディアゲートウェイをサポートするのに十分な機能が必要です。H.320およびH.324は、複数のメディアストリームが多重化された単一のデータストリームによって特徴付けられます。

If the mapping is from H.320 or H.324 on the circuit side, and H.323 on the packet side, it is assumed that the MG knows how to map respective subchannels from H.320/H.324 side to streams on packet side. If extra information is required when connecting two terminations, then it must be supplied so that the connections are not ambiguous.

マッピングが回路側のh.320またはh.324から、パケット側のh.323からである場合、MGはH.320/H.324側からそれぞれのサブチャネルをマッピングする方法を知っていると想定されています。パケット側。2つの終端を接続するときに追加の情報が必要な場合は、接続が曖昧にならないように提供する必要があります。

The Multimedia Gateway:

マルチメディアゲートウェイ:

1) should support Bonding Bearer channel aggregation,

1) ボンディングベアラーチャネルの集約をサポートする必要があります。

2) must support 2xB (and possibly higher rates) aggregation via H.221,

2) H.221を介した2xB(およびおそらく高いレート)の集約をサポートする必要があります。

3) must be able to dynamically change the size of audio, video and data channels within the h.320 multiplex,

3) H.320マルチプレックス内のオーディオ、ビデオ、およびデータチャネルのサイズを動的に変更できる必要があります。

4) must react to changes in the H.320 multiplex on 20 msec boundaries,

4) 20ミリ秒の境界でのH.320マルチプレックスの変化に反応する必要があります。

5) must support TCS4/IIS BAS commands,

5) TCS4/IIS BASコマンドをサポートする必要があります。

6) must support detection and creation of DTMF tones,

6) DTMFトーンの検出と作成をサポートする必要があります。

7) should support SNMP MIBS as specified in H.341 [3]

7) H.341で指定されているようにSNMP MIBSをサポートする必要があります[3]

a. If some of the above cannot be handled by the MGC to MG protocol due to timing constraints, then it is likely that the H.245 to H.242 processing must take place in the MG. Otherwise, support for this functionality in the multimedia gateway are protocol requirements.

a. タイミングの制約のために上記の一部をMGCからMGへのプロトコルで処理できない場合、H.245からH.242の処理がMGで行われなければならない可能性があります。それ以外の場合、マルチメディアゲートウェイでのこの機能のサポートはプロトコル要件です。

b. It must be possible on a call by call basis for the protocol to specify different applications. Thus, one call might be PSTN to PSTN under SS7 control, while the next might be ISDN/H.320 under SS7 control to H.323. This is only one example; the key requirement is that the protocol not prevent such applications.

b. プロトコルが異なるアプリケーションを指定するには、コールバイコールベースで可能になる必要があります。したがって、1つの呼び出しは、SS7コントロールの下でPSTNへのPSTNである可能性がありますが、次の呼び出しはSS7コントロールのH.323のISDN/H.320である可能性があります。これはほんの一例です。重要な要件は、プロトコルがそのようなアプリケーションを防止しないことです。

11.2.8. Audio Resource Function
11.2.8. オーディオリソース機能

An Audio Resource Function (ARF) consists of one or more functional modules which can be deployed on an stand alone media gateway server IVR, Intelligent Peripheral, speech/speaker recognition unit, etc. or a traditional media gateway. Such a media gateway is known as an Audio Enabled Gateway (AEG) if it performs tasks defined in one or more of the following ARF functional modules:

オーディオリソース関数(ARF)は、スタンドアロンメディアゲートウェイサーバーIVRに展開できる1つ以上の機能モジュール、インテリジェント周辺、音声/スピーカー認識ユニットなど、または従来のメディアゲートウェイで構成されています。このようなメディアゲートウェイは、次のARF機能モジュールの1つ以上で定義されたタスクを実行する場合、オーディオ対応ゲートウェイ(AEG)として知られています。

Play Audio, DTMF Collect, Record Audio, Speech Recognition, Speaker Verification/Identification, Auditory Feature Extraction/Recognition, or Audio Conferencing.

オーディオ、DTMFの収集、レコードオーディオ、音声認識、スピーカーの検証/識別、聴覚機能の抽出/認識、またはオーディオ会議を再生します。

Additional ARF function modules that support human to machine communications through the use of telephony tones (e.g., DTMF) or auditory means (e.g. speech) may be appended to the AEG definition in future versions of these requirements.

テレフォニートーン(例:DTMF)または聴覚手段(たとえば、音声)を使用してヒトから機械への通信をサポートする追加のARF関数モジュールは、これらの要件の将来のバージョンのAEG定義に追加される場合があります。

Generic scripting packages for any module must support all the requirements for that module. Any package extension for a given module must include, by inheritance or explicit reference, the requirements for that given module.

任意のモジュールの汎用スクリプトパッケージは、そのモジュールのすべての要件をサポートする必要があります。特定のモジュールのパッケージ拡張機能は、継承または明示的な参照によって、特定のモジュールの要件を含める必要があります。

The protocol requirements for each of the ARF modules are provided in the following subsections.

各ARFモジュールのプロトコル要件は、以下のサブセクションで提供されます。

11.2.8.1. Play Audio Module
11.2.8.1. オーディオモジュールを再生します

a. Be able to provide the following basic operation:

a. 次の基本操作を提供できます。

- request an ARF MG to play an announcement.

- ARF MGを要求して、発表をプレイします。

b. Be able to specify these play characteristics:

b. これらのプレイ特性を指定できる:

- Play volume

- ボリュームを再生します

- Play speed

- スピードをプレイします

- Play iterations

- イテレーションを再生します

- Interval between play iterations

- 再生反復間の間隔

- Play duration

- プレイ期間

c. Permit the specification of voice variables such as DN, number, date, time, etc. The protocol must allow specification of both the value (eg 234-3456), and well as the type (Directory number).

c. DN、番号、日付、時刻などの音声変数の仕様を許可します。プロトコルは、値(例えば234-3456)とタイプ(ディレクトリ番号)の両方の指定を許可する必要があります。

d. Using the terminology that a segment is a unit of playable speech, or is an abstraction that is resolvable to a unit of playable speech, permit specification of the following segment types:

d. セグメントが再生可能なスピーチの単位であるという用語を使用するか、プレイ可能なスピーチの単位に対して解決可能な抽象化であり、次のセグメントタイプの指定を許可します。

- A provisioned recording.

- プロビジョニング録音。

- A block of text to be converted to speech.

- 音声に変換されるテキストのブロック。

- A block of text to be displayed on a device.

- デバイスに表示されるテキストのブロック。

- A length of silence qualified by duration.

- 期間までに資格のある沈黙の長さ。

- An algorithmically generated tone.

- アルゴリズム的に生成されたトーン。

- A voice variable, specified by type and value. Given a variable type and value, the IVR/ARF unit would dynamically assemble the phrases required for its playback.

- タイプと値で指定された音声変数。可変タイプと値を考えると、IVR/ARFユニットは、再生に必要なフレーズを動的に組み立てます。

- An abstraction that represents a sequence of audio segments. Nesting of these abstractions must also be permitted.

- 一連のオーディオセグメントを表す抽象化。これらの抽象化のネストも許可する必要があります。

An example of this abstraction is a sequence of audio segments, the first of which is a recording of the words "The number you have dialed", followed by a Directory Number variable, followed by a recording of the words "is no longer in service".

この抽象化の例は、一連のオーディオセグメントであり、最初は「ダイヤルした番号」という単語の記録で、その後にディレクトリ番号変数が続き、その後に「単語の録音」が使用されます。「。

- An abstraction that represents a set of audio segments and which is resolved to a single segment by a qualifier. Nesting of these abstractions must be permitted.

- 一連のオーディオセグメントを表し、予選によって単一のセグメントに解決される抽象化。これらの抽象化のネストは許可する必要があります。

For example take a set of audio segments recorded in different languages all of which express the semantic concept "The number you have dialed is no longer in service". The set is resolved by a language qualifier. If the qualifier is "French", the set resolves to the French version of this announcement.

たとえば、さまざまな言語で記録されたオーディオセグメントのセットをすべて撮影します。これらはすべて、「ダイヤルした数はもはやサービスを提供していない」という意味の概念を表します。このセットは、言語修飾子によって解決されます。予選者が「フランス語」の場合、セットはこの発表のフランス語版に解決します。

In the case of a nested abstraction consisting of a set qualified by language at one level and and a set qualified by gender at another level, it would be possible to specify that an announcement be played in French and spoken by a female voice.

あるレベルで言語で資格を与えられ、別のレベルで性別によって資格のあるセットで構成されるセットで構成されるネストされた抽象化の場合、発表がフランス語で行われ、女性の声で話されることを指定することが可能です。

e. Provide two different methods of audio specification:

e. オーディオ仕様の2つの異なる方法を提供します。

- Direct specification of the audio components to be played by specifying the sequence of segments in the command itself.

- コマンド自体のセグメントのシーケンスを指定することにより、再生されるオーディオコンポーネントの直接仕様。

- Indirect specification of the audio components to be played by reference to a single identifier that resolves to a provisioned sequence of audio segments.

- プロビジョニングされた一連のオーディオセグメントに解決する単一の識別子を参照して再生されるオーディオコンポーネントの間接的な仕様。

11.2.8.2. DTMF Collect Module
11.2.8.2. DTMF収集モジュール

The DTMF Collect Module must support all of the requirements in the Play Module in addition to the following requirements:

DTMF収集モジュールは、次の要件に加えて、Playモジュールのすべての要件をサポートする必要があります。

a. Be able to provide the following basic operation:

a. 次の基本操作を提供できます。

- request an AEG to play an announcement, which may optionally terminated by DTMF, and then collect DTMF

- aegを要求してアナウンスを再生します。これは、オプションでdtmfによって終了し、DTMFを収集する場合があります

b. Be able to specify these event collection characteristics:

b. これらのイベントコレクションの特性を指定できます。

- The number of attempts to give the user to enter a valid DTMF pattern.

- 有効なDTMFパターンを入力するためにユーザーに提供する試みの数。

c. With respect to digit timers, allow the specification of:

c. 数字タイマーに関しては、次の仕様を許可します。

- Time allowed to enter the first digit.

- 最初の数字を入力するのが許可されています。

- Time allowed for user to enter each digit subsequent to the first digit.

- ユーザーが最初の数字に続いて各数字を入力するのが許可されました。

- Time allowed for user to enter a digit once the maximum expected number of digits has been entered.

- ユーザーが最大予想桁数が入力されたら、桁を入力する時間が許可されます。

d. To be able to allow multiple prompt operations DTMF digit collection, voice recording (if supported), and/or speech recognition analysis (if supported) provide the following types of prompts:

d. 複数のプロンプト操作DTMFデジットコレクション、音声録音(サポートされている場合)、および/または音声認識分析(サポートされている場合)を許可できるように、次の種類のプロンプトが提供されます。

- Initial Prompt

- 初期プロンプト

- Reprompt

- 再繰り返し

- Error prompt

- エラープロンプト

- Failure announcement

- 失敗の発表

- Success announcement.

- 成功の発表。

e. To allow digit pattern matching, allow the specification of:

e. 数字パターンの一致を許可するには、次の仕様を許可します。

- maximum number of digits to collect.

- 収集する最大数字数。

- minimum number of digits to collect.

- 収集する最小数字の数。

- a digit pattern using a regular expression.

- 正規表現を使用した数字パターン。

f. To allow digit buffer control, allow the specification of:

f. 桁バッファ制御を許可するには、次の仕様を許可します。

- Ability to clear digit buffer prior to playing initial prompt (default is not to clear buffer).

- 最初のプロンプトを再生する前に桁バッファーをクリアする機能(デフォルトはバッファをクリアしないことです)。

- Default clearing of buffer following playing of un-interruptible announcement segment.

- インターデッド可能なアナウンスセグメントの再生後のバッファーのデフォルトのクリア。

- Default clearing of buffer before playing a re-prompt in response to previous invalid input.

- 以前の無効な入力に応じて再採用する前のバッファーのデフォルトクリアリング。

g. Provide a method to specify DTMF interruptibility on a per audio segment basis.

g. オーディオセグメントごとにDTMF割り込み性を指定する方法を提供します。

h. Allow the specification of definable key sequences for DTMF digit collection to:

h. DTMFデジットコレクションの定義可能なキーシーケンスの指定を次のように許可します。

- Discard collected digits in progress, replay the prompt, and resume DTMF digit collection.

- 収集された数字を進行し、プロンプトを再生し、DTMFディジットコレクションを再開します。

- Discard collected digits in progress and resume DTMF digit collection.

- 進行中の収集された数字を破棄し、DTMFディジットコレクションを再開します。

- Terminate the current operation and return the terminating key sequence to the MGC.

- 現在の操作を終了し、MGCの終了キーシーケンスを返します。

i. Provide a way to ask the ARF MG to support the following definable keys for digit collection and recording. These keys would then be able to be acted upon by the ARF MG:

i. ARF MGに、次の定義可能なキーをデジットの収集と記録にサポートするように依頼する方法を提供します。これらのキーは、ARF MGによって行動することができます。

- A key to terminate playing of an announcement in progress.

- 進行中の発表のプレイを終了するための鍵。

- A set of one or more keys that can be accepted as the first digit to be collected.

- 収集される最初の数字として受け入れることができる1つ以上のキーのセット。

- A key that signals the end of user input. The key may or may not be returned to the MGC along with the input already collected.

- ユーザー入力の終わりを通知するキー。キーは、すでに収集された入力とともに、MGCに返される場合とされない場合があります。

- Keys to stop playing the current announcement and resume playing at the beginning of the first segment of the announcement, last segment of the announcement, previous segment of the announcement, next segment of the announcement, or the current announcement segment.

- 発表の最初のセグメントの開始時に現在の発表を再開し、再開する鍵、発表の最後のセグメント、発表の以前のセグメント、発表の次のセグメント、または現在の発表セグメント。

11.2.8.3. Record Audio Module
11.2.8.3. オーディオモジュールを記録します

The Record Module must support all of the requirements in the Play Module as in addition to the following requirements:

レコードモジュールは、次の要件に加えて、再生モジュール内のすべての要件をサポートする必要があります。

a. Be able to provide the following basic operation:

a. 次の基本操作を提供できます。

- request an AEG to play an announcement and then record voice.

- AEGをリクエストしてアナウンスをプレイしてから、音声を記録します。

b. Be able to specify these event collection characteristics:

b. これらのイベントコレクションの特性を指定できます。

- The number of attempts to give the user to make a recording.

- ユーザーに録音を作成する試みの数。

c. With respect to recording timers, allow the specification of:

c. タイマーの記録に関しては、次の仕様を許可します。

- Time to wait for the user to initially speak.

- ユーザーが最初に話すのを待つ時間です。

- The amount of silence necessary following the last speech segment for the recording to be considered complete.

- 録音が完全に見なされるために最後のスピーチセグメントに続いて必要な沈黙の量。

- The maximum allowable length of the recording (not including pre- and post- speech silence).

- 録音の最大許容長さ(発話前と音声後の沈黙は含まれません)。

d. To be able to allow multiple prompt operations for DTMF digit collection (if supported), voice recording (if supported), speech recognition analysis (if supported) and/or speech verification/identification (if supported) and then to provide the following types of prompts:

d. DTMFデジットコレクション(サポートされている場合)、音声録音(サポートされている場合)、音声認識分析(サポートされている場合)、および/または音声検証/識別(サポートされている場合)の複数のプロンプト操作を許可できるように、次のタイプのタイプを提供できます。プロンプト:

- Initial Prompt

- 初期プロンプト

- Reprompt

- 再繰り返し

- Error prompt

- エラープロンプト

- Failure announcement

- 失敗の発表

- Success announcement.

- 成功の発表。

e. Allow the specification of definable key sequences for digit recording or speech recognition analysis (if supported) to:

e. 数字記録または音声認識分析(サポートされている場合)の定義可能なキーシーケンスの指定を次のように許可します。

- Discard recording in progress, replay the prompt, and resume recording.

- 進行中の録音を破棄し、プロンプトを再生し、録音を再開します。

- Discard recording in progress and resume recording.

- 進行中の録音を破棄し、録音を再開します。

- Terminate the current operation and return the terminating key sequence to the MGC.

- 現在の操作を終了し、MGCの終了キーシーケンスを返します。

f. Provide a way to ask the ARF MG to support the following definable keys for recording. These keys would then be able to be acted upon by the ARF MG:

f. ARF MGに、録音用の次の定義可能なキーをサポートするように依頼する方法を提供します。これらのキーは、ARF MGによって行動することができます。

- A key to terminate playing of an announcement in progress.

- 進行中の発表のプレイを終了するための鍵。

- A key that signals the end of user input. The key may or may not be returned to the MGC along with the input already collected.

- ユーザー入力の終わりを通知するキー。キーは、すでに収集された入力とともに、MGCに返される場合とされない場合があります。

- Keys to stop playing the current announcement and resume playing at the beginning of the first segment of the announcement, last segment of the announcement, previous segment of the announcement, next segment of the announcement, or the current announcement segment.

- 発表の最初のセグメントの開始時に現在の発表を再開し、再開する鍵、発表の最後のセグメント、発表の以前のセグメント、発表の次のセグメント、または現在の発表セグメント。

g. While audio prompts are usually provisioned in IVR/ARF MGs, support changing the provisioned prompts in a voice session rather than a data session. In particular, with respect to audio management:

g. 通常、オーディオプロンプトはIVR/ARF MGSでプロビジョニングされますが、データセッションではなく音声セッションでプロビジョニングされたプロンプトの変更をサポートします。特に、オーディオ管理に関して:

- A method to replace provisioned audio with audio recorded during a call. The newly recorded audio must be accessible using the identifier of the audio it replaces.

- コール中に記録されたオーディオにプロビジョニングされたオーディオを置き換える方法。新しく録音されたオーディオは、交換するオーディオの識別子を使用してアクセスできる必要があります。

- A method to revert from replaced audio to the original provisioned audio.

- 交換されたオーディオから元のプロビジョニングオーディオに戻す方法。

- A method to take audio recorded during a call and store it such that it is accessible to the current call only through its own newly created unique identifier.

- 通話中に録音されたオーディオを撮影し、それを保存する方法で、現在の呼び出しにアクセスできるようにして、新しく作成された独自の一意の識別子を介してのみアクセスできます。

- A method to take audio recorded during a call and store it such that it is accessible to any subsequent call through its own newly created identifier.

- 通話中に録音されたオーディオを撮影し、それを保存する方法により、新しく作成された独自の識別子を介して後続の呼び出しにアクセスできるようにします。

11.2.8.4. Speech Recognition Module
11.2.8.4. 音声認識モジュール

The speech recognition module can be used for a number of speech recognition applications, such as:

音声認識モジュールは、次のような多くの音声認識アプリケーションに使用できます。

- Limited Vocabulary Isolated Speech Recognition (e.g., "yes", "no", the number "four"),

- 限られた語彙隔離された音声認識(例:「はい」、「いいえ」、数字「4」)、

- Limited Vocabulary Continuous Speech Feature Recognition (e.g., the utterance "four hundred twenty-three dollars"),and/or

- 限られた語彙連続音声機能認識(たとえば、「43ドルの43ドル」)、および/または

- Continuous Speech Recognition (e.g., unconstrained speech recognition tasks).

- 継続的な音声認識(例:制約のない音声認識タスク)。

The Speech Recognition Module must support all of the requirements in the Play Module as in addition to the following requirements:

音声認識モジュールは、次の要件に加えて、再生モジュールのすべての要件をサポートする必要があります。

a. Be able to provide the following basic operation: request an AEG to play an announcement and then perform speech recognition analysis.

a. 次の基本的な操作を提供できるようにします。AEGを要求してアナウンスをプレイし、音声認識分析を実行します。

b. Be able to specify these event collection characteristics:

b. これらのイベントコレクションの特性を指定できます。

- The number of attempts to give to perform speech recognition task.

- 音声認識タスクを実行するための試みの数。

c. With respect to speech recognition analysis timers, allow the specification of:

c. 音声認識分析タイマーに関しては、次の仕様を許可します。

- Time to wait for the user to initially speak.

- ユーザーが最初に話すのを待つ時間です。

- The amount of silence necessary following the last speech segment for the speech recognition analysis segment to be considered complete.

- 音声認識分析セグメントの最後の音声セグメントに続いて必要とされる沈黙の量。

- The maximum allowable length of the speech recognition analysis (not including pre- and post- speech silence).

- 音声認識分析の最大許容長さ(前後の沈黙と後の沈黙は含まれません)。

d. To be able to allow multiple prompt operations for DTMF digit collection (if supported), voice recording (if supported), and/or speech recognition analysis and then to provide the following types of prompts:

d. DTMFデジットコレクション(サポートされている場合)、音声録音(サポートされている場合)、および/または音声認識分析の複数のプロンプト操作を許可し、次のタイプのプロンプトを提供できるようにします。

- Initial Prompt

- 初期プロンプト

- Reprompt

- 再繰り返し

- Error prompt

- エラープロンプト

- Failure announcement

- 失敗の発表

- Success announcement.

- 成功の発表。

e. Allow the specification of definable key sequences for digit recording (if supported) or speech recognition analysis to:

e. 数字記録(サポートされている場合)または音声認識分析の定義可能なキーシーケンスの指定を次のように許可します。

- Discard in process analysis, replay the prompt, and resume analysis.

- プロセス分析で廃棄し、プロンプトを再生し、分析を再開します。

- Discard recording in progress and resume analysis.

- 進行中の記録を破棄し、分析を履歴します。

- Terminate the current operation and return the terminating key sequence to the MGC.

- 現在の操作を終了し、MGCの終了キーシーケンスを返します。

f. Provide a way to ask the ARF MG to support the following definable keys for speech recognition analysis. These keys would then be able to be acted upon by the ARF MG:

f. ARF MGに、音声認識分析のために次の定義可能なキーをサポートするように依頼する方法を提供します。これらのキーは、ARF MGによって行動することができます。

- A key to terminate playing of an announcement in progress.

- 進行中の発表のプレイを終了するための鍵。

- A key that signals the end of user input. The key may or may not be returned to the MGC along with the input already collected.

- ユーザー入力の終わりを通知するキー。キーは、すでに収集された入力とともに、MGCに返される場合とされない場合があります。

- Keys to stop playing the current announcement and resume playing at the beginning of the first segment of the announcement, last segment of the announcement, previous segment of the announcement, next segment of the announcement, or the current announcement segment.

- 発表の最初のセグメントの開始時に現在の発表を再開し、再開する鍵、発表の最後のセグメント、発表の以前のセグメント、発表の次のセグメント、または現在の発表セグメント。

11.2.8.5. Speaker Verification/Identification Module
11.2.8.5. スピーカー検証/識別モジュール

The speech verification/identification module returns parameters that indicate either the likelihood of the speaker to be the person that they claim to be (verification task) or the likelihood of the speaker being one of the persons contained in a set of previously characterized speakers (identification task).

音声検証/識別モジュールは、スピーカーが自分が主張する人物である可能性(検証タスク)であるか、スピーカーが以前に特徴付けられたスピーカーのセットに含まれる人の1人である可能性のいずれかを示すパラメーターを返します(識別タスク)。

The Speaker Verification/Identification Module must support all of the requirements in the Play Module in addition to the following requirements:

スピーカーの検証/識別モジュールは、次の要件に加えて、再生モジュールのすべての要件をサポートする必要があります。

a. Be able to download parameters, such as speaker templates (verification task) or sets of potential speaker templates (identification task), either prior to the session or in mid-session.

a. セッション前またはセッション中のいずれかで、スピーカーテンプレート(検証タスク)や潜在的なスピーカーテンプレートのセット(識別タスク)などのパラメーターをダウンロードできます。

b. Be able to download application specific software to the ARF either prior to the session or in mid-session.

b. セッション前またはセッション中のいずれかで、アプリケーション固有のソフトウェアをARFにダウンロードできます。

c. Be able to return parameters indicating either the likelihood of the speaker to be the person that they claim to be (verification task) or the likelihood of the speaker being one of the persons contained in a set of previously characterized speakers (identification task).

c. スピーカーが(検証タスク)と主張する人物である可能性を示すパラメーターを返すことができます。

d. Be able to provide the following basic operation: request an AEG to play an announcement and then perform speech verification/identification analysis.

d. 次の基本的な操作を提供できるようにします。AEGを要求してアナウンスを再生し、音声検証/識別分析を実行します。

e. Be able to specify these event collection characteristics: The number of attempts to give to perform speech verification/identification task.

e. これらのイベントコレクションの特性を指定できます。音声検証/識別タスクを実行する試みの数。

f. With respect to speech verification/identification analysis timers, allow the specification of:

f. 音声検証/識別分析タイマーに関しては、次の仕様を許可します。

- Time to wait for the user to initially speak.

- ユーザーが最初に話すのを待つ時間です。

- The amount of silence necessary following the last speech segment for the speech verification/identification analysis segment to be considered complete.

- 音声検証/識別分析セグメントの最後の音声セグメントに続く必要な沈黙の量。

- The maximum allowable length of the speech verification/identification analysis (not including pre- and post- speech silence).

- 音声検証/識別分析の最大許容長さ(発話前および音声後の沈黙は含まれません)。

g. To be able to allow multiple prompt operations for DTMF digit collection (if supported), voice recording, (if supported), speech recognition analysis (if supported) and/or speech verification/identification and provide the following types of prompts:

g. DTMFデジットコレクション(サポートされている場合)、音声録音(サポートされている場合)、音声認識分析(サポートされている場合)、および/または音声検証/識別の複数のプロンプト操作を許可できるように、次のタイプのプロンプトを提供できます。

- Initial Prompt

- 初期プロンプト

- Reprompt

- 再繰り返し

- Error prompt

- エラープロンプト

- Failure announcement

- 失敗の発表

- Success announcement.

- 成功の発表。

h. Allow the specification of definable key sequences for digit recording (if supported) or speech recognition (if supported) in the speech verification/identification analysis to:

h. スピーチ検証/識別分析で、数字記録(サポートされている場合)または音声認識(サポートされている場合)の定義可能なキーシーケンスの指定を次のように許可します。

- Discard speech verification/identification in analysis, replay the prompt, and resume analysis.

- 分析の音声検証/識別を廃棄し、プロンプトを再生し、分析を再開します。

- Discard speech verification/identification analysis in progress and resume analysis.

- 進行中の音声検証/識別分析を廃棄し、分析を履歴します。

- Terminate the current operation and return the terminating key sequence to the MGC.

- 現在の操作を終了し、MGCの終了キーシーケンスを返します。

i. Provide a way to ask the ARF MG to support the following definable keys for speech verification/identification analysis. These keys would then be able to be acted upon by the ARF MG:

i. ARF MGに、音声検証/識別分析のために次の定義可能なキーをサポートするように依頼する方法を提供します。これらのキーは、ARF MGによって行動することができます。

- A key to terminate playing of an announcement in progress.

- 進行中の発表のプレイを終了するための鍵。

- A key that signals the end of user input. The key may or may not be returned to the MGC along with the input already collected.

- ユーザー入力の終わりを通知するキー。キーは、すでに収集された入力とともに、MGCに返される場合とされない場合があります。

- Keys to stop playing the current announcement and resume speech verification/identification at the beginning of the first segment of the announcement, last segment of the announcement, previous segment of the announcement, next segment of the announcement, or the current announcement segment.

- 現在の発表の再生を停止し、発表の最初のセグメントの先頭、発表の最後のセグメント、発表の前のセグメント、発表の次のセグメント、または現在の発表セグメントで音声検証/識別を再開する鍵。

11.2.8.6. Auditory Feature Extraction/Recognition Module
11.2.8.6. 聴覚特徴抽出/認識モジュール

The auditory feature extraction/recognition module is engineered to continuously monitor the auditory stream for the appearance of particular auditory signals or speech utterances of interest and to report these events (and optionally a signal feature representation of these events) to network servers or MGCs.

聴覚機能の抽出/認識モジュールは、特定の聴覚信号または関心のある音声の発現の外観について聴覚ストリームを継続的に監視し、これらのイベント(およびオプションではこれらのイベントの信号表現)をネットワークサーバーまたはMGCに報告するように設計されています。

The Auditory Feature Extraction/Recognition Module must support the following requirements:

聴覚機能抽出/認識モジュールは、次の要件をサポートする必要があります。

a. Be able to download application specific software to the ARF either prior to the session or in mid-session.

a. セッション前またはセッション中のいずれかで、アプリケーション固有のソフトウェアをARFにダウンロードできます。

b. Be able to download parameters, such as a representation of the auditory feature to extract/recognize, for prior to the session or in mid-session.

b. セッション前またはセッション中に、抽出/認識する聴覚機能の表現などのパラメーターをダウンロードできます。

c. Be able to return parameters indicating the auditory event found or a representation of the feature found (i.e., auditory feature).

c. 見つかった聴覚イベントまたは見つかった機能の表現を示すパラメーターを返すことができます(つまり、聴覚機能)。

11.2.8.7. Audio Conferencing Module
11.2.8.7. オーディオ会議モジュール

The protocol must support:

プロトコルはサポートする必要があります。

a. a mechanism to create multi-point conferences of audio only and multimedia conferences in the MG.

a. MGでオーディオのみとマルチメディア会議のマルチポイント会議を作成するメカニズム。

b. audio mixing; mixing multiple audio streams into a new composite audio stream

b. オーディオミキシング;複数のオーディオストリームを新しいコンポジットオーディオストリームに混ぜる

c. audio switching; selection of incoming audio stream to be sent out to all conference participants.

c. オーディオスイッチング;すべての会議参加者に送信される着信オーディオストリームの選択。

11.2.9. Multipoint Control Units
11.2.9. マルチポイント制御ユニット

The protocol must support:

プロトコルはサポートする必要があります。

a. a mechanism to create multi-point conferences of audio only and multimedia conferences in the MG.

a. MGでオーディオのみとマルチメディア会議のマルチポイント会議を作成するメカニズム。

b. audio mixing; mixing multiple audio streams into a new composite audio stream

b. オーディオミキシング;複数のオーディオストリームを新しいコンポジットオーディオストリームに混ぜる

c. audio switching; selection of incoming audio stream to be sent out to all conference participants.

c. オーディオスイッチング;すべての会議参加者に送信される着信オーディオストリームの選択。

d. video switching; selection of video stream to be sent out to all conference participants

d. ビデオの切り替え;すべての会議参加者に送信されるビデオストリームの選択

e. lecture video mode; a video selection option where on video source is sent out to all conference users

e. 講義ビデオモード。ビデオソースがすべての会議ユーザーに送信されるビデオ選択オプション

f. multi-point of T.120 data conferencing.

f. T.120データ会議のマルチポイント。

g. The ability for the MG to function as an H.323 MP, and for the MGC to function as an H.323 MC, connected by this protocol (MEGACOP/H.248). It should be possible for audio, data, and video MG/MPs to be physically separate while being under the control of a single MGC/H.323 MC.

g. MGがH.323 MPとして機能し、MGCがこのプロトコル(Megacop/H.248)で接続されたH.323 MCとして機能する能力。単一のMGC/H.323 MCの制御下にある間に、オーディオ、データ、ビデオMG/MPSが物理的に分離される可能性があります。

12. References
12. 参考文献

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[2] ITU-T Recommendation Q.2630.1, AAL type 2 Signalling Protocol (Capability Set 1), December 1999.

[2] ITU-T推奨Q.2630.1、AALタイプ2シグナル伝達プロトコル(機能セット1)、1999年12月。

[3] ITU-T Recommendation H.341, Line Transmission of Non-Telephone Signals, May 1999.

[3] ITU-T推奨H.341、非テレフォン信号のライン伝送、1999年5月。

[4] ATM Forum Technical Committee, af-vtoa-0083.001, Voice and Telephony Over ATM to the Desktop Specification, March 1999.

[4] ATMフォーラムテクニカル委員会、AF-VTOA-0083.001、1999年3月、デスクトップ仕様へのATM上の音声およびテレフォニー。

[5] ITU-T Recommendation H.323v3, Packet-based Multimedia Communications Systems (includes Annex C - H.323 on ATM), September 1999.

[5] 1999年9月、パケットベースのマルチメディアコミュニケーションシステム(ANMEX C-H.323を含む)、パケットベースのマルチメディア通信システム(Annex C-H.323を含む)、ITU-Tの推奨事項。

[6] ATM Forum Technical Committee, af-saa-0124.000, Gateway for H.323 Media Transport Over ATM, May 1999.

[6] ATMフォーラム技術委員会、AF-SAA-0124.000、1999年5月、ATM上のH.323メディア輸送のゲートウェイ。

[7] ITU-T Recommendation T.140, Protocol for Multimedia Application Text Conversation, February 1998.

[7] ITU-T推奨T.140、マルチメディアアプリケーションテキスト会話のプロトコル、1998年2月。

[8] ITU-T Recommendation V.18, Operational and Interworking Requirements for DCEs Operating in Text Telephone Mode, February 1998.

[8] ITU-Tの推奨V.18、1998年2月、テキスト電話モードで動作するDCEの運用およびインターワーキング要件。

[9] ITU-T Recommendation Q.931, Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN User - Network Interface Layer 3 Specification for Basic Call Control, May 1998.

[9] ITU -Tの推奨Q.931、デジタルサブスクライバーシグナル伝達システムNo. 1(DSS 1) - ISDNユーザー - ネットワークインターフェイスレイヤー3基本コールコントロールの仕様、1998年5月。

14. Acknowledgements
14. 謝辞

The authors would like to acknowledge the many contributors who debated the Media Gateway Control Architecture and Requirements on the IETF Megaco and Sigtran mailing lists. Contributions to this document have also been made through internet-drafts and discussion with members of ETSI Tiphon, ITU-T SG16, TIA TR41.3.4, the ATM Forum, and the Multiservice Switching Forum.

著者は、IETF MegacoおよびSigtranのメーリングリストに関するメディアゲートウェイ制御アーキテクチャと要件について議論した多くの貢献者を認めたいと考えています。この文書への貢献は、インターネットドラフトとETSI Tiphon、ITU-T SG16、TIA TR41.3.4、ATMフォーラム、およびマルチサービススイッチングフォーラムのメンバーとの議論を通じても行われています。

15. Authors' Addresses
15. 著者のアドレス

Nancy Greene Nortel Networks P.O. Box 3511 Stn C Ottawa, ON, Canada K1Y 4H7

ナンシーグリーンノルテルネットワークP.O.Box 3511 Stn C Ottawa、ON、カナダK1Y 4H7

Phone: (514) 271-7221 EMail: ngreene@nortelnetworks.com

電話:(514)271-7221メール:ngreene@nortelnetworks.com

Michael A. Ramalho Cisco Systems 1802 Rue de la Port Wall Township, NJ

マイケルA.ラマルホシスコシステム1802ニュージャージー州ポートウォールタウンシップ

   Phone: +1.732.449.5762
   EMail: mramalho@cisco.com
        

Brian Rosen Marconi 1000 FORE Drive, Warrendale, PA 15086

ブライアン・ローゼン・マルコーニ1000フォアドライブ、ペンシルベニア州ワーレンデール15086

Phone: (724) 742-6826 EMail: brosen@eng.fore.com

電話:(724)742-6826メール:brosen@eng.fore.com

16. 完全な著作権声明

Copyright (C) The Internet Society (2000). All Rights Reserved.

Copyright(c)The Internet Society(2000)。無断転載を禁じます。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。