Tutorial zur Quality of Service (QoS) von Videotechnologien

Einführung

Dieses Dokument befasst sich mit der Qualität von Videoanrufen und bietet ein Tutorial zu den Aspekten, die beachtet werden müssen, während Quality of Service (QoS) auf einem Cisco Unified Border Element (CUBE)- oder einem TDM-Gateway (Time Division Multiplexing) konfiguriert wird.

Unterstützt von Baktha Muralidharan, Cisco TAC Engineer, herausgegeben von Anoop Kumar.

Voraussetzungen

Anforderungen

Dieses Dokument ist für Techniker, die mit Voice-over-IP (VoIP) vertraut sind, von besonderem Nutzen, auch wenn andere es für nützlich halten.

Verwendete Komponenten

Es wird keine spezielle Hardware oder Software zum Schreiben dieses Dokuments verwendet.

Hintergrundinformationen

Digitalisierte Audio in der einfachsten Form ist eine Reihe von Audiobeispielen, die jeweils den Schalldruck in diesem Zeitraum beschreiben.  Konversationsaudio kann mit nur 8000 Samples pro Sekunde erfasst und mit hoher Genauigkeit reproduziert werden[1].  Das bedeutet, dass, solange das Netzwerk in der Lage ist, die Stichproben ohne übermäßige Verzögerung, Jitter und Paketverlust zu transportieren, Audio am anderen Ende getreu reproduziert werden kann.

Im Gegensatz dazu ist die Präsentation, Verarbeitung und Übertragung von Video viel komplexer. Helligkeit, Kontrast, Farbsättigung, Reaktionsgeschwindigkeit (in Bewegung) und Lippensynchronisierung sind nur einige der Attribute, die die Qualität des Videos bestimmen. Videobeispiele benötigen im Allgemeinen viel mehr Platz. Es überrascht nicht, dass die Nachfrage nach Netzwerkbandbreite im Transportnetzwerk durch Videoanwendungen deutlich steigt. Die Audioqualität wird durch den :Mikrofonlautsprecher im Headset-Codec bestimmt. Die Qualität der Videoanrufe im Komprimierungsnetzwerk wird durch folgende Faktoren beeinflusst: Kompatibilität/Interoperabilität des Videocodec-Transportnetzwerks mit dem Videoanzeigegerät der Kamera

Hinweis: Im Unterschied zu Audio ist es wichtig zu verstehen, dass an Videoendgeräten bei der Einstellung der Qualität einiges passiert.

Ziel

QoS ist im Allgemeinen ein riesiges und komplexes Thema, das die Berücksichtigung der allgemeinen Datenverkehrsanforderungen (statt nur des Datenverkehrs, der die Qualität verbessern soll) erfordert. Es muss für jede Netzwerkkomponente auf dem Pfad des Medienflusses überprüft werden. Die Bereitstellung von Videoqualität in einer Videokonferenz ist noch komplexer, da sie neben den Netzwerkkomponenten auch die Überprüfung und Prüfung der Konfiguration und Optimierung an den Endpunkten beinhaltet. Die Videoqualität hat im Großen und Ganzen folgende Auswirkungen:

• Endpunktoptimierung - Optimierung der Endpunktkonfiguration (z. B. Auflösung, Frame-pro-Sekunde)
• Transportoptimierung - Optimierung des Netzwerks zur Übertragung des Videodatenverkehrs pro Netzwerk-SLA.
• Überlegungen zur Interoperabilität - Videoanrufe führen häufig zu Endpunkten mit unterschiedlichen Funktionen. Das Design und die Konfiguration der Systeme zur Maximierung der Interoperabilität können die Videoqualität beeinträchtigen.

Der Schwerpunkt dieses Dokuments liegt auf den QoS-Überlegungen auf dem IOS-Gateway oder CUBE, wenn Videoanrufe verarbeitet werden.

Die Abstimmung an den Endpunkten würde eine Reihe von Parametern an den Video-Endpunkten beinhalten. Dies hängt natürlich vom Produkt ab, aber hier sind einige allgemeine "Knobs":

• Auflösung (d. h. Bildgröße)
• Bildrate (d. h. Empfindlichkeit/Realität von Bewegungen)
• Tagging (d. h. ToS-Kennzeichnung)

Die Anpassung des Netzwerks für Videoanwendungen umfasst in der Regel Folgendes:

