RFC 6354 - Forward-Shifted RTP Redundancy Payload Support 日本語訳

URL : https://tools.ietf.org/html/rfc6354
タイトル : RFC 6354 - フォワード・シフトRTP冗長性ペイロードのサポート
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                            Q. Xie
Request for Comments: 6354                                   August 2011
Updates: 2198, 4102
Category: Standards Track
ISSN: 2070-1721

             Forward-Shifted RTP Redundancy Payload Support

Abstract

抽象

This document defines a simple enhancement to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media).

この文書では、順方向シフト冗長符号化方式、対応するプライマリ・データの前に送信され、すなわち、冗長データとRTPセッションをサポートするための簡単な拡張を定義します。順方向シフト冗長性（秒またはメディアの秒であっても数十例えば、連続損失）の連続するメディアフレームの多数の損失を隠蔽するために使用することができます。

Status of This Memo

このメモのステータス

This is an Internet Standards Track document.

これは、インターネット標準化過程文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6354.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6354で取得することができます。

著作権表示

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

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

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

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. Sending Redundant Data Inband vs. Out-of-Band ..............3
   2. Conventions .....................................................4
   3. Allowing Forward-Shifted Redundant Data .........................4
   4. Registration of Media Type "fwdred" .............................5
   5. Mapping Media Type Parameters into SDP ..........................7
   6. Usage in Offer/Answer ...........................................7
   7. IANA Considerations .............................................7
   8. Security Considerations .........................................8
   9. Normative References ............................................8
   Appendix A. Anti-Shadow Loss Concealment Using
               Forward-Shifted Redundancy .............................9
      A.1. Sender-Side Operations .....................................9
      A.2. Receiver-Side Operations ..................................11
         A.2.1. Normal-Mode Operation ................................11
         A.2.2. Anti-Shadow-Mode Operation ...........................12

1. Introduction

1. はじめに

This document defines a simple enhancement to RFC 2198 [RFC2198] to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data.

この文書では、順方向シフト冗長符号化方式、対応するプライマリ・データの前に送信され、すなわち、冗長データとRTPセッションをサポートするために、RFC 2198 [RFC2198]に簡単な拡張を定義します。

Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds of media). Such capability is highly desirable, especially in wireless mobile communication environments where the radio signal to a mobile wireless media receiver can be temporarily blocked by tall buildings, mountains, tunnels, etc. In other words, the receiver enters into a shadow of the radio coverage. No new data will be received when the receiver is in a shadow.

順方向シフト冗長性（メディアの秒例えば、連続損失）の連続するメディアフレームの多数の損失を隠蔽するために使用することができます。そのような能力は、特にモバイルワイヤレスメディア受信機への無線信号が一時的に言い換えると高層ビル、山、トンネル、等によって遮断することができ、受信機は、無線カバレッジの影に入る無線モバイル通信環境において、非常に望ましいです。受信機が影にあるときに新しいデータが受信されません。

In some extreme cases, the receiver may have to spend seconds or even tens of seconds in a shadow. The traditional backward-shifted redundant encoding scheme (i.e., redundant data is sent after the primary data), as currently supported by RFC 2198 [RFC2198], does not address such consecutive frame losses.

いくつかの極端な例では、受信機は、影に秒の秒あるいは数十を費やす必要があります。現在RFC 2198でサポートされている伝統的な逆方向シフト冗長符号化方式（すなわち、冗長データをプライマリ・データの後に送信される）、[RFC2198]は、そのような連続的なフレームの損失に対処していません。

In contrast, the forward-shifted redundancy scheme allows one to apply effective anti-shadow loss management at the receiver (as illustrated in Appendix A), thus preventing service interruptions when a mobile receiver runs into such a shadow.

対照的に、順方向シフト冗長方式は、（付録Aに示されているように）一つは、受信機において有効な抗影損失管理を適用することを可能にするモバイル受信機は、このような影に実行されるとき、したがって、サービスの中断を防止します。

