[要約] RFC 8858は、SDPを使用してRTPとRTCPのマルチプレクシングの独占サポートを示すための標準です。このRFCの目的は、SDPを介して通信セッションでのRTPとRTCPの効率的なマルチプレクシングを可能にすることです。

Internet Engineering Task Force (IETF)                       C. Holmberg
Request for Comments: 8858                                      Ericsson
Updates: 5761                                               January 2021
Category: Standards Track
ISSN: 2070-1721
        

Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)

セッション記述プロトコル(SDP)を用いたRTPおよびRTP制御プロトコル(RTCP)多重化の排他的サポートを示す(SDP)

Abstract

概要

This document defines a new Session Description Protocol (SDP) media-level attribute, 'rtcp-mux-only', that can be used by an endpoint to indicate exclusive support of RTP and RTP Control Protocol (RTCP) multiplexing. The document also updates RFC 5761 by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports.

この文書は、RTPおよびRTP制御プロトコル(RTCP)多重化の排他的なサポートを示すために、エンドポイントで使用できる新しいセッション記述プロトコル(SDP)メディアレベル属性 'RTCP-MUX専用'を定義します。また、オファーがメカニズムを使用して、別々のポートでRTCPを送受信できないことを示すことができることを明確にすることで、この文書はRFC 5761を更新します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはインターネット規格のトラック文書です。

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

この文書は、インターネットエンジニアリングタスクフォース(IETF)の製品です。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 https://www.rfc-editor.org/info/rfc8858.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8858で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2021 IETF信頼と文書著者として識別された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.

