Network Working Group                                        Y. Hiwasaki
Request for Comments: 5686                                     H. Ohmuro
Category: Standards Track                                NTT Corporation
                                                            October 2009
        
     RTP Payload Format for mU-law EMbedded Codec for Low-delay IP
                  Communication (UEMCLIP) Speech Codec
        

Abstract

抽象

This document describes the RTP payload format of a mU-law EMbedded Coder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711. The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech.

この文書では、低遅延IP通信(UEMCLIP)用μ則埋め込みコーダ、ITU-T G.711の拡張音声コーデックのRTPペイロードフォーマットを記述する。ビットストリームは、このように狭帯域と広帯域音声の間に便利なトランスコーディング操作を提供し、また、PCMUとして知られている組み込みのu-lawのビットストリームと拡張性の高い構造を有しています。

Status of This Memo

このメモのステータス

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント(http://trustee.ietf.org/license-info)に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者(複数可)材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者(単数または複数)から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。

Table of Contents

目次

   1. Introduction ....................................................2
      1.1. Terminology ................................................3
   2. Media Format Background .........................................3
   3. Payload Format ..................................................5
      3.1. RTP Header Usage ...........................................6
      3.2. Multiple Frames in an RTP Packet ...........................6
      3.3. Payload Data ...............................................7
           3.3.1. Main Header .........................................7
           3.3.2. Sub-Layer ..........................................10
   4. Transcoding between UEMCLIP and G.711 ..........................11
   5. Congestion Control Considerations ..............................12
   6. Payload Format Parameters ......................................13
      6.1. Media Type Registration ...................................13
      6.2. Mapping to SDP Parameters .................................14
           6.2.1. Mode Specification .................................15
      6.3. Offer-Answer Model Considerations .........................16
           6.3.1. Offer-Answer Guidelines ............................16
           6.3.2. Examples ...........................................17
   7. Security Considerations ........................................19
   8. IANA Considerations ............................................19
   9. References .....................................................19
      9.1. Normative References ......................................19
      9.2. Informative References ....................................20
        
1. Introduction
1. はじめに

This document specifies the payload format for sending UEMCLIP-encoded (mU-law EMbedded Coder for Low-delay IP communication) speech using the Real-time Transport Protocol (RTP) [RFC3550]. UEMCLIP is a proprietary codec that enhances u-law ITU-T G.711 [ITU-T-G.711] and that is designed to help the market for smooth transition towards the forthcoming wideband communication environment while achieving a very small media transcoding load with the existing terminals, in which the implementation of G.711 is mandatory.

この文書では、リアルタイムトランスポートプロトコル(RTP)[RFC3550]を用いて音声(低遅延IP通信のためにMU-法則埋め込まコーダー)UEMCLIPでエンコードされた送信用のペイロード形式を指定します。 UEMCLIPは、U-法のITU-T G.711 [ITU-TG.711]を強化して、非常に小さなメディアトランスコーディングの負荷を達成しながら、それは今後の広帯域通信環境へのスムーズな移行のための市場を支援するために設計された独自のコーデックですG.711の実装が必須である既存の端末、。

It should be noted that, generally speaking, codecs are negotiated and changed using an SDP exchange. Also, [RFC3550] defines general RTP mixer and translator models, where media transcoding may not take place at the node. For those cases, the design concept of the embedded structure is not useful. However, there are other cases when costly transcoding is unavoidable in commonly deployed types of Multi-point Control Units (MCUs), which terminate media and RTCP packets [RFC5117], and when narrowband and wideband terminals coexist. This embedded bitstream structure can reduce the media transcoding to a simple bitstream truncation.

一般的に言えば、コーデックをSDP交換を使用して交渉し、変更されていることに留意すべきです。また、[RFC3550]は、メディアトランスコーディングノードで行われないことがあり、一般的なRTPミキサおよびトランスレータモデルを定義します。これらのケースでは、埋め込まれた構造の設計思想は有用ではありません。高価なトランスコーディングは、メディア及びRTCPパケットを終了マルチポイント制御ユニット(マイコン)の一般展開タイプ、[RFC5117]に避けられない場合には、狭帯域及び広帯域端末が共存する場合しかし、他の場合があります。この埋め込まれたビットストリーム構造は、単純なビットストリームの切り捨てにメディアトランスコーディングを減らすことができます。

The background and the basic idea of the media format is described in Section 2. The details of the payload format are given in Section 3. The transcoding issues with G.711 are discussed in Section 4, and the considerations for congestion control are in Section 5. In Section 6, the payload format parameters for a media type registration for UEMCLIP RTP payload format and Session Description Protocol (SDP) mappings are provided. The security considerations and IANA considerations are dealt with in Section 7 and Section 8, respectively.

背景とメディアフォーマットの基本的な考え方は、ペイロードフォーマットの詳細はセクション4に記載されている第3 G.711とトランスコーディングの問題に記載されている第2節に記載され、および輻輳制御のための考察は、セクションに記載されてい第6 5.は、UEMCLIP RTPペイロードフォーマットおよびセッション記述プロトコル用のメディアタイプ登録のためのペイロード・フォーマット・パラメータ(SDP)のマッピングが提供されます。セキュリティ上の考慮事項とIANAの考慮事項は、それぞれ、第7及び第8節で対処されています。

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 [RFC2119].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

2. Media Format Background
2. Media形式の背景

UEMCLIP is an enhanced version of u-law ITU-T G.711, otherwise known as PCMU [RFC4856]. It is targeted at Voice over Internet Protocol (VoIP) applications, and its main goal is to provide a wideband communication platform that is highly interoperable with existing terminals equipped with G.711 and to stimulate the market to gradually shift to using wideband communication. In widely deployed multi-point conferencing systems, the packets usually go through RTCP-terminating (RTP Control Protocol) MCUs, "Topo-RTCP-terminating-MCU" as defined in [RFC5117]. Because the G.711 bitstream is embedded in the bitstream, costly media transcoding can be avoided in this case.

UEMCLIPは、そうでなければPCMU [RFC4856]として知られているU-法ITU-T G.711の拡張バージョンです。これは、インターネットプロトコル(VoIP)アプリケーション、ボイスオーバーを対象に、その主な目的は、G.711を搭載した既存の端末と高い相互運用性があり、徐々に広帯域通信を使用してに移行する市場を刺激するために、広帯域通信プラットフォームを提供することを目的とします。 [RFC5117]で定義されるように広く展開されているマルチポイント会議システムでは、パケットは、通常、RTCP-終端(RTP制御プロトコル)マイコン、「TOPO-RTCP-終端-MCU」を経ます。 G.711のビットストリームがビットストリームに埋め込まれているので、高価なメディアトランスコーディングは、この場合には避けることができます。

This document does not discuss the implementation details of the encoder and decoder, but only describes the bitstream format.

この文書では、エンコーダとデコーダの実装の詳細を議論するが、唯一のビットストリームフォーマットを説明していません。

Because of its scalable nature, there are a number of sub-bitstreams (sub-layer) in a UEMCLIP bitstream. By choosing appropriate sub-layers, the codec can adapt to the following requirements:

なぜなら、そのスケーラブルな性質の、UEMCLIPビットストリーム内のサブビットストリーム(サブレイヤー)の数があります。適切なサブレイヤーを選択することにより、コーデックは、次の要件に適応することができます。

o Sampling frequency,

Oサンプリング周波数、

o Number of channels,

Oチャネルの数、

o Speech quality, and

O音声品質、および

o Bit-rate.

Oビットレート。

The UEMCLIP codec operates at a 20-ms frame, and includes three sub-coders as shown in Table 1. The core layer is u-law G.711 at 64 kbit/s, and other two are quality and bandwidth enhancement layers with bit-rate of 16 kbit/s each.

UEMCLIPコーデックは20msのフレームで動作し、コア層は、64キロビット/秒でU法G.711であり、他の2つのビットが、品質と帯域幅拡張層である、表1に示すように、3つのサブ符号器を含みます16キロビット/秒毎の-rate。

   +-------+---------------------+----------+--------------------------+
   | Layer | Description         | Bit-rate | Coding algorithm         |
   +-------+---------------------+----------+--------------------------+
   |   a   | G.711 core          |       64 | u-law PCM                |
   |       |                     |          |                          |
   |   b   | Lower-band          |       16 | Time domain block        |
   |       | enhancement         |          | quantization             |
   |       |                     |          |                          |
   |   c   | Higher-band         |       16 | MDCT block quantization  |
   +-------+---------------------+----------+--------------------------+
        

Table 1: Sub-Layer Description

表1:サブレイヤの説明

Based on these sub-layers, the UEMCLIP codec operates in four modes as shown in Table 2. Here, "Ch" is the number of channels and "Fs" is the sampling frequency in kHz. It should be noted that the current version only supports single-channel operation and there might be future extensions with multi-channel capabilities. The absent Modes 2 and 5 are reserved for possible future extension to 32 kHz sampling modes. As the mode definition is expected to grow, any other modes not defined in this table MUST NOT be used for compatibility and interoperability reasons.

これらのサブ層に基づいて、ここで、表2に示すようにUEMCLIPコーデックは4つのモードで動作し、「CH」は、チャネルの数であり、「FS」はkHzのサンプリング周波数です。現在のバージョンは、シングルチャネル動作をサポートし、マルチチャンネル機能を持​​つ将来の拡張があるかもしれないことに留意すべきです。不在モード2および5は32 kHzのサンプリングモードへの可能な将来の拡張のために予約されています。モード定義が成長すると予想されるので、この表に定義されていない任意の他のモードは、互換性と相互運用性の理由のために使用してはいけません。

   +------+----+----+-------+-------+-------+-------------+------------+
   | Mode | Ch | Fs | Layer | Layer | Layer |    Bit-rate |      Total |
   |      |    |    |   a   |   b   |   c   | w/o headers |   bit-rate |
   |      |    |    |       |       |       |    [kbit/s] |   [kbit/s] |
   +------+----+----+-------+-------+-------+-------------+------------+
   |   0  |  1 |  8 |   x   |   -   |   -   |          64 |       67.2 |
   |      |    |    |       |       |       |             |            |
   |   1  |  1 | 16 |   x   |   -   |   x   |          80 |       84.0 |
   |      |    |    |       |       |       |             |            |
   |   2  |  - |  - |   -   |   -   |   -   |           - |          - |
   |      |    |    |       |       |       |             |            |
   |   3  |  1 |  8 |   x   |   x   |   -   |          80 |       84.0 |
   |      |    |    |       |       |       |             |            |
   |   4  |  1 | 16 |   x   |   x   |   x   |          96 |      100.8 |
   |      |    |    |       |       |       |             |            |
   |   5  |  - |  - |   -   |   -   |   -   |           - |          - |
   +------+----+----+-------+-------+-------+-------------+------------+
        

Table 2: Mode Description

表2:モード説明

The UEMCLIP bitstream contains internal headers and other side-information apart from the layer data. This results in total bit-rate larger than the sum of the layers shown in the above table. The detail of the internal headers and auxiliary information are described in Section 3.3.1.

UEMCLIPビットストリームは、レイヤデータとは別に、内部ヘッダおよび他のサイド情報を含んでいます。これは、上記の表に示されている層の合計よりも大きい合計ビットレートをもたらします。内部ヘッダと補助情報の詳細は、セクション3.3.1に記載されています。

Defining the sampling frequency and the number of channels does not result in a singular mode, i.e., there can be multiple modes for the same sampling frequency or number of channels. The supported modes would differ between implementations; thus, the sender and the receiver must negotiate what mode to use for transmission.

サンプリング周波数と特異モードをもたらさないチャネルの数を定義する、すなわち、同一のサンプリング周波数又はチャネルの数の複数のモードが存在することができます。サポートされているモードは、実装間で異なるであろう。このように、送信者と受信者が送信するためにどのようなモードを使用するように交渉しなければなりません。

3. Payload Format
3.ペイロードフォーマット

As an RTP payload, the UEMCLIP bitstream can contain one or more frames as shown in Figure 1.

図1に示すように、RTPペイロードとして、UEMCLIPビットストリームは、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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      RTP Header                               |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    |                                                               |
    |                 one or more frames of UEMCLIP                 |
    |                                                               |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
        

Figure 1: RTP Payload Format

図1:RTPペイロードフォーマット

The UEMCLIP bitstream has a scalable structure; thus, it is possible to reconstruct the signal by decoding a part of it. A UEMCLIP frame is composed of a main header (MH) followed by one or more (up to three) sub-layers (SLs) as shown in Figure 2.

UEMCLIPビットストリームは、スケーラブルな構造を有しています。従って、それの一部をデコードして信号を再構成することが可能です。 UEMCLIPフレームは、図2に示すように、1つまたは複数(3個まで)のサブ層(SLS)、続いてメインヘッダ(MH)から構成されています。

                            +--+-------+//-+
                            |MH| SL #1 |...|
                            +--+-------+//-+
        

Figure 2: A UEMCLIP Frame (Bitstream Format)

図2:UEMCLIPフレーム(ビットストリームフォーマット)

As a sub-layer, the core layer, i.e., "Layer a", MUST always be included. It should be noted that the location of the core layer may or may not immediately follow MH field. The decoder MUST always refer to the layer indices for proper decoding because the order of the sub-layers is arbitrary.

副層として、コア層、すなわち、「A層」は、常に含まれなければなりません。また、コア層の位置は、直ちにMHフィールドに従わなくてもよいか、ということに留意すべきです。副層の順序は任意であるので、デコーダは、常に適切な復号化のためにレイヤインデックスを参照しなければなりません。

The UEMCLIP bitstream does not explicitly include the following information: mode and sampling frequency (Fs). As described before, this information MUST be exchanged while establishing a connection, for example, by means of SDP.

モードとサンプリング周波数(fs):UEMCLIPビットストリームは、明示的に次の情報が含まれていません。前述したように、例えば、接続の確立中に、この情報は、SDPによって、交換しなければなりません。

3.1. RTP Header Usage
3.1. RTPヘッダーの使用

Each RTP packet starts with a fixed RTP header, as explained in [RFC3550]. The following fields of the RTP fixed header used specifically for UEMCLIP streams are emphasized:

各RTPパケットは、[RFC3550]で説明したように、固定されたRTPヘッダで始まります。 UEMCLIPストリームのために特別に使用されるRTPの固定ヘッダの次のフィールドが強調されます。

Payload type: The assignment of an RTP payload type for this packet format is outside the scope of this document; however, it is expected that a payload type in the dynamic range shall be assigned.

ペイロード・タイプ:このパケットフォーマットのためのRTPペイロードタイプの割り当ては、この文書の範囲外です。しかし、ダイナミックレンジにおけるペイロードタイプを割り当てなければならないことが予想されます。

Timestamp: This encodes the sampling instant of the first speech signal sample in the RTP data packet. For UEMCLIP streams, the RTP timestamp MUST advance based on a clock either at 8000 or 16000 (Hz). In cases where the audio sampling rate can change during a session, the RTP timestamp rate MUST be equal to the maximum rate (in Hz) given in the mode range (see Section 6.2.1). This implies that the RTP timestamp rate for UEMCLIP payload type MUST NOT change during a session. For example, for a UEMCLIP stream with 8-kHz audio sampling, where a transition to a 16-kHz audio sampling mode is allowed, the RTP time stamp must always advance using the 16-kHz clock rate. For a fixed audio sampling mode, the RTP timestamp rate should be either 8 or 16 kHz, depending on the sampling rate.

タイムスタンプ:これは、RTPデータパケットにおける第1の音声信号サンプルのサンプリングの瞬間をコードします。 UEMCLIPストリームは、RTPタイムスタンプは、クロックのいずれか8000または16000(Hz)とに基づいて進行しなければなりません。オーディオサンプリングレートがセッション中に変更することができる場合には、RTPタイムスタンプレートは、モードの範囲で与えられた最大速度(Hz単位)(セクション6.2.1を参照)に等しくなければなりません。これはUEMCLIPペイロードタイプのためのRTPタイムスタンプ率はセッション中に変更しないでなければならないことを意味します。例えば、16 kHzのオーディオサンプリングモードへの移行が許可されている8kHzの音声サンプリングとUEMCLIPストリームに対して、RTPタイムスタンプは、常に、16 kHzのクロックレートを使用して前進しなければなりません。固定オーディオサンプリングモードの場合、RTPタイムスタンプレートは、サンプリングレートに応じて、いずれか8、または16 kHzであるべきです。

Marker bit: If the codec is used for applications with discontinuous transmission (DTX, or silence compression), the first packet after a silence period during which packets have not been transmitted contiguously SHOULD have the marker bit in the RTP data header set to one. The marker bit in all other packets MUST be zero. Applications without DTX MUST set the marker bit to zero.

マーカビット:コーデックは、不連続送信(DTX、または無音圧縮)を持つアプリケーションに使用される場合、パケットが連続的に送信されていない時に無音期間の後の最初のパケットが1に設定されたRTPデータヘッダ内のマーカビットを有しているべきです。他のすべてのパケットでマーカービットはゼロでなければなりません。 DTXのないアプリケーションはゼロにマーカービットを設定しなければなりません。

3.2. Multiple Frames in an RTP Packet
3.2. RTPパケットに複数のフレーム

More than one UEMCLIP frame may be included in a single RTP packet by a sender. However, senders have the following additional restrictions:

複数UEMCLIPフレームは、送信者が単一のRTPパケットに含まれてもよいです。ただし、送信者は、次の追加の制限があります。

o A single RTP packet SHOULD NOT include more UEMCLIP frames than will fit in the path MTU.

単一のRTPパケットoをパスMTUに収まるよりも多くのUEMCLIPフレームを含むべきではありません。

o All frames contained in a single RTP packet MUST be of the same mode.

O単一のRTPパケットに含まれるすべてのフレームは同じモードでなければなりません。

o Frames MUST NOT be split between RTP packets.

OフレームはRTPパケットに分割してはなりません。

It is RECOMMENDED that the number of frames contained within an RTP packet be consistent with the application. Since UEMCLIP is designed for telephony applications where delay has a great impact on the quality, then fewer frames per packet for lower delay, is preferable.

RTPパケット内に含まれるフレームの数は、アプリケーションと一致することが推奨されます。 UEMCLIPは遅延が品質に大きな影響を有するテレフォニーアプリケーションのために設計されているため、より低遅延のためのパケットごと次いで少ないフレームが、好ましいです。

3.3. Payload Data
3.3. ペイロードデータ

In a UEMCLIP bitstream, all numbers are encoded in a network byte order.

UEMCLIPビットストリームでは、すべての数字は、ネットワークバイト順に符号化されています。

3.3.1. Main Header
3.3.1. メインヘッダ

The main header (MH) is placed at the top of a frame and has a size of 6 bytes. The content of the main header is shown in Figure 3.

メインヘッダ(MH)は、フレームの先頭に置き、6バイトのサイズを有しています。メインヘッダの内容は、図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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      MX       |                      PC                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          PC(cont'd)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 3: UEMCLIP Main Header Format (MH)

図3:UEMCLIPメインヘッダフォーマット(MH)

Mixing information (MX): 8 bits

8ビット:情報(MX)を混合

Mixing information field. This field is only relevant when Topo-RTCP-terminating-MCUs are utilized to interpret these fields. See Section 3.3.1.1 for details of the fields.

情報フィールドをミキシング。このフィールドは、TOPO-RTCP-着信のMCUは、これらのフィールドを解釈するために利用されている場合にのみ関連します。フィールドの詳細については、セクション3.3.1.1を参照してください。

Packet-loss Concealment information (PC): 40 bits

パケット損失隠蔽情報(PC):40ビット

Packet-loss concealment (PLC) information field. See Section 3.3.1.2.

パケット損失隠蔽(PLC)情報フィールド。 3.3.1.2項を参照してください。

3.3.1.1. Mixing Information Field
3.3.1.1。情報フィールドをミキシング
                            0 1 2 3 4 5 6 7
                           +-+-+-+-+-+-+-+-+
                           |C|R|V|   PW1   |
                           |1|1|1|         |
                           +-+-+-+-+-+-+-+-+
        

Figure 4: Mixing Information Field (MX)

図4:ミキシング情報フィールド(MX)

Check bit #1 (C1): 1 bit

チェックビット#1(C1):1ビット

Validity flag of V1 and PW1. This bit being "1" indicates that both parameters are valid, and "0" indicates that the parameters should be ignored. If any of these parameters is invalid, this bit should be set to "0". This flag is mainly intended for a UEMCLIP-conscious Topo-RTCP-terminating-MCU. This flag should be set to "0" in case of upward transcoding from G.711 (see Section 4).

V1とPW1の有効フラグ。このビットが「1」の両方のパラメータが有効であることを示し、「0」であることはパラメータは無視されるべきであることを示しています。これらのパラメータのいずれかが無効である場合、このビットは「0」に設定する必要があります。このフラグは主にUEMCLIP意識TOPO-RTCP-終端-MCUのために意図されています。このフラグはG.711から上方トランスコーディング(セクション4を参照)の場合には「0」に設定されるべきです。

Reserved bit #1 (R1): 1 bit

予約ビット#1(R1):1ビット

This bit should be ignored. The default of this bit is 0.

このビットは無視されるべきです。このビットのデフォルト値は0です。

VAD flag #1 (V1): 1 bit

WHATフラグ#1(V1):1個

Voice activity detection flag of the current frame, designed to be used for MCU operations. This flag being "1" indicates that the frame is an active (voice) segment, and "0" indicates that it is an inactive (non-voice) or a silent segment. This flag is specifically designed for mixing information. DTX judgment based this flag is not recommended.

MCUの動作のために使用されるように設計され、現在のフレームの音声アクティビティ検出フラグ。 「1」であるこのフラグは、フレームがアクティブ(音声)セグメントであることを示し、「0」は、それが非アクティブ(非音声)または無音区間であることを示しています。このフラグは、具体的に情報を混合するために設計されています。このフラグに基づくDTX判断は推奨されません。

Power #1 (PW1): 5 bits

電源#1(PW1):5ビット

Signal power code of the current frame. The code is obtained by calculating a root mean square (RMS) of "Layer a" and encoding this RMS using G.711 u-law [ITU-T-G.711]. Denoting the encoded RMS as R, then PW1 is obtained by PW1 = ((~R)>>2) & 0x1F, where "~", ">>", "&" are one's complement arithmetic, right SHIFT, and bitwise AND operators, respectively.

現在のフレームの信号パワーコード。コードは "A層" の平方(RMS)の平均平方根を計算し、これは[ITU-T-G.711]をG.711のU-法則を用いてRMS符号化することによって得られます。 Rとして符号化されたRMSを表す、次にPW1はPW1 =((〜R)>> 2)&0x1Fの、 "〜"、 ">>"、 "&" は1の補数演算、右シフト、およびビット単位であるANDによって得られます演算子、それぞれ。

3.3.1.2. PLC Information Field
3.3.1.2。 PLC情報フィールド
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|R2 |V|   K   |U|     P1      |U|     P2      |      PW2      |
   |2|   |2|       |1|             |2|             |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      R3       |
   |               |
   +-+-+-+-+-+-+-+-+
        

Figure 5: PLC Information Field (PC)

図5:PLC情報フィールド(PC)

Check bit #2 (C2): 1 bit

チェックビット#2(C2):1ビット

Validity flag of V2, K, U1, P1, U2, P2, and PW2. If the flag is "1", it means that all these parameters are valid, and "0" means that the parameters should be ignored. If any of these parameters is invalid, this bit should be set to "0". Similarly to C1, this flag should be set to "0" in case of upward transcoding from G.711 (see Section 4).

V2、K、U1、P1、U2、P2、及びPW2の有効フラグ。フラグが「1」であれば、それはこれらのすべてのパラメータが有効であることを意味し、「0」のパラメータは無視されるべきであることを意味しています。これらのパラメータのいずれかが無効である場合、このビットは「0」に設定する必要があります。同様C1に、このフラグはG.711(セクション4を参照)から上方トランスコーディングの場合には「0」に設定されるべきです。

Reserved bit #2 (R2): 2 bits

予約ビット#2(R2):2ビット

These bits should be ignored. The default of these bits are 0.

これらのビットは無視されるべきです。これらのビットのデフォルト値は0です。

VAD flag #2 (V2): 1 bit

WHATフラグ#2(V2):1個

Voice activity detection flag of the current frame, designed to be used for packet-loss concealment. This might not be the same as V1 in the mixing information, and might not be synchronous to the marker bit in the RTP header. DTX judgment based this flag is not recommended.

パケット損失隠蔽のために使用されるように設計された現在のフレームの音声アクティビティ検出フラグ。これは、ミキシング情報にV1と同じではないかもしれない、およびRTPヘッダ内のマーカビットに同期しないかもしれません。このフラグに基づくDTX判断は推奨されません。

Frame indicator (K): 4 bits

フレームインジケータ(K):4ビット

This value indicates the frame offset of U2, P2, and PW2. Since it is a better idea to carry the speech feature parameters as PLC information in a different frame to maintain the speech quality, this frame offset value gives with which frame the parameters are to be associated. The value ranges between "0" and "15". If the current frame number is N, for example, the value K indicates that U2, P2, and PW2 are associated with the frame of N-K. The frame indicator is equal to the difference in the RTP sequence number when one UEMCLIP frame is contained in a single RTP packet.

この値は、U2、P2、およびPW2のフレームオフセットを示します。それは音声品質を維持するために、異なるフレーム内のPLC情報として音声特徴パラメータを運ぶために良いアイデアであるため、このフレームオフセット値は、パラメータが関連すべきフレームに与えます。値が「0」と「15」の間の範囲です。現在のフレーム番号がNである場合、例えば、値Kは、U2、P2、及びPW2がN-Kのフレームに関連付けられていることを示しています。フレームインジケータは、一つUEMCLIPフレームは単一のRTPパケットに含まれるRTPシーケンス番号の差に等しいです。

V/UV flag #1 (U1): 1 bit

V / UVフラグ#1(U1):1ビット

Voiced/Unvoiced signal indicator of the current frame. This flag being "0" indicates that the frame is a voiced signal segment, and "1" indicates that it is an unvoiced signal segment.

現在のフレームの有声音/無声音信号インジケータ。 「0」フレームは有声信号セグメント、および「1」であることを示している、このフラグは、無声信号セグメントであることを示しています。

Pitch lag #1 (P1): 7 bits

ピッチラグ#1(P1):7ビット

Pitch code of the current frame. The actual pitch lag is calculated as P1+20 samples in 8-kHz sampling rate. Pitch lag must be 20 <= pitch length <= 120. Codes ranging between "0x65" and "0x7F" are not used. To obtain the pitch lag, any pitch estimation method can be used, such as the one used in G.711 Appendix I [Appendix I: A high quality low-complexity algorithm for packet loss concealment with G.711"">ITU-T-G.711Appendix1].

現在のフレームのピッチコード。実際のピッチラグは、8 kHzのサンプリングレートでP1 + 20サンプルとして算出されます。ピッチラグは、「0x65」および「から0x7F」が使用されていない間の範囲20 <=ピッチ長<= 120コードでなければなりません。 G.711のパケット損失隠蔽のための高品質低複雑性アルゴリズム「」> ITU-TG:ピッチラグを得るために、任意のピッチ推定方法は、G.711付録I [付録Iで使用されるものとして、使用することができます.711Appendix1]。

V/UV flag #2 (U2): 1 bit

V / UVフラグ#2(U2):1ビット

Voiced/Unvoiced signal indicator of the offset frame. This flag being "0" indicates that the frame is a voiced signal segment, and "1" indicates that it is an unvoiced signal segment. The offset value is defined as K.

オフセットフレームの有声音/無声音信号インジケータ。 「0」フレームは有声信号セグメント、および「1」であることを示している、このフラグは、無声信号セグメントであることを示しています。オフセット値は、Kのように定義されます

Pitch lag #2 (P2): 7 bits

ピッチラグ#2(P2):7ビット

Pitch code of the offset frame. The offset value is defined as K. The calculation method is identical to "P1", except that it is based on the signal of offset frame.

オフセットフレームのピッチコード。オフセット値算出方法は、それがフレームオフセットの信号に基づいていることを除いて、「P1」と同一であるK.として定義されます。

Power #2 (PW2): 8 bits

パワー#2(PW2):8ビット

Signal power code of the offset frame. The offset value is defined as K.

オフセットフレームの信号パワーコード。オフセット値は、Kのように定義されます

Reserved bits #3 (R3): 8 bits

予約ビット#3(R3):8ビット

These bits should be ignored. The default of all bits are "0".

これらのビットは無視されるべきです。すべてのビットのデフォルト値は「0」です。

3.3.2. Sub-Layer
3.3.2. サブレイヤ

Sub-layer (SL) is a sub-header followed by layer bitstreams, as shown in Figure 6. The sub-header indicates the layer location and the number of bytes.

サブ層(SL)は、サブヘッダは、層の位置及びバイト数を示し、図6に示すように、レイヤビットストリームに続いてサブヘッダーです。

     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 4 5 6 7   . . .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+
    |CI |FI |QI |R4 |      SB       |               LD         ...  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+
        

Figure 6: Sub-Layer Format (SL)

図6:サブ層フォーマット(SL)

Channel index (CI): 2 bits

チャネル・インデックス(CI):2ビット

Indicates the channel number. For all modes given in Table 2, this should be "0". The detail is given in Table 3.

チャンネル番号を示します。表2に与えられたすべてのモードでは、これは「0」である必要があります。詳細は表3に示されています。

Frequency index (FI): 2 bits

周波数インデックス(FI):2ビット

Indicates the frequency number. "0" means that the layer is in the base frequency band, higher number means that the layer is in respective frequency band. The detail is given in Table 3.

周波数番号を示します。 「0」は、層が、ベース周波数帯であることを意味し、より高い数の層がそれぞれの周波数帯域であることを意味します。詳細は表3に示されています。

Quality index (QI): 2 bits

品質指標(QI):2ビット

Indicates the quality layer number. "0" means that the layer is in the base layer, and higher number means that the layer is in respective quality layer. The detail is given in Table 3.

質の層の数を示します。 「0」は、層が、ベース層であることを意味し、より高い数の層がそれぞれの品質層であることを意味します。詳細は表3に示されています。

Reserved #4 (R4): 2 bits

予約#4(R4):2ビット

Not used (reserved). The default value is "0".

(予約済み)使用されていません。デフォルト値は「0」です。

Sub-layer Size (SB): 8 bits

サブ層サイズ(SB):8ビット

Indicates the byte size of the following sub-layer data.

以下のサブレイヤデータのバイトサイズを示します。

Layer Data (LD): SB*8 bits

レイヤのデータ(LD):SB * 8ビット

The actual sub-layer data.

実際のサブレイヤデータ。

For all the layers shown in Table 1, the layer indices are shown in Table 3.

表1に示す全ての層は、層インデックスを表3に示します。

                         +-------+----+----+----+
                         | Layer | CI | FI | QI |
                         +-------+----+----+----+
                         |   a   |  0 |  0 |  0 |
                         |       |    |    |    |
                         |   b   |  0 |  0 |  1 |
                         |       |    |    |    |
                         |   c   |  0 |  1 |  0 |
                         +-------+----+----+----+
        

Table 3: Layer Indices

表3:レイヤーのインデックス

4. Transcoding between UEMCLIP and G.711
UEMCLIPとG.711の間に4トランスコーディング

As given in Section 2, the u-law-encoded G.711 bitstream (Layer a) is the core layer of a UEMCLIP bitstream, and is always embedded. This means that media transcoding from the UEMCLIP bitstream to G.711 does not have to undergo decoding and re-encoding procedures, but simple extraction would suffice. However, this does not apply for the reverse procedure, i.e., transcoding from G.711 to UEMCLIP, because the auxiliary information in the main header (MH) must be assigned separately. It should be noted that this media transcoding is useful for a Media Translator (Topo-Media-Translator) or a Point-to-Multipoint Using RTCP Terminating MCU (Topo-RTCP-terminating-MCU) in [RFC5117], and all the requirements apply. This means that a transcoding device of this sort MUST rewrite RTCP packets, together with the RTP media packets.

第2に示すように、U-lawの符号化されたG.711ビットストリーム(層A)はUEMCLIPビットストリームのコア層であり、常に埋め込まれています。これはUEMCLIPビットストリームからG.711へのメディアトランスコーディングはデコードと再エンコード手続きを経る必要はありませんが、簡単な抽出が十分であることを意味します。メインヘッダ(MH)中の補助情報を別々に割り当てなければならないのでしかし、これは、G.711からUEMCLIPにトランスコード、すなわち、逆の手順のために適用されません。このメディアトランスコーディングは、メディアトランスレータ(トポ・メディア・翻訳)またはポイントツーマルチポイント[RFC5117]でRTCP終端MCU(TOPO-RTCP-終端-MCU)を使用して、すべての要件のために有用であることに留意すべきです適用されます。これは、この種のトランスコーディングデバイスは、RTPメディアパケットとともに、RTCPパケットを書き換えなければならないことを意味します。

The transcoding from UEMCLIP to u-law G.711 can be done easily by finding an appropriate sub-layer. Within a frame, the transcoder should look for a sub-layer with a layer index of "0x00", and subsequent LD that has a size of SB*8 bits (UEMCLIP has a 20-ms frame thus, SB=160) are the actual G.711 bitstream data. It should be noted that the transcoder should not always expect the core layer to be located right after the main header.

UEMCLIPからU-lawのG.711へのトランスコーディングは、適切なサブ層を見つけることによって容易に行うことができます。フレーム内で、トランスコーダは、SB * 8ビットの大きさを有する層「0×00」のインデックス、およびその後のLD(UEMCLIPは、このように20ミリ秒のフレームを有し、= 160 SB)であると副層になるはず実際のG.711ビットストリームデータ。トランスコーダは、常にコア層は右メインヘッダの後に配置されることを期待してはならないことに留意すべきです。

On the other hand, the transcoding from G.711 to UEMCLIP is not entirely straightforward. Since there are no means to generate enhancement sub-layers, a G.711 bitstream can only be converted to UEMCLIP Mode 0 bitstream. If the original G.711 bitstream is encoded in A-law, it should first be converted to u-law to become the core layer. Because a UEMCLIP frame size is 20 ms, a u-law-encoded G.711 bitstream MUST be a 160-sample chunk to become a core layer. For the main header contents, when the UEMCLIP encoder is not available, it should follow these guidelines:

一方、G.711からUEMCLIPへのトランスコードは完全に簡単ではありません。エンハンスメント・サブレイヤを生成する手段がないため、G.711ビットストリームのみUEMCLIPモード0ビットストリームに変換することができます。元のG.711ビットストリームを則で符号化されている場合は、第一のコア層になるようにU字法則に変換されなければなりません。 UEMCLIPフレームサイズが20ミリ秒であるため、U-法則エンコードG.711ビットストリームは、コア層になるように160サンプルのチャンクでなければなりません。メインヘッダの内容については、UEMCLIPエンコーダが使用できない場合、それはこれらのガイドラインに従うべきです。

o The check bits for mixing and PLC (C1 and C2) are set to 0.

混合及びPLC(C1及びC2)が0に設定されているためチェックビットO。

o The reserved bits (R1 to R3) in MH are set to respective default values.

O MH内の予約ビット(R3にR1)をそれぞれのデフォルト値に設定されています。

For the core layer (i.e., u-law G.711 bitstream), it should have the following sub-layer header:

コア層(即ち、U法則G.711ビットストリーム)の場合は、次のサブ層ヘッダを有するべきです。

o All CI, FI, QI, and R4 MUST be 0.

OすべてのCI、FI、QI、及びR4は0でなければなりません。

o Sub-layer size (SB) MUST be 160 for a 20-ms frame.

Oサブ層のサイズ(SB)は、20ミリ秒のフレーム160でなければなりません。

5. Congestion Control Considerations
5.輻輳制御に関する注意事項

The general congestion control considerations for transporting RTP data also apply to UEMCLIP over RTP [RFC3550] as well as any applicable RTP profile like Audio-Visual Profile (AVP) [RFC3551].

RTPデータを転送するための一般的な輻輳制御の考慮もRTP [RFC3550]だけでなく、オーディオビジュアルのプロフィールのような任意の適用可能なRTPプロファイル(AVP)[RFC3551]の上にUEMCLIPに適用されます。

The bandwidth of a UEMCLIP bitstream can be reduced by changing to lower-bit-rate modes. The embedded layer structure of UEMCLIP may help to control congestion, when dynamic mode changing (see Section 6.2.1) is available, and the range of modes is obtained by offer-answer negotiation as given in Section 6.3. It should be noted that this involves proper RTCP handling when the bit-rate is modified in an RTP translator or a mixer [RFC3550].

UEMCLIPビットストリームの帯域幅は、より低いビットレートのモードに変更することによって低減することができます。 UEMCLIPの埋め込み層構造は、ダイナミックモードが変化した場合に、輻輳を制御するのに役立つことができる(セクション6.2.1を参照)が使用可能であり、セクション6.3で与えられるモードの範囲が提供アンサーネゴシエーションにより得られます。ビットレートがRTPトランスレータやミキサー[RFC3550]に変更されたとき、これは、適切なRTCP処理を含むことに留意すべきです。

Packing more frames in each RTP payload can reduce the number of packets sent, and hence the overhead from IP/UDP/RTP headers, at the expense of increased delay and reduced error robustness against packet losses. It should be treated with care because increased delay means reduced quality.

各RTPペイロードに複数のフレームを充填するパケット損失に対する増加遅延および減少エラー耐性を犠牲にして、IP / UDP / RTPヘッダから送信されたパケットの数、したがってオーバーヘッドを低減することができます。遅延の増加が減少した品質を意味するので、それは注意して扱われるべきです。

6. Payload Format Parameters
6.ペイロードフォーマットのパラメータ
6.1. Media Type Registration
6.1. メディアタイプ登録

This registration is done using the template defined in [RFC4288] and following [RFC4855].

この登録は[RFC4288]で定義されたテンプレートを使用して、[RFC4855]以下で行われます。

Media type name: audio

メディアタイプ名:オーディオ

Media subtype name: UEMCLIP

メディアサブタイプ名:UEMCLIP

Required parameters:

必須パラメータ:

Rate: Defines the sampling rate, and it MUST be either 8000 or 16000. See Section 6.2.1 "Mode specification" of RFC 5686 (this RFC) for details.

レート:サンプリングレートを定義し、それは詳細についてはRFC 5686(このRFC)のどちらか8000または16000を参照してください6.2.1項「モードの​​指定」でなければなりません。

Optional parameters:

オプションのパラメータ:

ptime: See RFC 4566 [RFC4566].

PTIME:RFC 4566 [RFC4566]を参照してください。

maxptime: See RFC 4566 [RFC4566].

maxptime:RFC 4566 [RFC4566]を参照してください。

mode: Indicates the range of dynamically changeable modes during a session. Possible values are a comma-separated list of modes from the supported mode set: 0, 1, 3, and 4. If only one mode is specified, it means that the mode must not be changed during the session. When not specified, the mode transmission defaults to a singular mode as specified in Table 4. See Section 6.2.1 "Mode specification" of RFC 5686 (this RFC) for details.

モード:セッション中に動的に変更モードの範囲を示します。可能な値はサポートされているモード設定からモードのコンマ区切りのリストである:一つのモードを指定した場合は0、1、3、および4は、モードがセッション中に変更されてはならないことを意味します。指定しない場合、特異モードに伝送デフォルトは、詳細はRFC 5686(このRFC)の表4を参照のセクション6.2.1「モード指定」で指定されるように。

Encoding considerations: This media type is framed and contains binary data. See Section 4.8 of RFC 4288.

エンコードの考慮事項:このメディアタイプは、フレームとバイナリデータが含まれています。 RFC 4288のセクション4.8を参照してください。

Security considerations: See Section 7 "Security Considerations" of RFC 5686 (this RFC).

セキュリティに関する考慮事項:RFC 5686のセクション7「セキュリティに関する考慮事項」(このRFC)を参照してください。

Interoperability considerations: This media may be readily transcoded to u-law-encoded ITU-T G.711. See Section 4 "Transcoding between UEMCLIP and G.711" of RFC 5686 (this RFC).

相互運用性の考慮:このメディアは容易にU-法則でエンコードされたITU-T G.711にトランスコードすることができます。 RFC 5686(このRFC)の第4節 "UEMCLIPとG.711の間のトランスコーディング" を参照してください。

Published specification: RFC 5686 (this RFC)

公開された仕様:RFC 5686(このRFC)

Applications that use this media type: Audio and video streaming and conferencing tools.

オーディオとビデオストリーミングと会議ツール:このメディアタイプを使用するアプリケーション。

Additional information: None

追加情報:なし

Intended usage: COMMON

意図している用法:COMMON

Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP.

使用上の制限:このメディアタイプは、RTPを介してRTPフレーミングに依存し、したがってのみ転送のために定義されています。

Person & email address to contact for further information: Yusuke Hiwasaki <hiwasaki.yusuke@lab.ntt.co.jp>

人とEメールアドレスは、詳細のために連絡する:祐介Hiwasaki <hiwasaki.yusuke@lab.ntt.co.jp>

Author: Yusuke Hiwasaki

あうてょr: ゆすけ ひわさき

Change Controller: IETF Audio/Video Transport Working Group delegated from the IESG

変更コントローラ:IETFオーディオ/ビデオ輸送ワーキンググループIESGから委任

6.2. Mapping to SDP Parameters
6.2. SDPパラメータへのマッピング

The media types audio/UEMCLIP are mapped to fields in the Session Description Protocol (SDP) [RFC4566] as follows:

次のようにメディアタイプオーディオ/ UEMCLIPは、セッション記述プロトコル(SDP)内のフィールドに[RFC4566]をマッピングされます。

Media name: The "m=" line of SDP MUST be audio.

メディア名:SDPの「M =」の行は、オーディオでなければなりません。

Encoding name: Registered media subtype name should be used for the "a=rtpmap" line.

名前エンコード:登録メディアサブタイプ名は「A = rtpmap」行のために使用されるべきです。

Sampling Frequency: Depending on the mode, clock rate (sampling frequency) specified in "a=rtpmap" MUST be selected from the ones defined in Table 2. See Section 6.2.1 for details.

サンプリング周波数:モードの「a = rtpmap」で指定された、クロック・レート(サンプリング周波数)に応じて、詳細については表2を参照のセクション6.2.1で定義されたものの中から選択しなければなりません。

Encoding parameters: Since this is an audio stream, the encoding parameters indicate the number of audio channels, and this SHOULD default to "1", as selected from the ones defined in Table 2. This is OPTIONAL.

符号化パラメータ:これはオーディオストリームであるので、符号化パラメータは、オーディオチャンネルの数を示し、これはオプションであり、表2に定義されたものの中から選択され、これは、「1」をデフォルトとすべきです。

Packet time: A frame length of any UEMCLIP is 20 ms, thus the argument of "a=ptime" SHOULD be a multiple of "20". When not listed in SDP, it should also default to the minimum size: "20".

パケット時間:任意UEMCLIPのフレーム長は、従って、「A = PTIME」の引数が「20」の倍数でなければならず、20ミリ秒です。 「20」:SDPに記載されていない場合には、それはまた、最小サイズをデフォルトにする必要があります。

UMECLIP specific: Any description specific to UEMCLIP is defined in the Format Specification Parameters ("a=fmtp"). Each parameter MUST be separated with ";", and if any attribute (value) exists, it MUST be defined with "=". For compatibility reasons, any application/terminal MUST ignore any parameters that it does not understand. This is to ensure the upper-compatibility with parameters added in future enhancements. The mode specification should be made here (see Section 6.2.1).

UMECLIP特定:UEMCLIPに固有の説明は、フォーマット仕様のパラメータ(「A =のfmtp」)で定義されています。 、および任意の属性(値)が存在する場合、それは「=」で定義する必要があり、「」各パラメータを用いて分離しなければなりません。互換性の理由から、任意のアプリケーション/端末は、それが理解していないすべてのパラメータを無視しなければなりません。これは、将来の拡張に追加パラメータを用いて上位互換性を確保することです。モードの指定は、(6.2.1項を参照)、ここでなされるべきです。

6.2.1. Mode Specification
6.2.1. モードの仕様

Since UEMCLIP codec can operate in number of modes (bit-rates), it is desirable to specify the range of modes at which an encoder or a decoder can operate. When exchanging SDP messages, an offerer should specify all possible combinations of mode numbers as arguments to "mode=" in "a=fmtp" line, delimited by commas ",". In case of specifying multiple modes, those SHOULD appear in the descending priority order.

UEMCLIPコーデックモード(ビットレート)の数で動作することができるので、エンコーダまたはデコーダが動作可能なモードの範囲を指定することが望ましいです。 SDPメッセージを交換する場合、提供者は「」カンマで区切られ、「A =のfmtp」の行では、「モード=」の引数として、モード番号のすべての可能な組み合わせを指定する必要があります。複数のモードを指定する場合には、それらは、降順の優先度順に表示されます。

Although UEMCLIP decoders SHOULD accept bitstreams in any modes, an implementation may fail to adapt to the dynamic mode changes during a session. For this reason, an application may choose to operate either with one fixed mode or with multiple modes that can be dynamically changed. If the mode is to be fixed and changes are not allowed, this can be indicated by specifying a single mode per payload type.

UEMCLIPデコーダが任意のモードでビットストリームを受け入れるべきであるが、実装は、セッション中に動的モードの変化に適応できない場合があります。この理由のため、アプリケーションは、1つの固定モードまたは動的に変更することができる複数のモードのいずれかで動作するように選択することができます。モードが固定されると変更が許可されていない場合、これはペイロードタイプごとに単一のモードを指定することによって示すことができます。

The mode numbers that can be specified in a payload type as arguments to "mode" are restricted by a combination of a clock rate and a number of audio channels. This is because SDP binds a payload type to a combination of a sampling frequency and a number of audio channels. Table 4 gives selectable mode numbers that are attributed with clock rates. When mode specifications are not given at all, a payload type MUST default to a single mode using the default value specified in this table.

「モード」の引数としてペイロードタイプで指定できるモードの数は、クロックレートの組み合わせ及びオーディオチャネルの数によって制限されます。 SDPは、サンプリング周波数及びオーディオチャネルの数の組み合わせにペイロードタイプに結合するためです。表4は、クロック・レートで起因する選択可能なモード番号を提供します。モードの仕様が全く与えられていない場合には、ペイロードタイプは、この表で指定されたデフォルト値を使用して、単一モードをデフォルトとしなければなりません。

        +------------+----------+------------------+--------------+
        | Clock rate | Channels | Selectable modes | Default mode |
        +------------+----------+------------------+--------------+
        |       8000 |     1    |        0,3       |       0      |
        |            |          |                  |              |
        |      16000 |     1    |      0,1,3,4     |       1      |
        +------------+----------+------------------+--------------+
        

Table 4: Default Modes

表4:デフォルトのモード

It should be noted that a mode attributed with a larger sampling frequency (Fs) is not used in conjunction with smaller clock rates specified in "a=rtpmap". This means that Modes 0 and 3 can be specified in a payload type having a clock rate of both 8000 and 16000 in "a=rtpmap", but Modes 1 and 4 cannot be specified with one having a clock rate of 8000.

より大きなサンプリング周波数(FS)と帰属モードが「A = rtpmap」で指定されたより小さなクロック・レートに関連して使用されていないことに留意すべきです。これは、モード0及び3の「a = rtpmap」に8000と16000の両方のクロック・レートを有するペイロードタイプに指定することができるが、モード1および4は8000のクロックレートを有するものと指定することはできないことを意味します。

6.3. Offer-Answer Model Considerations
6.3. オファー回答モデルの考慮事項
6.3.1. Offer-Answer Guidelines
6.3.1. オファー回答ガイドライン

The procedures related to exchanging SDP messages MUST follow [RFC3264]. The following is a detailed list on the semantics of using the UEMCLIP payload format in an offer-answer exchange.

SDPメッセージを交換することに関連する手順は、[RFC3264]を従わなければなりません。以下は、オファーアンサー交換でUEMCLIPペイロードフォーマットを使用しての意味論上の詳細なリストです。

o An offerer SHOULD offer every possible combination of UEMCLIP payload type it can handle, i.e., sampling frequency, channel number, and fmtp parameters, in a preferred order. When the transmission bandwidth is restricted, it MUST be offered in accordance to the restriction.

O申出は、好ましい順に、それが処理できるUEMCLIPペイロードタイプ、即ち、サンプリング周波数、チャンネル数、及びのfmtpパラメータのすべての可能な組み合わせを提供するべきです。伝送帯域が制限されている場合は、制限に基づいて提供されなければなりません。

o When multiple UEMCLIP payload types are offered, it is RECOMMENDED that the answerer select a single UEMCLIP payload type and answer it back.

複数UEMCLIPペイロードタイプが提供されている場合は、O、回答が単一UEMCLIPペイロードタイプを選択して、戻ってそれに答えることが推奨されます。

o In a UEMCLIP payload type, an answerer MUST answer back suitable mode number(s) as a subset of what has been offered. This means that there is a symmetry assumption on sent and received streams, and the offerer MUST NOT send in modes that it does not offer.

O UEMCLIPペイロードタイプでは、回答者は、提供されたもののサブセットのような適切なモード番号(複数可)をバック答えなければなりません。これは送信され、受信されたストリーム上の対称性の仮定があることを意味し、オファー側はそれを提供しないモードで送ってはいけません。

o In an offering/answering SDP, any fmtp parameters that are not known MUST be ignored. If any unknown/undefined parameters should be offered, an answerer MUST delete the entry from the answer message.

O製品/応答SDPは、知られていない任意のfmtpパラメータは無視されなければなりません。未知/未定義のパラメータが提供されなければならない場合、回答は応答メッセージからエントリを削除しなければなりません。

o A receiver of an SDP message MUST only use specified payload types and modes. When a mode specification is missing, i.e., a mode is not specified at all, the session MUST default to one single mode without mode changes during a session. For this case, the default mode values, as shown in Table 4, MUST be used based on the sampling frequency and number of channels. This table must be looked up only when there are no mode specifications; thus, the offerer/answerer MUST NOT assume that the default modes are always available when it is not in the specified list of modes.

O SDPメッセージの受信機は、指定されたペイロードタイプとモードを使用しなければなりません。モードの指定が欠落している場合、すなわち、モードが全く指定されていない、セッションは、セッション中にモードを変更することなく、1つのモードをデフォルトとしなければなりません。この場合、デフォルトモード値は、表4に示すように、サンプリング周波数及びチャネルの数に基づいて使用されなければなりません。この表にはモードの仕様が存在しない場合にのみ、見上げなければなりません。このように、オファー側/アンサーは、モードの指定のリストにない場合、デフォルトモードは常に利用可能であると仮定してはいけません。

o When an offered condition does not fit an answerer's capabilities, it naturally MUST NOT answer any of the conditions, and the session MAY proceed to re-INVITE, if possible. If a condition (mode) is decided upon, an offerer and an answerer MUST transmit on this condition.

提供条件は、回答者の能力に適合しない場合は、O、それは当然の条件のいずれかを答えてはならない、とのセッションは、可能な場合は、再INVITEに進むことができます。状態(モード)の際に決定された場合、提供者及び回答は、この状態で送信しなければなりません。

6.3.2. Examples
6.3.2. 例

When an offerer indicates that he/she wishes to dynamically switch between modes (0,1,3, and 4) during a session, an example of an offered SDP could be:

提供者は、彼/彼女が動的セッション中のモード(0,1,3、及び4)との間で切り替えることを望むことを示す場合、提供されるSDPの例は次のようになります。

v=0 o=john 51050101 51050101 IN IP4 offhost.example.com s=- c=IN IP4 offhost.example.com t=0 0 m=audio 5004 RTP/AVP 96 a=rtpmap:96 UEMCLIP/16000/1 a=fmtp:96 mode=4,1,3,0

V = 0 0 =ジョン51050101 51050101 IN IP4 offhost.example.com S = - C = IN IP4 offhost.example.com T = 0、M =オーディオ5004 RTP / AVP 96 = rtpmap:96 UEMCLIP / 1分の16000 =のfmtp:96モード= 4,1,3,0

It should be noted that the listed modes appears in the offerer's preference.

リストされているモードは、オファー側の好みに現れることに留意すべきです。

When an answerer can only operate in Modes 1 and 0 but can dynamically switch between those modes during a session, an answerer MUST delete the entries of Mode 3 and 4, and answer back as:

回答は、モード1と0で動作することができる場合には、動的セッション中にこれらのモードを切り替えることができ、回答は、モード3及び4のエントリを削除し、そしてようにアンサーバックしなければなりません。

v=0 o=lena 549947322 549947322 IN IP4 anshost.example.org s=- c=IN IP4 anshost.example.org t=0 0 m=audio 5004 RTP/AVP 96 a=rtpmap:96 UEMCLIP/16000/1 a=fmtp:96 mode=1,0

V = 0 0 =レナ549947322 549947322 IN IP4 anshost.example.org S = - C = IN IP4 anshost.example.org T = 0、M =オーディオ5004 RTP / AVP 96 = rtpmap:96 UEMCLIP / 1分の16000 =のfmtp:96モード= 1,0

As a result, both would start communicating in either Mode 1 or 0, and can dynamically switch between those modes during the session.

結果として、両方のモード1または0のいずれかで通信を開始すると、動的セッション中にこれらのモードを切り替えることができます。

On the other hand, when the answerer is capable of communicating either in Modes 1 or 0, and cannot switch between modes during a session, an example of such answer is as follows:

次のように回答がモード1または0のいずれかで通信可能であり、セッション中にモードを切り替えることができない一方、そのような答えの例があります。

v=0 o=lena 549947322 549947322 IN IP4 anshost.example.org s=- c=IN IP4 anshost.example.org t=0 0 m=audio 5004 RTP/AVP 96 a=rtpmap:96 UEMCLIP/16000/1 a=fmtp:96 mode=1

V = 0 0 =レナ549947322 549947322 IN IP4 anshost.example.org S = - C = IN IP4 anshost.example.org T = 0、M =オーディオ5004 RTP / AVP 96 = rtpmap:96 UEMCLIP / 1分の16000 =のfmtp:96モード= 1

As a result, both will start communicating in Mode 1. It should be noted that mode change during this session is not allowed because the answerer responded with a single mode, and answerer selected Mode 1 above Mode 0 according to the offered order.

結果として、両方のは、回答を提供するために応じてモード0の上方にモード1の選択された単一モード、及び回答で応答するので、このセッション中にモード変更が許可されていないことに留意すべきであるモード1で通信を開始します。

If an offerer does not want a mode change during a session but is capable of receiving either Modes 4 or 1 bitstreams, the SDP should somewhat look like:

オファー側は、セッション中にモード変更をしたいが、モード4または1ビットストリームのいずれかを受信することが可能であるしない場合は、SDPは、多少のようになります。

v=0 o=john 51050101 51050101 IN IP4 offhost.example.com s=- c=IN IP4 offhost.example.com t=0 0 m=audio 5004 RTP/AVP 96 97 a=rtpmap:96 UEMCLIP/16000/1 a=fmtp:96 mode=4 a=rtpmap:97 UEMCLIP/16000/1 a=fmtp:97 mode=1

V = 0 0 =ジョン51050101 51050101 IN IP4 offhost.example.com S = - C = IN IP4 offhost.example.com T = 0、M =オーディオ5004 RTP / AVP 96 97 = rtpmap:96 UEMCLIP / 1分の16000 =のfmtp:96モード= 4 A = rtpmap:97 UEMCLIP / 1分の16000 A =のfmtp:97モード= 1

and if the answerer prefers to communicate in Mode 1, an answer would be:

回答は、モード1で通信することを好む場合と、答えは次のようになります。

v=0 o=lena 549947322 549947322 IN IP4 anshost.example.org s=- c=IN IP4 anshost.example.org t=0 0 m=audio 5004 RTP/AVP 97 a=rtpmap:97 UEMCLIP/16000/1 a=fmtp:97 mode=1

V = 0 0 =レナ549947322 549947322 IN IP4 anshost.example.org S = - C = IN IP4 anshost.example.org T = 0、M =オーディオ5004 RTP / AVP 97 = rtpmap:97 UEMCLIP / 1分の16000 =のfmtp:97モード= 1

Please note that it is RECOMMENDED to select a single UEMCLIP payload type for answers.

答えのための単一のUEMCLIPペイロードタイプを選択することをお勧めしますのでご注意ください。

The "ptime" attribute is used to denote the desired packetization interval. When not specified, it SHOULD default to 20. Since UEMCLIP uses 20-ms frames, ptime values of multiples of 20 imply multiple frames per packet. In the example below, the ptime is set to 60, and this means that offerer wants to receive 3 frames in each packet.

「PTIME」属性は、所望のパケット化間隔を示すために使用されます。指定されない場合UEMCLIPは、20ミリ秒のフレームを使用するので、それは20をデフォルトSHOULD、20の倍数のPTIME値は、パケットごとに複数のフレームを意味します。以下の例では、PTIMEは60に設定され、これは、申し出は、各パケットに3つのフレームを受信したいことを意味しています。

v=0 o=kosuke 2890844730 2890844730 IN IP4 anotherhost.example.com s=- c=IN IP4 anotherhost.example.com t=0 0 m=audio 5004 RTP/AVP 96 a=ptime:60 a=rtpmap:96 UEMCLIP/16000/1

V = 0 0 =浩輔2890844730 2890844730 IN IP4 anotherhost.example.com S = - C = IN IP4 anotherhost.example.com T = 0、M =オーディオ5004 RTP / AVP 96 = PTIME:60 = rtpmap:96 UEMCLIP / 1分の16000

When mode specification is not present, it should default to a fixed mode, and in this case, Mode 1 (see Section 6.2.1).

モード指定が存在しない場合、それは固定モードにデフォルト設定する必要があり、この場合には、モード1(セクション6.2.1を参照します)。

7. Security Considerations
7.セキュリティの考慮事項

RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and any appropriate profiles. This implies that confidentiality of the media streams is achieved by encryption unless the applicable profile specifies other means.

本明細書で定義されたペイロードフォーマットを使用して、RTPパケットは、RTP仕様[RFC3550]と、任意の適切なプロファイルで議論したセキュリティ問題を受けることです。これは、該当するプロファイルは、他の手段を指定しない限り、メディアストリームの機密性は、暗号化によって達成されることを意味します。

A potential denial-of-service threat exists for data encoding using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream that are complex to decode and cause the receiver output to become overloaded. However, the UEMCLIP covered in this document do not exhibit any significant non-uniformity.

潜在的なサービス拒否の脅威は、不均一な受信端計算負荷を有する圧縮技術を用いて、データ符号化のために存在します。攻撃者が復号器と受信器出力が過負荷になることを引き起こすのに複雑であり、ストリーム内の病理学的データグラムを注入することができます。しかし、本書で取り上げUEMCLIPは、有意な不均一性を示しません。

Another potential threat is memory attacks by illegal layer indices or byte numbers. The implementor of the decoder should always be aware that the indicated numbers may be corrupted and not point to the right sub-layer, and they may force reading beyond the bitstream boundaries. It is advised that a decoder implementation reject layers of such indices.

別の潜在的な脅威は違法層のインデックスまたはバイト数によってメモリ攻撃です。デコーダの実装は、常に表示された数字が破損し、右側のサブ層を指していてもよいことに注意する必要があり、それらは、ビットストリームの境界を越えて読み取りを強制することができます。デコーダの実装では、指標の層を拒否することをお勧めします。

8. IANA Considerations
8. IANAの考慮事項

One new media subtype (audio/UEMCLIP) has been registered by IANA. For details, see Section 6.1.

一つの新しいメディアサブタイプ(オーディオ/ UEMCLIP)はIANAによって登録されています。詳細については、6.1節を参照してください。

9. References
9.参考文献
9.1. Normative References
9.1. 引用規格

[ITU-T-G.711] International Telecommunications Union, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988.

[ITU-T G.711-]国際電気通信連合、 "パルス符号変調(PCM)音声周波数の"、ITU-T勧告G.711、1988年11月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル(SDP)とのオファー/アンサーモデル"。

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP:リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。

[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.

[RFC3551] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。

[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

[RFC4288]解放され、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP:セッション記述プロトコル"、RFC 4566、2006年7月。

[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.

[RFC4855] Casner、S.、RFC 4855、2007年2月 "RTPペイロード形式のメディアタイプ登録"。

[RFC4856] Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, February 2007.

[RFC4856] Casner、S.、「オーディオおよびビデオ会議用RTPプロファイルにおけるペイロード形式のメディアタイプ登録」、RFC 4856、2007年2月。

[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.

[RFC5117]ウェスター、M.とS.ベンゲル監督、 "RTPトポロジ"、RFC 5117、2008年1月。

9.2. Informative References
9.2. 参考文献

[ITU-T-G.711Appendix1] International Telecommunications Union, "Pulse code modulation (PCM) of voice frequencies, Appendix I: A high quality low-complexity algorithm for packet loss concealment with G.711", ITU-T Recommendation G.711 Appendix I, September 1999.

[ITU-TG.711Appendix1]国際電気通信連合、「音声周波数のパルス符号変調(PCM)、付録I:G.711とパケット損失隠蔽のための高品質低複雑アルゴリズム」、ITU-T勧告G.711付録I、1999年9月。

Authors' Addresses

著者のアドレス

Yusuke Hiwasaki NTT Corporation 3-9-11 Midori-cho, Musashino-shi Tokyo 180-8585 Japan

ゆすけ ひわさき んっt こrぽらちおん 3ー9ー11 みどりーちょ、 むさしのーし ときょ 180ー8585 じゃぱん

Phone: +81(422)59-4815 EMail: hiwasaki.yusuke@lab.ntt.co.jp

電話:+81(422)59から4815 Eメール:hiwasaki.yusuke@lab.ntt.co.jp

Hitoshi Ohmuro NTT Corporation 3-9-11 Midori-cho, Musashino-shi Tokyo 180-8585 Japan

ひとし おhむろ んっt こrぽらちおん 3ー9ー11 みどりーちょ、 むさしのーし ときょ 180ー8585 じゃぱん

Phone: +81(422)59-2151 EMail: ohmuro.hitoshi@lab.ntt.co.jp

電話:+81(422)59から2151 Eメール:ohmuro.hitoshi@lab.ntt.co.jp