Subject: [AVT] RTSP section for the Retransmission draft

From: Jose Rey <[email-masked]>
Date: Tue, 19 Nov 2002 15:50:19 -0600

Dear all,

enclosed the *NEW* RTSP section for the retransmission draft,
draft-ietf-avt-rtp-retransmission-03.txt. Sorry for being this late.

This should be the final version of the draft, so if you have any comments,
please speak up.

cheers,

José, for José and David.

------------------------

9. RTSP considerations

The Real-time Streaming Protocol (RTSP), RFC 2326 [7] is an
application-level protocol for control over the delivery of data with
real-time properties. This section looks at the issues involved in
controlling RTP sessions that use retransmissions.

9.1 RTSP control with SSRC-multiplexing

In the case of SSRC-multiplexing, the "m" line includes both original and
retransmission payload types and has a single RTSP "control" attribute. The
receiver uses the "m" line to request SETUP and TEARDOWN of the whole media
session. The RTP profile contained in the transport header MUST be the AVPF
profile or another suitable profile allowing extended feedback.

In order to control the sending of the session original media stream, the
receiver sends as usual PLAY and PAUSE requests to the sender for the
session. The RTP-info header that is used to set RTP-specific parameters in
the PLAY response MUST be set according to the RTP information of the
original stream.

As the receiver receives the original stream it can request retransmission
through RTCP requests without additional RTSP signalling.

9.2 RTSP control with session-multiplexing

In the case of Session-multiplexing, each SDP "m" line has an RTSP "control"
attribute. Hence, when retransmission is used, both the original session and
the retransmission have their own "control" attributes. The receiver can
associate the original session and the retransmission session through the
FID semantics as specified in Section 8.

The original and the retransmission streams are set up and torn down
separately through their respective media "control" attribute. The RTP
profile contained in the transport header MUST be the AVPF profile or other
another suitable profile allowing extended feedback for both the original
and the retransmission session.

The RTSP presentation SHOULD support aggregate control and SHOULD contain a
session level RTSP URL. The receiver SHOULD use aggregate control for an
original session an its associated retransmission session. Otherwise, there
would need to be two different 'session-id' values, i.e. for the original
and retransmission sessions, and the sender would not know how to associate
them.

The session-level "control" attribute is then used as usual to control the
playing of the original stream. As the receiver starts receiving the
original stream, it can request retransmissions through RTCP without
additional RTSP signalling.

9.3 Retransmission in pause state

Because of the nature of retransmissions, the sending of retransmission
packets should not be controlled through RTSP PLAY and PAUSE requests. The
PLAY and PAUSE requests SHOULD not affect the retransmission stream.
Retransmission packets are sent upon receiver requests in the original RTCP
stream, regardless of the state.

9.4 Cache control

Retransmission streams SHOULD NOT be cached.

In the case of session-multiplexing, the "Cache-Control" header SHOULD be
set to "no-cache" for the retransmission stream.

In the case of SSRC-multiplexing, RTSP cannot specify an independent caching
for the retransmission stream, because there is a single "m" line in SDP.
Therefore the implementer should take this fact into account when deciding
whether to cache an SSRC-multiplexed session or not.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt