Subject: draft-ietf-mmusic-rtsp-09.txt

From: Rob Lanphier <[email-masked]>
Date: Mon, 02 Feb 1998 11:05:15 -0800

Yet another cleanup draft, based on comments from ADs and implementors (mostly implementors).  Latest versions are below:

RTSP (Text):
http://www.real.com/rtsp/draft-ietf-mmusic-rtsp-09.txt
RTSP (Postscript):
http://www.cs.columbia.edu/~hgs/rtsp/draft/draft-ietf-mmusic-rtsp-09.ps

Since draft 08, the following changes were made:

*  Note at the end of the "RTSP States" section (1.7) about session 
id creation and usage
*  Note at the end of the "SETUP" section (10.4) about session id 
creation
*  Clarified PAUSE behavior with queued PLAYs.
*  Made Session: examples compliant with the spec
*  Changed RTSP behavior over TCP: SHOULD NOT retransmit -> MUST NOT
*  Changed RTP-Info rtptime header so that rtptime corresponds to npt
   (these should be the same 99% of the time)
*  Clarified begin and end times of range requests

Exhaustive change list is attached.  Let us know ASAP if you have any problems with the changes.

Rob
-----
*** draft-08.txt        Fri Jan 30 21:37:02 1998
--- draft-09.txt        Fri Jan 30 23:04:33 1998
***************
*** 1,7 ****
  Internet Engineering Task Force                                   MMUSIC WG
  Internet Draft                          H. Schulzrinne, A. Rao, R. Lanphier
! draft-ietf-mmusic-rtsp-08.txt             Columbia U./Netscape/RealNetworks
! January 15, 1998                                     Expires: July 15, 1998
  
                    Real Time Streaming Protocol (RTSP)
  
--- 1,7 ----
  Internet Engineering Task Force                                   MMUSIC WG
  Internet Draft                          H. Schulzrinne, A. Rao, R. Lanphier
! draft-ietf-mmusic-rtsp-09.txt             Columbia U./Netscape/RealNetworks
! February 2, 1998                                    Expires: August 2, 1998
  
                    Real Time Streaming Protocol (RTSP)
  
***************
*** 42,48 ****
  
  Copyright Notice:
  ##REMOVEME
!    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  
  Table of Contents
  
--- 42,48 ----
  
  Copyright Notice:
  ##REMOVEME
!    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  
  Table of Contents
  
***************
*** 499,504 ****
--- 499,505 ----
  
     Since not all media servers have the same functionality, media servers
     by necessity will support different sets of requests. For example:
+ 
       * A server may only be capable of playback thus has no need to
         support the RECORD request.
       * A server may not be capable of seeking (absolute positioning) if
***************
*** 612,617 ****
--- 613,623 ----
            Frees resources associated with the stream. The RTSP session
            ceases to exist on the server.
  
+           RTSP methods that contribute to state use the Session header
+           field (Section 12.37) to identify the RTSP session whose state
+           is being manipulated. The server generates session identifiers
+           in response to SETUP requests (Section 10.4).
+ 
  1.8 Relationship with Other Protocols
  
     RTSP has some overlap in functionality with HTTP. It also may interact
***************
*** 884,890 ****
  4 RTSP Message
  
       RTSP is a text-based protocol and uses the ISO 10646 character set
!    in UTF-8 encoding (RFC XXXX [21]). Lines are terminated by CRLF, but
     receivers should be prepared to also interpret CR and LF by themselves
     as line terminators.
  
--- 890,896 ----
  4 RTSP Message
  
       RTSP is a text-based protocol and uses the ISO 10646 character set
!    in UTF-8 encoding (RFC 2279 [21]). Lines are terminated by CRLF, but
     receivers should be prepared to also interpret CR and LF by themselves
     as line terminators.
  
***************
*** 900,906 ****
       This is also the encoding used for RTCP. ISO 8859-1 translates
       directly into Unicode with a high-order octet of zero. ISO 8859-1
       characters with the most-significant bit set are represented as
