File: rfc9248.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 (3023 lines) | stat: -rw-r--r-- 179,419 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 9248: Interoperability Profile for Relay User Equipment</title>
<meta content="Brian Rosen" name="author">
<meta content='
       Video Relay Service (VRS) is a term used to describe a method by which a hearing person can communicate with a sign language speaker who is deaf, deafblind, or hard of hearing (HoH) or has a speech disability using an interpreter (i.e., a Communications Assistant (CA)) connected via a videophone to the sign language speaker and an audio telephone call to the hearing user.  The CA interprets using sign language on the videophone link and voice on the telephone link.  Often the interpreters may be employed by a company or agency, termed a "provider" in this document.  The provider also provides a video service that allows users to connect video devices to their service and subsequently to CAs and other sign language speakers. It is desirable that the videophones used by the sign language speaker conform to a standard so that any device may be used with any provider and that direct video calls between sign language speakers work.  This document describes the interface between a videophone and a provider. 
    ' name="description">
<meta content="xml2rfc 3.12.10" name="generator">
<meta content="rue" name="keyword">
<meta content="relay user equipment" name="keyword">
<meta content="9248" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.10
    Python 3.6.15
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.7.1
    MarkupSafe 2.0.1
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9248.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;
  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.ulBare, li.ulBare {
  margin-left: 0em !important;
}
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;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#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;
  }
  pre.breakable {
    break-inside: auto;
  }
  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: auto;
  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";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9248" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-rum-rue-11" 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 9248</td>
<td class="center">Relay User Equipment Profile</td>
<td class="right">June 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Rosen</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/rfc9248" class="eref">9248</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="2022-06" class="published">June 2022</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Author:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">B. Rosen</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9248</h1>
<h1 id="title">Interoperability Profile for Relay User Equipment</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">Video Relay Service (VRS) is a term used to describe a method by which a hearing person can communicate with a sign language speaker who is deaf, deafblind, or hard of hearing (HoH) or has a speech disability using an interpreter (i.e., a Communications Assistant (CA)) connected via a videophone to the sign language speaker and an audio telephone call to the hearing user.  The CA interprets using sign language on the videophone link and voice on the telephone link.  Often the interpreters may be employed by a company or agency, termed a "provider" in this document.  The provider also provides a video service that allows users to connect video devices to their service and subsequently to CAs and other sign language speakers. It is desirable that the videophones used by the sign language speaker conform to a standard so that any device may be used with any provider and that direct video calls between sign language speakers work.  This document describes the interface between a videophone and a provider.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9248">https://www.rfc-editor.org/info/rfc9248</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) 2022 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 Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised 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 ulBare ulEmpty">
<li class="compact toc ulBare 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></p>
</li>
          <li class="compact toc ulBare 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></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a></p>
</li>
          <li class="compact toc ulBare 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-general-requirements" class="xref">General Requirements</a></p>
</li>
          <li class="compact toc ulBare 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-sip-signaling" class="xref">SIP Signaling</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare 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-registration" class="xref">Registration</a></p>
</li>
              <li class="compact toc ulBare 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-session-establishment" class="xref">Session Establishment</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.1">
                    <p id="section-toc.1-1.5.2.2.2.1.1"><a href="#section-5.2.1" class="xref">5.2.1</a>.  <a href="#name-normal-call-origination" class="xref">Normal Call Origination</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.2">
                    <p id="section-toc.1-1.5.2.2.2.2.1"><a href="#section-5.2.2" class="xref">5.2.2</a>.  <a href="#name-dial-around-origination" class="xref">Dial-Around Origination</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.3">
                    <p id="section-toc.1-1.5.2.2.2.3.1"><a href="#section-5.2.3" class="xref">5.2.3</a>.  <a href="#name-rue-contact-information" class="xref">RUE Contact Information</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.4">
                    <p id="section-toc.1-1.5.2.2.2.4.1"><a href="#section-5.2.4" class="xref">5.2.4</a>.  <a href="#name-incoming-calls" class="xref">Incoming Calls</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.5">
                    <p id="section-toc.1-1.5.2.2.2.5.1"><a href="#section-5.2.5" class="xref">5.2.5</a>.  <a href="#name-emergency-calls" class="xref">Emergency Calls</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare 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-mid-call-signaling" class="xref">Mid-Call Signaling</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-uri-representation-of-phone" class="xref">URI Representation of Phone Numbers</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.5">
                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-transport" class="xref">Transport</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-media" class="xref">Media</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-srtp-and-srtcp" class="xref">SRTP and SRTCP</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-text-based-communication" class="xref">Text-Based Communication</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-video" class="xref">Video</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.4">
                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-audio" class="xref">Audio</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.5">
                <p id="section-toc.1-1.6.2.5.1"><a href="#section-6.5" class="xref">6.5</a>.  <a href="#name-dtmf-digits" class="xref">DTMF Digits</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.6">
                <p id="section-toc.1-1.6.2.6.1"><a href="#section-6.6" class="xref">6.6</a>.  <a href="#name-session-description-protoco" class="xref">Session Description Protocol</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.7">
                <p id="section-toc.1-1.6.2.7.1"><a href="#section-6.7" class="xref">6.7</a>.  <a href="#name-privacy" class="xref">Privacy</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.8">
                <p id="section-toc.1-1.6.2.8.1"><a href="#section-6.8" class="xref">6.8</a>.  <a href="#name-negative-acknowledgement-pi" class="xref">Negative Acknowledgement, Picture Loss Indicator, and Full Intraframe Request Features</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-contacts" class="xref">Contacts</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-carddav-login-and-synchroni" class="xref">CardDAV Login and Synchronization</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-contacts-import-export-serv" class="xref">Contacts Import/Export Service</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-video-mail" class="xref">Video Mail</a></p>
</li>
          <li class="compact toc ulBare 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-provisioning-and-provider-s" class="xref">Provisioning and Provider Selection</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare 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-rue-provider-selection" class="xref">RUE Provider Selection</a></p>
</li>
              <li class="compact toc ulBare 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-rue-configuration-service" class="xref">RUE Configuration Service</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2.2.1">
                    <p id="section-toc.1-1.9.2.2.2.1.1"><a href="#section-9.2.1" class="xref">9.2.1</a>.  <a href="#name-provider-configuration" class="xref">Provider Configuration</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2.2.2">
                    <p id="section-toc.1-1.9.2.2.2.2.1"><a href="#section-9.2.2" class="xref">9.2.2</a>.  <a href="#name-rue-configuration" class="xref">RUE Configuration</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2.2.3">
                    <p id="section-toc.1-1.9.2.2.2.3.1"><a href="#section-9.2.3" class="xref">9.2.3</a>.  <a href="#name-versions" class="xref">Versions</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2.2.4">
                    <p id="section-toc.1-1.9.2.2.2.4.1"><a href="#section-9.2.4" class="xref">9.2.4</a>.  <a href="#name-examples" class="xref">Examples</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2.2.5">
                    <p id="section-toc.1-1.9.2.2.2.5.1"><a href="#section-9.2.5" class="xref">9.2.5</a>.  <a href="#name-using-the-provider-selectio" class="xref">Using the Provider Selection and RUE Configuration Services Together</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3">
                <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="xref">9.3</a>.  <a href="#name-openapi-interface-descripti" class="xref">OpenAPI Interface Descriptions</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3.2.1">
                    <p id="section-toc.1-1.9.2.3.2.1.1"><a href="#section-9.3.1" class="xref">9.3.1</a>.  <a href="#name-provider-list" class="xref">Provider List</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3.2.2">
                    <p id="section-toc.1-1.9.2.3.2.2.1"><a href="#section-9.3.2" class="xref">9.3.2</a>.  <a href="#name-configuration" class="xref">Configuration</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-iana-considerations" class="xref">IANA Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare 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-rue-provider-list-registry" class="xref">RUE Provider List Registry</a></p>
</li>
              <li class="compact toc ulBare 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-registration-of-rue-owner-v" class="xref">Registration of Rue-Owner Value of the Purpose Parameter</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare 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-normative-references" class="xref">Normative References</a></p>
</li>
          <li class="compact toc ulBare 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-informative-references" class="xref">Informative References</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</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">Video Relay Service (VRS) is a form of Telecommunications Relay Service (TRS) that enables people with hearing disabilities who use sign language,
      such as American Sign Language (ASL), to communicate with voice telephone users through video equipment.
      These services also enable communication between such
         individuals directly in suitable modalities, including any combination of sign language via video, real-time text, and speech.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
        This interoperability profile for Relay User Equipment (RUE) is a profile of the Session Initiation Protocol (SIP) and related media protocols that
        enables end-user equipment registration and calling for VRS calls. It specifies the minimal set of call flows and IETF
        and ITU-T standards that must be supported, provides guidance where the standards leave multiple implementation options, and specifies minimal and extended capabilities for RUE calls.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
   Both subscriber-to-provider (interpreted) and direct subscriber-to-subscriber 
   calls are supported on this interface.
While there are some accommodations in this document to maximize backwards compatibility with other devices and services that are used to provide VRS service, backwards compatibility is not a requirement, and some interwork may be required to allow direct video calls to older devices.  This document only describes the interface between the device and the provider, not any other interface the provider may have.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">The following illustrates a typical relay call.  The RUE device and the communications assistant (sign language interpreter) have videophones.  The hearing user has a telephone (mobile or fixed).<a href="#section-1-4" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-1-5">
<pre>
                           ||== RUE Interface (this document)
                           ||
                           \/
  +------+   +------+      -       +--------+     -      +-------+
  |User  |   |RUE   |    (   )     |Provider|    (  )    |User   |
  |who is|   |Device|&lt;-(Internet)-&gt;|        |            |who is |
  |Deaf  |&lt;-&gt;|      |              |        |&lt;-( PSTN )-&gt;|Hearing|
  +------+   +------+   --------   +--------+   ------   +-------+
                                        ^
                                        |
                                +--------------+
                                |Communications|
                                |Assistant     |
                                +--------------+
</pre><a href="#section-1-5" class="pilcrow">¶</a>
</div>
</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>
<span class="break"></span><dl class="dlNewline" id="section-2-1">
        <dt id="section-2-1.1">Communications Assistant (CA):</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.2">A sign-language interpreter working for a VRS provider, providing functionally equivalent phone service.<a href="#section-2-1.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.3">Communication modality (modality):</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.4">A specific form of communication that may be employed by two users, e.g., English voice, Spanish voice,
        American Sign Language, English lipreading, or French real-time text. Here, one communication modality is assumed to encompass both the
        language and the way that language is exchanged. For example, English voice and French voice are two different communication modalities.<a href="#section-2-1.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.5">Default video relay service:</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.6">The video relay service operated by a subscriber's default VRS provider.<a href="#section-2-1.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.7">Default video relay service provider (default provider):</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.8">The VRS
  provider that registers and assigns a telephone number to a
  specific subscriber and, by default, provides the
  VRS for incoming voice calls to the user.  The default
  provider, also by default, provides the VRS for outgoing relay calls. The
  user can have more than one telephone number, and each has a default
  provider.<a href="#section-2-1.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.9">Outbound dial-around call:</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.10">A relay call where the subscriber specifies the use of a VRS provider other than the default VRS provider.
        This can be accomplished by the user dialing a "front-door" number for a VRS provider and signing or texting a phone number to call ("two-stage").
        Alternatively, this can be accomplished by the user's RUE software instructing the server of its default VRS provider to automatically route the call through the alternate provider to the desired Public Switched Telephone Network (PSTN) directory number ("one-stage").  Dial-around is per call; for any call, a user can use the default VRS provider or any dial-around VRS provider.<a href="#section-2-1.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.11">Full Intra Request (FIR):</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.12">A request to a video media sender, requiring that media sender to send a decoder refresh point at the earliest opportunity. FIR is sometimes known as "instantaneous decoder refresh request", "video fast update request", or "fast update request".<a href="#section-2-1.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.13">Point-to-Point Call (P2P Call):</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.14">A call between two RUEs, without including a CA.<a href="#section-2-1.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.15">Relay call:</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.16">A call that allows people with hearing or speech disabilities to use a RUE to talk to users of conventional voice services with the aid of a CA to relay the communication.<a href="#section-2-1.16" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.17">Relay service (RS):</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.18">A service that allows a registered subscriber to use a RUE to make and receive relay calls, point-to-point calls, and relay-to-relay calls. The functions provided by the relay service include the provision of media links supporting the communication modalities used by the caller and callee, user registration and validation, authentication, authorization, automatic call distributor (ACD) platform functions, routing (including emergency call routing), call setup, mapping, call features (such as call forwarding and video mail), and assignment of CAs to relay calls.<a href="#section-2-1.18" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.19">Relay service provider (provider):</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.20">An organization that operates a relay service. A subscriber selects a relay service provider to assign and register a telephone number for their use, to register with for receipt of incoming calls, and to provide the default service for outgoing calls.<a href="#section-2-1.20" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.21">Relay user:</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.22">Please refer to "subscriber".<a href="#section-2-1.22" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.23">Relay user E.164 Number (user E.164):</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.24">The telephone number (in ITU-T E.164 format) assigned to the user.<a href="#section-2-1.24" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.25">Relay User Equipment (RUE):</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.26">A SIP user agent (UA) enhanced with extra features to support a subscriber in requesting, receiving, and using relay calls. A RUE may take many forms, including a stand-alone device; an application running on a general-purpose computing device, such as a laptop, tablet, or smartphone; or proprietary equipment connected to a server that provides the RUE interface.<a href="#section-2-1.26" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.27">RUE interface:</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.28">The interfaces described in this document between a RUE and a VRS provider who supports it.<a href="#section-2-1.28" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.29">Sign language:</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.30">A language that uses hand gestures and body language to convey meaning, including, but not limited to, American Sign Language (ASL).<a href="#section-2-1.30" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.31">Subscriber:</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.32">An individual who has registered with a provider and who obtains service by using a RUE. This is the conventional telecom term for an end-user customer, which in this case is a relay user.  A user may be a subscriber to more than one VRS provider.<a href="#section-2-1.32" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.33">Video Relay Service (VRS):</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.34">A relay service for people with hearing or speech disabilities who use sign language to communicate using video equipment (video RUE) with other people in real time. The video link allows the CA to view and interpret the subscriber's signed conversation and relay the conversation back and forth with the other party.<a href="#section-2-1.34" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
<section id="section-3">
      <h2 id="name-requirements-language">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
      </h2>
<p id="section-3-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.
    Lower- or mixed-case uses of these key
   words are not to be interpreted as carrying special significance.<a href="#section-3-1" class="pilcrow">¶</a></p>
</section>
<div id="general">
<section id="section-4">
      <h2 id="name-general-requirements">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-general-requirements" class="section-name selfRef">General Requirements</a>
      </h2>
<p id="section-4-1">All HTTP/HTTPS <span>[<a href="#RFC9110" class="xref">RFC9110</a>]</span> <span>[<a href="#RFC9112" class="xref">RFC9112</a>]</span> connections specified throughout this document <span class="bcp14">MUST</span> use HTTPS. Both HTTPS and all SIP connections <span class="bcp14">MUST</span> use TLS conforming to at least <span>[<a href="#RFC7525" class="xref">RFC7525</a>]</span> and <span class="bcp14">MUST</span> support <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">
           All text data payloads not otherwise constrained by a specification in another standards document <span class="bcp14">MUST</span> be encoded as Unicode UTF-8.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">Implementations <span class="bcp14">MUST</span> support IPv4 and IPv6.  Dual-stack support is NOT required, and provider implementations <span class="bcp14">MAY</span> support separate interfaces for IPv4 and IPv6 by having more than one server in the appropriate SRV record where there is either an A or AAAA record in each server DNS record but not both.  The same version of IP <span class="bcp14">MUST</span> be used for both signaling and media of a call unless Interactive Connectivity Establishment (ICE) <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span> is used; in which case, candidates may explicitly offer IPv4, IPv6, or both for any media stream.<a href="#section-4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sip">
<section id="section-5">
      <h2 id="name-sip-signaling">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-sip-signaling" class="section-name selfRef">SIP Signaling</a>
      </h2>
<p id="section-5-1">Implementations of the RUE interface <span class="bcp14">MUST</span> conform to the following core SIP standards:<a href="#section-5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5-2.1">
          <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span> (Base SIP)<a href="#section-5-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.2">
          <span>[<a href="#RFC3263" class="xref">RFC3263</a>]</span> (Locating SIP Servers)<a href="#section-5-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.3">
          <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span> (Offer/Answer)<a href="#section-5-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.4">
          <span>[<a href="#RFC3840" class="xref">RFC3840</a>]</span> (User Agent Capabilities)<a href="#section-5-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.5">
          <span>[<a href="#RFC5626" class="xref">RFC5626</a>]</span> (Outbound)<a href="#section-5-2.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.6">
          <span>[<a href="#RFC8866" class="xref">RFC8866</a>]</span> (Session Description Protocol)<a href="#section-5-2.6" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.7">
          <span>[<a href="#RFC3323" class="xref">RFC3323</a>]</span> (Privacy)<a href="#section-5-2.7" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.8">
          <span>[<a href="#RFC3605" class="xref">RFC3605</a>]</span> (RTCP Attribute in SDP)<a href="#section-5-2.8" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.9">
          <span>[<a href="#RFC3311" class="xref">RFC3311</a>]</span> (UPDATE Method)<a href="#section-5-2.9" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.10">
          <span>[<a href="#RFC5393" class="xref">RFC5393</a>]</span> (Loop-Fix)<a href="#section-5-2.10" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.11">
          <span>[<a href="#RFC5658" class="xref">RFC5658</a>]</span> (Record-Route Fix)<a href="#section-5-2.11" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.12">
          <span>[<a href="#RFC5954" class="xref">RFC5954</a>]</span> (ABNF Fix)<a href="#section-5-2.12" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.13">
          <span>[<a href="#RFC3960" class="xref">RFC3960</a>]</span> (Early Media)<a href="#section-5-2.13" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.14">
          <span>[<a href="#RFC6442" class="xref">RFC6442</a>]</span> (Geolocation Header Field)<a href="#section-5-2.14" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-5-3">
In the above documents, the RUE device conforms to the requirements of a SIP user agent, and the provider conforms to the requirements of the registrar and proxy server where the document specifies different behavior for different roles.   For providers offering a video mail service, <span>[<a href="#RFC6665" class="xref">RFC6665</a>]</span> (SIP Events) <span class="bcp14">MUST</span> be implemented to support the  Message-Waiting Indicator (MWI) (see <a href="#mwi" class="xref">Section 8</a>).<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">In addition, implementations <span class="bcp14">MUST</span> conform to:<a href="#section-5-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5-5.1">
          <span>[<a href="#RFC3327" class="xref">RFC3327</a>]</span> (Path Header Field)<a href="#section-5-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-5.2">
          <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span> and <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span> (ICE)<a href="#section-5-5.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-5.3">
          <span>[<a href="#RFC3326" class="xref">RFC3326</a>]</span> (Reason Header Field)<a href="#section-5-5.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-5.4">
          <span>[<a href="#RFC3515" class="xref">RFC3515</a>]</span> (REFER Method)<a href="#section-5-5.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-5.5">
          <span>[<a href="#RFC3891" class="xref">RFC3891</a>]</span> (Replaces Header Field)<a href="#section-5-5.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-5.6">
          <span>[<a href="#RFC3892" class="xref">RFC3892</a>]</span> (Referred-By Header Field)<a href="#section-5-5.6" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-5-6">Implementations <span class="bcp14">MUST</span> implement full ICE, although they <span class="bcp14">MAY</span> interwork with user agents that implement ICE-lite.<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="section-5-7">
           Implementations <span class="bcp14">MUST</span> include a "User-Agent" header field uniquely identifying the RUE application, platform, and version in all SIP requests and <span class="bcp14">MUST</span> include a "Server" header field with the same content in SIP responses.<a href="#section-5-7" class="pilcrow">¶</a></p>
<p id="section-5-8">Implementations intended to support mobile platforms <span class="bcp14">MUST</span> support <span>[<a href="#RFC8599" class="xref">RFC8599</a>]</span> and <span class="bcp14">MUST</span> use it as at least one way to support waking up the client from the background state.<a href="#section-5-8" class="pilcrow">¶</a></p>
<p id="section-5-9">The SIP signaling for registration and placing/receiving calls depends on the configuration of various values into the RUE device.  <a href="#config" class="xref">Section 9.2</a> describes the configuration mechanism that provides values that are used in the signaling.  When the device starts, the configuration mechanism is run, which retrieves the configuration data; then, SIP registration occurs using the values from the configuration.  After registration, calls may be sent or received by the RUE device.<a href="#section-5-9" class="pilcrow">¶</a></p>
<div id="register">
<section id="section-5.1">
        <h3 id="name-registration">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-registration" class="section-name selfRef">Registration</a>
        </h3>
<p id="section-5.1-1">
        The RUE <span class="bcp14">MUST</span> register with a SIP registrar, following <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span> and <span>[<a href="#RFC5626" class="xref">RFC5626</a>]</span>, at a provider it has an account with. If the configuration (see <a href="#config" class="xref">Section 9.2</a>) contains multiple "outbound-proxies" in "RueConfigurationData", then the RUE <span class="bcp14">MUST</span> use them as specified in <span>[<a href="#RFC5626" class="xref">RFC5626</a>]</span> to establish multiple flows.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">
        The Request-URI for the REGISTER request <span class="bcp14">MUST</span> contain the "provider-domain" from the configuration. The To URI and From URI <span class="bcp14">MUST</span> be identical URIs and formatted as follows:<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-3.1">if "user-name" is provided: "username@provider-domain"<a href="#section-5.1-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.1-3.2">if "user-name" is not provided: as specified in <a href="#uriphone" class="xref">Section 5.4</a>, use "phone-number" and "provider-domain" from the configuration<a href="#section-5.1-3.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.1-4">
        The RUE determines the URI to resolve by initially determining if one or more "outbound-proxies" are configured. If they are configured, the URI will be that of one of the "outbound-proxies". If no "outbound-proxies" are configured, the URI will be the Request-URI from the REGISTER request. The RUE extracts the domain from that URI and consults the DNS record for that domain. The DNS entry <span class="bcp14">MUST</span> contain NAPTR records conforming to <span>[<a href="#RFC3263" class="xref">RFC3263</a>]</span>. One of those NAPTR records <span class="bcp14">MUST</span> specify TLS as the preferred transport for SIP. For example, a DNS NAPTR query for "sip: p1.red.example.net" could return:<a href="#section-5.1-4" class="pilcrow">¶</a></p>
<div id="section-5.1-5">
<pre class="sourcecode">
IN NAPTR 50  50 "s" "SIPS+D2T" "" _sips._tcp.p1.red.example.net
IN NAPTR 90  50 "s" "SIP+D2T"  "" _sip._tcp.p1.red.example.net
</pre><a href="#section-5.1-5" class="pilcrow">¶</a>
</div>
<p id="section-5.1-6">
        If the RUE receives a 439 (First Hop Lacks Outbound Support) response to a REGISTER request, it <span class="bcp14">MUST</span> reattempt registration without using the outbound mechanism.<a href="#section-5.1-6" class="pilcrow">¶</a></p>
<p id="section-5.1-7">
        The registrar <span class="bcp14">MAY</span> authenticate the RUE using SIP digest authentication. The credentials to be used <span class="bcp14">MUST</span> come from the configuration in <a href="#config" class="xref">Section 9.2</a>: "user-name" if provided or "phone-number" if user-name is not provided, and "sip-password". This "user-name"/"sip-password" combination <span class="bcp14">SHOULD NOT</span> be the same as
        that used for other purposes, except as expressly described below, such as retrieving the RUE configuration or logging into the provider's customer service portal. 
<span>[<a href="#RFC8760" class="xref">RFC8760</a>]</span> <span class="bcp14">MUST</span> be supported by all implementations, and SHA-512 digest algorithms <span class="bcp14">MUST</span> be supported.<a href="#section-5.1-7" class="pilcrow">¶</a></p>
<p id="section-5.1-8">
        If the registration request fails with an indication that credentials from the configuration are invalid,
        then the RUE <span class="bcp14">MUST</span> retrieve a fresh version of the configuration.
        If credentials from a freshly retrieved configuration are found to be invalid,
        then the RUE <span class="bcp14">MUST</span> cease attempts to register and inform the RUE user of the problem.<a href="#section-5.1-8" class="pilcrow">¶</a></p>
<p id="section-5.1-9">
        Support for multiple simultaneous registrations with multiple providers by the RUE is <span class="bcp14">OPTIONAL</span> for the RUE (and providers do not need any support for this option).<a href="#section-5.1-9" class="pilcrow">¶</a></p>
<p id="section-5.1-10">
        Multiple simultaneous RUE SIP registrations from different RUE devices with the same SIP URI <span class="bcp14">SHOULD</span> be permitted by the provider. The provider <span class="bcp14">MAY</span> limit the total number of simultaneous registrations. When a new registration request is received that results in exceeding the limit on simultaneous registrations, the provider <span class="bcp14">MAY</span> then prematurely terminate another registration; however, it <span class="bcp14">SHOULD NOT</span> do this if it would disconnect an active call.<a href="#section-5.1-10" class="pilcrow">¶</a></p>
<p id="section-5.1-11">
        If a provider prematurely terminates a registration to reduce the total number of concurrent registrations with the same URI, it <span class="bcp14">SHOULD</span> take some action to prevent the affected RUE from automatically re-registering and re-triggering the condition.<a href="#section-5.1-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="session">
<section id="section-5.2">
        <h3 id="name-session-establishment">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-session-establishment" class="section-name selfRef">Session Establishment</a>
        </h3>
<div id="normalcall">
<section id="section-5.2.1">
          <h4 id="name-normal-call-origination">
<a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-normal-call-origination" class="section-name selfRef">Normal Call Origination</a>
          </h4>
<p id="section-5.2.1-1">
          After initial SIP registration, the RUE adheres to SIP <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span> basic call flows, as documented in <span>[<a href="#RFC3665" class="xref">RFC3665</a>]</span>.<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
<p id="section-5.2.1-2">
          A RUE device <span class="bcp14">MUST</span> route all outbound calls through an outbound proxy if configured.<a href="#section-5.2.1-2" class="pilcrow">¶</a></p>
<p id="section-5.2.1-3">
          The SIP URIs in the To field and the Request-URI <span class="bcp14">MUST</span> be formatted as specified in <a href="#uriphone" class="xref">Section 5.4</a> using the destination phone number or as SIP URIs as provided in the configuration (<a href="#config" class="xref">Section 9.2</a>). The domain field of the URIs <span class="bcp14">SHOULD</span> be the "provider-domain" from the configuration (e.g., sip:+15551234567@red.example.com;user=phone), except that an anonymous call would not use the provider domain.<a href="#section-5.2.1-3" class="pilcrow">¶</a></p>
<p id="section-5.2.1-4">
          Anonymous calls <span class="bcp14">MUST</span> be supported by all implementations. An anonymous call is signaled per <span>[<a href="#RFC3323" class="xref">RFC3323</a>]</span>.<a href="#section-5.2.1-4" class="pilcrow">¶</a></p>
<p id="section-5.2.1-5">
          The From URI <span class="bcp14">MUST</span> be formatted as specified in <a href="#uriphone" class="xref">Section 5.4</a>, using the "phone-number" and "provider-domain" from the configuration. It <span class="bcp14">SHOULD</span> also contain the display-name from the configuration when present. (Please refer to <a href="#config" class="xref">Section 9.2</a>.)<a href="#section-5.2.1-5" class="pilcrow">¶</a></p>
<p id="section-5.2.1-6">
          Negotiated media <span class="bcp14">MUST</span> follow the requirements specified in <a href="#media" class="xref">Section 6</a> of this document.<a href="#section-5.2.1-6" class="pilcrow">¶</a></p>
<p id="section-5.2.1-7">
          To allow time for an unanswered call to time out and direct it to a videomail server, the User Agent Client <span class="bcp14">MUST NOT</span> impose a time limit less than the default SIP INVITE transaction timeout of 3 minutes.<a href="#section-5.2.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="onestage">
<section id="section-5.2.2">
          <h4 id="name-dial-around-origination">
<a href="#section-5.2.2" class="section-number selfRef">5.2.2. </a><a href="#name-dial-around-origination" class="section-name selfRef">Dial-Around Origination</a>
          </h4>
<p id="section-5.2.2-1">Providers and RUE devices <span class="bcp14">MUST</span> support both one-stage and two-stage dial-around.<a href="#section-5.2.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2.2-2">
            Outbound dial-around calls allow a RUE user to select any provider to provide interpreting services for any call.
            "Two-stage" dial-around calls involve the RUE calling a telephone number that reaches the dial-around provider and
            using signing or dual-tone multi-frequency (DTMF) to provide the called party's telephone number. In two-stage dial-around, the To URI is the "front-door" URI (see <a href="#config" class="xref">Section 9.2</a>) in "ProviderConfigurationData" of
            the dial-around provider.  The RUE Provider Selection service (<a href="#providerselect" class="xref">Section 9.1</a>) can be used by the RUE to obtain a list of providers; then, the provider configuration (<a href="#providerConfig" class="xref">Section 9.2.1</a>) can be used to find the front-door URI for each of these providers.<a href="#section-5.2.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2.2-3">
            One-stage dial-around is a method where the called party's telephone number is provided in the To URI and the Request-URI,
            using the domain of the dial-around provider.<a href="#section-5.2.2-3" class="pilcrow">¶</a></p>
<p id="section-5.2.2-4">
            For one-stage dial-around, the RUE <span class="bcp14">MUST</span> follow the procedures in <a href="#normalcall" class="xref">Section 5.2.1</a> with the
            following exception: the domain part of the SIP URIs in the To field and the Request-URI <span class="bcp14">MUST</span> be the domain of the
            dial-around provider discovered as described in <a href="#providerselect" class="xref">Section 9.1</a>.<a href="#section-5.2.2-4" class="pilcrow">¶</a></p>
<p id="section-5.2.2-5">
            The following is a partial example of a one-stage dial-around call from VRS user +1-555-222-0001 hosted by red.example.com
            to a hearing user +1-555-123-4567 using dial-around to green.example.com for the relay service. Only important details of the
            messages are shown, and many header fields have been omitted:<a href="#section-5.2.2-5" class="pilcrow">¶</a></p>
<span id="name-one-stage-dial-around"></span><figure id="figure-1">
            <div class="alignLeft art-text artwork" id="section-5.2.2-6.1">
<pre>
  ,-+-.        ,----+----.    ,-----+-----.
  |RUE|        |Default  |    |Dial-Around|
  |   |        |Provider |    | Provider  |
  `-+-'        `----+----'    `-----+-----'
    |               |               |
    | [1] INVITE    |               |
    |--------------&gt;| [2] INVITE    |
    |               |--------------&gt;|

  Message Details:

  [1] INVITE Rue -&gt; Default Provider

  INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0
  To: &lt;sip:+15551234567@green.example.net;user=phone&gt;
  From: "Bob Smith" &lt;sip:+15552220001@red.example.net;user=phone&gt;

  [2] INVITE Default Provider -&gt; Dial-Around Provider

  INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0
  To: &lt;sip:+15551234567@green.example.net;user=phone&gt;
  From: "Bob Smith" sip:+15552220001@red.example.net;user=phone
  P-Asserted-Identity: sip:+15552220001@red.example.net
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-one-stage-dial-around" class="selfRef">One-Stage Dial-Around</a>
            </figcaption></figure>
</section>
</div>
<div id="contact">
<section id="section-5.2.3">
          <h4 id="name-rue-contact-information">
<a href="#section-5.2.3" class="section-number selfRef">5.2.3. </a><a href="#name-rue-contact-information" class="section-name selfRef">RUE Contact Information</a>
          </h4>
<p id="section-5.2.3-1">
                    To identify the owner of a RUE, the initial INVITE for a call from a RUE, or the 200 OK the RUE uses to accept a call,
                    identifies the owner by sending a Call-Info header field with a purpose parameter of "rue-owner".
                    The URI <span class="bcp14">MAY</span> be an HTTPS URI or Content-ID URL. The latter is defined by <span>[<a href="#RFC2392" class="xref">RFC2392</a>]</span> to locate
                    message body parts. This URI type is present in a SIP message to convey the RUE ownership information as a
                    MIME body. The form of the RUE ownership information is an xCard <span>[<a href="#RFC6351" class="xref">RFC6351</a>]</span>.     
                    Please refer to <span>[<a href="#RFC6442" class="xref">RFC6442</a>]</span> for an example of using content indirection URLs in SIP messages. Note that use of the content indirection URL
                    usually implies multiple message bodies ("mime/multipart"). The RUE owner is the entity that has local control over the device that is not necessarily the legal owner of the equipment.  It often is the user, but that is not necessarily true.  While no minimum fields in the xCard are specified, the name, address, phone number, and email address of the RUE owner are expected to be supplied.<a href="#section-5.2.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="incoming">
<section id="section-5.2.4">
          <h4 id="name-incoming-calls">
<a href="#section-5.2.4" class="section-number selfRef">5.2.4. </a><a href="#name-incoming-calls" class="section-name selfRef">Incoming Calls</a>
          </h4>
<p id="section-5.2.4-1">The RUE <span class="bcp14">MUST</span> only accept inbound calls sent to it by a proxy mentioned in the configuration.<a href="#section-5.2.4-1" class="pilcrow">¶</a></p>
<p id="section-5.2.4-2">If multiple simultaneous RUE SIP registrations from different RUE devices with the same SIP URI exist,
                    the provider <span class="bcp14">MUST</span> parallel fork the call to all registered RUEs so that they ring at the same time.
   The first RUE to reply with a 200 OK answers the call, and the
   provider <span class="bcp14">MUST</span> cancel other call branches using a CANCEL request.<a href="#section-5.2.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="emergency">
<section id="section-5.2.5">
          <h4 id="name-emergency-calls">
<a href="#section-5.2.5" class="section-number selfRef">5.2.5. </a><a href="#name-emergency-calls" class="section-name selfRef">Emergency Calls</a>
          </h4>
<p id="section-5.2.5-1">Implementations <span class="bcp14">MUST</span> conform to <span>[<a href="#RFC6881" class="xref">RFC6881</a>]</span> for handling of emergency calls, except that if the device is unable to determine its own location, it <span class="bcp14">MAY</span> send the emergency call without a Geolocation header field and without a Route header field (since it would be unable to query the Location-to-Service Translation (LoST) server for a route, per <span>[<a href="#RFC6881" class="xref">RFC6881</a>]</span>). If an emergency call arrives at the provider without a Geolocation header field, the provider <span class="bcp14">MUST</span> supply location by adding the Geolocation header field and <span class="bcp14">MUST</span> supply the route by querying the LoST server with that location.<a href="#section-5.2.5-1" class="pilcrow">¶</a></p>
<p id="section-5.2.5-2">
              If the emergency call is to be handled using existing country-specific procedures,
                    the provider is responsible for modifying the INVITE to conform to the country-specific requirements.
                    In this case, the location <span class="bcp14">MAY</span> be extracted from the <span>[<a href="#RFC6881" class="xref">RFC6881</a>]</span> conformant INVITE and used to
                    propagate it to the appropriate country-specific entities.  If the configuration specifies it, an implementation of a RUE device
                    <span class="bcp14">MAY</span> send a Geolocation header field containing its location in the
                    REGISTER request. If implemented, users <span class="bcp14">MUST</span> be offered an opt-out. Country-specific procedures might require the location to
                    be preloaded in some entity prior to placing an emergency call;
                    however, the RUE may have a more accurate and timely device location
                    than the manual, preloaded entry. That information <span class="bcp14">MAY</span> be used to populate the location to appropriate country-specific entities.  Re-registration <span class="bcp14">SHOULD</span> be used to update the location, so long as the rate of re-registration is limited if the device is moving.<a href="#section-5.2.5-2" class="pilcrow">¶</a></p>
<p id="section-5.2.5-3">Implementations <span class="bcp14">MUST</span> implement additional data <span>[<a href="#RFC7852" class="xref">RFC7852</a>]</span>.  RUE devices <span class="bcp14">MUST</span> implement data provider information, device information, and owner/subscriber information blocks.<a href="#section-5.2.5-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="midcall">
<section id="section-5.3">
        <h3 id="name-mid-call-signaling">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-mid-call-signaling" class="section-name selfRef">Mid-Call Signaling</a>
        </h3>
<p id="section-5.3-1">
          Implementations <span class="bcp14">MUST</span> support re-INVITE to renegotiate media session parameters (among other uses).
   Per <a href="#mediafeat" class="xref">Section 6.8</a>, implementations <span class="bcp14">MUST</span> be able to support an INFO message for full frame refresh for devices that do not support SRTCP (please refer to <a href="#srtp" class="xref">Section 6.1</a>). 
Implementations <span class="bcp14">MUST</span> support an in-dialog REFER (as described in <span>[<a href="#RFC3515" class="xref">RFC3515</a>]</span> and updated by <span>[<a href="#RFC7647" class="xref">RFC7647</a>]</span>, and including support for norefersub per <span>[<a href="#RFC4488" class="xref">RFC4488</a>]</span>) with the Replaces header field <span>[<a href="#RFC3891" class="xref">RFC3891</a>]</span> to enable call transfer.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="uriphone">
<section id="section-5.4">
        <h3 id="name-uri-representation-of-phone">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-uri-representation-of-phone" class="section-name selfRef">URI Representation of Phone Numbers</a>
        </h3>
<p id="section-5.4-1">
                    SIP URIs constructed from non-URI sources (dial strings) and sent to SIP proxies by the RUE <span class="bcp14">MUST</span> be represented as follows, depending on whether they can be represented as an E.164 number.  In this section, "expressed as an E.164 number" includes numbers, such as toll-free numbers that are not actually E.164 numbers but have the same format.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<p id="section-5.4-2">
                A dial string that can be expressed as an E.164 phone number <span class="bcp14">MUST</span> be represented as a SIP URI with a URI ";user=phone" tag. The user part of the URI <span class="bcp14">MUST</span> be in conformance with "global-number", as defined in <span>[<a href="#RFC3966" class="xref">RFC3966</a>]</span>. The user part <span class="bcp14">MUST NOT</span> contain any "visual-separator" characters, as defined in <span>[<a href="#RFC3966" class="xref">RFC3966</a>]</span>.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
<p id="section-5.4-3">
                    Dial strings that cannot be expressed as E.164 numbers <span class="bcp14">MUST</span> be represented as dialstring URIs, as specified by <span>[<a href="#RFC4967" class="xref">RFC4967</a>]</span>, e.g., sip:411@red.example.net;user=dialstring.<a href="#section-5.4-3" class="pilcrow">¶</a></p>
<p id="section-5.4-4">
                    The domain part of relay service URIs and User Address of Records (AoR) <span class="bcp14">MUST</span> resolve (per <span>[<a href="#RFC3263" class="xref">RFC3263</a>]</span>) to globally routable IPv4 and/or IPv6 addresses.<a href="#section-5.4-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="nat">
<section id="section-5.5">
        <h3 id="name-transport">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-transport" class="section-name selfRef">Transport</a>
        </h3>
<p id="section-5.5-1">
                    Implementations <span class="bcp14">MUST</span> conform to <span>[<a href="#RFC8835" class="xref">RFC8835</a>]</span>, except for its guidance on the WebRTC data channel, which this specification does not use. See <a href="#text" class="xref">Section 6.2</a> for how RUE supports real-time text without the data channel.<a href="#section-5.5-1" class="pilcrow">¶</a></p>
<p id="section-5.5-2">
                    Implementations <span class="bcp14">MUST</span> support SIP outbound <span>[<a href="#RFC5626" class="xref">RFC5626</a>]</span> (please also refer to <a href="#register" class="xref">Section 5.1</a>).<a href="#section-5.5-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="media">
<section id="section-6">
      <h2 id="name-media">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-media" class="section-name selfRef">Media</a>
      </h2>
<p id="section-6-1">This specification adopts the media specifications for WebRTC <span>[<a href="#RFC8825" class="xref">RFC8825</a>]</span>.
                Where WebRTC defines how interactive media communications may be established using a browser as a client, this specification assumes a normal SIP call.
                Various RTPs, RTCPs, SDPs, and specific media requirements specified for WebRTC are adopted for this document. Explicit requirements from the WebRTC suite of documents are described below .<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">To use WebRTC with this document, a gateway that presents a WebRTC server interface towards a browser and a RUE client interface towards a provider is assumed.  The gateway would interwork signaling and, as noted below, interwork at least any real-time text media in order to allow a standard browser-based WebRTC client to be a VRS client.  The combination of the browser client and the gateway would be a RUE user.  This document does not specify the gateway.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3"> The following sections specify the WebRTC documents to which conformance is required.  "Mandatory to Implement" means a conforming implementation <span class="bcp14">MUST</span> implement the
                specified capability.  It does not mean that the capability must be used in every session.  For example, Opus is a Mandatory-to-Implement audio codec, and all conforming
                implementations must support Opus.
 However, an implementation presenting a call across the RUE interface (where the call originates in the PSTN or an older, non-RUE-compatible device, which only offers G.711 audio) does not need to
                include the Opus codec in the offer, since it cannot be used with that call. Conformance to this document allows end-to-end RTCP and media congestion control for audio and video.<a href="#section-6-3" class="pilcrow">¶</a></p>
