draft-ietf-mmusic-rfc2326bis-39.txt   draft-ietf-mmusic-rfc2326bis-40.txt 
MMUSIC Working Group H. Schulzrinne MMUSIC Working Group H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Obsoletes: 2326 (if approved) A. Rao Obsoletes: 2326 (if approved) A. Rao
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: July 21, 2014 R. Lanphier Expires: August 14, 2014 R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
January 17, 2014 February 10, 2014
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-39 draft-ietf-mmusic-rfc2326bis-40
Abstract Abstract
This memorandum defines RTSP version 2.0 which obsoletes RTSP version This memorandum defines RTSP version 2.0 which obsoletes RTSP version
1.0 defined in RFC 2326. 1.0 defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-layer The Real Time Streaming Protocol, or RTSP, is an application-layer
protocol for setup and control of the delivery of data with real-time protocol for setup and control of the delivery of data with real-time
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 21, 2014. This Internet-Draft will expire on August 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 31 skipping to change at page 3, line 31
7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 38 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 38
7.2. Request Header Fields . . . . . . . . . . . . . . . . . . 40 7.2. Request Header Fields . . . . . . . . . . . . . . . . . . 40
8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 42 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 42
8.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 42 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 42
8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 46 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 46
9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 46 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 46
9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 47 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 47
9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 48 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 48
9.3. Message Body Format Negotiation . . . . . . . . . . . . . 48 9.3. Message Body Format Negotiation . . . . . . . . . . . . . 48
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 48 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.1. Reliability and Acknowledgements . . . . . . . . . . . . 49 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 49
10.2. Using Connections . . . . . . . . . . . . . . . . . . . 50 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 50
10.3. Closing Connections . . . . . . . . . . . . . . . . . . 53 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 53
10.4. Timing Out Connections and RTSP Messages . . . . . . . . 54 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 54
10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 55 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 55
10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 56 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 57
10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 57 10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 57
11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 58 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 58
11.1. Feature Tag: play.basic . . . . . . . . . . . . . . . . 60 11.1. Feature Tag: play.basic . . . . . . . . . . . . . . . . 60
12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 60 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 61
13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61
13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 63 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 63
13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 64 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 64
13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 66 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 66
13.3.1. Changing Transport Parameters . . . . . . . . . . . 69 13.3.1. Changing Transport Parameters . . . . . . . . . . . 69
13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 70 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 70
13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 70 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 70
13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 75 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 75
13.4.3. Updating current PLAY Requests . . . . . . . . . . . 76 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 76
13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 79 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 79
skipping to change at page 33, line 9 skipping to change at page 33, line 9
No-seeking: Seeking is not possible at all. No-seeking: Seeking is not possible at all.
If random access is possible, as indicated by the Media-Properties If random access is possible, as indicated by the Media-Properties
header, the actual behavior policy when seeking can be controlled header, the actual behavior policy when seeking can be controlled
using the Seek-Style header (Section 18.47). using the Seek-Style header (Section 18.47).
4.7.2. Retention 4.7.2. Retention
Media may have different retention policies in place that affect the Media may have different retention policies in place that affect the
operation on media. The following different media retention policies operation on media. The following different media retention policies
are envisioned and taken into consideration where applicable: are defined:
Unlimited: The media will not be removed as long as the RTSP session Unlimited: The media will not be removed as long as the RTSP session
is in existence. is in existence.
Time-Limited: The media will not be removed before the given Time-Limited: The media will not be removed before the given
wallclock time. After that time it may or may not be available wallclock time. After that time it may or may not be available
any more. any more.
Time-Duration: Each individual unit of the media will be retained Time-Duration: The media (on fragment or unit basis) will be
for the specified duration. retained for the specified duration.
4.7.3. Content Modifications 4.7.3. Content Modifications
There is also the question of how the content may change over time There is also the question of how the content may change over time
for a given media resource: for a given media resource:
Immutable: The content of the media will not change, even if the Immutable: The content of the media will not change, even if the
representation, i.e., encoding, quality, etc., may change. representation, i.e., encoding, quality, etc., may change.
Dynamic: Between explicit updates the media content will not change, Dynamic: The content can change due to external methods or triggers,
but the content may change due to external methods or triggers, such as playlists, but this will be announced by explicit updates.
such as playlists.
Time-Progressing: As time progresses new content will become Time-Progressing: As time progresses new content will become
available. If the content also is retained it will become longer available. If the content also is retained it will become longer
as everything between the start point and the point currently as everything between the start point and the point currently
being made available can be accessed. If the media server uses a being made available can be accessed. If the media server uses a
sliding window policy for retention, the start point will also sliding window policy for retention, the start point will also
change as time progresses. change as time progresses.
4.7.4. Supported Scale Factors 4.7.4. Supported Scale Factors
skipping to change at page 34, line 10 skipping to change at page 34, line 10
supported. The attribute is named "Scales". The "Scales" attribute supported. The attribute is named "Scales". The "Scales" attribute
may be updated at any point in the content due to content consisting may be updated at any point in the content due to content consisting
of spliced pieces or content being dynamically updated by out-of-band of spliced pieces or content being dynamically updated by out-of-band
mechanisms. mechanisms.
4.7.5. Mapping to the Attributes 4.7.5. Mapping to the Attributes
This section shows examples of how one would map the above usages to This section shows examples of how one would map the above usages to
the properties and their values. the properties and their values.
Example of On-demand: Random Access: Random-Access=5.0, Content Example of On-demand:
Modifications: Immutable, Retention: Unlimited or Time-Limited. Random Access: Random-Access=5.0, Content Modifications:
Immutable, Retention: Unlimited or Time-Limited.
Example of Dynamic On-demand: Random Access: Random-Access=3.0, Example of Dynamic On-demand:
Content Modifications: Dynamic, Retention: Unlimited or Time- Random Access: Random-Access=3.0, Content Modifications: Dynamic,
Limited. Retention: Unlimited or Time-Limited.
Example of Live: Random Access: No-seeking, Content Modifications: Example of Live:
Time-Progressing, Retention: Time-Duration=0.0 Random Access: No-seeking, Content Modifications: Time-
Progressing, Retention: Time-Duration=0.0
Example of Live with Recording: Random Access: Random-Access=3.0, Example of Live with Recording:
Content Modifications: Time-Progressing, Retention: Time- Random Access: Random-Access=3.0, Content Modifications: Time-
Duration=7200.0 Progressing, Retention: Time-Duration=7200.0
5. RTSP Message 5. RTSP Message
RTSP is a text-based protocol and uses the ISO 10646 character set in RTSP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding RFC 3629 [RFC3629]. Lines MUST be terminated by CRLF. UTF-8 encoding RFC 3629 [RFC3629]. Lines MUST be terminated by CRLF.
Text-based protocols make it easier to add optional parameters in Text-based protocols make it easier to add optional parameters in
a self-describing manner. Since the number of parameters and the a self-describing manner. Since the number of parameters and the
frequency of commands is low, processing efficiency is not a frequency of commands is low, processing efficiency is not a
concern. Text-based protocols, if done carefully, also allow easy concern. Text-based protocols, if done carefully, also allow easy
skipping to change at page 35, line 16 skipping to change at page 35, line 18
below ABNF [RFC5234] is for information and the formal message below ABNF [RFC5234] is for information and the formal message
specification is present in Section 20.2.2. specification is present in Section 20.2.2.
generic-message = start-line generic-message = start-line
*(rtsp-header CRLF) *(rtsp-header CRLF)
CRLF CRLF
[ message-body-data ] [ message-body-data ]
start-line = Request-Line | Status-Line start-line = Request-Line | Status-Line
In the interest of robustness, agents MUST ignore any empty line(s) In the interest of robustness, agents MUST ignore any empty line(s)
received where a Request-Line or Response-Line is expected. In other received where a Request-Line or Status-Line is expected. In other
words, if the agent is reading the protocol stream at the beginning words, if the agent is reading the protocol stream at the beginning
of a message and receives a CRLF first, it MUST ignore the CRLF. of a message and receives any number of CRLFs first, it MUST ignore
any of the CRLFs.
5.2. Message Headers 5.2. Message Headers
RTSP header fields (see Section 18) include general-header, request- RTSP header fields (see Section 18) include general-header, request-
header, response-header, and message-body header fields. header, response-header, and message-body header fields.
The order in which header fields with differing field names are The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response- general-header fields first, followed by request-header or response-
header fields, and ending with the Message-body header fields. header fields, and ending with the Message-body header fields.
skipping to change at page 48, line 14 skipping to change at page 48, line 14
header fields MUST be ignored by the recipient and forwarded by header fields MUST be ignored by the recipient and forwarded by
proxies. proxies.
9.2. Message Body 9.2. Message Body
An RTSP message with a message body MUST include the Content-Type and An RTSP message with a message body MUST include the Content-Type and
Content-Length headers. When a message body is included with a Content-Length headers. When a message body is included with a
message, the data type of that content data is determined via the message, the data type of that content data is determined via the
header fields Content-Type and Content-Encoding. header fields Content-Type and Content-Encoding.
Content-Type specifies the media type of the underlying data. Content-Type specifies the media type of the underlying data. There
is no default media format and the actual format used in the body is
required to be explicitly stated in the Content-Type header. By
being explicit and always require inclusion of the Content-Type
header with accurate information one avoids the many pitfalls in
heuristic based interpretation of the body content. These are issue
HTTP and email have suffered from.
Content-Encoding may be used to indicate any additional content Content-Encoding may be used to indicate any additional content
codings applied to the data, usually for the purpose of data codings applied to the data, usually for the purpose of data
compression, that are a property of the requested resource. The compression, that are a property of the requested resource. The
default encoding is 'identity', i.e. no transformation of the message default encoding is 'identity', i.e. no transformation of the message
body. body.
The Content-Length of a message is the length of the content, The Content-Length of a message is the length of the content,
measured in octets. measured in octets.
9.3. Message Body Format Negotiation 9.3. Message Body Format Negotiation
skipping to change at page 50, line 15 skipping to change at page 50, line 21
Lack of acknowledgment of an RTSP request should be handled within Lack of acknowledgment of an RTSP request should be handled within
the constraints of the connection timeout considerations described the constraints of the connection timeout considerations described
below (Section 10.4). below (Section 10.4).
10.2. Using Connections 10.2. Using Connections
A TCP transport can be used for both persistent connections (for A TCP transport can be used for both persistent connections (for
several message exchanges) and transient connections (for a single several message exchanges) and transient connections (for a single
message exchange). Implementations of this specification MUST message exchange). Implementations of this specification MUST
support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) support RTSP over TCP. The scheme of the RTSP URI (Section 4.2)
indicates the default port that the server will listen on if the port allows the client to specify the port it will contact the server on,
is not explicitly given. and defines the default port to use if one is not explicitly given.
In addition to the registered default ports, i.e., 554 (rtsp) and 322 In addition to the registered default ports, i.e., 554 (rtsp) and 322
(rtsps), there is an alternative port 8554 registered. This port may (rtsps), there is an alternative port 8554 registered. This port may
provide some benefits from non-registered ports if a RTSP server is provide some benefits over non-registered ports if a RTSP server is
unable to use the default ports. The benefits may include pre- unable to use the default ports. The benefits may include pre-
configured security policies as well as classifiers in network configured security policies as well as classifiers in network
monitoring tools. monitoring tools.
A RTSP client opening a TCP connection for accessing a particular A RTSP client opening a TCP connection for accessing a particular
resource as identified by a URI uses the IP address and port derived resource as identified by a URI uses the IP address and port derived
from the host and port parts of the URI. The IP address is either from the host and port parts of the URI. The IP address is either
the explicit address provided in the URI or any of the addresses the explicit address provided in the URI or any of the addresses
provided when performing A and AAAA record DNS lookups of the host provided when performing A and AAAA record DNS lookups of the host
name in the URI. name in the URI.
skipping to change at page 51, line 41 skipping to change at page 51, line 45
Without a persistent connection between the client and the server, Without a persistent connection between the client and the server,
the media server has no reliable way of reaching the client. the media server has no reliable way of reaching the client.
Because the likely failure of server to client established Because the likely failure of server to client established
connections the server will not even attempt establishing any connections the server will not even attempt establishing any
connection. connection.
Queuing of server to client requests has been considered. However Queuing of server to client requests has been considered. However
a security issue exists as to how it might be possible to a security issue exists as to how it might be possible to
authorize a client establishing a new connection as being a authorize a client establishing a new connection as being a
legitimate receiver of a request related to a particular RTSP legitimate receiver of a request related to a particular RTSP
session without the client first issuing requests related to the session, without the client first issuing requests related to the
request. Thus, it would be likely to make any such requests even pending request. Thus, it would be likely to make any such
more delayed and less useful. requests even more delayed and less useful.
The sending of client and server requests can be asynchronous events. The sending of client and server requests can be asynchronous events.
To avoid deadlock situations both client and server MUST be able to To avoid deadlock situations both client and server MUST be able to
send and receive requests simultaneously. As an RTSP response may be send and receive requests simultaneously. As an RTSP response may be
queued up for transmission, reception or processing behind the peer queued up for transmission, reception or processing behind the peer
RTSP agent's own requests, all RTSP agents are required to have a RTSP agent's own requests, all RTSP agents are required to have a
certain capability of handling outstanding messages. A potential certain capability of handling outstanding messages. A potential
issue is that outstanding requests may timeout despite them being issue is that outstanding requests may timeout despite them being
processed by the peer due to the response being caught in the queue processed by the peer due to the response being caught in the queue
behind a number of requests that the RTSP agent is processing but behind a number of requests that the RTSP agent is processing but
skipping to change at page 58, line 9 skipping to change at page 58, line 17
An RTSP server or proxy in an overload situation must select the An RTSP server or proxy in an overload situation must select the
value of the Retry-After header carefully and bearing in mind its value of the Retry-After header carefully and bearing in mind its
current load situation. It is REQUIRED to increase the timeout current load situation. It is REQUIRED to increase the timeout
period in proportion to the current load on the server, i.e., an period in proportion to the current load on the server, i.e., an
increasing workload should result in an increased length of the increasing workload should result in an increased length of the
indicated unavailability. It is REQUIRED to not send the same value indicated unavailability. It is REQUIRED to not send the same value
in the Retry-After header to all requesting proxies and clients, but in the Retry-After header to all requesting proxies and clients, but
to add a variation to the mean value of the Retry-After header. to add a variation to the mean value of the Retry-After header.
A more complex case may arise when a load balancing RTSP proxy is in A more complex case may arise when a load balancing RTSP proxy is in
use, i.e., where an RTSP proxy is used to select amongst a set of use. This is the case when an RTSP proxy is used to select amongst a
RTSP servers to handle the requests, or when multiple server set of RTSP servers to handle the requests or when multiple server
addresses are available for a given server name. The proxy or client addresses are available for a given server name. The proxy or client
may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable) may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable)
from one of its RTSP servers or proxies, or a TCP timeout (if the from one of its RTSP servers or proxies, or a TCP timeout (if the
server is even unable to handle the request message). The proxy or server is even unable to handle the request message). The proxy or
client simply retries the other addresses or configured proxies, but client simply retries the other addresses or configured proxies, but
may also receive a 503 (Service Unavailable) or 553 (Proxy may also receive a 503 (Service Unavailable) or 553 (Proxy
Unavailable) response or TCP timeouts from those addresses. In such Unavailable) response or TCP timeouts from those addresses. In such
a situation, where none of the RTSP servers/proxies/addresses can a situation, where none of the RTSP servers/proxies/addresses can
handle the request, the RTSP agent has to wait before it can send any handle the request, the RTSP agent has to wait before it can send any
new requests to the RTSP server. Any additional request to a new requests to the RTSP server. Any additional request to a
specific address MUST be delayed according to the Retry-After headers specific address MUST be delayed according to the Retry-After headers
received. For addresses where no response was received or TCP received. For addresses where no response was received or TCP
timeout occurred, an initial wait timer SHOULD be set to 5 seconds. timeout occurred, an initial wait timer SHOULD be set to 5 seconds.
That timer MUST be doubled for each additional failure to connect or That timer MUST be doubled for each additional failure to connect or
receive response until the value exceeds 30 minutes when the timers receive response until the value exceeds 30 minutes when the timers
mean value may be set to 30 minutes. It is REQUIRED to not set the mean value may be set to 30 minutes. It is REQUIRED to not set the
same value in the timer for each scheduling, but instead to add a same value in the timer for each scheduling, but instead to add a
variation to the mean value, resulting in picking a random value variation to the mean value, resulting in picking a random value
within the range from 0.5 to 1.5 of the mean value. within the range from 0.5 to 1.5 times the mean value.
11. Capability Handling 11. Capability Handling
This section describes the available capability handling mechanism This section describes the available capability handling mechanism
which allows RTSP to be extended. Extensions to this version of the which allows RTSP to be extended. Extensions to this version of the
protocol are basically done in two ways. First, new headers can be protocol are basically done in two ways. First, new headers can be
added. Secondly, new methods can be added. The capability handling added. Secondly, new methods can be added. The capability handling
mechanism is designed to handle both cases. mechanism is designed to handle both cases.
When a method is added, the involved parties can use the OPTIONS When a method is added, the involved parties can use the OPTIONS
skipping to change at page 82, line 7 skipping to change at page 82, line 7
session. The client SHOULD immediately return a response to the session. The client SHOULD immediately return a response to the
server. server.
PLAY_NOTIFY requests MAY use both aggregate control URI and PLAY_NOTIFY requests MAY use both aggregate control URI and
individual media resource URIs depending on the scope of the individual media resource URIs depending on the scope of the
notification. This scope may have important distinctions for notification. This scope may have important distinctions for
aggregated sessions, and each reason for a PLAY_NOTIFY request needs aggregated sessions, and each reason for a PLAY_NOTIFY request needs
to specify the interpretation and if aggregated control URIs or to specify the interpretation and if aggregated control URIs or
individual URIs may be used in requests. individual URIs may be used in requests.
PLAY_NOTIFY requests MAY be used with a message body, depending on PLAY_NOTIFY requests can be used with a message body, depending on
the value of the Notify-Reason header. It is described in the the value of the Notify-Reason header. It is described in the
particular section for each Notify-Reason if a message body is used. particular section for each Notify-Reason if a message body is used.
However, currently there is no Notify-Reason that allows using a However, currently there is no Notify-Reason that allows using a
message body. In this case, there is a need to obey some limitations message body. In this case, there is a need to obey some limitations
when adding new Notify-Reasons that intend to use a message body: the when adding new Notify-Reasons that intend to use a message body: the
server can send any type of message body, but it is not ensured that server can send any type of message body, but it is not ensured that
the client can understand the received message body. This is related the client can understand the received message body. This is related
to DESCRIBE (see Section 13.2 ), but in this particular case the to DESCRIBE (see Section 13.2 ), but in this particular case the
client can state its acceptable message bodies by using the Accept client can state its acceptable message bodies by using the Accept
header. In the case of PLAY_NOTIFY, the server does not know which header. In the case of PLAY_NOTIFY, the server does not know which
skipping to change at page 101, line 23 skipping to change at page 101, line 23
usage. usage.
15.1. Proxies and Protocol Extensions 15.1. Proxies and Protocol Extensions
The existence of proxies must always be considered when developing The existence of proxies must always be considered when developing
new RTSP extensions. Most types of proxies will need to implement new RTSP extensions. Most types of proxies will need to implement
any new method to operate correctly in the presence of that any new method to operate correctly in the presence of that
extension. New headers can be introduced and will not be blocked by extension. New headers can be introduced and will not be blocked by
older proxies. However, it is important to consider if this header older proxies. However, it is important to consider if this header
and its function is required to be understood by the proxy or can be and its function is required to be understood by the proxy or can be
forwarded. If the header needs to be understood, a feature-tag simply forwarded. If the header needs to be understood, a feature-
representing the functionality MUST be included in the Proxy-Require tag representing the functionality MUST be included in the Proxy-
header. Below are guidelines for analysis if the header needs to be Require header. Below are guidelines for analysis whether the header
understood. The transport header and its parameters also shows that needs to be understood. The transport header and its parameters are
headers that are extensible and require correct interpretation in the extensible which on the other hand requires handling rules for a
proxy also require handling rules. proxy in order to ensure a correct interpretation.
Whether a proxy needs to understand a header is not easy to Whether a proxy needs to understand a header is not easy to
determine, as they serve a broad variety of functions. When determine, as they serve a broad variety of functions. When
evaluating if a header needs to be understood, one can divide the evaluating if a header needs to be understood, one can divide the
functionality into three main categories: functionality into three main categories:
Media modifying: The caching and translator proxies are modifying Media modifying: The caching and translator proxies are modifying
the actual media and therefore need to understand also the request the actual media and therefore need to understand also the request
directed to the server that affects how the media is rendered. directed to the server that affects how the media is rendered.
Thus, this type of proxy needs to also understand the server side Thus, this type of proxy needs to also understand the server side
functionality. functionality.
Transport modifying: The access and the security proxy both need to Transport modifying: The access and the security proxy both need to
understand how the transport is performed, either for opening understand how the media transport is performed, either for
pinholes or to translate the outer headers, e.g., IP and UDP. opening pinholes or to translate the outer headers, e.g., IP and
UDP or TCP.
Non-modifying: The audit proxy is special in that it does not modify Non-modifying: The audit proxy is special in that it does not modify
the messages in other ways than to insert the Via header. That the messages in other ways than to insert the Via header. That
makes it possible for this type to forward RTSP messages that makes it possible for this type to forward RTSP messages that
contain different types of unknown methods, headers or header contain different types of unknown methods, headers or header
parameters. parameters.
Based on the above classification, one should evaluate if the new Based on the above classification, one should evaluate if the new
functionality requires the Transport modifying type of proxies to functionality requires the Transport modifying type of proxies to
understand it or not. understand it or not.
skipping to change at page 104, line 32 skipping to change at page 104, line 32
Media streams that are being adapted based on the transport capacity Media streams that are being adapted based on the transport capacity
between the server and the cache makes caching more difficult. A between the server and the cache makes caching more difficult. A
server needs to consider how it views caching of media streams that server needs to consider how it views caching of media streams that
it adapts and potentially instruct any caches to not cache such it adapts and potentially instruct any caches to not cache such
streams. streams.
16.1.1. Last-Modified Dates 16.1.1. Last-Modified Dates
The Last-Modified header (Section 18.27) value is often used as a The Last-Modified header (Section 18.27) value is often used as a
cache validator. In simple terms, a cache entry is considered to be cache validator. In simple terms, a cache entry is considered to be
valid if the content has not been modified since the Last-Modified valid if the cache entry was created after the Last-Modified time.
value.
16.1.2. Message Body Tag Cache Validators 16.1.2. Message Body Tag Cache Validators
The MTag response-header field value, a message body tag, provides The MTag response-header field value, a message body tag, provides
for an "opaque" cache validator. This might allow more reliable for an "opaque" cache validator. This might allow more reliable
validation in situations where it is inconvenient to store validation in situations where it is inconvenient to store
modification dates, where the one-second resolution of RTSP-date modification dates, where the one-second resolution of RTSP-date
values is not sufficient, or where the origin server wishes to avoid values is not sufficient, or where the origin server wishes to avoid
certain paradoxes that might arise from the use of modification certain paradoxes that might arise from the use of modification
dates. dates.
skipping to change at page 236, line 8 skipping to change at page 236, line 8
23.1. Normative References 23.1. Normative References
[FIPS-pub-180-2] [FIPS-pub-180-2]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Federal Information Processing Standards Publications "Federal Information Processing Standards Publications
(FIPS PUBS) 180-2: Secure Hash Standard", August 2002. (FIPS PUBS) 180-2: Secure Hash Standard", August 2002.
[I-D.ietf-avtcore-rtp-circuit-breakers] [I-D.ietf-avtcore-rtp-circuit-breakers]
Perkins, C. and V. Singh, "Multimedia Congestion Control: Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", draft-ietf- Circuit Breakers for Unicast RTP Sessions", draft-ietf-
avtcore-rtp-circuit-breakers-03 (work in progress), July avtcore-rtp-circuit-breakers-04 (work in progress),
2013. January 2014.
[I-D.ietf-mmusic-rtsp-nat] [I-D.ietf-mmusic-rtsp-nat]
Goldberg, J., Westerlund, M., and T. Zeng, "A Network Goldberg, J., Westerlund, M., and T. Zeng, "A Network
Address Translator (NAT) Traversal mechanism for media Address Translator (NAT) Traversal Mechanism for Media
controlled by Real-Time Streaming Protocol (RTSP)", draft- Controlled by Real-Time Streaming Protocol (RTSP)", draft-
ietf-mmusic-rtsp-nat-17 (work in progress), November 2013. ietf-mmusic-rtsp-nat-20 (work in progress), February 2014.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 28 change blocks. 
51 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/