!      1100001x 10xxxxxx. (See RFC XXXX [21])
  
     RTSP messages can be carried over any lower-layer transport protocol
     that is 8-bit clean.
--- 906,912 ----
       This is also the encoding used for RTCP. ISO 8859-1 translates
       directly into Unicode with a high-order octet of zero. ISO 8859-1
       characters with the most-significant bit set are represented as
!      1100001x 10xxxxxx. (See RFC 2279 [21])
  
     RTSP messages can be carried over any lower-layer transport protocol
     that is 8-bit clean.
***************
*** 1028,1034 ****
       needed for backward-compatibility with HTTP/1.0 servers, a
       consideration that does not apply to RTSP.
  
!    The asterisk "*" in the Request-URI means that the request does not
     apply to a particular resource, but to the server itself, and is only
     allowed when the method used does not necessarily apply to a resource.
     One example would be:
--- 1034,1040 ----
       needed for backward-compatibility with HTTP/1.0 servers, a
       consideration that does not apply to RTSP.
  
!    The asterisk ``*'' in the Request-URI means that the request does not
     apply to a particular resource, but to the server itself, and is only
     allowed when the method used does not necessarily apply to a resource.
     One example would be:
***************
*** 1309,1317 ****
     initial round-trip value of 500 ms. An implementation MAY cache the
     last RTT measurement as the initial value for future connections.
  
!    If a reliable transport protocol is used to carry RTSP, requests
!    SHOULD NOT be retransmitted; the RTSP application SHOULD instead rely
!    on the underlying transport to provide reliability.
  
       If both the underlying reliable transport such as TCP and the RTSP
       application retransmit requests, it is possible that each packet
--- 1315,1323 ----
     initial round-trip value of 500 ms. An implementation MAY cache the
     last RTT measurement as the initial value for future connections.
  
!    If a reliable transport protocol is used to carry RTSP, requests MUST
!    NOT be retransmitted; the RTSP application MUST instead rely on the
!    underlying transport to provide reliability.
  
       If both the underlying reliable transport such as TCP and the RTSP
       application retransmit requests, it is possible that each packet
***************
*** 1334,1340 ****
     (Section 12.17), which is incremented by one for each distinct request
     transmitted. If a request is repeated because of lack of
     acknowledgement, the request MUST carry the original sequence number
!    (i.e. sequence number is not incremented).
  
     Systems implementing RTSP MUST support carrying RTSP over TCP and MAY
     support UDP. The default port for the RTSP server is 554 for both UDP
--- 1340,1346 ----
     (Section 12.17), which is incremented by one for each distinct request
     transmitted. If a request is repeated because of lack of
     acknowledgement, the request MUST carry the original sequence number
!    (i.e., the sequence number is not incremented).
  
     Systems implementing RTSP MUST support carrying RTSP over TCP and MAY
     support UDP. The default port for the RTSP server is 554 for both UDP
***************
*** 1490,1496 ****
       C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0
             CSeq: 312
             Date: 23 Jan 1997 15:35:06 GMT
!            Session: 4711
             Content-Type: application/sdp
             Content-Length: 332
  
--- 1496,1502 ----
       C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0
             CSeq: 312
             Date: 23 Jan 1997 15:35:06 GMT
!            Session: 47112344
             Content-Type: application/sdp
             Content-Length: 332
  
***************
*** 1537,1546 ****
      S->C: RTSP/1.0 200 OK
            CSeq: 302
            Date: 23 Jan 1997 15:35:06 GMT
!           Session: 4711
            Transport: RTP/AVP;unicast;
              client_port=4588-4589;server_port=6256-6257
  
  10.5 PLAY
  
       The PLAY method tells the server to start sending data via the
--- 1543,1558 ----
      S->C: RTSP/1.0 200 OK
            CSeq: 302
            Date: 23 Jan 1997 15:35:06 GMT
