File: rfc8845.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 (6005 lines) | stat: -rw-r--r-- 305,961 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8845: Framework for Telepresence Multi-Streams</title>
<meta content="Mark Duckworth" name="author">
<meta content="Andrew Pepperell" name="author">
<meta content="Stephan Wenger" name="author">
<meta content="
       
   This document defines a framework for a protocol to enable devices
   in a telepresence conference to interoperate.  The protocol enables
   communication of information about multiple media streams so a
   sending system and receiving system can make reasonable decisions
   about transmitting, selecting, and rendering the media streams.
   This protocol is used in addition to SIP signaling and Session Description Protocol (SDP)
   negotiation for setting up a telepresence session. 
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="Telepresence" name="keyword">
<meta content="Conferencing" name="keyword">
<meta content="Video-Conferencing" name="keyword">
<meta content="MCU" name="keyword">
<meta content="8845" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.5.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8845.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8845" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-clue-framework-25" 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 8845</td>
<td class="center">CLUE Framework</td>
<td class="right">January 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Duckworth, et al.</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8845" class="eref">8845</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-01" class="published">January 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">M. Duckworth, <span class="editor">Ed.</span>
</div>
</div>
<div class="author">
      <div class="author-name">A. Pepperell</div>
<div class="org">Acano</div>
</div>
<div class="author">
      <div class="author-name">S. Wenger</div>
<div class="org">Tencent</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8845</h1>
<h1 id="title">Framework for Telepresence Multi-Streams</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
   This document defines a framework for a protocol to enable devices
   in a telepresence conference to interoperate.  The protocol enables
   communication of information about multiple media streams so a
   sending system and receiving system can make reasonable decisions
   about transmitting, selecting, and rendering the media streams.
   This protocol is used in addition to SIP signaling and Session Description Protocol (SDP)
   negotiation for setting up a telepresence session.<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/rfc8845">https://www.rfc-editor.org/info/rfc8845</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-definitions" class="xref">Definitions</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-overview-and-motivation" class="xref">Overview and Motivation</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-description-of-the-framewor" class="xref">Description of the Framework/Model</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-spatial-relationships" class="xref">Spatial Relationships</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-media-captures-and-capture-" class="xref">Media Captures and Capture Scenes</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-media-captures" class="xref">Media Captures</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.7.2.1.2.1">
                    <p id="section-toc.1-1.7.2.1.2.1.1"><a href="#section-7.1.1" class="xref">7.1.1</a>.  <a href="#name-media-capture-attributes" class="xref">Media Capture Attributes</a><a href="#section-toc.1-1.7.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-multiple-content-capture" class="xref">Multiple Content Capture</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.7.2.2.2.1">
                    <p id="section-toc.1-1.7.2.2.2.1.1"><a href="#section-7.2.1" class="xref">7.2.1</a>.  <a href="#name-mcc-attributes" class="xref">MCC Attributes</a><a href="#section-toc.1-1.7.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-capture-scene" class="xref">Capture Scene</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.7.2.3.2.1">
                    <p id="section-toc.1-1.7.2.3.2.1.1"><a href="#section-7.3.1" class="xref">7.3.1</a>.  <a href="#name-capture-scene-attributes" class="xref">Capture Scene Attributes</a><a href="#section-toc.1-1.7.2.3.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.3.2.2">
                    <p id="section-toc.1-1.7.2.3.2.2.1"><a href="#section-7.3.2" class="xref">7.3.2</a>.  <a href="#name-capture-scene-view-attribut" class="xref">Capture Scene View Attributes</a><a href="#section-toc.1-1.7.2.3.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.4">
                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="xref">7.4</a>.  <a href="#name-global-view-list" class="xref">Global View List</a><a href="#section-toc.1-1.7.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-simultaneous-transmission-s" class="xref">Simultaneous Transmission Set Constraints</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-encodings" class="xref">Encodings</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-individual-encodings" class="xref">Individual Encodings</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-encoding-group" class="xref">Encoding Group</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.3">
                <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="xref">9.3</a>.  <a href="#name-associating-captures-with-e" class="xref">Associating Captures with Encoding Groups</a><a href="#section-toc.1-1.9.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-consumers-choice-of-streams" class="xref">Consumer's Choice of Streams to Receive from the Provider</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-local-preference" class="xref">Local Preference</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-physical-simultaneity-restr" class="xref">Physical Simultaneity Restrictions</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.10.2.3">
                <p id="section-toc.1-1.10.2.3.1"><a href="#section-10.3" class="xref">10.3</a>.  <a href="#name-encoding-and-encoding-group" class="xref">Encoding and Encoding Group Limits</a><a href="#section-toc.1-1.10.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-extensibility" class="xref">Extensibility</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-examples-using-the-framewor" class="xref">Examples - Using the Framework (Informative)</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="xref">12.1</a>.  <a href="#name-provider-behavior" class="xref">Provider Behavior</a><a href="#section-toc.1-1.12.2.1.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.1.2.1">
                    <p id="section-toc.1-1.12.2.1.2.1.1"><a href="#section-12.1.1" class="xref">12.1.1</a>.  <a href="#name-three-screen-endpoint-provi" class="xref">Three-Screen Endpoint Provider</a><a href="#section-toc.1-1.12.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.1.2.2">
                    <p id="section-toc.1-1.12.2.1.2.2.1"><a href="#section-12.1.2" class="xref">12.1.2</a>.  <a href="#name-encoding-group-example" class="xref">Encoding Group Example</a><a href="#section-toc.1-1.12.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.1.2.3">
                    <p id="section-toc.1-1.12.2.1.2.3.1"><a href="#section-12.1.3" class="xref">12.1.3</a>.  <a href="#name-the-mcu-case" class="xref">The MCU Case</a><a href="#section-toc.1-1.12.2.1.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.2">
                <p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="xref">12.2</a>.  <a href="#name-media-consumer-behavior" class="xref">Media Consumer Behavior</a><a href="#section-toc.1-1.12.2.2.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.2.2.1">
                    <p id="section-toc.1-1.12.2.2.2.1.1"><a href="#section-12.2.1" class="xref">12.2.1</a>.  <a href="#name-one-screen-media-consumer" class="xref">One-Screen Media Consumer</a><a href="#section-toc.1-1.12.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.2.2.2">
                    <p id="section-toc.1-1.12.2.2.2.2.1"><a href="#section-12.2.2" class="xref">12.2.2</a>.  <a href="#name-two-screen-media-consumer-c" class="xref">Two-Screen Media Consumer Configuring the Example</a><a href="#section-toc.1-1.12.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.2.2.3">
                    <p id="section-toc.1-1.12.2.2.2.3.1"><a href="#section-12.2.3" class="xref">12.2.3</a>.  <a href="#name-three-screen-media-consumer" class="xref">Three-Screen Media Consumer Configuring the Example</a><a href="#section-toc.1-1.12.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.3">
                <p id="section-toc.1-1.12.2.3.1"><a href="#section-12.3" class="xref">12.3</a>.  <a href="#name-multipoint-conference-utili" class="xref">Multipoint Conference Utilizing Multiple Content Captures</a><a href="#section-toc.1-1.12.2.3.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.3.2.1">
                    <p id="section-toc.1-1.12.2.3.2.1.1"><a href="#section-12.3.1" class="xref">12.3.1</a>.  <a href="#name-single-media-captures-and-m" class="xref">Single Media Captures and MCC in the Same Advertisement</a><a href="#section-toc.1-1.12.2.3.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.3.2.2">
                    <p id="section-toc.1-1.12.2.3.2.2.1"><a href="#section-12.3.2" class="xref">12.3.2</a>.  <a href="#name-several-mccs-in-the-same-ad" class="xref">Several MCCs in the Same Advertisement</a><a href="#section-toc.1-1.12.2.3.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.3.2.3">
                    <p id="section-toc.1-1.12.2.3.2.3.1"><a href="#section-12.3.3" class="xref">12.3.3</a>.  <a href="#name-heterogeneous-conference-wi" class="xref">Heterogeneous Conference with Switching and Composition</a><a href="#section-toc.1-1.12.2.3.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.3.2.4">
                    <p id="section-toc.1-1.12.2.3.2.4.1"><a href="#section-12.3.4" class="xref">12.3.4</a>.  <a href="#name-heterogeneous-conference-wit" class="xref">Heterogeneous Conference with Voice-Activated Switching</a><a href="#section-toc.1-1.12.2.3.2.4.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-13" class="xref">13</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-14" class="xref">14</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-15" class="xref">15</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.15.2.1">
                <p id="section-toc.1-1.15.2.1.1"><a href="#section-15.1" class="xref">15.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.15.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.15.2.2">
                <p id="section-toc.1-1.15.2.2.1"><a href="#section-15.2" class="xref">15.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.15.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.16.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.17">
            <p id="section-toc.1-1.17.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.17.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="s-1">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">
   Current telepresence systems, though based on open standards such
   as RTP <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span> and SIP <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span>, cannot easily interoperate with
   each other.  A major factor limiting the interoperability of
   telepresence systems is the lack of a standardized way to describe
   and negotiate the use of multiple audio and video streams
   comprising the media flows.  This document provides a framework for
   protocols to enable interoperability by handling multiple streams
   in a standardized way.  The framework is intended to support the
   use cases described in "Use Cases for Telepresence Multistreams"
   <span>[<a href="#RFC7205" class="xref">RFC7205</a>]</span> and to meet the requirements in "Requirements for
   Telepresence Multistreams" <span>[<a href="#RFC7262" class="xref">RFC7262</a>]</span>. This includes cases using
   multiple media streams that are not necessarily telepresence.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
   The basic session setup for the use cases is based on SIP <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span>
   and SDP offer/answer <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span>.  In addition to basic SIP &amp; SDP
   offer/answer, signaling that is ControLling mUltiple streams for
   tElepresence (CLUE) specific is required to exchange the
   information describing the multiple Media Streams.  The motivation
   for this framework, an overview of the signaling, and the information
   required to be exchanged are described in subsequent sections of
   this document.  Companion documents describe the signaling details
   <span>[<a href="#RFC8848" class="xref">RFC8848</a>]</span>, the data model <span>[<a href="#RFC8846" class="xref">RFC8846</a>]</span>, and the protocol <span>[<a href="#RFC8847" class="xref">RFC8847</a>]</span>.<a href="#section-1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-2">
<section id="section-2">
      <h2 id="name-requirements-language">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</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>
</div>
<div id="s-3">
<section id="section-3">
      <h2 id="name-definitions">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-definitions" class="section-name selfRef">Definitions</a>
      </h2>
<p id="section-3-1">
   The terms defined below are used throughout this document and
   in companion documents.  Capitalization is used in order to easily identify a defined term.<a href="#section-3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3-2">
        <dt id="section-3-2.1">Advertisement:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.2">A CLUE message a Media Provider sends to a Media
   Consumer describing specific aspects of the content of the Media
   and any restrictions it has in terms of being able to provide
   certain Streams simultaneously.<a href="#section-3-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.3">Audio Capture (AC):</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.4">Media Capture for audio.  Denoted as "ACn" in the
   examples in this document.<a href="#section-3-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.5">Capture:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.6">Same as Media Capture.<a href="#section-3-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.7">Capture Device:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.8">A device that converts physical input, such as
   audio, video, or text, into an electrical signal, in most cases to
   be fed into a Media encoder.<a href="#section-3-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.9">Capture Encoding:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.10">A specific Encoding of a Media Capture, to be
   sent by a Media Provider to a Media Consumer via RTP.<a href="#section-3-2.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.11">Capture Scene:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.12">A structure representing a spatial region captured
   by one or more Capture Devices, each capturing Media representing a
   portion of the region. The spatial region represented by a Capture
   Scene may correspond to a real region in physical space, such as a
   room.  A Capture Scene includes attributes and one or more Capture
   Scene Views, with each view including one or more Media Captures.<a href="#section-3-2.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.13">Capture Scene View (CSV):</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.14">A list of Media Captures of the same
   Media type that together form one way to represent the entire
   Capture Scene.<a href="#section-3-2.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.15">CLUE:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.16">CLUE is an
   acronym for "ControLling mUltiple streams for tElepresence", which is
   the name of the IETF working group in which this document and certain
   companion documents have been developed.  Often, CLUE-* refers to
   something that has been designed by the CLUE working group; for
   example, this document may be called the CLUE-framework document
   herein and elsewhere.<a href="#section-3-2.16" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.17">CLUE-capable device:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.18">A device that supports the CLUE data channel
   <span>[<a href="#RFC8850" class="xref">RFC8850</a>]</span>, the CLUE protocol <span>[<a href="#RFC8847" class="xref">RFC8847</a>]</span> and the principles of CLUE negotiation; it also seeks CLUE-enabled calls.<a href="#section-3-2.18" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.19">CLUE-enabled call:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.20">A call in which two CLUE-capable devices have
   successfully negotiated support for a CLUE data channel in SDP
   <span>[<a href="#RFC4566" class="xref">RFC4566</a>]</span>. A CLUE-enabled call is not necessarily immediately able
   to send CLUE-controlled Media; negotiation of the data channel and
   of the CLUE protocol must complete first. Calls between two CLUE-capable devices that have not yet successfully completed
   negotiation of support for the CLUE data channel in SDP are not
   considered CLUE-enabled.<a href="#section-3-2.20" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.21">Conference:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.22">Used as defined in "A Framework for
   Conferencing within the Session Initiation Protocol (SIP)" <span>[<a href="#RFC4353" class="xref">RFC4353</a>]</span>.<a href="#section-3-2.22" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.23">Configure Message:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.24">A CLUE message a Media Consumer sends to a Media
   Provider specifying which content and Media Streams it wants to
   receive, based on the information in a corresponding Advertisement
   message.<a href="#section-3-2.24" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.25">Consumer:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.26">Short for Media Consumer.<a href="#section-3-2.26" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.27">Encoding:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.28">Short for Individual Encoding.<a href="#section-3-2.28" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.29">Encoding Group:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.30">A set of Encoding parameters representing a total
   Media Encoding capability to be subdivided across potentially
   multiple Individual Encodings.<a href="#section-3-2.30" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.31">Endpoint:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.32">A CLUE-capable device that is the logical point of final
   termination through receiving, decoding and Rendering, and/or
   initiation through capturing, encoding, and sending of Media
   Streams.  An Endpoint consists of one or more physical devices
   that source and sink Media Streams, and exactly one <span>[<a href="#RFC4353" class="xref">RFC4353</a>]</span>
   Participant (which, in turn, includes exactly one SIP User Agent).
   Endpoints can be anything from multiscreen/multicamera rooms to
   handheld devices.<a href="#section-3-2.32" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.33">Global View:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.34">A set of references to one or more CSVs
   of the same Media type that are defined within Scenes of the same
   Advertisement.  A Global View is a suggestion from the Provider to
   the Consumer for one set of CSVs that provide a useful
   representation of all the Scenes in the Advertisement.<a href="#section-3-2.34" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.35">Global View List:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.36">A list of Global Views included in an
   Advertisement.  A Global View List may include Global Views of
   different Media types.<a href="#section-3-2.36" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.37">Individual Encoding:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.38">a set of parameters representing a way to
   encode a Media Capture to become a Capture Encoding.<a href="#section-3-2.38" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.39">Multipoint Control Unit (MCU):</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.40">a CLUE-capable device that connects
   two or more Endpoints into one single multimedia
   Conference <span>[<a href="#RFC7667" class="xref">RFC7667</a>]</span>.  An MCU includes a Mixer like that described in <span>[<a href="#RFC4353" class="xref">RFC4353</a>]</span>,
   without the requirement of <span>[<a href="#RFC4353" class="xref">RFC4353</a>]</span> to send Media to each
   participant.<a href="#section-3-2.40" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.41">Media:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.42">Any data that, after suitable encoding, can be conveyed over
   RTP, including audio, video, or timed text.<a href="#section-3-2.42" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.43">Media Capture (MC):</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.44">A source of Media, such as from one or more Capture
   Devices or constructed from other Media Streams.<a href="#section-3-2.44" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.45">Media Consumer:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.46">A CLUE-capable device that intends to receive
   Capture Encodings.<a href="#section-3-2.46" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.47">Media Provider:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.48">A CLUE-capable device that intends to send Capture
   Encodings.<a href="#section-3-2.48" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.49">Multiple Content Capture (MCC):</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.50">A Capture that mixes and/or
   switches other Captures of a single type (for example, all audio or all
   video). Particular Media Captures may or may not be present in the
   resultant Capture Encoding, depending on time or space.  Denoted as
   "MCCn" in the example cases in this document.<a href="#section-3-2.50" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.51">Plane of Interest:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.52">The spatial plane within a Scene containing the
   most-relevant subject matter.<a href="#section-3-2.52" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.53">Provider:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.54">Same as a Media Provider.<a href="#section-3-2.54" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.55">Render:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.56">The process of generating a representation from Media, such
   as displayed motion video or sound emitted from loudspeakers.<a href="#section-3-2.56" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.57">Scene:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.58">Same as a Capture Scene.<a href="#section-3-2.58" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.59">Simultaneous Transmission Set:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.60">A set of Media Captures that can be
   transmitted simultaneously from a Media Provider.<a href="#section-3-2.60" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.61">Single Media Capture:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.62">A Capture that contains Media from a single
   source Capture Device, e.g., an Audio Capture from a single
   microphone or a Video Capture from a single camera.<a href="#section-3-2.62" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.63">Spatial Relation:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.64">The arrangement of two objects in space, in
   contrast to relation in time or other relationships.<a href="#section-3-2.64" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.65">Stream:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.66">A Capture Encoding sent from a Media Provider to a Media
   Consumer via RTP <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>.<a href="#section-3-2.66" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.67">Stream Characteristics:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.68">The Media Stream attributes commonly used
   in non-CLUE SIP/SDP environments (such as Media codec, bitrate,
   resolution, profile/level, etc.) as well as CLUE-specific
   attributes, such as the Capture ID or a spatial location.<a href="#section-3-2.68" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.69">Video Capture (VC):</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.70">Media Capture for video.  Denoted as VCn in the
   example cases in this document.<a href="#section-3-2.70" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.71">Video Composite:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.72">A single image that is formed, normally by an RTP
   mixer inside an MCU, by combining visual elements from separate
   sources.<a href="#section-3-2.72" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="s-4">
<section id="section-4">
      <h2 id="name-overview-and-motivation">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-overview-and-motivation" class="section-name selfRef">Overview and Motivation</a>
      </h2>
<p id="section-4-1">
   This section provides an overview of the functional elements
   defined in this document to represent a telepresence or
   multistream system.  The motivations for the framework described
   in this document are also provided.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">
   Two key concepts introduced in this document are the terms "Media Provider" and "Media Consumer". A Media Provider represents the
   entity that sends the Media and a Media Consumer represents the
   entity that receives the Media. A Media Provider provides Media in
   the form of RTP packets; a Media Consumer consumes those RTP
   packets.  Media Providers and Media Consumers can reside in
   Endpoints or in Multipoint Control Units (MCUs).  A Media Provider
   in an Endpoint is usually associated with the generation of Media
   for Media Captures; these Media Captures are typically sourced
   from cameras, microphones, and the like.  Similarly, the Media
   Consumer in an Endpoint is usually associated with renderers, such
   as screens and loudspeakers.  In MCUs, Media Providers and
   Consumers can have the form of outputs and inputs, respectively,
   of RTP mixers, RTP translators, and similar devices.  Typically,
   telepresence devices, such as Endpoints and MCUs, would perform as
   both Media Providers and Media Consumers, the former being
   concerned with those devices' transmitted Media and the latter
   with those devices' received Media.  In a few circumstances, a
   CLUE-capable device includes only Consumer or Provider
   functionality, such as recorder-type Consumers or webcam-type
   Providers.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">
   The motivations for the framework outlined in this document
   include the following:<a href="#section-4-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-4-4">
        <dt>(1)</dt>
<dd id="section-4-4.1">Endpoints in telepresence systems typically have multiple Media
      Capture and Media Render devices, e.g., multiple cameras and
      screens. While previous system designs were able to set up calls
      that would capture Media using all cameras and display Media on all
      screens, for example, there was no mechanism that could associate
      these Media Captures with each other in space and time, in a cross-vendor interoperable way.<a href="#section-4-4.1" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(2)</dt>
<dd id="section-4-4.2">The mere fact that there are multiple Media Capture and Media Render
      devices, each of which may be configurable in aspects such as zoom,
      leads to the difficulty that a variable number of such devices can
      be used to capture different aspects of a region.  The Capture
      Scene concept allows for the description of multiple setups for
      those multiple Media Capture devices that could represent sensible
      operation points of the physical Capture Devices in a room, chosen
      by the operator.  A Consumer can pick and choose from those
      configurations based on its rendering abilities and then inform the
      Provider about its choices.  Details are provided in <a href="#s-7" class="xref">Section 7</a>.<a href="#section-4-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(3)</dt>
<dd id="section-4-4.3">In some cases, physical limitations or other reasons disallow
      the concurrent use of a device in more than one setup.  For
      example, the center camera in a typical three-camera conference
      room can set its zoom objective to capture either the middle
      few seats only or all seats of a room, but not both concurrently.  The
      Simultaneous Transmission Set concept allows a Provider to signal
      such limitations.  Simultaneous Transmission Sets are part of the
      Capture Scene description and are discussed in <a href="#s-8" class="xref">Section 8</a>.<a href="#section-4-4.3" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(4)</dt>
<dd id="section-4-4.4">Often, the devices in a room do not have the computational
      complexity or connectivity to deal with multiple Encoding options
      simultaneously, even if each of these options is sensible in
      certain scenarios, and even if the simultaneous transmission is
      also sensible (i.e., in case of multicast Media distribution to
      multiple Endpoints).   Such constraints can be expressed by the
      Provider using the Encoding Group concept, which is described in <a href="#s-9" class="xref">Section 9</a>.<a href="#section-4-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(5)</dt>
<dd id="section-4-4.5">Due to the potentially large number of RTP Streams required for
      a Multimedia Conference involving potentially many Endpoints, each
      of which can have many Media Captures and Media renderers, it has
      become common to multiplex multiple RTP Streams onto the same
      transport address, so as to avoid using the port number as a
      multiplexing point and the associated shortcomings such as
      NAT/firewall traversal.  The large number of possible permutations
      of sensible options a Media Provider can make available to a Media
      Consumer makes a mechanism desirable that allows it to narrow down
      the number of possible options that a SIP offer/answer exchange has
      to consider.  Such information is made available using protocol
      mechanisms specified in this document and companion documents. 
The
      Media Provider and Media Consumer may use information in CLUE
      messages to reduce the complexity of SIP offer/answer messages.
      Also, there are aspects of the control of both Endpoints and MCUs
      that dynamically change during the progress of a call, such as
      audio-level-based screen switching, layout changes, and so on,
      which need to be conveyed.  Note that these control aspects are
      complementary to those specified in traditional SIP-based
      conference management, such as Binary Floor Control Protocol (BFCP).  An exemplary call flow can be
      found in <a href="#s-5" class="xref">Section 5</a>.<a href="#section-4-4.5" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-4-5">
   Finally, all this information needs to be conveyed, and the notion
   of support for it needs to be established.  This is done by the
   negotiation of a "CLUE channel", a data channel negotiated early
   during the initiation of a call.  An Endpoint or MCU that rejects
   the establishment of this data channel, by definition, does not
   support CLUE-based mechanisms, whereas an Endpoint or MCU that
   accepts it is indicating support for CLUE as specified in this
   document and its companion documents.<a href="#section-4-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-5">
<section id="section-5">
      <h2 id="name-description-of-the-framewor">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-description-of-the-framewor" class="section-name selfRef">Description of the Framework/Model</a>
      </h2>
<p id="section-5-1">
   The CLUE framework specifies how multiple Media Streams are to be
   handled in a telepresence Conference.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
   A Media Provider (transmitting Endpoint or MCU) describes specific
   aspects of the content of the Media and the Media Stream Encodings
   it can send in an Advertisement; and the Media Consumer responds to
   the Media Provider by specifying which content and Media Streams it
   wants to receive in a Configure message.  The Provider then
   transmits the asked-for content in the specified Streams.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">
   This Advertisement and Configure typically occur during call
   initiation, after CLUE has been enabled in a call, but they <span class="bcp14">MAY</span> also
   happen at any time throughout the call, whenever there is a change
   in what the Consumer wants to receive or (perhaps less common) what the
   Provider can send.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">
   An Endpoint or MCU typically acts as both Provider and Consumer at
   the same time, sending Advertisements and sending Configurations in
   response to receiving Advertisements.  (It is possible to be just
   one or the other.)<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">
   The data model <span>[<a href="#RFC8846" class="xref">RFC8846</a>]</span> is based around two
   main concepts: a Capture and an Encoding.  A Media Capture,
   such as of type audio or video, has attributes to describe the
   content a Provider can send.  Media Captures are described in terms
   of CLUE-defined attributes, such as Spatial Relationships and
   purpose of the Capture.  Providers tell Consumers which Media
   Captures they can provide, described in terms of the Media Capture
   attributes.<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6">
   A Provider organizes its Media Captures into one or more Capture
   Scenes, each representing a spatial region, such as a room.  A
   Consumer chooses which Media Captures it wants to receive from the
   Capture Scenes.<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="section-5-7">
   In addition, the Provider can send the Consumer a description of
   the Individual Encodings it can send in terms of identifiers that
   relate to items in SDP <span>[<a href="#RFC4566" class="xref">RFC4566</a>]</span>.<a href="#section-5-7" class="pilcrow">¶</a></p>
