Issuing multiple RTSP PLAY requests in a sequence within the same RTSP session will result in strange, and possibly wrong or unwanted, behavior for gst-rtsp-server. I've run three scenearios and included a sort of
pseudo network trace for the RTSP mechanisms I want to highlight, that expose things not handled properly by the server.
There is a follow up of the use cases with, first a section with a summrized list of issues found while issuing multiple PLAY requests, and second a section with an interpretation of, what I believe, is the relevant part of the RTSP 1.0, RTP and RTSP 2.0 Draft specifications.


== Mutiple RTSP PLAY request Use cases ==

Here follows three scenearios and some observations of the results. This example was performed with a ~17.5 seconds long media file containing only video with 12 fps.

Case 1) PLAY with Range -> PLAY with Range

C->S DESCRIBE
S->C Reply OK/SDP
C->S SETUP
S->C Reply OK
C->S PLAY Range: 0-5
S->C Reply OK Range: 0-5
S->C RTP/RTCP Stream (4.998+0.083 seconds of media)
S->C RTCP Bye
C->S PLAY Range: 0-5
S->C Reply OK Range: 0-17.495
S->C RTP Stream (17.411+0.083 seconds of media, No RTCP data)

It's obvious that the response from the server to the second PLAY request is wrong, it replies with the complete Range of the media, and the RTP data that follows contain all frames.

Case 2) PLAY no Range -> PLAY no Range

C->S DESCRIBE
S->C Reply OK/SDP
C->S SETUP
S->C Reply OK
C->S PLAY
S->C Reply OK Range: 0-17.495
S->C RTP/RTCP Stream (17.411+0.083 seconds of media)
S->C RTCP Bye
C->S PLAY
S->C Reply OK Range: 17.411-17.495
Note that neither RTP, nor RTCP, data is sent

NOTE: 17.411 is the PTS of the last frame
This is obviously wrong in some way. The server replies ok to the second PLAY request, but a PLAY without a range means that playback should continue from the pause point, and when the end of the media is reached the pause point is at the end. It doesn't feel natural that a client should expect data from this second PLAY request, but maybe some other response than OK is appropriate when a PLAY request is received when the pipeline's position is at the end.

Case 3) PLAY with Range -> PLAY no Range

C->S DESCRIBE
S->C Reply OK/SDP
C->S SETUP
S->C Reply OK
C->S PLAY Range: 0-5
S->C Reply OK Range: 0-5
S->C RTP/RTCP Stream (4.998+0.083 seconds of media)
S->C RTCP Bye
C->S PLAY
S->C Reply OK Range: 5-5
Note that neither RTP, nor RTCP, data is sent

The second PLAY response has the expected start position, but it looks strange replying OK with a Range that will not allow data to be sent.

== Observations of the scenarios above ==

From the use cases above and other not highlighted observations, it can be concluded that strange (not necessarily wrong) behavior exists:
 * 1) The RTCP BYE packet may arrive earlier then the last RTP packet (also for tunneled sessions)
This looks like a pure flaw or bug in the server, and it's already known.
 2) When an RTCP BYE is sent, no more RTCP packets will be sent at all within that session, but RTP packets may be sent
I think that the server should either stop sending both RTP and RTCP data and respond the PLAY requests with error code in this case (455 Method Not Valid In This State?), or send both RTP and RTCP.
 3) Two subsequent PLAY requests with the same Range stop, will cause the stop in the last one to be discarded. Instead the Range played will be from the requested start position until the end of the media.
When testing this a patch was made to prevent stop positions being treated as the rest of the media (patch will be attached).
 4) The stop position in a PLAY request's Range will be remembered in the server until a new PLAY request with a Range is received
The server collect statistics from the pipeline in a function called collect_media_stats() in rtsp-media.c. One of the things the function collects is the current Range, which from the beginning is 0-duration. The information about the duration is, however, lost when a PLAY with a Range is received. The duration will be restored when a FLUSHING seek with an open stop is sent to the pipeline.

== RTSP/RTP specification interpretation and ref ==

The RTP specification says that an RTCP BYE SHOULD be the last packet sent within a given SSRC [2, p. 22]. The RTSP 2.0 draft says that an RTSP server MUST NOT send an RTCP BYE message until it has finished using it's current SSRC and that it should keep the SSRC until the RTP session is terminated [3, p. 283]. The RTSP 1.0 RFC states that a PLAY request without a range header is legal and that the streams starts to be played from the beginning, or a pause point if it's present [1, p. 34]. A PAUSE request causes the stream to be halted and the current position becomes the pause point [1, p. 36]. When the stop position from a PLAY request's Range is reached, playback is automatically paused, as if a PAUSE request was received [1, p. 35]. A PAUSE request will also discard all queued PLAY requests (in gst-rtsp-server PLAY requests are not queued though) [1, p. 36].

I interpret the RTSP specification as if it should be possible to issue PLAY requests in a sequence, and if one of them is sent without a Range header, playback will continue were the previous PLAY stopped. It's of course an exception if the media has reached it's stop position, since it's not possible to continue and according to RTSP 2.0 draft the server SHOULD reply with an 457 "Invalid Range" in such case [3, p. 72].

== Suggested behavior ==

Use case 1) should preferably be supported by the server. Even if one can argue that the session is ended when an RTCP BYE is sent. There exists clients that depend on receiving an RTCP BYE packet after a range is completed.

In Use case 2) the server should preferably respond with Error Code 457 "Invalid Range".

In Use case 3) the proper thing a server would be to respond to the second PLAY by continue from the current pause point to the end (in this case Range 5-17).

== References ==

[1] RTSP - RFC 2326
[2] RTP - RFC 3550
[3] RTSP 2.0 Draft v40