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"/> <keyword>SCIP</keyword>
<keyword>FNBDT</keyword>
<workgroup>Payload Working Group</workgroup> <keyword>NATO</keyword>
<keyword>Department of Defense</keyword>
<keyword>DoD</keyword>
<keyword>NSA</keyword>
<keyword>STANAG</keyword>
<keyword>ICWG</keyword>
<keyword>IICWG</keyword>
<keyword>SCIPWG</keyword>
<abstract> <abstract>
<t>This document describes the RTP payload format of the Secure
<t>This document describes the RTP payload format of the Secure Communication Interoperability Protocol (SCIP). SCIP is an
Communication Interoperability Protocol (SCIP). SCIP is an application application-layer protocol that provides end-to-end session
layer protocol that provides end-to-end capability exchange, establishment, payload encryption, packetization and de-packetization of
packetization/de-packetization of media, reliable transport, and payload encryp media, and reliable transport. This document provides a globally
tion.</t> available reference that can be used for the development of network
equipment and procurement of services that support SCIP traffic. The
<t>SCIP handles packetization/de-packetization of the encrypted media and acts a intended audience is network security policymakers; network
s a administrators, architects, and original equipment manufacturers (OEMs);
tunneling protocol, treating SCIP payloads as opaque octets to be procurement personnel; and government agency and commercial industry
encapsulated within RTP payloads prior to transmission or decapsulated representatives.</t>
on reception. SCIP payloads are sized to fit within the maximum transmission un
it (MTU)
when transported over RTP thereby avoiding fragmentation.</t>
<t>SCIP transmits encrypted traffic and does not require the use of Secure RTP
(SRTP) for payload protection. SCIP also provides for reliable transport at
the application layer, so it is not necessary to negotiate RTCP retransmission
capabilities.</t>
<t>To establish reliable communications using SCIP over RTP, it is important
that middle boxes avoid parsing or modifying SCIP payloads.
Because SCIP payloads are confidentiality and integrity protected and are only
decipherable by
the originating and receiving SCIP devices, modification of the payload by
middle boxes would be detected as an integrity failure in SCIP devices,
resulting in retransmission and/or communication failure. Middle
boxes do not need to parse the SCIP payloads to correctly transport them.
Not only is parsing unnecessary to tunnel/detunnel SCIP within RTP,
but the parsing and filtering of SCIP payloads by middle boxes would likely lea
d to
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 the SCIP media subtypes to be listed in the Session Description Protocol (SDP)
nd only requires and only requires
a basic RTP transport channel for SCIP payloads. This basic transport channel is a basic RTP transport channel for SCIP payloads. This basic transport channel i
comparable to s comparable to
<xref target="RFC4040"/> Clearmode.</li> Clearmode as defined by <xref target="RFC4040"/>.</li>
<li>SCIP transmits encrypted traffic and does not require the use of Sec
<li>SCIP is designed to be network agnostic. It can operate over any digital lin ure RTP
k, including (SRTP) for payload protection. SCIP also provides for reliable transport at
the application layer, so it is not necessary to negotiate RTCP retransmission
capabilities.</li>
<li>SCIP includes built-in mechanisms that negotiate protocol message ve
rsions and capabilities.
To avoid SCIP protocol ossification (as described in <xref target="RFC9170"/>),
it is important
for middleboxes to not attempt parsing of the SCIP payload. As described in thi
s document,
such parsing serves no useful purpose.</li>
<li>SCIP is designed to be network agnostic. It can operate over any dig
ital link, 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 and de-packetization of payloads by produ
<li>SCIP handles packetization/de-packetization of payloads by producing encrypt cing 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 middlebox es 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>
</ul>
<li>SCIP includes built-in mechanisms that negotiate protocol message versions a </section>
nd capabilities. <section anchor="introduction">
To avoid SCIP protocol ossification (as described in <xref target="RFC9170"/>), <name>Introduction</name>
it is important <!-- section 2 -->
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>
</section>
<section anchor="introduction"><name>Introduction</name>
<!-- section 2 -->
<t>
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
security policymakers; network equipment OEMs, administrators, and architects;
procurement personnel;
and government agency and commercial industry representatives.
</t>
<t>
The document details usage of the "audio/scip" and "video/scip" pseudo-codecs <x
ref target="AUDIOSCIP"/>,
<xref target="VIDEOSCIP"/> as a secure session establishment protocol and media
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 <t>This document details usage of the "audio/scip" and "video/scip"
ure voice, video, and pseudo-codecs <xref target="MediaTypes"/> as a secure session establishmen
t protocol and media
transport protocol over RTP.</t>
<t>It discusses how:</t>
<ol spacing="normal">
<li>encrypted audio and video codec payloads are transported over RTP;</l
i>
<li>the IP network layer does not implement SCIP as a protocol since
SCIP operates at the application layer in endpoints;</li>
<li>the IP network layer enables SCIP traffic to transparently pass
through the network;</li>
<li>some network devices do not recognize SCIP and may remove the SCIP
codecs from the SDP media payload declaration before forwarding
to the next network node; and finally,</li>
<li>SCIP endpoint devices do not operate on networks if the SCIP
media subtype is removed 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 and 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 middleboxes 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 middleboxes, SCIP-210 represents an informative reference. While
media through middle boxes, SCIP-210 represents an informative reference. While older versions
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 therefore has <t>Note: The IETF has not conducted a security review of SCIP and
not verified therefore has not verified the claims contained in this document.</t>
the claims contained in this document.</t> </aside>
</aside>
<section anchor="conventions"><name>Conventions</name>
<!-- section 2.1 -->
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, a
nd only when,
they appear in all capitals, as shown here.</t>
<t>Best current practices for writing an RTP payload format
specification were followed <xref target="RFC2736"/> <xref target="RFC8088"/>
.</t>
<t>When referring to the Secure Communication Interoperability <section anchor="conventions">
<name>Conventions</name>
<!-- section 2.1 -->
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<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-Visual 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-Visual Profile with Feedback</dd>
<dt>IICWG:</dt> <dd>International Interoperability Control Working Group</dd> <dt>FNBDT:</dt>
<dt>NATO:</dt> <dd>North Atlantic Treaty Organization</dd> <dd>Future Narrowband Digital Terminal</dd>
<dt>OEM:</dt> <dd>Original Equipment Manufacturer</dd> <dt>ICWG:</dt>
<dt>SAVP:</dt> <dd>Secure Audio/Video Profile</dd> <dd>Interoperability Control Working Group</dd>
<dt>SAVPF:</dt> <dd>Secure Audio/Video Profile Feedback</dd> <dt>IICWG:</dt>
<dt>SCIP:</dt> <dd>Secure Communication Interoperability Protocol</dd> <dd>International Interoperability Control Working Group</dd>
<dt>SDP:</dt> <dd>Session Description Protocol</dd> <dt>MELPe:</dt>
<dt>SRTP:</dt> <dd>Secure Real-Time Transport Protocol</dd> <dd>Mixed Excitation Linear Prediction Enhanced</dd>
<dt>STANAG:</dt> <dd>Standardization Agreement</dd> <dt>MTU:</dt>
</dl> <dd>Maximum Transmission Unit</dd>
<dt>NATO:</dt>
</section> <dd>North Atlantic Treaty Organization</dd>
</section> <dt>OEM:</dt>
<dd>Original Equipment Manufacturer</dd>
<section anchor="background"><name>Background</name> <dt>SAVP:</dt>
<!-- section 3 --> <dd>Secure Audio-Visual Profile</dd>
<dt>SAVPF:</dt>
<dd>Secure Audio-Visual Profile with Feedback</dd>
<dt>SCIP:</dt>
<dd>Secure Communication Interoperability Protocol</dd>
<dt>SDP:</dt>
<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 and 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 and video codecs that it use s
(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 RTPs with SCIP</name>
<!-- section 4.3 -->
</section> <t>The SCIP application-layer protocol uses RTP as a basic transport for the "au
dio/scip" and
<section anchor="augmented-protocols"><name>Use of Augmented RTP Transport Proto "video/scip" payloads. Additional RTPs that do not modify the SCIP payload
cols with SCIP</name> are considered <bcp14>OPTIONAL</bcp14> in this document and are discretionary f
<!-- section 4.3 --> or a SCIP device vendor to implement.
Some examples include, but are not limited to:</t>
<t>The SCIP application layer protocol uses RTP as a basic transport for the aud <ul>
io/scip and <li>"RTP Payload Format for Generic Forward Error Correction" <xref ta
video/scip payloads. Additional RTP transport protocols that do not modify the rget="RFC5109"/></li>
SCIP payload <li>"Multiplexing RTP Data and Control Packets on a Single Port" <xref
are considered OPTIONAL in this document and are discretionary for a SCIP devic target="RFC5761"/></li>
e vendor to implement. <li>"Symmetric RTP / RTP Control Protocol (RTCP)" <xref target="RFC496
Some examples include but are not limited to:</t> 1"/></li>
<li>"Negotiating Media Multiplexing Using the Session Description Prot
<ul> ocol (SDP)" a.k.a.&nbsp;BUNDLE <xref target="RFC9143"/></li>
<li>RTP Payload Format for Generic Forward Error Correction <xref target="RFC510 </ul>
9"/></li> </section>
<li>Multiplexing RTP Data and Control Packets on a Single Port <xref target="RFC </section>
5761"/></li> <section anchor="payload-format-parameters">
<li>Symmetric RTP/RTP Control Protocol (RTCP) <xref target="RFC4961"/></li> <name>Payload Format Parameters</name>
<li>Negotiating Media Multiplexing Using the Session Description Protocol (BUNDL <!-- section 5 -->
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 <t>The SCIP RTP payload format is identified using the scip media
subtype, which is registered in accordance with <xref target="RFC4855"/> and subtype, which is registered in accordance with <xref target="RFC4855"/> and
per the media type registration template form <xref target="RFC6838"/>. A per the media type registration template from <xref target="RFC6838"/>. A
clock rate of 8000 Hz SHALL be used for "audio/scip". A clock clock rate of 8000 Hz <bcp14>SHALL</bcp14> be used for "audio/scip". A clock
rate of 90000 Hz SHALL be used for "video/scip".</t> rate of 90000 Hz <bcp14>SHALL</bcp14> be used for "video/scip".</t>
<section anchor="media-subtype-audioscip">
<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>
<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> <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
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 or MichaelF
Faller@gmail.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 or MichaelF
Faller@gmail.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
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 or MichaelFFaller@gmail.com) and Daniel H
anson
(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 or MichaelFF
aller@gmail.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 "a
<li>The media type ("audio") goes in SDP "m=" as the media name for audio/scip, udio/scip",
and the media type ("video") goes in SDP "m=" as the media name for video/scip.< and the media type ("video") goes in SDP "m=" as the media name for "video/scip"
/li> .</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> <sourcecode type="sdp">
m=audio 50000 RTP/AVP 96
<figure> a=rtpmap:96 scip/8000
<artwork> </sourcecode>
<![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> <t>An example mapping for "video/scip" is:</t>
<sourcecode type="sdp">
m=video 50002 RTP/AVP 97
a=rtpmap:97 scip/90000
</sourcecode>
<figure> <t>An example mapping for both "audio/scip" and "video/scip" is:</t>
<artwork> <sourcecode type="sdp">
<![CDATA[ m=audio 50000 RTP/AVP 96 m=audio 50000 RTP/AVP 96
a=rtpmap:96 scip/8000 a=rtpmap:96 scip/8000
m=video 50002 RTP/AVP 97 m=video 50002 RTP/AVP 97
a=rtpmap:97 scip/90000]]> a=rtpmap:97 scip/90000
</artwork> </sourcecode>
</figure>
</section>
<section anchor="sdp-offeranswer-considerations"><name>SDP Offer/Answer Consider </section>
ations</name> <section anchor="sdp-offeranswer-considerations">
<!-- section 5.4 --> <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>
<sourcecode type="sdp">
<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> </sourcecode>
</figure>
</section>
</section>
<section anchor="security-considerations"><name>Security Considerations</name> </section>
<!-- section 6 --> </section>
<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> <section anchor="iana-considerations">
<name>IANA Considerations</name>
<section anchor="iana-considerations"><name>IANA Considerations</name> <!-- section 7 -->
<!-- section 7 -->
<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> <t>The "audio/scip" and "video/scip" media subtypes have previously been
registered in the "Media Types" registry <xref target="MediaTypes"/>. IANA has
updated
these registrations to reference this document.</t>
</section>
<section anchor="scip-contact-info"><name>SCIP Contact Information</name> <section anchor="scip-contact-info">
<!-- section 8 --> <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 <xref target="SCIP210"/> may be requested from the email address b elow.
</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>
from <eref target="https://www.iad.gov/SecurePhone/index.cfm"/>. </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"/>. A U.S. Departm
ent of Defense Root Certificate should be
installed to access this website.
</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="MediaTypes" target="https://www.iana.org/assignments/
media-types">
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'> <front>
<front> <title>Media Types</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'>
<front>
<title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
<author fullname='J. Rosenberg' initials='J.' surname='Rosenberg'><organization/
></author>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organizat
ion/></author>
<date month='June' year='2002'/>
<abstract><t>This document defines a mechanism by which two entities can make us
e of the Session Description Protocol (SDP) to arrive at a common view of a mult
imedia session between them. In the model, one participant offers the other a d
escription of the desired session from their perspective, and the other particip
ant answers with the desired session from their perspective. This offer/answer
model is most useful in unicast sessions where information from both participant
s is needed for the complete view of the session. The offer/answer model is use
d by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]</t
></abstract>
</front>
<seriesInfo name='RFC' value='3264'/>
<seriesInfo name='DOI' value='10.17487/RFC3264'/>
</reference>
<reference anchor='RFC3550' target='https://www.rfc-editor.org/info/rfc3550'>
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organizat
ion/></author>
<author fullname='S. Casner' initials='S.' surname='Casner'><organization/></aut
hor>
<author fullname='R. Frederick' initials='R.' surname='Frederick'><organization/
></author>
<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'>
<front>
<title>RTP Profile for Audio and Video Conferences with Minimal Control</title>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organizat
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'>
<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'>
<front>
<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'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<front> 040.xml"/>
<title>Extended Secure RTP Profile for Real-time Transport Control Protocol (RTC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
P)-Based Feedback (RTP/SAVPF)</title> 855.xml"/>
<author fullname='J. Ott' initials='J.' surname='Ott'><organization/></author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname='E. Carrara' initials='E.' surname='Carrara'><organization/></a 961.xml"/>
uthor> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<date month='February' year='2008'/> 109.xml"/>
<abstract><t>An RTP profile (SAVP) for secure real-time communications and anoth <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
er profile (AVPF) to provide timely feedback from the receivers to a sender are 761.xml"/>
defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combina <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
tion of both profiles to enable secure RTP communications with feedback. [STAND 184.xml"/>
ARDS-TRACK]</t></abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</front> 838.xml"/>
<seriesInfo name='RFC' value='5124'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<seriesInfo name='DOI' value='10.17487/RFC5124'/> 201.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
202.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
083.xml"/>
<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='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'> <reference anchor="RMCAT" target="https://datatracker.ietf.org/wg/rmcat/
<front> about">
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <front>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho <title>RTP Media Congestion Avoidance Techniques (rmcat)</title>
r> <author>
<date month='May' year='2017'/> <organization>IETF</organization>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s </author>
pecifications. This document aims to reduce the ambiguity by clarifying that on </front>
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs </reference>
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">
<front> <front>
<title>SDP: Session Description Protocol</title> <title>SCIP Signaling Plan, SCIP-210</title>
<author fullname='A. Begen' initials='A.' surname='Begen'><organization/></autho <author>
r> <organization>SCIP Working Group</organization>
<author fullname='P. Kyzivat' initials='P.' surname='Kyzivat'><organization/></a </author>
uthor> </front>
<author fullname='C. Perkins' initials='C.' surname='Perkins'><organization/></a <annotation>Available by request via email to &lt;ncia.cis3@ncia.nato.i
uthor> nt&gt;.</annotation>
<author fullname='M. Handley' initials='M.' surname='Handley'><organization/></a </reference>
uthor>
<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>
</references> </references>
<references title='Informative References'>
<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">
<front>
<title>RTP Payload Format for Generic Forward Error Correction</title>
<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">
<front>
<title>Multiplexing RTP Data and Control Packets on a Single Port</title>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/>
<date month="April" year="2010"/>
<abstract>
<t>This memo discusses issues that arise when multiplexing RTP data packets and
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'>
<front>
<title>RTP Payload Format for H.264 Video</title>
<author fullname='Y.-K. Wang' initials='Y.-K.' surname='Wang'><organization/></a
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'>
<front>
<title>Media Type Specifications and Registration Procedures</title>
<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'>
<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'>
<front>
<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">
<front>
<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">
<front>
<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'>
<front>
<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'>
<front>
<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">
<front>
<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">
<front>
<title>Long-Term Viability of Protocol Extension Mechanisms</title>
<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/"
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'>
<front>
<title>SCIP Signaling Plan</title>
<author>
<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
es/video/scip">
<front>
<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> </references>
</back> </back>
</rfc> </rfc>
 End of changes. 92 change blocks. 
1126 lines changed or deleted 529 lines changed or added

This html diff was produced by rfcdiff 1.48.