File: rfc8817.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2615 lines) | stat: -rw-r--r-- 118,072 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8817: RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec</title>
<meta content="Victor Demjanenko, Ph.D." name="author">
<meta content="John Punaro" name="author">
<meta content="David Satterlee" name="author">
<meta content="
       
   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
   to enhance voice quality.  TSVCIS augmented speech data is
   processed in conjunction with its temporally matched Mixed Excitation Linear
   Prediction (MELP) 2400 speech data.  The RTP packetization of TSVCIS and
      MELPe speech coder data is described in detail. 
    " name="description">
<meta content="xml2rfc 2.47.0" name="generator">
<meta content="MELP" name="keyword">
<meta content="MELPe" name="keyword">
<meta content="TSVCIS" name="keyword">
<meta content="NRLVDR" name="keyword">
<meta content="Naval Research Laboratory" name="keyword">
<meta content="NRL" name="keyword">
<meta content="NATO" name="keyword">
<meta content="TSVWG" name="keyword">
<meta content="Department of Defense" name="keyword">
<meta content="DoD" name="keyword">
<meta content="NSA" name="keyword">
<meta content="MIL-STD" name="keyword">
<meta content="8817" name="rfc.number">
<link href="rfc8817.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8817" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis-05" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8817</td>
<td class="center">RTP Payload Format for TSVCIS Codec</td>
<td class="right">August 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Demjanenko, et al.</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8817" class="eref">8817</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-08" class="published">August 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">V. Demjanenko</div>
<div class="org">VOCAL Technologies, Ltd.</div>
</div>
<div class="author">
      <div class="author-name">J. Punaro</div>
<div class="org">VOCAL Technologies, Ltd.</div>
</div>
<div class="author">
      <div class="author-name">D. Satterlee</div>
