File: rfc8840.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 (3737 lines) | stat: -rw-r--r-- 188,886 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 8840: A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)</title>
<meta content="Emil Ivov" name="author">
<meta content="Thomas Stach" name="author">
<meta content="Enrico Marocco" name="author">
<meta content="Christer Holmberg" name="author">
<meta content='
       
        The Interactive Connectivity Establishment (ICE) protocol
        describes a Network Address Translator (NAT) traversal mechanism
        for UDP-based multimedia sessions established with the
        Offer/Answer model. The ICE extension for Incremental
        Provisioning of Candidates (Trickle ICE) defines a mechanism
        that allows ICE Agents to shorten session establishment delays
        by making the candidate gathering and connectivity checking
        phases of ICE non-blocking and by executing them in parallel.
       
       
        This document defines usage semantics for Trickle ICE with the Session
        Initiation Protocol (SIP).  The document also defines a new SIP Info
        Package to support this usage together with the corresponding media
        type.  Additionally, a new Session Description Protocol (SDP)
        "end-of-candidates" attribute and a new SIP option tag "trickle-ice"
        are defined.
       
    ' name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="8840" 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="rfc8840.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/rfc8840" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip-18" 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 8840</td>
<td class="center">Trickle ICE for SIP</td>
<td class="right">January 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Ivov, 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/rfc8840" class="eref">8840</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">E. Ivov</div>
<div class="org">Jitsi</div>
</div>
<div class="author">
      <div class="author-name">T. Stach</div>
<div class="org">Unaffiliated</div>
</div>
<div class="author">
      <div class="author-name">E. Marocco</div>
<div class="org">Telecom Italia</div>
</div>
<div class="author">
      <div class="author-name">C. Holmberg</div>
<div class="org">Ericsson</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8840</h1>
<h1 id="title">A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
        The Interactive Connectivity Establishment (ICE) protocol
        describes a Network Address Translator (NAT) traversal mechanism
        for UDP-based multimedia sessions established with the
        Offer/Answer model. The ICE extension for Incremental
        Provisioning of Candidates (Trickle ICE) defines a mechanism
        that allows ICE Agents to shorten session establishment delays
        by making the candidate gathering and connectivity checking
        phases of ICE non-blocking and by executing them in parallel.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">
        This document defines usage semantics for Trickle ICE with the Session
        Initiation Protocol (SIP).  The document also defines a new SIP Info
        Package to support this usage together with the corresponding media
        type.  Additionally, a new Session Description Protocol (SDP)
        "end-of-candidates" attribute and a new SIP option tag "trickle-ice"
        are defined.<a href="#section-abstract-2" 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/rfc8840">https://www.rfc-editor.org/info/rfc8840</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 toc ulEmpty">
<li class="compact toc ulEmpty" 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 toc ulEmpty" 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-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-protocol-overview" class="xref">Protocol Overview</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-discovery-issues" class="xref">Discovery Issues</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-relationship-with-the-offer" class="xref">Relationship with the Offer/Answer Model</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" 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-incremental-signaling-of-ic" class="xref">Incremental Signaling of ICE Candidates</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" 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-initial-offer-answer-exchan" class="xref">Initial Offer/Answer Exchange</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.1.2.1">
                    <p id="section-toc.1-1.4.2.1.2.1.1"><a href="#section-4.1.1" class="xref">4.1.1</a>.  <a href="#name-sending-the-initial-offer" class="xref">Sending the Initial Offer</a><a href="#section-toc.1-1.4.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.1.2.2">
                    <p id="section-toc.1-1.4.2.1.2.2.1"><a href="#section-4.1.2" class="xref">4.1.2</a>.  <a href="#name-receiving-the-initial-offer" class="xref">Receiving the Initial Offer</a><a href="#section-toc.1-1.4.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.1.2.3">
                    <p id="section-toc.1-1.4.2.1.2.3.1"><a href="#section-4.1.3" class="xref">4.1.3</a>.  <a href="#name-sending-the-initial-answer" class="xref">Sending the Initial Answer</a><a href="#section-toc.1-1.4.2.1.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.1.2.4">
                    <p id="section-toc.1-1.4.2.1.2.4.1"><a href="#section-4.1.4" class="xref">4.1.4</a>.  <a href="#name-receiving-the-initial-answe" class="xref">Receiving the Initial Answer</a><a href="#section-toc.1-1.4.2.1.2.4.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" 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-subsequent-offer-answer-exc" class="xref">Subsequent Offer/Answer Exchanges</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" 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-establishing-the-dialog" class="xref">Establishing the Dialog</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.3.2.1">
                    <p id="section-toc.1-1.4.2.3.2.1.1"><a href="#section-4.3.1" class="xref">4.3.1</a>.  <a href="#name-establishing-dialog-state-t" class="xref">Establishing Dialog State through Reliable Offer/Answer Delivery</a><a href="#section-toc.1-1.4.2.3.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.3.2.2">
                    <p id="section-toc.1-1.4.2.3.2.2.1"><a href="#section-4.3.2" class="xref">4.3.2</a>.  <a href="#name-establishing-dialog-state-th" class="xref">Establishing Dialog State through Unreliable Offer/Answer Delivery</a><a href="#section-toc.1-1.4.2.3.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.3.2.3">
                    <p id="section-toc.1-1.4.2.3.2.3.1"><a href="#section-4.3.3" class="xref">4.3.3</a>.  <a href="#name-initiating-trickle-ice-with" class="xref">Initiating Trickle ICE without an SDP Answer</a><a href="#section-toc.1-1.4.2.3.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" 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-delivering-candidates-in-in" class="xref">Delivering Candidates in INFO Requests</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" 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-initial-discovery-of-trickl" class="xref">Initial Discovery of Trickle ICE Support</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" 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-provisioning-support-for-tr" class="xref">Provisioning Support for Trickle ICE</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" 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-trickle-ice-discovery-with-" class="xref">Trickle ICE Discovery with Globally Routable User Agent URIs (GRUUs)</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-fall-back-to-half-trickle" class="xref">Fall Back to Half Trickle</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" 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-considerations-for-rtp-and-" class="xref">Considerations for RTP and RTCP Multiplexing</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" 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-considerations-for-media-mu" class="xref">Considerations for Media Multiplexing</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" 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-sdp-end-of-candidates-attri" class="xref">SDP "end-of-candidates" Attribute</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-definition" class="xref">Definition</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-offer-answer-procedures" class="xref">Offer/Answer Procedures</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" 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-content-type-application-tr" class="xref">Content Type "application/trickle-ice-sdpfrag"</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-overall-description" class="xref">Overall Description</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-grammar" class="xref">Grammar</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" 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-info-package" class="xref">Info Package</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-rationale-why-info" class="xref">Rationale -- Why INFO?</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-overall-description-2" class="xref">Overall Description</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.3">
                <p id="section-toc.1-1.10.2.3.1"><a href="#section-10.3" class="xref">10.3</a>.  <a href="#name-applicability" class="xref">Applicability</a><a href="#section-toc.1-1.10.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.4">
                <p id="section-toc.1-1.10.2.4.1"><a href="#section-10.4" class="xref">10.4</a>.  <a href="#name-info-package-name" class="xref">Info Package Name</a><a href="#section-toc.1-1.10.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.5">
                <p id="section-toc.1-1.10.2.5.1"><a href="#section-10.5" class="xref">10.5</a>.  <a href="#name-info-package-parameters" class="xref">Info Package Parameters</a><a href="#section-toc.1-1.10.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.6">
                <p id="section-toc.1-1.10.2.6.1"><a href="#section-10.6" class="xref">10.6</a>.  <a href="#name-sip-option-tags" class="xref">SIP Option Tags</a><a href="#section-toc.1-1.10.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.7">
                <p id="section-toc.1-1.10.2.7.1"><a href="#section-10.7" class="xref">10.7</a>.  <a href="#name-info-request-body-parts" class="xref">INFO Request Body Parts</a><a href="#section-toc.1-1.10.2.7.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.8">
                <p id="section-toc.1-1.10.2.8.1"><a href="#section-10.8" class="xref">10.8</a>.  <a href="#name-info-package-usage-restrict" class="xref">Info Package Usage Restrictions</a><a href="#section-toc.1-1.10.2.8.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.9">
                <p id="section-toc.1-1.10.2.9.1"><a href="#section-10.9" class="xref">10.9</a>.  <a href="#name-rate-of-info-requests" class="xref">Rate of INFO Requests</a><a href="#section-toc.1-1.10.2.9.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.10">
                <p id="section-toc.1-1.10.2.10.1"><a href="#section-10.10" class="xref">10.10</a>. <a href="#name-info-package-security-consi" class="xref">Info Package Security Considerations</a><a href="#section-toc.1-1.10.2.10.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" 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-deployment-considerations" class="xref">Deployment Considerations</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" 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-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" 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-sdp-end-of-candidates-attrib" class="xref">SDP "end-of-candidates" Attribute</a><a href="#section-toc.1-1.12.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" 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-type-application-tric" class="xref">Media Type "application/trickle-ice-sdpfrag"</a><a href="#section-toc.1-1.12.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.12.2.3">
                <p id="section-toc.1-1.12.2.3.1"><a href="#section-12.3" class="xref">12.3</a>.  <a href="#name-sip-info-package-trickle-ic" class="xref">SIP Info Package "trickle-ice"</a><a href="#section-toc.1-1.12.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.12.2.4">
                <p id="section-toc.1-1.12.2.4.1"><a href="#section-12.4" class="xref">12.4</a>.  <a href="#name-sip-option-tag-trickle-ice" class="xref">SIP Option Tag "trickle-ice"</a><a href="#section-toc.1-1.12.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" 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 toc ulEmpty" 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-references" class="xref">References</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.1">
                <p id="section-toc.1-1.14.2.1.1"><a href="#section-14.1" class="xref">14.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.14.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.14.2.2">
                <p id="section-toc.1-1.14.2.2.1"><a href="#section-14.2" class="xref">14.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.14.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.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.16.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 Interactive Connectivity Establishment (ICE) protocol
        <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span> describes
        a mechanism for Network Address Translator (NAT) traversal
        that consists of three main phases.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
        During the first phase, an agent gathers a set of candidate
        transport addresses (source IP, port, and transport
        protocol).
        This is followed by a second phase
        where these candidates are sent to a
        remote agent within
        the Session Description Protocol (SDP) body of a SIP message.
        At the remote agent, the gathering procedure is repeated and
        candidates are sent to the first agent.
        Once the candidate information is available, a third phase
        starts in parallel where connectivity between all candidates
        in both sets is checked (connectivity checks).
        Once these phases
        have been completed, and only then, both agents can begin
        communication.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
        According to <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>,
        the three phases above happen consecutively, in a blocking way,
        which can introduce undesirable setup delay during session
        establishment.
        The Trickle ICE extension
        <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span> defines generic
        semantics required for these ICE phases to happen
        in a parallel, non-blocking way and hence speeds up session
        establishment.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
        This specification defines a usage of Trickle ICE with
        the Session Initiation Protocol (SIP)<span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span>.
        It describes how ICE
        candidates are to be exchanged incrementally using SIP INFO
        requests <span>[<a href="#RFC6086" class="xref">RFC6086</a>]</span>
        and how the Half Trickle and Full Trickle modes defined in
        <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span> are to be used by
        SIP User Agents (UAs) depending on their expectations for
        support of Trickle ICE by a remote agent.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">
        This document defines a new Info Package as specified in
        <span>[<a href="#RFC6086" class="xref">RFC6086</a>]</span> for use with Trickle ICE together
        with the corresponding media type,
        SDP attribute, and SIP option tag.<a href="#section-1-5" class="pilcrow">¶</a></p>
</section>
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">
   The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are
    to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span>
        <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals,
    as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">
        This specification makes use of terminology defined by the
        ICE protocol in
        <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span> and by its Trickle ICE extension in
        <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span>. It is assumed that
        the reader is familiar with the terminology from both documents.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">  <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span> also describes
         how ICE makes use of the
         Session Traversal Utilities for NAT (STUN) protocol
         <span>[<a href="#RFC5389" class="xref">RFC5389</a>]</span> and its extension
         Traversal Using Relays around NAT (TURN) <span>[<a href="#RFC5766" class="xref">RFC5766</a>]</span>.<a href="#section-2-3" class="pilcrow">¶</a></p>
</section>
<div id="overview">
<section id="section-3">
      <h2 id="name-protocol-overview">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-protocol-overview" class="section-name selfRef">Protocol Overview</a>
      </h2>
<p id="section-3-1">
        When using  ICE for SIP according to
        <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span>,
        the ICE candidates are exchanged solely via
        SDP Offer/Answer as per <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span>.
        This specification defines an additional mechanism
        where candidates can be exchanged using SIP INFO messages
        and a newly defined Info Package <span>[<a href="#RFC6086" class="xref">RFC6086</a>]</span>.
        This also allows ICE
        candidates to be sent in parallel to an ongoing Offer/Answer
        negotiation and/or after the completion of the Offer/Answer
        negotiation.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
        Typically, in cases where Trickle ICE is fully supported,
        the Offerer sends an INVITE request
        containing a subset of candidates.
        Once an early dialog is established,
        the Offerer can continue sending
        candidates in INFO requests within that dialog.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">
        Similarly, an Answerer can send
        ICE candidates using INFO requests within
        the dialog established by its 18x provisional response.
        <a href="#fig-intro-example" class="xref">Figure 1</a> shows such a sample
        exchange:<a href="#section-3-3" class="pilcrow">¶</a></p>
<span id="name-sample-trickle-ice-scenario"></span><div id="fig-intro-example">
<figure id="figure-1">
        <div class="artwork art-text alignLeft" id="section-3-4.1">
<pre>
   STUN/TURN                                                STUN/TURN
    Servers          Alice                      Bob          Servers
       |               |                         |                |
       |  STUN Bi.Req. |     INVITE (Offer)      |                |
       |&lt;--------------|------------------------&gt;|                |
       |               |      183 (Answer)       | TURN Alloc Req |
       | STUN Bi.Resp. |&lt;------------------------|---------------&gt;|
       |--------------&gt;|  INFO/OK (SRFLX Cand.)  |                |
       |               |------------------------&gt;| TURN Alloc Resp|
       |               |  INFO/OK (Relay Cand.)  |&lt;---------------|
       |               |&lt;------------------------|                |
       |               |                         |                |
       |               |  More Cands &amp; ConnChecks|                |
       |               |&lt;=======================&gt;|                |
       |               |                         |                |
       |               |          200 OK         |                |
       |               |&lt;------------------------|                |
       |               |            ACK          |                |
       |               |------------------------&gt;|                |
       |               |                         |                |
       |               |&lt;===== MEDIA FLOWS =====&gt;|                |
       |               |                         |                |

       Note: "SRFLX" denotes server-reflexive candidates</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-sample-trickle-ice-scenario" class="selfRef">Sample Trickle ICE Scenario with SIP</a>
        </figcaption></figure>
