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