Internet Engineering Task Force (IETF) E. Ivov, Ed.
Request for Comments: 6465 Jitsi
Category: Standards Track E. Marocco, Ed.
ISSN: 2070-1721 Telecom Italia
J. Lennox
Vidyo
December 2011
A Real-time Transport Protocol (RTP) Header Extension for
Mixer-to-Client Audio Level Indication
Abstract
抽象
This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to.
この文書では、個々の参加者の音声レベルに関する情報を提供するために、音声会議にRTPレベルのミキサーのためのメカニズムを説明しています。そのような音声レベルインジケータは、それらがに関するオーディオデータと同一のRTPパケットで搬送されます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6465.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6465で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Protocol Operation ..............................................4
4. Audio Levels ....................................................5
5. Signaling Information ...........................................7
6. Security Considerations .........................................9
7. IANA Considerations ............................................10
8. Acknowledgments ................................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................11
Appendix A. Reference Implementation ..............................12
A.1. AudioLevelCalculator.java .................................12
"A Framework for Conferencing with the Session Initiation Protocol (SIP)" [RFC4353] presents an overall architecture for multi-party conferencing. Among others, the framework borrows from RTP [RFC3550] and extends the concept of a mixer entity "responsible for combining the media streams that make up a conference, and generating one or more output streams that are delivered to recipients". Every participant would hence receive, in a flat single stream, media originating from all the others.
[RFC4353]「セッション開始プロトコル（SIP）との会議のためのフレームワークは、」マルチパーティ会議の全体的なアーキテクチャを提示します。中でも、フレームワークは、RTP [RFC3550]から借用し、「会議を構成するメディアストリームを結合し、受信者に配信される1つ以上の出力ストリームを生成するための責任を負う」ミキサーエンティティの概念を拡張します。すべての参加者は、したがって、メディアが他のすべてに起因する、フラットな単一ストリームでは、受け取ることになります。
Using such centralized mixer-based architectures simplifies support for conference calls on the client side, since they would hardly differ from one-to-one conversations. However, the method also introduces a few limitations. The flat nature of the streams that a mixer would output and send to participants makes it difficult for users to identify the original source of what they are hearing.
こうした集中型のミキサーベースのアーキテクチャを使用すると、彼らはほとんど1対1の会話異なるなくなるので、会議のためのサポートは、クライアント側で呼び出す簡素化します。しかし、この方法はまた、いくつかの制限が導入されました。ミキサーは、参加者に出力して送信することをストリームのフラットな性質は、それが困難なユーザーは、彼らが聞いているかのオリジナルのソースを識別できるようになります。
Mechanisms that allow the mixer to send to participants cues on current speakers (e.g., the contributing source (CSRC) fields in RTP [RFC3550]) only work for speaking/silent binary indications. There are, however, a number of use cases where one would require more detailed information. Possible examples include the presence of background chat/noise/music/typing, someone breathing noisily in their microphone, or other cases where identifying the source of the disturbance would make it easy to remove it (e.g., by sending a private IM to the concerned party asking them to mute their microphone). A more advanced scenario could involve an intense discussion between multiple participants that the user does not personally know. Audio level information would help better recognize the speakers by associating with them complex (but still human readable) characteristics like loudness and speed, for example.
ミキサーは、現在のスピーカ（例えば、RTP [RFC3550]に貢献ソース（CSRC）フィールド）だけ/サイレントバイナリ表示を話すために働くに参加キューに送信することを可能にする機構。 1は、より詳細な情報を必要とするユースケースの数は、しかし、があります。可能な例は、障害の発生源を特定することは心配にプライベートIMを送信することにより、例えば（それを削除することが容易になるだろう背景チャット/ノイズ/音楽/タイピングの存在、そのマイクで音を立て呼吸誰か、あるいは他の例を含めます党）自分のマイクをミュートすることを求めます。より高度なシナリオでは、ユーザーが個人的に知っていない複数の参加者の間で激しい議論を伴う可能性があります。オーディオレベルの情報は、より良い例えば、彼らとラウドネスや速度などの複雑な（しかしまだ人間が読める）の特性を関連付けることにより、スピーカーを認識しやすくなります。
One way of presenting such information in a user-friendly manner would be for a conferencing client to attach audio level indicators to the corresponding participant-related components in the user interface. One possible example is displayed in Figure 1, where levels can help users determine that Alice is currently the active speaker, Carol is mute, and Bob and Dave are sending some background noise.
ユーザーフレンドリーな方法でそのような情報を提示する一つの方法は、ユーザーインターフェイスに対応する参加者関連のコンポーネントにオーディオレベル表示を添付する会議クライアントのためになります。 1つの可能な例は、レベルは、ユーザーが、アリスが、現在アクティブスピーカであることを決定することができ、図1に表示され、キャロルはミュートされ、ボブとDaveは、いくつかのバックグラウンドノイズを送信します。
________________________
| |
| 00:42 | Weekly Call |
|________________________|
| |
| |
| Alice |====== | (S) |
| |
| Bob |= | |
| |
| Carol | | (M) |
| |
| Dave |=== | |
| |
|________________________|
Figure 1: Displaying Detailed Speaker Information to the User by Including Audio Level for Every Participant
図1：すべての参加者の音声レベルを含めることにより、ユーザーに詳細なスピーカー情報の表示
Implementing a user interface like the above requires analysis of the media sent from other participants. In a conventional audio conference, this is only possible for the mixer, since all other conference participants are generally receiving a single, flat audio stream and therefore have no immediate way of determining individual audio levels.
上記のようなユーザインタフェースを実装する他の参加者から送信されたメディアの分析を必要とします。従来の音声会議では、これは、他のすべての会議参加者は、一般的に単一の平坦オーディオストリームを受信し、したがって、個々のオーディオレベルを決定するための即時方法を持たないので、ミキサーのためにのみ可能です。
This document specifies an RTP extension header that allows such mixers to deliver audio level information to conference participants by including it directly in the RTP packets transporting the corresponding audio data.
この文書では、このようなミキサーは、対応するオーディオデータを搬送するRTPパケットに直接それを含めることによって、参加者を会議に音声レベル情報を配信することを可能にするRTP拡張ヘッダを指定します。
The header extension in this document is different than, but complementary to, the one defined in [RFC6464], which defines a mechanism by which clients can indicate to audio mixers the levels of the audio in the packets they send.
この文書のヘッダ拡張子が異なるが、クライアントが送信するパケットにオーディオミキサーに音声のレベルを示すことができるメカニズムを定義[RFC6464]で定義されたもの、に相補的です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
According to RFC 3550 [RFC3550], a mixer is expected to include in outgoing RTP packets a list of identifiers (CSRC IDs) indicating the sources that contributed to the resulting stream. The presence of such CSRC IDs allows RTP clients to determine, in a binary way, the active speaker(s) in any given moment. The RTP Control Protocol (RTCP) also provides a basic mechanism to map the CSRC IDs to user identities through the CNAME field. More advanced mechanisms can exist, depending on the signaling protocol used to establish and control a conference. In the case of the Session Initiation Protocol [RFC3261], for example, "A Session Initiation Protocol (SIP) Event Package for Conference State" [RFC4575] defines a <src-id> tag that binds CSRC IDs to media streams and SIP URIs.
RFC 3550 [RFC3550]によれば、ミキサは、発信RTPが得られたストリームに貢献源を示す識別子（CSRCのID）のリストをパケットに含めることが予想されます。そのようなCSRC IDの存在は、任意の所与の瞬間にアクティブスピーカ（複数可）、バイナリように、RTPクライアントが決定することを可能にします。 RTP制御プロトコル（RTCP）もCNAMEフィールドを介してユーザIDにCSRC IDをマッピングするための基本的なメカニズムを提供します。より高度なメカニズムが確立し、会議を制御するために使用されるシグナリングプロトコルに応じて、存在することができます。セッション開始プロトコル[RFC3261]の場合には、例えば、「会議状態のためのAのセッション開始プロトコル（SIP）イベントパッケージ」[RFC4575]は、メディアストリームにCSRC IDを結合する<SRC-ID>タグとSIP URIを定義します。
This document describes an RTP header extension that allows mixers to indicate the audio level of every contributing conference participant (CSRC) in addition to simply indicating their on/off status. This new header extension uses the general mechanism for RTP header extensions as described in [RFC5285].
この文書では、ミキサーは、単に彼らのオン/オフ状態を示すことに加えて、すべての貢献会議参加（CSRC）のオーディオレベルを示すことを可能にするRTPヘッダ拡張を記述しています。この新しいヘッダ拡張は、[RFC5285]に記載されているように、RTPヘッダ拡張のための一般的なメカニズムを使用します。
Each instance of this header contains a list of one-octet audio levels expressed in -dBov, with values from 0 to 127 representing 0 to -127 dBov (see Figures 2 and 3). Appendix A provides a reference implementation indicating one way of obtaining such values from raw audio samples.
このヘッダの各インスタンスは、1オクテットのオーディオレベルのリストを含む-127 0を表す0から127までの値dBov（図2および図3を参照）と、-dBovで発現。付録Aは、生音声サンプルからそのような値を得る一つの方法を示すリファレンス実装を提供します。
Every audio level value pertains to the CSRC identifier located at the corresponding position in the CSRC list. In other words, the first value would indicate the audio level of the conference participant represented by the first CSRC identifier in that packet, and so forth. The number and order of these values MUST therefore match the number and order of the CSRC IDs present in the same packet.
すべての音声レベル値は、CSRCリスト内の対応する位置にCSRC識別子に関係します。換言すれば、最初の値は、等、パケットの最初のCSRC識別子によって表される会議参加者の音声レベルを示し、あろう。これらの値の数および順序は、従って、同じパケット内に存在CSRC IDの数と順序と一致しなければなりません。
When encoding audio level information, a mixer SHOULD include in a packet information that corresponds to the audio data being transported in that same packet. It is important that these values follow the actual stream as closely as possible. Therefore, a mixer SHOULD also calculate the values after the original contributing stream has undergone possible processing such as level normalization, and noise reduction, for example.
音声レベルの情報を符号化するとき、ミキサは、同じパケットで搬送されるオーディオデータに対応するパケット情報に含めるべきです。これらの値はできるだけ実際の流れに従うことが重要です。オリジナル寄与ストリームは、例えば、そのようなレベルの正規化、ノイズ低減として可能な処理を受けた後したがって、ミキサはまた、値を計算する必要があります。
It can sometimes happen that a conference involves more than a single mixer. In such cases, each of the mixers MAY choose to relay the CSRC list and audio level information they receive from peer mixers (as long as the total CSRC count remains below 16). Given that the maximum audio level is not precisely defined by this specification, it is likely that in such situations average audio levels would be perceptibly different for the participants located behind the different mixers.
時々会議は、単一のミキサーよりも多くを含むことが起こることができます。このような場合には、ミキサの各々は、CSRCリストと、それらがピア・ミキサー（限り総CSRCカウントが16を下回ったままのように）から受信した音声レベル情報を中継するために選ぶかもしれ。最大音声レベルを正確にこの仕様で定義されていないことを考えると、そのような状況では、平均音声レベルが異なるミキサの背後に位置参加者にとって知覚的に異なるであろうと思われます。
The audio level header extension carries the level of the audio in the RTP payload of the packet with which it is associated. This information is carried in an RTP header extension element as defined by "A General Mechanism for RTP Header Extensions" [RFC5285].
音声レベルのヘッダの拡張は、それが関連付けられているパケットのRTPペイロード内のオーディオのレベルを運びます。 「RTPヘッダ拡張のための一般的なメカニズム」[RFC5285]で定義されるように、この情報は、RTPヘッダ拡張要素で運ばれます。
The payload of the audio level header extension element can be encoded using either the one-byte or two-byte header defined in [RFC5285]. Figures 2 and 3 show sample audio level encodings with each of these header formats.
音声レベルのヘッダ拡張要素のペイロードは1バイトまたは[RFC5285]で定義された2バイトのヘッダのいずれかを使用して符号化することができます。これらのヘッダ・フォーマットのそれぞれと図2及び図3のサンプルオーディオレベルエンコーディングを図。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len=2 |0| level 1 |0| level 2 |0| level 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Sample Audio Level Encoding Using the
One-Byte Header Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len=3 |0| level 1 |0| level 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| level 3 | 0 (pad) | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Sample Audio Level Encoding Using the
Two-Byte Header Format
In the case of the one-byte header format, the 4-bit len field is the number minus one of data bytes (i.e., audio level values) transported in this header extension element following the one-byte header. Therefore, the value zero in this field indicates that one byte of data follows. In the case of the two-byte header format, the 8-bit len field contains the exact number of audio levels carried in the extension. RFC 3550 [RFC3550] only allows RTP packets to carry a maximum of 15 CSRC IDs. Given that audio levels directly refer to CSRC IDs, implementations MUST NOT include more than 15 audio level values. The maximum value allowed in the len field is therefore 14 for the one-byte header format and 15 for the two-byte header format.
1バイトのヘッダフォーマットの場合には、4ビットのLENフィールドは、数マイナス1バイトのヘッダを以下このヘッダー拡張要素に転送されるデータバイトの1つ（すなわち、音声レベル値）です。したがって、このフィールドの値はゼロでは1バイトのデータが続くことを示しています。 2バイトのヘッダフォーマットの場合には、8ビットのLENフィールドは、拡張で搬送されるオーディオレベルの正確な数を含んでいます。 RFC 3550 [RFC3550]は唯一のRTPパケットは15のCSRC IDの最大値を運ぶことを可能にします。オーディオレベルを直接CSRC IDに参照することを考えると、実装は、15の以上の音声レベル値を含んではいけません。 LENフィールドに許容される最大値は、従って、14 1バイトのヘッダフォーマット及び2バイトのヘッダ形式の15のためのものです。
Note: Audio levels in this document are defined in the same manner as is audio noise level in the RTP Payload Comfort Noise specification [RFC3389]. In [RFC3389], the overall magnitude of the noise level in comfort noise is encoded into the first byte of the payload, with spectral information about the noise in subsequent bytes. This specification's audio level parameter is defined so as to be identical to the comfort noise payload's noise-level byte.
注：RTPペイロードコンフォートノイズ仕様[RFC3389]にオーディオノイズレベルがあるように、この文書に記載されているオーディオのレベルは同様に定義されています。 [RFC3389]に、快適ノイズのノイズレベルの全体的な大きさは、後続のバイトのノイズに関するスペクトル情報と、ペイロードの最初のバイトに符号化されます。コンフォートノイズのペイロードのノイズレベルのバイトに一致するように、この仕様のオーディオレベルのパラメータが定義されます。
The magnitude of the audio level itself is packed into the seven least significant bits of the single byte of the header extension, shown in Figures 2 and 3. The least significant bit of the audio level magnitude is packed into the least significant bit of the byte. The most significant bit of the byte is unused and always set to 0.
オーディオレベル自体の大きさは、音声レベルの大きさの最下位ビットはバイトの最下位ビットにパックされたヘッダ、図2に示されている拡張、および3の単一バイトの7つの最下位ビットにパックされています。バイトの最上位ビットは未使用、常に0に設定されています。
The audio level is expressed in -dBov, with values from 0 to 127 representing 0 to -127 dBov. dBov is the level, in decibels, relative to the overload point of the system, i.e., the highest-intensity signal encodable by the payload format. (Note: Representation relative to the overload point of a system is particularly useful for digital implementations, since one does not need to know the relative calibration of the analog circuitry.) For example, in the case of u-law (audio/pcmu) audio [ITU.G711], the 0 dBov reference would be a square wave with values +/- 8031. (This translates to 6.18 dBm0, relative to u-law's dBm0 definition in Table 6 of [ITU.G711].)
オーディオレベルは-127 dBovに0を表す0から127までの値で、-dBovで発現されます。 dBovは、デシベル単位で、ペイロード形式により、すなわち、最高強度信号の符号化可能システムの過負荷点に対するレベルです。 （注：一方はアナログ回路の相対的なキャリブレーションを知る必要がないので、システムの過負荷ポイントに表現に対しては、デジタル実装するために特に有用である。）、例えば、U字法の場合（オーディオ/ PCMU）にオーディオ[ITU.G711]、0 dBov基準は、値+/- 8031の方形波であろう（これは[ITU.G711]の表6のU-法則のdBm0で定義に対して6.18 dBm0で、に変換されます。）
The audio level for digital silence -- for a muted audio source, for example -- MUST be represented as 127 (-127 dBov), regardless of the dynamic range of the encoded audio format.
デジタル無音のオーディオレベル - ミュートオーディオソースの、例えば - かかわらず、エンコードされたオーディオフォーマットのダイナミックレンジの、127（-127 dBov）として表現されなければなりません。
The audio level header extension only carries the level of the audio in the RTP payload of the packet with which it is associated, with no long-term averaging or smoothing applied. That level is measured as a root mean square of all the samples in the measured range.
音声レベルのヘッダの拡張のみ印加されていない長期平均化または平滑化と、それが関連付けられているパケットのRTPペイロード内のオーディオのレベルを、運びます。そのレベルは、測定範囲内の全てのサンプルの二乗平均平方根として測定されます。
To simplify implementation of the encoding procedures described here, this specification provides a sample Java implementation (see Appendix A) of an audio level calculator that helps obtain such values from raw linear Pulse Code Modulation (PCM) audio samples.
ここに記載の符号化手順の実装を簡素化するために、この仕様は、サンプルのJava実装を提供生線形パルス符号変調（PCM）オーディオサンプルからそのような値を得るのに役立つ音声レベル算出の（付録A参照）。
The URI for declaring the audio level header extension in a Session Description Protocol (SDP) extmap attribute and mapping it to a local extension header identifier is "urn:ietf:params:rtp-hdrext:csrc-audio-level". There is no additional setup information needed for this extension (i.e., no extension attributes).
セッション記述プロトコル（SDP）extmap属性における音声レベルヘッダ拡張を宣言し、ローカル拡張ヘッダ識別子にマッピングするためのURIは、「IETF：paramsは：RTP-hdrext：CSRC音声レベルURN」です。この拡張機能（すなわち、拡張子属性なし）のために必要な追加の設定情報がありません。
An example attribute line in the SDP for a conference might be:
会議のSDPの例の属性行は次のようになります。
a=extmap:7 urn:ietf:params:rtp-hdrext:csrc-audio-level
= extmap：7 URN：IETF：paramsは：RTP-hdrext：CSRC音声レベル
The above mapping will most often be provided per media stream (in the media-level section(s) of SDP, i.e., after an "m=" line) or globally if there is more than one stream containing audio level indicators in a session.
上記マッピングは、ほとんどの場合（「M =」行の後に、SDPのメディアレベル部（S）において、IE）メディア・ストリームごとに提供されるかグローバルセッションのオーディオレベルインジケータを含む複数のストリームが存在する場合。
Presence of the above attribute in the SDP description of a media stream indicates that RTP packets in that stream, which contain the level extension defined in this document, will be carrying such an extension with an ID of 7.
メディアストリームのSDP記述の上記属性が存在することは、この文書で定義されたレベルの拡張を含むそのストリームにおけるRTPパケットは、7のIDと、そのような拡張を搬送することを示しています。
Conferencing clients that support audio level indicators and have no mixing capabilities would not be able to provide content for this audio level extension and would hence have to always include the direction parameter in the "extmap" attribute with a value of "recvonly". Conference focus entities with mixing capabilities can omit the direction or set it to "sendrecv" in SDP offers. Such entities would need to set it to "sendonly" in SDP answers to offers with a "recvonly" parameter and to "sendrecv" when answering other "sendrecv" offers.
オーディオレベル表示をサポートし、何のミキシング機能を持たない会議クライアントは、このオーディオレベルの拡張のためのコンテンツを提供することができないので、常に「がrecvonly」の値が「extmap」属性に方向パラメータを含めなければならないでしょう。ミキシング機能の会議の焦点エンティティは、方向を省略するか、SDP申し出で「SENDRECV」に設定することができます。このようなエンティティは、他の「のsendrecv」の提供に答えると、「がrecvonly」パラメータと「SENDRECV」へと申し出へのSDPの回答では「sendonlyの」それを設定する必要があります。
This specification only defines the use of the audio level extensions in audio streams. They MUST NOT be advertised with other media types, such as video or text, for example.
この仕様は唯一のオーディオストリームにおける音声レベルの拡張機能の使用を定義します。彼らは、例えば、ビデオやテキストなどの他のメディアタイプ、と宣伝してはなりません。
Figures 4 and 5 show two example offer/answer exchanges between a conferencing client and a focus, and between two conference focus entities.
4および図5は、2つの例のオファー/アンサー会議クライアントと焦点間の交流、および2つの会議の焦点エンティティ間を示しました。
SDP Offer:
SDPオファー：
v=0 o=alice 2890844526 2890844526 IN IP6 host.example.com s=- c=IN IP6 host.example.com t=0 0 m=audio 49170 RTP/AVP 0 4 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=extmap:1/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level
V = 0 0 =アリス2890844526 2890844526 IN IP6 host.example.com S = - C = IN IP6 host.example.com T = 0、M =オーディオ49170 RTP / AVP 0 4 A = rtpmap：0 PCMU / 8000 = rtpmap：G723 / 8000 4 = extmap：1 / recvonlyでURN：IETF：paramsは：RTP-hdrext：CSRC音声レベル
SDP Answer:
SDP回答：
v=0 i=A Seminar on the session description protocol o=conf-focus 2890844730 2890844730 IN IP6 focus.example.net s=- c=IN IP6 focus.example.net t=0 0 m=audio 52544 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=extmap:1/sendonly urn:ietf:params:rtp-hdrext:csrc-audio-level
C = IN IP6 focus.example.net T = 0、M =オーディオ52544 RTP / AVP 0 - V = 0私は、セッション記述プロトコルO = CONF焦点2890844730 2890844730 IN IP6 focus.example.net S =セミナーを= = rtpmap：0 PCMU / 8000 = extmap：1 / sendonlyのURN：IETF：paramsは：RTP-hdrext：CSRC音声レベル
Figure 4: A Client-Initiated Example SDP Offer/Answer Exchange Negotiating an Audio Stream with One-Way Flow of Audio Level Information
図4：オーディオレベルの情報の一方向の流れとオーディオストリームを交渉クライアントが開始した例SDPオファー/アンサー交換
SDP Offer:
SDPオファー：
v=0 i=Un seminaire sur le protocole de description des sessions o=fr-focus 2890844730 2890844730 IN IP6 focus.fr.example.net s=- c=IN IP6 focus.fr.example.net t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=extmap:1/sendrecv urn:ietf:params:rtp-hdrext:csrc-audio-level
V = 0、I =アン神学校シュールルprotocoleデ説明DESセッションO = FR-焦点2890844730 2890844730 IP6 focus.fr.example.net S = IN - C = IN IP6 focus.fr.example.net T = 0、M =オーディオ49170 RTP / AVP 0 A = rtpmap：0 PCMU / 8000 = extmap：1 / SENDRECV URN：IETF：paramsは：RTP-hdrext：CSRC音声レベル
SDP Answer:
SDP回答：
v=0 i=A Seminar on the session description protocol o=us-focus 2890844526 2890844526 IN IP6 focus.us.example.net s=- c=IN IP6 focus.us.example.net t=0 0 m=audio 52544 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=extmap:1/sendrecv urn:ietf:params:rtp-hdrext:csrc-audio-level
C = IN IP6 focus.us.example.net T = 0、M =オーディオ52544 - V = 0 iがIP6 focus.us.example.net S =米国焦点2890844526 2890844526 = Oでセッション記述プロトコルにセミナー= RTP / AVP 0 A = rtpmap：0 PCMU / 8000 = extmap：1 / SENDRECV URN：IETF：paramsは：RTP-hdrext：CSRC音声レベル
Figure 5: An Example SDP Offer/Answer Exchange between Two Conference Focus Entities with Mixing Capabilities Negotiating an Audio Stream with Bidirectional Flow of Audio Level Information
図5：例SDPオファー/オーディオレベルの情報の双方向フローとオーディオストリームを交渉ミキシング機能を持つ2つの会議フォーカスエンティティ間の交流を回答
1. This document defines a means of attributing audio level to a particular participant in a conference. An attacker may try to modify the content of RTP packets in a way that would make audio activity from one participant appear to be coming from another participant.
1.この文書では、会議中の特定の参加者に音声レベルを帰属する手段を定義します。攻撃者が他の参加者から来ているように見える一人の参加者からの音声活動をするような方法でRTPパケットの内容を変更しようとするかもしれません。
2. Furthermore, the fact that audio level values would not be protected even in a Secure Real-time Transport Protocol (SRTP) session [RFC3711] might be of concern in some cases where the activity of a particular participant in a conference is confidential. Also, as discussed in [SRTP-VBR-AUDIO], an attacker might be able to infer information about the conversation, possibly with phoneme-level resolution.
2.さらに、オーディオレベル値もセキュアリアルタイムトランスポートプロトコル（SRTP）セッション[RFC3711]で保護されていないという事実は、会議中に特定の参加者の活動が機密であるいくつかのケースで心配であるかもしれません。また、[SRTP-VBR-AUDIO]で説明したように、攻撃者は、おそらく、音素レベルの分解能で、会話についての情報を推測することができるかもしれません。
3. Both of the above are concerns that stem from the design of the RTP protocol itself, and they would probably also apply when using CSRC identifiers in the way specified in RFC 3550 [RFC3550]. It is therefore important that, according to the
上記の3両は、RTPプロトコル自体の設計から幹懸念しており、RFC 3550 [RFC3550]で指定した方法で、CSRC識別子を使用している場合、彼らはおそらくも適用されるであろう。それはによると、ということが重要です
needs of a particular scenario, implementors and deployers
consider the use of header extension encryption [SRTP-ENCR-HDR]
or a lower-level security and authentication mechanism such as
IPsec [RFC4301], for example.
This document defines a new extension URI in the RTP Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data:
このドキュメントでは、次のデータによると、リアルタイムトランスポートプロトコル（RTP）パラメータレジストリのRTPコンパクトヘッダー拡張副登録の新しい拡張URIを定義します。
Extension URI: urn:ietf:params:rtp-hdrext:csrc-audio-level Description: Mixer-to-client audio level indicators Contact: emcho@jitsi.org Reference: RFC 6465
拡張URI：URN：IETF：のparams：RTP-hdrext：CSRC-オーディオレベルの説明：ミキサーからクライアントへのオーディオレベル表示の連絡先：emcho@jitsi.org参考：RFC 6465
Lyubomir Marinov contributed level measurement and rendering code.
Lyubomirマリノフは、レベル測定およびレンダリングコードを貢献しました。
Keith Drage, Roni Even, Miguel A. Garcia, John Elwell, Kevin P. Fleming, Ingemar Johansson, Michael Ramalho, Magnus Westerlund, and several others provided helpful feedback over the avt and avtext mailing lists.
キース糖剤は、ロニはしても、ミゲルA.ガルシア、ジョンエルウェル、ケビンP.フレミング、インゲマル・ヨハンソン、マイケルRamalho、マグヌスウェスター、および他のいくつかは、AVTとavtextメーリングリスト上で有益なフィードバックを提供します。
Jitsi's participation in this specification is funded by the NLnet Foundation.
この仕様でJitsiの参加はNLnet財団によって運営されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008.
[RFC5285]歌手、D.およびH. Desineni、 "RTPヘッダー拡張のための一般的なメカニズム"、RFC 5285、2008年7月。
[ITU.G711] International Telecommunication Union, "Pulse Code Modulation (PCM) of Voice Frequencies", ITU-T Recommendation G.711, November 1988.
[ITU.G711]国際電気通信連合、ITU-T勧告G.711、1988年11月 "音声周波数の符号変調（PCM）をパルス"。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, September 2002.
[RFC3389] Zopf、R.、RFC 3389、2002年9月 "コンフォートノイズ（CN）のためのリアルタイムトランスポートプロトコル（RTP）ペイロード"。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353]ローゼンバーグ、J.、RFC 4353、2006年2月 "セッション開始プロトコル（SIP）との会議のためのフレームワーク"。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575]ローゼンバーグ、J.、Schulzrinneと、H.、およびO.レヴィン、エド。、 "Aセッション開始プロトコル（SIP）の会議の状態のためのイベントパッケージ"、RFC 4575、2006年8月。
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication", RFC 6465, December 2011.
[RFC6464]レノックス、J.、エド。、Ivov、E.、およびE. Marocco、 "リアルタイムトランスポートプロトコルクライアント・ツー・ミキサーオーディオレベル表示について（RTP）ヘッダ拡張"、RFC 6465、2011年12月。
[SRTP-ENCR-HDR] Lennox, J., "Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP)", Work in Progress, October 2011.
[SRTP-ENCR-HDR]レノックス、J.、進歩、2011年10月で、作業 "セキュアリアルタイムトランスポートプロトコル（SRTP）のヘッダの拡張の暗号化"。
[SRTP-VBR-AUDIO] Perkins, C. and JM. Valin, "Guidelines for the use of Variable Bit Rate Audio with Secure RTP", Work in Progress, July 2011.
[SRTP-VBR-AUDIO]パーキンス、C.およびJM。 Valinは、「セキュアRTPと可変ビットレート・オーディオの使用のためのガイドライン」、進歩、2011年7月での作業。
Appendix A. Reference Implementation
付録A.リファレンス実装
This appendix contains Java code for a reference implementation of the level calculation and rendering methods. The code is not normative and is by no means the only possible implementation. Its purpose is to help implementors add audio level support to mixers and clients.
この付録では、レベル計算およびレンダリングメソッドのリファレンス実装のためのJavaコードが含まれています。コードは規範的ではなく、決して唯一可能な実装です。その目的は、実装者は、ミキサ、クライアントにオーディオのレベルのサポートを追加支援することです。
The Java code contains an AudioLevelCalculator class that calculates the sound pressure level of a signal with specific samples. It can be used in mixers to generate values suitable for the level extension headers.
Javaコードは、特定のサンプルを有する信号の音圧レベルを算出AudioLevelCalculatorクラスを含みます。レベルの拡張ヘッダに適した値を生成するミキサに使用することができます。
The implementation is provided in Java but does not rely on any of the language specifics and can be easily ported to another language.
実装はJavaで提供されますが、言語仕様のいずれにも依存せず、簡単に別の言語に移植することができます。
A.1. AudioLevelCalculator.java
A.1。 AudioLevelCalculator.java
<CODE BEGINS>
<CODEが開始されます>
/*
Copyright (c) 2011 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). */
、に基づき許可されており、中に含まれるライセンス条項に従う、簡体BSDライセンスは、IETFドキュメントに関連IETFトラストの法律規定（のセクション4.Cに記載されている変更の有無にかかわらず、ソースおよびバイナリ形式での再配布および使用http://trustee.ietf.org/license-info）。 * /
/**
* Calculates the audio level of specific samples of a signal
* relative to overload.
*/
public class AudioLevelCalculator
{
/**
* Calculates the audio level of a signal with specific
* <tt>samples</tt>.
*
* @param samples the samples whose audio level we need to
* calculate. The samples are specified as an <tt>int</tt>
* array starting at <tt>offset</tt>, extending <tt>length</tt>
* number of elements, and each <tt>int</tt> element in the
* specified range representing a sample whose audio level we
* need to calculate. Though a sample is provided in the
* form of an <tt>int</tt> value, the sample size in bits
* is determined by the caller via <tt>overload</tt>.
*
* @param offset the offset in <tt>samples</tt> at which the
* samples start.
*
* @param length the length of the signal specified in
* <tt>samples<tt>, starting at <tt>offset</tt>.
*
* @param overload the overload (point) of <tt>signal</tt>.
* For example, <tt>overload</tt> can be {@link Byte#MAX_VALUE}
* for 8-bit signed samples or {@link Short#MAX_VALUE} for
* 16-bit signed samples.
*
* @return the audio level of the specified signal.
*/
public static int calculateAudioLevel(
int[] samples, int offset, int length,
int overload)
{
/*
* Calculate the root mean square (RMS) of the signal.
*/
double rms = 0;
for (; offset < length; offset++)
{
double sample = samples[offset];
sample /= overload;
rms += sample * sample;
}
rms = (length == 0) ? 0 : Math.sqrt(rms / length);
/*
* The audio level is a logarithmic measure of the
* rms level of an audio sample relative to a reference
* value and is measured in decibels.
*/
double db;
/*
* The minimum audio level permitted.
*/
final double MIN_AUDIO_LEVEL = -127;
/*
* The maximum audio level permitted.
*/
final double MAX_AUDIO_LEVEL = 0;
if (rms > 0)
{
/*
* The "zero" reference level is the overload level,
* which corresponds to 1.0 in this calculation, because
* the samples are normalized in calculating the RMS.
*/
db = 20 * Math.log10(rms);
/*
* Ensure that the calculated level is within the minimum
* and maximum range permitted.
*/
if (db < MIN_AUDIO_LEVEL)
db = MIN_AUDIO_LEVEL;
else if (db > MAX_AUDIO_LEVEL)
db = MAX_AUDIO_LEVEL;
}
else
{
db = MIN_AUDIO_LEVEL;
}
return (int)Math.round(db); } }
リターン（INT）恐らくMath.round（デシベル）。 }}
<CODE ENDS>
<CODEはENDS>
Authors' Addresses
著者のアドレス
Emil Ivov (editor) Jitsi Strasbourg 67000 France
エミールIvov（エディタ）Jitsiストラスブールフランス
EMail: emcho@jitsi.org
メールアドレス：emcho@jitsi.org
Enrico Marocco (editor) Telecom Italia Via G. Reiss Romoli, 274 Turin 10148 Italy
エンリコ・モロッコ（エディタ）テレコムイタリアVia G.ライスRomoli、274 10148トリノイタリア
EMail: enrico.marocco@telecomitalia.it
メールアドレス：enrico.marocco@telecomitalia.it
Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US
ジョナサン・レノックスにVidyo社433ハッケンサックアベニュー7階ハッケンサック、NJ 07601米国
EMail: jonathan@vidyo.com
メールアドレス：jonathan@vidyo.com