この文書は、この文書の公開日に有効なIETF文書(https://truste.ietf.org/License-info)に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。

Table of Contents

目次

   1.  Introduction
   2.  Conventions
   3.  SDP 'rtcp-mux-only' Attribute
   4.  SDP Offer/Answer Procedures
     4.1.  General
     4.2.  Generating the Initial SDP Offer
     4.3.  Generating the Answer
     4.4.  Offerer Processing of the SDP Answer
     4.5.  Modifying the Session
   5.  Update to RFC 5761
     5.1.  General
     5.2.  Update to 4th Paragraph of Section 5.1.1
     5.3.  Update to 2nd Paragraph of Section 5.1.3
   6.  ICE Considerations
   7.  Security Considerations
   8.  IANA Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Author's Address
        
1. Introduction
1. はじめに

[RFC5761] defines how to multiplex RTP and RTCP on a single IP address and port, referred to as RTP/RTCP multiplexing. [RFC5761] also defines an SDP [RFC4566] attribute, 'rtcp-mux', that can be used by entities to indicate support of RTP/RTCP multiplexing and negotiate usage of it.

[RFC5761] RTP / RTCP多重化と呼ばれる単一のIPアドレスとポートでRTPとRTCPをマルチプレックスする方法を定義します。[RFC5761] RTP / RTCP多重化のサポートを示すためにエンティティで使用できるSDP [RFC4566]属性「RTCP-MUX」も定義します。

As defined in [RFC5761], if the peer endpoint does not support RTP/ RTCP multiplexing, both endpoints should use separate ports for sending and receiving of RTCP (referred to as fallback to usage of separate ports for RTP and RTCP).

[RFC5761]で定義されているように、ピアエンドポイントがRTP / RTCP多重化をサポートしていない場合、両方のエンドポイントはRTCPを送受信するための別々のポート(RTPおよびRTCPのための別々のポートのフォールバックと呼ばれます)を使用してください。

Some newer applications that do not require backward compatibility with peers that cannot multiplex RTCP might choose not to implement separation of RTP and RTCP. Examples of such applications are W3C WebRTC applications [WebRTC], which are not required to interoperate with non-WebRTC clients. For such applications, this document defines an SDP attribute to signal intent to require multiplexing. The use of this attribute in SDP offers [RFC3264] may harm the interoperability of entities that ever need to interoperate with peers that do not support RTC/RTCP multiplexing. Also, while the SDP answerer [RFC3264] might support, and prefer usage of, fallback to nonmultiplex, the attribute indicates that fallback to nonmultiplex cannot be enabled. One example of where nonmultiplex is preferred is where an endpoint is connected to a radio interface and wants to use different bearers (possibly with different quality characteristics) for RTP and RTCP. Another example is where one endpoint is acting as a gateway to a network where RTP/RTCP multiplexing cannot be used. In such a case, the endpoint may also prefer nonmultiplexing towards the other network. Otherwise, the endpoint would have to perform demultiplexing of RTP and RTCP.

RTCPを多重化できないピアとの下位互換性を必要としないいくつかの新しいアプリケーションは、RTPとRTCPの分離を実装しないことを選択できます。そのようなアプリケーションの例は、W3C WebRTCアプリケーション[WEBRTC]で、非WebRTCクライアントと相互運用する必要はありません。そのようなアプリケーションでは、このドキュメントは、多重化を要求する意図を送信するためのSDP属性を定義します。 SDPオファー[RFC3264]でこの属性を使用すると、RTC / RTCP多重化をサポートしていないピアと相互運用する必要があるエンティティの相互運用性を損なうことがあります。また、SDP回答者[RFC3264]がサポートされており、Uncultiplexへのフォールバックを優先しても、非マルチプレックスへのフォールバックを有効にすることはできません。 NonMultiplexが好ましい場合の一例は、エンドポイントが無線インターフェースに接続され、RTPおよびRTCPのための異なるベアラ(おそらく異なる品質特性)を使用したい場所である。もう1つの例は、RTP / RTCP多重化が使用できないネットワークへのゲートウェイとしてあるエンドポイントが1つのエンドポイントが機能している場合です。そのような場合、エンドポイントはまた、他のネットワークに向かって非多重化を好むことができる。それ以外の場合、エンドポイントはRTPとRTCPの逆多重化を実行する必要があります。

This document defines a new SDP media-level attribute, 'rtcp-mux-only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates [RFC5761] by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports.

このドキュメントは、RTP / RTCP多重化の排他的サポートを示すために、エンドポイントで使用できる新しいSDPメディアレベル属性 'RTCP-MUX-ONY'を定義します。また、オファーがメカニズムを使用できないことを明確にして、別々のポートでRTCPを送受信できないことを明確にすることで、この文書も更新します[RFC5761]。

This document also describes the Interactive Connectivity Establishment (ICE) [RFC8445] considerations when indicating exclusive support of RTP/RTCP multiplexing.

この文書では、RTP / RTCP多重化の排他的サポートを示す際の対話型接続確立(ICE)[RFC8445]に関する考慮事項についても説明します。

2. Conventions
2. 規約

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきです。

3. SDP 'rtcp-mux-only' Attribute
3. SDP 'RTCP-MUX専用'属性

This section defines a new SDP media-level attribute, 'rtcp-mux-only'.

このセクションでは、新しいSDPメディアレベルの属性 'RTCP-MUX-Only'を定義します。

Name: rtcp-mux-only

名前:RTCP-MUX専用です

Value: N/A

値:N / A.

Usage Level: media

使用レベル:メディア

Charset Dependent: no

文字セットに依存する:いいえ

Syntax: rtcp-mux-only

構文:RTCP-MUX専用です

Example: a=rtcp-mux-only

例:A = RTCP-MUX専用です

In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute to indicate exclusive support of RTP/RTCP multiplexing for the RTP-based media associated with the SDP media description ("m=" line).

SDPオファーでは、オファーはSDP 'RTCP-MUX only'属性を使用して、SDPメディア記述に関連付けられているRTPベースのメディアのRTP / RTCP多重化の排他的サポートを示します( "m ="行)。

In an SDP answer, the 'rtcp-mux' attribute [RFC5761] indicates that the answerer supports, and accepts usage of, RTP/RTCP multiplexing for the RTP-based media associated with the SDP media description ("m=" line).

SDPの回答では、 'RTCP-MUX'属性[RFC5761]は、回答者がSDPメディア記述に関連付けられているRTPベースのメディアのRTP / RTCP多重化をサポートしていることを示します( "m ="行)。

The usage of the 'rtcp-mux-only' attribute in an SDP answer is forbidden.

SDP回答の「rtcp-mux-only」属性の使用法は禁止されています。

The usage of the SDP 'rtcp-mux-only' attribute is only defined for RTP-based media.

SDP 'rtcp-mux-only'属性の使用法は、RTPベースのメディアに対してのみ定義されています。

The mux category [RFC8859] for the 'rtcp-mux-only' attribute is "IDENTICAL", which means that the attribute, if used within a BUNDLE group [RFC8843], must be associated with all multiplexed RTP-based media descriptions within the BUNDLE group.

'rtcp-mux-only'属性のMUXカテゴリ[RFC8859]は「同一」です。これは、バンドルグループ[RFC8843]内で使用されている場合、属性がすべての多重化されたRTPベースのメディアの説明に関連付けられている必要があります。バンドルグループ。

The 'rtcp-mux-only' attribute applies to the whole associated media description. The attribute MUST NOT be defined per source (using the SDP 'ssrc' attribute [RFC5576]).

'rtcp-mux-only'属性は、関連付けられているメディアの説明全体に適用されます。属性はソースごとに定義してはいけません(SDP 'SSRC'属性[RFC5576])。

The SDP offer/answer procedures [RFC3264] associated with the attribute are defined in Section 4.

属性に関連付けられているSDPオファー/アンサープロシージャ[RFC3264]はセクション4で定義されています。

4. SDP Offer/Answer Procedures
4. SDPオファー/アンサープロシージャー
4.1. General
4.1. 一般

This section defines the SDP offer/answer procedures [RFC3264] for indicating exclusive support of RTP/RTCP multiplexing and negotiating usage of it.

このセクションでは、RTP / RTCP多重化とその使用をネゴシエーションするためのSDPオファー/アンサープロシージャ[RFC3264]を定義します。

The procedures in this section apply to individual RTP-based SDP media descriptions ("m=" lines).

このセクションの手順は、個々のRTPベースのSDPメディアの説明( "m ="行)に適用されます。

4.2. Generating the Initial SDP Offer
4.2. 初期SDPオファーの生成

When sending the initial offer, if the offerer wants to indicate exclusive RTP/RTCP multiplexing for RTP-based media, it MUST associate an SDP 'rtcp-mux-only' attribute with the associated SDP media description ("m=" line).

最初のオファーを送信するとき、オファーがRTPベースのメディアの排他的なRTP / RTCP多重化を示す場合は、SDP 'RTCP-MUX only'属性を関連するSDPメディア記述( "m ="行)に関連付ける必要があります。

In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line), the offerer MUST also associate an SDP 'rtcp-mux' attribute with the same SDP media description ("m=" line), following the procedures in [RFC5761].