</div>
<div id="disco-issues">
<section id="section-3.1">
        <h3 id="name-discovery-issues">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-discovery-issues" class="section-name selfRef">Discovery Issues</a>
        </h3>
<p id="section-3.1-1">
          In order to benefit from Trickle ICE's full potential and
          reduce session establishment latency to a minimum, Trickle ICE
          Agents need to generate SDP Offers and Answers that contain
          incomplete and potentially empty sets of candidates. Such Offers
          and Answers can only be handled meaningfully by agents that
          actually support incremental candidate provisioning, which
          implies the need to confirm such support before  using
          it.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">
          Contrary to other protocols,
          where "in advance" capability
          discovery is widely implemented, the mechanisms that allow this
          for SIP (i.e., a combination of UA capabilities
          <span>[<a href="#RFC3840" class="xref">RFC3840</a>]</span> and Globally Routable User Agent URIs (GRUUs) <span>[<a href="#RFC5627" class="xref">RFC5627</a>]</span>)
          have only seen low levels of adoption.
          This presents an issue
          for Trickle ICE implementations as SIP UAs do not have an
          obvious means of verifying that their peer will support
          incremental candidate provisioning.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">
          The Half Trickle mode of operation defined in the Trickle
          ICE specification <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span>
          provides one way around this, by requiring the first Offer to
          contain a complete set of local ICE candidates
          and using only
          incremental provisioning of remote candidates
          for the rest of the session.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">
          While using Half Trickle does provide a working solution, it
          also comes at the price of increased latency. Therefore,
          <a href="#disco" class="xref">Section 5</a> makes several alternative
          suggestions that enable SIP UAs to engage in Full Trickle
          right from their first Offer: <a href="#disco-prov" class="xref">Section 5.1</a>
          discusses the use of online provisioning as a means of
          allowing the use of Trickle ICE for all endpoints in controlled
          environments. <a href="#disco-gruu" class="xref">Section 5.2</a> describes
          anticipatory discovery for implementations that actually do
          support GRUU and UA capabilities, and
          <a href="#half-full-trickle" class="xref">Section 5.3</a> discusses the implementation
          and use of Half Trickle by SIP UAs where none of the above
          are an option.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-3.2">
        <h3 id="name-relationship-with-the-offer">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-relationship-with-the-offer" class="section-name selfRef">Relationship with the Offer/Answer Model</a>
        </h3>
<p id="section-3.2-1">
          From the perspective of SIP middleboxes and proxies,
          the Offer/Answer exchange for
          Trickle ICE looks partly similar to the Offer/Answer exchange
          for regular ICE for SIP
          <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span>.
          However, in order to have the full picture of the candidate
          exchange, the newly introduced INFO messages
          need to be considered as well.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<span id="name-distinguishing-between-tric"></span><div id="fig-oa-and-trickle">
<figure id="figure-2">
          <div class="artwork art-text alignLeft" id="section-3.2-2.1">
<pre>
+-------------------------------+  +-------------------------------+
|   Alice      +--------------+ |  | +--------------+       Bob    |
|              | Offer/Answer | |  | | Offer/Answer |              |
| +--------+   |    Module    | |  | |    Module    |   +--------+ |
| |  ICE   |   +--------------+ |  | +--------------+   |  ICE   | |
| | Module |         |          |  |        |           | Module | |
| +--------+         |          |  |        |           +--------+ |
+-------------------------------+  +-------------------------------+
      |              |                      |                |
      |              |    INVITE (Offer)    |                |
      |              |---------------------&gt;|                |
      |              |     183 (Answer)     |                |
      |              |&lt;---------------------|                |
      |              |                      |                |
      |                                                      |
      |             SIP INFO (more candidates)               |
      |-----------------------------------------------------&gt;|
      |             SIP INFO (more candidates)               |
      |&lt;-----------------------------------------------------|
      |                                                      |
      |          STUN Binding Requests/Responses             |
      |-----------------------------------------------------&gt;|
      |          STUN Binding Requests/Responses             |
      |&lt;-----------------------------------------------------|
      |                                                      |</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-distinguishing-between-tric" class="selfRef">Distinguishing between Trickle ICE and Traditional Signaling</a>
          </figcaption></figure>
</div>
<p id="section-3.2-3">
          From an architectural viewpoint, as displayed in
          <a href="#fig-oa-and-trickle" class="xref">Figure 2</a>, exchanging candidates
          through SIP INFO requests could be represented as signaling
          between ICE modules and not between Offer/Answer modules of
          SIP UAs. Then, such INFO requests
          do not impact the state of the Offer/Answer transaction other
          than providing additional candidates.
          Consequently, INFO requests are not considered Offers or Answers.
          Nevertheless, candidates that have been exchanged
          using INFO requests
          <span class="bcp14">SHALL</span> be included in subsequent Offers or Answers.
          The version number in the "o=" line of that subsequent Offer
          needs to be incremented by 1 per the rules
          in <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span>.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="OAproc">
<section id="section-4">
      <h2 id="name-incremental-signaling-of-ic">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-incremental-signaling-of-ic" class="section-name selfRef">Incremental Signaling of ICE Candidates</a>
      </h2>
<p id="section-4-1">
        Trickle ICE Agents will exchange
        ICE descriptions compliant to
        <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span>
        via Offer/Answer procedures and/or INFO request bodies.
        This requires the following SIP-specific extensions:<a href="#section-4-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-4-2">
        <li id="section-4-2.1">
            Trickle ICE Agents <span class="bcp14">MUST</span> indicate support for Trickle ICE by
            including the SIP option-tag "trickle-ice" in a SIP Supported: header field
            within all SIP INVITE requests and  responses.<a href="#section-4-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.2">
            Trickle ICE Agents <span class="bcp14">MUST</span> indicate support for Trickle ICE by
            including the ice-option "trickle"
            within all SDP Offers and Answers in accordance to
            <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span>.<a href="#section-4-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.3">
          Trickle ICE Agents <span class="bcp14">MAY</span> include any number of ICE candidates,
          i.e., from zero to the complete set of candidates,
          in their initial Offer or Answer.
          If the complete candidate set is already included
          in the initial Offer, it is called Half Trickle.<a href="#section-4-2.3" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.4">
            Trickle ICE Agents <span class="bcp14">MAY</span> exchange additional ICE candidates using INFO requests
            within an existing INVITE dialog usage (including an early dialog)
            as specified in <span>[<a href="#RFC6086" class="xref">RFC6086</a>]</span>.
            The INFO requests carry an Info-Package: trickle-ice.
            Trickle ICE Agents <span class="bcp14">MUST</span> be prepared to receive INFO requests
            within that same dialog usage,
            containing additional candidates and/or
            an indication that trickling of such candidates has ended.<a href="#section-4-2.4" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.5">
            Trickle ICE Agents <span class="bcp14">MAY</span> exchange additional ICE candidates
            before the Answerer has sent the Answer provided that 
            an invite dialog usage is established at both Trickle ICE Agents.
            Note that in case of forking, multiple early dialogs may exist.<a href="#section-4-2.5" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-4-3">
         The following sections provide further details on how
         Trickle ICE Agents perform the initial Offer/Answer exchange
         (<a href="#InitialOA" class="xref">Section 4.1</a>),
         perform subsequent Offer/Answer exchanges
         (<a href="#subsOA" class="xref">Section 4.2</a>),
         and establish the INVITE dialog usage
         (<a href="#dialog-est" class="xref">Section 4.3</a>)
         such that they can incrementally trickle candidates
         (<a href="#info-sdp" class="xref">Section 4.4</a>).<a href="#section-4-3" class="pilcrow">¶</a></p>
<div id="InitialOA">
<section id="section-4.1">
        <h3 id="name-initial-offer-answer-exchan">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-initial-offer-answer-exchan" class="section-name selfRef">Initial Offer/Answer Exchange</a>
        </h3>
<div id="IniOS">
<section id="section-4.1.1">
          <h4 id="name-sending-the-initial-offer">
<a href="#section-4.1.1" class="section-number selfRef">4.1.1. </a><a href="#name-sending-the-initial-offer" class="section-name selfRef">Sending the Initial Offer</a>
          </h4>
<p id="section-4.1.1-1">
                 If the Offerer includes candidates in its initial Offer,
                 it <span class="bcp14">MUST</span> encode these candidates as specified in
                 <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span>.<a href="#section-4.1.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1.1-2">If the Offerer wants to send its initial Offer
                 before knowing any candidate for one or more media descriptions,
                 it <span class="bcp14">MUST</span> set the port to the default value  '9' for these media descriptions.
                 If the Offerer does not want to include the
                 host IP address in the corresponding "c="line,
                 e.g., due to privacy reasons,
                 it <span class="bcp14">SHOULD</span> include a default address in the "c="line,
                  which is set to the IPv4 address 0.0.0.0 or
                 to the IPv6 equivalent ::.<a href="#section-4.1.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1.1-3">
                 In this case, the Offerer obviously cannot know the 
  RTP Control Protocol (RTCP) transport address;
                 thus, it <span class="bcp14">MUST NOT</span> include the "rtcp" attribute <span>[<a href="#RFC3605" class="xref">RFC3605</a>]</span>.
                 This avoids potential ICE mismatch
                 (see <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span>) for the RTCP transport address.<a href="#section-4.1.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1.1-4">
                 If the Offerer wants to use RTCP multiplexing
                 <span>[<a href="#RFC5761" class="xref">RFC5761</a>]</span>
                 and/or exclusive RTCP multiplexing
                 <span>[<a href="#RFC8858" class="xref">RFC8858</a>]</span>,
                 it still will include the "rtcp-mux" and/or
                 "rctp-mux-only" attribute
                 in the initial Offer.<a href="#section-4.1.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1.1-5">
                 In any case, the Offerer <span class="bcp14">MUST</span> include
                 the "ice-options:trickle" attribute in accordance to
                <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span> and
                <span class="bcp14">MUST</span> include in each "m=" line a "mid" attribute
                in accordance to <span>[<a href="#RFC5888" class="xref">RFC5888</a>]</span>.

                The "mid" attribute identifies the "m=" line
                to which a candidate belongs and
                helps in case of multiple "m=" lines,
                when candidate gathering could occur in an order different
                from the order of the "m=" lines.<a href="#section-4.1.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IniOR">
<section id="section-4.1.2">
          <h4 id="name-receiving-the-initial-offer">
<a href="#section-4.1.2" class="section-number selfRef">4.1.2. </a><a href="#name-receiving-the-initial-offer" class="section-name selfRef">Receiving the Initial Offer</a>
          </h4>
<p id="section-4.1.2-1">
                 If the initial Offer included candidates,
                 the Answerer uses these candidates to start ICE processing
                 as specified in <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span>.<a href="#section-4.1.2-1" class="pilcrow">¶</a></p>
<p id="section-4.1.2-2">
                 If the initial Offer included the "ice-options:trickle" attribute,
                 the Answerer <span class="bcp14">MUST</span> be prepared for receiving trickled candidates later on.<a href="#section-4.1.2-2" class="pilcrow">¶</a></p>
<p id="section-4.1.2-3">
                 In case of a "m/c=" line with default values,
                 none of the eventually trickled candidates
                 will match the default destination.
                 This situation <span class="bcp14">MUST NOT</span> cause an ICE mismatch
                 (see <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span>).<a href="#section-4.1.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IniAS">
<section id="section-4.1.3">
          <h4 id="name-sending-the-initial-answer">
<a href="#section-4.1.3" class="section-number selfRef">4.1.3. </a><a href="#name-sending-the-initial-answer" class="section-name selfRef">Sending the Initial Answer</a>
          </h4>
<p id="section-4.1.3-1">
                 If the Answerer includes candidates in its initial Answer,
                 it <span class="bcp14">MUST</span> encode these candidates as specified in
                 <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span>.<a href="#section-4.1.3-1" class="pilcrow">¶</a></p>
<p id="section-4.1.3-2">If the Answerer wants to send its initial Answer
                 before knowing any candidate for one or more media descriptions,
                 it <span class="bcp14">MUST</span> set the port to the default value  '9' for these media descriptions.
                 If the  Answerer does not want to include the
                 host IP address in the corresponding "c="line,
                 e.g., due to privacy reasons,
                 it <span class="bcp14">SHOULD</span> include a default address in the "c="line,
                  which is set to the IPv4 address 0.0.0.0 or
                 to the IPv6 equivalent ::.<a href="#section-4.1.3-2" class="pilcrow">¶</a></p>
<p id="section-4.1.3-3">
                 In this case, the Answerer obviously cannot know the RTCP transport address; thus,
                 it <span class="bcp14">MUST NOT</span> include the "rtcp" attribute <span>[<a href="#RFC6086" class="xref">RFC6086</a>]</span>.
                 This avoids potential ICE mismatch
                 (see <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span>) for the RTCP transport address.<a href="#section-4.1.3-3" class="pilcrow">¶</a></p>
<p id="section-4.1.3-4">
                 If the Answerer accepts the use of RTCP multiplexing
                 <span>[<a href="#RFC5761" class="xref">RFC5761</a>]</span>
                 and/or exclusive RTCP multiplexing
                 <span>[<a href="#RFC8858" class="xref">RFC8858</a>]</span>,
                 it will include the "rtcp-mux" attribute
                 in the initial Answer.<a href="#section-4.1.3-4" class="pilcrow">¶</a></p>
<p id="section-4.1.3-5">
                 In any case, the Answerer <span class="bcp14">MUST</span> include
                 the "ice-options:trickle" attribute in accordance to
                <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span> and
                <span class="bcp14">MUST</span> include in each "m=" line
                a "mid" attribute in accordance to
                <span>[<a href="#RFC5888" class="xref">RFC5888</a>]</span>.<a href="#section-4.1.3-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IniAR">
<section id="section-4.1.4">
          <h4 id="name-receiving-the-initial-answe">
<a href="#section-4.1.4" class="section-number selfRef">4.1.4. </a><a href="#name-receiving-the-initial-answe" class="section-name selfRef">Receiving the Initial Answer</a>
          </h4>
<p id="section-4.1.4-1">
                 If the initial Answer included candidates,
                 the Offerer uses these candidates to start ICE processing
                 as specified in <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span>.<a href="#section-4.1.4-1" class="pilcrow">¶</a></p>
<p id="section-4.1.4-2">
                 In case of a "m/c=" line with default values,
                 none of the eventually trickled candidates
                 will match the default destination.
                 This situation <span class="bcp14">MUST NOT</span> cause an ICE mismatch
                 (see <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span>).<a href="#section-4.1.4-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="subsOA">
<section id="section-4.2">
        <h3 id="name-subsequent-offer-answer-exc">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-subsequent-offer-answer-exc" class="section-name selfRef">Subsequent Offer/Answer Exchanges</a>
        </h3>
<p id="section-4.2-1">
            Subsequent Offer/Answer exchanges are handled
            the same as regular ICE (see <span><a href="https://www.rfc-editor.org/rfc/rfc8839#section-4.4" class="relref">Section 4.4</a> of [<a href="#RFC8839" class="xref">RFC8839</a>]</span>).<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2"> If an Offer or Answer needs to be sent while the ICE Agents
            are in the middle of trickling,
            <span><a href="https://www.rfc-editor.org/rfc/rfc8839#section-4.4" class="relref">Section 4.4</a> of [<a href="#RFC8839" class="xref">RFC8839</a>]</span> applies.
            This means that an ICE Agent includes candidate attributes
            for all local candidates it had trickled previously
            for a specific media stream.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dialog-est">
<section id="section-4.3">
        <h3 id="name-establishing-the-dialog">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-establishing-the-dialog" class="section-name selfRef">Establishing the Dialog</a>
        </h3>
<p id="section-4.3-1">
          In order to be able to start trickling, the
          following two conditions need to be satisfied at the SIP UAs:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.3-2.1">
              Trickle ICE support at the peer agent <span class="bcp14">MUST</span> be confirmed.<a href="#section-4.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-2.2">
              A dialog <span class="bcp14">MUST</span> have been created between the peers.<a href="#section-4.3-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.3-3">
          <a href="#disco" class="xref">Section 5</a> discusses in detail the various options
          for satisfying the first of the above conditions. However, regardless
          of those mechanisms, agents are certain to have a
          clear understanding of whether their peers support trickle
          ICE once an Offer and an Answer have been exchanged,
          which also allows for ICE processing to commence
          (see <a href="#offerer-can-trickle" class="xref">Figure 3</a>).<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<div id="relprov">
<section id="section-4.3.1">
          <h4 id="name-establishing-dialog-state-t">
<a href="#section-4.3.1" class="section-number selfRef">4.3.1. </a><a href="#name-establishing-dialog-state-t" class="section-name selfRef">Establishing Dialog State through Reliable Offer/Answer Delivery</a>
          </h4>
<span id="name-a-sip-offerer-can-freely-tr"></span><div id="offerer-can-trickle">
<figure id="figure-3">
            <div class="artwork art-text alignLeft" id="section-4.3.1-1.1">
<pre>
                Alice                      Bob
                  |                         |
                  |     INVITE (Offer)      |
                  |------------------------&gt;|
                  |      183 (Answer)       |
                  |&lt;------------------------|
                  |        PRACK/OK         |
                  |------------------------&gt;|
                  |                         |
          +----------------------------------------+
          |Alice and Bob know that both can trickle|
          |and know that the dialog is in the early|
          |state. Send INFO!                       |
          +----------------------------------------+
                  |                         |
                  |  INFO/OK (+SRFLX Cand.) |
                  |------------------------&gt;|
                  |  INFO/OK (+SRFLX Cand.) |
                  |&lt;------------------------|
                  |                         |

        Note: "SRFLX" denotes server-reflexive candidates</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-a-sip-offerer-can-freely-tr" class="selfRef">A SIP Offerer can freely trickle as soon as it receives an Answer</a>
            </figcaption></figure>
</div>
<p id="section-4.3.1-2">
            As shown in <a href="#offerer-can-trickle" class="xref">Figure 3</a>,
            satisfying both conditions is relatively trivial for
            ICE Agents that have sent an Offer in an INVITE and that have
            received an Answer in a reliable provisional response.
            It is guaranteed to have confirmed support (or lack thereof) for
            Trickle ICE at the Answerer and to have
            fully initialized the SIP dialog at both ends.
            Offerers and Answerers (after receipt of the PRACK request)
            in the above situation can therefore
            freely commence trickling within the newly established dialog.<a href="#section-4.3.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="unrelprov">
<section id="section-4.3.2">
          <h4 id="name-establishing-dialog-state-th">
<a href="#section-4.3.2" class="section-number selfRef">4.3.2. </a><a href="#name-establishing-dialog-state-th" class="section-name selfRef">Establishing Dialog State through Unreliable Offer/Answer Delivery</a>
          </h4>
<p id="section-4.3.2-1">
            The situation is a bit more delicate for agents that have
            received an Offer in an INVITE request and have sent an Answer
            in an unreliable provisional response because, once the
            response has been sent, the Answerer does not
            know when or if it has been received
            (<a href="#answerer-cant-trickle" class="xref">Figure 4</a>).<a href="#section-4.3.2-1" class="pilcrow">¶</a></p>
<span id="name-a-sip-ua-that-sent-an-answe"></span><div id="answerer-cant-trickle">
<figure id="figure-4">
            <div class="artwork art-text alignLeft" id="section-4.3.2-2.1">
<pre>
                Alice                      Bob
                  |                         |
                  |     INVITE (Offer)      |
                  |------------------------&gt;|
                  |      183 (Answer)       |
                  |&lt;------------------------|
                  |                         |
                  |               +----------------------+
                  |               |Bob:  I don't know if |
                  |               |Alice got my 183 or if|
                  |               |her dialog is already |
                  |               |in the early state.   |
                  |               |  Can I send INFO???  |
                  |               +----------------------+
                  |                         |</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-a-sip-ua-that-sent-an-answe" class="selfRef">A SIP UA that sent an Answer in an unreliable provisional response does not know if it was received or if the dialog at the side of the Offerer has entered the early state</a>
            </figcaption></figure>
</div>
<p id="section-4.3.2-3">
            In order to clear this ambiguity as soon as possible,
            the Answerer needs to retransmit the provisional response
            with the exponential backoff timers described in
            <span>[<a href="#RFC3262" class="xref">RFC3262</a>]</span>.
            These retransmissions <span class="bcp14">MUST</span> cease on receipt
            of an INFO request carrying a "trickle-ice" Info Package body,
            on receipt of any other in-dialog request from the Offerer, or
            on transmission of the Answer in a 2xx response.
            The Offerer cannot send in-dialog requests until it receives
            a response, so the arrival of such a request proves that
            the response has arrived.
            Using the INFO request for dialog confirmation
            is similar to the procedure described in
            <span><a href="https://www.rfc-editor.org/rfc/rfc8839#section-7.1.1" class="relref">Section 7.1.1</a> of [<a href="#RFC8839" class="xref">RFC8839</a>]</span>, except that
            the STUN binding request is replaced by the INFO request.<a href="#section-4.3.2-3" class="pilcrow">¶</a></p>
<p id="section-4.3.2-4">
            The Offerer <span class="bcp14">MUST</span> send a Trickle ICE INFO request as soon as
            it receives an SDP Answer in an unreliable provisional
            response. This INFO request <span class="bcp14">MUST</span> repeat the candidates
            that were already provided in the Offer (as would be the case
            when Half Trickle is performed or when new candidates have not
            been learned since then).
            The first case could happen when Half Trickle is used and
            all candidates are already in the initial offer.
            The second case could happen when Full Trickle is used and
            the Offerer is currently gathering additional candidates
            but did not yet get them.
            Also, if the initial Offer did not contain any candidates,
            depending on how the Offerer gathers its candidates and
            how long it takes to do so, this INFO could still contain no candidates.<a href="#section-4.3.2-4" class="pilcrow">¶</a></p>
<p id="section-4.3.2-5">
            When Full Trickle is used and if newly learned candidates
            are available, the Offerer <span class="bcp14">SHOULD</span> also deliver
            these candidates in said INFO request,
            unless it wants to hold back some candidates in reserve,
            e.g., in case these candidates
            are expensive to use and would only be trickled
            if all other candidates failed.<a href="#section-4.3.2-5" class="pilcrow">¶</a></p>
<p id="section-4.3.2-6">
            The Offerer <span class="bcp14">SHOULD</span> include an "end-of-candidates" attribute
            in case candidate discovery has ended in the meantime
            and no further candidates are to be trickled.<a href="#section-4.3.2-6" class="pilcrow">¶</a></p>
<p id="section-4.3.2-7">
            As soon as an Answerer has received such an INFO request,
            the Answerer has an indication that a dialog is established
            at both ends and trickling can begin
            (<a href="#answerer-can-now-trickle" class="xref">Figure 5</a>).<a href="#section-4.3.2-7" class="pilcrow">¶</a></p>
<p id="section-4.3.2-8">
              Note: The "+SRFLX" in
             <a href="#answerer-can-now-trickle" class="xref">Figure 5</a>
             indicates that additional newly learned server-reflexive candidates are included.<a href="#section-4.3.2-8" class="pilcrow">¶</a></p>
<span id="name-a-sip-ua-that-received-an-i"></span><div id="answerer-can-now-trickle">
<figure id="figure-5">
            <div class="artwork art-text alignLeft" id="section-4.3.2-9.1">
<pre>
                Alice                      Bob
                  |                         |
                  |     INVITE (Offer)      |
                  |------------------------&gt;|
                  |      183 (Answer)       |
                  |&lt;------------------------|
                  |  INFO/OK (+SRFLX Cand.) |
                  |------------------------&gt;|
                  |                         |
                  |               +----------------------+
                  |               |Bob:  Now I know Alice|
                  |               | is ready. Send INFO! |
                  |               +----------------------+
                  |  INFO/OK (+SRFLX Cand.) |
                  |&lt;------------------------|
                  |                         |
                  |    200/ACK (Answer)     |
                  |&lt;------------------------|

          Note: "SRFLX" denotes server-reflexive candidates</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-a-sip-ua-that-received-an-i" class="selfRef">A SIP UA that received an INFO request after sending an unreliable                            provisional response knows that the dialog at the side of the receiver has entered the early             state</a>
            </figcaption></figure>
</div>
<p id="section-4.3.2-10">
          When sending the Answer in the 200 OK response to the INVITE request,
          the Answerer needs to repeat
          exactly the same Answer that was previously sent
          in the unreliable provisional
          response in order to fulfill the corresponding requirements in
          <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span>.
          Thus, the Offerer needs to be prepared
          for receiving a different number of candidates
          in that repeated Answer than previously exchanged via trickling
          and <span class="bcp14">MUST</span> ignore the candidate information
          in that 200 OK response.<a href="#section-4.3.2-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="head-start">
<section id="section-4.3.3">
          <h4 id="name-initiating-trickle-ice-with">
<a href="#section-4.3.3" class="section-number selfRef">4.3.3. </a><a href="#name-initiating-trickle-ice-with" class="section-name selfRef">Initiating Trickle ICE without an SDP Answer</a>
          </h4>
<p id="section-4.3.3-1">
            The ability to convey arbitrary candidates in INFO
            message bodies allows ICE Agents to initiate trickling
            without actually sending an Answer.
            Trickle ICE Agents can therefore respond to an INVITE request
            with provisional responses without an SDP Answer
            <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span>.
            Such provisional responses serve for establishing an early dialog.<a href="#section-4.3.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3.3-2">
            Agents that choose to establish the dialog in this way
            <span class="bcp14">MUST</span> retransmit these responses
            with the exponential backoff timers described in
            <span>[<a href="#RFC3262" class="xref">RFC3262</a>]</span>.
            These retransmissions <span class="bcp14">MUST</span> cease on receipt
            of an INFO request carrying a "trickle-ice" Info Package body,
            on receipt of any in-dialog requests from the Offerer, or
            on transmission of the Answer in a 2xx response.
            The Offerer cannot send in-dialog requests until it receives
            a response, so the arrival of such a request proves that
            the response has arrived.
            This is again similar to the procedure described in
            <span><a href="https://www.rfc-editor.org/rfc/rfc8839#section-6.1.1" class="relref">Section 6.1.1</a> of [<a href="#RFC8839" class="xref">RFC8839</a>]</span>,
            except that an Answer is not yet provided.<a href="#section-4.3.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3.3-3">
              Note: The "+SRFLX" in
             <a href="#can-now-trickle-unrelprov" class="xref">Figure 6</a>
             indicates that additional newly learned server-reflexive candidates are included.<a href="#section-4.3.3-3" class="pilcrow">¶</a></p>
<span id="name-a-sip-ua-sends-an-unreliabl"></span><div id="can-now-trickle-unrelprov">
<figure id="figure-6">
            <div class="artwork art-text alignLeft" id="section-4.3.3-4.1">
<pre>
                Alice                      Bob
                  |                         |
                  |     INVITE (Offer)      |
                  |------------------------&gt;|
                  |      183 (-)            |
                  |&lt;------------------------|
                  |  INFO/OK (SRFLX Cand.)  |
                  |------------------------&gt;|
                  |                         |
                  |               +----------------------+
                  |               |Bob:  Now I know again|
                  |               | that Alice is ready. |
                  |               | Send INFO!           |
                  |               +----------------------+
                  |  INFO/OK (SRFLX Cand.)  |
                  |&lt;------------------------|
                  |    183 (Answer) opt.    |
                  |&lt;------------------------|
                  |  INFO/OK (SRFLX Cand.)  |
                  |&lt;------------------------|
                  |    200/ACK (Answer)     |
                  |&lt;------------------------|

       Note: "SRFLX" denotes server-reflexive candidates</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-a-sip-ua-sends-an-unreliabl" class="selfRef">A SIP UA sends an unreliable provisional response without an Answer for establishing an early dialog</a>
            </figcaption></figure>
