[要約] RFC 6498は、MGCPのVoiceband Data（VBD）パッケージと一般的なメディア記述子パラメータパッケージに関するものです。このRFCの目的は、MGCPを使用して音声データを制御するためのパッケージとパラメータを定義することです。
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を使用したMedia Format ParameterパッケージとFAXパッケージの使用について説明します。
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
このドキュメントは、メディアストリームの整合性保護を必要とするメカニズムを定義します。このドキュメントは、さまざまな代替メカニズムを指定しますが、それらのいずれかを必須から実装するものとして選択しません。したがって、この仕様の使用は、これらの代替メカニズムの少なくとも1つを指定および使用する環境でのみ適しています。詳細については、セキュリティに関する考慮事項セクションをご覧ください。
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].
VoiceBandデータ（または単にVBD）という用語は、RFC 3550 [RFC3550]で定義されているRTPを使用して、データペイロードの輸送に適切なVoiceBand Codec（一般的にG.711UまたはG.711A）の使用を指します。このドキュメントでは、コールエージェントが冗長性[RFC2198]およびFEC（フォワードエラー補正）[RFC5109] [RFC5109]の有無にかかわらずVBDの接続の遷移を承認および監視できるようにする、メディアゲートウェイ制御プロトコル（MGCP）[RFC3435]パッケージを定義します。
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]
o ITU-T推奨V.150.1状態シグナル伝達イベント（SSE）[V1501]
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から一般的な電話ネットワーク（GSTN）への方向にFAX、モデム、およびテキストトーンを検出すると、VBDへの切り替えまたはゲートウェイ制御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刺激と調整技術の両方として機能する場合があります。FAXおよびモデムイベントとトーンを伝えるためにRFC 4733およびRFC 4734を使用するために使用されるが、Gateway 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.
VoiceBandデータ（VBD）パッケージは、すべてのVBD手順をサポートするために定義されています。このドキュメントは、異なる手順の相対的なメリットに対処せず、ある手順を別の手順よりも提唱していません。
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という用語を使用して、一般的なVoiceBandデータを参照します。パッケージのコンテキストで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
メディア形式パラメーター（FM）パッケージ[RFC3660]は、冗長性の交渉を許可するために、「FMTP」localConnectionOptionと併せて標準のオーディオMIMEサブタイプ「RED」の使用を説明します[RFC2198]、冗長性と冗長性のレベルを特定します。
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 FAX（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パッケージの定義は、セクション5で提供されています。セクション6では、VBDと冗長性を備えたFMパッケージの使用について説明します。セクション7では、VBDおよびFECでFMパッケージの使用について説明します。セクション8では、VBDでFXRパッケージを使用しています。セクション9では、VBDおよびGPMDパッケージの使用方法を示す2つのコールフロー例を提供します。セキュリティ上の考慮事項はセクション10にあり、その後にIANAの考慮事項（セクション11）と参照があります。
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.
このパッケージは、VoiceBandデータ（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 [RFC3435]のセクション6.6で定義されている標準の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.
GWVBD手順は、ゲートウェイで使用して、コールエージェントの関与なしにVBDコールを処理する方法を制御および決定できます。「ゲートウェイ制御されたボイスバンドデータ」（または単に「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.
このセクションでは、「構文仕様の拡張BNF：ABNF」[RFC5234]で定義されているABNFを使用して、プロトコル構文の正式な説明を提供します。構文は、[RFC5234]の付録B.1で定義されているコアルールを使用していますが、ここには含まれていません。さらに、構文は[RFC5234]の症例感度ルールに従います。つまり、MGCPはケース非感受性です（ただし、SDPはそうではありません）。ABNFは線形空白の暗黙的な仕様を提供しないことに注意する必要があり、したがって、MGCPメッセージは以下の文法に記載されている明示的な線形空白ルールに従う必要があります。ただし、一般的な堅牢性の原則に沿って、実装者は、受信したメッセージの追加の線形空白を許容することを強く奨励されています。
The RequestedEvent parameter is encoded as
RequestEdEventパラメーターはASとしてエンコードされます
GwVbdReqEvent = "gwvbd"
The ObservedEvent parameter is encoded as
観測された平均パラメーターは、としてエンコードされます
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] ")"
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"
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」、「Codec」、「Coord」、および「dir」パラメーターは、存在する場合は、示されている相対順序で表示する必要があります。
The "start", "update", "stop", and "failure" ObservedEvent parameters are defined as follows:
「start」、「update」、「stop」、および "fails"の観察された平均パラメーターは、次のように定義されます。
1) VBD Start (start)
1) vbd start（start）
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（STOP）」または「GWVBD（障害）」イベントが生成されるまで、ゲートウェイへのメディア処理手順を発行することを控える必要があります。唯一の「GWVBD（STOP）」または「GWVBD（故障）」イベントが各「GWVBD（Start）」イベントに対応するイベントが生成されます。
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（update）」イベントは、「gwvbd（start）」イベントの後にのみ生成する必要があります。
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手順が終了し、手順自体がエラーに遭遇しなかったことを示すだけです。「STOP」パラメーターは、VBDから非VBD「オーディオ」コーデックへの変更に対応する場合、またはVBDから「画像」や「テキスト」などの別のメディアタイプに対応できます。この変更は、コールエージェントまたはゲートウェイ制御の下にある場合があります。たとえば、ゲートウェイは、SSE [T38] [V152]の交換を通じて、VBDから「画像/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」イベントが報告される場合、「start」、「update」、「stop」、または "故障」パラメーターの1つが正確に存在する必要があり、最初のパラメーターである必要があります。
The "rc", "codec", "coord", and "dir" ObservedEvent parameters are defined as follows:
「RC」、「Codec」、「Coord」、および「DIR」の観察されたパラメーターは、次のように定義されます。
1) Reason Code (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:
「開始」と「更新」パラメーターを使用すると、Switch/ChangeをVBDにトリガーする理由があります。「停止」と「障害」パラメーターを使用すると、VBDからのスイッチをトリガーする理由。次の表の理由は、ITU-T Fax/TextPhone/Modem Tones検出パッケージ[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.
BaudotやEDTなどの同じ「チャネル」で散在するテキストとスピーチを使用した変調を使用したテキストフォンを含むソリューションの場合、コールエージェントはReasonCodeパラメーターを「VBD/GWVBD（Start）」イベントの一部として解釈する必要があります。ファックス、モデム、テキストの間。散在するテキストとスピーチの場合、コールエージェントは、多数の通知を避けるために「VBD/GWVBD（START）」イベントを受信する際に、「VBD/GWVBD」の通知要求を削除する必要があります。
For example,
例えば、
vbd/gwvbd(start, rc=Baudot)
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」の理由コードを使用すると、コールエージェントはテキストをFAX/Modemと区別することはできません。この場合、コールエージェントは、多数の通知に対して警告するポリシーを採用する必要があります。このようなポリシーをいくつか検討します。
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（Start、RC = PTSW）」イベントを受信すると、「VBD/GWVBD」の通知要求を削除できます。このポリシーでは、「更新」、「停止」、および「失敗」通知は、テキストとFAX/モデムで生成されません。
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,
コールエージェントは、テキストをFax/Modemと区別する後続の「VBD/GWVBD（更新）」イベントを待つ場合があります。理由コードが散在するテキストとスピーチを示している場合、コールエージェントは「VBD/GWVBD」の通知要求を削除する必要があります。例えば、
vbd/gwvbd(update, 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.
コールエージェントは、テキストとFAX/モデムを区別せずに「VBD/GWVBD（STOP）」イベントを受信したときに、「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.
コールエージェントは、テキストとFAX/モデムを区別せずに多くの「VBD/GWVBD（Start）」イベントを受け取った後、「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
「MC」理由コードは、メディアタイプが「オーディオ」（「イメージ」、「テキスト」、...）または「オーディオ」メディア形式がVBDコーデックから変更されたことを示しています（以外の理由で変更されました。「PTSW」）。たとえば、GWVBD手順は、ターミナル識別（CED）と呼ばれる検出時に開始される場合があります。その後、コールエージェントがMGCP FAX（FXR）パッケージのT.38手順を制御し、V.21フラグを検出すると開始される場合があります。「T38（Start）」イベントを受け取ると、コールエージェントは
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.
「L：A：Image/T38」のローカルコネクションオプションエンコードメソッドを含むModieConnectionOptionコマンドを使用して、VBDからT.38に切り替えるゲートウェイおよび「画像/T38」メディアの説明を持つRemoteConnectionDescriptor。これにより、GWVBD手順が停止します。VBDパッケージとFXRパッケージ（またはその他のパッケージ）の間に特定の相互依存関係はありません。GWVBD手順は、T.38手順が開始されることの直接的な結果としてではなく、メディアの変更の結果として停止されます。この状況では、「T38（Start）」イベントが「GWVBD（STOP）」イベントの前に送信されることに注意してください。コールエージェントは、GWVBD手順が「T38（Start）」イベントを受信したときに終了し、「GWVBD」イベントの通知を無効にしたことを推測することを選択できます。セクション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.
理由コードのリストは、ゲートウェイとコールエージェントの間に相互に理解される意味のある値を含むように拡張される場合があります。明らかに、拡張値の使用は、コールエージェントとの相互運用性を確保するために、ゲートウェイで提供可能なオプションでなければなりません。
2) Codec String (codec=<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へのスイッチ/変更に関連付けられたMIMEタイプ（「オーディオ/レッド」、「オーディオ/PCMU」、「Audio/PCMA」、「Audio/」に関連付けられています。G726-32 "、" audio/clearMode "、...）。「停止」と「障害」パラメーターを使用すると、コーデックパラメーターは、VBDからのスイッチ（「オーディオ/G729」、「画像/T38」、「テキスト/T140」、「Audio/V150MR」に関連付けられたMIMEタイプを記述します。、...）。これらの文字列は、http：//www.iana.org/assignments/media-typesにリストされている完全なmimeタイプでなければなりません。
3) Coordination Technique (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」調整技術により、VBDとの遷移を調整するために、状態シグナル伝達イベント[V1501]を使用します。
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.
調整技術のリストは、ゲートウェイとコールエージェントの間に相互に理解される意味のある値を含むように拡張される場合があります。明らかに、拡張値の使用は、コールエージェントとの相互運用性を確保するために、ゲートウェイで提供可能なオプションでなければなりません。
4) Direction of Stimulus (dir=<Direction>)
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.
コールエージェントとゲートウェイは、「START」と「STOP」パラメーターを実装し、「更新」と「障害」パラメーターを実装する必要があります。コールエージェントとゲートウェイは、「Coord」、「Codec」、および「dir」パラメーターを実装できます。コールエージェントは、「start」および「uptred」パラメーターと併せて「RC」パラメーターを実装する必要があります。コールエージェントとゲートウェイは、「停止」および「障害」パラメーターと組み合わせて「RC」パラメーターを実装できます。コールエージェントは、この仕様の一部として定義され、実装されていないパラメーターを含む、すべての未知の観察された平均パラメーターを無視する必要があります。
The following examples illustrate the encoding of the "gwvbd(start)" event:
次の例は、「gwvbd（start）」イベントのエンコードを示しています。
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)
The following examples illustrate the encoding of the "gwvbd(stop)" event:
次の例は、「GWVBD（STOP）」イベントのエンコードを示しています。
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.
「VoiceBandデータの交渉されていない手順」（または単に「NOPVBD」）イベントは、VBD手順が交渉されておらず、VBD刺激が検出されたときに発生します。「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手順には、ゲインとジッターの調整、音声アクティビティ検出の無効化、およびDCオフセットフィルターを含むがこれらに限定されないVBD処理が含まれる場合があります。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パラメーターはASとしてエンコードされます
NopVbdReqEvent = "nopvbd"
The ObservedEvent parameter is encoded as
観測された平均パラメーターは、としてエンコードされます
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] ")"
The following ABNF notation is common with the "gwvbd" ObservedEvent parameter:
次のABNF表記は、「GWVBD」の観察された平均パラメーターで一般的です。
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"
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:
「start」、「update」、「stop」、および "fails"の観察された平均パラメーターは、次のように定義されます。
1) VBD Start(start)
1) vbd start（start）
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（stop）」または「nopvbd（故障）」イベントは、各「nopvbd（start）」イベントに対応して生成される場合があります。コールエージェントは、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（update）」イベントは、「nopvbd（start）」イベントの後にのみ生成する必要があります。
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.
コールエージェントとゲートウェイは、「start」パラメーターを実装し、「更新」、「停止」、および「故障」パラメーターを実装する必要があります。コールエージェントは、「start」および「uptred」パラメーターと併せて「RC」パラメーターを実装する必要があります。コールエージェントとゲートウェイは、「停止」および「障害」パラメーターと組み合わせて「RC」パラメーターを実装できます。コールエージェントは、この仕様の一部として定義され、実装されていないパラメーターを含む、すべての未知の観察された平均パラメーターを無視する必要があります。
The definitions of the "rc", "codec", and "dir" ObservedEvent parameters are taken from the "gwvbd" event.
「RC」、「コーデック」、および「DIR」の観察された平均パラメーターの定義は、「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（start）」イベントのエンコードを示しています。
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（update）」イベントのエンコードを示しています。
O: vbd/nopvbd(update, rc=/ANSam, dir=IpToGstn)
The following examples illustrate the encoding of the "nopvbd(stop)" event:
次の例は、「nopvbd（stop）」イベントのエンコードを示しています。
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.
汎用メディア記述子パラメーターローカルコネクションオプションは、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:
汎用メディア記述子パラメーターは、キーワード「GPMD」または「O-GPMD」としてエンコードされ、その後、メディア形式名（MIMEサブタイプのみ）から始まるコロンと引用文字そのメディア形式に関連付けられたフォーマットパラメーター：
gpmd/gpmd:"<format> <parameter list>"
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」キーワードがコロンが続く1つの「gpmd」キーワードと、各汎用メディア記述子パラメーターの引用文のセミコロン分離リストを持つことによって、
L: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX";
"codec2 parameterY"
The two formats may be mixed:
2つの形式は混合される場合があります。
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"
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」パラメーターがコーデックの最初と2回目の発生に適用されるかどうかは明らかではありません。問題は、コーデックの順序が重要であること（つまり、コーデックが優先順序でリストされている）であり、上記の構文は「パラメータx」が優先されるかどうかを示す方法を提供しない（つまり、最初の「コーデック」に関連付けられているかどうか）（つまり、つまり、2番目の「Codec1」に関連付けられています）。このジレンマを解決するために、「GPMD」メディア形式のコーデックの後にコロンと<オーダー>が続きます。ここで、<dorderはコーデックリストの同じコーデックの発生に対して1からnの数値です。例えば、
L:a: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.
「parameterx」は、「a：codec1; codec1」リストの「codec1」の2番目のインスタンスに関連付けられていることを示します。無効なインスタンス番号が提供されている場合（たとえば、2つのインスタンスしかないインスタンス3）、エラーコード524-ローカル接続オプションの矛盾 - が返されます。<dorder>がない場合、最初のインスタンスが想定されます。
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"
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:
1つの例では、ペイロードタイプスイッチング[V152]を使用して、Gateway制御されたVoiceBandデータ（または単にVBD）と組み合わせて、汎用メディア記述子パラメーターLocalConnectionOptionを使用します。VBDのコンテキストでは、<フォーマット>はRTP/AVPペイロードタイプでなければなりません。<パラメーターリスト>は、「パラメーター=値」ペアのセミコロン分離リストです。
L: a:codec1, gpmd/gpmd:"codec1 parameterX=ValueA;parameterY=ValueB"
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"
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
エンドポイントの機能を監査するための要求が行われ、エンドポイントがG.711UをオーディオとVBDコーデックの両方としてサポートする場合、「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"
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.
MGCPメディア形式パラメーター（FM）パッケージ[RFC3660]標準のオーディオMIMEサブタイプ「RED」と併せて、コールエージェントが冗長性の交渉を許可して、冗長性とメディア形式のレベルを特定するために使用できます。各冗長レベルに関連付けられています。この例は、セクション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"
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
「formatx」は、「a：codec1; codec1」リストの「codec1」の2番目のインスタンスに関連付けられていることを示します。FMパッケージの例は、メディア形式と組み合わせてインスタンス構文の使用に限定されています。メディア形式のパラメーターと組み合わせて、インスタンス構文の使用を提案します
L:a: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はオーディオコーデックと冗長レベルの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は冗長レベルが2のオーディオコーデックで、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サブタイプ「パリティフェック」を使用して、フォワードエラー補正（FEC）[RFC5109]の交渉を許可することができます。
L: a: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が冗長コーデックペイロードフォーマット[RFC2198]のセカンダリコーデックとして送信される場合、標準のオーディオMIMEサブタイプ「RED」と組み合わせて、MGCPメディア形式パラメーター（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
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 FAX（FXR）パッケージ[RFC5347]は、コールエージェントによって使用され、コールエージェント制御T.38やV.152などのゲートウェイ手順を含むファックス処理を承認します。FXRパッケージを使用すると、VBDは2つのカテゴリのいずれかに分類されます。ゲートウェイプロシージャの一部として（「GWFAX」イベントになる）またはゲートウェイおよびオフ手順の一部として「特別なFAX処理なし」（特別なFAX処理」（「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
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
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」のサポートを示していません。したがって、ゲートウェイは、ファックス刺激（つまり、CNG、v.21フラグなど）を検出すると、T.38の厳密なファックス手順「T38」を開始しません。ただし、2つのエンドポイントは、ゲートウェイ制御されたVBDプロシージャ（v.152など）のネゴシエートを正常に交渉しました。したがって、「特別なファックス処理」を含むゲートウェイ制御モードが使用されます。「GWFAX（START）」イベントは、VBD（FAXを含む）刺激を検出すると生成されます。
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
and
と
L: fxr/fx:gw;t38-loose
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手順に比べて異なる好みを持つ可能性があります。
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パッケージを使用すると、ゲートウェイが追加のファックス処理パラメーターを実装できます。既存の「GW」パラメーターを1つ以上のMIMEタイプのリストで適格にすることにより、まさにそのようなパラメーターを定義します。
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」パラメーターを修飾することにより、ゲートウェイ手順の範囲を狭めます。コールエージェントがゲートウェイ制御されたFAX処理手順の使用を許可する次の例を考えてみましょう。
- involving "image/t38" (e.g., T.38oUDPTL, T.38oTCP):
- 「Image/T38」を含む（例：T.38oudptl、T.38OTCP）：
L: a:G729, fxr/fx:gw[image/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]
- involving VBD with redundancy (e.g., PCMU, V.152, and RFC 2198):
- 冗長性を伴うVBDを含む（例：PCMU、v.152、およびRFC 2198）：
L: a:G729;RED;PCMU, fmtp:"RED PCMU/PCMU",
gpmd/gpmd:"PCMU vbd=yes", fxr/fx:gw[audio/RED|audio/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タイプの1つを含む「特別なファックス処理」のみが承認されています。指定されたMIMEタイプのいずれかを含む「特別なFAX処理」のサポートを交渉する必要があります。または、ゲートウェイ手順のこの「インスタンス」は開始されません。コールエージェントがゲートウェイ制御されたファックス処理手順の使用を許可する次の例を考えてみましょう。
- involving "audio/t38" (e.g., T.38oRTP):
- 「Audio/T38」（例：T.38ORTP）を含む：
L: a:G729;t38, fxr/fx:gw[audio/t38]
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"
「FX」LocalConnectionOptionには、「GW」パラメーターの複数のインスタンスが含まれ、それぞれがMIMEタイプの異なるリストを持つインスタンスが含まれる場合があります。「特別なファックス処理なし」を承認するには、コールエージェントには、MIMEタイプのない「GW」パラメーターまたは「オフ」を含める必要があります。
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,
パラメーター。MIMEタイプのない「GW」パラメーターのインスタンスは、「GW」パラメーターの最後のインスタンスとして表示されます。次の例では、
L: a:G729;PCMU, fxr/fx:gw[image/t38];gw
the Call Agent authorizes the use of, and expresses a preference for,
コールエージェントは、の使用を承認し、優先順位を表明します。
1. Gateway controlled image/t38 (e.g., T.38oUDPTL)
1. ゲートウェイ制御画像/T38（例：T.38oudptl）
2. Any other gateway procedure with "special fax handling"
2. 「特別なファックス処理」を備えたその他のゲートウェイ手順
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. 特別なファックス処理はありません（これは、MGCP FAX（FXR）パッケージのセクション2.1で定義されている「FXR/FX：GW」パラメーターの関数です[RFC5347]）
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
the Call Agent authorizes the use of, and expresses a preference for,
コールエージェントは、の使用を承認し、優先順位を表明します。
1. Gateway controlled audio/t38 (e.g., T.38oRTP)
1. ゲートウェイ制御オーディオ/T38（例：T.38ORTP）
2. No special fax handling
2. 特別なファックス処理はありません
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手順に関して、さまざまなゲートウェイ制御ファックス処理手順に対する相対的な好みを表現できます。ファックス処理手順の次の優先リストを考慮してください。
1. Gateway controlled audio/t38 (e.g., T.38oRTP)
1. ゲートウェイ制御オーディオ/T38（例：T.38ORTP）
2. Gateway controlled image/t38 (e.g., T.38oUDPTL)
2. ゲートウェイ制御画像/T38（例：T.38oudptl）
3. Call Agent controlled image/t38
3. コールエージェント制御画像/T38
4. Gateway controlled VBD with redundancy (e.g., PCMU, V.152, and RFC 2198)
4. Gateway Controlled VBDは冗長性を備えています（例：PCMU、v.152、RFC 2198）
5. Gateway controlled VBD without redundancy (e.g., PCMU and V.152)
5. 冗長性なしのゲートウェイ制御VBD（例：PCMUおよびV.152）
6. Any other gateway procedure with "special fax handling"
6. 「特別なファックス処理」を備えたその他のゲートウェイ手順
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. 特別なファックス処理はありません（これは、MGCP FAX（FXR）パッケージのセクション2.1で定義されている「FXR/FX：GW」パラメーターの関数です[RFC5347]）
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
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
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文法と一致するブラケットのMIMEタイプ情報を無視する必要があります[RFC3435]。
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を使用したゲートウェイ制御下でのモデムコールを示しています。2つ目は、V.152とコールエージェント制御T.38を使用したゲートウェイ制御下でのFAXコールを示しています。
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を使用してGateway Controlled 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:
コールエージェントは、GaTewayにCreateConnectionコマンドを発行し、G.729メディアエンコードを使用し、「GWVBD」および「NOPVBD」イベントを通知するように指示します。コールエージェントは、G.711Uの冗長レベルを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
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
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
Step 3:
ステップ3：
The originating Call Agent sends a SIP INVITE message with the SDP to the terminating Call Agent.
発信元のコールエージェントは、SDPを含むSIP招待メッセージを終了コールエージェントに送信します。
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:
終了するコールエージェントは、終了ゲートウェイへのCreateConnectionコマンドを発行し、G.729メディアエンコードを使用し、「GWVBD」および「NOPVBD」イベントを通知するように指示します。繰り返しますが、コールエージェントは、G.711Uの冗長性レベルの1つのレベルを持つVBDコーデックとしての交渉を許可します。
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
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
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
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 200 OK応答を送り返し、SIP ACKを送信します（図示せず）。
Step 7:
ステップ7：
The originating Call Agent in turn sends a ModifyConnection command to the originating gateway:
発信元のコールエージェントは、順番にModieConnectionコマンドを発信ゲートウェイに送信します。
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
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ペイロードタイプでRTPパケットの送信を開始します（96）。
The "gwvbd(start)" event occurs, and a Notify command is sent to the Call Agent:
「gwvbd（start）」イベントが発生し、通話コマンドがコールエージェントに送信されます。
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:
コールエージェントは、notifyコマンドを確認します。
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パケットを受信すると、発信元のゲートウェイはRTPパケットの冗長なVBDペイロードタイプを送信し始めます。
The "gwvbd(start)" event occurs, and a Notify command is sent to the Call Agent:
「gwvbd（start）」イベントが発生し、通話コマンドがコールエージェントに送信されます。
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:
コールエージェントは、notifyコマンドを確認します。
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).
モデム呼び出しは終了します。終了ゲートウェイは、双方向の沈黙を検出し、ネゴシエートされたオーディオペイロードタイプでRTPパケットの送信を開始します（18）。
The "gwvbd(stop)" event occurs, and a Notify command is sent to the Call Agent:
「GWVBD（STOP）」イベントが発生し、通話コマンドがコールエージェントに送信されます。
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:
コールエージェントは、notifyコマンドを確認します。
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（STOP）」イベントが発生し、通話コマンドがコールエージェントに送信されます。
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:
コールエージェントは、notifyコマンドを確認します。
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:
コールエージェントは、GaTewayにCreateConnectionコマンドを発行し、G.729メディアエンコードを使用し、厳密なT.38手順またはゲートウェイ手順のいずれかを使用するように指示します。その結果、コールエージェントは、「T38」、「GWFAX」、「GWVBD」、および「NOPVBD」イベントの通知を要求します。コールエージェントは、G.711Uの冗長レベルを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
Step 2:
ステップ2：
The gateway acknowledges the command and includes SDP with codec information as well as capability, V.152, and redundancy information:
Gatewayはコマンドを認め、Codec情報と機能、v.152、および冗長情報を備えたSDPを含みます。
200 1000 OK I:1
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
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では、ファックス処理のためにv.152を超えるT.38の好みを表現するために、セッションレベルの「A = PMFT」SDP属性を使用する必要があることに注意してください。
Step 3:
ステップ3：
The originating Call Agent sends a SIP INVITE message with the SDP to the terminating Call Agent.
発信元のコールエージェントは、SDPを含むSIP招待メッセージを終了コールエージェントに送信します。
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
終了コールエージェントは、終了ゲートウェイへのCreateConnectionコマンドを発行し、G.729メディアエンコードを使用し、厳密なT.38手順またはゲートウェイ手順のいずれかを使用するように指示します。その結果、コールエージェントが要求します
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:
「T38」、「GWFAX」、「GWVBD」、および「NOPVBD」イベントの通知。繰り返しますが、コールエージェントは、G.711Uの冗長性レベルの1つのレベルを持つVBDコーデックとしての交渉を許可します。
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
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
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コールエージェント制御手順を使用できます。終了ゲートウェイはv.152と冗長性をサポートし、remoteconnectiondescriptorを含むことは、反対側がv.152と冗長性をサポートしていることを示しているため、v.152を使用したゲートウェイ制御VBDと冗長性をモデムおよびテキスト送信に使用できます。終了ゲートウェイは、SDPを使用して成功応答を送り返します。これには、機能、v.152、および冗長情報も含まれます。
200 2000 OK I:2
200 2000 OK I：2
v=0 o=- 25678 753849 IN IP4 192.0.2.2 s=- c=IN IP4 192.0.2.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
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 200 OK応答を送り返し、SIP ACKを送信します（図示せず）。
Step 7:
ステップ7：
The originating Call Agent in turn sends a ModifyConnection command to the originating gateway:
発信元のコールエージェントは、順番にModieConnectionコマンドを発信ゲートウェイに送信します。
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
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
ModieConnectionコマンドは、以前に送信されたLocalConnectionOptionsを繰り返しません。したがって、FAXの取り扱いに関する限り、ゲートウェイは現在のFAX処理手順、つまり厳密なコールエージェントが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）を検出します。FAXコールとモデム呼び出しの両方がこのシーケンスで開始できるため、V.21 Fax Preambleが検出されるステップ14までこれがFAXコールであると判断することはできません。終了ゲートウェイは、交渉された冗長VBDペイロードタイプ（96）でRTPパケットの送信を開始します。
The "gwvbd(start)" event occurs, and a Notify command is sent to the Call Agent:
「gwvbd（start）」イベントが発生し、通話コマンドがコールエージェントに送信されます。
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:
コールエージェントは、notifyコマンドを確認します。
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パケットを受信すると、発信元のゲートウェイはRTPパケットの冗長なVBDペイロードタイプを送信し始めます。
The "gwvbd(start)" event occurs, and a Notify command is sent to the Call Agent:
「gwvbd（start）」イベントが発生し、通話コマンドがコールエージェントに送信されます。
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:
コールエージェントは、notifyコマンドを確認します。
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:
終了ゲートウェイは、ファックスコールにコールエージェント制御T.38厳密な手順を使用しているため、「T38（start）」イベントが発生し、通話コマンドがコールエージェントに送信されます。
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:
コールエージェントは、notifyコマンドを確認します。
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:
終了ゲートウェイは、SDPで成功応答を送り返します。これには、「画像/T38」メディアの説明も含まれています。
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
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（STOP）」イベント通知は通常、この時点で送信されます。ただし、コールエージェントは「GWVBD」イベントの通知を要求しなくなりました。コールエージェントは、GWVBD手順が終了した「T38（Start）」イベントから推測されていたでしょう。
Step 19:
ステップ19：
The terminating Call Agent sends a re-INVITE to the originating Call Agent with the updated SDP.
終了コールエージェントは、更新されたSDPを使用して発信元のコールエージェントに再入力を送信します。
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
V = 0 O = -25678 753850 IN IP4 192.0.2.2 S = -C = 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
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
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（STOP）」イベント通知は通常、この時点で送信されます。ただし、コールエージェントは「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).
発信元のコールエージェントは、更新されたSDPを備えたSIP 200 OK応答を終了コールエージェントに送信し、これによりSIP ACKを送信します（図示せず）。
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
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 Fax（FXR）パッケージ[RFC5347]で定義されているように、コールエージェント制御T.38厳密な手順に対応しています。
This document defines two new packages, both of which have security considerations in two areas:
このドキュメントでは、2つの新しいパッケージを定義します。どちらも2つの領域にセキュリティ上の考慮事項があります。
1. MGCP signaling message security
1. MGCPシグナリングメッセージセキュリティ
2. Media stream security
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
MGCPシグナリングセキュリティの観点から、MGCP VBDおよびGPMDパッケージは、MGCP [RFC3435]で指定された手順に従って、基本的なMGCPシグナリング仕様に拡張機能を定義し、したがって、[セクション5で提供されるMGCPシグナルセキュリティの考慮事項と推奨事項に従って定義します。RFC3435]（つまり、IPSECの使用）もここにも適用されます。MGCPシグナル伝達の完全性保護の欠如は、一般にMGCPの使用に有害であり、ここで定義されている2つのパッケージはそれを変更しません。機密性の観点から、VBDパッケージは、脆弱またはプライバシーに敏感な情報を伝えるとは考えられていません。GPMDパッケージは、特定のパラメーターを定義しないため、わずかに異なります
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.
機密性が必要であると考えられています。ただし、Codecパラメーター情報を搭載できる一般的なパラメーターであるため、このパラメーターを介して機密情報が伝達される可能性があります。そのような潜在的な情報の機密性が懸念事項である場合、MGCPシグナリングの機密保護も提供する必要があります。[RFC5406]のセクション8は、[RFC3435]で提供されているものを超えているIPSECの使用を指定するための考慮事項を提供していることに注意する必要があります。ただし、MGCPのIPSECの使用は、MGCP VBDおよびGPMDパッケージだけでなく、すべてのMGCPに適用されることを考えると、このような詳細はここでは追加の詳細を指定しません。
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]で定義されているメディアストリームの一般的な使用に依存する拡張機能を再度定義します。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]で定義された暗号化キー（ "="）フィールドに依存しています。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.
SECURE 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 Networkベースのコールシグナル伝達プロトコル[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」の使用に貢献しています。特に、著者は、フレミング・アンドレアセン、ジョン・アトキンソン、ビル・フォスター、およびCableLabs PacketCable TGCP/NCS Focusチームの貢献に感謝したいと思います。この文書を徹底的にレビューしてくれたビリー・ヘアに感謝します。
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.
Joe StoneとRajesh Kumarは、この文書の主な著者です。セキュリティ上の考慮事項と最終編集者の役割は、フレミングアンドレアセンによって提供されました。Sandeep Sharmaは、ドキュメントの以前のバージョンの編集者でした。
[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-Parisis、RTPペイロード冗長なオーディオデータの場合」、RFC 2198、1997年9月。
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, October 2002.
[RFC3407] Andreasen、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] Andreasen、F。およびB. Foster、「Media Gateway Control Protocol（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.、Frederick、R。、およびV. Jacobson、「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] Foster、B。およびF. Andreasen、「Basic Media Gateway Control Protocol（MGCP）パッケージ」、RFC 3660、2003年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「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. Taylor、「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. Taylor、「モデム、FAX、およびテキスト電話信号のイベントの定義」、RFC 4734、2006年12月。
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.
[RFC5109] Li、A.、ed。、「一般的なフォワードエラー補正のRTPペイロード形式」、RFC 5109、2007年12月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5347] Andreasen, F. and D. Hancock, "Media Gateway Control Protocol Fax Package", RFC 5347, October 2008.
[RFC5347] Andreasen、F。およびD. Hancock、「Media Gateway Control Protocol Faxパッケージ」、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] International Telecommunication Union-Telecommunication Standardizationセクター、「モデムオーバー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シリーズDCESのエンドツーエンド接続の手順、修正1：SSE REASON IDへの変更」ボイスバンドデータとテキストをサポートするリレー」、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] International Telecommunication Union-Telecommunication Standardizationセクター、「IPネットワーク上の音声帯域データをサポートする手順」、ITU-T推奨V.152、2005年1月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327] Handley、M。and 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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、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.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（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] International Telecommunication Union-電気通信標準化セクター、「IPネットワークを介したリアルタイムグループ3ファクシミリ通信の手順」、ITU-T推奨T.38、2004年4月。
Authors' Addresses
著者のアドレス
Joe Stone Cisco Systems 2200 East President George Bush Highway Richardson, TX 75082 USA
ジョーストーンシスコシステム2200イースト大統領ジョージブッシュハイウェイリチャードソン、テキサス75082 USA
EMail: 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
Rajesh Kumar Cisco Systems Mail Stop SJCE/1/1 190 West Tasman Drive San Jose、CA 95134 USA
EMail: rkumar@cisco.com
URI: http://www.cisco.com/
Flemming Andreasen Cisco Systems Iselin, NJ 08830 USA
Flemming Andreasen Cisco Systems Iselin、NJ 08830 USA
EMail: fandreas@cisco.com
URI: http://www.cisco.com/