さらに、オファーがSDPの「RTCP-MUX only」属性をSDPのメディア記述( "m ="行)に関連付ける場合、オファーはSDP 'rtcp-mux'属性を同じSDPメディアの説明に関連付ける必要があります([RFC5761]の手順に従って、「M =」行)。

If the offerer associates an SDP 'rtcp' attribute [RFC3605] with an SDP media description ("m=" line), and if the offerer also associates an SDP 'rtcp-mux-only' attribute with the same SDP media description ("m=" line), the address and port values of the SDP 'rtcp' attribute MUST match the corresponding values for RTP.

オファーがSDP 'RTCP'属性[RFC3605]をSDPメディア記述( "m ="行)に関連付け、オファーがSDP 'RTCP-MUX only'属性を同じSDPメディアの説明に関連付ける場合)M = "Line)、SDP 'RTCP'属性のアドレスとポート値は、RTPの対応する値と一致する必要があります。

NOTE: This specification does not mandate the usage of the SDP 'rtcp' attribute for RTP/RTCP multiplexing.

注:この仕様は、RTP / RTCP多重化のためのSDP 'RTCP'属性の使用法を義務付けていません。

4.3. Generating the Answer
4.3. 答えを生成する

When an answerer receives an offer that contains an SDP 'rtcp-mux-only' attribute associated with an RTP-based SDP media description ("m=" line), then if the answerer accepts the usage of RTP/RTCP multiplexing, it MUST associate an SDP 'rtcp-mux' attribute with the corresponding SDP media description ("m=") in the associated answer, following the procedures in [RFC5761]. If the answerer does not accept the usage of RTP/RTCP multiplexing, it MUST either reject the SDP media description ("m=") by setting the port value to zero in the associated answer, or reject the whole offer, following the procedures in [RFC3264].

