File: rfc8688.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 (2409 lines) | stat: -rw-r--r-- 116,879 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8688: A Session Initiation Protocol (SIP) Response Code for Rejected Calls</title>
<meta content="Eric W. Burger" name="author">
<meta content="Bhavik Nagda" name="author">
<meta content="
       This document defines the 608 (Rejected) Session Initiation Protocol
      (SIP) response code. This response code enables calling parties to learn
      that an intermediary rejected their call attempt. No one will deliver,
      and thus answer, the call. As a 6xx code, the caller will be aware that
      future attempts to contact the same User Agent Server will likely fail.
      The initial use case driving the need for the 608 response code is when
      the intermediary is an analytics engine. In this case, the rejection is
      by a machine or other process. This contrasts with the 607 (Unwanted)
      SIP response code in which a human at the target User Agent Server
      indicates the user did not want the call. In some jurisdictions, this
      distinction is important. This document also defines the use of the
      Call-Info header field in 608 responses to enable rejected callers to
      contact entities that blocked their calls in error. This provides a
      remediation mechanism for legal callers that find their calls
      blocked. 
    " name="description">
<meta content="xml2rfc 2.35.0" name="generator">
<meta content="STIR" name="keyword">
<meta content="SIPCORE" name="keyword">
<meta content="IANA" name="keyword">
<meta content="8688" name="rfc.number">
<link href="rfc8688.xml" type="application/rfc+xml" rel="alternate">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* 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: 0 0 0.25em 0;
  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;
}
/* 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 {
  .sourcecode {
    margin-bottom: 1em;
  }
}</style>
<link href="rfc-local.css" type="text/css" rel="stylesheet">
<link href="https://dx.doi.org/10.17487/rfc8688" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected-09" 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 8688</td>
<td class="center">SIP Response Code for Rejected Calls</td>
<td class="right">December 2019</td>
</tr></thead>
<tfoot><tr>
<td class="left">Burger &amp; Nagda</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/rfc8688" class="eref">8688</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="2019-12" class="published">December 2019</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">E.W. Burger</div>
<div class="org">Georgetown University</div>
</div>
<div class="author">
      <div class="author-name">B. Nagda</div>
<div class="org">Massachusetts Institute of Technology</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8688</h1>
<h1 id="title">A Session Initiation Protocol (SIP) Response Code for Rejected Calls</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document defines the 608 (Rejected) Session Initiation Protocol
      (SIP) response code. This response code enables calling parties to learn
      that an intermediary rejected their call attempt. No one will deliver,
      and thus answer, the call. As a 6xx code, the caller will be aware that
      future attempts to contact the same User Agent Server will likely fail.
      The initial use case driving the need for the 608 response code is when
      the intermediary is an analytics engine. In this case, the rejection is
      by a machine or other process. This contrasts with the 607 (Unwanted)
      SIP response code in which a human at the target User Agent Server
      indicates the user did not want the call. In some jurisdictions, this
      distinction is important. This document also defines the use of the
      Call-Info header field in 608 responses to enable rejected callers to
      contact entities that blocked their calls in error. This provides a
      remediation mechanism for legal callers that find their calls
      blocked.<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/rfc8688">https://www.rfc-editor.org/info/rfc8688</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) 2019 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-protocol-operation" class="xref">Protocol Operation</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-intermediary-operation" class="xref">Intermediary Operation</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-jws-construction" class="xref">JWS Construction</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.3.2.2.2.1">
                    <p id="section-toc.1-1.3.2.2.2.1.1"><a href="#section-3.2.1" class="xref">3.2.1</a>.  <a href="#name-jose-header" class="xref">JOSE Header</a><a href="#section-toc.1-1.3.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.3.2.2.2.2">
                    <p id="section-toc.1-1.3.2.2.2.2.1"><a href="#section-3.2.2" class="xref">3.2.2</a>.  <a href="#name-jwt-payload" class="xref">JWT Payload</a><a href="#section-toc.1-1.3.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.3.2.2.2.3">
                    <p id="section-toc.1-1.3.2.2.2.3.1"><a href="#section-3.2.3" class="xref">3.2.3</a>.  <a href="#name-jws-signature" class="xref">JWS Signature</a><a href="#section-toc.1-1.3.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-uac-operation" class="xref">UAC Operation</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-legacy-interoperation" class="xref">Legacy Interoperation</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-announcement-requirements" class="xref">Announcement Requirements</a><a href="#section-toc.1-1.3.2.5.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-examples" class="xref">Examples</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-full-exchange" class="xref">Full Exchange</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-web-site-jcard" class="xref">Web Site jCard</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-multi-modal-jcard" class="xref">Multi-modal jCard</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-legacy-interoperability" class="xref">Legacy Interoperability</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-sip-response-code" class="xref">SIP Response Code</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-sip-feature-capability-indi" class="xref">SIP Feature-Capability Indicator</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-json-web-token-claim" class="xref">JSON Web Token Claim</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc 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-call-info-purpose" class="xref">Call-Info Purpose</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc 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-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc 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-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">The IETF has been addressing numerous issues surrounding how to
      handle unwanted and, depending on the jurisdiction, illegal calls <span>[<a href="#RFC5039" class="xref">RFC5039</a>]</span>. Secure Telephone Identity Revisited
      (STIR) <span>[<a href="#RFC7340" class="xref">RFC7340</a>]</span> and Signature-based
      Handling of Asserted information using toKENs (SHAKEN) <span>[<a href="#SHAKEN" class="xref">SHAKEN</a>]</span> address the cryptographic signing and
      attestation, respectively, of signaling to ensure the integrity and
      authenticity of the asserted caller identity.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">This document describes a new <span><a href="#RFC3261" class="xref">Session Initiation Protocol (SIP)</a> [<a href="#RFC3261" class="xref">RFC3261</a>]</span> response code,
      608, which allows calling parties to learn that an intermediary rejected
      their call. As described below, we need a distinct indicator to
      differentiate between a user rejection and an intermediary's rejection
      of a call. In some jurisdictions, service providers may not be permitted
      to block calls, even if unwanted by the user, unless there is an
      explicit user request. Moreover, users may misidentify the nature of a
      caller.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">For example, a legitimate caller may call a user who finds the call
      to be unwanted. However, instead of marking the call as unwanted, the
      user may mark the call as illegal. With that information, an analytics
      engine may determine to block all calls from that source. However, in
      some jurisdictions, blocking calls from that source for other users may
      not be legal. Likewise, one can envision jurisdictions that allow an
      operator to block such calls, but only if there is a remediation
      mechanism in place to address false positives.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">Some call-blocking services may return responses such as 604 (Does
      Not Exist Anywhere). This might be a strategy to try to get a
      destination's address removed from a calling database. However, other
      network elements might also interpret this to mean the user truly does
      not exist, which might result in the user not being able to receive
      calls from anyone, even if they wanted to receive the calls. In many
      jurisdictions, providing such false signaling is also illegal.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">The 608 response code addresses this need of remediating falsely
      blocked calls. Specifically, this code informs the SIP User Agent Client
      (UAC) that an intermediary blocked the call and provides a redress
      mechanism that allows callers to contact the operator of the
      intermediary.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">In the current call handling ecosystem, users can explicitly reject a
      call or later mark a call as being unwanted by issuing a <span><a href="#RFC8197" class="xref">607 SIP response code
      (Unwanted)</a> [<a href="#RFC8197" class="xref">RFC8197</a>]</span>. Figures <a href="#uas_reject" class="xref">1</a>
      and <a href="#reject_ladder" class="xref">2</a> show the operation
      of the 607 SIP response code. The User Agent Server (UAS) indicates the
      call was unwanted. As <span>[<a href="#RFC8197" class="xref">RFC8197</a>]</span>
      explains, not only does the called party desire to reject that call,
      they can let their proxy know that they consider future calls from that
      source unwanted. Upon receipt of the 607 response from the UAS, the
      proxy may send unwanted call indicators, such as the value of the From
      header field and other information elements, to a call analytics engine.
      For various reasons described in <span>[<a href="#RFC8197" class="xref">RFC8197</a>]</span>, if a network operator receives multiple reports of
      unwanted calls, that may indicate that the entity placing the calls is
      likely to be a source of unwanted calls for many people. As such, other
      customers of the service provider may want the service provider to
      automatically reject calls on their behalf.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">There is another value of the 607 rejection code. Presuming the proxy
      forwards the response code to the UAC, the calling UAC or intervening
      proxies will also learn the user is not interested in receiving calls
      from that sender.<a href="#section-1-7" class="pilcrow">¶</a></p>
<span id="name-unwanted-607-call-flow"></span><div id="uas_reject">
<figure id="figure-1">
        <div class="artwork art-text alignCenter art-ascii-art" id="section-1-8.1">
<pre>
                   +-----------+
                   |   Call    |
                   | Analytics |
                   |  Engine   |
                   +-----------+
                      ^     | (likely not SIP)
                      |     v
                   +-----------+
+-----+    607     |  Called   |    607    +-----+
| UAC | &lt;--------- |  Party    | &lt;-------- | UAS |
+-----+            |  Proxy    |           +-----+
                   +-----------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-unwanted-607-call-flow" class="selfRef">Unwanted (607) Call Flow</a>
        </figcaption></figure>
</div>
<p id="section-1-9">For calls rejected with a 607 from a legitimate caller, receiving a
      607 response code can inform the caller to stop attempting to call the
      user. Moreover, if a legitimate caller believes the user is rejecting
      their calls in error, they can use other channels to contact the user.
      For example, if a pharmacy calls a user to let them know their
      prescription is available for pickup and the user mistakenly thinks the
      call is unwanted and issues a 607 response code, the pharmacy, having an
      existing relationship with the customer, can send the user an email or
      push a note to the pharmacist to ask the customer to consider not
      rejecting their calls in the future.<a href="#section-1-9" class="pilcrow">¶</a></p>
<p id="section-1-10">Many systems that allow the user to mark the call unwanted (e.g.,
      with the 607 response code) also allow the user to change their mind and
      unmark such calls. This mechanism is relatively easy to implement as the
      user usually has a direct relationship with the service provider that is
      blocking calls.<a href="#section-1-10" class="pilcrow">¶</a></p>
<p id="section-1-11">However, things become more complicated if an intermediary, such as a
      third-party provider of call management services that classifies calls
      based on the relative likelihood that the call is unwanted,
      misidentifies the call as unwanted. <a href="#cae_reject" class="xref">Figure 3</a> shows this case. Note that the UAS typically does
      not receive an INVITE since the called party proxy rejects the call on
      behalf of the user. In this situation, it would be beneficial for the
      caller to learn who rejected the call so they can correct the
      misidentification.<a href="#section-1-11" class="pilcrow">¶</a></p>
<span id="name-unwanted-607-ladder-diagram"></span><div id="reject_ladder">
<figure id="figure-2">
        <div class="artwork art-text alignCenter art-call-flow" id="section-1-12.1">
<pre>
                 +--------+         +-----------+
                 | Called |         |   Call    |
+-----+          | Party  |         | Analytics |   +-----+
| UAC |          | Proxy  |         |  Engine   |   | UAS |
+-----+          +--------+         +-----------+   +-----+
   |  INVITE         |                    |            |
   | --------------&gt; |  Is call OK?       |            |
   |                 |-------------------&gt;|            |
   |                 |                    |            |
   |                 |               Yes  |            |
   |                 |&lt;-------------------|            |
   |                 |                    |            |
   |                 | INVITE             |            |
   |                 | ------------------------------&gt; |
   |                 |                    |            |
   |                 |                    |       607  |
   |                 | &lt;------------------------------ |
   |                 |                    |            |
   |                 |  Unwanted call     |            |
   |            607  | -----------------&gt; |            |
   | &lt;-------------- |  indicators        |            |
   |                 |                    |            |
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-unwanted-607-ladder-diagram" class="selfRef">Unwanted (607) Ladder Diagram</a>
        </figcaption></figure>
</div>
<span id="name-rejected-608-call-flow"></span><div id="cae_reject">
<figure id="figure-3">
        <div class="artwork art-text alignCenter art-ascii-art" id="section-1-13.1">
<pre>
                      +-----------+
                      |   Call    |
                      | Analytics |
                      |  Engine   |
                      +-----------+
                         ^     | (likely not SIP)
                         |     v
                      +-----------+
   +-----+    608     |  Called   |           +-----+
   | UAC | &lt;--------- |  Party    |           | UAS |
   +-----+            |  Proxy    |           +-----+
                      +-----------+
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-rejected-608-call-flow" class="selfRef">Rejected (608) Call Flow</a>
        </figcaption></figure>
</div>
<p id="section-1-14">In this situation, one might consider having the intermediary use the
      607 response code. 607 indicates to the caller that the subscriber does
      not want the call. However, <span>[<a href="#RFC8197" class="xref">RFC8197</a>]</span>
      specifies that one of the uses of 607 is to inform analytics engines
      that a user (human) has rejected a call. The problem here is that
      network elements downstream from the intermediary might interpret the
      607 as coming from a user (human) who has marked the call as unwanted,
      as opposed to coming from an algorithm using statistics or machine
      learning to reject the call. An algorithm can be vulnerable to the
      base-rate fallacy <span>[<a href="#BaseRate" class="xref">BaseRate</a>]</span> rejecting
      the call. In other words, those downstream entities should not rely on
      another entity "deciding" the call is unwanted. By distinguishing
      between a (human) user rejection and an intermediary engine's
      statistical rejection, a downstream network element that sees a 607
      response code can weigh it as a human rejection in its call analytics,
      versus deciding whether to consider a 608 at all, and if so, weighing it
      appropriately.<a href="#section-1-14" class="pilcrow">¶</a></p>
<p id="section-1-15">It is useful for blocked callers to have a redress mechanism. One can
      imagine that some jurisdictions will require it. However, we must be
      mindful that most of the calls that intermediaries block will, in fact,
      be illegal and eligible for blocking. Thus, providing alternate contact
      information for a user would be counterproductive to protecting that
      user from illegal communications. This is another reason we do not
      propose to simply allow alternate contact information in a 607 response
      message.<a href="#section-1-15" class="pilcrow">¶</a></p>
<p id="section-1-16">Why do we not use the same mechanism an analytics service provider
      offers their customers? Specifically, why not have the analytics service
      provider allow the called party to correct a call blocked in error? The
      reason is that while there is an existing relationship between the
      customer (called party) and the analytics service provider, it is
      unlikely there is a relationship between the caller and the analytics
      service provider. Moreover, there are numerous call blocking providers
      in the ecosystem. Therefore, we need a mechanism for indicating an
      intermediary rejected a call that also provides contact information for
      the operator of that intermediary without exposing the target user's
      contact information.<a href="#section-1-16" class="pilcrow">¶</a></p>
<p id="section-1-17">The protocol described in this document uses existing SIP protocol
      mechanisms for specifying the redress mechanism. In the Call-Info header
      field passed back to the UAC, we send additional information specifying
      a redress address. We choose to encode the redress address using <span><a href="#RFC7095" class="xref">jCard</a> [<a href="#RFC7095" class="xref">RFC7095</a>]</span>. As we will see later in
      this document, this information needs to have its own application-layer
      integrity protection. Thus, we use jCard rather than <span><a href="#RFC6350" class="xref">vCard</a> [<a href="#RFC6350" class="xref">RFC6350</a>]</span>, as we have a marshaling
      mechanism for creating a JavaScript Object Notation <span><a href="#RFC8259" class="xref">(JSON)</a> [<a href="#RFC8259" class="xref">RFC8259</a>]</span> object, such as a jCard,
      and a standard integrity format for such an object, namely, JSON Web
      Signature <span><a href="#RFC7515" class="xref">(JWS)</a> [<a href="#RFC7515" class="xref">RFC7515</a>]</span>. The SIP
      community is familiar with this concept as it is the mechanism used by
      <span><a href="#RFC8224" class="xref">STIR</a> [<a href="#RFC8224" class="xref">RFC8224</a>]</span>.<a href="#section-1-17" class="pilcrow">¶</a></p>
<p id="section-1-18">Integrity protecting the jCard with a cryptographic signature might
      seem unnecessary at first, but it is essential to preventing potential
      network attacks. <a href="#Security" class="xref">Section 6</a> describes
      the attack and why we sign the jCard in more detail.<a href="#section-1-18" class="pilcrow">¶</a></p>
</section>
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1"> The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
      "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
      "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
      "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are
      to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span>
        <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all
      capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-3">
      <h2 id="name-protocol-operation">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-protocol-operation" class="section-name selfRef">Protocol Operation</a>
      </h2>
<p id="section-3-1">This section uses the term "intermediary" to mean the entity that
      acts as a SIP UAS on behalf of the user in the network as opposed to the
      user's UAS (usually, but not necessarily, their phone). The intermediary
      could be a back-to-back user agent (B2BUA) or a SIP Proxy.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2"><a href="#cae_ladder" class="xref">Figure 4</a> shows an overview of the
      call flow for a rejected call.<a href="#section-3-2" class="pilcrow">¶</a></p>
<span id="name-rejected-608-ladder-diagram"></span><div id="cae_ladder">
<figure id="figure-4">
        <div class="artwork art-text alignCenter art-call-flow" id="section-3-3.1">
<pre>
                  +--------+         +-----------+
                  | Called |         |   Call    |
 +-----+          | Party  |         | Analytics |   +-----+
 | UAC |          | Proxy  |         |  Engine   |   | UAS |
 +-----+          +--------+         +-----------+   +-----+
    |  INVITE         |                    |            |
    | --------------&gt; |  Is call OK?       |            |
    |                 |-------------------&gt;|            |
    |                 |                    |            |
    |                 |               Yes  |            |
    |                 |&lt;-------------------|            |
    |                 |                    |            |
    |                 | INVITE             |            |
    |                 | ------------------------------&gt; |
    |                 |                    |            |
    |                 |                    |       607  |
    |                 | &lt;------------------------------ |
    |                 |                    |            |
    |                 |  Unwanted call     |            |
    |            607  | -----------------&gt; |            |
    | &lt;-------------- |  indicators        |            |
    |                 |                    |            |
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-rejected-608-ladder-diagram" class="selfRef">Rejected (608) Ladder Diagram</a>
        </figcaption></figure>
</div>
<section id="section-3.1">
        <h3 id="name-intermediary-operation">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-intermediary-operation" class="section-name selfRef">Intermediary Operation</a>
        </h3>
<p id="section-3.1-1">An intermediary <span class="bcp14">MAY</span> issue the 608 response code in a
        failure response for an INVITE, MESSAGE, SUBSCRIBE, or other
        out-of-dialog <span><a href="#RFC3261" class="xref">SIP</a> [<a href="#RFC3261" class="xref">RFC3261</a>]</span>
        request to indicate that an intermediary rejected the offered
        communication as unwanted by the user. An intermediary
        <span class="bcp14">MAY</span> issue the 608 as the value of the "cause" parameter
        of a SIP reason-value in a Reason header field <span>[<a href="#RFC3326" class="xref">RFC3326</a>]</span>.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">If an intermediary issues a 608 code and there are no indicators
        the calling party will use the contents of the Call-Info header field
        for malicious purposes (see <a href="#Security" class="xref">Section 6</a>), the intermediary <span class="bcp14">MUST</span> include a
        Call-Info header field in the response.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">If there is a Call-Info header field, it <span class="bcp14">MUST</span> have
        the "purpose" parameter of "jwscard". The value of the Call-Info
        header field <span class="bcp14">MUST</span> refer to a valid JSON Web Signature
        (JWS) <span>[<a href="#RFC7515" class="xref">RFC7515</a>]</span> encoding of a <span><a href="#RFC7095" class="xref">jCard</a> [<a href="#RFC7095" class="xref">RFC7095</a>]</span> object. The following
        section describes the construction of the JWS.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">Proxies need to be mindful that a downstream intermediary may
        reject the attempt with a 608 while other paths may still be in
        progress. In this situation, the requirements stated in <span><a href="https://www.rfc-editor.org/rfc/rfc3261#section-16.7" class="relref">Section 16.7</a> of [<a href="#RFC3261" class="xref">RFC3261</a>]</span> apply.
        Specifically, the proxy should cancel pending transactions and must
        not create any new branches. Note this is not a new requirement but
        simply pointing out the existing 6xx protocol mechanism in SIP.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
</section>
<section id="section-3.2">
        <h3 id="name-jws-construction">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-jws-construction" class="section-name selfRef">JWS Construction</a>
        </h3>
<p id="section-3.2-1">The intermediary constructs the JWS of the jCard as follows.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<section id="section-3.2.1">
          <h4 id="name-jose-header">
<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-jose-header" class="section-name selfRef">JOSE Header</a>
          </h4>
<p id="section-3.2.1-1">The Javascript Object Signing and Encryption (JOSE) header
          <span class="bcp14">MUST</span> include the typ, alg, and x5u parameters from
          <span><a href="#RFC7515" class="xref">JWS</a> [<a href="#RFC7515" class="xref">RFC7515</a>]</span>. The typ
          parameter <span class="bcp14">MUST</span> have the value "vcard+json".
          Implementations <span class="bcp14">MUST</span> support ES256 as JSON Web
          Algorithms (JWA) <span>[<a href="#RFC7518" class="xref">RFC7518</a>]</span> defines
          it and <span class="bcp14">MAY</span> support other registered signature
          algorithms. Finally, the x5u parameter <span class="bcp14">MUST</span> be a URI
          that resolves to the public key certificate corresponding to the key
          used to digitally sign the JWS.<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
</section>
<div id="JWT">
<section id="section-3.2.2">
          <h4 id="name-jwt-payload">
<a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-jwt-payload" class="section-name selfRef">JWT Payload</a>
          </h4>
<p id="section-3.2.2-1">The payload contains two JSON values. The first JSON Web Token
          (JWT) claim that <span class="bcp14">MUST</span> be present is the <span><a href="#RFC7519" class="xref">"iat" (issued at) claim</a> [<a href="#RFC7519" class="xref">RFC7519</a>]</span>.
          The "iat" <span class="bcp14">MUST</span> be set to the date and time of the
          issuance of the 608 response. This mandatory component protects the
          response from replay attacks.<a href="#section-3.2.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2.2-2">The second JWT claim that <span class="bcp14">MUST</span> be present is the
          "jcard" claim. The value of the <span><a href="#RFC7095" class="xref">jcard</a> [<a href="#RFC7095" class="xref">RFC7095</a>]</span> claim is a JSON array conforming to
          the JSON jCard data format defined in <span>[<a href="#RFC7095" class="xref">RFC7095</a>]</span>. <a href="#JWT-IANA" class="xref">Section 5.3</a> describes the registration. In
          the construction of the jcard claim, the "jcard" <span class="bcp14">MUST</span>
          include at least one of the URL, EMAIL, TEL, or ADR properties. UACs
          supporting this specification <span class="bcp14">MUST</span> be prepared to
          receive a full jCard. Call originators (at the UAC) can use the
          information returned by the jCard to contact the intermediary that
          rejected the call to appeal the intermediary's blocking of the call
          attempt. What the intermediary does if the blocked caller contacts
          the intermediary is outside the scope of this document.<a href="#section-3.2.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s.JWS">
<section id="section-3.2.3">
          <h4 id="name-jws-signature">
<a href="#section-3.2.3" class="section-number selfRef">3.2.3. </a><a href="#name-jws-signature" class="section-name selfRef">JWS Signature</a>
          </h4>
<p id="section-3.2.3-1"><span><a href="#RFC7515" class="xref">JWS</a> [<a href="#RFC7515" class="xref">RFC7515</a>]</span> specifies the
          procedure for calculating the signature over the jCard JWT. <a href="#EXAMPLES" class="xref">Section 4</a> of this document has a detailed
          example on constructing the JWS, including the signature.<a href="#section-3.2.3-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<section id="section-3.3">
        <h3 id="name-uac-operation">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-uac-operation" class="section-name selfRef">UAC Operation</a>
        </h3>
<p id="section-3.3-1">A UAC conforming to this specification <span class="bcp14">MUST</span> include
        the sip.608 feature-capability indicator in the Feature-Caps header
        field of the INVITE request.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">Upon receiving a 608 response, UACs perform normal SIP processing
        for 6xx responses.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<p id="section-3.3-3">As for the disposition of the jCard itself, the UAC
        <span class="bcp14">MUST</span> check the "iat" claim in the JWT. As noted in
        <a href="#JWT" class="xref">Section 3.2.2</a>, we are concerned about replay
        attacks. Therefore, the UAC <span class="bcp14">MUST</span> reject jCards that
        come with an expired "iat". The definition of "expired" is a matter of
        local policy. A reasonable value would be on the order of a minute due
        to clock drift and the possibility of the playing of an audio
        announcement before the delivery of the 608 response.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
</section>
<section id="section-3.4">
        <h3 id="name-legacy-interoperation">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-legacy-interoperation" class="section-name selfRef">Legacy Interoperation</a>
        </h3>
<p id="section-3.4-1">If the UAC indicates support for 608 and the intermediary issues a
        608, life is good, as the UAC will receive all the information it
        needs to remediate an erroneous block by an intermediary. However,
        what if the UAC does not understand 608? For example, how can we
        support callers from a legacy, non-SIP, public-switched network
        connecting to the SIP network via a media gateway?<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.4-2">We address this situation by having the first network element that
        conforms with this specification play an announcement. See <a href="#announcement" class="xref">Section 3.5</a> for requirements on the
        announcement. The simple rule is a network element that inserts the
        sip.608 feature capability <span class="bcp14">MUST</span> be able to convey at a
        minimum how to contact the operator of the intermediary that rejected
        the call attempt.<a href="#section-3.4-2" class="pilcrow">¶</a></p>
<p id="section-3.4-3">The degenerate case is the intermediary is the only element that
        understands the semantics of the 608 response code. Obviously, any SIP
        device will understand that a 608 response code is a 6xx error.
        However, there are no other elements in the call path that understand
        the meaning of the value of the Call-Info header field. The
        intermediary knows this is the case as the INVITE request will not
        have the sip.608 feature capability. In this case, one can consider
        the intermediary to be the element "inserting" a virtual sip.608
        feature capability. If the caveats described in Sections <a href="#announcement" class="xref">3.5</a> and <a href="#Security" class="xref">6</a> do not hold, the intermediary <span class="bcp14">MUST</span>
        play the announcement.<a href="#section-3.4-3" class="pilcrow">¶</a></p>
<p id="section-3.4-4">Now we take the case where a network element that understands the
        608 response code receives an INVITE for further processing. A network
        element conforming with this specification <span class="bcp14">MUST</span> insert
        the sip.608 feature capability per the behaviors described in <span><a href="https://www.rfc-editor.org/rfc/rfc6809#section-4.2" class="relref">Section 4.2</a> of [<a href="#RFC6809" class="xref">RFC6809</a>]</span>.<a href="#section-3.4-4" class="pilcrow">¶</a></p>
<p id="section-3.4-5">Do note that even if a network element plays an announcement
        describing the contents of the 608 response message, the network
        element <span class="bcp14">MUST</span> forward the 608 response code message as
        the final response to the INVITE.<a href="#section-3.4-5" class="pilcrow">¶</a></p>
<p id="section-3.4-6">One aspect of using a feature capability is that only the network
        elements that will either consume (UAC) or play an announcement (media
        gateway, session border controller (SBC) <span>[<a href="#RFC7092" class="xref">RFC7092</a>]</span>, or proxy) need to understand the sip.608 feature
        capability. If the other network elements conform to <span><a href="https://www.rfc-editor.org/rfc/rfc3261#section-16.6" class="relref">Section 16.6</a> of [<a href="#RFC3261" class="xref">RFC3261</a>]</span>, they will pass
        header fields such as "Feature-Caps: *;+sip.608" unmodified and
        without need for upgrade.<a href="#section-3.4-6" class="pilcrow">¶</a></p>
<p id="section-3.4-7">Because the ultimate disposition of the call attempt will be a
        600-class response, the network element conveying the announcement in
        the legacy direction <span class="bcp14">MUST</span> use the 183 Session Progress
        response to establish the media session. Because of the small chance
        the UAC is an extremely old legacy device and is using UDP, the UAC
        <span class="bcp14">MUST</span> include support for <span><a href="#RFC3262" class="xref">100rel</a> [<a href="#RFC3262" class="xref">RFC3262</a>]</span> in its INVITE, the network element
        conveying the announcement <span class="bcp14">MUST</span> Require 100rel in the
        183, and the UAC <span class="bcp14">MUST</span> issue a Provisional Response
        ACKnowledgement (PRACK) to which the network element
        <span class="bcp14">MUST</span> respond 200 OK PRACK.<a href="#section-3.4-7" class="pilcrow">¶</a></p>
</section>
<div id="announcement">
<section id="section-3.5">
        <h3 id="name-announcement-requirements">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-announcement-requirements" class="section-name selfRef">Announcement Requirements</a>
        </h3>
<p id="section-3.5-1">There are a few requirements on the element that handles the
        announcement for legacy interoperation.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<p id="section-3.5-2">As noted above, the element that inserts the sip.608 feature
        capability is responsible for conveying the information referenced by
        the Call-Info header field in the 608 response message. However, this
        specification does not mandate how to convey that information.<a href="#section-3.5-2" class="pilcrow">¶</a></p>
<p id="section-3.5-3">Let us take the case where a telecommunications service provider
        controls the element inserting the sip.608 feature capability. It
        would be reasonable to expect the service provider would play an
        announcement in the media path towards the UAC (caller). It is
        important to note the network element should be mindful of the media
        type requested by the UAC as it formulates the announcement. For
        example, it would make sense for an INVITE that only indicated audio
        codecs in the <span><a href="#RFC4566" class="xref">Session
        Description Protocol (SDP)</a> [<a href="#RFC4566" class="xref">RFC4566</a>]</span> to result in an audio announcement.
        Likewise, if the INVITE only indicated <span><a href="#RFC4103" class="xref">real-time text</a> [<a href="#RFC4103" class="xref">RFC4103</a>]</span> and the network element can
        render the information in the requested media format, the network
        element should send the information in a text format.<a href="#section-3.5-3" class="pilcrow">¶</a></p>
<p id="section-3.5-4">It is also possible for the network element inserting the sip.608
        feature capability to be under the control of the same entity that
        controls the UAC. For example, a large call center might have legacy
        UACs, but have a modern outbound calling proxy that understands the
        full semantics of the 608 response code. In this case, it is enough
        for the outbound calling proxy to digest the Call-Info information and
        handle the information digitally rather than "transcoding" the
        Call-Info information for presentation to the caller.<a href="#section-3.5-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<div id="EXAMPLES">
<section id="section-4">
      <h2 id="name-examples">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-examples" class="section-name selfRef">Examples</a>
      </h2>
<p id="section-4-1">These examples are not normative, do not include all protocol
      elements, and may have errors. Review the protocol documents for actual
      syntax and semantics of the protocol elements.<a href="#section-4-1" class="pilcrow">¶</a></p>
<section id="section-4.1">
        <h3 id="name-full-exchange">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-full-exchange" class="section-name selfRef">Full Exchange</a>
        </h3>
<p id="section-4.1-1">Given an INVITE, shamelessly taken from <span>[<a href="#SHAKEN" class="xref">SHAKEN</a>]</span>, with the line breaks in the Identity header field
        for display purposes only:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<div id="section-4.1-2">
<pre class="sourcecode">
INVITE sip:+12155550113@tel.one.example.net SIP/2.0
Max-Forwards: 69
Contact: &lt;sip:+12155550112@[2001:db8::12]:50207;rinstance=9da3088f3&gt;
To: &lt;sip:+12155550113@tel.one.example.net&gt;
From: "Alice" &lt;sip:+12155550112@tel.two.example.net&gt;;tag=614bdb40
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
P-Asserted-Identity: "Alice"&lt;sip:+12155550112@tel.two.example.net&gt;,
    &lt;tel:+12155550112&gt;
CSeq: 2 INVITE
Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO,
    MESSAGE, OPTIONS
Content-Type: application/sdp
Date: Tue, 16 Aug 2016 19:23:38 GMT
Feature-Caps: *;+sip.608
Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2V
uIiwieDV1IjoiaHR0cDovL2NlcnQuZXhhbXBsZTIubmV0L2V4YW1wbGUuY2VydCJ9.eyJ
hdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MDExMyJ9LCJpYXQiOiIxNDcx
Mzc1NDE4Iiwib3JpZyI6eyJ0biI6IisxMjE1NTU1MDExMiJ9LCJvcmlnaWQiOiIxMjNlN
DU2Ny1lODliLTEyZDMtYTQ1Ni00MjY2NTU0NDAwMCJ9.QAht_eFqQlaoVrnEV56Qly-OU
tsDGifyCcpYjWcaR661Cz1hutFH2BzIlDswTahO7ujjqsWjeoOb4h97whTQJg;info=
&lt;http://cert.example2.net/example.cert&gt;;alg=ES256
Content-Length: 153

v=0
o=- 13103070023943130 1 IN IP6 2001:db8::177
c=IN IP6 2001:db8::177
t=0 0
m=audio 54242 RTP/AVP 0
a=sendrecv
</pre><a href="#section-4.1-2" class="pilcrow">¶</a>
</div>
<p id="section-4.1-3">An intermediary could reply:<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<div id="section-4.1-4">
<pre class="sourcecode">
SIP/2.0 608 Rejected
Via: SIP/2.0/UDP [2001:db8::177]:60012;branch=z9hG4bK-524287-1
From: "Alice" &lt;sip:+12155550112@tel.two.example.net&gt;;tag=614bdb40
To: &lt;sip:+12155550113@tel.one.example.net&gt;
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
CSeq: 2 INVITE
Call-Info: &lt;https://block.example.net/complaint-jws&gt;;purpose=jwscard
</pre><a href="#section-4.1-4" class="pilcrow">¶</a>
</div>
<p id="section-4.1-5">The location https://block.example.net/complaint-jws resolves to a
        JWS. One would construct the JWS as follows.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
<p id="section-4.1-6">The JWS header of this example jCard could be:<a href="#section-4.1-6" class="pilcrow">¶</a></p>
<div id="section-4.1-7">
<pre class="sourcecode lang-json">
{ "alg":"ES256",
  "typ":"vcard+json",
  "x5u":"https://certs.example.net/reject_key.cer"
}
</pre><a href="#section-4.1-7" class="pilcrow">¶</a>
</div>
<p id="section-4.1-8">Now, let us construct a minimal jCard. For this example, the jCard
        refers the caller to an email address,
        remediation@blocker.example.net:<a href="#section-4.1-8" class="pilcrow">¶</a></p>
<div id="section-4.1-9">
<pre class="sourcecode lang-json">
["vcard",
  [
    ["version", {}, "text", "4.0"],
    ["fn", {}, "text", "Robocall Adjudication"],
    ["email", {"type":"work"}, "text", 
     "remediation@blocker.example.net"]
  ]
]
</pre><a href="#section-4.1-9" class="pilcrow">¶</a>
</div>
<p id="section-4.1-10">With this jCard, we can now construct the JWT:<a href="#section-4.1-10" class="pilcrow">¶</a></p>
<div id="section-4.1-11">
<pre class="sourcecode lang-json">{
  "iat":1546008698,
  "jcard":["vcard",
    [
      ["version", {}, "text", "4.0"],
      ["fn", {}, "text", "Robocall Adjudication"],
      ["email", {"type":"work"},
       "text", "remediation@blocker.example.net"]
    ]
  ]
} </pre><a href="#section-4.1-11" class="pilcrow">¶</a>
</div>
<p id="section-4.1-12">To calculate the signature, we need to encode the JSON Object
        Signing and Encryption (JOSE) header and JWT into base64url. As an
        implementation note, one can trim whitespace in the JSON objects to
        save a few bytes. UACs <span class="bcp14">MUST</span> be prepared to receive
        pretty-printed, compact, or bizarrely formatted JSON. For the purposes
        of this example, we leave the objects with pretty whitespace. Speaking
        of pretty vs. machine formatting, these examples have line breaks in
        the base64url encodings for ease of publication in the RFC format. The
        specification of base64url allows for these line breaks, and the
        decoded text works just fine. However, those extra line-break octets
        would affect the calculation of the signature. Implementations
        <span class="bcp14">MUST NOT</span> insert line breaks into the base64url
        encodings of the JOSE header or JWT. This also means UACs
        <span class="bcp14">MUST</span> be prepared to receive arbitrarily long octet
        streams from the URI referenced by the Call-Info header field.<a href="#section-4.1-12" class="pilcrow">¶</a></p>
<p id="section-4.1-13">base64url of JOSE header:<a href="#section-4.1-13" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft art-hex-dump" id="section-4.1-14">
<pre>
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczov
L2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0=
</pre><a href="#section-4.1-14" class="pilcrow">¶</a>
</div>
<p id="section-4.1-15">base64url of JWT:<a href="#section-4.1-15" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft art-hex-dump" id="section-4.1-16">
<pre>
eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7
fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRp
Y2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRp
YXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19
</pre><a href="#section-4.1-16" class="pilcrow">¶</a>
</div>
<p id="section-4.1-17">In this case, the object to sign (remembering this is just a single
        long line; the line breaks are for ease of review but do not appear in
        the actual object) is as follows:<a href="#section-4.1-17" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft art-hex-dump" id="section-4.1-18">
<pre>
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJk
K2pzb24iLCJ4NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9r
ZXkuY2VyIn0.eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2
ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2Nh
bGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0
IiwicmVtZWRpYXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19
</pre><a href="#section-4.1-18" class="pilcrow">¶</a>
</div>
<p id="section-4.1-19">We use the following X.509 PKCS #8-encoded Elliptic Curve Digital
        Signature Algorithm (ECDSA) key, also shamelessly taken from <span>[<a href="#SHAKEN" class="xref">SHAKEN</a>]</span>, as an example key for signing the
        hash of the above text. Do NOT use this key in real life! It is for
        example purposes only. At the very least, we would strongly recommend
        encrypting the key at rest.<a href="#section-4.1-19" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.1-20">
<pre>
-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy
qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW
ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
-----END PRIVATE KEY-----

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH
78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g==
-----END PUBLIC KEY-----
</pre><a href="#section-4.1-20" class="pilcrow">¶</a>
</div>
<p id="section-4.1-21">The resulting JWS, using the above key on the above object, renders
        the following ECDSA P-256 SHA-256 digital signature.<a href="#section-4.1-21" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.1-22">
<pre>
7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6g9AmL
5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag
</pre><a href="#section-4.1-22" class="pilcrow">¶</a>
</div>
<p id="section-4.1-23">Thus, the JWS stored at https://blocker.example.net/complaints-jws
        would contain:<a href="#section-4.1-23" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.1-24">
<pre>
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczovL
2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0.eyJpYXQiOjE1NDYwMD
g2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJ
dLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFp
bCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRpYXRpb25AYmxvY2tlci5le
GFtcGxlLm5ldCJdXV19.7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6
g9AmL5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag
</pre><a href="#section-4.1-24" class="pilcrow">¶</a>
</div>
</section>
<section id="section-4.2">
        <h3 id="name-web-site-jcard">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-web-site-jcard" class="section-name selfRef">Web Site jCard</a>
        </h3>
<p id="section-4.2-1">For an intermediary that provides a Web site for adjudication, the
        jCard could contain the following. Note that we do not show the
        calculation of the JWS; the URI reference in the Call-Info header
        field would be to the JWS of the signed jCard.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<div id="section-4.2-2">
<pre class="sourcecode lang-json">
["vcard",
  [
    ["version", {}, "text", "4.0"],
    ["fn", {}, "text", "Robocall Adjudication"],
    ["url", {"type":"work"},
     "text", "https://blocker.example.net/adjudication-form"]
  ]
] </pre><a href="#section-4.2-2" class="pilcrow">¶</a>
</div>
</section>
<section id="section-4.3">
        <h3 id="name-multi-modal-jcard">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-multi-modal-jcard" class="section-name selfRef">Multi-modal jCard</a>
        </h3>
<p id="section-4.3-1">For an intermediary that provides a telephone number and a postal
        address, the jCard could contain the following. Note that we do not
        show the calculation of the JWS; the URI reference in the Call-Info
        header field would be to the JWS of the signed jCard.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<div id="section-4.3-2">
<pre class="sourcecode lang-json">["vcard",
  [
    ["version", {}, "text", "4.0"],
    ["fn", {}, "text", "Robocall Adjudication"],
    ["adr", {"type":"work"}, "text",
      ["Argument Clinic",
       "12 Main St","Anytown","AP","000000","Somecountry"]
    ]
    ["tel", {"type":"work"}, "uri", "tel:+1-555-555-0112"]
  ]
]</pre><a href="#section-4.3-2" class="pilcrow">¶</a>
</div>
<p id="section-4.3-3">Note that it is up to the UAC to decide which jCard contact
        modality, if any, it will use.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
</section>
<section id="section-4.4">
        <h3 id="name-legacy-interoperability">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-legacy-interoperability" class="section-name selfRef">Legacy Interoperability</a>
        </h3>
<p id="section-4.4-1"><a href="#legacy_ladder" class="xref">Figure 5</a> depicts a call flow
        illustrating legacy interoperability. In this non-normative example,
        we see a UAC that does not support the full semantics for 608.
        However, there is an SBC that does support 608. Per <span>[<a href="#RFC6809" class="xref">RFC6809</a>]</span>, the SBC can insert "*;+sip.608"
        into the Feature-Caps header field for the INVITE. When the
        intermediary, labeled "Called Party Proxy" in the figure, rejects the
        call, it knows it can simply perform the processing described in this
        document. Since the intermediary saw the sip.608 feature capability,
        it knows it does not need to send any media describing whom to contact
        in the event of an erroneous rejection. For illustrative purposes, the
        figure shows generic SIP Proxies in the flow. Their presence or
        absence or the number of proxies is not relevant to the operation of
        the protocol. They are in the figure to show that proxies that do not
        understand the sip.608 feature capability can still participate in a
        network offering 608 services.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<span id="name-legacy-operation"></span><div id="legacy_ladder">
<figure id="figure-5">
          <div class="artwork art-text alignCenter art-ascii-art" id="section-4.4-2.1">
<pre>
                                                      +---------+
                                                      |  Call   |
                                                      |Analytics|
                                                      | Engine  |
                                                      +--+--+---+
                                                         ^  |
                                                         |  |
                                                         |  v
                                                       +-+--+-+
    +---+    +-----+    +---+    +-----+    +-----+    |Called|
    |UAC+----+Proxy+----+SBC+----+Proxy+----+Proxy+----+Party |
    +---+    +-----+    +---+    +-----+    +-----+    |Proxy |
      |                   |                            +------+
      | INVITE            |                               |
      |------------------&gt;|                               |
      |                   | INVITE                        |
      |                   |------------------------------&gt;|
      |                   | Feature-Caps: *;+sip.608      |
      |                   |                               |
      |                   |                  608 Rejected |
      |                   |&lt;------------------------------|
      |               183 |              Call-Info: &lt;...&gt; |
      |&lt;------------------|    [path for Call-Info elided |
      |     SDP for media |     for illustration purposes]|
      |                   |                               |
      | PRACK             |                               |
      |------------------&gt;|                               |
      |                   |                               |
      |      200 OK PRACK |                               |
      |&lt;------------------|                               |
      |                   |                               |
      |&lt;== Announcement ==|                               |
      |                   |                               |
      |      608 Rejected |                               |
      |&lt;------------------|                               |
      |  Call-Info: &lt;...&gt; |                               |
      |                   |                               |
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-legacy-operation" class="selfRef">Legacy Operation</a>
          </figcaption></figure>
</div>
<p id="section-4.4-3">When the SBC receives the 608 response code, it correlates that
        with the original INVITE from the UAC. The SBC remembers that it
        inserted the sip.608 feature capability, which means it is responsible
        for somehow alerting the UAC the call failed and disclosing whom to
        contact. At this point, the SBC can play a prompt, either natively or
        through a mechanism such as <span><a href="#RFC4240" class="xref">NETANN</a> [<a href="#RFC4240" class="xref">RFC4240</a>]</span>, that sends the relevant information in
        the appropriate media to the UAC. Since this is a potentially long
        transaction and there is a chance the UAC is using an unreliable
        transport protocol, the UAC will have indicated support for
        provisional responses, the SBC will indicate it requires a PRACK from
        the UAC in the 183 response, the UAC will provide the PRACK, and the
        SBC will acknowledge receipt of the PRACK before playing the
        announcement.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<p id="section-4.4-4">As an example, the SBC could extract the FN and TEL jCard fields
        and play something like a special information tone (see Section
        6.21.2.1 of Telcordia <span>[<a href="#SR-2275" class="xref">SR-2275</a>]</span> or Section 7 of <span><a href="#ITU.E.180.1998" class="xref">ITU-T E.180</a> [<a href="#ITU.E.180.1998" class="xref">ITU.E.180.1998</a>]</span>), followed by "Your call
        has been rejected by...", followed by a text-to-speech translation of
        the FN text, followed by "You can reach them on...", followed by a
        text-to-speech translation of the telephone number in the TEL
        field.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
<p id="section-4.4-5">Note that the SBC also still sends the full 608 response code,
        including the Call-Info header field, towards the UAC.<a href="#section-4.4-5" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<section id="section-5">
      <h2 id="name-iana-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<section id="section-5.1">
        <h3 id="name-sip-response-code">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-sip-response-code" class="section-name selfRef">SIP Response Code</a>
        </h3>
<p id="section-5.1-1">This document defines a new SIP response code, 608, in the
        "Response Codes" subregistry of the "Session Initiation Protocol (SIP)
        Parameters" registry defined in <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span>.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<dl class="dlParallel dlCompact" id="section-5.1-2">
          <dt id="section-5.1-2.1">Response code:</dt>
          <dd style="margin-left: 9.0em" id="section-5.1-2.2">608<a href="#section-5.1-2.2" class="pilcrow">¶</a>
</dd>
<dt id="section-5.1-2.3">Description:</dt>
          <dd style="margin-left: 9.0em" id="section-5.1-2.4">Rejected<a href="#section-5.1-2.4" class="pilcrow">¶</a>
</dd>
<dt id="section-5.1-2.5">Reference:</dt>
          <dd style="margin-left: 9.0em" id="section-5.1-2.6">RFC 8688<a href="#section-5.1-2.6" class="pilcrow">¶</a>
</dd>
</dl>
</section>
<section id="section-5.2">
        <h3 id="name-sip-feature-capability-indi">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-sip-feature-capability-indi" class="section-name selfRef">SIP Feature-Capability Indicator</a>
        </h3>
<p id="section-5.2-1">This document defines the feature capability, sip.608, in the "SIP
        Feature-Capability Indicator Registration Tree" registry defined in
        <span>[<a href="#RFC6809" class="xref">RFC6809</a>]</span>.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<dl class="dlParallel dlCompact" id="section-5.2-2">
          <dt id="section-5.2-2.1">Name:</dt>
          <dd style="margin-left: 7.0em" id="section-5.2-2.2">sip.608<a href="#section-5.2-2.2" class="pilcrow">¶</a>
</dd>
<dt id="section-5.2-2.3">Description:</dt>
          <dd style="margin-left: 7.0em" id="section-5.2-2.4">This feature-capability indicator, when included in a
          Feature-Caps header field of an INVITE request, indicates that the
          entity associated with the indicator will be responsible for
          indicating to the caller any information contained in the 608 SIP
          response code, specifically, the value referenced by the Call-Info
          header field.<a href="#section-5.2-2.4" class="pilcrow">¶</a>
</dd>
<dt id="section-5.2-2.5">Reference:</dt>
          <dd style="margin-left: 7.0em" id="section-5.2-2.6">RFC 8688<a href="#section-5.2-2.6" class="pilcrow">¶</a>
</dd>
</dl>
</section>
<div id="JWT-IANA">
<section id="section-5.3">
        <h3 id="name-json-web-token-claim">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-json-web-token-claim" class="section-name selfRef">JSON Web Token Claim</a>
        </h3>
<p id="section-5.3-1">This document defines the new JSON Web Token claim in the "JSON Web
        Token Claims" subregistry created by <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span>. <a href="#JWT" class="xref">Section 3.2.2</a> defines the
        syntax. The required information is:<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<dl class="dlParallel dlCompact" id="section-5.3-2">
          <dt id="section-5.3-2.1">Claim Name:</dt>
          <dd style="margin-left: 10.0em" id="section-5.3-2.2">jcard<a href="#section-5.3-2.2" class="pilcrow">¶</a>
</dd>
<dt id="section-5.3-2.3">Claim Description:</dt>
          <dd style="margin-left: 10.0em" id="section-5.3-2.4">jCard data<a href="#section-5.3-2.4" class="pilcrow">¶</a>
</dd>
<dt id="section-5.3-2.5">Change Controller:</dt>
          <dd style="margin-left: 10.0em" id="section-5.3-2.6">IESG<a href="#section-5.3-2.6" class="pilcrow">¶</a>
</dd>
<dt id="section-5.3-2.7">Reference:</dt>
          <dd style="margin-left: 10.0em" id="section-5.3-2.8">RFC 8688, <span>[<a href="#RFC7095" class="xref">RFC7095</a>]</span><a href="#section-5.3-2.8" class="pilcrow">¶</a>
</dd>
</dl>
</section>
</div>
<section id="section-5.4">
        <h3 id="name-call-info-purpose">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-call-info-purpose" class="section-name selfRef">Call-Info Purpose</a>
        </h3>
<p id="section-5.4-1">This document defines the new predefined value "jwscard" for the
        "purpose" header field parameter of the Call-Info header field. This
        modifies the "Header Field Parameters and Parameter Values"
        subregistry of the "Session Initiation Protocol (SIP) Parameters"
        registry by adding this RFC as a reference to the line for the header
        field "Call-Info" and parameter name "purpose":<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<dl class="dlParallel dlCompact" id="section-5.4-2">
          <dt id="section-5.4-2.1">Header Field:</dt>
          <dd style="margin-left: 10.0em" id="section-5.4-2.2">Call-Info<a href="#section-5.4-2.2" class="pilcrow">¶</a>
</dd>
<dt id="section-5.4-2.3">Parameter Name:</dt>
          <dd style="margin-left: 10.0em" id="section-5.4-2.4">purpose<a href="#section-5.4-2.4" class="pilcrow">¶</a>
</dd>
<dt id="section-5.4-2.5">Predefined Values:</dt>
          <dd style="margin-left: 10.0em" id="section-5.4-2.6">Yes<a href="#section-5.4-2.6" class="pilcrow">¶</a>
</dd>
<dt id="section-5.4-2.7">Reference:</dt>
          <dd style="margin-left: 10.0em" id="section-5.4-2.8">RFC 8688<a href="#section-5.4-2.8" class="pilcrow">¶</a>
</dd>
</dl>
</section>
</section>
<div id="Security">
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">Intermediary operators need to be mindful to whom they are sending
      the 608 response. The intermediary could be rejecting a truly malicious
      caller. This raises two issues. The first is the caller, now alerted
      that an intermediary is automatically rejecting their call attempts, may
      change their call behavior to defeat call-blocking systems. The second,
      and more significant risk, is that by providing a contact in the
      Call-Info header field, the intermediary may be giving the malicious
      caller a vector for attack. In other words, the intermediary will be
      publishing an address that a malicious actor may use to launch an attack
      on the intermediary. Because of this, intermediary operators may wish to
      configure their response to only include a Call-Info header field for
      INVITE, or other signed initiating methods, that pass validation by
      <span><a href="#RFC8224" class="xref">STIR</a> [<a href="#RFC8224" class="xref">RFC8224</a>]</span>.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">Another risk is as follows. Consider an attacker that floods a proxy
      that supports the sip.608 feature. However, the SDP in the INVITE
      request refers to a victim device. Moreover, the attacker somehow knows
      there is a 608-aware gateway connecting to the victim who is on a
      segment that lacks the sip.608 feature capability. Because the mechanism
      described here can result in sending an audio file to the target of the
      SDP, an attacker could use the mechanism described by this document as
      an amplification attack, given a SIP INVITE can be under 1 kilobyte and
      an audio file can be hundreds of kilobytes. One remediation for this is
      for devices that insert a sip.608 feature capability to only transmit
      media to what is highly likely to be the actual source of the call
      attempt. A method for this is to only play media in response to a
      STIR-signed INVITE that passes validation. Beyond requiring a valid STIR
      signature on the INVITE, the intermediary can also use remediation
      procedures such as doing the connectivity checks specified by <span><a href="#RFC8445" class="xref">Interactive Connectivity
      Establishment</a> [<a href="#RFC8445" class="xref">RFC8445</a>]</span>. If the target did not request the media, the check
      will fail.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">Yet another risk is a malicious intermediary that generates a
      malicious 608 response with a jCard referring to a malicious agent. For
      example, the recipient of a 608 may receive a TEL URI in the vCard. When
      the recipient calls that address, the malicious agent could ask for
      personally identifying information. However, instead of using that
      information to verify the recipient's identity, they are phishing the
      information for nefarious ends. A similar scenario can unfold if the
      malicious agent inserts a URI that points to a phishing or other site.
      As such, we strongly recommend the recipient validates to whom they are
      communicating with if asking to adjudicate an erroneously rejected call
      attempt. Since we may also be concerned about intermediate nodes
      modifying contact information, we can address both issues with a single
      solution. The remediation is to require the intermediary to sign the
      jCard. Signing the jCard provides integrity protection. In addition, one
      can imagine mechanisms such as used by <span>[<a href="#SHAKEN" class="xref">SHAKEN</a>]</span>.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">Similarly, one can imagine an adverse agent that maliciously spoofs a
      608 response with a victim's contact address to many active callers who
      may then all send redress requests to the specified address (the basis
      for a denial-of-service attack). The process would occur as follows: (1)
      a malicious agent senses INVITE requests from a variety of UACs and (2)
      spoofs 608 responses with an unsigned redress address before the
      intended receivers can respond, causing (3) the UACs to all contact the
      redress address at once. The jCard encoding allows the UAC to verify the
      blocking intermediary's identity before contacting the redress address.
      Specifically, because the sender signs the jCard, we can
      cryptographically trace the sender of the jCard. Given the protocol
      machinery of having a signature, one can apply local policy to decide
      whether to believe that the sender of the jCard represents the owner of
      the contact information found in the jCard. This guards against a
      malicious agent spoofing 608 responses.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">Specifically, one could use policies around signing certificate
      issuance as a mechanism for traceback to the entity issuing the jCard.
      One check could be verifying that the identity of the subject of the
      certificate relates to the To header field of the initial SIP request,
      similar to validating that the intermediary was vouching for the From
      header field of a SIP request with that identity. Note that we are only
      protecting against a malicious intermediary and not a hidden
      intermediary attack (formerly known as a "man-in-the-middle attack").
      Thus, we only need to ensure the signature is fresh, which is why we
      include "iat". For most implementations, we assume that the intermediary
      has a single set of contact points and will generate the jCard on
      demand. As such, there is no need to directly correlate HTTPS fetches to
      specific calls. However, since the intermediary is in control of the
      jCard and Call-Info response, an intermediary may choose to encode
      per-call information in the URI returned in a given 608 response.
      However, if the intermediary does go that route, the intermediary
      <span class="bcp14">MUST</span> use a non-deterministic URI reference mechanism and
      be prepared to return dummy responses to URI requests referencing calls
      that do not exist so that attackers attempting to glean call metadata by
      guessing URIs (and thus calls) will not get any actionable information
      from the HTTPS GET.<a href="#section-6-5" class="pilcrow">¶</a></p>
<p id="section-6-6">Since the decision of whether to include Call-Info in the 608
      response is a matter of policy, one thing to consider is whether a
      legitimate caller can ascertain whom to contact without including such
      information in the 608. For example, in some jurisdictions, if only the
      terminating service provider can be the intermediary, the caller can
      look up who the terminating service provider is based on the routing
      information for the dialed number. Thus, the Call-Info jCard could be
      redundant information. However, the factors going into a particular
      service provider's or jurisdiction's choice of whether to include
      Call-Info is outside the scope of this document.<a href="#section-6-6" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-7">
      <h2 id="name-references">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-7.1">
        <h3 id="name-normative-references">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">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>
<dt id="RFC3261">[RFC3261]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor">, Schulzrinne, H.</span><span class="refAuthor">, Camarillo, G.</span><span class="refAuthor">, Johnston, A.</span><span class="refAuthor">, Peterson, J.</span><span class="refAuthor">, Sparks, R.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, and E. Schooler</span>, <span class="refTitle">"SIP: Session Initiation Protocol"</span>, <span class="seriesInfo">RFC 3261</span>, <span class="seriesInfo">DOI 10.17487/RFC3261</span>, <time datetime="2002-06">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>
<dt id="RFC3262">[RFC3262]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor"> and H. Schulzrinne</span>, <span class="refTitle">"Reliability of Provisional Responses in Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 3262</span>, <span class="seriesInfo">DOI 10.17487/RFC3262</span>, <time datetime="2002-06">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3262">https://www.rfc-editor.org/info/rfc3262</a>&gt;</span>. </dd>
<dt id="RFC3326">[RFC3326]</dt>
        <dd>
<span class="refAuthor">Schulzrinne, H.</span><span class="refAuthor">, Oran, D.</span><span class="refAuthor">, and 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">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>
<dt id="RFC6809">[RFC6809]</dt>
        <dd>
<span class="refAuthor">Holmberg, C.</span><span class="refAuthor">, Sedlacek, I.</span><span class="refAuthor">, and H. Kaplan</span>, <span class="refTitle">"Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 6809</span>, <span class="seriesInfo">DOI 10.17487/RFC6809</span>, <time datetime="2012-11">November 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6809">https://www.rfc-editor.org/info/rfc6809</a>&gt;</span>. </dd>
<dt id="RFC7095">[RFC7095]</dt>
        <dd>
<span class="refAuthor">Kewisch, P.</span>, <span class="refTitle">"jCard: The JSON Format for vCard"</span>, <span class="seriesInfo">RFC 7095</span>, <span class="seriesInfo">DOI 10.17487/RFC7095</span>, <time datetime="2014-01">January 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7095">https://www.rfc-editor.org/info/rfc7095</a>&gt;</span>. </dd>
<dt id="RFC7515">[RFC7515]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span><span class="refAuthor">, Bradley, J.</span><span class="refAuthor">, and N. Sakimura</span>, <span class="refTitle">"JSON Web Signature (JWS)"</span>, <span class="seriesInfo">RFC 7515</span>, <span class="seriesInfo">DOI 10.17487/RFC7515</span>, <time datetime="2015-05">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7515">https://www.rfc-editor.org/info/rfc7515</a>&gt;</span>. </dd>
<dt id="RFC7518">[RFC7518]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refTitle">"JSON Web Algorithms (JWA)"</span>, <span class="seriesInfo">RFC 7518</span>, <span class="seriesInfo">DOI 10.17487/RFC7518</span>, <time datetime="2015-05">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7518">https://www.rfc-editor.org/info/rfc7518</a>&gt;</span>. </dd>
<dt id="RFC7519">[RFC7519]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span><span class="refAuthor">, Bradley, J.</span><span class="refAuthor">, and N. Sakimura</span>, <span class="refTitle">"JSON Web Token (JWT)"</span>, <span class="seriesInfo">RFC 7519</span>, <span class="seriesInfo">DOI 10.17487/RFC7519</span>, <time datetime="2015-05">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7519">https://www.rfc-editor.org/info/rfc7519</a>&gt;</span>. </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">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>
</dl>
</section>
<section id="section-7.2">
        <h3 id="name-informative-references">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="BaseRate">[BaseRate]</dt>
        <dd>
<span class="refAuthor">Bar-Hillel, M.</span>, <span class="refTitle">"The Base-Rate Fallacy in Probability Judgements"</span>, <time datetime="1977-04">April 1977</time>, <span>&lt;<a href="https://apps.dtic.mil/docs/citations/ADA045772">https://apps.dtic.mil/docs/citations/ADA045772</a>&gt;</span>. </dd>
<dt id="ITU.E.180.1998">[ITU.E.180.1998]</dt>
        <dd>
<span class="refAuthor">ITU-T</span>, <span class="refTitle">"Technical characteristics of tones for the telephone service"</span>, <span class="seriesInfo">ITU-T Recommendation E.180/Q.35</span>, <time datetime="1998-03">March 1998</time>. </dd>
<dt id="RFC4103">[RFC4103]</dt>
        <dd>
<span class="refAuthor">Hellstrom, G.</span><span class="refAuthor"> and 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">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>
<dt id="RFC4240">[RFC4240]</dt>
        <dd>
<span class="refAuthor">Burger, E., Ed.</span><span class="refAuthor">, Van Dyke, J.</span><span class="refAuthor">, and A. Spitzer</span>, <span class="refTitle">"Basic Network Media Services with SIP"</span>, <span class="seriesInfo">RFC 4240</span>, <span class="seriesInfo">DOI 10.17487/RFC4240</span>, <time datetime="2005-12">December 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4240">https://www.rfc-editor.org/info/rfc4240</a>&gt;</span>. </dd>
<dt id="RFC4566">[RFC4566]</dt>
        <dd>
<span class="refAuthor">Handley, M.</span><span class="refAuthor">, Jacobson, V.</span><span class="refAuthor">, and C. Perkins</span>, <span class="refTitle">"SDP: Session Description Protocol"</span>, <span class="seriesInfo">RFC 4566</span>, <span class="seriesInfo">DOI 10.17487/RFC4566</span>, <time datetime="2006-07">July 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4566">https://www.rfc-editor.org/info/rfc4566</a>&gt;</span>. </dd>
<dt id="RFC5039">[RFC5039]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor"> and C. Jennings</span>, <span class="refTitle">"The Session Initiation Protocol (SIP) and Spam"</span>, <span class="seriesInfo">RFC 5039</span>, <span class="seriesInfo">DOI 10.17487/RFC5039</span>, <time datetime="2008-01">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5039">https://www.rfc-editor.org/info/rfc5039</a>&gt;</span>. </dd>
<dt id="RFC6350">[RFC6350]</dt>
        <dd>
<span class="refAuthor">Perreault, S.</span>, <span class="refTitle">"vCard Format Specification"</span>, <span class="seriesInfo">RFC 6350</span>, <span class="seriesInfo">DOI 10.17487/RFC6350</span>, <time datetime="2011-08">August 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6350">https://www.rfc-editor.org/info/rfc6350</a>&gt;</span>. </dd>
<dt id="RFC7092">[RFC7092]</dt>
        <dd>
<span class="refAuthor">Kaplan, H.</span><span class="refAuthor"> and V. Pascual</span>, <span class="refTitle">"A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents"</span>, <span class="seriesInfo">RFC 7092</span>, <span class="seriesInfo">DOI 10.17487/RFC7092</span>, <time datetime="2013-12">December 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7092">https://www.rfc-editor.org/info/rfc7092</a>&gt;</span>. </dd>
<dt id="RFC7340">[RFC7340]</dt>
        <dd>
<span class="refAuthor">Peterson, J.</span><span class="refAuthor">, Schulzrinne, H.</span><span class="refAuthor">, and H. Tschofenig</span>, <span class="refTitle">"Secure Telephone Identity Problem Statement and Requirements"</span>, <span class="seriesInfo">RFC 7340</span>, <span class="seriesInfo">DOI 10.17487/RFC7340</span>, <time datetime="2014-09">September 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7340">https://www.rfc-editor.org/info/rfc7340</a>&gt;</span>. </dd>
<dt id="RFC8197">[RFC8197]</dt>
        <dd>
<span class="refAuthor">Schulzrinne, H.</span>, <span class="refTitle">"A SIP Response Code for Unwanted Calls"</span>, <span class="seriesInfo">RFC 8197</span>, <span class="seriesInfo">DOI 10.17487/RFC8197</span>, <time datetime="2017-07">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8197">https://www.rfc-editor.org/info/rfc8197</a>&gt;</span>. </dd>
<dt id="RFC8224">[RFC8224]</dt>
        <dd>
<span class="refAuthor">Peterson, J.</span><span class="refAuthor">, Jennings, C.</span><span class="refAuthor">, Rescorla, E.</span><span class="refAuthor">, and C. Wendt</span>, <span class="refTitle">"Authenticated Identity Management in the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 8224</span>, <span class="seriesInfo">DOI 10.17487/RFC8224</span>, <time datetime="2018-02">February 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8224">https://www.rfc-editor.org/info/rfc8224</a>&gt;</span>. </dd>
<dt id="RFC8259">[RFC8259]</dt>
        <dd>
<span class="refAuthor">Bray, T., Ed.</span>, <span class="refTitle">"The JavaScript Object Notation (JSON) Data Interchange Format"</span>, <span class="seriesInfo">STD 90</span>, <span class="seriesInfo">RFC 8259</span>, <span class="seriesInfo">DOI 10.17487/RFC8259</span>, <time datetime="2017-12">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8259">https://www.rfc-editor.org/info/rfc8259</a>&gt;</span>. </dd>
<dt id="RFC8445">[RFC8445]</dt>
        <dd>
<span class="refAuthor">Keranen, A.</span><span class="refAuthor">, Holmberg, C.</span><span class="refAuthor">, and J. Rosenberg</span>, <span class="refTitle">"Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal"</span>, <span class="seriesInfo">RFC 8445</span>, <span class="seriesInfo">DOI 10.17487/RFC8445</span>, <time datetime="2018-07">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>
<dt id="SHAKEN">[SHAKEN]</dt>
        <dd>
<span class="refAuthor">ATIS/SIP Forum IP-INNI Task Group</span>, <span class="refTitle">"Signature-based Handling of Asserted information using toKENs (SHAKEN)"</span>, <span class="seriesInfo">ATIS 1000074</span>, <time datetime="2017-01">January 2017</time>, <span>&lt;<a href="https://www.sipforum.org/download/sip-forum-twg-10-signature-based-handling-of-asserted-information-using-tokens-shaken-pdf/?wpdmdl=2813">https://www.sipforum.org/download/sip-forum-twg-10-signature-based-handling-of-asserted-information-using-tokens-shaken-pdf/?wpdmdl=2813</a>&gt;</span>. </dd>
<dt id="SR-2275">[SR-2275]</dt>
      <dd>
<span class="refAuthor">Telcordia</span>, <span class="refTitle">"Telcordia Notes on the Networks"</span>, <span class="seriesInfo">Telcordia SR-2275</span>, <time datetime="2000-10">October 2000</time>. </dd>
</dl>
</section>
</section>
<div id="Acknowledgements">
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">This document liberally lifts from <span>[<a href="#RFC8197" class="xref">RFC8197</a>]</span> in its text and structure. However, the mechanism and
      purpose of 608 is quite different than 607. Any errors are the current
      editor's and not the editor of RFC 8197. Thanks also go to Ken Carlberg
      of the FCC, Russ Housley, Paul Kyzivat, and Tolga Asveren for their
      suggestions on improving the document. Tolga's suggestion to provide a
      mechanism for legacy interoperability served to expand the document by
      50%. In addition, Tolga came up with the jCard attack. Finally, Christer
      Holmberg, as always, provided a close reading and fixed a SIP
      feature-capability bug found by Yehoshua Gev.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">Of course, we appreciated the close read and five pages of comments
      from our estimable Area Director, Adam Roach. In addition, we received
      valuable comments during IETF Last Call and JWT review from Ines Robles,
      Mike Jones, and Brian Campbell, and IESG review from Alissa Cooper, Eric
      Vyncke, Alexey Melnikov, Benjamin Kaduk, Barry Leiba, and with most
      glee, Warren Kumari.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">Finally, Bhavik Nagda provided clarifying edits as well and, more
      especially, wrote and tested an implementation of the 608 response code
      in Kamailio. Code is available at <span><a href="https://github.com/nagdab/608_Implementation">https://github.com/nagdab/608_Implementation</a></span>. Grace Chuan
      from MIT regenerated and verified the JWT while working at the FCC.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Eric W. Burger</span></div>
<div dir="auto" class="left"><span class="org">Georgetown University</span></div>
<div dir="auto" class="left"><span class="street-address">37th &amp; O St, NW</span></div>
<div dir="auto" class="left">
<span class="locality">Washington</span>, <span class="region">DC</span> <span class="postal-code">20057</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:eburger@standardstrack.com" class="email">eburger@standardstrack.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Bhavik Nagda</span></div>
<div dir="auto" class="left"><span class="org">Massachusetts Institute of Technology</span></div>
<div dir="auto" class="left"><span class="street-address">77 Massachusetts Avenue</span></div>
<div dir="auto" class="left">
<span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</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:nagdab@gmail.com" class="email">nagdab@gmail.com</a>
</div>
</address>
</section>
</div>
<script>var toc = document.getElementById("toc");
var tocToggle = toc.querySelector("h2");
var tocNav = toc.querySelector("nav");

// mobile menu toggle
tocToggle.onclick = function(event) {
    if (window.innerWidth < 1024) {
 var tocNavDisplay = tocNav.currentStyle ? tocNav.currentStyle.display : getComputedStyle(tocNav, null).display;
 if (tocNavDisplay == "none") {
     tocNav.style.display = "block";
 } else {
     tocNav.style.display = "none";
 }
    }
}

// toc anchor scroll to anchor
tocNav.addEventListener("click", function (event) {
    event.preventDefault();
    if (event.target.nodeName == 'A') {
 if (window.innerWidth < 1024) {
     tocNav.style.display = "none";
 }
 var href = event.target.getAttribute("href");
 var anchorId = href.substr(1);
 var anchor =  document.getElementById(anchorId);
 anchor.scrollIntoView(true);
 window.history.pushState("","",href);
    }
});

// switch toc mode when window resized
window.onresize = function () {
    if (window.innerWidth < 1024) {
 tocNav.style.display = "none";
    } else {
 tocNav.style.display = "block";
    }
}
</script>
</body>
</html>