!           Session: 47112344
            Transport: RTP/AVP;unicast;
              client_port=4588-4589;server_port=6256-6257
  
+    The server generates session identifiers in response to SETUP
+    requests. If a SETUP request to a server includes a session
+    identifier, the server MUST bundle this setup request into the
+    existing session or return error ``459 Aggregate Operation Not
+    Allowed'' (see Section 11.3.10).
+ 
  10.5 PLAY
  
       The PLAY method tells the server to start sending data via the
***************
*** 1564,1577 ****
--- 1576,1592 ----
  
       C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
             CSeq: 835
+            Session: 12345678
             Range: npt=10-15
  
       C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
             CSeq: 836
+            Session: 12345678
             Range: npt=20-25
  
       C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
             CSeq: 837
+            Session: 12345678
             Range: npt=30-
  
     See the description of the PAUSE request for further examples.
***************
*** 1604,1609 ****
--- 1619,1625 ----
  
       C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0
             CSeq: 833
+            Session: 12345678
             Range: smpte=0:10:20-;time=19970123T153600Z
  
       S->C: RTSP/1.0 200 OK
***************
*** 1616,1621 ****
--- 1632,1638 ----
  
       C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0
             CSeq: 835
+            Session: 12345678
             Range: clock=19961108T142300Z-19961108T143520Z
  
       S->C: RTSP/1.0 200 OK
***************
*** 1642,1662 ****
  
       C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
             CSeq: 834
!            Session: 1234
  
       S->C: RTSP/1.0 200 OK
             CSeq: 834
             Date: 23 Jan 1997 15:35:06 GMT
  
     The PAUSE request may contain a Range header specifying when the
!    stream or presentation is to be halted. The header must contain
!    exactly one value rather than a time range. The normal play time for
!    the stream is set to that value. The pause request becomes effective
!    the first time the server is encountering the time point specified in
!    any of the currently pending PLAY requests. If the Range header
!    specifies a time outside any currently pending PLAY requests, the
!    error ``457 Invalid Range'' is returned. If this header is missing,
!    stream delivery is interrupted immediately on receipt of the message.
  
     For example, if the server has play requests for ranges 10 to 15 and
     20 to 29 pending and then receives a pause request for NPT 21, it
--- 1659,1687 ----
  
       C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
             CSeq: 834
!            Session: 12345678
  
       S->C: RTSP/1.0 200 OK
             CSeq: 834
             Date: 23 Jan 1997 15:35:06 GMT
  
     The PAUSE request may contain a Range header specifying when the
!    stream or presentation is to be halted. We refer to this point as the
!    ``pause point''. The header must contain exactly one value rather than
!    a time range. The normal play time for the stream is set to the pause
!    point. The pause request becomes effective the first time the server
!    is encountering the time point specified in any of the currently
!    pending PLAY requests. If the Range header specifies a time outside
!    any currently pending PLAY requests, the error ``457 Invalid Range''
!    is returned. If a media unit (such as an audio or video frame) starts
!    presentation at exactly the pause point, it is not played or recorded.
!    If the Range header is missing, stream delivery is interrupted
!    immediately on receipt of the message and the pause point is set to
!    the current normal play time.
! 
!    A PAUSE request discards all queued PLAY requests. However, the pause
!    point in the media stream MUST be maintained. A subsequent PLAY
!    request without Range header resumes from the pause point.
  
     For example, if the server has play requests for ranges 10 to 15 and
     20 to 29 pending and then receives a pause request for NPT 21, it
***************
*** 1691,1697 ****
     Example:
       C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
             CSeq: 892
!            Session: 1234
       S->C: RTSP/1.0 200 OK
             CSeq: 892
  
--- 1716,1722 ----
     Example:
       C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
             CSeq: 892
!            Session: 12345678
       S->C: RTSP/1.0 200 OK
             CSeq: 892
  
***************
*** 1707,1713 ****
       S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
             CSeq: 431
             Content-Type: text/parameters
!            Session: 1234
             Content-Length: 15
  
             packets_received