回答者がRTPベースのSDPメディア記述(「M =」行)に関連付けられたSDP 'RTCP-MUX-only'属性を含むオファーを受信すると、回答者がRTP / RTCP多重化の使用を受け入れる場合は、[RFC5761]の手順に従って、関連付けられている回答に、関連付けられている回答のSDP 'rtcp-mux'属性を関連付けられている答えに関連付けます。回答者がRTP / RTCP多重化の使用を受け入れない場合は、プロシージャの後に、ポート値をゼロに設定するか、またはオファー全体を拒否することによって、SDPメディア記述( "m =")を拒否する必要があります。[RFC3264]。

The answerer MUST NOT associate an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line) in the answer.

回答者は、SDPの「rtcp-mux-only」属性を答えにSDPメディア記述( "m ="行)に関連付けてはいけません。

4.4. Offerer Processing of the SDP Answer
4.4. SDP回答の提供者の処理

If an offerer associated an SDP 'rtcp-mux-only' attribute with an RTP-based SDP media description ("m=" line) in an offer, and if the corresponding SDP media description ("m=" line) in the associated answer contains an SDP 'rtcp-mux' attribute, the offerer MUST apply the RTP/RTCP multiplexing procedures [RFC5761] to the associated RTP-based media. If the corresponding SDP media description ("m=" line) in the associated answer does not contain an SDP 'rtcp-mux' attribute, the offerer MUST either take appropriate actions in order to disable the associated RTP-based media -- e.g., send a new offer with a zero port value associated with the SDP media description ("m=" line) -- or send a new offer without associating an SDP 'rtcp-mux-only' attribute with the SDP media description ("m=" line).

オファーのRTPベースのSDPメディア記述( "m ="行)で提供者が提供している場合、および関連する対応するSDPメディア記述( "m =" line)が関連付けられている場合回答にはSDP 'RTCP-MUX'属性が含まれているため、オファーはRTP / RTCP多重化手順[RFC5761]を関連するRTPベースのメディアに適用する必要があります。関連付けられている回答内の対応するSDPメディア記述( "m ="行)にSDP 'RTCP-MUX'属性が含まれていない場合、オファーは関連するRTPベースのメディアを無効にするために適切なアクションを取る必要があります。SDPメディア記述( "m ="行)に関連付けられているゼロポート値で新しいオファーを送信するか、SDP 'RTCP-MUX only'属性をSDPメディアの説明に関連付けずに新しいオファーを送信する( "m ="線)

NOTE: This document does not mandate specific actions on how to terminate the RTP media. The offerer might, for example, terminate the RTP media by sending a new offer in which the port value of the SDP media description is set to zero.

注:このドキュメントは、RTPメディアを終了する方法についての特定のアクションを義務付けません。例えば、提供者は、例えば、SDPメディア記述のポート値がゼロに設定されている新しいオファーを送信することによってRTPメディアを終了する可能性があります。

4.5. Modifying the Session
4.5. セッションを変更する

When an offerer sends a subsequent offer, if the offerer and answerer have previously negotiated usage of exclusive RTP/RTCP multiplexing for the media associated with an RTP-based SDP media description ("m=" line), the offerer SHOULD associate an SDP 'rtcp-mux-only' with the corresponding SDP media description ("m=" line).

オファーが後続のオファーを送信すると、オファーと回答者が以前にRTPベースのSDPメディア記述に関連付けられているメディアのための排他的RTP / RTCP多重化の使用を以前にネゴシエートされた場合( "m ="行)、オファーはSDP 'を関連付けるべきです対応するSDPメディア記述を使用したRTCP-MUX専用 '( "m ="行)。

In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line), the offerer MUST also associate an SDP 'rtcp-mux' attribute with the same SDP media description ("m=" line), following the procedures in [RFC5761].

さらに、オファーがSDPの「RTCP-MUX only」属性をSDPのメディア記述( "m ="行)に関連付ける場合、オファーはSDP 'rtcp-mux'属性を同じSDPメディアの説明に関連付ける必要があります([RFC5761]の手順に従って、「M =」行)。