• Verständnis der Zusammensetzung des Datenverkehrs, der durch das CUBE fließt, z. B. maximales [Anrufvolumen] usw.
• Überprüfung der Netzwerk-Link-/Pipe-Kapazität
• Entwerfen geeigneter QoS-Richtlinien, um sicherzustellen, dass das SLA für jede Datenverkehrsklasse eingehalten wird

Interoperabilität spielt eine Rolle, wenn heterogene (Video- und Telepresence-) Systeme an einem Konferenzgespräch teilnehmen. Die Erfahrung, die ein TP- und Videotelefonsystem bietet, ist grundlegend anders. Die Interoperabilität zwischen ihnen wird im Allgemeinen durch Überbrückung mithilfe eines Verfahrens erreicht, das als Kaskadierung bezeichnet wird.

Was nicht abgedeckt wird

Dies ist kein Designdokument und auch kein umfassendes Video-QoS-Dokument. Insbesondere werden in diesem Dokument folgende Themen nicht behandelt:

• Signalisierung [Protokolle] von Videoanrufen, die über das hinausgehen, was erforderlich ist, um QoS-bezogene Aspekte zu veranschaulichen.
• Einrichtung/Konfiguration von Videoendgeräten
• Umfassende Überprüfung der QoS-Mechanismen, einschließlich Policing, Queuing, Shaping und Burst
• Überprüfung der QoS-Konfiguration auf Layer-2-Switches oder Überlegungen zur Vertrauensgrenze.

Merkmale des Netzwerkverkehrs für Video

Video, wie Audio, ist in Echtzeit.  Audio-Übertragungen sind konstante Bit-Rate (CBR). Im Gegensatz dazu ist der Videodatenverkehr tendenziell sprunghaft und wird als variable Bit-Rate (VBR) bezeichnet. Folglich ist die Bitrate für Videoübertragungen nicht unbedingt konstant, wenn wir eine bestimmte Qualität aufrechterhalten müssen[2].

Bild 1

Auch die Bestimmung der für Videoanwendungen erforderlichen Bandbreite und das Bursting ist stärker involviert. Dies wird später in diesem Dokument erläutert.

• Videodatenverkehr ist sprunghaft.
• Videopakete können sehr groß sein.
• Audio ist immer CBR. Video ist in der Regel VBR. 

Warum ist Video-Burst?

Die Antwort liegt darin, wie Video komprimiert wird. Denken Sie daran, dass Video eine Abfolge von Bildern (Bildern) ist, die abgespielt werden, um einen visuellen Bewegungseffekt zu erzielen. Komprimierungstechniken, die von Videocodecs verwendet werden, verwenden den Delta-Codierung[3], der durch das Speichern von Bytewerten als Unterschiede (Deltas) zwischen sequenziellen (Samples) Werten anstelle der Werte selbst funktioniert. Dementsprechend werden Videos als aufeinander folgende Frames kodiert (und übertragen), die nur die "beweglichen Teile" und nicht ganze Frames übertragen.

Sie fragen sich wahrscheinlich, warum sich der Ton auch schrittweise ändert? Gut, wahr genug, aber "Motion" (oder Dynamik) beeinflusst nicht annähernd so viel Audio wie Video. Die 8-Bit-Audio-Samples komprimieren nicht besser, wenn Delta-codiert, Video-Samples (Frames) tun. Die relative Änderung von Stichprobe (Frame zu Frame) zu Stichprobe ist Video viel kleiner als die in Audio. Je nach Art und Grad der Bewegung können Videoproben sehr unterschiedlich groß sein. Bild 2 zeigt Videokomprimierung -

Bild 2

Ein I-Frame ist ein Intra-kodiertes Bild, im Prinzip ein vollständig angegebenes Bild, wie eine herkömmliche statische Bilddatei.

Ein P-Frame (Predicted Picture) enthält nur die Änderungen im Bild vom vorherigen Frame. Der Encoder muss die unveränderlichen Hintergrundpixel nicht im P-Frame speichern, wodurch Platz eingespart wird. P-Frames werden auch als Delta-Frames bezeichnet.

Ein B-Frame (bidirektionales Bild) spart noch mehr Platz, indem er Unterschiede zwischen dem aktuellen Frame und den beiden vorherigen und folgenden Frames verwendet, um dessen Inhalt anzugeben.

Messung der Videoqualität

