[要約] RFC 7667は、RTPトポロジーに関するガイドラインであり、RTPセッションのトポロジー設計に関する情報を提供します。このRFCの目的は、異なるネットワーク環境でのRTPセッションの効果的な設計と展開を支援することです。
Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 7667 Ericsson
Obsoletes: 5117 S. Wenger
Category: Informational Vidyo
ISSN: 2070-1721 November 2015
RTP Topologies
RTPトポロジ
Abstract
概要
This document discusses point-to-point and multi-endpoint topologies used in environments based on the Real-time Transport Protocol (RTP). In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology.
このドキュメントでは、Real-time Transport Protocol（RTP）に基づく環境で使用されるポイントツーポイントおよびマルチエンドポイントトポロジについて説明します。特に、ビデオ会議業界で一般的に採用されている集中型トポロジは、RTP用語にマッピングされています。
This document is updated with additional topologies and replaces RFC 5117.
このドキュメントは、追加のトポロジで更新され、RFC 5117に取って代わります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc7667.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7667で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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に記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Definitions Related to RTP Grouping Taxonomy . . . . . . 5
3. Topologies . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 6
3.2. Point to Point via Middlebox . . . . . . . . . . . . . . 7
3.2.1. Translators . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Back-to-Back RTP sessions . . . . . . . . . . . . . . 11
3.3. Point to Multipoint Using Multicast . . . . . . . . . . . 12
3.3.1. Any-Source Multicast (ASM) . . . . . . . . . . . . . 12
3.3.2. Source-Specific Multicast (SSM) . . . . . . . . . . . 14
3.3.3. SSM with Local Unicast Resources . . . . . . . . . . 15
3.4. Point to Multipoint Using Mesh . . . . . . . . . . . . . 17
3.5. Point to Multipoint Using the RFC 3550 Translator . . . . 20
3.5.1. Relay - Transport Translator . . . . . . . . . . . . 20
3.5.2. Media Translator . . . . . . . . . . . . . . . . . . 21
3.6. Point to Multipoint Using the RFC 3550 Mixer Model . . . 22
3.6.1. Media-Mixing Mixer . . . . . . . . . . . . . . . . . 24
3.6.2. Media-Switching Mixer . . . . . . . . . . . . . . . . 27
3.7. Selective Forwarding Middlebox . . . . . . . . . . . . . 29
3.8. Point to Multipoint Using Video-Switching MCUs . . . . . 33
3.9. Point to Multipoint Using RTCP-Terminating MCU . . . . . 34
3.10. Split Component Terminal . . . . . . . . . . . . . . . . 35
3.11. Non-symmetric Mixer/Translators . . . . . . . . . . . . . 38
3.12. Combining Topologies . . . . . . . . . . . . . . . . . . 38
4. Topology Properties . . . . . . . . . . . . . . . . . . . . . 39
4.1. All-to-All Media Transmission . . . . . . . . . . . . . . 39
4.2. Transport or Media Interoperability . . . . . . . . . . . 40
4.3. Per-Domain Bitrate Adaptation . . . . . . . . . . . . . . 40
4.4. Aggregation of Media . . . . . . . . . . . . . . . . . . 41
4.5. View of All Session Participants . . . . . . . . . . . . 41
4.6. Loop Detection . . . . . . . . . . . . . . . . . . . . . 42
4.7. Consistency between Header Extensions and RTCP . . . . . 42
5. Comparison of Topologies . . . . . . . . . . . . . . . . . . 42
6. Security Considerations . . . . . . . . . . . . . . . . . . . 43
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.1. Normative References . . . . . . . . . . . . . . . . . . 45
7.2. Informative References . . . . . . . . . . . . . . . . . 45
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
Real-time Transport Protocol (RTP) [RFC3550] topologies describe methods for interconnecting RTP entities and their processing behavior for RTP and the RTP Control Protocol (RTCP). This document tries to address past and existing confusion, especially with respect to terms not defined in RTP but in common use in the communication industry, such as the Multipoint Control Unit or MCU.
リアルタイム転送プロトコル（RTP）[RFC3550]トポロジでは、RTPエンティティを相互接続する方法と、RTPおよびRTP制御プロトコル（RTCP）の処理動作について説明します。このドキュメントでは、特にRTPで定義されていないが、マルチポイントコントロールユニットやMCUなどの通信業界で一般的に使用されている用語に関して、過去と現在の混乱に対処しようとしています。
When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was developed, the main emphasis lay in the efficient support of point-to-point and small multipoint scenarios without centralized multipoint control. In practice, however, most multipoint conferences operate utilizing centralized units referred to as MCUs. MCUs may implement mixer or translator functionality (in RTP [RFC3550] terminology) and signaling support. They may also contain additional application-layer functionality. This document focuses on the media transport aspects of the MCU that can be realized using RTP, as discussed below. Further considered are the properties of mixers and translators, and how some types of deployed MCUs deviate from these properties.
フィードバック付きの視聴覚プロファイル（AVPF）[RFC4585]が開発されたとき、集中型マルチポイント制御のないポイントツーポイントおよび小さなマルチポイントシナリオの効率的なサポートに重点が置かれました。ただし、実際には、ほとんどのマルチポイント会議は、MCUと呼ばれる集中型ユニットを使用して動作します。 MCUは、ミキサーまたはトランスレータ機能（RTP [RFC3550]用語で）およびシグナリングサポートを実装できます。また、追加のアプリケーション層機能が含まれている場合もあります。このドキュメントでは、以下で説明するように、RTPを使用して実現できるMCUのメディアトランスポートの側面に焦点を当てています。さらに検討されるのは、ミキサーとトランスレーターの特性、および配備された一部のタイプのMCUがこれらの特性からどのように逸脱するかです。
This document also codifies new multipoint architectures that have recently been introduced and that were not anticipated in RFC 5117; thus, this document replaces [RFC5117]. These architectures use scalable video coding and simulcasting, and their associated centralized units are referred to as Selective Forwarding Middleboxes (SFMs). This codification provides a common information basis for future discussion and specification work.
このドキュメントは、最近導入され、RFC 5117で予期されていなかった新しいマルチポイントアーキテクチャも体系化しています。したがって、この文書は[RFC5117]を置き換えます。これらのアーキテクチャは、スケーラブルなビデオコーディングと同時放送を使用し、関連する集中型ユニットは、選択的転送ミドルボックス（SFM）と呼ばれます。この体系化は、将来の議論と仕様作成作業のための共通の情報基盤を提供します。
The new topologies are Point to Point via Middlebox (Section 3.2), Source-Specific Multicast (Section 3.3.2), SSM with Local Unicast Resources (Section 3.3.3), Point to Multipoint Using Mesh (Section 3.4), Selective Forwarding Middlebox (Section 3.7), and Split Component Terminal (Section 3.10). The Point to Multipoint Using the RFC 3550 Mixer Model (Section 3.6) has been significantly expanded to cover two different versions, namely Media-Mixing Mixer (Section 3.6.1) and Media-Switching Mixer (Section 3.6.2).
新しいトポロジは、ミドルボックス経由のポイントツーポイント（セクション3.2）、ソース固有のマルチキャスト（セクション3.3.2）、ローカルユニキャストリソースを使用したSSM（セクション3.3.3）、メッシュを使用したポイントツーマルチポイント（セクション3.4）、選択的転送ミドルボックスです。 （セクション3.7）、および分割コンポーネントターミナル（セクション3.10）。 RFC 3550ミキサーモデル（セクション3.6）を使用したポイントツーマルチポイントは、メディア混合ミキサー（セクション3.6.1）とメディア切り替えミキサー（セクション3.6.2）の2つの異なるバージョンをカバーするように大幅に拡張されました。
The document's attempt to clarify and explain sections of the RTP spec [RFC3550] is informal. It is not intended to update or change what is normatively specified within RFC 3550.
RTP仕様[RFC3550]のセクションを明確にして説明する文書の試みは非公式です。 RFC 3550で規範的に指定されている内容を更新または変更することは意図されていません。
ASM: Any-Source Multicast
ASM：Any-Source Multicast
AVPF: The extended RTP profile for RTCP-based feedback
AVPF：RTCPベースのフィードバック用の拡張RTPプロファイル
CSRC: Contributing Source
CSRC：寄稿元
Link: The data transport to the next IP hop
リンク：次のIPホップへのデータ転送
Middlebox: A device that is on the Path that media travel between two endpoints
ミドルボックス：メディアが2つのエンドポイント間を移動するパス上にあるデバイス
MCU: Multipoint Control Unit
MCU：マルチポイントコントロールユニット
Path: The concatenation of multiple links, resulting in an end-to-end data transfer.
パス：複数のリンクを連結した結果、エンドツーエンドのデータ転送が行われます。
PtM: Point to Multipoint
PtM：ポイントツーマルチポイント
PtP: Point to Point
PtP：ポイントツーポイント
SFM: Selective Forwarding Middlebox
SFM：選択転送ミドルボックス
SSM: Source-Specific Multicast
SSM：ソース固有のマルチキャスト
SSRC: Synchronization Source
SSRC：同期ソース
The following definitions have been taken from [RFC7656].
以下の定義は[RFC7656]から取られました。
Communication Session: A Communication Session is an association among two or more Participants communicating with each other via one or more Multimedia Sessions.
通信セッション：通信セッションは、1つ以上のマルチメディアセッションを介して互いに通信する2人以上の参加者間の関連付けです。
Endpoint: A single addressable entity sending or receiving RTP packets. It may be decomposed into several functional blocks, but as long as it behaves as a single RTP stack mentity, it is classified as a single "endpoint".
エンドポイント：RTPパケットを送信または受信する単一のアドレス指定可能なエンティティ。いくつかの機能ブロックに分解される可能性がありますが、単一のRTPスタックメンタリティとして動作する限り、単一の「エンドポイント」として分類されます。
Media Source: A Media Source is the logical source of a time progressing digital media stream synchronized to a reference clock. This stream is called a Source Stream.
メディアソース：メディアソースは、基準クロックに同期した時間進行デジタルメディアストリームの論理ソースです。このストリームは、ソースストリームと呼ばれます。
Multimedia Session: A Multimedia Session is an association among a group of participants engaged in communication via one or more RTP sessions.
マルチメディアセッション：マルチメディアセッションは、1つ以上のRTPセッションを介して通信に参加している参加者のグループ間の関連付けです。
This subsection defines several topologies that are relevant for codec control but also RTP usage in other contexts. The section starts with point-to-point cases, with or without middleboxes. Then it follows a number of different methods for establishing point-to-multipoint communication. These are structured around the most fundamental enabler, i.e., multicast, a mesh of connections, translators, mixers, and finally MCUs and SFMs. The section ends by discussing decomposited terminals, asymmetric middlebox behaviors, and combining topologies.
このサブセクションでは、コーデック制御だけでなく、他のコンテキストでのRTPの使用に関連するいくつかのトポロジを定義します。セクションは、ミドルボックスの有無にかかわらず、ポイントツーポイントのケースから始まります。次に、ポイントツーマルチポイント通信を確立するためのいくつかの異なる方法に従います。これらは、最も基本的なイネーブラー、つまりマルチキャスト、接続のメッシュ、トランスレーター、ミキサー、そして最後にMCUとSFMを中心に構成されています。このセクションの最後は、分解された端末、非対称ミドルボックスの動作、トポロジの組み合わせについて説明します。
The topologies may be referenced in other documents by a shortcut name, indicated by the prefix "Topo-".
トポロジは、接頭辞「Topo-」で示されるショートカット名によって他のドキュメントで参照される場合があります。
For each of the RTP-defined topologies, we discuss how RTP, RTCP, and the carried media are handled. With respect to RTCP, we also discuss the handling of RTCP feedback messages as defined in [RFC4585] and [RFC5104].
RTPで定義されたトポロジごとに、RTP、RTCP、および伝送されるメディアの処理方法について説明します。 RTCPに関しては、[RFC4585]および[RFC5104]で定義されているRTCPフィードバックメッセージの処理についても説明します。
Shortcut name: Topo-Point-to-Point
ショートカット名：Topo-Point-to-Point
The Point-to-Point (PtP) topology (Figure 1) consists of two endpoints, communicating using unicast. Both RTP and RTCP traffic are conveyed endpoint to endpoint, using unicast traffic only (even if, in exotic cases, this unicast traffic happens to be conveyed over an IP multicast address).
ポイントツーポイント（PtP）トポロジ（図1）は、ユニキャストを使用して通信する2つのエンドポイントで構成されています。 RTPとRTCPの両方のトラフィックは、ユニキャストトラフィックのみを使用してエンドポイント間で伝達されます（エキゾチックなケースでは、このユニキャストトラフィックがたまたまIPマルチキャストアドレスで伝達される場合でも）。
+---+ +---+
| A |<------->| B |
+---+ +---+
Figure 1: Point to Point
図1：ポイントツーポイント
The main property of this topology is that A sends to B, and only B, while B sends to A, and only A. This avoids all complexities of handling multiple endpoints and combining the requirements stemming from them. Note that an endpoint can still use multiple RTP Synchronization Sources (SSRCs) in an RTP session. The number of RTP sessions in use between A and B can also be of any number, subject only to system-level limitations like the number range of ports.
このトポロジの主な特性は、AがBに送信し、Bのみを送信し、BはAに送信し、Aのみを送信することです。これにより、複数のエンドポイントを処理し、それらから生じる要件を組み合わせる複雑さがすべて回避されます。エンドポイントは、RTPセッションで複数のRTP同期ソース（SSRC）を引き続き使用できることに注意してください。 AとBの間で使用されているRTPセッションの数も任意の数にすることができ、ポートの数の範囲などのシステムレベルの制限のみに従います。
RTCP feedback messages for the indicated SSRCs are communicated directly between the endpoints. Therefore, this topology poses minimal (if any) issues for any feedback messages. For RTP sessions that use multiple SSRCs per endpoint, it can be relevant to implement support for cross-reporting suppression as defined in "Sending Multiple Media Streams in a Single RTP Session" [MULTI-STREAM-OPT].
示されたSSRCのRTCPフィードバックメッセージは、エンドポイント間で直接通信されます。したがって、このトポロジでは、フィードバックメッセージの問題が（あれば）最小限に抑えられます。エンドポイントごとに複数のSSRCを使用するRTPセッションの場合、「単一のRTPセッションでの複数のメディアストリームの送信」[MULTI-STREAM-OPT]で定義されているクロスレポート抑制のサポートを実装することが適切な場合があります。
This section discusses cases where two endpoints communicate but have one or more middleboxes involved in the RTP session.
このセクションでは、2つのエンドポイントが通信しているが、RTPセッションにミドルボックスが1つ以上含まれている場合について説明します。
Shortcut name: Topo-PtP-Translator
ショートカット名：Topo-PtP-Translator
Two main categories of translators can be distinguished: Transport Translators and Media Translators. Both translator types share common attributes that separate them from mixers. For each RTP stream that the translator receives, it generates an individual RTP stream in the other domain. A translator keeps the SSRC for an RTP stream across the translation, whereas a mixer can select a single RTP stream from multiple received RTP streams (in cases like audio/ video switching) or send out an RTP stream composed of multiple mixed media received in multiple RTP streams (in cases like audio mixing or video tiling), but always under its own SSRC, possibly using the CSRC field to indicate the source(s) of the content. Mixers are more common in point-to-multipoint cases than in PtP. The reason is that in PtP use cases, the primary focus of a middlebox is enabling interoperability, between otherwise non-interoperable endpoints, such as transcoding to a codec the receiver supports, which can be done by a Media Translator.
トランスレーターの2つの主要なカテゴリー、トランスポートトランスレーターとメディアトランスレーターを区別できます。どちらのトランスレータタイプも、それらをミキサーから分離する共通の属性を共有します。トランスレータが受信するRTPストリームごとに、他のドメインで個別のRTPストリームを生成します。トランスレータは、RTPストリームのSSRCを変換全体で維持しますが、ミキサーは、受信した複数のRTPストリームから単一のRTPストリームを選択し（オーディオ/ビデオスイッチングなどの場合）、複数で受信した複数の混合メディアで構成されるRTPストリームを送信できます。 RTPストリーム（オーディオミキシングやビデオタイリングなどの場合）ですが、常に独自のSSRCの下にあり、CSRCフィールドを使用してコンテンツのソースを示している可能性があります。ミキサーは、ポイントツーマルチポイントの場合にPtPよりも一般的です。その理由は、PtPユースケースでは、ミドルボックスの主な焦点は、レシーバーがサポートするコーデックへのトランスコーディングなど、他の相互運用できないエンドポイント間の相互運用性を有効にすることです。これは、メディアトランスレーターで実行できます。
As specified in Section 7.1 of [RFC3550], the SSRC space is common for all participants in the RTP session, independent of on which side of the translator the session resides. Therefore, it is the responsibility of the endpoints (as the RTP session participants) to run SSRC collision detection, and the SSRC is thus a field the translator cannot change. Any Source Description (SDES) information associated with an SSRC or CSRC also needs to be forwarded between the domains for any SSRC/CSRC used in the different domains.
[RFC3550]のセクション7.1で指定されているように、SSRCスペースは、RTPセッションのすべての参加者に共通であり、トランスレータのどちら側にセッションが存在するかには関係ありません。したがって、SSRC衝突検出を実行するのは（RTPセッション参加者としての）エンドポイントの責任であり、SSRCはトランスレーターが変更できないフィールドです。 SSRCまたはCSRCに関連付けられているソース記述（SDES）情報も、異なるドメインで使用されるSSRC / CSRCのドメイン間で転送する必要があります。
A translator commonly does not use an SSRC of its own and is not visible as an active participant in the RTP session. One reason to have its own SSRC is when a translator acts as a quality monitor that sends RTCP reports and therefore is required to have an SSRC. Another example is the case when a translator is prepared to use RTCP feedback messages. This may, for example, occur in a translator configured to detect packet loss of important video packets, and it wants to trigger repair by the media sending endpoint, by sending feedback messages. While such feedback could use the SSRC of the target for the translator (the receiving endpoint), this in turn would require translation of the target RTCP reports to make them consistent. It may be simpler to expose an additional SSRC in the session. The only concern is that endpoints failing to support the full RTP specification may have issues with multiple SSRCs reporting on the RTP streams sent by that endpoint, as this use case may be viewed as exotic by implementers.
通常、トランスレーターは独自のSSRCを使用せず、RTPセッションのアクティブな参加者としては表示されません。独自のSSRCを使用する1つの理由は、トランスレーターがRTCPレポートを送信する品質モニターとして機能するため、SSRCが必要になる場合です。別の例は、トランスレータがRTCPフィードバックメッセージを使用する準備ができている場合です。これは、たとえば、重要なビデオパケットのパケット損失を検出するように構成されたトランスレータで発生する可能性があり、フィードバックメッセージを送信することにより、メディア送信エンドポイントによる修復をトリガーしたい場合があります。そのようなフィードバックは、トランスレーター（受信エンドポイント）のターゲットのSSRCを使用できますが、ターゲットRTCPレポートを変換して整合させる必要があります。セッションで追加のSSRCを公開する方が簡単な場合があります。唯一の懸念は、エンドポイントが完全なRTP仕様をサポートしていない場合、そのエンドポイントから送信されたRTPストリームに関する複数のSSRCのレポートで問題が発生する可能性があることです。
In general, a translator implementation should consider which RTCP feedback messages or codec-control messages it needs to understand in relation to the functionality of the translator itself. This is completely in line with the requirement to also translate RTCP messages between the domains.
一般に、トランスレータの実装では、トランスレータ自体の機能に関連して理解する必要があるRTCPフィードバックメッセージまたはコーデック制御メッセージを検討する必要があります。これは、ドメイン間でRTCPメッセージも変換するという要件と完全に一致しています。
Shortcut name: Topo-PtP-Relay
ショートカット名：Topo-PtP-Relay
There exist a number of different types of middleboxes that might be inserted between two endpoints on the transport level, e.g., to perform changes on the IP/UDP headers, and are, therefore, basic Transport Translators. These middleboxes come in many variations including NAT [RFC3022] traversal by pinning the media path to a public address domain relay and network topologies where the RTP stream is required to pass a particular point for audit by employing relaying, or preserving privacy by hiding each peer's transport addresses to the other party. Other protocols or functionalities that provide this behavior are Traversal Using Relays around NAT (TURN) [RFC5766] servers, Session Border Gateways, and Media Processing Nodes with media anchoring functionalities.
たとえば、IP / UDPヘッダーの変更を実行するために、トランスポートレベルの2つのエンドポイントの間に挿入される可能性のあるさまざまなタイプのミドルボックスがいくつか存在するため、基本的なトランスポートトランスレーターです。これらのミドルボックスには、NAT [RFC3022]トラバーサルなどの多くのバリエーションがあり、メディアパスをパブリックアドレスドメインリレーに固定することや、RTPストリームがリレーを使用して監査のために特定のポイントを通過する必要がある場合や、各ピアを非表示にしてプライバシーを保護する必要がある相手にアドレスを転送します。この動作を提供する他のプロトコルまたは機能は、NAT（TURN）[RFC5766]サーバー、セッションボーダーゲートウェイ、およびメディアアンカー機能を備えたメディア処理ノードの周りのリレーを使用したトラバーサルです。
+---+ +---+ +---+
| A |<------>| T |<------->| B |
+---+ +---+ +---+
Figure 2: Point to Point with Translator
図2：トランスレーターを使用したポイントツーポイント
A common element in these functions is that they are normally transparent at the RTP level, i.e., they perform no changes on any RTP or RTCP packet fields and only affect the lower layers. They may affect, however, the path since the RTP and RTCP packets are routed between the endpoints in the RTP session, and thereby they indirectly affect the RTP session. For this reason, one could believe that Transport Translator-type middleboxes do not need to be included in this document. This topology, however, can raise additional requirements in the RTP implementation and its interactions with the signaling solution. Both in signaling and in certain RTCP fields, network addresses other than those of the relay can occur since B has a different network address than the relay (T). Implementations that cannot support this will also not work correctly when endpoints are subject to NAT.
これらの関数の共通要素は、RTPレベルでは通常透過的であることです。つまり、RTPまたはRTCPパケットフィールドに対して変更を行わず、下位層にのみ影響します。ただし、RTPおよびRTCPパケットはRTPセッションのエンドポイント間でルーティングされるため、パスに影響を与える可能性があり、RTPセッションに間接的に影響します。このため、トランスポートトランスレータータイプのミドルボックスをこのドキュメントに含める必要はないと考えられます。ただし、このトポロジでは、RTP実装およびシグナリングソリューションとの相互作用における追加要件が発生する可能性があります。シグナリングと特定のRTCPフィールドの両方で、Bはリレー（T）とは異なるネットワークアドレスを持っているため、リレー以外のネットワークアドレスが発生する可能性があります。これをサポートできない実装も、エンドポイントがNATの対象である場合は正しく機能しません。
The Transport Relay implementations also have to take into account security considerations. In particular, source address filtering of incoming packets is usually important in relays, to prevent attackers from injecting traffic into a session, which one peer may, in the absence of adequate security in the relay, think it comes from the other peer.
トランスポートリレーの実装では、セキュリティに関する考慮事項も考慮する必要があります。特に、着信パケットの送信元アドレスフィルタリングは通常、リレーで重要です。これは、攻撃者がセッションにトラフィックを注入するのを防ぐためです。一方のピアは、リレーに十分なセキュリティがない場合、もう一方のピアからのものであると考えます。
Shortcut name: Topo-Trn-Translator
ショートカット名：Topo-Trn-Translator
Transport Translators (Topo-Trn-Translator) do not modify the RTP stream itself but are concerned with transport parameters. Transport parameters, in the sense of this section, comprise the transport addresses (to bridge different domains such as unicast to multicast) and the media packetization to allow other transport protocols to be interconnected to a session (in gateways).
トランスポートトランスレーター（Topo-Trn-Translator）はRTPストリーム自体を変更しませんが、トランスポートパラメーターに関係します。このセクションの意味でのトランスポートパラメータは、トランスポートアドレス（ユニキャストからマルチキャストへの異なるドメインをブリッジするため）とメディアパケット化で構成され、他のトランスポートプロトコルをセッションに相互接続できるようにします（ゲートウェイ内）。
Translators that bridge between different protocol worlds need to be concerned about the mapping of the SSRC/CSRC (Contributing Source) concept to the non-RTP protocol. When designing a translator to a non-RTP-based media transport, an important consideration is how to handle different sources and their identities. This problem space is not discussed henceforth.
異なるプロトコルの世界を橋渡しするトランスレーターは、SSRC / CSRC（Contributing Source）の概念の非RTPプロトコルへのマッピングを考慮する必要があります。非RTPベースのメディアトランスポートへのトランスレータを設計する場合、重要な考慮事項は、さまざまなソースとそのIDを処理する方法です。この問題空間については、今後は説明しません。
Of the Transport Translators, this memo is primarily interested in those that use RTP on both sides, and this is assumed henceforth.
トランスポートトランスレータのうち、このメモは主に両側でRTPを使用するものに関心があり、これは今後想定されます。
The most basic Transport Translators that operate below the RTP level were already discussed in Section 3.2.1.1.
RTPレベル未満で動作する最も基本的なトランスポートトランスレータは、セクション3.2.1.1で既に説明されています。
Shortcut name: Topo-Media-Translator
ショートカット名：Topo-Media-Translator
Media Translators (Topo-Media-Translator) modify the media inside the RTP stream. This process is commonly known as transcoding. The modification of the media can be as small as removing parts of the stream, and it can go all the way to a full decoding and re-encoding (down to the sample level or equivalent) utilizing a different media codec. Media Translators are commonly used to connect endpoints without a common interoperability point in the media encoding.
メディアトランスレータ（Topo-Media-Translator）は、RTPストリーム内のメディアを変更します。このプロセスは一般にトランスコーディングと呼ばれます。メディアの変更は、ストリームの一部を削除する程度の小さなものにすることができ、さまざまなメディアコーデックを使用して、完全なデコードと再エンコード（サンプルレベルまたは同等のものまで）に至ることができます。メディアトランスレータは、メディアエンコーディングに共通の相互運用ポイントがないエンドポイントを接続するために一般的に使用されます。
Stand-alone Media Translators are rare. Most commonly, a combination of Transport and Media Translator is used to translate both the media and the transport aspects of the RTP stream carrying the media between two transport domains.
スタンドアロンのメディアトランスレーターはまれです。最も一般的には、トランスポートとメディアトランスレータの組み合わせを使用して、2つのトランスポートドメイン間でメディアを運ぶRTPストリームのメディアとトランスポートの側面の両方を変換します。
When media translation occurs, the translator's task regarding handling of RTCP traffic becomes substantially more complex. In this case, the translator needs to rewrite endpoint B's RTCP receiver report before forwarding them to endpoint A. The rewriting is needed as the RTP stream received by B is not the same RTP stream as the other participants receive. For example, the number of packets transmitted to B may be lower than what A sends, due to the different media format and data rate. Therefore, if the receiver reports were forwarded without changes, the extended highest sequence number would indicate that B was substantially behind in reception, while it most likely would not be. Therefore, the translator must translate that number to a corresponding sequence number for the stream the translator received. Similar requirements exist for most other fields in the RTCP receiver reports.
メディア変換が発生すると、RTCPトラフィックの処理に関するトランスレータのタスクが大幅に複雑になります。この場合、トランスレータはエンドポイントAに転送する前にエンドポイントBのRTCP受信者レポートを書き換える必要があります。Bが受信したRTPストリームは他の参加者が受け取るRTPストリームと同じではないため、書き換えが必要です。たとえば、メディアフォーマットとデータレートが異なるため、Bに送信されるパケット数は、Aが送信するパケット数よりも少ない場合があります。したがって、受信者レポートが変更なしで転送された場合、拡張された最大シーケンス番号は、Bが実質的に遅れていることを示しますが、そうではない可能性が高いです。したがって、トランスレータはその番号を、トランスレータが受信したストリームの対応するシーケンス番号に変換する必要があります。 RTCP受信者レポートの他のほとんどのフィールドにも同様の要件があります。
A Media Translator may in some cases act on behalf of the "real" source (the endpoint originally sending the media to the translator) and respond to RTCP feedback messages. This may occur, for example, when a receiving endpoint requests a bandwidth reduction, and the Media Translator has not detected any congestion or other reasons for bandwidth reduction between the sending endpoint and itself. In that case, it is sensible that the Media Translator reacts to codec control messages itself, for example, by transcoding to a lower media rate.
メディアトランスレータは、「実際の」ソース（元々はメディアをトランスレータに送信するエンドポイント）に代わって動作し、RTCPフィードバックメッセージに応答する場合があります。これは、たとえば、受信エンドポイントが帯域幅の削減を要求し、Media Translatorが送信エンドポイントとそれ自体の間の帯域幅削減の輻輳やその他の理由を検出していない場合に発生する可能性があります。その場合、Media Translatorがコーデック制御メッセージ自体に、たとえばより低いメディアレートにトランスコーディングすることによって反応することは賢明です。
A variant of translator behavior worth pointing out is the one depicted in Figure 3 of an endpoint A sending an RTP stream containing media (only) to B. On the path, there is a device T that manipulates the RTP streams on A's behalf. One common example is that T adds a second RTP stream containing Forward Error Correction (FEC) information in order to protect A's (non FEC-protected) RTP stream. In this case, T needs to semantically bind the new FEC RTP stream to A's media-carrying RTP stream, for example, by using the same CNAME as A.
トランスレータの動作のバリエーションの1つは、メディアを含む（のみ）RTPストリームをBに送信するエンドポイントAの図3に示すものです。パス上に、Aの代わりにRTPストリームを操作するデバイスTがあります。 1つの一般的な例は、Aの（FECで保護されていない）RTPストリームを保護するために、Tが前方誤り訂正（FEC）情報を含む2番目のRTPストリームを追加することです。この場合、Tは、たとえば、Aと同じCNAMEを使用して、新しいFEC RTPストリームをAのメディアを運ぶRTPストリームに意味的にバインドする必要があります。
+------+ +------+ +------+
| | | | | |
| A |------->| T |-------->| B |
| | | |---FEC-->| |
+------+ +------+ +------+
Figure 3: Media Translator Adding FEC
図3：FECを追加するメディアトランスレーター
There may also be cases where information is added into the original RTP stream, while leaving most or all of the original RTP packets intact (with the exception of certain RTP header fields, such as the sequence number). One example is the injection of metadata into the RTP stream, carried in their own RTP packets.
シーケンス番号などの特定のRTPヘッダーフィールドを除いて、元のRTPパケットのほとんどまたはすべてをそのままにして、元のRTPストリームに情報が追加される場合もあります。 1つの例は、RTPストリームへのメタデータの注入であり、独自のRTPパケットで伝送されます。
Similarly, a Media Translator can sometimes remove information from the RTP stream, while otherwise leaving the remaining RTP packets unchanged (again with the exception of certain RTP header fields).
同様に、Media Translatorは、RTPストリームから情報を削除することもできますが、それ以外の場合は、残りのRTPパケットを変更しません（これも、特定のRTPヘッダーフィールドを除く）。
Either type of functionality where T manipulates the RTP stream, or adds an accompanying RTP stream, on behalf of A is also covered under the Media Translator definition.
Aに代わってTがRTPストリームを操作するか、付随するRTPストリームを追加する機能のどちらのタイプも、Media Translator定義でカバーされます。
Shortcut name: Topo-Back-To-Back
ショートカット名：Topo-Back-To-Back
There exist middleboxes that interconnect two endpoints (A and B) through themselves (MB), but not by being part of a common RTP session. Instead, they establish two different RTP sessions: one between A and the middlebox and another between the middlebox and B. This topology is called Topo-Back-To-Back.
2つのエンドポイント（AとB）を相互に接続するミドルボックス（MB）が存在しますが、共通のRTPセッションの一部ではありません。代わりに、2つの異なるRTPセッションを確立します。1つはAとMiddleboxの間、もう1つはMiddleboxとBの間です。このトポロジは、Topo-Back-To-Backと呼ばれます。
|<--Session A-->| |<--Session B-->|
+------+ +------+ +------+
| A |------->| MB |-------->| B |
+------+ +------+ +------+
Figure 4: Back-to-Back RTP Sessions through Middlebox
図4：Middleboxを介した連続したRTPセッション
The middlebox acts as an application-level gateway and bridges the two RTP sessions. This bridging can be as basic as forwarding the RTP payloads between the sessions or more complex including media transcoding. The difference of this topology relative to the single RTP session context is the handling of the SSRCs and the other session-related identifiers, such as CNAMEs. With two different RTP sessions, these can be freely changed and it becomes the middlebox's responsibility to maintain the correct relations.
ミドルボックスは、アプリケーションレベルのゲートウェイとして機能し、2つのRTPセッションをブリッジします。このブリッジングは、セッション間でRTPペイロードを転送するのと同じくらい基本的なものか、メディアトランスコーディングを含むより複雑なものになります。単一のRTPセッションコンテキストに対するこのトポロジの違いは、SSRCとCNAMEなどの他のセッション関連の識別子の処理です。 2つの異なるRTPセッションを使用すると、これらを自由に変更でき、正しい関係を維持することがミドルボックスの責任になります。
The signaling or other above RTP-level functionalities referencing RTP streams may be what is most impacted by using two RTP sessions and changing identifiers. The structure with two RTP sessions also puts a congestion control requirement on the middlebox, because it becomes fully responsible for the media stream it sources into each of the sessions.
RTPストリームを参照するシグナリングまたはその他の上記のRTPレベルの機能は、2つのRTPセッションを使用して識別子を変更することによって最も影響を受ける可能性があります。 2つのRTPセッションを持つ構造は、ミドルボックスにも輻輳制御要件を課します。これは、それが各セッションに送信するメディアストリームを完全に担当するためです。
Adherence to congestion control can be solved locally on each of the two segments or by bridging statistics from the receiving endpoint through the middlebox to the sending endpoint. From an implementation point, however, the latter requires dealing with a number of inconsistencies. First, packet loss must be detected for an RTP stream sent from A to the middlebox, and that loss must be reported through a skipped sequence number in the RTP stream from the middlebox to B. This coupling and the resulting inconsistencies are conceptually easier to handle when considering the two RTP streams as belonging to a single RTP session.
輻輳制御の順守は、2つのセグメントのそれぞれでローカルに解決するか、受信エンドポイントからミドルボックスを介して送信エンドポイントに統計をブリッジすることで解決できます。ただし、実装の点から見ると、後者は多くの不整合に対処する必要があります。まず、Aからミドルボックスに送信されたRTPストリームのパケット損失を検出する必要があり、その損失はミドルボックスからBへのRTPストリームのスキップされたシーケンス番号を通じて報告する必要があります。この結合と結果として生じる不整合は、概念的には処理が簡単です2つのRTPストリームを1つのRTPセッションに属していると見なす場合。
Multicast is an IP-layer functionality that is available in some networks. Two main flavors can be distinguished: Any-Source Multicast (ASM) [RFC1112] where any multicast group participant can send to the group address and expect the packet to reach all group participants and Source-Specific Multicast (SSM) [RFC3569], where only a particular IP host sends to the multicast group. Each of these models are discussed below in their respective sections.
マルチキャストは、一部のネットワークで使用可能なIP層機能です。次の2つの主要なフレーバーを区別できます。Any-SourceMulticast（ASM）[RFC1112]マルチキャストグループ参加者はグループアドレスに送信でき、パケットがすべてのグループ参加者に到達することを期待できます。Source-SpecificMulticast（SSM）[RFC3569]特定のIPホストのみがマルチキャストグループに送信します。これらの各モデルについては、以下のそれぞれのセクションで説明します。
Shortcut name: Topo-ASM (was Topo-Multicast)
ショートカット名：Topo-ASM（以前はTopo-Multicast）
+-----+
+---+ / \ +---+
| A |----/ \---| B |
+---+ / Multi- \ +---+
+ cast +
+---+ \ Network / +---+
| C |----\ /---| D |
+---+ \ / +---+
+-----+
Figure 5: Point to Multipoint Using Multicast
図5：マルチキャストを使用したポイントツーマルチポイント
Point to Multipoint (PtM) is defined here as using a multicast topology as a transmission model, in which traffic from any multicast group participant reaches all the other multicast group participants, except for cases such as:
ポイントツーマルチポイント（PtM）は、ここでは、マルチキャストトポロジを伝送モデルとして使用するものとして定義されています。この場合、マルチキャストグループの参加者からのトラフィックは、次のような場合を除き、他のすべてのマルチキャストグループの参加者に到達します。
o packet loss, or
o パケット損失、または
o when a multicast group participant does not wish to receive the traffic for a specific multicast group and, therefore, has not subscribed to the IP multicast group in question. This scenario can occur, for example, where a Multimedia Session is distributed using two or more multicast groups, and a multicast group participant is subscribed only to a subset of these sessions.
o マルチキャストグループの参加者が特定のマルチキャストグループのトラフィックを受信したくないため、問題のIPマルチキャストグループにサブスクライブしていない場合。このシナリオは、たとえば、マルチメディアセッションが2つ以上のマルチキャストグループを使用して配信され、マルチキャストグループの参加者がこれらのセッションのサブセットにのみサブスクライブされる場合に発生する可能性があります。
In the above context, "traffic" encompasses both RTP and RTCP traffic. The number of multicast group participants can vary between one and many, as RTP and RTCP scale to very large multicast groups (the theoretical limit of the number of participants in a single RTP session is in the range of billions). The above can be realized using ASM.
上記のコンテキストでは、「トラフィック」にはRTPトラフィックとRTCPトラフィックの両方が含まれます。 RTPとRTCPが非常に大規模なマルチキャストグループに対応するため、マルチキャストグループの参加者の数は1人から多数の間で変動する可能性があります（単一のRTPセッションの参加者数の理論上の制限は数十億の範囲です）。上記はASMを使用して実現できます。
For feedback usage, it is useful to define a "small multicast group" as a group where the number of multicast group participants is so low (and other factors such as the connectivity is so good) that it allows the participants to use early or immediate feedback, as defined in AVPF [RFC4585]. Even when the environment would allow for the use of a small multicast group, some applications may still want to use the more limited options for RTCP feedback available to large multicast groups, for example, when there is a likelihood that the threshold of the small multicast group (in terms of multicast group participants) may be exceeded during the lifetime of a session.
フィードバックの使用については、「小さなマルチキャストグループ」を、マルチキャストグループ参加者の数が非常に少ない（および接続性などの他の要因が非常に高い）ため、参加者が早期または即時に使用できるグループとして定義すると便利ですAVPF [RFC4585]で定義されているフィードバック。環境が小さなマルチキャストグループの使用を許可する場合でも、一部のアプリケーションは、たとえば、小さなマルチキャストのしきい値の可能性がある場合に、大きなマルチキャストグループが利用できるRTCPフィードバックのより制限されたオプションを使用したい場合があります。グループ（マルチキャストグループ参加者に関して）は、セッションの存続期間中に超過する可能性があります。
RTCP feedback messages in multicast reach, like media data, every subscriber (subject to packet losses and multicast group subscription). Therefore, the feedback suppression mechanism discussed in [RFC4585] is typically required. Each individual endpoint that is a multicast group participant needs to process every feedback message it receives, not only to determine if it is affected or if the feedback message applies only to some other endpoint but also to derive timing restrictions for the sending of its own feedback messages, if any.
マルチキャストのRTCPフィードバックメッセージは、メディアデータのように、すべてのサブスクライバーに到達します（パケット損失とマルチキャストグループのサブスクリプションの対象）。したがって、[RFC4585]で説明されているフィードバック抑制メカニズムが通常必要です。マルチキャストグループの参加者である個々のエンドポイントは、受信したすべてのフィードバックメッセージを処理する必要があります。フィードバックメッセージが影響を受けるかどうか、またはフィードバックメッセージが他のエンドポイントにのみ適用されるかどうかを判断するだけでなく、独自のフィードバックを送信するためのタイミング制限を導出するメッセージ（存在する場合）。
Shortcut name: Topo-SSM
ショートカット名：Topo-SSM
In Any-Source Multicast, any of the multicast group participants can send to all the other multicast group participants, by sending a packet to the multicast group. In contrast, Source-Specific Multicast [RFC3569][RFC4607] refers to scenarios where only a single source (Distribution Source) can send to the multicast group, creating a topology that looks like the one below:
Any-Source Multicastでは、マルチキャストグループにパケットを送信することにより、任意のマルチキャストグループ参加者が他のすべてのマルチキャストグループ参加者に送信できます。対照的に、送信元固有のマルチキャスト[RFC3569] [RFC4607]は、単一の送信元（配布元）のみがマルチキャストグループに送信できるシナリオを指し、以下のようなトポロジを作成します。
+--------+ +-----+
|Media | | | Source-Specific
|Sender 1|<----->| D S | Multicast
+--------+ | I O | +--+----------------> R(1)
| S U | | | |
+--------+ | T R | | +-----------> R(2) |
|Media |<----->| R C |->+ | : | |
|Sender 2| | I E | | +------> R(n-1) | |
+--------+ | B | | | | | |
: | U | +--+--> R(n) | | |
: | T +-| | | | |
: | I | |<---------+ | | |
+--------+ | O |F|<---------------+ | |
|Media | | N |T|<--------------------+ |
|Sender M|<----->| | |<-------------------------+
+--------+ +-----+ RTCP Unicast
FT = Feedback Target Transport from the Feedback Target to the Distribution Source is via unicast or multicast RTCP if they are not co-located.
FT =フィードバックターゲットから配布ソースへのフィードバックターゲットトランスポートは、同じ場所に配置されていない場合、ユニキャストまたはマルチキャストRTCPを経由します。
Figure 6: Point to Multipoint Using Source-Specific Multicast
図6：ソース固有のマルチキャストを使用したポイントツーマルチポイント
In the SSM topology (Figure 6), a number of RTP sending endpoints (RTP sources henceforth) (1 to M) are allowed to send media to the SSM group. These sources send media to a dedicated Distribution Source, which forwards the RTP streams to the multicast group on behalf of the original RTP sources. The RTP streams reach the receiving endpoints (receivers henceforth) (R(1) to R(n)). The receivers' RTCP messages cannot be sent to the multicast group, as the SSM multicast group by definition has only a single IP sender. To support RTCP, an RTP extension for SSM [RFC5760] was defined. It uses unicast transmission to send RTCP from each of the receivers to one or more Feedback Targets (FT). The Feedback Targets relay the RTCP unmodified, or provide a summary of the participants' RTCP reports towards the whole group by forwarding the RTCP traffic to the Distribution Source. Figure 6 only shows a single Feedback Target integrated in the Distribution Source, but for scalability the FT can be distributed and each instance can have responsibility for subgroups of the receivers. For summary reports, however, there typically must be a single Feedback Target aggregating all the summaries to a common message to the whole receiver group.
SSMトポロジ（図6）では、多数のRTP送信エンドポイント（以降、RTPソース）（1〜M）がSSMグループにメディアを送信できます。これらのソースは、元のRTPソースに代わってRTPストリームをマルチキャストグループに転送する専用の配布ソースにメディアを送信します。 RTPストリームは受信側エンドポイント（以降、受信側）に到達します（R（1）〜R（n））。定義上、SSMマルチキャストグループには単一のIP送信者しかないため、受信者のRTCPメッセージはマルチキャストグループに送信できません。 RTCPをサポートするために、SSM [RFC5760]のRTP拡張が定義されました。ユニキャスト送信を使用して、RTCPを各レシーバーから1つ以上のフィードバックターゲット（FT）に送信します。フィードバックターゲットは、RTCPを変更せずにリレーするか、RTCPトラフィックを配布元に転送することにより、グループ全体に向けて参加者のRTCPレポートの概要を提供します。図6は、配布ソースに統合された単一のフィードバックターゲットのみを示していますが、スケーラビリティのためにFTを配布でき、各インスタンスが受信機のサブグループに責任を持つことができます。ただし、要約レポートの場合、通常は、すべての要約を受信者グループ全体への共通メッセージに集約する単一のフィードバックターゲットが必要です。
The RTP extension for SSM specifies how feedback (both reception information and specific feedback events) are handled. The more general problems associated with the use of multicast, where everyone receives what the Distribution Source sends, need to be accounted for.
SSMのRTP拡張は、フィードバック（受信情報と特定のフィードバックイベントの両方）の処理方法を指定します。配布ソースが送信するものを誰もが受け取るマルチキャストの使用に関連する、より一般的な問題を説明する必要があります。
The aforementioned situation results in common behavior for RTP multicast:
前述の状況では、RTPマルチキャストの一般的な動作が発生します。
1. Multicast applications often use a group of RTP sessions, not one. Each endpoint needs to be a member of most or all of these RTP sessions in order to perform well.
1. 多くの場合、マルチキャストアプリケーションは、1つではなくRTPセッションのグループを使用します。各エンドポイントは、適切に実行するために、これらのRTPセッションのほとんどまたはすべてのメンバーである必要があります。
2. Within each RTP session, the number of media sinks is likely to be much larger than the number of RTP sources.
2. 各RTPセッション内で、メディアシンクの数はRTPソースの数よりもはるかに多くなる可能性があります。
3. Multicast applications need signaling functions to identify the relationships between RTP sessions.
3. マルチキャストアプリケーションには、RTPセッション間の関係を識別するためのシグナリング機能が必要です。
4. Multicast applications need signaling functions to identify the relationships between SSRCs in different RTP sessions.
4. マルチキャストアプリケーションには、さまざまなRTPセッションのSSRC間の関係を識別するためのシグナリング機能が必要です。
All multicast configurations share a signaling requirement: all of the endpoints need to have the same RTP and payload type configuration. Otherwise, endpoint A could, for example, be using payload type 97 to identify the video codec H.264, while endpoint B would identify it as MPEG-2, with unpredictable but almost certainly not visually pleasing results.
すべてのマルチキャスト設定はシグナリング要件を共有します。すべてのエンドポイントは同じRTPおよびペイロードタイプ設定を持っている必要があります。それ以外の場合、たとえば、エンドポイントAはペイロードタイプ97を使用してビデオコーデックH.264を識別し、エンドポイントBはそれをMPEG-2として識別します。
Security solutions for this type of group communication are also challenging. First, the key management and the security protocol must support group communication. Source authentication becomes more difficult and requires specialized solutions. For more discussion on this, please review "Options for Securing RTP Sessions" [RFC7201].
この種のグループコミュニケーションのためのセキュリティソリューションも課題です。まず、キー管理とセキュリティプロトコルがグループ通信をサポートする必要があります。ソース認証はより困難になり、特殊なソリューションが必要になります。この詳細については、「RTPセッションを保護するためのオプション」[RFC7201]を確認してください。
Shortcut name: Topo-SSM-RAMS
ショートカット名：Topo-SSM-RAMS
"Unicast-Based Rapid Acquisition of Multicast RTP Sessions" [RFC6285] results in additional extensions to SSM topology.
「マルチキャストRTPセッションのユニキャストベースの高速取得」[RFC6285]により、SSMトポロジがさらに拡張されます。
----------- --------------
| |------------------------------------>| |
| |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| |
| | | |
| Multicast | ---------------- | |
| Source | | Retransmission | | |
| |-------->| Server (RS) | | |
| |.-.-.-.->| | | |
| | | ------------ | | |
----------- | | Feedback | |<.=.=.=.=.| |
| | Target (FT)| |<~~~~~~~~~| RTP Receiver |
PRIMARY MULTICAST | ------------ | | (RTP_Rx) |
RTP SESSION with | | | |
UNICAST FEEDBACK | | | |
| | | |
- - - - - - - - - - - |- - - - - - - - |- - - - - |- - - - - - - |- -
| | | |
UNICAST BURST | ------------ | | |
(or RETRANSMISSION) | | Burst/ | |<~~~~~~~~>| |
RTP SESSION | | Retrans. | |.........>| |
| |Source (BRS)| |<.=.=.=.=>| |
| ------------ | | |
| | | |
---------------- --------------
-------> Multicast RTP Stream
.-.-.-.> Multicast RTCP Stream
.=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages
.......> Unicast RTP Stream
Figure 7: SSM with Local Unicast Resources (RAMS)
図7：ローカルユニキャストリソース（RAMS）を使用したSSM
The rapid acquisition extension allows an endpoint joining an SSM multicast session to request media starting with the last sync point (from where media can be decoded without requiring context established by the decoding of prior packets) to be sent at high speed until such time where, after the decoding of these burst-delivered media packets, the correct media timing is established, i.e., media packets are received within adequate buffer intervals for this application. This is accomplished by first establishing a unicast PtP RTP session between the Burst/Retransmission Source (BRS) (Figure 7) and the RTP Receiver. The unicast session is used to transmit cached packets from the multicast group at higher then normal speed in order to synchronize the receiver to the ongoing multicast RTP stream. Once the RTP receiver and its decoder have caught up with the multicast session's current delivery, the receiver switches over to receiving directly from the multicast group. In many deployed applications, the (still existing) PtP RTP session is used as a repair channel, i.e., for RTP Retransmission traffic of those packets that were not received from the multicast group.
高速取得拡張機能により、SSMマルチキャストセッションに参加するエンドポイントは、最後の同期点から始まるメディア（前のパケットのデコードによって確立されたコンテキストを必要とせずにメディアをデコードできる場所）から、そのような時間まで高速で送信されるように要求できます。これらのバースト配信されたメディアパケットのデコード後、正しいメディアタイミングが確立されます。つまり、メディアパケットは、このアプリケーションに適したバッファ間隔内で受信されます。これは、最初にBurst / Retransmission Source（BRS）（図7）とRTPレシーバーの間にユニキャストPtP RTPセッションを確立することで実現されます。ユニキャストセッションは、受信者を進行中のマルチキャストRTPストリームに同期させるために、キャッシュされたパケットをマルチキャストグループから通常より高い速度で送信するために使用されます。 RTPレシーバーとそのデコーダーがマルチキャストセッションの現在の配信に追いつくと、レシーバーはマルチキャストグループからの直接受信に切り替えます。多くのデプロイされたアプリケーションでは、（まだ存在する）PtP RTPセッションは、修復チャネルとして、つまり、マルチキャストグループから受信されなかったパケットのRTP再送信トラフィック用に使用されます。
Shortcut name: Topo-Mesh
ショートカット名：Topo-Mesh
+---+ +---+
| A |<---->| B |
+---+ +---+
^ ^
\ /
\ /
v v
+---+
| C |
+---+
Figure 8: Point to Multipoint Using Mesh
図8：メッシュを使用したポイントツーマルチポイント
Based on the RTP session definition, it is clearly possible to have a joint RTP session involving three or more endpoints over multiple unicast transport flows, like the joint three-endpoint session depicted above. In this case, A needs to send its RTP streams and RTCP packets to both B and C over their respective transport flows. As long as all endpoints do the same, everyone will have a joint view of the RTP session.
RTPセッションの定義に基づいて、上記の結合された3つのエンドポイントセッションのように、複数のユニキャストトランスポートフロー上の3つ以上のエンドポイントが関与する結合RTPセッションを持つことが明らかに可能です。この場合、Aは、RTPストリームとRTCPパケットをそれぞれのトランスポートフローを介してBとCの両方に送信する必要があります。すべてのエンドポイントが同じことをしている限り、誰もがRTPセッションを共同で見ることができます。
This topology does not create any additional requirements beyond the need to have multiple transport flows associated with a single RTP session. Note that an endpoint may use a single local port to receive all these transport flows (in which case the sending port, IP address, or SSRC can be used to demultiplex), or it might have separate local reception ports for each of the endpoints.
このトポロジでは、単一のRTPセッションに複数のトランスポートフローを関連付ける必要性以外に、追加の要件は発生しません。エンドポイントは、これらすべてのトランスポートフローを受信するために単一のローカルポートを使用する場合があります（この場合、送信ポート、IPアドレス、またはSSRCを使用して逆多重化できます）、またはエンドポイントごとに個別のローカル受信ポートがある場合があります。
+-A--------------------+
|+---+ |
||CAM| | +-B-----------+
|+---+ +-UDP1------| |-UDP1------+ |
| | | +-RTP1----| |-RTP1----+ | |
| V | | +-Video-| |-Video-+ | | |
|+----+ | | | |<----------------|BV1 | | | |
||ENC |----+-+-+--->AV1|---------------->| | | | |
|+----+ | | +-------| |-------+ | | |
| | | +---------| |---------+ | |
| | +-----------| |-----------+ |
| | | +-------------+
| | |
| | | +-C-----------+
| | +-UDP2------| |-UDP2------+ |
| | | +-RTP1----| |-RTP1----+ | |
| | | | +-Video-| |-Video-+ | | |
| +-------+-+-+--->AV1|---------------->| | | | |
| | | | |<----------------|CV1 | | | |
| | | +-------| |-------+ | | |
| | +---------| |---------+ | |
| +-----------| |-----------+ |
+----------------------+ +-------------+
Figure 9: A Multi-Unicast Mesh with a Joint RTP Session
図9：ジョイントRTPセッションを備えたマルチユニキャストメッシュ
Figure 9 depicts endpoint A's view of using a common RTP session when establishing the mesh as shown in Figure 8. There is only one RTP session (RTP1) but two transport flows (UDP1 and UDP2). The Media Source (CAM) is encoded and transmitted over the SSRC (AV1) across both transport layers. However, as this is a joint RTP session, the two streams must be the same. Thus, a congestion control adaptation needed for the paths A to B and A to C needs to use the most restricting path's properties.
図9は、図8に示すようにメッシュを確立するときに共通のRTPセッションを使用するエンドポイントAのビューを示しています。RTPセッションは1つ（RTP1）のみで、トランスポートフローは2つ（UDP1とUDP2）あります。 Media Source（CAM）はエンコードされ、SSRC（AV1）を介して両方のトランスポート層に送信されます。ただし、これはジョイントRTPセッションであるため、2つのストリームは同じである必要があります。したがって、パスAからBおよびAからCに必要な輻輳制御適応は、最も制限的なパスのプロパティを使用する必要があります。
An alternative structure for establishing the above topology is to use independent RTP sessions between each pair of peers, i.e., three different RTP sessions. In some scenarios, the same RTP stream may be sent from the transmitting endpoint; however, it also supports local adaptation taking place in one or more of the RTP streams, rendering them non-identical.
上記のトポロジを確立するための代替構造は、ピアの各ペア間で独立したRTPセッション、つまり3つの異なるRTPセッションを使用することです。一部のシナリオでは、同じRTPストリームが送信エンドポイントから送信される場合があります。ただし、1つ以上のRTPストリームで行われるローカル適応もサポートしているため、それらは同一ではありません。
+-A----------------------+ +-B-----------+
|+---+ | | |
||MIC| +-UDP1------| |-UDP1------+ |
|+---+ | +-RTP1----| |-RTP1----+ | |
| | +----+ | | +-Audio-| |-Audio-+ | | |
| +->|ENC1|--+-+-+--->AA1|------------->| | | | |
| | +----+ | | | |<-------------|BA1 | | | |
| | | | +-------| |-------+ | | |
| | | +---------| |---------+ | |
| | +-----------| |-----------+ |
| | ------------| |-------------|
| | | |-------------+
| | |
| | | +-C-----------+
| | | | |
| | +-UDP2------| |-UDP2------+ |
| | | +-RTP2----| |-RTP2----+ | |
| | +----+ | | +-Audio-| |-Audio-+ | | |
| +->|ENC2|--+-+-+--->AA2|------------->| | | | |
| +----+ | | | |<-------------|CA1 | | | |
| | | +-------| |-------+ | | |
| | +---------| |---------+ | |
| +-----------| |-----------+ |
+------------------------+ +-------------+
Figure 10: A Multi-Unicast Mesh with an Independent RTP Session
図10：独立したRTPセッションを備えたマルチユニキャストメッシュ
Let's review the topology when independent RTP sessions are used from A's perspective in Figure 10 by considering both how the media is handled and how the RTP sessions are set up in Figure 10. A's microphone is captured and the audio is fed into two different encoder instances, each with a different independent RTP session, i.e., RTP1 and RTP2, respectively. The SSRCs (AA1 and AA2) in each RTP session are completely independent, and the media bitrate produced by the encoders can also be tuned differently to address any congestion control requirements differing for the paths A to B compared to A to C.
図10のメディアの処理方法とRTPセッションの設定方法の両方を検討することにより、図10のAの視点から独立したRTPセッションが使用される場合のトポロジーを確認してみましょう。Aのマイクがキャプチャされ、オーディオが2つの異なるエンコーダインスタンスに供給されます。 、それぞれに異なる独立したRTPセッション、つまり、それぞれRTP1とRTP2があります。各RTPセッションのSSRC（AA1およびAA2）は完全に独立しており、エンコーダーによって生成されたメディアビットレートは、AからCと比較してパスAからBで異なる輻輳制御要件に対処するために異なる方法で調整できます。
From a topologies viewpoint, an important difference exists in the behavior around RTCP. First, when a single RTP session spans all three endpoints A, B, and C, and their connecting RTP streams, a common RTCP bandwidth is calculated and used for this single joint session. In contrast, when there are multiple independent RTP sessions, each RTP session has its local RTCP bandwidth allocation.
トポロジーの観点からは、RTCPに関する動作に重要な違いがあります。まず、単一のRTPセッションが3つすべてのエンドポイントA、B、C、およびそれらの接続RTPストリームにまたがる場合、共通のRTCP帯域幅が計算され、この単一のジョイントセッションに使用されます。対照的に、複数の独立したRTPセッションがある場合、各RTPセッションにはローカルRTCP帯域幅割り当てがあります。
Further, when multiple sessions are used, endpoints not directly involved in a session do not have any awareness of the conditions in those sessions. For example, in the case of the three-endpoint configuration in Figure 8, endpoint A has no awareness of the conditions occurring in the session between endpoints B and C (whereas if a single RTP session were used, it would have such awareness).
さらに、複数のセッションが使用されている場合、セッションに直接関与していないエンドポイントは、それらのセッションの状態を認識しません。たとえば、図8の3つのエンドポイント構成の場合、エンドポイントAは、エンドポイントBとCの間のセッションで発生している状態を認識していません（単一のRTPセッションが使用された場合、そのような認識があります）。
Loop detection is also affected. With independent RTP sessions, the SSRC/CSRC cannot be used to determine when an endpoint receives its own media stream, or a mixed media stream including its own media stream (a condition known as a loop). The identification of loops and, in most cases, their avoidance, has to be achieved by other means, for example, through signaling or the use of an RTP external namespace binding SSRC/CSRC among any communicating RTP sessions in the mesh.
ループ検出も影響を受けます。独立したRTPセッションでは、SSRC / CSRCを使用して、エンドポイントが独自のメディアストリーム、または独自のメディアストリームを含む混合メディアストリーム（ループと呼ばれる状態）をいつ受信するかを判断できません。ループの識別、およびほとんどの場合、それらの回避は、他の手段、たとえば、シグナリング、またはメッシュ内の通信しているRTPセッション間でSSRC / CSRCをバインドするRTP外部名前空間を使用することによって達成する必要があります。
This section discusses some additional usages related to point to multipoint of translators compared to the point-to-point cases in Section 3.2.1.
このセクションでは、セクション3.2.1のポイントツーポイントの場合と比較した、トランスレーターのポイントツーマルチポイントに関連するいくつかの追加の使用法について説明します。
Shortcut name: Topo-PtM-Trn-Translator
ショートカット名：Topo-PtM-Trn-Translator
This section discusses Transport Translator-only usages to enable multipoint sessions.
このセクションでは、マルチポイントセッションを有効にするためのトランスポートトランスレータのみの使用法について説明します。
+-----+
+---+ / \ +------------+ +---+
| A |<---/ \ | |<---->| B |
+---+ / \ | | +---+
+ Multicast +->| Translator |
+---+ \ Network / | | +---+
| C |<---\ / | |<---->| D |
+---+ \ / +------------+ +---+
+-----+
Figure 11: Point to Multipoint Using Multicast
図11：マルチキャストを使用したポイントツーマルチポイント
Figure 11 depicts an example of a Transport Translator performing at least IP address translation. It allows the (non-multicast-capable) endpoints B and D to take part in an Any-Source Multicast session involving endpoints A and C, by having the translator forward their unicast traffic to the multicast addresses in use, and vice versa. It must also forward B's traffic to D, and vice versa, to provide both B and D with a complete view of the session.
図11は、少なくともIPアドレス変換を実行するトランスポートトランスレーターの例を示しています。これにより、（非マルチキャスト対応の）エンドポイントBとDは、トランスレーターに使用中のマルチキャストアドレスにユニキャストトラフィックを転送させることにより、エンドポイントAとCを含むAny-Source Multicastセッションに参加できます。また、BとDの両方にセッションの完全なビューを提供するために、BのトラフィックをDに転送したり、その逆を行う必要があります。
+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Translator |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
Figure 12: RTP Translator (Relay) with Only Unicast Paths
図12：ユニキャストパスのみのRTPトランスレータ（リレー）
Another translator scenario is depicted in Figure 12. The translator in this case connects multiple endpoints through unicast. This can be implemented using a very simple Transport Translator which, in this document, is called a relay. The relay forwards all traffic it receives, both RTP and RTCP, to all other endpoints. In doing so, a multicast network is emulated without relying on a multicast-capable network infrastructure.
別のトランスレータシナリオを図12に示します。この場合のトランスレータは、ユニキャストを介して複数のエンドポイントを接続します。これは、このドキュメントではリレーと呼ばれる非常に単純なトランスポートトランスレータを使用して実装できます。リレーは、RTPとRTCPの両方を含むすべてのトラフィックを他のすべてのエンドポイントに転送します。その際、マルチキャスト対応ネットワークインフラストラクチャに依存することなく、マルチキャストネットワークがエミュレートされます。
For RTCP feedback, this results in a similar set of considerations to those described in the ASM RTP topology. It also puts some additional signaling requirements onto the session establishment; for example, a common configuration of RTP payload types is required.
RTCPフィードバックの場合、これにより、ASM RTPトポロジで説明されているものと同様の一連の考慮事項が生じます。また、セッションの確立にいくつかの追加のシグナリング要件を課します。たとえば、RTPペイロードタイプの一般的な設定が必要です。
Transport Translators and relays should always consider implementing source address filtering, to prevent attackers from using the listening ports on the translator to inject traffic. The translator can, however, go one step further, especially if explicit SSRC signaling is used, to prevent endpoints from sending SSRCs other than its own (that are, for example, used by other participants in the session). This can improve the security properties of the session, despite the use of group keys that on a cryptographic level allows anyone to impersonate another in the same RTP session.
トランスポートトランスレーターとリレーは、攻撃者がトランスレーターのリスニングポートを使用してトラフィックを注入するのを防ぐために、常に送信元アドレスフィルタリングの実装を検討する必要があります。ただし、トランスレータは、特に明示的なSSRCシグナリングが使用されている場合は、エンドポイントがそれ自体以外のSSRC（たとえば、セッションの他の参加者によって使用されている）を送信しないようにするために、さらに一歩進んでいくことができます。これにより、暗号化レベルで誰でも同じRTPセッションで別のユーザーになりすますことができるグループキーを使用しているにもかかわらず、セッションのセキュリティプロパティを改善できます。
A translator that doesn't change the RTP/RTCP packet content can be operated without requiring it to have access to the security contexts used to protect the RTP/RTCP traffic between the participants.
RTP / RTCPパケットの内容を変更しないトランスレータは、参加者間のRTP / RTCPトラフィックを保護するために使用されるセキュリティコンテキストにアクセスする必要がなくても操作できます。
In the context of multipoint communications, a Media Translator is not providing new mechanisms to establish a multipoint session. It is more of an enabler, or facilitator, that ensures a given endpoint or a defined subset of endpoints can participate in the session.
マルチポイント通信のコンテキストでは、Media Translatorはマルチポイントセッションを確立するための新しいメカニズムを提供していません。特定のエンドポイントまたは定義されたエンドポイントのサブセットがセッションに参加できるようにするのは、イネーブラーまたはファシリテーターのようなものです。
If endpoint B in Figure 11 were behind a limited network path, the translator may perform media transcoding to allow the traffic received from the other endpoints to reach B without overloading the path. This transcoding can help the other endpoints in the multicast part of the session, by not requiring the quality transmitted by A to be lowered to the bitrates that B is actually capable of receiving (and vice versa).
図11のエンドポイントBが制限されたネットワークパスの背後にある場合、トランスレータはメディアトランスコーディングを実行して、他のエンドポイントから受信したトラフィックがパスを過負荷にすることなくBに到達できるようにします。このトランスコーディングは、Aが送信する品質を、Bが実際に受信できるビットレートまで下げる必要がない（またはその逆）ことで、セッションのマルチキャスト部分の他のエンドポイントに役立ちます。
Shortcut name: Topo-Mixer
ショートカット名：Topo-Mixer
A mixer is a middlebox that aggregates multiple RTP streams that are part of a session by generating one or more new RTP streams and, in most cases, by manipulating the media data. One common application for a mixer is to allow a participant to receive a session with a reduced amount of resources.
ミキサーは、1つ以上の新しいRTPストリームを生成し、ほとんどの場合、メディアデータを操作することにより、セッションの一部である複数のRTPストリームを集約するミドルボックスです。ミキサーの一般的な用途の1つは、参加者が少ないリソース量でセッションを受信できるようにすることです。
+-----+
+---+ / \ +-----------+ +---+
| A |<---/ \ | |<---->| B |
+---+ / Multi- \ | | +---+
+ cast +->| Mixer |
+---+ \ Network / | | +---+
| C |<---\ / | |<---->| D |
+---+ \ / +-----------+ +---+
+-----+
Figure 13: Point to Multipoint Using the RFC 3550 Mixer Model
図13：RFC 3550ミキサーモデルを使用したポイントツーマルチポイント
A mixer can be viewed as a device terminating the RTP streams received from other endpoints in the same RTP session. Using the media data carried in the received RTP streams, a mixer generates derived RTP streams that are sent to the receiving endpoints.
ミキサーは、同じRTPセッションで他のエンドポイントから受信したRTPストリームを終端するデバイスと見なすことができます。ミキサは、受信したRTPストリームで伝送されるメディアデータを使用して、受信エンドポイントに送信される派生RTPストリームを生成します。
The content that the mixer provides is the mixed aggregate of what the mixer receives over the PtP or PtM paths, which are part of the same Communication Session.
ミキサーが提供するコンテンツは、同じ通信セッションの一部であるPtPまたはPtMパスを介してミキサーが受信するものの混合された集合体です。
The mixer creates the Media Source and the source RTP stream just like an endpoint, as it mixes the content (often in the uncompressed domain) and then encodes and packetizes it for transmission to a receiving endpoint. The CSRC Count (CC) and CSRC fields in the RTP header can be used to indicate the contributors to the newly generated RTP stream. The SSRCs of the to-be-mixed streams on the mixer input appear as the CSRCs at the mixer output. That output stream uses a unique SSRC that identifies the mixer's stream. The CSRC should be forwarded between the different endpoints to allow for loop detection and identification of sources that are part of the Communication Session. Note that Section 7.1 of RFC 3550 requires the SSRC space to be shared between domains for these reasons. This also implies that any SDES information normally needs to be forwarded across the mixer.
ミキサーは、コンテンツを（多くの場合、非圧縮ドメインで）混合し、受信エンドポイントへの送信用にエンコードおよびパケット化するため、エンドポイントのようにメディアソースとソースRTPストリームを作成します。 RTPヘッダーのCSRCカウント（CC）およびCSRCフィールドを使用して、新しく生成されたRTPストリームへの貢献者を示すことができます。ミキサ入力で混合されるストリームのSSRCは、ミキサ出力でCSRCとして表示されます。その出力ストリームは、ミキサーのストリームを識別する一意のSSRCを使用します。通信セッションの一部であるソースのループ検出と識別を可能にするために、CSRCは異なるエンドポイント間で転送される必要があります。 RFC 3550のセクション7.1では、これらの理由により、ドメイン間でSSRCスペースを共有する必要があることに注意してください。これは、SDES情報は通常、ミキサー全体に転送される必要があることも意味します。
The mixer is responsible for generating RTCP packets in accordance with its role. It is an RTP receiver and should therefore send RTCP receiver reports for the RTP streams it receives and terminates. In its role as an RTP sender, it should also generate RTCP sender reports for those RTP streams it sends. As specified in Section 7.3 of RFC 3550, a mixer must not forward RTCP unaltered between the two domains.
ミキサーは、その役割に従ってRTCPパケットを生成します。これはRTPレシーバーであるため、受信して終了するRTPストリームのRTCPレシーバーレポートを送信する必要があります。 RTP送信者としての役割では、送信するRTPストリームのRTCP送信者レポートも生成する必要があります。 RFC 3550のセクション7.3で指定されているように、ミキサーは2つのドメイン間で変更されていないRTCPを転送してはなりません。
The mixer depicted in Figure 13 is involved in three domains that need to be separated: the Any-Source Multicast network (including endpoints A and C), endpoint B, and endpoint D. Assuming all four endpoints in the conference are interested in receiving content from all other endpoints, the mixer produces different mixed RTP streams for B and D, as the one to B may contain content received from D, and vice versa. However, the mixer may only need one SSRC per media type in each domain where it is the receiving entity and transmitter of mixed content.
図13に示されているミキサーは、分離する必要がある3つのドメインに関与しています。Any-SourceMulticastネットワーク（エンドポイントAおよびCを含む）、エンドポイントB、およびエンドポイントD。会議の4つのエンドポイントすべてがコンテンツの受信に関心があると仮定します。他のすべてのエンドポイントから、ミキサーはBとDの異なる混合RTPストリームを生成します。これは、1からBにはDから受信したコンテンツが含まれている場合があり、その逆の場合も同様です。ただし、ミキサーは、それが混合コンテンツの受信エンティティおよび送信者である各ドメインのメディアタイプごとに1つのSSRCしか必要としない場合があります。
In the multicast domain, a mixer still needs to provide a mixed view of the other domains. This makes the mixer simpler to implement and avoids any issues with advanced RTCP handling or loop detection, which would be problematic if the mixer were providing non-symmetric behavior. Please see Section 3.11 for more discussion on this topic. The mixing operation, however, in each domain could potentially be different.
マルチキャストドメインでは、ミキサーは他のドメインの混合ビューを提供する必要があります。これにより、ミキサーの実装が簡単になり、高度なRTCP処理やループ検出に関する問題が回避されます。これは、ミキサーが非対称の動作を提供する場合に問題になります。このトピックの詳細については、セクション3.11を参照してください。ただし、各ドメインでの混合操作は異なる可能性があります。
A mixer is responsible for receiving RTCP feedback messages and handling them appropriately. The definition of "appropriate" depends on the message itself and the context. In some cases, the reception of a codec-control message by the mixer may result in the generation and transmission of RTCP feedback messages by the mixer to the endpoints in the other domain(s). In other cases, a message is handled by the mixer locally and therefore not forwarded to any other domain.
ミキサーは、RTCPフィードバックメッセージを受信し、適切に処理します。 「適切」の定義は、メッセージ自体とコンテキストによって異なります。場合によっては、ミキサーがコーデック制御メッセージを受信すると、ミキサーがRTCPフィードバックメッセージを生成して他のドメインのエンドポイントに送信することがあります。他の場合では、メッセージはミキサーによってローカルで処理されるため、他のドメインには転送されません。
When replacing the multicast network in Figure 13 (to the left of the mixer) with individual unicast paths as depicted in Figure 14, the mixer model is very similar to the one discussed in Section 3.9 below. Please see the discussion in Section 3.9 about the differences between these two models.
図14に示すように、図13（ミキサーの左側）のマルチキャストネットワークを個別のユニキャストパスに置き換える場合、ミキサーモデルは、以下のセクション3.9で説明するモデルと非常に似ています。これらの2つのモデルの違いについては、セクション3.9の説明を参照してください。
+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Mixer |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
Figure 14: RTP Mixer with Only Unicast Paths
図14：ユニキャストパスのみのRTPミキサー
We now discuss in more detail the different mixing operations that a mixer can perform and how they can affect RTP and RTCP behavior.
ここで、ミキサーが実行できるさまざまなミキシング操作と、RTPおよびRTCPの動作にどのように影響を与えることができるかについて詳しく説明します。
The Media-Mixing Mixer is likely the one that most think of when they hear the term "mixer". Its basic mode of operation is that it receives RTP streams from several endpoints and selects the stream(s) to be included in a media-domain mix. The selection can be through static configuration or by dynamic, content-dependent means such as voice activation. The mixer then creates a single outgoing RTP stream from this mix.
Media-Mixing Mixerは、「ミキサー」という用語を聞いたときに最もよく考えられるものです。その基本的な動作モードは、複数のエンドポイントからRTPストリームを受信し、メディアドメインミックスに含めるストリームを選択することです。選択は、静的構成を介して、または音声アクティベーションなどの動的なコンテンツ依存の手段を介して行うことができます。次に、ミキサーはこのミックスから単一の発信RTPストリームを作成します。
The most commonly deployed Media-Mixing Mixer is probably the audio mixer, used in voice conferencing, where the output consists of a mixture of all the input audio signals; this needs minimal signaling to be successfully set up. From a signal processing viewpoint, audio mixing is relatively straightforward and commonly possible for a reasonable number of endpoints. Assume, for example, that one wants to mix N streams from N different endpoints. The mixer needs to decode those N streams, typically into the sample domain, and then produce N or N+1 mixes. Different mixes are needed so that each endpoint gets a mix of all other sources except its own, as this would result in an echo. When N is lower than the number of all endpoints, one may produce a mix of all N streams for the group that are currently not included in the mix; thus, N+1 mixes. These audio streams are then encoded again, RTP packetized, and sent out. In many cases, audio level normalization, noise suppression, and similar signal processing steps are also required or desirable before the actual mixing process commences.
最も一般的に展開されているMedia-Mixing Mixerはおそらく音声会議で使用されるオーディオミキサーであり、出力はすべての入力オーディオ信号の混合で構成されます。これを正しく設定するには、最小限のシグナリングが必要です。信号処理の観点からは、オーディオミキシングは比較的単純であり、妥当な数のエンドポイントで一般的に可能です。たとえば、N個の異なるエンドポイントからのN個のストリームを混合したいとします。ミキサーは、これらのNストリームを、通常はサンプルドメインにデコードしてから、NまたはN + 1ミックスを生成する必要があります。エコーが発生するため、各エンドポイントが自身のソースを除く他のすべてのソースのミックスを取得できるように、異なるミックスが必要です。 Nがすべてのエンドポイントの数よりも小さい場合、現在ミックスに含まれていない、グループのすべてのNストリームのミックスを生成できます。したがって、N + 1が混合します。これらのオーディオストリームは、再度エンコードされ、RTPパケット化されて送信されます。多くの場合、実際のミキシングプロセスを開始する前に、オーディオレベルの正規化、ノイズ抑制、および同様の信号処理ステップも必要または望ましいです。
In video, the term "mixing" has a different interpretation than audio. It is commonly used to refer to the process of spatially combining contributed video streams, which is also known as "tiling". The reconstructed, appropriately scaled down videos can be spatially arranged in a set of tiles, with each tile containing the video from an endpoint (typically showing a human participant). Tiles can be of different sizes so that, for example, a particularly important participant, or the loudest speaker, is being shown in a larger tile than other participants. A self-view picture can be included in the tiling, which can be either locally produced or feedback from a mixer-received and reconstructed video image. Such remote loopback allows for confidence monitoring, i.e., it enables the participant to see himself/herself in the same quality as other participants see him/her. The tiling normally operates on reconstructed video in the sample domain. The tiled image is encoded, packetized, and sent by the mixer to the receiving endpoints. It is possible that a middlebox with media mixing duties contains only a single mixer of the aforementioned type, in which case all participants necessarily see the same tiled video, even if it is being sent over different RTP streams. More common, however, are mixing arrangements where an individual mixer is available for each outgoing port of the middlebox, allowing individual compositions for each receiving endpoint (a feature commonly referred to as personalized layout).
ビデオでは、「ミキシング」という用語の解釈はオーディオとは異なります。これは一般的に、「タイリング」とも呼ばれる、提供されたビデオストリームを空間的に組み合わせるプロセスを指すために使用されます。再構成され、適切に縮小されたビデオは、一連のタイルに空間的に配置でき、各タイルにはエンドポイント（通常は人間の参加者を示す）からのビデオが含まれます。タイルはさまざまなサイズにすることができるため、たとえば、特に重要な参加者や最大のスピーカーが他の参加者よりも大きなタイルで表示されます。セルフビュー画像をタイリングに含めることができます。タイリングは、ローカルで作成するか、ミキサーで受信して再構築したビデオ画像からフィードバックすることができます。このようなリモートループバックにより、信頼性の監視が可能になります。つまり、参加者は、他の参加者が見ているのと同じ品質で自分自身を見ることができます。タイリングは通常、サンプルドメインの再構成されたビデオで動作します。タイル画像はエンコードされ、パケット化され、ミキサーによって受信エンドポイントに送信されます。メディアミキシング機能を備えたミドルボックスに前述のタイプのミキサーが1つだけ含まれている可能性があります。その場合、たとえ異なるRTPストリームで送信されている場合でも、すべての参加者は必ず同じタイルビデオを見ることができます。ただし、より一般的なのは、ミドルボックスの各発信ポートに個別のミキサーを使用できるミキシング配置であり、受信エンドポイントごとに個別のコンポジションが可能になります（一般にパーソナライズされたレイアウトと呼ばれる機能）。
One problem with media mixing is that it consumes both large amounts of media processing resources (for the decoding and mixing process in the uncompressed domain) and encoding resources (for the encoding of the mixed signal). Another problem is the quality degradation created by decoding and re-encoding the media, which is the result of the lossy nature of the most commonly used media codecs. A third problem is the latency introduced by the media mixing, which can be substantial and annoyingly noticeable in case of video, or in case of audio if that mixed audio is lip-synchronized with high-latency video. The advantage of media mixing is that it is straightforward for the endpoints to handle the single media stream (which includes the mixed aggregate of many sources), as they don't need to handle multiple decodings, local mixing, and composition. In fact, mixers were introduced in pre-RTP times so that legacy, single stream receiving endpoints (that, in some protocol environments, actually didn't need to be aware of the multipoint nature of the conference) could successfully participate in what a user would recognize as a multiparty video conference.
メディアミキシングの問題の1つは、大量のメディア処理リソース（非圧縮ドメインでのデコードおよびミキシングプロセス用）とエンコードリソース（混合信号のエンコード用）の両方を消費することです。もう1つの問題は、メディアのデコードと再エンコードによって生じる品質の低下です。これは、最も一般的に使用されているメディアコーデックの非可逆性の結果です。 3番目の問題は、メディアミキシングによって発生するレイテンシです。これは、ビデオの場合、またはオーディオの場合、混合されたオーディオが高レイテンシビデオとリップシンクされる場合、かなり大きくて気になるほど顕著になります。メディアミキシングの利点は、複数のデコード、ローカルミキシング、およびコンポジションを処理する必要がないため、エンドポイントが単一のメディアストリーム（多くのソースの混合された集合体を含む）を処理することが簡単であることです。実際、ミキサーはRTP以前に導入されたため、レガシーの単一ストリーム受信エンドポイント（一部のプロトコル環境では、実際には会議のマルチポイントの性質を意識する必要がなかった）がユーザーの参加に成功することができましたマルチパーティのビデオ会議として認識されます。
+-A---------+ +-MIXER----------------------+
| +-RTP1----| |-RTP1------+ +-----+ |
| | +-Audio-| |-Audio---+ | +---+ | | |
| | | AA1|--------->|---------+-+-|DEC|->| | |
| | | |<---------|MA1 <----+ | +---+ | | |
| | | | |(BA1+CA1)|\| +---+ | | |
| | +-------| |---------+ +-|ENC|<-| B+C | |
| +---------| |-----------+ +---+ | | |
+-----------+ | | | |
| | M | |
+-B---------+ | | E | |
| +-RTP2----| |-RTP2------+ | D | |
| | +-Audio-| |-Audio---+ | +---+ | I | |
| | | BA1|--------->|---------+-+-|DEC|->| A | |
| | | |<---------|MA2 <----+ | +---+ | | |
| | +-------| |(AA1+CA1)|\| +---+ | | |
| +---------| |---------+ +-|ENC|<-| A+C | |
+-----------+ |-----------+ +---+ | | |
| | M | |
+-C---------+ | | I | |
| +-RTP3----| |-RTP3------+ | X | |
| | +-Audio-| |-Audio---+ | +---+ | E | |
| | | CA1|--------->|---------+-+-|DEC|->| R | |
| | | |<---------|MA3 <----+ | +---+ | | |
| | +-------| |(AA1+BA1)|\| +---+ | | |
| +---------| |---------+ +-|ENC|<-| A+B | |
+-----------+ |-----------+ +---+ +-----+ |
+----------------------------+
Figure 15: Session and SSRC Details for Media Mixer
図15：メディアミキサーのセッションとSSRCの詳細
From an RTP perspective, media mixing can be a very simple process, as can be seen in Figure 15. The mixer presents one SSRC towards the receiving endpoint, e.g., MA1 to Peer A, where the associated stream is the media mix of the other endpoints. As each peer, in this example, receives a different version of a mix from the mixer, there is no actual relation between the different RTP sessions in terms of actual media or transport-level information. There are, however, common relationships between RTP1-RTP3, namely SSRC space and identity information. When A receives the MA1 stream, which is a combination of BA1 and CA1 streams, the mixer may include CSRC information in the MA1 stream to identify the Contributing Sources BA1 and CA1, allowing the receiver to identify the Contributing Sources even if this were not possible through the media itself or through other signaling means.
図15に示すように、RTPの観点からは、メディアミキシングは非常に単純なプロセスである可能性があります。ミキサーは、1つのSSRCを受信エンドポイントに向けて提示します（例：MA1からピアAへ）。関連するストリームは他のメディアミックスです。エンドポイント。この例では、各ピアがミキサーから異なるバージョンのミックスを受信するため、実際のメディアまたはトランスポートレベルの情報に関して、異なるRTPセッション間に実際の関係はありません。ただし、RTP1とRTP3の間には共通の関係があります。つまり、SSRCスペースとID情報です。 AがBA1ストリームとCA1ストリームの組み合わせであるMA1ストリームを受信すると、ミキサーはCSRC情報をMA1ストリームに含めて、貢献ソースBA1とCA1を識別し、これが不可能な場合でも受信者が貢献ソースを識別できるようにします。メディア自体または他の信号手段を介して。
The CSRC has, in turn, utility in RTP extensions, like the RTP header extension for Mixer-to-Client Audio Level Indication [RFC6465]. If the SSRCs from the endpoint to mixer paths are used as CSRCs in another RTP session, then RTP1, RTP2, and RTP3 become one joint session as they have a common SSRC space. At this stage, the mixer also needs to consider which RTCP information it needs to expose in the different paths. In the above scenario, a mixer would normally expose nothing more than the SDES information and RTCP BYE for a CSRC leaving the session. The main goal would be to enable the correct binding against the application logic and other information sources. This also enables loop detection in the RTP session.
次に、CSRCは、ミキサーからクライアントへのオーディオレベル表示[RFC6465]のRTPヘッダー拡張のようなRTP拡張にユーティリティを備えています。エンドポイントからミキサーパスへのSSRCが別のRTPセッションでCSRCとして使用される場合、RTP1、RTP2、およびRTP3は、共通のSSRCスペースがあるため、1つのジョイントセッションになります。この段階で、ミキサーは、異なるパスで公開する必要のあるRTCP情報も考慮する必要があります。上記のシナリオでは、ミキサーは通常、セッションを離れるCSRCに対して、SDES情報とRTCP BYEしか公開しません。主な目標は、アプリケーションロジックやその他の情報ソースに対して正しいバインディングを有効にすることです。これにより、RTPセッションでのループ検出も有効になります。
Media-Switching Mixers are used in limited functionality scenarios where no, or only very limited, concurrent presentation of multiple sources is required by the application and also in more complex multi-stream usages with receiver mixing or tiling, including combined with simulcast and/or scalability between source and mixer. An RTP mixer based on media switching avoids the media decoding and encoding operations in the mixer, as it conceptually forwards the encoded media stream as it was being sent to the mixer. It does not avoid, however, the decryption and re-encryption cycle as it rewrites RTP headers. Forwarding media (in contrast to reconstructing-mixing-encoding media) reduces the amount of computational resources needed in the mixer and increases the media quality (both in terms of fidelity and reduced latency).
Media-Switching Mixersは、アプリケーションで複数のソースの同時プレゼンテーションが必要とされない、または非常に限られた限られた機能のシナリオで使用されます。また、サイマルキャストおよび/またはソースとミキサー間のスケーラビリティ。メディアスイッチングに基づくRTPミキサーは、ミキサーへの送信時にエンコードされたメディアストリームを概念的に転送するため、ミキサーでのメディアのデコードおよびエンコード操作を回避します。ただし、RTPヘッダーを書き換えるため、復号化と再暗号化のサイクルは回避されません。フォワーディングメディア（再構成ミキシングエンコーディングメディアとは対照的に）は、ミキサーで必要な計算リソースの量を減らし、メディアの品質を向上させます（忠実度と遅延の両方に関して）。
A Media-Switching Mixer maintains a pool of SSRCs representing conceptual or functional RTP streams that the mixer can produce. These RTP streams are created by selecting media from one of the RTP streams received by the mixer and forwarded to the peer using the mixer's own SSRCs. The mixer can switch between available sources if that is required by the concept for the source, like the currently active speaker. Note that the mixer, in most cases, still needs to perform a certain amount of media processing, as many media formats do not allow to "tune into" the stream at arbitrary points in their bitstream.
メディアスイッチングミキサーは、ミキサーが生成できる概念的または機能的なRTPストリームを表すSSRCのプールを維持します。これらのRTPストリームは、ミキサーが受信したRTPストリームの1つからメディアを選択することによって作成され、ミキサー自体のSSRCを使用してピアに転送されます。現在アクティブなスピーカーなど、ソースのコンセプトで必要な場合、ミキサーは利用可能なソースを切り替えることができます。多くのメディア形式では、ビットストリームの任意のポイントでストリームを「調整」することができないため、ほとんどの場合、ミキサーは一定量のメディア処理を実行する必要があることに注意してください。
To achieve a coherent RTP stream from the mixer's SSRC, the mixer needs to rewrite the incoming RTP packet's header. First, the SSRC field must be set to the value of the mixer's SSRC. Second, the sequence number must be the next in the sequence of outgoing packets it sent. Third, the RTP timestamp value needs to be adjusted using an offset that changes each time one switches the Media Source. Finally, depending on the negotiation of the RTP payload type, the value representing this particular RTP payload configuration may have to be changed if the different endpoint-to-mixer paths have not arrived on the same numbering for a given configuration. This also requires that the different endpoints support a common set of codecs, otherwise media transcoding for codec compatibility would still be required.
ミキサーのSSRCからコヒーレントなRTPストリームを実現するには、ミキサーは着信RTPパケットのヘッダーを書き換える必要があります。まず、SSRCフィールドをミキサーのSSRCの値に設定する必要があります。次に、シーケンス番号は、送信した発信パケットのシーケンスの次でなければなりません。 3番目に、RTPタイムスタンプ値は、メディアソースを切り替えるたびに変化するオフセットを使用して調整する必要があります。最後に、RTPペイロードタイプのネゴシエーションによっては、この特定のRTPペイロード構成を表す値は、異なるエンドポイントからミキサーへのパスが特定の構成の同じ番号に到達していない場合に変更する必要があります。これには、さまざまなエンドポイントが共通のコーデックセットをサポートすることも必要です。それ以外の場合は、コーデック互換性のためのメディアトランスコーディングが依然として必要です。
We now consider the operation of a Media-Switching Mixer that supports a video conference with six participating endpoints (A-F) where the two most recent speakers in the conference are shown to each receiving endpoint. Thus, the mixer has two SSRCs sending video to each peer, and each peer is capable of locally handling two video streams simultaneously.
次に、会議の最新の2人の発言者が各受信エンドポイントに表示される、6つの参加エンドポイント（A-F）でのビデオ会議をサポートするメディア切り替えミキサーの操作を検討します。したがって、ミキサーには、各ピアにビデオを送信する2つのSSRCがあり、各ピアは2つのビデオストリームをローカルで同時に処理できます。
+-A---------+ +-MIXER----------------------+
| +-RTP1----| |-RTP1------+ +-----+ |
| | +-Video-| |-Video---+ | | | |
| | | AV1|------------>|---------+-+------->| S | |
| | | |<------------|MV1 <----+-+-BV1----| W | |
| | | |<------------|MV2 <----+-+-EV1----| I | |
| | +-------| |---------+ | | T | |
| +---------| |-----------+ | C | |
+-----------+ | | H | |
| | | |
+-B---------+ | | M | |
| +-RTP2----| |-RTP2------+ | A | |
| | +-Video-| |-Video---+ | | T | |
| | | BV1|------------>|---------+-+------->| R | |
| | | |<------------|MV3 <----+-+-AV1----| I | |
| | | |<------------|MV4 <----+-+-EV1----| X | |
| | +-------| |---------+ | | | |
| +---------| |-----------+ | | |
+-----------+ | | | |
: : : :
: : : :
+-F---------+ | | | |
| +-RTP6----| |-RTP6------+ | | |
| | +-Video-| |-Video---+ | | | |
| | | FV1|------------>|---------+-+------->| | |
| | | |<------------|MV11 <---+-+-AV1----| | |
| | | |<------------|MV12 <---+-+-EV1----| | |
| | +-------| |---------+ | | | |
| +---------| |-----------+ +-----+ |
+-----------+ +----------------------------+
Figure 16: Media-Switching RTP Mixer
図16：メディア切り替えRTPミキサー
The Media-Switching Mixer can, similarly to the Media-Mixing Mixer, reduce the bitrate required for media transmission towards the different peers by selecting and forwarding only a subset of RTP streams it receives from the sending endpoints. In case the mixer receives simulcast transmissions or a scalable encoding of the Media Source, the mixer has more degrees of freedom to select streams or subsets of streams to forward to a receiving endpoint, both based on transport or endpoint restrictions as well as application logic.
Media-Switching Mixerは、Media-Mixing Mixerと同様に、送信エンドポイントから受信するRTPストリームのサブセットのみを選択して転送することにより、異なるピアへのメディア送信に必要なビットレートを削減できます。ミキサーが同時送信またはメディアソースのスケーラブルなエンコーディングを受信する場合、ミキサーは、トランスポートまたはエンドポイントの制限とアプリケーションロジックの両方に基づいて、受信エンドポイントに転送するストリームまたはストリームのサブセットを選択する自由度が高くなります。
To ensure that a media receiver in an endpoint can correctly decode the media in the RTP stream after a switch, a codec that uses temporal prediction needs to start its decoding from independent refresh points, or points in the bitstream offering similar functionality (like "dirty refresh points"). For some codecs, for example, frame-based speech and audio codecs, this is easily achieved by starting the decoding at RTP packet boundaries, as each packet boundary provides a refresh point (assuming proper packetization on the encoder side). For other codecs, particularly in video, refresh points are less common in the bitstream or may not be present at all without an explicit request to the respective encoder. The Full Intra Request [RFC5104] RTCP codec control message has been defined for this purpose.
エンドポイントのメディアレシーバーが切り替え後にRTPストリームのメディアを正しくデコードできるようにするには、時間予測を使用するコーデックが、独立したリフレッシュポイント、または同様の機能を提供するビットストリームのポイント（「ダーティ」など）からデコードを開始する必要があります。更新ポイント」）。一部のコーデック（フレームベースの音声コーデックやオーディオコーデックなど）では、RTPパケット境界でデコードを開始することでこれを簡単に実現できます。これは、各パケット境界が更新ポイントを提供するためです（エンコーダー側での適切なパケット化を前提としています）。他のコーデック、特にビデオの場合、リフレッシュポイントはビットストリームではあまり一般的ではないか、それぞれのエンコーダーへの明示的な要求がないとまったく存在しない場合があります。フルイントラリクエスト[RFC5104] RTCPコーデックコントロールメッセージは、この目的のために定義されています。
In this type of mixer, one could consider fully terminating the RTP sessions between the different endpoint and mixer paths. The same arguments and considerations as discussed in Section 3.9 need to be taken into consideration and apply here.
このタイプのミキサーでは、異なるエンドポイントとミキサーパス間のRTPセッションを完全に終了することを検討できます。セクション3.9で説明したのと同じ議論と考慮事項を考慮に入れ、ここで適用する必要があります。
Another method for handling media in the RTP mixer is to "project", or make available, all potential RTP sources (SSRCs) into a per-endpoint, independent RTP session. The middlebox can select which of the potential sources that are currently actively transmitting media will be sent to each of the endpoints. This is similar to the Media-Switching Mixer but has some important differences in RTP details.
RTPミキサーでメディアを処理するもう1つの方法は、すべての潜在的なRTPソース（SSRC）をエンドポイントごとの独立したRTPセッションに "投影"または利用可能にすることです。ミドルボックスは、現在アクティブにメディアを送信している潜在的なソースのどれを各エンドポイントに送信するかを選択できます。これはMedia-Switching Mixerに似ていますが、RTPの詳細にいくつかの重要な違いがあります。
+-A---------+ +-Middlebox-----------------+
| +-RTP1----| |-RTP1------+ +-----+ |
| | +-Video-| |-Video---+ | | | |
| | | AV1|------------>|---------+-+------>| | |
| | | |<------------|BV1 <----+-+-------| S | |
| | | |<------------|CV1 <----+-+-------| W | |
| | | |<------------|DV1 <----+-+-------| I | |
| | | |<------------|EV1 <----+-+-------| T | |
| | | |<------------|FV1 <----+-+-------| C | |
| | +-------| |---------+ | | H | |
| +---------| |-----------+ | | |
+-----------+ | | M | |
| | A | |
+-B---------+ | | T | |
| +-RTP2----| |-RTP2------+ | R | |
| | +-Video-| |-Video---+ | | I | |
| | | BV1|------------>|---------+-+------>| X | |
| | | |<------------|AV1 <----+-+-------| | |
| | | |<------------|CV1 <----+-+-------| | |
| | | | : : : |: : : : : : : : :| | |
| | | |<------------|FV1 <----+-+-------| | |
| | +-------| |---------+ | | | |
| +---------| |-----------+ | | |
+-----------+ | | | |
: : : :
: : : :
+-F---------+ | | | |
| +-RTP6----| |-RTP6------+ | | |
| | +-Video-| |-Video---+ | | | |
| | | FV1|------------>|---------+-+------>| | |
| | | |<------------|AV1 <----+-+-------| | |
| | | | : : : |: : : : : : : : :| | |
| | | |<------------|EV1 <----+-+-------| | |
| | +-------| |---------+ | | | |
| +---------| |-----------+ +-----+ |
+-----------+ +---------------------------+
Figure 17: Selective Forwarding Middlebox
図17：選択的転送ミドルボックス
In the six endpoint conference depicted above (in Figure 17), one can see that endpoint A is aware of five incoming SSRCs, BV1-FV1. If this middlebox intends to have a similar behavior as in Section 3.6.2 where the mixer provides the endpoints with the two latest speaking endpoints, then only two out of these five SSRCs need concurrently transmit media to A. As the middlebox selects the source in the different RTP sessions that transmit media to the endpoints, each RTP stream requires the rewriting of certain RTP header fields when being projected from one session into another. In particular, the sequence number needs to be consecutively incremented based on the packet actually being transmitted in each RTP session. Therefore, the RTP sequence number offset will change each time a source is turned on in an RTP session. The timestamp (possibly offset) stays the same.
上に示した6つのエンドポイント会議（図17）では、エンドポイントAが5つの着信SSRC、BV1-FV1を認識していることがわかります。このミドルボックスがセクション3.6.2と同様の動作をする予定の場合、ミキサーがエンドポイントに2つの最新の発話エンドポイントを提供する場合、これら5つのSSRCのうち2つだけがメディアをAに同時に送信する必要があります。ミドルボックスがエンドポイントにメディアを送信するさまざまなRTPセッションでは、各RTPストリームは、あるセッションから別のセッションに投影されるときに、特定のRTPヘッダーフィールドの書き換えが必要です。特に、シーケンス番号は、各RTPセッションで実際に送信されているパケットに基づいて連続的にインクリメントする必要があります。したがって、RTPシーケンス番号オフセットは、RTPセッションでソースがオンになるたびに変更されます。タイムスタンプ（場合によってはオフセット）は変わりません。
The RTP sessions can be considered independent, resulting in that the SSRC numbers used can also be handled independently. This simplifies the SSRC collision detection and avoidance but requires tools such as remapping tables between the RTP sessions. Using independent RTP sessions is not required, as it is possible for the switching behavior to also perform with a common SSRC space. However, in this case, collision detection and handling becomes a different problem. It is up to the implementation to use a single common SSRC space or separate ones.
RTPセッションは独立していると見なすことができるため、使用されるSSRC番号も独立して処理できます。これにより、SSRC衝突の検出と回避が簡素化されますが、RTPセッション間でテーブルを再マッピングするなどのツールが必要です。スイッチング動作が共通のSSRCスペースでも実行できるため、独立したRTPセッションを使用する必要はありません。ただし、この場合、衝突の検出と処理は別の問題になります。単一の共通SSRCスペースまたは個別のスペースを使用するかどうかは、実装次第です。
Using separate SSRC spaces has some implications. For example, the RTP stream that is being sent by endpoint B to the middlebox (BV1) may use an SSRC value of 12345678. When that RTP stream is sent to endpoint F by the middlebox, it can use any SSRC value, e.g., 87654321. As a result, each endpoint may have a different view of the application usage of a particular SSRC. Any RTP-level identity information, such as SDES items, also needs to update the SSRC referenced, if the included SDES items are intended to be global. Thus, the application must not use SSRC as references to RTP streams when communicating with other peers directly. This also affects loop detection, which will fail to work as there is no common namespace and identities across the different legs in the Communication Session on the RTP level. Instead, this responsibility falls onto higher layers.
個別のSSRCスペースを使用すると、いくつかの影響があります。たとえば、エンドポイントBからミドルボックス（BV1）に送信されているRTPストリームは、SSRC値12345678を使用できます。そのRTPストリームがミドルボックスによってエンドポイントFに送信される場合、87654321などの任意のSSRC値を使用できます。その結果、各エンドポイントは、特定のSSRCのアプリケーション使用の異なるビューを持つ場合があります。含まれるSDESアイテムがグローバルであることを意図している場合、SDESアイテムなどのRTPレベルの識別情報も、参照されるSSRCを更新する必要があります。したがって、他のピアと直接通信する場合、アプリケーションはSSRCをRTPストリームへの参照として使用してはなりません。これはループ検出にも影響します。RTPレベルの通信セッションでは、異なるレッグに共通の名前空間とIDがないため、機能しません。代わりに、この責任は上位層にあります。
The middlebox is also responsible for receiving any RTCP codec control requests coming from an endpoint and deciding if it can act on the request locally or needs to translate the request into the RTP session/transport leg that contains the Media Source. Both endpoints and the middlebox need to implement conference-related codec control functionalities to provide a good experience. Commonly used are Full Intra Request to request from the Media Source that switching points be provided between the sources and Temporary Maximum Media Bitrate Request (TMMBR) to enable the middlebox to aggregate congestion control responses towards the Media Source so to enable it to adjust its bitrate (obviously, only in case the limitation is not in the source to middlebox link).
ミドルボックスは、エンドポイントからのRTCPコーデック制御要求を受信し、ローカルで要求に作用できるかどうか、またはメディアソースを含むRTPセッション/トランスポートレッグに要求を変換する必要があるかどうかを決定する役割も果たします。優れたエクスペリエンスを提供するには、エンドポイントとミドルボックスの両方に、会議関連のコーデック制御機能を実装する必要があります。一般的に使用されるのは、ソース間で切り替えポイントを提供するようメディアソースから要求するフルイントラリクエストと、ミドルボックスがメディアソースに向けて輻輳制御応答を集約してビットレートを調整できるようにするための一時最大メディアビットレートリクエスト（TMMBR）です。 （明らかに、ソースからミドルボックスへのリンクに制限がない場合にのみ）。
The Selective Forwarding Middlebox has been introduced in recently developed videoconferencing systems in conjunction with, and to capitalize on, scalable video coding as well as simulcasting. An example of scalable video coding is Annex G of H.264, but other codecs, including H.264 AVC and VP8, also exhibit scalability, albeit only in the temporal dimension. In both scalable coding and simulcast cases, the video signal is represented by a set of two or more bitstreams, providing a corresponding number of distinct fidelity points. The middlebox selects which parts of a scalable bitstream (or which bitstream, in the case of simulcasting) to forward to each of the receiving endpoints. The decision may be driven by a number of factors, such as available bitrate, desired layout, etc. Contrary to transcoding MCUs, SFMs have extremely low delay and provide features that are typically associated with high-end systems (personalized layout, error localization) without any signal processing at the middlebox. They are also capable of scaling to a large number of concurrent users, and--due to their very low delay--can also be cascaded.
セレクティブフォワーディングミドルボックスは、最近開発されたビデオ会議システムに導入され、スケーラブルビデオコーディングおよび同時放送と組み合わせて活用します。スケーラブルビデオコーディングの例は、H.264のAnnex Gですが、H.264 AVCやVP8を含む他のコーデックも、時間的な次元でのみですが、スケーラビリティを示します。スケーラブルなコーディングとサイマルキャストの両方のケースで、ビデオ信号は2つ以上のビットストリームのセットで表され、対応する数の異なる忠実度ポイントを提供します。ミドルボックスは、スケーラブルなビットストリームのどの部分（または同時配信の場合はどのビットストリーム）を選択して、各受信エンドポイントに転送するかを選択します。意思決定は、利用可能なビットレート、望ましいレイアウトなど、多くの要因によって駆動される場合があります。MCUのトランスコーディングとは異なり、SFMは遅延が非常に低く、ハイエンドシステムに通常関連する機能（パーソナライズされたレイアウト、エラーのローカライズ）を提供します。ミドルボックスでの信号処理なし。また、多数の同時ユーザーへの拡張が可能で、遅延が非常に小さいため、カスケード接続することもできます。
This version of the middlebox also puts different requirements on the endpoint when it comes to decoder instances and handling of the RTP streams providing media. As each projected SSRC can, at any time, provide media, the endpoint either needs to be able to handle as many decoder instances as the middlebox received, or have efficient switching of decoder contexts in a more limited set of actual decoder instances to cope with the switches. The application also gets more responsibility to update how the media provided is to be presented to the user.
ミドルボックスのこのバージョンでは、デコーダーのインスタンスとメディアを提供するRTPストリームの処理に関して、エンドポイントにさまざまな要件を課します。予測される各SSRCはいつでもメディアを提供できるため、エンドポイントはミドルボックスが受信した数と同じ数のデコーダーインスタンスを処理できる必要があるか、実際のデコーダーインスタンスのより限定されたセットでデコーダーコンテキストを効率的に切り替えて対処する必要がありますスイッチ。また、アプリケーションは、提供されたメディアをユーザーに提示する方法を更新する責任も高くなります。
Note that this topology could potentially be seen as a Media Translator that includes an on/off logic as part of its media translation. The topology has the property that all SSRCs present in the session are visible to an endpoint. It also has mixer aspects, as the streams it provides are not basically translated versions, but instead they have conceptual property assigned to them and can be both turned on/off as well as fully or partially delivered. Thus, this topology appears to be some hybrid between the translator and mixer model.
このトポロジは、メディア変換の一部としてオン/オフロジックを含むメディアトランスレータと見なされる可能性があることに注意してください。トポロジーには、セッションに存在するすべてのSSRCがエンドポイントから見えるという特性があります。提供するストリームは基本的に翻訳されたバージョンではないため、ミキサーの側面もありますが、代わりに概念的なプロパティが割り当てられており、オンまたはオフにしたり、完全にまたは部分的に配信したりできます。したがって、このトポロジーは、トランスレーターモデルとミキサーモデルの間のハイブリッドのように見えます。
The differences between a Selective Forwarding Middlebox and a Switching-Media Mixer (Section 3.6.2) are minor, and they share most properties. The above requirement on having a large number of decoding instances or requiring efficient switching of decoder contexts, are one point of difference. The other is how the identification is performed, where the mixer uses CSRC to provide information on what is included in a particular RTP stream that represents a particular concept. Selective forwarding gets the source information through the SSRC and instead uses other mechanisms to indicate the streams intended usage, if needed.
セレクティブフォワーディングミドルボックスとスイッチングメディアミキサー（セクション3.6.2）の違いはわずかで、ほとんどのプロパティを共有しています。多数の復号化インスタンスを持つか、デコーダーコンテキストの効率的な切り替えを必要とする上記の要件は、1つの違いです。もう1つは、識別の実行方法です。ミキサーはCSRCを使用して、特定の概念を表す特定のRTPストリームに何が含まれているかに関する情報を提供します。選択転送は、SSRCを介してソース情報を取得し、代わりに、必要に応じて他のメカニズムを使用してストリームの使用目的を示します。
Shortcut name: Topo-Video-switch-MCU
ショートカット名：Topo-Video-switch-MCU
+---+ +------------+ +---+
| A |------| Multipoint |------| B |
+---+ | Control | +---+
| Unit |
+---+ | (MCU) | +---+
| C |------| |------| D |
+---+ +------------+ +---+
Figure 18: Point to Multipoint Using a Video-Switching MCU
図18：ビデオスイッチングMCUを使用したポイントツーマルチポイント
This PtM topology was popular in early implementations of multipoint videoconferencing systems due to its simplicity, and the corresponding middlebox design has been known as a "video-switching MCU". The more complex RTCP-terminating MCUs, discussed in the next section, became the norm, however, when technology allowed implementations at acceptable costs.
このPtMトポロジは、そのシンプルさのために、マルチポイントビデオ会議システムの初期の実装で人気があり、対応するミドルボックスデザインは「ビデオスイッチングMCU」として知られています。ただし、次のセクションで説明する、より複雑なRTCP終端MCUは、テクノロジが許容可能なコストで実装できるようになったときに標準になりました。
A video-switching MCU forwards to a participant a single media stream, selected from the available streams. The criteria for selection are often based on voice activity in the audio-visual conference, but other conference management mechanisms (like presentation mode or explicit floor control) are known to exist as well.
ビデオスイッチングMCUは、利用可能なストリームから選択された単一のメディアストリームを参加者に転送します。多くの場合、選択基準は視聴覚会議での音声アクティビティに基づいていますが、他の会議管理メカニズム（プレゼンテーションモードや明示的なフロア制御など）も存在することが知られています。
The video-switching MCU may also perform media translation to modify the content in bitrate, encoding, or resolution. However, it still may indicate the original sender of the content through the SSRC. In this case, the values of the CC and CSRC fields are retained.
ビデオスイッチングMCUは、メディア変換を実行して、ビットレート、エンコーディング、または解像度でコンテンツを変更することもできます。ただし、SSRCを介したコンテンツの元の送信者を示す場合があります。この場合、CCおよびCSRCフィールドの値は保持されます。
If not terminating RTP, the RTCP sender reports are forwarded for the currently selected sender. All RTCP receiver reports are freely forwarded between the endpoints. In addition, the MCU may also originate RTCP control traffic in order to control the session and/or report on status from its viewpoint.
RTPを終了しない場合、RTCP送信者レポートは、現在選択されている送信者に転送されます。すべてのRTCP受信者レポートは、エンドポイント間で自由に転送されます。さらに、MCUはRTCP制御トラフィックを発信して、セッションを制御したり、その視点からステータスを報告したりすることもできます。
The video-switching MCU has most of the attributes of a translator. However, its stream selection is a mixing behavior. This behavior has some RTP and RTCP issues associated with it. The suppression of all but one RTP stream results in most participants seeing only a subset of the sent RTP streams at any given time, often a single RTP stream per conference. Therefore, RTCP receiver reports only report on these RTP streams. Consequently, the endpoints emitting RTP streams that are not currently forwarded receive a view of the session that indicates their RTP streams disappear somewhere en route. This makes the use of RTCP for congestion control, or any type of quality reporting, very problematic.
ビデオスイッチングMCUには、トランスレータのほとんどの属性があります。ただし、そのストリーム選択はミキシング動作です。この動作には、それに関連するRTPおよびRTCPの問題がいくつかあります。 1つを除くすべてのRTPストリームを抑制すると、ほとんどの参加者は常に、送信されたRTPストリームのサブセットのみを確認し、多くの場合、会議ごとに1つのRTPストリームを確認します。したがって、RTCPレシーバレポートは、これらのRTPストリームに関するレポートのみを報告します。その結果、現在転送されていないRTPストリームを発信しているエンドポイントは、RTPストリームが途中で消えたことを示すセッションのビューを受け取ります。これにより、輻輳制御またはあらゆるタイプの品質レポートにRTCPを使用することが非常に問題になります。
To avoid the aforementioned issues, the MCU needs to implement two features. First, it needs to act as a mixer (see Section 3.6) and forward the selected RTP stream under its own SSRC and with the appropriate CSRC values. Second, the MCU needs to modify the RTCP RRs it forwards between the domains. As a result, it is recommended that one implement a centralized video-switching conference using a mixer according to RFC 3550, instead of the shortcut implementation described here.
前述の問題を回避するには、MCUに2つの機能を実装する必要があります。まず、ミキサーとして機能し（セクション3.6を参照）、選択したRTPストリームを独自のSSRCの下で適切なCSRC値と共に転送する必要があります。次に、MCUはドメイン間で転送するRTCP RRを変更する必要があります。そのため、ここで説明するショートカット実装ではなく、RFC 3550に準拠したミキサーを使用して、集中型ビデオスイッチング会議を実装することをお勧めします。
Shortcut name: Topo-RTCP-terminating-MCU
ショートカット名：Topo-RTCP-terminating-MCU
+---+ +------------+ +---+
| A |<---->| Multipoint |<---->| B |
+---+ | Control | +---+
| Unit |
+---+ | (MCU) | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
Figure 19: Point to Multipoint Using Content Modifying MCUs
図19：コンテンツ変更MCUを使用したポイントツーマルチポイント
In this PtM scenario, each endpoint runs an RTP point-to-point session between itself and the MCU. This is a very commonly deployed topology in multipoint video conferencing. The content that the MCU provides to each participant is either:
このPtMシナリオでは、各エンドポイントはそれ自体とMCUの間でRTPポイントツーポイントセッションを実行します。これは、マルチポイントビデオ会議で非常に一般的に導入されているトポロジです。 MCUが各参加者に提供するコンテンツは次のいずれかです。
a. a selection of the content received from the other endpoints or
a. 他のエンドポイントから受信したコンテンツの選択、または
b. the mixed aggregate of what the MCU receives from the other PtP paths, which are part of the same Communication Session.
b. MCUが同じ通信セッションの一部である他のPtPパスから受信するものの混合集約。
In case (a), the MCU may modify the content in terms of bitrate, encoding format, or resolution. No explicit RTP mechanism is used to establish the relationship between the original RTP stream of the media being sent and the RTP stream the MCU sends. In other words, the outgoing RTP streams typically use a different SSRC, and may well use a different payload type (PT), even if this different PT happens to be mapped to the same media type. This is a result of the individually negotiated RTP session for each endpoint.
ケース（a）の場合、MCUはビットレート、エンコード形式、または解像度の観点からコンテンツを変更できます。送信されるメディアの元のRTPストリームとMCUが送信するRTPストリームとの関係を確立するために、明示的なRTPメカニズムは使用されません。つまり、発信RTPストリームは通常、別のSSRCを使用し、この異なるPTが偶然同じメディアタイプにマッピングされている場合でも、別のペイロードタイプ（PT）を使用する可能性があります。これは、各エンドポイントに対して個別にネゴシエートされたRTPセッションの結果です。
In case (b), the MCU is the Media Source and generates the Source RTP Stream as it mixes the received content and then encodes and packetizes it for transmission to an endpoint. According to RTP
ケース（b）の場合、MCUはメディアソースであり、受信したコンテンツを混合し、エンドポイントに送信するためにエンコードおよびパケット化するときにソースRTPストリームを生成します。 RTPによると
[RFC3550], the SSRC of the contributors are to be signaled using the CSRC/CC mechanism. In practice, today, most deployed MCUs do not implement this feature. Instead, the identification of the endpoints whose content is included in the mixer's output is not indicated through any explicit RTP mechanism. That is, most deployed MCUs set the CC field in the RTP header to zero, thereby indicating no available CSRC information, even if they could identify the original sending endpoints as suggested in RTP.
[RFC3550]、貢献者のSSRCはCSRC / CCメカニズムを使用して通知されます。実際には、今日配備されているほとんどのMCUはこの機能を実装していません。代わりに、コンテンツがミキサーの出力に含まれているエンドポイントの識別は、明示的なRTPメカニズムによって示されません。つまり、展開されたほとんどのMCUは、RTPヘッダーのCCフィールドをゼロに設定し、RTPで提案された元の送信エンドポイントを識別できたとしても、利用可能なCSRC情報がないことを示します。
The main feature that sets this topology apart from what RFC 3550 describes is the breaking of the common RTP session across the centralized device, such as the MCU. This results in the loss of explicit RTP-level indication of all participants. If one were using the mechanisms available in RTP and RTCP to signal this explicitly, the topology would follow the approach of an RTP mixer. The lack of explicit indication has at least the following potential problems:
RFC 3550で説明されているものとは別にこのトポロジを設定する主な機能は、MCUなどの集中型デバイス全体で共通のRTPセッションを切断することです。これにより、すべての参加者の明示的なRTPレベルの表示が失われます。 RTPおよびRTCPで利用可能なメカニズムを使用してこれを明示的に通知する場合、トポロジはRTPミキサーのアプローチに従います。明示的な表示がないことには、少なくとも以下の潜在的な問題があります。
1. Loop detection cannot be performed on the RTP level. When carelessly connecting two misconfigured MCUs, a loop could be generated.
1. ループ検出は、RTPレベルでは実行できません。誤って構成された2つのMCUを不注意に接続すると、ループが生成される可能性があります。
2. There is no information about active media senders available in the RTP packet. As this information is missing, receivers cannot use it. It also deprives the client of information related to currently active senders in a machine-usable way, thus preventing clients from indicating currently active speakers in user interfaces, etc.
2. RTPパケットで使用可能なアクティブなメディアセンダーに関する情報はありません。この情報がないため、受信者はそれを使用できません。また、マシンで使用可能な方法で現在アクティブな送信者に関連する情報をクライアントから奪うため、クライアントがユーザーインターフェイスなどで現在アクティブなスピーカーを示すのを防ぐことができます。
Note that many/most deployed MCUs (and video conferencing endpoints) rely on signaling-layer mechanisms for the identification of the Contributing Sources, for example, a SIP conferencing package [RFC4575]. This alleviates, to some extent, the aforementioned issues resulting from ignoring RTP's CSRC mechanism.
多くの、または最も多く配備されているMCU（およびビデオ会議エンドポイント）は、SIP会議パッケージ[RFC4575]などの発信元の識別をシグナリング層メカニズムに依存していることに注意してください。これにより、RTPのCSRCメカニズムを無視することに起因する前述の問題がある程度緩和されます。
Shortcut name: Topo-Split-Terminal
ショートカット名：Topo-Split-Terminal
In some applications, for example, in some telepresence systems, terminals may not be integrated into a single functional unit but composed of more than one subunits. For example, a telepresence room terminal employing multiple cameras and monitors may consist of multiple video conferencing subunits, each capable of handling a single camera and monitor. Another example would be a video conferencing terminal in which audio is handled by one subunit, and video by another. Each of these subunits uses its own physical network interface (for example: Ethernet jack) and network address.
一部のアプリケーションでは、たとえば、一部のテレプレゼンスシステムでは、端末は単一の機能ユニットに統合されておらず、複数のサブユニットで構成されている場合があります。たとえば、複数のカメラとモニターを使用するテレプレゼンスルーム端末は、それぞれが単一のカメラとモニターを処理できる複数のビデオ会議サブユニットで構成できます。別の例は、オーディオが1つのサブユニットによって処理され、ビデオが別のサブユニットによって処理されるビデオ会議端末です。これらの各サブユニットは、独自の物理ネットワークインターフェイス（イーサネットジャックなど）とネットワークアドレスを使用します。
The various (media processing) subunits need (logically and physically) to be interconnected by control functionality, but their media plane functionality may be split. These types of terminals are referred to as split component terminals. Historically, the earliest split component terminals were perhaps the independent audio and video conference software tools used over the MBONE in the late 1990s.
さまざまな（メディア処理）サブユニットが（論理的および物理的に）制御機能によって相互接続される必要がありますが、それらのメディアプレーン機能は分割される場合があります。これらのタイプの端子は、分割コンポーネント端子と呼ばれます。歴史的に見て、最も初期の分割コンポーネント端末は、おそらく1990年代後半にMBONEで使用された独立したオーディオおよびビデオ会議ソフトウェアツールでした。
An example for such a split component terminal is depicted in Figure 20. Within split component terminal A, at least audio and video subunits are addressed by their own network addresses. In some of these systems, the control stack subunit may also have its own network address.
そのような分割コンポーネント端末の例を図20に示します。分割コンポーネント端末A内では、少なくともオーディオサブユニットとビデオサブユニットは、独自のネットワークアドレスでアドレス指定されます。これらのシステムの一部では、制御スタックサブユニットも独自のネットワークアドレスを持っている場合があります。
From an RTP viewpoint, each of the subunits terminates RTP and acts as an endpoint in the sense that each subunit includes its own, independent RTP stack. However, as the subunits are semantically part of the same terminal, it is appropriate that this semantic relationship is expressed in RTCP protocol elements, namely in the CNAME.
RTPの観点から見ると、各サブユニットはRTPを終端し、各サブユニットが独自の独立したRTPスタックを含むという意味でエンドポイントとして機能します。ただし、サブユニットは意味的に同じ端末の一部であるため、この意味上の関係をRTCPプロトコル要素、つまりCNAMEで表すことが適切です。
+---------------------+
| Endpoint A |
| Local Area Network |
| +------------+ |
| +->| Audio |<+-RTP---\
| | +------------+ | \ +------+
| | +------------+ | +-->| |
| +->| Video |<+-RTP-------->| B |
| | +------------+ | +-->| |
| | +------------+ | / +------+
| +->| Control |<+-SIP---/
| +------------+ |
+---------------------+
Figure 20: Split Component Terminal
図20：分割コンポーネント端子
It is further sensible that the subunits share a common clock from which RTP and RTCP clocks are derived, to facilitate synchronization and avoid clock drift.
同期を容易にし、クロックのドリフトを回避するために、サブユニットがRTPおよびRTCPクロックの派生元である共通のクロックを共有することはさらに賢明です。
To indicate that audio and video Source Streams generated by different subunits share a common clock, and can be synchronized, the RTP streams generated from those Source Streams need to include the same CNAME in their RTCP SDES packets. The use of a common CNAME for RTP flows carried in different transport-layer flows is entirely normal for RTP and RTCP senders, and fully compliant RTP endpoints, middleboxes, and other tools should have no problem with this.
異なるサブユニットによって生成されたオーディオとビデオのソースストリームが共通のクロックを共有し、同期できることを示すために、それらのソースストリームから生成されたRTPストリームは、RTCP SDESパケットに同じCNAMEを含める必要があります。さまざまなトランスポート層フローで運ばれるRTPフローに共通のCNAMEを使用することは、RTPおよびRTCP送信者にとって完全に正常であり、完全に準拠したRTPエンドポイント、ミドルボックス、およびその他のツールはこれで問題ありません。
However, outside of the split component terminal scenario (and perhaps a multihomed endpoint scenario, which is not further discussed herein), the use of a common CNAME in RTP streams sent from separate endpoints (as opposed to a common CNAME for RTP streams sent on different transport-layer flows between two endpoints) is rare. It has been reported that at least some third-party tools like some network monitors do not handle gracefully endpoints that use a common CNAME across multiple transport-layer flows: they report an error condition in which two separate endpoints are using the same CNAME. Depending on the sophistication of the support staff, such erroneous reports can lead to support issues.
ただし、分割コンポーネント端末シナリオ（およびおそらくマルチホームエンドポイントシナリオ、ここでは詳しく説明しません）の外では、個別のエンドポイントから送信されるRTPストリームでの共通CNAMEの使用（送信されるRTPストリームの共通CNAMEとは対照的） 2つのエンドポイント間で異なるトランスポート層フロー）はまれです。一部のネットワークモニターなどの少なくとも一部のサードパーティツールは、複数のトランスポートレイヤーフローで共通のCNAMEを使用する正常なエンドポイントを処理しないことが報告されています。これらのツールは、2つの別々のエンドポイントが同じCNAMEを使用しているというエラー状態を報告します。サポートスタッフの洗練度によっては、このような誤ったレポートがサポートの問題につながる可能性があります。
The aforementioned support issue can sometimes be avoided if each of the subunits of a split component terminal is configured to use a different CNAME, with the synchronization between the RTP streams being indicated by some non-RTP signaling channel rather than using a common CNAME sent in RTCP. This complicates the signaling, especially in cases where there are multiple SSRCs in use with complex synchronization requirements, as is the same in many current telepresence systems. Unless one uses RTCP terminating topologies such as Topo-RTCP-terminating-MCU, sessions involving more than one video subunit with a common CNAME are close to unavoidable.
分割コンポーネント端末の各サブユニットが異なるCNAMEを使用するように構成されており、RTPストリーム間の同期が、送信された共通のCNAMEを使用するのではなく、RTP以外のシグナリングチャネルによって示されている場合、前述のサポートの問題を回避できることがあります。 RTCP。これはシグナリングを複雑にします。特に、現在の多くのテレプレゼンスシステムと同じように、複数のSSRCが複雑な同期要件で使用されている場合はそうです。 Topo-RTCP-terminating-MCUなどのRTCP終端トポロジを使用しない限り、共通のCNAMEを持つ複数のビデオサブユニットが関与するセッションは避けられません。
The different RTP streams comprising a split terminal system can form a single RTP session or they can form multiple RTP sessions, depending on the visibility of their SSRC values in RTCP reports. If the receiver of the RTP streams sent by the split terminal sends reports relating to all of the RTP flows (i.e., to each SSRC) in each RTCP report, then a single RTP session is formed. Alternatively, if the receiver of the RTP streams sent by the split terminal does not send cross-reports in RTCP, then the audio and video form separate RTP sessions.
分割端末システムを構成するさまざまなRTPストリームは、RTCPレポートでのSSRC値の可視性に応じて、単一のRTPセッションを形成することも、複数のRTPセッションを形成することもできます。分割端末によって送信されたRTPストリームの受信者が、各RTCPレポート内のすべてのRTPフロー（つまり、各SSRC）に関連するレポートを送信すると、単一のRTPセッションが形成されます。あるいは、分割端末によって送信されたRTPストリームの受信者がRTCPでクロスレポートを送信しない場合、オーディオとビデオは別々のRTPセッションを形成します。
For example, in Figure 20, B will send RTCP reports to each of the subunits of A. If the RTCP packets that B sends to the audio subunit of A include reports on the reception quality of the video as well as the audio, and similarly if the RTCP packets that B sends to the video subunit of A include reports on the reception quality of the audio as well as video, then a single RTP session is formed. However, if the RTCP packets B sends to the audio subunit of A only report on the received audio, and the RTCP packets B sends to the video subunit of A only report on the received video, then there are two separate RTP sessions.
たとえば、図20では、BはRTCPレポートをAの各サブユニットに送信します。BがAのオーディオサブユニットに送信するRTCPパケットに、ビデオとオーディオの受信品質に関するレポートが含まれている場合、同様にBがAのビデオサブユニットに送信するRTCPパケットに、オーディオとビデオの受信品質に関するレポートが含まれている場合、単一のRTPセッションが形成されます。ただし、RTCPパケットBがAのオーディオサブユニットに送信するのは受信したオーディオに関するレポートのみであり、RTCPパケットBがAのビデオサブユニットに送信するのは受信したビデオに関するレポートのみである場合、2つの別々のRTPセッションがあります。
Forming a single RTP session across the RTP streams sent by the different subunits of a split terminal gives each subunit visibility into reception quality of RTP streams sent by the other subunits.
分割端末のさまざまなサブユニットから送信されたRTPストリーム全体で単一のRTPセッションを形成すると、各サブユニットは、他のサブユニットから送信されたRTPストリームの受信品質を確認できます。
This information can help diagnose reception quality problems, but at the cost of increased RTCP bandwidth use.
この情報は、受信品質の問題を診断するのに役立ちますが、RTCP帯域幅の使用量が増加します。
RTP streams sent by the subunits of a split terminal need to use the same CNAME in their RTCP packets if they are to be synchronized, irrespective of whether a single RTP session is formed or not.
分割端末のサブユニットによって送信されたRTPストリームは、単一のRTPセッションが形成されているかどうかに関係なく、それらを同期する場合、RTCPパケットで同じCNAMEを使用する必要があります。
Shortcut name: Topo-Asymmetric
ショートカット名：非対称トポ
It is theoretically possible to construct an MCU that is a mixer in one direction and a translator in another. The main reason to consider this would be to allow topologies similar to Figure 13, where the mixer does not need to mix in the direction from B or D towards the multicast domains with A and C. Instead, the RTP streams from B and D are forwarded without changes. Avoiding this mixing would save media processing resources that perform the mixing in cases where it isn't needed. However, there would still be a need to mix B's media towards D. Only in the direction B -> multicast domain or D -> multicast domain would it be possible to work as a translator. In all other directions, it would function as a mixer.
理論的には、一方向ではミキサーであり、別方向ではトランスレータであるMCUを構築できます。これを検討する主な理由は、図13と同様のトポロジを許可することです。この場合、ミキサーはBまたはDからAおよびCのマルチキャストドメインに向かう方向で混合する必要はありません。代わりに、BおよびDからのRTPストリームは変更せずに転送されます。このミキシングを回避すると、ミキシングが不要な場合にミキシングを実行するメディア処理リソースを節約できます。ただし、BのメディアをDに向けて混合する必要があります。B->マルチキャストドメインまたはD->マルチキャストドメインの方向でのみ、トランスレータとして機能することができます。他のすべての方向では、ミキサーとして機能します。
The mixer/translator would still need to process and change the RTCP before forwarding it in the directions of B or D to the multicast domain. One issue is that A and C do not know about the mixed-media stream the mixer sends to either B or D. Therefore, any reports related to these streams must be removed. Also, receiver reports related to A's and C's RTP streams would be missing. To avoid A and C thinking that B and D aren't receiving A and C at all, the mixer needs to insert locally generated reports reflecting the situation for the streams from A and C into B's and D's sender reports. In the opposite direction, the receiver reports from A and C about B's and D's streams also need to be aggregated into the mixer's receiver reports sent to B and D. Since B and D only have the mixer as source for the stream, all RTCP from A and C must be suppressed by the mixer.
ミキサー/トランスレーターは、RTCPをBまたはDの方向にマルチキャストドメインに転送する前に、RTCPを処理して変更する必要があります。 1つの問題は、AとCがミキサーがBまたはDに送信する混合メディアストリームを認識しないことです。したがって、これらのストリームに関連するレポートは削除する必要があります。また、AおよびCのRTPストリームに関連するレシーバーレポートが欠落します。 BとDがAとCをまったく受信していないとAとCが考えるのを避けるために、ミキサーはAとCからのストリームの状況を反映するローカルで生成されたレポートをBとDの送信者レポートに挿入する必要があります。反対方向では、BとDのストリームに関するAとCからのレシーバーレポートも、BとDに送信されるミキサーのレシーバーレポートに集約する必要があります。BとDは、ストリームのソースとしてミキサーのみを持っているため、すべてのRTCPからAとCはミキサーによって抑制されなければなりません。
This topology is so problematic, and it is so easy to get the RTCP processing wrong, that it is not recommended for implementation.
このトポロジは非常に問題が多く、RTCP処理が誤って起こりやすいため、実装にはお勧めできません。
Topologies can be combined and linked to each other using mixers or translators. However, care must be taken in handling the SSRC/CSRC space. A mixer does not forward RTCP from sources in other domains, but instead generates its own RTCP packets for each domain it mixes into, including the necessary SDES information for both the CSRCs and the SSRCs. Thus, in a mixed domain, the only SSRCs seen will be the ones present in the domain, while there can be CSRCs from all the domains connected together with a combination of mixers and translators. The combined SSRC and CSRC space is common over any translator or mixer. It is important to facilitate loop detection, something that is likely to be even more important in combined topologies due to the mixed behavior between the domains. Any hybrid, like the Topo-Video-switch-MCU or Topo-Asymmetric, requires considerable thought on how RTCP is dealt with.
トポロジーは、ミキサーまたはトランスレーターを使用して結合および相互にリンクできます。ただし、SSRC / CSRCスペースの取り扱いには注意が必要です。ミキサーは、他のドメインのソースからRTCPを転送するのではなく、CSRCとSSRCの両方に必要なSDES情報を含め、ミキシングするドメインごとに独自のRTCPパケットを生成します。したがって、混合ドメインでは、ドメインに存在するSSRCのみが表示されますが、ミキサーとトランスレーターの組み合わせで接続されたすべてのドメインのCSRCが存在する可能性があります。 SSRCとCSRCを組み合わせたスペースは、どのトランスレーターやミキサーでも一般的です。ループ検出を促進することは重要です。これは、ドメイン間の動作が混在しているため、組み合わせトポロジではさらに重要になる可能性があります。 Topo-Video-switch-MCUやTopo-Asymmetricなどのハイブリッドでは、RTCPの処理方法について十分な検討が必要です。
The topologies discussed in Section 3 have different properties. This section describes these properties. Note that, even if a certain property is supported within a particular topology concept, the necessary functionality may be optional to implement.
セクション3で説明するトポロジには、さまざまな特性があります。このセクションでは、これらのプロパティについて説明します。特定のプロパティが特定のトポロジコンセプト内でサポートされている場合でも、必要な機能を実装するかどうかは任意であることに注意してください。
To recapitulate, multicast, and in particular ASM, provides the functionality that everyone may send to, or receive from, everyone else within the session. SSM can provide a similar functionality by having anyone intending to participate as a sender to send its media to the SSM Distribution Source. The SSM Distribution Source forwards the media to all receivers subscribed to the multicast group. Mesh, MCUs, mixers, Selective Forwarding Middleboxes (SFMs), and translators may all provide that functionality at least on some basic level. However, there are some differences in which type of reachability they provide.
要約、マルチキャスト、特にASMは、セッション内の他の全員に送信または受信できる機能を提供します。 SSMは、メディアをSSM配布ソースに送信するために送信者として参加することを意図している人を誰でも持つことにより、同様の機能を提供できます。 SSM配布ソースは、マルチキャストグループに登録されているすべての受信者にメディアを転送します。メッシュ、MCU、ミキサー、選択的転送ミドルボックス（SFM）、およびトランスレーターはすべて、少なくともいくつかの基本的なレベルでその機能を提供します。ただし、提供する到達可能性のタイプにはいくつかの違いがあります。
The topologies that come closest to emulating Any-Source IP Multicast, with all-to-all transmission capabilities, are the Transport Translator function called "relay" in Section 3.5, as well as the Mesh with joint RTP sessions (Section 3.4). Media Translators, Mesh with independent RTP Sessions, mixers, SFUs, and the MCU variants do not provide a fully meshed forwarding on the transport level; instead, they only allow limited forwarding of content from the other session participants.
エニーソースIPマルチキャストのエミュレーションに最も近いトポロジーは、All-to-All送信機能を備え、セクション3.5で「リレー」と呼ばれるトランスポートトランスレーター機能と、ジョイントRTPセッションを使用したメッシュ（セクション3.4）です。メディアトランスレータ、独立したRTPセッションを備えたメッシュ、ミキサー、SFU、およびMCUバリアントは、トランスポートレベルで完全にメッシュ化された転送を提供しません。代わりに、他のセッション参加者からのコンテンツの制限付き転送のみを許可します。
The "all-to-all media transmission" requires that any media transmitting endpoint considers the path to the least-capable receiving endpoint. Otherwise, the media transmissions may overload that path. Therefore, a sending endpoint needs to monitor the path from itself to any of the receiving endpoints, to detect the currently least-capable receiver and adapt its sending rate accordingly. As multiple endpoints may send simultaneously, the available resources may vary. RTCP's receiver reports help perform this monitoring, at least on a medium time scale.
「すべてからすべてへのメディア送信」では、すべてのメディア送信エンドポイントが、最小能力の受信エンドポイントへのパスを考慮する必要があります。そうしないと、メディア送信がそのパスに過負荷をかける可能性があります。したがって、送信側エンドポイントは、自身から受信側エンドポイントへのパスを監視して、現在最も能力の低い受信機を検出し、それに応じて送信レートを調整する必要があります。複数のエンドポイントが同時に送信する可能性があるため、使用可能なリソースは異なる場合があります。 RTCPの受信者レポートは、少なくとも中程度の時間スケールでこの監視を実行するのに役立ちます。
The resource consumption for performing all-to-all transmission varies depending on the topology. Both ASM and SSM have the benefit that only one copy of each packet traverses a particular link. Using a relay causes the transmission of one copy of a packet per endpoint-to-relay path and packet transmitted. However, in most cases, the links carrying the multiple copies will be the ones close to the relay (which can be assumed to be part of the network infrastructure with good connectivity to the backbone) rather than the endpoints (which may be behind slower access links). The Mesh topologies causes N-1 streams of transmitted packets to traverse the first-hop link from the endpoint, in a mesh with N endpoints. How long the different paths are common is highly situation dependent.
全対全送信を実行するためのリソース消費は、トポロジーによって異なります。 ASMとSSMの両方に、各パケットの1つのコピーだけが特定のリンクを通過するという利点があります。リレーを使用すると、エンドポイントからリレーへのパスごとにパケットのコピーが1つ送信され、パケットが送信されます。ただし、ほとんどの場合、複数のコピーを運ぶリンクは、エンドポイント（低速アクセスの背後にある可能性がある）ではなく、リレー（バックボーンへの接続が良好なネットワークインフラストラクチャの一部であると見なすことができる）に近いリンクになります。リンク）。メッシュトポロジでは、N-1のエンドポイントを持つメッシュで、送信されたパケットのN-1ストリームがエンドポイントから最初のホップのリンクを通過します。さまざまなパスが共通する期間は状況に大きく依存します。
The transmission of RTCP by design adapts to any changes in the number of participants due to the transmission algorithm, defined in the RTP specification [RFC3550], and the extensions in AVPF [RFC4585] (when applicable). That way, the resources utilized for RTCP stay within the bounds configured for the session.
設計によるRTCPの送信は、RTP仕様[RFC3550]で定義されている送信アルゴリズム、およびAVPFの拡張[RFC4585]（該当する場合）による参加者数の変化に適応します。このようにして、RTCPに使用されるリソースは、セッション用に構成された境界内にとどまります。
All translators, mixers, RTCP-terminating MCUs, and Mesh with individual RTP sessions allow changing the media encoding or the transport to other properties of the other domain, thereby providing extended interoperability in cases where the endpoints lack a common set of media codecs and/or transport protocols. Selective Forwarding Middleboxes can adopt the transport and (at least) selectively forward the encoded streams that match a receiving endpoint's capability. It requires an additional translator to change the media encoding if the encoded streams do not match the receiving endpoint's capabilities.
すべてのトランスレータ、ミキサー、RTCP終了MCU、および個別のRTPセッションを備えたメッシュにより、メディアエンコーディングまたはトランスポートを他のドメインの他のプロパティに変更できるため、エンドポイントに共通のメディアコーデックセットがない場合に相互運用性が拡張されます。またはトランスポートプロトコル。選択転送ミドルボックスは、トランスポートを採用し、受信エンドポイントの機能に一致するエンコードされたストリームを（少なくとも）選択的に転送できます。エンコードされたストリームが受信エンドポイントの機能と一致しない場合、メディアエンコーディングを変更するために追加のトランスレータが必要です。
Endpoints are often connected to each other with a heterogeneous set of paths. This makes congestion control in a Point-to-Multipoint set problematic. In the ASM, SSM, Mesh with common RTP session, and Transport Relay scenarios, each individual sending endpoint has to adapt to the receiving endpoint behind the least-capable path, yielding suboptimal quality for the endpoints behind the more capable paths. This is no longer an issue when Media Translators, mixers, SFMs, or MCUs are involved, as each endpoint only needs to adapt to the slowest path within its own domain. The translator, mixer, SFM, or MCU topologies all require their respective outgoing RTP streams to adjust the bitrate, packet rate, etc., to adapt to the least-capable path in each of the other domains. That way one can avoid lowering the quality to the least-capable endpoint in all the domains at the cost (complexity, delay, equipment) of the mixer, SFM, or translator, and potentially the media sender (multicast/layered encoding and sending the different representations).
エンドポイントは、多くの場合、異種のパスのセットで相互に接続されています。これにより、ポイントツーマルチポイントセットの輻輳制御が問題になります。 ASM、SSM、一般的なRTPセッションを使用するメッシュ、およびトランスポートリレーのシナリオでは、個々の送信エンドポイントは、最小能力のパスの背後にある受信エンドポイントに適応する必要があり、より有能なパスの背後にあるエンドポイントの品質が最適ではなくなります。メディアトランスレータ、ミキサー、SFM、またはMCUが関係する場合、これは問題ではなくなりました。各エンドポイントは、自身のドメイン内の最も遅いパスにのみ適応する必要があるためです。トランスレータ、ミキサー、SFM、またはMCUトポロジはすべて、ビットレート、パケットレートなどを調整して、他の各ドメインの最小能力のパスに適応するために、それぞれの発信RTPストリームを必要とします。こうすることで、ミキサー、SFM、またはトランスレーターのコスト（複雑さ、遅延、機器）、および場合によってはメディアセンダー（マルチキャスト/レイヤードエンコーディングおよび送信）を犠牲にして、すべてのドメインで最小能力のエンドポイントまで品質を低下させることを回避できます異なる表現）。
In the all-to-all media property mentioned above and provided by ASM, SSM, Mesh with common RTP session, and relay, all simultaneous media transmissions share the available bitrate. For endpoints with limited reception capabilities, this may result in a situation where even a minimal, acceptable media quality cannot be accomplished, because multiple RTP streams need to share the same resources. One solution to this problem is to use a mixer, or MCU, to aggregate the multiple RTP streams into a single one, where the single RTP stream takes up less resources in terms of bitrate. This aggregation can be performed according to different methods. Mixing or selection are two common methods. Selection is almost always possible and easy to implement. Mixing requires resources in the mixer and may be relatively easy and not impair the quality too badly (audio) or quite difficult (video tiling, which is not only computationally complex but also reduces the pixel count per stream, with corresponding loss in perceptual quality).
上記のASM、SSM、共通のRTPセッションを備えたメッシュ、およびリレーによって提供されるall-to-allメディアプロパティでは、すべての同時メディア送信が利用可能なビットレートを共有します。受信機能が制限されたエンドポイントの場合、複数のRTPストリームが同じリソースを共有する必要があるため、許容できる最低限のメディア品質でも達成できない状況が発生する可能性があります。この問題の1つの解決策は、ミキサーまたはMCUを使用して、複数のRTPストリームを単一のRTPストリームに集約することです。この場合、単一のRTPストリームがビットレートの観点で使用するリソースが少なくなります。この集約は、さまざまな方法で実行できます。混合または選択は、2つの一般的な方法です。ほとんどの場合、選択は可能であり、実装は簡単です。ミキシングにはミキサー内のリソースが必要であり、比較的簡単で品質が悪くない（オーディオ）または非常に難しい（ビデオタイリングは、計算が複雑になるだけでなく、ストリームごとのピクセル数が減少し、それに対応する知覚品質が低下する） 。
The RTP protocol includes functionality to identify the session participants through the use of the SSRC and CSRC fields. In addition, it is capable of carrying some further identity information about these participants using the RTCP SDES. In topologies that provide a full all-to-all functionality, i.e., ASM, Mesh with common RTP session, and relay, a compliant RTP implementation offers the functionality directly as specified in RTP. In topologies that do not offer all-to-all communication, it is necessary that RTCP is handled correctly in domain bridging functions. RTP includes explicit specification text for translators and mixers, and for SFMs the required functionality can be derived from that text. However, the MCU described in Section 3.8 cannot offer the full functionality for session participant identification through RTP means. The topologies that create independent RTP sessions per endpoint or pair of endpoints, like a Back-to-Back RTP session, MESH with independent RTP sessions, and the RTCP terminating MCU (Section 3.9), with an exception of SFM, do not support RTP-based identification of session participants. In all those cases, other non-RTP-based mechanisms need to be implemented if such knowledge is required or desirable. When it comes to SFM, the SSRC namespace is not necessarily joint. Instead, identification will require knowledge of SSRC/CSRC mappings that the SFM performed; see Section 3.7.
RTPプロトコルには、SSRCおよびCSRCフィールドを使用してセッション参加者を識別する機能が含まれています。さらに、RTCP SDESを使用して、これらの参加者に関する追加のID情報を伝送できます。 ASM、共通のRTPセッションを使用したメッシュ、およびリレーなど、完全なオールツーオール機能を提供するトポロジでは、準拠したRTP実装により、RTPで指定された機能が直接提供されます。オールツーオール通信を提供しないトポロジでは、ドメインブリッジング機能でRTCPが正しく処理される必要があります。 RTPには、トランスレータとミキサーの明示的な仕様テキストが含まれており、SFMの場合、必要な機能はそのテキストから派生できます。ただし、セクション3.8で説明されているMCUは、RTP手段によるセッション参加者識別のための完全な機能を提供できません。エンドツーエンドまたはエンドポイントのペアごとに独立したRTPセッションを作成するトポロジ（バックツーバックRTPセッション、独立したRTPセッションを備えたMESH、SFMを除くRTCP終端MCU（セクション3.9）など）は、RTPをサポートしませんベースのセッション参加者の識別。これらすべてのケースで、そのような知識が必要または望ましい場合は、RTPベースではない他のメカニズムを実装する必要があります。 SFMに関しては、SSRC名前空間は必ずしも結合している必要はありません。代わりに、識別には、SFMが実行したSSRC / CSRCマッピングの知識が必要です。セクション3.7を参照してください。
In complex topologies with multiple interconnected domains, it is possible to unintentionally form media loops. RTP and RTCP support detecting such loops, as long as the SSRC and CSRC identities are maintained and correctly set in forwarded packets. Loop detection will work in ASM, SSM, Mesh with joint RTP session, and relay. It is likely that loop detection works for the video-switching MCU, Section 3.8, at least as long as it forwards the RTCP between the endpoints. However, the Back-to-Back RTP sessions, Mesh with independent RTP sessions, and SFMs will definitely break the loop detection mechanism.
複数の相互接続されたドメインを持つ複雑なトポロジでは、意図せずにメディアループが形成される可能性があります。 RTPおよびRTCPは、SSRCおよびCSRC IDが維持され、転送されたパケットに正しく設定されている限り、このようなループの検出をサポートします。ループ検出は、ASM、SSM、ジョイントRTPセッションを備えたメッシュ、およびリレーで機能します。ループ検出は、少なくともエンドポイント間でRTCPを転送する限り、ビデオスイッチングMCU、セクション3.8で機能する可能性があります。ただし、バックツーバックRTPセッション、独立したRTPセッションを備えたメッシュ、およびSFMは、ループ検出メカニズムを確実に破壊します。
Some RTP header extensions have relevance not only end to end but also hop to hop, meaning at least some of the middleboxes in the path are aware of their potential presence through signaling, intercept and interpret such header extensions, and potentially also rewrite or generate them. Modern header extensions generally follow "A General Mechanism for RTP Header Extensions" [RFC5285], which allows for all of the above. Examples for such header extensions include the Media ID (MID) in [SDP-BUNDLE]. At the time of writing, there was also a proposal for how to include some SDES into an RTP header extension [RTCP-SDES].
一部のRTPヘッダー拡張は、エンドツーエンドだけでなくホップツーホップにも関連性があります。つまり、パス内のミドルボックスの少なくとも一部は、そのようなヘッダー拡張のシグナリング、インターセプト、解釈を通じて潜在的な存在を認識しており、それらを書き換えたり生成したりする可能性もあります。最近のヘッダー拡張は一般に、「RTPヘッダー拡張の一般的なメカニズム」[RFC5285]に準拠しており、上記のすべてを可能にします。このようなヘッダー拡張の例には、[SDP-BUNDLE]のメディアID（MID）が含まれます。執筆時点では、RTPヘッダー拡張[RTCP-SDES]にSDESを含める方法についての提案もありました。
When such header extensions are in use, any middlebox that understands it must ensure consistency between the extensions it sees and/or generates and the RTCP it receives and generates. For example, the MID of the bundle is sent in an RTP header extension and also in an RTCP SDES message. This apparent redundancy was introduced as unaware middleboxes may choose to discard RTP header extensions. Obviously, inconsistency between the MID sent in the RTP header extension and in the RTCP SDES message could lead to undesirable results, and, therefore, consistency is needed. Middleboxes unaware of the nature of a header extension, as specified in [RFC5285], are free to forward or discard header extensions.
このようなヘッダー拡張が使用されている場合、それを理解するミドルボックスは、それが認識および/または生成する拡張と、それが受信および生成するRTCPとの間の一貫性を確保する必要があります。たとえば、バンドルのMIDは、RTPヘッダー拡張とRTCP SDESメッセージで送信されます。この明らかな冗長性は、ミドルボックスがRTPヘッダー拡張を破棄することを選択する可能性があるために導入されました。明らかに、RTPヘッダー拡張で送信されたMIDとRTCP SDESメッセージで送信されたMIDとの間に不整合があると、望ましくない結果が生じる可能性があるため、整合性が必要です。 [RFC5285]で指定されているように、ヘッダー拡張の性質を認識しないミドルボックスは、ヘッダー拡張を自由に転送または破棄できます。
The table below attempts to summarize the properties of the different topologies. The legend to the topology abbreviations are: Topo-Point-to-Point (PtP), Topo-ASM (ASM), Topo-SSM (SSM), Topo-Trn-Translator (TT), Topo-Media-Translator (including Transport Translator) (MT), Topo-Mesh with joint session (MJS), Topo-Mesh with individual sessions (MIS), Topo-Mixer (Mix), Topo-Asymmetric (ASY), Topo-Video-switch-MCU (VSM), Topo-RTCP-terminating-MCU (RTM), and Selective Forwarding Middlebox (SFM). In the table below, Y indicates Yes or full support, N indicates No support, (Y) indicates partial support, and N/A indicates not applicable.
次の表は、さまざまなトポロジのプロパティをまとめたものです。トポロジーの略語の凡例は次のとおりです。トポポイントツーポイント（PtP）、トポASM（ASM）、トポSSM（SSM）、トポTrnトランスレーター（TT）、トポメディアトランスレーター（トランスポートを含む）トランスレータ）（MT）、トポメッシュとジョイントセッション（MJS）、トポメッシュと個別セッション（MIS）、トポミキサー（ミックス）、トポ非対称（ASY）、トポビデオスイッチMCU（VSM） 、Topo-RTCP-terminating-MCU（RTM）、およびSelective Forwarding Middlebox（SFM）。次の表で、Yは「はい」または完全サポートを示し、Nはサポートなし、（Y）は部分的なサポート、N / Aは該当なしを示します。
Property PtP ASM SSM TT MT MJS MIS Mix ASY VSM RTM SFM
---------------------------------------------------------------------
All-to-All Media N Y (Y) Y Y Y (Y) (Y) (Y) (Y) (Y) (Y)
Interoperability N/A N N Y Y Y Y Y Y N Y Y
Per-Domain Adaptation N/A N N N Y N Y Y Y N Y Y
Aggregation of Media N N N N N N N Y (Y) Y Y N
Full Session View Y Y Y Y Y Y N Y Y (Y) N Y
Loop Detection Y Y Y Y Y Y N Y Y (Y) N N
Please note that the Media Translator also includes the Transport Translator functionality.
Media TranslatorにはTransport Translator機能も含まれていることに注意してください。
The use of mixers, SFMs, and translators has impact on security and the security functions used. The primary issue is that mixers, SFMs, and translators modify packets, thus preventing the use of integrity and source authentication, unless they are trusted devices that take part in the security context, e.g., the device can send Secure Real-time Transport Protocol (SRTP) and Secure Real-time Transport Control Protocol (SRTCP) [RFC3711] packets to endpoints in the Communication Session. If encryption is employed, the Media Translator, SFM, and mixer need to be able to decrypt the media to perform its function. A Transport Translator may be used without access to the encrypted payload in cases where it translates parts that are not included in the encryption and integrity protection, for example, IP address and UDP port numbers in a media stream using SRTP [RFC3711]. However, in general, the translator, SFM, or mixer needs to be part of the signaling context and get the necessary security associations (e.g., SRTP crypto contexts) established with its RTP session participants.
ミキサー、SFM、およびトランスレーターの使用は、セキュリティーおよび使用されるセキュリティー機能に影響を与えます。主な問題は、ミキサー、SFM、およびトランスレータがパケットを変更することです。これにより、セキュリティコンテキストに参加する信頼できるデバイスでない限り、整合性とソース認証の使用が妨げられます。たとえば、デバイスがSecure Real-time Transport Protocol（ SRTP）およびSecure Real-time Transport Control Protocol（SRTCP）[RFC3711]パケットを通信セッションのエンドポイントに送信します。暗号化が採用されている場合、Media Translator、SFM、およびミキサーは、メディアを復号化してその機能を実行できる必要があります。 SRTPを使用したメディアストリームのIPアドレスとUDPポート番号など、暗号化と整合性保護に含まれていない部分を変換する場合、トランスポートトランスレーターは、暗号化されたペイロードにアクセスせずに使用できます[RFC3711]。ただし、一般に、トランスレータ、SFM、またはミキサーは、シグナリングコンテキストの一部であり、RTPセッションの参加者と必要なセキュリティアソシエーション（SRTP暗号コンテキストなど）を確立する必要があります。
Including the mixer, SFM, and translator in the security context allows the entity, if subverted or misbehaving, to perform a number of very serious attacks as it has full access. It can perform all the attacks possible (see RFC 3550 and any applicable profiles) as if the media session were not protected at all, while giving the impression to the human session participants that they are protected.
セキュリティー・コンテキストにミキサー、SFM、およびトランスレーターを含めることにより、エンティティーは、破壊された場合や不正な動作を行った場合でも、フルアクセスが可能なため、非常に深刻な攻撃を多数実行できます。メディアセッションがまったく保護されていないかのように、可能なすべての攻撃（RFC 3550および該当するプロファイルを参照）を実行しながら、保護されているという印象をヒューマンセッションの参加者に与えることができます。
Transport Translators have no interactions with cryptography that work above the transport layer, such as SRTP, since that sort of translator leaves the RTP header and payload unaltered. Media Translators, on the other hand, have strong interactions with cryptography, since they alter the RTP payload. A Media Translator in a session that uses cryptographic protection needs to perform cryptographic processing to both inbound and outbound packets.
トランスポートトランスレーターは、SRTPなどのトランスポートレイヤーより上で機能する暗号化との相互作用がありません。これは、そのようなトランスレーターがRTPヘッダーとペイロードを変更しないままにするためです。一方、Media TranslatorはRTPペイロードを変更するため、暗号と強い相互作用があります。暗号保護を使用するセッションのメディアトランスレータは、受信パケットと送信パケットの両方に対して暗号処理を実行する必要があります。
A Media Translator may need to use different cryptographic keys for the inbound and outbound processing. For SRTP, different keys are required, because an RFC 3550 Media Translator leaves the SSRC unchanged during its packet processing, and SRTP key sharing is only allowed when distinct SSRCs can be used to protect distinct packet streams.
Media Translatorは、インバウンド処理とアウトバウンド処理に異なる暗号鍵を使用する必要がある場合があります。 RFC 3550 Media Translatorはパケット処理中にSSRCを変更せずに残すため、SRTPには異なるキーが必要です。SRTPキーの共有は、個別のSSRCを使用して個別のパケットストリームを保護できる場合にのみ許可されます。
When the Media Translator uses different keys to process inbound and outbound packets, each session participant needs to be provided with the appropriate key, depending on whether they are listening to the translator or the original source. (Note that there is an architectural difference between RTP media translation, in which participants can rely on the RTP payload type field of a packet to determine appropriate processing, and cryptographically protected media translation, in which participants must use information that is not carried in the packet.)
Media Translatorがインバウンドパケットとアウトバウンドパケットを処理するために異なるキーを使用する場合、各セッション参加者には、トランスレーターを聞くか元のソースを聞くかに応じて、適切なキーを提供する必要があります。 （参加者が適切な処理を決定するためにパケットのRTPペイロードタイプフィールドに依存できるRTPメディア変換と、参加者がで運ばれない情報を使用する必要がある暗号で保護されたメディア変換には、アーキテクチャ上の違いがあることに注意してくださいパケット。）
When using security mechanisms with translators, SFMs, and mixers, it is possible that the translator, SFM, or mixer could create different security associations for the different domains they are working in. Doing so has some implications:
トランスレータ、SFM、およびミキサーでセキュリティメカニズムを使用する場合、トランスレータ、SFM、またはミキサーが、作業しているさまざまなドメインに対してさまざまなセキュリティアソシエーションを作成する可能性があります。これには、いくつかの影響があります。
First, it might weaken security if the mixer/translator accepts a weaker algorithm or key in one domain rather than in another. Therefore, care should be taken that appropriately strong security parameters are negotiated in all domains. In many cases, "appropriate" translates to "similar" strength. If a key-management system does allow the negotiation of security parameters resulting in a different strength of the security, then this system should notify the participants in the other domains about this.
まず、ミキサー/トランスレーターが別のドメインではなくあるドメインでより弱いアルゴリズムまたはキーを受け入れると、セキュリティが低下する可能性があります。したがって、すべてのドメインで適切に強力なセキュリティパラメータがネゴシエートされるように注意する必要があります。多くの場合、「適切」は「同様の」強さを意味します。鍵管理システムがセキュリティパラメータのネゴシエーションを許可し、その結果、セキュリティの強度が異なる場合、このシステムは、これについて他のドメインの参加者に通知する必要があります。
Second, the number of crypto contexts (keys and security-related state) needed (for example, in SRTP [RFC3711]) may vary between mixers, SFMs, and translators. A mixer normally needs to represent only a single SSRC per domain and therefore needs to create only one security association (SRTP crypto context) per domain. In contrast, a translator needs one security association per participant it translates towards, in the opposite domain. Considering Figure 11, the translator needs two security associations towards the multicast domain: one for B and one for D. It may be forced to maintain a set of totally independent security associations between itself and B and D, respectively, so as to avoid two-time pad occurrences. These contexts must also be capable of handling all the sources present in the other domains. Hence, using completely independent security associations (for certain keying mechanisms) may force a translator to handle N*DM keys and related state, where N is the total number of SSRCs used over all domains and DM is the total number of domains.
第2に、必要な暗号化コンテキスト（キーとセキュリティ関連の状態）の数（SRTP [RFC3711]など）は、ミキサー、SFM、およびトランスレータによって異なる場合があります。ミキサーは通常、ドメインごとに1つのSSRCのみを表す必要があるため、ドメインごとに1つのセキュリティアソシエーション（SRTP暗号コンテキスト）のみを作成する必要があります。対照的に、翻訳者は、反対のドメインで、翻訳対象の参加者ごとに1つのセキュリティアソシエーションを必要とします。図11を考慮すると、トランスレータはマルチキャストドメインに対して2つのセキュリティアソシエーションを必要とします。1つはB用、もう1つはD用です。 -time padオカレンス。これらのコンテキストは、他のドメインに存在するすべてのソースを処理できる必要もあります。したがって、（特定のキーイングメカニズムに対して）完全に独立したセキュリティアソシエーションを使用すると、トランスレータがN * DMキーおよび関連する状態を処理するように強制される場合があります。
The ASM, SSM, Relay, and Mesh (with common RTP session) topologies each have multiple endpoints that require shared knowledge about the different crypto contexts for the endpoints. These multiparty topologies have special requirements on the key management as well as the security functions. Specifically, source authentication in these environments has special requirements.
ASM、SSM、リレー、およびメッシュ（共通のRTPセッションを使用）トポロジにはそれぞれ、複数のエンドポイントがあり、エンドポイントのさまざまな暗号コンテキストに関する共有知識が必要です。これらのマルチパーティトポロジには、キー管理とセキュリティ機能に関する特別な要件があります。特に、これらの環境でのソース認証には特別な要件があります。
There exist a number of different mechanisms to provide keys to the different participants. One example is the choice between group keys and unique keys per SSRC. The appropriate keying model is impacted by the topologies one intends to use. The final security properties are dependent on both the topologies in use and the keying mechanisms' properties and need to be considered by the application. Exactly which mechanisms are used is outside of the scope of this document. Please review RTP Security Options [RFC7201] to get a better understanding of most of the available options.
さまざまな参加者にキーを提供するさまざまなメカニズムがいくつか存在します。 1つの例は、SSRCごとのグループキーと一意のキーの選択です。適切なキーイングモデルは、使用するトポロジによって影響を受けます。最終的なセキュリティプロパティは、使用中のトポロジとキーイングメカニズムのプロパティの両方に依存するため、アプリケーションで考慮する必要があります。正確にどのメカニズムが使用されるかは、このドキュメントの範囲外です。 RTPセキュリティオプション[RFC7201]を確認して、利用可能なほとんどのオプションについて理解を深めてください。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <http://www.rfc-editor.org/info/rfc3550>。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、DOI 10.17487 / RFC4585、2006年7月、<http://www.rfc-editor.org/info/rfc4585>。
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.
[RFC7656] Lennox、J.、Gross、K.、Nandakumar、S.、Salgueiro、G。、およびB. Burman、編、「A Realization of Semantics and Mechanisms for Real-Time Transport Protocol（RTP）Sources」 、RFC 7656、2015年11月、<http://www.rfc-editor.org/info/rfc7656>。
[MULTI-STREAM-OPT] Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback", Work in Progress, draft-ietf-avtcore-rtp-multi-stream-optimisation-08, October 2015.
[MULTI-STREAM-OPT] Lennox、J.、Westerlund、M.、Wu、W。、およびC. Perkins、「単一のRTPセッションでの複数のメディアストリームの送信：RTCP受信統計とその他のフィードバックのグループ化」、進行中の作業、draft-ietf-avtcore-rtp-multi-stream-optimization-08、2015年10月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <http://www.rfc-editor.org/info/rfc1112>.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、DOI 10.17487 / RFC1112、1989年8月、<http://www.rfc-editor.org/info/rfc1112>。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、DOI 10.17487 / RFC3022、2001年1月、<http://www.rfc-editor.org/info/ rfc3022>。
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 2003, <http://www.rfc-editor.org/info/rfc3569>.
[RFC3569] Bhattacharyya、S。、編、「ソース固有のマルチキャスト（SSM）の概要」、RFC 3569、DOI 10.17487 / RFC3569、2003年7月、<http://www.rfc-editor.org/info/ rfc3569>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004、<http://www.rfc-editor.org/info/rfc3711>。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, DOI 10.17487/RFC4575, August 2006, <http://www.rfc-editor.org/info/rfc4575>.
[RFC4575] Rosenberg、J.、Schulzrinne、H。、およびO. Levin、編、「会議状態用のSession Initiation Protocol（SIP）イベントパッケージ」、RFC 4575、DOI 10.17487 / RFC4575、2006年8月、<http： //www.rfc-editor.org/info/rfc4575>。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, <http://www.rfc-editor.org/info/rfc4607>.
[RFC4607] Holbrook、H.およびB. Cain、「Source-Specific Multicast for IP」、RFC 4607、DOI 10.17487 / RFC4607、2006年8月、<http://www.rfc-editor.org/info/rfc4607>。
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5104] Wenger、S.、Chandra、U.、Westerlund、M。、およびB. Burman、「フィードバック付きのRTPオーディオビジュアルプロファイルのコーデック制御メッセージ（AVPF）」、RFC 5104、DOI 10.17487 / RFC5104、2月2008、<http://www.rfc-editor.org/info/rfc5104>。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, DOI 10.17487/RFC5117, January 2008, <http://www.rfc-editor.org/info/rfc5117>.
[RFC5117] Westerlund、M。およびS. Wenger、「RTPトポロジ」、RFC 5117、DOI 10.17487 / RFC5117、2008年1月、<http://www.rfc-editor.org/info/rfc5117>。
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, <http://www.rfc-editor.org/info/rfc5285>.
[RFC5285] Singer、D。およびH. Desineni、「一般的なRTPヘッダー拡張メカニズム」、RFC 5285、DOI 10.17487 / RFC5285、2008年7月、<http://www.rfc-editor.org/info/rfc5285> 。
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, DOI 10.17487/RFC5760, February 2010, <http://www.rfc-editor.org/info/rfc5760>.
[RFC5760] Ott、J.、Chesterfield、J。、およびE. Schooler、「ユニキャストフィードバック付きの単一ソースマルチキャストセッション用のRTP制御プロトコル（RTCP）拡張」、RFC 5760、DOI 10.17487 / RFC5760、2010年2月、<http ：//www.rfc-editor.org/info/rfc5760>。
[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, DOI 10.17487/RFC5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5766] Mahy、R.、Matthews、P.、J。Rosenberg、「NAT（TURN）のリレーを使用したトラバーサル：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、RFC 5766、DOI 10.17487 / RFC5766、4月2010、<http://www.rfc-editor.org/info/rfc5766>。
[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, DOI 10.17487/RFC6285, June 2011, <http://www.rfc-editor.org/info/rfc6285>.
[RFC6285] Ver Steeg、B.、Begen、A.、Van Caenegem、T。、およびZ. Vax、「マルチキャストRTPセッションのユニキャストベースの高速取得」、RFC 6285、DOI 10.17487 / RFC6285、2011年6月、<http ：//www.rfc-editor.org/info/rfc6285>。
[RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication", RFC 6465, DOI 10.17487/RFC6465, December 2011, <http://www.rfc-editor.org/info/rfc6465>.
[RFC6465] Ivov、E.、Ed。、Marocco、E.、Ed。、and J. Lennox、 "A Real-time Transport Protocol（RTP）Header Extension for Mixer-to-Client Audio Level Indication"、RFC 6465、 DOI 10.17487 / RFC6465、2011年12月、<http://www.rfc-editor.org/info/rfc6465>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<http://www.rfc-editor.org/info/rfc7201>。
[RTCP-SDES] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP Header Extension for RTCP Source Description Items", Work in Progress, draft-ietf-avtext-sdes-hdr-ext-02, July 2015.
[RTCP-SDES] Westerlund、M.、Burman、B.、Even、R。、およびM. Zanaty、「RTCPソース記述アイテムのRTPヘッダー拡張」、作業中、draft-ietf-avtext-sdes-hdr- ext-02、2015年7月。
[SDP-BUNDLE] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Work in Progress, draft-ietf-mmusic-sdp-bundle-negotiation-23, July 2015.
[SDP-BUNDLE] Holmberg、C.、Alvestrand、H。、およびC. Jennings、「Session Description Protocol（SDP）を使用したメディア多重化のネゴシエーション」、進行中の作業、draft-ietf-mmusic-sdp-bundle-negotiation- 2015年7月23日。
Acknowledgements
謝辞
The authors would like to thank Mark Baugher, Bo Burman, Ben Campbell, Umesh Chandra, Alex Eleftheriadis, Roni Even, Ladan Gharai, Geoff Hunt, Suresh Krishnan, Keith Lantz, Jonathan Lennox, Scarlet Liuyan, Suhas Nandakumar, Colin Perkins, and Dan Wing for their help in reviewing and improving this document.
著者は、マーク・バウアー、ボー・バーマン、ベン・キャンベル、ウメシュ・チャンドラ、アレックス・エレフテリアディス、ロニ・イブン、ラダン・ガライ、ジェフ・ハント、スレッシュ・クリシュナン、キース・ランツ、ジョナサン・レノックス、スカーレット・リューヤン、スハス・ナンダクマー、コリン・パーキンス、ダンに感謝しますこの文書のレビューと改善に協力してくれたウイング。
Authors' Addresses
著者のアドレス
Magnus Westerlund Ericsson Farogatan 2 SE-164 80 Kista Sweden
Magnus Westerlund Ericsson Farogatan 2 SE-164 80 Kistaスウェーデン
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com
Stephan Wenger Vidyo 433 Hackensack Ave Hackensack, NJ 07601 United States
Stephan Wenger Vidyo 433 Hackensack Ave Hackensack、NJ 07601アメリカ
Email: stewe@stewe.org