File: rfc8834.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 (3718 lines) | stat: -rw-r--r-- 236,090 bytes
<!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 8834: Media Transport and Use of RTP in WebRTC</title>
<meta content="Colin Perkins" name="author">
<meta content="Magnus Westerlund" name="author">
<meta content="Jörg Ott" name="author">
<meta content="
       The framework for Web Real-Time Communication (WebRTC) provides support
      for direct interactive rich communication using audio, video, text,
      collaboration, games, etc. between two peers' web browsers. This memo
      describes the media transport aspects of the WebRTC framework. It
      specifies how the Real-time Transport Protocol (RTP) is used in the
      WebRTC context and gives requirements for which RTP features, profiles,
      and extensions need to be supported. 
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="8834" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.5.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8834.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,
dl.compact, .dlCompact {
  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;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8834" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage-26" 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 8834</td>
<td class="center">RTP for WebRTC</td>
<td class="right">January 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Perkins, 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/rfc8834" class="eref">8834</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="2021-01" class="published">January 2021</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">C. Perkins</div>
<div class="org">University of Glasgow</div>
</div>
<div class="author">
      <div class="author-name">M. Westerlund</div>
<div class="org">Ericsson</div>
</div>
<div class="author">
      <div class="author-name">J. Ott</div>
<div class="org">Technical University Munich</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8834</h1>
<h1 id="title">Media Transport and Use of RTP in WebRTC</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">The framework for Web Real-Time Communication (WebRTC) provides support
      for direct interactive rich communication using audio, video, text,
      collaboration, games, etc. between two peers' web browsers. This memo
      describes the media transport aspects of the WebRTC framework. It
      specifies how the Real-time Transport Protocol (RTP) is used in the
      WebRTC context and gives requirements for which RTP features, profiles,
      and extensions need to be supported.<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/rfc8834">https://www.rfc-editor.org/info/rfc8834</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) 2021 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>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-rationale" class="xref">Rationale</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" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</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-webrtc-use-of-rtp-core-prot" class="xref">WebRTC Use of RTP: Core Protocols</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" 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-rtp-and-rtcp" class="xref">RTP and RTCP</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" 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-choice-of-the-rtp-profile" class="xref">Choice of the RTP Profile</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" 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-choice-of-rtp-payload-forma" class="xref">Choice of RTP Payload Formats</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" 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-use-of-rtp-sessions" class="xref">Use of RTP Sessions</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-rtp-and-rtcp-multiplexing" class="xref">RTP and RTCP Multiplexing</a><a href="#section-toc.1-1.4.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.4.2.6">
                <p id="section-toc.1-1.4.2.6.1"><a href="#section-4.6" class="xref">4.6</a>.  <a href="#name-reduced-size-rtcp" class="xref">Reduced Size RTCP</a><a href="#section-toc.1-1.4.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.4.2.7">
                <p id="section-toc.1-1.4.2.7.1"><a href="#section-4.7" class="xref">4.7</a>.  <a href="#name-symmetric-rtp-rtcp" class="xref">Symmetric RTP/RTCP</a><a href="#section-toc.1-1.4.2.7.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.4.2.8">
                <p id="section-toc.1-1.4.2.8.1"><a href="#section-4.8" class="xref">4.8</a>.  <a href="#name-choice-of-rtp-synchronizati" class="xref">Choice of RTP Synchronization Source (SSRC)</a><a href="#section-toc.1-1.4.2.8.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.4.2.9">
                <p id="section-toc.1-1.4.2.9.1"><a href="#section-4.9" class="xref">4.9</a>.  <a href="#name-generation-of-the-rtcp-cano" class="xref">Generation of the RTCP Canonical Name (CNAME)</a><a href="#section-toc.1-1.4.2.9.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.4.2.10">
                <p id="section-toc.1-1.4.2.10.1"><a href="#section-4.10" class="xref">4.10</a>. <a href="#name-handling-of-leap-seconds" class="xref">Handling of Leap Seconds</a><a href="#section-toc.1-1.4.2.10.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-webrtc-use-of-rtp-extension" class="xref">WebRTC Use of RTP: Extensions</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-conferencing-extensions-and" class="xref">Conferencing Extensions and Topologies</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.5.2.1.2.1">
                    <p id="section-toc.1-1.5.2.1.2.1.1"><a href="#section-5.1.1" class="xref">5.1.1</a>.  <a href="#name-full-intra-request-fir" class="xref">Full Intra Request (FIR)</a><a href="#section-toc.1-1.5.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.5.2.1.2.2">
                    <p id="section-toc.1-1.5.2.1.2.2.1"><a href="#section-5.1.2" class="xref">5.1.2</a>.  <a href="#name-picture-loss-indication-pli" class="xref">Picture Loss Indication (PLI)</a><a href="#section-toc.1-1.5.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.5.2.1.2.3">
                    <p id="section-toc.1-1.5.2.1.2.3.1"><a href="#section-5.1.3" class="xref">5.1.3</a>.  <a href="#name-slice-loss-indication-sli" class="xref">Slice Loss Indication (SLI)</a><a href="#section-toc.1-1.5.2.1.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.5.2.1.2.4">
                    <p id="section-toc.1-1.5.2.1.2.4.1"><a href="#section-5.1.4" class="xref">5.1.4</a>.  <a href="#name-reference-picture-selection" class="xref">Reference Picture Selection Indication (RPSI)</a><a href="#section-toc.1-1.5.2.1.2.4.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.5.2.1.2.5">
                    <p id="section-toc.1-1.5.2.1.2.5.1"><a href="#section-5.1.5" class="xref">5.1.5</a>.  <a href="#name-temporal-spatial-trade-off-" class="xref">Temporal-Spatial Trade-Off Request (TSTR)</a><a href="#section-toc.1-1.5.2.1.2.5.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.5.2.1.2.6">
                    <p id="section-toc.1-1.5.2.1.2.6.1"><a href="#section-5.1.6" class="xref">5.1.6</a>.  <a href="#name-temporary-maximum-media-str" class="xref">Temporary Maximum Media Stream Bit Rate Request (TMMBR)</a><a href="#section-toc.1-1.5.2.1.2.6.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-header-extensions" class="xref">Header Extensions</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.5.2.2.2.1">
                    <p id="section-toc.1-1.5.2.2.2.1.1"><a href="#section-5.2.1" class="xref">5.2.1</a>.  <a href="#name-rapid-synchronization" class="xref">Rapid Synchronization</a><a href="#section-toc.1-1.5.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.5.2.2.2.2">
                    <p id="section-toc.1-1.5.2.2.2.2.1"><a href="#section-5.2.2" class="xref">5.2.2</a>.  <a href="#name-client-to-mixer-audio-level" class="xref">Client-to-Mixer Audio Level</a><a href="#section-toc.1-1.5.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.5.2.2.2.3">
                    <p id="section-toc.1-1.5.2.2.2.3.1"><a href="#section-5.2.3" class="xref">5.2.3</a>.  <a href="#name-mixer-to-client-audio-level" class="xref">Mixer-to-Client Audio Level</a><a href="#section-toc.1-1.5.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.5.2.2.2.4">
                    <p id="section-toc.1-1.5.2.2.2.4.1"><a href="#section-5.2.4" class="xref">5.2.4</a>.  <a href="#name-media-stream-identification" class="xref">Media Stream Identification</a><a href="#section-toc.1-1.5.2.2.2.4.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.5.2.2.2.5">
                    <p id="section-toc.1-1.5.2.2.2.5.1"><a href="#section-5.2.5" class="xref">5.2.5</a>.  <a href="#name-coordination-of-video-orien" class="xref">Coordination of Video Orientation</a><a href="#section-toc.1-1.5.2.2.2.5.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</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-webrtc-use-of-rtp-improving" class="xref">WebRTC Use of RTP: Improving Transport Robustness</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-negative-acknowledgements-a" class="xref">Negative Acknowledgements and RTP Retransmission</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-forward-error-correction-fe" class="xref">Forward Error Correction (FEC)</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</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-webrtc-use-of-rtp-rate-cont" class="xref">WebRTC Use of RTP: Rate Control and Media Adaptation</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-boundary-conditions-and-cir" class="xref">Boundary Conditions and Circuit Breakers</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-congestion-control-interope" class="xref">Congestion Control Interoperability and Legacy Systems</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</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-webrtc-use-of-rtp-performan" class="xref">WebRTC Use of RTP: Performance Monitoring</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-webrtc-use-of-rtp-future-ex" class="xref">WebRTC Use of RTP: Future Extensions</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-signaling-considerations" class="xref">Signaling Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-webrtc-api-considerations" class="xref">WebRTC API Considerations</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-rtp-implementation-consider" class="xref">RTP Implementation Considerations</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="xref">12.1</a>.  <a href="#name-configuration-and-use-of-rt" class="xref">Configuration and Use of RTP Sessions</a><a href="#section-toc.1-1.12.2.1.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.12.2.1.2.1">
                    <p id="section-toc.1-1.12.2.1.2.1.1"><a href="#section-12.1.1" class="xref">12.1.1</a>.  <a href="#name-use-of-multiple-media-sourc" class="xref">Use of Multiple Media Sources within an RTP Session</a><a href="#section-toc.1-1.12.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.1.2.2">
                    <p id="section-toc.1-1.12.2.1.2.2.1"><a href="#section-12.1.2" class="xref">12.1.2</a>.  <a href="#name-use-of-multiple-rtp-session" class="xref">Use of Multiple RTP Sessions</a><a href="#section-toc.1-1.12.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.1.2.3">
                    <p id="section-toc.1-1.12.2.1.2.3.1"><a href="#section-12.1.3" class="xref">12.1.3</a>.  <a href="#name-differentiated-treatment-of" class="xref">Differentiated Treatment of RTP Streams</a><a href="#section-toc.1-1.12.2.1.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.2">
                <p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="xref">12.2</a>.  <a href="#name-media-source-rtp-streams-an" class="xref">Media Source, RTP Streams, and Participant Identification</a><a href="#section-toc.1-1.12.2.2.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.12.2.2.2.1">
                    <p id="section-toc.1-1.12.2.2.2.1.1"><a href="#section-12.2.1" class="xref">12.2.1</a>.  <a href="#name-media-source-identification" class="xref">Media Source Identification</a><a href="#section-toc.1-1.12.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.2.2.2">
                    <p id="section-toc.1-1.12.2.2.2.2.1"><a href="#section-12.2.2" class="xref">12.2.2</a>.  <a href="#name-ssrc-collision-detection" class="xref">SSRC Collision Detection</a><a href="#section-toc.1-1.12.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.12.2.2.2.3">
                    <p id="section-toc.1-1.12.2.2.2.3.1"><a href="#section-12.2.3" class="xref">12.2.3</a>.  <a href="#name-media-synchronization-conte" class="xref">Media Synchronization Context</a><a href="#section-toc.1-1.12.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-13" class="xref">13</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-14" class="xref">14</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-15" class="xref">15</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.15.2.1">
                <p id="section-toc.1-1.15.2.1.1"><a href="#section-15.1" class="xref">15.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.15.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.15.2.2">
                <p id="section-toc.1-1.15.2.2.1"><a href="#section-15.2" class="xref">15.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.15.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.16.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.17">
            <p id="section-toc.1-1.17.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.17.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<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">The <span><a href="#RFC3550" class="xref">Real-time Transport Protocol (RTP)</a> [<a href="#RFC3550" class="xref">RFC3550</a>]</span>
      provides a framework for delivery of audio and video teleconferencing
      data and other real-time media applications. Previous work has defined
      the RTP protocol, along with numerous profiles, payload formats, and
      other extensions. When combined with appropriate signaling, these form
      the basis for many teleconferencing systems.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">The Web Real-Time Communication (WebRTC) framework provides the
      protocol building blocks to support direct, interactive, real-time
      communication using audio, video, collaboration, games, etc. between
      two peers' web browsers. This memo describes how the RTP framework is to
      be used in the WebRTC context. It proposes a baseline set of RTP
      features that are to be implemented by all WebRTC endpoints, along with
      suggested extensions for enhanced functionality.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">This memo specifies a protocol intended for use within the WebRTC
      framework but is not restricted to that context. An overview of the
      WebRTC framework is given in <span>[<a href="#RFC8825" class="xref">RFC8825</a>]</span>.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">The structure of this memo is as follows. <a href="#sec-rationale" class="xref">Section 2</a> outlines our rationale for preparing this
      memo and choosing these RTP features. <a href="#sec-terminology" class="xref">Section 3</a> defines terminology. Requirements for
      core RTP protocols are described in <a href="#sec-rtp-core" class="xref">Section 4</a>,
      and suggested RTP extensions are described in <a href="#sec-rtp-extn" class="xref">Section 5</a>. <a href="#sec-rtp-robust" class="xref">Section 6</a>
      outlines mechanisms that can increase robustness to network problems,
      while <a href="#sec-rate-control" class="xref">Section 7</a> describes
      congestion control and rate adaptation mechanisms. The discussion of
      mandated RTP
      mechanisms concludes in <a href="#sec-perf" class="xref">Section 8</a> with a review of
      performance monitoring and network management tools. <a href="#sec-extn" class="xref">Section 9</a> gives some guidelines for future incorporation
      of other RTP and RTP Control Protocol (RTCP) extensions into this
      framework. <a href="#sec-signalling" class="xref">Section 10</a> describes requirements
      placed on the signaling channel. <a href="#sec-webrtc-api" class="xref">Section 11</a>
      discusses the relationship between features of the RTP framework and the
      WebRTC application programming interface (API), and <a href="#sec-rtp-func" class="xref">Section 12</a> discusses RTP implementation
      considerations. The memo concludes with <span><a href="#sec-security" class="xref">security considerations</a> (<a href="#sec-security" class="xref">Section 13</a>)</span> and <span><a href="#sec-iana" class="xref">IANA considerations</a> (<a href="#sec-iana" class="xref">Section 14</a>)</span>.<a href="#section-1-4" class="pilcrow">¶</a></p>
</section>
<div id="sec-rationale">
<section id="section-2">
      <h2 id="name-rationale">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-rationale" class="section-name selfRef">Rationale</a>
      </h2>
<p id="section-2-1">The RTP framework comprises the RTP data transfer protocol, the RTP
      control protocol, and numerous RTP payload formats, profiles, and
      extensions. This range of add-ons has allowed RTP to meet various needs
      that were not envisaged by the original protocol designers and support
      many new media encodings, but it raises the question of what
      extensions are to be supported by new implementations. The development
      of the WebRTC framework provides an opportunity to review the available
      RTP features and extensions and define a common baseline RTP feature
      set for all WebRTC endpoints. This builds on the past 20 years of RTP
      development to mandate the use of extensions that have shown widespread
      utility, while still remaining compatible with the wide installed base
      of RTP implementations where possible.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">RTP and RTCP extensions that are not discussed in this document can
      be implemented by WebRTC endpoints if they are beneficial for new use
      cases. However, they are not necessary to address the WebRTC use cases
      and requirements identified in <span>[<a href="#RFC7478" class="xref">RFC7478</a>]</span>.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">While the baseline set of RTP features and extensions defined in this
      memo is targeted at the requirements of the WebRTC framework, it is
      expected to be broadly useful for other conferencing-related uses of
      RTP. In particular, it is likely that this set of RTP features and
      extensions will be appropriate for other desktop or mobile
      video-conferencing systems, or for room-based high-quality telepresence
      applications.<a href="#section-2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-terminology">
<section id="section-3">
      <h2 id="name-terminology">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-3-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.
    Lower- or mixed-case uses of
      these key words are not to be interpreted as carrying special
      significance in this memo.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">We define the following additional terms:<a href="#section-3-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3-3">
        <dt id="section-3-3.1">WebRTC MediaStream:</dt>
        <dd style="margin-left: 1.5em" id="section-3-3.2">The MediaStream concept defined by
          the W3C in the <span><a href="#W3C.WD-mediacapture-streams" class="xref">WebRTC API</a> [<a href="#W3C.WD-mediacapture-streams" class="xref">W3C.WD-mediacapture-streams</a>]</span>. A
          MediaStream consists of zero or more MediaStreamTracks.<a href="#section-3-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-3.3">MediaStreamTrack:</dt>
        <dd style="margin-left: 1.5em" id="section-3-3.4">Part of the MediaStream concept
          defined by the W3C in the <span><a href="#W3C.WD-mediacapture-streams" class="xref">WebRTC API</a> [<a href="#W3C.WD-mediacapture-streams" class="xref">W3C.WD-mediacapture-streams</a>]</span>. A
          MediaStreamTrack is an individual stream of media from any type of
          media source such as a microphone or a camera, but conceptual
          sources such as an audio mix or a video composition are also possible.<a href="#section-3-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-3.5">Transport-layer flow:</dt>
        <dd style="margin-left: 1.5em" id="section-3-3.6">A unidirectional flow of
          transport packets that are identified by a particular 5-tuple
          of source IP address, source port, destination IP address,
          destination port, and transport protocol.<a href="#section-3-3.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-3.7">Bidirectional transport-layer flow:</dt>
        <dd style="margin-left: 1.5em" id="section-3-3.8">A bidirectional
          transport-layer flow is a transport-layer flow that is symmetric.
          That is, the transport-layer flow in the reverse direction has a
          5-tuple where the source and destination address and ports are
          swapped compared to the forward path transport-layer flow, and the
          transport protocol is the same.<a href="#section-3-3.8" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-3-4">This document uses the terminology from <span>[<a href="#RFC7656" class="xref">RFC7656</a>]</span> and <span>[<a href="#RFC8825" class="xref">RFC8825</a>]</span>. Other terms are used
      according to their definitions from the <span><a href="#RFC3550" class="xref">RTP
      specification</a> [<a href="#RFC3550" class="xref">RFC3550</a>]</span>. In particular, note the following frequently used
      terms: RTP stream, RTP session, and endpoint.<a href="#section-3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-rtp-core">
<section id="section-4">
      <h2 id="name-webrtc-use-of-rtp-core-prot">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-webrtc-use-of-rtp-core-prot" class="section-name selfRef">WebRTC Use of RTP: Core Protocols</a>
      </h2>
<p id="section-4-1">The following sections describe the core features of RTP and RTCP
      that need to be implemented, along with the mandated RTP profiles. Also
      described are the core extensions providing essential features that all
      WebRTC endpoints need to implement to function effectively on today's
      networks.<a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="sec-rtp-rtcp">
<section id="section-4.1">
        <h3 id="name-rtp-and-rtcp">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-rtp-and-rtcp" class="section-name selfRef">RTP and RTCP</a>
        </h3>
<p id="section-4.1-1">The <span><a href="#RFC3550" class="xref">Real-time Transport Protocol (RTP)</a> [<a href="#RFC3550" class="xref">RFC3550</a>]</span> is <span class="bcp14">REQUIRED</span> to be implemented as the media transport protocol
        for WebRTC. RTP itself comprises two parts: the RTP data transfer
        protocol and the RTP Control Protocol (RTCP). RTCP is a fundamental
        and integral part of RTP and <span class="bcp14">MUST</span> be implemented and used in all
        WebRTC endpoints.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">The following RTP and RTCP features are sometimes omitted in
        limited-functionality implementations of RTP, but they are <span class="bcp14">REQUIRED</span> in all
        WebRTC endpoints:<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1-3.1">Support for use of multiple simultaneous synchronization source
            (SSRC) values in a
            single RTP session, including support for RTP endpoints that send
            many SSRC values simultaneously, following <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span> and <span>[<a href="#RFC8108" class="xref">RFC8108</a>]</span>. The RTCP
            optimizations for multi-SSRC sessions defined in <span>[<a href="#RFC8861" class="xref">RFC8861</a>]</span>
            <span class="bcp14">MAY</span> be supported; if supported, the usage <span class="bcp14">MUST</span> be signaled.<a href="#section-4.1-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-3.2">Random choice of SSRC on joining a session; collision detection
            and resolution for SSRC values (see also <a href="#sec-ssrc" class="xref">Section 4.8</a>).<a href="#section-4.1-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-3.3">Support for reception of RTP data packets containing
            contributing source (CSRC)
            lists, as generated by RTP mixers, and RTCP packets relating to
            CSRCs.<a href="#section-4.1-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-3.4">Sending correct synchronization information in the RTCP Sender
            Reports, to allow receivers to implement lip synchronization; see
            <a href="#rapid-sync" class="xref">Section 5.2.1</a> regarding support for the rapid
            RTP synchronization extensions.<a href="#section-4.1-3.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-3.5">Support for multiple synchronization contexts. Participants
            that send multiple simultaneous RTP packet streams <span class="bcp14">SHOULD</span> do so as
            part of a single synchronization context, using a single RTCP
            CNAME for all streams and allowing receivers to play the streams
            out in a synchronized manner. For compatibility with potential
            future versions of this specification, or for interoperability
            with non-WebRTC devices through a gateway, receivers <span class="bcp14">MUST</span> support
            multiple synchronization contexts, indicated by the use of
            multiple RTCP CNAMEs in an RTP session. This specification
            mandates the usage of a single CNAME when sending RTP 
            streams in some circumstances; see <a href="#sec-cname" class="xref">Section 4.9</a>.<a href="#section-4.1-3.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-3.6">Support for sending and receiving RTCP Sender Report (SR), Receiver  Report (RR), Source Description (SDES), and BYE
            packet types. Note that support for other RTCP packet types is
            <span class="bcp14">OPTIONAL</span> unless mandated by other parts of this specification.
            Note that additional RTCP packet types are used by the <span><a href="#sec-profile" class="xref">RTP/SAVPF profile</a> (<a href="#sec-profile" class="xref">Section 4.2</a>)</span> and the other <span><a href="#sec-rtp-extn" class="xref">RTCP extensions</a> (<a href="#sec-rtp-extn" class="xref">Section 5</a>)</span>. WebRTC endpoints
            that implement the Session Description Protocol (SDP) bundle
            negotiation extension will use the
            SDP Grouping Framework "mid" attribute to identify media streams.
            Such endpoints <span class="bcp14">MUST</span> implement the RTCP SDES media
            identification (MID) item described in
            <span>[<a href="#RFC8843" class="xref">RFC8843</a>]</span>.<a href="#section-4.1-3.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-3.7">Support for multiple endpoints in a single RTP session, and for
            scaling the RTCP transmission interval according to the number of
            participants in the session; support for randomized RTCP
            transmission intervals to avoid synchronization of RTCP reports;
            support for RTCP timer reconsideration (<span><a href="https://www.rfc-editor.org/rfc/rfc3550#section-6.3.6" class="relref">Section 6.3.6</a> of [<a href="#RFC3550" class="xref">RFC3550</a>]</span>) and
            reverse reconsideration (<span><a href="https://www.rfc-editor.org/rfc/rfc3550#section-6.3.4" class="relref">Section 6.3.4</a> of [<a href="#RFC3550" class="xref">RFC3550</a>]</span>).<a href="#section-4.1-3.7" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-3.8">Support for configuring the RTCP bandwidth as a fraction of the
            media bandwidth, and for configuring the fraction of the RTCP
            bandwidth allocated to senders -- e.g., using the SDP "b=" line
            <span>[<a href="#RFC4566" class="xref">RFC4566</a>]</span> <span>[<a href="#RFC3556" class="xref">RFC3556</a>]</span>.<a href="#section-4.1-3.8" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-3.9">Support for the reduced minimum RTCP reporting interval
            described in <span><a href="https://www.rfc-editor.org/rfc/rfc3550#section-6.2" class="relref">Section 6.2</a> of [<a href="#RFC3550" class="xref">RFC3550</a>]</span>. When
            using the reduced minimum RTCP reporting interval, the fixed
            (nonreduced) minimum interval <span class="bcp14">MUST</span> be used when calculating the
            participant timeout interval (see Sections <a href="https://www.rfc-editor.org/rfc/rfc3550#section-6.2" class="relref">6.2</a> and <a href="https://www.rfc-editor.org/rfc/rfc3550#section-6.3.5" class="relref">6.3.5</a> of <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>). The delay before sending the
            initial 
            compound RTCP packet can be set to zero (see <span><a href="https://www.rfc-editor.org/rfc/rfc3550#section-6.2" class="relref">Section 6.2</a> of [<a href="#RFC3550" class="xref">RFC3550</a>]</span> as updated by <span>[<a href="#RFC8108" class="xref">RFC8108</a>]</span>).<a href="#section-4.1-3.9" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-3.10">Support for discontinuous transmission. RTP allows endpoints to
            pause and resume transmission at any time. When resuming, the RTP
            sequence number will increase by one, as usual, while the increase
            in the RTP timestamp value will depend on the duration of the
            pause. Discontinuous transmission is most commonly used with some
            audio payload formats, but it is not audio specific and can be used
            with any RTP payload format.<a href="#section-4.1-3.10" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-3.11">Ignore unknown RTCP packet types and RTP header extensions.
            This is to ensure robust handling of future extensions, middlebox
            behaviors, etc., that can result in receiving RTP header
            extensions or RTCP packet types that were not signaled. If a compound RTCP
            packet that contains a mixture of known and unknown
            RTCP packet types is received, the known packet types need to be processed as
            usual, with only the unknown packet types being discarded.<a href="#section-4.1-3.11" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.1-4">It is known that a significant number of legacy RTP
        implementations, especially those targeted at systems with
        only Voice over IP (VoIP), do
        not support all of the above features and in some cases do not
        support RTCP at all. Implementers are advised to consider the
        requirements for graceful degradation when interoperating with legacy
        implementations.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5">Other implementation considerations are discussed in <a href="#sec-rtp-func" class="xref">Section 12</a>.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-profile">
<section id="section-4.2">
        <h3 id="name-choice-of-the-rtp-profile">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-choice-of-the-rtp-profile" class="section-name selfRef">Choice of the RTP Profile</a>
        </h3>
<p id="section-4.2-1">The complete specification of RTP for a particular application
        domain requires the choice of an RTP profile. For WebRTC use, the
        <span><a href="#RFC5124" class="xref">extended secure RTP profile for
        RTCP-based feedback
        (RTP/SAVPF)</a> [<a href="#RFC5124" class="xref">RFC5124</a>]</span>, as extended by <span>[<a href="#RFC7007" class="xref">RFC7007</a>]</span>, <span class="bcp14">MUST</span> be implemented. The RTP/SAVPF profile
        is the combination of the basic <span><a href="#RFC3551" class="xref">RTP/AVP
        profile</a> [<a href="#RFC3551" class="xref">RFC3551</a>]</span>, the <span><a href="#RFC4585" class="xref">RTP profile for RTCP-based
        feedback (RTP/AVPF)</a> [<a href="#RFC4585" class="xref">RFC4585</a>]</span>, and the <span><a href="#RFC3711" class="xref">secure RTP
        profile (RTP/SAVP)</a> [<a href="#RFC3711" class="xref">RFC3711</a>]</span>.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">The RTCP-based feedback extensions <span>[<a href="#RFC4585" class="xref">RFC4585</a>]</span>
        are needed for the improved RTCP timer model. This allows more
        flexible transmission of RTCP packets in response to events, rather
        than strictly according to bandwidth, and is vital for being able to
        report congestion signals as well as media events. These extensions
        also allow saving RTCP bandwidth, and an endpoint will commonly only
        use the full RTCP bandwidth allocation if there are many events that
        require feedback. The timer rules are also needed to make use of the
        RTP conferencing extensions discussed in <a href="#conf-ext" class="xref">Section 5.1</a>.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<aside id="section-4.2-3">
          <p id="section-4.2-3.1">Note: The enhanced RTCP timer model defined in the RTP/AVPF
            profile is backwards compatible with legacy systems that implement
            only the RTP/AVP or RTP/SAVP profile, given some constraints on
            parameter configuration such as the RTCP bandwidth value and
            "trr‑int". The most important factor for interworking with
            RTP/(S)AVP endpoints via a gateway is to set the "trr-int" parameter
            to a value representing 4 seconds; see <span><a href="https://www.rfc-editor.org/rfc/rfc8108#section-7.1.3" class="relref">Section 7.1.3</a> of [<a href="#RFC8108" class="xref">RFC8108</a>]</span>.<a href="#section-4.2-3.1" class="pilcrow">¶</a></p>
</aside>
<p id="section-4.2-4">The secure RTP (SRTP) profile extensions <span>[<a href="#RFC3711" class="xref">RFC3711</a>]</span> are needed to provide media encryption,
        integrity protection, replay protection, and a limited form of source
        authentication. WebRTC endpoints <span class="bcp14">MUST NOT</span> send packets using the basic
        RTP/AVP profile or the RTP/AVPF profile; they <span class="bcp14">MUST</span> employ the full
        RTP/SAVPF profile to protect all RTP and RTCP packets that are
        generated. In other words, implementations <span class="bcp14">MUST</span> use SRTP and Secure RTCP (SRTCP). The
        RTP/SAVPF profile <span class="bcp14">MUST</span> be configured using the cipher suites,
        DTLS-SRTP protection profiles, keying mechanisms, and other parameters
        described in <span>[<a href="#RFC8827" class="xref">RFC8827</a>]</span>.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec.codecs">
<section id="section-4.3">
        <h3 id="name-choice-of-rtp-payload-forma">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-choice-of-rtp-payload-forma" class="section-name selfRef">Choice of RTP Payload Formats</a>
        </h3>
<p id="section-4.3-1">Mandatory-to-implement audio codecs and RTP payload formats for
        WebRTC endpoints are defined in <span>[<a href="#RFC7874" class="xref">RFC7874</a>]</span>. Mandatory-to-implement video
        codecs and RTP payload formats for WebRTC endpoints are defined in
        <span>[<a href="#RFC7742" class="xref">RFC7742</a>]</span>. WebRTC endpoints <span class="bcp14">MAY</span>
        additionally implement any other codec for which an RTP payload format
        and associated signaling has been defined.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">WebRTC endpoints cannot assume that the other participants in an
        RTP session understand any RTP payload format, no matter how common.
        The mapping between RTP payload type numbers and specific
        configurations of particular RTP payload formats <span class="bcp14">MUST</span> be agreed before
        those payload types/formats can be used. In an SDP context, this can
        be done using the "a=rtpmap:" and "a=fmtp:" attributes associated with
        an "m=" line, along with any other SDP attributes needed to configure
        the RTP payload format.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">Endpoints can signal support for multiple RTP payload formats or
        multiple configurations of a single RTP payload format, as long as
        each unique RTP payload format configuration uses a different RTP
        payload type number. As outlined in <a href="#sec-ssrc" class="xref">Section 4.8</a>,
        the RTP payload type number is sometimes used to associate an RTP
        packet stream with a signaling context. This association is possible
        provided unique RTP payload type numbers are used in each context. For
        example, an RTP packet stream can be associated with an SDP "m=" line
        by comparing the RTP payload type numbers used by the RTP packet
        stream with payload types signaled in the "a=rtpmap:" lines in the
        media sections of the SDP. This leads to the following
        considerations:<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-4.3-4.1">If RTP packet streams are being associated with signaling
            contexts based on the RTP payload type, then the assignment of RTP
            payload type numbers <span class="bcp14">MUST</span> be unique across signaling
            contexts.<a href="#section-4.3-4.1" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-4.3-4.2">If the same RTP payload format configuration is used in
            multiple contexts, then a different RTP payload type number has to
            be assigned in each context to ensure uniqueness.<a href="#section-4.3-4.2" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-4.3-4.3">If the RTP payload type number is not being used to associate
            RTP packet streams with a signaling context, then the same RTP
            payload type number can be used to indicate the exact same RTP
            payload format configuration in multiple contexts.<a href="#section-4.3-4.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.3-5">A single RTP payload type number <span class="bcp14">MUST NOT</span> be assigned to
        different RTP payload formats, or different configurations of the same
        RTP payload format, within a single RTP session (note that the "m="
        lines in an <span><a href="#RFC8843" class="xref">SDP
        BUNDLE group</a> [<a href="#RFC8843" class="xref">RFC8843</a>]</span> form a single RTP session).<a href="#section-4.3-5" class="pilcrow">¶</a></p>
<p id="section-4.3-6">An endpoint that has signaled support for multiple RTP payload
        formats <span class="bcp14">MUST</span> be able to accept data in any of those payload formats at
        any time, unless it has previously signaled limitations on its
        decoding capability. This requirement is constrained if several types
        of media (e.g., audio and video) are sent in the same RTP session. In
        such a case, a source (SSRC) is restricted to switching only between
        the RTP payload formats signaled for the type of media that is being
        sent by that source; see <a href="#sec.session-mux" class="xref">Section 4.4</a>. To
        support rapid rate adaptation by changing codecs, RTP does not require
        advance signaling for changes between RTP payload formats used by a
        single SSRC that were signaled during session setup.<a href="#section-4.3-6" class="pilcrow">¶</a></p>
<p id="section-4.3-7">If performing changes between two RTP payload types that use
        different RTP clock rates, an RTP sender <span class="bcp14">MUST</span> follow the
        recommendations in <span><a href="https://www.rfc-editor.org/rfc/rfc7160#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC7160" class="xref">RFC7160</a>]</span>. RTP
        receivers <span class="bcp14">MUST</span> follow the recommendations in
        <span><a href="https://www.rfc-editor.org/rfc/rfc7160#section-4.3" class="relref">Section 4.3</a> of [<a href="#RFC7160" class="xref">RFC7160</a>]</span>
        in order to support sources that switch
        between clock rates in an RTP session. These recommendations for
        receivers are backwards compatible with the case where senders use
        only a single clock rate.<a href="#section-4.3-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec.session-mux">