Anti-shadow loss concealment as described in this document can be readily applied to the streaming of pre-recorded media. Because of the need of generating the forward-shifted anti-shadow redundant stream, to apply anti-shadow loss concealment to the streaming of live media will require the insertion of a delay equal to or greater than the amount of forward-shifting at the source of media.

抗シャドーロス隠蔽この文書に記載されているように、容易に予め記録されたメディアのストリーミングに適用することができます。順方向シフト抗シャドウ冗長ストリームを生成する必要性のため、ライブメディアのストリーミングに抗シャドウロス隠蔽を適用するためにソースで前方シフト量以上の遅延の挿入を必要としますメディアの。

1.1. Sending Redundant Data Inband vs. Out-of-Band

1.1. アウトオブバンド対冗長データ帯域内の送信

Regardless of the direction of time shift (e.g., forward-shifting, or backward-shifting as in RFC 2198) or the encoding scheme (e.g., Forward Error Correction (FEC), or non-FEC), there is always the option of sending the redundant data and the primary data either in the same RTP session (i.e., inband) or in separate RTP sessions (i.e., out-of-band). There are pros and cons for either approach, as outlined below.

かかわらず、時間シフト（例えば、前方にシフト、または後方にシフトRFC 2198のように）または符号化方式（例えば、前方誤り訂正（FEC）、または非FEC）の方向の、送信のオプションが常にあります冗長データと、一次データのいずれかと同じRTPセッション（すなわち、帯域内）で、または別個のRTPセッション（すなわち、アウト・オブ・バンド）。下記のとおり長所と短所は、どちらかのアプローチがあります。

Inband Approach:

インバンドアプローチ：

o Pro: A single RTP session is faster to set up and easier to manage.

Oプロ：単一のRTPセッションを設定すると簡単に管理するために高速です。

o Pro: A single RTP session presents a simpler problem for NAT/ firewall traversal.

Oプロ：シングルRTPセッションはNAT /ファイアウォール越えのためのシンプルな問題を提示します。

o Pro: Less overall overhead -- one source of RTP/UDP/IP overhead.

Oプロ：少ない全体的なオーバーヘッド - RTP / UDP / IPのオーバーヘッドの一つのソース。

o Con: Lack of flexibility -- difficult for middle boxes such as gateways to add/remove the redundant data.

Oコン：柔軟性の欠如 - 真ん中の箱のための困難な冗長データを追加/削除するゲートウェイなど。

o Con: Need more specification -- special payload formats need to be defined to carry the redundant data inband.

Oコン：より多くの仕様が必要 - 特殊なペイロードフォーマットは、冗長データのインバンドを運ぶために定義する必要があります。

Out-of-Band Approach:

アウトオブバンドのアプローチ：

o Pro: Flexibility -- redundant data can be more easily added, removed, or replaced by a middle box such as a gateway.

Oプロ：柔軟性 - 冗長データはより容易にそのようなゲートウェイとして、追加、削除、または中間ボックスで置き換えることができます。

o Pro: Little or no specification -- no new payload format is needed.

Oプロ：リトルまたは指定なし - 新しいペイロードフォーマットは必要ありません。

o Con: Multiple RTP sessions may take longer to set up and may be more complex to manage.

Oコン：複数のRTPセッションがセットアップに時間がかかることがあり、管理が複雑になることがあります。

o Con: Multiple RTP sessions for NAT/firewall traversal are harder to address.

Oコン：NAT /ファイアウォールトラバーサルのための複数のRTPセッションが対処することが困難です。

o Con: Bigger overall overhead -- more than one source of RTP/UDP/IP overhead.

Oコン：ビガー全体的なオーバーヘッド - RTP / UDP / IPのオーバーヘッドの複数のソース。

It is noteworthy that the specification of inband payload formats, as described in this document and in RFC 2198, does not preclude a deployment from using the out-of-band approach. Rather, it gives the deployment the choice to use whichever approach is deemed most beneficial under a given circumstance.

インバンドペイロードフォーマットの仕様は、この文書およびRFC 2198に記載されているように、アウトオブバンドアプローチを使用することから導入を排除するものではないことは注目に値します。むしろ、それは展開に与えられた状況下で最も有益と認められる方のアプローチを使用するかを選択できます。

