Internet Engineering Task Force (IETF) J. Stone
Request for Comments: 6498 R. Kumar
Category: Informational F. Andreasen
ISSN: 2070-1721 Cisco Systems
February 2012
Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package
メディアゲートウェイコントロールプロトコル（MGCP）音声帯域データ（VBD）パッケージと汎用メディア記述子パラメータパッケージ
Abstract
抽象
This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from Voiceband Data (VBD) with or without redundancy and FEC (forward error correction). Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec. In addition to defining these new packages, this document describes the use of the Media Format Parameter package and Fax package with VBD, redundancy, and FEC.
この文書では、とや、冗長性とFEC（前方誤り訂正）のない音声帯域データ（VBD）へとからの接続の移行を承認し、監視するためのコールエージェントを有効メディアゲートウェイコントロールプロトコル（MGCP）パッケージを定義します。フォーカスがVBD上ではあるが、汎用メディア記述子パラメータパッケージには、特定のコーデックのための他の動作モードではなく、VBDに関連し、許可するために使用することができます。これらの新しいパッケージを定義するだけで、この文書はVBD、冗長性、およびFECとメディアフォーマットのパラメータパッケージとファックスパッケージの使用を記載しています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6498.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6498で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Applicability Statement .........................................3
2. Introduction ....................................................3
3. Terminology .....................................................5
4. Voiceband Data Package Definition ...............................5
4.1. Events and Signals .........................................5
4.1.1. Gateway Controlled Voiceband Data ...................6
4.1.2. No Negotiated Procedure for Voiceband Data .........13
5. General-Purpose Media Descriptor Parameter Package Definition ..16
5.1. LocalConnectionOptions ....................................16
5.1.1. General-Purpose Media Descriptor Parameter .........17
6. Use of Media Format Parameter Package with VBD and Redundancy ..20
7. Use of Media Format Parameter Package with VBD and FEC .........22
8. Use of Fax Package with VBD ....................................23
9. Call Flow Examples .............................................27
9.1. Modem Call with Gateway Controlled VBD ....................27
9.2. Fax Call with Gateway Controlled VBD and Call
Agent Controlled T.38 .....................................33
10. Security Considerations .......................................42
11. IANA Considerations ...........................................44
12. Acknowledgements ..............................................44
13. References ....................................................44
13.1. Normative References .....................................44
13.2. Informative References ...................................46
This document defines a mechanism that requires media stream integrity protection. The document specifies different alternative mechanisms but does not choose one of them as mandatory-to-implement. Consequently, the use of this specification is only suitable in environments that specify and use at least one of these alternative mechanisms. Please see the Security Considerations section for further details.
この文書では、メディアストリームの整合性の保護を必要とするメカニズムを定義します。文書には、さまざまな代替メカニズムを指定しますが、実装に必須の、それらのいずれかを選択していません。したがって、本明細書の使用は、これらの代替の機構のうちの少なくとも一つを指定し、使用する環境にのみ適しています。詳細については、セキュリティの考慮事項のセクションを参照してください。
The term Voiceband Data (or simply VBD) refers to the use of a suitable voiceband codec (commonly G.711u or G.711a) for the transport of data payloads using RTP as defined in RFC 3550 [RFC3550]. This document defines Media Gateway Control Protocol (MGCP) [RFC3435] packages that enable a Call Agent to authorize and monitor the transition of a connection to and from VBD with or without redundancy [RFC2198] and FEC (forward error correction) [RFC5109].
RFC 3550 [RFC3550]で定義される用語音声帯域データ（又は単にVBD）は、RTPを使用してデータペイロードの輸送に適した音声帯域コーデック（一般的にG.711uまたはG.711A）の使用を指します。この文書では、メディアゲートウェイコントロールプロトコル（MGCP）[RFC3435]の冗長性の有無にかかわらずVBDへとからの接続の移行を承認し、監視するためのコールエージェントを有効パッケージ[RFC2198]とFEC（前方誤り訂正）[RFC5109]を定義します。
There are a number of different VBD procedures. These procedures vary in terms of how the transition to and from VBD is coordinated end to end. Some coordination techniques are mutually negotiated by the two gateways using the Session Description Protocol (SDP) [RFC4566]. These coordination techniques include
異なるVBD手順の数があります。これらの手順は、VBDおよびからの移行が端と端を配位される方法の点で異なります。いくつかの協調技術が互いにセッション記述プロトコル（SDP）[RFC4566]を使用して2つのゲートウェイによってネゴシエートされます。これらの調整技術には、
o ITU-T Recommendation V.150.1 State Signaling Event (SSE) [V1501]
ITU-T勧告V.150.1状態シグナリングイベント（SSE）[V1501] O
o ITU-T Recommendation V.152 Payload Type Switching [V152]
O ITU-T勧告V.152ペイロードタイプ切り替え[V152]
Other coordination techniques are not negotiated. For example, the detection of fax, modem, and text tones in the direction from the IP to the General Switched Telephone Network (GSTN) may result in a switch to VBD or a change (e.g., disable echo cancellation) to the gateway controlled VBD procedure already in place. The IP-side detected tone serves as both a VBD stimulus and a coordination technique.
その他の調整技術が交渉されていません。例えば、一般的にIPからの方向にファックス、モデム、およびテキストトーンの検出は、ゲートウェイ制御VBD（例えば、エコーキャンセルを無効）電話網（GSTN）はVBDにスイッチまたは変化をもたらすことができるスイッチ代わりに、すでに手続き。 IP側検出されたトーンは、VBD刺激と協調技術の両方として機能します。
RFC 4733 [RFC4733] and RFC 4734 [RFC4734] can be used to convey fax and modem events and tones. As with IP-side tone detection, the telephone event may serve as both a VBD stimulus and a coordination technique. Note that while the use of RFC 4733 and RFC 4734 to convey fax and modem events and tones is negotiated, the use of RFC 4733 and RFC 4734 as a gateway VBD coordination technique (at present) is not.
RFC 4733 [RFC4733]及びRFC 4734 [RFC4734]は、ファックス、モデムイベントとトーンを伝達するために使用することができます。 IP側のトーン検出と同様に、電話イベントはVBD刺激と協調技術の両方として働くことができます。ファックス、モデムイベントとトーンを搬送するRFC 4733及びRFC 4734の使用をネゴシエートしている間、（現時点で）ゲートウェイVBDコーディネーション技術としてRFC 4733及びRFC 4734の使用がないことに留意されたいです。
The Voiceband Data (VBD) package is defined to support all VBD procedures. This document does not address the relative merits of different procedures nor does it advocate one procedure over another.
音声帯域データ（VBD）パッケージは、すべてのVBDの手続きをサポートするために定義されています。この文書では、異なる手順の相対的なメリットに対処しておらず、別の上に1つの手順を提唱ありません。
We will use the term VBD to refer to Voiceband Data in general. In referring to VBD in the context of the package, we will use the term VBD package. We use the term "audio" (with double quotes) to refer to the IANA media type. We use the term audio (without double quotes) to refer to the use of the "audio" media type for (most commonly) voice.
私たちは、一般的には音声帯域データを参照するために用語のVBDを使用します。パッケージのコンテキストでVBDを参照するには、我々は、用語VBDパッケージを使用します。私たちは、IANAメディアタイプを参照するために（二重引用符付き）用語「オーディオ」を使用します。私たちは、（最も一般的に）声のための「オーディオ」メディアタイプの使用を参照するために（二重引用符なし）用語のオーディオを使用しています。
A package is defined for the General-Purpose Media Descriptor Parameter [V152]. In the context of VBD, the General-Purpose Media Descriptor Parameter (GPMD) package is used to authorize the negotiation of a particular codec for use with VBD. The General-Purpose Media Descriptor Parameter is "general" in nature and may be used in applications other than VBD.
パッケージは、汎用メディア記述子パラメータ[V152]のために定義されています。 VBDの文脈では、汎用メディア記述子パラメータ（GPMD）パッケージは、VBDで使用するために特定のコーデックの交渉を許可するために使用されます。汎用メディア記述子パラメータは、自然の中で、「一般的」であるとVBD以外の用途に使用することができます。
The Media Format Parameter (FM) package [RFC3660] describes the use of the standard audio MIME subtype "RED" in conjunction with the "fmtp" LocalConnectionOption in order to authorize the negotiation of redundancy [RFC2198], to identify the levels of redundancy and the
Media形式のパラメータ（FM）パッケージ[RFC3660]は、冗長性のレベルを識別するために、冗長性[RFC2198]の交渉を許可するために、「のfmtp」LocalConnectionOptionと併せて標準的なオーディオMIMEサブタイプ「RED」の使用を説明し、インクルード
media format associated with each redundancy level. This document will further explore the use of the FM package with VBD and redundancy.
各冗長レベルに関連付けられたメディアフォーマット。この文書では、さらにVBDと冗長性を備えたFMパッケージの使用を検討します。
The VBD package is intended to complement the MGCP Fax (FXR) package [RFC5347]. This document will explore the use of the FXR package with VBD.
VBDパッケージはMGCPファックス（FXR）パッケージ[RFC5347]を補完することを意図しています。この文書では、VBDとFXRパッケージの使用を検討します。
The VBD package definition is provided in Section 4. The GPMD package definition is provided in Section 5. In Section 6, we discuss the use of the FM package with VBD and redundancy. In Section 7, we discuss the use of the FM package with VBD and FEC. In Section 8, we discuss the use of the FXR package with VBD. In Section 9, we provide two call flow examples showing how to use the VBD and GPMD packages. Security considerations are found in Section 10, followed by the IANA considerations (Section 11) and references.
VBDパッケージ定義はセクション4で提供されGPMDパッケージ定義は、我々がVBDと冗長性を備えたFMパッケージの使用を議論し、6章では第5節で提供されています。第7節では、VBDとFECとFMパッケージの使用を議論します。第8章では、我々は、VBDとFXRパッケージの使用を議論します。第9章では、我々は、VBDとGPMDパッケージを使用する方法を示す2つのコールフローの例を示します。セキュリティの考慮事項は、IANAの考慮事項（第11条）との言及に続いて、第10節に記載されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
This package is defined for Voiceband Data (VBD). The package defines new events as detailed below.
このパッケージは、音声帯域データ（VBD）のために定義されています。パッケージには、下記のとおり、新しいイベントを定義します。
Package Name: VBD
パッケージ名：VBD
Package Version: 0
パッケージバージョン：0
The following events are defined in support of the above:
次のイベントは、上記のサポートで定義されています。
-------------------------------------------------------------------
| Symbol | Definition | R | S | Duration |
|--------|---------------------------------|-----|-----|------------|
| gwvbd | Gateway Controlled VBD | x | | |
| nopvbd | No Negotiated Procedure for VBD | x | | |
-------------------------------------------------------------------
This is standard MGCP package format as defined in Section 6.6 of RFC 3435 [RFC3435]. The definitions of the individual events are provided in the following subsections.
RFC 3435のセクション6.6 [RFC3435]で定義されるように、これは、標準的なMGCPパッケージ形式です。個々のイベントの定義は、以下のサブセクションで提供されています。
The gwvbd procedure can be used by the gateway to control and decide how to handle VBD calls without Call Agent involvement. The "Gateway Controlled Voiceband Data" (or simply "gwvbd") event occurs when a gwvbd procedure has been negotiated and VBD stimulus is detected. The "gwvbd" event may occur when the gwvbd procedure is updated (e.g., upon detecting new stimulus) and when the procedure fails. The "gwvbd" event occurs when the gwvbd procedure ends. The gwvbd procedure MUST be negotiated with the other side by passing and recognizing relevant parameters via the LocalConnectionDescriptor and RemoteConnectionDescriptor.
制御し、VBDの処理方法を決定するためにゲートウェイで使用することができgwvbd手順は、コールエージェントの関与なしで呼び出します。 「ゲートウェイは、音声帯域データを制御された」（または単に「gwvbd」）gwvbd手順がネゴシエートされ、VBD刺激が検出されたときにイベントが発生します。 gwvbd手順が更新されたときに（例えば、新たな刺激を検出する）と手順が失敗したときに「gwvbd」イベントが発生する可能性があります。 gwvbd手続きが終了したときに「gwvbd」イベントが発生します。 gwvbd手順はLocalConnectionDescriptorとRemoteConnectionDescriptorを介して関連するパラメータを渡すことと認識して他方の側と交渉しなければなりません。
The following recommendations from MGCP [RFC3435] apply.
MGCPから以下の提言[RFC3435]適用されます。
In this section, we provide a formal description of the protocol syntax, using ABNF as defined in "Augmented BNF for Syntax Specifications: ABNF" [RFC5234]. The syntax makes use of the core rules defined in Appendix B.1 of [RFC5234], which are not included here. Furthermore, the syntax follows the case-sensitivity rules of [RFC5234], i.e., MGCP is case-insensitive (but SDP is not). It should be noted that ABNF does not provide for implicit specification of linear white space, and MGCP messages MUST thus follow the explicit linear white space rules provided in the grammar below. However, in line with general robustness principles, implementers are strongly encouraged to tolerate additional linear white space in messages received.
[RFC5234]：このセクションでは、我々は「ABNF構文仕様のための増大しているBNF」で定義されたABNFを使用して、プロトコル構文の正式な説明を提供します。構文はここに含まれていないの付録B.1 [RFC5234]で定義されたコア規則を利用します。さらに、構文、すなわち、MGCPは、大文字小文字を区別しない（ただし、SDPではない）、[RFC5234]の大文字と小文字の区別ルールに従います。 ABNFは、リニアホワイトスペースの暗黙の仕様を提供しない、とMGCPメッセージは、このように、以下の文法で提供明示的な線形空白のルールに従わなければならないことに留意すべきです。しかし、一般的な堅牢性の原則に沿って、実装者が強く受信されたメッセージに追加リニアホワイトスペースを容認することをお勧めします。
The RequestedEvent parameter is encoded as
RequestedEventパラメータは以下のように符号化されます
GwVbdReqEvent = "gwvbd"
GwVbdReqEventは= "gwvbd"
The ObservedEvent parameter is encoded as
ObservedEventパラメータは以下のように符号化されます
GwVbdObsEvent = GwVbdObsEventStart / GwVbdObsEventUpdate / GwVbdObsEventStop / GwVbdObsEventFailure
GwVbdObsEvent = GwVbdObsEventStart / GwVbdObsEventUpdate / GwVbdObsEventStop / GwVbdObsEventFailure
GwVbdObsEventStart = "gwvbd(start" Rc [Codec] [Coord] [Dir] ")" GwVbdObsEventUpdate = "gwvbd(update" Rc [Codec] [Dir] ")" GwVbdObsEventStop = "gwvbd(stop" [Rc] [Codec] ")" GwVbdObsEventFailure = "gwvbd(failure" [Rc] [Codec] ")"
GwVbdObsEventStartは= GwVbdObsEventUpdate = "gwvbd（アップデート" RC [コーデック] [DIR] "）" GwVbdObsEventStop = "gwvbd（停止" [RC] [コーデック] "（RC [コーデック] [COORD] [ディレクトリ]をgwvbd開始" "）" "）" GwVbdObsEventFailure = "gwvbd（失敗" [RC] [コーデック] "）"
Codec = "," *WSP "codec=" CodecString CodecString = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-" / "_" / "." / "/") Coord = "," *WSP "coord=" CoordinationTechnique CoordinationTechnique = "v152ptsw" / "v150fw" Rc = "," *WSP "rc=" ReasonCode ReasonCode = 1*(ALPHA / DIGIT / "-" / "_" / "." / "/") ; Refer to the values listed in the tables below. Dir = "," *WSP "dir=" Direction Direction = "GstnToIp" / "IpToGstn"
コーデック= "" * WSP "コーデック=" CodecString CodecString =（ALPHA / DIGIT）*（ALPHA / DIGIT / " - " "" / "_" / / "/"）COORD = "" * WSP「COORD = "CoordinationTechnique CoordinationTechnique = "v152ptsw"/ "v150fw" RC ="、 "* WSP "RC =" reasonCodeはreasonCodeは= 1 *（ALPHA / DIGIT / " - "/ "_"/"「/ "/"）;以下の表に記載されている値を参照してください。 DIR = "" * WSP "DIR =" 方向方向= "GstnToIp" / "IpToGstn"
ABNF does not provide for position-independent parameters. The "rc", "codec", "coord", and "dir" parameters, if present, MUST appear in the relative order shown.
ABNFは位置独立なパラメータを提供しません。存在する場合、「RC」、「コーデック」、「COORD」、および「DIR」パラメータは、示される相対的な順序で現れなければなりません。
The "start", "update", "stop", and "failure" ObservedEvent parameters are defined as follows:
「スタート」、「更新」、「停止」、および以下のように「失敗」ObservedEventパラメータが定義されています。
1) VBD Start (start)
1）VBDを起動（開始）
The gwvbd procedure was initiated. The Call Agent SHOULD refrain from issuing media handling instructions to the gateway until either a "gwvbd(stop)" or "gwvbd(failure)" event is generated. One and only one "gwvbd(stop)" or "gwvbd(failure)" event is generated corresponding to each "gwvbd(start)" event.
gwvbd手続きを開始しました。いずれかの「gwvbd（停止）」または「gwvbd（失敗）」イベントが発生するまでのコールエージェントは、ゲートウェイに指示を扱うメディアの発行を控えるべきです。唯一つの「gwvbd（停止）」または「gwvbd（失敗）」イベントは、各「gwvbd（開始）」イベントに対応して生成されます。
2) VBD Update (update)
2）VBDアップデート（更新）
The gwvbd procedure was updated. The "gwvbd(update)" event MUST only be generated after a "gwvbd(start)" event and before a "gwvbd(stop)" or "gwvbd(failure)" event.
gwvbd手順を更新しました。 「gwvbd（更新）」イベントは、「gwvbd（スタート）」イベントと「gwvbd（停止）」または「gwvbd（失敗）」イベントの前後に生成されなければなりません。
3) VBD Stop (stop)
3）VBD停止（停止）
The gwvbd procedure ended, and the gateway did not detect any errors. Note that this does not necessarily imply a successful fax, modem, or text transmission. It merely indicates that the gwvbd procedure has ended and the procedure itself did not encounter any errors. The "stop" parameter may correspond to a change from VBD to a non-VBD "audio" codec or from VBD to another media type such as "image" or "text". This change may be under Call Agent or gateway control. For example, the gateway may coordinate the switch from VBD to "image/t38" through the exchange of SSEs [T38] [V152]. For an example involving Call Agent control, refer to the "MC" Reason Code. In both examples, the gwvbd procedure ends with the media change.
gwvbd処理を終了し、ゲートウェイはすべてのエラーを検出しませんでした。これは必ずしも成功ファックス、モデム、またはテキスト送信を意味するものではないことに注意してください。それは単にgwvbd手続きが終了したことを示し、手続き自体は、何らかのエラーが発生しませんでした。 「停止」パラメータは、「画像」または「テキスト」として非VBD「オーディオ」コーデックまたは他のメディアタイプにVBDからVBDからの変化に対応することができます。この変更は、コールエージェントまたはゲートウェイの制御下にあり得ます。例えば、ゲートウェイはVBDからスイッチを調整することができるSSES [T38] [V152]の交換を通じて、「画像/ T38」に。コールエージェントの制御に関わるたとえば、「MC」の理由コードを参照してください。両方の例において、gwvbd手順は、培地交換で終了します。
4) VBD Failure (failure)
4）VBD障害（故障）
The gwvbd procedure ended abnormally. Some kind of problem was encountered in the gwvbd procedure, and the procedure ended.
gwvbd手順が異常終了しました。問題のいくつかの種類がgwvbd手順で遭遇し、手続きは終了しました。
When the "gwvbd" event is reported, exactly one of the "start", "update", "stop", or "failure" parameters MUST be present and MUST be the first parameter supplied.
「gwvbd」イベントが報告される場合、正確に一つの「開始」、「更新」、「停止」の、または「失敗」のパラメータに存在していなければなりませんし、供給された第1のパラメータである必要があります。
The "rc", "codec", "coord", and "dir" ObservedEvent parameters are defined as follows:
以下のように「RC」、「コーデック」、「COORD」、および「DIR」ObservedEventパラメータが定義されています。
1) Reason Code (rc=<ReasonCode>)
1）理由コード（RC = <reasonCodeは>）
With the "start" and "update" parameters, the reason for triggering the switch/change to VBD. With the "stop" and "failure" parameters, the reason for triggering the switch from VBD. The Reason Codes in the following table, which are based on the ITU-T Fax/Textphone/Modem Tones Detection package [H2482], ITU-T V.150.1 Amendment 1 [V1501A1], and ITU-T V.152 [V152], may be used with the "start" and "update" parameters:
「開始」と「更新」のパラメータ、VBDへの切り替え/変更をトリガするための理由が。 「ストップ」と「失敗」のパラメータ、VBDからスイッチをトリガするための理由が。 ITU-Tファックス/ Textphone /モデムトーン検出パッケージ[H2482]、ITU-T V.150.1改正1 [V1501A1]、およびITU-T V.152 [V152]に基づいて次の表に理由コード、「開始」と「更新」のパラメータで使用することができます。
---------------------------------------------------------------
| ReasonCode | Description |
|------------|--------------------------------------------------|
| CNG | T.30 fax calling |
| V21flag | V.21 tone and flags for fax answering |
| CIV18 | V.8 CI with V.18 call function |
| XCI | V.18 XCI |
| V18txp | V.18 txp |
| Belltone | Bell 103 carrier, high- or low-frequency channel |
| | (ITU-T Recommendation V.18) |
| Baudot | Baudot initial tone and character (ITU-T |
| | Recommendation V.18) |
| Edt | EDT initial tone and character (ITU-T |
| | Recommendation V.18) |
| CIdata | V.8 CI with any data call function |
| CT | V.25 calling tone |
| CIfax | V.8 CI with fax call function |
| V21tone | V.21 carrier, high- or low-frequency channel |
| V23tone | V.23 carrier, high- or low-frequency channel |
| V8bis | V.8 bis modem handshaking signal |
| ANS | V.25 ANS, equivalent to T.30 CED from answering |
| | terminal |
| /ANS | V.25 ANS with periodic phase reversals |
| ANSam | V.8 ANSam |
| /ANSam | V.8 ANSam with periodic phase reversals |
| CMFax | V.8 CM sequence indicating fax call function |
| JMFax | V.8 JM sequence indicating fax call function |
| CMData | V.8 CM sequence indicating unspecified data |
| | call function |
| JMData | V.8 JM sequence indicating unspecified data |
| | call function |
| CMText | V.8 CM sequence indicating text call function |
| JMText | V.8 JM sequence indicating text call function |
| PTSW | Payload type switch as defined in V.152 |
---------------------------------------------------------------
For solutions involving textphones using a modulation with interspersed text and speech on the same "channel", such as Baudot and EDT, the Call Agent SHOULD interpret the ReasonCode parameter as part of the "vbd/gwvbd(start)" event in order to differentiate between fax, modem, and text. In the case of interspersed text and speech, the Call Agent SHOULD remove the notification request for "vbd/gwvbd" upon receiving the "vbd/gwvbd(start)" event in order to avoid large numbers of notifications.
このようボドーやEDTと同じ「チャンネル」に散在するテキストおよびスピーチで変調を使用してtextphonesを伴う解決策については、コール・エージェントは区別するために「VBD / gwvbd（スタート）」イベントの一環として、reasonCodeはパラメータを解釈すべきですファックス、モデム、およびテキストの間。散在テキストと音声の場合には、コールエージェントは、通知の多数を避けるために、「VBD / gwvbd（スタート）」イベントを受信すると、「VBD / gwvbd」の通知要求を削除する必要があります。
For example,
例えば、
vbd/gwvbd(start, rc=Baudot)
VBD / gwvbd（開始、RC =ボドー）
With a ReasonCode of "PTSW", the Call Agent cannot differentiate text from fax/modem. In this case, the Call Agent SHOULD adopt a policy that guards against large numbers of notifications. We consider several such policies.
「PTSW」のreasonCodeはでは、コールエージェントはファックス/モデムからテキストを区別することはできません。この場合、コールエージェントは、通知の多数のデバイスを保護政策を採用すべきです。我々はいくつかのような政策を検討してください。
The Call Agent MAY remove the notification request for "vbd/gwvbd" upon receiving the "vbd/gwvbd(start, rc=PTSW)" event. With this policy, "update", "stop", and "failure" notifications will not be generated with text AND fax/modem.
コール・エージェントは、「VBD / gwvbd（スタート、RC = PTSW）」イベントを受信すると、「VBD / gwvbd」の通知要求を削除することができます。このポリシーでは、「更新」、「停止」、および「失敗」の通知は、テキストおよびファックス/モデムで生成されることはありません。
The Call Agent MAY wait for a subsequent "vbd/gwvbd(update)" event that differentiates text from fax/modem. If the ReasonCode indicates interspersed text and speech, the Call Agent SHOULD remove the notification request for "vbd/gwvbd". For example,
コール・エージェントは、ファックス/モデムからテキストを区別し、後続の「VBD / gwvbd（更新）」イベントを待つことができます。 reasonCodeはが散在テキストやスピーチを示している場合、コールエージェントは、「VBD / gwvbd」の通知要求を削除する必要があります。例えば、
vbd/gwvbd(update, rc=Edt)
VBD / gwvbd（更新、RC =香水EDT）
The Call Agent MAY remove the notification request for "vbd/gwvbd" upon receiving a "vbd/gwvbd(stop)" event without having differentiated between text and fax/modem.
コール・エージェントは、テキストおよびファックス/モデムを区別せずに「VBD / gwvbd（停止）」イベントを受信すると、「VBD / gwvbd」の通知要求を削除することができます。
The Call Agent MAY remove the notification request for "vbd/gwvbd" after having received a number of "vbd/gwvbd(start)" events without having differentiated between text and fax/modem. The specific number of events after which the notification request is removed is considered an implementation detail outside the scope of this specification.
コールエージェントは、多くの「VBD / gwvbd（スタート）」テキストおよびファックス/モデムを区別せずにイベントを受信した後、「VBD / gwvbd」の通知要求を削除することができます。通知要求が除去された後イベントの特定の数は、本明細書の範囲外の実装の詳細であると考えられます。
Reason Codes applicable with the "stop" parameter are listed below:
「ストップ」パラメータを使用して該当する理由コードは次のとおりです。
------------------------------------------------------
| ReasonCode | Description |
|------------|-----------------------------------------|
| SIL | Bidirectional silence |
| Voice | Voice signals |
| PTSW | Payload type switch as defined in V.152 |
| MC | Media change |
------------------------------------------------------
The "MC" Reason Code indicates that the media type has changed from "audio" (to "image", "text", ...) or the "audio" media format has changed from a VBD codec (for a reason other than "PTSW"). For example, the gwvbd procedure may be initiated upon detecting called terminal identification (CED). Subsequently, the Call Agent controlled T.38 procedure of the MGCP Fax (FXR) package [RFC5347] may be initiated upon detecting V.21 flags. Upon receipt of a "t38(start)" event, the Call Agent will instruct the gateway to switch from VBD to T.38 through the use of a ModifyConnection command involving a LocalConnectionOption encoding method of "L:a:image/t38" and/or a RemoteConnectionDescriptor with an "image/t38" media description. This stops the gwvbd procedure. There is no specific interdependency between the VBD package and the FXR package (or any other package). The gwvbd procedure is stopped as a consequence of the media change, not as a direct consequence of the T.38 procedure being initiated. Note that in this situation the "t38(start)" event will be sent before the "gwvbd(stop)" event. The Call Agent MAY choose to infer that the gwvbd procedure has ended upon receiving the "t38(start)" event and disable the notification of the "gwvbd" event. Refer to the example call flow in Section 9.2.
「MC」理由コードは、メディアタイプ以外の理由（VBDコーデックから変更された（「テキスト」、「画像」と、...）「オーディオ」または「オーディオ」メディアフォーマットから変更されたことを示し"PTSW"）。例えば、gwvbd手順は、端末識別（CED）と呼ばれる検出したときに開始することができます。その後、MGCPファックス（FXR）パッケージ[RFC5347]のコールエージェント制御のT.38手順は、V.21フラグを検出したときに開始することができます。 「T38（開始）」イベントを受信すると、コールエージェントが「：L画像/ T38」のLocalConnectionOption符号化方法を含むModifyConnectionコマンドの使用を通してT.38するVBDから切り替えるようにゲートウェイに指示すると/または「画像/ T38」メディア記述とRemoteConnectionDescriptor。これはgwvbd手順を停止します。 VBDパッケージとFXRパッケージ（または他のパッケージ）の間には、特定の相互依存性はありません。 gwvbd手順は、メディアの変化の結果として、開始されていないT.38手順の直接の結果として停止しています。この状況で「T38（スタート）」イベント「はgwvbd（停止）」イベントの前に送信されることに注意してください。コールエージェントは「gwvbd」イベントの通知をgwvbd手順は、「T38（スタート）」イベントを受信したときに終了したことを推測して無効にすることができます。 9.2節で例のコールフローを参照してください。
Reason Codes applicable with the "failure" parameter:
「失敗」パラメータを使用して該当する理由コード：
----------------------------------------------------
| ReasonCode | Description |
|------------|---------------------------------------|
| TO | Indicates that a timeout has occurred |
----------------------------------------------------
The list of Reason Codes may be extended to include values with meaning mutually understood between the gateway and the Call Agent. Obviously, the use of extended values MUST be a provisionable option on the gateway in order to ensure interoperability with the Call Agent.
理由コードのリストは、相互ゲートウェイとCallエージェントとの間で理解される意味を有する値を含むように拡張することができます。明らかに、拡張された値を使用すると、コールエージェントとの相互運用性を確保するために、ゲートウェイのプロビジョニングオプションでなければなりません。
2) Codec String (codec=<CodecString>)
2）コーデックストリング（コーデック= <CodecString>）
With the "start" and "update" parameters, the codec parameter describes the MIME type associated with the switch/change to VBD (e.g., "audio/RED", "audio/PCMU", "audio/PCMA", "audio/G726-32", "audio/clearmode", ...). With the "stop" and "failure" parameters, the codec parameter describes the MIME type associated with the switch from VBD (e.g., "audio/G729", "image/t38", "text/ t140", "audio/v150mr", ...). These strings should be full MIME types as listed in http://www.iana.org/assignments/media-types.
「開始」と「更新」のパラメータでは、コーデックパラメータはVBDへの切り替え/変更（例えば、「オーディオ/ RED」、「オーディオ/ PCMU」、「オーディオ/ PCMA」、「オーディオ/に関連付けられているMIMEタイプを記述するG726-32" 、 "オーディオ/クリアモード"、...）。 「停止」と「失敗」のパラメータでは、コーデックのパラメータはVBDからスイッチに関連付けられているMIMEタイプを記述する（例えば、「オーディオ/ G729」、「画像/ T38」、「テキスト/ T140」、「オーディオ/ v150mr」 、...）。 http://www.iana.org/assignments/media-typesに記載されているように、これらの文字列は、完全なMIMEタイプでなければなりません。
3) Coordination Technique (coord=<CoordinationTechnique>)
3）調整法（COORD = <CoordinationTechnique>）
The technique used to coordinate the transition to and from VBD with the remote endpoint. The coordination techniques are summarized in the following table:
およびリモートエンドポイントとVBDからの遷移を調整するために使用される技術。コーディネーション技術を次の表にまとめます。
------------------------------------------------------
| CoordinationTechnique | Description |
|-----------------------|------------------------------|
| v152ptsw | V.152 Payload Type Switching |
| v150fw | V.150.1 SSE |
------------------------------------------------------
With the "v152ptsw" coordination technique, payload type switching [V152] is used to coordinate the transition to and from VBD.
「v152ptsw」協調技術と、ペイロードタイプ切り替え[V152]はVBDおよびからの移行を調整するために使用されます。
With the "v150fw" coordination technique, state signaling events [V1501] are used to coordinate the transition to and from VBD.
「v150fw」コーディネーション技術では、状態シグナリングイベント[V1501]はVBDおよびからの移行を調整するために使用されます。
The list of coordination techniques may be extended to include values with meaning mutually understood between the gateway and the Call Agent. Obviously, the use of extended values MUST be a provisionable option on the gateway in order to ensure interoperability with the Call Agent.
協調技術のリストは、相互ゲートウェイとCallエージェントとの間で理解される意味を有する値を含むように拡張することができます。明らかに、拡張された値を使用すると、コールエージェントとの相互運用性を確保するために、ゲートウェイのプロビジョニングオプションでなければなりません。
4) Direction of Stimulus (dir=<Direction>)
刺激の4）の方向（DIR = <方向>）
With the "start" and "update" parameters, the "dir" parameter describes the direction of the stimulus that resulted in the switch/change to VBD.
「開始」と「更新」のパラメータでは、「DIR」パラメータはVBDへの切り替え/変更が生じた刺激の方向を示しています。
---------------------------------------------------
| Direction | Description |
|-----------|------------------------------------ |
| GstnToIp | Stimulus detected in the direction |
| | from the GSTN to IP network, |
| | including fax, modem, and text tones. |
| IpToGstn | Stimulus detected in the direction |
| | from the IP to GSTN network, |
| | including fax, modem, and text tones |
| | (e.g., IP-side tone detection); |
| | RTP packet with VBD payload type |
| | (e.g., V.152 or V.150.1). |
----------------------------------------------------
Call Agents and gateways MUST implement the "start" and "stop" parameters and MAY implement the "update" and "failure" parameters. Call Agents and gateways MAY implement the "coord", "codec", and "dir" parameters. Call Agents MAY, and gateways MUST, implement the "rc" parameter in conjunction with the "start" and "update" parameters. Call Agents and gateways MAY implement the "rc" parameter in conjunction with the "stop" and "failure" parameters. A Call Agent MUST ignore all unknown ObservedEvent parameters, including parameters that are defined as part of this specification and not implemented.
コールエージェントとゲートウェイは、「開始」とパラメータを「停止」と「更新」と「失敗」のパラメータを実装してもよい（MAY）を実装しなければなりません。コールエージェントとゲートウェイは、「COORD」、「コーデック」、および「DIR」のパラメータを実施することができます。コールエージェントMAY、およびゲートウェイは、「開始」と「更新」のパラメータと一緒に「RC」パラメータを実装しなければなりません。コールエージェントとゲートウェイは、「停止」と「失敗」のパラメータと併せて「RC」パラメータを実施することができます。コール・エージェントは、この仕様の一部として定義され、実装されていないパラメータを含む、すべての未知ObservedEventパラメータを無視しなければなりません。
The following examples illustrate the encoding of the "gwvbd(start)" event:
以下の実施例は、「gwvbd（開始）」イベントのエンコーディングを示します。
O: vbd/gwvbd(start, rc=ANS)
O: vbd/gwvbd(start, rc=ANS, codec=audio/PCMU, coord=v152ptsw)
O: vbd/gwvbd(start, rc=PTSW, codec=audio/RED)
The following example illustrates the encoding of the "gwvbd(update)" event:
次の例は、「gwvbd（更新）」イベントのエンコーディングを示します。
O: vbd/gwvbd(update, rc=/ANSam, dir=IpToGstn)
O：VBD / gwvbd（更新、RC = / ANSamの、DIR = IpToGstn）
The following examples illustrate the encoding of the "gwvbd(stop)" event:
以下の実施例は、「gwvbd（停止）」イベントのエンコーディングを示します。
O: vbd/gwvbd(stop)
O: vbd/gwvbd(stop, rc=SIL, codec=audio/G729)
O: vbd/gwvbd(stop, rc=MC, codec=image/t38)
The following examples illustrate the encoding of the "gwvbd(failure)" event:
以下の実施例は、「gwvbd（失敗）」イベントのエンコーディングを示します。
O: vbd/gwvbd(failure, codec=audio/G729)
O: vbd/gwvbd(failure, rc=TO, codec=audio/G729)
The "No Negotiated Procedure for Voiceband Data" (or simply "nopvbd") event occurs when a VBD procedure has not been negotiated and VBD stimulus is detected. The "nopvbd" event may occur when the procedure is updated (e.g., upon detecting new stimulus), when the procedure ends, and when the procedure fails. Even though a procedure was not negotiated, a VBD handling procedure MAY still be in place locally on the endpoint, as described further below.
VBD手順がネゴシエートされていないとVBD刺激が検出された場合、「音声帯域データなし交渉手順」（または単に「nopvbd」）イベントが発生します。手順が終了すると、処理が失敗した場合手順は、（例えば、新たな刺激を検出したときに）更新されたときに「nopvbd」イベントが発生する可能性があります。手順が交渉されていなかったにもかかわらず、後述するように、VBDの取り扱い手順は、まだ、エンドポイント上でローカルな場所であってもよいです。
The nopvbd procedure MAY involve VBD handling including, but not limited to, adjusting gain and jitter, disabling voice activity detection, and DC offset filters. The nopvbd procedure MAY involve switching to another codec. The Call Agent MAY have to issue further commands in response to the "nopvbd" event in order to ensure a successful VBD call.
nopvbd手順は、VBDの取り扱いを含め、これらに限定されないが、ゲインおよびジッタを調整し、音声アクティビティ検出を無効にし、DCフィルタをオフセット含むことができます。 nopvbd手順は、別のコーデックへの切り替えを伴うことがあります。コールエージェントは成功したVBDコールを確保するために「nopvbd」イベントに応答して、さらにコマンドを発行する必要があります。
As with the "gwvbd" event, the same recommendations from MGCP [RFC3435] regarding ABNF, general robustness principles, and white space apply.
「gwvbd」イベントと同様に、ABNFに関するMGCP [RFC3435]、一般的な堅牢性の原則、及びホワイトスペースから同じ推奨事項が当てはまります。
The RequestedEvent parameter is encoded as
RequestedEventパラメータは以下のように符号化されます
NopVbdReqEvent = "nopvbd"
NopVbdReqEvent = "nopvbd"
The ObservedEvent parameter is encoded as
ObservedEventパラメータは以下のように符号化されます
NopVbdObsEvent = NopVbdObsEventStart / NopVbdObsEventUpdate / NopVbdObsEventStop / NopVbdObsEventFailure
NopVbdObsEvent = NopVbdObsEventStart / NopVbdObsEventUpdate / NopVbdObsEventStop / NopVbdObsEventFailure
NopVbdObsEventStart = "nopvbd(start" Rc [Codec] [Dir] ")" NopVbdObsEventUpdate = "nopvbd(update" Rc [Codec] [Dir] ")" NopVbdObsEventStop = "nopvbd(stop" [Rc] [Codec] ")" NopVbdObsEventFailure = "nopvbd(failure" [Rc] [Codec] ")"
NopVbdObsEventStart = "nopvbd（開始" NopVbdObsEventUpdate = "nopvbd（アップデート" RC [コーデック] [DIR] "）" RC [コーデック] [DIR] "）" NopVbdObsEventStopは= "nopvbd（停止" [RC] [コーデック] "）" NopVbdObsEventFailure = "nopvbd（失敗" [RC] [コーデック] "）"
The following ABNF notation is common with the "gwvbd" ObservedEvent parameter:
以下のABNF表記は「gwvbd」ObservedEventパラメータで共通です。
Codec = "," *WSP "codec=" CodecString CodecString = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-" / "_" / "." / "/") Rc = "," *WSP "rc=" ReasonCode ReasonCode = 1*(ALPHA / DIGIT / "-" / "_" / "." / "/") ; Refer to the values listed in the tables above. Dir = "," *WSP "dir=" Direction Direction = "GstnToIp" / "IpToGstn"
コーデック= "" * WSP "コーデック=" CodecString CodecString =（ALPHA / DIGIT）*（ALPHA / DIGIT / " - " "" / "_" / / "/"）RC = "" * WSP「RC = "reasonCodeはreasonCodeは= 1 *（ALPHA / DIGIT / " - "/ "_"/"」/ "/"）。上記の表に列挙された値を参照。 DIR = "" * WSP "DIR =" 方向方向= "GstnToIp" / "IpToGstn"
ABNF does not provide for position-independent parameters. The "rc", "codec", and "dir" parameters, if present, MUST appear in the relative order shown.
ABNFは位置独立なパラメータを提供しません。 「RC」、「コーデック」、および「DIR」パラメータは、存在する場合、図示の相対的順序で現れなければなりません。
The "start", "update", "stop", and "failure" ObservedEvent parameters are defined as follows:
「スタート」、「更新」、「停止」、および以下のように「失敗」ObservedEventパラメータが定義されています。
1) VBD Start(start)
1）VBDを起動（開始）
The nopvbd procedure was initiated. The Call Agent may have to issue further commands in order to ensure a successful VBD call (e.g., switch to another codec). At most one "nopvbd(stop)" or "nopvbd(failure)" event MAY be generated corresponding to each "nopvbd(start)" event. The Call Agent MAY need to infer that the nopvbd procedure has ended.
nopvbd手続きを開始しました。コールエージェントは成功したVBDコール（別のコーデックに、例えば、スイッチ）を確保するために、さらにコマンドを発行する必要があります。多くても1つの「nopvbd（停止）」または「nopvbd（失敗）」でのイベントは、それぞれ「nopvbd（スタート）」イベントに対応して生成されるかもしれません。コールエージェントはnopvbd手続きが終了したことを推測する必要があるかもしれません。
2) VBD Update (update)
2）VBDアップデート（更新）
The nopvbd procedure was updated. The "nopvbd(update)" event MUST only be generated after a "nopvbd(start)" event and before a "nopvbd(stop)" or "nopvbd(failure)" event.
nopvbd手順を更新しました。 「nopvbd（更新）」のイベントが唯一の「nopvbd（スタート）」イベントと「nopvbd（停止）」または「nopvbd（失敗）」イベントの前後に生成されなければなりません。
3) VBD Stop (stop)
3）VBD停止（停止）
The nopvbd procedure ended, and the gateway did not detect any errors. Note that this does not necessarily imply a successful fax, modem, or text transmission. It merely indicates that the nopvbd procedure has ended and the procedure itself did not encounter any errors. Refer to the definition of the "stop" parameter from the "gwvbd" event in Section 4.1.1 for additional information.
nopvbd処理を終了し、ゲートウェイはすべてのエラーを検出しませんでした。これは必ずしも成功ファックス、モデム、またはテキスト送信を意味するものではないことに注意してください。それは単にnopvbd手続きが終了したことを示し、手続き自体は、何らかのエラーが発生しませんでした。詳細については、4.1.1項で「gwvbd」イベントから「停止」パラメータの定義を参照してください。
4) VBD Failure (failure)
4）VBD障害（故障）
The nopvbd procedure ended abnormally. Some kind of problem was encountered in the nopvbd procedure, and the procedure ended.
nopvbd手順が異常終了しました。問題のいくつかの種類がnopvbd手順で遭遇し、手続きは終了しました。
Call Agents and gateways MUST implement the "start" parameter and MAY implement the "update", "stop", and "failure" parameters. Call Agents MAY, and gateways MUST, implement the "rc" parameter in conjunction with the "start" and "update" parameters. Call Agents and gateways MAY implement the "rc" parameter in conjunction with the "stop" and "failure" parameters. A Call Agent MUST ignore all unknown ObservedEvent parameters including parameters that are defined as part of this specification and not implemented.
コールエージェントとゲートウェイは、「スタート」パラメータを実装しなければならないし、「更新」、「停止」、および「失敗」のパラメータを実施することができます。コールエージェントMAY、およびゲートウェイは、「開始」と「更新」のパラメータと一緒に「RC」パラメータを実装しなければなりません。コールエージェントとゲートウェイは、「停止」と「失敗」のパラメータと併せて「RC」パラメータを実施することができます。コール・エージェントは、この仕様の一部として定義され、実装されていないパラメータを含むすべての未知ObservedEventのパラメータを無視しなければなりません。
The definitions of the "rc", "codec", and "dir" ObservedEvent parameters are taken from the "gwvbd" event.
「RC」、「コーデック」、および「DIR」ObservedEventパラメータの定義は、「gwvbd」イベントから取得されます。
As with the "gwvbd" event, the same recommendations regarding interspersed text and speech apply.
「gwvbd」イベントと同じように、散在するテキストおよびスピーチに関する同じ推奨事項が適用されます。
The following examples illustrate the encoding of the "nopvbd(start)" event:
以下の実施例は、「nopvbd（開始）」イベントのエンコーディングを示します。
O: vbd/nopvbd(start, rc=ANS)
O: vbd/nopvbd(start, rc=ANS, codec=audio/PCMU)
The following example illustrates the encoding of the "nopvbd(update)" event:
次の例は、「nopvbd（更新）」イベントのエンコーディングを示します。
O: vbd/nopvbd(update, rc=/ANSam, dir=IpToGstn)
O：VBD / nopvbd（更新、RC = / ANSamの、DIR = IpToGstn）
The following examples illustrate the encoding of the "nopvbd(stop)" event:
以下の実施例は、「nopvbd（停止）」イベントのエンコーディングを示します。
O: vbd/nopvbd(stop)
O: vbd/nopvbd(stop, rc=SIL, codec=audio/G729)
O: vbd/nopvbd(stop, rc=MC, codec=image/t38)
The following examples illustrate the encoding of the "nopvbd(failure)" event:
以下の実施例は、「nopvbd（失敗）」イベントのエンコーディングを示します。
O: vbd/nopvbd(failure, codec=audio/G729)
O: vbd/nopvbd(failure, rc=TO, codec=audio/G729)
This package is defined for the General-Purpose Media Descriptor Parameter [V152]. The package defines a new LocalConnectionOption as detailed below.
このパッケージは、汎用メディア記述子パラメータ[V152]のために定義されています。下記のとおりパッケージには、新しいLocalConnectionOptionを定義します。
Package Name: GPMD Package Version: 0
パッケージ名：GPMDパッケージのバージョン：0
The following new LocalConnectionOptions field is defined in support of the above:
次の新しいLocalConnectionOptionsフィールドは、上記のサポートで定義されています。
------------------------------------------------------
| Symbol | Definition |
|--------|---------------------------------------------|
| gpmd | General-Purpose Media Descriptor Parameter |
------------------------------------------------------
The definition of the LocalConnectionOption is provided in the following subsection.
LocalConnectionOptionの定義は、以下のサブセクションで提供されています。
The General-Purpose Media Descriptor Parameter LocalConnectionOption is similar to the "gpmd" SDP [RFC4566] attribute defined in ITU-T Recommendation V.152 [V152] and is applicable to all of the same media formats that the corresponding SDP "gpmd" attribute could be used with.
汎用メディア記述子パラメータLocalConnectionOptionは、ITU-T勧告V.152 [V152]で定義された「gpmd」SDP [RFC4566]属性と同様であり、対応するSDP属性を「gpmd」同じメディアフォーマットの全てに適用可能ですで使用することができます。
The General-Purpose Media Descriptor Parameter is encoded as the keyword "gpmd" or "o-gpmd", followed by a colon and a quoted string beginning with the media format name (MIME subtype only) followed by a space, followed by the media format parameters associated with that media format:
汎用メディア記述子パラメータは、メディアが続き、コロンとスペースに続いて、メディアのフォーマット名（MIMEサブタイプのみ）で始まる引用符で囲まれた文字列に続いて、キーワード「gpmd」または「O-gpmd」としてエンコードされますそのメディアフォーマットに関連付けられたフォーマットパラメータ：
gpmd/gpmd:"<format> <parameter list>"
gpmd / gpmd： "<フォーマット> <パラメータリスト>"
For simplicity, we will use the terms "codec" and "media format" interchangeably in the following. Multiple media formats may be indicated by either repeating the "gpmd" LocalConnectionOption multiple times, such as
簡単にするために、我々は、用語「コーデック」と同義的に以下の「メディア形式」を使用します。複数のメディアフォーマットは、次のような「gpmd」LocalConnectionOption複数回、繰り返すことのいずれかによって示すことができます
L: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX",
gpmd/gpmd:"codec2 parameterY"
or alternatively by having a single "gpmd" keyword followed by a colon, and a semicolon-separated list of quoted strings for each General-Purpose Media Descriptor Parameter, as in
または代わりのように、コロンシングル「gpmd」キーワード、および各汎用メディア記述子パラメータの引用符で囲まれた文字列をセミコロンで区切ったリストを持つことにより、
L: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX";
"codec2 parameterY"
The two formats may be mixed:
二つのフォーマットを混合してもよいです。
L: a:codec1;codec2;codec3, gpmd/gpmd:"codec1 parameterX",
gpmd/gpmd:"codec2 parameterY";
"codec3 parameterZ"
The carriage returns above are included for formatting reasons only and are not permissible in a real implementation. This holds true for all of the examples in this document.
キャリッジリターンは、上記だけの理由をフォーマットするために含まれ、実際の実装では許容されないが。これは、このドキュメントの例のすべてに当てはまります。
If it is possible for the same codec to be requested with and without the "gpmd" parameter, the following could result:
同じコーデックがでと「gpmd」パラメータを指定せずに要求することは可能である場合は、次のようになる可能性があり：
L: a:codec1;codec1, gpmd/gpmd:"codec1 parameterX"
L：CODEC1; CODEC1、gpmd / gpmd： "CODEC1 parameterX"
However, it would not be clear whether the "gpmd" parameter was to be applied to the first or the second occurrence of the codec. The problem is that codec ordering is important (i.e., codecs are listed in preferred order), and the above syntax does not provide a way to indicate whether "parameterX" is preferred (i.e., associated with the first "codec1") or not (i.e., associated with the second "codec1"). In order to resolve this dilemma, the codec in the "gpmd" media format is followed by a colon and an <order>, where <order> is a number from one to N for occurrences of the same codec in the codec list. For example,
しかし、「gpmd」パラメータは第一又は第二のコーデックの発生に適用されることになっていたかどうかは明らかではないであろう。問題は、コーデックの順序は（すなわち、コーデックは、好ましい順に列挙されている）が重要であるということです、そして上記の構文は（すなわち、最初の「CODEC1」に関連した）か否か（「parameterXが」優先されるかどうかを示すための方法を提供していません。すなわち、）は、第2の「CODEC1」に関連付けられています。このジレンマを解決するために、「gpmd」メディア形式のコーデックは、<順序は>コーデックリストに同じコーデックの発生のためのNに1から数である結腸および<順序>が続きます。例えば、
L:a:codec1;codec1, gpmd/gpmd:"codec1:2 parameterX"
L：CODEC1; CODEC1、gpmd / gpmd： "CODEC1：2 parameterX"
indicates that "parameterX" is associated with the second instance of "codec1" in the "a:codec1;codec1" list. If an invalid instance number is supplied (e.g., instance 3 where there are only two instances), then error code 524 -- inconsistency in local connection options -- will be returned. In the absence of an <order>, the first instance is assumed.
「; CODEC1 CODEC1」リスト「parameterXが」中「CODEC1」の2番目のインスタンスに関連付けられていることを示しています。無効なインスタンス番号が供給されている場合（例えば、2つだけのインスタンスが存在するインスタンス3）は、エラーコード524 - ローカル接続オプションで矛盾が - 返されます。 <注文>の非存在下で、最初のインスタンスが想定されます。
Prepending "gpmd" with the string "o-" (i.e., "o-gpmd") indicates that the parameter is optional. In that case, the gateway may decide not to use the "gpmd" parameter specified, or only use it in part.
文字列を「gpmd」「O-」（すなわち、「O-gpmd」）を先頭に追加するパラメータはオプションであることを示しています。その場合、ゲートウェイは、指定された「gpmd」パラメータを使用するか、または一部だけでそれを使用しないことを決定することができます。
If the "gpmd" LocalConnectionOption parameter is not optional (i.e., does not have "o-" in front of it), and the LocalConnectionOption parameter value is either not recognized or not supported, then the associated codec is considered "not supported".
「gpmd」LocalConnectionOptionパラメータはオプションでない場合（すなわち、その前に「-O-」ていない）、及びLocalConnectionOptionパラメータ値が認識されない、またはサポートされていないか、関連コーデックを「サポートされていない」と考えられます。
When auditing capabilities, the "gpmd" LocalConnectionOption parameter MUST be returned with a semicolon-separated list of supported formats and/or multiple independent "gpmd" parameters, as in
監査機能は、「gpmd」LocalConnectionOptionパラメータは、同様にサポートするフォーマット及び/又は複数の独立した「gpmd」パラメータのセミコロンで区切られたリストで返さなければならない場合
A: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX";
"codec2 parameterY"
or
または
A: a:codec1;codec1, gpmd/gpmd:"codec1 parameterX"
：：CODEC1; CODEC1、gpmd / gpmd： "CODEC1 parameterX"
One example uses the General-Purpose Media Descriptor Parameter LocalConnectionOption in conjunction with gateway controlled Voiceband Data (or simply VBD) using payload type switching [V152]. In the context of VBD, the <format> must be an RTP/AVP payload type. The <parameter list> is a semicolon-separated list of "parameter=value" pairs:
一例では、ペイロードタイプの切り替え[V152]を使用してゲートウェイ制御音声帯域データ（又は単にVBD）と組み合わせて汎用メディア記述子パラメータLocalConnectionOptionを使用します。 VBD、<フォーマット>の文脈でRTP / AVPペイロードタイプでなければなりません。 <パラメータリスト>「パラメータ=値」のペアのセミコロンで区切られたリストです。
L: a:codec1, gpmd/gpmd:"codec1 parameterX=ValueA;parameterY=ValueB"
L：CODEC1、gpmd / gpmd： "CODEC1パラメータ= ValueA;パラメータ=値"
In the example below, G.729 is an audio codec and G.711u is a VBD codec:
以下の例では、G.729オーディオコーデックとにG.711uはVBDコーデックです。
L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes"
L：G729、PCMU、gpmd / gpmd： "PCMUのVBD = yes" を
The corresponding media description in the SDP as part of the connection request acknowledgment might look like
接続要求の確認応答の一部として、SDPにおける対応するメディアの説明は、次のようになります
m=audio 12345 RTP/AVP 18 96
a=rtpmap:96 PCMU/8000
a=gpmd:96 vbd=yes
If a request is made to audit the capabilities of an endpoint, and the endpoint supports G.711u as both an audio and VBD codec, then the "gpmd" LocalConnectionOption parameter might look like
要求がエンドポイントの機能を監査するために作られた、およびエンドポイントは、オーディオおよびVBDコーデックの両方としてにG.711uをサポートしている場合は、その後、「gpmd」LocalConnectionOptionパラメータは、次のようになります
A: a:PCMU, p:10-40, e:on, s:on,
m:sendonly;recvonly;sendrecv;inactive
A: a:PCMU, p:10-40, e:on, s:off,
m:sendonly;recvonly;sendrecv;inactive,
gpmd/gpmd:"PCMU vbd=yes"
Given that some parameters, e.g., silence suppression, are only compatible with G.711u as an audio codec, then the gateway MUST return different capability sets corresponding to audio and VBD.
いくつかのパラメータ、例えば、無音抑圧は、オーディオコーデックなどにG.711uのみに対応していることを考えると、ゲートウェイは、オーディオ及びVBDに対応する異なる能力セットを返さなければなりません。
If we combine V.152 and redundancy [RFC2198], an example LocalConnectionOption might look like the example below. In this example, G.729 is an audio codec and G.711u is a VBD codec with a redundancy level of one:
私たちはV.152と冗長性[RFC2198]を組み合わせた場合、例えばLocalConnectionOptionは、以下の例のようになります。この例では、G.729オーディオコーデックとにG.711uは、一つの冗長レベルとVBDコーデックです。
L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU"
L：G729; RED; PCMU、gpmd / gpmd： "PCMUのVBD = yes" と、のfmtp： "RED PCMU / PCMU"
The corresponding media description in the SDP as part of the connection request acknowledgment might look like
接続要求の確認応答の一部として、SDPにおける対応するメディアの説明は、次のようになります
m=audio 12345 RTP/AVP 18 96 97
a=rtpmap:96 RED/8000
a=fmtp:96 97/97
a=rtpmap:97 PCMU/8000
a=gpmd:97 vbd=yes
Refer to Section 6 for more examples involving V.152 and redundancy.
V.152と冗長性を含む、より多くの例については、セクション6を参照してください。
The MGCP Media Format Parameter (FM) package [RFC3660] in conjunction with the standard audio MIME subtype "RED" may be used by the Call Agent to authorize the negotiation of redundancy [RFC2198], to identify the levels of redundancy and the media format associated with each redundancy level. An example of this was demonstrated in Section 5.
標準的なオーディオMIMEサブタイプ「RED」は、冗長性のレベルおよびメディアフォーマットを識別するために、[RFC2198]の冗長性交渉を認可するためにコールエージェントで使用することができると一緒にMGCPメディアフォーマットパラメータ（FM）パッケージ[RFC3660]各冗長性レベルに関連します。この例は、第5節で実証されました。
The FM package states that the "fmtp" LocalConnectionOption MUST be returned when auditing capabilities. Applying this to VBD and redundancy might result in
FMパッケージには「のfmtp」LocalConnectionOptionは時に監査機能を返されなければならないと述べています。 VBDにこれを適用すると、冗長性をする可能性があります
A: a:PCMU, p:10-40, e:on, s:on,
m:sendonly;recvonly;sendrecv;inactive
A: a:RED;PCMU, p:10-40, e:on, s:off,
m:sendonly;recvonly;sendrecv;inactive,
gpmd/gpmd:"PCMU vbd=yes",
fmtp:"RED PCMU/PCMU"
The FM package defines "instance syntax", in which
FMパッケージはここで、「インスタンスの構文」を定義します
L:a:codec1;codec1, fmtp:"codec1:2 formatX"
L：CODEC1; CODEC1、のfmtp： "CODEC1：2 formatX"
indicates that "formatX" is associated with the second instance of "codec1" in the "a:codec1;codec1" list. The examples in the FM package are limited to the use of the instance syntax in conjunction with the media format. We propose the use of the instance syntax in conjunction with the media format parameters
「; CODEC1 CODEC1」リスト「formatXが」中「CODEC1」の2番目のインスタンスに関連付けられていることを示しています。 FMパッケージの例では、メディアフォーマットと連動して、インスタンスの構文の使用に限定されています。私たちは、メディアフォーマットのパラメータと連動して、インスタンスの構文を使用することを提案しています
L:a:codec1;codec2;codec3;codec2, fmtp:"codec3 codec2:2/codec2:2"
L：CODEC1; CODEC2; codec3; CODEC2、のfmtp： "codec3 CODEC2：2 / CODEC2：2"
Let's build on the example of Section 5. In the example below, G.729 is an audio codec, and G.711u is both an audio codec and a VBD codec with a redundancy level of one:
のは、以下の例では第5節の例を構築してみましょう、G.729は、オーディオコーデックで、にG.711uはオーディオコーデックと1の冗長レベルとVBDコーデックの両方です。
L: a:G729;PCMU;RED;PCMU, gpmd/gpmd:"PCMU:2 vbd=yes",
fmtp:"RED PCMU:2/PCMU:2"
The corresponding media description in the SDP as part of the connection request acknowledgment might look like
接続要求の確認応答の一部として、SDPにおける対応するメディアの説明は、次のようになります
m=audio 12345 RTP/AVP 18 0 96 97
a=rtpmap:96 RED/8000
a=fmtp:96 97/97
a=rtpmap:97 PCMU/8000
a=gpmd:97 vbd=yes
Note that the relative preference of the LocalConnectionOption encoding methods is preserved in the "audio" media formats (i.e., payload types) as part of the media description. In this example, this reflects a preference for V.152 with redundancy versus without. No preference is inferred from the relative order of the different LocalConnectionOptions, namely "a", "gpmd/gpmd", and "fmtp".
メディア記述の一部としてLocalConnectionOption符号化方法の相対的な嗜好が「音声」のメディアフォーマット（即ち、ペイロードタイプ）に保存されていることに留意されたいです。この例では、このことはせずに対する冗長性V.152のための好みを反映しています。問わないは異なるLocalConnectionOptions、すなわち、「A」、「gpmd / gpmd」、及び「のfmtp」の相対的順序から推測されていません。
A Call Agent can authorize the negotiation of audio codecs and VBD codecs involving different levels of redundancy. In the example below, G.711u is a VBD codec with a redundancy level of two (preferred) or one:
コール・エージェントは、冗長性の異なるレベルを含むオーディオコーデックとVBDコーデックのネゴシエーションを許可することができます。以下の例では、にG.711uは、2つ（好ましい）または1つの冗長レベルとVBDコーデックです。
L: a:G729;RED;RED;PCMU, fmtp:"RED PCMU/PCMU/PCMU",
fmtp:"RED:2 PCMU/PCMU",
gpmd/gpmd:"PCMU vbd=yes"
The corresponding media description in the SDP as part of the connection request acknowledgment might look like
接続要求の確認応答の一部として、SDPにおける対応するメディアの説明は、次のようになります
m=audio 12345 RTP/AVP 18 96 97 98
a=rtpmap:96 RED/8000
a=fmtp:96 98/98/98
a=rtpmap:97 RED/8000
a=fmtp:97 98/98
a=rtpmap:98 PCMU/8000
a=gpmd:98 vbd=yes
Redundancy can be applied to both audio codecs and VBD codecs. In the example below, G.729 is an audio codec with a redundancy level of two and G.711u is a VBD codec with a redundancy level of one:
冗長性は、オーディオコーデックとVBDコーデックの両方に適用することができます。以下の例では、G.729は、二つの冗長レベルを有するオーディオコーデックとにG.711uは、一つの冗長レベルとVBDコーデックです。
L: a:RED;G729;RED;PCMU, fmtp:"RED G729/G729/G729",
fmtp:"RED:2 PCMU/PCMU",
gpmd/gpmd:"PCMU vbd=yes"
The corresponding media description in the SDP as part of the connection request acknowledgment might look like
接続要求の確認応答の一部として、SDPにおける対応するメディアの説明は、次のようになります
m=audio 12345 RTP/AVP 96 18 97 98
a=rtpmap:96 RED/8000
a=fmtp:96 18/18/18
a=rtpmap:97 RED/8000
a=fmtp:97 98/98
a=rtpmap:98 PCMU/8000
a=gpmd:98 vbd=yes
A Call Agent may authorize the negotiation of forward error correction (FEC) [RFC5109] with the standard audio MIME subtype "parityfec":
コール・エージェントは、標準的なオーディオMIMEサブタイプ「parityfec」と前方誤り訂正（FEC）[RFC5109]の交渉を許可することができます。
L: a:PCMU;parityfec
L：PCMU; parityfec
By default, we assume that FEC packets are to be sent as a separate stream. The corresponding media description in the SDP as part of the connection request acknowledgment might look like
デフォルトでは、我々は、FECパケットが別々のストリームとして送信されることを前提としています。接続要求の確認応答の一部として、SDPにおける対応するメディアの説明は、次のようになります
v=0
c=IN IP4 192.0.2.0
m=audio 49170 RTP/AVP 0 96
a=rtpmap:96 parityfec/8000
a=fmtp:96 49172 IN IP4 192.0.2.0
If FEC is to be sent as a secondary codec in the redundant codec payload format [RFC2198], we again leverage the MGCP Media Format Parameter (FM) package [RFC3660] in conjunction with the standard audio MIME subtype "RED":
FECは、標準的なオーディオMIMEサブタイプ「RED」と併せて冗長コーデックペイロード形式[RFC2198]、我々は再びMGCP Mediaフォーマットパラメータを活用（FM）パッケージ[RFC3660]で二次コーデックとして送信する場合：
L: a:G729;RED;PCMU;parityfec, gpmd/gpmd:"PCMU vbd=yes",
fmtp:"RED PCMU/parityfec"
The corresponding media description might look like
対応するメディアの説明は、次のようになります
v=0 c=IN IP4 192.0.2.0 m=audio 49170 RTP/AVP 18 96 97 98 a=rtpmap:96 RED/8000 a=fmtp:96 97/98 a=rtpmap:97 PCMU/8000 a=gpmd:97 vbd=yes a=rtpmap:98 parityfec/8000
V = 0 C = IN IP4 192.0.2.0 M =オーディオ49170 RTP / AVP 18 96 97 98 = rtpmap：96 RED / 8000 =のfmtp：96 97/98 A = rtpmap：97 PCMU / 8000 A = gpmd：97 VBD =はい= rtpmap：98 parityfec / 8000
The FM package states that the "fmtp" LocalConnectionOption MUST be returned when auditing capabilities. Applying this to VBD, redundancy and FEC might result in
FMパッケージには「のfmtp」LocalConnectionOptionは時に監査機能を返されなければならないと述べています。 VBD、冗長性とFECにこれを適用するとする可能性があります
A: a:PCMU, p:10-40, e:on, s:on,
m:sendonly;recvonly;sendrecv;inactive
A: a:RED;PCMU;parityfec, p:10-40, e:on, s:off,
m:sendonly;recvonly;sendrecv;inactive,
gpmd/gpmd:"PCMU vbd=yes",
fmtp:"RED PCMU/parityfec"
The MGCP Fax (FXR) package [RFC5347] is used by a Call Agent to authorize fax handling, including Call Agent controlled T.38 and gateway procedures such as V.152. With the FXR package, VBD falls into one of two categories: "special fax handling" as part of the gateway procedure (resulting in the "gwfax" event), or "no special fax handling" as part of the gateway and Off procedures (resulting in the "nopfax" event). In order for a VBD procedure to fall into the "special fax handling" category, support for it MUST be negotiated with the other side by passing and recognizing relevant parameters via the LocalConnectionDescriptor and RemoteConnectionDescriptor.
MGCPファックス（FXR）パッケージ[RFC5347]は、そのようなV.152などのコール・エージェント制御T.38ゲートウェイ手順を含む、ファックスの取り扱いを許可するコールエージェントによって使用されます。 FXRパッケージと、VBDは、2つのカテゴリのいずれかに該当しない（「gwfax」イベントが生じる）ゲートウェイ手順の一部として、「特別なファックスの取り扱い」、またはゲートウェイとオフ手続きの一部としての「特別なファックスの取り扱い」（ 「nopfax」イベント）になります。 VBD手順は、「特別なファックスの取り扱い」のカテゴリに分類するためには、そのためのサポートが合格とLocalConnectionDescriptorとRemoteConnectionDescriptorを経由して、関連するパラメータを認識することにより、他の側に交渉しなければなりません。
A gateway controlled VBD procedure such as V.152 MUST fall into the category of gateway controlled mode involving "special fax handling". The resulting "gwfax" event is what informs the Call Agent to refrain from issuing media handling instructions that could otherwise have a negative impact on the gateway procedure.
このようV.152などのゲートウェイ制御VBD手順は、「特別なファックスの取り扱い」を含むゲートウェイ制御モードのカテゴリに分類されなければなりません。得られた「gwfax」イベントは、そうでない場合は、ゲートウェイの手順にマイナスの影響を与える可能性があるメディア処理命令を発行することを控えるようにコールエージェントに通知するものです。
Consider the following example (with shorthand SDP notation):
（速記SDP表記で）次の例を考えてみます。
CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 1
M: sendrecv
L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes", fxr/fx:t38;gw
X: 1
R: fxr/t38, fxr/gwfax, fxr/nopfax
v=0 c=IN IP4 192.0.2.1 m=audio 3456 RTP/AVP 18 96 a=rtpmap:96 PCMU/8000 a=gpmd:96 vbd=yes
V = 0 C = IN IP4 192.0.2.1のM =オーディオ3456 RTP / AVP 18 96 = rtpmap：96 PCMU / 8000 = gpmd：96 VBD =はい
200 2000 OK I: 1
200 2000 OK I：1
v=0 c=IN IP4 192.0.2.2 m=audio 1296 RTP/AVP 18 96 a=rtpmap:96 PCMU/8000 a=gpmd:96 vbd=yes
V = 0 C = IN IP4 192.0.2.2のM =オーディオ1296 RTP / AVP 18 96 = rtpmap：96 PCMU / 8000 = gpmd：96 VBD =はい
The RemoteConnectionDescriptor does not indicate support for "image/ t38" as a latent capability [RFC3407]. Consequently, the gateway will not initiate the T.38 strict fax procedure, "t38", upon detecting fax stimulus (i.e., CNG, V.21 flags, etc.). However, the two endpoints did successfully negotiate a gateway controlled VBD procedure (e.g., V.152); therefore, a gateway controlled mode involving "special fax handling" is used. The "gwfax(start)" event will be generated upon detecting VBD (including fax) stimulus.
RemoteConnectionDescriptor潜在能力[RFC3407]として「画像/ T38」のサポートを示していません。したがって、ゲートウェイは、FAX刺激（即ち、CNG、V.21フラグなど）を検出すると、T.38厳密ファックス手順、「T38」を開始しないであろう。しかし、2つのエンドポイントが正常にゲートウェイ制御VBD手順（例えば、V.152）をネゴシエートしませんでした。そのため、「特別なファックスの取り扱い」を含むゲートウェイ制御モードが使用されています。 「gwfax（スタート）」イベントは、刺激（ファックスを含む）VBDを検出したときに生成されます。
A Call Agent can express a preference for a gateway procedure involving "special fax handling" over a T.38 procedure (strict or loose). For example,
コールエージェントは（厳密か緩い）T.38手続き上の「特別なファックスの取り扱い」を含むゲートウェイ・プロシージャのための好みを表現することができます。例えば、
L: fxr/fx:gw;t38
L：FXR / FX：GW; T38
and
そして
L: fxr/fx:gw;t38-loose
L：FXR / FX：GW; T38緩いです
However, with the existing syntax of the FXR package, a Call Agent cannot express a preference for one gateway procedure over another, each with possibly different preferences relative to a T.38 procedure.
しかし、FXRパッケージの既存の構文を使用して、コールエージェントは、T.38手順に対しておそらく異なる好みにそれぞれを別の上の1つのゲートウェイ手順の好みを表現することができません。
The FXR package allows a gateway to implement additional fax handling parameters. We define just such a parameter by qualifying the existing "gw" parameter with a list of one or more MIME types:
FXRパッケージは、ゲートウェイは、追加のファックス処理パラメータを実装することができます。私たちは、一つ以上のMIMEタイプのリストで、既存の「GW」パラメータを修飾することによって、まさにこのようなパラメータを定義します。
Gateway = "gw[" mimeType 0*("|" mimeType) "]"
mimeType = mimeMediaType "/" mimeSubType
; mimeMediaType and mimeSubType from
; http://www.iana.org/assignments/media-types/
By qualifying the "gw" parameter with a list of MIME types, we narrow the scope of the gateway procedure. Consider the following examples in which the Call Agent authorizes the use of a gateway controlled fax handling procedure:
MIMEタイプのリストで、「GW」パラメータを修飾することによって、我々は、ゲートウェイ手順の範囲を狭めます。コールエージェントがゲートウェイ制御のファックス処理手順の使用を許可する次の例を考えてみます。
- involving "image/t38" (e.g., T.38oUDPTL, T.38oTCP):
- "画像/ T38"（例えば、T.38oUDPTL、T.38oTCP）を含みます。
L: a:G729, fxr/fx:gw[image/t38]
A：G729、FXR / FX：GW [画像/ T38]
- involving VBD (e.g., PCMU and V.152):
- VBD（例えば、PCMUとV.152）を含みます。
L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes", fxr/fx:gw[audio/PCMU]
L：G729; PCMU、gpmd / gpmd： "PCMU VBD = yes" を、FXR / FX：GW [オーディオ/ PCMU]
- involving VBD with redundancy (e.g., PCMU, V.152, and RFC 2198):
- 冗長性（例えば、PCMU、V.152、およびRFC 2198）とVBDを含みます。
L: a:G729;RED;PCMU, fmtp:"RED PCMU/PCMU", gpmd/gpmd:"PCMU vbd=yes", fxr/fx:gw[audio/RED|audio/PCMU]
L：G729; RED; PCMU、のfmtp： "RED PCMU / PCMU"、gpmd / gpmd： "PCMUのVBD = yes" を、FXR / FX：GW [オーディオ/ RED |オーディオ/ PCMU]
Only "special fax handling" involving one of the specified MIME types is authorized. Support for "special fax handling" involving one of the specified MIME types MUST be negotiated, or this "instance" of the gateway procedure is not initiated. Consider the following example in which the Call Agent authorizes the use of a gateway controlled fax handling procedure:
指定されたMIMEタイプのいずれかを含む唯一の「特別なファックスの取り扱いは、」許可されています。指定されたMIMEタイプのいずれかを含む「特別ファックス取扱い」のサポートが交渉しなければなりません、またはゲートウェイ手順のこの「インスタンス」が開始されていません。コールエージェントがゲートウェイ制御のファックス処理手順の使用を許可する次の例を考えてみましょう。
- involving "audio/t38" (e.g., T.38oRTP):
- 関係する "オーディオ/ T38"（例えば、T.38oRTP）：
L: a:G729;t38, fxr/fx:gw[audio/t38]
ジョー[アウディ/一口]：一口、破壊/ファックス; Juhas：A：の場合
In this example, the call will fail if the gateway fails to negotiate "audio/t38".
ゲートウェイは、「オーディオ/ T38」の交渉に失敗した場合は、この例では、コールは失敗します。
The "fx" LocalConnectionOption MAY now involve multiple instances of the "gw" parameter, each with a different list of MIME types. In order to authorize "no special fax handling", the Call Agent MUST include the "gw" parameter without a MIME type, or the "off" parameter. The instance of the "gw" parameter without a MIME type should appear as the last instance of the "gw" parameter. In the following example,
「FX」LocalConnectionOptionは今、「GW」パラメータの複数のインスタンス、MIMEタイプの別のリストとそれぞれを含むことができます。 「特別なファックスの取り扱い」を認可しないためには、コールエージェントは、MIMEタイプ、または「オフ」パラメータを指定せずに「GW」パラメータを含める必要があります。 MIMEタイプのない「GW」パラメータのインスタンスは、「GW」パラメータの最後のインスタンスとして表示されます。次の例では、
L: a:G729;PCMU, fxr/fx:gw[image/t38];gw
A：G729、PCMU、FXR / FX：GW [画像/ T38]; GW
the Call Agent authorizes the use of, and expresses a preference for,
コールエージェントが使用を許可、およびのための好みを表現し、
3. No special fax handling (this is a function of the "fxr/fx:gw" parameter as defined in Section 2.1 of the MGCP Fax (FXR) package [RFC5347])
3.特別なファックスを処理しない（これは、「FXR / FX：GW」の関数であるMGCPファックス（FXR）パッケージ[RFC5347]のセクション2.1で定義されたパラメータ）
If present, the "off" parameter should appear as the last parameter. In the following example,
存在する場合は、「オフ」パラメータが最後のパラメータとして表示されます。次の例では、
L: a:G729;PCMU;t38, fxr/fx:gw[audio/t38];off
A：G729、PCMU、T38、FXR / FX：GW [オーディオ/ T38];オフ
the Call Agent authorizes the use of, and expresses a preference for,
コールエージェントが使用を許可、およびのための好みを表現し、
We can express relative preferences for different gateway controlled fax handling procedures, not only with respect to one another, but with respect to T.38 procedures. Consider the following preferential list of fax handling procedures:
我々は、互いに対して、しかしT.38手順に関してだけでなく、異なるゲートウェイ制御ファックス処理手順の相対プリファレンスを表現することができます。ファックス処理手順の次の優先リストを考えてみましょう：
4. Gateway controlled VBD with redundancy (e.g., PCMU, V.152, and RFC 2198)
冗長性（例えば、PCMU、V.152、およびRFC 2198）4.ゲートウェイ制御VBD
7. No special fax handling (this is a function of the "fxr/fx:gw" parameter as defined in Section 2.1 of the MGCP Fax (FXR) package [RFC5347])
7.特別なファックスを処理しない（これは、「FXR / FX：GW」の関数であるMGCPファックス（FXR）パッケージ[RFC5347]のセクション2.1で定義されたパラメータ）
This would be expressed as
これは、次のように表現されるだろう
L: a:G729;PCMU;t38;RED;PCMU, gpmd/gpmd:"PCMU:2 vbd=yes", fmtp:"RED PCMU:2/PCMU:2", fxr/fx:gw[audio/t38|image/t38];t38;gw[audio/RED|audio/PCMU:2];gw
L：G729; PCMU; T38; RED; PCMU、gpmd / gpmd： "PCMU：2 VBD = yes" と、のfmtp： "RED PCMU：2 / PCMU：2"、FXR / FX：GW [オーディオ/ T38 |画像/ T38]; T38; GW [オーディオ/ RED |オーディオ/ PCMU：2]; GW
Note that the bracketed form of the "gw" parameter is NOT defined as part of the VBD package. The bracketed form of the "gw" parameter is defined as an extension to the FXR package. Gateways that implement the bracketed form of the "gw" parameter MUST return this form of the parameter when capabilities are audited as illustrated by the following example:
「GW」パラメータの括弧フォームがVBDパッケージの一部として定義されていないことに注意してください。 「GW」パラメータの括弧形態は、FXRパッケージへの拡張として定義されます。 「GW」パラメータの括弧のフォームを実装するゲートウェイは、次の例で示すように、機能が監査されるパラメータのこのフォームを返す必要があります。
A: fxr/fx:t38;t38-loose;gw[audio/t38|image/t38];gw;off
：FXR / FX：T38; T38、ルーズ; GW [オーディオ/ T38 |画像/ T38]; GW、オフ
Support for the bracketed "gw" parameter MAY be spread across multiple capability lines:
括弧「GW」パラメータのサポートは、複数の機能行にまたがることがあります。
A: a:RED;PCMU, p:10-40, e:on, s:off,
m:sendonly;recvonly;sendrecv;inactive,
gpmd/gpmd:"PCMU vbd=yes",
fmtp:"RED PCMU/PCMU",
fxr/fx:gw[audio/RED|audio/PCMU]
A: a:t38, fxr/fx:gw[audio/t38]
A: a:image/t38, fxr/fx:t38;t38-loose;gw[image/t38]
A Call Agent SHOULD only attempt to leverage the bracketed form of the "gw" parameter in conjunction with an endpoint that indicates support for the bracketed syntax as part of its capabilities.
コール・エージェントは、その機能の一部として括弧付き構文のサポートを示してエンドポイントと連動して、「GW」パラメータの括弧のフォームを活用しようとすべきです。
Call Agents and gateways that do not support this form of the "gw" parameter MUST ignore the bracketed MIME type information consistent with the MGCP grammar [RFC3435].
「GW」パラメータのこの形式をサポートしていないコールエージェントとゲートウェイは、MGCP文法[RFC3435]と一致括弧MIMEタイプの情報を無視しなければなりません。
In this section, we provide two call flow examples. The first one illustrates a modem call under gateway control using V.152. The second one illustrates a fax call under gateway control using V.152 and Call Agent controlled T.38.
このセクションでは、我々は2つのコールフローの例を示します。最初のものは、V.152を使用して、ゲートウェイの制御下でモデムコールを示します。二つ目は、V.152とコールエージェント制御のT.38を使用してゲートウェイ制御下にファックスコールを示しています。
In this example, both sides support gateway controlled VBD using V.152 with redundancy. We assume that the originating and terminating Call Agents communicate via the Session Initiation Protocol (SIP) [RFC3261]:
この例では、両側は、冗長性とV.152を使用して制御VBDゲートウェイサポート。我々は、発信および着信コールエージェントは、セッション開始プロトコル（SIP）[RFC3261]を介して通信すると仮定する。
------------------------------------------------------------------
| #| GW-o | CA-o | CA-t | GW-t |
|==|===============|===============|===============|===============|
| 1| <-|CRCX | | |
| 2| 200(sdp-o)|-> | | |
| 3| | INVITE(sdp-o)|-> | |
| 4| | | CRCX(sdp-o)|-> |
| 5| | | <-|200 (sdp-t) |
| 6| | <-|200(sdp-t) | |
| 7| <-|MDCX(sdp-t) | | |
| 8| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
| 9| | | |<- ANS/T.30 CED|
|10| | | <- NTFY(gwvbd start)|
|11| | | 200|-> |
|12|NTFY(gwvbd start) -> | | |
|13| <-|200 | | |
|--|---------------|---------------|---------------|---------------|
|14| | | | (modem ends) |
|15| | | <- NTFY(gwvbd stop) |
|16| | | 200|-> |
|17|NTFY(gwvbd stop) -> | | |
|18| <-|200 | | |
------------------------------------------------------------------
Step 1:
ステップ1：
The Call Agent issues a CreateConnection command to the gateway, instructing it to use G.729 media encoding and to notify it of the "gwvbd" and "nopvbd" events. The Call Agent authorizes the negotiation of G.711u as a VBD codec with a redundancy level of one:
コール・エージェントは、G.729メディアエンコーディングを使用すると、「gwvbd」と「nopvbd」のイベントのことを通知することを指示し、ゲートウェイにのCreateConnectionコマンドを発行します。コールエージェントは1の冗長レベルとVBDコーデックなどにG.711uの交渉を許可します：
CRCX 1000 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 C: 1 L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU" M: recvonly R: vbd/gwvbd, vbd/nopvbd X: 1 Q: process, loop
CRCX千ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 C：1 L：G729; RED; PCMU、gpmd / gpmd： "PCMUのVBD = YES" のfmtp：「RED PCMU / PCMU 「M：がrecvonly R：VBD / gwvbd、VBD / nopvbd X：1 Q：プロセス、ループ
Step 2:
ステップ2：
The gateway acknowledges the command and includes SDP with codec information as well as V.152 and redundancy information:
ゲートウェイは、コマンドを認識し、コーデック情報、ならびにV.152および冗長情報をSDPを含みます。
200 1000 OK
I:1
v=0 o=- 25678 753849 IN IP4 192.0.2.1 s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 3456 RTP/AVP 18 96 97 a=rtpmap:96 RED/8000 a=fmtp:96 97/97 a=rtpmap:97 PCMU/8000 a=gpmd:97 vbd=yes
V = 0 = 0 - C = IN IP4 192.0.2.1 T = 0、M =オーディオ3456 RTP / AVP 18 96 97 = rtpmap - IP4 192.0.2.1 S = IN 25678 753849：96 RED / 8000 =のfmtp：96 97分の97 A = rtpmap：97 PCMU / 8000 = gpmd：97 VBD =はい
Step 3:
ステップ3：
The originating Call Agent sends a SIP INVITE message with the SDP to the terminating Call Agent.
発信エージェントは、SIPを終端するコールエージェントにSDPをINVITEメッセージを送信します。
Step 4:
ステップ4：
The terminating Call Agent issues a CreateConnection command to the terminating gateway, instructing it to use G.729 media encoding and to notify it of the "gwvbd" and "nopvbd" events. Again, the Call Agent authorizes the negotiation of G.711u as a VBD codec with a redundancy level of one:
着呼エージェントは、G.729メディアエンコーディングを使用すると、「gwvbd」と「nopvbd」のイベントのことを通知することを指示し、終端ゲートウェイへのCreateConnectionコマンドを発行します。ここでも、コールエージェントは1の冗長レベルとVBDコーデックとしてにG.711uの交渉を許可します：
CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 C: 2 L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU" M: sendrecv R: vbd/gwvbd, vbd/nopvbd X: 20 Q: process, loop v=0 o=- 25678 753849 IN IP4 192.0.2.1 s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 3456 RTP/AVP 18 96 97 a=rtpmap:96 RED/8000 a=fmtp:96 97/97 a=rtpmap:97 PCMU/8000 a=gpmd:97 vbd=yes
CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 C：2 L：G729; RED; PCMU、gpmd / gpmd： "PCMUのVBD = YES" のfmtp：「RED PCMU / PCMU 「M：のsendrecv R：VBD / gwvbd、VBD / nopvbd X：20 Q：プロセス、ループV = 0 0 = - C = IN IP4 192.0.2.1 T = 0、M = - 25678 753849 IP4 192.0.2.1 S = INオーディオ3456 RTP / AVP 18 96 97 = rtpmap：/ 8000 96 RED =のfmtp：96 97分の97 A = rtpmap：97 PCMU / 8000 = gpmd：97 VBD =はい
Step 5:
ステップ5：
The terminating gateway supports V.152 and redundancy, and the RemoteConnectionDescriptor included indicates that the other side supports V.152 and redundancy. The terminating gateway sends back a success response with its SDP, which also includes V.152 and redundancy information:
終端ゲートウェイは、V.152と冗長性をサポートし、RemoteConnectionDescriptorが含まれる他側はV.152と冗長性をサポートしていることを示しています。終端ゲートウェイはまたV.152および冗長情報を含むそのSDPと成功応答を返信します。
200 2000 OK
I:2
v=0 o=- 25678 753849 IN IP4 192.0.2.2 s=- c=IN IP4 192.0.2.2 t=0 0 m=audio 1296 RTP/AVP 18 96 97 a=rtpmap:96 RED/8000 a=fmtp:96 97/97 a=rtpmap:97 PCMU/8000 a=gpmd:97 vbd=yes
V = 0 = 0 - C = IN IP4 192.0.2.2 T = 0、M =オーディオ1296 RTP / AVP 18 96 97 = rtpmap - IP4 192.0.2.2 S = IN 25678 753849：96 RED / 8000 =のfmtp：96 97分の97 A = rtpmap：97 PCMU / 8000 = gpmd：97 VBD =はい
Step 6:
ステップ6：
The terminating Call Agent sends back a SIP 200 OK response to the originating Call Agent, which in turn sends a SIP ACK (not shown).
終了コールエージェントが順番にSIP ACKを送信発信エージェントにSIP 200 OK応答を返す（図示せず）。
Step 7:
ステップ7：
The originating Call Agent in turn sends a ModifyConnection command to the originating gateway:
順番に発信エージェントは発信ゲートウェイにModifyConnectionコマンドを送信します。
MDCX 1001 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
I: 1
M: sendrecv
v=0 o=- 25678 753849 IN IP4 192.0.2.2 s=- c=IN IP4 192.0.2.2 t=0 0 m=audio 1296 RTP/AVP 18 96 97 a=rtpmap:96 RED/8000 a=fmtp:96 97/97 a=rtpmap:97 PCMU/8000 a=gpmd:97 vbd=yes
V = 0 = 0 - C = IN IP4 192.0.2.2 T = 0、M =オーディオ1296 RTP / AVP 18 96 97 = rtpmap - IP4 192.0.2.2 S = IN 25678 753849：96 RED / 8000 =のfmtp：96 97分の97 A = rtpmap：97 PCMU / 8000 = gpmd：97 VBD =はい
Since the RemoteConnectionDescriptor indicates that the other side supports V.152 and redundancy, the gateway will in fact be able to use the gateway controlled VBD procedure with redundancy. Had there not been any support for V.152 in the RemoteConnectionDescriptor, then this command would still have succeeded; however, there would be no negotiated procedure for VBD handling.
RemoteConnectionDescriptorは反対側がV.152と冗長性をサポートしていることを示しているので、ゲートウェイは、実際に冗長性とゲートウェイ制御VBDプロシージャを使用することができるであろう。そこRemoteConnectionDescriptorでのV.152のための任意のサポートがなかったら、このコマンドは、まだ成功しています。しかし、VBDの取り扱いには交渉した手順はないだろう。
Step 8:
ステップ8：
The gateway acknowledges the command. At this point, a call is established using G.729 encoding, and if a VBD call is detected, the gateway controlled VBD procedure will be initiated.
ゲートウェイはコマンドを認めています。この時点で、コールはG.729符号化を使用して確立され、及びVBDコールが検出された場合、ゲートウェイ制御VBD手順が開始されます。
Steps 9-10:
9-10手順：
A modem call now occurs. The terminating gateway detects a T.30 CED tone (a.k.a. V.25 ANS) in the GSTN-to-IP direction and begins transmitting RTP packets with the negotiated redundant VBD payload type (96).
モデムコールは今起こります。終端ゲートウェイはGSTNツーIP方向にT.30 CEDトーン（別名V.25のANS）を検出し、ネゴシエート冗長VBDペイロードタイプ（96）とRTPパケットの送信を開始します。
The "gwvbd(start)" event occurs, and a Notify command is sent to the Call Agent:
「gwvbd（スタート）」イベントが発生すると、通知コマンドがコールエージェントに送信されます。
NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: vbd/gwvbd(start, rc=ANS, codec=audio/RED, coord=v152ptsw)
X: 20
Step 11:
ステップ11：
The Call Agent acknowledges the Notify command:
コール・エージェントは通知コマンドを認識します：
200 2500 OK
200 2500 OK
Step 12:
ステップ12：
Upon receiving an RTP packet with the redundant VBD payload type (96), the originating gateway begins transmitting RTP packets with the redundant VBD payload type.
冗長VBDペイロードタイプ（96）とRTPパケットを受信すると、発信側ゲートウェイは、冗長VBDペイロードタイプと、RTPパケットの送信を開始します。
The "gwvbd(start)" event occurs, and a Notify command is sent to the Call Agent:
「gwvbd（スタート）」イベントが発生すると、通知コマンドがコールエージェントに送信されます。
NTFY 1500 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
O: vbd/gwvbd(start, rc=PTSW, codec=audio/RED)
X: 1
Step 13:
ステップ13：
The Call Agent acknowledges the Notify command:
コール・エージェントは通知コマンドを認識します：
200 1500 OK
200 1500 OK
Steps 14-15:
14-15手順：
The modem call ends. The terminating gateway detects bidirectional silence and begins transmitting RTP packets with the negotiated audio payload type (18).
モデムコールが終了します。終端ゲートウェイは、双方向無音を検出し、ネゴシエートオーディオペイロードタイプ（18）とRTPパケットの送信を開始します。
The "gwvbd(stop)" event occurs, and a Notify command is sent to the Call Agent:
「gwvbd（停止）」イベントが発生すると、通知コマンドがコールエージェントに送信されます。
NTFY 2501 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: vbd/gwvbd(stop, rc=SIL, codec=audio/G729)
X: 20
Step 16:
ステップ16：
The Call Agent acknowledges the Notify command:
コール・エージェントは通知コマンドを認識します：
200 2501 OK
200 2501 OK
Step 17:
ステップ17：
Upon receiving an RTP packet with the audio payload type (18), the originating gateway begins transmitting RTP packets with the audio payload type.
オーディオペイロードタイプ（18）とRTPパケットを受信すると、発信側ゲートウェイは、オーディオペイロードタイプと、RTPパケットの送信を開始します。
The "gwvbd(stop)" event occurs, and a Notify command is sent to the Call Agent:
「gwvbd（停止）」イベントが発生すると、通知コマンドがコールエージェントに送信されます。
NTFY 1501 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
O: vbd/gwvbd(stop, rc=PTSW, codec=audio/G729)
X: 1
Step 18:
ステップ18：
The Call Agent acknowledges the Notify command:
コール・エージェントは通知コマンドを認識します：
200 1501 OK
200 1501 OK
The modem call is now over.
モデムコールが終わりました。
9.2. Fax Call with Gateway Controlled VBD and Call Agent Controlled T.38
9.2. ゲートウェイ制御VBDとコールエージェントの制御T.38ファックスでのコール
In this example, both sides support gateway controlled VBD using V.152 with redundancy and Call Agent controlled T.38. We assume that the originating and terminating Call Agent communicate via the Session Initiation Protocol (SIP) [RFC3261]:
この例では、両側は、冗長性とコール・エージェント制御T.38とV.152を使用して制御VBDゲートウェイサポート。私たちは、発信および着信呼エージェントがセッション開始プロトコル（SIP）[RFC3261]を介して通信することを前提としています。
------------------------------------------------------------------
| #| GW-o | CA-o | CA-t | GW-t |
|==|===============|===============|===============|===============|
| 1| <-|CRCX | | |
| 2| 200(sdp-o)|-> | | |
| 3| | INVITE(sdp-o)|-> | |
| 4| | | CRCX(sdp-o)|-> |
| 5| | | <-|200 (sdp-t) |
| 6| | <-|200(sdp-t) | |
| 7| <-|MDCX(sdp-t) | | |
| 8| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
| 9| | | |<- ANS/T.30 CED|
|10| | | <- NTFY(gwvbd start)|
|11| | | 200|-> |
|12|NTFY(gwvbd start) -> | | |
|13| <-|200 | | |
|14| | | <- V.21 Preamble|
|15| | | <- NTFY(t38 start)|
|16| | | 200|-> |
|17| | | MDCX(t38)|-> |
|18| | | <-|200(sdp-t2) |
|19| | <-|INVITE(sdp-t2) | |
|20| <-|MDCX(sdp-t2) | | |
|21| 200(sdp-o2)|-> | | |
|22| | 200(sdp-o2)|-> | |
|23| | | MDCX(sdp-o2)|-> |
|24| | | <-|200 |
|25| V.21 Preamble |-> | | |
|26|NTFY(t38 start)|-> | | |
|27| <-|200 | | |
|--|---------------|---------------|---------------|---------------|
|28| | | | (fax ends) |
|29| | | <-|NTFY(t38 stop) |
|30| | | 200|-> |
|31|NTFY(t38 stop) |-> | | |
|32| <-|200 | | |
------------------------------------------------------------------
Step 1:
ステップ1：
The Call Agent issues a CreateConnection command to the gateway, instructing it to use G.729 media encoding and to use either the strict T.38 procedure or the gateway procedure. Consequently, the Call Agent requests notification of the "t38", "gwfax", "gwvbd", and "nopvbd" events. The Call Agent authorizes the negotiation of G.711u as a VBD codec with a redundancy level of one:
コール・エージェントは、G.729メディアエンコーディングを使用し、厳格なT.38手順またはゲートウェイの手順のいずれかを使用するように指示し、ゲートウェイにのCreateConnectionコマンドを発行します。その結果、コールエージェントは、「T38」、「gwfax」、「gwvbd」、および「nopvbd」のイベントの通知を要求します。コールエージェントは1の冗長レベルとVBDコーデックなどにG.711uの交渉を許可します：
CRCX 1000 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 C: 1 L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU", fxr/fx:t38;gw M: recvonly R: fxr/t38, fxr/gwfax, vbd/gwvbd, vbd/nopvbd X: 1 Q: process, loop
CRCX千ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 C：1 L：G729; RED; PCMU、gpmd / gpmd： "PCMUのVBD = YES" のfmtp：「RED PCMU / PCMU 」FXR / FX：T38; GW M：がrecvonly R：FXR / T38、FXR / gwfax、VBD / gwvbd、VBD / nopvbd X：1 Q：プロセス、ループ
Step 2:
ステップ2：
The gateway acknowledges the command and includes SDP with codec information as well as capability, V.152, and redundancy information:
ゲートウェイは、コマンドを認識し、コーデック情報、ならびに能力、V.152、および冗長情報をSDPを含みます。
200 1000 OK
I:1
v=0 o=- 25678 753849 IN IP4 192.0.2.1 s=- c=IN IP4 192.0.2.1 t=0 0 a=pmft: T38 m=audio 3456 RTP/AVP 18 96 97 a=rtpmap:96 RED/8000 a=fmtp:96 97/97 a=rtpmap:97 PCMU/8000 a=gpmd:97 vbd=yes a=sqn: 0 a=cdsc: 1 audio RTP/AVP 18 96 97 a=cdsc: 4 image udptl t38
V = 0 = 0 - IN 25678 753849 IP4 192.0.2.1 S = - C = IN IP4 192.0.2.1 T = 0、A = pmft：T38のM =オーディオ3456 RTP / AVP 18 96 97 = rtpmap：96 RED / 8000 A =のfmtp：96 97分の97 A = rtpmap：97 PCMU / 8000 = gpmd：97 VBD = = YESのSQN：0 = CDSC：1オーディオRTP / AVP 18 96 97 = CDSC：4画像UDPTLのT38
Note that V.152 requires the use of the session-level "a=pmft" SDP attribute in order to express a preference for T.38 over V.152 for fax handling.
V.152がFAX処理用V.152上T.38に対する好みを表現するために「= pmft」SDP属性セッション・レベルの使用を必要とすることに留意されたいです。
Step 3:
ステップ3：
The originating Call Agent sends a SIP INVITE message with the SDP to the terminating Call Agent.
発信エージェントは、SIPを終端するコールエージェントにSDPをINVITEメッセージを送信します。
Step 4:
ステップ4：
The terminating Call Agent issues a CreateConnection command to the terminating gateway, instructing it to use G.729 media encoding and to use either the strict T.38 procedure or the gateway procedure. Consequently, the Call Agent requests notification of the "t38", "gwfax", "gwvbd", and "nopvbd" events. Again, the Call Agent authorizes the negotiation of G.711u as a VBD codec with a redundancy level of one:
終端コール・エージェントは、G.729メディアエンコーディングを使用し、厳密T.38手順またはゲートウェイ手順のいずれかを使用するように指示し、終端ゲートウェイへのCreateConnectionコマンドを発行します。その結果、コールエージェントは、「T38」、「gwfax」、「gwvbd」、および「nopvbd」のイベントの通知を要求します。ここでも、コールエージェントは1の冗長レベルとVBDコーデックとしてにG.711uの交渉を許可します：
CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 C: 2 L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU", fxr/fx:t38;gw M: sendrecv R: fxr/t38, fxr/gwfax, vbd/gwvbd, vbd/nopvbd X: 20 Q: process, loop
CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 C：2 L：G729; RED; PCMU、gpmd / gpmd： "PCMUのVBD = YES" のfmtp：「RED PCMU / PCMU 」FXR / FX：T38; GW M：のsendrecv R：FXR / T38、FXR / gwfax、VBD / gwvbd、VBD / nopvbd X：20 Q：プロセス、ループ
v=0 o=- 25678 753849 IN IP4 192.0.2.1 s=- c=IN IP4 192.0.2.1 t=0 0 a=pmft: T38 m=audio 3456 RTP/AVP 18 96 97 a=rtpmap:96 RED/8000 a=fmtp:96 97/97 a=rtpmap:97 PCMU/8000 a=gpmd:97 vbd=yes a=sqn: 0 a=cdsc: 1 audio RTP/AVP 18 96 97 a=cdsc: 4 image udptl t38
V = 0 = 0 - IN 25678 753849 IP4 192.0.2.1 S = - C = IN IP4 192.0.2.1 T = 0、A = pmft：T38のM =オーディオ3456 RTP / AVP 18 96 97 = rtpmap：96 RED / 8000 A =のfmtp：96 97分の97 A = rtpmap：97 PCMU / 8000 = gpmd：97 VBD = = YESのSQN：0 = CDSC：1オーディオRTP / AVP 18 96 97 = CDSC：4画像UDPTLのT38
Step 5:
ステップ5：
The terminating gateway supports T.38, and the RemoteConnectionDescriptor included indicates that the other side supports T.38 as well, so the strict T.38 Call Agent controlled procedure requested can be used. The terminating gateway supports V.152 and redundancy, and the RemoteConnectionDescriptor included indicates that the other side supports V.152 and redundancy, so gateway controlled VBD using V.152 and redundancy can be used for modem and text transmissions. The terminating gateway sends back a success response with its SDP, which also includes capability, V.152, and redundancy information:
終端ゲートウェイはT.38をサポートし、そしてRemoteConnectionDescriptorが含ま反対側も同様にT.38をサポートすることを示しているので、要求された厳密T.38 Callエージェント制御手順を使用することができます。終端ゲートウェイは、V.152と冗長性をサポートし、RemoteConnectionDescriptorが含まれる他側はV.152と冗長性をサポートしていることを示しているので、V.152と冗長性は、モデムやテキスト送信のために使用することができる使用して制御VBDゲートウェイ。終端ゲートウェイはまた、能力、V.152、および冗長情報を含むそのSDPと成功応答を返信します。
200 2000 OK
I:2
v=0 o=- 25678 753849 IN IP4 192.0.2.2 s=- c=IN IP4 192.0.2.2 t=0 0 a=pmft: T38 m=audio 1296 RTP/AVP 18 96 97 a=rtpmap:96 RED/8000 a=fmtp:96 97/97 a=rtpmap:97 PCMU/8000 a=gpmd:97 vbd=yes a=sqn: 0 a=cdsc: 1 audio RTP/AVP 18 96 97 a=cdsc: 4 image udptl t38
V = 0 = 0 - IN 25678 753849 IP4 192.0.2.2 S = - C = IN IP4 192.0.2.2 T = 0、A = pmft：T38のM =オーディオ1296 RTP / AVP 18 96 97 = rtpmap：96 RED / 8000 A =のfmtp：96 97分の97 A = rtpmap：97 PCMU / 8000 = gpmd：97 VBD = = YESのSQN：0 = CDSC：1オーディオRTP / AVP 18 96 97 = CDSC：4画像UDPTLのT38
Step 6:
ステップ6：
The terminating Call Agent sends back a SIP 200 OK response to the originating Call Agent, which in turn sends a SIP ACK (not shown).
終了コールエージェントが順番にSIP ACKを送信発信エージェントにSIP 200 OK応答を返す（図示せず）。
Step 7:
ステップ7：
The originating Call Agent in turn sends a ModifyConnection command to the originating gateway:
順番に発信エージェントは発信ゲートウェイにModifyConnectionコマンドを送信します。
MDCX 1001 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
I: 1
M: sendrecv
v=0 o=- 25678 753849 IN IP4 192.0.2.2 s=- c=IN IP4 192.0.2.2 t=0 0 a=pmft: T38 m=audio 1296 RTP/AVP 18 96 97 a=rtpmap:96 RED/8000 a=fmtp:96 97/97 a=rtpmap:97 PCMU/8000 a=gpmd:97 vbd=yes a=sqn: 0 a=cdsc: 1 audio RTP/AVP 18 96 97 a=cdsc: 4 image udptl t38
V = 0 = 0 - IN 25678 753849 IP4 192.0.2.2 S = - C = IN IP4 192.0.2.2 T = 0、A = pmft：T38のM =オーディオ1296 RTP / AVP 18 96 97 = rtpmap：96 RED / 8000 A =のfmtp：96 97分の97 A = rtpmap：97 PCMU / 8000 = gpmd：97 VBD = = YESのSQN：0 = CDSC：1オーディオRTP / AVP 18 96 97 = CDSC：4画像UDPTLのT38
The ModifyConnection command does not repeat the LocalConnectionOptions sent previously. As far as fax handling is concerned, the gateway therefore attempts to continue using the current fax handling procedure, i.e., strict Call Agent controlled T.38. Since the capability information indicates that the other side supports T.38, the gateway will in fact be able to use the strict Call Agent controlled T.38 procedure. Since the
ModifyConnectionコマンドは、以前に送られたLocalConnectionOptionsを繰り返していません。限りファックスの取り扱いに関しては、ゲートウェイは、したがって、現在のファックス処理手順、すなわち、厳密Callエージェント制御T.38を継続して使用しようとします。能力情報は、他の側がT.38をサポートしていることを示しているため、ゲートウェイは、実際には、厳密なコールエージェント制御のT.38手順を使用することができるようになります。から
RemoteConnectionDescriptor indicates that the other side supports V.152 and redundancy, the gateway will in fact be able to use the V.152 VBD procedure with redundancy.
RemoteConnectionDescriptor他側はV.152と冗長性をサポートし、ゲートウェイは、実際に冗長性V.152 VBDプロシージャを使用することができるであろうことを示しています。
Step 8:
ステップ8：
The gateway acknowledges the command. At this point, a call is established using G.729 encoding, and if a fax call is detected, the Call Agent controlled T.38 procedure will be initiated. If a modem or text call is detected, the V.152 VBD procedure will be initiated.
ゲートウェイはコマンドを認めています。この時点で、コールはG.729エンコーディングを使用して確立され、FAXコールが検出された場合、コールエージェント制御のT.38手順が開始されます。モデムやテキストの呼び出しが検出された場合、V.152 VBD手順が開始されます。
Steps 9-10:
9-10手順：
The terminating gateway detects the T.30 CED tone (a.k.a. V.25 ANS). Since both fax and modem calls can start with this sequence, it is not possible to determine that this is a fax call until step 14, where the V.21 fax preamble is detected. The terminating gateway begins transmitting RTP packets with the negotiated redundant VBD payload type (96).
終端ゲートウェイはT.30 CEDトーン（別名V.25のANS）を検出します。両方のファックスモデムコールがこの順序で開始することができるので、V.21ファックスプリアンブルが検出されるステップ14までFAXコールであることを決定することは不可能です。終端ゲートウェイはネゴシエート冗長VBDペイロードタイプ（96）とRTPパケットの送信を開始します。
The "gwvbd(start)" event occurs, and a Notify command is sent to the Call Agent:
「gwvbd（スタート）」イベントが発生すると、通知コマンドがコールエージェントに送信されます。
NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: vbd/gwvbd(start, rc=ANS, codec=audio/RED, coord=v152ptsw)
X: 20
Step 11:
ステップ11：
The Call Agent acknowledges the Notify command:
コール・エージェントは通知コマンドを認識します：
200 2500 OK
200 2500 OK
Step 12:
ステップ12：
Upon receiving an RTP packet with the redundant VBD payload type (96), the originating gateway begins transmitting RTP packets with the redundant VBD payload type.
冗長VBDペイロードタイプ（96）とRTPパケットを受信すると、発信側ゲートウェイは、冗長VBDペイロードタイプと、RTPパケットの送信を開始します。
The "gwvbd(start)" event occurs, and a Notify command is sent to the Call Agent:
「gwvbd（スタート）」イベントが発生すると、通知コマンドがコールエージェントに送信されます。
NTFY 1500 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
O: vbd/gwvbd(start, rc=PTSW, codec=audio/RED)
X: 1
Step 13:
ステップ13：
The Call Agent acknowledges the Notify command:
コール・エージェントは通知コマンドを認識します：
200 1500 OK
200 1500 OK
Steps 14-15:
14-15手順：
The terminating gateway detects the V.21 fax preamble.
終端ゲートウェイは、V.21ファックスプリアンブルを検出します。
The terminating gateway is using the Call Agent controlled T.38 strict procedure for fax calls, so the "t38(start)" event occurs, and a Notify command is sent to the Call Agent:
「T38（開始）」イベントが発生し、通知コマンドがCallエージェントに送信されるように、終端ゲートウェイは、FAXコールのためのコール・エージェント制御T.38厳密な手順を使用しています
NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: fxr/t38(start)
X: 20
Step 16:
ステップ16：
The Call Agent acknowledges the Notify command:
コール・エージェントは通知コマンドを認識します：
200 2500 OK
200 2500 OK
Step 17:
ステップ17：
The Call Agent then instructs the terminating gateway to change to using the "image/t38" MIME type instead:
コール・エージェントは、代わりに、「画像/ T38」MIMEタイプを使用するように変更する終端ゲートウェイに指示します。
MDCX 2002 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 2
I: 2
L: a:image/t38
R: fxr/t38
X: 21
Note that the Call Agent is no longer requesting notification of the "gwvbd" event.
コールエージェントは、もはや「gwvbd」イベントの通知を要求していることに注意してください。
Step 18:
ステップ18：
The terminating gateway sends back a success response with its SDP, which also includes the "image/t38" media description:
終端ゲートウェイはまた、「画像/ T38」メディア記述を含むそのSDPと成功応答を返信します。
200 2002 OK
200 2002 OK
v=0 o=- 25678 753850 IN IP4 192.0.2.2 s=- c=IN IP4 192.0.2.2 t=0 0 m=image 1296 udptl t38 a=sqn: 0 a=cdsc: 1 audio RTP/AVP 18 96 97 a=cpar: a=rtpmap:96 RED/8000 a=cpar: a=fmtp:96 97/97 a=cpar: a=rtpmap:97 PCMU/8000 a=cpar: a=gpmd:97 vbd=yes a=cdsc: 4 image udptl t38
V = 0 0 = - C = IN IP4 192.0.2.2 T = 0、M =画像1296 UDPTLのT38のA = SQN - IP4 192.0.2.2 S = IN 25678 753850：0 = CDSC：1オーディオRTP / AVP 18 96 97 A = CPAR：A = rtpmap：96 RED / 8000 = CPAR：A =のfmtp：96 97分の97 = CPAR：A = rtpmap：97 PCMU / 8000 = CPAR：A = gpmd：97 VBD = YES = CDSC：4画像UDPTLのT38
The gwvbd procedure ends due to the media type change. The "gwvbd(stop)" event notification would normally be sent at this point; however, the Call Agent is no longer requesting notification of the "gwvbd" event. The Call Agent would have inferred from the "t38(start)" event that the gwvbd procedure ended.
gwvbd手順が原因メディアタイプの変更に終了します。 「gwvbd（停止）」のイベント通知は、通常、この時点で送信されます。しかし、コールエージェントは、もはや「gwvbd」イベントの通知を要求されません。コール・エージェントは、「T38（スタート）」gwvbd手続きが終了したイベントから推測するだろう。
Step 19:
ステップ19：
The terminating Call Agent sends a re-INVITE to the originating Call Agent with the updated SDP.
着呼エージェントが更新されSDPに発信エージェントに再INVITEを送信します。
Step 20:
ステップ20：
The originating Call Agent then sends a ModifyConnection command to the originating gateway:
発信エージェントはその後、発信ゲートウェイにModifyConnectionコマンドを送信します。
MDCX 1003 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
I: 1
R: fxr/t38
X: 2
v=0 o=- 25678 753850 IN IP4 192.0.2.2 s=- c=IN IP4 192.0.2.2 t=0 0 m=image 1296 udptl t38 a=sqn: 0 a=cdsc: 1 audio RTP/AVP 18 96 97 a=cpar: a=rtpmap:96 RED/8000 a=cpar: a=fmtp:96 97/97 a=cpar: a=rtpmap:97 PCMU/8000 a=cpar: a=gpmd:97 vbd=yes a=cdsc: 4 image udptl t38
V = 0 0 = - C = IN IP4 192.0.2.2 T = 0、M =画像1296 UDPTLのT38のA = SQN - IP4 192.0.2.2 S = IN 25678 753850：0 = CDSC：1オーディオRTP / AVP 18 96 97 A = CPAR：A = rtpmap：96 RED / 8000 = CPAR：A =のfmtp：96 97分の97 = CPAR：A = rtpmap：97 PCMU / 8000 = CPAR：A = gpmd：97 VBD = YES = CDSC：4画像UDPTLのT38
Step 21:
ステップ21：
The originating gateway changes to T.38 and sends back a success response with the updated SDP:
発信ゲートウェイのT.38への変更や更新SDPの成功の応答を返します：
200 1003 OK
200 1003 OK
v=0 o=- 25678 753850 IN IP4 192.0.2.1 s=- c=IN IP4 192.0.2.1 t=0 0 m=image 3456 udptl t38 a=sqn: 0 a=cdsc: 1 audio RTP/AVP 18 96 97 a=cpar: a=rtpmap:96 RED/8000 a=cpar: a=fmtp:96 97/97 a=cpar: a=rtpmap:97 PCMU/8000 a=cpar: a=gpmd:97 vbd=yes a=cdsc: 4 image udptl t38
V = 0 0 = - C = IN IP4 192.0.2.1 T = 0、M =画像3456 UDPTLのT38のA = SQN - IP4 192.0.2.1 S = IN 25678 753850：0 = CDSC：1オーディオRTP / AVP 18 96 97 A = CPAR：A = rtpmap：96 RED / 8000 = CPAR：A =のfmtp：96 97分の97 = CPAR：A = rtpmap：97 PCMU / 8000 = CPAR：A = gpmd：97 VBD = YES = CDSC：4画像UDPTLのT38
Again, the gwvbd procedure ends due to the media type change. The "gwvbd(stop)" event notification would normally be sent at this point; however, the Call Agent is no longer requesting notification of the "gwvbd" event.
ここでも、gwvbd手順が原因メディアタイプの変更に終了します。 「gwvbd（停止）」のイベント通知は、通常、この時点で送信されます。しかし、コールエージェントは、もはや「gwvbd」イベントの通知を要求されません。
Step 22:
ステップ22：
The originating Call Agent sends a SIP 200 OK response with the updated SDP to the terminating Call Agent, which in turn sends a SIP ACK (not shown).
発信エージェントが順番にSIP ACKを送信終了のコールエージェントへの更新SDPとSIP 200 OK応答を送信し（図示せず）。
Step 23:
ステップ23：
The terminating Call Agent sends a ModifyConnection with the updated SDP to the terminating gateway:
着信呼エージェントは、終端ゲートウェイへの更新SDPとModifyConnectionを送信します。
MDCX 2002 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 2
I: 2
v=0 o=- 25678 753850 IN IP4 192.0.2.1 s=- c=IN IP4 192.0.2.1 t=0 0 m=image 3456 udptl t38 a=sqn: 0 a=cdsc: 1 audio RTP/AVP 18 96 97 a=cpar: a=rtpmap:96 RED/8000 a=cpar: a=fmtp:96 97/97 a=cpar: a=rtpmap:97 PCMU/8000 a=cpar: a=gpmd:97 vbd=yes a=cdsc: 4 image udptl t38
V = 0 0 = - C = IN IP4 192.0.2.1 T = 0、M =画像3456 UDPTLのT38のA = SQN - IP4 192.0.2.1 S = IN 25678 753850：0 = CDSC：1オーディオRTP / AVP 18 96 97 A = CPAR：A = rtpmap：96 RED / 8000 = CPAR：A =のfmtp：96 97分の97 = CPAR：A = rtpmap：97 PCMU / 8000 = CPAR：A = gpmd：97 VBD = YES = CDSC：4画像UDPTLのT38
Steps 24-32:
24-32手順：
These steps correspond to the Call Agent controlled T.38 strict procedure as defined in the MGCP Fax (FXR) package [RFC5347].
MGCPファックス（FXR）パッケージ[RFC5347]で定義されるように、これらのステップは、コールエージェント制御T.38厳格な手順に対応します。
This document defines two new packages, both of which have security considerations in two areas:
この文書では、二つの領域では、セキュリティ上の考慮事項があり、どちらも2つの新しいパッケージを、定義しています。
From an MGCP signaling security point of view, the MGCP VBD and GPMD packages define extensions to the basic MGCP signaling specification in accordance with the procedures specified in MGCP [RFC3435], and hence the MGCP signaling security considerations and recommendations provided in Section 5 of [RFC3435] (namely the use of IPsec) apply here as well. Lack of MGCP signaling integrity protection can in general be detrimental to any use of MGCP, and the two packages defined here do not change that. From a confidentiality point of view, the VBD package is not believed to convey any vulnerable or privacy-sensitive information. The GPMD package is slightly different inasmuch as it does not define any specific parameters that are believed to require confidentiality; however, it is a generic parameter that can carry any codec parameter information, and hence it is possible that confidential information is conveyed through this parameter. If confidentiality of any such potential information is a concern, confidentiality protection of the MGCP signaling MUST be provided as well. It should be noted that Section 8 of [RFC5406] provides considerations for specifying the use of IPsec that are above and beyond those provided in [RFC3435]; however, given that the use of IPsec for MGCP applies to all of MGCP, and not just the MGCP VBD and GPMD packages, we do not specify such additional detail here.
セキュリティの観点シグナリングMGCPから、[MGCP VBDとGPMDパッケージはMGCPで指定された手順に従って仕様シグナリング基本的なMGCP [RFC3435]の拡張機能を定義し、したがって、MGCPは、セクション5で提供されるセキュリティの考慮事項および推奨シグナリングRFC3435]（IPsecののすなわち使用）もここに適用されます。 MGCPシグナリング完全性保護の欠如は、一般的にMGCPのいずれかの使用に有害となる可能性があり、ここで定義された2つのパッケージには、それを変更しないでください。ビューの機密保持の観点から、VBDパッケージは、任意の脆弱やプライバシーに敏感な情報を伝えるために考えられません。 GPMDパッケージには、機密性を必要とすると考えられている任意の特定のパラメータを定義しない限り、若干異なっています。しかし、それはどのコーデックパラメータ情報を運ぶことができる汎用的なパラメータであり、そのためには、機密情報がこのパラメータを搬送することも可能です。そのような可能性のある情報の機密性が懸念される場合は、MGCPシグナリングの機密性保護も同様に提供されなければなりません。それは[RFC5406]のセクション8は、上記とに設けられたものを超えているのIPsecの使用を指定するための考慮事項を提供することに留意すべきである[RFC3435]。しかし、MGCPのためのIPsecの使用は、MGCPの全てに適用されるだけではなく、MGCP VBDとGPMDパッケージことを考えると、我々はここで、このような追加の詳細を指定しないでください。
From a media stream security point of view, the MGCP VBD and GPMD packages again define extensions that rely on the general use of media streams defined in MGCP [RFC3435], and hence the MGCP media stream security considerations and recommendations provided in Section 5.1 of [RFC3435] apply here as well. Lack of media stream security can in general be detrimental to any media stream established via MGCP, and the two packages defined here do not change that. Confidentiality concerns apply as for any other media stream. Integrity concerns are further compounded by the GPMD package's use of payload type switching, state signaling events, and media stream in-band triggers to drive overall Voiceband Data operation: Integrity protection with replay protection MUST be used to counter these threats.
ビューのメディア・ストリーム・セキュリティの観点から、MGCP VBDとGPMDパッケージは再びMGCP [RFC3435]で定義されたメディアストリームの一般的な使用に依存している拡張機能を定義し、したがって、MGCPメディアストリームのセキュリティの考慮事項および推奨事項は、セクション5.1に提供[ RFC3435]ここにも適用されます。メディアストリームのセキュリティの欠如は、一般的にMGCPを介して確立任意のメディアストリームに有害であることができ、ここで定義された2つのパッケージには、それを変更しないでください。機密性の懸念は、他のメディアストリームのためとして適用されます。整合性の懸念はさらに、インバンドペイロードタイプの切り替え、状態シグナル伝達事象、およびメディアストリームのGPMDパッケージの使用によって合成され、全体的な音声帯域データ操作を駆動するためにトリガー：再生保護との整合性の保護は、これらの脅威に対抗するために使用しなければなりません。
Ideally, there would be a single mandatory-to-implement media stream security mechanism to provide this integrity protection, and in theory there is, since MGCP [RFC3435] defines a media stream security mechanism. However, the standard MGCP media stream security mechanism defined in [RFC3435] relies on the encryption key ("k=") field defined in the original SDP specification [RFC2327], the use of which is no longer recommended in the current SDP specification [RFC4566]. In practice, this mechanism has also seen very limited implementation, and hence there is not much value in relying on it. Still, the integrity protection requirement remains, and there are several different ways this can be achieved:
理想的には、この完全性保護を提供するために、単一実装に必須のメディアストリームのセキュリティ・メカニズムがあるだろう、とMGCP [RFC3435]は、メディアストリームのセキュリティ・メカニズムを定義しているので、理論的には、そこにあります。しかしながら、[RFC3435]で定義された標準MGCPメディアストリームのセキュリティメカニズムは、元のSDP仕様[RFC2327]で定義された暗号鍵（「K =」）フィールドに依存して、の使用は、もはや[現在のSDP仕様で推奨されていませんRFC4566]。実際には、このメカニズムはまた、非常に限られた実装を見ている、ひいてはそれに頼るに多くの価値がありません。それでも、完全性保護の要件が残り、これを達成することができ、いくつかの異なる方法があります。
Secure RTP: For RTP-based media streams, the use of Secure RTP [RFC3711] with an associated key management mechanism is generally preferred at the time of this writing; however, such a mechanism has currently not been defined for MGCP.
RTPを確保：RTPベースのメディアストリームについて、関連する鍵管理メカニズムを有するセキュアRTP [RFC3711]を使用することは、一般的にこれを書いている時点で好ましいです。しかし、このようなメカニズムは、現在、MGCPのために定義されていません。
PacketCable Security: The PacketCable Network-Based Call Signaling Protocol [NCS] defines another media stream security mechanism that is generally supported by PacketCable-compliant implementations. Implementations targeted for those environments SHOULD implement this security mechanism.
PacketCableのセキュリティ：PacketCableのネットワークベースのコールシグナリングプロトコルは、[NCS]一般的なPacketCable準拠の実装によってサポートされている別のメディアストリームのセキュリティ・メカニズムを定義します。これらの環境を対象と実装は、このセキュリティ・メカニズムを実装する必要があります。
Lower-Level Security: In the absence of a common media stream security mechanism supported by both endpoints, a lower-level security mechanism, e.g., IPsec, MUST be used. Note that since there is no inherent MGCP signaling support for such a lower-level security mechanism, it MUST be configured by other means.
低レベルのセキュリティ：両方のエンドポイントでサポートされている共通のメディアストリームのセキュリティメカニズム、低レベルのセキュリティメカニズムが存在しない場合には、例えば、IPsecは、使用しなければなりません。そのような低レベルのセキュリティメカニズムのサポートをシグナリングは固有MGCPがないので、それは他の手段によって構成しなければならないことに留意されたいです。
The IANA has registered the following MGCP packages:
IANAは、次のMGCPパッケージを登録しています：
Package Title Name Version
------------- ---- -------
Voiceband Data VBD 0
General-Purpose Media Descriptor Parameter GPMD 0
Several people have contributed to the development of the MGCP VBD and GPMD packages and the use of the MIME subtypes "RED" and "parityfec" with the FM package for VBD with redundancy and FEC. In particular, the authors would like to thank Flemming Andreasen, John Atkinson, Bill Foster, and the CableLabs PacketCable TGCP/NCS focus team for their contributions. Many thanks to Billy Hare for doing a thorough review of this document.
いくつかの人々は、MGCP VBDとGPMDパッケージの開発と冗長性とFECとのVBD用FMパッケージとMIMEサブタイプを使用する「RED」と「parityfec」に貢献してきました。特に、著者はフレミングAndreasenの、ジョン・アトキンソン、ビル・フォスター、そして彼らの貢献のためのCableLabsのPacketCableのTGCP / NCSフォーカスチームに感謝したいと思います。このドキュメントの徹底的な見直しを行うためのビリーうさぎに感謝します。
Joe Stone and Rajesh Kumar are the main authors of this document; security considerations and final editor role were provided by Flemming Andreasen. Sandeep Sharma was editor on earlier versions of the document.
ジョー・ストーンとラジェッシュクマーは、この文書の主な著者です。セキュリティ上の考慮事項と、最終的な編集者の役割は、フレミングAndreasenのによって提供されました。サンディープ・シャーマは、ドキュメントの以前のバージョンの編集者でした。
[H2482] International Telecommunication Union - Telecommunication Standardization Sector, "Gateway control protocol: Facsimile, text conversation and call discrimination packages", ITU-T Recommendation H.248.2, November 2000.
[H2482]国際電気通信連合 - 電気通信標準化部門、「ゲートウェイ制御プロトコル：ファックス、テキストの会話や差別のパッケージを呼び出す」、ITU-T勧告H.248.2、2000年11月。
[NCS] CableLabs(R), "PacketCable(TM) 1.5 Specifications: Network-Based Call Signaling Protocol, PKT-SP-NCS1.5-I03- 070412", April 2007.
[NCS] CableLabsの（R）、 "PacketCableの（TM）1.5仕様：ネットワークベースのコールシグナリングプロトコル、PKT-SP-NCS1.5-I03- 070412"、2007年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[RFC2198]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ・ガルシア、A.、およびS.フォッシー-Parisis、「RTPペイロード冗長オーディオ・データ」、RFC 2198、1997年9月のため。
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, October 2002.
[RFC3407]アンドレア、F.、 "セッション記述プロトコル（SDP）シンプルな能力宣言"、RFC 3407、2002年10月。
[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[RFC3435]アンドレア、F.およびB.フォスター、 "メディアゲートウェイコントロールプロトコル（MGCP）バージョン1.0"、RFC 3435、2003年1月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3660] Foster, B. and F. Andreasen, "Basic Media Gateway Control Protocol (MGCP) Packages", RFC 3660, December 2003.
[RFC3660]フォスター、B.およびF.アンドレア、 "基本的なメディアゲートウェイコントロールプロトコル（MGCP）パッケージ"、RFC 3660、2003年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[RFC4733] Schulzrinneと、H.、およびT.テイラー、 "DTMFケタ、電話トーン、およびテレフォニーシグナルのためのRTPペイロード"、RFC 4733、2006年12月。
[RFC4734] Schulzrinne, H. and T. Taylor, "Definition of Events for Modem, Fax, and Text Telephony Signals", RFC 4734, December 2006.
[RFC4734] Schulzrinneと、H.、およびT.テイラー、 "モデム、ファックス、およびテキストテレフォニーシグナルのためのイベントの定義"、RFC 4734、2006年12月。
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.
[RFC5109]李、A.編、RFC 5109、2007年12月、 "一般的なフォワードエラー訂正のためのRTPペイロードフォーマット"。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、STD 68、RFC 5234、2008年1月。
[RFC5347] Andreasen, F. and D. Hancock, "Media Gateway Control Protocol Fax Package", RFC 5347, October 2008.
[RFC5347]アンドレア、F.とD.ハンコック、 "メディアゲートウェイ制御プロトコルファックスパッケージ"、RFC 5347、2008年10月。
[V1501] International Telecommunication Union - Telecommunication Standardization Sector, "Modem-over-IP networks: Procedures for the end-to-end connection of V-series DCEs", ITU-T Recommendation V.150.1, January 2003.
[V1501]国際電気通信連合 - 電気通信標準化部門、「モデムオーバーIPネットワーク：VシリーズのDCEのエンドツーエンド接続のための手順」、ITU-T勧告V.150.1、2003年1月。
[V1501A1] International Telecommunication Union - Telecommunication Standardization Sector, "Modem-over-IP networks: Procedures for the end-to-end connection of V-series DCEs, Amendment 1: Modification to SSE reason identifier codes to support voice band data and text relay", ITU-T Recommendation V.150.1 Amendment 1, January 2005.
[V1501A1]国際電気通信連合 - 電気通信標準化部門、「モデムオーバーIPネットワーク：VシリーズのDCEのエンドツーエンド接続の手順、修正1：音声帯域データとテキストをサポートするために、SSEの理由識別子コードへの変更リレー」、ITU-T勧告V.150.1の改正1、2005年1月。
[V152] International Telecommunication Union - Telecommunication Standardization Sector, "Procedures for supporting Voice-Band Data over IP Networks", ITU-T Recommendation V.152, January 2005.
[V152]国際電気通信連合 - 電気通信標準化部門、「IPネットワーク上で音声帯域データをサポートするための手順」、ITU-T勧告V.152、2005年1月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327]ハンドリー、M.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, February 2009.
[RFC5406] Bellovin氏、S.、 "IPsecのバージョン2の使用を指定するためのガイドライン"、BCP 146、RFC 5406、2009年2月。
[T38] International Telecommunication Union - Telecommunication Standardization Sector, "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, April 2004.
[T38]国際電気通信連合 - 電気通信標準化部門、ITU-T勧告T.38、2004年4月「IPネットワーク上のリアルタイムグループ3ファクシミリ通信のための手順」。
Authors' Addresses
著者のアドレス
Joe Stone Cisco Systems 2200 East President George Bush Highway Richardson, TX 75082 USA
ジョー・ストーンシスコシステムズ2200東ブッシュ大統領ハイウェイ・リチャードソン、TX 75082 USA
EMail: joestone@cisco.com URI: http://www.cisco.com/
電子メール：joestone@cisco.com URI：http://www.cisco.com/
Rajesh Kumar Cisco Systems Mail Stop SJCE/1/1 190 West Tasman Drive San Jose, CA 95134 USA
ラジェッシュクマーシスコシステムズメールストップSJCE / 1月1日190西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: rkumar@cisco.com URI: http://www.cisco.com/
電子メール：rkumar@cisco.com URI：http://www.cisco.com/
Flemming Andreasen Cisco Systems Iselin, NJ 08830 USA
フレミングAndreasenのシスコシステムズ、アイセリン、NJ 08830 USA
EMail: fandreas@cisco.com URI: http://www.cisco.com/
電子メール：fandreas@cisco.com URI：http://www.cisco.com/