<section id="section-4.4">
        <h3 id="name-use-of-rtp-sessions">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-use-of-rtp-sessions" class="section-name selfRef">Use of RTP Sessions</a>
        </h3>
<p id="section-4.4-1">An association amongst a set of endpoints communicating using RTP
        is known as an RTP session <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>. An endpoint
        can be involved in several RTP sessions at the same time. In a
        multimedia session, each type of media has typically been carried in a
        separate RTP session (e.g., using one RTP session for the audio and a
        separate RTP session using a different transport-layer flow for the
        video). WebRTC endpoints are <span class="bcp14">REQUIRED</span> to implement support for
        multimedia sessions in this way, separating each RTP session using
        different transport-layer flows for compatibility with legacy systems
        (this is sometimes called session multiplexing).<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">In modern-day networks, however, with the widespread use of network
        address/port translators (NAT/NAPT) and firewalls, it is desirable to
        reduce the number of transport-layer flows used by RTP applications.
        This can be done by sending all the RTP packet streams in a single RTP
        session, which will comprise a single transport-layer flow. This will
        prevent the use of some quality-of-service mechanisms, as discussed in
        <a href="#sec-differentiated" class="xref">Section 12.1.3</a>. Implementations are
        therefore also <span class="bcp14">REQUIRED</span> to support transport of all RTP packet
        streams, independent of media type, in a single RTP session using a
        single transport-layer flow, according to <span>[<a href="#RFC8860" class="xref">RFC8860</a>]</span> (this is
        sometimes called SSRC multiplexing). If multiple types of media are to
        be used in a single RTP session, all participants in that RTP session
        <span class="bcp14">MUST</span> agree to this usage. In an SDP context, the
        mechanisms described in <span>[<a href="#RFC8843" class="xref">RFC8843</a>]</span> can be used to
        signal such a bundle of RTP packet streams forming a single RTP
        session.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3">Further discussion about the suitability of different RTP session
        structures and multiplexing methods to different scenarios can be
        found in <span>[<a href="#RFC8872" class="xref">RFC8872</a>]</span>.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec.rtcp-mux">
<section id="section-4.5">
        <h3 id="name-rtp-and-rtcp-multiplexing">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-rtp-and-rtcp-multiplexing" class="section-name selfRef">RTP and RTCP Multiplexing</a>
        </h3>
<p id="section-4.5-1">Historically, RTP and RTCP have been run on separate
        transport-layer flows (e.g., two UDP ports for each RTP session, one
        for RTP and one for RTCP). With the increased use of Network
        Address/Port Translation (NAT/NAPT), this has become problematic, since
        maintaining multiple NAT bindings can be costly. It also complicates
        firewall administration, since multiple ports need to be opened to
        allow RTP traffic. To reduce these costs and session setup times,
        implementations are <span class="bcp14">REQUIRED</span> to support multiplexing RTP data packets
        and RTCP control packets on a single transport-layer flow <span>[<a href="#RFC5761" class="xref">RFC5761</a>]</span>. Such RTP and RTCP multiplexing <span class="bcp14">MUST</span> be
        negotiated in the signaling channel before it is used. If SDP is used
        for signaling, this negotiation <span class="bcp14">MUST</span> use the mechanism defined in
        <span>[<a href="#RFC5761" class="xref">RFC5761</a>]</span>. Implementations can also support sending RTP and RTCP on
        separate transport-layer flows, but this is <span class="bcp14">OPTIONAL</span> to implement.  If
        an implementation does not support RTP and RTCP sent on separate
        transport-layer flows, it <span class="bcp14">MUST</span> indicate that using the mechanism
        defined in <span>[<a href="#RFC8858" class="xref">RFC8858</a>]</span>.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<p id="section-4.5-2">Note that the use of RTP and RTCP multiplexed onto a single
        transport-layer flow ensures that there is occasional traffic sent on
        that port, even if there is no active media traffic. This can be
        useful to keep NAT bindings alive <span>[<a href="#RFC6263" class="xref">RFC6263</a>]</span>.<a href="#section-4.5-2" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.6">
        <h3 id="name-reduced-size-rtcp">
<a href="#section-4.6" class="section-number selfRef">4.6. </a><a href="#name-reduced-size-rtcp" class="section-name selfRef">Reduced Size RTCP</a>
        </h3>
<p id="section-4.6-1">RTCP packets are usually sent as compound RTCP packets, and <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span> requires that those compound packets start
        with an SR or RR packet. When using
        frequent RTCP feedback messages under the RTP/AVPF profile <span>[<a href="#RFC4585" class="xref">RFC4585</a>]</span>, these statistics are not needed in every
        packet, and they unnecessarily increase the mean RTCP packet size. This can
        limit the frequency at which RTCP packets can be sent within the RTCP
        bandwidth share.<a href="#section-4.6-1" class="pilcrow">¶</a></p>
<p id="section-4.6-2">To avoid this problem, <span>[<a href="#RFC5506" class="xref">RFC5506</a>]</span> specifies how
        to reduce the mean RTCP message size and allow for more frequent
        feedback. Frequent feedback, in turn, is essential to make real-time
        applications quickly aware of changing network conditions and
        to allow them to adapt their transmission and encoding behavior.
        Implementations <span class="bcp14">MUST</span> support sending and receiving noncompound RTCP
        feedback packets <span>[<a href="#RFC5506" class="xref">RFC5506</a>]</span>. Use of noncompound
        RTCP packets <span class="bcp14">MUST</span> be negotiated using the signaling channel. If SDP
        is used for signaling, this negotiation <span class="bcp14">MUST</span> use the attributes
        defined in <span>[<a href="#RFC5506" class="xref">RFC5506</a>]</span>. For backwards
        compatibility, implementations are also <span class="bcp14">REQUIRED</span> to support the use of
        compound RTCP feedback packets if the remote endpoint does not agree
        to the use of noncompound RTCP in the signaling exchange.<a href="#section-4.6-2" class="pilcrow">¶</a></p>
</section>
<section id="section-4.7">
        <h3 id="name-symmetric-rtp-rtcp">
<a href="#section-4.7" class="section-number selfRef">4.7. </a><a href="#name-symmetric-rtp-rtcp" class="section-name selfRef">Symmetric RTP/RTCP</a>
        </h3>