--- 1732,1738 ----
       S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
             CSeq: 431
             Content-Type: text/parameters
!            Session: 12345678
             Content-Length: 15
  
             packets_received
***************
*** 1812,1818 ****
  
       C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0
             CSeq: 954
!            Session: 1234
             Conference: 128.16.64.19/32492374
  
  10.12 Embedded (Interleaved) Binary Data
--- 1837,1843 ----
  
       C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0
             CSeq: 954
!            Session: 12345678
             Conference: 128.16.64.19/32492374
  
  10.12 Embedded (Interleaved) Binary Data
***************
*** 1855,1869 ****
             CSeq: 2
             Date: 05 Jun 1997 18:57:18 GMT
             Transport: RTP/AVP/TCP;interleaved=0-1
!            Session: 12345
  
       C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0
             CSeq: 3
!            Session: 12345
  
       S->C: RTSP/1.0 200 OK
             CSeq: 3
!            Session: 12345
             Date: 05 Jun 1997 18:59:15 GMT
             RTP-Info: url=rtsp://foo.com/bar.file;
               seq=232433;rtptime=972948234
--- 1880,1894 ----
             CSeq: 2
             Date: 05 Jun 1997 18:57:18 GMT
             Transport: RTP/AVP/TCP;interleaved=0-1
!            Session: 12345678
  
       C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0
             CSeq: 3
!            Session: 12345678
  
       S->C: RTSP/1.0 200 OK
             CSeq: 3
!            Session: 12345678
             Date: 05 Jun 1997 18:59:15 GMT
             RTP-Info: url=rtsp://foo.com/bar.file;
               seq=232433;rtptime=972948234
***************
*** 1953,1959 ****
  
    11.3.10 459 Aggregate Operation Not Allowed
  
!    The requested method may not be applied on the URL in question since
     it is an aggregate (presentation) URL. The method may be applied on a
     stream URL.
  
--- 1978,1984 ----
  
    11.3.10 459 Aggregate Operation Not Allowed
  
!      The requested method may not be applied on the URL in question since
     it is an aggregate (presentation) URL. The method may be applied on a
     stream URL.
  
***************
*** 2410,2417 ****
     is not understood, the recipient should return ``501 Not
     Implemented''.
  
!    Range            = "Range" ":" 1#ranges-specifier 
!                        [ ";" "time" "=" utc-time ]
     ranges-specifier = npt-range | utc-range | smpte-range
  
     Example:
--- 2435,2453 ----
     is not understood, the recipient should return ``501 Not
     Implemented''.
  
!    Ranges are half-open intervals, including the lower point, but
!    excluding the upper point. In other words, a range of a-b starts
!    exactly at time a, but stops just before b. Only the start time of a
!    media unit such as a video or audio frame is relevant. As an example,
!    assume that video frames are generated every 40 ms. A range of
!    10.0-10.1 would include a video frame starting at 10.0 or later time
!    and would include a video frame starting at 10.08, even though it
!    lasted beyond the interval. A range of 10.0-10.08, on the other hand,
!    would exclude the frame at 10.08.
! 
! 
!    Range            = "Range" ":" 1\#ranges-specifier 
!                      [ ";" "time" "=" utc-time ]
     ranges-specifier = npt-range | utc-range | smpte-range
  
     Example:
***************
*** 2476,2482 ****
     Proxies and other intermediary devices SHOULD ignore features that are
     not understood in this field. If a particular extension requires that
     intermediate devices support it, the extension should be tagged in the
!    Proxy-Require field instead (see Section 3.4).
  
  12.33 RTP-Info
  
--- 2512,2518 ----
     Proxies and other intermediary devices SHOULD ignore features that are
     not understood in this field. If a particular extension requires that
     intermediate devices support it, the extension should be tagged in the
!    Proxy-Require field instead (see Section 12.27).
  
  12.33 RTP-Info
  
***************
*** 2495,2503 ****
            originated after the seek.
  
     rtptime:
!           Indicates the RTP timestamp of the first packet of the stream.
!           The client uses this value to calculate the mapping of RTP time
!           to NPT.
  
       A mapping from RTP timestamps to NTP timestamps (wall clock) is
       available via RTCP. However, this information is not sufficient to
--- 2531,2544 ----
            originated after the seek.
  
     rtptime:
!           Indicates the RTP timestamp corresponding to the time value in
!           the Range response header. (Note: For aggregrate control, a
!           particular stream may not actually generate a packet for the
!           Range time value returned or implied. Thus, there is no
!           guarantee that the packet with the sequence number indicated by
!           seq actually has the timestamp indicated by rtptime.) The
!           client uses this value to calculate the mapping of RTP time to
!           NPT.
  
       A mapping from RTP timestamps to NTP timestamps (wall clock) is
       available via RTCP. However, this information is not sufficient to
***************
*** 2901,2907 ****
  
       A->C: RTSP/1.0 200 OK
             CSeq: 1
!            Session: 1234
             Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;
                        server_port=5000-5001
  
--- 2942,2948 ----
  
       A->C: RTSP/1.0 200 OK
             CSeq: 1
!            Session: 12345678
             Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;
                        server_port=5000-5001
  
***************
*** 2911,2954 ****
  
       V->C: RTSP/1.0 200 OK
             CSeq: 1
!            Session: 1235
             Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;
                        server_port=5002-5003
  
       C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
             CSeq: 2
!            Session: 1235
             Range: smpte=0:10:00-
  
       V->C: RTSP/1.0 200 OK
             CSeq: 2
!            Session: 1235
             Range: smpte=0:10:00-0:20:00
             RTP-Info: url=rtsp://video.example.com/twister/video;
               seq=12312232;rtptime=78712811
  
       C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
             CSeq: 2
!            Session: 1234
             Range: smpte=0:10:00-
  
       A->C: RTSP/1.0 200 OK
             CSeq: 2
!            Session: 1234
             Range: smpte=0:10:00-0:20:00
             RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
               seq=876655;rtptime=1032181
  
       C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
             CSeq: 3
!            Session: 1234
  
       A->C: RTSP/1.0 200 OK
             CSeq: 3
  
       C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
             CSeq: 3
!            Session: 1235
  
       V->C: RTSP/1.0 200 OK
             CSeq: 3
--- 2952,2995 ----
  
       V->C: RTSP/1.0 200 OK
             CSeq: 1
!            Session: 23456789
             Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;
                        server_port=5002-5003
  
       C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
             CSeq: 2
!            Session: 23456789
             Range: smpte=0:10:00-
  
       V->C: RTSP/1.0 200 OK
             CSeq: 2
!            Session: 23456789
             Range: smpte=0:10:00-0:20:00
             RTP-Info: url=rtsp://video.example.com/twister/video;
               seq=12312232;rtptime=78712811
  
       C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
             CSeq: 2
!            Session: 12345678
             Range: smpte=0:10:00-
  
       A->C: RTSP/1.0 200 OK
             CSeq: 2
!            Session: 12345678
             Range: smpte=0:10:00-0:20:00
             RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
               seq=876655;rtptime=1032181
  
       C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
             CSeq: 3
!            Session: 12345678
  
       A->C: RTSP/1.0 200 OK
             CSeq: 3
  
       C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
             CSeq: 3
!            Session: 23456789
  
       V->C: RTSP/1.0 200 OK
             CSeq: 3
***************
*** 3015,3058 ****
             CSeq: 2
             Transport: RTP/AVP;unicast;client_port=8000-8001;
                        server_port=9000-9001
!            Session: 1234
  
       C->M: SETUP rtsp://foo/twister/video RTSP/1.0
             CSeq: 3
             Transport: RTP/AVP;unicast;client_port=8002-8003
!            Session: 1234
  
       M->C: RTSP/1.0 200 OK
             CSeq: 3
             Transport: RTP/AVP;unicast;client_port=8002-8003;
                        server_port=9004-9005
