RFC 8079 - Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8079
タイトル : RFC 8079 - バックツーバックユーザーエージェント（B2BUA）でのRTP制御プロトコル（RTCP）のエンドツーエンドサポートのガイドライン
翻訳編集 : 自動生成

[要約] 要約：RFC 8079は、Back-to-Back User Agents（B2BUAs）でのRTP Control Protocol（RTCP）のエンドツーエンドサポートのためのガイドラインです。目的：このRFCの目的は、B2BUAsでRTCPを適切にサポートするためのガイドラインを提供することです。

Internet Engineering Task Force (IETF)                        L. Miniero
Request for Comments: 8079                                      Meetecho
Category: Standards Track                              S. Garcia Murillo
ISSN: 2070-1721                                                  Medooze
                                                              V. Pascual
                                                                  Oracle
                                                           February 2017

Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs)

バックツーバックユーザーエージェント（B2BUA）でのRTP制御プロトコル（RTCP）のエンドツーエンドサポートのガイドライン

Abstract

概要

SIP Back-to-Back User Agents (B2BUAs) are often designed to also be on the media path, rather than just to intercept signalling. This means that B2BUAs often implement an RTP or RTP Control Protocol (RTCP) stack as well, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP messages get lost because of mismatches in the reported data.

SIPバックツーバックユーザーエージェント（B2BUA）は、シグナリングを傍受するだけでなく、メディアパスにも存在するように設計されていることがよくあります。つまり、B2BUAはRTPまたはRTP制御プロトコル（RTCP）スタックも実装することが多く、B2BUAが相互に関連付けてブリッジする個別のマルチメディアセッションにつながります。統制されていない場合、この動作は、特にRTCPメッセージに含まれる統計情報とフィードバック情報が、報告されたデータの不一致により失われる場合に、通信エクスペリエンスに深刻な影響を与える可能性があります。

This document defines the proper behaviour B2BUAs should follow when acting on both the signalling plane and media plane in order to preserve the end-to-end functionality of RTCP.

このドキュメントでは、RTCPのエンドツーエンドの機能を維持するために、シグナリングプレーンとメディアプレーンの両方で動作するときにB2BUAが従うべき適切な動作を定義しています。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8079.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8079で入手できます。

著作権表示

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Signalling/Media Plane B2BUAs . . . . . . . . . . . . . . . .   4
     3.1.  Media Relay . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Media-Aware Relay . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Media Terminator  . . . . . . . . . . . . . . . . . . . .  11
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1. Introduction

1. はじめに

Session Initiation Protocol (SIP) [RFC3261] Back-to-Back User Agents (B2BUAs) are SIP entities that can act as a logical combination of both a User Agent Server (UAS) and a User Agent Client (UAC). As such, their behaviour is not always completely adherent to standards and can lead to unexpected situations. [RFC7092] presents a taxonomy of the most commonly deployed B2BUA implementations and describes how they differ in terms of the functionality and features they provide.

セッション開始プロトコル（SIP）[RFC3261]バックツーバックユーザーエージェント（B2BUA）は、ユーザーエージェントサーバー（UAS）とユーザーエージェントクライアント（UAC）の両方の論理的な組み合わせとして機能できるSIPエンティティです。そのため、それらの動作は常に完全に標準に準拠しているわけではなく、予期しない状況につながる可能性があります。 [RFC7092]は、最も一般的に展開されるB2BUA実装の分類法を示し、それらが提供する機能と機能の点でどのように異なるかを説明します。

Such components often do not only act on the signalling plane (intercepting and possibly modifying SIP messages), but also on the media plane. This means that, in order to receive and manage all RTP and RTCP [RFC3550] packets in a session, these components also manipulate the session descriptions [RFC4566] in the related offer/ answer exchanges [RFC3264]. The reasons for such behaviour can be different. The B2BUA may want, for instance, to provide transcoding functionality for participants with incompatible codecs, or it may need the traffic to be directly handled for different reasons. This can lead to several different topologies for RTP-based communication, as documented in [RFC7667].

このようなコンポーネントは、多くの場合、シグナリングプレーン（SIPメッセージのインターセプトおよび場合によっては変更）だけでなく、メディアプレーンにも作用します。つまり、セッションですべてのRTPおよびRTCP [RFC3550]パケットを受信して管理するために、これらのコンポーネントは関連するオファー/アンサー交換[RFC3264]のセッション記述[RFC4566]も操作します。このような動作の理由は異なる場合があります。 B2BUAは、たとえば、互換性のないコーデックを持つ参加者にトランスコーディング機能を提供したい場合や、さまざまな理由でトラフィックを直接処理する必要がある場合があります。これは、[RFC7667]で文書化されているように、RTPベースの通信にいくつかの異なるトポロジーをもたらす可能性があります。

Whatever the reason, such behaviour does not come without a cost. In fact, whenever a media-aware component is placed on the path between two or more participants that want to communicate by means of RTP/ RTCP, the end-to-end nature of such protocols is broken. While this may not be a problem for RTP packets, which can be quite easily relayed, it definitely can cause serious issue for RTCP messages, which carry important information and feedback on the communication quality the participants are experiencing. Consider, for instance, the simple scenario only involving two participants and a single RTP session depicted in Figure 1:

理由が何であれ、そのような振る舞いには費用がかかります。実際、RTP / RTCPを使用して通信したい2人以上の参加者間のパスにメディア対応コンポーネントが配置されると、そのようなプロトコルのエンドツーエンドの性質が損なわれます。これは、非常に簡単に中継できるRTPパケットの問題ではないかもしれませんが、参加者が経験している通信品質に関する重要な情報とフィードバックを運ぶRTCPメッセージに重大な問題を引き起こす可能性があります。たとえば、図1に示す2人の参加者と1つのRTPセッションのみを含む単純なシナリオを考えてみます。

   +--------+              +---------+              +---------+
   |        |=== SSRC1 ===>|         |=== SSRC3 ===>|         |
   | Alice  |              |  B2BUA  |              |   Bob   |
   |        |<=== SSRC2 ===|         |<=== SSRC4 ===|         |
   +--------+              +---------+              +---------+

Figure 1: B2BUA Modifying RTP Headers

図1：B2BUAのRTPヘッダーの変更

In this common scenario, a participant (Alice) is communicating with another participant (Bob) as a result of a signalling session managed by a B2BUA: this B2BUA is also on the media path between the two and is acting as a Media Relay. This means that two separate RTP sessions are involved (one per side), each carrying two RTP streams (one per media direction). As part of this process, the B2BUA is also rewriting some of the RTP header information on the way. In this example, just the Synchronization Source (SSRC) of the incoming RTP streams is changed, but more information may be modified as well (e.g., sequence numbers, timestamps, etc.). In particular, whenever Alice sends an RTP packet, she sets her SSRC (SSRC1) in the RTP header of her RTP source stream. The B2BUA rewrites the SSRC (SSRC3) before relaying the packet to Bob. At the same time, RTP packets sent by Bob (SSRC4) get their SSRC rewritten as well (SSRC2) before being relayed to Alice.