<p id="section-4.7-1">To ease traversal of NAT and firewall devices, implementations are
        <span class="bcp14">REQUIRED</span> to implement and use <span><a href="#RFC4961" class="xref">symmetric
        RTP</a> [<a href="#RFC4961" class="xref">RFC4961</a>]</span>. The reason for using symmetric RTP is primarily to avoid
        issues with NATs and firewalls by ensuring that the send and receive
        RTP packet streams, as well as RTCP, are actually bidirectional
        transport-layer flows. This will keep alive the NAT and firewall
        pinholes and help indicate consent that the receive direction is a
        transport-layer flow the intended recipient actually wants. In
        addition, it saves resources, specifically ports at the endpoints, but
        also in the network, because the NAT mappings or firewall state is not
        unnecessarily bloated. The amount of per-flow QoS state kept in the
        network is also reduced.<a href="#section-4.7-1" class="pilcrow">¶</a></p>
</section>
<div id="sec-ssrc">
<section id="section-4.8">
        <h3 id="name-choice-of-rtp-synchronizati">
<a href="#section-4.8" class="section-number selfRef">4.8. </a><a href="#name-choice-of-rtp-synchronizati" class="section-name selfRef">Choice of RTP Synchronization Source (SSRC)</a>
        </h3>
<p id="section-4.8-1">Implementations are <span class="bcp14">REQUIRED</span> to support signaled RTP
        synchronization source (SSRC) identifiers. If SDP is used, this <span class="bcp14">MUST</span>
        be done using the "a=ssrc:" SDP attribute defined in Sections <a href="https://www.rfc-editor.org/rfc/rfc5576#section-4.1" class="relref">4.1</a>
        and <a href="https://www.rfc-editor.org/rfc/rfc5576#section-5" class="relref">5</a> of <span>[<a href="#RFC5576" class="xref">RFC5576</a>]</span> and the "previous-ssrc" source attribute defined in <span><a href="https://www.rfc-editor.org/rfc/rfc5576#section-6.2" class="relref">Section 6.2</a> of [<a href="#RFC5576" class="xref">RFC5576</a>]</span>; other per-SSRC attributes defined in <span>[<a href="#RFC5576" class="xref">RFC5576</a>]</span> <span class="bcp14">MAY</span> be supported.<a href="#section-4.8-1" class="pilcrow">¶</a></p>
<p id="section-4.8-2">While support for signaled SSRC identifiers is mandated, their use
        in an RTP session is <span class="bcp14">OPTIONAL</span>. Implementations <span class="bcp14">MUST</span> be prepared to
        accept RTP and RTCP packets using SSRCs that have not been explicitly
        signaled ahead of time. Implementations <span class="bcp14">MUST</span> support random SSRC
        assignment and <span class="bcp14">MUST</span> support SSRC collision detection and resolution,
        according to <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>. When using signaled SSRC
        values, collision detection <span class="bcp14">MUST</span> be performed as described in 
        <span><a href="https://www.rfc-editor.org/rfc/rfc5576#section-5" class="relref">Section 5</a> of [<a href="#RFC5576" class="xref">RFC5576</a>]</span>.<a href="#section-4.8-2" class="pilcrow">¶</a></p>
<p id="section-4.8-3">It is often desirable to associate an RTP packet stream with a
        non-RTP context. For users of the WebRTC API, a mapping between SSRCs
        and MediaStreamTracks is provided per <a href="#sec-webrtc-api" class="xref">Section 11</a>. For gateways or other usages, it is
        possible to associate an RTP packet stream with an "m=" line in a
        session description formatted using SDP. If SSRCs are signaled, this
        is straightforward (in SDP, the "a=ssrc:" line will be at the media
        level, allowing a direct association with an "m=" line). If SSRCs are
        not signaled, the RTP payload type numbers used in an RTP packet
        stream are often sufficient to associate that packet stream with a
        signaling context. For example, if RTP payload type numbers are assigned as
        described in <a href="#sec.codecs" class="xref">Section 4.3</a> of this memo, the RTP
        payload types used by an RTP packet stream can be compared with values
        in SDP "a=rtpmap:" lines, which are at the media level in SDP and so
        map to an "m=" line.<a href="#section-4.8-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-cname">
<section id="section-4.9">
        <h3 id="name-generation-of-the-rtcp-cano">
<a href="#section-4.9" class="section-number selfRef">4.9. </a><a href="#name-generation-of-the-rtcp-cano" class="section-name selfRef">Generation of the RTCP Canonical Name (CNAME)</a>
        </h3>
<p id="section-4.9-1">The RTCP Canonical Name (CNAME) provides a persistent
        transport-level identifier for an RTP endpoint. While the
        SSRC identifier for an RTP endpoint can
        change if a collision is detected or when the RTP application is
        restarted, its RTCP CNAME is meant to stay unchanged for the duration
        of an <span><a href="#W3C.WebRTC" class="xref">RTCPeerConnection</a> [<a href="#W3C.WebRTC" class="xref">W3C.WebRTC</a>]</span>,
        so that RTP endpoints can be uniquely identified and associated with
        their RTP packet streams within a set of related RTP sessions.<a href="#section-4.9-1" class="pilcrow">¶</a></p>
<p id="section-4.9-2">Each RTP endpoint <span class="bcp14">MUST</span> have at least one RTCP CNAME, and that RTCP
        CNAME <span class="bcp14">MUST</span> be unique within the RTCPeerConnection. RTCP CNAMEs
        identify a particular synchronization context -- i.e., all SSRCs
        associated with a single RTCP CNAME share a common reference clock. If
        an endpoint has SSRCs that are associated with several unsynchronized
        reference clocks, and hence different synchronization contexts, it
        will need to use multiple RTCP CNAMEs, one for each synchronization
        context.<a href="#section-4.9-2" class="pilcrow">¶</a></p>
<p id="section-4.9-3">Taking the discussion in <a href="#sec-webrtc-api" class="xref">Section 11</a> into
        account, a WebRTC endpoint <span class="bcp14">MUST NOT</span> use more than one RTCP CNAME in
        the RTP sessions belonging to a single RTCPeerConnection (that is, an
        RTCPeerConnection forms a synchronization context). RTP middleboxes
        <span class="bcp14">MAY</span> generate RTP packet streams associated with more than one RTCP
        CNAME, to allow them to avoid having to resynchronize media from
        multiple different endpoints that are part of a multiparty RTP
        session.<a href="#section-4.9-3" class="pilcrow">¶</a></p>
<p id="section-4.9-4">The <span><a href="#RFC3550" class="xref">RTP specification</a> [<a href="#RFC3550" class="xref">RFC3550</a>]</span> includes
        guidelines for choosing a unique RTP CNAME, but these are not
        sufficient in the presence of NAT devices. In addition, long-term
        persistent identifiers can be problematic from a <span><a href="#sec-security" class="xref">privacy viewpoint</a> (<a href="#sec-security" class="xref">Section 13</a>)</span>. Accordingly, a WebRTC
        endpoint <span class="bcp14">MUST</span> generate a new, unique, short-term persistent RTCP CNAME
        for each RTCPeerConnection, following <span>[<a href="#RFC7022" class="xref">RFC7022</a>]</span>,
        with a single exception; if explicitly requested at creation, an
        RTCPeerConnection <span class="bcp14">MAY</span> use the same CNAME as an existing
        RTCPeerConnection within their common same-origin context.<a href="#section-4.9-4" class="pilcrow">¶</a></p>
<p id="section-4.9-5">A WebRTC endpoint <span class="bcp14">MUST</span> support reception of any CNAME that matches
        the syntax limitations specified by the <span><a href="#RFC3550" class="xref">RTP
        specification</a> [<a href="#RFC3550" class="xref">RFC3550</a>]</span> and cannot assume that any CNAME will be chosen
        according to the form suggested above.<a href="#section-4.9-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-leap-sec">
<section id="section-4.10">
        <h3 id="name-handling-of-leap-seconds">
<a href="#section-4.10" class="section-number selfRef">4.10. </a><a href="#name-handling-of-leap-seconds" class="section-name selfRef">Handling of Leap Seconds</a>
        </h3>
<p id="section-4.10-1">The guidelines given in <span>[<a href="#RFC7164" class="xref">RFC7164</a>]</span> regarding
        handling of leap seconds to limit their
        impact on RTP media play-out and synchronization <span class="bcp14">SHOULD</span> be followed.<a href="#section-4.10-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-rtp-extn">
<section id="section-5">
      <h2 id="name-webrtc-use-of-rtp-extension">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-webrtc-use-of-rtp-extension" class="section-name selfRef">WebRTC Use of RTP: Extensions</a>
      </h2>
<p id="section-5-1">There are a number of RTP extensions that are either needed to obtain
      full functionality, or extremely useful to improve on the baseline
      performance, in the WebRTC context. One set of these extensions is
      related to conferencing, while others are more generic in nature. The
      following subsections describe the various RTP extensions mandated or
      suggested for use within WebRTC.<a href="#section-5-1" class="pilcrow">¶</a></p>
<div id="conf-ext">
<section id="section-5.1">
        <h3 id="name-conferencing-extensions-and">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-conferencing-extensions-and" class="section-name selfRef">Conferencing Extensions and Topologies</a>
        </h3>
<p id="section-5.1-1">RTP is a protocol that inherently supports group communication.
        Groups can be implemented by having each endpoint send its RTP packet
        streams to an RTP middlebox that redistributes the traffic, by using a
        mesh of unicast RTP packet streams between endpoints, or by using an
        IP multicast group to distribute the RTP packet streams. These
        topologies can be implemented in a number of ways as discussed in
        <span>[<a href="#RFC7667" class="xref">RFC7667</a>]</span>.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">While the use of IP multicast groups is popular in IPTV systems,
        the topologies based on RTP middleboxes are dominant in interactive
        video-conferencing environments. Topologies based on a mesh of unicast
        transport-layer flows to create a common RTP session have not seen
        widespread deployment to date. Accordingly, WebRTC endpoints are not
        expected to support topologies based on IP multicast groups or
        mesh-based topologies, such as a point-to-multipoint mesh
        configured as a single RTP session ("Topo-Mesh" in the terminology of
        <span>[<a href="#RFC7667" class="xref">RFC7667</a>]</span>).
        However, a point-to-multipoint mesh constructed using several RTP
        sessions, implemented in WebRTC using independent <span><a href="#W3C.WebRTC" class="xref">RTCPeerConnections</a> [<a href="#W3C.WebRTC" class="xref">W3C.WebRTC</a>]</span>, can be
        expected to be used in WebRTC and needs to be supported.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<p id="section-5.1-3">WebRTC endpoints implemented according to this memo are expected to
        support all the topologies described in <span>[<a href="#RFC7667" class="xref">RFC7667</a>]</span> where the RTP
        endpoints send and receive unicast RTP packet streams to and from some
        peer device, provided that peer can participate in performing
        congestion control on the RTP packet streams. The peer device could be
        another RTP endpoint, or it could be an RTP middlebox that
        redistributes the RTP packet streams to other RTP endpoints. This
        limitation means that some of the RTP middlebox-based topologies are
        not suitable for use in WebRTC. Specifically:<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-4.1">Video-switching Multipoint Control Units (MCUs) (Topo-Video-switch-MCU) <span class="bcp14">SHOULD NOT</span> be
            used, since they make the use of RTCP for congestion control and
            quality-of-service reports problematic (see <span><a href="https://www.rfc-editor.org/rfc/rfc7667#section-3.8" class="relref">Section 3.8</a> of [<a href="#RFC7667" class="xref">RFC7667</a>]</span>).<a href="#section-5.1-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.1-4.2">The Relay-Transport Translator (Topo-PtM-Trn-Translator)
            topology <span class="bcp14">SHOULD NOT</span> be used, because its safe use requires a
            congestion control algorithm or RTP circuit breaker that handles
            point to multipoint, which has not yet been standardized.<a href="#section-5.1-4.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.1-5">The following topology can be used, however it has some issues
        worth noting:<a href="#section-5.1-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-6.1">Content-modifying MCUs with RTCP termination
            (Topo-RTCP-terminating-MCU) <span class="bcp14">MAY</span> be used. Note that in this RTP
            topology, RTP loop detection and identification of active senders
            is the responsibility of the WebRTC application; since the clients
            are isolated from each other at the RTP layer, RTP cannot assist
            with these functions (see <span><a href="https://www.rfc-editor.org/rfc/rfc7667#section-3.9" class="relref">Section 3.9</a> of [<a href="#RFC7667" class="xref">RFC7667</a>]</span>).<a href="#section-5.1-6.1" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.1-7">The RTP extensions described in Sections <a href="#sec-fir" class="xref">5.1.1</a> to <a href="#sec.tmmbr" class="xref">5.1.6</a> are designed to be used with
        centralized conferencing, where an RTP middlebox (e.g., a conference
        bridge) receives a participant's RTP packet streams and distributes
        them to the other participants. These extensions are not necessary for
        interoperability; an RTP endpoint that does not implement these
        extensions will work correctly but might offer poor performance.
        Support for the listed extensions will greatly improve the quality of
        experience; to provide a reasonable baseline quality, some of
        these extensions are mandatory to be supported by WebRTC
        endpoints.<a href="#section-5.1-7" class="pilcrow">¶</a></p>
<p id="section-5.1-8">The RTCP conferencing extensions are defined in <span><a href="#RFC4585" class="xref">"Extended RTP Profile for Real-time
        Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"</a> [<a href="#RFC4585" class="xref">RFC4585</a>]</span>
        and <span><a href="#RFC5104" class="xref">"Codec Control
        Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"</a> [<a href="#RFC5104" class="xref">RFC5104</a>]</span>; they
        are fully usable by the <span><a href="#RFC5124" class="xref">secure variant of this
        profile (RTP/SAVPF)</a> [<a href="#RFC5124" class="xref">RFC5124</a>]</span>.<a href="#section-5.1-8" class="pilcrow">¶</a></p>
<div id="sec-fir">
<section id="section-5.1.1">
          <h4 id="name-full-intra-request-fir">
<a href="#section-5.1.1" class="section-number selfRef">5.1.1. </a><a href="#name-full-intra-request-fir" class="section-name selfRef">Full Intra Request (FIR)</a>
          </h4>
<p id="section-5.1.1-1">The Full Intra Request message is defined in Sections <a href="https://www.rfc-editor.org/rfc/rfc5104#section-3.5.1" class="relref">3.5.1</a> and
          <a href="https://www.rfc-editor.org/rfc/rfc5104#section-4.3.1" class="relref">4.3.1</a> of <span><a href="#RFC5104" class="xref">Codec Control Messages</a> [<a href="#RFC5104" class="xref">RFC5104</a>]</span>.
          It is used to make the mixer request a new Intra picture from a
          participant in the session. This is used when switching between
          sources to ensure that the receivers can decode the video or other
          predictive media encoding with long prediction chains. WebRTC
          endpoints that are sending media <span class="bcp14">MUST</span> understand and react to FIR
          feedback messages they receive, since this greatly improves the user
          experience when using centralized mixer-based conferencing. Support
          for sending FIR messages is <span class="bcp14">OPTIONAL</span>.<a href="#section-5.1.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-5.1.2">
          <h4 id="name-picture-loss-indication-pli">
<a href="#section-5.1.2" class="section-number selfRef">5.1.2. </a><a href="#name-picture-loss-indication-pli" class="section-name selfRef">Picture Loss Indication (PLI)</a>
          </h4>
<p id="section-5.1.2-1">The Picture Loss Indication message is defined in 
          <span><a href="https://www.rfc-editor.org/rfc/rfc4585#section-6.3.1" class="relref">Section 6.3.1</a> of the RTP/AVPF profile [<a href="#RFC4585" class="xref">RFC4585</a>]</span>. It is used by
          a receiver to tell the sending encoder that it lost the decoder
          context and would like to have it repaired somehow. This is
          semantically different from the Full Intra Request above, as there
          could be multiple ways to fulfill the request. WebRTC endpoints that
          are sending media <span class="bcp14">MUST</span> understand and react to PLI feedback messages
          as a loss-tolerance mechanism. Receivers <span class="bcp14">MAY</span> send PLI messages.<a href="#section-5.1.2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-5.1.3">
          <h4 id="name-slice-loss-indication-sli">
<a href="#section-5.1.3" class="section-number selfRef">5.1.3. </a><a href="#name-slice-loss-indication-sli" class="section-name selfRef">Slice Loss Indication (SLI)</a>
          </h4>
<p id="section-5.1.3-1">The Slice Loss Indication message is defined in <span><a href="https://www.rfc-editor.org/rfc/rfc4585#section-6.3.2" class="relref">Section 6.3.2</a> of the RTP/AVPF profile [<a href="#RFC4585" class="xref">RFC4585</a>]</span>. It is used by a
          receiver to tell the encoder that it has detected the loss or
          corruption of one or more consecutive macro blocks and would like
          to have these repaired somehow. It is <span class="bcp14">RECOMMENDED</span> that receivers
          generate SLI feedback messages if slices are lost when using a codec
          that supports the concept of macro blocks. A sender that receives an
          SLI feedback message <span class="bcp14">SHOULD</span> attempt to repair the lost slice(s).<a href="#section-5.1.3-1" class="pilcrow">¶</a></p>
</section>
<section id="section-5.1.4">
          <h4 id="name-reference-picture-selection">
<a href="#section-5.1.4" class="section-number selfRef">5.1.4. </a><a href="#name-reference-picture-selection" class="section-name selfRef">Reference Picture Selection Indication (RPSI)</a>
          </h4>
<p id="section-5.1.4-1">Reference Picture Selection Indication (RPSI) messages are
          defined in <span><a href="https://www.rfc-editor.org/rfc/rfc4585#section-6.3.3" class="relref">Section 6.3.3</a> of the RTP/AVPF
          profile [<a href="#RFC4585" class="xref">RFC4585</a>]</span>. Some video-encoding standards allow the use of
          older reference pictures than the most recent one for predictive
          coding. If such a codec is in use, and if the encoder has learned
          that encoder-decoder synchronization has been lost, then a
          known-as-correct reference picture can be used as a base for future
          coding. The RPSI message allows this to be signaled. Receivers that
          detect that encoder-decoder synchronization has been lost <span class="bcp14">SHOULD</span>
          generate an RPSI feedback message if the codec being used supports
          reference-picture selection. An RTP packet-stream sender that
          receives such an
          RPSI message <span class="bcp14">SHOULD</span> act on that messages to change the reference
          picture, if it is possible to do so within the available bandwidth
          constraints and with the codec being used.<a href="#section-5.1.4-1" class="pilcrow">¶</a></p>
</section>
<section id="section-5.1.5">
          <h4 id="name-temporal-spatial-trade-off-">
<a href="#section-5.1.5" class="section-number selfRef">5.1.5. </a><a href="#name-temporal-spatial-trade-off-" class="section-name selfRef">Temporal-Spatial Trade-Off Request (TSTR)</a>
          </h4>
<p id="section-5.1.5-1">The temporal-spatial trade-off request and notification are
          defined in Sections <a href="https://www.rfc-editor.org/rfc/rfc5104#section-3.5.2" class="relref">3.5.2</a> and <a href="https://www.rfc-editor.org/rfc/rfc5104#section-4.3.2" class="relref">4.3.2</a> of <span>[<a href="#RFC5104" class="xref">RFC5104</a>]</span>. This request can be used to ask the video
          encoder to change the trade-off it makes between temporal and
          spatial resolution -- for example, to prefer high spatial image quality
          but low frame rate. Support for TSTR requests and notifications is
          <span class="bcp14">OPTIONAL</span>.<a href="#section-5.1.5-1" class="pilcrow">¶</a></p>
</section>
<div id="sec.tmmbr">
<section id="section-5.1.6">
          <h4 id="name-temporary-maximum-media-str">
<a href="#section-5.1.6" class="section-number selfRef">5.1.6. </a><a href="#name-temporary-maximum-media-str" class="section-name selfRef">Temporary Maximum Media Stream Bit Rate Request (TMMBR)</a>
          </h4>
<p id="section-5.1.6-1">The Temporary Maximum Media Stream Bit Rate Request (TMMBR) feedback message is defined in Sections <a href="https://www.rfc-editor.org/rfc/rfc5104#section-3.5.4" class="relref">3.5.4</a> and <a href="https://www.rfc-editor.org/rfc/rfc5104#section-4.2.1" class="relref">4.2.1</a>
          of <span><a href="#RFC5104" class="xref">Codec Control Messages</a> [<a href="#RFC5104" class="xref">RFC5104</a>]</span>. This
          request and its corresponding Temporary Maximum Media Stream Bit
          Rate Notification (TMMBN) message <span>[<a href="#RFC5104" class="xref">RFC5104</a>]</span> are used by a media receiver to
          inform the sending party that there is a current limitation on the
          amount of bandwidth available to this receiver. There can be various
          reasons for this: for example, an RTP mixer can use this message to
          limit the media rate of the sender being forwarded by the mixer
          (without doing media transcoding) to fit the bottlenecks existing
          towards the other session participants. WebRTC endpoints that are
          sending media are <span class="bcp14">REQUIRED</span> to implement support for TMMBR messages
          and <span class="bcp14">MUST</span> follow bandwidth limitations set by a TMMBR message
          received for their SSRC. The sending of TMMBR messages is
          <span class="bcp14">OPTIONAL</span>.<a href="#section-5.1.6-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-5.2">
        <h3 id="name-header-extensions">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-header-extensions" class="section-name selfRef">Header Extensions</a>
        </h3>
<p id="section-5.2-1">The <span><a href="#RFC3550" class="xref">RTP specification</a> [<a href="#RFC3550" class="xref">RFC3550</a>]</span> provides the
        capability to include RTP header extensions containing in-band data,
        but the format and semantics of the extensions are poorly specified.
        The use of header extensions is <span class="bcp14">OPTIONAL</span> in WebRTC, but if they are
        used, they <span class="bcp14">MUST</span> be formatted and signaled following the general
        mechanism for RTP header extensions defined in <span>[<a href="#RFC8285" class="xref">RFC8285</a>]</span>, since this gives well-defined semantics to
        RTP header extensions.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">As noted in <span>[<a href="#RFC8285" class="xref">RFC8285</a>]</span>, the requirement from
        the RTP specification that header extensions are "designed so that the
        header extension may be ignored" <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>
        stands. To be specific, header extensions <span class="bcp14">MUST</span> only be used for data
        that can safely be ignored by the recipient without affecting
        interoperability and <span class="bcp14">MUST NOT</span> be used when the presence of the
        extension has changed the form or nature of the rest of the packet in
        a way that is not compatible with the way the stream is signaled
        (e.g., as defined by the payload type). Valid examples of RTP header
        extensions might include metadata that is additional to the usual RTP
        information but that can safely be ignored without compromising
        interoperability.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<div id="rapid-sync">
<section id="section-5.2.1">
          <h4 id="name-rapid-synchronization">
<a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-rapid-synchronization" class="section-name selfRef">Rapid Synchronization</a>
          </h4>
<p id="section-5.2.1-1">Many RTP sessions require synchronization between audio, video,
          and other content. This synchronization is performed by receivers,
          using information contained in RTCP SR packets, as described in the
          <span><a href="#RFC3550" class="xref">RTP specification</a> [<a href="#RFC3550" class="xref">RFC3550</a>]</span>. This basic
          mechanism can be slow, however, so it is <span class="bcp14">RECOMMENDED</span> that the rapid
          RTP synchronization extensions described in <span>[<a href="#RFC6051" class="xref">RFC6051</a>]</span> be implemented in addition to RTCP SR-based
          synchronization.<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
<p id="section-5.2.1-2">This header extension uses the 
          generic header extension framework described in <span>[<a href="#RFC8285" class="xref">RFC8285</a>]</span> and so needs to be negotiated
          before it can be used.<a href="#section-5.2.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-client-to-mixer">
<section id="section-5.2.2">
          <h4 id="name-client-to-mixer-audio-level">
<a href="#section-5.2.2" class="section-number selfRef">5.2.2. </a><a href="#name-client-to-mixer-audio-level" class="section-name selfRef">Client-to-Mixer Audio Level</a>
          </h4>
<p id="section-5.2.2-1">The <span><a href="#RFC6464" class="xref">client-to-mixer audio level
          extension</a> [<a href="#RFC6464" class="xref">RFC6464</a>]</span> is an RTP header extension used by an endpoint to
          inform a mixer about the level of audio activity in the packet to
          which the header is attached. This enables an RTP middlebox to make
          mixing or selection decisions without decoding or detailed
          inspection of the payload, reducing the complexity in some types of
          mixers. It can also save decoding resources in receivers, which can
          choose to decode only the most relevant RTP packet streams based on
          audio activity levels.<a href="#section-5.2.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2.2-2">The <span><a href="#RFC6464" class="xref">client-to-mixer audio level header
          extension</a> [<a href="#RFC6464" class="xref">RFC6464</a>]</span> <span class="bcp14">MUST</span> be implemented. It is <span class="bcp14">REQUIRED</span> that
          implementations be capable of encrypting the header extension
          according to <span>[<a href="#RFC6904" class="xref">RFC6904</a>]</span>, since the information
          contained in these header extensions can be considered sensitive.
          The use of this encryption is <span class="bcp14">RECOMMENDED</span>; however, usage of the
          encryption can be explicitly disabled through API or signaling.<a href="#section-5.2.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2.2-3">This header extension uses the 
          generic header extension framework described in <span>[<a href="#RFC8285" class="xref">RFC8285</a>]</span> and so needs to be negotiated
          before it can be used.<a href="#section-5.2.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-mixer-to-client">
<section id="section-5.2.3">
          <h4 id="name-mixer-to-client-audio-level">
<a href="#section-5.2.3" class="section-number selfRef">5.2.3. </a><a href="#name-mixer-to-client-audio-level" class="section-name selfRef">Mixer-to-Client Audio Level</a>
          </h4>
<p id="section-5.2.3-1">The <span><a href="#RFC6465" class="xref">mixer-to-client audio level header
          extension</a> [<a href="#RFC6465" class="xref">RFC6465</a>]</span> provides an endpoint with the audio level of the
          different sources mixed into a common source stream by an RTP mixer.
          This enables a user interface to indicate the relative activity
          level of each session participant, rather than just being included
          or not based on the CSRC field. This is a pure optimization of non-critical functions and is hence <span class="bcp14">OPTIONAL</span> to implement. If this
          header extension is implemented, it is <span class="bcp14">REQUIRED</span> that implementations
          be capable of encrypting the header extension according to <span>[<a href="#RFC6904" class="xref">RFC6904</a>]</span>, since the information contained in these
          header extensions can be considered sensitive. It is further
          <span class="bcp14">RECOMMENDED</span> that this encryption be used, unless the encryption has
          been explicitly disabled through API or signaling.<a href="#section-5.2.3-1" class="pilcrow">¶</a></p>
<p id="section-5.2.3-2">This header extension uses the 
          generic header extension framework described in <span>[<a href="#RFC8285" class="xref">RFC8285</a>]</span> and so needs to be negotiated
          before it can be used.<a href="#section-5.2.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-mid">
<section id="section-5.2.4">
          <h4 id="name-media-stream-identification">
<a href="#section-5.2.4" class="section-number selfRef">5.2.4. </a><a href="#name-media-stream-identification" class="section-name selfRef">Media Stream Identification</a>
          </h4>
<p id="section-5.2.4-1">WebRTC endpoints that implement the SDP bundle negotiation
          extension will use the SDP Grouping Framework "mid" attribute to
          identify media streams. Such endpoints <span class="bcp14">MUST</span> implement the RTP MID
          header extension described in <span>[<a href="#RFC8843" class="xref">RFC8843</a>]</span>.<a href="#section-5.2.4-1" class="pilcrow">¶</a></p>
<p id="section-5.2.4-2">This header extension uses the 
          generic header extension framework described in <span>[<a href="#RFC8285" class="xref">RFC8285</a>]</span> and so needs to be negotiated
          before it can be used.<a href="#section-5.2.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-cvo">
<section id="section-5.2.5">
          <h4 id="name-coordination-of-video-orien">
<a href="#section-5.2.5" class="section-number selfRef">5.2.5. </a><a href="#name-coordination-of-video-orien" class="section-name selfRef">Coordination of Video Orientation</a>
          </h4>
<p id="section-5.2.5-1">WebRTC endpoints that send or receive video <span class="bcp14">MUST</span> implement the
          coordination of video orientation (CVO) RTP header extension as
          described in <span><a href="https://www.rfc-editor.org/rfc/rfc7742#section-4" class="relref">Section 4</a> of [<a href="#RFC7742" class="xref">RFC7742</a>]</span>.<a href="#section-5.2.5-1" class="pilcrow">¶</a></p>
<p id="section-5.2.5-2">This header extension uses the 
          generic header extension framework described in <span>[<a href="#RFC8285" class="xref">RFC8285</a>]</span> and so needs to be negotiated
          before it can be used.<a href="#section-5.2.5-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</section>
</div>
<div id="sec-rtp-robust">
<section id="section-6">
      <h2 id="name-webrtc-use-of-rtp-improving">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-webrtc-use-of-rtp-improving" class="section-name selfRef">WebRTC Use of RTP: Improving Transport Robustness</a>
      </h2>
<p id="section-6-1">There are tools that can make RTP packet streams robust against
      packet loss and reduce the impact of loss on media quality. However,
      they generally add some overhead compared to a non-robust stream. The
      overhead needs to be considered, and the aggregate bitrate <span class="bcp14">MUST</span> be rate
      controlled to avoid causing network congestion (see <a href="#sec-rate-control" class="xref">Section 7</a>). As a result, improving robustness
      might require a lower base encoding quality but has the potential to
      deliver that quality with fewer errors. The mechanisms described in the
      following subsections can be used to improve tolerance to packet
      loss.<a href="#section-6-1" class="pilcrow">¶</a></p>
<div id="sec-rtx">
<section id="section-6.1">
        <h3 id="name-negative-acknowledgements-a">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-negative-acknowledgements-a" class="section-name selfRef">Negative Acknowledgements and RTP Retransmission</a>
        </h3>
<p id="section-6.1-1">As a consequence of supporting the RTP/SAVPF profile,
        implementations can send negative acknowledgements (NACKs) for RTP
        data packets <span>[<a href="#RFC4585" class="xref">RFC4585</a>]</span>. This feedback can be used
        to inform a sender of the loss of particular RTP packets, subject to
        the capacity limitations of the RTCP feedback channel. A sender can
        use this information to optimize the user experience by adapting the
        media encoding to compensate for known lost packets.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">RTP packet stream senders are <span class="bcp14">REQUIRED</span> to understand the generic
        NACK message defined in <span><a href="https://www.rfc-editor.org/rfc/rfc4585#section-6.2.1" class="relref">Section 6.2.1</a> of [<a href="#RFC4585" class="xref">RFC4585</a>]</span>, but they <span class="bcp14">MAY</span> choose to ignore some or all of this
        feedback (following <span><a href="https://www.rfc-editor.org/rfc/rfc4585#section-4.2" class="relref">Section 4.2</a> of [<a href="#RFC4585" class="xref">RFC4585</a>]</span>).
        Receivers <span class="bcp14">MAY</span> send NACKs for missing RTP packets. Guidelines on when
        to send NACKs are provided in <span>[<a href="#RFC4585" class="xref">RFC4585</a>]</span>. It is
        not expected that a receiver will send a NACK for every lost RTP
        packet; rather, it needs to consider the cost of sending NACK feedback
        and the importance of the lost packet to make an informed decision on
        whether it is worth telling the sender about a packet-loss event.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
<p id="section-6.1-3">The <span><a href="#RFC4588" class="xref">RTP retransmission payload format</a> [<a href="#RFC4588" class="xref">RFC4588</a>]</span>
        offers the ability to retransmit lost packets based on NACK feedback.
        Retransmission needs to be used with care in interactive real-time
        applications to ensure that the retransmitted packet arrives in time
        to be useful, but it can be effective in environments with relatively low
        network RTT. (An RTP sender can estimate the RTT to the receivers using
        the information in RTCP SR and RR packets, as described at the end of
        <span><a href="https://www.rfc-editor.org/rfc/rfc3550#section-6.4.1" class="relref">Section 6.4.1</a> of [<a href="#RFC3550" class="xref">RFC3550</a>]</span>). The use of
        retransmissions can also increase the forward RTP bandwidth and can
        potentially cause increased packet loss if the original packet loss
        was caused by network congestion. Note, however, that retransmission
        of an important lost packet to repair decoder state can have lower
        cost than sending a full intra frame. It is not appropriate to blindly
        retransmit RTP packets in response to a NACK. The importance of lost
        packets and the likelihood of them arriving in time to be useful need
        to be considered before RTP retransmission is used.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<p id="section-6.1-4">Receivers are <span class="bcp14">REQUIRED</span> to implement support for RTP retransmission
        packets <span>[<a href="#RFC4588" class="xref">RFC4588</a>]</span> sent using SSRC multiplexing
        and <span class="bcp14">MAY</span> also support RTP retransmission packets sent using session
        multiplexing. Senders <span class="bcp14">MAY</span> send RTP retransmission packets in response
        to NACKs if support for the RTP retransmission payload format has been
        negotiated and the sender believes it is useful to send a
        retransmission of the packet(s) referenced in the NACK. Senders do not
        need to retransmit every NACKed packet.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-FEC">
<section id="section-6.2">
        <h3 id="name-forward-error-correction-fe">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-forward-error-correction-fe" class="section-name selfRef">Forward Error Correction (FEC)</a>
        </h3>
<p id="section-6.2-1">The use of Forward Error Correction (FEC) can provide an effective
        protection against some degree of packet loss, at the cost of steady
        bandwidth overhead. There are several FEC schemes that are defined for
        use with RTP. Some of these schemes are specific to a particular RTP
        payload format, and others operate across RTP packets and can be used with
        any payload format. Note that using redundant encoding
        or FEC will lead to increased play-out delay, which needs to be
        considered when choosing FEC schemes and their parameters.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">WebRTC endpoints <span class="bcp14">MUST</span> follow the recommendations for FEC use given
        in <span>[<a href="#RFC8854" class="xref">RFC8854</a>]</span>. WebRTC endpoints <span class="bcp14">MAY</span>
        support other types of FEC, but these <span class="bcp14">MUST</span> be negotiated before they
        are used.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-rate-control">
<section id="section-7">
      <h2 id="name-webrtc-use-of-rtp-rate-cont">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-webrtc-use-of-rtp-rate-cont" class="section-name selfRef">WebRTC Use of RTP: Rate Control and Media Adaptation</a>
      </h2>
<p id="section-7-1">WebRTC will be used in heterogeneous network environments using a
      variety of link technologies, including both wired and wireless links,
      to interconnect potentially large groups of users around the world. As a
      result, the network paths between users can have widely varying one-way
      delays, available bitrates, load levels, and traffic mixtures.
      Individual endpoints can send one or more RTP packet streams to each
      participant, and there can be several participants. Each of these RTP
      packet streams can contain different types of media, and the type of
      media, bitrate, and number of RTP packet streams as well as
      transport-layer flows can be highly asymmetric. Non-RTP traffic can
      share the network paths with RTP transport-layer flows. Since the
      network environment is not predictable or stable, WebRTC endpoints <span class="bcp14">MUST</span>
      ensure that the RTP traffic they generate can adapt to match changes in
      the available network capacity.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">The quality of experience for users of WebRTC is very dependent on
      effective adaptation of the media to the limitations of the network.
      Endpoints have to be designed so they do not transmit significantly more
      data than the network path can support, except for very short time
      periods; otherwise, high levels of network packet loss or delay spikes
      will occur, causing media quality degradation. The limiting factor on
      the capacity of the network path might be the link bandwidth, or it
      might be competition with other traffic on the link (this can be
      non-WebRTC traffic, traffic due to other WebRTC flows, or even
      competition with other WebRTC flows in the same session).<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">An effective media congestion control algorithm is therefore an
      essential part of the WebRTC framework. However, at the time of this
      writing, there is no standard congestion control algorithm that can be
      used for interactive media applications such as WebRTC's flows. Some
      requirements for congestion control algorithms for RTCPeerConnections
      are discussed in <span>[<a href="#RFC8836" class="xref">RFC8836</a>]</span>.
      If a standardized congestion control algorithm that satisfies these
      requirements is developed in the future, this memo will need to be
      updated to mandate its use.<a href="#section-7-3" class="pilcrow">¶</a></p>
<section id="section-7.1">
        <h3 id="name-boundary-conditions-and-cir">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-boundary-conditions-and-cir" class="section-name selfRef">Boundary Conditions and Circuit Breakers</a>
        </h3>
<p id="section-7.1-1">WebRTC endpoints <span class="bcp14">MUST</span> implement the RTP circuit breaker algorithm
        that is described in <span>[<a href="#RFC8083" class="xref">RFC8083</a>]</span>. The RTP
        circuit breaker is designed to enable applications to recognize and
        react to situations of extreme network congestion. However, since the
        RTP circuit breaker might not be triggered until congestion becomes
        extreme, it cannot be considered a substitute for congestion control,
        and applications <span class="bcp14">MUST</span> also implement congestion control to allow them
        to adapt to changes in network capacity. The congestion control
        algorithm will have to be proprietary until a standardized
        congestion control algorithm is available. Any future RTP congestion control
        algorithms are expected to operate within the envelope allowed by the
        circuit breaker.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2">The session-establishment signaling will also necessarily
        establish boundaries to which the media bitrate will conform. The
        choice of media codecs provides upper and lower bounds on the
        supported bitrates that the application can utilize to provide useful
        quality, and the packetization choices that exist. In addition, the
        signaling channel can establish maximum media bitrate boundaries
        using, for example, the SDP "b=AS:" or "b=CT:" lines and the RTP/AVPF
        TMMBR messages (see <a href="#sec.tmmbr" class="xref">Section 5.1.6</a> of this memo). Signaled bandwidth
        limitations, such as SDP "b=AS:" or "b=CT:" lines received from the
        peer, <span class="bcp14">MUST</span> be followed when sending RTP packet streams. A WebRTC
        endpoint receiving media <span class="bcp14">SHOULD</span> signal its bandwidth limitations.
        These limitations have to be based on known bandwidth limitations, for
        example the capacity of the edge links.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
</section>
<section id="section-7.2">
        <h3 id="name-congestion-control-interope">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-congestion-control-interope" class="section-name selfRef">Congestion Control Interoperability and Legacy Systems</a>
        </h3>
<p id="section-7.2-1">All endpoints that wish to interwork with WebRTC <span class="bcp14">MUST</span> implement
        RTCP and provide congestion feedback via the defined RTCP reporting
        mechanisms.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">When interworking with legacy implementations that support RTCP
        using the <span><a href="#RFC3551" class="xref">RTP/AVP profile</a> [<a href="#RFC3551" class="xref">RFC3551</a>]</span>, congestion
        feedback is provided in RTCP RR packets every few seconds.
        Implementations that have to interwork with such endpoints <span class="bcp14">MUST</span> ensure
        that they keep within the <span><a href="#RFC8083" class="xref">RTP
        circuit breaker</a> [<a href="#RFC8083" class="xref">RFC8083</a>]</span> constraints to limit the
        congestion they can cause.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
<p id="section-7.2-3">If a legacy endpoint supports RTP/AVPF, this enables negotiation of
        important parameters for frequent reporting, such as the "trr-int"
        parameter, and the possibility that the endpoint supports some useful
        feedback format for congestion control purposes such as <span><a href="#RFC5104" class="xref">TMMBR</a> [<a href="#RFC5104" class="xref">RFC5104</a>]</span>. Implementations that have to interwork
        with such endpoints <span class="bcp14">MUST</span> ensure that they stay within
        the <span><a href="#RFC8083" class="xref">RTP circuit
        breaker</a> [<a href="#RFC8083" class="xref">RFC8083</a>]</span> constraints to limit the 
        congestion they can cause, but they
        might find that they can achieve better congestion response depending
        on the amount of feedback that is available.<a href="#section-7.2-3" class="pilcrow">¶</a></p>
<p id="section-7.2-4">With proprietary congestion control algorithms, issues can arise
        when different algorithms and implementations interact in a
        communication session. If the different implementations have made
        different choices in regards to the type of adaptation, for example
        one sender based, and one receiver based, then one could end up in a
        situation where one direction is dual controlled when the other
        direction is not controlled. This memo cannot mandate behavior for
        proprietary congestion control algorithms, but implementations that
        use such algorithms ought to be aware of this issue and try to ensure
        that effective congestion control is negotiated for media flowing in
        both directions. If the IETF were to standardize both sender- and
        receiver-based congestion control algorithms for WebRTC traffic in the
        future, the issues of interoperability, control, and ensuring that
        both directions of media flow are congestion controlled would also
        need to be considered.<a href="#section-7.2-4" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="sec-perf">
<section id="section-8">
      <h2 id="name-webrtc-use-of-rtp-performan">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-webrtc-use-of-rtp-performan" class="section-name selfRef">WebRTC Use of RTP: Performance Monitoring</a>
      </h2>
<p id="section-8-1">As described in <a href="#sec-rtp-rtcp" class="xref">Section 4.1</a>, implementations
      are <span class="bcp14">REQUIRED</span> to generate RTCP Sender Report (SR) and Receiver Report
      (RR) packets relating to the RTP packet streams they send and receive.
      These RTCP reports can be used for performance monitoring purposes,
      since they include basic packet-loss and jitter statistics.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">A large number of additional performance metrics are supported by the
      RTCP Extended Reports (XR) framework; see <span>[<a href="#RFC3611" class="xref">RFC3611</a>]</span> and <span>[<a href="#RFC6792" class="xref">RFC6792</a>]</span>. At the time of
      this writing, it is not clear what extended metrics are suitable for use
      in WebRTC, so there is no requirement that implementations generate RTCP
      XR packets. However, implementations that can use detailed performance
      monitoring data <span class="bcp14">MAY</span> generate RTCP XR packets as appropriate. The use of
      RTCP XR packets <span class="bcp14">SHOULD</span> be signaled; implementations <span class="bcp14">MUST</span> ignore RTCP XR
      packets that are unexpected or not understood.<a href="#section-8-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-extn">
<section id="section-9">
      <h2 id="name-webrtc-use-of-rtp-future-ex">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-webrtc-use-of-rtp-future-ex" class="section-name selfRef">WebRTC Use of RTP: Future Extensions</a>
      </h2>
<p id="section-9-1">It is possible that the core set of RTP protocols and RTP extensions
      specified in this memo will prove insufficient for the future needs of
      WebRTC. In this case, future updates to this memo have to be made
      following <span><a href="#RFC2736" class="xref">"Guidelines for Writers of RTP
      Payload Format Specifications"</a> [<a href="#RFC2736" class="xref">RFC2736</a>]</span>, <span><a href="#RFC8088" class="xref">"How to Write an RTP Payload
      Format"</a> [<a href="#RFC8088" class="xref">RFC8088</a>]</span>, and <span><a href="#RFC5968" class="xref">"Guidelines for Extending the
      RTP Control Protocol (RTCP)"</a> [<a href="#RFC5968" class="xref">RFC5968</a>]</span>. They also <span class="bcp14">SHOULD</span> take into account any future
      guidelines for extending RTP and related protocols that have been
      developed.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">Authors of future extensions are urged to consider the wide range of
      environments in which RTP is used when recommending extensions, since
      extensions that are applicable in some scenarios can be problematic in
      others. Where possible, the WebRTC framework will adopt RTP extensions
      that are of general utility, to enable easy implementation of a gateway
      to other applications using RTP, rather than adopt mechanisms that are
      narrowly targeted at specific WebRTC use cases.<a href="#section-9-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-signalling">
<section id="section-10">
      <h2 id="name-signaling-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-signaling-considerations" class="section-name selfRef">Signaling Considerations</a>
      </h2>
<p id="section-10-1">RTP is built with the assumption that an external signaling channel
      exists and can be used to configure RTP sessions and their features.
      The basic configuration of an RTP session consists of the following
      parameters:<a href="#section-10-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-10-2">
        <dt id="section-10-2.1">RTP profile:</dt>
        <dd style="margin-left: 1.5em" id="section-10-2.2">The name of the RTP profile to be used in the
          session. The <span><a href="#RFC3551" class="xref">RTP/AVP</a> [<a href="#RFC3551" class="xref">RFC3551</a>]</span> and <span><a href="#RFC4585" class="xref">RTP/AVPF</a> [<a href="#RFC4585" class="xref">RFC4585</a>]</span> profiles can interoperate on a basic
          level, as can their secure variants, <span><a href="#RFC3711" class="xref">RTP/SAVP</a> [<a href="#RFC3711" class="xref">RFC3711</a>]</span> and <span><a href="#RFC5124" class="xref">RTP/SAVPF</a> [<a href="#RFC5124" class="xref">RFC5124</a>]</span>. The secure variants of the
          profiles do not directly interoperate with the nonsecure variants,
          due to the presence of additional header fields for authentication
          in SRTP packets and cryptographic transformation of the payload.
          WebRTC requires the use of the RTP/SAVPF profile, and this <span class="bcp14">MUST</span> be
          signaled. Interworking functions might transform this into the
          RTP/SAVP profile for a legacy use case by indicating to the WebRTC
          endpoint that the RTP/SAVPF is used and configuring a "trr-int" value
          of 4 seconds.<a href="#section-10-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-2.3">Transport information:</dt>
        <dd style="margin-left: 1.5em" id="section-10-2.4">Source and destination IP
          address(es) and ports for RTP and RTCP <span class="bcp14">MUST</span> be signaled for each RTP
          session. In WebRTC, these transport addresses will be provided by
          <span><a href="#RFC8445" class="xref">Interactive Connectivity Establishment
          (ICE)</a> [<a href="#RFC8445" class="xref">RFC8445</a>]</span> that signals candidates and
          arrives at nominated candidate address pairs. If <span><a href="#RFC5761" class="xref">RTP and RTCP multiplexing</a> [<a href="#RFC5761" class="xref">RFC5761</a>]</span> is to be used
          such that a single port -- i.e., transport-layer flow -- is used for RTP
          and RTCP flows, this <span class="bcp14">MUST</span> be signaled (see <a href="#sec.rtcp-mux" class="xref">Section 4.5</a>).<a href="#section-10-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-2.5">RTP payload types, media formats, and format parameters:</dt>
        <dd style="margin-left: 1.5em" id="section-10-2.6">The
          mapping between media type names (and hence the RTP payload formats
          to be used) and the RTP payload type numbers <span class="bcp14">MUST</span> be signaled.
          Each media type <span class="bcp14">MAY</span> also have a number of media type parameters that
          <span class="bcp14">MUST</span> also be signaled to configure the codec and RTP payload format
          (the "a=fmtp:" line from SDP). <a href="#sec.codecs" class="xref">Section 4.3</a> of
          this memo discusses requirements for uniqueness of payload
          types.<a href="#section-10-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-2.7">RTP extensions:</dt>
        <dd style="margin-left: 1.5em" id="section-10-2.8">The use of any additional RTP header
          extensions and RTCP packet types, including any necessary
          parameters, <span class="bcp14">MUST</span> be signaled. This signaling ensures
          that a WebRTC endpoint's behavior, especially when sending, is predictable and consistent. For robustness and
          compatibility with non-WebRTC systems that might be connected to a
          WebRTC session via a gateway, implementations are <span class="bcp14">REQUIRED</span> to ignore
          unknown RTCP packets and RTP header extensions (see also <a href="#sec-rtp-rtcp" class="xref">Section 4.1</a>).<a href="#section-10-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-2.9">RTCP bandwidth:</dt>
        <dd style="margin-left: 1.5em" id="section-10-2.10">Support for exchanging RTCP bandwidth
          values with the endpoints will be necessary. This <span class="bcp14">SHALL</span> be done as
          described in <span><a href="#RFC3556" class="xref">"Session Description Protocol
          (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP)
          Bandwidth"</a> [<a href="#RFC3556" class="xref">RFC3556</a>]</span> if using SDP, or something semantically
          equivalent. This also ensures that the endpoints have a common view
          of the RTCP bandwidth. A common view of the RTCP bandwidth among
          different endpoints is important to prevent differences in RTCP
          packet timing and timeout intervals causing interoperability
          problems.<a href="#section-10-2.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-10-3">These parameters are often expressed in SDP messages conveyed within
      an offer/answer exchange. RTP does not depend on SDP or the
      offer/answer model but does require all the necessary parameters to be
      agreed upon and provided to the RTP implementation. Note that in WebRTC,
      it will depend on the signaling model and API how these parameters need
      to be configured, but they will need to either be set in the API or
      explicitly signaled between the peers.<a href="#section-10-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-webrtc-api">
<section id="section-11">
      <h2 id="name-webrtc-api-considerations">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-webrtc-api-considerations" class="section-name selfRef">WebRTC API Considerations</a>
      </h2>
<p id="section-11-1">The <span><a href="#W3C.WebRTC" class="xref">WebRTC API</a> [<a href="#W3C.WebRTC" class="xref">W3C.WebRTC</a>]</span> and the
      <span><a href="#W3C.WD-mediacapture-streams" class="xref">Media Capture and
      Streams API</a> [<a href="#W3C.WD-mediacapture-streams" class="xref">W3C.WD-mediacapture-streams</a>]</span> define and use the concept of a MediaStream that
      consists of zero or more MediaStreamTracks. A MediaStreamTrack is an
      individual stream of media from any type of media source, such as a
      microphone or a camera, but conceptual sources, like an audio mix or
      a video composition, are also possible. The MediaStreamTracks within a
      MediaStream might need to be synchronized during playback.<a href="#section-11-1" class="pilcrow">¶</a></p>
<p id="section-11-2">A MediaStreamTrack's realization in RTP, in the context of an
      RTCPeerConnection, consists of a source packet stream, identified by an
      SSRC, sent within an RTP session that is part of the RTCPeerConnection. The
      MediaStreamTrack can also result in additional packet streams, and thus
      SSRCs, in the same RTP session. These can be dependent packet streams
      from scalable encoding of the source stream associated with the
      MediaStreamTrack, if such a media encoder is used. They can also be
      redundancy packet streams; these are created when applying <span><a href="#sec-FEC" class="xref">Forward Error Correction</a> (<a href="#sec-FEC" class="xref">Section 6.2</a>)</span> or <span><a href="#sec-rtx" class="xref">RTP retransmission</a> (<a href="#sec-rtx" class="xref">Section 6.1</a>)</span> to the source packet
      stream.<a href="#section-11-2" class="pilcrow">¶</a></p>
<p id="section-11-3">It is important to note that the same media source can be feeding
      multiple MediaStreamTracks. As different sets of constraints or other
      parameters can be applied to the MediaStreamTrack, each MediaStreamTrack
      instance added to an RTCPeerConnection <span class="bcp14">SHALL</span> result in an independent
      source packet stream with its own set of associated packet streams and
      thus different SSRC(s). It will depend on applied constraints and
      parameters if the source stream and the encoding configuration will be
      identical between different MediaStreamTracks sharing the same media
      source. If the encoding parameters and constraints are the same, an
      implementation could choose to use only one encoded stream to create the
      different RTP packet streams. Note that such optimizations would need to
      take into account that the constraints for one of the MediaStreamTracks
      can change at any moment, meaning that the encoding configurations might
      no longer be identical, and two different encoder instances would then be
      needed.<a href="#section-11-3" class="pilcrow">¶</a></p>
<p id="section-11-4">The same MediaStreamTrack can also be included in multiple
      MediaStreams; thus, multiple sets of MediaStreams can implicitly need to
      use the same synchronization base. To ensure that this works in all
      cases and does not force an endpoint to disrupt the media by changing
      synchronization base and CNAME during delivery of any ongoing packet
      streams, all MediaStreamTracks and their associated SSRCs originating
      from the same endpoint need to be sent using the same CNAME within one
      RTCPeerConnection. This is motivating the use of a single CNAME in <a href="#sec-cname" class="xref">Section 4.9</a>.<a href="#section-11-4" class="pilcrow">¶</a></p>
<aside id="section-11-5">
        <p id="section-11-5.1">The requirement to use the same CNAME for all SSRCs that
          originate from the same endpoint does not require a middlebox that
          forwards traffic from multiple endpoints to only use a single
          CNAME.<a href="#section-11-5.1" class="pilcrow">¶</a></p>
</aside>
<p id="section-11-6">Different CNAMEs normally need to be used for different
      RTCPeerConnection instances, as specified in <a href="#sec-cname" class="xref">Section 4.9</a>. Having two communication sessions with the
      same CNAME could enable tracking of a user or device across different
      services (see <span><a href="https://www.rfc-editor.org/rfc/rfc8826#section-4.4.1" class="relref">Section 4.4.1</a> of [<a href="#RFC8826" class="xref">RFC8826</a>]</span> for details). A web
      application can request that the CNAMEs used in different
      RTCPeerConnections (within a same-origin context) be the same; this
      allows for synchronization of the endpoint's RTP packet streams across
      the different RTCPeerConnections.<a href="#section-11-6" class="pilcrow">¶</a></p>
<aside id="section-11-7">
        <p id="section-11-7.1">Note: This doesn't result in a tracking issue, since the creation
          of matching CNAMEs depends on existing tracking within a single
          origin.<a href="#section-11-7.1" class="pilcrow">¶</a></p>
</aside>
<p id="section-11-8">The above will currently force a WebRTC endpoint that receives
      a MediaStreamTrack on one RTCPeerConnection and adds it as outgoing one
      on any RTCPeerConnection to perform resynchronization of the stream.
      Since the sending party needs to change the CNAME to the one it uses,
      this implies it has to use a local system clock as the timebase for the
      synchronization. Thus, the relative relation between the timebase of the
      incoming stream and the system sending out needs to be defined. This
      relation also needs monitoring for clock drift and likely adjustments of
      the synchronization. The sending entity is also responsible for
      congestion control for its sent streams. In cases of packet loss, the
      loss of incoming data also needs to be handled. This leads to the
      observation that the method that is least likely to cause issues or
      interruptions in the outgoing source packet stream is a model of full
      decoding, including repair, followed by encoding of the media again
      into the outgoing packet stream. Optimizations of this method are
      clearly possible and implementation specific.<a href="#section-11-8" class="pilcrow">¶</a></p>
<p id="section-11-9">A WebRTC endpoint <span class="bcp14">MUST</span> support receiving multiple MediaStreamTracks,
      where each of the different MediaStreamTracks (and its sets of
      associated packet streams) uses different CNAMEs. However,
      MediaStreamTracks that are received with different CNAMEs have no
      defined synchronization.<a href="#section-11-9" class="pilcrow">¶</a></p>
<aside id="section-11-10">
        <p id="section-11-10.1">Note: The motivation for supporting reception of multiple CNAMEs
          is to allow for forward compatibility with any future changes that
          enable more efficient stream handling when endpoints relay/forward
          streams. It also ensures that endpoints can interoperate with
          certain types of multistream middleboxes or endpoints that are not
          WebRTC.<a href="#section-11-10.1" class="pilcrow">¶</a></p>
</aside>
<p id="section-11-11"><span><a href="#RFC8829" class="xref">"JavaScript Session Establishment
      Protocol (JSEP)"</a> [<a href="#RFC8829" class="xref">RFC8829</a>]</span> specifies that the binding between the WebRTC
      MediaStreams, MediaStreamTracks, and the SSRC is done as specified in <span><a href="#RFC8830" class="xref">"WebRTC MediaStream Identification in the Session
      Description Protocol"</a> [<a href="#RFC8830" class="xref">RFC8830</a>]</span>. Section 4.1 of <span><a href="#RFC8830" class="xref">the MediaStream Identification (MSID) document</a> [<a href="#RFC8830" class="xref">RFC8830</a>]</span> also defines
      how to map source packet streams with unknown SSRCs to
      MediaStreamTracks and MediaStreams. This later is relevant to handle
      some cases of legacy interoperability. Commonly, the RTP payload type of
      any incoming packets will reveal if the packet stream is a source stream
      or a redundancy or dependent packet stream. The association to the
      correct source packet stream depends on the payload format in use for
      the packet stream.<a href="#section-11-11" class="pilcrow">¶</a></p>
<p id="section-11-12">Finally, this specification puts a requirement on the WebRTC API to
      realize a method for determining the <span><a href="#sec-rtp-rtcp" class="xref">CSRC
      list</a> (<a href="#sec-rtp-rtcp" class="xref">Section 4.1</a>)</span> as well as the <span><a href="#sec-mixer-to-client" class="xref">mixer-to-client audio levels</a> (<a href="#sec-mixer-to-client" class="xref">Section 5.2.3</a>)</span> (when
      supported); the basic requirements for this is further discussed in
      <a href="#sec-media-stream-id" class="xref">Section 12.2.1</a>.<a href="#section-11-12" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-rtp-func">
<section id="section-12">
      <h2 id="name-rtp-implementation-consider">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-rtp-implementation-consider" class="section-name selfRef">RTP Implementation Considerations</a>
      </h2>
<p id="section-12-1">The following discussion provides some guidance on the implementation
      of the RTP features described in this memo. The focus is on a WebRTC
      endpoint implementation perspective, and while some mention is made of
      the behavior of middleboxes, that is not the focus of this memo.<a href="#section-12-1" class="pilcrow">¶</a></p>
<section id="section-12.1">
        <h3 id="name-configuration-and-use-of-rt">
<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-configuration-and-use-of-rt" class="section-name selfRef">Configuration and Use of RTP Sessions</a>
        </h3>
<p id="section-12.1-1">A WebRTC endpoint will be a simultaneous participant in one or more
        RTP sessions. Each RTP session can convey multiple media sources and
        include media data from multiple endpoints. In the following, some
        ways in which WebRTC endpoints can configure and use RTP sessions are
        outlined.<a href="#section-12.1-1" class="pilcrow">¶</a></p>
<div id="sec.multiple-flows">
<section id="section-12.1.1">
          <h4 id="name-use-of-multiple-media-sourc">
<a href="#section-12.1.1" class="section-number selfRef">12.1.1. </a><a href="#name-use-of-multiple-media-sourc" class="section-name selfRef">Use of Multiple Media Sources within an RTP Session</a>
          </h4>
<p id="section-12.1.1-1">RTP is a group communication protocol, and every RTP session can
          potentially contain multiple RTP packet streams. There are several
          reasons why this might be desirable:<a href="#section-12.1.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-12.1.1-2.1">
              <p id="section-12.1.1-2.1.1">Multiple media types:<a href="#section-12.1.1-2.1.1" class="pilcrow">¶</a></p>
<p id="section-12.1.1-2.1.2">Outside of WebRTC, it is
              common to use one RTP session for each type of media source
              (e.g., one RTP session for audio sources and one for video
              sources, each sent over different transport-layer flows).
              However, to reduce the number of UDP ports used, the default in
              WebRTC is to send all types of media in a single RTP session, as
              described in <a href="#sec.session-mux" class="xref">Section 4.4</a>, using RTP
              and RTCP multiplexing (<a href="#sec.rtcp-mux" class="xref">Section 4.5</a>) to
              further reduce the number of UDP ports needed. This RTP session
              then uses only one bidirectional transport-layer flow but will
              contain multiple RTP packet streams, each containing a different
              type of media. A common example might be an endpoint with a
              camera and microphone that sends two RTP packet streams, one
              video and one audio, into a single RTP session.<a href="#section-12.1.1-2.1.2" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-12.1.1-2.2">
              <p id="section-12.1.1-2.2.1">Multiple capture devices:<a href="#section-12.1.1-2.2.1" class="pilcrow">¶</a></p>
<p id="section-12.1.1-2.2.2">A WebRTC endpoint might
              have multiple cameras, microphones, or other media capture
              devices, and so it might want to generate several RTP packet
              streams of the same media type. Alternatively, it might want to
              send media from a single capture device in several different
              formats or quality settings at once. Both can result in a single
              endpoint sending multiple RTP packet streams of the same media
              type into a single RTP session at the same time.<a href="#section-12.1.1-2.2.2" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-12.1.1-2.3">
              <p id="section-12.1.1-2.3.1">Associated repair data:<a href="#section-12.1.1-2.3.1" class="pilcrow">¶</a></p>
<p id="section-12.1.1-2.3.2">An endpoint might send an
              RTP packet stream that is somehow associated with another
              stream. For example, it might send an RTP packet stream that
              contains FEC or retransmission data relating to another stream.
              Some RTP payload formats send this sort of associated repair
              data as part of the source packet stream, while others send it
              as a separate packet stream.<a href="#section-12.1.1-2.3.2" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-12.1.1-2.4">
              <p id="section-12.1.1-2.4.1">Layered or multiple-description coding:<a href="#section-12.1.1-2.4.1" class="pilcrow">¶</a></p>
<p id="section-12.1.1-2.4.2">Within a single
              RTP session, an endpoint can use a layered media codec -- for
              example, H.264 Scalable Video Coding (SVC) --
              or a multiple-description codec that generates multiple RTP
              packet streams, each with a distinct RTP SSRC.<a href="#section-12.1.1-2.4.2" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-12.1.1-2.5">
              <p id="section-12.1.1-2.5.1">RTP mixers, translators, and other middleboxes:<a href="#section-12.1.1-2.5.1" class="pilcrow">¶</a></p>
<p id="section-12.1.1-2.5.2">An
              RTP session, in the WebRTC context, is a point-to-point
              association between an endpoint and some other peer device,
              where those devices share a common SSRC space. The peer device
              might be another WebRTC endpoint, or it might be an RTP mixer,
              translator, or some other form of media-processing middlebox. In
              the latter cases, the middlebox might send mixed or relayed RTP
              streams from several participants, which the WebRTC endpoint will
              need to render. Thus, even though a WebRTC endpoint might only
              be a member of a single RTP session, the peer device might be
              extending that RTP session to incorporate other endpoints.
              WebRTC is a group communication environment, and endpoints need
              to be capable of receiving, decoding, and playing out multiple
              RTP packet streams at once, even in a single RTP session.<a href="#section-12.1.1-2.5.2" class="pilcrow">¶</a></p>
</li>
          </ul>
</section>
</div>
<div id="sec.multiple-sessions">
<section id="section-12.1.2">
          <h4 id="name-use-of-multiple-rtp-session">
<a href="#section-12.1.2" class="section-number selfRef">12.1.2. </a><a href="#name-use-of-multiple-rtp-session" class="section-name selfRef">Use of Multiple RTP Sessions</a>
          </h4>
<p id="section-12.1.2-1">In addition to sending and receiving multiple RTP packet streams
          within a single RTP session, a WebRTC endpoint might participate in
          multiple RTP sessions. There are several reasons why a WebRTC
          endpoint might choose to do this:<a href="#section-12.1.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-12.1.2-2.1">
              <p id="section-12.1.2-2.1.1">To interoperate with legacy devices:<a href="#section-12.1.2-2.1.1" class="pilcrow">¶</a></p>
<p id="section-12.1.2-2.1.2">The common
              practice in the non-WebRTC world is to send different types of
              media in separate RTP sessions -- for example, using one RTP
              session for audio and another RTP session, on a separate
              transport-layer flow, for video. All WebRTC endpoints need to
              support the option of sending different types of media on
              different RTP sessions so they can interwork with such legacy
              devices. This is discussed further in <a href="#sec.session-mux" class="xref">Section 4.4</a>.<a href="#section-12.1.2-2.1.2" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-12.1.2-2.2">
              <p id="section-12.1.2-2.2.1">To provide enhanced quality of service:<a href="#section-12.1.2-2.2.1" class="pilcrow">¶</a></p>
<p id="section-12.1.2-2.2.2">Some
              network-based quality-of-service mechanisms operate on the
              granularity of transport-layer flows. If use of
              these mechanisms to provide differentiated quality of service
              for some RTP packet streams is desired, then those RTP packet streams need
              to be sent in a separate RTP session using a different
              transport-layer flow, and with appropriate quality-of-service
              marking. This is discussed further in <a href="#sec-differentiated" class="xref">Section 12.1.3</a>.<a href="#section-12.1.2-2.2.2" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-12.1.2-2.3">
              <p id="section-12.1.2-2.3.1">To separate media with different purposes:<a href="#section-12.1.2-2.3.1" class="pilcrow">¶</a></p>
<p id="section-12.1.2-2.3.2">An
              endpoint might want to send RTP packet streams that have
              different purposes on different RTP sessions, to make it easy
              for the peer device to distinguish them. For example, some
              centralized multiparty conferencing systems display the active
              speaker in high resolution but show low-resolution "thumbnails"
              of other participants. Such systems might configure the
              endpoints to send simulcast high- and low-resolution versions of
              their video using separate RTP sessions to simplify the
              operation of the RTP middlebox. In the WebRTC context, this is
              currently possible by establishing multiple WebRTC
              MediaStreamTracks that have the same media source in one (or
              more) RTCPeerConnection. Each MediaStreamTrack is then
              configured to deliver a particular media quality and thus media
              bitrate, and it will produce an independently encoded version with
              the codec parameters agreed specifically in the context of that
              RTCPeerConnection. The RTP middlebox can distinguish packets
              corresponding to the low- and high-resolution streams by
              inspecting their SSRC, RTP payload type, or some other
              information contained in RTP payload, RTP header extension, or
              RTCP packets. However, it can be easier to distinguish the RTP packet
              streams if they arrive on separate RTP sessions on separate
              transport-layer flows.<a href="#section-12.1.2-2.3.2" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-12.1.2-2.4">
              <p id="section-12.1.2-2.4.1">To directly connect with multiple peers:<a href="#section-12.1.2-2.4.1" class="pilcrow">¶</a></p>
<p id="section-12.1.2-2.4.2">A
              multiparty conference does not need to use an RTP middlebox.
              Rather, a multi-unicast mesh can be created, comprising several
              distinct RTP sessions, with each participant sending RTP traffic
              over a separate RTP session (that is, using an independent
              RTCPeerConnection object) to every other participant, as shown
              in <a href="#fig-mesh" class="xref">Figure 1</a>. This topology has the
              benefit of not requiring an RTP middlebox node that is trusted
              to access and manipulate the media data. The downside is that it
              increases the used bandwidth at each sender by requiring one
              copy of the RTP packet streams for each participant that is
              part of the same session beyond the sender itself.<a href="#section-12.1.2-2.4.2" class="pilcrow">¶</a></p>
<span id="name-multi-unicast-using-several"></span><div id="fig-mesh">
<figure id="figure-1">
                <div class="artwork art-text alignLeft" id="section-12.1.2-2.4.3.1">
<pre>

+---+     +---+
| A |&lt;---&gt;| B |
+---+     +---+
  ^         ^
   \       /
    \     /
     v   v
     +---+
     | C |
     +---+</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-multi-unicast-using-several" class="selfRef">Multi-unicast Using Several RTP Sessions</a>
                </figcaption></figure>
</div>
<p id="section-12.1.2-2.4.4">The multi-unicast topology could also be implemented as a
              single RTP session, spanning multiple peer-to-peer
              transport-layer connections, or as several pairwise RTP
              sessions, one
              between each pair of peers. To maintain a coherent mapping of
              the relationship between RTP sessions and RTCPeerConnection
              objects, it is <span class="bcp14">RECOMMENDED</span> that this be implemented as several
              individual RTP sessions. The only downside is that endpoint A
              will not learn of the quality of any transmission happening
              between B and C, since it will not see RTCP reports for the RTP
              session between B and C, whereas it would if all three
              participants were part of a single RTP session. Experience with
              the Mbone tools (experimental RTP-based multicast conferencing
              tools from the late 1990s) has shown that RTCP reception
              quality reports for third parties can be presented to users in a
              way that helps them understand asymmetric network problems, and
              the approach of using separate RTP sessions prevents this.
              However, an advantage of using separate RTP sessions is that it
              enables using different media bitrates and RTP session
              configurations between the different peers, thus not forcing B
              to endure the same quality reductions as C will if there are limitations
              in the transport from A to C. It is believed that
              these advantages outweigh the limitations in debugging
              power.<a href="#section-12.1.2-2.4.4" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-12.1.2-2.5">
              <p id="section-12.1.2-2.5.1">To indirectly connect with multiple peers:<a href="#section-12.1.2-2.5.1" class="pilcrow">¶</a></p>
<p id="section-12.1.2-2.5.2">A
              common scenario in multiparty conferencing is to create
              indirect connections to multiple peers, using an RTP mixer,
              translator, or some other type of RTP middlebox. <a href="#fig-mixerFirst" class="xref">Figure 2</a> outlines a simple topology that
              might be used in a four-person centralized conference. The
              middlebox acts to optimize the transmission of RTP packet
              streams from certain perspectives, either by only sending some
              of the received RTP packet stream to any given receiver, or by
              providing a combined RTP packet stream out of a set of
              contributing streams.<a href="#section-12.1.2-2.5.2" class="pilcrow">¶</a></p>
<span id="name-rtp-mixer-with-only-unicast"></span><div id="fig-mixerFirst">
<figure id="figure-2">
                <div class="artwork art-text alignLeft" id="section-12.1.2-2.5.3.1">
<pre>

+---+      +-------------+      +---+
| A |&lt;----&gt;|             |&lt;----&gt;| B |
+---+      | RTP mixer,  |      +---+
           | translator, |
           | or other    |
+---+      | middlebox   |      +---+
| C |&lt;----&gt;|             |&lt;----&gt;| D |
+---+      +-------------+      +---+</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-rtp-mixer-with-only-unicast" class="selfRef">RTP Mixer with Only Unicast Paths</a>
                </figcaption></figure>
</div>
<p id="section-12.1.2-2.5.4">There are various methods of implementation for the
              middlebox. If implemented as a standard RTP mixer or translator,
              a single RTP session will extend across the middlebox and
              encompass all the endpoints in one multiparty session. Other
              types of middleboxes might use separate RTP sessions between each
              endpoint and the middlebox. A common aspect is that these RTP
              middleboxes can use a number of tools to control the media
              encoding provided by a WebRTC endpoint. This includes functions
              like requesting the breaking of the encoding chain and having the
              encoder produce a so-called Intra frame. Another common aspect
              is limiting the bitrate of a stream to better match the mixed
              output. Other aspects are controlling the most suitable
              frame rate, picture resolution, and the trade-off between frame rate
              and spatial quality. The middlebox has the responsibility to
              correctly perform congestion control, identify sources, and
              manage synchronization while providing the application with
              suitable media optimizations. The middlebox also has to be a
              trusted node when it comes to security, since it manipulates
              either the RTP header or the media itself (or both) received
              from one endpoint before sending them on towards the endpoint(s);
              thus they need to be able to decrypt and then re-encrypt the RTP
              packet stream before sending it out.<a href="#section-12.1.2-2.5.4" class="pilcrow">¶</a></p>
<p id="section-12.1.2-2.5.5">Mixers are expected to not
              forward RTCP reports regarding RTP packet streams across
              themselves. This is due to the difference between the RTP packet
              streams provided to the different endpoints. The original media
              source lacks information about a mixer's manipulations prior to being
              sent to the different receivers. This scenario also results
              in an endpoint's feedback or requests going to the mixer. When
              the mixer can't act on this by itself, it is forced to go to the
              original media source to fulfill the receiver's request. This will
              not necessarily be explicitly visible to any RTP and RTCP
              traffic, but the interactions and the time to complete them will
              indicate such dependencies.<a href="#section-12.1.2-2.5.5" class="pilcrow">¶</a></p>
<p id="section-12.1.2-2.5.6">Providing source authentication in multiparty scenarios is a
              challenge. In the mixer-based topologies, endpoints source
              authentication is based on, firstly, verifying that media comes
              from the mixer by cryptographic verification and, secondly,
              trust in the mixer to correctly identify any source towards the
              endpoint. In RTP sessions where multiple endpoints are directly
              visible to an endpoint, all endpoints will have knowledge about
              each others' master keys and can thus inject packets claiming to
              come from another endpoint in the session. Any node performing
              relay can perform noncryptographic mitigation by preventing
              forwarding of packets that have SSRC fields that came from other
              endpoints before. For cryptographic verification of the source,
              SRTP would require additional security mechanisms -- for example,
              <span><a href="#RFC4383" class="xref">Timed Efficient Stream Loss-Tolerant
              Authentication (TESLA) for SRTP</a> [<a href="#RFC4383" class="xref">RFC4383</a>]</span> -- that are not part
              of the base WebRTC standards.<a href="#section-12.1.2-2.5.6" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-12.1.2-2.6">
              <p id="section-12.1.2-2.6.1">To forward media between multiple peers:<a href="#section-12.1.2-2.6.1" class="pilcrow">¶</a></p>
<p id="section-12.1.2-2.6.2">It is
              sometimes desirable for an endpoint that receives an RTP packet
              stream to be able to forward that RTP packet stream to a third
              party. The are some obvious security and privacy implications in
              supporting this, but also potential uses. This is supported in
              the W3C API by taking the received and decoded media and using
              it as a media source that is re-encoded and transmitted as a new
              stream.<a href="#section-12.1.2-2.6.2" class="pilcrow">¶</a></p>
<p id="section-12.1.2-2.6.3">At the RTP layer, media forwarding acts as a back-to-back RTP
              receiver and RTP sender. The receiving side terminates the RTP
              session and decodes the media, while the sender side re-encodes
              and transmits the media using an entirely separate RTP session.
              The original sender will only see a single receiver of the
              media, and will not be able to tell that forwarding is happening
              based on RTP-layer information, since the RTP session that is
              used to send the forwarded media is not connected to the RTP
              session on which the media was received by the node doing the
              forwarding.<a href="#section-12.1.2-2.6.3" class="pilcrow">¶</a></p>
<p id="section-12.1.2-2.6.4">The endpoint that is performing the forwarding is responsible
              for producing an RTP packet stream suitable for onwards
              transmission. The outgoing RTP session that is used to send the
              forwarded media is entirely separate from the RTP session on which
              the media was received. This will require media transcoding for
              congestion control purposes to produce a suitable bitrate for
              the outgoing RTP session, reducing media quality and forcing the
              forwarding endpoint to spend the resource on the transcoding.
              The media transcoding does result in a separation of the two
              different legs, removing almost all dependencies, and allowing
              the forwarding endpoint to optimize its media transcoding
              operation. The cost is greatly increased computational
              complexity on the forwarding node. Receivers of the forwarded
              stream will see the forwarding device as the sender of the
              stream and will not be able to tell from the RTP layer that
              they are receiving a forwarded stream rather than an entirely
              new RTP packet stream generated by the forwarding device.<a href="#section-12.1.2-2.6.4" class="pilcrow">¶</a></p>
</li>
          </ul>
</section>
</div>
<div id="sec-differentiated">
<section id="section-12.1.3">
          <h4 id="name-differentiated-treatment-of">
<a href="#section-12.1.3" class="section-number selfRef">12.1.3. </a><a href="#name-differentiated-treatment-of" class="section-name selfRef">Differentiated Treatment of RTP Streams</a>
          </h4>
<p id="section-12.1.3-1">There are use cases for differentiated treatment of RTP packet
          streams. Such differentiation can happen at several places in the
          system. First of all is the prioritization within the endpoint
          sending the media, which controls both which RTP packet streams
          will be sent and their allocation of bitrate out of the
          current available aggregate, as determined by the congestion
          control.<a href="#section-12.1.3-1" class="pilcrow">¶</a></p>
<p id="section-12.1.3-2">It is expected that the <span><a href="#W3C.WebRTC" class="xref">WebRTC API</a> [<a href="#W3C.WebRTC" class="xref">W3C.WebRTC</a>]</span> will allow the
          application to indicate relative priorities for different
          MediaStreamTracks. These priorities can then be used to influence
          the local RTP processing, especially when it comes to determining
          how to divide the available bandwidth between
          the RTP packet streams for the sake of congestion control. Any
          changes in relative priority will also
          need to be considered for RTP packet streams that are associated
          with the main RTP packet streams, such as redundant streams for RTP
          retransmission and FEC. The importance of such redundant RTP packet
          streams is dependent on the media type and codec used, with regard to
          how robust that codec is against packet loss. However, a default policy
          might be to use the same priority for a redundant RTP packet stream
          as for the source RTP packet stream.<a href="#section-12.1.3-2" class="pilcrow">¶</a></p>
<p id="section-12.1.3-3">Secondly, the network can prioritize transport-layer flows and
          subflows, including RTP packet streams. Typically, differential
          treatment includes two steps, the first being identifying whether an
          IP packet belongs to a class that has to be treated differently, the
          second consisting of the actual mechanism for prioritizing packets.
          Three common methods for classifying IP packets are:<a href="#section-12.1.3-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-12.1.3-4">
            <dt id="section-12.1.3-4.1">DiffServ:</dt>
            <dd style="margin-left: 1.5em" id="section-12.1.3-4.2">The endpoint marks a packet with a
              DiffServ code point to indicate to the network that the packet
              belongs to a particular class.<a href="#section-12.1.3-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.1.3-4.3">Flow based:</dt>
            <dd style="margin-left: 1.5em" id="section-12.1.3-4.4">Packets that need to be given a
              particular treatment are identified using a combination of IP
              and port address.<a href="#section-12.1.3-4.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.1.3-4.5">Deep packet inspection:</dt>
            <dd style="margin-left: 1.5em" id="section-12.1.3-4.6">A network classifier (DPI)
              inspects the packet and tries to determine if the packet
              represents a particular application and type that is to be
              prioritized.<a href="#section-12.1.3-4.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-12.1.3-5">Flow-based differentiation will provide the same treatment to all
          packets within a transport-layer flow, i.e., relative prioritization
          is not possible. Moreover, if the resources are limited, it might not
          be possible to provide differential treatment compared to
          best effort for all the RTP packet streams used in a WebRTC session.
          The use of flow-based differentiation needs to be coordinated
          between the WebRTC system and the network(s). The WebRTC endpoint
          needs to know that flow-based differentiation might be used to
          provide the separation of the RTP packet streams onto different UDP
          flows to enable a more granular usage of flow-based differentiation.
          The used flows, their 5-tuples, and prioritization will need to be
          communicated to the network so that it can identify the flows
          correctly to enable prioritization. No specific protocol support for
          this is specified.<a href="#section-12.1.3-5" class="pilcrow">¶</a></p>
<p id="section-12.1.3-6">DiffServ assumes that either the endpoint or a classifier can
          mark the packets with an appropriate Differentiated Services Code
          Point (DSCP) so that the packets are
          treated according to that marking. If the endpoint is to mark the
          traffic, two requirements arise in the WebRTC context: 1) The WebRTC
          endpoint has to know which DSCPs to use and know that it can use them on
          some set of RTP packet streams. 2) The information needs to be
          propagated to the operating system when transmitting the packet.
          Details of this process are outside the scope of this memo and are
          further discussed in <span><a href="#RFC8837" class="xref">"Differentiated Services Code Point (DSCP) Packet
   Markings for WebRTC QoS"</a> [<a href="#RFC8837" class="xref">RFC8837</a>]</span>.<a href="#section-12.1.3-6" class="pilcrow">¶</a></p>