!            Session: 1234
  
       C->M: PLAY rtsp://foo/twister RTSP/1.0
             CSeq: 4
             Range: npt=0-
!            Session: 1234
  
       M->C: RTSP/1.0 200 OK
             CSeq: 4
!            Session: 1234
             RTP-Info: url=rtsp://foo/twister/video;
               seq=9810092;rtptime=3450012
  
       C->M: PAUSE rtsp://foo/twister/video RTSP/1.0
             CSeq: 5
!            Session: 1234
  
       M->C: RTSP/1.0 460 Only aggregate operation allowed
             CSeq: 5
  
       C->M: PAUSE rtsp://foo/twister RTSP/1.0
             CSeq: 6
!            Session: 1234
  
       M->C: RTSP/1.0 200 OK
             CSeq: 6
!            Session: 1234
  
       C->M: SETUP rtsp://foo/twister RTSP/1.0
             CSeq: 7
--- 3056,3099 ----
             CSeq: 2
             Transport: RTP/AVP;unicast;client_port=8000-8001;
                        server_port=9000-9001
!            Session: 12345678
  
       C->M: SETUP rtsp://foo/twister/video RTSP/1.0
             CSeq: 3
             Transport: RTP/AVP;unicast;client_port=8002-8003
!            Session: 12345678
  
       M->C: RTSP/1.0 200 OK
             CSeq: 3
             Transport: RTP/AVP;unicast;client_port=8002-8003;
                        server_port=9004-9005
!            Session: 12345678
  
       C->M: PLAY rtsp://foo/twister RTSP/1.0
             CSeq: 4
             Range: npt=0-
!            Session: 12345678
  
       M->C: RTSP/1.0 200 OK
             CSeq: 4
!            Session: 12345678
             RTP-Info: url=rtsp://foo/twister/video;
               seq=9810092;rtptime=3450012
  
       C->M: PAUSE rtsp://foo/twister/video RTSP/1.0
             CSeq: 5
!            Session: 12345678
  
       M->C: RTSP/1.0 460 Only aggregate operation allowed
             CSeq: 5
  
       C->M: PAUSE rtsp://foo/twister RTSP/1.0
             CSeq: 6
!            Session: 12345678
  
       M->C: RTSP/1.0 200 OK
             CSeq: 6
!            Session: 12345678
  
       C->M: SETUP rtsp://foo/twister RTSP/1.0
             CSeq: 7
***************
*** 3275,3287 ****
  
       M->C: RTSP/1.0 200 OK
             CSeq: 91
!            Session: 508876
             Transport: RTP/AVP;multicast;destination=224.0.1.11;
                        port=21010-21011;mode=record;ttl=127
  
       C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0
             CSeq: 92
!            Session: 508876
             Transport: RTP/AVP;multicast;destination=224.0.1.12;
                        port=61010-61011;mode=record;ttl=127
  
--- 3316,3328 ----
  
       M->C: RTSP/1.0 200 OK
             CSeq: 91
!            Session: 50887676
             Transport: RTP/AVP;multicast;destination=224.0.1.11;
                        port=21010-21011;mode=record;ttl=127
  
       C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0
             CSeq: 92
!            Session: 50887676
             Transport: RTP/AVP;multicast;destination=224.0.1.12;
                        port=61010-61011;mode=record;ttl=127
  
***************
*** 3292,3298 ****
  
       C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0
             CSeq: 93
!            Session: 508876
             Range: clock=19961110T1925-19961110T2015
  
       M->C: RTSP/1.0 200 OK
--- 3333,3339 ----
  
       C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0
             CSeq: 93
!            Session: 50887676
             Range: clock=19961110T1925-19961110T2015
  
       M->C: RTSP/1.0 200 OK
***************
*** 3482,3488 ****
  ##REMOVEME
       PLAY rtsp://foo.com/movie RTSP/1.0
       CSeq: 559
