[要約] RFC 6849は、メディアループバックのためのSession Description Protocol（SDP）とReal-time Transport Protocol（RTP）の拡張を提供しています。このRFCの目的は、ネットワーク上でのメディアのループバックテストを可能にすることです。
Internet Engineering Task Force (IETF) H. Kaplan, Ed.
Request for Comments: 6849 Acme Packet
Category: Standards Track K. Hedayat
ISSN: 2070-1721 EXFO
N. Venna
Saperix
P. Jones
Cisco Systems, Inc.
N. Stratton
BlinkMind, Inc.
February 2013
An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback
メディアループバック用のセッション記述プロトコル（SDP）およびリアルタイム転送プロトコル（RTP）の拡張
Abstract
概要
The wide deployment of Voice over IP (VoIP), real-time text, and Video over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, real-time text, or Video over IP service. Today, in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new Session Description Protocol (SDP) media types and attributes that enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, real-time text, and Video over IP performance metrics.
ボイスオーバーIP（VoIP）、リアルタイムテキスト、およびビデオオーバーIPサービスの幅広い展開により、リアルタイムの音声/テキスト/ビデオの品質、信頼性、および全体的なパフォーマンスの管理と維持に新たな課題が生じました。特に、メディア配信は注意が必要な領域です。これらの課題に対処する1つの方法は、メディアをトランスミッターにループバックしてメディア配信パフォーマンスを監視することです。これは通常、サービスの「アクティブモニタリング」と呼ばれます。メディアループバックは、特定のVoIP、リアルタイムテキスト、またはVideo over IPサービスのエッジへのトランスポートの品質を保証する上で特に人気があります。今日、リアルタイムのメディアを配信するネットワークでは、「ping」や「traceroute」を実行していないため、管理者はサービスに関する品質の問題を積極的に監視、管理、診断するために必要なツールがありません。ここで定義された拡張機能は、新しいセッション記述プロトコル（SDP）メディアタイプと属性を追加し、メディアがトランスミッターにループバックされるメディアセッションの確立を可能にします。このようなメディアセッションは、より高度なVoIP、リアルタイムテキスト、およびVideo over IPパフォーマンスメトリックを測定する手段を提供することにより、監視およびトラブルシューティングツールとして機能します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6849.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6849で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Use Cases Supported ........................................4
2. Terminology .....................................................6
3. Overview of Operation ...........................................6
3.1. SDP Offerer Behavior .......................................6
3.2. SDP Answerer Behavior ......................................7
4. New SDP Attributes ..............................................7
4.1. Loopback-Type Attribute ....................................7
4.2. Loopback-Role Attributes: loopback-source and
loopback-mirror ............................................8
5. Rules for Generating the SDP Offer/Answer .......................9
5.1. Generating the SDP Offer for Loopback Session ..............9
5.2. Generating the SDP Answer for Loopback Session ............10
5.3. Offerer Processing of the SDP Answer ......................12
5.4. Modifying the Session .....................................12
5.5. Establishing Sessions between Entities behind NATs ........12
6. RTP Requirements ...............................................13
7. Payload Formats for Packet Loopback ............................13
7.1. Encapsulated Payload Format ...............................14
7.2. Direct Loopback RTP Payload Format ........................16
8. SRTP Behavior ..................................................17
9. RTCP Requirements ..............................................18
10. Congestion Control ............................................18
11. Examples ......................................................18
11.1. Offer for Specific Media Loopback Type ...................19
11.2. Offer for Choice of Media Loopback Type ..................19
11.3. Answerer Rejecting Loopback Media ........................20
12. Security Considerations .......................................21
13. Implementation Considerations .................................22
14. IANA Considerations ...........................................22
14.1. SDP Attributes ...........................................22
14.2. Media Types ..............................................23
15. Acknowledgements ..............................................31
16. References ....................................................31
16.1. Normative References .....................................31
16.2. Informative References ...................................32
The overall quality, reliability, and performance of VoIP, real-time text, and Video over IP services rely on the performance and quality of the media path. In order to assure the quality of the delivered media, there is a need to monitor the performance of the media transport. One method of monitoring and managing the overall quality of real-time VoIP, real-time text, and Video over IP services is through monitoring the quality of the media in an active session. This type of "active monitoring" of services is a method of proactively managing the performance and quality of VoIP-based services.
VoIP、リアルタイムテキスト、Video over IPサービスの全体的な品質、信頼性、およびパフォーマンスは、メディアパスのパフォーマンスと品質に依存しています。配信されるメディアの品質を保証するために、メディアトランスポートのパフォーマンスを監視する必要があります。リアルタイムVoIP、リアルタイムテキスト、およびVideo over IPサービスの全体的な品質を監視および管理する1つの方法は、アクティブなセッションでメディアの品質を監視することです。このタイプのサービスの「アクティブモニタリング」は、VoIPベースのサービスのパフォーマンスと品質をプロアクティブに管理する方法です。
The goal of active monitoring is to measure the media quality of a VoIP, real-time text, or Video over IP session. A way to achieve this goal is to request an endpoint to loop media back to the other endpoint and to provide media statistics (e.g., RTP Control Protocol (RTCP) [RFC3550] and RTCP Extended Reports (RTCP-XR) [RFC3611] information). Another method involves deployment of special endpoints that always loop incoming media back for all sessions. Although the latter method has been used and is functional, it does not scale to support large networks and introduces new network management challenges. Further, it does not offer the granularity of testing a specific endpoint that may be exhibiting problems.
アクティブモニタリングの目的は、VoIP、リアルタイムテキスト、またはVideo over IPセッションのメディア品質を測定することです。この目標を達成する方法は、他のエンドポイントにメディアをループバックするようにエンドポイントに要求し、メディア統計を提供することです（たとえば、RTP制御プロトコル（RTCP）[RFC3550]およびRTCP拡張レポート（RTCP-XR）[RFC3611]情報） 。別の方法には、すべてのセッションで着信メディアを常にループバックする特別なエンドポイントの展開が含まれます。後者の方法が使用され、機能していますが、大規模なネットワークをサポートするように拡張できず、新しいネットワーク管理の課題が生じます。さらに、問題が発生している可能性のある特定のエンドポイントをテストするための細分性は提供されません。
The extension defined in this document introduces new SDP media types and attributes that enable establishment of media sessions where the media is looped back to the transmitter. The SDP offer/answer model [RFC3264] is used to establish a loopback connection. Furthermore, this extension provides guidelines on handling RTP [RFC3550], as well as usage of RTCP [RFC3550] and RTCP-XR [RFC3611] for reporting media-related measurements.
このドキュメントで定義されている拡張機能は、メディアがトランスミッタにループバックされるメディアセッションの確立を可能にする新しいSDPメディアタイプと属性を導入します。 SDPオファー/アンサーモデル[RFC3264]は、ループバック接続を確立するために使用されます。さらに、この拡張機能は、RTP [RFC3550]の処理に関するガイドラインと、メディア関連の測定値を報告するためのRTCP [RFC3550]およびRTCP-XR [RFC3611]の使用法を提供します。
As a matter of terminology in this document, packets flow from one peer acting as a "loopback source", to the other peer acting as a "loopback mirror", which in turn returns packets to the loopback source. In advance of the session, the peers negotiate to determine which one acts in which role, using the SDP offer/answer exchange. The negotiation also includes details such as the type of loopback to be used.
このドキュメントの用語の問題として、パケットは、「ループバックソース」として機能する一方のピアから、「ループバックミラー」として機能するもう一方のピアに流れ、次に、ループバックソースにパケットを返します。セッションの前に、ピアは、SDPオファー/アンサー交換を使用して、どのロールでどのアクションを実行するかを決定するために交渉します。ネゴシエーションには、使用するループバックのタイプなどの詳細も含まれます。
This specification supports three use cases: "encapsulated packet loopback", "direct loopback", and "media loopback". These are distinguished by the treatment of incoming RTP packets at the loopback mirror.
この仕様は、「カプセル化パケットループバック」、「直接ループバック」、および「メディアループバック」の3つの使用例をサポートしています。これらは、ループバックミラーでの着信RTPパケットの処理によって区別されます。
In the encapsulated packet loopback case, the entire incoming RTP packet is encapsulated as payload within an outer RTP packet that is specific to this use case and specified in Section 7.1. The encapsulated packet is returned to the loopback source. The loopback source can generate statistics for one-way path performance up to the RTP level for each direction of travel by examining sequence numbers and timestamps in the encapsulating outer RTP header and the encapsulated RTP packet payload. The loopback source can also play back the returned media content for evaluation.
カプセル化されたパケットループバックの場合、着信RTPパケット全体が、この使用例に固有でセクション7.1で指定されている外部RTPパケット内のペイロードとしてカプセル化されます。カプセル化されたパケットはループバックソースに返されます。ループバックソースは、カプセル化する外部RTPヘッダーとカプセル化されたRTPパケットペイロードのシーケンス番号とタイムスタンプを調べることにより、移動方向ごとにRTPレベルまでの一方向パスパフォーマンスの統計を生成できます。ループバックソースは、返されたメディアコンテンツを再生して評価することもできます。
Because the encapsulating RTP packet header extends the packet size, it could encounter difficulties in an environment where the original RTP packet size is close to the path Maximum Transmission Unit (MTU) size. The encapsulating payload format therefore offers the possibility of RTP-level fragmentation of the returned packets. The use of this facility could affect statistics derived for the return path. In addition, the increased bit rate required in the return direction may affect these statistics more directly in a restricted-bandwidth situation.
カプセル化RTPパケットヘッダーはパケットサイズを拡張するため、元のRTPパケットサイズがパスの最大伝送ユニット（MTU）サイズに近い環境では問題が発生する可能性があります。したがって、カプセル化ペイロード形式は、返されたパケットのRTPレベルの断片化の可能性を提供します。この機能を使用すると、リターンパスから得られる統計に影響を与える可能性があります。また、帯域幅が制限されている状況では、戻り方向に必要なビットレートが増加すると、これらの統計に直接影響を与える可能性があります。
In the direct loopback case, the loopback mirror copies the payload of the incoming RTP packet into a new RTP packet, using a payload format specific to this use case and specified in Section 7.2. The loopback mirror returns the new packet to the packet source. There is no provision in this case for RTP-level fragmentation.
ダイレクトループバックの場合、ループバックミラーは、この使用例に固有のセクション7.2で指定されているペイロード形式を使用して、着信RTPパケットのペイロードを新しいRTPパケットにコピーします。ループバックミラーは、新しいパケットをパケットソースに返します。この場合、RTPレベルの断片化に対する規定はありません。
This use case has the advantage of keeping the packet size the same in both directions. The packet source can compute only two-way path statistics from the direct loopback packet header but can play back the returned media content.
この使用例には、パケットサイズを両方向で同じに保つという利点があります。パケットソースは、直接ループバックパケットヘッダーから双方向パス統計のみを計算できますが、返されたメディアコンテンツを再生できます。
It has been suggested that the loopback source, knowing that the incoming packet will never be passed to a decoder, can store a timestamp and sequence number inside the payload of the packet it sends to the mirror, then extract that information from the returned direct loopback packet and compute one-way path statistics as in the previous case. Obviously, playout of returned content is no longer possible if this is done.
着信パケットがデコーダに渡されないことを知っているループバックソースは、ミラーに送信するパケットのペイロード内にタイムスタンプとシーケンス番号を格納し、返された直接ループバックからその情報を抽出できることが示唆されています前のケースと同様に、パケットと一方向パス統計を計算します。明らかに、これが行われた場合、返されたコンテンツの再生はもはや可能ではありません。
In the media loopback case, the loopback mirror submits the incoming packet to a decoder appropriate to the incoming payload type. The packet is taken as close as possible to the analog level, then re-encoded according to an outgoing format determined by SDP negotiation. The re-encoded content is returned to the loopback source as an RTP packet with payload type corresponding to the re-encoding format.
メディアループバックの場合、ループバックミラーは着信ペイロードタイプに適したデコーダに着信パケットを送信します。パケットは可能な限りアナログレベルに近づけられ、SDPネゴシエーションによって決定された発信フォーマットに従って再エンコードされます。再エンコードされたコンテンツは、再エンコード形式に対応するペイロードタイプを持つRTPパケットとしてループバックソースに返されます。
This usage allows troubleshooting at the codec level. The capability for path statistics is limited to what is available from RTCP reports.
この使用法により、コーデックレベルでのトラブルシューティングが可能になります。パス統計の機能は、RTCPレポートから利用できる機能に制限されています。
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]で説明されているように解釈されます。
SDP: Session Description Protocol, as defined in [RFC4566]. This document assumes that the SDP offer/answer model is followed, per [RFC3264], but does not assume any specific signaling protocol for carrying the SDP.
SDP：[RFC4566]で定義されているセッション記述プロトコル。このドキュメントは、[RFC3264]に従って、SDPオファー/アンサーモデルに従うことを想定していますが、SDPを伝送するための特定のシグナリングプロトコルを想定していません。
The following terms are borrowed from [RFC3264] definitions: offer, offerer, answer, answerer, and agent.
次の用語は、[RFC3264]の定義から借用したものです：オファー、オファー者、アンサー、アンサー、およびエージェント。
This document defines two loopback 'types', two 'roles', and two encoding formats for loopback. For any given SDP offerer or answerer pair, one side is the source of RTP packets, while the other is the mirror looping packets/media back. Those define the two loopback roles. As the mirror, two 'types' of loopback can be performed: packet-level or media-level. When media-level is used, there is no further choice of encoding format -- there is only one format: whatever is indicated for normal media, since the "looping" is performed at the codec level. When packet-level looping is performed, however, the mirror can either send back RTP in an encapsulated format or direct loopback format. The rest of this document describes these loopback types, roles, and encoding formats, and the SDP offer/answer rules for indicating them.
このドキュメントでは、2つのループバック「タイプ」、2つの「ロール」、およびループバックの2つのエンコーディング形式を定義しています。特定のSDPオファーまたはアンサーのペアでは、一方がRTPパケットのソースであり、もう一方がミラーループパケット/メディアバックです。これらは2つのループバックロールを定義します。ミラーとして、2つの「タイプ」のループバックを実行できます。パケットレベルまたはメディアレベルです。メディアレベルを使用する場合、エンコード形式を選択する必要はありません。形式は1つだけです。「ループ」はコーデックレベルで実行されるため、通常のメディアで示されている形式です。ただし、パケットレベルのループが実行されている場合、ミラーはRTPをカプセル化形式または直接ループバック形式で送信できます。このドキュメントの残りの部分では、これらのループバックタイプ、役割、およびエンコード形式、およびそれらを示すためのSDPオファー/アンサールールについて説明します。
An SDP offerer compliant to this specification and attempting to establish a media session with media loopback will include "loopback" media attributes for each individual media description in the offer message that it wishes to have looped back. Note that the offerer may choose to only request loopback for some media descriptions/streams but not others. For example, it might wish to request loopback for a video stream but not audio, or vice versa.
この仕様に準拠し、メディアループバックを使用してメディアセッションを確立しようとするSDPオファーは、ループバックしたいオファーメッセージに個々のメディア記述の「ループバック」メディア属性を含めます。提供者は、一部のメディアの説明/ストリームに対してのみループバックを要求することを選択する場合があることに注意してください。たとえば、ビデオストリームにはループバックを要求するが、オーディオには要求しない、またはその逆の場合があります。
The offerer will look for the "loopback" media attributes in the media description(s) of the response from the SDP answer for confirmation that the request is accepted.
提案者は、要求が受け入れられたことを確認するために、SDP回答からの応答のメディア記述で「ループバック」メディア属性を探します。
In order to accept a loopback offer (that is, an offer containing "loopback" in the media description), an SDP answerer includes the "loopback" media attribute in each media description for which it desires loopback.
ループバックオファー（つまり、メディア記述に「ループバック」を含むオファー）を受け入れるために、SDPアンサーは、ループバックを希望する各メディア記述に「ループバック」メディア属性を含めます。
An answerer can reject an offered stream (either with loopback-source or loopback-mirror) if the loopback-type is not specified, the specified loopback-type is not supported, or the endpoint cannot honor the offer for any other reason. The loopback request is rejected by setting the stream's media port number to zero in the answer as defined in RFC 3264 [RFC3264] or by rejecting the entire offer (i.e., by rejecting the session request entirely).
ループバックタイプが指定されていない、指定されたループバックタイプがサポートされていない、または他の理由でエンドポイントがオファーを受け入れられない場合、回答者は提供されたストリームを（ループバックソースまたはループバックミラーで）拒否できます。ループバック要求は、RFC 3264 [RFC3264]で定義されている回答でストリームのメディアポート番号をゼロに設定するか、オファー全体を拒否する（つまり、セッション要求を完全に拒否する）ことで拒否されます。
Note that an answerer that is not compliant to this specification and that receives an offer with the "loopback" media attributes would ignore the attributes and treat the incoming offer as a normal request. If the offerer does not wish to establish a "normal" RTP session, it would need to terminate the session upon receiving such an answer.
この仕様に準拠しておらず、「ループバック」メディア属性を持つオファーを受信するアンサーは、属性を無視し、着信オファーを通常のリクエストとして扱います。提案者が「通常の」RTPセッションの確立を望まない場合は、そのような回答を受け取ったらセッションを終了する必要があります。
Three new SDP media-level attributes are defined: one indicates the type of loopback, and the other two define the role of the agent.
3つの新しいSDPメディアレベル属性が定義されています。1つはループバックのタイプを示し、他の2つはエージェントの役割を定義します。
This specification defines a new "loopback" attribute, which indicates that the agent wishes to perform loopback, and the type of loopback that the agent is able to do. The loopback-type is a value media attribute [RFC4566] with the following syntax:
この仕様は、エージェントがループバックを実行したいことを示す新しい「ループバック」属性と、エージェントが実行できるループバックのタイプを定義します。 loopback-typeは、次の構文の値メディア属性[RFC4566]です。
a=loopback:<loopback-type>
Following is the Augmented BNF [RFC5234] for loopback-type:
次に、ループバックタイプの拡張BNF [RFC5234]を示します。
attribute =/ loopback-attr ; attribute defined in RFC 4566
属性= / loopback-attr; RFC 4566で定義されている属性
loopback-attr = "loopback:" SP loopback-type loopback-type = loopback-choice [1*SP loopback-choice] loopback-choice = loopback-type-pkt / loopback-type-media loopback-type-pkt = "rtp-pkt-loopback" loopback-type-media = "rtp-media-loopback" The loopback-type is used to indicate the type of loopback. The loopback-type values are rtp-pkt-loopback and rtp-media-loopback.
loopback-attr = "loopback：" SP loopback-type loopback-type = loopback-choice [1 * SP loopback-choice] loopback-choice = loopback-type-pkt / loopback-type-media loopback-type-pkt = "rtp -pkt-loopback "loopback-type-media =" rtp-media-loopback "loopback-typeは、ループバックのタイプを示すために使用されます。ループバックタイプの値は、rtp-pkt-loopbackおよびrtp-media-loopbackです。
rtp-pkt-loopback: In this mode, the RTP packets are looped back to the sender at a point before the encoder/decoder function in the receive direction to a point after the encoder/decoder function in the send direction. This effectively re-encapsulates the RTP payload with the RTP/UDP/IP headers appropriate for sending it in the reverse direction. Any type of encoding-related functions, such as packet loss concealment, MUST NOT be part of this type of loopback path. In this mode, the RTP packets are looped back with a new payload type and format. Section 7 describes the payload formats that are to be used for this type of loopback. This type of loopback applies to the encapsulated and direct loopback use cases described in Section 1.1.
rtp-pkt-loopback：このモードでは、RTPパケットは、送信方向のエンコーダー/デコーダー機能の後のポイントに、受信方向のエンコーダー/デコーダー機能の前のポイントで送信者にループバックされます。これにより、RTPペイロードは、逆方向に送信するのに適したRTP / UDP / IPヘッダーで効果的に再カプセル化されます。パケット損失隠蔽など、あらゆるタイプのエンコーディング関連の機能は、このタイプのループバックパスの一部であってはなりません。このモードでは、RTPパケットは新しいペイロードタイプとフォーマットでループバックされます。セクション7では、このタイプのループバックに使用されるペイロード形式について説明します。このタイプのループバックは、セクション1.1で説明されているカプセル化および直接ループバックの使用例に適用されます。
rtp-media-loopback: This loopback is activated as close as possible to the analog interface and after the decoder so that the RTP packets are subsequently re-encoded prior to transmission back to the sender. This type of loopback applies to the media loopback use case described in Section 1.1.3.
rtp-media-loopback：このループバックは、アナログインターフェイスのできるだけ近くで、デコーダーの後にアクティブ化されるため、RTPパケットは、その後、送信者に送信する前に再エンコードされます。このタイプのループバックは、セクション1.1.3で説明されているメディアループバックの使用例に適用されます。
The loopback role defines two property media attributes [RFC4566] that are used to indicate the role of the agent generating the SDP offer or answer. The syntax of the two loopback-role media attributes is as follows:
ループバックロールは、SDPオファーまたはアンサーを生成するエージェントのロールを示すために使用される2つのプロパティメディア属性[RFC4566]を定義します。 2つのループバックロールメディア属性の構文は次のとおりです。
a=loopback-source
a = loopback-source
and
そして
a=loopback-mirror
a = loopback-mirror
Following is the Augmented BNF [RFC5234] for loopback-source and loopback-mirror:
次に、loopback-sourceおよびloopback-mirrorのAugmented BNF [RFC5234]を示します。
attribute =/ loopback-source / loopback-mirror
; attribute defined in RFC 4566
loopback-source = "loopback-source"
loopback-mirror = "loopback-mirror"
loopback-source: This attribute specifies that the entity that generated the SDP is the media source and expects the receiver of the SDP message to act as a loopback mirror.
loopback-source：この属性は、SDPを生成したエンティティがメディアソースであり、SDPメッセージの受信者がループバックミラーとして機能することを期待することを指定します。
loopback-mirror: This attribute specifies that the entity that generated the SDP will mirror (echo) all received media back to the sender of the RTP stream. No media is generated locally by the looping-back entity for transmission in the mirrored stream.
loopback-mirror：この属性は、SDPを生成したエンティティが、受信したすべてのメディアをRTPストリームの送信者にミラーリング（エコー）することを指定します。ミラーリングされたストリームで送信するために、ループバックエンティティによってローカルにメディアが生成されることはありません。
The "m=" line in the SDP includes all the payload types that will be used during the loopback session. The complete payload space for the session is specified in the "m=" line, and the rtpmap attribute is used to map from the payload type number to an encoding name denoting the payload format to be used.
SDPの「m =」行には、ループバックセッション中に使用されるすべてのペイロードタイプが含まれています。セッションの完全なペイロードスペースは「m =」行で指定され、rtpmap属性は、ペイロードタイプ番号から、使用されるペイロード形式を示すエンコーディング名にマップするために使用されます。
If an offerer wishes to make a loopback request, it includes both the loopback-type and loopback-role attributes in a valid SDP offer:
オファー提供者がループバック要求を行いたい場合、有効なSDPオファーにloopback-type属性とloopback-role属性の両方が含まれます。
Example: m=audio 41352 RTP/AVP 0 8 100
a=loopback:rtp-media-loopback
a=loopback-source
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:100 G7221/16000/1
Since media loopback requires bidirectional RTP, its normal direction mode is "sendrecv"; the "sendrecv" direction attribute MAY be encoded in SDP or not, as per Section 5.1 of [RFC3264], since it is implied by default. If either the loopback source or mirror wishes to disable loopback use during a session, the direction mode attribute "inactive" MUST be used as per [RFC3264]. The direction mode attributes "recvonly" and "sendonly" are incompatible with the loopback mechanism and MUST NOT be indicated when generating an SDP offer or answer. When receiving an SDP offer or answer, if "recvonly" or "sendonly" is indicated for loopback, the SDP-receiving agent SHOULD treat it as a protocol failure of the loopback negotiation and terminate the session through its normal means (e.g., by sending a SIP BYE if SIP is used) or reject the offending media stream.
メディアループバックには双方向RTPが必要なため、通常の方向モードは「sendrecv」です。 [sendrecv]方向属性は、[RFC3264]のセクション5.1のように、SDPでエンコードされる場合とされない場合があります。これは、デフォルトで暗黙指定されているためです。ループバックソースまたはミラーのいずれかがセッション中にループバックの使用を無効にする場合は、[RFC3264]のように、方向モード属性「非アクティブ」を使用する必要があります。方向モード属性「recvonly」および「sendonly」はループバックメカニズムと互換性がなく、SDPオファーまたはアンサーを生成するときに指定してはなりません。 SDPオファーまたはアンサーを受信するときに、「recvonly」または「sendonly」がループバックに示されている場合、SDP受信エージェントは、それをループバックネゴシエーションのプロトコル障害として扱い、通常の方法（たとえば、 SIPが使用されている場合はSIP BYE）、または問題のメディアストリームを拒否します。
The offerer may offer more than one loopback-type in the SDP offer. The port number and the address in the offer (m/c= lines) indicate where the offerer would like to receive the media stream(s). The payload type numbers indicate the value of the payload the offerer expects to receive. However, the answer might indicate a subset of payload type numbers from those given in the offer. In that case, the offerer MUST only send the payload types received in the answer, per normal SDP offer/answer rules.
提供者は、SDP提供で複数のループバックタイプを提供できます。オファー内のポート番号とアドレス（m / c =行）は、オファー側がメディアストリームを受信する場所を示します。ペイロードタイプ番号は、オファー提供者が受信することを期待するペイロードの値を示します。ただし、答えは、オファーで提供されたものからのペイロードタイプ番号のサブセットを示す場合があります。その場合、提供者は、通常のSDPオファー/アンサールールに従って、回答で受信したペイロードタイプのみを送信する必要があります。
If the offer indicates rtp-pkt-loopback support, the offer MUST also contain either an encapsulated or direct loopback encoding format encoding name, or both, as defined in Sections 7.1 and 7.2 of this document. If the offer only indicates rtp-media-loopback support, then neither encapsulated nor direct loopback encoding formats apply and they MUST NOT be in the offer.
オファーがrtp-pkt-loopbackサポートを示している場合、オファーには、このドキュメントのセクション7.1および7.2で定義されているように、カプセル化または直接ループバックエンコーディング形式のエンコーディング名、またはその両方を含める必要があります。オファーがrtp-media-loopbackサポートのみを示している場合、カプセル化も直接ループバックエンコーディング形式も適用されず、オファーに含まれていてはなりません。
If loopback-type is rtp-pkt-loopback, the loopback mirror MUST send, and the loopback source MUST receive, the looped-back packets encoded in one of the two payload formats (encapsulated RTP or direct loopback) as defined in Section 7.
loopback-typeがrtp-pkt-loopbackの場合、ループバックミラーは送信しなければならず（MUST）、ループバックソースはセクション7で定義されている2つのペイロード形式（カプセル化RTPまたはダイレクトループバック）のいずれかでエンコードされたループバックパケットを受信しなければなりません（MUST）。
Example: m=audio 41352 RTP/AVP 0 8 112
a=loopback:rtp-pkt-loopback
a=loopback-source
a=rtpmap:112 encaprtp/8000
Example: m=audio 41352 RTP/AVP 0 8 112
a=loopback:rtp-pkt-loopback
a=loopback-source
a=rtpmap:112 rtploopback/8000
As with the offer, an SDP answer for loopback follows SDP offer/answer rules for the direction attribute, but directions of "sendonly" or "recvonly" do not apply for loopback operation.
オファーと同様に、ループバックのSDP回答は、方向属性のSDPオファー/回答ルールに従いますが、「sendonly」または「recvonly」の方向はループバック操作には適用されません。
The port number and the address in the answer (m/c= lines) indicate where the answerer would like to receive the media stream. The payload type numbers indicate the value of the payload types the answerer expects to send and receive.
回答のポート番号とアドレス（m / c =行）は、回答者がメディアストリームを受信する場所を示します。ペイロードタイプ番号は、回答者が送受信を期待するペイロードタイプの値を示します。
An answerer includes both the loopback-role and loopback-type attributes in the answer to indicate that it will accept the loopback request. When a stream is offered with the loopback-source attribute, the corresponding stream in the response will be loopback-mirror and vice versa, provided the answerer is capable of supporting the requested loopback-type.
回答者は、ループバック要求を受け入れることを示すために、回答にloopback-role属性とloopback-type属性の両方を含めます。ストリームがloopback-source属性で提供されると、応答側が要求されたループバックタイプをサポートできる場合、応答内の対応するストリームはループバックミラーになります（逆も同様）。
For example, if the offer contains the loopback-source attribute:
たとえば、オファーにloopback-source属性が含まれている場合：
m=audio 41352 RTP/AVP 0 8
a=loopback:rtp-media-loopback
a=loopback-source
The answer that is capable of supporting the offer must contain the loopback-mirror attribute:
オファーをサポートできる回答には、loopback-mirror属性が含まれている必要があります。
m=audio 12345 RTP/AVP 0 8
a=loopback:rtp-media-loopback
a=loopback-mirror
If a stream is offered with multiple loopback-type attributes, the answer MUST include only one of the loopback types that are accepted by the answerer. The answerer SHOULD give preference to the first loopback-type in the SDP offer.
ストリームに複数のループバックタイプ属性が提供されている場合、回答には、回答者が受け入れるループバックタイプの1つのみを含める必要があります。回答者は、SDPオファーの最初のループバックタイプを優先する必要があります（SHOULD）。
For example, if the offer contains:
たとえば、オファーに次のものが含まれている場合：
m=audio 41352 RTP/AVP 0 8 112
a=loopback:rtp-media-loopback rtp-pkt-loopback
a=loopback-source
a=rtpmap:112 encaprtp/8000
The answer that is capable of supporting the offer and chooses to loopback the media using the rtp-media-loopback type must contain:
オファーをサポートでき、rtp-media-loopbackタイプを使用してメディアをループバックすることを選択する回答には、以下が含まれている必要があります。
m=audio 12345 RTP/AVP 0 8
a=loopback:rtp-media-loopback
a=loopback-mirror
As specified in Section 7, if the loopback-type is rtp-pkt-loopback, either the encapsulated RTP payload format or direct loopback RTP payload format MUST be used for looped-back packets.
セクション7で指定されているように、loopback-typeがrtp-pkt-loopbackの場合、カプセル化されたRTPペイロード形式または直接ループバックRTPペイロード形式をループバックパケットに使用する必要があります。
For example, if the offer contains:
たとえば、オファーに次のものが含まれている場合：
m=audio 41352 RTP/AVP 0 8 112 113
a=loopback:rtp-pkt-loopback
a=loopback-source
a=rtpmap:112 encaprtp/8000
a=rtpmap:113 rtploopback/8000
The answer that is capable of supporting the offer must contain one of the following:
オファーをサポートできる回答には、次のいずれかが含まれている必要があります。
m=audio 12345 RTP/AVP 0 8 112
a=loopback:rtp-pkt-loopback
a=loopback-mirror
a=rtpmap:112 encaprtp/8000
m=audio 12345 RTP/AVP 0 8 113
a=loopback:rtp-pkt-loopback
a=loopback-mirror
a=rtpmap:113 rtploopback/8000
The previous examples used the 'encaprtp' and 'rtploopback' encoding names, which will be defined in Sections 7.1.3 and 7.2.3.
前の例では、セクション7.1.3および7.2.3で定義される「encaprtp」および「rtploopback」エンコーディング名を使用していました。
If the received SDP answer does not contain an a=loopback-mirror or a=loopback-source attribute, it is assumed that the loopback extensions are not supported by the remote agent. This is not a protocol failure and instead merely completes the SDP offer/answer exchange with whatever normal rules apply; the offerer MAY decide to end the established RTP session (if any) through normal means of the upper-layer signaling protocol (e.g., by sending a SIP BYE).
受信したSDP回答にa = loopback-mirrorまたはa = loopback-source属性が含まれていない場合、ループバック拡張はリモートエージェントでサポートされていないと見なされます。これはプロトコル障害ではなく、適用される通常のルールでSDPオファー/アンサー交換を完了するだけです。提供者は、（たとえば、SIP BYEを送信することにより）上位層シグナリングプロトコルの通常の手段を通じて、確立されたRTPセッション（存在する場合）を終了することを決定できます（MAY）。
At any point during the loopback session, either participant MAY issue a new offer to modify the characteristics of the previous session, as defined in Section 8 of RFC 3264 [RFC3264]. This also includes transitioning from a normal media processing mode to loopback mode, and vice versa.
ループバックセッション中の任意の時点で、いずれかの参加者が、RFC 3264 [RFC3264]のセクション8で定義されているように、前のセッションの特性を変更する新しいオファーを発行する場合があります。これには、通常のメディア処理モードからループバックモードへの移行、およびその逆も含まれます。
Interactive Connectivity Establishment (ICE) [RFC5245], Traversal Using Relays around NAT (TURN) [RFC5766], and Session Traversal Utilities for NAT (STUN) [RFC5389] provide a general solution to establishing media sessions between entities that are behind Network Address Translators (NATs). Loopback sessions that involve one or more endpoints behind NATs can also use these general solutions wherever possible.
Interactive Connectivity Establishment（ICE）[RFC5245]、NAT周りのリレーを使用したトラバーサル（TURN）[RFC5766]、およびNATのセッショントラバーサルユーティリティ（STUN）[RFC5389]は、ネットワークアドレストランスレーターの背後にあるエンティティ間でメディアセッションを確立するための一般的なソリューションを提供します（NAT）。 NATの背後にある1つ以上のエンドポイントを含むループバックセッションでも、可能な限りこれらの一般的なソリューションを使用できます。
If ICE is not supported, then in the case of loopback, the mirroring entity will not send RTP packets and therefore will not automatically create the NAT pinhole in the way that other SIP sessions do. Therefore, if the mirroring entity is behind a NAT, it MUST send some packets to the identified address/port(s) of the peer, in order to open the NAT pinhole. Using ICE, this would be accomplished with the STUN connectivity check process or through a TURN server connection. If ICE is not supported, either [RFC6263] or Section 10 of ICE [RFC5245] can be followed to open the pinhole and keep the NAT binding alive/refreshed.
ICEがサポートされていない場合、ループバックの場合、ミラーリングエンティティはRTPパケットを送信しないため、他のSIPセッションのようにNATピンホールが自動的に作成されません。したがって、ミラーリングエンティティがNATの背後にある場合、NATピンホールを開くために、ピアの識別されたアドレス/ポートにいくつかのパケットを送信する必要があります。 ICEを使用すると、これはSTUN接続性チェックプロセスまたはTURNサーバー接続を介して行われます。 ICEがサポートされていない場合は、[RFC6263]またはICEのセクション10 [RFC5245]に従ってピンホールを開き、NATバインディングを有効/更新したままにできます。
Note that for any form of NAT traversal to function, symmetric RTP/RTCP [RFC4961] MUST be used, unless the mirror can control the NAT(s) in its path to create explicit pinholes. In other words, both agents MUST send packets from the source address and port they receive packets on, unless some mechanism is used to avoid that need (e.g., by using the Port Control Protocol).
ミラーがパス内のNATを制御して明示的なピンホールを作成できない場合を除き、NATトラバーサルが機能するためには、対称RTP / RTCP [RFC4961]を使用する必要があることに注意してください。つまり、両方のエージェントは、その必要性を回避するために何らかのメカニズムが使用されていない限り（ポート制御プロトコルを使用するなど）、送信元アドレスとパケットを受信するポートからパケットを送信する必要があります。
A loopback source MUST NOT send multiple source streams on the same 5-tuple, since there is no means for the mirror to indicate which is which in its mirrored RTP packets.
ミラーリングされたRTPパケットのどれがミラーであるかを示す手段がないため、ループバックソースは同じ5タプルで複数のソースストリームを送信してはなりません（MUST NOT）。
A loopback mirror that is compliant to this specification and accepts media with the loopback type rtp-pkt-loopback loops back the incoming RTP packets using either the encapsulated RTP payload format or the direct loopback RTP payload format as defined in Section 7 of this specification.
この仕様に準拠し、ループバックタイプrtp-pkt-loopbackのメディアを受け入れるループバックミラーは、この仕様のセクション7で定義されているカプセル化されたRTPペイロード形式または直接ループバックRTPペイロード形式を使用して、着信RTPパケットをループバックします。
A device that is compliant to this specification and performing the mirroring using the loopback type rtp-media-loopback MUST transmit all received media back to the sender, unless congestion feedback or other lower-layer constraints prevent it from doing so. The incoming media is treated as if it were to be played; for example, the media stream may receive treatment from Packet Loss Concealment (PLC) algorithms. The mirroring entity re-generates all the RTP header fields as it would when transmitting media. The mirroring entity MAY choose to encode the loopback media according to any of the media descriptions supported by the offering entity. Furthermore, in cases where the same media type is looped back, the mirroring entity can choose to preserve the number of frames/packets and the bit rate of the encoded media according to the received media.
この仕様に準拠し、ループバックタイプrtp-media-loopbackを使用してミラーリングを実行するデバイスは、輻輳フィードバックまたは他の下位層の制約により送信を妨げない限り、受信したすべてのメディアを送信者に送信する必要があります。着信メディアは、再生されるかのように扱われます。たとえば、メディアストリームは、パケット損失隠蔽（PLC）アルゴリズムから処理を受け取る場合があります。ミラーリングエンティティは、メディアの送信時と同様に、すべてのRTPヘッダーフィールドを再生成します。ミラーリングエンティティは、オファリングエンティティでサポートされているメディアの説明のいずれかに従ってループバックメディアをエンコードすることを選択できます。さらに、同じメディアタイプがループバックされる場合、ミラーリングエンティティは、受信したメディアに応じて、フレーム/パケットの数とエンコードされたメディアのビットレートを保持するように選択できます。
The payload formats described in this section MUST be used by a loopback mirror when 'rtp-pkt-loopback' is the specified loopback-type. Two different formats are specified here -- an encapsulated RTP payload format and a direct loopback RTP payload format. The encapsulated RTP payload format should be used when the incoming RTP header information needs to be preserved during the loopback operation. This is useful in cases where the loopback source needs to measure performance metrics in both directions. However, this comes at the expense of increased packet size as described in Section 7.1. The direct loopback RTP payload format should be used when bandwidth requirements prevent the use of the encapsulated RTP payload format.
このセクションで説明するペイロード形式は、「rtp-pkt-loopback」が指定されたループバックタイプである場合、ループバックミラーで使用する必要があります。ここでは、2つの異なる形式が指定されています。カプセル化されたRTPペイロード形式と直接ループバックRTPペイロード形式です。ループバック操作中に着信RTPヘッダー情報を保持する必要がある場合は、カプセル化されたRTPペイロード形式を使用する必要があります。これは、ループバックソースが両方向のパフォーマンスメトリックを測定する必要がある場合に役立ちます。ただし、セクション7.1で説明されているように、パケットサイズが大きくなるという犠牲が伴います。帯域幅の要件によりカプセル化されたRTPペイロード形式を使用できない場合は、ダイレクトループバックRTPペイロード形式を使用する必要があります。
A received RTP packet is encapsulated in the payload section of the RTP packet generated by a loopback mirror. Each received packet is encapsulated in a separate encapsulating RTP packet; the encapsulated packet would be fragmented only if required (for example, due to MTU limitations).
受信したRTPパケットは、ループバックミラーによって生成されたRTPパケットのペイロードセクションにカプセル化されます。受信した各パケットは、個別のカプセル化RTPパケットにカプセル化されます。カプセル化されたパケットは、必要な場合にのみフラグメント化されます（たとえば、MTUの制限のため）。
Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document; it is either specified by the RTP profile under which this payload format is used or more likely signaled dynamically out-of-band (e.g., using SDP; Section 7.1.3 defines the name binding).
ペイロードタイプ（PT）：このパケット形式のRTPペイロードタイプの割り当ては、このドキュメントの範囲外です。これは、このペイロード形式が使用されるRTPプロファイルによって指定されるか、または帯域外で動的に通知される可能性が高くなります（たとえば、SDPを使用して、セクション7.1.3は名前バインディングを定義します）。
Marker (M) bit: If the received RTP packet is looped back in multiple encapsulating RTP packets, the M bit is set to 1 in every fragment except the last packet; otherwise, it is set to 0.
マーカー（M）ビット：受信したRTPパケットが複数のカプセル化RTPパケットにループバックされる場合、Mビットは最後のパケットを除くすべてのフラグメントで1に設定されます。それ以外の場合は0に設定されます。
Extension (X) bit: This bit is defined by the RTP profile used.
拡張（X）ビット：このビットは、使用されるRTPプロファイルによって定義されます。
Sequence Number: The RTP sequence number SHOULD be generated by the loopback mirror in the usual manner with a constant random offset as described in RFC 3550 [RFC3550].
シーケンス番号：RTPシーケンス番号は、RFC 3550 [RFC3550]で説明されているように、一定のランダムオフセットを使用して通常の方法でループバックミラーによって生成される必要があります（SHOULD）。
Timestamp: The RTP timestamp denotes the sampling instant for when the loopback mirror is transmitting this packet to the loopback source. The RTP timestamp MUST use the same clock rate as that of the encapsulated packet. The initial value of the timestamp SHOULD be random for security reasons (see Section 5.1 of RFC 3550 [RFC3550]).
タイムスタンプ：RTPタイムスタンプは、ループバックミラーがこのパケットをループバックソースに送信しているときのサンプリングの瞬間を示します。 RTPタイムスタンプは、カプセル化されたパケットと同じクロックレートを使用する必要があります。タイムスタンプの初期値は、セキュリティ上の理由からランダムにする必要があります（RFC 3550 [RFC3550]のセクション5.1を参照）。
Synchronization source (SSRC): This field is set as described in RFC 3550 [RFC3550].
同期ソース（SSRC）：このフィールドは、RFC 3550 [RFC3550]で説明されているように設定されます。
The CSRC count (CC) and contributing source (CSRC) fields are used as described in RFC 3550 [RFC3550].
RFC3550 [RFC3550]で説明されているように、CSRCカウント（CC）および提供元（CSRC）フィールドが使用されます。
The outer RTP header of the encapsulating packet is followed by the payload header defined in this section, after any header extension(s). If the received RTP packet has to be looped back in multiple encapsulating packets due to fragmentation, the encapsulating RTP header in each packet is followed by the payload header defined in this section. The header is devised so that the loopback source can decode looped-back packets in the presence of moderate packet loss [RFC3550]. The RTP payload of the encapsulating RTP packet starts with the payload header defined in this section.
カプセル化パケットの外部RTPヘッダーの後には、ヘッダー拡張の後に、このセクションで定義されたペイロードヘッダーが続きます。フラグメント化のために受信したRTPパケットを複数のカプセル化パケットにループバックする必要がある場合、各パケットのカプセル化RTPヘッダーの後に、このセクションで定義されているペイロードヘッダーが続きます。ヘッダーは、ループバックソースが中程度のパケット損失がある場合にループバックパケットをデコードできるように考案されています[RFC3550]。カプセル化RTPパケットのRTPペイロードは、このセクションで定義されたペイロードヘッダーで始まります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| receive timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F | R | CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| transmit timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Encapsulating RTP Packet Payload Header
図1. RTPパケットペイロードヘッダーのカプセル化
The 12 octets after the receive timestamp are identical to the encapsulated RTP header of the received packet except for the first 2 bits of the first octet. In effect, the received RTP packet is encapsulated by creating a new outer RTP header followed by 4 new bytes of a receive timestamp, followed by the original received RTP header and payload, except that the first two bits of the received RTP header are overwritten as defined here.
受信タイムスタンプの後の12オクテットは、最初のオクテットの最初の2ビットを除いて、受信パケットのカプセル化されたRTPヘッダーと同じです。実際には、受信したRTPパケットのカプセル化は、新しい外部RTPヘッダーを作成し、その後に受信タイムスタンプの4バイトを追加し、その後に元の受信したRTPヘッダーとペイロードを続けます。ただし、受信したRTPヘッダーの最初の2ビットは、ここで定義されます。
Receive timestamp: 32 bits
受信タイムスタンプ：32ビット
The receive timestamp denotes the sampling instant for when the last octet of the received media packet that is being encapsulated by the loopback mirror is received from the loopback source. The same clock rate MUST be used by the loopback source. The initial value of the timestamp SHOULD be random for security reasons (see Section 5.1 of RFC 3550 [RFC3550]).
受信タイムスタンプは、ループバックミラーによってカプセル化されている受信メディアパケットの最後のオクテットがループバックソースから受信されたときのサンプリングの瞬間を示します。ループバックソースでも同じクロックレートを使用する必要があります。タイムスタンプの初期値は、セキュリティ上の理由からランダムにする必要があります（RFC 3550 [RFC3550]のセクション5.1を参照）。
Fragmentation (F): 2 bits
フラグメンテーション（F）：2ビット
Possible values are First Fragment (00), Last Fragment (01), No Fragmentation (10), or Intermediate Fragment (11). This field identifies how much of the received packet is encapsulated in this packet by the loopback mirror. If the received packet is not fragmented, this field is set to 10; otherwise, the packet that contains the first fragments sets this field to 00. The packet that contains the last fragment sets this field to 01, and all other packets set this field to 11.
可能な値は、First Fragment（00）、Last Fragment（01）、No Fragmentation（10）、またはIntermediate Fragment（11）です。このフィールドは、受信したパケットのうち、ループバックミラーによってこのパケットにカプセル化される量を示します。受信したパケットがフラグメント化されていない場合、このフィールドは10に設定されます。それ以外の場合、最初のフラグメントを含むパケットはこのフィールドを00に設定します。最後のフラグメントを含むパケットはこのフィールドを01に設定し、他のすべてのパケットはこのフィールドを11に設定します。
The payload type number for the encapsulated stream can be negotiated using SDP. There is no static payload type assignment for the encapsulating stream, so dynamic payload type numbers MUST be used. The binding to the name is indicated by an rtpmap attribute. The name used in this binding is "encaprtp".
カプセル化されたストリームのペイロードタイプ番号は、SDPを使用してネゴシエートできます。カプセル化ストリームには静的なペイロードタイプの割り当てがないため、動的なペイロードタイプ番号を使用する必要があります。名前へのバインディングは、rtpmap属性によって示されます。このバインディングで使用される名前は「encaprtp」です。
The following is an example SDP fragment for encapsulated RTP.
以下は、カプセル化されたRTPのSDPフラグメントの例です。
m=audio 41352 RTP/AVP 112
a=rtpmap:112 encaprtp/8000
The direct loopback RTP payload format can be used in scenarios where the 16-byte overhead of the encapsulated payload format is of concern, or simply due to local policy. When using this payload format, the receiver loops back each received RTP packet payload (not header) in a separate RTP packet.
直接ループバックRTPペイロード形式は、カプセル化されたペイロード形式の16バイトのオーバーヘッドが懸念されるシナリオで、または単にローカルポリシーのために使用できます。このペイロード形式を使用する場合、レシーバーは受信した各RTPパケットペイロード（ヘッダーではない）を個別のRTPパケットにループバックします。
Because a direct loopback format does not retain the original RTP headers, there will be no indication of the original payload-type sent to the mirror, in looped-back packets. Therefore, the loopback source SHOULD only send one payload type per loopback RTP session if direct mode is used.
直接ループバック形式では元のRTPヘッダーが保持されないため、ループバックされたパケットでは、ミラーに送信された元のペイロードタイプが示されません。したがって、ダイレクトモードが使用されている場合、ループバックソースは、ループバックRTPセッションごとに1つのペイロードタイプのみを送信する必要があります。
Payload Type (PT): The assignment of an RTP payload type for the encapsulating packet format is outside the scope of this document; it is either specified by the RTP profile under which this payload format is used or more likely signaled dynamically out-of-band (e.g., using SDP; Section 7.2.3 defines the name binding).
ペイロードタイプ（PT）：カプセル化パケット形式へのRTPペイロードタイプの割り当ては、このドキュメントの範囲外です。これは、このペイロード形式が使用されるRTPプロファイルによって指定されるか、または帯域外で動的にシグナリングされる可能性が高くなります（たとえば、SDPを使用して、セクション7.2.3は名前バインディングを定義します）。
Marker (M) bit: This bit is set to the value in the received packet.
マーカー（M）ビット：このビットは、受信したパケットの値に設定されます。
Extension (X) bit: This bit is defined by the RTP profile used.
拡張（X）ビット：このビットは、使用されるRTPプロファイルによって定義されます。
Sequence Number: The RTP sequence number SHOULD be generated by the loopback mirror in the usual manner with a constant random offset, as per [RFC3550].
シーケンス番号：RTPシーケンス番号は、[RFC3550]のように、一定のランダムオフセットを使用して通常の方法でループバックミラーによって生成される必要があります（SHOULD）。
Timestamp: The RTP timestamp denotes the sampling instant for when the loopback mirror is transmitting this packet to the loopback source. The same clock rate MUST be used as that of the received RTP packet. The initial value of the timestamp SHOULD be random for security reasons (see Section 5.1 of RFC 3550 [RFC3550]).
タイムスタンプ：RTPタイムスタンプは、ループバックミラーがこのパケットをループバックソースに送信しているときのサンプリングの瞬間を示します。受信したRTPパケットと同じクロックレートを使用する必要があります。タイムスタンプの初期値は、セキュリティ上の理由からランダムにする必要があります（RFC 3550 [RFC3550]のセクション5.1を参照）。
SSRC: This field is set as described in RFC 3550 [RFC3550].
SSRC：このフィールドは、RFC 3550 [RFC3550]で説明されているように設定されます。
The CC and CSRC fields are used as described in RFC 3550 [RFC3550].
CCおよびCSRCフィールドは、RFC 3550 [RFC3550]で説明されているように使用されます。
This payload format does not define any payload-specific headers. The loopback mirror simply copies the RTP payload data from the payload portion of the RTP packet received from the loopback source.
このペイロード形式では、ペイロード固有のヘッダーは定義されていません。ループバックミラーは、ループバックソースから受信したRTPパケットのペイロード部分からRTPペイロードデータをコピーするだけです。
The payload type number for the payload loopback stream can be negotiated using a mechanism like SDP. There is no static payload type assignment for the stream, so dynamic payload type numbers MUST be used. The binding to the name is indicated by an rtpmap attribute. The name used in this binding is "rtploopback".
ペイロードループバックストリームのペイロードタイプ番号は、SDPなどのメカニズムを使用してネゴシエートできます。ストリームには静的なペイロードタイプの割り当てがないため、動的なペイロードタイプ番号を使用する必要があります。名前へのバインディングは、rtpmap属性によって示されます。このバインディングで使用される名前は「rtploopback」です。
The following is an example SDP fragment for the direct loopback RTP format.
次に、ダイレクトループバックRTPフォーマットのSDPフラグメントの例を示します。
m=audio 41352 RTP/AVP 112
a=rtpmap:112 rtploopback/8000
Secure RTP (SRTP) [RFC3711] MAY be used for loopback sessions. SRTP operates at a lower logical layer than RTP, and thus if both sides negotiate to use SRTP, each side uses its own key and performs encryption/decryption, authentication, etc. Therefore, the loopback function on the mirror occurs after the SRTP packet has been decrypted and authenticated, as a normal cleartext RTP packet without a Master Key Identifier (MKI) or authentication tag; once the cleartext RTP packet or payload is mirrored -- either at the media-layer, direct packet-layer, or encapsulated packet-layer -- it is encrypted by the mirror using its own key.
Secure RTP（SRTP）[RFC3711]は、ループバックセッションに使用できます。 SRTPはRTPよりも下位の論理層で動作するため、両側がSRTPを使用するようにネゴシエートする場合、両側が独自のキーを使用して暗号化/復号化、認証などを実行します。マスターキー識別子（MKI）または認証タグのない通常のクリアテキストRTPパケットとして復号化および認証されます。クリアテキストRTPパケットまたはペイロードがミラーリングされると（メディアレイヤー、ダイレクトパケットレイヤー、またはカプセル化されたパケットレイヤーのいずれかで）、独自のキーを使用してミラーによって暗号化されます。
In order to provide the same level of protection to both forward and reverse media flows (media to and from the mirror), if SRTP is used it MUST be used in both directions with the same properties.
フォワードとリバースの両方のメディアフロー（ミラーへのメディアとミラーからのメディア）に同じレベルの保護を提供するために、SRTPを使用する場合は、双方向で同じプロパティを使用する必要があります。
The use of the loopback attribute is intended for the monitoring of media quality of the session. Consequently, the media performance information should be exchanged between the offering and the answering entities. An offering or answering agent that is compliant to this specification SHOULD support RTCP per [RFC3550] and RTCP-XR per RFC 3611 [RFC3611]. Furthermore, if the offerer or answerer chooses to support RTCP-XR, they SHOULD support the RTCP-XR Loss Run Length Encoding (RLE) Report Block, Duplicate RLE Report Block, Statistics Summary Report Block, and VoIP Metrics Report Block per Sections 4.1, 4.2, 4.6, and 4.7 of RFC 3611 [RFC3611]. The offerer and the answerer MAY support other RTCP-XR reporting blocks as defined by RFC 3611 [RFC3611].
loopback属性の使用は、セッションのメディア品質の監視を目的としています。したがって、メディアのパフォーマンス情報は、オファリングと応答エンティティの間で交換する必要があります。この仕様に準拠するオファリングまたは応答エージェントは、[RFC3550]によるRTCPおよびRFC 3611 [RFC3611]によるRTCP-XRをサポートする必要があります（SHOULD）。さらに、提供者または回答者がRTCP-XRのサポートを選択した場合、セクション4.1に従って、RTCP-XRロスランレングスエンコーディング（RLE）レポートブロック、重複RLEレポートブロック、統計要約レポートブロック、およびVoIPメトリックレポートブロックをサポートする必要があります。 RFC 3611 [RFC3611]の4.2、4.6、4.7。提供者と回答者は、RFC 3611 [RFC3611]で定義されている他のRTCP-XRレポートブロックをサポートする場合があります。
All the participants in a media-level loopback session SHOULD implement congestion control mechanisms as defined by the RTP profile under which the loopback mechanism is implemented. For audio/video profiles, implementations SHOULD conform to the mechanism defined in Section 2 of RFC 3551 [RFC3551].
メディアレベルのループバックセッションのすべての参加者は、ループバックメカニズムが実装されているRTPプロファイルで定義されているように、輻輳制御メカニズムを実装する必要があります（SHOULD）。音声/動画プロファイルの場合、実装はRFC 3551 [RFC3551]のセクション2で定義されたメカニズムに準拠する必要があります（SHOULD）。
For packet-level loopback types, the loopback source SHOULD implement congestion control. The mirror will simply reflect back the RTP packets it receives (either in encapsulated or direct modes); therefore, the source needs to control the congestion of both forward and reverse paths by reducing its sending rate to the mirror. This keeps the loopback mirror implementation simpler and provides more flexibility for the source performing a loopback test.
パケットレベルのループバックタイプの場合、ループバックソースは輻輳制御を実装する必要があります（SHOULD）。ミラーは、それが受信したRTPパケットを単純に反射します（カプセル化モードまたは直接モードのいずれかで）。したがって、ソースはミラーへの送信レートを下げることにより、フォワードパスとリバースパスの両方の輻輳を制御する必要があります。これにより、ループバックミラーの実装がよりシンプルになり、ループバックテストを実行するソースの柔軟性が向上します。
This section provides examples for media descriptions using SDP for different scenarios. The examples are given for SIP-based transactions; for convenience, they are abbreviated and do not show the complete signaling.
このセクションでは、さまざまなシナリオでSDPを使用するメディア記述の例を示します。 SIPベースのトランザクションの例を示します。便宜上、これらは省略されており、完全なシグナリングを示していません。
An agent sends an SDP offer that looks like:
エージェントは次のようなSDPオファーを送信します。
v=0
o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com
s=-
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=loopback:rtp-media-loopback
a=loopback-source
a=rtpmap:0 pcmu/8000
The agent is offering to source the media and expects the answering agent to mirror the RTP stream per the loopback type rtp-media-loopback.
エージェントはメディアを提供することを申し出ており、応答エージェントがループバックタイプrtp-media-loopbackごとにRTPストリームをミラーリングすることを期待しています。
An answering agent sends an SDP answer that looks like:
応答エージェントは、次のようなSDP応答を送信します。
v=0
o=bob 1234567890 1122334455 IN IP4 host.biloxi.example.com
s=-
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49270 RTP/AVP 0
a=loopback:rtp-media-loopback
a=loopback-mirror
a=rtpmap:0 pcmu/8000
The answerer agrees to mirror the media from the offerer at the media level.
回答者は、メディアレベルで提供者からのメディアをミラーリングすることに同意します。
An agent sends an SDP offer that looks like:
エージェントは次のようなSDPオファーを送信します。
v=0 o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com s=- c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 112 113 a=loopback:rtp-media-loopback rtp-pkt-loopback a=loopback-source a=rtpmap:0 pcmu/8000 a=rtpmap:112 encaprtp/8000 a=rtpmap:113 rtploopback/8000 The offerer is offering to source the media and expects the answerer to mirror the RTP stream at either the media or RTP level.
v = 0 o = alice 2890844526 2890842807 IN IP4 host.atlanta.example.com s =-c = IN IP4 host.atlanta.example.com t = 0 0 m = audio 49170 RTP / AVP 0112113 a = loopback：rtp -media-loopback rtp-pkt-loopback a = loopback-source a = rtpmap：0 pcmu / 8000 a = rtpmap：112 encaprtp / 8000 a = rtpmap：113 rtploopback / 8000提供者はメディアを提供することを申し出ており、回答者に期待していますメディアまたはRTPレベルでRTPストリームをミラーリングします。
An answering agent sends an SDP answer that looks like:
応答エージェントは、次のようなSDP応答を送信します。
v=0
o=bob 1234567890 1122334455 IN IP4 host.biloxi.example.com
s=-
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49270 RTP/AVP 0 112
a=loopback:rtp-pkt-loopback
a=loopback-mirror
a=rtpmap:0 pcmu/8000
a=rtpmap:112 encaprtp/8000
The answerer agrees to mirror the media from the offerer at the packet level using the encapsulated RTP payload format.
回答者は、カプセル化されたRTPペイロード形式を使用して、提供者からのメディアをパケットレベルでミラーリングすることに同意します。
An agent sends an SDP offer that looks like:
エージェントは次のようなSDPオファーを送信します。
v=0
o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com
s=-
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=loopback:rtp-media-loopback
a=loopback-source
a=rtpmap:0 pcmu/8000
The offerer is offering to source the media and expects the answerer to mirror the RTP stream at the media level.
提案者はメディアを調達することを提案しており、回答者がメディアレベルでRTPストリームをミラーリングすることを期待しています。
An answering agent sends an SDP answer that looks like:
応答エージェントは、次のようなSDP応答を送信します。
v=0 o=bob 1234567890 1122334455 IN IP4 host.biloxi.example.com s=- c=IN IP4 host.biloxi.example.com t=0 0 m=audio 0 RTP/AVP 0 a=rtpmap:0 pcmu/8000 Note in this case that the answerer did not indicate loopback support, although it could have and still used a port number of 0 to indicate that it does not wish to accept that media session.
v = 0 o = bob 1234567890 1122334455 IN IP4 host.biloxi.example.com s =-c = IN IP4 host.biloxi.example.com t = 0 0 m = audio 0 RTP / AVP 0 a = rtpmap：0 pcmu / 8000この場合、アンサーがループバックサポートを示していないことに注意してください。ただし、ポート番号0を使用していても、そのメディアセッションを受け入れたくないことを示しています。
Alternatively, the answering agent could have simply rejected the entire SDP offer through some higher-layer signaling protocol means (e.g., by rejecting the SIP INVITE request if the SDP offer was in the INVITE).
または、応答エージェントは、上位層のシグナリングプロトコル手段を介してSDPオファー全体を単に拒否することもできます（たとえば、SDPオファーがINVITEにある場合、SIP INVITE要求を拒否することにより）。
The security considerations of [RFC3264] and [RFC3550] apply.
[RFC3264]と[RFC3550]のセキュリティに関する考慮事項が適用されます。
Given that media loopback may be automated without the end user's knowledge, the answerer of the media loopback should be aware of denial-of-service attacks. It is RECOMMENDED that session requests for media loopback be authenticated and the frequency of such sessions limited by the answerer.
メディアループバックはエンドユーザーの知らないうちに自動化される可能性があるため、メディアループバックの回答者はサービス拒否攻撃を認識する必要があります。メディアループバックのセッション要求を認証し、そのようなセッションの頻度を回答者が制限することをお勧めします。
If the higher-layer signaling protocol were not authenticated, a malicious attacker could create a session between two parties the attacker wishes to target, with each party acting as the loopback mirror to the other, of the rtp-pkt-loopback type. A few RTP packets sent to either party would then infinitely loop among the two, as fast as they could process them, consuming their resources and network bandwidth.
上位層のシグナリングプロトコルが認証されなかった場合、悪意のある攻撃者は、攻撃者がターゲットにしたい2つのパーティ間にセッションを作成し、各パーティが他方に対するループバックミラーとして機能し、rtp-pkt-loopbackタイプを実行する可能性があります。いずれかの当事者に送信されたいくつかのRTPパケットは、2つの間で無限にループし、それらが処理できるのと同じ速さで、リソースとネットワーク帯域幅を消費します。
Furthermore, media loopback provides a means of attack indirection, whereby a malicious attacker creates a loopback session as the loopback source and uses the mirror to reflect the attacker's packets against a target -- perhaps a target the attacker could not reach directly, such as one behind a firewall, for example. Or, the attacker could initiate the session as the loopback mirror, in the hopes of making the peer generate media against another target.
さらに、メディアループバックは攻撃を間接的に行う手段を提供します。これにより、悪意のある攻撃者はループバックソースとしてループバックセッションを作成し、ミラーを使用してターゲットに対する攻撃者のパケットを反映します。たとえば、ファイアウォールの背後。または、攻撃者は、ピアが別のターゲットに対してメディアを生成することを期待して、ループバックミラーとしてセッションを開始する可能性があります。
If end-user devices such as mobile phones answer loopback requests without authentication and without notifying the end user, then an attacker could cause the battery to drain, and possibly deny the end user normal phone service or cause network data usage fees. This could even occur naturally if a legitimate loopback session does not terminate properly and the end device does not have a timeout mechanism for such.
携帯電話などのエンドユーザーデバイスが認証なしでエンドユーザーに通知せずにループバックリクエストに応答した場合、攻撃者はバッテリーを消耗させ、エンドユーザーの通常の電話サービスを拒否したり、ネットワークデータ使用料を発生させたりする可能性があります。これは、正当なループバックセッションが適切に終了せず、エンドデバイスにそのためのタイムアウトメカニズムがない場合、自然に発生する可能性もあります。
For the reasons noted above, end-user devices SHOULD provide a means of indicating to the human user that the device is in a loopback session, even if it is an authenticated session. Devices that answer or generate loopback sessions SHOULD either perform keepalive/refresh tests of the session state through some means or time out the session automatically.
上記の理由により、エンドユーザーデバイスは、認証されたセッションであっても、デバイスがループバックセッションであることを人間のユーザーに示す手段を提供する必要があります（SHOULD）。ループバックセッションに応答または生成するデバイスは、何らかの方法でセッション状態のキープアライブ/更新テストを実行するか、セッションを自動的にタイムアウトする必要があります（SHOULD）。
The media loopback approach described in this document is a complete solution that would work under all scenarios. However, it is possible that the solution may not be lightweight enough for some implementations. In light of this concern, this section clarifies which features of the loopback proposal MUST be implemented for all implementations and which features MAY be deferred if the complete solution is not desired.
このドキュメントで説明するメディアループバックアプローチは、すべてのシナリオで機能する完全なソリューションです。ただし、一部の実装では、ソリューションが十分に軽量でない可能性があります。この懸念に照らして、このセクションでは、ループバックプロポーザルのどの機能をすべての実装に実装する必要があるか、および完全なソリューションが必要ない場合はどの機能を延期する必要があるかを明確にします。
All implementations MUST at least support the rtp-pkt-loopback mode for loopback-type, with direct media loopback payload encoding. In addition, for the loopback role, all implementations of an SDP offerer MUST at least be able to act as a loopback source. These requirements are intended to provide a minimal level of interoperability between different implementations.
すべての実装は、直接メディアループバックペイロードエンコーディングを使用して、少なくともループバックタイプのrtp-pkt-loopbackモードをサポートする必要があります。さらに、ループバックの役割では、SDPオファーのすべての実装が少なくともループバックソースとして機能できる必要があります。これらの要件は、異なる実装間で最小レベルの相互運用性を提供することを目的としています。
This document defines three new media-level SDP attributes. IANA has registered the following attributes.
このドキュメントでは、3つの新しいメディアレベルのSDP属性を定義しています。 IANAは以下の属性を登録しています。
Contact name: Kaynam Hedayat Email address: kh274@cornell.edu Telephone number: +1-617-899-3279 Attribute name: loopback Type of attribute: Media level. Subject to charset: No. Purpose of attribute: The 'loopback' attribute is used to indicate the type of media loopback. Allowed attribute values: The parameters for 'loopback' may be one or more of "rtp-pkt-loopback" and "rtp-media-loopback". See Section 4 of RFC 6849 for syntax.
連絡先名：Kaynam Hedayatメールアドレス：kh274@cornell.edu電話番号：+ 1-617-899-3279属性名：loopback属性のタイプ：メディアレベル。 charsetの対象：いいえ。属性の目的： 'loopback'属性は、メディアループバックのタイプを示すために使用されます。許可された属性値： 'loopback'のパラメーターは、「rtp-pkt-loopback」および「rtp-media-loopback」の1つ以上です。構文については、RFC 6849のセクション4をご覧ください。
Contact name: Kaynam Hedayat Email address: kh274@cornell.edu Telephone number: +1-617-899-3279 Attribute name: loopback-source Type of attribute: Media level. Subject to charset: No. Purpose of attribute: The 'loopback-source' attribute specifies that the sender is the media source and expects the receiver to act as a loopback mirror. Allowed attribute values: N/A
連絡先名：Kaynam Hedayatメールアドレス：kh274@cornell.edu電話番号：+ 1-617-899-3279属性名：loopback-source属性のタイプ：メディアレベル。 charsetの対象：いいえ。属性の目的： 'loopback-source'属性は、送信者がメディアソースであり、受信者がループバックミラーとして機能することを期待することを指定します。許可された属性値：N / A
Contact name: Kaynam Hedayat Email address: kh274@cornell.edu Telephone number: +1-617-899-3279 Attribute name: loopback-mirror Type of attribute: Media level. Subject to charset: No. Purpose of attribute: The 'loopback-mirror' attribute specifies that the receiver will mirror (echo) all received media back to the sender of the RTP stream. Allowed attribute values: N/A
連絡先名：Kaynam Hedayatメールアドレス：kh274@cornell.edu電話番号：+ 1-617-899-3279属性名：loopback-mirror属性のタイプ：メディアレベル。 charsetの対象：いいえ。属性の目的： 'loopback-mirror'属性は、受信者が受信したすべてのメディアをRTPストリームの送信者にミラーリング（エコー）することを指定します。許可された属性値：N / A
The IANA has registered the following media types.
IANAは次のメディアタイプを登録しています。
To: ietf-types@iana.org
と： いえｔｆーｔｙぺｓ＠いあな。おｒｇ
Subject: Registration of media type audio/encaprtp
件名：メディアタイプaudio / encaprtpの登録
Type name: audio
タイプ名：オーディオ
Subtype name: encaprtp
サブタイプ名：encaprtp
Required parameters:
必須パラメーター：
rate: RTP timestamp clock rate, which is equal to the sampling rate. This is specified by the loopback source and reflected by the mirror.
rate：RTPタイムスタンプクロックレート。サンプリングレートと同じです。これは、ループバックソースによって指定され、ミラーによって反映されます。
Optional parameters: N/A
オプションのパラメーター：N / A
Encoding considerations: This media type is framed.
エンコードに関する考慮事項：このメディアタイプはフレーム化されています。
Security considerations: See Section 12 of RFC 6849.
セキュリティに関する考慮事項：RFC 6849のセクション12をご覧ください。
Interoperability considerations: N/A
相互運用性に関する考慮事項：N / A
Published specification: RFC 6849.
公開された仕様：RFC 6849。
Applications that use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given VoIP service.
このメディアタイプを使用するアプリケーション：特定のVoIPサービスのエッジへの転送品質を監視および保証する必要があるアプリケーション。
Additional information: N/A
追加情報：なし
Contact: the authors of RFC 6849.
連絡先：RFC 6849の作成者。
Intended usage: LIMITED USE
使用目的：限定使用
Restrictions on usage: This media type depends on RTP framing and hence is only defined for transfer via RTP. Transfer within other framing protocols is not defined at this time.
使用の制限：このメディアタイプはRTPフレーミングに依存するため、RTP経由の転送に対してのみ定義されます。現在、他のフレーミングプロトコル内での転送は定義されていません。
Author: Kaynam Hedayat.
著者：ケイナム・ヘダヤット。
Change controller: IETF PAYLOAD working group delegated from the IESG.
コントローラの変更：IESGから委任されたIETF PAYLOADワーキンググループ。
To: ietf-types@iana.org
と： いえｔｆーｔｙぺｓ＠いあな。おｒｇ
Subject: Registration of media type video/encaprtp
件名：メディアタイプvideo / encaprtpの登録
Type name: video
タイプ名：ビデオ
Subtype name: encaprtp
サブタイプ名：encaprtp
Required parameters:
必須パラメーター：
rate: RTP timestamp clock rate, which is equal to the sampling rate. This is specified by the loopback source and reflected by the mirror.
rate：RTPタイムスタンプクロックレート。サンプリングレートと同じです。これは、ループバックソースによって指定され、ミラーによって反映されます。
Optional parameters: N/A
オプションのパラメーター：N / A
Encoding considerations: This media type is framed.
エンコードに関する考慮事項：このメディアタイプはフレーム化されています。
Security considerations: See Section 12 of RFC 6849.
セキュリティに関する考慮事項：RFC 6849のセクション12をご覧ください。
Interoperability considerations: N/A Published specification: RFC 6849.
相互運用性に関する考慮事項：N / A公開仕様：RFC 6849。
Applications that use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given Video Over IP service.
このメディアタイプを使用するアプリケーション：特定のビデオオーバーIPサービスのエッジへの転送品質を監視および保証する必要があるアプリケーション。
Additional information: N/A
追加情報：なし
Contact: the authors of RFC 6849.
連絡先：RFC 6849の作成者。
Intended usage: LIMITED USE
使用目的：限定使用
Restrictions on usage: This media type depends on RTP framing and hence is only defined for transfer via RTP. Transfer within other framing protocols is not defined at this time.
使用の制限：このメディアタイプはRTPフレーミングに依存するため、RTP経由の転送に対してのみ定義されます。現在、他のフレーミングプロトコル内での転送は定義されていません。
Author: Kaynam Hedayat.
著者：ケイナム・ヘダヤット。
Change controller: IETF PAYLOAD working group delegated from the IESG.
コントローラの変更：IESGから委任されたIETF PAYLOADワーキンググループ。
To: ietf-types@iana.org
と： いえｔｆーｔｙぺｓ＠いあな。おｒｇ
Subject: Registration of media type text/encaprtp
件名：メディアタイプtext / encaprtpの登録
Type name: text
タイプ名：テキスト
Subtype name: encaprtp
サブタイプ名：encaprtp
Required parameters:
必須パラメーター：
rate: RTP timestamp clock rate, which is equal to the sampling rate. This is specified by the loopback source and reflected by the mirror.
rate：RTPタイムスタンプクロックレート。サンプリングレートと同じです。これは、ループバックソースによって指定され、ミラーによって反映されます。
Optional parameters: N/A
オプションのパラメーター：N / A
Encoding considerations: This media type is framed.
エンコードに関する考慮事項：このメディアタイプはフレーム化されています。
Security considerations: See Section 12 of RFC 6849.
セキュリティに関する考慮事項：RFC 6849のセクション12をご覧ください。
Interoperability considerations: N/A
相互運用性に関する考慮事項：N / A
Published specification: RFC 6849.
公開された仕様：RFC 6849。
Applications that use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given real-time text service.
このメディアタイプを使用するアプリケーション：特定のリアルタイムテキストサービスのエッジへの転送品質を監視および保証する必要があるアプリケーション。
Additional information: N/A
追加情報：なし
Contact: the authors of RFC 6849.
連絡先：RFC 6849の作成者。
Intended usage: LIMITED USE
使用目的：限定使用
Restrictions on usage: This media type depends on RTP framing and hence is only defined for transfer via RTP. Transfer within other framing protocols is not defined at this time.
使用の制限：このメディアタイプはRTPフレーミングに依存するため、RTP経由の転送に対してのみ定義されます。現在、他のフレーミングプロトコル内での転送は定義されていません。
Author: Kaynam Hedayat.
著者：ケイナム・ヘダヤット。
Change controller: IETF PAYLOAD working group delegated from the IESG.
コントローラの変更：IESGから委任されたIETF PAYLOADワーキンググループ。
To: ietf-types@iana.org
と： いえｔｆーｔｙぺｓ＠いあな。おｒｇ
Subject: Registration of media type application/encaprtp
件名：メディアタイプapplication / encaprtpの登録
Type name: application
タイプ名：アプリケーション
Subtype name: encaprtp
サブタイプ名：encaprtp
Required parameters:
必須パラメーター：
rate: RTP timestamp clock rate, which is equal to the sampling rate. This is specified by the loopback source and reflected by the mirror.
rate：RTPタイムスタンプクロックレート。サンプリングレートと同じです。これは、ループバックソースによって指定され、ミラーによって反映されます。
Optional parameters: N/A
オプションのパラメーター：N / A
Encoding considerations: This media type is framed.
エンコードに関する考慮事項：このメディアタイプはフレーム化されています。
Security considerations: See Section 12 of RFC 6849.
セキュリティに関する考慮事項：RFC 6849のセクション12をご覧ください。
Interoperability considerations: N/A
相互運用性に関する考慮事項：N / A
Published specification: RFC 6849.
公開された仕様：RFC 6849。
Applications that use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given real-time application service.
このメディアタイプを使用するアプリケーション：特定のリアルタイムアプリケーションサービスのエッジへのトランスポートの品質を監視および保証する必要があるアプリケーション。
Additional information: N/A
追加情報：なし
Contact: the authors of RFC 6849.
連絡先：RFC 6849の作成者。
Intended usage: LIMITED USE
使用目的：限定使用
Restrictions on usage: This media type depends on RTP framing and hence is only defined for transfer via RTP. Transfer within other framing protocols is not defined at this time.
使用の制限：このメディアタイプはRTPフレーミングに依存するため、RTP経由の転送に対してのみ定義されます。現在、他のフレーミングプロトコル内での転送は定義されていません。
Author: Kaynam Hedayat.
著者：ケイナム・ヘダヤット。
Change controller: IETF PAYLOAD working group delegated from the IESG.
コントローラの変更：IESGから委任されたIETF PAYLOADワーキンググループ。
To: ietf-types@iana.org
と： いえｔｆーｔｙぺｓ＠いあな。おｒｇ
Subject: Registration of media type audio/rtploopback
件名：メディアタイプaudio / rtploopbackの登録
Type name: audio
タイプ名：オーディオ
Subtype name: rtploopback
サブタイプ名：rtploopback
Required parameters:
必須パラメーター：
rate: RTP timestamp clock rate, which is equal to the sampling rate. This is specified by the loopback source and reflected by the mirror.
rate：RTPタイムスタンプクロックレート。サンプリングレートと同じです。これは、ループバックソースによって指定され、ミラーによって反映されます。
Optional parameters: N/A
オプションのパラメーター：N / A
Encoding considerations: This media type is framed.
エンコードに関する考慮事項：このメディアタイプはフレーム化されています。
Security considerations: See Section 12 of RFC 6849.
セキュリティに関する考慮事項：RFC 6849のセクション12をご覧ください。
Interoperability considerations: N/A
相互運用性に関する考慮事項：N / A
Published specification: RFC 6849.
公開された仕様：RFC 6849。
Applications that use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given VoIP service.
このメディアタイプを使用するアプリケーション：特定のVoIPサービスのエッジへの転送品質を監視および保証する必要があるアプリケーション。
Additional information: N/A
追加情報：なし
Contact: the authors of RFC 6849.
連絡先：RFC 6849の作成者。
Intended usage: LIMITED USE
使用目的：限定使用
Restrictions on usage: This media type depends on RTP framing and hence is only defined for transfer via RTP. Transfer within other framing protocols is not defined at this time.
使用の制限：このメディアタイプはRTPフレーミングに依存するため、RTP経由の転送に対してのみ定義されます。現在、他のフレーミングプロトコル内での転送は定義されていません。
Author: Kaynam Hedayat.
著者：ケイナム・ヘダヤット。
Change controller: IETF PAYLOAD working group delegated from the IESG.
コントローラの変更：IESGから委任されたIETF PAYLOADワーキンググループ。
To: ietf-types@iana.org
と： いえｔｆーｔｙぺｓ＠いあな。おｒｇ
Subject: Registration of media type video/rtploopback
件名：メディアタイプvideo / rtploopbackの登録
Type name: video
タイプ名：ビデオ
Subtype name: rtploopback
サブタイプ名：rtploopback
Required parameters:
必須パラメーター：
rate: RTP timestamp clock rate, which is equal to the sampling rate. This is specified by the loopback source and reflected by the mirror.
rate：RTPタイムスタンプクロックレート。サンプリングレートと同じです。これは、ループバックソースによって指定され、ミラーによって反映されます。
Optional parameters: N/A
オプションのパラメーター：N / A
Encoding considerations: This media type is framed.
エンコードに関する考慮事項：このメディアタイプはフレーム化されています。
Security considerations: See Section 12 of RFC 6849.
セキュリティに関する考慮事項：RFC 6849のセクション12をご覧ください。
Interoperability considerations: N/A
相互運用性に関する考慮事項：N / A
Published specification: RFC 6849.
公開された仕様：RFC 6849。
Applications that use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given Video Over IP service.
このメディアタイプを使用するアプリケーション：特定のビデオオーバーIPサービスのエッジへの転送品質を監視および保証する必要があるアプリケーション。
Additional information: N/A
追加情報：なし
Contact: the authors of RFC 6849.
連絡先：RFC 6849の作成者。
Intended usage: LIMITED USE Restrictions on usage: This media type depends on RTP framing and hence is only defined for transfer via RTP. Transfer within other framing protocols is not defined at this time.
使用目的：制限付き使用法使用法の制限：このメディアタイプはRTPフレーミングに依存するため、RTP経由の転送に対してのみ定義されます。現在、他のフレーミングプロトコル内での転送は定義されていません。
Author: Kaynam Hedayat.
著者：ケイナム・ヘダヤット。
Change controller: IETF PAYLOAD working group delegated from the IESG.
コントローラの変更：IESGから委任されたIETF PAYLOADワーキンググループ。
To: ietf-types@iana.org
と： いえｔｆーｔｙぺｓ＠いあな。おｒｇ
Subject: Registration of media type text/rtploopback
件名：メディアタイプtext / rtploopbackの登録
Type name: text
タイプ名：テキスト
Subtype name: rtploopback
サブタイプ名：rtploopback
Required parameters:
必須パラメーター：
rate: RTP timestamp clock rate, which is equal to the sampling rate. This is specified by the loopback source and reflected by the mirror.
rate：RTPタイムスタンプクロックレート。サンプリングレートと同じです。これは、ループバックソースによって指定され、ミラーによって反映されます。
Optional parameters: N/A
オプションのパラメーター：N / A
Encoding considerations: This media type is framed.
エンコードに関する考慮事項：このメディアタイプはフレーム化されています。
Security considerations: See Section 12 of RFC 6849.
セキュリティに関する考慮事項：RFC 6849のセクション12をご覧ください。
Interoperability considerations: N/A
相互運用性に関する考慮事項：N / A
Published specification: RFC 6849.
公開された仕様：RFC 6849。
Applications that use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given real-time text service.
このメディアタイプを使用するアプリケーション：特定のリアルタイムテキストサービスのエッジへの転送品質を監視および保証する必要があるアプリケーション。
Additional information: N/A
追加情報：なし
Contact: the authors of RFC 6849.
連絡先：RFC 6849の作成者。
Intended usage: LIMITED USE
使用目的：限定使用
Restrictions on usage: This media type depends on RTP framing and hence is only defined for transfer via RTP. Transfer within other framing protocols is not defined at this time.
使用の制限：このメディアタイプはRTPフレーミングに依存するため、RTP経由の転送に対してのみ定義されます。現在、他のフレーミングプロトコル内での転送は定義されていません。
Author: Kaynam Hedayat.
著者：ケイナム・ヘダヤット。
Change controller: IETF PAYLOAD working group delegated from the IESG.
コントローラの変更：IESGから委任されたIETF PAYLOADワーキンググループ。
To: ietf-types@iana.org
と： いえｔｆーｔｙぺｓ＠いあな。おｒｇ
Subject: Registration of media type application/rtploopback
件名：メディアタイプapplication / rtploopbackの登録
Type name: application
タイプ名：アプリケーション
Subtype name: rtploopback
サブタイプ名：rtploopback
Required parameters:
必須パラメーター：
rate: RTP timestamp clock rate, which is equal to the sampling rate. This is specified by the loopback source and reflected by the mirror.
rate：RTPタイムスタンプクロックレート。サンプリングレートと同じです。これは、ループバックソースによって指定され、ミラーによって反映されます。
Optional parameters: N/A
オプションのパラメーター：N / A
Encoding considerations: This media type is framed.
エンコードに関する考慮事項：このメディアタイプはフレーム化されています。
Security considerations: See Section 12 of RFC 6849.
セキュリティに関する考慮事項：RFC 6849のセクション12をご覧ください。
Interoperability considerations: N/A
相互運用性に関する考慮事項：N / A
Published specification: RFC 6849.
公開された仕様：RFC 6849。
Applications that use this media type: Applications wishing to monitor and ensure the quality of transport to the edge of a given real-time application service.
このメディアタイプを使用するアプリケーション：特定のリアルタイムアプリケーションサービスのエッジへのトランスポートの品質を監視および保証する必要があるアプリケーション。
Additional information: N/A
追加情報：なし
Contact: the authors of RFC 6849.
連絡先：RFC 6849の作成者。
Intended usage: LIMITED USE
使用目的：限定使用
Restrictions on usage: This media type depends on RTP framing and hence is only defined for transfer via RTP. Transfer within other framing protocols is not defined at this time.
使用の制限：このメディアタイプはRTPフレーミングに依存するため、RTP経由の転送に対してのみ定義されます。現在、他のフレーミングプロトコル内での転送は定義されていません。
Author: Kaynam Hedayat.
著者：ケイナム・ヘダヤット。
Change controller: IETF PAYLOAD working group delegated from the IESG.
コントローラの変更：IESGから委任されたIETF PAYLOADワーキンググループ。
This document's editor would like to thank the original authors of the document: Kaynam Hedayat, Nagarjuna Venna, Paul E. Jones, Arjun Roychowdhury, Chelliah SivaChelvan, and Nathan Stratton. The editor has made fairly insignificant changes in the end. Also, we'd like to thank Magnus Westerlund, Miguel Garcia, Muthu Arul Mozhi Perumal, Jeff Bernstein, Paul Kyzivat, Dave Oran, Flemming Andreasen, Gunnar Hellstrom, Emil Ivov, and Dan Wing for their feedback, comments, and suggestions.
このドキュメントの編集者は、ドキュメントの元の作成者であるKaynam Hedayat、Nagarjuna Venna、Paul E. Jones、Arjun Roychowdhury、Chelliah SivaChelvan、Nathan Strattonに感謝します。編集者は結局かなり重要でない変更を行いました。また、フィードバック、コメント、提案をいただいたMagnus Westerlund、Miguel Garcia、Muthu Arul Mozhi Perumal、Jeff Bernstein、Paul Kyzivat、Dave Oran、Flemming Andreasen、Gunnar Hellstrom、Emil Ivov、Dan Wingにも感謝いたします。
[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月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「オファー/アンサーモデルとセッション記述プロトコル（SDP）」、RFC 3264、2002年6月。
[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：A Transport Protocol for Real-Time Applications」、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月。
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]フリードマン、T。、編、カセレス、R、編、およびA.クラーク、編、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、2003年11月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007.
[RFC4961]ウィング、D。、「対称RTP / RTP制御プロトコル（RTCP）」、BCP 131、RFC 4961、2007年7月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、2010年4月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「Session Traversal Utilities for NAT（STUN）」、RFC 5389、2008年10月。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766] Mahy、R.、Matthews、P.、J。Rosenberg、「NAT周辺のリレーを使用したトラバーサル（TURN）：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、RFC 5766、2010年4月。
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows", RFC 6263, June 2011.
[RFC6263] Marjou、X。およびA. Sollaud、「RTP / RTP制御プロトコル（RTCP）フローに関連するNATマッピングを維持するためのアプリケーションメカニズム」、RFC 6263、2011年6月。
Authors' Addresses
著者のアドレス
Hadriel Kaplan (editor) Acme Packet 100 Crosby Drive Bedford, MA 01730 US EMail: hkaplan@acmepacket.com URI: http://www.acmepacket.com
Hadriel Kaplan（editor）Acme Packet 100 Crosby Drive Bedford、MA 01730 US Eメール：hkaplan@acmepacket.com URI：http://www.acmepacket.com
Kaynam Hedayat EXFO 285 Mill Road Chelmsford, MA 01824 US EMail: kh274@cornell.edu URI: http://www.exfo.com/
Kaynam Hedayat EXFO 285 Mill Road Chelmsford、MA 01824 US Eメール：kh274@cornell.edu URI：http://www.exfo.com/
Nagarjuna Venna Saperix c/o DogPatch Labs One Cambridge Center, 6th Floor Cambridge, MA 02142 US EMail: vnagarjuna@saperix.com URI: http://www.saperix.com/
Nagarjuna Venna Saperix c / o DogPatch Labs One Cambridge Center、6th Floor Cambridge、MA 02142 US Eメール：vnagarjuna@saperix.com URI：http://www.saperix.com/
Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 US EMail: paulej@packetizer.com URI: http://www.cisco.com/
Paul E. Jones Cisco Systems、Inc. 7025 Kit Creek Rd。 Research Triangle Park、NC 27709 US EMail：paulej@packetizer.com URI：http://www.cisco.com/
Nathan Stratton BlinkMind, Inc. 2027 Briarchester Dr. Katy, TX 77450 US EMail: nathan@robotics.net URI: http://www.robotics.net/
Nathan Stratton BlinkMind、Inc. 2027 Briarchester Dr. Katy、TX 77450 US Eメール：nathan@robotics.net URI：http://www.robotics.net/