rfc9607v1.txt | rfc9607.txt | |||
---|---|---|---|---|
skipping to change at line 15 ¶ | skipping to change at line 15 ¶ | |||
ISSN: 2070-1721 General Dynamics Mission Systems, Inc. | ISSN: 2070-1721 General Dynamics Mission Systems, Inc. | |||
July 2024 | July 2024 | |||
RTP Payload Format for the Secure Communication Interoperability | RTP Payload Format for the Secure Communication Interoperability | |||
Protocol (SCIP) Codec | Protocol (SCIP) Codec | |||
Abstract | Abstract | |||
This document describes the RTP payload format of the Secure | This document describes the RTP payload format of the Secure | |||
Communication Interoperability Protocol (SCIP). SCIP is an | Communication Interoperability Protocol (SCIP). SCIP is an | |||
application-layer protocol that provides end-to-end capability | application-layer protocol that provides end-to-end session | |||
exchange, packetization/de-packetization of media, reliable | establishment, payload encryption, packetization and de-packetization | |||
transport, and payload encryption. | of media, and reliable transport. This document provides a globally | |||
available reference that can be used for the development of network | ||||
SCIP handles packetization/de-packetization of encrypted media and | equipment and procurement of services that support SCIP traffic. The | |||
acts as a tunneling protocol, treating SCIP payloads as opaque octets | intended audience is network security policymakers; network | |||
to be encapsulated within RTP payloads prior to transmission or | administrators, architects, and original equipment manufacturers | |||
decapsulated on reception. SCIP payloads are sized to fit within the | (OEMs); procurement personnel; and government agency and commercial | |||
maximum transmission unit (MTU) when transported over RTP, thereby | industry representatives. | |||
avoiding fragmentation. | ||||
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. | ||||
To establish reliable communications using SCIP over RTP, it is | ||||
important that middleboxes avoid parsing or modifying SCIP payloads. | ||||
Because SCIP payloads are confidentiality and integrity protected and | ||||
are only decipherable by the originating and receiving SCIP devices, | ||||
modification of the payload by middle boxes would be detected as an | ||||
integrity failure in SCIP devices, resulting in retransmission and/or | ||||
communication failure. Middle boxes do not need to parse the SCIP | ||||
payloads to correctly transport them. Not only is parsing | ||||
unnecessary to tunnel/detunnel SCIP within RTP, but the parsing and | ||||
filtering of SCIP payloads by middle boxes would likely lead to | ||||
ossification of the evolving SCIP protocol. | ||||
IESG Note | IESG Note | |||
This IETF specification depends upon a second technical specification | This IETF specification depends upon a second technical specification | |||
that is not available publicly, namely [SCIP210]. The IETF was | that is not available publicly, namely [SCIP210]. The IETF was | |||
therefore unable to conduct a security review of that specification, | therefore unable to conduct a security review of that specification, | |||
independently or when carried inside Audio/Video Transport (AVT). | independently or when carried inside Audio/Video Transport (AVT). | |||
Implementers need to be aware that the IETF hence cannot verify any | Implementers need to be aware that the IETF hence cannot verify any | |||
of the security claims contained in this document. | of the security claims contained in this document. | |||
skipping to change at line 91 ¶ | skipping to change at line 73 ¶ | |||
Table of Contents | Table of Contents | |||
1. Key Points | 1. Key Points | |||
2. Introduction | 2. Introduction | |||
2.1. Conventions | 2.1. Conventions | |||
2.2. Abbreviations | 2.2. Abbreviations | |||
3. Background | 3. Background | |||
4. Payload Format | 4. Payload Format | |||
4.1. RTP Header Fields | 4.1. RTP Header Fields | |||
4.2. Congestion Control Considerations | 4.2. Congestion Control Considerations | |||
4.3. Use of Augmented RTP Transport Protocols with SCIP | 4.3. Use of Augmented RTPs with SCIP | |||
5. Payload Format Parameters | 5. Payload Format Parameters | |||
5.1. Media Subtype "audio/scip" | 5.1. Media Subtype "audio/scip" | |||
5.2. Media Subtype "video/scip" | 5.2. Media Subtype "video/scip" | |||
5.3. Mapping to SDP | 5.3. Mapping to SDP | |||
5.4. SDP Offer/Answer Considerations | 5.4. SDP Offer/Answer Considerations | |||
6. Security Considerations | 6. Security Considerations | |||
7. IANA Considerations | 7. IANA Considerations | |||
8. SCIP Contact Information | 8. SCIP Contact Information | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
skipping to change at line 114 ¶ | skipping to change at line 96 ¶ | |||
1. Key Points | 1. Key Points | |||
* SCIP is an application-layer protocol that uses RTP as a | * SCIP is an application-layer protocol that uses RTP as a | |||
transport. This document defines the SCIP media subtypes to be | transport. This document defines the SCIP media subtypes to be | |||
listed in the Session Description Protocol (SDP) and only requires | listed in the Session Description Protocol (SDP) and only requires | |||
a basic RTP transport channel for SCIP payloads. This basic | a basic RTP transport channel for SCIP payloads. This basic | |||
transport channel is comparable to Clearmode as defined by | transport channel is comparable to Clearmode as defined by | |||
[RFC4040]. | [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 | * SCIP is designed to be network agnostic. It can operate over any | |||
digital link, including non-IP modem-based PSTN and ISDN. The | digital link, including non-IP modem-based PSTN and ISDN. The | |||
SCIP media subtypes listed in this document were developed for | SCIP media subtypes listed in this document were developed for | |||
SCIP to operate over RTP. | SCIP to operate over RTP. | |||
* SCIP handles packetization/de-packetization of payloads by | * SCIP handles packetization and de-packetization of payloads by | |||
producing encrypted media packets that are not greater than the | producing encrypted media packets that are not greater than the | |||
MTU size. The SCIP payload is opaque to the network, therefore, | MTU size. The SCIP payload is opaque to the network, therefore, | |||
SCIP functions as a tunneling protocol for the encrypted media, | SCIP functions as a tunneling protocol for the encrypted media, | |||
without the need for middle boxes to parse SCIP payloads. Since | without the need for middleboxes to parse SCIP payloads. Since | |||
SCIP payloads are integrity protected, modification of the SCIP | SCIP payloads are integrity protected, modification of the SCIP | |||
payload is detected as an integrity violation by SCIP endpoints, | payload is detected as an integrity violation by SCIP endpoints, | |||
leading to communication failure. | leading to communication failure. | |||
* 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 middle boxes to | ||||
not attempt parsing of the SCIP payload. As described in this | ||||
document, such parsing serves no useful purpose. | ||||
2. Introduction | 2. Introduction | |||
The purpose of this document is to provide enough information to | This document details usage of the "audio/scip" and "video/scip" | |||
enable SCIP payloads to be transported through the network without | pseudo-codecs [MediaTypes] as a secure session establishment protocol | |||
modification or filtering. This document provides a reference for | and media transport protocol over RTP. | |||
network security policymakers; network equipment OEMs, | ||||
administrators, and architects; procurement personnel; and government | ||||
agency and commercial industry representatives. | ||||
This document details usage of the "audio/scip" [AUDIOSCIP] and | It discusses how: | |||
"video/scip" [VIDEOSCIP] pseudo-codecs as a secure session | ||||
establishment protocol and media transport protocol over RTP. It | ||||
discusses: | ||||
1. how encrypted audio and video codec payloads are transported over | 1. encrypted audio and video codec payloads are transported over | |||
RTP; | RTP; | |||
2. the IP network layer not implementing SCIP as a protocol since | 2. the IP network layer does not implement SCIP as a protocol since | |||
SCIP operates at the application layer in endpoints; | SCIP operates at the application layer in endpoints; | |||
3. the IP network layer enabling SCIP traffic to transparently pass | 3. the IP network layer enables SCIP traffic to transparently pass | |||
through the network; | through the network; | |||
4. network devices not recognizing SCIP, and thus removing the SCIP | 4. some network devices do not recognize SCIP and may remove the | |||
codecs from the SDP media payload declaration before forwarding | SCIP codecs from the SDP media payload declaration before | |||
to the next network node; and finally, | forwarding to the next network node; and finally, | |||
5. SCIP endpoint devices not operating on networks due to the scip | 5. SCIP endpoint devices do not operate on networks if the SCIP | |||
media subtype removal from the SDP media payload declaration. | media subtype is removed from the SDP media payload declaration. | |||
The United States, along with its NATO Partners, have implemented | The United States, along with its NATO Partners, have implemented | |||
SCIP in secure voice, video, and data products operating on | SCIP in secure voice, video, and data products operating on | |||
commercial, private, and tactical IP networks worldwide using the | commercial, private, and tactical IP networks worldwide using the | |||
scip media subtype. The SCIP data traversing the network is | scip media subtype. The SCIP data traversing the network is | |||
encrypted, and network equipment in-line with the session cannot | encrypted, and network equipment in-line with the session cannot | |||
interpret the traffic stream in any way. SCIP-based RTP traffic is | interpret the traffic stream in any way. SCIP-based RTP traffic is | |||
opaque and can vary significantly in structure and frequency, making | opaque and can vary significantly in structure and frequency, making | |||
traffic profiling not possible. Also, as the SCIP protocol continues | traffic profiling not possible. Also, as the SCIP protocol continues | |||
to evolve independently of this document, any network device that | to evolve independently of this document, any network device that | |||
attempts to filter traffic (e.g., deep packet inspection) may cause | attempts to filter traffic (e.g., deep packet inspection) may cause | |||
unintended consequences in the future when changes to the SCIP | unintended consequences in the future when changes to the SCIP | |||
traffic may not be recognized by the network device. | traffic may not be recognized by the network device. | |||
The SCIP protocol defined in SCIP-210 [SCIP210] includes built-in | The SCIP protocol defined in SCIP-210 [SCIP210] includes built-in | |||
support for packetization/de-packetization, retransmission, | support for packetization and de-packetization, retransmission, | |||
capability exchange, version negotiation, and payload encryption. | capability exchange, version negotiation, and payload encryption. | |||
Since the traffic is encrypted, neither the RTP transport nor middle | Since the traffic is encrypted, neither the RTP transport nor | |||
boxes can usefully parse or modify SCIP payloads; modifications are | middleboxes can usefully parse or modify SCIP payloads; modifications | |||
detected as integrity violations resulting in retransmission, and | are detected as integrity violations resulting in retransmission, and | |||
eventually, communication failure. | eventually, communication failure. | |||
Because knowledge of the SCIP payload format is not needed to | Because knowledge of the SCIP payload format is not needed to | |||
transport SCIP signaling or media through middle boxes, SCIP-210 | transport SCIP signaling or media through middleboxes, SCIP-210 | |||
represents an informative reference. While older versions of the | represents an informative reference. While older versions of the | |||
SCIP-210 specification are publicly available, the authors strongly | SCIP-210 specification are publicly available, the authors strongly | |||
encourage network implementers to treat SCIP payloads as opaque | encourage network implementers to treat SCIP payloads as opaque | |||
octets. When handled correctly, such treatment does not require | octets. When handled correctly, such treatment does not require | |||
referring to SCIP-210, and any assumptions about the format of SCIP | referring to SCIP-210, and any assumptions about the format of SCIP | |||
messages defined in SCIP-210 are likely to lead to protocol | messages defined in SCIP-210 are likely to lead to protocol | |||
ossification and communication failures as the protocol evolves. | 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 | 2.1. Conventions | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
The best current practices for writing an RTP payload format | The best current practices for writing an RTP payload format | |||
specification, as per [RFC2736] and [RFC8088], were followed. | specification, as per [RFC2736] and [RFC8088], were followed. | |||
skipping to change at line 222 ¶ | skipping to change at line 199 ¶ | |||
subtype scip, lowercase "scip" is used. | subtype scip, lowercase "scip" is used. | |||
2.2. Abbreviations | 2.2. Abbreviations | |||
The following abbreviations are used in this document. | The following abbreviations are used in this document. | |||
AVP: Audio/Video Profile | AVP: Audio/Video Profile | |||
AVPF: Audio/Video Profile Feedback | AVPF: Audio/Video Profile Feedback | |||
FNBDT: Future Narrowband Digital Terminal | ||||
ICWG: Interoperability Control Working Group | ICWG: Interoperability Control Working Group | |||
IICWG: International 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 | NATO: North Atlantic Treaty Organization | |||
OEM: Original Equipment Manufacturer | OEM: Original Equipment Manufacturer | |||
SAVP: Secure Audio/Video Profile | SAVP: Secure Audio/Video Profile | |||
SAVPF: Secure Audio/Video Profile Feedback | SAVPF: Secure Audio/Video Profile Feedback | |||
SCIP: Secure Communication Interoperability Protocol | SCIP: Secure Communication Interoperability Protocol | |||
skipping to change at line 266 ¶ | skipping to change at line 249 ¶ | |||
Interoperability Control Working Group (IICWG), which was later | Interoperability Control Working Group (IICWG), which was later | |||
renamed the SCIP Working Group. | renamed the SCIP Working Group. | |||
First generation SCIP devices operated on circuit-switched networks. | First generation SCIP devices operated on circuit-switched networks. | |||
SCIP was then expanded to radio and IP networks. The scip media | SCIP was then expanded to radio and IP networks. The scip media | |||
subtype transports SCIP secure session establishment signaling and | subtype transports SCIP secure session establishment signaling and | |||
secure application traffic. The built-in negotiation and flexibility | secure application traffic. The built-in negotiation and flexibility | |||
provided by the SCIP protocols make it a natural choice for many | provided by the SCIP protocols make it a natural choice for many | |||
scenarios that require various secure applications and associated | scenarios that require various secure applications and associated | |||
encryption suites. SCIP has been adopted by NATO in STANAG 5068. | encryption suites. SCIP has been adopted by NATO in STANAG 5068. | |||
SCIP standards are currently available to participating government/ | SCIP standards are currently available to participating government | |||
military communities and select OEMs of equipment that support SCIP. | and military communities and select OEMs of equipment that support | |||
SCIP. | ||||
However, SCIP must operate over global networks (including private | However, SCIP must operate over global networks (including private | |||
and commercial networks). Without access to necessary information to | and commercial networks). Without access to necessary information to | |||
support SCIP, some networks may not support the SCIP media subtypes. | support SCIP, some networks may not support the SCIP media subtypes. | |||
Issues may occur simply because information is not as readily | Issues may occur simply because information is not as readily | |||
available to OEMs, network administrators, and network architects. | available to OEMs, network administrators, and network architects. | |||
This document provides essential information about the audio/scip and | This document provides essential information about the "audio/scip" | |||
video/scip media subtypes that enable network equipment manufacturers | and "video/scip" media subtypes that enable network equipment | |||
to include settings for "scip" as a known audio and video media | manufacturers to include settings for "scip" as a known audio and | |||
subtype in their equipment. This enables network administrators to | video media subtype in their equipment. This enables network | |||
define and implement a compatible security policy that includes audio | administrators to define and implement a compatible security policy | |||
and video media subtypes "audio/scip" and "video/scip", respectively, | that includes audio and video media subtypes "audio/scip" and "video/ | |||
as permitted codecs on the network. | scip", respectively, as permitted codecs on the network. | |||
All current IP-based SCIP endpoints implement "scip" as a media | All current IP-based SCIP endpoints implement "scip" as a media | |||
subtype. Registration of scip as a media subtype provides a common | subtype. Registration of scip as a media subtype provides a common | |||
reference for network equipment manufacturers to recognize SCIP in an | reference for network equipment manufacturers to recognize SCIP in an | |||
SDP payload declaration. | SDP payload declaration. | |||
4. Payload Format | 4. Payload Format | |||
The "scip" media subtype identifies and indicates support for SCIP | The "scip" media subtype identifies and indicates support for SCIP | |||
traffic that is being transported over RTP. Transcoding, lossy | traffic that is being transported over RTP. Transcoding, lossy | |||
compression, or other data modifications MUST NOT be performed by the | compression, or other data modifications MUST NOT be performed by the | |||
network on the SCIP RTP payload. The audio/scip and video/scip media | network on the SCIP RTP payload. The "audio/scip" and "video/scip" | |||
subtype data streams within the network, including the VoIP network, | media subtype data streams within the network, including the VoIP | |||
MUST be a transparent relay and be treated as "clear-channel data", | network, MUST be a transparent relay and be treated as "clear-channel | |||
similar to the Clearmode media subtype defined by [RFC4040]. | data", similar to the Clearmode media subtype defined by [RFC4040]. | |||
[RFC4040] is referenced because Clearmode does not define specific | [RFC4040] is referenced because Clearmode does not define specific | |||
RTP payload content, packet size, or packet intervals, but rather | RTP payload content, packet size, or packet intervals, but rather | |||
enables Clearmode devices to signal that they support a compatible | enables Clearmode devices to signal that they support a compatible | |||
mode of operation and defines a transparent channel on which devices | mode of operation and defines a transparent channel on which devices | |||
may communicate. This document takes a similar approach. Network | may communicate. This document takes a similar approach. Network | |||
devices that implement support for SCIP need to enable SCIP endpoints | devices that implement support for SCIP need to enable SCIP endpoints | |||
to signal that they support SCIP and provide a transparent channel on | to signal that they support SCIP and provide a transparent channel on | |||
which SCIP endpoints may communicate. | which SCIP endpoints may communicate. | |||
skipping to change at line 329 ¶ | skipping to change at line 313 ¶ | |||
| | | | | | |||
| SCIP Payload | | | SCIP Payload | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 1: SCIP RTP Payload Format | Figure 1: SCIP RTP Payload Format | |||
The SCIP codec produces an encrypted bitstream that is transported | The SCIP codec produces an encrypted bitstream that is transported | |||
over RTP. Unlike other codecs, SCIP does not have its own upper | over RTP. Unlike other codecs, SCIP does not have its own upper | |||
layer syntax (e.g., no Network Adaptation Layer (NAL) units), but | layer syntax (e.g., no Network Adaptation Layer (NAL) units), but | |||
rather encrypts the output of the audio/video codecs that it uses | 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 | (e.g., G.729D, H.264 [RFC6184], etc.). SCIP achieves this by | |||
encapsulating the encrypted codec output that has been previously | encapsulating the encrypted codec output that has been previously | |||
formatted according to the relevant RTP payload specification for | formatted according to the relevant RTP payload specification for | |||
that codec. SCIP endpoints MAY employ mechanisms, such as inter- | that codec. SCIP endpoints MAY employ mechanisms, such as inter- | |||
media RTP synchronization as described in [RFC8088], Section 3.3.4, | media RTP synchronization as described in [RFC8088], Section 3.3.4, | |||
to synchronize audio/scip and video/scip streams. | to synchronize "audio/scip" and "video/scip" streams. | |||
Figure 2 below illustrates notionally how codec packets and SCIP | Figure 2 below illustrates notionally how codec packets and SCIP | |||
control messages are packetized for transmission over RTP. | control messages are packetized for transmission over RTP. | |||
+-----------+ +-----------------------+ | +-----------+ +-----------------------+ | |||
| Codec | | SCIP control messages | | | Codec | | SCIP control messages | | |||
+-----------+ +-----------------------+ | +-----------+ +-----------------------+ | |||
| | | | | | |||
| | | | | | |||
V V | V V | |||
skipping to change at line 422 ¶ | skipping to change at line 406 ¶ | |||
layer, the higher-level media codec control layer, and the lower- | layer, the higher-level media codec control layer, and the lower- | |||
level transport interface, as well as components dedicated to | level transport interface, as well as components dedicated to | |||
congestion control functions. | congestion control functions. | |||
Use of the packet loss feedback mechanisms in AVPF [RFC4585] and | Use of the packet loss feedback mechanisms in AVPF [RFC4585] and | |||
SAVPF [RFC5124] are OPTIONAL because SCIP itself manages | SAVPF [RFC5124] are OPTIONAL because SCIP itself manages | |||
retransmissions of some errored or lost packets. Specifically, the | retransmissions of some errored or lost packets. Specifically, the | |||
payload-specific feedback messages defined in [RFC4585], Section 6.3 | payload-specific feedback messages defined in [RFC4585], Section 6.3 | |||
are OPTIONAL when transporting video data. | are OPTIONAL when transporting video data. | |||
4.3. Use of Augmented RTP Transport Protocols with SCIP | 4.3. Use of Augmented RTPs with SCIP | |||
The SCIP application-layer protocol uses RTP as a basic transport for | The SCIP application-layer protocol uses RTP as a basic transport for | |||
the audio/scip and video/scip payloads. Additional RTPs that do not | the "audio/scip" and "video/scip" payloads. Additional RTPs that do | |||
modify the SCIP payload are considered OPTIONAL in this document and | not modify the SCIP payload are considered OPTIONAL in this document | |||
are discretionary for a SCIP device vendor to implement. Some | and are discretionary for a SCIP device vendor to implement. Some | |||
examples include, but are not limited to: | examples include, but are not limited to: | |||
* "RTP Payload Format for Generic Forward Error Correction" | * "RTP Payload Format for Generic Forward Error Correction" | |||
[RFC5109] | [RFC5109] | |||
* "Multiplexing RTP Data and Control Packets on a Single Port" | * "Multiplexing RTP Data and Control Packets on a Single Port" | |||
[RFC5761] | [RFC5761] | |||
* "Symmetric RTP / RTP Control Protocol (RTCP)" [RFC4961] | * "Symmetric RTP / RTP Control Protocol (RTCP)" [RFC4961] | |||
skipping to change at line 460 ¶ | skipping to change at line 444 ¶ | |||
Type name: audio | Type name: audio | |||
Subtype name: scip | Subtype name: scip | |||
Required parameters: N/A | Required parameters: N/A | |||
Optional parameters: N/A | Optional parameters: N/A | |||
Encoding considerations: Binary. This media subtype is only defined | Encoding considerations: Binary. This media subtype is only defined | |||
for transfer via RTP. There SHALL be no encoding/decoding | for transfer via RTP. There SHALL be no transcoding of the audio | |||
(transcoding) of the audio stream as it traverses the network. | stream as it traverses the network. | |||
Security considerations: See Section 6. | Security considerations: See Section 6. | |||
Interoperability considerations: N/A | Interoperability considerations: N/A | |||
Published specification: [SCIP210] | Published specification: [SCIP210] | |||
Applications that use this media type: N/A | Applications that use this media type: N/A | |||
Fragment identifier considerations: none | Fragment identifier considerations: none | |||
Additional information: | Additional information: | |||
Deprecated alias names for this type: N/A | Deprecated alias names for this type: N/A | |||
Magic number(s): N/A | Magic number(s): N/A | |||
File extension(s): N/A | File extension(s): N/A | |||
Macintosh file type code(s): N/A | Macintosh file type code(s): N/A | |||
Person & email address to contact for further information: Michael | Person & email address to contact for further information: Michael | |||
Faller (michael.faller@gd-ms.com) and Daniel Hanson | Faller (michael.faller@gd-ms.com or MichaelFFaller@gmail.com) and | |||
(dan.hanson@gd-ms.com) | Daniel Hanson (dan.hanson@gd-ms.com) | |||
Intended usage: COMMON | Intended usage: COMMON | |||
Restrictions on usage: N/A | Restrictions on usage: N/A | |||
Authors: Michael Faller (michael.faller@gd-ms.com) and Daniel Hanson | Authors: Michael Faller (michael.faller@gd-ms.com or | |||
(dan.hanson@gd-ms.com) | MichaelFFaller@gmail.com) and Daniel Hanson (dan.hanson@gd-ms.com) | |||
Change controller: SCIP Working Group (ncia.cis3@ncia.nato.int) | Change controller: SCIP Working Group (ncia.cis3@ncia.nato.int) | |||
5.2. Media Subtype "video/scip" | 5.2. Media Subtype "video/scip" | |||
Type name: video | Type name: video | |||
Subtype name: scip | Subtype name: scip | |||
Required parameters: N/A | Required parameters: N/A | |||
Optional parameters: N/A | Optional parameters: N/A | |||
Encoding considerations: Binary. This media subtype is only defined | Encoding considerations: Binary. This media subtype is only defined | |||
for transfer via RTP. There SHALL be no encoding/decoding | for transfer via RTP. There SHALL be no transcoding of the video | |||
(transcoding) of the video stream as it traverses the network. | stream as it traverses the network. | |||
Security considerations: See Section 6. | Security considerations: See Section 6. | |||
Interoperability considerations: N/A | Interoperability considerations: N/A | |||
Published specification: [SCIP210] | Published specification: [SCIP210] | |||
Applications that use this media type: N/A | Applications that use this media type: N/A | |||
Fragment identifier considerations: none | Fragment identifier considerations: none | |||
Additional information: | Additional information: | |||
Deprecated alias names for this type: N/A | Deprecated alias names for this type: N/A | |||
Magic number(s): N/A | Magic number(s): N/A | |||
File extension(s): N/A | File extension(s): N/A | |||
Macintosh file type code(s): N/A | Macintosh file type code(s): N/A | |||
Person & email address to contact for further information: Michael | Person & email address to contact for further information: Michael | |||
Faller (michael.faller@gd-ms.com) and Daniel Hanson | Faller (michael.faller@gd-ms.com or MichaelFFaller@gmail.com) and | |||
(dan.hanson@gd-ms.com) | Daniel Hanson (dan.hanson@gd-ms.com) | |||
Intended usage: COMMON | Intended usage: COMMON | |||
Restrictions on usage: N/A | Restrictions on usage: N/A | |||
Authors: Michael Faller (michael.faller@gd-ms.com) and Daniel Hanson | Authors: Michael Faller (michael.faller@gd-ms.com or | |||
(dan.hanson@gd-ms.com) | MichaelFFaller@gmail.com) and Daniel Hanson (dan.hanson@gd-ms.com) | |||
Change controller: SCIP Working Group (ncia.cis3@ncia.nato.int) | Change controller: SCIP Working Group (ncia.cis3@ncia.nato.int) | |||
5.3. Mapping to SDP | 5.3. Mapping to SDP | |||
The mapping of the above-defined payload format media subtype and its | The mapping of the above-defined payload format media subtype and its | |||
parameters SHALL be implemented according to Section 3 of [RFC4855]. | parameters SHALL be implemented according to Section 3 of [RFC4855]. | |||
Since SCIP includes its own facilities for capabilities exchange, it | Since SCIP includes its own facilities for capabilities exchange, it | |||
is only necessary to negotiate the use of SCIP within SDP Offer/ | is only necessary to negotiate the use of SCIP within SDP Offer/ | |||
Answer; the specific codecs to be encapsulated within SCIP are then | Answer; the specific codecs to be encapsulated within SCIP are then | |||
negotiated via the exchange of SCIP control messages. | negotiated via the exchange of SCIP control messages. | |||
The information carried in the media type specification has a | The information carried in the media type specification has a | |||
specific mapping to fields in the Session Description Protocol (SDP) | specific mapping to fields in the Session Description Protocol (SDP) | |||
[RFC8866], which is commonly used to describe RTP sessions. When SDP | [RFC8866], which is commonly used to describe RTP sessions. When SDP | |||
is used to specify sessions employing the SCIP codec, the mapping is | is used to specify sessions employing the SCIP codec, the mapping is | |||
as follows: | as follows: | |||
* The media type ("audio") goes in SDP "m=" as the media name for | * 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 | "audio/scip", and the media type ("video") goes in SDP "m=" as the | |||
media name for video/scip. | media name for "video/scip". | |||
* The media subtype ("scip") goes in SDP "a=rtpmap" as the encoding | * The media subtype ("scip") goes in SDP "a=rtpmap" as the encoding | |||
name. The required parameter "rate" also goes in "a=rtpmap" as | name. The required parameter "rate" also goes in "a=rtpmap" as | |||
the clock rate. | the clock rate. | |||
* The optional parameters "ptime" and "maxptime" go in the SDP | * The optional parameters "ptime" and "maxptime" go in the SDP | |||
"a=ptime" and "a=maxptime" attributes, respectively. | "a=ptime" and "a=maxptime" attributes, respectively. | |||
An example mapping for audio/scip is: | An example mapping for "audio/scip" is: | |||
m=audio 50000 RTP/AVP 96 | m=audio 50000 RTP/AVP 96 | |||
a=rtpmap:96 scip/8000 | a=rtpmap:96 scip/8000 | |||
An example mapping for video/scip is: | An example mapping for "video/scip" is: | |||
m=video 50002 RTP/AVP 97 | m=video 50002 RTP/AVP 97 | |||
a=rtpmap:97 scip/90000 | a=rtpmap:97 scip/90000 | |||
An example mapping for both audio/scip and video/scip is: | An example mapping for both "audio/scip" and "video/scip" is: | |||
m=audio 50000 RTP/AVP 96 | m=audio 50000 RTP/AVP 96 | |||
a=rtpmap:96 scip/8000 | a=rtpmap:96 scip/8000 | |||
m=video 50002 RTP/AVP 97 | m=video 50002 RTP/AVP 97 | |||
a=rtpmap:97 scip/90000 | a=rtpmap:97 scip/90000 | |||
5.4. SDP Offer/Answer Considerations | 5.4. SDP Offer/Answer Considerations | |||
In accordance with the SDP Offer/Answer model [RFC3264], the SCIP | In accordance with the SDP Offer/Answer model [RFC3264], the SCIP | |||
device SHALL list the SCIP payload type number in order of preference | device SHALL list the SCIP payload type number in order of preference | |||
skipping to change at line 628 ¶ | skipping to change at line 612 ¶ | |||
does the RTP payload format contain any active content. | does the RTP payload format contain any active content. | |||
SCIP only encrypts the contents transported in the RTP payload; it | SCIP only encrypts the contents transported in the RTP payload; it | |||
does not protect the RTP header or RTCP packets. Applications | does not protect the RTP header or RTCP packets. Applications | |||
requiring additional RTP headers and/or RTCP security might consider | requiring additional RTP headers and/or RTCP security might consider | |||
mechanisms such as SRTP [RFC3711], however these additional | mechanisms such as SRTP [RFC3711], however these additional | |||
mechanisms are considered OPTIONAL in this document. | mechanisms are considered OPTIONAL in this document. | |||
7. IANA Considerations | 7. IANA Considerations | |||
The audio/scip and video/scip media subtypes have previously been | The "audio/scip" and "video/scip" media subtypes have previously been | |||
registered with IANA [AUDIOSCIP] [VIDEOSCIP]. IANA should update | registered in the "Media Types" registry [MediaTypes]. IANA has | |||
[AUDIOSCIP] and [VIDEOSCIP] to reference this document upon | updated these registrations to reference this document. | |||
publication. | ||||
8. SCIP Contact Information | 8. SCIP Contact Information | |||
The SCIP protocol is maintained by the SCIP Working Group. The | The SCIP protocol is maintained by the SCIP Working Group. The | |||
current SCIP-210 specification may be requested from the email | current SCIP-210 specification [SCIP210] may be requested from the | |||
address below. | email address below. | |||
SCIP Working Group, CIS3 Partnership | SCIP Working Group, CIS3 Partnership | |||
NATO Communications and Information Agency | NATO Communications and Information Agency | |||
Oude Waalsdorperweg 61 | Oude Waalsdorperweg 61 | |||
2597 AK The Hague, Netherlands | 2597 AK The Hague, Netherlands | |||
Email: ncia.cis3@ncia.nato.int | Email: ncia.cis3@ncia.nato.int | |||
An older public version of the SCIP-210 specification can be | An older public version of the SCIP-210 specification can be | |||
downloaded from https://www.iad.gov/SecurePhone/index.cfm. | 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. References | |||
9.1. Normative References | 9.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
skipping to change at line 704 ¶ | skipping to change at line 689 ¶ | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: | [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: | |||
Session Description Protocol", RFC 8866, | Session Description Protocol", RFC 8866, | |||
DOI 10.17487/RFC8866, January 2021, | DOI 10.17487/RFC8866, January 2021, | |||
<https://www.rfc-editor.org/info/rfc8866>. | <https://www.rfc-editor.org/info/rfc8866>. | |||
9.2. Informative References | 9.2. Informative References | |||
[AUDIOSCIP] | [MediaTypes] | |||
IANA, "audio/scip", | IANA, "Media Types", | |||
<https://www.iana.org/assignments/media-types/audio/scip>. | <https://www.iana.org/assignments/media-types>. | |||
[RFC4040] Kreuter, R., "RTP Payload Format for a 64 kbit/s | [RFC4040] Kreuter, R., "RTP Payload Format for a 64 kbit/s | |||
Transparent Call", RFC 4040, DOI 10.17487/RFC4040, April | Transparent Call", RFC 4040, DOI 10.17487/RFC4040, April | |||
2005, <https://www.rfc-editor.org/info/rfc4040>. | 2005, <https://www.rfc-editor.org/info/rfc4040>. | |||
[RFC4855] Casner, S., "Media Type Registration of RTP Payload | [RFC4855] Casner, S., "Media Type Registration of RTP Payload | |||
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, | Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, | |||
<https://www.rfc-editor.org/info/rfc4855>. | <https://www.rfc-editor.org/info/rfc4855>. | |||
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", | [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", | |||
skipping to change at line 779 ¶ | skipping to change at line 764 ¶ | |||
DOI 10.17487/RFC9143, February 2022, | DOI 10.17487/RFC9143, February 2022, | |||
<https://www.rfc-editor.org/info/rfc9143>. | <https://www.rfc-editor.org/info/rfc9143>. | |||
[RFC9170] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol | [RFC9170] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol | |||
Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170, | Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170, | |||
December 2021, <https://www.rfc-editor.org/info/rfc9170>. | December 2021, <https://www.rfc-editor.org/info/rfc9170>. | |||
[RMCAT] IETF, "RTP Media Congestion Avoidance Techniques (rmcat)", | [RMCAT] IETF, "RTP Media Congestion Avoidance Techniques (rmcat)", | |||
<https://datatracker.ietf.org/wg/rmcat/about>. | <https://datatracker.ietf.org/wg/rmcat/about>. | |||
[SCIP210] SCIP Working Group, "SCIP Signaling Plan", SCIP-210, | [SCIP210] SCIP Working Group, "SCIP Signaling Plan, SCIP-210", | |||
r3.11, September 2023, | ||||
<https://www.iad.gov/SecurePhone/index.cfm>. | <https://www.iad.gov/SecurePhone/index.cfm>. | |||
[VIDEOSCIP] | ||||
IANA, "video/scip", | ||||
<https://www.iana.org/assignments/media-types/video/scip>. | ||||
Authors' Addresses | Authors' Addresses | |||
Daniel Hanson | Daniel Hanson | |||
General Dynamics Mission Systems, Inc. | General Dynamics Mission Systems, Inc. | |||
150 Rustcraft Road | 150 Rustcraft Road | |||
Dedham, MA 02026 | Dedham, MA 02026 | |||
United States of America | United States of America | |||
Email: dan.hanson@gd-ms.com | Email: dan.hanson@gd-ms.com | |||
Michael Faller | Michael Faller | |||
End of changes. 42 change blocks. | ||||
115 lines changed or deleted | 95 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |