draft-ietf-mmusic-rtsp-06.txt   draft-ietf-mmusic-rtsp-07.txt 
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
Internet Draft H. Schulzrinne, A. Rao, R. Lanphier Internet Draft H. Schulzrinne, A. Rao, R. Lanphier
draft-ietf-mmusic-rtsp-06.txt Columbia U./Netscape/RealNetworks draft-ietf-mmusic-rtsp-07.txt Columbia U./Netscape/RealNetworks
November 21, 1997 Expires: May 21, 1998 January 7, 1998 Expires: July 7, 1998
Real Time Streaming Protocol (RTSP) Real Time Streaming Protocol (RTSP)
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at line 767 skipping to change at line 767
parameters from multimedia conferences the media server is parameters from multimedia conferences the media server is
participating in. These conferences are created by protocols participating in. These conferences are created by protocols
outside the scope of this specification, e.g., H.323 [17] or SIP outside the scope of this specification, e.g., H.323 [17] or SIP
[10]. Instead of the RTSP client explicitly providing transport [10]. Instead of the RTSP client explicitly providing transport
information, for example, it asks the media server to use the information, for example, it asks the media server to use the
values in the conference description instead. values in the conference description instead.
3.4 Session Identifiers 3.4 Session Identifiers
Session identifiers are opaque strings of arbitrary length. Linear Session identifiers are opaque strings of arbitrary length. Linear
white space must be URL-escaped. A session identifier SHOULD be chosen white space must be URL-escaped. A session identifier MUST be chosen
randomly and SHOULD be at least eight octets long to make guessing it randomly and MUST be at least eight octets long to make guessing it
more difficult. (See Section 16.) more difficult. (See Section 16.)
session-id = 1*( ALPHA | DIGIT | safe ) session-id = 1*( ALPHA | DIGIT | safe )
3.5 SMPTE Relative Timestamps 3.5 SMPTE Relative Timestamps
A SMPTE relative timestamp expresses time relative to the start of A SMPTE relative timestamp expresses time relative to the start of
the clip. Relative timestamps are expressed as SMPTE time codes for the clip. Relative timestamps are expressed as SMPTE time codes for
frame-level access accuracy. The time code has the format frame-level access accuracy. The time code has the format
hours:minutes:seconds:frames.subframes, with the origin at the start hours:minutes:seconds:frames.subframes, with the origin at the start
skipping to change at line 791 skipping to change at line 791
supported (such as "SMPTE 25") through the use of alternative use of supported (such as "SMPTE 25") through the use of alternative use of
"smpte time". For the ``frames'' field in the time value can assume "smpte time". For the ``frames'' field in the time value can assume
the values 0 through 29. The difference between 30 and 29.97 frames the values 0 through 29. The difference between 30 and 29.97 frames
per second is handled by dropping the first two frame indices (values per second is handled by dropping the first two frame indices (values
00 and 01) of every minute, except every tenth minute. If the frame 00 and 01) of every minute, except every tenth minute. If the frame
value is zero, it may be omitted. Subframes are measured in value is zero, it may be omitted. Subframes are measured in
one-hundredth of a frame. one-hundredth of a frame.
smpte-range = smpte-type "=" smpte-time "-" [ smpte-time ] smpte-range = smpte-type "=" smpte-time "-" [ smpte-time ]
smpte-type = "smpte" | "smpte-30-drop" | "smpte-25" smpte-type = "smpte" | "smpte-30-drop" | "smpte-25"
; Other timecodes may be added ; other timecodes may be added
smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ] smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ]
[ "." 1*2DIGIT ] [ "." 1*2DIGIT ]
Examples: Examples:
smpte=10:12:33:20- smpte=10:12:33:20-
smpte=10:07:33- smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01 smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01 smpte-25=10:07:00-10:07:33:05.01
3.6 Normal Play Time 3.6 Normal Play Time
skipping to change at line 831 skipping to change at line 831
npt-range = ( npt-time "-" [ npt-time ] ) | ( "-" npt-time ) npt-range = ( npt-time "-" [ npt-time ] ) | ( "-" npt-time )
npt-time = "now" | npt-sec | npt-hhmmss npt-time = "now" | npt-sec | npt-hhmmss
npt-sec = 1*DIGIT [ "." *DIGIT ] npt-sec = 1*DIGIT [ "." *DIGIT ]
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]
npt-hh = 1*DIGIT ; any positive number npt-hh = 1*DIGIT ; any positive number
npt-mm = 1*2DIGIT ; 0-59 npt-mm = 1*2DIGIT ; 0-59
npt-ss = 1*2DIGIT ; 0-59 npt-ss = 1*2DIGIT ; 0-59
Examples: Examples:
npt=123.45-125 npt=123.45-125
npt=12:05:35.3 npt=12:05:35.3-
npt=now npt=now-
The syntax conforms to ISO 8601. The npt-sec notation is optimized The syntax conforms to ISO 8601. The npt-sec notation is optimized
for automatic generation, the ntp-hhmmss notation for consumption for automatic generation, the ntp-hhmmss notation for consumption
by human readers. The ``now'' constant allows clients to request to by human readers. The ``now'' constant allows clients to request to
receive the live feed rather than the stored or time-delayed receive the live feed rather than the stored or time-delayed
version. This is needed since neither absolute time nor zero time version. This is needed since neither absolute time nor zero time
are appropriate for this case. are appropriate for this case.
3.7 Absolute Time 3.7 Absolute Time
skipping to change at line 1528 skipping to change at line 1528
transport parameters selected by the server. transport parameters selected by the server.
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302 CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589 Transport: RTP/AVP;unicast;client_port=4588-4589
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
CSeq: 302 CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Session: 4711 Session: 4711
Transport: RTP/AVP;unicast;client_port=4588-4589 Transport: RTP/AVP;unicast;
;server_port=6256-6257 client_port=4588-4589;server_port=6256-6257
10.5 PLAY 10.5 PLAY
The PLAY method tells the server to start sending data via the The PLAY method tells the server to start sending data via the
mechanism specified in SETUP. A client MUST NOT issue a PLAY request mechanism specified in SETUP. A client MUST NOT issue a PLAY request
until any outstanding SETUP requests have been acknowledged as until any outstanding SETUP requests have been acknowledged as
successful. successful.
The PLAY request positions the normal play time to the beginning of The PLAY request positions the normal play time to the beginning of
the range specified and delivers stream data until the end of the the range specified and delivers stream data until the end of the
skipping to change at line 1855 skipping to change at line 1854
Session: 12345 Session: 12345
C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0 C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0
CSeq: 3 CSeq: 3
Session: 12345 Session: 12345
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
CSeq: 3 CSeq: 3
Session: 12345 Session: 12345
Date: 05 Jun 1997 18:59:15 GMT Date: 05 Jun 1997 18:59:15 GMT
RTP-Info: url=rtsp://foo.com/bar.file;seq=232433;rtptime=972948234 RTP-Info: url=rtsp://foo.com/bar.file;
seq=232433;rtptime=972948234
S->C: $\000{2 byte length}{"length" bytes data, w/RTP header} S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\000{2 byte length}{"length" bytes data, w/RTP header} S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\001{2 byte length}{"length" bytes RTCP packet} S->C: $\001{2 byte length}{"length" bytes RTCP packet}
11 Status Code Definitions 11 Status Code Definitions
Where applicable, HTTP status [H10] codes are reused. Status codes Where applicable, HTTP status [H10] codes are reused. Status codes
that have the same meaning are not repeated here. See Table 1 for a that have the same meaning are not repeated here. See Table 1 for a
listing of which status codes may be returned by which requests. listing of which status codes may be returned by which requests.
skipping to change at line 3074 skipping to change at line 3074
Content-length: 48 Content-length: 48
v=0 v=0
o=- 872653257 872653257 IN IP4 172.16.2.187 o=- 872653257 872653257 IN IP4 172.16.2.187
s=mu-law wave file s=mu-law wave file
i=audio test i=audio test
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control:streamid=0 a=control:streamid=0
C->S SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0 C->S SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=6970-6971;mode=play Transport: RTP/AVP/UDP;unicast;
client_port=6970-6971;mode=play
CSeq: 2 CSeq: 2
S->C RTSP/1.0 200 OK S->C RTSP/1.0 200 OK
Transport: RTP/AVP/UDP;unicast;client_port=6970-6971; Transport: RTP/AVP/UDP;unicast;client_port=6970-6971;
server_port=6970-6971;mode=play server_port=6970-6971;mode=play
CSeq: 2 CSeq: 2
Session: 2034820394 Session: 2034820394
C->S PLAY rtsp://foo.com/test.wav RTSP/1.0 C->S PLAY rtsp://foo.com/test.wav RTSP/1.0
CSeq: 3 CSeq: 3
skipping to change at line 3155 skipping to change at line 3155
s=RTSP Session s=RTSP Session
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
a=control:rtsp://live.example.com/concert/audio a=control:rtsp://live.example.com/concert/audio
c=IN IP4 224.2.0.1/16 c=IN IP4 224.2.0.1/16
C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0
CSeq: 2 CSeq: 2
Transport: RTP/AVP;multicast Transport: RTP/AVP;multicast
M->C: RTSP/1.0 200 OK M->C: RTSP/1.0 200 OK
CSeq: 2 CSeq: 2
Transport: RTP/AVP;multicast;destination=224.2.0.1;port=3456-3457; Transport: RTP/AVP;multicast;destination=224.2.0.1;
ttl=16 port=3456-3457;ttl=16
Session: 0456804596 Session: 0456804596
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0
CSeq: 3 CSeq: 3
Session: 0456804596 Session: 0456804596
M->C: RTSP/1.0 200 OK M->C: RTSP/1.0 200 OK
CSeq: 3 CSeq: 3
Session: 0456804596 Session: 0456804596
skipping to change at line 3242 skipping to change at line 3242
m=audio 21010 RTP/AVP 5 m=audio 21010 RTP/AVP 5
c=IN IP4 224.0.1.11/127 c=IN IP4 224.0.1.11/127
a=ptime:40 a=ptime:40
m=video 61010 RTP/AVP 31 m=video 61010 RTP/AVP 31
c=IN IP4 224.0.1.12/127 c=IN IP4 224.0.1.12/127
M->C: RTSP/1.0 200 OK M->C: RTSP/1.0 200 OK
CSeq: 90 CSeq: 90
C->M: SETUP rtsp://server.example.com/meeting/audiotrack RTSP/1.0 C->M: SETUP rtsp://server.example.com/meeting/audiotrack RTSP/1.0
CSeq: 91 CSeq: 91
Transport: RTP/AVP;mulicast;destination=224.0.1.11;port=21010-21011; Transport: RTP/AVP;multicast;destination=224.0.1.11;
mode=record;ttl=127 port=21010-21011;mode=record;ttl=127
M->C: RTSP/1.0 200 OK M->C: RTSP/1.0 200 OK
CSeq: 91 CSeq: 91
Session: 508876 Session: 508876
Transport: RTP/AVP;mulicast;destination=224.0.1.11;port=21010-21011; Transport: RTP/AVP;multicast;destination=224.0.1.11;
mode=record;ttl=127 port=21010-21011;mode=record;ttl=127
C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0 C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0
CSeq: 92 CSeq: 92
Session: 508876 Session: 508876
Transport: RTP/AVP;mulicast;destination=224.0.1.12;port=61010-61011; Transport: RTP/AVP;multicast;destination=224.0.1.12;
mode=record;ttl=127 port=61010-61011;mode=record;ttl=127
M->C: RTSP/1.0 200 OK M->C: RTSP/1.0 200 OK
CSeq: 92 CSeq: 92
Transport: RTP/AVP;mulicast;destination=224.0.1.12;port=61010-61011; Transport: RTP/AVP;multicast;destination=224.0.1.12;
mode=record;ttl=127 port=61010-61011;mode=record;ttl=127
C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0 C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0
CSeq: 93 CSeq: 93
Session: 508876 Session: 508876
Range: clock=19961110T1925-19961110T2015 Range: clock=19961110T1925-19961110T2015
M->C: RTSP/1.0 200 OK M->C: RTSP/1.0 200 OK
CSeq: 93 CSeq: 93
15 Syntax 15 Syntax
skipping to change at line 3428 skipping to change at line 3428
(RFC XXXX) SHOULD be used. (RFC XXXX) SHOULD be used.
Stream issues: Stream issues:
RTSP only provides for stream control. Stream delivery issues RTSP only provides for stream control. Stream delivery issues
are not covered in this section, nor in the rest of this draft. are not covered in this section, nor in the rest of this draft.
RTSP implementations will most likely rely on other protocols RTSP implementations will most likely rely on other protocols
such as RTP, IP Multicast, RSVP, and IGMP, and should address such as RTP, IP Multicast, RSVP, and IGMP, and should address
considerations brought up in these specifications (even when considerations brought up in these specifications (even when
non-standard equivalents are used in place of said protocols). non-standard equivalents are used in place of said protocols).
A RTSP Protocol State Machines Persistently suspicious behavior:
RTSP servers SHOULD return error code 403 (Forbidden) upon
receiving a single instance of behavior which is deemed a
security risk. RTSP servers SHOULD also be aware of attempts to
probe the server for weaknesses and entry points and MAY
arbitrarily disconnect and ignore further requests clients
which are deemed to be in violation of local security policy.
Appendix A: RTSP Protocol State Machines
The RTSP client and server state machines describe the behavior of The RTSP client and server state machines describe the behavior of
the protocol from RTSP session initialization through RTSP session the protocol from RTSP session initialization through RTSP session
termination. termination.
State is defined on a per object basis. An object is uniquely State is defined on a per object basis. An object is uniquely
identified by the stream URL and the RTSP session identifier. Any identified by the stream URL and the RTSP session identifier. Any
request/reply using aggregate URLs denoting RTSP presentations request/reply using aggregate URLs denoting RTSP presentations
composed of multiple streams will have an effect on the individual composed of multiple streams will have an effect on the individual
states of all the streams. For example, if the presentation /movie states of all the streams. For example, if the presentation /movie
skipping to change at line 3564 skipping to change at line 3571
RECORD Recording RECORD Recording
Playing PLAY Playing Playing PLAY Playing
PAUSE Ready PAUSE Ready
TEARDOWN Init TEARDOWN Init
SETUP Playing SETUP Playing
Recording RECORD Recording Recording RECORD Recording
PAUSE Ready PAUSE Ready
TEARDOWN Init TEARDOWN Init
SETUP Recording SETUP Recording
B Interaction with RTP Appendix B: Interaction with RTP
RTSP allows media clients to control selected, non-contiguous RTSP allows media clients to control selected, non-contiguous
sections of media presentations, rendering those streams with an RTP sections of media presentations, rendering those streams with an RTP
media layer[19]. The media layer rendering the RTP stream should not media layer[19]. The media layer rendering the RTP stream should not
be affected by jumps in NPT. Thus, both RTP sequence numbers and RTP be affected by jumps in NPT. Thus, both RTP sequence numbers and RTP
timestamps MUST be continuous and monotonic across jumps of NPT. timestamps MUST be continuous and monotonic across jumps of NPT.
As an example, assume a clock frequency of 8000 Hz, a packetization As an example, assume a clock frequency of 8000 Hz, a packetization
interval of 100 ms and an initial sequence number and timestamp of interval of 100 ms and an initial sequence number and timestamp of
zero. First we play NPT 10 through 15, then skip ahead and play NPT 18 zero. First we play NPT 10 through 15, then skip ahead and play NPT 18
skipping to change at line 3610 skipping to change at line 3617
frames/second at a scale of two and speed (Section 12.35) of one, the frames/second at a scale of two and speed (Section 12.35) of one, the
server would drop every second frame to maintain and deliver video server would drop every second frame to maintain and deliver video
packets with the normal timestamp spacing of 3,000 per frame, but NPT packets with the normal timestamp spacing of 3,000 per frame, but NPT
would increase by 1/15 second for each video frame. would increase by 1/15 second for each video frame.
The client can maintain a correct display of NPT by noting the RTP The client can maintain a correct display of NPT by noting the RTP
timestamp value of the first packet arriving after repositioning. The timestamp value of the first packet arriving after repositioning. The
sequence parameter of the RTP-Info (Section 12.33) header provides the sequence parameter of the RTP-Info (Section 12.33) header provides the
first sequence number of the next segment. first sequence number of the next segment.
C Use of SDP for RTSP Session Descriptions Appendix C: Use of SDP for RTSP Session Descriptions
The Session Description Protocol (SDP, RFC XXXX) may be used to The Session Description Protocol (SDP, RFC XXXX) may be used to
describe streams or presentations in RTSP. Such usage is limited to describe streams or presentations in RTSP. Such usage is limited to
specifying means of access and encoding(s) for: specifying means of access and encoding(s) for:
aggregate control: aggregate control:
A presentation composed of streams from one or more servers A presentation composed of streams from one or more servers
that are not available for aggregate control. Such a that are not available for aggregate control. Such a
description is typically retrieved by HTTP or other non-RTSP description is typically retrieved by HTTP or other non-RTSP
means. However, they may be received with ANNOUNCE methods. means. However, they may be received with ANNOUNCE methods.
skipping to change at line 3685 skipping to change at line 3692
Example: Example:
m=audio 0 RTP/AVP 31 m=audio 0 RTP/AVP 31
C.1.3 Payload type(s) C.1.3 Payload type(s)
The payload type(s) are specified in the ``m='' field. In case the The payload type(s) are specified in the ``m='' field. In case the
payload type is a static payload type from RFC 1890([1]), no other payload type is a static payload type from RFC 1890([1]), no other
information is required. In case it is a dynamic payload type, the information is required. In case it is a dynamic payload type, the
media attribute ``rtpmap'' is used to specify what the media is. The media attribute ``rtpmap'' is used to specify what the media is. The
``encoding name'' within the ``rtpmap'' attribute may be one of those ``encoding name'' within the ``rtpmap'' attribute may be one of those
specified in RFC 1890 (Sections 5 and 6), or an experimental encoding specified in RFC 1890 (Sections 5 and 6), or an experimental encoding
with a ``X-'' prefix as specified in RFC XXXX. Codec-specific with a ``X-'' prefix as specified in RFC XXXX (SDP). Codec-specific
parameters are not specified in this field, but rather in the ``fmtp'' parameters are not specified in this field, but rather in the ``fmtp''
attribute described below. Implementors seeking to register new attribute described below. Implementors seeking to register new
encodings should follow the procedure in RFC 1890. If the media type encodings should follow the procedure in RFC 1890. If the media type
is not suited to the RTP AV profile, then it is recommended that a new is not suited to the RTP AV profile, then it is recommended that a new
profile be created and the appropriate profile name be used in lieu of profile be created and the appropriate profile name be used in lieu of
``RTP/AVP'' in the ``m='' field. ``RTP/AVP'' in the ``m='' field.
C.1.4 Format-specific parameters C.1.4 Format-specific parameters
Format-specific parameters are conveyed using the ``fmtp'' media Format-specific parameters are conveyed using the ``fmtp'' media
skipping to change at line 3814 skipping to change at line 3821
m=audio 8004 RTP/AVP 3 m=audio 8004 RTP/AVP 3
a=control:trackID=2 a=control:trackID=2
In this example, the client is required to establish a single RTSP In this example, the client is required to establish a single RTSP
session to the server, and uses the URLs session to the server, and uses the URLs
rtsp://example.com/movie/trackID=1 and rtsp://example.com/movie/trackID=1 and
rtsp://example.com/movie/trackID=2 to set up the video and audio rtsp://example.com/movie/trackID=2 to set up the video and audio
streams, respectively. The URL rtsp://example.com/movie/ controls the streams, respectively. The URL rtsp://example.com/movie/ controls the
whole movie. whole movie.
D Minimal RTSP implementation Appendix D: Minimal RTSP implementation
D.1 Client D.1 Client
A client implementation MUST be able to do the following : A client implementation MUST be able to do the following :
* Generate the following requests : * Generate the following requests :
SETUP, TEARDOWN, and one of PLAY (i.e., a minimal playback client) SETUP, TEARDOWN, and one of PLAY (i.e., a minimal playback client)
or RECORD (i.e., a minimal recording client). If RECORD is or RECORD (i.e., a minimal recording client). If RECORD is
implemented, ANNOUNCE must be implemented as well. implemented, ANNOUNCE must be implemented as well.
* Include the following headers in requests: * Include the following headers in requests:
skipping to change at line 3949 skipping to change at line 3956
D.2.2 Authentication-enabled D.2.2 Authentication-enabled
In order to correctly handle client authentication, the server MUST In order to correctly handle client authentication, the server MUST
additionally be able to do the following: additionally be able to do the following:
* Generate the 401 status code when authentication is required for * Generate the 401 status code when authentication is required for
the resource. the resource.
* Parse and include the WWW-Authenticate header * Parse and include the WWW-Authenticate header
* Implement Basic Authentication and Digest Authentication * Implement Basic Authentication and Digest Authentication
E Changes Appendix E: Changes
Since draft 06 (November 21, 1997 version) of RTSP, the following
changes were made:
* Added "Persistently suspicious behavior" to Security
Considerations (Section 16).
* Fixed examples in the explanation of NPT (Section 3.6).
* Session identifiers MUST be chosen at random and must be at least
8 octets long (Section 3.4). (Formerly, this was only SHOULD).
* Made XXXX reference to SDP more clearly belong to SDP in Appendix
C (still needs to be fixed when SDP gets an RFC number).
Since draft 05 (October 28, 1997 version) of RTSP, the following Since draft 05 (October 28, 1997 version) of RTSP, the following
changes were made: changes were made:
* Added reference to Timestamp: header * Added reference to Timestamp: header.
* Added some RTP-Info headers to PLAY responses in example code. * Added some RTP-Info headers to PLAY responses in example code.
* Added atomicity wording to SET_PARAMETER. * Added atomicity wording to SET_PARAMETER.
* Added support for smpte-25 * Added support for smpte-25.
* Added Allow header to header table. * Added Allow header to header table.
* Changed smpte and npt to allow 1*2DIGIT. * Changed smpte and npt to allow 1*2DIGIT.
* Changed RTP-Info from providing the last sequence number of the * Changed RTP-Info from providing the last sequence number of the
previous segment to first sequence number of the next segment. previous segment to first sequence number of the next segment.
* Changed SDP a=length to a=range. * Changed SDP a=length to a=range.
* Described ``append'' Transport parameter further. * Described ``append'' Transport parameter further.
* Fixed bugs in CSeq wording (was per packet, now per request). * Fixed bugs in CSeq wording (was per packet, now per request).
* Fleshed out security section reference to HTTP by explaining why * Fleshed out security section reference to HTTP by explaining why
each of the HTTP recommendations are applicable to RTSP. each of the HTTP recommendations are applicable to RTSP.
* Allow server initiated OPTIONS exchange * Allow server initiated OPTIONS exchange
skipping to change at line 4036 skipping to change at line 4054
also conveys the port to be used at the server for RTCP messages, also conveys the port to be used at the server for RTCP messages,
and the start sequence number that will be used in the RTP and the start sequence number that will be used in the RTP
packets. packets.
* The use of the Session: header has been enhanced. Requests for * The use of the Session: header has been enhanced. Requests for
multiple URLs may be sent in a single session. multiple URLs may be sent in a single session.
* There is a distinction between aggregate (presentation) URLs and * There is a distinction between aggregate (presentation) URLs and
stream URLs. Error codes have been added to reflect the fact that stream URLs. Error codes have been added to reflect the fact that
some methods may be allowed only on a particular type of URL. some methods may be allowed only on a particular type of URL.
* Example showing the use of aggregate/presentation control using a * Example showing the use of aggregate/presentation control using a
single RTSP session has been added. single RTSP session has been added.
* Support for the PEP (Protocol Extension Protocol) headers has been * Support for the PEP (Protocol Extension Protocol) headers has been
added. added.
* Server-Client DESCRIBE messages have been renamed to ANNOUNCE for * Server-Client DESCRIBE messages have been renamed to ANNOUNCE for
better clarity and differentiation. better clarity and differentiation.
Note that this list does not reflect minor changes in wording or Note that this list does not reflect minor changes in wording or
correction of typographical errors. correction of typographical errors.
F Author Addresses Appendix F: Author Addresses
Henning Schulzrinne Henning Schulzrinne
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
New York, NY 10027 New York, NY 10027
USA USA
electronic mail: schulzrinne@cs.columbia.edu electronic mail: schulzrinne@cs.columbia.edu
Anup Rao Anup Rao
skipping to change at line 4060 skipping to change at line 4079
New York, NY 10027 New York, NY 10027
USA USA
electronic mail: schulzrinne@cs.columbia.edu electronic mail: schulzrinne@cs.columbia.edu
Anup Rao Anup Rao
Netscape Communications Corp. Netscape Communications Corp.
501 E. Middlefield Road 501 E. Middlefield Road
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
electronic mail: anup@netscape.com electronic mail: anup@netscape.com
Robert Lanphier Robert Lanphier
RealNetworks RealNetworks
1111 Third Avenue Suite 2900 1111 Third Avenue Suite 2900
Seattle, WA 98101 Seattle, WA 98101
USA USA
electronic mail: robla@prognet.com electronic mail: robla@prognet.com
G Acknowledgements Appendix G: Acknowledgements
This draft is based on the functionality of the original RTSP draft This draft is based on the functionality of the original RTSP draft
submitted in October 96. It also borrows format and descriptions from submitted in October 96. It also borrows format and descriptions from
HTTP/1.1. HTTP/1.1.
This document has benefited greatly from the comments of all those This document has benefited greatly from the comments of all those
participating in the MMUSIC-WG. In addition to those already participating in the MMUSIC-WG. In addition to those already
mentioned, the following individuals have contributed to this mentioned, the following individuals have contributed to this
specification: specification:
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/