<p id="section-12.1.3-7">Despite the SRTP media encryption, deep packet inspectors will
          still be fairly capable of
          classifying the RTP streams. The reason
          is that SRTP leaves the first 12 bytes of the RTP header
          unencrypted. This enables easy RTP stream identification using the
          SSRC and provides the classifier with useful information that can be
          correlated to determine, for example, the stream's media type. Using
          packet sizes, reception times, packet inter-spacing, RTP timestamp
          increments, and sequence numbers, fairly reliable classifications are
          achieved.<a href="#section-12.1.3-7" class="pilcrow">¶</a></p>
<p id="section-12.1.3-8">For packet-based marking schemes, it might be possible to mark
          individual RTP packets differently based on the relative priority of
          the RTP payload. For example, video codecs that have I, P, and B
          pictures could prioritize any payloads carrying only B frames less,
          as these are less damaging to lose. However, depending on the QoS
          mechanism and what markings are applied, this can result in not
          only different packet-drop probabilities but also packet reordering;
          see <span>[<a href="#RFC8837" class="xref">RFC8837</a>]</span> and <span>[<a href="#RFC7657" class="xref">RFC7657</a>]</span> for further discussion. As a
          default policy, all RTP packets related to an RTP packet stream ought
          to be provided with the same prioritization; per-packet
          prioritization is outside the scope of this memo but might be
          specified elsewhere in future.<a href="#section-12.1.3-8" class="pilcrow">¶</a></p>
<p id="section-12.1.3-9">It is also important to consider how RTCP packets associated with
          a particular RTP packet stream need to be marked. RTCP compound
          packets with Sender Reports (SRs) ought to be marked with the same
          priority as the RTP packet stream itself, so the RTCP-based
          round-trip time (RTT) measurements are done using the same
          transport-layer flow priority as the RTP packet stream experiences.
          RTCP compound packets containing an RR packet ought to be sent with the
          priority used by the majority of the RTP packet streams reported on.
          RTCP packets containing time-critical feedback packets can use
          higher priority to improve the timeliness and likelihood of delivery
          of such feedback.<a href="#section-12.1.3-9" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<section id="section-12.2">
        <h3 id="name-media-source-rtp-streams-an">
<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-media-source-rtp-streams-an" class="section-name selfRef">Media Source, RTP Streams, and Participant Identification</a>
        </h3>
<div id="sec-media-stream-id">
<section id="section-12.2.1">
          <h4 id="name-media-source-identification">
<a href="#section-12.2.1" class="section-number selfRef">12.2.1. </a><a href="#name-media-source-identification" class="section-name selfRef">Media Source Identification</a>
          </h4>
<p id="section-12.2.1-1">Each RTP packet stream is identified by a unique synchronization
          source (SSRC) identifier. The SSRC identifier is carried in each of
          the RTP packets comprising an RTP packet stream, and is also used to
          identify that stream in the corresponding RTCP reports. The SSRC is
          chosen as discussed in <a href="#sec-ssrc" class="xref">Section 4.8</a>. The first
          stage in demultiplexing RTP and RTCP packets received on a single
          transport-layer flow at a WebRTC endpoint is to separate the RTP
          packet streams based on their SSRC value; once that is done,
          additional demultiplexing steps can determine how and where to
          render the media.<a href="#section-12.2.1-1" class="pilcrow">¶</a></p>
<p id="section-12.2.1-2">RTP allows a mixer, or other RTP-layer middlebox, to combine
          encoded streams from multiple media sources to form a new encoded
          stream from a new media source (the mixer). The RTP packets in that
          new RTP packet stream can include a contributing source (CSRC) list,
          indicating which original SSRCs contributed to the combined source
          stream. As described in <a href="#sec-rtp-rtcp" class="xref">Section 4.1</a>,
          implementations need to support reception of RTP data packets
          containing a CSRC list and RTCP packets that relate to sources
          present in the CSRC list. The CSRC list can change on a
          packet-by-packet basis, depending on the mixing operation being
          performed. Knowledge of what media sources contributed to a
          particular RTP packet can be important if the user interface
          indicates which participants are active in the session. Changes in
          the CSRC list included in packets need to be exposed to the WebRTC
          application using some API if the application is to be able to
          track changes in session participation. It is desirable to map CSRC
          values back into WebRTC MediaStream identities as they cross this
          API, to avoid exposing the SSRC/CSRC namespace to WebRTC
          applications.<a href="#section-12.2.1-2" class="pilcrow">¶</a></p>
<p id="section-12.2.1-3">If the mixer-to-client audio level extension <span>[<a href="#RFC6465" class="xref">RFC6465</a>]</span> is being used in the session (see <a href="#sec-mixer-to-client" class="xref">Section 5.2.3</a>), the information in the CSRC
          list is augmented by audio-level information for each contributing
          source. It is desirable to expose this information to the WebRTC
          application using some API, after mapping the CSRC values to WebRTC
          MediaStream identities, so it can be exposed in the user
          interface.<a href="#section-12.2.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-12.2.2">
          <h4 id="name-ssrc-collision-detection">
<a href="#section-12.2.2" class="section-number selfRef">12.2.2. </a><a href="#name-ssrc-collision-detection" class="section-name selfRef">SSRC Collision Detection</a>
          </h4>
<p id="section-12.2.2-1">The RTP standard requires RTP implementations to have support for
          detecting and handling SSRC collisions -- i.e., be able to resolve the conflict
          when two different endpoints use the same SSRC value (see <span><a href="https://www.rfc-editor.org/rfc/rfc3550#section-8.2" class="relref">Section 8.2</a> of [<a href="#RFC3550" class="xref">RFC3550</a>]</span>). This requirement also
          applies to WebRTC endpoints. There are several scenarios where SSRC
          collisions can occur:<a href="#section-12.2.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-12.2.2-2.1">In a point-to-point session where each SSRC is associated
              with either of the two endpoints and the main media-carrying SSRC
              identifier will be announced in the signaling
              channel, a collision is less likely to occur due to the
              information about used SSRCs. If SDP is used, this information
              is provided by <span><a href="#RFC5576" class="xref">source-specific SDP
              attributes</a> [<a href="#RFC5576" class="xref">RFC5576</a>]</span>. Still, collisions can occur if both endpoints
              start using a new SSRC identifier prior to having signaled it
              to the peer and received acknowledgement on the signaling
              message. <span><a href="#RFC5576" class="xref">"Source-Specific Media Attributes in the
              Session Description Protocol (SDP)"</a> [<a href="#RFC5576" class="xref">RFC5576</a>]</span>
              contains a mechanism to signal how the
              endpoint resolved the SSRC collision.<a href="#section-12.2.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-12.2.2-2.2">SSRC values that have not been signaled could also appear in
              an RTP session. This is more likely than it appears, since some
              RTP functions use extra SSRCs to provide their functionality.
              For example, retransmission data might be transmitted using a
              separate RTP packet stream that requires its own SSRC, separate
              from the SSRC of the source RTP packet stream <span>[<a href="#RFC4588" class="xref">RFC4588</a>]</span>. In those cases, an endpoint can create
              a new SSRC that strictly doesn't need to be announced over the
              signaling channel to function correctly on both RTP and
              RTCPeerConnection level.<a href="#section-12.2.2-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-12.2.2-2.3">Multiple endpoints in a multiparty conference can create new
              sources and signal those towards the RTP middlebox. In cases
              where the SSRC/CSRC are propagated between the different
              endpoints from the RTP middlebox, collisions can occur.<a href="#section-12.2.2-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-12.2.2-2.4">An RTP middlebox could connect an endpoint's
              RTCPeerConnection to another RTCPeerConnection from the same
              endpoint, thus forming a loop where the endpoint will receive
              its own traffic. While it is clearly considered a bug, it is
              important that the endpoint be able to recognize and handle the
              case when it occurs. This case becomes even more problematic
              when media mixers and such are involved, where the stream
              received is a different stream but still contains this client's
              input.<a href="#section-12.2.2-2.4" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-12.2.2-3">These SSRC/CSRC collisions can only be handled on the RTP level 
          when the same RTP session is extended across multiple
          RTCPeerConnections by an RTP middlebox. To resolve the more generic
          case where multiple RTCPeerConnections are interconnected,
          identification of the media source or sources that are part of a MediaStreamTrack
          being propagated across multiple interconnected RTCPeerConnection
          needs to be preserved across these interconnections.<a href="#section-12.2.2-3" class="pilcrow">¶</a></p>
</section>
<section id="section-12.2.3">
          <h4 id="name-media-synchronization-conte">
<a href="#section-12.2.3" class="section-number selfRef">12.2.3. </a><a href="#name-media-synchronization-conte" class="section-name selfRef">Media Synchronization Context</a>
          </h4>
<p id="section-12.2.3-1">When an endpoint sends media from more than one media source, it
          needs to consider if (and which of) these media sources are to be
          synchronized. In RTP/RTCP, synchronization is provided by having a
          set of RTP packet streams be indicated as coming from the same
          synchronization context and logical endpoint by using the same RTCP
          CNAME identifier.<a href="#section-12.2.3-1" class="pilcrow">¶</a></p>
<p id="section-12.2.3-2">The next provision is that the internal clocks of all media
          sources -- i.e., what drives the RTP timestamp -- can be correlated to a
          system clock that is provided in RTCP Sender Reports encoded in an
          NTP format. By correlating all RTP timestamps to a common system
          clock for all sources, the timing relation of the different RTP
          packet streams, also across multiple RTP sessions, can be derived at
          the receiver and, if desired, the streams can be synchronized.
 The requirement is for the media sender to provide the correlation
          information; whether or not the information is used is up to the receiver.<a href="#section-12.2.3-2" class="pilcrow">¶</a></p>
</section>
</section>
</section>
</div>
<div id="sec-security">
<section id="section-13">
      <h2 id="name-security-considerations">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-13-1">The overall security architecture for WebRTC is described in <span>[<a href="#RFC8827" class="xref">RFC8827</a>]</span>, and security
      considerations for the WebRTC framework are described in <span>[<a href="#RFC8826" class="xref">RFC8826</a>]</span>. These considerations also
      apply to this memo.<a href="#section-13-1" class="pilcrow">¶</a></p>
<p id="section-13-2">The security considerations of the RTP specification, the RTP/SAVPF
      profile, and the various RTP/RTCP extensions and RTP payload formats
      that form the complete protocol suite described in this memo apply. It
      is believed that there are no new security considerations resulting from
      the combination of these various protocol extensions.<a href="#section-13-2" class="pilcrow">¶</a></p>
<p id="section-13-3"><span><a href="#RFC5124" class="xref">"Extended Secure RTP
      Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)"</a> [<a href="#RFC5124" class="xref">RFC5124</a>]</span>
      provides handling of fundamental issues by offering confidentiality,
      integrity, and partial source authentication. A media-security solution
      that is mandatory to implement and use is created by combining this secured RTP
      profile and <span><a href="#RFC5764" class="xref">DTLS-SRTP keying</a> [<a href="#RFC5764" class="xref">RFC5764</a>]</span>, as defined by
      <span><a href="https://www.rfc-editor.org/rfc/rfc8827#section-5.5" class="relref">Section 5.5</a> of [<a href="#RFC8827" class="xref">RFC8827</a>]</span>.<a href="#section-13-3" class="pilcrow">¶</a></p>
<p id="section-13-4">RTCP packets convey a Canonical Name (CNAME) identifier that is used
      to associate RTP packet streams that need to be synchronized across
      related RTP sessions. Inappropriate choice of CNAME values can be a
      privacy concern, since long-term persistent CNAME identifiers can be
      used to track users across multiple WebRTC calls. <a href="#sec-cname" class="xref">Section 4.9</a> of this memo mandates generation of
      short-term persistent RTCP CNAMES, as specified in RFC 7022, resulting in
      untraceable CNAME values that alleviate this risk.<a href="#section-13-4" class="pilcrow">¶</a></p>
<p id="section-13-5">Some potential denial-of-service attacks exist if the RTCP reporting
      interval is configured to an inappropriate value. This could be done by
      configuring the RTCP bandwidth fraction to an excessively large or small
      value using the SDP "b=RR:" or "b=RS:" lines <span>[<a href="#RFC3556" class="xref">RFC3556</a>]</span> or some similar mechanism, or by choosing an
      excessively large or small value for the RTP/AVPF minimal
      receiver report interval (if using SDP, this is the
      "a=rtcp-fb:... trr-int"
      parameter) <span>[<a href="#RFC4585" class="xref">RFC4585</a>]</span>. The risks are as
      follows:<a href="#section-13-5" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-13-6">
        <li id="section-13-6.1">the RTCP bandwidth could be configured to make the regular
          reporting interval so large that effective congestion control cannot
          be maintained, potentially leading to denial of service due to
          congestion caused by the media traffic;<a href="#section-13-6.1" class="pilcrow">¶</a>
</li>
        <li id="section-13-6.2">the RTCP interval could be configured to a very small value,
          causing endpoints to generate high-rate RTCP traffic, potentially
          leading to denial of service due to the RTCP traffic not being
          congestion controlled; and<a href="#section-13-6.2" class="pilcrow">¶</a>
</li>
        <li id="section-13-6.3">RTCP parameters could be configured differently for each
          endpoint, with some of the endpoints using a large reporting
          interval and some using a smaller interval, leading to denial of
          service due to premature participant timeouts due to mismatched
          timeout periods that are based on the reporting interval. This is a
          particular concern if endpoints use a small but nonzero value for
          the RTP/AVPF minimal receiver report interval (trr-int) <span>[<a href="#RFC4585" class="xref">RFC4585</a>]</span>, as discussed in 
        <span><a href="https://www.rfc-editor.org/rfc/rfc8108#section-6.1" class="relref">Section 6.1</a> of [<a href="#RFC8108" class="xref">RFC8108</a>]</span>.<a href="#section-13-6.3" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-13-7">Premature participant timeout can be avoided by using the fixed
      (nonreduced) minimum interval when calculating the participant timeout
      (see <a href="#sec-rtp-rtcp" class="xref">Section 4.1</a> of this memo and 
      <span><a href="https://www.rfc-editor.org/rfc/rfc8108#section-7.1.2" class="relref">Section 7.1.2</a> of [<a href="#RFC8108" class="xref">RFC8108</a>]</span>). To address
      the other concerns, endpoints <span class="bcp14">SHOULD</span> ignore parameters that configure
      the RTCP reporting interval to be significantly longer than the default
      five-second interval specified in <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span> (unless
      the media data rate is so low that the longer reporting interval roughly
      corresponds to 5% of the media data rate), or that configure the RTCP
      reporting interval small enough that the RTCP bandwidth would exceed the
      media bandwidth.<a href="#section-13-7" class="pilcrow">¶</a></p>
<p id="section-13-8">The guidelines in <span>[<a href="#RFC6562" class="xref">RFC6562</a>]</span> apply when using
      variable bitrate (VBR) audio codecs such as Opus (see <a href="#sec.codecs" class="xref">Section 4.3</a> for discussion of mandated audio codecs).
      The guidelines in <span>[<a href="#RFC6562" class="xref">RFC6562</a>]</span> also apply, but are of
      lesser importance, when using the client-to-mixer audio level header
      extensions (<a href="#sec-client-to-mixer" class="xref">Section 5.2.2</a>) or the
      mixer-to-client audio level header extensions (<a href="#sec-mixer-to-client" class="xref">Section 5.2.3</a>). The use of the encryption of the
      header extensions are <span class="bcp14">RECOMMENDED</span>, unless there are known reasons, like
      RTP middleboxes performing voice-activity-based source selection or
      third-party monitoring that will greatly benefit from the information,
      and this has been expressed using API or signaling. If further evidence
      is produced to show that information leakage is significant from
      audio-level indications, then use of encryption needs to be mandated at
      that time.<a href="#section-13-8" class="pilcrow">¶</a></p>
<p id="section-13-9">In multiparty communication scenarios using RTP middleboxes, a lot
      of trust is placed on these middleboxes to preserve the session's
      security. The middlebox needs to maintain confidentiality and integrity
      and perform source authentication. As discussed in <a href="#sec.multiple-flows" class="xref">Section 12.1.1</a>, the middlebox can perform checks
      that prevent any endpoint participating in a conference from impersonating
      another. Some additional security considerations regarding multiparty
      topologies can be found in <span>[<a href="#RFC7667" class="xref">RFC7667</a>]</span>.<a href="#section-13-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-iana">
<section id="section-14">
      <h2 id="name-iana-considerations">
<a href="#section-14" class="section-number selfRef">14. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-14-1">This document has no IANA actions.<a href="#section-14-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-15">
      <h2 id="name-references">
<a href="#section-15" class="section-number selfRef">15. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-15.1">
        <h3 id="name-normative-references">
<a href="#section-15.1" class="section-number selfRef">15.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<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="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="RFC3556">[RFC3556]</dt>
        <dd>
<span class="refAuthor">Casner, S.</span>, <span class="refTitle">"Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth"</span>, <span class="seriesInfo">RFC 3556</span>, <span class="seriesInfo">DOI 10.17487/RFC3556</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3556">https://www.rfc-editor.org/info/rfc3556</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="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="RFC4588">[RFC4588]</dt>
        <dd>
<span class="refAuthor">Rey, J.</span><span class="refAuthor">, Leon, D.</span><span class="refAuthor">, Miyazaki, A.</span><span class="refAuthor">, Varsa, V.</span><span class="refAuthor">, and R. Hakenberg</span>, <span class="refTitle">"RTP Retransmission Payload Format"</span>, <span class="seriesInfo">RFC 4588</span>, <span class="seriesInfo">DOI 10.17487/RFC4588</span>, <time datetime="2006-07" class="refDate">July 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4588">https://www.rfc-editor.org/info/rfc4588</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4961">[RFC4961]</dt>
        <dd>
<span class="refAuthor">Wing, D.</span>, <span class="refTitle">"Symmetric RTP / RTP Control Protocol (RTCP)"</span>, <span class="seriesInfo">BCP 131</span>, <span class="seriesInfo">RFC 4961</span>, <span class="seriesInfo">DOI 10.17487/RFC4961</span>, <time datetime="2007-07" class="refDate">July 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4961">https://www.rfc-editor.org/info/rfc4961</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5104">[RFC5104]</dt>
        <dd>
<span class="refAuthor">Wenger, S.</span><span class="refAuthor">, Chandra, U.</span><span class="refAuthor">, Westerlund, M.</span><span class="refAuthor">, and B. Burman</span>, <span class="refTitle">"Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"</span>, <span class="seriesInfo">RFC 5104</span>, <span class="seriesInfo">DOI 10.17487/RFC5104</span>, <time datetime="2008-02" class="refDate">February 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5104">https://www.rfc-editor.org/info/rfc5104</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="RFC5506">[RFC5506]</dt>
        <dd>
<span class="refAuthor">Johansson, I.</span><span class="refAuthor"> and M. Westerlund</span>, <span class="refTitle">"Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences"</span>, <span class="seriesInfo">RFC 5506</span>, <span class="seriesInfo">DOI 10.17487/RFC5506</span>, <time datetime="2009-04" class="refDate">April 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5506">https://www.rfc-editor.org/info/rfc5506</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5761">[RFC5761]</dt>
        <dd>
<span class="refAuthor">Perkins, C.</span><span class="refAuthor"> and M. Westerlund</span>, <span class="refTitle">"Multiplexing RTP Data and Control Packets on a Single Port"</span>, <span class="seriesInfo">RFC 5761</span>, <span class="seriesInfo">DOI 10.17487/RFC5761</span>, <time datetime="2010-04" class="refDate">April 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5761">https://www.rfc-editor.org/info/rfc5761</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5764">[RFC5764]</dt>
        <dd>
<span class="refAuthor">McGrew, D.</span><span class="refAuthor"> and E. Rescorla</span>, <span class="refTitle">"Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)"</span>, <span class="seriesInfo">RFC 5764</span>, <span class="seriesInfo">DOI 10.17487/RFC5764</span>, <time datetime="2010-05" class="refDate">May 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5764">https://www.rfc-editor.org/info/rfc5764</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6051">[RFC6051]</dt>
        <dd>
