10. Implementierungsbeispiele
Dieses Dokument verpflichtet nur Sender- und Empfängerverhalten, das für Interoperabilität nötig ist. Bestimmte Algorithmen, etwa Ratensteuerung oder Pufferverwaltung für spezifische Umgebungen, können die Retransmissionseffizienz erhöhen.
Dieser Abschnitt gibt einen Überblick über verschiedene innerhalb dieser Spezifikation zulässige Implementierungsoptionen.
Das erste Beispiel beschreibt eine minimale Empfängerimplementierung. Damit lassen sich verlorene RTP-Pakete retransmitieren, der Verlust von Retransmissionen effizient erkennen und bei Bedarf mehrfache Retransmissionen durchführen. Der Großteil der Verarbeitung liegt beim Server.
Das zweite Beispiel zeigt, wie Retransmissionen in (kleinen) Multicast-Gruppen zusammen mit geschichteter Kodierung genutzt werden können. Es verdeutlicht, dass Retransmissionen und geschichtete Kodierung ergänzende Techniken sein können.
10.1. Beispiel einer minimalen Empfängerimplementierung
Dieser Abschnitt gibt ein Beispiel einer Implementierung mit mehrfachen Retransmissionen. Der Sender überträgt Originaldaten in RTP-Paketen mit dem MPEG-4-Video-RTP-Nutzlastformat. Es wird angenommen, dass NACK-Feedback-Nachrichten gemäß [1] verwendet werden. Ein SDP-Beispiel mit SSRC-Multiplexing folgt:
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
Der formatspezifische Parameter „rtx-time“ bedeutet, dass der Server gesendete Pakete 3,0 Sekunden in einem Retransmission-Puffer hält; danach werden sie aus dem Puffer entfernt und nicht erneut gesendet.
In diesem Implementierungsbeispiel bleibt die erforderliche RTP-Empfängerverarbeitung für Retransmission minimal. Der Empfänger erkennt Paketverlust an Lücken in den empfangenen Sequenznummern. Er signalisiert verlorene Pakete per NACK gemäß AVPF [1]. Der Empfänger sollte die signalisierte Retransmission-Pufferlänge des Senders berücksichtigen, um den eigenen Empfangspuffer zu dimensionieren. Aus der Pufferlänge sollte er die maximale Anzahl von Retransmissionsanforderungen pro Paket ableiten.
Der Sender sollte Pakete selektiv retransmitieren; d. h. er sollte je nach Paketwichtigkeit, beobachteter Quality of Service (QoS) und Stauzustand der Verbindung zum Empfänger entscheiden, ob ein angefordertes Paket erneut gesendet wird. Offensichtlich steigt die Senderverarbeitung mit der Empfängeranzahl, da Zustandsinformation und Verarbeitungslast pro Empfänger anfallen.
10.2. Retransmission geschichtet kodierter Medien im Multicast
Dieser Abschnitt zeigt die Kombination von Retransmissionen mit geschichteter Kodierung in Multicast-Sessions. Das Retransmissionsframework ist nur für kleine Multicast-Anwendungen vorgesehen. Siehe RFC 2887 [10] zur Diskussion von NACK-Implosion, schwerer Überlastung durch Feedback in großen zuverlässigen Multicast-Anwendungen.
Pakete unterschiedlicher Wichtigkeit werden in verschiedenen RTP-Sessions gesendet. Die zugehörigen Retransmission-Ströme können selbst als verschiedene Retransmission-Schichten betrachtet werden. Die relative Wichtigkeit der Retransmission-Ströme sollte der relativen Wichtigkeit der Originalströme entsprechen.
Bei Multicast ist SSRC-Multiplexing von Original- und Retransmission-Strömen gemäß Abschnitt 5.3 dieses Dokuments nicht erlaubt. Daher MUST der (die) Retransmission-Strom(-Ströme) in anderen RTP-Sessions per Session-Multiplexing gesendet werden.
Ein SDP-Beispiel für Multicast-Retransmissionen bei geschichtet kodierten Medien:
m=video 8000 RTP/AVPF 98
c=IN IP4 224.2.1.0/127/3
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
m=video 8000 RTP/AVPF 99
c=IN IP4 224.2.1.3/127/3
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000
Server und Empfänger können die in den vorherigen Beispielen skizzierten Retransmissionsmethoden implementieren. Zusätzlich können sie Anforderung und Retransmission eines verlorenen Pakets von der zugehörigen Schicht abhängig machen.