<div id="srtp">
<section id="section-6.1">
        <h3 id="name-srtp-and-srtcp">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-srtp-and-srtcp" class="section-name selfRef">SRTP and SRTCP</a>
        </h3>
<p id="section-6.1-1">
                    Implementations <span class="bcp14">MUST</span> support <span>[<a href="#RFC8834" class="xref">RFC8834</a>]</span>, except that MediaStreamTracks are not used.  Implementations <span class="bcp14">MUST</span> conform to <span><a href="https://www.rfc-editor.org/rfc/rfc8827#section-6.4" class="relref">Section 6.4</a> of [<a href="#RFC8827" class="xref">RFC8827</a>]</span>.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="text">
<section id="section-6.2">
        <h3 id="name-text-based-communication">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-text-based-communication" class="section-name selfRef">Text-Based Communication</a>
        </h3>
<p id="section-6.2-1">
                 Implementations <span class="bcp14">MUST</span> support real-time text <span>[<a href="#RFC4102" class="xref">RFC4102</a>]</span> <span>[<a href="#RFC4103" class="xref">RFC4103</a>]</span> via T.140 media.
                 One original and two redundant generations <span class="bcp14">MUST</span> be transmitted and supported with a 300 ms transmission interval.  Implementations <span class="bcp14">MUST</span> support <span>[<a href="#RFC9071" class="xref">RFC9071</a>]</span>, especially for emergency calls.  Note that <span>[<a href="#RFC4103" class="xref">RFC4103</a>]</span> is
                 not how real-time text is transmitted in WebRTC, and some form of transcoder would be required to interwork real-time text in the data channel
                 of WebRTC to <span>[<a href="#RFC4103" class="xref">RFC4103</a>]</span> real-time text.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">
            Transport of T.140 real-time text in WebRTC is specified in <span>[<a href="#RFC8865" class="xref">RFC8865</a>]</span>, using
              the WebRTC data channel. <span>[<a href="#RFC8865" class="xref">RFC8865</a>]</span> also has some advice on how gateways
              between <span>[<a href="#RFC4103" class="xref">RFC4103</a>]</span> and <span>[<a href="#RFC8865" class="xref">RFC8865</a>]</span> should operate. It is <span class="bcp14">RECOMMENDED</span> that
              <span>[<a href="#RFC8865" class="xref">RFC8865</a>]</span>, including multiparty support, be used for communication with browser-based WebRTC implementations.  Implementations <span class="bcp14">MUST</span> support <span>[<a href="#RFC9071" class="xref">RFC9071</a>]</span>.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="video">
<section id="section-6.3">
        <h3 id="name-video">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-video" class="section-name selfRef">Video</a>
        </h3>
<p id="section-6.3-1">Implementations <span class="bcp14">MUST</span> conform to <span>[<a href="#RFC7742" class="xref">RFC7742</a>]</span> with the following exceptions:
        only H.264, as specified in <span>[<a href="#RFC7742" class="xref">RFC7742</a>]</span>, is Mandatory to
 Implement, and VP8 support is <span class="bcp14">OPTIONAL</span> at both the
 device and providers. This is because backwards compatibility is
 desirable, and older devices do not support VP8.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="audio">
<section id="section-6.4">
        <h3 id="name-audio">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-audio" class="section-name selfRef">Audio</a>
        </h3>
<p id="section-6.4-1">Implementations <span class="bcp14">MUST</span> conform to <span>[<a href="#RFC7874" class="xref">RFC7874</a>]</span>.<a href="#section-6.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dtmf">
<section id="section-6.5">
        <h3 id="name-dtmf-digits">
<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-dtmf-digits" class="section-name selfRef">DTMF Digits</a>
        </h3>
<p id="section-6.5-1">
                        Implementations <span class="bcp14">MUST</span> support the "audio/telephone-event" <span>[<a href="#RFC4733" class="xref">RFC4733</a>]</span> media type. They <span class="bcp14">MUST</span> support
                        conveying event codes 0 through 11 (DTMF digits "0"-"9", "*","#") defined in Table 7 of <span>[<a href="#RFC4733" class="xref">RFC4733</a>]</span>. Handling of other tones is <span class="bcp14">OPTIONAL</span>.<a href="#section-6.5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="SDP">
<section id="section-6.6">
        <h3 id="name-session-description-protoco">
<a href="#section-6.6" class="section-number selfRef">6.6. </a><a href="#name-session-description-protoco" class="section-name selfRef">Session Description Protocol</a>
        </h3>
<p id="section-6.6-1">
            The SDP offers and answers <span class="bcp14">MUST</span> conform to the SDP rules in <span>[<a href="#RFC8829" class="xref">RFC8829</a>]</span>
              except that the RUE interface uses SIP transport for SDP. The SDP
              for real-time text <span class="bcp14">MUST</span> specify the T.140 payload type <span>[<a href="#RFC4103" class="xref">RFC4103</a>]</span>.<a href="#section-6.6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="privacy">
<section id="section-6.7">
        <h3 id="name-privacy">
<a href="#section-6.7" class="section-number selfRef">6.7. </a><a href="#name-privacy" class="section-name selfRef">Privacy</a>
        </h3>
<p id="section-6.7-1">
            The RUE <span class="bcp14">MUST</span> provide for user privacy by implementing a local
            one-way mute, without signaling, for both audio and video. 
     However, RUE
              <span class="bcp14">MUST</span> maintain any states in the network (e.g., NAT bindings) by periodically sending media packets
              on all active media sessions containing silence, comfort noise, blank
              screen, etc., per <span>[<a href="#RFC6263" class="xref">RFC6263</a>]</span>.<a href="#section-6.7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="mediafeat">
<section id="section-6.8">
        <h3 id="name-negative-acknowledgement-pi">
<a href="#section-6.8" class="section-number selfRef">6.8. </a><a href="#name-negative-acknowledgement-pi" class="section-name selfRef">Negative Acknowledgement, Picture Loss Indicator, and Full Intraframe Request Features</a>
        </h3>
<p id="section-6.8-1">The NACK, FIR, and Picture Loss Indicator (PLI) features, as described in <span>[<a href="#RFC4585" class="xref">RFC4585</a>]</span> and <span>[<a href="#RFC5104" class="xref">RFC5104</a>]</span>, <span class="bcp14">MUST</span> be implemented.  Availability of these features <span class="bcp14">MUST</span> be announced with the "ccm" feedback value.  NACK should be used when negotiated and conditions warrant its use and the other end supports it.  Signaling picture losses as a PLI should be preferred.  FIR should be used only in situations where not sending a decoder refresh point would render the video unusable for the users, as per <span><a href="https://www.rfc-editor.org/rfc/rfc5104#section-4.3.1.2" class="relref">Section 4.3.1.2</a> of [<a href="#RFC5104" class="xref">RFC5104</a>]</span>.<a href="#section-6.8-1" class="pilcrow">¶</a></p>
<p id="section-6.8-2">For backwards compatibility with calling devices that do not support the foregoing methods, implementations <span class="bcp14">MUST</span> implement SIP INFO messages to send and receive XML-encoded Picture Fast Update messages according to <span>[<a href="#RFC5168" class="xref">RFC5168</a>]</span>.<a href="#section-6.8-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="contacts">
<section id="section-7">
      <h2 id="name-contacts">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-contacts" class="section-name selfRef">Contacts</a>
      </h2>
<div id="carddav">
<section id="section-7.1">
        <h3 id="name-carddav-login-and-synchroni">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-carddav-login-and-synchroni" class="section-name selfRef">CardDAV Login and Synchronization</a>
        </h3>
<p id="section-7.1-1">Support of vCard Extensions to WebDAV (CardDAV) by providers is <span class="bcp14">OPTIONAL</span>.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2">The RUE <span class="bcp14">MUST</span> and providers <span class="bcp14">MAY</span> be able to synchronize the user's contact directory between the RUE endpoint and one maintained by the user's VRS provider using CardDAV <span>[<a href="#RFC6352" class="xref">RFC6352</a>]</span> <span>[<a href="#RFC6764" class="xref">RFC6764</a>]</span>.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
<p id="section-7.1-3">The configuration (see <a href="#config" class="xref">Section 9.2</a>) RueConfigurationData <span class="bcp14">MAY</span> supply a "carddav-username" and "carddav-domain" identifying a CardDAV server and address book for this account, plus an optional "carddav-password".<a href="#section-7.1-3" class="pilcrow">¶</a></p>
<p id="section-7.1-4">To access the CardDAV server and address book, the RUE <span class="bcp14">MUST</span> follow <span><a href="https://www.rfc-editor.org/rfc/rfc6764#section-6" class="relref">Section 6</a> of [<a href="#RFC6764" class="xref">RFC6764</a>]</span>, using the configured carddav-username and carddav-domain in place of an email address. If the request triggers a challenge for digest authentication credentials, the RUE <span class="bcp14">MUST</span> continue using matching carddav-username and carddav-password from the configuration. If no carddav-username and carddav-password are configured, the RUE <span class="bcp14">MUST</span> use the SIP user-name and sip-password from the configuration. If the SIP credentials fail, the RUE <span class="bcp14">MUST</span> query the user.<a href="#section-7.1-4" class="pilcrow">¶</a></p>
<p id="section-7.1-5">Synchronization using CardDAV <span class="bcp14">MUST</span> be a two-way synchronization service, with proper handling of asynchronous adds, changes, and deletes at either end of the transport channel.<a href="#section-7.1-5" class="pilcrow">¶</a></p>
<p id="section-7.1-6">The RUE <span class="bcp14">MAY</span> support other CardDAV services.<a href="#section-7.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="import">
<section id="section-7.2">
        <h3 id="name-contacts-import-export-serv">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-contacts-import-export-serv" class="section-name selfRef">Contacts Import/Export Service</a>
        </h3>
<p id="section-7.2-1">Implementations <span class="bcp14">MUST</span> be able to export/import the list of contacts in xCard <span>[<a href="#RFC6351" class="xref">RFC6351</a>]</span> XML format.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">The RUE accesses this service via the "contacts-uri" in the configuration. The URL <span class="bcp14">MUST</span> resolve to identify a web server resource that imports/exports contact lists for authorized users.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
<p id="section-7.2-3">The RUE stores/retrieves the contact list (address book) by issuing an HTTPS POST or GET request. If the request triggers a challenge for digest authentication credentials, the RUE <span class="bcp14">MUST</span> attempt to continue using the "contacts-username" and "contacts-password" from the configuration. If no contacts-username is configured, the SIP user-name from the configuration is used; if the SIP user-name is not configured, the phone-number is used.  If user-name or phone-number is used, the sip-password is used to authenticate to the contact list server.<a href="#section-7.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="mwi">
<section id="section-8">
      <h2 id="name-video-mail">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-video-mail" class="section-name selfRef">Video Mail</a>
      </h2>
<p id="section-8-1">Support for video mail includes a retrieval mechanism and a Message-Waiting Indicator (MWI).  Message storage is not specified by this document.  RUE devices <span class="bcp14">MUST</span> support message retrieval using a SIP call to a specified SIP URI using DTMF to manage the mailbox, as well as a browser-based interface reached at a specified HTTPS URI.  If a provider supports video mail, at least one of these mechanisms <span class="bcp14">MUST</span> be supported.  RUE devices <span class="bcp14">MUST</span> support both.  See <a href="#config" class="xref">Section 9.2</a> for how the URI to reach the retrieval interface is obtained.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">Implementations <span class="bcp14">MUST</span> support subscriptions to "message-summary" events <span>[<a href="#RFC3842" class="xref">RFC3842</a>]</span> to the URI specified in the configuration. Providers <span class="bcp14">MUST</span> support MWI if they support video mail.  RUE devices <span class="bcp14">MUST</span> support MWI.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">The "videomail" and "mwi" properties in the configuration (see RueConfigurationData in <a href="#rueConfig" class="xref">Section 9.2.2</a>) give the URIs for message retrieval and "message-summary" subscription.<a href="#section-8-3" class="pilcrow">¶</a></p>
<p id="section-8-4">In notification bodies, if detailed message summaries are available, messages with video <span class="bcp14">MUST</span> be reported using "message-context-class multimedia-message", as defined in <span>[<a href="#RFC3458" class="xref">RFC3458</a>]</span> .<a href="#section-8-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-9">
      <h2 id="name-provisioning-and-provider-s">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-provisioning-and-provider-s" class="section-name selfRef">Provisioning and Provider Selection</a>
      </h2>
<p id="section-9-1">To simplify how users interact with RUE devices, the RUE interface separates provisioning into two parts.  One provides a directory of providers so that a user interface can allow easy provider selection either for registering or for dial-around.  The other provides configuration data for the device for each provider.<a href="#section-9-1" class="pilcrow">¶</a></p>
<div id="providerselect">
<section id="section-9.1">
        <h3 id="name-rue-provider-selection">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-rue-provider-selection" class="section-name selfRef">RUE Provider Selection</a>
        </h3>
