idnits 2.17.1 draft-ietf-mmusic-rtsp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 462 has weird spacing: '...sts for each ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1997) is 9814 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 1188 looks like a reference -- Missing reference section? '2' on line 1191 looks like a reference -- Missing reference section? '3' on line 1193 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Anup Rao, Netscape Communications 2 Rob Lanphier, Progressive Networks 4 SUBMITTED: 26th November 1996 Expires: 26th May 1997 6 Real Time Streaming Protocol (RTSP) 7 9 STATUS OF THIS MEMO 11 This is an Internet-Draft. Internet-Drafts are working documents of 12 the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. Internet-Drafts are draft documents 15 valid for a maximum of six months and may be updated, replaced, or 16 obsoleted by other documents at any time. It is inappropriate to use 17 Internet-Drafts as reference material or to cite them other than as 18 "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "lid-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 mannari.oz.au (Pacific Rim), ds.internic.net (Us East Coast), or 24 ftp.isi.edu (US West Coast). 26 Prior to the expiration of this draft, the list of open issues may be 27 found at the following URL: 29 http://www.prognet.com/prognet/ra/openissues.html 31 This contains a list of issues that have been discussed on the MMUSIC 32 mailing list (confctrl). Many of the points brought up have a rather 33 holistic effect on the whole document (such as discussions of 34 converting the protocol to a text-based protocol, or breaking this 35 draft up into several drafts), while other have rather localized 36 effect (Appendix C changes). The points that are localized will be 37 be pointed out in various parts of this draft. 39 ABSTRACT 41 The Real Time Streaming Protocol, or RTSP, is an application-level 42 protocol for control over the delivery of data with real-time 43 properties. RTSP provides an extensible framework to enable 44 controlled, on-demand delivery of real- time data, such as audio and 45 video. Sources of data can include both live data feeds and stored 46 clips. This protocol is intended to control multiple data delivery 47 sessions, provide a means for choosing delivery channels such as UDP, 48 multicast UDP and TCP, and delivery mechanisms based upon RTP (RFC 49 1889). RTSP uses the Session Control Protocol (SCP) (see appendix) to 50 allow the use of a single TCP connection between the client and 51 server for controlling delivery of one or more streams of data. 53 Rao, Lanphier Page 1 54 [Note: see "Use Of UDP For Delivery Of Control Messages" in the "Open 55 Issues" document for discussion of alternative control delivery 56 (http://www.prognet.com/prognet/rt/openissues.html)] 58 TABLE OF CONTENTS 60 1.0 INTRODUCTION 61 2.0 DOCUMENT CONVENTIONS 62 3.0 PROTOCOL DESCRIPTION 63 3.1 Connection Messages 64 3.2 Object Messages 65 3.3 Custom Messages/Events 66 3.4 Media specific options and Extension mechanism 67 4.0 EXAMPLES/APPLICATION NOTE 68 5.0 REFERENCES 69 6.0 APPENDIXES 70 6.1 Appendix A - Data Packets 71 6.2 Appendix B - Session Control Protocol (SCP) 72 6.3 Appendix C - RTSP Audio Format 73 6.4 Appendix D - RTSP Audio Annotations 74 6.5 Appendix E - Authors 76 1.0 INTRODUCTION 78 This document describes the Real Time Streaming Protocol, or RTSP. 80 The RTSP provides mechanisms to: 81 -Request delivery of real-time data 82 -Request a specific transport type and destination for 83 the delivery of the data 84 -Request information about the data in a format- 85 specific fashion 86 -Start, stop, and pause the delivery of the data 87 -Provide random access to various portions of the data 88 (where applicable) 90 RTSP uses TCP for delivery of control messages, and allows for a 91 variety of delivery options for the data including both multicast and 92 unicast UDP based on RTP(RFC 1889), and TCP where applicable. RTSP 93 uses the Session Control Protocol (see appendix) to allow the use of 94 a single TCP connection between the client and server for controlling 95 delivery of one or more streams of data. The RTSP specifically uses 96 one SCP session to deliver control messages and in addition, a new 97 SCP session might be opened for each real-time object delivered. 99 Rao, Lanphier Page 2 100 While the protocol is designed for the streaming of real- time data 101 regardless of its format, it also provides mechanisms to inquire 102 about format specific information (compression type, data rate, 103 compression-type specific headers and frame boundaries). 104 Considerations for each peer arising from these features are 105 discussed later in the document. Three typical categories of data 106 whose delivery could be controlled with RTSP include: 108 1. Real-time stored clips 109 This category comprises all real-time recordings (primarily 110 audio/video). Examples include web sites with audio narration, 111 stored audio recordings, and video recordings. A typical end-user 112 application would be an audio/video store site providing excerpts 113 from its collection on-demand. 115 2. Real-time live feeds 116 This category comprises real-time data which is fed in live at the 117 server site rather than being pre-recorded. Examples of this usage 118 include a press conference, a live internet radio station, or a 119 televised shuttle launch. 121 3. Non real-time stored data 122 This category comprises non-real-time data of any MIME type, similar 123 to data served by HTTP servers. This data is provided over a new SCP 124 session. While HTTP servers would serve this kind of data in most 125 cases, it might be advanta- geous to serve non-real-time data with 126 RTSP. This is typically true of non-real-time data pertaining to 127 real- time data being served; for example, a text track playing along 128 with audio/video. This category is meant to provide the capability of 129 serving non-real-time data through RTSP, and it is strongly 130 recommended that it be used only when advantageous over existing 131 mechanisms. 133 [Note: Other scenarios that don't fall into the above categories may 134 be discussed in the "Open Issues" document 135 (http://www.prognet.com/prognet/rt/openissues.html)] 137 2.0 DOCUMENT CONVENTIONS 139 The following conventions are used throughout this document: 141 Byte Order and Alignment 142 All integer fields are carried in network byte order, where the most 143 significant byte is sent first. Integers are aligned on their natural 144 length: 16 bit integers on even byte boundary, 32 bit integers on 4 145 byte boundary and so on. 147 Rao, Lanphier Page 3 148 Definitions 150 Stream 151 A stream is data of a distinct type that is sent from server to 152 client at a rate defined by the server, even if more bandwidth is 153 available. For a typical video broadcast, for example, one stream 154 could consist of the video signal, one stream could consist of the 155 audio data, and one stream could contain the closed caption 156 information. In most cases, each stream is served at the rate that it 157 should be rendered by the client. 159 Global Control Session 160 The SCP session with a well-known session ID, used for exchange of 161 connection messages described later in this document. 163 Stream Control Session 164 An SCP session established for each stream, used for 165 exchange of object messages described later in this 166 document. 168 URL 169 A Uniform Resource Locator or URL is a unique identifier 170 that describes a resource on the Internet. The syntax for 171 URLs is defined by RFC 1738. 173 3.0 PROTOCOL DESCRIPTION 175 Two classes of messages exist in RTSP; those sent on the 176 Global control session, termed connection messages and 177 those sent on the Stream control session, termed object 178 messages. Some messages might fall in both categories. 180 3.1 Connection messages 182 Connection messages are used to negotiate protocol version and 183 possibly client identity. This is common to all streams 184 requested on the connection. 186 Rao, Lanphier Page 4 187 HELLO 189 Upon connection, the client sends a HELLO message to the server 190 informing it of its version and desire to establish a RTSP 191 session. The server replies with a HELLO message. The server 192 need not wait for the clients HELLO message before sending its 193 own. The message includes protocol version, and optional 194 character string denoting the user- agent(to be specified). The 195 communication continues in the lower of the exchanged 196 versions. If the two sides cannot speak this common version, the 197 connection is closed. 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | HELLO | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Major | Minor | Sub Protocol | Reserved | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | | 207 / User Agent (Optional) / 208 | | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Major Version 212 Specifies the major RTSP version. 214 Minor Version 215 Specifies the minor RTSP version within the major version. 217 Sub Protocol 218 Specifies the sub-protocol spoken by the sender. For normal 219 client-server communication, this should be 0. 221 Reserved 222 For future use. 224 User Agent 225 Is an optional null-terminated character string sent by the 226 client to provide information like the client name, machine type, 227 OS etc. 229 Rao, Lanphier Page 5 230 ID 232 This message is sent by either a server or a client. The 233 recipient of this message is asked to prove its identity. A 234 number of different schemes are possible, the simplest of which 235 uses a password. More complicated schemes can cause a one time 236 challenge and response mechanism. Multiple challenge response 237 steps are possible and implemenation dependent. 239 A separate ID message allows a server to service a number of 240 different classes of users. The ID message can be sent at any 241 time during the session or may be sent once per URL, depending on 242 how a service is configured. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | tag(ID) | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | key type | (reserved) | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | | 252 / authentication key / 253 | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Key type 257 Specifies the authentication key type. Authentication of 258 different strengths might be required in different 259 situations. This field allows a choice of authentication. It is 260 up to the client and server to negotiate what level of 261 authentication is used. Note that different services might be 262 available at different authentication levels. 264 Authentication key 265 Specifies the key that authenticates the sender. The standard key 266 types and proper responses will be specified in an extension to 267 this document. 269 ID_RESP 270 This message is sent in response to an ID message. The entity 271 issuing the ID message closes the TCP connection if the response 272 is not valid. 274 Rao, Lanphier Page 6 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | tag(ID_RESP) | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | key type | response code | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 / response data / 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Key type 288 Specifies the authentication key type. Authentication of 289 different strength may be required in different situations. This 290 field allows a choice of authentication. It is up to the client 291 and server to negotiate what level of authentication is used. 292 Note that different services might be available at different 293 authentication levels. 295 Response code 296 Specifies one of the two possible responses to an ID message: 297 OK 298 Authentication type recognized, response follows. 300 UNKNOWN 301 Unknown type, ordered list of authentication types follows 302 (can be a null list). 304 Response data 305 Specifies the response, depending on the response code. If OK, 306 then this is the key that authenticates the sender, and the 307 format is dictated by the authentication type. If UNKNOWN, then 308 this is a list of 16-bit response types that are acceptable to 309 the recipient. 311 The standard key types and proper responses will be specified in 312 an extension to this document. 314 REDIRECT 316 A redirect message informs the client that it must connect to 317 another server location. When received on the Global control 318 session, it should be made effective as specified by offset. The 319 message can also be sent on a Stream control session, in which 320 case it it relative to the stream. 322 Rao, Lanphier Page 7 323 0 1 2 3 324 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 325 +-------------------------------+-------------------------------+ 326 | tag (REDIRECT) | 327 +-------------------------------+-------------------------------+ 328 | Offset | 329 +-------------------------------+-------------------------------+ 330 | | 331 / URL / 332 | | 333 +-------------------------------+-------------------------------+ 335 Offset 336 On the Stream control session, specifies the position (in 337 milliseconds) in the media stream at which time the 338 redirection is effective. If received on the global control 339 session, it means that the server is not available after 340 this time. 342 URL 343 Is a null-terminated string that identifies the new location for 344 the object. This URL is similar to the one specified in the 345 original FETCH request, described later in this document. 347 OPTIONS 349 This message is used to negotiate additional functionality. This 350 can be sent by the client or the server. This is provided as an 351 extension mechanism to extend the protocol without changing the 352 version number. Set 0 refers to the global set of options, a 353 universally-agreed upon set. Implementors can use this to 354 negotiate replacements for messages in the current specification; 355 however, all implementations must be able to support the core 356 messages defined here, and be prepared not to use an option 357 should the other implementation not be prepared to support the 358 given option. The maximum size of an option set is 64. 360 This is defined in the spirit of the TELNET protocol (RFC 854), 361 which provides a further explanation of how different 362 implementations may interoperate using this mechanism. 364 Rao, Lanphier Page 8 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | tag (OPTIONS) | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | option set | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | highest option number | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |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| 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 / / 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 |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| 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Option set 382 Implementors can specify an option set to use for adding custom 383 extensions. In addition, as the protocol matures, certain 384 options may be accepted as universal to all clients,which will be 385 placed in the reserved range of option sets. The following ranges 386 of options are reserved: 388 Option set Purpose 389 ----------- ------------------------------------ 391 0 This is a universally accepted set 392 of options 394 0x1-0xFFFF Reserved for later allocation 396 0x10000-0xFFFFFFFF Custom extensions (i.e. vendor or 397 organization specific) 399 Highest option number 400 Specifies the highest option number that is set or unset. It is 401 used to calculate the length of the bit vectors that follow. This 402 list is zero indexed. 404 Rao, Lanphier Page 9 405 s.d.s.w 406 s.d.s.w 407 ^ ^ ^ ^ 408 | | | | 409 select do/don't ----------+ | | | 410 do/don't -------------------+ | | 411 select will/won't ------------+ | 412 will/won't ---------------------+ 414 select do/don't 415 If set, activates the do/don't flag 417 do/don't 418 If set to 1, means DO and if set to 0, means DON'T. 420 DO indicates the request that the other party perform, or 421 confirmation that you are expecting the other party to perform, 422 the indicated option. 424 DON'T indicates the demand that the other party stops performing, 425 or confirmation that you are no longer expecting the other party 426 to perform, the indicated option. 428 select will/won't 429 If set, activates the will/won't flag 431 will/won't 432 1 means WILL, 0 means WON'T. 434 WILL indicates the desire to begin performing, or confirmation 435 that the indicated options are being used. 437 WON'T indicates the refusal to perform, or continue performing, 438 the indicated option. 440 At a minimum, the response to a OPTION is to reply with the 441 desire to perform NONE of the requested options. 443 The Working Group or IETF needs to define and regulate the 444 registration process for OPTIONS sets. Currently, no sets are 445 defined. 447 GOODBYE 448 Sent only by the client to politely close the RTSP session. 450 The client sends this message to the server to indicate that it 451 is done with its requests and wants to terminate the session. 453 0 1 2 3 454 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 455 +-------------------------------+-------------------------------+ 456 | tag (GOODBYE) | 457 +-------------------------------+-------------------------------+ 459 3.2 OBJECT MESSAGES 461 These messages are sent on the stream control session (one of 462 which exists for each stream). They a used to request objects, 463 set transport mechanism, and control data delivery. 465 FETCH 466 This is the first message sent on a new stream control session. 467 It requests an object of a given name. If the object exists, and 468 the client is permitted to access it, the server accepts the 469 request and sends a STREAM_HEADER message to the client. If the 470 object is non-existent or access is not allowed, the appro- 471 priate error message is sent to the client. 473 The client uses this message to request an object (for example, 474 an audio clip) from the server. The object is specified as an URL. 476 0 1 2 3 477 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 478 +-------------------------------+-------------------------------+ 479 | tag (FETCH) | 480 +-------------------------------+-------------------------------+ 481 | Bandwidth (Bits per second) | 482 +-------------------------------+-------------------------------+ 483 | Max Number of Hops | Request Flags |F|M|N| 484 +-------------------------------+-------------------------------+ 485 | | 486 / URL (null-terminated) / 487 | | 488 +-------------------------------+-------------------------------+ 490 Bandwidth 491 Specifies the client's estimate of the bandwidth (in bits per 492 sec) it has available for a particular stream. The exact bit rate 493 of the stream is provided by the STREAM_HEADER message from the 494 server. If the server refuses the request based on insufficient 495 bandwidth, then the server sends the appropriate error message. 497 Max Number of Hops 498 Specifies the maximum number of hops. A hop is a connection 499 between Client, Server or Proxy. For example, the are three hops 500 for passing through two proxies and connecting to a server. If 501 set to 0xFFFF, then the number of hops is unlimited. 503 Request Flags 504 F - Fresh bit, used to override Proxy Cache 505 M - Multicast capable 506 N - No Rate (rate unlimited file transfer, used only for TCP. 507 This could be used for transfering non-real time data, such as 508 metafiles) 510 URL - Universal Resource Locator 512 Specifies a null-terminated string which identifies the 513 location for the object (i.e. RTSP://host-name:port/filename) 515 STREAM_HEADER 517 This message is sent in response to a successful FETCH message. 518 It provides the basic information about the stream such as rate, 519 generic type, and last modification time. 521 0 1 2 3 522 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 523 +-------------------------------+-------------------------------+ 524 | tag (STREAM_HEADER) | 525 +-------------------------------+-------------------------------+ 526 | Generic Type (family) | 527 +-------------------------------+-------------------------------+ 528 | Bit Rate (Bits per second) | 529 +-------------------------------+-------------------------------+ 530 | Last Modification Time | 531 +-------------------------------+-------------------------------+ 532 | Reserved | 533 +-------------------------------+-------------------------------+ 534 | Length (milliseconds) | 535 +-------------------------------+-------------------------------+ 536 | Max Packet size (bytes) | 537 +---------------+---------------+---------------+---------------+ 538 | Flags x|L|C|H|A|U|M| 539 +---------------+---------------+---------------+---------------+ 541 Generic type (family) 542 Specifies the type of family, such as RTSP_Audio, etc. Currently, 543 RTSP_Audio is defined in the appendix. 545 Bandwidth 546 Specifies the rate or bandwidth of the stream in bits per second. 547 It is set to 0 if non-realtime. 549 Last Modification Time 550 Specifies the last time the object was modified. The specified 551 time is seconds since Jan 01 1970(UTC). 553 Reserved 554 Reserved for future use. 556 Length 557 Specifies the stream length in miliseconds. It is 0 if the object 558 is live or if it is non-realtime. 560 Max Packet Size 561 Specifies the maximum packet size in bytes that the server 562 supports for the stream. 564 Flags 565 x: Unicast available 566 L: Live : if set, the stream is live and there is no 567 concept of position. 568 C: Copy : if set, means that the client can save it. 569 H: Cached : if set, the object is cached on a proxy. 570 A: if set, stream can be cached by the client 571 U: UDP Okay : if set, the stream can be sent via a 572 unreliable channel. 573 M: Stream is available via Multicast, and a 574 SET_TRANSPORT message follows providing this 575 information 577 [Note: There has been discussion of providing this 578 information in a session description that is loaded via 579 HTTP or some other mechanism prior to the RTSP connection 580 being established. See "Metafiles/Session Descriptions" in 581 http://www.prognet.com/prognet/rt/openissues.html] 583 SET_TRANSPORT 585 This message is sent to set the delivery mechanism for a stream. 586 The client uses this message to request the transport used for 587 the data transfer. 589 The server can use this message to inform the client about multicast 590 availability (this is the only instance the server sends this 591 message). 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | tag (SET_TRANSPORT) | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 |C| | ChannelID | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | synchronization source (SSRC) identifier | 601 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 602 / Transport specific fields / 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 C flag : This flag specifies the type of header/framing. 607 C = 0 : Standard RTP header 608 C = 1 : Compressed/Extensible RTP header 610 SSRC: 32 bits 612 Identifies the synchronization source to be associated with the 613 data. This can be used for de-multiplexing by the client of data 614 received on the same port. 616 Channel ID 618 Transport channel Fixed RTP header Compressed RTP header Channel ID 620 Unicast UDP Yes Yes 0 622 Multicast UDP Yes Yes 1 624 SCP Yes Yes 2 626 SCP - compressed Yes Yes 3 628 Note : The client may not send a channel ID of 1. This is 629 sent by the server only. 631 Transport Spcific Fields 633 Channel ID 0: 635 0 1 2 3 636 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 637 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 638 | port | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 Port 642 Specifies the port number on which the stream should be sent. 644 Channel ID 2,3 : 646 0 1 2 3 647 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 648 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 649 | session ID | (reserved) | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 Session ID 653 Specifies the SCP session ID that should be associated with this 654 stream. 656 Channel ID 1 658 0 1 2 3 659 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 660 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 661 | port | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | address | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 Port 667 Specifies the port number on which the stream is sent. 669 Address 670 Specifies the multicast group address where the data is 671 available. 673 [Note: There is some debate over the best way to address 674 RTP header compression in the "Compressed RTP section" of 675 the "RTSP Open Issues" document. 676 (see http://www.prognet.com/prognet/rt/openissues.html)] 678 [Note: There has also been debate about what level of RTP 679 support to provide. It has been suggested that a server 680 should be able to stream directly into an RTP based 681 conference which may contain clients that are not 682 necessarily RTSP-aware, so long as the requesting 683 conference client provides control connection proxying. 684 See the "RTSP Open Issues" document section titled "Joining 685 Into Existing Conferences" 686 (http://www.prognet.com/prognet/rt/openissues.html)] 688 SET_SPEED 690 This advisory message sets the speed at which the server delivers 691 data to the client, contingent on the server's ability and desire 692 to serve the file at the given speed. Implementation by the 693 server is optional. The default is the bit rate of the stream. 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | tag(SET_SPEED ) | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | (reserved) |F| 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | speed | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Speed 706 Send speed as a ratio. The speed is relative to the normal 707 speed for the stream, as expressed as a ratio of speed 708 divided by 65536 (i.e. 2^16). For example, speed is 65536 709 for real-time delivery, 32768 (2^15) for half-speed 710 delivery, and 131072 (2^17) for double-speed delivery. A 711 speed of zero is invalid. 713 F 714 If F is set, sends the data as fast as possible. This feature 715 only works on a TCP data connection. 717 PLAY_RANGE 719 This message tells the server to start sending data via the 720 previously set transport mechanism. The two fields, From and To, 721 specify the range in milliseconds. If the the "To" field is zero, 722 it signifies the end of the stream. If the "To" field is non- 723 zero, it should be greater than the value specified in 724 the "From" field. 726 0 1 2 3 727 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 728 +-------------------------------+-------------------------------+ 729 | tag (PLAY_RANGE) | 730 +-------------------------------+-------------------------------+ 731 | From (in ms) | 732 +-------------------------------+-------------------------------+ 733 | To (in ms) | 734 +-------------------------------+-------------------------------+ 735 STREAM_SYNC 737 This message is sent by the server to the client in response to 738 the PLAY_RANGE message. It informs the client of the first 739 expected sequence number, and in case of some delivery types, the 740 first expected timestamp. 742 0 1 2 3 743 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 744 +-------------------------------+-------------------------------+ 745 | tag (STREAM_SYNC) | 746 +-------------------------------+-------------------------------+ 747 | Sequence Number | Reserved | 748 +-------------------------------+-------------------------------+ 749 | Start Time | 750 +---------------------------------------------------------------+ 752 Sequence Number 753 Specifies where the new data starts. This number should be far 754 enough away from the last sequence number sent so that old 755 packets can be detected and rejected. 757 Start Time 758 Specifies the offset (in milliseconds) relative to the origin of 759 the first packet that will be sent. 761 SET_BLOCK_SIZE 763 This is an advisory message sent from the client to the server 764 setting the transport packet size. The server truncates it to the 765 closest multiple of the minimum media-specific block size or 766 overrides it with the media specific size if necessary. 768 0 1 2 3 769 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 770 +-------------------------------+-------------------------------+ 771 | tag (SET_BLOCKSIZE) | 772 +-------------------------------+-------------------------------+ 773 | Block Size | 774 +-------------------------------+-------------------------------+ 776 Block Size 777 Specifies the size of the block in bytes. 779 STOP 780 This messages tells the server to stop sending. This is used for 781 `pause' operation, and the server is to keep track of the stream 782 position in order to `resume' play when a resume command is given. 784 0 1 2 3 785 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 786 +-------------------------------+-------------------------------+ 787 | tag (STOP) | 788 +-------------------------------+-------------------------------+ 790 RESUME 791 This message tells the server to resume sending from the position 792 it was stopped at with the STOP message. If no STOP message was 793 sent prior to RESUME, the messages is ignored. 795 0 1 2 3 796 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 797 +-------------------------------+-------------------------------+ 798 | tag (RESUME) | 799 +-------------------------------+-------------------------------+ 801 SEND_REPORT 803 This message is sent by the server to the client requesting 804 statistics on data reception. At a minimum, the client is 805 required to reply to the message of type 1 (PING) indicating that 806 it is receiving data. 808 0 1 2 3 809 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 810 +-------------------------------+-------------------------------+ 811 | tag (SEND_REPORT) | 812 +-------------------------------+-------------------------------+ 813 | Report Type | 814 +-------------------------------+-------------------------------+ 816 Report Type: 817 1 - PING, 818 2 - Text Message 819 3 - Reception Report 821 REPORT 822 Sent by the client to the server in response to the SEND_REPORT 823 message. or otherwise. 825 0 1 2 3 826 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 827 +-------------------------------+-------------------------------+ 828 | tag (REPORT) | 829 +-------------------------------+-------------------------------+ 830 | Report Type | 831 +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ 832 | Report Specific Fields | 833 +-------------------------------+-------------------------------+ 835 Report Type: 836 1 - PING 837 2 - Text Message, 838 3 - Reception Report 840 PING Report (1) Report Specific Fields (NONE, just respond with 841 Report type 1) 842 Text Message (2) Report Specific Fields 844 0 1 2 3 845 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 846 +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ 847 | Text String (Null Terminated) | 848 +-------------------------------+-------------------------------+ 849 Text String (Null terminated). 850 Reception Report (3) - Report specific fields 852 0 1 2 3 853 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 854 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 855 | Packets Received | Packets Lost | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Lagging | Buffer occupancy | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Packets Received 861 Specifies the number of packets received since last report 863 Packets Lost 864 Specifies the number of packets lost since the last report. 866 Lagging 867 Specifies that the buffer level is below (1), or above the 868 desired level (0). 870 Buffer occupancy 872 Specifies the number of milliseconds below or above the desired 873 level. 875 ERROR 877 This message is sent by the server to the client in case of an 878 abnormal condition. It includes a numeric error code which is 879 defined later in this document and an optional null-terminated 880 error string. 882 Error is sent by the server to report an error to the client. 884 0 1 2 3 885 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 886 +-------------------------------+-------------------------------+ 887 | tag (ERROR) | 888 +-------------------------------+-------------------------------+ 889 |F| error code | 890 +-------------------------------+-------------------------------+ 891 | | 892 / Error String (null-terminated) / 893 | | 894 +-------------------------------+-------------------------------+ 896 F:(one bit) Fatal Error Flag 897 Is used to tell the client it must terminate the session. 899 error codes: 900 200 - Success 901 400 - FETCH failure; no such object exists 902 401 - FETCH failure; fetch refused 903 402 - SEND_RANGE out of bounds 904 403 - Incompatible protocol version 905 404 - SET_TRANSPORT failure; bad port specified 906 405 - Feed gone - live feed closed 907 406 - Can't do that on non-live feed 908 407 - Request not supported 909 408 - Request refused due to bandwidth mismatch 910 (e.g. Insufficient Client Bandwidth) 911 500 - Unspecified server-side problem 912 501 - Server running low on resources and cannot 913 satisfy request 915 UDP_RESEND 917 This messages is sent by the client to request retransmission 918 packets of specific sequence numbers. The service of the request 919 at the server end is optional. 921 0 1 2 3 922 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 923 +-------------------------------+-------------------------------+ 924 | tag (UDP_RESEND) | 925 +-------------------------------+-------------------------------+ 926 | Sequence Number | Number of Packets | 927 +-------------------------------+-------------------------------+ 929 Sequence Number: 930 Specifies the first packet that needs to be resent. 932 Number of Packets: 933 Specifies the number of packets that need to be resent, beginning 934 with the above sequence number. 936 3.3 CUSTOM MESSAGES/EVENTS 938 These messages are intended to provide a general notification 939 system from the server to the client or from the client to the 940 server. The message could be sent on the control or object 941 session. An example of using the custom message is when the 942 server announces the availability of a new stream, or drives the 943 client's web browser to a particular location. 945 The message includes payload type and payload. Currently, defined 946 payload types are NewURL(1) and GotoURL(2). Implementation of 947 this custom messaging system is optional for both client and 948 server, and vendor specific payload types could be added as 949 necessary. 951 EVENT_NOTIFY 953 0 1 2 3 954 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 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | tag(EVENT_NOTIFY) | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Payload Type | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | | 961 / Payload / 962 | | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 Payload Type 966 Specifies one of the currently defined payload types. For 967 example, NewURL(1) and GotoURL(2). 969 Payload 970 For the previous two payload types, specifies the URL. 972 3.4 MEDIA SPECIFIC OPTIONS AND EXTENSION MECHANISM 974 RTSP provides an extensible way for the client to query and set 975 media-specific parameters and to set media-specific parameters 976 for the stream. This is done via the GET_PARAM and PARAM_REPLY 977 messages. The GET_PARAM message includes a request ID, family 978 identifier and a parameter identifier. The PARAM_REPLY mes- 979 sage includes the corresponding request ID, and a variable length 980 reply data payload. 982 GET_PARAM 984 0 1 2 3 985 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 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | tag (GET_PARAM) | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | REQUEST_ID | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | FAMILY_ID | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | PARAMETER_ID | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 REQUEST_ID 996 Is a 32 bit number used to reference this request, must be non- 997 zero. 999 FAMILY_ID 1000 Currently, RTSP_Audio (Family 1) is defined in Appendix C. 1002 PARAMETER_ID 1003 Specified the parameter ID within the family. These are defined 1004 for the in Appendix C. 1006 PARAM_REPLY 1008 0 1 2 3 1009 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 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | tag(PARAM_REPLY) | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | REQUEST_ID | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | FAMILY_ID | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | PARAMETER_ID | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | DATA_TYPE | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 / DATA / 1022 | | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 For a list of currently defined family and parameter identifiers, 1026 see Appendix C. An example of use of these messages is available 1027 in the next section. Data types are String(0), Integer(1), and 1028 Opaque data(2). 1030 This message can be sent by the server to the client, even if the 1031 client has not sent a request. The client must be prepared to 1032 handle this. In this case, the REQUEST_ID is 0x0. 1034 REQUEST_ID 1035 Is a 32 bit number used to reference this request, must be non- 1036 zero. 1038 FAMILY_ID 1039 Currently, RTSP_Audio (Family 1) is defined in Appendix C. 1041 PARAMETER_ID 1043 Specified the parameter ID within the family. These are defined 1044 for the in Appendix C. 1046 PARAM_REFUSE 1047 If the server does not support the requested parameter or family, 1048 it sends a ParamRefuse, whose format is as below: 1050 0 1 2 3 1051 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 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | tag(PARAM_REFUSE) | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | REQUEST_ID | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | FAMILY_ID | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | PARAMETER_ID | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | ERROR_CODE | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 REQUEST_ID 1065 Is a 32 bit number used to reference this request, must be non- 1066 zero. 1068 FAMILY_ID 1069 Currently, RTSP_Audio (FAMILY_ID1) is defined in Appendix C. 1071 PARAMETER_ID 1072 Specified the parameter ID within the family. Currently, the 1073 RTSP_Audio is defined in Appendix C. 1075 ERROR_CODE: As defined earlier. 1077 SET_PARAM 1079 Using the same principle as GET_PARAM, a media-specific option 1080 for the stream can be set using the SET_PARAM message. Examples 1081 of an option include encryption, custom encoding or quality 1082 levels. The server replies with a SET_PARAM_REPLY or 1083 PARAM_REFUSE. 1085 0 1 2 3 1086 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 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | tag (SET_PARAM) | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 | REQUEST_ID | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | FAMILY_ID | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | PARAMETER_ID | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | | 1097 / DATA / 1098 | | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 REQUEST_ID 1102 Is a 32 bit number used to reference this request, must be non- 1103 zero. 1105 FAMILY_ID 1106 Currently, RTSP_Audio (Family 1) is defined in Appendix C. 1108 PARAMETER_ID 1109 Specified the parameter ID within the family. These are defined 1110 for the in Appendix C. 1112 DATA 1113 Specifies the payload specific to the family and parameters. 1115 4.0 EXAMPLES/APPLICATION NOTE 1117 Example of use of GetParam to request and play an audio file: 1119 CLIENT SERVER 1121 CONTROL_SCP: HELLO---------------------------> 1123 <---------------------------CONTROL_SCP:HELLO 1125 <--------------------------- CONTROL_SCP:ID 1127 (OPTIONAL) CONTROL_SCP:ID_RESP---------------------> 1129 STREAM_SCP_0: FETCH-----------------------------> 1131 STREAM_SCP_0: GETPARAM--------------------------> 1133 STREAM_SCP_0: GETPARAM--------------------------> 1135 <------------------------- STREAM_SCP_0:STREAM_HEADER 1137 <------------------------- STREAM_SCP_0:PARAM_REPLY 1139 <------------------------- STREAM_SCP_0:PARAM_REPLY 1141 STREAM_SCP_0: SETPARAM(eg.encryption) ----------------> 1143 <-------------------------- STREAM_SCP_0:PARAM_REPLY 1145 STREAM_SCP_0: SET_TRANSPORT(RTP)----------------> 1147 STREAM_SCP_0: PLAY_RANGE(a,b)-------------------> 1149 <--------------------------- STREAM_SCP_0:STREAM_SYNC 1151 <--------------------------- Data on UDP channel 1153 Example of use of custom message: 1155 CLIENT SERVER 1157 CONTROL_SCP: HELLO----------------------------> 1158 <----------------------------CONTROL_SCP:HELLO 1160 STREAM_SCP_0: FETCH -------------------> 1162 <-------------------------- STREAM_SCP_0:STREAM_HEADER 1164 STREAM_OBJECT_SCP_0: SET_TRANSPORT(RTP)--------> 1166 STREAM_OBJECT_SCP_0: PLAY_RANGE(a,b)-----------------> 1168 <--------------------------- STREAM_SCP_0:STREAMSYNC 1170 <--------------------------- Data on UDP channel 1172 <--------------------------- CONTROL_SCP: EVENT_NOTIFY(NewURL) 1174 STREAM_OBJECT_SCP_1: FETCH---------------------> 1176 <------------------------- STREAM_SCP_1:STREAM_HEADER 1178 STREAM_SCP_1: SET_TRANSPORT(RTP)----------------> 1180 STREAM_SCP_1: SEEK(a,b)-------------------------> 1182 <--------------------------------- STREAM_SCP_1:STREAM_SYNC 1184 <------------------------------- Data on UDP channel 1186 5.0 REFERENCES: 1188 [1] H. Shulzrinne, S. Casner, R. Frederick, and S. McCanne, "RTP: 1189 A Transport Protocol for real-time applications." RFC 1889 1191 [2] Simon Spero, Session Control Protocol(SCP). 1193 [3] J. Postel, J. Reynolds, "Telnet Protocol Spefication.", RFC 854 1195 6.0 APPENDIXES 1197 6.1 APPENDIX A - Data packets 1199 [Note: see "Compartmentalize the Protocol" in the "RTSP 1200 Open Issues" document for discussion of the possible split 1201 of this appendix into a separate document 1202 (http://www.prognet.com/prognet/rt/openissues.html)] 1204 The following are the types of data packet formats. 1206 RTP: The format of the UDP packet is a standard RTP packet, as 1207 per RFC 1889. This is a description of how the RTP packet is used 1208 by RTSP. Complete generalized descriptions of these fields can be 1209 found in RFC 1889. 1211 0 1 2 3 1212 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 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 |V=2|P|X| CC |M| PT | sequence number | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | timestamp | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | synchronization source (SSRC) identifier | 1219 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1220 | contributing source (CSRC) identifiers | 1221 | .... | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 The first twelve octets are present in every RTP packet, while 1225 the list of CSRC identifiers usually will not be present (though 1226 may be used when broadcasting an RTP conferencing session, for 1227 instance). The fields have the following meaning: 1229 Version (V): 2 bits 1230 This field identifies the version of RTP. The version used by 1231 this specification is two (2). 1233 Padding (P): 1 bit 1234 If the padding bit is set, the packet contains one or more 1235 additional padding octets at the end which are not part of the 1236 payload. The last octet of the padding contains a count of how 1237 many padding octets should be ignored. 1239 Extension (X): 1 bit 1240 Not used. Set to zero for RTP compatibility. CSRC count (CC): 4 1241 bits. The CSRC count contains the number of CSRC identifiers that 1242 follow the fixed header. 1244 Marker (M): 1 bit 1245 In RTSP, this designates the block boundary. This is a point at 1246 which a client can start decoding the stream. 1248 Payload type (PT): 7 bits 1249 Each stream uses a payload type allocated dynamically between 96 1250 and 127, to remain consistent with the dynamic mappings in the 1251 audio-video profile (RFC 1890). 1253 Sequence number: 16 bits 1254 The sequence number increments by one for each RTP data packet 1255 sent, and may be used by the receiver to detect packet loss and 1256 to restore packet sequence. The initial value of the sequence 1257 number is random (unpredictable) to make known plaintext attacks 1258 on encryption more difficult, even if the source itself does 1259 not encrypt, because the packets may flow through a translator 1260 that does. 1262 Timestamp: 32 bits 1263 The timestamp is a tick mark which reflects the sampling instant 1264 of the first octet in the RTP data packet. The clock frequency is 1265 dependent on the format of data carried as payload. 1267 SSRC: 32 bits 1268 The SSRC field identifies the synchronization source associated 1269 with the data. This identifier is chosen with the intent that no 1270 two synchronization sources within the same RTSP session will 1271 have the same SSRC. 1273 CSRC list: 0 to 15 items, 32 bits each 1274 The CSRC list identifies the contributing sources for the payload 1275 contained in this packet. The number of identifiers is given by 1276 the CC field. If there are more than 15 contributing sources, 1277 only 15 may be identified. 1279 Compressed RTP 1280 [Note: There has been some questions as to the 1281 appropriateness of this name, since it is really an 1282 application-level compression that relies on RTSP to carry 1283 some of the "compressed" information out of band. We will 1284 probably change this name to reflect its distance from RTP.] 1286 0 1 2 3 1287 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 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 |v|M|t|s| SSRC | sequence number |timestamp (opt)... 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 ... | 1292 +-+-+-+-+-+-+-+-+ 1294 version (v): 1 bit 1295 If this is 1, the rest of this packet is standard RTP, and we can 1296 treat it as such. If it is 0, the rest of the packet is defined 1297 as follows. 1299 marker (M): 1 bit 1300 In RTSP, this designates the block boundary. This is a point at 1301 which a client can start decoding the stream. 1303 timestamp lower bits compression bit (t): 1 bit 1304 This number specifies the existence of the least-significant two 1305 bytes of the timestamps. If this bit is not set, the value of 1306 these bytes are calculated based some media-specific method 1307 (probably using the sequence number). If this bit is set, the 1308 value of these bytes are given in this packet. 1310 The upper bits are determined based on the probable value given 1311 the sequence number. This compression scheme does not work for 1312 packets that are spaced out at intervals greater than roughly 64 1313 seconds. 1315 sequence number inclusion bit(s) 1316 This bit is for compatibility with reliable, sequenced delivery 1317 mechanisms, such as SCP. This should always be set to 1. 1319 SSRC: 4 bits or 36 bits 1320 The SSRC field identifies the synchronization source associated 1321 with the data. This identifier is chosen with the intent that no 1322 two synchronization sources within the same RTSP session will 1323 have the same SSRC. 1325 This is 4 bits unless set to 15 (1111), in which case it expands 1326 to 36 bits, and the lower 32 bits are the actual SSRC. 1328 sequence number: 16 bits 1329 The sequence number increments by one for each RTP data packet 1330 sent, and may be used by the receiver to detect packet loss and 1331 to restore packet sequence. The initial value of the sequence 1332 number is random (unpredictable) to make known-plaintext attacks 1333 on encryption more difficult, even if the source itself does 1334 not encrypt, because the packets may flow through a translator 1335 that does. 1337 6.2 APPENDIX B - Session Control Protocol (SCP) 1339 [Note: see "Compartmentalize the Protocol" in the "RTSP 1340 Open Issues" document for discussion of the possible split 1341 of this appendix into a separate document 1342 (http://www.prognet.com/prognet/rt/openissues.html)] 1344 [Note: other methods of multiplexing are currently being 1345 discussed. Simon Spero has a new draft of SCP at 1346 http://sunsite.unc.edu/ses/scp.html. SMUX, from Jim 1347 Gettys and the W3C at http://www.w3.org is another candidate.] 1349 This document was originally written by Simon Spero for the HTTP- 1350 NG project. It has been slightly editied and clarified. 1352 Several heavily used Internet applications such as FTP, GOPHER, 1353 and HTTP use a protocol model in which every transaction 1354 requires a separate TCP connection. Since clients normally issue 1355 multiple requests to the same server, this model is quite 1356 inefficient, as it incurs all the connection start up costs for 1357 every single request. 1359 SCP is a simple protocol which lets a server and client have 1360 multiple conversations over a single TCP connection. 1362 Definitions 1364 A session is a virtual stream of data carried within the single 1365 TCP connection. It is independent of any other session within the 1366 same connection. 1368 A session identifier is a unique number which is used to specify 1369 which session a particular block of data is associated with. 1371 Session flag names are borrowed from TCP. The name SYN means 1372 "open" in SCP. The name FIN means "finish" or "close" in SCP. The 1373 name RST means "reset" in SCP. PUSH indicates the end of a 1374 segment. 1376 Services 1378 SCP's main service is dialogue control. This service allows 1379 either end of the connection to establish multiple virtual 1380 sessions over a single transport connection. SCP also allows a 1381 sender to indicate message boundaries, and allows a receiver to 1382 reject an incoming session. 1384 Design goals 1386 SCP allows data to be sent with the session establishment; the 1387 recepient does not confirm successful connection establishment, 1388 but may reject unsuccessful attempts. This simplifies the design 1389 of the protocol, and removes the latency required for a con- 1390 firmed operation. 1392 Low overhead 1394 SCP has a fixed overhead of 8 bytes per segment. This overhead is 1395 only incurred once per segment, instead of once per packet. 1397 Simple design 1399 The session protocol should be simple enough to implement for a 1400 single application. 1402 Protocol Description 1404 Header Format: 1406 0 1 2 3 1407 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 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 |0|0|0|0| flags | session ID | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | session length | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | | 1414 / data / 1415 | | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 flags: 1419 0x1 : SYN 1420 0x2 : FIN 1421 0x4 : RST 1422 0x8 : PUSH 1424 Protocol Operation 1426 Session ID allocation 1427 Each session is allocated a session identifier. Session 1428 Identifiers below 1024 are reserved. Session IDs allocated by 1429 clients are even; those allocated byservers, odd. 1431 Session establishment 1432 A new session is established by setting the SYN bit in the first 1433 message sent on that channel. 1435 Graceful release 1437 A session is ended by sending a message with the FIN bit set. 1438 Each end of a connection may be closed independently. 1440 Disgraceful release 1441 A session may be terminated by sending a message with the RST bit 1442 set. All pending data for that session should be discarded 1444 Message boundaries 1445 A message boundary is marked by sending a message with the PUSH 1446 bit set. The boundary is set at the final octet in this message, 1447 including that octet. 1449 Compressed Header SCP 1451 +-+-+-+-+-+-+-+-+-----//------+-------//-------+---//---+ 1452 |1|P| IDL | LNL | session ID | segment length | data | 1453 +-+-+-+-+-+-+-+-+-----//------+-------//-------+---//---+ 1455 P: 1 bit 1456 Push bit. This denotes a message boundry, which is set at the 1457 final octet in this message. 1459 IDL: 3 bit 1460 Length of the session ID field (as described below). 1462 LNL: 3 bits 1463 Length of the session length field (as described below). 1465 session ID: Variable number of bits, depending on IDL field 1466 Identifier for this session. The session ID value is relative to 1467 1024, which is the minimum non-reserved value. 1469 segment length: Variable number of bits, depending on LNL field. 1470 Length of the payload in bytes. 1472 IDL and LNL values: 3 bits 1474 value Length of Session ID or Segment Length field 1475 0x0 use previous value 1476 0x1 4 bits 1477 0x2 8 bits 1478 0x3 12 bits 1479 0x4 16 bits 1480 0x5 24 bits 1481 0x6 32 bits 1482 0x7 64 bits 1484 IDL and LNL values should be chosen so that byte alignment of the 1485 packet is guaranteed. 1487 6.3 APPENDIX C - RTSP -Audio (Family ID =1 ) 1488 Format descriptor (Parameter=1) 1489 [Note: see "Compartmentalize the Protocol" in the "RTSP 1490 Open Issues" document for discussion of the possible split 1491 of this appendix into a separate document 1492 (http://www.prognet.com/prognet/rt/openissues.html)] 1493 [Note: see "Change Appendix C (families of stream types)" 1494 in the "RTSP Open Issues" document for discussion of a 1495 series of proposed changes to this Appendix, such as 1496 changing CODEC IDs to UUIDs, modifying the audio family, 1497 and adding a video family 1498 (http://www.prognet.com/prognet/rt/openissues.html)] 1500 0 1 2 3 1501 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 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | CODEC ID | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | NumChannels | Bits/Sample | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | Samples Per Second | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | Average Frame Size | Maximum Frame Size | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | Samples Per Frame | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 |P| Frames Per Packet | Extra Bytes | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | Number Of Frames | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | CODEC-specific Data | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 : : : 1520 : : : 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 The above structure describes a generic compressed audio stream 1524 for the RTSP Audio Family. 1526 CODEC ID: The CODEC ID uniquely identifies the codec which was 1527 used to generate this audio data. CODEC ID's in the range 0x00 1528 through 0xffff are reserved for ACM (Audio Compression Manager 1529 native to Microsoft Windows Operating systems) compatible/ 1530 interoperable codecs. 1532 NumChannels: Use 1 for mono, 2 for stereo 1534 Bits/Sample: Number of bits per sample as specified by the codec. 1535 Codecs which do not need or do not have a well defined value for 1536 this parameter may set this to zero. 1538 Samples Per Second: Playback rate for each channel in 1539 samples per second (hertz). 1541 Average Frame Size: Frame is the smallest unit of encoded audio 1542 data that can be streamed from the server. Average Frame Size 1543 represents the typical size (in bytes) of a frame. This family 1544 does not support non byte-aligned frames. 1546 Maximum Frame Size: Size in bytes of the largest frame. For 1547 constant bit rate codecs, this value is the same as the Average 1548 Frame Size. 1550 Samples Per Frame: Number of samples of audio data encoded in 1551 each frame. This family does not support variable duration frames. 1553 P: If P is not set, then the audio data is planar and the client 1554 has the option to request data packets of size which are 1555 multiples of the average frame size. If P is set, the stream is 1556 packetized (usually for variable bit rate data and live feeds), 1557 then the size of the data packet is defined by frame size and 1558 frames per packet (described below). 1560 Frames Per Packet: For packetized formats, this represents the 1561 number of frames in every data packet. For planar formats, this 1562 is a hint to the client regarding the server preference. 1564 Extra Bytes: This specifies the number of bytes of codec specific 1565 data that follow the fixed header. 1567 Number of Frames: Total number of frames in the audio stream. For 1568 non-seekable streams (e.g. live feeds), this should be set to 1569 zero. 1571 6.4 APPENDIX D - RTSP - Audio (Family ID =1 ) : Annotations 1572 (Parameter=2) 1574 [Note: see "Compartmentalize the Protocol" in the "RTSP 1575 Open Issues" document for discussion of the possible split 1576 of this appendix into a separate document 1577 (http://www.prognet.com/prognet/rt/openissues.html)] 1578 This payload data enables the server to communicate additional 1579 information about the stream to the client. Examples of such 1580 information include the authorof the clip, the clip name, 1581 copyright information, creation date etc. The payload data is 1582 organized as a list of information chunks. Each such chunk has an 1583 identifier, length of the chunk and the actual data itself. 1585 0 1 2 3 1586 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 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | Number of chunks | 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | Chunk Identifier (Chunk 0) | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | Number of Bytes (Chunk 0) | 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | Chunk Data (Chunk 0) | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 : : : 1597 : : : 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | Chunk Identifier (Chunk n-1) | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | Number of Bytes (Chunk n-1) | 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | Chunk Data (Chunk n-1) | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 : : : 1606 : : : 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 Chunk Identifier 1610 This is a four character code identifying the chunk. For example, 1611 `I''C''O''P' is used for copyright information which is 1612 stored as a null terminated string. `I''N''A''M' is used for the 1613 name of the audio clip. `I''U''R''L' serves to pass the URL for 1614 the CODEC installer. The client should use this URL if it 1615 encounters a clip compressed with an unknown CODEC. 1617 Any chunk with an unrecognized four character code should be 1618 ignored by the client. 1620 Number of Bytes 1622 Represents the length of the chunk data. The chunk data should be 1623 16 bit aligned. 1625 6.5 APPENDIX E - Authors 1627 Contacts: 1629 At Netscape: Anup Rao 1630 At Progressive Networks: Rob Lanphier 1632 [Note: this list will need to be updated for the final 1633 release of the document] 1635 The following authors contributed to this document: 1637 Martin Dunsmuir 1638 General Manager Server Products, 1639 Progressive Networks 1640 1111 Third Avenue, Suite 2900 1641 Tel. 206 674 2700 (main #) 1643 John K. Ho 1644 Project Manager 1645 Netscape Communications Corp. 1646 685 E. Middlefield Rd. 1647 Mountain View, CA, 94043 1648 Tel. 415 254 1900 (main #) 1650 Rob Lanphier 1651 Program Manager 1652 Progressive Networks 1654 Eduardo F. Llach 1655 Manager, Media Server Team, 1656 Netscape Communications Corp. 1658 Rob McCool 1659 Technical Team Leader, Media Server 1660 Netscape Communications Corp. 1662 Igor Plotnikov 1663 Technical Team Leader, Media Server 1664 Netscape Communications Corp. 1666 Anup Rao 1667 Member, Technical Staff 1668 Netscape Communications Corp. 1670 Pinaki Shah 1671 Member, Technical Staff 1672 Netscape Communications Corp. 1674 Alexander Sokolsky 1675 Member, Technical Staff 1676 Netscape Communications Corp. 1678 Dale Stammen 1679 Lead Saxophone 1680 Progressive Networks 1682 John Francis Stracke 1683 Senior LiveMedia Architect 1684 Netscape Communications Corp.