2. Conventions

2.表記

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。

3. Allowing Forward-Shifted Redundant Data

3.フォワードシフトされた冗長データを許可

In RFC 2198, the timestamp offset in the additional header corresponding to a redundant block is defined as a 14-bit unsigned offset of the timestamp relative to the timestamp given in the RTP header. As stated in RFC 2198:

RFC 2198において、冗長ブロックに対応する追加のヘッダのオフセットタイムスタンプは、RTPヘッダで与えられたタイムスタンプに対するタイムスタンプのオフセットは14ビットの符号なしとして定義されます。 RFC 2198に記載されているように：

The use of an unsigned offset implies that redundant data must be sent after the primary data, and is hence a time to be subtracted from the current timestamp to determine the timestamp of the data for which this block is the redundancy.

符号なしオフセットの使用は、冗長データがプライマリ・データの後に送信されなければならないことを意味し、従ってこのブロックが冗長されたデータのタイムスタンプを決定するために、現在のタイムスタンプから減算される時間です。

This effectively prevents RFC 2198 from being used to support forward-shifted redundant blocks.

これは、効果的に前方にシフトされた冗長ブロックをサポートするために使用されるのRFC 2198を防止します。

In order to support the use of forward-shifted redundant blocks, the media type "fwdred", which allows a parameter called "forwardshift", is introduced to indicate the capability of and willingness to use forward-shifted redundancy and the base value of timestamp forward-shifting. The base value of "forwardshift" is an integer equal to or greater than '0' in RTP timestamp units.

順方向シフト冗長ブロックの使用をサポートするために、「fwdred」メディアタイプは、能力および意欲フォワードシフト冗長性を使用すると、タイムスタンプのベース値を示すために導入され、「forwardshift」と呼ばれるパラメータを可能にします前方にシフト。「forwardshift」の基準値は、RTPタイムスタンプ単位に等しいか又は「0」よりも大きい整数です。

In an RTP session that uses forward-shifted redundant encodings, the timestamp of a redundant block in a received RTP packet is determined as follows:

次のように前方にシフト冗長符号化方式を使用するRTPセッションでは、受信したRTPパケットにおける冗長ブロックのタイムスタンプが決定されます。

timestamp of redundant block = timestamp in RTP header - timestamp offset in additional header + forward-shift base value

追加ヘッダ+前進シフトベース値にオフセットタイムスタンプ - RTPヘッダ内の冗長ブロック=タイムスタンプのスタンプ

Note that generally, in a forward-shifted session, the timestamp offset in the additional header is set to '0'.

一般に、順方向シフトのセッションで、追加のヘッダのオフセットタイムスタンプが「0」に設定されていることに留意されたいです。

The sender MUST NOT change the contents of a packet that appears in a forward-shifted stream when it is time to send it in the main stream.

送信者は、それがメインストリームにそれを送信する時間があるときに前方シフトストリームに表示され、パケットの内容を変更しないでください。

4. Registration of Media Type "fwdred"

「fwdred」メディアタイプの4登録

The definition is based on media type "red" defined in RFC 2198 [RFC2198] and RFC 4102 [RFC4102], with the addition of the "forwardshift" parameter.

定義は「forwardshift」パラメータを添加して、RFC 2198 [RFC2198]及びRFC 4102 [RFC4102]で定義されたメディアタイプ「赤」に基づいています。

Type names: audio, text

型名：オーディオ、テキスト

Subtype names: fwdred

サブタイプ名：fwdred

Required parameters:

必須パラメータ：

rate: as defined in [RFC4102].

レート：[RFC4102]で定義されます。

pt: as defined in [RFC4102].

PT：[RFC4102]で定義されます。

forwardshift: An unsigned integer can be specified as the value.

forwardshift：符号なし整数値として指定することができます。

If this parameter has a value greater than '0', it indicates that the sender of this parameter will use forward-shifting with a base value as specified when sending out redundant data. This value is in RTP timestamp units.