Videogeräte von Cisco messen oder melden die Videoqualität als solche nicht, sodass die Videoqualität eher wahrgenommen als gemessen wird. Es gibt standardisierte Algorithmen, die die Qualität mittels eines MOS (Mean Opinion Score) messen. Wenn jedoch Probleme mit der Audioqualität gemeldet werden, ist die Wahrscheinlichkeit höher, dass Fälle von Videoqualität (TAC) geöffnet werden, da die Qualität von Benutzern eher als Fehler empfunden wird als durch ein Tool gemeldet.

Kontrollen an Endpunkten

Faktoren, die die Videoqualität beeinflussen, sind:

• Videocodec (MPEG4, H261, H263, H264 und H265)
• Größe (1/8. Bildschirm, 1/4 Bildschirm, Vollbildschirm)
• Bildrate (1 bis 30 Bilder pro Sekunde, 6 Standard)
• die Einstellung für die Komprimierungsqualität (niedrig, mittel, hoch)

Im Allgemeinen ist jede der oben genannten Optionen an den Endpunkten wählbar/kontrollierbar.

Sichtbare Artefakte

Quilting, Combing und Banding werden an diese Begriffe gewöhnt, Teil der Video-Beeinträchtigung Taxonomie.

Netzwerk-SLAs für Videoqualität

Empfohlen wird ein Netzwerk-SLA für Video[4]:

• Latenz ≤ 150-300 ms
• Jitter ≤ 10 ms-50 ms
• Verlust ≤ 0,5 %

Im Übrigen gelten für die Übertragung von Audio folgende Netzwerk-SLA:

• Latenz ≤ 150-300 ms
• Jitter ≤ 20 ms-50 ms
• Verlust ≤ 1 %

Hinweis: Bei Videoübertragungen ist die Wahrscheinlichkeit von Paketverlusten höher als bei Sprachübertragungen.  Dies ist zu erwarten, sobald Sie wissen, dass Interframes Informationen aus vorherigen Frames erfordern, was bedeutet, dass der Verlust von Interframes den Prozess der Rekonstruktion des Videobilds verheerend sein kann.

Kontrollen im Transportnetzwerk

Im Allgemeinen kann das SLA für die Videoübertragung mithilfe von QoS-Richtlinien bereitgestellt werden, die denen für die Audioübertragung sehr ähnlich sind. Aufgrund der Art des Videodatenverkehrs gibt es jedoch einige Unterschiede.

  

Hinweis: Obwohl der Umfang dieses Dokuments auf die CUBE-Komponente beschränkt ist, denken Sie daran, dass QoS eine End-to-End-Lösung ist.

Videovarianten

Sind alle Videos gleich? Nun, nicht ganz. Die Varianten von Video als Medium umfassen:

• Videotelefonie/Videokonferenzen
• Interaktive Echtzeit-Kommunikation
• Relativ geringere Bandbreite. Bis zu ca. 1 Mbit/s
• TelePresence
• Interaktive Echtzeit-Kommunikation
• Realitätsnahe Umgebung
• Erfordert sehr hohe Bandbreite
• Streaming
• Unidirektionale Echtzeit-Kommunikation
• Unicast oder Multicast möglich
• Hohe Bandbreite
• Verzögert empfindlich (die Warteschlange für das Video kann mehrere Sekunden dauern)
• Größtenteils unempfindlich gegenüber Jitter (aufgrund von Anwendungspufferung)
• Der Verlust darf nicht mehr als 5 Prozent betragen.
• Die Latenz darf maximal 4 bis 5 Sekunden betragen (abhängig von den Pufferfunktionen der Videoanwendung).
• Einige Videos (z. B. Unterhaltung) können für den Scavenger-Service in Betracht gezogen werden.

Hinweis: Im Interesse der Kürze werden für die oben aufgeführten Videodaten keine umfassenden Darstellungen bereitgestellt.

Codecs für Videodatenverkehr