<p id="section-5-8">
   The Provider can also specify constraints on its ability to provide
   Media, and a sensible design choice for a Consumer is to take these
   into account when choosing the content and Capture Encodings it
   requests in the later offer/answer exchange.  Some constraints are
   due to the physical limitations of device; for example, a camera
   may not be able to provide zoom and non-zoom views simultaneously.
   Other constraints are system based, such as maximum bandwidth.<a href="#section-5-8" class="pilcrow">¶</a></p>
<p id="section-5-9">
   The following diagram illustrates the information contained in an
   Advertisement.<a href="#section-5-9" class="pilcrow">¶</a></p>
<span id="name-advertisement-structure"></span><div id="ref-advertisement-structure">
<figure id="figure-1">
        <div class="artwork art-text alignLeft" id="section-5-10.1">
<pre>
...................................................................
.  Provider Advertisement             +--------------------+      .
.                                     | Simultaneous Sets  |      .
.        +------------------------+   +--------------------+      .
.        |       Capture Scene N  |   +--------------------+      .
.      +-+----------------------+ |   | Global View List   |      .
.      |       Capture Scene 2  | |   +--------------------+      .
.    +-+----------------------+ | |      +----------------------+ .
.    |  Capture Scene 1       | | |      |  Encoding Group N    | .
.    |    +---------------+   | | |    +-+--------------------+ | .
.    |    | Attributes    |   | | |    |   Encoding Group 2   | | .
.    |    +---------------+   | | |  +-+--------------------+ | | .
.    |                        | | |  |   Encoding Group 1   | | | .
.    |    +----------------+  | | |  |     parameters       | | | .
.    |    |  V i e w s     |  | | |  |      bandwidth       | | | .
.    |    |  +---------+   |  | | |  | +-------------------+| | | .
.    |    |  |Attribute|   |  | | |  | | V i d e o         || | | .
.    |    |  +---------+   |  | | |  | | E n c o d i n g s || | | .
.    |    |                |  | | |  | | Encoding 1        || | | .
.    |    | View 1         |  | | |  | |                   || | | .
.    |    |  (list of MCs) |  | |-+  | +-------------------+| | | .
.    |    +----|-|--|------+  |-+    |                      | | | .
.    +---------|-|--|---------+      | +-------------------+| | | .
.              | |  |                | | A u d i o         || | | .
.              | |  |                | | E n c o d i n g s || | | .
.              v |  |                | | Encoding 1        || | | .
.      +---------|--|--------+       | |                   || | | .
.      | Media Capture N     |------&gt;| +-------------------+| | | .
.    +-+---------v--|------+ |       |                      | | | .
.    | Media Capture 2     | |       |                      | |-+ .
.  +-+--------------v----+ |--------&gt;|                      | |   .
.  | Media Capture  1    | | |       |                      |-+   .
.  |  +----------------+ |----------&gt;|                      |     .
.  |  | Attributes     | | |_+       +----------------------+     .
.  |  +----------------+ |_+                                      .
.  +---------------------+                                        .
.                                                                 .
...................................................................
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-advertisement-structure" class="selfRef">Advertisement Structure</a>
        </figcaption></figure>
</div>
<p id="section-5-11"><a href="#ref-basic-information-flow" class="xref">Figure 2</a> illustrates the call flow used by a simple system (two Endpoints) in compliance with this document.  A very brief outline of the call flow is described in the text that follows.<a href="#section-5-11" class="pilcrow">¶</a></p>
<span id="name-basic-information-flow"></span><div id="ref-basic-information-flow">
<figure id="figure-2">
        <div class="artwork art-text alignLeft" id="section-5-12.1">
<pre>
      +-----------+                     +-----------+
      | Endpoint1 |                     | Endpoint2 |
      +----+------+                     +-----+-----+
           | INVITE (BASIC SDP+CLUECHANNEL)   |
           |---------------------------------&gt;|
           |    200 0K (BASIC SDP+CLUECHANNEL)|
           |&lt;---------------------------------|
           | ACK                              |
           |---------------------------------&gt;|
           |                                  |
           |&lt;################################&gt;|
           |       BASIC MEDIA SESSION        |
           |&lt;################################&gt;|
           |                                  |
           |    CONNECT (CLUE CTRL CHANNEL)   |
           |=================================&gt;|
           |            ...                   |
           |&lt;================================&gt;|
           |   CLUE CTRL CHANNEL ESTABLISHED  |
           |&lt;================================&gt;|
           |                                  |
           | ADVERTISEMENT 1                  |
           |*********************************&gt;|
           |                  ADVERTISEMENT 2 |
           |&lt;*********************************|
           |                                  |
           |                      CONFIGURE 1 |
           |&lt;*********************************|
           | CONFIGURE 2                      |
           |*********************************&gt;|
           |                                  |
           | REINVITE (UPDATED SDP)           |
           |---------------------------------&gt;|
           |              200 0K (UPDATED SDP)|
           |&lt;---------------------------------|
           | ACK                              |
           |---------------------------------&gt;|
           |                                  |
           |&lt;################################&gt;|
           |     UPDATED MEDIA SESSION        |
           |&lt;################################&gt;|
           |                                  |
           v                                  v
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-basic-information-flow" class="selfRef">Basic Information Flow</a>
        </figcaption></figure>
</div>
<p id="section-5-13">
   An initial offer/answer exchange establishes a basic Media session,
   for example, audio-only, and a CLUE channel between two Endpoints.
   With the establishment of that channel, the Endpoints have
   consented to use the CLUE protocol mechanisms and, therefore, <span class="bcp14">MUST</span>
   adhere to the CLUE protocol suite as outlined herein.<a href="#section-5-13" class="pilcrow">¶</a></p>
<p id="section-5-14">
   Over this CLUE channel, the Provider in each Endpoint conveys its
   characteristics and capabilities by sending an Advertisement as
   specified herein.  The Advertisement is typically not sufficient to
   set up all Media.  The Consumer in the Endpoint receives the
   information provided by the Provider and can use it for several
   purposes.  It uses it, along with information from an offer/answer
   exchange, to construct a CLUE Configure message to tell the
   Provider what the Consumer wishes to receive.  Also, the Consumer
   may use the information provided to tailor the SDP it is going to
   send during any following SIP offer/answer exchange, and its
   reaction to SDP it receives in that step.  It is often a sensible
   implementation choice to do so.  Spatial relationships associated
   with the Media can be included in the Advertisement, and it is
   often sensible for the Media Consumer to take those spatial
   relationships into account when tailoring the SDP.  The Consumer
   can also limit the number of Encodings it must set up resources to
   receive, and not waste resources on unwanted Encodings, because it
   has the Provider's Advertisement information ahead of time to
   determine what it really wants to receive.  The Consumer can also
   use the Advertisement information for local rendering decisions.<a href="#section-5-14" class="pilcrow">¶</a></p>
<p id="section-5-15">
   This initial CLUE exchange is followed by an SDP offer/answer
   exchange that not only establishes those aspects of the Media that
   have not been "negotiated" over CLUE, but also has the effect of
   setting up the Media transmission itself, involving potentially
   security exchanges, Interactive Connectivity Establishment (ICE), and whatnot.  This step is considered "plain vanilla
   SIP".<a href="#section-5-15" class="pilcrow">¶</a></p>
<p id="section-5-16">
   During the lifetime of a call, further exchanges <span class="bcp14">MAY</span> occur over the
   CLUE channel.  In some cases, those further exchanges lead to a
   modified system behavior of Provider or Consumer (or both) without
   any other protocol activity such as further offer/answer exchanges.
   For example, a Configure Message requesting that the Provider place a
   different Capture source into a Capture Encoding, signaled over the
   CLUE channel, ought not to lead to heavy-handed mechanisms like SIP
   re-invites.  In other cases, however, after the CLUE negotiation, an
   additional offer/answer exchange becomes necessary.  For example,
   if both sides decide to upgrade the call from one screen to a
   multi-screen call, and more bandwidth is required for the additional
   video channels compared to what was previously negotiated using
   offer/answer, a new offer/answer exchange is required.<a href="#section-5-16" class="pilcrow">¶</a></p>
<p id="section-5-17">
   One aspect of the protocol outlined herein, and specified in more
   detail in companion documents, is that it makes available to the
   Consumer information regarding the Provider's capabilities to
   deliver Media and attributes related to that Media such as their
   Spatial Relationship.  The operation of the renderer inside the
   Consumer is unspecified in that it can choose to ignore some
   information provided by the Provider and/or not Render Media
   Streams available from the Provider (although the Consumer follows
   the CLUE protocol and, therefore, gracefully receives and responds
   to the Provider's information using a Configure operation).<a href="#section-5-17" class="pilcrow">¶</a></p>
<p id="section-5-18">
   A CLUE-capable device interoperates with a device that does not
   support CLUE.  The CLUE-capable device can determine, by the result
   of the initial offer/answer exchange, if the other device supports
   and wishes to use CLUE. The specific mechanism for this is
   described in <span>[<a href="#RFC8848" class="xref">RFC8848</a>]</span>.  If the other device does
   not use CLUE, then the CLUE-capable device falls back to behavior
   that does not require CLUE.<a href="#section-5-18" class="pilcrow">¶</a></p>
<p id="section-5-19">
   As for the Media, Provider and Consumer have an end-to-end
   communication relationship with respect to (RTP-transported) Media;
   and the mechanisms described herein and in companion documents do
   not change the aspects of setting up those RTP flows and sessions.
   In other words, the RTP Media sessions conform to the negotiated
   SDP whether or not CLUE is used.<a href="#section-5-19" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-6">
<section id="section-6">
      <h2 id="name-spatial-relationships">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-spatial-relationships" class="section-name selfRef">Spatial Relationships</a>
      </h2>
<p id="section-6-1">
   In order for a Consumer to perform a proper rendering, it is often
   necessary (or at least helpful) for the Consumer to have received
   spatial information about the Streams it is receiving.  CLUE
   defines a coordinate system that allows Media Providers to describe
   the Spatial Relationships of their Media Captures to enable proper
   scaling and spatially sensible rendering of their Streams.  The
   coordinate system is based on a few principles:<a href="#section-6-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6-2.1">Each Capture Scene has a distinct coordinate system, unrelated
      to the coordinate systems of other Scenes.<a href="#section-6-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.2">Simple systems that do not have multiple Media Captures to
      associate spatially need not use the coordinate model, although
      it can still be useful to provide an Area of Capture.<a href="#section-6-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.3">
          <p id="section-6-2.3.1">Coordinates can either be in real, physical units (millimeters),
      have an unknown scale, or have no physical scale.  Systems that
      know their physical dimensions (for example, professionally
      installed Telepresence room systems) <span class="bcp14">MUST</span> provide those real-world measurements to enable the best user experience for
      advanced receiving systems that can utilize this information.
      Systems that don't know specific physical dimensions but still
      know relative distances <span class="bcp14">MUST</span> use "Unknown Scale".  "No Scale" is
      intended to be used only where Media Captures from different
      devices (with potentially different scales) will be forwarded
      alongside one another (e.g., in the case of an MCU).<a href="#section-6-2.3.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6-2.3.2.1">"Millimeters" means the scale is in millimeters.<a href="#section-6-2.3.2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6-2.3.2.2">"Unknown Scale" means the scale is not necessarily in millimeters, but
         the scale is the same for every Capture in the Capture Scene.<a href="#section-6-2.3.2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6-2.3.2.3">"No Scale" means the scale could be different for each
         Capture -- an MCU Provider that advertises two adjacent
         Captures and picks sources (which can change quickly) from
         different Endpoints might use this value; the scale could be
         different and changing for each Capture.  But the areas of
         capture still represent a Spatial Relation between Captures.<a href="#section-6-2.3.2.3" class="pilcrow">¶</a>
</li>
          </ul>
</li>
        <li class="normal" id="section-6-2.4">The coordinate system is right-handed Cartesian X, Y, Z with the
      origin at a spatial location of the Provider's choosing.  The
      Provider <span class="bcp14">MUST</span> use the same coordinate system with the same scale
      and origin for all coordinates within the same Capture Scene.<a href="#section-6-2.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-6-3">The direction of increasing coordinate values is as follows:
X increases from left to right, from the point of view of an
observer at the front of the room looking toward the back;
Y increases from the front of the room to the back of the room;
Z increases from low to high (i.e., floor to ceiling).<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">
   Cameras in a Scene typically point in the direction of increasing
   Y, from front to back.  But there could be multiple cameras
   pointing in different directions.  If the physical space does not
   have a well-defined front and back, the Provider chooses any
   direction for X, Y, and Z consistent with right-handed
   coordinates.<a href="#section-6-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-7">
<section id="section-7">
      <h2 id="name-media-captures-and-capture-">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-media-captures-and-capture-" class="section-name selfRef">Media Captures and Capture Scenes</a>
      </h2>
<p id="section-7-1">
   This section describes how Providers can describe the content of
   Media to Consumers.<a href="#section-7-1" class="pilcrow">¶</a></p>
<div id="s-7.1">
<section id="section-7.1">
        <h3 id="name-media-captures">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-media-captures" class="section-name selfRef">Media Captures</a>
        </h3>
<p id="section-7.1-1">
   Media Captures are the fundamental representations of Streams that
   a device can transmit.  What a Media Capture actually represents is
   flexible:<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.1-2.1">It can represent the immediate output of a physical source (e.g.,
      camera, microphone) or 'synthetic' source (e.g., laptop computer, DVD player).<a href="#section-7.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-2.2">It can represent the output of an audio mixer or video composer.<a href="#section-7.1-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-2.3">It can represent a concept such as 'the loudest speaker'.<a href="#section-7.1-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-2.4">It can represent a conceptual position such as 'the leftmost
      Stream'.<a href="#section-7.1-2.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.1-3">
   To identify and distinguish between multiple Capture instances,
   Captures have a unique identity.  For instance, VC1, VC2, AC1, and
   AC2 (where VC1 and VC2 refer to two different Video Captures and
   AC1 and AC2 refer to two different Audio Captures).<a href="#section-7.1-3" class="pilcrow">¶</a></p>
<p id="section-7.1-4">Some key points about Media Captures:<a href="#section-7.1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.1-5.1">A Media Capture is of a single Media type (e.g., audio or
       video).<a href="#section-7.1-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-5.2">A Media Capture is defined in a Capture Scene and is given an
       Advertisement unique identity.  The identity may be referenced
       outside the Capture Scene that defines it through an MCC.<a href="#section-7.1-5.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-5.3">A Media Capture may be associated with one or more CSVs.<a href="#section-7.1-5.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-5.4">A Media Capture has exactly one set of spatial information.<a href="#section-7.1-5.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-5.5">A Media Capture can be the source of at most one Capture
       Encoding.<a href="#section-7.1-5.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.1-6">
   Each Media Capture can be associated with attributes to describe
   what it represents.<a href="#section-7.1-6" class="pilcrow">¶</a></p>
<div id="s-7.1.1">
<section id="section-7.1.1">
          <h4 id="name-media-capture-attributes">
<a href="#section-7.1.1" class="section-number selfRef">7.1.1. </a><a href="#name-media-capture-attributes" class="section-name selfRef">Media Capture Attributes</a>
          </h4>
<p id="section-7.1.1-1">
   Media Capture attributes describe information about the Captures.
   A Provider can use the Media Capture attributes to describe the
   Captures for the benefit of the Consumer of the Advertisement
   message.  All these attributes are optional.  Media Capture
   attributes include:<a href="#section-7.1.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.1.1-2.1">Spatial information, such as Point of Capture, Point on Line
        of Capture, and Area of Capture, (all of which, in combination,
        define the capture field of, for example, a camera).<a href="#section-7.1.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-7.1.1-2.2">Other descriptive information to help the Consumer choose
        between Captures (e.g., description, presentation, view,
        priority, language, person information, and type).<a href="#section-7.1.1-2.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-7.1.1-3">
   The subsections below define the Capture attributes.<a href="#section-7.1.1-3" class="pilcrow">¶</a></p>
<div id="s-7.1.1.1">
<section id="section-7.1.1.1">
            <h5 id="name-point-of-capture">
<a href="#section-7.1.1.1" class="section-number selfRef">7.1.1.1. </a><a href="#name-point-of-capture" class="section-name selfRef">Point of Capture</a>
            </h5>
<p id="section-7.1.1.1-1">
   The Point of Capture attribute is a field with a single Cartesian
   (X, Y, Z) point value that describes the spatial location of the
   capturing device (such as camera).  For an Audio Capture with
   multiple microphones, the Point of Capture defines the nominal midpoint of the microphones.<a href="#section-7.1.1.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-7.1.1.2">
<section id="section-7.1.1.2">
            <h5 id="name-point-on-line-of-capture">
<a href="#section-7.1.1.2" class="section-number selfRef">7.1.1.2. </a><a href="#name-point-on-line-of-capture" class="section-name selfRef">Point on Line of Capture</a>
            </h5>
<p id="section-7.1.1.2-1">
   The Point on Line of Capture attribute is a field with a single
   Cartesian (X, Y, Z) point value that describes a position in space
   of a second point on the axis of the capturing device, toward the
   direction it is pointing; the first point being the Point of
   Capture (see above).<a href="#section-7.1.1.2-1" class="pilcrow">¶</a></p>
<p id="section-7.1.1.2-2">
   Together, the Point of Capture and Point on Line of Capture define
   the direction and axis of the capturing device, for example, the
   optical axis of a camera or the axis of a microphone.  The Media
   Consumer can use this information to adjust how it Renders the
   received Media if it so chooses.<a href="#section-7.1.1.2-2" class="pilcrow">¶</a></p>
<p id="section-7.1.1.2-3">
   For an Audio Capture, the Media Consumer can use this information
   along with the Audio Capture Sensitivity Pattern to define a three-dimensional volume of capture where sounds can be expected to be
   picked up by the microphone providing this specific Audio Capture.
   If the Consumer wants to associate an Audio Capture with a Video
   Capture, it can compare this volume with the Area of Capture for
   video Media to provide a check on whether the Audio Capture is
   indeed spatially associated with the Video Capture. For example, a
   video Area of Capture that fails to intersect at all with the audio
   volume of capture, or is at such a long radial distance from the
   microphone Point of Capture that the audio level would be very low,
   would be inappropriate.<a href="#section-7.1.1.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-7.1.1.3">
<section id="section-7.1.1.3">
            <h5 id="name-area-of-capture">
<a href="#section-7.1.1.3" class="section-number selfRef">7.1.1.3. </a><a href="#name-area-of-capture" class="section-name selfRef">Area of Capture</a>
            </h5>
<p id="section-7.1.1.3-1">
   The Area of Capture is a field with a set of four (X, Y, Z) points
   as a value that describes the spatial location of what is being
   "captured".  This attribute applies only to Video Captures, not
   other types of Media. By comparing the Area of Capture for
   different Video Captures within the same Capture Scene, a Consumer
   can determine the Spatial Relationships between them and Render
   them correctly.<a href="#section-7.1.1.3-1" class="pilcrow">¶</a></p>
<p id="section-7.1.1.3-2">
   The four points <span class="bcp14">MUST</span> be co-planar, forming a quadrilateral, which
   defines the Plane of Interest for the particular Media Capture.<a href="#section-7.1.1.3-2" class="pilcrow">¶</a></p>
<p id="section-7.1.1.3-3">
   If the Area of Capture is not specified, it means the Video Capture
   might be spatially related to other Captures in the same Scene, but
   there is no detailed information on the relationship.  For a switched
   Capture that switches between different sections within a larger
   area, the Area of Capture <span class="bcp14">MUST</span> use coordinates for the larger
   potential area.<a href="#section-7.1.1.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-7.1.1.4">
<section id="section-7.1.1.4">
            <h5 id="name-mobility-of-capture">
<a href="#section-7.1.1.4" class="section-number selfRef">7.1.1.4. </a><a href="#name-mobility-of-capture" class="section-name selfRef">Mobility of Capture</a>
            </h5>
<p id="section-7.1.1.4-1">
   The Mobility of Capture attribute indicates whether or not the
   Point of Capture, Point on Line of Capture, and Area of Capture
   values stay the same over time, or are expected to change
   (potentially frequently).  Possible values are static, dynamic, and
   highly dynamic.<a href="#section-7.1.1.4-1" class="pilcrow">¶</a></p>
<p id="section-7.1.1.4-2">
   An example for "dynamic" is a camera mounted on a stand that is
   occasionally hand-carried and placed at different positions in
   order to provide the best angle to capture a work task.  A camera
   worn by a person who moves around the room is an example for
   "highly dynamic". In either case, the effect is that the Point of Capture,
   Capture Axis, and Area of Capture change with time.<a href="#section-7.1.1.4-2" class="pilcrow">¶</a></p>
<p id="section-7.1.1.4-3">
   The Point of Capture of a static Capture <span class="bcp14">MUST NOT</span> move for the life of
   the CLUE session. The Point of Capture of dynamic Captures is
   categorized by a change in position followed by a reasonable period
   of stability -- in the order of magnitude of minutes. Highly
   dynamic Captures are categorized by a Point of Capture that is
   constantly moving.  If the Area of Capture, Point of Capture, and
   Point on Line of Capture attributes are included with dynamic or highly
   dynamic Captures, they indicate spatial information at the time of
   the Advertisement.<a href="#section-7.1.1.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-7.1.1.5">
<section id="section-7.1.1.5">
            <h5 id="name-audio-capture-sensitivity-p">
<a href="#section-7.1.1.5" class="section-number selfRef">7.1.1.5. </a><a href="#name-audio-capture-sensitivity-p" class="section-name selfRef">Audio Capture Sensitivity Pattern</a>
            </h5>
<p id="section-7.1.1.5-1">
   The Audio Capture Sensitivity Pattern attribute applies only to
   Audio Captures.  This attribute gives information about the nominal
   sensitivity pattern of the microphone that is the source of the
   Capture.  Possible values include patterns such as omni, shotgun,
   cardioid, and hyper-cardioid.<a href="#section-7.1.1.5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-7.1.1.6">
<section id="section-7.1.1.6">
            <h5 id="name-description">
<a href="#section-7.1.1.6" class="section-number selfRef">7.1.1.6. </a><a href="#name-description" class="section-name selfRef">Description</a>
            </h5>
<p id="section-7.1.1.6-1">
   The Description attribute is a human-readable description (which
   could be in multiple languages) of the Capture.<a href="#section-7.1.1.6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-7.1.1.7">
<section id="section-7.1.1.7">
            <h5 id="name-presentation">
<a href="#section-7.1.1.7" class="section-number selfRef">7.1.1.7. </a><a href="#name-presentation" class="section-name selfRef">Presentation</a>
            </h5>
<p id="section-7.1.1.7-1">
   The Presentation attribute indicates that the Capture originates
   from a presentation device, that is, one that provides supplementary
   information to a Conference through slides, video, still images,
   data, etc.  Where more information is known about the Capture, it <span class="bcp14">MAY</span>
   be expanded hierarchically to indicate the different types of
   presentation Media, e.g., presentation.slides, presentation.image,
   etc.<a href="#section-7.1.1.7-1" class="pilcrow">¶</a></p>
<p id="section-7.1.1.7-2">
   Note: It is expected that a number of keywords will be defined that
   provide more detail on the type of presentation. Refer to <span>[<a href="#RFC8846" class="xref">RFC8846</a>]</span> for how to extend the model.<a href="#section-7.1.1.7-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-7.1.1.8">
<section id="section-7.1.1.8">
            <h5 id="name-view">
<a href="#section-7.1.1.8" class="section-number selfRef">7.1.1.8. </a><a href="#name-view" class="section-name selfRef">View</a>
            </h5>
<p id="section-7.1.1.8-1">
   The View attribute is a field with enumerated values, indicating
   what type of view the Capture relates to.  The Consumer can use
   this information to help choose which Media Captures it wishes to
   receive.  Possible values are as follows:<a href="#section-7.1.1.8-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.1.1.8-2">
              <dt id="section-7.1.1.8-2.1">Room:</dt>
              <dd style="margin-left: 6.0em" id="section-7.1.1.8-2.2">Captures the entire Scene<a href="#section-7.1.1.8-2.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.1.1.8-2.3">Table:</dt>
              <dd style="margin-left: 6.0em" id="section-7.1.1.8-2.4">Captures the conference table with seated people<a href="#section-7.1.1.8-2.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.1.1.8-2.5">Individual:</dt>
              <dd style="margin-left: 6.0em" id="section-7.1.1.8-2.6">Captures an individual person<a href="#section-7.1.1.8-2.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.1.1.8-2.7">Lectern:</dt>
              <dd style="margin-left: 6.0em" id="section-7.1.1.8-2.8">Captures the region of the lectern including the
 presenter, for example, in a classroom-style conference room<a href="#section-7.1.1.8-2.8" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.1.1.8-2.9">Audience:</dt>
              <dd style="margin-left: 6.0em" id="section-7.1.1.8-2.10">Captures a region showing the audience in a classroom-style conference room<a href="#section-7.1.1.8-2.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</section>