このパラメータは、「0」よりも大きい値を有する場合、それは、冗長データを送信するときに指定されるように、このパラメータの送信者が基準値と前進シフトを使用することを示しています。この値は、RTPタイムスタンプユニットです。

If this parameter has a value of '0', it indicates that the sender of this parameter will not use forward-shifting when sending its redundant data; i.e., the sender will have the same behaviors as defined in RFC 2198.

このパラメータが「0」の値を有する場合、その冗長データを送信する場合、このパラメータの送信者が前方にシフトを使用しないことを示しています。すなわち、送信者は、RFC 2198で定義されたものと同じ振る舞いを持つことになります。

Optional parameters:

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

ptime: as defined in [RFC4102] [RFC4566].

PTIME：[RFC4102]、[RFC4566]で定義されます。

maxptime: as defined in [RFC4102] [RFC4867].

maxptime：[RFC4102]、[RFC4867]で定義されます。

Encoding considerations:

エンコードの考慮事項：

This media type is framed binary data (see RFC 4288, Section 4.8) and is only defined for transfer of RTP redundant data frames specified in RFC 2198.

このメディアタイプは、バイナリデータをフレーム化された（RFC 4288、セクション4.8を参照）のみRFC 2198で指定されたRTP冗長データフレームの転送のために定義されています。

Security considerations: See Section 6 of RFC 2198.

セキュリティの考慮事項：RFC 2198のセクション6を参照してください。

Interoperability considerations: none.

相互運用性に関する注意事項：なし。

Published specification:

公開された仕様：

RTP redundant data frame format is specified in RFC 2198.

RTP冗長データフレームフォーマットは、RFC 2198で指定されています。

Applications that use this media type:

このメディアタイプを使用するアプリケーション：

It is expected that real-time audio/video, text streaming, and conferencing tools/applications that want protection against losses of a large number of consecutive frames will be interested in using this type.

これは、リアルタイムのオーディオ/ビデオというテキスト・ストリーミング、および連続したフレームの数が多いの損失に対する保護は、このタイプを使用することに興味があるだろうしたい会議ツール/アプリケーションが期待されます。

Additional information: none.

追加情報：なし。

Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス：

Qiaobing Xie <Qiaobing.Xie@gmail.com>

オリンピックアイスQ私はIE X <Q Iオリンピック氷を.X IE@Gmail.com>

Intended usage: COMMON

意図している用法：COMMON

Restrictions on usage:

使用に関する制限事項：

This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550 [RFC3550]). Transfer within other framing protocols is not defined at this time.

このメディアタイプは、RTP（RFC 3550 [RFC3550]）を介してRTPフレーミングに依存し、したがってのみ転送のために定義されています。他のフレーミングプロトコル内の転送は、この時点で定義されていません。

Author:

著者：

Qiaobing Xie

オリンピックアイスQ私はIEをX

Change controller:

コントローラを変更します。

IETF Audio/Video Transport working group delegated from the IESG.

IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ。

5. Mapping Media Type Parameters into SDP

SDPへ5.マッピングメディアタイプのパラメータ

The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the forward-shifted redundant format, the mapping is as follows:

メディアタイプ仕様で搬送される情報は、一般的にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）[RFC4566]のフィールドに特定のマッピングを有します。 SDPは、順方向シフト冗長形式を採用セッションを指定するために使用される場合、以下のように、マッピングは次のとおりです。

o The media type ("audio") goes in SDP "m=" as the media name.

Oメディアタイプ（「オーディオ」）は、メディア名としてSDP「m =」に進みます。

o The media subtype ("fwdred") goes in SDP "a=rtpmap" as the encoding name.

Oメディアサブタイプ（「fwdred」）は、符号化名としてSDPの「a = rtpmap」に進みます。

o The required parameter "forwardshift" goes in the SDP "a=fmtp" attribute by copying it directly from the media type string as "forwardshift=value".

O必要なパラメータ「forwardshiftは」「forwardshift =値」などのメディアタイプ文字列から直接コピーすることによって、SDPの「a =のfmtp」属性になります。

