RFC5347 日本語訳
5347 Media Gateway Control Protocol Fax Package. F. Andreasen, D.Hancock. October 2008. (Format: TXT=86532 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group F. Andreasen
Request for Comments: 5347 Cisco Systems
Category: Informational D. Hancock
CableLabs
October 2008
Andreasenがコメントのために要求するワーキンググループF.をネットワークでつないでください: 5347年のシスコシステムズカテゴリ: 情報のD.ハンコックCableLabs2008年10月
Media Gateway Control Protocol Fax Package
メディアゲートウェイ制御プロトコルファックスパッケージ
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement.
このドキュメントは、ファックス呼び出しを支持するためにメディアゲートウェイControlプロトコル(MGCP)パッケージを定義します。 パッケージはファックスのために、2つの異なった方法で支持されるという要求を許します。 最初のものはCallエージェントのコントロールの下でITU-T Recommendation T.38をファックスリレーに利用します。 ゲートウェイが1つでハンドルと同様にファックス送信のための方法に決める秒に、ファックスの細部はCallエージェントかかわり合いなしで呼びます。
Andreasen & Hancock Informational [Page 1] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[1ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Fax Package Definition ..........................................3
2.1. LocalConnectionOptions .....................................3
2.1.1. T.38 Procedure (Strict or Loose) ....................6
2.1.2. Gateway Procedure ...................................8
2.1.3. Off Procedure .......................................8
2.1.4. Mode Operation ......................................8
2.1.5. Detecting a Fax Call ...............................10
2.1.6. Considerations for Determining Which
Procedures to Request ..............................11
2.2. Events and Signals ........................................13
2.2.1. Gateway Controlled Fax (gwfax) .....................13
2.2.2. No Special Fax Handling (nopfax) ...................14
2.2.3. T.38 Fax Relay (t38) ...............................14
2.3. Connection Parameters .....................................15
2.4. Negotiation of T.38 Parameters ............................16
2.5. Implementation Considerations .............................18
2.5.1. Media IP Address and Port for T.38 .................18
2.5.2. Case Sensitivity ...................................18
2.5.3. Boolean Indicator After T.38 Parameters ............19
3. Call Flow Examples .............................................19
3.1. Call Agent Controlled T.38 Strict .........................20
3.2. Multiple and Different Options ............................29
3.3. Interaction with SIP Endpoints ............................37
4. Security Considerations ........................................44
5. IANA Considerations ............................................44
6. Normative References ...........................................44
7. Informative References .........................................45
1. 序論…2 1.1. このドキュメントで中古のコンベンション…3 2. ファックスで、パッケージ定義を送ってください…3 2.1. LocalConnectionOptions…3 2.1.1. T.38手順(厳しいかゆるい)…6 2.1.2. ゲートウェイ手順…8 2.1.3. 手順で…8 2.1.4. モード操作…8 2.1.5. ファックスを検出して、電話をしてください…10 2.1.6. どの手順を要求したらよいかを決定するための問題…11 2.2. 出来事と信号…13 2.2.1. ゲートウェイはファックス(gwfax)を制御しました…13 2.2.2. 特別番組も、全く取り扱い(nopfax)はファックスで送りません…14 2.2.3. T.38はファックスでリレー(t38)を送ります…14 2.3. 接続パラメタ…15 2.4. T.38パラメタの交渉…16 2.5. 実現問題…18 2.5.1. T.38のためのメディアIPアドレスとポート…18 2.5.2. 感度をケースに入れてください…18 2.5.3. T.38パラメタの後のブールインディケータ…19 3. 例に流れに電話をしてください…19 3.1. エージェントの制御T.38が厳しいと言ってください…20 3.2. 複数の、そして、異なったオプション…29 3.3. 一口終点との相互作用…37 4. セキュリティ問題…44 5. IANA問題…44 6. 標準の参照…44 7. 有益な参照…45
1. Introduction
1. 序論
This document defines a Media Gateway Control Protocol (MGCP) [RFC3435] package that enables MGCP controlled gateways to support fax calls. The package enables fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 using either UDP Transport Layer (UDPTL) or TCP (see [T38]) for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement.
このドキュメントはサポートへの制御ゲートウェイがファックスで呼び出しを送るMGCPを有効にするメディアゲートウェイControlプロトコル(MGCP)[RFC3435]パッケージを定義します。 パッケージは2つの異なった方法で支持されるというファックス要求を可能にします。 最初のものは、ファックスリレーに、Callエージェントのコントロールの下にUDP Transport Layer(UDPTL)かTCP([T38]を見る)のどちらかを使用することでITU-T Recommendation T.38を利用します。 ゲートウェイが1つでハンドルと同様にファックス送信のための方法に決める秒に、ファックスの細部はCallエージェントかかわり合いなしで呼びます。
The fax package definition is provided in Section 2, and in Section 3 we provide three call flow examples showing how to use it. Security considerations are found in Section 4, followed by the IANA considerations and references.
ファックスパッケージ定義をセクション2に提供します、そして、セクション3に、私たちはどのようにそれを使用するかを示す3つの呼び出し流れの例を提供します。 セキュリティ問題はIANA問題と参照があとに続いたセクション4で見つけられます。
Andreasen & Hancock Informational [Page 2] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[2ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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 BCP 14, RFC-2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC-2119[RFC2119])で説明されるように本書では解釈されることであるべきです。
2. Fax Package Definition
2. ファックスパッケージ定義
A package is defined for fax. The package defines new LocalConnectionOptions, events, and connection parameters as detailed below:
パッケージはファックスのために定義されます。 パッケージは以下に詳述する新しいLocalConnectionOptions、出来事、および接続パラメタを定義します:
Package Name: FXR Package Version: 0
名前をパッケージしてください: FXRはバージョンをパッケージします: 0
2.1. LocalConnectionOptions
2.1. LocalConnectionOptions
A new Fax LocalConnectionOptions (LCO) parameter is defined for fax handling. The Call Agent supplies this fax LCO to indicate the desired fax handling procedure to the Media Gateway. The fax LCO contains a list of desired fax handling procedures ordered by preference, with the most desired procedure listed first. When the parameter is explicitly included in a command, the gateway MUST be able to use at least one of the listed procedures for the command to succeed. Currently, the list can indicate one or more of the following procedures (see Sections 2.1.1 to 2.1.4 for further details on these):
新しいファックスLocalConnectionOptions(LCO)パラメタはファックス取り扱いのために定義されます。 Callエージェントは、必要なファックス取り扱い手順をメディアゲートウェイに示すためにこのファックスLCOを供給します。 ファックスLCOは好みで注文された必要なファックス取り扱い手順のリストを含んでいます、最も必要な手順が最初に記載されている状態で。 パラメタがコマンドに明らかに含まれているとき、ゲートウェイは成功するコマンドに少なくとも記載された手順の1つを使用できなければなりません。 現在、リストは以下の手順の1つ以上を示すことができます(さらに詳しい明細についてはこれらでセクション2.1の.1〜2.1に.4を見てください):
* T.38 Strict:
Use T.38 [T38] with either UDPTL or TCP for fax relay and have the
Call Agent control it. Assuming the procedure can be used (see
Section 2.1.1), a switch to T.38 procedures will be initiated upon
fax detection, and a "t38(start)" event will be generated (see
Section 2.2). This mode requires an indication of T.38 support
from the remote side in order to be used, as described further in
Section 2.1.1.
* T.38厳しい: ファックスリレーに、UDPTLかTCPのどちらかとT.38[T38]を使用してください、そして、Callエージェントにそれを制御させてください。 手順を仮定するのを使用できます、そして、(セクション2.1.1を見てください)T.38手順へのスイッチはファックス検出のときに開始されるでしょう、そして、「t38(始める)」出来事は発生するでしょう(セクション2.2を見てください)。 このモードは使用されるために遠隔地側からT.38サポートのしるしを必要とします、セクション2.1.1で、より詳しく説明されるように。
* T.38 Loose:
Identical to T.38 Strict procedure, except that an indication of
T.38 support from the remote side is not required for the procedure
to be used.
* T.38はほどけます: T.38 Strict手順と同じです、それ以外に、遠隔地側からのT.38サポートのしるしは、手順が用いられるのに必要ではありません。
* Off:
Do not invoke any special procedure for fax, except for echo
cancellation adjustment and possibly switching to another codec.
* オフ: ファックスのためのエコーキャンセル調整とことによると別のコーデックに切り替わる以外のどんな特別な手順も呼び出さないでください。
Andreasen & Hancock Informational [Page 3] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[3ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
* Gateway:
Let the gateway control and decide how to handle fax calls without
Call Agent involvement. This includes the case where the gateway
does not do anything special for fax; hence, by definition this
procedure can always be supported. If the gateway invokes a
special procedure upon detection of fax, it will generate a
"gwfax(start)" event to inform the Call Agent of this (see Section
2.2). The Call Agent SHOULD then refrain from issuing potentially
conflicting commands to the gateway until the gateway ends its
special fax handling procedure.
* ゲートウェイ: ゲートウェイに制御して、Callエージェントかかわり合いなしでファックス呼び出しを扱う方法を決めさせてください。 これはゲートウェイがファックスに、特別なものは何もしないケースを含んでいます。 したがって、定義上、いつもこの手順を支持できます。 ゲートウェイがファックスの検出の特別な手順を呼び出すと、それは、これについてCallエージェントに知らせるために「gwfax(始める)」出来事を発生させるでしょう(セクション2.2を見てください)。 そして、CallエージェントSHOULDは、ゲートウェイが特別なファックス取り扱い手順を終わらせるまで潜在的に闘争しているコマンドをゲートウェイに発行するのを控えます。
A gateway that ends up not being able to invoke any special
procedure for fax will generate a "nopfax(start)" event (see
Section 2.2) upon detection of fax.
ファックスのためにどんな特別な手順も呼び出すことができない終わるゲートウェイはファックスの検出のときに「nopfax(始める)」出来事(セクション2.2を見る)を発生させるでしょう。
The set of possible values (i.e., procedures) for the fax LCO is extensible. The prefix "x-", which indicates an optional extension, and the prefix "x+", which indicates a mandatory extension, are reserved for vendor-specific use.
ファックスLCOに、可能な値(すなわち、手順)のセットは広げることができます。 接頭語「x」と接頭語「x+」(義務的な拡大を示す)は業者特定的用法のために予約されます。(接頭語は任意の拡大を示します)。
In CreateConnection commands, the fax LCO value defaults to "gateway". In ModifyConnection commands, the fax LCO value defaults to its current value on the connection. Thus, if LocalConnectionOptions are omitted or if the fax LCO is not included in a ModifyConnection command, the previous fax LCO value for the connection is retained without affecting the outcome of the command; consequently, the gateway may now not apply any special procedure to fax. If the Call Agent wants to ensure that a command succeeds only when a fax procedure is applied, the command needs to include the fax LCO explicitly.
CreateConnectionコマンドでは、ファックスLCO価値は「ゲートウェイ」をデフォルトとします。 ModifyConnectionコマンドでは、ファックスLCO価値は接続の現行価値をデフォルトとします。 したがって、LocalConnectionOptionsが省略されるか、またはファックスLCOがModifyConnectionコマンドに含まれていないなら、コマンドの結果に影響しないで、接続のための前のファックスLCO価値は保有されます。 その結果、ゲートウェイは現在、ファックスで送るどんな特別な手順も適用しないかもしれません。 Callエージェントが、ファックス手順が適用されているときだけ、コマンドが成功するのを保証したいなら、コマンドは、明らかにファックスLCOを含む必要があります。
As an example of this, assume that the CreateConnection command
successfully specified the use of "T.38 Strict", and a
ModifyConnection command is now received without the fax LCO but
with a RemoteConnectionDescriptor indicating no support for T.38.
In this case, the ModifyConnection command will succeed, but T.38
procedures will no longer be invoked upon fax detection (a
"nopfax" event will be generated). Had the Call Agent instead
included the fax LCO set to "T.38 Strict", the command would have
failed.
この例として、CreateConnectionコマンドが首尾よく「T.38厳しいこと」の使用を指定して、ファックスLCOなしで、RemoteConnectionDescriptorがT.38のサポートを全く示していなくModifyConnectionコマンドが現在受け取られると仮定してください。 この場合、ModifyConnectionコマンドは成功するでしょうが、T.38手順はファックス検出のときにもう呼び出されないでしょう("nopfax"出来事は発生するでしょう)。 Callエージェントが代わりにLCOが「T.38厳しく」設定するファックスを入れたなら、コマンドは失敗したでしょうに。
If multiple fax parameter values are provided, the gateway MUST choose one of the procedures specified according to the order in which they are supplied, except as follows:
複数のファックスパラメタ値を提供するなら、ゲートウェイはそれらが供給される注文に従って指定された手順の1つを選ばなければなりません、以下の通りを除いて:
Andreasen & Hancock Informational [Page 4] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[4ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
1. If "gateway" would have been selected and it would have resulted
in no special procedure being applied, and
1. そしてどんな特別な手順ももたらしていて、適用されていることがないだろう。
2. if there are procedures other than "off" that are specified after
"gateway" (e.g., "t38"),
2. “off"以外の「ゲートウェイ」の後に指定される手順がある、(例えば、「t38")」
then the gateway MUST use the most preferred of those subsequent procedures that can be supported. If none of those subsequent procedures can be supported, the gateway reverts to not invoking any special procedure for fax. Please refer to Section 2.1.4 for further details on determining which procedures can be supported.
そして、ゲートウェイは支持できるそれらのその後の手順で最も都合のよいのを使用しなければなりません。 それらのその後の手順のどれかを支持できないなら、ゲートウェイはファックスのためにどんな特別な手順も呼び出さないのに戻ります。 さらに詳しい明細についてはどの手順を支持できるかを決定するとき、セクション2.1.4を参照してください。
The fax LCO parameter is encoded as the keyword "fx" (prefixed with the package name per [RFC3435]), followed by a colon and then a semicolon separated list of values, where T.38 Strict is encoded as "t38", T.38 Loose is encoded as "t38-loose", gateway is encoded as "gw", and off is encoded as "off".
ファックスLCOパラメタがコロンと次に、値のセミコロンの切り離されたリストがあとに続いたT.38 Strictがコード化される"fx"([RFC3435]あたりのパッケージ名で、前に置かれている)というキーワードとしてコード化される、「t38"、T.38 Looseが「ゆるいt38」としてコード化されて、「gw」と、下にあるときゲートウェイがコード化される、“off"としてコード化される、」
The following example illustrates the use of PCMU or G.729 for audio encoding, and T.38 Strict fax relay (preferred) or gateway control for fax:
以下の例はPCMUかG.729のオーディオコード化の使用を例証します、そして、T.38 Strictはファックスのためにファックスでリレー(好まれる)かゲートウェイコントロールを送ります:
L: a:PCMU;G729, fxr/fx:t38;gw
L: : PCMU; fxr/fx: G729、t38; gw
It should be noted that MGCP allows the CreateConnection command to omit both LocalConnectionOptions and RemoteConnectionDescriptor, thereby letting the gateway decide upon the media parameters to use. When the T.38 fax package is supported, the gateway could thus choose to do either audio or T.38 fax relay in such cases. Most likely, the Call Agent requires one or the other to be used, and hence it SHOULD NOT omit both LocalConnectionOptions and RemoteConnectionDescriptor in CreateConnection commands.
MGCPがLocalConnectionOptionsとRemoteConnectionDescriptorの両方を省略するCreateConnectionコマンドを許容することに注意されるべきです、その結果、ゲートウェイに使用するメディアパラメタについて決めさせます。 T.38ファックスパッケージが支えられるとき、その結果、ゲートウェイは、そのような場合オーディオかT.38ファックスリレーのどちらかをするのを選ぶかもしれません。 Callエージェントは、たぶん、使用されるべき1かもう片方を必要として、したがって、それを必要とします。SHOULD NOTはCreateConnectionコマンドでLocalConnectionOptionsとRemoteConnectionDescriptorの両方を省略します。
When auditing capabilities, the fax LCO may be returned with a semicolon-separated list of supported fax handling parameters. The values "t38", "t38-loose", "off", and "gw" MAY be omitted from such a list as they are always implied. Gateways that implement additional parameters SHOULD return these additional parameters when capabilities are audited, as illustrated by the following example:
能力を監査するとき、支持されたファックス取り扱いパラメタのセミコロンで切り離されたリストと共にファックスLCOを返すかもしれません。 「それらはそのようなaリストですが、いつも含意されて、t38"、「ゆるいt38」、“off"、および"gw"は省略されるかもしれない」値。 能力が監査されるとき、追加パラメタSHOULDを実行するゲートウェイが以下の例によって例証されるようにこれらの追加パラメタを返します:
A: a:image/t38, fxr/fx:mypar, ...
A: a: fxr/fx: イメージ/t38、mypar…
In the following subsections, we provide additional detail on the above-defined fax procedures.
以下の小区分に、私たちは上で定義されたファックス手順に関する追加詳細を明らかにします。
Andreasen & Hancock Informational [Page 5] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[5ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
2.1.1. T.38 Procedure (Strict or Loose)
2.1.1. T.38手順(厳しいかゆるい)です。
When a gateway is instructed to use one of the T.38 procedures (strict or loose), also known as Call Agent controlled T.38 mode, the "m=" line in the Session Description Protocol (SDP) returned will not indicate use of UDPTL-based or TCP-based T.38 (unless the gateway was also instructed to use "image/t38" for the media stream). Any other entity seeing this SDP will not know whether or not T.38 is supported and hence whether it is safe to attempt a switch to T.38 upon fax detection. To remedy this dilemma, capability information for T.38 (if supported) using the SDP Simple Capability Declaration extensions [RFC3407] MUST be included. Other capability information is included as well, regardless of whether the Call Agent authorized use of those in the connection handling command. A subsequent attempt to actually use these may of course not succeed, e.g., because the Call Agent LCO does not allow them to be used. The following example illustrates the RFC 3407 [RFC3407] capability descriptor--note the inclusion of both current (audio) and latent (T.38) capabilities, as specified in RFC 3407 [RFC3407]:
ゲートウェイが(厳しいかゆるい)でT.38手順の1つを使用するよう命令されて、また、Callとして知られているとき、エージェントがT.38モードを制御して、記述プロトコル(SDP)が返したSessionの「m=」線がUDPTLベースの、または、TCPベースのT.38の使用を示さない、(ゲートウェイがまた、命令された使用でなかった、「メディアの流れのためのイメージ/t38")」 このSDPを見る実体はいかなる他のもT.38が支持されるかどうかと、したがって、ファックス検出のときにT.38にスイッチを試みるのが安全であるかどうかを知らないでしょう。 このジレンマを改善するために、SDP Simple Capability Declaration拡張子[RFC3407]を使用するT.38(支持されるなら)のための能力情報を含まなければなりません。 また、他の能力情報は含まれています、Callエージェントが接続取り扱い命令におけるそれらの使用を認可したかどうかにかかわらず。 実際にこれらを使用するその後の試みはもちろん成功しないかもしれません、例えば、CallエージェントLCOが、それらが使用されるのを許容しないので。 以下の例はRFC3407[RFC3407]能力記述子を例証します--現在(オーディオの)のものと同様に潜在している(T.38)能力の包含に注意してください、RFC3407[RFC3407]で指定されるように:
m=audio 3456 RTP/AVP 18
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 18
a=cdsc: 2 image udptl t38
mはオーディオの3456RTP/AVP18a=sqnと等しいです: 0a=cdsc: 1 オーディオのRTP/AVP18a=cdsc: 2イメージudptl t38
For a list of T.38 related parameters to be included in the SDP, please refer to T.38 Annex D [T38].
T.38関係パラメータのリストがSDPに含まれるには、T.38 Annex D[T38]を参照してください。
Upon fax detection, a gateway that has successfully been instructed to use one of the T.38 procedures will:
ファックス検出に関して、T.38手順の1つを使用するよう首尾よく命令されたゲートウェイはそうするでしょう:
1. Initiate the T.38 fax relay procedure and mute the media channel
in both the send and receive direction (unless the media channel
is already using T.38).
1. T.38ファックスリレー手順に着手してくださいといって、両方でメディアチャンネルに音を消してください、指示を送って、受け取ってください(メディアチャンネルが既にT.38を使用していない場合)。
2. Generate a "t38(start)" event.
2. 「t38(始める)」出来事を発生させてください。
3. Await further instructions from the Call Agent in order to
initiate the actual media change (unless the media channel is
already using T.38).
3. 実際のメディア変化を起こす(メディアチャンネルが既にT.38を使用していない場合)ためにCallエージェントからその後の支持を待ってください。
The Call Agent instructs the gateway to perform the media change by sending it a ModifyConnection command with "image/t38" listed as the encoding method in the LocalConnectionOptions (receipt of a ModifyConnection command without LocalConnectionOptions but with a RemoteConnectionDescriptor containing an "m=" line with the MIME type "image/t38" would achieve the same). Per the normal MGCP codec negotiation procedures (see [RFC3435] Section 2.6), if a
Callエージェントが、ゲートウェイがModifyConnectionコマンドをそれに送るのによるメディア変化を実行するよう命令する、「イメージ/t38"がLocalConnectionOptionsのコード化方法を記載した、(LocalConnectionOptionsのはない、RemoteConnectionDescriptorがMIMEの種類がある「m=」線を含んでいるModifyConnectionコマンドの領収書、「t38"が同じように達成するイメージ/)、」 正常なMGCPコーデック交渉手順([RFC3435]セクション2.6を見る)aです。
Andreasen & Hancock Informational [Page 6] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[6ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
RemoteConnectionDescriptor was included as well, it needs to include an "m=" line with "image/t38" as an acceptable media format in order for the command to succeed. The gateway may choose between the UDPTL and TCP transport protocols at its own discretion subject to the normal MGCP codec negotiation procedures (in practice, TCP-based implementations are currently rare).
また、RemoteConnectionDescriptorは含まれて、それは、「成功するコマンドにおいて、整然としている許容メディア形式としてのイメージ/t38"」がある「m=」線を含む必要があります。 正常なMGCPコーデック交渉手順を条件としてゲートウェイは一存でUDPTLとTCPトランスポート・プロトコルを選ぶかもしれません(実際には、TCPベースの実現は現在、まれです)。
If a RemoteConnectionDescriptor was not included with the ModifyConnection command sent to a gateway that initiated the T.38 procedure, it is possible (in fact likely), that the last received RemoteConnectionDescriptor did not include an "m=" line listing "image/t38" as an acceptable media format. In that case, the endpoint cannot send T.38 media to the other side. The endpoint MUST instead wait for an updated RemoteConnectionDescriptor that contains "image/t38" as an acceptable media format and a supported transport protocol (UDPTL or TCP). The T.38 fax procedure continues when an acceptable RemoteConnectionDescriptor is received. An acceptable RemoteConnectionDescriptor contains an "m=" line with the "image/t38" MIME type (using the normal SDP syntax) and a supported transport protocol (UDPTL or TCP). If the fax call fails (e.g., due to a fax timeout) while waiting for either the Call Agent to instruct the gateway to switch to "image/t38" or for an acceptable RemoteConnectionDescriptor, a "t38(stop)" or a "t38(failure)" event MUST be generated. When the T.38 procedure ends, a "t38(stop)" or "t38(failure)" event MUST be generated.
それがRemoteConnectionDescriptorがModifyConnectionコマンドをゲートウェイに送って含まれていなかったならそれがT.38手順に着手したのが可能である(事実上、ありそうな)、最終がRemoteConnectionDescriptorを受けたのが「許容メディア形式としてのイメージ/t38"」を記載する「m=」線を含んでいませんでした。 その場合、終点は反対側へのメディアをT.38に送ることができません。 終点は代わりに「許容メディア形式と支持されたトランスポート・プロトコル(UDPTLかTCP)としてのイメージ/t38"」を含むアップデートされたRemoteConnectionDescriptorを待たなければなりません。 許容できるRemoteConnectionDescriptorが受け取られているとき、T.38ファックス手順は続きます。 許容できるRemoteConnectionDescriptorは「イメージ/t38"MIMEの種類(正常なSDP構文を使用する)と支持されたトランスポート・プロトコル(UDPTLかTCP)」がある「m=」線を含んでいます。 Callエージェントが、「イメージ/t38"か許容できるRemoteConnectionDescriptorに関して、「t38(止まる)」か「t38(失敗)」出来事は発生しなければならないこと」に切り替わるようゲートウェイに命令するのを待っている間、ファックス呼び出しが失敗するなら(例えば、ファックスタイムアウトのため)。 T.38手順が終わるとき、「t38(止まる)」か「t38(失敗)」出来事は発生しなければなりません。
Finally, the Call Agent may need to abort a T.38 procedure that is in progress. This can for example be done when the remote side is unable to switch to T.38, and a fallback to fax passthrough using an audio codec is attempted. The Call Agent instructs the endpoint to abort an in-progress T.38 procedure by use of the "off" fax LCO as illustrated below:
最終的に、Callエージェントは、進行しているT.38手順を中止する必要があるかもしれません。 遠隔地側がT.38に切り替わることができないとき、例えば、これができます、そして、オーディオコーデックを使用することでpassthroughにファックスする後退は試みます。 Callエージェントは、以下で例証されるように“off"ファックスLCOの使用で進行中のT.38手順を中止するよう終点に命令します:
L: fxr/fx:off
L: fxr/fx: 下に
We now define "time t38init" as the point in time where the T.38 procedure was initiated, and "time t38abort" as the point in time where the Call Agent aborts an in-progress T.38 procedure. If the Call Agent at time t38abort instructs or enables the endpoint to revert to one or more codecs that were in use just prior to time t38init, the endpoint SHOULD use media stream parameters that mimic the most recent LocalConnectionDescriptor issued before time t38init. For example, IP-address and UDP port, payload formats used and their payload type mapping, should all be the same as before time t38init. This will enable the fallback to be as rapid as possible. A LocalConnectionDescriptor is returned as usual, i.e., only if one or
私たちは、時間内にのポイントとしてのT.38手順が着手された「時間t38init」、および時間内にのポイントとしての「時間t38abort」のときに現在、Callエージェントがどこで進行中のT.38手順を中止するかを定義します。 時間t38abortのCallエージェントが、終点が戻るのを命令するか、または可能にするなら、1つ以上の時間t38init、終点SHOULD使用のすぐ前に使用中であったコーデックにメディアは時間t38initの前で発行された最新のLocalConnectionDescriptorをまねるパラメタを流します。 例えば、IP-アドレスとUDPポート(形式が使用したペイロードとそれらのペイロードタイプマッピング)は、時間t38initの前とすべて同じであるべきです。 これは、後退ができるだけ急速であることを可能にするでしょう。 またはすなわち、1である場合にだけいつものようにLocalConnectionDescriptorを返す。
Andreasen & Hancock Informational [Page 7] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[7ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
more parameters changed since the last LocalConnectionDescriptor issued (e.g., if a T.38 LCD was issued or a transport address in the audio LCD was changed).
LocalConnectionDescriptorが発行した最終以来、より多くのパラメタが変化しました(例えば、T.38 LCDを発行したか、またはオーディオのLCDの輸送アドレスを変えたなら)。
2.1.2. Gateway Procedure
2.1.2. ゲートウェイ手順
A gateway using the gateway procedure, also known as Gateway controlled mode, may initiate special fax handling upon detecting a fax call. The details of this special fax handling are outside the scope of this document. However, in order to use any special fax handling, support for it MUST be negotiated with the other side by passing and recognizing relevant parameters via the LocalConnectionDescriptor and RemoteConnectionDescriptor (this includes the use of RTP-based T.38). If the other side has not indicated support for the special fax handling desired, the gateway MUST NOT attempt to initiate it. When special fax handling is initiated, a "gwfax(start)" event MUST be generated, thereby enabling the Call Agent to differ between the Call Agent and gateway controlled mode while still being informed about the actual change to fax. When the special gateway handling of fax ends, a "gwfax(stop)" or "gwfax(failure)" event MUST be generated.
また、ゲートウェイがモードを制御したので知られていて、ゲートウェイがゲートウェイ手順を用いて、開始スペシャルがファックスでファックス呼び出しを検出するときの取り扱いを送りますように。 このドキュメントの範囲の外にこの特別なファックス取り扱いの詳細があります。 しかしながら、どんな特別なファックス取り扱いも使用するために、LocalConnectionDescriptorとRemoteConnectionDescriptorを通して関連パラメタを通過して、認識することによって、それのサポートを反対側と交渉しなければなりません(これはRTPベースのT.38の使用を含んでいます)。 反対側で特別なファックス取り扱いのどんな示されたサポートも望んでいないなら、ゲートウェイは、それを開始するのを試みてはいけません。 特別なファックス取り扱いが開始されるとき、「gwfax(始める)」出来事は発生しなければなりません、その結果、ファックスで送る実際の変化に関してまだ知識がある間、CallエージェントがCallエージェントとゲートウェイの制御モードの間で異なるのを可能にします。 ファックスの特別なゲートウェイ取り扱いが終わるとき、「gwfax(止まる)」か「gwfax(失敗)」出来事は発生しなければなりません。
2.1.3. Off Procedure
2.1.3. 手順で
A gateway using the "off" procedure will not invoke any special fax procedures, e.g., T.38, when detecting a fax. However, the gateway may still adjust local echo cancellation and/or switch to an alternative codec as needed. Also, a "nopfax(start)" event MUST be generated; a corresponding "stop" event, however, will not.
ファックスを検出するとき、“off"手順を用いるゲートウェイはどんな特別なファックス手順、例えばT.38も呼び出さないでしょう。 しかしながら、ゲートウェイは、まだローカルエコーキャンセルを調整している、そして/または、必要に応じて代替のコーデックに切り替わるかもしれません。 また、「nopfax(始める)」出来事は発生しなければなりません。 しかしながら、対応する「停止」出来事は望んでいます。
Generating a "stop" event would imply that the gateway had to infer when the fax call ends, which involves processing the media stream. However, when using the "off" mode, such processing is not expected to occur.
「停止」出来事がファックス呼び出しであるときに、推論するためにゲートウェイがそうしたのを含意する発生(メディアの流れを処理することを伴う)は終わります。 しかしながら、“off"モードを使用するとき、そのような処理が起こらないと予想されます。
2.1.4. Mode Operation
2.1.4. モード操作
For each of the above modes, the RemoteConnectionDescriptor provides information on what procedure(s) the other side supports. The following rules are used to determine which procedure to use:
それぞれの上のモードのために、RemoteConnectionDescriptorは反対側がどんな手順を支えるかの情報を提供します。 以下の規則はどの手順を用いたらよいかを決定するのに使用されます:
1. Whatever the Call Agent specified in the Fax
LocalConnectionOptions for the current command MUST be adhered to.
If the gateway cannot satisfy any of the options, the command
fails (error code 532 -- unsupported value(s) in
LocalConnectionOptions is RECOMMENDED).
1. Callエージェントが現在のコマンドのためのファックスLocalConnectionOptionsで指定したことなら何でも固く守らなければなりません。 ゲートウェイがオプションのどれかを満たすことができないなら、コマンドは失敗します(誤りは532をコード化します--LocalConnectionOptionsのサポートされない値はRECOMMENDEDです)。
Andreasen & Hancock Informational [Page 8] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[8ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
2. If both Fax LocalConnectionOptions and a
RemoteConnectionDescriptor are provided, the procedure selected
MUST be supported by both sides -- this is currently only an issue
for "T.38 Strict". A procedure can be satisfied by the remote
side if:
2. ファックスLocalConnectionOptionsとRemoteConnectionDescriptorの両方を提供するなら、両側は選択された手順を支持しなければなりません--現在これが問題にすぎない、「T.38厳しいです」。 遠隔地側で手順を満たすことができる、:
* the relevant MIME media type, e.g., "image/t38", is included in
the "m=" line in the RemoteConnectionDescriptor, or
* または、例えば、関連MIMEメディアタイプ、「イメージ/t38"、含まれているコネがRemoteConnectionDescriptorの「m=」線である、」
* the relevant MIME media type is included as a capability (see
[RFC3407]) in the RemoteConnectionDescriptor.
* 関連MIMEメディアタイプは能力([RFC3407]を見る)としてRemoteConnectionDescriptorに含まれています。
If the gateway cannot select any of the procedures in the Fax
LocalConnectionOptions, the command fails (error code 532 is
RECOMMENDED). Note that "T.38 Loose", "gateway", and "off" -- by
definition -- can always be supported by an implementation that
supports this package, irrespective of what the
RemoteConnectionDescriptor indicates.
ゲートウェイがファックスLocalConnectionOptionsの手順のどれかを選択できないなら、コマンドは失敗します(エラーコード532はRECOMMENDEDです)。 このパッケージを支える実現で「T.38はほどける」、「ゲートウェイ」、および“off"を定義上いつも支持できることに注意してください、RemoteConnectionDescriptorが示すことでは、関係ありません。
3. If the Call Agent did not include any Fax LocalConnectionOptions
or a RemoteConnectionDescriptor with the command, the gateway MUST
continue using whichever procedure it is currently using.
3. CallエージェントがどんなファックスLocalConnectionOptionsかコマンドがあるRemoteConnectionDescriptorも入れなかったなら、ゲートウェイは、それが現在用いている手順を用い続けなければなりません。
4. If the Call Agent did not include any Fax LocalConnectionOptions,
but a RemoteConnectionDescriptor was included, the gateway MUST
follow rule 2 in selecting a procedure. In so doing, the default
Fax LocalConnectionOptions, i.e., "gateway" in CreateConnection,
or the current value in ModifyConnection, MUST be used. In the
case of ModifyConnection, the outcome of the command does not
depend on the gateway being able to select one of these "default"
procedures (as described in Section 2.1). Note that this is not
an issue for the CreateConnection command, since the default value
can always be supported by definition.
4. Callエージェントが少しのファックスLocalConnectionOptionsも入れませんでしたが、RemoteConnectionDescriptorが含まれていたなら、ゲートウェイは手順を選択する際に規則2に従わなければなりません。 そうする際に、デフォルトファックスLocalConnectionOptions(すなわち、CreateConnectionの「ゲートウェイ」、またはModifyConnectionの現行価値)を使用しなければなりません。 ModifyConnectionの場合では、コマンドの結果はこれらの「デフォルト」手順の1つを選択できるゲートウェイに依存しません(セクション2.1で説明されるように)。 これがCreateConnectionコマンドのための問題でないことに注意してください、定義上いつもデフォルト値を支持できるので。
5. A previously received RemoteConnectionDescriptor does not affect
what procedure can be selected. Only a RemoteConnectionDescriptor
supplied with the current command affects the procedure selection.
However, in order to send media of a given type (e.g.,
"image/t38"), the most recently received
RemoteConnectionDescriptor MUST include a corresponding media
line.
5. 以前に容認されたRemoteConnectionDescriptorは、どんな手順を選択できるかに影響しません。 現在のコマンドが供給されたRemoteConnectionDescriptorだけが手順選択に影響します。 しかしながら、当然のことのメディアを送るためにタイプしてください、(例えば、「イメージ/t38")、最も最近容認されたRemoteConnectionDescriptorが対応するメディア線を含まなければならない、」
Andreasen & Hancock Informational [Page 9] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[9ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
The following examples illustrate the use of the above rules:
以下の例は上の規則の使用を例証します:
Per rule 1, a gateway that only supports standard T.38 fax relay will fail a command that only contains the fax option "mypar", whereas it will succeed a command that contains "t38-loose", "gw", "off", or no fax LCO. A command that only contained "t38", i.e., use of T.38 in "strict" mode, may or may not succeed (depending on the RemoteConnectionDescriptor).
それは「ゆるいt38」を含むコマンドを引き継ぐでしょう、そして、標準のT.38ファックスリレーを支えるだけであるゲートウェイは規則1に従ってファックスオプション"mypar"を含むだけであるコマンドに失敗するでしょうが、"gw"、“off"、またはいいえがファックスで「t38"(すなわち、「厳しい」モードにおけるT.38の使用)は成功(RemoteConnectionDescriptorによって)であるかもしれない」をLCOそれが含んだだけであるコマンドに送ります。
A gateway supporting T.38 that receives a CreateConnection command with the fax handling LCO set to "t38" and a RemoteConnectionDescriptor with neither a T.38 capability nor a T.38 media stream will fail per rule 2. Had the fax handling LCO included either "t38-loose", "gw" or "off", the command would have succeeded, and any of the procedures included could have been selected.
ファックス取り扱いLCOでCreateConnectionコマンドを受け取るT.38を支持するゲートウェイは「どちらもT.38能力かT.38メディアの流れがあるt38"とRemoteConnectionDescriptorは規則2単位で失敗すること」にセットしました。 ファックス取り扱いLCOが「ゆるいt38」、"gw"か“off"のどちらかを含んでいたなら、コマンドは成功したでしょうに、そして、手順のどれかを含んでいるのは選択されたかもしれません。
Assume a gateway supporting T.38 has successfully executed a CreateConnection command with fax handling set to "t38" (i.e., strict). If the gateway now receives a ModifyConnection command without a fax handling LCO but with a RemoteConnectionDescriptor that has neither a T.38 capability nor a media stream with "image/t38", the command will succeed (since rule 1 has no effect in that case). However, per rule 2 and 4, there will not be any T.38 procedure in place. Had the Call Agent instead included a fax handling LCO set to "t38" again, the command would have failed per rule 2.
T.38を支持するゲートウェイが「t38"(すなわち、厳しい)」に設定されたファックス取り扱いで首尾よくCreateConnectionコマンドを実行したと仮定してください。 ゲートウェイが現在受信されるなら、ファックスがLCOにもかかわらず、RemoteConnectionDescriptorと共にそれを扱うことのないModifyConnectionコマンドには、T.38能力もメディアの流れも「イメージ/t38"、コマンドは成功(規則1はその場合効き目がないので)」と共にありません。 しかしながら、どんなT.38手順も適所に規則2と4単位でないでしょう。 代わりにCallエージェントをファックス取り扱いLCOが「一方、規則2単位でコマンドが失敗したt38"」に設定した含んでいたこと。
Finally, it should be noted that a switch to T.38 can be initiated by either one or both of the originating and terminating gateways and hence implementations MUST be prepared to handle this. This includes the case where both sides initiate the switch, which for example can occur when the originating fax generates Calling Tone (CNG) and the terminating fax detects V.21 fax preamble (see [T30]) before the switch to T.38 has been performed on the terminating side.
最終的に、T.38へのスイッチをどちらかで開始できなければならないか、または由来、ゲートウェイを終えて、およびしたがって、実現についてこれを扱うように準備しなければならないことに注意されるべきです。 これは両側が由来しているファックスがCalling利根(CNG)を発生させて、終わりファックスがV.21ファックス序文を検出するとき([T30]を見てください)例えばT.38へのスイッチが終わり側に実行される前に現れることができるスイッチを開始するケースを含んでいます。
2.1.5. Detecting a Fax Call
2.1.5. ファックス呼び出しを検出します。
A fax call can be detected by several different means (e.g., V.21 fax preamble, T.30 CNG tone, or V.8 signals) depending on the fax transmission method being used. Implementations of this package MUST at a minimum detect a fax call based on V.21 fax preamble.
使用されるファックス透過法によって、いくつかの異なった手段(例えば、V.21はファックスで序文を送ります、とT.30 CNGが調子を変えるか、またはV.8は合図する)でファックス呼び出しを検出できます。 このパッケージの実現は最小限でV.21ファックス序文に基づくファックス呼び出しを検出しなければなりません。
Triggering based on T.30 CNG tone MAY be done; this is generally considered acceptable for G3 and lower fax speeds. However, when used with T.38 version 2 or earlier, it will impact V.34 high-speed fax. The reason is that T.38 version 2 (and earlier) does not support the V.8 ANSam and CM signals used with V.34 fax, and hence the V.34 faxes will downspeed to G3 (14.400 bps) or lower when using T.38 version 2 (or earlier). Also, a few rare cases of modems
T.30 CNGトーンに基づく引き金となることは完了しているかもしれません。 一般に、これはG3と下側のファックス速度において許容できると考えられます。 しかしながら、T.38バージョン2以前と共に使用されると、それはV.34の高速ファックスに影響を与えるでしょう。 理由がT.38バージョン2(より早くに)が信号がV.34ファックスで使用したV.8 ANSamとCMをサポートしないということであり、T.38バージョン2(前)を使用するとき、したがって、V.34ファックスは、G3(14.400ビーピーエス)にdownspeedしたか、または下ろされるでしょう。 モデムのいくつかのまれなケースも
Andreasen & Hancock Informational [Page 10] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[10ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
generating T.30 CNG tones for non-fax calls have been reported; such modems would generate a false trigger for fax. As a consequence of the above, it is RECOMMENDED that implementations of this package that support T.30 CNG-based fax detection provide a configuration option to disable it for T.38 version 2 (or earlier).
非ファックスのためにT.30 CNGトーンを発生させて、呼び出しは報告されました。 そのようなモデムはファックスのために偽の引き金を発生させるでしょう。 上記の結果として、T.30 CNGベースのファックス検出を支持するこのパッケージの実現がT.38バージョン2(より早くに)のためにそれを無能にするために設定オプションを提供するのは、RECOMMENDEDです。
2.1.6. Considerations for Determining Which Procedures to Request
2.1.6. どの手順を要求したらよいかを決定するための問題
It is important to understand the implications of using any one of the above defined procedures. Furthermore, multiple alternative procedures can be requested, however not all combinations make sense. In this section, we elaborate on both of these issues.
上の定義された手順のどれかを用いる含意を理解しているのは重要です。 その上、複数の交替手続きを要求できて、しかしながら、すべての組み合わせが理解できるというわけではありません。 このセクションで、私たちはこれらの問題の両方について詳しく説明します。
Use of the T.38 Strict mode is ideal in an environment where it is known that other endpoints generate RFC 3407 [RFC3407] capability descriptions with T.38 fax relay information. If a RemoteConnectionDescriptor without T.38 fax relay capabilities is received in such an environment, it is known that the other side does not support T.38, and hence an unsuccessful attempt to switch to T.38 (which in turn may lead to a failed fax call) can be avoided. If it is not known whether other endpoints support the RFC 3407 [RFC3407] capability descriptors, the trade-off is less clear. The advantage is that a switch to T.38 will only be attempted if it is known that the other side supports it, but endpoints that do not indicate support for T.38 may still support it; however, T.38 will not be used with these, which in turn may lead to unnecessary fax failures with low-bandwidth codecs or lossy networks.
T.38 Strictモードの使用は他の終点がT.38ファックスリレー情報でRFC3407[RFC3407]能力記述を発生させるのが知られているところで環境で理想的です。 そのような環境でT.38ファックスリレー能力のないRemoteConnectionDescriptorを受け取るなら、反対側がT.38を支えないのを知っていて、したがって、T.38(順番に失敗したファックス呼び出しに通じるかもしれない)に切り替わる失敗の試みを避けることができます。 他の終点がRFC3407[RFC3407]能力記述子を支持するかどうかは知られていないなら、トレードオフがそれほど明確ではありません。 利点は反対側がそれを支えるのが知られている場合にだけT.38へのスイッチが試みられますが、T.38のサポートを示さない終点がまだそれを支持しているかもしれないということです。 しかしながら、T.38はこれら、どれが順番に低バンド幅コーデックがある不要なファックスの故障に通じるかもしれないか、そして、または損失性ネットワークと共に使用されないでしょう。
Use of the T.38 loose mode involves the same considerations as for T.38 Strict, however the pros and cons are reversed. If a peer endpoint does not support T.38, the T.38 loose mode will still attempt to switch to T.38 (and fail), which in turn may lead to a failed fax call. On the other hand, if the peer endpoint does not support the RFC 3407 [RFC3407] capability descriptors, but the peer endpoint does in fact support T.38, T.38 would still be used with this mode.
T.38のゆるいモードの使用はT.38 Strictのように同じ問題にかかわって、しかしながら、賛否両論は逆にされます。 同輩終点がT.38を支持しないと、それでも、T.38のゆるいモードは、T.38(失敗する)に切り替わるのを試みるでしょう。(順番に、T.38は失敗したファックス呼び出しに通じるかもしれません)。 他方では、同輩終点がRFC3407[RFC3407]能力記述子を支持しませんが、同輩終点が事実上T.38を支持するなら、T.38はこのモードでまだ使用されているでしょう。
In summary, there is no single good answer to the use of either T.38 Strict or T.38 loose mode; it depends on the capabilities of the endpoints involved as well as the trade-off between potentially letting fax calls fail due to lack of capability indications (where T.38 is otherwise supported) versus potentially letting fax calls fail due to an unsuccessful switch to T.38 (because T.38 in fact was not supported). It should be noted that Call Agents may have means beyond RFC 3407 [RFC3407] capability descriptors to determine if a peer endpoint supports T.38 or not. For example, when SIP is used as the signaling protocol with other peers (e.g., Call Agents or other SIP devices), the SIP OPTIONS method can be used to learn whether
概要には、T.38 StrictかT.38のゆるいモードのどちらかの使用のどんなただ一つの適切な答もありません。 それはファックス呼び出しが失敗のスイッチのため潜在的にT.38に失敗することに対してファックス呼び出しが能力指摘(T.38が別の方法で支持されるところ)の不足のため潜在的に失敗することの間のトレードオフと同様にかかわる終点の能力によります(T.38が事実上支持されなかったので)。 CallエージェントにはRFC3407[RFC3407]能力記述子を超えた同輩終点がT.38を支持するかどうか決定する手段があるかもしれないことに注意されるべきです。 シグナリングが他の同輩(例えば、Callエージェントか他のSIP装置)と共に議定書を作るときSIPが使用されているとき、例えば、学ぶのにSIP OPTIONS方法を使用できます。
Andreasen & Hancock Informational [Page 11] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[11ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
T.38 is supported. Also, if the Call Agent allows use of high-bandwidth codecs with redundancy when support for T.38 is not indicated, fax calls may still succeed without the use of T.38, even in networks with non-negligible packet loss.
T.38は支持されます。 また、T.38のサポートが示されないとき、Callエージェントが冗長がある高帯域コーデックの使用を許すなら、ファックス呼び出しはT.38の使用なしでまだ成功しているかもしれません、非取るにたらないパケット損失に伴うネットワークでさえ。
When the gateway controlled mode is selected, there will only be special fax handling if the two peer endpoints support the same fax handling method; note that the details of the actual method is entirely up to the vendor. Also note that if the two peer endpoints do not support the same method for fax handling or if the method is not indicated in the SDP exchanged, there will be no special fax handling in place. Furthermore, the Call Agent will not be aware that this is the case until the fax transmission starts and a "nopfax(start)" event is generated.
ゲートウェイの制御モードが選択されるとき、2つの同輩終点が同じファックス取り扱い方法を支持する場合にだけ、特別なファックス取り扱いがあるでしょう。 実際の方法の詳細が完全な業者次第であることに注意してください。 また、2つの同輩終点がファックス取り扱いのために同じ方法を支持しないか、または方法が交換されたSDPで示されないと、どんな特別なファックス取り扱いも適所にないことに注意してください。 その上、Callエージェントはファックス送信が始まるまでこれがそうであることを意識しないでしょう、そして、「nopfax(始める)」出来事は発生します。
The off mode is straightforward; there will be no special procedure in place for fax handling, except for the usual handling of echo cancellation and possibly a change to a higher bandwidth codec.
オフモードは簡単です。 どんな特別な手順もファックス取り扱いのために適所にないでしょう、エコーキャンセルの普通の取り扱いとことによるとより高い帯域幅コーデックへの変化を除いて。
Having looked at the individual procedures in more detail, we now elaborate on some of the combinations of procedures that may be requested:
さらに詳細に独特の手順を見て、私たちは現在、要求されているかもしれない手順の組み合わせのいくつかについて詳しく説明します:
* T.38 strict:
If the T.38 strict procedure is placed after the T.38 loose or the
off procedure (both of which can always be supported), it will not
be selected. Apart from this, it makes little sense to request
both T.38 strict and T.38 loose.
* T.38厳しい: T.38がほどけた後にT.38の厳しい手順が置かれるか、そして、オフ手順(いつもそれの両方を支持できる)、それは選択されないでしょう。 これは別として、それでT.38厳しい状態で両方を要求する小さい感覚とT.38はゆるくなります。
* T.38 loose:
The T.38 loose procedure can always be supported, so any procedure
specified after T.38 loose will not be selected.
* T.38はほどけます: いつもT.38のゆるい手順を支持できるので、T.38がほどけた後に指定されたどんな手順も選択されないでしょう。
* Gateway:
The gateway controlled procedure can always be supported. If the
gateway controlled procedure would have resulted in no special fax
procedure and further options (except off) are provided, those
procedures will be attempted. If neither of those procedures can
be supported, there will be no special fax procedure in place.
* ゲートウェイ: いつもゲートウェイの制御手順を支持できます。 ゲートウェイの制御手順がどんな特別なファックス手順ももたらしていなくて、一層のオプション(except off)を提供すると、それらの手順を試みるでしょう。 それらの手順のどちらも支持できないと、どんな特別なファックス手順も適所にないでしょう。
* Off:
The off procedure can always be supported. Any procedure specified
after this one will not be selected.
* オフ: いつもオフ手順を支持できます。 これが選択されなかった後にどんな手順も指定しました。
Andreasen & Hancock Informational [Page 12] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[12ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
2.2. Events and Signals
2.2. 出来事と信号
The following events are defined in support of the above:
以下の出来事は上記を支持して定義されます:
------------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|---------|----------------------------|-----|---------------------|
| gwfax | Gateway controlled fax | x | |
| nopfax | No special fax handling | x | |
| t38 | T.38 fax relay | x | |
------------------------------------------------------------------
------------------------------------------------------------------ | シンボル| 定義| R| S持続時間| |---------|----------------------------|-----|---------------------| | gwfax| ゲートウェイの制御ファックス| x| | | nopfax| 特別なファックス取り扱いがありません。| x| | | t38| T.38ファックスリレー| x| | ------------------------------------------------------------------
The definitions of the individual events are provided in the following subsections.
個人種目の定義を以下の小区分に提供します。
2.2.1. Gateway Controlled Fax (gwfax)
2.2.1. ゲートウェイの制御ファックス(gwfax)
The "gateway controlled fax" event occurs when the gateway handled fax procedure either starts, stops, or fails. The event is encoded as "gwfax", and the following event parameters, which apply to ObservedEvents only, are defined:
ゲートウェイの扱われたファックス手順が始まるか、止まるか、または失敗すると、「ゲートウェイの制御ファックス」出来事は起こります。 "gwfax"、および以下のイベントパラメタ(ObservedEventsだけに適用される)が定義されるとき、出来事はコード化されます:
* start:
Gateway controlled fax procedure was initiated. The Call Agent
SHOULD refrain from issuing media handling instructions to the
gateway until either a "gwfax(stop)" or "gwfax(failure)" event is
generated.
* 以下を始めてください。 ゲートウェイの制御ファックス手順は着手されました。 CallエージェントSHOULDは、「gwfax(止まる)」か「gwfax(失敗)」のどちらか出来事が発生するまでメディア取扱上の注意事項をゲートウェイに発行するのを控えます。
* stop:
Gateway controlled fax procedure ended and the gateway did not
detect any errors. Note that this does not necessarily imply a
successfully transmitted fax. It merely indicates that the gateway
controlled fax procedure has ended and the procedure itself did not
encounter any errors. Media parameters for the connection are as
before the gateway handled fax procedure started.
* 以下を止めてください。 ゲートウェイの制御ファックス手順は終わりました、そして、ゲートウェイは少しの誤りも検出しませんでした。 これが必ず首尾よく伝えられたファックスを含意するというわけではないことに注意してください。 それは、ゲートウェイの制御ファックス手順が終わって、手順自体が少しの誤りにも遭遇しなかったのを単に示します。 接続へのメディアパラメタは従来と同様始められたゲートウェイの扱われたファックス手順です。
* failure:
The gateway controlled fax procedure ended abnormally. Some kind
of problem was encountered in the gateway controlled fax procedure,
and the procedure ended. Media parameters are as before the
gateway handled fax procedure started.
* 失敗: ゲートウェイの制御ファックス手順は異常に終わりました。 ゲートウェイの制御ファックス手順である種の問題が行きあたられました、そして、手順は終わりました。 メディアパラメタは従来と同様始められたゲートウェイの扱われたファックス手順です。
One of the above parameters will be present when the event is reported. The "gwfax" event MAY be parameterized with additional parameters in ObservedEvents, however it is RECOMMENDED that one of the above parameters is the first parameter supplied. Unknown parameters MUST be ignored.
出来事が報告されるとき、上記のパラメタの1つは存在するでしょう。 追加パラメタがObservedEventsにある状態で、"gwfax"出来事はparameterizedされるかもしれなくて、しかしながら、上記のパラメタの1つが提供された最初のパラメタであることはRECOMMENDEDです。 未知のパラメタを無視しなければなりません。
Andreasen & Hancock Informational [Page 13] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[13ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
The following example illustrates the encoding of the "gwfax" event:
以下の例は"gwfax"出来事のコード化を例証します:
O: fxr/gwfax(start)
O: fxr/gwfax(stop, foobar)
O: fxr/gwfax(始める)O: fxr/gwfax(停止、foobar)
2.2.2. No Special Fax Handling (nopfax)
2.2.2. 特別なファックス取り扱いがありません。(nopfax)
The "no special fax handling" event occurs when there is no special fax handling procedure in place and a fax call is detected. This can happen either because no special fax handling procedure was requested (including "off") or negotiation resulted in no special fax handling procedure being supported. The event is encoded as "nopfax", and the following event parameter, which applies to ObservedEvents only, is defined:
どんな特別なファックス取り扱い手順も適所にないとき、「特別なファックス取り扱いがありません」出来事は起こります、そして、ファックス呼び出しは検出されます。 どんな特別なファックス取り扱い手順も要求されなかったか(“off"を含んでいて)、または交渉が支持されるどんな特別なファックス取り扱い手順ももたらさなかったので、これは起こることができます。 "nopfax"、および以下のイベントパラメタ(ObservedEventsだけに適用される)が定義されるとき、出来事はコード化されます:
* start:
No special fax handling procedure is in place, however a fax call
is now detected. The Call Agent may have to issue further commands
in order to ensure a successful fax call (e.g., switch to another
codec).
* 以下を始めてください。 どんな特別なファックス取り扱い手順も適所になくて、しかしながら、ファックス呼び出しは現在、検出されます。 Callエージェントは、うまくいっているファックス呼び出しを確実にするためにさらなるコマンドを発行しなければならないかもしれません(例えば、別のコーデックに切り替わってください)。
The above parameter will be present when the event is reported. The "nopfax" event MAY be parameterized with additional parameters on ObservedEvents, however it is RECOMMENDED that the above parameter is the first parameter supplied. Unknown parameters MUST be ignored. Note that this event currently cannot be parameterized with "stop" or "failure" as it only detects the beginning of a fax call.
出来事が報告されるとき、上記のパラメタは存在するでしょう。 "nopfax"出来事はObservedEventsに関する追加パラメタでparameterizedされるかもしれなくて、しかしながら、上記のパラメタが提供された最初のパラメタであることはRECOMMENDEDです。 未知のパラメタを無視しなければなりません。 ファックス呼び出しの始まりを検出するだけであるとき現在「停止」か「失敗」でこの出来事をparameterizedされることができないことに注意してください。
The following example illustrates the encoding of the "nopfax" event:
以下の例は"nopfax"出来事のコード化を例証します:
O: fxr/nopfax(start)
O: fxr/nopfax(始め)
2.2.3. T.38 Fax Relay (t38)
2.2.3. T.38ファックスリレー(t38)
The "T.38 fax relay" event occurs when one of the T.38 fax relay procedures (strict or loose) either starts, stops, or fails. The event is encoded as "t38", and the following event parameters, which apply to ObservedEvents only, are defined:
T.38ファックスリレー手順(厳しいかゆるい)の1つが始まるか、止まるか、または失敗すると、「T.38ファックスリレー」出来事は起こります。 「t38"、および以下のイベントパラメタ(ObservedEventsだけに適用される)は定義される」とき、出来事がコード化されます。
* start:
A fax call was detected on the endpoint and the Call Agent
controlled T.38 fax relay procedure was initiated. The Call Agent
SHOULD modify each side of the connection to start using the
"image/t38" media format, unless they already do. Note that, as
long as use of the Call Agent controlled T.38 relay procedure is in
effect, the event will be generated upon fax call detection,
irrespective of the current encoding method on any connections on
the endpoint (incl. "image/t38"). The "t38(start)" event MUST be
* 以下を始めてください。 ファックス呼び出しは終点に検出されました、そして、制御T.38がファックスでリレー手順を送るCallエージェントは開始されました。 CallエージェントSHOULDは、「既にしないならメディアがフォーマットするイメージ/t38"」を使用し始めるように接続の各側面を変更します。 Callエージェントの使用が制御された限り、T.38リレー手順が有効である、出来事はファックス呼び出し検出のときに発生するでしょう、終点におけるどんな接続のときにも方法をコード化する電流において関係ないことに注意してください。(incl。 「イメージ/t38"」). 「t38(始める)」出来事はそうであるに違いありません。
Andreasen & Hancock Informational [Page 14] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[14ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
generated at most once by the endpoint per fax call, regardless of
whether or not it is requested again in a subsequent requested
events list.
それが再びその後の要求されたイベントリストで要求されているかどうかにかかわらずファックス呼び出しあたりの終点のそばで高々かつて発生しています。
* stop:
Call Agent controlled T.38 fax relay procedure ended and the
gateway did not detect any errors. Note that this does not
necessarily imply a successfully transmitted fax. It merely
indicates that the Call Agent controlled T.38 fax relay procedure
has ended and the procedure itself did not encounter any errors.
The Call Agent may want to modify the media parameters for each
side of the connection. Note that, in contrast to the gateway
controlled fax procedure case, media parameters such as codecs do
not automatically revert to their values before the start of the
fax call; however, echo cancellation and silence suppression do per
the procedures in [RFC3435] Section 2.3.5. The "t38(stop)" event
MUST NOT be generated unless a corresponding "t38(start)" event for
the fax call in question was generated earlier.
* 以下を止めてください。 ファックスリレー手順が終わらせた呼び出しエージェントの制御T.38とゲートウェイは少しの誤りも検出しませんでした。 これが必ず首尾よく伝えられたファックスを含意するというわけではないことに注意してください。 それは、Callエージェントがファックスリレー手順が終わらせたT.38を制御して、手順自体が少しの誤りにも遭遇しなかったのを単に示します。 Callエージェントは接続の各側面のためのメディアパラメタを変更したがっているかもしれません。 コーデックなどのメディアパラメタがファックス呼び出しの始まりの前にゲートウェイの制御ファックス手順ケースと対照して自動的にそれらの値に戻らないことに注意してください。 しかしながら、エコーキャンセルと沈黙抑圧は[RFC3435]で手順単位でセクション2.3.5をします。 問題のファックス呼び出しのための対応する「t38(始める)」出来事が、より早く発生しなかったなら、「t38(止まる)」出来事は発生してはいけません。
* failure:
Call Agent controlled T.38 fax relay procedure ended abnormally.
Some kind of problem in the Call Agent controlled T.38 fax relay
procedure was encountered, and the procedure ended. The Call Agent
may want to modify the media parameters for each side of the
connection. Note that, in contrast to the gateway controlled fax
procedure case, media parameters such as codecs do not
automatically revert to their state before the start of the fax
call; however, echo cancellation and silence suppression do per the
procedures in [RFC3435] Section 2.3.5. The "t38(failure)" event
MUST NOT be generated unless a corresponding "t38(start)" event for
the fax call in question was generated earlier.
* 失敗: エージェントの制御T.38を異常に終わったファックスリレー手順と呼んでください。 制御T.38がファックスでリレー手順を送るCallエージェントのある種の問題が行きあたられました、そして、手順は終わりました。 Callエージェントは接続の各側面のためのメディアパラメタを変更したがっているかもしれません。 コーデックなどのメディアパラメタがファックス呼び出しの始まりの前にゲートウェイの制御ファックス手順ケースと対照して自動的にそれらの状態に戻らないことに注意してください。 しかしながら、エコーキャンセルと沈黙抑圧は[RFC3435]で手順単位でセクション2.3.5をします。 問題のファックス呼び出しのための対応する「t38(始める)」出来事が、より早く発生しなかったなら、「t38(失敗)」出来事は発生してはいけません。
One of the above parameters will be present when the event is reported. The "t38" event MAY be parameterized with additional parameters, however it is RECOMMENDED that one of the above parameters is the first parameter supplied. Unknown parameters MUST be ignored.
出来事が報告されるとき、上記のパラメタの1つは存在するでしょう。 「しかしながら、t38"出来事は追加パラメタでparameterizedされるかもしれなくて、上記のパラメタの1つが提供された最初のパラメタであることはRECOMMENDEDです。」 未知のパラメタを無視しなければなりません。
The following example illustrates the encoding of the "t38" event:
以下の例がコード化を例証する、「t38"出来事:」
O: fxr/t38(start)
O: fxr/t38(stop, foobar)
O: fxr/t38(始める)O: fxr/t38(停止、foobar)
2.3. Connection Parameters
2.3. 接続パラメタ
The connection parameters for the connection, that measures packets and octets sent and received, MUST include packets and octets for fax handling as well. Interarrival jitter and average transmission delay
接続への接続パラメタ(パケットと八重奏が送って、受けたその測定)はまた、ファックス取り扱いのためのパケットと八重奏を含まなければなりません。 Interarrivalジターと平均したトランスミッション遅れ
Andreasen & Hancock Informational [Page 15] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[15ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
calculation however MAY NOT be performed while fax is in progress, e.g., if T.38 is used. In such cases, the interarrival jitter and average transmission delay calculations are simply suspended until calculations can resume, e.g., by changing back to an RTP-based media stream.
しかしながら、例えば、T.38が使用されているなら、ファックスが進行している間、計算は実行されないかもしれません。 そのような場合、計算が再開できるまで、interarrivalジターと平均したトランスミッション遅れ計算は単に中断します、例えば、RTPベースのメディアの流れに変わって戻ることによって。
In addition to these connection parameters, the fax package defines the following connection parameters, which gateways MAY support:
これらの接続パラメタに加えて、ファックスパッケージは以下の接続パラメタを定義します:(ゲートウェイはパラメタを支持するかもしれません)。
Number of fax pages sent (PGS):
ファックスページの数は(PGS)を送りました:
The cumulative number of fax pages sent by the endpoint for the
life of the connection. The parameter is encoded as "PGS", and
the value supplied is a string of up to nine decimal digits.
終点によって接続の人生に送られたファックスページの累積している数。 パラメタは「PGS」としてコード化されます、そして、供給された値は一連の最大9つの10進数字です。
Number of fax pages received (PGR):
ファックスページの数は(PGR)を受けました:
The cumulative number of fax pages received by the endpoint for
the life of the connection. The parameter is encoded as "PGR",
and the value supplied is a string of up to nine decimal digits.
終点によって接続の人生に受け取られたファックスページの累積している数。 パラメタは"PGR"としてコード化されます、そして、供給された値は一連の最大9つの10進数字です。
The following example illustrates the use of these parameters:
以下の例はこれらのパラメタの使用を例証します:
P: FXR/PGS=3, FXR/PGR=0, PS=1245, OS=62345, ...
P: FXR/PGS=3、FXR/PGR=0、PS=1245、OS=62345…
2.4. Negotiation of T.38 Parameters
2.4. T.38パラメタの交渉
T.38 Annex D [T38] defines a number of T.38 parameters that can be negotiated in the SDP. Currently, T.38 does not specify procedures for how each of these parameters is negotiated or in particular whether each side has to use the same value. Therefore, we considered adding such definitions and procedures here. However, it is expected that T.38 will rectify the above, which could lead to conflicting definitions and procedures. To avoid that, we instead assume the existence of an offer/answer [RFC3264] section for T.38, where T.38 Annex D parameters are classified as either declarative or negotiated, and we then provide guidelines for how to map such definitions and procedures to the MGCP fax package defined here.
T.38別館D[T38]はSDPで交渉できる多くのT.38パラメタを定義します。 現在、T.38はそれぞれのこれらのパラメタがどのように交渉されるか、そして、または特に、それぞれの側が同じ値を使用しなければならないかどうかに手順を指定しません。 したがって、私たちは、ここでそのような定義と手順を加えると考えました。 しかしながら、T.38が上記を正すと予想されます。(上記は闘争定義へのリードと手順をそうすることができました)。 それを避けるために、私たちは代わりにT.38のための申し出/答え[RFC3264]部とここで定義されたMGCPファックスパッケージへの手順の存在を仮定します。そこでT.38 Annex Dパラメタは、叙述的であるとして分類されるか、または交渉されて、次に、私たちはどうそのような定義を写像するかためにはガイドラインを提供します。
MGCP does not specify use of the offer/answer model but instead operates with the concept of connection handling commands (e.g., CreateConnection and ModifyConnection) that may include a RemoteConnectionDescriptor (SDP) and in turn may generate a LocalConnectionDescriptor (SDP) in their response.
MGCPは申し出/答えモデルの使用を指定しませんが、代わりにRemoteConnectionDescriptor(SDP)を含むかもしれなくて、彼らの応答でLocalConnectionDescriptor(SDP)を順番に、発生させるかもしれない接続取り扱い命令(例えば、CreateConnectionとModifyConnection)の概念で作動します。
Andreasen & Hancock Informational [Page 16] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[16ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
When an MGCP endpoint receives a CreateConnection command without a RemoteConnectionDescriptor, it should follow the corresponding T.38 procedures for generating an initial offer and return the resulting SDP in its LocalConnectionDescriptor.
MGCP終点がRemoteConnectionDescriptorなしでCreateConnectionコマンドを受け取るとき、それは、初期の申し出を発生させるように対応するT.38手順に従って、LocalConnectionDescriptorで結果として起こるSDPを返すべきです。
When an MGCP endpoint receives a CreateConnection command with a RemoteConnectionDescriptor, it should follow the corresponding T.38 procedures for receiving an initial offer and generating an answer to it. The resulting SDP is returned in the LocalConnectionDescriptor.
MGCP終点がRemoteConnectionDescriptorとのCreateConnectionコマンドを受け取るとき、それは初期の申し出を受けて、それの答えを発生させるための対応するT.38手順に従うべきです。 LocalConnectionDescriptorで結果として起こるSDPを返します。
When an MGCP endpoint receives a ModifyConnection command with a RemoteConnectionDescriptor, it cannot determine whether this corresponds to an answer to an initial offer or to a new offer. This is not an issue for declarative parameters since they can be specified independently in either direction. Negotiated parameters, however, require some consideration:
MGCP終点がRemoteConnectionDescriptorとのModifyConnectionコマンドを受け取るとき、それは、これが初期の申し出か新しい申し出の答えに対応するかどうか決定できません。 独自にどちらの方向にもそれらを指定できるので、これは叙述的なパラメタのための問題ではありません。 しかしながら、交渉されたパラメタは何らかの考慮を必要とします:
When an offerer receives an answer to a previous offer, the negotiation has completed and the parameters negotiated can no longer be changed with this offer/answer exchange. The negotiated parameters may be subject to certain validation checks. Conversely, when an answerer receives an offer, the negotiation is open and the answerer may change some of the offered negotiated parameters. Since the MGCP endpoint does not know which situation it is in, it cannot perform the "offerer" validation checks. Likewise, in order to ensure that any required negotiation actually takes place, it needs to process an incoming SDP as an offer. If the SDP in fact does correspond to an offer, then this is obviously correct behavior. However, if the SDP corresponds to an answer, and one or more negotiated parameters did change, then this will result in a new SDP. The Call Agent may or may not contain sufficient intelligence to determine whether or not this new SDP needs to result in another offer/answer exchange.
申出人が受信する、前の申し出、交渉の答えが完成して、パラメタが交渉した、もう、この申し出/答え交換に従って、変えることができません。 交渉されたパラメタはある合法化チェックを受けることがあるかもしれません。 answererが申し出を受けるとき、逆に、交渉は開いています、そして、answererは提供された交渉されたパラメタのいくつかを変えるかもしれません。 MGCP終点が、それがどの状況にあるかを知らないので、それは「申出人」合法化チェックを実行できません。 同様に、どんな必要な交渉も実際に行われるのを確実にするために、それは、申し出として入って来るSDPを処理する必要があります。 SDPが事実上申し出に対応しているなら、これは明らかに正しい振舞いです。 しかしながら、SDPが答え、および1つに対応しているか、そして、さらに交渉されたパラメタが変化して、次に、これは新しいSDPをもたらすでしょう。 Callエージェントはこの新しいSDPが、別の申し出/答え交換をもたらす必要であるかどうか決定できるくらいの知性を含むかもしれません。
For example, if the initial offer (in response to a
CreateConnection without SDP) contained fax version 2, and the
answer (in response to a CreateConnection with SDP) contained fax
version 0, then the corresponding ModifyConnection command (with
SDP) will result in an updated SDP with fax version also set to
zero. If this was the only change in the updated SDP, a new
offer/answer exchange would not be needed. Note that this example
does not imply that it is generally considered a good idea for
Call Agents to parse SDP in order to determine whether or not new
offer/answer exchanges are needed.
例えば、初期の申し出(SDPのないCreateConnectionに対応した)がファックスバージョン2を含んで、答え(SDPとCreateConnectionに対応した)がファックスバージョン0を含んだなら、対応するModifyConnectionコマンド(SDPと)はまた、ゼロに設定されたファックスバージョンでアップデートされたSDPをもたらすでしょう。 これがアップデートされたSDPで唯一の変化であるなら、新しい申し出/答え交換は必要でないでしょうに。 この例が、Callエージェントが新しい申し出/答え交換が必要であるかどうか決定するためにSDPを分析するように一般に、それが名案であると考えられるのを含意しないことに注意してください。
Finally, a ModifyConnection without SDP that generates an SDP needs to be considered. The SDP generated may either correspond to an initial offer/answer exchange or a subsequent offer/answer exchange.
最終的に、SDPを発生させるSDPのないModifyConnectionは、考えられる必要があります。 発生するSDPは初期の申し出/答え交換かその後の申し出/答え交換に対応するかもしれません。
Andreasen & Hancock Informational [Page 17] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[17ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
The endpoint should generate SDP as if it was part of a subsequent offer/answer exchange. If the Call Agent does not desire such semantics, it can simply create a new connection instead.
終点はまるでそれがその後の申し出/答え交換の一部であるかのようにSDPを発生させるべきです。 Callエージェントがそのような意味論を望んでいないなら、それは代わりに単に新しい接続を創造できます。
2.5. Implementation Considerations
2.5. 実現問題
2.5.1. Media IP Address and Port for T.38
2.5.1. T.38のためのメディアIPアドレスとポート
When an endpoint is instructed to change to or from T.38 for a media stream, it SHOULD continue using the same IP address and port the media stream is currently using, since this will minimize any Quality of Service, Network Address Translator (NAT), and Firewall interactions from the change. However, if an endpoint has a good reason, it MAY choose not to follow this recommendation.
終点がいつまで命令されるかはメディアの流れのためにT.38かT.38から変化して、それはSHOULDです。同じIPアドレスとメディアの流れが現在使用しているポートを使用し続けてください、これがServiceのどんなQuality、Network Address Translator(NAT)、および変化からのFirewall相互作用も最小にするので。 しかしながら、終点にもっともな理由があるなら、それは、この推薦に続かないのを選ぶかもしれません。
When an endpoint uses the same port for RTP audio and T.38 with either UDPTL or TCP, packets of one type (e.g., T.38) may be received while expecting packets of another type (RTP audio). Since there is explicit signaling to indicate which type is expected at any given point in time, this does not introduce any new problems. In other words, the receiver does not operate as a demultiplexer with a need to determine if a given packet received is an RTP audio packet or a T.38 UDPTL/TCP packet. The receiver simply processes incoming packets as usual. If T.38 packets are expected, then incoming packets are validated against T.38, and if RTP audio packets are expected, then incoming packets are validated against RTP.
終点がUDPTLかTCPのどちらかとRTPオーディオとT.38に同じポートを使用すると、別のタイプ(RTPオーディオ)にパケットを予想している間、1つのタイプ(例えば、T.38)のパケットを受け取るかもしれません。 時間内に、ポイントを考えて、どれがタイプされるかがいずれでも予想されるのを示すために明白なシグナリングがあるので、これはどんな新しい問題も紹介しません。言い換えれば、受信機は、与えられたパケットが受信されたかどうか決定する必要性があるデマルチプレクサがRTPオーディオパケットかT.38 UDPTL/TCPパケットであるので、動作しません。 受信機は単に通常通りの入って来るパケットを処理します。 T.38パケットが予想されるなら、入って来るパケットはT.38に対して有効にされます、そして、RTPオーディオパケットが予想されるなら、入って来るパケットはRTPに対して有効にされます。
2.5.2. Case Sensitivity
2.5.2. ケース感度
IANA has registered the uppercase string "UDPTL" as the transport protocol identifier to be used for UDP-based T.38. However, the examples provided in Recommendation T.38, as well as most (if not all) current implementations, use the lowercase string "udptl" instead. Implementations conforming to this package SHOULD generate the lowercase string "udptl" and accept the lowercase, uppercase, and mixed upper/lowercase strings as being equivalent.
IANAは、UDPベースのT.38に使用されるために輸送プロトコル識別子として大文字しているストリング"UDPTL"を登録しました。 しかしながら、Recommendation T.38に提供された例、およびほとんどの(すべて)現在の実現が代わりに小文字のストリング"udptl"を使用します。 このパッケージSHOULDに従う実現は、同等であるとして小文字のストリング"udptl"を発生させて、小文字の、そして、大文字していて、複雑な上側の、または、小文字のストリングを認めます。
The attribute "T38MaxBitRate" was once incorrectly registered with IANA as "T38maxBitRate" (lower-case "m"). In accordance with T.38 examples and common implementation practice, the form "T38MaxBitRate" SHOULD be generated by implementations conforming to this package.
属性"T38MaxBitRate"は"T38maxBitRate"として一度不当にIANAに登録されました(小文字の「m」)。 T.38の例と一般的な実現練習、フォーム"T38MaxBitRate"SHOULDに従って、このパッケージに従う実現で発生してください。
In general, it is RECOMMENDED that implementations of this package accept lowercase, uppercase, and mixed upper/lowercase encodings of all the T.38 attributes.
一般に、このパッケージの実現がすべてのT.38属性の小文字の、そして、大文字していて、混ぜられた上側の、または、小文字のencodingsを受け入れるのは、RECOMMENDEDです。
Andreasen & Hancock Informational [Page 18] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[18ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
2.5.3. Boolean Indicator After T.38 Parameters
2.5.3. T.38パラメタの後のブールインディケータ
Some implementations incorrectly use a colon (':') followed by a
number (zero or one) after the attributes T38FaxFillBitRemoval,
T38FaxTranscodingMMR, and T38FaxTranscodingJBIG. Implementations
that receive such erroneous encodings MAY interpret the value ":0" as
lack of support for the option and all other values as support for
the option.
いくつかの実現が不当にコロンを使用する、(':'、)、属性のT38FaxFillBitRemoval、T38FaxTranscodingMMR、およびT38FaxTranscodingJBIGの後の数(ゼロか1)はあとに続いています。 「そのような誤ったencodingsを受ける実現が値を解釈するかもしれない」: オプションのサポートの不足としての0インチとオプションのサポートとしての他のすべての値。
3. Call Flow Examples
3. 例に流れに電話をしてください。
In this section, we provide three example call flows. The first one illustrates a T.38 fax call under Call Agent control on both the originating and terminating side. The second one illustrates the use of multiple and different options on the two sides. The third one illustrates the interaction with a SIP endpoint.
このセクションに、私たちは3回の例の呼び出し流れを供給します。 最初のものは由来していて終わっている側でCallエージェントコントロールの下でT.38ファックス呼び出しを例証します。 2番目のものは2つの側における複数の、そして、異なったオプションの使用を例証します。 3番目のものはSIP終点を相互作用に入れます。
Andreasen & Hancock Informational [Page 19] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[19ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
3.1. Call Agent Controlled T.38 Strict
3.1. エージェントの制御T.38が厳しいと言ってください。
In this example, both sides are under strict T.38 Call Agent control. We assume the originating and terminating Call Agents communicate via the Session Initiation Protocol (SIP) [RFC3261]. Furthermore, the originating fax machine does not generate CNG tone, which is typical of early (i.e., pre-1993) fax machines.
この例には、両側が厳しいT.38 Callエージェントコントロールの下にあります。 私たちは、Session Initiationプロトコル(SIP)[RFC3261]で由来していて終わっているCallエージェントが交信すると思います。 その上、由来しているファックス装置はCNGトーンを発生させません。(それは、前(すなわち、pre-1993)のファックス装置の典型です)。
------------------------------------------------------------------
| #| 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| | | | <- V.21 fax |
| | | | | preamble |
|11| | | <-|NTFY(t38 start)|
|12| | | 200|-> |
|13| | | MDCX(t38)|-> |
|14| | | <-|200(sdp-t2) |
|15| | <-|INVITE(sdp-t2) | |
|16| <-|MDCX(sdp-t2) | | |
|17| 200(sdp-o2)|-> | | |
|18| | 200(sdp-o2)|-> | |
|19| | | MDCX(sdp-o2)|-> |
|20| | | <-|200 |
|21| V.21 fax -> | | | |
| | preamble | | | |
|22|NTFY(t38 start)|-> | | |
|23| <-|200 | | |
|24| <-|RQNT(T38 event)| | |
|25| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
|26| | | | (fax ends) |
|27| | | <-|NTFY(t38 stop) |
|28| | | 200|-> |
|29|NTFY(t38 stop) |-> | | |
|30| <-|200 | | |
------------------------------------------------------------------
------------------------------------------------------------------ | #| GW-o| カリフォルニア-o| カリフォルニア-t| GW-t| |==|===============|===============|===============|===============| | 1| <、-、|CRCX| | | | 2| 200 (sdp-o)|、-、>、|、|、|、| 3| | (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| | | | <。 V.21ファックス| | | | | | 序文| |11| | | <、-、|NTFY(t38始め)| |12| | | 200|、-、>、| |13| | | MDCX(t38)|、-、>、| |14| | | <、-、|200 (sdp-t2)| |15| | <、-、|(sdp-t2)を招待してください。| | |16| <、-、|MDCX(sdp-t2)| | | |17| 200 (sdp-o2)|、-、>、|、|、| |18| | 200 (sdp-o2)|、-、>、|、| |19| | | MDCX(sdp-o2)|、-、>、| |20| | | <、-、|200 | |21| V.21ファックス->。| | | | | | 序文| | | | |22|NTFY(t38始め)|、-、>、|、|、| |23| <、-、|200 | | | |24| <、-、|RQNT(T38出来事)| | | |25| 200|、-、>、|、|、| |--|---------------|---------------|---------------|---------------| |26| | | | (ファックスエンド) | |27| | | <、-、|NTFY(t38停止)| |28| | | 200|、-、>、| |29|NTFY(t38停止)|、-、>、|、|、| |30| <、-、|200 | | | ------------------------------------------------------------------
Andreasen & Hancock Informational [Page 20] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[20ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 1:
ステップ1:
The Call Agent issues a CreateConnection command to the gateway, instructing it to use PCMU media encoding and to use the strict Call Agent controlled T.38 procedure. Consequently, the Call Agent asks the gateway to notify it of the "t38" event:
CallエージェントはCreateConnectionコマンドをゲートウェイに発行して、PCMUメディアコード化を使用して、厳しいCallエージェントを使用するようそれに命令するのがT.38手順を制御しました。 その結果、それに通知してください、Callエージェントが、ゲートウェイに頼む「t38"出来事:」
CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
L: a:PCMU, fxr/fx:t38
M: recvonly
R: fxr/t38
X: 1
CRCX1000 ds/ds1-1/1@gw-o.example.net MGCP1.0C: 1、L: : PCMU、fxr/fx: t38M: recvonly R: fxr/t38X: 1
Step 2:
ステップ2:
The gateway acknowledges the command and includes SDP with codec information and RFC 3407 [RFC3407] capability information:
ゲートウェイは、コーデック情報とRFC3407[RFC3407]能力情報でコマンドを承諾して、SDPを含んでいます:
200 1000 OK
I:1
200 1000は私: 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 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
v=0o=-25678 753849IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=0 0m=オーディオの3456RTP/AVP0a=sqn: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38
Step 3:
ステップ3:
The originating Call Agent sends a SIP INVITE message with the SDP to the terminating Call Agent.
由来しているCallエージェントはSDPがあるSIP INVITEメッセージを終わっているCallエージェントに送ります。
Andreasen & Hancock Informational [Page 21] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[21ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 4:
ステップ4:
The terminating Call Agent issues a CreateConnection command to the terminating gateway, instructing it to use PCMU media encoding and to use the strict Call Agent controlled T.38 procedure. Consequently, the Call Agent asks the gateway to notify it of the "t38" event:
終わっているCallエージェントは終わりゲートウェイにCreateConnectionコマンドを発行して、PCMUメディアコード化を使用して、厳しいCallエージェントを使用するようそれに命令するのがT.38手順を制御しました。 その結果、それに通知してください、Callエージェントが、ゲートウェイに頼む「t38"出来事:」
CRCX 2000 ds/ds1-1/2@gw-t.example.net MGCP 1.0
C: 2
L: a:PCMU, fxr/fx:t38
M: sendrecv
R: fxr/t38
X: 20
CRCX2000 ds/ds1-1/2@gw-t.example.net MGCP1.0C: 2、L: : PCMU、fxr/fx: t38M: sendrecv R: fxr/t38X: 20
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 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
v=0o=-25678 753849IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=0 0m=オーディオの3456RTP/AVP0a=sqn: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージ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 sends back a success response with its SDP, which also includes capability information:
終わりゲートウェイがT.38を支持して、RemoteConnectionDescriptorを含んでいるのが、反対側がまた、T.38を支えるのを示すので、制御手順が要求した厳しいT.38 Callエージェントを使用できます。 終わりゲートウェイはまた、能力情報を含んでいるSDPとの成功応答を返送します:
200 2000 OK
I:2
200 2000は私: 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 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
v=0o=-25678 753849IN IP4 192.0.2.2 s=c=IN IP4 192.0.2.2t=0 0m=オーディオの1296RTP/AVP0a=sqn: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38
Andreasen & Hancock Informational [Page 22] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[22ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
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).
終わっているCallエージェントは由来しているCallエージェントへのSIP ACK(目立たない)が順番に発信するSIP200OK応答を返送します。
Step 7:
ステップ7:
The originating Call Agent in turn sends a ModifyConnection command to the originating gateway:
由来しているCallエージェントは順番にModifyConnectionコマンドを由来しているゲートウェイに送ります:
MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
M: sendrecv
MDCX1001 ds/ds1-1/1@gw-o.example.net MGCP1.0C: 1、私: 1M: 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 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
v=0o=-25678 753849IN IP4 192.0.2.2 s=c=IN IP4 192.0.2.2t=0 0m=オーディオの1296RTP/AVP0a=sqn: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージ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 the other side supports T.38, the gateway will in fact be able to use the strict Call Agent controlled T.38 procedure. Had there not been any support for T.38 in the RemoteConnectionDescriptor, then this command would still have succeeded, however there would be no special fax handling procedure (since strict mode could not be supported).
ModifyConnectionコマンドは以前に送られたLocalConnectionOptionsを繰り返しません。 したがって、ファックス取り扱いに関する限り、ゲートウェイは、現在のファックス取り扱い手順、すなわち、厳しいCallエージェントの制御T.38を使用し続けているのを試みます。 能力情報が事実上、T.38、ゲートウェイが使用できる反対側サポートを示すので、厳しいCallエージェントはT.38手順を制御しました。 RemoteConnectionDescriptorのT.38のサポートが少しのなかったなら、このコマンドはまだ成功しているだろうにて、しかしながら、どんな特別なファックス取り扱い手順もないでしょう(厳しいモードを支持できなかったので)。
Step 8:
ステップ8:
The gateway acknowledges the command. At this point, a call is established using PCMU encoding, and if a fax call is detected, the Call Agent controlled T.38 procedure will be initiated.
ゲートウェイはコマンドを承諾します。 PCMUコード化を使用して、ファックス呼び出しが検出されるなら、ここに呼び出しは確立されます、Callエージェント。制御T.38手順は着手されるでしょう。
Andreasen & Hancock Informational [Page 23] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[23ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Steps 9-11:
ステップ9-11テロ:
A fax call now occurs. The T.30 CED tone (a.k.a. V.25 ANS) is sent -- in this case, it is simply passed through the current PCMU encoding. 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 10, where the V.21 fax preamble is detected.
ファックス呼び出しは現在、起こります。 T.30 CEDトーン(通称V.25 ANS)を送ります--この場合、それは現在のPCMUコード化を単に通り抜けます。 ファックスとモデム呼び出しの両方がこの系列から始まることができるので、これがファックスステップ10、どこまで電話することであるかを決定するために、V.21ファックス序文が検出されるのは、可能ではありません。
The gateway was instructed to apply the Call Agent controlled T.38 procedure for fax calls, so it begins to mute audio, generates the "t38(start)" event, and notifies the Call Agent:
ゲートウェイがファックスのための制御T.38手順が呼ぶCallエージェントを適用するよう命令されて、オーディオに音を消し始めるので、「t38(始める)」出来事を発生させて、Callエージェントに通知します:
NTFY 2500 ds/ds1-1/2@gw-t.example.net MGCP 1.0
O: fxr/t38(start)
X: 20
NTFY2500 ds/ds1-1/2@gw-t.example.net MGCP1.0O: fxr/t38(始める)X: 20
Step 12:
ステップ12:
The Call Agent acknowledges the Notify command:
CallエージェントはNotifyコマンドを承諾します:
200 2500 OK
2500が承認する200
Step 13:
ステップ13:
The Call Agent then instructs the terminating gateway to use the "image/t38" MIME type instead:
次に、Callエージェントが、終わりゲートウェイが使用するよう命令する、「代わりにイメージ/t38"MIMEの種類:」
MDCX 2002 ds/ds1-1/2@gw-t.example.net MGCP 1.0
C: 2
I: 2
L: a:image/t38
R: fxr/t38
X: 21
MDCX2002 ds/ds1-1/2@gw-t.example.net MGCP1.0C: 2、私: 2、L: a: イメージ/t38R: fxr/t38X: 21
Andreasen & Hancock Informational [Page 24] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[24ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 14:
ステップ14:
The gateway changes to T.38 and sends back a success response with updated SDP:
ゲートウェイは、アップデートされたSDPと共にT.38に変化して、成功応答を返送します:
200 2002 OK
2002が承認する200
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 0 18
a=cdsc: 3 image udptl t38
0 0v=0○=-25678 753850IN IP4 192.0.2.2 s=c=IN IP4 192.0.2.2t=mはイメージ1296udptl t38 a=sqnと等しいです: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38
Note that since the gateway's current RemoteConnectionDescriptor (as opposed to the LocalConnectionDescriptor returned here) does not list "image/t38" as a valid encoding method, the terminating gateway is still muting the media and is now waiting for an updated RemoteConnectionDescriptor with "image/t38".
ゲートウェイの現在のRemoteConnectionDescriptor(ここに返されたLocalConnectionDescriptorと対照的に)が記載しないのでそれに注意してください、「有効なコード化方法としてのイメージ/t38"、終わりゲートウェイはまだメディアに音を消していて、現在、「イメージ/t38"」でアップデートされたRemoteConnectionDescriptorを待っています。
Step 15:
ステップ15:
The terminating Call Agent sends a re-INVITE to the originating Call Agent with the updated SDP.
終わっているCallエージェントはアップデートされたSDPの由来しているCallエージェントに再INVITEを送ります。
Step 16:
ステップ16:
The originating Call Agent then sends a ModifyConnection command to the originating gateway:
次に、由来しているCallエージェントはModifyConnectionコマンドを由来しているゲートウェイに送ります:
MDCX 1003 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
MDCX1003 ds/ds1-1/1@gw-o.example.net MGCP1.0C: 1、私: 1
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 0 18
a=cdsc: 3 image udptl t38
0 0v=0○=-25678 753850IN IP4 192.0.2.2 s=c=IN IP4 192.0.2.2t=mはイメージ1296udptl t38 a=sqnと等しいです: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38
Andreasen & Hancock Informational [Page 25] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[25ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 17:
ステップ17:
The originating gateway changes to T.38 and sends back a success response with updated SDP:
由来しているゲートウェイは、アップデートされたSDPと共にT.38に変化して、成功応答を返送します:
200 1003 OK
1003が承認する200
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 0 18
a=cdsc: 3 image udptl t38
0 0v=0○=-25678 753850IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=mはイメージ3456udptl t38 a=sqnと等しいです: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38
Step 18:
ステップ18:
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).
由来しているCallエージェントは終わっているCallエージェントへのアップデートされたSDPとのOK応答をSIP200に送ります。(SIP ACK(目立たない)は順番に、SDPのために発信します)。
Step 19:
ステップ19:
The terminating Call Agent sends a ModifyConnection with the updated SDP to the terminating gateway:
終わっているCallエージェントはアップデートされたSDPとModifyConnectionを終わりゲートウェイに送ります:
MDCX 2003 ds/ds1-1/2@gw-t.example.net MGCP 1.0
C: 2
I: 2
MDCX2003 ds/ds1-1/2@gw-t.example.net MGCP1.0C: 2、私: 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 0 18
a=cdsc: 3 image udptl t38
0 0v=0○=-25678 753850IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=mはイメージ3456udptl t38 a=sqnと等しいです: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38
Andreasen & Hancock Informational [Page 26] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[26ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 20:
ステップ20:
The terminating gateway sends back a success response:
終わりゲートウェイは成功応答を返送します:
200 2003 OK
2003が承認する200
Since the terminating gateway now has a RemoteConnectionDescriptor with "image/t38" as valid media, it can start exchanging T.38 with the originating gateway.
以来、終わりゲートウェイには、現在、「有効なメディアとしてのイメージ/t38"、由来しているゲートウェイとT.38を交換し始めることができること」があるRemoteConnectionDescriptorがあります。
Steps 21, 22:
ステップ21、22:
The originating endpoint detects V.21 fax preamble. Even though the endpoint is already using "image/t38" for media, it generates a "t38(start)" event and notifies the Call Agent.
由来している終点はV.21ファックス序文を検出します。 終点は既に使用することでのそうです。「メディアのために/t38"に像を描いてください、「t38(始める)」出来事を発生させて、Callエージェントに通知します」。
NTFY 3500 ds/ds1-1/1@gw-o.example.net MGCP 1.0
O: fxr/t38(start)
X: 1
NTFY3500 ds/ds1-1/1@gw-o.example.net MGCP1.0O: fxr/t38(始める)X: 1
Steps 23, 24:
ステップ23、24:
The Call Agent acknowledges the Notify command, then issues a new request for notification of the "t38" event.
Callエージェントは、Notifyコマンドを承諾して、次に、「t38"出来事」の通知に関する新しい要求を出します。
200 3500 OK
.
RQNT 1004 ds/ds1-1/1@gw-o.example.net MGCP 1.0
R: fxr/t38
X: 2
200 3500年のOK RQNT1004 ds/ds1-1/1@gw-o.example.net MGCP1.0R: fxr/t38X: 2
Step 25:
ステップ25:
The gateway acknowledges the command.
ゲートウェイはコマンドを承諾します。
200 1004 OK
1004が承認する200
Steps 26, 27:
ステップ26、27:
When the fax ends, a "t38(stop)" event is generated by the terminating endpoint, which is notified to the Call Agent:
ファックスが終わるとき、「t38(止まる)」出来事は終わり終点で発生します:(終点はCallエージェントに通知されます)。
NTFY 2501 ds/ds1-1/2@gw-t.example.net MGCP 1.0
O: t38(stop)
X: 21
NTFY2501 ds/ds1-1/2@gw-t.example.net MGCP1.0O: t38(止まる)X: 21
Andreasen & Hancock Informational [Page 27] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[27ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 28:
ステップ28:
The Call Agent acknowledges the Notify command:
CallエージェントはNotifyコマンドを承諾します:
200 2501 OK
2501が承認する200
Step 29:
ステップ29:
The originating endpoint also generates a "t38(stop)" event, which is notified to the Call Agent:
また、由来している終点は「t38(止まる)」出来事を発生させます:(出来事はCallエージェントに通知されます)。
NTFY 3502 ds/ds1-1/1@gw-o.example.net MGCP 1.0
O: t38(stop)
X: 2
NTFY3502 ds/ds1-1/1@gw-o.example.net MGCP1.0O: t38(止まる)X: 2
Step 30:
ステップ30:
The Call Agent acknowledges the Notify command:
CallエージェントはNotifyコマンドを承諾します:
200 3502 OK
3502が承認する200
The fax call is now over. The Call Agent may now decide to change back to a voice codec, delete the connection, or do something different.
ファックス呼び出しは現在、終わっています。Callエージェントは、現在、音声コーデックに変わって戻るか、接続を削除するか、または何か異なったことをすると決めるかもしれません。
Andreasen & Hancock Informational [Page 28] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[28ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
3.2. Multiple and Different Options
3.2. 複数の、そして、異なったオプション
In this example, the originating gateway is instructed to use the gateway procedure, whereas the terminating gateway is given a choice between the gateway procedure and the strict t38 procedure. Furthermore, the originating fax machine is generating CNG tone.
この例では、ゲートウェイ手順を用いるよう由来しているゲートウェイを命令しますが、ゲートウェイ手順と厳しいt38手順の選択を終わりゲートウェイに与えます。 その上、由来しているファックス装置はCNGトーンを発生させています。
------------------------------------------------------------------
| #| 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| CNG ->| | | |
|10| | | |<- ANS/T.30 CED|
|11| | | |<- V.21 fax |
| | | | | preamble |
|12| | | <-|NTFY(t38 start)|
|13| | | 200|-> |
|14| | | MDCX(t38)|-> |
|15| | | <-|200(sdp-t2) |
|16| | <-|INVITE(sdp-t2) | |
|17| <-|MDCX(sdp-t2) | | |
|18| 200(sdp-o2)|-> | | |
|19| | 200(sdp-o2)|-> | |
|20| | | MDCX(sdp-o2)|-> |
|21| | | <-|200 |
|--|---------------|---------------|---------------|---------------|
|22| | | | (fax ends) |
|23| | | <-|NTFY(t38 stop) |
|24| | | 200|-> |
------------------------------------------------------------------
------------------------------------------------------------------ | #| GW-o| カリフォルニア-o| カリフォルニア-t| GW-t| |==|===============|===============|===============|===============| | 1| <、-、|CRCX| | | | 2| 200 (sdp-o)|、-、>、|、|、|、| 3| | (sdp-o)を招待してください。|、-、>、|、|、| 4| | | CRCX(sdp-o)|、-、>、|、| 5| | | <、-、|200 (sdp-t)| | 6| | <、-、|200 (sdp-t)| | | 7| <、-、|MDCX(sdp-t)| | | | 8| 200|、-、>、|、|、| |--|---------------|---------------|---------------|---------------| | 9| CNG、->|、|、|、| |10| | | | <、- ANS/T.30 CED| |11| | | | <、- V.21ファックス| | | | | | 序文| |12| | | <、-、|NTFY(t38始め)| |13| | | 200|、-、>、| |14| | | MDCX(t38)|、-、>、| |15| | | <、-、|200 (sdp-t2)| |16| | <、-、|(sdp-t2)を招待してください。| | |17| <、-、|MDCX(sdp-t2)| | | |18| 200 (sdp-o2)|、-、>、|、|、| |19| | 200 (sdp-o2)|、-、>、|、| |20| | | MDCX(sdp-o2)|、-、>、| |21| | | <、-、|200 | |--|---------------|---------------|---------------|---------------| |22| | | | (ファックスエンド) | |23| | | <、-、|NTFY(t38停止)| |24| | | 200|、-、>、| ------------------------------------------------------------------
Andreasen & Hancock Informational [Page 29] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[29ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 1:
ステップ1:
The Call Agent issues a CreateConnection command to the gateway, instructing it to use PCMU media encoding and to use the gateway procedure. Consequently, the Call Agent asks the gateway to notify it of the "gwfax" event:
CallエージェントはCreateConnectionコマンドをゲートウェイに発行します、PCMUメディアコード化を使用して、ゲートウェイ手順を用いるようそれに命令して。 その結果、Callエージェントは、"gwfax"出来事についてそれに通知するようにゲートウェイに頼みます:
CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
L: a:PCMU, fxr/fx:gw
M: recvonly
R: fxr/gwfax
X: 1
CRCX1000 ds/ds1-1/1@gw-o.example.net MGCP1.0C: 1、L: : PCMU、fxr/fx: gw M: recvonly R: fxr/gwfax X: 1
Step 2:
ステップ2:
The gateway acknowledges the command and includes SDP with codec information and capability information:
ゲートウェイは、コーデック情報と能力情報でコマンドを承諾して、SDPを含んでいます:
200 1000 OK
I:1
200 1000は私: 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 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
a=X-FaxScheme: 123
v=0o=-25678 753849IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=0 0m=オーディオの3456RTP/AVP0a=sqn: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38 a=X-FaxScheme: 123
We assume the gateway supports some other fax scheme, and it indicates this by including an attribute "X-FaxScheme: 123".
私たちが、ゲートウェイがある他のファックス計画を支持すると思って、属性を含んでいることによってこれを示す、「X-FaxScheme:」 123".
Step 3:
ステップ3:
The originating Call Agent sends a SIP INVITE message with the SDP to the terminating Call Agent.
由来しているCallエージェントはSDPがあるSIP INVITEメッセージを終わっているCallエージェントに送ります。
Andreasen & Hancock Informational [Page 30] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[30ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 4:
ステップ4:
The terminating Call Agent issues a CreateConnection command to the terminating gateway, instructing it to use PCMU media encoding and to use either the gateway procedure or the strict Call Agent controlled T.38 procedure. Consequently, the Call Agent asks the gateway to notify it of both the "gwfax" and "t38" events:
終わっているCallエージェントは終わりゲートウェイにCreateConnectionコマンドを発行して、PCMUメディアコード化を使用して、ゲートウェイ手順か厳しいCallエージェントのどちらかを用いるようそれに命令するのがT.38手順を制御しました。 そして、その結果、Callエージェントが、両方の"gwfax"についてそれに通知するようにゲートウェイに頼む、「t38"出来事:」
CRCX 2000 ds/ds1-1/2@gw-t.example.net MGCP 1.0
C: 2
L: a:PCMU, fxr/fx:gw;t38
M: sendrecv
R: fxr/t38, fxr/gwfax
X: 20
CRCX2000 ds/ds1-1/2@gw-t.example.net MGCP1.0C: 2、L: : PCMU、fxr/fx: gw; t38M: sendrecv R: fxr/t38、fxr/gwfax X: 20
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 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
a=X-FaxScheme: 123
v=0o=-25678 753849IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=0 0m=オーディオの3456RTP/AVP0a=sqn: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38 a=X-FaxScheme: 123
Step 5:
ステップ5:
The terminating gateway does not support any special gateway fax handling; however, it does support 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 honored. The terminating gateway sends back a success response with its SDP, which also includes capability information:
終わりゲートウェイは少しの特別なゲートウェイファックス取り扱いも支持しません。 しかしながら、T.38を支持して、RemoteConnectionDescriptorを含んでいるのが、反対側がまた、T.38を支えるのを示すので、制御手順が要求した厳しいT.38 Callエージェントを尊敬できます。 終わりゲートウェイはまた、能力情報を含んでいるSDPとの成功応答を返送します:
200 2000 OK
I:2
200 2000は私: 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 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
v=0o=-25678 753849IN IP4 192.0.2.2 s=c=IN IP4 192.0.2.2t=0 0m=オーディオの1296RTP/AVP0a=sqn: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38
Andreasen & Hancock Informational [Page 31] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[31ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
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).
終わっているCallエージェントは由来しているCallエージェントへのSIP ACK(目立たない)が順番に発信するSIP200OK応答を返送します。
Step 7:
ステップ7:
The originating Call Agent in turns sends a ModifyConnection command to the originating gateway:
回転における由来しているCallエージェントはModifyConnectionコマンドを由来しているゲートウェイに送ります:
MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
M: sendrecv
MDCX1001 ds/ds1-1/1@gw-o.example.net MGCP1.0C: 1、私: 1M: 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 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
v=0o=-25678 753849IN IP4 192.0.2.2 s=c=IN IP4 192.0.2.2t=0 0m=オーディオの1296RTP/AVP0a=sqn: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージ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, i.e., the gateway procedure. The SDP information returned however does not indicate support for the "X- FaxScheme: 123", and hence the originating gateway will not invoke any special fax handling procedure for this call.
ModifyConnectionコマンドは以前に送られたLocalConnectionOptionsを繰り返しません。 したがって、ファックス取り扱いに関する限り、ゲートウェイは、現在のファックス取り扱い(すなわち、ゲートウェイ手順)を使用し続けているのを試みます。 しかしながら、返されたSDP情報がサポートを示さない、「X FaxScheme:」 「123」、およびしたがって、由来しているゲートウェイは呼び出さないでしょう。この呼び出しのためのあらゆる特別なファックス取り扱い手順を呼び出してください。
Step 8:
ステップ8:
The gateway acknowledges the command. At this point, a call is established using PCMU encoding, and if a fax call is detected, no special fax handling procedure will occur.
ゲートウェイはコマンドを承諾します。 ここに、呼び出しはPCMUコード化を使用するのにおいて確立しています、そして、ファックス呼び出しが検出されると、どんな特別なファックス取り扱い手順も起こらないでしょう。
Andreasen & Hancock Informational [Page 32] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[32ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Steps 9-12:
ステップ9-12:
A CNG tone is generated by the originating fax, thereby indicating a fax call. If the gateway was using either of the T.38 modes, or if it had negotiated support for a special gateway handling procedure with the other side, a "t38(start)" or "gwfax(start)" event would now have been generated and the switch to T.38 (or special gateway handling) could start. However, since the negotiation with the terminating gateway resulted in the originating gateway not doing anything special for fax, no such event is generated. Instead, the "nopfax(start)" event is now generated, but since the Call Agent has not requested this event, it is not detected and hence not reported to the Call Agent. Consequently, the CNG tone is simply passed through the current PCMU encoding without the (originating) Call Agent being aware of the fax call.
CNGトーンは由来しているファックスで発生して、その結果、ファックス呼び出しを示します。 ゲートウェイがT.38モードのどちらかを使用していたなら、特別なゲートウェイ取り扱い手順のサポートを反対側と交渉したなら、「t38(始める)」か「gwfax(始める)」出来事は今発生したでしょうに、そして、T.38(または、特別なゲートウェイ取り扱い)へのスイッチは始動できました。 しかしながら、終わりゲートウェイとの交渉がファックスに、特別なものは何もしない由来しているゲートウェイをもたらしたので、どんなそのような出来事も発生しません。 代わりに、「nopfax(始める)」出来事が現在、発生しますが、Callエージェントがこの出来事を要求していないので、それは、検出されないで、またしたがって、Callエージェントに報告されません。 その結果、CNGトーンは、ファックス呼び出しを意識しているので、現在のPCMUコード化を(由来すること)の呼び出しエージェントなしで単に通り抜けます。
Subsequently, the T.30 CED tone (a.k.a. V.25 ANS) occurs -- in this case, it is also simply passed through the current PCMU encoding. 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 11, where the V.21 fax preamble is detected.
次に、T.30 CEDトーン(通称V.25 ANS)は起こります--また、この場合、それは現在のPCMUコード化を単に通り抜けます。 ファックスとモデム呼び出しの両方がこの系列から始まることができるので、これがファックスステップ11、どこまで電話することであるかを決定するために、V.21ファックス序文が検出されるのは、可能ではありません。
The terminating gateway is using the Call Agent controlled T.38 procedure for fax calls, so it begins to mute audio, generates the "t38(start)" event, and notifies the Call Agent:
終わりゲートウェイがファックスのための制御T.38手順が呼ぶCallエージェントを使用していて、オーディオに音を消し始めるので、「t38(始める)」出来事を発生させて、Callエージェントに通知します:
NTFY 2500 ds/ds1-1/2@gw-t.example.net MGCP 1.0
O: fxr/t38(start)
X: 20
NTFY2500 ds/ds1-1/2@gw-t.example.net MGCP1.0O: fxr/t38(始める)X: 20
Step 13:
ステップ13:
The Call Agent acknowledges the Notify command:
CallエージェントはNotifyコマンドを承諾します:
200 2500 OK
2500が承認する200
Step 14:
ステップ14:
The Call Agent then instructs the terminating gateway to use the "image/t38" MIME type instead:
次に、Callエージェントが、終わりゲートウェイが使用するよう命令する、「代わりにイメージ/t38"MIMEの種類:」
MDCX 2002 ds/ds1-1/2@gw-t.example.net MGCP 1.0
C: 2
I: 2
L: a:image/t38
R: fxr/t38
X: 21
MDCX2002 ds/ds1-1/2@gw-t.example.net MGCP1.0C: 2、私: 2、L: a: イメージ/t38R: fxr/t38X: 21
Andreasen & Hancock Informational [Page 33] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[33ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 15:
ステップ15:
The gateway changes to T.38 and sends back a success response with updated SDP:
ゲートウェイは、アップデートされたSDPと共にT.38に変化して、成功応答を返送します:
200 2002 OK
2002が承認する200
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 0 18
a=cdsc: 3 image udptl t38
0 0v=0○=-25678 753850IN IP4 192.0.2.2 s=c=IN IP4 192.0.2.2t=mはイメージ1296udptl t38 a=sqnと等しいです: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38
Note that since the terminating gateway's last received RemoteConnectionDescriptor (as opposed to the LocalConnectionDescriptor returned here) did not list "image/t38" as a valid encoding method, the terminating gateway is still muting the media and is now waiting for an updated RemoteConnectionDescriptor with "image/t38".
RemoteConnectionDescriptor(ここに返されたLocalConnectionDescriptorと対照的に)が最後に終わりゲートウェイを受信したのでそれが記載しなかったことに注意してください、「有効なコード化方法としてのイメージ/t38"、終わりゲートウェイはまだメディアに音を消していて、現在、「イメージ/t38"」でアップデートされたRemoteConnectionDescriptorを待っています。
Step 16:
ステップ16:
The terminating Call Agent sends a re-INVITE to the originating Call Agent with the updated SDP.
終わっているCallエージェントはアップデートされたSDPの由来しているCallエージェントに再INVITEを送ります。
Step 17:
ステップ17:
The originating Call Agent then sends a ModifyConnection command to the originating gateway:
次に、由来しているCallエージェントはModifyConnectionコマンドを由来しているゲートウェイに送ります:
MDCX 1003 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
MDCX1003 ds/ds1-1/1@gw-o.example.net MGCP1.0C: 1、私: 1
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 0 18
a=cdsc: 3 image udptl t38
0 0v=0○=-25678 753850IN IP4 192.0.2.2 s=c=IN IP4 192.0.2.2t=mはイメージ1296udptl t38 a=sqnと等しいです: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38
Andreasen & Hancock Informational [Page 34] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[34ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 18:
ステップ18:
The originating gateway changes to T.38 and sends back a success response with updated SDP:
由来しているゲートウェイは、アップデートされたSDPと共にT.38に変化して、成功応答を返送します:
200 1003 OK
1003が承認する200
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 0 18
a=cdsc: 3 image udptl t38
0 0v=0○=-25678 753850IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=mはイメージ3456udptl t38 a=sqnと等しいです: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38
Step 19:
ステップ19:
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).
由来しているCallエージェントは終わっているCallエージェントへのアップデートされたSDPとのOK応答をSIP200に送ります。(SIP ACK(目立たない)は順番に、SDPのために発信します)。
Step 20:
ステップ20:
The terminating Call Agent sends a ModifyConnection with the updated SDP to the terminating gateway:
終わっているCallエージェントはアップデートされたSDPとModifyConnectionを終わりゲートウェイに送ります:
MDCX 2003 ds/ds1-1/2@gw-t.example.net MGCP 1.0
C: 2
I: 2
MDCX2003 ds/ds1-1/2@gw-t.example.net MGCP1.0C: 2、私: 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 0 18
a=cdsc: 3 image udptl t38
0 0v=0○=-25678 753850IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=mはイメージ3456udptl t38 a=sqnと等しいです: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38
Andreasen & Hancock Informational [Page 35] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[35ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 21:
ステップ21:
The terminating gateway sends back a success response:
終わりゲートウェイは成功応答を返送します:
200 2003 OK
2003が承認する200
Since the terminating gateway now has a RemoteConnectionDescriptor with "image/t38" as valid media, it can start exchanging T.38 with the originating gateway.
以来、終わりゲートウェイには、現在、「有効なメディアとしてのイメージ/t38"、由来しているゲートウェイとT.38を交換し始めることができること」があるRemoteConnectionDescriptorがあります。
Steps 22, 23:
ステップ22、23:
When the fax ends, a "t38(stop)" event is generated, which is notified to the Call Agent:
ファックスが終わるとき、「t38(止まる)」出来事(Callエージェントに通知される)は発生します:
NTFY 2501 ds/ds1-1/2@gw-t.example.net MGCP 1.0
O: t38(stop)
X: 21
NTFY2501 ds/ds1-1/2@gw-t.example.net MGCP1.0O: t38(止まる)X: 21
Step 24:
ステップ24:
The Call Agent acknowledges the Notify command:
CallエージェントはNotifyコマンドを承諾します:
200 2501 OK
2501が承認する200
The fax call is now over. The Call Agent may now decide to change back to a voice codec, delete the connection, or do something different.
ファックス呼び出しは現在、終わっています。Callエージェントは、現在、音声コーデックに変わって戻るか、接続を削除するか、または何か異なったことをすると決めるかもしれません。
Andreasen & Hancock Informational [Page 36] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[36ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
3.3. Interaction with SIP Endpoints
3.3. 一口終点との相互作用
In this example, we show interaction with a SIP endpoint that does not support the RFC 3407 [RFC3407] capability descriptors. To accommodate such endpoints, the T.38 loose mode is being used (at the risk of initiating T.38 to an endpoint that does not support it). Once again, the originating fax does not generate CNG tone.
この例では、私たちはRFC3407[RFC3407]能力記述子を支持しないSIP終点との相互作用を示しています。 そのような終点を収容するために、T.38のゆるいモードは使用されています(それを支持しない終点にT.38を開始するというリスクで)。 もう一度、由来しているファックスはCNGトーンを発生させません。
------------------------------------------------------------------
| #| GW-o | CA-o | SIP-UA-t | fax |
|==|===============|===============|===============|===============|
| 1| <-|CRCX | | |
| 2| 200(sdp-o)|-> | | |
| 3| | INVITE(sdp-o)|-> | |
| 4| | <-|200(sdp-t) | |
| 5| | ACK|-> | |
| 6| <-|MDCX(sdp-t) | | |
| 7| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
| 8| | | | <- ANS/ |
| | | | | T.30 CED |
| 9| | | | <- V.21 fax |
| | | | | preamble |
|10| | <-|INVITE(sdp-t2) | |
|11| <-|MDCX(sdp-t2) | | |
|12| 200(sdp-o2)|-> | | |
|13| | 200(sdp-o2)|-> | |
|14| | <-|ACK | |
|15| V.21 fax -> | | | |
| | preamble | | | |
|16|NTFY(t38 start)|-> | | |
|17| <-|200 | | |
|18| <-|RQNT(T38 event)| | |
|19| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
|20| | | | (fax ends) |
|21| | <-|BYE | |
|22| | 200|-> | |
|23|NTFY(t38 stop) |-> | | |
|24| <-|200 | | |
------------------------------------------------------------------
------------------------------------------------------------------ | #| GW-o| カリフォルニア-o| 一口UA t| ファックス| |==|===============|===============|===============|===============| | 1| <、-、|CRCX| | | | 2| 200 (sdp-o)|、-、>、|、|、|、| 3| | (sdp-o)を招待してください。|、-、>、|、|、| 4| | <、-、|200 (sdp-t)| | | 5| | ACK|、-、>、|、|、| 6| <、-、|MDCX(sdp-t)| | | | 7| 200|、-、>、|、|、| |--|---------------|---------------|---------------|---------------| | 8| | | | <。 ANS/| | | | | | T.30 CED| | 9| | | | <。 V.21ファックス| | | | | | 序文| |10| | <、-、|(sdp-t2)を招待してください。| | |11| <、-、|MDCX(sdp-t2)| | | |12| 200 (sdp-o2)|、-、>、|、|、| |13| | 200 (sdp-o2)|、-、>、|、| |14| | <、-、|ACK| | |15| V.21ファックス->。| | | | | | 序文| | | | |16|NTFY(t38始め)|、-、>、|、|、| |17| <、-、|200 | | | |18| <、-、|RQNT(T38出来事)| | | |19| 200|、-、>、|、|、| |--|---------------|---------------|---------------|---------------| |20| | | | (ファックスエンド) | |21| | <、-、|さようなら| | |22| | 200|、-、>、|、| |23|NTFY(t38停止)|、-、>、|、|、| |24| <、-、|200 | | | ------------------------------------------------------------------
Andreasen & Hancock Informational [Page 37] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[37ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 1:
ステップ1:
The Call Agent issues a CreateConnection command to the gateway, instructing it to use PCMU media encoding and to use the loose Call Agent controlled T.38 procedure. Consequently, the Call Agent asks the gateway to notify it of the "t38" event:
CallエージェントはCreateConnectionコマンドをゲートウェイに発行して、PCMUメディアコード化を使用して、自由なCallエージェントを使用するようそれに命令するのがT.38手順を制御しました。 その結果、それに通知してください、Callエージェントが、ゲートウェイに頼む「t38"出来事:」
CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
L: a:PCMU, fxr/fx:t38-loose
M: recvonly
R: fxr/t38
X: 1
CRCX1000 ds/ds1-1/1@gw-o.example.net MGCP1.0C: 1、L: : PCMU、fxr/fx: ゆるいt38M: recvonly R: fxr/t38X: 1
Step 2:
ステップ2:
The gateway acknowledges the command and includes SDP with codec information and RFC 3407 [RFC3407] capability information:
ゲートウェイは、コーデック情報とRFC3407[RFC3407]能力情報でコマンドを承諾して、SDPを含んでいます:
200 1000 OK
I:1
200 1000は私: 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 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
v=0o=-25678 753849IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=0 0m=オーディオの3456RTP/AVP0a=sqn: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38
Andreasen & Hancock Informational [Page 38] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[38ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 3:
ステップ3:
The originating SIP User Agent (UA) sends a SIP INVITE message with the SDP to the terminating Call Agent (not all SIP details shown here):
由来しているSIP Userエージェント(UA)は終わっているCallエージェント(ここに示されたというわけではないすべてのSIPの詳細)にSDPがあるSIP INVITEメッセージを送ります:
INVITE sip:bob@biloxi.example.com SIP/2.0
...
Content-Type: application/sdp
Content-Length: 167
INVITEはちびちび飲みます: bob@biloxi.example.com SIP/2.0 コンテントタイプ: sdp Contentアプリケーション/長さ: 167
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 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
v=0o=-25678 753849IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=0 0m=オーディオの3456RTP/AVP0a=sqn: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38
Step 4:
ステップ4:
The terminating SIP User Agent sends back a SIP 200 OK response (not all SIP details shown) to the originating Call Agent:
終わっているSIP Userエージェントは由来しているCallエージェントへのSIP200OK応答(示されたというわけではないすべてのSIPの詳細)を返送します:
SIP/2.0 200 OK
...
Content-Type: application/sdp
Content-Length: 100
一口/2.0 200に、OK… コンテントタイプ: sdp Contentアプリケーション/長さ: 100
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 0
v=0○=-25678 753849IN IP4 192.0.2.2 s=cは0 0t=mのIN IP4 192.0.2.2=オーディオの1296RTP/AVP0と等しいです。
Note that the terminating SIP User Agent does not use the RFC 3407 [RFC3407] capability descriptor to indicate support for (or lack of support for) T.38.
または、終わっているSIP Userエージェントがサポートを示すRFC3407[RFC3407]能力記述子を使用しないことに注意してください、(サポートが欠けている、)、T.38。
Andreasen & Hancock Informational [Page 39] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[39ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 5:
ステップ5:
The originating Call Agent receives the SIP 200 response and sends a SIP ACK message to the terminating SIP UA.
由来しているCallエージェントは、SIP200応答を受けて、SIP ACKメッセージを終わっているSIP UAに送ります。
Note that the Call Agent does not know whether the peer entity supports T.38. In order to figure this out, the Call Agent could send a SIP OPTIONS request to the terminating SIP UA, requesting it to return its capabilities (not shown). Note that this can of course be done towards any SIP peer, e.g., if the other side was a Call Agent speaking SIP it could be done there too.
Callエージェントが、同輩実体がT.38を支持するかどうかを知らないことに注意してください。 これを見積もるために、CallエージェントはSIP OPTIONS要求を終わっているSIP UAに送ることができました、能力(目立たない)を返すようそれに要求して。 もちろんどんなSIP同輩に向かってもこれができることに注意してください、例えば、反対側がまた、そこでそれをできたSIPを話しているCallエージェントであったなら。
Step 6:
ステップ6:
The originating Call Agent in turns sends a ModifyConnection command to the originating gateway:
回転における由来しているCallエージェントはModifyConnectionコマンドを由来しているゲートウェイに送ります:
MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
M: sendrecv
MDCX1001 ds/ds1-1/1@gw-o.example.net MGCP1.0C: 1、私: 1M: 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 0
v=0○=-25678 753849IN IP4 192.0.2.2 s=cは0 0t=mのIN IP4 192.0.2.2=オーディオの1296RTP/AVP0と等しいです。
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., loose Call Agent controlled T.38. The T.38 loose procedure can always be supported, and hence a switch to T.38 will be attempted if the originating gateway detects a fax call.
ModifyConnectionコマンドは以前に送られたLocalConnectionOptionsを繰り返しません。 したがって、ファックス取り扱いに関する限り、ゲートウェイは、現在のファックス取り扱い手順、すなわち、自由なCallエージェントの制御T.38を使用し続けているのを試みます。 いつもT.38のゆるい手順を支持できます、そして、したがって、由来しているゲートウェイがファックス呼び出しを検出すると、T.38へのスイッチは試みられるでしょう。
Step 7:
ステップ7:
The gateway acknowledges the command. At this point, a call is established using PCMU encoding, and if a fax call is detected, the Call Agent controlled T.38 procedure will be initiated.
ゲートウェイはコマンドを承諾します。 PCMUコード化を使用して、ファックス呼び出しが検出されるなら、ここに呼び出しは確立されます、Callエージェント。制御T.38手順は着手されるでしょう。
Andreasen & Hancock Informational [Page 40] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[40ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Steps 8, 9:
ステップ8、9:
A fax call now occurs. The T.30 CED tone (a.k.a. V.25 ANS) is sent--in this case, it is simply passed through the current PCMU encoding. 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 9, where the V.21 fax preamble is detected.
ファックス呼び出しは現在、起こります。 T.30 CEDトーン(通称V.25 ANS)を送ります--この場合、それは現在のPCMUコード化を単に通り抜けます。 ファックスとモデム呼び出しの両方がこの系列から始まることができるので、これがファックスステップ9、どこまで電話することであるかを決定するために、V.21ファックス序文が検出されるのは、可能ではありません。
Step 10:
ステップ10:
The terminating SIP UA does in fact support T.38 and, upon detecting the fax call, attempts to change to T.38. Consequently, it sends a re-INVITE to the originating Call Agent with an updated SDP indicating a switch to T.38.
ファックス呼び出しを検出するとき、終わっているSIP UAは、事実上、T.38を支持して、T.38に変化するのを試みます。 その結果、それはスイッチをT.38に示すアップデートされたSDPの由来しているCallエージェントに再INVITEを送ります。
INVITE sip:ca@ca-o.example.net SIP/2.0
...
Content-Type: application/sdp
Content-Length: 100
INVITEはちびちび飲みます: ca@ca-o.example.net SIP/2.0 コンテントタイプ: sdp Contentアプリケーション/長さ: 100
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
v=0○=-25678 753850IN IP4 192.0.2.2 s=cは0 0t=mのIN IP4 192.0.2.2=イメージ1296udptl t38と等しいです。
Step 11:
ステップ11:
The originating Call Agent then sends a ModifyConnection command to the originating gateway:
次に、由来しているCallエージェントはModifyConnectionコマンドを由来しているゲートウェイに送ります:
MDCX 1003 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
MDCX1003 ds/ds1-1/1@gw-o.example.net MGCP1.0C: 1、私: 1
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
v=0○=-25678 753850IN IP4 192.0.2.2 s=cは0 0t=mのIN IP4 192.0.2.2=イメージ1296udptl t38と等しいです。
Andreasen & Hancock Informational [Page 41] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[41ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 12:
ステップ12:
The originating gateway changes to T.38 and sends back a success response with updated SDP:
由来しているゲートウェイは、アップデートされたSDPと共にT.38に変化して、成功応答を返送します:
200 1003 OK
1003が承認する200
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 0 18
a=cdsc: 3 image udptl t38
0 0v=0○=-25678 753850IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=mはイメージ3456udptl t38 a=sqnと等しいです: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38
Step 13:
ステップ13:
The originating Call Agent sends a SIP 200 OK response with the updated SDP to the terminating SIP User Agent:
由来しているCallエージェントはアップデートされたSDPとのSIP200OK応答を終わっているSIP Userエージェントに送ります:
SIP/2.0 200 OK
...
Content-Type: application/sdp
Content-Length: 167
一口/2.0 200に、OK… コンテントタイプ: sdp Contentアプリケーション/長さ: 167
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 0 18
a=cdsc: 3 image udptl t38
0 0v=0○=-25678 753850IN IP4 192.0.2.1 s=c=IN IP4 192.0.2.1t=mはイメージ3456udptl t38 a=sqnと等しいです: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3イメージudptl t38
Step 14:
ステップ14:
The terminating SIP User Agent receives the SIP 200 and sends a SIP ACK.
終わっているSIP Userエージェントは、SIP200を受け取って、SIP ACKを送ります。
Since the terminating SIP User Agent now has a RemoteConnectionDescriptor with "image/t38" as valid media, it can start exchanging T.38 with the originating gateway (and vice versa).
以来、終わっているSIP Userエージェントは現在、「有効なメディアとしてのイメージ/t38"、由来しているゲートウェイ(逆もまた同様である)とT.38を交換し始めることができること」があるRemoteConnectionDescriptorを持っています。
Andreasen & Hancock Informational [Page 42] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[42ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Steps 15, 16:
ステップ15、16:
The originating endpoint detects V.21 fax preamble. Even though the endpoint is already using "image/t38" for media, it generates a "t38(start)" event and notifies the Call Agent.
由来している終点はV.21ファックス序文を検出します。 終点は既に使用することでのそうです。「メディアのために/t38"に像を描いてください、「t38(始める)」出来事を発生させて、Callエージェントに通知します」。
NTFY 3500 ds/ds1-1/1@gw-o.example.net MGCP 1.0
O: fxr/t38(start)
X: 1
NTFY3500 ds/ds1-1/1@gw-o.example.net MGCP1.0O: fxr/t38(始める)X: 1
Steps 17, 18:
ステップ17、18:
The Call Agent acknowledges the Notify command and issues a new (piggybacked) request for notification of the T38 event.
Callエージェントは、T38出来事の通知のためにNotifyコマンドを承諾して、新しい(背負われる)要求を出します。
200 3500 OK
.
RQNT 1004 ds/ds1-1/1@gw-o.example.net MGCP 1.0
R: fxr/t38
X: 2
200 3500年のOK RQNT1004 ds/ds1-1/1@gw-o.example.net MGCP1.0R: fxr/t38X: 2
Step 19:
ステップ19:
The gateway acknowledges the command.
ゲートウェイはコマンドを承諾します。
200 1004 OK
1004が承認する200
Steps 20-22:
ステップ20-22:
When the fax ends, the terminating SIP UA decides to tear down the call and hence sends a SIP BYE message, which the Call Agent responds to with a SIP 200.
ファックスが終わると、終わっているSIP UAは呼び出しを取りこわすと決めて、したがって、SIP BYEメッセージを送ります。(CallエージェントはSIP200と共にそれに応じます)。
Step 23:
ステップ23:
The originating endpoint also generates a "t38(stop)" event, which is notified to the Call Agent:
また、由来している終点は「t38(止まる)」出来事を発生させます:(出来事はCallエージェントに通知されます)。
NTFY 3502 ds/ds1-1/1@gw-o.example.net MGCP 1.0 O: t38(stop) X: 2
NTFY3502 ds/ds1-1/1@gw-o.example.net MGCP1.0O: t38(止まる)X: 2
Andreasen & Hancock Informational [Page 43] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[43ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Step 24:
ステップ24:
The Call Agent acknowledges the Notify command:
CallエージェントはNotifyコマンドを承諾します:
200 3502 OK
3502が承認する200
The fax call is now over. The Call Agent may now decide to change back to a voice codec, delete the connection, or do something different.
ファックス呼び出しは現在、終わっています。Callエージェントは、現在、音声コーデックに変わって戻るか、接続を削除するか、または何か異なったことをすると決めるかもしれません。
4. Security Considerations
4. セキュリティ問題
The MGCP fax package itself is not known to introduce any new security concerns. However, implementers should note that T.38 media is currently transported over UDP (UDPTL) or TCP in the clear and without any integrity protection. If for example security services are in place to protect RTP media streams, these will thus not be in effect for the T.38 media stream. If such lack of security is a concern, the fax LocalConnectionOptions allowing T.38 in this package SHOULD NOT be used, i.e., the "off" (or a new secure extension) fax LocalConnectionOption should be used.
MGCPファックスパッケージ自体がどんな新しい安全上の配慮も導入するのが知られません。 しかしながら、T.38メディアは注意ですが、implementersは現在UDP(UDPTL)かTCPの上で明確と少しも保全保護なしで輸送されていた状態でそうするべきです。 RTPメディアの流れを保護するために例えばセキュリティー・サービスが適所にあると、その結果、これらはT.38メディアの流れに有効にならないでしょう。 セキュリティのそのような不足が関心であるなら、このパッケージSHOULD NOTにT.38を許容するファックスLocalConnectionOptionsが使用されて、すなわち、“off"(または、新しい安全な拡大)ファックスLocalConnectionOptionは使用されるべきです。
5. IANA Considerations
5. IANA問題
IANA has registered the following MGCP package:
IANAは以下のMGCPパッケージを登録しました:
Package Title Name Version
------------- ---- -------
Fax FXR 0
パッケージタイトル名前バージョン------------- ---- ------- ファックスFXR0
6. Normative References
6. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control
Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[RFC3435] Andreasen、F.、およびB.フォスター、「メディアゲートウェイコントロールは2003年1月にバージョン1インチ、(MGCP)RFC3435について議定書の中で述べます」。
[T38] ITU-T Recommendation T.38, "Procedures for real-time Group
3 facsimile communication over IP networks", March 2002.
[T38]ITU-T Recommendation T.38、「IPネットワークの上のリアルタイムのGroup3ファクシミリ通信のための手順」、2002年3月。
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002.
[RFC3407] Andreasen、F.、「セッションの記述のプロトコルの(SDP)簡単な能力宣言」、RFC3407、2002年10月。
Andreasen & Hancock Informational [Page 44] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[44ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
7. Informative References
7. 有益な参照
[T30] ITU-T Recommendation T.30, "Procedures for document
facsimile transmission in the general switched telephone
network", July 2003.
[T30]ITU-T Recommendation T.30、「一般的な切り換えられた電話網におけるドキュメントファクシミリ伝送のための手順」、2003年7月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC3264] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
Acknowledgements
承認
Several people have contributed to the development of the MGCP fax package. In particular, the author would like to thank Bill Foster, Paul Jones, Gary Kelly, Rajesh Kumar, Dave Horwitz, Hiroshi Tamura, Rob Thompson, and the CableLabs PacketCable NCS focus team for their contributions.
数人はMGCPファックスパッケージの開発に貢献しました。 特に、作者は彼らの貢献についてビル・フォスター、ポールジョーンズ、ギャリー・ケリー、ラジェッシュ・クマー、デーヴ・ホロウィッツ、Hiroshi田村、ロブトンプソン、およびCableLabs PacketCable NCS焦点チームに感謝したがっています。
Authors' Addresses
作者のアドレス
Flemming Andreasen Cisco Systems 499 Thornall Street, 8th Floor Edison, NJ 08837
ニュージャージー フレミングAndreasenシスコシステムズ499Thornall通り、第8Floorエディソン、08837
EMail: fandreas@cisco.com
メール: fandreas@cisco.com
David Hancock CableLabs 858 Coal Creek Circle Louisville, CO 80027
デヴィッドハンコックCableLabs858石炭クリーク円のルイビル、CO 80027
EMail: d.hancock@cablelabs.com
メール: d.hancock@cablelabs.com
Andreasen & Hancock Informational [Page 45] RFC 5347 MGCP Fax Package October 2008
Andreasenとハンコックの情報[45ページ]のRFC5347MGCPはファックスでパッケージ2008年10月を送ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Andreasen & Hancock Informational [Page 46]
Andreasenであって、ハンコック情報です。[46ページ]
一覧
スポンサーリンク