<p id="section-9.1-1">To allow the user to select a relay service, the RUE <span class="bcp14">MAY</span> at any time obtain (typically on startup) a list of providers that provide service in a country.  
IANA has established a registry that contains a two-letter country code and a list entry point string (see <a href="#plist" class="xref">Section 10.1</a>).  The entry point, when used with the following OpenAPI interface, returns a list of provider names for a country code suitable for display, with a corresponding entry point to obtain information about that provider.  No mechanism to determine the country where the RUE is located is specified in this document.  Typically, the country is the home country of the user but may be a local country while traveling.  Some countries allow support from their home country when traveling abroad.  Regardless, the RUE device will need to allow the user to choose the country.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
<p id="section-9.1-2">
Each country that supports VRS using this specification <span class="bcp14">MAY</span> support the provider list.  This document does not specify who maintains the list.  Some possibilities are a regulator or an entity designated by a regulator, an agreement among providers to provide the list, or a user group.<a href="#section-9.1-2" class="pilcrow">¶</a></p>
<p id="section-9.1-3">
            The interface to obtain the list of providers is described by an OpenAPI <span>[<a href="#OpenAPI" class="xref">OpenAPI</a>]</span> interface description.  In that interface description, the "servers" component includes an occurrence of "localhost".   The value from the registry of the "list entry point" string for the
                desired country is substituted for "localhost" in the "servers"
                component to obtain the server URI prefix of the interface to be
                used to obtain the list of providers for that country.  The "Providers" path then specifies the rest of the URI used to obtain the list.  For example, if the list entryPoint is "example.com/api", the provider list would be obtained from https://example.com/api/rum/v1/Providers.<a href="#section-9.1-3" class="pilcrow">¶</a></p>
<p id="section-9.1-4">
        The V1.0 "ProviderList" is a JSON object consisting of an array where each entry describes one provider. Each entry consists of the following items:<a href="#section-9.1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.1-5.1">name: This parameter contains the text label identifying the provider and is meant to be displayed to the human VRS user.<a href="#section-9.1-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-9.1-5.2">providerEntryPoint: A string used for configuration purposes by the RUE (as discussed in <a href="#config" class="xref">Section 9.2</a>).  The string <span class="bcp14">MUST</span> start with a domain but <span class="bcp14">MAY</span> include other URI path elements after the domain.<a href="#section-9.1-5.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-9.1-6">The VRS user interacts with the RUE to select from the provider list one or more providers with whom the user has already established an account, wishes to establish an account, or wishes to use the provider for a one-stage dial-around.<a href="#section-9.1-6" class="pilcrow">¶</a></p>
<span id="name-example-of-a-providerlist-j"></span><figure id="figure-2">
          <div id="section-9.1-7.1">
<pre class="lang-json sourcecode">
{
  "providers": [
    {
      "name": "Red",
      "entryPoint": "red.example.net"
    },
    {
      "name": "Green",
      "entryPoint": "green.example.net"
    },
    {
      "name": "Blue",
      "entryPoint": "blue.example.net"
    }
  ]
}
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-example-of-a-providerlist-j" class="selfRef">Example of a ProviderList JSON Object</a>
          </figcaption></figure>
</section>
</div>
<div id="config">
<section id="section-9.2">
        <h3 id="name-rue-configuration-service">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-rue-configuration-service" class="section-name selfRef">RUE Configuration Service</a>
        </h3>
<p id="section-9.2-1">
                A RUE device may retrieve a provider configuration using a simple HTTPs web service. There are two entry points.  One is used without user credentials, and the response includes configuration data for new user signup and dial-around.  The other uses a locally stored username and password that results from a new user signup to authenticate to the interface and returns configuration data for the RUE.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
<p id="section-9.2-2">The interface to obtain configuration data is described by an OpenAPI <span>[<a href="#OpenAPI" class="xref">OpenAPI</a>]</span> interface description.  In that interface description, the "servers" component string includes an occurrence of "localhost".  The entry point string obtained from the provider list (<a href="#providerselect" class="xref">Section 9.1</a>) is substituted for "localhost" to obtain the server prefix of the interface.  The path then specifies the rest of the URI used to obtain the list.  For example, if the entryPoint from the provider list is "red.example.net", the provider configuration would be obtained from https://red.example.net/rum/V1/ProviderConfig and the RUE configuration would be obtained from https://red.example.net/rum/V1/RueConfig.<a href="#section-9.2-2" class="pilcrow">¶</a></p>
<p id="section-9.2-3">
 In both the queries, an optional parameter may be provided to the interface, which is an API Key (apiKey).  The implementation <span class="bcp14">MAY</span> have an apiKey obtained from the provider and specific to the implementation.  The method used to obtain the apiKey is not specified in this document.  The provider <span class="bcp14">MAY</span> refuse to provide service to an implementation presenting an apiKey it does not recognize.<a href="#section-9.2-3" class="pilcrow">¶</a></p>
<p id="section-9.2-4">
Also in both queries, the RUE device provides a client-provided, required parameter, which contains an instance identifier (instanceId).  This parameter <span class="bcp14">MUST</span> be the same value each time this instance (same implementation on same device) queries the interface.  This <span class="bcp14">MAY</span> be used by the provider, for example, to associate a location with the instance for emergency calls.  This should be globally unique.  A Universally Unique Identifier (UUID) is suggested.<a href="#section-9.2-4" class="pilcrow">¶</a></p>
<p id="section-9.2-5">
        For example, a query for the RUE configuration could be
https://red.example.net/rum/V1/RueConfig?apiKey="t65667Ajjss90uuuDisKt8999"&amp;instanceId="5595b5a3-0687-4b8e-9913-a7f2a04fb7bd"<a href="#section-9.2-5" class="pilcrow">¶</a></p>
<p id="section-9.2-6">
                The data returned is a JSON object consisting of key/value configuration parameters to be used by the RUE.<a href="#section-9.2-6" class="pilcrow">¶</a></p>
<p id="section-9.2-7">
                The configuration data payload includes the following data items. Items not noted as (<span class="bcp14">OPTIONAL</span>) are <span class="bcp14">REQUIRED</span>. If other unexpected items are found, they <span class="bcp14">MUST</span> be ignored.<a href="#section-9.2-7" class="pilcrow">¶</a></p>
<div id="providerConfig">
<section id="section-9.2.1">
          <h4 id="name-provider-configuration">
<a href="#section-9.2.1" class="section-number selfRef">9.2.1. </a><a href="#name-provider-configuration" class="section-name selfRef">Provider Configuration</a>
          </h4>