</div>
<div id="s-7.1.1.9">
<section id="section-7.1.1.9">
            <h5 id="name-language">
<a href="#section-7.1.1.9" class="section-number selfRef">7.1.1.9. </a><a href="#name-language" class="section-name selfRef">Language</a>
            </h5>
<p id="section-7.1.1.9-1">
   The Language attribute indicates one or more languages used in the
   content of the Media Capture.  Captures <span class="bcp14">MAY</span> be offered in different
   languages in case of multilingual and/or accessible Conferences.  A
   Consumer can use this attribute to differentiate between them and
   pick the appropriate one.<a href="#section-7.1.1.9-1" class="pilcrow">¶</a></p>
<p id="section-7.1.1.9-2">
   Note that the Language attribute is defined and meaningful both for
   Audio and Video Captures.  In case of Audio Captures, the meaning
   is obvious.  For a Video Capture, "Language" could, for example, be
   sign interpretation or text.<a href="#section-7.1.1.9-2" class="pilcrow">¶</a></p>
<p id="section-7.1.1.9-3">
   The Language attribute is coded per <span>[<a href="#RFC5646" class="xref">RFC5646</a>]</span>.<a href="#section-7.1.1.9-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-7.1.1.10">
<section id="section-7.1.1.10">
            <h5 id="name-person-information">
<a href="#section-7.1.1.10" class="section-number selfRef">7.1.1.10. </a><a href="#name-person-information" class="section-name selfRef">Person Information</a>
            </h5>
<p id="section-7.1.1.10-1">
   The Person Information attribute allows a Provider to provide
   specific information regarding the people in a Capture (regardless
   of whether or not the Capture has a Presentation attribute). The
   Provider may gather the information automatically or manually from
   a variety of sources; however, the xCard <span>[<a href="#RFC6351" class="xref">RFC6351</a>]</span> format is used to
   convey the information. This allows various information, such as
   Identification information (<span><a href="https://www.rfc-editor.org/rfc/rfc6350#section-6.2" class="relref">Section 6.2</a> of [<a href="#RFC6350" class="xref">RFC6350</a>]</span>), Communication
   Information (<span><a href="https://www.rfc-editor.org/rfc/rfc6350#section-6.4" class="relref">Section 6.4</a> of [<a href="#RFC6350" class="xref">RFC6350</a>]</span>), and Organizational information
   (<span><a href="https://www.rfc-editor.org/rfc/rfc6350#section-6.6" class="relref">Section 6.6</a> of [<a href="#RFC6350" class="xref">RFC6350</a>]</span>), to be communicated. A Consumer may then
   automatically (i.e., via a policy) or manually select Captures
   based on information about who is in a Capture. It also allows a
   Consumer to Render information regarding the people participating
   in the Conference or to use it for further processing.<a href="#section-7.1.1.10-1" class="pilcrow">¶</a></p>
<p id="section-7.1.1.10-2">
   The Provider may supply a minimal set of information or a larger
   set of information. However, it <span class="bcp14">MUST</span> be compliant to <span>[<a href="#RFC6350" class="xref">RFC6350</a>]</span> and
   supply a "VERSION" and "FN" property. A Provider may supply
   multiple xCards per Capture of any KIND (<span><a href="https://www.rfc-editor.org/rfc/rfc6350#section-6.1.4" class="relref">Section 6.1.4</a> of [<a href="#RFC6350" class="xref">RFC6350</a>]</span>).<a href="#section-7.1.1.10-2" class="pilcrow">¶</a></p>
<p id="section-7.1.1.10-3">
   In order to keep CLUE messages compact, the Provider <span class="bcp14">SHOULD</span> use a
   URI to point to any LOGO, PHOTO, or SOUND contained in the xCard
   rather than transmitting the LOGO, PHOTO, or SOUND data in a CLUE
   message.<a href="#section-7.1.1.10-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-7.1.1.11">
<section id="section-7.1.1.11">
            <h5 id="name-person-type">
<a href="#section-7.1.1.11" class="section-number selfRef">7.1.1.11. </a><a href="#name-person-type" class="section-name selfRef">Person Type</a>
            </h5>
<p id="section-7.1.1.11-1">
   The Person Type attribute indicates the type of people contained in
   the Capture with respect to the meeting agenda (regardless of
   whether or not the Capture has a Presentation attribute). As a
   Capture may include multiple people, the attribute may contain
   multiple values. However, values <span class="bcp14">MUST NOT</span> be repeated within the
   attribute.<a href="#section-7.1.1.11-1" class="pilcrow">¶</a></p>
<p id="section-7.1.1.11-2">
   An Advertiser associates the person type with an individual Capture
   when it knows that a particular type is in the Capture. If an
   Advertiser cannot link a particular type with some certainty to a
   Capture, then it is not included. On reception of a
   Capture with a Person Type attribute, a Consumer knows with some certainty that
   the Capture contains that person type. The Capture may contain
   other person types, but the Advertiser has not been able to
   determine that this is the case.<a href="#section-7.1.1.11-2" class="pilcrow">¶</a></p>
<p id="section-7.1.1.11-3">The types of Captured people include:<a href="#section-7.1.1.11-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.1.1.11-4">
              <dt id="section-7.1.1.11-4.1">Chair:</dt>
              <dd style="margin-left: 7.5em" id="section-7.1.1.11-4.2">the person responsible for running the meeting
        according to the agenda.<a href="#section-7.1.1.11-4.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.1.1.11-4.3">Vice-Chair:</dt>
              <dd style="margin-left: 7.5em" id="section-7.1.1.11-4.4">the person responsible for assisting the chair in
        running the meeting.<a href="#section-7.1.1.11-4.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.1.1.11-4.5">Minute Taker:</dt>
              <dd style="margin-left: 7.5em" id="section-7.1.1.11-4.6">the person responsible for recording the
        minutes of the meeting.<a href="#section-7.1.1.11-4.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.1.1.11-4.7">Attendee:</dt>
              <dd style="margin-left: 7.5em" id="section-7.1.1.11-4.8">the person has no particular responsibilities with
        respect to running the meeting.<a href="#section-7.1.1.11-4.8" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.1.1.11-4.9">Observer:</dt>
              <dd style="margin-left: 7.5em" id="section-7.1.1.11-4.10">an Attendee without the right to influence the
        discussion.<a href="#section-7.1.1.11-4.10" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.1.1.11-4.11">Presenter:</dt>
              <dd style="margin-left: 7.5em" id="section-7.1.1.11-4.12">the person scheduled on the agenda to make a
        presentation in the meeting. Note: This is not related to any
        "active speaker" functionality.<a href="#section-7.1.1.11-4.12" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.1.1.11-4.13">Translator:</dt>
              <dd style="margin-left: 7.5em" id="section-7.1.1.11-4.14">the person providing some form of translation
        or commentary in the meeting.<a href="#section-7.1.1.11-4.14" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.1.1.11-4.15">Timekeeper:</dt>
              <dd style="margin-left: 7.5em" id="section-7.1.1.11-4.16">the person responsible for maintaining the
        meeting schedule.<a href="#section-7.1.1.11-4.16" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
<p id="section-7.1.1.11-5">
   Furthermore, the Person Type attribute may contain one or more
   strings allowing the Provider to indicate custom meeting-specific
   types.<a href="#section-7.1.1.11-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-7.1.1.12">
<section id="section-7.1.1.12">
            <h5 id="name-priority">
<a href="#section-7.1.1.12" class="section-number selfRef">7.1.1.12. </a><a href="#name-priority" class="section-name selfRef">Priority</a>
            </h5>
<p id="section-7.1.1.12-1">
   The Priority attribute indicates a relative priority between
   different Media Captures.  The Provider sets this priority, and the
   Consumer <span class="bcp14">MAY</span> use the priority to help decide which Captures it
   wishes to receive.<a href="#section-7.1.1.12-1" class="pilcrow">¶</a></p>
<p id="section-7.1.1.12-2">
   The Priority attribute is an integer that indicates a relative
   priority between Captures. For example, it is possible to assign a
   priority between two presentation Captures that would allow a
   remote Endpoint to determine which presentation is more important.
   Priority is assigned at the individual Capture level. It represents
   the Provider's view of the relative priority between Captures with
   a priority. The same priority number <span class="bcp14">MAY</span> be used across multiple
   Captures. It indicates that they are equally important. If no priority
   is assigned, no assumptions regarding relative importance of the
   Capture can be assumed.<a href="#section-7.1.1.12-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-7.1.1.13">
<section id="section-7.1.1.13">
            <h5 id="name-embedded-text">
<a href="#section-7.1.1.13" class="section-number selfRef">7.1.1.13. </a><a href="#name-embedded-text" class="section-name selfRef">Embedded Text</a>
            </h5>
<p id="section-7.1.1.13-1">
   The Embedded Text attribute indicates that a Capture provides
   embedded textual information. For example, the Video Capture may
   contain speech-to-text information composed with the video image.<a href="#section-7.1.1.13-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-7.1.1.14">
<section id="section-7.1.1.14">
            <h5 id="name-related-to">
<a href="#section-7.1.1.14" class="section-number selfRef">7.1.1.14. </a><a href="#name-related-to" class="section-name selfRef">Related To</a>
            </h5>
<p id="section-7.1.1.14-1">
   The Related To attribute indicates the Capture contains additional
   complementary information related to another Capture.  The value
   indicates the identity of the other Capture to which this Capture
   is providing additional information.<a href="#section-7.1.1.14-1" class="pilcrow">¶</a></p>
<p id="section-7.1.1.14-2">
   For example, a Conference can utilize translators or facilitators
   that provide an additional audio Stream (i.e., a translation or
   description or commentary of the Conference).  Where multiple
   Captures are available, it may be advantageous for a Consumer to
   select a complementary Capture instead of or in addition to a
   Capture it relates to.<a href="#section-7.1.1.14-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="s-7.2">
<section id="section-7.2">
        <h3 id="name-multiple-content-capture">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-multiple-content-capture" class="section-name selfRef">Multiple Content Capture</a>
        </h3>
<p id="section-7.2-1">
   The MCC indicates that one or more Single Media Captures are
   multiplexed (temporally and/or spatially) or mixed in one Media
   Capture.  Only one Capture type (i.e., audio, video, etc.) is
   allowed in each MCC instance.  The MCC may contain a reference to
   the Single Media Captures (which may have their own attributes) as
   well as attributes associated with the MCC itself.  An MCC may also
   contain other MCCs.  The MCC <span class="bcp14">MAY</span> reference Captures from within the
   Capture Scene that defines it or from other Capture Scenes.  No
   ordering is implied by the order that Captures appear within an MCC.
   An MCC <span class="bcp14">MAY</span> contain no references to other Captures to indicate that
   the MCC contains content from multiple sources, but no information
   regarding those sources is given. MCCs either contain the
   referenced Captures and no others or have no referenced Captures
   and, therefore, may contain any Capture.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">
   One or more MCCs may also be specified in a CSV.  This allows an
   Advertiser to indicate that several MCC Captures are used to
   represent a Capture Scene.  <a href="#ref-advertisement-sent-to-endpoint-f-two-encodings" class="xref">Table 14</a> provides an example of this
   case.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
<p id="section-7.2-3">
   As outlined in <a href="#s-7.1" class="xref">Section 7.1</a>, each instance of the MCC has its own
   Capture identity, i.e., MCC1.  It allows all the individual Captures
   contained in the MCC to be referenced by a single MCC identity.<a href="#section-7.2-3" class="pilcrow">¶</a></p>
<p id="section-7.2-4">The example below shows the use of a Multiple Content Capture:<a href="#section-7.2-4" class="pilcrow">¶</a></p>
<span id="name-multiple-content-capture-co"></span><div id="ref-multiple-content-capture-concept">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-multiple-content-capture-co" class="selfRef">Multiple Content Capture Concept</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1"> Capture Scene #1</th>
              <th class="text-left" rowspan="1" colspan="1"> </th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">VC1</td>
              <td class="text-left" rowspan="1" colspan="1">{MC attributes}</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">VC2</td>
              <td class="text-left" rowspan="1" colspan="1">{MC attributes}</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">VC3</td>
              <td class="text-left" rowspan="1" colspan="1">{MC attributes}</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">MCC1(VC1,VC2,VC3)</td>
              <td class="text-left" rowspan="1" colspan="1">{MC and MCC attributes}</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">CSV(MCC1)</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-7.2-6">
   This indicates that MCC1 is a single Capture that contains the
   Captures VC1, VC2, and VC3, according to any MCC1 attributes.<a href="#section-7.2-6" class="pilcrow">¶</a></p>
<div id="s-7.2.1">
<section id="section-7.2.1">
          <h4 id="name-mcc-attributes">
<a href="#section-7.2.1" class="section-number selfRef">7.2.1. </a><a href="#name-mcc-attributes" class="section-name selfRef">MCC Attributes</a>
          </h4>
<p id="section-7.2.1-1">
   Media Capture attributes may be associated with the MCC instance
   and the Single Media Captures that the MCC references.  A Provider
   should avoid providing conflicting attribute values between the MCC
   and Single Media Captures. Where there is conflict the attributes
   of the MCC, a Provider should override any that may be present in the individual
   Captures.<a href="#section-7.2.1-1" class="pilcrow">¶</a></p>
<p id="section-7.2.1-2">
   A Provider <span class="bcp14">MAY</span> include as much or as little of the original source
   Capture information as it requires.<a href="#section-7.2.1-2" class="pilcrow">¶</a></p>
<p id="section-7.2.1-3">
   There are MCC-specific attributes that <span class="bcp14">MUST</span> only be used with
   Multiple Content Captures. These are described in the sections
   below. The attributes described in <a href="#s-7.1.1" class="xref">Section 7.1.1</a> <span class="bcp14">MAY</span> also be used
   with MCCs.<a href="#section-7.2.1-3" class="pilcrow">¶</a></p>
<p id="section-7.2.1-4">
   The spatial-related attributes of an MCC indicate its Area of
   Capture and Point of Capture within the Scene, just like any other
   Media Capture.  The spatial information does not imply anything
   about how other Captures are composed within an MCC.<a href="#section-7.2.1-4" class="pilcrow">¶</a></p>
<p id="section-7.2.1-5">For example: a virtual Scene could be constructed for the MCC
 Capture with two Video Captures with a MaxCaptures attribute set
   to 2 and an Area of Capture attribute provided with an overall
   area.  Each of the individual Captures could then also include an
   Area of Capture attribute with a subset of the overall area.
   The Consumer would then know how each Capture is related to others
   within the Scene, but not the relative position of the individual
   Captures within the composed Capture.<a href="#section-7.2.1-5" class="pilcrow">¶</a></p>
<span id="name-example-of-mcc-and-single-m"></span><div id="table_2">
<table class="center" id="table-2">
            <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-example-of-mcc-and-single-m" class="selfRef">Example of MCC and Single Media Capture Attributes</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #1</th>
                <th class="text-left" rowspan="1" colspan="1"></th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC1</td>
                <td class="text-right" rowspan="1" colspan="1">
                  <ul class="text-right ulEmpty compact">
<li class="text-right ulEmpty compact" id="section-7.2.1-6.2.1.2.1.1">AreaofCapture=(0,0,0)(9,0,0)<a href="#section-7.2.1-6.2.1.2.1.1" class="pilcrow">¶</a>
</li>
                    <li class="text-right ulEmpty compact" id="section-7.2.1-6.2.1.2.1.2">(0,0,9)(9,0,9)<a href="#section-7.2.1-6.2.1.2.1.2" class="pilcrow">¶</a>
</li>
                  </ul>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC2</td>
                <td class="text-right" rowspan="1" colspan="1">
                  <ul class="text-right ulEmpty compact">
<li class="text-right ulEmpty compact" id="section-7.2.1-6.2.2.2.1.1">AreaofCapture=(10,0,0)(19,0,0)<a href="#section-7.2.1-6.2.2.2.1.1" class="pilcrow">¶</a>
</li>
                    <li class="text-right ulEmpty compact" id="section-7.2.1-6.2.2.2.1.2">(10,0,9)(19,0,9)<a href="#section-7.2.1-6.2.2.2.1.2" class="pilcrow">¶</a>
</li>
                  </ul>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC1(VC1,VC2)</td>
                <td class="text-right" rowspan="1" colspan="1">
                  <ul class="text-right ulEmpty compact">
<li class="text-right ulEmpty compact" id="section-7.2.1-6.2.3.2.1.1">MaxCaptures=2<a href="#section-7.2.1-6.2.3.2.1.1" class="pilcrow">¶</a>
</li>
                    <li class="text-right ulEmpty compact" id="section-7.2.1-6.2.3.2.1.2">AreaofCapture=(0,0,0)(19,0,0)<a href="#section-7.2.1-6.2.3.2.1.2" class="pilcrow">¶</a>
</li>
                    <li class="text-right ulEmpty compact" id="section-7.2.1-6.2.3.2.1.3">(0,0,9)(19,0,9)<a href="#section-7.2.1-6.2.3.2.1.3" class="pilcrow">¶</a>
</li>
                  </ul>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(MCC1)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-7.2.1-7">
   The subsections below describe the MCC-only attributes.<a href="#section-7.2.1-7" class="pilcrow">¶</a></p>
<div id="s-7.2.1.1">
<section id="section-7.2.1.1">
            <h5 id="name-maxcapture-maximum-number-o">
<a href="#section-7.2.1.1" class="section-number selfRef">7.2.1.1. </a><a href="#name-maxcapture-maximum-number-o" class="section-name selfRef">MaxCapture: Maximum Number of Captures within an MCC</a>
            </h5>
<p id="section-7.2.1.1-1">
   The MaxCaptures attribute indicates the maximum
   number of individual Captures that may appear in a Capture Encoding
   at a time.  The actual number at any given time can be less than or
   equal to this maximum.  It may be used to derive how the Single
   Media Captures within the MCC are composed/switched with regard
   to space and time.<a href="#section-7.2.1.1-1" class="pilcrow">¶</a></p>
<p id="section-7.2.1.1-2">
   A Provider can indicate that the number of Captures in an MCC
   Capture Encoding is equal ("=") to the MaxCaptures value or that
   there may be any number of Captures up to and including ("&lt;=") the
   MaxCaptures value. This allows a Provider to distinguish between an
   MCC that purely represents a composition of sources and an MCC
   that represents switched sources or switched and composed sources.<a href="#section-7.2.1.1-2" class="pilcrow">¶</a></p>
<p id="section-7.2.1.1-3">
   MaxCaptures may be set to one so that only content related to one
   of the sources is shown in the MCC Capture Encoding at a time, or
   it may be set to any value up to the total number of Source Media
   Captures in the MCC.<a href="#section-7.2.1.1-3" class="pilcrow">¶</a></p>
<p id="section-7.2.1.1-4">
   The bullets below describe how the setting of MaxCaptures versus the
   number of Captures in the MCC affects how sources appear in a
   Capture Encoding:<a href="#section-7.2.1.1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.2.1.1-5.1">A switched case occurs when
 MaxCaptures is set to &lt;= 1 and the number of Captures in
 the MCC is greater than 1 (or not specified) in the MCC. Zero
 or one Captures may be switched into the Capture Encoding. Note:
 zero is allowed because of the "&lt;=".<a href="#section-7.2.1.1-5.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-7.2.1.1-5.2">A switched case occurs when MaxCaptures is set to = 1 and
 the number of Captures in the MCC is greater than 1 (or not
 specified) in the MCC. Only one Capture source is contained in
 a Capture Encoding at a time.<a href="#section-7.2.1.1-5.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-7.2.1.1-5.3">A switched and composed case occurs when MaxCaptures is set
 to &lt;= N (with N &gt; 1) and the number of Captures in the
 MCC is greater than N (or not specified). The Capture Encoding
 may contain purely switched sources (i.e., &lt;=2 allows for one
 source on its own), or it may contain composed and switched
 sources (i.e., a composition of two sources switched between the
 sources).<a href="#section-7.2.1.1-5.3" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-7.2.1.1-5.4">A switched and composed case occurs when MaxCaptures is set
 to = N (with N &gt; 1) and the number of Captures in the MCC
 is greater than N (or not specified).  The Capture Encoding
 contains composed and switched sources (i.e., a composition of
 N sources switched between the sources). It is not possible to
 have a single source.<a href="#section-7.2.1.1-5.4" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-7.2.1.1-5.5">A switched and composed case occurs when MaxCaptures is set
 &lt;= to the number of Captures in the MCC. The Capture
 Encoding may contain Media switched between any number (up to
 the MaxCaptures) of composed sources.<a href="#section-7.2.1.1-5.5" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-7.2.1.1-5.6">A composed case occurs when MaxCaptures is set = to the number of Captures in the
        MCC. All the sources are composed into
        a single Capture Encoding.<a href="#section-7.2.1.1-5.6" class="pilcrow">¶</a>
</li>
            </ul>
<p id="section-7.2.1.1-6">
   If this attribute is not set, then as a default, it is assumed that all
   source Media Capture content can appear concurrently in the Capture
   Encoding associated with the MCC.<a href="#section-7.2.1.1-6" class="pilcrow">¶</a></p>
<p id="section-7.2.1.1-7">
   For example, the use of MaxCaptures equal to 1 on an MCC with three
   Video Captures, VC1, VC2, and VC3, would indicate that the Advertiser
   in the Capture Encoding would switch between VC1, VC2, and VC3 as
   there may be only a maximum of one Capture at a time.<a href="#section-7.2.1.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-7.2.1.2">
<section id="section-7.2.1.2">
            <h5 id="name-policy">
<a href="#section-7.2.1.2" class="section-number selfRef">7.2.1.2. </a><a href="#name-policy" class="section-name selfRef">Policy</a>
            </h5>
<p id="section-7.2.1.2-1">
   The Policy MCC attribute indicates the criteria that the Provider
   uses to determine when and/or where Media content appears in the
   Capture Encoding related to the MCC.<a href="#section-7.2.1.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2.1.2-2">
   The attribute is in the form of a token that indicates the policy
   and an index representing an instance of the policy.  The same
   index value can be used for multiple MCCs.<a href="#section-7.2.1.2-2" class="pilcrow">¶</a></p>
<p id="section-7.2.1.2-3">
   The tokens are as follows:<a href="#section-7.2.1.2-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.2.1.2-4">
              <dt id="section-7.2.1.2-4.1">SoundLevel:</dt>
              <dd style="margin-left: 1.5em" id="section-7.2.1.2-4.2">This indicates that the content of the MCC is
   determined by a sound-level-detection algorithm. The loudest
   (active) speaker (or a previous speaker, depending on the index
   value) is contained in the MCC.<a href="#section-7.2.1.2-4.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.2.1.2-4.3">RoundRobin:</dt>
              <dd style="margin-left: 1.5em" id="section-7.2.1.2-4.4">This indicates that the content of the MCC is
   determined by a time-based algorithm. For example, the Provider
   provides content from a particular source for a period of time and
   then provides content from another source, and so on.<a href="#section-7.2.1.2-4.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
<p id="section-7.2.1.2-5">
   An index is used to represent an instance in the policy setting. An
   index of 0 represents the most current instance of the policy, i.e.,
   the active speaker, 1 represents the previous instance, i.e., the
   previous active speaker, and so on.<a href="#section-7.2.1.2-5" class="pilcrow">¶</a></p>
<p id="section-7.2.1.2-6">
   The following example shows a case where the Provider provides two
   Media Streams, one showing the active speaker and a second Stream
   showing the previous speaker.<a href="#section-7.2.1.2-6" class="pilcrow">¶</a></p>
<span id="name-example-policy-mcc-attribut"></span><div id="ref-example-policy-mcc-attribute-usage">
<table class="center" id="table-3">
              <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-example-policy-mcc-attribut" class="selfRef">Example Policy MCC Attribute Usage</a>
              </caption>
<thead>
                <tr>
                  <th class="text-left" rowspan="1" colspan="1"> Capture Scene #1</th>
                  <th class="text-left" rowspan="1" colspan="1"> </th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">VC1</td>
                  <td class="text-left" rowspan="1" colspan="1"></td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">VC2</td>
                  <td class="text-left" rowspan="1" colspan="1"></td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">MCC1(VC1,VC2)</td>
                  <td class="text-left" rowspan="1" colspan="1">Policy=SoundLevel:0<br>
   MaxCaptures=1</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">MCC2(VC1,VC2)</td>
                  <td class="text-left" rowspan="1" colspan="1">Policy=SoundLevel:1<br>
   MaxCaptures=1</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">CSV(MCC1,MCC2)</td>
                  <td class="text-left" rowspan="1" colspan="1"></td>
                </tr>
              </tbody>
            </table>