• • Der H.261-Codec wurde ursprünglich für die Übertragung über ISDN-Leitungen entwickelt. Bei der Verwendung von Video-Bonding beträgt die Video-Bitrate das Vielfache von 64 Kbit/s.
  • H.263 - Codec wird sowohl in IP-basierten Videokonferenzen als auch in ISDN-Netzwerken eingesetzt. H.263 benötigt die Hälfte der Bandbreite, um dieselbe Videoqualität wie bei H.261 zu erreichen. Infolgedessen wurde H.263 weitgehend durch H.261 ersetzt. H.263 wurde für eine große Bandbreite von Bitraten optimiert und nicht nur für 64 K Bits/s wie bei H.261.
  • H.264/MPEG-4 - Cs ist derzeit eines der am häufigsten verwendeten Formate und verwendet die halbe oder weniger Bitrate von MPEG-2, H.263 oder MPEG-4 Teil 2.
  • H265 - Eine von mehreren potenziellen Nachfolgern des weit verbreiteten H.264 und basiert auf der Erweiterung der gleichen Konzepte. Er unterstützt Auflösungen bis 8192 x 4320, einschließlich 8 K UHD.

Hinweis: Video wird wie Audio im Realtime Protocol (RTP) übertragen.

QoS-Mechanismen für Video

Im Prinzip sind die QoS-Mechanismen zur Bereitstellung der SLAs für ein Videotransportnetzwerk größtenteils dieselben wie für Audio. Es gibt jedoch einige Unterschiede, vor allem aufgrund der sprunghaften Übertragung von Video und VBR.

Für QoS gibt es zwei Ansätze, nämlich Interated Services(intserv) und Differentiated Services(diffserv).

Betrachten Sie Intserv als auf Signalisierungsebene und diffserv auf Medienebene einsetzbar. Das inserv-Modell gewährleistet die Qualität durch den Betrieb auf Kontrollebene. diffserv hat sich zum Ziel gesetzt, die Qualität durch den Betrieb auf Datenebene sicherzustellen.

Netzwerkgeräte in der IntServ-Architektur fordern statische Bandbreitenreservierungen an und halten den Status aller reservierten Datenflüsse aufrecht, während sie Klassifizierungs-, Marking- und Warteschlangendienste für diese Datenflüsse ausführen. Die IntServ-Architektur arbeitet und integriert sowohl die Kontrollebene als auch die Datenebene und wurde als solche aufgrund von Einschränkungen bei der Skalierung weitgehend aufgegeben. Das Protokoll für die Bandbreitenreservierung ist RSVP (Resource ReaderVation Protocol).

Es gibt auch IntServ/DiffServ-Modell, das eine Art Mix ist. Dieses Modell trennt Vorgänge auf der Kontrollebene von Vorgängen auf der Datenebene. Der RSVP-Betrieb ist auf die Zugangskontrolle beschränkt. mit DiffServ-Mechanismen zur Bearbeitung von Klassifizierungs-, Marking-, Richtlinien- und Planungsvorgängen. Daher ist das IntServ/DiffServ-Modell hochgradig skalierbar und flexibel.

Hinweis: Dieses Dokument konzentriert sich nur auf diffserv (viz-a-viz-Priorisierungsschema, LLQ-Ansatz).

Bandbreitengarantie

Bandbreite ist offensichtlich der grundlegendste QoS-Parameter.  Dies hängt von mehreren Parametern ab, insbesondere von:

• Verwendeter Codec
• Bildrate
• Bildgröße
• Anrufvolumen (Spitze und Durchschnitt)

Der alte Trick, Bandbreite auf das Problem zu werfen, ist nicht immer die Lösung. Dies gilt insbesondere für die Videoqualität. Beispielsweise gibt es bei CUVA (Cisco Unified Video Advantage) keinen Synchronisierungsmechanismus zwischen den beiden beteiligten Geräten (Telefon und PC). Daher sollte QoS so konfiguriert werden, dass Jitter, Latenz, fragmentierte Pakete und Pakete, die nicht in der richtigen Reihenfolge sind, minimiert werden.

Hinweis: Interaktives Video hat die gleichen Service-Level-Anforderungen wie VoIP, da ein Sprachanruf in den Video-Stream integriert ist.Streaming Video hat aufgrund der hohen Anzahl an Pufferung, die in die Anwendungen integriert wurde, sehr viel höhere Anforderungen.

Schließlich ist es wichtig zu verstehen, dass es im Gegensatz zu VoIP keine klaren Formeln zur Berechnung der erforderlichen inkrementellen Bandbreite gibt. Dies liegt daran, dass die Größe und die Paketraten von Videopaketen erheblich variieren und größtenteils auf den Bewegungsgrad der übertragenen Videobilder zurückzuführen sind. Mehr dazu später.

Warteschlangenverwaltung