<ul class="normal">
<li class="normal" id="section-9.2.1-1.1">
              <p id="section-9.2.1-1.1.1">signup: (<span class="bcp14">OPTIONAL</span>) an array of JSON objects consisting of:<a href="#section-9.2.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.2.1-1.1.2.1">language: entry from the IANA "Language Subtag Registry" (<span><a href="https://www.iana.org/assignments/language-subtag-registry">https://www.iana.org/assignments/language-subtag-registry</a></span>). Normally, this would be a written language tag.<a href="#section-9.2.1-1.1.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-9.2.1-1.1.2.2">uri: a URI to the website for creating a new account in the supported language. The new user signup URI may only initiate creation of a new account.  Various vetting, approval, and other processes may be needed, which could take time, before the account is established.  The result of creating a new account would be account credentials (e.g., username and password), which would be manually entered into the RUE device that forms the authentication parameters for the RUE configuration service described below in <a href="#rueConfig" class="xref">Section 9.2.2</a>.<a href="#section-9.2.1-1.1.2.2" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li class="normal" id="section-9.2.1-1.2">
              <p id="section-9.2.1-1.2.1">dial-around: an array of JSON objects consisting of:<a href="#section-9.2.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.2.1-1.2.2.1">language: entry from the IANA "Language Subtag Registry".  Normally, this would be a sign language tag.<a href="#section-9.2.1-1.2.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-9.2.1-1.2.2.2">front-door: a URI to a queue of interpreters supporting the specified language for a two-stage dial-around.<a href="#section-9.2.1-1.2.2.2" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-9.2.1-1.2.2.3">oneStage: a URI that can be used with a one-stage dial-around (<a href="#onestage" class="xref">Section 5.2.2</a>) using an interpreter supporting the specified language.<a href="#section-9.2.1-1.2.2.3" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li class="normal" id="section-9.2.1-1.3">
              <p id="section-9.2.1-1.3.1">helpDesk: (<span class="bcp14">OPTIONAL</span>) an array of JSON objects consisting of:<a href="#section-9.2.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.2.1-1.3.2.1">language: entry from the IANA "Language Subtag Registry". Normally, this would be a sign language tag; although, it could be a written language tag if the help desk only supports a chat interface.<a href="#section-9.2.1-1.3.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-9.2.1-1.3.2.2">uri: a URI that reaches a help desk for callers supporting the specified language.  The URI <span class="bcp14">MAY</span> be a SIP URI for help provided with a SIP call or <span class="bcp14">MAY</span> be an HTTPS URI for help provided with a browser interface.<a href="#section-9.2.1-1.3.2.2" class="pilcrow">¶</a>
</li>
              </ul>
<p id="section-9.2.1-1.3.3">A list is specified so that the provider can offer multiple choices to users for language and interface styles.<a href="#section-9.2.1-1.3.3" class="pilcrow">¶</a></p>
</li>
          </ul>
</section>
</div>
<div id="rueConfig">
<section id="section-9.2.2">
          <h4 id="name-rue-configuration">
<a href="#section-9.2.2" class="section-number selfRef">9.2.2. </a><a href="#name-rue-configuration" class="section-name selfRef">RUE Configuration</a>
          </h4>
<ul class="normal">
<li class="normal" id="section-9.2.2-1.1">lifetime: (<span class="bcp14">OPTIONAL</span>) specifies how long (in seconds) the RUE <span class="bcp14">MAY</span> cache the configuration values.  Values may not be valid when lifetime expires.  If the RUE caches configuration values, it <span class="bcp14">MUST</span> cryptographically protect them against unauthorized disclosure (e.g., by other applications on the platform the RUE is built on). The RUE <span class="bcp14">SHOULD</span> retrieve a fresh copy of the configuration before the lifetime expires or as soon as possible after it expires. The lifetime is not guaranteed, i.e., the configuration may change before the lifetime value expires. In that case, the provider <span class="bcp14">MAY</span> indicate this by generating authorization challenges to requests and/or prematurely terminating a registration. Emergency calls <span class="bcp14">MUST</span> continue to work.  If not specified, the RUE <span class="bcp14">MUST</span> fetch new configuration data every time it starts.<a href="#section-9.2.2-1.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.2-1.2">sip-password: (<span class="bcp14">OPTIONAL</span>) a password used for SIP, STUN, and TURN authentication.  The RUE device retains this data, which it <span class="bcp14">MUST</span> cryptographically protect against unauthorized disclosure (e.g., by other applications on the platform the RUE is built on).  If it is not supplied but was supplied on a prior invocation of this interface, the most recently supplied password <span class="bcp14">MUST</span> be used.  If it was never supplied, the password used to authenticate to the configuration service is used for SIP, as well as STUN and TURN servers mentioned in this configuration.<a href="#section-9.2.2-1.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.2-1.3">phone-number: (<span class="bcp14">REQUIRED</span>) the telephone number (in E.164 format) assigned to this subscriber. This becomes the user portion of the SIP URI identifying the subscriber.<a href="#section-9.2.2-1.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.2-1.4">user-name: (<span class="bcp14">OPTIONAL</span>) a username used for authenticating to the provider.  If not provided, phone-number is used.<a href="#section-9.2.2-1.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.2-1.5">display-name: (<span class="bcp14">OPTIONAL</span>) a human-readable display name for the subscriber.<a href="#section-9.2.2-1.5" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.2-1.6">provider-domain: (<span class="bcp14">REQUIRED</span>) the domain for the provider.  This becomes the server portion of the SIP URI identifying the subscriber.<a href="#section-9.2.2-1.6" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.2-1.7">outbound-proxies: (<span class="bcp14">OPTIONAL</span>) an array of URIs of SIP proxies to be used when sending requests to the provider.<a href="#section-9.2.2-1.7" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.2-1.8">mwi: (<span class="bcp14">OPTIONAL</span>) a URI identifying a SIP event server that generates "message-summary" events for this subscriber.<a href="#section-9.2.2-1.8" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.2-1.9">videomail: (<span class="bcp14">OPTIONAL</span>) a SIP or HTTPS URI that can be used to retrieve video mail messages.<a href="#section-9.2.2-1.9" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.2-1.10">contacts: (<span class="bcp14">OPTIONAL</span>) an HTTPS URI ("contacts-uri"), (<span class="bcp14">OPTIONAL</span>) "contacts-username", and "contacts-password" that may be used to export (retrieve) the subscriber's complete contact list managed by the provider. At least the URI <span class="bcp14">MUST</span> be provided if the subscriber has contacts. If contact-username and contacts-password are not supplied, the sip credentials are used. If the contacts-username is provided, contacts-password <span class="bcp14">MUST</span> be provided.  If contacts-password is provided, contacts-username <span class="bcp14">MUST</span> be provided.<a href="#section-9.2.2-1.10" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.2-1.11">carddav: (<span class="bcp14">OPTIONAL</span>) an address ("carddav-domain"), (<span class="bcp14">OPTIONAL</span>) "carddav-username", and "carddav-password" identifying a "CardDAV" server and account that can be used to synchronize the RUE's contact list with the contact list managed by the provider.  If carddav-username and carddav-password are not supplied, the sip credentials are used. If the carddav-username is provided, carddav-password <span class="bcp14">MUST</span> be provided.  If carddav-password is provided, carddav-username <span class="bcp14">MUST</span> be provided.<a href="#section-9.2.2-1.11" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.2-1.12">sendLocationWithRegistration: (<span class="bcp14">OPTIONAL</span>) true if the RUE should send a Geolocation header field with REGISTER; false if it should not. Defaults to false if not present.<a href="#section-9.2.2-1.12" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.2-1.13">ice-servers: (<span class="bcp14">OPTIONAL</span>) an array of server types and URLs identifying STUN and TURN servers available for use by the RUE for establishing media streams in calls via the provider. If the same URL provides both STUN and TURN services, it <span class="bcp14">MUST</span> be listed twice, each with different server types.<a href="#section-9.2.2-1.13" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="versions">
<section id="section-9.2.3">
          <h4 id="name-versions">
<a href="#section-9.2.3" class="section-number selfRef">9.2.3. </a><a href="#name-versions" class="section-name selfRef">Versions</a>
          </h4>
<p id="section-9.2.3-1">
       Both web services also have a simple version mechanism that returns a list of versions of the web service it supports.       
This document describes version 1.0.
Versions are displayed as a major version, followed by
a period ".", followed by a minor version, where the major and minor
versions are integers. A backwards compatible change within a major version <span class="bcp14">MAY</span> increment only the minor version number.  A non-backwards, compatible change <span class="bcp14">MUST</span> increment the major version number.  Backwards compatibility applies to both the server and the client.  Either may have any higher or lower minor revision and interoperate with its counterpart with the same major version.  To achieve backwards compatibility, implementations <span class="bcp14">MUST</span> ignore any object members they do not implement. Minor version definitions <span class="bcp14">SHALL</span> only add objects, optional members of existing objects, and non-mandatory-to-use functions and <span class="bcp14">SHALL NOT</span> delete or change any objects, members of objects, or functions.  This means an implementation of a specific major version and minor version is backwards compatible with all minor versions of the major version.  The version mechanism returns an array of supported versions, one for each major version supported, with the minor version listed being the highest-supported minor version.<a href="#section-9.2.3-1" class="pilcrow">¶</a></p>
<p id="section-9.2.3-2">Unless the per-country provider list service is operated by a provider at the same base URI as that provider's configuration service, the version of the configuration service <span class="bcp14">MAY</span> be different from the version of the provider list service.<a href="#section-9.2.3-2" class="pilcrow">¶</a></p>
<span id="name-example-of-a-version-json-o"></span><figure id="figure-3">
            <div id="section-9.2.3-3.1">
<pre class="lang-json sourcecode">
{
  "versions": [
    {
     "major": 1,
     "minor": 6
    },
    {
     "major": 2,
     "minor": 13
    },
    {
     "major": 3,
     "minor": 2
    }
  ]
}
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-example-of-a-version-json-o" class="selfRef">Example of a Version JSON Object</a>
            </figcaption></figure>
</section>
</div>
<div id="configExamples">
<section id="section-9.2.4">
          <h4 id="name-examples">
<a href="#section-9.2.4" class="section-number selfRef">9.2.4. </a><a href="#name-examples" class="section-name selfRef">Examples</a>
          </h4>
<span id="name-example-json-provider-confi"></span><figure id="figure-4">
            <div id="section-9.2.4-1.1">
<pre class="lang-json sourcecode">
{
  "signUp": [
     { "language" : "en", "uri" : "https:hello-en.example.net"},
     { "language" : "es", "uri" : "https:hello-es.example.net"} ] ,
  "dial-around": [
     { "language" : "en", "front-door" : "sip:fd-en.example.net",
          "oneStage" : "sip:1stg-eng.example.com" } ,
     { "language" : "es", "front-door" : "sip:fd-es.example.net",
          "oneStage" : "sip:1stg-spn.example.com" } ] ,
  "helpDesk": [
     { "language" : "en", "uri" : "sip:help-en.example.net"} ,
     { "language" : "es", "uri" : "sip:help-es.example.net"} ]
}
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-example-json-provider-confi" class="selfRef">Example JSON Provider Configuration Payload</a>
            </figcaption></figure>
<span id="name-example-json-rue-configurat"></span><figure id="figure-5">
            <div id="section-9.2.4-2.1">
<pre class="lang-json sourcecode">
{
  "lifetime": 86400,
  "display-name" : "Bob Smith",
  "phone-number": "+15551234567",
  "provider-domain": "red.example.net",
  "outbound-proxies": [
    "sip:p1.red.example.net",
    "sip:p2.red.example.net" ],
  "mwi": "sip:+15551234567@red.example.net;user=phone",
  "videomail": "sip:+15551234567@vm.red.example.net;user=phone",
  "contacts": {
    "contacts-uri":
       "https://red.example.net:443/c/3617b719-2c3a-46f4-9c13",
    "contacts-username": "bob",
    "contacts-password": "XhOT4ch@ZEi&amp;3u2xEYQNMO^5UGb"
  },
  "carddav": {
     "carddav-domain": "carddav.example.com",
     "carddav-username": "bob",
     "carddav-password": "sj887%dd*jJty%87hyys5hHT"
  },
  "sendLocationWithRegistration": false,
  "ice-servers": [
     {"stun":"stun.red.example.com:19302" },
     {"turn":"turn.red.example.com:3478"}
  ]
}
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-example-json-rue-configurat" class="selfRef">Example JSON RUE Configuration Payload</a>
            </figcaption></figure>
</section>
</div>
<div id="configExplain">
<section id="section-9.2.5">
          <h4 id="name-using-the-provider-selectio">
<a href="#section-9.2.5" class="section-number selfRef">9.2.5. </a><a href="#name-using-the-provider-selectio" class="section-name selfRef">Using the Provider Selection and RUE Configuration Services Together</a>
          </h4>
<p id="section-9.2.5-1">One way to use these two services is:<a href="#section-9.2.5-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-9.2.5-2">
   <li id="section-9.2.5-2.1">At startup, the RUE retrieves the provider list for the country it is located in.<a href="#section-9.2.5-2.1" class="pilcrow">¶</a>
</li>
            <li id="section-9.2.5-2.2">
              <p id="section-9.2.5-2.2.1">For each provider in the list:<a href="#section-9.2.5-2.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.2.5-2.2.2.1">If the RUE does not have credentials for that provider, if requested by the user, use the ProviderConfig path without credentials to obtain signup, dial-around, and help desk information.<a href="#section-9.2.5-2.2.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-9.2.5-2.2.2.2">If the RUE has credentials for that provider, use the RueConfig path with the locally stored credentials to configure the RUE for that provider.<a href="#section-9.2.5-2.2.2.2" class="pilcrow">¶</a>
</li>
              </ul>
</li>
          </ol>
</section>
</div>
</section>
</div>
<div id="schema">
<section id="section-9.3">
        <h3 id="name-openapi-interface-descripti">
<a href="#section-9.3" class="section-number selfRef">9.3. </a><a href="#name-openapi-interface-descripti" class="section-name selfRef">OpenAPI Interface Descriptions</a>
        </h3>
<p id="section-9.3-1">The interfaces in Sections <a href="#providerselect" class="xref">9.1</a> and <a href="#config" class="xref">9.2</a> are formally specified with OpenAPI 3.0 <span>[<a href="#OpenAPI" class="xref">OpenAPI</a>]</span> descriptions in YAML form.<a href="#section-9.3-1" class="pilcrow">¶</a></p>
<p id="section-9.3-2">The OpenAPI description below is normative.  If there is any conflict between the text or examples and this section, the OpenAPI description takes precedence.<a href="#section-9.3-2" class="pilcrow">¶</a></p>
<div id="listSchema">
<section id="section-9.3.1">
          <h4 id="name-provider-list">
<a href="#section-9.3.1" class="section-number selfRef">9.3.1. </a><a href="#name-provider-list" class="section-name selfRef">Provider List</a>
          </h4>
<span id="name-provider-list-openapi-descr"></span><figure id="figure-6">
            <div id="section-9.3.1-1.1">
<pre class="breakable lang-yaml sourcecode">
openapi: 3.0.1
info:
  title: RUM Provider List API
  version: "1.0"
servers:
  - url: https://localhost/rum/v1
paths:
  /Providers:
    get:
      summary: Get a list of providers and domains to get
               config data from
      operationId: GetProviderList
      responses:
        '200':
          description: List of providers for a country
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ProviderList'
  /Versions:
    servers:
      - url: https://localhost/rum
        description: Override base path for Versions query
    get:
      summary: Retrieves all supported versions
      operationId: RetrieveVersions
      responses:
        '200':
          description: Versions supported
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/VersionsArray'
components:
  schemas:
    ProviderList:
      type: object
      required:
        - providers
      properties:
        providers:
          type: array
          items:
            type: object
            required:
              - name
              - providerEntryPoint
            properties:
              name:
                type: string
                description: Human-readable provider name
              providerEntryPoint:
                type: string
                description: Provider entry point for interface
    VersionsArray:
      type: object
      required:
        - versions
      properties:
        versions:
          type: array
          items:
            type: object
            required:
              - major
              - minor
            properties:
              major:
                type: integer
                format: int32
                description: Version major number
              minor:
                type: integer
                format: int32
                description: Version minor number
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-provider-list-openapi-descr" class="selfRef">Provider List OpenAPI Description (RueProviderList.yaml)</a>
            </figcaption></figure>
</section>
</div>
<div id="configSchema">
<section id="section-9.3.2">
          <h4 id="name-configuration">
<a href="#section-9.3.2" class="section-number selfRef">9.3.2. </a><a href="#name-configuration" class="section-name selfRef">Configuration</a>
          </h4>
<span id="name-configuration-openapi-descr"></span><figure id="figure-7">
            <div id="section-9.3.2-1.1">
<pre class="breakable lang-yaml sourcecode">
openapi: 3.0.1
info:
  title: RUM Configuration API
  version: "1.0"
servers:
  - url: https://localhost/rum/v1
paths:
  /ProviderConfig:
    get:
      summary: Configuration data for one provider
      operationId: GetProviderConfiguration
      parameters:
        - in: query
          name: apiKey
          schema:
            type: string
          description: API Key assigned to this implementation
        - in: query
          name: instanceId
          schema:
            type: string
          required: true
          description: Unique string for this implementation
                       on this device
      responses:
        '200':
          description: Configuration object
          content:
            application/json:
              schema:
                $ref:
                 '#/components/schemas/ProviderConfigurationData'
  /RueConfig:
    get:
      summary: Configuration data for one RUE
      operationId: GetRueConfiguration
      parameters:
        - in: query
          name: apiKey
          schema:
            type: string
          description: API Key assigned to this implementation
        - in: query
          name: instanceId
          schema:
            type: string
          required: true
          description: Unique string for this implementation
                       on this device
      responses:
        '200':
          description: Configuration object
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/RueConfigurationData'
  /Versions:
    servers:
      - url: https://localhost/rum
        description: Override base path for Versions query
    get:
      summary: Retrieves all supported versions
      operationId: RetrieveVersions
      responses:
        '200':
          description: Versions supported
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/VersionsArray'
components:
  schemas:
    ProviderConfigurationData:
      type: object
      required:
        - dial-around
      properties:
        signup:
          type: array
          items:
            type: object
            required:
              - language
              - uri
            properties:
              language:
                type: string
                description: Entry from IANA "Language Subtag
                  Registry"
              uri:
                type: string
                format: uri
                description: URI to signup website supporting
                  this language
        dial-around:
          type: array
          items:
            type: object
            required:
              - language
              - front-door
              - oneStage
            properties:
              language:
                type: string
                description: Entry from IANA "Language Subtag
                  Registry"
              front-door:
                type: string
                format: uri
                description: SIP URI for two-stage dial-around
              oneStage:
                type: string
                format: uri
                description: SIP URI for one-stage dial-around
        helpDesk:
          type: array
          items:
            type: object
            required:
              - language
              - uri
            properties:
              language:
                type: string
                description: Entry from IANA "Language Subtag
                   Registry"
              uri:
                type: string
                format: uri
                description: SIP URI of help desk supporting language
    RueConfigurationData:
      type: object
      required:
        - phone-number
        - provider-domain
      properties:
        lifetime:
          type: integer
          description: How long (in seconds) the RUE MAY cache the
                       configuration values
        sip-password:
          type: string
        phone-number:
          type: string
          description: Telephone number assigned this subscriber in
            E.164 format
        user-name:
          type: string
          description: A username assigned to this subscriber
        display-name:
          type: string
          description: Display name for the subscriber
        provider-domain:
          type: string
          description: Domain of the provider for this subscriber
        outbound-proxies:
          type: array
          items:
             type: string
             format: uri
             description: SIP URI of a proxy to be used when sending
                       requests to the provider
        mwi:
          type: string
          format: uri
          description: A URI identifying a SIP event server that
              generates "message-summary" events for this subscriber
        videomail:
          type: string
          format: uri
          description: An HTTPS or SIP URI that can be used to
                       retrieve video mail messages
        contacts:
          type: object
          description: Server and credentials for contact
             import/export
          required:
            - contacts-uri
          properties:
            contacts-uri:
              type: string
              format: uri
              description: An HTTPS URI that may be used to export
                (retrieve) the subscriber's complete contact list
                managed by the provider
            contacts-username:
              type: string
              description: Username for authentication with the
                CardDAV server.  Use SIP user-name if not provided
            contacts-password:
              type: string
              description: Password for authentication. Use provider
                sip-password if not provided
        carddav:
          type: object
          description: CardDAV server and user information that can
               be used to synchronize the RUE's contact list with
               the contact list managed by the provider
          required:
            - carddav-domain
          properties:
            carddav-domain:
              type: string
              description: CardDAV server address
            carddav-username:
              type: string
              description: Username for authentication with the
                 CardDAV server.  Use SIP user-name if not provided
            carddav-password:
              type: string
              description: Password for authentication to the CardDAV
                 server. Use provider sip-password if not provided
        sendLocationWithRegistration:
          type: boolean
          description: True if the RUE should send a Geolocation
               header field with REGISTER; false if it should not.
               Defaults to false if not present
        ice-servers:
          type: array
          items:
            type: object
            required:
              - server-type
              - uri
            properties:
              server-type:
                type: string
                description: Server type ("stun" or "turn")
              uri:
                type: string
                format: uri
                description: URIs identifying STUN and TURN servers
                  available for use by the RUE for establishing
                  media streams in calls via the provider
    VersionsArray:
      type: object
      required:
        - versions
      properties:
        versions:
          type: array
          items:
            type: object
            required:
              - major
              - minor
            properties:
              major:
                type: integer
                format: int32
                description: Version major number
              minor:
                type: integer
                format: int32
                description: Version minor number
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-configuration-openapi-descr" class="selfRef">Configuration OpenAPI Description (RueConfiguration.yaml)</a>
            </figcaption></figure>
</section>
</div>
</section>
</div>
</section>
<div id="IANA">
<section id="section-10">
      <h2 id="name-iana-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<div id="plist">
<section id="section-10.1">
        <h3 id="name-rue-provider-list-registry">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-rue-provider-list-registry" class="section-name selfRef">RUE Provider List Registry</a>
        </h3>
<p id="section-10.1-1">IANA has created the "RUE Provider List" registry.  The registration policy is "Expert Review" <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.
   A regulator operated or designated list interface operator is preferred. 
Otherwise, evidence that the proposed list interface operator will provide a complete list of providers is required to add the entry to the registry.  
   Updates to the registry are permitted if
   the expert determines that the proposed URI provides a more accurate
   list than the existing entry.
 Each entry has two fields; values for both <span class="bcp14">MUST</span> be provided when registering or updating an entry:<a href="#section-10.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-10.1-2.1">country code: a two-letter ISO93166 country code<a href="#section-10.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.1-2.2">list entry point: a string is used to compose the URI to the provider list interface for that country<a href="#section-10.1-2.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="purpose">
<section id="section-10.2">
        <h3 id="name-registration-of-rue-owner-v">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-registration-of-rue-owner-v" class="section-name selfRef">Registration of Rue-Owner Value of the Purpose Parameter</a>
        </h3>
<p id="section-10.2-1">This document defines the new predefined value "rue-owner" for the "purpose" header field parameter of the Call-Info header field. The use for rue-owner is defined in <a href="#contact" class="xref">Section 5.2.3</a>. IANA has added a reference to this document in the "Header Field Parameters and Parameter Values" subregistry of the "Session Initiation Protocol (SIP) Parameters" for the header field "Call-Info" and parameter name "purpose".<a href="#section-10.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-10.2-2">
          <dt id="section-10.2-2.1">Header Field:</dt>
          <dd style="margin-left: 1.5em" id="section-10.2-2.2">Call-Info<a href="#section-10.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-10.2-2.3">Parameter Name:</dt>
          <dd style="margin-left: 1.5em" id="section-10.2-2.4">purpose<a href="#section-10.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-10.2-2.5">Predefined Values:</dt>
          <dd style="margin-left: 1.5em" id="section-10.2-2.6">Yes<a href="#section-10.2-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="Security">
<section id="section-11">
      <h2 id="name-security-considerations">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-11-1">
         The RUE is required to communicate with servers on public IP addresses and specific ports to perform its required functions. If it is necessary for the RUE to function on a corporate or other network that operates a default-deny firewall between the RUE and these services, the user must arrange with their network manager for passage of traffic through such a firewall in accordance with the protocols and associated SRV records as exposed by the provider. Because VRS providers may use different ports for different services, these port numbers may differ from provider to provider.<a href="#section-11-1" class="pilcrow">¶</a></p>
<p id="section-11-2">This document
          requires implementation and use of a number of other specifications in
          order to fulfill the RUE profile; the security considerations described
          in those documents apply accordingly to the RUE interactions.<a href="#section-11-2" class="pilcrow">¶</a></p>
<p id="section-11-3"> When a CA participates in a conversation, they
          have access to the content of the conversation even though it is
          nominally a conversation between the two endpoints.  There is an
          expectation that the CA will keep the communication contents in
          confidence.  This is usually defined by contractual or legal requirements.<a href="#section-11-3" class="pilcrow">¶</a></p>
<p id="section-11-4">Since different providers (within a given country) may have different
          policies, RUE implementations <span class="bcp14">MUST</span> include a user
          interaction step to select from available providers before proceeding to actually register with any given
          provider.<a href="#section-11-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-12">
      <h2 id="name-normative-references">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
      </h2>
<dl class="references">
<dt id="OpenAPI">[OpenAPI]</dt>
      <dd>
<span class="refAuthor">Miller, D.</span>, <span class="refAuthor">Whitlock, J.</span>, <span class="refAuthor">Gardiner, M.</span>, <span class="refAuthor">Ralphson, M.</span>, <span class="refAuthor">Ratovsky, R.</span>, and <span class="refAuthor">U. Sarid</span>, <span class="refTitle">"OpenAPI Specification v3.0.1"</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://spec.openapis.org/oas/v3.0.1">https://spec.openapis.org/oas/v3.0.1</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
      <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2392">[RFC2392]</dt>
      <dd>
<span class="refAuthor">Levinson, E.</span>, <span class="refTitle">"Content-ID and Message-ID Uniform Resource Locators"</span>, <span class="seriesInfo">RFC 2392</span>, <span class="seriesInfo">DOI 10.17487/RFC2392</span>, <time datetime="1998-08" class="refDate">August 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2392">https://www.rfc-editor.org/info/rfc2392</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>, and <span class="refAuthor">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="RFC3263">[RFC3263]</dt>
      <dd>
<span class="refAuthor">Rosenberg, J.</span> and <span class="refAuthor">H. Schulzrinne</span>, <span class="refTitle">"Session Initiation Protocol (SIP): Locating SIP Servers"</span>, <span class="seriesInfo">RFC 3263</span>, <span class="seriesInfo">DOI 10.17487/RFC3263</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3263">https://www.rfc-editor.org/info/rfc3263</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3264">[RFC3264]</dt>
      <dd>
<span class="refAuthor">Rosenberg, J.</span> and <span class="refAuthor">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="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="RFC3323">[RFC3323]</dt>
      <dd>
<span class="refAuthor">Peterson, J.</span>, <span class="refTitle">"A Privacy Mechanism for the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 3323</span>, <span class="seriesInfo">DOI 10.17487/RFC3323</span>, <time datetime="2002-11" class="refDate">November 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3323">https://www.rfc-editor.org/info/rfc3323</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3326">[RFC3326]</dt>
      <dd>
<span class="refAuthor">Schulzrinne, H.</span>, <span class="refAuthor">Oran, D.</span>, and <span class="refAuthor">G. Camarillo</span>, <span class="refTitle">"The Reason Header Field for the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 3326</span>, <span class="seriesInfo">DOI 10.17487/RFC3326</span>, <time datetime="2002-12" class="refDate">December 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3326">https://www.rfc-editor.org/info/rfc3326</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3327">[RFC3327]</dt>
      <dd>
<span class="refAuthor">Willis, D.</span> and <span class="refAuthor">B. Hoeneisen</span>, <span class="refTitle">"Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts"</span>, <span class="seriesInfo">RFC 3327</span>, <span class="seriesInfo">DOI 10.17487/RFC3327</span>, <time datetime="2002-12" class="refDate">December 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3327">https://www.rfc-editor.org/info/rfc3327</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3458">[RFC3458]</dt>
      <dd>
<span class="refAuthor">Burger, E.</span>, <span class="refAuthor">Candell, E.</span>, <span class="refAuthor">Eliot, C.</span>, and <span class="refAuthor">G. Klyne</span>, <span class="refTitle">"Message Context for Internet Mail"</span>, <span class="seriesInfo">RFC 3458</span>, <span class="seriesInfo">DOI 10.17487/RFC3458</span>, <time datetime="2003-01" class="refDate">January 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3458">https://www.rfc-editor.org/info/rfc3458</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3515">[RFC3515]</dt>
      <dd>
<span class="refAuthor">Sparks, R.</span>, <span class="refTitle">"The Session Initiation Protocol (SIP) Refer Method"</span>, <span class="seriesInfo">RFC 3515</span>, <span class="seriesInfo">DOI 10.17487/RFC3515</span>, <time datetime="2003-04" class="refDate">April 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3515">https://www.rfc-editor.org/info/rfc3515</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="RFC3840">[RFC3840]</dt>
      <dd>
<span class="refAuthor">Rosenberg, J.</span>, <span class="refAuthor">Schulzrinne, H.</span>, and <span class="refAuthor">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="RFC3842">[RFC3842]</dt>
      <dd>
<span class="refAuthor">Mahy, R.</span>, <span class="refTitle">"A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 3842</span>, <span class="seriesInfo">DOI 10.17487/RFC3842</span>, <time datetime="2004-08" class="refDate">August 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3842">https://www.rfc-editor.org/info/rfc3842</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3891">[RFC3891]</dt>
      <dd>
<span class="refAuthor">Mahy, R.</span>, <span class="refAuthor">Biggs, B.</span>, and <span class="refAuthor">R. Dean</span>, <span class="refTitle">"The Session Initiation Protocol (SIP) "Replaces" Header"</span>, <span class="seriesInfo">RFC 3891</span>, <span class="seriesInfo">DOI 10.17487/RFC3891</span>, <time datetime="2004-09" class="refDate">September 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3891">https://www.rfc-editor.org/info/rfc3891</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3892">[RFC3892]</dt>
      <dd>
<span class="refAuthor">Sparks, R.</span>, <span class="refTitle">"The Session Initiation Protocol (SIP) Referred-By Mechanism"</span>, <span class="seriesInfo">RFC 3892</span>, <span class="seriesInfo">DOI 10.17487/RFC3892</span>, <time datetime="2004-09" class="refDate">September 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3892">https://www.rfc-editor.org/info/rfc3892</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3960">[RFC3960]</dt>
      <dd>
<span class="refAuthor">Camarillo, G.</span> and <span class="refAuthor">H. Schulzrinne</span>, <span class="refTitle">"Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 3960</span>, <span class="seriesInfo">DOI 10.17487/RFC3960</span>, <time datetime="2004-12" class="refDate">December 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3960">https://www.rfc-editor.org/info/rfc3960</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3966">[RFC3966]</dt>
      <dd>
<span class="refAuthor">Schulzrinne, H.</span>, <span class="refTitle">"The tel URI for Telephone Numbers"</span>, <span class="seriesInfo">RFC 3966</span>, <span class="seriesInfo">DOI 10.17487/RFC3966</span>, <time datetime="2004-12" class="refDate">December 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3966">https://www.rfc-editor.org/info/rfc3966</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4102">[RFC4102]</dt>
      <dd>
<span class="refAuthor">Jones, P.</span>, <span class="refTitle">"Registration of the text/red MIME Sub-Type"</span>, <span class="seriesInfo">RFC 4102</span>, <span class="seriesInfo">DOI 10.17487/RFC4102</span>, <time datetime="2005-06" class="refDate">June 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4102">https://www.rfc-editor.org/info/rfc4102</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4103">[RFC4103]</dt>
      <dd>
<span class="refAuthor">Hellstrom, G.</span> and <span class="refAuthor">P. Jones</span>, <span class="refTitle">"RTP Payload for Text Conversation"</span>, <span class="seriesInfo">RFC 4103</span>, <span class="seriesInfo">DOI 10.17487/RFC4103</span>, <time datetime="2005-06" class="refDate">June 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4103">https://www.rfc-editor.org/info/rfc4103</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4488">[RFC4488]</dt>
      <dd>
<span class="refAuthor">Levin, O.</span>, <span class="refTitle">"Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription"</span>, <span class="seriesInfo">RFC 4488</span>, <span class="seriesInfo">DOI 10.17487/RFC4488</span>, <time datetime="2006-05" class="refDate">May 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4488">https://www.rfc-editor.org/info/rfc4488</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4585">[RFC4585]</dt>
      <dd>
<span class="refAuthor">Ott, J.</span>, <span class="refAuthor">Wenger, S.</span>, <span class="refAuthor">Sato, N.</span>, <span class="refAuthor">Burmeister, C.</span>, and <span class="refAuthor">J. Rey</span>, <span class="refTitle">"Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"</span>, <span class="seriesInfo">RFC 4585</span>, <span class="seriesInfo">DOI 10.17487/RFC4585</span>, <time datetime="2006-07" class="refDate">July 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4585">https://www.rfc-editor.org/info/rfc4585</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4733">[RFC4733]</dt>
      <dd>
<span class="refAuthor">Schulzrinne, H.</span> and <span class="refAuthor">T. Taylor</span>, <span class="refTitle">"RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals"</span>, <span class="seriesInfo">RFC 4733</span>, <span class="seriesInfo">DOI 10.17487/RFC4733</span>, <time datetime="2006-12" class="refDate">December 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4733">https://www.rfc-editor.org/info/rfc4733</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4967">[RFC4967]</dt>
      <dd>
<span class="refAuthor">Rosen, B.</span>, <span class="refTitle">"Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier"</span>, <span class="seriesInfo">RFC 4967</span>, <span class="seriesInfo">DOI 10.17487/RFC4967</span>, <time datetime="2007-07" class="refDate">July 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4967">https://www.rfc-editor.org/info/rfc4967</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5104">[RFC5104]</dt>
      <dd>
<span class="refAuthor">Wenger, S.</span>, <span class="refAuthor">Chandra, U.</span>, <span class="refAuthor">Westerlund, M.</span>, and <span class="refAuthor">B. Burman</span>, <span class="refTitle">"Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"</span>, <span class="seriesInfo">RFC 5104</span>, <span class="seriesInfo">DOI 10.17487/RFC5104</span>, <time datetime="2008-02" class="refDate">February 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5104">https://www.rfc-editor.org/info/rfc5104</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5168">[RFC5168]</dt>
      <dd>
<span class="refAuthor">Levin, O.</span>, <span class="refAuthor">Even, R.</span>, and <span class="refAuthor">P. Hagendorf</span>, <span class="refTitle">"XML Schema for Media Control"</span>, <span class="seriesInfo">RFC 5168</span>, <span class="seriesInfo">DOI 10.17487/RFC5168</span>, <time datetime="2008-03" class="refDate">March 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5168">https://www.rfc-editor.org/info/rfc5168</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5393">[RFC5393]</dt>
      <dd>
<span class="refAuthor">Sparks, R., Ed.</span>, <span class="refAuthor">Lawrence, S.</span>, <span class="refAuthor">Hawrylyshen, A.</span>, and <span class="refAuthor">B. Campen</span>, <span class="refTitle">"Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies"</span>, <span class="seriesInfo">RFC 5393</span>, <span class="seriesInfo">DOI 10.17487/RFC5393</span>, <time datetime="2008-12" class="refDate">December 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5393">https://www.rfc-editor.org/info/rfc5393</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5626">[RFC5626]</dt>
      <dd>
<span class="refAuthor">Jennings, C., Ed.</span>, <span class="refAuthor">Mahy, R., Ed.</span>, and <span class="refAuthor">F. Audet, Ed.</span>, <span class="refTitle">"Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 5626</span>, <span class="seriesInfo">DOI 10.17487/RFC5626</span>, <time datetime="2009-10" class="refDate">October 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5626">https://www.rfc-editor.org/info/rfc5626</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5658">[RFC5658]</dt>
      <dd>
<span class="refAuthor">Froment, T.</span>, <span class="refAuthor">Lebel, C.</span>, and <span class="refAuthor">B. Bonnaerens</span>, <span class="refTitle">"Addressing Record-Route Issues in the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 5658</span>, <span class="seriesInfo">DOI 10.17487/RFC5658</span>, <time datetime="2009-10" class="refDate">October 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5658">https://www.rfc-editor.org/info/rfc5658</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5954">[RFC5954]</dt>
      <dd>
<span class="refAuthor">Gurbani, V., Ed.</span>, <span class="refAuthor">Carpenter, B., Ed.</span>, and <span class="refAuthor">B. Tate, Ed.</span>, <span class="refTitle">"Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261"</span>, <span class="seriesInfo">RFC 5954</span>, <span class="seriesInfo">DOI 10.17487/RFC5954</span>, <time datetime="2010-08" class="refDate">August 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5954">https://www.rfc-editor.org/info/rfc5954</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6263">[RFC6263]</dt>
      <dd>
<span class="refAuthor">Marjou, X.</span> and <span class="refAuthor">A. Sollaud</span>, <span class="refTitle">"Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows"</span>, <span class="seriesInfo">RFC 6263</span>, <span class="seriesInfo">DOI 10.17487/RFC6263</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6263">https://www.rfc-editor.org/info/rfc6263</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6351">[RFC6351]</dt>
      <dd>
<span class="refAuthor">Perreault, S.</span>, <span class="refTitle">"xCard: vCard XML Representation"</span>, <span class="seriesInfo">RFC 6351</span>, <span class="seriesInfo">DOI 10.17487/RFC6351</span>, <time datetime="2011-08" class="refDate">August 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6351">https://www.rfc-editor.org/info/rfc6351</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6352">[RFC6352]</dt>
      <dd>
<span class="refAuthor">Daboo, C.</span>, <span class="refTitle">"CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)"</span>, <span class="seriesInfo">RFC 6352</span>, <span class="seriesInfo">DOI 10.17487/RFC6352</span>, <time datetime="2011-08" class="refDate">August 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6352">https://www.rfc-editor.org/info/rfc6352</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6442">[RFC6442]</dt>
      <dd>
<span class="refAuthor">Polk, J.</span>, <span class="refAuthor">Rosen, B.</span>, and <span class="refAuthor">J. Peterson</span>, <span class="refTitle">"Location Conveyance for the Session Initiation Protocol"</span>, <span class="seriesInfo">RFC 6442</span>, <span class="seriesInfo">DOI 10.17487/RFC6442</span>, <time datetime="2011-12" class="refDate">December 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6442">https://www.rfc-editor.org/info/rfc6442</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6665">[RFC6665]</dt>
      <dd>
<span class="refAuthor">Roach, A.B.</span>, <span class="refTitle">"SIP-Specific Event Notification"</span>, <span class="seriesInfo">RFC 6665</span>, <span class="seriesInfo">DOI 10.17487/RFC6665</span>, <time datetime="2012-07" class="refDate">July 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6665">https://www.rfc-editor.org/info/rfc6665</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6764">[RFC6764]</dt>
      <dd>
<span class="refAuthor">Daboo, C.</span>, <span class="refTitle">"Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)"</span>, <span class="seriesInfo">RFC 6764</span>, <span class="seriesInfo">DOI 10.17487/RFC6764</span>, <time datetime="2013-02" class="refDate">February 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6764">https://www.rfc-editor.org/info/rfc6764</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6881">[RFC6881]</dt>
      <dd>
<span class="refAuthor">Rosen, B.</span> and <span class="refAuthor">J. Polk</span>, <span class="refTitle">"Best Current Practice for Communications Services in Support of Emergency Calling"</span>, <span class="seriesInfo">BCP 181</span>, <span class="seriesInfo">RFC 6881</span>, <span class="seriesInfo">DOI 10.17487/RFC6881</span>, <time datetime="2013-03" class="refDate">March 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6881">https://www.rfc-editor.org/info/rfc6881</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7525">[RFC7525]</dt>
      <dd>
<span class="refAuthor">Sheffer, Y.</span>, <span class="refAuthor">Holz, R.</span>, and <span class="refAuthor">P. Saint-Andre</span>, <span class="refTitle">"Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">BCP 195</span>, <span class="seriesInfo">RFC 7525</span>, <span class="seriesInfo">DOI 10.17487/RFC7525</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7525">https://www.rfc-editor.org/info/rfc7525</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7647">[RFC7647]</dt>
      <dd>
<span class="refAuthor">Sparks, R.</span> and <span class="refAuthor">A.B. Roach</span>, <span class="refTitle">"Clarifications for the Use of REFER with RFC 6665"</span>, <span class="seriesInfo">RFC 7647</span>, <span class="seriesInfo">DOI 10.17487/RFC7647</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7647">https://www.rfc-editor.org/info/rfc7647</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7742">[RFC7742]</dt>
      <dd>
<span class="refAuthor">Roach, A.B.</span>, <span class="refTitle">"WebRTC Video Processing and Codec Requirements"</span>, <span class="seriesInfo">RFC 7742</span>, <span class="seriesInfo">DOI 10.17487/RFC7742</span>, <time datetime="2016-03" class="refDate">March 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7742">https://www.rfc-editor.org/info/rfc7742</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7852">[RFC7852]</dt>
      <dd>
<span class="refAuthor">Gellens, R.</span>, <span class="refAuthor">Rosen, B.</span>, <span class="refAuthor">Tschofenig, H.</span>, <span class="refAuthor">Marshall, R.</span>, and <span class="refAuthor">J. Winterbottom</span>, <span class="refTitle">"Additional Data Related to an Emergency Call"</span>, <span class="seriesInfo">RFC 7852</span>, <span class="seriesInfo">DOI 10.17487/RFC7852</span>, <time datetime="2016-07" class="refDate">July 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7852">https://www.rfc-editor.org/info/rfc7852</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7874">[RFC7874]</dt>
      <dd>
<span class="refAuthor">Valin, JM.</span> and <span class="refAuthor">C. Bran</span>, <span class="refTitle">"WebRTC Audio Codec and Processing Requirements"</span>, <span class="seriesInfo">RFC 7874</span>, <span class="seriesInfo">DOI 10.17487/RFC7874</span>, <time datetime="2016-05" class="refDate">May 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7874">https://www.rfc-editor.org/info/rfc7874</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="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>, and <span class="refAuthor">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="RFC8446">[RFC8446]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8599">[RFC8599]</dt>
      <dd>
<span class="refAuthor">Holmberg, C.</span> and <span class="refAuthor">M. Arnold</span>, <span class="refTitle">"Push Notification with the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 8599</span>, <span class="seriesInfo">DOI 10.17487/RFC8599</span>, <time datetime="2019-05" class="refDate">May 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8599">https://www.rfc-editor.org/info/rfc8599</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8760">[RFC8760]</dt>
      <dd>
<span class="refAuthor">Shekh-Yusef, R.</span>, <span class="refTitle">"The Session Initiation Protocol (SIP) Digest Access Authentication Scheme"</span>, <span class="seriesInfo">RFC 8760</span>, <span class="seriesInfo">DOI 10.17487/RFC8760</span>, <time datetime="2020-03" class="refDate">March 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8760">https://www.rfc-editor.org/info/rfc8760</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8825">[RFC8825]</dt>
      <dd>
<span class="refAuthor">Alvestrand, H.</span>, <span class="refTitle">"Overview: Real-Time Protocols for Browser-Based Applications"</span>, <span class="seriesInfo">RFC 8825</span>, <span class="seriesInfo">DOI 10.17487/RFC8825</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8825">https://www.rfc-editor.org/info/rfc8825</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8827">[RFC8827]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"WebRTC Security Architecture"</span>, <span class="seriesInfo">RFC 8827</span>, <span class="seriesInfo">DOI 10.17487/RFC8827</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8827">https://www.rfc-editor.org/info/rfc8827</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8829">[RFC8829]</dt>
      <dd>
<span class="refAuthor">Uberti, J.</span>, <span class="refAuthor">Jennings, C.</span>, and <span class="refAuthor">E. Rescorla, Ed.</span>, <span class="refTitle">"JavaScript Session Establishment Protocol (JSEP)"</span>, <span class="seriesInfo">RFC 8829</span>, <span class="seriesInfo">DOI 10.17487/RFC8829</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8829">https://www.rfc-editor.org/info/rfc8829</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8834">[RFC8834]</dt>
      <dd>
<span class="refAuthor">Perkins, C.</span>, <span class="refAuthor">Westerlund, M.</span>, and <span class="refAuthor">J. Ott</span>, <span class="refTitle">"Media Transport and Use of RTP in WebRTC"</span>, <span class="seriesInfo">RFC 8834</span>, <span class="seriesInfo">DOI 10.17487/RFC8834</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8834">https://www.rfc-editor.org/info/rfc8834</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8835">[RFC8835]</dt>
      <dd>
<span class="refAuthor">Alvestrand, H.</span>, <span class="refTitle">"Transports for WebRTC"</span>, <span class="seriesInfo">RFC 8835</span>, <span class="seriesInfo">DOI 10.17487/RFC8835</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8835">https://www.rfc-editor.org/info/rfc8835</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>, and <span class="refAuthor">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="RFC8865">[RFC8865]</dt>
      <dd>
<span class="refAuthor">Holmberg, C.</span> and <span class="refAuthor">G. Hellström</span>, <span class="refTitle">"T.140 Real-Time Text Conversation over WebRTC Data Channels"</span>, <span class="seriesInfo">RFC 8865</span>, <span class="seriesInfo">DOI 10.17487/RFC8865</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8865">https://www.rfc-editor.org/info/rfc8865</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8866">[RFC8866]</dt>
      <dd>
<span class="refAuthor">Begen, A.</span>, <span class="refAuthor">Kyzivat, P.</span>, <span class="refAuthor">Perkins, C.</span>, and <span class="refAuthor">M. Handley</span>, <span class="refTitle">"SDP: Session Description Protocol"</span>, <span class="seriesInfo">RFC 8866</span>, <span class="seriesInfo">DOI 10.17487/RFC8866</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8866">https://www.rfc-editor.org/info/rfc8866</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9071">[RFC9071]</dt>
      <dd>
<span class="refAuthor">Hellström, G.</span>, <span class="refTitle">"RTP-Mixer Formatting of Multiparty Real-Time Text"</span>, <span class="seriesInfo">RFC 9071</span>, <span class="seriesInfo">DOI 10.17487/RFC9071</span>, <time datetime="2021-07" class="refDate">July 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9071">https://www.rfc-editor.org/info/rfc9071</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9110">[RFC9110]</dt>
      <dd>
<span class="refAuthor">Fielding, R., Ed.</span>, <span class="refAuthor">Nottingham, M., Ed.</span>, and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"HTTP Semantics"</span>, <span class="seriesInfo">STD 97</span>, <span class="seriesInfo">RFC 9110</span>, <span class="seriesInfo">DOI 10.17487/RFC9110</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9110">https://www.rfc-editor.org/info/rfc9110</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9112">[RFC9112]</dt>
    <dd>
<span class="refAuthor">Fielding, R., Ed.</span>, <span class="refAuthor">Nottingham, M., Ed.</span>, and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"HTTP/1.1"</span>, <span class="seriesInfo">STD 99</span>, <span class="seriesInfo">RFC 9112</span>, <span class="seriesInfo">DOI 10.17487/RFC9112</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9112">https://www.rfc-editor.org/info/rfc9112</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-13">
      <h2 id="name-informative-references">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
      </h2>
<dl class="references">
<dt id="RFC3665">[RFC3665]</dt>
      <dd>
<span class="refAuthor">Johnston, A.</span>, <span class="refAuthor">Donovan, S.</span>, <span class="refAuthor">Sparks, R.</span>, <span class="refAuthor">Cunningham, C.</span>, and <span class="refAuthor">K. Summers</span>, <span class="refTitle">"Session Initiation Protocol (SIP) Basic Call Flow Examples"</span>, <span class="seriesInfo">BCP 75</span>, <span class="seriesInfo">RFC 3665</span>, <span class="seriesInfo">DOI 10.17487/RFC3665</span>, <time datetime="2003-12" class="refDate">December 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3665">https://www.rfc-editor.org/info/rfc3665</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
    <dd>
<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<div id="Acknowledgements">
<section id="appendix-A">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-A-1"><span class="contact-name">Brett Henderson</span> and <span class="contact-name">Jim Malloy</span> provided many helpful edits to prior draft versions of this document.  <span class="contact-name">Paul Kyzivat</span> provided extensive reviews and comments.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-B">
      <h2 id="name-authors-address">
<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Brian Rosen</span></div>
<div dir="auto" class="left"><span class="street-address">470 Conrad Dr</span></div>
<div dir="auto" class="left">
<span class="locality">Mars</span>, <span class="region">PA</span> <span class="postal-code">16046</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:br@brianrosen.net" class="email">br@brianrosen.net</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>