<span class="refAuthor">Perkins, C.</span><span class="refAuthor"> and T. Schierl</span>, <span class="refTitle">"Rapid Synchronisation of RTP Flows"</span>, <span class="seriesInfo">RFC 6051</span>, <span class="seriesInfo">DOI 10.17487/RFC6051</span>, <time datetime="2010-11" class="refDate">November 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6051">https://www.rfc-editor.org/info/rfc6051</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6464">[RFC6464]</dt>
        <dd>
<span class="refAuthor">Lennox, J., Ed.</span><span class="refAuthor">, Ivov, E.</span><span class="refAuthor">, and E. Marocco</span>, <span class="refTitle">"A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication"</span>, <span class="seriesInfo">RFC 6464</span>, <span class="seriesInfo">DOI 10.17487/RFC6464</span>, <time datetime="2011-12" class="refDate">December 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6464">https://www.rfc-editor.org/info/rfc6464</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6465">[RFC6465]</dt>
        <dd>
<span class="refAuthor">Ivov, E., Ed.</span><span class="refAuthor">, Marocco, E., Ed.</span><span class="refAuthor">, and J. Lennox</span>, <span class="refTitle">"A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication"</span>, <span class="seriesInfo">RFC 6465</span>, <span class="seriesInfo">DOI 10.17487/RFC6465</span>, <time datetime="2011-12" class="refDate">December 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6465">https://www.rfc-editor.org/info/rfc6465</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="RFC6904">[RFC6904]</dt>
        <dd>
<span class="refAuthor">Lennox, J.</span>, <span class="refTitle">"Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)"</span>, <span class="seriesInfo">RFC 6904</span>, <span class="seriesInfo">DOI 10.17487/RFC6904</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6904">https://www.rfc-editor.org/info/rfc6904</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7007">[RFC7007]</dt>
        <dd>
<span class="refAuthor">Terriberry, T.</span>, <span class="refTitle">"Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)"</span>, <span class="seriesInfo">RFC 7007</span>, <span class="seriesInfo">DOI 10.17487/RFC7007</span>, <time datetime="2013-08" class="refDate">August 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7007">https://www.rfc-editor.org/info/rfc7007</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7022">[RFC7022]</dt>
        <dd>
<span class="refAuthor">Begen, A.</span><span class="refAuthor">, Perkins, C.</span><span class="refAuthor">, Wing, D.</span><span class="refAuthor">, and E. Rescorla</span>, <span class="refTitle">"Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)"</span>, <span class="seriesInfo">RFC 7022</span>, <span class="seriesInfo">DOI 10.17487/RFC7022</span>, <time datetime="2013-09" class="refDate">September 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7022">https://www.rfc-editor.org/info/rfc7022</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7160">[RFC7160]</dt>
        <dd>
<span class="refAuthor">Petit-Huguenin, M.</span><span class="refAuthor"> and G. Zorn, Ed.</span>, <span class="refTitle">"Support for Multiple Clock Rates in an RTP Session"</span>, <span class="seriesInfo">RFC 7160</span>, <span class="seriesInfo">DOI 10.17487/RFC7160</span>, <time datetime="2014-04" class="refDate">April 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7160">https://www.rfc-editor.org/info/rfc7160</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7164">[RFC7164]</dt>
        <dd>
<span class="refAuthor">Gross, K.</span><span class="refAuthor"> and R. Brandenburg</span>, <span class="refTitle">"RTP and Leap Seconds"</span>, <span class="seriesInfo">RFC 7164</span>, <span class="seriesInfo">DOI 10.17487/RFC7164</span>, <time datetime="2014-03" class="refDate">March 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7164">https://www.rfc-editor.org/info/rfc7164</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7742">[RFC7742]</dt>
        <dd>
<span class="refAuthor">Roach, A.B.</span>, <span class="refTitle">"WebRTC Video Processing and Codec Requirements"</span>, <span class="seriesInfo">RFC 7742</span>, <span class="seriesInfo">DOI 10.17487/RFC7742</span>, <time datetime="2016-03" class="refDate">March 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7742">https://www.rfc-editor.org/info/rfc7742</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7874">[RFC7874]</dt>
        <dd>
<span class="refAuthor">Valin, JM.</span><span class="refAuthor"> and C. Bran</span>, <span class="refTitle">"WebRTC Audio Codec and Processing Requirements"</span>, <span class="seriesInfo">RFC 7874</span>, <span class="seriesInfo">DOI 10.17487/RFC7874</span>, <time datetime="2016-05" class="refDate">May 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7874">https://www.rfc-editor.org/info/rfc7874</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="RFC8108">[RFC8108]</dt>
        <dd>
<span class="refAuthor">Lennox, J.</span><span class="refAuthor">, Westerlund, M.</span><span class="refAuthor">, Wu, Q.</span><span class="refAuthor">, and C. Perkins</span>, <span class="refTitle">"Sending Multiple RTP Streams in a Single RTP Session"</span>, <span class="seriesInfo">RFC 8108</span>, <span class="seriesInfo">DOI 10.17487/RFC8108</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8108">https://www.rfc-editor.org/info/rfc8108</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="RFC8285">[RFC8285]</dt>
        <dd>
<span class="refAuthor">Singer, D.</span><span class="refAuthor">, Desineni, H.</span><span class="refAuthor">, and R. Even, Ed.</span>, <span class="refTitle">"A General Mechanism for RTP Header Extensions"</span>, <span class="seriesInfo">RFC 8285</span>, <span class="seriesInfo">DOI 10.17487/RFC8285</span>, <time datetime="2017-10" class="refDate">October 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8285">https://www.rfc-editor.org/info/rfc8285</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8825">[RFC8825]</dt>
        <dd>
<span class="refAuthor">Alvestrand, H.</span>, <span class="refTitle">"Overview: Real-Time Protocols for Browser-Based Applications"</span>, <span class="seriesInfo">RFC 8825</span>, <span class="seriesInfo">DOI 10.17487/RFC8825</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8825">https://www.rfc-editor.org/info/rfc8825</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8826">[RFC8826]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"Security Considerations for WebRTC"</span>, <span class="seriesInfo">RFC 8826</span>, <span class="seriesInfo">DOI 10.17487/RFC8826</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8826">https://www.rfc-editor.org/info/rfc8826</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8827">[RFC8827]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"WebRTC Security Architecture"</span>, <span class="seriesInfo">RFC 8827</span>, <span class="seriesInfo">DOI 10.17487/RFC8827</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8827">https://www.rfc-editor.org/info/rfc8827</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8843">[RFC8843]</dt>
        <dd>
<span class="refAuthor">Holmberg, C.</span><span class="refAuthor">, Alvestrand, H.</span><span class="refAuthor">, and C. Jennings</span>, <span class="refTitle">"Negotiating Media Multiplexing Using the Session Description Protocol (SDP)"</span>, <span class="seriesInfo">RFC 8843</span>, <span class="seriesInfo">DOI 10.17487/RFC8843</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8843">https://www.rfc-editor.org/info/rfc8843</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8854">[RFC8854]</dt>
        <dd>
<span class="refAuthor">Uberti, J.</span>, <span class="refTitle">"WebRTC Forward Error Correction Requirements"</span>, <span class="seriesInfo">RFC 8854</span>, <span class="seriesInfo">DOI 10.17487/RFC8854</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8854">https://www.rfc-editor.org/info/rfc8854</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8858">[RFC8858]</dt>
        <dd>
<span class="refAuthor">Holmberg, C.</span>, <span class="refTitle">"Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)"</span>, <span class="seriesInfo">RFC 8858</span>, <span class="seriesInfo">DOI 10.17487/RFC8858</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8858">https://www.rfc-editor.org/info/rfc8858</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8860">[RFC8860]</dt>
        <dd>
<span class="refAuthor">Westerlund, M.</span><span class="refAuthor">, Perkins, C.</span><span class="refAuthor">, and J. Lennox</span>, <span class="refTitle">"Sending Multiple Types of Media in a Single RTP Session"</span>, <span class="seriesInfo">RFC 8860</span>, <span class="seriesInfo">DOI 10.17487/RFC8860</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8860">https://www.rfc-editor.org/info/rfc8860</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8861">[RFC8861]</dt>
        <dd>
<span class="refAuthor">Lennox, J.</span><span class="refAuthor">, Westerlund, M.</span><span class="refAuthor">, Wu, Q.</span><span class="refAuthor">, and C. Perkins</span>, <span class="refTitle">"Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback"</span>, <span class="seriesInfo">RFC 8861</span>, <span class="seriesInfo">DOI 10.17487/RFC8861</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8861">https://www.rfc-editor.org/info/rfc8861</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="W3C.WD-mediacapture-streams">[W3C.WD-mediacapture-streams]</dt>
        <dd>
<span class="refAuthor">Jennings, C.</span><span class="refAuthor">, Aboba, B.</span><span class="refAuthor">, Bruaroey, J-I.</span><span class="refAuthor">, and H. Boström</span>, <span class="refTitle">"Media Capture and Streams"</span>, <span class="refContent">W3C Candidate Recommendation</span>, <span>&lt;<a href="https://www.w3.org/TR/mediacapture-streams/">https://www.w3.org/TR/mediacapture-streams/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="W3C.WebRTC">[W3C.WebRTC]</dt>
      <dd>
<span class="refAuthor">Jennings, C.</span><span class="refAuthor">, Boström, H.</span><span class="refAuthor">, and J-I. Bruaroey</span>, <span class="refTitle">"WebRTC 1.0: Real-time Communication Between Browsers"</span>, <span class="refContent">W3C Proposed Recommendation</span>, <span>&lt;<a href="https://www.w3.org/TR/webrtc/">https://www.w3.org/TR/webrtc/</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-15.2">
        <h3 id="name-informative-references">
<a href="#section-15.2" class="section-number selfRef">15.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC3611">[RFC3611]</dt>
        <dd>
<span class="refAuthor">Friedman, T., Ed.</span><span class="refAuthor">, Caceres, R., Ed.</span><span class="refAuthor">, and A. Clark, Ed.</span>, <span class="refTitle">"RTP Control Protocol Extended Reports (RTCP XR)"</span>, <span class="seriesInfo">RFC 3611</span>, <span class="seriesInfo">DOI 10.17487/RFC3611</span>, <time datetime="2003-11" class="refDate">November 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3611">https://www.rfc-editor.org/info/rfc3611</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4383">[RFC4383]</dt>
        <dd>
<span class="refAuthor">Baugher, M.</span><span class="refAuthor"> and E. Carrara</span>, <span class="refTitle">"The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)"</span>, <span class="seriesInfo">RFC 4383</span>, <span class="seriesInfo">DOI 10.17487/RFC4383</span>, <time datetime="2006-02" class="refDate">February 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4383">https://www.rfc-editor.org/info/rfc4383</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5576">[RFC5576]</dt>
        <dd>
<span class="refAuthor">Lennox, J.</span><span class="refAuthor">, Ott, J.</span><span class="refAuthor">, and T. Schierl</span>, <span class="refTitle">"Source-Specific Media Attributes in the Session Description Protocol (SDP)"</span>, <span class="seriesInfo">RFC 5576</span>, <span class="seriesInfo">DOI 10.17487/RFC5576</span>, <time datetime="2009-06" class="refDate">June 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5576">https://www.rfc-editor.org/info/rfc5576</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5968">[RFC5968]</dt>
        <dd>
<span class="refAuthor">Ott, J.</span><span class="refAuthor"> and C. Perkins</span>, <span class="refTitle">"Guidelines for Extending the RTP Control Protocol (RTCP)"</span>, <span class="seriesInfo">RFC 5968</span>, <span class="seriesInfo">DOI 10.17487/RFC5968</span>, <time datetime="2010-09" class="refDate">September 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5968">https://www.rfc-editor.org/info/rfc5968</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6263">[RFC6263]</dt>
        <dd>
<span class="refAuthor">Marjou, X.</span><span class="refAuthor"> and A. Sollaud</span>, <span class="refTitle">"Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows"</span>, <span class="seriesInfo">RFC 6263</span>, <span class="seriesInfo">DOI 10.17487/RFC6263</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6263">https://www.rfc-editor.org/info/rfc6263</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6792">[RFC6792]</dt>
        <dd>
<span class="refAuthor">Wu, Q., Ed.</span><span class="refAuthor">, Hunt, G.</span><span class="refAuthor">, and P. Arden</span>, <span class="refTitle">"Guidelines for Use of the RTP Monitoring Framework"</span>, <span class="seriesInfo">RFC 6792</span>, <span class="seriesInfo">DOI 10.17487/RFC6792</span>, <time datetime="2012-11" class="refDate">November 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6792">https://www.rfc-editor.org/info/rfc6792</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7478">[RFC7478]</dt>
        <dd>
<span class="refAuthor">Holmberg, C.</span><span class="refAuthor">, Hakansson, S.</span><span class="refAuthor">, and G. Eriksson</span>, <span class="refTitle">"Web Real-Time Communication Use Cases and Requirements"</span>, <span class="seriesInfo">RFC 7478</span>, <span class="seriesInfo">DOI 10.17487/RFC7478</span>, <time datetime="2015-03" class="refDate">March 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7478">https://www.rfc-editor.org/info/rfc7478</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7656">[RFC7656]</dt>
        <dd>
<span class="refAuthor">Lennox, J.</span><span class="refAuthor">, Gross, K.</span><span class="refAuthor">, Nandakumar, S.</span><span class="refAuthor">, Salgueiro, G.</span><span class="refAuthor">, and B. Burman, Ed.</span>, <span class="refTitle">"A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources"</span>, <span class="seriesInfo">RFC 7656</span>, <span class="seriesInfo">DOI 10.17487/RFC7656</span>, <time datetime="2015-11" class="refDate">November 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7656">https://www.rfc-editor.org/info/rfc7656</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7657">[RFC7657]</dt>
        <dd>
<span class="refAuthor">Black, D., Ed.</span><span class="refAuthor"> and P. Jones</span>, <span class="refTitle">"Differentiated Services (Diffserv) and Real-Time Communication"</span>, <span class="seriesInfo">RFC 7657</span>, <span class="seriesInfo">DOI 10.17487/RFC7657</span>, <time datetime="2015-11" class="refDate">November 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7657">https://www.rfc-editor.org/info/rfc7657</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7667">[RFC7667]</dt>
        <dd>
<span class="refAuthor">Westerlund, M.</span><span class="refAuthor"> and S. Wenger</span>, <span class="refTitle">"RTP Topologies"</span>, <span class="seriesInfo">RFC 7667</span>, <span class="seriesInfo">DOI 10.17487/RFC7667</span>, <time datetime="2015-11" class="refDate">November 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7667">https://www.rfc-editor.org/info/rfc7667</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="RFC8445">[RFC8445]</dt>
        <dd>
<span class="refAuthor">Keranen, A.</span><span class="refAuthor">, Holmberg, C.</span><span class="refAuthor">, and J. Rosenberg</span>, <span class="refTitle">"Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal"</span>, <span class="seriesInfo">RFC 8445</span>, <span class="seriesInfo">DOI 10.17487/RFC8445</span>, <time datetime="2018-07" class="refDate">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8445">https://www.rfc-editor.org/info/rfc8445</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8829">[RFC8829]</dt>
        <dd>
<span class="refAuthor">Uberti, J.</span><span class="refAuthor">, Jennings, C.</span><span class="refAuthor">, and E. Rescorla, Ed.</span>, <span class="refTitle">"JavaScript Session Establishment Protocol (JSEP)"</span>, <span class="seriesInfo">RFC 8829</span>, <span class="seriesInfo">DOI 10.17487/RFC8829</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8829">https://www.rfc-editor.org/info/rfc8829</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8830">[RFC8830]</dt>
        <dd>
<span class="refAuthor">Alvestrand, H.</span>, <span class="refTitle">"WebRTC MediaStream Identification in the Session Description Protocol"</span>, <span class="seriesInfo">RFC 8830</span>, <span class="seriesInfo">DOI 10.17487/RFC8830</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8830">https://www.rfc-editor.org/info/rfc8830</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8836">[RFC8836]</dt>
        <dd>
<span class="refAuthor">Jesup, R.</span><span class="refAuthor"> and Z. Sarker, Ed.</span>, <span class="refTitle">"Congestion Control Requirements for Interactive Real-Time Media"</span>, <span class="seriesInfo">RFC 8836</span>, <span class="seriesInfo">DOI 10.17487/RFC8836</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8836">https://www.rfc-editor.org/info/rfc8836</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8837">[RFC8837]</dt>
        <dd>
<span class="refAuthor">Jones, P.</span><span class="refAuthor">, Dhesikan, S.</span><span class="refAuthor">, Jennings, C.</span><span class="refAuthor">, and D. Druta</span>, <span class="refTitle">"Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS"</span>, <span class="seriesInfo">RFC 8837</span>, <span class="seriesInfo">DOI 10.17487/RFC8837</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8837">https://www.rfc-editor.org/info/rfc8837</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8872">[RFC8872]</dt>
      <dd>
<span class="refAuthor">Westerlund, M.</span><span class="refAuthor">, Burman, B.</span><span class="refAuthor">, Perkins, C.</span><span class="refAuthor">, Alvestrand, H.</span><span class="refAuthor">, and R. Even</span>, <span class="refTitle">"Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams"</span>, <span class="seriesInfo">RFC 8872</span>, <span class="seriesInfo">DOI 10.17487/RFC8872</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8872">https://www.rfc-editor.org/info/rfc8872</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="Acknowledgements">
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">The authors would like to thank <span class="contact-name">Bernard Aboba</span>,
<span class="contact-name">Harald Alvestrand</span>, <span class="contact-name">Cary Bran</span>,
<span class="contact-name">Ben Campbell</span>, <span class="contact-name">Alissa Cooper</span>,
<span class="contact-name">Spencer Dawkins</span>, <span class="contact-name">Charles Eckel</span>,
<span class="contact-name">Alex Eleftheriadis</span>, <span class="contact-name">Christian Groves</span>, <span class="contact-name">Chris Inacio</span>, <span class="contact-name">Cullen Jennings</span>, <span class="contact-name">Olle Johansson</span>, <span class="contact-name">Suhas Nandakumar</span>, <span class="contact-name">Dan Romascanu</span>, <span class="contact-name">Jim Spring</span>, <span class="contact-name">Martin Thomson</span>, and the other members of the
IETF RTCWEB working group for their valuable feedback.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <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">Colin Perkins</span></div>
<div dir="auto" class="left"><span class="org">University of Glasgow</span></div>
<div dir="auto" class="left"><span class="street-address">School of Computing Science</span></div>
<div dir="auto" class="left"><span class="locality">Glasgow</span></div>
<div dir="auto" class="left"><span class="postal-code">G12 8QQ</span></div>
<div dir="auto" class="left"><span class="country-name">United Kingdom</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:csp@csperkins.org" class="email">csp@csperkins.org</a>
</div>
<div class="url">
<span>URI:</span>
<a href="https://csperkins.org/" class="url">https://csperkins.org/</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Magnus Westerlund</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div dir="auto" class="left"><span class="street-address">Torshamnsgatan 23</span></div>
<div dir="auto" class="left">SE-<span class="postal-code">164 80</span> <span class="locality">Kista</span>
</div>
<div dir="auto" class="left"><span class="country-name">Sweden</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:magnus.westerlund@ericsson.com" class="email">magnus.westerlund@ericsson.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jörg Ott</span></div>
<div dir="auto" class="left"><span class="org">Technical University Munich</span></div>
<div dir="auto" class="left"><span class="extended-address">Department of Informatics<br>Chair of Connected Mobility</span></div>
<div dir="auto" class="left"><span class="street-address">Boltzmannstrasse 3</span></div>
<div dir="auto" class="left">
<span class="postal-code">85748</span> <span class="locality">Garching</span>
</div>
<div dir="auto" class="left"><span class="country-name">Germany</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ott@in.tum.de" class="email">ott@in.tum.de</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>