If the offerer does not associate the attributes with the corresponding SDP media description ("m=" line), it is an indication that the offerer no longer wants to use RTP/RTCP multiplexing and instead MUST fall back to usage of separate ports for RTP and RTCP once the offer has been accepted by the answerer.

オファーが対応するSDPメディア記述( "m ="行)に属性を関連付けない場合は、オファーがRTP / RTCP多重化を使用したくなく、代わりにRTPの別のポートの使用に戻る必要があります。申し出が回答者によって受け入れられたらRTCP。

When an offerer sends a subsequent offer, if the offerer and answerer have not previously negotiated usage of RTP/RTCP multiplexing for the media associated with an RTP-based SDP media description ("m=" line), the offerer MAY indicate exclusive support of RTP/RTCP multiplexing, following the procedures in Section 4.2. The offerer MUST process the associated answer following the procedures in Section 4.4.

オファーが後続のオファーを送信すると、オファーと回答者がRTPベースのSDPメディア記述に関連付けられているメディアのRTP / RTCP多重化の使用を以前にネゴシエートされていない場合(「M =」回線)、オファーはの排他的なサポートを示している可能性があります。4.2節の手順に従って、RTP / RTCP多重化。オファーは、4.4項の手順に従って関連付けられた答えを処理する必要があります。

It is RECOMMENDED to not switch between usage of RTP/RTCP multiplexing and usage of separate ports for RTP and RTCP in a subsequent offer, unless there is a use case that mandates it.

それを義務付けるユースケースがない限り、RTP / RTCP多重化とRTPとRTCPのための別々のポートの使用の使用を切り替えることは推奨されます。

5. Update to RFC 5761
5. RFC 5761に更新されます
5.1. General
5.1. 一般

This section updates Sections 5.1.1 and 5.1.3 of [RFC5761] by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports, and that the offerer shall terminate the affected streams if the answerer does not indicate support of RTP/RTCP multiplexing. It also clarifies that, when the offerer is not able to send and receive RTCP on separate ports, the offerer will not provide an SDP 'candidate' attribute for RTCP, nor will the offerer provide a fallback port for RTCP (using the SDP 'rtcp' attribute).

このセクションは、オファーが別々のポートでRTCPを送受信できないことを示すメカニズムを使用できるようにすることで、オファーを使用できるようにすることができ、オファーが影響を受けるストリームを終了することを明確にすることで、[RFC5761]のセクション5.1.1および5.1.3を更新します。回答者はRTP / RTCP多重化のサポートを示さない。また、オファーが別々のポートでRTCPを送受信できない場合、オファーはRTCPのSDP ''候補 '属性を提供しません。また、オファーはRTCPのフォールバックポートを提供しません(SDP' RTCPを使用して)。'属性)。

5.2. Update to 4th Paragraph of Section 5.1.1
5.2. セクション5.1.1の4段落に更新されます

NOTE: [RFC8035] also updates Section 5.1.1 of [RFC5761]. While the paragraph updated in this document is not updated by [RFC8035], the location of the paragraph within Section 5.1.1 is moved.

注:[RFC8035] [RFC5761]の[5.1.1]を更新します。この文書で更新された段落は[RFC8035]によって更新されていないが、セクション5.1.1内の段落の場所が移動されます。

OLD TEXT:

古いテキスト:

   |  If the answer does not contain an "a=rtcp-mux" attribute, the
   |  offerer MUST NOT multiplex RTP and RTCP packets on a single port.
   |  Instead, it should send and receive RTCP on a port allocated
   |  according to the usual port-selection rules (either the port pair,
   |  or a signalled port if the "a=rtcp:" attribute [10] is also
   |  included).  This will occur when talking to a peer that does not
   |  understand the "a=rtcp-mux" attribute.
        

NEW TEXT:

新しいテキスト:

   |  If the answer does not contain an "a=rtcp-mux" attribute, the
   |  offerer MUST NOT multiplex RTP and RTCP packets on a single port.
   |  Instead, it should send and receive RTCP on a port allocated
   |  according to the usual port-selection rules (either the port pair,
   |  or a signaled port if the "a=rtcp:" attribute [10] is also
   |  included).  This will occur when talking to a peer that does not
   |  understand the "a=rtcp-mux" attribute.  However, if the offerer
   |  indicated in the offer that it is not able to send and receive
   |  RTCP on a separate port, the offerer MUST disable the media
   |  streams associated with the attribute.  The mechanism for
   |  indicating that the offerer is not able to send and receive RTCP
   |  on a separate port is outside the scope of this specification.
        
5.3. Update to 2nd Paragraph of Section 5.1.3
5.3. セクション5.1.3の第2段落に更新されます

OLD TEXT:

古いテキスト:

   |  If it is desired to use both ICE and multiplexed RTP and RTCP, the
   |  initial offer MUST contain an "a=rtcp-mux" attribute to indicate
   |  that RTP and RTCP multiplexing is desired and MUST contain
   |  "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:"
   |  line indicating a fallback port for RTCP in the case that the
   |  answerer does not support RTP and RTCP multiplexing.  This MUST be
   |  done for each media where RTP and RTCP multiplexing is desired.
        

NEW TEXT:

新しいテキスト:

   |  If it is desired to use both ICE and multiplexed RTP and RTCP, the
   |  initial offer MUST contain an "a=rtcp-mux" attribute to indicate
   |  that RTP and RTCP multiplexing is desired and MUST contain
   |  "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:"
   |  line indicating a fallback port for RTCP in the case that the
   |  answerer does not support RTP and RTCP multiplexing.  This MUST be
   |  done for each media where RTP and RTCP multiplexing is desired.
   |  However, if the offerer indicates in the offer that it is not able
   |  to send and receive RTCP on a separate port, the offerer MUST NOT
   |  include "a=candidate:" lines for RTCP and MUST NOT provide a
   |  fallback port for RTCP using the "a=rtcp:" line.
        
6. ICE Considerations
6. 氷の考慮事項

As defined in [RFC8445], if an entity is aware that the remote peer supports, and is willing to use, RTP/RTCP multiplexing, the entity will only provide RTP candidates (component ID 1). However, only providing RTP candidates does not, as such, imply exclusive support of RTP/RTCP multiplexing. RTCP candidates also would not be provided in cases where RTCP is not supported at all. Therefore, additional information is needed in order to indicate support of exclusive RTP/ RTCP multiplexing. This document defines such a mechanism using the SDP 'rtcp-mux-only' attribute.

[RFC8445]で定義されているように、エンティティがリモートピアがサポートしていることを認識しており、使用したいと思っている場合は、RTP / RTCP多重化、entityはRTP候補のみを提供します(コンポーネントID 1)。ただし、RTP候補を提供するだけではなく、RTP / RTCP多重化の排他的なサポートを意味します。RTCP候補は、RTCPがまったくサポートされていない場合には提供されません。したがって、排他的RTP / RTCP多重化のサポートを示すためには、追加情報が必要です。このドキュメントは、SDP 'RTCP-MUX-only'属性を使用しているそのようなメカニズムを定義します。

7. Security Considerations
7. セキュリティに関する考慮事項

This document does not introduce new security considerations beyond those specified in [RFC3605] and [RFC5761].

この文書では、[RFC3605]と[RFC5761]で指定されたものを超えて新しいセキュリティ上の考慮事項を導入していません。

8. IANA Considerations
8. IANAの考慮事項

This document updates the "Session Description Protocol Parameters" registry as specified in Section 8.2.4 of [RFC4566]. Specifically, it adds the SDP 'rtcp-mux-only' attribute to the table for SDP media-level attributes.

[RFC4566]のセクション8.2.4で指定されている「セッション記述プロトコルパラメータ」レジストリを更新します。具体的には、SDPのメディアレベルの属性の表にSDP 'RTCP-MUX専用'属性を追加します。

Attribute name: rtcp-mux-only

属性名:RTCP-MUX専用

Type of attribute: media-level

属性の種類:メディアレベル

Subject to charset: no

文字セットの対象:NO

Purpose: Indicate exclusive support of RTP/RTCP multiplexing

目的:RTP / RTCP多重化の排他的サポートを示す

Appropriate Values: N/A

適切な値:N / A

Contact name: Christer Holmberg (christer.holmberg@ericsson.com)

連絡先名:Christer Holmberg(Christer.holmberg@ericsson.com)