</div>
<p id="section-4.3.3-5">
        When sending the Answer, the agent <span class="bcp14">MUST</span> repeat all currently
        known and used candidates, if any,
        and <span class="bcp14">MAY</span> include all newly gathered candidates since the last INFO request was sent.
        However, if that Answer was already sent in an unreliable provisional response,
        the Answerers <span class="bcp14">MUST</span> repeat
        exactly the same Answer in the 200 OK response to the INVITE request
        in order to fulfill the corresponding requirements in
        <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span>.
        In case that trickling continued,
        an Offerer needs to be prepared for receiving fewer candidates
        in that repeated Answer than previously exchanged via trickling
        and <span class="bcp14">MUST</span> ignore the candidate information in that 200 OK response.<a href="#section-4.3.3-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="info-sdp">
<section id="section-4.4">
        <h3 id="name-delivering-candidates-in-in">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-delivering-candidates-in-in" class="section-name selfRef">Delivering Candidates in INFO Requests</a>
        </h3>
<p id="section-4.4-1">
        Whenever new ICE candidates become available for sending,
        agents encode them in "candidate" attributes as described
        by <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span>. For example:<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<div id="section-4.4-2">
<pre class="sourcecode lang-sdp">
  a=candidate:1 1 UDP 2130706432 200a0b:12f0::1 5000 typ host</pre><a href="#section-4.4-2" class="pilcrow">¶</a>
</div>
<p id="section-4.4-3">
          The use of SIP INFO requests happens within the context of the
          Info Package as defined in <a href="#info-package" class="xref">Section 10</a>.
          The media type
          <span>[<a href="#RFC6838" class="xref">RFC6838</a>]</span>
          for their payload <span class="bcp14">MUST</span> be set to
          "application/trickle-ice-sdpfrag" as defined in
          <a href="#trickle_ice_sdpfrag_def" class="xref">Section 9</a>.
          The INFO request body adheres to the grammar as specified in
          <a href="#trickle_ice_sdpfrag_grammar" class="xref">Section 9.2</a>.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<p id="section-4.4-4">
          Since neither the "candidate" nor the "end-of-candidates"
          attributes contain information that would allow correlating them to
          a specific "m=" line,
          it is handled through the use of
          pseudo "m=" lines.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
<p id="section-4.4-5">
          Pseudo "m=" lines follow the SDP syntax for "m=" lines as
          defined in
          <span>[<a href="#RFC4566" class="xref">RFC4566</a>]</span> and are linked to the corresponding "m=" line
          in the SDP Offer or Answer via the identification tag
          in a "mid" attribute
          <span>[<a href="#RFC5888" class="xref">RFC5888</a>]</span>.
          A pseudo  "m=" line does not provide semantics other
          than indicating to which "m=" line a candidate belongs.
          Consequently, the receiving agent <span class="bcp14">MUST</span> ignore any remaining content of the pseudo "m=" line,
          which is not defined in this document.
          This guarantees that the  "application/trickle-ice-sdpfrag" bodies do not interfere with the Offer/Answer
          procedures as specified in <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span>.<a href="#section-4.4-5" class="pilcrow">¶</a></p>
<p id="section-4.4-6">
        When sending the INFO request, the agent <span class="bcp14">MAY</span>,
        if already known to the  agent, include the same content into
        the pseudo "m=" line as for the "m=" line in the corresponding Offer or Answer.
        However, since Trickle ICE might be decoupled from the Offer/Answer negotiation, the content might
        be unknown to the agent. In this case, the agent <span class="bcp14">MUST</span> include the following default values:<a href="#section-4.4-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.4-7.1">
              The media field is set to 'audio'.<a href="#section-4.4-7.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.4-7.2">
              The port value is set to '9'.<a href="#section-4.4-7.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.4-7.3">
              The proto value is set to 'RTP/AVP'.<a href="#section-4.4-7.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.4-7.4">
              The fmt field <span class="bcp14">MUST</span> appear only once and is set to '0'.<a href="#section-4.4-7.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.4-8">
        Agents <span class="bcp14">MUST</span> include  a pseudo "m=" line and an
          identification tag in a "mid" attribute for every "m=" line
          whose candidate list they intend to update.
          Such "mid" attributes <span class="bcp14">MUST</span>
          immediately precede the list of candidates for that specific
          "m=" line.<a href="#section-4.4-8" class="pilcrow">¶</a></p>
<p id="section-4.4-9">
          All "candidate" or "end-of-candidates" attributes
          following a "mid" attribute, up until (and excluding) the next
          occurrence of a pseudo "m=" line, pertain to the "m=" line
          identified by that identification tag.<a href="#section-4.4-9" class="pilcrow">¶</a></p>
<p id="section-4.4-10">
          Note, that there is no requirement that the INFO request body
          contains as many pseudo "m=" lines as the Offer/Answer
          contains "m=" lines, nor that the pseudo "m=" lines be in the same
          order as the "m=" lines that they pertain to.
          The correspondence can be made via the "mid" attributes
          since candidates are grouped in sections headed
          by "pseudo" "m=" lines.
          These sections contain "mid" attribute values that point
          back to the true "m=" line.<a href="#section-4.4-10" class="pilcrow">¶</a></p>
<p id="section-4.4-11">
          An "end-of-candidates" attribute, preceding
          the first pseudo "m=" line, indicates the end of all trickling
          from that agent,
          as opposed to end of trickling for a specific "m=" line,
          which would be indicated by a media-level
          "end-of-candidates" attribute.<a href="#section-4.4-11" class="pilcrow">¶</a></p>
<p id="section-4.4-12">
            Refer to
            <a href="#INFOexample" class="xref">Figure 7</a>
            for an example of the INFO request content.<a href="#section-4.4-12" class="pilcrow">¶</a></p>
<p id="section-4.4-13">
          The use of pseudo "m=" lines allows for a structure similar to
          the one in SDP Offers and Answers where
          separate media-level and session-level sections can be distinguished.
          In the current case, lines preceding the first
          pseudo "m=" line are considered to be session level.
          Lines appearing in between or after
          pseudo "m=" lines will be interpreted as media level.<a href="#section-4.4-13" class="pilcrow">¶</a></p>
<aside id="section-4.4-14">
          <p id="section-4.4-14.1">
              Note that while this specification uses the "mid"
              attribute from <span>[<a href="#RFC5888" class="xref">RFC5888</a>]</span>, it does not
              define any grouping semantics.<a href="#section-4.4-14.1" class="pilcrow">¶</a></p>
</aside>
<p id="section-4.4-15">
          All INFO requests <span class="bcp14">MUST</span> carry the "ice-pwd" and "ice-ufrag"
          attributes that allow mapping them to a specific ICE generation.
          An agent <span class="bcp14">MUST</span> discard any received INFO requests containing "ice-pwd" and "ice-ufrag"
          attributes that do not match those of the current ICE Negotiation Session.<a href="#section-4.4-15" class="pilcrow">¶</a></p>
<p id="section-4.4-16">
          The "ice-pwd" and "ice-ufrag" attributes <span class="bcp14">MUST</span> appear at the same level
          as the ones in the Offer/Answer exchange.
          In other words, if they were present
          as session-level attributes, they will also appear
          at the beginning of all INFO request payloads, i.e., preceding
          the first pseudo "m=" line.
          If they were originally exchanged as media-level
          attributes, potentially overriding session-level values,
          then they will also be included in INFO request payloads
          following the corresponding pseudo "m=" lines.<a href="#section-4.4-16" class="pilcrow">¶</a></p>
<p id="section-4.4-17">
          Note that
          when candidates are trickled, <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span> 
          requires that each candidate must be delivered
          to the receiving Trickle ICE implementation not more than once
          and in the same order as it was conveyed.
          If the signaling protocol provides any candidate retransmissions,
          they need to be hidden from the ICE implementation.
          This requirement is fulfilled as follows.<a href="#section-4.4-17" class="pilcrow">¶</a></p>
<p id="section-4.4-18">
          Since the agent is not fully aware of the state of the ICE Negotiation Session at its peer,
          it <span class="bcp14">MUST</span> include all currently known and used local candidates in every INFO request.
          That is, the agent <span class="bcp14">MUST</span> repeat in the INFO request body
          all candidates that were previously sent under the same
          combination of "ice-pwd" and "ice-ufrag"
          in the same order as they were sent before.
          In other words, the sequence of a previously sent
          list of candidates <span class="bcp14">MUST NOT</span> change in subsequent INFO requests,
          and newly gathered candidates <span class="bcp14">MUST</span> be added
          at the end of that list.
          Although repeating all candidates creates some overhead, it also allows easier handling of problems
          that could arise from unreliable transports like, e.g., loss of messages and reordering,
          which can be detected through the CSeq: header field in the INFO request.<a href="#section-4.4-18" class="pilcrow">¶</a></p>
<p id="section-4.4-19">
          In addition, an ICE Agent needs to adhere to
          <span><a href="https://www.rfc-editor.org/rfc/rfc8838#section-17" class="relref">Section 17</a> of [<a href="#RFC8838" class="xref">RFC8838</a>]</span>
          on preserving candidate order while trickling.<a href="#section-4.4-19" class="pilcrow">¶</a></p>
<p id="section-4.4-20">
          When receiving INFO requests carrying any candidates, agents
          <span class="bcp14">MUST</span> first identify and discard the attribute lines
          containing candidates they have already received in previous
          INFO requests or in the Offer/Answer exchange preceding them.<a href="#section-4.4-20" class="pilcrow">¶</a></p>
<p id="section-4.4-21"> Such candidates are considered to be equal if their IP address
          port, transport, and component ID are the same.
          After identifying and discarding the known candidates,
          the agents <span class="bcp14">MUST</span> forward the actual new candidates to the ICE Agents
          in the same order as they were received in the INFO request body.
          The ICE Agents will then process the new candidates
          according to the rules described in <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span>.<a href="#section-4.4-21" class="pilcrow">¶</a></p>
<p id="section-4.4-22"> Receiving an "end-of-candidates" attribute in an INFO request body
        -- with the "ice-ufrag" and "ice-pwd" attributes matching the current ICE generation --
        is an indication from the peer agent that it will not send any further candidates.
        When included at the session level, i.e., before any pseudo "m=" line,
        this indication applies to the whole session;
        when included at the media level, the indication applies
        only to the corresponding "m=" line.
        Handling of such end-of-candidates indications is defined in
        <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span>.<a href="#section-4.4-22" class="pilcrow">¶</a></p>
<p id="section-4.4-23">
          The example in <a href="#INFOexample" class="xref">Figure 7</a> shows the content
           of a candidate delivering INFO request. In the example, the
           "end-of-candidates" attributes indicate that
           the candidate gathering is finished and
           that no further INFO requests follow.<a href="#section-4.4-23" class="pilcrow">¶</a></p>
<span id="name-an-example-for-the-content-"></span><div id="INFOexample">
<figure id="figure-7">
          <div id="section-4.4-24.1">
<pre class="sourcecode">
  INFO sip:alice@example.com SIP/2.0
  ...
  Info-Package: trickle-ice
  Content-type: application/trickle-ice-sdpfrag
  Content-Disposition: Info-Package
  Content-length: 862

  a=ice-pwd:asd88fgpdd777uzjYhagZg
  a=ice-ufrag:8hhY
  m=audio 9 RTP/AVP 0
  a=mid:1
  a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 5000 typ host
  a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 5001 typ host
  a=candidate:1 1 UDP 2130706431 192.0.2.1 5010 typ host
  a=candidate:1 2 UDP 2130706431 192.0.2.1 5011 typ host
  a=candidate:2 1 UDP 1694498815 192.0.2.3 5010 typ srflx
     raddr 192.0.2.1 rport 8998
  a=candidate:2 2 UDP 1694498815 192.0.2.3 5011 typ srflx
     raddr 192.0.2.1 rport 8998
  a=end-of-candidates
  m=audio 9 RTP/AVP 0
  a=mid:2
  a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 6000 typ host
  a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 6001 typ host
  a=candidate:1 1 UDP 2130706431 192.0.2.1 6010 typ host
  a=candidate:1 2 UDP 2130706431 192.0.2.1 6011 typ host
  a=candidate:2 1 UDP 1694498815 192.0.2.3 6010 typ srflx
     raddr 192.0.2.1 rport 9998
  a=candidate:2 2 UDP 1694498815 192.0.2.3 6011 typ srflx
     raddr 192.0.2.1 rport 9998
  a=end-of-candidates

      Note: In a real INFO request, there will be no line breaks
            in the "candidate" attributes</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-an-example-for-the-content-" class="selfRef">An Example for the Content of an INFO Request</a>
          </figcaption></figure>
</div>
</section>
</div>
</section>
</div>
<div id="disco">
<section id="section-5">
      <h2 id="name-initial-discovery-of-trickl">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-initial-discovery-of-trickl" class="section-name selfRef">Initial Discovery of Trickle ICE Support</a>
      </h2>
<p id="section-5-1">
         SIP UAs are required by <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span> to indicate their support of and intent to use Trickle ICE in their Offers and Answers by using the "ice-options:trickle" attribute, and they <span class="bcp14">MUST</span> include the SIP option-tag "trickle-ice" in
          a SIP Supported: or Require: header field.
          This makes discovery
          fairly straightforward for Answerers or for cases where
          Offers need to be generated within existing dialogs (i.e.,
          when sending UPDATE or re-INVITE requests).
          In both scenarios, prior
          SDP bodies will have provided the necessary information.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
          Obviously, such information is not available at the time a first
          Offer is being constructed, and it is therefore impossible
          for ICE Agents to determine support for incremental
          provisioning that way. The following options are suggested as
          ways of addressing this issue.<a href="#section-5-2" class="pilcrow">¶</a></p>
<div id="disco-prov">
<section id="section-5.1">
        <h3 id="name-provisioning-support-for-tr">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-provisioning-support-for-tr" class="section-name selfRef">Provisioning Support for Trickle ICE</a>
        </h3>
<p id="section-5.1-1">
            In certain situations, it may be possible for integrators
            deploying Trickle ICE to know in advance that some or all
            endpoints reachable from within the deployment will support
            Trickle ICE.
            This is the case, for example, if Session Border Controllers
            (SBCs) with support for this specification are used
            to connect to UAs that do not support Trickle ICE.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">
            While the exact mechanism for allowing such  provisioning
            is out of scope here, this specification encourages trickle
            ICE implementations to allow the option in the way they find
            most appropriate.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<p id="section-5.1-3">
            However, an Offerer assuming Trickle ICE support <span class="bcp14">MUST</span>
            include a SIP Require: trickle-ice header field.
            That way, if the provisioned assumption of Trickle ICE support
            ends up being incorrect, the failure is (a) operationally
            easy to track down and (b) recoverable by the client,
            i.e., they can resend the request without the
            SIP Require: header field and without
            the assumption of Trickle ICE support.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="disco-gruu">