Low Latency Queuing (LLQ) ist die bevorzugte Warteschlangenrichtlinie für VoIP-Audio. Angesichts der strengen Verzögerungs-/Jitter-empfindlichen Anforderungen von TP und der Notwendigkeit, Audio und Video für CUVA zu synchronisieren, wird auch für den gesamten Videodatenverkehr das Priority Queuing (LLQ) empfohlen. Beachten Sie, dass für Video die Prioritätsbandbreite im Allgemeinen um 20 % erhöht wird, um den Overhead zu berücksichtigen.

Header-Komprimierung

Nicht für Video empfohlen.

Link-Fragmentierung und -Verschachtelung

LFI ist ein beliebter Mechanismus, um sicherzustellen, dass Jitter bei langsamen Verbindungen, bei denen Serialisierungsverzögerungen hoch sein können, nicht außer Kontrolle gerät.

Auch bei langsamen Verbindungen wird Interactive-Video nicht empfohlen. Der Grund hierfür ist, dass LLQ, dem der Videodatenverkehr zugewiesen ist, nicht fragmentiert ist. Das bedeutet, dass große interaktive Videopakete (z. B. Full-Motion-I-Frames mit 1500 Byte) bei kleineren Interactive-Video-Paketen zu Serialisierungsverzögerungen führen können.

Überlastungsvermeidung

Selektive Verwerfen basierend auf RTCP

Burst

Dieser QoS-Mechanismus ist wichtig für den Videodatenverkehr, der, wie bereits erwähnt, sprunghaft anhält.

Der optionale Burst-Parameter kann als Teil des Priority-Befehls konfiguriert werden[6].

Bei H.264 wäre der "Worst-Case-Burst" der Vollbildschirm von (räumlich komprimierten) Video. Basierend auf umfangreichen Tests auf TP-Systemen liegt dieser Wert bei 64 KB. Daher sollte der LLQ Burst-Parameter so konfiguriert werden, dass pro Frame und Bildschirm bis zu 64 KB Burst möglich sind. Das CTS-1000-System mit 1080p-Best (mit optionaler Unterstützung eines Hilfsvideostreams[7]) wird mit einem LLQ konfiguriert, der einen optimalen Burst-Parameter von 128 (2x64) KB aufweist.

Wie viel Bandbreite?

Wie viel Bandbreite wird also benötigt, um einen Videoanruf zuverlässig zu übertragen? Bevor wir uns den Berechnungen zuwenden, müssen wir die folgenden Konzepte verstehen, die sich nur auf die Videokommunikation beziehen.

Auflösung

Dies bezieht sich im Wesentlichen auf die Größe des Bildes.  Weitere häufig verwendete Begriffe hierfür sind Videoformat und Bildschirmgröße.  Im Folgenden werden häufig verwendete Videoformate dargestellt.

Format	Videoauflösung (Pixel)
QUCIF	128 x 96
QCIF	176 x 144
SCIF	256 x 192
SIF	352 x 240
CIF	352 x 288
DCIF	528 x 384
4 CIF	704 x 576
16 CIF	1408 x 1152

Die meisten Videokonferenzgeräte werden im CIF- oder 4CIF-Format ausgeführt.

Ref.: http://en.wikipedia.org/wiki/Common_Intermediate_Format

Hinweis: In der Audio-Welt gibt es keine Entsprechung für (Video-) Auflösung.

Bildrate

Dies bezieht sich auf die Geschwindigkeit, mit der ein Bildverarbeitungsgerät eindeutige aufeinander folgende Bilder erzeugt, die als Frames bezeichnet werden. Die Bildrate wird als Frames pro Sekunde (fps) ausgedrückt.

Hinweis: Die entsprechende Kennzahl in der Audio-Welt ist die Abtastzeit. z. B. 8000 für g.711ulaw.

Bandbreitenberechnung

Bandbreitenberechnungen für Videotelefoniesysteme und andere herkömmliche Videokonferenzsysteme sind in der Regel einfacher.

Betrachten Sie beispielsweise einen TP-Anruf mit einer Auflösung von 1080 x 1920.  Die erforderliche Bandbreite wird wie folgt berechnet:

     2.073.600 Pixel pro Frame

        x3 Farben pro Pixel

        x1 Byte (8 Bit) pro Farbe

        x 30 Bilder pro Sekunde

        = 1,5 Gbit/s pro Bildschirm. Nicht komprimiert!

