<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC2736 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2736.xml">
<!ENTITY RFC8088 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8088.xml">
<!ENTITY RFC3264 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY RFC3550 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC3551 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY RFC8130 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8130.xml">
<!ENTITY RFC3711 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY RFC4566 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY RFC4855 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4855.xml">
<!ENTITY RFC5124 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5124.xml">
<!ENTITY RFC6562 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6562.xml">
<!ENTITY RFC6838 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml">
<!ENTITY RFC8083 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8083.xml">
<!ENTITY RFC8085 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml">
<!ENTITY RFC4585 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml">
<!ENTITY RFC7201 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7201.xml">
<!ENTITY RFC7202 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7202.xml">
]> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     docName="draft-ietf-payload-tsvcis-05" category="std" ipr="trust200902"> ipr="trust200902"
     obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true"
     tocInclude="true" version="3" number="8817" consensus="yes">

  <!-- xml2rfc v2v3 conversion 2.46.0 -->
  <!-- Generated by id2xml 1.5.0 on 2020-07-02T22:03:45Z -->
	<?rfc strict="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="no"?>
	<?rfc text-list-symbols="o*+-"?>
	<?rfc toc="yes"?>
	<front>
	<title>RTP

    <title abbrev="RTP Payload Format for TSVCIS Codec">RTP Payload Format for
    Tactical Secure Voice Cryptographic Interoperability Specification
    (TSVCIS) Codec</title>
    <seriesInfo name="RFC" value="8817"/>
    <author initials="V." surname="Demjanenko" fullname="Victor Demjanenko, Ph.D.">
      <organization>VOCAL Technologies, Ltd.</organization>
      <address>
        <postal>
          <street>520 Lee Entrance</street>
	    <street>Suite Entrance, Suite 202</street>
	    <city>Buffalo</city><region>NY</region><code>14228</code>
          <city>Buffalo</city>
          <region>NY</region>
          <code>14228</code>
          <country>United States of America</country>
        </postal>
        <phone>+1 716 688 4675</phone>
        <email>victor.demjanenko@vocal.com</email>
      </address>
    </author>
    <author initials="J." surname="Punaro" fullname="John Punaro">
      <organization>VOCAL Technologies, Ltd.</organization>
      <address>
        <postal>
          <street>520 Lee Entrance</street>
	    <street>Suite Entrance, Suite 202</street>
	    <city>Buffalo</city><region>NY</region><code>14228</code>
          <city>Buffalo</city>
          <region>NY</region>
          <code>14228</code>
          <country>United States of America</country>
        </postal>
        <phone>+1 716 688 4675</phone>
        <email>john.punaro@vocal.com</email>
      </address>
    </author>
    <author initials="D." surname="Satterlee" fullname="David Satterlee">
      <organization>VOCAL Technologies, Ltd.</organization>
      <address>
        <postal>
          <street>520 Lee Entrance</street>
	    <street>Suite Entrance, Suite 202</street>
	    <city>Buffalo</city><region>NY</region><code>14228</code>
          <city>Buffalo</city>
          <region>NY</region>
          <code>14228</code>
          <country>United States of America</country>
        </postal>
        <phone>+1 716 688 4675</phone>
        <email>david.satterlee@vocal.com</email>
      </address>
    </author>
    <date year="2020" month="July"/> month="August"/>
    <workgroup>Payload Working Group</workgroup>
	<abstract><t>

<keyword>MELP</keyword>
<keyword>MELPe</keyword>
<keyword>TSVCIS</keyword>
<keyword>NRLVDR</keyword>
<keyword>Naval Research Laboratory</keyword>
<keyword>NRL</keyword>
<keyword>NATO</keyword>
<keyword>TSVWG</keyword>
<keyword>Department of Defense</keyword>
<keyword>DoD</keyword>
<keyword>NSA</keyword>
<keyword>MIL-STD</keyword>

    <abstract>
      <t>
   This document describes the RTP payload format for the Tactical
   Secure Voice Cryptographic Interoperability Specification (TSVCIS)
   speech coder.  TSVCIS is a scalable narrowband voice coder supporting
   varying encoder data rates and fallbacks.  It is implemented as an
   augmentation to the Mixed Excitation Linear Prediction Enhanced
   (MELPe) speech coder by conveying additional speech coder parameters
   for enhancing
   to enhance voice quality.  TSVCIS augmented speech data is
   processed in conjunction with its temporal temporally matched MELP Mixed Excitation Linear
   Prediction (MELP) 2400 speech data.  The RTP packetization of TSVCIS and
      MELPe speech coder data is described in detail.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sect-1"><t> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   This document describes how compressed Tactical Secure Voice
   Cryptographic Interoperability Specification (TSVCIS) speech as
   produced by the TSVCIS codec <xref target="TSVCIS"/> target="TSVCIS" format="default"/> <xref target="NRLVDR"/> target="NRLVDR" format="default"/> may be formatted for
   use as an RTP payload.  The TSVCIS speech coder (or TSVCIS speech
   aware speech-aware communications equipment on any intervening transport link) may
   adjust to restricted bandwidth conditions by reducing the amount of
   augmented speech data and relying on the underlying MELPe speech
   coder for the most constrained bandwidth links.</t>
      <t>
   Details are provided for packetizing the TSVCIS augmented speech data
   along with MELPe 2400 bps speech parameters in a an RTP packet. The
   sender may send one or more codec data frames per packet, depending
   on the application scenario or based on transport network conditions,
   bandwidth restrictions, delay requirements, and packet loss
   tolerance.</t>
      <section title="Conventions" anchor="sect-1.1"><t> anchor="sect-1.1" numbered="true" toc="default">
        <name>Conventions</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
   "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
   BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
        <t>
   Best current practices for writing an RTP payload format
   specification were followed <xref target="RFC2736"/> target="RFC2736" format="default"/> <xref target="RFC8088"/>.</t> target="RFC8088" format="default"/>.</t>
      </section>

    <section anchor="sect-1.2" numbered="true" toc="default">
      <name>Abbreviations</name>
      <t>The following abbreviations are used in this document.</t>
