"GStreamer" (GNOME Bugzilla)
2015-12-17 14:35:24 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=759598
Bug ID: 759598
Summary: Lacking support for multiple PLAY requests in one RTSP
session
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-rtsp-server
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@axis.com
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---
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
Bug ID: 759598
Summary: Lacking support for multiple PLAY requests in one RTSP
session
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-rtsp-server
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@axis.com
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---
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
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.