RFC4733 日本語訳
4733 RTP Payload for DTMF Digits, Telephony Tones, and TelephonySignals. H. Schulzrinne, T. Taylor. December 2006. (Format: TXT=115614 bytes) (Obsoletes RFC2833) (Updated by RFC4734, RFC5244) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Schulzrinne
Request for Comments: 4733 Columbia U.
Obsoletes: 2833 T. Taylor
Category: Standards Track Nortel
December 2006
Schulzrinneがコメントのために要求するワーキンググループH.をネットワークでつないでください: 4733 コロンビアU.は以下を時代遅れにします。 2833年のT.テイラーカテゴリ: 標準化過程ノーテル2006年12月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
このメモは二元的なトーン多重周波数(DTMF)合図、他のトーン信号、およびRTPパケットの電話出来事を運ぶ方法を説明します。 それはRFC2833を時代遅れにします。
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.
このメモは、最も基本的なイベントコードだけを得て、RFC2833で定義された基本的な枠組みで広げますが、保有します。 それは他のイベントコード課題が加えられるかもしれないIANA登録をセットアップします。 仲間ドキュメントはモデム、ファックス、テキスト電話、およびチャンネルで関連している合図出来事に関連するこの登録にイベントコードを加えます。 他のドキュメントが彼らの使用を蘇らせるといけないので、RFC2833で定義されたイベントコードの残りは条件付きに予約されます。
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.
このドキュメントは多くの明確化を正本に供給します。 しかしながら、明確に、RFC2833から、要件を取り除くことによって、すべての対応する実現がDTMF出来事を支持するのは異なります。 代わりに、バンドの外でメディア流れの内容の交渉に参加する対応する実現は、それらがどんな出来事を支持するかを示します。 このメモは3つの新しい手順をRFC2833枠組みに追加します: セグメントへの長い出来事の下位区分、単一のパケット、および概念における複数の出来事の報告、および州のイベントの報告。
Schulzrinne & Taylor Standards Track [Page 1] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[1ページ]。
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
1. 序論…4 1.1. 用語…4 1.2. 概観…4 1.3. 潜在的アプリケーション…5 1.4. 出来事(州)はパターン、および声でコード化されたトーンに調子を変えさせます…6 2. 命名された電話出来事のためのRTP有効搭載量形式…8 2.1. 序論…8 2.2. RTPヘッダーフィールドの使用…8 2.2.1. タイムスタンプ…8 2.2.2. マーカーは噛み付きました…8 2.3. 有効搭載量形式…8 2.3.1. イベント分野…9 2.3.2. E(「終わる」)に噛み付きました…9 2.3.3. Rに噛み付きました…9 2.3.4. ボリューム分野…9 2.3.5. 持続時間分野…9 2.4. 任意のメディアはパラメタをタイプします…10 2.4.1. SDPとの関係…10 2.5. 手順…11 2.5.1. 手順を送ります…11 2.5.2. 手順を受けます…16 2.6. 混雑とパフォーマンス…19 2.6.1. パフォーマンス要件…20 2.6.2. 信頼性のメカニズム…20 2.6.3. 混雑に適応します…22 3. 出来事の仕様はDTMFのために出来事をコード化します…23 3.1. DTMFアプリケーション…23 3.2. DTMF出来事…25 3.3. 混雑問題…25 4. 電話のためのRTP有効搭載量形式は調子を変えます…26 4.1. 序論…26 4.2. 一般的な電話に関する例は信号に調子を変えさせます…27 4.3. RTPヘッダーフィールドの使用…27 4.3.1. タイムスタンプ…27 4.3.2. マーカーは噛み付きました…27 4.3.3. 有効搭載量形式…28 4.3.4. 任意のメディアはパラメタをタイプします…29 4.4. 手順…29 4.4.1. 手順を送ります…29 4.4.2. 手順を受けます…30 4.4.3. 混雑の取り扱い…30 5. 例…31 6. セキュリティ問題…38
Schulzrinne & Taylor Standards Track [Page 2] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[2ページ]。
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
7. IANA問題…38 7.1. メディアは登録証明書をタイプします…40 7.1.1. メディアType電話オーディオ/イベントの登録…40 7.1.2. メディアTypeオーディオ/トーンの登録…42 8. 承認…43 9. 参照…43 9.1. 標準の参照…43 9.2. 有益な参照…RFC2833からの変化の44付録A.概要…46
Schulzrinne & Taylor Standards Track [Page 3] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[3ページ]。
1. Introduction
1. 序論
1.1. Terminology
1.1. 用語
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].
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように解釈されることであるべきですか?
This document uses the following abbreviations:
このドキュメントは以下の略語を使用します:
ANSam Answer tone (amplitude modulated) [24]
ANSam Answerトーン(振幅は変調しました)[24]
DTMF Dual-Tone Multifrequency [10]
DTMF二元的なトーン多重周波数[10]
IVR Interactive Voice Response unit
IVR Interactive Voice Responseユニット
PBX Private branch exchange (telephone system)
PBX兵士のブランチ交換(電話)
PSTN Public Switched (circuit) Telephone Network
PSTN公衆は(サーキット)電話網を切り換えました。
RTP Real-time Transport Protocol [5]
RTPのリアルタイムのトランスポート・プロトコル[5]
SDP Session Description Protocol [9]
SDPセッション記述プロトコル[9]
1.2. Overview
1.2. 概観
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.
このメモは、それらの頻度とリズム(セクション4)だけの用語で一般的な多重周波数トーンについて説明するために2つのRTP[5]ペイロード書式、出来事(セクション2)として二元的なトーン多重周波数(DTMF)ケタ、他の線、およびトランク信号を運ぶためのもの、および2番目のものを定義します。 電話トーン信号のための別々の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
このセクションの残りは本書では説明されたペイロードタイプを定義することに関する動機を提供します。 セクション2は命名された出来事の使用のためのペイロード書式と関連手順を定義します。 セクション3はイベントコードが本書では定義される出来事について説明します。 セクション4はトーン表現のためのペイロード形式と関連手順について説明します。 セクション5はコード化された出来事、トーン、および結合したペイロードに関するいくつかの例を提供します。 セクション6はセキュリティ問題に対処します。 セクション7は命名された電話のためにイベントコードの登録のためのIANA要件を定義します。
Schulzrinne & Taylor Standards Track [Page 4] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[4ページ]。
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つのペイロード形式のためのタイプ登録証明書をメディアに提供します。 付録Aは、RFC2833[12]からの変化について説明して、[12]で定義されたイベントコードの気質を特に示します。
1.3. Potential Applications
1.3. 潜在的アプリケーション
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に伝播しなければならないということです。 この1つの例がIVRへのトーンをDTMFに通過するゲートウェイです。 このシナリオでは、トーンの間のくぎりの頻度、振幅、トーン持続時間、および持続時間はすべてかなりです、そして、確かと注文で個々のトーン信号を届けなければなりません。
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
アナログの線において、ダイヤルトーンは地方のスイッチでいつも発生します。 統合Services Digital Network(ISDN)端末は、ダイヤルトーンを局所的に発生させて、次に、ダイヤルされたケタを含むQ.931[22]SETUPメッセージを送るかもしれません。 端末は少しもCalledパーティケタなしでSETUPメッセージをただ送ります、スイッチがケタ収集(端末で、KEYPADの主要なプレスケタ情報として情報メッセージのCalledパーティかKeypad Facility Information Elements(IEs)の中で提供する)をして、ダイヤルトーンを提供するその時
Schulzrinne & Taylor Standards Track [Page 5] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[5ページ]。
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.
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.
呼出音(また、ringbackトーンと呼ばれる)は訪問される人における地方のスイッチで発生します、一方通行の声の経路が訪問される人の電話リングの次第に開けられている状態で。 (これは答えのすぐ後に被呼者の応答を切り取るという可能性を小さくします。 また、それは、プレ答え発表かバンドでの呼び出し進歩指摘が呼出音の前か呼出音の代わりに訪問者に届くことを許可します。) 混雑トーンと特別な情報トーンは、道に沿ってスイッチのどれかで発生できて、ISDN User Partに基づいている(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中継方式」か音声帯域データの場合で時々同じクラスに関する信号を送るでしょう。 アナログ線に役立つエンドシステムのものなどの他の場合には、受け取られたものと異なったクラスに送られた信号があるでしょう。
1.4. Events, States, Tone Patterns, and Voice-Encoded Tones
1.4. 出来事、州、トーンパターン、および声でコード化されたトーン
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つ以上のフォームの合図情報を運ぶのは望ましいかもしれません。
Schulzrinne & Taylor Standards Track [Page 6] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[6ページ]。
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 Recommendation V.152[26]を見てください。 あるいはまた、ファックス、テキスト、またはモデム信号のために、それぞれ、T.38[23]、RFC4103[15]、またはV.150.1モデムリレー[25]などの専門化している輸送は使用されるかもしれません。 最終的に、64個のkbit/sチャンネルが、透明にRFC4040Clearmodeペイロードタイプ[14]を使用することで運ばれるかもしれません。 これらの方法は、現在のドキュメントの範囲の外にありますが、ここで定義されたペイロードタイプと共に使用されるかもしれません。
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. 送付ゲートウェイは、本書では定義されたトーン表現(セクション4)を使用することで単に音声帯域信号の頻度成分を測定して、この情報をRTP受信機に伝えることができます。 このモードで、ゲートウェイは、トーンの意味について明察する試みを全くしませんが、スピーチ信号とトーンを単に区別します。 エンドシステムは、測定されているというよりむしろ構成された頻度を使用することで同じアプローチを使用するかもしれません。
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信号をバンドの外に送信するための唯一の可能な方法です。
Schulzrinne & Taylor Standards Track [Page 7] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[7ページ]。
2. RTP Payload Format for Named Telephone Events
2. 命名された電話出来事のためのRTP有効搭載量形式
2.1. Introduction
2.1. 序論
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ペイロード形式が「電話出来事」として指定されるのをタイプします。 現在の習慣に従って、このペイロード形式は、静的なペイロード形式数を持っていませんが、ダイナミックとバンドの外で確立されたRTPペイロード形式数を使用します。 デフォルトクロック周波数は8000Hzですが、ダイナミックなペイロードタイプを選任するとき、クロック周波数を再定義できます。
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.
命名された電話出来事は、オーディオストリームの一部として運ばれて、ゲートウェイでオーディオ波形の世代を簡素化するのに通常の音声チャンネルとして同じ一連番号とタイムスタンプベースを使用しなければなりません。 命名された電話イベントペイロードタイプは、非常に非常に圧縮されたオーディオコーデックであると考えることができて、同じように他のコーデックとして扱われます。
2.2. Use of RTP Header Fields
2.2. RTPヘッダーフィールドの使用
2.2.1. Timestamp
2.2.1. タイムスタンプ
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.
RTPタイムスタンプで与えるとき、セクション2.5で説明されたイベント持続時間は始まります。 複数のRTPパケットにかかる出来事に関しては、RTPタイムスタンプは出来事の始まりを特定します、すなわち、いくつかのRTPパケットが同じタイムスタンプを運ぶかもしれません。 以下を見てください、セクション2.5。セグメントに分けられなければならない持続的な出来事、(.1 .3、)タイムスタンプはセグメントの始まりを示します。
2.2.2. Marker Bit
2.2.2. マーカービット
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)、最初のセグメントだけで、マーカービットを設定するでしょう。
2.3. Payload Format
2.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 出来事|E|R| ボリューム| 持続時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Payload Format for Named Events
図1: 命名された出来事のための有効搭載量形式
Schulzrinne & Taylor Standards Track [Page 8] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[8ページ]。
2.3.1. Event Field
2.3.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 Considerations、セクション7を見てください)。 この登録の初期の内容はセクション3で定義された出来事から成ります。
2.3.2. E ("End") Bit
2.3.2. E(「終わり」)ビット
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の値に設定されるなら、「終わり」ビットは、このパケットが出来事の終わりを含むのを示します。 以下を見てください、セクション2.5。セグメントに分けられなければならない持続的な出来事、(.1 .3) 最終的なセグメントのための最終的なパケットだけで、Eビットを設定するでしょう。
2.3.3. R Bit
2.3.3. Rビット
This field is reserved for future use. The sender MUST set it to zero, and the receiver MUST ignore it.
この分野は今後の使用のために予約されます。 送付者はゼロにそれを設定しなければなりません、そして、受信機はそれを無視しなければなりません。
2.3.4. Volume Field
2.3.4. ボリューム分野
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〜-63dBm0から変化します。 したがって、より大きい値は下側のボリュームを指示します。 この値はドキュメンテーションがボリュームが適切であることを示す出来事のためだけに定義されます。 他の出来事のために、送付者はゼロにボリュームを設定しなければなりません、そして、受信機は値を無視しなければなりません。
2.3.5. Duration Field
2.3.5. 持続時間分野
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.
ゼロの特別な持続時間値は、すなわち、出来事が「いつまでも」持続するのを示すために予約されているのが、状態であるということであり、アップデートするまで有効であると考えられます。 送付者はそれら以外の出来事のための持続時間が州と定義したゼロを伝えてはいけません。 受信機SHOULDは出来事が状態でないなら持続時間がないイベントレポートを無視します。
Schulzrinne & Taylor Standards Track [Page 9] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[9ページ]。
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.
8000Hzの標本抽出率では、持続時間分野は、最大およそ8秒のイベント持続時間を言い表すために十分です。
2.4. Optional Media Type Parameters
2.4. 任意のメディア型引数
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.
「レート」パラメタは、RTPタイムスタンプとイベント持続時間分野にHertzの標本抽出率について説明して、したがって、ユニットについて説明します。 数は整数として書かれています。 省略されるなら、デフォルト値は8000Hzです。
2.4.1. Relationship to SDP
2.4.1. SDPとの関係
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.
セクション3でSDPへのメディアタイプ任意のパラメタのお勧めのマッピングにRFC3555[6]を与えます。 命名されたイベントペイロードタイプへの「レート」メディア型引数はこのコンベンションに続きます: それはa=rtpmapの<クロックレート>成分としていつものように言い表されます: 線を結果と考えてください。
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.
「出来事」メディア型引数は支持された出来事のリストの前でストリング「出来事=」を省略するのでRFC3555に示されたコンベンションから逸れます。
a=fmtp:<format> <list of values>
a=fmtp: 値の>の<形式><リスト
The list of values has the format and meaning described above.
値のリストには、上で説明された形式と意味があります。
Schulzrinne & Taylor Standards Track [Page 10] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[10ページ]。
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で出来事と定義されたと仮定しますそれぞれ)を扱うことができるなら、SDPメッセージに以下の記述を含んでいるでしょう:
m=audio 12346 RTP/AVP 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15,66,70
m=オーディオの12346RTP/AVP100a=rtpmap: 100 電話出来事/8000a=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"
「電話オーディオ/出来事;出来事=「0-15、66、70インチ; =を評定する」8000」
2.5. Procedures
2.5. 手順
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.
このセクションは命名されたイベントペイロードタイプに関連している手順を定義します。 追加手順は特定のイベントコードに関連しているドキュメンテーションで指定されるかもしれません。
2.5.1. Sending Procedures
2.5.1. 送付手順
2.5.1.1. Negotiation of Payloads
2.5.1.1. 有効搭載量の交渉
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.
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.
Negotiation of payloads between sender and receiver is achieved by out-of-band means, using SDP, for example.
Negotiation of payloads between sender and receiver is achieved by out-of-band means, using SDP, for example.
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.
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.
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
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
Schulzrinne & Taylor Standards Track [Page 11] RFC 4733 Telephony Events and Tones December 2006
Schulzrinne & Taylor Standards Track [Page 11] RFC 4733 Telephony Events and Tones December 2006
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.
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.
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
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.
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.
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.
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.
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
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.
For further discussion of packetization periods see Section 2.6.3.
2.5.1.2. Transmission of Event Packets
2.5.1.2. Transmission of Event Packets
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 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.
Schulzrinne & Taylor Standards Track [Page 12] RFC 4733 Telephony Events and Tones December 2006
Schulzrinne & Taylor Standards Track [Page 12] RFC 4733 Telephony Events and Tones December 2006
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.
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.
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.
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.
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.)
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.)
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.
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.
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.
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.
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 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.
For robustness, the sender SHOULD retransmit "state" events periodically.
For robustness, the sender SHOULD retransmit "state" events periodically.
Schulzrinne & Taylor Standards Track [Page 13] RFC 4733 Telephony Events and Tones December 2006
Schulzrinne & Taylor Standards Track [Page 13] RFC 4733 Telephony Events and Tones December 2006
2.5.1.3. Long-Duration Events
2.5.1.3. Long-Duration Events
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).
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).
2.5.1.3.1. Exceptional Procedure for Combined Payloads
2.5.1.3.1. Exceptional Procedure for Combined Payloads
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:
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:
maximum duration = 0x3FFF - (R-1)*(packetization period in
timestamp units)
maximum duration = 0x3FFF - (R-1)*(packetization period in timestamp units)
where R is the highest redundant layer number consisting of event payload.
where R is the highest redundant layer number consisting of event payload.
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.
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.
2.5.1.4. Retransmission of Final Packet
2.5.1.4. Retransmission of Final Packet
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.
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.
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
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
Schulzrinne & Taylor Standards Track [Page 14] RFC 4733 Telephony Events and Tones December 2006
Schulzrinne & Taylor Standards Track [Page 14] RFC 4733 Telephony Events and Tones December 2006
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.
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.
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).
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.
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.
2.5.1.5. Packing Multiple Events into One Packet
2.5.1.5. Packing Multiple Events into One Packet
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.
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.
This approach is similar to having multiple frames of frame-based audio in one RTP packet.
This approach is similar to having multiple frames of frame-based audio in one RTP packet.
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.
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.
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.
Schulzrinne & Taylor Standards Track [Page 15] RFC 4733 Telephony Events and Tones December 2006
Schulzrinne & Taylor Standards Track [Page 15] RFC 4733 Telephony Events and Tones December 2006
2.5.1.6. RTP Sequence Number
2.5.1.6. RTP Sequence Number
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.
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.
2.5.2. Receiving Procedures
2.5.2. Receiving Procedures
2.5.2.1. Indication of Receiver Capabilities Using SDP
2.5.2.1. Indication of Receiver Capabilities Using SDP
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.
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.
2.5.2.2. Playout of Tone Events
2.5.2.2. Playout of Tone Events
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.
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.
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.
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.
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.
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.
Schulzrinne & Taylor Standards Track [Page 16] RFC 4733 Telephony Events and Tones December 2006
Schulzrinne & Taylor Standards Track [Page 16] RFC 4733 Telephony Events and Tones December 2006
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.
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:
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 it receives a packet with the E bit set;
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 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 it receives an alternative non-event media stream (assuming none
was being received while the event stream was active); or
o it receives an alternative non-event media stream (assuming none was being received while the event stream was active); or
o a given time period elapses.
o a given time period elapses.
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.
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.
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.
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
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
Schulzrinne & Taylor Standards Track [Page 17] RFC 4733 Telephony Events and Tones December 2006
Schulzrinne & Taylor Standards Track [Page 17] RFC 4733 Telephony Events and Tones December 2006
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.
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.
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.
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.
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.
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.
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.
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.
2.5.2.3. Long-Duration Events
2.5.2.3. Long-Duration Events
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.
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.
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.
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.
Schulzrinne & Taylor Standards Track [Page 18] RFC 4733 Telephony Events and Tones December 2006
Schulzrinne & Taylor Standards Track [Page 18] RFC 4733 Telephony Events and Tones December 2006
2.5.2.3.1. Exceptional Procedure for Combined Payloads
2.5.2.3.1. Exceptional Procedure for Combined Payloads
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.
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.
2.5.2.4. Multiple Events in a Packet
2.5.2.4. Multiple Events in a Packet
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.
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.2.5. Soft States
2.5.2.5. Soft States
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.
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.
2.6. Congestion and Performance
2.6. Congestion and Performance
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.
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.
Schulzrinne & Taylor Standards Track [Page 19] RFC 4733 Telephony Events and Tones December 2006
Schulzrinne & Taylor Standards Track [Page 19] RFC 4733 Telephony Events and Tones December 2006
2.6.1. Performance Requirements
2.6.1. Performance Requirements
Typically, an implementation of the telephone-event payload will aim to limit the rate at which each of the following impairments occurs:
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. 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;
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. 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;
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. the duration of playout of a given event differs from the correct duration as detected at the sender by more than a given amount;
d. gaps occur in playout of a given event;
d. gaps occur in playout of a given event;
e. end-to-end delay for the media stream exceeds a given value.
e. end-to-end delay for the media stream exceeds a given value.
The relative importance of these constraints varies between applications.
The relative importance of these constraints varies between applications.
2.6.2. Reliability Mechanisms
2.6.2. Reliability Mechanisms
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.
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.
The named event procedures provide two complementary redundancy mechanisms to deal with lost packets:
The named event procedures provide two complementary redundancy mechanisms to deal with lost packets:
a. Intra-event updates:
a. Intra-event updates:
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.
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.
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
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
Schulzrinne & Taylor Standards Track [Page 20] RFC 4733 Telephony Events and Tones December 2006
Schulzrinne & Taylor Standards Track [Page 20] RFC 4733 Telephony Events and Tones December 2006
packetization interval of 50 ms, two packets in a row can get
lost without causing a premature end of the tone generated.
packetization interval of 50 ms, two packets in a row can get lost without causing a premature end of the tone generated.
b. Repeat last event packet:
b. Repeat last event packet:
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.
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.
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.
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.
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.
また、それをある.4が示すセクション2.5.1が最終的なイベントレポートの「再-トランスミッション」を運ぶためにRFC2198[2]オーディオ冗長メカニズムを使用に当てるところでは、このメカニズムは、最終報告書「再-トランスミッション」の数を広げるのに使用されるかもしれません。 必要であるときに2つ以上のレベルの冗長を使用することによって、これをします。 RFC2198の使用は、単に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)).
再生アルゴリズムは、性能必要条件を満たすための追加メカニズムです。 セクション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
最終的に、送付者によって費やされたpacketizationの期間と、受信機によって使用される再生遅れと、パケット損失へのイベント流動の脆弱性との相互作用があります。 パケット損失が独立していると仮定して、より短いpacketization間隔はそれを意味します。
Schulzrinne & Taylor Standards Track [Page 21] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[21ページ]。
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.
異なった信頼性のメカニズムの間の見返りから見て、特定のイベントSHOULDのドキュメンテーションはそれらの出来事のアプリケーションのための適切なデザイン決定の議論を含んでいます。 この命令はIANA問題のセクションで繰り返されます。
2.6.3. Adjusting to Congestion
2.6.3. 混雑に適応します。
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.
今までのところ、議論はミーティング性能要件に関するものです。 しかしながら、また、混雑の間ネットワークで彼らの要求を抑えるという出来事のアプリケーションが肝心の混雑に順応できるかどうかに関する質問があります。 理論上、出来事のためにpacketization間隔を増加させることによって、これができます、1秒単位で、より少ないパケットを送るように。 これは犠牲者の増加する再生遅れによって伴われなければなりません。 本来2つの終わりの間のコーディネートはこのためにおもしろい問題です。 しかしながら、完了しているなら、packetization間隔が最初に延ばされるとき、そのような動作は出来事の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.
主として扱われる出来事の平均した持続時間によって、そのような測定からの利益は異なります。 最悪の場合には、最初の例が示すように増加するpacketization間隔による集合帯域幅用法の減少はかなり穏やかであるかもしれません。 平均したイベント持続時間が3.33ms(例えば、V.21ビット)であると仮定してください。 与えられたイベントレポートが損失目的を満たすのに合計で4個のトランスミッションが必要であるとさらに仮定してください。 テーブル1はメディアの流れの集合ビット伝送速度の異なったpacketization間隔の衝撃を示しています。
+--------------------+-----------+---------------+------------------+ | 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 | +--------------------+-----------+---------------+------------------+
+--------------------+-----------+---------------+------------------+ | Packetization| パケット/s| IPパケット| 総IPビット| | 間隔(ms)| | サイズ(ビット)| レート(ビット/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レベルにおけるデータ信号速度対Packetization間隔(3個の「再-トランスミッション」、1出来事あたり3.33ms)
Schulzrinne & Taylor Standards Track [Page 22] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[22ページ]。
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.
見ることができるように、間隔(25〜50ms)の倍増は25msで終わりから終わりへの遅れを増加させて、同じ量の1回のギャップを引き起こしている間、集合ビット伝送速度をおよそ20%落とします。 特定のV.21トーン出来事の再生を広げるのは、論外であり、そうはセクション2.5の最初のアルゴリズムです。(.2 .2 このアプリケーションで使用しなければならない、) パケットサイズの増加で、より長いpacketizationの期間がある秒あたりのパケットの数の減少は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.
より長い持続時間の出来事に関しては、帯域幅での減少はpacketization間隔の増加により比例しています。 また、最終的なイベントレポートの損失もそれほど批判的でないかもしれないので、下側の冗長レベルは許容しています。 Tableへの同様のデータに1を示しますが、テーブル2はイベント落成のために基本的な2「再-トランスミッション」だけで沈黙(理想化されたDTMFベースのテキスト・メッセージングセッションのように)の50msによって切り離された出来事を仮定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 | +--------------------+-----------+---------------+------------------+
+--------------------+-----------+---------------+------------------+ | Packetization| パケット/s| IPパケット| 総IPビット| | 間隔(ms)| | サイズ(ビット)| レート(ビット/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レベルにおけるデータ信号速度対Packetization間隔(2個の「再-トランスミッション」、1出来事あたり70ms、出来事の間の50ms)
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.
また、前の出来事が含まれているとき、1回の出来事だけが報告されて、520ビットであるときに、テーブルの第3桁では、パケットサイズは448ビットです。 1つ未満のレベルの冗長が50msのpacketization間隔まで必要です、ほとんどのパケットがその時、2つの出来事を報告しますが。 より長い間隔は少なくともいくつかのパケットで第2のレベルの冗長を必要とします。
3. Specification of Event Codes for DTMF Events
3. DTMF出来事のためのイベントコードの仕様
This document defines one class of named events: DTMF tones.
このドキュメントは1つのクラスの命名された出来事を定義します: DTMFは調子を変えます。
3.1. DTMF Applications
3.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ネットワークにおけるゲートウェイかアプリケーション・サーバーなどの実体、またはサーキット交換網の電話スイッチかIVRsなどの実体によって消費されるかもしれません。
Schulzrinne & Taylor Standards Track [Page 23] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[23ページ]。
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ペイロードを送ります。 ゲートウェイには、必要なディジタル信号プロセッサとアルゴリズムがおそらくあります、しばしばDTMFを検出するのが必要であるときに、例えば、2ステージのダイヤルするために。 ゲートウェイにトーンを検出させるのが、この仕事をしなければならないので受信インターネットエンドシステムを救って、また、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 Recommendation Q.24[11](Table A-1)は、国のスイッチ装置が調査した遺産が40msに関する信号の間国の2番目に、よるのあたり8〜10ケタの最大の合図レート40ms、ミニマム・ポーズの最小の認識可能な信号持続時間を予想するのを示します。 一般に、それらの間には、より大きいくぎりがある状態で、人間が発生している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
また、DTMFトーンはテキスト電話に使用されるかもしれません。 このアプリケーションはITU-T Recommendation V.18[27]別館B.に記録されます。In本件、どちらの終わり(ハーフデュプレックスモード)にも交互にDTMFを送ります、最小の300-msターンアラウンドタイムで。 このアプリケーションにおけるトーン持続時間における唯一の規制はそれらの間のそれらとくぎりが指定された最小の値を超えなければならないということです。 送信側のゲートウェイが指定されるとしてのV.18 Annex B(40>=msの調子を変えて、ポーズします)によるDTMF信号を検出できますが、発信するはずであるのは、RECOMMENDEDです。
Schulzrinne & Taylor Standards Track [Page 24] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[24ページ]。
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.
V.18 DTMF送付者(70>=ms、くぎりの50>=msに調子を変えさせる)のものに対応するイベント持続時間。 時折外向的な出来事のバッファリングをいくらかの含意するかもしれませんが、ソース端末がV.18 Annex 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出来事を変換しているアプリケーションをトーンに受け取って戻して、SHOULDは.2にセクション2.5.2における最初のものよりむしろ2番目の再生アルゴリズムを使用します。 これはパケット損失か混雑に対して何らかの丈夫さを提供します。
3.2. DTMF Events
3.2. DTMF出来事
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 |
+-------+--------+------+---------+
+-------+--------+------+---------+ | 出来事| コード| タイプ| ボリューム? | +-------+--------+------+---------+ | 0--9 | 0--9 | トーン| はい| | * | 10 | トーン| はい| | # | 11 | トーン| はい| | A--D| 12--15 | トーン| はい| +-------+--------+------+---------+
Table 3: DTMF Named Events
テーブル3: 出来事というDTMF
3.3. Congestion Considerations
3.3. 混雑問題
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トーンがテキスト電話に使用されている特別なケース中以外の主要な考慮ではありません。 .2が使用中であることを上のセクション3.1、セクション2.5.2の2番目の再生アルゴリズムで推薦するのでそれを仮定する場合、どれがさらに少ないかなら、最大100msへのpacketization間隔か正常な間隔の二重の一時的増加は無害であるべきです。
Schulzrinne & Taylor Standards Track [Page 25] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[25ページ]。
4. RTP Payload Format for Telephony Tones
4. 電話トーンのためのRTP有効搭載量形式
4.1. Introduction
4.1. 序論
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:
ダイヤルトーンなどの電話トーンのためのどんなただ一つの世界規格もありません、(ringback)を鳴らして、忙しいです、混雑(「忙し速いい」)、特別な発表トーン、または、公衆電話認識、キャッチホンまたは記録などの他の特別なトーンのいくつかが調子を変えます。 しかしながら、ITU-T Recommendation 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 電話出来事のためのバンドにおけるトーンが25Hz(アンゴラの呼出音)から2600Hz(SS No.5とR1での線合図に使用されるトーン)の範囲にあります。 バンドにおける電話周波数区域は3400Hzに制限されます。 R2はアナログトランクスの上の線合図のために3825Hzのバンドで出ているトーンを定義します。 (ピアノには、27.5〜4186Hzの範囲があります。)
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は調子を変える)の間で480Hz(ジャマイカ)に及びます。 非整数頻度は16 2/3と33 1/3Hzの頻度にだけ使用されます。
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 Recommendation E.180[18]は、異なった電話会社が0.5〜1.5%のトーン精度を必要とすることに注意します。 Recommendationは1%の周波数公差を勧めます。
Schulzrinne & Taylor Standards Track [Page 26] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[26ページ]。
4.2. Examples of Common Telephone Tone Signals
4.2. 一般的な電話トーン信号に関する例
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.
作成者への援助として、Table4はいくつかの一般的なトーンをまとめます。 「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 | +-------------------------+-------------------+----------+----------+
+-------------------------+-------------------+----------+----------+ | トーン名| 頻度| 時に| 時間で| | | | (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ビット| または980か1180。| 0.00333 | -- | | | 1650か1850| | | | ------------- | ---------- | -------- | -------- | | ITUダイヤルトーン| 425 | -- | -- | | 米国ダイヤルトーン| 350+440 | -- | -- | | ITU呼出音| 425 | 0.67-1.5 | 3-5 | | 米国呼出音| 440+480 | 2.0 | 4.0 | | ITU話中音| 425 | 0.1-0.6 | 0.1-0.7 | | 米国話中音| 480+620 | 0.5 | 0.5 | | ITU混雑トーン| 425 | 0.1-0.6 | 0.1-0.7 | | 米国混雑トーン| 480+620 | 0.25 | 0.25 | +-------------------------+-------------------+----------+----------+
Table 4: Examples of Telephony Tones
テーブル4: 電話トーンに関する例
4.3. Use of RTP Header Fields
4.3. RTPヘッダーフィールドの使用
4.3.1. Timestamp
4.3.1. タイムスタンプ
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で説明されたイベント持続時間はその時、始まります。
4.3.2. Marker Bit
4.3.2. マーカービット
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パケットを区別するのにマーカービットを使用します。 SHOULDが最初のパケットのための1に設定されて、同じように関連している続くすべてのパケットのための0マーカービットは調子を変えます。
Schulzrinne & Taylor Standards Track [Page 27] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[27ページ]。
4.3.3. Payload Format
4.3.3. 有効搭載量形式
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ペイロード書式を定義します。 (対応するメディアタイプは「オーディオ/トーン」です。) デフォルトタイムスタンプレートは8000Hzですが、他のレートは定義されるかもしれません。 タイムスタンプレートが頻度、まさしく持続時間の解釈に影響しないことに注意してください。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
......
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 変調|T| ボリューム| 持続時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R R R R| 頻度|R R R R| 頻度| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R R R R| 頻度|R R R R| 頻度| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R R R R| 頻度|R R R R| 頻度| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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の変調頻度。 分野は最大511Hzを変調頻度に許容する9ビットの符号のない整数です。 変調が全くなければ、この分野には、ゼロの値があります。 変調の振幅がペイロードで示されないで、バンドの外による決定している手段であるに違いないことに注意してください。
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/3Hzなどの変調頻度があるので、このビットは1/3Hzに正確な頻度を許容します。
Schulzrinne & Taylor Standards Track [Page 28] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[28ページ]。
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.)
ボリューム: 0〜-63dBm0から範囲があるサインを落とした後にdBm0で言い表されたトーンのパワーレベル。 (注意: デジタル音声発振器のための都合のよい平らな範囲は-3dBm0への-8dBm0です。)
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.
持続時間: タイムスタンプユニットで測定されて、ネットワークバイトオーダーで提示されたトーンの持続時間。 トーンは、RTPタイムスタンプによって特定された瞬間に始まって、持続時間値のために持続します。 ゼロの値は、受入れられないで、そのような持続時間SHOULDが無視されている状態で、調子を変えます。
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ビットの符号のない整数として表されるべきトーンの頻度。 分野サイズは頻度を4095Hzまで表すことができます。(Hzは電話の範囲を超えています)。ゼロの値は沈黙を示します。 シングル・トーンはいろいろな頻度を含むことができます。 頻度が全く指定されないなら、パケットは沈黙の期間を報告します。
R:
This field is reserved for future use. The sender MUST set it to
zero, and the receiver MUST ignore it.
R: この分野は今後の使用のために予約されます。 送付者はゼロにそれを設定しなければなりません、そして、受信機はそれを無視しなければなりません。
4.3.4. Optional Media Type Parameters
4.3.4. 任意のメディア型引数
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で標本抽出率について説明します。 数は整数として書かれています。 省略されるなら、デフォルト値は8000Hzです。
4.4. Procedures
4.4. 手順
This section defines the procedures associated with the tone payload type.
このセクションはトーンペイロードタイプに関連している手順を定義します。
4.4.1. Sending Procedures
4.4.1. 送付手順
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.
送付者は、トーンが認識されるとすぐに、初期のトーンパケットを送るか、またはあらかじめ交渉されたpacketizationの期間が経過するまで、待つかもしれません。 SHOULDがマーカービットに1に設定させるトーンのための最初のRTPパケット。
Schulzrinne & Taylor Standards Track [Page 29] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[29ページ]。
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.
より長い持続時間トーンの場合では、送付者SHOULDは同じトーン例のために複数のRTPパケットを発生させます。 発生する各パケットのためにRTPタイムスタンプをアップデートしなければなりません(運んで、対照的に、例えば、パケットのためのタイムスタンプに、出来事に電話をしてください)。 同じトーンSHOULDのためのその後のパケットでマーカービットを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パケットは発生するかもしれません、最新のpacketizationの期間、経過するのを待たない。
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で説明された電話イベントペイロードは本来余分です、同じ出来事のための後のパケットがボリュームの変化以外の出来事の以前の歴史のすべてを運ぶので。 対照的に、トーンペイロードタイプのための各パケットは単独で立ちます。 無くなっているパケットは犠牲者に利用可能な情報のギャップを意味します。 したがって、増加する信頼性のために、送付者SHOULDは、同じRTPパケットでRFC2198[2]オーディオ冗長を使用することで新しくて古いトーンレポートを結合します。
4.4.2. Receiving Procedures
4.4.2. 手順を受けます。
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パケットのものの隣接です、そして、ペイロード内容は同じである)のための連続したトーンレポートを展開するとき、受信実現SHOULDは変化も中断なしでトーンを続けています。
4.4.3. Handling of Congestion
4.4.3. 混雑の取り扱い
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受信機レポートを通した)のため失われていて、それは初期の、そして、当座のトーンのためのpacketization間隔が交通量を受信機に変えるために報告するSHOULD増加です。これが犠牲者にダメージが大きい結果を引き起こさないで可能である程度はその終わりに使用された再生遅れと、そして、トーンに関連している特定のアプリケーションに依存します。 したがって、いかなる時もともに、packetization間隔の最大のpacketization間隔と最大の増加が構成かアウトの問題である、-、バンド交渉について。
Schulzrinne & Taylor Standards Track [Page 30] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[30ページ]。
5. Examples
5. 例
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を考えてください。そうすれば、送付ゲートウェイはそれらを検出します。 最初のケタは、長い間(1600タイムスタンプユニット)の200msであり、時0に始まります。 2番目のケタは、250ms(2000タイムスタンプユニット)を持続して、時間880ms(7040タイムスタンプユニット)で始まります。 3番目のケタは、時に1.4秒間(1万1200タイムスタンプユニット)押されて、220ms(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、1時のRTP一連番号で始まると思われて、ボリューム設定は忘れられます。
+-------+-----------+------+--------+------+--------+--------+------+ | 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 | | | | | | |
+-------+-----------+------+--------+------+--------+--------+------+ | 時間| 出来事| M| 時間| Seq| 出来事| 硬膜| E| | (ms) | | ビット| スタンプ| いいえ| コード| tion| ビット| +-------+-----------+------+--------+------+--------+--------+------+ | 0 | "9" | | | | | | | | | 始め| | | | | | | | 50 | RTP| "1" | 0 | 1 | 9 | 400 | "0" | | | パケット1| | | | | | | | | 発信します。| | | | | | | | 100 | RTP| "0" | 0 | 2 | 9 | 800 | "0" | | | パケット2| | | | | | | | | 発信します。| | | | | | | | 150 | RTP| "0" | 0 | 3 | 9 | 1200 | "0" | | | パケット3| | | | | | | | | 発信します。| | | | | | | | 200 | RTP| "0" | 0 | 4 | 9 | 1600 | "0" | | | パケット4| | | | | | | | | 発信します。| | | | | | | | 200 | 「9インチは終わります」| | | | | | | | 250 | RTP| "0" | 0 | 5 | 9 | 1600 | "1" | | | パケット4| | | | | | | | | 1番目| | | | | | | | | retrans| | | | | | | | | 任務| | | | | | | | 300 | RTP| "0" | 0 | 6 | 9 | 1600 | "1" | | | パケット4| | | | | | | | | 2番目| | | | | | | | | retrans| | | | | | | | | 任務| | | | | | | | 880 | まず最初に、「1インチ」| | | | | | | | | 始め| | | | | | |
Schulzrinne & Taylor Standards Track [Page 31] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[31ページ]。
| 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 | | | | | | | +-------+-----------+------+--------+------+--------+--------+------+
| 930 | RTP| "1" | 7040 | 7 | 1 | 400 | "0" | | | パケット5| | | | | | | | | 発信します。| | | | | | | | ... | ... | ... | ... | ... | ... | ... | ... | | 1130 | RTP| "0" | 7040 | 11 | 1 | 2000 | "0" | | | パケット9| | | | | | | | | 発信します。| | | | | | | | 1130 | まず最初に、「1インチ」| | | | | | | | | 終わり| | | | | | | | 1180 | RTP| "0" | 7040 | 12 | 1 | 2000 | "1" | | | パケット9| | | | | | | | | 1番目| | | | | | | | | retrans| | | | | | | | | 任務| | | | | | | | 1230 | RTP| "0" | 7040 | 13 | 1 | 2000 | "1" | | | パケット9| | | | | | | | | 2番目| | | | | | | | | retrans| | | | | | | | | 任務| | | | | | | | 1400 | 2番目| | | | | | | | | "1" | | | | | | | | | 始め| | | | | | | | 1450 | RTP| "1" | 11200 | 14 | 1 | 400 | "0" | | | パケット10| | | | | | | | | 発信します。| | | | | | | | ... | ... | ... | ... | ... | ... | ... | ... | | 1620 | 2番目| | | | | | | | | 「1インチは終わります」| | | | | | | | 1650 | RTP| "0" | 11200 | 18 | 1 | 1760 | "1" | | | パケット14| | | | | | | | | 発信します。| | | | | | | | 1700 | RTP| "0" | 11200 | 19 | 1 | 1760 | "1" | | | パケット14| | | | | | | | | 1番目| | | | | | | | | retrans| | | | | | | | | 任務| | | | | | | | 1750 | RTP| "0" | 11200 | 20 | 1 | 1760 | "1" | | | パケット14| | | | | | | | | 2番目| | | | | | | | | retrans| | | | | | | | | 任務| | | | | | | +-------+-----------+------+--------+------+--------+--------+------+
Table 5: Example of Event Reporting
テーブル5: イベント報告に関する例
Schulzrinne & Taylor Standards Track [Page 32] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[32ページ]。
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
+-------+-----------+-----+--------+------+--------+-------+--------+ | 時間| 出来事| M| 時間| Seq| 硬膜| Freq1| Freq2| | (ms) | | ビット| スタンプ| いいえ| tion| (Hz) | (Hz) | +-------+-----------+-----+--------+------+--------+-------+--------+ | 0 | "9" | | | | | | | | | 始め| | | | | | | | 50 | RTP| "1" | 0 | 1 | 400 | 852 | 1477 | | | パケット1| | | | | | | | | 発信します。| | | | | | | | 100 | RTP| "0" | 400 | 2 | 400 | 852 | 1477 | | | パケット2| | | | | | | | | 発信します。| | | | | | | | ... | ... | ... | ... | ... | ... | ... | ... | | 200 | RTP| "0" | 1200 | 4 | 400 | 852 | 1477 | | | パケット4| | | | | | | | | 発信します。| | | | | | | | 200 | 「9インチは終わります」| | | | | | | | 880 | まず最初に、「1インチ」| | | | | | | | | 始め| | | | | | | | 930 | RTP| "1" | 7040 | 5 | 400 | 697 | 1209 | | | パケット5| | | | | | | | | 発信します。| | | | | | | | 980 | RTP| "0" | 7440 | 6 | 400 | 697 | 1209 | | | パケット6| | | | | | | | | 発信します。| | | | | | | | ... | ... | ... | ... | ... | ... | ... | ... | | 1130 | まず最初に、「1インチ」| | | | | | | | | 終わり| | | | | | | | 1400 | 2番目| | | | | | | | | "1" | | | | | | | | | 始め| | | | | | | | 1450 | RTP| "1" | 11200 | 10 | 400 | 697 | 1209 | | | パケット10| | | | | | | | | 発信します。| | | | | | | | ... | ... | ... | ... | ... | ... | ... | ... | | 1620 | 2番目| | | | | | | | | 「1インチは終わります」| | | | | | | | 1650 | RTP| "0" | 12800 | 14 | 160 | 697 | 1209 | | | パケット14| | | | | | | | | 発信します。| | | | | | | +-------+-----------+-----+--------+------+--------+-------+--------+ テーブル6: トーン報告に関する例
Schulzrinne & Taylor Standards Track [Page 33] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[33ページ]。
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タイムスタンプがいつも進むことを意味します。 推論として、同じ量に従って、RFC2198ヘッダーのイベントペイロードのために相殺されたタイムスタンプは増加します。
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.
すべて下の数字は「上記の14インチがテーブルの上に置くRTPパケット」を例証します。 Table5に対応している、図3はイベントだけペイロードを示しています。 Table6に対応している、図4はトーンだけペイロードを示しています。 最終的に、図5はただ一つの余分な層としてトーン予備選挙と出来事に伴う結合したペイロードを示しています。 結合したペイロードにはTable5に示された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
m=オーディオの12344RTP/AVP99a=rtpmap: 99G729/8000 a=ptime: 20m=オーディオの12346RTP/AVP100a=rtpmap: 100電話出来事/8000a=fmtp: 100 0-15a=ptime: 50
Schulzrinne & Taylor Standards Track [Page 34] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[34ページ]。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 太平洋標準時| 一連番号| | 2 |0|0| 0 |0| 100 | 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| | 11200 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| | 0x5234a8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 出来事|E R| ボリューム| 持続時間| | 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
m=オーディオの12344RTP/AVP99a=rtpmap: 99G729/8000 a=ptime: 20m=オーディオの12346RTP/AVP101a=rtpmap: 101トーン/8000a=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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 太平洋標準時| 一連番号| | 2 |0|0| 0 |0| 101 | 14 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| | 12800 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| | 0x5234a8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 変調|T| ボリューム| 持続時間| | 0 |0| 20 | 160 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R R R R| 頻度|R R R R| 頻度| |0 0 0 0| 697 |0 0 0 0| 1209 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Example RTP Packet for Tone Payload
図4: トーン有効搭載量のための例のRTPパケット
Schulzrinne & Taylor Standards Track [Page 35] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[35ページ]。
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
m=オーディオの12344RTP/AVP99a=rtpmap: 99G729/8000 a=ptime: 20m=オーディオの12346RTP/AVP102 101 100a=rtpmap: 102赤/8000/1a=fmtp: 102 101/100a=rtpmap: 101トーン/8000a=rtpmap: 100電話出来事/8000a=fmtp: 100 0-15a=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ビットの境界で始まるかのように実際のペイロードを贈ります。 実際のパケットでは、それらは、2198年のRFCヘッダーの端直後続いて、その結果、連続した単語への1つの置き換えられた八重奏です。
Schulzrinne & Taylor Standards Track [Page 36] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[36ページ]。
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 | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 太平洋標準時| 一連番号| | 2 |0|0| 0 |0| 102 | 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| | 12800 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| | 0x5234a8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| 太平洋標準時のブロック| タイムスタンプオフセット| ブロック長| |1| 100 | 1600 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| 太平洋標準時のブロック| イベントペイロードは始まります… / |0| 101 | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Event payload
イベントペイロード
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event |E R| volume | duration |
| 1 |1 0| 20 | 1760 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 出来事|E R| ボリューム| 持続時間| | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 変調|T| ボリューム| 持続時間| | 0 |0| 20 | 160 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R R R R| 頻度|R R R R| 頻度| |0 0 0 0| 697 |0 0 0 0| 1209 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example RTP Packet for Combined Tone and Event Payloads
図5: 結合したトーンとイベント有効搭載量のための例のRTPパケット
Schulzrinne & Taylor Standards Track [Page 37] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[37ページ]。
6. Security Considerations
6. セキュリティ問題
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パケットはRTP仕様で議論したセキュリティ問題を受けることがある、(RFC3550[5])、(例えば、RFC3551[13])。 RFC3550議論は秘密性のための要件に焦点を合わせます。 実現に関連する追加担保問題がRFC2198[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.
この仕様に基づき定義された電話イベントペイロードは非常に圧縮されます。 ちょうど1ビットの価値における変化は受信機で解読されるように意味における大きな変化をもたらすことができます。その結果、電話イベントペイロードタイプにメッセージの保全を提供しなければなりません。
To meet the need for protection both of confidentiality and integrity, compliant implementations SHOULD implement the Secure Real-time Transport Protocol (SRTP) [7].
秘密性と保全の保護の需要を満たすために、言いなりになっている実現SHOULDはSecureレアル-時間Transportプロトコル(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.
ゲートウェイデザインが強健で、低いオーバーヘッドのトーン世代を含んでいれば、パケット処理が潜在的サービスの否定の脅威を引き起こすように、このペイロードタイプは受信機サイド計算量における少しの重要な非の一様性も示しません。
7. IANA Considerations
7. IANA問題
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に出来事を登録しなければなりません。 登録証明書はRFC2434[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. 既存のイベントコードと、ことによるとイベント定義の何らかの小さい方の変更は出来事を表すことができません。
Schulzrinne & Taylor Standards Track [Page 38] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[38ページ]。
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.
専門家はイベントコードの配分のときに提案された出来事に指導を提供するのにさらに責任感が強いです。 明確に、専門家は、1つが何か新しいドキュメントでRFC2833で定義されましたが、指定しなかったように出来事が同じであるように見えるかどうかを示さなければなりません。 この場合、イベントコードはRFC2833でそのイベントSHOULDに指定しました。提案された出来事に割り当てられます。 さもなければ、以下に記載された利用可能なイベントコードのセットからイベントコードを割り当てなければなりません。 このセットが消耗しているなら、予約されたイベントコードからの課題のための評価基準は最初に新しい仕様にそれらのRFC2833意味で蘇るという最も低い確率を持っているように見えるものを割り当てることです。
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、特定の出来事のドキュメンテーションで議論した異なった信頼性のメカニズムの間の見返りから見て、SHOULDはそれらの出来事のアプリケーションのための適切なデザイン決定の議論を含んでいます。
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まで及びます。 初期の登録内容は、Table7に示されて、このドキュメントのセクション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 コードは[17]で定義された出来事のために121-137に174-205に予約されます。
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はまず2833年の対応するRFC出来事を蘇らせる仕様、および他のすべてのコードを割り当ててある後に一般的な課題のための2番目の例で予約されます。
Schulzrinne & Taylor Standards Track [Page 39] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[39ページ]。
+------------+--------------------------------+-----------+
| 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 |
+------------+--------------------------------+-----------+
+------------+--------------------------------+-----------+ | イベントコード| イベント名| 参照| +------------+--------------------------------+-----------+ | 0 | DTMF、ケタ「0インチ」| RFC4733| | 1 | DTMF、ケタ「1インチ」| RFC4733| | 2 | DTMF、ケタ「2インチ」| RFC4733| | 3 | DTMF、ケタ「3インチ」| RFC4733| | 4 | DTMF、ケタ「4インチ」| RFC4733| | 5 | DTMF、ケタ「5インチ」| RFC4733| | 6 | DTMF、ケタ「6インチ」| RFC4733| | 7 | DTMF、ケタ「7インチ」| RFC4733| | 8 | DTMF、ケタ「8インチ」| RFC4733| | 9 | DTMF、ケタ「9インチ」| RFC4733| | 10 | DTMFケタ「*」| RFC4733| | 11 | DTMFケタ「#」| RFC4733| | 12 | DTMFケタ「A」| RFC4733| | 13 | DTMFケタ「B」| RFC4733| | 14 | DTMFケタ「C」| RFC4733| | 15 | DTMFケタ「D」| RFC4733| +------------+--------------------------------+-----------+
Table 7: audio/telephone-event Event Code Registry
テーブル7: 電話オーディオ/イベントEvent Code Registry
7.1. Media Type Registrations
7.1. メディアは登録証明書をタイプします。
7.1.1. Registration of Media Type audio/telephone-event
7.1.1. メディアType電話オーディオ/イベントの登録
This registration is done in accordance with [6] and [8].
[6]と[8]によると、この登録をします。
Type name: audio
型名: オーディオ
Subtype name: telephone-event
Subtypeは以下を命名します。 電話出来事
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トーン)のサポートは想定されます。
Schulzrinne & Taylor Standards Track [Page 40] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[40ページ]。
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で標本抽出率について説明します。 数は整数として書かれています。 省略されるなら、デフォルト値は8000Hzです。
Encoding considerations:
問題をコード化します:
In the terminology defined by [8] section 4.8, this type is framed
and binary.
[8] セクション4.8によって定義された用語では、このタイプは、縁どられて2進です。
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.
マジックナンバー(s): なし。 ファイル拡張子(s): なし。 マッキントッシュファイルタイプは(s)をコード化します: なし。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
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:
コントローラを変えてください:
IETF Audio/Video Transport Working Group as delegated from the
IESG.
IESGから代表として派遣されるIETF Audio/ビデオTransport作業部会。
Schulzrinne & Taylor Standards Track [Page 41] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[41ページ]。
7.1.2. Registration of Media Type audio/tone
7.1.2. メディアTypeオーディオ/トーンの登録
This registration is done in accordance with [6] and [8].
[6]と[8]によると、この登録をします。
Type name: audio
型名: オーディオ
Subtype name: tone
Subtypeは以下を命名します。 トーン
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で標本抽出率について説明します。 数は整数として書かれています。 省略されるなら、デフォルト値は8000Hzです。
Encoding considerations:
問題をコード化します:
In the terminology defined by [8] section 4.8, this type is framed
and binary.
[8] セクション4.8によって定義された用語では、このタイプは、縁どられて2進です。
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.
マジックナンバー(s): なし。 ファイル拡張子(s): なし。 マッキントッシュファイルタイプは(s)をコード化します: なし。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
Tom Taylor, taylor@nortel.com.
IETF AVT Working Group.
トム・テイラー、 taylor@nortel.com 。 IETF AVT作業部会。
Intended usage: COMMON.
意図している用法: 一般的。
Schulzrinne & Taylor Standards Track [Page 42] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[42ページ]。
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:
コントローラを変えてください:
IETF Audio/Video Transport Working Group as delegated from the
IESG.
IESGから代表として派遣されるIETF Audio/ビデオTransport作業部会。
8. Acknowledgements
8. 承認
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.
スコットPetrackはRFC2833の原作者でした。 ヘニングSchulzrinneは後でドキュメントを完成するために彼の専門的技術を貸与しましたが、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.
RFC2833では、Megacoワーキンググループの提案は承諾されました。 コリン・パーキンスとマグヌスWesterland(AVT作業部会のChairs)は現在のドキュメントの構成における有益な助言を提供しました。 数年間、詳細なアドバイスとRFC2833のためのコメントか、このドキュメントか、両方がHisham Abdelhamid、フレミングAndreasen、フレッドBurg、スティーブCasner、ダンDeliberato、ファティーErdin、ビル・フォスター、マイクフォックス、Mehryar Garakani、グナー・ヘルストリョーム、ラジェッシュ・クマー、テリー・リヨン、スティーブMagnell、Zarkoマルコフ、ティムMelanchuk、カイ・ミャオ、サティシュMundra、ケビン・ノル、バーン・パクソン、オレンPeleg、Raghavendra Prabhu、モシェSamoha、トッドSherer、エードリアンSoncodi、Yaakovシタイン、ミラStevanovic、アレックスUrquizo、およびHerb Wildfeurによって提供されました。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ-ガルシア、A.、およびS.堀-Parisis、「余分なオーディオデータのためのRTP有効搭載量」、RFC2198(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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
Schulzrinne & Taylor Standards Track [Page 43] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[43ページ]。
[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]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[6] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
[6]CasnerとS.とP.Hoschka、「RTP有効搭載量形式のMIMEの種類登録」、RFC3555、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.
2004年の[7]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[8] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
解放された[8]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
[9] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[9] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[10] International Telecommunication Union, "Technical features of
push-button telephone sets", ITU-T Recommendation Q.23,
November 1988.
[10] 国際電気通信連合、「プッシュホンセットに関する技術的特徴」、ITU-T Recommendation Q.23、1988年11月。
[11] International Telecommunication Union, "Multifrequency push-
button signal reception", ITU-T Recommendation Q.24,
November 1988.
[11] 国際電気通信連合、「多重周波数がボタンの信号レセプションを押す」ITU-T Recommendation Q.24、1988年11月。
9.2. Informative References
9.2. 有益な参照
[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有効搭載量」、RFC2833)は2000がそうするかもしれません。
[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プロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[14] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent
Call", RFC 4040, April 2005.
[14]Kreuter、R.、「64kbit/s Transparent CallのためのRTP有効搭載量Format」、RFC4040、2005年4月。
[15] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005.
[15] ヘルストリョームとG.とP.ジョーンズ、「テキストの会話のためのRTP有効搭載量」、RFC4103、2005年6月。
[16] Schulzrinne, H. and T. Taylor, "Definition of Events for Modem,
Fax, and Text Telephony Signals", RFC 4734, December 2006.
[16]SchulzrinneとH.とT.テイラー、「モデム、ファックス、およびテキスト電話信号のための出来事の定義」、RFC4734、2006年12月。
[17] Schulzrinne, H. and T. Taylor, "Definition of Events For
Channel-Oriented Telephony Signalling", Work In Progress ,
November 2005.
[17] 「チャンネル指向の電話合図のための出来事の定義」というSchulzrinne、H.、およびT.テイラーは進歩、2005年11月に働いています。
Schulzrinne & Taylor Standards Track [Page 44] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[44ページ]。
[18] International Telecommunication Union, "Technical
characteristics of tones for the telephone service", ITU-T
Recommendation E.180/Q.35, March 1998.
[18] 国際電気通信連合、「電話サービスのためのトーンの技術的な特性」、ITU-T Recommendation 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 Recommendation 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] 国際電気通信連合、「音声符号器:」 「マルチメディア通信のための5.3と6.3kbit/sを伝わる二元的なレート音声符号器」、ITU-T Recommendation 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)を使用する8kbit/sでのスピーチのコード化」、ITU-T Recommendation 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]国際電気通信連合、「基本的な呼び出しコントロールのためのISDNユーザネットワーク・インターフェース層の3仕様」、ITU-T Recommendation 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]国際電気通信連合、ITU-T Recommendation T.38、2003年7月「Group3がIPネットワークの上でコミュニケーションを電送するリアルタイムのための手順」
[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 Recommendation 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] 国際電気通信連合、「モデム過剰IPは以下をネットワークでつなぎます」。 「終わりから終わりとのV-シリーズDCEsの接続のための手順」、ITU-T Recommendation 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 Networksの上でVoice-バンドDataを支持するための手順」、ITU-T Recommendation 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 Recommendation 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>.
また、Recommendation V.18 Amendment1、2002年11月を見てください。 [28] VOIP紛争調停人LLC、「徹底的:、」 「パケット損失Burstiness」、2005、<http://www.voiptroubleshooter.com/徹底的な/burstloss.html>。
Schulzrinne & Taylor Standards Track [Page 45] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[45ページ]。
Appendix A. Summary of Changes from RFC 2833
RFC2833からの変化の付録A.概要
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.
多くの明確化を仕様に取り入れて、メモはかなり再構築されました。 以下に述べられたそれらの項目を除いて、メモへの変化は後方にコンパチブル明確化であることを意図します。 しかしながら、RFC2833[12]との矛盾と不明瞭な定義のため、いくつかの実現がこのバージョンと異なっている方法でそのメモを解釈しそうでした。
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.
RFC2833は、すべての実現がDTMF出来事(イベントコード0-15)を受けることができるのを必要としました。 セクション2.5 .1 .1通の現在のドキュメントが、送付者が受信機が受けることができる出来事だけを伝えるのを必要とします。 受信機能力に関する知識がないとき、送付者SHOULDはDTMF出来事にもかかわらず、他の出来事がないサポートを仮定します。 送付者SHOULDは、それがどんな出来事を送ることができるかを示します。 セクション2.5 .2 .1 SDP MUSTを使用することで能力に合図する受信機が、それがどの出来事を受けることができるかを示すのが必要です。
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.
ペイロードのボリューム分野の非ゼロ値はRFC2833のDTMFトーンだけに適切でした、そして、他の出来事に関して、受信機はそれらを無視しなければなりませんでした。 現在のメモは、それぞれの出来事の定義が、ボリューム分野がその出来事に適切であるかどうかを示すのを必要とします。 .2が量を受けるなら受信機がするかもしれないことを示すセクション2.5.2の最後のパラグラフはボリューム分野が適切である出来事のための値のゼロに合っています。 RFC2833受信機規則と共に、これはトランスミッションの両方の方向に後方の互換性を確実にします。
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は持続時間がペイロード持続時間分野の容量を超えている出来事を報告して、展開するための新しい手順を導入します。 この手順は古い(RFC2833)受信機で瞬間の混乱を引き起こすかもしれません、Eが前のイベントレポートと噛み付かれて、Mを設定しないで噛み付いた新しい方の設定なしでタイムスタンプをアップデートするので。
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は短期間出来事の系列がただ一つのイベントレポートに詰め込まれるかもしれない新しい手順を導入します。 古い(RFC2833)受信機がそのようなレポートを受け取るなら、それは受信機がおめでたの予定であったより満足しているパケット船倉以来同じくらい無効のパケットを捨てるかもしれません。 とにかく、パケットの追加出来事は負けられるでしょう。
Schulzrinne & Taylor Standards Track [Page 46] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[46ページ]。
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.
保全の保護のための要件について言及するためにSecurity Considerations部をアップデートします。 より重要に、それは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]がモデム、ファックス、およびテキスト電話に関連して、それぞれチャンネルで関連している電話に合図する出来事について説明します。 RFC2833課題における誤りと冗長のためにいくつかの変更を後者にしました。 実行されたように見えないので、RFC2833で定義された残っている出来事は推奨しないのですが、それらのどれかが将来必要であるといけないので、それらのコードは条件付きに予約されました。 テーブル8は詳細にイベントコードの気質を示します。 このテーブルで言及されなかったイベントコードは、RFC2833によって割り当てられないで、ずっと未使用です。
+-------------+---------------------------------------+-------------+ | 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] | +-------------+---------------------------------------+-------------+
+-------------+---------------------------------------+-------------+ | イベントコード| RFC2833記述| 気質| +-------------+---------------------------------------+-------------+ | 0-15 | DTMFケタ| RFC4733| | 16 | 線フラッシュ(非難されます)| 予約されます。| | 23-31 | 未使用| [16] | | 32-40 | データとファックス| [16] | | 41-48 | データとファックス(V.8bisの、そして、推奨しない)| 予約されます。| | 52-63 | 未使用| [16] | | 64-89 | E.182線イベント(非難されます)| 予約されます。| | 96-112 | 国の特有の線イベント| 予約されます。| | | (推奨しない)です。 | | | 121-127 | 未使用| [17] | | 128-137 | トランクス: mf0-9| [17] | | 138-143 | トランクス: 他のMF(非難されます)| 予約されます。| | 144-159 | トランクス: ABCD合図| [17] | | 160-168 | トランクス: 様々です(推奨しない)。| 予約されます。| | 170-173 | トランクス: 様々です(推奨しない)。| 予約されます。| | 174-205 | 未使用| [17] | +-------------+---------------------------------------+-------------+
Table 8: Disposition of RFC 2833-defined Event Codes
テーブル8: RFCの気質、2833年定義されたイベントコード
Schulzrinne & Taylor Standards Track [Page 47] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[47ページ]。
Authors' Addresses
作者のアドレス
Henning Schulzrinne Columbia U. Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 US
コンピュータサイエンスコロンビア大学1214アムステルダムAvenueニューヨーク10027ニューヨーク(米国)のヘニングSchulzrinneコロンビアU.部
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Tom Taylor Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada
トム・テイラーノーテル1852ロレーヌAveオンタリオK1H 6Z8オタワ(カナダ)
EMail: taylor@nortel.com
メール: taylor@nortel.com
Schulzrinne & Taylor Standards Track [Page 48] RFC 4733 Telephony Events and Tones December 2006
SchulzrinneとテイラーStandardsは2006年12月にRFC4733電話出来事とトーンを追跡します[48ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信用、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Schulzrinne & Taylor Standards Track [Page 49]
Schulzrinneとテイラー標準化過程[49ページ]
一覧
スポンサーリンク