<dl newline="false" indent="10" spacing="normal">
<dt>AVP:</dt><dd>Audio/Video Profile</dd>
<dt>AVPF:</dt><dd>Audio/Video Profile Feedback</dd>
<dt>CELP:</dt><dd>Code-Excited Linear Prediction</dd>
<dt>FEC:</dt><dd>Forward Error Correction</dd>
<dt>LPC:</dt><dd>Linear-Predictive Coding</dd>
<dt>LSB:</dt><dd>Least Significant Bit</dd>
<dt>MELP:</dt><dd>Mixed Excitation Linear Prediction</dd>
<dt>MELPe:</dt><dd>Mixed Excitation Linear Prediction Enhanced</dd>
<dt>MSB:</dt><dd>Most Significant Bit</dd>
<dt>MTC:</dt><dd>Modified Count</dd>
<dt>NATO:</dt><dd>North American Treaty Organization</dd>
<dt>NRL:</dt><dd>Naval Research Lab</dd>
<dt>PLC:</dt><dd>Packet Loss Concealment</dd>
<dt>SAVP:</dt><dd>Secure Audio/Video Profile</dd>
<dt>SAVPF:</dt><dd>Secure Audio/Video Profile Feedback</dd>
<dt>SDP:</dt><dd>Session Description Protocol</dd>
<dt>SSRC:</dt><dd>Synchronization Source</dd>
<dt>SRTP:</dt><dd>Secure Real-Time Transport Protocol</dd>
<dt>TSVCIS:</dt><dd>Tactical Secure Voice Cryptographic Interoperability Specification</dd>
<dt>VAD:</dt><dd>Voice Activity Detect</dd>
<dt>VDR:</dt><dd>Variable Date Rate</dd>
</dl>

    </section>
    </section>
    <section title="Background" anchor="sect-2"><t> anchor="sect-2" numbered="true" toc="default">
      <name>Background</name>
      <t>
   The MELP speech coder was developed by the US military as an upgrade
   from the LPC-based CELP standard vocoder for low-bitrate
   communications <xref target="MELP"/>. target="MELP" format="default"/>.  ("LPC" stands for "Linear-Predictive Coding",
   and "CELP" stands for "Code-Excited Linear Prediction".) MELP was
   further enhanced and subsequently adopted by NATO as MELPe "MELPe" for use by
   its members and Partnership for Peace countries for military and
   other governmental communications as international NATO Standard
   STANAG 4591 <xref target="MELPE"/>.</t> target="MELPE" format="default"/>.</t>
      <t>
   The Tactical Secure Voice Cryptographic Interoperability
   Specification (TSVCIS) is a specification written by the Tactical
   Secure Voice Working Group (TSVWG) for enabling to enable all modern tactical
   secure voice devices to be interoperable across the US Department of
   Defense <xref target="TSVCIS"/>. target="TSVCIS" format="default"/>.  One of the most important aspects is that the
   voice modes defined in TSVCIS are based on specific fixed rates of the Naval Research Lab's (NRL's) Variable Date Rate (VDR) Vocoder Vocoder, which
   uses the MELPe standard as its base <xref target="NRLVDR"/>. target="NRLVDR" format="default"/>.  A complete TSVCIS
   speech frame consists of MELPe speech parameters and corresponding
   TSVCIS augmented speech data.</t>
      <t>
   In addition to the augmented speech data, the TSVCIS specification
   identifies which speech coder and framing bits are to be encrypted, encrypted
   and how they are protected by forward error correction (FEC)
   techniques (using block codes).  At the RTP transport layer, only the
   speech-coder-related
   speech coder-related bits need to be considered and are conveyed in
   unencrypted form.  In most IP-based network deployments, standard
   link encryption methods (SRTP, (Secure Real-Time Transport Protocol (SRTP), VPNs, FIPS 140 link encryptors encryptors, or Type
   1 Ethernet encryptors) would be used to secure the RTP speech
   contents.</t>

      <t>
   TSVCIS augmented speech data is derived from the signal processing
   and data already performed generated by the MELPe speech coder.  For the
   purposes of this specification, only the general parameter nature of
   TSVCIS will be characterized.  Depending on the bandwidth available
   (and FEC requirements), a varying number of TSVCIS-specific speech
   coder parameters need to be transported.  These are first byte-packed
   and then conveyed from encoder to decoder.</t>
      <t>
   Byte packing of TSVCIS speech data into packed parameters is
   processed as per the following example:</t>

<figure><artwork><![CDATA[
      Three-bit field: bits example, where</t>
<dl><dt>Three-bit field:</dt><dd>Bits A, B, and C (A is MSB, MSB; C is LSB)
      Five-bit field: bits LSB)</dd>
     <dt>Five-bit field:</dt><dd>Bits D, E, F, G, and H (D is MSB, MSB; H is LSB) LSB)</dd>
</dl>
      <artwork name="" type="" align="left" alt=""><![CDATA[
        MSB                                              LSB
         0      1      2      3      4      5      6      7
     +------+------+------+------+------+------+------+------+
     |   H  |   G  |   F  |   E  |   D  |   C  |   B  |   A  |
     +------+------+------+------+------+------+------+------+
]]></artwork>
	</figure>
      <t>
   This packing method places the three-bit field "first" in the lowest
   bits followed by the next five-bit field.  Parameters may be split
   between octets with the most significant bits in the earlier octet.
   Any unfilled bits in the last octet MUST <bcp14>MUST</bcp14> be filled with
      zero.</t>

      <t>
   In order to accommodate a varying amount of TSVCIS augmented speech
   data, an octet count specifies the number of octets representing
   the packed TSVCIS packed parameters.  The encoding to do so is presented in
   <xref target="sect-3.2"/>. target="sect-3.2" format="default"/>.  TSVCIS specifically uses the NRL VDR in two
   configurations using with a fixed set of 15 and 35 packed octet
   parameters in a standardized order <xref target="TSVCIS"/>.</t> target="TSVCIS" format="default"/>.</t>
    </section>
    <section title="Payload Format" anchor="sect-3"><t> anchor="sect-3" numbered="true" toc="default">
      <name>Payload Format</name>
      <t>
   The TSVCIS codec augments the standard MELP 2400, 1200 1200, and 600
   bitrates and hence uses 22.5, 67.5, or 90 ms frames with a sampling
   rate clock of 8 kHz, so the RTP timestamp MUST <bcp14>MUST</bcp14> be in units of 1/8000
   of a second.</t>
      <t>
   The RTP payload for TSVCIS has the format shown in Figure 1. <xref target="fig-1"/>.  No
   additional header specific to this payload format is needed.  This
   format is intended for situations where the sender and the receiver
   send one or more codec data frames per packet.</t>
      <figure title="Packet anchor="fig-1">
        <name>Packet Format Diagram" anchor="fig-1"><artwork><![CDATA[ Diagram</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         RTP Header                            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                                                               |
+                 one or more frames of TSVCIS                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>
   The RTP header of the packetized encoded TSVCIS speech has the
   expected values as described in <xref target="RFC3550"/>. target="RFC3550" format="default"/>.  The usage of the M bit
   SHOULD
   <bcp14>SHOULD</bcp14> be as specified in the applicable RTP profile -- for example,
   <xref target="RFC3551"/>, where <xref target="RFC3551"/> target="RFC3551" format="default"/> specifies that if the sender does not
   suppress silence (i.e., sends a frame on every frame interval), the
   M bit will always be zero.  When more than one codec data frame is
   present in a single RTP packet, the timestamp specified is that of
   the oldest data frame represented in the RTP packet.</t>
      <t>
   The assignment of an RTP payload type for this new packet format is
   outside the scope of this document and will not be specified here. It
   is expected that the RTP profile for a particular class of
   applications will assign a payload type for this encoding, or encoding; if that
   is not done, then a payload type in the dynamic range shall be chosen
   by the sender.</t>
      <section title="MELPe anchor="sect-3.1" numbered="true" toc="default">
        <name>MELPe Bitstream Definitions" anchor="sect-3.1"><t> Definitions</name>
        <t>
   The TCVCIS TSVCIS speech coder includes all three MELPe coder rates used as
   base speech parameters or as speech coders for bandwidth restricted bandwidth-restricted
   links.  RTP packetization of MELPe follows RFC 8130 <xref target="RFC8130"/> and is repeated
   here for all three MELPe rates <xref target="RFC8130"/> target="RFC8130" format="default"/>, with its recommendations now
   regarded as requirements.  The bits previously labeled as RSVA, RSVB,
   and RSVC in RFC 8130 SHOULD <xref target="RFC8130"/> <bcp14>SHOULD</bcp14> be filled with
   rate coding, code bits CODA, CODB,
   and CODC, as shown in Table 1 <xref target="tab-1"/> (compatible with Table 7 in Section 3.3
   of <xref target="RFC8130"/>).</t>

	<texttable title="TSVCIS/MELPe target="RFC8130" sectionFormat="of" section="3.3"/>).</t>
        <table anchor="tab-1" align="center">
          <name>TSVCIS/MELPe Frame Bitrate Indicators and Frame Length" anchor="tab-1" style="all"><ttcol> Coder Bitrate</ttcol>
	<ttcol> CODA</ttcol>
	<ttcol> CODB</ttcol>
	<ttcol> CODC</ttcol>
	<ttcol> Length</ttcol>
	<c>2400 bps</c>
	<c>0</c>
	<c>0</c>
	<c>N/A</c>
	<c>7</c>
	<c>1200 bps</c>
	<c>1</c>
	<c>0</c>
	<c>0</c>
	<c>11</c>
	<c>600 bps</c>
	<c>0</c>
	<c>1</c>
	<c>N/A</c>
	<c>7</c>
	<c>Comfort Noise</c>
	<c>1</c>
	<c>0</c>
	<c>1</c>
	<c>2</c>
	<c>TSVCIS data</c>
	<c>1</c>
	<c>1</c>
	<c>N/A</c>
	<c>var.</c>
	</texttable> Length</name>
          <thead>
            <tr>
              <th align="left">Coder Bitrate</th>
              <th align="left">CODA</th>
              <th align="left">CODB</th>
              <th align="left">CODC</th>
              <th align="left">Length</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">2400 bps</td>
              <td align="left">0</td>
              <td align="left">0</td>
              <td align="left">N/A</td>
              <td align="left">7</td>
            </tr>
            <tr>
              <td align="left">1200 bps</td>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">0</td>
              <td align="left">11</td>
            </tr>
            <tr>
              <td align="left">600 bps</td>
              <td align="left">0</td>
              <td align="left">1</td>
              <td align="left">N/A</td>
              <td align="left">7</td>
            </tr>
            <tr>
              <td align="left">Comfort Noise</td>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">1</td>
              <td align="left">2</td>
            </tr>
            <tr>
              <td align="left">TSVCIS Data</td>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">N/A</td>
              <td align="left">var.</td>
            </tr>
          </tbody>
        </table>
        <t>
   The total number of bits used to describe one MELPe frame of 2400 bps
   speech is 54, which fits in 7 octets (with two rate code bits). For
   MELPe 1200 bps speech, the total number of bits used is 81, which
   fits in 11 octets (with three rate code bits and four unused bits).
   For MELPe 600 bps speech, the total number of bits used is 54, which
   fits in 7 octets (with two rate code bits).  The comfort noise frame
   consists of 13 bits, which fits in 2 octets (with three rate code
   bits).  TSVCIS packed parameters will use the last code combination
   in a trailing byte as discussed in <xref target="sect-3.2"/>.</t> target="sect-3.2" format="default"/>.</t>
        <t>
   It should be noted that CODB for MELPe 600 bps mode MAY <bcp14>MAY</bcp14> deviate from
   the value in Table 1 <xref target="tab-1"/> when bit 55 is used as an alternating 1/0
   end-to-end framing bit. Frame decoding would remain distinct as CODA
   being zero on its own would indicate a 7-byte frame for either a 2400
   or 600 bps rate rate, and the use of 600 bps speech coding could be deduced
   from the RTP timestamp (and anticipated by the SDP Session Description Protocol
	(SDP) negotiations).</t>
        <section title="2400 anchor="sect-3.1.1" numbered="true" toc="default">
          <name>2400 bps Bitstream Structure" anchor="sect-3.1.1"><t> Structure</name>
          <t>
   The 2400 bps MELPe RTP payload is constructed as per Figure 2. <xref target="fig-2"/>.  Note
   that CODA MUST <bcp14>MUST</bcp14> be filled with 0 and CODB SHOULD <bcp14>SHOULD</bcp14> be filled with 0 as
   per <xref target="sect-3.1"/>. target="sect-3.1" format="default"/>.  CODB MAY <bcp14>MAY</bcp14> contain an end-to-end framing bit if
   required by the endpoints.</t>
          <figure title="Packed anchor="fig-2">
            <name>Packed MELPe 2400 bps Payload Octets" anchor="fig-2"><artwork><![CDATA[ Octets</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
        MSB                                              LSB
         0      1      2      3      4      5      6      7
     +------+------+------+------+------+------+------+------+
     | B_08 | B_07 | B_06 | B_05 | B_04 | B_03 | B_02 | B_01 |
     +------+------+------+------+------+------+------+------+
     | B_16 | B_15 | B_14 | B_13 | B_12 | B_11 | B_10 | B_09 |
     +------+------+------+------+------+------+------+------+
     | B_24 | B_23 | B_22 | B_21 | B_20 | B_19 | B_18 | B_17 |
     +------+------+------+------+------+------+------+------+
     | B_32 | B_31 | B_30 | B_29 | B_28 | B_27 | B_26 | B_25 |
     +------+------+------+------+------+------+------+------+
     | B_40 | B_39 | B_38 | B_37 | B_36 | B_35 | B_34 | B_33 |
     +------+------+------+------+------+------+------+------+
     | B_48 | B_47 | B_46 | B_45 | B_44 | B_43 | B_42 | B_41 |
     +------+------+------+------+------+------+------+------+
     | CODA | CODB | B_54 | B_53 | B_52 | B_51 | B_50 | B_49 |
     +------+------+------+------+------+------+------+------+
]]></artwork>
          </figure>
        </section>
        <section title="1200 anchor="sect-3.1.2" numbered="true" toc="default">
          <name>1200 bps Bitstream Structure" anchor="sect-3.1.2"><t> Structure</name>
          <t>
   The 1200 bps MELPe RTP payload is constructed as per Figure 3. <xref target="fig-3"/>.  Note
   that CODA, CODB, and CODC MUST <bcp14>MUST</bcp14> be filled with 1, 0, and 0
   respectively 0,
   respectively, as per <xref target="sect-3.1"/>. target="sect-3.1" format="default"/>.  RSV0 MUST <bcp14>MUST</bcp14> be coded as 0.</t>
          <figure title="Packed anchor="fig-3">
            <name>Packed MELPe 1200 bps Payload Octets" anchor="fig-3"><artwork><![CDATA[ Octets</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
        MSB                                              LSB
         0      1      2      3      4      5      6      7
     +------+------+------+------+------+------+------+------+
     | B_08 | B_07 | B_06 | B_05 | B_04 | B_03 | B_02 | B_01 |
     +------+------+------+------+------+------+------+------+
     | B_16 | B_15 | B_14 | B_13 | B_12 | B_11 | B_10 | B_09 |
     +------+------+------+------+------+------+------+------+
     | B_24 | B_23 | B_22 | B_21 | B_20 | B_19 | B_18 | B_17 |
     +------+------+------+------+------+------+------+------+
     | B_32 | B_31 | B_30 | B_29 | B_28 | B_27 | B_26 | B_25 |
     +------+------+------+------+------+------+------+------+
     | B_40 | B_39 | B_38 | B_37 | B_36 | B_35 | B_34 | B_33 |
     +------+------+------+------+------+------+------+------+
     | B_48 | B_47 | B_46 | B_45 | B_44 | B_43 | B_42 | B_41 |
     +------+------+------+------+------+------+------+------+
     | B_56 | B_55 | B_54 | B_53 | B_52 | B_51 | B_50 | B_49 |
     +------+------+------+------+------+------+------+------+
     | B_64 | B_63 | B_62 | B_61 | B_60 | B_59 | B_58 | B_57 |
     +------+------+------+------+------+------+------+------+
     | B_72 | B_71 | B_70 | B_69 | B_68 | B_67 | B_66 | B_65 |
     +------+------+------+------+------+------+------+------+
     | B_80 | B_79 | B_78 | B_77 | B_76 | B_75 | B_74 | B_73 |
     +------+------+------+------+------+------+------+------+
     | CODA | CODB | CODC | RSV0 | RSV0 | RSV0 | RSV0 | B_81 |
     +------+------+------+------+------+------+------+------+
]]></artwork>
          </figure>
        </section>
        <section title="600 anchor="sect-3.1.3" numbered="true" toc="default">
          <name>600 bps Bitstream Structure" anchor="sect-3.1.3"><t> Structure</name>
          <t>
   The 600 bps MELPe RTP payload is constructed as per Figure 4. <xref target="fig-4"/>.  Note
   CODA MUST <bcp14>MUST</bcp14> be filled with 0 and CODB SHOULD <bcp14>SHOULD</bcp14> be filled with 1 as per
   <xref target="sect-3.1"/>. target="sect-3.1" format="default"/>.  CODB MAY <bcp14>MAY</bcp14> contain an end-to-end framing bit if required
   by the endpoints.</t>
          <figure title="Packed anchor="fig-4">
            <name>Packed MELPe 600 bps Payload Octets" anchor="fig-4"><artwork><![CDATA[ Octets</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
        MSB                                              LSB
         0      1      2      3      4      5      6      7
     +------+------+------+------+------+------+------+------+
     | B_08 | B_07 | B_06 | B_05 | B_04 | B_03 | B_02 | B_01 |
     +------+------+------+------+------+------+------+------+
     | B_16 | B_15 | B_14 | B_13 | B_12 | B_11 | B_10 | B_09 |
     +------+------+------+------+------+------+------+------+
     | B_24 | B_23 | B_22 | B_21 | B_20 | B_19 | B_18 | B_17 |
     +------+------+------+------+------+------+------+------+
     | B_32 | B_31 | B_30 | B_29 | B_28 | B_27 | B_26 | B_25 |
     +------+------+------+------+------+------+------+------+
     | B_40 | B_39 | B_38 | B_37 | B_36 | B_35 | B_34 | B_33 |
     +------+------+------+------+------+------+------+------+
     | B_48 | B_47 | B_46 | B_45 | B_44 | B_43 | B_42 | B_41 |
     +------+------+------+------+------+------+------+------+
     | CODA | CODB | B_54 | B_53 | B_52 | B_51 | B_50 | B_49 |
     +------+------+------+------+------+------+------+------+
]]></artwork>
          </figure>
        </section>
        <section title="Comfort anchor="sect-3.1.4" numbered="true" toc="default">
          <name>Comfort Noise Bitstream Definition" anchor="sect-3.1.4"><t> Definition</name>
          <t>
   The comfort noise MELPe RTP payload is constructed as per Figure 5. <xref target="fig-5"/>.
   Note that CODA, CODB, and CODC MUST <bcp14>MUST</bcp14> be filled with 1, 0, and 1
   respectively 1,
   respectively, as per <xref target="sect-3.1"/>.</t> target="sect-3.1" format="default"/>.</t>
          <figure title="Packed anchor="fig-5">
            <name>Packed MELPe Comfort Noise Payload Octets" anchor="fig-5"><artwork><![CDATA[ Octets</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
        MSB                                              LSB
         0      1      2      3      4      5      6      7
     +------+------+------+------+------+------+------+------+
     | B_08 | B_07 | B_06 | B_05 | B_04 | B_03 | B_02 | B_01 |
     +------+------+------+------+------+------+------+------+
     | CODA | CODB | CODC | B_13 | B_12 | B_11 | B_10 | B_09 |
     +------+------+------+------+------+------+------+------+
]]></artwork>
          </figure>
        </section>
      </section>
      <section title="TSVCIS anchor="sect-3.2" numbered="true" toc="default">
        <name>TSVCIS Bitstream Definition" anchor="sect-3.2"><t> Definition</name>
        <t>
   The TSVCIS augmented speech data as packed parameters MUST <bcp14>MUST</bcp14> be placed
   immediately after a corresponding MELPe 2400 bps payload in the same
   RTP packet.  The packed parameters are counted in octets (TC).  The
   preferred placement SHOULD <bcp14>SHOULD</bcp14> be used for TSVCIS payloads with TC less
   than or equal to 77 octets, and octets; this is shown in Figure 6. <xref target="fig-6"/>.  In the
   preferred placement, a single trailing octet SHALL <bcp14>SHALL</bcp14> be appended to
   include a two-bit rate code, CODA and CODB, CODB (both bits set to one) one),
   and a six-bit modified count (MTC).  The special modified count value
   of all ones (representing a an MTC value of 63) SHALL NOT <bcp14>SHALL NOT</bcp14> be used for
   this format as it is used as the indicator for the alternate packing
   format shown next.  In a standard implementation, the TSVCIS speech
   coder uses a minimum of 15 octets for parameters in octet packed
   form.  The modified count (MTC) MUST <bcp14>MUST</bcp14> be reduced by 15 from the full
   octet count (TC).  Computed MTC = TC-15.  This accommodates a maximum
   of 77 parameter octets (maximum (the maximum value of MTC is 62, 62; 77 is the sum of
   62+15).</t>
        <figure title="Preferred anchor="fig-6">
          <name>Preferred Packed TSVCIS Payload Octets" anchor="fig-6"><artwork><![CDATA[ Octets</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
        MSB                                              LSB
         0      1      2      3      4      5      6      7
     +------+------+------+------+------+------+------+------+
  1  | T008 | T007 | T006 | T005 | T004 | T003 | T002 | T001 |
     +------+------+------+------+------+------+------+------+
  2  | T016 | T015 | T014 | T013 | T012 | T011 | T010 | T009 |
     +------+------+------+------+------+------+------+------+
  3  | T024 | T023 | T022 | T021 | T020 | T019 | T018 | T017 |
     +------+------+------+------+------+------+------+------+
  4  | T032 | T031 | T030 | T029 | T028 | T027 | T026 | T025 |
     +------+------+------+------+------+------+------+------+
  5  | T040 | T039 | T038 | T037 | T036 | T035 | T034 | T033 |
     +------+------+------+------+------+------+------+------+
  6  | T048 | T047 | T046 | T045 | T044 | T043 | T042 | T041 |
     +------+------+------+------+------+------+------+------+
  7  | TO56 | TO55 | T054 | T053 | T052 | T051 | T050 | T049 |
     +------+------+------+------+------+------+------+------+
  8  | T064 | T063 | T062 | T061 | T060 | T059 | T058 | T057 |
     +------+------+------+------+------+------+------+------+
  9  | T072 | T071 | T070 | T069 | T068 | T067 | T066 | T065 |
     +------+------+------+------+------+------+------+------+
 10  | T080 | T079 | T078 | T077 | T076 | T075 | T074 | T073 |
     +------+------+------+------+------+------+------+------+
 11  | T088 | T087 | T086 | T085 | T084 | T083 | T082 | T081 |
     +------+------+------+------+------+------+------+------+
 12  | TO96 | TO95 | T094 | T093 | T092 | T091 | T090 | T089 |
     +------+------+------+------+------+------+------+------+
 13  | T104 | T103 | T102 | T101 | T100 | T099 | T098 | T097 |
     +------+------+------+------+------+------+------+------+
 14  | T112 | T111 | T110 | T109 | T108 | T107 | T106 | T105 |
     +------+------+------+------+------+------+------+------+
 15  | T120 | T119 | T118 | T117 | T116 | T115 | T114 | T113 |
     +------+------+------+------+------+------+------+------+
     |                      .  .  .  .                       |
     +------+------+------+------+------+------+------+------+
TC+1 | CODA | CODB |          modified octet count           |
     +------+------+------+------+------+------+------+------+
]]></artwork>
        </figure>
        <t>
   In order to accommodate all other NRL VDR configurations, an
   alternate parameter placement MUST <bcp14>MUST</bcp14> use two trailing bytes as shown in
   Figure 7.
   <xref target="fig-7"/>.  The last trailing byte MUST <bcp14>MUST</bcp14> be filled with a two-bit rate
   code, CODA and CODB, CODB (both bits set to one) one), and its six-bit count
   field MUST <bcp14>MUST</bcp14> be filled with ones.  The second to last trailing byte
   MUST
   <bcp14>MUST</bcp14> contain the parameter count (TC) in octets (a value from 1 and
   255, inclusive). The value of zero SHALL <bcp14>SHALL</bcp14> be considered as reserved.</t>
        <figure title="Length anchor="fig-7">
          <name>Length Unrestricted Packed TSVCIS Payload Octets" anchor="fig-7"><artwork><![CDATA[ Octets</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
        MSB                                              LSB
         0      1      2      3      4      5      6      7
     +------+------+------+------+------+------+------+------+
  1  | T008 | T007 | T006 | T005 | T004 | T003 | T002 | T001 |
     +------+------+------+------+------+------+------+------+
  2  | T016 | T015 | T014 | T013 | T012 | T011 | T010 | T009 |
     +------+------+------+------+------+------+------+------+
     |                      .  .  .  .                       |
     +------+------+------+------+------+------+------+------+
TC+1 |                      octet count                      |
     +------+------+------+------+------+------+------+------+
TC+2 | CODA | CODB |   1  |   1  |   1  |   1  |   1  |   1  |
     +------+------+------+------+------+------+------+------+
]]></artwork>
        </figure>

      </section>
      <section title="Multiple anchor="sect-3.3" numbered="true" toc="default">
        <name>Multiple TSVCIS Frames in an RTP Packet" anchor="sect-3.3"><t> Packet</name>
        <t>
   A TSVCIS RTP packet payload consists of zero or more consecutive
   TSVCIS coder frames (each consisting of MELPe 2400 and TSVCIS coder
   data), with the oldest frame first, followed by zero or one MELPe
   comfort noise frame.  The presence of a comfort noise frame can be
   determined by its rate code bits in its last octet.</t>
        <t>
   The default packetization interval is one coder frame (22.5, 67.5, or
   90 ms) according to the coder bitrate (2400, 1200, or 600 bps). For
   some applications, a longer packetization interval is used to reduce
   the packet rate.</t>
        <t>
   A TSVCIS RTP packet without coder and comfort noise frames MAY <bcp14>MAY</bcp14> be
   used periodically by an endpoint to indicate connectivity by an
   otherwise idle receiver.</t>
        <t>
   TSVCIS coder frames in a single RTP packet MAY <bcp14>MAY</bcp14> have varying TSVCIS
   parameter octet counts.  Its packed parameter octet count (length) is
   indicated in the trailing byte(s).  All MELPe frames in a single RTP
   packet MUST <bcp14>MUST</bcp14> be of the same coder bitrate.  For all MELPe coder
   frames, the coder rate bits in the trailing byte identify the
   contents and length as per Table 1.</t> <xref target="tab-1"/>.</t>
        <t>
   It is important to observe that senders have the following additional
   restrictions:</t>

	<t>
   Senders SHOULD NOT
        <ul>
   <li>Senders <bcp14>SHOULD NOT</bcp14> include more TSVCIS or MELPe frames in a single
   RTP packet than will fit in the MTU of the RTP transport protocol.</t>

	<t> protocol.</li>
        <li>
   Frames MUST NOT <bcp14>MUST NOT</bcp14> be split between RTP packets.</t> packets.</li>
	</ul>
        <t>
   It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the number of frames contained within an RTP packet
   be consistent with the application.  For example, in telephony and other
   real-time applications where delay is important, then the fewer frames per
   packet
   packet, the lower the delay, whereas delay. However, for bandwidth-constrained links or
   delay-insensitive streaming messaging applications, more than one frame per
   packet or many frames per packet would be acceptable.</t>
        <t>
   Information describing the number of frames contained in an RTP
   packet is not transmitted as part of the RTP payload.  The way to
   determine the number of TSVCIS/MELPe frames is to identify each frame
   type and length length, thereby counting the total number of octets within
   the RTP packet.</t>
      </section>
      <section title="Congestion anchor="sect-3.4" numbered="true" toc="default">
        <name>Congestion Control Considerations" anchor="sect-3.4"><t> Considerations</name>
        <t>
   The target bitrate of TSVCIS can be adjusted at any point in time,
   thus allowing congestion management.  Furthermore, the amount of
   encoded speech or audio data encoded in a single packet can be used
   for congestion control, since the packet rate is inversely
   proportional to the packet duration.  A lower packet transmission
   rate reduces the amount of header overhead but at the same time
   increases latency and loss sensitivity, so it ought to be used
   with care.</t>
        <t>
   Since UDP does not provide congestion control, applications that use
   RTP over UDP SHOULD <bcp14>SHOULD</bcp14> implement their own congestion control above the
   UDP layer <xref target="RFC8085"/> target="RFC8085" format="default"/> and MAY <bcp14>MAY</bcp14> also implement a transport circuit
   breaker <xref target="RFC8083"/>. target="RFC8083" format="default"/>.  Work in the RMCAT working group Working Group <xref target="RMCAT"/> target="RMCAT" format="default"/> describes
   the interactions and conceptual interfaces necessary between the
   application components that relate to congestion control, including
   the RTP layer, the higher-level media codec control layer, and the
   lower-level transport interface, as well as components dedicated to
   congestion control functions.</t>
      </section>
    </section>
    <section title="Payload anchor="sect-4" numbered="true" toc="default">
      <name>Payload Format Parameters" anchor="sect-4"><t> Parameters</name>
      <t>
   This RTP payload format is identified using the TSVCIS media subtype,
   which is registered in accordance with RFC 4855 <xref target="RFC4855"/> target="RFC4855" format="default"/> and per the
   media type registration template from RFC 6838 <xref target="RFC6838"/>.</t> target="RFC6838" format="default"/>.</t>
      <section title="Media anchor="sect-4.1" numbered="true" toc="default">
        <name>Media Type Definitions" anchor="sect-4.1"><t>

   <list style="hanging">

   <t hangText="Type name:"> audio</t>

   <t hangText="Subtype name:"> TSVCIS</t>

   <t hangText="Required parameters:"> N/A</t>

   <t hangText="Optional parameters:">

   <list style="hanging" hangIndent="6">

     <t hangText="ptime:"> Definitions</name>
        <dl newline="false" spacing="normal">
          <dt>Type name:</dt>
          <dd> audio</dd>
          <dt>Subtype name:</dt>
          <dd> TSVCIS</dd>
          <dt>Required parameters:</dt>
     <dd>Clock Rate (Hz): 8000</dd>
	</dl>
        <dl newline="true" spacing="normal">
          <dt>Optional parameters:</dt>
          <dd>
            <dl newline="true" spacing="normal">
              <dt>ptime:</dt>
              <dd> the recommended length of time (in milliseconds)
              represented by the media in a packet.  It SHALL <bcp14>SHALL</bcp14>
              use the nearest rounded-up ms integer packet duration.  For
              TSVCIS, this corresponds to the following values: 23, 45, 68,
              90, 112, 135, 156, and 180.  Larger values can be used as long
              as they are properly rounded.  See Section 6
     of RFC 4566 <xref target="RFC4566"/>.</t>

     <t hangText="maxptime:"> target="RFC4566"
              sectionFormat="of" section="6"/>.</dd>

              <dt>maxptime:</dt>
              <dd> the maximum length of time (in milliseconds) that can be
              encapsulated in a packet.  It SHALL <bcp14>SHALL</bcp14> use the
              nearest rounded-up ms integer packet duration.  For TSVCIS, this
              corresponds to the following values: 23, 45, 68, 90, 112, 135,
              156, and 180.  Larger values can be used as long as they are
              properly rounded.  See Section 6
     of RFC 4566 <xref target="RFC4566"/>.</t>

     <t hangText="bitrate:"> target="RFC4566" sectionFormat="of"
              section="6"/>.</dd>

              <dt>bitrate:</dt>
              <dd> specifies the MELPe coder bitrates supported.  Possible
              values are a comma-separated list of rates from the following
              set: 2400, 1200, 600.  The modes are listed in order of
              preference; the first is preferred.  If "bitrate" is not
              present, the fixed coder bitrate of 2400 MUST <bcp14>MUST</bcp14> be
              used.	</t>

     <t hangText="tcmax:"> </dd>

	      <dt>tcmax:</dt>
              <dd> specifies the TSVCIS maximum value for the TC supported or desired
              desired, ranging from 1 to 255.  If "tcmax" is not present, a
              default value of 35 is used.</t>

	</list>
	</t>

     <t hangText="Encoding considerations:"> used.</dd>
