[要約] RFC 6354は、Forward-Shifted RTP Redundancy Payload Supportに関する標準仕様です。このRFCの目的は、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
フォワードシフトRTP冗長性ペイロードサポート
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6354で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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
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.
このドキュメントでは、RFC 2198 [RFC2198]の単純な強化を定義して、将来のシフト冗長エンコード、つまり、対応する一次データの前に送信される冗長データを使用したRTPセッションをサポートします。
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.
このドキュメントで説明されているように、シェード損失の隠蔽は、事前に録音されたメディアのストリーミングに容易に適用できます。順方向にシフトしたアンチシャドウ冗長ストリームを生成する必要があるため、ライブメディアのストリーミングにアンチシャドウ損失の隠蔽を適用するには、ソースでの順方向シフトの量以上の遅延を挿入する必要があります。メディアの。
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セッション（つまり、INBAND）または別々のRTPセッション（つまり、バンド外）のいずれかです。以下に概説するように、どちらのアプローチにも長所と短所があります。
Inband Approach:
インバンドアプローチ：
o Pro: A single RTP session is faster to set up and easier to manage.
o Pro：単一のRTPセッションのセットアップが速く、管理が容易です。
o Pro: A single RTP session presents a simpler problem for NAT/ firewall traversal.
o Pro：単一のRTPセッションは、NAT/ファイアウォールトラバーサルのより単純な問題を提示します。
o Pro: Less overall overhead -- one source of RTP/UDP/IP overhead.
o Pro：全体的なオーバーヘッド - RTP/UDP/IPオーバーヘッドの1つのソース。
o Con: Lack of flexibility -- difficult for middle boxes such as gateways to add/remove the redundant data.
o CON：柔軟性の欠如 - ゲートウェイなどの中央のボックスが冗長データを追加/削除するのが難しい。
o Con: Need more specification -- special payload formats need to be defined to carry the redundant data inband.
o CON：より多くの仕様が必要です - 冗長データを搭載するには、特別なペイロード形式を定義する必要があります。
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 Pro：柔軟性 - 冗長データは、ゲートウェイなどの中央のボックスに簡単に追加、削除、または置き換えることができます。
o Pro: Little or no specification -- no new payload format is needed.
o Pro：仕様はほとんどまたはまったくありません - 新しいペイロード形式は必要ありません。
o Con: Multiple RTP sessions may take longer to set up and may be more complex to manage.
o CON：複数のRTPセッションがセットアップに時間がかかる場合があり、管理がより複雑になる場合があります。
o Con: Multiple RTP sessions for NAT/firewall traversal are harder to address.
o CON：NAT/ファイアウォールトラバーサルの複数のRTPセッションを対処するのは困難です。
o Con: Bigger overall overhead -- more than one source of RTP/UDP/IP overhead.
o CON：全体的なオーバーヘッド - 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で説明されているように、インバンドペイロード形式の仕様は、帯域外アプローチを使用することを排除することを妨げないことは注目に値します。むしろ、展開により、特定の状況下で最も有益であるとみなされるアプローチを使用する選択を選択できます。
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]で説明されているように解釈されます。
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」の基本値は、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.
送信者は、メインストリームに送信する時が来たときに、順方向シフトされたストリームに表示されるパケットの内容を変更してはなりません。
The definition is based on media type "red" defined in RFC 2198 [RFC2198] and RFC 4102 [RFC4102], with the addition of the "forwardshift" parameter.
定義は、RFC 2198 [RFC2198]およびRFC 4102 [RFC4102]で定義されているメディアタイプ「RED」に基づいており、「ForwardShift」パラメーターが追加されています。
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:
詳細については、連絡先への個人およびメールアドレス：
Qiaobing Xie <Qiaobing.Xie@gmail.com>
Intended usage: 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フレーミングに依存するため、RTP（RFC 3550 [RFC3550]）を介した転送に対してのみ定義されます。他のフレーミングプロトコル内の転送は、現時点では定義されていません。
Author:
著者：
Qiaobing Xie
qiaobing xie
Change controller:
コントローラーの変更：
IETF Audio/Video Transport working group delegated from the IESG.
IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
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:
メディアタイプの仕様に掲載されている情報には、セッション説明プロトコル（SDP）[RFC4566]のフィールドへの特定のマッピングがあります。これは、RTPセッションを記述するために一般的に使用されます。SDPを使用して、順方向シフト冗長形式を使用したセッションを指定する場合、マッピングは次のとおりです。
o The media type ("audio") goes in SDP "m=" as the media name.
o メディアタイプ（ "Audio"）は、メディア名として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 = value」として直接コピーすることにより、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
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
The "forwardshift" SDP parameter specified in this document is declarative, and all reasonable values are expected to be supported.
このドキュメントで指定された「ForwardShift」SDPパラメーターは宣言的であり、すべての合理的な値がサポートされると予想されます。
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]
fwdred [rfc6354]
o IANA added the following to the "Text Media Types" registry:
o IANAは「テキストメディアタイプ」レジストリに以下を追加しました。
fwdred [RFC6354]
fwdred [rfc6354]
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、および[RFC3550]のセクション9および14で説明されているセキュリティ上の考慮事項が、この仕様に適用されます。さらに、サービス拒否攻撃を防ぐために、受信者は、宣言の過剰のオフセット値を考慮した場合、「Forwardshift」パラメーター宣言を無視する準備をする必要があります。そのような場合、受信者は、結果のRTPセッションで冗長ストリームも無視する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-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.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type", RFC 4102, June 2005.
[RFC4102]ジョーンズ、P。、「テキスト/レッドマイムサブタイプの登録」、RFC 4102、2005年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「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.、Westerlund、M.、Lakaniemi、A。、およびQ. Xie、 "RTPペイロード形式および適応マルチレート（AMR）およびアダプティブマルチレート広帯域のファイルストレージ形式（AMR-WBB）Audio Codecs」、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.
ただし、ここで説明したように、レシーバーでのシェラドー損失の隠蔽と組み合わせて、前方シフト冗長性の採用は、シャドウイングの効果によるサービスの中断を効果的に防ぐことができます。
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セッションの伝送シーケンスのセグメントを示しています。ここで簡単にするために、タイムスタンプの値が2つの連続したフレームの間に1倍になると想定している場合、この前方シフト冗長性は次のとおりです。
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に0になります。これは、各フレームが20ミリ秒のオリジナルメディアを表す場合、3.1秒の前方シフトを意味します。
Primary stream AS stream
ストリームとしてのプライマリストリーム
... | |
v v
Pkt k+8 [ 111 ] [ 266 ]
| |
v v
Pkt k+7 [ 110 ] [ 265 ]
| |
v v
^ Pkt k+6 [ 109 ] [ 264 ]
| | |
| v v
Pkt k+5 [ 108 ] [ 263 ]
T | |
I v v
M Pkt k+4 [ 107 ] [ 262 ]
E | |
v v
Pkt k+3 [ 106 ] [ 261 ]
| |
v v
Pkt k+2 [ 105 ] [ 260 ]
| |
v v
Pkt k+1 [ 104 ] [ 259 ]
| |
v v
Pkt k [ 103 ] [ 258 ]
| |
v v
(Transmitted first)
Figure 1: An Example of Forward-Shifted Redundant RTP Packet Transmission
図1：順方向シフトされた冗長なRTPパケット送信の例
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.
アンチシャドウレシーバーは、「通常モード」と「モードとして」という2つのモード間で動作します。受信機が影にない場合（つまり、まだ新しいデータを受信する場合）、通常モードで動作します。それ以外の場合、ASモードで動作します。
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パケットを受信した後、受信機はプレーアウト用の適切なメディアデコーダーにプライマリデータを直接渡します（不振バッファーを使用する前に使用できます。プレイアウトですが、簡単にするためには、ここでは何も使用されていないと仮定します）が、データとして受信されたものはアンチシャドウバッファーに保存されます。
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) ...
T = 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秒に対応する最古のフレームと、t = 6.18秒に対応する最年少フレーム。
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.
期限切れのフレームの連続パージと新しいフレームの追加のために、通常モードでは、アンチシャドウバッファーが常にいっぱいになり、次の「フォワードシフト」量の冗長フレームが保持されることを確認することは難しくありません。
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.
シャドウ条件が終了すると（新しいデータが再び到着し始めます）、受信機はすぐに通常の操作モードに戻り、新しく到着したプライマリフレームから再生されます。同時に、フレームとして新しい到着がアンチシャドウバッファーの再充填を開始します。
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 Xie 15901 WetherBurn Rd。チェスターフィールド、ミズーリ州63017米国
Phone: +1-847-893-0222
EMail: Qiaobing.Xie@gmail.com