<section id="section-5.2">
        <h3 id="name-trickle-ice-discovery-with-">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-trickle-ice-discovery-with-" class="section-name selfRef">Trickle ICE Discovery with Globally Routable User Agent URIs (GRUUs)</a>
        </h3>
<p id="section-5.2-1">
            <span>[<a href="#RFC3840" class="xref">RFC3840</a>]</span> provides a way for SIP UAs
            to query for support of specific capabilities using, among
            others, OPTIONS requests. On the other hand, support for
            GRUU according to
            <span>[<a href="#RFC5627" class="xref">RFC5627</a>]</span>
            allows SIP requests to be addressed to specific UAs (as
            opposed to arbitrary instances of an address of record).
            Combining the two and using the "trickle-ice" option tag
            defined in <a href="#option-tag" class="xref">Section 10.6</a> provides SIP UAs with
            a way of learning the capabilities of specific SIP UA instances
            and then addressing them directly with INVITE requests that
            require Trickle ICE support.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">
            Such learning of capabilities may happen in different ways.
            One option for a SIP UA is to learn the
            GRUU instance ID of a peer through presence and then to query
            its capabilities with an OPTIONS request.
            Alternatively, it can also just send an OPTIONS request to
            the Address of Record (AOR) it intends to contact and then inspect the returned
            response(s) for support of both GRUU and Trickle ICE
            (<a href="#options-gruu" class="xref">Figure 8</a>).
            It is noted that using the GRUU means that the INVITE request
            can go only to that particular device.
            This prevents the use of forking for that request.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<span id="name-trickle-ice-support-discove"></span><div id="options-gruu">
<figure id="figure-8">
          <div class="artwork art-text alignLeft" id="section-5.2-3.1">
<pre>
         Alice                                                Bob
           |                                                   |
           |        OPTIONS sip:b1@example.com SIP/2.0         |
           |--------------------------------------------------&gt;|
           |                                                   |
           |                      200 OK                       |
           |    Contact: sip:b1@example.com;gr=hha9s8d-999a    |
           |            ;audio;video|;trickle-ice;...          |
           |&lt;--------------------------------------------------|
           |                                                   |
           | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 |
           |             Supported: trickle-ice                |
           |                      (Offer)                      |
           |--------------------------------------------------&gt;|
           |                                                   |
           |                  183 (Answer)                     |
           |&lt;--------------------------------------------------|
           |                INFO/OK (Trickling)                |
           |&lt;-------------------------------------------------&gt;|
           |                                                   |
           |                      ...                          |
           |                                                   |</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-trickle-ice-support-discove" class="selfRef">Trickle ICE Support Discovery with OPTIONS and GRUU</a>
          </figcaption></figure>
</div>
<p id="section-5.2-4">
            Confirming support for Trickle ICE through
            <span>[<a href="#RFC3840" class="xref">RFC3840</a>]</span> gives SIP UAs the option to engage
            in Full Trickle negotiation (as opposed to the more lengthy
            Half Trickle) from the very first Offer they send.<a href="#section-5.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="half-full-trickle">
<section id="section-5.3">
        <h3 id="name-fall-back-to-half-trickle">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-fall-back-to-half-trickle" class="section-name selfRef">Fall Back to Half Trickle</a>
        </h3>
<p id="section-5.3-1">
            In cases where none of the other mechanisms in this section
            are acceptable, SIP UAs should use the Half Trickle mode
            defined in <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span>.
            With Half Trickle, agents initiate sessions the same way
            they would when using ICE for SIP
            <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span>.
            This means that, prior to actually sending an Offer, agents
            first gather ICE candidates in a blocking way and then
            send them all in that Offer. The blocking nature of the
            process implies that some amount of latency will
            be accumulated, and it is advised that agents try to
            anticipate it where possible, for example, when user
            actions indicate a high likelihood for an imminent call
            (e.g., activity on a keypad or a phone going off hook).<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">
            Using Half Trickle results in Offers that are
            compatible with both ICE SIP endpoints <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span> and legacy
            endpoints <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span>.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
<span id="name-example-of-a-typical-half-t"></span><div id="fig-half-trickle">
<figure id="figure-9">
          <div class="artwork art-text alignLeft" id="section-5.3-3.1">
<pre>
STUN/TURN                                                STUN/TURN
Servers          Alice                      Bob          Servers
   |               |                             |               |
   |&lt;--------------|                             |               |
   |               |                             |               |
   |               |                             |               |
   |   Candidate   |                             |               |
   |               |                             |               |
   |               |                             |               |
   |   Discovery   |                             |               |
   |               |                             |               |
   |               |                             |               |
   |--------------&gt;|       INVITE (Offer)        |               |
   |               |----------------------------&gt;|               |
   |               |        183 (Answer)         |--------------&gt;|
   |               |&lt;----------------------------|               |
   |               |  INFO (repeated candidates) |               |
   |               |----------------------------&gt;|               |
   |               |                             |               |
   |               |    INFO (more candidates)   |   Candidate   |
   |               |&lt;----------------------------|               |
   |               |    Connectivity Checks      |               |
   |               |&lt;===========================&gt;|   Discovery   |
   |               |   INFO (more candidates)    |               |
   |               |&lt;----------------------------|               |
   |               |    Connectivity Checks      |&lt;--------------|
   |               |&lt;===========================&gt;|               |
   |               |                             |               |
   |               |          200 OK             |               |
   |               |&lt;----------------------------|               |
   |               |                             |               |
   |               |&lt;======= MEDIA FLOWS =======&gt;|               |
   |               |                             |               |</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-example-of-a-typical-half-t" class="selfRef">Example of a Typical (Half) Trickle ICE Exchange with SIP</a>
          </figcaption></figure>
</div>
<p id="section-5.3-4">

          As a reminder, once a single Offer or Answer has
          been exchanged within a specific dialog, support for
          Trickle ICE will have been determined.
          No further use of Half Trickle will therefore be necessary
          within that same dialog,
          and all subsequent exchanges can use the Full Trickle mode
          of operation.<a href="#section-5.3-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="rtcp-cons">
<section id="section-6">
      <h2 id="name-considerations-for-rtp-and-">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-considerations-for-rtp-and-" class="section-name selfRef">Considerations for RTP and RTCP Multiplexing</a>
      </h2>
<p id="section-6-1">
        The following consideration describes options for Trickle ICE
        in order to give some guidance to implementers on how trickling
        can be optimized with respect to providing RTCP candidates.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">
        Handling of the "rtcp" attribute <span>[<a href="#RFC3605" class="xref">RFC3605</a>]</span>
        and the "rtcp-mux" attribute for RTP/RTCP multiplexing <span>[<a href="#RFC5761" class="xref">RFC5761</a>]</span>
        is already considered in
        <span><a href="https://www.rfc-editor.org/rfc/rfc8445#section-5.1.1.1" class="relref">Section 5.1.1.1</a> of [<a href="#RFC8445" class="xref">RFC8445</a>]</span> and
        in <span>[<a href="#RFC5761" class="xref">RFC5761</a>]</span>.
        These considerations are still valid for Trickle ICE; however,
        trickling provides more flexibility for the sequence of candidate exchange in case of RTCP multiplexing.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">
        If the Offerer supports RTP/RTCP multiplexing exclusively as specified
        in <span>[<a href="#RFC8858" class="xref">RFC8858</a>]</span>,
        the procedures in that document apply for the handling of the "rtcp-mux-only", "rtcp", and "rtcp-mux" attributes.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">
        While a Half Trickle Offerer has to send an Offer compliant to
        <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span> and <span>[<a href="#RFC5761" class="xref">RFC5761</a>]</span> including candidates for all components, the flexibility of a Full Trickle Offerer allows
        the sending of only RTP candidates (component 1) in the initial Offer
        assuming that RTCP multiplexing is supported by the Answerer.
        A Full Trickle Offerer would need to start gathering and trickling
        RTCP candidates (component 2)
        only after having received an indication in the Answer that
        the Answerer unexpectedly does not support RTCP multiplexing.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">
        A Trickle Answerer <span class="bcp14">MAY</span> include an "rtcp-mux" attribute
        <span>[<a href="#RFC5761" class="xref">RFC5761</a>]</span> in the "application/trickle-ice-sdpfrag" body
        if it supports and uses RTP and RTCP multiplexing.
        The Trickle Answerer needs to follow the guidance on the usage of the "rtcp" attribute as given in
         <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span> and
         <span>[<a href="#RFC3605" class="xref">RFC3605</a>]</span>.
        Receipt of this attribute at the Offerer in an INFO request prior to the Answer
        indicates that the Answerer supports and uses RTP and RTCP multiplexing.
        The Offerer can use this information, e.g., for stopping the gathering of RTCP candidates
        and/or for freeing corresponding resources.<a href="#section-6-5" class="pilcrow">¶</a></p>
<p id="section-6-6">
        This behavior is illustrated by the following example Offer that indicates support for RTP and RTCP multiplexing.<a href="#section-6-6" class="pilcrow">¶</a></p>
<div id="section-6-7">
<pre class="sourcecode lang-sdp">
  v=0
  o=alice 2890844526 2890844526 IN IP6 atlanta.example.com
  s=
  c=IN IP6 2001:db8:a0b:12f0::3
  t=0 0
  a=ice-pwd:777uzjYhagZgasd88fgpdd
  a=ice-ufrag:Yhh8
  m=audio 5000 RTP/AVP 0
  a=mid:1
  a=rtcp-mux
  a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host</pre><a href="#section-6-7" class="pilcrow">¶</a>
</div>
<p id="section-6-8">
        Once the dialog is established as described in <a href="#dialog-est" class="xref">Section 4.3</a>, the Answerer
        sends the following INFO request.<a href="#section-6-8" class="pilcrow">¶</a></p>
<div id="section-6-9">
<pre class="sourcecode">
  INFO sip:alice@example.com SIP/2.0
  ...
  Info-Package: trickle-ice
  Content-type: application/trickle-ice-sdpfrag
  Content-Disposition: Info-Package
  Content-length: 161

  a=ice-pwd:asd88fgpdd777uzjYhagZg
  a=ice-ufrag:8hhY
  m=audio 9 RTP/AVP 0
  a=mid:1
  a=rtcp-mux
  a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ host</pre><a href="#section-6-9" class="pilcrow">¶</a>
</div>
<p id="section-6-10">
        This INFO request indicates that the Answerer supports and uses
        RTP and RTCP multiplexing as well.
        It allows the Offerer to omit gathering RTCP candidates or
        releasing already gathered RTCP candidates.
        If the INFO request did not contain the "rtcp-mux" attribute,
        the Offerer has to gather RTCP candidates
        unless it wants to wait until receipt of an Answer that eventually confirms
        support or non-support for RTP and RTCP multiplexing.
        In case the Offerer already sent RTCP candidates in a previous INFO request,
        it still needs to repeat them in subsequent INFO requests,
        even when that support for RTCP multiplexing was confirmed
        by the Answerer and the Offerer has released its RTCP candidates.<a href="#section-6-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="bundle-cons">
<section id="section-7">
      <h2 id="name-considerations-for-media-mu">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-considerations-for-media-mu" class="section-name selfRef">Considerations for Media Multiplexing</a>
      </h2>
<p id="section-7-1">
        The following considerations describe options for Trickle ICE
        in order to give some guidance to implementers on how trickling
        can be optimized with respect to providing candidates in case of Media Multiplexing
        <span>[<a href="#RFC8843" class="xref">RFC8843</a>]</span>.
        It is assumed that the reader is familiar with <span>[<a href="#RFC8843" class="xref">RFC8843</a>]</span>.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">
        ICE candidate exchange is already considered in
        <span><a href="https://www.rfc-editor.org/rfc/rfc8843#section-10" class="relref">Section 10</a> of [<a href="#RFC8843" class="xref">RFC8843</a>]</span>.
        These considerations are still valid for Trickle ICE; however,
        trickling provides more flexibility for the sequence of candidate exchange,
        especially in Full Trickle mode.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">
        Except for bundle-only "m=" lines, a Half Trickle Offerer has to
        send an Offer with candidates for all bundled "m=" lines.
        The additional flexibility, however, allows a Full Trickle Offerer
        to initially send only candidates for the "m=" line with the
        suggested Offerer BUNDLE address.<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">
        On receipt of the Answer, the Offerer will detect
        if BUNDLE is supported by the Answerer and if the suggested Offerer BUNDLE address was selected.
        In this case, the Offerer does not need to trickle further candidates for the remaining "m=" lines in a bundle.
        However, if BUNDLE is not supported, the Full Trickle Offerer needs to gather and trickle candidates
        for the remaining "m=" lines as necessary.
        If the Answerer selects an Offerer BUNDLE address that is different from the suggested Offerer BUNDLE address,
        the  Full Trickle Offerer needs to gather and trickle candidates
        for the "m=" line that carries the selected Offerer BUNDLE address.<a href="#section-7-4" class="pilcrow">¶</a></p>
<p id="section-7-5">
        A Trickle Answerer <span class="bcp14">SHOULD</span> include a "group:BUNDLE" attribute
        <span>[<a href="#RFC8843" class="xref">RFC8843</a>]</span>
        at session level in the "application/trickle-ice-sdpfrag" body
        if it supports and uses bundling.
        When doing so, the Answerer <span class="bcp14">MUST</span> include all identification-tags in the same order that is used or will be used in the Answer.<a href="#section-7-5" class="pilcrow">¶</a></p>
<p id="section-7-6">
        Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the Answerer
        supports and uses bundling.
        The Offerer can use this information, e.g., for stopping the gathering of candidates
        for the remaining "m=" lines in a bundle and/or for freeing corresponding resources.<a href="#section-7-6" class="pilcrow">¶</a></p>
<p id="section-7-7">
        This behavior is illustrated by the following example Offer that indicates support for Media Multiplexing.<a href="#section-7-7" class="pilcrow">¶</a></p>