</div>
</section>
</div>
<div id="s-7.2.1.3">
<section id="section-7.2.1.3">
            <h5 id="name-synchronizationid-synchroni">
<a href="#section-7.2.1.3" class="section-number selfRef">7.2.1.3. </a><a href="#name-synchronizationid-synchroni" class="section-name selfRef">SynchronizationID: Synchronization Identity</a>
            </h5>
<p id="section-7.2.1.3-1">
   The SynchronizationID MCC attribute indicates how the
   individual Captures in multiple MCC Captures are synchronized.  To
   indicate that the Capture Encodings associated with MCCs contain
   Captures from the same source at the same time, a Provider should
   set the same SynchronizationID on each of the concerned
   MCCs.  It is the Provider that determines what the source for the
   Captures is, so a Provider can choose how to group together Single
   Media Captures into a combined "source" for the purpose of
   switching them together to keep them synchronized according to the
   SynchronizationID attribute.  For example, when the Provider is in
   an MCU, it may determine that each separate CLUE Endpoint is a
   remote source of Media. The SynchronizationID may be used
   across Media types, i.e., to synchronize audio- and video-related
   MCCs.<a href="#section-7.2.1.3-1" class="pilcrow">¶</a></p>
<p id="section-7.2.1.3-2">
   Without this attribute it is assumed that multiple MCCs may provide
   content from different sources at any particular point in time.<a href="#section-7.2.1.3-2" class="pilcrow">¶</a></p>
<p id="section-7.2.1.3-3">For example:<a href="#section-7.2.1.3-3" class="pilcrow">¶</a></p>
<span id="name-example-synchronizationid-m"></span><div id="table_4">
<table class="center" id="table-4">
              <caption>
<a href="#table-4" class="selfRef">Table 4</a>:
<a href="#name-example-synchronizationid-m" class="selfRef">Example SynchronizationID MCC Attribute Usage</a>
              </caption>
<tbody>
                <tr>
                  <th class="text-left" rowspan="1" colspan="1">Capture Scene #1</th>
                  <th class="text-left" rowspan="1" colspan="1"></th>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">VC1</td>
                  <td class="text-left" rowspan="1" colspan="1">Description=Left</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">VC2</td>
                  <td class="text-left" rowspan="1" colspan="1">Description=Center</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">VC3</td>
                  <td class="text-left" rowspan="1" colspan="1">Description=Right</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">AC1</td>
                  <td class="text-left" rowspan="1" colspan="1">Description=Room</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">CSV(VC1,VC2,VC3)</td>
                  <td class="text-left" rowspan="1" colspan="1"></td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">CSV(AC1)</td>
                  <td class="text-left" rowspan="1" colspan="1"></td>
                </tr>
              </tbody>
              <tbody>
                <tr>
                  <th class="text-left" rowspan="1" colspan="1">Capture Scene #2</th>
                  <th class="text-left" rowspan="1" colspan="1"></th>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">VC4</td>
                  <td class="text-left" rowspan="1" colspan="1">Description=Left</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">VC5</td>
                  <td class="text-left" rowspan="1" colspan="1">Description=Center</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">VC6</td>
                  <td class="text-left" rowspan="1" colspan="1">Description=Right</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">AC2</td>
                  <td class="text-left" rowspan="1" colspan="1">Description=Room</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">CSV(VC4,VC5,VC6)</td>
                  <td class="text-left" rowspan="1" colspan="1"></td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">CSV(AC2)</td>
                  <td class="text-left" rowspan="1" colspan="1"></td>
                </tr>
              </tbody>
              <tbody>
                <tr>
                  <th class="text-left" rowspan="1" colspan="1">Capture Scene #3</th>
                  <th class="text-left" rowspan="1" colspan="1"></th>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">VC7</td>
                  <td class="text-left" rowspan="1" colspan="1"></td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">AC3</td>
                  <td class="text-left" rowspan="1" colspan="1"></td>
                </tr>
              </tbody>
              <tbody>
                <tr>
                  <th class="text-left" rowspan="1" colspan="1">Capture Scene #4</th>
                  <th class="text-left" rowspan="1" colspan="1"></th>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">VC8</td>
                  <td class="text-left" rowspan="1" colspan="1"></td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">AC4</td>
                  <td class="text-left" rowspan="1" colspan="1"></td>
                </tr>
              </tbody>
              <tbody>
                <tr>
                  <th class="text-left" rowspan="1" colspan="1">Capture Scene #5</th>
                  <th class="text-left" rowspan="1" colspan="1"></th>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">MCC1(VC1,VC4,VC7)</td>
                  <td class="text-left" rowspan="1" colspan="1">SynchronizationID=1<br>MaxCaptures=1</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">MCC2(VC2,VC5,VC8)</td>
                  <td class="text-left" rowspan="1" colspan="1">SynchronizationID=1<br>MaxCaptures=1</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">MCC3(VC3,VC6)</td>
                  <td class="text-left" rowspan="1" colspan="1">MaxCaptures=1</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">MCC4(AC1,AC2,AC3,AC4)</td>
                  <td class="text-left" rowspan="1" colspan="1">SynchronizationID=1<br>MaxCaptures=1</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">CSV(MCC1,MCC2,MCC3)</td>
                  <td class="text-left" rowspan="1" colspan="1"></td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">CSV(MCC4)</td>
                  <td class="text-left" rowspan="1" colspan="1"></td>
                </tr>
              </tbody>
            </table>
</div>
<p id="section-7.2.1.3-5">
   The above Advertisement would indicate that MCC1, MCC2, MCC3, and
   MCC4 make up a Capture Scene.  There would be four Capture
   Encodings (one for each MCC).  Because MCC1 and MCC2 have the same
   SynchronizationID, each Encoding from MCC1 and MCC2, respectively,
   would together have content from only Capture Scene 1 or only
   Capture Scene 2 or the combination of VC7 and VC8 at a particular
   point in time.  In this case, the Provider has decided the sources
   to be synchronized are Scene #1, Scene #2, and Scene #3 and #4
   together. The Encoding from MCC3 would not be synchronized with
   MCC1 or MCC2. As MCC4 also has the same SynchronizationID
   as MCC1 and MCC2, the content of the audio Encoding will be
   synchronized with the video content.<a href="#section-7.2.1.3-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-7.2.1.4">
<section id="section-7.2.1.4">
            <h5 id="name-allow-subset-choice">
<a href="#section-7.2.1.4" class="section-number selfRef">7.2.1.4. </a><a href="#name-allow-subset-choice" class="section-name selfRef">Allow Subset Choice</a>
            </h5>
<p id="section-7.2.1.4-1">
   The Allow Subset Choice MCC attribute is a boolean value,
   indicating whether or not the Provider allows the Consumer to
   choose a specific subset of the Captures referenced by the MCC.
   If this attribute is true, and the MCC references other Captures,
   then the Consumer <span class="bcp14">MAY</span> select (in a Configure message) a specific
   subset of those Captures to be included in the MCC, and the
   Provider <span class="bcp14">MUST</span> then include only that subset.  If this attribute is
   false, or the MCC does not reference other Captures, then the
   Consumer <span class="bcp14">MUST NOT</span> select a subset.<a href="#section-7.2.1.4-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="s-7.3">
<section id="section-7.3">
        <h3 id="name-capture-scene">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-capture-scene" class="section-name selfRef">Capture Scene</a>
        </h3>
<p id="section-7.3-1">
   In order for a Provider's individual Captures to be used
   effectively by a Consumer, the Provider organizes the Captures into
   one or more Capture Scenes, with the structure and contents of
   these Capture Scenes being sent from the Provider to the Consumer
   in the Advertisement.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<p id="section-7.3-2">
   A Capture Scene is a structure representing a spatial region
   containing one or more Capture Devices, each capturing Media
   representing a portion of the region.  A Capture Scene includes one
   or more Capture Scene Views (CSVs), with each CSV including one or
   more Media Captures of the same Media type.  There can also be
   Media Captures that are not included in a CSV. A
   Capture Scene represents, for example, the video image of a group
   of people seated next to each other, along with the sound of their
   voices, which could be represented by some number of VCs and ACs in
   the CSVs.  An MCU can also describe in Capture
   Scenes what it constructs from Media Streams it receives.<a href="#section-7.3-2" class="pilcrow">¶</a></p>
<p id="section-7.3-3">
   A Provider <span class="bcp14">MAY</span> advertise one or more Capture Scenes.  What
   constitutes an entire Capture Scene is up to the Provider.  A
   simple Provider might typically use one Capture Scene for
   participant Media (live video from the room cameras) and another
   Capture Scene for a computer-generated presentation.  In more-complex systems, the use of additional Capture Scenes is also
   sensible.  For example, a classroom may advertise two Capture
   Scenes involving live video: one including only the camera
   capturing the instructor (and associated audio) the other
   including camera(s) capturing students (and associated audio).<a href="#section-7.3-3" class="pilcrow">¶</a></p>
<p id="section-7.3-4">
   A Capture Scene <span class="bcp14">MAY</span> (and typically will) include more than one type
   of Media.  For example, a Capture Scene can include several CSVs
   for Video Captures and several CSVs for
   Audio Captures.  A particular Capture <span class="bcp14">MAY</span> be included in more than
   one CSV.<a href="#section-7.3-4" class="pilcrow">¶</a></p>
<p id="section-7.3-5">
   A Provider <span class="bcp14">MAY</span> express Spatial Relationships between Captures that
   are included in the same Capture Scene.  However, there is no
   Spatial Relationship between Media Captures from different Capture
   Scenes.  In other words, Capture Scenes each use their own spatial
   measurement system as outlined in <a href="#s-6" class="xref">Section 6</a>.<a href="#section-7.3-5" class="pilcrow">¶</a></p>
<p id="section-7.3-6">
   A Provider arranges Captures in a Capture Scene to help the
   Consumer choose which Captures it wants to Render.  The CSVs
   in a Capture Scene are different alternatives the
   Provider is suggesting for representing the Capture Scene.  Each
   CSV is given an advertisement-unique identity.  The
   order of CSVs within a Capture Scene has no
   significance.  The Media Consumer can choose to receive all Media
   Captures from one CSV for each Media type (e.g.,
   audio and video), or it can pick and choose Media Captures
   regardless of how the Provider arranges them in CSVs.
   Different CSVs of the same Media type are
   not necessarily mutually exclusive alternatives.  Also note that
   the presence of multiple CSVs (with potentially
   multiple Encoding options in each view) in a given Capture Scene
   does not necessarily imply that a Provider is able to serve all the
   associated Media simultaneously (although the construction of such
   an over-rich Capture Scene is probably not sensible in many cases).
   What a Provider can send simultaneously is determined through the
   Simultaneous Transmission Set mechanism, described in <a href="#s-8" class="xref">Section 8</a>.<a href="#section-7.3-6" class="pilcrow">¶</a></p>
<p id="section-7.3-7">
   Captures within the same CSV <span class="bcp14">MUST</span> be of the same
   Media type -- it is not possible to mix audio and Video Captures in
   the same CSV, for instance.  The Provider <span class="bcp14">MUST</span> be
   capable of encoding and sending all Captures (that have an Encoding
   Group) in a single CSV simultaneously.  The order of
   Captures within a CSV has no significance.  A
   Consumer can decide to receive all the Captures in a single CSV,
   but a Consumer could also decide to receive just a
   subset of those Captures.  A Consumer can also decide to receive
   Captures from different CSVs, all subject to the
   constraints set by Simultaneous Transmission Sets, as discussed in
   <a href="#s-8" class="xref">Section 8</a>.<a href="#section-7.3-7" class="pilcrow">¶</a></p>
<p id="section-7.3-8">
   When a Provider advertises a Capture Scene with multiple CSVs, it
   is essentially signaling that there are multiple representations of
   the same Capture Scene available.  In some cases, these multiple
   views would be used simultaneously (for instance, a "video view" and
   an "audio view").  In some cases, the views would conceptually be
   alternatives (for instance, a view consisting of three Video
   Captures covering the whole room versus a view consisting of just a
   single Video Capture covering only the center of a room).  In this
   latter example, one sensible choice for a Consumer would be to
   indicate (through its Configure and possibly through an additional
   offer/answer exchange) the Captures of that CSV that
   most closely matched the Consumer's number of display devices or
   screen layout.<a href="#section-7.3-8" class="pilcrow">¶</a></p>
<p id="section-7.3-9">
   The following is an example of four potential CSVs for
   an Endpoint-style Provider:<a href="#section-7.3-9" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-7.3-10">
          <li id="section-7.3-10.1">(VC0, VC1, VC2) - left, center, and right camera Video Captures<a href="#section-7.3-10.1" class="pilcrow">¶</a>
</li>
          <li id="section-7.3-10.2">(MCC3) - Video Capture associated with loudest room segment<a href="#section-7.3-10.2" class="pilcrow">¶</a>
</li>
          <li id="section-7.3-10.3">(VC4) - Video Capture zoomed out view of all people in the room<a href="#section-7.3-10.3" class="pilcrow">¶</a>
</li>
          <li id="section-7.3-10.4">(AC0) - main audio<a href="#section-7.3-10.4" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-7.3-11">
   The first view in this Capture Scene example is a list of Video
   Captures that have a Spatial Relationship to each other.
   Determination of the order of these Captures (VC0, VC1, and VC2) for
   rendering purposes is accomplished through use of their Area of
   Capture attributes.  The second view (MCC3) and the third view
   (VC4) are alternative representations of the same room's video,
   which might be better suited to some Consumers' rendering
   capabilities.  The inclusion of the Audio Capture in the same
   Capture Scene indicates that AC0 is associated with all of those
   Video Captures, meaning it comes from the same spatial region.
   Therefore, if audio were to be Rendered at all, this audio would be
   the correct choice, irrespective of which Video Captures were
   chosen.<a href="#section-7.3-11" class="pilcrow">¶</a></p>
<div id="s-7.3.1">
<section id="section-7.3.1">
          <h4 id="name-capture-scene-attributes">
<a href="#section-7.3.1" class="section-number selfRef">7.3.1. </a><a href="#name-capture-scene-attributes" class="section-name selfRef">Capture Scene Attributes</a>
          </h4>
<p id="section-7.3.1-1">
   Capture Scene attributes can be applied to Capture Scenes as well
   as to individual Media Captures.  Attributes specified at this
   level apply to all constituent Captures.  Capture Scene attributes
   include the following:<a href="#section-7.3.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.3.1-2.1">Human-readable description of the Capture Scene, which could
        be in multiple languages;<a href="#section-7.3.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-7.3.1-2.2">xCard Scene information<a href="#section-7.3.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-7.3.1-2.3">Scale information ("Millimeters", "Unknown Scale", "No Scale"), as
        described in <a href="#s-6" class="xref">Section 6</a>.<a href="#section-7.3.1-2.3" class="pilcrow">¶</a>
</li>
          </ul>
<div id="s-7.3.1.1">
<section id="section-7.3.1.1">
            <h5 id="name-scene-information">
<a href="#section-7.3.1.1" class="section-number selfRef">7.3.1.1. </a><a href="#name-scene-information" class="section-name selfRef">Scene Information</a>
            </h5>
<p id="section-7.3.1.1-1">
   The Scene Information attribute provides information regarding the
   Capture Scene rather than individual participants. The Provider
   may gather the information automatically or manually from a
   variety of sources. The Scene Information attribute allows a
   Provider to indicate information such as organizational or
   geographic information allowing a Consumer to determine which
   Capture Scenes are of interest in order to then perform Capture
   selection. It also allows a Consumer to Render information
   regarding the Scene or to use it for further processing.<a href="#section-7.3.1.1-1" class="pilcrow">¶</a></p>
<p id="section-7.3.1.1-2">
   As per <a href="#s-7.1.1.10" class="xref">Section 7.1.1.10</a>, the xCard format is used to convey this
   information and the Provider may supply a minimal set of
   information or a larger set of information.<a href="#section-7.3.1.1-2" class="pilcrow">¶</a></p>
<p id="section-7.3.1.1-3">
   In order to keep CLUE messages compact the Provider <span class="bcp14">SHOULD</span> use a
   URI to point to any LOGO, PHOTO, or SOUND contained in the xCard
   rather than transmitting the LOGO, PHOTO, or SOUND data in a CLUE
   message.<a href="#section-7.3.1.1-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="s-7.3.2">
<section id="section-7.3.2">
          <h4 id="name-capture-scene-view-attribut">
<a href="#section-7.3.2" class="section-number selfRef">7.3.2. </a><a href="#name-capture-scene-view-attribut" class="section-name selfRef">Capture Scene View Attributes</a>
          </h4>
<p id="section-7.3.2-1">
   A Capture Scene can include one or more CSVs in
   addition to the Capture-Scene-wide attributes described above.
   CSV attributes apply to the CSV as a
   whole, i.e., to all Captures that are part of the CSV.<a href="#section-7.3.2-1" class="pilcrow">¶</a></p>
<p id="section-7.3.2-2">CSV attributes include the following:<a href="#section-7.3.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.3.2-3.1">A human-readable description (which could be in multiple
        languages) of the CSV.<a href="#section-7.3.2-3.1" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
</section>
</div>
<div id="s-7.4">
<section id="section-7.4">
        <h3 id="name-global-view-list">
<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-global-view-list" class="section-name selfRef">Global View List</a>
        </h3>
<p id="section-7.4-1">
   An Advertisement can include an optional Global View list.  Each
   item in this list is a Global View.  The Provider can include
   multiple Global Views, to allow a Consumer to choose sets of
   Captures appropriate to its capabilities or application.  The
   choice of how to make these suggestions in the Global View list
   for what represents all the Scenes for which the Provider can send
   Media is up to the Provider.  This is very similar to how each CSV
   represents a particular Scene.<a href="#section-7.4-1" class="pilcrow">¶</a></p>
<p id="section-7.4-2">
   As an example, suppose an Advertisement has three Scenes, and each
   Scene has three CSVs, ranging from one to three Video Captures in
   each CSV.  The Provider is advertising a total of nine Video
   Captures across three Scenes.  The Provider can use the Global
   View list to suggest alternatives for Consumers that can't receive
   all nine Video Captures as separate Media Streams.  For
   accommodating a Consumer that wants to receive three Video
   Captures, a Provider might suggest a Global View containing just a
   single CSV with three Captures and nothing from the other two
   Scenes.  Or a Provider might suggest a Global View containing
   three different CSVs, one from each Scene, with a single Video
   Capture in each.<a href="#section-7.4-2" class="pilcrow">¶</a></p>
<p id="section-7.4-3">Some additional rules:<a href="#section-7.4-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.4-4.1">The ordering of Global Views in the Global View list is
        insignificant.<a href="#section-7.4-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.4-4.2">The ordering of CSVs within each Global View is
        insignificant.<a href="#section-7.4-4.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.4-4.3">A particular CSV may be used in multiple Global Views.<a href="#section-7.4-4.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.4-4.4">The Provider must be capable of encoding and sending all
        Captures within the CSVs of a given Global View
        simultaneously.<a href="#section-7.4-4.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.4-5">
   The following figure shows an example of the structure of Global
   Views in a Global View List.<a href="#section-7.4-5" class="pilcrow">¶</a></p>
<span id="name-global-view-list-structure"></span><div id="ref-global-view-list-structure">
<figure id="figure-3">
          <div class="artwork art-text alignLeft" id="section-7.4-6.1">
<pre>
   ........................................................
   . Advertisement                                        .
   .                                                      .
   . +--------------+         +-------------------------+ .
   . |Scene 1       |         |Global View List         | .
   . |              |         |                         | .
   . | CSV1 (v)&lt;----------------- Global View (CSV 1)   | .
   . |         &lt;-------.      |                         | .
   . |              |  *--------- Global View (CSV 1,5) | .
   . | CSV2 (v)     |  |      |                         | .
   . |              |  |      |                         | .
   . | CSV3 (v)&lt;---------*------- Global View (CSV 3,5) | .
   . |              |  | |    |                         | .
   . | CSV4 (a)&lt;----------------- Global View (CSV 4)   | .
   . |         &lt;-----------.  |                         | .
   . +--------------+  | | *----- Global View (CSV 4,6) | .
   .                   | | |  |                         | .
   . +--------------+  | | |  +-------------------------+ .
   . |Scene 2       |  | | |                              .
   . |              |  | | |                              .
   . | CSV5 (v)&lt;-------' | |                              .
   . |         &lt;---------' |                              .
   . |              |      |        (v) = video           .
   . | CSV6 (a)&lt;-----------'        (a) = audio           .
   . |              |                                     .
   . +--------------+                                     .
   `......................................................'
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-global-view-list-structure" class="selfRef">Global View List Structure</a>
          </figcaption></figure>
</div>
</section>
</div>
</section>
</div>
<div id="s-8">
<section id="section-8">
      <h2 id="name-simultaneous-transmission-s">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-simultaneous-transmission-s" class="section-name selfRef">Simultaneous Transmission Set Constraints</a>
      </h2>
<p id="section-8-1">
   In many practical cases, a Provider has constraints or limitations
   on its ability to send Captures simultaneously.  One type of
   limitation is caused by the physical limitations of capture
   mechanisms; these constraints are represented by a Simultaneous
   Transmission Set.  The second type of limitation reflects the
   encoding resources available, such as bandwidth or video encoding
   throughput (macroblocks/second).  This type of constraint is
   captured by Individual Encodings and Encoding Groups, discussed
   below.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">
   Some Endpoints or MCUs can send multiple Captures simultaneously;
   however, sometimes there are constraints that limit which Captures
   can be sent simultaneously with other Captures.  A device may not
   be able to be used in different ways at the same time.  Provider
   Advertisements are made so that the Consumer can choose one of
   several possible mutually exclusive usages of the device.  This
   type of constraint is expressed in a Simultaneous Transmission Set,
   which lists all the Captures of a particular Media type (e.g.,
   audio, video, or text) that can be sent at the same time.  There are
   different Simultaneous Transmission Sets for each Media type in the
   Advertisement.  This is easier to show in an example.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">
   Consider the example of a room system where there are three cameras,
   each of which can send a separate Capture covering two people
   each: VC0, VC1, and VC2.  The middle camera can also zoom out (using an
   optical zoom lens) and show all six people, VC3.  But the middle
   camera cannot be used in both modes at the same time; it has to
   either show the space where two participants sit or the whole six
   seats, but not both at the same time.  As a result, VC1 and VC3
   cannot be sent simultaneously.<a href="#section-8-3" class="pilcrow">¶</a></p>
<p id="section-8-4">
   Simultaneous Transmission Sets are expressed as sets of the Media
   Captures that the Provider could transmit at the same time (though,
   in some cases, it is not intuitive to do so).  If a Multiple
   Content Capture is included in a Simultaneous Transmission Set, it
   indicates that the Capture Encoding associated with it could be
   transmitted as the same time as the other Captures within the
   Simultaneous Transmission Set. It does not imply that the Single
   Media Captures contained in the Multiple Content Capture could all
   be transmitted at the same time.<a href="#section-8-4" class="pilcrow">¶</a></p>
<p id="section-8-5">
   In this example, the two Simultaneous Transmission Sets are shown in
   <a href="#ref-two-simultaneous-transmission-sets" class="xref">Table 5</a>.  If a Provider advertises one or more mutually exclusive
   Simultaneous Transmission Sets, then, for each Media type, the
   Consumer <span class="bcp14">MUST</span> ensure that it chooses Media Captures that lie wholly
   within one of those Simultaneous Transmission Sets.<a href="#section-8-5" class="pilcrow">¶</a></p>
<span id="name-two-simultaneous-transmissi"></span><div id="ref-two-simultaneous-transmission-sets">
<table class="center" id="table-5">
        <caption>
<a href="#table-5" class="selfRef">Table 5</a>:
<a href="#name-two-simultaneous-transmissi" class="selfRef">Two Simultaneous Transmission Sets</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Simultaneous Sets</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">{VC0, VC1, VC2}</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">{VC0, VC3, VC2}</td>
          </tr>
        </tbody>
      </table>
</div>
<p id="section-8-7">
   A Provider OPTIONALLY can include the Simultaneous Transmission
   Sets in its Advertisement.  These constraints apply across all the
   Capture Scenes in the Advertisement.  It is a syntax-conformance
   requirement that the Simultaneous Transmission Sets <span class="bcp14">MUST</span> allow all
   the Media Captures in any particular CSV to be used
   simultaneously.  Similarly, the Simultaneous Transmission Sets <span class="bcp14">MUST</span>
   reflect the simultaneity expressed by any Global View.<a href="#section-8-7" class="pilcrow">¶</a></p>
<p id="section-8-8">
   For shorthand convenience, a Provider <span class="bcp14">MAY</span> describe a Simultaneous
   Transmission Set in terms of CSVs and Capture
   Scenes.  If a CSV is included in a Simultaneous
   Transmission Set, then all Media Captures in the CSV
   are included in the Simultaneous Transmission Set.  If a Capture
   Scene is included in a Simultaneous Transmission Set, then all its
   CSVs (of the corresponding Media type) are included
   in the Simultaneous Transmission Set.  The end result reduces to a
   set of Media Captures, of a particular Media type, in either case.<a href="#section-8-8" class="pilcrow">¶</a></p>
<p id="section-8-9">
   If an Advertisement does not include Simultaneous Transmission
   Sets, then the Provider <span class="bcp14">MUST</span> be able to simultaneously provide all
   the Captures from any one CSV of each Media type from each Capture
   Scene.  Likewise, if there are no Simultaneous Transmission Sets
   and there is a Global View list, then the Provider <span class="bcp14">MUST</span> be able to
   simultaneously provide all the Captures from any particular Global
   View (of each Media type) from the Global View list.<a href="#section-8-9" class="pilcrow">¶</a></p>
<p id="section-8-10">
   If an Advertisement includes multiple CSVs in a
   Capture Scene, then the Consumer <span class="bcp14">MAY</span> choose one CSV
   for each Media type, or it <span class="bcp14">MAY</span> choose individual Captures based on the
   Simultaneous Transmission Sets.<a href="#section-8-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-9">
<section id="section-9">
      <h2 id="name-encodings">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-encodings" class="section-name selfRef">Encodings</a>
      </h2>
<p id="section-9-1">
   Individual Encodings and Encoding Groups are CLUE's mechanisms
   allowing a Provider to signal its limitations for sending Captures,
   or combinations of Captures, to a Consumer.  Consumers can map the
   Captures they want to receive onto the Encodings, with the Encoding
   parameters they want.  As for the relationship between the CLUE-specified mechanisms based on Encodings and the SIP offer/answer
   exchange, please refer to <a href="#s-5" class="xref">Section 5</a>.<a href="#section-9-1" class="pilcrow">¶</a></p>
<div id="s-9.1">
<section id="section-9.1">
        <h3 id="name-individual-encodings">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-individual-encodings" class="section-name selfRef">Individual Encodings</a>
        </h3>
<p id="section-9.1-1">
   An Individual Encoding represents a way to encode a Media Capture
   as a Capture Encoding, to be sent as an encoded Media Stream from
   the Provider to the Consumer.  An Individual Encoding has a set of
   parameters characterizing how the Media is encoded.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
<p id="section-9.1-2">
   Different Media types have different parameters, and different
   encoding algorithms may have different parameters.  An Individual
   Encoding can be assigned to at most one Capture Encoding at any
   given time.<a href="#section-9.1-2" class="pilcrow">¶</a></p>
<p id="section-9.1-3">
   Individual Encoding parameters are represented in SDP  
<span>[<a href="#RFC4566" class="xref">RFC4566</a>]</span>,
   not in CLUE messages.  For example, for a video Encoding using
   H.26x compression technologies, this can include parameters such
   as follows:<a href="#section-9.1-3" class="pilcrow">¶</a></p>
<ul class="compact">
<li class="compact" id="section-9.1-4.1">Maximum bandwidth;<a href="#section-9.1-4.1" class="pilcrow">¶</a>
</li>
          <li class="compact" id="section-9.1-4.2">Maximum picture size in pixels;<a href="#section-9.1-4.2" class="pilcrow">¶</a>
</li>
          <li class="compact" id="section-9.1-4.3">Maximum number of pixels to be processed per second;<a href="#section-9.1-4.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-9.1-5">
   The bandwidth parameter is the only one that specifically relates
   to a CLUE Advertisement, as it can be further constrained by the
   maximum group bandwidth in an Encoding Group.<a href="#section-9.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-9.2">
<section id="section-9.2">
        <h3 id="name-encoding-group">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-encoding-group" class="section-name selfRef">Encoding Group</a>
        </h3>
<p id="section-9.2-1">
   An Encoding Group includes a set of one or more Individual
   Encodings, and parameters that apply to the group as a whole.  By
   grouping multiple Individual Encodings together, an Encoding Group
   describes additional constraints on bandwidth for the group. A
   single Encoding Group <span class="bcp14">MAY</span> refer to Encodings for different Media
   types.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
<p id="section-9.2-2">The Encoding Group data structure contains:<a href="#section-9.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.2-3.1">Maximum bitrate for all Encodings in the group combined;<a href="#section-9.2-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-9.2-3.2">A list of identifiers for the Individual Encodings belonging to the group.<a href="#section-9.2-3.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-9.2-4">
   When the Individual Encodings in a group are instantiated into
   Capture Encodings, each Capture Encoding has a bitrate that <span class="bcp14">MUST</span> be
   less than or equal to the max bitrate for the particular Individual
   Encoding.  The "maximum bitrate for all Encodings in the group"
   parameter gives the additional restriction that the sum of all the
   individual Capture Encoding bitrates <span class="bcp14">MUST</span> be less than or equal to
   this group value.<a href="#section-9.2-4" class="pilcrow">¶</a></p>
<p id="section-9.2-5">
   The following diagram illustrates one example of the structure of a
   Media Provider's Encoding Groups and their contents.<a href="#section-9.2-5" class="pilcrow">¶</a></p>
<span id="name-encoding-group-structure"></span><div id="ref-encoding-group-structure">
<figure id="figure-4">
          <div class="artwork art-text alignLeft" id="section-9.2-6.1">
<pre>
,-------------------------------------------------.
|             Media Provider                      |
|                                                 |
|  ,--------------------------------------.       |
|  | ,--------------------------------------.     |
|  | | ,--------------------------------------.   |
|  | | |          Encoding Group              |   |
|  | | | ,-----------.                        |   |
|  | | | |           | ,---------.            |   |
|  | | | |           | |         | ,---------.|   |
|  | | | | Encoding1 | |Encoding2| |Encoding3||   |
|  `.| | |           | |         | `---------'|   |
|    `.| `-----------' `---------'            |   |
|      `--------------------------------------'   |
`-------------------------------------------------'
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-encoding-group-structure" class="selfRef">Encoding Group Structure</a>
          </figcaption></figure>