The following is an example of usage that indicates forward-shifted (by 5.1 sec) redundancy:

冗長性（5.1秒によって）前方にシフト示し使い方の例を示します。

m=audio 12345 RTP/AVP 121 0 5 a=rtpmap:121 fwdred/8000/1 a=fmtp:121 0/5 forwardshift=40800

M =オーディオ12345 RTP / AVP 121 0 5 A = rtpmap：121 fwdred / 1分の8000 A =のfmtp：121 0/5 forwardshift = 40800

The following is an example of usage that indicates sending redundancy without forward-shifting (equivalent to RFC 2198):

以下は、順方向シフト（RFC 2198に相当）することなく、冗長性を送信示す使用例です。

m=audio 12345 RTP/AVP 121 0 5 a=rtpmap:121 fwdred/8000/1 a=fmtp:121 0/5 forwardshift=0

M =オーディオ12345 RTP / AVP 121 0 5 A = rtpmap：121 fwdred / 1分の8000 A =のfmtp：121 0/5 forwardshift = 0

6. Usage in Offer/Answer

オファー/回答6.使用法

The "forwardshift" SDP parameter specified in this document is declarative, and all reasonable values are expected to be supported.

この文書で指定された「forwardshift」SDPパラメータは宣言型であり、すべての合理的な値がサポートされることが期待されます。

7. IANA Considerations

7. IANAの考慮事項

IANA made the assignments described below per this document.

IANAはこのドキュメントごとに下記の割り当てを行いました。

o IANA added the following to the "Audio Media Types" registry:

O IANAは、「オーディオメディアタイプ」レジストリに次を追加しました：

fwdred [RFC6354]

o IANA added the following to the "Text Media Types" registry:

O IANAは、「テキストメディアタイプ」レジストリに次を追加しました：

fwdred [RFC6354]

8. Security Considerations

8.セキュリティの考慮事項

Security considerations discussed in Section 6 of [RFC2198], Section 4 of [RFC4856], and Sections 9 and 14 of [RFC3550] apply to this specification. In addition, to prevent denial-of-service attacks, a receiver SHOULD be prepared to ignore a 'forwardshift' parameter declaration if it considers the offset value in the declaration excessive. In such a case, the receiver SHOULD also ignore the redundant stream in the resultant RTP session.

[RFC2198]のセクション6、[RFC4856]のセクション4、およびセクション9と[RFC3550]の14で説明したセキュリティ上の考慮事項は、本明細書に適用されます。また、サービス拒否攻撃を防止するために、受信機は、それが過剰宣言のオフセット値を考慮した場合に「forwardshift」パラメータ宣言を無視するように準備されるべきです。このような場合、受信機はまた、得られたRTPセッションにおける冗長ストリームを無視すべきです。

9. Normative References

9.引用規格