<p id="section-7-8">
        If the Offerer already sent candidates for "m=" lines
        in a bundle in a previous INFO request,
        it still needs to repeat them in subsequent INFO requests,
        even when that support for bundling was confirmed
        by the Answerer and the Offerer has released candidates that are no longer needed.<a href="#section-7-8" class="pilcrow">¶</a></p>
<div id="section-7-9">
<pre class="sourcecode lang-sdp">
   v=0
   o=alice 2890844526 2890844526 IN IP6 atlanta.example.com
   s=
   c=IN IP6 2001:db8:a0b:12f0::3
   t=0 0
   a=group:BUNDLE foo bar
   a=ice-pwd:777uzjYhagZgasd88fgpdd
   a=ice-ufrag:Yhh8
   m=audio 10000 RTP/AVP 0
   a=mid:foo
   a=rtcp-mux
   a=rtpmap:0 PCMU/8000
   a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
   a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host
   m=video 10002 RTP/AVP 31
   a=mid:bar
   a=rtcp-mux
   a=rtpmap:31 H261/90000
   a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid</pre><a href="#section-7-9" class="pilcrow">¶</a>
</div>
<p id="section-7-10">
        The example Offer indicates support for RTP and RTCP multiplexing
        and contains a "candidate" attribute only for the "m=" line
        with the suggested Offerer BUNDLE address.
        Once the dialog is established as described in  <a href="#dialog-est" class="xref">Section 4.3</a>, the Answerer
        sends the following INFO request.<a href="#section-7-10" class="pilcrow">¶</a></p>
<div id="section-7-11">
<pre class="sourcecode">
   INFO sip:alice@example.com SIP/2.0
   ...
   Info-Package: trickle-ice
   Content-type: application/trickle-ice-sdpfrag
   Content-Disposition: Info-Package
   Content-length: 219

   a=group:BUNDLE foo bar
   a=ice-pwd:asd88fgpdd777uzjYhagZg
   a=ice-ufrag:8hhY
   m=audio 9 RTP/AVP 0
   a=mid:foo
   a=rtcp-mux
   a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host</pre><a href="#section-7-11" class="pilcrow">¶</a>
</div>
<p id="section-7-12">
        This INFO request indicates that the Answerer supports and uses Media Multiplexing as well.
        Note that the Answerer only includes a single pseudo "m=" line since candidates
         matching those from the second "m=" line in the offer are not needed from the Answerer.<a href="#section-7-12" class="pilcrow">¶</a></p>
<p id="section-7-13">
        The INFO request also indicates that the Answerer accepted the suggested Offerer BUNDLE address.
        This allows the Offerer to omit gathering RTP and RTCP candidates for the other "m=" lines
        or releasing already gathered candidates.
        If the INFO request did not contain the "group:BUNDLE" attribute, the Offerer has to gather
        RTP and RTCP  candidates for the other "m=" lines  unless it wants to wait until receipt
        of an Answer that eventually confirms
        support or non-support for Media Multiplexing.<a href="#section-7-13" class="pilcrow">¶</a></p>
<p id="section-7-14">
        Independent of using Full Trickle or Half Trickle mode, the rules from
         <span>[<a href="#RFC8859" class="xref">RFC8859</a>]</span> apply to both, Offerer and Answerer,
        when putting attributes as specified in
        <a href="#trickle_ice_sdpfrag_grammar" class="xref">Section 9.2</a>
         in the "application/trickle-ice-sdpfrag" body.<a href="#section-7-14" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-eoc">
<section id="section-8">
      <h2 id="name-sdp-end-of-candidates-attri">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-sdp-end-of-candidates-attri" class="section-name selfRef">SDP "end-of-candidates" Attribute</a>
      </h2>
<div id="eoc-def">
<section id="section-8.1">
        <h3 id="name-definition">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-definition" class="section-name selfRef">Definition</a>
        </h3>
<p id="section-8.1-1">
      This section defines the new SDP media-level and session-level
      <span>[<a href="#RFC4566" class="xref">RFC4566</a>]</span>
      "end-of-candidates" attribute. "end-of-candidates" is a property attribute
      <span>[<a href="#RFC4566" class="xref">RFC4566</a>]</span>; hence, it has no value.
      By including this attribute in an Offer or Answer, the sending agent indicates
      that it will not trickle further candidates.
      When included at the session level, this indication applies to the whole session;
      when included at the media level, the indication applies only to the corresponding media description.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-8.1-2.1">
            <span class="break"></span><dl class="dlParallel" id="section-8.1-2.1.1">
              <dt id="section-8.1-2.1.1.1">Name:</dt>
              <dd style="margin-left: 1.5em" id="section-8.1-2.1.1.2">end-of-candidates<a href="#section-8.1-2.1.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-8.1-2.1.1.3">Value:</dt>
              <dd style="margin-left: 1.5em" id="section-8.1-2.1.1.4">N/A<a href="#section-8.1-2.1.1.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-8.1-2.1.1.5">Usage Level:</dt>
              <dd style="margin-left: 1.5em" id="section-8.1-2.1.1.6">media and session level<a href="#section-8.1-2.1.1.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-8.1-2.1.1.7">Charset Dependent:</dt>
              <dd style="margin-left: 1.5em" id="section-8.1-2.1.1.8">no<a href="#section-8.1-2.1.1.8" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-8.1-2.1.1.9">Mux Category:</dt>
              <dd style="margin-left: 1.5em" id="section-8.1-2.1.1.10">IDENTICAL<a href="#section-8.1-2.1.1.10" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-8.1-2.1.1.11">Example:</dt>
              <dd style="margin-left: 1.5em" id="section-8.1-2.1.1.12">a=end-of-candidates<a href="#section-8.1-2.1.1.12" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</li>
        </ul>
</section>
</div>
<div id="eoc-ind">
<section id="section-8.2">
        <h3 id="name-offer-answer-procedures">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-offer-answer-procedures" class="section-name selfRef">Offer/Answer Procedures</a>
        </h3>
<p id="section-8.2-1">The Offerer or Answerer <span class="bcp14">MAY</span> include an "end-of-candidates" attribute
          in case candidate discovery has ended
          and no further candidates are to be trickled.
          The Offerer or Answerer <span class="bcp14">MUST</span> provide the "end-of-candidates" attribute
          together with the "ice-ufrag" and "ice-pwd" attributes of the current
          ICE generation as required by
          <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span>.
          When included at the session level,
          this indication applies to the whole session;
          when included at the media level, the indication applies
          only to the corresponding media description.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
<p id="section-8.2-2">
          Receipt of an "end-of-candidates" attribute at an
          Offerer or Answerer
          -- with the "ice-ufrag" and "ice-pwd" attributes matching the current ICE generation --
          indicates that the gathering of candidates
          has ended at the peer, for either the session or only the
          corresponding media description as specified above.
          The receiving agent forwards an end-of-candidates indication
          to the ICE Agent, which in turn acts as specified in
          <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span>.<a href="#section-8.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="trickle_ice_sdpfrag_def">
<section id="section-9">
      <h2 id="name-content-type-application-tr">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-content-type-application-tr" class="section-name selfRef">Content Type "application/trickle-ice-sdpfrag"</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-overall-description">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-overall-description" class="section-name selfRef">Overall Description</a>
        </h3>
<p id="section-9.1-1">
        An "application/trickle-ice-sdpfrag" body is used exclusively by the "trickle-ice" Info Package.
        Other SDP-related applications need to define their own media type.
        The INFO request body uses a subset of the possible SDP lines
        as defined by the grammar in <span>[<a href="#RFC4566" class="xref">RFC4566</a>]</span>.
        A valid body uses only pseudo "m=" lines and certain attributes
        that are needed and/or useful for trickling candidates.
        The content adheres to the following grammar.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
</section>
<div id="trickle_ice_sdpfrag_grammar">
<section id="section-9.2">
        <h3 id="name-grammar">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-grammar" class="section-name selfRef">Grammar</a>
        </h3>
<p id="section-9.2-1">
           The grammar of an "application/trickle-ice-sdpfrag" body is
           based on the following ABNF <span>[<a href="#RFC5234" class="xref">RFC5234</a>]</span>.
           It specifies the subset of existing SDP attributes
           that is needed or useful for trickling candidates.
           The grammar uses the indicator for case-sensitive %s,
           as defined in <span>[<a href="#RFC7405" class="xref">RFC7405</a>]</span>,
           but it also imports grammar for other SDP attributes that
           precede the production of <span>[<a href="#RFC7405" class="xref">RFC7405</a>]</span>.
           A sender <span class="bcp14">SHOULD</span> use lower case for attributes
           from such earlier grammar, but a receiver <span class="bcp14">MUST</span> treat
           them as case insensitive.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
<div id="section-9.2-2">
<pre class="sourcecode lang-abnf">
   ;  Syntax
   trickle-ice-sdpfrag =   session-level-fields
                     pseudo-media-descriptions
   session-level-fields = *(session-level-field CRLF)

   session-level-field =  ice-lite-attribute /
                     ice-pwd-attribute /
                     ice-ufrag-attribute /
                     ice-options-attribute /
                     ice-pacing-attribute /
                     end-of-candidates-attribute /
                     bundle-group-attribute /
                     extension-attribute-fields
                                         ; for future extensions

   ice-lite-attribute     = %s"a" "=" ice-lite
   ice-pwd-attribute      = %s"a" "=" ice-pwd-att
   ice-ufrag-attribute    = %s"a" "=" ice-ufrag-att
   ice-pacing-attribute   = %s"a" "=" ice-pacing-att
   ice-options-attribute  = %s"a" "=" ice-options
   end-of-candidates-attribute  = %s"a" "=" end-of-candidates
   end-of-candidates            = %s"end-of-candidates"
   bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics
                              *(SP identification-tag)
   bundle-semantics = "BUNDLE"
   extension-attribute-fields   = attribute-fields

   pseudo-media-descriptions    =  *( media-field
                              trickle-ice-attribute-fields )
   trickle-ice-attribute-fields = *(trickle-ice-attribute-field CRLF)
   trickle-ice-attribute-field = mid-attribute /
                           candidate-attributes /
                           ice-pwd-attribute  /
                           ice-ufrag-attribute /
                           remote-candidate-attribute /
                           end-of-candidates-attribute /
                           rtcp-attribute /
                           rtcp-mux-attribute /
                           rtcp-mux-only-attribute /
                           extension-attribute-fields
                                           ; for future extensions

   rtcp-attribute                = %s"a" "=" %s"rtcp"
   rtcp-mux-attribute            = %s"a" "=" %s"rtcp-mux"
   rtcp-mux-only-attribute       = %s"a" "=" %s"rtcp-mux-only"
   candidate-attributes          = %s"a" "=" candidate-attribute
   remote-candidate-attribute    = %s"a" "=" remote-candidate-att</pre><a href="#section-9.2-2" class="pilcrow">¶</a>
</div>
<p id="section-9.2-3">
   ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-pacing-att,
   ice-options, candidate-attribute, and remote-candidate-att are from <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span>; identification-tag and mid-attribute are from <span>[<a href="#RFC5888" class="xref">RFC5888</a>]</span>; and media-field and attribute-fields are from <span>[<a href="#RFC4566" class="xref">RFC4566</a>]</span>.  The "rtcp" attribute is defined in <span>[<a href="#RFC3605" class="xref">RFC3605</a>]</span>, the "rtcp-mux" attribute is defined
   in <span>[<a href="#RFC5761" class="xref">RFC5761</a>]</span>, and the "rtcp-mux-only"
   attribute is defined in <span>[<a href="#RFC8858" class="xref">RFC8858</a>]</span>.  The
   latter attributes lack formal grammar in their corresponding RFCs and are
   reproduced here.<a href="#section-9.2-3" class="pilcrow">¶</a></p>
<p id="section-9.2-4">
          The "ice-pwd" and "ice-ufrag" attributes <span class="bcp14">MUST</span> appear at the
          same level as the ones in the Offer/Answer exchange.  In other words,
          if they were present as session-level attributes, they will also
          appear at the beginning of all INFO request payloads, i.e., preceding
          all pseudo "m=" lines.  If they were originally exchanged as media-level
          attributes, potentially overriding session-level values, then
          they will also be included in INFO request payloads following the
          corresponding pseudo "m=" lines.<a href="#section-9.2-4" class="pilcrow">¶</a></p>
<p id="section-9.2-5">
         An Agent <span class="bcp14">MUST</span> ignore any received unknown extension-attribute-fields.<a href="#section-9.2-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="info-package">
<section id="section-10">
      <h2 id="name-info-package">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-info-package" class="section-name selfRef">Info Package</a>
      </h2>
<div id="rationale">
<section id="section-10.1">
        <h3 id="name-rationale-why-info">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-rationale-why-info" class="section-name selfRef">Rationale -- Why INFO?</a>
        </h3>
<p id="section-10.1-1">
          The decision to use SIP INFO requests as a candidate transport
          method is based primarily on their lightweight nature. Once a
          dialog has been established, INFO requests can be exchanged
          both ways with no restrictions on timing and frequency and no
          risk of collision.<a href="#section-10.1-1" class="pilcrow">¶</a></p>
<p id="section-10.1-2"> A critical fact is that the sending of Trickle ICE candidates
        in one direction is entirely uncoupled from sending candidates
        in the other direction.
        Thus, the sending of candidates in each direction can be
        done by a stream of INFO requests that is not correlated with
        the stream of INFO requests in the other direction.
        And since each INFO request cumulatively includes
        the contents of all previous INFO requests in that direction,
        the ordering between INFO requests need not be preserved.
        All of this permits using largely independent INFO requests.<a href="#section-10.1-2" class="pilcrow">¶</a></p>