Bei Komprimierung reicht eine Bandbreite von 4 Mbit/s pro Bildschirm (> 99% komprimiert) aus, um den obigen Frame zu übertragen!

In der folgenden Tabelle sind einige der Kombinationen aufgelistet:

Bild Format	Leuchtkraft Pixel	Leuchtkraft Linien	Nicht komprimiert Bitrate (Mbit/s)
			10 Frames/s		30 Bilder/s
			Grau	Farbe	Grau	Farbe
QUCIF	128	96	1,0	1,5	3,0	4,4
QCIF	176	144	2,0	3,0	6,1	9,1
CIF	352	288	8,1	12,2	24,3	36,5
4 CIF	704	576	32,4	48,7	97,3	146,0
16 CIF	1408	1152	129,8	194,6	389,3	583,9

Beachten Sie, dass die obigen Berechnungen nur für einen Bildschirm gelten. Ein TP-Anruf kann mehrere Bildschirme umfassen, sodass die Gesamtbandbreite für den Anruf ein Vielfaches der Bandbreite pro Bildschirm darstellt.

Unter https://supportforums.cisco.com/thread/311604 finden Sie einen guten Bandbreitenrechner für Cisco TP-Systeme.

Klassifizierung/Marking von Videodatenverkehr

Wie wird Videodatenverkehr identifiziert/ausgezeichnet? Eine Möglichkeit zur Klassifizierung von Paketen auf CUBE ist die Verwendung von DSCP-Markierungen.

In der folgenden Tabelle werden die DSCP-Markierungen pro Cisco QoS-Baseline sowie RFC 4594 veranschaulicht.

Datenverkehr	Layer-3-PHB	Layer-3-DSCP
Anrufsignalisierung	CS3	24
Sprache	EF	46
Videokonferenz	AF41	34
TelePresence	CS4	32
Multimedia-Streaming	AF31	26
Broadcast-Video	CS5	40

PHB - Per-Hop Behavior Bezeichnet die Aktivitäten des Routers im Hinblick auf die Paketklassifizierung und die Konditionierung des Datenverkehrs, z. B. Messung, Markierung, Shaping und Richtlinienvergabe.

Standardmäßig markiert CUCM (Cisco Unified Call Manager) vor Version 9.0 den gesamten Videodatenverkehr (einschließlich TelePresence) auf AF41. Ab Version 9.0 konfiguriert CUCM die folgenden DSCP-Werte vorab:

• TelePresence-Anrufe (Immersive Video) bei CS4 und
• Videoanrufe (IP-Videotelefonie) bei AF41

Konfiguration

Die Konfiguration zur Optimierung der Audioqualität erfordert die Berechnung der Prioritätsbandbreite und die Implementierung der LLQ-Richtlinie auf einem WAN-Link. Dies basiert in der Regel auf dem erwarteten Anrufvolumen und dem verwendeten Audio-Codec.

Die Prinzipien sind identisch, aber die Videobandbreite über ein CUBE lässt sich nicht so einfach berechnen. Dies ist auf eine Reihe von Faktoren zurückzuführen, darunter:

• Wie berechnet man die gesamte Bandbreite, die für verschiedene TP-Anrufe (die durch das CUBE fließen) erforderlich ist, möglicherweise mit einer unterschiedlichen Anzahl von Bildschirmen und Auflösungen?
• Bursts und VBR
• Eine weitere Dimension der Komplexität [in der Bandbreitenberechnung] hat mit "Interoperabilitätsanrufen" zu tun? Interoperabilitätsanrufe verwenden TIPP. TIPP steht für Telepresence Interoperability Protocol. TIPP wird verwendet, um mehrere Bildschirme, mehrere Audio-Streams sowie einen Hilfsdaten-Bildschirm in zwei RTP-Datenflüsse zu vervielfachen, jeweils einen für Video und Audio. Er ermöglicht Point-to-Point- und Multipoint-Sitzungen sowie eine Kombination aus Mehrbildschirm- und Einzelbildschirm-Endgeräten. TIPP ist ein proprietäres Protokoll von Cisco. TIPP basiert auf RTCP.

Aus diesem Grund erfolgt die Bandbreitenbereitstellung für Videosysteme manchmal in umgekehrter Reihenfolge, d. h. die Bandbreite, die ein Transportnetzwerk bereitstellen kann, wird mit der LLQ-Richtlinie zuerst bestimmt, und der Endpunkt wird entsprechend konfiguriert. Endgeräte-Videosysteme sind intelligent genug, um die verschiedenen Videoparameter an die Pipe-Größe anzupassen! Dementsprechend signalisieren die Endpunkte den Anruf.

