\section{Interaction with RTP}
\label{sec:rtp}

RTSP allows to play selected, non-contiguous sections of a presentation.
The media client playing back the RTP stream should not be affected by
jumps in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be
continuous and monotonic across jumps of NPT.
 
As an example, assume a clock frequency of 8000 Hz, a packetization
interval of 100 ms and an initial sequence number and timestamp of zero.
First we play NPT 10 through 15, then skip ahead and play NPT 18 through
20.  The first segment is presented as RTP packets with sequence numbers
0 through 49 and timestamp 0 through 39,200.  The second segment
consists of RTP packets with sequence number 50 through 69, with
timestamps 40,000 through 55,200.
 
\motivation{We cannot assume that the RTSP client can communicate with 
the RTP media agent, as the two may be independent processes.  If the
RTP timestamp shows the same gap as the NPT, the media agent will assume
that there is a pause in the presentation.  If the jump in NPT is large
enough, the RTP timestamp may roll over and the media agent may believe
later packets to be duplicates of packets just played out.}
 
For scaling (see Section~\ref{sec:Scale}), RTP timestamps should
correspond to the playback timing.  For example, when playing video
recorded at 30 frames/second at a scale of two and speed (Section
\ref{sec:Speed}) of one, the server would drop every second frame to
maintain and deliver video packets with the normal timestamp spacing of
3,000 per frame, but NPT would increase by 1/15 second for each video
frame.

The client can maintain a correct display of NPT by noting the RTP
timestamp value of the first packet arriving after repositioning.  The
{\sf sequence} parameter of the {\sf Transport-Info}
(Section~\ref{sec:Transport-Info} header provides the last sequence
number of the previous segment.
