Internet Engineering Task Force (IETF) D. Hanson
Request for Comments: 9607 M. Faller
Category: Standards Track K. Maver
ISSN: 2070-1721 General Dynamics Mission Systems, Inc.
July 2024
This document describes the RTP payload format of the Secure Communication Interoperability Protocol (SCIP). SCIP is an application-layer protocol that provides end-to-end session establishment, payload encryption, packetization and de-packetization of media, and reliable transport. This document provides a globally available reference that can be used for the development of network equipment and procurement of services that support SCIP traffic. The intended audience is network security policymakers; network administrators, architects, and original equipment manufacturers (OEMs); procurement personnel; and government agency and commercial industry representatives.
このドキュメントでは、安全な通信相互運用性プロトコル（SCIP）のRTPペイロード形式について説明します。SCIPは、エンドツーエンドのセッションの確立、ペイロード暗号化、パケット化とメディアのパケット化、および信頼できる輸送を提供するアプリケーション層プロトコルです。このドキュメントは、ネットワーク機器の開発とSCIPトラフィックをサポートするサービスの調達に使用できるグローバルに利用可能なリファレンスを提供します。意図した視聴者は、ネットワークセキュリティ政策立案者です。ネットワーク管理者、建築家、およびオリジナルの機器メーカー（OEM）。調達担当者;政府機関と商業産業の代表者。
This IETF specification depends upon a second technical specification that is not available publicly, namely [SCIP210]. The IETF was therefore unable to conduct a security review of that specification, independently or when carried inside Audio/Video Transport (AVT). Implementers need to be aware that the IETF hence cannot verify any of the security claims contained in this document.
このIETF仕様は、公開されていない2番目の技術仕様、つまり[SCIP210]に依存します。したがって、IETFは、独立して、またはAudio/Video Transport（AVT）内で運ばれたときに、その仕様のセキュリティレビューを実施することができませんでした。したがって、IETFはこのドキュメントに含まれるセキュリティクレームのいずれかを確認できないことに注意する必要があります。
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/rfc9607.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9607で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Key Points
2. Introduction
2.1. Conventions
2.2. Abbreviations
3. Background
4. Payload Format
4.1. RTP Header Fields
4.2. Congestion Control Considerations
4.3. Use of Augmented RTPs with SCIP
5. Payload Format Parameters
5.1. Media Subtype "audio/scip"
5.2. Media Subtype "video/scip"
5.3. Mapping to SDP
5.4. SDP Offer/Answer Considerations
6. Security Considerations
7. IANA Considerations
8. SCIP Contact Information
9. References
9.1. Normative References
9.2. Informative References
Authors' Addresses
* SCIP is an application-layer protocol that uses RTP as a transport. This document defines the SCIP media subtypes to be listed in the Session Description Protocol (SDP) and only requires a basic RTP transport channel for SCIP payloads. This basic transport channel is comparable to Clearmode as defined by [RFC4040].
* SCIPは、RTPを輸送として使用するアプリケーション層プロトコルです。このドキュメントでは、セッション説明プロトコル（SDP）にリストされるSCIPメディアサブタイプを定義し、SCIPペイロードには基本的なRTPトランスポートチャネルのみが必要です。この基本的な輸送チャネルは、[RFC4040]で定義されているClearModeに匹敵します。
* SCIP transmits encrypted traffic and does not require the use of Secure RTP (SRTP) for payload protection. SCIP also provides for reliable transport at the application layer, so it is not necessary to negotiate RTCP retransmission capabilities.
* SCIPは暗号化されたトラフィックを送信し、ペイロード保護のために安全なRTP（SRTP）を使用する必要はありません。SCIPはまた、アプリケーション層での信頼できる輸送を提供するため、RTCPの再送信機能を交渉する必要はありません。
* SCIP includes built-in mechanisms that negotiate protocol message versions and capabilities. To avoid SCIP protocol ossification (as described in [RFC9170]), it is important for middleboxes to not attempt parsing of the SCIP payload. As described in this document, such parsing serves no useful purpose.
* SCIPには、プロトコルメッセージバージョンと機能を交渉する組み込みメカニズムが含まれています。SCIPプロトコルの骨化を避けるため（[RFC9170]で説明されている）、MiddleboxがSCIPペイロードの解析を試みないことが重要です。このドキュメントで説明されているように、このような解析は有用な目的を果たしません。
* SCIP is designed to be network agnostic. It can operate over any digital link, including non-IP modem-based PSTN and ISDN. The SCIP media subtypes listed in this document were developed for SCIP to operate over RTP.
* SCIPは、ネットワーク不可知論者になるように設計されています。非IPモデムベースのPSTNおよびISDNを含むあらゆるデジタルリンクで動作できます。このドキュメントにリストされているSCIPメディアサブタイプは、SCIPがRTPを介して動作するために開発されました。
* SCIP handles packetization and de-packetization of payloads by producing encrypted media packets that are not greater than the MTU size. The SCIP payload is opaque to the network, therefore, SCIP functions as a tunneling protocol for the encrypted media, without the need for middleboxes to parse SCIP payloads. Since SCIP payloads are integrity protected, modification of the SCIP payload is detected as an integrity violation by SCIP endpoints, leading to communication failure.
* SCIPは、MTUサイズより大きくない暗号化されたメディアパケットを生成することにより、ペイロードのパケット化とパケット化を処理します。SCIPペイロードはネットワークにとって不透明であるため、SCIPは、SCIPペイロードを解析するためのミドルボックスを必要とせずに、暗号化されたメディアのトンネルプロトコルとして機能します。SCIPペイロードは整合性保護されているため、SCIPエンドポイントによる整合性違反としてSCIPペイロードの変更が検出され、通信障害につながります。
This document details usage of the "audio/scip" and "video/scip" pseudo-codecs [MediaTypes] as a secure session establishment protocol and media transport protocol over RTP.
このドキュメントでは、RTPを介した安全なセッション確立プロトコルおよびメディアトランスポートプロトコルとしての「オーディオ/SCIP」および「ビデオ/SCIP」擬似コデック[メディアタイプ]の使用について詳しく説明しています。
It discusses how:
方法について説明します：
1. encrypted audio and video codec payloads are transported over RTP;
1. 暗号化されたオーディオおよびビデオコーデックペイロードは、RTPを介して輸送されます。
2. the IP network layer does not implement SCIP as a protocol since SCIP operates at the application layer in endpoints;
2. SCIPはエンドポイントのアプリケーションレイヤーで動作するため、IPネットワークレイヤーはプロトコルとしてSCIPを実装しません。
3. the IP network layer enables SCIP traffic to transparently pass through the network;
3. IPネットワークレイヤーにより、SCIPトラフィックはネットワークを透過的に通過できます。
4. some network devices do not recognize SCIP and may remove the SCIP codecs from the SDP media payload declaration before forwarding to the next network node; and finally,
4. 一部のネットワークデバイスはSCIPを認識せず、次のネットワークノードに転送する前に、SDPメディアペイロード宣言からSCIPコーデックを削除する場合があります。そして最後に、
5. SCIP endpoint devices do not operate on networks if the SCIP media subtype is removed from the SDP media payload declaration.
5. SCIPメディアサブタイプがSDPメディアペイロード宣言から削除された場合、SCIPエンドポイントデバイスはネットワークで動作しません。
The United States, along with its NATO Partners, have implemented SCIP in secure voice, video, and data products operating on commercial, private, and tactical IP networks worldwide using the scip media subtype. The SCIP data traversing the network is encrypted, and network equipment in-line with the session cannot interpret the traffic stream in any way. SCIP-based RTP traffic is opaque and can vary significantly in structure and frequency, making traffic profiling not possible. Also, as the SCIP protocol continues to evolve independently of this document, any network device that attempts to filter traffic (e.g., deep packet inspection) may cause unintended consequences in the future when changes to the SCIP traffic may not be recognized by the network device.
米国は、NATOパートナーとともに、SCIPメディアサブタイプを使用して、世界中の商業、プライベート、および戦術的なIPネットワークで動作する安全な音声、ビデオ、およびデータ製品にSCIPを実装しています。ネットワークを通過するSCIPデータは暗号化されており、セッションとインラインなネットワーク機器はトラフィックストリームをいかなる方法でも解釈できません。SCIPベースのRTPトラフィックは不透明であり、構造と頻度が大幅に異なる可能性があるため、トラフィックプロファイリングは不可能です。また、SCIPプロトコルはこのドキュメントとは無関係に進化し続けるため、SCIPトラフィックの変更がネットワークデバイスによって認識されない場合、トラフィックのフィルタリング（たとえば、パケット検査など）を試みるネットワークデバイスは、将来意図しない結果を引き起こす可能性があります。。
The SCIP protocol defined in SCIP-210 [SCIP210] includes built-in support for packetization and de-packetization, retransmission, capability exchange, version negotiation, and payload encryption. Since the traffic is encrypted, neither the RTP transport nor middleboxes can usefully parse or modify SCIP payloads; modifications are detected as integrity violations resulting in retransmission, and eventually, communication failure.
SCIP-210 [SCIP210]で定義されているSCIPプロトコルには、パケット化とパケット化、再送信、能力交換、バージョン交渉、およびペイロード暗号化のための組み込みサポートが含まれています。トラフィックは暗号化されているため、RTPトランスポートもミドルボックスもSCIPペイロードを有用に解析または変更することはできません。修正は、再送信をもたらす整合性違反として検出され、最終的にはコミュニケーションの障害が発生します。
Because knowledge of the SCIP payload format is not needed to transport SCIP signaling or media through middleboxes, SCIP-210 represents an informative reference. While older versions of the SCIP-210 specification are publicly available, the authors strongly encourage network implementers to treat SCIP payloads as opaque octets. When handled correctly, such treatment does not require referring to SCIP-210, and any assumptions about the format of SCIP messages defined in SCIP-210 are likely to lead to protocol ossification and communication failures as the protocol evolves.
SCIPのペイロード形式の知識は、SCIPシグナルまたはメディアをミドルボックスを介して輸送するために必要ではないため、SCIP-210は有益なリファレンスを表しています。SCIP-210仕様の古いバージョンは公開されていますが、著者はネットワークの実装者がSCIPペイロードを不透明なオクテットとして扱うことを強く奨励しています。正しく処理する場合、そのような治療ではSCIP-210を参照する必要はなく、SCIP-210で定義されたSCIPメッセージの形式に関する仮定は、プロトコルが進化するにつれてプロトコルの骨化と通信の障害につながる可能性があります。
Note: The IETF has not conducted a security review of SCIP and therefore has not verified the claims contained in this document.
注：IETFは、SCIPのセキュリティレビューを実施していないため、このドキュメントに含まれるクレームを確認していません。
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」、「shall」、「shill "of"、 "nove"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The best current practices for writing an RTP payload format specification, as per [RFC2736] and [RFC8088], were followed.
[RFC2736]および[RFC8088]に従って、RTPペイロード形式の仕様を作成するための最良の現在のプラクティスに従いました。
When referring to the Secure Communication Interoperability Protocol, the uppercase acronym "SCIP" is used. When referring to the media subtype scip, lowercase "scip" is used.
安全な通信相互運用性プロトコルを参照する場合、大文字の頭字語「SCIP」が使用されます。メディアサブタイプSCIPを参照する場合、小文字「SCIP」が使用されます。
The following abbreviations are used in this document.
このドキュメントでは、次の略語が使用されています。
AVP:
AVP：
Audio-Visual Profile
オーディオビジュアルプロファイル
AVPF:
AVPF：
Audio-Visual Profile with Feedback
フィードバック付きのオーディオビジュアルプロファイル
FNBDT:
fnbdt：
Future Narrowband Digital Terminal
将来のナローバンドデジタル端末
ICWG:
ICWG：
Interoperability Control Working Group
相互運用性制御ワーキンググループ
IICWG:
iicwg：
International Interoperability Control Working Group
国際相互運用性制御ワーキンググループ
MELPe:
メルペ：
Mixed Excitation Linear Prediction Enhanced
混合励起線形予測が強化されました
MTU:
MTU：
Maximum Transmission Unit
最大送信ユニット
NATO:
NATO：
North Atlantic Treaty Organization
北大西洋条約機関
OEM:
OEM：
Original Equipment Manufacturer
オリジナルの機器メーカー
SAVP:
SAVP：
Secure Audio-Visual Profile
安全なオーディオビジュアルプロファイル
SAVPF:
savpf：
Secure Audio-Visual Profile with Feedback
フィードバックを使用して、オーディオビジュアルプロファイルを保護します
SCIP:
SCIP：
Secure Communication Interoperability Protocol
安全な通信相互運用性プロトコル
SDP:
SDP：
Session Description Protocol
セッション説明プロトコル
SRTP:
SRTP：
Secure Real-time Transport Protocol
安全なリアルタイムトランスポートプロトコル
STANAG:
スタナグ：
Standardization Agreement
標準化契約
The Secure Communication Interoperability Protocol (SCIP) allows the negotiation of several voice, data, and video applications using various cryptographic suites. SCIP also provides several important characteristics that have led to its broad acceptance as a secure communications protocol.
安全な通信相互運用性プロトコル（SCIP）により、さまざまな暗号化されたスイートを使用して、いくつかの音声、データ、ビデオアプリケーションの交渉が可能になります。SCIPは、安全な通信プロトコルとしての幅広い受け入れにつながったいくつかの重要な特性も提供します。
SCIP began in the United States as the Future Narrowband Digital Terminal (FNBDT) Protocol in the late 1990s. A combined U.S. Department of Defense and vendor consortium formed a governing organization named the Interoperability Control Working Group (ICWG) to manage the protocol. In time, the group expanded to include NATO, NATO partners, and European vendors under the name International Interoperability Control Working Group (IICWG), which was later renamed the SCIP Working Group.
SCIPは、1990年代後半に将来のナローバンドデジタルターミナル（FNBDT）プロトコルとして米国で始まりました。米国国防総省とベンダーコンソーシアムの合計は、プロトコルを管理するために相互運用性コントロールワーキンググループ（ICWG）という名前の管理組織を設立しました。やがて、グループはNATO、NATOパートナー、ヨーロッパのベンダーを含むように拡大し、International Interoperability Control Working Group（IICWG）という名前で、後にSCIPワーキンググループと改名されました。
First generation SCIP devices operated on circuit-switched networks. SCIP was then expanded to radio and IP networks. The scip media subtype transports SCIP secure session establishment signaling and secure application traffic. The built-in negotiation and flexibility provided by the SCIP protocols make it a natural choice for many scenarios that require various secure applications and associated encryption suites. SCIP has been adopted by NATO in STANAG 5068. SCIP standards are currently available to participating government and military communities and select OEMs of equipment that support SCIP.
第一世代のSCIPデバイスは、サーキットスイッチネットワークで動作しました。その後、SCIPはラジオおよびIPネットワークに拡張されました。SCIPメディアサブタイプは、SCIPセッションセッションの確立シグナル伝達と安全なアプリケーショントラフィックを輸送します。SCIPプロトコルによって提供される組み込みの交渉と柔軟性は、さまざまな安全なアプリケーションと関連する暗号化スイートを必要とする多くのシナリオで自然な選択となります。SCIPはStanag 5068でNATOで採用されています。現在、SCIP基準は参加している政府および軍事コミュニティ、およびSCIPをサポートする機器のOEMを選択しています。
However, SCIP must operate over global networks (including private and commercial networks). Without access to necessary information to support SCIP, some networks may not support the SCIP media subtypes. Issues may occur simply because information is not as readily available to OEMs, network administrators, and network architects.
ただし、SCIPはグローバルネットワーク（プライベートおよび商業ネットワークを含む）で動作する必要があります。SCIPをサポートするために必要な情報にアクセスしないと、一部のネットワークはSCIPメディアサブタイプをサポートしない場合があります。情報がOEM、ネットワーク管理者、ネットワークアーキテクトが容易に利用できることがないため、問題が発生する可能性があります。
This document provides essential information about the "audio/scip" and "video/scip" media subtypes that enable network equipment manufacturers to include settings for "scip" as a known audio and video media subtype in their equipment. This enables network administrators to define and implement a compatible security policy that includes audio and video media subtypes "audio/scip" and "video/ scip", respectively, as permitted codecs on the network.
このドキュメントは、ネットワーク機器メーカーが機器の既知のオーディオおよびビデオメディアサブタイプとして「SCIP」の設定を含めることができる「オーディオ/SCIP」および「ビデオ/SCIP」メディアサブタイプに関する重要な情報を提供します。これにより、ネットワーク上のコーデックとして、それぞれオーディオおよびビデオメディアのサブタイプ「オーディオ/ SCIP」と「ビデオ/ SCIP」を含む互換性のあるセキュリティポリシーを定義および実装できます。
All current IP-based SCIP endpoints implement "scip" as a media subtype. Registration of scip as a media subtype provides a common reference for network equipment manufacturers to recognize SCIP in an SDP payload declaration.
現在のすべてのIPベースのSCIPエンドポイントは、メディアサブタイプとして「SCIP」を実装しています。SCIPのメディアサブタイプとしての登録は、ネットワーク機器メーカーがSDPペイロード宣言でSCIPを認識するための共通の参照を提供します。
The "scip" media subtype identifies and indicates support for SCIP traffic that is being transported over RTP. Transcoding, lossy compression, or other data modifications MUST NOT be performed by the network on the SCIP RTP payload. The "audio/scip" and "video/scip" media subtype data streams within the network, including the VoIP network, MUST be a transparent relay and be treated as "clear-channel data", similar to the Clearmode media subtype defined by [RFC4040].
「SCIP」メディアサブタイプは、RTPを介して輸送されているSCIPトラフィックのサポートを識別し、示しています。SCIP RTPペイロード上のネットワークによって、トランスコーディング、紛失した圧縮、またはその他のデータの変更を実行しないでください。VoIPネットワークを含むネットワーク内の「オーディオ/SCIP」および「ビデオ/SCIP」メディアサブタイプのデータストリームは、透過的なリレーであり、[クリアチャネルデータ]として扱われなければなりません。RFC4040]。
[RFC4040] is referenced because Clearmode does not define specific RTP payload content, packet size, or packet intervals, but rather enables Clearmode devices to signal that they support a compatible mode of operation and defines a transparent channel on which devices may communicate. This document takes a similar approach. Network devices that implement support for SCIP need to enable SCIP endpoints to signal that they support SCIP and provide a transparent channel on which SCIP endpoints may communicate.
[RFC4040]は、ClearModeが特定のRTPペイロードコンテンツ、パケットサイズ、またはパケット間隔を定義していないため、ClearModeデバイスが互換性のある動作モードをサポートし、デバイスが通信できる透明チャネルを定義することを信号するため、参照されます。このドキュメントは同様のアプローチを取ります。SCIPのサポートを実装するネットワークデバイスは、SCIPエンドポイントがSCIPをサポートすることを信号し、SCIPエンドポイントが通信する可能性のある透明チャネルを提供できるようにする必要があります。
SCIP is an application-layer protocol that is defined in SCIP-210. The SCIP traffic consists of encrypted SCIP control messages and codec data. The payload size and interval will vary considerably depending on the state of the SCIP protocol within the SCIP device.
SCIPは、SCIP-210で定義されているアプリケーション層プロトコルです。SCIPトラフィックは、暗号化されたSCIP制御メッセージとコーデックデータで構成されています。ペイロードサイズと間隔は、SCIPデバイス内のSCIPプロトコルの状態によって大きく異なります。
Figure 1 below illustrates the RTP payload format for SCIP.
以下の図1は、SCIPのRTPペイロード形式を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| SCIP Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SCIP RTP Payload Format
図1：SCIP RTPペイロード形式
The SCIP codec produces an encrypted bitstream that is transported over RTP. Unlike other codecs, SCIP does not have its own upper layer syntax (e.g., no Network Adaptation Layer (NAL) units), but rather encrypts the output of the audio and video codecs that it uses (e.g., G.729D, H.264 [RFC6184], etc.). SCIP achieves this by encapsulating the encrypted codec output that has been previously formatted according to the relevant RTP payload specification for that codec. SCIP endpoints MAY employ mechanisms, such as inter-media RTP synchronization as described in [RFC8088], Section 3.3.4, to synchronize "audio/scip" and "video/scip" streams.
SCIPコーデックは、RTPを介して輸送される暗号化されたビットストリームを生成します。他のコーデックとは異なり、SCIPには独自の上層構文（たとえば、ネットワーク適応レイヤー（NAL）ユニットなし）はありませんが、使用するオーディオおよびビデオコーデックの出力を暗号化します（例：G.729D、H.2644[RFC6184]など）。SCIPは、そのコーデックの関連するRTPペイロード仕様に従って以前にフォーマットされた暗号化されたコーデック出力をカプセル化することにより、これを達成します。SCIPエンドポイントは、[RFC8088]、セクション3.3.4で説明されているように、メディア間RTP同期などのメカニズムを使用して、「オーディオ/SCIP」と「ビデオ/SCIP」ストリームを同期させる場合があります。
Figure 2 below illustrates notionally how codec packets and SCIP control messages are packetized for transmission over RTP.
以下の図2は、RTPを介した送信のためにCodecパケットとSCIP制御メッセージがどのようにパケット化されるかを概念的に示しています。
+-----------+ +-----------------------+
| Codec | | SCIP control messages |
+-----------+ +-----------------------+
| |
| |
V V
+--------------------------------------------------+
| Packetizer* (<= MTU size) |
+--------------------------------------------------+
| |
| |
V |
+--------------+ |
| Encryption | |
+--------------+ |
| |
| |
V V
+--------------------------------------------------+
| RTP |
+--------------------------------------------------+
Figure 2: SCIP RTP Architecture
図2：SCIP RTPアーキテクチャ
* Packetizer:
* パケット化者：
The SCIP application layer will ensure that all traffic sent to the RTP layer will not exceed the MTU size. The receiving SCIP RTP layer will handle packet identification, ordering, and reassembly. When required, the SCIP application layer handles error detection and retransmission.
SCIPアプリケーションレイヤーは、RTPレイヤーに送信されるすべてのトラフィックがMTUサイズを超えないようにします。受信SCIP RTPレイヤーは、パケットの識別、順序、および再組み立てを処理します。必要に応じて、SCIPアプリケーションレイヤーはエラーの検出と再送信を処理します。
As described above, the SCIP RTP payload format is variable and cannot be described in specificity in this document. Details can be found in SCIP-210. SCIP will continue to evolve and, as such, the SCIP RTP traffic MUST NOT be filtered by network devices based upon what currently is observed or documented. The focus of this document is for network devices to consider the SCIP RTP payload as opaque and allow it to traverse the network. Network devices MUST NOT modify SCIP RTP packets.
上記のように、SCIP RTPペイロード形式は可変であり、このドキュメントの特異性で説明することはできません。詳細はSCIP-210にあります。SCIPは進化し続け、そのため、SCIP RTPトラフィックは、現在観察または文書化されているものに基づいてネットワークデバイスによってフィルタリングされてはなりません。このドキュメントの焦点は、ネットワークデバイスがSCIP RTPペイロードを不透明と見なし、ネットワークを通過できるようにすることです。ネットワークデバイスは、SCIP RTPパケットを変更してはなりません。
The SCIP RTP header fields SHALL conform to [RFC3550].
SCIP RTPヘッダーフィールドは[RFC3550]に準拠するものとします。
SCIP traffic may be continuous or discontinuous. The Timestamp field MUST increment based on the sampling clock for discontinuous transmission as described in [RFC3550], Section 5.1. The Timestamp field for continuous transmission applications is dependent on the sampling rate of the media as specified in the media subtype's specification (e.g., Mixed Excitation Linear Prediction Enhanced (MELPe)). Note that during a SCIP session, both discontinuous and continuous traffic are highly probable.
SCIPトラフィックは、継続的または不連続な場合があります。[RFC3550]、セクション5.1に記載されているように、不連続な伝送のサンプリングクロックに基づいて、タイムスタンプフィールドが増加する必要があります。継続的な伝送アプリケーションのタイムスタンプフィールドは、メディアサブタイプの仕様で指定されているように、メディアのサンプリングレートに依存します（たとえば、混合励起線形予測（MELPE））。SCIPセッション中に、不連続と継続的なトラフィックの両方が非常に可能性が高いことに注意してください。
The Marker bit SHALL be set to zero for discontinuous traffic. The Marker bit for continuous traffic is based on the underlying media subtype specification. The underlying media is opaque within SCIP RTP packets.
マーカービットは、不連続なトラフィックの場合はゼロに設定されます。継続的なトラフィックのマーカービットは、基礎となるメディアサブタイプの仕様に基づいています。基礎となるメディアは、SCIP RTPパケット内の不透明です。
The bitrate of SCIP may be adjusted depending on the capability of the underlying codec (such as MELPe [RFC8130], G.729D [RFC3551], etc.). The number of encoded audio frames per packet may also be adjusted to control congestion. Discontinuous transmission may also be used if supported by the underlying codec.
SCIPのビットレートは、基礎となるコーデック（MelPe [RFC8130]、G.729d [RFC3551]など）の機能に応じて調整できます。パケットあたりのエンコードされたオーディオフレームの数も、混雑を制御するように調整することもできます。基礎となるコーデックによってサポートされている場合、不連続感染を使用することもできます。
Since UDP does not provide congestion control, applications that use RTP over UDP SHOULD implement their own congestion control above the UDP layer [RFC8085] and MAY also implement a transport circuit breaker [RFC8083]. Work in the RTP Media Congestion Avoidance Techniques (RMCAT) working group [RMCAT] describes the interactions and conceptual interfaces necessary between the application components that relate to congestion control, including the RTP layer, the higher-level media codec control layer, and the lower-level transport interface, as well as components dedicated to congestion control functions.
UDPは混雑制御を提供しないため、UDPを介してRTPを使用するアプリケーションは、UDP層[RFC8085]の上に独自の混雑制御を実装し、輸送回路ブレーカー[RFC8083]を実装することもできます。RTPメディアでの作業渋滞回避技術（RMCAT）ワーキンググループ[RMCAT]は、RTP層、高レベルのメディアコーデック制御レイヤー、低下など、混雑制御に関連するアプリケーションコンポーネント間の相互作用と概念インターフェイスを説明します。- レベルの輸送インターフェイス、および輻輳制御機能専用のコンポーネント。
Use of the packet loss feedback mechanisms in AVPF [RFC4585] and SAVPF [RFC5124] are OPTIONAL because SCIP itself manages retransmissions of some errored or lost packets. Specifically, the payload-specific feedback messages defined in [RFC4585], Section 6.3 are OPTIONAL when transporting video data.
AVPF [RFC4585]およびSAVPF [RFC5124]でのパケット損失フィードバックメカニズムの使用は、SCIP自体がいくつかのエラーパケットまたは紛失したパケットの再送信を管理するため、オプションです。具体的には、[RFC4585]で定義されているペイロード固有のフィードバックメッセージは、ビデオデータを輸送するときにオプションです。
The SCIP application-layer protocol uses RTP as a basic transport for the "audio/scip" and "video/scip" payloads. Additional RTPs that do not modify the SCIP payload are considered OPTIONAL in this document and are discretionary for a SCIP device vendor to implement. Some examples include, but are not limited to:
SCIPアプリケーション層プロトコルは、RTPを「オーディオ/SCIP」および「ビデオ/SCIP」ペイロードの基本的なトランスポートとして使用します。SCIPペイロードを変更しない追加のRTPは、このドキュメントではオプションと見なされ、SCIPデバイスベンダーが実装する裁量的です。いくつかの例には、以下が含まれますが、これらに限定されません。
* "RTP Payload Format for Generic Forward Error Correction" [RFC5109]
* 「ジェネリックフォワードエラー補正用のRTPペイロード形式」[RFC5109]
* "Multiplexing RTP Data and Control Packets on a Single Port" [RFC5761]
* 「単一のポートでのRTPデータと制御パケットの多重化」[RFC5761]
* "Symmetric RTP / RTP Control Protocol (RTCP)" [RFC4961]
* 「対称RTP / RTPコントロールプロトコル（RTCP）」[RFC4961]
* "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)" a.k.a. BUNDLE [RFC9143]
* 「セッション説明プロトコル（SDP）を使用したメディアの多重化交渉」A.K.A.バンドル[RFC9143]
The SCIP RTP payload format is identified using the scip media subtype, which is registered in accordance with [RFC4855] and per the media type registration template from [RFC6838]. A clock rate of 8000 Hz SHALL be used for "audio/scip". A clock rate of 90000 Hz SHALL be used for "video/scip".
SCIP RTPペイロード形式は、[RFC4855]に従って登録されており、[RFC6838]のメディア型登録テンプレートに従って登録されているSCIPメディアサブタイプを使用して識別されます。8000 Hzのクロックレートを「オーディオ/SCIP」に使用するものとします。90000 Hzの時計レートは、「ビデオ/SCIP」に使用するものとします。
Type name:
タイプ名：
audio
オーディオオーディオ
Subtype name:
サブタイプ名：
scip
サイプ
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
Binary. This media subtype is only defined for transfer via RTP. There SHALL be no transcoding of the audio stream as it traverses the network.
バイナリ。このメディアサブタイプは、RTPを介した転送に対してのみ定義されます。ネットワークを通過する際に、オーディオストリームのトランスコーディングはありません。
Security considerations:
セキュリティ上の考慮事項：
See Section 6.
セクション6を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
[SCIP210]
[scip210]
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
N/A
n/a
Fragment identifier considerations:
フラグメント識別子の考慮事項：
none
なしのどれも
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨エイリアス名：
N/A
n/a
Magic number(s):
マジックナンバー：
N/A
n/a
File extension(s):
ファイル拡張子：
N/A
n/a
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Michael Faller (michael.faller@gd-ms.com or MichaelFFaller@gmail.com) and Daniel Hanson (dan.hanson@gd-ms.com)
Michael Faller（Michael.faller@gd-ms.comまたはmichaelffaller@gmail.com）およびダニエルハンソン（dan.hanson@gd-ms.com）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
N/A
n/a
Authors:
著者：
Michael Faller (michael.faller@gd-ms.com or MichaelFFaller@gmail.com) and Daniel Hanson (dan.hanson@gd-ms.com)
Michael Faller（Michael.faller@gd-ms.comまたはmichaelffaller@gmail.com）およびダニエルハンソン（dan.hanson@gd-ms.com）
Change controller:
Change Controller：
SCIP Working Group (ncia.cis3@ncia.nato.int)
SCIPワーキンググループ（ncia.cis3@ncia.nato.int）
Type name:
タイプ名：
video
ビデオ
Subtype name:
サブタイプ名：
scip
サイプ
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
Binary. This media subtype is only defined for transfer via RTP. There SHALL be no transcoding of the video stream as it traverses the network.
バイナリ。このメディアサブタイプは、RTPを介した転送に対してのみ定義されます。ネットワークを通過する際のビデオストリームのトランスコーディングはありません。
Security considerations:
セキュリティ上の考慮事項：
See Section 6.
セクション6を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
[SCIP210]
[scip210]
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
N/A
n/a
Fragment identifier considerations:
フラグメント識別子の考慮事項：
none
なしのどれも
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨エイリアス名：
N/A
n/a
Magic number(s):
マジックナンバー：
N/A
n/a
File extension(s):
ファイル拡張子：
N/A
n/a
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Michael Faller (michael.faller@gd-ms.com or MichaelFFaller@gmail.com) and Daniel Hanson (dan.hanson@gd-ms.com)
Michael Faller（Michael.faller@gd-ms.comまたはmichaelffaller@gmail.com）およびダニエルハンソン（dan.hanson@gd-ms.com）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
N/A
n/a
Authors:
著者：
Michael Faller (michael.faller@gd-ms.com or MichaelFFaller@gmail.com) and Daniel Hanson (dan.hanson@gd-ms.com)
Michael Faller（Michael.faller@gd-ms.comまたはmichaelffaller@gmail.com）およびダニエルハンソン（dan.hanson@gd-ms.com）
Change controller:
Change Controller：
SCIP Working Group (ncia.cis3@ncia.nato.int)
SCIPワーキンググループ（ncia.cis3@ncia.nato.int）
The mapping of the above-defined payload format media subtype and its parameters SHALL be implemented according to Section 3 of [RFC4855].
上記の定義されたペイロード形式のメディアサブタイプとそのパラメーターのマッピングは、[RFC4855]のセクション3に従って実装するものとします。
Since SCIP includes its own facilities for capabilities exchange, it is only necessary to negotiate the use of SCIP within SDP Offer/ Answer; the specific codecs to be encapsulated within SCIP are then negotiated via the exchange of SCIP control messages.
SCIPには能力交換のための独自の施設が含まれているため、SDPのオファー/回答内でのSCIPの使用を交渉するだけです。SCIP内でカプセル化される特定のコーデックは、SCIP制御メッセージの交換を介して交渉されます。
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC8866], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the SCIP codec, the mapping is as follows:
メディアタイプの仕様に掲載されている情報には、セッション説明プロトコル（SDP）[RFC8866]のフィールドへの特定のマッピングがあります。これは、RTPセッションを説明するために一般的に使用されます。SDPを使用してSCIPコーデックを使用するセッションを指定する場合、マッピングは次のとおりです。
* The media type ("audio") goes in SDP "m=" as the media name for "audio/scip", and the media type ("video") goes in SDP "m=" as the media name for "video/scip".
* メディアタイプ（「オーディオ」）は、「オーディオ/SCIP」のメディア名としてSDP「M =」に入り、メディアタイプ（「ビデオ」）は、「ビデオ/」のメディア名としてSDP「M =」になります。scip "。
* The media subtype ("scip") goes in SDP "a=rtpmap" as the encoding name. The required parameter "rate" also goes in "a=rtpmap" as the clock rate.
* メディアサブタイプ（ "scip"）は、エンコーディング名としてsdp "a = rtpmap"になります。必要なパラメーター「レート」も、クロックレートとして「a = rtpmap」にも含まれます。
* The optional parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
* オプションのパラメーター「PTIME」と「MAXPTIME」は、それぞれSDP「A = PTIME」および「A = MaxPtime」属性に移動します。
An example mapping for "audio/scip" is:
「オーディオ/SCIP」のマッピングの例は次のとおりです。
m=audio 50000 RTP/AVP 96
a=rtpmap:96 scip/8000
An example mapping for "video/scip" is:
「ビデオ/SCIP」のマッピングの例は次のとおりです。
m=video 50002 RTP/AVP 97
a=rtpmap:97 scip/90000
An example mapping for both "audio/scip" and "video/scip" is:
「オーディオ/SCIP」と「ビデオ/SCIP」の両方のマッピングの例は次のとおりです。
m=audio 50000 RTP/AVP 96
a=rtpmap:96 scip/8000
m=video 50002 RTP/AVP 97
a=rtpmap:97 scip/90000
In accordance with the SDP Offer/Answer model [RFC3264], the SCIP device SHALL list the SCIP payload type number in order of preference in the "m" media line.
SDPオファー/回答モデル[RFC3264]に従って、SCIPデバイスは、「M」メディアラインの優先順位でSCIPペイロードタイプ番号をリストするものとします。
For example, an SDP Offer with scip as the preferred audio media subtype:
たとえば、希望のオーディオメディアサブタイプとしてSCIPを使用したSDPのオファー：
m=audio 50000 RTP/AVP 96 0 8
a=rtpmap:96 scip/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity, and source authenticity for RTP in general. This responsibility lies on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in "Options for Securing RTP Sessions" [RFC7201]. Applications SHOULD use one or more appropriate strong security mechanisms. The rest of this Security Considerations section discusses the security impacting properties of the payload format itself.
この仕様で定義されたペイロード形式を使用したRTPパケットは、RTP仕様[RFC3550]、およびRTP/AVP [RFC3551]、RTP/AVPF [RFC4585]、RTP/SAVP/SAVP/SAVP/AVPF [RFC3551]などの該当するRTPプロファイルで説明されているセキュリティ考慮事項の対象となります。[RFC3711]、またはRTP/ SAVPF [RFC5124]。ただし、「RTPフレームワークの保護：RTPが単一のメディアセキュリティソリューションを義務付けていない理由」[RFC7202]は、RTPペイロード形式の責任ではなく、機密性などの基本的なセキュリティ目標を満たすために使用されるソリューションを議論または義務付けていることは、一般的にRTPの整合性、およびソースの信頼性。この責任は、アプリケーションでRTPを使用している人にはあります。彼らは、「RTPセッションを保護するためのオプション」[RFC7201]の利用可能なセキュリティメカニズムと重要な考慮事項に関するガイダンスを見つけることができます。アプリケーションは、1つ以上の適切な強力なセキュリティメカニズムを使用する必要があります。このセキュリティに関する考慮事項の残りのセクションでは、ペイロード形式自体のセキュリティに影響を与えるプロパティについて説明します。
This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus do not inherently pose a denial-of-service threat due to the receipt of pathological data, nor does the RTP payload format contain any active content.
このRTPペイロード形式とそのメディアデコーダーは、パケット処理のために受信機側の計算の複雑さに有意な不均一性を示さないため、病理学的データの受領のためにサービス拒否の脅威をもたらすことも、RTPペイロード形式には、アクティブなコンテンツが含まれています。
SCIP only encrypts the contents transported in the RTP payload; it does not protect the RTP header or RTCP packets. Applications requiring additional RTP headers and/or RTCP security might consider mechanisms such as SRTP [RFC3711], however these additional mechanisms are considered OPTIONAL in this document.
SCIPは、RTPペイロードで輸送されるコンテンツのみを暗号化します。RTPヘッダーまたはRTCPパケットを保護しません。追加のRTPヘッダーおよび/またはRTCPセキュリティを必要とするアプリケーションは、SRTP [RFC3711]などのメカニズムを考慮する場合がありますが、これらの追加メカニズムはこのドキュメントではオプションと見なされます。
The "audio/scip" and "video/scip" media subtypes have previously been registered in the "Media Types" registry [MediaTypes]. IANA has updated these registrations to reference this document.
「オーディオ/SCIP」および「ビデオ/SCIP」メディアサブタイプは、以前に「メディアタイプ」レジストリ[メディアタイプ]に登録されています。IANAはこれらの登録を更新して、このドキュメントを参照しています。
The SCIP protocol is maintained by the SCIP Working Group. The current SCIP-210 specification [SCIP210] may be requested from the email address below.
SCIPプロトコルは、SCIPワーキンググループによって維持されています。現在のSCIP-210仕様[SCIP210]は、以下のメールアドレスから要求される場合があります。
SCIP Working Group, CIS3 Partnership
NATO Communications and Information Agency
Oude Waalsdorperweg 61
2597 AK The Hague, Netherlands
Email: ncia.cis3@ncia.nato.int
An older public version of the SCIP-210 specification can be downloaded from https://www.iad.gov/SecurePhone/index.cfm. A U.S. Department of Defense Root Certificate should be installed to access this website.
SCIP-210仕様の古い公開バージョンは、https://www.iad.gov/securephone/index.cfmからダウンロードできます。このウェブサイトにアクセスするには、米国国防総省ルート証明書をインストールする必要があります。
[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>.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736,
DOI 10.17487/RFC2736, December 1999,
<https://www.rfc-editor.org/info/rfc2736>.
[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>.
[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, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003,
<https://www.rfc-editor.org/info/rfc3551>.
[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,
<https://www.rfc-editor.org/info/rfc3711>.
[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,
<https://www.rfc-editor.org/info/rfc4585>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <https://www.rfc-editor.org/info/rfc5124>.
[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>.
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", RFC 8866,
DOI 10.17487/RFC8866, January 2021,
<https://www.rfc-editor.org/info/rfc8866>.
[MediaTypes]
IANA, "Media Types",
<https://www.iana.org/assignments/media-types>.
[RFC4040] Kreuter, R., "RTP Payload Format for a 64 kbit/s
Transparent Call", RFC 4040, DOI 10.17487/RFC4040, April
2005, <https://www.rfc-editor.org/info/rfc4040>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
<https://www.rfc-editor.org/info/rfc4855>.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
<https://www.rfc-editor.org/info/rfc4961>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <https://www.rfc-editor.org/info/rfc5109>.
[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>.
[RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP
Payload Format for H.264 Video", RFC 6184,
DOI 10.17487/RFC6184, May 2011,
<https://www.rfc-editor.org/info/rfc6184>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<https://www.rfc-editor.org/info/rfc7201>.
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media
Security Solution", RFC 7202, DOI 10.17487/RFC7202, April
2014, <https://www.rfc-editor.org/info/rfc7202>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", RFC 8083,
DOI 10.17487/RFC8083, March 2017,
<https://www.rfc-editor.org/info/rfc8083>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8088] Westerlund, M., "How to Write an RTP Payload Format",
RFC 8088, DOI 10.17487/RFC8088, May 2017,
<https://www.rfc-editor.org/info/rfc8088>.
[RFC8130] Demjanenko, V. and D. Satterlee, "RTP Payload Format for
the Mixed Excitation Linear Prediction Enhanced (MELPe)
Codec", RFC 8130, DOI 10.17487/RFC8130, March 2017,
<https://www.rfc-editor.org/info/rfc8130>.
[RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", RFC 9143,
DOI 10.17487/RFC9143, February 2022,
<https://www.rfc-editor.org/info/rfc9143>.
[RFC9170] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol
Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170,
December 2021, <https://www.rfc-editor.org/info/rfc9170>.
[RMCAT] IETF, "RTP Media Congestion Avoidance Techniques (rmcat)",
<https://datatracker.ietf.org/wg/rmcat/about>.
[SCIP210] SCIP Working Group, "SCIP Signaling Plan, SCIP-210".
Available by request via email to
<ncia.cis3@ncia.nato.int>.
Daniel Hanson
General Dynamics Mission Systems, Inc.
150 Rustcraft Road
Dedham, MA 02026
United States of America
Email: dan.hanson@gd-ms.com
Michael Faller
General Dynamics Mission Systems, Inc.
150 Rustcraft Road
Dedham, MA 02026
United States of America
Email: michael.faller@gd-ms.com, MichaelFFaller@gmail.com
Keith Maver
General Dynamics Mission Systems, Inc.
150 Rustcraft Road
Dedham, MA 02026
United States of America
Email: keith.maver@gd-ms.com