</div>
<p id="section-9.2-7">A Provider advertises one or more Encoding Groups.  Each Encoding
Group includes one or more Individual Encodings.  Each Individual
Encoding can represent a different way of encoding Media.  For
example, one Individual Encoding may be 1080p60 video, another could
be 720p30, with a third being 352x288p30, all in, for example, H.264
format.<a href="#section-9.2-7" class="pilcrow">¶</a></p>
<p id="section-9.2-8">While a typical three-codec/display system might have one Encoding
Group per "codec box" (physical codec, connected to one camera and
one screen), there are many possibilities for the number of
Encoding Groups a Provider may be able to offer and for the
Encoding values in each Encoding Group.<a href="#section-9.2-8" class="pilcrow">¶</a></p>
<p id="section-9.2-9">
   There is no requirement for all Encodings within an Encoding Group
   to be instantiated at the same time.<a href="#section-9.2-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-9.3">
<section id="section-9.3">
        <h3 id="name-associating-captures-with-e">
<a href="#section-9.3" class="section-number selfRef">9.3. </a><a href="#name-associating-captures-with-e" class="section-name selfRef">Associating Captures with Encoding Groups</a>
        </h3>
<p id="section-9.3-1">
   Each Media Capture, including MCCs, <span class="bcp14">MAY</span> be associated with one
   Encoding Group. To be eligible for configuration, a Media Capture
   <span class="bcp14">MUST</span> be associated with one Encoding Group, which is used to
   instantiate that Capture into a Capture Encoding. When an MCC is
   configured, all the Media Captures referenced by the MCC will appear
   in the Capture Encoding according to the attributes of the chosen
   Encoding of the MCC. This allows an Advertiser to specify Encoding
   attributes associated with the Media Captures without the need to
   provide an individual Capture Encoding for each of the inputs.<a href="#section-9.3-1" class="pilcrow">¶</a></p>
<p id="section-9.3-2">
   If an Encoding Group is assigned to a Media Capture referenced by
   the MCC, it indicates that this Capture may also have an individual
   Capture Encoding.<a href="#section-9.3-2" class="pilcrow">¶</a></p>
<p id="section-9.3-3">For example:<a href="#section-9.3-3" class="pilcrow">¶</a></p>
<span id="name-example-usage-of-encoding-w"></span><div id="ref-example-usage-of-encoding-with-mcc-and-source-captures">
<table class="center" id="table-6">
          <caption>
<a href="#table-6" class="selfRef">Table 6</a>:
<a href="#name-example-usage-of-encoding-w" class="selfRef">Example Usage of Encoding with MCC and Source Captures</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Capture Scene #1</th>
              <th class="text-left" rowspan="1" colspan="1"> </th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">VC1</td>
              <td class="text-left" rowspan="1" colspan="1">EncodeGroupID=1</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">VC2</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">MCC1(VC1,VC2)</td>
              <td class="text-left" rowspan="1" colspan="1">EncodeGroupID=2</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">CSV(VC1)</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">CSV(MCC1)</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-9.3-5">
   This would indicate that VC1 may be sent as its own Capture
   Encoding from EncodeGroupID=1 or that it may be sent as part of a
   Capture Encoding from EncodeGroupID=2 along with VC2.<a href="#section-9.3-5" class="pilcrow">¶</a></p>
<p id="section-9.3-6">
   More than one Capture <span class="bcp14">MAY</span> use the same Encoding Group.<a href="#section-9.3-6" class="pilcrow">¶</a></p>
<p id="section-9.3-7">
   The maximum number of Capture Encodings that can result from a
   particular Encoding Group constraint is equal to the number of
   Individual Encodings in the group.  The actual number of Capture
   Encodings used at any time <span class="bcp14">MAY</span> be less than this maximum.  Any of
   the Captures that use a particular Encoding Group can be encoded
   according to any of the Individual Encodings in the group.<a href="#section-9.3-7" class="pilcrow">¶</a></p>
<p id="section-9.3-8">
   It is a protocol conformance requirement that the Encoding Groups
   <span class="bcp14">MUST</span> allow all the Captures in a particular CSV to
   be used simultaneously.<a href="#section-9.3-8" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="s-10">
<section id="section-10">
      <h2 id="name-consumers-choice-of-streams">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-consumers-choice-of-streams" class="section-name selfRef">Consumer's Choice of Streams to Receive from the Provider</a>
      </h2>
<p id="section-10-1">
   After receiving the Provider's Advertisement message (which includes
   Media Captures and associated constraints), the Consumer composes
   its reply to the Provider in the form of a Configure message.  The
   Consumer is free to use the information in the Advertisement as it
   chooses, but there are a few obviously sensible design choices,
   which are outlined below.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">
   If multiple Providers connect to the same Consumer (i.e., in an
   MCU-less multiparty call), it is the responsibility of the Consumer
   to compose Configures for each Provider that both fulfill each
   Provider's constraints as expressed in the Advertisement, as well
   as its own capabilities.<a href="#section-10-2" class="pilcrow">¶</a></p>
<p id="section-10-3">
   In an MCU-based multiparty call, the MCU can logically terminate
   the Advertisement/Configure negotiation in that it can hide the
   characteristics of the receiving Endpoint and rely on its own
   capabilities (transcoding/transrating/etc.) to create Media Streams
   that can be decoded at the Endpoint Consumers.  The timing of an
   MCU's sending of Advertisements (for its outgoing ports) and
   Configures (for its incoming ports, in response to Advertisements
   received there) is up to the MCU and is implementation dependent.<a href="#section-10-3" class="pilcrow">¶</a></p>
<p id="section-10-4">
   As a general outline, a Consumer can choose, based on the
   Advertisement it has received, which Captures it wishes to receive,
   and which Individual Encodings it wants the Provider to use to
   encode the Captures.<a href="#section-10-4" class="pilcrow">¶</a></p>
<p id="section-10-5">
   On receipt of an Advertisement with an MCC, the Consumer treats the
   MCC as per other non-MCC Captures with the following differences:<a href="#section-10-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-10-6.1">The Consumer would understand that the MCC is a Capture that
     includes the referenced individual Captures (or any Captures, if
     none are referenced) and that these individual Captures are
     delivered as part of the MCC's Capture Encoding.<a href="#section-10-6.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-10-6.2">The Consumer may utilize any of the attributes associated with
     the referenced individual Captures and any Capture Scene attributes
     from where the individual Captures were defined to choose Captures
     and for Rendering decisions.<a href="#section-10-6.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-10-6.3">If the MCC attribute Allow Subset Choice is true, then the
     Consumer may or may not choose to receive all the indicated
     Captures.  It can choose to receive a subset of Captures indicated
     by the MCC.<a href="#section-10-6.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-10-7">For example, if the Consumer receives:<a href="#section-10-7" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-10-8">
        MCC1(VC1,VC2,VC3){attributes}<a href="#section-10-8" class="pilcrow">¶</a></p>
<p id="section-10-9">
   A Consumer could choose all the Captures within an MCC; however, if
   the Consumer determines that it doesn't want VC3, it can return
   MCC1(VC1,VC2).  If it wants all the individual Captures, then it
   returns only the MCC identity (i.e., MCC1).  If the MCC in the
   Advertisement does not reference any individual Captures, or the
   Allow Subset Choice attribute is false, then the Consumer cannot
   choose what is included in the MCC: it is up to the Provider to
   decide.<a href="#section-10-9" class="pilcrow">¶</a></p>
<p id="section-10-10">
   A Configure Message includes a list of Capture Encodings.  These
   are the Capture Encodings the Consumer wishes to receive from the
   Provider.  Each Capture Encoding refers to one Media Capture and
   one Individual Encoding.<a href="#section-10-10" class="pilcrow">¶</a></p>
<p id="section-10-11">
   For each Capture the Consumer wants to receive, it configures one
   of the Encodings in that Capture's Encoding Group.  The Consumer
   does this by telling the Provider, in its Configure Message, which
   Encoding to use for each chosen Capture.  Upon receipt of this
   Configure from the Consumer, common knowledge is established
   between Provider and Consumer regarding sensible choices for the
   Media Streams.  The setup of the actual Media channels, at least in
   the simplest case, is left to a following offer/answer exchange.
   Optimized implementations may speed up the reaction to the
   offer/answer exchange by reserving the resources at the time of
   finalization of the CLUE handshake.<a href="#section-10-11" class="pilcrow">¶</a></p>
<p id="section-10-12">
   CLUE Advertisements and Configure Messages don't necessarily
   require a new SDP offer/answer for every CLUE message
   exchange.  But the resulting Encodings sent via RTP must conform to
   the most-recent SDP offer/answer result.<a href="#section-10-12" class="pilcrow">¶</a></p>
<p id="section-10-13">
   In order to meaningfully create and send an initial Configure, the
   Consumer needs to have received at least one Advertisement, and an
   SDP offer defining the Individual Encodings, from the Provider.<a href="#section-10-13" class="pilcrow">¶</a></p>
<p id="section-10-14">
   In addition, the Consumer can send a Configure at any time during
   the call.  The Configure <span class="bcp14">MUST</span> be valid according to the most
   recently received Advertisement.  The Consumer can send a Configure
   either in response to a new Advertisement from the Provider or on
   its own, for example, because of a local change in conditions
   (people leaving the room, connectivity changes, multipoint related
   considerations).<a href="#section-10-14" class="pilcrow">¶</a></p>
<p id="section-10-15">
   When choosing which Media Streams to receive from the Provider, and
   the encoding characteristics of those Media Streams, the Consumer
   advantageously takes several things into account: its local
   preference, simultaneity restrictions, and encoding limits.<a href="#section-10-15" class="pilcrow">¶</a></p>
<div id="s-10.1">
<section id="section-10.1">
        <h3 id="name-local-preference">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-local-preference" class="section-name selfRef">Local Preference</a>
        </h3>
<p id="section-10.1-1">
   A variety of local factors influence the Consumer's choice of
   Media Streams to be received from the Provider:<a href="#section-10.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-10.1-2.1">If the Consumer is an Endpoint, it is likely that it would
      choose, where possible, to receive Video and Audio Captures that
      match the number of display devices and audio system it has.<a href="#section-10.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.1-2.2">If the Consumer is an MCU, it may choose to receive loudest
      speaker Streams (in order to perform its own Media composition)
      and avoid pre-composed Video Captures.<a href="#section-10.1-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.1-2.3">User choice (for instance, selection of a new layout) may result
      in a different set of Captures, or different Encoding
      characteristics, being required by the Consumer.<a href="#section-10.1-2.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="s-10.2">
<section id="section-10.2">
        <h3 id="name-physical-simultaneity-restr">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-physical-simultaneity-restr" class="section-name selfRef">Physical Simultaneity Restrictions</a>
        </h3>
<p id="section-10.2-1">
   Often there are physical simultaneity constraints of the Provider
   that affect the Provider's ability to simultaneously send all of
   the Captures the Consumer would wish to receive.  For instance, an
   MCU, when connected to a multi-camera room system, might prefer to
   receive both individual video Streams of the people present in the
   room and an overall view of the room from a single camera.  Some
   Endpoint systems might be able to provide both of these sets of
   Streams simultaneously, whereas others might not (if the overall
   room view were produced by changing the optical zoom level on the
   center camera, for instance).<a href="#section-10.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-10.3">
<section id="section-10.3">
        <h3 id="name-encoding-and-encoding-group">
<a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-encoding-and-encoding-group" class="section-name selfRef">Encoding and Encoding Group Limits</a>
        </h3>
<p id="section-10.3-1">
   Each of the Provider's Encoding Groups has limits on bandwidth,
   and the constituent potential Encodings have limits on the
   bandwidth, computational complexity, video frame rate, and
   resolution that can be provided.  When choosing the Captures to be
   received from a Provider, a Consumer device <span class="bcp14">MUST</span> ensure that the
   Encoding characteristics requested for each individual Capture
   fits within the capability of the Encoding it is being configured
   to use, as well as ensuring that the combined Encoding
   characteristics for Captures fit within the capabilities of their
   associated Encoding Groups.  In some cases, this could cause an
   otherwise "preferred" choice of Capture Encodings to be passed
   over in favor of different Capture Encodings -- for instance, if a
   set of three Captures could only be provided at a low resolution
   then a three screen device could switch to favoring a single,
   higher quality, Capture Encoding.<a href="#section-10.3-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="s-11">
<section id="section-11">
      <h2 id="name-extensibility">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-extensibility" class="section-name selfRef">Extensibility</a>
      </h2>
<p id="section-11-1">
   One important characteristics of the Framework is its
   extensibility.  The standard for interoperability and handling
   multiple Streams must be future-proof. The framework itself is
   inherently extensible through expanding the data model types.  For
   example:<a href="#section-11-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-11-2.1">Adding more types of Media, such as telemetry, can done by
      defining additional types of Captures in addition to audio and
      video.<a href="#section-11-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-11-2.2">Adding new functionalities, such as 3-D Video Captures, may
      require additional attributes describing the Captures.<a href="#section-11-2.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-11-3">
   The infrastructure is designed to be extended rather than
   requiring new infrastructure elements.  Extension comes through
   adding to defined types.<a href="#section-11-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-12">
<section id="section-12">
      <h2 id="name-examples-using-the-framewor">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-examples-using-the-framewor" class="section-name selfRef">Examples - Using the Framework (Informative)</a>
      </h2>
<p id="section-12-1">
   This section gives some examples, first from the point of view of
   the Provider, then the Consumer, then some multipoint scenarios.<a href="#section-12-1" class="pilcrow">¶</a></p>
<div id="s-12.1">
<section id="section-12.1">
        <h3 id="name-provider-behavior">
<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-provider-behavior" class="section-name selfRef">Provider Behavior</a>
        </h3>
<p id="section-12.1-1">
   This section shows some examples in more detail of how a Provider
   can use the framework to represent a typical case for telepresence
   rooms.  First, an Endpoint is illustrated, then an MCU case is
   shown.<a href="#section-12.1-1" class="pilcrow">¶</a></p>
<div id="s-12.1.1">
<section id="section-12.1.1">
          <h4 id="name-three-screen-endpoint-provi">
<a href="#section-12.1.1" class="section-number selfRef">12.1.1. </a><a href="#name-three-screen-endpoint-provi" class="section-name selfRef">Three-Screen Endpoint Provider</a>
          </h4>
<p id="section-12.1.1-1">
   Consider an Endpoint with the following description:<a href="#section-12.1.1-1" class="pilcrow">¶</a></p>
<p id="section-12.1.1-2">
   Three cameras, three displays, and a six-person table<a href="#section-12.1.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-12.1.1-3.1">Each camera can provide one Capture for each 1/3-section of the
      table.<a href="#section-12.1.1-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-12.1.1-3.2">A single Capture representing the active speaker can be provided
      (voice-activity-based camera selection to a given encoder input
      port implemented locally in the Endpoint).<a href="#section-12.1.1-3.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-12.1.1-3.3">A single Capture representing the active speaker with the other
      two Captures shown picture in picture (PiP) within the Stream can
      be provided (again, implemented inside the Endpoint).<a href="#section-12.1.1-3.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-12.1.1-3.4">A Capture showing a zoomed out view of all six seats in the room
      can be provided.<a href="#section-12.1.1-3.4" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-12.1.1-4">
   The Video and Audio Captures for this Endpoint can be described as
   follows.<a href="#section-12.1.1-4" class="pilcrow">¶</a></p>
<p id="section-12.1.1-5">
   Video Captures:<a href="#section-12.1.1-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-12.1.1-6">
            <dt id="section-12.1.1-6.1">VC0</dt>
            <dd style="margin-left: 3.5em" id="section-12.1.1-6.2">(the left camera Stream), Encoding Group=EG0, view=table<a href="#section-12.1.1-6.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.1.1-6.3">VC1</dt>
            <dd style="margin-left: 3.5em" id="section-12.1.1-6.4">(the center camera Stream), Encoding Group=EG1, view=table<a href="#section-12.1.1-6.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.1.1-6.5">VC2</dt>
            <dd style="margin-left: 3.5em" id="section-12.1.1-6.6">(the right camera Stream), Encoding Group=EG2, view=table<a href="#section-12.1.1-6.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.1.1-6.7">MCC3</dt>
            <dd style="margin-left: 3.5em" id="section-12.1.1-6.8">(the loudest panel Stream), Encoding Group=EG1, view=table, MaxCaptures=1, policy=SoundLevel<a href="#section-12.1.1-6.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.1.1-6.9">MCC4</dt>
            <dd style="margin-left: 3.5em" id="section-12.1.1-6.10">(the loudest panel Stream with PiPs), Encoding Group=EG1, view=room, MaxCaptures=3, policy=SoundLevel<a href="#section-12.1.1-6.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.1.1-6.11">VC5</dt>
            <dd style="margin-left: 3.5em" id="section-12.1.1-6.12">(the zoomed out view of all people in the room), Encoding Group=EG1, view=room<a href="#section-12.1.1-6.12" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.1.1-6.13">VC6</dt>
            <dd style="margin-left: 3.5em" id="section-12.1.1-6.14">(presentation Stream), Encoding Group=EG1, presentation<a href="#section-12.1.1-6.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-12.1.1-7">
   The following diagram is a top view of the room with three cameras, three
   displays, and six seats.  Each camera captures two people.  The six
   seats are not all in a straight line.<a href="#section-12.1.1-7" class="pilcrow">¶</a></p>
<span id="name-room-layout-top-view"></span><div id="ref-room-layout-top-view">
<figure id="figure-5">
            <div class="artwork art-text alignLeft" id="section-12.1.1-8.1">
<pre>
   ,-. d
  (   )`--.__        +---+
   `-' /     `--.__  |   |
 ,-.  |            `-.._ |_-+Camera 2 (VC2)
(   ).'     &lt;--(AC1)-+-''`+-+
 `-' |_...---''      |   |
 ,-.c+-..__          +---+
(   )|     ``--..__  |   |
 `-' |             ``+-..|_-+Camera 1 (VC1)
 ,-. |      &lt;--(AC2)..--'|+-+                          ^
