draft-ietf-mmusic-rfc2326bis-25.txt   draft-ietf-mmusic-rfc2326bis-26.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: April 28, 2011 R. Lanphier Expires: May 21, 2011 R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
October 25, 2010 November 17, 2010
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-25 draft-ietf-mmusic-rfc2326bis-26
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 which is defined in RFC 2326. 1.0 which is defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level The Real Time Streaming Protocol, or RTSP, is an application-level
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 47 skipping to change at page 1, line 47
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 April 28, 2011. This Internet-Draft will expire on May 21, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 11, line 22 skipping to change at page 11, line 22
"network remote control" for multimedia servers, similar to the "network remote control" for multimedia servers, similar to the
remote control for a DVD player. remote control for a DVD player.
The protocol operates between RTSP 2.0 clients and servers, but also The protocol operates between RTSP 2.0 clients and servers, but also
supports the usage of proxies placed between clients and servers. supports the usage of proxies placed between clients and servers.
Clients can request information about streaming media from servers by Clients can request information about streaming media from servers by
asking for a description of the media or use media description asking for a description of the media or use media description
provided externally. The media delivery protocol is used to provided externally. The media delivery protocol is used to
establish the media streams described by the media description. establish the media streams described by the media description.
Clients can then request to play out the media, pause it, or stop it Clients can then request to play out the media, pause it, or stop it
completely, as known from a regular DVD player remote control. The completely, as known from DVD players remote control or media
requested media can consist of multiple audio and video streams that players. The requested media can consist of multiple audio and video
are delivered as a time-synchronized streams from servers to clients. streams that are delivered as a time-synchronized streams from
servers to clients.
RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] that obsoletes that RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] that obsoletes that
specification. This protocol is based on RTSP 1.0 but is not specification. This protocol is based on RTSP 1.0 but is not
backwards compatible other than in the basic version negotiation backwards compatible other than in the basic version negotiation
mechanism. The changes are documented in Appendix J. There are many mechanism. The changes are documented in Appendix J. There are many
reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but
some of the main ones are: some of the main ones are:
o Most headers that needed to be extensible did not define the o Most headers that needed to be extensible did not define the
allowed syntax, preventing safe deployment of extensions; allowed syntax, preventing safe deployment of extensions;
skipping to change at page 13, line 16 skipping to change at page 13, line 16
This section provides a informative overview of the different This section provides a informative overview of the different
mechanisms in the RTSP 2.0 protocol, to give the reader a high level mechanisms in the RTSP 2.0 protocol, to give the reader a high level
understanding before getting into all the different details. In case understanding before getting into all the different details. In case
of conflict with this description and the later sections, the later of conflict with this description and the later sections, the later
sections take precedence. For more information about considered use sections take precedence. For more information about considered use
cases for RTSP see Appendix E. cases for RTSP see Appendix E.
RTSP 2.0 is a bi-directional request and response protocol that first RTSP 2.0 is a bi-directional request and response protocol that first
establishes a context including content resources (the media) and establishes a context including content resources (the media) and
then controls the delivery of these content resources from the server then controls the delivery of these content resources from the
to the client. RTSP has three fundamental parts: Session provider to the consumer. RTSP has three fundamental parts: Session
Establishment, Media Delivery Control, and an extensibility model Establishment, Media Delivery Control, and an extensibility model
described below. The protocol is based on some assumptions about described below. The protocol is based on some assumptions about
existing functionality to provide a complete solution for client existing functionality to provide a complete solution for client
controlled real-time media delivery. controlled real-time media delivery.
RTSP uses text-based messages, requests and responses, that may RTSP uses text-based messages, requests and responses, that may
contain a binary message body. An RTSP request starts with a method contain a binary message body. An RTSP request starts with a method
line that identifies the method, the protocol and version and the line that identifies the method, the protocol and version and the
resource to act on. Following the method line are a number of RTSP resource to act on. Following the method line are a number of RTSP
headers. This part is ended by two consecutive carriage return line headers. This part is ended by two consecutive carriage return line
skipping to change at page 35, line 31 skipping to change at page 35, line 31
Requests contain methods, the object the method is operating upon and Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent parameters to further describe the method. Methods are idempotent
unless otherwise noted. Methods are also designed to require little unless otherwise noted. Methods are also designed to require little
or no state maintenance at the media server. or no state maintenance at the media server.
5.1. Message Types 5.1. Message Types
RTSP messages consist of requests from client to server, or server to RTSP messages consist of requests from client to server, or server to
client, and responses in the reverse direction. Request Section 7 client, and responses in the reverse direction. Request Section 7
and Response Section 8 messages use a format based on the generic and Response Section 8 messages use a format based on the generic
message format of RFC 0822 [RFC0822] for transferring bodies (the message format of RFC 2822 [RFC2822] for transferring bodies (the
payload of the message). Both types of message consist of a start- payload of the message). Both types of message consist of a start-
line, zero or more header fields (also known as "headers"), an empty line, zero or more header fields (also known as "headers"), an empty
line (i.e., a line with nothing preceding the CRLF) indicating the line (i.e., a line with nothing preceding the CRLF) indicating the
end of the header, and possibly the data of the message-body. end of the header, and possibly the data of the message-body.
generic-message = start-line generic-message = start-line
*(message-header CRLF) *(message-header CRLF)
CRLF CRLF
[ message-body-data ] [ message-body-data ]
start-line = Request-Line | Status-Line start-line = Request-Line | Status-Line
skipping to change at page 64, line 14 skipping to change at page 64, line 14
By forcing a DESCRIBE response to contain all media initialization By forcing a DESCRIBE response to contain all media initialization
for the set of streams that it describes, and discouraging the use for the set of streams that it describes, and discouraging the use
of DESCRIBE for media indirection, any looping problems can be of DESCRIBE for media indirection, any looping problems can be
avoided that might have resulted from other approaches. avoided that might have resulted from other approaches.
Example: Example:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312 CSeq: 312
User-Agent: PhonyClient 1.2 User-Agent: PhonyClient/1.2
Accept: application/sdp, application/example Accept: application/sdp, application/example
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 312 CSeq: 312
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.1 Server: PhonyServer/1.1
Content-Base: rtsp://server.example.com/fizzle/foo/ Content-Base: rtsp://server.example.com/fizzle/foo/
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 358 Content-Length: 358
skipping to change at page 74, line 43 skipping to change at page 74, line 43
A total replacement is signaled by having the first range A total replacement is signaled by having the first range
specification have an explicit start value, e.g. npt=45- or specification have an explicit start value, e.g. npt=45- or
npt=45-60, in which case the server stops playout at the current npt=45-60, in which case the server stops playout at the current
playout point and then starts delivering media according to the Range playout point and then starts delivering media according to the Range
header. This is equivalent to having the client first send a PAUSE header. This is equivalent to having the client first send a PAUSE
and then a new play request that isn't based on the pause point. In and then a new play request that isn't based on the pause point. In
the case of continuation the first range specifier has an implicit the case of continuation the first range specifier has an implicit
start point and a explicit stop value (Z), e.g. npt=-60, which start point and a explicit stop value (Z), e.g. npt=-60, which
indicate that it MUST convert the range specifier being played prior indicate that it MUST convert the range specifier being played prior
to this PLAY request (X to Y) into (X to Z) and continue as this was to this PLAY request (X to Y) into (X to Z) and continue as this was
the request originally played. If the stop point is beyond the the request originally played. If the current delivery point is
current delivery point, the server SHALL immediately pause delivery. beyond the stop point, the server SHALL immediately pause delivery.
As the request has been completed successfully it shall be responded As the request has been completed successfully it shall be responded
with 200 OK. A PLAY-NOTIFY with end-of-stream is also sent to with 200 OK. A PLAY_NOTIFY with end-of-stream is also sent to
indicate the actual stop point. The pause point is set to the indicate the actual stop point. The pause point is set to the
requested stop point. requested stop point.
Following is an example of this behavior: The server has received Following is an example of this behavior: The server has received
requests to play ranges 10 to 15. If the new PLAY request arrives at requests to play ranges 10 to 15. If the new PLAY request arrives at
the server 4 seconds after the previous one, it will take effect the server 4 seconds after the previous one, it will take effect
while the server still plays the first range (10-15). The server while the server still plays the first range (10-15). The server
changes the current play to continue to 25 seconds, i.e. the changes the current play to continue to 25 seconds, i.e. the
equivalent single request would be PLAY with range: npt=10-25. equivalent single request would be PLAY with range: npt=10-25.
skipping to change at page 200, line 14 skipping to change at page 200, line 14
Location Headers and Spoofing: If a single server supports multiple Location Headers and Spoofing: If a single server supports multiple
organizations that do not trust each another, then it needs to organizations that do not trust each another, then it needs to
check the values of Location and Content-Location header fields check the values of Location and Content-Location header fields
in responses that are generated under control of said in responses that are generated under control of said
organizations to make sure that they do not attempt to organizations to make sure that they do not attempt to
invalidate resources over which they have no authority. invalidate resources over which they have no authority.
([H15.4]) ([H15.4])
In addition to the recommendations in the current HTTP specification In addition to the recommendations in the current HTTP specification
(RFC 2616 [RFC2616], as of this writing) and also of the previous (RFC 2616 [RFC2616], as of this writing) and also of the previous RFC
RFC2068 [RFC2068], future HTTP specifications may provide additional 2068 [RFC2068], future HTTP specifications may provide additional
guidance on security issues. guidance on security issues.
The following are added considerations for RTSP implementations. The following are added considerations for RTSP implementations.
Concentrated denial-of-service attack: The protocol offers the Concentrated denial-of-service attack: The protocol offers the
opportunity for a remote-controlled denial-of-service attack. opportunity for a remote-controlled denial-of-service attack.
See Section 21.1. See Section 21.1.
Session hijacking: Since there is no or little relation between a Session hijacking: Since there is no or little relation between a
transport layer connection and an RTSP session, it is possible transport layer connection and an RTSP session, it is possible
skipping to change at page 225, line 11 skipping to change at page 225, line 11
pictures and associated audio information - part 6: pictures and associated audio information - part 6:
Extension for digital storage media and control", Extension for digital storage media and control",
ISO Draft Standard 13818-6, November 1995. ISO Draft Standard 13818-6, November 1995.
[ISO.8601.2000] [ISO.8601.2000]
International Organization for Standardization, "Data International Organization for Standardization, "Data
elements and interchange formats - Information interchange elements and interchange formats - Information interchange
- Representation of dates and times", ISO/IEC Standard - Representation of dates and times", ISO/IEC Standard
8601, December 2000. 8601, December 2000.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions
Functional Specification", RFC 1644, July 1994. Functional Specification", RFC 1644, July 1994.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997. RFC 2068, January 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999. RFC 2663, August 1999.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
skipping to change at page 251, line 26 skipping to change at page 251, line 26
The usage of SRTP requires that a security context is established. The usage of SRTP requires that a security context is established.
The default key-management unless otherwise signalled shall be MIKEY The default key-management unless otherwise signalled shall be MIKEY
in RSA-R mode as defined in Appendix C.1.4.1, and not according to in RSA-R mode as defined in Appendix C.1.4.1, and not according to
the procedure defined in "Key Management Extensions for Session the procedure defined in "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)" Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)"
[RFC4567]. The reason is that RFC 4567 sends the initial MIKEY [RFC4567]. The reason is that RFC 4567 sends the initial MIKEY
message in SDP, thus both requiring the usage of the DESCRIBE method message in SDP, thus both requiring the usage of the DESCRIBE method
and forcing the server to keep state for client performing DESCRIBE and forcing the server to keep state for client performing DESCRIBE
in anticipation that they might require key management. in anticipation that they might require key management.
MIKEY is selected as default method for establishing security MIKEY is selected as default method for establishing SRTP
association within an RTSP session as it can be embedded in the RTSP cryptographic context within an RTSP session as it can be embedded in
messages, while still ensuring confidentiality of content of the the RTSP messages, while still ensuring confidentiality of content of
keying material, even when using hop-by-hop TLS security for the RTSP the keying material, even when using hop-by-hop TLS security for the
messages. This method does also support pipelining of the RTSP RTSP messages. This method does also support pipelining of the RTSP
messages. messages.
C.1.4.1. MIKEY Key Establishment C.1.4.1. MIKEY Key Establishment
This method for using MIKEY to establish the security context for This method for using MIKEY to establish the SRTP cryptographic
SRTP is initiated in the client's SETUP request, and the servers context is initiated in the client's SETUP request, and the servers
response to the SETUP carries the MIKEY response. Thus ensuring that response to the SETUP carries the MIKEY response. Thus ensuring that
the Security context establishment happens simultaneously with the the crypto context establishment happens simultaneously with the
establishment of the media stream being protected. By using MIKEY's establishment of the media stream being protected. By using MIKEY's
RSA-R mode [RFC4738] the client can be initiator and still allow the RSA-R mode [RFC4738] the client can be initiator and still allow the
server to set the parameters in accordance with the actual media server to set the parameters in accordance with the actual media
stream. stream.
The Security Context Establishment is done according to the following The SRTP cryptographic context establishment is done according to the
process: following process:
1. The client determines that SAVP or SAVPF shall be used from 1. The client determines that SAVP or SAVPF shall be used from
media description format, e.g. SDP. If no other key management media description format, e.g. SDP. If no other key management
method is explicitly signalled, then MIKEY SHALL be used as method is explicitly signalled, then MIKEY SHALL be used as
defined here in. This specification does not specify an defined here in. This specification does not specify an
explicit method for indicating this security context explicit method for indicating this SRTP cryptographic context
establishment method, but future specifications may. establishment method, but future specifications may.
2. The client SHALL establish a TLS connection for RTSP messages, 2. The client SHALL establish a TLS connection for RTSP messages,
directly or hop by hop with the server. If hop-by-hop TLS directly or hop by hop with the server. If hop-by-hop TLS
security is used, the User method SHALL be indicated in the security is used, the User method SHALL be indicated in the
Accept-Credentials header. We do note that using hop-by-hop Accept-Credentials header. We do note that using hop-by-hop
does allow the proxy to insert itself as a man in the middle does allow the proxy to insert itself as a man in the middle
also in the MIKEY exchange by providing one of its certificates, also in the MIKEY exchange by providing one of its certificates,
rather than the server's in the Connection-Credentials header. rather than the server's in the Connection-Credentials header.
The client shall therefore validate the server certificate. The client shall therefore validate the server certificate.
skipping to change at page 252, line 34 skipping to change at page 252, line 34
included in the MIKEY message. The client SHALL indicate its included in the MIKEY message. The client SHALL indicate its
SRTP capabilities in the message. SRTP capabilities in the message.
5. The MIKEY message from the previous step is base64 [RFC4648] 5. The MIKEY message from the previous step is base64 [RFC4648]
encoded and becomes the value of the MIKEY parameter that are encoded and becomes the value of the MIKEY parameter that are
included in the transport specification(s) that specifies a SRTP included in the transport specification(s) that specifies a SRTP
based profile (SAVP, SAVPF) in the SETUP request. based profile (SAVP, SAVPF) in the SETUP request.
6. Any proxy encountering the MIKEY parameter SHALL forward it 6. Any proxy encountering the MIKEY parameter SHALL forward it
without modification. A proxy requiring to understand transport without modification. A proxy requiring to understand transport
specificaation which doesn't support SAVP/SAVPF with MIKEY will specification which doesn't support SAVP/SAVPF with MIKEY will
discard the whole transport specification. Most types of proxy discard the whole transport specification. Most types of proxy
can easily support SAVP and SAVPF with MIKEY. If possible can easily support SAVP and SAVPF with MIKEY. If possible
bypassing the proxy should be tried. bypassing the proxy should be tried.
7. The server upon receiving the SETUP request, while need to 7. The server upon receiving the SETUP request, will need to decide
decide upon the transport specification to use, if multiple are upon the transport specification to use, if multiple are
included by the client. In the determination of which transport included by the client. In the determination of which transport
specifications that are supported and preferred, the server specifications that are supported and preferred, the server
should decode the MIKEY message to take the embedded SRTP should decode the MIKEY message to take the embedded SRTP
parameters into account. If all transport specs require SRTP parameters into account. If all transport specs require SRTP
but no MIKEY parameter or other supported keying method is but no MIKEY parameter or other supported keying method is
included, the server shall respond with 403. included, the server shall respond with 403.
8. Upon generating a response the following outcomes can occur: 8. Upon generating a response the following outcomes can occur:
* A transport spec not using SRTP and MIKEY is selected. Thus * A transport spec not using SRTP and MIKEY is selected. Thus
skipping to change at page 253, line 28 skipping to change at page 253, line 28
client. That message is included in the MIKEY parameter part client. That message is included in the MIKEY parameter part
of the single selected transport specification in the SETUP of the single selected transport specification in the SETUP
response. The server will set the SRTP parameters as response. The server will set the SRTP parameters as
preferred for this media stream within the supported range by preferred for this media stream within the supported range by
the client. the client.
9. The server transmits the SETUP response back to the client. 9. The server transmits the SETUP response back to the client.
10. The client receives the SETUP response and if the response code 10. The client receives the SETUP response and if the response code
indicates a successful request it decodes the MIKEY message and indicates a successful request it decodes the MIKEY message and
establish the security context from the parameters in the MIKEY establish the SRTP cryptographic context from the parameters in
response. the MIKEY response.
In the above method the client's certificate may be self-signed in In the above method the client's certificate may be self-signed in
cases where the client's identify is not necessary to establish and cases where the client's identify is not necessary to establish and
the security goal is only to ensure that the RTSP signalling client the security goal is only to ensure that the RTSP signalling client
is the same as the one receiving the SRTP security context. is the same as the one receiving the SRTP security context.
C.1.5. SAVPF/UDP C.1.5. SAVPF/UDP
The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback
(RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in (RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in
RTSP sessions using RTP. All that is defined for AVP MUST also apply RTSP sessions using RTP. All that is defined for AVP MUST also apply
for SAVPF. for SAVPF.
The usage of SRTP requires that a security association is The usage of SRTP requires that a cryptographic context is
established. The default mechanism for establishing that security established. The default mechanism for establishing that security
association is to use MIKEY[RFC3830] with RTSP as defined association is to use MIKEY[RFC3830] with RTSP as defined
Appendix C.1.4.1. Appendix C.1.4.1.
C.1.6. RTCP usage with RTSP C.1.6. RTCP usage with RTSP
RTCP has several usages when RTP is used for media transport as RTCP has several usages when RTP is used for media transport as
explained below. Due to that RTCP MUST be supported if an RTSP agent explained below. Due to that RTCP MUST be supported if an RTSP agent
handles RTP. handles RTP.
skipping to change at page 282, line 9 skipping to change at page 282, line 9
o Source authentication, or at least validation that RTSP messages o Source authentication, or at least validation that RTSP messages
comes from the same entity becomes extremely important, as session comes from the same entity becomes extremely important, as session
hijacking may be substantially easier for RTSP message transport hijacking may be substantially easier for RTSP message transport
using an unreliable protocol like UDP than for TCP. using an unreliable protocol like UDP than for TCP.
There exist two RTSP headers thats primarily are intended for being There exist two RTSP headers thats primarily are intended for being
used by the unreliable handling of RTSP messages and which will be used by the unreliable handling of RTSP messages and which will be
maintained: maintained:
o [CSeq] See Section 16.19 o CSeq: See Section 16.19
o [Timestamp] See Section 16.51 o Timestamp: See Section 16.51
Appendix H. Backwards Compatibility Considerations Appendix H. Backwards Compatibility Considerations
This section contains notes on issues about backwards compatibility This section contains notes on issues about backwards compatibility
with clients or servers being implemented according to RFC 2326 with clients or servers being implemented according to RFC 2326
[RFC2326]. Note that there exists no requirement to implement RTSP [RFC2326]. Note that there exists no requirement to implement RTSP
1.0, in fact we recommend against it as it is difficult to do in an 1.0, in fact we recommend against it as it is difficult to do in an
interoperable way. interoperable way.
A server implementing RTSP/2.0 MUST include a RTSP-Version of A server implementing RTSP/2.0 MUST include a RTSP-Version of
 End of changes. 24 change blocks. 
38 lines changed or deleted 39 lines changed or added

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