RFC2705 日本語訳
2705 Media Gateway Control Protocol (MGCP) Version 1.0. M. Arango, A.Dugan, I. Elliott, C. Huitema, S. Pickett. October 1999. (Format: TXT=304056 bytes) (Obsoleted by RFC3435) (Updated by RFC3660) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Arango
Request for Comments: 2705 RSL COM
Category: Informational A. Dugan
I. Elliott
Level3 Communications
C. Huitema
Telcordia
S. Pickett
Vertical Networks
October 1999
Arangoがコメントのために要求するワーキンググループM.をネットワークでつないでください: 2705年のRSL COMカテゴリ: ネットワーク1999年10月のC.Huitema Telcordia S.ピケットVerticalの情報のA.デュガンI.エリオットLevel3コミュニケーション
Media Gateway Control Protocol (MGCP)
Version 1.0
メディアゲートウェイ制御プロトコル(MGCP)バージョン1.0
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 (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
IESG NOTE:
IESGは以下に注意します。
This document is being published for the information of the community. It describes a protocol that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITF-T SG16 who are currently working on a potential successor to this protocol.
このドキュメントは共同体の情報のために発表されています。 それは現在多くの製品の中に配布されているプロトコルについて説明します。 Implementersは現在このプロトコルの潜在的後継者に働いているIETF Megaco作業部会とITF-T SG16で開発を意識しているべきです。
Abstract
要約
This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP) Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements.
このドキュメントは、外部の呼び出し制御要素からボイス・オーバー IP(VoIP)ゲートウェイを制御するために、アプリケーションプログラミングインターフェースと対応するプロトコル(MGCP)について説明します。 MGCPは呼び出しコントロール「知性」がゲートウェイの外にあって、外部の呼び出し制御要素によって扱われる呼び出し規制アーキテクチャを仮定します。
The document is structured in 6 main sections:
ドキュメントは6つの主なセクションで構造化されます:
* The introduction presents the basic assumptions and the relation
to other protocols such as H.323, RTSP, SAP or SIP.
* 序論はH.323、RTSP、SAPまたはSIPなどの他のプロトコルとの基本仮定と関係を提示します。
Arango, et al. Informational [Page 1] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[1ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
* The interface section presents a conceptual overview of the MGCP,
presenting the naming conventions, the usage of the session
description protocol SDP, and the procedures that compose MGCP:
Notifications Request, Notification, Create Connection, Modify
Connection, Delete Connection, AuditEndpoint, AuditConnection and
RestartInProgress.
* インタフェースセクションはMGCPの概念的な概要を提示します、命名規則、セッション記述プロトコルSDPの使用法、およびMGCPを構成する手順を提示して: 通知要求(通知)は接続を創造して、接続を変更してください、そして、接続、AuditEndpoint、AuditConnection、およびRestartInProgressを削除してください。
* The protocol description section presents the MGCP encodings,
which are based on simple text formats, and the transmission
procedure over UDP.
* プロトコル記述部はUDPの上にMGCP encodingsとトランスミッション手順を提示します。(MGCP encodingsは簡単なテキスト形式に基づいています)。
* The security section presents the security requirement of MGCP,
and its usage of IP security services (IPSEC).
* セキュリティ部はMGCPのセキュリティ要件、およびそのIPセキュリティー・サービス(IPSEC)の用法を提示します。
* The event packages section provides an initial definition of
packages and event names.
* セクションがパッケージとイベント名の初期の定義を供給するイベントパッケージ。
* The description of the changes made in combining SGCP 1.1 and IPDC
to create MGCP 1.0.
* 変化の記述は、MGCP1.0を作成するためにSGCPを結合する際に1.1とIPDCを作りました。
Table of Contents
目次
1. Introduction .............................................. 5
1.1. Relation with the H.323 standards .................... 7
1.2. Relation with the IETF standards ..................... 8
1.3. Definitions .......................................... 9
2. Media Gateway Control Interface ........................... 9
2.1. Model and naming conventions. ........................ 10
2.1.1. Types of endpoints .............................. 10
2.1.1.1. Digital channel (DS0) ...................... 11
2.1.1.2. Analog line ................................ 11
2.1.1.3. Annoucement server access point ............ 12
2.1.1.4. Interactive Voice Response access point .... 12
2.1.1.5. Conference bridge access point ............. 13
2.1.1.6. Packet relay ............................... 13
2.1.1.7. Wiretap access point ....................... 14
2.1.1.8. ATM "trunk side" interface. ................ 14
2.1.2. Endpoint identifiers ............................ 15
2.1.3. Calls and connections ........................... 17
2.1.3.1. Names of calls ............................. 20
2.1.3.2. Names of connections ....................... 20
2.1.3.3. Management of resources, attributes of ..... 20
2.1.3.4. Special case of local connections .......... 23
2.1.4. Names of Call Agents and other entities ......... 23
2.1.5. Digit maps ...................................... 24
2.1.6. Names of events ................................. 26
2.2. Usage of SDP ......................................... 29
2.3. Gateway Control Commands ............................. 30
1. 序論… 5 1.1. H.323規格との関係… 7 1.2. IETF規格との関係… 8 1.3. 定義… 9 2. メディアゲートウェイコントロールは連結します… 9 2.1. モデルと命名規則。 ........................ 10 2.1.1. 終点のタイプ… 10 2.1.1.1. デジタル・チャンネル(DS0)… 11 2.1.1.2. アナログの系列… 11 2.1.1.3. Annoucementサーバアクセスポイント… 12 2.1.1.4. 対話的なVoice Responseアクセスポイント… 12 2.1.1.5. カンフェレンス・ブリッジアクセスポイント… 13 2.1.1.6. パケットリレー… 13 2.1.1.7. アクセスポイントを盗聴してください… 14 2.1.1.8. ATM「トランク側」は連結します。 ................ 14 2.1.2. 終点識別子… 15 2.1.3. 呼び出しと接続… 17 2.1.3.1. 呼び出しの名前… 20 2.1.3.2. 接続の名前… 20 2.1.3.3. リソースの管理、属性、… 20 2.1.3.4. 市内接続の特別なケース… 23 2.1.4. Callエージェントと他の実体の名前… 23 2.1.5. ケタ地図… 24 2.1.6. イベントの名前… 26 2.2. SDPの使用法… 29 2.3. ゲートウェイコントロールは命令します… 30
Arango, et al. Informational [Page 2] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[2ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
2.3.1. EndpointConfiguration ........................... 32
2.3.2. NotificationRequest ............................. 33
2.3.3. CreateConnection ................................ 38
2.3.4. ModifyConnection ................................ 44
2.3.5. DeleteConnection (from the Call Agent) .......... 46
2.3.6. DeleteConnection (from the VoIP gateway) ........ 51
2.3.7. DeleteConnection (multiple connections, from the 51
2.3.8. Audit Endpoint .................................. 52
2.3.9. Audit Connection ................................ 55
2.3.10. Restart in progress ............................ 56
2.4. Return codes and error codes. ........................ 58
2.5. Reason Codes ......................................... 61
3. Media Gateway Control Protocol ............................ 61
3.1. General description .................................. 62
3.2. Command Header ....................................... 62
3.2.1. Command line .................................... 62
3.2.1.1. Coding of the requested verb ............... 63
3.2.1.2. Transaction Identifiers .................... 63
3.2.1.3. Coding of the endpoint identifiers and ..... 64
3.2.1.4. Coding of the protocol version ............. 65
3.2.2. Parameter lines ................................. 65
3.2.2.1. Response Acknowledgement ................... 68
3.2.2.2. Local connection options ................... 68
3.2.2.3. Capabilities ............................... 70
3.2.2.4. Connection parameters ...................... 71
3.2.2.5. Reason Codes ............................... 72
3.2.2.6. Connection mode ............................ 73
3.2.2.7. Coding of event names ...................... 73
3.2.2.8. RequestedEvents ............................ 74
3.2.2.9. SignalRequests ............................. 76
3.2.2.10. ObservedEvent ............................. 76
3.2.2.11. RequestedInfo ............................. 76
3.2.2.12. QuarantineHandling ........................ 77
3.2.2.13. DetectEvents .............................. 77
3.2.2.14. EventStates ............................... 77
3.2.2.15. RestartMethod ............................. 78
3.2.2.16. Bearer Information ........................ 78
3.3. Format of response headers ........................... 78
3.4. Formal syntax description of the protocol ............ 81
3.5. Encoding of the session description .................. 86
3.5.1. Usage of SDP for an audio service ............... 86
3.5.2. Usage of SDP in a network access service ........ 87
3.5.3. Usage of SDP for ATM connections ................ 90
3.5.4. Usage of SDP for local connections .............. 91
3.6. Transmission over UDP ................................ 91
3.6.1. Providing the At-Most-Once functionality ........ 91
3.6.2. Transaction identifiers and three ways handshake. 92
3.6.3. Computing retransmission timers ................. 93
2.3.1. EndpointConfiguration… 32 2.3.2. NotificationRequest… 33 2.3.3. CreateConnection… 38 2.3.4. ModifyConnection… 44 2.3.5. DeleteConnection(呼び出しエージェントからの)… 46 2.3.6. DeleteConnection(VoIPゲートウェイからの)… 51 2.3.7. DeleteConnection、(51 2.3.8監査Endpointからの複数の接続、.522.3、.9. 監査Connection、.552.3、.10. 進行中の.562.4の復帰コードとエラーコードを再開してください; …、58、2.5. Codes......................................... 61 3メディアゲートウェイControlプロトコル............................ 61 3.1概説.................................. 62 3.2コマンドHeaderを推論してください…; …… 62 3.2.1コマンドライン、.623.2、.1、.1. 要求された動詞のコード化、.633.2、.1、.2. トランザクションIdentifiers、.633.2、.1、.3. プロトコルバージョン............. 65 3.2.2のパラメタ行の終点識別子と..... 64 3.2.1.4コード化のコード化、.653.2、.2、.1. 応答Acknowledgement、.683.2、.2、.2. 市内接続オプション、.683.2、.2、.3. 上限 QuarantineHandling、.773.2、.2、.13. DetectEvents、.773.2、.2、.14. EventStates、.773.2、.2、.15. RestartMethod、.783.2、.2、.16. 運搬人情報…; …、78、3.3. 応答ヘッダ........................... 78 3.4セッション記述のプロトコル.813.5コード化の正式な構文記述の形式、.863.5、.1. オーディオサービスのためのSDPの使用法……… . 86、3.5、.2. ネットワークアクセス・サービスにおけるSDPの使用法、.873.5、.3. ATM接続のためのSDPの使用法、.903.5、.4. UDPの上の市内接続.913.6トランスミッションのためのSDPの使用法、.913.6、.1. 提供、At、最も一度、機能性、.913.6、.2. トランザクション識別子と3つの方法、握手92個の3.6.3コンピューティング再送信タイマー................. 93
Arango, et al. Informational [Page 3] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[3ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
3.6.4. Piggy backing ................................... 94
3.6.5. Provisional responses ........................... 94
4. States, failover and race conditions. ..................... 95
4.1. Basic Asumptions ..................................... 95
4.2. Security, Retransmission, and Detection of Lost ...... 96
4.3. Race conditions ...................................... 99
4.3.1. Quarantine list ................................. 99
4.3.2. Explicit detection ..............................103
4.3.3. Ordering of commands, and treatment of disorder .104
4.3.4. Fighting the restart avalanche ..................105
4.3.5. Disconnected Endpoints ..........................107
1. A "disconnected" timer is initialized to a random value, .107
2. The gateway then waits for either the end of this timer, .107
3. When the "disconnected" timer elapses, when a command is .107
4. If the "disconnected" procedure still left the endpoint ..107
5. Security requirements .....................................108
5.1. Protection of media connections ......................109
6. Event packages and end point types ........................109
6.1. Basic packages .......................................110
6.1.1. Generic Media Package ...........................110
6.1.2. DTMF package ....................................112
6.1.3. MF Package ......................................113
6.1.4. Trunk Package ...................................114
6.1.5. Line Package ....................................116
6.1.6. Handset emulation package .......................119
6.1.7. RTP Package .....................................120
6.1.8. Network Access Server Package ...................121
6.1.9. Announcement Server Package .....................122
6.1.10. Script Package .................................122
6.2. Basic endpoint types and profiles ....................123
7. Versions and compatibility ................................124
7.1. Differences between version 1.0 and draft 0.5 ........124
7.2. Differences between draft-04 and draft-05 ............125
7.3. Differences between draft-03 and draft-04 ............125
7.4. Differences between draft-02 and draft-03 ............125
7.5. Differences between draft-01 and draft-02 ............126
7.6. The making of MGCP from IPDC and SGCP ................126
7.7. Changes between MGCP and initial versions of SGCP ....126
8. Security Considerations ...................................128
9. Acknowledgements ..........................................128
10. References ................................................129
11. Authors' Addresses ........................................130
12. Appendix A: Proposed "MoveConnection" command .............132
12.1. Proposed syntax modification ........................133
13. Full Copyright Statement ..................................134
3.6.4. 子豚の支援… 94 3.6.5. 暫定的な応答… 94 4. 州、フェイルオーバー、および競合条件。 ..................... 95 4.1. 基本的なAsumptions… 95 4.2. セキュリティ、Retransmission、および検出、失われています… 96 4.3. 競合条件… 99 4.3.1. リストを検疫してください… 99 4.3.2. 明白な検出…103 4.3.3. .4にコマンド、および混乱.104 4.3の処理を注文します。 再開殺到と戦います…105 4.3.5. 終点であると切断されます…107 1. 「切断している」タイマは2に無作為の値、.107に初期化されます。 そして、ゲートウェイはこのタイマ、.107の終わりの間、3に待っています。 コマンドが4に.107であるときに、「切断している」タイマが経過する場合 「切断している」手順がまだ終点を出ていたなら。107 5. セキュリティ要件…108 5.1. メディア接続の保護…109 6. イベントパッケージとエンドポイントタイプ…109 6.1. 基本的なパッケージ…110 6.1.1. ジェネリックメディア・パッケージ…110 6.1.2. DTMFパッケージ…112 6.1.3. mfパッケージ…113 6.1.4. トランクパッケージ…114 6.1.5. パッケージを裏打ちしてください…116 6.1.6. 受話器エミュレーションパッケージ…119 6.1.7. RTPパッケージ…120 6.1.8. アクセス・サーバーパッケージをネットワークでつないでください…121 6.1.9. 発表サーバパッケージ…122 6.1.10. スクリプトパッケージ…122 6.2. 基本的な終点タイプとプロフィール…123 7. バージョンと互換性…124 7.1. バージョン1.0と草稿0.5の違い…124 7.2. 草稿-04と草稿-05の違い…125 7.3. 草稿-03と草稿-04の違い…125 7.4. 草稿-02と草稿-03の違い…125 7.5. 草稿-01と草稿-02の違い…126 7.6. IPDCとSGCPからのMGCPの作成…126 7.7. SGCPのMGCPと初期のバージョンの間の変化…126 8. セキュリティ問題…128 9. 承認…128 10. 参照…129 11. 作者のアドレス…130 12. 付録A: 提案された"MoveConnection"は命令します…132 12.1. 構文変更を提案します…133 13. 完全な著作権宣言文…134
Arango, et al. Informational [Page 4] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[4ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
1. Introduction
1. 序論
This document describes an abstract application programming interface and a corresponding protocol (MGCP) for controlling Telephony Gateways from external call control elements called media gateway controllers or call agents. A telephony gateway is a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over the Internet or over other packet networks. Example of gateways are:
このドキュメントは、メディアゲートウェイコントローラか呼び出しエージェントと呼ばれる外部の呼び出し制御要素からTelephony Gatewaysを制御するために、抽象的なアプリケーションプログラミングインターフェースと対応するプロトコル(MGCP)について説明します。 電話ゲートウェイは電話回線の上で運ばれた音声信号とインターネットの上、または、他のパケット網の上まで運ばれたデータ・パケットの間に変換を供給するネットワーク要素です。 ゲートウェイに関する例は以下の通りです。
* Trunking gateways, that interface between the telephone network
and a Voice over IP network. Such gateways typically manage a
large number of digital circuits.
* 中継方式ゲートウェイ、電話網とボイス・オーバー IPネットワークとのそのインタフェース。 そのようなゲートウェイは多くのディジタル回路を通常管理します。
* Voice over ATM gateways, which operate much the same way as voice
over IP trunking gateways, except that they interface to an ATM
network.
* ATMの上でゲートウェイを声に出してください、ATMネットワークに連結するのを除いて。(ゲートウェイはIP中継方式ゲートウェイの上でずっと声への大体同じことを操作します)。
* Residential gateways, that provide a traditional analog (RJ11)
interface to a Voice over IP network. Examples of residential
gateways include cable modem/cable set-top boxes, xDSL devices,
broad-band wireless devices
* 住宅のゲートウェイであり、それは伝統的なアナログの(RJ11)インタフェースをボイス・オーバー IPネットワークに提供します。 住宅のゲートウェイに関する例はケーブルモデム/ケーブルセットトップボックス、xDSLデバイス、広帯域ワイヤレス機器を含んでいます。
* Access gateways, that provide a traditional analog (RJ11) or
digital PBX interface to a Voice over IP network. Examples of
access gateways include small-scale voice over IP gateways.
* ゲートウェイにアクセスしてください、そして、それは伝統的なアナログ(RJ11)かデジタルPBXインタフェースをボイス・オーバー IPネットワークに提供します。 アクセスゲートウェイに関する例はIPゲートウェイの上に小規模の声を含んでいます。
* Business gateways, that provide a traditional digital PBX
interface or an integrated "soft PBX" interface to a Voice over IP
network.
* ビジネスゲートウェイであり、それは伝統的なデジタルPBXインタフェースか統合「柔らかいPBX」インタフェースをボイス・オーバー IPネットワークに提供します。
* Network Access Servers, that can attach a "modem" to a telephone
circuit and provide data access to the Internet. We expect that,
in the future, the same gateways will combine Voice over IP
services and Network Access services.
* Access Serversをネットワークでつないでください、それは、「モデム」を電話回線に付けて、インターネットへのデータ・アクセスを供給できます。 私たちは、同じゲートウェイが未来にボイス・オーバー IPサービスとNetwork Accessサービスを結合すると予想します。
* Circuit switches, or packet switches, which can offer a control
interface to an external call control element.
* 回路が切り替わるか、またはパケット(コントロールインタフェースを外部の呼び出し制御要素まで提供できる)は切り替わります。
MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements. The MGCP assumes that these call control elements, or Call Agents, will synchronize with each other to send coherent commands to the gateways under their control. MGCP does not define a mechanism for synchronizing Call Agents. MGCP is, in essence, a master/slave protocol, where the gateways are expected to execute commands sent by the Call Agents. In consequence, this document specifies in great detail the expected behavior of the gateways, but
MGCPは呼び出しコントロール「知性」がゲートウェイの外にあって、外部の呼び出し制御要素によって扱われる呼び出し規制アーキテクチャを仮定します。 MGCPは、これらの呼び出し制御要素、またはCallエージェントが彼らのコントロールの下におけるゲートウェイにコヒーレントコマンドを送るために互いに連動すると仮定します。 MGCPは、Callエージェントを連動させるようにメカニズムを定義しません。 本質、マスター/奴隷プロトコルにはMGCPがゲートウェイがCallエージェントによって送られたコマンドを実行すると予想されるところにあります。 その結果、しかし、このドキュメントは丹念にゲートウェイの予想された動きを指定します。
Arango, et al. Informational [Page 5] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[5ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
only specify those parts of a call agent implementation, such as timer management, that are mandated for proper operation of the protocol.
単にプロトコルの適切な操作のために強制されるタイマ管理などの呼び出しエージェント実装のそれらの部品を指定してください。
MGCP assumes a connection model where the basic constructs are endpoints and connections. Endpoints are sources or sinks of data and could be physical or virtual. Examples of physical endpoints are:
MGCPは基本的な構造物が終点と接続である接続モデルに就きます。 終点は、ソースであるかデータを沈ませて、あるかもしれません。物理的であるか、または仮想です。 物理的な終点に関する例は以下の通りです。
* An interface on a gateway that terminates a trunk connected to a
PSTN switch (e.g., Class 5, Class 4, etc.). A gateway that
terminates trunks is called a trunk gateway.
* トランクを終えるゲートウェイの上のインタフェースはPSTNスイッチ(例えば、Class5、Class4など)に接続しました。 トランクスを終えるゲートウェイはトランクゲートウェイと呼ばれます。
* An interface on a gateway that terminates an analog POTS
connection to a phone, key system, PBX, etc. A gateway that
terminates residential POTS lines (to phones) is called a
residential gateway.
* 電話、主要なシステム、PBXなどとのアナログのPOTS接続を終えるゲートウェイの上のインタフェース 住宅のPOTS系列(電話への)を終えるゲートウェイは住宅のゲートウェイと呼ばれます。
An example of a virtual endpoint is an audio source in an audio- content server. Creation of physical endpoints requires hardware installation, while creation of virtual endpoints can be done by software.
仮想の終点に関する例はオーディオ内容サーバのオーディオソースです。物理的な終点の作成はハードウェア・インストレーションを必要とします、ソフトウェアで仮想の終点の作成ができますが。
Connections may be either point to point or multipoint. A point to point connection is an association between two endpoints with the purpose of transmitting data between these endpoints. Once this association is established for both endpoints, data transfer between these endpoints can take place. A multipoint connection is established by connecting the endpoint to a multipoint session.
コネクションズは、ポイント・ツー・ポイントか多点のどちらかであるかもしれません。 接続はポイント・ツー・ポイント、これらの終点の間にデータを送る目的がある2つの終点の間の協会です。 この協会がいったん両方の終点に設立されると、これらの終点の間のデータ転送は行われることができます。 マルチポイント接続は、多点セッションまで終点をつなげることによって、確立されます。
Connections can be established over several types of bearer networks:
いくつかのタイプの基幹ネットワークの上でコネクションズを確立できます:
* Transmission of audio packets using RTP and UDP over a TCP/IP
network.
* TCP/IPネットワークの上でRTPとUDPを使用するオーディオパケットのトランスミッション。
* Transmission of audio packets using AAL2, or another adaptation
layer, over an ATM network.
* AAL2を使用するオーディオパケットのトランスミッション、またはATMネットワークの上の別の適合層。
* Transmission of packets over an internal connection, for example
the TDM backplane or the interconnection bus of a gateway. This is
used, in particular, for "hairpin" connections, connections that
terminate in a gateway but are immediately rerouted over the
telephone network.
* 例えば、内部の接続、TDMバックプレーンの上のパケットのトランスミッションかゲートウェイのインタコネクトバス。 これは「ヘアピン」接続(ゲートウェイで終わりますが、すぐに電話網の上で別ルートで送られる接続)に特に使用されます。
For point-to-point connections the endpoints of a connection could be in separate gateways or in the same gateway.
二地点間接続にとって、接続の終点が別々のゲートウェイか同じゲートウェイにあるかもしれません。
Arango, et al. Informational [Page 6] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[6ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
1.1. Relation with the H.323 standards
1.1. H.323規格との関係
MGCP is designed as an internal protocol within a distributed system that appears to the outside as a single VoIP gateway. This system is composed of a Call Agent, that may or may not be distributed over several computer platforms, and of a set of gateways, including at least one "media gateway" that perform the conversion of media signals between circuits and packets, and at least one "signalling gateway" when connecting to an SS7 controlled network. In a typical configuration, this distributed gateway system will interface on one side with one or more telephony (i.e. circuit) switches, and on the other side with H.323 conformant systems, as indicated in the following table:
MGCPは内部のプロトコルとして1VoIP門として外部まで現れる分散システムの中で設計されています。 このシステムはそのいくつかのコンピュータプラットホームにわたって分配されるかもしれなくて、SS7に接続するときの回路と、パケットと、少なくとも1の間のメディア信号の変換を実行する少なくとも1「メディアゲートウェイ」を含む1セットのゲートウェイの「ゲートウェイに合図します」制御ネットワークのCallエージェントで構成されます。 典型的な構成では、この分配されたゲートウェイシステムは1個以上の電話(すなわち、回路)スイッチがある半面の上と、そして、H.323 conformantシステムがある反対側の上に連結するでしょう、以下のテーブルにみられるように:
___________________________________________________________________
| Functional| Phone | Terminating | H.323 conformant |
| Plane | switch | Entity | systems |
|___________|____________|_________________|_______________________|
| Signaling | Signaling | Call agent | Signaling exchanges |
| Plane | exchanges | | with the call agent |
| | through | | through H.225/RAS and|
| | SS7/ISUP | | H.225/Q.931. |
|___________|____________|_________________|_______________________|
| | | | Possible negotiation |
| | | | of logical channels |
| | | | and transmission |
| | | | parameters through |
| | | | H.245 with the call |
| | | | agent. |
|___________|____________|_________________|_______________________|
| | | Internal | |
| | | synchronization| |
| | | through MGCP | |
|___________|____________|_________________|_______________________|
| Bearer | Connection| Telephony | Transmission of VOIP |
| Data | through | gateways | data using RTP |
| Transport | high speed| | directly between the |
| Plane | trunk | | H.323 station and the|
| | groups | | gateway. |
|___________|____________|_________________|_______________________|
___________________________________________________________________ | 機能的| 電話| 終わります。| H.323 conformant| | 飛行機| スイッチ| 実体| システム| |___________|____________|_________________|_______________________| | シグナリング| シグナリング| エージェントに電話をしてください。| シグナリング交換| | 飛行機| 交換| | 呼び出しエージェントと共に| | | 突き抜ける| | そしてH.225/RAS。| | | SS7/ISUP| | H.225/Q.931。 | |___________|____________|_________________|_______________________| | | | | 可能な交渉| | | | | 論理チャネルについて| | | | | そして、トランスミッション| | | | | パラメタ、通じて。| | | | | 呼び出しがあるH.245| | | | | エージェント。 | |___________|____________|_________________|_______________________| | | | 内部| | | | | 同期| | | | | MGCPを通して| | |___________|____________|_________________|_______________________| | 運搬人| 接続| 電話| VOIPのトランスミッション| | データ| 突き抜ける| ゲートウェイ| RTPを使用するデータ| | 輸送| 高速| | 直接間| | 飛行機| トランク| | そしてH.323ステーション。| | | グループ| | ゲートウェイ。 | |___________|____________|_________________|_______________________|
In the MGCP model, the gateways focus on the audio signal translation function, while the Call Agent handles the signaling and call processing functions. As a consequence, the Call Agent implements the "signaling" layers of the H.323 standard, and presents itself as an "H.323 Gatekeeper" or as one or more "H.323 Endpoints" to the H.323 systems.
MGCPモデルでは、音声信号翻訳のゲートウェイ焦点は機能します、Callエージェントがシグナリングと呼び出し処理機能を扱いますが。 結果として、Callエージェントは、「シグナリング」がH.323規格の層であると実装して、「H.323門番」として、または、1「H.323終点」としてH.323システムに出向きます。
Arango, et al. Informational [Page 7] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[7ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
1.2. Relation with the IETF standards
1.2. IETF規格との関係
While H.323 is the recognized standard for VoIP terminals, the IETF has also produced specifications for other types of multi-media applications. These other specifications include:
H.323はVoIP端末の認識された規格ですが、また、IETFは他のタイプのマルチメディアアプリケーションのための仕様を作り出しました。 これらの他の仕様は:
* the Session Description Protocol (SDP), RFC 2327,
* セッション記述プロトコル(SDP)、RFC2327
* the Session Announcement Protocol (SAP),
* セッション発表プロトコル(SAP)
* the Session Initiation Protocol (SIP),
* セッション開始プロトコル(一口)
* the Real Time Streaming Protocol (RTSP), RFC 2326.
* リアルタイムのストリーミングのプロトコル(RTSP)、RFC2326。
The latter three specifications are in fact alternative signaling standards that allow for the transmission of a session description to an interested party. SAP is used by multicast session managers to distribute a multicast session description to a large group of recipients, SIP is used to invite an individual user to take part in a point-to-point or unicast session, RTSP is used to interface a server that provides real time data. In all three cases, the session description is described according to SDP; when audio is transmitted, it is transmitted through the Real-time Transport Protocol, RTP.
事実上、後者の3つの仕様が利害関係者にとってセッション記述の送信を考慮する代替のシグナリング規格です。 SAPはマルチキャストセッション記述を受取人の大きいグループに広げるのにマルチキャストセッションマネージャによって使用されて、SIPは個々のユーザがポイントツーポイントかユニキャストセッションのときに参加するよう誘うのに使用されて、RTSPは、リアルタイムのデータを提供するサーバを連結するのに使用されます。 すべての3つの場合では、SDPに従って、セッション記述は説明されます。 RTP、オーディオが送られるとき、それはレアル-時間Transportプロトコルを通して伝えられます。
The distributed gateway systems and MGCP will enable PSTN telephony users to access sessions set up using SAP, SIP or RTSP. The Call Agent provides for signaling conversion, according to the following table:
分配されたゲートウェイシステムとMGCPは、PSTN電話ユーザがセットアップされたセッションにアクセスするのをSAP、SIPまたはRTSPを使用することで可能にするでしょう。 以下のテーブルに従って、Callエージェントはシグナリング変換に備えます:
Arango, et al. Informational [Page 8] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[8ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
_____________________________________________________________________
| Functional| Phone | Terminating | IETF conforming systems|
| Plane | switch | Entity | |
|___________|____________|_________________|_________________________|
| Signaling | Signaling | Call agent | Signaling exchanges |
| Plane | exchanges | | with the call agent |
| | through | | through SAP, SIP or |
| | SS7/ISUP | | RTSP. |
|___________|____________|_________________|_________________________|
| | | | Negotiation of session |
| | | | description parameters |
| | | | through SDP (telephony |
| | | | gateway terminated but |
| | | | passed via the call |
| | | | agent to and from the |
| | | | IETF conforming system)|
|___________|____________|_________________|_________________________|
| | | Internal | |
| | | synchronization| |
| | | through MGCP | |
|___________|____________|_________________|_________________________|
| Bearer | Connection| Telephony | Transmission of VoIP |
| Data | through | gateways | data using RTP, |
| Transport | high speed| | directly between the |
| Plane | trunk | | remote IP end system |
| | groups | | and the gateway. |
|___________|____________|_________________|_________________________|
_____________________________________________________________________ | 機能的| 電話| 終わります。| IETF従うシステム| | 飛行機| スイッチ| 実体| | |___________|____________|_________________|_________________________| | シグナリング| シグナリング| エージェントに電話をしてください。| シグナリング交換| | 飛行機| 交換| | 呼び出しエージェントと共に| | | 突き抜ける| | またはSAPを通して、ちびちび飲んでください。| | | SS7/ISUP| | RTSP。 | |___________|____________|_________________|_________________________| | | | | セッションの交渉| | | | | 記述パラメタ| | | | | そして、SDP、(電話| | | | | しかし、終えられたゲートウェイ| | | | | 呼び出しで、通過されます|、| | | | エージェント、| | | | | IETF従うシステム、)| |___________|____________|_________________|_________________________| | | | 内部| | | | | 同期| | | | | MGCPを通して| | |___________|____________|_________________|_________________________| | 運搬人| 接続| 電話| VoIPのトランスミッション| | データ| 突き抜ける| ゲートウェイ| RTPを使用するデータ| | 輸送| 高速| | 直接間| | 飛行機| トランク| | リモートIPエンドシステム| | | グループ| | そして、ゲートウェイ。 | |___________|____________|_________________|_________________________|
The SDP standard has a pivotal status in this architecture. We will see in the following description that we also use it to carry session descriptions in MGCP.
SDP規格に、このアーキテクチャの重要な状態がいます。 私たちは、以下の記述でまた、MGCPでセッション記述を運ぶのにそれを使用するのがわかるでしょう。
1.3. Definitions
1.3. 定義
Trunk: A communication channel between two switching systems. E.g., a DS0 on a T1 or E1 line.
トランク: 交換システム例えば、DS0あたり2の間のT1か1Eの系列に関する通信チャネル。
2. Media Gateway Control Interface
2. メディアゲートウェイコントロールインタフェース
The interface functions provide for connection control and endpoint control. Both use the same system model and the same naming conventions.
インタフェース機能は接続コントロールと終点コントロールに備えます。 両方が同じシステムモデルと同じ命名規則を使用します。
Arango, et al. Informational [Page 9] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[9ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
2.1. Model and naming conventions
2.1. モデルと命名規則
The MGCP assumes a connection model where the basic constructs are endpoints and connections. Connections are grouped in calls. One or more connections can belong to one call. Connections and calls are set up at the initiative of one or several Call Agents.
MGCPは基本的な構造物が終点と接続である接続モデルに就きます。 コネクションズは呼び出しで分類されます。 1つ以上の接続が1つの呼び出しに属すことができます。 コネクションズと呼び出しは1か数人のCallエージェントのイニシアチブのときにセットアップされます。
2.1.1. Types of endpoints
2.1.1. 終点のタイプ
In the introduction, we presented several classes of gateways. Such classifications, however, can be misleading. Manufacturers can arbitrarily decide to provide several types of services in a single packaging. A single product could well, for example, provide some trunk connections to telephony switches, some primary rate connections and some analog line interfaces, thus sharing the characteristics of what we described in the introduction as "trunking", "access" and "residential" gateways. MGCP does not make assumptions about such groupings. We simply assume that media gateways support collections of endpoints. The type of the endpoint determines its functionalities. Our analysis, so far, has led us to isolate the following basic endpoint types:
序論では、私たちは数人のクラスのゲートウェイを示しました。 しかしながら、そのような分類は紛らわしい場合があります。 メーカーは、単一のパッケージにおける、いくつかのタイプのサービスを提供すると任意に決めることができます。 例えば、ただ一つの製品はたぶん電話スイッチ、何人かのプライマリレート接続、およびいくつかのアナログのラインインターフェースに何人かのトランク接続を供給するでしょう、その結果、私たちが序論で「中継方式」、「アクセス」、および「住宅」のゲートウェイと説明したことに関する特性を共有します。 MGCPはそのような組分けに関する仮定をしません。 私たちは、メディアゲートウェイが終点の収集をサポートすると単に思います。 終点のタイプは機能性を決定します。 私たちの分析は、今までのところ、私たちが以下の基本的な終点タイプを隔離するように導きました:
* Digital channel (DS0),
* デジタル・チャンネル(DS0)
* Analog line,
* アナログの系列
* Annoucement server access point,
* Annoucementサーバアクセスポイント
* Interactive Voice Response access point,
* 対話的なVoice Responseアクセスポイント
* Conference bridge access point,
* カンフェレンス・ブリッジアクセスポイント
* Packet relay,
* パケットリレー
* Wiretap access point,
* アクセスポイントを盗聴してください。
* ATM "trunk side" interface.
* ATM「トランク側」は連結します。
In this section, we will develop the expected behavior of such end points.
このセクションでは、私たちはそのようなエンドポイントの予想された振舞いを開発するつもりです。
This list is not limitative. There may be other types of endpoints defined in the future, for example test endpoint that could be used to check network quality, or frame-relay endpoints that could be used to managed audio channels multiplexed over a frame-relay virtual circuit.
このリストはlimitativeではありません。 将来定義された、他のタイプの終点、例えばネットワーク品質をチェックするのに使用できたテスト終点があったかもしれませんか、または管理された音声チャンネルに使用できたフレームリレー終点はフレームリレーの仮想の回路の上に多重送信されました。
Arango, et al. Informational [Page 10] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[10ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
2.1.1.1. Digital channel (DS0)
2.1.1.1. デジタル・チャンネル(DS0)
Digital channels provide an 8Khz*8bit service. Such channels are found in trunk and ISDN interfaces. They are typically part of digital multiplexes, such as T1, E1, T3 or E3 interfaces. Media gateways that support such channels are capable of translating the digital signals received on the channel, which may be encoded according to A or mu-law, using either the complete set of 8 bits or only 7 of these bits, into audio packets. When the media gateway also supports a NAS service, the gateway shall be capable of receiving either audio-encoded data (modem connection) or binary data (ISDN connection) and convert them into data packets.
デジタル・チャンネルは8Khz*8bit serviceを提供します。 そのようなチャンネルはトランクとISDNインタフェースで見つけられます。 通常、それらはT1、1E、T3または3ユーロのインタフェースなどのデジタルマルチプレックスの一部です。 そのようなチャンネルを支えるメディアゲートウェイはAかμ法によると、コード化されるかもしれないチャンネルで受け取られたディジタル信号を翻訳できます、8ビットの完全なセットかこれらの7ビットだけを使用して、オーディオパケットに。 また、メディアゲートウェイが、NASがサービスであるとサポートすると、ゲートウェイは、オーディオでコード化されたデータ(モデム接続)かバイナリ・データ(ISDN接続)のどちらかを受け取ることができて、それらをデータ・パケットに変換するものとします。
+-------
+------------+|
(channel) ===|DS0 endpoint| -------- Connections
+------------+|
+-------
+------- +------------+| (チャンネル) ===|DS0終点| -------- コネクションズ+------------+| +-------
Media gateways should be able to establish several connections between the endpoint and the packet networks, or between the endpoint and other endpoints in the same gateway. The signals originating from these connections shall be mixed according to the connection "mode", as specified later in this document. The precise number of connections that an endpoint support is a characteristic of the gateway, and may in fact vary according with the allocation of resource within the gateway.
メディアゲートウェイは同じゲートウェイの終点とパケット網か、終点と他の終点とのいくつかの関係を確立するはずであることができます。 接続「モード」に従って、これらの接続から発する信号は後で指定されるとして本書では複雑であるものとします。 終点がサポートする接続の正確な数は、ゲートウェイの特性であり、事実上、ゲートウェイの中でリソースの配分と一致しながら、異なるかもしれません。
In some cases, digital channels are used to carry signalling. This is the case for example of SS7 "F" links, or ISDN "D" channels. Media gateways that support these signalling functions shall be able to send and receive the signalling packets to and from a call agent, using the "back haul" procedures defined by the SIGTRAN working group of the IETF. Digital channels are sometimes used in conjunction with channel associated signalling, such as "MF R2". Media gateways that support these signalling functions shall be able to detect and produce the corresponding signals, such as for example "wink" or "A", according to the event signalling and reporting procedures defined in MGCP.
いくつかの場合、デジタル・チャンネルは、合図を運ぶのに使用されます。 例えば、これはSS7「F」リンク、またはISDN「D」チャンネルのそうです。 これらの合図機能をサポートするメディアゲートウェイは、エージェントと呼び出しエージェントから合図パケットを送って、受けることができるでしょう、IETFのSIGTRANワーキンググループによって定義された「返路輸送」手順を用いて。 デジタル・チャンネルは時々「mf R2"」などのように合図しながら関連づけられたチャンネルに関連して使用されます。 これらの合図機能をサポートするメディアゲートウェイは、対応する信号を検出して、作り出すことができるでしょう、「ウインク」のようにあれほど、またはイベント合図と手順を報告するのに従った「A」は中でMGCPを定義しました。
2.1.1.2. Analog line
2.1.1.2. アナログの系列
Analog lines can be used either as a "client" interface, providing service to a classic telephone unit, or as a "service" interface, allowing the gateway to send and receive analog calls. When the media gateway also supports a NAS service, the gateway shall be capable of receiving audio-encoded data (modem connection) and convert them into data packets.
古典的な電話ユニットに対するサービスを提供して、「クライアント」インタフェースとしてアナログの系列を使用できますか、または「サービス」インタフェースとして、アナログを送って、受けるためにゲートウェイを許容するのは呼びます。 また、メディアゲートウェイが、NASがサービスであるとサポートすると、ゲートウェイは、オーディオでコード化されたデータ(モデム接続)を受け取ることができて、それらをデータ・パケットに変換するものとします。
Arango, et al. Informational [Page 11] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[11ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
+-------
+---------------+|
(line) ===|analog endpoint| -------- Connections
+---------------+|
+-------
+------- +---------------+| (系列) ===|アナログの終点| -------- コネクションズ+---------------+| +-------
Media gateways should be able to establish several connections between the endpoint and the packet networks, or between the endpoint and other endpoints in the same gateway. The audio signals originating from these connections shall be mixed according to the connection "mode", as specified later in this document. The precise number of connections that an endpoint support is a characteristic of the gateway, and may in fact vary according with the allocation of resource within the gateway. A typical gateway should however be able to support two or three connections per endpoint, in order to provide services such as "call waiting" or "three ways calling".
メディアゲートウェイは同じゲートウェイの終点とパケット網か、終点と他の終点とのいくつかの関係を確立するはずであることができます。 接続「モード」に従って、これらの接続から発する音声信号は後で指定されるとして本書では複雑であるものとします。 終点がサポートする接続の正確な数は、ゲートウェイの特性であり、事実上、ゲートウェイの中でリソースの配分と一致しながら、異なるかもしれません。 しかしながら、典型的なゲートウェイは1終点あたり2か3つの接続をサポートするはずであることができます、「キャッチホン」などのサービスを提供するか、または「3つの方法が呼ん」で。
2.1.1.3. Annoucement server access point
2.1.1.3. Annoucementサーバアクセスポイント
An announcement server endpoint provides acces to an announcement service. Under requests from the call agent, the announcement server will "play" a specified announcement. The requests from the call agent will follow the event signalling and reporting procedures defined in MGCP.
発表サーバ終点は発表サービスにaccesを提供します。 呼び出しエージェントからの要求で、発表サーバは指定された発表を「プレーするでしょう」。 呼び出しエージェントからの要求はMGCPで定義された手順を示して、報告するイベントに続くでしょう。
+----------------------+
| Announcement endpoint| -------- Connection
+----------------------+
+----------------------+ | 発表終点| -------- 接続+----------------------+
A given announcement endpoint is not supposed to support more than one connection at a time. If several connections were established to the same endpoint, then the same announcements would be played simultaneously over all the connections.
与えられた発表終点は一度に1つ以上の接続をサポートするべきではありません。 いくつかの接続が同じ終点に確立されるなら、同じ発表は同時に、すべての接続の上でプレーされるでしょうに。
Connections to an announcement server are typically oneway, or "half duplex" -- the announcement server is not expected to listen the audio signals from the connection.
発表サーバへのコネクションズは、通常oneway、または「半二重」です--発表サーバが接続から音声信号を聴かないと予想されます。
2.1.1.4. Interactive Voice Response access point
2.1.1.4. 対話的なVoice Responseアクセスポイント
An Interactive Voice Response (IVR) endpoint provides acces to an IVR service. Under requests from the call agent, the IVR server will "play" announcements and tones, and will "listen" to responses from the user. The requests from the call agent will follow the event signalling and reporting procedures defined in MGCP.
Interactive Voice Response(IVR)終点はIVRサービスにaccesを提供します。 呼び出しエージェントからの要求で、IVRサーバは、発表とトーンを「プレーし」て、ユーザから応答を「聴くでしょう」。 呼び出しエージェントからの要求はMGCPで定義された手順を示して、報告するイベントに続くでしょう。
Arango, et al. Informational [Page 12] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[12ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
+-------------+
| IVR endpoint| -------- Connection
+-------------+
+-------------+ | IVR終点| -------- 接続+-------------+
A given IVR endpoint is not supposed to support more than one connection at a time. If several connections were established to the same endpoint, then the same tones and announcements would be played simultaneously over all the connections.
与えられたIVR終点は一度に1つ以上の接続をサポートするべきではありません。 いくつかの接続が同じ終点に確立されるなら、同じトーンと発表は同時に、すべての接続の上でプレーされるでしょうに。
2.1.1.5. Conference bridge access point
2.1.1.5. カンフェレンス・ブリッジアクセスポイント
A conference bridge endpoint is used to provide access to a specific conference.
カンフェレンス・ブリッジ終点は、特定の会議へのアクセスを提供するのに使用されます。
+-------
+--------------------------+|
|Conference bridge endpoint| -------- Connections
+--------------------------+|
+-------
+------- +--------------------------+| |カンフェレンス・ブリッジ終点| -------- コネクションズ+--------------------------+| +-------
Media gateways should be able to establish several connections between the endpoint and the packet networks, or between the endpoint and other endpoints in the same gateway. The signals originating from these connections shall be mixed according to the connection "mode", as specified later in this document. The precise number of connections that an endpoint support is a characteristic of the gateway, and may in fact vary according with the allocation of resource within the gateway.
メディアゲートウェイは同じゲートウェイの終点とパケット網か、終点と他の終点とのいくつかの関係を確立するはずであることができます。 接続「モード」に従って、これらの接続から発する信号は後で指定されるとして本書では複雑であるものとします。 終点がサポートする接続の正確な数は、ゲートウェイの特性であり、事実上、ゲートウェイの中でリソースの配分と一致しながら、異なるかもしれません。
2.1.1.6. Packet relay
2.1.1.6. パケットリレー
A packet relay endpoint is a specific form of conference bridge, that typically only supports two connections. Packets relays can be found in firewalls between a protected and an open network, or in transcoding servers used to provide interoperation between incompatible gateways, for example gateways that do not support compatible compression algorithms, or gateways that operate over different transmission networks such as IP and ATM.
パケットリレー終点が特定の形式のカンフェレンス・ブリッジである、それは2つの接続しか通常サポートしません。 保護されたaとオープンネットワークの間のファイアウォール、または非互換なゲートウェイ(例えば、コンパチブル圧縮がIPやATMなどの異なった送電網の上で作動するアルゴリズム、またはゲートウェイであるとサポートしないゲートウェイ)の間にinteroperationを供給するのに使用されるコード変換サーバでパケットリレーを見つけることができます。
+-------
+---------------------+ |
|Packet relay endpoint| 2 connections
+---------------------+ |
+-------
+------- +---------------------+ | |パケットリレー終点| 2つの接続+---------------------+ | +-------
Arango, et al. Informational [Page 13] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[13ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
2.1.1.7. Wiretap access point
2.1.1.7. 盗聴アクセスポイント
A wiretap access point provides access to a wiretap service, providing either a recording or a life playback of a connection.
盗聴アクセスポイントは盗聴サービスへのアクセスを提供します、接続の録音か寿命再生のどちらかを提供して。
+-----------------+
| Wiretap endpoint| -------- Connection
+-----------------+
+-----------------+ | 盗聴終点| -------- 接続+-----------------+
A given wiretap endpoint is not supposed to support more than one connection at a time. If several connections were established to the same endpoint, then the recording or playback would mix the audio signals received on this connections.
与えられた盗聴終点は一度に1つ以上の接続をサポートするべきではありません。 いくつかの接続が同じ終点に確立されるなら、録音か再生がこの接続のときに受け取られた音声信号を混ぜるでしょうに。
Connections to an wiretap endpoint are typically oneway, or "half duplex" -- the wiretap server is not expected to signal its presence in a call.
盗聴終点へのコネクションズは、通常oneway、または「半二重」です--盗聴サーバが呼び出しで存在を示唆しないと予想されます。
2.1.1.8. ATM "trunk side" interface.
2.1.1.8. ATM「トランク側」は連結します。
ATM "trunk side" endpoints are typically found when one or several ATM permanent virtual circuits are used as a replacement for the classic "TDM" trunks linking switches. When ATM/AAL2 is used, several trunks or channels are multiplexed on a single virtual circuit; each of these trunks correspond to a single endpoint.
1かいくつかのATM相手固定接続が古典的な"TDM"トランクスリンクに交換として使用されるとき、「トランク側」終点が通常見つけられるATMは切り替わります。 ATM/AAL2が使用されているとき、ただ一つの仮想の回路の上に数個のトランクスかチャンネルを多重送信します。 それぞれのこれらのトランクスは単一の終点に対応しています。
+-------
+------------------+|
(channel) = |ATM trunk endpoint| -------- Connections
+------------------+|
+-------
+------- +------------------+| (チャンネル) = |ATMトランク終点| -------- コネクションズ+------------------+| +-------
Media gateways should be able to establish several connections between the endpoint and the packet networks, or between the endpoint and other endpoints in the same gateway. The signals originating from these connections shall be mixed according to the connection "mode", as specified later in this document. The precise number of connections that an endpoint support is a characteristic of the gateway, and may in fact vary according with the allocation of resource within the gateway.
メディアゲートウェイは同じゲートウェイの終点とパケット網か、終点と他の終点とのいくつかの関係を確立するはずであることができます。 接続「モード」に従って、これらの接続から発する信号は後で指定されるとして本書では複雑であるものとします。 終点がサポートする接続の正確な数は、ゲートウェイの特性であり、事実上、ゲートウェイの中でリソースの配分と一致しながら、異なるかもしれません。
Arango, et al. Informational [Page 14] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[14ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
2.1.2. Endpoint identifiers
2.1.2. 終点識別子
Endpoints identifiers have two components that both are case insensitive:
終点識別子には、2つのともに大文字と小文字を区別しないコンポーネントがあります:
* the domain name of the gateway that is managing the endpoint,
* 終点を管理しているゲートウェイのドメイン名
* a local name within that gateway,
* そのゲートウェイの中の地方名
The syntax of the local name depends on the type of endpoint being named. However, the local name for each of these types is naturally hierarchical, beginning with a term which identifies the physical gateway containing the given endpoint and ending in a term which specifies the individual endpoint concerned. With this in mind, the following rules for construction and interpretation of the Entity Name field for these entity types MUST be supported:
地方名の構文は命名される終点のタイプに頼っています。 しかしながら、これらのタイプ各人のための地方名は自然に階層的です、関する個々の終点を指定する用語で与えられた終点と結末を含む物理的なゲートウェイを特定する用語で始まって。 これが念頭にある場合、これらの実体タイプのためのEntity Name分野の工事と解釈のための以下の規則をサポートしなければなりません:
1) The individual terms of the naming path MUST be separated by a
single slash ("/", ASCII 2F hex).
1) ただ一つのスラッシュ(「/」、ASCII2F十六進法)で命名経路の個々の用語を切り離さなければなりません。
2) The individual terms are character strings composed of letters,
digits or other printable characters, with the exception of
characters used as delimitors ("/", "@"), characters used for
wildcarding ("*", "$") and white spaces.
2) 個々の用語は手紙、ケタまたは他の印刷可能なキャラクタで構成された文字列です、delimitors(「/」、"@")として使用されるキャラクタを除いて、wildcarding(「*」、「$」)と余白に使用されるキャラクタ。
3) Wild-carding is represented either by an asterisk ("*") or a
dollar sign ("$") for the terms of the naming path which are to be
wild-carded. Thus, if the full naming path looks like
3) アスタリスク(「*」)かドル記号(「$」)によってワイルドな梳綿機は荒野によってcardedされていることになっている命名経路の用語のときに表されます。 したがって、完全な命名経路であるなら、面相は好きです。
term1/term2/term3
term1/term2/term3
then the Entity Name field looks like this depending on which
terms are wild-carded:
次に、Entity Name分野は用語が荒野によってcardedされているこの依存に似ています:
*/term2/term3 if term1 is wild-carded
term1/*/term3 if term2 is wild-carded
term1/term2/* if term3 is wild-carded
term1/*/* if term2 and term3 are wild-carded,
etc.
*term1であるなら、*term2とterm3が荒野によってcardedされているのなどならterm3がワイルドなcarded term1/*/*であるならterm2がワイルドなcarded term1/term2/であるなら、/term2/term3はワイルドなcarded term1/*/term3です。
In each of these examples a dollar sign could have appeared
instead of an asterisk.
それぞれに関するこれらの例では、ドル記号はアスタリスクの代わりに現れたかもしれません。
Arango, et al. Informational [Page 15] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[15ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
4) A term represented by an asterisk is to be interpreted as: "use
ALL values of this term known within the scope of the Media
Gateway". A term represented by a dollar sign is to be
interpreted as: "use ANY ONE value of this term known within the
scope of the Media Gateway". The description of a specific
command may add further criteria for selection within the general
rules given here.
4) アスタリスクによって表された用語は解釈されることになっています: 「メディアゲートウェイの範囲の中で知られていた今期のすべての値を使用してください。」 ドル記号によって表された用語は解釈されることになっています: 「メディアゲートウェイの範囲の中で知られていた今期のANY ONE値を使用してください。」 特定のコマンドの記述はここに与えられた総則の中で選択のさらなる評価基準を加えるかもしれません。
If the Media Gateway controls multiple physical gateways, the first term of the naming MUST identify the physical gateway containing the desired entity. If the Media Gateway controls only a single physical gateway, the first term of the naming string MAY identify that physical gateway, depending on local practice. A local name that is composed of only a wildcard character refers to either all (*) or any ($) endpoints within the media gateway.
メディアゲートウェイが複数の物理的なゲートウェイを制御するなら、命名の前期は必要な実体を含む物理的なゲートウェイを特定しなければなりません。 メディアゲートウェイが物理的な1つの門だけを制御するなら、命名ストリングの前期はその物理的なゲートウェイを特定するかもしれません、地方の習慣によって。 ワイルドカードキャラクタだけで構成される地方名はメディアゲートウェイの中のすべての(*)かどんな($)終点のどちらかについても言及します。
In the case of trunking gateways, endpoints are trunk circuits linking a gateway to a telephone switch. These circuits are typically grouped into a digital multiplex, that is connected to the gateway by a physical interface. Such circuits are named in three contexts:
中継方式ゲートウェイの場合では、終点は電話スイッチへのゲートウェイをリンクするトランク回路です。 これらの回路は、通常デジタルマルチプレックスに分類されていて、すなわち、物理インターフェースのそばでゲートウェイに接続されています。 そのような回路は3つの文脈で命名されます:
* In the ISUP protocol, trunks are grouped into trunk groups,
identified by the SS7 point codes of the switches that the group
connects. Circuits within a trunk group are identified by a
circuit number (CIC in ISUP).
* ISUPプロトコルでは、トランクスはグループが接続するスイッチのSS7ポイントコードによって特定されたトランクグループに分類されます。 回路番号(ISUPのCIC)によってトランクグループの中の回路は特定されます。
* In the gateway configuration files, physical interfaces are
typically identified by the name of the interface, an arbitrary
text string. When the interface multiplexes several circuits,
individual circuits are typically identified by a circuit number.
* ゲートウェイ構成ファイルでは、物理インターフェースはインタフェースの名前、任意のテキスト文字列によって通常特定されます。 インタフェースがいくつかの回路を多重送信するとき、個々の回路は回路番号によって通常特定されます。
* In MGCP, the endpoints are identified by an endpoint identifier.
* MGCPでは、終点は終点識別子によって特定されます。
The Call Agents use configuration databases to map ranges of circuit numbers within an ISUP trunk group to corresponding ranges of circuits in a multiplex connected to a gateway through a physical interface. The gateway will be identified, in MGCP, by a domain name. The local name will be structured to encode both the name of the physical interface, for example X35V3+A4, and the circuit number within the multiplex connected to the interface, for example 13. The circuit number will be separated from the name of the interface by a fraction bar, as in:
Callエージェントは、ISUPトランクグループの中で物理インターフェースを通してゲートウェイに接続されたマルチプレックスの対応する範囲の回路に回路番号の範囲を写像するのに構成データベースを使用します。 ゲートウェイはMGCPでドメイン名によって特定されるでしょう。 地方名は、インタフェース、例えば、13に接続されたマルチプレックスの中で物理インターフェースの名前、例えば、X35V3+A4と回路番号の両方をコード化するために構造化されるでしょう。 回路番号は以下のように断片バーによってインタフェースの名前と切り離されるでしょう。
X35V3+A4/13
X35V3+A4/13
Arango, et al. Informational [Page 16] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[16ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Other types of endpoints will use different conventions. For example, in gateways were physical interfaces by construction only control one circuit, the circuit number will be omitted. The exact syntax of such names should be specified in the corresponding server specification.
他のタイプの終点は異なったコンベンションを使用するでしょう。 例えば、物理インターフェースが工事であったなら、ゲートウェイでは、1個の回路しか制御しないでください、そして、回路番号は省略されるでしょう。 そのような名前の正確な構文は対応するサーバ仕様で指定されるべきです。
2.1.3. Calls and connections
2.1.3. 呼び出しと接続
Connections are created on the call agent on each endpoint that will be involved in the "call." In the classic example of a connection between two "DS0" endpoints (EP1 and EP2), the call agents controlling the end points will establish two connections (C1 and C2):
コネクションズは「呼び出し」にかかわる各終点で呼び出しエージェントで作成されます。 2の間の関係に関する典型例、「DS0"終点(EP1とEP2)、エンドポイントを制御している呼び出しエージェントは2つの接続(C1とC2)を確立するでしょう」。
+---+ +---+
(channel1) ===|EP1|--(C1)--... ...(C2)--|EP2|===(channel2)
+---+ +---+
+---+ +---+ (channel1)===|EP1|--(C1)--... ...(C2)--|EP2|===(channel2) +---+ +---+
Each connection will be designated locally by a connection identifier, and will be characterized by connection attributes.
各接続は、接続識別子によって局所的に任命されて、接続属性によって描写されるでしょう。
When the two endpoints are located on gateways that are managed by the same call agent, the creation is done via the three following steps:
同じ呼び出しエージェントによって管理されるゲートウェイに2つの終点の見つけるとき、以下の次の3ステップを通して作成をします:
1) The call agent asks the first gateway to "create a connection" on
the first endpoint. The gateway allocates resources to that
connection, and respond to the command by providing a "session
description." The session description contains the information
necessary for a third party to send packets towards the newly
created connection, such as for example IP address, UDP port, and
packetization parameters.
1) 呼び出しエージェントは最初の終点で「接続を創造してください」に最初のゲートウェイを招きます。 ゲートウェイはその接続にリソースを割り当てます、そして、「セッション記述」を提供することによって、コマンドに応じてください。 セッション記述は第三者が新たに作成された接続に向かってパケットを送るのに必要な情報を含んでいます、例えば、IPアドレスや、UDPポートや、packetizationパラメタなどのように。
2) The call agent then asks the second gateway to "create a
connection" on the second endpoint. The command carries the
"session description" provided by the first gateway. The gateway
allocates resources to that connection, and respond to the command
by providing its own "session description."
2) そして、呼び出しエージェントは2番目の終点で「接続を創造してください」に2番目のゲートウェイを招きます。 コマンドは最初のゲートウェイによって提供された「セッション記述」を運びます。 ゲートウェイはその接続にリソースを割り当てます、そして、それ自身の「セッション記述」を提供することによって、コマンドに応じてください。
3) The call agent uses a "modify connection" command to provide this
second "session description" to the first endpoint. Once this is
done, communication can proceed in both directions.
3) 呼び出しエージェントはこの2番目の「セッション記述」を最初の終点に提供する「接続を変更してください」というコマンドを使用します。 これがいったん完了していると、コミュニケーションは両方の方向に続くことができます。
When the two endpoints are located on gateways that are managed by the different call agents, these two call agents shall exchange information through a call-agent to call-agent signalling protocol, in order to synchronize the creation of the connection on the two endpoints.
2つの終点が異なった呼び出しエージェントによって管理されるゲートウェイに見つけられているとき、これらの2人の呼び出しエージェントが呼び出しエージェントを通して呼び出しエージェント合図プロトコルと情報交換するものとします、2つの終点で接続の作成を同期させるように。
Arango, et al. Informational [Page 17] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[17ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Once established, the connection parameters can be modified at any time by a "modify connection" command. The call agent may for example instruct the gateway to change the compression algorithm used on a connection, or to modify the IP address and UDP port to which data should be sent, if a connection is "redirected."
いったん設立されると、いつでも、「接続を変更してください」というコマンドで接続パラメタを変更できます。 例えば、呼び出しエージェントは、接続のときに使用された圧縮アルゴリズムを変えるか、またはデータが送られるべきであるIPアドレスとUDPポートを変更するようゲートウェイに命令するかもしれません、接続が「向け直される」なら。
The call agent removes a connection by sending to the gateway a "delete connection" command. The gateway may also, under some circumstances, inform a gateway that a connection could not be sustained.
呼び出しエージェントは、「接続を削除してください」というコマンドをゲートウェイに送ることによって、接続を外します。 また、いくつかの状況で、ゲートウェイは、接続を支えることができなかったことをゲートウェイに知らせるかもしれません。
The following diagram provides a view of the states of a connection, as seen from the gateway:
以下のダイヤグラムはゲートウェイから見られるように接続の州に関する意見を提供します:
Arango, et al. Informational [Page 18] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[18ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Create connection
received
|
V
+-------------------+
|resource allocation|-(failed)-+
+-------------------+ |
| (connection refused)
(successful)
|
v
+----------->+
| |
| +-------------------+
| | remote session |
| | description |----------(yes)--------+
| | available ? | |
| +-------------------+ |
| | |
| (no) |
| | |
| +-----------+ +------+
| +--->| half open |------> Delete <-------| open |<----------+
| | | (wait) | Connection |(wait)| |
| | +-----------+ received +------+ |
| | | | | |
| | Modify Connection | Modify Connection |
| | received | received |
| | | | | |
| | +--------------------+ | +--------------------+ |
| | |assess modification | | |assess modification | |
| | +--------------------+ | +--------------------+ |
| | | | | | | |
| |(failed) (successful) | (failed) (successful) |
| | | | | | | |
| +<---+ | | +-------------+-------+
| | |
+<-------------------+ |
|
+-----------------+
| Free connection |
| resources. |
| Report. |
+-----------------+
|
V
受け取られていた状態で接続を創造してください。| +に対して-------------------+ |資源配分|-(失敗されます)-+ +-------------------+ | | (拒否された接続) (うまくいく)です。 | +に対して----------->+| | | +-------------------+ | | リモートセッション| | | 記述|----------(はい)--------+ | | 利用可能ですか? | | | +-------------------+ | | | | | (いいえ) | | | | | +-----------+ +------+ | +--->| 半分は開きます。|------>は<を削除します。-------| 戸外| <、-、-、-、-、-、-、-、-、--+ | | | (待ち) | 接続|(待ち)| | | | +-----------+ 容認された+------+ | | | | | | | | | 接続を変更してください。| 接続を変更してください。| | | 受信します。| 受信します。| | | | | | | | | +--------------------+ | +--------------------+ | | | |変更を評価してください。| | |変更を評価してください。| | | | +--------------------+ | +--------------------+ | | | | | | | | | | |(失敗されます) (うまくいく)です。 | (失敗されます) (うまくいく)です。 | | | | | | | | | | + <。---+ | | +-------------+-------+ | | | + <。-------------------+ | | +-----------------+ | 無料の接続| | リソース。 | | 報告してください。 | +-----------------+ | V
Arango, et al. Informational [Page 19] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[19ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
2.1.3.1. Names of calls
2.1.3.1. 呼び出しの名前
One of the attributes of each connection is the "call identifier."
それぞれの接続の属性の1つは「呼び出し識別子」です。
Calls are identified by unique identifiers, independent of the underlying platforms or agents. These identifiers are created by the Call Agent. They are treated in MGCP as unstructured octet strings.
呼び出しは基本的なプラットホームかエージェントの如何にかかわらずユニークな識別子によって特定されます。 これらの識別子はCallエージェントによって作成されます。 それらは不統一な八重奏ストリングとしてMGCPで扱われます。
Call identifiers are expected to be unique within the system, or at a minimum, unique within the collection of Call Agents that control the same gateways. When a Call Agent builds several connections that pertain to the same call, either on the same gateway or in different gateways, these connections that belong to the same call share the same call-id. This identifier can then be used by accounting or management procedures, which are outside the scope of MGCP.
呼び出し識別子がシステムか、最小限において特有であると予想されます、同じゲートウェイを制御するCallエージェントの収集の中でユニークです。 Callエージェントが同じゲートウェイの上、または、異なったゲートウェイで同じ呼び出しに関係するいくつかの接続を組み込むとき、同じ呼び出しに属すこれらの接続が同じ呼び出しイドを共有します。 そして、会計か管理手順でこの識別子を使用できます。(MGCPの範囲の外に手順があります)。
2.1.3.2. Names of connections
2.1.3.2. 接続の名前
Connection identifiers are created by the gateway when it is requested to create a connection. They identify the connection within the context of an endpoint. They are treated in MGCP as unstructured octet strings. The gateway should make sure that a proper waiting period, at least 3 minutes, elapses between the end of a connection that used this identifier and its use in a new connection for the same endpoint. (Gateways may decide to use identifiers that are unique within the context of the gateway.)
接続を創造するよう要求されているとき、接続識別子はゲートウェイによって作成されます。 彼らは終点の文脈の中で接続を特定します。 それらは不統一な八重奏ストリングとしてMGCPで扱われます。 ゲートウェイは、適切な待ちの期間(少なくとも3分)がこの識別子を使用した接続の終わりとその使用の間で同じ終点のための新しい接続で経過するのを確実にするはずです。 (ゲートウェイは、ゲートウェイの文脈の中でユニークな識別子を使用すると決めるかもしれません。)
2.1.3.3. Management of resources, attributes of connections
2.1.3.3. リソースの管理、接続の属性
Many types of resources will be associated to a connection, such as specific signal processing functions or packetization functions. Generally, these resources fall in two categories:
多くのタイプに関するリソースは機能かpacketization機能を処理する特定の信号などの接続に関連づけられるでしょう。 一般に、これらのリソースは2つのカテゴリで下がります:
1) Externally visible resources, that affect the format of "the bits
on the network" and must be communicated to the second endpoint
involved in the connection.
1) 外部的に目に見えるリソースであり、それに「ネットワークのビット」の形式に影響して、接続にかかわる2番目の終点に伝えなければなりません。
2) Internal resources, that determine which signal is being sent over
the connection and how the received signals are processed by the
endpoint.
2) 社内資源であり、それはどの信号を接続の上に送るか、そして、終点でどのように受信された信号を処理するかを決定します。
The resources allocated to a connection, and more generally the handling of the connection, are chosen by the gateway under instructions from the call agent. The call agent will provide these instructions by sending two set of parameters to the gateway:
接続に割り当てられたリソース、および、より一般に接続の取り扱うのはゲートウェイによって呼び出しエージェントから指示で選ばれています。 呼び出しエージェントはパラメタの2セットをゲートウェイに送ることによって、これらの指示を提供するでしょう:
1) The local directives instruct the gateway on the choice of
resources that should be used for a connection,
1) 地方の指示が命令される、接続に使用されるべきであるリソースの選択でのゲートウェイ
Arango, et al. Informational [Page 20] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[20ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
2) When available, the "session description" provided by the other
end of the connection.
2) 利用可能であるときに、接続のもう一方の端までに提供された「セッション記述。」です。
The local directives specify such parameters as the mode of the connection (e.g. send only, send-receive), preferred coding or packetization methods, usage of echo cancellation or silence suppression. (A detailed list can be found in the specification of the LocalConnectionOptions parameter of the CreateConnection command.) For each of these parameters, the call agent can either specify a value, a range of value, or no value at all. This allow various implementations to implement various level of control, from a very tight control where the call agent specifies minute details of the connection handling to a very loose control where the call agent only specifies broad guidelines, such as the maximum bandwidth, and let the gateway choose the detailed values.
地方の指示が接続の方法のようなパラメタを指定する、(例えば、発信してください、単に、発信、-受信してください、)、都合のよいコード化かpacketizationメソッド(エコーキャンセルか沈黙抑圧の用法) (CreateConnectionコマンドのLocalConnectionOptionsパラメタの仕様で詳細なリストを見つけることができます。) それぞれのこれらのパラメタとして、呼び出しエージェントは値(全く値にもかかわらず、価値がない1つの範囲)を指定できます。 これで、様々な実装が呼び出しエージェントが呼び出しエージェントが幅広い指針を指定するだけである非常にゆるいコントロールへの接続取り扱いに関する詳細を指定する最大の帯域幅などの非常にきついコントロールから様々な管理水準を実装するのを許容して、ゲートウェイは詳細な値を選びます。
Based on the value of the local directives, the gateway will determine the resources allocated to the connection. When this is possible, the gateway will choose values that are in line with the remote session description - but there is no absolute requirement that the parameters be exactly the same.
地方の指示の値に基づいて、ゲートウェイは接続に割り当てられたリソースを決定するでしょう。 これが可能であるときに、ゲートウェイはリモートセッション記述に沿ってある値を選ぶでしょう--しかし、パラメタがまさに同じであるという絶対条件が全くありません。
Once the resource have been allocated, the gateway will compose a "session description" that describes the way it intends to receive packets. Note that the session description may in some cases present a range of values. For example, if the gateway is ready to accept one of several compression algorithm, it can provide a list of these accepted algorithms.
いったんリソースを割り当てると、ゲートウェイはパケットを受けるつもりである方法を述べる「セッション記述」を構成するでしょう。 いくつかの場合、セッション記述がさまざまな値を提示するかもしれないことに注意してください。 例えば、ゲートウェイが数個の圧縮アルゴリズムの1つを受け入れる準備ができているなら、それはこれらの受け入れられたアルゴリズムのリストを提供できます。
Arango, et al. Informational [Page 21] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[21ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Local Directives
(from call agent 1)
|
V
+-------------+
| resources |
| allocation |
| (gateway 1) |
+-------------+
| |
V |
Local |
Parameters V
| Session
| Description Local Directives
| | (from call agent 2)
| +---> Transmission----+ |
| (CA to CA) | |
| V V
| +-------------+
| | resources |
| | allocation |
| | (gateway 2) |
| +-------------+
| | |
| | V
| | Local
| | Parameters
| Session
| Description
| +---- Transmission<---+
| | (CA to CA)
V V
+-------------+
| modification|
| (gateway 1) |
+-------------+
|
V
Local
Parameters
地方のDirectives(呼び出しエージェント1からの)| +に対して-------------+ | リソース| | 配分| | (ゲートウェイ1) | +-------------+ | | V| ローカル| パラメタV| セッション| 記述の地方の指示| | (呼び出しエージェント2からの) | +--->トランスミッション----+ | | (カリフォルニアへのカリフォルニア) | | | V V| +-------------+ | | リソース| | | 配分| | | (ゲートウェイ2) | | +-------------+ | | | | | V| | ローカル| | パラメタ| セッション| 記述| +---- トランスミッション<。---+ | | (カリフォルニアへのカリフォルニア) +に対するV-------------+ | 変更| | (ゲートウェイ1) | +-------------+ | Vローカルのパラメタ
-- Information flow: local directives & session descriptions --
-- 情報流動: 地方の指示とセッション記述--
Arango, et al. Informational [Page 22] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[22ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
2.1.3.4. Special case of local connections
2.1.3.4. 市内接続の特別なケース
Large gateways include a large number of endpoints which are often of different types. In some networks, we may often have to set-up connections between endpoints that are located within the same gateway. Examples of such connections may be:
大きいゲートウェイはしばしば異なったタイプのそうである多くの終点を含んでいます。 いくつかのネットワークでは、私たちは同じゲートウェイの中に位置している終点の間の接続をしばしばセットアップしなければならないかもしれません。 そのような接続に関する例は以下の通りです。
* Connecting a trunk line to a wiretap device,
* 盗聴デバイスに幹線をつなげます。
* Connecting a call to an Interactive Voice-Response unit,
* Interactive Voice-応答ユニットに呼び出しを接続します。
* Connecting a call to a Conferencing unit,
* Conferencingユニットに呼び出しを接続します。
* Routing a call from on endpoint to another, something often
described as a "hairpin" connection.
* aが別のものへの終点、しばしば「ヘアピン」接続として記述された何かに呼ぶルート設定。
Local connections are much simpler to establish than network connections. In most cases, the connection will be established through some local interconnecting device, such as for example a TDM bus.
市内接続は設立するのが接続をネットワークでつなぐよりはるかに簡単です。 多くの場合、接続は例えば、TDMバスなどのある地方の内部連絡デバイスを通して確立されるでしょう。
When two endpoints are managed by the same gateway, it is possible to specify the connection in a single command that conveys the name of the two endpoints that will be connected. The command is essentially a "Create Connection" command which includes the name of the second endpoint in lieu of the "remote session description."
2つの終点が同じゲートウェイによって管理されるとき、つなげられる2つの終点の名前を伝えるただ一つのコマンドにおける接続を指定するのは可能です。 コマンドは本質的には「接続を創造してください」という「リモートセッション記述」の代わりに2番目の終点の名前を含んでいるコマンドです。
2.1.4. Names of Call Agents and other entities
2.1.4. Callエージェントと他の実体の名前
The media gateway control protocol has been designed to allow the implementation of redundant Call Agents, for enhanced network reliability. This means that there is no fixed binding between entities and hardware platforms or network interfaces.
メディアゲートウェイ制御プロトコルは、高められたネットワークの信頼性のための余分なCallエージェントの実装を許容するように設計されています。 これは、実体とハードウェアプラットホームかネットワーク・インターフェースの間には、固定結合が全くないことを意味します。
Reliability can be improved by the following precautions:
以下の注意で信頼性を改良できます:
* Entities such as endpoints or Call Agents are identified by their
domain name, not their network addresses. Several addresses can be
associated with a domain name. If a command or a response cannot
be forwarded to one of the network addresses, implementations
should retry the transmission using another address.
* 終点かCallエージェントなどの実体は彼らのネットワーク・アドレスではなく、彼らのドメイン名によって特定されます。 いくつかのアドレスをドメイン名に関連づけることができます。 コマンドか応答をネットワーク・アドレスの1つに送ることができないなら、実装は、別のアドレスを使用することでトランスミッションを再試行するべきです。
* Entities may move to another platform. The association between a
logical name (domain name) and the actual platform are kept in the
domain name service. Call Agents and Gateways should keep track of
the time-to-live of the record they read from the DNS. They should
query the DNS to refresh the information if the time to live has
expired.
* 実体は別のプラットホームに移行するかもしれません。 論理的な名前(ドメイン名)と実際のプラットホームとの協会はドメイン名サービスで維持されます。 エージェントとGatewaysが生きる現代の道であることを保つはずである彼らがDNSから読む記録の呼び出し。 生きる時間が期限が切れたなら、彼らは、情報をリフレッシュするためにDNSについて質問するべきです。
Arango, et al. Informational [Page 23] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[23ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
In addition to the indirection provided by the use of domain names and the DNS, the concept of "notified entity" is central to reliability and fail-over in MGCP. The "notified entity" for an endpoint is the Call Agent currently controlling that endpoint. At any point in time, an endpoint has one, and only one, "notified entity" associated with it, and when the endpoint needs to send a command to the Call Agent, it MUST send the command to the current "notified entity" for which endpoint(s) the command pertains. Upon startup, the "notified entity" MUST be set to a provisioned value. Most commands sent by the Call Agent include the ability to explicitly name the "notified entity" through the use of a "NotifiedEntity" parameter. The "notified entity" will stay the same until either a new "NotifiedEntity" parameter is received or the endpoint reboots. If the "notified entity" for an endpoint is empty or has not been set explicitly, the "notified entity" will then default to the source address of the last connection handling command or notification request received for the endpoint. Auditing will thus not change the "notified entity."
ドメイン名の使用とDNSによって提供された間接指定に加えて、「通知された実体」の概念はMGCPで信頼性とフェイルオーバーに主要です。 終点への「通知された実体」は現在その終点を制御しているCallエージェントです。 時間内にの任意な点では、終点がそれに関連している1、および1だけ、「通知された実体」を持っています、そして、終点が、Callエージェントにコマンドを送る必要があると、それがコマンドがそれの終点に関して関係する現在の「通知された実体」にコマンドを送らなければなりません。 始動のときに、「通知された実体」を食糧を供給された値に設定しなければなりません。 Callエージェントによって送られたほとんどのコマンドが"NotifiedEntity"パラメタの使用で明らかに「通知された実体」を命名する能力を含んでいます。 新しい"NotifiedEntity"パラメタが受信されているか、または終点がリブートされるまで、「通知された実体」は同じままでしょう。 終点への「通知された実体」が空であるか、または明らかに設定されていないと、「通知された実体」は終点に受け取られた最後の接続取り扱い命令か通知要求のソースアドレスをデフォルトとするでしょう。 その結果、監査は「通知された実体」を変えないでしょう。
2.1.5. Digit maps
2.1.5. ケタ地図
The Call Agent can ask the gateway to collect digits dialed by the user. This facility is intended to be used with residential gateways to collect the numbers that a user dials; it may also be used with trunking gateways and access gateways alike, to collect the access codes, credit card numbers and other numbers requested by call control services.
Callエージェントは、ユーザによってダイヤルされたケタを集めるようにゲートウェイに頼むことができます。 ユーザがダイヤルする番号を集めるのに住宅のゲートウェイと共にこの施設が使用されることを意図します。 また、それはアクセスコードを集めるのに中継方式ゲートウェイとアクセスゲートウェイと共に同じく使用されるかもしれません、とクレジットカード番号と他の数は呼び出しコントロールサービスで要求しました。
An alternative procedure is for the gateway to notify the Call Agent of the dialed digits, as soon as they are dialed. However, such a procedure generates a large number of interactions. It is preferable to accumulate the dialed numbers in a buffer, and to transmit them in a single message.
ダイヤルされたケタについてCallエージェントに通知するために、ゲートウェイには交替手続きがあります、それらがダイヤルされるとすぐに。 しかしながら、そのような手順は多くの相互作用を生成します。 バッファのダイヤルされた数を蓄積して、ただ一つのメッセージでそれらを伝えるのは望ましいです。
The problem with this accumulation approach, however, is that it is hard for the gateway to predict how many numbers it needs to accumulate before transmission. For example, using the phone on our desk, we can dial the following numbers:
しかしながら、この蓄積アプローチに関する問題はそれが、トランスミッションの前にいくつの数を蓄積する必要であるかをゲートウェイにおいて予測しにくいということです。 例えば、私たちの机の上に電話を使用して、私たちは以下の番号にダイヤルすることができます:
Arango, et al. Informational [Page 24] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[24ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
_______________________________________________________
| 0 | Local operator |
| 00 | Long distance operator |
| xxxx | Local extension number |
| 8xxxxxxx | Local number |
| #xxxxxxx | Shortcut to local number at|
| | other corporate sites |
| *xx | Star services |
| 91xxxxxxxxxx | Long distance number |
| 9011 + up to 15 digits| International number |
|________________________|_____________________________|
_______________________________________________________ | 0 | ローカルのオペレータ| | 00 | 長距離のオペレータ| | xxxx| 地方の内線電話番号| | 8xxxxxxx| 市内番号| | #xxxxxxx| 市内番号への近道| | | 他の法人のサイト| | *xx| 星のサービス| | 91xxxxxxxxxx| 長距離の番号| | 最大9011+15ケタ| 国際数| |________________________|_____________________________|
The solution to this problem is to load the gateway with a digit map that correspond to the dial plan. This digit map is expressed using a syntax derived from the Unix system command, egrep. For example, the dial plan described above results in the following digit map:
この問題への解決はダイヤルプランに一致しているケタ地図をゲートウェイに積むことです。 このケタ地図は、Unixシステム・コマンド、egrepから得られた構文を使用することで表されます。 例えば以下のケタ地図の結果を超えて説明されたダイヤルプラン:
(0T| 00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)
(0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx| *xx|91xxxxxxxxxx|9011x.T)
The formal syntax of the digit map is described by the DigitMap rule in the formal syntax description of the protocol (section 3.4). A Digit-Map, according to this syntax, is defined either by a "string" or by a list of strings. Each string in the list is an alternative numbering scheme, specified either as a set of digits or timers, or as regular expression. A gateway that detects digits, letters or timers will:
ケタ地図の正式な構文はプロトコル(セクション3.4)の正式な構文記述におけるDigitMap規則で説明されます。 この構文によると、Digit-地図は「ストリング」かストリングのリストによって定義されます。 リストの各ストリングは1セットのケタかタイマとして、または、正規表現として指定された代替のナンバリングスキームです。 ケタ、手紙またはタイマを検出するゲートウェイはそうするでしょう:
1) Add the event parameter code as a token to the end of an internal
state variable called the "current dial string"
1) 「現在のダイヤルストリング」と、内部の州の変数の終わりまでのトークンが呼んだようにイベントパラメタコードを加えてください。
2) Apply the current dial string to the digit map table, attempting a
match to each regular expression in the Digit Map in lexical order
2) 現在のダイヤルストリングをケタ地図テーブルに適用してください、語彙オーダーにおけるDigit Mapの各正規表現にマッチを試みて
3) If the result is under-qualified (partially matches at least one
entry in the digit map), do nothing further.
3) 結果が下の適切であるなら(ケタ地図における少なくとも1つのエントリーに部分的に合っています)、さらに何もしないでください。
If the result matches, or is over-qualified (i.e. no further digits could possibly produce a match), send the current digit string to the Call Agent. A match, in this specification, can be either a "perfect match," exactly matching one of the specified alternatives, or an impossible match, which occur when the dial string does not match any of the alternative. Unexpected timers, for example, can cause "impossible matches." Both perfect matches and impossible matches trigger notification of the accumulated digits.
結果が合っているか、または資格過剰であるなら(すなわち、どんなさらなるケタもマッチを生産できませんでした)、現在のケタストリングをCallエージェントに送ってください。 この仕様では、マッチは「似合いの二人」であることができます、まさにダイヤルストリングが代替手段のいずれにも合っていないと現れる指定された代替手段、または不可能なマッチの1つを合わせて。 例えば、予期していなかったタイマは「不可能なマッチ」を引き起こす場合があります。 似合いの二人と不可能なマッチの両方が蓄積されたケタの通知の引き金となります。
Digit maps are provided to the gateway by the Call Agent, whenever the Call Agent instructs the gateway to listen for digits.
ケタ地図はCallエージェントによってゲートウェイに提供されます、Callエージェントが、ケタの聞こうとするようゲートウェイに命令するときはいつも。
Arango, et al. Informational [Page 25] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[25ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
2.1.6. Names of events
2.1.6. イベントの名前
The concept of events and signals is central to MGCP. A Call Agent may ask to be notified about certain events occurring in an endpoint, e.g. off-hook events, and a call agent may request certain signals to be applied to an endpoint, e.g. dial-tone.
イベントと信号の概念はMGCPに主要です。 Callエージェントは、終点に起こるあるイベント、例えば、オフフックイベントに関して通知されるように頼むかもしれません、そして、呼び出しエージェントは終点(例えば、ダイヤルトーン)に適用されるようある信号に要求するかもしれません。
Events and signals are grouped in packages within which they share the same namespace which we will refer to as event names in the following. Packages are groupings of the events and signals supported by a particular type of endpoint. For instance, one package may support a certain group of events and signals for analog access lines, and another package may support another group of events and signals for video lines. One or more packages may exist for a given endpoint-type.
イベントと信号はそれらが私たちが以下にイベント名を呼ぶつもりであるのと同じ名前空間を共有するパッケージの中に分類されます。 パッケージは特定のタイプの終点によって支えられたイベントと信号の組分けです。 例えば、1個のパッケージがアナログのアクセス回線のためのイベントと信号のあるグループをサポートするかもしれません、そして、別のパッケージはビデオ系列のためのイベントと信号の別のグループをサポートするかもしれません。 1個以上のパッケージが与えられた終点タイプのために存在するかもしれません。
Event names are case insensitive and are composed of two logical parts, a package name and an event name. Both names are strings of letters, hyphens and digits, with the restriction that hyphens shall never be the first or last characters in a name. Package or event names are not case sensitive - values such as "hu", "Hu", "HU" or "hU" should be considered equal.
イベント名は、大文字と小文字を区別しなく、2つの論理的な部分、パッケージ名、およびイベント名で構成されます。 両方の名前は、手紙のストリングと、ハイフンとケタです、ハイフンが1番目であるか名前でキャラクタを決して持続しないものとするという制限で。 パッケージかイベント名が大文字と小文字を区別していません--"hu"などの値、「胡」、「胡」または「胡」が等しいと考えられるべきです。
Examples of package names are "D" (DTMF), "M" (MF), "T" (Trunk) or "L" (Line). Examples of event names can be "hu" (off hook or "hang- up" transition), "hf" (flash hook) or "0" (the digit zero).
パッケージ名に関する例は、「D」(DTMF)、「M」(mf)、「T」(トランク)または「L」(線)です。 イベント名に関する例は、"hu"(フックか「上に掛かってください」変遷の)、"hf"(フラッシュフック)または「0インチ(ケタゼロ)」であることができます。
In textual representations, the package name, when present, is
separated from the event name by a slash ("/"). The package name is
in fact optional. Each endpoint-type has a default package associated
with it, and if the package name is excluded from the event name, the
default package name for that endpoint-type is assumed. For example,
for an analog access line, the following two event names are equal:
原文の表現では、存在しているとき、スラッシュ(「/」)によってパッケージ名はイベント名と切り離されます。 事実上、パッケージ名は任意です。 それぞれの終点タイプには、それに関連しているデフォルトパッケージがあります、そして、パッケージ名がイベント名から除かれるなら、その終点タイプのためのデフォルトパッケージ名は想定されます。 例えば、アナログのアクセス回線において、以下の2つのイベント名が等しいです:
l/dl dial-tone in the line package for an analog access line.
アナログのアクセス回線のための系列パッケージの中のl/dlダイヤルトーン。
dl dial-tone in the line package (default) for an analog access
line.
アナログのアクセス回線のための系列パッケージ(デフォルト)の中のdlダイヤルトーン。
This document defines a basic set of package names and event names. Additional package names and event names can be registered with the IANA. A package definition shall define the name of the package, and the definition of each event belonging to the package. The event definition shall include the precise name of the event (i.e., the code used in MGCP), a plain text definition of the event, and, when appropriate, the precise definition of the corresponding signals, for example the exact frequencies of audio signal such as dial tones or DTMF tones.
このドキュメントは基本的なセットのパッケージ名とイベント名を定義します。 追加パッケージ名とイベント名をIANAに登録できます。 パッケージ定義はパッケージの名前、およびパッケージに属すそれぞれのイベントの定義を定義するものとします。 イベント定義はイベント(すなわち、MGCPで使用されるコード)の正確な名前、イベントのプレーンテキスト定義、および適切であり対応する信号(例えば、音声信号のダイヤルトーンかDTMFトーンなどの正確な頻度)の厳密な定義を含んでいるものとします。
Arango, et al. Informational [Page 26] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[26ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
In addition, implementers can gain experience by using experimental packages. The names of experimental packages must start with the two characters "x-"; the IANA shall not register package names that start with these characters.
さらに、implementersは、実験パッケージを使用することによって、経験を積むことができます。 実験パッケージの名前は2つのキャラクタ「x」から始まらなければなりません。 IANAはこれらのキャラクタから始まるパッケージ名を登録しないものとします。
Digits, or letters, are supported in many packages, notably "DTMF"
and "MF". Digits and letters are defined by the rules "Digit" and
"Letter" in the definition of digit maps. This definition refers to
the digits (0 to 9), to the asterisk or star ("*") and orthotrope,
number or pound sign ("#"), and to the letters "A", "B", "C" and "D",
as well as the timer indication "T". These letters can be combined in
"digit string" that represent the keys that a user punched on a dial.
In addition, the letter "X" can be used to represent all digits, and
the sign "$" can be used in wildcard notations. The need to easily
express the digit strings has a consequence on the form of event
names:
ケタ、または手紙が多くのパッケージ、著しく"DTMF"、および「mf」で支えられます。 ケタと手紙はケタ地図の定義で規則「ケタ」と「手紙」で定義されます。 この定義はアスタリスクか星(「*」)とorthotropeか、数かポンド記号(「#」)と、そして、手紙「A」、「B」、「C」、および「D」とケタ(0〜9)を呼びます、タイマ指示「T」と同様に。 ユーザがダイヤルの上にパンチしたキーを表す「ケタストリング」でこれらの手紙を結合できます。 さらに、すべてのケタを表すのに文字「X」を使用できます、そして、ワイルドカード記法で「$」というサインを使用できます。 容易にケタストリングを急送する必要性はイベント名のフォームの上に結果を持っています:
An event name that does not denote a digit should always contain at
least one character that is neither a digit, nor one of the letters
A, B, C, D, T or X. (Such names should not contain the special
signs "*", "#", "/" or "$".)
ケタを指示しないイベント名はいつもケタでなくてまた手紙A、B、C、D、TまたはXの1つでない少なくとも1文字を、含むべきです。「(そのような名前が特別なサイン「*」、「#」を含むべきでない、」、/、」 「$」、)
A Call Agent may often have to ask a gateway to detect a group of events. Two conventions can be used to denote such groups:
Callエージェントは、しばしばイベントのグループを検出するようにゲートウェイに頼まなければならないかもしれません。 そのようなグループを指示するのに2つのコンベンションを使用できます:
* The wildcard convention can be used to detect any event belonging
to a package, or a given event in many packages, or event any
event in any package supported by the gateway.
* どんなイベントもどんなパッケージの中のどんなイベントもゲートウェイで支えた多くのパッケージ、またはイベントでパッケージ、または与えられたイベントに属すのを検出するのにワイルドカードコンベンションを使用できます。
* The regular expression Range notation can be used to detect a
range of digits.
* さまざまなケタを検出するのに正規表現Range記法を使用できます。
The star sign (*) can be used as a wildcard instead of a package name, and the keyword "all" can be used as a wildcard instead of an event name:
パッケージ名の代わりにワイルドカードとして星座(*)を使用できます、そして、イベント名の代わりにワイルドカードとして「すべて」というキーワードを使用できます:
A name such as "foo/all" denotes all events in package "foo"
A name such as "*/bar" denotes the event "bar" in any package
supported by the gateway
The names "*" or "*/all" denote all events supported by the
gate way.
「fooに、」 Aは」 */バーとしてそのようなものを命名すること」がイベント「バー」を指示するいずれもパッケージするパッケージの中のすべてのイベントが、ゲートウェイのそばで名前」 「*」か*/がすべてであるとサポートしました。「Aがそのようなものを命名する、「foo/、すべて」、指示、」 ゲートウェイによってサポートされたすべてのイベントを指示してください。
The call agent can ask a gateway to detect a set of digits or letters either by individually describing those letters, or by using the "range" notation defined in the syntax of digit strings. For example, the call agent can:
呼び出しエージェントは、個別にそれらの手紙について説明するか、またはケタストリングの構文で定義された「範囲」記法を使用することによって1セットのケタか手紙を検出するようにゲートウェイに頼むことができます。 例えば、呼び出しエージェントはそうすることができます:
Arango, et al. Informational [Page 27] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[27ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Use the letter "x" to denote "any letter or digit."
Use the notation "[0-9#]" to denote the digits 0 to 9 and the pound
sign.
文字「x」を使用して、「どんな手紙やケタも」を指示してください。 0〜9にケタを指示する「[0-9#]」という記法とポンド記号を使用してください。
In some cases, Call Agents will request the gateway to generate or detect events on connections rather than on the end point itself. For example, gateways may be asked to provide a ringback tone on a connection. When an event shall be applied on a connection, the name of the connection is added to the name of the event, using an "at" sign (@) as a delimiter, as in:
いくつかの場合、Callエージェントは、エンドポイント自体でというよりむしろ接続にイベントを生成するか、または検出するようゲートウェイに要求するでしょう。 例えば、ゲートウェイが接続のringbackトーンを提供するように頼まれるかもしれません。 イベントが接続のときに適用されるものとするとき、接続の名前はイベントの名前に追加されます、以下デリミタとして“at"サイン(@)を使用して
G/rt@0A3F58
G/rt@0A3F58
The wildcard character "*" (star) can be used to denote "all connections". When this convention is used, the gateway will generate or detect the event on all the connections that are connected to the endpoint. An example of this convention could be:
「すべての接続」を指示するのにワイルドカードキャラクタ「*」(星)を使用できます。 このコンベンションが使用されているとき、ゲートウェイは、終点に接されるすべての接続に、イベントを生成するか、または検出するでしょう。 このコンベンションに関する例は以下の通りであるかもしれません。
R/qa@*
R/qa@*
The wildcard character "$" can be used to denote "the current connection." It should only be used by the call agent, when the event notification request is "encapsulated" within a command creation or modification command. When this convention is used, the gateway will generate or detect the event on the connection that is currently being created or modified. An example of this convention is:
「現在の接続」を指示するのにワイルドカードキャラクタ「$」を使用できます。 それは呼び出しエージェントによって使用されるだけであるべきです、イベント通知要求がコマンド作成か変更命令の中で「カプセル化される」とき。 このコンベンションが使用されているとき、ゲートウェイは、現在創造されるか、または変更されている接続に、イベントを生成するか、または検出するでしょう。 このコンベンションに関する例は以下の通りです。
G/rt@$
G/rt@$
The connection id, or a wildcard replacement, can be used in conjunction with the "all packages" and "all events" conventions. For example, the notation:
「すべてのパッケージ」と「すべてのイベント」コンベンションに関連して接続イド、またはワイルドカード交換を使用できます。 例えば、記法:
*/all@*
* /all@*
can be used to designate all events on all connections.
すべての接続でのすべてのイベントを指定するのに使用できます。
Events and signals are described in packages. The package description must provide, for each events, the following informations:
イベントと信号はパッケージの中に説明されます。 パッケージ記述はイベント、以下の情報をそれぞれに提供しなければなりません:
* The description of the event and its purpose, which should mean
the actual signal that is generated by the client (i.e., xx ms FSK
tone) as well as the resulting user observed result (i.e., MW
light on/off).
* イベントとその目的の記述。(その記述は、結果として起こるユーザと同様にクライアントによって生成される(すなわち、xx ms FSKは調子を変えます)実際の信号が結果(すなわち、下にMW光が/にある状態で)を観測したことを意味するべきです)。
* The detailed characteristics of the event, such as for example
frequencies and amplitude of audio signals, modulations and
repetitions,
* イベントの音声信号、変調、および反復の例えば、頻度や振幅などの詳細な特性
Arango, et al. Informational [Page 28] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[28ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
* The typical and maximum duration of the event.
* イベントの典型的で最大の持続時間。
Signals are divided into different types depending on their behavior:
信号は彼らの振舞いを当てにする異なったタイプに分割されます:
* On/off (OO) Once applied, these signals last forever until they
are turned off. This may happen either as the result of an event
or a new SignalRequests (see later).
* オンであるかオフな(OO)は一度適用して、それらがオフにされるまで、これらの信号はいつまでも続きます。 これはイベントの結果か新しいSignalRequestsとして起こるかもしれません(後で見てください)。
* Time-out (TO) Once applied, these signals last until they are
either turned off (by an event or SignalRequests) or a signal
specific period of time has elapsed. Depending on package
specifications, a signal that times out may generate an "operation
complete" event.
* タイムアウト(TO)が一度適用されたか、それらがオフにされるまで(イベントかSignalRequests)、これらの信号がもつか、または信号の特定の期間は経過しました。 パッケージ仕様、回のアウトが「操作完全な」イベントを生成するかもしれないという信号によります。
* Brief (BR) The duration of these signals is so short, that they
stop on their own. If an event occurs the signal will not stop,
however if a new SignalRequests is applied, the signal will stop.
(Note: this point should be debated. One could make a case that
events such as strings of DTMF digits should in fact be allowed to
complete.)
* これらの持続時間が示す要約(BR)はとても短く、彼らはそれら自身のに上に乗っています。 イベントが起こると、信号は止まらないで、新しいSignalRequestsが適用されていると、しかしながら、信号は止まるでしょう。 (以下に注意してください。 このポイントは討論されるべきです。 1つは事実上、DTMFケタのストリングなどのイベントが完成できるべきである弁護をするかもしれません。)
TO signals are normally used to alert the endpoints' users, to
signal them that they are expected to perform a specific action,
such as hang down the phone (ringing). Transmission of these
signals should typically be interrupted as soon as the first of
the requested events has been produced.
通常、TO信号は、終点のユーザの注意を喚起して、彼らが特定の動作を実行すると予想されると彼らに合図するのに使用されます(鳴らします)。動作は電話を垂らします。 要求されたイベントの1番目を生産してあるとすぐに、これらの信号の伝達は通常中断されるべきです。
Package descriptions should describe, for all signals, their type
(OO, TO, BR). They should also describe the maximum duration of
the TO signals.
パッケージ記述はすべての信号のために、彼らのタイプ(OO、TO、BR)について説明するべきです。 また、彼らはTO信号の最大の持続時間について説明するべきです。
2.2. Usage of SDP
2.2. SDPの使用法
The Call Agent uses the MGCP to provision the gateways with the description of connection parameters such as IP addresses, UDP port and RTP profiles. These descriptions will follow the conventions delineated in the Session Description Protocol which is now an IETF proposed standard, documented in RFC 2327.
CallエージェントはIPアドレス、UDPなどの接続パラメタの記述があるゲートウェイが移植して、RTPが輪郭を描く支給にMGCPを使用します。 これらの記述は現在RFC2327に記録されたIETF提案された標準であるSession記述プロトコルで図で表わされたコンベンションを次に続かせるでしょう。
SDP allows for description of multimedia conferences. This version limits SDP usage to the setting of audio circuits and data access circuits. The initial session descriptions contain the description of exactly one media, of type "audio" for audio connections, "nas" for data access.
SDPはマルチメディア会議の記述を考慮します。 このバージョンはSDP用法をオーディオ回路とデータ・アクセス回路の設定に制限します。 初期のセッション記述はまさに1つのメディア、オーディオ接続のためのタイプ「オーディオ」、データ・アクセスのための"nas"の記述を含んでいます。
Arango, et al. Informational [Page 29] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[29ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
2.3. Gateway Control Commands
2.3. ゲートウェイ制御コマンド
This section describes the commands of the MGCP. The service consists of connection handling and endpoint handling commands. There are nine commands in the protocol:
このセクションはMGCPのコマンドについて説明します。 サービスは接続取り扱いと終点取り扱い命令から成ります。 プロトコルには9つのコマンドがあります:
* The Call Agent can issue an EndpointConfiguration command to a
gateway, instructing the gateway about the coding characteristics
expected by the "line-side" of the endpoint.
* Callエージェントはゲートウェイ、コード化の特性の周りのゲートウェイが終点の「系列側」で予想した命令にEndpointConfigurationコマンドを発行できます。
* The Call Agent can issue a NotificationRequest command to a
gateway, instructing the gateway to watch for specific events such
as hook actions or DTMF tones on a specified endpoint .
* CallエージェントはNotificationRequestコマンドをゲートウェイに発行できます、指定された終点でフック動作かDTMFトーンなどの特定のイベントに注意するようゲートウェイに命令して。
* The gateway will then use the Notify command to inform the Call
Agent when the requested events occur.
* そして、ゲートウェイは要求されたイベントがいつ起こるかをCallエージェントに知らせるNotifyコマンドを使用するでしょう。
* The Call Agent can use the CreateConnection command to create a
connection that terminates in an "endpoint" inside the gateway.
* Callエージェントはゲートウェイの中で「終点」で終わる接続を創造するCreateConnectionコマンドを使用できます。
* The Call Agent can use the ModifyConnection command to change the
parameters associated to a previously established connection.
* Callエージェントは以前に確立した接続に関連づけられたパラメタを変えるModifyConnectionコマンドを使用できます。
* The Call Agent can use the DeleteConnection command to delete an
existing connection. The DeleteConnection command may also be used
by a gateway to indicate that a connection can no longer be
sustained.
* Callエージェントは既存の接続を削除するDeleteConnectionコマンドを使用できます。 また、DeleteConnectionコマンドはゲートウェイによって使用されて、もう接続を支えることができないのを示すかもしれません。
* The Call Agent can use the AuditEndpoint and AuditConnection
commands to audit the status of an "endpoint" and any connections
associated with it. Network management beyond the capabilities
provided by these commands are generally desirable, e.g.
information about the status of the gateway. Such capabilities are
expected to be supported by the use of the Simple Network
Management Protocol (SNMP) and definition of a MIB which is
outside the scope of this specification.
* CallエージェントはAuditEndpointと「終点」の状態とそれに関連しているどんな接続も監査するAuditConnectionコマンドを使用できます。 一般に、これらのコマンドで提供された能力を超えたネットワークマネージメントは例えば望ましいです。ゲートウェイの状態の情報。 Simple Network Managementプロトコル(SNMP)の使用とこの仕様の範囲の外にあるMIBの定義でそのような能力がサポートされると予想されます。
* The Gateway can use the RestartInProgress command to notify the
Call Agent that the gateway, or a group of endpoints managed by
the gateway, is being taken out of service or is being placed back
in service.
* ゲートウェイはゲートウェイ、またはゲートウェイによって管理された終点のグループを使われなくなっていた状態で取っているか、または使用中の状態で元の場所に置いているようにCallエージェントに通知するRestartInProgressコマンドを使用できます。
These services allow a controller (normally, the Call Agent) to instruct a gateway on the creation of connections that terminate in an "endpoint" attached to the gateway, and to be informed about events occurring at the endpoint. An endpoint may be for example:
これらのサービスで、コントローラ(通常Callエージェント)は命令できます。そして、「終点」で終わる接続の作成のゲートウェイがゲートウェイに付いた、終点に起こるイベントに関して知識があるために。 例えば、終点は以下の通りです。
Arango, et al. Informational [Page 30] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[30ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
* A specific trunk circuit, within a trunk group terminating in a
gateway,
* ゲートウェイで終わるトランクグループの中の特定のトランク回路
* A specific announcement handled by an announcement server.
* 発表サーバによって扱われた特定の発表。
Connections are grouped into "calls". Several connections, that may or may not belong to the same call, can terminate in the same endpoint . Each connection is qualified by a "mode" parameter, which can be set to "send only" (sendonly), "receive only" (recvonly), "send/receive" (sendrecv), "conference" (confrnce), "data", "inactive" (inactive), "loopback", "continuity test" (conttest), "network loop back" (netwloop) or "network continuity test" (netwtest).
コネクションズは「呼び出し」に分類されます。 いくつかの接続、それは同じ呼び出しに属すかもしれなくて、同じ終点で終わることができます。各接続は設定できる「モード」パラメタによって資格がある、「「不活発である」(不活発な)(sendrecv)、「会議」(confrnce)が、」 (sendonly)だけ、を送ってください、「受信専用であること」を(recvonlyします)「送るか、または受ける」という「データ」、「ループバック」、「連続テスト」(最もconttest)、「ネットワークループバック」(netwloop)または「ネットワーク連続テスト。」(最もnetwtest)
The handling of the audio signals received on these connections is determined by the mode parameters:
これらの接続のときに受け取られた音声信号の取り扱いはモードパラメタで決定します:
* Audio signals received in data packets through connections in
"receive", "conference" or "send/receive" mode are mixed and sent
to the endpoint.
* 音声信号は、データ・パケットで「受信してください」、「会議」における接続で受信するか、または複雑であり、終点に送られたモードを「送るか、または受けます」。
* Audio signals originating from the endpoint are transmitted over
all the connections whose mode is "send", "conference" or
"send/receive."
* 終点から発する音声信号がモードが「発信してください」、「会議」であるすべての接続の上に送られる、「送るか、落手」
* In addition to being sent to the endpoint, audio signals received
in data packets through connections in "conference" mode are
replicated to all the other connections whose mode is
"conference."
* 終点に送ることに加えて、「会議」モードにおける接続によるデータ・パケットに受け取られた音声信号はモードが「会議」である他のすべての接続に模写されます。
The "loopback" and "continuity test" modes are used during maintenance and continuity test operations. There are two flavors of continuity test, one specified by ITU and one used in the US. In the first case, the test is a loopback test. The originating switch will send a tone (the go tone) on the bearer circuit and expect the terminating switch to loopback the circuit. If the originating switch sees the same tone returned (the return tone), the COT has passed. If not, the COT has failed. In the second case, the go and return tones are different. The originating switch sends a certain go tone. The terminating switch detects the go tone, it asserts a different return tone in the backwards direction. When the originating switch detects the return tone, the COT is passed. If the originating switch never detects the return tone, the COT has failed.
「ループバック」と「連続テスト」モードは維持と連続テスト操作の間、使用されます。 米国で使用される連続テスト、ITUによって指定されたもの、および1の2つの風味があります。 前者の場合、テストは折返しテストです。 由来しているスイッチは、トーン(碁のトーン)を運搬人サーキットに送って、終わりスイッチをループバックに予想するでしょう。サーキット。 由来しているスイッチが、(リターントーン)が同じトーンに返されるのを見るなら、COTは通りました。 そうでなければ、COTは失敗しました。 2番目の場合では、碁とリターントーンは異なっています。 由来しているスイッチはある碁のトーンを送ります。 終わりスイッチは碁のトーンを検出して、それは異なったリターントーンについて遅れている方向に断言します。 由来しているスイッチがリターントーンを検出すると、COTは渡されます。 由来しているスイッチがリターントーンを決して検出しないなら、COTは失敗しました。
If the mode is set to "loopback", the gateway is expected to return the incoming signal from the endpoint back into that same endpoint. This procedure will be used, typically, for testing the continuity of trunk circuits according to the ITU specifications.
モードが「ループバック」に設定されるなら、ゲートウェイが入って来る信号を終点からその同じ終点に返して戻すと予想されます。 この手順は、ITU仕様通りにトランクサーキットの連続をテストするのに通常用いられるでしょう。
Arango, et al. Informational [Page 31] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[31ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
If the mode is set to "continuity test", the gateway is informed that the other end of the circuit has initiated a continuity test procedure according to the GR specification. The gateway will place the circuit in the transponder mode required for dual-tone continuity tests.
モードが「連続テスト」に設定されるなら、ゲートウェイはサーキットのもう一方の端がGR仕様通りに連続テスト手順に着手したと知らされます。 ゲートウェイは二元的なトーン連続テストに必要であるトランスポンダーモードにサーキットを置くでしょう。
If the mode is set to "network loopback", the audio signals received from the connection will be echoed back on the same connection.
モードが「ネットワークループバック」に設定されると、接続から受け取られた音声信号は同じ接続のときにecho backでしょう。
If the mode is set to "network continuity test", the gateway will process the packets received from the connection according to the transponder mode required for dual-tone continuity test, and send the processed signal back on the connection.
モードが「ネットワーク連続テスト」に設定されると、ゲートウェイは、二元的なトーン連続テストに必要であるトランスポンダーモードによって接続から受け取られたパケットを処理して、接続のときに処理信号を返送するでしょう。
2.3.1. EndpointConfiguration
2.3.1. EndpointConfiguration
The EndpointConfiguration commands are used to specify the encoding of the signals that will be received by the endpoint. For example, in certain international telephony configurations, some calls will carry mu-law encoded audio signals, while other will use A-law. The Call Agent will use the EndpointConfiguration command to pass this information to the gateway. The configuration may vary on a call by call basis, but can also be used in the absence of any connection.
EndpointConfigurationコマンドは、終点によって受信される信号のコード化を指定するのに使用されます。 例えば、ある国際的な電話構成では、いくつかの呼び出しがμ法のコード化された音声信号を運んで、他間、A-法を使用するでしょう。 Callエージェントはこの情報をゲートウェイに通過するEndpointConfigurationコマンドを使用するでしょう。 構成を呼び出しのときに呼び出し基礎で異なるかもしれませんが、また、どんな接続がないとき使用できます。
ReturnCode
<-- EndpointConfiguration( EndpointId,
BearerInformation)
ReturnCode<--EndpointConfiguration(EndpointId、BearerInformation)
EndpointId is the name for the endpoint in the gateway where EndpointConfiguration executes, as defined in section 2.1.1. The "any of" wildcard convention shall not be used. If the "all of" wildcard convention is used, the command applies to all the endpoint whose name matches the wildcard.
EndpointIdはEndpointConfigurationが定義されたコネとしてセクション2.1.1を実行するゲートウェイの終点への名前です。 「」 ワイルドカードでは、コンベンションを少しも使用しないものとします。 「」 ワイルドカードコンベンションのすべてが使用されている、コマンドは名前がワイルドカードに合っているすべての終点に適用されます。
BearerInformation is a parameter defining the coding of the data received from the line side. These information is encoded as a list of sub-parameters. The only sub-parameter defined in this version of the specification is the encoding method, whose values can be set to "A-law" and "mu-law".
BearerInformationは線側から受け取られたデータのコード化を定義するパラメタです。 これらの情報はサブパラメタのリストとしてコード化されます。 仕様のこのバージョンで定義された唯一のサブパラメタがコード化方法です。「A-法」と「μ法」にその値を設定できます。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCodeはゲートウェイによって返されたパラメタです。 それは、コマンドの結果を示して、論評が任意にあとに続いた整数から成ります。
Arango, et al. Informational [Page 32] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[32ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
2.3.2. NotificationRequest
2.3.2. NotificationRequest
The NotificationRequest commands are used to request the gateway to send notifications upon the occurrence of specified events in an endpoint. For example, a notification may be requested for when a gateway detects that an endpoint is receiving tones associated with fax communication. The entity receiving this notification may decide to use a different type of encoding method in the connections bound to this endpoint.
NotificationRequestコマンドは、終点の指定された出来事の発生のときに通告を送るようゲートウェイに要求するのに使用されます。 例えば、ゲートウェイがそれを検出するとき、終点がファックスコミュニケーションに関連しているトーンを受けているので、通知は要求されているかもしれません。 この通知を受け取る実体は、この終点に縛られた接続に方法をコード化する異なったタイプを使用すると決めるかもしれません。
ReturnCode
<-- NotificationRequest( EndpointId,
[NotifiedEntity,]
[RequestedEvents,]
RequestIdentifier,
[DigitMap,]
[SignalRequests,]
[QuarantineHandling,]
[DetectEvents,]
[encapsulated EndpointConfiguration])
ReturnCode<--NotificationRequest(EndpointId、[NotifiedEntity][RequestedEvents]RequestIdentifier[DigitMap][SignalRequests][QuarantineHandling][DetectEvents][EndpointConfigurationを要約します])
EndpointId is the name for the endpoint in the gateway where NotificationRequest executes, as defined in section 2.1.1.
EndpointIdはNotificationRequestが定義されたコネとしてセクション2.1.1を実行するゲートウェイの終点への名前です。
NotifiedEntity is an optional parameter that specifies where the notifications should be sent. When this parameter is absent, the notifications should be sent to the originator of the NotificationRequest.
NotifiedEntityは通知がどこに送られるべきであるかを指定する任意のパラメタです。 このパラメタが欠けているとき、NotificationRequestの創始者に通知を送るべきです。
RequestIdentifier is used to correlate this request with the notifications that it triggers.
RequestIdentifierは、それが引き金となる通知でこの要求を関連させるのに使用されます。
RequestedEvents is a list of events that the gateway is requested to detect and report. Such events include, for example, fax tones, continuity tones, or on-hook transition. To each event is associated an action, which can be:
RequestedEventsはゲートウェイが検出して、報告するよう要求されている出来事のリストです。 そのような出来事は例えばファックストーン、連続トーン、またはフックにおける変遷を含んでいます。 関連づけられた各出来事、動作。(その動作は以下の通りであることができます)。
* Notify the event immediately, together with the accumulated list
of observed events,
* 至急観測された出来事の蓄積されたリストと共に出来事に通知してください。
* Swap audio,
* オーディオを交換してください。
* Accumulate the event in an event buffer, but don't notify yet,
* イベントバッファにおける出来事を蓄積しなさい、ただし、まだ通知しないでください。
* Accumulate according to Digit Map,
* ケタ地図に従って、蓄積してください。
* Keep Signal(s) active,
* Signal(s)をアクティブに保ってください。
Arango, et al. Informational [Page 33] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[33ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
* process the Embedded Notification Request,
* Embedded Notification Requestを処理してください。
* Ignore the event.
* 出来事を無視してください。
Some actions can be combined. In particular:
いくつかの動作を結合できます。 特に:
* The "swap audio" action can be combined with "Notify",
"Accumulate" and "Ignore."
* 「通知してください」、「蓄積してください」、および「無視」に「スワッピングオーディオ」動作を結合できます。
* The "keep signal active" action can be combined with "Notify",
"Accumulate", "Accumulate according to Digit Map", "Ignore" and
"Embedded Notification Request."
* 「信号をアクティブに保ってください」という動作を「通知してください」に結合できます、と「蓄積してください」、「ケタ地図に従って、蓄積してください」は「無視し」て、「埋め込まれた通知は要求します」。
* The "Embedded Notification Request" can be combined with
"Accumulate" and with "Keep signals active." It can also be
combined with Notify, if the gateway is allowed to issue several
Notify commands in response to a single Notification request.
* 「蓄積してください」と「信号をアクティブに保ってください」に「埋め込まれた通知要求」を結合できます。 また、それをNotifyに結合できます、ゲートウェイがただ一つのNotification要求に対応していくつかのNotifyコマンドを発行できるなら。
In addition to the requestedEvents parameter specified in the command, some profiles of MGCP have introduced the concept of "persistent events." According to such profiles, the persistent event list is configured in the endpoint, by means outside the scope of MGCP. The basic MGCP specification does not specify any persistent event.
コマンドで指定されたrequestedEventsパラメタに加えて、MGCPのいくつかのプロフィールが「しつこい出来事」の概念を紹介しました。 そのようなプロフィールによると、しつこいイベントリストは終点でMGCPの範囲の外の手段で構成されます。 基本のMGCP仕様はどんなしつこい出来事も指定しません。
If a persistent event is not included in the list of RequestedEvents, and the event occurs, the event will be detected anyway, and processed like all other events, as if the persistent event had been requested with a Notify action. Thus, informally, persistent events can be viewed as always being implicitly included in the list of RequestedEvents with an action to Notify, although no glare detection, etc., will be performed.
しつこい出来事がRequestedEventsのリストに含まれていなくて、出来事が起こると、出来事は、他のすべての出来事のようにとにかく検出されて、処理されるでしょう、まるでしつこい出来事がNotify動作で要求されたかのように。 いつものようにRequestedEventsのリストで動作でそれとなくNotifyに含められて、このようにして、そして、非公式に、しつこい出来事を見ることができます、ギラギラと眩しい光検出などがないのは実行されるでしょうが。
Non-persistent events are those events explicitly included in the RequestedEvents list. The (possibly empty) list of requested events completely replaces the previous list of requested events. In addition to the persistent events, only the events specified in the requested events list will be detected by the endpoint. If a persistent event is included in the RequestedEvents list, the action specified will then replace the default action associated with the event for the life of the RequestedEvents list, after which the default action is restored. For example, if "Ignore off-hook" was specified, and a new request without any off-hook instructions were received, the default "Notify off-hook" operation then would be restored. A given event MUST NOT appear more than once in a RequestedEvents.
非しつこい出来事はRequestedEventsリストに明らかに含まれていたそれらの出来事です。 要求された出来事の(ことによると空)のリストは要求された出来事の前のリストを完全に置き換えます。 しつこい出来事に加えて、要求されたイベントリストで指定された出来事だけが終点によって検出されるでしょう。 しつこい出来事がRequestedEventsリストに含まれていると、指定された動作はデフォルト動作が復元されるRequestedEventsリストの人生の出来事に関連しているデフォルト動作に取って代わるでしょう。 例えば、そして、「オフフックを無視してください」を指定して、少しもオフフック指示のない新しい要求を受け取るなら、デフォルト「フックで、通知してください」操作を復元するでしょうに。 与えられた出来事はRequestedEventsで一度より多く見えてはいけません。
Arango, et al. Informational [Page 34] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[34ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
The gateway will detect the union of the persistent events and the requested events. If an event is not specified in either list, it will be ignored.
ゲートウェイはしつこい出来事と要求された出来事の組合を検出するでしょう。 出来事がどちらのリストでも指定されないと、それは無視されるでしょう。
The Swap Audio action can be used when a gateway handles more than one active connection on an endpoint. This will be the case for three-way calling, call waiting, and possibly other feature scenarios. In order to avoid the round-trip to the Call Agent when just changing which connection is attached to the audio functions of the endpoint, the NotificationRequest can map an event (usually hook flash, but could be some other event) to a local function swap audio, which selects the "next" connection in a round robin fashion. If there is only one connection, this action is effectively a no-op.
ゲートウェイが終点における1つ以上の活発な接続を扱うとき、Swap Audio動作を使用できます。 これは三者通話、キャッチホン、およびことによると他の特徴シナリオのためにそうになるでしょう。 どの接続が終点のオーディオ機能に付けられているかをただ変えるとき、Callエージェントへの往復を避けるために、NotificationRequestは地方の機能スワッピングオーディオに出来事を写像できます(通常フラッシュを掛けますが、ある他の出来事であるかもしれません)。(それは、連続ファッションで「次」の接続を選びます)。 1つの接続しかなければ、事実上、この動作はオプアートではありません。
If signal(s) are desired to start when an event being looked for occurs, the "Embedded NotificationRequest" action can be used. The embedded NotificationRequest may include a new list of RequestedEvents, SignalRequests and a new digit map as well. The semantics of the embedded NotificationRequest is as if a new NotificationRequest was just received with the same NotifiedEntity, and RequestIdentifier. When the "Embedded NotificationRequest" is activated, the "current dial string" will be cleared; the list of observed events and the quarantine buffer will be unaffected.
探される出来事が起こるとき、信号が始まることが望まれているなら、「埋め込まれたNotificationRequest」動作を使用できます。 埋め込まれたNotificationRequestはまた、RequestedEvents、SignalRequests、および新しいケタ地図の新しいリストを含むかもしれません。 まるで新しいNotificationRequestが同じNotifiedEntity、およびRequestIdentifierと共に受け取られていた状態で正当であるかのように埋め込まれたNotificationRequestの意味論はそうです。 「埋め込まれたNotificationRequest」が活性であるときに、「現在のダイヤルストリング」はクリアされるでしょう。 観測された出来事のリストと隔離バッファは影響を受けなくなるでしょう。
MGCP implementations shall be able to support at least one level of embedding. An embedded NotificationRequest that respects this limitation shall not contain another Embedded NotificationRequest.
MGCP実現は埋め込みの少なくとも1つのレベルを支持できるでしょう。 この制限を尊敬する埋め込まれたNotificationRequestは別のEmbedded NotificationRequestを含まないものとします。
DigitMap is an optional parameter that allows the Call Agent to provision the gateways with a digit map according to which digits will be accumulated. If this optional parameter is absent, the previously defined value is retained. This parameter must be defined, either explicitly or through a previous command, if the RequestedEvent parameters contain an request to "accumulate according to the digit map." The collection of these digits will result in a digit string. The digit string is initialized to a null string upon reception of the NotificationRequest, so that a subsequent notification only returns the digits that were collected after this request. Digits that were accumulated according to the digit map are reported as any other accumulated event, in the order in which they occur. It is therefore possible that other events be accumulated may be found in between the list of digits.
DigitMapは支給へのケタ地図があるケタが蓄積されるゲートウェイをCallエージェントに許容する任意のパラメタです。 この任意のパラメタが欠けるなら、以前に定義された値は保有されます。 明らかか前のコマンドを通してこのパラメタを定義しなければなりません、RequestedEventパラメタが「ケタ地図によると蓄積する」という要求を含んでいるなら。 これらのケタの収集はケタストリングをもたらすでしょう。 ケタストリングはNotificationRequestのレセプションでヌルストリングに初期化されます、その後の通知がこの要求の後に集められたケタを返すだけであるように。 ケタ地図によると、蓄積されたケタはいかなる他の蓄積された出来事としても報告されます、それらが起こるオーダーで。 したがって、他の出来事が蓄積されて、ケタのリストの間で見つけられるかもしれないということであることは可能です。
SignalRequests is a parameter that contains the set of signals that the gateway is asked to apply to the endpoint, such as, for example ringing, or continuity tones. Signals are identified by their name, which is an event name, and may be qualified by parameters.
SignalRequestsはゲートウェイがそのようで、例えば、鳴っている終点に適用するように頼まれるという信号か連続トーンのセットを含むパラメタです。 信号は、それらの名前によって特定されて、パラメタによって資格があるかもしれません。(名前はイベント名です)。
Arango, et al. Informational [Page 35] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[35ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
The action triggered by the SignalRequests is synchronized with the collection of events specified in the RequestedEvents parameter. For example, if the NotificationRequest mandates "ringing" and the event request ask to look for an "off-hook" event, the ringing shall stop as soon as the gateway detect an off hook event. The formal definition is that the generation of all "Time Out" signals shall stop as soon as one of the requested events is detected, unless the "Keep signals active" action is associated to the specified event.
SignalRequestsによって引き起こされた動作はRequestedEventsパラメタで指定される出来事の収集と同時にします。 例えば、NotificationRequestが、「鳴ること」とイベント要求が、「オフフック」出来事を探すように頼むのを強制するなら、ゲートウェイがオフフック出来事を検出するとすぐに、鳴ることは止まるものとします。 公式の定義は要求された出来事の1つが検出されるとすぐに、すべての「タイムアウト」信号の世代が止まるものとするということです、「信号をアクティブに保ってください」という動作が指定された出来事に関連づけられない場合。
The specific definition of actions that are requested via these SignalRequests, such as the duration of and frequency of a DTMF digit, is out side the scope of MGCP. This definition may vary from location to location and hence from gateway to gateway.
そして、持続時間などのこれらのSignalRequestsを通して要求されている動作の特定の定義、側から、DTMFケタの頻度はMGCPの範囲です。 この定義は位置から位置までしたがって、ゲートウェイへのゲートウェイと異なるかもしれません。
The RequestedEvents and SignalRequests refer to the same event definitions. In one case, the gateway is asked to detect the occurrence of the event, and in the other case it is asked to generate it. The specific events and signals that a given endpoint can detect or perform are determined by the list of event packages that are supported by that end point. Each package specifies a list of events and actions that can be detected or performed. A gateway that is requested to detect or perform an event belonging to a package that is not supported by the specified endpoint shall return an error. When the event name is not qualified by a package name, the default package name for the end point is assumed. If the event name is not registered in this default package, the gateway shall return an error.
RequestedEventsとSignalRequestsは同じイベント定義について言及します。 ある場合では、ゲートウェイが出来事の発生を検出するように頼まれて、もう片方の場合では、それを発生させるように頼まれます。 与えられた終点が検出するか、または実行できる特定の出来事と信号はそのエンドポイントによって支えられるイベントパッケージのリストで決定します。 各パッケージは検出するか、または実行できる出来事と動作のリストを指定します。 指定された終点によって支えられないパッケージに属す出来事を検出するか、または実行するよう要求されているゲートウェイは誤りを返すものとします。 イベント名はパッケージ名によって資格がないとき、エンドポイントのためのデフォルトパッケージ名が想定されます。 イベント名がこのデフォルトパッケージの中に登録されないなら、ゲートウェイは誤りを返すものとします。
The Call Agent can send a NotificationRequest whose requested signal list is empty. It will do so for example when tone generation should stop.
Callエージェントは要求された信号リストが空であるNotificationRequestを送ることができます。 例えば、トーン世代が止まると、それはそうするでしょう。
The optional QuarantineHandling parameter specifies the handling of "quarantine" events, i.e. events that have been detected by the gateway before the arrival of this NotificationRequest command, but have not yet been notified to the Call Agent. The parameter provides a set of handling options:
任意のQuarantineHandlingパラメタは「隔離」出来事、すなわち、このNotificationRequestコマンドの到着の前にゲートウェイによって検出されましたが、まだCallエージェントに通知されていない出来事の取り扱いを指定します。 パラメタは1セットの取り扱いオプションを提供します:
* whether the quarantined events should be processed or discarded
(the default is to process them.)
* 検疫している出来事が処理されるべきであるか、または捨てられるべきであって(デフォルトはそれらを処理することです。)
* whether the gateway is expected to generate at most one
notification (step by step), or multiple notifications (loop), in
response to this request (the default is exactly one.)
* ゲートウェイが最も1つで通知(段階的な)を発生させると予想されるか、そして、この要求に対応した複数の通知(輪)(デフォルトはちょうど1です。)
When the parameter is absent, the default value is assumed.
パラメタが欠けているとき、デフォルト値は想定されます。
Arango, et al. Informational [Page 36] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[36ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
We should note that the quarantine-handling parameter also governs the handling of events that were detected but not yet notified when the command is received.
私たちは、また、コマンドが受け取られているとき隔離取り扱いパラメタが検出されましたが、まだ通知されていなかった出来事の取り扱いを治めることに注意するべきです。
DetectEvents is an optional parameter that specifies a list of events that the gateway is requested to detect during the quarantine period. When this parameter is absent, the events that should be detected in the quarantine period are those listed in the last received DetectEvents list. In addition, the gateway should also detect the events specified in the request list, including those for which the "ignore" action is specified.
DetectEventsはゲートウェイが隔離の期間、検出するよう要求されている出来事のリストを指定する任意のパラメタです。 このパラメタが欠けているとき、隔離時代に検出されるべきである出来事は最後の受信されたDetectEventsリストに記載されたものです。 また、さらに、ゲートウェイは要求リストで指定された出来事を検出するはずです、「無視」動作が指定されるそれらを含んでいて。
Some events and signals, such as the in-line ringback or the quality alert, are performed or detected on connections terminating in the end point rather than on the endpoint itself. The structure of the event names allow the Call Agent to specify the connection (or connections) on which the events should be performed or detected.
インラインringbackか上質の警戒などのいくつかの出来事と信号が、終点自体でというよりむしろエンドポイントで終わる接続に、実行されるか、または検出されます。 名前で、出来事が実行されるべきであるか、または検出されるべきである接続(または、接続)をCallエージェントを指定する出来事の構造。
The command may carry an encapsulated EndpointConfiguration command, that will apply to the same endpoint. When this command is present, the parameters of the EndpointConfiguration command are inserted after the normal parameters of the NotificationRequest, with the exception of the EndpointId, which is not replicated.
コマンドは要約のEndpointConfigurationコマンドを運ぶかもしれなくて、それは同じ終点に当てはまるでしょう。 このコマンドが存在しているとき、EndpointConfigurationコマンドのパラメタはNotificationRequestの正常なパラメタの後に挿入されます、EndpointIdを除いて。(EndpointIdは模写されません)。
The encapsulated EndpointConfiguration command shares the fate of the NotificationRequest command. If the NotificationRequest is rejected, the EndpointConfiguration is not executed.
要約のEndpointConfigurationコマンドはNotificationRequestコマンドの運命を共有します。 NotificationRequestが拒絶されるなら、EndpointConfigurationは実行されません。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary. .NH 3 Notifications
ReturnCodeはゲートウェイによって返されたパラメタです。 それは、コマンドの結果を示して、論評が任意にあとに続いた整数から成ります。 .NH3通知
Notifications are sent via the Notify command and are sent by the gateway when the observed events occur.
通知をNotifyコマンドで送って、観測された出来事が起こるとき、ゲートウェイは送ります。
ReturnCode
<-- Notify( EndpointId,
[NotifiedEntity,]
RequestIdentifier,
ObservedEvents)
ReturnCode<--通知してください。(EndpointId、RequestIdentifier、[NotifiedEntity]ObservedEvents)
EndpointId is the name for the endpoint in the gateway which is issuing the Notify command, as defined in section 2.1.1. The identifier should be a fully qualified endpoint identifier, including the domain name of the gateway. The local part of the name shall not use the wildcard convention.
EndpointIdはNotifyコマンドを発行しているゲートウェイの終点への名前です、セクション2.1.1で定義されるように。 識別子はゲートウェイのドメイン名を含む完全に適切な終点識別子であるべきです。 名前の地方の部分はワイルドカードコンベンションを使用しないものとします。
Arango, et al. Informational [Page 37] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[37ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
NotifiedEntity is an optional parameter that identifies the entity to which the notifications is sent. This parameter is equal to the last received value of the NotifiedEntity parameter. The parameter is absent if there was no such parameter in the triggering request. The notification is sent to the "current notified entity" or, if no such entity was ever specified, to the address from which the request was received.
NotifiedEntityは通知がどれであるかに送られた実体を特定する任意のパラメタです。 このパラメタはNotifiedEntityパラメタの最後の容認された値と等しいです。 引き金となる要求に何かそのようなパラメタがなかったなら、パラメタは欠けています。 または、「現在の通知された実体」に通知を送る、何かそのような実体が今までに要求が受け取られたアドレスに指定されなかったなら。
RequestIdentifier is parameter that repeats the RequestIdentifier parameter of the NotificationRequest that triggered this notification. It is used to correlate this notification with the request that triggered it.
RequestIdentifierはこの通知の引き金となったNotificationRequestのRequestIdentifierパラメタを繰り返すパラメタです。 それは、それの引き金となった要求でこの通知を関連させるのに使用されます。
ObservedEvents is a list of events that the gateway detected. A single notification may report a list of events that will be reported in the order in which they were detected. The list may only contain the identification of events that were requested in the RequestedEvents parameter of the triggering NotificationRequest. It will contain the events that were either accumulated (but not notified) or treated according to digit map (but no match yet), and the final event that triggered the detection or provided a final match in the digit map.
ObservedEventsはゲートウェイが検出した出来事のリストです。 ただ一つの通知はそれらが検出されたオーダーで報告される出来事のリストを報告するかもしれません。 リストは引き金となっているNotificationRequestのRequestedEventsパラメタで要求された出来事の識別を含むだけであるかもしれません。 それは、ケタ地図(いいえはまだ合っている)によって蓄積されたか(しかし、通知されません)、または扱われた出来事を含んでいて、ケタ地図に検出の引き金となったか、または決勝戦を提供した最終的な出来事を含むでしょう。
ReturnCode is a parameter returned by the call agent. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCodeは呼び出しエージェントによって返されたパラメタです。 それは、コマンドの結果を示して、論評が任意にあとに続いた整数から成ります。
2.3.3. CreateConnection
2.3.3. CreateConnection
This command is used to create a connection between two endpoints.
このコマンドは、2つの終点の間の接続を創造するのに使用されます。
ReturnCode,
ConnectionId,
[SpecificEndPointId,]
[LocalConnectionDescriptor,]
[SecondEndPointId,]
[SecondConnectionId]
<--- CreateConnection(CallId,
EndpointId,
[NotifiedEntity,]
[LocalConnectionOptions,]
Mode,
[{RemoteConnectionDescriptor |
SecondEndpointId}, ]
[Encapsulated NotificationRequest,]
[Encapsulated EndpointConfiguration])
ReturnCode、ConnectionId、[SpecificEndPointId][LocalConnectionDescriptor][SecondEndPointId][SecondConnectionId]<。--- CreateConnection(CallId、EndpointId、[NotifiedEntity][LocalConnectionOptions]モード[RemoteConnectionDescriptor| SecondEndpointId][NotificationRequestを要約しました][EndpointConfigurationを要約します])
Arango, et al. Informational [Page 38] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[38ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
A connection is defined by its endpoints. The input parameters in CreateConnection provide the data necessary to build a gateway's "view" of a connection.
接続は終点によって定義されます。 CreateConnectionの入力パラメタはゲートウェイの接続の「視点」を建てるのに必要なデータを提供します。
CallId is a globally unique parameter that identifies the call (or session) to which this connection belongs. Connections that belong to the same call share the same call-id. The call-id can be used to identify calls for reporting and accounting purposes. It does not affect the handling of connections by the gateway.
CallIdはこの接続が属する要求(または、セッション)を特定するグローバルにユニークなパラメタです。 同じ呼び出しに属すコネクションズが同じ呼び出しイドを共有します。 報告するための呼び出しと会計目的を特定するのに呼び出しイドを使用できます。 それはゲートウェイのそばで接続の取り扱いに影響しません。
EndpointId is the identifier for the connection endpoint in the gateway where CreateConnection executes. The EndpointId can be fully-specified by assigning a value to the parameter EndpointId in the function call or it may be under-specified by using the "anyone" wildcard convention. If the endpoint is underspecified, the endpoint identifier will be assigned by the gateway and its complete value returned in the SpecificEndPointId parameter of the response.
ゲートウェイの接続終点のための識別子はどこCreateConnectionであるか。EndpointId、実行します。 EndpointIdは、下のファンクションコールにおけるEndpointIdかそれがパラメタであるかもしれないことへの値を割り当てることによって指定されていた状態で「だれも」ワイルドカードコンベンションを使用することによって完全に指定できます。 終点がunderspecifiedされると、終点識別子は応答のSpecificEndPointIdパラメタで返されたゲートウェイとその完全な値によって割り当てられるでしょう。
The NotifiedEntity is an optional parameter that specifies where the Notify or DeleteConnection commands should be sent. If the parameter is absent, the Notify or DeleteConnection commands should be sent to the last received Notified Entity, or to originator of the CreateConnection command if no Notified Entity was ever received for the end point.
NotifiedEntityはNotifyかDeleteConnectionコマンドがどこに送られるべきであるかを指定する任意のパラメタです。 パラメタが欠けて、今までにエンドポイントのためにNotified Entityを全く受け取らなかったなら、NotifyかDeleteConnectionコマンドが、最後の容認されたNotified Entityに送るべきであるか、またはCreateConnectionの創始者に命令するべきです。
LocalConnectionOptions is a parameter used by the Call Agent to direct the handling of the connection by the gateway. The fields contained in LocalConnectionOptions are the following:
LocalConnectionOptionsはゲートウェイのそばで接続の取り扱いを指示するのにCallエージェントによって使用されたパラメタです。 LocalConnectionOptionsに含まれた分野は以下です:
* Encoding Method,
* 方法をコード化します。
* Packetization period,
* Packetizationの期間
* Bandwidth,
* 帯域幅
* Type of Service,
* サービスのタイプ
* Usage of echo cancellation,
* エコーキャンセルの用法
* Usage of silence suppression or voice activity detection,
* 沈黙抑圧か声のアクティビティ検出の用法
* Usage of signal level adaptation and noise level reduction, or
"gain control."
* 信号レベル適合と騒音レベル減少か、「利得制御」の用法。
* Usage of reservation service,
* 予約サービスの用法
* Usage of RTP security,
* RTPセキュリティの用法
Arango, et al. Informational [Page 39] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[39ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
* Type of network used to carry the connection.
* ネットワークのタイプは以前はよく接続を運びました。
This set of field can be completed by vendor specific optional or mandatory extensions. The encoding of the first three fields, when they are present, will be compatible with the SDP and RTP profiles:
このセットの分野は業者の特定の任意の、または、義務的な拡大で完成できます。 それらが存在しているとき、最初の3つの分野のコード化はSDPとRTPプロフィールと互換性があるでしょう:
* The encoding method shall be specified by using one or several
valid encoding names, as defined in the RTP AV Profile or
registered with the IANA.
* コード化方法は1かいくつかの妥当なコード化名を使用することによって、指定されるものとします、RTP AV Profileで定義されるか、またはIANAに登録されるように。
* The packetization period is encoded as either the length of time
in milliseconds represented by the media in a packet, as specified
in the "ptime" parameter of SDP, or as a range value, specifying
both the minimum and maximum acceptable packetization periods.
* packetizationの期間はミリセカンドで表現される時間の長さがパケットにメディアで表したどちらかとしてコード化されます、SDPの"ptime"パラメタか、範囲値として指定されるように、両方の最小の、そして、最大の許容できるpacketizationの期間を指定して。
* The bandwidth is encoded as either a single value or a range,
expressed as an integer number of kilobit per seconds.
* 帯域幅は1秒あたりのキロビットの整数として言い表されたただ一つの値か範囲のどちらかとしてコード化されます。
For each of the first three fields, the Call Agent has three options:
それぞれの最初の3つの分野に、Callエージェントは3つのオプションを持っています:
* It may state exactly one value, which the gateway will then use
for the connection,
* それはまさに1つの値を述べるかもしれません。(次に、ゲートウェイは接続にそれを使用するでしょう)。
* It may provide a loose specification, such as a list of allowed
encoding methods or a range of packetization periods,
* それは許容コード化方法かさまざまなpacketizationの期間のリストなどのゆるい仕様を提供するかもしれません。
* It may simply provide a bandwidth indication, leaving the choice
of encoding method and packetization period to the gateway.
* 方法とpacketizationの期間をゲートウェイにコード化することの選択を残して、それは単に帯域幅指示を提供するかもしれません。
The bandwidth specification shall not contradict the specification of encoding methods and packetization period. If an encoding method is specified, then the gateway is authorized to use it, even if it results in the usage of a larger bandwidth than specified.
帯域幅仕様は方法とpacketizationの期間をコード化する仕様に矛盾しないものとします。 コード化方法が指定されるなら、ゲートウェイがそれを使用するのが認可されます、指定されるより大きい帯域幅の用法をもたらしても。
The LocalConnectionOptions parameter may be absent in the case of a data call.
LocalConnectionOptionsパラメタはデータ呼び出しの場合で欠けているかもしれません。
The Type of Service specifies the class of service that will be used for the connection. When the connection is transmitted over an IP network, the parameters encodes the 8-bit type of service value parameter of the IP header. When the Type of Service is not specified, the gateway shall use a default or configured value.
ServiceのTypeは接続に利用されるサービスのクラスを指定します。 接続がIPネットワークの上に伝えられるとき、8ビット型が修理するパラメタエンコードはIPヘッダーのパラメタを評価します。 ServiceのTypeが指定されないとき、ゲートウェイはデフォルトか構成された値を使用するものとします。
The gateways can be instructed to perform a reservation, for example using RSVP, on a given connection. When a reservation is needed, the call agent will specify the reservation profile that should be used, which is either "controlled load" or "guaranteed service." The
例えば、与えられた接続のときにRSVPを使用して、ゲートウェイが予約を実行するよう命令できます。 予約が必要であるときに、呼び出しエージェントは使用されるべきであり、「制御負荷」か「保証されたサービス」のどちらかである予約プロフィールを指定するでしょう。 The
Arango, et al. Informational [Page 40] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[40ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
absence of reservation can be indicated by asking for the "best effort" service, which is the default value of this parameter. When reservation has been asked on a connection, the gateway will:
「ベストエフォート型」のサービスを求めることによって、予約の欠如を示すことができます。(サービスはこのパラメタのデフォルト値です)。 予約が接続に尋ねられたとき、ゲートウェイは尋ねられてしまうでしょう:
* start emitting RSVP "PATH" messages if the connection is in
"send-only", "send-receive", "conference", "network loop back" or
"network continuity test" mode (if a remote connection descriptor
has been received,)
* 中に接続があるならRSVP「経路」メッセージを放ち始めてください、「発信、-単に、」、「発信、-受信してください、」、「会議」、「ネットワークループバック」または「ネットワーク連続テスト」モード(リモート接続記述子を受け取ったなら)
* start emitting RSVP "RESV" messages as soon as it receives "PATH"
messages if the connection is in "receive-only", "send-receive",
"conference", "network loop back" or "network continuity test"
mode.
* 接続が「受信専用」にあるなら「経路」メッセージを受け取るとすぐに、RSVP"RESV"メッセージを放ち始めてください、「発信、-受信してください、」、「会議」(「ネットワークループバック」か「ネットワーク連続テスト」モード)
The RSVP filters will be deduced from the characteristics of the connection. The RSVP resource profiles will be deduced from the connection's bandwidth and packetization period.
RSVPフィルタは接続の特性から推論されるでしょう。 RSVPリソースプロフィールは接続の帯域幅とpacketizationの期間から推論されるでしょう。
By default, the telephony gateways always perform echo cancellation. However, it is necessary, for some calls, to turn off these operations. The echo cancellation parameter can have two values, "on" (when the echo cancellation is requested) and "off" (when it is turned off.)
デフォルトで、電話ゲートウェイはいつもエコーキャンセルを実行します。 しかしながら、それが、これらの操作をオフにするのにいくつかの呼び出しに必要です。 エコーキャンセルパラメタは2つの値、“on"(エコーキャンセルが要求されているとき)、および“off"を持つことができます。(それがオフにされるとき。)
The telephony gateways may perform gain control, in order to adapt the level of the signal. However, it is necessary, for example for modem calls, to turn off this function. The gain control parameter may either be specified as "automatic", or as an explicit number of decibels of gain. The default is to not perform gain control, which is equivalent to specifying a gain of 0 decibels.
電話ゲートウェイは、信号のレベルを適合させるために利得制御を実行するかもしれません。 しかしながら、それが、この機能をオフにするのに例えば、モデム呼び出しに必要です。 利得管理パラメータは「自動」として、または、明白な数のデシベルの利得として指定されるかもしれません。 デフォルトは利得制御を実行しないことです。(それは、0デシベルの獲得を指定するのに同等です)。
The telephony gateways may perform voice activity detection, and avoid sending packets during periods of silence. However, it is necessary, for example for modem calls, to turn off this detection. The silence suppression parameter can have two values, "on" (when the detection is requested) and "off" (when it is turned off.) The default is "off."
電話ゲートウェイは、声のアクティビティ検出を実行して、沈黙の期間、パケットを送るのを避けるかもしれません。 しかしながら、それが、この検出をオフにするのに例えば、モデム呼び出しに必要です。 沈黙抑圧パラメタは2つの値、“on"(検出が要求されているとき)、および“off"を持つことができます(それがオフにされるとき)。 デフォルトは「オフです」。
The Call agent can request the gateway to enable encryption of the audio Packets. It does so by providing an key specification, as specified in RFC 2327. By default, encryption is not used.
Callエージェントは、オーディオのPacketsの暗号化を可能にするようゲートウェイに要求できます。 それは、RFC2327で指定されるようにキー仕様を提供することによって、そうします。 デフォルトで、暗号化は使用されていません。
The Call Agent may instruct the gateway to prepare the connection on a specified type of network. The type of network is encoded as in the "connection-field" parameter of the SDP standard. Possible values are IN (Internet), ATM and LOCAL. The parameter is optional; if absent, the network is determined by the type of gateway.
Callエージェントは、指定されたタイプのネットワークに接続を用意するようゲートウェイに命令するかもしれません。 ネットワークのタイプはSDP規格の「接続分野」パラメタのようにコード化されます。 可能な値は、IN(インターネット)と、ATMとLOCALです。 パラメタは任意です。 休むなら、ネットワークはゲートウェイのタイプによって決定されます。
Arango, et al. Informational [Page 41] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[41ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
RemoteConnectionDescriptor is the connection descriptor for the remote side of a connection, on the other side of the IP network. It includes the same fields as in the LocalConnectionDescriptor, i.e. the fields that describe a session according to the SDP standard. This parameter may have a null value when the information for the remote end is not known yet. This occurs because the entity that builds a connection starts by sending a CreateConnection to one of the two gateways involved in it. For the first CreateConnection issued, there is no information available about the other side of the connection. This information may be provided later via a ModifyConnection call. In the case of data connections (mode=data), this parameter describes the characteristics of the data connection.
RemoteConnectionDescriptorはIPネットワークの反対側における接続の遠隔地側のための接続記述子です。 それはLocalConnectionDescriptor(すなわち、SDP規格に従ってセッションについて説明する分野)のように同じ分野を含んでいます。 このパラメタには、リモートエンドのための情報がまだ知られていないと、ヌル値があるかもしれません。 それが接続を組み込む実体がそれにかかわる2門の1つにCreateConnectionを送ることによって始まるので、これは起こります。 CreateConnectionが発行した1日に、接続の反対側に関して利用可能などんな情報もありません。 後でModifyConnection呼び出しでこの情報を提供するかもしれません。 データ接続(モードはデータと等しい)の場合では、このパラメタはデータ接続の特性について説明します。
The SecondEndpointId can be used instead of the RemoteConnectionDescriptor to establish a connection between two endpoints located on the same gateway. The connection is by definition a local connection. The SecondEndpointId can be fully- specified by assigning a value to the parameter SecondEndpointId in the function call or it may be under-specified by using the "anyone" wildcard convention. If the secondendpoint is underspecified, the second endpoint identifier will be assigned by the gateway and its complete value returned in the SecondEndPointId parameter of the response.
RemoteConnectionDescriptorの代わりに同じゲートウェイに見つけられた2つの終点の間に取引関係を築くのにSecondEndpointIdを使用できます。 接続は定義上市内接続です。 ファンクションコールでパラメタSecondEndpointIdに値を割り当てることによって、SecondEndpointIdを完全に指定できますか、またはそれは下の「だれも」ワイルドカードコンベンションを使用することによって指定されているかもしれません。 secondendpointがunderspecifiedされると、2番目の終点識別子は応答のSecondEndPointIdパラメタで返されたゲートウェイとその完全な値によって割り当てられるでしょう。
Mode indicates the mode of operation for this side of the connection. The mode are "send", "receive", "send/receive", "conference", "data", "inactive", "loopback", "continuity test", "network loop back" or "network continuity test." The expected handling of these modes is specified in the introduction of the "Gateway Handling Function" section. Some end points may not be capable of supporting all modes. If the command specifies a mode that the endpoint cannot support, and error shall be returned.
モードは接続の手前に運転モードを示します。 モードは「発信してください」、「受信してください」が、「会議」、「不活発である」「データ」「ループバック」、「連続テスト」、「ネットワークループバック」または「ネットワーク連続テスト」と「送るか、または受ける」ということです。 これらのモードの予想された取り扱いは「ゲートウェイ取り扱い機能」セクションの導入で指定されます。 いくつかのエンドポイントがすべてのモードをサポートすることができるかもしれないというわけではありません。 コマンドが終点がサポートすることができないモードを指定して、誤りが返されるものとするなら。
The gateway returns a ConnectionId, that uniquely identifies the connection within one endpoint, and a LocalConnectionDescriptor, which is a session description that contains information about addresses and RTP ports, as defined in SDP. The LocalConnectionDescriptor is not returned in the case of data connections. The SpecificEndPointId is an optional parameter that identifies the responding endpoint. It can be used when the EndpointId argument referred to a "any of" wildcard name. When a SpecificEndPointId is returned, the Call Agent should use it as the EndpointId value is successive commands referring to this call.
ゲートウェイはConnectionIdを返して、それは1つの終点、およびLocalConnectionDescriptorの中で唯一接続を特定します、SDPで定義されるように。LocalConnectionDescriptorはアドレスとRTPポートの情報を含むセッション記述です。 LocalConnectionDescriptorはデータ接続の場合で返されません。 SpecificEndPointIdは応じる終点を特定する任意のパラメタです。 EndpointId議論がaについて言及したとき、それを使用できる、「いくらか、」 ワイルドカード名について。 SpecificEndPointIdを返すとき、EndpointId値が連続したコマンドであるので、Callエージェントはこの呼び出しについて言及しながら、それを使用するべきです。
Arango, et al. Informational [Page 42] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[42ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
When a SecondEndpointId is specified, the command really creates two connections that can be manipulated separately through ModifyConnection and DeleteConnection commands. The response to the creation provides a SecondConnectionId parameter that identifies the second connection.
SecondEndpointIdが指定されるとき、コマンドは本当に別々にModifyConnectionを通して操ることができる2つの接続とDeleteConnectionコマンドを作成します。 作成への応答は2番目の接続を特定するSecondConnectionIdパラメタを提供します。
After receiving a "CreateConnection" request that did not include a RemoteConnectionDescriptor parameter, a gateway is in an ambiguous situation. Because it has exported a LocalConnectionDescriptor parameter, it can potentially receive packets. Because it has not yet received the RemoteConnectionDescriptor parameter of the other gateway, it does not know whether the packets that it receives have been authorized by the Call Agent. It must thus navigate between two risks, i.e. clipping some important announcements or listening to insane data. The behavior of the gateway is determined by the value of the Mode parameter:
RemoteConnectionDescriptorパラメタを含んでいなかった"CreateConnection"要求を受け取った後に、ゲートウェイが漠然とした状況にあります。 LocalConnectionDescriptorパラメタをエクスポートしたので、それは潜在的にパケットを受けることができます。 まだもう片方のゲートウェイのRemoteConnectionDescriptorパラメタを受け取っていないので、それは、それが受けるパケットがCallエージェントによって認可されたかどうかを知りません。 その結果、それはすなわち、2つのリスク、切り取りの間で狂気のデータの何らかの重要な発表か聴取にナビゲートしなければなりません。 ゲートウェイの動きはModeパラメタの値で決定します:
* If the mode was set to ReceiveOnly, the gateway should accept the
voice signals and transmit them through the endpoint.
* モードがReceiveOnlyに設定されるなら、ゲートウェイは、音声信号を受け入れて、終点を通してそれらを送るでしょうに。
* If the mode was set to Inactive, Loopback, Continuity Test, the
gateway should refuse the voice signals.
* モードがInactive、Loopback、Continuity Testに設定されるなら、ゲートウェイは音声信号を拒否するでしょうに。
* If the mode was set to Network Loopback or Network Continuity
Test, the gateway should perform the expected echo or Response.
* モードがNetwork LoopbackかNetwork Continuity Testに設定されるなら、ゲートウェイは予想されたエコーかResponseを実行するでしょうに。
Note that the mode values SendReceive, Conference, Data and SendOnly don't make sense in this situation. They should be treated as errors, and the command should be rejected (Error code 517).
最頻値のSendReceive、コンファレンス、Data、およびSendOnlyがこの状況で理解できないことに注意してください。 それらは誤りとして扱われるべきです、そして、コマンドは拒絶されるべきです(エラーコード517)。
The command may optionally contain an encapsulated Notification Request command, in which case a RequestIdentifier parameter will be present, as well as, optionally, the RequestedEvents DigitMap, SignalRequests, QuarantineHandling and DetectEvents parameters. The encapsulated NotificationRequest is executed simultaneously with the creation of the connection. For example, when the Call Agent wants to initiate a call to an residential gateway, it should:
コマンドは任意に任意にカプセル化されたNotification Requestコマンド、RequestIdentifierパラメタがどの場合に存在するだろうか、そして、RequestedEvents DigitMap、SignalRequests、QuarantineHandling、およびDetectEventsパラメタを含むかもしれません。 カプセル化されたNotificationRequestは同時に、接続の作成で実行されます。 Callエージェントが住宅のゲートウェイに呼び出しを開始したがっているとき、例えば、開始するべきです:
* ask the residential gateway to prepare a connection, in order to
be sure that the user can start speaking as soon as the phone goes
off hook,
* 接続を用意するように住宅のゲートウェイに頼んでください、ユーザが、電話がフックを去るとすぐに、話し始めることができるのを確信しているように
* ask the residential gateway to start ringing,
* 鳴り始めるように住宅のゲートウェイに頼んでください。
* ask the residential gateway to notify the Call Agent when the
phone goes off-hook.
* 電話がフックに動いているときにはCallエージェントに通知するように住宅のゲートウェイに頼んでください。
Arango, et al. Informational [Page 43] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[43ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
This can be accomplished in a single CreateConnection command, by also transmitting the RequestedEvent parameters for the off hook event, and the SignalRequest parameter for the ringing signal.
ただ一つのCreateConnectionコマンドでこれを達成できます、また、オフフックイベントのためにRequestedEventパラメタを伝えて、鳴る信号のためにSignalRequestパラメタを伝えることによって。
When these parameters are present, the creation and the NotificationRequests should be synchronized, which means that bothshould be accepted, or both refused. In our example, the CreateConnection may be refused if the gateway does not have sufficient resources, or cannot get adequate resources from the local network access, and the off-hook Notification-Request can be refused in the glare condition, if the user is already off-hook. In this example, the phone should not ring if the connection cannot be established, and the connection should not be established if the user is already off hook.
これらのパラメタが存在しているとき、作成とNotificationRequestsが同期するべきでしたか、(bothshouldが受け入れられることを意味します)または両方が拒否しました。 私たちの例では、ゲートウェイが十分なリソースを持たないことができませんし、また企業内情報通信網アクセスから適切なリソースを得ることができないなら、CreateConnectionを拒否するかもしれません、そして、ギラギラと眩しい光状態でオフフックNotification-要求を拒否できます、ユーザが既にフックであるなら。 この例には、接続を確立できないなら、電話は鳴るはずがなくて、ユーザがフックに既にいるなら、接続を確立するべきではありません。
The NotifiedEntity parameter, if present, applies to both the CreateConnection and the NotificationRequest command. It defines the new "notified entity" for the endpoint.
存在しているなら、NotifiedEntityパラメタはCreateConnectionとNotificationRequestコマンドの両方に適用されます。 それは新しい「通知された実体」を終点と定義します。
The command may carry an encapsulated EndpointConfiguration command, that will apply to the same endpoint. When this command is present, the parameters of the EndpointConfiguration command are inserted after the normal parameters of the CreateConnection with the exception of the EndpointId, which is not replicated. The EndpointConfiguration command may be encapsulated together with an encapsulated NotificationRequest command.
コマンドはカプセル化されたEndpointConfigurationコマンドを運ぶかもしれなくて、それは同じ終点に当てはまるでしょう。 このコマンドが存在しているとき、EndpointIdを除いて、EndpointConfigurationコマンドのパラメタはCreateConnectionの正常なパラメタの後に挿入されます。(EndpointIdは模写されません)。 EndpointConfigurationコマンドはカプセル化されたNotificationRequestコマンドと共にカプセル化されるかもしれません。
The encapsulated EndpointConfiguration command shares the fate of the CreateConnection command. If the CreateConnection is rejected, the EndpointConfiguration is not executed.
カプセル化されたEndpointConfigurationコマンドはCreateConnectionコマンドの運命を共有します。 CreateConnectionが拒絶されるなら、EndpointConfigurationは実行されません。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCodeはゲートウェイによって返されたパラメタです。 それは、コマンドの結果を示して、論評が任意にあとに続いた整数から成ります。
2.3.4. ModifyConnection
2.3.4. ModifyConnection
This command is used to modify the characteristics of a gateway's "view" of a connection. This "view" of the call includes both the local connection descriptors as well as the remote connection descriptor.
このコマンドは、ゲートウェイの接続の「視点」の特性を変更するのに使用されます。 呼び出しのこの「視点」は市内接続記述子とリモート接続記述子の両方を含んでいます。
Arango, et al. Informational [Page 44] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[44ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
ReturnCode,
[LocalConnectionDescriptor]
<--- ModifyConnection(CallId,
EndpointId,
ConnectionId,
[NotifiedEntity,]
[LocalConnectionOptions,]
[Mode,]
[RemoteConnectionDescriptor,]
[Encapsulated NotificationRequest,]
[Encapsulated EndpointConfiguration])
ReturnCode、[LocalConnectionDescriptor]<。--- ModifyConnection(CallId、EndpointId、ConnectionId[NotifiedEntity][LocalConnectionOptions][モード][RemoteConnectionDescriptor][NotificationRequestであるとカプセル化されます][EndpointConfigurationであるとカプセル化されます])
The parameters used are the same as in the CreateConnection command, with the addition of a ConnectionId that identifies the connection within the endpoint. This parameter is returned by the CreateConnection function, as part of the local connection descriptor. It uniquely identifies the connection within the context of the endpoint.
使用されるパラメタはCreateConnectionコマンドと同じです、終点の中で接続を特定するConnectionIdの追加で。 このパラメタは市内接続記述子の一部としてCreateConnection機能によって返されます。 それは終点の文脈の中で唯一接続を特定します。
The EndpointId should be a fully qualified endpoint identifier. The local name shall not use the wildcard convention.
EndpointIdは完全に適切な終点識別子であるべきです。 地方名はワイルドカードコンベンションを使用しないものとします。
The ModifyConnection command can be used to affect parameters of a connection in the following ways:
以下の方法による接続のパラメタに影響するのにModifyConnectionコマンドを使用できます:
* Provide information about the other end of the connection, through
the RemoteConnectionDescriptor.
* 接続のもう一方の端頃にRemoteConnectionDescriptorを通して情報を提供してください。
* Activate or deactivate the connection, by changing the value of
the Mode parameter. This can occur at any time during the
connection, with arbitrary parameter values.
* Modeパラメタの値を変えることによって、接続を動かすか、または非活性化してください。 これはいつでも、任意のパラメタ値との関係の間、起こることができます。
* Change the sending parameters of the connection, for example by
switching to a different coding scheme, changing the packetization
period, or modifying the handling of echo cancellation.
* 例えば、異なったコード構成に切り替わることによって、接続の送付パラメタを変えてください、packetizationの期間を変えるか、またはエコーキャンセルの取り扱いを変更して。
Connections can only be activated if the RemoteConnectionDescriptor has been provided to the gateway. The receive only mode, however, can be activated without the provision of this descriptor.
RemoteConnectionDescriptorをゲートウェイに提供した場合にだけ、コネクションズを活性化できます。 しかしながら、受信専用モードはこの記述子の支給なしで活性化できます。
The command will only return a LocalConnectionDescriptor if the local connection parameters, such as RTP ports, were modified. (Usage of this feature is actually for further study.)
RTPポートなどの市内接続パラメタが変更された場合にだけ、コマンドはLocalConnectionDescriptorを返すでしょう。 (実際にさらなる研究にはこの特徴の用法があります。)
The command may optionally contain an encapsulated Notification Request command, in which case a RequestIdentifier parameter will be present, as well as, optionnally, the RequestedEvents DigitMap, SignalRequests, QuarantineHandling and DetectEvents parameters. The
コマンドは任意にoptionnallyにカプセル化されたNotification Requestコマンド、RequestIdentifierパラメタがどの場合に存在するだろうか、そして、RequestedEvents DigitMap、SignalRequests、QuarantineHandling、およびDetectEventsパラメタを含むかもしれません。 The
Arango, et al. Informational [Page 45] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[45ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
encapsulated NotificationRequest is executed simultaneously with the modification of the connection. For example, when a connection is accepted, the calling gateway should be instructed to place the circuit in send-receive mode and to stop providing ringing tones.
カプセル化されたNotificationRequestは同時に、接続の変更で実行されます。 そして、例えば、接続を受け入れるときの呼ぶゲートウェイが回路を置いてください、命令されるべきである発信、-受信してください、モード、鳴ることを提供するのを止めるのが調子を変えます。
This can be accomplished in a single ModifyConnection command, by also transmitting the RequestedEvent parameters, for the on hook event, and an empty SignalRequest parameter, to stop the provision of ringing tones.
呼出音の支給を止めるためにまた、オンのためのRequestedEventパラメタを伝えるのによるただ一つのModifyConnectionコマンド、フックイベント、および空のSignalRequestパラメタでこれを達成できます。
When these parameters are present, the modification and the NotificationRequests should be synchronized, which means that both should be accepted, or both refused. The NotifiedEntity parameter, if present, applies to both the ModifyConnection and the NotificationRequest command.
これらのパラメタが存在しているとき、変更とNotificationRequestsは同時にするべきです(両方を受け入れるべきであったか、または両方が拒否したことを意味します)。 存在しているなら、NotifiedEntityパラメタはModifyConnectionとNotificationRequestコマンドの両方に適用されます。
The command may carry an encapsulated EndpointConfiguration command, that will apply to the same endpoint. When this command is present, the parameters of the EndpointConfiguration command are inserted after the normal parameters of the ModifyConnection with the exception of the EndpointId, which is not replicated. The EndpointConfiguration command may be encapsulated together with an encapsulated NotificationRequest command.
コマンドはカプセル化されたEndpointConfigurationコマンドを運ぶかもしれなくて、それは同じ終点に当てはまるでしょう。 このコマンドが存在しているとき、EndpointIdを除いて、EndpointConfigurationコマンドのパラメタはModifyConnectionの正常なパラメタの後に挿入されます。(EndpointIdは模写されません)。 EndpointConfigurationコマンドはカプセル化されたNotificationRequestコマンドと共にカプセル化されるかもしれません。
The encapsulated EndpointConfiguration command shares the fate of the ModifyConnection command. If the ModifyConnection is rejected, the EndpointConfiguration is not executed.
カプセル化されたEndpointConfigurationコマンドはModifyConnectionコマンドの運命を共有します。 ModifyConnectionが拒絶されるなら、EndpointConfigurationは実行されません。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCodeはゲートウェイによって返されたパラメタです。 それは、コマンドの結果を示して、論評が任意にあとに続いた整数から成ります。
2.3.5. DeleteConnection (from the Call Agent)
2.3.5. DeleteConnection(呼び出しエージェントからの)
This command is used to terminate a connection. As a side effect, it collects statistics on the execution of the connection.
このコマンドは、接続を終えるのに使用されます。 副作用として、それは接続の実行のときに統計を集めます。
ReturnCode,
Connection-parameters
<-- DeleteConnection(CallId,
EndpointId,
ConnectionId,
[Encapsulated NotificationRequest,]
[Encapsulated EndpointConfiguration])
ReturnCode、接続パラメタ<--DeleteConnection(CallId、EndpointId、ConnectionId[NotificationRequestであるとカプセル化されます][EndpointConfigurationであるとカプセル化されます])
The endpoint identifier, in this form of the DeleteConnection command, shall be fully qualified. Wildcard conventions shall not be used.
DeleteConnectionコマンドのこの形では、終点識別子は完全に資格があるものとします。 ワイルドカードコンベンションを使用しないものとします。
Arango, et al. Informational [Page 46] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[46ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
In the general case where a connection has two ends, this command has to be sent to both gateways involved in the connection. Some connections, however, may use IP multicast. In this case, they can be deleted individually.
接続が2つの端を持っている一般的な場合では、接続にかかわる両方のゲートウェイにこのコマンドを送らなければなりません。 しかしながら、IPマルチキャストを使用する接続もあるかもしれません。 この場合、個別にそれらを削除できます。
After the connection has been deleted, any loopback that has been requested for the connection should be cancelled. When all connections to an endpoint have been deleted, that endpoint should be placed in inactive mode.
接続が削除された後に、接続のために要求されているどんなループバックも取り消されるべきです。 終点とのすべての接続が削除されたとき、その終点は不活発なモードに置かれるべきです。
In response to the DeleteConnection command, the gateway returns a list of parameters that describe the status of the connection. These parameters are:
DeleteConnectionコマンドに対応して、ゲートウェイは接続の状態について説明するパラメタのリストを返します。 これらのパラメタは以下の通りです。
Number of packets sent:
パケットの数は発信しました:
The total number of RTP data packets transmitted by the sender since starting transmission on this connection. The count is not reset if the sender changes its synchronization source identifier (SSRC, as defined in RTP), for example as a result of a Modify command. The value is zero if the connection was set in "receive only" mode.
RTPデータ・パケットの総数はこの接続のときに以来伝送を始める送付者で伝わりました。 送付者が同期ソース識別子を変えるならカウントがリセットされない、(RTPで定義されるようなSSRC、例えば、Modifyコマンドの結果、。 接続が「受信専用である」モードでセットであったなら、値はゼロです。
Number of octets sent:
八重奏の数は発信しました:
The total number of payload octets (i.e., not including header or padding) transmitted in RTP data packets by the sender since starting transmission on this connection. The count is not reset if the sender changes its SSRC identifier, for example as a result of a ModifyConnection command. The value is zero if the connection was set in "receive only" mode.
この接続のときに伝送を始めて以来、ペイロード八重奏(すなわち、ヘッダーを含んでいないか、またはそっと歩かない)の総数は送付者によるRTPデータ・パケットを伝わりました。 送付者がSSRC識別子を変えるなら、カウントはリセットされません、例えば、ModifyConnectionコマンドの結果、。 接続が「受信専用である」モードでセットであったなら、値はゼロです。
Number of packets received:
パケットの数は受けました:
The total number of RTP data packets received by the sender since starting reception on this connection. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connection was set in "send only" mode.
この接続にレセプションを始めて以来データ・パケットが送付者で受けたRTPの総数。 カウントは送付者がいくつかの値を使用したなら異なったSSRCから受け取られたパケットを含んでいます。 値が接続があったならゼロが始まるということである、「」 モードだけを送ってください。
Number of octets received:
八重奏の数は受けました:
The total number of payload octets (i.e., not including header or padding) transmitted in RTP data packets by the sender since starting transmission on this connection. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connection was set in "send only" mode.
この接続のときに伝送を始めて以来、ペイロード八重奏(すなわち、ヘッダーを含んでいないか、またはそっと歩かない)の総数は送付者によるRTPデータ・パケットを伝わりました。 カウントは送付者がいくつかの値を使用したなら異なったSSRCから受け取られたパケットを含んでいます。 値が接続があったならゼロが始まるということである、「」 モードだけを送ってください。
Arango, et al. Informational [Page 47] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[47ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Number of packets lost:
パケットの数は損をしました:
The total number of RTP data packets that have been lost since the beginning of reception. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any which are late or duplicates. The count includes packets received from different SSRC, if the sender used several values. Thus packets that arrive late are not counted as lost, and the loss may be negative if there are duplicates. The count includes packets received from different SSRC, if the sender used several values. The number of packets expected is defined to be the extended last sequence number received, as defined next, less the initial sequence number received. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connection was set in "send only" mode. This parameter is omitted if the connection was set in "data" mode.
レセプションの始まり以来失われているRTPデータ・パケットの総数。 この数は、パケットの数がそれほど実際に受け取られたパケットの数を予想しませんでした、受け取られたパケットの数が最近のいずれか写しを含んでいるところでことになるように定義されます。 カウントは送付者がいくつかの値を使用したなら異なったSSRCから受け取られたパケットを含んでいます。 したがって、遅く到着するパケットは失われているように数えられません、そして、写しがあれば、損失は否定的であるかもしれません。 カウントは送付者がいくつかの値を使用したなら異なったSSRCから受け取られたパケットを含んでいます。 予想されたパケットの数は広げることであることのように最後の一連番号が受けたなるように次に定義されるように定義されて、以下は受け取られた初期シーケンス番号です。 カウントは送付者がいくつかの値を使用したなら異なったSSRCから受け取られたパケットを含んでいます。 値が接続があったならゼロが始まるということである、「」 モードだけを送ってください。 このパラメタは接続が「データ」モードでセットであったなら省略されます。
Interarrival jitter:
Interarrivalジター:
An estimate of the statistical variance of the RTP data packet interarrival time measured in milliseconds and expressed as an unsigned integer. The interarrival jitter J is defined to be the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver compared to the sender for a pair of packets. Detailed computation algorithms are found in RFC 1889. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connection was set in "send only" mode. This parameter is omitted if the connection was set in "data" mode.
ミリセカンドで測定されて、符号のない整数として言い表されたRTPデータ・パケットinterarrival時間の統計的な変化の見積り。 interarrivalジターJは、受信機のパケットスペースの違いDの平均偏差(絶対値を整える)に1組のパケットのために送付者と比べて、なるように定義されます。 細かな計算アルゴリズムはRFC1889で見つけられます。 カウントは送付者がいくつかの値を使用したなら異なったSSRCから受け取られたパケットを含んでいます。 値が接続があったならゼロが始まるということである、「」 モードだけを送ってください。 このパラメタは接続が「データ」モードでセットであったなら省略されます。
Average transmission delay:
トランスミッション遅れを平均してください:
An estimate of the network latency, expressed in milliseconds. This is the average value of the difference between the NTP timestamp indicated by the senders of the RTCP messages and the NTP timestamp of the receivers, measured when this messages are received. The average is obtained by summing all the estimates, then dividing by the number of RTCP messages that have been received. This parameter is omitted if the connection was set in "data" mode. When the gateway's clock is not synchronized by NTP, the latency value can be computed as one half of the round trip delay, as measured through RTCP. When the gateway cannot compute the one way delay or the round trip delay, the parameter conveys a null value.
ミリセカンドで言い表されたネットワーク潜在の見積り。 これがRTCPメッセージの送付者によって示されたNTPタイムスタンプと受信機に関するNTPタイムスタンプの違いの平均値である、これであるときに、測定されて、メッセージは受信されています。 すべての見積りをまとめることによって、平均を得ます、RTCPの数に応じて受け取られたメッセージがその時分割して。 このパラメタは接続が「データ」モードでセットであったなら省略されます。 NTPがゲートウェイの時計を連動させないとき、周遊旅行遅れの半分として潜在値を計算できます、RTCPを通して測定されるように。 ゲートウェイが一方通行の遅れか周遊旅行遅れを計算できないとき、パラメタはヌル値を伝えます。
For a detailed definition of these variables, refer to RFC 1889.
これらの変数の詳細な定義について、RFC1889を参照してください。
Arango, et al. Informational [Page 48] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[48ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
When the connection was set up over an ATM network, the meaning of these parameters may change:
接続がATMネットワークの上にセットアップされたとき、これらのパラメタの意味は変化するかもしれません:
Number of packets sent: The total number of ATM cells transmitted
since starting transmission on this connection.
パケットの数は発信しました: この接続のときに伝送を始めて以来、ATMセルの総数は伝わりました。
Number of octets sent:
The total number of payload octets transmitted in ATM cells.
八重奏の数は発信しました: ペイロード八重奏の総数はATMセルの中を伝わりました。
Number of packets received:
The total number of ATM cells received since starting reception on
this connection.
パケットの数は受けました: この接続にレセプションを始めて以来受け取られたATMセルの総数。
Number of octets received:
The total number of payload octets received in ATM cells.
八重奏の数は受けました: ATMセルの中で受けられたペイロード八重奏の総数。
Number of packets lost:
Should be determined as the number of cell losts, or set to zero
if the adaptation layer does not enable the gateway to assess
losses.
パケットの数は損をしました: 適合層が、ゲートウェイが損失を評価するのを可能にしないなら、セルlostsの数として断固としているか、またはゼロにセットするべきです。
Interarrival jitter:
Should be understood as the interarrival jitter between ATM cells.
Interarrivalジター: ATMセルの間のinterarrivalジターとして理解されるべきです。
Average transmission delay:
The gateway may not be able to assess this parameter over an ATM
network. It could simply report a null value.
トランスミッション遅れを平均してください: ゲートウェイはATMネットワークの上でこのパラメタを評価できないかもしれません。 それは単にヌル値を報告するかもしれません。
When the connection was set up over an LOCAL interconnect, the meaning of these parameters is defined as follows:
接続がLOCAL内部連絡の上にセットアップされたとき、これらのパラメタの意味は以下の通り定義されます:
Number of packets sent:
Not significant.
パケットの数は発信しました: 重要でない。
Number of octets sent:
The total number of payload octets transmitted over the local
connection.
八重奏の数は発信しました: ペイロード八重奏の総数は市内接続の上を伝わりました。
Number of packets received:
Not significant.
パケットの数は受けました: 重要でない。
Number of octets received:
The total number of payload octets received over the connection.
八重奏の数は受けました: 接続の上に受けられたペイロード八重奏の総数。
Number of packets lost:
Not significant. A value of zero is assumed.
パケットの数は損をしました: 重要でない。 ゼロの値は想定されます。
Arango, et al. Informational [Page 49] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[49ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Interarrival jitter:
Not significant. A value of zero is assumed.
Interarrivalジター: 重要でない。 ゼロの値は想定されます。
Average transmission delay:
Not significant. A value of zero is assumed.
トランスミッション遅れを平均してください: 重要でない。 ゼロの値は想定されます。
The standard set of connection parameters can be extended by the creation of extension parameters.
拡大パラメタの作成は接続パラメタの標準セットを広げることができます。
The command may optionally contain an encapsulated Notification Request command, in which case a RequestIdentifier parameter will be present, as well as, optionnally, the RequestedEvents DigitMap, SignalRequests, QuarantineHandling and DetectEvents parameters. The encapsulated NotificationRequest is executed simultaneously with the deletion of the connection. For example, when a user hang-up is notified, the gateway should be instructed to delete the connection and to start looking for an off hook event.
コマンドは任意にoptionnallyにカプセル化されたNotification Requestコマンド、RequestIdentifierパラメタがどの場合に存在するだろうか、そして、RequestedEvents DigitMap、SignalRequests、QuarantineHandling、およびDetectEventsパラメタを含むかもしれません。 カプセル化されたNotificationRequestは同時に、接続の削除で実行されます。 ユーザハングアップが通知されるとき、例えば、ゲートウェイが接続を削除して、オフフックイベントを探し始めるよう命令されるべきです。
This can be accomplished in a single DeleteConnection command, by also transmitting the RequestedEvent parameters, for the off hook event, and an empty SignalRequest parameter.
ただ一つのDeleteConnectionコマンドでこれを達成できます、また、RequestedEventパラメタを伝えることによって、オフフックイベント、および空のSignalRequestパラメタのために。
When these parameters are present, the DeleteConnection and the NotificationRequests should be synchronized, which means that both should be accepted, or both refused.
これらのパラメタが存在しているとき、DeleteConnectionとNotificationRequestsは連動するべきです(両方を受け入れるべきであったか、または両方が拒否したことを意味します)。
The command may carry an encapsulated EndpointConfiguration command, that will apply to the same endpoint. When this command is present, the parameters of the EndpointConfiguration command are inserted after the normal parameters of the DeleteConnection with the exception of the EndpointId, which is not replicated. The EndpointConfiguration command may be encapsulated together with an encapsulated NotificationRequest command.
コマンドはカプセル化されたEndpointConfigurationコマンドを運ぶかもしれなくて、それは同じ終点に当てはまるでしょう。 このコマンドが存在しているとき、EndpointIdを除いて、EndpointConfigurationコマンドのパラメタはDeleteConnectionの正常なパラメタの後に挿入されます。(EndpointIdは模写されません)。 EndpointConfigurationコマンドはカプセル化されたNotificationRequestコマンドと共にカプセル化されるかもしれません。
The encapsulated EndpointConfiguration command shares the fate of the DeleteConnection command. If the DeleteConnection is rejected, the EndpointConfiguration is not executed.
カプセル化されたEndpointConfigurationコマンドはDeleteConnectionコマンドの運命を共有します。 DeleteConnectionが拒絶されるなら、EndpointConfigurationは実行されません。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCodeはゲートウェイによって返されたパラメタです。 それは、コマンドの結果を示して、論評が任意にあとに続いた整数から成ります。
Arango, et al. Informational [Page 50] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[50ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
2.3.6. DeleteConnection (from the VoIP gateway)
2.3.6. DeleteConnection(VoIPゲートウェイからの)
In some circumstances, a gateway may have to clear a connection, for example because it has lost the resource associated with the connection, or because it has detected that the endpoint no longer is capable or willing to send or receive voice. The gateway terminates the connection by using a variant of the DeleteConnection command:
いくつかの事情では、ゲートウェイは接続をきれいにしなければならないかもしれません、例えば、それを検出したので、終点がもう接続に関連しているリソースを失っていなくて、またできないで、また声を送るか、または受けることを望んでいないので。 ゲートウェイはDeleteConnectionコマンドの異形を使用することによって、接続を終えます:
ReturnCode,
<-- DeleteConnection( CallId,
EndpointId,
ConnectionId,
Reason-code,
Connection-parameters)
ReturnCode、<--DeleteConnection(CallId、EndpointId、ConnectionId、理由コード、接続パラメタ)
In addition to the call, endpoint and connection identifiers, the gateway will also send the call's parameters that would have been returned to the Call Agent in response to a DeleteConnection command. The reason code indicates the cause of the disconnection.
また、呼び出し、終点、および接続識別子に加えて、ゲートウェイはDeleteConnectionコマンドに対応してCallエージェントに返された呼び出しのパラメタを送るでしょう。 理由コードは断線の原因を示します。
ReturnCode is a parameter returned by the call agent. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCodeは呼び出しエージェントによって返されたパラメタです。 それは、コマンドの結果を示して、論評が任意にあとに続いた整数から成ります。
2.3.7. DeleteConnection (multiple connections, from the Call Agent)
2.3.7. DeleteConnection(Callエージェントからの複数の接続)
A variation of the DeleteConnection function can be used by the Call Agent to delete multiple connections at the same time. The command can be used to delete all connections that relate to a Call for an endpoint:
Callエージェントは、同時に複数の接続を削除するのにDeleteConnection機能の変化を使用できます。 Callに関連するすべての接続を終点に削除するのにコマンドを使用できます:
ReturnCode,
<-- DeleteConnection( CallId,
EndpointId)
ReturnCode、<--DeleteConnection(CallId、EndpointId)
It can also be used to delete all connections that terminate in a given endpoint:
また、与えられた終点で終わるすべての接続を削除するのにそれを使用できます:
ReturnCode,
<-- DeleteConnection( EndpointId)
ReturnCode、<--DeleteConnection(EndpointId)
Finally, Call Agents can take advantage of the hierarchical naming structure of endoints to delete all the connections that belong to a group of endpoints. In this case, the "local name" component of the EndpointID will be specified using the "all value" wildcarding convention. The "any value" convention shall not be used. For example, if endpoints names are structured as the combination of a physical interface name and a circuit number, as in "X35V3+A4/13",
最終的に、Callエージェントは、終点のグループに属すすべての接続を削除するのにendointsの階層的な命名構造を利用できます。 この場合EndpointIDの「地方名」の部品が指定された使用になる、「すべての値」wildcardingコンベンション。 「どんな値も」コンベンションを使用しないものとします。 例えば、名前は終点であるなら物理インターフェース名と回路番号の組み合わせとして構造化されます、「X35V3+A4/13インチ」のように
Arango, et al. Informational [Page 51] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[51ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
the Call Agent may replace the circuit number by a wild card character "*", as in "X35V3+A4/*". This "wildcard" command instructs the gateway to delete all the connections that where attached to circuits connected to the physical interface "X35V3+A4".
Callエージェントは「X35V3+A4/*」のようにワイルドカードキャラクタ「*」に回路番号を置き換えるかもしれません。 この「ワイルドカード」コマンドは、サーキットに付けられているところで物理インターフェース「X35V3+A4"」に接続したすべての接続を削除するようゲートウェイに命令します。
After the connections have been deleted, the endpoint should be placed in inactive mode. Any loopback that has been requested for the connections should be cancelled.
接続が削除された後に、終点は不活発なモードに置かれるべきです。 接続のために要求されているどんなループバックも取り消されるべきです。
This command does not return any individual statistics or call parameters.
このコマンドは、どんな個々の統計も返しもしませんし、パラメタと呼びもしません。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCodeはゲートウェイによって返されたパラメタです。 それは、コマンドの結果を示して、論評が任意にあとに続いた整数から成ります。
2.3.8. Audit Endpoint
2.3.8. 監査終点
The AuditEndPoint command can be used by the Call Agent to find out the status of a given endpoint.
Callエージェントは、与えられた終点の状態を見つけるのにAuditEndPointコマンドを使用できます。
ReturnCode,
EndPointIdList|{
[RequestedEvents,]
[DigitMap,]
[SignalRequests,]
[RequestIdentifier,]
[NotifiedEntity,]
[ConnectionIdentifiers,]
[DetectEvents,]
[ObservedEvents,]
[EventStates,]
[BearerInformation,]
[RestartReason,]
[RestartDelay,]
[ReasonCode,]
[Capabilities]}
<--- AuditEndPoint(EndpointId,
[RequestedInfo])
ReturnCode、EndPointIdList|[RequestedEvents][DigitMap][SignalRequests][RequestIdentifier][NotifiedEntity][ConnectionIdentifiers][DetectEvents][ObservedEvents][EventStates][BearerInformation][RestartReason][RestartDelay][ReasonCode][能力]<。--- AuditEndPoint(EndpointId、[RequestedInfo])
The EndpointId identifies the endpoint that is being audited. The "all of" wildcard convention can be used to start auditing of a group of endpoints. If this convention is used, the gateway should return the list of endpoint identifiers that match the wildcard in the EndPointIdList parameter. It shall not return any parameter specific to one of these endpoints.
EndpointIdは監査されている終点を特定します。 「終点のグループのスタート監査に」 ワイルドカードコンベンションのすべてを使用できます。 このコンベンションが使用されているなら、ゲートウェイはEndPointIdListパラメタでワイルドカードに合っている終点識別子のリストを返すはずです。 それはこれらの終点の1つに特定のどんなパラメタも返さないものとします。
Arango, et al. Informational [Page 52] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[52ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
When a non-wildcard EndpointId is specified, the (possibly empty) RequestedInfo parameter describes the information that is requested for the EndpointId specified. The following endpoint info can be audited with this command:
非ワイルドカードEndpointIdが指定されるとき、(ことによると空)のRequestedInfoパラメタは指定されたEndpointIdのために要求されている情報について説明します。 このコマンドで以下の終点インフォメーションを監査できます:
RequestedEvents, DigitMap, SignalRequests, RequestIdentifier, NotifiedEntity, ConnectionIdentifiers, DetectEvents, ObservedEvents, EventStates, RestartReason, RestartDelay, ReasonCode, and Capabilities.
RequestedEvents、DigitMap、SignalRequests、RequestIdentifier、NotifiedEntity、ConnectionIdentifiers、DetectEvents、ObservedEvents、EventStates、RestartReason、RestartDelay、ReasonCode、および能力。
The response will in turn include information about each of the items for which auditing info was requested:
応答は順番におよそそれぞれ監査のインフォメーションが要求された項目の情報を含むでしょう:
* RequestedEvents: The current value of RequestedEvents the endpoint
is using including the action associated with each event.
Persistent events are included in the list.
* RequestedEvents: 各出来事に関連している動作を含む終点が使用しているRequestedEventsの現行価値。 しつこい出来事はリストに含まれています。
* DigitMap: the digit map the endpoint is currently using.
* DigitMap: 終点が現在使用しているケタ地図。
* SignalRequests: A list of the; Time-Out signals that are currently
active, On/Off signals that are currently "on" for the endpoint
(with or without parameter), and any pending Brief signals. Time-
Out signals that have timed-out, and currently playing Brief
signals are not included.
* SignalRequests: Aが記載する、。 現在活性である外の時間信号、現在終点(パラメタのあるなしにかかわらず)への“on"であるOn/オフな信号、およびどんな未定のBrief信号。 調節されて、現在プレーしているBrief信号がある時間の出ている信号含まれていません。
* RequestIdentifier, the RequestIdentifier for the last Notification
Request received by this endpoint (includes NotificationRequest
encapsulated in Connection handling primitives). If no
notification request has been received, the value zero will be
returned.
* RequestIdentifier、最後のNotification RequestのためのRequestIdentifierはこの終点(Connection取り扱い基関数で要約されたNotificationRequestを含んでいる)のそばで受信しました。 通知要求を全く受け取っていないと、値ゼロを返すでしょう。
* QuarantineHandling, the QuarantineHandling for the last
NotificationRequest received by this endpoint.
* QuarantineHandling、最後のNotificationRequestのためのQuarantineHandlingはこの終点のそばで受信しました。
* DetectEvents, the list of events that are currently detected in
quarantine mode.
* DetectEvents、現在隔離モードで検出される出来事のリスト。
* NotifiedEntity, the current notified entity for the endpoint.
* NotifiedEntity、電流は実体に終点に通知しました。
* ConnectionIdentifiers, the list of ConnectionIdentifiers for all
connections that currently exist for the specified endpoint.
* ConnectionIdentifiers、現在指定された終点に存在するすべての接続のためのConnectionIdentifiersのリスト。
* ObservedEvents: the current list of observed events for the
endpoint.
* ObservedEvents: 終点への観測された出来事の現在のリスト。
Arango, et al. Informational [Page 53] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[53ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
* EventStates: For events that have auditable states associated with
them, the event corresponding to the state the endpoint is in,
e.g., off-hook if the endpoint is off-hook. The definition of the
individual events will state if the event in question has an
auditable state associated with it.
* EventStates: 監査可能を持っている出来事に関しては、州はそれら(終点が終点がオフフックであるなら例えば、フックにある状態に対応する出来事)と交際しました。 個人種目の定義は、問題の出来事でそれに関連している監査可能状態があるかどうかと述べるでしょう。
* BearerInformation: the value of the last received
BearerInformation parameter for this endpoint.
* BearerInformation: 最終値はBearerInformationパラメタをこの終点に受け取りました。
* RestartReason: the value of the restart reason parameter in the
last RestartInProgress command issued by the endpoint, "restart"
indicating a fully functional endpoint.
* RestartReason: 最後のRestartInProgressコマンドにおける、再開理由パラメタの値は、完全に機能的な終点を示しながら、終点のそばで「再開してください。」と発行しました。
* RestartDelay: the value of the restart delay parameter if a
RestartInProgress command was issued by the endpoint at the time
of the response, or zero if the command would not include this
parameter.
* RestartDelay: RestartInProgressが命令して、コマンドが発行されなかったなら、再開遅れパラメタの値は応答、またはゼロ時点で、終点によって発行されました。このパラメタを含めてください。
* ReasonCode:the value of the Reason-Code parameter in the last
RestartInProgress or DeleteConnection command issued by the
gateway for the endpoint, or the special value 000 if the
endpoint's state is nominal.
* ReasonCode: コマンドが終点の状態であるなら終点、または特別な値000のためにゲートウェイで発行した最後のRestartInProgressかDeleteConnectionのReason-コード・パラメータの値は名目上です。
* The capabilities for the endpoint similar to the
LocalConnectionOptions parameter and including event packages and
connection modes. If there is a need to specify that some
parameters, such as e.g., silence suppression, are only compatible
with some
* LocalConnectionOptionsパラメタとイベントパッケージと接続モードを含んでいるのと同様の終点への能力。 例えば、沈黙抑圧などのいくつかのパラメタがいくつかと互換性があるだけであると指定する必要があれば
* codecs, then the gateway will return several capability sets:
* コーデックであり、次に、ゲートウェイは数個の能力セットを返すでしょう:
Compression Algorithm: a list of supported codecs. The rest of
the parameters will apply to all codecs specified in this list.
圧縮アルゴリズム: 支持されたコーデックのリスト。 パラメタの残りはこのリストで指定されたすべてのコーデックに適用されるでしょう。
Packetization Period: A single value or a range may be
specified.
Packetizationの期間: ただ一つの値か範囲が指定されるかもしれません。
Bandwidth: A single value or a range corresponding to the range
for packetization periods may be specified (assuming no silence
suppression).
帯域幅: packetizationの期間、範囲に対応するただ一つの値か範囲が指定されるかもしれません(どんな沈黙も抑圧でないと仮定して)。
Echo Cancellation: Whether echo cancellation is supported or
not.
キャンセルをまねてください: エコーキャンセルは支持されるのであるかどうか
Silence Suppression: Whether silence suppression is supported
or not.
抑圧を黙らせてください: 沈黙抑圧は支持されるのであるかどうか
Type of Service: Whether type of service is supported or not.
サービスのタイプ: サービスのタイプは支持されるのであるかどうか
Arango, et al. Informational [Page 54] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[54ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Event Packages: A list of event packages supported. The first
event package in the list will be the default package.
イベントパッケージ: パッケージが支持した出来事のリスト。 リストにおける最初のイベントパッケージはデフォルトパッケージになるでしょう。
Modes: A list of supported connection modes.
モード: 支持された接続モードのリスト。
The Call Agent may then decide to use the AuditConnection command to obtain further information about the connections.
そして、Callエージェントは、接続に関する詳細を得るAuditConnectionコマンドを使用すると決めるかもしれません。
If no info was requested and the EndpointId refers to a valid endpoint, the gateway simply returns a positive acknowledgement.
インフォメーションが全く要求されないで、EndpointIdが有効な終点について言及するなら、ゲートウェイは単に積極的な承認を返します。
If no NotifiedEntity has been specified in the last NotificationRequest, the notified entity defaults to the source address of the last NotificationRequest command received for this connection.
NotifiedEntityが全く最後のNotificationRequestで指定されていないなら、通知された実体はこの接続のために受け取られた最後のNotificationRequestコマンドのソースアドレスをデフォルトとします。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCodeはゲートウェイによって返されたパラメタです。 それは、コマンドの結果を示して、論評が任意にあとに続いた整数から成ります。
2.3.9. Audit Connection
2.3.9. 監査接続
The AuditConnection command can be used by the Call Agent to retrieve the parameters attached to a connection:
Callエージェントは接続に愛着しているパラメタを検索するのにAuditConnectionコマンドを使用できます:
ReturnCode,
[CallId,]
[NotifiedEntity,]
[LocalConnectionOptions,]
[Mode,]
[RemoteConnectionDescriptor,]
[LocalConnectionDescriptor,]
[ConnectionParameters]
<--- AuditConnection(EndpointId,
ConnectionId,
RequestedInfo)
ReturnCode、[CallId][NotifiedEntity][LocalConnectionOptions][モード][RemoteConnectionDescriptor][LocalConnectionDescriptor][ConnectionParameters]<。--- AuditConnection(EndpointId、ConnectionId、RequestedInfo)
The EndpointId parameter specifies the endpoint that handles the connection. The wildcard conventions shall not be used.
EndpointIdパラメタは接続を扱う終点を指定します。 ワイルドカードコンベンションを使用しないものとします。
The ConnectionId parameter is the identifier of the audited connection, within the context of the specified endpoint.
ConnectionIdパラメタは指定された終点の文脈の中の監査の関係に関する識別子です。
The (possibly empty) RequestedInfo describes the information that is requested for the ConnectionId within the EndpointId specified. The following connection info can be audited with this command:
(ことによると空)のRequestedInfoは指定されたEndpointIdの中のConnectionIdのために要求されている情報について説明します。 このコマンドで以下の接続インフォメーションを監査できます:
Arango, et al. Informational [Page 55] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[55ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
CallId, NotifiedEntity, LocalConnectionOptions, Mode,
RemoteConnectionDescriptor, LocalConnectionDescriptor,
ConnectionParameters
CallId、NotifiedEntity、LocalConnectionOptions、モード、RemoteConnectionDescriptor、LocalConnectionDescriptor、ConnectionParameters
The AuditConnectionResponse will in turn include information about each of the items auditing info was requested for:
AuditConnectionResponseは順番におよそそれぞれ監査のインフォメーションが要求された項目の情報を含むでしょう:
* CallId, the CallId for the call the connection belongs to.
* CallId、接続が属す呼び出しのためのCallId。
* NotifiedEntity, the current notified entity for the Connection.
* NotifiedEntity、電流はConnectionのために実体に通知しました。
* LocalConnectionOptions, the LocalConnectionOptions that was
supplied for the connection.
* LocalConnectionOptions、接続に提供されたLocalConnectionOptions。
* Mode, the current mode of the connection.
* モード、接続の現在の方法。
* RemoteConnectionDescriptor, the RemoteConnectionDescriptor that
was supplied to the gateway for the connection.
* RemoteConnectionDescriptor、接続のためにゲートウェイに供給されたRemoteConnectionDescriptor。
* LocalConnectionDescriptor, the LocalConnectionDescriptor the gate-
way supplied for the connection.
* LocalConnectionDescriptor、ゲート道が接続に提供したLocalConnectionDescriptor。
* ConnectionParameters, the current value of the connection
parameters for the connection.
* ConnectionParameters、接続への接続パラメタの現行価値。
If no info was requested and the EndpointId is valid, the gateway simply checks that the connection exists, and if so returns a positive acknowledgement.
インフォメーションが全く要求されないで、EndpointIdによる有効です、ゲートウェイが接続が存在するのを単にチェックするということであり、そうが積極的な承認を返すなら。
If no NotifiedEntity has been specified for the connection, the notified entity defaults to the source address of the last connection handling command received for this connection.
NotifiedEntityが全く接続に指定されていないなら、通知された実体はこの接続のために受け取られた最後の接続取り扱い命令のソースアドレスをデフォルトとします。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCodeはゲートウェイによって返されたパラメタです。 それは、コマンドの結果を示して、論評が任意にあとに続いた整数から成ります。
2.3.10. Restart in progress
2.3.10. 進行中で、再開してください。
The RestartInProgress command is used by the gateway to signal that An endpoint, or a group of endpoint, is taken in or out of service.
RestartInProgressコマンドは、An終点、または終点のグループが騙されると合図するゲートウェイのそばで中古であるか、または使われなくなっています。
ReturnCode,
[NotifiedEntity]
<------- RestartInProgress ( EndPointId,
RestartMethod,
[RestartDelay,]
[Reason-code])
ReturnCode、[NotifiedEntity]<。------- RestartInProgress(EndPointId、RestartMethod[RestartDelay][理由コード])
Arango, et al. Informational [Page 56] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[56ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
The EndPointId identifies the endpoint that are taken in or out of service. The "all of" wildcard convention may be used to apply the command to a group of endpoint, such as for example all endpoints that are attached to a specified interface, or even all endpoints that are attached to a given gateway. The "any of" wildcard convention shall not be used.
EndPointIdは中に入れるか、または使われなくなっていた状態で終点を特定します。 「」 ワイルドカードコンベンションのすべてが終点のグループにコマンドを適用するのに使用されるかもしれません、例えば指定されたインタフェースに付けられているすべての終点、または与えられたゲートウェイに付けられているすべての終点などのようにさえ。 「」 ワイルドカードでは、コンベンションを少しも使用しないものとします。
The RestartMethod parameter specified the type of restart. Three values have been defined:
RestartMethodパラメタは再開のタイプを指定しました。 3つの値が定義されました:
* A "graceful" restart method indicates that the specified endpoints
will Be taken out of service after the specified delay. The
established connections are not yet affected, but the Call Agent
should refrain to establish new connections, and should try to
gracefully tear down the existing connections.
* 「優雅な」再開方法は、指定された終点は指定された遅れの後に使われなくなっていた状態で取られたBeがそうするのを示します。 確立した接続がまだ影響を受けていませんが、Callエージェントは、新しい接続を証明するために控えるべきであり、優雅に既存の接続を取りこわそうとするべきです。
* A "forced" restart method indicates that the specified endpoints
are taken abruptely out of service. The established connections,
if any, are lost.
* 「無理矢理」の再開方法は、指定された終点がabruptelyに使われなくなっていた状態で取られるのを示します。 もしあれば確立した接続は迷子になっています。
* A "restart" method indicates that service will be restored on the
endpoints after the specified "restart delay." There are no
connections that are currently established on the endpoints.
* 「再開」方法は、サービスが指定された「再開遅れ」の後に終点で復元されるのを示します。 現在終点で確立される接続が全くありません。
* A "disconnected" method indicates that the endpoint has become
disconnected and is now trying to establish connectivity. The
"restart delay" specifies the number of seconds the endpoint has
been disconnected. Established connections are not affected.
* 「外された」方法は、終点が外されるようになったのを示して、現在、接続性を確立しようとしています。 「再開遅れ」は秒数を指定します。終点は外されました。 確立した接続は影響を受けません。
* A "cancel-graceful" method indicates that a gateway is canceling a
previously issued "graceful" restart command.
* 「キャンセル優雅な」方法は、ゲートウェイが以前に発行された「優雅な」再開コマンドを中止しているのを示します。
The optional "restart delay" parameter is expressed as a number of seconds. If the number is absent, the delay value should be considered null. In the case of the "graceful" method, a null delay indicates that the call agent should simply wait for the natural termination of the existing connections, without establishing new connections. The restart delay is always considered null in the case of the "forced" method.
任意の「再開遅れ」パラメタは秒数として言い表されます。 数が欠けるなら、遅れ値はヌルであると考えられるべきです。 「優雅な」方法の場合では、ヌル遅れは、呼び出しエージェントが単に既存の接続の自然な終了を待つべきであるのを示します、新しい接続を確立しないで。 再開遅れは「無理矢理」の方法の場合でヌルであるといつも考えられます。
A restart delay of null for the "restart" method indicates that service has already been restored. This typically will occur after gateway startup/reboot.
「再開」方法のためのヌルの再開遅れは、サービスが既に復元されたのを示します。 これはゲートウェイ始動/リブートの後に通常起こるでしょう。
The optional reason code parameter the cause of the restart.
任意はコード・パラメータを推論します。再開の原因。
Arango, et al. Informational [Page 57] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[57ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Gateways SHOULD send a "graceful" or "forced" RestartInProgress message as a courtesy to the Call Agent when they are taken out of service, e.g., by being shutdown, or taken out of service by a network management system, although the Call Agent cannot rely on always receiving such messages. Gateways MUST send a "restart" RestartInProgress message with a null delay to their Call Agent when they are back in service according to the restart procedure specified in Section 4.3.4 - Call Agents can rely on receiving this message. Also, gateways MUST send a "disconnected" RestartInProgress message to their current "notified entity" according to the "disconnected" procedure specified in Section 4.3.5. The "restart delay" parameter MUST NOT be used with the "forced" restart method.
彼らを例えば、閉鎖であることで使われなくなっていた状態で取るか、またはネットワーク管理システムで使われなくなっていた状態で取るとき、ゲートウェイSHOULDは礼儀として「優雅である」か「無理矢理」のRestartInProgressメッセージをCallエージェントに送ります、Callエージェントがいつもそのようなメッセージを受け取るのを当てにすることができませんが。 セクション4.3.4で指定された再開手順によると、彼らが再び使用中であるときに、ゲートウェイはヌル遅れがある「再開」RestartInProgressメッセージを彼らのCallエージェントに送らなければなりません--呼び出しエージェントはこのメッセージを受け取るのを当てにすることができます。 また、セクション4.3.5で指定された「外された」手順に応じて、ゲートウェイは「外された」RestartInProgressメッセージを彼らの現在の「通知された実体」に送らなければなりません。 「無理矢理」の再開方法で「再開遅れ」パラメタを使用してはいけません。
The RestartInProgress message will be sent to the current notified entity for the EndpointId in question. It is expected that a default Call Agent, i.e., notified entity, has been provisioned for each endpoint so, after a reboot, the default Call Agent will be the notified entity for each endpoint. Gateways should take full advantage of wild- carding to minimize the number of RestartInProgress messages generated when multiple endpoints in a gateway restart and the endpoints are managed by the same Call Agent.
問題のEndpointIdのために現在の通知された実体にRestartInProgressメッセージを送るでしょう。 デフォルトCallエージェント(すなわち、通知された実体)が各終点に食糧を供給されたと予想されるので、リブートの後にデフォルトCallエージェントは各終点への通知された実体になるでしょう。 ゲートウェイは、ゲートウェイ再開における複数の終点と終点が同じCallエージェントによって管理されるとき発生するRestartInProgressメッセージの数を最小にするのにワイルドな梳綿機を最大限に利用するはずです。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCodeはゲートウェイによって返されたパラメタです。 それは、コマンドの結果を示して、論評が任意にあとに続いた整数から成ります。
A NotifiedEntity may additionally be returned with the response from the Call Agent:
応答と共にCallエージェントからNotifiedEntityをさらに、返すかもしれません:
* If the response indicated success (return code 200 - transaction
executed), the restart procedure has completed, and the
NotifiedEntity returned is the new "notified entity" for the
endpoint(s).
* 示された成功(復帰コード200--実行された取引)、再開手順が終了して、NotifiedEntityが返した応答が終点への新しい「通知された実体」であるなら。
* If the response from the Call Agent indicated an error, the
restart procedure is not yet complete, and must therefore be
initiated again. If a NotifiedEntity parameter was returned, it
then specifies the new "notified entity" for the endpoint(s),
which must consequently be used when retrying the restart
procedure.
* Callエージェントからの応答が誤りを示したなら、再開手順をまだ完了していなくて、したがって、再び着手しなければなりません。 NotifiedEntityパラメタが返されたなら、それは新しい「通知された実体」を終点に指定します。(再開手順を再試行するとき、その結果、それを使用しなければなりません)。
2.4. Return codes and error codes.
2.4. 復帰コードとエラーコード。
All MGCP commands are acknowledged. The acknowledgment carries a return code, which indicates the status of the command. The return code is an integer number, for which four ranges of values have been defined:
すべてのMGCPコマンドが承諾されます。 承認は復帰コードを運びます。(それは、コマンドの状態を示します)。 復帰コードは整数です:(4つの範囲の値はそれにおいて定義されました)。
Arango, et al. Informational [Page 58] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[58ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
* values between 100 and 199 indicate a provisional response,
* 100と199の間の値は暫定的な応答を示します。
* values between 200 and 299 indicate a successful completion,
* 200と299の間の値は無事終了を示します。
* values between 400 and 499 indicate a transient error,
* 400と499の間の値は一時的エラーを示します。
* values between 500 and 599 indicate a permanent error.
* 500と599の間の値は永続エラーを示します。
The values that have been already defined are listed in the following list:
既に定義された値は以下のリストに記載されています:
100 The transaction is currently being executed. An actual
completion message will follow on later.
100 取引は現在、実行されています。 実際の完了メッセージは、より遅いところで従うでしょう。
200 The requested transaction was executed normally.
200 通常、要求された取引は実行されました。
250 The connection was deleted.
250 接続は削除されました。
400 The transaction could not be executed, due to a transient error.
400 一時的エラーのため取引を実行できませんでした。
401 The phone is already off hook
401 電話がフックに既にあります。
402 The phone is already on hook
402 フックの上に電話が既にあります。
403 The transaction could not be executed, because the endpoint does
not have sufficient resources at this time
403 このとき、終点には十分なリソースがないので、取引を実行できませんでした。
404 Insufficient bandwidth at this time
404 今回の不十分な帯域幅
500 The transaction could not be executed, because the endpoint is
unknown.
500 終点が未知であるので、取引を実行できませんでした。
01 The transaction could not be executed, because the endpoint is
not ready.
01 終点が準備ができていないので、取引を実行できませんでした。
502 The transaction could not be executed, because the endpoint does
not have sufficient resources
502 終点には十分なリソースがないので、取引を実行できませんでした。
510 The transaction could not be executed, because a protocol error
was detected.
510 プロトコル誤りが検出されたので、取引を実行できませんでした。
11 The transaction could not be executed, because the command
contained an unrecognized extension.
11 コマンドが認識されていない拡大を含んだので、取引を実行できませんでした。
512 The transaction could not be executed, because the gateway is
not equipped to detect one of the requested events.
512 要求された出来事の1つを検出するためにゲートウェイを備えていないので、取引を実行できませんでした。
Arango, et al. Informational [Page 59] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[59ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
513 The transaction could not be executed, because the gateway is
not equipped to generate one of the requested signals.
513 要求された信号の1つを発生させるようにゲートウェイを備えていないので、取引を実行できませんでした。
514 The transaction could not be executed, because the gateway
cannot send the specified announcement.
514 ゲートウェイが指定された発表を送ることができないので、取引を実行できませんでした。
515 The transaction refers to an incorrect connection-id (may have
been already deleted)
515 取引は不正確な接続イドを示します。(既に削除されたかもしれません)
516 The transaction refers to an unknown call-id.
516 取引は未知の呼び出しイドを示します。
517 Unsupported or invalid mode.
517 サポートされないか無効のモード。
518 Unsupported or unknown package.
518のサポートされないか未知のパッケージ。
519 Endpoint does not have a digit map.
519終点には、ケタ地図がありません。
520 The transaction could not be executed, because the endpoint is
"restarting".
520 終点が「再開している」ので、取引を実行できませんでした。
521 Endpoint redirected to another Call Agent.
別のCallエージェントに向け直された521終点。
522 No such event or signal.
522 そのような出来事か信号でない。
523 Unknown action or illegal combination of actions
523 動作の未知の動きか不法な組み合わせ
524 Internal inconsistency in LocalConnectionOptions
524 LocalConnectionOptionsでの内部の矛盾
525 Unknown extension in LocalConnectionOptions
525 LocalConnectionOptionsでの未知の拡大
526 Insufficient bandwidth
526 不十分な帯域幅
527 Missing RemoteConnectionDescriptor
527 なくなったRemoteConnectionDescriptor
528 Incompatible protocol version
528の両立しないプロトコルバージョン
529 Internal hardware failure
529 内部のハードウェアの故障
530 CAS signaling protocol error.
530CASシグナリングは誤りについて議定書の中で述べます。
531 failure of a grouping of trunks (e.g. facility failure).
531 トランクス(例えば、施設失敗)の組分けの失敗。
Arango, et al. Informational [Page 60] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[60ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
2.5. Reason Codes
2.5. 理由コード
Reason-codes are used by the gateway when deleting a connection to inform the Call Agent about the reason for deleting the connection. They may also be used in a RestartInProgress command, to inform the gateway of the Restart's reason. The reason code is an integer number, and the following values have been defined:
接続を削除する理由に関してCallエージェントに知らせるために接続を削除するとき、理由コードはゲートウェイによって使用されます。 また、それらは、Restartの理由のゲートウェイを知らせるのにRestartInProgressコマンドに使用されるかもしれません。 理由コードは整数です、そして、以下の値は定義されました:
000 Endpoint state is nominal. (This code is used only in response
to audit requests.)
000 終点州は名目上です。 (このコードは単に監査要求に対応して使用されます。)
900 Endpoint malfunctioning
900 終点誤動作
901 Endpoint taken out of service
使われなくなっていた状態で取られた901終点
902 Loss of lower layer connectivity (e.g., downstream sync)
902 下層の接続性の損失(例えば、川下の同時性)
3. Media Gateway Control Protocol
3. メディアゲートウェイ制御プロトコル
The MGCP implements the media gateway control interface as a set of transactions. The transactions are composed of a command and a mandatory response. There are eight types of command:
MGCPは1セットの取引としてメディアゲートウェイコントロールインタフェースを実行します。 取引はコマンドと義務的な応答で構成されます。 コマンドの8つのタイプがあります:
* CreateConnection
* CreateConnection
* ModifyConnection
* ModifyConnection
* DeleteConnection
* DeleteConnection
* NotificationRequest
* NotificationRequest
* Notify
* 通知してください。
* AuditEndpoint
* AuditEndpoint
* AuditConnection
* AuditConnection
* RestartInProgress
* RestartInProgress
The first four commands are sent by the Call Agent to a gateway. The Notify command is sent by the gateway to the Call Agent. The gateway may also send a DeleteConnection as defined in 2.3.6. The Call Agent may send either of the Audit commands to the gateway. The Gateway may send a RestartInProgress command to the Call Agent.
最初の4つのコマンドがCallエージェントによってゲートウェイに送られます。 ゲートウェイはNotifyコマンドをCallエージェントに送ります。 また、ゲートウェイは2.3で.6に定義されるようにDeleteConnectionを送るかもしれません。 CallエージェントはAuditコマンドのどちらかをゲートウェイに送るかもしれません。 ゲートウェイはRestartInProgressコマンドをCallエージェントに送るかもしれません。
Arango, et al. Informational [Page 61] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[61ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
3.1. General description
3.1. 概説
All commands are composed of a Command header, optionally followed by a session description.
すべてのコマンドがセッション記述が任意にあとに続いたCommandヘッダーで構成されます。
All responses are composed of a Response header, optionally followed by a session description.
すべての応答がセッション記述が任意にあとに続いたResponseヘッダーで構成されます。
Headers and session descriptions are encoded as a set of text lines, separated by a carriage return and line feed character (or, optionnally, a single line-feed character). The headers are separated from the session description by an empty line.
ヘッダーとセッション記述は復帰と改行文字(optionnallyに単独の改行キャラクタ)によって切り離された1セットのテキスト線としてコード化されます。 ヘッダーは人影のない線によってセッション記述から分離されます。
MGCP uses a transaction identifier to correlate commands and responses. The transaction identifier is encoded as a component of the command header and repeated as a component of the response header (see section 3.2.1, 3.2.1.2 and 3.3).
MGCPは、コマンドと応答を関連させるのに取引識別子を使用します。 取引識別子がコマンドヘッダーの部品としてコード化されて、応答ヘッダの部品として繰り返される、(.1が、3.2に.1、3.2を区分するのを見る、.2と3.3)
3.2. Command Header
3.2. コマンドヘッダー
The command header is composed of:
コマンドヘッダーは以下で構成されます。
* A command line, identifying the requested action or verb, the
transaction identifier, the endpoint towards which the action is
requested, and the MGCP protocol version,
* コマンドライン、要求された動作か動詞を特定する、取引識別子、動作が要求されている終点、およびMGCPはバージョンについて議定書の中で述べます。
* A set of parameter lines, composed of a parameter name followed by
a parameter value.
* パラメタ値があとに続いたパラメタ名で構成された1セットのパラメタ行。
Unless otherwise noted or dictated by other referenced standards, each component in the command header is case insensitive. This goes for verbs as well as parameters and values, and all comparisons MUST treat upper and lower case as well as combinations of these as being equal.
他の参照をつけられた規格によって別の方法で注意されるか、または書き取られない場合、コマンドヘッダーのそれぞれのコンポーネントは大文字と小文字を区別しないです。 これはパラメタと値と同様に動詞に行きます、そして、また、すべての比較が等しいとしてこれらの組み合わせとして大文字と小文字を扱わなければなりません。
3.2.1. Command line
3.2.1. コマンドライン
The command line is composed of:
コマンドラインは以下で構成されます。
* The name of the requested verb,
* 要求された動詞の名前
* The identification of the transaction,
* 取引の識別
* The name of the endpoint that should execute the command (in
notifications or restarts, the name of the endpoint that is
issuing the command),
* コマンド(通知か再開における、命令を発している終点の名前)を実行するべきである終点の名前
* The protocol version.
* プロトコルバージョン。
Arango, et al. Informational [Page 62] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[62ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
These four items are encoded as strings of printable ASCII characters, separated by white spaces, i.e. the ASCII space (0x20) or tabulation (0x09) characters. It is recommended to use exactly one ASCII space separator.
これらの4つの項目が余白によって切り離された印刷可能なASCII文字のストリングとしてコード化されます、すなわち、ASCIIスペース(0×20)か図表作成(0×09)のキャラクタ。 まさに1つのASCII宇宙分離符を使用するのはお勧めです。
3.2.1.1. Coding of the requested verb
3.2.1.1. 要求された動詞のコード化
The verbs that can be requested are encoded as four letter upper or lower case ASCII codes (comparisons should be case insensitive) as defined in the following table:
要求できる動詞は以下のテーブルで定義されるように4つの手紙の上側の、または、低いケースASCIIコードとしてコード化されます(比較は大文字と小文字を区別しないはずです):
______________________________
| Verb | Code|
|______________________|______|
| EndpointConfiguration| EPCF|
| CreateConnection | CRCX|
| ModifyConnection | MDCX|
| DeleteConnection | DLCX|
| NotificationRequest | RQNT|
| Notify | NTFY|
| AuditEndpoint | AUEP|
| AuditConnection | AUCX|
| RestartInProgress | RSIP|
|______________________|______|
______________________________ | 動詞| コード| |______________________|______| | EndpointConfiguration| EPCF| | CreateConnection| CRCX| | ModifyConnection| MDCX| | DeleteConnection| DLCX| | NotificationRequest| RQNT| | 通知してください。| NTFY| | AuditEndpoint| AUEP| | AuditConnection| AUCX| | RestartInProgress| RSIP| |______________________|______|
The transaction identifier is encoded as a string of up to 9 decimal digits. In the command lines, it immediately follows the coding of the verb.
取引識別子は一連の最大9つの10進数字としてコード化されます。 コマンドラインでは、それはすぐに、動詞のコード化に続きます。
New verbs may be defined in further versions of the protocol. It may be necessary, for experimentation purposes, to use new verbs before they are sanctioned in a published version of this protocol. Experimental verbs should be identified by a four letter code starting with the letter X, such as for example XPER.
新しい動詞はプロトコルの今後のバージョンで定義されるかもしれません。 それが、それらがこのプロトコルの発行されたバージョンで認可される前に新しい動詞を使用するのに実験目的に必要であるかもしれません。 実験動詞は文字Xから始まる例えば、XPERなどの4レター・コードによって特定されるべきです。
3.2.1.2. Transaction Identifiers
3.2.1.2. 取引識別子
MGCP uses a transaction identifier to correlate commands and responses. A gateway supports two separate transaction identifier name spaces:
MGCPは、コマンドと応答を関連させるのに取引識別子を使用します。 ゲートウェイは2つの別々の取引識別子名前空間を支持します:
a transaction identifier name space for sending transactions, and
そして送付取引のための取引識別子名前スペース。
a transaction identifier name space for receiving transactions.
取引を受けるための取引識別子名前スペース。
At a minimum, transaction identifiers for commands sent to a given gateway MUST be unique for the maximum lifetime of the transactions within the collection of Call Agents that control that gateway. Thus,
最小限では、与えられたゲートウェイに送られたコマンドのための取引識別子は取引の最大の生涯、そのゲートウェイを制御するCallエージェントの収集の中でユニークであるに違いありません。 このようにして
Arango, et al. Informational [Page 63] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[63ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
regardless of the sending Call Agent, gateways can always detect duplicate transactions by simply examining the transaction identifier. The coordination of these transaction identifiers between Call Agents is outside the scope of this specification though.
送付Callエージェントにかかわらず、ゲートウェイは、単にトランザクション識別子を調べることによって、写しトランザクションをいつも検出できます。 もっとも、この仕様の範囲の外にCallエージェントの間のこれらのトランザクション識別子のコーディネートがあります。
Transaction identifiers for all commands sent from a given gateway MUST be unique for the maximum lifetime of the transactions regardless of which Call Agent the command is sent to. Thus, a Call Agent can always detect a duplicate transaction from a gateway by the combination of the domain-name of the endpoint and the transaction identifier.
どのCallエージェントにコマンドを送るかにかかわらず与えられたゲートウェイから送られたすべてのコマンドのためのトランザクション識別子はトランザクションの最大の生涯、ユニークであるに違いありません。 したがって、Callエージェントはゲートウェイから終点のドメイン名とトランザクション識別子の組み合わせで写しトランザクションをいつも検出できます。
The transaction identifier is encoded as a string of up to nine decimal digits. In the command lines, it immediately follows the coding of the verb.
トランザクション識別子は一連の最大9つの10進数字としてコード化されます。 コマンドラインでは、それはすぐに、動詞のコード化に続きます。
Transaction identifiers have values between 1 and 999999999. An MGCP entity MUST NOT reuse a transaction identifier more quickly than three minutes after completion of the previous command in which the identifier was used.
トランザクション識別子には、値が1と999999999の間あります。 MGCP実体は識別子が使用された前のコマンドの完成の3分後よりはやくトランザクション識別子を再利用してはいけません。
3.2.1.3. Coding of the endpoint identifiers and entity names
3.2.1.3. 終点識別子と実体名のコード化
The endpoint identifiers and entity names are encoded as case insensitive e-mail addresses, as defined in RFC 821. In these addresses, the domain name identifies the system where the endpoint is attached, while the left side identifies a specific endpoint on that system.
終点識別子と実体名は大文字と小文字を区別しないEメールアドレスRFC821で定義されるようにコード化されます。 これらのアドレスでは、ドメイン名が終点が付属しているシステムを特定します、左側がそのシステムの上の特定の終点を特定しますが。
Examples of such addresses can be:
そのようなアドレスに関する例は以下の通りであることができます。
______________________________________________________________________
| hrd4/56@gw23.example.net | Circuit number 56 in |
| | interface "hrd4" of the Gateway 23 |
| | of the "Example" network |
| Call-agent@ca.example.net | Call Agent for the |
| | "example" network |
| Busy-signal@ann12.example.net| The "busy signal" virtual |
| | endpoint in the announcement |
| | server number 12. |
|______________________________|______________________________________|
______________________________________________________________________ | hrd4/56@gw23.example.net | 中の回路番号56| | | 「ゲートウェイ23のhrd4"」を連結してください。| | | 「例」ネットワークについて| | Call-agent@ca.example.net | 呼び出しエージェント| | | 「例」ネットワーク| | Busy-signal@ann12.example.net | 「話中音」仮想| | | 発表における終点| | | サーバNo.12。 | |______________________________|______________________________________|
The name of notified entities is expressed with the same syntax, with the possible addition of a port number as in:
通知された実体の名前は以下のように同じ構文、ポートナンバーの可能な追加で表されます。
Call-agent@ca.example.net:5234
Call-agent@ca.example.net : 5234
Arango, et al. Informational [Page 64] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[64ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
In case the port number is omitted, the default MGCP port (2427) will be used.
ポートナンバーが省略されるといけないので、デフォルトMGCPポート(2427)は使用されるでしょう。
3.2.1.4. Coding of the protocol version
3.2.1.4. プロトコルバージョンのコード化
The protocol version is coded as the key word MGCP followed by a white space and the version number, and optionally followed by a profile name.. The version number is composed of a major version, coded by a decimal number, a dot, and a minor version number, coded as a decimal number. The version described in this document is version 1.0.
プロトコルバージョンを余白とバージョン番号に従ってキーワードMGCPが続いてコード化されて、プロフィール名は任意にあとに続いています。 バージョン番号は10進数としてコード化された10進数、ドット、およびマイナーバージョン番号によってコード化された主要なバージョンで構成されます。 本書では説明されたバージョンはバージョン1.0です。
The profile name, if present, is represented by a white-space separated strings of visible (printable) characters extending to the end of the line. Profile names may be defined for user communities who want to apply restrictions or other profiling to MGCP.
存在しているなら、プロフィール名は行の終わりに達する目に見える(印刷可能な)キャラクタの切り離された余白ストリングによって表されます。 プロフィール名は制限か他のプロフィールをMGCPに適用したがっているユーザーコミュニティと定義されるかもしれません。
In the initial messages, the version will be coded as:
初期のメッセージでは、バージョンは以下としてコード化されるでしょう。
MGCP 1.0
MGCP1.0
3.2.2. Parameter lines
3.2.2. パラメタ行
Parameter lines are composed of a parameter name, which in most cases is composed of a single upper case character, followed by a colon, a white space and the parameter value. The parameter that can be present in commands are defined in the following table:
パラメタ行はパラメタ名で構成されます。(多くの場合、それは、コロン、余白、およびパラメタ値があとに続いた単独の大文字キャラクタで構成されます)。 コマンドで存在する場合があるパラメタは以下のテーブルで定義されます:
Arango, et al. Informational [Page 65] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[65ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
_______________________________________________________________________ |Parameter name | Code| Parameter value | |______________________|______|_______________________________________| |ResponseAck | K | see description | |BearerInformation | B | see description | |CallId | C | Hexadecimal string, at most 32 chars.| |ConnectionId | I | Hexadecimal string, at most 32 chars.| |NotifiedEntity | N | An identifier, in RFC 821 format, | | | | composed of an arbitrary string and | | | | of the domain name of the requesting | | | | entity, possibly completed by a port | | | | number, as in: | | | | Call-agent@ca.example.net:5234 | |RequestIdentifier | X | Hexadecimal string, at most 32 chars.| |LocalConnectionOptions| L | See description | |Connection Mode | M | See description | |RequestedEvents | R | See description | |SignalRequests | S | See description | |DigitMap | D | A text encoding of a digit map | |ObservedEvents | O | See description | |ConnectionParameters | P | See description | |ReasonCode | E | An arbitrary character string | |SpecificEndpointID | Z | An identifier, in RFC 821 format, | | | | composed of an arbitrary string, | | | | followed by an "@" followed by the | | | | domain name of the gateway to which | | | | this endpoint is attached. | |Second Endpoint ID | Z2 | Endpoint Id. | |SecondConnectionId | I2 | Connection Id. | |RequestedInfo | F | See description | |QuarantineHandling | Q | See description | |DetectEvents | T | See Description | |RestartMethod | RM | See description | |RestartDelay | RD | A number of seconds, encoded as | | | | a decimal number | |EventStates | ES | See description | |Capabilities | A | See description | |______________________|______|_______________________________________| |RemoteConnection | RC | Session Description | |Descriptor | | | |LocalConnection | LC | Session Description | |Descriptor | | | |______________________|______|_______________________________________|
_______________________________________________________________________ |パラメタ名| コード| パラメタ値| |______________________|______|_______________________________________| |ResponseAck| K| 記述を見てください。| |BearerInformation| B| 記述を見てください。| |CallId| C| ほとんどの32の雑用における16進ストリング、||ConnectionId| I| ほとんどの32の雑用における16進ストリング、||NotifiedEntity| N| RFC821形式における識別子| | | | そして任意のストリングで構成される。| | | | 要求のドメイン名について| | | | ことによるとポートで完成した実体| | | | 以下での数 | | | | Call-agent@ca.example.net : 5234| |RequestIdentifier| X| ほとんどの32の雑用における16進ストリング、||LocalConnectionOptions| L| 記述を見てください。| |接続モード| M| 記述を見てください。| |RequestedEvents| R| 記述を見てください。| |SignalRequests| S| 記述を見てください。| |DigitMap| D| ケタ地図のテキストコード化| |ObservedEvents| O| 記述を見てください。| |ConnectionParameters| P| 記述を見てください。| |ReasonCode| E| 気紛れな質ストリング| |SpecificEndpointID| Z| RFC821形式における識別子| | | | 任意のストリングを落ち着かせます。| | | | 続かれる"@"によって続かれています。| | | | ゲートウェイのドメイン名、どれ| | | | この終点は付属しています。 | |第2Endpoint ID| Z2| Endpointアイダホ州 | |SecondConnectionId| I2| 接続アイダホ州 | |RequestedInfo| F| 記述を見てください。| |QuarantineHandling| Q| 記述を見てください。| |DetectEvents| T| 記述を見てください。| |RestartMethod| RM| 記述を見てください。| |RestartDelay| rd| 秒数であって、コード化にされる| | | | 10進数| |EventStates| ES| 記述を見てください。| |能力| A| 記述を見てください。| |______________________|______|_______________________________________| |RemoteConnection| RC| セッション記述| |記述子| | | |LocalConnection| LC| セッション記述| |記述子| | | |______________________|______|_______________________________________|
Arango, et al. Informational [Page 66] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[66ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
The parameters are not necessarily present in all commands. The following table provides the association between parameters and commands. The letter M stands for mandatory, O for optional and F for forbidden.
パラメタは必ずすべてのコマンドで存在しているというわけではありません。 以下のテーブルはパラメタとコマンドとの協会を提供します。 O、文字Mが義務的に表す、任意である、F、禁制です。
___________________________________________________________________ | Parameter name | EP| CR| MD| DL| RQ| NT| AU| AU| RS| | | CF| CX| CX| CX| NT| FY| EP| CX| IP| |_____________________|____|____|____|____|____|____|____|____|____| | ResponseAck | O | O | O | O | O | O | O | O | O | | BearerInformation | M | O | O | O | O | F | F | F | F | | CallId | F | M | M | O | F | F | F | F | F | | ConnectionId | F | F | M | O | F | F | F | M | F | | RequestIdentifier | F | O+| O+| O+| M | M | F | F | F | | LocalConnection | F | O | O | F | F | F | F | F | F | | Options | | | | | | | | | | | Connection Mode | F | M | M | F | F | F | F | F | F | | RequestedEvents | F | O | O | O | O*| F | F | F | F | | SignalRequests | F | O | O | O | O*| F | F | F | F | | NotifiedEntity | F | O | O | O | O | O | F | F | F | | ReasonCode | F | F | F | O | F | F | F | F | O | | ObservedEvents | F | F | F | F | F | M | F | F | F | | DigitMap | F | O | O | O | O | F | F | F | F | | Connection | F | F | F | O | F | F | F | F | F | | parameters | | | | | | | | | | | Specific Endpoint ID| F | F | F | F | F | F | F | F | F | | Second Endpoint ID | F | O | F | F | F | F | F | F | F | | RequestedInfo | F | F | F | F | F | F | M | M | F | | QuarantineHandling | F | O | O | O | O | F | F | F | F | | DetectEvents | F | O | O | O | O | F | F | F | F | | EventStates | F | F | F | F | F | F | F | F | F | | RestartMethod | F | F | F | F | F | F | F | F | M | | RestartDelay | F | F | F | F | F | F | F | F | O | | SecondConnectionID | F | F | F | F | F | F | F | F | F | | Capabilities | F | F | F | F | F | F | F | F | F | |_____________________|____|____|____|____|____|____|____|____|____| | RemoteConnection | F | O | O | F | F | F | F | F | F | | Descriptor | | | | | | | | | | | LocalConnection | F | F | F | F | F | F | F | F | F | | Descriptor | | | | | | | | | | |_____________________|____|____|____|____|____|____|____|____|____|
___________________________________________________________________ | パラメタ名| EP| CR| MD| dl| RQ| NT| Au| Au| RS| | | Cf| CX| CX| CX| NT| FY| EP| CX| IP| |_____________________|____|____|____|____|____|____|____|____|____| | ResponseAck| O| O| O| O| O| O| O| O| O| | BearerInformation| M| O| O| O| O| F| F| F| F| | CallId| F| M| M| O| F| F| F| F| F| | ConnectionId| F| F| M| O| F| F| F| M| F| | RequestIdentifier| F| ○ +| ○ +| ○ +| M| M| F| F| F| | LocalConnection| F| O| O| F| F| F| F| F| F| | オプション| | | | | | | | | | | 接続モード| F| M| M| F| F| F| F| F| F| | RequestedEvents| F| O| O| O| ○ *| F| F| F| F| | SignalRequests| F| O| O| O| ○ *| F| F| F| F| | NotifiedEntity| F| O| O| O| O| O| F| F| F| | ReasonCode| F| F| F| O| F| F| F| F| O| | ObservedEvents| F| F| F| F| F| M| F| F| F| | DigitMap| F| O| O| O| O| F| F| F| F| | 接続| F| F| F| O| F| F| F| F| F| | パラメタ| | | | | | | | | | | 特定のEndpoint ID| F| F| F| F| F| F| F| F| F| | 第2Endpoint ID| F| O| F| F| F| F| F| F| F| | RequestedInfo| F| F| F| F| F| F| M| M| F| | QuarantineHandling| F| O| O| O| O| F| F| F| F| | DetectEvents| F| O| O| O| O| F| F| F| F| | EventStates| F| F| F| F| F| F| F| F| F| | RestartMethod| F| F| F| F| F| F| F| F| M| | RestartDelay| F| F| F| F| F| F| F| F| O| | SecondConnectionID| F| F| F| F| F| F| F| F| F| | 能力| F| F| F| F| F| F| F| F| F| |_____________________|____|____|____|____|____|____|____|____|____| | RemoteConnection| F| O| O| F| F| F| F| F| F| | 記述子| | | | | | | | | | | LocalConnection| F| F| F| F| F| F| F| F| F| | 記述子| | | | | | | | | | |_____________________|____|____|____|____|____|____|____|____|____|
Note (+) that the RequestIdentifier parameter is optional in connection creation, modification and deletion commands, but that it becomes mandatory if the command contains an encapsulated notification request.
RequestIdentifierパラメタが接続作成、変更、および削除命令で任意ですが、コマンドがカプセル化された通知要求を含んでいるならそれが義務的になることに注意してください(+)。
Arango, et al. Informational [Page 67] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[67ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Note (*) that the RequestedEvents and SignalRequests parameters are optional in the NotificationRequest. If these parameters are omitted, the corresponding lists will be considered empty.
RequestedEventsとSignalRequestsパラメタがNotificationRequestで任意であることに注意してください(*)。 これらのパラメタが省略されると、対応するリストは空であると考えられるでしょう。
If implementers need to experiment with new parameters, for example when developing a new application of MGCP, they should identify these parameters by names that start with the string "X-" or "X+", such as for example:
例えば、MGCPの新しいアプリケーションを開発するとき、implementersが、新しいパラメタを実験する必要があるなら、ストリング「X」か「X+」から始まる名前のこれらのパラメタを特定するべきです、以下のようなもの
X-FlowerOfTheDay: Daisy
X-FlowerOfTheDay: ひな菊
Parameter names that start with "X+" are critical parameter extensions. An MGCP entity that receives a critical parameter extension that it cannot understand should refuse to execute the command. It should respond with an error code 511 (Unrecognized extension).
「X+」から始まるパラメタ名は臨界パラメータ拡張子です。 それが理解できない臨界パラメータ拡張子を受け取るMGCP実体は、コマンドを実行するのを拒否するべきです。 それはエラーコード511(認識されていない拡大)で応じるべきです。
Parameter names that start with "X-" are non critical parameter extensions. An MGCP entity that receives a non critical parameter extension that it cannot understand can safely ignore that parameter.
「X」から始まるパラメタ名は非臨界パラメータ拡張子です。 それが理解できない非臨界パラメータ拡張子を受け取るMGCP実体は安全にそのパラメタを無視できます。
3.2.2.1. Response Acknowledgement
3.2.2.1. 応答承認
The response acknowledgement attribute is used to managed the "at- most-once" facility described in the "transmission over UDP" section. It contains a comma separated list of "confirmed transaction-id ranges".
応答承認属性が管理されるのに使用される、「-、かつてだいたい、」 「UDPの上のトランスミッション」セクションで説明された施設。 それは「確認されたトランザクションイド範囲」のコンマの切り離されたリストを含んでいます。
Each "confirmed transaction-id ranges" is composed of either one decimal number, when the range includes exactly one transaction, or two decimal numbers separated by a single hyphen, describing the lower and higher transaction identifiers included in the range.
それぞれ、「確認されたトランザクションイド範囲」は1つの10進数で構成されます、範囲がまさに1つのトランザクション、またはただ一つのハイフンによって切り離された2つの10進数を含んでいると、範囲に低くて、より高いトランザクション識別子を含んでいると説明して。
An example of response acknowledgement is:
応答承認に関する例は以下の通りです。
K: 6234-6255, 6257, 19030-19044
K: 6234-6255, 6257, 19030-19044
3.2.2.2. Local connection options
3.2.2.2. 市内接続オプション
The local connection options describe the operational parameters that the Call Agent suggests to the gateway. These parameters are:
市内接続オプションはCallエージェントがゲートウェイに勧める操作上のパラメタについて説明します。 これらのパラメタは以下の通りです。
* The packetization period in milliseconds, encoded as the keyword
"p", followed by a colon and a decimal number. If the Call Agent
specifies a range of values, the range will be specified as two
decimal numbers separated by an hyphen.
* コロンと10進数に従って、キーワード「p」としてコード化されたミリセカンドで表現されるpacketizationの期間は続きました。 Callエージェントがさまざまな値を指定すると、範囲はハイフンによって切り離された2つの10進数として指定されるでしょう。
Arango, et al. Informational [Page 68] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[68ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
* The preferred type of compression algorithm, encoded as the
keyword "a", followed by a colon and a character string. If the
Call Agent specifies a list of values, these values will be
separated by a semicolon.
* キーワード“a"としてコード化された都合のよいタイプの圧縮アルゴリズムはコロンと文字列で従いました。 Callエージェントが値のリストを指定すると、これらの値はセミコロンによって切り離されるでしょう。
* The bandwidth in kilobits per second (1000 bits per second),
encoded as the keyword "b", followed by a colon and a decimal
number. If the Call Agent specifies a range of values, the range
will be specified as two decimal numbers separated by an hyphen.
* コロンと10進数に従って、キーワード「b」としてコード化された秒(1000のbps)あたりのキロビットにおける帯域幅は続きました。 Callエージェントがさまざまな値を指定すると、範囲はハイフンによって切り離された2つの10進数として指定されるでしょう。
* The echo cancellation parameter, encoded as the keyword "e",
followed by a colon and the value "on" or "off".
* キーワード「e」としてコード化されたエコーキャンセルパラメタは値のコロンと“on"か“off"で従いました。
* The gain control parameter, encoded as the keyword "gc", followed
by a colon a value which can be either the keyword "auto" or a
decimal number (positive or negative) representing the number of
decibels of gain.
* "gc"というキーワードとしてコード化された利得制御パラメタは、デシベルの利得の数を表しながら、コロンによる「自動車」というキーワードか10進数のどちらかであるかもしれない値に続きました(肯定しているか否定している)。
* The silence suppression parameter, encoded as the keyword "s",
followed by a colon and the value "on" or "off".
* キーワード「s」としてコード化された沈黙抑圧パラメタは値のコロンと“on"か“off"で従いました。
* The type of service parameter, encoded as the keyword "t",
followed by a colon and the value encoded as two hexadecimal
digits.
* キーワード「t」としてコード化されたサービスパラメタのタイプは2つの16進数字としてコード化されたコロンと値で続きました。
* The resource reservation parameter, encoded as the keyword "r",
followed by a colon and the value "g" (guaranteed service), "cl"
(controlled load) or "be" (best effort).
* コロンと値「g」(アフターサービスを保証します)か、「Cl」(制御負荷)か「いる」(ベストエフォート型)でキーワード「r」としてコード化された資源予約パラメタは従いました。
* The encryption key, encoded as the keyword "k" followed by a colon
and a key specification, as defined for the parameter "K" of SDP
(RFC 2327).
* コロンとキー仕様でキーワード「k」として主要で、コード化された暗号化は続きました、SDP(RFC2327)のパラメタ「K」のために定義されるように。
* The type of network, encoded as the keyword "nt" followed by a
colon and the type of network encoded as the keyword "IN", "ATM"
or "LOCAL".
* キーワード"nt"がコロンで続いてコード化されたネットワークのタイプと「IN」、「気圧」または「ローカル」というキーワードとしてコード化されたネットワークのタイプ。
Each of the parameters is optional. When several parameters are present, the values are separated by a comma.
それぞれのパラメタは任意です。 いくつかのパラメタが存在しているとき、値はコンマによって切り離されます。
Examples of connection descriptors are:
接続記述子に関する例は以下の通りです。
L: p:10, a:PCMU
L: p:10, a:G726-32
L: p:10-20, b:64
L: b:32-64, e:off
L: p: 10 : PCMU L: p: 10 : G726-32L: p: 10-20、b: 64 L、: b: 32-64、e: 下に
These set of attributes may be extended by extension attributes.
これらのセットの属性は拡大属性によって広げられるかもしれません。
Arango, et al. Informational [Page 69] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[69ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Extension attributes are composed of an attribute name, followed by a semi-colon and by an attribute value. The attribute name should start by the two characters "x+", for a mandatory extensions, or "x-", for a non mandatory extension. If a gateway receives a mandatory extension attribute that it does not recognize, it should reject the command with an error code 525 (Unknown extension in LocalConnectionOptions).
拡大属性はセミコロンと属性値があとに続いた属性名で構成されます。 属性名は2つのキャラクタで「x+」を始めるべきです、義務的な拡大、または「x」のために、非義務的な拡大のために。 ゲートウェイがそれが認識しない義務的な拡大属性を受けるなら、それはエラーコード525(LocalConnectionOptionsでの未知の拡大)でコマンドを拒絶するべきです。
3.2.2.3. Capabilities
3.2.2.3. 能力
Capabilities inform the Call Agent about endpoints' capabilities when audited. The encoding of capabilities is based on the Local Connection Options encoding for the parameters that are common to both. In addition, capabilities can also contain a list of supported packages, and a list of supported modes.
監査されると、能力は終点の能力に関してCallエージェントに知らせます。 能力のコード化は両方に共通のパラメタのためのLocal Connection Optionsコード化に基づいています。 また、さらに、能力はサポートしているパッケージのリスト、およびサポートしているモードのリストを含むことができます。
The parameters used are:
使用されるパラメタは以下の通りです。
*
A list of supported codecs. The following parameters will apply to
all codecs specified in this list. If there is a need to specify
that some parameters, such as e.g. silence suppression, are only
compatible with some codecs, then the gateway will return several
LocalConnectionOptions parameters, one for each set of codecs.
* サポートしているコーデックのリスト。 以下のパラメタはこのリストで指定されたすべてのコーデックに適用されるでしょう。 例えば、沈黙抑圧などのいくつかのパラメタがいくつかのコーデックと互換性があるだけであると指定する必要があると、ゲートウェイはいくつかのLocalConnectionOptionsパラメタ(それぞれのセットのコーデックのためのもの)を返すでしょう。
Packetization Period:
A range may be specified.
Packetizationの期間: 範囲は指定されるかもしれません。
Bandwidth:
A range corresponding to the range for packetization periods may
be specified (assuming no silence suppression). If absent, the
values will be deduced from the codec type.
帯域幅: packetizationの期間、範囲に対応する範囲は指定されるかもしれません(どんな沈黙も抑圧でないと仮定して)。 休むと、値はコーデックタイプから推論されるでしょう。
Echo Cancellation:
"on" if echo cancellation is supported for this codec, "off"
otherwise. The default is support.
キャンセルをまねてください: "on"はエコーキャンセルであるならこのコーデック、“off"のために別の方法でサポートされます。 デフォルトはサポートです。
Silence Suppression:
"on" if silence suppression is supported for this codec, "off"
otherwise. The default is support.
抑圧を黙らせてください: "on"は沈黙抑圧であるならこのコーデック、“off"のために別の方法でサポートされます。 デフォルトはサポートです。
Gain Control:
"0" if gain control is not supported. The default is support.
コントロールを獲得してください: 「0インチは利得制御であるならサポートされません。」 デフォルトはサポートです。
Type of Service:
The value "0" indicates no support for type of service, all other
values indicate support for type of service. The default is
support.
サービスのタイプ: 「サービスのタイプ、他の値が示すすべてのためにサポート0インチがいいえをサービスのタイプのサポートを示すす」値。 デフォルトはサポートです。
Arango, et al. Informational [Page 70] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[70ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Resource Reservation:
The parameter indicates the reservation services that are
supported, in addition to best effort. The value "g" is encoded
when the gateway supports both the guaranteed and the controlled
load service, "cl" when only the controlled load service is
supported. The default is "best effort."
資源予約: パラメタはベストエフォート型に加えてサポートされる予約サービスを示します。 制御負荷サービスだけがサポートされるとき、ゲートウェイが、両方が保証と制御負荷サービス、「Cl」であるとサポートするとき、値「g」はコード化されます。 デフォルトは「ベストエフォート型です」。
Encryption Key:
Encoding any value indicates support for encryption. Default is
no support.
暗号化キー: どんな値もコード化すると、暗号化のサポートは示されます。 デフォルトはサポートではありません。
Type of network:
The keyword "nt", followed by a colon and a semicolon separated
list of supported network types. This parameter is optional.
ネットワークのタイプ: コロンがあとに続いた"nt"というキーワードとサポートしているネットワークのセミコロンの切り離されたリストはタイプされます。 このパラメタは任意です。
Event Packages
The event packages supported by this endpoint encoded as the
keyword "v", followed by a colon and a character string. If a list
of values is specified, these values will be separated by a
semicolon. The first value specified will be the default package
for that endpoint.
イベントパッケージがコロンと文字列があとに続いたキーワード「v」としてコード化されたこの終点でサポートしたイベントパッケージ。 値のリストが指定されると、これらの値はセミコロンによって切り離されるでしょう。 指定された最初の値はその終点のためにデフォルトパッケージになるでしょう。
Modes
The modes supported by this endpoint encoded as the keyword "m",
followed by a colon and a semicolon-separated list of supported
connection modes for this endpoint.
モードがこの終点でサポートしたモードはコロンがあとに続いた「m」というキーワードとサポートしている接続のセミコロンで切り離されたリストとしてこの終点にモードをコード化しました。
3.2.2.4. Connection parameters
3.2.2.4. 接続パラメタ
Connection parameters are encoded as a string of type and value pairs, where the type is a either letter identifier of the parameter or an extension type, and the value a decimal integer. Types are separated from value by an `=' sign. Parameters are encoded from each other by a comma.
タイプと価値のストリング(タイプは、10進整数にパラメタに関するどちらかの手紙識別子か拡大タイプと、値である)が対にされるとき、接続パラメタはコード化されます。 タイプは'='サインによって値と切り離されます。 パラメタはコンマによって互いからコード化されます。
Arango, et al. Informational [Page 71] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[71ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
The connection parameter types are specified in the following table:
接続パラメータの型は以下のテーブルで指定されます:
__________________________________________________________________
| Connection parameter| Code| Connection parameter |
| name | | value |
|_____________________|______|____________________________________|
| Packets sent | PS | The number of packets that |
| | | were sent on the connection. |
| Octets sent | OS | The number of octets that |
| | | were sent on the connection. |
| Packets received | PR | The number of packets that |
| | | were received on the connection. |
| Octets received | OR | The number of octets that |
| | | were received on the connection. |
| Packets lost | PL | The number of packets that |
| | | were not received on the |
| | | connection, as deduced from |
| | | gaps in the sequence number. |
| Jitter | JI | The average inter-packet arrival |
| | | jitter, in milliseconds, |
| | | expressed as an integer number. |
| Latency | LA | Average latency, in milliseconds, |
| | | expressed as an integer number. |
|_____________________|______|____________________________________|
__________________________________________________________________ | 接続パラメタ| コード| 接続パラメタ| | 名前| | 値| |_____________________|______|____________________________________| | パケットは発信しました。| PS| パケットの数、それ| | | | 接続に送りました。 | | 八重奏は発信しました。| OS| 八重奏の数、それ| | | | 接続に送りました。 | | パケットは受信されました。| PR| パケットの数、それ| | | | 接続のときに、受け取りました。 | | 八重奏は受信されました。| OR| 八重奏の数、それ| | | | 接続のときに、受け取りました。 | | パケットは損をしました。| PL| パケットの数、それ| | | | 受け取られませんでした。| | | | 推論されるとしての接続| | | | 一連番号におけるギャップ。 | | ジター| JI| 平均した相互パケット到着| | | | ミリセカンドで表現されるジター| | | | 整数として、言い表されます。 | | 潜在| LA| ミリセカンドで潜在を平均してください。| | | | 整数として、言い表されます。 | |_____________________|______|____________________________________|
Extension parameters names are composed of the string "X-" followed by a two letters extension parameter name. Call agents that received unrecognized extensions shall silently ignore these extensions.
拡大パラメタ名は2手紙拡大パラメタ名があとに続いたストリング「X」で構成されます。 認識されていない拡大を受けた呼び出しエージェントは静かにこれらの拡大を無視するものとします。
An example of connection parameter encoding is:
接続パラメタコード化に関する例は以下の通りです。
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
P: PS=1245、OS=62345、PR=0、または=0、PLが0、JI=0、LA=48と等しいです。
3.2.2.5. Reason Codes
3.2.2.5. 理由コード
Reason codes are three-digit numeric values. The reason code is optionally followed by a white space and commentary, e.g.:
理由コードは3ケタの数値です。 余白と論評は例えば任意に理由コードのあとに続いています:
900 Endpoint malfunctioning
900 終点誤動作
A list of reason-codes can be found in Section 2.5.
セクション2.5で理由コードのリストを見つけることができます。
Arango, et al. Informational [Page 72] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[72ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
3.2.2.6. Connection mode
3.2.2.6. 接続モード
The connection mode describes the mode of operation of the connection. The possible values are:
接続モードは接続の運転モードを説明します。 可能な値は以下の通りです。
________________________________________________________
| Mode | Meaning |
|____________|__________________________________________|
| M: sendonly| The gateway should only send packets |
| M: recvonly| The gateway should only receive packets |
| M: sendrecv| The gateway should send |
| | and receive packets |
| M: confrnce| The gateway should place |
| | the connection in conference mode |
| M: inactive| The gateway should neither |
| | send nor receive packets |
| M: loopback| The gateway should place |
| | the circuit in loopback mode. |
| M: conttest| The gateway should place |
| | the circuit in test mode. |
| M: netwloop| The gateway should place |
| | the connection in network loopback mode.|
| M: netwtest| The gateway should place |
| | the connection in network |
| | continuity test mode. |
| M: data | The gateway should use the circuit |
| | for network access for data |
| | (e.g., PPP, SLIP, etc.). |
|____________|__________________________________________|
________________________________________________________ | モード| 意味| |____________|__________________________________________| | M: sendonly| ゲートウェイはパケットを送るだけであるはずです。| | M: recvonly| ゲートウェイはパケットを受けるだけであるはずです。| | M: sendrecv| ゲートウェイは発信するはずです。| | | そして、パケットを受けてください。| | M: confrnce| ゲートウェイは置くはずです。| | | 会議モードにおける接続| | M: 不活発| ゲートウェイはどちらもそうするべきです。| | | パケットを送って、受けてください。| | M: ループバック| ゲートウェイは置くはずです。| | | ループバックモードによる回路。 | | M: 最もconttestである| ゲートウェイは置くはずです。| | | テスト・モードによる回路。 | | M: netwloop| ゲートウェイは置くはずです。| | | ネットワークループバックモードにおける接続、|| M: 最もnetwtestである| ゲートウェイは置くはずです。| | | ネットワークにおける接続| | | 連続テスト・モード。 | | M: データ| ゲートウェイは回路を使用するはずです。| | | データのためのネットワークアクセスのために| | | (例えば、PPP、SLIPなど。) | |____________|__________________________________________|
3.2.2.7. Coding of event names
3.2.2.7. イベント名のコード化
Event names are composed of an optional package name, separated by a slash (/) from the name of the actual event. The event name can optionally be followed by an at sign (@) and the identifier of a connection on which the event should be observed. Event names are used in the RequestedEvents, SignalRequests and ObservedEvents parameter.
イベント名はスラッシュ(/)によって現実の出来事の名前と切り離された任意のパッケージ名で構成されます。 任意にイベント名に従うことができる、イベントが観測されるべきである接続に関するサイン(@)と識別子で。 イベント名はRequestedEvents、SignalRequests、およびObservedEventsパラメタで使用されます。
Each signal has one of the following signal-types associated with: On/Off (OO), Time-out (TO), Brief (BR). (These signal types are specified in the package definitions, and are not present in the messages.) On/Off signals can be parameterized with a "+" to turn the signal on, or a "-" to turn the signal off. If an on/off signal is not parameterized, the signal is turned on. Both of the following will turn the vmwi signal on:
各信号には、以下に関連づけられた以下の信号タイプのひとりがいます。 オンであるかオフな(OO)(タイムアウト(TO))は(Br)に事情を知らせます。 (これらの信号タイプは、パッケージ定義で指定されて、メッセージに出席していません。) オンであるかオフな信号は信号をつける「+」、または「-」でparameterizedされて、信号をオフにすることができます。 オンであるかオフな信号がparameterizedされないなら、信号はつけられています。 以下の両方がvmwi信号をつけるでしょう:
vmwi(+), vmwi
vmwi(+)、vmwi
Arango, et al. Informational [Page 73] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[73ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
The following are valid examples of event names:
↓これはイベント名の有効な例です:
____________________________________________________________
| L/hu | on-hook transition, in the line package |
| F/0 | digit 0 in the MF package |
| fh | Flash-hook, assuming that the line package|
| | is a default package for the end point. |
| G/rt@0A3F58 | Ring back signal on |
| | connection "0A3F58". |
|_____________|_____________________________________________|
____________________________________________________________ | L/hu| フックにおける系列パッケージにおける変遷| | F/0| MFパッケージの中のケタ0| | fh| それが系列パッケージであると仮定するフラッシュフック| | | デフォルトパッケージはエンドポイントのためのものですか? | | G/rt@0A3F58 | 後部が合図するリング| | | 接続"0A3F58""。 | |_____________|_____________________________________________|
In addition, the range and wildcard notation of events can be used, instead of individual names, in the RequestedEvents and DetectEvents parameters. The star sign can be used to denote "all connections", and the dollar sign can be used to denote the "current" connection. The following are valid examples of such notations:
In addition, the range and wildcard notation of events can be used, instead of individual names, in the RequestedEvents and DetectEvents parameters. The star sign can be used to denote "all connections", and the dollar sign can be used to denote the "current" connection. The following are valid examples of such notations:
__________________________________________________________
| M/[0-9] | Digits 0 to 9 in the MF package |
| fh | Flash-hook, assuming that the line package|
| | is a default package for the end point. |
| [0-9*#A-D]| All digits and letters in the DTMF |
| | packages (default for endpoint). |
| T/$ | All events in the trunk packages. |
| R/qa@* | The quality alert event in all |
| | connections |
| R/rt@$ | Ringback on current connection |
|___________|_____________________________________________|
__________________________________________________________ | M/[0-9] | Digits 0 to 9 in the MF package | | fh | Flash-hook, assuming that the line package| | | is a default package for the end point. | | [0-9*#A-D]| All digits and letters in the DTMF | | | packages (default for endpoint). | | T/$ | All events in the trunk packages. | | R/qa@* | The quality alert event in all | | | connections | | R/rt@$ | Ringback on current connection | |___________|_____________________________________________|
3.2.2.8. RequestedEvents
3.2.2.8. RequestedEvents
The RequestedEvent parameter provides the list of events that have been requested. The event codes are described in the previous section.
The RequestedEvent parameter provides the list of events that have been requested. The event codes are described in the previous section.
Each event can be qualified by a requested action, or by a list of actions. The actions, when specified, are encoded as a list of keywords, enclosed in parenthesis and separated by commas. The codes for the various actions are:
Each event can be qualified by a requested action, or by a list of actions. The actions, when specified, are encoded as a list of keywords, enclosed in parenthesis and separated by commas. The codes for the various actions are:
Arango, et al. Informational [Page 74] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango, et al. Informational [Page 74] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
______________________________________
| Action | Code|
|______________________________|______|
| Notify immediately | N |
| Accumulate | A |
| Treat according to digit map | D |
| Swap | S |
| Ignore | I |
| Keep Signal(s) active | K |
| Embedded Notification Request| E |
|______________________________|______|
______________________________________ | Action | Code| |______________________________|______| | Notify immediately | N | | Accumulate | A | | Treat according to digit map | D | | Swap | S | | Ignore | I | | Keep Signal(s) active | K | | Embedded Notification Request| E | |______________________________|______|
When no action is specified, the default action is to notify the event. This means that, for example, ft and ft(N) are equivalent. Events that are not listed are ignored.
When no action is specified, the default action is to notify the event. This means that, for example, ft and ft(N) are equivalent. Events that are not listed are ignored.
The digit-map action can only be specified for the digits, letters and interdigit timers in the MF and DTMF packages, or in other packages that would define the encoding of digits and timers.
The digit-map action can only be specified for the digits, letters and interdigit timers in the MF and DTMF packages, or in other packages that would define the encoding of digits and timers.
The requested list is encoded on a single line, with event/action groups separated by commas. Examples of RequestedEvents encoding are:
The requested list is encoded on a single line, with event/action groups separated by commas. Examples of RequestedEvents encoding are:
R: hu(N), hf(S,N)
R: hu(N), [0-9#T](D)
R: hu(N), hf(S,N) R: hu(N), [0-9#T](D)
In the case of the "enable" action, the embedded notification request parameters are encoded as a list of up to three parameter groups, separated by commas. Each group start by a one letter identifier, followed by a list of parameters enclosed between parenthesis. The first optional parameter group, identified by the letter "R", is the enabled value of the RequestedEvents parameter. The second optional group, identified by the letter "S", is the enabled value of the SignalRequests parameter. The third optional group, identified by the letter "D", is the enabled value of the DigitMap. (Note that some existing implementation may encode these three components in a different order.)
In the case of the "enable" action, the embedded notification request parameters are encoded as a list of up to three parameter groups, separated by commas. Each group start by a one letter identifier, followed by a list of parameters enclosed between parenthesis. The first optional parameter group, identified by the letter "R", is the enabled value of the RequestedEvents parameter. The second optional group, identified by the letter "S", is the enabled value of the SignalRequests parameter. The third optional group, identified by the letter "D", is the enabled value of the DigitMap. (Note that some existing implementation may encode these three components in a different order.)
If the RequestedEvents is not present, the parameter will be set to a null value. If the SignalRequest is not present, the parameter will be set to a null value. If the DigitMap is absent, the current value should be used. The following are valid examples of embedded requests:
If the RequestedEvents is not present, the parameter will be set to a null value. If the SignalRequest is not present, the parameter will be set to a null value. If the DigitMap is absent, the current value should be used. The following are valid examples of embedded requests:
R: hd(E(R([0-9#T](D),hu(N)),S(dl),D([0-9].[#T])))
R: hd(E(R([0-9#T](D),hu(N)),S(dl)))
R: hd(E(R([0-9#T](D),hu(N)),S(dl),D([0-9].[#T]))) R: hd(E(R([0-9#T](D),hu(N)),S(dl)))
Arango, et al. Informational [Page 75] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango, et al. Informational [Page 75] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
3.2.2.9. SignalRequests
3.2.2.9. SignalRequests
The SignalRequests parameter provides the name of the signals that have been requested. Each signal is identified by a name, as indicated in the previous section.
The SignalRequests parameter provides the name of the signals that have been requested. Each signal is identified by a name, as indicated in the previous section.
Several signals, such as for example announcement or ADSI display, can be qualified by additional parameters:
Several signals, such as for example announcement or ADSI display, can be qualified by additional parameters:
* the name and parameters of the announcement,
* the name and parameters of the announcement,
* the string that should be displayed.
* the string that should be displayed.
These parameters will be encoded as a set of UTF8 character strings,
spearated by comams and enclosed within parenthesis, as in:
S: adsi("123456 Francois Gerard")
S: ann(no-such-number, 1234567)
These parameters will be encoded as a set of UTF8 character strings, spearated by comams and enclosed within parenthesis, as in: S: adsi("123456 Francois Gerard") S: ann(no-such-number, 1234567)
When several signals are requested, their codes are separated by a comma, as in:
When several signals are requested, their codes are separated by a comma, as in:
S: asdi(123456 Your friend), rg
S: asdi(123456 Your friend), rg
3.2.2.10. ObservedEvent
3.2.2.10. ObservedEvent
The observed event parameters provides the list of events that have been observed. The event codes are the same as those used in the NotificationRequest. Events that have been accumulated according to the digit map may be grouped in a single string; they should be reported as lists of isolated events if other events where detected during the digit accumulation. Examples of observed actions are:
The observed event parameters provides the list of events that have been observed. The event codes are the same as those used in the NotificationRequest. Events that have been accumulated according to the digit map may be grouped in a single string; they should be reported as lists of isolated events if other events where detected during the digit accumulation. Examples of observed actions are:
O: L/hu
O: 8295555T
O: 8,2,9,5,5,L/hf,5,5,T
O: L/hf, L/hf, L/hu
O: L/hu O: 8295555T O: 8,2,9,5,5,L/hf,5,5,T O: L/hf, L/hf, L/hu
3.2.2.11. RequestedInfo
3.2.2.11. RequestedInfo
The RequestedInfo parameter contains a comma separated list of parameter codes, as defined in the "Parameter lines" section. For example, if one wants to audit the value of the NotifiedEntity, RequestIdentifier, RequestedEvents, SignalRequests, DigitMap, QuarantineHandling and DetectEvents parameters, The value of the RequestedInfo parameter will be:
The RequestedInfo parameter contains a comma separated list of parameter codes, as defined in the "Parameter lines" section. For example, if one wants to audit the value of the NotifiedEntity, RequestIdentifier, RequestedEvents, SignalRequests, DigitMap, QuarantineHandling and DetectEvents parameters, The value of the RequestedInfo parameter will be:
F:N,X,R,S,D,Q,T
F:N,X,R,S,D,Q,T
Arango, et al. Informational [Page 76] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango, et al. Informational [Page 76] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
The capabilities request, in the AuditEndPoint command, is encoded by the keyword "A", as in:
The capabilities request, in the AuditEndPoint command, is encoded by the keyword "A", as in:
F:A
F:A
3.2.2.12. QuarantineHandling
3.2.2.12. QuarantineHandling
The quarantine handling parameter contains a list of comma separated keywords:
The quarantine handling parameter contains a list of comma separated keywords:
* The keyword "process" or "discard" to indicate the treatment of
quarantined events. If neither process or discard is present,
process is assumed.
* The keyword "process" or "discard" to indicate the treatment of quarantined events. If neither process or discard is present, process is assumed.
* The keyword "step" or "loop" to indicate whether exactly at most
one notification is expected, or whether multiple notifications
are allowed. If neither step or loop is present, step is assumed.
The following values are valid examples:
* The keyword "step" or "loop" to indicate whether exactly at most one notification is expected, or whether multiple notifications are allowed. If neither step or loop is present, step is assumed. The following values are valid examples:
Q:loop
Q:process
Q:discard,loop
Q:loop Q:process Q:discard,loop
3.2.2.13. DetectEvents
3.2.2.13. DetectEvents
The DetectEvent parameter is encoded as a comma separated list of events, such as for example:
The DetectEvent parameter is encoded as a comma separated list of events, such as for example:
T: hu,hd,hf,[0-9#*]
T: hu,hd,hf,[0-9#*]
It should be noted, that no actions can be associated with the events.
It should be noted, that no actions can be associated with the events.
3.2.2.14. EventStates
3.2.2.14. EventStates
The EventStates parameter is encoded as a comma separated list of events, such as for example:
The EventStates parameter is encoded as a comma separated list of events, such as for example:
ES: hu
ES: hu
It should be noted, that no actions can be associated with the events.
It should be noted, that no actions can be associated with the events.
Arango, et al. Informational [Page 77] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango, et al. Informational [Page 77] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
3.2.2.15. RestartMethod
3.2.2.15. RestartMethod
The RestartMethod parameter is encoded as one of the keywords "graceful", "forced", "restart", "disconnected" or "cancel-graceful" as for example:
The RestartMethod parameter is encoded as one of the keywords "graceful", "forced", "restart", "disconnected" or "cancel-graceful" as for example:
RM:restart
RM:restart
3.2.2.16. Bearer Information
3.2.2.16. Bearer Information
The values of the bearer informations are encoded as a comma separated list of attributes, represented by an attribute name, separated by a colon from an attribute value.
The values of the bearer informations are encoded as a comma separated list of attributes, represented by an attribute name, separated by a colon from an attribute value.
The only attribute that is defined is the "encoding" (code "e"), whose defined values are "A" (A-law) and "mu" (mu-law).
The only attribute that is defined is the "encoding" (code "e"), whose defined values are "A" (A-law) and "mu" (mu-law).
An example of bearer information encoding is:
An example of bearer information encoding is:
B: e:mu
B: e:mu
3.3. Format of response headers
3.3. Format of response headers
The response header is composed of a response line, optionally followed by headers that encode the response parameters.
The response header is composed of a response line, optionally followed by headers that encode the response parameters.
An example of response header could be:
An example of response header could be:
200 1203 OK
200 1203 OK
The response line starts with the response code, which is a three digit numeric value. The code is followed by a white space, the transaction identifier, and an optional commentary preceded by a white space.
The response line starts with the response code, which is a three digit numeric value. The code is followed by a white space, the transaction identifier, and an optional commentary preceded by a white space.
The following table describe the parameters whose presence is mandatory or optional in a response header, as a function of the command that triggered the response. The letter M stands for mandatory, O for optional and F for forbidden.
The following table describe the parameters whose presence is mandatory or optional in a response header, as a function of the command that triggered the response. The letter M stands for mandatory, O for optional and F for forbidden.
Arango, et al. Informational [Page 78] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango, et al. Informational [Page 78] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
___________________________________________________________________
| Parameter name | EP| CR| MD| DL| RQ| NT| AU| AU| RS|
| | CF| CX| CX| CX| NT| FY| EP| CX| IP|
|_____________________|____|____|____|____|____|____|____|____|____|
| ResponseAck | F | F | F | F | F | F | F | F | F |
| BearerInformation | F | F | F | F | F | F | O | F | F |
| CallId | F | F | F | F | F | F | F | O | F |
| ConnectionId | F | O*| F | F | F | F | F | F | F |
| RequestIdentifier | F | F | F | F | F | F | O | F | F |
| LocalConnection | F | F | F | F | F | F | O | O | F |
| Options | | | | | | | | | |
| Connection Mode | F | F | F | F | F | F | F | O | F |
| RequestedEvents | F | F | F | F | F | F | O | F | F |
| SignalRequests | F | F | F | F | F | F | O | F | F |
| NotifiedEntity | F | F | F | F | F | F | F | F | O |
| ReasonCode | F | F | F | F | F | F | O | F | F |
| ObservedEvents | F | F | F | F | F | F | O | F | F |
| DigitMap | F | F | F | F | F | F | O | F | F |
| Connection | F | F | F | O | F | F | F | O | F |
| Parameters | | | | | | | | | |
| Specific Endpoint ID| F | O | F | F | F | F | F | F | F |
| RequestedInfo | F | F | F | F | F | F | F | F | F |
| QuarantineHandling | F | F | F | F | F | F | O | F | F |
| DetectEvents | F | F | F | F | F | F | O | F | F |
| EventStates | F | F | F | F | F | F | O | F | F |
| RestartMethod | F | F | F | F | F | F | O | F | F |
| RestartDelay | F | F | F | F | F | F | O | F | F |
| Capabilities | F | F | F | F | F | F | O | F | F |
| SecondConnectionId | F | O | F | F | F | F | F | F | F |
| SecondEndpointID | F | O | F | F | F | F | F | F | F |
|_____________________|____|____|____|____|____|____|____|____|____|
| LocalConnection | F | M | O | F | F | F | F | O*| F |
| Descriptor | | | | | | | | | |
| RemoteConnection | F | F | F | F | F | F | F | O*| F |
| Descriptor | | | | | | | | | |
|_____________________|____|____|____|____|____|____|____|____|____|
___________________________________________________________________ | Parameter name | EP| CR| MD| DL| RQ| NT| AU| AU| RS| | | CF| CX| CX| CX| NT| FY| EP| CX| IP| |_____________________|____|____|____|____|____|____|____|____|____| | ResponseAck | F | F | F | F | F | F | F | F | F | | BearerInformation | F | F | F | F | F | F | O | F | F | | CallId | F | F | F | F | F | F | F | O | F | | ConnectionId | F | O*| F | F | F | F | F | F | F | | RequestIdentifier | F | F | F | F | F | F | O | F | F | | LocalConnection | F | F | F | F | F | F | O | O | F | | Options | | | | | | | | | | | Connection Mode | F | F | F | F | F | F | F | O | F | | RequestedEvents | F | F | F | F | F | F | O | F | F | | SignalRequests | F | F | F | F | F | F | O | F | F | | NotifiedEntity | F | F | F | F | F | F | F | F | O | | ReasonCode | F | F | F | F | F | F | O | F | F | | ObservedEvents | F | F | F | F | F | F | O | F | F | | DigitMap | F | F | F | F | F | F | O | F | F | | Connection | F | F | F | O | F | F | F | O | F | | Parameters | | | | | | | | | | | Specific Endpoint ID| F | O | F | F | F | F | F | F | F | | RequestedInfo | F | F | F | F | F | F | F | F | F | | QuarantineHandling | F | F | F | F | F | F | O | F | F | | DetectEvents | F | F | F | F | F | F | O | F | F | | EventStates | F | F | F | F | F | F | O | F | F | | RestartMethod | F | F | F | F | F | F | O | F | F | | RestartDelay | F | F | F | F | F | F | O | F | F | | Capabilities | F | F | F | F | F | F | O | F | F | | SecondConnectionId | F | O | F | F | F | F | F | F | F | | SecondEndpointID | F | O | F | F | F | F | F | F | F | |_____________________|____|____|____|____|____|____|____|____|____| | LocalConnection | F | M | O | F | F | F | F | O*| F | | Descriptor | | | | | | | | | | | RemoteConnection | F | F | F | F | F | F | F | O*| F | | Descriptor | | | | | | | | | | |_____________________|____|____|____|____|____|____|____|____|____|
In the case of a CreateConnection message, the response line is followed by a Connection-Id parameter. It may also be followed a Specific-Endpoint-Id parameter, if the creation request was sent to a wildcarded Endpoint-Id. The connection-Id parameter is marked as optional in the Table. In fact, it is mandatory with all positive responses, when a connection was created, and forbidden when the response is negative, when no connection as created.
In the case of a CreateConnection message, the response line is followed by a Connection-Id parameter. It may also be followed a Specific-Endpoint-Id parameter, if the creation request was sent to a wildcarded Endpoint-Id. The connection-Id parameter is marked as optional in the Table. In fact, it is mandatory with all positive responses, when a connection was created, and forbidden when the response is negative, when no connection as created.
In the case of a DeleteConnection message, the response line is followed by a Connection Parameters parameter, as defined in section 3.2.2.2.
In the case of a DeleteConnection message, the response line is followed by a Connection Parameters parameter, as defined in section 3.2.2.2.
Arango, et al. Informational [Page 79] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango, et al. Informational [Page 79] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
A LocalConnectionDescriptor should be transmitted with a positive response (code 200) to a CreateConnection. It may be transmitted in response to a ModifyConnection command, if the modification resulted in a modification of the session parameters. The LocalConnectionDescriptor is encoded as a "session description," as defined in section 3.4. It is separated from the response header by an empty line.
A LocalConnectionDescriptor should be transmitted with a positive response (code 200) to a CreateConnection. It may be transmitted in response to a ModifyConnection command, if the modification resulted in a modification of the session parameters. The LocalConnectionDescriptor is encoded as a "session description," as defined in section 3.4. It is separated from the response header by an empty line.
When several session descriptors are encoded in the same response, they are encoded one after each other, separated by an empty line. This is the case for example when the response to an audit connection request carries both a local session description and a remote session description, as in:
When several session descriptors are encoded in the same response, they are encoded one after each other, separated by an empty line. This is the case for example when the response to an audit connection request carries both a local session description and a remote session description, as in:
200 1203 OK
C: A3C47F21456789F0
N: [128.96.41.12]
L: p:10, a:PCMU;G726-32
M: sendrecv
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48
200 1203 OK C: A3C47F21456789F0 N: [128.96.41.12] L: p:10, a:PCMU;G726-32 M: sendrecv P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48
v=0
c=IN IP4 128.96.41.1
m=audio 1296 RTP/AVP 0
v=0 c=IN IP4 128.96.41.1 m=audio 1296 RTP/AVP 0
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000
In this example, according to the SDP syntax, each description starts with a "version" line, (v=...). The local description is always transmitted before the remote description. If a connection descriptor is requested, but it does not exist for the connection audited, that connection descriptor will appear with the SDP protocol version field only.
In this example, according to the SDP syntax, each description starts with a "version" line, (v=...). The local description is always transmitted before the remote description. If a connection descriptor is requested, but it does not exist for the connection audited, that connection descriptor will appear with the SDP protocol version field only.
Arango, et al. Informational [Page 80] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango, et al. Informational [Page 80] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
3.4. Formal syntax description of the protocol
3.4. Formal syntax description of the protocol
In this section, we provided a formal description of the protocol syntax, following the "Augmented BNF for Syntax Specifications" defined in RFC 2234.
In this section, we provided a formal description of the protocol syntax, following the "Augmented BNF for Syntax Specifications" defined in RFC 2234.
MGCPMessage = MGCPCommand / MGCPResponse
MGCPMessage = MGCPCommand / MGCPResponse
MGCPCommand = MGCPCommandLine 0*(MGCPParameter) [EOL *SDPinformation]
MGCPCommand = MGCPCommandLine 0*(MGCPParameter) [EOL *SDPinformation]
MGCPCommandLine = MGCPVerb 1*(WSP) <transaction-id> 1*(WSP)
<endpointName> 1*(WSP) MGCPversion EOL
MGCPCommandLine = MGCPVerb 1*(WSP) <transaction-id> 1*(WSP) <endpointName> 1*(WSP) MGCPversion EOL
MGCPVerb = "EPCF" / "CRCX" / "MDCX" / "DLCX" / "RQNT"
/ "NTFY" / "AUEP" / "AUCX" / "RSIP" / extensionVerb
MGCPVerb = "EPCF" / "CRCX" / "MDCX" / "DLCX" / "RQNT" / "NTFY" / "AUEP" / "AUCX" / "RSIP" / extensionVerb
extensionVerb = "X" 3(ALPHA / DIGIT)
extensionVerb = "X" 3(ALPHA / DIGIT)
transaction-id = 1*9(DIGIT)
transaction-id = 1*9(DIGIT)
endpointName = localEndpointName "@" DomainName
LocalEndpointName = LocalNamePart 0*("/" LocalNamePart)
LocalNamePart = AnyName / AllName / NameString
AnyName = "$"
AllNames = "*"
NameString = 1*(range-of-allowed-characters)
DomainName = 1*256(ALPHA / DIGIT / "." / "-") ; as defined in RFC 821
endpointName = localEndpointName "@" DomainName LocalEndpointName = LocalNamePart 0*("/" LocalNamePart) LocalNamePart = AnyName / AllName / NameString AnyName = "$" AllNames = "*" NameString = 1*(range-of-allowed-characters) DomainName = 1*256(ALPHA / DIGIT / "." / "-") ; as defined in RFC 821
MGCPversion = "MGCP" 1*(WSP) 1*(DIGIT) "." 1*(DIGIT)
[1*(WSP) ProfileName]
ProfileName = 1*(range-of-allowed-characters)
MGCPversion = "MGCP" 1*(WSP) 1*(DIGIT) "." 1*(DIGIT) [1*(WSP) ProfileName] ProfileName = 1*(range-of-allowed-characters)
MGCPParameter = ParameterValue EOL
MGCPParameter = ParameterValue EOL
ParameterValue = ("K" ":" 0*WSP <ResponseAck>) /
("B" ":" 0*WSP <BearerInformation>) /
("C" ":" 0*WSP <CallId>) /
("I" ":" 0*WSP <ConnectionId>) /
("N" ":" 0*WSP <NotifiedEntity>) /
("X" ":" 0*WSP <RequestIdentifier>) /
("L" ":" 0*WSP <LocalConnectionOptions>) /
("M" ":" 0*WSP <ConnectionMode>) /
("R" ":" 0*WSP <RequestedEvents>) /
("S" ":" 0*WSP <SignalRequests>) /
("D" ":" 0*WSP <DigitMap>) /
("O" ":" 0*WSP <ObservedEvents>) /
("P" ":" 0*WSP <ConnectionParameters>) /
("E" ":" 0*WSP <ReasonCode>) /
ParameterValue = ("K" ":" 0*WSP <ResponseAck>) / ("B" ":" 0*WSP <BearerInformation>) / ("C" ":" 0*WSP <CallId>) / ("I" ":" 0*WSP <ConnectionId>) / ("N" ":" 0*WSP <NotifiedEntity>) / ("X" ":" 0*WSP <RequestIdentifier>) / ("L" ":" 0*WSP <LocalConnectionOptions>) / ("M" ":" 0*WSP <ConnectionMode>) / ("R" ":" 0*WSP <RequestedEvents>) / ("S" ":" 0*WSP <SignalRequests>) / ("D" ":" 0*WSP <DigitMap>) / ("O" ":" 0*WSP <ObservedEvents>) / ("P" ":" 0*WSP <ConnectionParameters>) / ("E" ":" 0*WSP <ReasonCode>) /
Arango, et al. Informational [Page 81] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango, et al. Informational [Page 81] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
("Z" ":" 0*WSP <SpecificEndpointID>) /
("Z2" ":" 0*WSP <SecondEndpointID>) /
("I2" ":" 0*WSP <SecondConnectionID>) /
("F" ":" 0*WSP <RequestedInfo>) /
("Q" ":" 0*WSP <QuarantineHandling>) /
("T" ":" 0*WSP <DetectEvents>) /
("RM" ":" 0*WSP <RestartMethod>) /
("RD" ":" 0*WSP <RestartDelay>) /
("A" ":" 0*WSP <Capabilities>) /
("ES" ":" 0*WSP <EventStates>) /
(extensionParameter ":" 0*WSP <parameterString>)
("Z" ":" 0*WSP <SpecificEndpointID>) / ("Z2" ":" 0*WSP <SecondEndpointID>) / ("I2" ":" 0*WSP <SecondConnectionID>) / ("F" ":" 0*WSP <RequestedInfo>) / ("Q" ":" 0*WSP <QuarantineHandling>) / ("T" ":" 0*WSP <DetectEvents>) / ("RM" ":" 0*WSP <RestartMethod>) / ("RD" ":" 0*WSP <RestartDelay>) / ("A" ":" 0*WSP <Capabilities>) / ("ES" ":" 0*WSP <EventStates>) / (extensionParameter ":" 0*WSP <parameterString>)
ResponseAck = confirmedTransactionIdRange
*[ "," confirmedTransactionIdRange ]
ResponseAck = confirmedTransactionIdRange *[ "," confirmedTransactionIdRange ]
confirmedTransactionIdRange = 1*9DIGIT [ "-" 1*9DIGIT ]
confirmedTransactionIdRange = 1*9DIGIT [ "-" 1*9DIGIT ]
BearerInformation = BearerAttribute 0*("," 0*WSP BearerAttribute)
BearerAttribute = ("e" ":" <BearerEncoding>)
BearerEncoding = "A" / "mu"
BearerInformation = BearerAttribute 0*("," 0*WSP BearerAttribute) BearerAttribute = ("e" ":" <BearerEncoding>) BearerEncoding = "A" / "mu"
CallId = 1*32(HEXDIG)
CallId = 1*32(HEXDIG)
// The audit request response may include a list of identifiers
ConnectionId = 1*32(HEXDIG) 0*("," 1*32(HEXDIG))
SecondConnectionID = ConnectionId
// The audit request response may include a list of identifiers ConnectionId = 1*32(HEXDIG) 0*("," 1*32(HEXDIG)) SecondConnectionID = ConnectionId
NotifiedEntity = [LocalName "@"] DomainName [":" portNumber] LocalName = 1*32(suitableCharacter) portNumber = 1*5(DIGIT)
NotifiedEntity = [LocalName "@"] DomainName [":" portNumber] LocalName = 1*32(suitableCharacter) portNumber = 1*5(DIGIT)
RequestIdentifier = 1*32(HEXDIG)
RequestIdentifier = 1*32(HEXDIG)
LocalConnectionOptions = [ LocalOptionValue 0*(WSP)
0*("," 0*(WSP) LocalOptionValue 0*(WSP)) ]
LocalOptionValue = ("p" ":" <packetizationPeriod> )
/ ("a" ":" <compressionAlgorithm> )
/ ("b" ":" <bandwidth> )
/ ("e" ":" <echoCancellation> )
/ ("gc" ":" <gainControl> )
/ ("s" ":" <silenceSuppression> )
/ ("t" ":" <typeOfService> )
/ ("r" ":" <resourceReservation> )
/ ("k" ":" <encryptionmethod>[":"<encryptionKey>])
/ ("nt" ":" <typeOfNetwork> )
/ (localOptionExtensionName ":"
/ localOptionExtensionValue)
LocalConnectionOptions = [ LocalOptionValue 0*(WSP) 0*("," 0*(WSP) LocalOptionValue 0*(WSP)) ] LocalOptionValue = ("p" ":" <packetizationPeriod> ) / ("a" ":" <compressionAlgorithm> ) / ("b" ":" <bandwidth> ) / ("e" ":" <echoCancellation> ) / ("gc" ":" <gainControl> ) / ("s" ":" <silenceSuppression> ) / ("t" ":" <typeOfService> ) / ("r" ":" <resourceReservation> ) / ("k" ":" <encryptionmethod>[":"<encryptionKey>]) / ("nt" ":" <typeOfNetwork> ) / (localOptionExtensionName ":" / localOptionExtensionValue)
Arango, et al. Informational [Page 82] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango, et al. Informational [Page 82] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Capabilities = [ CapabilityValue 0*(WSP)
0*("," 0*(WSP) CapabilityValue 0*(WSP)) ]
Capabilities = [ CapabilityValue 0*(WSP) 0*("," 0*(WSP) CapabilityValue 0*(WSP)) ]
CapabilityValue = LocalOptionValue
/ ("v" ":" <supportedPackages>)
/ ("m" ":" <supportedModes> )
CapabilityValue = LocalOptionValue / ("v" ":" <supportedPackages>) / ("m" ":" <supportedModes> )
packetizationPeriod = 1*4(DIGIT)["-" 1*4(DIGIT)]
compressionAlgorithm = algorithmName 0*(";" algorithmName)
algorithmName = 1*32(SuitableCharacter)
bandwidth = 1*4(DIGIT)["-" 1*4(DIGIT)]
echoCancellation = "on" / "off"
gainControl = "auto" / ["-"]1*4(DIGIT)
silenceSuppression = "on" / "off"
typeOfService = 2HEXDIG
resourceReservation = "g" / "cl" / "be"
packetizationPeriod = 1*4(DIGIT)["-" 1*4(DIGIT)] compressionAlgorithm = algorithmName 0*(";" algorithmName) algorithmName = 1*32(SuitableCharacter) bandwidth = 1*4(DIGIT)["-" 1*4(DIGIT)] echoCancellation = "on" / "off" gainControl = "auto" / ["-"]1*4(DIGIT) silenceSuppression = "on" / "off" typeOfService = 2HEXDIG resourceReservation = "g" / "cl" / "be"
;encryption parameters are coded as in SDP (RFC 2327)
encryptiondata = ( "clear" ":" <encryptionKey> )
/ ( "base64" ":" <encodedEncryptionKey> )
/ ( "uri" ":" <URItoObtainKey> )
/ ( "prompt" ) ; defined in SDP, not usable in MGCP!
encryptionKey = 1*(SuitableCharacter / SP)
encodedEncryptionKey = 1*(ALPHA / DIGIT / "+" / "/" / "=")
URItoObtainKey = 1*(SuitableCharacter) / quotedString
;encryption parameters are coded as in SDP (RFC 2327) encryptiondata = ( "clear" ":" <encryptionKey> ) / ( "base64" ":" <encodedEncryptionKey> ) / ( "uri" ":" <URItoObtainKey> ) / ( "prompt" ) ; defined in SDP, not usable in MGCP! encryptionKey = 1*(SuitableCharacter / SP) encodedEncryptionKey = 1*(ALPHA / DIGIT / "+" / "/" / "=") URItoObtainKey = 1*(SuitableCharacter) / quotedString
typeOfNetwork = "IN" / "ATM" / "LOCAL"
supportedModes= ConnectionMode 0*(";" ConnectionMode)
supportedPackages = packageName 0*(";" packageName)
typeOfNetwork = "IN" / "ATM" / "LOCAL" supportedModes= ConnectionMode 0*(";" ConnectionMode) supportedPackages = packageName 0*(";" packageName)
localOptionExtensionName = "x" ("+"/"-") 1*32(SuitableCharacter)
localOptionExtensionValue = 1*32(SuitableCharacter) / quotedString
localOptionExtensionName = "x" ("+"/"-") 1*32(SuitableCharacter) localOptionExtensionValue = 1*32(SuitableCharacter) / quotedString
ConnectionMode = "sendonly" / "recvonly" / "sendrecv" /
"confrnce" / "inactive" / "loopback" /
"conttest" / "netwloop" / "netwtest" / "data"
ConnectionMode = "sendonly" / "recvonly" / "sendrecv" / "confrnce" / "inactive" / "loopback" / "conttest" / "netwloop" / "netwtest" / "data"
RequestedEvents = [requestedEvent 0*("," 0*(WSP) requestedEvent)]
requestedEvent = eventName [ "(" requestedActions ")" ]
RequestedEvents = [requestedEvent 0*("," 0*(WSP) requestedEvent)] requestedEvent = eventName [ "(" requestedActions ")" ]
eventName = [ (packageName / "*") "/" ] (eventId / "all" / eventRange)
[ "@" (ConnectionId / "$" / "*") ]
packageName = 1*(ALPHA / DIGIT / HYPHEN)
eventId = 1*(SuitableCharacter)
eventRange = "[" 1*(DIGIT / DTMFLetter / "*" / "#" /
eventName = [ (packageName / "*") "/" ] (eventId / "all" / eventRange) [ "@" (ConnectionId / "$" / "*") ] packageName = 1*(ALPHA / DIGIT / HYPHEN) eventId = 1*(SuitableCharacter) eventRange = "[" 1*(DIGIT / DTMFLetter / "*" / "#" /
Arango, et al. Informational [Page 83] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango, et al. Informational [Page 83] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
(DIGIT "-" DIGIT)/(DTMFLetter "-"
DTMFLetter)) "]"
(DIGIT "-" DIGIT)/(DTMFLetter "-" DTMFLetter)) "]"
requestedActions = requestedAction 0*("," 0*(WSP) requestedAction)
requestedAction = "N" / "A" / "D" / "S" / "I" / "K" /
"E" "(" EmbeddedRequest ")"
requestedActions = requestedAction 0*("," 0*(WSP) requestedAction) requestedAction = "N" / "A" / "D" / "S" / "I" / "K" / "E" "(" EmbeddedRequest ")"
EmbeddedRequest = ( "R" "(" EmbeddedRequestList ")"
["," "S" "(" EmbeddedSignalRequest ")" ]
["," "D" "(" EmbeddedDigitMap ")" ] )
/ ( "S" "(" EmbeddedSignalRequest ")"
["," "D" "(" EmbeddedDigitMap ")" ] )
/ ( "D" "(" EmbeddedDigitMap ")" )
EmbeddedRequest = ( "R" "(" EmbeddedRequestList ")" ["," "S" "(" EmbeddedSignalRequest ")" ] ["," "D" "(" EmbeddedDigitMap ")" ] ) / ( "S" "(" EmbeddedSignalRequest ")" ["," "D" "(" EmbeddedDigitMap ")" ] ) / ( "D" "(" EmbeddedDigitMap ")" )
EmbeddedRequestList = RequestedEvents EmbeddedSignalRequest = SignalRequests EmbeddedDigitMap = DigitMap
EmbeddedRequestList = RequestedEvents EmbeddedSignalRequest = SignalRequests EmbeddedDigitMap = DigitMap
SignalRequests = [ SignalRequest 0*("," 0*(WSP) SignalRequest ) ]
SignalRequest = eventName [ "(" eventParameters ")" ]
eventParameters = eventParameter 0*("," 0*(WSP) eventParameter)
eventParameter = eventParameterString / quotedString
eventParameterString = 1*(SuitableCharacter)
SignalRequests = [ SignalRequest 0*("," 0*(WSP) SignalRequest ) ] SignalRequest = eventName [ "(" eventParameters ")" ] eventParameters = eventParameter 0*("," 0*(WSP) eventParameter) eventParameter = eventParameterString / quotedString eventParameterString = 1*(SuitableCharacter)
DigitMap = DigitString / "(" DigitStringList ")"
DigitStringList = DigitString 0*( "|" DigitString )
DigitString = 1*(DigitStringElement)
DigitStringElement = DigitPosition ["."]
DigitPosition = DigitMapLetter / DigitMapRange
DigitMapLetter = DIGIT / "#" / "*" / "A" / "B" / "C" / "D" / "T"
DigitMapRange = "x" / "[" 1*DigitLetter "]"
DigitLetter ::= *((DIGIT "-" DIGIT ) / DigitMapLetter)
DigitMap = DigitString / "(" DigitStringList ")" DigitStringList = DigitString 0*( "|" DigitString ) DigitString = 1*(DigitStringElement) DigitStringElement = DigitPosition ["."] DigitPosition = DigitMapLetter / DigitMapRange DigitMapLetter = DIGIT / "#" / "*" / "A" / "B" / "C" / "D" / "T" DigitMapRange = "x" / "[" 1*DigitLetter "]" DigitLetter ::= *((DIGIT "-" DIGIT ) / DigitMapLetter)
ObservedEvents = SignalRequests EventStates = SignalRequests
ObservedEvents = SignalRequests EventStates = SignalRequests
ConnectionParameters = [ConnectionParameter
0*( "," 0*(WSP) ConnectionParameter )
ConnectionParameter = ( "PS" "=" packetsSent )
/ ( "OS" "=" octetsSent )
/ ( "PR" "=" packetsReceived )
/ ( "OR" "=" octetsReceived )
/ ( "PL" "=" packetsLost )
/ ( "JI" "=" jitter )
/ ( "LA" "=" averageLatency )
/ ( ConnectionParameterExtensionName "="
ConnectionParameterExtensionValue )
packetsSent = 1*9(DIGIT)
ConnectionParameters = [ConnectionParameter 0*( "," 0*(WSP) ConnectionParameter ) ConnectionParameter = ( "PS" "=" packetsSent ) / ( "OS" "=" octetsSent ) / ( "PR" "=" packetsReceived ) / ( "OR" "=" octetsReceived ) / ( "PL" "=" packetsLost ) / ( "JI" "=" jitter ) / ( "LA" "=" averageLatency ) / ( ConnectionParameterExtensionName "=" ConnectionParameterExtensionValue ) packetsSent = 1*9(DIGIT)
Arango, et al. Informational [Page 84] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango, et al. Informational [Page 84] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
octetsSent = 1*9(DIGIT) packetsReceived = 1*9(DIGIT) octetsReceived = 1*9(DIGIT) packetsLost = 1*9(DIGIT) jitter = 1*9(DIGIT) averageLatency = 1*9(DIGIT) ConnectionParameterExtensionName = "X" "-" 2*ALPHA ConnectionParameterExtensionValue = 1*9(DIGIT)
octetsSent=1*9(DIGIT)packetsReceived=1*9(DIGIT)octetsReceived=1*9(DIGIT)packetsLost=1*9(DIGIT)ジター=1*9(DIGIT)averageLatency=1*9(DIGIT)ConnectionParameterExtensionNameは「X」「-」2*アルファConnectionParameterExtensionValue=1*9と等しいです。(ケタ)
ReasonCode = 3DIGIT [SPACE 1*(%x20-7E)]
ReasonCodeは3DIGITと等しいです。[スペース1*(%x20 7E)]
SpecificEndpointID = endpointName SecondEndpointID = endpointName
SpecificEndpointID=endpointName SecondEndpointIDはendpointNameと等しいです。
RequestedInfo = [infoCode 0*("," infoCode)]
RequestedInfo=[infoCode0*、(「」、infoCode]
infoCode = "B" / "C" / "I" / "N" / "X" / "L" / "M" /
"R" / "S" / "D" / "O" / "P" / "E" / "Z" /
"Q" / "T" / "RC" / "LC" / "A" / "ES" / "RM" / "RD"
等しい..C
QuarantineHandling = loopControl / processControl /
(loopControl "," processControl )
loopControl = "step" / "loop"
processControl = "process" / "discard"
「QuarantineHandlingがloopControl / processControl /と等しい、(loopControl、」、「ステップ」/「輪」」 processControl) loopControl=processControl=は「処理する」か、または「捨てます」。
DetectEvents = [eventName 0*("," eventName)]
DetectEvents=[eventName0*、(「」、eventName]
RestartMethod = "graceful" / "forced" / "restart" / "disconnected"
「優雅な」RestartMethod=/は、「強制する」か、「再開する」、または「切断しました」。
RestartDelay = 1*6(DIGIT)
RestartDelay=1*6(ケタ)
extensionParameter = "X" ("-"/"+") 1*6(ALPHA / DIGIT)
parameterString = 1*(%x20-7F)
「extensionParameterが「X」と等しい、(「-」/、」 +、」、)、1*6(アルファー/ケタ)parameterString=1*(%x20 7F)
MGCPResponse = MGCPResponseLine 0*(MGCPParameter)
[EOL *SDPinformation]
MGCPResponseはMGCPResponseLine0*(MGCPParameter)と等しいです。[EOL*SDPinformation]
MGCPResponseLine = (<responseCode> 1*(WSP) <transaction-id>
[1*(WSP) <responseString>] EOL)
responseCode = 3DIGIT
responseString = *(%x20-7E)
MGCPResponseLine=(<responseCode>1*(WSP)<トランザクションイド>[1*(WSP)<responseString>]EOL)responseCodeは3DIGIT responseString=*と等しいです。(%x20 7E)
SuitableCharacter= DIGIT / ALPHA / "+" / "-" / "_" / "&" /
"!" / "'" / "|" / "=" / "#" / "?" / "/" /
"." / "$" / "*" / ";" / "@" / "[" / "]" /
"^" / "`" / "{" / "}" / "~"
SuitableCharacterはケタ/アルファ/「+」/「-」/"_"/“&"/“!"と等しいです。 / "'" / "|" / "=" / "#" / "?" / "/" / "." / "$" / "*" / ";" / "@" / "[" / "]" / "^" / "`" / "{" / "}" / "~"
quotedString = DQUOTE visibleString
quotedStringはDQUOTE visibleStringと等しいです。
Arango, et al. Informational [Page 85] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[85ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
0*(quoteEscape visibleString) DQUOTE
quoteEscape = DQUOTE DQUOTE
visibleString = (%x00-21 / %x23-FF)
EOL = CRLF / LF
0*(quoteEscape visibleString)DQUOTE quoteEscape=DQUOTE DQUOTE visibleString=(%x00-21/%x23-ff)EOLはCRLF / LFと等しいです。
SDPinformation = ;See RFC 2327
SDPinformation=; RFC2327を見てください。
3.5. Encoding of the session description
3.5. セッション記述のコード化
The session description is encoded in conformance with the session description protocol, SDP. MGCP implementations are expected to be fully capable of parsing any conformant SDP message, and should send session descriptions that strictly conform to the SDP standard. The usage of SDP actually depends on the type of session that is being, as specified in the "mode" parameter:
SDP、セッション記述はセッション記述プロトコルで順応でコード化されます。 MGCP実装は、どんなconformant SDPメッセージも完全に分析できると予想されて、厳密にSDP規格に従うセッション記述を送るべきです。 SDPの使用法を実際に「モード」パラメタで指定されるように存在であるセッションのタイプに頼っています:
* if the mode is set to "data", the session description describes
the configuration of a data access service.
* モードが「データ」に設定されるなら、セッション記述はデータアクセス・サービスの構成について説明します。
* if the mode is set to any other value, the session description is
for an audio service.
* モードがいかなる他の値にも設定されるなら、セッション記述はオーディオサービスのためのものです。
For an audio service, the gateway will consider the information provided in SDP for the "audio" media. For a data service, the gateway will consider the information provided for the "network- access" media.
オーディオサービスのために、ゲートウェイは「オーディオ」メディアのためにSDPに提供された情報を考えるでしょう。 データサービスのために、ゲートウェイは、情報が「ネットワークアクセス」メディアに備えたと考えるでしょう。
3.5.1. Usage of SDP for an audio service
3.5.1. オーディオサービスのためのSDPの使用法
In a telephony gateway, we only have to describe sessions that use exactly one media, audio. The parameters of SDP that are relevant for the telephony application are:
電話ゲートウェイでは、私たちはまさに1つのメディア、オーディオを使用するセッションについて説明するだけでよいです。 電話アプリケーションにおいて、関連しているSDPのパラメタは以下の通りです。
At the session description level:
セッション記述レベルで:
* The IP address of the remote gateway (in commands) or of the
local gateway (in responses), or multicast address of the audio
conference, encoded as an SDP "connection data" parameter. This
parameter specifies the IP address that will be used to
exchange RTP packets.
* リモートゲートウェイ(コマンドにおける)か地方のゲートウェイ(応答における)のアドレス、またはオーディオ会議のマルチキャストアドレスがSDP「接続データ」パラメタとしてコード化したIP。 このパラメタはRTPパケットを交換するのに使用されるIPアドレスを指定します。
For the audio media:
オーディオメディアのために:
* Media description field (m) specifying the audio media, the
transport port used for receiving RTP packets by the remote
gateway (commands) or by the local gateway (responses), the
* メディア記述はオーディオメディアを指定しながら、(m)をさばきます、リモートゲートウェイ(コマンド)の近くか地方のゲートウェイ(応答)のそばでRTPパケットを受けるのに使用される輸送ポート
Arango, et al. Informational [Page 86] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[86ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
RTP/AVP transport, and the list of formats that the gateway
will accept. This list should normally always include the code
0 (reserved for PCMU).
RTP/AVP輸送、およびゲートウェイが受け入れる形式のリスト。 通常、このリストはいつもコード0(PCMUのために、予約されます)を含んでいるはずです。
* Optionally, RTPMAP attributes that define the encoding of
dynamic audio formats,
* 任意に、ダイナミックなオーディオ形式のコード化を定義するRTPMAP属性
* Optionally, a packetization period (packet time) attribute
(Ptime) defining the duration of the packet,
* 任意に、packetizationの期間(パケット時間)は、パケットの持続時間を定義しながら、(Ptime)を結果と考えます。
* Optionally, an attribute defining the type of connection
(sendonly, recvonly, sendrecv, inactive). Note that this
attribute does not have a direct relation with the "Mode"
parameter of MGCP. In fact, the SDP type of connection will
most of the time be set to "sendrecv", regardless of the value
used by MGCP. Other values will only be used rarely, for
example in the case of information or announcement servers that
need to establish one way connections.
* 任意に、接続(recvonlyに、sendrecvで、不活発な状態で、sendonlyする)のタイプを定義する属性。 MGCPの「モード」パラメタとのダイレクト関係がこの属性にないことに注意してください。 事実上、接続のSDPタイプはたいてい"sendrecv"に用意ができるでしょう、MGCPによって使用された値にかかわらず。 他の値はめったに使用されるだけではないでしょう、例えば、一方通行の接続を確立する必要がある情報か発表サーバの場合で。
* The IP address of the remote gateway (in commands) or of the
local gateway (in responses), if it is not present at the
session level.
* リモートゲートウェイ(コマンドにおける)か地方のゲートウェイ(応答における)のIPアドレスそれがセッションレベルで存在していないなら。
An example of SDP specification for an audio connection could be:
オーディオ接続のためのSDP仕様に関する例は以下の通りであるかもしれません。
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
.1mのIN IP4 128.96.41=オーディオの3456RTP/AVP0 96v=0c=a=rtpmap: 96G726-32/8000
There is a request, in some environments, to use the MGCP to negotiate connections that will use other transmission channels than RTP over UDP and IP. This will be detailed in an extension to this document.
UDPの上のRTPとIP以外のトランスミッションチャンネルを使用する接続を交渉するのにMGCPを使用するために、いくつかの環境には要求があります。 これはこのドキュメントへの拡大で詳細になるでしょう。
3.5.2. Usage of SDP in a network access service
3.5.2. ネットワークアクセス・サービスにおけるSDPの使用法
The parameters of SDP that are relevant for a data network access application are:
データ網アクセスアプリケーションにおいて、関連しているSDPのパラメタは以下の通りです。
For the data media:
データメディアのために:
* Media description field (m) specifying the network access
media, identified by the code "m=nas/xxxx", where "xxxx"
describes the access control method that should be used for
parametrizing the network access, as specified below. The field
may also specify the port that should be used for contacting
the server, as specified in the SDP syntax.
* "xxxx"がアクセスについて説明するコード「m=nas/xxxx」によって特定されたネットワークアクセスメディアを指定するメディア記述分野(m)がネットワークアクセスをparametrizingするのに使用されるべきであるメソッドを制御します、以下で指定されるとして。 また、分野はサーバに連絡するのに使用されるべきであるポートを指定するかもしれません、SDP構文で指定されるように。
Arango, et al. Informational [Page 87] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[87ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
* Connection address parameter (c=) specifying the address, or
the domain name, of the server that implement the access
control method. This parameter may also be specified at the
session level.
* 接続アドレスパラメタ(c=)がアドレス、またはドメイン名を指定して、サーバでは、それは、アクセス制御がメソッドであると実装します。 また、このパラメタはセッションレベルで指定されるかもしれません。
* Optionally, a bearer type attribute (a=bearer:) describing the
type of data connection to be used, including the modem type.
* 運搬人タイプ属性(=運搬人:)が使用されるためにデータ接続のタイプについて説明して、モデムを含んでいて、任意に、タイプしてください。
* Optionally, a framing type attribue (a=framing:) describing the
type of framing that will be used on the channel.
* 任意に、それを縁どるタイプについて説明する縁どりタイプattribue(以下を縁どる=)はチャンネルの上に使用されるでしょう。
* Optionally, attributes describing the called number
(a=dialed:), the number to which the call was delivered
(a=called:) and the calling number (a=dialing:).
* 任意に、呼ばれた数(=はダイヤルした:)、呼び出しが提供された数(=は呼んだ:)、および呼ぶことについて説明する属性が(以下にダイヤルする=)に付番します。
* Optionally, attributes describing the range of addresses that
could be used by the dialup client on its LAN (a=subnet:).
* 任意に、ダイアルアップクライアントがLAN(=サブネット:)で使用できたアドレスの範囲について説明する属性。
* Optionally, an encryption key, encoded as specified in the SDP
protocol(k=).
* 任意に、SDPの指定されるとして主要で、コード化された暗号化は(k=)について議定書の中で述べます。
The connection address shall be encoded as specified in the SDP standard. It will be used in conjunction with the port specified in the media line to access a server, whose type will one of:
接続アドレスはSDP規格で指定されるようにコード化されるものとします。 それは以下についてタイプが1つを望んでいるサーバにアクセスするためにメディア系列で指定されたポートに関連して使用されるでしょう。
__________________________________________________________
| Method name| Method description |
|____________|____________________________________________|
| radius | Authentication according |
| | to the Radius protocol. |
| tacacs | Authentication according |
| | to the TACACS+ protocol. |
| diameter | Authentication according |
| | to the Diameter protocol. |
| l2tp | Level 2 tunneling protocol. |
| | The address and port are those of the LNS.|
| login | Local login. (There is normally |
| | no server for that method.) |
| none | No authentication required. |
| | (The call was probably vetted |
| | by the Call Agent.) |
|____________|____________________________________________|
__________________________________________________________ | メソッド名| メソッド記述| |____________|____________________________________________| | 半径| 認証一致| | | Radiusに、議定書を作ってください。 | | tacacs| 認証一致| | | TACACS+プロトコルに。 | | 直径| 認証一致| | | Diameterに、議定書を作ってください。 | | l2tp| レベル2 プロトコルにトンネルを堀ります。 | | | アドレスとポートがLNSのものである、|| ログイン| 地方のログイン。 (通常、あります| | | そのメソッドのためのサーバがありません) | | なし| どんな認証も必要ではありません。 | | | 診察されて、呼び出しはたぶんそうでした。(| | | Callエージェントで) | |____________|____________________________________________|
If needed, the gateway may use the key specified in the announcement to access the service. That key, in particular, may be used for the establishment of an L2TP tunnel.
必要であるなら、ゲートウェイはサービスにアクセスするために発表で指定されたキーを使用するかもしれません。 そのキーはL2TPトンネルの設立に特に使用されるかもしれません。
Arango, et al. Informational [Page 88] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[88ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
The bearer attribute is composed of a bearer name and an optional extension. The bearer type specifies the type of modulation (modem name) or, in the case of digital connections, the type of ISDN service (8 bits, 7 bits). When an extension is present, it is separated from the bearer name by a single slash (/). The valid values of the bearer attribute are defined in the following table:
運搬人属性は運搬人名と任意の拡大で構成されます。 運搬人タイプは変調(モデム名)のタイプかデジタル接続の場合におけるISDNサービスのタイプ(8ビットと、7ビット)を指定します。 拡大が存在しているとき、ただ一つのスラッシュ(/)によってそれは運搬人名と切り離されます。 運搬人属性の有効値は以下のテーブルで定義されます:
____________________________________________________________________
| Type of bearer description | Example of values |
|_________________________________|_________________________________|
| ITU modem standard | V.32, V.34, V.90. |
| ITU modem standard qualified | v.90/3com, |
| by a manufacturer name | v.90/rockwell, |
| | v.90/xxx |
| Well known modem types | X2, K56flex |
| ISDN transparent access, 64 kbps| ISDN64 |
| ISDN64 + V.110 | ISDN64/V.110 |
| ISDN64 + V.120 | ISDN64/V.120 |
| ISDN transparent access, 56 kbps| ISDN56 |
| Informal identification | (Requires coordination between |
| | the Call Agent and the gateway)|
|_________________________________|_________________________________|
____________________________________________________________________ | 運搬人記述のタイプ| 値に関する例| |_________________________________|_________________________________| | ITUモデム規格| V.32、V.34、V.90。 | | ITUモデム規格は資格を得ました。| v.90/3com| | メーカー名で| v.90/rockwell| | | v.90/xxx| | 顔が広いモデムタイプ| X2、K56flex| | ISDNのわかりやすいアクセス、64キロビット毎秒| ISDN64| | ISDN64+V.110| ISDN64/V.110| | ISDN64+V.120| ISDN64/V.120| | ISDNのわかりやすいアクセス、56キロビット毎秒| ISDN56| | 非公式の識別| (|間のコーディネート| | Callエージェントとゲートウェイを必要とします)| |_________________________________|_________________________________|
The valid values of the framing attribute are defined in the following table:
縁どり属性の有効値は以下のテーブルで定義されます:
_________________________________________________
| Type of framing description| Example of values|
|____________________________|___________________|
| PPP, asynchronous framing | ppp-asynch |
| PPP, HDLC framing | ppp-hdlc |
| SLIP, asynchronous | slip |
| Asynchronous, no framing | asynch |
|____________________________|___________________|
_________________________________________________ | 縁どり記述のタイプ| 値に関する例| |____________________________|___________________| | PPP、非同期な縁どり| ppp-asynch| | PPP、HDLC縁どり| ppp-hdlc| | SLIPで、非同期です。| メモ用紙| | 非同期で、縁どりません。| asynch| |____________________________|___________________|
The network access authentication parameter provides instructions on the access control that should be exercized for the data call. This optional attribute is encoded as:
ネットワークアクセス認証パラメタはデータ呼び出しのためにexercizedされるべきであるアクセス制御の指示を提供します。 この任意の属性は以下としてコード化されます。
"a=subnet:" <network type> <address type>
<connection address> "/" <prefix length>
「=サブネット:」 「<ネットワークタイプ><アドレスタイプ><接続アドレス>」/」 <接頭語の長さ>。
Where the parameters "network type", "address type", and "connection address" are formatted as defined for the connection address parameter (c=) in SDP, and where the "prefix length" is a decimal representation of the number of bits in the prefix.
パラメタが「タイプをネットワークでつなぐところ」では、「アドレスタイプ」、および「接続アドレス」はSDPの接続アドレスパラメタ(c=)のために定義されて、「接頭語の長さ」が接頭語のビットの数の10進表現であるところでフォーマットされます。
Arango, et al. Informational [Page 89] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[89ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Examples of SDP announcement for the network access service could be:
ネットワークアクセス・サービスのためのSDP発表に関する例は以下の通りであるかもしれません。
v=0
m=nas/radius
c=IN IP4 radius.example.net
a=bearer:v.34
a=framing:ppp-asynch
a=dialed:18001234567
a=called:12345678901
a=dialing:12340567890
=運搬人: =縁どり: ppp asynch a=がダイヤルしたv.34: 1=あたり18001234567が呼んだv=0m=IN nas/半径c=IP4 radius.example.net: : 12340567890にダイヤルする1=あたり12345678901
v=0
m=nas/none
c=IN IP4 128.96.41.1
a=subnet:IN IP4 123.45.67.64/26
a=bearer:isdn64
a=framing:ppp-sync
a=dialed:18001234567
a=dialing:2345678901
v=0mがnas/cのいずれも=でないIN IP4と等しい、128.96、.41、.1、以下を縁どりますppp同時性a=がダイヤルした: 18001234567a=ダイヤルすること: 運搬人: =サブネット: IN IP4 123.45.67.64/26a=isdn64 a=2345678901
v=0
c=IN IP4 access.example.net
m=nas/l2tp
k=clear:some-shared-secret
a=bearer:v.32
a=framing:ppp-asynch
a=dialed:18001234567
a=dialing:2345678901
v=0cは= はっきりとIN IP4アクセサリーexample.net m=nas/l2tp kと等しいです: 共有されていくつか秘密のaは運搬人と等しいです: v.32aは縁どりと等しいです: ppp asynch a=は: 18001234567a=ダイヤルすること: 2345678901にダイヤルしました。
3.5.3. Usage of SDP for ATM connections
3.5.3. ATM接続のためのSDPの使用法
The specification of the SDP payload for ATM connections will be described in a companion document, "Usage of MGCP to control Voice over ATM gateways." The following text is indicative.
ATM接続のためのSDPペイロードの仕様は仲間ドキュメント、「ATMゲートウェイの上でVoiceを制御するMGCPの使用法」で説明されるでしょう。 以下のテキストは暗示しています。
The SDP payload will specify:
SDPペイロードは指定するでしょう:
* That the connection is to be established over an ATM interface,
using the "c=" parameter of SDP to specify an address in the ATM
family, the ATM addressing variant (NSAP, UNI, E.164) and the ATM
address.
* それ、接続はATMインタフェースの上で確立されることになっています、ATMファミリーにおけるアドレス、ATMアドレシング異形(NSAP、UNI、E.164)、およびATMアドレスを指定するのにSDPの「c=」パラメタを使用して。
* The "m=audio" parameter will specify the audio encoding and, if
needed, the VPI and VCI.
* 「m=オーディオ」のパラメタは必要でありオーディオコード化、VPI、およびVCIを指定するでしょう。
* Additional attributes parameters (a=) will be used to specify the
ATM coding variants, such as the type of adaptation layer and the
error correction or loss compenmsation algorithms.
* 追加属性パラメタ(=)はATMコード化異形を指定するのに使用されるでしょう、適合層のタイプやエラー修正や損失compenmsationアルゴリズムのように。
Arango, et al. Informational [Page 90] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[90ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
An example of SDP payload for an ATM connection could be:
ATM接続のためのSDPペイロードに関する例は以下の通りであるかもしれません。
v=0 c=ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.fe m=audio
5/1002 ATM/AVP PCMU a=connection_type:AAL2
接続_オーディオの5/1002v=0 c=ATM NSAP47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.fe m=ATM/AVP PCMU a=タイプ: AAL2
3.5.4. Usage of SDP for local connections
3.5.4. 市内接続のためのSDPの使用法
When MGCP is used to set up internal connections within a single gateway, the SDP format is used to encode the parameters of that connection. The following parameters will be used:
MGCPが1門の中で内部の接続をセットアップするのに使用されるとき、SDP形式は、その接続のパラメタをコード化するのに使用されます。 以下のパラメタは使用されるでしょう:
* The connection parameter (C=) will specify that the connection is
local, using the keyword "LOCAL" as network type space, the
keyword "EPN" (endpoint name) as address type, and the name of
the endpoint as the connection-address.
* 接続パラメタ(C=)は、接続が地元であると指定するでしょう、接続アドレスとしてネットワークタイプスペースとしての「地方」のキーワード、アドレスタイプとしてのキーワード"EPN"(終点名)、および終点の名前を使用して。
* The "m=audio" parameter will specify a port number, which will
always be set to 0, the type of protocol, always set to the
keyword LOCAL, and the type of encoding, using the same
conventions used for RTP (RTP payload numbers.) The type of
encoding should normally be set to 0 (PCMU).
* 「m=オーディオ」のパラメタはポートナンバーを指定するでしょう、RTP(RTPペイロード番号)に使用される同じコンベンションを使用して。(ポートナンバーはいつも0、いつもキーワードLOCALに設定されたプロトコルのタイプ、およびコード化のタイプに設定されるでしょう)。 通常、コード化のタイプは0(PCMU)に用意ができているはずです。
An example of local SDP payload could be:
地方のSDPペイロードに関する例は以下の通りであるかもしれません。
v=0
c=LOCAL EPN X35V3+A4/13
m=audio 0 LOCAL 0
v=0 c=LOCAL EPN X35V3+A4/13mはオーディオの0LOCAL0と等しいです。
3.6. Transmission over UDP
3.6. UDPの上のトランスミッション
MGCP messages are transmitted over UDP. Commands are sent to one of the IP addresses defined in the DNS for the specified endpoint . The responses are sent back to the source address of the commands.
MGCPメッセージはUDPの上に送られます。 DNSで指定された終点と定義されたIPアドレスの1つにコマンドを送ります。コマンドのソースアドレスを応答に送り返します。
When no port is specified for the endpoint, the commands should be sent:
ポートを全く終点に指定しないとき、コマンドを送るべきです:
* by the Call Agents, to the default MGCP port for gateways, 2427.
* MGCPがゲートウェイ、2427年のために移植するデフォルトへのCallエージェントで。
* by the Gateways, to the default MGCP port for Call Agents, 2727.
* Gatewaysで、デフォルトに、MGCPはCallのためにエージェント、2727を移植します。
3.6.1. Providing the At-Most-Once functionality
3.6.1. At、最も一度、機能性
MGCP messages, being carried over UDP, may be subject to losses. In the absence of a timely response, commands are repeated. Most MGCP commands are not idempotent. The state of the gateway would become
UDPに伝えられるMGCPメッセージは損失を被りやすいかもしれません。 タイムリーな応答がないとき、コマンドは繰り返されます。 ほとんどのMGCPコマンドはベキ等元ではありません。 ゲートウェイの状態はなるでしょう。
Arango, et al. Informational [Page 91] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[91ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
unpredictable if, for example, CreateConnection commands were executed several times. The transmission procedures must thus provide an "At-Most-Once" functionality.
コマンドが例えば、CreateConnectionであるなら何度か実行されたのを予測できません。 その結果、トランスミッション手順が提供されなければならない、「大部分、一度、」 機能性。
MGCP entities are expected to keep in memory a list of the responses that they sent to recent transactions and a list of the transactions that are currently being executed. The transaction identifiers of incoming commands are compared to the transaction identifiers of the recent responses. If a match is found, the MGCP entity does not execute the transaction, but simply repeats the response. The remaining commands will be compared to the list of current transaction. If a match is found, the MGCP entity does not execute the transaction, which is simply ignored.
MGCP実体がメモリにそれらが最近のトランザクションに送った応答のリストと現在実行されているトランザクションのリストを保つと予想されます。 受信コマンドに関するトランザクション識別子は最近の応答に関するトランザクション識別子にたとえられます。 マッチが見つけられるなら、MGCP実体は、トランザクションを実行しませんが、単に応答を繰り返します。 残っているコマンドは経常取引のリストにたとえられるでしょう。 マッチが見つけられるなら、MGCP実体はトランザクションを実行しません。(それは、単に無視されます)。
The procedure use a long timer value, noted LONG-TIMER in the following. The timer should be set larger than the maximum duration of a transaction, which should take into account the maximum number of repetitions, the maximum value of the repetition timer and the maximum propagation delay of a packet in the network. A suggested value is 30 seconds.
LONG-TIMERは、以下で手順が長いタイマ値を使用することに注意しました。 タイマはネットワークで反復の最大数、反復タイマの最大値、およびパケットの最大の伝播遅延を考慮に入れるべきであるトランザクションの最大の持続時間より大きいセットであるべきです。 提案された値は30秒です。
The copy of the responses can be destroyed either LONG-TIMER seconds after the response is issued, or when the gateway (or the call agent) receives a confirmation that the response has been received, through the "Response Acknowledgement attribute". For transactions that are acknowledged through this attribute, the gateway shall keep a copy of the transaction-id for LONG-TIMER seconds after the response is issued, in order to detect and ignore duplicate copies of the transaction request that could be produced by the network.
応答のコピーは破壊されて、応答が発行された後かゲートウェイであることのLONG-TIMER秒(または、呼び出しエージェント)は受け取られていた状態で応答があった確認を受け取ります、「応答Acknowledgement属性」を通してことであるかもしれません。 この属性を通して承認されるトランザクションのために、応答が発行された秒後にゲートウェイはLONG-TIMERのためのトランザクションイドの写しを取っておくものとします、ネットワークが作り出すことができたトランザクション要求の写本を検出して、無視するために。
3.6.2. Transaction identifiers and three ways handshake
3.6.2. トランザクション識別子と3つの方法、握手
Transaction identifiers are integer numbers in the range from 0 to 999,999,999. Call-agents may decide to use a specific number space for each of the gateways that they manage, or to use the same number space for all gateways that belong to some arbitrary group. Call agents may decide to share the load of managing a large gateway between several independent processes. These processes will share the same transaction number space. There are multiple possible implementations of this sharing, such as having a centralized allocation of transaction identifiers, or pre-allocating non- overlapping ranges of identifiers to different processes. The implementations must guarantee that unique transaction identifiers are allocated to all transactions that originate from a logical call agent, as defined in the "states, failover and race conditions" section. Gateways can simply detect duplicate transactions by looking at the transaction identifier only.
トランザクション識別子は0〜9億9999万9999までの範囲の整数です。 呼び出しエージェントは、それらが管理するそれぞれのゲートウェイに特定の数のスペースを使用するか、または何らかの任意のグループのものすべてのゲートウェイに同じ数のスペースを使用すると決めるかもしれません。 呼び出しエージェントは、いくつかの独立しているプロセスの間の大きいゲートウェイを管理する負荷を共有すると決めるかもしれません。 これらのプロセスは同じトランザクション数のスペースを共有するでしょう。 この共有の複数の可能な実装があります、異なったプロセスにトランザクション識別子の集結された配分を持っているか、または非重なっている範囲に関する識別子をあらかじめ割り当てるのなどように。 実装は、ユニークなトランザクション識別子が論理的な呼び出しエージェントから発するすべてのトランザクションに割り当てられるのを保証しなければなりません、「州、フェイルオーバー、および競合条件」セクションで定義されるように。 ゲートウェイは、トランザクション識別子だけを見ることによって、単に写しトランザクションを検出できます。
Arango, et al. Informational [Page 92] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[92ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
The Response Acknowledgement Attribute can be found in any command. It carries a set of "confirmed transaction-id ranges."
どんなコマンドでもResponse Acknowledgement Attributeを見つけることができます。 それは1セットの「確認されたトランザクションイド範囲」を運びます。
MGCP gateways may choose to delete the copies of the responses to transactions whose id is included in "confirmed transaction-id ranges" received in the Response Confirmation messages. They should silently discard further commands from that Call Agent when the transaction-id falls within these ranges.
MGCPゲートウェイは、イドがResponse Confirmationメッセージに受け取られた「確認されたトランザクションイド範囲」に含まれているトランザクションへの応答のコピーを削除するのを選ぶかもしれません。 トランザクションイドがこれらの範囲の中に下がるとき、彼らはそのCallエージェントからさらなるコマンドを静かに捨てるべきです。
The "confirmed transaction-id ranges" values shall not be used if more than LONG-TIMER seconds have elapsed since the gateway issued its last response to that call agent, or when a gateway resumes operation. In this situation, commands should be accepted and processed, without any test on the transaction-id.
LONG-TIMER秒以上がゲートウェイがその呼び出しエージェントへの最後の応答を発行したか、またはゲートウェイが操作を再開するときに時経過したなら、「確認されたトランザクションイド範囲」値を使用しないものとします。 この状況で、コマンドは、トランザクションイドの少しもテストなしで受け入れられて、処理されるべきです。
Commands that carry the "Response Acknowledgement attribute" may be transmitted in disorder. The gateway shall retain the union of the "confirmed transaction-id ranges" received in recent commands.
「応答Acknowledgement属性」を運ぶコマンドは混乱で伝えられるかもしれません。 ゲートウェイは最近のコマンドで受け取られた「確認されたトランザクションイド範囲」の組合を保有するものとします。
3.6.3. Computing retransmission timers
3.6.3. 再送信タイマーを計算します。
It is the responsibility of the requesting entity to provide suitable time outs for all outstanding commands, and to retry commands when time outs have been exceeded. Furthermore, when repeated commands fail to be acknowledged, it is the responsibility of the requesting entity to seek redundant services and/or clear existing or pending connections.
それは要求実体がすべての傑出しているコマンドに適当なタイムアウトを供給して、タイムアウトが超えられているときコマンドを再試行する責任です。 繰り返されたコマンドが承認されないとき、その上、それは要求実体が余分なサービス、そして/または、明確な存在か未定の接続を求める責任です。
The specification purposely avoids specifying any value for the retransmission timers. These values are typically network dependent. The retransmission timers should normally estimate the timer by measuring the time spent between the sending of a command and the return of a response. One possibility is to use the algorithm implemented in TCP-IP, which uses two variables:
仕様は、どんな値も再送信タイマーに指定するのをわざわざ避けます。 通常、これらの値はネットワーク扶養家族です。 通常、再送信タイマーは、コマンドの送付と応答の復帰の間で費やされた時間を測定することによって、タイマを見積もっているはずです。 1つの可能性は2つの変数を使用するTCP-IPで実装されたアルゴリズムを使用することです:
* the average acknowledgement delay, AAD, estimated through an
exponentially smoothed average of the observed delays,
* 遅れ、AADが観測の指数関数的に平坦な平均で見積もっていた平均した承認は延着します。
* the average deviation, ADEV, estimated through an exponentially
smoothed average of the absolute value of the difference between
the observed delay and the current average
* 平均偏差、観測された遅れと現在の平均の違いの絶対値の指数関数的に平坦な平均で見積もられていたADEV
The retransmission timer, in TCP, is set to the sum of the average delay plus N times the average deviation. In MGCP, the maximum value of the timer should however be bounded, in order to guarantee that no repeated packet will be received by the gateways after LONG-TIMER seconds. A suggested maximum value is 4 seconds.
TCPでは、再送信タイマーは平均した遅れと平均偏差のN倍の合計に設定されます。 しかしながら、MGCPでは、タイマの最大値は境界があるべきです、繰り返されたパケットが全くLONG-TIMER秒以降ゲートウェイによって受け取られないのを保証するために。 提案された最大値は4秒です。
Arango, et al. Informational [Page 93] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[93ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
After any retransmission, the MGCP entity should do the following:
どんな「再-トランスミッション」の後にも、MGCP実体は以下をするべきです:
* It should double the estimated value of the average delay, AAD
* AAD、それは平均した遅れの見積価格を倍にするべきです。
* It should compute a random value, uniformly distributed between
0.5 AAD and AAD
* それは一様に0.5のAADとAADの間に分配された無作為の値を計算するべきです。
* It should set the retransmission timer to the sum of that random
value and N times the average deviation.
* それはその無作為の値と平均偏差のN倍の合計に再送信タイマーを設定するべきです。
This procedure has two effects. Because it includes an exponentially increasing component, it will automatically slow down the stream of messages in case of congestion. Because it includes a random component, it will break the potential synchronization between notifications triggered by the same external event.
この手順に、2つの効果があります。 指数関数的に増加するコンポーネントを含んでいるので、それは混雑の場合に自動的にメッセージのストリームを減速させるでしょう。 無作為のコンポーネントを含んでいるので、それは同じ外部のイベントによって引き起こされた通知の間の潜在的同期を壊すでしょう。
3.6.4. Piggy backing
3.6.4. 子豚の支援
There are cases when a Call Agent will want to send several messages at the same time to the same gateways. When several MGCP messages have to be sent in the same UDP packets, they should be separated by a line of text that contain a single dot, as in for example:
Callエージェントが同時にいくつかのメッセージを同じゲートウェイに送りたくなるとき、ケースがあります。 同じUDPパケットでいくつかのMGCPメッセージを送らなければならないとき、ただ一つのドットを含むテキスト行でそれらを切り離すべきです、例を受けそうで:
200 2005 OK
DLCX 1244 card23/21@trgw-7.example.net MGCP 1.0
C: A3C47F21456789F0
I: FDE234C8
200 2005はDLCX1244 card23/21@trgw-7.example.net MGCPを1.0C承認します: A3C47F21456789F0I: FDE234C8
The piggy-backed messages should be processed exactly has if they had been received in several simultaneous messages.
便乗しているメッセージは処理されるべきです。まさに、いくつかの同時のメッセージにそれらを受け取ったなら、持っています。
3.6.5. Provisional responses
3.6.5. 暫定的な応答
Executing some transactions may require a long time. Long execution times may interact with the timer based retransmission procedure. This may result either in an inordinate number of retransmissions, or in timer values that become too long to be efficient.
いくつかのトランザクションを実行するのは長い時間を必要とするかもしれません。 長い実行時間はベースのタイマで「再-トランスミッション」手順を相互作用させるかもしれません。 これは「再-トランスミッション」の過度の数、または効率的であるように思えないほど長くなるタイマ値に結果として生じるかもしれません。
Gateways that can predict that a transaction will require a long execution time may send a provisional response, with response code 100. They should send this response if they receive a repetition of a transaction that is still being executed.
トランザクションが長い実行時間を必要とすると予測できるゲートウェイは暫定的な応答を送るかもしれません、応答コード100で。 まだ実行されているトランザクションの反復を受けるなら、彼らはこの応答を送るべきです。
MGCP entities that receive a provisional response shall switch to a longer repetition timer for that transaction.
暫定的な応答を受けるMGCP実体はそのトランザクションのために、より長い反復タイマに切り替わるものとします。
Arango, et al. Informational [Page 94] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[94ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
4. States, failover and race conditions.
4. 州、フェイルオーバー、および競合条件。
In order to implement proper call signalling, the Call Agent must keep track of the state of the endpoint, and the gateway must make sure that events are properly notified to the call agent. Special conditions exist when the gateway or the call agent are restarted: the gateway must be redirected to a new call agent during "failover" procedures, the call agent must take special action when the gateway is taken offline, or restarted.
合図、Callエージェントが、終点の状態の道であることを保たなければならなくて、ゲートウェイが確実にかけなければならない適切な電話にそれを実装するために、イベントは適切に呼び出しエージェントに通知されます。 ゲートウェイか呼び出しエージェントが再出発されるとき、特別な状態は存在しています: 呼び出しエージェントは、「フェイルオーバー」手順の間、新しい呼び出しエージェントにゲートウェイを向け直さなければならなくて、ゲートウェイをオフラインで取るか、または再開するとき、特別な行動を取らなければなりません。
4.1. Basic Asumptions
4.1. 基本的なAsumptions
The support of "failover" is based on the following assumptions:
「フェイルオーバー」のサポートは以下の仮定に基づいています:
* Call Agents are identified by their domain name, not their network
addresses, and several addresses can be associated with a domain
name.
* 彼らのネットワーク・アドレスではなく、彼らのドメイン名で呼び出しエージェントを特定します、そして、いくつかのアドレスをドメイン名に関連づけることができます。
* An endpoint has one NotifiedEntity associated with it any given
point in time.
* 終点には、時間内に、それに関連している1NotifiedEntityが任意な与えられた点であります。
* The NotifiedEntity is the last value of the "NotifiedEntity"
parameter received for this endpoint (including wild-carded end-
point-names). If no explicit "NotifiedEntity" parameter has been
received, the "NotifiedEntity" defaults to the provisioned
NotifiedEntity value, or if no value was provisioned to the source
address of the last command received for the endpoint,
* NotifiedEntityはこの終点に受け取られた"NotifiedEntity"パラメタの最終値(荒野でcardedされた終わりのポイント名を含んでいて)です。 どんな明白な"NotifiedEntity"パラメタも受け取っていないなら、"NotifiedEntity"は食糧を供給されたNotifiedEntity値かそれとも値が全く終点に受け取られた持続コマンドのソースアドレスに食糧を供給されなかったかどうかをデフォルトとします。
* Responses to commands are always sent to the source address of the
command, regardless of the NotifiedEntity.
* NotifiedEntityにかかわらずいつもコマンドへの応答をコマンドのソースアドレスに送ります。
* When the "notified entity" refers to a domain name that resolves
to multiple IP- address, endpoints are capable of switching
between different interfaces on the same logical call agent,
however they cannot switch to other (backup) call agent(s) on
their own. A backup call agent can however instruct them to
switch, either directly or indirectly.
* 「通知された実体」が複数のIPへの決議が記述するドメイン名を示すとき、終点が同じ論理的な呼び出しエージェントで異なったインタフェースを切り換えることができる、しかしながら、それらは他の(バックアップ)呼び出しエージェントにそれら自身のを切り換えることができません。 しかしながら、バックアップ呼び出しエージェントは、直接か間接的に切り替わるよう彼らに命令できます。
* If an entire call agent becomes unavailable, the endpoints managed
by that call agent will eventually become "disconnected". The only
way for these endpoints to become connected again is either for
the failed call agent to become available, or for a backup call
agent to contact the affected endpoints.
* 全体の呼び出しエージェントが入手できなくなると、その呼び出しエージェントによって管理された終点は結局、「外される」ようになるでしょう。 これらの終点が再び接続されるようになる唯一の方法がどちらか利用可能になるか、またはバックアップ呼び出しエージェントが影響を受ける終点に接触する失敗した呼び出しエージェントのためのものです。
* When a backup call agent has taken over control of a group of
endpoints, it is assumed that the failed call agent will
communicate and synchronize with the backup call agent in order to
* バックアップ呼び出しエージェントが終点のグループのコントロールを持って行ったとき、失敗した呼び出しエージェントがバックアップ呼び出しエージェントに交信して、連動すると思われます。
Arango, et al. Informational [Page 95] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[95ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
transfer control of the affected endpoints back to the original
call agent (if that's even desired - maybe the failed call agent
should simply become the backup call agent now).
影響を受ける終点のコントロールをオリジナルの呼び出しエージェントに移して戻してください、(それは望まれさえします--多分、失敗した呼び出しエージェントが現在単にバックアップ呼び出しエージェントになるべきである、)
We should note that handover conflict resolution between separate CA's is not in place - we are relying strictly on the CA's knowing what they are doing and communicating with each other (although AuditEndpoint can be used to learn about the current NotifiedEntity).
We should note that handover conflict resolution between separate CA's is not in place - we are relying strictly on the CA's knowing what they are doing and communicating with each other (although AuditEndpoint can be used to learn about the current NotifiedEntity).
4.2. Security, Retransmission, and Detection of Lost Associations:
4.2. 無くなっている協会のセキュリティ、Retransmission、および検出:
The media gateway control protocol is organized as a set of transactions, each of which is composed of a command and a response, commonly referred to as an acknowledgement. The MGCP messages, being carried over UDP, may be subject to losses. In the absence of a timely response, commands are repeated. MGCP entities are expected to keep in memory a list of the responses that they sent to recent transactions, i.e. a list of all the responses they sent over the last LONG-TIMER seconds, and a list of the transactions that are currently being executed.
1セットの取引(それのそれぞれがコマンドと応答で構成される)が一般的に承認を呼んだので、メディアゲートウェイ制御プロトコルは組織化されています。 UDPに伝えられるMGCPメッセージは損失を被りやすいかもしれません。 タイムリーな応答がないとき、コマンドは繰り返されます。 MGCP実体がメモリにそれらが最近の取引に送った応答のリスト、すなわち、それらが最後のLONG-TIMER秒に移動したすべての応答のリスト、および現在実行されている取引のリストを保つと予想されます。
The transaction identifiers of incoming commands are compared to the transaction identifiers of the recent responses. If a match is found, the MGCP entity does not execute the transaction, but simply repeats the response. The remaining commands will be compared to the list of current transaction. If a match is found, the MGCP entity does not execute the transaction, which is simply ignored - a response will be provided when the execution of the command is complete.
受信コマンドに関する取引識別子は最近の応答に関する取引識別子にたとえられます。 マッチが見つけられるなら、MGCP実体は、取引を実行しませんが、単に応答を繰り返します。 残っているコマンドは経常取引のリストにたとえられるでしょう。 マッチが見つけられるなら、MGCP実体は単に無視される取引を実行しません--コマンドの実行が完全であるときに、応答を提供するでしょう。
The repetition mechanism is used to guard against four types of possible errors:
反復メカニズムは4つのタイプの可能な誤りに用心するのに使用されます:
* transmission errors, when for example a packet is lost due to
noise on a line or congestion in a queue,
* 待ち行列における伝送エラー、例えばパケットがいつ線における雑音のため失われているか、そして、または混雑
* component failure, when for example an interface to a call agent
becomes unavailable,
* 例えば呼び出しエージェントへのインタフェースが入手できなくなるときのコンポーネント故障
* call agent failure, when for example an entire call agent becomes
unavailable,
* エージェント失敗、いつに電話をしなさいか、そして、例えば、全体の呼び出しエージェントは入手できなくなります。
* failover, when a new call agent is "taking over" transparently.
* 新しい呼び出しエージェントが透明に「引き継ぐ予定である」ときのフェイルオーバー。
The elements should be able to derive from the past history an estimate of the packet loss rate due to transmission errors. In a properly configured system, this loss rate should be kept very low, typically less than 1%. If a call agent or a gateway has to repeat a message more than a few times, it is very legitimate to assume that
要素は伝送エラーのため過去の歴史からパケット損失率の見積りを得るはずであることができます。 適切に構成されたシステムでは、この損失率は非常に下であるのと、通常1%未満保たれるべきです。 呼び出しエージェントかゲートウェイがかなり多くの回メッセージを繰り返さなければならないなら、それを仮定するのは非常に正統です。
Arango, et al. Informational [Page 96] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[96ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
something else than a transmission error is occurring. For example, given a loss rate of 1%, the probability that 5 consecutive transmission attempts fail is 1 in 100 billion, an event that should occur less than once every 10 days for a call agent that processes 1,000 transactions per second. (Indeed, the number of repetition that is considered excessive should be a function of the prevailing packet loss rate.) We should note that the "suspicion threshold", which we will call "Max1", is normally lower than the "disconnection threshold", which should be set to a larger value.
他の何か、伝送エラーが起こっているより。 例えば、1%の損失率を考えて、5つの連続したトランスミッション試みが失敗するという確率は1000億のうちの1です、そのそれが呼び出しエージェントのための10日間に一度1秒あたり1,000の取引を処理するほど起こるべきでない出来事。 (本当に、過度であると考えられる反復の数は行き渡っているパケット損失率の関数であるべきです。) 私たちは「通常、Max1"は、より大きい値に設定されるべきである「断線敷居」より低い」というその私たちはそうするつもりである「容疑敷居」要求に注意するべきです。
Command issued: N=0
|
transmission: N++
| +------------ retransmission: N++ -----------+
| | |
| | transmission |
| | +---to new address -+<--------------------|--+
| | | N=0 | | |
V V V | | |
+-----------+ | | |
| awaiting |- new call agent ->+ +------------+ | |
| response |--- timer elapsed --->| N > Max1 ? |-(no)+ |
+-----------+ <----------+ +------------+ ^ |
| | | | | |
| +- wrong key? -+ (yes) | |
| | | |
response received (if N=Max1, | |
| or N=Max2 | |
| check DNS) | |
v | | |
(end) +---------------+ | |
|more addresses?|(yes)|--+
+---------------+ |
| |
(no) |
| |
+------------+ |
| N > Max2 ? |(no)-+
+------------+
|
(yes)
|
v
(disconnected)
コマンドは発行しました: N=0| トランスミッション: N++| +------------ 「再-トランスミッション」: N++-----------+ | | | | | トランスミッション| | | +---新しい+を記述している<に--------------------|--+ | | | N=0| | | V V V| | | +-----------+ | | | | 待ちます。|- 新しい呼び出しエージェント->++------------+ | | | 応答|--- タイマは経過しました。--->| N>Max1?|-(いいえ)+ | +-----------+ <。----------+ +------------+ ^ | | | | | | | | +間違ったキー? -+ (はい)| | | | | | 応答は受信されました(| | | N=Max2| | | N=Max1、チェックDNSであるなら)。| | v| | | (終わり) +---------------+ | | |より多くのアドレス?、|、(はい)|--+ +---------------+ | | | (いいえ) | | | +------------+ | | N>Max2?|(いいえ)-+ +------------+ | (はい) | v(連絡を断ちます)
A classic retransmission algorithm would simply count the number of successive repetitions, and conclude that the association is broken after re-transmitting the packet an excessive number of times
古典的な再送信アルゴリズムが、単に連続した反復の数を数えて、パケットを再送した後に協会が壊れていると結論を下すだろう、過度の数の回
Arango, et al. Informational [Page 97] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[97ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
(typically between 7 and 11 times.) In order to account for the possibility of an undetected or in-progress "failover", we modify the classic algorithm as follows:
(通常7〜11回。) 非検出されたか進行中の「フェイルオーバー」の可能性を説明するために、私たちは以下の古典的なアルゴリズムを変更します:
* We request that the gateway always checks for the presence of a
new call agent. It can be noticed either by
* 私たちは、ゲートウェイが新しい呼び出しエージェントの存在がないかどうかいつもチェックするよう要求します。 それに気付くことができます。
- receiving a valid multicast message announcing a failover, or
- またはフェイルオーバーを発表する有効なマルチキャストメッセージを受け取る。
- receiving a command where the NotifiedEntity points to the new
call agent, or
- またはNotifiedEntityが新しい呼び出しエージェントを示すコマンドを受け取る。
- receiving a redirection response pointing to a new Call Agent.
- 新しいCallエージェントを示しながら、リダイレクション応答を受けます。
If a new call agent is detected, the gateway starts transmitting
outstanding commands to that new agent. Responses to commands are
still transmitted to the source address of the command.
新しい呼び出しエージェントが検出されるなら、ゲートウェイはその新しいエージェントに傑出しているコマンドを伝え始めます。 コマンドへの応答はまだコマンドのソースアドレスに伝えられています。
* we request that if the number of repetitions for this Call Agent
is larger than "Max1", that the gateway actively queries the name
server in order to detect the possible change of the call agent
interfaces.
* このCallエージェントの繰返し数が「Max1"、ゲートウェイが呼び出しエージェントの可能な変化を検出するために活発にネームサーバについて質問するのは連結する」より大きいなら、私たちがそれを要求します。
* The gateway may have learned several IP addresses for the call
agent. If the number of repetitions is larger than "Max1" and
lower than "Max2", and there are more interfaces that have not
been tried, then the gateway should direct the retransmissions to
alternate addresses.
* ゲートウェイは呼び出しエージェントのためにいくつかのIPアドレスを学んだかもしれません。 繰返し数が、より大きい、「Max1"で下側、「Max2"、試みられていないより多くのインタフェースがあって、次に、ゲートウェイが、アドレスを交替するよう「再-トランスミッション」に指示するはずである、」
* If there are no more interfaces to try, and the number of
repetitions is Max2, then the gateway contacts the DNS one more
time to see if any other interface should have become available.
If not, the gateway is now disconnected.
* 試みるそれ以上のインタフェースが全くなくて、繰返し数がMax2であるなら、ゲートウェイは、他のインタフェースが利用可能になるべきであったかどうか確認するために、より多くの1回の間、DNSに連絡します。 そうでなければ、ゲートウェイは現在、外されます。
The procedure will maximize the chances of detecting an ongoing failover. It poses indeed two very specific problems, the potentially long delays of a timer based procedure and the risk of confusion caused by the use of cryptographic protections.
手順は進行中のフェイルオーバーを検出するという可能性を最大にするでしょう。本当に、それは2つの非常に特定の問題、タイマの潜在的に長い遅れに暗号の保護の使用で引き起こされたベースの手順と混乱の危険を引き起こします。
In order to automatically adapt to network load, MGCP specifies exponentially increasing timers. If the initial timer is set to 200 milliseconds, the loss of a fifth retransmission will be detected after about 6 seconds. This is probably an acceptable waiting delay to detect a failover. The repetitions should continue after that delay not only in order to perhaps overcome a transient connectivity problem, but also in order to allow some more time for the execution of a failover - waiting a total delay of 30 seconds is probably acceptable.
自動的にネットワーク負荷に順応するために、MGCPはタイマを指数関数的に増加させながら、指定します。 初期のタイマが200ミリセカンドに設定されると、5番目の「再-トランスミッション」の損失はおよそ6秒以降、検出されるでしょう。 これはたぶんフェイルオーバーを検出するその許容できる待ち遅れです。反復が次々と続くべきである、唯一でない、フェイルオーバーの実行のためのそれ以上の時間を許容する--恐らく一時的な接続性問題を克服しなさい、ただし、30秒の待ちのa総遅れはたぶんまた許容できます。
Arango, et al. Informational [Page 98] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[98ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
It is however important that the maximum delay of retransmissions be bounded. Prior to any retransmission, it is checked that the time elapsed since the sending of the initial datagram is no greater than T- MAX. If more than T-MAX time has elapsed, the endpoint becomes disconnected. The value T-MAX is related to the LONG-TIMER value: the LONG-TIMER value is obtained by adding to T-MAX the maximum propagation delay in the network.
どんなに重要であっても、「再-トランスミッション」の最大の遅れは境界があるのが、そうです。 どんな「再-トランスミッション」の前ではも、時間が初期のデータグラムの発信がTよりMAX以下であるので経過したのがチェックされます。 T-MAX時間以上が経過したなら、終点は外されるようになります。 値のT-MAXはLONG-TIMER値に関連します: ネットワークの最大の伝播遅延をT-MAXに加えることによって、LONG-TIMER値を得ます。
Another potential cause of connection failure would be the reception of a "wrong key" message, sent by a call agent that could not authenticate the command, presumably because it had lost the security parameters of the association. Such messages are actually not authorized in IPSEC, and they should in fact not be taken at face value: an attacker could easily forge "wrong key" messages in order to precipitate the loss of a control connection. The current algorithm ignores these messages, which translates into a strict reliance on timers. The algorithm could in fact be improved, maybe by executing a check with the key server of the call agent after "Max1" repetitions.
おそらく協会のセキュリティパラメタを失ったので、接続失敗の別の潜在的原因はコマンドを認証できなかった呼び出しエージェントによって送られた「間違ったキー」メッセージのレセプションでしょう。 実際にIPSECでそのようなメッセージを認可しません、そして、事実上、それらを額面通りに取るべきではありません: 攻撃者は、コントロール接続の損失を沈殿させるために容易に「間違ったキー」メッセージを作り出すことができました。 現在のアルゴリズムはこれらのメッセージを無視します(タイマへの厳しい信用に翻訳されます)。 事実上、アルゴリズムを改良できました、多分「Max1"反復」の後に呼び出しエージェントの主要なサーバによるチェックを実行することによって。
4.3. Race conditions
4.3. 競合条件
MGCP deals with race conditions through the notion of a "quarantine list" and through explicit detection of desynchronization.
「隔離リスト」の概念を通して脱同期化の明白な検出を通してMGCPは競合条件に対処します。
MGCP does not assume that the transport mechanism will maintain the order of command and responses. This may cause race conditions, that may be obviated through a proper behavior of the call agent. (Note that some race conditions are inherent to distributed systems; they would still occur, even if the commands were transmitted in strict order.)
MGCPは、移送機構がコマンドと応答の注文を維持すると仮定しません。 これは競合条件を引き起こすかもしれなくて、呼び出しエージェントの適切な振舞いでそれを取り除くかもしれません。 (いくつかの競合条件が分散システムに固有であることに注意してください; まだ起こっているでしょう、コマンドが厳しいオーダーで伝えられたとしても。)
In some cases, many gateways may decide to restart operation at the same time. This may occur, for example, if an area loses power or transmission capability during an earthquake or an ice storm. When power and transmission are reestablished, many gateways may decide to send "RestartInProgress" commands simultaneously, leading to very unstable operation.
いくつかの場合、多くのゲートウェイが、同時に操作を再開すると決めるかもしれません。 例えば、領域が地震か着氷性悪天の間、パワーかトランスミッション能力を失うなら、これは起こるかもしれません。 パワーとトランスミッションが回復するとき、非常に不安定な操作に通じて、多くのゲートウェイが、同時に「RestartInProgress」コマンドを送ると決めるかもしれません。
4.3.1. Quarantine list
4.3.1. 隔離リスト
MGCP controlled gateways will receive "notification requests" that ask them to watch for a list of "events." The protocol elements that determine the handling of these events are the "Requested Events" list, the "Digit Map" and the "Detect Events" list.
制御ゲートウェイが望んでいるMGCPは「出来事」のリストに注意するように彼らに頼む「通知要求」を受けます。 これらの出来事の取り扱いを決定するプロトコル要素は、「要求された出来事」リストと、「ケタ地図」と「出来事を検出してください」というリストです。
Arango, et al. Informational [Page 99] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[99ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
When the endpoint is initialized, the requested events list and the digit map are empty. After reception of a command, the gateway starts observing the endpoint for occurrences of the events mentioned in the list.
終点が初期化されるとき、要求されたイベントリストとケタ地図は空です。 コマンドのレセプションの後に、ゲートウェイはリストで言及された出来事の発生に関して終点を観測し始めます。
The events are examined as they occur. The action that follows is determined by the "action" parameter associated to the event in the list of requested events, and also by the digit map. The events that are defined as "accumulate" or "treat according to digit map" are accumulated in a list of events, the events that are marked as "treated according to the digit map" will additionally be accumulated in the dialed string. This will go on until one event is encountered that triggers a Notification to the "notified entity."
起こるとき、出来事は調べられます。 続く動作は要求された出来事のリストにおける出来事に関連づけられた「動作」パラメタ、およびケタ地図でも決定します。 「蓄積する」か、または「ケタ地図によると、扱う」とき、定義される出来事は出来事のリストに蓄積されて、「ケタ地図によると、扱われる」ように著しい出来事はダイヤルされたストリングにさらに、蓄積されるでしょう。 「通知された実体」にNotificationの引き金となる1回の出来事が遭遇するまで、これは先へ進むでしょう。
The gateway, at this point, will transmit the notification command and will place the endpoint in a "notification" state. As long as the endpoint is in this notification state, the events that are to be detected on the endpoint are stored in a "quarantine" buffer for later processing. The events are, in a sense, "quarantined." All events that are specified by the union of the RequestedEvents parameter and the most recently received DetectEvent parameter or, in the absence of the latter, all events that are referred to in the RequestedEvents, should be detected and quarantined, regardless of the action associated to the event.
ゲートウェイは、ここに通知命令を送って、「通知」状態に終点を置くでしょう。 終点がこの通知状態にある限り、終点に検出されることになっている出来事は後で処理するための「隔離」バッファに格納されます。 出来事はある意味で「検疫されます」。 RequestedEventsパラメタと大部分の組合によって指定されるすべての出来事が最近、DetectEventパラメタを受け取ったか、すべての出来事が、後者がないときRequestedEventsで言及されて、検出されて、検疫されるべきです、出来事に関連づけられた動作にかかわらず。
The endpoint exits the "notification state" when the acknowledgement of the Notify command is received. The Notify command may be retransmitted in the "notification state", as specified in section 3.5. When the endpoint exits the "notification state" it resets the list of observed events and the "current dial string" of the endpoint to a null value.
Notifyコマンドの承認が受け取られているとき、終点は「通知状態」を出ます。 Notifyコマンドはセクション3.5で指定されるように「通知状態」で再送されるかもしれません。 終点が「通知状態」を出るとき、それは観測された出来事のリストと終点の「現在のダイヤルストリング」をヌル値にリセットします。
Following that point, the behavior of the gateway depends on the value of The QuarantineHandling parameter in the notification request. If the Call Agent specified that it expected at most one notification in response to the notification request command, then the gateway should simply keep on accumulating events in the quarantine list until it receives the next notification request command.
そのポイントに従って、ゲートウェイの動きは通知要求における、QuarantineHandlingパラメタの値に依存します。 Callエージェントが、最も1つで通知要求命令に対応して通知を予想したと指定するなら、ゲートウェイは、次の通知要求命令を受け取るまで単に隔離リストにおける出来事を蓄積し続けるでしょうに。
If the gateway is authorized to send multiple successive Notify commands, it will proceed as follows. When the gateway exits the "notification state", it resets the list of observed events and the "current dial string" of the endpoint to a null value and starts processing the list of quarantined events, using the already received list of requested events and digit map. When processing these events,
ゲートウェイが複数の連続したNotifyコマンドを送るのが認可されると、それは以下の通り続くでしょう。 ゲートウェイが「通知状態」を出るとき、観測された出来事のリストと終点の「現在のダイヤルストリング」をヌル値にリセットして、検疫している出来事のリストを処理し始めます、要求された出来事とケタ地図の既に受信されたリストを使用して。 これらの出来事を処理するとき
Arango, et al. Informational [Page 100] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[100ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
the gateway may encounter an event which requires a Notify command to be sent. If that is the case, the gateway can adopt one of the two following behaviors:
ゲートウェイは送られるべきNotifyコマンドを必要とする出来事に遭遇するかもしれません。 それがそうであるなら、振舞いに続いて、ゲートウェイは2つのものの1つを採用できます:
* it can immediately transmit a Notify command that will report all
events that were accumulated in the list of observed events until
the triggering event, included, leaving the unprocessed events in
the quarantine list,
* それはすぐに隔離リストにおける未加工の出来事を残して、観測された出来事のリストに含まれていた引き金となる出来事まで蓄積されたすべての出来事を報告するNotifyコマンドを伝えることができます。
* or it can attempt to empty the quarantined list and transmit a
single Notify command reporting several sets of events and
possibly several dial strings. The dial string is reset to a null
value after each triggering event. The events that follow the last
triggering event are left in the quarantine list.
* または、それは、検疫しているリストを空にして、数セットの出来事を報告するただ一つのNotifyコマンドとことによると数個のダイヤルストリングを伝えるのを試みることができます。 ダイヤルストリングは各引き金となる出来事の後にヌル値にリセットされます。 最後の引き金となる出来事に続いて起こる出来事は隔離リストに残されます。
If the gateway transmits a Notify command, the end point will remain in the "notification state" until the acknowledgement is received. If the gateway does not find a quarantined event that requests a Notify command, it places the end point in a normal state. Events are then processed as they come, in exactly the same way as if a Notification Request command had just been received.
ゲートウェイがNotifyコマンドを伝えると、承認が受け取られているまで、エンドポイントは「通知状態」に残るでしょう。 ゲートウェイがNotifyコマンドを要求する検疫している出来事に当たらないなら、それは正常な状態にエンドポイントを置きます。 来ます、まさに同じように次に、処理されているのに出来事はまるでちょうどNotification Requestコマンドを受け取ったかのようにそうです。
A gateway may receive at any time a new Notification Request command for the end point. When a new notification request is received in the notification state, the gateway shall ensure that the pending notification is received by the Call Agent prior to a successful response to the new NotificationRequest. It does so by using the "piggy-backing" functionality of the protocol. The messages will then be sent in a single packetto the source of the new NotificationRequest, regardless of respectively the source and "notified entity" for the old and new command. The steps involved are the following:
ゲートウェイはいつでも、エンドポイントのための新しいNotification Requestコマンドを受け取るかもしれません。 通知状態に新しい通知要求を受け取るとき、ゲートウェイは、未定の通知が新しいNotificationRequestへのうまくいっている応答の前にCallエージェントによって受け取られるのを確実にするものとします。 それは、プロトコルの「便乗」の機能性を使用することによって、そうします。 次に、新しいNotificationRequestの源の単一のpackettoでメッセージを送るでしょう、古くて新しいコマンドのためのそれぞれソースと「通知された実体」にかかわらず。 かかわったステップは以下です:
a) the gateway builds a message that carries in a single packet a
repetition of the old pending Notify command and the
acknowledgement of the new notification request.
a) ゲートウェイは単一のパケットで古い未定のNotifyコマンドの反復と新しい通知要求の承認を運ぶメッセージを築き上げます。
b) the endpoint is then taken out of the "notification state" without
waiting for the acknowledgement of the notification command.
b) そして、通知命令の承認を待たないで、終点は「通知状態」から取り出されます。
c) a copy of the unacknowledged Notify command command is kept until
an acknowledgement is received. If a timer elapses, the
notification will be repeated, in a packet that will also carry a
repetition of the acknowledgement of the notification request.
c) 承認が受け取られているまで、不承認のNotifyコマンド命令の写しは取っておかれます。 タイマが経過すると、通知は繰り返されるでしょう、また、通知要求の承認の反復を運ぶパケットで。
Arango, et al. Informational [Page 101] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[101ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
d) if the acknowledgement is lost, the Call Agent will retransmit the
Notification Request. The gateway will reply to this repetition
by retransmitting in a single packet the unacknowledged Notify and
the acknowledgement of the notification request.
d) 承認が無くなると、CallエージェントはNotification Requestを再送するでしょう。 ゲートウェイは、単一のパケットで不承認のNotifyと通知要求の承認を再送することによって、この反復に答えるでしょう。
e) if the gateway has to transmit a Notify before the previous Notify
is acknowledged, it should construct a packet that piggybacks a
repetition of the old Notify, a repetition of the acknowledgement
of the last notification request and the new Notify.
前のNotifyが承認される前にe)はゲートウェイであるならNotifyを伝えなければならなくて、それは古いNotifyの反復、最後の通知要求の承認の反復、および新しいNotifyを背負うパケットを組み立てるべきです。
f) Gateways that cannot piggyback several packets in the same message
should elect to leave the endpoint in the "notification" state as
long as the last notification is not acknowledged.
f) 同じメッセージのいくつかのパケットを背負うことができないゲートウェイは、最後の通知が承諾されない限り、「通知」状態で終点を出るのを選ぶはずです。
After receiving the Notification Request command, the requested events list and digit map (if a new one was provided) are replaced by the newly received parameters, and the list of observed events and accumulated dial string are reset to a null value. The behavior is conditioned by the value of the QuarantineHandling parameter. The parameter may specify that quarantined events, or previously observed events, should be discarded, in which case they will be. If the parameter specifies that the quarantined events should be processed, the gateway will start processing the list of quarantined events or previously observed events, using the newly received list of requested events and digit map. When processing these events, the gateway may encounter an event which requires a Notify command to be sent. If that is the case, the gateway will immediately transmit a Notify command that will report all events that were accumulated in the list of observed events until the triggering event, included, leaving the unprocessed events in the quarantine buffer, and will enter the "notification state".
Notification Requestコマンドを受け取った後に、要求されたイベントリストとケタ地図(新しいものを提供したなら)を新たに受け取られたパラメタに取り替えます、そして、観測された出来事のリストと蓄積されたダイヤルストリングをヌル値にリセットします。 振舞いはQuarantineHandlingパラメタの値で条件とします。 パラメタは、検疫している出来事、または以前に観測された出来事がどの場合になるかに捨てられるべきであると指定するかもしれません。 パラメタが、検疫している出来事が処理されるべきであると指定すると、ゲートウェイは検疫している出来事か以前に観測された出来事のリストを処理し始めるでしょう、要求された出来事とケタ地図の新たに受け取られたリストを使用して。 これらの出来事を処理するとき、ゲートウェイは送られるべきNotifyコマンドを必要とする出来事に遭遇するかもしれません。 それがそうであるなら、ゲートウェイはすぐに、隔離における未加工の出来事を残す含まれていた引き金となる出来事が「通知状態」にバッファリングして、入るまで観測された出来事のリストに蓄積されたすべての出来事を報告するNotifyコマンドを伝えるでしょう。
A new notification request may be received while the gateway has accumulated events according to the previous notification requests, but has not yet detected a notification-triggering events. The handling of not-yet-notified events is determined, as with the quarantined events, by the quarantine handling parameters:
新しい通知要求は、前の通知要求に従ってゲートウェイが出来事を蓄積している間受け取るかもしれませんが、まだ通知引き金となる出来事を検出していません。 まだ通知されなかった出来事の取り扱いは隔離取り扱いパラメタによる検疫している出来事のように決定しています:
* If the quarantine-handling parameter specifies that quarantined
events shall be ignored, the observed event list is simply reset.
* 隔離取り扱いパラメタが、検疫している出来事が無視されると指定するなら、観測されたイベントリストは単にリセットされます。
* If the quarantine-handling parameter specifies that quarantined
events shall be processed, the observed event list is transferred
to the quarantined event list. The observed event list is then
reset, and the quarantined event list is processed.
* 隔離取り扱いパラメタが、検疫している出来事が処理されると指定するなら、観測されたイベントリストを検疫しているイベントリストに移します。 次に、観測されたイベントリストはリセットされます、そして、検疫しているイベントリストは処理されます。
Arango, et al. Informational [Page 102] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[102ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Call Agents SHOULD provide the response to a successful Notify message and the new NotificationRequest in the same datagram using the piggy-backing mechanism.
呼び出しエージェントSHOULDは、便乗メカニズムを使用することでうまくいっているNotifyメッセージと新しいNotificationRequestへの応答を同じデータグラムに供給します。
4.3.2. Explicit detection
4.3.2. 明白な検出
A key element of the state of several endpoints is the position of the hook. A race condition may occur when the user decides to go off-hook before the Call Agent has the time to ask the gateway to notify an off hook event (the "glare" condition well known in telephony), or if the user goes on-hook before the Call Agent has the time to request the event's notification.
いくつかの終点の状態の主要な要素はフックの位置です。 ユーザが、Callエージェントにオフフック出来事(電話でよく知られている「ギラギラと眩しい光」状態)に通知するようにゲートウェイに頼む時間がある前かCallエージェントに出来事の通知を要求する時間がある前にフックに行くこと場合フックに行くと決めると、競合条件は起こるかもしれません。
To avoid this race condition, the gateway should check the condition of the endpoint before acknowledging a NotificationRequest. It should return an error:
この競合条件を避けるために、NotificationRequestを承認する前に、ゲートウェイは終点の状態をチェックするはずです。 それは誤りを返すべきです:
1- If the gateway is requested to notify an "off hook" transition
while the phone is already off hook,
ゲートウェイであるなら、電話がフックに既にある間、1が「オフフック」変遷に通知するよう要求されます。
2- If the gateway is requested to notify an "on hook" or "flash hook"
condition while the phone is already on hook.
電話が既にオンである間、ゲートウェイが「フック」か「フラッシュフック」状態に通知するよう要求されるなら、2は掛けられます。
It should be noted, that the condition check is performed at the time the notification request is received, where as the actual event that caused the current condition may have either been reported, or ignored earlier, or it may currently be quarantined.
それは注意されるべきですか、通知要求が受信されているときそれが現実の出来事として現在の状態を引き起こしたところで状態点検が実行されるのが、報告されたか、より早く無視されたかもしれません、またはそれが現在、検疫されるかもしれません。
The other state variables of the gateway, such as the list of RequestedEvent or list of requested signals, are entirely replaced after each successful NotificationRequest, which prevents any long term discrepancy between the Call Agent and the gateway.
それぞれのうまくいっているNotificationRequestの後にゲートウェイのRequestedEventのリストか要求された信号のリストなどの他の州の変数を完全に取り替えます。NotificationRequestはCallエージェントとゲートウェイの間のどんな長期食い違いも防ぎます。
When a NotificationRequest is unsuccessful, whether it is included in a connection-handling command or not, the gateway will simply continue as if the command had never been received. As all other transactions, the NotificationRequest should operate as an atomic transaction, thus any changes initiated as a result of the command should be reverted.
それが接続取り扱い命令に含まれているか否かに関係なく、NotificationRequestが失敗しているとき、ゲートウェイはまるでコマンドを一度も受け取ったことがなかったかのように単に続くでしょう。 他のすべての取引として、NotificationRequestは原子取引として作動するはずです、その結果、コマンドの結果、起こされたどんな変化も振り向けられるべきです。
Another race condition may occur when a Notify is issued shortly before the reception by the gateway of a NotificationRequest. The RequestIdentifier is used to correlate Notify commands with NotificationRequest commands.
Notifyがレセプションのすぐ前にNotificationRequestのゲートウェイによって発行されるとき、別の競合条件は起こるかもしれません。 RequestIdentifierは、NotificationRequestコマンドでNotifyコマンドを関連させるのに使用されます。
Arango, et al. Informational [Page 103] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[103ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
4.3.3. Ordering of commands, and treatment of disorder
4.3.3. コマンドの注文、および混乱の処理
MGCP does not mandate that the underlying transport protocol guarantees the sequencing of commands sent to a gateway or an endpoint. This property tends to maximize the timeliness of actions, but it has a few draw backs. For example:
MGCPは、基本的なトランスポート・プロトコルがゲートウェイか終点に送られたコマンドの配列を保証するのを強制しません。 この特性は、動作のタイムリーさであるのを最大にする傾向がありますが、それには、いくつかのドロー後部があります。 例えば:
* Notify commands may be delayed and arrive to the call agent after
the transmission of a new Notification Request command,
* 通知コマンドは、新しいNotification Requestコマンドの送信の後に呼び出しエージェントに遅れて、到着するかもしれません。
* If a new NotificationRequest is transmitted before a previous one
is acknowledged, there is no guarantee that the previous one will
not be received in second position.
* 前の1つが承認される前に新しいNotificationRequestが伝えられるなら、前のものが2番目の位置に受け取られないという保証が全くありません。
Call Agents that want to guarantee consistent operation of the end points can use the following rules:
エンドポイントの一貫した操作が以下の規則を使用できるのを保証したがっているエージェントに電話をしてください:
1) When a gateway handles several endpoints, commands pertaining to
the different endpoints can be sent in parallel, for example
following a model where each endpoint is controlled by its own
process or its own thread.
1) ゲートウェイがいくつかの終点を扱うとき、異なった終点に関係するコマンドは平行に送ることができます、例えば、各終点がそれ自身の過程かそれ自身の糸によって制御されるモデルに従って。
2) When several connections are created on the same endpoint,
commands pertaining to different connections can be sent in
parallel.
2) 同じ終点でいくつかの接続を創造するとき、異なった接続に関係するコマンドは平行に送ることができます。
3) On a given connection, there should normally be only one
outstanding command (create or modify). However, a
DeleteConnection command can be issued at any time. In
consequence, a gateway may sometimes receive a ModifyConnection
command that applies to a previously deleted connection. Such
commands should be ignored, and an error code should be returned.
3) 与えられた接続には、通常、1つの傑出しているコマンド(作成するか、または変更する)しかあるはずがありません。 しかしながら、いつでも、DeleteConnectionコマンドを発行できます。 その結果、ゲートウェイは時々以前に削除された接続に適用されるModifyConnectionコマンドを受け取るかもしれません。 そのようなコマンドは無視されるべきです、そして、エラーコードは返されるべきです。
4) On a given endpoint, there should normally be only one outstanding
NotificationRequest command at any time. The RequestId parameter
should be used to correlate Notify commands with the triggering
notification request.
4) 与えられた終点に、通常、1つの傑出しているNotificationRequestコマンドしかいつでもあるはずがありません。 RequestIdパラメタは引き金となる通知によるNotifyコマンドが要求する相関物に使用されるべきです。
5) In some cases, an implicitly or explicitly wildcarded
DeleteConnection command that applies to a group of endpoints can
step in front of a pending CreateConnection command. The Call
Agent should individually delete all connections whose completion
was pending at the time of the global DeleteConnection command.
Also, new CreateConnection commands for endpoints named by the
wild-carding cannot be sent until the wild-carded DeleteConnection
command is acknowledged.
5) いくつかの場合で踏む、それとなくか明らかに、終点のグループに適用されるwildcarded DeleteConnectionコマンドは未定のCreateConnectionコマンドの正面で踏まれることができます。 Callエージェントは個別に、完成がグローバルなDeleteConnectionコマンド時点で未定であったすべての接続を削除するべきです。 また、ワイルドなcarded DeleteConnectionコマンドが承諾されるまで、ワイルドな梳綿機によって指定された終点のための新しいCreateConnectionコマンドを送ることができません。
Arango, et al. Informational [Page 104] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[104ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
6) When commands are embedded within each other, sequencing
requirements for all commands must be adhered to. For example a
Create Connection command with a Notification Request in it must
adhere to the sequencing for CreateConnection and
NotificationRequest at the same time.
6) コマンドが互いの中で埋め込まれているとき、すべてのコマンドのための配列要件を固く守らなければなりません。 例えば、Notification RequestがそれにあるCreate Connectionコマンドは同時に、CreateConnectionとNotificationRequestのための配列を固く守らなければなりません。
7) AuditEndpoint and AuditConnection is not subject to any
sequencing.
7) AuditEndpointとAuditConnectionはどんな配列も受けることがありません。
8) RestartInProgress must always be the first command sent by an
endpoint as defined by the restart procedure. Any other command or
response must be delivered after this RestartInProgress command
(piggy-backing allowed).
8) いつもRestartInProgressは再開手順で定義されるように終点によって送られた最初のコマンドであるに違いありません。 このRestartInProgressが命令した(許容されて、便乗して)後にいかなる他のコマンドか応答も提供しなければなりません。
9) When multiple messages are piggy-backed in a single packet, the
messages are always processed in order.
9) 複数のメッセージが単一のパケットで背負われるとき、メッセージはいつも整然とした状態で処理されます。
These rules do not affect the gateway, which should always respond to commands.
これらの規則はゲートウェイに影響しません。(それは、いつもコマンドに応じるはずです)。
4.3.4. Fighting the restart avalanche
4.3.4. 再開殺到と戦います。
Let's suppose that a large number of gateways are powered on simultaneously. If they were to all initiate a RestartInProgress transaction, the call agent would very likely be swamped, leading to message losses and network congestion during the critical period of service restoration. In order to prevent such avalanches, the following behavior is suggested:
多くのゲートウェイが同時に電源を入れられていると思いましょう。 彼らが皆、RestartInProgressトランザクションを開始するなら、呼び出しエージェントはたぶん殺到されるでしょうに、サービス復旧の要継続期間の間、メッセージの損失とネットワークの混雑に通じて。 そのような殺到を防ぐために、以下の振舞いは示されます:
1) When a gateway is powered on, it should initiate a restart timer
to a random value, uniformly distributed between 0 and a maximum
waiting delay (MWD). Care should be taken to avoid synchronicity
of the random number generation between multiple gateways that
would use the same algorithm.
1) ゲートウェイが電源を入れられているとき、それは一様に0最大の待ち遅れ(MWD)の間に分配された無作為の値に再開タイマを開始するべきです。 同じアルゴリズムを使用する複数のゲートウェイの間の乱数発生の共時性を避けるために注意するべきです。
2) The gateway should then wait for either the end of this timer, the
reception of a command from the call agent, or the detection of a
local user activity, such as for example an off-hook transition on
a residential gateway.
2) 次に、ゲートウェイはこのタイマの端、呼び出しエージェントからのコマンドのレセプションか地方のユーザ活動の検出のどちらかを待つはずです、例えば、住宅のゲートウェイにおけるオフフック変遷のように。
3) When the timer elapses, when a command is received, or when an
activity is detected, the gateway should initiate the restart
procedure.
3) コマンドが受け取られているとき、タイマが経過するか、または活動が検出されるとき、ゲートウェイは再開手順に着手するはずです。
Arango, et al. Informational [Page 105] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[105ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
The restart procedure simply requires the endpoint to guarantee that the first message (command or response) that the Call Agent sees from this endpoint is a RestartInProgress message informing the Call Agent about the restart. The endpoint is free to take full advantage of piggy-backing to achieve this.
再開手順は、Callエージェントがこの終点から見る最初のメッセージ(コマンドか応答)が再開に関してCallエージェントに知らせるRestartInProgressメッセージであることを保証するために単に終点を必要とします。 終点は、これを達成するのに自由に便乗を最大限に利用できます。
It is expected that each endpoint in a gateway will have a provisionable Call Agent, i.e., "notified entity", to direct the initial restart message towards. When the collection of endpoints in a gateway is managed by more than one Call Agent, the above procedure must be performed for each collection of endpoints managed by a given Call Agent. The gateway MUST take full advantage of wild-carding to minimize the number of RestartInProgress messages generated when multiple endpoints in a gateway restart and the endpoints are managed by the same Call Agent.
再開が通信するイニシャルを指示するためにゲートウェイの各終点にはすなわち、provisionable Callエージェント、「通知された実体」があると予想されます。 ゲートウェイでの終点の収集が1人以上のCallエージェントによって管理されるとき、与えられたCallエージェントによって管理された終点の各収集のために上の手順を実行しなければなりません。 ゲートウェイはゲートウェイ再開における複数の終点と終点が同じCallエージェントによって管理されるとき生成されたRestartInProgressの数を最小にするためにはワイルドな梳綿機メッセージを最大限に利用しなければなりません。
The value of MWD is a configuration parameter that depends on the type of the gateway. The following ]reasoning can be used to determine the value of this delay on residential gateways.
MWDの値はゲートウェイのタイプに頼る設定パラメータです。 以下] 住宅のゲートウェイの上でこの遅れの値を決定するのに推理を使用できます。
Call agents are typically dimensioned to handle the peak hour traffic load, during which, in average, 10% of the lines will be busy, placing calls whose average duration is typically 3 minutes. The processing of a call typically involves 5 to 6 MGCP transactions between each end point and the call agent. This simple calculation shows that the call agent is expected to handle 5 to 6 transactions for each end point, every 30 minutes on average, or, to put it otherwise, about one transaction per end point every 5 to 6 minutes on average. This suggest that a reasonable value of MWD for a residential gateway would be 10 to 12 minutes. In the absence of explicit configuration, residential gateways should adopt a value of 600 seconds for MWD.
呼び出しエージェントは平均における、系列の10%が忙しくなるピーク時トラヒック負荷を扱うために通常dimensionedされます、通常、平均した持続時間が3分である電話をして。 呼び出しの処理は各エンドポイントと呼び出しエージェントの間の5〜6つのMGCPトランザクションに通常かかわります。 この簡単な計算は、そうでなければ、それを置くためにまたは、呼び出しエージェントが各エンドポイント、30分毎の5〜6つのトランザクションを平均的に扱うと予想されるのを示します、5〜6分毎の平均でのエンドポイントあたりおよそ1つのトランザクション。 これは、住宅のゲートウェイへのMWDの適正価値が10〜12分であると示唆します。 明白な構成がないとき、住宅のゲートウェイはMWDのために600秒の値を採用するはずです。
The same reasoning suggests that the value of MWD should be much shorter for trunking gateways or for business gateways, because they handle a large number of endpoints, and also because the usage rate of these endpoints is much higher than 10% during the peak busy hour, a typical value being 60%. These endpoints, during the peak hour, are this expected to contribute about one transaction per minute to the call agent load. A reasonable algorithm is to make the value of MWD per "trunk" endpoint six times shorter than the MWD per residential gateway, and also inversely proportional to the number of endpoints that are being restarted. for example MWD should be set to 2.5 seconds for a gateway that handles a T1 line, or to 60 milliseconds for a gateway that handles a T3 line.
同じ推理は、中継方式ゲートウェイかビジネスゲートウェイには、MWDの値がはるかに短いはずであると示唆します、多くの終点を扱って、これらの終点の使用率もピークの間の10%が時間と忙しくするよりはるかにまた、高いので、典型的な値が60%であり。 ピーク時の間、これらの終点は1分あたりおよそ1つのトランザクションを呼び出しエージェント負荷に寄付すると予想されたこれです。 合理的なアルゴリズムは「トランク」終点sixあたりのMWDの値をMWDより何倍も少なく住宅の門あたり、また、逆に再開されている終点の数に変化するようにすることです。例えばMWDはT1系列を扱うゲートウェイへの2.5秒、または、T3系列を扱うゲートウェイへの60ミリセカンドに用意ができるべきです。
Arango, et al. Informational [Page 106] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[106ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
4.3.5. Disconnected Endpoints
4.3.5. 終点であると切断されます。
In addition to the restart procedure, gateways also have a "disconnected" procedure, which is initiated when an endpoint becomes "disconnected" as described in Section 3.4.2. It should here be noted, that endpoints can only become disconnected when they attempt to communicate with the Call Agent. The following steps are followed by an endpoint that becomes "disconnected":
また、再開手順に加えて、ゲートウェイには、「切断している」手順があります。(終点がセクション3.4.2で説明されるように「切断される」ようになるとき、それは、着手されます)。 それはここでなるべきです。注意されてください、そして、Callエージェントとコミュニケートするのを試みるときだけ、その終点は切断されるようになることができます。 「切断される」ようになる終点は以下の方法のあとに続いています:
1. A "disconnected" timer is initialized to a random value, uniformly
distributed between 0 and a provisionable "disconnected" initial
waiting delay (Tdinit), e.g., 15 seconds. Care MUST be taken to
avoid synchronicity of the random number generation between
multiple gateways and endpoints that would use the same algorithm.
1. 「切断している」タイマは一様に0初期の待ち遅れ(Tdinit)であると「切断された」支給可能の間に分配された無作為の値に初期化されます、例えば、15秒。 同じアルゴリズムを使用する複数のゲートウェイと終点の間の乱数発生の共時性を避けるために注意しなければなりません。
2. The gateway then waits for either the end of this timer, the
reception of a command from the call agent, or the detection of a
local user activity for the endpoint, such as for example an off-
hook transition.
2. そしてゲートウェイはこのタイマの端、呼び出しエージェントからのコマンドのレセプションか終点のための地方のユーザ活動の検出のどちらかを待っています、例えば、オフフック変遷のように。
3. When the "disconnected" timer elapses, when a command is received,
or when a local user activity is detected, the gateway initiates
the "disconnected" procedure for the endpoint. In the case of
local user activity, a provisionable "disconnected" minimum
waiting delay (Tdmin) must furthermore have elapsed since the
gateway became disconnected or the last time it initiated the
"disconnected" procedure in order to limit the rate at which the
procedure is performed.
3. コマンドが受け取られているとき、「切断している」タイマが経過するか、または終点への地方のユーザ活動が検出されて、ゲートウェイ開始が「切断する」であるという手順であるときに。 地方のユーザ活動の場合では、その上、ゲートウェイが切断されるようになったか、または前回手順が実行される速度を制限するために「切断している」手順に着手したとき、最小の待ち遅れ(Tdmin)であると「切断された」支給可能は経過したに違いありません。
4. If the "disconnected" procedure still left the endpoint
disconnected, the "disconnected" timer is then doubled, subject to
a provisionable "disconnected" maximum waiting delay (Tdmax),
e.g., 600 seconds, and the gateway proceeds with step 2 again.
4. 「切断している」手順がまだ終点を切断されたままにしていたなら、「切断している」タイマは最大の待ち遅れであると(Tdmax)、例えば、600秒「切断された」支給可能を条件として倍にされます、そして、ゲートウェイは再びステップ2を続けます。
The "disconnected" procedure is similar to the restart procedure in that it now simply states that the endpoint MUST send a RestartInProgress command to the Call Agent informing it that the endpoint was disconnected and furthermore guarantee that the first message (command or response) that the Call Agent now sees from this endpoint MUST be this RestartInProgress command. The endpoint MUST take full advantage of piggy-backing in achieving this. The Call Agent may then for instance decide to audit the endpoint, or simply clear all connections for the endpoint.
「切断している」手順は現在終点が、終点切断されたことをそれに知らせるCallエージェントにRestartInProgressコマンドを送って、その上、Callエージェントが今この終点から見る最初のメッセージ(コマンドか応答)がこのRestartInProgressコマンドであるに違いないことを保証しなければならないと単に述べるという点において再開手順と同様です。 終点はこれを達成する際に便乗を最大限に利用しなければなりません。 Callエージェントは、次に、例えば、終点を監査すると決めるか、または単に終点のためのすべての接続をきれいにするかもしれません。
This specification purposely does not specify any additional behavior for a disconnected endpoint. Vendors MAY for instance choose to provide silence, play reorder tone, or even enable a downloaded wav file to be played.
この仕様はわざわざ切断している終点のための少しの追加振舞いも指定しません。 例えば、ベンダーは、沈黙を供給するか、追加注文トーンをプレーするか、またはダウンロードされたwavファイルが使われるのを可能にするのさえ選ぶかもしれません。
Arango, et al. Informational [Page 107] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[107ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
The default value for Tdinit is 15 seconds, the default value for Tdmin, is 15 seconds, and the default value for Tdmax is 600 seconds.
Tdinitのためのデフォルト値は15秒(Tdminのためのデフォルト値)が15秒であり、Tdmaxのためのデフォルト値が600秒であるということです。
5. Security requirements
5. セキュリティ要件
If unauthorized entities could use the MGCP, they would be able to set-up unauthorized calls, or to interfere with authorized calls. We expect that MGCP messages will always be carried over secure Internet connections, as defined in the IP security architecture as defined in RFC 2401, using either the IP Authentication Header, defined in RFC 2402, or the IP Encapsulating Security Payload, defined in RFC 2406. The complete MGCP protocol stack would thus include the following layers:
権限のない実体がMGCPを使用できるなら、それらは、権限のない呼び出しをセットアップするか、または認可された呼び出しを妨げることができるでしょうに。 私たちは、MGCPメッセージがいつも安全なインターネット接続に伝えられると予想します、RFC2401で定義されるセキュリティー体系、RFC2402で定義されたIP Authentication Headerを使用するか、またはIP Encapsulating Security有効搭載量がRFC2406で定義したIPで定義されるように。 その結果、完全なMGCPプロトコル・スタックは以下の層を含んでいるでしょう:
________________________________
| MGCP |
|_______________________________|
| UDP |
|_______________________________|
| IP security |
| (authentication or encryption)|
|_______________________________|
| IP |
|_______________________________|
| transmission media |
|_______________________________|
________________________________ | MGCP| |_______________________________| | UDP| |_______________________________| | IPセキュリティ| | (認証か暗号化)| |_______________________________| | IP| |_______________________________| | トランスミッションメディア| |_______________________________|
Adequate protection of the connections will be achieved if the gateways and the Call Agents only accept messages for which IP security provided an authentication service. An encryption service will provide additional protection against eavesdropping, thus forbidding third parties from monitoring the connections set up by a given endpoint
ゲートウェイとCallエージェントがIPセキュリティが認証サービスを提供したメッセージを受け入れるだけであると、接続の適切な保護は達成されるでしょう。 暗号化サービスは盗聴に対する追加保護を提供するでしょう、その結果、接続をモニターするのからの険しい第三者が与えられた終点のそばでセットアップします。
The encryption service will also be requested if the session descriptions are used to carry session keys, as defined in SDP.
また、セッション記述がセッションキーを運ぶのに使用されると、暗号化サービスは要求されるでしょう、SDPで定義されるように。
These procedures do not necessarily protect against denial of service attacks by misbehaving gateways or misbehaving call agents. However, they will provide an identification of these misbehaving entities, which should then be deprived of their authorization through maintenance procedures.
これらの手順は必ずふらちな事をするのによるサービス攻撃の否定に対してゲートウェイかふらちな事をしている呼び出しエージェントを保護するというわけではありません。 しかしながら、彼らはこれらのふらちな事する実体の識別を提供するでしょう。(次に、実体は保守手順でそれらの承認を奪われるべきです)。
Arango, et al. Informational [Page 108] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[108ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
5.1. Protection of media connections
5.1. メディア接続の保護
MGCP allows call agent to provide gateways with "session keys" that can be used to encrypt the audio messages, protecting against eavesdropping.
MGCPは呼び出しエージェントにオーディオメッセージを暗号化するのに使用できる「セッションキー」をゲートウェイに提供させます、盗聴から守って。
A specific problem of packet networks is "uncontrolled barge-in." This attack can be performed by directing media packets to the IP address and UDP port used by a connection. If no protection is implemented, the packets will be decompressed and the signals will be played on the "line side".
パケット網の特定の問題は「中では、はしけで運びます非制御の」です。 接続によって使用されたIPアドレスとUDPポートにメディア向けの資料セットを向けることによって、この攻撃を実行できます。 ノー・プロテクションが実装されると、パケットは減圧されるでしょう、そして、信号は「系列側」で使われるでしょう。
A basic protection against this attack is to only accept packets from known sources, checking for example that the IP source address and UDP source port match the values announced in the "remote session description." But this has two inconveniences: it slows down connection establishment and it can be fooled by source spoofing:
この攻撃に対する基本的な保護は知られているソースからパケットを受け入れるだけであることです、例えば、IPソースアドレスとUDPソースポートが「リモートセッション記述」で発表された値に合っているのをチェックして。 しかし、これには、2つの不便があります: それはコネクション確立を減速させます、そして、ソーススプーフィングでだますことができます:
* To enable the address-based protection, the call agent must obtain
the remote session description of the e-gress gateway and pass it
to the in-gress gateway. This requires at least one network round
trip, and leaves us with a dilemma: either allow the call to
proceed without waiting for the round trip to complete, and risk
for example "clipping" a remote announcement, or wait for the full
round trip and settle for slower call-set-up procedures.
* 呼び出しエージェントは、アドレスベースの保護を可能にするために、電子gressゲートウェイのリモートセッション記述を得て、イングレスゲートウェイにそれを通過しなければなりません。 これは、旅行の周りで少なくとも1つのネットワークを必要として、私たちにジレンマを残します: 周遊旅行が完了する待ち、および危険なしで続くという例えばリモート発表を「切り取る」要求を許すか、完全な周遊旅行を待ってください、そして、または、より遅い呼び出し設定の手順を受け入れてください。
* Source spoofing is only effective if the attacker can obtain valid
pairs of source destination addresses and ports, for example by
listening to a fraction of the traffic. To fight source spoofing,
one could try to control all access points to the network. But
this is in practice very hard to achieve.
* 攻撃者が有効な組のソース送付先アドレスとポートを入手できる場合にだけ、ソーススプーフィングは有効です、例えば、トラフィックの部分を聞くことによって。 ソーススプーフィングと戦うために、ものはすべてのアクセスポイントをネットワークに制御しようとするかもしれません。 しかし、これは実際には非常に達成しにくいあります。
An alternative to checking the source address is to encrypt and authenticate the packets, using a secret key that is conveyed during the call set-up procedure. This will no slow down the call set-up, and provides strong protection against address spoofing.
ソースアドレスをチェックすることへの代替手段は、パケットを暗号化して、認証することです、呼び出し設定の手順の間に運ばれる秘密鍵を使用して。 下側呼び出しに遅くないこの意志は、アドレススプーフィングに対する強い保護をセットアップして、提供します。
6. Event packages and end point types
6. イベントパッケージとエンドポイントタイプ
This section provides an initial definition of packages and event names. More packages can be defined in additional documents.
このセクションはパッケージとイベント名の初期の定義を提供します。 追加ドキュメントで、より多くのパッケージを定義できます。
Arango, et al. Informational [Page 109] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[109ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
6.1. Basic packages
6.1. 基本的なパッケージ
The list of basic packages includes the following:
基本的なパッケージのリストは以下を含んでいます:
_________________________________________
| Package | name |
|______________________________|_________|
| Generic Media Package | G |
| DTMF package | D |
| MF Package | M |
| Trunk Package | T |
| Line Package | L |
| Handset Package | H |
| RTP Package | R |
| Network Access Server Package| N |
| Announcement Server Package | A |
| Script Package | Script|
|______________________________|_________|
_________________________________________ | パッケージ| 名前| |______________________________|_________| | ジェネリックメディア・パッケージ| G| | DTMFパッケージ| D| | mfパッケージ| M| | トランクパッケージ| T| | 線パッケージ| L| | 受話器パッケージ| H| | RTPパッケージ| R| | ネットワークアクセス・サーバーパッケージ| N| | 発表サーバパッケージ| A| | スクリプトパッケージ| スクリプト| |______________________________|_________|
In the tables of events for each package, there are five columns:
各パッケージのためのイベントのテーブルに、5つのコラムがあります:
Symbol: the unique symbol used for the event
Definition: a short description of the event
シンボル: ユニークなシンボルはイベントにDefinitionを使用しました: イベントの短い記述
R: an x appears in this column is the event can be Requested by
the call agent.
R: xはこれに現れます。呼び出しによるRequestedがエージェントであったかもしれないなら、コラムはイベントです。
S: if nothing appears in this column for an event, then the event
cannot be signaled on command by the call agent. Otherwise, the
following symbols identify the type of event:
S: 何もこのコラムにイベントに関して現れないなら、呼び出しエージェントによるコマンドのときにイベントに合図できません。 さもなければ、以下のシンボルはイベントのタイプを特定します:
OO On/Off signal. The signal is turned on until commanded by the
call agent to turn it off, and vice versa.
OO On/オフな信号。 それをオフにすると呼び出しエージェントによって命令されるまで、信号はつけられています、そして、逆もまた同様です。
TO Timeout signal. The signal lasts for a given duration unless
it is superseded by a new signal.
TO Timeoutは合図します。 それが新しい信号によって取って代わられない場合、信号は与えられた持続時間のためにもちます。
BR Brief signal. The event has a short, known duration.
BR Briefは合図します。 イベントには、短くて、知られている持続時間があります。
Duration: specifies the duration of TO signals.
持続時間: TO信号の持続時間を指定します。
Arango, et al. Informational [Page 110] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[110ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
6.1.1. Generic Media Package
6.1.1. ジェネリックメディア・パッケージ
Package Name: G
名前をパッケージしてください: G
The generic media package group the events and signals that can be observed on several types of endpoints, such as trunking gateways, access gateways or residential gateways.
ジェネリックメディアパッケージはいくつかのタイプの終点で観察できるイベントと信号を分類します、中継方式ゲートウェイ、アクセスゲートウェイまたは住宅のゲートウェイなどのように。
_____________________________________________________________________ | Symbol | Definition | R | S Duration | |__________|____________________________|_____|______________________| | mt | Modem detected | x | | | ft | Fax tone detected | x | | | ld | Long duration connection | x | | | pat(###) | Pattern ### detected | x | OO | | rt | Ringback tone | | TO | | rbk(###) | ring back on connection | | TO 180 seconds | | cf | Confirm tone | | BR | | cg | Network Congestion tone | | TO | | it | Intercept tone | | OO | | pt | Preemption tone | | OO | | of | report failure | x | | |__________|____________________________|_____|______________________|
_____________________________________________________________________ | シンボル| 定義| R| S持続時間| |__________|____________________________|_____|______________________| | mt| 検出されたモデム| x| | | フィート| 検出されたファックストーン| x| | | ld| 長い持続時間接続| x| | | 軽くたたくこと(###)| 検出されたパターン###| x| OO| | rt| Ringbackトーン| | to| | rbk(###)| 接続のときに、鳴ってください。| | 180秒のTO| | Cf| トーンを確認してください。| | Br| | cg| ネットワークCongestionトーン| | to| | それ| インタセプトトーン| | OO| | Pt| 先取りトーン| | OO| | of| レポート失敗| x| | |__________|____________________________|_____|______________________|
The signals are defined as follows:
信号は以下の通り定義されます:
The pattern definition can be used for specific algorithms such as
answering machine detection, tone detection, and the like.
留守番電話検出や、トーン検出や、同様のものなどの特定のアルゴリズムにパターン定義を使用できます。
Ring back tone (rt)
an Audible Ring Tone, a combination of two AC tones with
frequencies of 440 and 480 Hertz and levels of -19 dBm each, to
give a combined level of -16 dBm. The cadence for Audible Ring
Tone is 2 seconds on followed by 4 seconds off. See GR- 506-CORE -
LSSGR: SIGNALING, Section 17.2.5.
440と480Hertzの頻度とそれぞれ-19dBmのレベルでトーン(rt)Audible Ring利根、2つの交流トーンの組み合わせの電話をかけ直して、-16dBmの結合したレベルを与えてください。 Audible Ring利根へのリズムは4秒までに以下でオフさ2秒です。 GRが506芯を取るのを見てください--、LSSGR: シグナリング、セクション17.2.5。
Ring back on connection
A ring back tone, applied to the connection whose identifier is
passed as a parameter.
トーンであって、識別子がパラメタとして通過される接続に適用された接続Aリング後部で鳴ってください。
The "long duration connection" is detected when a connection has been established for more than 1 hour.
接続が1時間以上確立されているとき、「長い持続時間接続」は検出されます。
Arango, et al. Informational [Page 111] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[111ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
6.1.2. DTMF package
6.1.2. DTMFパッケージ
Package name: D
名前をパッケージしてください: D
_______________________________________________________________
| Symbol | Definition | R | S Duration |
|________|___________________________|_____|___________________|
| 0 | DTMF 0 | x | BR |
| 1 | DTMF 1 | x | BR |
| 2 | DTMF 2 | x | BR |
| 3 | DTMF 3 | x | BR |
| 4 | DTMF 4 | x | BR |
| 5 | DTMF 5 | x | BR |
| 6 | DTMF 6 | x | BR |
| 7 | DTMF 7 | x | BR |
| 8 | DTMF 8 | x | BR |
| 9 | DTMF 9 | x | BR |
| # | DTMF # | x | BR |
| * | DTMF * | x | BR |
| A | DTMF A | x | BR |
| B | DTMF B | x | BR |
| C | DTMF C | x | BR |
| D | DTMF D | x | BR |
| L | long duration indicator | x | 2 seconds|
| X | Wildcard, match | x | |
| | any digit 0-9 | | |
| T | Interdigit timer | x | 4 seconds|
| of | report failure | x | |
|________|___________________________|_____|___________________|
_______________________________________________________________ | シンボル| 定義| R| S持続時間| |________|___________________________|_____|___________________| | 0 | DTMF0| x| Br| | 1 | DTMF1| x| Br| | 2 | DTMF2| x| Br| | 3 | DTMF3| x| Br| | 4 | DTMF4| x| Br| | 5 | DTMF5| x| Br| | 6 | DTMF6| x| Br| | 7 | DTMF7| x| Br| | 8 | DTMF8| x| Br| | 9 | DTMF9| x| Br| | # | DTMF#| x| Br| | * | DTMF*| x| Br| | A| DTMF A| x| Br| | B| DTMF B| x| Br| | C| DTMF C| x| Br| | D| DTMF D| x| Br| | L| 長い持続時間インディケータ| x| 2秒| | X| ワイルドカード、マッチ| x| | | | どんなケタ0-9| | | | T| 趾間部タイマ| x| 4秒| | of| レポート失敗| x| | |________|___________________________|_____|___________________|
The "interdigit timer" T is a digit input timer that can be used in two ways:
「趾間部タイマ」Tは2つの方法で使用できるケタ入力タイマです:
* When timer T is used with a digit map, the timer is not started
until the first digit is entered, and the timer is restarted after
each new digit is entered until either a digit map match or
mismatch occurs. In this case, timer T functions as an inter-digit
timer.
* タイマTがケタ地図と共に使用されるとき、最初のケタが入られて、ケタ地図マッチかミスマッチのどちらかが現れるまでそれぞれの新しいケタが入れられた後にタイマが再開されるまで、タイマは始動されません。 この場合、タイマTは趾間部タイマとして機能します。
* When timer T is used without a digit map, the timer is started
immediately and simply cancelled (but not restarted) as soon as a
digit is entered. In this case, timer T can be used as an
interdigit timer when overlap sending is used.
* タイマTがケタ地図なしで使用されるとき、ケタが入れられるとすぐに、タイマは、すぐに、始動されて、単に取り消されます(しかし、再開されません)。 オーバラップ発信がこの場合使用されているとき、趾間部タイマとしてタイマTを使用できます。
When used with a digit map, timer T takes on one of two values,
T(partial) or T(critical). When at least one more digit is
required for the digit string to match any of the patterns in the
digit map, timer T takes on the value T(partial), corresponding to
ケタ地図と共に使用されると、タイマTは2値、T(部分的な)またはT(重要な)の1つを帯びます。 ケタストリングがケタ地図のパターンのどれかに合うのに少なくとももうひとつのケタが必要であるときに、タイマTは値T(部分的な)を呈します、対応しています。
Arango, et al. Informational [Page 112] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[112ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
partial dial timing. If a timer is all that is required to produce
a match, timer T takes on the value T(critical) corresponding to
critical timing. When timer T is used without a digit map, timer T
takes on the value T(critical). The default value for T(partial)
is 16 seconds and the default value for T(critical) is 4 seconds.
The provisioning process may alter both of these.
部分的なダイヤルタイミング。 タイマがマッチを生産するのに必要であるすべてなら、タイマTは重要なタイミングに対応する値T(重要な)を呈します。 タイマTがケタ地図なしで使用されるとき、タイマTは値T(重要な)を呈します。 T(部分的な)のためのデフォルト値は16秒です、そして、T(重要な)のためのデフォルト値は4秒です。 食糧を供給するプロセスはこれらの両方を変更するかもしれません。
The "long duration indicator" is observed when a DTMF signal is
produced for a duration larger than two seconds. In this case,
the gateway will detect two successive events: first, when the
signal has been recognized, the DTMF signal, and then, 2 seconds
later, the long duration signal.
DTMF信号が2秒より大きい持続時間のために作り出されるとき、「長い持続時間インディケータ」は観測されます。 この場合、ゲートウェイは2つの連続したイベントを検出するでしょう: 信号が認識されていて、DTMF信号であって、次に、2秒より遅れているときの最初に、長い持続時間信号。
6.1.3. MF Package
6.1.3. mfパッケージ
Package Name: M
名前をパッケージしてください: M
________________________________________________________
| Symbol | Definition | R | S Duration |
|________|____________________|_____|___________________|
| 0 | MF 0 | x | BR |
| 1 | MF 1 | x | BR |
| 2 | MF 2 | x | BR |
| 3 | MF 3 | x | BR |
| 4 | MF 4 | x | BR |
| 5 | MF 5 | x | BR |
| 6 | MF 6 | x | BR |
| 7 | MF 7 | x | BR |
| 8 | MF 8 | x | BR |
| 9 | MF 9 | x | BR |
| X | Wildcard, match | x | |
| | any digit 0-9 | | |
| T | Interdigit timer | x | 4 seconds|
| K0 | MF K0 or KP | x | BR |
| K1 | MF K1 | x | BR |
| K2 | MF K2 | x | BR |
| S0 | MF S0 or ST | x | BR |
| S1 | MF S1 | x | BR |
| S2 | MF S2 | x | BR |
| S3 | MF S3 | x | BR |
| wk | Wink | x | BR |
| wko | Wink off | x | BR |
| is | Incoming seizure | x | OO |
| rs | Return seizure | x | OO |
| us | Unseize circuit | x | OO |
| of | report failure | x | |
|________|____________________|_____|___________________|
________________________________________________________ | シンボル| 定義| R| S持続時間| |________|____________________|_____|___________________| | 0 | mf0| x| Br| | 1 | mf1| x| Br| | 2 | mf2| x| Br| | 3 | mf3| x| Br| | 4 | mf4| x| Br| | 5 | mf5| x| Br| | 6 | mf6| x| Br| | 7 | mf7| x| Br| | 8 | mf8| x| Br| | 9 | mf9| x| Br| | X| ワイルドカード、マッチ| x| | | | どんなケタ0-9| | | | T| 趾間部タイマ| x| 4秒| | K0| mf K0かKP| x| Br| | K1| mf K1| x| Br| | ケーツー| MFケーツー| x| Br| | S0| 第またはmf S0。| x| Br| | S1| mf S1| x| Br| | S2| mf S2| x| Br| | S3| mf S3| x| Br| | 週| ウインク| x| Br| | wko| 下にウインクしてください。| x| Br| | あります。| 入って来る捕獲| x| OO| | rs| リターン捕獲| x| OO| | 私たち| 回路をUnseizeします。| x| OO| | of| レポート失敗| x| | |________|____________________|_____|___________________|
Arango, et al. Informational [Page 113] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[113ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
The definition of the MF package events is as follows:
MFパッケージイベントの定義は以下の通りです:
Wink
A transition from unseized to seized to unseized trunk states
within a specified period. Typical seizure period is 100-350
msec.)
Aが「非-差押え」られるのから移行するウインクは指定された期間以内に「非-差押え」られたトランク州に止まりました。 典型的な捕獲の期間は100-350msecです。)
Incoming seizure
Incoming indication of call attempt.
呼び出し試みの入って来る捕獲Incomingしるし。
Return seizure:
Seizure in response to outgoing seizure.
捕獲を返してください: 外向的な捕獲に対応した捕獲。
Unseize circuit:
Unseizure of a circuit at the end of a call.
Unseizeする、回路: 呼び出しの終わりの回路のUnseizure。
Wink off:
A signal used in operator services trunks. A transition from
seized to unseized to seized trunk states within a specified
period of 100-350 ms. (To be checked)
以下でウインクしてください。 信号はオペレータサービスにトランクスを使用しました。 100-350 指定された期間の原稿の中の捕らわれているトランク州に「非-差押え」られるのに差押えられて、Aは移行します。(チェックされる)
6.1.4. Trunk Package
6.1.4. トランクパッケージ
Package Name: T
名前をパッケージしてください: T
_____________________________________________________________________ | Symbol | Definition | R | S Duration | |________|________________________________|_____|____________________| | co1 | Continuity tone (single tone,| x | OO | | | or return tone) | | | | co2 | Continuity test (go tone, | x | OO | | | in dual tone procedures) | | | | lb | Loopback | | OO | | om | Old Milliwatt Tone (1000 Hz) | x | OO | | nm | New Milliwatt Tone (1004 Hz) | x | OO | | tl | Test Line | x | OO | | zz | No circuit | x | OO | | as | Answer Supervision | x | OO | | ro | Reorder Tone | x | TO 30 seconds| | of | report failure | x | | | bl | Blocking | | OO | |________|________________________________|_____|____________________|
_____________________________________________________________________ | シンボル| 定義| R| S持続時間| |________|________________________________|_____|____________________| | co1| 連続トーン(| x| OO| | | シングル・トーン、リターントーン)| | | | co2| 連続テスト(| x| OO| | | 順調なトーン、コネ二元的なトーン手順)| | | | lb| ループバック| | OO| | om| 古いミリワットトーン(1000Hz)| x| OO| | nm| 新しいミリワットトーン(1004Hz)| x| OO| | Tl| 試運転用線路| x| OO| | zz| 回路がありません。| x| OO| | as| 答え指揮| x| OO| | ro| 追加注文トーン| x| 30秒のTO| | of| レポート失敗| x| | | bl| ブロッキング| | OO| |________|________________________________|_____|____________________|
The definition of the trunk package signal events is as follows:
トランクパッケージ信号イベントの定義は以下の通りです:
Continuity Tone (co1):
A tone at 2010 + or - 30 Hz.
連続トーン(co1): または、2010年の+におけるトーン、--30Hz。
Arango, et al. Informational [Page 114] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[114ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Continuity Test (co2):
A tone at the 1780 + or - 30 Hz.
連続テスト(co2): または、1780年の+におけるトーン、--30Hz。
Milliwatt Tones:
Old Milliwatt Tone (1000 Hz), New Milliwatt Tone (1004 Hz)
ミリワットトーン: 古いミリワットトーン(1000Hz)、新しいミリワットトーン(1004Hz)
Line Test:
105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 dBm0
+ or -- 0.5dB).
テストを裏打ちしてください: または、または、105テスト線テスト進歩トーン、(2225Hz+、--、-10dBm0+の25Hz、--0.5dB)
No circuit:
(that annoying tri-tone, low to high)
回路がありません: (その煩わしい3音、高値への安値)
Answer Supervision:
指揮に答えてください:
Reorder Tone:
Reorder tone is a combination of two AC tones with frequencies of
480 and 620 Hertz and levels of -24 dBm each, to give a combined
level of -21 dBm. The cadence for Station Busy Tone is 0.25
seconds on followed by 0.25 seconds off, repeating continuously.
See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7.
追加注文トーン: 追加注文トーンは、-21dBmの結合したレベルを与えるためには480と620Hertzの頻度とそれぞれ-24dBmのレベルがある2つの交流トーンの組み合わせです。 絶え間なく繰り返して、駅のBusy利根へのリズムは0.25秒までに以下でオフさ0.25秒です。 GR506コアを見てください--、LSSGR: シグナリング、セクション17.2.7。
Blocking:
The call agent can place the circuit in a blocked state by
applying the "bl(+)" signal to the endpoint. It can unblock it by
applying the "bl(-)" signal.
ブロッキング: 呼び出しエージェントは、「bl(+)」信号を終点に適用することによって、妨げられた状態の回路を置くことができます。 それは、"bl(-)"信号を適用することによって、それを「非-妨げ」ることができます。
The continuity tones are used when the call agent wants to initiate a continuity test. There are two types of tests, single tone and dual tone. The Call agent is expected to know, through provisioning information, which test should be applied to a given endpoint. For example, the call agent that wants to initiate a single frequency test will send to the gateway a command of the form:
呼び出しエージェントが連続テストを開始したがっているとき、連続トーンは使用されています。 2つのタイプのテスト、シングル・トーン、および二元的なトーンがあります。 Callエージェントが、どのテストが与えられた終点に適用されるべきであるかを情報に食糧を供給することで知っていると予想されます。 例えば、ただ一つの頻度テストを開始したがっている呼び出しエージェントは形式のコマンドをゲートウェイに送るでしょう:
RQNT 1234 epx-t1/17@tgw2.example.net
X: AB123FE0
S: co1
R: co1
RQNT1234 epx-t1/17@tgw2.example.net X: AB123FE0 S: co1R: co1
If it wanted instead to initiate a dual-tone test, it would send the command:
それが代わりに二元的なトーンテストを開始したいと思うなら、コマンドを送るでしょうに:
RQNT 1234 epx-t1/17@tgw2.example.net
X: AB123FE0
S: co2
R: co1
RQNT1234 epx-t1/17@tgw2.example.net X: AB123FE0 S: co2R: co1
Arango, et al. Informational [Page 115] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[115ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
The gateway would send the requested signal, and in both cases would look for the return of the 2010 Hz tone (co1). When it detects that tone, it will send the corresponding notification.
ゲートウェイは、要求された信号を送って、どちらの場合も、2010Hzのトーン(co1)の復帰を探すでしょう。 そのトーンを検出するとき、それは対応する通知を送るでしょう。
The tones are of type OO: the gateway will keep sending them until it receives a new notification request.
タイプOOにはトーンがあります: ゲートウェイはそれが新しい通知要求を受け取るまでそれらを送り続けるでしょう。
6.1.5. Line Package
6.1.5. 線パッケージ
Package Name: L
名前をパッケージしてください: L
________________________________________________________________________ |Symbol | Definition | R | S Duration | |_____________|______________________________|_____|___________________| |adsi(string) | adsi display | | BR | |vmwi | visual message | | OO | | | waiting indicator | | | |hd | Off hook transition | x | | |hu | On hook transition | x | | |hf | Flash hook | x | | |aw | Answer tone | x | OO | |bz | Busy tone | | TO 30 seconds | |ci(ti,nu,na) | Caller-id | | BR | |wt | Call Waiting tone | | TO 30 seconds | |wt1, wt2, | Alternative call | | | |wt3, wt4 | waiting tones | | | |dl | Dial tone | | TO 16 seconds | |mwi | Message waiting ind. | | TO 16 seconds | |nbz | Network busy | x | OO | | | (fast cycle busy) | | | |ro | Reorder tone | | TO 30 seconds | |rg | Ringing | | TO 180 seconds| |r0, r1, r2, | Distinctive ringing | | TO 180 seconds| |r3, r4, r5, | | | | |r6 or r7 | | | | |rs | Ringsplash | | BR | |p | Prompt tone | x | BR | |e | Error tone | x | BR | |sl | Stutter dialtone | | TO 16 seconds | |v | Alerting Tone | | OO | |y | Recorder Warning Tone | | OO | |sit | SIT tone | | | |z | Calling Card Service Tone | | OO | |oc | Report on completion | x | | |ot | Off hook warning tone | | TO indefinite | |s(###) | Distinctive tone pattern | x | BR | |of | report failure | x | | |_____________|______________________________|_____|___________________|
________________________________________________________________________ |シンボル| 定義| R| S持続時間| |_____________|______________________________|_____|___________________| |adsi(ストリング)| adsiディスプレイ| | Br| |vmwi| 視覚メッセージ| | OO| | | 準備中表示| | | |hd| フック変遷で| x| | |hu| フック変遷に関して| x| | |hf| フラッシュフック| x| | |aw| 答えトーン| x| OO| |bz| 話中音| | 30秒のTO| |ci(ti、ν、Na)| 訪問者イド| | Br| |wt| 呼び出しWaitingトーン| | 30秒のTO| |wt1、wt2| 代替の呼び出し| | | |wt3、wt4| 待ちトーン| | | |dl| ダイヤルトーン| | 16秒のTO| |mwi| メッセージ待ちind。 | | 16秒のTO| |nbz| ネットワーク忙しいです。| x| OO| | | (速く、忙しい状態で、循環します) | | | |ro| 追加注文トーン| | 30秒のTO| |rg| 鳴ります。| | 180秒のTO| |r0、r1、r2| 特有の鳴ること| | 180秒のTO| |r3、r4、r5| | | | |r6かr7| | | | |rs| Ringsplash| | Br| |p| 迅速なトーン| x| Br| |e| 誤りトーン| x| Br| |sl| どもりdialtone| | 16秒のTO| |v| トーンを警告します。| | OO| |y| レコーダー警告トーン| | OO| |座ってください。| SITトーン| | | |z| テレホンカードサービストーン| | OO| |oc| 完成に関して、報告してください。| x| | |ot| オフフック警告トーン| | TO無期です。| |s(###)| 特有のトーンパターン| x| Br| |of| レポート失敗| x| | |_____________|______________________________|_____|___________________|
Arango, et al. Informational [Page 116] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[116ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
The definition of the tones is as follows:
トーンの定義は以下の通りです:
Dial tone:
A combined 350 + 440 Hz tone.
ダイヤルトーン: 結合した350+440Hz、調子を変えてください。
Visual Message Waiting Indicator
The transmission of the VMWI messages will conform to the
requirements in Section 2.3.2, "On-hook Data Transmission Not
Associated with Ringing" in TR-H-000030 and the CPE guidelines in
SR-TSV-002476. VMWI messages will only be sent from the SPCS when
the line is idle. If new messages arrive while the line is busy,
the VMWI indicator message will be delayed until the line goes
back to the idle state. The CA should periodically refresh the
CPE's visual indicator. See TR-NWT-001401 - Visual Message Waiting
Indicator Generic Requirements; and GR- 30-CORE - Voiceband Data
Transmission Interface.
VMWIメッセージの伝達がTR-H-000030とSR-TSV-002476のCPEガイドラインの.2、「フックの上の鳴るのに関連づけられなかったデータ伝送」というセクション2.3で要件に従わせる視覚Message Waiting Indicator。 系列が活動していないときにだけ、SPCSからVMWIメッセージを送るでしょう。 回線が話し中である間、新しいメッセージが到着すると、系列が活動していない状態に戻るまで、VMWIインディケータメッセージは遅れるでしょう。 カリフォルニアは定期的にCPEの視覚インディケータをリフレッシュするべきです。 TR-NWT-001401を見てください--視覚通話待ち指示器ジェネリック要件 そして、GRの30コア--Voicebandデータ伝送インタフェース。
Message waiting Indicator
See GR-506-CORE, 17.2.3.
.3にIndicator See GR-506-CORE、17.2を待つメッセージ
Alerting Tone:
a 440 Hz Tone of 2 second duration followed by 1/2 second of tone
every 10 seconds.
警告トーン: 2番目の持続時間が10秒毎に1/2秒のトーンを続けた2の440Hzの利根。
Ring splash
Ringsplash, also known as "Reminder ring" is a burst of ringing
that may be applied to the physical forwarding line (when idle) to
indicate that a call has been forwarded and to remind the user
that a CF subfeature is active. In the US, it is defined to be a
0.5(-0,+0.1) second burst of power ringing. See TR-TSY-000586 -
Call Forwarding Subfeatures.
リングスプラッシュRingsplash、また、「思い出させるものリング」として知られているのは、呼び出しが進められたのを示して、CF subfeatureがアクティブであることをユーザに思い出させるために物理的な推進系列(活動していないときに)に適用されるかもしれない鳴ることの炸裂です。 米国では、それが、パワーの鳴ることの0.5(+0.1の-0)の2番目の炸裂になるように定義されます。 TR-TSY-000586を見てください--Subfeaturesを前に呼んでください。
Call waiting tone
Call Waiting tone is defined in GR-506-CORE, 14.2. Call Waiting
feature is defined in TR-TSY-000571. By defining "wt" as a TO
signal you are really defining the feature which seems wrong to me
(given the spirit of MGCP), hence the definition of "wt" as a BR
signal in ECS, per GR-506-CORE. Also, it turns out that there is
actually four different call waiting tone patterns (see GR-506-
CORE, 14.2) so we have wt1, wt2, wt3, wt4.
キャッチホントーンCall WaitingトーンはGR-506-CORE、14.2で定義されます。 呼び出しWaiting機能はTR-TSY-000571で定義されます。 「wt」をTO信号と定義することによって、あなたは本当に私(MGCPを精神に与える)にとって間違っているように見える特徴、したがって、「wt」の定義をECSのBR信号と定義しています、GR-506-CORE単位で。 また、4つの異なったキャッチホントーンパターンが実際にある(GR-506COREを見てください、14.2)と判明するので、私たちはwt1を持っています、wt2、wt3、wt4。
Caller Id (ci(time, number, name)):
The caller-id event carries three parameters, the time of the
call, the calling number and the calling name. Each of the three
fields are optional, however each of the commas will always be
included. See TR-NWT-001188, GR-30-CORE, and TR-NWT-000031.
訪問者Id(ci(時間、数、名前)): 訪問者イドイベントは3つのパラメタ、呼び出しの時間、呼んでいる数、および呼んでいる名前を運びます。 それぞれの3つの分野が任意である、しかしながら、それぞれのコンマはいつも含まれるでしょう。 TR-NWT-001188、GR30コア、およびTR-NWT-000031を見てください。
Arango, et al. Informational [Page 117] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[117ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Recorder Warning Tone:
1400 Hz of Tone of 0.5 second duration every 15 seconds.
レコーダー警告トーン: 0.5秒の持続時間の利根の15秒あたり1400Hz。
SIT tone:
used for indicating a line is out of service.
SITは調子を変えます: 系列が使われなくなっているのを示すのにおいて、使用されています。
Calling Card Service Tone:
60 ms of 941 + 1477 Hz and 940 ms of 350 + 440 Hz (dial tone),
decaying exponentially with a time constant of 200 ms.
カードサービスと呼んで、調子を変えてください: 60 941+1477Hzのmsと200原稿の時定数で指数関数的に腐食する350+440Hz(ダイヤルトーン)の940ms
Distinctive tone pattern:
where ### is any number between 000 and 999, inclusive. Can be
used for distinctive ringing, customized dial tone, etc.
特有のトーンパターン: ###、がどんな000〜999の数的であっても、包括的であるところ。 特有の鳴るカスタム設計されたダイヤルトーンなどに使用できます。
Report on completion
The report on completion event is detected when the gateway was
asked to perform one or several signals of type TO on the
endpoint, and when these signals were completed without being
stopped by the detection of a requested event such as off-hook
transition or dialed digit. The completion report may carry as
parameter the name of the signal that came to the end of its live
time, as in:
ゲートウェイであるときに、完成イベントに関するレポートが検出されるという完成に関するレポートがタイプTOに関する1かいくつかの信号を終点に実行するように頼まれて、これらの信号がいつオフフック変遷などの要求されたイベントの検出で止められないで完成されたか、またはケタにダイヤルしたかをそうされます。 完成レポートはパラメタとして以下のようにライブ時間の終わりに来た信号の名前を載せるかもしれません。
O: L/oc(L/dl)
O: L/oc(L/dl)
Ring back on connection
A ring back tone, applied to the connection wghose identifier is
passed as a parameter.
トーンであって、接続wghose識別子に適用された接続Aリング後部のリング後部はパラメタとして通過されます。
We should note that many of these definitions vary from country to country. The frequencies listed above are the one in use in North America. There is a need to accommodate different tone sets in different countries, and there is still an ongoing debate on the best way to meet that requirement:
私たちは、これらの定義の多くが国によって違うことに注意するべきです。 上に記載された頻度は北アメリカの使用中のものです。 異なった国に異なったトーンセットを収容する必要があります、そして、まだ、その必要条件を満たす最も良い方法に関する進行中の討論があります:
* One solution is to define different event packages specifying for
example the German dialtone as "L-DE/DL".
* 1つのソリューションは「L-DE/dl」として例えばドイツのdialtoneを指定する異なったイベントパッケージを定義することです。
* Another solution is to use a management interface to specify on an
endpoint basis which frequency shall be associated to what tone.
* 他の解決法は終点ベースでどの頻度がどんなトーンに関連するかを指定するのに管理インタフェースを使用することです。
Arango, et al. Informational [Page 118] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[118ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
6.1.6. Handset emulation package
6.1.6. 受話器エミュレーションパッケージ
Package Name: H
名前をパッケージしてください: H
________________________________________________________________________ |Symbol | Definition | R | S Duration | |_____________|______________________________|_____|___________________| |adsi(string) | adsi display | x | BR | |tdd | | | | |vmwi | | | | |hd | Off hook transition | x | OO | |hu | On hook transition | x | OO | |hf | Flash hook | x | BR | |aw | Answer tone | x | OO | |bz | Busy tone | x | OO | |wt | Call Waiting tone | x | TO 30 seconds | |dl | Dial tone (350 + 440 Hz) | x | TO 120 seconds| |nbz | Network busy | x | OO | | | (fast cycle busy) | | | |rg | Ringing | x | TO 30 seconds | |r0, r1, r2, | Distinctive ringing | x | TO 30 seconds | |r3, r4, r5, | | | | |r6 or r7 | | | | |p | Prompt tone | x | BR | |e | Error tone | x | BR | |sdl | Stutter dialtone | x | TO 16 seconds | |v | Alerting Tone | x | OO | |y | Recorder Warning Tone | x | OO | |t | SIT tone | x | | |z | Calling Card Service Tone | x | OO | |oc | Report on completion | x | | |ot | Off hook warning tone | x | OO | |s(###) | Distinctive tone pattern | x | BR | |of | report failure | x | | |_____________|______________________________|_____|___________________|
________________________________________________________________________ |シンボル| 定義| R| S持続時間| |_____________|______________________________|_____|___________________| |adsi(ストリング)| adsiディスプレイ| x| Br| |tdd| | | | |vmwi| | | | |hd| フック変遷で| x| OO| |hu| フック変遷に関して| x| OO| |hf| フラッシュフック| x| Br| |aw| 答えトーン| x| OO| |bz| 話中音| x| OO| |wt| 呼び出しWaitingトーン| x| 30秒のTO| |dl| ダイヤルトーン(350+440Hz)| x| 120秒のTO| |nbz| ネットワーク忙しいです。| x| OO| | | (速く、忙しい状態で、循環します) | | | |rg| 鳴ります。| x| 30秒のTO| |r0、r1、r2| 特有の鳴ること| x| 30秒のTO| |r3、r4、r5| | | | |r6かr7| | | | |p| 迅速なトーン| x| Br| |e| 誤りトーン| x| Br| |sdl| どもりdialtone| x| 16秒のTO| |v| トーンを警告します。| x| OO| |y| レコーダー警告トーン| x| OO| |t| SITトーン| x| | |z| テレホンカードサービストーン| x| OO| |oc| 完成に関して、報告してください。| x| | |ot| オフフック警告トーン| x| OO| |s(###)| 特有のトーンパターン| x| Br| |of| レポート失敗| x| | |_____________|______________________________|_____|___________________|
The handset emulation package is an extension of the line package, to be used when the gateway is capable of emulating a handset. The difference with the line package is that events such as "off hook" can be signalled as well as detected.
受話器エミュレーションパッケージは、ゲートウェイが受話器を見習うことができるとき、使用されるためには系列パッケージの拡大です。 系列パッケージがある違いは「フック」などのイベントに合図して、検出できるということです。
Arango, et al. Informational [Page 119] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[119ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
6.1.7. RTP Package
6.1.7. RTPパッケージ
Package Name: R
名前をパッケージしてください: R
____________________________________________________________________
| Symbol | Definition | R | S Duration|
|_________|________________________________|_____|__________________|
| UC | Used codec changed | x | |
| SR(###) | Sampling rate changed | x | |
| JI(###) | Jitter buffer size changed | x | |
| PL(###) | Packet loss exceeded | x | |
| qa | Quality alert | x | |
| co1 | Continuity tone (single tone,| x | OO |
| | or return tone) | | |
| co2 | Continuity test (go tone, | x | OO |
| | in dual tone procedures) | | |
| of | report failure | x | |
|_________|________________________________|_____|__________________|
____________________________________________________________________ | シンボル| 定義| R| S持続時間| |_________|________________________________|_____|__________________| | UC| 中古のコーデックは変化しました。| x| | | SR(###)| 標本抽出率は変化しました。| x| | | JI(###)| ジターバッファサイズは変化しました。| x| | | PL(###)| 損失が超えていたパケット| x| | | qa| 上質の警戒| x| | | co1| 連続トーン(| x| OO| | | シングル・トーン、リターントーン)| | | | co2| 連続テスト(| x| OO| | | 順調なトーン、コネ二元的なトーン手順)| | | | of| レポート失敗| x| | |_________|________________________________|_____|__________________|
Codec Changed:
Codec changed to hexadecimal codec number enclosed in parenthesis,
as in UC(15), to indicate the codec was changed to PCM mu-law.
Codec Numbers are specified in RFC 1890, or in a new definition of
the audio profiles for RTP that replaces this RFC. Some
implementations of media gateways may not allow the codec to be
changed upon command from the call agent. codec changed to codec
hexadecimal ##.
コーデックは変化しました: コーデックはコーデックがPCMμ法に変わったのを示すためにUC(15)のように挿入句に同封された16進コーデック番号に変化しました。 コーデック民数記はRFC1890、またはこのRFCを取り替えるRTPのためのオーディオプロフィールの新しい定義で指定されます。 コーデックはコマンドのときにメディアゲートウェイのいくつかの実装で呼び出しエージェントから変化しないかもしれません。コーデックはコーデック16進##に変化しました。
Sampling Rate Changed:
Sampling rate changed to decimal number in milliseconds enclosed
in parenthesis, as in SR(20), to indicate the sampling rate was
changed to 20 milliseconds. Some implementations of media
gateways may not allow the sampling rate to be changed upon
command from a call agent.
標本抽出率は変化しました: 標本抽出率は標本抽出率が変えられたのを示すためにSR(20)のように挿入句に同封されたミリセカンドから20ミリセカンドで10進数に変化しました。 メディアゲートウェイのいくつかの実装で、標本抽出率はコマンドのときに呼び出しエージェントから変化しないかもしれません。
Jitter Buffer Size Changed:
When the media gateway has the ability to automatically adjust the
depth of the jitter buffer for received RTP streams, it is useful
for the media gateway controller to receive notification that the
media gateway has automatically increased its jitter buffer size
to accomodate increased or decreased variability in network
latency. The syntax for requesting notification is "JI", which
tells the media gateway that the controller wants notification of
any jitter buffer size changes. The syntax for notification from
the media gateway to the controller is "JI(####)", where the ####
is the new size of the jitter buffer, in milliseconds.
ジターバッファサイズは変化しました: メディアゲートウェイに自動的に容認されたRTPストリームのためのジターバッファの深さを調整する能力があるとき、メディアゲートウェイコントローラがメディアゲートウェイが自動的にaccomodateへのサイズが増強したジターバッファを増強するか、またはネットワーク潜在における可変性を減少させたという通知を受け取るのは、役に立ちます。 通知を要求するための構文はコントローラがどんなジターバッファサイズ変化の通知も必要とするとメディアゲートウェイに言う"JI"です。 コントローラへのメディアゲートウェイからの通知のための構文は「JI(####)」です、ミリセカンドで。そこでは、####、はジターバッファの新しいサイズです。
Arango, et al. Informational [Page 120] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[120ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Packet Loss Exceeded:
Packet loss rate exceed the threshold of the specified decimal
number of packets per 100,000 packets, where the packet loss
number is contained in parenthesis. For example, PL(10) indicates
packets are being dropped at a rate of 1 in 10,000 packets.
パケット損失は超えていました: パケット損失率は10万のパケットあたりのパケットの指定された10進数の敷居を超えています。そこでは、パケット損失番号が挿入句に含まれています。 例えば、PL(10)は、パケットが1万のパケットの1のレートで下げられているのを示します。
Quality alert
The packet loss rate or the combination of delay and jitter exceed
a specified quality threshold.
品質はパケット損失率か遅れの組み合わせを警告します、そして、ジターは指定された上質の敷居を超えています。
The continuity tones are the same as those defined in the Trunk package. They can be use in conjunction with the Network LoopBack or Network Continuity Test modes to test the continuity of an RTP circuit.
連続トーンはTrunkパッケージで定義されたものと同じです。 それらは、Network LoopBackかNetwork Continuity Testモードに関連したRTP回路の連続をテストするためには使用であるかもしれません。
The "operation failure" code can be used to report problems such as the loss of underlying connectivity. The observed event can include as parameter the reason code of the failure.
基本的な接続性の損失などの問題を報告するのに「操作失敗」コードを使用できます。 観測されたイベントはパラメタとして失敗の理由コードを含むことができます。
6.1.8. Network Access Server Package
6.1.8. ネットワークアクセス・サーバーパッケージ
Package Name: N
名前をパッケージしてください: N
____________________________________________________________
| Symbol | Definition | R | S Duration|
|________|__________________________|_____|_________________|
| pa | Packet arrival | x | |
| cbk | Call back request | x | |
| cl | Carrier lost | x | |
| au | Authorization succeeded| x | |
| ax | Authorization denied | x | |
| of | Report failure | x | |
|________|__________________________|_____|_________________|
____________________________________________________________ | シンボル| 定義| R| S持続時間| |________|__________________________|_____|_________________| | pa| パケット到着| x| | | cbk| 要求に電話し直してください。| x| | | Cl| キャリヤーは損をしました。| x| | | Au| 承認は成功しました。| x| | | 斧| 否定された承認| x| | | of| レポート失敗| x| | |________|__________________________|_____|_________________|
The packet arrival event is used to notify that at least one packet was recently sent to an Internet address that is observed by an endpoint. The event report includes the Internet address, in standard ASCII encoding, between parenthesis:
パケット到着イベントはそれに通知するのに使用されて、最近少なくとも1つのパケットを終点によって観測されるインターネット・アドレスに送ったということです。 イベントレポートは挿入句の間で以下をコード化する標準のASCIIにインターネット・アドレスを含んでいます。
O: pa(192.96.41.1)
O: pa(192.96.41.1)
The call back event is used to notify that a call back has been requested during the initial phase of a data connection. The event report includes the identification of the user that should be called back, between parenthesis:
逆イベントがそれに通知するのに使用されて、呼び出し後部がデータ接続の初期位相の間、要求されているということであるという要求。 イベントレポートは挿入句の間でコールバックされるべきであるユーザの識別を含んでいます:
O: cbk(user25)
O: cbk(user25)
Arango, et al. Informational [Page 121] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[121ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
6.1.9. Announcement Server Package
6.1.9. 発表サーバパッケージ
Package Name: A
名前をパッケージしてください: A
___________________________________________________________________
| Symbol | Definition | R | S Duration|
|________________|________________________|_____|__________________|
| ann(url,parms) | Play an announcement | | TO variable|
| oc | Report on completion | x | |
| of | Report failure | x | |
|________________|________________________|_____|__________________|
___________________________________________________________________ | シンボル| 定義| R| S持続時間| |________________|________________________|_____|__________________| | ann(url、parms)| 発表をプレーしてください。| | TO変数| | oc| 完成に関して、報告してください。| x| | | of| レポート失敗| x| | |________________|________________________|_____|__________________|
The announcement action is qualified by an URL name and by a set of initial parameters as in for example:
発表動作は例を受けそうでURL名と1セットの初期値パラメタによって資格があります:
S: ann(http://scripts.example.net/all-lines-busy.au)
S: ann( http://scripts.example.net/all-lines-busy.au )
The "operation complete" event will be detected when the announcement is played out. If the announcement cannot be played out, an operation failure event can be returned. The failure may be explained by a commentary, as in:
発表が使い果たされるとき、「操作完全な」イベントは検出されるでしょう。 発表を使い果たすことができないなら、操作失敗イベントを返すことができます。 失敗は以下のように論評で説明されるかもしれません。
O: A/of(file not found)
O: A/(ファイルが見つからない)
6.1.10. Script Package
6.1.10. スクリプトパッケージ
Package Name: Script
名前をパッケージしてください: スクリプト
______________________________________________________________
| Symbol | Definition | R | S | Duration|
|___________|________________________|_____|______|___________|
| java(url) | Load a java script | | TO | variable|
| perl(url) | Load a perl script | | TO | variable|
| tcl(url) | Load a TCL script | | TO | variable|
| xml(url) | Load an XML script | | TO | variable|
| oc | Report on completion | x | | |
| of | Report failure | x | | |
|___________|________________________|_____|______|___________|
______________________________________________________________ | シンボル| 定義| R| S| 持続時間| |___________|________________________|_____|______|___________| | java(url)| javaスクリプトをロードしてください。| | to| 変数| | パール(url)| パールスクリプトをロードしてください。| | to| 変数| | tcl(url)| TCLスクリプトをロードしてください。| | to| 変数| | xml(url)| XMLスクリプトをロードしてください。| | to| 変数| | oc| 完成に関して、報告してください。| x| | | | of| レポート失敗| x| | | |___________|________________________|_____|______|___________|
The "language" action define is qualified by an URL name and by a set of initial parameters as in for example:
「言語」動作が定義する、URL名と1セットの初期値パラメタで、例を受けそうで、資格があります:
S: script/java(http://scripts.example.net/credit-
card.java,long,1234)
S: スクリプト/java( http://scripts.example.net/credit- card.java、長さ1234)
Arango, et al. Informational [Page 122] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[122ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
The current definition defines keywords for the most common languages. More languages may be defined in further version of this documents. For each language, an API specification will describe how the scripts can issue local "notificationRequest" commands, and receive the corresponding notifications.
現在の定義は最も一般的な言語のためのキーワードを定義します。 より多くの言語がこのドキュメントの今後のバージョンで定義されるかもしれません。 各言語のために、API仕様はスクリプトがどうローカルの"notificationRequest"コマンドを発行して、対応する通知を受け取ることができるかを説明するでしょう。
The script produces an output which consists of one or several text string, separated by commas. The text string are reported as a commentary in the report on completion, as in for example:
スクリプトは1から成る出力かコンマによって分離された数個のテキスト文字列を作り出します。 テキスト文字列は完成に関するレポートにおける論評例を受けそうで報告されます:
O: script/oc(21223456794567,9738234567)
O: スクリプト/oc(21223456794567,9738234567)
The failure report may also return a string, as in:
また、異常報告書は以下のようにストリングを返すかもしれません。
O: script/oc(21223456794567,9738234567)
O: スクリプト/oc(21223456794567,9738234567)
The definition of the script environment and the specific actions in that environment are for further study.
さらなる研究にはスクリプト環境の定義とその環境における特定の動作があります。
6.2. Basic endpoint types and profiles
6.2. 基本的な終点タイプとプロフィール
We define the following basic endpoint types and profiles:
私たちは以下の基本的な終点タイプとプロフィールを定義します:
* Trunk gateway (ISUP)
* トランクゲートウェイ(ISUP)
* Trunk gateway (MF)
* トランクゲートウェイ(mf)
* Network Access Server (NAS)
* ネットワークアクセス・サーバー(NAS)
* Combined NAS/VOIP gateway
* 結合したNAS/VOIPゲートウェイ
* Access Gateway
* ゲートウェイにアクセスしてください。
* Residential Gateway
* 住宅のゲートウェイ
* Announcement servers
* 発表サーバ
Arango, et al. Informational [Page 123] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[123ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
These gateways are supposed to implement the following packages
これらのゲートウェイは以下のパッケージを実装するべきです。
___________________________________________________________
| Gateway | Supported packages |
|____________________________|_____________________________|
| Trunk gateway (ISUP) | GM, DTMF, TK, RTP |
| Trunk gateway (MF) | GM, MF, DTMF, TK, RTP |
| Network Access Server (NAS)| GM, MF, TK, NAS |
| Combined NAS/VOIP gateway | GM, MF, DTMF, TK, NAS, RTP|
| Access Gateway (VOIP) | GM, DTMF, MF, RTP |
| Access Gateway (VOIP+NAS) | GM, DTMF, MF, NAS, RTP |
| Residential Gateway | GM, DTMF, Line, RTP |
| Announcement Server | ANN, RTP |
|____________________________|_____________________________|
___________________________________________________________ | ゲートウェイ| パッケージであるとサポートされます。| |____________________________|_____________________________| | トランクゲートウェイ(ISUP)| GM、DTMF、TK、RTP| | トランクゲートウェイ(MF)| GM、mf、DTMF、TK、RTP| | ネットワークアクセス・サーバー(NAS)| GM、mf、TK、NAS| | 結合したNAS/VOIPゲートウェイ| GM、mf、DTMF、TK、NAS、RTP| | アクセスゲートウェイ(VOIP)| GM、DTMF、mf、RTP| | アクセスゲートウェイ(VOIP+NAS)| GM、DTMF、mf、NAS、RTP| | 住宅のゲートウェイ| RTP、GM、DTMFは立ち並んでいます。| | 発表サーバ| アン、RTP| |____________________________|_____________________________|
Advanced announcement servers may also support the Script package.
また、高度な発表サーバはScriptパッケージを支えるかもしれません。
Advanced trunking servers may support the ANN package, the Script package, and in some cases the Line and Handset package as well.
高度な中継方式サーバはいくつかの場合また、ANNパッケージ、Scriptパッケージ、線、およびHandsetパッケージを支えるかもしれません。
7. Versions and compatibility
7. バージョンと互換性
7.1. Differences between version 1.0 and draft 0.5
7.1. バージョン1.0と草稿0.5の違い
Draft 0-5 was issued in February 1999, as the last update of draft version 0.1. Version 1.0 benefits from implementation experience, and also aligns as much as possible with the CableLabs' NCS project. The main differences between the February draft and version 1.0 are:
草稿0-5は1999年2月に草案バージョン0.1のアップデートとして発行されました。 バージョン1.0は、実装経験の利益を得て、また、CableLabsのNCSプロジェクトをできるだけ一直線にします。 2月の草稿とバージョン1.0の主な違いは以下の通りです。
* Specified more clearly that the encoding of three
LocalConnectionOptions parameters, Encoding Method, Packetization
Period and Bandwidth, shall follow the conventions laid out in
SDP.
* より明確に、3つのLocalConnectionOptionsパラメタのコード化(Encoding Method、Packetization Period、およびBandwidth)がSDPで広げられたコンベンションに続くだろうと指定しました。
* Specified how the quarantine handling parameter governs the
handling of detected but not yet specified events.
* 隔離取り扱いパラメタがどう検出されましたが、まだ指定されなかったイベントの取り扱いを治めるかを指定しました。
* Specified that unexpected timers or digits should trigger
transmission of the dialed string.
* 予期していなかったタイマかケタがダイヤルされたストリングのトランスミッションの引き金となるべきであると指定しました。
* Removed the digit map syntax description from section 2.1.5 (it
was redundant with section 3.4.)
* 取り除いて、ケタはセクション2.1.5から構文記述を写像します。(それはセクション3.4で余分でした。)
* Corrected miscellaneous bugs in the formal syntax description.
* 直っているその他は正式な構文記述で急いで去ります。
* Aligned specification of commands with the CableLabs NCS
specification. This mostly affects the AuditEndpoint and
* CableLabs NCS仕様にコマンドの仕様を一直線にしました。 そしてこれがAuditEndpointにほとんど影響する。
Arango, et al. Informational [Page 124] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[124ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
RestartInProgress commands.
RestartInProgressは命令します。
* Aligned the handling of retransmission with the CableLabs NCS
specification.
* CableLabs NCS仕様に「再-トランスミッション」の取り扱いを一直線にしました。
* Added the provisional response return code and corresponding
behavior description.
* 暫定的な応答復帰コードと対応する振舞い記述を加えました。
* Added an optional reason code parameter to restart in progress.
* 任意の理由コード・パラメータを進行中の再開に加えました。
* Added the possibility to audit the restart method, restart delay
and reason code.
* 再開メソッド、再開遅れ、および理由コードを監査する可能性を加えました。
7.2. Differences between draft-04 and draft-05
7.2. 草稿-04と草稿-05の違い
Differences are minor: corrected the copyright statement, and corrected a bug in the formal description.
違いは小さい方です: 著作権宣言文を修正して、形式的記述でバグを修正しました。
7.3. Differences between draft-03 and draft-04
7.3. 草稿-03と草稿-04の違い
Draft 04 corrects a number of minor editing mistakes that were pointed out during the review of draft 03, issued on February 1.
草稿04は草稿03のレビューの間に指摘された多くの小さい方の編集誤りを修正します、2月1日に発行されて。
7.4. Differences between draft-02 and draft-03
7.4. 草稿-02と草稿-03の違い
The main differences between draft-02, issued in January 22 1998, and draft 03 are:
1998年1月22日で発行された草稿-02と、草稿03の主な違いは以下の通りです。
* Introduced a discussion on endpoint types,
* 終点タイプについての議論を導入しました。
* Introduced a discussion of the connection set-up procedure, and of
the role of connection parameters,
* 接続設定の手順、および接続パラメタの役割の議論を導入しました。
* Introduced a notation of the connection identifier within event
names,
* イベント名の中で接続識別子の記法を導入しました。
* Documented the extension procedure for the LocalConnectionOptions
parameter and for the ConnectionParameters parameter,
* LocalConnectionOptionsパラメタとConnectionParametersパラメタのために拡張の手順を記録しました。
* Introduced a three-way handshake procedure, using a ResponseAck
parameter, in order to allow gateways to delete copies of old
responses without waiting for a 30 seconds timer,
* ゲートウェイが30秒のタイマを待たないで古い応答のコピーを削除するのを許容するのにResponseAckパラメタを使用して、3方向ハンドシェイク手順を導入しました。
* Expanded the security section to include a discussion of
"uncontrolled barge-in."
* 「中では、はしけで運非制御の」議論を含むようにセキュリティ部を膨張させました。
* Propsed a "create two connections" command, as an appendix.
* 付録として「2つの接続を創造してください」というコマンドをPropsedしました。
Arango, et al. Informational [Page 125] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[125ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
7.5. Differences between draft-01 and draft-02
7.5. 草稿-01と草稿-02の違い
The main differences between draft-01, issued in November 1998, and draft 02 are:
1998年11月に発行された草稿-01と、草稿02の主な違いは以下の通りです。
* Added an ABNF description of the protocol.
* プロトコルのABNF記述を加えました。
* Specification of an EndpointConfiguration command,
* EndpointConfigurationコマンドの仕様
* Addition of a "two endpoints" mode in the create connection
command,
* 中の「2つの終点」のモードの追加、接続命令を作成してください。
* Modification of the package wildcards from "$/$" to "*/all" at the
Request of early implementors,
* 」 */への「」 $/$からのパッケージワイルドカードの変更」、すべて、」 初期の作成者の依頼で
* Revision of some package definitions to better align with external
specifications.
* 外部仕様によりよく並べるいくつかのパッケージ定義の改正。
* Addition of a specification for the handling of "failover."
* 「フェイルオーバー」の取り扱いのための仕様の追加。
* Revision of the section on race conditions.
* 競合条件におけるセクションの改正。
7.6. The making of MGCP from IPDC and SGCP
7.6. IPDCとSGCPからのMGCPの作成
MGCP version 0.1 results from the fusion of the SGCP and IPDC proposals.
MGCPバージョン0.1はSGCPとIPDC提案の溶融から生じます。
7.7. Changes between MGCP and initial versions of SGCP
7.7. SGCPのMGCPと初期のバージョンの間の変化
MGCP version 0.1 (which subsumes SGCP version 1.2) introduces the following changes from SGCP version 1.1:
MGCPバージョン0.1(SGCPバージョン1.2を包括します)はSGCPバージョン1.1からの以下の変化を導入します:
* Protocol name changed to MGCP.
* プロトコル名はMGCPに変化しました。
* Introduce a formal wildcarding structure in the name of endpoints,
inspired from IPDC, and detailed the usage of wildcard names in
each operation.
* IPDCから奮い立たせられた終点の名にかけて正式なwildcarding構造を紹介して、各操作でワイルドカード名の用法を詳しく述べました。
* Naming scheme for events, introducing a package structure inspired
from IPDC.
* イベントの体系を命名して、パッケージ構造を紹介するのはIPDCから奮い立たせられました。
* New operations for audit endpoint, audit connection (requested by
the Cablelabs) and restart (inspired from IPDC).
* 監査終点のための新しい操作、監査接続(Cablelabsによって要求されている)、および再開(IPDCから、奮い立たせられます)。
* New parameter to control the behavior of the notification request.
* 通知要求の振舞いを制御する新しいパラメタ。
* Improved text on the detection and handling of race conditions.
* 競合条件の検出と取り扱いに関する改良されたテキスト。
Arango, et al. Informational [Page 126] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[126ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
* Syntax modification for event reporting, to incorporate package
names.
* イベントのための構文変更が報告して、盛込むために、名前をパッケージしてください。
* Definition of basic event packages (inspired from IPDC).
* 基本的なイベントパッケージ(IPDCから、奮い立たせられる)の定義。
* Incorporation of mandatory and optional extension parameters,
inspired by IPDC.
* IPDCによって奮い立たせられた義務的で任意の拡大パラメタの編入。
SGCP version 1.1 introduces the following changes from version SGCP
1.0:
SGCPバージョン1.1はSGCP1.0にバージョンからの以下の変化を導入します:
* Extension parameters (X-??:)
* 拡大パラメタ(X?:、)
* Error Code 511 (Unrecognized extension).
* 誤りCode511(認識されていない拡大)。
* All event codes can be used in RequestEvent, SignalRequest and
ObservedEvent parameters.
* RequestEvent、SignalRequest、およびObservedEventパラメタですべてのイベントコードを使用できます。
* Error Code 512 (Not equipped to detect requested event).
* 誤りCode512(要求されたイベントを検出するために、備えられていません)。
* Error Code 513 (Not equipped to generate requested signal).
* 誤りCode513(要求された信号を生成するために、備えられていません)。
* Error Code 514 (Unrecognized announcement).
* 誤りCode514(認識されていない発表)。
* Specific Endpoint-ID can be returned in creation commands.
* 作成コマンドで特定のEndpoint-IDを返すことができます。
* Changed the code for the ASDI display from "ad" to "asdi" to avoid
conflict with the digits A and D.
* 「広告」から"asdi"までのASDIディスプレイがケタAとDとの闘争を避けるように、コードを変えました。
* Changed the code for the answer tone from "at" to "aw" to avoid
conflict with the digit A and the timer mark T
* 変えて、“at"から"aw"までの答えトーンがケタAとの闘争を避けるコードとタイマはTをマークします。
* Changed the code for the busy tone from "bt" to "bz" to avoid
conflict with the digit B and the timer mark T
* 変えて、"bt"から"bz"までの話中音がケタBとの闘争を避けるコードとタイマはTをマークします。
* Specified that the continuity tone value is "co" (CT was
incorrectly used in several instances; CT conflicts with .)
* 連続トーン価値がそうであると指定する、「共同、」(コネチカットはいくつかのインスタンスに不当に使用されました; コネチカットは衝突します。)
* Changed the code for the dial tone from "dt" to "dl" to avoid
conflict with the digit D and the timer mark T
* 変えて、"dt"から「dl」までのダイヤルトーンがケタDとの闘争を避けるコードとタイマはTをマークします。
* Added a code point for announcement requests.
* 発表要求のためにコード・ポイントを加えました。
* Added a code point for the "wink" event.
* 「ウインク」イベントのためにコード・ポイントを加えました。
* Set the "octet received" code in the "Connection Parameters" to
"OR" (was set to RO, but then "OR" was used throughout all
examples.)
* 「OR」への「接続パラメタ」に「八重奏受け取られていている」コードをはめ込んでください。(次に、RO、「OR」へのセットがすべての例中で使用されたということでした。)
Arango, et al. Informational [Page 127] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[127ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
* Added a "data" mode.
* 「データ」モードを加えました。
* Added a description of SDP parameters for the network access mode
(NAS).
* ネットワークアクセス・モード(NAS)のためのSDPパラメタの記述を加えました。
* Added four flow diagrams for the network access mode.
* ネットワークのための4つの付記されたフローチャートがモードにアクセスします。
* Incorporated numerous editing suggestions to make the description
easier to understand. In particular, cleared the confusion between
requests, queries, functions and commands.
* 記述を理解しているのをより簡単にする法人組織の頻繁な編集提案。 クリアされて、要求の間の混乱(質問)は、特に、機能して、命令します。
* Defined the continuity test mode as specifying a dual-tone
transponder, while the loopback mode can be used for a single tone
test.
* シングル・トーンテストにループバックモードを使用できる間、二元的なトーントランスポンダーを指定すると連続テスト・モードを定義しました。
* Added event code "OC", operation completed.
* 操作は、加えられたイベントコード"OC"と完成しました。
* Added the specification of the "quarantine list", which clarifies
the expected handling of events and notifications.
* イベントと通知の予想された取り扱いをはっきりさせる「隔離リスト」の仕様を加えました。
* Added the specification of a "wildcard delete" operation.
* aの仕様を加える、「ワイルドカードは」 操作を削除します。
8. Security Considerations
8. セキュリティ問題
Security issues are discussed in section 5.
セクション5で安全保障問題について議論します。
9. Acknowledgements
9. 承認
We want to thank here the many reviewers who provided us with advice on the design of SGCP and then MGCP, notably Flemming Andreasen, Sankar Ardhanari, Francois Berard, David Auerbach, Bob Biskner, David Bukovinsky, Jerry Kamitses, Oren Kudevitzki, Barry Hoffner, Troy Morley, Dave Oran, Jeff Orwick, John Pickens, Lou Rubin, Chip Sharp, Paul Sijben, Kurt Steinbrenner, Joe Stone and Stuart Wray.
ここで、SGCP、次に、MGCP、著しくフレミングAndreasen、Sankar Ardhanari、フランソアBerard、デヴィッド・アウアーバック、ボブBiskner、デヴィッドBukovinsky、ジェリーKamitses、オレンKudevitzki、バリーHoffner、トロイモーレイ、デーヴ・オランジェフOrwick、ジョン・ピケンズ、ルウ・ルービン、Chipシャープ、ポールSijben、カート・スタインブレナー、ジョー・ストーン、およびスチュアート・レイのデザインに関するアドバイスを私たちに提供した多くの評論家に感謝申し上げます。
The version 0.1 of MGCP is heavily inspired by the "Internet Protocol Device Control" (IPDC) designed by the Technical Advisory Committee set up by Level 3 Communications. Whole sets of text have been retrieved from the IP Connection Control protocol, IP Media Control protocol, and IP Device Management. The authors wish to acknowledge the contribution to these protocols made by Ilya Akramovich, Bob Bell, Dan Brendes, Peter Chung, John Clark, Russ Dehlinger, Andrew Dugan, Isaac Elliott, Cary FitzGerald, Jan Gronski, Tom Hess, Geoff Jordan, Tony Lam, Shawn Lewis, Dave Mazik, Alan Mikhak, Pete O'Connell, Scott Pickett, Shyamal Prasad, Eric Presworsky, Paul Richards, Dale Skran, Louise Spergel, David Sprague, Raj Srinivasan, Tom Taylor and Michael Thomas.
MGCPのバージョン0.1はLevelによってセットアップされたTechnical Advisory Committeeによって設計された「インターネットプロトコル装置制御」(IPDC)3Communicationsによって大いに奮い立たせられます。 IP Connection Controlプロトコル、IPメディアControlプロトコル、およびIP Device Managementからテキストの全体集合を検索してあります。 作者はイリヤAkramovich、ボブ・ベル、ダンBrendes、ピーター・チャン、ジョン・クラーク、ラスDehlinger、アンドリュー・デュガン、イサク・エリオット、ケーリーFitzGerald、ジャンGronski、トム・ヘス、ジェフ・ジョーダン、トニー・ラム、ショーン・ルイス、デーヴMazik、アランMikhak、ピートオコネル、スコット・ピケット、Shyamalプラサード、エリックPresworsky、ポール・リチャーズ、デールSkran、ルイーズSpergel、デヴィッド・スプレーグ、Raj Srinivasan、トム・テイラー、およびマイケル・トーマスによって作られたこれらのプロトコルへの貢献を承諾したがっています。
Arango, et al. Informational [Page 128] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[128ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
10. References
10. 参照
* Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications", RFC 1889,
January 1996.
* Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
* Schulzrinne, H., "RTP Profile for Audio and Video Conferences with
Minimal Control", RFC 1890, January 1996.
* Schulzrinne、H.、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC1890、1996年1月。
* Handley, M and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
* ハンドレー、M、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
* Handley, M., "SAP - Session Announcement Protocol", Work in
Progress.
* 「SAP--セッション発表は議定書を作ります」。ハンドレー、M.、仕事進行中です。
* Handley, M., Schulzrinne, H. and E. Schooler, "Session Initiation
Protocol (SIP)", RFC 2543, March 1999.
* ハンドレーとM.とSchulzrinneとH.とE.学生、「セッション開始プロトコル(一口)」、RFC2543、1999年3月。
* Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
* SchulzrinneとH.とラオとA.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」、RFC2326 1998年4月。
* ITU-T, Recommendation Q.761, "FUNCTIONAL DESCRIPTION OF THE ISDN
USER PART OF SIGNALLING SYSTEM No. 7", (Malaga-Torremolinos, 1984;
modified at Helsinki, 1993)
* ITU-T、推薦Q.761、「合図システムNo.7インチのISDNユーザ部分の機能的な記述」(マラガ-トレモリノス、1984; ヘルシンキ、1993年に変更されます)
* ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF MESSAGES AND
SIGNALS OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 7",
(MalagaTorremolinos, 1984; modified at Helsinki, 1993)
* ITU-T、推薦Q.762、「そして、ISDNユーザの信号が合図システムNo.7インチを離れさせるというメッセージの一般的な機能」(MalagaTorremolinos、1984; ヘルシンキ、1993年に変更されます)
* ITU-T, Recommendation H.323 (02/98), "PACKET-BASED MULTIMEDIA
COMMUNICATIONS SYSTEMS."
* ITU-T、推薦H.323(02/98)、「パケットベースのマルチメディア通信システム。」
* ITU-T, Recommendation H.225, "Call Signaling Protocols and Media
Stream Packetization for Packet Based Multimedia Communications
Systems."
* ITU-T、推薦H.225は「パケットのベースのマルチメディア通信システムのためにシグナリングプロトコルとメディアをストリームPacketizationと呼びます」。
* ITU-T, Recommendation H.245 (02/98), "CONTROL PROTOCOL FOR
MULTIMEDIA COMMUNICATION."
* ITU-T、推薦H.245(02/98)は「マルチメディア通信のためにプロトコルを制御します」。
* Kent, S. and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
* ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
* Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
* ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
* Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
* ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
Arango, et al. Informational [Page 129] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[129ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
* Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
* クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
11. Authors' Addresses
11. 作者のアドレス
Mauricio Arango RSL COM Latin America 6300 N.W. 5th Way, Suite 100 Ft. Lauderdale, FL 33309
6300北西第5道、スイート100フィートのマウリシオArango RSL COMラテンアメリカ ローダーデイル、フロリダ 33309
Phone: (954) 492-0913 EMail: marango@rslcom.com
以下に電話をしてください。 (954) 492-0913 メールしてください: marango@rslcom.com
Andrew Dugan Level3 Communications 1450 Infinite Drive Louisville, CO 80027
アンドリューデュガンLevel3Communications1450の無限のドライブルイビル、CO 80027
Phone: (303)926 3123 EMail: andrew.dugan@l3.com
以下に電話をしてください。 (303)926 3123はメールされます: andrew.dugan@l3.com
Isaac Elliott Level3 Communications 1450 Infinite Drive Louisville, CO 80027
イサクエリオットLevel3Communications1450の無限のドライブルイビル、CO 80027
Phone: (303)926 3123 EMail: ike.elliott@l3.com
以下に電話をしてください。 (303)926 3123はメールされます: ike.elliott@l3.com
Arango, et al. Informational [Page 130] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[130ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
Christian Huitema Telcordia Technologies MCC 1J236B 445 South Street Morristown, NJ 07960 U.S.A.
クリスチャンのHuitema Telcordia Technologies MCC 1J236B445の南通りモリスタウン(ニュージャージー)07960米国
Phone: +1 973-829-4266 EMail: huitema@research.telcordia.com
以下に電話をしてください。 +1 973-829-4266 メールしてください: huitema@research.telcordia.com
Scott Pickett Vertical Networks 1148 East Arques Ave Sunnyvale, CA 94086
スコットピケット垂直なネットワーク1148の東Arques Aveサニーベル(カリフォルニア)94086
Phone: (408) 523-9700 extension 200 EMail: ScottP@vertical.com
以下に電話をしてください。 (408) 523-9700 拡大200EMail: ScottP@vertical.com
Further information is available on the SGCP web site:
詳細はSGCPウェブサイトで利用可能です:
http://www.argreenhouse.com/SGCP/
http://www.argreenhouse.com/SGCP/
Arango, et al. Informational [Page 131] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[131ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
12. Appendix A: Proposed "MoveConnection" command
12. 付録A: 提案された"MoveConnection"コマンド
It has been proposed to create a new command, that would move an existing connection from one endpoint to another, on the same gateway. This command would be specially useful for handling certain call services, such as call forwarding between endpoints served by the same gateway.
それは新しいコマンドを作成するために提案されて、それは既存の1つの終点から別の終点までの接続を動かすでしょう、同じゲートウェイの上で。 特に、このコマンドは終点の間の自動転送などの呼び出しサービスが同じゲートウェイのそばで役立ったのを確信している取り扱いの役に立つでしょう。
[SecondEndPointId,]
[ConnectionId,]
[LocalConnectionDescriptor]
<--- ModifyConnection(CallId,
EndpointId,
ConnectionId,
SecondEndPointId,
[NotifiedEntity,]
[LocalConnectionOptions,]
[Mode,]
[RemoteConnectionDescriptor,]
[Encapsulated NotificationRequest,]
[Encapsulated EndpointConfiguration])
[SecondEndPointId] [ConnectionId][LocalConnectionDescriptor]<。--- ModifyConnection(CallId、EndpointId、ConnectionId、SecondEndPointId[NotifiedEntity][LocalConnectionOptions][モード][RemoteConnectionDescriptor][NotificationRequestであるとカプセル化されます][EndpointConfigurationであるとカプセル化されます])
The parameters used are the same as in the ModifyConnection command, with the addition of a SecondEndpointId that identifies the endpoint towards which the connection is moved.
使用されるパラメタはModifyConnectionコマンドと同じです、接続が動かされる終点を特定するSecondEndpointIdの追加で。
The EndpointId should be the fully qualified endpoint identifier of the endpoint on which the connection has been created. The local name shall not use the wildcard convention.
EndpointIdは接続が創造された終点の完全に適切な終点識別子であるべきです。 地方名はワイルドカードコンベンションを使用しないものとします。
The SecondEndpointId shall be the endpoint identifier of the endpoint towards which the connection has been created. The "any of" wildcard convention can be used, but not the "all of" convention. If the SecondEndpointId parameter is unqualified, the gateway will choose a value, that will be returned to the call agent as a response parameter.
SecondEndpointIdは接続が創造された終点に関する終点識別子になるでしょう。 「しかし、」 ワイルドカードに、いくらか、コンベンションを使用できる、「」 コンベンションのすべて。 ゲートウェイは、SecondEndpointIdパラメタが資格がないならそれが応答パラメタとして呼び出しエージェントに返されるのを値を選ぶでしょう。
The command will result in the "move" of the existing connection to the second endpoint. Depending on gateway implementations, the connection identifier of the connection after the move may or may not be the same as the connection identifier before the move. If it is not the same, the new value is returned as a response parameter.
コマンドは2番目の終点との既存の接続の「移動」をもたらすでしょう。 ゲートウェイ実装によって、移動の後の接続の接続識別子は移動の前に接続識別子と同じであるかもしれません。 それが同じでないなら、応答パラメタとして新しい値を返します。
The intent of the command is to effect a local relocation of the connection, without having to modify such transmission parameters as IP addresses and port, and thus without forcing the call agent to signal the change of parameters to the remote gateway, at the other
コマンドの意図はIPが扱うようなトランスミッションパラメタとポートを変更しなければならないことなしでその結果、呼び出しエージェントにリモートゲートウェイへのパラメタの変化を合図させることなしで接続の地方の再配置に作用することです、もう片方で
Arango, et al. Informational [Page 132] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[132ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
end of the connection. However, gateway architectures may not always allow such transparent moves. For example, some architectures could allow specific IP addresses to different boards that handles specific group of endpoints. If for any reason the transmission parameters have to be changed as a result of the move, the new LocalConnectionDescriptor is returned as a response parameter.
接続の終わり。 しかしながら、ゲートウェイアーキテクチャはいつもそのようなわかりやすい移動を許すかもしれないというわけではありません。 例えば、いくつかのアーキテクチャが終点の特定のグループを扱う異なったボードに特定のIPアドレスを許容するかもしれません。 どんな理由でも移動の結果、トランスミッションパラメタを変えなければならないなら、応答パラメタとして新しいLocalConnectionDescriptorを返します。
The LocalConnectionOptions, Mode, and RemoteConnectionDescriptor, when present, are applied after the move.
LocalConnectionOptions、Mode、およびRemoteConnectionDescriptor、現在のいつが移動の後に適用されるか。
The RequestedEvents, RequestIdentifier, DigitMap, SignalRequests, QuarantineHandling and DetectEvents parameters are optional. They can be used by the Call Agent to transmit a NotificationRequest that is executed simultaneously with the move of the connection. When these parameters are present, the NotificationRequest applies to the second endpoint.
RequestedEvents、RequestIdentifier、DigitMap、SignalRequests、QuarantineHandling、およびDetectEventsパラメタは任意です。 Callエージェントは、同時に接続の移動で実行されるNotificationRequestを伝えるのにそれらを使用できます。 これらのパラメタが存在しているとき、NotificationRequestは2番目の終点に適用します。
When these parameters are present, the move and the NotificationRequests should be synchronized, which means that both should be accepted, or both refused. The NotifiedEntity parameter, if present, applies to both the ModifyConnection and the NotificationRequest command.
これらのパラメタが存在しているとき、移動とNotificationRequestsは同時にするべきです(両方を受け入れるべきであったか、または両方が拒否したことを意味します)。 存在しているなら、NotifiedEntityパラメタはModifyConnectionとNotificationRequestコマンドの両方に適用されます。
The command may carry an encapsulated EndpointConfiguration command, that will also apply to the second endpoint. When this command is present, the parameters of the EndpointConfiguration command are inserted after the normal parameters of the MoveConnection with the exception of the SecondEndpointId, which is not replicated. The End- pointConfiguration command may be encapsulated together with an encapsulated NotificationRequest command.
コマンドはカプセル化されたEndpointConfigurationコマンドを運ぶかもしれません、また、それが2番目の終点に当てはまるでしょう。 このコマンドが存在しているとき、SecondEndpointIdを除いて、EndpointConfigurationコマンドのパラメタはMoveConnectionの正常なパラメタの後に挿入されます。(SecondEndpointIdは模写されません)。 End- pointConfigurationコマンドはカプセル化されたNotificationRequestコマンドと共にカプセル化されるかもしれません。
The encapsulated EndpointConfiguration command shares the fate of the MoveConnection command. If the MoveConnection is rejected, the End- pointConfiguration is not executed.
カプセル化されたEndpointConfigurationコマンドはMoveConnectionコマンドの運命を共有します。 MoveConnectionが拒絶されるなら、End- pointConfigurationは実行されません。
12.1. Proposed syntax modification
12.1. 提案された構文変更
The only syntax modification necessary for the addition of the moveConnection command is the addition of the keyword MOVE to the authorized values in the MGCPVerb clause of the formal syntax.
moveConnectionコマンドの追加に必要な唯一の構文変更が正式な構文のMGCPVerb節の認可された値へのキーワードMOVEの追加です。
Arango, et al. Informational [Page 133] RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Arango、他 情報[133ページ]のRFC2705メディアゲートウェイ制御プロトコル(MGCP)1999年10月
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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機能のための基金は現在、インターネット協会によって提供されます。
Arango, et al. Informational [Page 134]
Arango、他 情報[134ページ]
一覧
スポンサーリンク