[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月。

[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.

[RFC2198]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ・ガルシア、A.、およびS.フォッシー-Parisis、「RTPペイロード冗長オーディオ・データ」、RFC 2198、1997年9月のため。

[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月。

[RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type", RFC 4102, June 2005.

[RFC4102]ジョーンズ、P.、 "テキスト/赤いMIMEサブタイプの登録"、RFC 4102、2005年6月。

[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月。

[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月。

[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, April 2007.

[RFC4867] Sjoberg、J.、ウェスター、M.、Lakaniemi、A.、およびQ.謝、「RTPペイロード形式と適応マルチレート（AMR）と適応マルチレート広帯域（AMR-WBのためのストレージ・ファイル形式）オーディオコーデック」、RFC 4867、2007年4月。

Appendix A. Anti-Shadow Loss Concealment Using Forward-Shifted Redundancy

フォワード・シフト冗長性の使用付録A.アンチシャドウ損失隠蔽

(This Appendix is included for Informational purposes.)

（この付録は情報提供の目的のために含まれています。）

It is not unusual in a wireless mobile communication environment that the radio signal to a mobile wireless media receiver can be temporarily blocked by tall buildings, mountains, tunnels, etc. for a period of time. In other words, the receiver enters into a shadow of the radio coverage. When the receiver is in such a shadow, no new data will be received. In some extreme cases, the receiver may have to spend seconds or even tens of seconds in such a shadow.

これは、モバイル無線メディア受信機への無線信号を一時的期間のための高層ビル、山、トンネル、等によって遮断することができる無線移動通信環境では珍しいことではありません。換言すれば、受信機は、無線カバレッジの影に入ります。受信機は、このような影になると、新しいデータが受信されません。いくつかの極端な例では、受信機は、このような影に秒または秒のさえ数十を費やす必要があります。

Without special design considerations to compensate for the loss of data due to shadowing, a mobile user may experience an unacceptable level of service interruptions. Traditional redundant encoding schemes (including RFC 2198 and most FEC schemes) are known to be ineffective in dealing with such losses of consecutive frames.

シャドーイングによるデータの損失を補償するために特別な設計上の考慮事項がなければ、モバイルユーザーは、サービスの中断を許容できないレベルを体験することがあります。（RFC 2198と最もFEC方式を含む）は、従来の冗長符号化方式は、連続するフレームのような損失に対処するには無効であることが知られています。

However, the employment of forward-shifted redundancy, in combination with the anti-shadow loss concealment at the receiver, as described here, can effectively prevent service interruptions due to the effect of shadowing.

しかし、前方にシフトした冗長性の雇用は、受信機での抗シャドウ損失隠蔽との組み合わせで、ここで説明するように、効果的にシャドーイングの影響によるサービスの中断を防ぐことができます。

A.1. Sender-Side Operations

A.1。送信者側の操作

For anti-shadow loss management, the RTP sender simply adds a forward-shifted redundant stream (called anti-shadow or AS stream) while transmitting the primary media stream. The amount of forward-shifting, which should remain constant for the duration of the session, will determine the maximal length of shadows that can be completely concealed at the receiver, as explained below.

一次メディア・ストリームを送信しながら、抗シャドウロス管理のために、RTP送信者は、単に（抗シャドウ又はストリームとして呼ばれる）順方向シフト冗長ストリームを付加します。以下に説明するように、セッションの期間中一定のままでなければならない順方向シフトの量は、完全に受信機に隠すことができる影の最大の長さを決定します。

Except for the fact that the redundant stream is forward-shifted relative to the primary stream (i.e., the redundant data is sent ahead of the corresponding primary data), the design decision and trade-offs on the quality, encoding, bandwidth overhead, etc. of the redundant stream are not different from the traditional RTP payload redundant scheme.

冗長ストリームは、プライマリストリーム（すなわち、冗長データが対応するプライマリデータよりも先に送信されます）、品質、エンコーディング、帯域幅のオーバーヘッドの設計上の決定とトレードオフなどに対して順方向にシフトしているという事実を除いて冗長ストリームのは、従来のRTPペイロード冗長方式とは異なるものではありません。

The following diagram illustrates a segment of the transmission sequence of a forward-shifted redundant RTP session, in which the AS stream is forward-shifted by 155 frames. If, for simplicity here, we assume that the value of the timestamp is incremented by 1 between two consecutive frames, this forward-shifted redundancy can then be indicated with:

次の図は、ASストリームは155のフレームにより前方にシフトされた前方にシフト冗長RTPセッションの送信シーケンスのセグメントを示します。ここでは簡単のために、我々は、タイムスタンプの値は1 2の間の連続フレームずつ増加していることを前提とし、場合、この前方シフト冗長性は、その後に表示することができます。

forwardshift=155

forwardshift = 155

and the setting of the timestamp offset to 0 in all the additional headers. This can mean 3.1 seconds of forward-shifting if each frame represents 20 ms of original media.

タイムスタンプの設定は、すべての追加のヘッダーに0にオフセット。各フレームは、元のメディアの20ミリ秒を表す場合、これは、順方向シフトの3.1秒を意味することができます。

Primary stream AS stream

ストリームASプライマリストリーム

(Transmitted first)

（最初に送信）

Figure 1: An Example of Forward-Shifted Redundant RTP Packet Transmission

図1：フォワードシフト冗長RTPパケット送信の例

A.2. Receiver-Side Operations

A.2。受信側の操作

The anti-shadow receiver is illustrated in the following diagram.

抗シャドウ受信機は、以下の図に示されています。

                                                 +---------+
                               normal mode   sw1 | media   |     media
    Primary stream ======================o___o==>| decoder |===> output
    AS stream     ----                           +---------+     device
                     |             AS mode o
                     |       +---------+   |
                     |       | anti-   |   |
                     ------->| shadow  |----
                             | buffer  |
                             +---------+
                                  |
                                  V
                             expired frames
                             discarded

Figure 2: Anti-Shadow RTP Receiver

図2：アンチシャドウRTPレシーバー

The anti-shadow receiver operates between two modes -- "normal mode" and "AS mode". When the receiver is not in a shadow (i.e., when it still receives new data), it operates in the normal mode. Otherwise, it operates in the AS mode.

「通常モード」と「ASモード」 - 抗シャドウ受信機は、2つのモードの間で動作します。受信機は影でないとき（それがまだ新しいデータを受信した場合、すなわち、）、それは通常モードで動作します。それ以外の場合は、ASモードで動作します。

A.2.1. Normal-Mode Operation

A.2.1。ノーマルモード動作

In the normal mode, after receiving a new RTP packet that contains the primary data and forward-shifted AS data, the receiver passes the primary data directly to the appropriate media decoder for play-out (a de-jittering buffer may be used before the play-out, but for simplicity we assume that none is used here), while the received AS data is stored in an anti-shadow buffer.

ノーマルモードでは、プライマリ・データを含み、データとして順方向シフト新しいRTPパケットを受信した後、受信機は、プレイアウトのための適切なメディアデコーダに直接プライマリ・データを渡し（Aデジッタバッファは、前に使用してもよいですアウトプレーが、簡単のために、我々は、データが抗シャドウバッファに格納されたとして受信しながら、）何もここで使用されていないことを前提としています。

Moreover, data stored in the anti-shadow buffer will be continuously checked to determine whether it has expired. If any redundant data in the anti-shadow buffer is found to have a timestamp older (i.e., smaller) than that of the last primary frame passed to the media decoder, it will be considered expired and be purged from the anti-shadow buffer.

また、抗シャドウ・バッファに格納されたデータは連続的に、それが満了したかどうかを決定するためにチェックされます。抗シャドウ・バッファ内の任意の冗長データは、メディアデコーダに渡される最後の一次フレームよりも古いタイムスタンプ（すなわち、より小さい）を有することが発見された場合、それが期限切れとみなされ、抗シャドウバッファからパージされます。

The following example illustrates the operation of the anti-shadow buffer in normal mode. We use the same assumption as in Figure 1, and assume that the initial timestamp value is 103 when the session starts.

次の例では、ノーマルモードにおける抗シャドウ・バッファの動作を示します。我々は、図1と同じ仮定を使用して、セッションの開始時に初期タイムスタンプ値が103であることを前提としています。

             Timestamp     Timestamp
     Time      being      of media in
    (in ms)  played out    AS buffer         Note
   ------------------------------------------------------------------
     t < 0                 --             (buffer empty)
      ...
     t=0       103         258            (hold 1 AS frame)
     t=20      104         258-259        (hold 2 AS frames)
     t=40      105         258-260        (hold 3 AS frames)

... t=3080 257 258-412 (full, hold 155 AS frames) t=3100 258 259-413 (full, frame 258 purged) t=3120 259 260-414 (full, frame 259 purged) ...

... T = 3080 257 258-412（フル、フレーム155を保持する）、T = 3100 258 259から413（完全、フレーム258をパージ）T = 3120 259 260から414（完全、フレーム259をパージ）...

t=6240 415 416-570 (always holds 3.1 sec worth of redundant data) ...

トン= 6240 415 416-570（常に冗長データの3.1秒の価値を保持しています）...

Figure 3: Example of Anti-Shadow Buffer Operation in Normal Mode

図3：通常モードにおける抗シャドウバッファ動作の例

Before the beginning of the session (t<0), the anti-shadow buffer will be empty. When the first primary frame is received, the play-out will start immediately, and the first received AS frame is stored in the anti-shadow buffer. With the arrival of more forward-shifted redundant frames, the anti-shadow buffer will gradually be filled up.

セッションの開始前に（T <0）、抗シャドウバッファは空になります。最初の主要なフレームを受信した場合、プレイアウトがすぐに開始され、最初のフレームは抗シャドウバッファに格納されるとして受け取りました。より前方にシフト冗長フレームの到着と、抗シャドウバッファは徐々に埋められます。

For the example shown in Figure 3, after 3.08 seconds (the amount of the forward-shifting minus one frame) from the start of the session, the anti-shadow buffer will be full, holding exactly 3.1 seconds worth of redundant data, with the oldest frame corresponding to t=3.1 sec and the youngest frame corresponding to t=6.18 sec.

図3に示す例では、セッションの開始から3.08秒（順方向シフトマイナス1フレーム分の量）の後、抗シャドウバッファがと、冗長データの価値を正確に3.1秒間保持し、完全であろう最も古いフレームTに対応= 3.1秒、6.18秒= Tに対応最年少フレーム。

It is not difficult to see that in normal mode, because of the continuous purge of expired frames and the addition of new frames, the anti-shadow buffer will always be full, holding the next 'forwardshift' amount of redundant frames.

期限切れのフレームの連続パージと新しいフレームの添加、抗シャドウバッファは常に冗長フレームの次の「forwardshift」量を保持して、いっぱいになるので、通常モードでそれを見ることは難しいことではありません。

A.2.2. Anti-Shadow-Mode Operation

A.2.2。アンチシャドウモード動作

When the receiver enters a shadow (or any other conditions that prevent the receiver from getting new media data), the receiver switches to the anti-shadow mode, in which it simply continues the play-out from the forward-shifted redundant data stored in the anti-shadow buffer.

受信機は、影（又は新たなメディアデータを得ることから、受信機を防ぐ他の条件）を入力するとき、受信機は、それが単純に格納されたフォワードシフト冗長データからプレイアウトを継続する抗シャドウモードに切り替わり抗シャドウバッファ。

For the example in Figure 3, if the receiver enters a shadow at t=3120, it can continue the play-out by using the forward-shifted redundant frames (ts=260-414) from the anti-shadow buffer. As long as the receiver can move out of the shadow by t=6240, there will be no service interruption.

図3の例では、受信機は、T = 3120で影に入った場合、それは抗シャドウバッファから前方にシフト冗長フレーム（TS = 260から414）を使用してプレイアウトを継続することができます。限り、受信機は、T = 6240により影の外に移動することができるように、何のサービスの中断が存在しないであろう。

When the shadow condition ends (meaning new data starts to arrive again), the receiver immediately switches back to the normal mode of operation, playing out from newly arrived primary frames. At the same time, the arrival of new AS frames will start to re-fill the anti-shadow buffer.

影条件は終了する（新しいデータを意味するが再び到着し始め）する場合、受信機はすぐに新たに到着した主フレームから出て遊んで、通常の動作モードに戻ります。同時に、フレームAS新しいの到着は、抗シャドウバッファを再埋めるために開始します。

However, if the duration of the shadow is longer than the amount of forward-shifting, the receiver will run out of media frames from its anti-shadow buffer. At that point, service interruption will occur.

影の持続時間が長い順方向シフトの量よりも大きい場合は、受信機は、その抗シャドウ・バッファからのメディアフレームの不足であろう。その時点で、サービスの中断が発生します。

Author's Address

著者のアドレス

Qiaobing Xie 15901 Wetherburn Rd. Chesterfield, MO 63017 US

Qiaobing謝15901 Wetherburn Rdを。チェスターフィールド、MO 63017米国

Phone: +1-847-893-0222 EMail: Qiaobing.Xie@gmail.com

電話：+ 1-847-893-0222 Eメール：Qiaobing.Xie@gmail.com