<dt>Channels:</dt>
<dd>1</dd>
            </dl>
	  </dd></dl>
        <dl newline="false" spacing="normal">
          <dt>Encoding considerations:</dt>
          <dd> This media subtype is framed and binary; see
	Section 4.8 of RFC 6838 <xref target="RFC6838"/>.</t>

     <t hangText="Security considerations:">
          target="RFC6838" sectionFormat="of" section="4.8"/>.</dd>
          <dt>Security considerations:</dt>
          <dd> Please see Section 8 <xref target="sect-8"/> of RFC XXXX.</t>

<!-- [EDITOR NOTE - please replace XXXX with the RFC number of this document.] -->

     <t hangText="Interoperability considerations:"> N/A</t>

     <t hangText="Published specification:"> <xref target="TSVCIS"/></t>

     <t hangText="Applications 8817.</dd>
     <dt>Interoperability considerations:</dt>
          <dd>N/A</dd>
          <dt>Published specification:</dt>
          <dd>
            <xref target="TSVCIS" format="default"/></dd>
          <dt>Applications that use this media type:"> N/A</t>

     <t hangText="Fragment type:</dt>
          <dd>N/A</dd>
          <dt>Fragment identifier considerations:"> N/A</t>

     <t hangText="Additional information:">

	<list style="hanging" hangIndent="9">
        <?rfc subcompact="yes"?>
	  <t hangText="Clock Rate (Hz):"> 8000</t>
	  <t hangText="Channels:"> 1</t>
        <?rfc subcompact="no"?>
	</list>
     </t>

     <t hangText="Deprecated considerations:</dt>
          <dd>N/A</dd>

   <dt>Additional information:</dt><dd>
   <t><br/></t>
   <dl spacing="compact">
     <dt>Deprecated alias names for this type:"> N/A</t>

     <t hangText="Magic number(s):"> N/A</t>

     <t hangText="File extension(s):"> N/A</t>

     <t hangText="Macintosh 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):"> N/A</t>

     <t hangText="Person code(s):</dt>
     <dd>N/A</dd>
   </dl>
 </dd>

          <dt>Person &amp; email address to contact for further information:">

	<list>
	  <?rfc subcompact="yes"?>
	  <t>Victor information:</dt>
          <dd><t><br/><contact fullname="Victor Demjanenko, Ph.D.</t>
	  <t>VOCAL Technologies, Ltd.</t>
	  <t>520 Lee Entrance, Suite 202</t>
	  <t>Buffalo, NY  14228</t>
	  <t>United States of America</t>
	  <t>Phone: +1 716 688 4675</t>
	  <t>Email: victor.demjanenko@vocal.com</t>
        <?rfc subcompact="no"?>
	</list> Ph.D."/>
          &lt;victor.demjanenko@vocal.com&gt;
	</t>

      <t hangText="Intended usage:"> COMMON</t>

      <t hangText="Restrictions
	  </dd>

          <dt>Intended usage:</dt>
          <dd>COMMON</dd>
          <dt>Restrictions on usage:"> usage:</dt>
          <dd> The media subtype depends on RTP
      framing and hence is only defined for transfer via RTP <xref
      target="RFC3550"/>. target="RFC3550" format="default"/>.  Transport within other framing protocols is not
      defined at this time.</t>

      <t hangText="Author:">Victor Demjanenko</t>

      <t hangText="Change controller:"> IETF, time.</dd>
          <dt>Author:</dt>
          <dd><t><contact fullname="Victor Demjanenko, Ph.D."/></t></dd>
          <dt>Change controller:</dt>
          <dd> IETF; contact &lt;avt@ietf.org&gt;</t>

      <t hangText="Provisional &lt;avt@ietf.org&gt;</dd>
          <dt>Provisional registration? (standards tree only):"> No</t>

      </list>
    </t> only):</dt>
          <dd> No</dd>
        </dl>
      </section>
      <section title="Mapping anchor="sect-4.2" numbered="true" toc="default">
        <name>Mapping to SDP" anchor="sect-4.2"><t> SDP</name>
        <t>
   The mapping of the above-defined payload format media subtype and its
   parameters SHALL <bcp14>SHALL</bcp14> be done according to Section 3 of RFC 4855 <xref target="RFC4855"/>.</t> target="RFC4855" sectionFormat="of" section="3"/>.</t>
        <t>
   The information carried in the media type specification has a
   specific mapping to fields in the Session Description Protocol (SDP)
   <xref target="RFC4566"/>, target="RFC4566" format="default"/>, which is commonly used to describe RTP sessions.  When SDP
   is used to specify sessions employing the TSVCIS codec, the mapping
   is as follows:</t>

	<t><list style="symbols"><t>The
        <ul spacing="normal">
          <li>The media type ("audio") goes in SDP "m=" as the media name.</t>

	<t>The name.</li>
          <li>The media subtype (payload format name) goes in SDP "a=rtpmap" as
      the encoding name.</t>

	<t>The name.</li>
          <li>The parameter "bitrate" goes in the SDP "a=fmtp" attribute by
      copying it as a "bitrate=&lt;value&gt;" string.</t>

	<t>The string.</li>
          <li>The parameter "tcmax" goes in the SDP "a=fmtp" attribute by
      copying it as a "tcmax=&lt;value&gt;" string.</t>

	<t>The string.</li>
          <li>The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
      "a=maxptime" attributes, respectively.</t>

	</list>
	</t> respectively.</li>
        </ul>
        <t>
   When conveying information via SDP, the encoding name SHALL <bcp14>SHALL</bcp14> be
   "TSVCIS" (the same as the media subtype).</t>
        <t>
   An example of the media representation in SDP for describing TSVCIS
   might be:</t>

	<figure><artwork><![CDATA[
        <sourcecode type="sdp"><![CDATA[
   m=audio 49120 RTP/AVP 96
   a=rtpmap:96 TSVCIS/8000
]]></artwork>
	</figure>
]]></sourcecode>
        <t>
   The optional media type parameter "bitrate", when present, MUST <bcp14>MUST</bcp14> be
   included in the "a=fmtp" attribute in the SDP, expressed as a media
   type string in the form of a semicolon-separated list of
   parameter=value pairs.  The string "value" can be one or more of
   2400, 1200, and 600, separated by commas (where each bitrate value
   indicates the corresponding MELPe coder).  An example of the media
   representation in SDP for describing TSVCIS when all three coder
   bitrates are supported might be:</t>

	<figure><artwork><![CDATA[
        <sourcecode type="sdp"><![CDATA[
   m=audio 49120 RTP/AVP 96
   a=rtpmap:96 TSVCIS/8000
   a=fmtp:96 bitrate=2400,600,1200
]]></artwork>
	</figure>
]]></sourcecode>
        <t>
   The optional media type parameter "tcmax", when present, MUST <bcp14>MUST</bcp14> be
   included in the "a=fmtp" attribute in the SDP, expressed as a media
   type string in the form of a semicolon-separated list of
   parameter=value pairs.  The string "value" is an integer number in
   the range of 1 to 255 representing the maximum number of TSVCIS
   parameter octets supported.  An example of the media representation
   in SDP for describing TSVCIS with a maximum of 101 octets supported
   is as follows:</t>

	<figure><artwork><![CDATA[
        <sourcecode type="sdp"><![CDATA[
   m=audio 49120 RTP/AVP 96
   a=rtpmap:96 TSVCIS/8000
   a=fmtp:96 tcmax=101
]]></artwork>
	</figure>
]]></sourcecode>
        <t>
   The parameter "ptime" cannot be used for the purpose of specifying
   the TSVCIS operating mode, mode due to the fact that that, for certain values values, it
   will be impossible to distinguish which mode is about to be used
   (e.g., when ptime=68, it would be impossible to distinguish if whether the
   packet is carrying one frame of 67.5 ms or three frames of 22.5 ms).</t>
        <t>
   Note that the payload format (encoding) names are commonly shown in
   upper case.  Media subtypes are commonly shown in lower case.  These
   names are case insensitive in both places.  Similarly, parameter
   names are case insensitive in both the media subtype name and the
   default mapping to the SDP a=fmtp attribute.</t>
      </section>
      <section title="Declarative anchor="sect-4.3" numbered="true" toc="default">
        <name>Declarative SDP Considerations" anchor="sect-4.3"><t> Considerations</name>
        <t>
   For declarative media, the "bitrate" parameter specifies the possible
   bitrates used by the sender.  Multiple TSVCIS rtpmap values (such as
   97, 98, and 99, as used below) MAY <bcp14>MAY</bcp14> be used to convey TSVCIS-coded
   voice at different bitrates.  The receiver can then select an
   appropriate TSVCIS codec by using 97, 98, or 99.</t>

	<figure><artwork><![CDATA[
        <sourcecode type="sdp"><![CDATA[
   m=audio 49120 RTP/AVP 97 98 99
   a=rtpmap:97 TSVCIS/8000
   a=fmtp:97 bitrate=2400
   a=rtpmap:98 TSVCIS/8000
   a=fmtp:98 bitrate=1200
   a=rtpmap:99 TSVCIS/8000
   a=fmtp:99 bitrate=600
]]></artwork>
	</figure>
]]></sourcecode>
        <t>
   For declarative media, the "tcmax" parameter specifies the maximum
   number of octets of TSVCIS packed parameter octets parameters used by the sender or the
   sender's communications channel.</t>
      </section>
      <section title="Offer/Answer anchor="sect-4.4" numbered="true" toc="default">
        <name>Offer/Answer SDP Considerations" anchor="sect-4.4"><t> Considerations</name>
        <t>
   In the Offer/Answer model <xref target="RFC3264"/>, target="RFC3264" format="default"/>, "bitrate" is a bidirectional
   parameter.  Both sides MUST <bcp14>MUST</bcp14> use a common "bitrate" value or values.
   The offer contains the bitrates supported by the offerer, listed in
   its preferred order.  The answerer MAY <bcp14>MAY</bcp14> agree to any bitrate by
   listing the bitrate first in the answerer response.  Additionally,
   the answerer MAY <bcp14>MAY</bcp14> indicate any secondary bitrate or bitrates that it
   supports.  The initial bitrate used by both parties SHALL <bcp14>SHALL</bcp14> be the
   first bitrate specified in the answerer response.</t>

        <t>
   For example, if offerer bitrates are "2400,600" and answer answerer bitrates
   are "600,2400", the initial bitrate is 600.  If other bitrates are
   provided by the answerer, any common bitrate between the offer and
   answer MAY <bcp14>MAY</bcp14> be used at any time in the future.  Activation of these
   other common bitrates is beyond the scope of this document.</t>
        <t>
   The use of a lower bitrate is often important for a case such as when
   one endpoint utilizes a bandwidth-constrained link (e.g., 1200 bps
   radio link or slower), where only the lower coder bitrate will work.</t>
        <t>
   In the Offer/Answer model <xref target="RFC3264"/>, target="RFC3264" format="default"/>, "tcmax" is a bidirectional
   parameter.  Both sides SHOULD <bcp14>SHOULD</bcp14> use a common "tcmax" value.  The offer
   contains the tcmax supported by the offerer.  The answerer MAY <bcp14>MAY</bcp14> agree
   to any tcmax equal to or less than this value by stating the desired
   tcmax in the answerer response.  The answerer alternatively MAY <bcp14>MAY</bcp14>
   identify its own tcmax and rely on TSVCIS ignoring any augmented data
   it cannot use.</t>
      </section>
    </section>
    <section title="Discontinuous Transmissions" anchor="sect-5"><t> anchor="sect-5" numbered="true" toc="default">
      <name>Discontinuous Transmissions</name>
      <t>
   A primary application of TSVCIS is for radio communications of voice
   conversations, and discontinuous transmissions are normal.  When
   TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may
   cease and resume frequently.  RTP synchronization source (SSRC)
   sequence number gaps indicate lost packets to be filled by Packet
   Loss Concealment (PLC), while abrupt loss of RTP packets indicates
   intended discontinuous transmissions.  Resumption of voice
   transmission SHOULD <bcp14>SHOULD</bcp14> be indicated by the RTP marker bit (M) set to 1.</t>
      <t>If a TSVCIS coder so desires, it may send a MELPe comfort noise frame as
   per Appendix B of <xref target="SCIP210"/> target="SCIP210" format="default"/> prior to ceasing transmission. A
   receiver may optionally use comfort noise during its silence periods.  No
   SDP negotiations are required.
      </t>
    </section>
    <section title="Packet anchor="sect-6" numbered="true" toc="default">
      <name>Packet Loss Concealment" anchor="sect-6"><t> Concealment</name>
      <t>
   TSVCIS packet loss concealment (PLC) uses the special properties and
   coding for the pitch/voicing parameter of the MELPe 2400 bps coder.
   The PLC erasure indication utilizes any of the errored encodings of a
   non-voiced frame as identified in Table 1 of <xref target="MELPE"/>. target="MELPE" format="default"/>. For the sake of
   simplicity, it is preferred that a code value of 3 for the
   pitch/voicing parameter be used.  Hence, set bits P0 and P1 to one
   and bits P2, P3, P4, P5, and P6 to zero.</t>
      <t>
   When using PLC in 1200 bps or 600 bps mode, the MELPe 2400 bps
   decoder is called three or four times, respectively, to cover the
   loss of a low bitrate MELPe frame.</t>
    </section>
    <section title="IANA Considerations" anchor="sect-7"><t>
   This memo requests that anchor="sect-7" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   IANA registers has registered TSVCIS as specified in <xref target="sect-4.1"/>. target="sect-4.1"
   format="default"/>.  The media type is also requested to be has been added to the IANA
   registry for "RTP Payload Format MIME types" Media Types"
   (<eref target="http://www.iana.org/assignments/rtp-parameters"/>).</t> target="https://www.iana.org/assignments/rtp-parameters"/>).</t>
    </section>
    <section title="Security Considerations" anchor="sect-8"><t> anchor="sect-8" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification <xref target="RFC3550"/> target="RFC3550" format="default"/> and in any applicable RTP profile such as
   RTP/AVP <xref target="RFC3551"/>, target="RFC3551" format="default"/>, RTP/AVPF <xref target="RFC4585"/>, target="RFC4585" format="default"/>, RTP/SAVP <xref target="RFC3711"/>, target="RFC3711" format="default"/>, or
   RTP/SAVPF <xref target="RFC5124"/>. target="RFC5124" format="default"/>.  However, as discussed in <xref target="RFC7202"/>, target="RFC7202" format="default"/>, it is not
   an RTP payload format's responsibility to discuss or mandate what
   solutions are used to meet such basic security goals as
   confidentiality, integrity, and source authenticity for RTP in
   general.  This responsibility lies with anyone using RTP in an
   application.  They can find guidance on available security mechanisms
   and important considerations in <xref target="RFC7201"/>. target="RFC7201" format="default"/>.  Applications SHOULD <bcp14>SHOULD</bcp14> use
   one or more appropriate strong security mechanisms.  The rest of this
   section discusses the security-impacting properties of the payload
   format itself.</t>
      <t>
   This RTP payload format and the TSVCIS decoder, to the best of our
   knowledge, do not exhibit any significant non-uniformity in the
   receiver-side computational complexity for packet processing and thus
   are unlikely to pose a denial-of-service threat due to the receipt of
   pathological data. Additionally, the RTP payload format does not
   contain any active content.</t>
      <t>
   Please see the security considerations discussed in <xref target="RFC6562"/> target="RFC6562" format="default"/>
   regarding Voice Activity Detect (VAD) and its effect on bitrates.</t>
    </section>
  </middle>
  <back>
	<references title="Normative References">
	&RFC2119;
	&RFC8174;
	&RFC2736;
	&RFC8088;
	&RFC3264;
	&RFC3550;
	&RFC3551;
	&RFC8130;
	&RFC3711;
	&RFC4566;
	&RFC4855;
	&RFC5124;
	&RFC6562;
	&RFC6838;
	&RFC8083;
	&RFC8085;
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2736.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8088.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3551.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8130.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4855.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5124.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6562.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8083.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
        <reference anchor="NRLVDR"><front> anchor="NRLVDR">
          <front>
            <title>Universal Vocoder Using Variable Data Rate Vocoding</title>
            <seriesInfo name="DOI" value="10.21236/ada588068"/>
            <seriesInfo name="Naval Research Lab" value="NRL/FR/5555--13-10, 239"/>
            <author initials="D." surname="Heide" fullname="D. fullname="David Heide">
	</author>
            <author initials="A." surname="Cohen" fullname="A. fullname="Aaron Cohen">
	</author>
            <author initials="Y." surname="Lee" fullname="Y. fullname="Yvette Lee">
	</author>
            <author initials="T." surname="Moran" fullname="T. fullname="Thomas Moran">
	</author>
            <date month="June" year="2013"/>
          </front>

	<seriesInfo name="Naval Research Lab" value="NRL/FR/5555-13-10, 239"/>
        </reference>
        <reference anchor="MELP"><front> anchor="MELP">
          <front>
            <title>Analog-to-Digital Conversion of Voice by 2,400 Bit/Second Mixed Excitation Linear Prediction (MELP)</title>
	<author>
	<organization>Department
            <seriesInfo name="Department of Defense Telecommunications Standard</organization> Standard" value="MIL-STD-3005"/>
            <author>
              <organization>Department of Defense</organization>
            </author>
            <date month="December" year="1999"/>
          </front>
	<seriesInfo name="" value="MIL-STD-3005"/>
        </reference>
        <reference anchor="MELPE"><front> anchor="MELPE">
          <front>
            <title>The 600 Bit/S, 1200 Bit/S and 2400 Bit/S NATO Interoperable Narrow Band Voice Coder</title>
            <seriesInfo name="STANAG" value="No. 4591"/>
            <author>
              <organization>North Atlantic Treaty Organization (NATO)</organization>
            </author>
            <date month="January" year="2006"/> month="October" year="2008"/>
          </front>

	<seriesInfo name="STANAG" value="No. 4591"/>
        </reference>
        <reference anchor="SCIP210"><front> anchor="SCIP210">
          <front>
            <title>SCIP Signaling Plan</title>
            <author>
              <organization>National Security Agency</organization>
            </author>
            <date month="December" year="2007"/> month="January" year="2013"/>
          </front>
	<seriesInfo name="" value="SCIP-210"/>
	  <refcontent>SCIP-210</refcontent>
        </reference>
      </references>
	<references title="Informative References">

      <references>
        <name>Informative References</name>
        <reference anchor="TSVCIS"><front> anchor="TSVCIS">
          <front>
            <title>Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Version 3.1</title>
            <seriesInfo name="NSA" value="09-01A"/>
            <author>
              <organization>National Security Agency</organization>
            </author>
            <date month="March" year="2019"/>
          </front>

	<seriesInfo name="NSA" value="09-01A"/>
        </reference>
	&RFC4585;
	&RFC7201;
	&RFC7202;
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7201.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7202.xml"/>
        <reference anchor="RMCAT" target="https://datatracker.ietf.org/wg/rmcat/about/"><front> target="https://datatracker.ietf.org/wg/rmcat/about/">
          <front>
            <title>RTP Media Congestion Avoidance Techniques (rmcat) Working Group</title>
            <author>
              <organization>IETF</organization>
            </author>

	<date/>
          </front>
        </reference>
      </references>
    </references>
  </back>
</rfc>