[要約] RFC 4733は、DTMFダイヤル、電話音、および電話信号のためのRTPペイロードを定義しています。このRFCの目的は、リアルタイム通信プロトコル（RTP）を使用して、音声通信セッションでDTMFダイヤルや電話音を伝送するための標準化を提供することです。
Network Working Group H. Schulzrinne
Request for Comments: 4733 Columbia U.
Obsoletes: 2833 T. Taylor
Category: Standards Track Nortel
December 2006
RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
DTMFディジット、テレフォニートーン、テレフォニーシグナルのRTPペイロード
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
Abstract
概要
This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833.
このメモでは、RTPパケットでデュアルトーンマルチフェーク（DTMF）シグナル、その他のトーン信号、テレフォニーイベントを運ぶ方法について説明します。RFC 2833を廃止します。
This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use.
このメモは、RFC 2833で定義されている基本的なフレームワークをキャプチャおよび拡張しますが、最も基本的なイベントコードのみを保持しています。他のイベントコードの割り当てを追加できるIANAレジストリをセットアップします。コンパニオンドキュメントは、モデム、FAX、テキストテレフォニー、およびチャネル関連のシグナル伝達イベントに関連するこのレジストリにイベントコードを追加します。RFC 2833で定義されているイベントコードの残りの部分は、他の文書が使用を復活させた場合に備えて条件付きで予約されています。
This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events.
このドキュメントは、元のドキュメントにいくつかの説明を提供します。ただし、すべての準拠の実装がDTMFイベントをサポートするという要件を削除することにより、特にRFC 2833とは異なります。代わりに、メディアストリームコンテンツの帯域外交渉に参加する準拠の実装は、彼らがサポートするイベントを示しています。このメモは、RFC 2833フレームワークに3つの新しい手順を追加します。長いイベントのセグメントへの細分化、単一のパケットでの複数のイベントの報告、および州イベントの概念と報告です。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Overview ...................................................4
1.3. Potential Applications .....................................5
1.4. Events, States, Tone Patterns, and Voice-Encoded Tones .....6
2. RTP Payload Format for Named Telephone Events ...................8
2.1. Introduction ...............................................8
2.2. Use of RTP Header Fields ...................................8
2.2.1. Timestamp ...........................................8
2.2.2. Marker Bit ..........................................8
2.3. Payload Format .............................................8
2.3.1. Event Field .........................................9
2.3.2. E ("End") Bit .......................................9
2.3.3. R Bit ...............................................9
2.3.4. Volume Field ........................................9
2.3.5. Duration Field ......................................9
2.4. Optional Media Type Parameters ............................10
2.4.1. Relationship to SDP ................................10
2.5. Procedures ................................................11
2.5.1. Sending Procedures .................................11
2.5.2. Receiving Procedures ...............................16
2.6. Congestion and Performance ................................19
2.6.1. Performance Requirements ...........................20
2.6.2. Reliability Mechanisms .............................20
2.6.3. Adjusting to Congestion ............................22
3. Specification of Event Codes for DTMF Events ...................23
3.1. DTMF Applications .........................................23
3.2. DTMF Events ...............................................25
3.3. Congestion Considerations .................................25
4. RTP Payload Format for Telephony Tones .........................26
4.1. Introduction ..............................................26
4.2. Examples of Common Telephone Tone Signals .................27
4.3. Use of RTP Header Fields ..................................27
4.3.1. Timestamp ..........................................27
4.3.2. Marker Bit .........................................27
4.3.3. Payload Format .....................................28
4.3.4. Optional Media Type Parameters .....................29
4.4. Procedures ................................................29
4.4.1. Sending Procedures .................................29
4.4.2. Receiving Procedures ...............................30
4.4.3. Handling of Congestion .............................30
5. Examples .......................................................31
6. Security Considerations ........................................38
7. IANA Considerations ............................................38
7.1. Media Type Registrations ..................................40
7.1.1. Registration of Media Type audio/telephone-event ...40
7.1.2. Registration of Media Type audio/tone ..............42
8. Acknowledgements ...............................................43
9. References .....................................................43
9.1. Normative References ......................................43
9.2. Informative References ....................................44
Appendix A. Summary of Changes from RFC 2833 ......................46
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"RFC 2119 [1]に記載されているように解釈されるべきです。
This document uses the following abbreviations:
ANSam Answer tone (amplitude modulated) [24]
ANSAM回答トーン（振幅変調）[24]
DTMF Dual-Tone Multifrequency [10]
dtmfデュアルトーン多requency [10]
IVR Interactive Voice Response unit
IVRインタラクティブな音声応答ユニット
PBX Private branch exchange (telephone system)
PBXプライベートブランチエクスチェンジ（電話システム）
PSTN Public Switched (circuit) Telephone Network
PSTN Public Switched（Circuit）電話ネットワーク
RTP Real-time Transport Protocol [5]
RTPリアルタイムトランスポートプロトコル[5]
SDP Session Description Protocol [9]
SDPセッション説明プロトコル[9]
This memo defines two RTP [5] payload formats, one for carrying dual-tone multifrequency (DTMF) digits and other line and trunk signals as events (Section 2), and a second one to describe general multifrequency tones in terms only of their frequency and cadence (Section 4). Separate RTP payload formats for telephony tone signals are desirable since low-rate voice codecs cannot be guaranteed to reproduce these tone signals accurately enough for automatic recognition. In addition, tone properties such as the phase reversals in the ANSam tone will not survive speech coding. Defining separate payload formats also permits higher redundancy while maintaining a low bit rate. Finally, some telephony events such as "on-hook" occur out-of-band and cannot be transmitted as tones.
このメモは、2つのRTP [5]ペイロードフォーマットを定義します。1つはデュアルトーンの多面的（DTMF）数字、およびその他のラインとトランクシグナルをイベント（セクション2）として、もう1つは周波数のみで一般的な多面的なトーンを記述するための2番目のRTPフォーマットを定義します。およびケイデンス（セクション4）。低料金の音声コーデックは、自動認識のためにこれらのトーン信号を正確に再現することを保証できないため、テレフォニートーン信号用の個別のRTPペイロード形式が望ましいです。さらに、ANSAMトーンの位相反転などのトーン特性は、音声コーディングに耐えられません。個別のペイロードフォーマットを定義することで、低いレートを維持しながら、より高い冗長性が可能になります。最後に、「オンフック」などのテレフォニーイベントの一部は、帯域外で発生し、トーンとして送信することはできません。
The remainder of this section provides the motivation for defining the payload types described in this document. Section 2 defines the payload format and associated procedures for use of named events. Section 3 describes the events for which event codes are defined in this document. Section 4 describes the payload format and associated procedures for tone representations. Section 5 provides some examples of encoded events, tones, and combined payloads. Section 6 deals with security considerations. Section 7 defines the IANA requirements for registration of event codes for named telephone events, establishes the initial content of that registry, and provides the media type registrations for the two payload formats. Appendix A describes the changes from RFC 2833 [12] and in particular indicates the disposition of the event codes defined in [12].
このセクションの残りの部分は、このドキュメントで説明されているペイロードタイプを定義する動機を提供します。セクション2では、指定されたイベントを使用するためのペイロード形式と関連する手順を定義します。セクション3では、このドキュメントでイベントコードが定義されているイベントについて説明します。セクション4では、トーン表現のペイロード形式と関連する手順について説明します。セクション5では、エンコードされたイベント、トーン、および組み合わせのペイロードの例を示します。セクション6では、セキュリティ上の考慮事項を扱います。セクション7では、名前付き電話イベントのイベントコードの登録に関するIANA要件を定義し、そのレジストリの初期コンテンツを確立し、2つのペイロード形式のメディアタイプの登録を提供します。付録Aでは、RFC 2833 [12]からの変更について説明し、特に[12]で定義されているイベントコードの処分を示しています。
The payload formats described here may be useful in a number of different scenarios.
ここで説明するペイロード形式は、さまざまなシナリオで役立つ場合があります。
On the sending side, there are two basic possibilities: either the sending side is an end system that originates the signals itself, or it is a gateway with the task of propagating incoming telephone signals into the Internet.
送信側には、2つの基本的な可能性があります。送信側は、信号自体を発信するエンドシステムであるか、インターネットに着信電話信号を伝播するタスクを備えたゲートウェイです。
On the receiving side, there are more possibilities. The first is that the receiver must propagate tone signalling accurately into the PSTN for machine consumption. One example of this is a gateway passing DTMF tones to an IVR. In this scenario, frequencies, amplitudes, tone durations, and the durations of pauses between tones are all significant, and individual tone signals must be delivered reliably and in order.
受信側には、より多くの可能性があります。1つ目は、レシーバーがマシン消費のためにトーン信号をPSTNに正確に伝播する必要があることです。この一例は、DTMFトーンをIVRに通すゲートウェイです。このシナリオでは、周波数、振幅、トーンの持続時間、およびトーン間の一時停止の期間はすべて重要であり、個々のトーン信号を確実に順番に配信する必要があります。
In a second receiving scenario, the receiver must play out tones for human consumption. Typically, rather than a series of tone signals each with its own meaning, the content will consist of a single tone played out continuously or a single sequence of tones and possibly silence, repeated cyclically for some period of time. Often the end of the tone playout will be triggered by an event fed back in the other direction, using either in- or out-of-band means. Examples of this are dial tone or busy tone.
2番目の受信シナリオでは、受信者は人間の消費のためにトーンを再生する必要があります。通常、コンテンツは、一連のトーンがそれぞれ独自の意味を持つものではなく、連続的に再生される単一のトーンまたは単一のトーンと、おそらく沈黙の単一のトーンで構成され、一定期間周期的に繰り返されます。多くの場合、トーンプレイアウトの終わりは、帯域内または帯域外の平均を使用して、反対方向に返されたイベントによってトリガーされます。この例は、ダイヤルトーンまたはビジートーンです。
The relationship between position in the network and the tones to be played out is a complicating factor in this scenario. In the phone network, tones are generated at different places, depending on the switching technology and the nature of the tone. This determines, for example, whether a person making a call to a foreign country hears her local tones she is familiar with or the tones as used in the country called.
ネットワーク内の位置とプレイされるトーンとの関係は、このシナリオの複雑な要因です。電話ネットワークでは、スイッチングテクノロジーとトーンの性質に応じて、異なる場所でトーンが生成されます。これは、たとえば、外国に電話をかけている人が、彼女がよく知っている地元のトーンや、呼ばれる国で使用されているトーンを聞くかどうかを決定します。
For analog lines, dial tone is always generated by the local switch. Integrated Services Digital Network (ISDN) terminals may generate dial tone locally and then send a Q.931 [22] SETUP message containing the dialed digits. If the terminal just sends a SETUP message without any Called Party digits, then the switch does digit collection (provided by the terminal as KEYPAD key press digit information within Called Party or Keypad Facility Information Elements (IEs) of INFORMATION messages), and provides dial tone over the B-channel. The terminal can either use the audio signal on the B-channel or use the Q.931 messages to trigger locally generated dial tone.
アナログラインの場合、ダイヤルトーンは常にローカルスイッチによって生成されます。統合サービスデジタルネットワーク（ISDN）端子は、ダイヤルトーンをローカルで生成し、ダイヤルされた数字を含むQ.931 [22]セットアップメッセージを送信する場合があります。端末が党の数字と呼ばれるセットアップメッセージを送信するだけの場合、スイッチは桁のコレクション（端末によって提供されるキーパッドキープレス桁情報として提供されます。Bチャネルのトーン。端子は、Bチャンネルのオーディオ信号を使用するか、Q.931メッセージを使用して、ローカルに生成されたダイヤルトーンをトリガーすることができます。
Ringing tone (also called ringback tone) is generated by the local switch at the callee, with a one-way voice path opened up as soon as the callee's phone rings. (This reduces the chance of clipping the called party's response just after answer. It also permits pre-answer announcements or in-band call-progress indications to reach the caller before or in lieu of a ringing tone.) Congestion tone and special information tones can be generated by any of the switches along the way, and may be generated by the caller's switch based on ISDN User Part (ISUP) messages received. Busy tone is generated by the caller's switch, triggered by the appropriate ISUP message, for analog instruments, or the ISDN terminal.
リンギングトーン（リングバックトーンとも呼ばれます）は、Calleeのローカルスイッチによって生成され、Calleeの電話が鳴るとすぐに一方向の音声パスが開きます。（これにより、回答の直後に呼び出された党の応答を切り取る可能性が低くなります。また、リンギングトーンの前または代わりに発信者に到達する前の発表またはバンドのコールプログレスの適応症を許可します。）混雑のトーンと特別な情報トーン途中のスイッチのいずれかによって生成され、ISDNユーザーパーツ（ISUP）メッセージに基づいて発信者のスイッチによって生成される場合があります。ビジートーンは、発信者のスイッチによって生成され、適切なISUPメッセージによってトリガーされ、アナログ機器またはISDN端子がトリガーされます。
In the third scenario, an end system is directly connected to the Internet and processes the incoming media stream directly. There is no need to regenerate tone signals, so that time alignment and power levels are not relevant. These systems rely on sending systems to generate events in place of tones and do not perform their own audio waveform analysis. An example of such a system is an Internet interactive voice response (IVR) system.
3番目のシナリオでは、エンドシステムがインターネットに直接接続され、着信メディアストリームを直接処理します。トーン信号を再生する必要はないため、時間の調整とパワーレベルが関連しません。これらのシステムは、トーンの代わりにイベントを生成するためにシステムの送信に依存しており、独自のオーディオ波形分析を実行しません。このようなシステムの例は、インターネットインタラクティブな音声応答（IVR）システムです。
In circumstances where exact timing alignment between the audio stream and the DTMF digits or other events is not important and data is sent unicast, as in the IVR example, it may be preferable to use a reliable control protocol rather than RTP packets. In those circumstances, this payload format would not be used.
オーディオストリームとDTMF桁またはその他のイベントの間の正確なタイミングの調整が重要ではなく、IVRの例のように、RTPパケットではなく信頼できる制御プロトコルを使用することが望ましい場合があります。そのような状況では、このペイロード形式は使用されません。
Note that in a number of these cases it is possible that the gateway or end system will be both a sender and receiver of telephone signals. Sometimes the same class of signals will be sent as received -- in the case of "RTP trunking" or voice-band data, for instance. In other cases, such as that of an end system serving analogue lines, the signals sent will be in a different class from those received.
これらのケースの多くでは、ゲートウェイまたはエンドシステムが電話信号の送信者および受信者の両方になる可能性があることに注意してください。たとえば、「RTPトランキング」またはボイスバンドデータの場合、同じクラスの信号が受信されたとおりに送信される場合があります。他の場合、アナログラインを提供するエンドシステムのような場合、送信される信号は、受信したものとは異なるクラスになります。
This document provides the means for in-band transport over the Internet of two broad classes of signalling information: in-band tones or tone sequences, and signals sent out-of-band in the PSTN. Tone signals can be carried using any of the three methods listed below. Depending on the application, it may be desirable to carry the signalling information in more than one form at once.
このドキュメントは、2つの幅広いクラスのシグナル伝達情報のインターネットを介した帯域内輸送の手段を提供します：帯域内のトーンまたはトーンシーケンス、およびPSTNで帯域外に送られた信号。トーン信号は、以下にリストされている3つの方法のいずれかを使用して実施できます。アプリケーションに応じて、信号情報を一度に複数のフォームに携帯することが望ましい場合があります。
1. The gateway or end system can change to a higher-bandwidth codec such as G.711 [19] when tone signals are to be conveyed. See new ITU-T Recommendation V.152 [26] for a formal treatment of this approach. Alternatively, for fax, text, or modem signals respectively, a specialized transport such as T.38 [23], RFC 4103 [15], or V.150.1 modem relay [25] may be used. Finally, 64 kbit/s channels may be carried transparently using the RFC 4040 Clearmode payload type [14]. These methods are out of scope of the present document, but may be used along with the payload types defined here.
1. ゲートウェイまたはエンドシステムは、トーン信号を伝達する場合、G.711 [19]などの高帯域幅コーデックに変更できます。このアプローチの正式な扱いについては、新しいITU-T推奨V.152 [26]を参照してください。または、それぞれFAX、テキスト、またはモデム信号の場合、T.38 [23]、RFC 4103 [15]、V.150.1モデムリレー[25]などの特殊なトランスポートを使用することができます。最後に、RFC 4040 ClearModeペイロードタイプ[14]を使用して、64のkbit/sチャネルを透過的に運ぶことができます。これらの方法は現在のドキュメントの範囲外ですが、ここに定義されているペイロードタイプとともに使用できます。
2. The sending gateway can simply measure the frequency components of the voice-band signals and transmit this information to the RTP receiver using the tone representation defined in this document (Section 4). In this mode, the gateway makes no attempt to discern the meaning of the tones, but simply distinguishes tones from speech signals. An end system may use the same approach using configured rather than measured frequencies.
2. 送信ゲートウェイは、このドキュメントで定義されているトーン表現を使用して、ボイスバンド信号の周波数コンポーネントを単純に測定し、この情報をRTPレシーバーに送信できます（セクション4）。このモードでは、ゲートウェイはトーンの意味を識別しようとはしませんが、単に音声信号を区別します。ENDシステムは、測定された周波数ではなく構成されたアプローチを使用する場合があります。
All tone signals in use in the PSTN and meant for human consumption are sequences of simple combinations of sine waves, either added or modulated. (However, some modem signals such as the ANSam tone [24] or systems dependent on phase shift keying cannot be conveyed so simply.)
PSTNで使用され、人間の消費を目的としたすべてのトーン信号は、追加または変調された正弦波の単純な組み合わせのシーケンスです。（ただし、ANSAMトーン[24]や位相シフトに依存するシステムなどの一部のモデム信号は、単純に伝えることはできません。）
3. As a third option, a sending gateway can recognize tones such as ringing or busy tone or DTMF digit '0', and transmit a code that identifies them using the telephone-event payload defined in this document (Section 2). The receiver then produces a tone signal or other indication appropriate to the signal. Generally, since the recognition of signals at the sender often depends on their on/off pattern or the sequence of several tones, this recognition can take several seconds. On the other hand, the gateway may have access to the actual signalling information that generates the tones and thus can generate the RTP packet immediately, without the detour through acoustic signals.
3. 3番目のオプションとして、送信ゲートウェイは、リンギングやビジートーンやDTMFディジット '0'などのトーンを認識し、このドキュメントで定義された電話 - イベントペイロードを使用してそれらを識別するコードを送信できます（セクション2）。その後、受信機は、信号に適したトーン信号またはその他の表示を生成します。一般に、送信者での信号の認識は、しばしばそれらのオン/オフパターンまたはいくつかのトーンのシーケンスに依存するため、この認識には数秒かかる場合があります。一方、ゲートウェイは、トーンを生成する実際のシグナル伝達情報にアクセスできるため、音響信号を迂回せずにRTPパケットをすぐに生成できます。
The third option (use of named events) is the only feasible method for transmitting out-of-band PSTN signals as content within RTP sessions.
3番目のオプション（名前付きイベントの使用）は、RTPセッション内のコンテンツとして帯域外PSTN信号を送信するための唯一の実行可能な方法です。
The RTP payload format for named telephone events is designated as "telephone-event", the media type as "audio/telephone-event". In accordance with current practice, this payload format does not have a static payload type number, but uses an RTP payload type number established dynamically and out-of-band. The default clock frequency is 8000 Hz, but the clock frequency can be redefined when assigning the dynamic payload type.
名前付き電話イベントのRTPペイロード形式は、「電話 - イベント」として指定され、メディアタイプは「Audio/Telephone-Ivent」として指定されています。現在のプラクティスに従って、このペイロード形式は静的なペイロードタイプ番号を持っていませんが、動的で帯域外に確立されたRTPペイロードタイプ番号を使用します。デフォルトのクロック周波数は8000 Hzですが、動的なペイロードタイプを割り当てるときにクロック周波数を再定義できます。
Named telephone events are carried as part of the audio stream and MUST use the same sequence number and timestamp base as the regular audio channel to simplify the generation of audio waveforms at a gateway. The named telephone-event payload type can be considered to be a very highly-compressed audio codec and is treated the same as other codecs.
名前の電話イベントはオーディオストリームの一部として運ばれ、同じシーケンス番号とタイムスタンプベースを通常のオーディオチャネルと使用して、ゲートウェイでのオーディオ波形の生成を簡素化する必要があります。指定された電話イベントペイロードタイプは、非常に高度に圧縮されたオーディオコーデックと見なされ、他のコーデックと同じように扱われます。
The event duration described in Section 2.5 begins at the time given by the RTP timestamp. For events that span multiple RTP packets, the RTP timestamp identifies the beginning of the event, i.e., several RTP packets may carry the same timestamp. For long-lasting events that have to be split into segments (see below, Section 2.5.1.3), the timestamp indicates the beginning of the segment.
セクション2.5で説明されているイベント期間は、RTPタイムスタンプによって与えられた時点で始まります。複数のRTPパケットにまたがるイベントの場合、RTPタイムスタンプはイベントの開始を識別します。つまり、いくつかのRTPパケットが同じタイムスタンプを搭載する場合があります。セグメントに分割する必要がある長期的なイベント（以下、セクション2.5.1.3を参照）の場合、タイムスタンプはセグメントの始まりを示しています。
The RTP marker bit indicates the beginning of a new event. For long-lasting events that have to be split into segments (see below, Section 2.5.1.3), only the first segment will have the marker bit set.
RTPマーカービットは、新しいイベントの開始を示します。セグメントに分割する必要がある長期的なイベントの場合（以下、セクション2.5.1.3を参照）、最初のセグメントのみがマーカービットを設定します。
The payload format for named telephone events is shown in Figure 1.
名前付き電話イベントのペイロード形式を図1に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event |E|R| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Payload Format for Named Events
図1：名前付きイベントのペイロード形式
The event field is a number between 0 and 255 identifying a specific telephony event. An IANA registry of event codes for this field has been established (see IANA Considerations, Section 7). The initial content of this registry consists of the events defined in Section 3.
イベントフィールドは、特定のテレフォニーイベントを識別する0〜255の数です。このフィールドのイベントコードのIANAレジストリが確立されました（IANAの考慮事項、セクション7を参照）。このレジストリの初期コンテンツは、セクション3で定義されているイベントで構成されています。
If set to a value of one, the "end" bit indicates that this packet contains the end of the event. For long-lasting events that have to be split into segments (see below, Section 2.5.1.3), only the final packet for the final segment will have the E bit set.
1の値に設定すると、「end」ビットは、このパケットにイベントの終了が含まれていることを示します。セグメントに分割する必要がある長期にわたるイベントの場合（以下、セクション2.5.1.3を参照）、最終セグメントの最終パケットのみがEビットを設定します。
This field is reserved for future use. The sender MUST set it to zero, and the receiver MUST ignore it.
このフィールドは、将来の使用のために予約されています。送信者はそれをゼロに設定する必要があり、レシーバーはそれを無視する必要があります。
For DTMF digits and other events representable as tones, this field describes the power level of the tone, expressed in dBm0 after dropping the sign. Power levels range from 0 to -63 dBm0. Thus, larger values denote lower volume. This value is defined only for events for which the documentation indicates that volume is applicable. For other events, the sender MUST set volume to zero and the receiver MUST ignore the value.
トーンとして表されるDTMFディジットやその他のイベントの場合、このフィールドは、サインをドロップした後にDBM0で表現されるトーンのパワーレベルを説明しています。電力レベルの範囲は0〜 -63 dBM0です。したがって、値が大きいと低い体積が示されます。この値は、ドキュメントがボリュームが適用可能であることを示すイベントに対してのみ定義されます。他のイベントの場合、送信者はボリュームをゼロに設定する必要があり、レシーバーは値を無視する必要があります。
The duration field indicates the duration of the event or segment being reported, in timestamp units, expressed as an unsigned integer in network byte order. For a non-zero value, the event or segment began at the instant identified by the RTP timestamp and has so far lasted as long as indicated by this parameter. The event may or may not have ended. If the event duration exceeds the maximum representable by the duration field, the event is split into several contiguous segments as described below (Section 2.5.1.3).
期間フィールドは、タイムスタンプユニットで、ネットワークバイトの順序で署名されていない整数として表されるイベントまたはセグメントの期間を示します。ゼロ以外の値の場合、イベントまたはセグメントは、RTPタイムスタンプによって識別されたインスタントで始まり、このパラメーターが示す限りこれまで続いています。イベントは終了したかもしれません。イベント期間が期間中に表現可能な最大値を超える場合、以下に説明するように、イベントはいくつかの連続セグメントに分割されます（セクション2.5.1.3）。
The special duration value of zero is reserved to indicate that the event lasts "forever", i.e., is a state and is considered to be effective until updated. A sender MUST NOT transmit a zero duration for events other than those defined as states. The receiver SHOULD ignore an event report with zero duration if the event is not a state.
ゼロの特別な期間値は、イベントが「永遠に」続くことを示すために予約されています。つまり、状態であり、更新されるまで有効であると考えられています。送信者は、状態として定義されているイベント以外のイベントに対してゼロ期間を送信してはなりません。レシーバーは、イベントが状態ではない場合、ゼロ期間のイベントレポートを無視する必要があります。
Events defined as states MAY contain a non-zero duration, indicating that the sender intends to refresh the state before the time duration has elapsed ("soft state").
状態として定義されたイベントには、ゼロ以外の期間が含まれている可能性があり、送信者が期間が経過する前に状態を更新するつもりであることを示しています（「ソフトステート」）。
For a sampling rate of 8000 Hz, the duration field is sufficient to express event durations of up to approximately 8 seconds.
8000 Hzのサンプリングレートの場合、期間フィールドは最大約8秒のイベント期間を表現するのに十分です。
As indicated in the media type registration for named events in Section 7.1.1, the telephone-event media type supports two optional parameters: the "events" parameter and the "rate" parameter.
セクション7.1.1の名前付きイベントのメディアタイプの登録に示されているように、電話 - イベントメディアタイプは、「イベント」パラメーターと「レート」パラメーターの2つのオプションパラメーターをサポートしています。
The "events" parameter lists the events supported by the implementation. Events are listed as one or more comma-separated elements. Each element can be either a single integer providing the value of an event code or an integer followed by a hyphen and a larger integer, presenting a range of consecutive event code values. The list does not have to be sorted. No white space is allowed in the argument. The union of all of the individual event codes and event code ranges designates the complete set of event numbers supported by the implementation.
「イベント」パラメーターには、実装によってサポートされているイベントがリストされています。イベントは、1つ以上のコンマ区切り要素としてリストされています。各要素は、イベントコードの値を提供する単一の整数または整数に続いてハイフンとより大きな整数のいずれかであり、連続したイベントコード値の範囲を提示します。リストをソートする必要はありません。議論には空白は許可されていません。個々のすべてのイベントコードとイベントコード範囲の連合は、実装によってサポートされるイベント番号の完全なセットを指定します。
The "rate" parameter describes the sampling rate, in Hertz, and hence the units for the RTP timestamp and event duration fields. The number is written as an integer. If omitted, the default value is 8000 Hz.
「レート」パラメーターは、HERTZのサンプリングレート、したがってRTPタイムスタンプおよびイベント期間フィールドの単位を記述します。番号は整数として書かれています。省略すると、デフォルト値は8000 Hzです。
The recommended mapping of media type optional parameters to SDP is given in Section 3 of RFC 3555 [6]. The "rate" media type parameter for the named event payload type follows this convention: it is expressed as usual as the <clock rate> component of the a=rtpmap: attribute line.
SDPへのメディアタイプのオプションパラメーターの推奨マッピングは、RFC 3555のセクション3に記載されています[6]。指名されたイベントペイロードタイプの「レート」メディアタイプパラメーターは、この規則に従います。これは、a = rtpmap：属性行の<clockレート>コンポーネントとして通常どおり表現されます。
The "events" media type parameter deviates from the convention suggested in RFC 3555 because it omits the string "events=" before the list of supported events.
「イベント」メディアタイプパラメーターは、サポートされているイベントのリストの前に文字列「イベント=」を省略するため、RFC 3555で提案されたコンベンションから逸脱しています。
a=fmtp:<format> <list of values>
The list of values has the format and meaning described above.
値のリストには、上記の形式と意味があります。
For example, if the payload format uses the payload type number 100, and the implementation can handle the DTMF tones (events 0 through 15) and the dial and ringing tones (assuming as an example that these were defined as events with codes 66 and 70, respectively), it would include the following description in its SDP message:
たとえば、ペイロードフォーマットがペイロードタイプ番号100を使用し、実装がDTMFトーン（イベント0〜15）とダイヤルおよびリンギングトーン（これらがコード66および70のイベントとして定義されていると仮定して、DTMFトーン（イベント0〜15）を処理できる場合、それぞれ）、次の説明にSDPメッセージに含まれます。
m=audio 12346 RTP/AVP 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15,66,70
The following sample media type definition corresponds to the SDP example above:
次のサンプルメディアタイプ定義は、上記のSDP例に対応しています。
audio/telephone-event;events="0-15,66,70";rate="8000"
This section defines the procedures associated with the named event payload type. Additional procedures may be specified in the documentation associated with specific event codes.
このセクションでは、指定されたイベントペイロードタイプに関連付けられた手順を定義します。特定のイベントコードに関連付けられたドキュメントで、追加の手順を指定できます。
Events are usually sent in combination with or alternating with other payload types. Payload negotiation may specify separate event and other payload streams, or it may specify a combined stream that mixes other payload types with events using RFC 2198 [2] redundancy headers. The purpose of using a combined stream may be for debugging or to ease the transition between general audio and events.
イベントは通常、他のペイロードタイプと組み合わせて、または他のペイロードタイプと交互に送信されます。ペイロードネゴシエーションは、個別のイベントやその他のペイロードストリームを指定する場合があります。または、RFC 2198 [2]冗長ヘッダーを使用して、他のペイロードタイプとイベントを組み合わせた複合ストリームを指定する場合があります。組み合わせたストリームを使用する目的は、デバッグすること、または一般的なオーディオとイベントの間の移行を容易にすることです。
Negotiation of payloads between sender and receiver is achieved by out-of-band means, using SDP, for example.
送信者とレシーバー間のペイロードの交渉は、たとえばSDPを使用して、帯域外の手段によって達成されます。
The sender SHOULD indicate what events it supports, using the optional "events" parameter associated with the telephone-event media type. If the sender receives an "events" parameter from the receiver, it MUST restrict the set of events it sends to those listed in the received "events" parameter. For backward compatibility, if no "events" parameter is received, the sender SHOULD assume support for the DTMF events 0-15 but for no other events.
送信者は、電話のイベントメディアタイプに関連付けられたオプションの「イベント」パラメーターを使用して、サポートするイベントを示す必要があります。送信者が受信機から「イベント」パラメーターを受信した場合、受信した「イベント」パラメーターにリストされているイベントに送信されるイベントのセットを制限する必要があります。後方互換性の場合、「イベント」パラメーターが受信されない場合、送信者はDTMFイベント0-15のサポートを引き受ける必要がありますが、他のイベントはありません。
Events MAY be sent in combination with older events using RFC 2198 [2] redundancy. Section 2.5.1.4 describes how this can be used to avoid packet and RTP header overheads when retransmitting final event reports. Section 2.6 discusses the use of additional levels of RFC 2198 redundancy to increase the probability that at least one copy of the report of the end of an event reaches the receiver. The following SDP shows an example of such usage, where G.711 audio appears in a separate stream, and the primary component of the redundant payload is events.
イベントは、RFC 2198 [2]冗長性を使用して、古いイベントと組み合わせて送信できます。セクション2.5.1.4では、最終的なイベントレポートを再送信する際に、パケットとRTPヘッダーのオーバーヘッドを回避するためにこれを使用する方法について説明します。セクション2.6では、RFC 2198冗長性の追加レベルの使用について説明して、イベントの終了のレポートの少なくとも1つのコピーが受信機に届く確率を高めます。次のSDPは、G.711オーディオが別のストリームに表示され、冗長ペイロードの主要なコンポーネントがイベントであるこのような使用の例を示しています。
m=audio 12344 RTP/AVP 99
a=rtpmap:99 pcmu/8000
m=audio 12346 RTP/AVP 100 101
a=rtpmap:100 red/8000/1
a=fmtp:100 101/101/101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
When used in accordance with the offer-answer model (RFC 3264 [4]), the SDP a=ptime: attribute indicates the packetization period that the author of the session description expects when receiving media. This value does not have to be the same in both directions. The appropriate period may vary with the application, since increased packetization periods imply increased end-to-end response times in instances where one end responds to events reported from the other.
オファーアンスワーモデル（RFC 3264 [4]）に従って使用する場合、SDP A = PTIME：属性は、セッション説明の著者がメディアを受信するときに期待するパケット化期間を示します。この値は、両方向で同じである必要はありません。適切な期間はアプリケーションによって異なる場合があります。これは、パケット化期間の増加が、一方の端がもう一方から報告されたイベントに応答する場合に、エンドツーエンドの応答時間の増加を意味するためです。
Negotiation of telephone-events sessions using SDP MAY specify such differences by separating events corresponding to different applications into different streams. In the example below, events 0-15 are DTMF events, which have a fairly wide tolerance on timing. Events 32-49 and 52-60 are events related to data transmission and are subject to end-to-end response time considerations. As a result, they are assigned a smaller packetization period than the DTMF events.
SDPを使用した電話イベントセッションの交渉は、異なるアプリケーションに対応するイベントを異なるストリームに分離することにより、そのような違いを指定する場合があります。以下の例では、イベント0-15はDTMFイベントであり、タイミングにかなり広い耐性があります。イベント32-49および52-60は、データ送信に関連するイベントであり、エンドツーエンドの応答時間の考慮事項の対象となります。その結果、DTMFイベントよりも小さな包装期間が割り当てられます。
m=audio 12344 RTP/AVP 99
a=rtpmap:99 telephone-event/8000
a=fmtp:99 0-15
a=ptime:50
m=audio 12346 RTP/AVP 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 32-49,52-60
a=ptime:30
For further discussion of packetization periods see Section 2.6.3.
パケット化期間の詳細については、セクション2.6.3を参照してください。
DTMF digits and other named telephone events are carried as part of the audio stream, and they MUST use the same sequence number and timestamp base as the regular audio channel to simplify the generation of audio waveforms at a gateway.
DTMFの数字やその他の名前付き電話イベントは、オーディオストリームの一部として運ばれ、ゲートウェイでのオーディオ波形の生成を簡素化するために、通常のオーディオチャネルと同じシーケンス番号とタイムスタンプベースを使用する必要があります。
An audio source SHOULD start transmitting event packets as soon as it recognizes an event and continue to send updates until the event has ended. The update packets MUST have the same RTP timestamp value as the initial packet for the event, but the duration MUST be increased to reflect the total cumulative duration since the beginning of the event.
オーディオソースは、イベントを認識したらすぐにイベントパケットの送信を開始し、イベントが終了するまで更新を送信し続ける必要があります。更新パケットは、イベントの初期パケットと同じRTPタイムスタンプ値を持っている必要がありますが、イベントの開始以来の累積期間を反映するために期間を増やす必要があります。
The first packet for an event MUST have the M bit set. The final packet for an event MUST have the E bit set, but setting of the "E" bit MAY be deferred until the final packet is retransmitted (see Section 2.5.1.4). Intermediate packets for an event MUST NOT have either the M bit or the E bit set.
イベントの最初のパケットには、Mビットセットが必要です。イベントの最終パケットにはeビットセットが必要ですが、最終パケットが再送信されるまで「e」ビットの設定を延期することができます（セクション2.5.1.4を参照）。イベント用の中間パケットは、MビットまたはEビットセットのいずれかを持っていてはなりません。
Sending of a packet with the E bit set is OPTIONAL if the packet reports two events that are defined as mutually exclusive states, or if the final packet for one state is immediately followed by a packet reporting a mutually exclusive state. (For events defined as states, the appearance of a mutually exclusive state implies the end of the previous state.)
eビットセットでパケットを送信することは、相互に排他的な状態として定義されている2つのイベントをパケットが報告する場合、または1つの状態の最終パケットがすぐに相互に排他的な状態を報告するパケットが続く場合にオプションです。（州として定義されたイベントの場合、相互に排他的な状態の外観は、前の状態の終わりを意味します。）
A source has wide latitude as to how often it sends event updates. A natural interval is the spacing between non-event audio packets. (Recall that a single RTP packet can contain multiple audio frames for frame-based codecs and that the packet interval can vary during a session.) Alternatively, a source MAY decide to use a different spacing for event updates, with a value of 50 ms RECOMMENDED.
ソースは、イベントの更新を送信する頻度について幅広い緯度を持っています。自然な間隔は、イベント以外のオーディオパケット間の間隔です。（単一のRTPパケットには、フレームベースのコーデックに複数のオーディオフレームが含まれ、セッション中にパケット間隔が異なる可能性があることを思い出してください。）または、ソースは、50ミリ秒の値でイベントの更新に異なる間隔を使用することを決定する場合があります。おすすめされた。
Timing information is contained in the RTP timestamp, allowing precise recovery of inter-event times. Thus, the sender does not in theory need to maintain precise or consistent time intervals between event packets. However, the sender SHOULD minimize the need for buffering at the receiving end by sending event reports at constant intervals.
タイミング情報はRTPタイムスタンプに含まれており、イベント間時間の正確な回復を可能にします。したがって、送信者は理論的には、イベントパケット間で正確または一貫した時間間隔を維持する必要はありません。ただし、送信者は、一定の間隔でイベントレポートを送信することにより、受信側でのバッファリングの必要性を最小限に抑える必要があります。
DTMF digits and other tone events are sent incrementally to avoid having the receiver wait for the completion of the event. In some cases (for example, data session startup protocols), waiting until the end of a tone before reporting it will cause the session to fail. In other cases, it will simply cause undesirable delays in playout at the receiving end.
DTMFの数字やその他のトーンイベントは、レシーバーがイベントの完了を待つことを避けるために段階的に送信されます。場合によっては（たとえば、データセッションの起動プロトコル）、トーンが終了するまで待ってから報告するとセッションが失敗します。他の場合には、受信側でのプレイアウトに望ましくない遅延を引き起こすだけです。
For robustness, the sender SHOULD retransmit "state" events periodically.
堅牢性のために、送信者は定期的に「状態」イベントを再送信する必要があります。
If an event persists beyond the maximum duration expressible in the duration field (0xFFFF), the sender MUST send a packet reporting this maximum duration but MUST NOT set the E bit in this packet. The sender MUST then begin reporting a new "segment" with the RTP timestamp set to the time at which the previous segment ended and the duration set to the cumulative duration of the new segment. The M bit of the first packet reporting the new segment MUST NOT be set. The sender MUST repeat this procedure as required until the end of the complete event has been reached. The final packet for the complete event MUST have the E bit set (either on initial transmission or on retransmission as described below).
イベントが持続時間を超えて持続している場合（0xFFFF）、送信者はこの最大期間を報告するパケットを送信する必要がありますが、このパケットにEビットを設定してはなりません。その後、送信者は、前のセグメントが終了した時間に設定されたRTPタイムスタンプを使用して、新しい「セグメント」の報告を開始し、期間を新しいセグメントの累積期間に設定する必要があります。新しいセグメントを報告する最初のパケットのmビットを設定してはなりません。送信者は、完全なイベントの終了が到達するまで、必要に応じてこの手順を繰り返す必要があります。完全なイベントの最終パケットには、eビットセットが必要です（以下に説明するように、初期送信または再送信時）。
If events are combined as a redundant payload with another payload type using RFC 2198 [2] redundancy, the above procedure SHALL be applied, but using a maximum duration that ensures that the timestamp offset of the oldest generation of events in an RFC 2198 packet never exceeds 0x3FFF. If the sender is using a constant packetization period, the maximum segment duration can be calculated from the following formula:
イベントがRFC 2198 [2]冗長性を使用して別のペイロードタイプと冗長ペイロードとして組み合わされている場合、上記の手順が適用されますが、RFC 2198パケットのイベントの最古のイベントのタイムスタンプのオフセットを保証する最大期間を使用してください。0x3fffを超えます。送信者が一定のパケット化期間を使用している場合、次の式から最大セグメントの持続時間を計算できます。
maximum duration = 0x3FFF - (R-1)*(packetization period in timestamp units)
最大期間= 0x3fff-（r -1）*（タイムスタンプユニットのパケット化期間）
where R is the highest redundant layer number consisting of event payload.
ここで、Rはイベントペイロードで構成される最高の冗長レイヤー数です。
The RFC 2198 redundancy header timestamp offset value is only 14 bits, compared with the 16 bits in the event payload duration field. Since with other payloads the RTP timestamp typically increments for each new sample, the timestamp offset value becomes limiting on reported event duration. The limit becomes more constraining when older generations of events are also included in the combined payload.
RFC 2198冗長ヘッダータイムスタンプのオフセット値は、イベントペイロード期間フィールドの16ビットと比較して、わずか14ビットです。他のペイロードでは、RTPタイムスタンプは通常、新しいサンプルごとに増分するため、タイムスタンプのオフセット値は報告されたイベント期間に制限されます。古い世代のイベントが複合ペイロードにも含まれている場合、制限はより制約になります。
The final packet for each event and for each segment SHOULD be sent a total of three times at the interval used by the source for updates. This ensures that the duration of the event or segment can be recognized correctly even if an instance of the last packet is lost.
各イベントと各セグメントの最終パケットは、アップデートのためにソースが使用する間隔で合計3回送信する必要があります。これにより、最後のパケットのインスタンスが失われた場合でも、イベントまたはセグメントの期間を正しく認識できるようになります。
A sender MAY use RFC 2198 [2] with up to two levels of redundancy to combine retransmissions with reports of new events, thus saving on header overheads. In this usage, the primary payload is new event reports, while the first and (if necessary) second levels of redundancy report first and second retransmissions of final event reports. Within a session negotiated to allow such usage, packets containing the RFC 2198 payload SHOULD NOT be sent except when both primary and retransmitted reports are to be included. All other packets of the session SHOULD contain only the simple, non-redundant telephone-event payload. Note that the expected proportion of simple versus redundant packets affects the order in which they should be specified on an SDP m= line.
送信者は、最大2つのレベルの冗長性を持つRFC 2198 [2]を使用して、再送信と新しいイベントのレポートを組み合わせて、ヘッダーの張り出しを節約することができます。この使用法では、主要なペイロードは新しいイベントレポートですが、最終イベントレポートの最初と（必要に応じて）冗長性レポートの最初と2番目の再送信の第1レベルと2番目のレポートがあります。このような使用を許可するために交渉されたセッション内で、RFC 2198ペイロードを含むパケットは、プライマリレポートと再送信レポートの両方を含める場合を除き、送信しないでください。セッションの他のすべてのパケットには、単純な非冗長な電話イベントペイロードのみが含まれている必要があります。単純なパケットと冗長パケットの予想的な割合は、SDP M = Lineで指定する必要がある順序に影響することに注意してください。
There is little point in sending initial or interim event reports redundantly because each succeeding packet describes the event fully (except for typically irrelevant variations in volume).
後続の各パケットがイベントを完全に説明しているため、初期または暫定イベントレポートを冗長に送信することにはほとんど意味がありません（通常、無関係なボリュームのバリエーションを除く）。
A sender MAY delay setting the E bit until retransmitting the last packet for a tone, rather than setting the bit on its first transmission. This avoids having to wait to detect whether the tone has indeed ended. Once the sender has set the E bit for a packet, it MUST continue to set the E bit for any further retransmissions of that packet.
送信者は、最初の送信にビットを設定するのではなく、最後のパケットをトーンの再送信するまでEビットの設定を遅らせることができます。これにより、トーンが実際に終了したかどうかを検出するのを待たなければなりません。送信者がパケットのためにEビットを設定したら、そのパケットのさらに再送信のためにEビットを引き続き設定する必要があります。
Multiple named events can be packed into a single RTP packet if and only if the events are consecutive and contiguous, i.e., occur without overlap and without pause between them, and if the last event packed into a packet occurs quickly enough to avoid excessive delays at the receiver.
複数の名前付きイベントは、イベントが連続して連続している場合にのみ、単一のRTPパケットに詰め込むことができます。つまり、それらの間で重複せず、一時停止せずに発生します。受信機。
This approach is similar to having multiple frames of frame-based audio in one RTP packet.
このアプローチは、1つのRTPパケットにフレームベースのオーディオの複数のフレームを持つことに似ています。
The constraint that packed events not overlap implies that events designated as states can be followed in a packet only by other state events that are mutually exclusive to them. The constraint itself is needed so that the beginning time of each event can be calculated at the receiver.
パックされたイベントがオーバーラップしないという制約は、州として指定されたイベントに、それらに相互に排他的な他の州のイベントのみがパケットで追跡できることを意味します。各イベントの開始時間を受信機で計算できるように、制約自体が必要です。
In a packet containing events packed in this way, the RTP timestamp MUST identify the beginning of the first event or segment in the packet. The M bit MUST be set if the packet records the beginning of at least one event. (This will be true except when the packet carries the end of one segment and the beginning of the next segment of the same long-lasting event.) The E bit and duration for each event in the packet MUST be set using the same rules as if that event were the only event contained in the packet.
この方法で詰め込まれたイベントを含むパケットで、RTPタイムスタンプは、パケット内の最初のイベントまたはセグメントの開始を特定する必要があります。パケットが少なくとも1つのイベントの開始を記録する場合は、Mビットを設定する必要があります。（これは、パケットが1つのセグメントの終了と同じ長期にわたるイベントの次のセグメントの開始を運ぶ場合を除きます。）パケット内の各イベントのeビットと持続時間は、同じルールを使用して設定する必要があります。そのイベントがパケットに含まれる唯一のイベントである場合。
The RTP sequence number MUST be incremented by one in each successive RTP packet sent. Incrementing applies to retransmitted as well as initial instances of event reports, to permit the receiver to detect lost packets for RTP Control Protocol (RTCP) receiver reports.
RTPシーケンス番号は、送信される各RTPパケットごとに1つずつ増加する必要があります。インクリメントは、イベントレポートの初期インスタンスと同様に再送信に適用され、受信者がRTPコントロールプロトコル（RTCP）受信者レポートの紛失パケットを検出できるようにします。
Receivers can indicate which named events they can handle, for example, by using the Session Description Protocol (RFC 4566 [9]). SDP descriptions using the event payload MUST contain an fmtp format attribute that lists the event values that the receiver can process.
受信者は、たとえば、セッション説明プロトコル（RFC 4566 [9]）を使用して、どの名前のイベントを処理できるかを示すことができます。イベントペイロードを使用したSDP説明には、受信者が処理できるイベント値をリストするFMTP形式の属性を含める必要があります。
In the gateway scenario, an Internet telephony gateway connecting a packet voice network to the PSTN re-creates the DTMF or other tones and injects them into the PSTN. Since, for example, DTMF digit recognition takes several tens of milliseconds, the first few milliseconds of a digit will arrive as regular audio packets. Thus, careful time and power (volume) alignment between the audio samples and the events is needed to avoid generating spurious digits at the receiver. The receiver may also choose to delay playout of the tones by some small interval after playout of the preceding audio has ended, to ensure that downstream equipment can discriminate the tones properly.
ゲートウェイのシナリオでは、パケット音声ネットワークをPSTNに接続するインターネットテレフォニーゲートウェイがDTMFまたはその他のトーンを再作成し、それらをPSTNに注入します。たとえば、DTMFの桁認識には数十ミリ秒かかるため、数桁の最初の数ミリ秒は通常のオーディオパケットとして到着します。したがって、受信機でスプリアスディジットの生成を避けるために、オーディオサンプルとイベントの間の慎重な時間とパワー（ボリューム）アラインメントが必要です。また、レシーバーは、下流の機器がトーンを適切に区別できるように、前のオーディオの再生アウトが終了した後、少し間隔でトーンの再生を遅らせることを選択できます。
Some implementations send events and encoded audio packets (e.g., PCMU or the codec used for speech signals) for the same time instant for the duration of the event. It is RECOMMENDED that gateways render only the telephone-event payload once it is received, since the audio may contain spurious tones introduced by the audio compression algorithm. However, it is anticipated that these extra tones in general should not interfere with recognition at the far end.
いくつかの実装は、イベントとエンコードされたオーディオパケット（例：PCMUまたは音声信号に使用されるコーデックなど）を同じ時間瞬間に送信します。オーディオには、オーディオ圧縮アルゴリズムによって導入されたスプリアストーンが含まれる可能性があるため、ゲートウェイが受信したら電話とイベントのペイロードのみをレンダリングすることをお勧めします。ただし、一般にこれらの余分なトーンは、遠端での認識を妨げるべきではないと予想されています。
Receiver implementations MAY use different algorithms to create tones, including the two described here. (Note that not all implementations have the need to re-create a tone; some may only care about recognizing the events.) With either algorithm, a receiver may impose a playout delay to provide robustness against packet loss or delay. The tradeoff between playout delay and other factors is discussed further in Section 2.6.3.
レシーバーの実装は、ここで説明する2つを含む、異なるアルゴリズムを使用してトーンを作成する場合があります。（すべての実装がトーンを再作成する必要があるわけではないことに注意してください。イベントの認識のみを気にする人もいます。）いずれかのアルゴリズムでは、受信者がパケットの損失または遅延に対して堅牢性を提供するためにプレイアウト遅延を課す可能性があります。プレイアウト遅延と他の要因の間のトレードオフについては、セクション2.6.3でさらに説明します。
In the first algorithm, the receiver simply places a tone of the given duration in the audio playout buffer at the location indicated by the timestamp. As additional packets are received that extend the same tone, the waveform in the playout buffer is extended accordingly. (Care has to be taken if audio is mixed, i.e., summed, in the playout buffer rather than simply copied.) Thus, if a packet in a tone lasting longer than the packet interarrival time gets lost and the playout delay is short, a gap in the tone may occur.
最初のアルゴリズムでは、受信者は、タイムスタンプが示す場所にあるオーディオプレイアウトバッファーに指定された期間のトーンを配置するだけです。同じトーンを拡張する追加のパケットが受信されると、それに応じてプレイアウトバッファーの波形が拡張されます。（オーディオが混合されている場合、つまり、単にコピーするのではなく、プレイアウトバッファーで合計された場合は注意が必要です。）したがって、パケット間の到着時間よりも長く続くトーンのパケットのパケットが失われ、プレイアウトの遅延が短い場合、トーンのギャップが発生する可能性があります。
Alternatively, the receiver can start a tone and play it until one of the following occurs:
あるいは、レシーバーはトーンを開始し、次のいずれかが発生するまで再生できます。
o it receives a packet with the E bit set;
o Eビットセットでパケットを受け取ります。
o it receives the next tone, distinguished by a different timestamp value (noting that new segments of long-duration events also appear with a new timestamp value);
o 別のタイムスタンプ値で区別される次のトーンを受け取ります（長期イベントの新しいセグメントも新しいタイムスタンプ値で表示されることに注意してください）。
o it receives an alternative non-event media stream (assuming none was being received while the event stream was active); or
o イベント以外の代替メディアストリームを受け取ります（イベントストリームがアクティブになっている間は何も受け取られていないと仮定します）。また
o a given time period elapses.
o 与えられた期間が経過します。
This is more robust against packet loss, but may extend the tone beyond its original duration if all retransmissions of the last packet in an event are lost. Limiting the time period of extending the tone is necessary to avoid that a tone "gets stuck". This algorithm is not a license for senders to set the duration field to zero; it MUST be set to the current duration as described, since this is needed to create accurate events if the first event packet is lost, among other reasons.
これはパケットの損失に対してより堅牢ですが、イベントの最後のパケットのすべての再送信が失われた場合、トーンを元の持続時間を超えて延長する可能性があります。トーンを拡張する期間を制限することは、トーンが「立ち往生する」ことを避けるために必要です。このアルゴリズムは、送信者が期間フィールドをゼロに設定するライセンスではありません。これは、最初のイベントパケットが失われた場合など、正確なイベントを作成するために必要であるため、説明されているように現在の期間に設定する必要があります。
Regardless of the algorithm used, the tone SHOULD NOT be extended by more than three packet interarrival times. A slight extension of tone durations and shortening of pauses is generally harmless.
A receiver SHOULD NOT restart a tone once playout has stopped. It MAY do so if the tone is of a type meant for human consumption or is one for which interruptions will not cause confusion at the receiving device.
プレイアウトが停止したら、レシーバーはトーンを再起動しないでください。トーンが人間の消費を目的としたタイプである場合、または中断が受信デバイスで混乱を引き起こさない場合がそうする場合があります。
If a receiver receives an event packet for an event that it is not currently playing out and the packet does not have the M bit set, earlier packets for that event have evidently been lost. This can be confirmed by gaps in the RTP sequence number. The receiver MAY determine on the basis of retained history and the timestamp and event code of the current packet that it corresponds to an event already played out and lapsed. In that case, further reports for the event MUST be ignored, as indicated in the previous paragraph.
レシーバーが現在再生されていないイベントのイベントパケットを受信し、パケットにMビットセットがない場合、そのイベントの以前のパケットは明らかに失われました。これは、RTPシーケンス番号のギャップによって確認できます。受信者は、保持された履歴と現在のパケットのタイムスタンプとイベントコードに基づいて決定する場合があります。その場合、前の段落に示されているように、イベントのさらなる報告は無視する必要があります。
If, on the other hand, the event has not been played out at all, the receiver MAY attempt to play the event out to the complete duration indicated in the event report. The appropriate behavior will depend on the event type, and requires consideration of the relationship of the event to audio media flows and whether correct event duration is essential to the correct operation of the media session.
一方、イベントがまったくプレイされていない場合、レシーバーはイベントレポートに示されている完全な期間までイベントをプレイしようとする場合があります。適切な動作はイベントタイプに依存し、メディアのフローとのイベントとの関係を考慮し、メディアセッションの正しい操作に正しいイベント期間が不可欠であるかどうかを考慮する必要があります。
A receiver SHOULD NOT rely on a particular event packet spacing, but instead MUST use the event timestamps and durations to determine timing and duration of playout.
受信者は、特定のイベントパケット間隔に依存してはなりませんが、代わりにイベントタイムスタンプと期間を使用して、プレイアウトのタイミングと期間を決定する必要があります。
The receiver MUST calculate jitter for RTCP receiver reports based on all packets with a given timestamp. Note: The jitter value should primarily be used as a means for comparing the reception quality between two users or two time periods, not as an absolute measure.
受信者は、特定のタイムスタンプを持つすべてのパケットに基づいて、RTCPレシーバーレポートのジッターを計算する必要があります。注：ジッター値は、主に、絶対的な尺度としてではなく、2つのユーザーまたは2つの期間間の受信品質を比較するための手段として使用する必要があります。
If a zero volume is indicated for an event for which the volume field is defined, then the receiver MAY reconstruct the volume from the volume of non-event audio or MAY use the nominal value specified by the ITU Recommendation or other document defining the tone. This ensures backwards compatibility with RFC 2833 [12], where the volume field was defined only for DTMF events.
ボリュームフィールドが定義されているイベントにゼロボリュームが示されている場合、レシーバーは、イベントオーディオのボリュームからボリュームを再構築するか、トーンを定義するITU推奨またはその他のドキュメントで指定された名目値を使用する場合があります。これにより、RFC 2833 [12]との逆方向の互換性が保証され、ボリュームフィールドはDTMFイベントでのみ定義されました。
If an event report is received with duration equal to the maximum duration expressible in the duration field (0xFFFF) and the E bit for the report is not set, the event report may mark the end of a segment generated according to the procedures of Section 2.5.1.3. If another report for the same event type is received, the receiver MUST compare the RTP timestamp for the new event with the sum of the RTP timestamp of the previous report plus the duration (0xFFFF). The receiver uses the absence of a gap between the events to detect that it is receiving a single long-duration event.
イベントレポートが、期間フィールド（0xFFFF）で表現可能な最大期間に等しい期間で受信し、レポートのEビットが設定されていない場合、イベントレポートはセクション2.5の手順に従って生成されたセグメントの終了をマークする場合があります。.1.3。同じイベントタイプの別のレポートを受信した場合、受信者は、新しいイベントのRTPタイムスタンプを、前のレポートのRTPタイムスタンプと期間（0xffff）の合計と比較する必要があります。受信者は、イベント間にギャップがないことを使用して、単一の長期イベントを受信していることを検出します。
The total duration of a long-duration event is (obviously) the sum of the durations of the segments used to report it. This is equal to the duration of the final segment (as indicated in the final packet for that segment), plus 0xFFFF multiplied by the number of segments preceding the final segment.
長時間のイベントの合計期間は、（明らかに）それを報告するために使用されるセグメントの期間の合計です。これは、最終セグメントの期間（そのセグメントの最終パケットに示されているように）に加えて、最終セグメントの前のセグメントの数を掛けた0xffffに等しくなります。
If events are combined as a redundant payload with another payload type using RFC 2198 [2] redundancy, segments are generated at intervals of 0x3FFF or less, rather than 0xFFFF, as required by the procedures of Section 2.5.1.3.1 in this case. If a receiver is using the events component of the payload, event duration may be only an approximate indicator of division into segments, but the lack of an E bit and the adjacency of two reports with the same event code are strong indicators in themselves.
イベントがRFC 2198 [2]冗長性を使用して別のペイロードタイプと冗長ペイロードとして組み合わされている場合、セクション2.5.1.3.1の手順で必要に応じて、0xFFFFではなく0x3FFF以下の間隔でセグメントが生成されます。受信者がペイロードのイベントコンポーネントを使用している場合、イベント期間はセグメントへの分割の近似指標にすぎない場合がありますが、Eビットの欠如と同じイベントコードを持つ2つのレポートの隣接は、それ自体が強力な指標です。
The procedures of Section 2.5.1.5 require that if multiple events are reported in the same packet, they are contiguous and non-overlapping. As a result, it is not strictly necessary for the receiver to know the start times of the events following the first one in order to play them out -- it needs only to respect the duration reported for each event. Nevertheless, if knowledge of the start time for a given event after the first one is required, it is equal to the sum of the start time of the preceding event plus the duration of the preceding event.
セクション2.5.1.5の手順では、同じパケットで複数のイベントが報告されている場合、それらは隣接していない、重複していないことが要求されています。その結果、受信者がそれらをプレイするために最初のイベントに続くイベントの開始時間を知ることは厳密に必要ではありません。各イベントについて報告された期間を尊重するだけです。それにもかかわらず、最初のイベントが必要な後に特定のイベントの開始時間の知識が必要な場合、前のイベントの開始時間と前のイベントの期間の合計に等しくなります。
If the duration of a soft state event expires, the receiver SHOULD consider the value of the state to be "unknown" unless otherwise indicated in the event documentation.
ソフト状態イベントの期間が期限切れになった場合、レシーバーは、イベントドキュメントで特に示されない限り、状態の価値を「不明」と見なす必要があります。
Packet transmission through the Internet is marked by occasional periods of congestion lasting on the order of second, during which network delay, jitter, and packet loss are all much higher than they are in between these periods. Reference [28] characterizes this phenomenon. Well-behaved applications are expected, preferably, to reduce their demands on the network during such periods of congestion. At the least, they should not increase their demands. This section explores both application performance and the possibilities for good behavior in the face of congestion.
インターネットを介したパケット送信は、ネットワークの遅延、ジッター、パケットの損失がこれらの期間の間にあるものよりもはるかに高い秒の順序で時折渋滞の期間によってマークされています。参照[28]はこの現象を特徴づけています。このような渋滞の期間中にネットワークに対する要求を減らすことが望ましい場合、行儀の良いアプリケーションが期待されています。少なくとも、彼らは彼らの要求を増やすべきではありません。このセクションでは、輻輳に直面したアプリケーションのパフォーマンスと良好な行動の可能性の両方について説明します。
Typically, an implementation of the telephone-event payload will aim to limit the rate at which each of the following impairments occurs:
通常、電話 - イベントペイロードの実装は、次の各障害が発生するレートを制限することを目的としています。
a. an event encoded at the sender fails to be played out at the receiver, either because the event report is lost or because it arrives after playout of later content has started;
a. 送信者でエンコードされたイベントは、イベントレポートが紛失したか、後のコンテンツの再生が開始された後に到着したため、受信機で展開されません。
b. the start of playout of an event at the receiver is delayed relative to other events or other media operating on the same timestamp base;
b. レシーバーでのイベントのプレイアウトの開始は、同じタイムスタンプベースで動作する他のイベントまたは他のメディアと比較して遅れます。
c. the duration of playout of a given event differs from the correct duration as detected at the sender by more than a given amount;
c. 特定のイベントのプレイアウトの期間は、送信者で特定の金額を超えて検出された正しい期間とは異なります。
d. gaps occur in playout of a given event;
d. ギャップは、特定のイベントのプレイアウトで発生します。
e. end-to-end delay for the media stream exceeds a given value.
e. メディアストリームのエンドツーエンドの遅延は、特定の値を超えています。
The relative importance of these constraints varies between applications.
これらの制約の相対的な重要性は、アプリケーション間で異なります。
To improve reliability, all payload types including telephone-events can use a jitter buffer, i.e., impose a playout delay, at the receiving end. This mechanism addresses the first four requirements listed above, but at the expense of the last one.
信頼性を向上させるために、電話イベントを含むすべてのペイロードタイプは、ジッターバッファーを使用できます。つまり、受信側でプレイアウト遅延を課すことができます。このメカニズムは、上記の最初の4つの要件に対処しますが、最後の要件を犠牲にしています。
The named event procedures provide two complementary redundancy mechanisms to deal with lost packets:
指定されたイベント手順は、失われたパケットに対処するための2つの補完的な冗長機構を提供します。
a. Intra-event updates:
a. イベント内の更新：
Events that last longer than one packetization period (e.g., 50 ms) are updated periodically, so that the receiver can reconstruct the event and its duration if it receives any of the update packets, albeit with delay.
1つのパケット化期間（50ミリ秒など）より長く続くイベントは定期的に更新されるため、レシーバーは、遅延がありますが、更新パケットのいずれかを受け取った場合にイベントとその期間を再構築できます。
During an event, the RTP event payload format provides incremental updates on the event. The error resiliency afforded by this mechanism depends on whether the first or second algorithm in Section 2.5.2.2 is used and on the playout delay at the receiver. For example, if the receiver uses the first algorithm and only places the current duration of tone signal in the playout buffer, for a playout delay of 120 ms and a packetization interval of 50 ms, two packets in a row can get lost without causing a premature end of the tone generated.
イベント中、RTPイベントペイロード形式は、イベントの増分更新を提供します。このメカニズムによって得られるエラーの弾力性は、セクション2.5.2.2の最初のアルゴリズムか2番目のアルゴリズムが使用されているか、レシーバーでのプレイアウト遅延に依存します。たとえば、受信者が最初のアルゴリズムを使用し、現在のトーン信号のみをプレイアウトバッファーに配置する場合、プレイアウト遅延は120ミリ秒と50ミリ秒のパケット化インターバルで、2つのパケットが連続して失われる可能性があります。生成されたトーンの未熟な端。
b. Repeat last event packet:
b. 最後のイベントパケットを繰り返します：
As described in Section 2.5.1.4, the last report for an event is transmitted a total of three times. This mechanism adds robustness to the reporting of the end of an event.
セクション2.5.1.4で説明されているように、イベントの最後のレポートは合計3回送信されます。このメカニズムは、イベントの終了の報告に堅牢性を追加します。
It may be necessary to extend the level of redundancy to achieve requirement a) (in Section 2.6.1) in a specific network environment. Taking the 25-30% loss rate during congestion periods illustrated in [28] as typical, and setting an objective that at least 99% of end-of-event reports will eventually get through to the receiver under these conditions, simple probability calculations indicate that each event completion has to be reported four times. This is one more level of redundancy than required by the basic "Repeat last event packet" algorithm. Of course, the objective is probably unrealistically stringent; it was chosen to make a point.
特定のネットワーク環境で要件a）（セクション2.6.1で）を達成するには、冗長性のレベルを拡張する必要がある場合があります。[28]に示されている混雑期間中に25〜30％の損失率を典型的に示し、これらの条件下で最終的にイベント終末のレポートの少なくとも99％がレシーバーに到達するという目的を設定すると、単純な確率の計算は示されています。各イベントの完了は4回報告する必要があります。これは、基本的な「繰り返し最後のイベントパケット」アルゴリズムで要求されるよりも1つのレベルの冗長性です。もちろん、目標はおそらく非現実的に厳しいものです。それはポイントを作るために選ばれました。
Where Section 2.5.1.4 indicates that it is appropriate to use the RFC 2198 [2] audio redundancy mechanism to carry retransmissions of final event reports, this mechanism MAY also be used to extend the number of final report retransmissions. This is done by using more than two levels of redundancy when necessary. The use of RFC 2198 helps to mitigate the extra bandwidth demands that would be imposed simply by retransmitting final event packets more than three times.
セクション2.5.1.4は、RFC 2198 [2]オーディオ冗長メカニズムを使用して最終的なイベントレポートの再送信を実行することが適切であることを示しています。このメカニズムは、最終レポートの再送信の数を拡張するためにも使用できます。これは、必要に応じて3つ以上のレベルの冗長性を使用することによって行われます。RFC 2198の使用は、最終的なイベントパケットを3回以上再送信するだけで課される追加の帯域幅の要求を軽減するのに役立ちます。
These two redundancy mechanisms clearly address requirement a) in the previous section. They also help meet requirement c), to the extent that the redundant packets arrive before playout of the events they report is due to expire. They are not helpful in meeting the other requirements, although they do not directly cause impairments themselves in the way that a large jitter buffer increases end-to-end delay.
これらの2つの冗長性メカニズムは、a）前のセクションで要件に明確に対処します。また、要件を満たすのに役立ちますc）、冗長なパケットが報告されるイベントのプレイアウトが期限切れになる前に到着する程度まで。彼らは他の要件を満たすのに役立ちませんが、大規模なジッターバッファがエンドツーエンドの遅延を増加させる方法で障害を直接引き起こしません。
The playout algorithm is an additional mechanism for meeting the performance requirements. In particular, using the second algorithm in Section 2.5.2.2 will meet requirement d) of the previous section by preventing gaps in playout, but at the potential cost of increases in duration (requirement c)).
Playoutアルゴリズムは、パフォーマンス要件を満たすための追加のメカニズムです。特に、セクション2.5.2.2の2番目のアルゴリズムを使用すると、プレイアウトのギャップを防ぐことにより、前のセクションの要件d）を満たしますが、期間の増加の潜在的なコスト（要件C））です。
Finally, there is an interaction between the packetization period used by a sender, the playout delay used by the receiver, and the vulnerability of an event flow to packet losses. Assuming packet losses are independent, a shorter packetization interval means that the receiver can use a smaller playout delay to recover from a given number of consecutive packet losses, at any stage of event playout. This improves end-to-end delays in applications where that matters.
最後に、送信者が使用するパケット化期間、レシーバーが使用するプレイアウト遅延、およびパケット損失へのイベントフローの脆弱性との間には相互作用があります。パケットの損失が独立していると仮定すると、パケット化間隔が短くなると、レシーバーがより小さなプレイアウト遅延を使用して、イベントプレイアウトの任意の段階で、特定の数の連続したパケット損失から回復できることを意味します。これにより、それが重要なアプリケーションのエンドツーエンドの遅延が改善されます。
In view of the tradeoffs between the different reliability mechanisms, documentation of specific events SHOULD include a discussion of the appropriate design decisions for the applications of those events. This mandate is repeated in the section on IANA considerations.
さまざまな信頼性メカニズム間のトレードオフを考慮して、特定のイベントのドキュメントには、これらのイベントのアプリケーションに関する適切な設計決定の議論を含める必要があります。この任務は、IANAの考慮事項に関するセクションで繰り返されます。
So far, the discussion has been about meeting performance requirements. However, there is also the question of whether applications of events can adapt to congestion to the point that they reduce their demands on the networks during congestion. In theory this can be done for events by increasing the packetization interval, so that fewer packets are sent per second. This has to be accompanied by an increased playout delay at the receiving end. Coordination between the two ends for this purpose is an interesting issue in itself. If it is done, however, such an action implies a one-time gap or extended playout of an event when the packetization interval is first extended, as well as increased end-to-end delay during the whole period of increased playout delay.
これまでのところ、議論はパフォーマンス要件を満たすことについてでした。ただし、イベントのアプリケーションが混雑に適応できるかどうかという問題もあります。理論的には、これはパケット化間隔を増やすことでイベントで実行できます。そのため、1秒あたりの送信されるパケットが少なくなります。これには、受信側でのプレイアウト遅延の増加を伴う必要があります。この目的のための両端間の調整は、それ自体が興味深い問題です。しかし、それが行われた場合、そのようなアクションは、パケット化間隔が最初に拡張されたときにイベントの1回限りのギャップまたは延長されたプレイアウトを意味し、プレイアウト遅延の全期間中にエンドツーエンドの遅延が増加します。
The benefit from such a measure varies primarily depending on the average duration of the events being handled. In the worst case, as a first example shows, the reduction in aggregate bandwidth usage due to an increased packetization interval may be quite modest. Suppose the average event duration is 3.33 ms (V.21 bits, for instance). Suppose further that four transmissions in total are required for a given event report to meet the loss objective. Table 1 shows the impact of varying packetization intervals on the aggregate bit rate of the media stream.
このような尺度の利点は、主に処理されるイベントの平均期間によって異なります。最悪の場合、最初の例が示すように、包装間隔の増加による帯域幅の使用量の減少は非常に控えめかもしれません。平均イベント期間が3.33ミリ秒（たとえば、v.21ビット）であるとします。さらに、損失の目的を満たすために特定のイベントレポートに合計4つの送信が必要であると仮定します。表1は、メディアストリームの集約ビットレートに対するさまざまなパケット化間隔の影響を示しています。
+--------------------+-----------+---------------+------------------+
| Packetization | Packets/s | IP Packet | Total IP Bit |
| Interval (ms) | | Size (bits) | Rate (bits/s) |
+--------------------+-----------+---------------+------------------+
| 50 | 20 | 2440 | 48800 |
| 33.3 | 30 | 1800 | 54000 |
| 25 | 40 | 1480 | 59200 |
| 20 | 50 | 1288 | 64400 |
+--------------------+-----------+---------------+------------------+
Table 1: Data Rate at the IP Level versus Packetization Interval (three retransmissions, 3.33 ms per event)
表1：IPレベルとパケット化間隔でのデータレート（3回の再送信、イベントあたり3.33ミリ秒）
As can be seen, a doubling of the interval (from 25 to 50 ms) drops aggregate bit rate by about 20% while increasing end-to-end delay by 25 ms and causing a one-time gap of the same amount. (Extending the playout of a specific V.21 tone event is out of the question, so the first algorithm of Section 2.5.2.2 must be used in this application.) The reduction in number of packets per second with longer packetization periods is countered by the increase in packet size due to the increase in number of events per packet.
ご覧のとおり、間隔の2倍（25〜50ミリ秒）は、エンドツーエンドの遅延を25ミリ秒増やし、同じ量の1回限りのギャップを引き起こしながら、ビットレートを約20％低下させます。（特定のv.21トーンイベントの再生アウトを拡張することは問題外であるため、セクション2.5.2.2の最初のアルゴリズムをこのアプリケーションで使用する必要があります。）長いパケット化期間の1秒あたりのパケット数の減少は、パケットあたりのイベント数の増加によるパケットサイズの増加。
For events of longer duration, the reduction in bandwidth is more proportional to the increase in packetization interval. The loss of final event reports may also be less critical, so that lower redundancy levels are acceptable. Table 2 shows similar data to Table 1, but assuming 70-ms events separated by 50 ms of silence (as in an idealized DTMF-based text messaging session) with only the basic two retransmissions for event completions.
より長い期間のイベントの場合、帯域幅の減少は包装間隔の増加に比例します。最終的なイベントレポートの損失もそれほど重要ではないため、冗長レベルの低下は許容されます。表2は、表1と同様のデータを示していますが、イベント完了の基本的な2つの再送信のみを使用して、50ミリ秒の沈黙（理想化されたDTMFベースのテキストメッセージングセッションのように）で区切られた70 msのイベントを想定しています。
+--------------------+-----------+---------------+------------------+
| Packetization | Packets/s | IP Packet | Total IP Bit |
| Interval (ms) | | Size (bits) | Rate (bits/s) |
+--------------------+-----------+---------------+------------------+
| 50 | 20 | 448/520 | 10040 |
| 33.3 | 30 | 448/520 | 14280 |
| 25 | 40 | 448/520 | 18520 |
| 20 | 50 | 448 | 22400 |
+--------------------+-----------+---------------+------------------+
Table 2: Data Rate at the IP Level versus Packetization Interval (two retransmissions, 70 ms per event, 50 ms between events)
表2：IPレベルとパケット化間隔でのデータレート（2回の再送信、イベントあたり70ミリ秒、イベント間で50ミリ秒）
In the third column of the table, the packet size is 448 bits when only one event is being reported and 520 bits when the previous event is also included. No more than one level of redundancy is needed up to a packetization interval of 50 ms, although at that point most packets are reporting two events. Longer intervals require a second level of redundancy in at least some packets.
テーブルの3番目の列では、1つのイベントのみが報告されている場合は448ビットと、前のイベントも含まれている場合は520ビットです。その時点では、ほとんどのパケットが2つのイベントを報告していますが、50ミリ秒のパケット化間隔までは1レベルの冗長性が必要です。より長い間隔では、少なくとも一部のパケットで2番目のレベルの冗長性が必要です。
This document defines one class of named events: DTMF tones.
このドキュメントでは、名前付きイベントの1つのクラスであるDTMFトーンを定義しています。
DTMF signalling [10] is typically generated by a telephone set or possibly by a PBX (Private branch telephone exchange). DTMF digits may be consumed by entities such as gateways or application servers in the IP network, or by entities such as telephone switches or IVRs in the circuit switched network.
DTMFシグナル伝達[10]は、通常、電話セットまたは場合によってはPBX（プライベートブランチの電話交換）によって生成されます。DTMF桁は、IPネットワーク内のゲートウェイやアプリケーションサーバーなどのエンティティ、または回路スイッチネットワークの電話スイッチやIVRなどのエンティティによって消費される場合があります。
The DTMF events support two possible applications at the sending end:
DTMFイベントは、送信先で2つの可能なアプリケーションをサポートしています。
1. The Internet telephony gateway detects DTMF on the incoming circuits and sends the RTP payload described here instead of regular audio packets. The gateway likely has the necessary digital signal processors and algorithms, as it often needs to detect DTMF, e.g., for two-stage dialing. Having the gateway detect tones relieves the receiving Internet end system from having to do this work and also avoids having low bit-rate codecs like G.723.1 [20] render DTMF tones unintelligible.
1. インターネットテレフォニーゲートウェイは、着信回路でDTMFを検出し、通常のオーディオパケットではなく、ここで説明するRTPペイロードを送信します。ゲートウェイには、2段階のダイヤルの場合、DTMFを検出する必要があることが多いため、必要なデジタル信号プロセッサとアルゴリズムがある可能性があります。ゲートウェイの検出トーンを持つことにより、受信インターネットエンドシステムがこの作業を行わなければならないことを軽減し、G.723.1 [20]レンダリングDTMFトーンのようなビットレートコーデックが低くなることも避けます。
2. An Internet end system such as an "Internet phone" can emulate DTMF functionality without concerning itself with generating precise tone pairs and without imposing the burden of tone recognition on the receiver.
2. 「インターネット電話」などのインターネットエンドシステムは、正確なトーンペアを生成することとそれ自体を考慮せずにDTMF機能をエミュレートし、レシーバーにトーン認識の負担を課すことなくエミュレートできます。
A similar distinction occurs at the receiving end.
受信側でも同様の区別が発生します。
1. In the gateway scenario, an Internet telephony gateway connecting a packet voice network to the PSTN re-creates the DTMF tones or other telephony events and injects them into the PSTN.
1. ゲートウェイのシナリオでは、パケット音声ネットワークをPSTNに接続するインターネットテレフォニーゲートウェイがDTMFトーンまたはその他のテレフォニーイベントを再作成し、それらをPSTNに注入します。
2. In the end system scenario, the DTMF events are consumed by the receiving entity itself.
2. 最終システムのシナリオでは、DTMFイベントは受信エンティティ自体によって消費されます。
In the most common application, DTMF tones are sent in one direction only, typically from the calling end. The consuming device is most commonly an IVR. DTMF may alternate with voice from either end. In most cases, the only constraint on tone duration is that it exceed a minimum value. However, in some cases a long-duration tone (in excess of 1-2 seconds) has special significance.
最も一般的なアプリケーションでは、DTMFトーンは、通常は呼び出し端から一方向にのみ送信されます。消費デバイスは最も一般的にIVRです。DTMFは、両端からの音声と交互になる場合があります。ほとんどの場合、トーン期間の唯一の制約は、最小値を超えることです。ただし、場合によっては、長期的なトーン（1〜2秒を超える）には特に重要です。
ITU-T Recommendation Q.24 [11], Table A-1, indicates that the legacy switching equipment in the countries surveyed expects a minimum recognizable signal duration of 40 ms, a minimum pause between signals of 40 ms, and a maximum signalling rate of 8 to 10 digits per second depending on the country. Human-generated DTMF signals, of course, are generally longer with larger pauses between them.
ITU-Tの推奨Q.24 [11]、表A-1は、調査対象国のレガシースイッチング装置が、40ミリ秒の最小認識信号期間、40 msの信号間の最低一時停止、最大シグナル伝達率を期待していることを示しています。国に応じて8〜10桁あたり。もちろん、ヒトで生成されたDTMF信号は、一般に、それらの間に大きな一時停止があり、より長くなります。
DTMF tones may also be used for text telephony. This application is documented in ITU-T Recommendation V.18 [27] Annex B. In this case, DTMF is sent alternately from either end (half-duplex mode), with a minimum 300-ms turn-around time. The only constraints on tone durations in this application are that they and the pauses between them must exceed specified minimum values. It is RECOMMENDED that a gateway at the sending end be capable of detecting DTMF signals as specified by V.18 Annex B (tones and pauses >=40 ms), but should send event durations corresponding to those of a V.18 DTMF sender (tones >=70 ms, pauses >=50 ms). This may occasionally imply some degree of buffering of outgoing events, but if the source terminal conforms to V.18 Annex B, this should not get out of hand.
DTMFトーンは、テキストテレフォニーにも使用できます。このアプリケーションは、ITU-Tの推奨V.18 [27] Annex Bで文書化されています。この場合、DTMFはどちらの端（半分二重モード）から交互に送信され、最低300 msのターンアラウンド時間があります。このアプリケーションのトーン期間の唯一の制約は、それらとそれらの間の一時停止が指定された最小値を超えなければならないことです。送信端のゲートウェイは、v.18付録B（トーンとポーズ> = 40ミリ秒）で指定されているDTMF信号を検出できることをお勧めしますが、v.18 dtmf送信者に対応するイベント期間（トーン> = 70ミリ秒、一時停止> = 50ミリ秒）。これは、発信イベントのある程度のバッファリングを暗示することがありますが、ソース端子がv.18付録Bに準拠している場合、これは手に負えなくなるはずです。
Since minor increases in tone duration are harmless for all applications of DTMF, but unintended breaks in playout of a DTMF digit can confuse the receiving endpoint by creating the appearance of extra digits, receiving applications that are converting DTMF events back to tones SHOULD use the second playout algorithm rather than the first one in Section 2.5.2.2. This provides some robustness against packet loss or congestion.
トーン期間のわずかな増加はDTMFのすべてのアプリケーションで無害であるため、DTMF桁のプレイアウトの意図しない休憩は、余分な数字の外観を作成することで受信エンドポイントを混乱させる可能性があり、DTMFイベントをトーンに変換しているアプリケーションを受信すると、2番目のアプリケーションが使用されるはずです。セクション2.5.2.2の最初のアルゴリズムではなく、プレイアウトアルゴリズム。これにより、パケットの喪失または混雑に対する堅牢性が提供されます。
Table 3 shows the DTMF-related event codes within the telephone-event payload format. The DTMF digits 0-9 and * and # are commonly supported. DTMF digits A through D are less frequently encountered, typically in special applications such as military networks.
表3は、電話とイベントのペイロード形式内のDTMF関連のイベントコードを示しています。DTMF数字0-9および *および＃は一般的にサポートされています。DTMF桁aからDは、通常、軍事ネットワークなどの特別なアプリケーションでは、頻繁に発生します。
+-------+--------+------+---------+
| Event | Code | Type | Volume? |
+-------+--------+------+---------+
| 0--9 | 0--9 | tone | yes |
| * | 10 | tone | yes |
| # | 11 | tone | yes |
| A--D | 12--15 | tone | yes |
+-------+--------+------+---------+
Table 3: DTMF Named Events
表3：DTMFという名前のイベント
The key considerations for the delivery of DTMF events are reliability and avoidance of unintended breaks within the playout of a given tone. End-to-end round-trip delay is not a major consideration except in the special case where DTMF tones are being used for text telephony. Assuming that, as recommended in Section 3.1 above, the second playout algorithm of Section 2.5.2.2 is in use, a temporary increase in packetization interval to as much as 100 ms or double the normal interval, whichever is less, should be harmless.
DTMFイベントの配信に関する重要な考慮事項は、信頼性と、特定のトーンのプレイアウト内での意図しない休憩の回避です。エンドツーエンドの往復遅延は、テキストテレフォニーにDTMFトーンが使用されている特別なケースを除いて、大きな考慮事項ではありません。上記のセクション3.1で推奨されているように、セクション2.5.2.2の2番目のプレイアウトアルゴリズムが使用されていると仮定すると、パケット化間隔の一時的な増加が100 msまたは2倍の通常の間隔を2倍にする必要があります。
As an alternative to describing tones and events by name, as described in Section 2, it is sometimes preferable to describe them by their waveform properties. In particular, recognition is faster than for naming signals since it does not depend on recognizing durations or pauses.
セクション2で説明されているように、名前でトーンとイベントを説明する代わりに、波形特性でそれらを記述することが望ましい場合があります。特に、認識は期間や一時停止の認識に依存しないため、信号の命名よりも速いです。
There is no single international standard for telephone tones such as dial tone, ringing (ringback), busy, congestion ("fast-busy"), special announcement tones, or some of the other special tones, such as payphone recognition, call waiting or record tone. However, ITU-T Recommendation E.180 [18] notes that across all countries, these tones share a number of characteristics:
ダイヤルトーン、リンギング（リングバック）、忙しい、輻輳（「速い忙しい」）、特別な発表トーン、またはペイフォン認識、コール待機、または待機待機などのその他の特別なトーンなどの電話トーンには、単一の国際標準はありません。レコードトーン。ただし、ITU-Tの推奨e.180 [18]は、すべての国で、これらのトーンが多くの特性を共有していることに注意してください。
o Telephony tones consist of either a single tone, the addition of two or three tones or the modulation of two tones. (Almost all tones use two frequencies; only the Hungarian "special dial tone" has three.) Tones that are mixed have the same amplitude and do not decay.
o テレフォニートーンは、単一のトーン、2つまたは3つのトーンの追加、または2つのトーンの変調で構成されています。（ほとんどすべてのトーンは2つの周波数を使用します。ハンガリーの「特別なダイヤルトーン」のみが3つあります。）混合されたトーンは同じ振幅を持ち、崩壊しません。
o In-band tones for telephony events are in the range of 25 Hz (ringing tone in Angola) to 2600 Hz (the tone used for line signalling in SS No. 5 and R1). The in-band telephone frequency range is limited to 3400 Hz. R2 defines a 3825 Hz out-of-band tone for line signalling on analogue trunks. (The piano has a range from 27.5 to 4186 Hz.)
o テレフォニーイベントのバンドイントーンは、25 Hz（アンゴラのリンギングトーン）から2600 Hz（SS No. 5およびR1のラインシグナル伝達に使用されるトーン）の範囲です。バンド内の電話頻度範囲は3400 Hzに制限されています。R2は、アナログトランクでのラインシグナル伝達のために3825 Hzバンド外のトーンを定義します。（ピアノの範囲は27.5〜4186 Hzです。）
o Modulation frequencies range between 15 (ANSam tone) to 480 Hz (Jamaica). Non-integer frequencies are used only for frequencies of 16 2/3 and 33 1/3 Hz.
o 変調頻度は、15（ANSAMトーン）から480 Hz（ジャマイカ）の範囲です。非整数周波数は、16 2/3および33 1/3 Hzの周波数にのみ使用されます。
o Tones that are not continuous have durations of less than four seconds.
o 連続していないトーンには、4秒未満の期間があります。
o ITU Recommendation E.180 [18] notes that different telephone companies require a tone accuracy of between 0.5 and 1.5%. The Recommendation suggests a frequency tolerance of 1%.
o ITUの推奨e.180 [18]は、異なる電話会社には0.5〜1.5％のトーンの精度が必要であることに注意しています。推奨事項は、1％の周波数許容度を示唆しています。
As an aid to the implementor, Table 4 summarizes some common tones. The rows labeled "ITU ..." refer to ITU-T Recommendation E.180 [18]. In these rows, the on and off durations are suggested ranges within which local standards would set specific values. The symbol "+" in the table indicates addition of the tones, without modulation, while "*" indicates amplitude modulation.
実装者への援助として、表4はいくつかの一般的なトーンをまとめたものです。「itu ...」というラベルの付いた行は、ITU-Tの推奨事項E.180 [18]を参照しています。これらの行では、現地標準が特定の値を設定する範囲が示唆されています。テーブルのシンボル「」は、変調なしでトーンの追加を示し、「*」は振幅変調を示します。
+-------------------------+-------------------+----------+----------+
| Tone Name | Frequency | On Time | Off Time |
| | | (s) | (s) |
+-------------------------+-------------------+----------+----------+
| CNG | 1100 | 0.5 | 3.0 |
| V.25 CT | 1300 | 0.5 | 2.0 |
| CED | 2100 | 3.3 | -- |
| ANS | 2100 | 3.3 | -- |
| ANSam | 2100*15 | 3.3 | -- |
| V.21 bit | 980 or 1180 or | 0.00333 | -- |
| | 1650 or 1850 | | |
| ------------- | ---------- | -------- | -------- |
| ITU dial tone | 425 | -- | -- |
| U.S. dial tone | 350+440 | -- | -- |
| ITU ringing tone | 425 | 0.67-1.5 | 3-5 |
| U.S. ringing tone | 440+480 | 2.0 | 4.0 |
| ITU busy tone | 425 | 0.1-0.6 | 0.1-0.7 |
| U.S. busy tone | 480+620 | 0.5 | 0.5 |
| ITU congestion tone | 425 | 0.1-0.6 | 0.1-0.7 |
| U.S. congestion tone | 480+620 | 0.25 | 0.25 |
+-------------------------+-------------------+----------+----------+
Table 4: Examples of Telephony Tones
The RTP timestamp reflects the measurement point for the current packet. The event duration described in Section 4.3.3 begins at that time.
RTPタイムスタンプは、現在のパケットの測定点を反映しています。セクション4.3.3で説明されているイベント期間は、その時点で始まります。
The tone payload type uses the marker bit to distinguish the first RTP packet reporting a given instance of a tone from succeeding packets for that tone. The marker bit SHOULD be set to 1 for the first packet, and to 0 for all succeeding packets relating to the same tone.
トーンペイロードタイプは、マーカービットを使用して、そのトーンの後続パケットからトーンの特定のインスタンスを報告する最初のRTPパケットを区別します。マーカービットは、最初のパケットの場合は1に、同じトーンに関連するすべての後続のパケットで0に設定する必要があります。
Based on the characteristics described above, this document defines an RTP payload format called "tone" that can represent tones consisting of one or more frequencies. (The corresponding media type is "audio/tone".) The default timestamp rate is 8000 Hz, but other rates may be defined. Note that the timestamp rate does not affect the interpretation of the frequency, just the durations.
上記の特性に基づいて、このドキュメントは、1つ以上の周波数で構成されるトーンを表す「トーン」と呼ばれるRTPペイロード形式を定義します。（対応するメディアタイプは「オーディオ/トーン」です。）デフォルトのタイムスタンプレートは8000 Hzですが、他のレートが定義される場合があります。タイムスタンプのレートは、頻度の解釈に影響を与えないことに注意してください。
In accordance with current practice, this payload format does not have a static payload type number, but uses an RTP payload type number established dynamically and out-of-band.
現在のプラクティスに従って、このペイロード形式は静的なペイロードタイプ番号を持っていませんが、動的で帯域外に確立されたRTPペイロードタイプ番号を使用します。
The payload format is shown in Figure 2.
ペイロード形式を図2に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation |T| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Payload Format for Tones
図2：トーンのペイロード形式
The payload contains the following fields:
ペイロードには次のフィールドが含まれています。
modulation: The modulation frequency, in Hz. The field is a 9-bit unsigned integer, allowing modulation frequencies up to 511 Hz. If there is no modulation, this field has a value of zero. Note that the amplitude of modulation is not indicated in the payload and must be determined by out-of-band means.
変調：Hzの変調周波数。フィールドは9ビットの署名されていない整数であり、最大511 Hzまでの変調周波数が可能になります。変調がない場合、このフィールドにはゼロの値があります。変調の振幅はペイロードに示されておらず、帯域外の平均によって決定する必要があることに注意してください。
T: If the T bit is set (one), the modulation frequency is to be divided by three. Otherwise, the modulation frequency is taken as is.
T：tビットが設定されている場合（1）、変調周波数は3で除算されます。それ以外の場合、変調頻度はそのまま取得されます。
This bit allows frequencies accurate to 1/3 Hz, since modulation frequencies such as 16 2/3 Hz are in practical use.
16 2/3 Hzなどの変調周波数が実際に使用されているため、このビットは1/3 Hzまで正確になることができます。
volume: The power level of the tone, expressed in dBm0 after dropping the sign, with range from 0 to -63 dBm0. (Note: A preferred level range for digital tone generators is -8 dBm0 to -3 dBm0.)
ボリューム：標識を落とした後にDBM0で表現されたトーンのパワーレベル、0〜 -63 DBM0の範囲。（注：デジタルトーンジェネレーターの優先レベル範囲は-8 dBM0〜 -3 dBM0です。）
duration: The duration of the tone, measured in timestamp units and presented in network byte order. The tone begins at the instant identified by the RTP timestamp and lasts for the duration value. The value of zero is not permitted, and tones with such a duration SHOULD be ignored.
The definition of duration corresponds to that for sample-based codecs, where the timestamp represents the sampling point for the first sample.
frequency: The frequencies of the tones to be added, measured in Hz and represented as a 12-bit unsigned integer. The field size is sufficient to represent frequencies up to 4095 Hz, which exceeds the range of telephone systems. A value of zero indicates silence. A single tone can contain any number of frequencies. If no frequencies are specified, the packet reports a period of silence.
周波数：追加するトーンの周波数は、Hzで測定され、12ビットの署名されていない整数として表されます。フィールドサイズは、最大4095 Hzまでの周波数を表すのに十分であり、これは電話システムの範囲を超えています。ゼロの値は沈黙を示します。単一のトーンには、任意の数の周波数を含めることができます。周波数が指定されていない場合、パケットは沈黙の期間を報告します。
R: This field is reserved for future use. The sender MUST set it to zero, and the receiver MUST ignore it.
R：このフィールドは、将来の使用のために予約されています。送信者はそれをゼロに設定する必要があり、レシーバーはそれを無視する必要があります。
The "rate" parameter describes the sampling rate, in Hertz. The number is written as an integer. If omitted, the default value is 8000 Hz.
「レート」パラメーターは、Hertzのサンプリングレートを記述します。番号は整数として書かれています。省略すると、デフォルト値は8000 Hzです。
This section defines the procedures associated with the tone payload type.
このセクションでは、トーンペイロードタイプに関連する手順を定義します。
The sender MAY send an initial tones packet as soon as a tone is recognized, or MAY wait until a pre-negotiated packetization period has elapsed. The first RTP packet for a tone SHOULD have the marker bit set to 1.
送信者は、トーンが認識されるとすぐに初期トーンパケットを送信するか、事前に交渉されたパケット化期間が経過するまで待つことができます。トーン用の最初のRTPパケットは、マーカービットを1に設定する必要があります。
In the case of longer-duration tones, the sender SHOULD generate multiple RTP packets for the same tone instance. The RTP timestamp MUST be updated for each packet generated (in contrast, for instance, to the timestamp for packets carrying telephone events). Subsequent packets for the same tone SHOULD have the marker bit set to 0, and the RTP timestamp in each subsequent packet MUST equal the sum of the timestamp and the duration in the preceding packet.
長時間のトーンの場合、送信者は同じトーンインスタンスに対して複数のRTPパケットを生成する必要があります。RTPタイムスタンプは、生成されたパケットごとに更新する必要があります（たとえば、電話イベントを運ぶパケットのタイムスタンプと対照的です）。同じトーンの後続のパケットは、マーカービットを0に設定し、その後の各パケットのRTPタイムスタンプは、前のパケットのタイムスタンプの合計と持続時間に等しくなければなりません。
A final RTP packet MAY be generated as soon as the end of the tone is detected, without waiting for the latest packetization period to elapse.
最新のパケット化期間が経過するのを待つことなく、トーンの終了が検出されるとすぐに、最終的なRTPパケットが生成される場合があります。
The telephone-event payload described in Section 2 is inherently redundant, in that later packets for the same event carry all of the earlier history of the event except for variations in volume. In contrast, each packet for the tone payload type stands alone; a lost packet means a gap in the information available at the receiving end. Thus, for increased reliability, the sender SHOULD combine new and old tone reports in the same RTP packet using RFC 2198 [2] audio redundancy.
セクション2で説明されている電話 - イベントのペイロードは本質的に冗長です。同じイベントの後のパケットは、ボリュームのバリエーションを除いて、イベントの初期の履歴のすべてを伴うという点では。対照的に、トーンペイロードタイプの各パケットは単独で存在します。失われたパケットとは、受信側で利用可能な情報のギャップを意味します。したがって、信頼性を高めるために、送信者は、RFC 2198 [2]オーディオ冗長性を使用して、同じRTPパケットに新しいトーンレポートと古いトーンレポートを組み合わせる必要があります。
Receiving implementations play out the tones as received, typically with a playout delay to allow for lost packets. When playing out successive tone reports for the same tone (marker bit is zero, the RTP timestamp is contiguous with that of the previous RTP packet, and payload content is identical), the receiving implementation SHOULD continue the tone without change or a break.
実装の受信は、受信した通りにトーンを再生します。通常は、パケットを失うことを可能にするためにプレイアウトの遅延があります。同じトーンの連続トーンレポートを再生すると（マーカービットがゼロで、RTPタイムスタンプが以前のRTPパケットのものと隣接し、ペイロードコンテンツが同じです）、受信実装は変更や休憩なしでトーンを継続する必要があります。
If the sender determines that packets are being lost due to congestion (e.g., through RTCP receiver reports), it SHOULD increase the packetization interval for initial and interim tone reports so as to reduce traffic volume to the receiver. The degree to which this is possible without causing damaging consequences at the receiving end depends both upon the playout delay used at that end and upon the specific application associated with the tones. Both the maximum packetization interval and maximum increase in packetization interval at any one time are therefore a matter of configuration or out-of-band negotiation.
送信者が混雑のためにパケットが失われていると判断した場合（たとえば、RTCPレシーバーレポートを介して）、受信機への交通量を減らすために初期および暫定トーンレポートのパケット化間隔を増やす必要があります。受信側で損傷を引き起こすことなくこれが可能である程度は、その端で使用されるプレイアウト遅延とトーンに関連する特定のアプリケーションの両方に依存します。したがって、最大パケット化間隔とパケット化間隔の最大増加の両方は、構成または帯域外交渉の問題です。
Consider a DTMF dialling sequence, where the user dials the digits "911" and a sending gateway detects them. The first digit is 200 ms long (1600 timestamp units) and starts at time 0; the second digit lasts 250 ms (2000 timestamp units) and starts at time 880 ms (7040 timestamp units); the third digit is pressed at time 1.4 s (11,200 timestamp units) and lasts 220 ms (1760 timestamp units). The frame duration is 50 ms.
ユーザーが数字「911」にダイヤルし、送信ゲートウェイがそれらを検出するDTMFダイヤルシーケンスを検討します。最初の数字は200ミリ秒の長さ（1600タイムスタンプユニット）で、時間0から始まります。2桁目は250ミリ秒（2000タイムスタンプユニット）に続き、時間880ミリ秒（7040タイムスタンプユニット）から始まります。3番目の数字は、時間1.4秒（11,200タイムスタンプユニット）で押され、220ミリ秒（1760タイムスタンプユニット）が続きます。フレーム期間は50ミリ秒です。
Table 5 shows the complete sequence of events assuming that only the telephone-event payload type is being reported. For simplicity: the timestamp is assumed to begin at 0, the RTP sequence number at 1, and volume settings are omitted.
表5は、電話でイベントのペイロードタイプのみが報告されていると仮定したイベントの完全なシーケンスを示しています。簡単にするために、タイムスタンプは0から始まると想定され、RTPシーケンス番号は1、ボリューム設定は省略されています。
+-------+-----------+------+--------+------+--------+--------+------+
| Time | Event | M | Time- | Seq | Event | Dura- | E |
| (ms) | | bit | stamp | No | Code | tion | bit |
+-------+-----------+------+--------+------+--------+--------+------+
| 0 | "9" | | | | | | |
| | starts | | | | | | |
| 50 | RTP | "1" | 0 | 1 | 9 | 400 | "0" |
| | packet 1 | | | | | | |
| | sent | | | | | | |
| 100 | RTP | "0" | 0 | 2 | 9 | 800 | "0" |
| | packet 2 | | | | | | |
| | sent | | | | | | |
| 150 | RTP | "0" | 0 | 3 | 9 | 1200 | "0" |
| | packet 3 | | | | | | |
| | sent | | | | | | |
| 200 | RTP | "0" | 0 | 4 | 9 | 1600 | "0" |
| | packet 4 | | | | | | |
| | sent | | | | | | |
| 200 | "9" ends | | | | | | |
| 250 | RTP | "0" | 0 | 5 | 9 | 1600 | "1" |
| | packet 4 | | | | | | |
| | first | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 300 | RTP | "0" | 0 | 6 | 9 | 1600 | "1" |
| | packet 4 | | | | | | |
| | second | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 880 | First "1" | | | | | | |
| | starts | | | | | | |
| 930 | RTP | "1" | 7040 | 7 | 1 | 400 | "0" |
| | packet 5 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1130 | RTP | "0" | 7040 | 11 | 1 | 2000 | "0" |
| | packet 9 | | | | | | |
| | sent | | | | | | |
| 1130 | First "1" | | | | | | |
| | ends | | | | | | |
| 1180 | RTP | "0" | 7040 | 12 | 1 | 2000 | "1" |
| | packet 9 | | | | | | |
| | first | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 1230 | RTP | "0" | 7040 | 13 | 1 | 2000 | "1" |
| | packet 9 | | | | | | |
| | second | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 1400 | Second | | | | | | |
| | "1" | | | | | | |
| | starts | | | | | | |
| 1450 | RTP | "1" | 11200 | 14 | 1 | 400 | "0" |
| | packet 10 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1620 | Second | | | | | | |
| | "1" ends | | | | | | |
| 1650 | RTP | "0" | 11200 | 18 | 1 | 1760 | "1" |
| | packet 14 | | | | | | |
| | sent | | | | | | |
| 1700 | RTP | "0" | 11200 | 19 | 1 | 1760 | "1" |
| | packet 14 | | | | | | |
| | first | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 1750 | RTP | "0" | 11200 | 20 | 1 | 1760 | "1" |
| | packet 14 | | | | | | |
| | second | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
+-------+-----------+------+--------+------+--------+--------+------+
Table 5: Example of Event Reporting
表5：イベントレポートの例
Table 6 shows the same sequence assuming that only the tone payload type is being reported. This looks somewhat different. For simplicity: the timestamp is assumed to begin at 0, the sequence number at 1. Volume, the T bit, and the modulation frequency are omitted. The latter two are always 0.
表6は、トーンペイロードタイプのみが報告されていると仮定して、同じシーケンスを示しています。これは多少異なって見えます。簡単にするために、タイムスタンプは0で始まると想定されています。シーケンス数は1で、ボリューム、Tビット、および変調周波数は省略されています。後者の2つは常に0です。
+-------+-----------+-----+--------+------+--------+-------+--------+
| Time | Event | M | Time- | Seq | Dura- | Freq 1| Freq 2 |
| (ms) | | bit | stamp | No | tion | (Hz) | (Hz) |
+-------+-----------+-----+--------+------+--------+-------+--------+
| 0 | "9" | | | | | | |
| | starts | | | | | | |
| 50 | RTP | "1" | 0 | 1 | 400 | 852 | 1477 |
| | packet 1 | | | | | | |
| | sent | | | | | | |
| 100 | RTP | "0" | 400 | 2 | 400 | 852 | 1477 |
| | packet 2 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 200 | RTP | "0" | 1200 | 4 | 400 | 852 | 1477 |
| | packet 4 | | | | | | |
| | sent | | | | | | |
| 200 | "9" ends | | | | | | |
| 880 | First "1" | | | | | | |
| | starts | | | | | | |
| 930 | RTP | "1" | 7040 | 5 | 400 | 697 | 1209 |
| | packet 5 | | | | | | |
| | sent | | | | | | |
| 980 | RTP | "0" | 7440 | 6 | 400 | 697 | 1209 |
| | packet 6 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1130 | First "1" | | | | | | |
| | ends | | | | | | |
| 1400 | Second | | | | | | |
| | "1" | | | | | | |
| | starts | | | | | | |
| 1450 | RTP | "1" | 11200 | 10 | 400 | 697 | 1209 |
| | packet 10 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1620 | Second | | | | | | |
| | "1" ends | | | | | | |
| 1650 | RTP | "0" | 12800 | 14 | 160 | 697 | 1209 |
| | packet 14 | | | | | | |
| | sent | | | | | | |
+-------+-----------+-----+--------+------+--------+-------+--------+
Table 6: Example of Tone Reporting
Now consider a combined payload, where the tone payload is the primary payload type and the event payload is treated as a redundant encoding (one level of redundancy). Because the primary payload is tones, the tone payload rules determine the setting of the RTP header fields. This means that the RTP timestamp always advances. As a corollary, the timestamp offset for the events payload in the RFC 2198 header increases by the same amount.
次に、トーンペイロードが主要なペイロードタイプであり、イベントペイロードが冗長エンコーディング（冗長性の1つのレベル）として扱われる組み合わせのペイロードを検討します。主なペイロードはトーンであるため、トーンペイロードルールはRTPヘッダーフィールドの設定を決定します。これは、RTPタイムスタンプが常に進歩することを意味します。結果として、RFC 2198ヘッダーのイベントペイロードのタイムスタンプオフセットは、同じ量だけ増加します。
One issue that has to be considered in a combined payload is how to handle retransmissions of final event reports. The tone payload specification does not recommend retransmissions of final packets, so it is unclear what to put in the primary payload fields of the combined packet. In the interests of simplicity, it is suggested that the retransmitted packets copy the fields relating to the primary payload (including the RTP timestamp) from the original packet. The same principle can be applied if the packet includes multiple levels of event payload redundancy.
複合ペイロードで考慮する必要がある問題の1つは、最終的なイベントレポートの再送信を処理する方法です。トーンペイロード仕様では、最終パケットの再送信を推奨しないため、複合パケットのプライマリペイロードフィールドに何を配置するかは不明です。簡単にするために、再送信されたパケットは、元のパケットからプライマリペイロード（RTPタイムスタンプを含む）に関連するフィールドをコピーすることが示唆されています。パケットに複数のレベルのイベントペイロード冗長性が含まれている場合、同じ原則を適用できます。
The figures below all illustrate "RTP packet 14" in the above tables. Figure 3 shows an event-only payload, corresponding to Table 5. Figure 4 shows a tone-only payload, corresponding to Table 6. Finally, Figure 5 shows a combined payload, with tones primary and events as a single redundant layer. Note that the combined payload has the RTP sequence numbers shown in Table 5, because the transmitted sequence includes the retransmitted packets.
以下の図はすべて、上記の表の「RTPパケット14」を示しています。図3は、表5に対応するイベントのみのペイロードを示しています。図4は、表6に対応するトーンのみのペイロードを示しています。最後に、図5は、トーンのプライマリとイベントが単一の冗長層としてのペイロードを示しています。送信されたシーケンスには再送信パケットが含まれているため、複合ペイロードには表5に示されているRTPシーケンス番号があることに注意してください。
Figure 3 assumes that the following SDP specification was used. This session description provides for separate streams of G.729 [21] audio and events. Packets reported within the G.729 stream are not considered here.
図3は、次のSDP仕様が使用されたと仮定しています。このセッションの説明は、G.729 [21]オーディオとイベントの個別のストリームを提供します。G.729ストリーム内で報告されたパケットはここでは考慮されません。
m=audio 12344 RTP/AVP 99
a=rtpmap:99 G729/8000
a=ptime:20
m=audio 12346 RTP/AVP 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:50
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 100 | 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 11200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event |E R| volume | duration |
| 1 |1 0| 20 | 1760 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Example RTP Packet for Event Payload
図3：イベントペイロードの例RTPパケット
Figure 4 assumes that an SDP specification similar to that of the previous case was used.
図4は、以前のケースと同様のSDP仕様が使用されたと仮定しています。
m=audio 12344 RTP/AVP 99
a=rtpmap:99 G729/8000
a=ptime:20
m=audio 12346 RTP/AVP 101
a=rtpmap:101 tone/8000
a=ptime:50
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 101 | 14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 12800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation |T| volume | duration |
| 0 |0| 20 | 160 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
|0 0 0 0| 697 |0 0 0 0| 1209 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Example RTP Packet for Tone Payload
図4：トーンペイロードのためのRTPパケットの例
Figure 5, for the combined payload, assumes the following SDP session description:
図5は、ペイロードを組み合わせて、次のSDPセッションの説明を想定しています。
m=audio 12344 RTP/AVP 99
a=rtpmap:99 G729/8000
a=ptime:20
m=audio 12346 RTP/AVP 102 101 100
a=rtpmap:102 red/8000/1
a=fmtp:102 101/100
a=rtpmap:101 tone/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:50
For ease of presentation, Figure 5 presents the actual payloads as if they began on 32-bit boundaries. In the actual packet, they follow immediately after the end of the RFC 2198 header, and thus are displaced one octet into successive words.
プレゼンテーションを容易にするために、図5は、32ビットの境界で始まったかのように実際のペイロードを示しています。実際のパケットでは、RFC 2198ヘッダーの終了直後に続いているため、1オクテットが連続した単語に移動します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 102 | 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 12800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 100 | 1600 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | event payload begins ... /
|0| 101 | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Event payload
イベントペイロード
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event |E R| volume | duration |
| 1 |1 0| 20 | 1760 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tone payload
トーンペイロード
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation |T| volume | duration |
| 0 |0| 20 | 160 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
|0 0 0 0| 697 |0 0 0 0| 1209 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example RTP Packet for Combined Tone and Event Payloads
図5：トーンとイベントのペイロードを組み合わせたRTPパケットの例
RTP packets using the payload formats defined in this specification are subject to the security considerations discussed in the RTP specification (RFC 3550 [5]), and any appropriate RTP profile (for example, RFC 3551 [13]). The RFC 3550 discussion focuses on requirements for confidentiality. Additional security considerations relating to implementation are described in RFC 2198 [2].
この仕様で定義されているペイロード形式を使用したRTPパケットは、RTP仕様（RFC 3550 [5]）で説明されているセキュリティ考慮事項と、適切なRTPプロファイル（たとえば、RFC 3551 [13]）の対象となります。RFC 3550ディスカッションは、機密性の要件に焦点を当てています。実装に関する追加のセキュリティ上の考慮事項は、RFC 2198 [2]で説明されています。
The telephone-event payload defined in this specification is highly compressed. A change in value of just one bit can result in a major change in meaning as decoded at the receiver. Thus, message integrity MUST be provided for the telephone-event payload type.
この仕様で定義されている電話のイベントペイロードは非常に圧縮されています。値の値の変更は、レシーバーでデコードされたように、意味の大きな変化をもたらす可能性があります。したがって、電話 - イベントペイロードタイプにはメッセージの整合性を提供する必要があります。
To meet the need for protection both of confidentiality and integrity, compliant implementations SHOULD implement the Secure Real-time Transport Protocol (SRTP) [7].
機密性と整合性の両方の保護の必要性を満たすために、準拠した実装は安全なリアルタイム輸送プロトコル（SRTP）を実装する必要があります[7]。
Note that the appropriate method of key distribution for SRTP may vary with the specific application.
SRTPの重要な分布の適切な方法は、特定のアプリケーションによって異なる場合があることに注意してください。
In some deployments, it may be preferable to use other means to provide protection equivalent to that provided by SRTP.
一部の展開では、SRTPが提供するものと同等の保護を提供するために、他の手段を使用することが望ましい場合があります。
Provided that gateway design includes robust, low-overhead tone generation, this payload type does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing to cause a potential denial-of-service threat.
ゲートウェイの設計には堅牢で低オーバーヘッドトーン生成が含まれている場合、このペイロードタイプは、パケット処理のレシーバー側の計算の複雑さに有意な不均一性を示して、潜在的なサービス拒否の脅威を引き起こします。
This document updates the descriptions of two RTP payload formats, 'telephone-event' and 'tone', and associated Internet media types, audio/telephone-event and audio/tone. It also documents the event codes for DTMF tone events.
このドキュメントでは、2つのRTPペイロード形式、「電話イベント」および「トーン」、および関連するインターネットメディアタイプ、オーディオ/電話 - イベント、オーディオ/トーンの説明を更新します。また、DTMFトーンイベントのイベントコードを文書化します。
Within the audio/telephone-event type, events MUST be registered with IANA. Registrations are subject to the policies "Specification Required" and "Expert Review" as defined in RFC 2434 [3]. The IETF-appointed expert must ensure that:
オーディオ/電話イベントタイプ内で、イベントはIANAに登録する必要があります。登録には、RFC 2434 [3]で定義されている「必要な仕様」および「専門家レビュー」のポリシーの対象となります。IETFに任命された専門家は、次のことを確認する必要があります。
a. the meaning and application of the proposed events are clearly documented;
a. 提案されたイベントの意味と適用は明確に文書化されています。
b. the events cannot be represented by existing event codes, possibly with some minor modification of event definitions;
b. イベントは、既存のイベントコードで表現することはできません。おそらく、イベント定義を少し変更することができます。
c. the number of events is the minimum necessary to fulfill the purpose of their application(s).
c. イベントの数は、アプリケーションの目的を満たすために必要な最小です。
The expert is further responsible for providing guidance on the allocation of event codes to the proposed events. Specifically, the expert must indicate whether the event appears to be the same as one defined in RFC 2833 but not specified in any new document. In this case, the event code specified in RFC 2833 for that event SHOULD be assigned to the proposed event. Otherwise, event codes MUST be assigned from the set of available event codes listed below. If this set is exhausted, the criterion for assignment from the reserved set of event codes is to first assign those that appear to have the lowest probability of being revived in their RFC 2833 meaning in a new specification.
専門家は、提案されたイベントへのイベントコードの割り当てに関するガイダンスをさらに提供する責任があります。具体的には、専門家は、イベントがRFC 2833で定義されているものと同じように見えるが、新しいドキュメントでは指定されていないかどうかを示す必要があります。この場合、そのイベントのRFC 2833で指定されたイベントコードは、提案されたイベントに割り当てる必要があります。それ以外の場合、イベントコードは、以下にリストされている利用可能なイベントコードのセットから割り当てる必要があります。このセットが使い果たされている場合、イベントコードの予約セットからの割り当ての基準は、最初に新しい仕様でRFC 2833の意味で復活する可能性が最も低いと思われるものを割り当てることです。
The documentation for each event MUST indicate whether the event is a state, tone, or other type of event (e.g., an out-of-band electrical event such as on-hook or an indication that will not itself be played out as tones at the receiving end). For tone events, the documentation MUST indicate whether the volume field is applicable or must be set to 0.
各イベントのドキュメントでは、イベントが状態、トーン、またはその他のタイプのイベントであるかどうかを示している必要があります（たとえば、オンフックなどの帯域外の電気イベントや、それ自体がトーンとして再生されない兆候受信側）。トーンイベントの場合、ドキュメントは、ボリュームフィールドが適用可能かどうかを示す必要があります。または0に設定する必要があります。
In view of the tradeoffs between the different reliability mechanisms discussed in Section 2.6, documentation of specific events SHOULD include a discussion of the appropriate design decisions for the applications of those events.
セクション2.6で説明したさまざまな信頼性メカニズム間のトレードオフを考慮して、特定のイベントの文書には、これらのイベントのアプリケーションに関する適切な設計決定の議論を含める必要があります。
Legal event codes range from 0 to 255. The initial registry content is shown in Table 7, and consists of the sixteen events defined in Section 3 of this document. The remaining codes have the following disposition:
法的イベントコードの範囲は0〜255です。初期レジストリコンテンツは表7に示されており、このドキュメントのセクション3で定義されている16のイベントで構成されています。残りのコードには次の処分があります。
o codes 17-22, 50-51, 90-95, 113-120, 169, and 206-255 are available for assignment;
o コード17-22、50-51、90-95、113-120、169、および206-255は割り当てに利用できます。
o codes 23-40, 49, and 52-63 are reserved for events defined in [16];
o コード23-40、49、および52-63は、[16]で定義されたイベントのために予約されています。
o codes 121-137 and 174-205 are reserved for events defined in [17];
o コード121-137および174-205は、[17]で定義されたイベントのために予約されています。
o codes 16, 41-48, 64-88, 96-112, 138-168, and 170-173 are reserved in the first instance for specifications reviving the corresponding RFC 2833 events, and in the second instance for general assignment after all other codes have been assigned.
o コード16、41-48、64-88、96-112、138-168、および170-173は、対応するRFC 2833イベントを復活させる仕様のために、および他のすべてのコードの後の一般的な割り当てのための2番目の例では予約されています割り当てられています。
+------------+--------------------------------+-----------+
| Event Code | Event Name | Reference |
+------------+--------------------------------+-----------+
| 0 | DTMF digit "0" | RFC 4733 |
| 1 | DTMF digit "1" | RFC 4733 |
| 2 | DTMF digit "2" | RFC 4733 |
| 3 | DTMF digit "3" | RFC 4733 |
| 4 | DTMF digit "4" | RFC 4733 |
| 5 | DTMF digit "5" | RFC 4733 |
| 6 | DTMF digit "6" | RFC 4733 |
| 7 | DTMF digit "7" | RFC 4733 |
| 8 | DTMF digit "8" | RFC 4733 |
| 9 | DTMF digit "9" | RFC 4733 |
| 10 | DTMF digit "*" | RFC 4733 |
| 11 | DTMF digit "#" | RFC 4733 |
| 12 | DTMF digit "A" | RFC 4733 |
| 13 | DTMF digit "B" | RFC 4733 |
| 14 | DTMF digit "C" | RFC 4733 |
| 15 | DTMF digit "D" | RFC 4733 |
+------------+--------------------------------+-----------+
Table 7: audio/telephone-event Event Code Registry
表7：オーディオ/電話 - イベントイベントコードレジストリ
This registration is done in accordance with [6] and [8].
この登録は[6]および[8]に従って行われます。
Type name: audio
Subtype name: telephone-event
サブタイプ名：電話 - イベント
Required parameters: none.
必要なパラメーター：なし。
Optional parameters:
オプションのパラメーター：
The "events" parameter lists the events supported by the implementation. Events are listed as one or more comma-separated elements. Each element can be either a single integer providing the value of an event code or an integer followed by a hyphen and a larger integer, presenting a range of consecutive event code values. The list does not have to be sorted. No white space is allowed in the argument. The union of all of the individual event codes and event code ranges designates the complete set of event numbers supported by the implementation. If the "events" parameter is omitted, support for events 0-15 (the DTMF tones) is assumed.
「イベント」パラメーターには、実装によってサポートされているイベントがリストされています。イベントは、1つ以上のコンマ区切り要素としてリストされています。各要素は、イベントコードの値を提供する単一の整数または整数に続いてハイフンとより大きな整数のいずれかであり、連続したイベントコード値の範囲を提示します。リストをソートする必要はありません。議論には空白は許可されていません。個々のすべてのイベントコードとイベントコード範囲の連合は、実装によってサポートされるイベント番号の完全なセットを指定します。「イベント」パラメーターが省略されている場合、イベント0-15（DTMFトーン）のサポートが想定されます。
The "rate" parameter describes the sampling rate, in Hertz. The number is written as an integer. If omitted, the default value is 8000 Hz.
「レート」パラメーターは、Hertzのサンプリングレートを記述します。番号は整数として書かれています。省略すると、デフォルト値は8000 Hzです。
Encoding considerations:
考慮事項のエンコード：
In the terminology defined by [8] section 4.8, this type is framed and binary.
[8]セクション4.8で定義されている用語では、このタイプはフレームとバイナリです。
Security considerations:
セキュリティ上の考慮事項：
See Section 6, "Security Considerations", in this document.
このドキュメントのセクション6「セキュリティ上の考慮事項」を参照してください。
Interoperability considerations: none.
相互運用性の考慮事項：なし。
Published specification: this document.
公開された仕様：このドキュメント。
Applications which use this media:
このメディアを使用するアプリケーション：
The telephone-event audio subtype supports the transport of events occurring in telephone systems over the Internet.
電話イベントオーディオサブタイプは、インターネット上の電話システムで発生するイベントの輸送をサポートしています。
Additional information:
追加情報：
Magic number(s): N/A. File extension(s): N/A. Macintosh file type code(s): N/A.
マジック番号：n/a。ファイル拡張子：n/a。Macintoshファイルタイプコード：n/a。
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Tom Taylor, taylor@nortel.com. IETF AVT Working Group.
トム・テイラー、taylor@nortel.com。IETF AVTワーキンググループ。
Intended usage: COMMON.
意図された使用法：共通。
Restrictions on usage:
使用に関する制限：
This type is defined only for transfer via RTP [5].
このタイプは、RTP [5]を介した転送に対してのみ定義されます。
Author: IETF Audio/Video Transport Working Group.
著者：IETFオーディオ/ビデオトランスポートワーキンググループ。
Change controller:
Change Controller：
IETF Audio/Video Transport Working Group as delegated from the IESG.
IESGから委任されたIETFオーディオ/ビデオトランスポートワーキンググループ。
This registration is done in accordance with [6] and [8].
この登録は[6]および[8]に従って行われます。
Type name: audio
タイプ名：オーディオ
Subtype name: tone
サブタイプ名：トーン
Required parameters: none
必要なパラメーター：なし
Optional parameters:
オプションのパラメーター：
The "rate" parameter describes the sampling rate, in Hertz. The number is written as an integer. If omitted, the default value is 8000 Hz.
「レート」パラメーターは、Hertzのサンプリングレートを記述します。番号は整数として書かれています。省略すると、デフォルト値は8000 Hzです。
Encoding considerations:
考慮事項のエンコード：
In the terminology defined by [8] section 4.8, this type is framed and binary.
[8]セクション4.8で定義されている用語では、このタイプはフレームとバイナリです。
Security considerations:
セキュリティ上の考慮事項：
See Section 6, "Security Considerations", in this document.
このドキュメントのセクション6「セキュリティ上の考慮事項」を参照してください。
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: this document.
公開された仕様：このドキュメント。
Applications which use this media:
このメディアを使用するアプリケーション：
The tone audio subtype supports the transport of pure composite tones, for example, those commonly used in the current telephone system to signal call progress.
Additional information:
追加情報：
Magic number(s): N/A. File extension(s): N/A. Macintosh file type code(s): N/A.
マジック番号：n/a。ファイル拡張子：n/a。Macintoshファイルタイプコード：n/a。
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Tom Taylor, taylor@nortel.com. IETF AVT Working Group.
トム・テイラー、taylor@nortel.com。IETF AVTワーキンググループ。
Intended usage: COMMON.
意図された使用法：共通。
Restrictions on usage:
使用に関する制限：
This type is defined only for transfer via RTP [5].
このタイプは、RTP [5]を介した転送に対してのみ定義されます。
Author: IETF Audio/Video Transport Working Group.
著者：IETFオーディオ/ビデオトランスポートワーキンググループ。
Change controller:
Change Controller：
IETF Audio/Video Transport Working Group as delegated from the IESG.
Scott Petrack was the original author of RFC 2833. Henning Schulzrinne later loaned his expertise to complete the document, but Scott must be credited with the energy behind the idea of a compact encoding of tones over IP.
スコット・ペトラックはRFC 2833の元の著者でした。ヘニング・シュルツリンヌは後に文書を完成させるために彼の専門知識を貸しましたが、スコットはIPよりもトーンのコンパクトなエンコードのアイデアの背後にあるエネルギーを認めなければなりません。
In RFC 2833, the suggestions of the Megaco working group were acknowledged. Colin Perkins and Magnus Westerland, Chairs of the AVT Working Group, provided helpful advice in the formation of the present document. Over the years, detailed advice and comments for RFC 2833, this document, or both were provided by Hisham Abdelhamid, Flemming Andreasen, Fred Burg, Steve Casner, Dan Deliberato, Fatih Erdin, Bill Foster, Mike Fox, Mehryar Garakani, Gunnar Hellstrom, Rajesh Kumar, Terry Lyons, Steve Magnell, Zarko Markov, Tim Melanchuk, Kai Miao, Satish Mundra, Kevin Noll, Vern Paxson, Oren Peleg, Raghavendra Prabhu, Moshe Samoha, Todd Sherer, Adrian Soncodi, Yaakov Stein, Mira Stevanovic, Alex Urquizo, and Herb Wildfeur.
RFC 2833では、メガコワーキンググループの提案が認められました。AVTワーキンググループの椅子であるColin PerkinsとMagnus Westerlandは、現在の文書の形成に役立つアドバイスを提供しました。長年にわたり、RFC 2833の詳細なアドバイスとコメント、この文書、またはその両方は、Hisham Abdelhamid、Flemming Andreasen、Fred Burg、Steve Casner、Dan Deliberato、Fatih Erdin、Bill Foster、Mike Fox、Mehryar Garakani、Gunnar Hellstrom、Rajesh Kumar、Terry Lyons、Steve Magnell、Zarko Markov、Tim Lanchuk、Kai Miao、Satish Mundra、Kevin Noll、Vern Paxson、Oren Peleg、Raghavendra Prabhu、Moshe Samoha、Todd Sherer、Adrian Soncodi、およびハーブWildfeur。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[2] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-Parisis、 "RTP Payload for Redundant Audioデータ」、RFC 2198、1997年9月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[5]
[6] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[6] Casner、S。およびP. Hoschka、「RTPペイロードフォーマットのMIMEタイプ登録」、RFC 3555、2003年7月。
[7] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[7] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[8] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[8] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[9] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[9] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[10] International Telecommunication Union, "Technical features of push-button telephone sets", ITU-T Recommendation Q.23, November 1988.
[10] 国際電気通信ユニオン、「プッシュボタン電話セットの技術的特徴」、ITU-Tの推奨Q.23、1988年11月。
[11] International Telecommunication Union, "Multifrequency push-button signal reception", ITU-T Recommendation Q.24, November 1988.
[11] International Telecommunication Union、「多面的なプッシュボタン信号受信」、ITU-Tの推奨Q.24、1988年11月。
[12] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[12] Schulzrinne、H。およびS. Petrack、「DTMFディジット、テレフォニートーン、テレフォニーシグナルのRTPペイロード」、RFC 2833、2000年5月。
[13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[13] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[14] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent Call", RFC 4040, April 2005.
[14]
[15] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[15] Hellstrom、G。およびP. Jones、「テキスト会話のためのRTPペイロード」、RFC 4103、2005年6月。
[16] Schulzrinne, H. and T. Taylor, "Definition of Events for Modem, Fax, and Text Telephony Signals", RFC 4734, December 2006.
[16]
[17] Schulzrinne, H. and T. Taylor, "Definition of Events For Channel-Oriented Telephony Signalling", Work In Progress , November 2005.
[17] Schulzrinne、H。およびT. Taylor、「チャネル指向のテレフォニーシグナリングのイベントの定義」、2005年11月、進行中の作業。
[18] International Telecommunication Union, "Technical characteristics of tones for the telephone service", ITU-T Recommendation E.180/Q.35, March 1998.
[18] 国際電気通信ユニオン、「電話サービスのトーンの技術的特性」、ITU-T推奨E.180/Q.35、1998年3月。
[19] International Telecommunication Union, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988.
[19] 国際電気通信ユニオン、「音声周波数のパルスコード変調（PCM）」、ITU-T推奨G.711、1988年11月。
[20] International Telecommunication Union, "Speech coders : Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s", ITU-T Recommendation G.723.1, March 1996.
[20] International Telecommunication Union、「スピーチコーダー：5.3および6.3 Kbit/sで送信するマルチメディア通信のデュアルレートスピーチコーダー」、ITU-T推奨G.723.1、1996年3月。
[21] International Telecommunication Union, "Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996.
[21] 国際電気通信ユニオン、「コンジュゲート構造代数コード発現線形予測（CS-Acelp）を使用した8 kbit/sでの音声のコーディング」、ITU-T推奨G.729、1996年3月。
[22] International Telecommunication Union, "ISDN user-network interface layer 3 specification for basic call control", ITU-T Recommendation Q.931, May 1998.
[22] International Telecommunication Union、「ISDNユーザーネットワークインターフェイスレイヤー3基本コールコントロールの仕様」、ITU-T推奨Q.931、1998年5月。
[23] International Telecommunication Union, "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, July 2003.
[23] International Telecommunication Union、「IPネットワーク上のリアルタイムグループ3ファクシミリ通信の手順」、ITU-T推奨T.38、2003年7月。
[24] International Telecommunication Union, "Procedures for starting sessions of data transmission over the public switched telephone network", ITU-T Recommendation V.8, November 2000.
[24] 国際電気通信ユニオン、「公共の切り替えた電話網を介したデータ送信のセッションを開始する手順」、ITU-T勧告v.8、2000年11月。
[25] International Telecommunication Union, "Modem-over-IP networks: Procedures for the end-to-end connection of V-series DCEs", ITU-T Recommendation V.150.1, January 2003.
[25] International Telecommunication Union、「モデムオーバーIPネットワーク：VシリーズDCEのエンドツーエンド接続の手順」、ITU-T推奨V.150.1、2003年1月。
[26] International Telecommunication Union, "Procedures for supporting Voice-Band Data over IP Networks", ITU-T Recommendation V.152, January 2005.
[26] 国際電気通信連合、「IPネットワーク上の音声帯域データをサポートする手順」、ITU-T推奨v.152、2005年1月。
[27] International Telecommunication Union, "Operational and interworking requirements for {DCEs operating in the text telephone mode", ITU-T Recommendation V.18, November 2000.
[27] 国際電気通信ユニオン、「テキスト電話モードで動作するDCESの運用およびインターワーキング要件」、ITU-T推奨v.18、2000年11月。
See also Recommendation V.18 Amendment 1, Nov. 2002. [28] VOIP Troubleshooter LLC, "Indepth: Packet Loss Burstiness", 2005, <http://www.voiptroubleshooter.com/indepth/burstloss.html>.
2002年11月、推奨v.18修正1、[28] VoIP Troubbleshooter LLC、「Indepth：Packet Loss Burstiness」、2005、<http://www.voiptroubleshooter.com/indepth/burstloss.html>も参照してください。
The memo has been significantly restructured, incorporating a large number of clarifications to the specification. With the exception of those items noted below, the changes to the memo are intended to be backwards-compatible clarifications. However, due to inconsistencies and unclear definitions in RFC 2833 [12] it is likely that some implementations interpreted that memo in ways that differ from this version.
RFC 2833 required that all implementations be capable of receiving the DTMF events (event codes 0-15). Section 2.5.1.1 of the present document requires that a sender transmit only the events that the receiver is capable of receiving. In the absence of a knowledge of receiver capabilities, the sender SHOULD assume support of the DTMF events but of no other events. The sender SHOULD indicate what events it can send. Section 2.5.2.1 requires that a receiver signalling its capabilities using SDP MUST indicate which events it can receive.
RFC 2833は、すべての実装がDTMFイベントを受信できることを要求しました（イベントコード0-15）。現在のドキュメントのセクション2.5.1.1では、送信者が受信者が受信できるイベントのみを送信する必要があります。受信機の機能に関する知識がない場合、送信者はDTMFイベントのサポートを想定する必要がありますが、他のイベントはありません。送信者は、送信できるイベントを示す必要があります。セクション2.5.2.1では、SDPを使用してその機能を通知する受信者が、受け取ることができるイベントを示す必要があります。
Non-zero values in the volume field of the payload were applicable only to DTMF tones in RFC 2833, and for other events the receiver was required to ignore them. The present memo requires that the definition of each event indicate whether the volume field is applicable to that event. The last paragraph of Section 2.5.2.2 indicates what a receiver may do if it receives volumes with zero values for events to which the volume field is applicable. Along with the RFC 2833 receiver rule, this ensures backward compatibility in both directions of transmission.
ペイロードのボリュームフィールドの非ゼロ値は、RFC 2833のDTMFトーンにのみ適用され、他のイベントではレシーバーがそれらを無視する必要がありました。現在のメモでは、各イベントの定義が、ボリュームフィールドがそのイベントに適用できるかどうかを示すことを要求しています。セクション2.5.2.2の最後の段落は、ボリュームフィールドが適用されるイベントの値がゼロのボリュームを受信した場合、レシーバーが何をするかを示します。RFC 2833レシーバールールに加えて、これにより、伝送の両方向に後方互換性が保証されます。
Section 2.5.1.3 and Section 2.5.2.3 introduce a new procedure for reporting and playing out events whose duration exceeds the capacity of the payload duration field. This procedure may cause momentary confusion at an old (RFC 2833) receiver, because the timestamp is updated without setting the E bit of the preceding event report and without setting the M bit of the new one.
セクション2.5.1.3およびセクション2.5.2.3では、ペイロード期間フィールドの容量を超える期間を報告およびプレイするための新しい手順を紹介します。この手順は、前述のイベントレポートのeビットを設定せず、新しいもののmビットを設定することなく更新されるため、古い（RFC 2833）レシーバーで瞬間的な混乱を引き起こす可能性があります。
Section 2.5.1.5 and Section 2.5.2.4 introduce a new procedure whereby a sequence of short-duration events may be packed into a single event report. If an old (RFC 2833) receiver receives such a report, it may discard the packet as invalid, since the packet holds more content than the receiver was expecting. In any event, the additional events in the packet will be lost.
セクション2.5.1.5およびセクション2.5.2.4では、一連の短時間のイベントを単一のイベントレポートに詰め込むことができる新しい手順を紹介します。古い（RFC 2833）レシーバーがそのようなレポートを受け取る場合、パケットはレシーバーが予想していたよりも多くのコンテンツを保持するため、パケットを無効と廃棄する可能性があります。いずれにせよ、パケット内の追加のイベントは失われます。
Section 2.3.5 introduces the possibility of "state" events and defines procedures for setting the duration field for reports of such events. Section 2.5.1.2 defines special exemptions from the setting of the E bit for state events. Three more sections mention procedures related to these events.
セクション2.3.5では、「状態」イベントの可能性を紹介し、そのようなイベントのレポートの期間フィールドを設定する手順を定義します。セクション2.5.1.2は、州イベントのEビットの設定からの特別な免除を定義しています。さらに3つのセクションがこれらのイベントに関連する手順に言及しています。
The Security Considerations section is updated to mention the requirement for protection of integrity. More importantly, it makes implementation of SRTP [7] mandatory for compliant implementations, without specifying a mandatory-to-implement method of key distribution.
セキュリティ上の考慮事項セクションは、完全性の保護要件に言及するために更新されます。さらに重要なことは、重要な分布の義務的な実装方法を指定せずに、準拠の実装にSRTP [7]の実装を必須にすることです。
Finally, this document establishes an IANA registry for event codes and establishes criteria for their documentation. This document provides an initial population for the new registry, consisting solely of the sixteen DTMF events. Two companion documents [16] and [17] describe events related to modems, fax, and text telephony and to channel-associated telephony signalling, respectively. Some changes were made to the latter because of errors and redundancies in the RFC 2833 assignments. The remaining events defined in RFC 2833 are deprecated because they do not appear to have been implemented, but their codes have been conditionally reserved in case any of them is needed in the future. Table 8 indicates the disposition of the event codes in detail. Event codes not mentioned in this table were not allocated by RFC 2833 and continue to be unused.
最後に、このドキュメントはイベントコードのIANAレジストリを確立し、ドキュメントの基準を確立します。このドキュメントは、16のDTMFイベントのみで構成される新しいレジストリの初期集団を提供します。2つのコンパニオンドキュメント[16]と[17]は、それぞれモデム、ファックス、テキストテレフォニー、およびチャネル関連のテレフォニーシグナリングに関連するイベントを説明しています。RFC 2833の割り当てのエラーと冗長性のために、後者にいくつかの変更が加えられました。RFC 2833で定義されている残りのイベントは、実装されていないように見えるため廃止されますが、将来的にはそれらのいずれかが必要である場合に条件付きで条件付きで予約されています。表8は、イベントコードの処分を詳細に示しています。この表に記載されていないイベントコードは、RFC 2833によって割り当てられておらず、引き続き使用されていません。
+-------------+---------------------------------------+-------------+
| Event Codes | RFC 2833 Description | Disposition |
+-------------+---------------------------------------+-------------+
| 0-15 | DTMF digits | RFC 4733 |
| 16 | Line flash (deprecated) | Reserved |
| 23-31 | Unused | [16] |
| 32-40 | Data and fax | [16] |
| 41-48 | Data and fax (V.8bis, deprecated) | Reserved |
| 52-63 | Unused | [16] |
| 64-89 | E.182 line events (deprecated) | Reserved |
| 96-112 | Country-specific line events | Reserved |
| | (deprecated) | |
| 121-127 | Unused | [17] |
| 128-137 | Trunks: MF 0-9 | [17] |
| 138-143 | Trunks: other MF (deprecated) | Reserved |
| 144-159 | Trunks: ABCD signalling | [17] |
| 160-168 | Trunks: various (deprecated) | Reserved |
| 170-173 | Trunks: various (deprecated) | Reserved |
| 174-205 | Unused | [17] |
+-------------+---------------------------------------+-------------+
Table 8: Disposition of RFC 2833-defined Event Codes
表8：RFC 2833定義のイベントコードの処分
Authors' Addresses
著者のアドレス
Henning Schulzrinne Columbia U. Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 US
ヘニングシュルツリンコロンビアU.コンピュータサイエンスコロンビア大学1214アムステルダムアベニューニューヨーク、ニューヨーク10027米国
EMail: schulzrinne@cs.columbia.edu
Tom Taylor Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada
トム・テイラー・ノーテル1852オンタリオ州K1H 6Z8カナダ、ロレイン・アヴェ・オタワ
EMail: taylor@nortel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。