home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rao-rtsp-00.txt < prev    next >
Text File  |  1996-10-10  |  70KB  |  1,915 lines
  1. INTERNET-DRAFT                       Anup Rao, Netscape Communications
  2.                                     Rob Lanphier, Progressive Networks
  3.  
  4. SUBMITTED: 9th October 1996                        Expires: April 1997
  5.  
  6.               Real Time Streaming Protocol(RTSP) 
  7.                    <draft-rao-rtsp-00.txt>
  8.  
  9. STATUS OF THIS MEMO
  10.  
  11. This is an Internet-Draft.  Internet-Drafts are working
  12. documents of the Internet Engineering Task Force (IETF),
  13. its areas, and its working groups. Note that other groups
  14. may also distribute working documents as Internet-Drafts.
  15. Internet-Drafts are draft documents valid for a maximum 
  16. of six months and may be updated, replaced, or obsoleted by
  17. other documents at any time.  It is inappropriate to use
  18. Internet-Drafts as reference material or 
  19. to cite them other than as "work in progress."
  20.  
  21. To learn the current status of any Internet-Draft, please
  22. check the "lid-abstracts.txt" listing contained in the
  23. Internet-Drafts Shadow Directories on ftp.is.co.za
  24. (Africa), nic.nordu.net (Europe), mannari.oz.au (Pacific
  25. Rim), ds.internic.net (Us East Coast), or ftp.isi.edu (US
  26. West Coast).
  27.  
  28. ABSTRACT
  29.  
  30. The Real Time Streaming Protocol, or RTSP, is an
  31. application-level protocol for control over the delivery of
  32. data with real-time properties. RTSP provides an extensible
  33. framework to enable controlled, on-demand delivery of real-
  34. time data, such as audio and video. Sources of data can
  35. include both live data feeds and stored clips. This
  36. protocol is intended to control multiple data delivery
  37. sessions, provide a means for choosing delivery
  38. channels such as UDP, multicast UDP and TCP, and delivery
  39. mechanisms based upon RTP (RFC 1889). RTSP uses the Session
  40. Control Protocol (SCP) (see appendix) to allow the use of a
  41. single TCP connection between the client and server for
  42. controlling delivery of one or more streams of data.
  43.  
  44.  
  45. Rao, Lanphier                                      Page 1
  46.  
  47.  
  48. INTERNET-DRAFT          RTSP              October 9, 1996
  49.  
  50.  
  51. TABLE OF CONTENTS
  52.  
  53.      1.0 INTRODUCTION
  54.      2.0 DOCUMENT CONVENTIONS
  55.      3.0 PROTOCOL DESCRIPTION
  56.           3.1 Connection Messages
  57.           3.2 Object Messages
  58.           3.3 Custom Messages/Events 
  59.           3.4 Media specific options and Extension mechanism 
  60.      4.0 EXAMPLES/APPLICATION NOTE
  61.      5.0 REFERENCES
  62.      6.0 APPENDIXES
  63.           6.1 Appendix A - Data Packets 
  64.           6.2 Appendix B - Session Control Protocol (SCP)
  65.           6.3 Appendix C - RTSP Audio Format
  66.           6.4 Appendix D - RTSP Audio Annotations
  67.           6.5 Appendix E - Authors
  68.  
  69. 1.0 INTRODUCTION
  70.  
  71. This document describes the Real Time Streaming Protocol,
  72. or RTSP. 
  73.  
  74. The RTSP provides mechanisms to:
  75.      -Request delivery of real-time data 
  76.      -Request a specific transport type and destination for
  77.       the delivery of the data 
  78.      -Request information about the data in a format-
  79.       specific fashion 
  80.      -Start, stop, and pause the delivery of the data 
  81.      -Provide random access to various portions of the data
  82.       (where applicable) 
  83.  
  84.  
  85. Rao, Lanphier                                      Page 2
  86.  
  87.  
  88. INTERNET-DRAFT          RTSP              October 9, 1996
  89.  
  90.  
  91. RTSP uses TCP for delivery of control messages, and allows
  92. for a variety of delivery options for the data including
  93. both multicast and unicast UDP based on RTP(RFC 1889), and TCP
  94. where applicable. RTSP uses the Session Control Protocol 
  95. (see appendix) to allow the use of a single TCP connection
  96. between the client and server for controlling delivery of
  97. one or more streams of data. The RTSP specifically uses one
  98. SCP session to deliver control messages and in addition, 
  99. a new SCP session might be opened for each real-time object
  100. delivered.
  101.  
  102. While the protocol is designed for the streaming of real-
  103. time data regardless of its format, it also provides
  104. mechanisms to inquire about format specific information
  105. (compression type, data rate, compression-type specific
  106. headers and frame boundaries). Considerations for each peer
  107. arising from these features are discussed later in the
  108. document. Three typical categories of data whose delivery
  109. could be controlled with RTSP include:
  110.  
  111. 1. Real-time stored clips
  112. This category comprises all real-time recordings (primarily
  113. audio/video). 
  114. Examples include web sites with audio narration, stored
  115. audio recordings, and video recordings. A typical end-user
  116. application would be an audio/video store site providing
  117. excerpts from its collection on-demand.
  118.  
  119. 2. Real-time live feeds
  120. This category comprises real-time data which is fed in live
  121. at the server site rather than being pre-recorded. Examples
  122. of this usage include a press conference, a live internet
  123. radio station, or a televised shuttle launch.
  124.  
  125. 3. Non real-time stored data
  126. This category comprises non-real-time data of any MIME
  127. type, similar to data served by HTTP servers. This data is
  128. provided over a new SCP session. While HTTP servers would
  129. serve this kind of data in most cases, it might be advanta-
  130. geous to serve non-real-time data with RTSP. This is
  131. typically true of non-real-time data pertaining to real-
  132. time data being served; for example, a text track playing
  133. along with audio/video. This category is meant to provide
  134. the capability of serving non-real-time data through RTSP,
  135. and it is strongly recommended that it be used only when
  136. advantageous over existing mechanisms.
  137.  
  138.  
  139. Rao, Lanphier                                      Page 3
  140.  
  141.  
  142. INTERNET-DRAFT          RTSP              October 9, 1996
  143.  
  144.  
  145. 2.0 DOCUMENT CONVENTIONS
  146.  
  147. The following conventions are used throughout this document:
  148.  
  149. Byte Order and Alignment
  150. All integer fields are carried in network byte order, where
  151. the most significant byte is sent first. Integers are
  152. aligned on their natural length: 16 bit integers on even
  153. byte boundary, 32 bit integers on 4 byte boundary and so on.  
  154.  
  155. Definitions
  156.  
  157. Stream
  158. A stream is data of a distinct type that is sent from
  159. server to client at a rate defined by the server, even if
  160. more bandwidth is available. For a typical video broadcast,
  161. for example, one stream could consist of the video signal,
  162. one stream could consist of the audio data, and one stream
  163. could contain the closed caption information. In most
  164. cases, each stream is served at the rate that it should be
  165. rendered by the client.
  166.  
  167. Global Control Session
  168. The SCP session with a well-known session ID, used for
  169. exchange of connection messages described later in this
  170. document.
  171.  
  172. Stream Control Session
  173.  
  174. An SCP session established for each stream, used for
  175. exchange of object messages described later in this
  176. document.
  177.  
  178. URL
  179. A Uniform Resource Locator or URL is a unique identifier
  180. that describes a resource on the Internet. The syntax for
  181. URLs is defined by RFC 1738.
  182.  
  183.  
  184. Rao, Lanphier                                      Page 4
  185.  
  186.  
  187. INTERNET-DRAFT          RTSP              October 9, 1996
  188.  
  189.  
  190. 3.0 PROTOCOL DESCRIPTION
  191.  
  192. Two classes of messages exist in RTSP; those sent on the
  193. Global control session, termed connection messages and
  194. those sent on the Stream control session, termed object
  195. messages. Some messages might fall in both categories.
  196.  
  197. 3.1 Connection messages
  198.  
  199. Connection messages are used to negotiate protocol version
  200. and possibly client identity.  This is common to all
  201. streams requested on the connection.
  202.  
  203. HELLO
  204. Upon connection, the client sends a HELLO message to the
  205. server informing it of its version and desire to establish
  206. a RTSP session. The server replies with a HELLO message.
  207. The server need not wait for the clients HELLO message
  208. before sending its own. The message includes protocol
  209. version, and optional character string denoting the user-
  210. agent(to be specified). The communication continues in the
  211. lower of the exchanged versions. If the two sides cannot
  212. speak this common version, the connection is closed.
  213.  
  214.  0                   1                   2                   3
  215.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  216. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  217. |                         HELLO                                 |
  218. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  219. |     Major     |     Minor     | Sub Protocol  |     Reserved  |
  220. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  221. |                                                               |
  222. /                      User Agent (Optional)                    /
  223. |                                                               |
  224. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  225.  
  226. Major Version 
  227. Specifies the major RTSP version.
  228.  
  229. Minor Version
  230. Specifies the minor RTSP version within the major version.
  231.  
  232.  
  233. Rao, Lanphier                                      Page 5
  234.  
  235.  
  236. INTERNET-DRAFT          RTSP              October 9, 1996
  237.  
  238.  
  239. Sub Protocol
  240. Specifies the sub-protocol spoken by the sender. For normal 
  241. client-server communication, this should be 0.
  242.  
  243. Reserved
  244. For future use. 
  245.  
  246. User Agent
  247. Is an optional null-terminated character string sent by the client 
  248. to provide information like the client name, machine type, OS etc.
  249.  
  250. ID 
  251.  
  252. This message is sent by either a server or a client. The recipient of this
  253. message is asked to prove its identity. A number of different schemes are
  254. possible, the simplest of which uses a password. More complicated schemes can
  255. cause a one time challenge and response mechanism. Multiple challenge
  256. response steps are possible and implemenation dependent.
  257.  
  258. A separate ID message allows a server to service a number of different classes 
  259. of users. The ID message can be sent at any time during the session or may be 
  260. sent once per URL, depending on how a service is configured. 
  261.  
  262.  
  263. Rao, Lanphier                                      Page 6
  264.  
  265.  
  266. INTERNET-DRAFT          RTSP              October 9, 1996
  267.  
  268.  
  269.  0                   1                   2                   3
  270.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  271. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  272. |                          tag(ID)                              |
  273. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  274. |            key type           |           (reserved)          |
  275. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  276. |                                                               |
  277. /                      authentication key                       /
  278. |                                                               |
  279. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  280.  
  281. Key type 
  282. Specifies the authentication key type. Authentication of different strengths 
  283. might be required in different situations. This field allows a choice of 
  284. authentication. It is up to the client and server to negotiate what level of 
  285. authentication is used. Note that different services might be available at
  286. different authentication levels. 
  287.  
  288. Authentication key 
  289. Specifies the key that authenticates the sender. The standard key types and 
  290. proper responses will be specified in an extension to this document. 
  291.  
  292. ID_RESP
  293. This message is sent in response to an ID message. The entity issuing the ID 
  294. message closes the TCP connection if the response is not valid.
  295.  
  296.  
  297. Rao, Lanphier                                      Page 7
  298.  
  299.  
  300. INTERNET-DRAFT          RTSP              October 9, 1996
  301.  
  302.  
  303.  0                   1                   2                   3
  304.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  305. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  306. |                          (tag)ID_RESP                         |
  307. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  308. |            key type           |          response code        |
  309. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  310. |                                                               |
  311. /                         response data                         /
  312. |                                                               |
  313. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  314.  
  315. Key type 
  316. Specifies the authentication key type. Authentication of
  317. different strength may be required in different situations. This
  318. field allows a choice of authentication. It is up to the client
  319. and server to negotiate what level of authentication is used.
  320. Note that different services might be available at different 
  321. authentication levels.
  322.  
  323. Response code 
  324. Specifies one of the two possible responses to an ID message:
  325.      OK 
  326.      Authentication type recognized, response follows. 
  327.  
  328.      UNKNOWN 
  329.      Unknown type, ordered list of authentication types follows
  330.      (can be a null list). 
  331.  
  332. Response data 
  333. Specifies the response, depending on the response code. If OK,
  334. then this is the key that authenticates the sender, and the
  335. format is dictated by the authentication type. If UNKNOWN, then
  336. this is a list of 16-bit response types that are acceptable to
  337. the recipient. 
  338.  
  339. The standard key types and proper responses will be specified in
  340. an extension to this document. 
  341.  
  342.  
  343.  
  344. Rao, Lanphier                                      Page 8
  345.  
  346.  
  347. INTERNET-DRAFT          RTSP              October 9, 1996
  348.  
  349.  
  350. REDIRECT  
  351.  
  352. A redirect message informs the client that it must connect to
  353. another server location. When received on the Global control
  354. session, it should be made effective as specified by offset. The
  355. message can also be sent on a Stream control session, in which
  356. case it it relative to the stream.
  357.  
  358.  0                   1                   2                   3
  359.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  360. +-------------------------------+-------------------------------+
  361. |                             tag  (REDIRECT)                   |
  362. +-------------------------------+-------------------------------+
  363. |                             Offset                            |
  364. +-------------------------------+-------------------------------+
  365. |                                                               |
  366. \                              URL                              \
  367. |                                                               |
  368. +-------------------------------+-------------------------------+
  369.  
  370. Offset: On the Stream control session, 
  371. Specifies the position (in milliseconds) in the media stream at
  372. which time the redirection is effective. If received on the
  373. global control session, it means that the server is not available
  374. after this time.
  375.  
  376. URL
  377. Is a null-terminated string that identifies the new location for
  378. the object. This URL is similar to the one specified in the
  379. original FETCH request, described later in this document.
  380.  
  381. OPTIONS
  382.  
  383. This message is used to negotiate additional functionality. This
  384. can be sent by the client or the server. This is provided as an
  385. extension mechanism to extend the protocol without changing the
  386. version number. Set 0 refers to the global set of options, a
  387. universally-agreed upon set. Implementors can use this to
  388. negotiate replacements for messages in the current specification;
  389. however, all implementations must be able to support the core
  390. messages defined here, and be prepared not to use an option
  391. should the other implementation not be prepared to support the
  392. given option. The maximum size of an option set is 64.
  393.  
  394. This is defined in the spirit of the TELNET protocol (RFC 854),
  395. which provides  a further explanation of how different
  396. implementations may interoperate using this mechanism.
  397.  
  398.  
  399. Rao, Lanphier                                      Page 9
  400.  
  401.  
  402. INTERNET-DRAFT          RTSP              October 9, 1996
  403.  
  404.  
  405.  0                   1                   2                   3
  406.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  407. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  408. |                     tag (OPTIONS)                             |
  409. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  410. |                          option set                           |
  411. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  412. |                     highest option number                     |
  413. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  414. |s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|
  415. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  416. /                                                               /
  417. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  418. |s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|
  419. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  420.  
  421. Option set
  422. Implementors can specify an option set to use for adding custom extensions. 
  423. In addition, as the protocol matures, certain options may be accepted as
  424. universal to all clients,which will be placed in the reserved range of 
  425. option sets. The following ranges of options are reserved: 
  426.  
  427. Option set                    Purpose
  428. -----------                   ------------------------------------
  429.  
  430. 0                             This is a universally accepted set
  431.                               of options
  432.  
  433. 0x1-0xFFFF                    Reserved for later allocation
  434.  
  435. 0x10000-0xFFFFFFFF            Custom extensions (i.e. vendor or 
  436.                               organization specific)
  437.  
  438.  
  439. Rao, Lanphier                                     Page 10
  440.  
  441.  
  442. INTERNET-DRAFT          RTSP              October 9, 1996
  443.  
  444.  
  445. Highest option number 
  446. Specifies the highest option number that is set or unset. It is
  447. used to calculate the length of the bit vectors that follow. This
  448. list is zero indexed. 
  449.  
  450. s.d.s.w 
  451.                                             s.d.s.w
  452.                                             ^ ^ ^ ^
  453.                                             | | | |
  454.                  select do/don't  ----------+ | | |
  455.                  do/don't  -------------------+ | |
  456.                  select will/won't  ------------+ |
  457.                  will/won't  ---------------------+
  458.                     
  459. select do/don't  
  460. If set, activates the do/don't flag 
  461.                     
  462. do/don't 
  463. If set to 1, means DO and if set to 0, means DON'T. 
  464.  
  465. DO indicates the request that the other party perform, or
  466. confirmation that you are expecting the other party to perform,
  467. the indicated option.
  468.  
  469. DON'T indicates the demand that the other party stops performing,
  470. or confirmation that you are no longer expecting the other party
  471. to perform, the indicated option.
  472.  
  473. select will/won't 
  474. If set, activates the will/won't flag 
  475.  
  476. will/won't 
  477. 1 means WILL, 0 means WON'T. 
  478.  
  479. WILL indicates the desire to begin performing, or confirmation
  480. that the indicated options are being used. 
  481.  
  482. WON'T indicates the refusal to perform, or continue performing,
  483. the indicated option. 
  484.  
  485.  
  486. Rao, Lanphier                                     Page 11
  487.  
  488.  
  489. INTERNET-DRAFT          RTSP              October 9, 1996
  490.  
  491.  
  492. At a minimum, the response to a OPTION is to reply with the
  493. desire to perform NONE of the requested options.
  494.  
  495. The Working Group or IETF needs to define and regulate the
  496. registration process for OPTIONS sets. Currently, no sets are
  497. defined.
  498.  
  499.  
  500. GOODBYE
  501. Sent only by the client to politely close the RTSP session.
  502.  
  503. The client sends this message to the server to indicate that it
  504. is done with its requests and wants to terminate the session.
  505.  
  506.  0                   1                   2                   3
  507.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  508. +-------------------------------+-------------------------------+
  509. |                         tag (GOODBYE)                         |
  510. +-------------------------------+-------------------------------+
  511.  
  512. 3.2 OBJECT MESSAGES
  513.  
  514. These messages are sent on the stream control session (one of
  515. which exists for  each stream). They a used to request objects,
  516. set transport mechanism, and control data delivery.
  517.  
  518. FETCH 
  519. This is the first message sent on a new stream control session.
  520. It requests an object of a given name. If the object exists, and
  521. the client is permitted to access it, the server accepts the
  522. request and sends a STREAM_HEADER message to the client. If the
  523. object is non-existent or access is not allowed, the appro-
  524. priate error message is sent to the client.
  525.  
  526. The client uses this message to request an object (for example,
  527. an audio clip) from the server. The object is specified as an URL.
  528.  
  529.  
  530. Rao, Lanphier                                     Page 12
  531.  
  532.  
  533. INTERNET-DRAFT          RTSP              October 9, 1996
  534.  
  535.  
  536.  0                   1                   2                   3
  537.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  538. +-------------------------------+-------------------------------+
  539. |                          tag (FETCH)                          |
  540. +-------------------------------+-------------------------------+
  541. |                    Bandwidth (Bits per second)                |
  542. +-------------------------------+-------------------------------+
  543. |          Max Number of Hops   |     Request Flags       |F|M|N|
  544. +-------------------------------+-------------------------------+
  545. |                                                               |
  546. \                       URL (null-terminated)                   \
  547. |                                                               |
  548. +-------------------------------+-------------------------------+
  549.  
  550. Bandwidth
  551. Specifies the client's estimate of the bandwidth (in bits per
  552. sec) it has available for a particular stream. The exact bit rate
  553. of the stream is provided by the STREAM_HEADER message from the
  554. server. If the server refuses the request based on insufficient
  555. bandwidth, then the server sends the appropriate error message.
  556.  
  557. Max Number of Hops
  558. Specifies the maximum number of hops. A hop is a connection
  559. between Client, Server or Proxy. For example, the are three hops
  560. for passing through two proxies and connecting to a server. If
  561. set to 0xFFFF, then the number of hops is unlimited.
  562.  
  563. Request Flags
  564.    F - Fresh bit, used to override Proxy Cache
  565.    M - Multicast capable
  566.    N - No Rate (rate unlimited file transfer, used only for TCP.
  567. This could be used for transfering non-real time data, such as 
  568. metafiles)
  569.  
  570. URL - Universal Resource Locator 
  571. Specifies a null-terminated string which identifies the location for the 
  572. object.(i.e. RTSP://host-name:port/filename)
  573.  
  574.  
  575. Rao, Lanphier                                     Page 13
  576.  
  577.  
  578. INTERNET-DRAFT          RTSP              October 9, 1996
  579.  
  580.  
  581. STREAM_HEADER
  582.  
  583. This message is sent in response to a successful FETCH message.
  584. It provides the basic information about the stream such as rate,
  585. generic type, and last modification time. 
  586.  
  587.  0                   1                   2                   3
  588.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  589. +-------------------------------+-------------------------------+
  590. |                        tag (stream-header)                    |
  591. +-------------------------------+-------------------------------+
  592. |                       Generic Type (family)                   |
  593. +-------------------------------+-------------------------------+
  594. |                    Bit Rate (Bits per second)                 |
  595. +-------------------------------+-------------------------------+
  596. |                     Last Modification Time                    |
  597. +-------------------------------+-------------------------------+
  598. |                           Reserved                            |
  599. +-------------------------------+-------------------------------+
  600. |                      Length (milliseconds)                    |
  601. +-------------------------------+-------------------------------+
  602. |                      Max Packet size (bytes)                  |
  603. +---------------+---------------+---------------+---------------+
  604. |                       Flags                      x|L|C|H|A|U|M|
  605. +---------------+---------------+---------------+---------------+
  606.          
  607. Generic type (family)
  608. Specifies the type of family, such as RTSP_Audio, etc. Currently,
  609. RTSP_Audio is defined in the appendix.
  610.  
  611. Bandwidth
  612. Specifies the rate or bandwidth of the stream in bits per second.
  613. It is set to 0 if non-realtime.
  614.  
  615. Last Modification Time
  616. Specifies the last time the object was modified. The specified
  617. time is seconds since Jan 01 1970(UTC).
  618.  
  619. Reserved
  620. Reserved for future use. 
  621.  
  622. Length
  623. Specifies the stream length in miliseconds. It is 0 if the object
  624. is live or if it is non-realtime.
  625.  
  626.  
  627. Rao, Lanphier                                     Page 14
  628.  
  629.  
  630. INTERNET-DRAFT          RTSP              October 9, 1996
  631.  
  632.  
  633. Max Packet Size
  634. Specifies the maximum packet size in bytes that the server
  635. supports for the stream.
  636.  
  637.           Flags 
  638.              x: Unicast available
  639.              L: Live : if set, the stream is live and there is no 
  640.                 concept of position.
  641.              C: Copy : if set, means that the client can save it.
  642.              H: Cached : if set, the object is cached on a proxy.
  643.              A: if set, stream can be cached by the client
  644.              U: UDP Okay : if set, the stream can be sent via a 
  645.                 unreliable channel.
  646.              M: Stream is available via Multicast, and a
  647.                 SET_TRANSPORT message follows providing this
  648.                 information
  649.  
  650. SET_TRANSPORT
  651.  
  652. This message is sent to set the delivery mechanism for a stream. 
  653. The client uses this message to request the transport used for
  654. the data transfer. 
  655.  
  656. The server can use this message to inform the client about multicast availabil-
  657. ity (this is the only instance the server sends this message).
  658.  
  659.  0                   1                   2                   3
  660.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  661. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  662. |                     tag (SET_TRANSPORT)                       |
  663. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  664. |C|                              |            ChannelID         | 
  665. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  666. |           synchronization source (SSRC) identifier            |
  667. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  668. /                   Transport specific fields                   /
  669. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  670.  
  671. C flag : This flag specifies the type of header/framing.
  672.  
  673.      C =  0  :  Standard RTP header
  674.      C =  1  :  Compressed/Extensible RTP header
  675.  
  676.  
  677. Rao, Lanphier                                     Page 15
  678.  
  679.  
  680. INTERNET-DRAFT          RTSP              October 9, 1996
  681.  
  682.  
  683. SSRC: 32 bits 
  684.  
  685. Identifies the synchronization source to be associated with the
  686. data. This can be used for de-multiplexing by the client of data
  687. received on the same port.
  688.  
  689. Channel ID
  690.  
  691. Transport channel  Fixed RTP header   Compressed RTP header  Channel ID   
  692.  
  693. Unicast UDP          Yes                     Yes                0              
  694.  
  695. Multicast UDP        Yes                     Yes                1
  696.  
  697. SCP                  Yes                     Yes                2
  698.  
  699. SCP - compressed     Yes                     Yes                3 
  700.  
  701. Note : The client may not send a channel ID of 1. This is sent by the server 
  702. only. 
  703.  
  704. Transport Spcific Fields
  705.  
  706. Channel ID 0:
  707.  
  708.  0                   1                   2                   3
  709.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  710. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  711. |                             port                              |
  712. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  713.  
  714. Port
  715. Specifies the port number on which the stream should be sent. 
  716.  
  717. Channel ID 2,3 :
  718.  
  719.  0                   1                   2                   3
  720.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  721. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  722. |                session ID                     |   (reserved)  |
  723. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  724.  
  725.  
  726. Rao, Lanphier                                     Page 16
  727.  
  728.  
  729. INTERNET-DRAFT          RTSP              October 9, 1996
  730.  
  731.  
  732. Session ID
  733. Specifies the SCP session ID that should be associated with this
  734. stream. 
  735.  
  736. Channel ID 1
  737.  
  738.  0                   1                   2                   3
  739.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  740. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  741. |                             port                              |
  742. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  743. |                            address                            |
  744. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  745.  
  746. Port
  747. Specifies the port number on which the stream is sent. 
  748.  
  749. Address
  750. Specifies the multicast group address where the data is available. 
  751.  
  752. SET_SPEED
  753.  
  754. This advisory message sets the speed at which the server delivers
  755. data to the client, contingent on the server's ability and desire
  756. to serve the file at the given speed. Implementation by the
  757. server is optional. The default is the bit rate of the stream.
  758.  
  759.  0                   1                   2                   3
  760.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  761. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  762. |                         tag(SET_SPEED )                       |
  763. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  764. |                         (reserved)                          |F|
  765. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  766. |                            speed                              |
  767. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  768.  
  769.  
  770. Rao, Lanphier                                     Page 17
  771.  
  772.  
  773. INTERNET-DRAFT          RTSP              October 9, 1996
  774.  
  775.  
  776. Speed
  777. Send speed as a ratio. The speed is relative to the normal speed
  778. for the stream, as expressed as a ratio of speed divided by 65536
  779. (i.e. 2^16). For example, speed is 65536 for real-time delivery,
  780. 32768 (2^15) for half-speed delivery, and 131072 (2^17) for
  781. double-speed delivery.  A speed of zero is invalid. 
  782.  
  783. F
  784. If F is set, sends the data as fast as possible. This feature
  785. only works on a TCP data connection. 
  786.  
  787. PLAY_RANGE 
  788.  
  789. This message tells the server to start sending data via the
  790. previously set transport mechanism. The two fields, From and To,
  791. specify the range in milliseconds. If the the "To" field is zero,
  792. it signifies the end of the stream. If the "To" field is non-
  793. zero, it should be greater than the value specified in 
  794. the "From" field.
  795.  
  796.  0                   1                   2                   3
  797.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  798. +-------------------------------+-------------------------------+
  799. |                         tag (PLAY_RANGE)                      |
  800. +-------------------------------+-------------------------------+
  801. |                          From (in ms)                         |
  802. +-------------------------------+-------------------------------+
  803. |                           To (in ms)                          |
  804. +-------------------------------+-------------------------------+
  805.  
  806.  
  807. Rao, Lanphier                                     Page 18
  808.  
  809.  
  810. INTERNET-DRAFT          RTSP              October 9, 1996
  811.  
  812.  
  813. STREAM_SYNC 
  814.  
  815. This message is sent by the server to the client in response to
  816. the PLAY_RANGE message. It informs the client of the first
  817. expected sequence number, and in case of some delivery types, the
  818. first expected timestamp.
  819.  
  820.  0                   1                   2                   3
  821.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  822. +-------------------------------+-------------------------------+
  823. |                         tag (STREAM_SYNC)                     |
  824. +-------------------------------+-------------------------------+
  825. |       Sequence Number         |           Reserved            | 
  826. +-------------------------------+-------------------------------+
  827. |                         Start Time                            |
  828. +---------------------------------------------------------------+
  829.           
  830. Sequence Number
  831. Specifies where the new data starts. This number should be far
  832. enough away from the last sequence number sent so that old
  833. packets can be detected and rejected. 
  834.  
  835. Start Time
  836. Specifies the offset (in milliseconds) relative to the origin of
  837. the first packet that will be sent.
  838.  
  839. SET_BLOCK_SIZE
  840.  
  841. This is an advisory message sent from the client to the server
  842. setting the transport packet size. The server truncates it to the
  843. closest multiple of the minimum media-specific block size or
  844. overrides it with the media specific size if necessary.
  845.  
  846.  
  847. Rao, Lanphier                                     Page 19
  848.  
  849.  
  850. INTERNET-DRAFT          RTSP              October 9, 1996
  851.  
  852.  
  853.  0                   1                   2                   3
  854.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  855. +-------------------------------+-------------------------------+
  856. |                       tag (SET_BLOCKSIZE)                     |
  857. +-------------------------------+-------------------------------+
  858. |                          Block Size                           |
  859. +-------------------------------+-------------------------------+
  860.  
  861. Block Size
  862. Specifies the size of the block in bytes.
  863.  
  864. STOP
  865. This messages tells the server to stop sending. This is used for
  866. `pause' operation, and the server is to keep track of the stream
  867. position in order to `resume' play when a resume command is given. 
  868.  
  869.    0                   1                   2                   3
  870.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  871. +-------------------------------+-------------------------------+
  872. |                           tag (STOP)                          |
  873. +-------------------------------+-------------------------------+
  874.      
  875. RESUME
  876. This message tells the server to resume sending from the position
  877. it was stopped at with the STOP message. If no STOP message was
  878. sent prior to RESUME, the messages is ignored. 
  879.  
  880.  0                   1                   2                   3
  881.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  882. +-------------------------------+-------------------------------+
  883. |                           tag (RESUME)                        |
  884. +-------------------------------+-------------------------------+
  885.  
  886. SEND_REPORT 
  887.  
  888. This message is sent by the server to the client requesting
  889. statistics on data reception. At a minimum, the client is
  890. required to reply to the message of type 1 (PING) indicating that
  891. it is receiving data.
  892.  
  893.  
  894. Rao, Lanphier                                     Page 20
  895.  
  896.  
  897. INTERNET-DRAFT          RTSP              October 9, 1996
  898.  
  899.  
  900.     0                   1                   2                   3
  901.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  902. +-------------------------------+-------------------------------+
  903. |                         tag (SEND_REPORT)                     |
  904. +-------------------------------+-------------------------------+
  905. |                           Report Type                         |
  906. +-------------------------------+-------------------------------+
  907.           
  908. Report Type:
  909.                1 - PING,
  910.                2 - Text Message 
  911.                3 - Reception Report
  912.  
  913. REPORT 
  914. Sent by the client to the server in response to the SEND_REPORT
  915. message. or otherwise. 
  916.  
  917.  0                   1                   2                   3
  918.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  919. +-------------------------------+-------------------------------+
  920. |                           tag (REPORT)                        |
  921. +-------------------------------+-------------------------------+
  922. |                           Report Type                         |
  923. +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
  924. |               Report Specific Fields                          |
  925. +-------------------------------+-------------------------------+
  926.         
  927. Report Type:
  928.                1 - PING 
  929.                2 - Text Message, 
  930.                3 - Reception Report
  931.  
  932. PING Report (1) Report Specific Fields (NONE, just respond with
  933.                 Report type 1) 
  934. Text Message (2) Report Specific Fields 
  935.  
  936.  0                   1                   2                   3
  937.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  938. +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
  939. |        Text String (Null Terminated)                          |
  940. +-------------------------------+-------------------------------+
  941.                 Text String (Null terminated). 
  942. Reception Report (3) - Report specific fields 
  943.  
  944.  
  945. Rao, Lanphier                                     Page 21
  946.  
  947. INTERNET-DRAFT          RTSP              October 9, 1996
  948.  
  949.  
  950.  0                   1                   2                   3
  951.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  952. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  953. |            Packets Received  |         Packets Lost           |
  954. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  955. |            Lagging           |         Buffer occupancy       |
  956. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  957.  
  958. Packets Received 
  959. Specifies the number of packets received since last report
  960.  
  961. Packets Lost
  962. Specifies the number of packets lost since the last report. 
  963.  
  964. Lagging 
  965. Specifies that the buffer level is below (1), or above the
  966. desired level (0).   
  967.  
  968. Buffer occupancy 
  969.  
  970. Specifies the number of milliseconds below or above the desired
  971. level. 
  972.  
  973. ERROR
  974.  
  975. This message is sent by the server to the client in case of an
  976. abnormal condition. It includes a numeric error code which is
  977. defined later in this document and an optional null-terminated
  978. error string.
  979.  
  980. Error is sent by the server to report an error to the client.
  981.  
  982.  
  983. Rao, Lanphier                                     Page 22
  984.  
  985.  
  986. INTERNET-DRAFT          RTSP              October 9, 1996
  987.  
  988.  
  989.  0                   1                   2                   3
  990.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  991. +-------------------------------+-------------------------------+
  992. |                           tag (ERROR)                         |
  993. +-------------------------------+-------------------------------+
  994. |F|                          error code                         |
  995. +-------------------------------+-------------------------------+
  996. |                                                               |
  997. \                   Error String (null-terminated)              \
  998. |                                                               |
  999. +-------------------------------+-------------------------------+
  1000.        
  1001. F:(one bit) Fatal Error Flag
  1002. Is used to tell the client it must terminate the session.
  1003.  
  1004. error codes:
  1005.                200 - Success 
  1006.                400 - FETCH failure; no such object exists 
  1007.                401 - FETCH failure; fetch refused 
  1008.                402 - SEND_RANGE out of bounds 
  1009.                403 - Incompatible protocol version 
  1010.                404 - SET_TRANSPORT failure; bad port specified 
  1011.                405 - Feed gone - live feed closed 
  1012.                406 - Can't do that on non-live feed 
  1013.                407 - Request not supported 
  1014.                408 - Request refused due to bandwidth mismatch 
  1015.                      (e.g. Insufficient Client Bandwidth)
  1016.                500 - Unspecified server-side problem 
  1017.                501 - Server running low on resources and cannot
  1018.                      satisfy request 
  1019.  
  1020.  
  1021. Rao, Lanphier                                     Page 23
  1022.  
  1023.  
  1024. INTERNET-DRAFT          RTSP              October 9, 1996
  1025.  
  1026.  
  1027. UDP_RESEND  
  1028.  
  1029. This messages is sent by the client to request retransmission
  1030. packets of specific sequence numbers. The service of the request
  1031. at the server end is optional.
  1032.  
  1033.  0                   1                   2                   3
  1034.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1035. +-------------------------------+-------------------------------+
  1036. |                        tag (UDP_RESEND)                       |
  1037. +-------------------------------+-------------------------------+
  1038. |       Sequence Number         |         Number of Packets     |
  1039. +-------------------------------+-------------------------------+
  1040.  
  1041. Sequence Number:
  1042. Specifies the first packet that needs to be resent. 
  1043.  
  1044. Number of Packets:
  1045. Specifies the number of packets that need to be resent, beginning
  1046. with the above sequence number. 
  1047.  
  1048. 3.3 CUSTOM MESSAGES/EVENTS 
  1049.  
  1050. These messages are intended to provide a general notification
  1051. system from the server to the client or from the client to the
  1052. server. The message could be sent on the control or object
  1053. session. An example of using the custom message is when the
  1054. server announces the availability of a new stream, or drives the
  1055. client's web browser to a particular location. 
  1056.  
  1057. The message includes payload type and payload. Currently, defined
  1058. payload types are NewURL(1) and GotoURL(2). Implementation of
  1059. this custom messaging system is optional for both client and
  1060. server, and vendor specific payload types could be added as
  1061. necessary.
  1062.  
  1063.  
  1064. Rao, Lanphier                                     Page 24
  1065.  
  1066.  
  1067. INTERNET-DRAFT          RTSP              October 9, 1996
  1068.  
  1069.  
  1070. EVENT_NOTIFY
  1071.  
  1072.  0                   1                   2                   3
  1073.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1074. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1075. |                        tag(EVENT_NOTIFY)                      |
  1076. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1077. |                         Payload Type                          |
  1078. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1079. |                                                               |
  1080. /                            Payload                            / 
  1081. |                                                               |
  1082. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1083.          
  1084. Payload Type
  1085. Specifies one of the currently defined payload types. For
  1086. example, NewURL(1) and GotoURL(2). 
  1087.  
  1088. Payload 
  1089. For the previous two payload types, specifies the URL.
  1090.  
  1091. 3.4 MEDIA SPECIFIC OPTIONS AND EXTENSION MECHANISM
  1092.  
  1093. RTSP provides an extensible way for the client to query and set
  1094. media-specific parameters and to set media-specific parameters
  1095. for the stream. This is done via the GET_PARAM and PARAM_REPLY
  1096. messages. The GET_PARAM message includes a request ID, family
  1097. identifier and a parameter identifier. The PARAM_REPLY mes-
  1098. sage includes the corresponding request ID, and a variable length
  1099. reply data payload.
  1100.  
  1101. GET_PARAM
  1102.  
  1103.   0                   1                   2                   3
  1104.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1105. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1106. |                      tag (GET_PARAM)                          |
  1107. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1108. |                          REQUEST_ID                           |
  1109. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1110. |                         FAMILY_ID                             |
  1111. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1112. |                        PARAMETER_ID                           |
  1113. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1114.  
  1115. REQUEST_ID
  1116. Is a 32 bit number used to reference this request, must be non-
  1117. zero.
  1118.  
  1119. FAMILY_ID
  1120. Currently, RTSP_Audio (Family 1) is defined in Appendix C.
  1121.  
  1122. PARAMETER_ID
  1123. Specified the parameter ID within the family. These are defined
  1124. for the in Appendix C.
  1125.  
  1126. Rao, Lanphier                                     Page 25
  1127.  
  1128.  
  1129. INTERNET-DRAFT          RTSP              October 9, 1996
  1130.  
  1131.  
  1132. PARAM_REPLY
  1133.  
  1134.  0                   1                   2                   3
  1135.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1136. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1137. |                      tag(PARAM_REPLY)                         |
  1138. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1139. |                          REQUEST_ID                           |
  1140. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1141. |                         FAMILY_ID                             |
  1142. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1143. |                        PARAMETER_ID                           |
  1144. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1145. |                         DATA_TYPE                             |
  1146. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1147. /                            DATA                               /
  1148. |                                                               |
  1149. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1150.       
  1151. For a list of currently defined family and parameter identifiers,
  1152. see Appendix C. An example of use of these messages is available
  1153. in the next section. Data types are String(0), Integer(1), and
  1154. Opaque data(2).
  1155.  
  1156. This message can be sent by the server to the client, even if the
  1157. client has not sent a request. The client must be prepared to
  1158. handle this. In this case, the REQUEST_ID is 0x0.
  1159.  
  1160. REQUEST_ID
  1161. Is a 32 bit number used to reference this request, must be non-
  1162. zero.
  1163.  
  1164. FAMILY_ID
  1165. Currently, RTSP_Audio (Family 1) is defined in Appendix C.
  1166.  
  1167. PARAMETER_ID
  1168.  
  1169. Specified the parameter ID within the family. These are defined
  1170. for the in Appendix C.
  1171.  
  1172. Rao, Lanphier                                     Page 26
  1173.  
  1174.  
  1175. INTERNET-DRAFT          RTSP              October 9, 1996
  1176.  
  1177.  
  1178. PARAM_REFUSE
  1179. If the server does not support the requested parameter or family,
  1180. it sends a ParamRefuse, whose format is as below:
  1181.  
  1182.  0                   1                   2                   3
  1183.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1184. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1185. |                     tag(PARAM_REFUSE)                         |
  1186. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1187. |                          REQUEST_ID                           |
  1188. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1189. |                         FAMILY_ID                             |
  1190. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1191. |                        PARAMETER_ID                           |
  1192. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1193. |                         ERROR_CODE                            |
  1194. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1195.  
  1196. REQUEST_ID
  1197. Is a 32 bit number used to reference this request, must be non-
  1198. zero.
  1199.  
  1200. FAMILY_ID
  1201. Currently, RTSP_Audio (FAMILY_ID1) is defined in Appendix C.
  1202.  
  1203. PARAMETER_ID
  1204. Specified the parameter ID within the family. Currently, the
  1205. RTSP_Audio is defined in Appendix C.
  1206.  
  1207. ERROR_CODE: As defined earlier.
  1208.  
  1209.  
  1210. Rao, Lanphier                                     Page 27
  1211.  
  1212.  
  1213. INTERNET-DRAFT          RTSP              October 9, 1996
  1214.  
  1215.  
  1216. SET_PARAM
  1217.  
  1218. Using the same principle as GET_PARAM, a media-specific option
  1219. for the stream can be set using the SET_PARAM message. Examples
  1220. of an option include encryption, custom encoding or quality
  1221. levels. The server replies with a SET_PARAM_REPLY or PARAM_REFUSE.
  1222.  
  1223.  0                   1                   2                   3
  1224.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1225. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1226. |                     tag (SET_PARAM)                           |
  1227. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1228. |                          REQUEST_ID                           |
  1229. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1230. |                         FAMILY_ID                             |
  1231. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1232. |                        PARAMETER_ID                           |
  1233. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1234. |                                                               |
  1235. /                            DATA                               /
  1236. |                                                               |
  1237. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1238.  
  1239. REQUEST_ID
  1240. Is a 32 bit number used to reference this request, must be non-
  1241. zero.
  1242.  
  1243. FAMILY_ID
  1244. Currently, RTSP_Audio (Family 1) is defined in Appendix C.
  1245.  
  1246. PARAMETER_ID
  1247. Specified the parameter ID within the family. These are defined
  1248. for the in Appendix C.
  1249.  
  1250. DATA
  1251. Specifies the payload specific to the family and parameters.
  1252.  
  1253.  
  1254. Rao, Lanphier                                     Page 28
  1255.  
  1256.  
  1257. INTERNET-DRAFT          RTSP              October 9, 1996
  1258.  
  1259.  
  1260. 4.0 EXAMPLES/APPLICATION NOTE
  1261.  
  1262. Example of use of GetParam to request and play an audio file:
  1263.  
  1264. CLIENT                                SERVER
  1265.  
  1266. CONTROL_SCP: HELLO--------------------------->
  1267.  
  1268. <---------------------------CONTROL_SCP:HELLO
  1269.  
  1270. <--------------------------- CONTROL_SCP:ID
  1271.  
  1272. (OPTIONAL) CONTROL_SCP:ID_RESP--------------------->
  1273.  
  1274. STREAM_SCP_0: FETCH----------------------------->
  1275.  
  1276. STREAM_SCP_0: GETPARAM-------------------------->
  1277.  
  1278. STREAM_SCP_0: GETPARAM-------------------------->
  1279.  
  1280. <-------------------------  STREAM_SCP_0:STREAM_HEADER
  1281.  
  1282. <-------------------------  STREAM_SCP_0:PARAM_REPLY
  1283.  
  1284. <-------------------------  STREAM_SCP_0:PARAM_REPLY
  1285.  
  1286. STREAM_SCP_0: SETPARAM(eg.encryption) ----------------> 
  1287.  
  1288. <--------------------------  STREAM_SCP_0:PARAM_REPLY
  1289.  
  1290. STREAM_SCP_0: SET_TRANSPORT(RTP)---------------->
  1291.  
  1292. STREAM_SCP_0: PLAY_RANGE(a,b)------------------->
  1293.  
  1294. <--------------------------- STREAM_SCP_0:STREAM_SYNC
  1295.  
  1296. <--------------------------- Data on UDP channel
  1297.  
  1298.     
  1299.  
  1300. Example of use of custom message:
  1301.  
  1302. CLIENT                                            SERVER
  1303.  
  1304. CONTROL_SCP: HELLO---------------------------->
  1305.  
  1306. <----------------------------CONTROL_SCP:HELLO
  1307.  
  1308. STREAM_SCP_0: FETCH ------------------->
  1309.  
  1310. <--------------------------  STREAM_SCP_0:STREAM_HEADER
  1311.  
  1312.                            
  1313.  
  1314. STREAM_OBJECT_SCP_0: SET_TRANSPORT(RTP)-------->
  1315.  
  1316. STREAM_OBJECT_SCP_0: PALY_RANGE(a,b)----------------->
  1317.  
  1318. <--------------------------- STREAM_SCP_0:STREAMSYNC
  1319.  
  1320. <--------------------------- Data on UDP channel 
  1321.  
  1322. <--------------------------- CONTROL_SCP: EVENT_NOTIFY(NewURL)
  1323.  
  1324. STREAM_OBJECT_SCP_1: FETCH--------------------->
  1325.  
  1326. <-------------------------  STREAM_SCP_1:STREAM_HEADER
  1327.  
  1328.                         
  1329.  
  1330. STREAM_SCP_1: SET_TRANSPORT(RTP)---------------->
  1331.  
  1332. STREAM_SCP_1: SEEK(a,b)------------------------->
  1333.  
  1334. <--------------------------------- STREAM_SCP_1:STREAM_SYNC
  1335.  
  1336. <------------------------------- Data on UDP channel 
  1337.  
  1338.  
  1339.  
  1340. Rao, Lanphier                                      Page 29
  1341.  
  1342.  
  1343. INTERNET-DRAFT          RTSP              October 9, 1996
  1344.  
  1345.  
  1346. 5.0 REFERENCES:
  1347.  
  1348. [1] H. Shulzrinne, S. Casner, R. Frederick, and S. McCanne, "RTP:
  1349.         A Transport Protocol for real-time applications." RFC 1889
  1350.  
  1351. [2] Simon Spero, Session Control Protocol(SCP). 
  1352.  
  1353. [3] J. Postel, J. Reynolds, "Telnet Protocol Spefication.", RFC 854 
  1354.  
  1355.  
  1356.  
  1357.  
  1358. 6.0 APPENDIXES
  1359.  
  1360.  
  1361.  
  1362. 6.1 APPENDIX A - Data packets
  1363.  
  1364.      
  1365.  
  1366. The following are the types of data packet formats.
  1367.  
  1368. RTP: The format of the UDP packet is a standard RTP packet, as
  1369. per RFC 1889. This is a description of how the RTP packet is used
  1370. by RTSP. Complete generalized descriptions of these fields can be
  1371. found in RFC 1889. 
  1372.  
  1373.  0                   1                   2                   3
  1374.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1375. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1376. |V=2|P|X|  CC   |M|     PT      |       sequence number         |
  1377. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1378. |                           timestamp                           |
  1379. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1380. |           synchronization source (SSRC) identifier            |
  1381. +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  1382. |            contributing source (CSRC) identifiers             |
  1383. |                             ....                              |
  1384. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1385.  
  1386. The first twelve octets are present in every RTP packet, while
  1387. the list of CSRC identifiers usually will not be present (though
  1388. may be used when broadcasting an RTP conferencing session, for
  1389. instance). The fields have the following meaning:
  1390.  
  1391. Version (V): 2 bits 
  1392. This field identifies the version of RTP. The version used by
  1393. this specification is two (2). 
  1394.  
  1395. Padding (P): 1 bit 
  1396. If the padding bit is set, the packet contains one or more
  1397. additional padding octets at the end which are not part of the
  1398. payload. The last octet of the padding contains a count of how
  1399. many padding octets should be ignored. 
  1400.  
  1401. Extension (X): 1 bit 
  1402. Not used. Set to zero for RTP compatibility. CSRC count (CC): 4
  1403. bits. The CSRC count contains the number of CSRC identifiers that
  1404. follow the fixed header. 
  1405.  
  1406.  
  1407. Rao, Lanphier                                     Page 30
  1408.  
  1409.  
  1410. INTERNET-DRAFT          RTSP              October 9, 1996
  1411.  
  1412.  
  1413. Marker (M): 1 bit 
  1414. In RTSP, this designates the block boundary. This is a point at
  1415. which a client can start decoding the stream. 
  1416.  
  1417. Payload type (PT): 7 bits 
  1418. Each stream uses a payload type allocated dynamically between 96
  1419. and 127, to remain consistent with the dynamic mappings in the
  1420. audio-video profile (RFC 1890). 
  1421.  
  1422. Sequence number: 16 bits 
  1423. The sequence number increments by one for each RTP data packet
  1424. sent, and may be used by the receiver to detect packet loss and
  1425. to restore packet sequence. The initial value of the sequence
  1426. number is random (unpredictable) to make known plaintext attacks
  1427. on encryption more difficult, even if the source itself does 
  1428. not encrypt, because the packets may flow through a translator
  1429. that does. 
  1430.  
  1431. Timestamp: 32 bits 
  1432. The timestamp is a tick mark which reflects the sampling instant
  1433. of the first octet in the RTP data packet. The clock frequency is
  1434. dependent on the format of data carried as payload. 
  1435.  
  1436. SSRC: 32 bits 
  1437. The SSRC field identifies the synchronization source associated
  1438. with the data. This identifier is chosen with the intent that no
  1439. two synchronization sources within the same RTSP session will
  1440. have the same SSRC. 
  1441.  
  1442. CSRC list: 0 to 15 items, 32 bits each 
  1443. The CSRC list identifies the contributing sources for the payload
  1444. contained in this packet. The number of identifiers is given by
  1445. the CC field. If there are more than 15 contributing sources,
  1446. only 15 may be identified. 
  1447.  
  1448.  
  1449. Rao, Lanphier                                     Page 31
  1450.  
  1451.  
  1452. INTERNET-DRAFT          RTSP              October 9, 1996
  1453.  
  1454.  
  1455. Compressed RTP
  1456.  
  1457.  0                   1                   2                   3
  1458.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1459. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1460. |v|M|t|s| SSRC  |   sequence number             |timestamp (opt)...
  1461. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1462. ...              |
  1463. +-+-+-+-+-+-+-+-+
  1464.  
  1465. version (v): 1 bit 
  1466. If this is 1, the rest of this packet is standard RTP, and we can
  1467. treat it as such. If it is 0, the rest of the packet is defined
  1468. as follows. 
  1469.  
  1470. marker (M): 1 bit 
  1471. In RTSP, this designates the block boundary. This is a point at
  1472. which a client can start decoding the stream. 
  1473.  
  1474. timestamp lower bits compression bit (t): 1 bit 
  1475. This number specifies the existence of the least-significant two
  1476. bytes of the timestamps. If this bit is not set, the value of
  1477. these bytes are calculated based some media-specific method
  1478. (probably using the sequence number). If this bit is set, the
  1479. value of these bytes are given in this packet. 
  1480.  
  1481. The upper bits are determined based on the probable value given
  1482. the sequence number. This compression scheme does not work for
  1483. packets that are spaced out at intervals greater than roughly 64
  1484. seconds. 
  1485.  
  1486. sequence number inclusion bit(s) 
  1487. This bit is for compatibility with reliable, sequenced delivery
  1488. mechanisms, such as SCP. This should always be set to 1. 
  1489.  
  1490.  
  1491. Rao, Lanphier                                     Page 32
  1492.  
  1493.  
  1494. INTERNET-DRAFT          RTSP              October 9, 1996
  1495.  
  1496. SSRC: 4 bits or 36 bits 
  1497. The SSRC field identifies the synchronization source associated
  1498. with the data. This identifier is chosen with the intent that no
  1499. two synchronization sources within the same RTSP session will
  1500. have the same SSRC. 
  1501.  
  1502. This is 4 bits unless set to 15 (1111), in which case it expands
  1503. to 36 bits, and the lower 32 bits are the actual SSRC. 
  1504.  
  1505. sequence number: 16 bits 
  1506. The sequence number increments by one for each RTP data packet
  1507. sent, and may be used by the receiver to detect packet loss and
  1508. to restore packet sequence. The initial value of the sequence
  1509. number is random (unpredictable) to make known-plaintext attacks
  1510. on encryption more difficult, even if the source itself does 
  1511. not encrypt, because the packets may flow through a translator
  1512. that does. 
  1513.  
  1514.  
  1515. 6.2 APPENDIX B - Session Control Protocol (SCP)
  1516.  
  1517. This document was originally written by Simon Spero for the HTTP-
  1518. NG project. It has been slightly editied and clarified.
  1519.  
  1520. Several heavily used Internet applications such as FTP, GOPHER,
  1521. and HTTP use a protocol model in which every transaction
  1522. requires a separate TCP connection. Since clients normally issue
  1523. multiple requests to the same server, this model is quite
  1524. inefficient, as it incurs all the connection start up costs for
  1525. every single request. 
  1526.  
  1527. SCP is a simple protocol which lets a server and client have
  1528. multiple conversations over a single TCP connection. 
  1529.  
  1530.  
  1531. Rao, Lanphier                                     Page 33
  1532.  
  1533.  
  1534. INTERNET-DRAFT          RTSP              October 9, 1996
  1535.  
  1536. Definitions
  1537.  
  1538. A session is a virtual stream of data carried within the single
  1539. TCP connection. It is independent of any other session within the
  1540. same connection.
  1541.  
  1542. A session identifier is a unique number which is used to specify
  1543. which session a particular block of data is associated with.
  1544.  
  1545. Session flag names are borrowed from TCP. The name SYN means
  1546. "open" in SCP. The name FIN means "finish" or "close" in SCP. The
  1547. name RST means "reset" in SCP. PUSH indicates the end of a
  1548. segment.
  1549.  
  1550. Services
  1551.  
  1552. SCP's main service is dialogue control. This service allows
  1553. either end of the connection to establish multiple virtual
  1554. sessions over a single transport connection. SCP also allows a
  1555. sender to indicate message boundaries, and allows a receiver to
  1556. reject an incoming session. 
  1557.  
  1558. Design goals 
  1559.  
  1560. SCP allows data to be sent with the session establishment; the
  1561. recepient does not confirm successful connection establishment,
  1562. but may reject unsuccessful attempts. This simplifies the design
  1563. of the protocol, and removes the latency required for a con-
  1564. firmed operation. 
  1565.  
  1566.  
  1567. Rao, Lanphier                                     Page 34
  1568.  
  1569.  
  1570. INTERNET-DRAFT          RTSP              October 9, 1996
  1571.  
  1572.  
  1573. Low overhead 
  1574.  
  1575. SCP has a fixed overhead of 8 bytes per segment. This overhead is
  1576. only incurred once per segment, instead of once per packet. 
  1577.  
  1578. Simple design 
  1579.  
  1580. The session protocol should be simple enough to implement for a
  1581. single application. 
  1582.  
  1583. Protocol Description
  1584.  
  1585. Header Format: 
  1586.  
  1587.  0                   1                   2                   3
  1588.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1589. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1590. |0|0|0|0| flags |               session ID                      |
  1591. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1592. |                        session length                         |
  1593. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1594. |                                                               |
  1595. /                             data                              /
  1596. |                                                               |
  1597. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1598.                
  1599. flags:
  1600.                     0x1 : SYN
  1601.                     0x2 : FIN
  1602.                     0x4 : RST
  1603.                     0x8 : PUSH
  1604.  
  1605.  
  1606. Rao, Lanphier                                     Page 35
  1607.  
  1608.  
  1609. INTERNET-DRAFT          RTSP              October 9, 1996
  1610.  
  1611.  
  1612. Protocol Operation
  1613.  
  1614. Session ID allocation
  1615. Each session is allocated a session identifier. Session
  1616. Identifiers below 1024 are reserved. Session IDs allocated by
  1617. clients are even; those allocated byservers, odd. 
  1618.  
  1619.  
  1620. Session establishment
  1621. A new session is established by setting the SYN bit in the first
  1622. message sent on that channel. 
  1623.  
  1624. Graceful release
  1625.  
  1626. A session is ended by sending a message with the FIN bit set.
  1627. Each end of a connection may be closed independently. 
  1628.  
  1629. Disgraceful release
  1630. A session may be terminated by sending a message with the RST bit
  1631. set. All pending data for that session should be discarded 
  1632.  
  1633. Message boundaries
  1634. A message boundary is marked by sending a message with the PUSH
  1635. bit set. The boundary is set at the final octet in this message,
  1636. including that octet. 
  1637.  
  1638. Compressed Header SCP
  1639.  
  1640.  +-+-+-+-+-+-+-+-+-----//------+-------//-------+---//---+
  1641.  |1|P| IDL | LNL | session ID  | segment length |  data  |
  1642.  +-+-+-+-+-+-+-+-+-----//------+-------//-------+---//---+
  1643.    
  1644.  
  1645. Rao, Lanphier                                     Page 36
  1646.  
  1647.  
  1648. INTERNET-DRAFT          RTSP              October 9, 1996
  1649.  
  1650.  
  1651. P: 1 bit 
  1652. Push bit. This denotes a message boundry, which is set at the
  1653. final octet in this message. 
  1654.  
  1655. IDL: 3 bit 
  1656. Length of the session ID field (as described below). 
  1657.  
  1658. LNL: 3 bits 
  1659. Length of the session length field (as described below). 
  1660.  
  1661. session ID: Variable number of bits, depending on IDL field 
  1662. Identifier for this session. The session ID value is relative to
  1663. 1024, which is the minimum non-reserved value. 
  1664.  
  1665.  segment length: Variable number of bits, depending on LNL field.
  1666. Length of the payload in bytes. 
  1667.  
  1668. IDL and LNL values: 3 bits 
  1669.  
  1670.                value  Length of Session ID or Segment Length field
  1671.                0x0    use previous value 
  1672.                0x1    4 bits
  1673.                0x2    8 bits
  1674.                0x3    12 bits
  1675.                0x4    16 bits
  1676.                0x5    24 bits
  1677.                0x6    32 bits
  1678.                0x7    64 bits
  1679.        
  1680. IDL and LNL values should be chosen so that byte alignment of the
  1681. packet is guaranteed. 
  1682.  
  1683.  
  1684. Rao, Lanphier                                     Page 37
  1685.  
  1686.  
  1687. INTERNET-DRAFT          RTSP              October 9, 1996
  1688.  
  1689.  
  1690. 6.3 APPENDIX C - RTSP -Audio (Family ID =1 ) 
  1691.              Format descriptor (Parameter=1)
  1692.           
  1693.  0                   1                   2                   3
  1694.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1695. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1696. |                          CODEC ID                             |
  1697. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1698. |          NumChannels          |     Bits/Sample               |
  1699. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1700. |                      Samples Per Second                       |   
  1701. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1702. |      Average Frame Size       |        Maximum Frame Size     |   
  1703. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1704. |                      Samples Per Frame                        |   
  1705. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1706. |P|       Frames Per Packet     |        Extra Bytes            |   
  1707. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1708. |                      Number Of Frames                         |   
  1709. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1710. |                      CODEC-specific Data                      |   
  1711. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1712. :                             :                                 :
  1713. :                             :                                 :
  1714. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1715.    
  1716. The above structure describes a generic compressed audio stream
  1717. for the RTSP Audio Family.
  1718.  
  1719. CODEC ID: The CODEC ID uniquely identifies the codec which was
  1720. used to generate this audio data. CODEC ID's in the range 0x00
  1721. through 0xffff are reserved for ACM (Audio Compression Manager
  1722. native to Microsoft Windows Operating systems) compatible/
  1723. interoperable codecs.
  1724.  
  1725.  
  1726. Rao, Lanphier                                     Page 38
  1727.  
  1728.  
  1729. INTERNET-DRAFT          RTSP              October 9, 1996
  1730.      
  1731.  
  1732. NumChannels: Use 1 for mono, 2 for stereo 
  1733.  
  1734. Bits/Sample: Number of bits per sample as specified by the codec.
  1735. Codecs which do not need or do not have a well defined value for
  1736. this parameter may set this to zero.
  1737.  
  1738. Samples Per Second: Playback rate for each channel in samples per second (hertz).
  1739.  
  1740. Average Frame Size: Frame is the smallest unit of encoded audio
  1741. data that can be streamed from the server. Average Frame Size
  1742. represents the typical size (in bytes) of a frame. This family
  1743. does not support non byte-aligned frames.
  1744.  
  1745.     
  1746. Maximum Frame Size: Size in bytes of the largest frame. For
  1747. constant bit rate codecs, this value is the same as the Average
  1748. Frame Size.
  1749.  
  1750.  Samples Per Frame: Number of samples of audio data encoded in
  1751. each frame. This family does not support variable duration frames.
  1752.  
  1753. P: If P is not set, then the audio data is planar and the client 
  1754. has the option to request data packets of size which are
  1755. multiples of the average frame size. If P is set, the stream is
  1756. packetized (usually for variable bit rate data and live feeds),
  1757. then the size of the data packet is defined by frame size and 
  1758. frames per packet (described below).
  1759.  
  1760. Frames Per Packet: For packetized formats, this represents the
  1761. number of frames in every data packet. For planar formats, this
  1762. is a hint to the client regarding the server preference.
  1763.  
  1764. Extra Bytes: This specifies the number of bytes of codec specific
  1765. data that follow the fixed header.
  1766.  
  1767. Number of Frames: Total number of frames in the audio stream. For
  1768. non-seekable streams (e.g. live feeds), this should be set to
  1769. zero.
  1770.  
  1771. Rao, Lanphier                                     Page 39
  1772.  
  1773.  
  1774. INTERNET-DRAFT          RTSP              October 9, 1996
  1775.  
  1776.  
  1777. 6.4 APPENDIX D - RTSP - Audio (Family ID =1 ) : Annotations
  1778. (Parameter=2)
  1779.  
  1780. This payload data enables the server to communicate additional
  1781. information about the stream to the client. Examples of such
  1782. information include the authorof the clip, the clip name,
  1783. copyright information, creation date etc. The payload data is
  1784. organized as a list of information chunks. Each such chunk has an 
  1785. identifier, length of the chunk and the actual data itself.
  1786.  
  1787.  0                   1                   2                   3
  1788.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1789. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1790. |                        Number of chunks                       |
  1791. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1792. |                   Chunk Identifier (Chunk 0)                  |
  1793. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1794. |                    Number of Bytes (Chunk 0)                  |
  1795. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1796. |                       Chunk Data (Chunk 0)                    |
  1797. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1798. :                                 :                             :
  1799. :                                 :                             :
  1800. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1801. |                   Chunk Identifier (Chunk n-1)                |
  1802. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1803. |                    Number of Bytes (Chunk n-1)                |
  1804. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1805. |                       Chunk Data (Chunk n-1)                  |
  1806. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1807. :                                 :                             :
  1808. :                                 :                             :
  1809. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1810.  
  1811.  
  1812. Rao, Lanphier                                     Page 40
  1813.  
  1814.  
  1815. INTERNET-DRAFT          RTSP              October 9, 1996
  1816.  
  1817.  
  1818. Chunk Identifier
  1819. This is a four character code identifying the chunk. For example,
  1820. `I''C''O''P' is used for copyright information which is
  1821. stored as a null terminated string. `I''N''A''M' is used for the
  1822. name of the audio clip. `I''U''R''L' serves to pass the URL for
  1823. the CODEC installer. The client should use this URL if it 
  1824. encounters a clip compressed with an unknown CODEC.
  1825.  
  1826. Any chunk with an unrecognized four character code should be
  1827. ignored by the client.
  1828.  
  1829. Number of Bytes
  1830.  
  1831. Represents the length of the chunk data. The chunk data should be
  1832. 16 bit aligned.
  1833.  
  1834. Rao, Lanphier                                     Page 41
  1835.  
  1836.  
  1837. INTERNET-DRAFT          RTSP              October 9, 1996
  1838.  
  1839.  
  1840. 6.5 APPENDIX E - Authors
  1841.  
  1842. Contacts: 
  1843.  
  1844. At Netscape:              Anup Rao     <anup@netscape.com>
  1845. At Progressive Networks:  Rob Lanphier <robla@prognet.com>
  1846.  
  1847.  
  1848. The following authors contributed to this document:
  1849.  
  1850. Martin Dunsmuir  <martind@prognet.com>
  1851.   General Manager Server Products,
  1852.   Progressive Networks
  1853.   1111 Third Avenue, Suite 2900
  1854.   Tel. 206 674 2700 (main #)
  1855.  
  1856. John K. Ho  <johnkho@netscape.com>
  1857.   Project Manager
  1858.   Netscape Communications Corp.
  1859.   685 E. Middlefield Rd.
  1860.   Mountain View, CA, 94043
  1861.   Tel. 415 254 1900 (main #)
  1862.  
  1863. Rob Lanphier  <robla@prognet.com>
  1864.   Program Manager
  1865.   Progressive Networks
  1866.  
  1867. Eduardo F. Llach  <eduardo@netscape.com>
  1868.   Manager, Media Server Team, 
  1869.   Netscape Communications Corp.
  1870.  
  1871. Rob McCool  <robm@netscape.com>
  1872.   Technical Team Leader, Media Server
  1873.   Netscape Communications Corp.
  1874.  
  1875. Igor Plotnikov  <igor@netscape.com>
  1876.   Technical Team Leader, Media Server 
  1877.   Netscape Communications Corp.
  1878.  
  1879.  
  1880. Rao, Lanphier                                     Page 42
  1881.  
  1882.  
  1883. INTERNET-DRAFT          RTSP              October 9, 1996
  1884.  
  1885.  
  1886. Anup Rao
  1887.   Member, Technical Staff 
  1888.   Netscape Communications Corp.
  1889.  
  1890. Pinaki Shah
  1891.   Member, Technical Staff 
  1892.   Netscape Communications Corp.
  1893.  
  1894. Alexander Sokolsky
  1895.   Member, Technical Staff
  1896.   Netscape Communications Corp.
  1897.  
  1898. Dale Stammen
  1899.   Lead Saxophone
  1900.   Progressive Networks
  1901.  
  1902. John Francis Stracke
  1903.   Senior LiveMedia Architect
  1904.   Netscape Communications Corp.
  1905.  
  1906.  
  1907.  
  1908.  
  1909.  
  1910.  
  1911.  
  1912. Rao, Lanphier                                     Page 43
  1913.  
  1914.  
  1915.