<p id="section-10.1-3">
            Contrarily, UPDATE or other Offer/Answer mechanisms assume
            that the messages in each direction are tightly coupled
            with messages in the other direction.
            Using Offer/Answer and UPDATE requests
          <span>[<a href="#RFC3311" class="xref">RFC3311</a>]</span>
          would introduce the following complications:<a href="#section-10.1-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-10.1-4">
          <dt id="section-10.1-4.1">Blocking of messages: </dt>
          <dd style="margin-left: 1.5em" id="section-10.1-4.2">
              Offer/Answer is defined as a
              strictly sequential mechanism in <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span>.
              There can only be a maximum of one active exchange
              at any point of time.
              Both sides cannot simultaneously send Offers nor
              can they generate multiple Offers prior to
              receiving an Answer.
              Using UPDATE requests for
              candidate transport would therefore imply the
              implementation of a candidate pool at every agent where
              candidates can be stored until it is once again that
              agent's "turn" to emit an Answer or a new Offer.
              Such an approach would introduce non-negligible
              complexity for no additional value.<a href="#section-10.1-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-10.1-4.3">Elevated risk of glare: </dt>
          <dd style="margin-left: 1.5em" id="section-10.1-4.4">
              The sequential nature of Offer/Answer also makes it
              impossible for both sides to send Offers simultaneously.
              What's worse is that there are no mechanisms in SIP to
              actually prevent that. <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span>, where
              the situation of Offers crossing on the wire is described
              as "glare", only defines a procedure for addressing the
              issue after it has occurred. According to that procedure,
              both Offers are invalidated and both sides need to retry
              the negotiation after a period between 0 and 4 seconds.

              The high likelihood for glare and the average two-second
              backoff intervals to occur implies that the duration of
              Trickle ICE processing would not only fail to improve but
              actually exceed those of regular ICE.<a href="#section-10.1-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-10.1-5">
          INFO messages decouple the exchange of candidates from the
          Offer/Answer negotiation
          and are subject to none of the glare issues described above,
          which makes them a very convenient and lightweight mechanism
          for asynchronous delivery of candidates.<a href="#section-10.1-5" class="pilcrow">¶</a></p>
<p id="section-10.1-6">
          Using in-dialog INFO messages also provides a way of
          guaranteeing that candidates are delivered end to end, between
          the same entities that are actually in the process of
          initiating a session. Out-of-dialog alternatives would have implied
          requiring support for GRUU
          <span>[<a href="#RFC5627" class="xref">RFC5627</a>]</span> that, given GRUUs relatively low
          adoption levels, would have constituted too strong of a
          constraint to the adoption of Trickle ICE.<a href="#section-10.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-10.2">
        <h3 id="name-overall-description-2">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-overall-description-2" class="section-name selfRef">Overall Description</a>
        </h3>
<p id="section-10.2-1">
          This specification defines an Info Package for use by
          SIP UAs implementing Trickle ICE.
          INFO requests carry ICE candidates discovered after the peer UAs have confirmed mutual support for Trickle ICE.<a href="#section-10.2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-10.3">
        <h3 id="name-applicability">
<a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-applicability" class="section-name selfRef">Applicability</a>
        </h3>
<p id="section-10.3-1">
          The purpose of the ICE protocol is to establish a media path
          in the presence of NAT and firewalls.
          The candidates are transported in INFO requests and are
           part of this establishment.<a href="#section-10.3-1" class="pilcrow">¶</a></p>
<p id="section-10.3-2">
          Candidates sent by a Trickle ICE Agent after the Offer
          follow the same signaling path and reach the same
          entity as the Offer itself. While it is true that GRUUs can
          be used to achieve this, one of the goals of this
          specification is to allow operation of Trickle ICE in as many
          environments as possible including those without GRUU support.
          Using out-of-dialog SUBSCRIBE/NOTIFY requests would not
          satisfy this goal.<a href="#section-10.3-2" class="pilcrow">¶</a></p>
</section>
<section id="section-10.4">
        <h3 id="name-info-package-name">
<a href="#section-10.4" class="section-number selfRef">10.4. </a><a href="#name-info-package-name" class="section-name selfRef">Info Package Name</a>
        </h3>
<p id="section-10.4-1">
          This document defines a SIP Info Package as per
          <span>[<a href="#RFC6086" class="xref">RFC6086</a>]</span>. The Info Package token name for this
          package is "trickle-ice".<a href="#section-10.4-1" class="pilcrow">¶</a></p>
</section>
<section id="section-10.5">
        <h3 id="name-info-package-parameters">
<a href="#section-10.5" class="section-number selfRef">10.5. </a><a href="#name-info-package-parameters" class="section-name selfRef">Info Package Parameters</a>
        </h3>
<p id="section-10.5-1">
          This document does not define any Info Package parameters.<a href="#section-10.5-1" class="pilcrow">¶</a></p>
</section>
<div id="option-tag">
<section id="section-10.6">
        <h3 id="name-sip-option-tags">
<a href="#section-10.6" class="section-number selfRef">10.6. </a><a href="#name-sip-option-tags" class="section-name selfRef">SIP Option Tags</a>
        </h3>
<p id="section-10.6-1">
          <span>[<a href="#RFC6086" class="xref">RFC6086</a>]</span> allows Info Package specifications to
          define SIP option-tags. This specification extends the option-tag
          construct of the SIP grammar as follows:<a href="#section-10.6-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-10.6-2">
<pre>
 option-tag /= "trickle-ice"</pre><a href="#section-10.6-2" class="pilcrow">¶</a>
</div>
<p id="section-10.6-3">
         SIP entities that support this
          specification <span class="bcp14">MUST</span> place the "trickle-ice" option-tag in a SIP
          Supported: or Require: header field within
          all SIP INVITE requests and responses.<a href="#section-10.6-3" class="pilcrow">¶</a></p>
<p id="section-10.6-4">
          When responding to, or generating, a SIP OPTIONS request, a SIP
          entity <span class="bcp14">MUST</span> also include the "trickle-ice" option-tag in a SIP
          Supported: or Require: header field.<a href="#section-10.6-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-10.7">
        <h3 id="name-info-request-body-parts">
<a href="#section-10.7" class="section-number selfRef">10.7. </a><a href="#name-info-request-body-parts" class="section-name selfRef">INFO Request Body Parts</a>
        </h3>
<p id="section-10.7-1">
          Entities implementing this specification <span class="bcp14">MUST</span> include a
          payload of type "application/trickle-ice-sdpfrag" in SIP INFO requests as defined
          in <a href="#trickle_ice_sdpfrag_grammar" class="xref">Section 9.2</a>.
          The payload is used to convey SDP-encoded ICE candidates.<a href="#section-10.7-1" class="pilcrow">¶</a></p>
</section>
<section id="section-10.8">
        <h3 id="name-info-package-usage-restrict">
<a href="#section-10.8" class="section-number selfRef">10.8. </a><a href="#name-info-package-usage-restrict" class="section-name selfRef">Info Package Usage Restrictions</a>
        </h3>
<p id="section-10.8-1">
           This document does not define any Info Package Usage Restrictions.<a href="#section-10.8-1" class="pilcrow">¶</a></p>
</section>
<section id="section-10.9">
        <h3 id="name-rate-of-info-requests">
<a href="#section-10.9" class="section-number selfRef">10.9. </a><a href="#name-rate-of-info-requests" class="section-name selfRef">Rate of INFO Requests</a>
        </h3>
<p id="section-10.9-1">
           Given that IP addresses may be gathered rapidly, a
           Trickle ICE Agent with many network interfaces might create a
           high rate of INFO requests if every newly
           detected candidate is trickled individually without aggregation.
          An implementation <span class="bcp14">MUST</span> aggregate ICE candidates in case an
          unreliable transport protocol such as UDP is used.
          A Trickle ICE Agent <span class="bcp14">MUST NOT</span> have more than one INFO request
          pending at any one time.
          When INFO messages are sent over an unreliable transport,
          they are retransmitted according to the rules specified in
          <span>[<a href="#RFC3261" class="xref">RFC3261</a>], <a href="https://www.rfc-editor.org/rfc/rfc3261#section-17.1.2.1" class="relref">Section 17.1.2.1</a></span>.<a href="#section-10.9-1" class="pilcrow">¶</a></p>
<p id="section-10.9-2">
        If the INFO requests are sent on top of TCP,
        which is probably the standard way,
        it is not an issue for the network anymore,
        but it can remain one for SIP proxies and other intermediaries
        forwarding the SIP INFO messages.
        Also, an endpoint may not be able to tell that it has congestion
        controlled transport all the way.<a href="#section-10.9-2" class="pilcrow">¶</a></p>
</section>
<section id="section-10.10">
        <h3 id="name-info-package-security-consi">
<a href="#section-10.10" class="section-number selfRef">10.10. </a><a href="#name-info-package-security-consi" class="section-name selfRef">Info Package Security Considerations</a>
        </h3>
<p id="section-10.10-1">
           See <a href="#sec-cons" class="xref">Section 13</a>.<a href="#section-10.10-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="deploy-cons">
<section id="section-11">
      <h2 id="name-deployment-considerations">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-deployment-considerations" class="section-name selfRef">Deployment Considerations</a>
      </h2>
<p id="section-11-1">
        Trickle ICE uses two mechanisms for the exchange of candidate information.
        This imposes new requirements to certain middleboxes
        that are used in some networks, e.g., for monitoring purposes.
        While the first mechanism, SDP Offers and Answers,
         is already used by regular ICE and is assumed to be supported,
          the second mechanism, INFO request bodies,
          needs to be considered by such middleboxes as well when
         trickle ICE is used.
         Such middleboxes need to make sure that they remain
         in the signaling path of the INFO requests and
         understand the INFO request body.<a href="#section-11-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA">
<section id="section-12">
      <h2 id="name-iana-considerations">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<div id="sec-eoc-iana">
<section id="section-12.1">
        <h3 id="name-sdp-end-of-candidates-attrib">
<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-sdp-end-of-candidates-attrib" class="section-name selfRef">SDP "end-of-candidates" Attribute</a>
        </h3>
<p id="section-12.1-1">
      This section defines a new SDP media-level and session-level
      <span>[<a href="#RFC4566" class="xref">RFC4566</a>]</span> "end-of-candidates" attribute, which is a property attribute
      <span>[<a href="#RFC4566" class="xref">RFC4566</a>]</span> and hence has no value.<a href="#section-12.1-1" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-12.1-2.1">
            <span class="break"></span><dl class="dlParallel" id="section-12.1-2.1.1">
              <dt id="section-12.1-2.1.1.1">Name:</dt>
              <dd style="margin-left: 1.5em" id="section-12.1-2.1.1.2">end-of-candidates<a href="#section-12.1-2.1.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-12.1-2.1.1.3">Value:</dt>
              <dd style="margin-left: 1.5em" id="section-12.1-2.1.1.4">N/A<a href="#section-12.1-2.1.1.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-12.1-2.1.1.5">Usage Level:</dt>
              <dd style="margin-left: 1.5em" id="section-12.1-2.1.1.6">media and session<a href="#section-12.1-2.1.1.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-12.1-2.1.1.7">Charset Dependent:</dt>
              <dd style="margin-left: 1.5em" id="section-12.1-2.1.1.8">no<a href="#section-12.1-2.1.1.8" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-12.1-2.1.1.9">Purpose:</dt>
              <dd style="margin-left: 1.5em" id="section-12.1-2.1.1.10">The sender indicates that it will not trickle
            further ICE candidates.<a href="#section-12.1-2.1.1.10" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-12.1-2.1.1.11">O/A Procedures:</dt>
              <dd style="margin-left: 1.5em" id="section-12.1-2.1.1.12">RFC 8840 defines the detailed
                   SDP Offer/Answer procedures for
                   the "end-of-candidates" attribute.<a href="#section-12.1-2.1.1.12" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-12.1-2.1.1.13">Mux Category:</dt>
              <dd style="margin-left: 1.5em" id="section-12.1-2.1.1.14">IDENTICAL<a href="#section-12.1-2.1.1.14" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-12.1-2.1.1.15">Reference:</dt>
              <dd style="margin-left: 1.5em" id="section-12.1-2.1.1.16">RFC 8840<a href="#section-12.1-2.1.1.16" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-12.1-2.1.1.17">Example:</dt>
              <dd style="margin-left: 1.5em" id="section-12.1-2.1.1.18">a=end-of-candidates<a href="#section-12.1-2.1.1.18" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</li>
        </ul>
</section>
</div>
<div id="sdpfrag-reg">
<section id="section-12.2">
        <h3 id="name-media-type-application-tric">
<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-media-type-application-tric" class="section-name selfRef">Media Type "application/trickle-ice-sdpfrag"</a>
        </h3>
<p id="section-12.2-1">
      This document defines the new media type "application/trickle-ice-sdpfrag"
      in accordance with <span>[<a href="#RFC6838" class="xref">RFC6838</a>]</span>.<a href="#section-12.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-12.2-2">
          <dt id="section-12.2-2.1">Type name:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.2">application<a href="#section-12.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.3">Subtype name:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.4">trickle-ice-sdpfrag<a href="#section-12.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.5">Required parameters:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.6">None.<a href="#section-12.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.7">Optional parameters:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.8">None.<a href="#section-12.2-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.9">Encoding considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.10">
            <p id="section-12.2-2.10.1">
            The media contents follow the same rules as SDP,
            except as noted in this document.
            The media contents are text, with the grammar specified
            in <a href="#trickle_ice_sdpfrag_grammar" class="xref">Section 9.2</a>.<a href="#section-12.2-2.10.1" class="pilcrow">¶</a></p>
<p id="section-12.2-2.10.2">
            Although the initially defined content of a trickle-ice-sdpfrag body
            does only include ASCII characters,
            UTF-8-encoded content might be introduced via extension attributes.
            The "charset" attribute may be used to signal the presence of other
            character sets in certain parts of a trickle-ice-sdpfrag body (see
            <span>[<a href="#RFC4566" class="xref">RFC4566</a>]</span>).
            Arbitrary binary content cannot be directly represented
            in SDP or a trickle-ice-sdpfrag body.<a href="#section-12.2-2.10.2" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.11">Security considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.12">See <span>[<a href="#RFC4566" class="xref">RFC4566</a>]</span> and RFC 8840<a href="#section-12.2-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.13">Interoperability considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.14">See RFC 8840<a href="#section-12.2-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.15">Published specification:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.16">See RFC 8840<a href="#section-12.2-2.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.17">Applications that use this media type:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.18">Trickle ICE<a href="#section-12.2-2.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.19">Fragment identifier considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.20">N/A<a href="#section-12.2-2.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.21">Additional information:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.22">
            <p id="section-12.2-2.22.1"><br></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-12.2-2.22.2">
              <dt id="section-12.2-2.22.2.1">Deprecated alias names for this type:</dt>
              <dd style="margin-left: 1.5em" id="section-12.2-2.22.2.2">N/A<a href="#section-12.2-2.22.2.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-12.2-2.22.2.3">Magic number(s):</dt>
              <dd style="margin-left: 1.5em" id="section-12.2-2.22.2.4">N/A<a href="#section-12.2-2.22.2.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-12.2-2.22.2.5">File extension(s):</dt>
              <dd style="margin-left: 1.5em" id="section-12.2-2.22.2.6">N/A<a href="#section-12.2-2.22.2.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-12.2-2.22.2.7">Macintosh File Type Code(s):</dt>
              <dd style="margin-left: 1.5em" id="section-12.2-2.22.2.8">N/A<a href="#section-12.2-2.22.2.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.23">Person and email address to contact for further information:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.24">The IESG (iesg@ietf.org)<a href="#section-12.2-2.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.25">Intended usage:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.26">Trickle ICE for SIP as specified in RFC 8840.<a href="#section-12.2-2.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.27">Restrictions on usage:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.28">N/A<a href="#section-12.2-2.28" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.29">Author/Change controller:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.30">The IESG (iesg@ietf.org)<a href="#section-12.2-2.30" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.31">Provisional registration? (standards tree only):</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.32">N/A<a href="#section-12.2-2.32" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="package-reg">
