rfc9607xml2.original.xml   rfc9607.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.15 (Ruby 3.
0.2) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?rfc {"toc"=>nil, "sortrefs"=>nil, "symrefs"=>nil}="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-avtcore-rtp-scip-09" number="9607" category="std" consensus="true" submiss ionType="IETF" updates="" obsoletes="" tocInclude="true" xml:lang="en" version=" 3" sortRefs="true" symRefs="true">
<rfc ipr="trust200902" docName="draft-ietf-avtcore-rtp-scip-09" category="std" c onsensus="true" submissionType="IETF">
<front> <front>
<title abbrev="SCIP RTP Payload Format">RTP Payload Format for the Secure Co mmunication <title abbrev="SCIP RTP Payload Format">RTP Payload Format for the Secure Co mmunication
Interoperability Protocol (SCIP) Codec</title> Interoperability Protocol (SCIP) Codec</title>
<seriesInfo name="RFC" value="9607"/>
<author initials="D." surname="Hanson" fullname="Daniel Hanson"> <author initials="D." surname="Hanson" fullname="Daniel Hanson">
<organization>General Dynamics Mission Systems, Inc.</organization> <organization>General Dynamics Mission Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>150 Rustcraft Road</street> <street>150 Rustcraft Road</street>
<city>Dedham</city> <city>Dedham</city>
<region>MA</region> <region>MA</region>
<code>02026</code> <code>02026</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
skipping to change at line 44 skipping to change at line 40
<organization>General Dynamics Mission Systems, Inc.</organization> <organization>General Dynamics Mission Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>150 Rustcraft Road</street> <street>150 Rustcraft Road</street>
<city>Dedham</city> <city>Dedham</city>
<region>MA</region> <region>MA</region>
<code>02026</code> <code>02026</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>michael.faller@gd-ms.com</email> <email>michael.faller@gd-ms.com</email>
<email>MichaelFFaller@gmail.com</email>
</address> </address>
</author> </author>
<author initials="K." surname="Maver" fullname="Keith Maver"> <author initials="K." surname="Maver" fullname="Keith Maver">
<organization>General Dynamics Mission Systems, Inc.</organization> <organization>General Dynamics Mission Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>150 Rustcraft Road</street> <street>150 Rustcraft Road</street>
<city>Dedham</city> <city>Dedham</city>
<region>MA</region> <region>MA</region>
<code>02026</code> <code>02026</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>keith.maver@gd-ms.com</email> <email>keith.maver@gd-ms.com</email>
</address> </address>
</author> </author>
<date year="2024" month="July"/>
<area>WIT</area>
<workgroup>avtcore</workgroup>
<date year="2024" month="February" day="13"/> <!--[rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<workgroup>Payload Working Group</workgroup> <keyword>example</keyword>
<abstract> <!-- [rfced] Because of the abstract's length, we suggest
moving some of its content to the Introduction. As noted in
Section 4.3 of RFC 7322:
Every RFC must have an Abstract that provides a concise and
comprehensive overview of the purpose and contents of the entire
document, to give a technically knowledgeable reader a general
overview of the function of the document....
A satisfactory Abstract can often be
constructed in part from material within the Introduction section,
but an effective Abstract may be shorter, less detailed, and perhaps
broader in scope than the Introduction.
<t>This document describes the RTP payload format of the Secure Please let us know how the text may be updated.
Communication Interoperability Protocol (SCIP). SCIP is an application -->
layer protocol that provides end-to-end capability exchange,
packetization/de-packetization of media, reliable transport, and payload encryp
tion.</t>
<t>SCIP handles packetization/de-packetization of the encrypted media and acts a <abstract>
s a <t>This document describes the RTP payload format of the Secure
Communication Interoperability Protocol (SCIP). SCIP is an application-layer pr
otocol that provides end-to-end capability exchange,
packetization/de-packetization of media, reliable transport, and payload encryp
tion.</t>
<t>SCIP handles packetization/de-packetization of encrypted media and acts
as a
tunneling protocol, treating SCIP payloads as opaque octets to be tunneling protocol, treating SCIP payloads as opaque octets to be
encapsulated within RTP payloads prior to transmission or decapsulated encapsulated within RTP payloads prior to transmission or decapsulated
on reception. SCIP payloads are sized to fit within the maximum transmission un it (MTU) on reception. SCIP payloads are sized to fit within the maximum transmission un it (MTU)
when transported over RTP thereby avoiding fragmentation.</t> when transported over RTP, thereby avoiding fragmentation.</t>
<t>SCIP transmits encrypted traffic and does not require the use of Secure
<t>SCIP transmits encrypted traffic and does not require the use of Secure RTP RTP
(SRTP) for payload protection. SCIP also provides for reliable transport at (SRTP) for payload protection. SCIP also provides for reliable transport at
the application layer, so it is not necessary to negotiate RTCP retransmission capabilities.</t> the application layer, so it is not necessary to negotiate RTCP retransmission capabilities.</t>
<t>To establish reliable communications using SCIP over RTP, it is importa
<t>To establish reliable communications using SCIP over RTP, it is important nt
that middle boxes avoid parsing or modifying SCIP payloads. that middleboxes avoid parsing or modifying SCIP payloads.
Because SCIP payloads are confidentiality and integrity protected and are only decipherable by Because SCIP payloads are confidentiality and integrity protected and are only decipherable by
the originating and receiving SCIP devices, modification of the payload by the originating and receiving SCIP devices, modification of the payload by
middle boxes would be detected as an integrity failure in SCIP devices, middle boxes would be detected as an integrity failure in SCIP devices,
resulting in retransmission and/or communication failure. Middle resulting in retransmission and/or communication failure. Middle
boxes do not need to parse the SCIP payloads to correctly transport them. boxes do not need to parse the SCIP payloads to correctly transport them.
Not only is parsing unnecessary to tunnel/detunnel SCIP within RTP, Not only is parsing unnecessary to tunnel/detunnel SCIP within RTP,
but the parsing and filtering of SCIP payloads by middle boxes would likely lea d to but the parsing and filtering of SCIP payloads by middle boxes would likely lea d to
ossification of the evolving SCIP protocol.</t> ossification of the evolving SCIP protocol.</t>
</abstract> </abstract>
<note>
<name>IESG Note</name>
<t>This IETF specification depends upon a second technical specification
that is not available publicly, namely <xref target="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.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="key-points">
<section anchor="key-points"><name>Key Points</name> <name>Key Points</name>
<!-- section 1 --> <!-- section 1 -->
<ul> <ul>
<li>SCIP is an application layer protocol that uses RTP as a transport. This do <li>SCIP is an application-layer protocol that uses RTP as a transport.
cument defines This document defines
the SCIP media subtypes to be listed in the Session Description Protocol (SDP) a nd only requires the SCIP media subtypes to be listed in the Session Description Protocol (SDP) a nd only requires
a basic RTP transport channel for SCIP payloads. This basic transport channel is comparable to a basic RTP transport channel for SCIP payloads. This basic transport channel is comparable to
<xref target="RFC4040"/> Clearmode.</li> Clearmode as defined by <xref target="RFC4040"/>.</li>
<li>SCIP is designed to be network agnostic. It can operate over any dig
<li>SCIP is designed to be network agnostic. It can operate over any digital lin ital link, including
k, including
non-IP modem-based PSTN and ISDN. The SCIP media subtypes listed in this docume nt were non-IP modem-based PSTN and ISDN. The SCIP media subtypes listed in this docume nt were
developed for SCIP to operate over RTP.</li> developed for SCIP to operate over RTP.</li>
<li>SCIP handles packetization/de-packetization of payloads by producing
<li>SCIP handles packetization/de-packetization of payloads by producing encrypt encrypted media packets
ed media packets
that are not greater than the MTU size. The SCIP payload is opaque to the netwo rk, therefore, SCIP functions that are not greater than the MTU size. The SCIP payload is opaque to the netwo rk, therefore, SCIP functions
as a tunneling protocol for the encrypted media, without the need for middle bo xes to parse SCIP payloads. as a tunneling protocol for the encrypted media, without the need for middle bo xes to parse SCIP payloads.
Since SCIP payloads are integrity protected, modification of the SCIP payload i s detected as an Since SCIP payloads are integrity protected, modification of the SCIP payload i s detected as an
integrity violation by SCIP endpoints leading to communication failure.</li> integrity violation by SCIP endpoints, leading to communication failure.</li>
<li>SCIP includes built-in mechanisms that negotiate protocol message ve
<li>SCIP includes built-in mechanisms that negotiate protocol message versions a rsions and capabilities.
nd capabilities.
To avoid SCIP protocol ossification (as described in <xref target="RFC9170"/>), it is important To avoid SCIP protocol ossification (as described in <xref target="RFC9170"/>), it is important
for middle boxes to not attempt parsing of the SCIP payload. As described in th is document, for middle boxes to not attempt parsing of the SCIP payload. As described in th is document,
such parsing serves no useful purpose.</li></ul> such parsing serves no useful purpose.</li>
</section> </ul>
</section>
<section anchor="introduction"><name>Introduction</name> <section anchor="introduction">
<!-- section 2 --> <name>Introduction</name>
<!-- section 2 -->
<t> <t>
The purpose of this document is to provide enough information to enable SCIP pay loads to be transported The purpose of this document is to provide enough information to enable SCIP pay loads to be transported
through the network without modification or filtering. The document provides a reference for network through the network without modification or filtering. This document provides a reference for network
security policymakers; network equipment OEMs, administrators, and architects; procurement personnel; security policymakers; network equipment OEMs, administrators, and architects; procurement personnel;
and government agency and commercial industry representatives. and government agency and commercial industry representatives.
</t> </t>
<t> <!--[rfced] For ease of the reader, we have formatted the text as a
The document details usage of the "audio/scip" and "video/scip" pseudo-codecs <x list. In addition, we changed the verbs to make these list items more
ref target="AUDIOSCIP"/>, parallel and consistent. Please review and let us know if this conveys
<xref target="VIDEOSCIP"/> as a secure session establishment protocol and media the intended meaning.
transport protocol over RTP.
It discusses (1) how encrypted audio and video codec payloads are transported o
ver RTP;
(2) the IP network layer not implementing SCIP as a protocol since SCIP operate
s at the
application layer in endpoints; (3) the IP network layer enabling SCIP traffic
to transparently
pass through the network; (4) network devices not recognizing SCIP, and thus re
moving the scip
codecs from the SDP media payload declaration before forwarding to the next net
work node; and finally,
(5) SCIP endpoint devices not operating on networks due to the scip media subty
pe removal from the
SDP media payload declaration.
</t>
<t>The United States, along with its NATO Partners, have implemented SCIP in sec Original:
ure voice, video, and It discusses (1) how encrypted audio and video codec payloads are
transported over RTP; (2) the IP network layer not implementing SCIP
as a protocol since SCIP operates at the application layer in
endpoints; (3) the IP network layer enabling SCIP traffic to
transparently pass through the network; (4) network devices not
recognizing SCIP, and thus removing the scip codecs from the SDP
media payload declaration before forwarding to the next network node;
and finally, (5) SCIP endpoint devices not operating on networks due
to the scip media subtype removal from the SDP media payload
declaration.
Perhaps:
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. network devices do not recognize SCIP, and thus 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 due to the scip
media subtype removal from the SDP media payload declaration.
-->
<t>This document details usage of the "audio/scip" <xref
target="AUDIOSCIP"/> and "video/scip" <xref target="VIDEOSCIP"/>
pseudo-codecs as a secure session establishment protocol and media
transport protocol over RTP. It discusses:</t>
<ol spacing="normal">
<li>how encrypted audio and video codec payloads are transported over
RTP;</li>
<li>the IP network layer not implementing SCIP as a protocol since
SCIP operates at the application layer in endpoints;</li>
<li>the IP network layer enabling SCIP traffic to transparently pass
through the network;</li>
<li>network devices not recognizing SCIP, and thus removing the SCIP
codecs from the SDP media payload declaration before forwarding to the
next network node; and finally,</li>
<li>SCIP endpoint devices not operating on networks due to the scip
media subtype removal from the SDP media payload declaration.</li>
</ol>
<t>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 data products operating on commercial, private, and tactical IP networks
worldwide using the scip media subtype. The SCIP data traversing the network is encrypted, 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 str eam in any way. and network equipment in-line with the session cannot interpret the traffic str eam in any way.
SCIP-based RTP traffic is opaque and can vary significantly in structure and fr equency making SCIP-based RTP traffic is opaque and can vary significantly in structure and fr equency, making
traffic profiling not possible. Also, as the SCIP protocol continues to evolve independently 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., dee p packet inspection) of this document, any network device that attempts to filter traffic (e.g., dee p packet inspection)
may cause unintended consequences in the future when changes to the SCIP traffi c may not be recognized by may cause unintended consequences in the future when changes to the SCIP traffi c may not be recognized by
the network device. the network device.
</t> </t>
<t>The SCIP protocol defined in SCIP-210 <xref target="SCIP210"/> includes
<t>The SCIP protocol defined in SCIP-210 <xref target="SCIP210"/> includes built built-in
-in
support for packetization/de-packetization, retransmission, support for packetization/de-packetization, retransmission,
capability exchange, version negotiation, and payload encryption. Since the tra ffic is encrypted, capability exchange, version negotiation, and payload encryption. Since the tra ffic is encrypted,
neither the RTP transport nor middle boxes can usefully parse or modify SCIP neither the RTP transport nor middle boxes can usefully parse or modify SCIP
payloads; modifications are detected as integrity violations resulting in payloads; modifications are detected as integrity violations resulting in
retransmission, and eventually, communication failure.</t> retransmission, and eventually, communication failure.</t>
<t>Because knowledge of the SCIP payload format is not needed to transport
<t>Because knowledge of the SCIP payload format is not needed to transport SCIP SCIP signaling or
signaling or
media through middle boxes, SCIP-210 represents an informative reference. While older versions media through middle boxes, SCIP-210 represents an informative reference. While older versions
of the SCIP-210 specification are publicly available, the authors strongly enco urage of the SCIP-210 specification are publicly available, the authors strongly enco urage
network implementers to treat SCIP payloads as opaque octets. When handled corr ectly, such network implementers to treat SCIP payloads as opaque octets. When handled corr ectly, such
treatment does not require referring to SCIP-210, and any assumptions about the format of 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 a nd SCIP messages defined in SCIP-210 are likely to lead to protocol ossification a nd
communication failures as the protocol evolves.</t> communication failures as the protocol evolves.</t>
<aside>
<aside> <t>Note: The IETF has not conducted a security review of SCIP and theref
<t>Note: The IETF has not conducted a security review of SCIP and therefore has ore has not verified
not verified
the claims contained in this document.</t> the claims contained in this document.</t>
</aside> </aside>
<section anchor="conventions">
<section anchor="conventions"><name>Conventions</name> <name>Conventions</name>
<!-- section 2.1 --> <!-- section 2.1 -->
<t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
"MAY", and "OPTIONAL" in this document are to be interpreted as ",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, a "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nd only when, "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
<t>Best current practices for writing an RTP payload format interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
specification were followed <xref target="RFC2736"/> <xref target="RFC8088"/> target="RFC8174"/> when, and only when, they appear in all capitals, as
.</t> shown here.
</t>
<t>When referring to the Secure Communication Interoperability <t>The best current practices for writing an RTP payload format
specification, as per <xref target="RFC2736"/> and <xref target="RFC8088"/>,
were followed.</t>
<t>When referring to the Secure Communication Interoperability
Protocol, the uppercase acronym "SCIP" is used. When referring Protocol, the uppercase acronym "SCIP" is used. When referring
to the media subtype scip, lowercase "scip" is used.</t> to the media subtype scip, lowercase "scip" is used.</t>
</section>
</section> <section anchor="abbreviations">
<name>Abbreviations</name>
<section anchor="abbreviations"><name>Abbreviations</name> <!-- section 2.2 -->
<!-- section 2.2 -->
<t>The following abbreviations are used in this document.</t> <t>The following abbreviations are used in this document.</t>
<dl newline="false" indent="10" spacing="normal">
<dl newline="false" indent="10" spacing="compact"> <dt>AVP:</dt>
<dt>AVP:</dt> <dd>Audio/Video Profile</dd> <dd>Audio/Video Profile</dd>
<dt>AVPF:</dt> <dd>Audio/Video Profile Feedback</dd> <dt>AVPF:</dt>
<dt>ICWG:</dt> <dd>Interoperability Control Working Group</dd> <dd>Audio/Video Profile Feedback</dd>
<dt>IICWG:</dt> <dd>International Interoperability Control Working Group</dd> <dt>ICWG:</dt>
<dt>NATO:</dt> <dd>North Atlantic Treaty Organization</dd> <dd>Interoperability Control Working Group</dd>
<dt>OEM:</dt> <dd>Original Equipment Manufacturer</dd> <dt>IICWG:</dt>
<dt>SAVP:</dt> <dd>Secure Audio/Video Profile</dd> <dd>International Interoperability Control Working Group</dd>
<dt>SAVPF:</dt> <dd>Secure Audio/Video Profile Feedback</dd> <dt>NATO:</dt>
<dt>SCIP:</dt> <dd>Secure Communication Interoperability Protocol</dd> <dd>North Atlantic Treaty Organization</dd>
<dt>SDP:</dt> <dd>Session Description Protocol</dd> <dt>OEM:</dt>
<dt>SRTP:</dt> <dd>Secure Real-Time Transport Protocol</dd> <dd>Original Equipment Manufacturer</dd>
<dt>STANAG:</dt> <dd>Standardization Agreement</dd> <dt>SAVP:</dt>
</dl> <dd>Secure Audio/Video Profile</dd>
<dt>SAVPF:</dt>
</section> <dd>Secure Audio/Video Profile Feedback</dd>
</section> <dt>SCIP:</dt>
<dd>Secure Communication Interoperability Protocol</dd>
<section anchor="background"><name>Background</name> <dt>SDP:</dt>
<!-- section 3 --> <dd>Session Description Protocol</dd>
<dt>SRTP:</dt>
<dd>Secure Real-Time Transport Protocol</dd>
<dt>STANAG:</dt>
<dd>Standardization Agreement</dd>
</dl>
</section>
</section>
<section anchor="background">
<name>Background</name>
<!-- section 3 -->
<t>The Secure Communication Interoperability Protocol (SCIP) <t>The Secure Communication Interoperability Protocol (SCIP)
allows the negotiation of several voice, data, and video allows the negotiation of several voice, data, and video
applications using various cryptographic suites. SCIP also provides several applications using various cryptographic suites. SCIP also provides several
important characteristics that have led to its broad acceptance as a secure important characteristics that have led to its broad acceptance as a secure
communications protocol.</t> communications protocol.</t>
<t>SCIP began in the United States as the Future Narrowband Digital
<t>SCIP began in the United States as the Future Narrowband Digital
Terminal (FNBDT) Protocol in the late 1990s. A combined U.S. Department of D efense Terminal (FNBDT) Protocol in the late 1990s. A combined U.S. Department of D efense
and vendor consortium formed a governing organization named the and vendor consortium formed a governing organization named the
Interoperability Control Working Group (ICWG) to manage the Interoperability Control Working Group (ICWG) to manage the
protocol. In time, the group expanded to include NATO, NATO protocol. In time, the group expanded to include NATO, NATO
partners and European vendors under the name International partners, and European vendors under the name International
Interoperability Control Working Group (IICWG), which was later Interoperability Control Working Group (IICWG), which was later
renamed the SCIP Working Group.</t> renamed the SCIP Working Group.</t>
<t>First generation SCIP devices operated on circuit-switched
<t>First generation SCIP devices operated on circuit-switched
networks. SCIP was then expanded to radio and IP networks. networks. SCIP was then expanded to radio and IP networks.
The scip media subtype transports SCIP secure session The scip media subtype transports SCIP secure session
establishment signaling and secure application traffic. The establishment signaling and secure application traffic. The
built-in negotiation and flexibility provided by the SCIP built-in negotiation and flexibility provided by the SCIP
protocols make it a natural choice for many scenarios that protocols make it a natural choice for many scenarios that
require various secure applications and associated encryption require various secure applications and associated encryption
suites. SCIP has been adopted by NATO in STANAG 5068. suites. SCIP has been adopted by NATO in STANAG 5068.
SCIP standards are currently available to participating SCIP standards are currently available to participating
government/military communities and select OEMs of equipment government/military communities and select OEMs of equipment
that support SCIP.</t> that support SCIP.</t>
<t>However, SCIP must operate over global networks (including
<t>However, SCIP must operate over global networks (including
private and commercial networks). Without access to necessary private and commercial networks). Without access to necessary
information to support SCIP, some networks may not support the information to support SCIP, some networks may not support the
SCIP media subtypes. Issues may occur simply because SCIP media subtypes. Issues may occur simply because
information is not as readily available to OEMs, network information is not as readily available to OEMs, network
administrators, and network architects.</t> administrators, and network architects.</t>
<t>This document provides essential information about the audio/scip and
<t>This document provides essential information about audio/scip and video/scip media subtypes that enable network equipment
video/scip media subtypes that enables network equipment
manufacturers to include settings for "scip" as a known audio and video media manufacturers to include settings for "scip" as a known audio and video media
subtype in their equipment. This enables network administrators subtype in their equipment. This enables network administrators
to define and implement a compatible security policy which includes audio and to define and implement a compatible security policy that includes audio and
video media subtypes "audio/scip" and "video/scip", respectively, as permitte d video media subtypes "audio/scip" and "video/scip", respectively, as permitte d
codecs on the network.</t> codecs on the network.</t>
<t>All current IP-based SCIP endpoints implement "scip" as a media
<t>All current IP-based SCIP endpoints implement "scip" as a media
subtype. Registration of scip as a media subtype provides a subtype. Registration of scip as a media subtype provides a
common reference for network equipment manufacturers to common reference for network equipment manufacturers to
recognize SCIP in an SDP payload declaration.</t> recognize SCIP in an SDP payload declaration.</t>
</section>
<section anchor="media-format-description">
<name>Payload Format</name>
<!-- section 4 -->
</section> <t>The "scip" media subtype identifies and indicates support for SCIP
traffic that is being transported over RTP. Transcoding, lossy
<section anchor="media-format-description"><name>Payload Format</name> compression, or other data modifications <bcp14>MUST NOT</bcp14> be
<!-- section 4 --> performed by the network on the SCIP RTP payload. The audio/scip and
video/scip media subtype data streams within the network, including the
<t>The "scip" media subtype indicates support for and identifies VoIP network, <bcp14>MUST</bcp14> be a transparent relay and be treated
SCIP traffic that is being transported over RTP. Transcoding, as "clear-channel data", similar to the Clearmode media subtype defined
lossy compression, or other data modifications MUST NOT be by <xref target="RFC4040"/>.</t>
performed by the network on the SCIP RTP payload. The audio/scip and <t><xref target="RFC4040"/> is referenced because Clearmode does not defin
video/scip media subtype data streams within the network, e
including the VoIP network, MUST be a transparent relay and be
treated as "clear-channel data", similar to the Clearmode media
subtype defined by <xref target="RFC4040"/>.</t>
<t>RFC 4040 is referenced because Clearmode does not define
specific RTP payload content, packet size, or packet intervals, but rather specific RTP payload content, packet size, or packet intervals, but rather
enables Clearmode devices to signal that they support a compatible mode of enables Clearmode devices to signal that they support a compatible mode of
operation and defines a transparent channel on which devices may communicate. operation and defines a transparent channel on which devices may communicate.
This document takes a similar approach. Network devices that implement suppor t for This document takes a similar approach. Network devices that implement suppor t for
SCIP need to enable SCIP endpoints to signal that they support SCIP and SCIP need to enable SCIP endpoints to signal that they support SCIP and
provide a transparent channel on which SCIP endpoints may communicate. provide a transparent channel on which SCIP endpoints may communicate.
</t> </t>
<t>SCIP is an application-layer protocol that is defined in SCIP-210.
<t>SCIP is an application layer protocol that is defined in SCIP-210.
The SCIP traffic consists of encrypted SCIP control messages The SCIP traffic consists of encrypted SCIP control messages
and codec data. The payload size and interval will vary considerably depending o n and codec data. The payload size and interval will vary considerably depending o n
the state of the SCIP protocol within the SCIP device.</t> the state of the SCIP protocol within the SCIP device.</t>
<t><xref target="fig-1"/> below illustrates the RTP payload format for SCI
<t>Figure 1 below illustrates the RTP payload format for SCIP.</t> P.</t>
<figure anchor="fig-1">
<figure anchor="fig-1" align="left" suppress-title="false" pn="figure-1"> <name slugifiedName="scip-payload">SCIP RTP Payload Format</name>
<name slugifiedName="scip-payload">SCIP RTP Payload Format</name> <artwork align="left"><![CDATA[
<artwork>
0 1 2 3 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 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 | | RTP Header |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | | |
| SCIP payload | | SCIP Payload |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
<t>The SCIP codec produces an encrypted bitstream that is transported over
<t>The SCIP codec produces an encrypted bitstream that is transported over RTP. RTP. Unlike other
Unlike other
codecs, SCIP does not have its own upper layer syntax (e.g., no Network Adaptati on Layer (NAL) codecs, SCIP does not have its own upper layer syntax (e.g., no Network Adaptati on Layer (NAL)
units), but rather encrypts the output of the audio/video codecs that it uses units), but rather encrypts the output of the audio/video codecs that it uses
(e.g., G.729D, H.264 <xref target="RFC6184"/>, etc.). (e.g., G.729D, H.264 <xref target="RFC6184"/>, etc.).
SCIP achieves this by encapsulating the encrypted codec output that has been pre viously formatted SCIP achieves this by encapsulating the encrypted codec output that has been pre viously formatted
according to the relevant RTP payload specification for that codec. SCIP endpoin according to the relevant RTP payload specification for that codec. SCIP endpoin
ts MAY employ ts <bcp14>MAY</bcp14> employ
mechanisms, such as Inter-media RTP Synchronization as described in <xref target mechanisms, such as inter-media RTP synchronization as described in <xref target
="RFC8088"/> Section 3.3.4, to ="RFC8088" sectionFormat="comma" section="3.3.4"/>, to
synchronize audio/scip and video/scip streams.</t> synchronize audio/scip and video/scip streams.</t>
<t><xref target="fig-2"/> below illustrates notionally how codec packets a
<t>Figure 2 below illustrates notionally how codec packets and SCIP control nd SCIP control
messages are packetized for transmission over RTP.</t> messages are packetized for transmission over RTP.</t>
<figure anchor="fig-2">
<figure anchor="fig-2" align="left" suppress-title="false" pn="figure-2"> <name slugifiedName="scip-architecture">SCIP RTP Architecture</name>
<name slugifiedName="scip-architecture">SCIP RTP Architecture</name> <artwork align="left"><![CDATA[
<artwork>
+-----------+ +-----------------------+ +-----------+ +-----------------------+
| Codec | | SCIP control messages | | Codec | | SCIP control messages |
+-----------+ +-----------------------+ +-----------+ +-----------------------+
| | | |
| | | |
V V V V
+--------------------------------------------------+ +--------------------------------------------------+
| Packetizer* (&lt;= MTU size) | | Packetizer* (<= MTU size) |
+--------------------------------------------------+ +--------------------------------------------------+
| | | |
| | | |
V | V |
+--------------+ | +--------------+ |
| Encryption | | | Encryption | |
+--------------+ | +--------------+ |
| | | |
| | | |
V V V V
+--------------------------------------------------+ +--------------------------------------------------+
| RTP | | RTP |
+--------------------------------------------------+ +--------------------------------------------------+
</artwork> ]]></artwork>
</figure> </figure>
<dl>
<aside><t>* Packetizer: The SCIP application layer will ensure that all traffic <dt>* Packetizer:</dt><dd>The SCIP application layer will ensure that al
sent to l traffic sent to
the RTP layer will not exceed the MTU size. The receiving SCIP RTP layer will handle 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 appl ication packet identification, ordering, and reassembly. When required, the SCIP appl ication
layer handles error detection and retransmission. layer handles error detection and retransmission.</dd>
</t></aside> </dl>
<t>As described above, the SCIP RTP payload format is variable and cannot
<t>As described above, the SCIP RTP payload format is variable and cannot be des be described in
cribed in
specificity in this document. Details can be found in SCIP-210. 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 filter ed SCIP will continue to evolve and, as such, the SCIP RTP traffic <bcp14>MUST NOT< /bcp14> be filtered
by network devices based upon what currently is observed or documented. The focu s of this document is for by network devices based upon what currently is observed or documented. The focu s of this document is for
network devices to consider the SCIP RTP payload as opaque and allow it to trave rse the network devices to consider the SCIP RTP payload as opaque and allow it to trave rse the
network. Network devices MUST NOT modify SCIP RTP packets.</t> network. Network devices <bcp14>MUST NOT</bcp14> modify SCIP RTP packets.</t>
<section anchor="rtp-header-fields">
<section anchor="rtp-header-fields"><name>RTP Header Fields</name> <name>RTP Header Fields</name>
<!-- section 4.1 --> <!-- section 4.1 -->
<t>The SCIP RTP header fields SHALL conform to RFC 3550.</t>
<t>SCIP traffic may be continuous or discontinuous. The Timestamp <t>The SCIP RTP header fields <bcp14>SHALL</bcp14> conform to <xref target="RFC3
field MUST increment based on the sampling clock for 550"/>.</t>
discontinuous transmission as described in <xref target="RFC3550"/>, Section <t>SCIP traffic may be continuous or discontinuous. The Timestamp
5.1. The Timestamp field for continuous transmission field <bcp14>MUST</bcp14> increment based on the sampling clock for
discontinuous transmission as described in <xref target="RFC3550" sectionForm
at="comma" section="5.1"/>. The Timestamp field for continuous transmission
applications is dependent on the sampling rate of the media as applications is dependent on the sampling rate of the media as
specified in the media subtype's specification (e.g., MELPe). specified in the media subtype's specification (e.g., Mixed Excitation Linear Prediction Enhanced (MELPe)).
Note that during a SCIP session, both discontinuous and Note that during a SCIP session, both discontinuous and
continuous traffic are highly probable.</t> continuous traffic are highly probable.</t>
<t>The Marker bit <bcp14>SHALL</bcp14> be set to zero for discontinuous
<t>The Marker bit SHALL be set to zero for discontinuous traffic. traffic.
The Marker bit for continuous traffic is based on the The Marker bit for continuous traffic is based on the
underlying media subtype specification. The underlying media underlying media subtype specification. The underlying media
is opaque within SCIP RTP packets.</t> is opaque within SCIP RTP packets.</t>
</section>
</section> <section anchor="congestion-control">
<name>Congestion Control Considerations</name>
<section anchor="congestion-control"><name>Congestion Control Considerations</na <!-- section 4.2 -->
me>
<!-- section 4.2 -->
<t>The bitrate of SCIP may be adjusted depending on the capability of the underl ying <t>The bitrate of SCIP may be adjusted depending on the capability of the underl ying
codec (such as MELPe <xref target="RFC8130"/>, G.729D <xref target="RFC3551"/ >, etc.). codec (such as MELPe <xref target="RFC8130"/>, G.729D <xref target="RFC3551"/ >, etc.).
The number of encoded audio frames per packet may The number of encoded audio frames per packet may
also be adjusted to control congestion. Discontinuous transmission may also also be adjusted to control congestion. Discontinuous transmission may also
be used if supported by the underlying codec. be used if supported by the underlying codec.
</t> </t>
<t>
<t>
Since UDP does not provide congestion control, applications that use Since UDP does not provide congestion control, applications that use
RTP over UDP SHOULD implement their own congestion control above the RTP over UDP <bcp14>SHOULD</bcp14> implement their own congestion control above
UDP layer <xref target="RFC8085"/> and MAY also implement a transport circuit the
UDP layer <xref target="RFC8085"/> and <bcp14>MAY</bcp14> also implement a trans
port circuit
breaker <xref target="RFC8083"/>. Work in the RTP Media Congestion Avoidance Tec hniques breaker <xref target="RFC8083"/>. Work in the RTP Media Congestion Avoidance Tec hniques
(RMCAT) working group <xref target="RMCAT"/> describes (RMCAT) working group <xref target="RMCAT"/> describes
the interactions and conceptual interfaces necessary between the the interactions and conceptual interfaces necessary between the
application components that relate to congestion control, including application components that relate to congestion control, including
the RTP layer, the higher-level media codec control layer, and the the RTP layer, the higher-level media codec control layer, and the
lower-level transport interface, as well as components dedicated to lower-level transport interface, as well as components dedicated to
congestion control functions. congestion control functions.
</t> </t>
<t>Use of the packet loss feedback mechanisms in AVPF <xref target="RFC4
<t>Use of the packet loss feedback mechanisms in AVPF <xref target="RFC4585"/> a 585"/> and
nd SAVPF <xref target="RFC5124"/> are <bcp14>OPTIONAL</bcp14> because SCIP itself
SAVPF <xref target="RFC5124"/> are OPTIONAL because SCIP itself manages retrans manages retransmissions
missions of some errored or lost packets. Specifically, the payload-specific feedback me
of some errored or lost packets. Specifically, the Payload-Specific Feedback Me ssages
ssages defined in <xref target="RFC4585" sectionFormat="comma" section="6.3"/> are <bc
defined in RFC 4585 section 6.3 are OPTIONAL when transporting video data. p14>OPTIONAL</bcp14> when transporting video data.
</t> </t>
</section>
<section anchor="augmented-protocols">
<name>Use of Augmented RTP Transport Protocols with SCIP</name>
<!-- section 4.3 -->
<!--[rfced] May the title of Section 4.3 be updated as follows,
as this seems redundant (where "RTP" is Real-time Transport Protocol)?
</section> Original: 4.3. Use of Augmented RTP Transport Protocols with SCIP
Perhaps: 4.3. Use of Augmented RTPs with SCIP
<section anchor="augmented-protocols"><name>Use of Augmented RTP Transport Proto
cols with SCIP</name>
<!-- section 4.3 -->
<t>The SCIP application layer protocol uses RTP as a basic transport for the aud
io/scip and
video/scip payloads. Additional RTP transport protocols that do not modify the
SCIP payload
are considered OPTIONAL in this document and are discretionary for a SCIP devic
e vendor to implement.
Some examples include but are not limited to:</t>
<ul>
<li>RTP Payload Format for Generic Forward Error Correction <xref target="RFC510
9"/></li>
<li>Multiplexing RTP Data and Control Packets on a Single Port <xref target="RFC
5761"/></li>
<li>Symmetric RTP/RTP Control Protocol (RTCP) <xref target="RFC4961"/></li>
<li>Negotiating Media Multiplexing Using the Session Description Protocol (BUNDL
E) <xref target="RFC9143"/></li>
</ul>
</section>
</section>
<section anchor="payload-format-parameters"><name>Payload Format Parameters</nam
e>
<!-- section 5 -->
<t>The SCIP RTP payload format is identified using the scip media
subtype, which is registered in accordance with <xref target="RFC4855"/> and
per the media type registration template form <xref target="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".</t>
<section anchor="media-subtype-audioscip"><name>Media Subtype "audio/scip"</name
>
<!-- section 5.1 -->
<t>Media type name: audio</t>
<t>Media subtype name: scip</t>
<t>Required parameters: N/A</t>
<t>Optional parameters: N/A</t>
<t>Encoding considerations: Binary. This media subtype is only
defined for transfer via RTP. There SHALL be no
encoding/decoding (transcoding) of the audio stream as it
traverses the network.</t>
<t>Security considerations: See Section 7.</t>
<t>Interoperability considerations: N/A</t>
<t>Published specifications: <xref target="SCIP210"/></t>
<t>Applications which use this media: N/A</t>
<t>Fragment Identifier considerations: none</t>
<t>Restrictions on usage: N/A</t>
<t>Additional information:</t>
<t indent="3">1. Deprecated alias names for this type: N/A</t>
<t indent="3">2. Magic number(s): N/A</t>
<t indent="3">3. File extension(s): N/A</t>
<t indent="3">4. Macintosh file type code: N/A</t>
<t indent="3">5. Object Identifiers: N/A</t>
<t>Person to contact for further information:</t>
<t indent="3">1. Name: Michael Faller and Daniel Hanson</t>
<t indent="3">2. Email: michael.faller@gd-ms.com and dan.hanson@gd-ms.com</t>
<t>Intended usage: Common</t>
<t>Authors:</t>
<t indent="3">Michael Faller - michael.faller@gd-ms.com</t>
<t indent="3">Daniel Hanson - dan.hanson@gd-ms.com</t>
<t>Change controller:</t>
<t indent="3">SCIP Working Group - ncia.cis3@ncia.nato.int</t>
</section>
<section anchor="media-subtype-videoscip"><name>Media Subtype "video/scip"</name
>
<!-- section 5.2 -->
<t>Media type name: video</t>
<t>Media subtype name: scip</t>
<t>Required parameters: N/A</t>
<t>Optional parameters: N/A</t>
<t>Encoding considerations: Binary. This media subtype is only
defined for transfer via RTP. There SHALL be no
encoding/decoding (transcoding) of the video stream as it
traverses the network.</t>
<t>Security considerations: See Section 7.</t>
<t>Interoperability considerations: N/A</t>
<t>Published specifications: <xref target="SCIP210"/></t> Similarly, may it be updated in "Additional RTP transport protocols that..."?
-->
<t>Applications which use this media: N/A</t> <!--[rfced] The list items below have been updated with quotes
because they are the titles of RFCs.
<t>Fragment Identifier considerations: none</t> FYI, the fourth list item has been updated to match the title of RFC 9143
(where "a.k.a. BUNDLE" is afterwards). Please review.
<t>Restrictions on usage: N/A</t> Original:
Additional RTP transport
protocols 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:
<t>Additional information:</t> * RTP Payload Format for Generic Forward Error Correction [RFC5109]
<t indent="3">1. Deprecated alias names for this type: N/A</t> * Multiplexing RTP Data and Control Packets on a Single Port
[RFC5761]
<t indent="3">2. Magic number(s): N/A</t> * Symmetric RTP/RTP Control Protocol (RTCP) [RFC4961]
<t indent="3">3. File extension(s): N/A</t> * Negotiating Media Multiplexing Using the Session Description
Protocol (BUNDLE) [RFC9143]
<t indent="3">4. Macintosh file type code: N/A</t> Current:
Additional RTP transport protocols 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:
<t indent="3">5. Object Identifiers: N/A</t> * "RTP Payload Format for Generic Forward Error Correction"
[RFC5109]
<t>Person to contact for further information:</t> * "Multiplexing RTP Data and Control Packets on a Single Port"
[RFC5761]
<t indent="3">1. Name: Michael Faller and Daniel Hanson</t> * "Symmetric RTP / RTP Control Protocol (RTCP)" [RFC4961]
<t indent="3">2. Email: michael.faller@gd-ms.com and dan.hanson@gd-ms.com</t> * "Negotiating Media Multiplexing Using the Session Description
Protocol (SDP)" a.k.a. BUNDLE [RFC9143]
-->
<t>Intended usage: Common</t> <t>The SCIP application-layer protocol uses RTP as a basic transport for the aud
io/scip and
video/scip payloads. Additional RTPs that do not modify the SCIP payload
are considered <bcp14>OPTIONAL</bcp14> in this document and are discretionary f
or a SCIP device vendor to implement.
Some examples include, but are not limited to:</t>
<ul>
<li>"RTP Payload Format for Generic Forward Error Correction" <xref ta
rget="RFC5109"/></li>
<li>"Multiplexing RTP Data and Control Packets on a Single Port" <xref
target="RFC5761"/></li>
<li>"Symmetric RTP / RTP Control Protocol (RTCP)" <xref target="RFC496
1"/></li>
<li>"Negotiating Media Multiplexing Using the Session Description Prot
ocol (SDP)" a.k.a.&nbsp;BUNDLE <xref target="RFC9143"/></li>
</ul>
</section>
</section>
<section anchor="payload-format-parameters">
<name>Payload Format Parameters</name>
<!-- section 5 -->
<t>Authors:</t> <t>The SCIP RTP payload format is identified using the scip media
subtype, which is registered in accordance with <xref target="RFC4855"/> and
per the media type registration template from <xref target="RFC6838"/>. A
clock rate of 8000 Hz <bcp14>SHALL</bcp14> be used for "audio/scip". A clock
rate of 90000 Hz <bcp14>SHALL</bcp14> be used for "video/scip".</t>
<section anchor="media-subtype-audioscip">
<t indent="3">Michael Faller - michael.faller@gd-ms.com</t> <!--[rfced] FYI, we made some formatting adjustments to the media type
registrations in Sections 5.1 and 5.2 per the template specified in RFC 6838.
<t indent="3">Daniel Hanson - dan.hanson@gd-ms.com</t> In addition, we have updated the pointer to the security considerations (2 insta nces).
<t>Change controller:</t> Original (links to IANA Considerations):
Security considerations: See Section 7.
<t indent="3">SCIP Working Group - ncia.cis3@ncia.nato.int</t> Current (links to Security Considerations):
Security considerations: See Section 6.
-->
</section> <name>Media Subtype "audio/scip"</name>
<!-- section 5.1 -->
<dl>
<dt>Type name:</dt><dd>audio</dd>
<dt>Subtype name:</dt><dd>scip</dd>
<dt>Required parameters:</dt><dd>N/A</dd>
<dt>Optional parameters:</dt><dd>N/A</dd>
<dt>Encoding considerations:</dt><dd>Binary. This media subtype is
only defined for transfer via RTP. There <bcp14>SHALL</bcp14> be no
encoding/decoding (transcoding) of the audio stream as it traverses
the network.</dd>
<dt>Security considerations:</dt><dd>See <xref target="security-conside
rations"/>.</dd>
<dt>Interoperability considerations:</dt><dd>N/A</dd>
<dt>Published specification:</dt><dd><xref target="SCIP210"/></dd>
<dt>Applications that use this media type:</dt><dd>N/A</dd>
<dt>Fragment identifier considerations:</dt><dd>none</dd>
<dt>Additional information:</dt><dd>
<t><br/></t>
<dl spacing="compact">
<dt>Deprecated alias names for this type:</dt><dd>N/A</dd>
<dt>Magic number(s):</dt><dd>N/A</dd>
<dt>File extension(s):</dt><dd>N/A</dd>
<dt>Macintosh file type code(s):</dt><dd>N/A</dd>
</dl>
</dd>
<dt>Person &amp; email address to contact for further
information:</dt><dd>Michael Faller (michael.faller@gd-ms.com) and
Daniel Hanson (dan.hanson@gd-ms.com)</dd>
<dt>Intended usage:</dt><dd>COMMON</dd>
<dt>Restrictions on usage:</dt><dd>N/A</dd>
<dt>Authors:</dt><dd>Michael Faller (michael.faller@gd-ms.com) and Daniel
Hanson (dan.hanson@gd-ms.com)</dd>
<dt>Change controller:</dt><dd>SCIP Working Group (ncia.cis3@ncia.nato.in
t)</dd>
</dl>
</section>
<section anchor="mapping-to-sdp"><name>Mapping to SDP</name> <section anchor="media-subtype-videoscip">
<!-- section 5.3 --> <name>Media Subtype "video/scip"</name>
<dl>
<dt>Type name:</dt><dd>video</dd>
<dt>Subtype name:</dt><dd>scip</dd>
<dt>Required parameters:</dt><dd>N/A</dd>
<dt>Optional parameters:</dt><dd>N/A</dd>
<dt>Encoding considerations:</dt><dd>Binary. This media subtype is
only defined for transfer via RTP. There <bcp14>SHALL</bcp14> be no
encoding/decoding (transcoding) of the video stream as it traverses
the network.</dd>
<dt>Security considerations:</dt><dd>See <xref target="security-considera
tions"/>.</dd>
<dt>Interoperability considerations:</dt><dd>N/A</dd>
<dt>Published specification:</dt><dd><xref target="SCIP210"/></dd>
<dt>Applications that use this media type:</dt><dd>N/A</dd>
<dt>Fragment identifier considerations:</dt><dd>none</dd>
<dt>Additional information:</dt><dd>
<t><br/></t>
<dl spacing="compact">
<dt>Deprecated alias names for this type:</dt><dd>N/A</dd>
<dt>Magic number(s):</dt><dd>N/A</dd>
<dt>File extension(s):</dt><dd>N/A</dd>
<dt>Macintosh file type code(s):</dt><dd>N/A</dd>
</dl>
</dd>
<dt>Person &amp; email address to contact for further information:</dt><dd
>Michael
Faller (michael.faller@gd-ms.com) and Daniel Hanson
(dan.hanson@gd-ms.com)</dd>
<dt>Intended usage:</dt><dd>COMMON</dd>
<dt>Restrictions on usage:</dt><dd>N/A</dd>
<dt>Authors:</dt><dd>Michael Faller (michael.faller@gd-ms.com) and Daniel
Hanson (dan.hanson@gd-ms.com)</dd>
<dt>Change controller:</dt><dd>SCIP Working Group (ncia.cis3@ncia.nato.int
)</dd>
</dl>
</section>
<t>The mapping of the above defined payload format media subtype <section anchor="mapping-to-sdp">
and its parameters SHALL be implemented according to Section 3 <name>Mapping to SDP</name>
of <xref target="RFC4855"/>.</t> <!-- section 5.3 -->
<t>Since SCIP includes its own facilities for capabilities exchange, <t>The mapping of the above-defined payload format media subtype
and its parameters <bcp14>SHALL</bcp14> be implemented according to <xref tar
get="RFC4855" sectionFormat="of" section="3"/>.</t>
<t>Since SCIP includes its own facilities for capabilities exchange,
it is only necessary to negotiate the use of SCIP within SDP Offer/Answer; 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 specific codecs to be encapsulated within SCIP are then negotiated via
the exchange of SCIP control messages.</t> the exchange of SCIP control messages.</t>
<t>The information carried in the media type specification has a
<t>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)
<xref target="RFC8866"/>, which is commonly used to describe RTP sessions. <xref target="RFC8866"/>, which is commonly used to describe RTP sessions.
When SDP is used to specify sessions employing the SCIP codec, the mapping When SDP is used to specify sessions employing the SCIP codec, the mapping
is as follows:</t> is as follows:</t>
<ul>
<ul> <li>The media type ("audio") goes in SDP "m=" as the media name for au
<li>The media type ("audio") goes in SDP "m=" as the media name for audio/scip, dio/scip,
and the media type ("video") goes in SDP "m=" as the media name for video/scip.< /li> and the media type ("video") goes in SDP "m=" as the media name for video/scip.< /li>
<li>The media subtype ("scip") goes in SDP "a=rtpmap" as the encoding name. <li>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.</li> The required parameter "rate" also goes in "a=rtpmap" as the clock rate.</li>
<li>The optional parameters "ptime" and "maxptime" go in the SDP "a=ptime" and <li>The optional parameters "ptime" and "maxptime" go in the SDP "a=pt ime" and
"a=maxptime" attributes, respectively.</li> "a=maxptime" attributes, respectively.</li>
</ul> </ul>
<t>An example mapping for audio/scip is:</t>
<t>An example mapping for audio/scip is:</t> <artwork><![CDATA[
m=audio 50000 RTP/AVP 96
<figure>
<artwork>
<![CDATA[ m=audio 50000 RTP/AVP 96
a=rtpmap:96 scip/8000]]>
</artwork>
</figure>
<t>An example mapping for video/scip is:</t>
<figure>
<artwork>
<![CDATA[ m=video 50002 RTP/AVP 97
a=rtpmap:97 scip/90000]]>
</artwork>
</figure>
<t>An example mapping for both audio/scip and video/scip is:</t>
<figure>
<artwork>
<![CDATA[ m=audio 50000 RTP/AVP 96
a=rtpmap:96 scip/8000 a=rtpmap:96 scip/8000
]]></artwork>
<t>An example mapping for video/scip is:</t>
<artwork><![CDATA[
m=video 50002 RTP/AVP 97 m=video 50002 RTP/AVP 97
a=rtpmap:97 scip/90000]]> a=rtpmap:97 scip/90000
</artwork> ]]></artwork>
</figure> <t>An example mapping for both audio/scip and video/scip is:</t>
<artwork><![CDATA[
</section> m=audio 50000 RTP/AVP 96
a=rtpmap:96 scip/8000
<section anchor="sdp-offeranswer-considerations"><name>SDP Offer/Answer Consider m=video 50002 RTP/AVP 97
ations</name> a=rtpmap:97 scip/90000
<!-- section 5.4 --> ]]></artwork>
</section>
<section anchor="sdp-offeranswer-considerations">
<name>SDP Offer/Answer Considerations</name>
<!-- section 5.4 -->
<t>In accordance with the SDP Offer/Answer model <xref target="RFC3264"/>, the <t>In accordance with the SDP Offer/Answer model <xref target="RFC3264"/>, the
SCIP device SHALL list the SCIP payload type number in order of SCIP device <bcp14>SHALL</bcp14> list the SCIP payload type number in order o f
preference in the "m" media line.</t> preference in the "m" media line.</t>
<t>For example, an SDP Offer with scip as the preferred audio media subt
<t>For example, an SDP Offer with scip as the preferred audio media subtype:</t> ype:</t>
<artwork><![CDATA[
<figure> m=audio 50000 RTP/AVP 96 0 8
<artwork>
<![CDATA[ m=audio 50000 RTP/AVP 96 0 8
a=rtpmap:96 scip/8000 a=rtpmap:96 scip/8000
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000]]> a=rtpmap:8 PCMA/8000
</artwork> ]]></artwork>
</figure> </section>
</section>
</section> <section anchor="security-considerations">
</section> <name>Security Considerations</name>
<!-- section 6 -->
<section anchor="security-considerations"><name>Security Considerations</name>
<!-- section 6 -->
<t>RTP packets using the payload format defined in this <t>RTP packets using the payload format defined in this
specification are subject to the security considerations specification are subject to the security considerations
discussed in the RTP specification <xref target="RFC3550"/>, and in any discussed in the RTP specification <xref target="RFC3550"/>, and in any
applicable RTP profile such as RTP/AVP <xref target="RFC3551"/>, RTP/AVPF applicable RTP profile such as RTP/AVP <xref target="RFC3551"/>, RTP/AVPF
<xref target="RFC4585"/>, RTP/SAVP <xref target="RFC3711"/>, or RTP/SAVPF <xr ef target="RFC5124"/>. <xref target="RFC4585"/>, RTP/SAVP <xref target="RFC3711"/>, or RTP/SAVPF <xr ef target="RFC5124"/>.
However, as "Securing the RTP Protocol Framework: Why RTP Does However, as "Securing the RTP Framework: Why RTP Does
Not Mandate a Single Media Security Solution" <xref target="RFC7202"/> Not Mandate a Single Media Security Solution" <xref target="RFC7202"/>
discusses, it is not an RTP payload format's responsibility to discusses, it is not an RTP payload format's responsibility to
discuss or mandate what solutions are used to meet the basic discuss or mandate what solutions are used to meet the basic
security goals like confidentiality, integrity, and source security goals like confidentiality, integrity, and source
authenticity for RTP in general. This responsibility lies on authenticity for RTP in general. This responsibility lies on
anyone using RTP in an application. They can find guidance on anyone using RTP in an application. They can find guidance on
available security mechanisms and important considerations in available security mechanisms and important considerations in
"Options for Securing RTP Sessions" <xref target="RFC7201"/>. "Options for Securing RTP Sessions" <xref target="RFC7201"/>.
Applications SHOULD use one or more appropriate strong security mechanisms. Applications <bcp14>SHOULD</bcp14> use one or more appropriate strong securit y mechanisms.
The rest of this Security Considerations section discusses the The rest of this Security Considerations section discusses the
security impacting properties of the payload format itself.</t> security impacting properties of the payload format itself.</t>
<t>This RTP payload format and its media decoder do not exhibit
<t>This RTP payload format and its media decoder do not exhibit
any significant non-uniformity in the receiver-side any significant non-uniformity in the receiver-side
computational complexity for packet processing, and thus do not computational complexity for packet processing, and thus do not
inherently pose a denial-of-service threat due to the receipt inherently pose a denial-of-service threat due to the receipt
of pathological data. Nor does the RTP payload format contain of pathological data, nor does the RTP payload format contain
any active content.</t> any active content.</t>
<t>SCIP only encrypts the contents transported in the RTP payload; it does
<t>SCIP only encrypts the contents transported in the RTP payload; it does not p not protect
rotect the RTP header or RTCP packets. Applications requiring additional RTP headers
the RTP header or RTCP packets. Applications requiring additional RTP header a and/or
nd/or
RTCP security might consider mechanisms such as SRTP <xref target="RFC3711"/>, RTCP security might consider mechanisms such as SRTP <xref target="RFC3711"/>,
however these additional mechanisms are considered OPTIONAL in this document.< however these additional mechanisms are considered <bcp14>OPTIONAL</bcp14> in
/t> this document.</t>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<!-- section 7 -->
</section> <t>The audio/scip and video/scip media subtypes have previously been registered
with IANA <xref target="AUDIOSCIP"/> <xref target="VIDEOSCIP"/>. IANA should
update <xref target="AUDIOSCIP"/> and <xref target="VIDEOSCIP"/> to
reference this document upon publication.</t>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name> <!--[rfced] Does the "IANA should update..." sentence below request
<!-- section 7 --> that IANA
A) update the references within the registrations (which are in
Sections 5.1 and 5.2) to point to this RFC rather than [SCIP210], or
B) update the Reference column in the media type registry (https://www.iana.org/
assignments/media-types)
<t>The audio/scip and video/scip media subtypes have previously Original:
been registered with IANA <xref target="AUDIOSCIP"/> <xref target="VIDEOSCIP" The audio/scip and video/scip media subtypes have previously been
/>. IANA should registered with IANA [AUDIOSCIP] [VIDEOSCIP]. IANA should update
update <xref target="AUDIOSCIP"/> and <xref target="VIDEOSCIP"/> to reference [AUDIOSCIP] and [VIDEOSCIP] to reference this document upon
this document publication.
upon publication.</t>
</section> Assuming (B) was your intention, we suggest the following update.
Please let us know if you agree.
<section anchor="scip-contact-info"><name>SCIP Contact Information</name> Suggested:
<!-- section 8 --> 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.
In addition, Section 2 would be updated accordingly:
Original:
The document details usage of the "audio/scip" and "video/scip"
pseudo-codecs [AUDIOSCIP], [VIDEOSCIP] as a secure session
establishment protocol and media transport protocol over RTP.
Suggested:
The 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.
where the reference is as follows:
[MediaTypes] IANA, "Media Types",
<https://www.iana.org/assignments/media-types>.
-->
<section anchor="scip-contact-info">
<name>SCIP Contact Information</name>
<!-- section 8 -->
<t>The SCIP protocol is maintained by the SCIP Working Group. The current SCIP- 210 <t>The SCIP protocol is maintained by the SCIP Working Group. The current SCIP- 210
specification may be requested from the email address below. specification may be requested from the email address below.
</t> </t>
<contact>
<t> <organization>SCIP Working Group, CIS3 Partnership</organization>
SCIP Working Group, CIS3 Partnership<br/> <address>
NATO Communications and Information Agency<br/> <postal>
Oude Waalsdorperweg 61<br/> <postalLine>NATO Communications and Information Agency</postalLine>
2597 AK The Hague, Netherlands<br/> <postalLine>Oude Waalsdorperweg 61</postalLine>
Email: ncia.cis3@ncia.nato.int</t> <postalLine>2597 AK The Hague, Netherlands</postalLine>
</postal>
<t>An older public version of the SCIP-210 specification can be downloaded <email>ncia.cis3@ncia.nato.int</email>
</address>
</contact>
<t>An older public version of the SCIP-210 specification can be downloaded
from <eref target="https://www.iad.gov/SecurePhone/index.cfm"/>. from <eref target="https://www.iad.gov/SecurePhone/index.cfm"/>.
</t> </t>
</section>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
736.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
264.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
550.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
551.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
711.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
585.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
124.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
866.xml"/>
</references>
<references>
<name>Informative References</name>
<references title='Normative References'> <reference anchor="AUDIOSCIP" target="https://www.iana.org/assignments/m
edia-types/audio/scip">
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'> <front>
<front> <title>audio/scip</title>
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <author>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a <organization>IANA</organization>
uthor> </author>
<date month='March' year='1997'/> </front>
<abstract><t>In many standards track documents several words are used to signify </reference>
the requirements in the specification. These words are often capitalized. This
document defines these words as they should be interpreted in IETF documents.
This document specifies an Internet Best Current Practices for the Internet Comm
unity, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC2736' target='https://www.rfc-editor.org/info/rfc2736'>
<front>
<title>Guidelines for Writers of RTP Payload Format Specifications</title>
<author fullname='M. Handley' initials='M.' surname='Handley'><organization/></a
uthor>
<author fullname='C. Perkins' initials='C.' surname='Perkins'><organization/></a
uthor>
<date month='December' year='1999'/>
<abstract><t>This document provides general guidelines aimed at assisting the au
thors of RTP Payload Format specifications in deciding on good formats. This do
cument specifies an Internet Best Current Practices for the Internet Community,
and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='36'/>
<seriesInfo name='RFC' value='2736'/>
<seriesInfo name='DOI' value='10.17487/RFC2736'/>
</reference>
<reference anchor='RFC3264' target='https://www.rfc-editor.org/info/rfc3264'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<front> 040.xml"/>
<title>An Offer/Answer Model with Session Description Protocol (SDP)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname='J. Rosenberg' initials='J.' surname='Rosenberg'><organization/ 855.xml"/>
></author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organizat 961.xml"/>
ion/></author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<date month='June' year='2002'/> 109.xml"/>
<abstract><t>This document defines a mechanism by which two entities can make us <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
e of the Session Description Protocol (SDP) to arrive at a common view of a mult 761.xml"/>
imedia session between them. In the model, one participant offers the other a d <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
escription of the desired session from their perspective, and the other particip 184.xml"/>
ant answers with the desired session from their perspective. This offer/answer <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
model is most useful in unicast sessions where information from both participant 838.xml"/>
s is needed for the complete view of the session. The offer/answer model is use <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
d by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]</t 201.xml"/>
></abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
</front> 202.xml"/>
<seriesInfo name='RFC' value='3264'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name='DOI' value='10.17487/RFC3264'/> 083.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
085.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
088.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
130.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
143.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
170.xml"/>
<reference anchor='RFC3550' target='https://www.rfc-editor.org/info/rfc3550'> <reference anchor="RMCAT" target="https://datatracker.ietf.org/wg/rmcat/
<front> about">
<title>RTP: A Transport Protocol for Real-Time Applications</title> <front>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organizat <title>RTP Media Congestion Avoidance Techniques (rmcat)</title>
ion/></author> <author>
<author fullname='S. Casner' initials='S.' surname='Casner'><organization/></aut <organization>IETF</organization>
hor> </author>
<author fullname='R. Frederick' initials='R.' surname='Frederick'><organization/ </front>
></author> </reference>
<author fullname='V. Jacobson' initials='V.' surname='Jacobson'><organization/><
/author>
<date month='July' year='2003'/>
<abstract><t>This memorandum describes RTP, the real-time transport protocol. R
TP provides end-to-end network transport functions suitable for applications tra
nsmitting real-time data, such as audio, video or simulation data, over multicas
t or unicast network services. RTP does not address resource reservation and do
es not guarantee quality-of- service for real-time services. The data transport
is augmented by a control protocol (RTCP) to allow monitoring of the data deliv
ery in a manner scalable to large multicast networks, and to provide minimal con
trol and identification functionality. RTP and RTCP are designed to be independ
ent of the underlying transport and network layers. The protocol supports the u
se of RTP-level translators and mixers. Most of the text in this memorandum is i
dentical to RFC 1889 which it obsoletes. There are no changes in the packet for
mats on the wire, only changes to the rules and algorithms governing how the pro
tocol is used. The biggest change is an enhancement to the scalable timer algori
thm for calculating when to send RTCP packets in order to minimize transmission
in excess of the intended rate when many participants join a session simultaneou
sly. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='64'/>
<seriesInfo name='RFC' value='3550'/>
<seriesInfo name='DOI' value='10.17487/RFC3550'/>
</reference>
<reference anchor='RFC3551' target='https://www.rfc-editor.org/info/rfc3551'> <!--[rfced] The URL provided in the text and reference below gives the
<front> message "Warning: Potential Security Risk Ahead" (Firefox) and
<title>RTP Profile for Audio and Video Conferences with Minimal Control</title> "Your connection is not private" (Chrome). Is there an alternative URL
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organizat available for this resource?
ion/></author>
<author fullname='S. Casner' initials='S.' surname='Casner'><organization/></aut
hor>
<date month='July' year='2003'/>
<abstract><t>This document describes a profile called &quot;RTP/AVP&quot; for th
e use of the real-time transport protocol (RTP), version 2, and the associated c
ontrol protocol, RTCP, within audio and video multiparticipant conferences with
minimal control. It provides interpretations of generic fields within the RTP s
pecification suitable for audio and video conferences. In particular, this docu
ment defines a set of default mappings from payload type numbers to encodings. T
his document also describes how audio and video data may be carried within RTP.
It defines a set of standard encodings and their names when used within RTP. T
he descriptions provide pointers to reference implementations and the detailed s
tandards. This document is meant as an aid for implementors of audio, video and
other real-time multimedia applications. This memorandum obsoletes RFC 1890. I
t is mostly backwards-compatible except for functions removed because two intero
perable implementations were not found. The additions to RFC 1890 codify existi
ng practice in the use of payload formats under this profile and include new pay
load formats defined since RFC 1890 was published. [STANDARDS-TRACK]</t></abstr
act>
</front>
<seriesInfo name='STD' value='65'/>
<seriesInfo name='RFC' value='3551'/>
<seriesInfo name='DOI' value='10.17487/RFC3551'/>
</reference>
<reference anchor='RFC3711' target='https://www.rfc-editor.org/info/rfc3711'> Original (in Section 8, SCIP Contact Information):
<front>
<title>The Secure Real-time Transport Protocol (SRTP)</title>
<author fullname='M. Baugher' initials='M.' surname='Baugher'><organization/></a
uthor>
<author fullname='D. McGrew' initials='D.' surname='McGrew'><organization/></aut
hor>
<author fullname='M. Naslund' initials='M.' surname='Naslund'><organization/></a
uthor>
<author fullname='E. Carrara' initials='E.' surname='Carrara'><organization/></a
uthor>
<author fullname='K. Norrman' initials='K.' surname='Norrman'><organization/></a
uthor>
<date month='March' year='2004'/>
<abstract><t>This document describes the Secure Real-time Transport Protocol (SR
TP), a profile of the Real-time Transport Protocol (RTP), which can provide conf
identiality, message authentication, and replay protection to the RTP traffic an
d to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP
). [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3711'/>
<seriesInfo name='DOI' value='10.17487/RFC3711'/>
</reference>
<reference anchor='RFC4585' target='https://www.rfc-editor.org/info/rfc4585'> An older public version of the SCIP-210 specification can be
<front> downloaded from https://www.iad.gov/SecurePhone/index.cfm.
<title>Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Base
d Feedback (RTP/AVPF)</title>
<author fullname='J. Ott' initials='J.' surname='Ott'><organization/></author>
<author fullname='S. Wenger' initials='S.' surname='Wenger'><organization/></aut
hor>
<author fullname='N. Sato' initials='N.' surname='Sato'><organization/></author>
<author fullname='C. Burmeister' initials='C.' surname='Burmeister'><organizatio
n/></author>
<author fullname='J. Rey' initials='J.' surname='Rey'><organization/></author>
<date month='July' year='2006'/>
<abstract><t>Real-time media streams that use RTP are, to some degree, resilient
against packet losses. Receivers may use the base mechanisms of the Real-time
Transport Control Protocol (RTCP) to report packet reception statistics and thus
allow a sender to adapt its transmission behavior in the mid-term. This is the
sole means for feedback and feedback-based error repair (besides a few codec-sp
ecific mechanisms). This document defines an extension to the Audio-visual Prof
ile (AVP) that enables receivers to provide, statistically, more immediate feedb
ack to the senders and thus allows for short-term adaptation and efficient feedb
ack-based repair mechanisms to be implemented. This early feedback profile (AVP
F) maintains the AVP bandwidth constraints for RTCP and preserves scalability to
large groups. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4585'/>
<seriesInfo name='DOI' value='10.17487/RFC4585'/>
</reference>
<reference anchor='RFC5124' target='https://www.rfc-editor.org/info/rfc5124'> Original (in Section 9.2, Informative References):
<front>
<title>Extended Secure RTP Profile for Real-time Transport Control Protocol (RTC
P)-Based Feedback (RTP/SAVPF)</title>
<author fullname='J. Ott' initials='J.' surname='Ott'><organization/></author>
<author fullname='E. Carrara' initials='E.' surname='Carrara'><organization/></a
uthor>
<date month='February' year='2008'/>
<abstract><t>An RTP profile (SAVP) for secure real-time communications and anoth
er profile (AVPF) to provide timely feedback from the receivers to a sender are
defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combina
tion of both profiles to enable secure RTP communications with feedback. [STAND
ARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5124'/>
<seriesInfo name='DOI' value='10.17487/RFC5124'/>
</reference>
<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'> [SCIP210] SCIP Working Group, "SCIP Signaling Plan", SCIP-210,
<front> r3.11, September 2023,
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <https://www.iad.gov/SecurePhone/index.cfm>.
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho -->
r>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor='RFC8866' target='https://www.rfc-editor.org/info/rfc8866'> <reference anchor="SCIP210" target="https://www.iad.gov/SecurePhone/inde
<front> x.cfm">
<title>SDP: Session Description Protocol</title> <front>
<author fullname='A. Begen' initials='A.' surname='Begen'><organization/></autho <title>SCIP Signaling Plan</title>
r> <author>
<author fullname='P. Kyzivat' initials='P.' surname='Kyzivat'><organization/></a <organization>SCIP Working Group</organization>
uthor> </author>
<author fullname='C. Perkins' initials='C.' surname='Perkins'><organization/></a <date year="2023" month="September"/>
uthor> </front>
<author fullname='M. Handley' initials='M.' surname='Handley'><organization/></a <refcontent>SCIP-210, r3.11</refcontent>
uthor> </reference>
<date month='January' year='2021'/>
<abstract><t>This memo defines the Session Description Protocol (SDP). SDP is in
tended for describing multimedia sessions for the purposes of session announceme
nt, session invitation, and other forms of multimedia session initiation. This d
ocument obsoletes RFC 4566.</t></abstract>
</front>
<seriesInfo name='RFC' value='8866'/>
<seriesInfo name='DOI' value='10.17487/RFC8866'/>
</reference>
<reference anchor="VIDEOSCIP" target="https://www.iana.org/assignments/m
edia-types/video/scip">
<front>
<title>video/scip</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
</references>
</references> </references>
</back>
<references title='Informative References'> <!--[rfced] Please review the following questions and changes regarding the
terminology used in this document.
<reference anchor="AUDIOSCIP" target="https://www.iana.org/assignments/media-typ
es/audio/scip">
<front>
<title>audio/scip: Internet Assigned Numbers Authority (IANA)</title>
<author initials="M." surname="Faller">
<organization></organization>
</author>
<author initials="D." surname="Hanson">
<organization></organization>
</author>
<date year="2021" month="January" day="28"/>
</front>
</reference>
<reference anchor='RFC4040' target='https://www.rfc-editor.org/info/rfc4040'>
<front>
<title>RTP Payload Format for a 64 kbit/s Transparent Call</title>
<author fullname='R. Kreuter' initials='R.' surname='Kreuter'><organization/></a
uthor>
<date month='April' year='2005'/>
<abstract><t>This document describes how to carry 64 kbit/s channel data transpa
rently in RTP packets, using a pseudo-codec called &quot;Clearmode&quot;. It al
so serves as registration for a related MIME type called &quot;audio/clearmode&q
uot;.</t><t>&quot;Clearmode&quot; is a basic feature of VoIP Media Gateways. [S
TANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4040'/>
<seriesInfo name='DOI' value='10.17487/RFC4040'/>
</reference>
<reference anchor='RFC4855' target='https://www.rfc-editor.org/info/rfc4855'>
<front>
<title>Media Type Registration of RTP Payload Formats</title>
<author fullname='S. Casner' initials='S.' surname='Casner'><organization/></aut
hor>
<date month='February' year='2007'/>
<abstract><t>This document specifies the procedure to register RTP payload forma
ts as audio, video, or other media subtype names. This is useful in a text-base
d format description or control protocol to identify the type of an RTP transmis
sion. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4855'/>
<seriesInfo name='DOI' value='10.17487/RFC4855'/>
</reference>
<reference anchor="RFC4961" target="https://www.rfc-editor.org/info/rfc4961">
<front>
<title>Symmetric RTP / RTP Control Protocol (RTCP)</title>
<author fullname="D. Wing" initials="D." surname="Wing"/>
<date month="July" year="2007"/>
<abstract>
<t>This document recommends using one UDP port pair for both communication direc
tions of bidirectional RTP and RTP Control Protocol (RTCP) sessions, commonly ca
lled "symmetric RTP" and "symmetric RTCP". This document specifies an Internet B
est Current Practices for the Internet Community, and requests discussion and su
ggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="131"/>
<seriesInfo name="RFC" value="4961"/>
<seriesInfo name="DOI" value="10.17487/RFC4961"/>
</reference>
<reference anchor="RFC5109" target="https://www.rfc-editor.org/info/rfc5109"> a. We note the use of scip, audio/scip, and video/scip with and without quotes
<front> throughout this document (as seen in the example below). How would you like
<title>RTP Payload Format for Generic Forward Error Correction</title> these terms to appear for consistency?
<author fullname="A. Li" initials="A." role="editor" surname="Li"/>
<date month="December" year="2007"/>
<abstract>
<t>This document specifies a payload format for generic Forward Error Correction
(FEC) for media data encapsulated in RTP. It is based on the exclusive-or (pari
ty) operation. The payload format described in this document allows end systems
to apply protection using various protection lengths and levels, in addition to
using various protection group sizes to adapt to different media and channel cha
racteristics. It enables complete recovery of the protected packets or partial r
ecovery of the critical parts of the payload depending on the packet loss situat
ion. This scheme is completely compatible with non-FEC-capable hosts, so the rec
eivers in a multicast group that do not implement FEC can still work by simply i
gnoring the protection data. This specification obsoletes RFC 2733 and RFC 3009.
The FEC specified in this document is not backward compatible with RFC 2733 and
RFC 3009. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5109"/>
<seriesInfo name="DOI" value="10.17487/RFC5109"/>
</reference>
<reference anchor="RFC5761" target="https://www.rfc-editor.org/info/rfc5761"> Original:
<front> This document provides essential information about audio/scip and
<title>Multiplexing RTP Data and Control Packets on a Single Port</title> video/scip media subtypes that enables network equipment
<author fullname="C. Perkins" initials="C." surname="Perkins"/> manufacturers to include settings for "scip" as a known audio and
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/> video media subtype in their equipment. This enables network
<date month="April" year="2010"/> administrators to define and implement a compatible security policy
<abstract> which includes audio and video media subtypes "audio/scip" and
<t>This memo discusses issues that arise when multiplexing RTP data packets and "video/scip", respectively, as permitted codecs on the network.
RTP Control Protocol (RTCP) packets on a single UDP port. It updates RFC 3550 an
d RFC 3551 to describe when such multiplexing is and is not appropriate, and it
explains how the Session Description Protocol (SDP) can be used to signal multip
lexed sessions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5761"/>
<seriesInfo name="DOI" value="10.17487/RFC5761"/>
</reference>
<reference anchor='RFC6184' target='https://www.rfc-editor.org/info/rfc6184'> b. Please review usage of the "/" character throughout. In the instances
<front> below, it may be unclear to a reader whether the "/" stands for "and" or
<title>RTP Payload Format for H.264 Video</title> "or". For clarity, we recommend updating these instances to "and", "or", or
<author fullname='Y.-K. Wang' initials='Y.-K.' surname='Wang'><organization/></a "and/or".
uthor>
<author fullname='R. Even' initials='R.' surname='Even'><organization/></author>
<author fullname='T. Kristensen' initials='T.' surname='Kristensen'><organizatio
n/></author>
<author fullname='R. Jesup' initials='R.' surname='Jesup'><organization/></autho
r>
<date month='May' year='2011'/>
<abstract><t>This memo describes an RTP Payload format for the ITU-T Recommendat
ion H.264 video codec and the technically identical ISO/IEC International Standa
rd 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and
the Multiview Video Coding extension, for which the RTP payload formats are def
ined elsewhere. The RTP payload format allows for packetization of one or more N
etwork Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in e
ach RTP payload. The payload format has wide applicability, as it supports appl
ications from simple low bitrate conversational usage, to Internet video streami
ng with interleaved transmission, to high bitrate video-on-demand.</t><t>This me
mo obsoletes RFC 3984. Changes from RFC 3984 are summarized in Section 14. Iss
ues on backward compatibility to RFC 3984 are discussed in Section 15. [STANDAR
DS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6184'/>
<seriesInfo name='DOI' value='10.17487/RFC6184'/>
</reference>
<reference anchor='RFC6838' target='https://www.rfc-editor.org/info/rfc6838'> Originals:
<front> SCIP is an application layer protocol that provides end-to-end capability
<title>Media Type Specifications and Registration Procedures</title> exchange, packetization/de-packetization of media...
<author fullname='N. Freed' initials='N.' surname='Freed'><organization/></autho
r>
<author fullname='J. Klensin' initials='J.' surname='Klensin'><organization/></a
uthor>
<author fullname='T. Hansen' initials='T.' surname='Hansen'><organization/></aut
hor>
<date month='January' year='2013'/>
<abstract><t>This document defines procedures for the specification and registra
tion of media types for use in HTTP, MIME, and other Internet protocols. This m
emo documents an Internet Best Current Practice.</t></abstract>
</front>
<seriesInfo name='BCP' value='13'/>
<seriesInfo name='RFC' value='6838'/>
<seriesInfo name='DOI' value='10.17487/RFC6838'/>
</reference>
<reference anchor='RFC7201' target='https://www.rfc-editor.org/info/rfc7201'> Not only is parsing unnecessary to tunnel/detunnel SCIP within RTP...
<front>
<title>Options for Securing RTP Sessions</title>
<author fullname='M. Westerlund' initials='M.' surname='Westerlund'><organizatio
n/></author>
<author fullname='C. Perkins' initials='C.' surname='Perkins'><organization/></a
uthor>
<date month='April' year='2014'/>
<abstract><t>The Real-time Transport Protocol (RTP) is used in a large number of
different application domains and environments. This heterogeneity implies tha
t different security mechanisms are needed to provide services such as confident
iality, integrity, and source authentication of RTP and RTP Control Protocol (RT
CP) packets suitable for the various environments. The range of solutions makes
it difficult for RTP-based application developers to pick the most suitable mec
hanism. This document provides an overview of a number of security solutions fo
r RTP and gives guidance for developers on how to choose the appropriate securit
y mechanism.</t></abstract>
</front>
<seriesInfo name='RFC' value='7201'/>
<seriesInfo name='DOI' value='10.17487/RFC7201'/>
</reference>
<reference anchor='RFC7202' target='https://www.rfc-editor.org/info/rfc7202'> SCIP standards are currently available to participating government/
<front> military communities...
<title>Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Secur
ity Solution</title>
<author fullname='C. Perkins' initials='C.' surname='Perkins'><organization/></a
uthor>
<author fullname='M. Westerlund' initials='M.' surname='Westerlund'><organizatio
n/></author>
<date month='April' year='2014'/>
<abstract><t>This memo discusses the problem of securing real-time multimedia se
ssions. It also explains why the Real-time Transport Protocol (RTP) and the ass
ociated RTP Control Protocol (RTCP) do not mandate a single media security mecha
nism. This is relevant for designers and reviewers of future RTP extensions to
ensure that appropriate security mechanisms are mandated and that any such mecha
nisms are specified in a manner that conforms with the RTP architecture.</t></ab
stract>
</front>
<seriesInfo name='RFC' value='7202'/>
<seriesInfo name='DOI' value='10.17487/RFC7202'/>
</reference>
<reference anchor="RFC8083" target="https://www.rfc-editor.org/info/rfc8083"> There SHALL be no encoding/decoding (transcoding) of the audio stream
<front> as it traverses the network.
<title>Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions<
/title>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<author fullname="V. Singh" initials="V." surname="Singh"/>
<date month="March" year="2017"/>
<abstract>
<t>The Real-time Transport Protocol (RTP) is widely used in telephony, video con
ferencing, and telepresence applications. Such applications are often run on bes
t-effort UDP/IP networks. If congestion control is not implemented in these appl
ications, then network congestion can lead to uncontrolled packet loss and a res
ulting deterioration of the user's multimedia experience. The congestion control
algorithm acts as a safety measure by stopping RTP flows from using excessive r
esources and protecting the network from overload. At the time of this writing,
however, while there are several proprietary solutions, there is no standard alg
orithm for congestion control of interactive RTP flows.</t>
<t>This document does not propose a congestion control algorithm. It instead def
ines a minimal set of RTP circuit breakers: conditions under which an RTP sender
needs to stop transmitting media data to protect the network from excessive con
gestion. It is expected that, in the absence of long-lived excessive congestion,
RTP applications running on best-effort IP networks will be able to operate wit
hout triggering these circuit breakers. To avoid triggering the RTP circuit brea
ker, any Standards Track congestion control algorithms defined for RTP will need
to operate within the envelope set by these RTP circuit breaker algorithms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8083"/>
<seriesInfo name="DOI" value="10.17487/RFC8083"/>
<format target="https://www.rfc-editor.org/info/rfc8083" type="TXT"/>
</reference>
<reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8085"> c. FYI - The terms below have been updated as follows. Please review
<front> and let us know if you have any additional changes.
<title>UDP Usage Guidelines</title>
<author fullname="L. Eggert" initials="L." surname="Eggert"/>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="G. Shepherd" initials="G." surname="Shepherd"/>
<date month="March" year="2017"/>
<abstract>
<t>The User Datagram Protocol (UDP) provides a minimal message-passing transport
that has no inherent congestion control mechanisms. This document provides guid
elines on the use of UDP for the designers of applications, tunnels, and other p
rotocols that use UDP. Congestion control guidelines are a primary focus, but th
e document also provides guidance on other topics, including message sizes, reli
ability, checksums, middlebox traversal, the use of Explicit Congestion Notifica
tion (ECN), Differentiated Services Code Points (DSCPs), and ports.</t>
<t>Because congestion control is critical to the stable operation of the Interne
t, applications and other protocols that choose to use UDP as an Internet transp
ort must employ mechanisms to prevent congestion collapse and to establish some
degree of fairness with concurrent traffic. They may also need to implement addi
tional mechanisms, depending on how they use UDP.</t>
<t>Some guidance is also applicable to the design of other protocols (e.g., prot
ocols layered directly on IP or via IP-based tunnels), especially when these pro
tocols do not themselves provide congestion control.</t>
<t>This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
<format target="https://www.rfc-editor.org/info/rfc8085" type="TXT"/>
</reference>
<reference anchor='RFC8088' target='https://www.rfc-editor.org/info/rfc8088'> Inter-media RTP Synchronization -> inter-media RTP synchronization
<front> to match RFC 8088, which is cited.
<title>How to Write an RTP Payload Format</title>
<author fullname='M. Westerlund' initials='M.' surname='Westerlund'><organizatio
n/></author>
<date month='May' year='2017'/>
<abstract><t>This document contains information on how best to write an RTP payl
oad format specification. It provides reading tips, design practices, and pract
ical tips on how to produce an RTP payload format specification quickly and with
good results. A template is also included with instructions.</t></abstract>
</front>
<seriesInfo name='RFC' value='8088'/>
<seriesInfo name='DOI' value='10.17487/RFC8088'/>
</reference>
<reference anchor='RFC8130' target='https://www.rfc-editor.org/info/rfc8130'> Payload-Specific Feedback Messages -> payload-specific feedback messages
<front> to match RFC 4585, which is cited.
<title>RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (M
ELPe) Codec</title>
<author fullname='V. Demjanenko' initials='V.' surname='Demjanenko'><organizatio
n/></author>
<author fullname='D. Satterlee' initials='D.' surname='Satterlee'><organization/
></author>
<date month='March' year='2017'/>
<abstract><t>This document describes the RTP payload format for the Mixed Excita
tion Linear Prediction Enhanced (MELPe) speech coder. MELPe's three different s
peech encoding rates and sample frame sizes are supported. Comfort noise proced
ures and packet loss concealment are described in detail.</t></abstract>
</front>
<seriesInfo name='RFC' value='8130'/>
<seriesInfo name='DOI' value='10.17487/RFC8130'/>
</reference>
<reference anchor="RFC9143" target="https://www.rfc-editor.org/info/rfc9143"> scip codecs -> SCIP codecs
<front> for consistency with other instances within this document.
<title>Negotiating Media Multiplexing Using the Session Description Protocol (SD -->
P)</title>
<author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
<author fullname="H. Alvestrand" initials="H." surname="Alvestrand"/>
<author fullname="C. Jennings" initials="C." surname="Jennings"/>
<date month="February" year="2022"/>
<abstract>
<t>This specification defines a new Session Description Protocol (SDP) Grouping
Framework extension called 'BUNDLE'. The extension can be used with the SDP offe
r/answer mechanism to negotiate the usage of a single transport (5-tuple) for se
nding and receiving media described by multiple SDP media descriptions ("m=" sec
tions). Such transport is referred to as a "BUNDLE transport", and the media is
referred to as "bundled media". The "m=" sections that use the BUNDLE transport
form a BUNDLE group.</t>
<t>This specification defines a new RTP Control Protocol (RTCP) Source Descripti
on (SDES) item and a new RTP header extension.</t>
<t>This specification updates RFCs 3264, 5888, and 7941.</t>
<t>This specification obsoletes RFC 8843.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9143"/>
<seriesInfo name="DOI" value="10.17487/RFC9143"/>
</reference>
<reference anchor="RFC9170" target="https://www.rfc-editor.org/info/rfc9170"> <!-- [rfced] FYI - We have added expansions for abbreviations upon first use
<front> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
<title>Long-Term Viability of Protocol Extension Mechanisms</title> expansion in the document carefully to ensure correctness.
<author fullname="M. Thomson" initials="M." surname="Thomson"/>
<author fullname="T. Pauly" initials="T." surname="Pauly"/>
<date month="December" year="2021"/>
<abstract>
<t>The ability to change protocols depends on exercising the extension and versi
on-negotiation mechanisms that support change. This document explores how regula
r use of new protocol features can ensure that it remains possible to deploy cha
nges to a protocol. Examples are given where lack of use caused changes to be mo
re difficult or costly.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9170"/>
<seriesInfo name="DOI" value="10.17487/RFC9170"/>
</reference>
<reference anchor="RMCAT" target="https://datatracker.ietf.org/wg/rmcat/about/" MELPe expanded to Mixed Excitation Linear Prediction Enhanced
quoteTitle="true" derivedAnchor="RMCAT"> -->
<front>
<title>RTP Media Congestion Avoidance Techniques (rmcat) Working Group</title>
<author>
<organization showOnFrontPage="true">IETF</organization>
</author>
</front>
</reference>
<reference anchor="SCIP210" target='https://www.iad.gov/SecurePhone/index.cfm'> <!--[rfced] Please review each artwork element in the XML file. Specifically,
<front> should any artwork element in Sections 5.3 and 5.4 be tagged as
<title>SCIP Signaling Plan</title> sourcecode or another element? (We note that RFC 9143 used the
<author> sourcecode element with type="sdp" for what may be similar text.)
<organization>SCIP Working Group</organization>
</author>
<date year="2023" month="September"/>
</front>
<refcontent>SCIP-210, r3.11</refcontent>
</reference>
<reference anchor="VIDEOSCIP" target="https://www.iana.org/assignments/media-typ Relevant documentation:
es/video/scip"> https://authors.ietf.org/rfcxml-vocabulary#artwork
<front> https://authors.ietf.org/rfcxml-vocabulary#sourcecode
<title>video/scip: Internet Assigned Numbers Authority (IANA)</title> -->
<author initials="M." surname="Faller">
<organization></organization>
</author>
<author initials="D." surname="Hanson">
<organization></organization>
</author>
<date year="2021" month="January" day="28"/>
</front>
</reference>
</references> <!--[rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
</back> Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice. -->
</rfc> </rfc>
 End of changes. 140 change blocks. 
1042 lines changed or deleted 694 lines changed or added

This html diff was produced by rfcdiff 1.48.