<div class="org">VOCAL Technologies, Ltd.</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8817</h1>
<h1 id="title">RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
   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
   to enhance voice quality.  TSVCIS augmented speech data is
   processed in conjunction with its temporally matched Mixed Excitation Linear
   Prediction (MELP) 2400 speech data.  The RTP packetization of TSVCIS and
      MELPe speech coder data is described in detail.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8817">https://www.rfc-editor.org/info/rfc8817</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-conventions" class="xref">Conventions</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-abbreviations" class="xref">Abbreviations</a><a href="#section-toc.1-1.1.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-background" class="xref">Background</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-payload-format" class="xref">Payload Format</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-melpe-bitstream-definitions" class="xref">MELPe Bitstream Definitions</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.3.2.1.2.1">
                    <p id="section-toc.1-1.3.2.1.2.1.1"><a href="#section-3.1.1" class="xref">3.1.1</a>.  <a href="#name-2400-bps-bitstream-structur" class="xref">2400 bps Bitstream Structure</a><a href="#section-toc.1-1.3.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.3.2.1.2.2">
                    <p id="section-toc.1-1.3.2.1.2.2.1"><a href="#section-3.1.2" class="xref">3.1.2</a>.  <a href="#name-1200-bps-bitstream-structur" class="xref">1200 bps Bitstream Structure</a><a href="#section-toc.1-1.3.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.3.2.1.2.3">
                    <p id="section-toc.1-1.3.2.1.2.3.1"><a href="#section-3.1.3" class="xref">3.1.3</a>.  <a href="#name-600-bps-bitstream-structure" class="xref">600 bps Bitstream Structure</a><a href="#section-toc.1-1.3.2.1.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.3.2.1.2.4">
                    <p id="section-toc.1-1.3.2.1.2.4.1"><a href="#section-3.1.4" class="xref">3.1.4</a>.  <a href="#name-comfort-noise-bitstream-def" class="xref">Comfort Noise Bitstream Definition</a><a href="#section-toc.1-1.3.2.1.2.4.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-tsvcis-bitstream-definition" class="xref">TSVCIS Bitstream Definition</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-multiple-tsvcis-frames-in-a" class="xref">Multiple TSVCIS Frames in an RTP Packet</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-congestion-control-consider" class="xref">Congestion Control Considerations</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-payload-format-parameters" class="xref">Payload Format Parameters</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-media-type-definitions" class="xref">Media Type Definitions</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-mapping-to-sdp" class="xref">Mapping to SDP</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-declarative-sdp-considerati" class="xref">Declarative SDP Considerations</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-offer-answer-sdp-considerat" class="xref">Offer/Answer SDP Considerations</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-discontinuous-transmissions" class="xref">Discontinuous Transmissions</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-packet-loss-concealment" class="xref">Packet Loss Concealment</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="sect-1">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">
   This document describes how compressed Tactical Secure Voice
   Cryptographic Interoperability Specification (TSVCIS) speech as
   produced by the TSVCIS codec <span>[<a href="#TSVCIS" class="xref">TSVCIS</a>]</span> <span>[<a href="#NRLVDR" class="xref">NRLVDR</a>]</span> may be formatted for
   use as an RTP payload.  The TSVCIS speech coder (or TSVCIS 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.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
   Details are provided for packetizing the TSVCIS augmented speech data
   along with MELPe 2400 bps speech parameters in 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.<a href="#section-1-2" class="pilcrow">¶</a></p>
<div id="sect-1.1">
<section id="section-1.1">
        <h3 id="name-conventions">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-conventions" class="section-name selfRef">Conventions</a>
        </h3>
<p id="section-1.1-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>",
    "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">
   Best current practices for writing an RTP payload format
   specification were followed <span>[<a href="#RFC2736" class="xref">RFC2736</a>]</span> <span>[<a href="#RFC8088" class="xref">RFC8088</a>]</span>.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-1.2">
<section id="section-1.2">
        <h3 id="name-abbreviations">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-abbreviations" class="section-name selfRef">Abbreviations</a>
        </h3>
<p id="section-1.2-1">The following abbreviations are used in this document.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-1.2-2">
          <dt id="section-1.2-2.1">AVP:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.2">Audio/Video Profile<a href="#section-1.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.3">AVPF:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.4">Audio/Video Profile Feedback<a href="#section-1.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.5">CELP:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.6">Code-Excited Linear Prediction<a href="#section-1.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.7">FEC:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.8">Forward Error Correction<a href="#section-1.2-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.9">LPC:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.10">Linear-Predictive Coding<a href="#section-1.2-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.11">LSB:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.12">Least Significant Bit<a href="#section-1.2-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.13">MELP:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.14">Mixed Excitation Linear Prediction<a href="#section-1.2-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.15">MELPe:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.16">Mixed Excitation Linear Prediction Enhanced<a href="#section-1.2-2.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.17">MSB:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.18">Most Significant Bit<a href="#section-1.2-2.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.19">MTC:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.20">Modified Count<a href="#section-1.2-2.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.21">NATO:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.22">North American Treaty Organization<a href="#section-1.2-2.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.23">NRL:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.24">Naval Research Lab<a href="#section-1.2-2.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.25">PLC:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.26">Packet Loss Concealment<a href="#section-1.2-2.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.27">SAVP:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.28">Secure Audio/Video Profile<a href="#section-1.2-2.28" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.29">SAVPF:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.30">Secure Audio/Video Profile Feedback<a href="#section-1.2-2.30" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.31">SDP:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.32">Session Description Protocol<a href="#section-1.2-2.32" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.33">SSRC:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.34">Synchronization Source<a href="#section-1.2-2.34" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.35">SRTP:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.36">Secure Real-Time Transport Protocol<a href="#section-1.2-2.36" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.37">TSVCIS:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.38">Tactical Secure Voice Cryptographic Interoperability Specification<a href="#section-1.2-2.38" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.39">VAD:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.40">Voice Activity Detect<a href="#section-1.2-2.40" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.41">VDR:</dt>
          <dd style="margin-left: 5.0em" id="section-1.2-2.42">Variable Date Rate<a href="#section-1.2-2.42" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="sect-2">
<section id="section-2">
      <h2 id="name-background">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-background" class="section-name selfRef">Background</a>
      </h2>
<p id="section-2-1">
   The MELP speech coder was developed by the US military as an upgrade
   from the LPC-based CELP standard vocoder for low-bitrate
   communications <span>[<a href="#MELP" class="xref">MELP</a>]</span>.  ("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" for use by
   its members and Partnership for Peace countries for military and
   other governmental communications as international NATO Standard
   STANAG 4591 <span>[<a href="#MELPE" class="xref">MELPE</a>]</span>.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">
   The Tactical Secure Voice Cryptographic Interoperability
   Specification (TSVCIS) is a specification written by the Tactical
   Secure Voice Working Group (TSVWG) to enable all modern tactical
   secure voice devices to be interoperable across the US Department of
   Defense <span>[<a href="#TSVCIS" class="xref">TSVCIS</a>]</span>.  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, which
   uses the MELPe standard as its base <span>[<a href="#NRLVDR" class="xref">NRLVDR</a>]</span>.  A complete TSVCIS
   speech frame consists of MELPe speech parameters and corresponding
   TSVCIS augmented speech data.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">
   In addition to the augmented speech data, the TSVCIS specification
   identifies which speech coder and framing bits are to be 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 bits need to be considered and are conveyed in
   unencrypted form.  In most IP-based network deployments, standard
   link encryption methods (Secure Real-Time Transport Protocol (SRTP), VPNs, FIPS 140 link encryptors, or Type
   1 Ethernet encryptors) would be used to secure the RTP speech
   contents.<a href="#section-2-3" class="pilcrow">¶</a></p>
<p id="section-2-4">
   TSVCIS augmented speech data is derived from the signal processing
   and data 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.<a href="#section-2-4" class="pilcrow">¶</a></p>
<p id="section-2-5">
   Byte packing of TSVCIS speech data into packed parameters is
   processed as per the following example, where<a href="#section-2-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2-6">
        <dt id="section-2-6.1">Three-bit field:</dt>
        <dd id="section-2-6.2">Bits A, B, and C (A is MSB; C is LSB)<a href="#section-2-6.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-6.3">Five-bit field:</dt>
        <dd id="section-2-6.4">Bits D, E, F, G, and H (D is MSB; H is LSB)<a href="#section-2-6.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<div class="artwork art-text alignLeft" id="section-2-7">
<pre>
        MSB                                              LSB
         0      1      2      3      4      5      6      7
     +------+------+------+------+------+------+------+------+
     |   H  |   G  |   F  |   E  |   D  |   C  |   B  |   A  |
     +------+------+------+------+------+------+------+------+
</pre><a href="#section-2-7" class="pilcrow">¶</a>
</div>
<p id="section-2-8">
   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 <span class="bcp14">MUST</span> be filled with
      zero.<a href="#section-2-8" class="pilcrow">¶</a></p>
<p id="section-2-9">
   In order to accommodate a varying amount of TSVCIS augmented speech
   data, an octet count specifies the number of octets representing
   the TSVCIS packed parameters.  The encoding to do so is presented in
   <a href="#sect-3.2" class="xref">Section 3.2</a>.  TSVCIS specifically uses the NRL VDR in two
   configurations with a fixed set of 15 and 35 packed octet
   parameters in a standardized order <span>[<a href="#TSVCIS" class="xref">TSVCIS</a>]</span>.<a href="#section-2-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-3">
<section id="section-3">
      <h2 id="name-payload-format">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-payload-format" class="section-name selfRef">Payload Format</a>
      </h2>
<p id="section-3-1">
   The TSVCIS codec augments the standard MELP 2400, 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 <span class="bcp14">MUST</span> be in units of 1/8000
   of a second.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
   The RTP payload for TSVCIS has the format shown in <a href="#fig-1" class="xref">Figure 1</a>.  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.<a href="#section-3-2" class="pilcrow">¶</a></p>
<span id="name-packet-format-diagram"></span><div id="fig-1">
<figure id="figure-1">
        <div class="artwork art-text alignLeft" id="section-3-3.1">
<pre>
 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                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-packet-format-diagram" class="selfRef">Packet Format Diagram</a>
        </figcaption></figure>
</div>
<p id="section-3-4">
   The RTP header of the packetized encoded TSVCIS speech has the
   expected values as described in <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>.  The usage of the M bit
   <span class="bcp14">SHOULD</span> be as specified in the applicable RTP profile -- for example,
   <span>[<a href="#RFC3551" class="xref">RFC3551</a>]</span> 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.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">
   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; if that
   is not done, then a payload type in the dynamic range shall be chosen
   by the sender.<a href="#section-3-5" class="pilcrow">¶</a></p>
<div id="sect-3.1">
<section id="section-3.1">
        <h3 id="name-melpe-bitstream-definitions">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-melpe-bitstream-definitions" class="section-name selfRef">MELPe Bitstream Definitions</a>
        </h3>
<p id="section-3.1-1">
   The TSVCIS speech coder includes all three MELPe coder rates used as
   base speech parameters or as speech coders for bandwidth-restricted
   links.  RTP packetization of MELPe follows <span>[<a href="#RFC8130" class="xref">RFC8130</a>]</span> and is repeated
   here for all three MELPe rates <span>[<a href="#RFC8130" class="xref">RFC8130</a>]</span>, with its recommendations now
   regarded as requirements.  The bits previously labeled as RSVA, RSVB,
   and RSVC in <span>[<a href="#RFC8130" class="xref">RFC8130</a>]</span> <span class="bcp14">SHOULD</span> be filled with
   rate code bits CODA, CODB,
   and CODC, as shown in <a href="#tab-1" class="xref">Table 1</a> (compatible with Table 7 in <span><a href="https://www.rfc-editor.org/rfc/rfc8130#section-3.3" class="relref">Section 3.3</a> of [<a href="#RFC8130" class="xref">RFC8130</a>]</span>).<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<span id="name-tsvcis-melpe-frame-bitrate-"></span><div id="tab-1">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-tsvcis-melpe-frame-bitrate-" class="selfRef">TSVCIS/MELPe Frame Bitrate Indicators and Frame Length</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Coder Bitrate</th>
              <th class="text-left" rowspan="1" colspan="1">CODA</th>
              <th class="text-left" rowspan="1" colspan="1">CODB</th>
              <th class="text-left" rowspan="1" colspan="1">CODC</th>
              <th class="text-left" rowspan="1" colspan="1">Length</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2400 bps</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">N/A</td>
              <td class="text-left" rowspan="1" colspan="1">7</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1200 bps</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">11</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">600 bps</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">N/A</td>
              <td class="text-left" rowspan="1" colspan="1">7</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Comfort Noise</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">2</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">TSVCIS Data</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">N/A</td>
              <td class="text-left" rowspan="1" colspan="1">var.</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-3.1-3">
   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 <a href="#sect-3.2" class="xref">Section 3.2</a>.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">
   It should be noted that CODB for MELPe 600 bps mode <span class="bcp14">MAY</span> deviate from
   the value in <a href="#tab-1" class="xref">Table 1</a> 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, and the use of 600 bps speech coding could be deduced
   from the RTP timestamp (and anticipated by the Session Description Protocol
 (SDP) negotiations).<a href="#section-3.1-4" class="pilcrow">¶</a></p>
<div id="sect-3.1.1">
<section id="section-3.1.1">
          <h4 id="name-2400-bps-bitstream-structur">
<a href="#section-3.1.1" class="section-number selfRef">3.1.1. </a><a href="#name-2400-bps-bitstream-structur" class="section-name selfRef">2400 bps Bitstream Structure</a>
          </h4>
<p id="section-3.1.1-1">
   The 2400 bps MELPe RTP payload is constructed as per <a href="#fig-2" class="xref">Figure 2</a>.  Note
   that CODA <span class="bcp14">MUST</span> be filled with 0 and CODB <span class="bcp14">SHOULD</span> be filled with 0 as
   per <a href="#sect-3.1" class="xref">Section 3.1</a>.  CODB <span class="bcp14">MAY</span> contain an end-to-end framing bit if
   required by the endpoints.<a href="#section-3.1.1-1" class="pilcrow">¶</a></p>
<span id="name-packed-melpe-2400-bps-paylo"></span><div id="fig-2">
<figure id="figure-2">
            <div class="artwork art-text alignLeft" id="section-3.1.1-2.1">
<pre>
        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 |
     +------+------+------+------+------+------+------+------+
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-packed-melpe-2400-bps-paylo" class="selfRef">Packed MELPe 2400 bps Payload Octets</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="sect-3.1.2">
<section id="section-3.1.2">
          <h4 id="name-1200-bps-bitstream-structur">
<a href="#section-3.1.2" class="section-number selfRef">3.1.2. </a><a href="#name-1200-bps-bitstream-structur" class="section-name selfRef">1200 bps Bitstream Structure</a>
          </h4>
<p id="section-3.1.2-1">
   The 1200 bps MELPe RTP payload is constructed as per <a href="#fig-3" class="xref">Figure 3</a>.  Note
   that CODA, CODB, and CODC <span class="bcp14">MUST</span> be filled with 1, 0, and 0,
   respectively, as per <a href="#sect-3.1" class="xref">Section 3.1</a>.  RSV0 <span class="bcp14">MUST</span> be coded as 0.<a href="#section-3.1.2-1" class="pilcrow">¶</a></p>
<span id="name-packed-melpe-1200-bps-paylo"></span><div id="fig-3">
<figure id="figure-3">
            <div class="artwork art-text alignLeft" id="section-3.1.2-2.1">
<pre>
        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 |
     +------+------+------+------+------+------+------+------+
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-packed-melpe-1200-bps-paylo" class="selfRef">Packed MELPe 1200 bps Payload Octets</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="sect-3.1.3">
<section id="section-3.1.3">
          <h4 id="name-600-bps-bitstream-structure">
<a href="#section-3.1.3" class="section-number selfRef">3.1.3. </a><a href="#name-600-bps-bitstream-structure" class="section-name selfRef">600 bps Bitstream Structure</a>
          </h4>
<p id="section-3.1.3-1">
   The 600 bps MELPe RTP payload is constructed as per <a href="#fig-4" class="xref">Figure 4</a>.  Note
   CODA <span class="bcp14">MUST</span> be filled with 0 and CODB <span class="bcp14">SHOULD</span> be filled with 1 as per
   <a href="#sect-3.1" class="xref">Section 3.1</a>.  CODB <span class="bcp14">MAY</span> contain an end-to-end framing bit if required
   by the endpoints.<a href="#section-3.1.3-1" class="pilcrow">¶</a></p>
<span id="name-packed-melpe-600-bps-payloa"></span><div id="fig-4">
<figure id="figure-4">
            <div class="artwork art-text alignLeft" id="section-3.1.3-2.1">
<pre>
        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 |
     +------+------+------+------+------+------+------+------+
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-packed-melpe-600-bps-payloa" class="selfRef">Packed MELPe 600 bps Payload Octets</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="sect-3.1.4">
<section id="section-3.1.4">
          <h4 id="name-comfort-noise-bitstream-def">
<a href="#section-3.1.4" class="section-number selfRef">3.1.4. </a><a href="#name-comfort-noise-bitstream-def" class="section-name selfRef">Comfort Noise Bitstream Definition</a>
          </h4>
<p id="section-3.1.4-1">
   The comfort noise MELPe RTP payload is constructed as per <a href="#fig-5" class="xref">Figure 5</a>.
   Note that CODA, CODB, and CODC <span class="bcp14">MUST</span> be filled with 1, 0, and 1,
   respectively, as per <a href="#sect-3.1" class="xref">Section 3.1</a>.<a href="#section-3.1.4-1" class="pilcrow">¶</a></p>
<span id="name-packed-melpe-comfort-noise-"></span><div id="fig-5">
<figure id="figure-5">
            <div class="artwork art-text alignLeft" id="section-3.1.4-2.1">
<pre>
        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 |
     +------+------+------+------+------+------+------+------+
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-packed-melpe-comfort-noise-" class="selfRef">Packed MELPe Comfort Noise Payload Octets</a>
            </figcaption></figure>
</div>
</section>
</div>
</section>
</div>
<div id="sect-3.2">
<section id="section-3.2">
        <h3 id="name-tsvcis-bitstream-definition">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-tsvcis-bitstream-definition" class="section-name selfRef">TSVCIS Bitstream Definition</a>
        </h3>
<p id="section-3.2-1">
   The TSVCIS augmented speech data as packed parameters <span class="bcp14">MUST</span> 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 <span class="bcp14">SHOULD</span> be used for TSVCIS payloads with TC less
   than or equal to 77 octets; this is shown in <a href="#fig-6" class="xref">Figure 6</a>.  In the
   preferred placement, a single trailing octet <span class="bcp14">SHALL</span> be appended to
   include a two-bit rate code, CODA and CODB (both bits set to one),
   and a six-bit modified count (MTC).  The special modified count value
   of all ones (representing an MTC value of 63) <span class="bcp14">SHALL NOT</span> 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) <span class="bcp14">MUST</span> be reduced by 15 from the full
   octet count (TC).  Computed MTC = TC-15.  This accommodates a maximum
   of 77 parameter octets (the maximum value of MTC is 62; 77 is the sum of
   62+15).<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<span id="name-preferred-packed-tsvcis-pay"></span><div id="fig-6">
<figure id="figure-6">
          <div class="artwork art-text alignLeft" id="section-3.2-2.1">
<pre>
        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           |
     +------+------+------+------+------+------+------+------+
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-preferred-packed-tsvcis-pay" class="selfRef">Preferred Packed TSVCIS Payload Octets</a>
          </figcaption></figure>
</div>
<p id="section-3.2-3">
   In order to accommodate all other NRL VDR configurations, an
   alternate parameter placement <span class="bcp14">MUST</span> use two trailing bytes as shown in
   <a href="#fig-7" class="xref">Figure 7</a>.  The last trailing byte <span class="bcp14">MUST</span> be filled with a two-bit rate
   code, CODA and CODB (both bits set to one), and its six-bit count
   field <span class="bcp14">MUST</span> be filled with ones.  The second to last trailing byte
   <span class="bcp14">MUST</span> contain the parameter count (TC) in octets (a value from 1 and
   255, inclusive). The value of zero <span class="bcp14">SHALL</span> be considered as reserved.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<span id="name-length-unrestricted-packed-"></span><div id="fig-7">
<figure id="figure-7">
          <div class="artwork art-text alignLeft" id="section-3.2-4.1">
<pre>
        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  |
     +------+------+------+------+------+------+------+------+
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-length-unrestricted-packed-" class="selfRef">Length Unrestricted Packed TSVCIS Payload Octets</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="sect-3.3">
<section id="section-3.3">
        <h3 id="name-multiple-tsvcis-frames-in-a">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-multiple-tsvcis-frames-in-a" class="section-name selfRef">Multiple TSVCIS Frames in an RTP Packet</a>
        </h3>
<p id="section-3.3-1">
   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.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">
   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.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<p id="section-3.3-3">
   A TSVCIS RTP packet without coder and comfort noise frames <span class="bcp14">MAY</span> be
   used periodically by an endpoint to indicate connectivity by an
   otherwise idle receiver.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
<p id="section-3.3-4">
   TSVCIS coder frames in a single RTP packet <span class="bcp14">MAY</span> 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 <span class="bcp14">MUST</span> 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 <a href="#tab-1" class="xref">Table 1</a>.<a href="#section-3.3-4" class="pilcrow">¶</a></p>
<p id="section-3.3-5">
   It is important to observe that senders have the following additional
   restrictions:<a href="#section-3.3-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.3-6.1">Senders <span class="bcp14">SHOULD NOT</span> include more TSVCIS or MELPe frames in a single
   RTP packet than will fit in the MTU of the RTP transport protocol.<a href="#section-3.3-6.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.3-6.2">
   Frames <span class="bcp14">MUST NOT</span> be split between RTP packets.<a href="#section-3.3-6.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.3-7">
   It is <span class="bcp14">RECOMMENDED</span> 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, the fewer frames per
   packet, the lower the 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.<a href="#section-3.3-7" class="pilcrow">¶</a></p>
<p id="section-3.3-8">
   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, thereby counting the total number of octets within
   the RTP packet.<a href="#section-3.3-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-3.4">
<section id="section-3.4">
        <h3 id="name-congestion-control-consider">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-congestion-control-consider" class="section-name selfRef">Congestion Control Considerations</a>
        </h3>
<p id="section-3.4-1">
   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.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.4-2">
   Since UDP does not provide congestion control, applications that use
   RTP over UDP <span class="bcp14">SHOULD</span> implement their own congestion control above the
   UDP layer <span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span> and <span class="bcp14">MAY</span> also implement a transport circuit
   breaker <span>[<a href="#RFC8083" class="xref">RFC8083</a>]</span>.  Work in the RMCAT Working Group <span>[<a href="#RMCAT" class="xref">RMCAT</a>]</span> 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.<a href="#section-3.4-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-4">
<section id="section-4">
      <h2 id="name-payload-format-parameters">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-payload-format-parameters" class="section-name selfRef">Payload Format Parameters</a>
      </h2>
<p id="section-4-1">
   This RTP payload format is identified using the TSVCIS media subtype,
   which is registered in accordance with <span>[<a href="#RFC4855" class="xref">RFC4855</a>]</span> and per the
   media type registration template from <span>[<a href="#RFC6838" class="xref">RFC6838</a>]</span>.<a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="sect-4.1">
<section id="section-4.1">
        <h3 id="name-media-type-definitions">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-media-type-definitions" class="section-name selfRef">Media Type Definitions</a>
        </h3>
<span class="break"></span><dl class="dlParallel" id="section-4.1-1">
          <dt id="section-4.1-1.1">Type name:</dt>
          <dd id="section-4.1-1.2"> audio<a href="#section-4.1-1.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-1.3">Subtype name:</dt>
          <dd id="section-4.1-1.4"> TSVCIS<a href="#section-4.1-1.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-1.5">Required parameters:</dt>
          <dd id="section-4.1-1.6">Clock Rate (Hz): 8000<a href="#section-4.1-1.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlNewline" id="section-4.1-2">
          <dt id="section-4.1-2.1">Optional parameters:</dt>
          <dd id="section-4.1-2.2">
            <span class="break"></span><dl class="dlNewline" id="section-4.1-2.2.1">
              <dt id="section-4.1-2.2.1.1">ptime:</dt>
              <dd id="section-4.1-2.2.1.2"> the recommended length of time (in milliseconds)
              represented by the media in a packet.  It <span class="bcp14">SHALL</span>
              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 <span><a href="https://www.rfc-editor.org/rfc/rfc4566#section-6" class="relref">Section 6</a> of [<a href="#RFC4566" class="xref">RFC4566</a>]</span>.<a href="#section-4.1-2.2.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-2.2.1.3">maxptime:</dt>
              <dd id="section-4.1-2.2.1.4"> the maximum length of time (in milliseconds) that can be
              encapsulated in a packet.  It <span class="bcp14">SHALL</span> 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 <span><a href="https://www.rfc-editor.org/rfc/rfc4566#section-6" class="relref">Section 6</a> of [<a href="#RFC4566" class="xref">RFC4566</a>]</span>.<a href="#section-4.1-2.2.1.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-2.2.1.5">bitrate:</dt>
              <dd id="section-4.1-2.2.1.6"> 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 <span class="bcp14">MUST</span> be
              used.<a href="#section-4.1-2.2.1.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-2.2.1.7">tcmax:</dt>
              <dd id="section-4.1-2.2.1.8"> specifies the TSVCIS maximum value for the TC supported or
              desired, ranging from 1 to 255.  If "tcmax" is not present, a
              default value of 35 is used.<a href="#section-4.1-2.2.1.8" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-2.2.1.9">Channels:</dt>
              <dd id="section-4.1-2.2.1.10">1<a href="#section-4.1-2.2.1.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel" id="section-4.1-3">
          <dt id="section-4.1-3.1">Encoding considerations:</dt>
          <dd id="section-4.1-3.2"> This media subtype is framed and binary; see <span><a href="https://www.rfc-editor.org/rfc/rfc6838#section-4.8" class="relref">Section 4.8</a> of [<a href="#RFC6838" class="xref">RFC6838</a>]</span>.<a href="#section-4.1-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-3.3">Security considerations:</dt>
          <dd id="section-4.1-3.4"> Please see <a href="#sect-8" class="xref">Section 8</a> of RFC 8817.<a href="#section-4.1-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-3.5">Interoperability considerations:</dt>
          <dd id="section-4.1-3.6">N/A<a href="#section-4.1-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-3.7">Published specification:</dt>
          <dd id="section-4.1-3.8">
            <span>[<a href="#TSVCIS" class="xref">TSVCIS</a>]</span><a href="#section-4.1-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-3.9">Applications that use this media type:</dt>
          <dd id="section-4.1-3.10">N/A<a href="#section-4.1-3.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-3.11">Fragment identifier considerations:</dt>
          <dd id="section-4.1-3.12">N/A<a href="#section-4.1-3.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-3.13">Additional information:</dt>
          <dd id="section-4.1-3.14">
            <p id="section-4.1-3.14.1"><br></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-4.1-3.14.2">
              <dt id="section-4.1-3.14.2.1">Deprecated alias names for this type:</dt>
              <dd id="section-4.1-3.14.2.2">N/A<a href="#section-4.1-3.14.2.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-3.14.2.3">Magic number(s):</dt>
              <dd id="section-4.1-3.14.2.4">N/A<a href="#section-4.1-3.14.2.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-3.14.2.5">File extension(s):</dt>
              <dd id="section-4.1-3.14.2.6">N/A<a href="#section-4.1-3.14.2.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-3.14.2.7">Macintosh file type code(s):</dt>
              <dd id="section-4.1-3.14.2.8">N/A<a href="#section-4.1-3.14.2.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-3.15">Person &amp; email address to contact for further information:</dt>
          <dd id="section-4.1-3.16">
            <p id="section-4.1-3.16.1"><br><span class="contact-name">Victor Demjanenko, Ph.D.</span>
          &lt;victor.demjanenko@vocal.com&gt;<a href="#section-4.1-3.16.1" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-3.17">Intended usage:</dt>
          <dd id="section-4.1-3.18">COMMON<a href="#section-4.1-3.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-3.19">Restrictions on usage:</dt>
          <dd id="section-4.1-3.20"> The media subtype depends on RTP
      framing and hence is only defined for transfer via RTP <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>.  Transport within other framing protocols is not
      defined at this time.<a href="#section-4.1-3.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-3.21">Author:</dt>
          <dd id="section-4.1-3.22">
            <p id="section-4.1-3.22.1"><span class="contact-name">Victor Demjanenko, Ph.D.</span><a href="#section-4.1-3.22.1" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-3.23">Change controller:</dt>
          <dd id="section-4.1-3.24"> IETF; contact &lt;avt@ietf.org&gt;<a href="#section-4.1-3.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-3.25">Provisional registration? (standards tree only):</dt>
          <dd id="section-4.1-3.26"> No<a href="#section-4.1-3.26" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sect-4.2">
<section id="section-4.2">
        <h3 id="name-mapping-to-sdp">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-mapping-to-sdp" class="section-name selfRef">Mapping to SDP</a>
        </h3>
<p id="section-4.2-1">
   The mapping of the above-defined payload format media subtype and its
   parameters <span class="bcp14">SHALL</span> be done according to <span><a href="https://www.rfc-editor.org/rfc/rfc4855#section-3" class="relref">Section 3</a> of [<a href="#RFC4855" class="xref">RFC4855</a>]</span>.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">
   The information carried in the media type specification has a
   specific mapping to fields in the Session Description Protocol (SDP)
   <span>[<a href="#RFC4566" class="xref">RFC4566</a>]</span>, which is commonly used to describe RTP sessions.  When SDP
   is used to specify sessions employing the TSVCIS codec, the mapping
   is as follows:<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.2-3.1">The media type ("audio") goes in SDP "m=" as the media name.<a href="#section-4.2-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-3.2">The media subtype (payload format name) goes in SDP "a=rtpmap" as
      the encoding name.<a href="#section-4.2-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-3.3">The parameter "bitrate" goes in the SDP "a=fmtp" attribute by
      copying it as a "bitrate=&lt;value&gt;" string.<a href="#section-4.2-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-3.4">The parameter "tcmax" goes in the SDP "a=fmtp" attribute by
      copying it as a "tcmax=&lt;value&gt;" string.<a href="#section-4.2-3.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-3.5">The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
      "a=maxptime" attributes, respectively.<a href="#section-4.2-3.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.2-4">
   When conveying information via SDP, the encoding name <span class="bcp14">SHALL</span> be
   "TSVCIS" (the same as the media subtype).<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<p id="section-4.2-5">
   An example of the media representation in SDP for describing TSVCIS
   might be:<a href="#section-4.2-5" class="pilcrow">¶</a></p>
<div id="section-4.2-6">
<pre class="sourcecode lang-sdp">
   m=audio 49120 RTP/AVP 96
   a=rtpmap:96 TSVCIS/8000
</pre><a href="#section-4.2-6" class="pilcrow">¶</a>
</div>
<p id="section-4.2-7">
   The optional media type parameter "bitrate", when present, <span class="bcp14">MUST</span> 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:<a href="#section-4.2-7" class="pilcrow">¶</a></p>
<div id="section-4.2-8">
<pre class="sourcecode lang-sdp">
   m=audio 49120 RTP/AVP 96
   a=rtpmap:96 TSVCIS/8000
   a=fmtp:96 bitrate=2400,600,1200
</pre><a href="#section-4.2-8" class="pilcrow">¶</a>
</div>
<p id="section-4.2-9">
   The optional media type parameter "tcmax", when present, <span class="bcp14">MUST</span> 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:<a href="#section-4.2-9" class="pilcrow">¶</a></p>
<div id="section-4.2-10">
<pre class="sourcecode lang-sdp">
   m=audio 49120 RTP/AVP 96
   a=rtpmap:96 TSVCIS/8000
   a=fmtp:96 tcmax=101
</pre><a href="#section-4.2-10" class="pilcrow">¶</a>
</div>
<p id="section-4.2-11">
   The parameter "ptime" cannot be used for the purpose of specifying
   the TSVCIS operating mode due to the fact that, for certain 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 whether the
   packet is carrying one frame of 67.5 ms or three frames of 22.5 ms).<a href="#section-4.2-11" class="pilcrow">¶</a></p>
