RFC2833 日本語訳
2833 RTP Payload for DTMF Digits, Telephony Tones and TelephonySignals. H. Schulzrinne, S. Petrack. May 2000. (Format: TXT=68786 bytes) (Obsoleted by RFC4733, RFC4734) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Schulzrinne
Request for Comments: 2833 Columbia University
Category: Standards Track S. Petrack
MetaTel
May 2000
Schulzrinneがコメントのために要求するワーキンググループH.をネットワークでつないでください: 2833年のコロンビア大学カテゴリ: 標準化過程S.Petrack MetaTel2000年5月
RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
DTMFケタ、電話トーン、および電話信号のためのRTP有効搭載量
Status of this Memo
この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 Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets.
このメモはRTPパケットの二元的なトーン多重周波数(DTMF)シグナリング、他のトーン信号、および電話出来事を運ぶ方法を説明します。
1 Introduction
1つの序論
This memo defines two payload formats, one for carrying dual-tone multifrequency (DTMF) digits, other line and trunk signals (Section 3), and a second one for general multi-frequency tones in RTP [1] packets (Section 4). Separate RTP payload formats are desirable since low-rate voice codecs cannot be guaranteed to reproduce these tone signals accurately enough for automatic recognition. Defining separate payload formats also permits higher redundancy while maintaining a low bit rate.
このメモは2つのペイロード書式、二元的なトーン多重周波数(DTMF)ケタ、他の線、およびトランク信号(セクション3)を運ぶためのもの、およびRTP[1]パケット(セクション4)の一般的な多重周波数トーンのための2番目のものを定義します。 別々のRTPペイロード形式は、自動認識のためにこれらのトーン信号を十分正確に再生させるために低率音声コーデックを保証できないので、望ましいです。 また、別々のペイロード書式を定義すると、より高い冗長は低ビット伝送速度を維持している間、可能にします。
The payload formats described here may be useful in at least three applications: DTMF handling for gateways and end systems, as well as "RTP trunks". In the first application, 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 that low bit-rate codecs like G.723.1 render DTMF tones unintelligible. Secondly, an Internet
ここで説明されたペイロード形式は少なくとも3つのアプリケーションで役に立つかもしれません: ゲートウェイのためのDTMF取り扱いと「RTPトランクス」と同様にエンドシステム。 最初のアプリケーションでは、インターネット電話ゲートウェイは、入って来るサーキットの上にDTMFを検出して、レギュラーのオーディオパケットの代わりにここで説明されたRTPペイロードを送ります。 ゲートウェイには、必要なディジタル信号プロセッサとアルゴリズムがおそらくあります、しばしばDTMFを検出するのが必要であるときに、例えば、2ステージのダイヤルするために。 ゲートウェイにトーンを検出させると、受信インターネットエンドシステムがこの仕事をしなければならないので救われて、また、G.723.1がDTMFトーンを難解にするようにそんなに低いビット伝送速度コーデックは避けられます。 第二にインターネット
Schulzrinne & Petrack Standards Track [Page 1] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[1ページ]。
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.
システムを「インターネット電話」がそれ自体に関して正確なトーン組を発生させて、トーン認識の負担を受信機に課さないでDTMFの機能性を見習うことができる終わらせてください。
In the "RTP trunk" application, RTP is used to replace a normal
circuit-switched trunk between two nodes. This is particularly of
interest in a telephone network that is still mostly circuit-
switched. In this case, each end of the RTP trunk encodes audio
channels into the appropriate encoding, such as G.723.1 or G.729.
However, this encoding process destroys in-band signaling information
which is carried using the least-significant bit ("robbed bit
signaling") and may also interfere with in-band signaling tones, such
as the MF digit tones. In addition, tone properties such as the phase
reversals in the ANSam tone, will not survive speech coding. Thus,
the gateway needs to remove the in-band signaling information from
the bit stream. It can now either carry it out-of-band in a signaling
transport mechanism yet to be defined, or it can use the mechanism
described in this memorandum. (If the two trunk end points are within
reach of the same media gateway controller, the media gateway
controller can also handle the signaling.) Carrying it in-band may
simplify the time synchronization between audio packets and the tone
or signal information. This is particularly relevant where duration
and timing matter, as in the carriage of DTMF signals.
「RTPトランク」アプリケーションでは、RTPは、2つのノードの間で正常なサーキットで切り換えられたトランクを取り替えるのに使用されます。 これは特に電話網におもしろいです、すなわち、それでも、ほとんどサーキットが切り替わりました。 この場合、RTPトランクの各端は適切なコード化に音声チャンネルをコード化します、G.723.1やG.729のように。 しかしながら、このコード化の過程は、バンドにおける最下位ビット(「噛み付いているシグナリングから、略奪する」)を使用することで運ばれるシグナリング情報を無効にして、また、バンドにおけるシグナリングトーンを妨げるかもしれません、MFケタトーンなどのように。 添加、ANSamトーンにおけるフェーズ反転などのトーン所有地では、音声符号化は生き残っていないでしょう。 したがって、ゲートウェイは、ビットストリームからバンドにおけるシグナリング情報を取り除く必要があります。 それが今、まだ定義されているためにシグナリング移送機構でバンドの外までそれを運ぶことができますか、またはそれはこのメモで説明されたメカニズムを使用できます。 (また、同じメディアゲートウェイコントローラの範囲の中に2つのトランクエンドポイントがあるなら、メディアゲートウェイコントローラはシグナリングを扱うことができます。) それを運ぶと、バンドでは、オーディオパケットの間の時間同期化とトーンか信号情報が簡略化するかもしれません。 これはDTMF信号の運搬のように持続時間とタイミングが重要であるところで特に関連しています。
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 [2] and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[2]について説明して、対応する実現のために要件レベルを示すとき解釈されることであるべきですか?
2 Events vs. Tones
2回の出来事対トーン
A gateway has two options for handling DTMF digits and events. First, it can simply measure the frequency components of the voice band signals and transmit this information to the RTP receiver (Section 4). In this mode, the gateway makes no attempt to discern the meaning of the tones, but simply distinguishes tones from speech signals.
ゲートウェイには、取り扱いDTMFケタと出来事のための2つのオプションがあります。 まず最初に、それは、単に音声帯域信号の頻度成分を測定して、RTP受信機(セクション4)にこの情報を伝えることができます。 このモードで、ゲートウェイは、トーンの意味について明察する試みを全くしませんが、スピーチ信号とトーンを単に区別します。
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. (There is at least one tone, the ANSam tone [3] used for indicating data transmission over voice lines, that makes use of periodic phase reversals.)
PSTNであって意味されることで人間の消費で使用でのすべてのトーン信号が正弦波の簡単な組み合わせの系列である、どちらかが、加えたか、または変調しました。 (少なくとも1つのトーン、周期的なフェーズ反転を利用する[3]が声の線でデータ伝送を示すのに使用したANSamトーンがあります。)
As a second option, a gateway can recognize the tones and translate them into a name, such as ringing or busy tone. The receiver then produces a tone signal or other indication appropriate to the signal.
2番目のオプションとして、ゲートウェイは、トーンを認識して、それらを名前に翻訳できます、鳴るのや話中音のように。 そして、受信機は信号に適切なトーン信号か他の指示を作り出します。
Schulzrinne & Petrack Standards Track [Page 2] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[2ページ]。
Generally, since the recognition of signals 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 signaling information that generates the tones and thus can generate the RTP packet immediately, without the detour through acoustic signals.
一般に、信号の認識がしばしばそれらのオンであるかオフなパターンかいくつかのトーンの系列によるので、この認識は数秒取ることができます。 他方では、ゲートウェイは、トーンを発生させる実際のシグナリング情報に近づく手段を持っているかもしれなくて、その結果、すぐにRTPパケットを発生させることができます、音響による信号を通した回り道なしで。
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. ISDN terminals may generate dial tone locally and then send a Q.931 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 messages, and provides dial tone over the B-channel. The terminal can either use the audio signal on the B-channel or can use the Q.931 messages to trigger locally generated dial tone.
アナログの線において、ダイヤルトーンは地方のスイッチでいつも発生します。 ISDN端末は、ダイヤルトーンを局所的に発生させて、次に、ダイヤルされたケタを含むQ.931 SETUPメッセージを送るかもしれません。 端末が少しもCalledパーティケタなしでSETUPメッセージをただ送るなら、スイッチは、ケタ収集をして、KEYPADメッセージとして端末のそばで供給して、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 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トーンと呼ばれる)は訪問される人における地方のスイッチで発生します、一方通行の声の経路が訪問される人の電話リングの次第に開けられている状態で。 (これは答えのすぐ後に被呼者の応答を切り取るという可能性を小さくします。 また、それは、プレ答え発表かバンドでの呼び出し進歩指摘が呼出音の前か呼出音の代わりに訪問者に届くことを許可します。) 混雑トーンと特別な情報トーンは、道に沿ってスイッチのどれかで発生できて、受け取られたISUPメッセージに基づく訪問者のスイッチで発生するかもしれません。 話中音は適切なISUPメッセージによって引き起こされた訪問者のスイッチでアナログの器具、またはISDN端末に発生します。
Gateways which send signaling events via RTP MAY send both named signals (Section 3) and the tone representation (Section 4) as a single RTP session, using the redundancy mechanism defined in Section 3.7 to interleave the two representations. It is generally a good idea to send both, since it allows the receiver to choose the appropriate rendering.
RTP MAYを通してシグナル伝達事象を送るゲートウェイがただ一つのRTPセッションとして信号(セクション3)とトーン表現(セクション4)という両方を送ります、2つの表現をはさみ込むためにセクション3.7で定義された冗長メカニズムを使用して。 受信機がそれで適切な表現を選ぶことができるので、一般に、両方を送るのは、名案です。
If a gateway cannot present a tone representation, it SHOULD send the audio tones as regular RTP audio packets (e.g., as payload format PCMU), in addition to the named signals.
ゲートウェイであるならトーン表現を提示できません、それ。SHOULDはRTPオーディオパケット(例えば、ペイロード形式PCMUとしての)を通常であるとしてのオーディオトーンに送ります、命名された信号に加えて。
Schulzrinne & Petrack Standards Track [Page 3] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[3ページ]。
3 RTP Payload Format for Named Telephone Events
3 命名された電話出来事のためのRTP有効搭載量形式
3.1 Introduction
3.1 序論
The payload format for named telephone events described below is suitable for both gateway and end-to-end scenarios. In the gateway scenario, an Internet telephony gateway connecting a packet voice network to the PSTN recreates the DTMF tones or other telephony events 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.
以下で説明された命名された電話出来事のためのペイロード形式はゲートウェイと終わりから終わりへの両方のシナリオに適しています。 ゲートウェイシナリオでは、パケット声のネットワークをPSTNに接続するインターネット電話ゲートウェイは、DTMFトーンか他の電話出来事を休養させて、PSTNにそれらを注ぎます。 例えば、DTMFケタ認識が数個の10ミリセカンドと同じくらい取るので、ケタの数最初のミリセカンドがレギュラーのオーディオパケットとして到着するでしょう。 したがって、オーディオのサンプルと出来事の間の慎重な時間とパワー(ボリューム)整列が、受信機で偽りのケタを発生させるのを避けるのに必要です。
DTMF digits and named telephone events are carried as part of the audio stream, and MUST use the same sequence number and time-stamp base as the regular audio channel to simplify the generation of audio waveforms at a gateway. The default clock frequency is 8,000 Hz, but the clock frequency can be redefined when assigning the dynamic payload type.
DTMFケタと命名された電話出来事は、オーディオストリームの一部として運ばれて、ゲートウェイでオーディオ波形の世代を簡素化するのに通常の音声チャンネルと同じ一連番号とタイムスタンプベースを使用しなければなりません。 デフォルトクロック周波数は8,000Hzですが、ダイナミックなペイロードタイプを選任するとき、クロック周波数を再定義できます。
The payload format described here achieves a higher redundancy even in the case of sustained packet loss than the method proposed for the Voice over Frame Relay Implementation Agreement [4].
ここで説明されたペイロード形式は持続しているパケット損失の場合でさえFrame Relay Implementation Agreement[4]の上のVoiceのために提案された方法より高い冗長を実現します。
If an end system is directly connected to the Internet and does not need to generate tone signals again, time alignment and power levels are not relevant. These systems rely on PSTN gateways or Internet end systems to generate DTMF events and do not perform their own audio waveform analysis. An example of such a system is an Internet interactive voice-response (IVR) system.
エンドシステムが直接インターネットに関連づけられて、再びトーン信号を発生させる必要はないなら、時間整列とパワーレベルは関連していません。 これらのシステムは、DTMF出来事を発生させるようにPSTNゲートウェイかインターネットエンドシステムを当てにして、それら自身のオーディオ波形解析を実行しません。 そのようなシステムに関する例はインターネットインタラクティブ声応答(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, such as the IVR example mentioned earlier, 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パケットよりむしろ信頼できる制御プロトコルを使用するのは望ましいかもしれません。 それらの事情では、このペイロード形式は使用されないでしょう。
3.2 Simultaneous Generation of Audio and Events
3.2オーディオと出来事の同時の世代
A source MAY send events and coded audio packets for the same time instants, using events as the redundant encoding for the audio stream, or it MAY block outgoing audio while event tones are active and only send named events as both the primary and redundant encodings.
ソースが同じ時間瞬間に出来事とコード化されたオーディオパケットを送るかもしれなくて、オーディオのための余分なコード化として出来事を使用して、流れてくださいか、それは、イベントトーンがアクティブである間、出発しているオーディオを妨げて、両方の第一の、そして、余分なencodingsとして命名された出来事を送るだけであるかもしれません。
Schulzrinne & Petrack Standards Track [Page 4] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[4ページ]。
Note that a period covered by an encoded tone may overlap in time with a period of audio encoded by other means. This is likely to occur at the onset of a tone and is necessary to avoid possible errors in the interpretation of the reproduced tone at the remote end. Implementations supporting this payload format must be prepared to handle the overlap. It is RECOMMENDED that gateways only render the encoded tone 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.
コード化されたトーンでカバーされた期間が時間内に他の手段でコード化されるオーディオの期間に重なるかもしれないことに注意してください。 これが、トーンの開始のときに起こりそうであって、リモートエンドにおける再生しているトーンの解釈における可能な誤りを避けるのに必要です。 オーバラップを扱うようにこのペイロード形式を支持する実現を準備しなければなりません。 オーディオが音声圧縮アルゴリズムで導入された偽りのトーンを含むかもしれないのでゲートウェイがコード化されたトーンをレンダリングするだけであるのは、RECOMMENDEDです。 しかしながら、一般に、これらの余分なトーンが遠端で認識を妨げるべきでないと予期されます。
3.3 Event Types
3.3 イベントタイプ
This payload format is used for five different types of signals:
このペイロード形式は5つの異なったタイプに関する信号に使用されます:
o DTMF tones (Section 3.10);
o DTMFは(セクション3.10)に調子を変えさせます。
o fax-related tones (Section 3.11);
o ファックス関連のトーン(セクション3.11)。
o standard subscriber line tones (Section 3.12);
o 標準の加入者線トーン(セクション3.12)。
o country-specific subscriber line tones (Section 3.13) and;
o そして、国の特有の加入者線トーン(セクション3.13)、。
o trunk events (Section 3.14).
o トランク出来事(セクション3.14)。
A compliant implementation MUST support the events listed in Table 1 with the exception of "flash". If it uses some other, out-of-band mechanism for signaling line conditions, it does not have to implement the other events.
対応する実現は「フラッシュ」を除いて、Table1に記載された出来事を支持しなければなりません。 使用する、ある他のシグナリングのためのバンドで出ているメカニズムは状態を裏打ちして、それは他の出来事を実行する必要はありません。
In some cases, an implementation may simply ignore certain events, such as fax tones, that do not make sense in a particular environment. Section 3.9 specifies how an implementation can use the SDP "fmtp" parameter within an SDP description to indicate its inability to understand a particular event or range of events.
いくつかの場合、実現は単に特定の環境で理解できないファックストーンなどのある出来事を無視するかもしれません。 セクション3.9は実現が特定の出来事か1つの範囲の出来事を理解できないことを示すのにSDP記述の中でどうSDP"fmtp"パラメタを使用できるかを指定します。
Depending on the available user interfaces, an implementation MAY render all tones in Table 5 the same or, preferably, use the tones conveyed by the concurrent "tone" payload or other RTP audio payload. Alternatively, it could provide a textual representation.
望ましくは、利用可能なユーザインタフェースによって、実現は、Table5のすべてのトーンを同じにするか、または同時発生の「トーン」ペイロードか他のRTPのオーディオのペイロードによって伝えられたトーンを使用するかもしれません。 あるいはまた、それは原文の表現を提供するかもしれません。
Note that end systems that emulate telephones only need to support the events described in Sections 3.10 and 3.12, while systems that receive trunk signaling need to implement those in Sections 3.10, 3.11, 3.12 and 3.14, since MF trunks also carry most of the "line" signals. Systems that do not support fax or modem functionality do not need to render fax-related events described in Section 3.11.
電話をエミュレートするエンドシステムが、セクション3.10と3.12で説明された出来事を支持する必要であるだけであることに注意してください、トランクシグナリングを受けるシステムは、セクション3.10、3.11、3.12、および3.14でそれらを実行する必要がありますが、また、MFトランクスが「線」信号の大部分を運ぶので。 ファックスかモデムの機能性を支えないシステムは、セクション3.11でファックス関連の出来事について説明するようにレンダリングする必要はありません。
Schulzrinne & Petrack Standards Track [Page 5] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[5ページ]。
The RTP payload format is designated as "telephone-event", the MIME type as "audio/telephone-event". The default timestamp rate is 8000 Hz, but other rates may be defined. In accordance with current practice, this payload format does not have a static payload type number, but uses a RTP payload type number established dynamically and out-of-band.
RTPペイロード形式は「電話出来事」、「電話オーディオ/出来事」としてのMIMEの種類として指定されます。 デフォルトタイムスタンプレートは8000Hzですが、他のレートは定義されるかもしれません。 現在の習慣に従って、このペイロード形式は、静的なペイロード形式数を持っていませんが、ダイナミックとバンドの外で確立されたRTPペイロード形式数を使用します。
3.4 Use of RTP Header Fields
3.4 RTPヘッダーフィールドの使用
Timestamp: The RTP timestamp reflects the measurement point for
the current packet. The event duration described in Section
3.5 extends forwards from that time. The receiver calculates
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.
タイムスタンプ: RTPタイムスタンプは現在のパケットのために測定ポイントを反映します。 セクション3.5で説明されたイベント持続時間はあの時以来前方に広がります。 受信機は与えられたタイムスタンプがあるすべてのパケットに基づくRTCP受信機レポートのためのジターについて計算します。 以下に注意してください。 ジター値は、絶対測定ではなく、2人のユーザか2回の期間の間のレセプション品質を比較するのに手段として主として使用されるべきです。
Marker bit: The RTP marker bit indicates the beginning of a new
event.
マーカーは噛み付きました: RTPマーカービットは新しい出来事の始まりを示します。
3.5 Payload Format
3.5 有効搭載量形式
The payload format is shown in Fig. 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: 命名された出来事のための有効搭載量形式
events: The events are encoded as shown in Sections 3.10 through
3.14.
出来事: 出来事はセクション3.10〜3.14に示されるようにコード化されます。
volume: 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. The range of valid DTMF is from 0 to -36 dBm0 (must
accept); lower than -55 dBm0 must be rejected (TR-TSY-000181,
ITU-T Q.24A). Thus, larger values denote lower volume. This
value is defined only for DTMF digits. For other events, it
is set to zero by the sender and is ignored by the receiver.
ボリューム: トーンとして「表-可能」なDTMFケタと他の出来事に関しては、この分野はサインを落とした後にdBm0で言い表されたトーンのパワーレベルについて説明します。 パワーレベルは0〜-63dBm0から変化します。 有効なDTMFの範囲が0〜-36dBm0(受け入れなければならない)からあります。 -55より低く、dBm0を拒絶しなければなりません(TR-TSY-000181、ITU-T Q.24A)。 したがって、より大きい値は下側のボリュームを指示します。 この値はDTMFケタのためだけに定義されます。 他の出来事に関しては、それは、送付者によってゼロに設定されて、受信機によって無視されます。
Schulzrinne & Petrack Standards Track [Page 6] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[6ページ]。
duration: Duration of this digit, in timestamp units. Thus, the
event 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.
持続時間: タイムスタンプユニットのこのケタの持続時間。 したがって、出来事は、RTPタイムスタンプによって特定された瞬間に始まって、このパラメタによって示されて、今までのところ、持続しました。 出来事は終わったかもしれません。
For a sampling rate of 8000 Hz, this field is sufficient to
express event durations of up to approximately 8 seconds.
8000Hzの標本抽出率では、この分野は、最大およそ8秒のイベント持続時間を言い表すために十分です。
E: If set to a value of one, the "end" bit indicates that this
packet contains the end of the event. Thus, the duration
parameter above measures the complete duration of the event.
E: 1の値に設定されるなら、「終わり」ビットは、このパケットが出来事の終わりを含むのを示します。 したがって、上記の持続時間パラメタは出来事の完全な持続時間を測定します。
A sender MAY delay setting the end bit until retransmitting
the last packet for a tone, rather than on its first
transmission. This avoids having to wait to detect whether
the tone has indeed ended.
送付者は、最初のトランスミッションに関してというよりむしろトーンのために最後のパケットを再送するまで終わりのビットを設定するのを遅らせるかもしれません。 これは、本当に、トーンが終わったかどうか検出するのを待たなければならないのを避けます。
Receiver implementations MAY use different algorithms to
create tones, including the two described here. In the first,
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 it receives a packet with the
"E" bit set, the next tone, distinguished by a different
timestamp value or a given time period elapses. This is more
robust against packet loss, but may extend the tone 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". 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.
受信機実現は、ここに説明された2を含むトーンを作成するのに異なったアルゴリズムを使用するかもしれません。 1番目に、受信機は単にタイムスタンプによって示された位置のオーディオ再生バッファの与えられた持続時間のトーンを置きます。 同じトーンを広げる受け取られた追加パケットとして、再生バッファの波形はそれに従って、広げられます。 (オーディオが単にコピーされるより再生バッファにむしろ混ぜられて、すなわち、まとめられるなら、注意しなければなりません。) したがって、パケットinterarrival時間が失せるより長い間続くトーンと再生遅れにおけるパケットが脆いなら、トーンにおけるギャップは起こるかもしれません。 あるいはまた、「E」ビットがセットしたことでのパケット、異なったタイムスタンプ値によって区別された次のトーンを受けるまで、受信機が、トーンを始めて、それをプレーできますか、または与えられた期間は経過します。 これは、パケット損失に対して、より強健ですが、出来事における最後のパケットのすべての「再-トランスミッション」が無くなるなら、トーンを広げるかもしれません。 トーンを広げる期間を制限するのが、避けるのにトーンが「立ち往生すること」が必要です。 使用されるアルゴリズムにかかわらず調子を変える、さらに広げられて、3つのパケットinterarrival回数よりSHOULD NOTに調子を変えさせてください。 一般に、トーン持続時間のわずかな拡大とくぎりの短縮は無害です。
R: This field is reserved for future use. The sender MUST set it
to zero, the receiver MUST ignore it.
R: この分野は今後の使用のために予約されます。 送付者はゼロにそれを設定しなければならなくて、受信機はそれを無視しなければなりません。
Schulzrinne & Petrack Standards Track [Page 7] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[7ページ]。
3.6 Sending Event Packets
3.6 送付イベントパケット
An audio source SHOULD start transmitting event packets as soon as it recognizes an event and every 50 ms thereafter or the packet interval for the audio codec used for this session, if known. (The sender does not need to maintain precise time intervals between event packets in order to maintain precise inter-event times, since the timing information is contained in the timestamp.)
その後出来事と50ms毎を認識するとすぐに、イベントパケットを伝えるオーディオソースSHOULD始めか知られているならこのセッションに使用されるオーディオコーデックのためのパケット間隔。 (送付者は正確な相互イベント回を維持するためにイベントパケットの正確な時間間隔を維持する必要はありません、タイミング情報がタイムスタンプに含まれているので。)
Q.24 [5], Table A-1, indicates that all administrations surveyed
use a minimum signal duration of 40 ms, with signaling velocity
(tone and pause) of no less than 93 ms.
Q.24[5](Table A-1)は、政権が調査したすべてが40msの最小の信号持続時間を使用するのを示します、いいえ93、原稿のシグナリング速度(調子を変えて、ポーズする)で
If an event continues for more than one period, the source generating the events should send a new event packet with the RTP timestamp value corresponding to the beginning of the event and the duration of the event increased correspondingly. (The RTP sequence number is incremented by one for each packet.) If there has been no new event in the last interval, the event SHOULD be retransmitted three times or until the next event is recognized. This ensures that the duration of the event can be recognized correctly even if the last packet for an event is lost.
出来事が1回以上の期間、続くなら、出来事の始まりに対応するRTPタイムスタンプ価値と出来事の持続時間が対応する増加している状態で、出来事を発生させているソースは新しいイベントパケットを送るべきです。 (RTP一連番号は各パケットあたり1つ増加されます。) どんな新しい出来事も最後の間隔になかったなら、イベントSHOULDは3回再送されるか、または次の出来事まで認識されます。 これは、出来事のための最後のパケットが無くなっても正しく出来事の持続時間を認識できるのを確実にします。
DTMF digits and events are sent incrementally to avoid having the
receiver wait for the completion of the event. Since some tones
are two seconds long, this would incur a substantial delay. The
transmitter does not know if event length is important and thus
needs to transmit immediately and incrementally. If the receiver
application does not care about event length, the incremental
transmission mechanism avoids delay. Some applications, such as
gateways into the PSTN, care about both delays and event duration.
受信機に出来事の完成を待たせるのを避けるためにDTMFケタと出来事を増加して送ります。 いくつかのトーンが長さ2秒であるので、これはかなりの遅れを被るでしょう。 送信機は、イベントの長さが重要であるかどうかを知らないで、その結果、すぐに、そして増加して伝わる必要があります。 受信側アプリケーションがイベントの長さを心配しないなら、増加の効果波及経路は遅れを避けます。 PSTNへのゲートウェイなどのいくつかのアプリケーションが遅れとイベント持続時間の両方を心配します。
3.7 Reliability
3.7 信頼性
During an event, the RTP event payload format provides incremental updates on the event. The error resiliency depends on the playout delay at the receiver. For example, for a playout delay of 120 ms and a packet gap of 50 ms, two packets in a row can get lost without causing a gap in the tones generated at the receiver.
出来事の間、RTPイベントペイロード形式は出来事でアップデート増加を提供します。 誤りの弾性は受信機の再生遅れによります。例えば、受信機で発生するトーンにおけるギャップを引き起こさないで、120msの再生遅れと50msのパケットギャップに、並んでいる2つのパケットが失せることができます。
The audio redundancy mechanism described in RFC 2198 [6] MAY be used to recover from packet loss across events. The effective data rate is r times 64 bits (32 bits for the redundancy header and 32 bits for the telephone-event payload) every 50 ms or r times 1280 bits/second, where r is the number of redundant events carried in each packet. The value of r is an implementation trade-off, with a value of 5 suggested.
RFC2198[6]で説明されたオーディオ冗長メカニズムは、出来事の向こう側にパケット損失から回復するのに使用されるかもしれません。 有効なデータ信号速度は50の(冗長ヘッダーのための32ビットと電話イベントペイロードのための32ビット)のmsかr回数毎2分のビット/1280に64ビットr回です、rが各パケットで運ばれた余分な出来事の数であるところで。 rの値は5の値が示されている実現トレードオフです。
Schulzrinne & Petrack Standards Track [Page 8] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[8ページ]。
The timestamp offset in this redundancy scheme has 14 bits, so
that it allows a single packet to "cover" 2.048 seconds of
telephone events at a sampling rate of 8000 Hz. Including the
starting time of previous events allows precise reconstruction of
the tone sequence at a gateway. The scheme is resilient to
consecutive packet losses spanning this interval of 2.048 seconds
or r digits, whichever is less. Note that for previous digits,
only an average loudness can be represented.
この冗長計画で相殺されたタイムスタンプは14ビットを持っています、単一のパケットが8000Hzの標本抽出率で2.048秒の電話出来事を「覆うこと」を許容するように。 前の出来事の始動時を含んでいると、調子連鎖の正確な再構成はゲートウェイで許されます。 計画はどれがさらに少ないかなら2.048秒かrケタのこの間隔にかかる連続したパケット損失に弾力があります。 前のケタにおいて、平均した高らかしか表すことができないことに注意してください。
An encoder MAY treat the event payload as a highly-compressed version of the current audio frame. In that mode, each RTP packet during an event would contain the current audio codec rendition (say, G.723.1 or G.729) of this digit as well as the representation described in Section 3.5, plus any previous events seen earlier.
エンコーダは現在のオーディオフレームの非常に圧縮されたバージョンとしてイベントペイロードを扱うかもしれません。 そのモードで、出来事の間のそれぞれのRTPパケットはセクション3.5で説明された表現、および、より早く見られたどんな前の出来事と同様にこのケタの現在のオーディオコーデック表現(たとえば、G.723.1かG.729)を含んでいるでしょう。
This approach allows dumb gateways that do not understand this
format to function. See also the discussion in Section 1.
このアプローチはこの形式が機能するのを理解していない馬鹿なゲートウェイを許容します。 また、セクション1で議論を見てください。
3.8 Example
3.8 例
A typical RTP packet, where the user is just dialing the last digit of the DTMF sequence "911". The first digit was 200 ms long (1600 timestamp units) and started at time 0, the second digit lasted 250 ms (2000 timestamp units) and started at time 800 ms (6400 timestamp units), the third digit was pressed at time 1.4 s (11,200 timestamp units) and the packet shown was sent at 1.45 s (11,600 timestamp units). The frame duration is 50 ms. To make the parts recognizable, the figure below ignores byte alignment. Timestamp and sequence number are assumed to have been zero at the beginning of the first digit. In this example, the dynamic payload types 96 and 97 have been assigned for the redundancy mechanism and the telephone event payload, respectively.
ユーザがただDTMF系列「911」の下ケタにダイヤルしているところの典型的なRTPパケット。 最初のケタは、長い間(1600タイムスタンプユニット)の200msであり、時0に始まりました、そして、2番目のケタは、250ms(2000タイムスタンプユニット)を持続して、時に800ms(6400タイムスタンプユニット)を始動しました、そして、時に1.4秒間(1万1200タイムスタンプユニット)、3番目のケタを押しました、そして、1.45秒間(1万1600タイムスタンプユニット)のときに見せられたパケットを送りました。 フレーム持続時間が原稿Toが認識可能な部品をする50である、以下の図はバイト整列を無視します。 タイムスタンプと一連番号は最初のケタの始めにおけるゼロであったと思われます。 この例では、ダイナミックなペイロードタイプ96と97は冗長メカニズムと電話イベントペイロードのためにそれぞれ選任されました。
Schulzrinne & Petrack Standards Track [Page 9] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[9ページ]。
3.9 Indication of Receiver Capabilities using SDP
3.9 SDPを使用する受信機能力のしるし
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| 96 | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 11200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 11200 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 11200 - 6400 = 4800 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT |
|0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 9 |1 0| 7 | 1600 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |1 0| 10 | 2000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |0 0| 20 | 400 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 96 | 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| | 11200 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| | 0x5234a8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| 太平洋標準時のブロック| タイムスタンプオフセット| ブロック長| |1| 97 | 11200 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| 太平洋標準時のブロック| タイムスタンプオフセット| ブロック長| |1| 97 | 11200 - 6400 = 4800 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| 太平洋標準時のブロック| |0| 97 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ケタ|E R| ボリューム| 持続時間| | 9 |1 0| 7 | 1600 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ケタ|E R| ボリューム| 持続時間| | 1 |1 0| 10 | 2000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ケタ|E R| ボリューム| 持続時間| | 1 |0 0| 20 | 400 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example RTP packet after dialing "911"
図2: 「911」にダイヤルした後の例のRTPパケット
Receivers MAY indicate which named events they can handle, for example, by using the Session Description Protocol (RFC 2327 [7]). The payload formats use the following fmtp format to list the event values that they can receive:
Receivers MAY indicate which named events they can handle, for example, by using the Session Description Protocol (RFC 2327 [7]). The payload formats use the following fmtp format to list the event values that they can receive:
a=fmtp:<format> <list of values>
a=fmtp:<format> <list of values>
The list of values consists of comma-separated elements, which can be either a single decimal number or two decimal numbers separated by a hyphen (dash), where the second number is larger than the first. No whitespace is allowed between numbers or hyphens. The list does not have to be sorted.
The list of values consists of comma-separated elements, which can be either a single decimal number or two decimal numbers separated by a hyphen (dash), where the second number is larger than the first. No whitespace is allowed between numbers or hyphens. The list does not have to be sorted.
Schulzrinne & Petrack Standards Track [Page 10] RFC 2833 Tones May 2000
Schulzrinne & Petrack Standards Track [Page 10] RFC 2833 Tones May 2000
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, it would include the following description in its SDP message:
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, it would include the following description in its SDP message:
a=fmtp:100 0-15,66,70
a=fmtp:100 0-15,66,70
Since all implementations MUST be able to receive events 0 through 15, listing these events in the a=fmtp line is OPTIONAL.
Since all implementations MUST be able to receive events 0 through 15, listing these events in the a=fmtp line is OPTIONAL.
The corresponding MIME parameter is "events", so that the following sample media type definition corresponds to the SDP example above:
The corresponding MIME parameter is "events", so that the following sample media type definition corresponds to the SDP example above:
audio/telephone-event;events="0-11,66,67";rate="8000"
audio/telephone-event;events="0-11,66,67";rate="8000"
3.10 DTMF Events
3.10 DTMF Events
Table 1 summarizes the DTMF-related named events within the telephone-event payload format.
Table 1 summarizes the DTMF-related named events within the telephone-event payload format.
Event encoding (decimal)
_________________________
0--9 0--9
* 10
# 11
A--D 12--15
Flash 16
Event encoding (decimal) _________________________ 0--9 0--9 * 10 # 11 A--D 12--15 Flash 16
Table 1: DTMF named events
Table 1: DTMF named events
3.11 Data Modem and Fax Events
3.11 Data Modem and Fax Events
Table 3.11 summarizes the events and tones that can appear on a subscriber line serving a fax machine or modem. The tones are described below, with additional detail in Table 7.
Table 3.11 summarizes the events and tones that can appear on a subscriber line serving a fax machine or modem. The tones are described below, with additional detail in Table 7.
ANS: This 2100 +/- 15 Hz tone is used to disable echo
suppression for data transmission [8,9]. For fax machines,
Recommendation T.30 [9] refers to this tone as called
terminal identification (CED) answer tone.
ANS: This 2100 +/- 15 Hz tone is used to disable echo suppression for data transmission [8,9]. For fax machines, Recommendation T.30 [9] refers to this tone as called terminal identification (CED) answer tone.
/ANS: This is the same signal as ANS, except that it reverses
phase at an interval of 450 +/- 25 ms. It disables both
echo cancellers and echo suppressors. (In the ITU
Recommendation V.25 [8], this signal is rendered as ANS
with a bar on top.)
/ANS: This is the same signal as ANS, except that it reverses phase at an interval of 450 +/- 25 ms. It disables both echo cancellers and echo suppressors. (In the ITU Recommendation V.25 [8], this signal is rendered as ANS with a bar on top.)
Schulzrinne & Petrack Standards Track [Page 11] RFC 2833 Tones May 2000
Schulzrinne & Petrack Standards Track [Page 11] RFC 2833 Tones May 2000
ANSam: The modified answer tone (ANSam) [3] is a sinewave signal
at 2100 +/- 1 Hz without phase reversals, amplitude-modulated
by a sinewave at 15 +/- 0.1 Hz. This tone is sent by modems
if network echo canceller disabling is not required.
ANSam: The modified answer tone (ANSam) [3] is a sinewave signal at 2100 +/- 1 Hz without phase reversals, amplitude-modulated by a sinewave at 15 +/- 0.1 Hz. This tone is sent by modems if network echo canceller disabling is not required.
/ANSam: The modified answer tone with phase reversals (ANSam) [3]
is a sinewave signal at 2100 +/- 1 Hz with phase reversals at
intervals of 450 +/- 25 ms, amplitude-modulated by a sinewave
at 15 +/- 0.1 Hz. This tone [10,8] is sent by modems [11] and
faxes to disable echo suppressors.
/ANSam: The modified answer tone with phase reversals (ANSam) [3] is a sinewave signal at 2100 +/- 1 Hz with phase reversals at intervals of 450 +/- 25 ms, amplitude-modulated by a sinewave at 15 +/- 0.1 Hz. This tone [10,8] is sent by modems [11] and faxes to disable echo suppressors.
CNG: After dialing the called fax machine's telephone number (and
before it answers), the calling Group III fax machine
(optionally) begins sending a CalliNG tone (CNG) consisting
of an interrupted tone of 1100 Hz. [9]
CNG: After dialing the called fax machine's telephone number (and before it answers), the calling Group III fax machine (optionally) begins sending a CalliNG tone (CNG) consisting of an interrupted tone of 1100 Hz. [9]
CRdi: Capabilities Request (CRd), initiating side, [12] is a
dual-tone signal with tones at 1375 Hz and 2002 Hz for 400
ms, followed by a single tone at 1900 Hz for 100 ms. "This
signal requests the remote station transition from telephony
mode to an information transfer mode and requests the
transmission of a capabilities list message by the remote
station. In particular, CRdi is sent by the initiating
station during the course of a call, or by the calling
station at call establishment in response to a CRe or MRe."
CRdi: Capabilities Request (CRd), initiating side, [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 1900 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a capabilities list message by the remote station. In particular, CRdi is sent by the initiating station during the course of a call, or by the calling station at call establishment in response to a CRe or MRe."
CRdr: CRdr is the response tone to CRdi (see above). It consists
of a dual-tone signal with tones at 1529 Hz and 2225 Hz for
400 ms, followed by a single tone at 1900 Hz for 100 ms.
CRdr: CRdr is the response tone to CRdi (see above). It consists of a dual-tone signal with tones at 1529 Hz and 2225 Hz for 400 ms, followed by a single tone at 1900 Hz for 100 ms.
CRe: Capabilities Request (CRe) [12] is a dual-tone signal with
tones at tones at 1375 Hz and 2002 Hz for 400 ms, followed by
a single tone at 400 Hz for 100 ms. "This signal requests the
remote station transition from telephony mode to an
information transfer mode and requests the transmission of a
capabilities list message by the remote station. In
particular, CRe is sent by an automatic answering station at
call establishment."
CRe: Capabilities Request (CRe) [12] is a dual-tone signal with tones at tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 400 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a capabilities list message by the remote station. In particular, CRe is sent by an automatic answering station at call establishment."
CT: "The calling tone [8] consists of a series of interrupted
bursts of binary 1 signal or 1300 Hz, on for a duration of
not less than 0.5 s and not more than 0.7 s and off for a
duration of not less than 1.5 s and not more than 2.0 s."
Modems not starting with the V.8 call initiation tone often
use this tone.
CT: "The calling tone [8] consists of a series of interrupted bursts of binary 1 signal or 1300 Hz, on for a duration of not less than 0.5 s and not more than 0.7 s and off for a duration of not less than 1.5 s and not more than 2.0 s." Modems not starting with the V.8 call initiation tone often use this tone.
Schulzrinne & Petrack Standards Track [Page 12] RFC 2833 Tones May 2000
Schulzrinne & Petrack Standards Track [Page 12] RFC 2833 Tones May 2000
ESi: Escape Signal (ESi) [12] is a dual-tone signal with tones at
1375 Hz and 2002 Hz for 400 ms, followed by a single tone at
980 Hz for 100 ms. "This signal requests the remote station
transition from telephony mode to an information transfer
mode. signal ESi is sent by the initiating station."
ESi: Escape Signal (ESi) [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 980 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode. signal ESi is sent by the initiating station."
ESr: Escape Signal (ESr) [12] is a dual-tone signal with tones at
1529 Hz and 2225 Hz for 400 ms, followed by a single tone at
1650 Hz for 100 ms. Same as ESi, but sent by the responding
station.
ESr: Escape Signal (ESr) [12] is a dual-tone signal with tones at 1529 Hz and 2225 Hz for 400 ms, followed by a single tone at 1650 Hz for 100 ms. Same as ESi, but sent by the responding station.
MRdi: Mode Request (MRd), initiating side, [12] is a dual-tone
signal with tones at 1375 Hz and 2002 Hz for 400 ms followed
by a single tone at 1150 Hz for 100 ms. "This signal requests
the remote station transition from telephony mode to an
information transfer mode and requests the transmission of a
mode select message by the remote station. In particular,
signal MRd is sent by the initiating station during the
course of a call, or by the calling station at call
establishment in response to an MRe." [12]
MRdi: Mode Request (MRd), initiating side, [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms followed by a single tone at 1150 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a mode select message by the remote station. In particular, signal MRd is sent by the initiating station during the course of a call, or by the calling station at call establishment in response to an MRe." [12]
MRdr: MRdr is the response tone to MRdi (see above). It consists
of a dual-tone signal with tones at 1529 Hz and 2225 Hz for
400 ms, followed by a single tone at 1150 Hz for 100 ms.
MRdr: MRdr is the response tone to MRdi (see above). It consists of a dual-tone signal with tones at 1529 Hz and 2225 Hz for 400 ms, followed by a single tone at 1150 Hz for 100 ms.
MRe: Mode Request (MRe) [12] is a dual-tone signal with tones at
1375 Hz and 2002 Hz for 400 ms, followed by a single tone at
650 Hz for 100 ms. "This signal requests the remote station
transition from telephony mode to an information transfer
mode and requests the transmission of a mode select message
by the remote station. In particular, signal MRe is sent by
an automatic answering station at call establishment." [12]
MRe: Mode Request (MRe) [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 650 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a mode select message by the remote station. In particular, signal MRe is sent by an automatic answering station at call establishment." [12]
V.21: V.21 describes a 300 b/s full-duplex modem that employs
frequency shift keying (FSK). It is used by Group 3 fax
machines to exchange T.30 information. The calling transmits
on channel 1 and receives on channel 2; the answering modem
transmits on channel 2 and receives on channel 1. Each bit
value has a distinct tone, so that V.21 signaling comprises a
total of four distinct tones.
V.21: V.21 describes a 300 b/s full-duplex modem that employs frequency shift keying (FSK). It is used by Group 3 fax machines to exchange T.30 information. The calling transmits on channel 1 and receives on channel 2; the answering modem transmits on channel 2 and receives on channel 1. Each bit value has a distinct tone, so that V.21 signaling comprises a total of four distinct tones.
Schulzrinne & Petrack Standards Track [Page 13] RFC 2833 Tones May 2000
Schulzrinne & Petrack Standards Track [Page 13] RFC 2833 Tones May 2000
In summary, procedures in Table 2 are used.
In summary, procedures in Table 2 are used.
Procedure indications
___________________________________________________
V.25 and V.8 ANS
V.25, echo canceller disabled ANS, /ANS, ANS, /ANS
V.8 ANSam
V.8, echo canceller disabled /ANSam
Procedure indications ___________________________________________________ V.25 and V.8 ANS V.25, echo canceller disabled ANS, /ANS, ANS, /ANS V.8 ANSam V.8, echo canceller disabled /ANSam
Table 2: Use of ANS, ANSam and /ANSam in V.x recommendations
Table 2: Use of ANS, ANSam and /ANSam in V.x recommendations
Event encoding (decimal)
___________________________________________________
Answer tone (ANS) 32
/ANS 33
ANSam 34
/ANSam 35
Calling tone (CNG) 36
V.21 channel 1, "0" bit 37
V.21 channel 1, "1" bit 38
V.21 channel 2, "0" bit 39
V.21 channel 2, "1" bit 40
CRdi 41
CRdr 42
CRe 43
ESi 44
ESr 45
MRdi 46
MRdr 47
MRe 48
CT 49
Event encoding (decimal) ___________________________________________________ Answer tone (ANS) 32 /ANS 33 ANSam 34 /ANSam 35 Calling tone (CNG) 36 V.21 channel 1, "0" bit 37 V.21 channel 1, "1" bit 38 V.21 channel 2, "0" bit 39 V.21 channel 2, "1" bit 40 CRdi 41 CRdr 42 CRe 43 ESi 44 ESr 45 MRdi 46 MRdr 47 MRe 48 CT 49
Table 3: Data and fax named events
Table 3: Data and fax named events
3.12 Line Events
3.12 Line Events
Table 4 summarizes the events and tones that can appear on a subscriber line.
Table 4 summarizes the events and tones that can appear on a subscriber line.
ITU Recommendation E.182 [13] defines when certain tones should be used. It defines the following standard tones that are heard by the caller:
ITU Recommendation E.182 [13] defines when certain tones should be used. It defines the following standard tones that are heard by the caller:
Dial tone: The exchange is ready to receive address information.
Dial tone: The exchange is ready to receive address information.
Schulzrinne & Petrack Standards Track [Page 14] RFC 2833 Tones May 2000
Schulzrinne & Petrack Standards Track [Page 14] RFC 2833 Tones May 2000
PABX internal dial tone: The PABX is ready to receive address
information.
PABX internal dial tone: The PABX is ready to receive address information.
Special dial tone: Same as dial tone, but the caller's line is
subject to a specific condition, such as call diversion or a
voice mail is available (e.g., "stutter dial tone").
Special dial tone: Same as dial tone, but the caller's line is subject to a specific condition, such as call diversion or a voice mail is available (e.g., "stutter dial tone").
Second dial tone: The network has accepted the address
information, but additional information is required.
Second dial tone: The network has accepted the address information, but additional information is required.
Ring: This named signal event causes the recipient to generate an
alerting signal ("ring"). The actual tone or other indication
used to render this named event is left up to the receiver.
(This differs from the ringing tone, below, heard by the
caller
Ring: This named signal event causes the recipient to generate an alerting signal ("ring"). The actual tone or other indication used to render this named event is left up to the receiver. (This differs from the ringing tone, below, heard by the caller
Ringing tone: The call has been placed to the callee and a calling
signal (ringing) is being transmitted to the callee. This
tone is also called "ringback".
Ringing tone: The call has been placed to the callee and a calling signal (ringing) is being transmitted to the callee. This tone is also called "ringback".
Special ringing tone: A special service, such as call forwarding
or call waiting, is active at the called number.
Special ringing tone: A special service, such as call forwarding or call waiting, is active at the called number.
Busy tone: The called telephone number is busy.
Busy tone: The called telephone number is busy.
Congestion tone: Facilities necessary for the call are temporarily
unavailable.
Congestion tone: Facilities necessary for the call are temporarily unavailable.
Calling card service tone: The calling card service tone consists
of 60 ms of the sum of 941 Hz and 1477 Hz tones (DTMF '#'),
followed by 940 ms of 350 Hz and 440 Hz (U.S. dial tone),
decaying exponentially with a time constant of 200 ms.
Calling card service tone: The calling card service tone consists of 60 ms of the sum of 941 Hz and 1477 Hz tones (DTMF '#'), followed by 940 ms of 350 Hz and 440 Hz (U.S. dial tone), decaying exponentially with a time constant of 200 ms.
Special information tone: The callee cannot be reached, but the
reason is neither "busy" nor "congestion". This tone should
be used before all call failure announcements, for the
benefit of automatic equipment.
Special information tone: The callee cannot be reached, but the reason is neither "busy" nor "congestion". This tone should be used before all call failure announcements, for the benefit of automatic equipment.
Comfort tone: The call is being processed. This tone may be used
during long post-dial delays, e.g., in international
connections.
Comfort tone: The call is being processed. This tone may be used during long post-dial delays, e.g., in international connections.
Hold tone: The caller has been placed on hold.
Hold tone: The caller has been placed on hold.
Record tone: The caller has been connected to an automatic
answering device and is requested to begin speaking.
Record tone: The caller has been connected to an automatic answering device and is requested to begin speaking.
Schulzrinne & Petrack Standards Track [Page 15] RFC 2833 Tones May 2000
Schulzrinne & Petrack Standards Track [Page 15] RFC 2833 Tones May 2000
Caller waiting tone: The called station is busy, but has call
waiting service.
Caller waiting tone: The called station is busy, but has call waiting service.
Pay tone: The caller, at a payphone, is reminded to deposit
additional coins.
Pay tone: The caller, at a payphone, is reminded to deposit additional coins.
Positive indication tone: The supplementary service has been
activated.
Positive indication tone: The supplementary service has been activated.
Negative indication tone: The supplementary service could not be
activated.
Negative indication tone: The supplementary service could not be activated.
Off-hook warning tone: The caller has left the instrument off-hook
for an extended period of time.
Off-hook warning tone: The caller has left the instrument off-hook for an extended period of time.
The following tones can be heard by either calling or called party during a conversation:
The following tones can be heard by either calling or called party during a conversation:
Call waiting tone: Another party wants to reach the subscriber.
Call waiting tone: Another party wants to reach the subscriber.
Warning tone: The call is being recorded. This tone is not
required in all jurisdictions.
Warning tone: The call is being recorded. This tone is not required in all jurisdictions.
Intrusion tone: The call is being monitored, e.g., by an operator.
Intrusion tone: The call is being monitored, e.g., by an operator.
CPE alerting signal: A tone used to alert a device to an arriving
in-band FSK data transmission. A CPE alerting signal is a
combined 2130 and 2750 Hz tone, both with tolerances of 0.5%
and a duration of 80 to. 80 ms. The CPE alerting signal is
used with ADSI services and Call Waiting ID services [14].
CPE alerting signal: A tone used to alert a device to an arriving in-band FSK data transmission. A CPE alerting signal is a combined 2130 and 2750 Hz tone, both with tolerances of 0.5% and a duration of 80 to. 80 ms. The CPE alerting signal is used with ADSI services and Call Waiting ID services [14].
The following tones are heard by operators:
The following tones are heard by operators:
Payphone recognition tone: The person making the call or being
called is using a payphone (and thus it is ill-advised to
allow collect calls to such a person).
Payphone recognition tone: The person making the call or being called is using a payphone (and thus it is ill-advised to allow collect calls to such a person).
Schulzrinne & Petrack Standards Track [Page 16] RFC 2833 Tones May 2000
Schulzrinne & Petrack Standards Track [Page 16] RFC 2833 Tones May 2000
Event encoding (decimal)
_____________________________________________
Off Hook 64
On Hook 65
Dial tone 66
PABX internal dial tone 67
Special dial tone 68
Second dial tone 69
Ringing tone 70
Special ringing tone 71
Busy tone 72
Congestion tone 73
Special information tone 74
Comfort tone 75
Hold tone 76
Record tone 77
Caller waiting tone 78
Call waiting tone 79
Pay tone 80
Positive indication tone 81
Negative indication tone 82
Warning tone 83
Intrusion tone 84
Calling card service tone 85
Payphone recognition tone 86
CPE alerting signal (CAS) 87
Off-hook warning tone 88
Ring 89
Event encoding (decimal) _____________________________________________ Off Hook 64 On Hook 65 Dial tone 66 PABX internal dial tone 67 Special dial tone 68 Second dial tone 69 Ringing tone 70 Special ringing tone 71 Busy tone 72 Congestion tone 73 Special information tone 74 Comfort tone 75 Hold tone 76 Record tone 77 Caller waiting tone 78 Call waiting tone 79 Pay tone 80 Positive indication tone 81 Negative indication tone 82 Warning tone 83 Intrusion tone 84 Calling card service tone 85 Payphone recognition tone 86 CPE alerting signal (CAS) 87 Off-hook warning tone 88 Ring 89
Table 4: E.182 line events
Table 4: E.182 line events
3.13 Extended Line Events
3.13 Extended Line Events
Table 5 summarizes country-specific events and tones that can appear on a subscriber line.
Table 5 summarizes country-specific events and tones that can appear on a subscriber line.
3.14 Trunk Events
3.14 Trunk Events
Table 6 summarizes the events and tones that can appear on a trunk. Note that trunk can also carry line events (Section 3.12), as MF signaling does not include backward signals [15].
Table 6 summarizes the events and tones that can appear on a trunk. Note that trunk can also carry line events (Section 3.12), as MF signaling does not include backward signals [15].
ABCD transitional: 4-bit signaling used by digital trunks. For N-
state signaling, the first N values are used.
ABCD transitional: 4-bit signaling used by digital trunks. For N- state signaling, the first N values are used.
Schulzrinne & Petrack Standards Track [Page 17] RFC 2833 Tones May 2000
Schulzrinne & Petrack Standards Track [Page 17] RFC 2833 Tones May 2000
Event encoding (decimal)
___________________________________________________
Acceptance tone 96
Confirmation tone 97
Dial tone, recall 98
End of three party service tone 99
Facilities tone 100
Line lockout tone 101
Number unobtainable tone 102
Offering tone 103
Permanent signal tone 104
Preemption tone 105
Queue tone 106
Refusal tone 107
Route tone 108
Valid tone 109
Waiting tone 110
Warning tone (end of period) 111
Warning Tone (PIP tone) 112
Event encoding (decimal) ___________________________________________________ Acceptance tone 96 Confirmation tone 97 Dial tone, recall 98 End of three party service tone 99 Facilities tone 100 Line lockout tone 101 Number unobtainable tone 102 Offering tone 103 Permanent signal tone 104 Preemption tone 105 Queue tone 106 Refusal tone 107 Route tone 108 Valid tone 109 Waiting tone 110 Warning tone (end of period) 111 Warning Tone (PIP tone) 112
Table 5: Country-specific Line events
Table 5: Country-specific Line events
The T1 ESF (extended super frame format) allows 2, 4, and 16
state signaling bit options. These signaling bits are named
A, B, C, and D. Signaling information is sent as robbed bits
in frames 6, 12, 18, and 24 when using ESF T1 framing. A D4
superframe only transmits 4-state signaling with A and B
bits. On the CEPT E1 frame, all signaling is carried in
timeslot 16, and two channels of 16-state (ABCD) signaling
are sent per frame.
The T1 ESF (extended super frame format) allows 2, 4, and 16 state signaling bit options. These signaling bits are named A, B, C, and D. Signaling information is sent as robbed bits in frames 6, 12, 18, and 24 when using ESF T1 framing. A D4 superframe only transmits 4-state signaling with A and B bits. On the CEPT E1 frame, all signaling is carried in timeslot 16, and two channels of 16-state (ABCD) signaling are sent per frame.
Since this information is a state rather than a changing
signal, implementations SHOULD use the following triple-
redundancy mechanism, similar to the one specified in ITU-T
Rec. I.366.2 [16], Annex L. At the time of a transition, the
same ABCD information is sent 3 times at an interval of 5 ms.
If another transition occurs during this time, then this
continues. After a period of no change, the ABCD information
is sent every 5 seconds.
Since this information is a state rather than a changing signal, implementations SHOULD use the following triple- redundancy mechanism, similar to the one specified in ITU-T Rec. I.366.2 [16], Annex L. At the time of a transition, the same ABCD information is sent 3 times at an interval of 5 ms. If another transition occurs during this time, then this continues. After a period of no change, the ABCD information is sent every 5 seconds.
Wink: A brief transition, typically 120-290 ms, from on-hook
(unseized) to off-hook (seized) and back to onhook, used by
the incoming exchange to signal that the call address
signaling can proceed.
Wink: A brief transition, typically 120-290 ms, from on-hook (unseized) to off-hook (seized) and back to onhook, used by the incoming exchange to signal that the call address signaling can proceed.
Incoming seizure: Incoming indication of call attempt (off-hook).
Incoming seizure: Incoming indication of call attempt (off-hook).
Schulzrinne & Petrack Standards Track [Page 18] RFC 2833 Tones May 2000
Schulzrinne & Petrack Standards Track [Page 18] RFC 2833 Tones May 2000
Event encoding (decimal)
__________________________________________________
MF 0... 9 128...137
MF K0 or KP (start-of-pulsing) 138
MF K1 139
MF K2 140
MF S0 to ST (end-of-pulsing) 141
MF S1... S3 142...143
ABCD signaling (see below) 144...159
Wink 160
Wink off 161
Incoming seizure 162
Seizure 163
Unseize circuit 164
Continuity test 165
Default continuity tone 166
Continuity tone (single tone) 167
Continuity test send 168
Continuity verified 170
Loopback 171
Old milliwatt tone (1000 Hz) 172
New milliwatt tone (1004 Hz) 173
Event encoding (decimal) __________________________________________________ MF 0... 9 128...137 MF K0 or KP (start-of-pulsing) 138 MF K1 139 MF K2 140 MF S0 to ST (end-of-pulsing) 141 MF S1... S3 142...143 ABCD signaling (see below) 144...159 Wink 160 Wink off 161 Incoming seizure 162 Seizure 163 Unseize circuit 164 Continuity test 165 Default continuity tone 166 Continuity tone (single tone) 167 Continuity test send 168 Continuity verified 170 Loopback 171 Old milliwatt tone (1000 Hz) 172 New milliwatt tone (1004 Hz) 173
Table 6: Trunk events
Table 6: Trunk events
Seizure: Seizure by answering exchange, in response to outgoing
seizure.
Seizure: Seizure by answering exchange, in response to outgoing seizure.
Unseize circuit: Transition of circuit from off-hook to on-hook at
the end of a call.
Unseize circuit: Transition of circuit from off-hook to on-hook at the end of a call.
Wink off: A brief transition, typically 100-350 ms, from off-hook
(seized) to on-hook (unseized) and back to off-hook (seized).
Used in operator services trunks.
Wink off: A brief transition, typically 100-350 ms, from off-hook (seized) to on-hook (unseized) and back to off-hook (seized). Used in operator services trunks.
Continuity tone send: A tone of 2010 Hz.
Continuity tone send: A tone of 2010 Hz.
Continuity tone detect: A tone of 2010 Hz.
Continuity tone detect: A tone of 2010 Hz.
Continuity test send: A tone of 1780 Hz is sent by the calling
exchange. If received by the called exchange, it returns a
"continuity verified" tone.
Continuity test send: A tone of 1780 Hz is sent by the calling exchange. If received by the called exchange, it returns a "continuity verified" tone.
Continuity verified: A tone of 2010 Hz. This is a response tone,
used in dual-tone procedures.
Continuity verified: A tone of 2010 Hz. This is a response tone, used in dual-tone procedures.
Schulzrinne & Petrack Standards Track [Page 19] RFC 2833 Tones May 2000
Schulzrinne & Petrack Standards Track [Page 19] RFC 2833 Tones May 2000
4 RTP Payload Format for Telephony Tones
4 RTP Payload Format for Telephony Tones
4.1 Introduction
4.1 Introduction
As an alternative to describing tones and events by name, as described in Section 3, 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.
As an alternative to describing tones and events by name, as described in Section 3, 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.
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, across
all countries, these tones share a number of characteristics [17]:
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, across all countries, these tones share a number of characteristics [17]:
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 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 Tones for telephony events are in the range of 25 (ringing tone
in Angola) to 1800 Hz. CED is the highest used tone at 2100 Hz.
The telephone frequency range is limited to 3,400 Hz. (The
piano has a range from 27.5 to 4186 Hz.)
o Tones for telephony events are in the range of 25 (ringing tone in Angola) to 1800 Hz. CED is the highest used tone at 2100 Hz. The telephone frequency range is limited to 3,400 Hz. (The piano has a range from 27.5 to 4186 Hz.)
o Modulation frequencies range between 15 (ANSam tone) to 480 Hz
(Jamaica). Non-integer frequencies are used only for
frequencies of 16 2/3 and 33 1/3 Hz. (These fractional
frequencies appear to be derived from older AC power grid
frequencies.)
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. (These fractional frequencies appear to be derived from older AC power grid frequencies.)
o Tones that are not continuous have durations of less than four
seconds.
o Tones that are not continuous have durations of less than four seconds.
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] notes that different telephone companies require a tone accuracy of between 0.5 and 1.5%. The Recommendation suggests a frequency tolerance of 1%.
4.2 Examples of Common Telephone Tone Signals
4.2 Examples of Common Telephone Tone Signals
As an aid to the implementor, Table 7 summarizes some common tones. The rows labeled "ITU ..." refer to the general recommendation of Recommendation E.180 [18]. Note that there are no specific guidelines for these tones. In the table, the symbol "+" indicates addition of
As an aid to the implementor, Table 7 summarizes some common tones. The rows labeled "ITU ..." refer to the general recommendation of Recommendation E.180 [18]. Note that there are no specific guidelines for these tones. In the table, the symbol "+" indicates addition of
Schulzrinne & Petrack Standards Track [Page 20] RFC 2833 Tones May 2000
Schulzrinne & Petrack Standards Track [Page 20] RFC 2833 Tones May 2000
the tones, without modulation, while "*" indicates amplitude modulation. The meaning of some of the tones is described in Section 3.12 or Section 3.11 (for V.21).
the tones, without modulation, while "*" indicates amplitude modulation. The meaning of some of the tones is described in Section 3.12 or Section 3.11 (for V.21).
Tone name frequency on period off period
______________________________________________________
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 "0" bit, ch. 1 1180 0.00333
V.21 "1" bit, ch. 1 980 0.00333
V.21 "0" bit, ch. 2 1850 0.00333
V.21 "1" bit, ch. 2 1650 0.00333
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
U.S. busy tone 480+620 0.5 0.5
______________________________________________________
ITU congestion tone 425
U.S. congestion tone 480+620 0.25 0.25
期間の期間のトーン名前頻度______________________________________________________ CNG1100 0.5 3.0V.25 CT1300 0.5 2.0CED、2100、3.3、--、ANS、2100、3.3、--ANSam2100*15 3.3--「0インチはchに噛み付いた」V.21。 1 1180 0.00333 「1インチはchに噛み付いた」V.21。 1 980 0.00333 「0インチはchに噛み付いた」V.21。 2 1850 0.00333 「1インチはchに噛み付いた」V.21。 2 1650 0.00333 ITUダイヤルトーン425----米国が+440にトーン350にダイヤルする----______________________________________________________ ITU呼出音425 0.67--1.5 3--5米国呼出音440+480 2.0 4.0ITU話中音425米国話中音480+620 0.5 0.5______________________________________________________ ITU混雑トーン425米国混雑トーン480+620 0.25 0.25
Table 7: Examples of telephony tones
テーブル7: 電話トーンに関する例
4.3 Use of RTP Header Fields
4.3 RTPヘッダーフィールドの使用
Timestamp: The RTP timestamp reflects the measurement point for
the current packet. The event duration described in Section
3.5 extends forwards from that time.
タイムスタンプ: RTPタイムスタンプは現在のパケットのために測定ポイントを反映します。 セクション3.5で説明されたイベント持続時間はあの時以来前方に広がります。
4.4 Payload Format
4.4 有効搭載量形式
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 MIME type is "audio/tone".) The default timestamp rate is 8,000 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ペイロード書式を定義します。 (対応するMIMEの種類は「オーディオ/トーン」です。) デフォルトタイムスタンプレートは8,000Hzですが、他のレートは定義されるかもしれません。 タイムスタンプレートが頻度、まさしく持続時間の解釈に影響しないことに注意してください。
In accordance with current practice, this payload format does not have a static payload type number, but uses a RTP payload type number established dynamically and out-of-band.
現在の習慣に従って、このペイロード形式は、静的なペイロード形式数を持っていませんが、ダイナミックとバンドの外で確立されたRTPペイロード形式数を使用します。
It is shown in Fig. 3.
それは図3に示されます。
Schulzrinne & Petrack Standards Track [Page 21] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[21ページ]。
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 3: Payload format for tones
図3: トーンのための有効搭載量形式
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.
変調: 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に正確な頻度を許容します。
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.
The tone begins at the instant identified by the RTP
timestamp and lasts for the duration value.
持続時間: タイムスタンプユニットで測定されたトーンの持続時間。 トーンは、RTPタイムスタンプによって特定された瞬間に始まって、持続時間値のために持続します。
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,
頻度: 加えられた、Hzで測定された、12ビットの符号のない整数として表されるべきトーンの頻度。 分野サイズは、頻度を4095Hzまで表すために十分です。
Schulzrinne & Petrack Standards Track [Page 22] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[22ページ]。
which exceeds the range of telephone systems. A value of zero
indicates silence. A single tone can contain any number of
frequencies.
どれが電話ゼロの値の範囲を超えているかが沈黙を示します。 シングル・トーンはいろいろな頻度を含むことができます。
R: This field is reserved for future use. The sender MUST set it
to zero, the receiver MUST ignore it.
R: この分野は今後の使用のために予約されます。 送付者はゼロにそれを設定しなければならなくて、受信機はそれを無視しなければなりません。
4.5 Reliability
4.5 信頼性
This payload format uses the reliability mechanism described in Section 3.7.
このペイロード形式はセクション3.7で説明された信頼性のメカニズムを使用します。
5 Combining Tones and Named Events
5 トーンと命名された出来事を結合すること。
The payload formats in Sections 3 and 4 can be combined into a single payload using the method specified in RFC 2198. Fig. 4 shows an example. In that example, the RTP packet combines two "tone" and one "telephone-event" payloads. The payload types are chosen arbitrarily as 97 and 98, respectively, with a sample rate of 8000 Hz. Here, the redundancy format has the dynamic payload type 96.
RFC2198で指定された方法を使用することでセクション3と4におけるペイロード形式をただ一つのペイロードに結合できます。 図4は例を示しています。 その例では、RTPパケットは2「トーン」と1個の「電話出来事」ペイロードを結合します。 ペイロードタイプは97と98として8000Hzの見本郵送料率で任意にそれぞれ選ばれています。 ここで、冗長形式で、ダイナミックなペイロードは96をタイプします。
The packet represents a snapshot of U.S. ringing tone, 1.5 seconds (12,000 timestamp units) into the second "on" part of the 2.0/4.0 second cadence, i.e., a total of 7.5 seconds (60,000 timestamp units) into the ring cycle. The 440 + 480 Hz tone of this second cadence started at RTP timestamp 48,000. Four seconds of silence preceded it, but since RFC 2198 only has a fourteen-bit offset, only 2.05 seconds (16383 timestamp units) can be represented. Even though the tone sequence is not complete, the sender was able to determine that this is indeed ringback, and thus includes the corresponding named event.
パケットはリングサイクルまですなわち、米国呼出音、2番目のリズムの2番目の“on"部分への1.5秒(1万2000タイムスタンプユニット)、合計7.5秒(6万タイムスタンプユニット)のスナップを表します。 この2番目のリズムの440+480HzのトーンはRTPタイムスタンプ48,000で始まりました。 4秒の沈黙はそれに先行しましたが、RFC2198には14ビットのオフセットがあるだけであるので、ほんの2.05秒(16383タイムスタンプユニット)を表すことができます。 調子連鎖は完全ではありませんが、送付者は、これが本当にringbackであり、その結果、対応する命名された出来事を含んでいることを決定できました。
6 MIME Registration
6 MIME登録
6.1 audio/telephone-event
6.1電話オーディオ/出来事
MIME media type name: audio
MIMEメディア型名: オーディオ
MIME subtype name: telephone-event
MIME「副-タイプ」は以下を命名します。 電話出来事
Required parameters: none.
必要なパラメタ: なし。
Schulzrinne & Petrack Standards Track [Page 23] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[23ページ]。
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 |P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 96 | 31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 48000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 98 | 16383 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 16383 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT |
|0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event=ring |0|0| volume=0 | duration=28383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|P|X| CC|M| 太平洋標準時| 一連番号| | 2 |0|0| 0 |0| 96 | 31 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| | 48000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| | 0x5234a8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| 太平洋標準時のブロック| タイムスタンプオフセット| ブロック長| |1| 98 | 16383 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| 太平洋標準時のブロック| タイムスタンプオフセット| ブロック長| |1| 97 | 16383 | 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| 太平洋標準時のブロック| |0| 97 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | イベント=リング|0|0| ボリューム=0| 持続時間=28383| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=63 | duration=16383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=0 |0 0 0 0| frequency=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 変調=0|0| ボリューム=63| 持続時間=16383| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| 頻度=0|0 0 0 0| 頻度=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=5 | duration=12000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=440 |0 0 0 0| frequency=480 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 変調=0|0| ボリューム=5| 持続時間=12000| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| 頻度=440|0 0 0 0| 頻度=480| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Combining tones and events in a single RTP packet
図4: 単一のRTPパケットのトーンと出来事を結合します。
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 either be a
single integer or two integers separated by a hyphen. No
white space is allowed in the argument. The integers
designate the event numbers supported by the implementation.
All implementations MUST support events 0 through 15, so that
the parameter can be omitted if the implementation only
supports these events.
任意のパラメタ: 「出来事」パラメタは実現で支持された出来事を記載します。 出来事は1つ以上のコンマで切り離された要素として記載されています。 各要素は、ハイフンによって切り離されたただ一つの整数か2つの整数のどちらかであるかもしれません。 余白は全く議論で許容されていません。 整数は実現で支持されたイベント番号を指定します。 すべての実現が0〜15に出来事を支持しなければなりません、実現がこれらの出来事を支持するだけであるならパラメタを省略できるように。
Schulzrinne & Petrack Standards Track [Page 24] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[24ページ]。
The "rate" parameter describes the sampling rate, in Hertz.
The number is written as a floating point number or as an
integer. If omitted, the default value is 8000 Hz.
「レート」パラメタはHertzで標本抽出率について説明します。 数は浮動小数点として、または、整数として書かれています。 省略されるなら、デフォルト値は8000Hzです。
Encoding considerations: This type is only defined for transfer
via RTP [1].
問題をコード化します: このタイプは転送のためにRTP[1]を通して定義されるだけです。
Security considerations: See the "Security Considerations"
(Section 7) section in this document.
セキュリティ問題: 本書では「セキュリティ問題」(セクション7)セクションを見てください。
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:
追加情報:
1. Magic number(s): N/A
1. マジックナンバー(s): なし
2. File extension(s): N/A
2. ファイル拡張子(s): なし
3. Macintosh file type code: N/A
3. マッキントッシュファイルの種類コード: なし
6.2 audio/tone
6.2 オーディオ/トーン
MIME media type name: audio
MIMEメディア型名: オーディオ
MIME subtype name: tone
MIME「副-タイプ」は以下を命名します。 トーン
Required parameters: none
必要なパラメタ: なし
Optional parameters: The "rate" parameter describes the sampling
rate, in Hertz. The number is written as a floating point
number or as an integer. If omitted, the default value is
8000 Hz.
任意のパラメタ: 「レート」パラメタはHertzで標本抽出率について説明します。 数は浮動小数点として、または、整数として書かれています。 省略されるなら、デフォルト値は8000Hzです。
Encoding considerations: This type is only defined for transfer
via RTP [1].
問題をコード化します: このタイプは転送のためにRTP[1]を通して定義されるだけです。
Security considerations: See the "Security Considerations"
(Section 7) section in this document.
セキュリティ問題: 本書では「セキュリティ問題」(セクション7)セクションを見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification: This document.
広められた仕様: このドキュメント。
Schulzrinne & Petrack Standards Track [Page 25] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[25ページ]。
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:
追加情報:
1. Magic number(s): N/A
1. マジックナンバー(s): なし
2. File extension(s): N/A
2. ファイル拡張子(s): なし
3. Macintosh file type code: N/A
3. マッキントッシュファイルの種類コード: なし
7 Security Considerations
7 セキュリティ問題
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification (RFC 1889 [1]), and any appropriate RTP profile (for example RFC 1890 [19]).This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
いずれもRTPプロフィールを当てます。そして、この仕様に基づき定義されたペイロード書式を使用するRTPパケットはRTP仕様で議論したセキュリティ問題を受けることがある、(RFC1889[1])、(例えば、RFC1890[19]).Thisが、メディアの流れの秘密性が暗号化で達成されるのを含意します。 このペイロード形式と共に使用されるデータ圧縮が適用された終わりから終わりであるので、暗号化が圧縮の後に実行されるかもしれないので、2つの操作の間には、闘争が全くありません。
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.
パケット処理が潜在的サービスの否定の脅威を引き起こすように、このペイロードタイプは受信機サイド計算量における少しの重要な非の一様性も示しません。
In older networks employing in-band signaling and lacking appropriate tone filters, the tones in Section 3.14 may be used to commit toll fraud.
バンドにおけるシグナリングと欠いている適切なトーンフィルタを使うより古いネットワークでは、セクション3.14におけるトーンは、料金詐欺を犯すのに使用されるかもしれません。
Additional security considerations are described in RFC 2198 [6].
追加担保問題はRFC2198[6]で説明されます。
8 IANA Considerations
8 IANA問題
This document defines two new RTP payload formats, named telephone- event and tone, and associated Internet media (MIME) types, audio/telephone-event and audio/tone.
このドキュメントは2つの新しいRTPペイロード書式、命名された電話出来事、トーン、関連インターネットメディア(MIME)タイプ、電話オーディオ/出来事、およびオーディオ/トーンを定義します。
Within the audio/telephone-event type, additional events MUST be registered with IANA. Registrations are subject to approval by the current chair of the IETF audio/video transport working group, or by an expert designated by the transport area director if the AVT group has closed.
電話オーディオ/イベントタイプの中では、追加出来事をIANAに登録しなければなりません。 登録証明書はIETFオーディオ/ビデオ輸送ワーキンググループの現在のいす、またはAVTグループが休んだなら輸送領域ディレクターによって任命された専門家による承認を必要としています。
Schulzrinne & Petrack Standards Track [Page 26] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[26ページ]。
The meaning of new events MUST be documented either as an RFC or an equivalent standards document produced by another standardization body, such as ITU-T.
RFCか同等な規格文書が別の標準化本体によって製作されたITU-Tなどのように新しい出来事の意味を記録しなければなりません。
9 Acknowledgements
9つの承認
The suggestions of the Megaco working group are gratefully acknowledged. Detailed advice and comments were provided by Fred Burg, Steve Casner, Fatih Erdin, Bill Foster, Mike Fox, Gunnar Hellstrom, Terry Lyons, Steve Magnell, Vern Paxson and Colin Perkins.
Megacoワーキンググループの提案は感謝して承諾されます。 詳細なアドバイスとコメントはフレッドBurg、スティーブCasner、ファティーErdin、ビル・フォスター、マイクフォックス、グナー・ヘルストリョーム、テリー・リヨン、スティーブMagnell、バーン・パクソン、およびコリン・パーキンスによって提供されました。
10 Authors' Addresses
10人の作者のアドレス
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenueニューヨーク10027ニューヨーク(米国)のヘニングSchulzrinne部
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Scott Petrack MetaTel 45 Rumford Avenue Waltham, MA 02453 USA
スコットPetrack MetaTel45ラムフォードAvenue MA02453ウォルサム(米国)
EMail: scott.petrack@metatel.com
メール: scott.petrack@metatel.com
11 Bibliography
11 図書目録
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[1]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] International Telecommunication Union, "Procedures for starting
sessions of data transmission over the public switched telephone
network," Recommendation V.8, Telecommunication Standardization
Sector of ITU, Geneva, Switzerland, Feb. 1998.
[3] 国際電気通信連合、「公衆の上でデータ伝送のセッションを始めるための手順は電話網を切り換えました」、Recommendation V.8、ITUのTelecommunication Standardization Sector、ジュネーブ(スイス)1998年2月。
[4] R. Kocen and T. Hatala, "Voice over frame relay implementation
agreement", Implementation Agreement FRF.11, Frame Relay Forum,
Foster City, California, Jan. 1997.
[4] R.KocenとT.Hatala、「フレームリレー実現協定の上の声」、Implementation Agreement FRF.11(Frame Relay Forum、フォスター市(カリフォルニア)の1997年1月)。
Schulzrinne & Petrack Standards Track [Page 27] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[27ページ]。
[5] International Telecommunication Union, "Multifrequency push-
button signal reception," Recommendation Q.24, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, 1988.
[5]国際電気通信連合、「多重周波数がボタンの信号レセプションを押す」Recommendation Q.24、ITUのTelecommunication Standardization Sector、ジュネーブスイス1988。
[6] 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.
[6] パーキンスとC.とKouvelasとI.とホドソンとO.とハードマンとV.とハンドレーとM.とBolot、J.とベガ-ガルシアとA.とS.堀-Parisis、「余分なオーディオデータのためのRTP有効搭載量」RFC2198(1997年9月)。
[7] Handley M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[7] ハンドレーM.とV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[8] International Telecommunication Union, "Automatic answering
equipment and general procedures for automatic calling equipment
on the general switched telephone network including procedures
for disabling of echo control devices for both manually and
automatically established calls," Recommendation V.25,
Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, Oct. 1996.
[8] 国際電気通信連合、「手動的で自動的に両方のためのエコー制御装置を無能にする手順を含む一般的な切り換えられた電話網の自動呼び出し装置のための自動応答装置と基本手順は呼び出しを確立しました」、Recommendation V.25、ITUのTelecommunication Standardization Sector、ジュネーブ(スイス)1996年10月。
[9] International Telecommunication Union, "Procedures for document
facsimile transmission in the general switched telephone
network," Recommendation T.30, Telecommunication Standardization
Sector of ITU, Geneva, Switzerland, July 1996.
[9] 国際電気通信連合、「司令官におけるドキュメントファクシミリ伝送のための手順は電話網を切り換えました」、Recommendation T.30、ITUのTelecommunication Standardization Sector、ジュネーブ(スイス)1996年7月。
[10] International Telecommunication Union, "Echo cancellers,"
Recommendation G.165, Telecommunication Standardization Sector
of ITU, Geneva, Switzerland, Mar. 1993.
[10]国際電気通信連合、「エコーキャンセラー」、Recommendation G.165、ITUのTelecommunication Standardization Sector、ジュネーブスイス1993年3月。
[11] International Telecommunication Union, "A modem operating at
data signaling rates of up to 33 600 bit/s for use on the
general switched telephone network and on leased point-to-point
2-wire telephone-type circuits," Recommendation V.34,
Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, Feb. 1998.
[11] 国際電気通信連合、「司令官における使用のために最大33のデータ信号速度で600ビット/sを操作するモデムは電話網と賃貸された二地点間2有線電話タイプサーキットを切り換えました」、Recommendation V.34、ITUのTelecommunication Standardization Sector、ジュネーブ(スイス)1998年2月。
[12] International Telecommunication Union, "Procedures for the
identification and selection of common modes of operation
between data circuit-terminating equipments (DCEs) and between
data terminal equipments (DTEs) over the public switched
telephone network and on leased point-to-point telephone-type
circuits," Recommendation V.8bis, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Sept. 1998.
[12] 国際電気通信連合、「公衆電話交換網の上と、そして、賃貸されたポイントツーポイントにおけるサーキットを終えるデータ機器(DCEs)とデータ端末装置の間の一般的な運転モード(DTEs)の識別と品揃えのための手順はサーキットを電話でタイプします」、Recommendation V.8bis、ITUのTelecommunication Standardization Sector、ジュネーブ(スイス)1998年9月。
[13] International Telecommunication Union, "Application of tones and
recorded announcements in telephone services," Recommendation
E.182, Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, Mar. 1998.
[13]国際電気通信連合、「電話サービスにおけるトーンと記録された発表の応用。」(Recommendation E.182、ITUのTelecommunication Standardization Sector、ジュネーブスイス1998年3月)
Schulzrinne & Petrack Standards Track [Page 28] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[28ページ]。
[14] Bellcore, "Functional criteria for digital loop carrier
systems," Technical Requirement TR-NWT-000057, Telcordia
(formerly Bellcore), Morristown, New Jersey, Jan. 1993.
[14]Bellcore、「デジタルループ搬送システムの機能的な評価基準」、Technical Requirement TR-NWT-000057、Telcordia(以前Bellcore)、モリスタウン(ニュージャージー)1993年1月。
[15] J. G. van Bosse, Signaling in Telecommunications Networks
Telecommunications and Signal Processing, New York, New York:
Wiley, 1998.
[15] J.G.バンBosseとTelecommunications Networks TelecommunicationsのSignalingとSignal Processing、ニューヨーク(ニューヨーク): ワイリー、1998。
[16] International Telecommunication Union, "AAL type 2 service
specific convergence sublayer for trunking," Recommendation
I.366.2, Telecommunication Standardization Sector of ITU,
Geneva, Switzerland, Feb. 1999.
[16] 国際電気通信連合、「AALタイプ2は中継方式のために特定の集合副層を修理します」、Recommendation I.366.2、ITUのTelecommunication Standardization Sector、ジュネーブ(スイス)1999年2月。
[17] International Telecommunication Union, "Various tones used in
national networks," Recommendation Supplement 2 to
Recommendation E.180, Telecommunication Standardization Sector
of ITU, Geneva, Switzerland, Jan. 1994.
[17] 国際電気通信連合、「様々なトーンは国家でネットワークを使用しました」、Recommendation E.180へのRecommendation Supplement2、ITUのTelecommunication Standardization Sector、ジュネーブ(スイス)1994年1月。
[18] International Telecommunication Union, "Technical
characteristics of tones for telephone service," Recommendation
Supplement 2 to Recommendation E.180, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Jan. 1994.
[18]国際電気通信連合、「電話サービスのためのトーンの技術的な特性」、Recommendation E.180、ITUのTelecommunication Standardization Sector、ジュネーブスイス(1994年1月)へのRecommendation Supplement2。
[19] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC 1890, January 1996.
[19]Schulzrinne、H.、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC1890、1996年1月。
Schulzrinne & Petrack Standards Track [Page 29] RFC 2833 Tones May 2000
Schulzrinne&Petrack規格は2000年5月にRFC2833トーンを追跡します[29ページ]。
12 Full Copyright Statement
12 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Schulzrinne & Petrack Standards Track [Page 30]
Schulzrinne&Petrack標準化過程[30ページ]
一覧
スポンサーリンク