!      Session: 12345
  ##REMOVEME
     will have an effect on the states of movie/audio and movie/video.
  ##REMOVEME
--- 3523,3529 ----
  ##REMOVEME
       PLAY rtsp://foo.com/movie RTSP/1.0
       CSeq: 559
!      Session: 12345678
  ##REMOVEME
     will have an effect on the states of movie/audio and movie/video.
  ##REMOVEME
***************
*** 3527,3533 ****
     state, as listed above. Receiving a REDIRECT from the server is
     equivalent to receiving a 3xx redirect status from the server.
  
- 
     state       message sent     next state after response
     Init        SETUP            Ready
                 TEARDOWN         Init
--- 3568,3573 ----
***************
*** 3587,3593 ****
     success response (2xx). If a request results in a status code of 3xx,
     the state becomes Init. A status code of 4xx results in no change.
  
- 
       state           message received  next state
       Init            SETUP             Ready
                       TEARDOWN          Init
--- 3627,3632 ----
***************
*** 3862,3876 ****
  
     A client implementation MUST be able to do the following :
  
!      * Generate the following requests :
!        SETUP, TEARDOWN, and one of PLAY (i.e., a minimal playback client)
!        or RECORD (i.e., a minimal recording client). If RECORD is
!        implemented, ANNOUNCE must be implemented as well.
!      * Include the following headers in requests:
!        CSeq, Connection, Session, Transport. If ANNOUNCE is implemented,
!        the capability to include headers Content-Language,
!        Content-Encoding, Content-Length, and Content-Type should be as
!        well.
       * Parse and understand the following headers in responses: CSeq,
         Connection, Session, Transport, Content-Language,
         Content-Encoding, Content-Length, Content-Type. If RECORD is
--- 3901,3914 ----
  
     A client implementation MUST be able to do the following :
  
!      * Generate the following requests: SETUP, TEARDOWN, and one of PLAY
!        (i.e., a minimal playback client) or RECORD (i.e., a minimal
!        recording client). If RECORD is implemented, ANNOUNCE must be
!        implemented as well.
!      * Include the following headers in requests: CSeq, Connection,
!        Session, Transport. If ANNOUNCE is implemented, the capability to
!        include headers Content-Language, Content-Encoding,
!        Content-Length, and Content-Type should be as well.
       * Parse and understand the following headers in responses: CSeq,
         Connection, Session, Transport, Content-Language,
         Content-Encoding, Content-Length, Content-Type. If RECORD is
***************
*** 4121,4129 ****
            resource locators (URL),'' RFC 1738, Internet Engineering Task
            Force, Dec. 1994.
  
!    21     F. Yergeau, ``Utf-8, a transformation format of iso 10646,''
!           Request for Comments XXXX, Internet Engineering Task Force,
!           Jan. 1998.
  
     22     B. Braden, ``T/TCP - TCP extensions for transactions functional
            specification,'' RFC 1644, Internet Engineering Task Force,
--- 4159,4166 ----
            resource locators (URL),'' RFC 1738, Internet Engineering Task
            Force, Dec. 1994.
  
!    21     F. Yergeau, ``UTF-8, a transformation format of ISO 10646,''
!           RFC 2279, Internet Engineering Task Force, Jan. 1998.
  
     22     B. Braden, ``T/TCP - TCP extensions for transactions functional
            specification,'' RFC 1644, Internet Engineering Task Force,
***************
*** 4141,4147 ****
  
  Full Copyright Statement
  
!    Copyright (C) The Internet Society (1997). All Rights Reserved.
  
     This document and translations of it may be copied and furnished to
     others, and derivative works that comment on or otherwise explain it
--- 4178,4184 ----
  
  Full Copyright Statement
  
!    Copyright (C) The Internet Society (1998). All Rights Reserved.
  
     This document and translations of it may be copied and furnished to
     others, and derivative works that comment on or otherwise explain it

---
Rob Lanphier ([email-masked])    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/firewall