(   )|     __..--'   |   |                             |
 `-'b|..--'          +---+                             |X
 ,-. |``---..___     |   |                             |
(   )\          ```--..._|_-+Camera 0 (VC0)            |
 `-'  \     &lt;--(AC0) ..-''`-+                          |
  ,-. \      __.--'' |   |                  &lt;----------+
 (   ) |..-''        +---+                     Y
  `-' a                          (0,0,0) origin is under Camera 1
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-room-layout-top-view" class="selfRef">Room Layout Top View</a>
            </figcaption></figure>
</div>
<p id="section-12.1.1-9">
   The two points labeled 'b' and 'c' are intended to be at the midpoint
   between the seating positions, and where the fields of view of the
   cameras intersect.<a href="#section-12.1.1-9" class="pilcrow">¶</a></p>
<p id="section-12.1.1-10">
   The Plane of Interest for VC0 is a vertical plane that intersects
   points 'a' and 'b'.<a href="#section-12.1.1-10" class="pilcrow">¶</a></p>
<p id="section-12.1.1-11">
   The Plane of Interest for VC1 intersects points 'b' and 'c'. The
   plane of interest for VC2 intersects points 'c' and 'd'.<a href="#section-12.1.1-11" class="pilcrow">¶</a></p>
<p id="section-12.1.1-12">
   This example uses an area scale of millimeters.<a href="#section-12.1.1-12" class="pilcrow">¶</a></p>
<p id="section-12.1.1-13">Areas of capture:<a href="#section-12.1.1-13" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-12.1.1-14">
<pre>
    bottom left    bottom right  top left         top right
VC0 (-2011,2850,0) (-673,3000,0) (-2011,2850,757) (-673,3000,757)
VC1 ( -673,3000,0) ( 673,3000,0) ( -673,3000,757) ( 673,3000,757)
VC2 (  673,3000,0) (2011,2850,0) (  673,3000,757) (2011,3000,757)
MCC3(-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757)
MCC4(-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757)
VC5 (-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757)
VC6 none
</pre><a href="#section-12.1.1-14" class="pilcrow">¶</a>
</div>
<p id="section-12.1.1-15">Points of capture:<a href="#section-12.1.1-15" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-12.1.1-16">
<pre>
VC0 (-1678,0,800)
VC1 (0,0,800)
VC2 (1678,0,800)
MCC3 none
MCC4 none
VC5 (0,0,800)
VC6 none
</pre><a href="#section-12.1.1-16" class="pilcrow">¶</a>
</div>
<p id="section-12.1.1-17">
   In this example, the right edge of the VC0 area lines up with the
   left edge of the VC1 area.  It doesn't have to be this way.  There
   could be a gap or an overlap.  One additional thing to note for
   this example is the distance from 'a' to 'b' is equal to the distance
   from 'b' to 'c' and the distance from 'c' to 'd'.  All these distances are
   1346 mm. This is the planar width of each Area of Capture for VC0,
   VC1, and VC2.<a href="#section-12.1.1-17" class="pilcrow">¶</a></p>
<p id="section-12.1.1-18">
   Note the text in parentheses (e.g., "the left camera Stream") is
   not explicitly part of the model, it is just explanatory text for
   this example, and it is not included in the model with the Media
   Captures and attributes.  Also, MCC4 doesn't say anything about
   how a Capture is composed, so the Media Consumer can't tell based
   on this Capture that MCC4 is composed of a "loudest panel with PiPs".<a href="#section-12.1.1-18" class="pilcrow">¶</a></p>
<p id="section-12.1.1-19">
   Audio Captures:<a href="#section-12.1.1-19" class="pilcrow">¶</a></p>
<p id="section-12.1.1-20">
   Three ceiling microphones are located between the cameras and the
   table, at the same height as the cameras.  The microphones point
   down at an angle toward the seating positions.<a href="#section-12.1.1-20" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-12.1.1-21.1">AC0 (left), Encoding Group=EG3<a href="#section-12.1.1-21.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-12.1.1-21.2">AC1 (right), Encoding Group=EG3<a href="#section-12.1.1-21.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-12.1.1-21.3">AC2 (center), Encoding Group=EG3<a href="#section-12.1.1-21.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-12.1.1-21.4">AC3 being a simple pre-mixed audio Stream from the room (mono),
      Encoding Group=EG3<a href="#section-12.1.1-21.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-12.1.1-21.5">AC4 audio Stream associated with the presentation video (mono)
      Encoding Group=EG3, presentation<a href="#section-12.1.1-21.5" class="pilcrow">¶</a>
</li>
          </ul>
<div class="artwork art-text alignLeft" id="section-12.1.1-22">
<pre>
Point of Capture:           Point on Line of Capture:
AC0 (-1342,2000,800)       (-1342,2925,379)
AC1 ( 1342,2000,800)       ( 1342,2925,379)
AC2 (    0,2000,800)       (    0,3000,379)
AC3 (    0,2000,800)       (    0,3000,379)
AC4 none
</pre><a href="#section-12.1.1-22" class="pilcrow">¶</a>
</div>
<p id="section-12.1.1-23">The physical simultaneity information is:<a href="#section-12.1.1-23" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-12.1.1-24">
            Simultaneous Transmission Set #1 {VC0, VC1, VC2, MCC3, MCC4, VC6}<a href="#section-12.1.1-24" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-12.1.1-25">Simultaneous Transmission Set #2 {VC0, VC2, VC5, VC6}<a href="#section-12.1.1-25" class="pilcrow">¶</a></p>
<p id="section-12.1.1-26">
   This constraint indicates that it is not possible to use all the VCs at
   the same time.  VC5 cannot be used at the same time as VC1 or MCC3
   or MCC4.  Also, using every member in the set simultaneously may
   not make sense -- for example, MCC3 (loudest) and MCC4 (loudest with
   PiP).  In addition, there are Encoding constraints that make
   choosing all of the VCs in a set impossible.  VC1, MCC3, MCC4,
   VC5, and VC6 all use EG1 and EG1 has only three ENCs.  This constraint
   shows up in the Encoding Groups, not in the Simultaneous
   Transmission Sets.<a href="#section-12.1.1-26" class="pilcrow">¶</a></p>
<p id="section-12.1.1-27">
   In this example, there are no restrictions on which Audio Captures
   can be sent simultaneously.<a href="#section-12.1.1-27" class="pilcrow">¶</a></p>
<p id="section-12.1.1-28">
   Encoding Groups:<a href="#section-12.1.1-28" class="pilcrow">¶</a></p>
<p id="section-12.1.1-29">
   This example has three Encoding Groups associated with the Video
   Captures.  Each group can have three Encodings, but with each
   potential Encoding having a progressively lower specification.  In
   this example, 1080p60 transmission is possible (as ENC0 has a
   maxPps value compatible with that).  Significantly, as up to three
   Encodings are available per group, it is possible to transmit some
   Video Captures simultaneously that are not in the same view in the
   Capture Scene, for example, VC1 and MCC3 at the same time.  The
   information below about Encodings is a summary of what would be
   conveyed in SDP, not directly in the CLUE Advertisement.<a href="#section-12.1.1-29" class="pilcrow">¶</a></p>
<span id="name-example-encoding-groups-for"></span><div id="ref-example-encoding-groups-for-video">
<figure id="figure-6">
            <div class="artwork art-text alignLeft" id="section-12.1.1-30.1">
<pre>
encodeGroupID=EG0, maxGroupBandwidth=6000000
    encodeID=ENC0, maxWidth=1920, maxHeight=1088, maxFrameRate=60,
                   maxPps=124416000, maxBandwidth=4000000
    encodeID=ENC1, maxWidth=1280, maxHeight=720, maxFrameRate=30,
                   maxPps=27648000, maxBandwidth=4000000
    encodeID=ENC2, maxWidth=960, maxHeight=544, maxFrameRate=30,
                   maxPps=15552000, maxBandwidth=4000000
encodeGroupID=EG1  maxGroupBandwidth=6000000
    encodeID=ENC3, maxWidth=1920, maxHeight=1088, maxFrameRate=60,
                   maxPps=124416000, maxBandwidth=4000000
    encodeID=ENC4, maxWidth=1280, maxHeight=720, maxFrameRate=30,
                   maxPps=27648000, maxBandwidth=4000000
    encodeID=ENC5, maxWidth=960, maxHeight=544, maxFrameRate=30,
                   maxPps=15552000, maxBandwidth=4000000
encodeGroupID=EG2  maxGroupBandwidth=6000000
    encodeID=ENC6, maxWidth=1920, maxHeight=1088, maxFrameRate=60,
                   maxPps=124416000, maxBandwidth=4000000
    encodeID=ENC7, maxWidth=1280, maxHeight=720, maxFrameRate=30,
                   maxPps=27648000, maxBandwidth=4000000
    encodeID=ENC8, maxWidth=960, maxHeight=544, maxFrameRate=30,
                   maxPps=15552000, maxBandwidth=4000000
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-example-encoding-groups-for" class="selfRef">Example Encoding Groups for Video</a>
            </figcaption></figure>
</div>
<p id="section-12.1.1-31">
   For audio, there are five potential Encodings available, so all
   five Audio Captures can be encoded at the same time.<a href="#section-12.1.1-31" class="pilcrow">¶</a></p>
<span id="name-example-encoding-group-for-"></span><div id="ref-example-encoding-group-for-audio">
<figure id="figure-7">
            <div class="artwork art-text alignLeft" id="section-12.1.1-32.1">
<pre>
encodeGroupID=EG3, maxGroupBandwidth=320000
    encodeID=ENC9, maxBandwidth=64000
    encodeID=ENC10, maxBandwidth=64000
    encodeID=ENC11, maxBandwidth=64000
    encodeID=ENC12, maxBandwidth=64000
    encodeID=ENC13, maxBandwidth=64000
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-example-encoding-group-for-" class="selfRef">Example Encoding Group for Audio</a>
            </figcaption></figure>
</div>
<p id="section-12.1.1-33">
   Capture Scenes:<a href="#section-12.1.1-33" class="pilcrow">¶</a></p>
<p id="section-12.1.1-34">
   The following table represents the Capture Scenes for this
   Provider. Recall that a Capture Scene is composed of alternative
   CSVs covering the same spatial region.  Capture
   Scene #1 is for the main people Captures, and Capture Scene #2 is
   for presentation.<a href="#section-12.1.1-34" class="pilcrow">¶</a></p>
<p id="section-12.1.1-35">Each row in the table is a separate CSV.<a href="#section-12.1.1-35" class="pilcrow">¶</a></p>
<span id="name-example-csvs"></span><table class="center" id="table-7">
            <caption>
<a href="#table-7" class="selfRef">Table 7</a>:
<a href="#name-example-csvs" class="selfRef">Example CSVs</a>
            </caption>
<tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1"> Capture Scene #1</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC0, VC1, VC2</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC3</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC4</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC5</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">AC0, AC1, AC2</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">AC3</td>
              </tr>
            </tbody>
            <tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1"> Capture Scene #2</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC6</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">AC4</td>
              </tr>
            </tbody>
          </table>
<p id="section-12.1.1-37">
   Different Capture Scenes are distinct from each other and do not
   overlap.  A Consumer can choose a view from each Capture Scene.  In
   this case, the three Captures, VC0, VC1, and VC2, are one way of
   representing the video from the Endpoint.  These three Captures
   should appear adjacent to each other.  Alternatively, another
   way of representing the Capture Scene is with the Capture MCC3,
   which automatically shows the person who is talking; this is the same for
   the MCC4 and VC5 alternatives.<a href="#section-12.1.1-37" class="pilcrow">¶</a></p>
<p id="section-12.1.1-38">
   As in the video case, the different views of audio in Capture
   Scene #1 represent the "same thing", in that one way to receive
   the audio is with the three Audio Captures (AC0, AC1, and AC2), and
   another way is with the mixed AC3.  The Media Consumer can choose
   an audio CSV it is capable of receiving.<a href="#section-12.1.1-38" class="pilcrow">¶</a></p>
<p id="section-12.1.1-39">
   The spatial ordering is understood by the Media Capture attribute's
   Area of Capture, Point of Capture, and Point on Line of Capture.<a href="#section-12.1.1-39" class="pilcrow">¶</a></p>
<p id="section-12.1.1-40">
   A Media Consumer would likely want to choose a CSV
   to receive, partially based on how many Streams it can simultaneously
   receive.  A Consumer that can receive three video Streams would
   probably prefer to receive the first view of Capture Scene #1
   (VC0, VC1, and VC2) and not receive the other views.  A Consumer that
   can receive only one video Stream would probably choose one of the
   other views.<a href="#section-12.1.1-40" class="pilcrow">¶</a></p>
<p id="section-12.1.1-41">
   If the Consumer can receive a presentation Stream too, it would
   also choose to receive the only view from Capture Scene #2 (VC6).<a href="#section-12.1.1-41" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-12.1.2">
<section id="section-12.1.2">
          <h4 id="name-encoding-group-example">
<a href="#section-12.1.2" class="section-number selfRef">12.1.2. </a><a href="#name-encoding-group-example" class="section-name selfRef">Encoding Group Example</a>
          </h4>
<p id="section-12.1.2-1">
   This is an example of an Encoding Group to illustrate how it can
   express dependencies between Encodings.  The information below
   about Encodings is a summary of what would be conveyed in SDP, not
   directly in the CLUE Advertisement.<a href="#section-12.1.2-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-12.1.2-2">
<pre>
encodeGroupID=EG0 maxGroupBandwidth=6000000
    encodeID=VIDENC0, maxWidth=1920, maxHeight=1088,
      maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000
    encodeID=VIDENC1, maxWidth=1920, maxHeight=1088,
      maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000
    encodeID=AUDENC0, maxBandwidth=96000
    encodeID=AUDENC1, maxBandwidth=96000
    encodeID=AUDENC2, maxBandwidth=96000
</pre><a href="#section-12.1.2-2" class="pilcrow">¶</a>
</div>
<p id="section-12.1.2-3">
   Here, the Encoding Group is EG0.  Although the Encoding Group is
   capable of transmitting up to 6 Mbit/s, no individual video
   Encoding can exceed 4 Mbit/s.<a href="#section-12.1.2-3" class="pilcrow">¶</a></p>
<p id="section-12.1.2-4">
   This Encoding Group also allows up to three audio Encodings, AUDENC&lt;0-2&gt;. It is not required that audio and video Encodings reside
   within the same Encoding Group, but if so, then the group's overall
   maxBandwidth value is a limit on the sum of all audio and video
   Encodings configured by the Consumer.  A system that does not wish
   or need to combine bandwidth limitations in this way should
   instead use separate Encoding Groups for audio and video in order
   for the bandwidth limitations on audio and video to not interact.<a href="#section-12.1.2-4" class="pilcrow">¶</a></p>
<p id="section-12.1.2-5">
   Audio and video can be expressed in separate Encoding Groups, as
   in this illustration.<a href="#section-12.1.2-5" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-12.1.2-6">
<pre>
encodeGroupID=EG0 maxGroupBandwidth=6000000
    encodeID=VIDENC0, maxWidth=1920, maxHeight=1088,
      maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000
    encodeID=VIDENC1, maxWidth=1920, maxHeight=1088,
      maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000
encodeGroupID=EG1 maxGroupBandwidth=500000
    encodeID=AUDENC0, maxBandwidth=96000
    encodeID=AUDENC1, maxBandwidth=96000
    encodeID=AUDENC2, maxBandwidth=96000
</pre><a href="#section-12.1.2-6" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="s-12.1.3">
<section id="section-12.1.3">
          <h4 id="name-the-mcu-case">
<a href="#section-12.1.3" class="section-number selfRef">12.1.3. </a><a href="#name-the-mcu-case" class="section-name selfRef">The MCU Case</a>
          </h4>
<p id="section-12.1.3-1">
   This section shows how an MCU might express its Capture Scenes,
   intending to offer different choices for Consumers that can handle
   different numbers of Streams. Each MCC is for video. A single
   Audio Capture is provided for all single and multi-screen
   configurations that can be associated (e.g., lip-synced) with any
   combination of Video Captures (the MCCs) at the Consumer.<a href="#section-12.1.3-1" class="pilcrow">¶</a></p>
<span id="name-mcu-main-capture-scenes"></span><div id="ref-mcu-main-capture-scenes">
<table class="center" id="table-8">
            <caption>
<a href="#table-8" class="selfRef">Table 8</a>:
<a href="#name-mcu-main-capture-scenes" class="selfRef">MCU Main Capture Scenes</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #1</th>
                <th class="text-left" rowspan="1" colspan="1"></th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC</td>
                <td class="text-left" rowspan="1" colspan="1">for a one-screen Consumer</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC1, MCC2</td>
                <td class="text-left" rowspan="1" colspan="1">for a two-screen Consumer</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC3, MCC4, MCC5</td>
                <td class="text-left" rowspan="1" colspan="1">for a three-screen Consumer</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC6, MCC7, MCC8, MCC9</td>
                <td class="text-left" rowspan="1" colspan="1">for a four-screen Consumer</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">AC0</td>
                <td class="text-left" rowspan="1" colspan="1">AC representing all participants</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(MCC0)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(MCC1,MCC2)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(MCC3,MCC4,MCC5)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(MCC6,MCC7,MCC8,MCC9)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(AC0)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-12.1.3-3">
   If/when a presentation Stream becomes active within the Conference,
   the MCU might re-advertise the available Media as:<a href="#section-12.1.3-3" class="pilcrow">¶</a></p>
<span id="name-mcu-presentation-capture-sc"></span><div id="ref-mcu-presentation-capture-scene">
<table class="center" id="table-9">
            <caption>
<a href="#table-9" class="selfRef">Table 9</a>:
<a href="#name-mcu-presentation-capture-sc" class="selfRef">MCU Presentation Capture Scene</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #2</th>
                <th class="text-left" rowspan="1" colspan="1">Note</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC10</td>
                <td class="text-left" rowspan="1" colspan="1">Video Capture for presentation</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">AC1</td>
                <td class="text-left" rowspan="1" colspan="1">Presentation audio to accompany VC10</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC10)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(AC1)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
</section>
</div>
</section>
</div>
<div id="s-12.2">
<section id="section-12.2">
        <h3 id="name-media-consumer-behavior">
<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-media-consumer-behavior" class="section-name selfRef">Media Consumer Behavior</a>
        </h3>
<p id="section-12.2-1">
   This section gives an example of how a Media Consumer might behave
   when deciding how to request Streams from the three-screen
   Endpoint described in the previous section.<a href="#section-12.2-1" class="pilcrow">¶</a></p>
<p id="section-12.2-2">
   The receive side of a call needs to balance its requirements
   (based on number of screens and speakers), its decoding capabilities,
   available bandwidth, and the Provider's capabilities in order
   to optimally configure the Provider's Streams.  Typically, it would
   want to receive and decode Media from each Capture Scene
   advertised by the Provider.<a href="#section-12.2-2" class="pilcrow">¶</a></p>
<p id="section-12.2-3">
   A sane, basic, algorithm might be for the Consumer to go through
   each CSV in turn and find the collection of Video
   Captures that best matches the number of screens it has (this
   might include consideration of screens dedicated to presentation
   video display rather than "people" video) and then decide between
   alternative views in the video Capture Scenes based either on
   hard-coded preferences or on user choice.  Once this choice has been
   made, the Consumer would then decide how to configure the
   Provider's Encoding Groups in order to make best use of the
   available network bandwidth and its own decoding capabilities.<a href="#section-12.2-3" class="pilcrow">¶</a></p>
<div id="s-12.2.1">
<section id="section-12.2.1">
          <h4 id="name-one-screen-media-consumer">
<a href="#section-12.2.1" class="section-number selfRef">12.2.1. </a><a href="#name-one-screen-media-consumer" class="section-name selfRef">One-Screen Media Consumer</a>
          </h4>
<p id="section-12.2.1-1">
   MCC3, MCC4, and VC5 are all different views by themselves, not
   grouped together in a single view; so, the receiving device should
   choose between one of those.  The choice would come down to
   whether to see the greatest number of participants simultaneously
   at roughly equal precedence (VC5), a switched view of just the
   loudest region (MCC3), or a switched view with PiPs (MCC4).  An
   Endpoint device with a small amount of knowledge of these
   differences could offer a dynamic choice of these options, in-call, to the user.<a href="#section-12.2.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-12.2.2">
<section id="section-12.2.2">
          <h4 id="name-two-screen-media-consumer-c">
<a href="#section-12.2.2" class="section-number selfRef">12.2.2. </a><a href="#name-two-screen-media-consumer-c" class="section-name selfRef">Two-Screen Media Consumer Configuring the Example</a>
          </h4>
<p id="section-12.2.2-1">
   Mixing systems with an even number of screens, "2n", and those
   with "2n+1" cameras (and vice versa) is always likely to be the
   problematic case.  In this instance, the behavior is likely to be
   determined by whether a "two-screen" system is really a "two-decoder"
   system, i.e., whether only one received Stream can be displayed
   per screen or whether more than two Streams can be received and
   spread across the available screen area.  To enumerate three possible
   behaviors here for the two-screen system when it learns that the far
   end is "ideally" expressed via three Capture Streams:<a href="#section-12.2.2-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-12.2.2-2">
            <li id="section-12.2.2-2.1">Fall back to receiving just a single Stream (MCC3, MCC4, or VC5
      as per the one-screen Consumer case above) and either leave one
      screen blank or use it for presentation if/when a
      presentation becomes active.<a href="#section-12.2.2-2.1" class="pilcrow">¶</a>
</li>
            <li id="section-12.2.2-2.2">Receive three Streams (VC0, VC1, and VC2) and display across two
      screens (either with each Capture being scaled to 2/3 of a
      screen and the center Capture being split across two screens), or,
      as would be necessary if there were large bezels on the
      screens, with each Stream being scaled to 1/2 the screen width
      and height and there being a fourth "blank" panel.  This fourth panel
      could potentially be used for any presentation that became
      active during the call.<a href="#section-12.2.2-2.2" class="pilcrow">¶</a>
</li>
            <li id="section-12.2.2-2.3">Receive three Streams, decode all three, and use control information
      indicating which was the most active to switch between showing
      the left and center Streams (one per screen) and the center and
      right Streams.<a href="#section-12.2.2-2.3" class="pilcrow">¶</a>
</li>
          </ol>
<p id="section-12.2.2-3">
   For an Endpoint capable of all three methods of working described
   above, again it might be appropriate to offer the user the choice
   of display mode.<a href="#section-12.2.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-12.2.3">
<section id="section-12.2.3">
          <h4 id="name-three-screen-media-consumer">
<a href="#section-12.2.3" class="section-number selfRef">12.2.3. </a><a href="#name-three-screen-media-consumer" class="section-name selfRef">Three-Screen Media Consumer Configuring the Example</a>
          </h4>
<p id="section-12.2.3-1">
   This is the most straightforward case: the Media Consumer would
   look to identify a set of Streams to receive that best matched its
   available screens; so, the VC0 plus VC1 plus VC2 should match
   optimally.  The spatial ordering would give sufficient information
   for the correct Video Capture to be shown on the correct screen.
The Consumer would need to divide a single Encoding
Group's capability by 3 either to determine what resolution and frame
rate to configure the Provider with or to configure the individual
Video Captures' Encoding Groups with what makes most sense (taking
into account the receive side decode capabilities, overall call
bandwidth, the resolution of the screens plus any user preferences
such as motion vs. sharpness).<a href="#section-12.2.3-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="s-12.3">
<section id="section-12.3">
        <h3 id="name-multipoint-conference-utili">
<a href="#section-12.3" class="section-number selfRef">12.3. </a><a href="#name-multipoint-conference-utili" class="section-name selfRef">Multipoint Conference Utilizing Multiple Content Captures</a>
        </h3>
<p id="section-12.3-1">
   The use of MCCs allows the MCU to construct outgoing Advertisements
   describing complex Media switching and composition scenarios.  The
   following sections provide several examples.<a href="#section-12.3-1" class="pilcrow">¶</a></p>
<p id="section-12.3-2">
   Note: in the examples the identities of the CLUE elements (e.g.,
   Captures, Capture Scene) in the incoming Advertisements overlap.
   This is because there is no coordination between the Endpoints.
   The MCU is responsible for making these unique in the outgoing
   Advertisement.<a href="#section-12.3-2" class="pilcrow">¶</a></p>
<div id="s-12.3.1">
<section id="section-12.3.1">
          <h4 id="name-single-media-captures-and-m">
<a href="#section-12.3.1" class="section-number selfRef">12.3.1. </a><a href="#name-single-media-captures-and-m" class="section-name selfRef">Single Media Captures and MCC in the Same Advertisement</a>
          </h4>
<p id="section-12.3.1-1">
   Four Endpoints are involved in a Conference where CLUE is used. An
   MCU acts as a middlebox between the Endpoints with a CLUE channel
   between each Endpoint and the MCU. The MCU receives the following
   Advertisements.<a href="#section-12.3.1-1" class="pilcrow">¶</a></p>
<span id="name-advertisement-received-from"></span><div id="ref-advertisement-received-from-endpoint-a">
<table class="center" id="table-10">
            <caption>
<a href="#table-10" class="selfRef">Table 10</a>:
<a href="#name-advertisement-received-from" class="selfRef">Advertisement Received from Endpoint A</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1"> Capture Scene #1</th>
                <th class="text-left" rowspan="1" colspan="1"> Description=AustralianConfRoom</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC1</td>
                <td class="text-left" rowspan="1" colspan="1">Description=Audience<br>EncodeGroupID=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC1)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<span id="name-advertisement-received-from-"></span><div id="ref-advertisement-received-from-endpoint-b">
<table class="center" id="table-11">
            <caption>
<a href="#table-11" class="selfRef">Table 11</a>:
<a href="#name-advertisement-received-from-" class="selfRef">Advertisement Received from Endpoint B</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1"> Capture Scene #1</th>
                <th class="text-left" rowspan="1" colspan="1"> Description=ChinaConfRoom</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC1</td>
                <td class="text-left" rowspan="1" colspan="1">Description=Speaker<br>EncodeGroupID=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC2</td>
                <td class="text-left" rowspan="1" colspan="1">Description=Audience<br>EncodeGroupID=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC1, VC2)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-12.3.1-4" class="keepWithPrevious">Note: Endpoint B indicates that it sends two Streams.<a href="#section-12.3.1-4" class="pilcrow">¶</a></p>
<span id="name-advertisement-received-from-e"></span><div id="ref-advertisement-received-from-endpoint-c">
<table class="center" id="table-12">
            <caption>
<a href="#table-12" class="selfRef">Table 12</a>:
<a href="#name-advertisement-received-from-e" class="selfRef">Advertisement Received from Endpoint C</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1"> Capture Scene #1</th>
                <th class="text-left" rowspan="1" colspan="1"> Description=USAConfRoom</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC1</td>
                <td class="text-left" rowspan="1" colspan="1">Description=Audience<br>EncodeGroupID=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC1)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-12.3.1-6">
     If the MCU wanted to provide a Multiple Content Captures containing
     a round-robin switched view of the audience from the three Endpoints
   and the speaker, it could construct the following Advertisement:<a href="#section-12.3.1-6" class="pilcrow">¶</a></p>
<span id="name-advertisement-sent-to-endpo"></span><div id="ref-advertisement-sent-to-endpoint-f-one-encoding">
<table class="center" id="table-13">
            <caption>
<a href="#table-13" class="selfRef">Table 13</a>:
<a href="#name-advertisement-sent-to-endpo" class="selfRef">Advertisement Sent to Endpoint F - One Encoding</a>
            </caption>
<tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #1</th>
                <th class="text-left" rowspan="1" colspan="1">Description=AustralianConfRoom</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC1</td>
                <td class="text-left" rowspan="1" colspan="1">Description=Audience</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC1)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
            <tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #2</th>
                <th class="text-left" rowspan="1" colspan="1">Description=ChinaConfRoom</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC2</td>
                <td class="text-left" rowspan="1" colspan="1">Description=Speaker</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC3</td>
                <td class="text-left" rowspan="1" colspan="1">Description=Audience</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC2, VC3)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
            <tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #3</th>
                <th class="text-left" rowspan="1" colspan="1">Description=USAConfRoom</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC4</td>
                <td class="text-left" rowspan="1" colspan="1">Description=Audience</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC4)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
            <tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #4</th>
                <th class="text-left" rowspan="1" colspan="1"></th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC1(VC1,VC2,VC3,VC4)</td>
                <td class="text-left" rowspan="1" colspan="1">Policy=RoundRobin:1<br>           
                MaxCaptures=1<br>                 
                EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(MCC1)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-12.3.1-8">
     Alternatively, if the MCU wanted to provide the speaker as one Media
   Stream and the audiences as another, it could assign an Encoding
   Group to VC2 in Capture Scene 2 and provide a CSV in Capture Scene
   #4 as per the example below.<a href="#section-12.3.1-8" class="pilcrow">¶</a></p>
<span id="name-advertisement-sent-to-endpoi"></span><div id="ref-advertisement-sent-to-endpoint-f-two-encodings">
<table class="center" id="table-14">
            <caption>
<a href="#table-14" class="selfRef">Table 14</a>:
<a href="#name-advertisement-sent-to-endpoi" class="selfRef">Advertisement Sent to Endpoint F - Two Encodings</a>
            </caption>
<tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1"> Capture Scene #1</th>
                <th class="text-left" rowspan="1" colspan="1"> Description=AustralianConfRoom</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC1</td>
                <td class="text-left" rowspan="1" colspan="1">Description=Audience</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC1)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
            <tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #2</th>
                <th class="text-left" rowspan="1" colspan="1">Description=ChinaConfRoom</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC2</td>
                <td class="text-left" rowspan="1" colspan="1">Description=Speaker
                                  <br>EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC3</td>
                <td class="text-left" rowspan="1" colspan="1">Description=Audience</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC2, VC3)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
            <tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #3</th>
                <th class="text-left" rowspan="1" colspan="1">Description=USAConfRoom</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC4</td>
                <td class="text-left" rowspan="1" colspan="1">Description=Audience</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC4)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
            <tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #4</th>
                <th class="text-left" rowspan="1" colspan="1"></th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC1(VC1,VC3,VC4)</td>
                <td class="text-left" rowspan="1" colspan="1">Policy=RoundRobin:1
                                  <br>MaxCaptures=1
                                  <br>EncodingGroup=1
                                  <br>AllowSubset=True</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC2(VC2)</td>
                <td class="text-left" rowspan="1" colspan="1">MaxCaptures=1
                                   <br>EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV2(MCC1,MCC2)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-12.3.1-10">
   Therefore, a Consumer could choose whether or not to have a separate
   speaker-related Stream and could choose which Endpoints to see.  If
   it wanted the second Stream but not the Australian conference room,
   it could indicate the following Captures in the Configure message:<a href="#section-12.3.1-10" class="pilcrow">¶</a></p>
<span id="name-mcu-case-consumer-response"></span><div id="table_15">
<table class="center" id="table-15">
            <caption>
<a href="#table-15" class="selfRef">Table 15</a>:
<a href="#name-mcu-case-consumer-response" class="selfRef">MCU Case: Consumer Response</a>
            </caption>
<tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC1(VC3,VC4)</td>
                <td class="text-left" rowspan="1" colspan="1">Encoding</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC2</td>
                <td class="text-left" rowspan="1" colspan="1">Encoding</td>
              </tr>
            </tbody>
          </table>
</div>
</section>
</div>
<div id="s-12.3.2">
<section id="section-12.3.2">
          <h4 id="name-several-mccs-in-the-same-ad">
<a href="#section-12.3.2" class="section-number selfRef">12.3.2. </a><a href="#name-several-mccs-in-the-same-ad" class="section-name selfRef">Several MCCs in the Same Advertisement</a>
          </h4>
<p id="section-12.3.2-1">

   Multiple MCCs can be used where multiple Streams are used to carry
   Media from multiple Endpoints.  For example:<a href="#section-12.3.2-1" class="pilcrow">¶</a></p>
<p id="section-12.3.2-2">
   A Conference has three Endpoints D, E, and F. Each Endpoint has
   three Video Captures covering the left, middle, and right regions of
   each conference room.  The MCU receives the following
   Advertisements from D and E.<a href="#section-12.3.2-2" class="pilcrow">¶</a></p>
<span id="name-advertisement-received-from-en"></span><div id="ref-advertisement-received-from-endpoint-d">
<table class="center" id="table-16">
            <caption>
<a href="#table-16" class="selfRef">Table 16</a>:
<a href="#name-advertisement-received-from-en" class="selfRef">Advertisement Received from Endpoint D</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1"> Capture Scene #1</th>
                <th class="text-left" rowspan="1" colspan="1"> Description=AustralianConfRoom</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC1</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Left</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC2</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Center</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC3</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Right</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC1,VC2,VC3)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<span id="name-advertisement-received-from-end"></span><div id="ref-advertisement-received-from-endpoint-e">
<table class="center" id="table-17">
            <caption>
<a href="#table-17" class="selfRef">Table 17</a>:
<a href="#name-advertisement-received-from-end" class="selfRef">Advertisement Received from Endpoint E</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1"> Capture Scene #1</th>
                <th class="text-left" rowspan="1" colspan="1"> Description=ChinaConfRoom</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC1</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Left</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC2</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Center</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC3</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Right</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC1,VC2,VC3)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-12.3.2-5">
   The MCU wants to offer Endpoint F three Capture Encodings.  Each
   Capture Encoding would contain all the Captures from either
   Endpoint D or Endpoint E, depending on the active speaker.
   The MCU sends the following Advertisement:<a href="#section-12.3.2-5" class="pilcrow">¶</a></p>
<span id="name-advertisement-sent-to-endpoin"></span><div id="ref-advertisement-sent-to-endpoint-f">
<table class="center" id="table-18">
            <caption>
<a href="#table-18" class="selfRef">Table 18</a>:
<a href="#name-advertisement-sent-to-endpoin" class="selfRef">Advertisement Sent to Endpoint F</a>
            </caption>
<tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #1</th>
                <th class="text-left" rowspan="1" colspan="1">Description=AustralianConfRoom</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC1</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC2</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC3</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC1,VC2,VC3)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
            <tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #2</th>
                <th class="text-left" rowspan="1" colspan="1">Description=ChinaConfRoom</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC4</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC5</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC6</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC4,VC5,VC6)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
            <tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #3</th>
                <th class="text-left" rowspan="1" colspan="1"></th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC1(VC1,VC4)</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Left
                                       <br>MaxCaptures=1
                                       <br>SynchronizationID=1
                                       <br>EncodingGroup=1
     </td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC2(VC2,VC5)</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Center
                                       <br>MaxCaptures=1
                                       <br>SynchronizationID=1
                                       <br>EncodingGroup=1
     </td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC3(VC3,VC6)</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Right
                                       <br>MaxCaptures=1
                                       <br>SynchronizationID=1
                                       <br>EncodingGroup=1
     </td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(MCC1,MCC2,MCC3)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
</section>
</div>
<div id="s-12.3.3">
<section id="section-12.3.3">
          <h4 id="name-heterogeneous-conference-wi">
<a href="#section-12.3.3" class="section-number selfRef">12.3.3. </a><a href="#name-heterogeneous-conference-wi" class="section-name selfRef">Heterogeneous Conference with Switching and Composition</a>
          </h4>
<p id="section-12.3.3-1">
   Consider a Conference between Endpoints with the following
   characteristics:<a href="#section-12.3.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-12.3.3-2">
            <dt id="section-12.3.3-2.1">Endpoint A -</dt>
            <dd style="margin-left: 1.5em" id="section-12.3.3-2.2">4 screens, 3 cameras<a href="#section-12.3.3-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.3.3-2.3">Endpoint B -</dt>
            <dd style="margin-left: 1.5em" id="section-12.3.3-2.4">3 screens, 3 cameras<a href="#section-12.3.3-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.3.3-2.5">Endpoint C -</dt>
            <dd style="margin-left: 1.5em" id="section-12.3.3-2.6">3 screens, 3 cameras<a href="#section-12.3.3-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.3.3-2.7">Endpoint D -</dt>
            <dd style="margin-left: 1.5em" id="section-12.3.3-2.8">3 screens, 3 cameras<a href="#section-12.3.3-2.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.3.3-2.9">Endpoint E -</dt>
            <dd style="margin-left: 1.5em" id="section-12.3.3-2.10">1 screen, 1 camera<a href="#section-12.3.3-2.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.3.3-2.11">Endpoint F -</dt>
            <dd style="margin-left: 1.5em" id="section-12.3.3-2.12">2 screens, 1 camera<a href="#section-12.3.3-2.12" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.3.3-2.13">Endpoint G -</dt>
            <dd style="margin-left: 1.5em" id="section-12.3.3-2.14">1 screen, 1 camera<a href="#section-12.3.3-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-12.3.3-3">
   This example focuses on what the user in one of the three-camera
   multi-screen Endpoints sees.  Call this person User A, at Endpoint
   A.  There are four large display screens at Endpoint A. Whenever
   somebody at another site is speaking, all the Video Captures from
   that Endpoint are shown on the large screens.  If the talker is at
   a three-camera site, then the video from those three cameras fills three of
   the screens.  If the person speaking is at a single-camera site, then video
   from that camera fills one of the screens, while the other screens
   show video from other single-camera Endpoints.<a href="#section-12.3.3-3" class="pilcrow">¶</a></p>
<p id="section-12.3.3-4">
   User A hears audio from the four loudest talkers.<a href="#section-12.3.3-4" class="pilcrow">¶</a></p>
<p id="section-12.3.3-5">
   User A can also see video from other Endpoints, in addition to the
   current person speaking, although much smaller in size.  Endpoint A has four
   screens, so one of those screens shows up to nine other Media Captures
   in a tiled fashion.  When video from a three-camera Endpoint appears in
   the tiled area, video from all three cameras appears together across
   the screen with correct Spatial Relationship among those three images.<a href="#section-12.3.3-5" class="pilcrow">¶</a></p>
<span id="name-endpoint-a-four-screen-disp"></span><div id="ref-endpoint-a-4-screen-display">
<figure id="figure-8">
            <div class="artwork art-text alignLeft" id="section-12.3.3-6.1">
<pre>
   +---+---+---+ +-------------+ +-------------+ +-------------+
   |   |   |   | |             | |             | |             |
   +---+---+---+ |             | |             | |             |
   |   |   |   | |             | |             | |             |
   +---+---+---+ |             | |             | |             |
   |   |   |   | |             | |             | |             |
   +---+---+---+ +-------------+ +-------------+ +-------------+
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-endpoint-a-four-screen-disp" class="selfRef">Endpoint A - Four-Screen Display</a>
            </figcaption></figure>
</div>
<p id="section-12.3.3-7">
   User B at Endpoint B sees a similar arrangement, except there are
   only three screens, so the nine other Media Captures are spread out across
   the bottom of the three displays, in a PiP format.
   When video from a three-camera Endpoint appears in the PiP area, video
   from all three cameras appears together across one screen with
   correct Spatial Relationship.<a href="#section-12.3.3-7" class="pilcrow">¶</a></p>
<span id="name-endpoint-b-three-screen-dis"></span><div id="ref-endpoint-b-3-screen-display-with-pips">
<figure id="figure-9">
            <div class="artwork art-text alignLeft" id="section-12.3.3-8.1">
<pre>
           +-------------+ +-------------+ +-------------+
           |             | |             | |             |
           |             | |             | |             |
           |             | |             | |             |
           | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ |
           | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ |
           +-------------+ +-------------+ +-------------+
</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-endpoint-b-three-screen-dis" class="selfRef">Endpoint B - Three-Screen Display with PiPs</a>
            </figcaption></figure>
</div>
<p id="section-12.3.3-9">
   When somebody at a different Endpoint becomes the current speaker,
   then User A and User B both see the video from the new person speaking
   appear on their large screen area, while the previous speaker takes
   one of the smaller tiled or PiP areas.  The person who is the
   current speaker doesn't see themselves; they see the previous speaker
   in their large screen area.<a href="#section-12.3.3-9" class="pilcrow">¶</a></p>
<p id="section-12.3.3-10">
   One of the points of this example is that Endpoints A and B each
   want to receive three Capture Encodings for their large display areas,
   and nine Encodings for their smaller areas.  A and B are be able to
   each send the same Configure message to the MCU, and each receive
   the same conceptual Media Captures from the MCU.  The differences
   are in how they are Rendered and are purely a local matter at A and
   B.<a href="#section-12.3.3-10" class="pilcrow">¶</a></p>
<p id="section-12.3.3-11">The Advertisements for such a scenario are described below.<a href="#section-12.3.3-11" class="pilcrow">¶</a></p>
<span id="name-advertisement-received-at-t"></span><div id="ref-advertisement-received-at-the-mcu-from-endpoints-a-to-d">
<table class="center" id="table-19">
            <caption>
<a href="#table-19" class="selfRef">Table 19</a>:
<a href="#name-advertisement-received-at-t" class="selfRef">Advertisement Received at the MCU from Endpoints A to D</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1"> Capture Scene #1</th>
                <th class="text-left" rowspan="1" colspan="1"> Description=Endpoint x</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC1</td>
                <td class="text-left" rowspan="1" colspan="1">EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC2</td>
                <td class="text-left" rowspan="1" colspan="1">EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC3</td>
                <td class="text-left" rowspan="1" colspan="1">EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">AC1</td>
                <td class="text-left" rowspan="1" colspan="1">EncodingGroup=2</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV1(VC1, VC2, VC3)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV2(AC1)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<span id="name-advertisement-received-at-th"></span><div id="ref-advertisement-received-at-the-mcu-from-endpoints-e-to-g">
<table class="center" id="table-20">
            <caption>
<a href="#table-20" class="selfRef">Table 20</a>:
<a href="#name-advertisement-received-at-th" class="selfRef">Advertisement Received at the MCU from Endpoints E to G</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1"> Capture Scene #1</th>
                <th class="text-left" rowspan="1" colspan="1"> Description=Endpoint y</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC1</td>
                <td class="text-left" rowspan="1" colspan="1">EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">AC1</td>
                <td class="text-left" rowspan="1" colspan="1">EncodingGroup=2</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV1(VC1)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV2(AC1)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-12.3.3-14">
   Rather than considering what is displayed, CLUE concentrates more
   on what the MCU sends. The MCU doesn't know anything about the
   number of screens an Endpoint has.<a href="#section-12.3.3-14" class="pilcrow">¶</a></p>
<p id="section-12.3.3-15">
   As Endpoints A to D each advertise that three Captures make up a
   Capture Scene, the MCU offers these in a "site switching" mode.
   That is, there are three Multiple Content Captures (and
   Capture Encodings) each switching between Endpoints. The MCU
   switches in the applicable Media into the Stream based on voice
   activity. Endpoint A will not see a Capture from itself.<a href="#section-12.3.3-15" class="pilcrow">¶</a></p>
<p id="section-12.3.3-16">
   Using the MCC concept, the MCU would send the following
   Advertisement to Endpoint A:<a href="#section-12.3.3-16" class="pilcrow">¶</a></p>
<span id="name-advertisement-sent-to-endpoint"></span><div id="ref-advertisement-sent-to-endpoint-a-source-part">
<table class="center" id="table-21">
            <caption>
<a href="#table-21" class="selfRef">Table 21</a>:
<a href="#name-advertisement-sent-to-endpoint" class="selfRef">Advertisement Sent to Endpoint A - Source Part</a>
            </caption>
<tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #1</th>
                <th class="text-left" rowspan="1" colspan="1">Description=Endpoint B</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC4</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Left</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC5</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Center</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC6</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Right</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">AC1</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC4,VC5,VC6)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(AC1)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
            <tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #2</th>
                <th class="text-left" rowspan="1" colspan="1">Description=Endpoint C</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC7</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Left</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC8</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Center</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC9</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Right</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">AC2</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC7,VC8,VC9)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(AC2)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
            <tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #3</th>
                <th class="text-left" rowspan="1" colspan="1">Description=Endpoint D</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC10</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Left</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC11</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Center</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC12</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Right</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">AC3</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC10,VC11,VC12)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(AC3)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
            <tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #4</th>
                <th class="text-left" rowspan="1" colspan="1">Description=Endpoint E</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC13</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">AC4</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC13)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(AC4)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
            <tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #5</th>
                <th class="text-left" rowspan="1" colspan="1">Description=Endpoint F</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC14</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">AC5</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC14)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(AC5)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
            <tbody>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #6</th>
                <th class="text-left" rowspan="1" colspan="1">Description=Endpoint G</th>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC15</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">AC6</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(VC15)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(AC6)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-12.3.3-18">
   The above part of the Advertisement presents information about the
   sources to the MCC. The information is effectively the same as the
   received Advertisements, except that there are no Capture Encodings
   associated with them and the identities have been renumbered.<a href="#section-12.3.3-18" class="pilcrow">¶</a></p>
<p id="section-12.3.3-19">
   In addition to the source Capture information, the MCU advertises
   site switching of Endpoints B to G in three Streams.<a href="#section-12.3.3-19" class="pilcrow">¶</a></p>
<span id="name-advertisement-sent-to-endpoint-"></span><div id="table_22">
<table class="center" id="table-22">
            <caption>
<a href="#table-22" class="selfRef">Table 22</a>:
<a href="#name-advertisement-sent-to-endpoint-" class="selfRef">Advertisement Sent to Endpoint A - Switching Parts</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #7</th>
                <th class="text-left" rowspan="1" colspan="1">Description=Output3streammix</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC1(VC4,VC7,VC10,VC13)</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Left
                                            <br>MaxCaptures=1
                                            <br>SynchronizationID=1
                                            <br>Policy=SoundLevel:0
                                            <br>EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC2(VC5,VC8,VC11,VC14)</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Center
                                          <br>MaxCaptures=1
                                          <br>SynchronizationID=1
                                          <br>Policy=SoundLevel:0
                                          <br>EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC3(VC6,VC9,VC12,VC15)</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Right
                                          <br>MaxCaptures=1
                                          <br>SynchronizationID=1
                                          <br>Policy=SoundLevel:0
                                          <br>EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC4() (for audio)</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=whole Scene
                                          <br>MaxCaptures=1
                                          <br>Policy=SoundLevel:0
                                          <br>EncodingGroup=2</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC5() (for audio)</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=whole Scene
                                          <br>MaxCaptures=1
                                          <br>Policy=SoundLevel:1
                                          <br>EncodingGroup=2</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC6() (for audio)</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=whole Scene
                                          <br>MaxCaptures=1
                                          <br>Policy=SoundLevel:2
                                          <br>EncodingGroup=2</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC7() (for audio)</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=whole Scene
                                          <br>MaxCaptures=1
                                          <br>Policy=SoundLevel:3
                                          <br>EncodingGroup=2</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(MCC1,MCC2,MCC3)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(MCC4,MCC5,MCC6,MCC7)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-12.3.3-21">
   The above part describes the three main switched Streams that relate to
   site switching. MaxCaptures=1 indicates that only one Capture from
   the MCC is sent at a particular time. SynchronizationID=1 indicates
   that the source sending is synchronized. The Provider can choose to
   group together VC13, VC14, and VC15 for the purpose of switching
   according to the SynchronizationID.  Therefore, when the Provider
   switches one of them into an MCC, it can also switch the others
   even though they are not part of the same Capture Scene.<a href="#section-12.3.3-21" class="pilcrow">¶</a></p>
<p id="section-12.3.3-22">
   All the audio for the Conference is included in Scene #7.
   There isn't necessarily a one-to-one relation between any Audio
   Capture and Video Capture in this Scene.  Typically, a change in
   the loudest talker will cause the MCU to switch the audio Streams more
   quickly than switching video Streams.<a href="#section-12.3.3-22" class="pilcrow">¶</a></p>
<p id="section-12.3.3-23">
   The MCU can also supply nine Media Streams showing the active and
   previous eight speakers. It includes the following in the
   Advertisement:<a href="#section-12.3.3-23" class="pilcrow">¶</a></p>
<span id="name-advertisement-sent-to-endpoint-a"></span><div id="table_23">
<table class="center" id="table-23">
            <caption>
<a href="#table-23" class="selfRef">Table 23</a>:
<a href="#name-advertisement-sent-to-endpoint-a" class="selfRef">Advertisement Sent to Endpoint A - 9 Switched Parts</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #8</th>
                <th class="text-left" rowspan="1" colspan="1">Description=Output9stream</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-right" rowspan="1" colspan="1">MCC8(VC4,VC5,VC6,VC7,   
        <br>VC8,VC9,VC10,VC11,    
        <br>VC12,VC13,VC14,VC15)</td>
                <td class="text-left" rowspan="1" colspan="1">MaxCaptures=1
 <br>Policy=SoundLevel:0 
 <br>EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-right" rowspan="1" colspan="1">MCC9(VC4,VC5,VC6,VC7,
          <br>VC8,VC9,VC10,VC11,
          <br>VC12,VC13,VC14,VC15)
   </td>
                <td class="text-left" rowspan="1" colspan="1">MaxCaptures=1
   <br>Policy=SoundLevel:1  
   <br>EncodingGroup=1</td>
              </tr>
              <tr>
                <th class="text-center" rowspan="1" colspan="1">to</th>
                <th class="text-center" rowspan="1" colspan="1">to</th>
              </tr>
              <tr>
                <td class="text-right" rowspan="1" colspan="1">MCC16(VC4,VC5,VC6,VC7,
          <br>VC8,VC9,VC10,VC11,
          <br>VC12,VC13,VC14,VC15)</td>
                <td class="text-left" rowspan="1" colspan="1">MaxCaptures=1 
   <br>Policy=SoundLevel:8  
   <br>EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-right" rowspan="1" colspan="1">CSV(MCC8,MCC9,MCC10,
            <br>MCC11,MCC12,MCC13,
            <br>MCC14,MCC15,MCC16)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-12.3.3-25">
   The above part indicates that there are nine Capture Encodings. Each
   of the Capture Encodings may contain any Captures from any source
   site with a maximum of one Capture at a time. Which Capture is
   present is determined by the policy.  The MCCs in this Scene do not
   have any spatial attributes.<a href="#section-12.3.3-25" class="pilcrow">¶</a></p>
<p id="section-12.3.3-26">
   Note: The Provider alternatively could provide each of the MCCs
   above in its own Capture Scene.<a href="#section-12.3.3-26" class="pilcrow">¶</a></p>
<p id="section-12.3.3-27">
   If the MCU wanted to provide a composed Capture Encoding containing
   all of the nine Captures, it could advertise in addition:<a href="#section-12.3.3-27" class="pilcrow">¶</a></p>
<span id="name-advertisement-sent-to-endpoint-a-"></span><div id="ref-advertisement-sent-to-endpoint-a-9-composed-part">
<table class="center" id="table-24">
            <caption>
<a href="#table-24" class="selfRef">Table 24</a>:
<a href="#name-advertisement-sent-to-endpoint-a-" class="selfRef">Advertisement Sent to Endpoint A - 9 Composed Parts</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #9</th>
                <th class="text-left" rowspan="1" colspan="1">Description=NineTiles</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-right" rowspan="1" colspan="1">MCC13(MCC8,MCC9,MCC10,<br>
     MCC11,MCC12,MCC13,<br>
     MCC14,MCC15,MCC16)</td>
                <td class="text-left" rowspan="1" colspan="1">MaxCaptures=9<br>
  EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV(MCC13)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-12.3.3-29">
   As MaxCaptures is 9, it indicates that the Capture Encoding contains
   information from nine sources at a time.<a href="#section-12.3.3-29" class="pilcrow">¶</a></p>
<p id="section-12.3.3-30">
   The Advertisement to Endpoint B is identical to the above, other
   than the fact that Captures from Endpoint A would be added and the Captures
   from Endpoint B would be removed. Whether the Captures are Rendered
   on a four-screen display or a three-screen display is up to the
   Consumer to determine.  The Consumer wants to place Video Captures
   from the same original source Endpoint together, in the correct
   spatial order, but the MCCs do not have spatial attributes.  So, the
   Consumer needs to associate incoming Media packets with the
   original individual Captures in the Advertisement (such as VC4,
   VC5, and VC6) in order to know the spatial information it needs for
   correct placement on the screens.  The Provider can use the RTCP
   CaptureId source description (SDES) item and associated RTP header extension, as
   described in <span>[<a href="#RFC8849" class="xref">RFC8849</a>]</span>, to convey this
   information to the Consumer.<a href="#section-12.3.3-30" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-12.3.4">
<section id="section-12.3.4">
          <h4 id="name-heterogeneous-conference-wit">
<a href="#section-12.3.4" class="section-number selfRef">12.3.4. </a><a href="#name-heterogeneous-conference-wit" class="section-name selfRef">Heterogeneous Conference with Voice-Activated Switching</a>
          </h4>
<p id="section-12.3.4-1">
   This example illustrates how multipoint "voice-activated switching"
   behavior can be realized, with an Endpoint making its own decision
   about which of its outgoing video Streams is considered the "active talker" from that Endpoint.  Then, an MCU can decide which is the
   active talker among the whole Conference.<a href="#section-12.3.4-1" class="pilcrow">¶</a></p>
<p id="section-12.3.4-2">
   Consider a Conference between Endpoints with the following
   characteristics:<a href="#section-12.3.4-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-12.3.4-3">
            <dt id="section-12.3.4-3.1">Endpoint A -</dt>
            <dd style="margin-left: 1.5em" id="section-12.3.4-3.2">3 screens, 3 cameras<a href="#section-12.3.4-3.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.3.4-3.3">Endpoint B -</dt>
            <dd style="margin-left: 1.5em" id="section-12.3.4-3.4">3 screens, 3 cameras<a href="#section-12.3.4-3.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-12.3.4-3.5">Endpoint C -</dt>
            <dd style="margin-left: 1.5em" id="section-12.3.4-3.6">1 screen, 1 camera<a href="#section-12.3.4-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-12.3.4-4">
   This example focuses on what the user at Endpoint C sees.  The
   user would like to see the Video Capture of the current talker,
   without composing it with any other Video Capture.  In this
   example, Endpoint C is capable of receiving only a single video
   Stream.  The following tables describe Advertisements from Endpoints A and B
   to the MCU, and from the MCU to Endpoint C, that can be used to accomplish
   this.<a href="#section-12.3.4-4" class="pilcrow">¶</a></p>
<span id="name-advertisement-received-at-the"></span><div id="ref-advertisement-received-at-the-mcu-from-endpoints-a-and-b">
<table class="center" id="table-25">
            <caption>
<a href="#table-25" class="selfRef">Table 25</a>:
<a href="#name-advertisement-received-at-the" class="selfRef">Advertisement Received at the MCU from Endpoints A and B</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #1</th>
                <th class="text-left" rowspan="1" colspan="1">Description=Endpoint x</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC1</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Left
                              <br>EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC2</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Center
                               <br>EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">VC3</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Right 
                               <br>EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC1(VC1,VC2,VC3)</td>
                <td class="text-left" rowspan="1" colspan="1">MaxCaptures=1
                                <br>CaptureArea=whole Scene
                                <br>Policy=SoundLevel:0
                                <br>EncodingGroup=1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">AC1</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=whole Scene
                               <br>EncodingGroup=2</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV1(VC1, VC2, VC3)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV2(MCC1)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV3(AC1)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-12.3.4-6">
   Endpoints A and B are advertising each individual Video Capture,
   and also a switched Capture MCC1 that switches between the other
   three based on who is the active talker.  These Endpoints do not
   advertise distinct Audio Captures associated with each individual
   Video Capture, so it would be impossible for the MCU (as a Media
   Consumer) to make its own determination of which Video Capture is
   the active talker based just on information in the audio Streams.<a href="#section-12.3.4-6" class="pilcrow">¶</a></p>
<span id="name-advertisement-sent-from-the"></span><div id="ref-advertisement-sent-from-the-mcu-to-c">
<table class="center" id="table-26">
            <caption>
<a href="#table-26" class="selfRef">Table 26</a>:
<a href="#name-advertisement-sent-from-the" class="selfRef">Advertisement Sent from the MCU to Endpoint C</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Capture Scene #1</th>
                <th class="text-left" rowspan="1" colspan="1">Description=conference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC1()</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Left  
                <br>MaxCaptures=1       
                <br>SynchronizationID=1 
                <br>Policy=SoundLevel:0 
                <br>EncodingGroup=1     
       </td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC2()</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Center
                           <br>MaxCaptures=1       
                           <br>SynchronizationID=1 
                           <br>Policy=SoundLevel:0 
                           <br>EncodingGroup=1     
  </td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC3()</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=Right 
                           <br>MaxCaptures=1       
                           <br>SynchronizationID=1 
                           <br>Policy=SoundLevel:0 
                           <br>EncodingGroup=1     
  </td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC4()</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=whole Scene
                           <br>MaxCaptures=1            
                           <br>Policy=SoundLevel:0      
                           <br>EncodingGroup=1          
  </td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC5() (for audio)</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=whole Scene
                           <br>MaxCaptures=1            
                           <br>Policy=SoundLevel:0      
                           <br>EncodingGroup=2          
  </td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MCC6() (for audio)</td>
                <td class="text-left" rowspan="1" colspan="1">CaptureArea=whole Scene
                           <br>MaxCaptures=1            
                           <br>Policy=SoundLevel:1      
                           <br>EncodingGroup=2          
  </td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV1(MCC1,MCC2,MCC3)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV2(MCC4)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CSV3(MCC5,MCC6)</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-12.3.4-8">
   The MCU advertises one Scene, with four video MCCs.  Three of them
   in CSV1 give a left, center, and right view of the Conference, with
   site switching. MCC4 provides a single Video Capture
   representing a view of the whole Conference.  The MCU intends for
   MCC4 to be switched between all the other original source
   Captures.  In this example, Advertisement of the MCU is not giving all
   the information about all the other Endpoints' Scenes and which of
   those Captures are included in the MCCs.  The MCU could include all
   that if it wants to give the Consumers more
   information, but it is not necessary for this example scenario.<a href="#section-12.3.4-8" class="pilcrow">¶</a></p>
<p id="section-12.3.4-9">
   The Provider advertises MCC5 and MCC6 for audio.  Both are
   switched Captures, with different SoundLevel policies indicating
   they are the top two dominant talkers.  The Provider advertises
   CSV3 with both MCCs, suggesting the Consumer should use both if it
   can.<a href="#section-12.3.4-9" class="pilcrow">¶</a></p>
<p id="section-12.3.4-10">
   Endpoint C, in its Configure Message to the MCU, requests to
   receive MCC4 for video and MCC5 and MCC6 for audio.  In order for
   the MCU to get the information it needs to construct MCC4, it has
   to send Configure Messages to Endpoints A and B asking to receive MCC1 from
   each of them, along with their AC1 audio.  Now the MCU can use
   audio energy information from the two incoming audio Streams from
   Endpoints A and B to determine which of those alternatives is the current
   talker.  Based on that, the MCU uses either MCC1 from A or MCC1
   from B as the source of MCC4 to send to Endpoint C.<a href="#section-12.3.4-10" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="s-14">
<section id="section-13">
      <h2 id="name-iana-considerations">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-13-1">
This document has no IANA actions.<a href="#section-13-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="s-15">
<section id="section-14">
      <h2 id="name-security-considerations">
<a href="#section-14" class="section-number selfRef">14. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-14-1">
   There are several potential attacks related to telepresence, 
   specifically the protocols used by CLUE.  This is the case due to
   conferencing sessions, the natural involvement of multiple
   Endpoints, and the many, often user-invoked, capabilities provided
   by the systems.<a href="#section-14-1" class="pilcrow">¶</a></p>
<p id="section-14-2">
   An MCU involved in a CLUE session can experience many of the same
   attacks as a conferencing system such as the one enabled by
   the Conference
   Information Data Model for Centralized Conferencing (XCON) framework <span>[<a href="#RFC5239" class="xref">RFC5239</a>]</span>. Examples of attacks include the
   following: an Endpoint attempting to listen to sessions in which
   it is not authorized to participate, an Endpoint attempting to
   disconnect or mute other users, and theft of service by an
   Endpoint in attempting to create telepresence sessions it is not
   allowed to create. Thus, it is <span class="bcp14">RECOMMENDED</span> that an MCU
   implementing the protocols necessary to support CLUE follow the
   security recommendations specified in the conference control
   protocol documents.
  In the case of CLUE, SIP is the conferencing
   protocol, thus the security considerations in <span>[<a href="#RFC4579" class="xref">RFC4579</a>]</span> <span class="bcp14">MUST</span> be
   followed. Other security issues related to MCUs are discussed in
   the XCON framework <span>[<a href="#RFC5239" class="xref">RFC5239</a>]</span>. The use of xCard with potentially
   sensitive information provides another reason to implement
   recommendations in <span><a href="https://www.rfc-editor.org/rfc/rfc5239#section-11" class="relref">Section 11</a> of [<a href="#RFC5239" class="xref">RFC5239</a>]</span>.<a href="#section-14-2" class="pilcrow">¶</a></p>
<p id="section-14-3">
   One primary security concern, surrounding the CLUE framework
   introduced in this document, involves securing the actual
   protocols and the associated authorization mechanisms.  These
   concerns apply to Endpoint-to-Endpoint sessions as well as
   sessions involving multiple Endpoints and MCUs. <a href="#ref-basic-information-flow" class="xref">Figure 2</a> in
   <a href="#s-5" class="xref">Section 5</a> provides a basic flow of information exchange for CLUE
   and the protocols involved.<a href="#section-14-3" class="pilcrow">¶</a></p>
<p id="section-14-4">
   As described in <a href="#s-5" class="xref">Section 5</a>, CLUE uses SIP/SDP to
   establish the session prior to exchanging any CLUE-specific
   information. Thus, the security mechanisms recommended for SIP
   <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span>, including user authentication and
   authorization, <span class="bcp14">MUST</span> be supported. In addition, the Media <span class="bcp14">MUST</span> be
   secured. Datagram Transport Layer Security (DTLS) / Secure Real-time
   Transport Protocol (SRTP) <span class="bcp14">MUST</span> be supported and <span class="bcp14">SHOULD</span> be used unless the
   Media, which is based on RTP, is secured by other means (see <span>[<a href="#RFC7201" class="xref">RFC7201</a>]</span> <span>[<a href="#RFC7202" class="xref">RFC7202</a>]</span>).  Media security is
   also discussed in <span>[<a href="#RFC8848" class="xref">RFC8848</a>]</span> and <span>[<a href="#RFC8849" class="xref">RFC8849</a>]</span>. Note that SIP call setup is done before any
   CLUE-specific information is available, so the authentication and
   authorization are based on the SIP mechanisms. The entity that will
   be authenticated may use the Endpoint identity or the Endpoint user
   identity; this is an application issue and not a CLUE-specific
   issue.<a href="#section-14-4" class="pilcrow">¶</a></p>
<p id="section-14-5">
   A separate data channel is established to transport the CLUE
   protocol messages. The contents of the CLUE protocol messages are
   based on information introduced in this document.  The CLUE data
   model <span>[<a href="#RFC8846" class="xref">RFC8846</a>]</span> defines, through an XML
   schema, the syntax to be used. One type of information that could
   possibly introduce privacy concerns is the xCard information, as
   described in <a href="#s-7.1.1.10" class="xref">Section 7.1.1.10</a>. The decision about which xCard
   information to send in the CLUE channel is an application policy
   for point-to-point and multipoint calls based on the authenticated
   identity that can be the Endpoint identity or the user of the
   Endpoint. For example, the telepresence multipoint application can
   authenticate a user before starting a CLUE exchange with the
   telepresence system and have a policy per user.<a href="#section-14-5" class="pilcrow">¶</a></p>
<p id="section-14-6">
   In addition, the (text) description field in the Media Capture
   attribute (<a href="#s-7.1.1.6" class="xref">Section 7.1.1.6</a>) could possibly reveal sensitive
   information or specific identities. The same would be true for the
   descriptions in the Capture Scene (<a href="#s-7.3.1" class="xref">Section 7.3.1</a>) and CSV
   (<a href="#s-7.3.2" class="xref">Section 7.3.2</a>) attributes. An implementation <span class="bcp14">SHOULD</span> give users
   control over what sensitive information is sent in an
   Advertisement. One other important consideration for the
   information in the xCard as well as the description field in the
   Media Capture and CSV attributes is that while the
   Endpoints involved in the session have been authenticated, there
   are no assurance that the information in the xCard or description
   fields is authentic.  Thus, this information <span class="bcp14">MUST NOT</span> be used to
   make any authorization decisions.<a href="#section-14-6" class="pilcrow">¶</a></p>
<p id="section-14-7">
   While other information in the CLUE protocol messages does not
   reveal specific identities, it can reveal characteristics and
   capabilities of the Endpoints.  That information could possibly
   uniquely identify specific Endpoints.  It might also be possible
   for an attacker to manipulate the information and disrupt the CLUE
   sessions.  It would also be possible to mount a DoS attack on the
   CLUE Endpoints if a malicious agent has access to the data
   channel.  Thus, it <span class="bcp14">MUST</span> be possible for the Endpoints to establish
   a channel that is secure against both message recovery and
   message modification. Further details on this are provided in the
   CLUE data channel solution document <span>[<a href="#RFC8850" class="xref">RFC8850</a>]</span>.<a href="#section-14-7" class="pilcrow">¶</a></p>
<p id="section-14-8">
   There are also security issues associated with the authorization
   to perform actions at the CLUE Endpoints to invoke specific
   capabilities (e.g., rearranging screens, sharing content, etc.).
   However, the policies and security associated with these actions
   are outside the scope of this document and the overall CLUE
   solution.<a href="#section-14-8" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-15">
      <h2 id="name-references">
<a href="#section-15" class="section-number selfRef">15. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-15.1">
        <h3 id="name-normative-references">
<a href="#section-15.1" class="section-number selfRef">15.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3261">[RFC3261]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor">, Schulzrinne, H.</span><span class="refAuthor">, Camarillo, G.</span><span class="refAuthor">, Johnston, A.</span><span class="refAuthor">, Peterson, J.</span><span class="refAuthor">, Sparks, R.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, and E. Schooler</span>, <span class="refTitle">"SIP: Session Initiation Protocol"</span>, <span class="seriesInfo">RFC 3261</span>, <span class="seriesInfo">DOI 10.17487/RFC3261</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3261">https://www.rfc-editor.org/info/rfc3261</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3264">[RFC3264]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor"> and H. Schulzrinne</span>, <span class="refTitle">"An Offer/Answer Model with Session Description Protocol (SDP)"</span>, <span class="seriesInfo">RFC 3264</span>, <span class="seriesInfo">DOI 10.17487/RFC3264</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3264">https://www.rfc-editor.org/info/rfc3264</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3550">[RFC3550]</dt>
        <dd>
<span class="refAuthor">Schulzrinne, H.</span><span class="refAuthor">, Casner, S.</span><span class="refAuthor">, Frederick, R.</span><span class="refAuthor">, and V. Jacobson</span>, <span class="refTitle">"RTP: A Transport Protocol for Real-Time Applications"</span>, <span class="seriesInfo">STD 64</span>, <span class="seriesInfo">RFC 3550</span>, <span class="seriesInfo">DOI 10.17487/RFC3550</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3550">https://www.rfc-editor.org/info/rfc3550</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4566">[RFC4566]</dt>
        <dd>
<span class="refAuthor">Handley, M.</span><span class="refAuthor">, Jacobson, V.</span><span class="refAuthor">, and C. Perkins</span>, <span class="refTitle">"SDP: Session Description Protocol"</span>, <span class="seriesInfo">RFC 4566</span>, <span class="seriesInfo">DOI 10.17487/RFC4566</span>, <time datetime="2006-07" class="refDate">July 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4566">https://www.rfc-editor.org/info/rfc4566</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4579">[RFC4579]</dt>
        <dd>
<span class="refAuthor">Johnston, A.</span><span class="refAuthor"> and O. Levin</span>, <span class="refTitle">"Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents"</span>, <span class="seriesInfo">BCP 119</span>, <span class="seriesInfo">RFC 4579</span>, <span class="seriesInfo">DOI 10.17487/RFC4579</span>, <time datetime="2006-08" class="refDate">August 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4579">https://www.rfc-editor.org/info/rfc4579</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5239">[RFC5239]</dt>
        <dd>
<span class="refAuthor">Barnes, M.</span><span class="refAuthor">, Boulton, C.</span><span class="refAuthor">, and O. Levin</span>, <span class="refTitle">"A Framework for Centralized Conferencing"</span>, <span class="seriesInfo">RFC 5239</span>, <span class="seriesInfo">DOI 10.17487/RFC5239</span>, <time datetime="2008-06" class="refDate">June 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5239">https://www.rfc-editor.org/info/rfc5239</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5646">[RFC5646]</dt>
        <dd>
<span class="refAuthor">Phillips, A., Ed.</span><span class="refAuthor"> and M. Davis, Ed.</span>, <span class="refTitle">"Tags for Identifying Languages"</span>, <span class="seriesInfo">BCP 47</span>, <span class="seriesInfo">RFC 5646</span>, <span class="seriesInfo">DOI 10.17487/RFC5646</span>, <time datetime="2009-09" class="refDate">September 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5646">https://www.rfc-editor.org/info/rfc5646</a>&gt;</span>. </dd>
<dd class="break"></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" class="refDate">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>
<dd class="break"></dd>
<dt id="RFC6351">[RFC6351]</dt>
        <dd>
<span class="refAuthor">Perreault, S.</span>, <span class="refTitle">"xCard: vCard XML Representation"</span>, <span class="seriesInfo">RFC 6351</span>, <span class="seriesInfo">DOI 10.17487/RFC6351</span>, <time datetime="2011-08" class="refDate">August 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6351">https://www.rfc-editor.org/info/rfc6351</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8846">[RFC8846]</dt>
        <dd>
<span class="refAuthor">Presta, R.</span><span class="refAuthor"> and S P. Romano</span>, <span class="refTitle">"An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model"</span>, <span class="seriesInfo">RFC 8846</span>, <span class="seriesInfo">DOI 10.17487/RFC8846</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="http://www.rfc-editor.org/info/rfc8846">http://www.rfc-editor.org/info/rfc8846</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8847">[RFC8847]</dt>
        <dd>
<span class="refAuthor">Presta, R.</span><span class="refAuthor"> and S P. Romano</span>, <span class="refTitle">"Protocol for Controlling Multiple Streams for Telepresence (CLUE)"</span>, <span class="seriesInfo">RFC 8847</span>, <span class="seriesInfo">DOI 10.17487/RFC8847</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8847">https://www.rfc-editor.org/info/rfc8847</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8848">[RFC8848]</dt>
        <dd>
<span class="refAuthor">Hanton, R.</span><span class="refAuthor">, Kyzivat, P.</span><span class="refAuthor">, Xiao, L.</span><span class="refAuthor">, and C. Groves</span>, <span class="refTitle">"Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)"</span>, <span class="seriesInfo">RFC 8848</span>, <span class="seriesInfo">DOI 10.17487/RFC8848</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8848">https://www.rfc-editor.org/info/rfc8848</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8850">[RFC8850]</dt>
      <dd>
<span class="refAuthor">Holmberg, C.</span>, <span class="refTitle">"Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel"</span>, <span class="seriesInfo">RFC 8850</span>, <span class="seriesInfo">DOI 10.17487/RFC8850</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8850">https://www.rfc-editor.org/info/rfc8850</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-15.2">
        <h3 id="name-informative-references">
<a href="#section-15.2" class="section-number selfRef">15.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC4353">[RFC4353]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span>, <span class="refTitle">"A Framework for Conferencing with the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 4353</span>, <span class="seriesInfo">DOI 10.17487/RFC4353</span>, <time datetime="2006-02" class="refDate">February 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4353">https://www.rfc-editor.org/info/rfc4353</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7201">[RFC7201]</dt>
        <dd>
<span class="refAuthor">Westerlund, M.</span><span class="refAuthor"> and C. Perkins</span>, <span class="refTitle">"Options for Securing RTP Sessions"</span>, <span class="seriesInfo">RFC 7201</span>, <span class="seriesInfo">DOI 10.17487/RFC7201</span>, <time datetime="2014-04" class="refDate">April 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7201">https://www.rfc-editor.org/info/rfc7201</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7202">[RFC7202]</dt>
        <dd>
<span class="refAuthor">Perkins, C.</span><span class="refAuthor"> and M. Westerlund</span>, <span class="refTitle">"Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution"</span>, <span class="seriesInfo">RFC 7202</span>, <span class="seriesInfo">DOI 10.17487/RFC7202</span>, <time datetime="2014-04" class="refDate">April 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7202">https://www.rfc-editor.org/info/rfc7202</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7205">[RFC7205]</dt>
        <dd>
<span class="refAuthor">Romanow, A.</span><span class="refAuthor">, Botzko, S.</span><span class="refAuthor">, Duckworth, M.</span><span class="refAuthor">, and R. Even, Ed.</span>, <span class="refTitle">"Use Cases for Telepresence Multistreams"</span>, <span class="seriesInfo">RFC 7205</span>, <span class="seriesInfo">DOI 10.17487/RFC7205</span>, <time datetime="2014-04" class="refDate">April 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7205">https://www.rfc-editor.org/info/rfc7205</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7262">[RFC7262]</dt>
        <dd>
<span class="refAuthor">Romanow, A.</span><span class="refAuthor">, Botzko, S.</span><span class="refAuthor">, and M. Barnes</span>, <span class="refTitle">"Requirements for Telepresence Multistreams"</span>, <span class="seriesInfo">RFC 7262</span>, <span class="seriesInfo">DOI 10.17487/RFC7262</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7262">https://www.rfc-editor.org/info/rfc7262</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7667">[RFC7667]</dt>
        <dd>
<span class="refAuthor">Westerlund, M.</span><span class="refAuthor"> and S. Wenger</span>, <span class="refTitle">"RTP Topologies"</span>, <span class="seriesInfo">RFC 7667</span>, <span class="seriesInfo">DOI 10.17487/RFC7667</span>, <time datetime="2015-11" class="refDate">November 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7667">https://www.rfc-editor.org/info/rfc7667</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8849">[RFC8849]</dt>
      <dd>
<span class="refAuthor">Even, R.</span><span class="refAuthor"> and J. Lennox</span>, <span class="refTitle">"Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures"</span>, <span class="seriesInfo">RFC 8849</span>, <span class="seriesInfo">DOI 10.17487/RFC8849</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8849">https://www.rfc-editor.org/info/rfc8849</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="acks">
<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">
   <span class="contact-name">Allyn Romanow</span> and <span class="contact-name">Brian Baldino</span> were
     authors of early draft versions.
   <span class="contact-name">Mark Gorzynski</span> also contributed much to the initial approach.
   Many others also contributed, 
   including <span class="contact-name">Christian Groves</span>, 
   <span class="contact-name">Jonathan Lennox</span>, 
   <span class="contact-name">Paul Kyzivat</span>, 
   <span class="contact-name">Rob Hanton</span>, 
   <span class="contact-name">Roni Even</span>, 
   <span class="contact-name">Christer Holmberg</span>,
   <span class="contact-name">Stephen Botzko</span>, 
   <span class="contact-name">Mary Barnes</span>, 
   <span class="contact-name">John Leslie</span>, and 
   <span class="contact-name">Paul Coverdale</span>.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Mark Duckworth (<span class="role">editor</span>)</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mrducky73@outlook.com" class="email">mrducky73@outlook.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Andrew Pepperell</span></div>
<div dir="auto" class="left"><span class="org">Acano</span></div>
<div dir="auto" class="left"><span class="locality">Uxbridge</span></div>
<div dir="auto" class="left"><span class="country-name">United Kingdom</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:apeppere@gmail.com" class="email">apeppere@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Stephan Wenger</span></div>
<div dir="auto" class="left"><span class="org">Tencent</span></div>
<div dir="auto" class="left"><span class="street-address">2747 Park Blvd.</span></div>
<div dir="auto" class="left">
<span class="locality">Palo Alto</span>, <span class="region">CA</span> <span class="postal-code">94306</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:stewe@stewe.org" class="email">stewe@stewe.org</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>