<section id="section-12.3">
        <h3 id="name-sip-info-package-trickle-ic">
<a href="#section-12.3" class="section-number selfRef">12.3. </a><a href="#name-sip-info-package-trickle-ic" class="section-name selfRef">SIP Info Package "trickle-ice"</a>
        </h3>
<p id="section-12.3-1">
              This document defines a new SIP Info Package named "trickle-ice"
              and updates the "Info Packages Registry" with the following entry.<a href="#section-12.3-1" class="pilcrow">¶</a></p>
<div id="table_1">
<table class="left" id="table-1">
          <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
<thead>
            <tr>
              <th class="text-center" rowspan="1" colspan="1">Name</th>
              <th class="text-center" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">trickle-ice</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8840</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
<div id="optag-reg">
<section id="section-12.4">
        <h3 id="name-sip-option-tag-trickle-ice">
<a href="#section-12.4" class="section-number selfRef">12.4. </a><a href="#name-sip-option-tag-trickle-ice" class="section-name selfRef">SIP Option Tag "trickle-ice"</a>
        </h3>
<p id="section-12.4-1">
              This specification registers a new SIP option tag "trickle-ice"
              as per the guidelines in <span><a href="https://www.rfc-editor.org/rfc/rfc3261#section-27.1" class="relref">Section 27.1</a> of [<a href="#RFC3261" class="xref">RFC3261</a>]</span>
              and updates the "Option Tags" subregistry of the
              SIP Parameters registry  with the following entry:<a href="#section-12.4-1" class="pilcrow">¶</a></p>
<div id="table_2">
<table class="left" id="table-2">
          <caption><a href="#table-2" class="selfRef">Table 2</a></caption>
<thead>
            <tr>
              <th class="text-center" rowspan="1" colspan="1">Name</th>
              <th class="text-center" rowspan="1" colspan="1">Description</th>
              <th class="text-center" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">trickle‑ice</td>
              <td class="text-left" rowspan="1" colspan="1">This option tag is used to indicate that a UA supports and understands Trickle ICE.</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8840</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
</section>
</div>
<div id="sec-cons">
<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 Security Considerations of
        <span>[<a href="#RFC6086" class="xref">RFC6086</a>]</span>,  <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span>, and
        <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span> apply.
        This document clarifies how the above specifications are used together for trickling
        candidates and does not create additional security risks.<a href="#section-13-1" class="pilcrow">¶</a></p>
<p id="section-13-2">
      The new Info Package "trickle-ice" and
      the new media type "application/trickle-ice-sdpfrag"
      do not introduce additional security considerations
      when used in the context of Trickle ICE.
      Both are not intended to be used for other applications,
      so any security considerations for its use in other contexts
      is out of the scope of this document<a href="#section-13-2" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-14">
      <h2 id="name-references">
<a href="#section-14" class="section-number selfRef">14. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-14.1">
        <h3 id="name-normative-references">
<a href="#section-14.1" class="section-number selfRef">14.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="RFC3261">[RFC3261]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor">, Schulzrinne, H.</span><span class="refAuthor">, Camarillo, G.</span><span class="refAuthor">, Johnston, A.</span><span class="refAuthor">, Peterson, J.</span><span class="refAuthor">, Sparks, R.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, and E. Schooler</span>, <span class="refTitle">"SIP: Session Initiation Protocol"</span>, <span class="seriesInfo">RFC 3261</span>, <span class="seriesInfo">DOI 10.17487/RFC3261</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3261">https://www.rfc-editor.org/info/rfc3261</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3262">[RFC3262]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor"> and H. Schulzrinne</span>, <span class="refTitle">"Reliability of Provisional Responses in Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 3262</span>, <span class="seriesInfo">DOI 10.17487/RFC3262</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3262">https://www.rfc-editor.org/info/rfc3262</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3264">[RFC3264]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor"> and H. Schulzrinne</span>, <span class="refTitle">"An Offer/Answer Model with Session Description Protocol (SDP)"</span>, <span class="seriesInfo">RFC 3264</span>, <span class="seriesInfo">DOI 10.17487/RFC3264</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3264">https://www.rfc-editor.org/info/rfc3264</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3605">[RFC3605]</dt>
        <dd>
<span class="refAuthor">Huitema, C.</span>, <span class="refTitle">"Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)"</span>, <span class="seriesInfo">RFC 3605</span>, <span class="seriesInfo">DOI 10.17487/RFC3605</span>, <time datetime="2003-10" class="refDate">October 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3605">https://www.rfc-editor.org/info/rfc3605</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="RFC5234">[RFC5234]</dt>
        <dd>
<span class="refAuthor">Crocker, D., Ed.</span><span class="refAuthor"> and P. Overell</span>, <span class="refTitle">"Augmented BNF for Syntax Specifications: ABNF"</span>, <span class="seriesInfo">STD 68</span>, <span class="seriesInfo">RFC 5234</span>, <span class="seriesInfo">DOI 10.17487/RFC5234</span>, <time datetime="2008-01" class="refDate">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</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="RFC5888">[RFC5888]</dt>
        <dd>
<span class="refAuthor">Camarillo, G.</span><span class="refAuthor"> and H. Schulzrinne</span>, <span class="refTitle">"The Session Description Protocol (SDP) Grouping Framework"</span>, <span class="seriesInfo">RFC 5888</span>, <span class="seriesInfo">DOI 10.17487/RFC5888</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5888">https://www.rfc-editor.org/info/rfc5888</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6086">[RFC6086]</dt>
        <dd>
<span class="refAuthor">Holmberg, C.</span><span class="refAuthor">, Burger, E.</span><span class="refAuthor">, and H. Kaplan</span>, <span class="refTitle">"Session Initiation Protocol (SIP) INFO Method and Package Framework"</span>, <span class="seriesInfo">RFC 6086</span>, <span class="seriesInfo">DOI 10.17487/RFC6086</span>, <time datetime="2011-01" class="refDate">January 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6086">https://www.rfc-editor.org/info/rfc6086</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6838">[RFC6838]</dt>
        <dd>
<span class="refAuthor">Freed, N.</span><span class="refAuthor">, Klensin, J.</span><span class="refAuthor">, and T. Hansen</span>, <span class="refTitle">"Media Type Specifications and Registration Procedures"</span>, <span class="seriesInfo">BCP 13</span>, <span class="seriesInfo">RFC 6838</span>, <span class="seriesInfo">DOI 10.17487/RFC6838</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6838">https://www.rfc-editor.org/info/rfc6838</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7405">[RFC7405]</dt>
        <dd>
<span class="refAuthor">Kyzivat, P.</span>, <span class="refTitle">"Case-Sensitive String Support in ABNF"</span>, <span class="seriesInfo">RFC 7405</span>, <span class="seriesInfo">DOI 10.17487/RFC7405</span>, <time datetime="2014-12" class="refDate">December 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7405">https://www.rfc-editor.org/info/rfc7405</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="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="RFC8838">[RFC8838]</dt>
        <dd>
<span class="refAuthor">Ivov, E.</span><span class="refAuthor">, Uberti, J.</span><span class="refAuthor">, and P. Saint-Andre</span>, <span class="refTitle">"Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol"</span>, <span class="seriesInfo">RFC 8838</span>, <span class="seriesInfo">DOI 10.17487/RFC8838</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8838">https://www.rfc-editor.org/info/rfc8838</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8839">[RFC8839]</dt>
        <dd>
<span class="refAuthor">Petit-Huguenin, M.</span><span class="refAuthor">, Nandakumar, S.</span><span class="refAuthor">, Holmberg, C.</span><span class="refAuthor">, Keränen, A.</span><span class="refAuthor">, and R. Shpount</span>, <span class="refTitle">"Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)"</span>, <span class="seriesInfo">RFC 8839</span>, <span class="seriesInfo">DOI 10.17487/RFC8839</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8839">https://www.rfc-editor.org/info/rfc8839</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="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="RFC8859">[RFC8859]</dt>
      <dd>
<span class="refAuthor">Nandakumar, S.</span>, <span class="refTitle">"A Framework for Session Description Protocol (SDP) Attributes When Multiplexing"</span>, <span class="seriesInfo">RFC 8859</span>, <span class="seriesInfo">DOI 10.17487/RFC8859</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8859">https://www.rfc-editor.org/info/rfc8859</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-14.2">
        <h3 id="name-informative-references">
<a href="#section-14.2" class="section-number selfRef">14.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC3311">[RFC3311]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span>, <span class="refTitle">"The Session Initiation Protocol (SIP) UPDATE Method"</span>, <span class="seriesInfo">RFC 3311</span>, <span class="seriesInfo">DOI 10.17487/RFC3311</span>, <time datetime="2002-10" class="refDate">October 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3311">https://www.rfc-editor.org/info/rfc3311</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3840">[RFC3840]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor">, Schulzrinne, H.</span><span class="refAuthor">, and P. Kyzivat</span>, <span class="refTitle">"Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 3840</span>, <span class="seriesInfo">DOI 10.17487/RFC3840</span>, <time datetime="2004-08" class="refDate">August 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3840">https://www.rfc-editor.org/info/rfc3840</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5389">[RFC5389]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor">, Mahy, R.</span><span class="refAuthor">, Matthews, P.</span><span class="refAuthor">, and D. Wing</span>, <span class="refTitle">"Session Traversal Utilities for NAT (STUN)"</span>, <span class="seriesInfo">RFC 5389</span>, <span class="seriesInfo">DOI 10.17487/RFC5389</span>, <time datetime="2008-10" class="refDate">October 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5389">https://www.rfc-editor.org/info/rfc5389</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5627">[RFC5627]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span>, <span class="refTitle">"Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 5627</span>, <span class="seriesInfo">DOI 10.17487/RFC5627</span>, <time datetime="2009-10" class="refDate">October 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5627">https://www.rfc-editor.org/info/rfc5627</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5766">[RFC5766]</dt>
      <dd>
<span class="refAuthor">Mahy, R.</span><span class="refAuthor">, Matthews, P.</span><span class="refAuthor">, and J. Rosenberg</span>, <span class="refTitle">"Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"</span>, <span class="seriesInfo">RFC 5766</span>, <span class="seriesInfo">DOI 10.17487/RFC5766</span>, <time datetime="2010-04" class="refDate">April 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5766">https://www.rfc-editor.org/info/rfc5766</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<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 like to thank
        <span class="contact-name">Flemming Andreasen</span>,
        <span class="contact-name">Ayush Jain</span>,
        <span class="contact-name">Paul Kyzivat</span>,
        <span class="contact-name">Jonathan Lennox</span>,
        <span class="contact-name">Simon Perreault</span>,
        <span class="contact-name">Roman Shpount</span>,
        and
        <span class="contact-name">Martin Thomson</span>
        for reviewing and/or making various suggestions for
        improvements and optimizations.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">
        The authors also like to thank
        <span class="contact-name">Flemming Andreasen</span> for shepherding this document and
        <span class="contact-name">Ben Campbell</span> for his AD review and suggestions.
        In addition, the authors thank
        <span class="contact-name">Benjamin Kaduk</span>,
        <span class="contact-name">Adam Roach</span>,
        <span class="contact-name">Mirja Kühlewind</span>, and
        <span class="contact-name">Eric Rescorla</span>
        for their comments and/or text proposals for improving
        the document during IESG review.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">
        Many thanks to <span class="contact-name">Dale Worley</span> for the Gen-Art review and proposed
        enhancements for several sections.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
<p id="section-appendix.a-4">
        Many thanks to <span class="contact-name">Joerg Ott</span> for the TSV-Art review and suggested improvements.<a href="#section-appendix.a-4" class="pilcrow">¶</a></p>
<p id="section-appendix.a-5">
          The authors thank <span class="contact-name">Shawn Emery</span> for the Security Directorate review.<a href="#section-appendix.a-5" class="pilcrow">¶</a></p>
</section>
<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">Emil Ivov</span></div>
<div dir="auto" class="left"><span class="org">Jitsi</span></div>
<div dir="auto" class="left">
<span class="postal-code">67000</span> <span class="locality">Strasbourg</span>
</div>
<div dir="auto" class="left"><span class="country-name">France</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+33%206%2072%2081%2015%2055" class="tel">+33 6 72 81 15 55</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:emcho@jitsi.org" class="email">emcho@jitsi.org</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Thomas Stach</span></div>
<div dir="auto" class="left"><span class="org">Unaffiliated</span></div>
<div dir="auto" class="left">
<span class="postal-code">1130</span> <span class="locality">Vienna</span>
</div>
<div dir="auto" class="left"><span class="country-name">Austria</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:thomass.stach@gmail.com" class="email">thomass.stach@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Enrico Marocco</span></div>
<div dir="auto" class="left"><span class="org">Telecom Italia</span></div>
<div dir="auto" class="left"><span class="street-address">Via G. Reiss Romoli, 274</span></div>
<div dir="auto" class="left">
<span class="postal-code">10148</span> <span class="locality">Turin</span> </div>
<div dir="auto" class="left"><span class="country-name">Italy</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:enrico.marocco@telecomitalia.it" class="email">enrico.marocco@telecomitalia.it</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Christer Holmberg</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div dir="auto" class="left"><span class="street-address">Hirsalantie 11</span></div>
<div dir="auto" class="left">FI-<span class="postal-code">02420</span> <span class="locality">Jorvas</span>
</div>
<div dir="auto" class="left"><span class="country-name">Finland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:christer.holmberg@ericsson.com" class="email">christer.holmberg@ericsson.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>