9. RTSP-Überlegungen
Das Real Time Streaming Protocol (RTSP), RFC 2326 [7], ist ein Anwendungsprotokoll zur Steuerung der Zustellung von Daten mit Echtzeiteigenschaften. Dieser Abschnitt behandelt Fragen bei der Steuerung von RTP-Sessions mit Retransmission.
9.1. RTSP-Steuerung bei SSRC-Multiplexing
Bei SSRC-Multiplexing umfasst die „m“-Zeile sowohl Original- als auch Retransmission-Payload-Typen und hat ein einziges RTSP-„control“-Attribut. Der Empfänger nutzt die „m“-Zeile, um SETUP und TEARDOWN der gesamten Mediensession anzufordern. Das im Transport-Header enthaltene RTP-Profil MUST das AVPF-Profil oder ein anderes geeignetes Profil mit erweitertem Feedback sein. Ist der SSRC-Wert im Transport-Header der SETUP-Antwort enthalten, MUST er der des Originalstroms sein.
Um das Senden des Original-Medienstroms der Session zu steuern, sendet der Empfänger wie üblich PLAY- und PAUSE-Anfragen an den Sender. Der RTP-info-Header zur Setzung RTP-spezifischer Parameter in der PLAY-Antwort MUST gemäß den RTP-Informationen des Originalstroms gesetzt werden.
Wenn der Empfänger den Originalstrom zu empfangen beginnt, kann er Retransmission über RTCP-NACKs ohne zusätzliche RTSP-Signalisierung anfordern.
9.2. RTSP-Steuerung bei Session-Multiplexing
Bei Session-Multiplexing hat jede SDP-„m“-Zeile ein RTSP-„control“-Attribut. Bei Retransmission haben daher sowohl die Original-Session als auch die Retransmission jeweils eigene „control“-Attribute. Der Empfänger kann Original- und Retransmission-Session über die FID-Semantik gemäß Abschnitt 8 zuordnen.
Original- und Retransmission-Ströme werden getrennt über das jeweilige Medien-„control“-Attribut eingerichtet und abgebaut. Das im Transport-Header enthaltene RTP-Profil MUST für Original- und Retransmission-Sessions das AVPF-Profil oder ein anderes geeignetes Profil mit erweitertem Feedback sein.
Die RTSP-Präsentation SHOULD aggregierte Steuerung unterstützen und SHOULD eine Session-Level-RTSP-URL enthalten. Der Empfänger SHOULD aggregierte Steuerung für eine Original-Session und die zugehörige Retransmission-Session verwenden. Andernfalls wären zwei verschiedene „session-id“-Werte nötig, d. h. unterschiedliche Werte für Original- und Retransmission-Sessions, und der Sender wüsste nicht, wie er sie zuordnen soll.
Das Session-Level-„control“-Attribut wird dann wie üblich genutzt, um die Wiedergabe des Originalstroms zu steuern. Wenn der Empfänger den Originalstrom zu empfangen beginnt, kann er Retransmissionen über RTCP ohne zusätzliche RTSP-Signalisierung anfordern.
9.3. RTSP-Steuerung des Retransmission-Stroms
Wegen der Natur von Retransmissionen SHOULD das Senden von Retransmission-Paketen nicht über RTSP PLAY- und PAUSE-Anfragen gesteuert werden. PLAY- und PAUSE-Anfragen SHOULD den Retransmission-Strom nicht beeinflussen. Retransmission-Pakete werden auf Empfängeranforderungen im Original-RTCP-Strom hin gesendet, unabhängig vom Zustand.
9.4. Cache-Control
Retransmission-Ströme SHOULD NOT gecacht werden.
Bei Session-Multiplexing SHOULD der Header „Cache-Control“ für den Retransmission-Strom auf „no-cache“ gesetzt werden.
Bei SSRC-Multiplexing kann RTSP kein unabhängiges Caching für den Retransmission-Strom angeben, da es nur eine „m“-Zeile in SDP gibt. Implementierer sollten dies bei der Entscheidung über Caching einer SSRC-multiplexten Session berücksichtigen.