<p id="section-4.2-12">
   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.<a href="#section-4.2-12" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-4.3">
<section id="section-4.3">
        <h3 id="name-declarative-sdp-considerati">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-declarative-sdp-considerati" class="section-name selfRef">Declarative SDP Considerations</a>
        </h3>
<p id="section-4.3-1">
   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) <span class="bcp14">MAY</span> 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.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<div id="section-4.3-2">
<pre class="sourcecode lang-sdp">
   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
</pre><a href="#section-4.3-2" class="pilcrow">¶</a>
</div>
<p id="section-4.3-3">
   For declarative media, the "tcmax" parameter specifies the maximum
   number of octets of TSVCIS packed parameters used by the sender or the
   sender's communications channel.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-4.4">
<section id="section-4.4">
        <h3 id="name-offer-answer-sdp-considerat">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-offer-answer-sdp-considerat" class="section-name selfRef">Offer/Answer SDP Considerations</a>
        </h3>
<p id="section-4.4-1">
   In the Offer/Answer model <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span>, "bitrate" is a bidirectional
   parameter.  Both sides <span class="bcp14">MUST</span> use a common "bitrate" value or values.
   The offer contains the bitrates supported by the offerer, listed in
   its preferred order.  The answerer <span class="bcp14">MAY</span> agree to any bitrate by
   listing the bitrate first in the answerer response.  Additionally,
   the answerer <span class="bcp14">MAY</span> indicate any secondary bitrate or bitrates that it
   supports.  The initial bitrate used by both parties <span class="bcp14">SHALL</span> be the
   first bitrate specified in the answerer response.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">
   For example, if offerer bitrates are "2400,600" and 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 <span class="bcp14">MAY</span> be used at any time in the future.  Activation of these
   other common bitrates is beyond the scope of this document.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3">
   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.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<p id="section-4.4-4">
   In the Offer/Answer model <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span>, "tcmax" is a bidirectional
   parameter.  Both sides <span class="bcp14">SHOULD</span> use a common "tcmax" value.  The offer
   contains the tcmax supported by the offerer.  The answerer <span class="bcp14">MAY</span> agree
   to any tcmax equal to or less than this value by stating the desired
   tcmax in the answerer response.  The answerer alternatively <span class="bcp14">MAY</span>
   identify its own tcmax and rely on TSVCIS ignoring any augmented data
   it cannot use.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-5">
