RFC2805 日本語訳
2805 Media Gateway Control Protocol Architecture and Requirements. N.Greene, M. Ramalho, B. Rosen. April 2000. (Format: TXT=88190 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group N. Greene
Request for Comments: 2805 Nortel Networks
Category: Informational M. Ramalho
Cisco Systems
B. Rosen
Marconi
April 2000
コメントを求めるワーキンググループN.グリーン要求をネットワークでつないでください: 2805 ノーテルはカテゴリをネットワークでつなぎます: 情報のM.のRamalhoシスコシステムズB.ローゼンマルコニー2000年4月
Media Gateway Control Protocol Architecture and Requirements
メディアゲートウェイ制御プロトコルアーキテクチャと要件
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document describes protocol requirements for the Media Gateway Control Protocol between a Media Gateway Controller and a Media Gateway.
このドキュメントはメディアゲートウェイControllerとメディアゲートウェイの間のメディアゲートウェイControlプロトコルのためのプロトコル要件について説明します。
Greene, et al. Informational [Page 1] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[1ページ]の2805mgのRFC制御プロトコル要件2000年4月
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. 序論… 3 2. 用語… 3 3. 定義… 3 4. MGの中で想定された特定の機能… 5 5. 1呼び出しあたりの要件… 6 5.1. リソース予約… 6 5.2. 接続要件… 7 5.3. メディア変換… 8 5.4. 信号/イベント処理とスクリプティング… 9 5.5. QoS/CoS… 10 5.6. サポートをテストしてください… 11 5.7. 会計… 11 5.8. 合図コントロール… 11 6. リソースコントロール… 12 6.1. リソース状態管理… 12 6.2. リソース課題… 13 7. 操作上の/管理要件… 13 7.1. コントロール/接続性の保証… 13 7.2. 誤り制御… 14 7.3. MIB要件… 15 8. 一般プロトコル要件… 15 8.1. mg-MGC協会要件… 16 8.2. パフォーマンス要件… 17 9. 輸送… 17 9.1. 仮定は基本的なネットワークになりました… 17 9.2. 要件を輸送してください… 18 10. セキュリティ要件… 18 11. 特定の運搬人タイプに、特定の要件… 19 11.1. メディア特有のBearerはタイプします… 20 11.1.1. TDM PSTN(回路)のための要件… 20 11.1.2. パケットBearerはタイプします… 22 11.1.3. ATMのための運搬人タイプ要件… 23 11.2. アプリケーション決められた一定の要求… 26 11.2.1. 中継方式ゲートウェイ… 26 11.2.2. ゲートウェイにアクセスしてください… 27 11.2.3. ファックスポートがある中継方式/アクセスゲートウェイ… 27 11.2.4. テキスト電話がある中継方式/アクセスゲートウェイ… 28 11.2.5. アクセス・サーバーをネットワークでつないでください… 29 11.2.6. 能力ゲートウェイを制限します… 30 11.2.7. マルチメディアゲートウェイ… 31 11.2.8. オーディオリソース機能… 32 11.2.9. 多点制御装置… 42 12. 参照… 43 13. 承認… 43 14. 作者のアドレス… 44 15. 完全な著作権宣言文… 45
Greene, et al. Informational [Page 2] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[2ページ]の2805mgのRFC制御プロトコル要件2000年4月
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.
このドキュメントはメディアゲートウェイControlプロトコルに置かれるという要件について説明します。 単語プロトコルがそれ自身のところで使用されるとき、本書ではそれはそれとなくメディアゲートウェイControlプロトコルを意味します。
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.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは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.
メディアゲートウェイController(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)の機能は潜在的に異なったネットワークの間のメディアマッピング、そして/または、コード変換機能を提供します。パケット、フレームまたはそれの1つはあえてネットワークのためにセルネットワークでつながれること。 例えば、MGは交換回線網ネットワーク(SCN)施設(トランクス、輪)を終えて、それが既にpacketizedされないならメディアストリームをpacketizeして、packetizedトラフィックをパケット網に提供するかもしれません。 それはパケット網から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.
メディアGatewaysはSCN<->パケット/フレーム/セル機能に制限されません: すべてのパケットインタフェースがあるカンフェレンス・ブリッジはMGであるかもしれません、(IVR)対話的な音声認識ユニット、オーディオのリソース機能、またはセルインタフェースがある音声認識システムと同様に。
Greene, et al. Informational [Page 3] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[3ページ]の2805mgのRFC制御プロトコル要件2000年4月
* Media Gateway unit (MG-unit)
* メディアゲートウェイ部隊(黄疸指数)
An MG-unit is a physical entity that contains an MG function and may also contain other functions, e.g. an SG function.
黄疸指数はMG機能を含んでいて、また他の機能(例えば、SG機能)を含むかもしれない物理的実体です。
* Media Gateway Controller (MGC) function
* メディアゲートウェイController(MGC)機能
A Media Gateway Controller (MGC) function controls a MG.
メディアゲートウェイController(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機能は系列に関連しているプロセスSCN合図かMGによって制御されたトランク終了へのMG機能のコレジデントであるかもしれません、ISDN PRIトランクの「D」チャンネルなどのように。
* 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.
Bearer定義のTypeは特定用途/運搬人タイプのための詳細な要件を提供します。 例えば、メディアゲートウェイの特定のクラスは特定のBearerタイプをサポートするでしょう。
Greene, et al. Informational [Page 4] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[4ページ]の2805mgのRFC制御プロトコル要件2000年4月
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.
このセクションは一般的なメディアゲートウェイControlプロトコル要件の定義に環境を提供します。
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.
(必要なら、)メディア変換とコード変換がどこで実行されるかによる多くの異なった道、会議がリソースのプログラマビリティ、どうサポートされるかに関するレベルでMGsをarchitectedされることができて、関連合図がどのように扱われるかをそうされます。 機能は、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での発表を提供できるでしょう。 さらに、この違いは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によって直接扱われません)。
Greene, et al. Informational [Page 5] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[5ページ]の2805mgのRFC制御プロトコル要件2000年4月
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)
* 合図逆送を構成する能力(例えば、Sigtran逆送)
* 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. 1呼び出しあたりの要件
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。 メッセージ、与えられた数の終了の間の特定のセットの接続性、そして/または、関係に関連しているすべてのリソースのただ一つの交換におけるリリースを許してください。
Greene, et al. Informational [Page 6] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[6ページ]の2805mgのRFC制御プロトコル要件2000年4月
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、Analogue、ATM、IPまたはFR輸送にかかわる接続をサポートしてください。
c. Allow the specification of bearer plane (e.g. Frame Relay, IP,
etc.) on a call by call basis.
c。 呼び出しのときに呼び出し基礎で運搬人飛行機(例えば、Frame Relay、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。 より複雑な流れtopologiesの作成と変更に例えばカンフェレンス・ブリッジ能力をサポートしてください。 呼び出しかセッションからの/に関係者を呼び出しかセッションの間、メディアストリームを加えるか、または削除できてください、そして、加えるか、または引き算できてください。
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を指定させてください。
Greene, et al. Informational [Page 7] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[7ページ]の2805mgのRFC制御プロトコル要件2000年4月
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。 音声帯域トラフィックとしてテキスト電話/FAX/データモデム通信がメディア流動でMGによってMGで終えられるか、調節されるか、または反調節されて、パケットに変換されるか、または送られるかことであるとMGCを指定させてください。
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。 これらのケタ/信号/トーンがDual-トーンMultiFrequency(DTMF)ケタか他の系列と、トランク信号と一般的なMulti頻度(MF)トーンがMGで処理されることであると指定するMGCとどう扱われるかことであることを許容してください。 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ストリーム(例えばDTMFケタはオーディオRTPストリームから別々のRTPペイロードで発信した)の一部として分析して、発信しました。
5. Taken from a separate RTP stream and inserted in the line-side
audio stream.
5. 別々のRTPストリームから取られて、系列サイドオーディオストリームに挿入されます。
Greene, et al. Informational [Page 8] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[8ページ]の2805mgのRFC制御プロトコル要件2000年4月
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. 指示のスクリプトによると、扱われます。 最初のケース以外のすべてにおいて、沈黙、安らぎ雑音、または他の手段(例えば、いくつかの電話トーンのV字形の切込みフィルタリング)でケタ/信号/トーンに音を消すオプションを提供しなければなりません。 これらのイベントの検出が最大何十ミリセカンドもと同じくらい取るとき、ケタ/信号/トーンについて確かめることができる前に、オーディオ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-法/a法を指定させてください。
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 AAL2適合から例えば、パケット/セル輸送適合中流(パケットからパケット)transpacketization/コード変換だけ、またはATM AAL5を考慮してください。
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が明確にイベント通知を承諾する方法を提供してください。
Greene, et al. Informational [Page 9] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[9ページ]の2805mgのRFC制御プロトコル要件2000年4月
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登録手順で実装の定義されたイベントと信号に拡張機能を供給してください。 登録メカニズムの一部としてOrganizational Identifier(すなわち、ITU、ETSI、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。 MGsの間と、そして、方向で接続に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チャンネルに関するジターバッファパラメタは接続設定で指定させられてください。
Greene, et al. Informational [Page 10] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[10ページ]の2805mgのRFC制御プロトコル要件2000年4月
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。 起因するのと終わりの両方のための(COT)が終わらせる回路接続(2ワイヤと4ワイヤ)のPSTN Continuity Testingの異なったタイプのサポート。
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は、MGが呼び出しの終わりに自動的に課金情報を報告すると指定してください、要求の中間の呼び出しで、MGCとMGCによる指定されるとしてのユニット用法敷居における指定されるとしての特定の時間間隔で。
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。 アナログ系列とChannel Associated Signaling(CAS)の合図要件をサポートしてください。
Greene, et al. Informational [Page 11] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[11ページ]の2805mgのRFC制御プロトコル要件2000年4月
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。 本書では指定されたそれを超えてMG- 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を一緒にhomologatedしなければならない状況を作成してはいけません。
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が、MGがすべてのリソースを発表するよう要求するメソッドを提供してください。
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 Resourceディスカバリーメカニズムを提供してください。 リソースを言い表すのは、任意に難しい問題であるかもしれません、そして、プロトコルの初期のリリースには、リソース発見の安易な視点があるかもしれません。
At a minimum, resource discovery must enumerate the names of
available circuit terminations and the allowed values for
parameters supported by terminations.
最小限では、リソース発見は終了でサポートされたパラメタのために利用可能な回線終端と許容値の名前を列挙しなければなりません。
Greene, et al. Informational [Page 12] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[12ページ]の2805mgのRFC制御プロトコル要件2000年4月
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。 メカニズムを提供します。(そこでは、MGCはMGで現在の利用可能資源を発見してください、そして、リソースが接続によってダイナミックに消費されて、そのようなリソースの消費を合理的か確かに追跡できません)。 また、現在使用中のリソースを発見するのも可能であるべきです、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の能力を発見するのにMGCがSNMPマネージャ機能を実装するのが必要ではありません。
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が要求(例えば、DS0)にまさに使用するリソースをMGに示す能力を提供するか、またはMGが要求(例えば、16番目のtimeslot、またはG.723)のための特定のリソースを選択できる「ワイルドカード」メカニズムで1セットのリソース(例えば、T1系列かコーデックタイプのリストでDS0を選ぶ)を示してください。
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とMGCsを特定させてください。 これは、プロトコルのための他の非IP輸送技術が使用されているとき、MGsかMGCsに他の識別子を使用するのを排除しないものとします。
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.
コントロールと接続性の保証を提供するために、プロトコルは接触、または州のミスマッチの損失による制御不能の持続時間を最小にする手段を提供しなければなりません。
Greene, et al. Informational [Page 13] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[13ページ]の2805mgのRFC制御プロトコル要件2000年4月
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。 リソースの連動している視点の損失からの検出と回復とMGCsと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。 1バックアップMGCを可能にしてください、そして、MGに規則的な道で備えて、バックアップのひとりに連絡してください。
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に規則的なジグザグの山道に備えてください。 プロトコルの範囲の外にMGCsがどう自分たちの間のリソースを調整するかがあります。
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がUsage Parameter Control(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までの潜在的に有害なシグナリングシャワーの典型的な源であるか逆もまた同様です。
Greene, et al. Informational [Page 14] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[14ページ]の2805mgのRFC制御プロトコル要件2000年4月
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。 終了をリリースして、理由を伝えるようMGCにMGを要求させてください。
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にそのような要求の結果、終了を降ろすという決定を指定させるか、そのままでそれを残すか、またはそれを変更してください。
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。 プロトコルで、MGは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。 モジュールであって、かつ広げることができてください。 すべての実装がプロトコルのための可能な拡大のすべてをサポートしたがっているかもしれないというわけではありません。 これは処理リソースが制約つきである専門化しているタスクのために軽量の実装を可能にするでしょう。 プロトコルの特定の用途のための特定のプロフィールを定義することによって、これを達成できるでしょう。
Greene, et al. Informational [Page 15] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[15ページ]の2805mgのRFC制御プロトコル要件2000年4月
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。 非常に小さいMGsから非常に大きいMGsまでスケーラビリティをサポートしてください: 能力が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管理限界までスケーラビリティをサポートしてください: プロトコルは、1MGから何万数MGsまでMGCsがそのコントロールであるとサポートするべきです。
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つをサポートする住宅のゲートウェイの必要性、および何万もの系列をサポートする大きいPSTNゲートウェイの必要性をサポートしてください。 1つの極端かもう片方を支持するプロトコルメカニズムはさまざまなMGsに適切なより汎用のメカニズムを支持して最小にされるべきです。 専用メカニズムが実装の部分集合を最適化するために提案されるところでは、そのようなメカニズムは、任意であると定義されるべきであり、プロトコルの残りに最小量の影響力を持っているはずです。
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。 1つの実体のプロトコル能力の発見をもう片方に容易にしてください。
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。 複数のMGCsにコントロールメッセージをMGに送らせてください。 したがって、プロトコルは複数の合図アドレスから独身のMGまでのコントロールメッセージを許容しなければなりません。
Greene, et al. Informational [Page 16] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[16ページ]の2805mgのRFC制御プロトコル要件2000年4月
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が、MGが異なった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。 Continuityテストが最大200ms十字-MGC IAM(IAMはSS7接続設定msgへの付与という名前である)伝播遅延と、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。 保証がメッセージを注文して、そうしません: イベントの同じ源に関連しているメッセージの配列された配送は想定されません。
Greene, et al. Informational [Page 17] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[17ページ]の2805mgのRFC制御プロトコル要件2000年4月
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。 優先権がメッセージであるとサポートしてください: コマンド先行はプロトコルでsupercede非至急メッセージに至急メッセージを許容できるものとします。
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.
別々の信頼できるトランスポート層がメディアゲートウェイControlプロトコルは別として書かれているのを保証するというここのプロトコル信頼度要求事項が十分あるかもしれないことに注意してください。 また、Megacoの信頼できる輸送要件を同様のSigtran要件と比べるのが必要です。
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。 信頼されていないドメインの向こう側に安全なファッションで作動してください。
Greene, et al. Informational [Page 18] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[18ページ]の2805mgのRFC制御プロトコル要件2000年4月
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.
Table1に記載された運搬人タイプはMGsの異なったタイプにパッケージできます。 例は以下のセクションでリストアップされています。 一般的なメディアゲートウェイ制御プロトコルの範囲の外にそれらがどうパッケージされるかがあります。 プロトコルはTable1に記載されたすべてのタイプの運搬人タイプをサポートしなければなりません。
Greene, et al. Informational [Page 19] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[19ページ]の2805mgのRFC制御プロトコル要件2000年4月
Table 1: Bearer Types and Applications
テーブル1: 運搬人タイプとアプリケーション
Bearer Type Applications Transit Network
================================================================
Trunk+ISUP trunking/access IP, ATM, FR
Voice,Fax,NAS,
Multimedia
運搬人タイプアプリケーショントランジットネットワーク================================================================ トランク+ISUP中継方式/アクセスIP、ATM、FR Voice、ファックス、NAS、Multimedia
Trunk+MF trunking/access IP, ATM, FR
Voice,Fax,NAS,
Multimedia
トランク+MF中継方式/アクセスIP、ATM、FR Voice、ファックス、NAS、Multimedia
ISDN trunking/access IP, ATM, FR
Voice,Fax,NAS,
Multimedia
ISDN中継方式/アクセスIP、ATM、FR Voice、ファックス、NAS、Multimedia
Analogue Voice,Fax, IP, ATM, FR
Text Telephony
アナログ声、ファックス、IP、気圧、FRテキスト電話
Termination in a Restricted Voice,Fax, IP, ATM, FR
Capability Gateway Text Telephony
制限された声、ファックス、IP、気圧、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、気圧、FRゲートウェイ、およびMCU
Multimedia H.320 H.323 GW and MCU ISDN, IP, ATM, FR
マルチメディアのH.320 H.323GWとMCU ISDN、IP、気圧、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, ...
この運搬人タイプはTrunking GW、Access 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は、μ法かA-法が合図されるのをISUPを使用することで許容します)、プロトコルで「舗装用敷石-可能」でなければなりません。
Greene, et al. Informational [Page 20] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[20ページ]の2805mgのRFC制御プロトコル要件2000年4月
c. TDM attributes:
c。 TDM属性:
* Echo cancellation,
* キャンセルをまねてください。
* PCM encoding or other voice compression (e.g. mu-law or A-law),
* PCMコード化か他の声の圧縮(例えば、μ法かA-法)
* 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回路(timeslotと施設)の識別のために。
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からの/に呼びます。
k. H-channel (n x 64K) calls to/from the SCN.
k。 H-チャンネル(n x64K)はSCNからの/に呼びます。
l. B channel aggregation protocols for creating high speed channels
for multimedia over the SCN.
l。 マルチメディアのための高速チャンネルをSCNの上に創造するためのBチャネル集合プロトコル。
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. マルチチャンネルメディアの仕様は流れます。
Greene, et al. Informational [Page 21] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[21ページ]の2805mgのRFC制御プロトコル要件2000年4月
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. また、TrunkingとAccess Gatewaysでは、一度に1つ以上の活発な接続ができるリソースも混合とパケット重複ができなければなりません。
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を含んでいる)を受けて、遠端に合図するためにメディアゲートウェイControllerに配分を報告するポートを割り当てる可能性。 呼び出し基礎あたりのaにおける異なった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. 外向的な流れがユニキャストかそれともマルチキャストであるかことであると指定する能力。 この情報が送付先アドレスでIPネットワークでは、暗に示されていますが、他のネットワークでは、これが接続パラメタであることに注意してください。
i. invoking of encryption/decryption on media flows and
specification of the associated algorithm and key.
i. メディア流れの暗号化/復号化の呼び出しと関連アルゴリズムとキーの仕様。
Greene, et al. Informational [Page 22] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[22ページ]の2805mgのRFC制御プロトコル要件2000年4月
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, ....
この運搬人タイプが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識別子、VC識別子、およびAAL2スロットとしてのMG接続、これらのどちらかの荒野でcardedされた異形に割り当てられることであるATM終了の仕様を許容してください。 MGが接続の寿命の間ATM合図を使用することによってVCを選択して、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。 物理インターフェース+仮想のPath Identifier(VPI)+仮想のCircuit Identifier(VCI)を既存のVCCを参照してください。
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が局所的に設立される(SVCsはUNIかPNNIを通してゲートウェイで合図しているか、または同様の状態で合図しました)ところと、VCCの両端への意味のものである用語でVCCを間接的に呼ばなければなりません。 例えば、VCCの各端のATMデバイスのグローバル名かATMアドレス。 しかしながら、与えられた組のATMデバイスの間には、数個のVCCsがあるのは、可能であるか、またはありえそうです。 したがって、ATMアドレス組の文脈の中で明白なVCC識別子でATMアドレス組をさらに決議しなければなりません。
g. refer to a VCC as the Remote GW ATM End System Address + VCCI.
g. Remote GW ATM End System Address+VCCIをVCCを参照してください。
Greene, et al. Informational [Page 23] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[23ページ]の2805mgのRFC制御プロトコル要件2000年4月
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 End System Address(AESA)とE.164)であると扱うすべてのATMをサポートしてください。
11.1.3.2. Connection related requirements
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の上まで運ばされてください:VCCはaであるかもしれません。
* PVC or SPVC,
* PVCかSPVC
* an SVC established on demand, either by the MGC itself or by a
broker acting on its behalf or,
* またはSVCが要求に応じて、MGC自身または利益に影響しているブローカーで設立した。
* 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、または地方のMGからUNIかPNNI合図へのリモートエンドで起因しました。
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が狭周波数帯呼び出し基礎あたりのaに設立されるのに必要であるところでは、すべての必要事項が、あるメッセージで通過させられてください。
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に通過させられてください。
Greene, et al. Informational [Page 24] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[24ページ]の2805mgのRFC制御プロトコル要件2000年4月
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。 独身のVCCに写像されるという複数の狭周波数帯要求をAAL1/AAL2に許してください。 AAL2に関しては、これらの呼び出しは各VCCの中でAAL2チャンネル識別子によって差別化されます。 AAL2接続は1VCCとトランジットAAL2切換装置にかかるかもしれません。 ITU Q.2630.1[2]は終わりから終わりへのServed User Generated Reference(SUGR)と呼ばれる識別子を定義します。 それはAAL2合図プロトコルの起因するユーザから終わっているユーザまで透過的に情報を運びます。変更されない。
c. Allow unambiguous binding of a narrow band call to an AAL2
connection identifier, or AAL1 channel, within the specified
VCC.
c。 狭周波数帯呼び出しの明白な結合をAAL2接続識別子に許してください。さもないと、AAL1は指定されたVCCの中で精神を集中します。
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 Forumの標準のAF-VTOA-0083[4]単位で
* RTP with IP/UDP,
* IP/UDPとRTP
* RTP without IP/IDP per H.323v2 Annex C [5],
* 1H.323v2あたりのIP/IDPのないRTPはC[5]を付加します。
* Compressed RTP per ATM Forum AF-SAA-0124.000 [6].
* 気圧フォーラムAF SAA0124.000[6]あたりの圧縮されたRTP。
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に写像されるかもしれません。)
Greene, et al. Informational [Page 25] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[25ページ]の2805mgのRFC制御プロトコル要件2000年4月
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。 要求された通りMGによって取られたどんな輻輳回避行動のMGCでも通知を許容してください。
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にリソースと終点の有用性について質問させてください。 リソースはVCCs、およびDSPsを含むかもしれません。 VCCsは上がるか、または下がっているかもしれません。 エンドポイントは、接続なし、接続されるまたは入手できないかもしれません。
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.
TrunkingゲートウェイはATMネットワークの上のSCNネットワークとボイス・オーバー IPかVoiceとのインタフェースです。 そのようなゲートウェイは、SCNで合図するSS7か他のNNIに通常連結して、多くのディジタル回路を管理します。
The protocol must:
プロトコルはそうしなければなりません:
a. Provide circuit and packet-side loopback.
a。 回路とパケットサイドループバックを提供してください。
b. Provide circuit-side n x 64kbs connections.
b。 n回路サイドx64kbs接続を提供してください。
c. Provide subrate and multirate connections for further study.
c。 さらなる研究のための「副-レート」と多速度接続を提供してください。
Greene, et al. Informational [Page 26] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[26ページ]の2805mgのRFC制御プロトコル要件2000年4月
d. Provide the capability to support Reporting/generation of
per-trunk CAS signalling (DP, DTMF, MF, R2, J2, and national
variants).
d。 1トランクあたりのCAS合図(DP、DTMF、MF、R2、J2、および国家の異形)のReporting/世代をサポートする能力を提供してください。
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イベントについて検出されたケタの系列としてのフレキシブルなメカニズムによるケタごとのFor 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.
Accessゲートウェイは伝統的なアナログの声のISDN(PRIとBRI)のようなUNIインタフェース、ボイス・オーバー IPへの端末のインタフェース、ATMネットワークの上のVoice、またはFrame Relayネットワークの上のVoiceを接続します。
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イベントについて検出されたケタの系列としてのフレキシブルなメカニズムによるケタごとのFor 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.
さらなる研究にはプロトコルのProxyingがあります。
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. プロトコルはファックスの輸送に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を指定できなければなりません。
Greene, et al. Informational [Page 27] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[27ページ]の2805mgのRFC制御プロトコル要件2000年4月
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".
ポートのテキスト電話能力が「融通のきく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].
ポートがサポートしているテキスト電話プロトコルの違いのために適応すると思われます、テキストメディアストリームがさらなるコード変換[7]なしでパケット網でコード化されたコミュニケートしているT.140になるように。
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、Baudot-45、Baudot-50、ベル、V.21、ミニテル、および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。 交互のテキスト声のサポート: 呼び出しは、声のモードかテキストモードで始まって、呼び出しの間のどんな瞬間にも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。 ポートであるときに、テキストが対話的な声の応答への代替手段を基礎づけたか、またはゲートウェイのオーディオリソースの機能性はテキスト電話モードで使用されます。
Greene, et al. Informational [Page 28] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[28ページ]の2805mgのRFC制御プロトコル要件2000年4月
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。 どんなユニコードに基づいている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はNetwork Access Server(NAS)に参照アーキテクチャを供給します。 シグナリングはMGCに入ります、そして、MGCはNASを制御します。
+-------+ +-------+
Signaling | | | |
-----------+ MGC + | AAA |
| | | |
+---+---+ +--+----+
| |
Megaco|_______________|
|
|
+---+---+ ~~|~~~
Bearer | | ( )
-----------+ NAS +-------( IP )
| | ( )
+-------+ ~~~~~~
+-------+ +-------+ シグナリング| | | | -----------+ MGC+| AAA| | | | | +---+---+ +--+----+ | | Megaco|_______________| | | +---+---+ ~~|~~~ 運搬人| | ( ) -----------+ 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。 運搬人情報のキャリッジ。 プロトコルはTDM接続(例えば、64kbit/s、56kbit/s、384kbit/s)のデータ信号速度を指定できなければなりません、これがSCNから利用可能であるなら。
Greene, et al. Informational [Page 29] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[29ページ]の2805mgのRFC制御プロトコル要件2000年4月
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、または19.2kbit/sの「副-レート」接続と共にBearer能力で合図したV.110)から利用可能であるなら。
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。 融通のきくNASes: プロトコルはNASがダイナミックに適切なタイプの呼び出しを選択するのを許容するというかかってきた電話のための複数のオプションをサポートできなければなりません。 例えば、「スピーチ」Bearer Capabilityのためにコード化された入って来る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. Modeの、そして、64キロビット毎秒の8-khzが構造化した回路、Speech
2. Circuit Mode, 64-kbps, 8-khz structured, 3.1-khz, Audio
2. Modeの、そして、64キロビット毎秒の8-khzが構造化した回路、3.1-khz、Audio
3. Circuit Mode, 64-kbps, 8-khz structured, Unrestricted Digital
Transmission-Rate Adapted from 56-kbps
3. 56キロビット毎秒からのModeの、そして、64キロビット毎秒の8-khzが構造化した回路、Unrestricted Digital Transmission-レートAdapted
4. Circuit Mode, 64-kbps, 8-khz structure, Unrestricted Digital
Transmission
4. 回路Mode、64キロビット毎秒、8-khz構造、Unrestricted Digital Transmission
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へのCalledとCallingパーティNumber情報の通路。 Number、Redirecting Numberに請求するCharge Number/、およびOriginal Call Numberの通路も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が特定のトンネル、または、LNS、または、例えば、AAAサーバに接続するようNASに指示する能力。
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メカニズム(RADIUS/DIAMETER/))が再開かアップグレードの後にタイプ(PPP/SLIP/)にアクセスするという例えば能力情報を報告できてください。
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モデムSeeへのセクションにも適用されるかもしれません。
Greene, et al. Informational [Page 30] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[30ページ]の2805mgのRFC制御プロトコル要件2000年4月
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.323でH.320かH.324から来ているなら、MGがパケット側でH.320/H.324側からストリームまでそれぞれのサブチャネルを写像する方法を知っていると思われます。 2回の終了を接続するとき、その他の情報を必要とするならそれを供給しなければならないので、接続はあいまいではありません。
The Multimedia Gateway:
マルチメディアゲートウェイ:
1) should support Bonding Bearer channel aggregation,
1) サポートBonding Bearerは集合を向けるはずです。
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のmsec境界の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.242処理へのH.245はMGで行われそうになければなりません。 さもなければ、マルチメディアゲートウェイのこの機能性のサポートはプロトコル要件です。
Greene, et al. Informational [Page 31] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[31ページ]の2805mgのRFC制御プロトコル要件2000年4月
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がH.323へのSS7コントロールの下でISDN/H.320であるかもしれないということであるかもしれません。 これは1つの例にすぎません。 主要な要件はプロトコルがそのようなアプリケーションを防がないということです。
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:
Audio Resource Function(ARF)はスタンドアロンメディアゲートウェイサーバIVR、Intelligent Peripheral、スピーチ/話者認識ユニット、などまたは伝統的なメディアゲートウェイの上で配布することができる1つ以上の機能モジュールから成ります。 以下のARF機能モジュールの1つ以上で定義されたタスクを実行するなら、そのようなメディアゲートウェイはAudio Enabledゲートウェイ(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
- 速度をプレーしてください。
Greene, et al. Informational [Page 32] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[32ページ]の2805mgのRFC制御プロトコル要件2000年4月
- 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などの変数(数)が日付を入れる声、時間などの仕様を可能にしてください。 プロトコルはタイプ(ディレクトリ番号)として値(eg234-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.
- algorithmicallyはトーンを生成しました。
- 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".
「もう使用中でない」という言葉の録音でそれの1番目が単語の録音であるオーディオセグメントの系列が「あなたがダイヤルした番号」であるというこの抽象化に関する例は従いました、続いて、ディレクトリNumber変数に従います。
- 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.
- 1セットのオーディオ区分を表して、資格を与える人によってただ一つのセグメントに決議されている抽象化。 これらの抽象化の巣篭もりを受入れなければなりません。
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.
例えば、それのすべてが「あなたがダイヤルした番号はもう使用中でない」という意味概念を言い表す異なった言語で記録された1セットのオーディオ区分を取ってください。 セットは言語資格を与える人によって決議されています。 資格を与える人が「フランスのである」なら、セットこの発表のフランスのバージョンに決心します。
Greene, et al. Informational [Page 33] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[33ページ]の2805mgのRFC制御プロトコル要件2000年4月
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.
そして、そして、入れ子にされた抽象化が言語で1つのレベルにおいて資格があったセットから成るケース、別のレベルにおける性で資格があったセット、発表がフランス語でプレーされて、女性の声で話されると指定するのは可能でしょう。
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 Collect ModuleはPlay Moduleで以下の要件に加えて要件のすべてをサポートしなければなりません:
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
- Reprompt
Greene, et al. Informational [Page 34] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[34ページ]の2805mgのRFC制御プロトコル要件2000年4月
- 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。 オーディオセグメント基礎あたりのaでDTMF interruptibilityを指定するメソッドを提供してください。
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個以上のキーのセット。
Greene, et al. Informational [Page 35] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[35ページ]の2805mgのRFC制御プロトコル要件2000年4月
- 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:
Record ModuleはPlay Moduleで以下の要件に加えて要件のすべてをサポートしなければなりません:
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
- Reprompt
- Error prompt
- 誤りプロンプト
- Failure announcement
- 失敗発表
- Success announcement.
- 成功発表。
Greene, et al. Informational [Page 36] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[36ページ]の2805mgのRFC制御プロトコル要件2000年4月
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.
- それ自身のところを通って呼び出しの間に記録されたオーディオを取って、それがどんなその後の呼び出しにもアクセスしやすいようにそれを格納する方法は新たに識別子を作成しました。
Greene, et al. Informational [Page 37] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[37ページ]の2805mgのRFC制御プロトコル要件2000年4月
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"),
- 限られたVocabulary Isolated Speech Recognition(例えば、「はい」、「いいえ」、数「4」)
- Limited Vocabulary Continuous Speech Feature Recognition (e.g.,
the utterance "four hundred twenty-three dollars"),and/or
- そして/または限られたVocabulary Continuous Speech Feature Recognition(例えば、発声「423ドル」)。
- Continuous Speech Recognition (e.g., unconstrained speech
recognition tasks).
- 連続したSpeech Recognition(例えば、自由な音声認識タスク)。
The Speech Recognition Module must support all of the requirements in the Play Module as in addition to the following requirements:
Speech Recognition ModuleはPlay Moduleで以下の要件に加えて要件のすべてを支持しなければなりません:
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
- Reprompt
- Error prompt
- 誤りプロンプト
Greene, et al. Informational [Page 38] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[38ページ]の2805mgのRFC制御プロトコル要件2000年4月
- 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:
Verification/識別Module議長はPlay Moduleで以下の要件に加えて要件のすべてを支持しなければなりません:
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。 スピーカーテンプレートなどのパラメタ(検証タスク)かセッションの前か中間のセッションにおける潜在的スピーカーテンプレート(識別タスク)のセットをダウンロードできてください。
Greene, et al. Informational [Page 39] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[39ページ]の2805mgのRFC制御プロトコル要件2000年4月
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。 スピーカーの見込みがそれらが主張する人(検証タスク)であるか1セットの以前に特徴付けられたスピーカー(識別タスク)に含まれた人々のひとりであるスピーカーの見込みであることを示すパラメタは返すことができてください。
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
- Reprompt
- Error prompt
- 誤りプロンプト
- Failure announcement
- 失敗発表
- Success announcement.
- 成功発表。
Greene, et al. Informational [Page 40] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[40ページ]の2805mgのRFC制御プロトコル要件2000年4月
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.
聴力特徴抽出/認識モジュールが絶え間なく特定の聴力信号か興味があるスピーチ発声の外観のための聴力流れをモニターして、これらの出来事を報告するために設計される、(任意に、これらの出来事の信号特徴表現) ネットワークサーバかMGCsに。
The Auditory Feature Extraction/Recognition Module must support the following requirements:
Auditory Feature Extraction/認識Moduleは以下の要件を支持しなければなりません:
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。 いてください。セッションの前か中間のセッションときのパラメタ、抽出するか、または認識する聴力特徴の表現としてのそのようなものをダウンロードできます。
Greene, et al. Informational [Page 41] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[41ページ]の2805mgのRFC制御プロトコル要件2000年4月
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として機能する能力。 オーディオ、データ、およびビデオMG/MPにとって、肉体的に別々であるのは独身のMGC/H.323 MCのコントロールの下にある間、可能であるべきです。
Greene, et al. Informational [Page 42] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[42ページ]の2805mgのRFC制御プロトコル要件2000年4月
12. References
12. 参照
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] ITU-T Recommendation Q.2630.1, AAL type 2 Signalling Protocol
(Capability Set 1), December 1999.
[2] ITU-T Recommendation Q.2630.1、AALは1999年12月に2Signallingプロトコル(能力Set1)をタイプします。
[3] ITU-T Recommendation H.341, Line Transmission of Non-Telephone
Signals, May 1999.
[3] ITU-T推薦H.341(非電話信号の線伝達)は1999がそうするかもしれません。
[4] ATM Forum Technical Committee, af-vtoa-0083.001, Voice and
Telephony Over ATM to the Desktop Specification, March 1999.
[4] Desktop Specification、1999年3月までのATM Forum Technical Committee、af-vtoa-0083.001、Voice、およびTelephony Over ATM。
[5] ITU-T Recommendation H.323v3, Packet-based Multimedia
Communications Systems (includes Annex C - H.323 on ATM),
September 1999.
[5] ITU-T推薦H.323v3、パケットベースのマルチメディア通信システム(インクルード別館C--気圧のH.323)、1999年9月。
[6] ATM Forum Technical Committee, af-saa-0124.000, Gateway for
H.323 Media Transport Over ATM, May 1999.
[6] ATM Forum Technical Committee、af-saa-0124.000、H.323メディアTransport Over ATM、1999年5月のためのゲートウェイ。
[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月に作動するDCEsのための操作上と織り込む要件。
[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(DSS1)(ISDNユーザ))は基本的な呼び出しコントロール(1998年5月)のためのインタフェース層の3仕様をネットワークでつなぎます。
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メーリングリストでメディアゲートウェイのControl ArchitectureとRequirementsと討論した多くの貢献者を承認したがっています。 また、インターネット草稿とETSI Tiphon、ITU-T SG16、TIA TR41.3.4、ATM Forum、およびMultiservice Switching Forumのメンバーとの議論でこのドキュメントへの貢献をしました。
Greene, et al. Informational [Page 43] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[43ページ]の2805mgのRFC制御プロトコル要件2000年4月
15. Authors' Addresses
15. 作者のアドレス
Nancy Greene Nortel Networks P.O. Box 3511 Stn C Ottawa, ON, Canada K1Y 4H7
ナンシーグリーンノーテルは私書箱3511Stn Cオタワ、オンカナダ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.Ramalhoシスコシステムズ1802Rue de la Port Wall Township、ニュージャージー
Phone: +1.732.449.5762 EMail: mramalho@cisco.com
以下に電話をしてください。 +1.732 .449 .5762 メール: mramalho@cisco.com
Brian Rosen Marconi 1000 FORE Drive, Warrendale, PA 15086
Warrendale、PA ブライアン・ローゼン・マルコニー1000の前面のDrive、15086
Phone: (724) 742-6826 EMail: brosen@eng.fore.com
以下に電話をしてください。 (724) 742-6826 メールしてください: brosen@eng.fore.com
Greene, et al. Informational [Page 44] RFC 2805 MG Control Protocol Requirements April 2000
グリーン、他 情報[44ページ]の2805mgのRFC制御プロトコル要件2000年4月
16. Full Copyright Statement
16. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Greene, et al. Informational [Page 45]
グリーン、他 情報[45ページ]
一覧
スポンサーリンク
