1.1. Applicability (Anwendbarkeit)
1.1. Applicability (Anwendbarkeit)
XR-Pakete sind in mehreren Anwendungen nützlich und werden aus diesem Grund nicht als profilspezifische Erweiterungen zu RTCP-Sender- oder Empfängerberichten definiert [9, Abschnitt 6.4.3]. Dennoch sind sie nicht in allen Kontexten von Nutzen. Insbesondere ist der VoIP-Metriken-Berichtsblock (Abschnitt 4.7) spezifisch für Sprachanwendungen, obwohl er in einer Vielzahl solcher Anwendungen verwendet werden kann.
Der VoIP-Metriken-Berichtsblock kann auf jede Eins-zu-eins- oder Eins-zu-viele-Sprachanwendung angewendet werden, für die die Verwendung von RTP und RTCP spezifiziert ist. Die Verwendung von Gesprächsmetriken (Abschnitt 4.7.5), einschließlich des R-Faktors (wie durch das in [3] definierte E-Modell beschrieben) und des mittleren Meinungsscores für Gesprächsqualität (MOS-CQ), in anderen Anwendungen als einfachen Zwei-Parteien-Anrufen ist nicht definiert; daher sollten diese Metriken in Multicast-Konferenzanwendungen als nicht verfügbar identifiziert werden.
Die paketweisen Berichtsblocktypen, Verlust-RLE (Abschnitt 4.1), Duplikat-RLE (Abschnitt 4.2) und Paketempfangszeiten (Abschnitt 4.3), wurden mit Blick auf Netzwerk-Tomographie-Anwendungen wie die Multicast-Inferenz von Netzwerkmerkmalen (MINC) [11] definiert. MINC benötigt detaillierte Paketempfangsspuren von Multicast-Sitzungsempfängern, um die grobe Struktur des Multicast-Verteilungsbaums und die Parameter wie Verlustraten und Verzögerungen zu schließen, die für Pfade zwischen den Verzweigungspunkten dieses Baums gelten.
Jede Echtzeit-Multicast-Multimedia-Anwendung kann die paketweisen Berichtsblocktypen verwenden. Eine solche Anwendung könnte ein MINC-Inferenz-Subsystem verwenden, das ihr Multicast-Baum-Topologie-Informationen bereitstellen würde. Eine potenzielle Verwendung eines solchen Subsystems wäre die Identifizierung von Regionen mit hohem Verlust im Multicast-Baum und die Identifizierung von Multicast-Sitzungsteilnehmern, die gut positioniert sind, um Neuübertragungen verlorener Pakete bereitzustellen.
Detaillierte paketweise Berichte müssen nicht notwendigerweise unverhältnismäßig viel Bandbreite im Vergleich zu anderen RTCP-Paketen verbrauchen. Eine Anwendung kann die Größe dieser Blöcke begrenzen. Für diese Berichtsblöcke wird ein Mechanismus namens "Ausdünnung" bereitgestellt, der verwendet werden kann, um sicherzustellen, dass sie eine Größenbeschränkung einhalten, indem die Anzahl der gemeldeten Pakete innerhalb eines beliebigen Sequenznummernintervalls eingeschränkt wird. Die Begründung und Verwendung dieses Mechanismus wird in [13] beschrieben. Darüber hinaus benötigen Anwendungen möglicherweise keine Berichtsblöcke von allen Empfängern, um wichtige Fragen zu beantworten, wie z.B. wo im Multicast-Baum Pfade vorhanden sind, die einen definierten Verlustraten-Schwellenwert überschreiten. Intelligente Entscheidungen darüber, welche Empfänger diese Berichtsblöcke senden, können den Anteil der RTCP-Bandbreite, den sie verbrauchen, weiter einschränken.
Die paketweisen Berichtsblöcke können auch von dedizierten Netzwerküberwachungsanwendungen verwendet werden. Für eine solche Anwendung könnte es angemessen sein, mehr als 5% der RTP-Datenbandbreite für RTCP-Pakete zuzulassen, was proportional größere und detailliertere Berichtsblöcke ermöglicht.
Nichts in den paketweisen Blocktypen beschränkt ihre Verwendung auf Multicast-Anwendungen. Insbesondere könnten sie für Netzwerk-Tomographie ähnlich wie MINC verwendet werden, jedoch unter Verwendung gestreifter Unicast-Pakete. Darüber hinaus könnten sie, wenn es als nützlich befunden wird, für auf zwei Teilnehmer beschränkte Anwendungen verwendet werden.
Eine Verwendung, für die die paketweisen Berichte nicht unmittelbar geeignet sind, ist die Bestätigung von Datenpaketen als Teil eines Paket-Neuübertragungsmechanismus. Der Grund dafür ist, dass die für diese Blöcke vorgeschlagene Paketbuchhaltungstechnik von der normalerweise von RTP verwendeten Paketbuchhaltung abweicht. Um Messanwendungen zu bevorzugen, wird versucht, am Datenempfänger so wenig wie möglich zu interpretieren und die Interpretation so weit wie möglich den Teilnehmern zu überlassen, die die Berichtsblöcke empfangen. So könnte beispielsweise ein Paket mit einer anomalen SSRC-ID oder einer anomalen Sequenznummer durch normale RTP-Buchhaltung ausgeschlossen werden, würde aber für Netzwerküberwachungszwecke gemeldet.
Der Statistik-Zusammenfassungs-Berichtsblock (Abschnitt 4.6) wurde ebenfalls mit Blick auf Netzwerküberwachung definiert. Dieser Blocktyp kann gleichermaßen gut für Berichte über Unicast- und Multicast-Paketempfang verwendet werden.
Die referenzzeitbezogenen Blocktypen wurden für empfängerbasierte TCP-freundliche Multicast-Überlastkontrolle [18] konzipiert. Indem sie es Datenempfängern ermöglichen, ihre Rundlaufzeiten zu Sendern zu berechnen, helfen sie den Empfängern, die Downstream-Bandbreite abzuschätzen, die sie anfordern sollten. Beachten Sie, dass wenn jeder Empfänger Empfänger-Referenzzeit-Berichtsblöcke (Abschnitt 4.4) senden soll, ein Sender potenziell eine Anzahl von DLRR-Berichtsblöcken (Abschnitt 4.5) senden könnte, die der Anzahl der Empfänger entspricht, deren RTCP-Pakete innerhalb seines Berichtsintervalls beim Sender angekommen sind. Mit zunehmender Anzahl der Teilnehmer an einer Multicast-Sitzung sollte eine Anwendung Diskretion darüber walten lassen, welche Teilnehmer diese Blöcke senden und wie häufig.
XR-Pakete ergänzen die bestehenden RTCP-Pakete und können mit anderen RTCP-Paketen gestapelt werden, um zusammengesetzte RTCP-Pakete zu bilden [9, Abschnitt 6]. Die Einführung von XR-Paketen in eine Sitzung ändert in keiner Weise die Regeln, die die Berechnung des RTCP-Berichtsintervalls regeln [9, Abschnitt 6.2]. Da XR-Pakete RTCP-Pakete sind, werden sie als solche für Bandbreitenberechnungen gezählt. Infolgedessen kann das Hinzufügen erweiterter Berichtsinformationen dazu neigen, die durchschnittliche RTCP-Paketgröße und somit das durchschnittliche Berichtsintervall zu erhöhen. Diese Erhöhung kann durch Begrenzung der Größe von XR-Paketen begrenzt werden.
Die in diesem Dokument für XR-Pakete definierte SDP-Signalisierung (Abschnitt 5) wurde mit drei Verwendungsszenarien im Hinterkopf durchgeführt: eine Real Time Streaming Protocol (RTSP) kontrollierte Streaming-Anwendung, eine Eins-zu-viele Multicast-Multimedia-Anwendung wie eine Kursvorlesung mit erweitertem Feedback und eine Session Initiation Protocol (SIP) kontrollierte Gesprächssitzung mit zwei Parteien. Anwendungen, die SDP verwenden, können zusätzliche SDP-Signalisierung für hier nicht abgedeckte Fälle verwenden. Darüber hinaus steht es Anwendungen frei, andere Signalisierungsmechanismen als SDP zu verwenden.