<section id="section-5">
      <h2 id="name-discontinuous-transmissions">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-discontinuous-transmissions" class="section-name selfRef">Discontinuous Transmissions</a>
      </h2>
<p id="section-5-1">
   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 <span class="bcp14">SHOULD</span> be indicated by the RTP marker bit (M) set to 1.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">If a TSVCIS coder so desires, it may send a MELPe comfort noise frame as
   per Appendix B of <span>[<a href="#SCIP210" class="xref">SCIP210</a>]</span> prior to ceasing transmission. A
   receiver may optionally use comfort noise during its silence periods.  No
   SDP negotiations are required.<a href="#section-5-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-6">
<section id="section-6">
      <h2 id="name-packet-loss-concealment">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-packet-loss-concealment" class="section-name selfRef">Packet Loss Concealment</a>
      </h2>
<p id="section-6-1">
   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 <span>[<a href="#MELPE" class="xref">MELPE</a>]</span>. 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.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">
   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.<a href="#section-6-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-7">
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-7-1">
   IANA has registered TSVCIS as specified in <a href="#sect-4.1" class="xref">Section 4.1</a>.  The media type has been added to the IANA
   registry for "RTP Payload Format Media Types"
   (<span><a href="https://www.iana.org/assignments/rtp-parameters">https://www.iana.org/assignments/rtp-parameters</a></span>).<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-8">
<section id="section-8">
      <h2 id="name-security-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-8-1">
   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span> and in any applicable RTP profile such as
   RTP/AVP <span>[<a href="#RFC3551" class="xref">RFC3551</a>]</span>, RTP/AVPF <span>[<a href="#RFC4585" class="xref">RFC4585</a>]</span>, RTP/SAVP <span>[<a href="#RFC3711" class="xref">RFC3711</a>]</span>, or
   RTP/SAVPF <span>[<a href="#RFC5124" class="xref">RFC5124</a>]</span>.  However, as discussed in <span>[<a href="#RFC7202" class="xref">RFC7202</a>]</span>, 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 <span>[<a href="#RFC7201" class="xref">RFC7201</a>]</span>.  Applications <span class="bcp14">SHOULD</span> use
   one or more appropriate strong security mechanisms.  The rest of this
   section discusses the security-impacting properties of the payload
   format itself.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">
   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.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">
   Please see the security considerations discussed in <span>[<a href="#RFC6562" class="xref">RFC6562</a>]</span>
   regarding Voice Activity Detect (VAD) and its effect on bitrates.<a href="#section-8-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="MELP">[MELP]</dt>
        <dd>
<span class="refAuthor">Department of Defense</span>, <span class="refTitle">"Analog-to-Digital Conversion of Voice by 2,400 Bit/Second Mixed Excitation Linear Prediction (MELP)"</span>, <span class="seriesInfo">Department of Defense Telecommunications Standard MIL-STD-3005</span>, <time datetime="1999-12" class="refDate">December 1999</time>. </dd>
<dd class="break"></dd>
<dt id="MELPE">[MELPE]</dt>
        <dd>
<span class="refAuthor">North Atlantic Treaty Organization (NATO)</span>, <span class="refTitle">"The 600 Bit/S, 1200 Bit/S and 2400 Bit/S NATO Interoperable Narrow Band Voice Coder"</span>, <span class="seriesInfo">STANAG No. 4591</span>, <time datetime="2008-10" class="refDate">October 2008</time>. </dd>
<dd class="break"></dd>
<dt id="NRLVDR">[NRLVDR]</dt>
        <dd>
<span class="refAuthor">Heide, D.</span><span class="refAuthor">, Cohen, A.</span><span class="refAuthor">, Lee, Y.</span><span class="refAuthor">, and T. Moran</span>, <span class="refTitle">"Universal Vocoder Using Variable Data Rate Vocoding"</span>, <span class="seriesInfo">DOI 10.21236/ada588068</span>, <span class="seriesInfo">Naval Research Lab NRL/FR/5555--13-10, 239</span>, <time datetime="2013-06" class="refDate">June 2013</time>, <span>&lt;<a href="https://doi.org/10.21236/ada588068">https://doi.org/10.21236/ada588068</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2736">[RFC2736]</dt>
        <dd>
<span class="refAuthor">Handley, M.</span><span class="refAuthor"> and C. Perkins</span>, <span class="refTitle">"Guidelines for Writers of RTP Payload Format Specifications"</span>, <span class="seriesInfo">BCP 36</span>, <span class="seriesInfo">RFC 2736</span>, <span class="seriesInfo">DOI 10.17487/RFC2736</span>, <time datetime="1999-12" class="refDate">December 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2736">https://www.rfc-editor.org/info/rfc2736</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3264">[RFC3264]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor"> and H. Schulzrinne</span>, <span class="refTitle">"An Offer/Answer Model with Session Description Protocol (SDP)"</span>, <span class="seriesInfo">RFC 3264</span>, <span class="seriesInfo">DOI 10.17487/RFC3264</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3264">https://www.rfc-editor.org/info/rfc3264</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3550">[RFC3550]</dt>
        <dd>
<span class="refAuthor">Schulzrinne, H.</span><span class="refAuthor">, Casner, S.</span><span class="refAuthor">, Frederick, R.</span><span class="refAuthor">, and V. Jacobson</span>, <span class="refTitle">"RTP: A Transport Protocol for Real-Time Applications"</span>, <span class="seriesInfo">STD 64</span>, <span class="seriesInfo">RFC 3550</span>, <span class="seriesInfo">DOI 10.17487/RFC3550</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3550">https://www.rfc-editor.org/info/rfc3550</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3551">[RFC3551]</dt>
        <dd>
<span class="refAuthor">Schulzrinne, H.</span><span class="refAuthor"> and S. Casner</span>, <span class="refTitle">"RTP Profile for Audio and Video Conferences with Minimal Control"</span>, <span class="seriesInfo">STD 65</span>, <span class="seriesInfo">RFC 3551</span>, <span class="seriesInfo">DOI 10.17487/RFC3551</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3551">https://www.rfc-editor.org/info/rfc3551</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3711">[RFC3711]</dt>
        <dd>
<span class="refAuthor">Baugher, M.</span><span class="refAuthor">, McGrew, D.</span><span class="refAuthor">, Naslund, M.</span><span class="refAuthor">, Carrara, E.</span><span class="refAuthor">, and K. Norrman</span>, <span class="refTitle">"The Secure Real-time Transport Protocol (SRTP)"</span>, <span class="seriesInfo">RFC 3711</span>, <span class="seriesInfo">DOI 10.17487/RFC3711</span>, <time datetime="2004-03" class="refDate">March 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3711">https://www.rfc-editor.org/info/rfc3711</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4566">[RFC4566]</dt>
        <dd>
<span class="refAuthor">Handley, M.</span><span class="refAuthor">, Jacobson, V.</span><span class="refAuthor">, and C. Perkins</span>, <span class="refTitle">"SDP: Session Description Protocol"</span>, <span class="seriesInfo">RFC 4566</span>, <span class="seriesInfo">DOI 10.17487/RFC4566</span>, <time datetime="2006-07" class="refDate">July 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4566">https://www.rfc-editor.org/info/rfc4566</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4855">[RFC4855]</dt>
        <dd>
<span class="refAuthor">Casner, S.</span>, <span class="refTitle">"Media Type Registration of RTP Payload Formats"</span>, <span class="seriesInfo">RFC 4855</span>, <span class="seriesInfo">DOI 10.17487/RFC4855</span>, <time datetime="2007-02" class="refDate">February 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4855">https://www.rfc-editor.org/info/rfc4855</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5124">[RFC5124]</dt>
        <dd>
<span class="refAuthor">Ott, J.</span><span class="refAuthor"> and E. Carrara</span>, <span class="refTitle">"Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)"</span>, <span class="seriesInfo">RFC 5124</span>, <span class="seriesInfo">DOI 10.17487/RFC5124</span>, <time datetime="2008-02" class="refDate">February 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5124">https://www.rfc-editor.org/info/rfc5124</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6562">[RFC6562]</dt>
        <dd>
<span class="refAuthor">Perkins, C.</span><span class="refAuthor"> and JM. Valin</span>, <span class="refTitle">"Guidelines for the Use of Variable Bit Rate Audio with Secure RTP"</span>, <span class="seriesInfo">RFC 6562</span>, <span class="seriesInfo">DOI 10.17487/RFC6562</span>, <time datetime="2012-03" class="refDate">March 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6562">https://www.rfc-editor.org/info/rfc6562</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6838">[RFC6838]</dt>
        <dd>
<span class="refAuthor">Freed, N.</span><span class="refAuthor">, Klensin, J.</span><span class="refAuthor">, and T. Hansen</span>, <span class="refTitle">"Media Type Specifications and Registration Procedures"</span>, <span class="seriesInfo">BCP 13</span>, <span class="seriesInfo">RFC 6838</span>, <span class="seriesInfo">DOI 10.17487/RFC6838</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6838">https://www.rfc-editor.org/info/rfc6838</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8083">[RFC8083]</dt>
        <dd>
<span class="refAuthor">Perkins, C.</span><span class="refAuthor"> and V. Singh</span>, <span class="refTitle">"Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions"</span>, <span class="seriesInfo">RFC 8083</span>, <span class="seriesInfo">DOI 10.17487/RFC8083</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8083">https://www.rfc-editor.org/info/rfc8083</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8085">[RFC8085]</dt>
        <dd>
<span class="refAuthor">Eggert, L.</span><span class="refAuthor">, Fairhurst, G.</span><span class="refAuthor">, and G. Shepherd</span>, <span class="refTitle">"UDP Usage Guidelines"</span>, <span class="seriesInfo">BCP 145</span>, <span class="seriesInfo">RFC 8085</span>, <span class="seriesInfo">DOI 10.17487/RFC8085</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8085">https://www.rfc-editor.org/info/rfc8085</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8088">[RFC8088]</dt>
        <dd>
<span class="refAuthor">Westerlund, M.</span>, <span class="refTitle">"How to Write an RTP Payload Format"</span>, <span class="seriesInfo">RFC 8088</span>, <span class="seriesInfo">DOI 10.17487/RFC8088</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8088">https://www.rfc-editor.org/info/rfc8088</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8130">[RFC8130]</dt>
        <dd>
<span class="refAuthor">Demjanenko, V.</span><span class="refAuthor"> and D. Satterlee</span>, <span class="refTitle">"RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec"</span>, <span class="seriesInfo">RFC 8130</span>, <span class="seriesInfo">DOI 10.17487/RFC8130</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8130">https://www.rfc-editor.org/info/rfc8130</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SCIP210">[SCIP210]</dt>
      <dd>
<span class="refAuthor">National Security Agency</span>, <span class="refTitle">"SCIP Signaling Plan"</span>, <span class="refContent">SCIP-210</span>, <time datetime="2013-01" class="refDate">January 2013</time>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC4585">[RFC4585]</dt>
        <dd>
<span class="refAuthor">Ott, J.</span><span class="refAuthor">, Wenger, S.</span><span class="refAuthor">, Sato, N.</span><span class="refAuthor">, Burmeister, C.</span><span class="refAuthor">, and J. Rey</span>, <span class="refTitle">"Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"</span>, <span class="seriesInfo">RFC 4585</span>, <span class="seriesInfo">DOI 10.17487/RFC4585</span>, <time datetime="2006-07" class="refDate">July 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4585">https://www.rfc-editor.org/info/rfc4585</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7201">[RFC7201]</dt>
        <dd>
<span class="refAuthor">Westerlund, M.</span><span class="refAuthor"> and C. Perkins</span>, <span class="refTitle">"Options for Securing RTP Sessions"</span>, <span class="seriesInfo">RFC 7201</span>, <span class="seriesInfo">DOI 10.17487/RFC7201</span>, <time datetime="2014-04" class="refDate">April 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7201">https://www.rfc-editor.org/info/rfc7201</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7202">[RFC7202]</dt>
        <dd>
<span class="refAuthor">Perkins, C.</span><span class="refAuthor"> and M. Westerlund</span>, <span class="refTitle">"Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution"</span>, <span class="seriesInfo">RFC 7202</span>, <span class="seriesInfo">DOI 10.17487/RFC7202</span>, <time datetime="2014-04" class="refDate">April 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7202">https://www.rfc-editor.org/info/rfc7202</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RMCAT">[RMCAT]</dt>
        <dd>
<span class="refAuthor">IETF</span>, <span class="refTitle">"RTP Media Congestion Avoidance Techniques (rmcat) Working Group"</span>, <span>&lt;<a href="https://datatracker.ietf.org/wg/rmcat/about/">https://datatracker.ietf.org/wg/rmcat/about/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="TSVCIS">[TSVCIS]</dt>
      <dd>
<span class="refAuthor">National Security Agency</span>, <span class="refTitle">"Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Version 3.1"</span>, <span class="seriesInfo">NSA 09-01A</span>, <time datetime="2019-03" class="refDate">March 2019</time>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="authors-addresses">
<section id="section-appendix.a">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Victor Demjanenko, Ph.D.</span></div>
<div dir="auto" class="left"><span class="org">VOCAL Technologies, Ltd.</span></div>
<div dir="auto" class="left"><span class="street-address">520 Lee Entrance, Suite 202</span></div>
<div dir="auto" class="left">
<span class="locality">Buffalo</span>, <span class="region">NY</span> <span class="postal-code">14228</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1%20716%20688%204675" class="tel">+1 716 688 4675</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:victor.demjanenko@vocal.com" class="email">victor.demjanenko@vocal.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">John Punaro</span></div>
<div dir="auto" class="left"><span class="org">VOCAL Technologies, Ltd.</span></div>
<div dir="auto" class="left"><span class="street-address">520 Lee Entrance, Suite 202</span></div>
<div dir="auto" class="left">
<span class="locality">Buffalo</span>, <span class="region">NY</span> <span class="postal-code">14228</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1%20716%20688%204675" class="tel">+1 716 688 4675</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:john.punaro@vocal.com" class="email">john.punaro@vocal.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">David Satterlee</span></div>
<div dir="auto" class="left"><span class="org">VOCAL Technologies, Ltd.</span></div>
<div dir="auto" class="left"><span class="street-address">520 Lee Entrance, Suite 202</span></div>
<div dir="auto" class="left">
<span class="locality">Buffalo</span>, <span class="region">NY</span> <span class="postal-code">14228</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1%20716%20688%204675" class="tel">+1 716 688 4675</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:david.satterlee@vocal.com" class="email">david.satterlee@vocal.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>