Section 11.1), which represents the minimal media delivery for playback implementation.
Feature tags are used to determine whether the client, server, or proxy supports the functionality that is necessary to achieve the desired service. To determine support of a feature tag, several different headers can be used, each explained below: Supported: This header is used to determine the complete set of functionality that both client and server have, in general, and is not dependent on a specific resource. The intended usage is to determine before one needs to use a functionality that it is supported. It can be used in any method, but OPTIONS is the most suitable as it simultaneously determines all methods that are implemented. When sending a request, the requester declares all its capabilities by including all supported feature tags. This results in the receiver learning the requester's feature support. The receiver then includes its set of features in the response. Proxy-Supported: This header is used in a similar fashion as the Supported header, but instead of giving the supported functionality of the client or server, it provides both the requester and the responder a view of the common functionality supported in general by all members of the proxy chain between the client and server; it does not depend on the resource. Proxies are required to add this header whenever the Supported header is present, but proxies may also add it independently of the requester. Require: This header can be included in any request where the endpoint, i.e., the client or server, is required to understand the feature to correctly perform the request. This can, for example, be a SETUP request, where the server is required to understand a certain parameter to be able to set up the media delivery correctly. Ignoring this parameter would not have the desired effect and is not acceptable. Therefore, the endpoint receiving a request containing a Require MUST negatively acknowledge any feature that it does not understand and not perform the request. The response in cases where features are not supported is 551 (Option Not Supported). Also, the features that are not supported are given in the Unsupported header in the response. Proxy-Require: This header has the same purpose and behavior as Require except that it only applies to proxies and not the endpoint. Features that need to be supported by both proxies and endpoints need to be included in both the Require and Proxy-Require header.
Unsupported: This header is used in a 551 (Option Not Supported) error response, to indicate which features were not supported. Such a response is only the result of the usage of the Require or Proxy-Require headers where one or more features were not supported. This information allows the requester to make the best of situations as it knows which features are not supported. Section 18.33). This header allows a client to request that two or more requests be processed in the same RTSP session context that the first request
creates. In other words, a client can request that two or more media streams be set up and then played without needing to wait for a single response. This speeds up the initial start-up time for an RTSP session by at least one RTT. If a pipelined request builds on the successful completion of one or more prior requests, the requester must verify that all requests were executed as expected. A common example will be two SETUP requests and a PLAY request. In case one of the SETUP requests fails unexpectedly, the PLAY request can still be successfully executed. However, the resulting presentation will not be as expected by the requesting client, as only a single media instead of two will be played. In this case, the client can send a PAUSE request, correct the failing SETUP request, and then request it be played. RFC5234] in Section 20. The methods are summarized in Table 7.
+---------------+-----------+--------+-------------+-------------+ | method | direction | object | Server req. | Client req. | +---------------+-----------+--------+-------------+-------------+ | DESCRIBE | C -> S | P,S | recommended | recommended | | | | | | | | GET_PARAMETER | C -> S | P,S | optional | optional | | | | | | | | | S -> C | P,S | optional | optional | | | | | | | | OPTIONS | C -> S | P,S | required | required | | | | | | | | | S -> C | P,S | optional | optional | | | | | | | | PAUSE | C -> S | P,S | required | required | | | | | | | | PLAY | C -> S | P,S | required | required | | | | | | | | PLAY_NOTIFY | S -> C | P,S | required | required | | | | | | | | REDIRECT | S -> C | P,S | optional | required | | | | | | | | SETUP | C -> S | S | required | required | | | | | | | | SET_PARAMETER | C -> S | P,S | required | optional | | | | | | | | | S -> C | P,S | optional | optional | | | | | | | | TEARDOWN | C -> S | P,S | required | required | | | | | | | | | S -> C | P | required | required | +---------------+-----------+--------+-------------+-------------+ Table 7: Overview of RTSP Methods Note on Table 7: This table covers RTSP methods, their direction, and on what objects (P: presentation, S: stream) they operate. Further, it indicates whether a server or a client implementation is required (mandatory), recommended, or optional. Further note on Table 7: the GET_PARAMETER is optional. For example, a fully functional server can be built to deliver media without any parameters. However, SET_PARAMETER is required, i.e., mandatory to implement for the server; this is due to its usage for keep-alive. PAUSE is required because it is the only way of leaving the Play state without terminating the whole session.
If an RTSP agent does not support a particular method, it MUST return a 501 (Not Implemented) response code and the requesting RTSP agent, in turn, SHOULD NOT try this method again for the given agent/ resource combination. An RTSP proxy whose main function is to log or audit and not modify transport or media handling in any way MAY forward RTSP messages with unknown methods. Note that the proxy still needs to perform the minimal required processing, like adding the Via header. Section 4.3.7 of [RFC7231]. However, in RTSP, OPTIONS is bidirectional in that a client can send the request to a server and vice versa. A client MUST implement the capability to send an OPTIONS request and a server or a proxy MUST implement the capability to respond to an OPTIONS request. In addition to this "MUST-implement" functionality, clients, servers and proxies MAY provide support both for sending OPTIONS requests and for generating responses to the requests. An OPTIONS request may be issued at any time. Such a request does not modify the session state. However, it may prolong the session lifespan (see below). The URI in an OPTIONS request determines the scope of the request and the corresponding response. If the Request- URI refers to a specific media resource on a given host, the scope is limited to the set of methods supported for that media resource by the indicated RTSP agent. A Request-URI with only the host address limits the scope to the specified RTSP agent's general capabilities without regard to any specific media. If the Request-URI is an asterisk ("*"), the scope is limited to the general capabilities of the next hop (i.e., the RTSP agent in direct communication with the request sender). Regardless of the scope of the request, the Public header MUST always be included in the OPTIONS response, listing the methods that are supported by the responding RTSP agent. In addition, if the scope of the request is limited to a media resource, the Allow header MUST be included in the response to enumerate the set of methods that are allowed for that resource unless the set of methods completely matches the set in the Public header. If the given resource is not available, the RTSP agent SHOULD return an appropriate response code, such as 3rr or 4xx. The Supported header MAY be included in the request to query the set of features that are supported by the responding RTSP agent.
The OPTIONS method can be used to keep an RTSP session alive. However, this is not the preferred way of session keep-alive signaling; see Section 18.49. An OPTIONS request intended for keeping alive an RTSP session MUST include the Session header with the associated session identifier. Such a request SHOULD also use the media or the aggregated control URI as the Request-URI. Example: C->S: OPTIONS rtsp://server.example.com RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2 Proxy-Require: gzipped-messages Supported: play.basic S->C: RTSP/2.0 200 OK CSeq: 1 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS Supported: play.basic, setup.rtp.rtcp.mux, play.scale Server: PhonyServer/1.1 Note that the "gzipped-messages" feature tag in the Proxy-Require is a fictitious feature.
Example: C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 CSeq: 312 User-Agent: PhonyClient/1.2 Accept: application/sdp, application/example S->C: RTSP/2.0 200 OK CSeq: 312 Date: Thu, 23 Jan 1997 15:35:06 GMT Server: PhonyServer/1.1 Content-Base: rtsp://server.example.com/fizzle/foo/ Content-Type: application/sdp Content-Length: 358 v=0 o=MNobody 2890844526 2890842807 IN IP4 192.0.2.46 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/lectures/sdp.ps firstname.lastname@example.org (Seminar Management) c=IN IP4 0.0.0.0 a=control:* t=2873397496 2873404696 m=audio 3456 RTP/AVP 0 a=control:audio m=video 2232 RTP/AVP 31 a=control:video Media initialization is a requirement for any RTSP-based system, but the RTSP specification does not dictate that this is required to be done via the DESCRIBE method. There are three ways that an RTSP client may receive initialization information: o via an RTSP DESCRIBE request o via some other protocol (HTTP, email attachment, etc.) o via some form of user interface If a client obtains a valid description from an alternate source, the client MAY use this description for initialization purposes without issuing a DESCRIBE request for the same media. The client should use any MTag to either validate the presentation description or make the session establishment conditional on being valid.
It is RECOMMENDED that minimal servers support the DESCRIBE method, and highly recommended that minimal clients support the ability to act as "helper applications" that accept a media initialization file from a user interface, or other means that are appropriate to the operating environment of the clients. Appendix B. Init: Initial state. No session exists. Ready: Session is ready to start playing. Play: Session is playing, i.e., sending media-stream data in the direction S->C. The SETUP request for a URI specifies the transport mechanism to be used for the streamed media. The SETUP method may be used in two different cases, namely, creating an RTSP session and changing the transport parameters of media streams that are already set up. SETUP can be used in all three states, Init, Ready, and Play, to change the transport parameters. Additionally, Init and Ready can also be used for the creation of the RTSP session. The usage of the SETUP method in the Play state to add a media resource to the session is unspecified. The Transport header, see Section 18.54, specifies the media- transport parameters acceptable to the client for data transmission; the response will contain the transport parameters selected by the server. This allows the client to enumerate, in descending order of preference, the transport mechanisms and parameters acceptable to it, so the server can select the most appropriate. It is expected that the session description format used will enable the client to select a limited number of possible configurations that are offered as choices to the server. All transport-related parameters SHALL be included in the Transport header; the use of other headers for this purpose is NOT RECOMMENDED due to middleboxes, such as firewalls or NATs. For the benefit of any intervening firewalls, a client MUST indicate the known transport parameters, even if it has no influence over these parameters, for example, where the server advertises a fixed- multicast address as destination.
Since SETUP includes all transport initialization information, firewalls and other intermediate network devices (which need this information) are spared the more arduous task of parsing the DESCRIBE response, which has been reserved for media initialization. The client MUST include the Accept-Ranges header in the request, indicating all supported unit formats in the Range header. This allows the server to know which formats it may use in future session- related responses, such as a PLAY response without any range in the request. If the client does not support a time format necessary for the presentation, the server MUST respond using 456 (Header Field Not Valid for Resource) and include the Accept-Ranges header with the range unit formats supported for the resource. In a SETUP response, the server MUST include the Accept-Ranges header (see Section 18.5) to indicate which time formats are acceptable to use for this media resource. The SETUP 200 OK response MUST include the Media-Properties header (see Section 18.29). The combination of the parameters of the Media- Properties header indicates the nature of the content present in the session (see also Section 4.7). For example, a live stream with time shifting is indicated by o Random access set to Random-Access, o Content Modifications set to Time-Progressing, and o Retention set to Time-Duration (with specific recording window time value). The SETUP 200 OK response MUST include the Media-Range header (see Section 18.30) if the media is Time-Progressing.
A basic example for SETUP: C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 CSeq: 302 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", RTP/AVP/TCP;unicast;interleaved=0-1 Accept-Ranges: npt, clock User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 302 Date: Thu, 23 Jan 1997 15:35:06 GMT Server: PhonyServer/1.1 Session: QKyjN8nt2WqbWw4tIYof52;timeout=60 Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/ "192.0.2.53:4589"; src_addr="198.51.100.241:6256"/ "198.51.100.241:6257"; ssrc=2A3F93ED Accept-Ranges: npt Media-Properties: Random-Access=3.2, Time-Progressing, Time-Duration=3600.0 Media-Range: npt=0-2893.23 In the above example, the client wants to create an RTSP session containing the media resource "rtsp://example.com/foo/bar/baz.rm". The transport parameters acceptable to the client are either RTP/AVP/ UDP (UDP per default) to be received on client port 4588 and 4589 at the address the RTSP setup connection comes from or RTP/AVP interleaved on the RTSP control channel. The server selects the RTP/AVP/UDP transport and adds the address and ports it will send and receive RTP and RTCP from, and the RTP SSRC that will be used by the server. The server MUST generate a session identifier in response to a successful SETUP request unless a SETUP request to a server includes a session identifier or a Pipelined-Requests header referencing an existing session context. In that latter case, the server MUST bundle this SETUP request into the existing session (aggregated session) or return a 459 (Aggregate Operation Not Allowed) error code (see Section 17.4.23). An aggregate control URI MUST be used to control an aggregated session. This URI MUST be different from the stream control URIs of the individual media streams included in the aggregate (see Section 13.4.2 for aggregated sessions and for the particular URIs see Appendix D.1.1). The aggregate control URI is to be specified by the session description if the server supports aggregated control and aggregated control is desired for the session.
However, even if aggregated control is offered, the client MAY choose not to set up the session in aggregated control. If an aggregate control URI is not specified in the session description, it is normally an indication that non-aggregated control should be used. The SETUP of media streams in an aggregate that has not been given an aggregated control URI is unspecified. While the session ID sometimes carries enough information for aggregate control of a session, the aggregate control URI is still important for some methods such as SET_PARAMETER where the control URI enables the resource in question to be easily identified. The aggregate control URI is also useful for proxies, enabling them to route the request to the appropriate server, and for logging, where it is useful to note the actual resource on which a request was operating. A session will exist until it is either removed by a TEARDOWN request or is timed out by the server. The server MAY remove a session that has not demonstrated liveness signs from the client(s) within a certain timeout period. The default timeout value is 60 seconds; the server MAY set this to a different value and indicate so in the timeout field of the Session header in the SETUP response. For further discussion, see Section 18.49. Signs of liveness for an RTSP session include any RTSP requests from a client that contain a Session header with the ID for that session, as well as RTCP sender or receiver reports if RTP is used to transport the underlying media stream. RTCP sender reports may, for example, be received in session where the server is invited into a conference session and are thus valid as a liveness indicator. If a SETUP request on a session fails for any reason, the session state, as well as transport and other parameters for associated streams, MUST remain unchanged from their values as if the SETUP request had never been received by the server.
the changing of transport parameters will require that the client perform a TEARDOWN of the affected media and then set it up again. For an aggregated session, not tearing down all the media at the same time will avoid the creation of a new session. All transport parameters MAY be changed. However, the primary usage expected is to either change the transport protocol completely, like switching from Interleaved TCP mode to UDP or vice versa, or to change the delivery address. In a SETUP response for a request to change the transport parameters while in Play state, the server MUST include the Range header to indicate at what point the new transport parameters will be used. Further, if RTP is used for delivery, the server MUST also include the RTP-Info header to indicate at what timestamp and RTP sequence number the change will take place. If both RTP-Info and Range are included in the response, the "rtp_time" parameter and start point in the Range header MUST be for the corresponding time, i.e., be used in the same way as for PLAY to ensure the correct synchronization information is available. If the transport-parameters change that happened while in Play state results in a change of synchronization-related information, for example, changing RTP SSRC, the server MUST include the necessary synchronization information in the SETUP response. However, the server SHOULD avoid changing the synchronization information if possible. Section 18.47). It MUST deliver stream data until the end of the range if given, until a new PLAY request is received, until a PAUSE request (Section 13.5) is received, or until the end of the media is reached. If no Range
header is present in the PLAY request, the server SHALL play from current pause point until the end of media. The pause point defaults at session start to the beginning of the media. For media that is time-progressing and has no retention, the pause point will always be set equal to NPT "now", i.e., the current delivery point. The pause point may also be set to a particular point in the media by the PAUSE method; see Section 13.6. The pause point for media that is currently playing is equal to the current media position. For time- progressing media with time-limited retention, if the pause point represents a position that is older than what is retained by the server, the pause point will be moved to the oldest retained position. What range values are valid depends on the type of content. For content that isn't time-progressing, the range value is valid if the given range is part of any media within the aggregate. In other words, the valid media range for the aggregate is the union of all of the media components in the aggregate. If a given range value points outside of the media, the response MUST be the 457 (Invalid Range) error code and include the Media-Range header (Section 18.30) with the valid range for the media. Except for time-progressing content where the client requests a start point prior to what is retained, the start point is adjusted to the oldest retained content. For a start point that is beyond the media front edge, i.e., beyond the current value for "now", the server SHALL adjust the start value to the current front edge. The Range header's stop point value may point beyond the current media edge. In that case, the server SHALL deliver media from the requested (and possibly adjusted) start point until the first of either the provided stop point or the end of the media. Please note that if one simply wants to play from a particular start point until the end of media, using a Range header with an implicit stop point is RECOMMENDED. If a client requests to start playing at the end of media, either explicitly with a Range header or implicitly with a pause point that is at the end of media, a 457 (Invalid Range) error MUST be sent and include the Media-Range header (Section 18.30). It is specified below that the Range header also must be included in the response and that it will carry the pause point in the media, in the case of the session being in Ready State. Note that this also applies if the pause point or requested start point is at the beginning of the media and a Scale header (Section 18.46) is included with a negative value (playing backwards). For media with random access properties, a client may indicate which policy for start point selection the server should use. This is done by including the Seek-Style header (Section 18.47) in the PLAY
request. The Seek-Style applied will affect the content of the Range header as it will be adjusted to indicate from what point the media actually is delivered. A client desiring to play the media from the beginning MUST send a PLAY request with a Range header pointing at the beginning, e.g., "npt=0-". If a PLAY request is received without a Range header and media delivery has stopped at the end, the server SHOULD respond with a 457 (Invalid Range) error response. In that response, the current pause point MUST be included in a Range header. All range specifiers in this specification allow for ranges with an implicit start point (e.g., "npt=-30"). When used in a PLAY request, the server treats this as a request to start or resume delivery from the current pause point, ending at the end time specified in the Range header. If the pause point is located later than the given end value, a 457 (Invalid Range) response MUST be returned. The example below will play seconds 10 through 25. It also requests that the server deliver media from the first random access point prior to the indicated start point. C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 CSeq: 835 Session: ULExwZCXh2pd0xuFgkgZJW Range: npt=10-25 Seek-Style: RAP User-Agent: PhonyClient/1.2 Servers MUST include a Range header in any PLAY response, even if no Range header was present in the request. The response MUST use the same format as the request's Range header contained. If no Range header was in the request, the format used in any previous PLAY request within the session SHOULD be used. If no format has been indicated in a previous request, the server MAY use any time format supported by the media and indicated in the Accept-Ranges header in the SETUP request. It is RECOMMENDED that NPT is used if supported by the media. For any error response to a PLAY request, the server's response depends on the current session state. If the session is in Ready state, the current pause point is returned using a Range header with the pause point as the explicit start point and an implicit stop point. For time-progressing content, where the pause-point moves with real-time due to limited retention, the current pause point is returned. For sessions in Play state, the current playout point and
the remaining parts of the range request are returned. For any media with retention longer than 0 seconds, the currently valid Media-Range header SHALL also be included in the response. A PLAY response MAY include a header carrying synchronization information. As the information necessary is dependent on the media- transport format, further rules specifying the header and its usage are needed. For RTP the RTP-Info header is specified, see Section 18.45, and used in the following example. Here is a simple example for a single audio stream where the client requests the media starting from 3.52 seconds and to the end. The server sends a 200 OK response with the actual play time, which is 10 ms prior (3.51), and the RTP-Info header that contains the necessary parameters for the RTP stack. C->S: PLAY rtsp://example.com/audio RTSP/2.0 CSeq: 836 Session: ULExwZCXh2pd0xuFgkgZJW Range: npt=3.52- User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 836 Date: Thu, 23 Jan 1997 15:35:06 GMT Server: PhonyServer/1.0 Range: npt=3.51-324.39 Seek-Style: First-Prior Session: ULExwZCXh2pd0xuFgkgZJW RTP-Info:url="rtsp://example.com/audio" ssrc=0D12F123:seq=14783;rtptime=2345962545 S->C: RTP Packet TS=2345962545 => NPT=3.51 Media duration=0.16 seconds The server replies with the actual start point that will be delivered. This may differ from the requested range if alignment of the requested range to valid frame boundaries is required for the media source. Note that some media streams in an aggregate may need to be delivered from even earlier points. Also, some media formats have a very long duration per individual data unit; therefore, it might be necessary for the client to parse the data unit, and select where to start. The server SHALL also indicate which policy it uses for selecting the actual start point by including a Seek-Style header.
In the following example, the client receives the first media packet that stretches all the way up and past the requested playtime. Thus, it is the client's decision whether to render to the user the time between 3.52 and 7.05 or to skip it. In most cases, it is probably most suitable not to render that time period. C->S: PLAY rtsp://example.com/audio RTSP/2.0 CSeq: 836 Session: ZGGyCJOs8xaLkdNK2dmxQO Range: npt=7.05- User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 836 Date: Thu, 23 Jan 1997 15:35:06 GMT Server: PhonyServer/1.0 Session: ZGGyCJOs8xaLkdNK2dmxQO Range: npt=3.52- Seek-Style: First-Prior RTP-Info:url="rtsp://example.com/audio" ssrc=0D12F123:seq=14783;rtptime=2345962545 S->C: RTP Packet TS=2345962545 => NPT=3.52 Duration=4.15 seconds After playing the desired range, the presentation does NOT change to the Ready state, media delivery simply stops. If it is necessary to put the stream into the Ready state, a PAUSE request MUST be issued. A PLAY request while the stream is still in the Play state is legal and can be issued without an intervening PAUSE request. Such a request MUST replace the current PLAY action with the new one requested, i.e., being handled in the same way as if as the request was received in Ready state. In the case that the range in the Range header has an implicit start time ("-endtime"), the server MUST continue to play from where it currently was until the specified endpoint. This is useful to change the end to at another point than in the previous request. The following example plays the whole presentation starting at SMPTE time code 0:10:20 until the end of the clip. Note: the RTP-Info headers have been broken into several lines, where subsequent lines start with whitespace as allowed by the syntax.
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 CSeq: 833 Session: N465Wvsv0cjUy6tLqINkcf Range: smpte=0:10:20- User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 833 Date: Thu, 23 Jan 1997 15:35:06 GMT Session: N465Wvsv0cjUy6tLqINkcf Server: PhonyServer/1.0 Range: smpte=0:10:22-0:15:45 Seek-Style: Next RTP-Info:url="rtsp://example.com/twister.en" ssrc=0D12F123:seq=14783;rtptime=2345962545 For playing back a recording of a live presentation, it may be desirable to use clock units: C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 CSeq: 835 Session: N465Wvsv0cjUy6tLqINkcf Range: clock=19961108T142300Z-19961108T143520Z User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 835 Date: Thu, 23 Jan 1997 15:35:06 GMT Session: N465Wvsv0cjUy6tLqINkcf Server: PhonyServer/1.0 Range: clock=19961108T142300Z-19961108T143520Z Seek-Style: Next RTP-Info:url="rtsp://example.com/meeting.en" ssrc=0D12F123:seq=53745;rtptime=484589019
For aggregated sessions where the initial SETUP request (creating a session) is followed by one or more additional SETUP requests, a PLAY request MAY be pipelined (Section 12) after those additional SETUP requests without awaiting their responses. This procedure can reduce the delay from the start of session establishment until media playout has started with one RTT. However, a client needs to be aware that using this procedure will result in the playout of the server state established at the time of processing the PLAY, i.e., after the processing of all the requests prior to the PLAY request in the pipeline. This state may not be the intended one due to failure of any of the prior requests. A client can easily determine this based on the responses from those requests. In case of failure, the client can halt the media playout using PAUSE and try to establish the intended state again before issuing another PLAY request.
while the server still plays the first range (10-15). The server changes the current play to continue to 25 seconds, i.e., the equivalent single request would be PLAY with "range: npt=10-25". C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 834 Session: apzA8LnjQ5KWTdw0kUkiRh Range: npt=10-15 User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 834 Date: Thu, 23 Jan 1997 15:35:06 GMT Session: apzA8LnjQ5KWTdw0kUkiRh Server: PhonyServer/1.0 Range: npt=10-15 Seek-Style: Next RTP-Info:url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=5712;rtptime=934207921, url="rtsp://example.com/fizzle/videotrack" ssrc=789DAF12:seq=57654;rtptime=2792482193 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 835 Session: apzA8LnjQ5KWTdw0kUkiRh Range: npt=-25 User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 835 Date: Thu, 23 Jan 1997 15:35:09 GMT Session: apzA8LnjQ5KWTdw0kUkiRh Server: PhonyServer/1.0 Range: npt=14-25 Seek-Style: Next RTP-Info:url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=5712;rtptime=934239921, url="rtsp://example.com/fizzle/videotrack" ssrc=789DAF12:seq=57654;rtptime=2792842193 A common use of a PLAY request while in Play state is changing the scale of the media, i.e., entering or leaving fast forward or fast rewind. The client can issue an updating PLAY request that is either a continuation or a complete replacement, as discussed above this section. Below is an example of a client that is requesting a fast forward (scale = 2) without giving a stop point and then a change from fast forward to regular playout (scale = 1). In the second PLAY
request, the time is set explicitly to be wherever the server currently plays out (npt=now-) and the server responds with the actual playback point where the new scale actually takes effect (npt=02:17:27.144-). C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 2034 Session: apzA8LnjQ5KWTdw0kUkiRh Range: npt=now- Scale: 2.0 User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 2034 Date: Thu, 23 Jan 1997 15:35:06 GMT Session: apzA8LnjQ5KWTdw0kUkiRh Server: PhonyServer/1.0 Range: npt=02:17:21.394- Seek-Style: Next Scale: 2.0 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=5712;rtptime=934207921, url="rtsp://example.com/fizzle/videotrack" ssrc=789DAF12:seq=57654;rtptime=2792482193 [playing in fast forward and now returning to scale = 1] C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 2035 Session: apzA8LnjQ5KWTdw0kUkiRh Range: npt=now- Scale: 1.0 User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 2035 Date: Thu, 23 Jan 1997 15:35:09 GMT Session: apzA8LnjQ5KWTdw0kUkiRh Server: PhonyServer/1.0 Range: npt=02:17:27.144- Seek-Style: Next Scale: 1.0 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=5712;rtptime=934239921, url="rtsp://example.com/fizzle/videotrack" ssrc=789DAF12:seq=57654;rtptime=2792842193
Section 18.29): o the Random Access property is set to Random-Access; o the Content Modifications property is set to Immutable; o the Retention property is set to Unlimited or Time-Limited. Playing on-demand media follows the general usage as described in Section 13.4.1. Section 18.29): o the Random Access property is set to Random-Access; o the Content Modifications property is set to Dynamic; o the Retention property is set to Unlimited or Time-Limited. Playing on-demand media follows the general usage as described in Section 13.4.1 as long as the media has not been changed. There are two ways for the client to be informed about changes of media resources in Play state. The first being that the client will receive a PLAY_NOTIFY request with the Notify-Reason header set to media-properties-update (see Section 13.5.2). The client can use the value of the Media-Range header to decide further actions, if the Media-Range header is present in the PLAY_NOTIFY request. The second way is that the client issues a GET_PARAMETER request without a body but including a Media-Range header. The 200 OK response MUST include the current Media-Range header (see Section 18.30). Section 18.29): o the Random Access property is set to No-Seeking; o the Content Modifications property is set to Time-Progressing;
o the Retention property's Time-Duration is set to 0.0. For live media, the SETUP 200 OK response MUST include the Media- Range header (see Section 18.30). A client MAY send PLAY requests without the Range header. If the request includes the Range header, it MUST use a symbolic value representing "now". For NPT, that range specification is "npt=now-". The server MUST include the Range header in the response, and it MUST indicate an explicit time value and not a symbolic value. In other words, "npt=now-" cannot be used in the response. Instead, the time since session start is recommended, expressed as an open interval, e.g., "npt=96.23-". An absolute time value (clock) for the corresponding time MAY be given, i.e., "clock=20030213T143205Z-". The Absolute Time format can only be used if the client has shown support for it using the Accept-Ranges header. Section 18.29): o the Random Access property is set to Random-Access; o the Content Modifications property is set to Time-Progressing; o the Retention property is set to Time-Limited or Unlimited The SETUP 200 OK response MUST include the Media-Range header (see Section 18.30) for this type of media. For live media with recording, the Range header indicates the current delivery point in the media and the Media-Range header indicates the currently available media window around the current time. This window can cover recorded content in the past (seen from current time in the media) or recorded content in the future (seen from current time in the media). The server adjusts the delivery point to the requested border of the window. If the client requests a delivery point that is located outside the recording window, e.g., if the requested point is too far in the past, the server selects the oldest point in the recording. The considerations in Section 13.5.3 apply if a client requests delivery with scale (Section 18.46) values other than 1.0 (normal playback rate) while delivering live media with recording.
Section 18.29): o the Random Access property is set to Random-Access; o the Content Modifications property is set to Time-Progressing; o the Retention property is set to Time-Duration and a value indicating the recording interval (>0). The SETUP 200 OK response MUST include the Media-Range header (see Section 18.30) for this type of media. For live media with recording, the Range header indicates the current time in the media and the Media-Range header indicates a window around the current time. This window can cover recorded content in the past (seen from current time in the media) or recorded content in the future (seen from current time in the media). The server adjusts the play point to the requested border of the window, if the client requests a play point that is located outside the recording windows, e.g., if requested too far in the past, the server selects the oldest range in the recording. The considerations in Section 13.5.3 apply if a client requests delivery using a scale (Section 18.46) value other than 1.0 (normal playback rate) while delivering live media with time-shift.