CUBE-Bandbreitenverwaltung

Wie bewältigt CUBE also die Bandbreite in seinen (SIP) Angeboten/Antworten bei der Signalisierung von Videoanrufen? CUBE füllt die Videobandbreitenfelder in SDP wie folgt aus:

  1. Von Bandbreitenattribut im eingehenden SDP. In SDP gibt es ein Bandbreitenattribut, dessen Modifizierer verwendet wird, um festzulegen, auf welche Bitrate der Wert sich bezieht.  Das Attribut hat folgende Form: b=<modifier>:<Wert>

  2. Aus der auf dem CUBE konfigurierten Videobandbreite. Die geschätzte maximale Bandbreite wird beispielsweise anhand der vom CTS-Benutzer verwendeten Funktionen berechnet, und die geschätzte Bandbreite wird auf CUBE mithilfe der CLI vorkonfiguriert.

• <Bandbreiten Video tias modifier> oder
• <Bandbreitenvideo als Modifier>

  3. Standard-Videobandbreite (384 Kbit/s)

Der unten dargestellte Anrufablauf veranschaulicht, wie CUBE Bandbreite in Anrufsignalisierungsnachrichten einsetzt.

Insbesondere verwendet das CUBE folgende Logik:

• Bei Angeboten (für Anrufe) nutzt CUBE die konfigurierte Bandbreite.
• On (Antworten auf EOs) sendet CUBE Bandbreite, deren Wert das Minimum des Angebots und der lokalen Konfiguration ist.

Auf der SDP-Sitzungsebene ist der TIAS-Wert die maximale erforderliche Bandbreite, wenn alle deklarierten Medien-Streams verwendet werden[8].

Payload-Typen für Videocodecs

In diesem Bereich unterscheidet sich Video von Audio ebenfalls.  Audio-Codecs verwenden statische Payload-Typen. Video-Codecs hingegen verwenden dynamische RTP-Payload-Typen, die den Bereich von 96 bis 127 verwenden.

Der Grund für die Verwendung dynamischer Payload-Typen hat mit der weiten Anwendbarkeit von Video-Codecs zu tun. Videocodecs verfügen über Parameter, die einem Empfänger die Eigenschaften des gesendeten Streams bereitstellen. Video-Payload-Typen werden in SDP mithilfe des Parameters a=rtpmap definiert. Zusätzlich kann das Attribut "a=fmtp:" verwendet werden, um Formatparameter anzugeben. Die fmtp-Zeichenfolge ist undurchsichtig und wird nur an die andere Seite übergeben.

Hier ein Beispiel:

m=video 2338 RTP/AVP 97 98 99 100
c=IN IP4 192.168.90.237
b=TIAS:768000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500;packetiza tion-mode=1
a=rtpmap:99 H263-1998/90000
a=fmtp:99 custom=1024,768,4;custom=1024,576,4;custom=800,600,4;cif4=2;custom=720,480,2 ;custom=640,480,2;custom=512,288,1;cif=1;custom=352,240,1;qcif=1;maxbr=7680
a=rtpmap:100 H263/90000
a=fmtp:100 cif=1;qcif=1;maxbr=7680

Beachten Sie, dass die beiden Endpunkte, die an einem Anruf beteiligt sind, für denselben Codec möglicherweise einen anderen Payload-Typ verwenden können. CUBE reagiert auf jede Seite mit einer=rtpmap-Leitung, die auf der anderen Seite eingeht. Dies bedeutet, dass die Konfiguration "asymmetrische Payload full" für Videoanrufe benötigt wird, um zu funktionieren.

L2-Bandbreite

Im Gegensatz zu Sprachservices ist der IP-Videodatenverkehr in Echtzeit im Allgemeinen ein etwas sprunghafter Stream mit variabler Bitrate. Im Gegensatz zu Sprachservices bietet Video daher keine klaren Formeln für die Berechnung des Netzwerk-Overhead, da die Größe und die Übertragungsraten von Videopaketen proportional zum Bewegungsgrad innerhalb des Videobilds selbst variieren. Aus Sicht eines Netzwerkadministrators wird die Bandbreite immer auf Layer 2 bereitgestellt, aber die Variabilität der Paketgrößen und die Vielfalt der Layer-2-Medien, die die Pakete durchlaufen können, erschwert die Berechnung der tatsächlichen Bandbreite, die auf Layer 2 bereitgestellt werden sollte. Die konservative Regel, die gründlich getestet und weithin verwendet wurde, besteht jedoch darin, die Videobandbreite um 20 % zu hoch bereitzustellen. Dadurch werden der Burst von 10 % und der Netzwerk-Overhead von Layer 2 bis Layer 4 abgedeckt.

Überwachung/Messung

Wie bereits erwähnt, melden Videoendpunkte kein MOS als solches. Die folgenden Tools können jedoch zum Messen/Überwachen der Übertragungsnetzwerkleistung und zum Überwachen der Videoqualität verwendet werden.

IP SLAs-Video

Eine in IOS integrierte Funktion, IP SLAs (Service Level Agreements), führt die aktive Überwachung der Netzwerkleistung durch. Der IP SLAs-Videovorgang unterscheidet sich von anderen IP SLA-Operationen dadurch, dass der gesamte Datenverkehr nur eine Möglichkeit ist. Ein Responder muss die Sequenznummern und Zeitstempel lokal verarbeiten und auf eine Anfrage von der Quelle warten, bevor die berechneten Daten zurückgesendet werden.

Die Quelle sendet eine Anfrage an den Responder, wenn der aktuelle Videovorgang abgeschlossen ist. Diese Anforderung signalisiert dem Responder, dass keine Pakete mehr eingehen und dass die Videosenk-Funktion im Videobetrieb deaktiviert werden kann. Wenn die Antwort des Befragten an der Quelle eingeht, werden die Statistiken aus der Nachricht gelesen und die relevanten Felder im Vorgang aktualisiert.

CiscoWorks IPM (IOS Performance Monitor) misst mithilfe von IP SLA-Tests und MediaTrace[9] die Leistung und Berichte des Benutzerdatenverkehrs.

CUBE VQM

Die auf dem CUBE verfügbare VQM-Funktion (Video Quality Monitor) ist ein hervorragendes Tool zur Überwachung der Videoqualität zwischen zwei wichtigen Punkten. Die Ergebnisse werden als MOS angezeigt.

Diese Funktion steht ab IOS 15.2(1)T zur Verfügung. Beachten Sie, dass VQM DSP-Ressourcen verwendet.

Referenz

• http://www.cisco.com/en/US/partner/tech/tk1077/technologies_configuration_example09186a00807ca099.shtml
• http://www.cisco.com/en/US/partner/docs/video/milticomm/h320Bonding.html
• http://www.cisco.com/en/US/docs/solutions/TelePresence_Network_Systems_1.1_DG.pdf
• http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/videodg/qos.html
• http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/videodg/basics.html
• IP-Videotelefonie SRND -
• http://www.cisco.com/en/US/tech/tk1077/technologies_configuration_example09186a0080111c1b.shtml
• http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/TP_InterOp_v2.html
• http://www.encoding.com/do_you_have_any_information_on_h.264_levels
• http://www.cisco.com/en/US/partner/tech/tk1077/technologies_configuration_example09186a0080111c1b.shtml
• http://www.watchpointvideo.com/pdf/Measuring%20Video%20Quality%20in%20Videoconferencing%20Systems.pdf
• http://www.broadcastpapers.com/whitepapers/Why_IPTV_is_different_from_IP_data_and_VoIP.pdf?CFID=25762102&CFTOKEN=60dc627518f1a19b-3F4F563D-FC97-8A61-6169D8F641750255
• http://en.wikipedia.org/wiki/Video_compression_picture_types
• http://inst.eecs.berkeley.edu/~ee290t/sp04/lectures/coding_standards.pdf
• http://www.cs.jhu.edu/~yairamir/cs667/Multimedia/compress.gif
• http://www.wireshark.org/lists/wireshark-users/201003/msg00125.html
• http://www.networkworld.com/news/tech/2002/0923tech.html
• http://www.javvin.com/protocolH263.html
• http://www.cisco.com/en/US/docs/ios-xml/ios/ipsla/configuration/12-2se/sla_video.html#GUID-29B155B6-AFC3-4F8B-AC1D-C127C9D797F0

 StartSelection:0000000199 EndSelection:000000538