この一般的なシナリオでは、B2BUAによって管理されるシグナリングセッションの結果として、参加者（アリス）が別の参加者（ボブ）と通信しています。このB2BUAも2つの間のメディアパス上にあり、メディアリレーとして機能しています。これは、2つの個別のRTPセッションが関与し（サイドごとに1つ）、それぞれが2つのRTPストリーム（メディア方向ごとに1つ）を運ぶことを意味します。このプロセスの一部として、B2BUAは途中で一部のRTPヘッダー情報も書き換えています。この例では、着信RTPストリームの同期ソース（SSRC）のみが変更されていますが、さらに多くの情報（シーケンス番号、タイムスタンプなど）も変更される場合があります。特に、アリスはRTPパケットを送信するたびに、自分のRTPソースストリームのRTPヘッダーにSSRC（SSRC1）を設定します。 B2BUAは、パケットをボブにリレーする前にSSRC（SSRC3）を書き換えます。同時に、ボブ（SSRC4）から送信されたRTPパケットは、アリスに中継される前に、SSRCも書き換えられます（SSRC2）。

Assuming now that Alice needs to inform Bob that she has lost several packets in the last few seconds, she will place the related received RTP stream SSRC she is aware of (SSRC2) together with her own (SSRC1) in RTCP Reports and/or NACKs. Since the B2BUA is making use of different SSRCs for the RTP streams in the RTP session it established with each participant, blindly relaying Alice's incoming RTCP messages to Bob would cause issues. These RTCP messages would reference SSRCs Bob doesn't know about, which would result in precious feedback being dropped. In fact, Bob is only aware of SSRC4 (the one his source RTP stream uses) and SSRC3 (the one he's receiving from the B2BUA in the received RTP stream) and knows nothing about SSRC1 and SSRC2 in the messages he received instead. Considering the feedback being dropped because of this may contain precious information (e.g., related to packet loss, congestion, and other network issues or considerations), the inability to take them into account may lead to severe issues. For instance, Bob may flood Alice with more media packets she can handle and/or not retransmit the packets she missed and asked for. This may easily lead to a very bad communication experience, if not eventually to an unwanted termination of the communication itself.

アリスがボブに最後の数秒間にいくつかのパケットを失ったことを通知する必要があると仮定すると、彼女は自分が知っている関連する受信RTPストリームSSRC（SSRC2）を自分の（SSRC1）とともに自分の（SSRC1）とともにRTCPレポートまたはNACKに配置します。 B2BUAは、各参加者と確立したRTPセッションでRTPストリームに異なるSSRCを使用しているため、アリスの着信RTCPメッセージをボブに盲目的に中継すると問題が発生します。これらのRTCPメッセージは、ボブが知らないSSRCを参照するため、貴重なフィードバックがドロップされます。実際、ボブはSSRC4（ソースRTPストリームが使用するもの）とSSRC3（受信したRTPストリームでB2BUAから受信しているもの）だけを認識しており、代わりに受信したメッセージでSSRC1とSSRC2について何も知りません。これによりドロップされたフィードバックには貴重な情報が含まれている可能性があるため（たとえば、パケットの損失、輻輳、その他のネットワークの問題や考慮事項）、それらを考慮できないと深刻な問題が発生する可能性があります。たとえば、ボブは、アリスが処理できるより多くのメディアパケットでフラッドする、および/または見逃して要求したパケットを再送信しない場合があります。これは、最終的に通信自体の不要な終了に至らない場合でも、非常に悪い通信体験を簡単に引き起こす可能性があります。

This is just a trivial example that, together with additional scenarios, will be addressed in the following sections. Nevertheless, it is a valid example of how such a simple mishandling of precious information may lead to serious consequences. This is especially true if we picture more complex scenarios involving several participants at the same time, multiple RTP sessions (e.g., a video stream along audio) rather than a single one, redundancy RTP streams, SSRC multiplexing, and so on. Considering how common B2BUA deployments are, it is very important for them to properly address RTCP messages in order to be sure that their activities on the media plane do not break or interfere with anything relevant to the session.

これはほんのささいな例であり、追加のシナリオとともに、次のセクションで取り上げます。それにもかかわらず、それは貴重な情報のそのような単純な誤った取り扱いが深刻な結果につながるかもしれない方法の有効な例です。これは、複数の参加者が同時に関与するより複雑なシナリオ、単一のセッションではなく複数のRTPセッション（オーディオに沿ったビデオストリームなど）、冗長RTPストリーム、SSRC多重化などを想定している場合に特に当てはまります。 B2BUAの一般的な展開を考えると、メディアプレーンでのアクティビティが中断したり、セッションに関連するものに干渉したりしないように、RTCPメッセージに適切に対処することが非常に重要です。

2. Terminology

2. 用語

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

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

In addition, this document uses, where relevant, the RTP-related terminology defined in [RFC7656].

さらに、このドキュメントでは、関連する場合、[RFC7656]で定義されているRTP関連の用語を使用します。

3. Signalling/Media Plane B2BUAs

3. シグナリング/メディアプレーンB2BUA

As described in the Introduction (Section 1), it's very common for B2BUA deployments to act on the media plane rather than just on the signalling plane alone. In particular, [RFC7092] describes three different categories of such B2BUAs: (1) a simple Media Relay that is effectively unaware of anything that is transported; (2) a Media-aware Relay that inspects and/or modifies RTP and RTCP messages as they flow by; and (3) a full-fledged media termination entity that terminates and generates RTP and RTCP messages as needed.

はじめに（セクション1）で説明したように、B2BUA展開は、シグナリングプレーンだけでなく、メディアプレーンで動作するのが一般的です。特に、[RFC7092]は、そのようなB2BUAの3つの異なるカテゴリについて説明しています。（1）転送されるものを事実上認識しない単純なメディアリレー。（2）RTPおよびRTCPメッセージが流れるときに検査および/または変更するメディア認識リレー。（3）必要に応じてRTPおよびRTCPメッセージを終了および生成する本格的なメディア終了エンティティ。

[RFC3550] and [RFC7667] already mandate some specific behaviours in the presence of certain topologies. However, due to their mixed nature, B2BUAs sometimes can't or won't implement all relevant specifications. This means that it's not rare to encounter issues that may be avoided with more disciplined behaviour in that regard, that is, if the B2BUAs followed at least a set of guidelines to ensure no known problems occur. For this reason, the following subsections describe the proper behaviour that B2BUAs, whatever above category they fall in, should follow in order not to impact any end-to-end RTCP effectiveness.

[RFC3550]および[RFC7667]は、特定のトポロジーが存在する場合の特定の動作をすでに義務付けています。ただし、B2BUAはその性質が混在しているため、関連するすべての仕様を実装できない場合があります。つまり、B2BUAが少なくとも一連のガイドラインに従って既知の問題が発生しないようにする場合、その点に関してより厳格な動作で回避できる問題が発生することは珍しくありません。このため、以下のサブセクションでは、エンドツーエンドのRTCPの有効性に影響を与えないようにするために、B2BUAが上記のカテゴリに該当する場合でも、B2BUAが従うべき適切な動作について説明します。

3.1. Media Relay

3.1. メディアリレー

A Media Relay, as identified in [RFC7092], simply forwards all RTP and RTCP messages it receives without either inspecting or modifying them. Using the terminology in "RTP Topologies" [RFC7667], this can be seen as an RTP Transport Translator. As such, B2BUAs acting as Media Relays are not aware of what traffic they're handling. This means that both packet payloads and packet headers are opaque to them. Many Session Border Controllers (SBCs) implement this kind of behaviour, e.g., when acting as a bridge between an inner and outer network.

メディアリレーは、[RFC7092]で識別されているように、受信したすべてのRTPおよびRTCPメッセージを、検査も変更もせずに転送するだけです。「RTPトポロジ」[RFC7667]の用語を使用すると、これはRTPトランスポートトランスレータと見なすことができます。そのため、メディアリレーとして機能するB2BUAは、処理しているトラフィックを認識しません。これは、パケットペイロードとパケットヘッダーの両方が不透明であることを意味します。多くのセッションボーダーコントローラー（SBC）は、たとえば、内部ネットワークと外部ネットワーク間のブリッジとして機能する場合に、この種の動作を実装します。

Considering that all headers and identifiers in both RTP and RTCP are left untouched, issues like the SSRC mismatch described in the previous section would not occur. However, similar problems could still happen for different reasons, for instance, if the session description prepared by the B2BUA, whether it has been modified or not, ends up providing incorrect information. This may happen, for example, if the Session Description Protocol (SDP) on either side contains 'ssrc' [RFC5576] attributes that don't match the actual SSRC being advertised on the media plane or if the B2BUA advertised support for NACK because it implements it while the original INVITE didn't. Such issues might occur, for instance, when the B2BUA acting as a Media Relay is generating a new session description when bridging an incoming call rather than using the original session description. This may cause participants to find a mismatch between the SSRCs advertised in the SDP and the ones actually observed in RTP and RTCP messages or to have them either ignore or generate RTCP feedback packets that were not explicitly advertised as supported.

RTPとRTCPの両方のすべてのヘッダーと識別子が変更されていないことを考えると、前のセクションで説明したSSRCの不一致などの問題は発生しません。ただし、たとえば、B2BUAによって作成されたセッションの説明が変更されているかどうかにかかわらず、最終的に誤った情報が提供される場合など、さまざまな理由で同様の問題が発生する可能性があります。これは、たとえば、どちらかの側のセッション記述プロトコル（SDP）に、メディアプレーンでアドバタイズされている実際のSSRCと一致しない「ssrc」[RFC5576]属性が含まれている場合、またはB2BUAがNACKのサポートをアドバタイズした場合に発生する可能性があります。元のINVITEは実装していませんでした。このような問題は、たとえば、メディアリレーとして機能するB2BUAが、元のセッションの説明を使用するのではなく、着信コールをブリッジするときに新しいセッションの説明を生成する場合に発生する可能性があります。これにより、参加者は、SDPでアドバタイズされたSSRCと、RTPおよびRTCPメッセージで実際に観測されたSSRCの間の不一致を検出したり、サポートとして明示的にアドバタイズされなかったRTCPフィードバックパケットを無視または生成したりする可能性があります。

In order to prevent such an issue, a Media Relay B2BUA SHOULD forward all the SSRC- and RTCP-related SDP attributes when handling a multimedia session setup between participants: this includes attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 'rtcp-xr-attrib' [RFC3611], and others. However, certain SDP attributes may lead to call failures when forwarded by a Media Relay, as they have an implied assumption that the attribute describes the immediate peer. A clear example of this is the 'rtcp' [RFC3605] attribute, which describes the expected RTCP peer port. Other attributes might include the immediate peer's IP address, preferred transport, etc. In general, the guideline is to require rewriting of attributes that are implicitly describing the immediate peer. B2BUAs SHOULD forward all other SDP attributes in order to avoid breaking additional functionality that endpoints may be relying on. If implementors have doubts about whether this guidance applies to a specific attribute, they should test to determine if call failures occur.

このような問題を防ぐために、メディアリレーB2BUAは、参加者間のマルチメディアセッションセットアップを処理するときに、SSRCおよびRTCP関連のすべてのSDP属性を転送する必要があります。これには、「ssrc」[RFC3261]、「rtcp-fb」[ RFC4585]、 'rtcp-xr-attrib' [RFC3611]、その他。ただし、特定のSDP属性は、属性が直接のピアを説明するものであるという暗黙の前提があるため、メディアリレーによって転送されると、コール障害を引き起こす可能性があります。これの明確な例は、予想されるRTCPピアポートを説明する「rtcp」[RFC3605]属性です。その他の属性には、直接のピアのIPアドレス、優先トランスポートなどが含まれる場合があります。一般に、ガイドラインでは、直接のピアを暗黙的に記述している属性の書き換えを要求します。 B2BUAは、エンドポイントが依存している可能性のある追加機能を壊さないようにするために、他のすべてのSDP属性を転送する必要があります（SHOULD）。実装者がこのガイダンスが特定の属性に適用されるかどうか疑問がある場合は、呼び出しの失敗が発生するかどうかを判断するためにテストする必要があります。

The cited 'rtcp' example is also relevant whenever RTP/RTCP multiplexing [RFC5761] support is being negotiated. If the B2BUA acting as a Media Relay is unaware of the specifics of the traffic it is handling, and as such may not have RTP/RTCP parsing capabilities, it SHOULD reject RTP/RTCP multiplexing by removing the 'rtcp-mux' SDP attribute. If instead the Media Relay is able to parse RTP/RTCP, and can verify that demultiplexing can be performed without any RTP Payload Type rewrites (i.e., no overlap between any RTP Payload Types and the RTCP Payload Type space has been detected), then the B2BUA SHOULD negotiate RTP/RTCP multiplexing support if advertised.

引用された「rtcp」の例は、RTP / RTCP多重化[RFC5761]サポートがネゴシエートされている場合にも関連します。メディアリレーとして機能するB2BUAが処理するトラフィックの詳細を認識していないため、RTP / RTCP解析機能がない場合は、「rtcp-mux」SDP属性を削除してRTP / RTCP多重化を拒否する必要があります。代わりに、メディアリレーがRTP / RTCPを解析でき、RTPペイロードタイプの書き換えなしで逆多重化を実行できることを確認できる場合（つまり、RTPペイロードタイプとRTCPペイロードタイプスペースの重複が検出されていない場合）、 B2BUAは、アドバタイズされた場合、RTP / RTCP多重化サポートをネゴシエートする必要があります（SHOULD）。

It is worth mentioning that, by leaving RTCP messages untouched, a Media Relay may also leak information that, according to policies, may need to be hidden or masqueraded, e.g., domain names in CNAME items. Besides, these CNAME items may actually contain IP addresses: this means that, should a NAT be involved in the communication, this may actually result in CNAME collisions, which could indeed break the end-to-end RTCP behaviour. While [RFC7022] can prevent this from happening, there may be implementations that don't make use of it. As such, a B2BUA MAY rewrite CNAME items if any potential collision is detected, even in the Media Relay case. If a B2BUA does indeed decide to rewrite CNAME items, then it MUST generate new CNAMEs following [RFC7022]. The same SHOULD be done if RTP extensions involving CNAMEs are involved (e.g., "urn:ietf:params:rtp-hdrext:sdes:cname" [RFC7941]). If that is not possible, e.g., because the Media Relay does not have RTP header editing capabilities or does not support these extensions, then the B2BUA MUST reject the negotiation of such extensions when negotiating the session.

メディアリレーは、RTCPメッセージをそのままにしておくことで、ポリシーに従って、非表示にする必要がある、またはCNAMEアイテムのドメイン名などのマスカレードが必要になる可能性がある情報をリークする可能性があることにも言及する価値があります。さらに、これらのCNAMEアイテムには実際にIPアドレスが含まれている可能性があります。つまり、NATが通信に関与している場合、実際にCNAMEの衝突が発生し、エンドツーエンドのRTCP動作が実際に壊れる可能性があります。 [RFC7022]はこれを防ぐことができますが、それを利用しない実装があるかもしれません。したがって、メディアリレーの場合でも、衝突の可能性が検出された場合、B2BUAはCNAMEアイテムを書き換えることができます（MAY）。 B2BUAが実際にCNAMEアイテムを書き換えることを決定した場合、[RFC7022]に従って新しいCNAMEを生成する必要があります。 CNAMEを含むRTP拡張機能が関係する場合も、同じようにする必要があります（たとえば、「urn：ietf：params：rtp-hdrext：sdes：cname」[RFC7941]）。これが不可能な場合、たとえば、メディアリレーにRTPヘッダー編集機能がないか、これらの拡張機能をサポートしていないため、B2BUAはセッションのネゴシエーション時にそのような拡張機能のネゴシエーションを拒否する必要があります。

3.2. Media-Aware Relay

3.2. メディア対応リレー

A Media-aware Relay, unlike the Media Relay addressed in the previous section, is aware of the media traffic it is handling. This means it inspects RTP and RTCP messages flowing by and may even modify their headers. Using the terminology in [RFC3550], this can be seen as an RTP Translator. A B2BUA implementing this role typically does not inspect the RTP payloads, which would be opaque to them: this means that the actual media would not be manipulated (e.g., transcoded).

メディア対応リレーは、前のセクションで取り上げたメディアリレーとは異なり、処理するメディアトラフィックを認識しています。これは、フローするRTPおよびRTCPメッセージを検査し、ヘッダーを変更することさえあることを意味します。 [RFC3550]の用語を使用すると、これはRTPトランスレータと見なすことができます。この役割を実装するB2BUAは、通常、RTPペイロードを検査しません。RTPペイロードは不透明です。つまり、実際のメディアは操作されません（トランスコードなど）。

This makes them quite different from the Media Relays previously discussed, especially in terms of the potential issues that may occur at the RTCP level. In fact, being able to modify the RTP and RTCP headers, such B2BUAs may end up modifying RTP-related information like SSRC / Contributing Source (CSRC), sequence numbers, timestamps, and others in an RTP stream before forwarding the modified packets to the other interested participants. This means that, if not properly disciplined, such behaviour may easily lead to issues like the one described in the introductory section. For this reason, it is very important for a B2BUA modifying RTP-related information across two related RTP streams to also modify, in a coherent way, the same information in RTCP messages.

これにより、特にRTCPレベルで発生する可能性のある潜在的な問題の点で、前述のメディアリレーとは大きく異なります。実際、RTPヘッダーとRTCPヘッダーを変更できるため、そのようなB2BUAは、変更されたパケットを他の関心のある参加者。これは、適切に規律されていないと、そのような動作が導入セクションで説明されているような問題に簡単につながる可能性があることを意味します。このため、B2BUAが2つの関連するRTPストリームにわたってRTP関連の情報を変更することは、RTCPメッセージ内の同じ情報も一貫した方法で変更することが非常に重要です。

It is worthwhile to point out that such a B2BUA may not necessarily forward all the packets it receives. Selective Forwarding Units (SFUs) [RFC7667], for instance, may be implemented to aggregate or drop incoming RTCP messages while at the same time originating new ones on their own. It is important to clarify that a B2BUA SHOULD NOT randomly drop or forward RTCP feedback of the same type (e.g., a specific XR block type or specific Feedback messages) within the context of the same session as that may lead to confusing, if not broken, feedback to the recipients of the message due to gaps in the communication. As to the messages that are forwarded and/or aggregated, it's important to make sure the information is coherent.

このようなB2BUAは、受信したすべてのパケットを必ずしも転送するとは限らないことに注意してください。たとえば、選択的転送ユニット（SFU）[RFC7667]を実装して、着信RTCPメッセージを集約またはドロップすると同時に、独自に新しいメッセージを発信することができます。同じセッションのコンテキスト内で、B2BUAが同じタイプのRTCPフィードバックをランダムにドロップまたは転送してはならないことを明確にすることが重要です（例：特定のXRブロックタイプまたは特定のフィードバックメッセージ）。、コミュニケーションのギャップによるメッセージの受信者へのフィードバック。転送および/または集約されたメッセージに関しては、情報が一貫していることを確認することが重要です。

Besides the behaviour already mandated for RTCP translators in Section 7.2 of [RFC3550], a media-aware B2BUA MUST handle incoming RTCP messages to forward following these guidelines:

[RFC3550]のセクション7.2ですでにRTCPトランスレータに義務付けられている動作に加えて、メディア認識B2BUAは次のガイドラインに従って転送する着信RTCPメッセージを処理する必要があります。

Sender Report (SR) [RFC3550]: If the B2BUA has changed the SSRC of the sender RTP stream a Sender Report refers to, it MUST update the SSRC in the SR packet header as well. If the B2BUA has changed the SSRCs of other RTP streams too, and any of these streams are addressed in any of the SR Report Blocks, it MUST update the related values in the SR Report Blocks as well. If the B2BUA has also changed the base RTP sequence number when forwarding RTP packets, then this change MUST be reflected in the 'extended highest sequence number received' field in the Report Blocks. In case the B2BUA is acting as a Selective Forwarding Unit (SFU) [RFC7667], it needs to track in the outgoing SR, the relevant number of packets sent, and the total amount of bytes sent to the receiver.

送信者レポート（SR）[RFC3550]：B2BUAが送信者レポートが参照する送信者RTPストリームのSSRCを変更した場合、SRパケットヘッダーのSSRCも更新する必要があります。 B2BUAが他のRTPストリームのSSRCも変更し、これらのストリームのいずれかがSRレポートブロックのいずれかでアドレス指定されている場合、SRレポートブロックの関連する値も更新する必要があります。 B2BUAがRTPパケットを転送するときにベースRTPシーケンス番号も変更した場合、この変更はレポートブロックの「拡張された最大シーケンス番号受信」フィールドに反映される必要があります。 B2BUAがセレクティブフォワーディングユニット（SFU）[RFC7667]として機能している場合、送信SR、関連する送信パケット数、および受信機に送信された総バイト数を追跡する必要があります。

Receiver Report (RR) [RFC3550]: The guidelines for SR apply to RR as well.

受信者レポート（RR）[RFC3550]：SRのガイドラインはRRにも適用されます。

Source Description (SDES) [RFC3550]: If the B2BUA has changed the SSRC of any RTP stream addressed in any of the chunks of an incoming SDES message, it MUST update the related SSRCs in all the chunks. The same considerations made with respect to CNAME collisions at the end of Section 3.1 apply here as well.

ソース記述（SDES）[RFC3550]：B2BUAが着信SDESメッセージのチャンクのいずれかでアドレス指定されたRTPストリームのSSRCを変更した場合、すべてのチャンクで関連するSSRCを更新する必要があります。セクション3.1の終わりにCNAMEの衝突に関して行われたのと同じ考慮事項がここでも適用されます。

BYE [RFC3550]: If the B2BUA has changed the SSRC of any RTP stream addressed in the SSRC/CSRC identifiers included in a BYE packet, it MUST update them in the message.

BYE [RFC3550]：B2BUAがBYEパケットに含まれるSSRC / CSRC識別子でアドレス指定されたRTPストリームのSSRCを変更した場合、メッセージでそれらを更新する必要があります。

APP [RFC3550]: If the B2BUA has changed the SSRC of any RTP stream addressed in the header of an APP packet, it MUST update the identifier in the message. Should the B2BUA be aware of any specific APP message format that contains additional information related to SSRCs, it SHOULD update them accordingly as well.

APP [RFC3550]：B2BUAがAPPパケットのヘッダーでアドレス指定されたRTPストリームのSSRCを変更した場合、メッセージの識別子を更新する必要があります。 B2BUAがSSRCに関連する追加情報を含む特定のAPPメッセージ形式を認識している場合は、それに応じてそれらも更新する必要があります。

Extended Reports (XRs) [RFC3611]: If the B2BUA has changed the SSRC of the RTP stream associated with the originator of an XR packet, it MUST update the SSRC in the XR message header. The same guidelines given for SR/RR, with respect to SSRC identifiers in Report Blocks, apply to all the Report Block types in the XR message as well. If the B2BUA has also changed the base RTP sequence number when forwarding RTP packets, then this change MUST be reflected in the 'begin_seq' and 'end_seq' fields that are available in most of the Report Block types that are part of the XR specification.

拡張レポート（XR）[RFC3611]：B2BUAがXRパケットの発信者に関連付けられたRTPストリームのSSRCを変更した場合、XRメッセージヘッダーのSSRCを更新する必要があります。レポートブロックのSSRC識別子に関してSR / RRに与えられた同じガイドラインが、XRメッセージのすべてのレポートブロックタイプにも適用されます。 B2BUAがRTPパケットの転送時にベースRTPシーケンス番号も変更した場合、この変更は、XR仕様の一部であるほとんどのレポートブロックタイプで使用可能な「begin_seq」および「end_seq」フィールドに反映される必要があります。

Receiver Summary Information (RSI) [RFC5760]: If the B2BUA has changed any SSRC of RTP streams addressed in an RSI packet, it MUST update the SSRC identifiers in the message. This includes the distribution source SSRC, which MUST be rewritten with the one the B2BUA uses to send RTP packets to each sender participant, the summarized SSRC, and when a Collision Sub-Report Block is available, the SSRCs in the related list.

受信者要約情報（RSI）[RFC5760]：B2BUAがRSIパケットでアドレス指定されたRTPストリームのSSRCを変更した場合、メッセージ内のSSRC識別子を更新する必要があります。これには、B2BUAが各送信者の参加者にRTPパケットを送信するために使用する配布ソースSSRC、要約されたSSRC、および衝突サブレポートブロックが使用可能な場合は関連リストのSSRCを使用して書き換える必要があります。

Port Mapping (TOKEN) [RFC6284]: If the B2BUA has changed any SSRC of RTP streams addressed in a TOKEN packet, it MUST update the SSRC identifiers in the message. This includes the Packet Sender SSRC, which MUST be rewritten with the one the B2BUA uses to send RTP packets to each sender participant, and the Requesting Client SSRC when the message is a response, which MUST be rewritten using the related sender participant(s) SSRC.

ポートマッピング（トークン）[RFC6284]：B2BUAがトークンパケットでアドレス指定されたRTPストリームのSSRCを変更した場合、メッセージ内のSSRC識別子を更新する必要があります。これには、B2BUAが各送信者参加者にRTPパケットを送信するために使用するもので書き換える必要があるパケット送信者SSRC、およびメッセージが応答である場合は要求側クライアントSSRCが含まれ、関連する送信者参加者を使用して書き換える必要があります。 SSRC。

Feedback Messages [RFC4585]: All Feedback messages have a common packet format, which includes the SSRC identifier of the Packet Sender and the SSRC identifier of the media source the feedback is related to. Just as described for the previous messages, these SSRC identifiers MUST be updated in the message if the B2BUA has changed the SSRC of the RTP streams addressed there. It MUST NOT, however, change a media source SSRC that was originally set to zero, unless zero is actually the SSRC that was chosen by one of the involved endpoints, in which case the above-mentioned rules as to SSRC rewriting apply. Considering that many Feedback messages also include additional data as part of their specific Feedback Control Information (FCI), a media-aware B2BUA MUST take care of them accordingly, if it can parse and regenerate them, according to the following guidelines:

フィードバックメッセージ[RFC4585]：すべてのフィードバックメッセージには共通のパケット形式があり、パケット送信者のSSRC識別子とフィードバックが関連するメディアソースのSSRC識別子が含まれます。前のメッセージで説明したように、B2BUAがそこでアドレス指定されたRTPストリームのSSRCを変更した場合、これらのSSRC識別子をメッセージで更新する必要があります。ただし、ゼロが実際に関係するエンドポイントの1つによって選択されたSSRCでない限り、元々ゼロに設定されていたメディアソースSSRCを変更してはなりません。その場合、SSRC書き換えに関する上記のルールが適用されます。多くのフィードバックメッセージには、特定のフィードバック制御情報（FCI）の一部として追加のデータも含まれていることを考慮すると、メディア対応のB2BUAは、次のガイドラインに従ってメッセージを解析および再生成できる場合、それに応じてメッセージを処理する必要があります。

NACK [RFC4585]: A media-aware B2BUA MUST properly rewrite the Packet ID (PID) of all addressed lost packets in the NACK FCI if it changed the RTP sequence numbers.

NACK [RFC4585]：メディア対応のB2BUAは、RTPシーケンス番号を変更した場合、NACK FCIでアドレス指定されたすべての失われたパケットのパケットID（PID）を適切に書き換える必要があります。

TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM [RFC5104]: A media-aware B2BUA MUST properly rewrite the additional SSRC identifier in the specific FCI if it changed the related RTP SSRC of the media sender.

TMMBR / TMMBN / FIR / TSTR / TSTN / VBCM [RFC5104]：メディア対応B2BUAは、メディアセンダーの関連するRTP SSRCを変更した場合、特定のFCIの追加のSSRC識別子を適切に書き換える必要があります。

Receiver Estimated Max Bitrate (REMB) [RTCP-REMB]: [RTCP-REMB] describes an RTCP payload-specific Feedback message that reports the receiver's available bandwidth to the sender. As of the time of this writing, REMB has been widely deployed but has not been standardized. The REMB mechanism will not function correctly across a media-aware B2BUA that changes the SSRC of the media sender unless it also changes the SSRC values in the REMB packet.

受信者推定最大ビットレート（REMB）[RTCP-REMB]：[RTCP-REMB]は、受信者の利用可能な帯域幅を送信者に報告するRTCPペイロード固有のフィードバックメッセージを記述します。この記事の執筆時点では、REMBは広く展開されていますが、標準化されていません。 REMBメカニズムは、REMBパケットのSSRC値も変更しない限り、メディア送信者のSSRCを変更するメディア対応B2BUA全体で正しく機能しません。

Explicit Congestion Notification (ECN) [RFC6679]: The same guidelines given for SR/RR management apply, considering the presence of sequence numbers in the ECN Feedback Report format. For the management of RTCP XR ECN Summary Report messages, the same guidelines given for generic XR messages apply.

明示的輻輳通知（ECN）[RFC6679]：ECNフィードバックレポート形式のシーケンス番号の存在を考慮して、SR / RR管理に与えられた同じガイドラインが適用されます。 RTCP XR ECNサマリーレポートメッセージの管理については、一般的なXRメッセージに与えられたものと同じガイドラインが適用されます。

Apart from the generic guidelines related to Feedback messages, no additional modifications are needed for Picture Loss Indication (PLI), Slice Lost Indication (SLI), and Reference Picture Selection Indication (RPSI) Feedback messages.

フィードバックメッセージに関連する一般的なガイドラインとは別に、画像損失表示（PLI）、スライス損失表示（SLI）、および参照画像選択表示（RPSI）フィードバックメッセージに追加の変更は必要ありません。

Of course, the same considerations about the need for SDP and RTP/ RTCP information to be coherent applies to media-aware B2BUAs. This means that, if a B2BUA changes any SSRC, it MUST update the related 'ssrc' attributes, if present, before sending it to the recipient. Besides, it MUST rewrite the 'rtcp' attribute if provided. At the same time, while a media-aware B2BUA is typically able to inspect/ modify RTCP messages, it may not support all RTCP messages. This means that a B2BUA may choose to drop RTCP messages it can't parse. In that case, a media-aware B2BUA MUST advertise its RTCP level of support in the SDP in a coherent way in order to prevent, for instance, a UAC from sending NACK messages that would never reach the intended recipients. It's important to point out that, in case a compound RTCP packet was received and any RTCP message in it needs to be dropped, then the B2BUA SHOULD NOT drop the whole compound RTCP packet, but only the selected messages.

もちろん、SDPとRTP / RTCPの情報を整合させる必要性に関する同じ考慮事項が、メディア対応のB2BUAにも当てはまります。これは、B2BUAがSSRCを変更する場合、受信者に送信する前に、関連する「ssrc」属性があればそれを更新する必要があることを意味します。その上、それが提供されるなら、それは「rtcp」属性を書き直さなければなりません。同時に、メディア対応のB2BUAは通常RTCPメッセージを検査/変更できますが、すべてのRTCPメッセージをサポートしているとは限りません。これは、B2BUAが解析できないRTCPメッセージをドロップすることを選択する可能性があることを意味します。その場合、メディア対応のB2BUAは、たとえば意図した受信者に到達しないNACKメッセージをUACが送信しないようにするために、SDPでのRTCPサポートのレベルを一貫した方法でアドバタイズする必要があります。複合RTCPパケットが受信され、その中のRTCPメッセージをドロップする必要がある場合、B2BUAは複合RTCPパケット全体をドロップするのではなく、選択したメッセージのみをドロップする必要があることを指摘することが重要です。

The same considerations on CNAMEs made in regard to Media Relays apply to Media-aware Relays as well. Specifically, if RTP extensions involving CNAMEs are involved (e.g., "urn:ietf:params:rtp-hdrext:sdes:cname" [RFC7941]) and negotiated because the B2BUA supports them, then the B2BUA MUST update the CNAME value in there as well, if it was changed. It is worth pointing out that, if the new CNAME is larger than the old one, this would result in a larger RTP packet than originally received. If the length of the updated packet exceeds the MTU of any of the networks the packet will traverse, this can result in the packet being dropped and lost by the recipient.

メディアリレーに関して行われたCNAMEに関する同じ考慮事項は、メディア対応リレーにも適用されます。具体的には、CNAMEを含むRTP拡張機能が関係し（たとえば、「urn：ietf：params：rtp-hdrext：sdes：cname」[RFC7941]）、B2BUAがそれらをサポートするために交渉された場合、B2BUAはそこでCNAME値を次のように更新する必要があります。まあ、それが変更された場合。新しいCNAMEが古いCNAMEより大きい場合、最初に受信したものよりも大きなRTPパケットが発生することに注意してください。更新されたパケットの長さが、パケットが通過するいずれかのネットワークのMTUを超えると、受信者がパケットをドロップして損失する可能性があります。

A different set of considerations is worthwhile for RTP/RTCP multiplexing [RFC5761] and Reduced-Size RTCP [RFC5506]. While the former allows for a better management of network resources by multiplexing RTP packets and RTCP messages over the same transport, the latter allows for a compression of RTCP messages, thus leading to less network traffic. For RTP/RTCP multiplexing, a B2BUA acting as a Media Relay may use it on either RTP session independently. This means that, for instance, a Media Relay B2BUA may use RTP/RTCP multiplexing on one side of the communication and not use it on the other side, if the endpoint does not support it. This allows for a better management of network resources on the side that does support it. In case any of the parties in the communications supports it and the B2BUA does too, the related 'rtcp-mux' SDP attribute MUST be forwarded on the other side(s). If the B2BUA detects that any of the parties in the communication do not support the feature, it may decide to either disable it entirely or still advertise it for the RTP sessions with parties that do support it. In case the B2BUA decides to involve RTP/RTCP multiplexing, it MUST ensure that there are no conflicting RTP Payload Type numbers on either side. When there are, it MUST rewrite RTP Payload Type numbers to prevent conflicts in the session where the RTP/RTCP multiplexing is applied. Should RTP Payload Types be rewritten, the related information in the SDP MUST be updated accordingly.

RTP / RTCP多重化[RFC5761]と縮小サイズRTCP [RFC5506]には、考慮すべき一連の異なる考慮事項があります。前者は同じトランスポート上でRTPパケットとRTCPメッセージを多重化することでネットワークリソースの管理を改善できますが、後者はRTCPメッセージを圧縮できるため、ネットワークトラフィックが減少します。 RTP / RTCP多重化の場合、メディアリレーとして機能するB2BUAは、どちらかのRTPセッションで独立してそれを使用できます。つまり、たとえば、メディアリレーB2BUAは、通信の一方の側でRTP / RTCP多重化を使用し、エンドポイントでサポートされていない場合は、もう一方の側では使用しない可能性があります。これにより、ネットワークリソースをサポートする側でネットワークリソースをより適切に管理できます。通信の当事者のいずれかがそれをサポートし、B2BUAもそれをサポートする場合、関連する「rtcp-mux」SDP属性を反対側で転送する必要があります。 B2BUAは、通信のいずれかの当事者が機能をサポートしていないことを検出した場合、その機能を完全に無効にするか、それをサポートする当事者とのRTPセッションにアドバタイズすることを決定できます。 B2BUAがRTP / RTCP多重化を含むことを決定した場合、どちらの側にも競合するRTPペイロードタイプ番号がないことを確認する必要があります。存在する場合は、RTP / RTCP多重化が適用されるセッションでの競合を防ぐために、RTPペイロードタイプ番号を書き換える必要があります。 RTPペイロードタイプを書き換える場合は、SDPの関連情報を適宜更新する必要があります。

For Reduced-Size RTCP, the considerations are a bit different. In fact, while a Media Relay B2BUA may choose to use it on the side that supports it and not on the side that doesn't, there are several reasons for discouraging such behaviour. While Reduced-Size allows for less network traffic related to RTCP messaging in general, this gain may lead a Reduced-Size RTCP implementation to also issue a higher rate of RTCP Feedback messages. This would result in increased RTCP traffic on the side that does not support Reduced-Size and could, as a consequence, actually be counterproductive if the available bandwidth is different on the two sides. Negotiating a session with both sides would allow the B2BUA to discover which one supports Reduced-Size and which doesn't and decide whether or not to allow the sides to independently use Reduced-Size. Should the B2BUA decide to disable the feature on all sides, which is suggested in case Reduced-Size is not supported by all parties involved, it MUST NOT advertise support for the Reduced-Size RTCP functionality on either side, by removing the 'rtcp-rsize' attribute from the SDP.

縮小サイズのRTCPの場合、考慮事項は少し異なります。実際、メディアリレーB2BUAは、サポートする側ではなくサポートする側で使用することを選択する場合がありますが、そのような動作を妨げる理由はいくつかあります。縮小サイズでは、一般にRTCPメッセージングに関連するネットワークトラフィックが少なくなりますが、この利点により、縮小サイズのRTCP実装がより高いレートのRTCPフィードバックメッセージを発行する可能性があります。これにより、Reduced-Sizeをサポートしない側のRTCPトラフィックが増加し、結果として、使用可能な帯域幅が両側で異なる場合、実際には逆効果になる可能性があります。両側でセッションをネゴシエートすると、B2BUAは、どちらが縮小サイズをサポートし、どちらが縮小サイズをサポートしないかを検出し、サイドが個別に縮小サイズを使用することを許可するかどうかを決定できます。 B2BUAがすべての側でこの機能を無効にすることを決定した場合（これは、Reduced-Sizeが関係するすべての関係者によってサポートされていない場合に推奨されます）、「rtcp- SDPのrsize '属性。

3.3. Media Terminator

3.3. メディアターミネーター

A Media Terminator B2BUA, unlike simple Media Relays and media-aware ones, is able to terminate media itself. As such, it can inspect and/or modify RTP payloads as well. This means that such components, for instance, can act as media transcoders and/or originate specific RTP media. Using the terminology in "RTP Topologies" [RFC7667], this can be seen as an RTP Media Translator. Such a topology can also be seen as a back-to-back RTP session through a middlebox, as described in Section 3.2.2 of [RFC7667]. Such a capability makes them quite different from the previously introduced B2BUA typologies. Since such a B2BUA would terminate RTP itself, it can take care of the related statistics and feedback functionality directly, with no need to simply relay any message between the participants in the multimedia session.

メディアターミネーターB2BUAは、単純なメディアリレーやメディア対応のものとは異なり、メディア自体を終端できます。そのため、RTPペイロードの検査や変更も可能です。つまり、このようなコンポーネントは、たとえば、メディアトランスコーダーとして機能したり、特定のRTPメディアを発信したりできます。「RTPトポロジ」[RFC7667]の用語を使用すると、これはRTPメディアトランスレータと見なすことができます。このようなトポロジは、[RFC7667]のセクション3.2.2で説明されているように、ミドルボックスを介したバックツーバックRTPセッションと見なすこともできます。このような機能により、以前に導入されたB2BUAの類型とはまったく異なります。このようなB2BUAはRTP自体を終了するため、マルチメディアセッションの参加者間でメッセージを単に中継する必要がなく、関連する統計およびフィードバック機能を直接処理できます。

For this reason, no specific guideline is needed to ensure a proper end-to-end RTCP behaviour in such scenarios, because most of the time, there would be no end-to-end RTCP interaction among the involved participants in the first place. Nevertheless, should any RTCP message actually need to be forwarded to another participant in the multimedia session, the same guidelines provided for the media-aware B2BUA case apply.

このため、このようなシナリオで適切なエンドツーエンドのRTCP動作を保証するための特定のガイドラインは必要ありません。ほとんどの場合、そもそも関係する参加者間でエンドツーエンドのRTCP相互作用はないためです。それでも、実際にRTCPメッセージをマルチメディアセッションの別の参加者に転送する必要がある場合は、メディア対応のB2BUAケースに提供されているものと同じガイドラインが適用されます。

For RTP/RTCP multiplexing support, the same considerations already given for the Media Relay management also apply to Media Terminators.

RTP / RTCP多重化サポートの場合、メディアリレー管理に対して既に与えられた同じ考慮事項がメディアターミネーターにも適用されます。

Some different considerations might be given as to the Reduced-Size RTCP functionality instead. In fact, in the Media Terminator case, it is safe to use the feature independently on each side, as the B2BUA would terminate RTCP. In that case, the B2BUA SHOULD advertise and negotiate support for Reduced-Size if available and MUST NOT otherwise.

代わりに、縮小サイズのRTCP機能に関して、いくつかの異なる考慮事項が与えられる場合があります。実際、メディアターミネーターの場合、B2BUAがRTCPを終了するため、この機能を両側で個別に使用しても安全です。その場合、B2BUAは、利用可能な場合、縮小サイズのサポートをアドバタイズおよびネゴシエートする必要があります（SHOULD）。

4. IANA Considerations

4. IANAに関する考慮事項

This document does not require any IANA actions.

このドキュメントでは、IANAアクションは必要ありません。

5. Security Considerations

5. セキュリティに関する考慮事項

The discussion in the previous sections on the management of RTCP messages by a B2BUA worked under the assumption that the B2BUA has actual access to the RTP/RTCP information itself. This is indeed true if we assume that plain RTP and RTCP are being handled, but they may not be once any security is enforced on RTP packets and RTCP messages by means of Secure RTP (SRTP) [RFC3711].

B2BUAによるRTCPメッセージの管理に関する前のセクションの説明は、B2BUAがRTP / RTCP情報自体に実際にアクセスできるという前提の下で機能しました。プレーンなRTPとRTCPが処理されていると仮定すると、これは確かに当てはまりますが、Secure RTP（SRTP）[RFC3711]を使用してRTPパケットとRTCPメッセージにセキュリティが適用されると、そうではない場合があります。

While typically not an issue in the Media Relay case, where RTP and RTCP packets are forwarded without any modification regardless of whether or not security is involved, this could definitely have an impact on Media-aware Relays and Media Terminator B2BUAs. As simple example, if we envisage an SRTP / Secure RTCP (SRTCP) session across a B2BUA where the B2BUA itself has no access to the keys used to secure the session, there would be no way to manipulate SRTP headers without violating the hashing on the packet. At the same time, there would be no way to rewrite the RTCP information accordingly either.

セキュリティが関係するかどうかに関係なく、RTPおよびRTCPパケットが変更なしで転送されるメディアリレーの場合は通常問題ではありませんが、これは確実にメディア対応リレーおよびメディアターミネーターB2BUAに影響を与える可能性があります。簡単な例として、B2BUA自体がセッションを保護するために使用されるキーにアクセスできないB2BUA全体でSRTP / Secure RTCP（SRTCP）セッションを想定する場合、ハッシュの違反なしにSRTPヘッダーを操作する方法はありません。パケット。同時に、それに応じてRTCP情報を書き換える方法もありません。

For this reason, it is important to point out that the operations described in the previous sections are only possible if the B2BUA has a way to effectively manipulate the packets and messages flowing by. This means that, when media security is involved, only the Media Relay scenario can be properly addressed. Attempting to cover Media-aware Relay and Media Termination scenarios when involving secure sessions will inevitably lead to the B2BUA acting as a man in the middle; consequently, its behaviour is unspecified and discouraged. More considerations on this are provided in [RFC7879].

このため、前のセクションで説明した操作は、B2BUAが通過するパケットとメッセージを効果的に操作する方法を備えている場合にのみ可能であることを指摘することが重要です。これは、メディアセキュリティが関係している場合、メディアリレーシナリオのみが適切に対処できることを意味します。安全なセッションを含むときにメディア対応のリレーとメディア終了のシナリオをカバーしようとすると、必然的にB2BUAが中間者として機能することになります。その結果、その動作は不特定であり、推奨されません。これに関するより多くの考慮事項は[RFC7879]で提供されています。

It is also worth pointing out that there are scenarios where an improper management of RTCP messaging across a B2BUA may lead, willingly or not, to situations not unlike an attack. As a simple example, improper management of an REMB Feedback message containing, e.g., information on the limited bandwidth availability for a user, may lead to missing or misleading information to its peer. This may cause the peer to increase the encoder bitrate, maybe up to a point where a user with poor connectivity will inevitably be choked by an amount of data it cannot process. This scenario may thus result in what looks like a Denial-of-Service (DoS) attack towards the user.

また、B2BUA全体でのRTCPメッセージングの不適切な管理が、喜んでかどうかにかかわらず、攻撃とは異なる状況につながる可能性があるシナリオがあることも指摘する価値があります。簡単な例として、たとえばユーザーの帯域幅の制限に関する情報を含むREMBフィードバックメッセージの不適切な管理は、ピアへの情報の欠落または誤解を招く可能性があります。これにより、ピアがエンコーダのビットレートを上げる可能性があり、接続が不十分なユーザーが、処理できないデータの量によって必然的に窒息するポイントまで上昇する可能性があります。したがって、このシナリオでは、ユーザーに対するサービス拒否（DoS）攻撃のように見える可能性があります。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.

[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。

[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.

[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<http://www.rfc-editor.org / info / rfc3264>。

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

[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <http://www.rfc-editor.org/info/rfc3611>.

[RFC3611]フリードマン、T。、編、カセレス、R、編、およびA.クラーク、編、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、DOI 10.17487 / RFC3611、2003年11月、 <http://www.rfc-editor.org/info/rfc3611>。

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.

[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<http://www.rfc-editor.org/ info / rfc4566>。

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

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

[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, <http://www.rfc-editor.org/info/rfc5506>.

[RFC5506] Johansson、I。およびM. Westerlund、「Reduced-Size Real-Time Transport Control Protocol（RTCP）：Opportunities and Consequences」、RFC 5506、DOI 10.17487 / RFC5506、2009年4月、<http：// www .rfc-editor.org / info / rfc5506>。

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

[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <http://www.rfc-editor.org/info/rfc5761>.

[RFC5761] Perkins、C。およびM. Westerlund、「Multiplexing RTP Data and Control Packets on a Single Port」、RFC 5761、DOI 10.17487 / RFC5761、2010年4月、<http://www.rfc-editor.org/info / rfc5761>。

[RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping between Unicast and Multicast RTP Sessions", RFC 6284, DOI 10.17487/RFC6284, June 2011, <http://www.rfc-editor.org/info/rfc6284>.

[RFC6284] Begen、A.、Wing、D。、およびT. Van Caenegem、「ユニキャストとマルチキャストRTPセッション間のポートマッピング」、RFC 6284、DOI 10.17487 / RFC6284、2011年6月、<http：//www.rfc- editor.org/info/rfc6284>。

[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <http://www.rfc-editor.org/info/rfc6679>.

[RFC6679] Westerlund、M.、Johansson、I.、Perkins、C.、O'Hanlon、P。、およびK. Carlberg、「RTP over UDPの明示的輻輳通知（ECN）」、RFC 6679、DOI 10.17487 / RFC6679 、2012年8月、<http://www.rfc-editor.org/info/rfc6679>。

[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, <http://www.rfc-editor.org/info/rfc7022>.

[RFC7022] Begen、A.、Perkins、C.、Wing、D。、およびE. Rescorla、「RTP制御プロトコル（RTCP）正規名（CNAME）の選択に関するガイドライン」、RFC 7022、DOI 10.17487 / RFC7022、2013年9月、<http://www.rfc-editor.org/info/rfc7022>。

[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.

[RFC7656] Lennox、J.、Gross、K.、Nandakumar、S.、Salgueiro、G。、およびB. Burman、編、「リアルタイムの転送プロトコル（RTP）ソースのセマンティクスとメカニズムの分類法」、 RFC 7656、DOI 10.17487 / RFC7656、2015年11月、<http://www.rfc-editor.org/info/rfc7656>。

[RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items", RFC 7941, DOI 10.17487/RFC7941, August 2016, <http://www.rfc-editor.org/info/rfc7941>.

[RFC7941] Westerlund、M.、Burman、B.、Even、R。、およびM. Zanaty、「RTP Control Protocol（RTCP）Source Description ItemsのRTPヘッダー拡張」、RFC 7941、DOI 10.17487 / RFC7941、2016年8月、<http://www.rfc-editor.org/info/rfc7941>。

6.2. Informative References

6.2. 参考引用

[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, <http://www.rfc-editor.org/info/rfc3605>.

[RFC3605] Huitema、C。、「Session Description Protocol（SDP）のReal Time Control Protocol（RTCP）属性」、RFC 3605、DOI 10.17487 / RFC3605、2003年10月、<http://www.rfc-editor.org/ info / rfc3605>。

[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.ノーマン、「The Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、March 2004、<http://www.rfc-editor.org/info/rfc3711>。

[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <http://www.rfc-editor.org/info/rfc5576>.

[RFC5576] Lennox、J.、Ott、J。、およびT. Schierl、「Session Description Protocol（SDP）のソース固有のメディア属性」、RFC 5576、DOI 10.17487 / RFC5576、2009年6月、<http：// www.rfc-editor.org/info/rfc5576>。

[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, <http://www.rfc-editor.org/info/rfc7092>.

[RFC7092] Kaplan、H。およびV. Pascual、「A Taxonomy of Session Initiation Protocol（SIP）Back-to-Back User Agents」、RFC 7092、DOI 10.17487 / RFC7092、2013年12月、<http：//www.rfc -editor.org/info/rfc7092>。

[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <http://www.rfc-editor.org/info/rfc7667>.

[RFC7667] Westerlund、M。およびS. Wenger、「RTPトポロジ」、RFC 7667、DOI 10.17487 / RFC7667、2015年11月、<http://www.rfc-editor.org/info/rfc7667>。

[RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, <http://www.rfc-editor.org/info/rfc7879>.

[RFC7879] Ravindranath、R.、Reddy、T.、Salgueiro、G.、Pascual、V。、およびP. Ravindran、「SIPバックツーバックユーザーエージェントでのDTLS-SRTP処理」、RFC 7879、DOI 10.17487 / RFC7879、2016年5月、<http://www.rfc-editor.org/info/rfc7879>。

[RTCP-REMB] Alvestrand, H., Ed., "RTCP message for Receiver Estimated Maximum Bitrate", Work in Progress, draft-alvestrand-rmcat-remb-03, October 2013.

[RTCP-REMB] Alvestrand、H.、Ed。、「RTCP message for Receiver Estimated Maximum Bitrate」、Work in Progress、draft-alvestrand-rmcat-remb-03、2013年10月。

Acknowledgements

謝辞

The authors would like to thank Flavio Battimo and Pierluigi Palma for their invaluable feedback in the early stages of this document. The authors would also like to thank Colin Perkins, Bernard Aboba, Albrecht Schwarz, Hadriel Kaplan, Keith Drage, Jonathan Lennox, Stephen Farrell, Magnus Westerlund, Simon Perreault, and Ben Campbell for their constructive comments, suggestions, and reviews that were critical to the formulation and refinement of this document.

著者は、このドキュメントの初期の段階で貴重なフィードバックを提供してくれたFlavio BattimoとPierluigi Palmaに感謝します。著者はまた、建設的なコメント、提案、および批判的であったレビューについて、コリンパーキンス、バーナードアボバ、アルブレヒトシュワルツ、ハドリエルカプラン、キースドラジェ、ジョナサンレノックス、スティーブンファレル、マグナスウェスタールンド、サイモンペロール、ベンキャンベルに感謝します。このドキュメントの作成と改良。

Authors' Addresses

著者のアドレス

Lorenzo Miniero Meetecho

ロレンツォミニエロミーテチョ

   Email: lorenzo@meetecho.com

Sergio Garcia Murillo Medooze

セルジオガルシアムリーリョメドゥーズ

   Email: sergio.garcia.murillo@gmail.com

Victor Pascual Oracle

ビクターパスクアルオラクル

   Email: victor.pascual.avila@oracle.com