Mux Category: IDENTICAL

MUXカテゴリ:同一です

9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献

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

[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。

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

[RFC3264] Rosenberg、J.およびH.Schulzrinne、「セッション記述プロトコル(SDP)」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https://ww.rfc-editor.org/ info / rfc3264>。

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

[RFC4566]ハンドリー、M.、Jacobson、V.、およびC.Perkins、「SDP:セッション記述プロトコル」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https://www.rfc-editor.org/情報/ RFC4566>。

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

[RFC5761] Perkins、C、M. Westerlund、 "1つのポート上のRFCのRTPデータとコントロールパケット"、RFC 5761、DOI 10.17487 / RFC5761、2010年4月、<https://www.rfc-editor.org/info/ RFC5761>。

[RFC8035] Holmberg, C., "Session Description Protocol (SDP) Offer/ Answer Clarifications for RTP/RTCP Multiplexing", RFC 8035, DOI 10.17487/RFC8035, November 2016, <https://www.rfc-editor.org/info/rfc8035>.

[RFC8035] Holmberg、C、「セッション記述プロトコル(SDP)オファー/回答の説明「RFC / RTCP多重化」、RFC 8035、DOI 10.17487 / RFC8035、2016年11月、<https://www.rfc-editor.org/情報/ RFC8035>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/RFC8174>。

[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.

[RFC8445]ケラネン、A.、Holmberg、C.、J.Rosenberg、「インタラクティブ接続施設(氷):ネットワークアドレス翻訳者のためのプロトコル」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、<https://www.rfc-editor.org/info/rfc8445>。

[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, January 2021, <https://www.rfc-editor.org/info/rfc8843>.

[RFC8843] Holmberg、C、Alvestrand、H.、およびC.ジェンニング、「セッション記述プロトコル(SDP)」、RFC 8843、DOI 10.17487 / RFC8843、<https:// www。rfc-editor.org/info/rfc8843>。

[RFC8859] Nandakumar, S., "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI 10.17487/RFC8859, January 2021, <https://www.rfc-editor.org/info/rfc8859>.

[RFC8859] Nandakumar、S。、「マルチプレクシング時のセッション記述プロトコル(SDP)属性のフレームワーク」、RFC 8859、DOI 10.17487 / RFC8859、2021年1月、<https://www.rfc-editor.org/info/rfc8859>。

9.2. Informative References
9.2. 参考引用

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

[RFC3605] HUITEMA、C、「リアルタイム制御プロトコル(SDP)」(SDP) "、RFC 3605、DOI 10.17487 / RFC3605、2003年10月、<https://ww.rfc-editor.org/情報/ RFC3605>。

[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, <https://www.rfc-editor.org/info/rfc5576>.

[RFC5576] Lennox、J.、OTT、J.、およびT.Schierl、「セッション記述プロトコル(SDP)」、RFC 5576、DOI 10.17487 / RFC5576、2009年6月、<https://のソース固有のメディア属性www.rfc-editor.org/info/rfc5576>。

[WebRTC] Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0: Real-time Communication Between Browsers", W3C Proposed Recommendation, <https://www.w3.org/TR/webrtc/>.

[WEBRTC]ジェニングニング、C、Boström、H.、およびJ-I。Bruaroey、 "WebRTC 1.0:ブラウザ間のリアルタイム通信"、W3Cは推奨事項、<https://www.w3.org/tr/webrtc/>を提案しました。

Acknowledgements

謝辞

Thanks to Roman Shpount, Paul Kyzivat, Ari Keränen, Bo Burman, Tomas Frankkila, and Martin Thomson for their comments and input on the document. Thanks to Francis Dupont for the GENART review.

ローマのShpount、Paul Kyzivat、ARIKeränen、Bo Burman、Tomas Frankkila、およびMartin Thomsonのコメントをおかげで、文書上で入力。Genart Reviewのためのフランシスデュポンのおかげで。

Author's Address

著者の住所

Christer Holmberg Ericsson Hirsalantie 11 FI-02420 Jorvas Finland

Christer Holmberg Ericsson Hirsalantie 11 Fi-02420 Jorvas Finland

   Email: christer.holmberg@ericsson.com