From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc9607.txt | 800 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 800 insertions(+) create mode 100644 doc/rfc/rfc9607.txt (limited to 'doc/rfc/rfc9607.txt') diff --git a/doc/rfc/rfc9607.txt b/doc/rfc/rfc9607.txt new file mode 100644 index 0000000..a29b1a6 --- /dev/null +++ b/doc/rfc/rfc9607.txt @@ -0,0 +1,800 @@ + + + + +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 + + + RTP Payload Format for the Secure Communication Interoperability + Protocol (SCIP) Codec + +Abstract + + 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. + +IESG Note + + 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. + +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. + + 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. + +Copyright Notice + + Copyright (c) 2024 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + +Table of Contents + + 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 + +1. Key Points + + * 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 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 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 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 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. + +2. Introduction + + 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. + + It discusses how: + + 1. encrypted audio and video codec payloads are transported over + RTP; + + 2. the IP network layer does not implement SCIP as a protocol since + SCIP operates at the application layer in endpoints; + + 3. the IP network layer enables SCIP traffic to transparently pass + through the network; + + 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, + + 5. SCIP endpoint devices do not operate on networks if the SCIP + media subtype is removed from the SDP media payload declaration. + + 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. + + 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. + + 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. + + | Note: The IETF has not conducted a security review of SCIP and + | therefore has not verified the claims contained in this + | document. + +2.1. Conventions + + 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. + + The best current practices for writing an RTP payload format + specification, as per [RFC2736] and [RFC8088], were followed. + + 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. + +2.2. Abbreviations + + The following abbreviations are used in this document. + + AVP: Audio-Visual Profile + + AVPF: Audio-Visual Profile with Feedback + + FNBDT: Future Narrowband Digital Terminal + + ICWG: Interoperability Control Working Group + + IICWG: International Interoperability Control Working Group + + MELPe: Mixed Excitation Linear Prediction Enhanced + + MTU: Maximum Transmission Unit + + NATO: North Atlantic Treaty Organization + + OEM: Original Equipment Manufacturer + + SAVP: Secure Audio-Visual Profile + + SAVPF: Secure Audio-Visual Profile with Feedback + + SCIP: Secure Communication Interoperability Protocol + + SDP: Session Description Protocol + + SRTP: Secure Real-time Transport Protocol + + STANAG: Standardization Agreement + +3. Background + + 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 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. + + 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. + + 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. + + 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. + + 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. + +4. Payload Format + + 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]. + + [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. + + 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. + + Figure 1 below illustrates the RTP payload format for SCIP. + + 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 + + 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. + + Figure 2 below illustrates notionally how codec packets and SCIP + control messages are packetized for transmission over RTP. + + +-----------+ +-----------------------+ + | Codec | | SCIP control messages | + +-----------+ +-----------------------+ + | | + | | + V V + +--------------------------------------------------+ + | Packetizer* (<= MTU size) | + +--------------------------------------------------+ + | | + | | + V | + +--------------+ | + | Encryption | | + +--------------+ | + | | + | | + V V + +--------------------------------------------------+ + | RTP | + +--------------------------------------------------+ + + Figure 2: SCIP RTP Architecture + + * 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. + + 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. + +4.1. RTP Header Fields + + The SCIP RTP header fields SHALL conform to [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. + + 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. + +4.2. Congestion Control Considerations + + 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. + + 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. + + 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. + +4.3. Use of Augmented RTPs with SCIP + + 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: + + * "RTP Payload Format for Generic Forward Error Correction" + [RFC5109] + + * "Multiplexing RTP Data and Control Packets on a Single Port" + [RFC5761] + + * "Symmetric RTP / RTP Control Protocol (RTCP)" [RFC4961] + + * "Negotiating Media Multiplexing Using the Session Description + Protocol (SDP)" a.k.a. BUNDLE [RFC9143] + +5. Payload Format Parameters + + 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". + +5.1. Media Subtype "audio/scip" + + Type name: audio + + Subtype name: scip + + Required parameters: N/A + + Optional parameters: 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. + + Security considerations: See Section 6. + + Interoperability considerations: N/A + + Published specification: [SCIP210] + + Applications that use this media type: N/A + + Fragment identifier considerations: none + + Additional information: + + Deprecated alias names for this type: N/A + Magic number(s): N/A + File extension(s): N/A + Macintosh file type code(s): 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) + + Intended usage: COMMON + + Restrictions on usage: N/A + + Authors: Michael Faller (michael.faller@gd-ms.com or + MichaelFFaller@gmail.com) and Daniel Hanson (dan.hanson@gd-ms.com) + + Change controller: SCIP Working Group (ncia.cis3@ncia.nato.int) + +5.2. Media Subtype "video/scip" + + Type name: video + + Subtype name: scip + + Required parameters: N/A + + Optional parameters: 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. + + Security considerations: See Section 6. + + Interoperability considerations: N/A + + Published specification: [SCIP210] + + Applications that use this media type: N/A + + Fragment identifier considerations: none + + Additional information: + + Deprecated alias names for this type: N/A + Magic number(s): N/A + File extension(s): N/A + Macintosh file type code(s): 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) + + Intended usage: COMMON + + Restrictions on usage: N/A + + Authors: Michael Faller (michael.faller@gd-ms.com or + MichaelFFaller@gmail.com) and Daniel Hanson (dan.hanson@gd-ms.com) + + Change controller: SCIP Working Group (ncia.cis3@ncia.nato.int) + +5.3. Mapping to SDP + + The mapping of the above-defined payload format media subtype and its + parameters SHALL be implemented according to Section 3 of [RFC4855]. + + 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. + + 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: + + * 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". + + * 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. + + * The optional parameters "ptime" and "maxptime" go in the SDP + "a=ptime" and "a=maxptime" attributes, respectively. + + An example mapping for "audio/scip" is: + + m=audio 50000 RTP/AVP 96 + a=rtpmap:96 scip/8000 + + An example mapping for "video/scip" is: + + m=video 50002 RTP/AVP 97 + a=rtpmap:97 scip/90000 + + An example mapping for both "audio/scip" and "video/scip" is: + + m=audio 50000 RTP/AVP 96 + a=rtpmap:96 scip/8000 + m=video 50002 RTP/AVP 97 + a=rtpmap:97 scip/90000 + +5.4. SDP Offer/Answer Considerations + + 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. + + For example, an SDP Offer with scip as the preferred audio media + subtype: + + m=audio 50000 RTP/AVP 96 0 8 + a=rtpmap:96 scip/8000 + a=rtpmap:0 PCMU/8000 + a=rtpmap:8 PCMA/8000 + +6. Security Considerations + + 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. + + 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. + + 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. + +7. IANA Considerations + + 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. + +8. SCIP Contact Information + + 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 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. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP + Payload Format Specifications", BCP 36, RFC 2736, + DOI 10.17487/RFC2736, December 1999, + . + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + DOI 10.17487/RFC3264, June 2002, + . + + [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, . + + [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, + . + + [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, + . + + [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, + . + + [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, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: + Session Description Protocol", RFC 8866, + DOI 10.17487/RFC8866, January 2021, + . + +9.2. Informative References + + [MediaTypes] + IANA, "Media Types", + . + + [RFC4040] Kreuter, R., "RTP Payload Format for a 64 kbit/s + Transparent Call", RFC 4040, DOI 10.17487/RFC4040, April + 2005, . + + [RFC4855] Casner, S., "Media Type Registration of RTP Payload + Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, + . + + [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", + BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, + . + + [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error + Correction", RFC 5109, DOI 10.17487/RFC5109, December + 2007, . + + [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and + Control Packets on a Single Port", RFC 5761, + DOI 10.17487/RFC5761, April 2010, + . + + [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, + . + + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + . + + [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP + Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, + . + + [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, . + + [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: + Circuit Breakers for Unicast RTP Sessions", RFC 8083, + DOI 10.17487/RFC8083, March 2017, + . + + [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage + Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, + March 2017, . + + [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", + RFC 8088, DOI 10.17487/RFC8088, May 2017, + . + + [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, + . + + [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, + . + + [RFC9170] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol + Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170, + December 2021, . + + [RMCAT] IETF, "RTP Media Congestion Avoidance Techniques (rmcat)", + . + + [SCIP210] SCIP Working Group, "SCIP Signaling Plan, SCIP-210". + Available by request via email to + . + +Authors' Addresses + + 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 -- cgit v1.2.3