RFC3551 日本語訳
3551 RTP Profile for Audio and Video Conferences with Minimal Control.H. Schulzrinne, S. Casner. July 2003. (Format: TXT=106621, PS=317286, PDF=237831 bytes) (Obsoletes RFC1890) (Also STD0065) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H. Schulzrinne
Request for Comments: 3551 Columbia University
Obsoletes: 1890 S. Casner
Category: Standards Track Packet Design
July 2003
Schulzrinneがコメントのために要求するワーキンググループH.をネットワークでつないでください: 3551年のコロンビア大学は以下を時代遅れにします。 1890秒間Casnerカテゴリ: 標準化過程パケットデザイン2003年7月
RTP Profile for Audio and Video Conferences
with Minimal Control
最小量のコントロールがあるオーディオとテレビ会議システムのための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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings.
このドキュメントはリアルタイムのトランスポート・プロトコル(RTP)、バージョン2、および関連制御プロトコルの使用のために"RTP/AVP"と呼ばれるプロフィールについて説明します、RTCP、最小量のコントロールとのオーディオとビデオ「マルチ-関係者」会議の中で。 それはオーディオとテレビ会議システムに適したRTP仕様の中でジェネリック分野の解釈を提供します。 特に、このドキュメントは1セットのデフォルトマッピングをペイロード形式数からencodingsまで定義します。
This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications.
また、このドキュメントはオーディオとビデオ・データがRTPの中でどう運ばれるかもしれないかを説明します。 RTPの中で使用されると、それは標準のencodingsと彼らの名前の1セットを定義します。 記述は参照実装と詳細な規格に指針を提供します。 このドキュメントはオーディオ、ビデオ、および他のリアルタイムのマルチメディア応用の作成者のための援助として意味されます。
This memorandum obsoletes RFC 1890. It is mostly backwards- compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published.
このメモはRFC1890を時代遅れにします。 それはほとんど後方に2つの共同利用できる実装が見つけられなかったので取り除かれた機能を除いて、互換性があった状態であります。 RFC1890への追加は、このプロフィールの下でペイロード形式の使用における既存の習慣を成文化して、RFC1890が発行されたので形式が定義した新しいペイロードを含んでいます。
Schulzrinne & Casner Standards Track [Page 1] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[1ページ]RFCプロフィール2003年7月
Table of Contents
目次
1. Introduction ................................................. 3
1.1 Terminology ............................................. 3
2. RTP and RTCP Packet Forms and Protocol Behavior .............. 4
3. Registering Additional Encodings ............................. 6
4. Audio ........................................................ 8
4.1 Encoding-Independent Rules .............................. 8
4.2 Operating Recommendations ............................... 9
4.3 Guidelines for Sample-Based Audio Encodings ............. 10
4.4 Guidelines for Frame-Based Audio Encodings .............. 11
4.5 Audio Encodings ......................................... 12
4.5.1 DVI4 ............................................ 13
4.5.2 G722 ............................................ 14
4.5.3 G723 ............................................ 14
4.5.4 G726-40, G726-32, G726-24, and G726-16 .......... 18
4.5.5 G728 ............................................ 19
4.5.6 G729 ............................................ 20
4.5.7 G729D and G729E ................................. 22
4.5.8 GSM ............................................. 24
4.5.9 GSM-EFR ......................................... 27
4.5.10 L8 .............................................. 27
4.5.11 L16 ............................................. 27
4.5.12 LPC ............................................. 27
4.5.13 MPA ............................................. 28
4.5.14 PCMA and PCMU ................................... 28
4.5.15 QCELP ........................................... 28
4.5.16 RED ............................................. 29
4.5.17 VDVI ............................................ 29
5. Video ........................................................ 30
5.1 CelB .................................................... 30
5.2 JPEG .................................................... 30
5.3 H261 .................................................... 30
5.4 H263 .................................................... 31
5.5 H263-1998 ............................................... 31
5.6 MPV ..................................................... 31
5.7 MP2T .................................................... 31
5.8 nv ...................................................... 32
6. Payload Type Definitions ..................................... 32
7. RTP over TCP and Similar Byte Stream Protocols ............... 34
8. Port Assignment .............................................. 34
9. Changes from RFC 1890 ........................................ 35
10. Security Considerations ...................................... 38
11. IANA Considerations .......................................... 39
12. References ................................................... 39
12.1 Normative References .................................... 39
12.2 Informative References .................................. 39
13. Current Locations of Related Resources ....................... 41
1. 序論… 3 1.1用語… 3 2. RTP、RTCPパケット用紙、およびプロトコルの振舞い… 4 3. 追加Encodingsを登録します… 6 4. オーディオ… 8 4.1のコード化している無党派は判決を下します… 8 4.2 推薦を操作します… 9 サンプルベースのオーディオEncodingsのための4.3のガイドライン… 10 フレームベースのオーディオEncodingsのための4.4のガイドライン… 11 4.5 オーディオEncodings… 12 4.5 .1DVI4… 13 4.5 .2G722… 14 4.5 .3G723… 14 4.5 .4のG726-40、G726-32、G726-24、およびG726-16… 18 4.5 .5G728… 19 4.5 .6G729… 20 4.5 .7 G729DとG729E… 22 4.5 .8GSM… 24 4.5 .9GSM-EFR… 27 4.5 .10L8… 27 4.5 .11L16… 27 4.5 .12LPC… 27 4.5 .13MPA… 28 4.5 .14のPCMAとPCMU… 28 4.5 .15QCELP… 28 4.5 .16赤… 29 4.5 .17VDVI… 29 5. ビデオ… 30 5.1CelB… 30 5.2JPEG… 30 5.3H261… 30 5.4H263… 31 5.5H263-1998… 31 5.6MPV… 31 5.7 MP2T… 31 5.8nv… 32 6. 有効搭載量型定義… 32 7. TCPと同様のバイトの上RTPはプロトコルを流します… 34 8. 課題を移植してください… 34 9. RFC1890からの変化… 35 10. セキュリティ問題… 38 11. IANA問題… 39 12. 参照… 39 12.1 標準の参照… 39 12.2 有益な参照… 39 13. 関連リソースの現在の位置… 41
Schulzrinne & Casner Standards Track [Page 2] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[2ページ]RFCプロフィール2003年7月
14. Acknowledgments .............................................. 42 15. Intellectual Property Rights Statement ....................... 43 16. Authors' Addresses ........................................... 43 17. Full Copyright Statement ..................................... 44
14. 承認… 42 15. 知的所有権は声明を正します… 43 16. 作者のアドレス… 43 17. 完全な著作権宣言文… 44
1. Introduction
1. 序論
This profile defines aspects of RTP left unspecified in the RTP Version 2 protocol definition (RFC 3550) [1]. This profile is intended for the use within audio and video conferences with minimal session control. In particular, no support for the negotiation of parameters or membership control is provided. The profile is expected to be useful in sessions where no negotiation or membership control are used (e.g., using the static payload types and the membership indications provided by RTCP), but this profile may also be useful in conjunction with a higher-level control protocol.
このプロフィールはRTPバージョン2プロトコル定義(RFC3550)[1]で不特定の状態で残っているRTPの局面を定義します。 このプロフィールは使用のためにオーディオとテレビ会議システムの中で最小量のセッション制御で意図します。 特に、パラメタか会員資格コントロールの交渉のサポートを全く提供しません。 プロフィールがセッションのときに交渉でない会員資格コントロールがないのが使用されている(例えば、静的なペイロードタイプとRTCPによって提供された会員資格指摘を使用します)ところで役に立つと予想されますが、このプロフィールもまた、よりハイレベルの制御プロトコルに関連して役に立つかもしれません。
Use of this profile may be implicit in the use of the appropriate applications; there may be no explicit indication by port number, protocol identifier or the like. Applications such as session directories may use the name for this profile specified in Section 11.
このプロフィールの使用は適切なアプリケーションの使用で暗黙であるかもしれません。 ポートナンバー、プロトコル識別子または同様のものによるどんな明白な指示もないかもしれません。 セッションディレクトリなどのアプリケーションはセクション11で指定されたこのプロフィールに名前を使用するかもしれません。
Other profiles may make different choices for the items specified here.
他のプロフィールで、ここで項目のための異なった選択を指定するかもしれません。
This document also defines a set of encodings and payload formats for audio and video. These payload format descriptions are included here only as a matter of convenience since they are too small to warrant separate documents. Use of these payload formats is NOT REQUIRED to use this profile. Only the binding of some of the payload formats to static payload type numbers in Tables 4 and 5 is normative.
また、このドキュメントはオーディオとビデオのために1セットのencodingsとペイロード書式を定義します。 それらが別々のドキュメントを保証できないくらい小さいので、これらのペイロード書式の記述はここに都合上だけ含まれています。 これらのペイロード形式の使用はこのプロフィールを使用するNOT REQUIREDです。 Tables4と5の静的なペイロード形式数へのいくつかのペイロード形式の結合だけが規範的です。
1.1 Terminology
1.1 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for implementations compliant with this RTP profile.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは中でRFC2119[2]について説明して、このRTPプロフィールによる対応することの実装のために要件レベルを示すとき本書では解釈されることであるべきですか?
This document defines the term media type as dividing encodings of audio and video content into three classes: audio, video and audio/video (interleaved).
このドキュメントはオーディオとビデオ内容のencodingsを3つのクラスに分割すると用語メディアタイプを定義します: オーディオ、ビデオ、およびオーディオ/ビデオ(はさみ込まれます)。
Schulzrinne & Casner Standards Track [Page 3] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[3ページ]RFCプロフィール2003年7月
2. RTP and RTCP Packet Forms and Protocol Behavior
2. RTP、RTCPパケット用紙、およびプロトコルの振舞い
The section "RTP Profiles and Payload Format Specifications" of RFC 3550 enumerates a number of items that can be specified or modified in a profile. This section addresses these items. Generally, this profile follows the default and/or recommended aspects of the RTP specification.
「RTPプロフィールと有効搭載量書式仕様」というRFC3550のセクションはプロフィールで指定するか、または変更できる件数を列挙します。 このセクションはこれらの項目を扱います。一般に、このプロフィールはRTP仕様のデフォルト、そして/または、お勧めの局面に続きます。
RTP data header: The standard format of the fixed RTP data
header is used (one marker bit).
RTPデータヘッダー: 固定RTPデータヘッダーの標準書式は(1マーカービット)使用されます。
Payload types: Static payload types are defined in Section 6.
有効搭載量は以下をタイプします。 静的なペイロードタイプはセクション6で定義されます。
RTP data header additions: No additional fixed fields are
appended to the RTP data header.
RTPデータヘッダー追加: どんな追加固定野原もRTPデータヘッダーに追加しません。
RTP data header extensions: No RTP header extensions are
defined, but applications operating under this profile MAY use
such extensions. Thus, applications SHOULD NOT assume that the
RTP header X bit is always zero and SHOULD be prepared to ignore
the header extension. If a header extension is defined in the
future, that definition MUST specify the contents of the first 16
bits in such a way that multiple different extensions can be
identified.
RTPデータヘッダー拡張子: RTPヘッダー拡張子は全く定義されませんが、このプロフィールの下で作動するアプリケーションはそのような拡張子を使用するかもしれません。 したがって、アプリケーションSHOULD NOTは、ヘッダー拡大を無視するために準備されていて、RTPヘッダーXビットがいつもゼロとSHOULDであると仮定します。 ヘッダー拡大が将来定義されるなら、その定義は複数の異なった拡大を特定できるような方法で最初の16ビットのコンテンツを指定しなければなりません。
RTCP packet types: No additional RTCP packet types are defined
by this profile specification.
RTCPパケットはタイプされます: どんな追加RTCPパケットタイプもこのプロフィール仕様で定義されません。
RTCP report interval: The suggested constants are to be used for
the RTCP report interval calculation. Sessions operating under
this profile MAY specify a separate parameter for the RTCP traffic
bandwidth rather than using the default fraction of the session
bandwidth. The RTCP traffic bandwidth MAY be divided into two
separate session parameters for those participants which are
active data senders and those which are not. Following the
recommendation in the RTP specification [1] that 1/4 of the RTCP
bandwidth be dedicated to data senders, the RECOMMENDED default
values for these two parameters would be 1.25% and 3.75%,
respectively. For a particular session, the RTCP bandwidth for
non-data-senders MAY be set to zero when operating on
unidirectional links or for sessions that don't require feedback
on the quality of reception. The RTCP bandwidth for data senders
SHOULD be kept non-zero so that sender reports can still be sent
for inter-media synchronization and to identify the source by
CNAME. The means by which the one or two session parameters for
RTCP bandwidth are specified is beyond the scope of this memo.
RTCPは間隔を報告します: 提案された定数はRTCPレポート間隔計算に使用されることです。 このプロフィールの下で作動するセッションはセッション帯域幅のデフォルト部分を使用するよりむしろRTCPトラフィック帯域幅のための別々のパラメタを指定するかもしれません。 RTCPトラフィック帯域幅はそれらの関係者への活発なデータ送付者とそうしないそれらである2つの別々のセッションパラメタに分割されるかもしれません。 [1] 1/4のRTCP帯域幅がデータ送付者に捧げられるというRTP仕様に基づく推薦に続いて、これらの2つのパラメタのためのRECOMMENDEDデフォルト値は%と3.75%と、それぞれ1.25でしょう。 単方向のリンクかレセプションの品質のフィードバックを必要としないセッションのために作動するとき、特定のセッションのために、非データの送付者のためのRTCP帯域幅はゼロに設定されるかもしれません。 RTCP帯域幅、データ送付者SHOULDに関しては、中間体同期、CNAMEによるソースを特定するためにまだ送付者レポートを送ることができるように非ゼロであることが保たれてください。 RTCP帯域幅のための1か2つのセッションパラメタが指定される手段はこのメモの範囲を超えています。
Schulzrinne & Casner Standards Track [Page 4] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[4ページ]RFCプロフィール2003年7月
SR/RR extension: No extension section is defined for the RTCP SR
or RR packet.
SR/RR拡張子: 拡大部は全くRTCP SRかRRパケットのために定義されません。
SDES use: Applications MAY use any of the SDES items described
in the RTP specification. While CNAME information MUST be sent
every reporting interval, other items SHOULD only be sent every
third reporting interval, with NAME sent seven out of eight times
within that slot and the remaining SDES items cyclically taking up
the eighth slot, as defined in Section 6.2.2 of the RTP
specification. In other words, NAME is sent in RTCP packets 1, 4,
7, 10, 13, 16, 19, while, say, EMAIL is used in RTCP packet 22.
SDES使用: アプリケーションはRTP仕様で説明されたSDESの品目のいずれも使用するかもしれません。 あらゆる報告間隔CNAME情報を送らなければなりませんでしたが、あらゆる3番目に報告している間隔他の項目SHOULDを送るだけであって、NAMEと共に、そのスロットの中の8回と周期的に8番目のスロットを取る残っているSDESの品目からの7は発信していました、.2のセクション6.2RTP仕様に基づき定義されるように。 言い換えれば、RTCPパケット1、4、7、10、13、16、19でNAMEを送ります、たとえば、メールはRTCPパケット22で使用されますが。
Security: The RTP default security services are also the default
under this profile.
セキュリティ: また、RTPデフォルトセキュリティー・サービスはこのプロフィールの下のデフォルトです。
String-to-key mapping: No mapping is specified by this profile.
ストリングから重要へのマッピング: 写像はこのプロフィールによって指定されません。
Congestion: RTP and this profile may be used in the context of
enhanced network service, for example, through Integrated Services
(RFC 1633) [4] or Differentiated Services (RFC 2475) [5], or they
may be used with best effort service.
混雑: 例えば、RTPとこのプロフィールがIntegrated Services(RFC1633)[4]かDifferentiated Services(RFC2475)[5]を通して高められたネットワーク・サービスの文脈で使用されるかもしれませんか、または彼らはベストエフォート型サービスと共に使用されるかもしれません。
If enhanced service is being used, RTP receivers SHOULD monitor
packet loss to ensure that the service that was requested is
actually being delivered. If it is not, then they SHOULD assume
that they are receiving best-effort service and behave
accordingly.
高度サービスが使用されているなら、RTP受信機SHOULDは、要求されたサービスが実際に提供されているのを保証するためにパケット損失をモニターします。 それはそうでなく、次に、それらはSHOULDです。彼らが受信のベストエフォート型サービスであり、それに従って、振る舞うと仮定してください。
If best-effort service is being used, RTP receivers SHOULD monitor
packet loss to ensure that the packet loss rate is within
acceptable parameters. Packet loss is considered acceptable if a
TCP flow across the same network path and experiencing the same
network conditions would achieve an average throughput, measured
on a reasonable timescale, that is not less than the RTP flow is
achieving. This condition can be satisfied by implementing
congestion control mechanisms to adapt the transmission rate (or
the number of layers subscribed for a layered multicast session),
or by arranging for a receiver to leave the session if the loss
rate is unacceptably high.
ベストエフォート型サービスが利用されているなら、RTP受信機SHOULDは、許容できるパラメタの中にパケット損失率があるのを保証するためにパケット損失をモニターします。 同じネットワーク経路と同じネットワーク状態を経験することの向こう側のTCP流動が妥当なスケールで測定された少なくとも流れが実現しているRTPである平均したスループットを実現するなら、パケット損失は許容できると考えられます。 通信速度(層の数は層にされたマルチキャストセッションのために申し込まれた)を適合させるために混雑制御機構を実装するか、または損失率が容認できないほど高いなら受信機がセッションを出発するように手配することによって、この状態を満たすことができます。
The comparison to TCP cannot be specified exactly, but is intended
as an "order-of-magnitude" comparison in timescale and throughput.
The timescale on which TCP throughput is measured is the round-
trip time of the connection. In essence, this requirement states
that it is not acceptable to deploy an application (using RTP or
any other transport protocol) on the best-effort Internet which
consumes bandwidth arbitrarily and does not compete fairly with
TCP within an order of magnitude.
TCPとの比較は、まさに指定できませんが、スケールとスループットにおける1「桁」比較として意図します。 TCPスループットが測定されるスケールは接続の丸い旅行時間です。 本質では、この要件は、1桁以内で任意に帯域幅を消費して、TCPと公正に競争しないベストエフォート型インターネットでアプリケーションが(RTPを使用するか、いかなる他のトランスポート・プロトコルも)であると配布するのが許容できないと述べます。
Schulzrinne & Casner Standards Track [Page 5] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[5ページ]RFCプロフィール2003年7月
Underlying protocol: The profile specifies the use of RTP over
unicast and multicast UDP as well as TCP. (This does not preclude
the use of these definitions when RTP is carried by other lower-
layer protocols.)
基本的なプロトコル: プロフィールはTCPと同様にユニキャストとマルチキャストUDPの上でRTPの使用を指定します。 (RTPが他の低い層のプロトコルによって運ばれるとき、これはこれらの定義の使用を排除しません。)
Transport mapping: The standard mapping of RTP and RTCP to
transport-level addresses is used.
マッピングを輸送してください: 輸送レベルアドレスへのRTPとRTCPの標準のマッピングは使用されています。
Encapsulation: This profile leaves to applications the
specification of RTP encapsulation in protocols other than UDP.
カプセル化: このプロフィールはUDP以外のプロトコルのRTPカプセル化の仕様をアプリケーションに残します。
3. Registering Additional Encodings
3. 追加Encodingsを登録します。
This profile lists a set of encodings, each of which is comprised of a particular media data compression or representation plus a payload format for encapsulation within RTP. Some of those payload formats are specified here, while others are specified in separate RFCs. It is expected that additional encodings beyond the set listed here will be created in the future and specified in additional payload format RFCs.
このプロフィールはRTPの中のカプセル化のためにそれのそれぞれが特定のメディアデータ圧縮か表現から成るencodingsの1セットとペイロード書式を記載します。 それらのペイロード形式のいくつかがここで指定されますが、他のものは別々のRFCsで指定されます。 ここに記載されたセットを超えた追加encodingsが将来、作成されて、追加ペイロード形式RFCsで指定されると予想されます。
This profile also assigns to each encoding a short name which MAY be used by higher-level control protocols, such as the Session Description Protocol (SDP), RFC 2327 [6], to identify encodings selected for a particular RTP session.
また、このプロフィールは、特定のRTPセッションのために選択されたencodingsを特定するために記述プロトコル(SDP)、RFC2327[6]をそれぞれSessionなどの、よりハイレベルの制御プロトコルによって使用されるかもしれない省略名をコード化するのに割り当てます。
In some contexts it may be useful to refer to these encodings in the form of a MIME content-type. To facilitate this, RFC 3555 [7] provides registrations for all of the encodings names listed here as MIME subtype names under the "audio" and "video" MIME types through the MIME registration procedure as specified in RFC 2048 [8].
いくつかの文脈では、MIMEの満足しているタイプの形でこれらのencodingsについて言及するのは役に立つかもしれません。 これを容易にするために、RFC3555[7]はMIME「副-タイプ」が「オーディオ」と「ビデオ」の下でRFCの指定されるとしてのMIME登録手順によるMIMEの種類を2048[8]と命名するのでここに記載されたencodings名のすべてのための登録証明書を提供します。
Any additional encodings specified for use under this profile (or others) may also be assigned names registered as MIME subtypes with the Internet Assigned Numbers Authority (IANA). This registry provides a means to insure that the names assigned to the additional encodings are kept unique. RFC 3555 specifies the information that is required for the registration of RTP encodings.
また、MIME血液型亜型としてインターネットAssigned民数記Authority(IANA)に登録された名前はこのプロフィール(または、他のもの)の下の使用に指定されたどんな追加encodingsにも割り当てられるかもしれません。 この登録は追加encodingsに割り当てられた名前がユニークに保たれるのを保障する手段を提供します。 RFC3555はRTP encodingsの登録に必要である情報を指定します。
In addition to assigning names to encodings, this profile also assigns static RTP payload type numbers to some of them. However, the payload type number space is relatively small and cannot accommodate assignments for all existing and future encodings. During the early stages of RTP development, it was necessary to use statically assigned payload types because no other mechanism had been specified to bind encodings to payload types. It was anticipated that non-RTP means beyond the scope of this memo (such as directory services or invitation protocols) would be specified to establish a
また、名前をencodingsに割り当てることに加えて、このプロフィールは静的なRTPペイロード形式数をそれらのいくつかに割り当てます。 しかしながら、ペイロード形式数スペースは、比較的小さく、すべての存在と将来のencodingsのための課題に対応できません。 RTP開発の初期段階の間、他のメカニズムが全くペイロードタイプにencodingsを縛るために指定されていなかったので、静的に割り当てられたペイロードタイプを使用するのが必要でした。 このメモ(電話番号案内か招待プロトコルなどの)の範囲を超えた非RTP手段がaを証明するために指定されると予期されました。
Schulzrinne & Casner Standards Track [Page 6] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[6ページ]RFCプロフィール2003年7月
dynamic mapping between a payload type and an encoding. Now, mechanisms for defining dynamic payload type bindings have been specified in the Session Description Protocol (SDP) and in other protocols such as ITU-T Recommendation H.323/H.245. These mechanisms associate the registered name of the encoding/payload format, along with any additional required parameters, such as the RTP timestamp clock rate and number of channels, with a payload type number. This association is effective only for the duration of the RTP session in which the dynamic payload type binding is made. This association applies only to the RTP session for which it is made, thus the numbers can be re-used for different encodings in different sessions so the number space limitation is avoided.
ペイロードタイプとコード化の間のダイナミックなマッピング。 現在、ダイナミックなペイロードタイプ結合を定義するためのメカニズムはSession記述プロトコル(SDP)とITU-T Recommendation H.323/H.245などの他のプロトコルで指定されました。 これらのメカニズムはコード化/ペイロード形式の登録名を関連づけます、どんな追加必要なパラメタと共にも、チャンネルのRTPタイムスタンプクロックレートや数のように、ペイロード形式数で。 ダイナミックなペイロードタイプ結合がされるRTPセッションの持続時間だけに、この協会は有効です。 この協会はそれが作られているRTPセッションだけに適用されます、その結果、異なったセッションにおける異なったencodingsに数を再使用できます、したがって、数の宇宙制限が避けられます。
This profile reserves payload type numbers in the range 96-127 exclusively for dynamic assignment. Applications SHOULD first use values in this range for dynamic payload types. Those applications which need to define more than 32 dynamic payload types MAY bind codes below 96, in which case it is RECOMMENDED that unassigned payload type numbers be used first. However, the statically assigned payload types are default bindings and MAY be dynamically bound to new encodings if needed. Redefining payload types below 96 may cause incorrect operation if an attempt is made to join a session without obtaining session description information that defines the dynamic payload types.
このプロフィール蓄えのペイロードは排他的にダイナミックな課題のために範囲96-127で数をタイプします。 アプリケーションSHOULDは最初に、ダイナミックなペイロードタイプにこの範囲で値を使用します。 32以上のダイナミックなペイロードタイプを定義する必要があるそれらのアプリケーションは96より下でコードを縛るかもしれません、その場合、割り当てられなかったペイロード形式数が最初に使用されるのが、RECOMMENDEDです。 しかしながら、静的に割り当てられたペイロードタイプは、デフォルト結合であり、必要であるなら、ダイナミックに新しいencodingsに縛られるかもしれません。 96歳未満のペイロードタイプを再定義すると、ダイナミックなペイロードタイプを定義するセッション記述情報を得ないでセッションに参加するのを試みをするなら、不正確な操作は引き起こされるかもしれません。
Dynamic payload types SHOULD NOT be used without a well-defined mechanism to indicate the mapping. Systems that expect to interoperate with others operating under this profile SHOULD NOT make their own assignments of proprietary encodings to particular, fixed payload types.
ダイナミックなペイロードはSHOULD NOTをタイプします。明確なメカニズムなしでマッピングを示すのが使用されます。 他のものがこのプロフィールSHOULD NOTの下で働いていて共同利用すると予想するシステムが特定の、そして、固定されたペイロードタイプへの独占encodingsの課題にそれら自身のを作ります。
This specification establishes the policy that no additional static payload types will be assigned beyond the ones defined in this document. Establishing this policy avoids the problem of trying to create a set of criteria for accepting static assignments and encourages the implementation and deployment of the dynamic payload type mechanisms.
この仕様はどんな追加静的なペイロードも本書では定義されたものを超えて割り当てられるのをタイプしない方針を確立します。 この方針を確立すると、静的な課題を受け入れるための1セットの評価基準を作成しようとするという問題が避けられて、ダイナミックなペイロードタイプメカニズムの実現と展開は奨励されます。
The final set of static payload type assignments is provided in Tables 4 and 5.
静的なペイロードタイプ課題のファイナルセットをTables4と5に提供します。
Schulzrinne & Casner Standards Track [Page 7] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[7ページ]RFCプロフィール2003年7月
4. Audio
4. オーディオ
4.1 Encoding-Independent Rules
4.1 コード化して独立している規則
Since the ability to suppress silence is one of the primary motivations for using packets to transmit voice, the RTP header carries both a sequence number and a timestamp to allow a receiver to distinguish between lost packets and periods of time when no data was transmitted. Discontiguous transmission (silence suppression) MAY be used with any audio payload format. Receivers MUST assume that senders may suppress silence unless this is restricted by signaling specified elsewhere. (Even if the transmitter does not suppress silence, the receiver should be prepared to handle periods when no data is present since packets may be lost.)
沈黙を抑圧する能力が声を伝えるパケットを使用することに関する第一の動機の1つであるので、RTPヘッダーは受信機がデータが全く送られなかった無くなっているパケットと期間を見分けるのを許容するために一連番号とタイムスタンプの両方を運びます。 Discontiguousトランスミッション(沈黙抑圧)はどんなオーディオペイロード形式と共にも使用されるかもしれません。 受信機は、これがほかの場所で指定されたシグナリングによって制限されない場合送付者が沈黙を抑圧するかもしれないと仮定しなければなりません。 (送信機が沈黙を抑圧しないでも、受信機はパケットが失われるかもしれないのでデータがないのが存在している期間を扱うように準備されるべきです。)
Some payload formats (see Sections 4.5.3 and 4.5.6) define a "silence insertion descriptor" or "comfort noise" frame to specify parameters for artificial noise that may be generated during a period of silence to approximate the background noise at the source. For other payload formats, a generic Comfort Noise (CN) payload format is specified in RFC 3389 [9]. When the CN payload format is used with another payload format, different values in the RTP payload type field distinguish comfort-noise packets from those of the selected payload format.
何らかのペイロードがフォーマットする、(セクション4.5.3を見てください。そうすれば、4.5に、.6は、)ソースにおけるバックグラウンドノイズに近似するために沈黙の期間、発生するかもしれない人工の雑音のためにパラメータを指定するために「沈黙挿入記述子」か「安らぎ雑音」フレームを定義します。 他のペイロード形式として、一般的なコンフォートNoise(CN)ペイロード形式はRFC3389[9]で指定されます。 CNペイロード形式が別のペイロード形式と共に使用されるとき、RTPペイロードタイプ分野の異価は選択されたペイロード形式のものと安らぎ雑音パケットを区別します。
For applications which send either no packets or occasional comfort- noise packets during silence, the first packet of a talkspurt, that is, the first packet after a silence period during which packets have not been transmitted contiguously, SHOULD be distinguished by setting the marker bit in the RTP data header to one. The marker bit in all other packets is zero. The beginning of a talkspurt MAY be used to adjust the playout delay to reflect changing network delays. Applications without silence suppression MUST set the marker bit to zero.
すなわち、沈黙の間にどんなパケットも時々の安らぎ雑音パケットのどちらかも送らないアプリケーション、talkspurtの最初のパケット、SHOULD、パケットが近接して伝えられていない沈黙の期間の後の最初のパケットに関しては、RTPデータヘッダーにマーカービットをはめ込むことによって、1つに区別されてください。 他のすべてのパケットのマーカービットはゼロです。 talkspurtの始まりは、ネットワーク遅延を変えながら反射するように再生遅れを調整するのに使用されるかもしれません。 沈黙抑圧のないアプリケーションはマーカービットをゼロに設定しなければなりません。
The RTP clock rate used for generating the RTP timestamp is independent of the number of channels and the encoding; it usually equals the number of sampling periods per second. For N-channel encodings, each sampling period (say, 1/8,000 of a second) generates N samples. (This terminology is standard, but somewhat confusing, as the total number of samples generated per second is then the sampling rate times the channel count.)
RTPタイムスタンプを発生させるのに使用されるRTPクロックレートはチャンネルの数とコード化から独立しています。 通常、それは1秒あたりのサンプリング周期の数と等しいです。 N-チャンネルencodingsに関しては、各サンプリング周期(たとえば、1/8,000の2番目)はNサンプルを発生させます。 (この用語は、標準ですが、いくらか紛らわしいです、1秒単位で発生するサンプルの総数が次にチャンネルが数える標本抽出率回であるので。)
If multiple audio channels are used, channels are numbered left-to- right, starting at one. In RTP audio packets, information from lower-numbered channels precedes that from higher-numbered channels.
チャンネルが複数のオーディオであるなら使用されている、チャンネルは、番号付の左から1からの右です。 RTPオーディオパケットでは、より低く番号付のチャンネルからの情報は、より高く番号付のチャンネルからそれに先行します。
Schulzrinne & Casner Standards Track [Page 8] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[8ページ]RFCプロフィール2003年7月
For more than two channels, the convention followed by the AIFF-C audio interchange format SHOULD be followed [3], using the following notation, unless some other convention is specified for a particular encoding or payload format:
従われたコンベンションの2個以上のチャンネルのためにAIFF-Cオーディオ置き換え形式SHOULDによって続かれてください。ある他のコンベンションが特定のコード化かペイロードに指定されない場合以下の記法を使用する[3]が以下をフォーマットします。
l left
r right
c center
S surround
F front
R rear
lは後部でr権利cセンターS取り囲むものF戦線Rを出ました。
channels description channel
1 2 3 4 5 6
_________________________________________________
2 stereo l r
3 l r c
4 l c r S
5 Fl Fr Fc Sl Sr
6 l lc c r rc S
記述チャンネル1 2 3 4 5 6を向けます。_________________________________________________ 2 ステレオl r3l r c4l c r S5FlフランのFc Sl Sr6l lc c r rc S
Note: RFC 1890 defined two conventions for the ordering of four
audio channels. Since the ordering is indicated implicitly by
the number of channels, this was ambiguous. In this revision,
the order described as "quadrophonic" has been eliminated to
remove the ambiguity. This choice was based on the observation
that quadrophonic consumer audio format did not become popular
whereas surround-sound subsequently has.
以下に注意してください。 RFC1890は4つの音声チャンネルの注文のために2つのコンベンションを定義しました。 以来、注文はチャンネルの数によってそれとなく示されて、これはあいまいでした。 この改正では、「quadrophonicである」と記述されたオーダーは、あいまいさを取り除くために排除されました。 この選択はquadrophonic消費者オーディオ形式がポピュラーにならなかったという観測に基づきましたが、取り囲むもの音は次に、基づきました。
Samples for all channels belonging to a single sampling instant MUST be within the same packet. The interleaving of samples from different channels depends on the encoding. General guidelines are given in Section 4.3 and 4.4.
同じパケットの中に瞬間を抽出するシングルに属すオール・チャンネルへのサンプルがあるに違いありません。 異なったチャンネルからのサンプルのインターリービングはコード化であることによります。 セクション4.3と4.4で一般的ガイドラインを与えます。
The sampling frequency SHOULD be drawn from the set: 8,000, 11,025, 16,000, 22,050, 24,000, 32,000, 44,100 and 48,000 Hz. (Older Apple Macintosh computers had a native sample rate of 22,254.54 Hz, which can be converted to 22,050 with acceptable quality by dropping 4 samples in a 20 ms frame.) However, most audio encodings are defined for a more restricted set of sampling frequencies. Receivers SHOULD be prepared to accept multi-channel audio, but MAY choose to only play a single channel.
頻度SHOULDを抽出して、セットから得てください: 8,000、1万1025、1万6000、2万2050、2万4000、3万2000、4万4100、および4万8000Hz。 (アップルマッキントッシュのコンピュータが、より古かったので、ネイティブは20msフレームで4個のサンプルを落とすことによって、合格品質で2万2050に変換できる2万2254.54Hzのレートを抽出しました。) しかしながら、ほとんどのオーディオのencodingsがさらに制限されたセットのサンプリング周波数のために定義されます。 受信機SHOULDは、マルチチャンネルオーディオを受け入れるように準備されますが、単独のチャンネルを使うだけであるのを選ぶかもしれません。
4.2 Operating Recommendations
4.2 操作推薦
The following recommendations are default operating parameters. Applications SHOULD be prepared to handle other values. The ranges given are meant to give guidance to application writers, allowing a
以下の推薦はデフォルト操作パラメタです。 アプリケーションSHOULD、他の値を扱うように用意してください。 aを許容して、与えられた範囲はアプリケーション作家に指導を与えることになっています。
Schulzrinne & Casner Standards Track [Page 9] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[9ページ]RFCプロフィール2003年7月
set of applications conforming to these guidelines to interoperate without additional negotiation. These guidelines are not intended to restrict operating parameters for applications that can negotiate a set of interoperable parameters, e.g., through a conference control protocol.
アプリケーションが追加交渉なしで共同利用するこれらのガイドラインに従うセット。 これらのガイドラインが1セットの共同利用できるパラメタを交渉できるアプリケーションのための運転パラメータを制限することを意図しません、例えば、会議制御プロトコルを通して。
For packetized audio, the default packetization interval SHOULD have a duration of 20 ms or one frame, whichever is longer, unless otherwise noted in Table 1 (column "ms/packet"). The packetization interval determines the minimum end-to-end delay; longer packets introduce less header overhead but higher delay and make packet loss more noticeable. For non-interactive applications such as lectures or for links with severe bandwidth constraints, a higher packetization delay MAY be used. A receiver SHOULD accept packets representing between 0 and 200 ms of audio data. (For framed audio encodings, a receiver SHOULD accept packets with a number of frames equal to 200 ms divided by the frame duration, rounded up.) This restriction allows reasonable buffer sizing for the receiver.
デフォルトpacketization間隔SHOULDには、packetizedオーディオのために、20msか1個のフレームの持続時間があります、どれがさらに長いかなら、別の方法でTable1(コラム「ms/パケット」)に述べられない場合。 packetization間隔は終わりから終わりへの最小の遅れを決定します。 より長いパケットで、より少ないヘッダーオーバーヘッドにもかかわらず、より高い遅れを導入して、パケット損失は、よりめぼしくなります。 講演などの非対話的な応用か厳しい帯域幅規制とのリンクのために、より高いpacketization遅れは使用されるかもしれません。 受信機SHOULDはオーディオデータの0〜200msを表すパケットを受け入れます。 (縁どられたオーディオencodings、SHOULDが受け入れる受信機に関して、多くのフレームがあるパケットは切り上げられたフレーム持続時間が割られたmsと200と等しいです。) この制限は受信機のために妥当なバッファサイズ処理を許容します。
4.3 Guidelines for Sample-Based Audio Encodings
4.3 サンプルベースのオーディオEncodingsのためのガイドライン
In sample-based encodings, each audio sample is represented by a fixed number of bits. Within the compressed audio data, codes for individual samples may span octet boundaries. An RTP audio packet may contain any number of audio samples, subject to the constraint that the number of bits per sample times the number of samples per packet yields an integral octet count. Fractional encodings produce less than one octet per sample.
サンプルベースのencodingsでは、それぞれのオーディオのサンプルは固定数のビットによって表されます。 圧縮されたオーディオデータの中では、個々のサンプルのためのコードは八重奏境界にかかるかもしれません。 RTPオーディオパケットは1パケットあたりのサンプルの数が不可欠の八重奏をもたらすというサンプル時間あたりのビットの数が重要であるという規制を条件としていろいろなオーディオのサンプルを含むかもしれません。 断片的なencodingsは1サンプルあたり1つ未満の八重奏を起こします。
The duration of an audio packet is determined by the number of samples in the packet.
パケットのサンプルの数に従って、オーディオパケットの持続時間は決定しています。
For sample-based encodings producing one or more octets per sample, samples from different channels sampled at the same sampling instant SHOULD be packed in consecutive octets. For example, for a two- channel encoding, the octet sequence is (left channel, first sample), (right channel, first sample), (left channel, second sample), (right channel, second sample), .... For multi-octet encodings, octets SHOULD be transmitted in network byte order (i.e., most significant octet first).
同じ標本抽出の即時のSHOULDで抽出された異なったチャンネルからの1サンプルあたり1つ以上の八重奏を起こすサンプルベースのencodings、サンプルに関しては、連続した八重奏では、梱包されてください。 例えば2チャンネルのために、コード化しています、八重奏系列が(左のチャンネル、最初のサンプル)である、(正しいチャンネル、最初のサンプル)、(左のチャンネル、2番目のサンプル)、(正しいチャンネル、2番目のサンプル)、… マルチ八重奏encodings、八重奏SHOULD、ネットワークバイトオーダーで伝えられてください、(すなわち、最も重要な八重奏、1番目)
The packing of sample-based encodings producing less than one octet per sample is encoding-specific.
1サンプルあたり1つ未満の八重奏を起こすサンプルベースのencodingsのパッキングはコード化して特定です。
The RTP timestamp reflects the instant at which the first sample in the packet was sampled, that is, the oldest information in the packet.
RTPタイムスタンプはパケットにおける最初のサンプルが抽出された瞬間を反映します、すなわち、パケットで最も古い情報。
Schulzrinne & Casner Standards Track [Page 10] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[10ページ]RFCプロフィール2003年7月
4.4 Guidelines for Frame-Based Audio Encodings
4.4 フレームベースのオーディオEncodingsのためのガイドライン
Frame-based encodings encode a fixed-length block of audio into another block of compressed data, typically also of fixed length. For frame-based encodings, the sender MAY choose to combine several such frames into a single RTP packet. The receiver can tell the number of frames contained in an RTP packet, if all the frames have the same length, by dividing the RTP payload length by the audio frame size which is defined as part of the encoding. This does not work when carrying frames of different sizes unless the frame sizes are relatively prime. If not, the frames MUST indicate their size.
フレームベースのencodingsは別のブロックの圧縮されたデータへのオーディオと、通常、固定長についても固定長ブロックをコード化します。 フレームベースのencodingsのために、送付者は、そのようないくつかのフレームを単一のRTPパケットに結合するのを選ぶかもしれません。 受信機はRTPパケットに含まれたフレームの数を言うことができます、すべてのフレームに同じ長さがあるなら、コード化の一部と定義されるオーディオフレーム・サイズにRTPペイロード長を割ることによって。 フレーム・サイズが比較的主要でない場合異なったサイズのフレームを運ぶとき、これは働いていません。 そうでなければ、フレームはそれらのサイズを示さなければなりません。
For frame-based codecs, the channel order is defined for the whole block. That is, for two-channel audio, right and left samples SHOULD be coded independently, with the encoded frame for the left channel preceding that for the right channel.
フレームベースのコーデックに関しては、チャンネル注文を全体のブロックと定義します。 すなわち、2チャンネルのオーディオには、左右なサンプルSHOULDが独自にコード化されて、左のチャンネルのためのコード化されたフレームが権利のためにそれに先行していて、精神を集中してください。
All frame-oriented audio codecs SHOULD be able to encode and decode several consecutive frames within a single packet. Since the frame size for the frame-oriented codecs is given, there is no need to use a separate designation for the same encoding, but with different number of frames per packet.
すべてのフレーム指向のオーディオコーデックSHOULDはエンコードにできて、いくつかの連続したフレームを解読します。単一のパケットの中で。 フレーム指向のコーデックのためのフレーム・サイズを与えるので、同じコード化に別々の名称を使用しますが、異なった数の1パケットあたりのフレームで使用する必要は全くありません。
RTP packets SHALL contain a whole number of frames, with frames inserted according to age within a packet, so that the oldest frame (to be played first) occurs immediately after the RTP packet header. The RTP timestamp reflects the instant at which the first sample in the first frame was sampled, that is, the oldest information in the packet.
RTPパケットSHALLはフレームの整数を含んでいます、時代に従ってフレームがパケットの中で挿入されている状態で、最も古いフレーム(最初にプレーされる)がRTPパケットのヘッダー直後現れるように。 RTPタイムスタンプは最初のフレームにおける最初のサンプルが抽出された瞬間を反映します、すなわち、パケットで最も古い情報。
Schulzrinne & Casner Standards Track [Page 11] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[11ページ]RFCプロフィール2003年7月
4.5 Audio Encodings
4.5 オーディオEncodings
name of sampling default encoding sample/frame bits/sample rate ms/frame ms/packet __________________________________________________________________ DVI4 sample 4 var. 20 G722 sample 8 16,000 20 G723 frame N/A 8,000 30 30 G726-40 sample 5 8,000 20 G726-32 sample 4 8,000 20 G726-24 sample 3 8,000 20 G726-16 sample 2 8,000 20 G728 frame N/A 8,000 2.5 20 G729 frame N/A 8,000 10 20 G729D frame N/A 8,000 10 20 G729E frame N/A 8,000 10 20 GSM frame N/A 8,000 20 20 GSM-EFR frame N/A 8,000 20 20 L8 sample 8 var. 20 L16 sample 16 var. 20 LPC frame N/A 8,000 20 20 MPA frame N/A var. var. PCMA sample 8 var. 20 PCMU sample 8 var. 20 QCELP frame N/A 8,000 20 20 VDVI sample var. var. 20
サンプル/フレームビット/見本郵送料率ms/フレームms/パケットをコード化する標本抽出デフォルトの名前__________________________________________________________________ DVI4サンプル4var. 20 G722サンプル8 16,000 20G723フレームN/A8,000 30 30G726-40サンプル5 8,000 20G726-32サンプル4 8,000 20G726-24サンプル3 8,000 20G726-16サンプル2 8,000 20G728フレームN/A8,000 2.5 20G729フレームN/A8,000 10 20G729DフレームN/A8,000 10 20G729EフレームN/A8,000 10 20GSMフレームN/A8,000 20 20GSM-EFRフレームN/A8,000 20 20L8サンプル8var. 20 L16サンプル16var. 20 LPCフレームN/A8,000 20 20MPAフレームN/A var.var. PCMAサンプル8var. 20 PCMUサンプル8var. 20QCELPフレームN/は8,000 20 20VDVIサンプルvar.var.です。 20
Table 1: Properties of Audio Encodings (N/A: not applicable; var.:
variable)
テーブル1: オーディオEncodingsの特性(適切でないN/A:; var.: 変数)
The characteristics of the audio encodings described in this document are shown in Table 1; they are listed in order of their payload type in Table 4. While most audio codecs are only specified for a fixed sampling rate, some sample-based algorithms (indicated by an entry of "var." in the sampling rate column of Table 1) may be used with different sampling rates, resulting in different coded bit rates. When used with a sampling rate other than that for which a static payload type is defined, non-RTP means beyond the scope of this memo MUST be used to define a dynamic payload type and MUST indicate the selected RTP timestamp clock rate, which is usually the same as the sampling rate for audio.
encodingsが説明したオーディオの特性はTable1に本書では示されます。 それらはTable4の彼らのペイロードタイプの順に記載されています。 ほとんどのオーディオコーデックが固定標本抽出率に指定されているだけである間、いくつかのサンプルベースのアルゴリズム(Table1に関する標本抽出率コラムにおける、「var.」のエントリーで、示される)が異なった標本抽出率と共に使用されるかもしれません、異なったコード化されたビット伝送速度をもたらして。 静的なペイロードタイプが定義されるそれを除いた標本抽出率と共に使用されると、このメモの範囲を超えた非RTP手段は、ダイナミックなペイロードタイプを定義するのに使用しなければならなくて、選択されたRTPタイムスタンプクロックレートを示さなければなりません。(通常、それは、オーディオのための標本抽出率と同じです)。
Schulzrinne & Casner Standards Track [Page 12] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[12ページ]RFCプロフィール2003年7月
4.5.1 DVI4
4.5.1 DVI4
DVI4 uses an adaptive delta pulse code modulation (ADPCM) encoding scheme that was specified by the Interactive Multimedia Association (IMA) as the "IMA ADPCM wave type". However, the encoding defined here as DVI4 differs in three respects from the IMA specification:
DVI4は、「IMA ADPCM波のタイプ」としてインタラクティブ・マルチメディア協会(IMA)によって指定された計画をコード化しながら、適応型のデルタパルスコード変調(ADPCM)を使用します。 しかしながら、ここでDVI4と定義されたコード化はIMA仕様と3つの点において異なります:
o The RTP DVI4 header contains the predicted value rather than the
first sample value contained the IMA ADPCM block header.
o RTP DVI4ヘッダーは最初の標本値がIMA ADPCMブロックヘッダーを含んだよりむしろ予測値を含んでいます。
o IMA ADPCM blocks contain an odd number of samples, since the first
sample of a block is contained just in the header (uncompressed),
followed by an even number of compressed samples. DVI4 has an
even number of compressed samples only, using the `predict' word
from the header to decode the first sample.
o IMA ADPCMブロックはサンプルの奇数を含んでいます、1ブロックの最初のサンプルがまさしく圧縮されたサンプルの偶数があとに続いたヘッダー(解凍される)に含まれているので。 DVI4には、圧縮されたサンプルだけの偶数があります、最初のサンプルを解読するのにヘッダーからの'予測'単語を使用して。
o For DVI4, the 4-bit samples are packed with the first sample in
the four most significant bits and the second sample in the four
least significant bits. In the IMA ADPCM codec, the samples are
packed in the opposite order.
o DVI4に関しては、4ビットのサンプルは4つの最上位ビットにおける最初のサンプルと4つの最下位ビットにおける2番目のサンプルで詰められています。 IMA ADPCMコーデックでは、サンプルは反対のオーダーで詰められています。
Each packet contains a single DVI block. This profile only defines the 4-bit-per-sample version, while IMA also specified a 3-bit-per- sample encoding.
各パケットは1つのDVIブロックを含んでいます。 このプロフィールは1サンプルあたり4ビットのバージョンを定義するだけですが、また、IMAは噛み付いているサンプルの3コード化を指定しました。
The "header" word for each channel has the following structure:
各チャンネルに対する「ヘッダー」単語には、以下の構造があります:
int16 predict; /* predicted value of first sample
from the previous block (L16 format) */
u_int8 index; /* current index into stepsize table */
u_int8 reserved; /* set to zero by sender, ignored by receiver */
int16、予測します。 /*は前のブロック(L16形式)*/u_int8インデックスから最初のサンプルの値を予測しました。 電流が索引をつける/*はint8が予約したテーブル*/u_をstepsizeします。 /*は受信機*/によって無視された送付者でゼロにセットしました。
Each octet following the header contains two 4-bit samples, thus the number of samples per packet MUST be even because there is no means to indicate a partially filled last octet.
ヘッダーに続く各八重奏が2個の4ビットのサンプルを含んでいます、その結果、aが最後の八重奏を部分的にいっぱいにしたのを示す手段が全くないので、1パケットあたりのサンプルの数は偶数であるに違いありません。
Packing of samples for multiple channels is for further study.
さらなる研究には複数のチャンネルへのサンプルのパッキングがあります。
The IMA ADPCM algorithm was described in the document IMA Recommended Practices for Enhancing Digital Audio Compatibility in Multimedia Systems (version 3.0). However, the Interactive Multimedia Association ceased operations in 1997. Resources for an archived copy of that document and a software implementation of the RTP DVI4 encoding are listed in Section 13.
IMA ADPCMアルゴリズムはMultimedia Systems(バージョン3.0)のEnhancingデジタル・オーディオCompatibilityのためのドキュメントIMA Recommended Practicesで説明されました。 しかしながら、インタラクティブ・マルチメディア協会は1997年に操作をやめました。 そのドキュメントの保存されたコピーとRTP DVI4コード化のソフトウェア実行のためのリソースはセクション13にリストアップされています。
Schulzrinne & Casner Standards Track [Page 13] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[13ページ]RFCプロフィール2003年7月
4.5.2 G722
4.5.2 G722
G722 is specified in ITU-T Recommendation G.722, "7 kHz audio-coding within 64 kbit/s". The G.722 encoder produces a stream of octets, each of which SHALL be octet-aligned in an RTP packet. The first bit transmitted in the G.722 octet, which is the most significant bit of the higher sub-band sample, SHALL correspond to the most significant bit of the octet in the RTP packet.
ITU-T Recommendation G.722、「64kbit/sの中の7kHzのオーディオ符号化」でG722は指定されます。 G.722エンコーダはどのSHALLが八重奏、RTPパケットで八重奏によってそれぞれ並べられるかに関する流れを起こします。 より高いサブバンドのサンプルの最も重要なビットであるG.722八重奏で伝えられた最初のビット、SHALLは八重奏のRTPパケットで最も重要なビットに対応しています。
Even though the actual sampling rate for G.722 audio is 16,000 Hz, the RTP clock rate for the G722 payload format is 8,000 Hz because that value was erroneously assigned in RFC 1890 and must remain unchanged for backward compatibility. The octet rate or sample-pair rate is 8,000 Hz.
G.722オーディオのための実際の標本抽出率は1万6000Hzですが、その値はRFC1890で誤って割り当てられて、後方の互換性のために変わりがあってはいけないので、G722ペイロード形式のためのRTPクロックレートは8,000Hzです。 八重奏率かサンプル組レートが8,000Hzです。
4.5.3 G723
4.5.3 G723
G723 is specified in ITU Recommendation G.723.1, "Dual-rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s". The G.723.1 5.3/6.3 kbit/s codec was defined by the ITU-T as a mandatory codec for ITU-T H.324 GSTN videophone terminal applications. The algorithm has a floating point specification in Annex B to G.723.1, a silence compression algorithm in Annex A to G.723.1 and a scalable channel coding scheme for wireless applications in G.723.1 Annex C.
ITU Recommendation G.723.1、「5.3と6.3kbit/sを伝わるマルチメディア通信のための二元的なレート音声符号器」でG723は指定されます。 G.723.1 5.3/6.3kbit/sコーデックはITU-TによってITU-T H.324 GSTNテレビ電話端末アプリケーションのための義務的なコーデックと定義されました。 アルゴリズムはAnnex BにG.723.1、G.723.1へのAnnex Aの沈黙圧縮アルゴリズム、および無線機器のためのG.723.1 Annex Cのスケーラブルなチャンネルコード構成に浮動小数点仕様を持っています。
This Recommendation specifies a coded representation that can be used for compressing the speech signal component of multi-media services at a very low bit rate. Audio is encoded in 30 ms frames, with an additional delay of 7.5 ms due to look-ahead. A G.723.1 frame can be one of three sizes: 24 octets (6.3 kb/s frame), 20 octets (5.3 kb/s frame), or 4 octets. These 4-octet frames are called SID frames (Silence Insertion Descriptor) and are used to specify comfort noise parameters. There is no restriction on how 4, 20, and 24 octet frames are intermixed. The least significant two bits of the first octet in the frame determine the frame size and codec type:
このRecommendationは非常に低いビット伝送速度でマルチメディアサービスのスピーチ信号の部品を圧縮するのに使用できるコード値を指定します。 オーディオは30個のmsフレームで前を見るのにおいて当然の7.5msの追加遅れでコード化されます。 G.723.1フレームは3つのサイズの1つであるかもしれません: 24の八重奏(6.3kb/sフレーム)、20の八重奏(5.3kb/sフレーム)、または4つの八重奏。 これらの4八重奏のフレームは、SIDフレーム(沈黙Insertion Descriptor)と呼ばれて、安らぎ雑音パラメタを指定するのにおいて使用されています。 どう4、20、および24個の八重奏フレームを混ぜるかに関する制限が全くありません。 最初の八重奏のフレームで最も重要でない2ビットは、フレーム・サイズとコーデックがタイプされることを決定します:
bits content octets/frame
00 high-rate speech (6.3 kb/s) 24
01 low-rate speech (5.3 kb/s) 20
10 SID frame 4
11 reserved
満足している八重奏/フレーム00高い率スピーチ(6.3kb/s)24 01低率スピーチ(5.3kb/s)20 10SIDフレーム4 11が予約したビット
Schulzrinne & Casner Standards Track [Page 14] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[14ページ]RFCプロフィール2003年7月
It is possible to switch between the two rates at any 30 ms frame boundary. Both (5.3 kb/s and 6.3 kb/s) rates are a mandatory part of the encoder and decoder. Receivers MUST accept both data rates and MUST accept SID frames unless restriction of these capabilities has been signaled. The MIME registration for G723 in RFC 3555 [7] specifies parameters that MAY be used with MIME or SDP to restrict to a single data rate or to restrict the use of SID frames. This coder was optimized to represent speech with near-toll quality at the above rates using a limited amount of complexity.
どんな30msフレーム境界でも2つのレートを切り換えるのは可能です。 両方の(5.3kb/sと6.3kb/s)レートはエンコーダとデコーダの義務的な部分です。 これらの能力の制限が合図されていない場合、受信機は、両方のデータ信号速度を受け入れなければならなくて、SIDフレームを受け入れなければなりません。 RFC3555[7]のG723のためのMIME登録はただ一つのデータ信号速度に制限するか、または使用を制限するMIMEかSDPと共に使用されるかもしれないパラメタを指定します。SIDフレーム。 この符号化器は、料金における上記料金における品質で複雑さの数量限定を使用することでスピーチを表すために最適化されました。
The packing of the encoded bit stream into octets and the transmission order of the octets is specified in Rec. G.723.1 and is the same as that produced by the G.723 C code reference implementation. For the 6.3 kb/s data rate, this packing is illustrated as follows, where the header (HDR) bits are always "0 0" as shown in Fig. 1 to indicate operation at 6.3 kb/s, and the Z bit is always set to zero. The diagrams show the bit packing in "network byte order", also known as big-endian order. The bits of each 32-bit word are numbered 0 to 31, with the most significant bit on the left and numbered 0. The octets (bytes) of each word are transmitted most significant octet first. The bits of each data field are numbered in the order of the bit stream representation of the encoding (least significant bit first). The vertical bars indicate the boundaries between field fragments.
八重奏へのコード化されたビットストリームのパッキングと八重奏のトランスミッション命令はRecで指定されます。 G.723.1、そんなに生産されるのとG.723Cコード参照実現による同じくらいはそうです。 6.3kb/sデータ信号速度において、このパッキングは以下の通り例証されます、いつもヘッダー(HDR)ビットが「合わせてください6.3KB/sで操作を必要とするように図1に示される0インチ、およびZビットがいつも設定されるゼロ0」であるところで。 ダイヤグラムは「ネットワークバイトオーダー」を大勢引きつけて、また、ビッグエンディアンオーダーとして知られていた状態でビットを示しています。 それぞれの32ビットの単語のビットは0〜31に付番されます、左の、そして、番号付の0で最も重要なビットで。 最初に、それぞれの単語の八重奏(バイト)は伝えられた最も重要な八重奏です。 それぞれのデータ・フィールドのビットがコード化のビットストリーム表現の注文で付番される、(最下位ビット、1番目) 縦棒は分野断片の間の境界を示します。
Schulzrinne & Casner Standards Track [Page 15] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[15ページ]RFCプロフィール2003年7月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LPC |HDR| LPC | LPC | ACL0 |LPC|
| | | | | | |
|0 0 0 0 0 0|0 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2|
|5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 |
| | 1 |C| | 3 | 2 | | |
|0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
|4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 |
| | | | | | |
|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0|
|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSBPOS |Z|POS| MSBPOS | POS0 |POS| POS0 |
| | | 0 | | | 1 | |
|0 0 0 0 0 0 0|0|0 0|1 1 1 0 0 0|0 0 0 0 0 0 0 0|0 0|1 1 1 1 1 1|
|6 5 4 3 2 1 0| |1 0|2 1 0 9 8 7|9 8 7 6 5 4 3 2|1 0|5 4 3 2 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POS1 | POS2 | POS1 | POS2 | POS3 | POS2 |
| | | | | | |
|0 0 0 0 0 0 0 0|0 0 0 0|1 1 1 1|1 1 0 0 0 0 0 0|0 0 0 0|1 1 1 1|
|9 8 7 6 5 4 3 2|3 2 1 0|3 2 1 0|1 0 9 8 7 6 5 4|3 2 1 0|5 4 3 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POS3 | PSIG0 |POS|PSIG2| PSIG1 | PSIG3 |PSIG2|
| | | 3 | | | | |
|1 1 0 0 0 0 0 0|0 0 0 0 0 0|1 1|0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0|
|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|2 1 0|4 3 2 1 0|4 3 2 1 0|5 4 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC|HDR| LPC| LPC| ACL0|LPC| | | | | | | | |0 0 0 0 0 0|0 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACL2|ACL|A| GAIN0|ACL|ACL| GAIN0| GAIN1| | | 1 |C| | 3 | 2 | | | |0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAIN2| GAIN1| GAIN2| GAIN3| 格子| GAIN3| | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSBPOS|Z|POS| MSBPOS| POS0|POS| POS0| | | | 0 | | | 1 | | |0 0 0 0 0 0 0|0|0 0|1 1 1 0 0 0|0 0 0 0 0 0 0 0|0 0|1 1 1 1 1 1| |6 5 4 3 2 1 0| |1 0|2 1 0 9 8 7|9 8 7 6 5 4 3 2|1 0|5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS1| POS2| POS1| POS2| POS3| POS2| | | | | | | | |0 0 0 0 0 0 0 0|0 0 0 0|1 1 1 1|1 1 0 0 0 0 0 0|0 0 0 0|1 1 1 1| |9 8 7 6 5 4 3 2|3 2 1 0|3 2 1 0|1 0 9 8 7 6 5 4|3 2 1 0|5 4 3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS3| PSIG0|POS|PSIG2| PSIG1| PSIG3|PSIG2| | | | 3 | | | | | |1 1 0 0 0 0 0 0|0 0 0 0 0 0|1 1|0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0| |1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|2 1 0|4 3 2 1 0|4 3 2 1 0|5 4 3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: G.723 (6.3 kb/s) bit packing
図1: G.723(6.3kb/s)はパッキングに噛み付きました。
For the 5.3 kb/s data rate, the header (HDR) bits are always "0 1", as shown in Fig. 2, to indicate operation at 5.3 kb/s.
5.3kb/sデータ信号速度のために、ヘッダー(HDR)ビットはいつも、「0 操作を必要とするように、5.3では、何1インチも、/sは図2に示されるようにkbしている」ということです。
Schulzrinne & Casner Standards Track [Page 16] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[16ページ]RFCプロフィール2003年7月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LPC |HDR| LPC | LPC | ACL0 |LPC|
| | | | | | |
|0 0 0 0 0 0|0 1|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2|
|5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 |
| | 1 |C| | 3 | 2 | | |
|0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
|4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 |
| | | | | | |
|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0|
|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|4 3 2 1|1 0 9 8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POS0 | POS1 | POS0 | POS1 | POS2 |
| | | | | |
|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
|7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POS3 | POS2 | POS3 | PSIG1 | PSIG0 | PSIG3 | PSIG2 |
| | | | | | | |
|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|
|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|3 2 1 0|3 2 1 0|3 2 1 0|3 2 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC|HDR| LPC| LPC| ACL0|LPC| | | | | | | | |0 0 0 0 0 0|0 1|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACL2|ACL|A| GAIN0|ACL|ACL| GAIN0| GAIN1| | | 1 |C| | 3 | 2 | | | |0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAIN2| GAIN1| GAIN2| GAIN3| 格子| GAIN3| | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|4 3 2 1|1 0 9 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS0| POS1| POS0| POS1| POS2| | | | | | | |0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS3| POS2| POS3| PSIG1| PSIG0| PSIG3| PSIG2| | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|3 2 1 0|3 2 1 0|3 2 1 0|3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: G.723 (5.3 kb/s) bit packing
図2: G.723(5.3kb/s)はパッキングに噛み付きました。
The packing of G.723.1 SID (silence) frames, which are indicated by the header (HDR) bits having the pattern "1 0", is depicted in Fig. 3.
G.723.1 SID(沈黙)フレームのパッキング、「1 表現されたコネは何0インチも、図3ですか?」(フレームはパターンを持っているヘッダー(HDR)ビットによって示されます)。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LPC |HDR| LPC | LPC | GAIN |LPC|
| | | | | | |
|0 0 0 0 0 0|1 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2|
|5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC|HDR| LPC| LPC| 利得|LPC| | | | | | | | |0 0 0 0 0 0|1 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: G.723 SID mode bit packing
図3: G.723 SIDモードビットパッキング
Schulzrinne & Casner Standards Track [Page 17] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[17ページ]RFCプロフィール2003年7月
4.5.4 G726-40, G726-32, G726-24, and G726-16
4.5.4 G726-40、G726-32、G726-24、およびG726-16
ITU-T Recommendation G.726 describes, among others, the algorithm recommended for conversion of a single 64 kbit/s A-law or mu-law PCM channel encoded at 8,000 samples/sec to and from a 40, 32, 24, or 16 kbit/s channel. The conversion is applied to the PCM stream using an Adaptive Differential Pulse Code Modulation (ADPCM) transcoding technique. The ADPCM representation consists of a series of codewords with a one-to-one correspondence to the samples in the PCM stream. The G726 data rates of 40, 32, 24, and 16 kbit/s have codewords of 5, 4, 3, and 2 bits, respectively.
ITU-T Recommendation G.726は特に40と40から8,000サンプル/秒のときにコード化された、単独の64s A-法かμkbit/法のPCMチャンネル、32、24、または16kbit/sチャンネルの変換のために推薦されたアルゴリズムを説明します。 変換は、Adaptive Differentialパルスコードの変調(ADPCM)コード変換のテクニックを使用することでPCMの流れに適用されます。 ADPCM表現はサンプルへの1〜1つの通信でPCMの流れで一連の符号語から成ります。 40、32、24のG726データ信号速度、および16kbit/sには、それぞれ5、4、3、および2ビットの符号語があります。
The 16 and 24 kbit/s encodings do not provide toll quality speech. They are designed for used in overloaded Digital Circuit Multiplication Equipment (DCME). ITU-T G.726 recommends that the 16 and 24 kbit/s encodings should be alternated with higher data rate encodings to provide an average sample size of between 3.5 and 3.7 bits per sample.
encodingsが提供しない16と24kbit/sは上質のスピーチに料金を課します。 それらは中に積みすぎられた中古のDigital Circuit Multiplication Equipment(DCME)のために設計されています。 ITU-T G.726は、16と24kbit/s encodingsが1サンプルあたり3.5〜3.7ビットの標準見本サイズに提供するために、より高いデータ信号速度encodingsと交替されるべきであることを勧めます。
The encodings of G.726 are here denoted as G726-40, G726-32, G726-24, and G726-16. Prior to 1990, G721 described the 32 kbit/s ADPCM encoding, and G723 described the 40, 32, and 16 kbit/s encodings. Thus, G726-32 designates the same algorithm as G721 in RFC 1890.
G726-40、G726-32、G726-24、およびG726-16として指示されて、G.726のencodingsがここにあります。 1990年前に、G721は32kbit/s ADPCMコード化について説明しました、そして、G723は40、32、および16kbit/s encodingsについて説明しました。 したがって、G726-32はRFCのG721と同じアルゴリズムを1890に指定します。
A stream of G726 codewords contains no information on the encoding being used, therefore transitions between G726 encoding types are not permitted within a sequence of packed codewords. Applications MUST determine the encoding type of packed codewords from the RTP payload identifier.
G726符号語の流れは使用されるコード化の情報を全く含んでいません、したがって、タイプをコード化するG726の間の変遷が詰まっている符号語の系列の中で受入れられません。 アプリケーションはRTPペイロード識別子からコード化しているタイプの詰まっている符号語を決定しなければなりません。
No payload-specific header information SHALL be included as part of the audio data. A stream of G726 codewords MUST be packed into octets as follows: the first codeword is placed into the first octet such that the least significant bit of the codeword aligns with the least significant bit in the octet, the second codeword is then packed so that its least significant bit coincides with the least significant unoccupied bit in the octet. When a complete codeword cannot be placed into an octet, the bits overlapping the octet boundary are placed into the least significant bits of the next octet. Packing MUST end with a completely packed final octet. The number of codewords packed will therefore be a multiple of 8, 2, 8, and 4 for G726-40, G726-32, G726-24, and G726-16, respectively. An example of the packing scheme for G726-32 codewords is as shown, where bit 7 is the least significant bit of the first octet, and bit A3 is the least significant bit of the first codeword:
いいえ、ペイロード特有のヘッダー情報SHALL。オーディオデータの一部として、含まれています。 G726符号語の流れに以下の八重奏に詰め込まなければなりません: 最初の符号語が符号語の最下位ビットが八重奏における最下位ビットに並ぶように最初の八重奏に置かれて、次に、2番目の符号語が梱包されるので、最下位ビットは八重奏で最も重要でない居住者のいないビットと一致しています。 完全な符号語を八重奏に置くことができないとき、八重奏境界を重ね合わせるビットは次の八重奏の最下位ビットに置かれます。 パッキングは完全に詰まっている最終的な八重奏で終わらなければなりません。 したがって、梱包された符号語の数は、それぞれ8、2、8の倍数と、G726-40のための4と、G726-32と、G726-24と、G726-16になるでしょう。 示されるとしてG726-32符号語のパッキング計画に関する例があります、ビット7が最初の八重奏の最下位ビットであり、ビットA3が最初の符号語の最下位ビットであるところで:
Schulzrinne & Casner Standards Track [Page 18] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[18ページ]RFCプロフィール2003年7月
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|B B B B|A A A A|D D D D|C C C C| ...
|0 1 2 3|0 1 2 3|0 1 2 3|0 1 2 3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |B B B B|A A A|D D D D|C C C C| ... |0 1 2 3|0 1 2 3|0 1 2 3|0 1 2 3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
An example of the packing scheme for G726-24 codewords follows, where again bit 7 is the least significant bit of the first octet, and bit A2 is the least significant bit of the first codeword:
G726-24符号語のパッキング計画に関する例(再びビット7は最初の八重奏の最下位ビットである)は従います、そして、ビットA2は最初の符号語の最下位ビットです:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|C C|B B B|A A A|F|E E E|D D D|C|H H H|G G G|F F| ...
|1 2|0 1 2|0 1 2|2|0 1 2|0 1 2|0|0 1 2|0 1 2|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |C C|B B B|A A|F|E E E|D D D|C|H H H|G G G|F F| ... |1 2|0 1 2|0 1 2|2|0 1 2|0 1 2|0|0 1 2|0 1 2|0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Note that the "little-endian" direction in which samples are packed into octets in the G726-16, -24, -32 and -40 payload formats specified here is consistent with ITU-T Recommendation X.420, but is the opposite of what is specified in ITU-T Recommendation I.366.2 Annex E for ATM AAL2 transport. A second set of RTP payload formats matching the packetization of I.366.2 Annex E and identified by MIME subtypes AAL2-G726-16, -24, -32 and -40 will be specified in a separate document.
サンプルがG726-16の八重奏、-24、-32、および-40のペイロード形式に詰められている「リトルエンディアン」指示がここで指定したというメモは、ITU-T Recommendation X.420と一致していますが、ITU-T Recommendation I.366.2 Annex EでATM AAL2輸送に指定されることの正反対です。 MIME血液型亜型AAL2-G726-16、-24、-32、および-40によってI.366.2 Annex Eのpacketizationを合わせて、特定された2番目の1セットのRTPペイロード形式は別々のドキュメントで指定されるでしょう。
4.5.5 G728
4.5.5 G728
G728 is specified in ITU-T Recommendation G.728, "Coding of speech at 16 kbit/s using low-delay code excited linear prediction".
G728はITU-T Recommendation G.728、「低い遅れコードを使用する16kbit/sのスピーチのコード化は直線的な予測を起こしたところ」で指定されます。
A G.278 encoder translates 5 consecutive audio samples into a 10-bit codebook index, resulting in a bit rate of 16 kb/s for audio sampled at 8,000 samples per second. The group of five consecutive samples is called a vector. Four consecutive vectors, labeled V1 to V4 (where V1 is to be played first by the receiver), build one G.728 frame. The four vectors of 40 bits are packed into 5 octets, labeled B1 through B5. B1 SHALL be placed first in the RTP packet.
G.278エンコーダは5個の連続したオーディオのサンプルを10ビットの符号表インデックスに翻訳します、1秒あたり8,000個のサンプルで抽出されたオーディオのための16kb/sのレートを少しもたらして。 先進5ヵ国財務相・中央銀行総裁会議の連続したサンプルはベクトルと呼ばれます。 V4(V1が最初に、受信機によってプレーされることになっているところ)へのV1とラベルされた4つの連続したベクトルが1個のG.728フレームを建設します。 40ビットの4つのベクトルがB5を通してB1とラベルされた5つの八重奏に詰め込まれます。 B1 SHALL、最初に、RTPパケットに置かれてください。
Referring to the figure below, the principle for bit order is "maintenance of bit significance". Bits from an older vector are more significant than bits from newer vectors. The MSB of the frame goes to the MSB of B1 and the LSB of the frame goes to LSB of B5.
以下の図について言及して、噛み付いているオーダーのための原則は「噛み付いている意味の維持」です。 より古いベクトルからのビットは、より新しいベクトルからのビットより重要です。 フレームのMSBはB1のMSBに行きます、そして、フレームのLSBはB5のLSBに行きます。
Schulzrinne & Casner Standards Track [Page 19] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[19ページ]RFCプロフィール2003年7月
1 2 3 3
0 0 0 0 9
++++++++++++++++++++++++++++++++++++++++
<---V1---><---V2---><---V3---><---V4---> vectors
<--B1--><--B2--><--B3--><--B4--><--B5--> octets
<------------- frame 1 ---------------->
++++++++++++++ + + + + + + + + + + + + + + + + + + + + + + + + 1 2 3 3 0 0 0 0 9++<。---V1---><、-、--V2---><、-、--V3---><、-、--V4--->ベクトル<--B1--><--B2--><--B3--><--B4--><--B5-->八重奏<。------------- フレーム1---------------->。
In particular, B1 contains the eight most significant bits of V1, with the MSB of V1 being the MSB of B1. B2 contains the two least significant bits of V1, the more significant of the two in its MSB, and the six most significant bits of V2. B1 SHALL be placed first in the RTP packet and B5 last.
特に、B1はV1の8つの最上位ビットを含んでいます、B1のMSBであるV1のMSBで。 B2はV1の2つの最下位ビットを含んでいます、MSBの2、およびV2の6つの最上位ビットでは、より重要です。 B1 SHALL、最後に最初に、RTPパケットとB5に置かれてください。
4.5.6 G729
4.5.6 G729
G729 is specified in ITU-T Recommendation G.729, "Coding of speech at 8 kbit/s using conjugate structure-algebraic code excited linear prediction (CS-ACELP)". A reduced-complexity version of the G.729 algorithm is specified in Annex A to Rec. G.729. The speech coding algorithms in the main body of G.729 and in G.729 Annex A are fully interoperable with each other, so there is no need to further distinguish between them. An implementation that signals or accepts use of G729 payload format may implement either G.729 or G.729A unless restricted by additional signaling specified elsewhere related specifically to the encoding rather than the payload format. The G.729 and G.729 Annex A codecs were optimized to represent speech with high quality, where G.729 Annex A trades some speech quality for an approximate 50% complexity reduction [10]. See the next Section (4.5.7) for other data rates added in later G.729 Annexes. For all data rates, the sampling frequency (and RTP timestamp clock rate) is 8,000 Hz.
G729はITU-T Recommendation G.729、「接合の構造代数的なコードを使用する8kbit/sのスピーチのコード化は直線的な予測(CS-ACELP)を起こしたところ」で指定されます。 G.729アルゴリズムの減少している複雑さバージョンはAnnex AでRecに指定されます。 G.729。 G.729の本体とG.729 Annex Aの音声符号化アルゴリズムが互いと共に完全に共同利用できるので、さらにそれらを見分ける必要は全くありません。 G729ペイロード形式の使用を示すか、または受け入れる実現がG.729を実行するかもしれませんか、またはほかの場所で指定された追加シグナリングによって制限されない場合、G.729Aは特にペイロード形式よりむしろコード化に関連しました。 G.729とG.729 Annex Aコーデックは、高い品質でスピーチを表すために最適化されました。(そこでは、G.729 Annex Aは50%の大体の複雑さ減少[10]のために何らかのスピーチ品質を取り引きします)。 次のセクションを見てください、(4.5 他のデータ信号速度のための.7は)後のG.729 Annexesを加えました。 すべてのデータ信号速度のために、サンプリング周波数(そして、RTPタイムスタンプクロックレート)は8,000Hzです。
A voice activity detector (VAD) and comfort noise generator (CNG) algorithm in Annex B of G.729 is RECOMMENDED for digital simultaneous voice and data applications and can be used in conjunction with G.729 or G.729 Annex A. A G.729 or G.729 Annex A frame contains 10 octets, while the G.729 Annex B comfort noise frame occupies 2 octets. Receivers MUST accept comfort noise frames if restriction of their use has not been signaled. The MIME registration for G729 in RFC 3555 [7] specifies a parameter that MAY be used with MIME or SDP to restrict the use of comfort noise frames.
G.729のAnnex Bの音声活動探知器(VAD)と安らぎ雑音発生器(CNG)アルゴリズムは、デジタル同時の声とデータアプリケーションのためのRECOMMENDEDであり、G.729に関連して使用できますか、またはA G.729かG.729 Annex Aが縁どるG.729 Annex A.は10の八重奏を含んでいます、G.729 Annex B安らぎ雑音フレームが2つの八重奏を占領しますが。 彼らの使用の制限が合図されていないなら、受信機は安らぎ雑音フレームを受け入れなければなりません。 RFC3555[7]のG729のためのMIME登録は安らぎ雑音フレームの使用を制限するのにMIMEかSDPと共に使用されるかもしれないパラメタを指定します。
A G729 RTP packet may consist of zero or more G.729 or G.729 Annex A frames, followed by zero or one G.729 Annex B frames. The presence of a comfort noise frame can be deduced from the length of the RTP payload. The default packetization interval is 20 ms (two frames), but in some situations it may be desirable to send 10 ms packets. An
G729 RTPパケットはG.729かG.729 Annex Aが縁どるゼロか以上から成るかもしれません、ゼロか1つのG.729 Annex Bフレームによって続かれて。 RTPペイロードの長さから安らぎ雑音フレームの存在を推論できます。 デフォルトpacketization間隔は20ms(2個のフレーム)ですが、いくつかの状況で、10のmsパケットを送るのは望ましいかもしれません。 1
Schulzrinne & Casner Standards Track [Page 20] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[20ページ]RFCプロフィール2003年7月
example would be a transition from speech to comfort noise in the first 10 ms of the packet. For some applications, a longer packetization interval may be required to reduce the packet rate.
スピーチから安らぎ雑音まで例はパケットの最初の10msの変遷でしょう。 いくつかのアプリケーションにおいて、より長いpacketization間隔が、パケットレートを低下させるのに必要であるかもしれません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| L1 | L2 | L3 | P1 |P| C1 |
|0| | | | |0| |
| |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7| |0 1 2 3 4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C1 | S1 | GA1 | GB1 | P2 | C2 |
| 1 1 1| | | | | |
|5 6 7 8 9 0 1 2|0 1 2 3|0 1 2|0 1 2 3|0 1 2 3 4|0 1 2 3 4 5 6 7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C2 | S2 | GA2 | GB2 |
| 1 1 1| | | |
|8 9 0 1 2|0 1 2 3|0 1 2|0 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| L1| L2| L3| P1|P| C1| |0| | | | |0| | | |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7| |0 1 2 3 4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C1| S1| GA1| GB1| P2| C2| | 1 1 1| | | | | | |5 6 7 8 9 0 1 2|0 1 2 3|0 1 2|0 1 2 3|0 1 2 3 4|0 1 2 3 4 5 6 7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C2| S2| GA2| GB2| | 1 1 1| | | | |8 9 0 1 2|0 1 2 3|0 1 2|0 1 2 3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: G.729 and G.729A bit packing
図4: G.729とG.729Aはパッキングに噛み付きました。
The transmitted parameters of a G.729/G.729A 10-ms frame, consisting of 80 bits, are defined in Recommendation G.729, Table 8/G.729. The mapping of the these parameters is given below in Fig. 4. The diagrams show the bit packing in "network byte order", also known as big-endian order. The bits of each 32-bit word are numbered 0 to 31, with the most significant bit on the left and numbered 0. The octets (bytes) of each word are transmitted most significant octet first. The bits of each data field are numbered in the order as produced by the G.729 C code reference implementation.
80ビットから成って、G.729/G.729A 10-msフレームの伝えられたパラメタはRecommendation G.729、Table8/G.729で定義されます。 マッピング、図4の下をこれらのパラメタに与えます。 ダイヤグラムは「ネットワークバイトオーダー」を大勢引きつけて、また、ビッグエンディアンオーダーとして知られていた状態でビットを示しています。 それぞれの32ビットの単語のビットは0〜31に付番されます、左の、そして、番号付の0で最も重要なビットで。 最初に、それぞれの単語の八重奏(バイト)は伝えられた最も重要な八重奏です。 それぞれのデータ・フィールドのビットはG.729Cコード参照実現で生産されるようにオーダーで付番されます。
The packing of the G.729 Annex B comfort noise frame is shown in Fig. 5.
G.729 Annex B安らぎ雑音フレームのパッキングは図5に示されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| LSF1 | LSF2 | GAIN |R|
|S| | | |E|
|F| | | |S|
|0|0 1 2 3 4|0 1 2 3|0 1 2 3 4|V| RESV = Reserved (zero)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| LSF1| LSF2| 利得|R| |S| | | |E| |F| | | |S| |0|0 1 2 3 4|0 1 2 3|0 1 2 3 4|V| RESV=は+++++++++++++++++を予約しました(ゼロ)。
Figure 5: G.729 Annex B bit packing
図5: G.729はB噛み付いているパッキングを付加します。
Schulzrinne & Casner Standards Track [Page 21] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[21ページ]RFCプロフィール2003年7月
4.5.7 G729D and G729E
4.5.7 G729DとG729E
Annexes D and E to ITU-T Recommendation G.729 provide additional data rates. Because the data rate is not signaled in the bitstream, the different data rates are given distinct RTP encoding names which are mapped to distinct payload type numbers. G729D indicates a 6.4 kbit/s coding mode (G.729 Annex D, for momentary reduction in channel capacity), while G729E indicates an 11.8 kbit/s mode (G.729 Annex E, for improved performance with a wide range of narrow-band input signals, e.g., music and background noise). Annex E has two operating modes, backward adaptive and forward adaptive, which are signaled by the first two bits in each frame (the most significant two bits of the first octet).
ITU-T Recommendation G.729への別館DとEは追加データ信号速度を提供します。 データ信号速度がbitstreamで合図されないので、異なったペイロード形式数に写像される名前をコード化する異なったRTPを異なったデータ信号速度に与えます。 G729Dは6.4kbit/sコード化モード(チャネル容量の瞬間の減少のためのG.729 Annex D)を示します、G729Eが11.8kbit/sモード(例えば、さまざまな狭周波数帯入力信号、音楽、およびバックグラウンドノイズに伴う向上した性能のためのG.729 Annex E)を示しますが。 別館Eには、2つのオペレーティング・モードが後方に適応型であって、フォワード適応型の状態であります(各フレーム(最初の八重奏の最も重要な2ビット)で最初の2ビットによって合図されます)。
The voice activity detector (VAD) and comfort noise generator (CNG) algorithm specified in Annex B of G.729 may be used with Annex D and Annex E frames in addition to G.729 and G.729 Annex A frames. The algorithm details for the operation of Annexes D and E with the Annex B CNG are specified in G.729 Annexes F and G. Note that Annexes F and G do not introduce any new encodings. Receivers MUST accept comfort noise frames if restriction of their use has not been signaled. The MIME registrations for G729D and G729E in RFC 3555 [7] specify a parameter that MAY be used with MIME or SDP to restrict the use of comfort noise frames.
G.729のAnnex Bで指定された音声活動探知器(VAD)と安らぎ雑音発生器(CNG)アルゴリズムはG.729に加えたAnnex DとAnnex EフレームとG.729 Annex Aフレームと共に使用されるかもしれません。 Annex B CNGとのAnnexes DとEの操作のためのアルゴリズムの詳細はG.729 Annexes Fで指定されます、そして、Annexes FとGがするG.Noteは少しの新しいencodingsも導入しません。 彼らの使用の制限が合図されていないなら、受信機は安らぎ雑音フレームを受け入れなければなりません。 RFC3555[7]のG729DとG729EのためのMIME登録証明書は安らぎ雑音フレームの使用を制限するのにMIMEかSDPと共に使用されるかもしれないパラメタを指定します。
For G729D, an RTP packet may consist of zero or more G.729 Annex D frames, followed by zero or one G.729 Annex B frame. Similarly, for G729E, an RTP packet may consist of zero or more G.729 Annex E frames, followed by zero or one G.729 Annex B frame. The presence of a comfort noise frame can be deduced from the length of the RTP payload.
G729Dに関しては、RTPパケットはG.729 Annex Dが縁どるゼロか以上から成るかもしれません、ゼロか1つのG.729 Annex Bフレームによって続かれて。 同様に、G729Eに関して、RTPパケットはG.729 Annex Eが縁どるゼロか以上から成るかもしれません、ゼロか1つのG.729 Annex Bフレームによって続かれて。 RTPペイロードの長さから安らぎ雑音フレームの存在を推論できます。
A single RTP packet must contain frames of only one data rate, optionally followed by one comfort noise frame. The data rate may be changed from packet to packet by changing the payload type number. G.729 Annexes D, E and H describe what the encoding and decoding algorithms must do to accommodate a change in data rate.
単一のRTPパケットは1個の安らぎ雑音フレームが任意に支えた1つのデータ信号速度だけのフレームを含まなければなりません。 パケットによってデータ信号速度は、ペイロード形式数を変えることによって、変わるかもしれません。 G.729別館D、E、およびHはコード化とアルゴリズムを解読するとデータ信号速度における変化を収容するためにしなければならないことについて説明します。
For G729D, the bits of a G.729 Annex D frame are formatted as shown below in Fig. 6 (cf. Table D.1/G.729). The frame length is 64 bits.
G729Dに関しては、G.729 Annex Dフレームのビットは図6で以下に示すようにフォーマットされます。(Cf。 テーブルD.1/G.729). フレームの長さは64ビットです。
Schulzrinne & Casner Standards Track [Page 22] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[22ページ]RFCプロフィール2003年7月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| L1 | L2 | L3 | P1 | C1 |
|0| | | | | |
| |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7|0 1 2 3 4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C1 |S1 | GA1 | GB1 | P2 | C2 |S2 | GA2 | GB2 |
| | | | | | | | | |
|6 7 8|0 1|0 1 2|0 1 2|0 1 2 3|0 1 2 3 4 5 6 7 8|0 1|0 1 2|0 1 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| L1| L2| L3| P1| C1| |0| | | | | | | |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7|0 1 2 3 4 5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C1|S1| GA1| GB1| P2| C2|S2| GA2| GB2| | | | | | | | | | | |6 7 8|0 1|0 1 2|0 1 2|0 1 2 3|0 1 2 3 4 5 6 7 8|0 1|0 1 2|0 1 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: G.729 Annex D bit packing
図6: G.729はD噛み付いているパッキングを付加します。
The net bit rate for the G.729 Annex E algorithm is 11.8 kbit/s and a total of 118 bits are used. Two bits are appended as "don't care" bits to complete an integer number of octets for the frame. For G729E, the bits of a data frame are formatted as shown in the next two diagrams (cf. Table E.1/G.729). The fields for the G729E forward adaptive mode are packed as shown in Fig. 7.
G.729 Annex Eアルゴリズムのためのネットのビット伝送速度は11.8kbit/sです、そして、合計118ビットは使用されています。 フレームのための八重奏の整数を完成するために「気にかけないでください」というビットとして2ビットを追加します。 G729Eに関しては、データフレームのビットは次の2個のダイヤグラムで示されるようにフォーマットされます。(Cf。 テーブルE.1/G.729). G729Eの前進の適応型のモードのための分野は図7に示されるように人でいっぱいです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0|L| L1 | L2 | L3 | P1 |P| C0_1|
| |0| | | | |0| |
| | |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7| |0 1 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C1_1 | C2_1 | C3_1 | C4_1 |
| | | | | |
|3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GA1 | GB1 | P2 | C0_2 | C1_2 | C2_2 |
| | | | | | |
|0 1 2|0 1 2 3|0 1 2 3 4|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C3_2 | C4_2 | GA2 | GB2 |DC |
| | | | | | |
|6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2|0 1 2 3|0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0|L| L1| L2| L3| P1|P| C0_1| | |0| | | | |0| | | | |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7| |0 1 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | C1_1| C2_1| C3_1| C4_1| | | | | | | |3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GA1| GB1| P2| C0_2| C1_2| C2_2| | | | | | | | |0 1 2|0 1 2 3|0 1 2 3 4|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | C3_2| C4_2| GA2| GB2|DC| | | | | | | | |6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2|0 1 2 3|0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: G.729 Annex E (forward adaptive mode) bit packing
図7: G.729別館E(前進の適応型のモード)ビットパッキング
The fields for the G729E backward adaptive mode are packed as shown in Fig. 8.
G729Eの後方の適応型のモードのための分野は図8に示されるように人でいっぱいです。
Schulzrinne & Casner Standards Track [Page 23] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[23ページ]RFCプロフィール2003年7月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1| P1 |P| C0_1 | C1_1 |
| | |0| 1 1 1| |
| |0 1 2 3 4 5 6 7|0|0 1 2 3 4 5 6 7 8 9 0 1 2|0 1 2 3 4 5 6 7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C2_1 | C3_1 | C4_1 |GA1 | GB1 |P2 |
| | | | | | | |
|8 9|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2|0 1 2 3|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C0_2 | C1_2 | C2_2 |
| | 1 1 1| | |
|2 3 4|0 1 2 3 4 5 6 7 8 9 0 1 2|0 1 2 3 4 5 6 7 8 9|0 1 2 3 4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C3_2 | C4_2 | GA2 | GB2 |DC |
| | | | | | |
|6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2|0 1 2 3|0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1| P1|P| C0_1| C1_1| | | |0| 1 1 1| | | |0 1 2 3 4 5 6 7|0|0 1 2 3 4 5 6 7 8 9 0 1 2|0 1 2 3 4 5 6 7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | C2_1| C3_1| C4_1|GA1| GB1|P2| | | | | | | | | |8 9|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2|0 1 2 3|0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | C0_2| C1_2| C2_2| | | 1 1 1| | | |2 3 4|0 1 2 3 4 5 6 7 8 9 0 1 2|0 1 2 3 4 5 6 7 8 9|0 1 2 3 4 5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | C3_2| C4_2| GA2| GB2|DC| | | | | | | | |6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2|0 1 2 3|0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: G.729 Annex E (backward adaptive mode) bit packing
エイト環: G.729別館E(後方の適応型のモード)ビットパッキング
4.5.8 GSM
4.5.8 GSM
GSM (Group Speciale Mobile) denotes the European GSM 06.10 standard for full-rate speech transcoding, ETS 300 961, which is based on RPE/LTP (residual pulse excitation/long term prediction) coding at a rate of 13 kb/s [11,12,13]. The text of the standard can be obtained from:
GSM(モバイルでSpecialeを分類する)は全額料金スピーチコード変換、ETS300 961のヨーロッパのGSM06.10規格を指示します。(ETSは、13の速度でkb/s[11、12、13]をコード化しながら、RPE/LTP(残りのパルス励起/長期予測)に基づいています)。 以下から規格のテキストを得ることができます。
ETSI (European Telecommunications Standards Institute) ETSI Secretariat: B.P.152 F-06561 Valbonne Cedex France Phone: +33 92 94 42 00 Fax: +33 93 65 47 16
ETSI(規格が設けるヨーロッパのテレコミュニケーション)ETSI事務局: B.P.152F-06561Valbonne Cedexフランス電話: +33 92 94 42 00、Fax: +33 93 65 47 16
Blocks of 160 audio samples are compressed into 33 octets, for an effective data rate of 13,200 b/s.
160個のオーディオのサンプルのブロックは1万3200b/sの有効なデータ信号速度のために33の八重奏に圧縮されます。
4.5.8.1 General Packaging Issues
4.5.8.1 一般パッケージ問題
The GSM standard (ETS 300 961) specifies the bit stream produced by the codec, but does not specify how these bits should be packed for transmission. The packetization specified here has subsequently been adopted in ETSI Technical Specification TS 101 318. Some software implementations of the GSM codec use a different packing than that specified here.
GSM規格(ETS300 961)は、コーデックによって作成されたビットストリームを指定しますが、これらのビットがトランスミッションのためにどう梱包されるべきであるかは指定しません。 ここで指定されたpacketizationは次に、ETSI仕様書TS101 318に採用されました。 GSMコーデックのいくつかのソフトウェア実行がここで指定されたそれと異なったパッキングを使用します。
Schulzrinne & Casner Standards Track [Page 24] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[24ページ]RFCプロフィール2003年7月
field field name bits field field name bits
________________________________________________
1 LARc[0] 6 39 xmc[22] 3
2 LARc[1] 6 40 xmc[23] 3
3 LARc[2] 5 41 xmc[24] 3
4 LARc[3] 5 42 xmc[25] 3
5 LARc[4] 4 43 Nc[2] 7
6 LARc[5] 4 44 bc[2] 2
7 LARc[6] 3 45 Mc[2] 2
8 LARc[7] 3 46 xmaxc[2] 6
9 Nc[0] 7 47 xmc[26] 3
10 bc[0] 2 48 xmc[27] 3
11 Mc[0] 2 49 xmc[28] 3
12 xmaxc[0] 6 50 xmc[29] 3
13 xmc[0] 3 51 xmc[30] 3
14 xmc[1] 3 52 xmc[31] 3
15 xmc[2] 3 53 xmc[32] 3
16 xmc[3] 3 54 xmc[33] 3
17 xmc[4] 3 55 xmc[34] 3
18 xmc[5] 3 56 xmc[35] 3
19 xmc[6] 3 57 xmc[36] 3
20 xmc[7] 3 58 xmc[37] 3
21 xmc[8] 3 59 xmc[38] 3
22 xmc[9] 3 60 Nc[3] 7
23 xmc[10] 3 61 bc[3] 2
24 xmc[11] 3 62 Mc[3] 2
25 xmc[12] 3 63 xmaxc[3] 6
26 Nc[1] 7 64 xmc[39] 3
27 bc[1] 2 65 xmc[40] 3
28 Mc[1] 2 66 xmc[41] 3
29 xmaxc[1] 6 67 xmc[42] 3
30 xmc[13] 3 68 xmc[43] 3
31 xmc[14] 3 69 xmc[44] 3
32 xmc[15] 3 70 xmc[45] 3
33 xmc[16] 3 71 xmc[46] 3
34 xmc[17] 3 72 xmc[47] 3
35 xmc[18] 3 73 xmc[48] 3
36 xmc[19] 3 74 xmc[49] 3
37 xmc[20] 3 75 xmc[50] 3
38 xmc[21] 3 76 xmc[51] 3
分野フィールド名ビットはフィールド名ビットをさばきます。________________________________________________ 1LARc0 6 39のxmc22 3 2、LARc1 6 40xmc23 3 3LARc2 5 41xmc24 3 4LARc3 5 42xmc25 3 5LARc4 4 43Nc2 7 6 LARc5 4 44bc2 2 7 LARc6 3 45Mc2 2 8 LARc7 3 46xmaxc2 6 9 Nc0 7 47xmc26 3 10bc0 2 48xmc27 3、11Mc0 2 49xmc28 3 12xmaxc0 6 50xmc29 3 13xmc0 3 51xmc30 3 14xmc1 3 52xmc31 3 15xmc2 3 53xmc32 3 16xmc3 3 54xmc33、3 17xmc4 3 55xmc34 3 18xmc5 3 56xmc35 3 19xmc6 3 57xmc36 3 20xmc7; 3、58xmc37 3 21xmc8 3 59xmc38 3 22xmc9 3 60Nc3 7 23xmc10 3 61bc3 2 24xmc11 3 62Mc3 2 25xmc12 3 63xmaxc3 6、26Nc1 7 64xmc39 3 27bc1 2 65xmc40 3 28Mc1 2 66xmc41 3 29xmaxc1 6 67xmc42 3 30xmc13、3 68xmc43 3 31xmc14 3 69xmc44 3 32xmc15 3 70xmc45 3 33xmc16 3 71xmc46 3 34xmc17 3 72、xmc47 3 35xmc18 3 73xmc48 3 36xmc19 3 74xmc49 3 37xmc20 3 75xmc50 3 38xmc21 3 76xmc51 3
Table 2: Ordering of GSM variables
テーブル2: GSM変数の注文
Schulzrinne & Casner Standards Track [Page 25] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[25ページ]RFCプロフィール2003年7月
Octet Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7
_____________________________________________________________________
0 1 1 0 1 LARc0.0 LARc0.1 LARc0.2 LARc0.3
1 LARc0.4 LARc0.5 LARc1.0 LARc1.1 LARc1.2 LARc1.3 LARc1.4 LARc1.5
2 LARc2.0 LARc2.1 LARc2.2 LARc2.3 LARc2.4 LARc3.0 LARc3.1 LARc3.2
3 LARc3.3 LARc3.4 LARc4.0 LARc4.1 LARc4.2 LARc4.3 LARc5.0 LARc5.1
4 LARc5.2 LARc5.3 LARc6.0 LARc6.1 LARc6.2 LARc7.0 LARc7.1 LARc7.2
5 Nc0.0 Nc0.1 Nc0.2 Nc0.3 Nc0.4 Nc0.5 Nc0.6 bc0.0
6 bc0.1 Mc0.0 Mc0.1 xmaxc00 xmaxc01 xmaxc02 xmaxc03 xmaxc04
7 xmaxc05 xmc0.0 xmc0.1 xmc0.2 xmc1.0 xmc1.1 xmc1.2 xmc2.0
8 xmc2.1 xmc2.2 xmc3.0 xmc3.1 xmc3.2 xmc4.0 xmc4.1 xmc4.2
9 xmc5.0 xmc5.1 xmc5.2 xmc6.0 xmc6.1 xmc6.2 xmc7.0 xmc7.1
10 xmc7.2 xmc8.0 xmc8.1 xmc8.2 xmc9.0 xmc9.1 xmc9.2 xmc10.0
11 xmc10.1 xmc10.2 xmc11.0 xmc11.1 xmc11.2 xmc12.0 xmc12.1 xcm12.2
12 Nc1.0 Nc1.1 Nc1.2 Nc1.3 Nc1.4 Nc1.5 Nc1.6 bc1.0
13 bc1.1 Mc1.0 Mc1.1 xmaxc10 xmaxc11 xmaxc12 xmaxc13 xmaxc14
14 xmax15 xmc13.0 xmc13.1 xmc13.2 xmc14.0 xmc14.1 xmc14.2 xmc15.0
15 xmc15.1 xmc15.2 xmc16.0 xmc16.1 xmc16.2 xmc17.0 xmc17.1 xmc17.2
16 xmc18.0 xmc18.1 xmc18.2 xmc19.0 xmc19.1 xmc19.2 xmc20.0 xmc20.1
17 xmc20.2 xmc21.0 xmc21.1 xmc21.2 xmc22.0 xmc22.1 xmc22.2 xmc23.0
18 xmc23.1 xmc23.2 xmc24.0 xmc24.1 xmc24.2 xmc25.0 xmc25.1 xmc25.2
19 Nc2.0 Nc2.1 Nc2.2 Nc2.3 Nc2.4 Nc2.5 Nc2.6 bc2.0
20 bc2.1 Mc2.0 Mc2.1 xmaxc20 xmaxc21 xmaxc22 xmaxc23 xmaxc24
21 xmaxc25 xmc26.0 xmc26.1 xmc26.2 xmc27.0 xmc27.1 xmc27.2 xmc28.0
22 xmc28.1 xmc28.2 xmc29.0 xmc29.1 xmc29.2 xmc30.0 xmc30.1 xmc30.2
23 xmc31.0 xmc31.1 xmc31.2 xmc32.0 xmc32.1 xmc32.2 xmc33.0 xmc33.1
24 xmc33.2 xmc34.0 xmc34.1 xmc34.2 xmc35.0 xmc35.1 xmc35.2 xmc36.0
25 Xmc36.1 xmc36.2 xmc37.0 xmc37.1 xmc37.2 xmc38.0 xmc38.1 xmc38.2
26 Nc3.0 Nc3.1 Nc3.2 Nc3.3 Nc3.4 Nc3.5 Nc3.6 bc3.0
27 bc3.1 Mc3.0 Mc3.1 xmaxc30 xmaxc31 xmaxc32 xmaxc33 xmaxc34
28 xmaxc35 xmc39.0 xmc39.1 xmc39.2 xmc40.0 xmc40.1 xmc40.2 xmc41.0
29 xmc41.1 xmc41.2 xmc42.0 xmc42.1 xmc42.2 xmc43.0 xmc43.1 xmc43.2
30 xmc44.0 xmc44.1 xmc44.2 xmc45.0 xmc45.1 xmc45.2 xmc46.0 xmc46.1
31 xmc46.2 xmc47.0 xmc47.1 xmc47.2 xmc48.0 xmc48.1 xmc48.2 xmc49.0
32 xmc49.1 xmc49.2 xmc50.0 xmc50.1 xmc50.2 xmc51.0 xmc51.1 xmc51.2
八重奏ビット0にビット1にビット2にビット3にビット4にビット5に噛み付いている6ビット7_____________________________________________________________________ 0 1 1 0 1LARc0.0 LARc0.1 LARc0.2 LARc0.3 1LARc0.4 LARc0.5 LARc1.0 LARc1.1 LARc1.2 LARc1.3 LARc1.4 LARc1.5 2LARc2.0 LARc2.1 LARc2.2 LARc2.3 LARc2.4 LARc3.0 LARc3.1 LARc3.2 3LARc3.3 LARc3.4 LARc4.0 LARc4.1 LARc4.2 LARc4.3 LARc5.0 LARc5.1 4LARc5.2 LARc5.3 LARc6.0 LARc6.1 LARc6.2 LARc7.0 LARc7.1 LARc7.2 5Nc0.0 Nc0.1 Nc0.2 Nc0.3 Nc0.4 Nc0.5 Nc0.6 bc0.0 6bc0.1 Mc0.0 Mc0.1 xmaxc00 xmaxc01 xmaxc02 xmaxc03 xmaxc04 7xmaxc05 xmc0.0 xmc0.1 xmc0.2 xmc1.0 xmc1.1 xmc1.2 xmc2.0 8xmc2.1 xmc2.2 xmc3.0 xmc3.1 xmc3; 2 xmc4.0 xmc4.1 xmc4.2 9xmc5.0 xmc5.1 xmc5.2 xmc6.0 xmc6.1 xmc6.2 xmc7.0 xmc7.1 10xmc7.2 xmc8.0 xmc8.1 xmc8.2 xmc9.0 xmc9.1xmc9.2 xmc10.0 11 xmc10.1 xmc10.2 xmc11.0 xmc11.1xmc11.2 xmc12.0 xmc12.1 xcm12.2 12 Nc1.0 Nc1.1 Nc1.2 Nc1.3 Nc1.4 Nc1.5 Nc1.6 bc1; 0 13bc1.1 Mc1.0 Mc1.1 xmaxc10 xmaxc11 xmaxc12 xmaxc13 xmaxc14 14 xmax15 xmc13.0 xmc13.1 xmc13.2 xmc14.0 xmc14.1 xmc14.2 xmc15.0 15 xmc15.1 xmc15.2 xmc16.0 xmc16.1 xmc16.2 xmc17.0 xmc17.1 xmc17.2 16 xmc18.0 xmc18.1 xmc18.2 xmc19.0 xmc19.1 xmc19.2 xmc20.0 xmc20.1 17 xmc20.2 xmc21.0 xmc21.1 xmc21.2 xmc22.0 xmc22.1xmc22.2 xmc23.0 18 xmc23.1 xmc23.2 xmc24.0 xmc24.1xmc24.2 xmc25.0 xmc25.1 xmc25.2 19 Nc2.0 Nc2.1 Nc2.2 Nc2.3 Nc2.4 Nc2.5 Nc2.6 bc2.0 20bc2.1 Mc2.0 Mc2.1 xmaxc20 xmaxc21xmaxc22 xmaxc23 xmaxc24 21 xmaxc25 xmc26.0 xmc26.1 xmc26.2 xmc27.0 xmc27.1 xmc27.2 xmc28.0 22 xmc28.1 xmc28.2 xmc29.0 xmc29.1 xmc29.2 xmc30.0 xmc30.1 xmc30.2 23xmc31.0 xmc31.1 xmc31.2 xmc32.0 xmc32.1xmc32.2 xmc33.0 xmc33.1 24 xmc33.2 xmc34.0 xmc34.1 xmc34.2 xmc35.0 xmc35.1 xmc35; 2 xmc36.0 25 Xmc36.1 xmc36.2 xmc37.0 xmc37.1 xmc37.2 xmc38.0 xmc38.1 xmc38.2 26 Nc3.0 Nc3.1 Nc3.2 Nc3.3 Nc3.4 Nc3.5 Nc3.6 bc3.0 27bc3.1 Mc3.0 Mc3.1 xmaxc30 xmaxc31 xmaxc32 xmaxc33 xmaxc34 28 xmaxc35 xmc39.0 xmc39.1 xmc39.2 xmc40.0 xmc40.1 xmc40.2 xmc41; 0 29 xmc41.1 xmc41.2 xmc42.0 xmc42.1 xmc42.2 xmc43.0 xmc43.1 xmc43.2 30 xmc44.0 xmc44.1 xmc44.2 xmc45.0 xmc45.1 xmc45.2 xmc46.0 xmc46.1 31 xmc46.2 xmc47.0 xmc47.1 xmc47.2 xmc48.0 xmc48.1 xmc48.2xmc49.0 32 xmc49.1 xmc49.2 xmc50.0 xmc50.1 xmc50.2 xmc51.0 xmc51。1 xmc51.2
Table 3: GSM payload format
テーブル3: GSMペイロード形式
In the GSM packing used by RTP, the bits SHALL be packed beginning from the most significant bit. Every 160 sample GSM frame is coded into one 33 octet (264 bit) buffer. Every such buffer begins with a 4 bit signature (0xD), followed by the MSB encoding of the fields of the frame. The first octet thus contains 1101 in the 4 most significant bits (0-3) and the 4 most significant bits of F1 (0-3) in the 4 least significant bits (4-7). The second octet contains the 2 least significant bits of F1 in bits 0-1, and F2 in bits 2-7, and so on. The order of the fields in the frame is described in Table 2.
最も重要なビットからのRTP、ビットSHALLに従ってパッキングが使用したGSMでは、詰まっている始めになってください。 あらゆる160サンプルGSMフレームが1つ33の八重奏(264ビット)バッファの中にコード化されます。 そのようなあらゆるバッファがフレームの分野のMSBコード化があとに続いた4ビットの署名(0xD)で始まります。 その結果、最初の八重奏は4つの最下位ビット(4-7)におけるF1(0-3)の4つの最上位ビット(0-3)と4つの最上位ビットに1101を含んでいます。 2番目の八重奏はビット0-1、およびF2にビット2-7、などにF1の2つの最下位ビットを含んでいます。 Table2でフレームでの分野の注文について説明します。
Schulzrinne & Casner Standards Track [Page 26] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[26ページ]RFCプロフィール2003年7月
4.5.8.2 GSM Variable Names and Numbers
4.5.8.2 GSM変数名と数
In the RTP encoding we have the bit pattern described in Table 3, where F.i signifies the ith bit of the field F, bit 0 is the most significant bit, and the bits of every octet are numbered from 0 to 7 from most to least significant.
RTPコード化では、私たちはTable3で説明されたビット・パターンを重要にします。そこでは、F.私が分野Fについて噛み付かれたithを意味して、ビット0は最も重要なビットであり、あらゆる八重奏のビットは大部分から最少まで0〜7まで付番されます。
4.5.9 GSM-EFR
4.5.9 GSM-EFR
GSM-EFR denotes GSM 06.60 enhanced full rate speech transcoding, specified in ETS 300 726 which is available from ETSI at the address given in Section 4.5.8. This codec has a frame length of 244 bits. For transmission in RTP, each codec frame is packed into a 31 octet (248 bit) buffer beginning with a 4-bit signature 0xC in a manner similar to that specified here for the original GSM 06.10 codec. The packing is specified in ETSI Technical Specification TS 101 318.
GSM-EFRはGSM06.60エンハンストフルレートスピーチコード変換を指示します、セクション4.5.8で与えられたアドレスでETSIから利用可能なETS300 726で指定されて。 このコーデックには、244ビットのフレームの長さがあります。 RTPのトランスミッションにおいて、それぞれのコーデックフレームはそれと同様の方法による0xCがここでオリジナルのGSM06.10コーデックに指定した4ビットの署名で始まる31八重奏(248ビット)バッファに詰め込まれます。パッキングはETSI仕様書TS101 318で指定されます。
4.5.10 L8
4.5.10 L8
L8 denotes linear audio data samples, using 8-bits of precision with an offset of 128, that is, the most negative signal is encoded as zero.
L8は直線的なオーディオデータのサンプルを指示します、128のオフセットと共に精度の8ビットを使用して、すなわち、最も否定的な信号がゼロとしてコード化されます。
4.5.11 L16
4.5.11 L16
L16 denotes uncompressed audio data samples, using 16-bit signed representation with 65,535 equally divided steps between minimum and maximum signal level, ranging from -32,768 to 32,767. The value is represented in two's complement notation and transmitted in network byte order (most significant byte first).
L16は解凍されたオーディオデータのサンプルを指示します、最小の、そして、最大の信号レベルの間の等しく分割された6万5535ステップで16ビットのサインされた表現を使用して、-32,768〜3万2767まで及んで。 値が2の補数記法で表されて、ネットワークバイトオーダーで送られる、(最も重要なバイト、1番目)
The MIME registration for L16 in RFC 3555 [7] specifies parameters that MAY be used with MIME or SDP to indicate that analog pre- emphasis was applied to the signal before quantization or to indicate that a multiple-channel audio stream follows a different channel ordering convention than is specified in Section 4.1.
RFC3555[7]のL16のためのMIME登録はアナログのプレ強調が量子化の前に信号に適用されたのを示すか、または複数のチャンネルオーディオストリームがコンベンションを注文しているセクション4.1で指定されるのと異なったチャンネルに従うのを示すのにMIMEかSDPと共に使用されるかもしれないパラメタを指定します。
4.5.12 LPC
4.5.12 LPC
LPC designates an experimental linear predictive encoding contributed by Ron Frederick, which is based on an implementation written by Ron Zuckerman posted to the Usenet group comp.dsp on June 26, 1992. The codec generates 14 octets for every frame. The framesize is set to 20 ms, resulting in a bit rate of 5,600 b/s.
LPCは1992年6月26日にUsenetグループcomp.dspに掲示されていた状態でロンザッカーマンによって書かれた実現に基づいているロンフレディリックによって寄付された実験的な直線的な予言のコード化を指定します。 コーデックは各フレームあたり14の八重奏を発生させます。 framesizeする、5,600のしばらくレートをもたらす20msへのセットはb/sですか?
Schulzrinne & Casner Standards Track [Page 27] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[27ページ]RFCプロフィール2003年7月
4.5.13 MPA
4.5.13 MPA
MPA denotes MPEG-1 or MPEG-2 audio encapsulated as elementary streams. The encoding is defined in ISO standards ISO/IEC 11172-3 and 13818-3. The encapsulation is specified in RFC 2250 [14].
MPAがMPEG-1を指示するか、または基本であるとして要約されたMPEG-2オーディオは流れます。コード化はISO規格ISO/IECで11172-3に13818-3に定義されます。 カプセル化はRFC2250[14]で指定されます。
The encoding may be at any of three levels of complexity, called Layer I, II and III. The selected layer as well as the sampling rate and channel count are indicated in the payload. The RTP timestamp clock rate is always 90,000, independent of the sampling rate. MPEG-1 audio supports sampling rates of 32, 44.1, and 48 kHz (ISO/IEC 11172-3, section 1.1; "Scope"). MPEG-2 supports sampling rates of 16, 22.05 and 24 kHz. The number of samples per frame is fixed, but the frame size will vary with the sampling rate and bit rate.
Layer I、II、およびIIIと呼ばれる複雑さの3つのレベルのいずれにはもコード化があるかもしれません。 標本抽出率とチャンネルが数えるとき、また、選択された層はペイロードで示されます。 いつもRTPタイムスタンプクロックレートは標本抽出率の如何にかかわらず9万です。 MPEG-1オーディオは32、44.1、および48kHz(ISO/IEC11172-3、1.1;「範囲」というセクション)の標本抽出率を支持します。 MPEG-2は16、22.05、および24kHzの標本抽出率を支持します。 1フレームあたりのサンプルの数は固定されていますが、標本抽出率とビット伝送速度に従って、フレーム・サイズは異なるでしょう。
The MIME registration for MPA in RFC 3555 [7] specifies parameters that MAY be used with MIME or SDP to restrict the selection of layer, channel count, sampling rate, and bit rate.
RFC3555[7]のMPAのためのMIME登録は層、チャンネルカウント、標本抽出率、およびビット伝送速度の選択を制限するのにMIMEかSDPと共に使用されるかもしれないパラメタを指定します。
4.5.14 PCMA and PCMU
4.5.14 PCMAとPCMU
PCMA and PCMU are specified in ITU-T Recommendation G.711. Audio data is encoded as eight bits per sample, after logarithmic scaling. PCMU denotes mu-law scaling, PCMA A-law scaling. A detailed description is given by Jayant and Noll [15]. Each G.711 octet SHALL be octet-aligned in an RTP packet. The sign bit of each G.711 octet SHALL correspond to the most significant bit of the octet in the RTP packet (i.e., assuming the G.711 samples are handled as octets on the host machine, the sign bit SHALL be the most significant bit of the octet as defined by the host machine format). The 56 kb/s and 48 kb/s modes of G.711 are not applicable to RTP, since PCMA and PCMU MUST always be transmitted as 8-bit samples.
PCMAとPCMUはITU-T Recommendation G.711で指定されます。 オーディオデータは対数のスケーリングの後に1サンプルあたり8ビットとしてコード化されます。 PCMUはPCMA A-法が比例して、比例するμ法を指示します。 詳述はJayantとノル[15]によって与えられています。 それぞれのG.711八重奏SHALLはRTPパケットで八重奏によって並べられます。 それぞれのG.711八重奏SHALLに関する符号ビットは八重奏のRTPパケットで最も重要なビットに対応しています。(すなわち、G.711のサンプルを仮定するのが八重奏としてホスト・マシンの上で扱われる、符号ビットSHALL、ホスト・マシン形式によって定義される八重奏の最も重要なビット) G.711の56kb/sと48のkb/sモードはRTPに適切でなく、PCMAとPCMU MUST以来、8ビットのサンプルとしていつも伝えられてください。
See Section 4.1 regarding silence suppression.
沈黙抑圧に関してセクション4.1を見てください。
4.5.15 QCELP
4.5.15 QCELP
The Electronic Industries Association (EIA) & Telecommunications Industry Association (TIA) standard IS-733, "TR45: High Rate Speech Service Option for Wideband Spread Spectrum Communications Systems", defines the QCELP audio compression algorithm for use in wireless CDMA applications. The QCELP CODEC compresses each 20 milliseconds of 8,000 Hz, 16-bit sampled input speech into one of four different size output frames: Rate 1 (266 bits), Rate 1/2 (124 bits), Rate 1/4 (54 bits) or Rate 1/8 (20 bits). For typical speech patterns, this results in an average output of 6.8 kb/s for normal mode and 4.7 kb/s for reduced rate mode. The packetization of the QCELP audio codec is described in [16].
電子工業会(EIA)と電気通信産業連盟(TIA)、標準、-733である、「TR45:」 「Wideband Spread Spectrum Communications Systemsのための高いRate Speech Service Option」は無線のCDMAアプリケーションにおける使用のためのQCELP音声圧縮アルゴリズムを定義します。 QCELP CODECは8,000Hzの各20人のミリセカンドを圧縮します、4個の異なったサイズ出力フレームの1つへの16ビットの抽出された入力スピーチ: 1(266ビット)、Rate1/2(124ビット)、Rate1/4(54ビット)またはRate1/8(20ビット)を評定してください。 典型的なスピーチパターンのために、これは正規モードのための6.8kb/sと割引料金モードのための4.7kb/sの平均した出力をもたらします。 QCELPオーディオコーデックのpacketizationは[16]で説明されます。
Schulzrinne & Casner Standards Track [Page 28] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[28ページ]RFCプロフィール2003年7月
4.5.16 RED
4.5.16 赤
The redundant audio payload format "RED" is specified by RFC 2198 [17]. It defines a means by which multiple redundant copies of an audio packet may be transmitted in a single RTP stream. Each packet in such a stream contains, in addition to the audio data for that packetization interval, a (more heavily compressed) copy of the data from a previous packetization interval. This allows an approximation of the data from lost packets to be recovered upon decoding of a subsequent packet, giving much improved sound quality when compared with silence substitution for lost packets.
余分なオーディオペイロード形式「赤」はRFC2198[17]によって指定されます。 それはオーディオパケットの複数の余分なコピーがただ一つのRTPストリームで伝えられるかもしれない手段を定義します。 そのようなストリームにおける各パケットはそのpacketization間隔の間のオーディオデータに加えて前のpacketization間隔からのデータの(大いにより圧縮されています)のコピーを含んでいます。 これで、その後のパケットを解読するとき無くなっているパケットからのデータの近似は回復します、無くなっているパケットへの沈黙代替と比べると多くの改良された音の品質を与えて。
4.5.17 VDVI
4.5.17 VDVI
VDVI is a variable-rate version of DVI4, yielding speech bit rates of between 10 and 25 kb/s. It is specified for single-channel operation only. Samples are packed into octets starting at the most- significant bit. The last octet is padded with 1 bits if the last sample does not fill the last octet. This padding is distinct from the valid codewords. The receiver needs to detect the padding because there is no explicit count of samples in the packet.
VDVIはDVI4の変動金利バージョンであり、もたらすのは10〜25kb/sのスピーチビット伝送速度です。 それは単独のチャンネル操作だけに指定されます。 サンプルは噛み付かれて、大部分で重要な状態で始まる八重奏に詰め込まれます。 最後のサンプルが最後の八重奏をいっぱいにしていないなら、最後の八重奏は1ビットで水増しされます。 この詰め物は有効な符号語と異なっています。 受信機は、サンプルをどんな明白なカウントもパケットにないので詰め物を検出する必要があります。
It uses the following encoding:
それは以下のコード化を使用します:
DVI4 codeword VDVI bit pattern
_______________________________
0 00
1 010
2 1100
3 11100
4 111100
5 1111100
6 11111100
7 11111110
8 10
9 011
10 1101
11 11101
12 111101
13 1111101
14 11111101
15 11111111
DVI4符号語VDVIビット・パターン_______________________________ 0 00 1 010 2 1100 3 11100 4 111100 5 1111100 6 11111100 7 11111110 8 10 9 011 10 1101 11 11101 12 111101 13 1111101 14 11111101 15 11111111
Schulzrinne & Casner Standards Track [Page 29] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[29ページ]RFCプロフィール2003年7月
5. Video
5. ビデオ
The following sections describe the video encodings that are defined in this memo and give their abbreviated names used for identification. These video encodings and their payload types are listed in Table 5.
以下のセクションは、このメモで定義されるビデオencodingsについて説明して、識別に使用される彼らの略称を与えます。 これらのビデオencodingsと彼らのペイロードタイプはTable5に記載されています。
All of these video encodings use an RTP timestamp frequency of 90,000 Hz, the same as the MPEG presentation time stamp frequency. This frequency yields exact integer timestamp increments for the typical 24 (HDTV), 25 (PAL), and 29.97 (NTSC) and 30 Hz (HDTV) frame rates and 50, 59.94 and 60 Hz field rates. While 90 kHz is the RECOMMENDED rate for future video encodings used within this profile, other rates MAY be used. However, it is not sufficient to use the video frame rate (typically between 15 and 30 Hz) because that does not provide adequate resolution for typical synchronization requirements when calculating the RTP timestamp corresponding to the NTP timestamp in an RTCP SR packet. The timestamp resolution MUST also be sufficient for the jitter estimate contained in the receiver reports.
これらのビデオencodingsのすべてが9万HzのRTPタイムスタンプ頻度を使用します、MPEGプレゼンテーションタイムスタンプ頻度と同じです。 この頻度は25の典型的な24(HDTV)のための正確な整数タイムスタンプ増分と(PAL)と(NTSC)と30Hz(HDTV)の29.97のフレームレートと50、59.94、および60Hzの分野レートをもたらします。 90kHzはRECOMMENDEDですが、このプロフィールの中に使用された将来のビデオencodingsのために評価してください、そして、他のレートは使用されてもよいです。 しかしながら、それは、RTCP SRパケットでNTPタイムスタンプに対応するRTPタイムスタンプについて計算するとき、それが典型的な同期要件のための適切な解決を提供しないので、ビデオフレームレート(通常15〜30Hz)を使用するために十分ではありません。 また、タイムスタンプ解決も受信機レポートに含まれたジター見積りに十分であるに違いありません。
For most of these video encodings, the RTP timestamp encodes the sampling instant of the video image contained in the RTP data packet. If a video image occupies more than one packet, the timestamp is the same on all of those packets. Packets from different video images are distinguished by their different timestamps.
これらのビデオencodingsの大部分に関しては、RTPタイムスタンプはRTPデータ・パケットに含まれたビデオ画像の標本抽出の瞬間をコード化します。 ビデオ画像が1つ以上のパケットを占領するなら、タイムスタンプはそれらのパケットのすべてで同じです。 異なったビデオ画像からのパケットはそれらの異なったタイムスタンプによって区別されます。
Most of these video encodings also specify that the marker bit of the RTP header SHOULD be set to one in the last packet of a video frame and otherwise set to zero. Thus, it is not necessary to wait for a following packet with a different timestamp to detect that a new frame should be displayed.
また、これらのビデオencodingsの大部分は、RTPヘッダーSHOULDのマーカービットがビデオフレームの最後のパケットの1つに設定されて、別の方法でゼロに設定されると指定します。 したがって、検出する異なったタイムスタンプで次のパケットを待つために、新しいフレームを表示するのは必要ではありません。
5.1 CelB
5.1 CelB
The CELL-B encoding is a proprietary encoding proposed by Sun Microsystems. The byte stream format is described in RFC 2029 [18].
CELL-Bコード化はサン・マイクロシステムズによって提案された独占コード化です。バイト・ストリーム形式はRFC2029[18]で説明されます。
5.2 JPEG
5.2 JPEG
The encoding is specified in ISO Standards 10918-1 and 10918-2. The RTP payload format is as specified in RFC 2435 [19].
コード化はISO Standards10918-1と10918-2で指定されます。 RTPペイロード形式がRFC2435[19]で指定されるようにあります。
5.3 H261
5.3 H261
The encoding is specified in ITU-T Recommendation H.261, "Video codec for audiovisual services at p x 64 kbit/s". The packetization and RTP-specific properties are described in RFC 2032 [20].
ITU-T Recommendation H.261、「p x64kbit/sでの視聴覚のサービスのためのビデオコーデック」でコード化は指定されます。 packetizationとRTP特有の性質はRFC2032[20]で説明されます。
Schulzrinne & Casner Standards Track [Page 30] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[30ページ]RFCプロフィール2003年7月
5.4 H263
5.4 H263
The encoding is specified in the 1996 version of ITU-T Recommendation H.263, "Video coding for low bit rate communication". The packetization and RTP-specific properties are described in RFC 2190 [21]. The H263-1998 payload format is RECOMMENDED over this one for use by new implementations.
コード化は1996年のITU-T Recommendation H.263のバージョン、「少ないビット伝送速度コミュニケーションのためのビデオ符号化」で指定されます。 packetizationとRTP特有の性質はRFC2190[21]で説明されます。 H263-1998ペイロード形式は新しい実装による使用のためのこれの上のRECOMMENDEDです。
5.5 H263-1998
5.5 H263-1998
The encoding is specified in the 1998 version of ITU-T Recommendation H.263, "Video coding for low bit rate communication". The packetization and RTP-specific properties are described in RFC 2429 [22]. Because the 1998 version of H.263 is a superset of the 1996 syntax, this payload format can also be used with the 1996 version of H.263, and is RECOMMENDED for this use by new implementations. This payload format does not replace RFC 2190, which continues to be used by existing implementations, and may be required for backward compatibility in new implementations. Implementations using the new features of the 1998 version of H.263 MUST use the payload format described in RFC 2429.
コード化は1998年のITU-T Recommendation H.263のバージョン、「少ないビット伝送速度コミュニケーションのためのビデオ符号化」で指定されます。 packetizationとRTP特有の性質はRFC2429[22]で説明されます。 1998年のH.263のバージョンが1996年の構文のスーパーセットであるので、このペイロード形式は、また、1996年のH.263のバージョンと共に使用できて、新しい実装によるこの使用のためのRECOMMENDEDです。 このペイロード形式が、RFC2190を取り替えないで、新しい実装における後方の互換性に必要であるかもしれません。(RFCは既存の実装によって使用され続けています)。 1998年のH.263 MUSTのバージョンの実装新機能利用はRFC2429で説明されたペイロード形式を使用します。
5.6 MPV
5.6 MPV
MPV designates the use of MPEG-1 and MPEG-2 video encoding elementary streams as specified in ISO Standards ISO/IEC 11172 and 13818-2, respectively. The RTP payload format is as specified in RFC 2250 [14], Section 3.
MPVはISO Standards ISO/IEC11172に13818-2にそれぞれMPEG-1とMPEG-2ビデオのコード化の使用を指定されるとしての基本のストリームに指定します。 RTPペイロード形式がRFC2250[14]、セクション3で指定されるようにあります。
The MIME registration for MPV in RFC 3555 [7] specifies a parameter that MAY be used with MIME or SDP to restrict the selection of the type of MPEG video.
RFC3555[7]のMPVのためのMIME登録はMPEGビデオのタイプの選択を制限するのにMIMEかSDPと共に使用されるかもしれないパラメタを指定します。
5.7 MP2T
5.7 MP2T
MP2T designates the use of MPEG-2 transport streams, for either audio or video. The RTP payload format is described in RFC 2250 [14], Section 2.
MP2TはオーディオかビデオのどちらかのためにMPEG-2の使用を輸送ストリームに指定します。 RTPペイロード形式はRFC2250[14]、セクション2で説明されます。
Schulzrinne & Casner Standards Track [Page 31] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[31ページ]RFCプロフィール2003年7月
5.8 nv
5.8 nv
The encoding is implemented in the program `nv', version 4, developed at Xerox PARC by Ron Frederick. Further information is available from the author:
コード化は'nv'(バージョン4)がゼロックスPARCでロンフレディリックで開発したプログラムで実装されます。 詳細は作者から利用可能です:
Ron Frederick Blue Coat Systems Inc. 650 Almanor Avenue Sunnyvale, CA 94085 United States EMail: ronf@bluecoat.com
ロンフレディリック青いコートSystems株式会社650Almanor Avenueサニーベル(カリフォルニア)94085合衆国はメールされます: ronf@bluecoat.com
6. Payload Type Definitions
6. 有効搭載量型定義
Tables 4 and 5 define this profile's static payload type values for the PT field of the RTP data header. In addition, payload type values in the range 96-127 MAY be defined dynamically through a conference control protocol, which is beyond the scope of this document. For example, a session directory could specify that for a given session, payload type 96 indicates PCMU encoding, 8,000 Hz sampling rate, 2 channels. Entries in Tables 4 and 5 with payload type "dyn" have no static payload type assigned and are only used with a dynamic payload type. Payload type 2 was assigned to G721 in RFC 1890 and to its equivalent successor G726-32 in draft versions of this specification, but its use is now deprecated and that static payload type is marked reserved due to conflicting use for the payload formats G726-32 and AAL2-G726-32 (see Section 4.5.4). Payload type 13 indicates the Comfort Noise (CN) payload format specified in RFC 3389 [9]. Payload type 19 is marked "reserved" because some draft versions of this specification assigned that number to an earlier version of the comfort noise payload format. The payload type range 72-76 is marked "reserved" so that RTCP and RTP packets can be reliably distinguished (see Section "Summary of Protocol Constants" of the RTP protocol specification).
テーブル4と5はこのプロフィールの静的なペイロードタイプ値をRTPデータヘッダーのPT分野と定義します。 さらに、範囲96-127のペイロードタイプ値は会議制御プロトコルを通してダイナミックに定義されるかもしれません。制御プロトコルがこのドキュメントの範囲にあります。 例えば、セッションディレクトリは、与えられたセッションのために、ペイロードタイプ96がPCMUコード化を示すと指定するかもしれません、8,000Hzの標本抽出率、2個のチャンネル。 ペイロードタイプ「ダイン」があるTables4と5のエントリーは、どんな静的なペイロードタイプも選任させないで、ダイナミックなペイロードタイプで使用されるだけです。 使用は現在推奨しないです、そして、有効搭載量タイプ2はRFC1890のG721と、そして、この仕様の草案バージョンの同等な後継者G726-32に選任されましたが、その静的なペイロードタイプはペイロード形式のG726-32とAAL2-G726-32の闘争使用のために予約されているとマークされます(セクション4.5.4を見てください)。 有効搭載量タイプ13は、コンフォートNoise(CN)ペイロード形式がRFC3389[9]で指定したのを示します。 この仕様のいくつかの草案バージョンが安らぎ雑音ペイロード形式の以前のバージョンにその数を割り当てたので、有効搭載量タイプ19は「予約されている」とマークされます。 ペイロードタイプ範囲72-76は、RTCPとRTPパケットを確かに区別できる(「プロトコル定数の概要」というRTPプロトコル仕様のセクションを見る)ように「予約されていること」が示されます。
The payload types currently defined in this profile are assigned to exactly one of three categories or media types: audio only, video only and those combining audio and video. The media types are marked in Tables 4 and 5 as "A", "V" and "AV", respectively. Payload types of different media types SHALL NOT be interleaved or multiplexed within a single RTP session, but multiple RTP sessions MAY be used in parallel to send multiple media types. An RTP source MAY change payload types within the same media type during a session. See the section "Multiplexing RTP Sessions" of RFC 3550 for additional explanation.
現在このプロフィールで定義されているペイロードタイプはちょうど3つのカテゴリかメディアタイプのひとりに選任されます: オーディオとビデオを結合するオーディオだけ、ビデオだけ、およびもの。 メディアタイプは「A」、「V」、および"AV"としてTables4と5でそれぞれマークされます。 ただ一つのRTPセッション以内に異なったメディアタイプSHALL NOTの有効搭載量タイプをはさみ込むか、または多重送信して、マルチメディアタイプを送るのに平行で複数のRTPセッションだけを使用してもよいです。 RTPソースはセッションの間、同じメディアタイプの中でペイロードタイプを変えるかもしれません。 追加説明に関して「マルチプレクシングRTPセッション」というRFC3550のセクションを見てください。
Schulzrinne & Casner Standards Track [Page 32] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[32ページ]RFCプロフィール2003年7月
PT encoding media type clock rate channels
name (Hz)
___________________________________________________
0 PCMU A 8,000 1
1 reserved A
2 reserved A
3 GSM A 8,000 1
4 G723 A 8,000 1
5 DVI4 A 8,000 1
6 DVI4 A 16,000 1
7 LPC A 8,000 1
8 PCMA A 8,000 1
9 G722 A 8,000 1
10 L16 A 44,100 2
11 L16 A 44,100 1
12 QCELP A 8,000 1
13 CN A 8,000 1
14 MPA A 90,000 (see text)
15 G728 A 8,000 1
16 DVI4 A 11,025 1
17 DVI4 A 22,050 1
18 G729 A 8,000 1
19 reserved A
20 unassigned A
21 unassigned A
22 unassigned A
23 unassigned A
dyn G726-40 A 8,000 1
dyn G726-32 A 8,000 1
dyn G726-24 A 8,000 1
dyn G726-16 A 8,000 1
dyn G729D A 8,000 1
dyn G729E A 8,000 1
dyn GSM-EFR A 8,000 1
dyn L8 A var. var.
dyn RED A (see text)
dyn VDVI A var. 1
タイプクロックレートチャンネルが命名するメディア(Hz)をコード化するPT___________________________________________________ 0PCMU A8,000 1 1予約されたA2予約されたA3GSM A8,000 1 4G723A8,000 1 5DVI4A8,000 1 6DVI4A16,000 1 7LPC A8,000 1 8PCMA A8,000 1 9、G722A8,000 1 10L16A44,100 2 11L16A44,100 1 12QCELP A8,000 1 13CN A8,000 1 14MPA A90,000(テキストを見ます)15G728A8,000、1 16 DVI4A11; 025 予約されたA20がA23が割り当てられなかったA22が割り当てられなかったA21を割り当てなかった1 17DVI4A22,050 1 18G729A8,000 1 19はダインG726-32A8,000 1ダインG726-24A8,000 1ダインG726-16A8,000 1ダインG729D A8,000 1ダインG729E A8,000 1ダインGSM-EFR A8,000 1ダインL8A var.をAダインG726-40A8,000 1に割り当てませんでした; var.ダインRED A(テキストを見ます)ダインVDVI A var. 1
Table 4: Payload types (PT) for audio encodings
テーブル4: オーディオencodingsのための有効搭載量タイプ(太平洋標準時の)
Schulzrinne & Casner Standards Track [Page 33] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[33ページ]RFCプロフィール2003年7月
PT encoding media type clock rate
name (Hz)
_____________________________________________
24 unassigned V
25 CelB V 90,000
26 JPEG V 90,000
27 unassigned V
28 nv V 90,000
29 unassigned V
30 unassigned V
31 H261 V 90,000
32 MPV V 90,000
33 MP2T AV 90,000
34 H263 V 90,000
35-71 unassigned ?
72-76 reserved N/A N/A
77-95 unassigned ?
96-127 dynamic ?
dyn H263-1998 V 90,000
メディアタイプクロックレート名前(Hz)をコード化するPT_____________________________________________ 24 H261V90,000 32MPV V90,000 33MP2T AV90,000 34H263V90,000 35-71が割り当てなかったV31が割り当てられなかったV30が割り当てられなかったV28nv V90,000 29が割り当てられなかった割り当てられなかったV25CelB V90,000 26JPEG V90,000 27? 72-76 予約されたN/A N/A77-95に割り当てられませんか? 96-127動力?ダインH263-1998V90,000
Table 5: Payload types (PT) for video and combined
encodings
テーブル5: ビデオと結合したencodingsのための有効搭載量タイプ(太平洋標準時の)
Session participants agree through mechanisms beyond the scope of this specification on the set of payload types allowed in a given session. This set MAY, for example, be defined by the capabilities of the applications used, negotiated by a conference control protocol or established by agreement between the human participants.
セッション関係者は与えられたセッションのときに許容されたペイロードタイプのセットに関するこの仕様の範囲を超えたメカニズムを通して同意します。 例えば、このセットは人間の関係者の間で申し合わせて使用されるか、会議制御プロトコルによって交渉されるか、または確立されたアプリケーションの能力によって定義されるかもしれません。
Audio applications operating under this profile SHOULD, at a minimum, be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4). This allows interoperability without format negotiation and ensures successful negotiation with a conference control protocol.
オーディオアプリケーションがこのプロフィールSHOULDの下で最小限で作動して、ペイロードタイプ0(PCMU)と5(DVI4)を送る、そして/または、受け取ることができてください。 これは、形式交渉なしで相互運用性を許容して、会議制御プロトコルでうまくいっている交渉を確実にします。
7. RTP over TCP and Similar Byte Stream Protocols
7. TCPの上のRTPと同様のバイト・ストリームプロトコル
Under special circumstances, it may be necessary to carry RTP in protocols offering a byte stream abstraction, such as TCP, possibly multiplexed with other data. The application MUST define its own method of delineating RTP and RTCP packets (RTSP [23] provides an example of such an encapsulation specification).
特殊事情の下では、バイト・ストリーム抽象化を提供するプロトコルでRTPを運ぶのが必要であるかもしれません、ことによると他のデータと共に多重送信されたTCPなどのように。 アプリケーションはそれ自身のRTPとRTCPパケットを図で表わすメソッドを定義しなければなりません(RTSP[23]はそのようなカプセル化仕様に関する例を提供します)。
8. Port Assignment
8. ポート課題
As specified in the RTP protocol definition, RTP data SHOULD be carried on an even UDP port number and the corresponding RTCP packets SHOULD be carried on the next higher (odd) port number.
同等のUDPポートナンバーと対応するRTCPパケットSHOULDで運ばれてください。RTPで指定されるように定義について議定書の中で述べてください、RTPデータSHOULD、次の、より高い(変な)ポートナンバーで運ばれてください。
Schulzrinne & Casner Standards Track [Page 34] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[34ページ]RFCプロフィール2003年7月
Applications operating under this profile MAY use any such UDP port pair. For example, the port pair MAY be allocated randomly by a session management program. A single fixed port number pair cannot be required because multiple applications using this profile are likely to run on the same host, and there are some operating systems that do not allow multiple processes to use the same UDP port with different multicast addresses.
このプロフィール5月の使用でどんなそのようなUDPポートも操作するアプリケーションが対にされます。 例えば、セッション管理プログラムで手当たりしだいにポート組を割り当てるかもしれません。 このプロフィールを使用する複数のアプリケーションが同じホストで走りそうであって、複数のプロセスが異なったマルチキャストアドレスがある同じUDPポートを使用できないいくつかのオペレーティングシステムがあるので、固定1ポートナンバー組を必要とすることができません。
However, port numbers 5004 and 5005 have been registered for use with this profile for those applications that choose to use them as the default pair. Applications that operate under multiple profiles MAY use this port pair as an indication to select this profile if they are not subject to the constraint of the previous paragraph. Applications need not have a default and MAY require that the port pair be explicitly specified. The particular port numbers were chosen to lie in the range above 5000 to accommodate port number allocation practice within some versions of the Unix operating system, where port numbers below 1024 can only be used by privileged processes and port numbers between 1024 and 5000 are automatically assigned by the operating system.
しかしながら、デフォルトが対にされるとき、ポートNo.5004と5005は使用のためにそれらを使用するのを選ぶそれらのアプリケーションのためのこのプロフィールに示されました。 それらは前のパラグラフの規制を受けることがないなら、複数のプロフィールの下で作動するアプリケーションが、このプロフィールを選択するのに指示としてこのポート組を使用するかもしれません。 アプリケーションは、デフォルトを持つ必要はなくて、ポート組が明らかに指定されるのを必要とするかもしれません。 指定港番号はUnixオペレーティングシステムのいくつかのバージョンの中にポートナンバー配分練習を収容するために範囲に5000年より上で横たわるために選ばれて、どこで特権があるプロセスで1024の下におけるポートナンバーを使用できるだけであるか、そして、1024年と5000年の間ときのポートナンバーがオペレーティングシステムで自動的に割り当てられるということでした。
9. Changes from RFC 1890
9. RFC1890からの変化
This RFC revises RFC 1890. It is mostly backwards-compatible with RFC 1890 except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile. Since this profile may be used without using any of the payload formats listed here, the addition of new payload formats in this revision does not affect backwards compatibility. The changes are listed below, categorized into functional and non-functional changes.
このRFCはRFC1890を改訂します。 それは後方に2つの共同利用できる実現が見つけられなかったので取り除かれた機能以外のRFC1890とほとんど互換性があります。 RFC1890への追加はこのプロフィールの下でペイロード形式の使用における既存の習慣を成文化します。 このプロフィールがここに記載されたペイロード書式のいずれも使用しないで使用されるかもしれないので、この改正における、新しいペイロード形式の添加は後方に互換性に影響しません。 変化は、機能的で非機能的な変化に以下で記載されて、分類されています。
Functional changes:
機能的な変化:
o Section 11, "IANA Considerations" was added to specify the
registration of the name for this profile. That appendix also
references a new Section 3 "Registering Additional Encodings"
which establishes a policy that no additional registration of
static payload types for this profile will be made beyond those
added in this revision and included in Tables 4 and 5. Instead,
additional encoding names may be registered as MIME subtypes for
binding to dynamic payload types. Non-normative references were
added to RFC 3555 [7] where MIME subtypes for all the listed
payload formats are registered, some with optional parameters for
use of the payload formats.
o セクション11、「IANA問題」は、このプロフィールに名前の登録を指定するために加えられました。 静的なペイロードをどんな追加登録もこれのためにタイプしない方針を確立する「登録の追加Encodings」という新しいセクション3が輪郭を描く参照もそうする付録は、この改正で加えられたものを超えて作られていて、Tables4と5に含まれています。 代わりに、追加コード化名はダイナミックなペイロードタイプに付くためのMIME血液型亜型として登録されるかもしれません。 非引用規格はすべての記載されたペイロード形式のためのMIME血液型亜型が登録されているRFC3555[7]に加えられました、ペイロード形式の使用のための任意のパラメタがあるいくつか。
Schulzrinne & Casner Standards Track [Page 35] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[35ページ]RFCプロフィール2003年7月
o Static payload types 4, 16, 17 and 34 were added to incorporate
IANA registrations made since the publication of RFC 1890, along
with the corresponding payload format descriptions for G723 and
H263.
o 静的なペイロードタイプ4、16、17、および34はRFC1890の公表以来されたIANA登録証明書を取り入れるために加えられました、G723のための対応するペイロード書式の記述とH263と共に。
o Following working group discussion, static payload types 12 and 18
were added along with the corresponding payload format
descriptions for QCELP and G729. Static payload type 13 was
assigned to the Comfort Noise (CN) payload format defined in RFC
3389. Payload type 19 was marked reserved because it had been
temporarily allocated to an earlier version of Comfort Noise
present in some draft revisions of this document.
o ワーキンググループ議論に続いて、静的なペイロードタイプ12と18はQCELPとG729のために対応するペイロード書式の記述と共に加えられました。 静的なペイロードタイプ13はRFC3389で定義されたコンフォートNoise(CN)ペイロード書式に選任されました。 有効搭載量タイプ19は、一時このドキュメントのいくつかの改正案における現在のコンフォートNoiseの以前のバージョンにそれを割り当てたので、予約されているとマークされました。
o The payload format for G721 was renamed to G726-32 following the
ITU-T renumbering, and the payload format description for G726 was
expanded to include the -16, -24 and -40 data rates. Because of
confusion regarding draft revisions of this document, some
implementations of these G726 payload formats packed samples into
octets starting with the most significant bit rather than the
least significant bit as specified here. To partially resolve
this incompatibility, new payload formats named AAL2-G726-16, -24,
-32 and -40 will be specified in a separate document (see note in
Section 4.5.4), and use of static payload type 2 is deprecated as
explained in Section 6.
o ITU-Tの番号を付け替えることに続いて、G721のためのペイロード書式はG726-32に改名されました、そして、G726のためのペイロード書式の記述は-16を含むように広げられました、-24と-40のデータ信号速度。 このドキュメントの改正案に関する混乱のために、これらのG726ペイロード形式のいくつかの実現がここに指定されるとして始まる中で最下位ビットよりむしろビット最も重要である八重奏にサンプルに詰め込みました。 この不一致、AAL2-G726-16という新しいペイロード形式、-24、-32、および-40を部分的に決議するのは別々のドキュメントで指定されるでしょう、そして、(セクション4.5.4における注意を見てください)静的なペイロードタイプ2の使用はセクション6で説明されるように推奨しないです。
o Payload formats G729D and G729E were added following the ITU-T
addition of Annexes D and E to Recommendation G.729. Listings
were added for payload formats GSM-EFR, RED, and H263-1998
published in other documents subsequent to RFC 1890. These
additional payload formats are referenced only by dynamic payload
type numbers.
o Annexes DとEのRecommendation G.729へのITU-T添加に続いて、有効搭載量形式のG729DとG729Eは加えられました。 リストはRFC1890へのその後の他のドキュメントで発行されたペイロード形式のGSM-EFR、RED、およびH263-1998のために加えられました。 これらの追加ペイロード形式はダイナミックなペイロード形式数だけによって参照をつけられます。
o The descriptions of the payload formats for G722, G728, GSM, VDVI
were expanded.
o G722、G728、GSMのためのペイロード形式の記述であり、VDVIは広げられました。
o The payload format for 1016 audio was removed and its static
payload type assignment 1 was marked "reserved" because two
interoperable implementations were not found.
o 1016年のオーディオのためのペイロード形式を取り除きました、そして、2つの共同利用できる実現が見つけられなかったので、「予約されている」と静的なペイロードタイプ課題1をマークしました。
o Requirements for congestion control were added in Section 2.
o 輻輳制御のための要件はセクション2で加えられました。
o This profile follows the suggestion in the revised RTP spec that
RTCP bandwidth may be specified separately from the session
bandwidth and separately for active senders and passive receivers.
o このプロフィールはRTCP帯域幅が別々に別々にセッション帯域幅から活発な送付者と受け身の受信機に指定されるかもしれないという改訂されたRTP仕様に基づく提案に続きます。
o The mapping of a user pass-phrase string into an encryption key
was deleted from Section 2 because two interoperable
implementations were not found.
o 2つの共同利用できる実現が見つけられなかったので、暗号化キーへのユーザパスフレーズストリングに関するマッピングはセクション2から削除されました。
Schulzrinne & Casner Standards Track [Page 36] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[36ページ]RFCプロフィール2003年7月
o The "quadrophonic" sample ordering convention for four-channel
audio was removed to eliminate an ambiguity as noted in Section
4.1.
o 4チャンネルのオーディオのためにコンベンションを注文する"quadrophonic"のサンプルは、セクション4.1に述べられるようにあいまいさを排除するために取り除かれました。
Non-functional changes:
非機能的な変化:
o In Section 4.1, it is now explicitly stated that silence
suppression is allowed for all audio payload formats. (This has
always been the case and derives from a fundamental aspect of
RTP's design and the motivations for packet audio, but was not
explicit stated before.) The use of comfort noise is also
explained.
o セクション4.1では、現在、沈黙抑圧がすべてのオーディオペイロード形式のために許されていると明らかに述べられます。 (これは、いつもケースであり、RTPのデザインの基本的な面とパケットオーディオに関する動機を得ますが、以前、述べられていた状態で明白ではありませんでした。) また、安らぎ雑音の使用は説明されます。
o In Section 4.1, the requirement level for setting of the marker
bit on the first packet after silence for audio was changed from
"is" to "SHOULD be", and clarified that the marker bit is set only
when packets are intentionally not sent.
o いてください。オーディオのための沈黙の後の最初のパケットのマーカービットの設定へのレベルが変えられた要件がセクション4.1に、「ある」、「SHOULD、」 はっきりさせられて、マーカービットがパケットが故意にそうであるセットだけであることが発信しませんでした。
o Similarly, text was added to specify that the marker bit SHOULD be
set to one on the last packet of a video frame, and that video
frames are distinguished by their timestamps.
o 同様に、テキストは、マーカービットSHOULDがビデオフレームの最後のパケットの上の1つに用意ができて、ビデオフレームがそれらのタイムスタンプによって区別されると指定するために加えられました。
o RFC references are added for payload formats published after RFC
1890.
o RFC参照はRFC1890の後に発行されたペイロード形式のために加えられます。
o The security considerations and full copyright sections were
added.
o セキュリティ問題と完全なCopyright部は加えられました。
o According to Peter Hoddie of Apple, only pre-1994 Macintosh used
the 22254.54 rate and none the 11127.27 rate, so the latter was
dropped from the discussion of suggested sampling frequencies.
o アップルのピーターHoddieによると、pre-1994マッキントッシュだけが22254.54レートと11127.27が評定しないなにも使用したので、後者は提案されたサンプリング周波数の議論から落とされました。
o Table 1 was corrected to move some values from the "ms/packet"
column to the "default ms/packet" column where they belonged.
o テーブル1は、「ms/パケット」コラムからそれらが属した「デフォルトms/パケット」コラムまでいくつかの値を動かすために修正されました。
o Since the Interactive Multimedia Association ceased operations, an
alternate resource was provided for a referenced IMA document.
o インタラクティブ・マルチメディア協会が操作をやめたので、参照をつけられたIMAドキュメントに交互のリソースを提供しました。
o A note has been added for G722 to clarify a discrepancy between
the actual sampling rate and the RTP timestamp clock rate.
o G722が実際の標本抽出率とRTPタイムスタンプクロックレートの間の食い違いをはっきりさせるように、注意は加えられます。
o Small clarifications of the text have been made in several places,
some in response to questions from readers. In particular:
o 処々方々、読者からの質問に対応したいくつかでテキストの小さい明確化をしました。 特に:
- A definition for "media type" is given in Section 1.1 to allow
the explanation of multiplexing RTP sessions in Section 6 to be
more clear regarding the multiplexing of multiple media.
- セクション6における、マルチプレクシングRTPセッションの説明がマルチメディアのマルチプレクシングに関して、より明確であることを許容するためにセクション1.1で「メディアはタイプする」定義を与えます。
Schulzrinne & Casner Standards Track [Page 37] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[37ページ]RFCプロフィール2003年7月
- The explanation of how to determine the number of audio frames
in a packet from the length was expanded.
- 長さからパケットのオーディオフレームの数をどう測定するかに関する説明は広げられました。
- More description of the allocation of bandwidth to SDES items
is given.
- SDESの品目への帯域幅の配分の、より多くの記述を与えます。
- A note was added that the convention for the order of channels
specified in Section 4.1 may be overridden by a particular
encoding or payload format specification.
- 注意は加えられました。チャンネルの注文のためのコンベンションがセクション4.1で指定したのは特定のコード化かペイロード書式仕様によってくつがえされるかもしれません。
- The terms MUST, SHOULD, MAY, etc. are used as defined in RFC
2119.
- 用語が使用しなければならない、SHOULD、5月などはRFC2119で定義されるように使用されています。
o A second author for this document was added.
o このドキュメントのための2番目の作者は加えられました。
10. Security Considerations
10. セキュリティ問題
Implementations using the profile defined in this specification are subject to the security considerations discussed in the RTP specification [1]. This profile does not specify any different security services. The primary function of this profile is to list a set of data compression encodings for audio and video media.
この仕様に基づき定義されたプロフィールを使用する実現はRTP仕様[1]で議論したセキュリティ問題を受けることがあります。 このプロフィールは少しの異なったセキュリティー・サービスも指定しません。 このプロフィールの第一の機能はオーディオとビデオメディアのためにデータ圧縮encodingsの1セットを記載することです。
Confidentiality of the media streams is achieved by encryption. Because the data compression used with the payload formats described in this profile is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
メディアの流れの秘密性は暗号化で達成されます。 このプロフィールで説明されるペイロード形式と共に使用されるデータ圧縮が適用された終わりから終わりであるので、暗号化が圧縮の後に実行されるかもしれないので、2つの操作の間には、闘争が全くありません。
A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded.
潜在的サービスの否定の脅威は、データencodingsのために不均等な受信端末コンピュータの負荷を持っている圧縮のテクニックを使用することで存在しています。 攻撃者は、流れの中への解読するために複雑な病理学的なデータグラムを注入して、受信機を積みすぎさせることができます。
As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication MAY be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, source pruning is implemented in IGMPv3 (RFC 3376) [24] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.
どんなIPベースのプロトコル、いくつかの事情ではも、受信機は単に必要であるか望まれないあまりに多くのパケットの領収書で積みすぎられるかもしれません。 ネットワーク層認証は望まれないソースからパケットを捨てるのに使用されるかもしれませんが、認証自体の加工費は高過ぎるかもしれません。 マルチキャスト環境で、ソース刈り込みは、受信機が、どのソースがそれに達することができるかを選択するのを許容するためにIGMPv3(RFC3376)[24]とマルチキャストルーティング・プロトコルで実行されます。
Schulzrinne & Casner Standards Track [Page 38] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[38ページ]RFCプロフィール2003年7月
11. IANA Considerations
11. IANA問題
The RTP specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), RFC 2327 [6], to refer to transport methods. This profile registers the name "RTP/AVP".
RTP仕様は方法を輸送するのに参照するSession記述プロトコル(SDP)、RFC2327[6]などの、よりハイレベルの制御プロトコルによる使用のためのプロフィール名の登録を確立します。 このプロフィールは"RTP/AVP"という名前を登録します。
Section 3 establishes the policy that no additional registration of static RTP payload types for this profile will be made beyond those added in this document revision and included in Tables 4 and 5. IANA may reference that section in declining to accept any additional registration requests. In Tables 4 and 5, note that types 1 and 2 have been marked reserved and the set of "dyn" payload types included has been updated. These changes are explained in Sections 6 and 9.
セクション3はこのプロフィールのための静的なRTPペイロードタイプのどんな追加登録もこのドキュメント改正で加えられて、Tables4と5に含まれていたものでされない方針を確立します。 どんな追加登録要求も受け入れるのを断る際にIANAはそのセクションに参照をつけるかもしれません。 Tables4と5では、予約されているとタイプ1と2をマークして、「ダイン」ペイロードタイプを含むセットをアップデートしたことに注意してください。 これらの変化はセクション6と9で説明されます。
12. References
12. 参照
12.1 Normative References
12.1 標準の参照
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003.
[1]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC3550、2003年7月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[3] Apple Computer, "Audio Interchange File Format AIFF-C", August
1991. (also ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z).
[3]アップル・コンピューター、「オーディオ置き換えファイル形式AIFF-C」1991年8月。 ( ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z も。)
12.2 Informative References
12.2 有益な参照
[4] Braden, R., Clark, D. and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[4] ブレーデン、R.、クラーク、D.、およびS.Shenker、「インターネット構造における統合サービス:」 「概観」、RFC1633、1994年6月。
[5] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Service", RFC 2475,
December 1998.
[5] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「微分されたサービスのための構造」、RFC2475、1998年12月。
[6] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[6] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Types", RFC 3555, July 2003.
[7]CasnerとS.とP.Hoschka、「RTP有効搭載量タイプのMIMEの種類登録」、RFC3555、2003年7月。
[8] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", BCP
13, RFC 2048, November 1996.
解放された[8]、N.、Klensin、J.、およびJ.ポステル、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、BCP13、RFC2048、1996年11月。
Schulzrinne & Casner Standards Track [Page 39] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[39ページ]RFCプロフィール2003年7月
[9] Zopf, R., "Real-time Transport Protocol (RTP) Payload for
Comfort Noise (CN)", RFC 3389, September 2002.
[9]Zopf、R.、「安らぎ雑音(CN)のためのリアルタイムのトランスポート・プロトコル(RTP)有効搭載量」、RFC3389、2002年9月。
[10] Deleam, D. and J.-P. Petit, "Real-time implementations of the
recent ITU-T low bit rate speech coders on the TI TMS320C54X
DSP: results, methodology, and applications", in Proc. of
International Conference on Signal Processing, Technology, and
Applications (ICSPAT) , (Boston, Massachusetts), pp. 1656--1660,
October 1996.
[10]Deleam、D.、およびJ.-P。 小さい、「TI TMS320C54X DSPにおける最近のITU-T低いビット伝送速度音声符号器のリアルタイムの実現:」 中の「結果、方法論、およびアプリケーション」、Proc Signal Processing、Technology、およびApplications(ICSPAT)の上の国際コンファレンス、(ボストン(マサチューセッツ))についてページ 1656--1660と、1996年10月。
[11] Mouly, M. and M.-B. Pautet, The GSM system for mobile
communications Lassay-les-Chateaux, France: Europe Media
Duplication, 1993.
[11] ムリー、M.、およびM.B。 Pautet、移動通信Lassay-les-Chateaux、フランスのGSMシステム: ヨーロッパメディア複製、1993。
[12] Degener, J., "Digital Speech Compression", Dr. Dobb's Journal,
December 1994.
[12]Degener、J.、「デジタルスピーチ圧縮」、ドッブ博士のジャーナル、1994年12月。
[13] Redl, S., Weber, M. and M. Oliphant, An Introduction to GSM
Boston: Artech House, 1995.
GSMボストンへの[13]RedlとS.とウェーバーとM.とM.オリファント、序論: Artech家、1995。
[14] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP
Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[14] ホフマンとD.とフェルナンドとG.とGoyalとV.とM.Civanlar、「MPEG1/MPEG2ビデオのためのRTP有効搭載量形式」、RFC2250、1998年1月。
[15] Jayant, N. and P. Noll, Digital Coding of Waveforms--Principles
and Applications to Speech and Video Englewood Cliffs, New
Jersey: Prentice-Hall, 1984.
[15]JayantとN.とP.ノル、波形のデジタルコード化--スピーチへの原則とアプリケーションとビデオイングルウッドがけ、ニュージャージー: 新米のホール、1984。
[16] McKay, K., "RTP Payload Format for PureVoice(tm) Audio", RFC
2658, August 1999.
[16] マッケイ、K.、「PureVoice(tm)オーディオのためのRTP有効搭載量形式」、RFC2658、1999年8月。
[17] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, J.-C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload
for Redundant Audio Data", RFC 2198, September 1997.
[17] パーキンスとC.とKouvelasとI.とホドソンとO.とハードマンとV.とハンドレーとM.とBolotとJ.-C.、ベガ-ガルシアとA.とS.堀-Parisis、「余分なオーディオデータのためのRTP有効搭載量」RFC2198(1997年9月)。
[18] Speer, M. and D. Hoffman, "RTP Payload Format of Sun's CellB
Video Encoding", RFC 2029, October 1996.
[18] シュペーアとM.とD.ホフマン、「SunのCellBビデオのコード化のRTP有効搭載量形式」、RFC2029、1996年10月。
[19] Berc, L., Fenner, W., Frederick, R., McCanne, S. and P. Stewart,
"RTP Payload Format for JPEG-Compressed Video", RFC 2435,
October 1998.
[19]BercとL.とフェナーとW.とフレディリックとR.とMcCanne、S.とP.スチュワート、「JPEGによって圧縮されたビデオのためのRTP有効搭載量形式」RFC2435(1998年10月)。
[20] Turletti, T. and C. Huitema, "RTP Payload Format for H.261 Video
Streams", RFC 2032, October 1996.
[20]TurlettiとT.とC.Huitema、「H.261ビデオストリームのためのRTP有効搭載量形式」、RFC2032、1996年10月。
[21] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 2190,
September 1997.
[21] 朱、C.、「H.263ビデオストリームのためのRTP有効搭載量形式」、RFC2190、1997年9月。
Schulzrinne & Casner Standards Track [Page 40] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[40ページ]RFCプロフィール2003年7月
[22] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco, C.,
Newell, D., Ott, J., Sullivan, G., Wenger, S. and C. Zhu, "RTP
Payload Format for the 1998 Version of ITU-T Rec. H.263 Video
(H.263+)", RFC 2429, October 1998.
[22] ボルマンとC.とクラインとL.とDeisherとG.とGardosとT.とMacioccoとC.とヌーエルとD.とオットとJ.とサリバンとG.とウェンガーとS.とC.朱、「1998年のITU-T RecのバージョンのためのRTP有効搭載量形式。」 「H.263ビデオ(H.263+)」、RFC2429、1998年10月。
[23] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[23]SchulzrinneとH.とラオとA.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」、RFC2326 1998年4月。
[24] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
[24] カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月」。
13. Current Locations of Related Resources
13. 関連リソースの現在の位置
Note: Several sections below refer to the ITU-T Software Tool Library (STL). It is available from the ITU Sales Service, Place des Nations, CH-1211 Geneve 20, Switzerland (also check http://www.itu.int). The ITU-T STL is covered by a license defined in ITU-T Recommendation G.191, "Software tools for speech and audio coding standardization".
以下に注意してください。 下の数人のセクションがITU-T Software Tool図書館(STL)について言及します。 それはITU Sales Service、Place des Nations、CH-1211ジュネーブ20スイスから利用可能です(また、 http://www.itu.int をチェックしてください)。 ITU-T STLはITU-T Recommendation G.191で定義されたライセンスで覆われています、「スピーチとオーディオのためのソフトウェアツールは標準化をコード化し」て。
DVI4
DVI4
An archived copy of the document IMA Recommended Practices for Enhancing Digital Audio Compatibility in Multimedia Systems (version 3.0), which describes the IMA ADPCM algorithm, is available at:
Multimedia Systems(バージョン3.0)のEnhancingデジタル・オーディオCompatibilityのためのドキュメントIMA Recommended Practicesの保存されたコピーは以下で利用可能です。Multimedia SystemsはIMA ADPCMアルゴリズムを説明します。
http://www.cs.columbia.edu/~hgs/audio/dvi/
http://www.cs.columbia.edu/~hgs/audio/dvi/
An implementation is available from Jack Jansen at
実現はジャック・ヤンセンから利用可能です。
ftp://ftp.cwi.nl/local/pub/audio/adpcm.shar
ftp://ftp.cwi.nl/local/pub/audio/adpcm.shar
G722
G722
An implementation of the G.722 algorithm is available as part of the ITU-T STL, described above.
G.722アルゴリズムの実現は上で説明されたITU-T STLの一部として利用可能です。
G723
G723
The reference C code implementation defining the G.723.1 algorithm and its Annexes A, B, and C are available as an integral part of Recommendation G.723.1 from the ITU Sales Service, address listed above. Both the algorithm and C code are covered by a specific license. The ITU-T Secretariat should be contacted to obtain such licensing information.
G.723.1アルゴリズムを定義する参照Cコード実現とそのAnnexes A、B、およびCはITU Sales Service(上に記載されたアドレス)からのRecommendation G.723.1の不可欠の部分として利用可能です。 アルゴリズムとCコードの両方が特定のライセンスでカバーされています。 ITU-T事務局は、情報を認可しながらそのようなものを得るために連絡されるべきです。
Schulzrinne & Casner Standards Track [Page 41] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[41ページ]RFCプロフィール2003年7月
G726
G726
G726 is specified in the ITU-T Recommendation G.726, "40, 32, 24, and 16 kb/s Adaptive Differential Pulse Code Modulation (ADPCM)". An implementation of the G.726 algorithm is available as part of the ITU-T STL, described above.
G726はITU-T Recommendation G.726と、「40、32、24、および16kb/s Adaptive Differentialパルスコードの変調(ADPCM)」で指定されます。 G.726アルゴリズムの実現は上で説明されたITU-T STLの一部として利用可能です。
G729
G729
The reference C code implementation defining the G.729 algorithm and its Annexes A through I are available as an integral part of Recommendation G.729 from the ITU Sales Service, listed above. Annex I contains the integrated C source code for all G.729 operating modes. The G.729 algorithm and associated C code are covered by a specific license. The contact information for obtaining the license is available from the ITU-T Secretariat.
Iを通してG.729アルゴリズムとそのAnnexes Aを定義する参照Cコード実現はITU Sales ServiceからのRecommendation G.729の不可欠の部分として利用可能です、上では、記載されています。 別館IはすべてのG.729オペレーティング・モードのための統合Cソースコードを含んでいます。 G.729アルゴリズムと関連Cコードは特定のライセンスで含まれています。 免許を取得するための問い合わせ先はITU-T事務局から利用可能です。
GSM
GSM
A reference implementation was written by Carsten Bormann and Jutta Degener (then at TU Berlin, Germany). It is available at
参照実現はカルステン・ボルマンとユッタDegener(次にTUベルリン(ドイツ)で)によって書かれました。 それは利用可能です。
http://www.dmn.tzi.org/software/gsm/
http://www.dmn.tzi.org/software/gsm/
Although the RPE-LTP algorithm is not an ITU-T standard, there is a C code implementation of the RPE-LTP algorithm available as part of the ITU-T STL. The STL implementation is an adaptation of the TU Berlin version.
RPE-LTPアルゴリズムはITU-T規格ではありませんが、ITU-T STLの一部として利用可能なRPE-LTPアルゴリズムのCコード実現があります。 STL実現はTUベルリンバージョンの適合です。
LPC
LPC
An implementation is available at
実現は利用可能です。
ftp://parcftp.xerox.com/pub/net-research/lpc.tar.Z
ftp://parcftp.xerox.com/pub/net-research/lpc.tar.Z
PCMU, PCMA
PCMU、PCMA
An implementation of these algorithms is available as part of the ITU-T STL, described above.
これらのアルゴリズムの実現は上で説明されたITU-T STLの一部として利用可能です。
14. Acknowledgments
14. 承認
The comments and careful review of Simao Campos, Richard Cox and AVT Working Group participants are gratefully acknowledged. The GSM description was adopted from the IMTC Voice over IP Forum Service Interoperability Implementation Agreement (January 1997). Fred Burg and Terry Lyons helped with the G.729 description.
シモン・カンポス、リチャードCox、およびAVT作業部会の関係者のコメントと慎重なレビューは感謝して承諾されます。 GSM記述はIMTCボイス・オーバー IP Forum Service Interoperability Implementation Agreement(1997年1月)から採用されました。 フレッドBurgとテリー・リヨンはG.729記述で助けました。
Schulzrinne & Casner Standards Track [Page 42] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[42ページ]RFCプロフィール2003年7月
15. Intellectual Property Rights Statement
15. 知的所有権声明
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
16. Authors' Addresses
16. 作者のアドレス
Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 United States
ヘニングSchulzrinneコンピュータサイエンス学部コロンビア大学1214アムステルダムAvenueニューヨーク10027ニューヨーク(合衆国)
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
スティーブンL.CasnerパケットDesign3400Hillviewアベニュー、Building3パロアルト、カリフォルニア94304合衆国
EMail: casner@acm.org
メール: casner@acm.org
Schulzrinne & Casner Standards Track [Page 43] RFC 3551 RTP A/V Profile July 2003
3551RTP A/VのSchulzrinne&Casner標準化過程[43ページ]RFCプロフィール2003年7月
17. Full Copyright Statement
17. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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 & Casner Standards Track [Page 44]
Schulzrinne&Casner標準化過程[44ページ]
一覧
スポンサーリンク
