INTERNET-DRAFT 3 December 2003 Internet Engineering Task Force Expires: 3 June 2004 MMUSIC WG Geetha Srikantan Sun John Murata Apple Andrew Large Sun Streaming Relays draft-srikantan-mmusic-rtsp-streaming-relay-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 3, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. 1. Abstract Delivery of streaming media to a large number of clients distributed across several geographic and network boundaries presents several challenges in terms of scalability and stream quality. This document describes N-tier relays to address scalability and quality issues in the delivery of stored and live content. This document addresses issues in stream synchronization, content announcement/expiry, reliability of transport, failover/recovery, administration, and security issues. This document propose a set of primitives to enable implementation of Push and Pull mechanisms for N-tier relays. We also provide usage scenarios where each approach is most useful. The Pull and Push mechanisms are complementary and provide valuable building blocks in N-tier relays. This document introduces a few new RTSP methods and headers. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Terminology * Source - A source of media streams - either live or stored content may be used. The Source implements RTP and RTCP and produces RTP and RTCP packets for each media stream. The Source may or may not implement RTSP. * Live Source - A Source for live streams. It does not support RTSP 'PAUSE' and media streams are only available at the restricted times when the live session is in progress. * Broadcast - In the sense of a FM radio broadcast. The content could be either live or stored. Streams of RTP and RTCP packets are available with some degree of synchronization information. The streams can be sent over unicast or multicast. * Broadcaster - A network element which is a Source with Broadcast capability. * Server - An RTSP server implementation. Also an RTP and RTCP server implementation. * Client - An RTSP client implementation. Also an RTP and RTCP client implementation. * Player - A Client which renders media streams to end-user. * N-tier Relay - A network or group of networks with multiple tiers of hosts or network elements, each of which may be a Source, Live Source, Broadcaster, Server or Client. The Source, Live Source or Broadcaster is at the top tier of the relay. Several tiers of servers may exist. The last tier of the relay is the edge tier of nodes that stream content to Players. * Relay Node - A network element in any tier, except the last tier of an N-tier relay; i.e. any non-Player node. * Edge Node - A network element that is at the edge of the n-tier relay, and serves Players. * Interior Node - A network element that is at any tier, preceding the Edge tier of the relay; i.e. any Relay Node which is not an Edge Node. * Pull - The capability to pull content to into a network element. * Push - The capability to push content to a network element. * Publish - The capability to notify a network element about the availability of content or streaming session. 3. Introduction Delivery of streaming media to a large number of clients distributed across several geographic and network boundaries presents several challenges. Scalability and stream quality issues are addressed by using multiple relay nodes in the network, all of which deliver the same streaming session to clients. The nature and topology of such N-tier relays vary widely and interoperability will benefit from a clarification of behavior for relays and negotiated broadcasts for both TCP and UDP. This document outlines the main issues in relay networks and proposes primitives to enable n-tier relays. These primitives are based on RTSP, SDP, RTP/RTCP. Two kinds of relay modes are introduced, (a) Reflection, where packets are forwarded by relay nodes, without any alteration, and (b) Translation, where packet headers may be modified by intermediate relay nodes. Automated publication of SDP for live sessions using the RTSP ANNOUNCE method is also presented. The next section outlines main issues to consider in live streaming and N-tier relays. The following section describes motivation, details, assumptions and implications for each mechanism of the proposed solution. Use cases for these mechanisms are also provided in this section. The final section summarizes the N-tier relay approaches proposed in this document. It highlights the usage of old and new RTSP methods and headers in relays and also makes recommendations about including these either in the core RTSP spec or in an extension document. 4. Problem Scope This section describes the main issues in: * live streaming, and, * N-tier relays and broadcasts. 4.1 Live Streaming Problem Statement Live streaming includes a live source and one or more streaming servers that deliver the live stream to several downstream clients. Live streaming can also happen directly from a broadcaster as in the case of multicast broadcast. In order for live streaming to work, the SDP file describing a live session is published at the streaming server's content root typically using one of the following mechanisms: - manually ftp'ing the SDP file from the live source host to the streaming server host (onto the content root of the streaming server); - via a webserver; - via email, etc. At this point the live session can be accessed from the streaming server via the SDP file. Scalability and stream quality issues are addressed by using multiple relay nodes in the network, all of which deliver the same live session to clients. Examples of relays: 1. Server can pull a broadcast from another server with RTSP DESCRIBE/SETUP/PLAY methods and then relay or re-broadcast the streams or make the streams available to clients as a server. 2. Server can receive a push broadcast from a broadcaster that uses RTSP ANNOUNCE/SETUP/RECORD and then either relay or serve the broadcast. 3. There are situations, as in the case of an SDP declared UDP unicast or multicast broadcast, where there is an ANNOUNCE with no SETUP and no RECORD from the broadcaster. This arises in cases wherer (a) the broadcaster is not a complete RTSP-server implementation, and/or (b) when the multicast session is in progress and it is not possible to accurately determine the interaction points of RTSP and RTP/RTCP. When relay nodes deliver the live stream, network delays and the asynchronous nature of live streaming can result in synchronization issues at the streaming server and clients. There are different synchronization issues: - Minimum or controlled time lag from the original broadcast, so all watching or listening clients are viewing the same point in the broadcast regardless of how many relay nodes are between each Player instance and the Source. - If controlled lags or delays are allowed, at which point should they be introduced for each stream - which tier of the relay; which nodes? - Stream synchronization between streams of the same broadcast - is not easy when a client must tune into a live multicast broadcast. Two important security concerns around live streaming are: (a) A relay node may need to determine whether the live source that is announcing content, is a legitimate live source. (b) The live source may need to know if a relay node requesting content is a legitimate client. >From the above it is clear that an integrated solution for live streaming should address automated publication of live content, scalability concerns, quality and synchronization issues, and security concerns. 4.2 N-tier Relay and Broadcast Issues Section 4.1 outlined the main issues in live streaming. Many of the issues that are pertinent to live relays also apply to relays of stored content. This section outlines issues in enabling both broadcasts and relays of live and stored content. * Content Announcement and Expiry. Stored content may be deployed by a content management system at many nodes; the nodes need to be made aware of the availability of new stored content. Live source needs to inform relay nodes about the availability of a new live streaming session so that the relay node can access the session content in preparation for delivery to its clients. Media descriptions about a new streaming session can include the SDP that would normally be sent in a RTSP DESCRIBE response as well as expiry information, and other meta-information regarding this content. Media announcements can be made to indicate the availability of new sessions or to revoke a previous announcement. Players or other clients requesting an expired or revoked session should be sent a suitable message indicating that this content is no longer available. * Synchronization of streams within a session. As noted earlier, network delays and other factors can cause arbtrary delays in the delivery of media streams at all relay nodes. A session with a single media stream can use the arrival time of a RTP packet maps to NPT 0 (NPT == Normal Play Time), and record the packet's sequence number and timestamp to correspond with NPT 0. When more packets arrive it can determine whether these are older or newer packets and decide to discard or use these packets. When multiple streams form a session, there is usually a need to synchronize playout of these streams. Synchronization requires correspondence of the NPT clock to each media stream. Typically RTSP PLAY responses will contain a Range header with NPT info and a RTP-Info header with url, sequence number and timestamp of RTP packets that correspond to the NPT in the Range header. This information is sufficient for synchronization of streams. In cases where the relay is forwarding multicast, information for RTSP headers such as RTP-Info, is not available. As a result the synchronization requirements are necessarily weaker, in such scenarios. * Reliability of transport. When the N-tier relay spans several networks, arbitrary delays and losses in transmission are possible. Use of TCP for data transport is recommended to avoid losses and packet-reordering that UDP may introduce. * Firewalls Firewalls between any two nodes in the N-tier relay complicate matters. The simplest approach is to use TCP transport across firewalls. * Failover and Recovery of the Relay. If the broadcaster crashes and needs to be restarted, a relay recovery mechanism is needed. This could be based on (a) IP failover at the broadcaster, so relay nodes can auto-reconnect. (b) Via an explicit ANNOUNCE from the broadcaster after it has recovered. (c) From a backup broadcaster instance, etc. In case a relay node stops receiving streaming content unexpectedly, it can recover the streams by either by retrying connection to the upstream node, or by awaiting explicit notifcation of a new upstream source. If the relay node initiates retries, the rate of frequency and duration of retries may be signalled or configured. An abrupt end of the session may need to be signalled to relay nodes, as well. In case the broadcaster wants to disconnect and rebroadcast with a different set of addresses or different set of encodings, it will need to notify all its recipients of this change. * Security. There is a need to disallow arbitrary media announcements from unauthorized sources to relay nodes. Relay nodes such as live sources or broadcasters may need to authenticate requests for relay content. Protection of media distribution rights in an N-tier relay is desirable in many usage scenarios. * Administration. Each interior node in the relay needs to be configured with valid upstream and downstream hosts. Each edge node in the relay needs to be configured with valid upstream hosts. 5. Proposed Solution We propose a set of primitives that will enable n-tier relays and broadcasts for both live and stored content. In this approach the client and server interactions are such that a relay node can be both a relay/server and a broadcaster. The main components of the proposed solution are: * Two relay modes - Reflection and Translation. * Two relay mechanisms - Push and Pull. * Automated publication of live/stored content. The following subsections will discuss each of these components in detail. For each we provide (a) details, (b) assumptions, (c) implications, (d) pros/cons, (e) any new protocol primitives needed. 5.1 Relay Modes Two relay modes are described here - Reflection and Translation. 5.1.1 Reflection The source or broadcaster is typically RTP/RTCP implementations and either partial or complete RTSP implemetations. Media packets are forwarded without any modifications. Nodes in such relays may not have access to RTSP-specific information such as the mapping between NPT and timestamps of each stream in an RTSP session, consequently the stream-synchronization requirements are weaker in this relay mode. In case the broadcast stops or there is a failure in reception of content at the node, the relay node can send an end-of-stream notification to all its clients so they can teardown their sessions. 5.1.1.1 Reflection - Pros * Simple and easy to deploy. 5.1.1.2 Reflection - Cons * Lack of synchronization between streams can get amplified, particularly at tiers of the relay that are further away from the Source. 5.1.2 Translation The source or broadcaster is an RTSP server implementation. All the interior components of the relay implement RTSP and RTP/RTCP. In this mode, RTP timestamps (and sequence numbers) on packets may be translated to assist in stream synchronization and quality . In the event of a broadcaster/source failure, the interior relay nodes may provide sophisticated failover and recovry mechanisms. 5.1.2.1 Translation - Pros * Synchronization issues are addressed explicitly (except in multicast). 5.1.2.2 Translation - Cons * Complexity and extra processing at each node can add to latency. * Broadcaster needs to be a RTSP server implementation. * Broadcaster and relay/server need a mechanism to signal stream synchronization metadata. 5.2 Relay Mechanisms Two complementary relay mechanisms are presented here. In the Pull mechanism downstream relay nodes, such as streaming servers initiate the delivery of streams from upstream nodes. In the Push mechanism upstream nodes send content to downstream relay nodes. 5.2.1 Pull - Streaming Server Driven Approach In this approach, interior relay nodes such as a streaming server pull content from the broadcaster/source. The broadcaster sends ANNOUNCE with SDP contents and headers indicating expiry/lifetime and delivery protocol for the content. This causes the streaming server to request content from the source via SETUP, PLAY - as an RTSP client. The broadcaster behaves like a streaming server and the downstream server behaves like a streaming client. That is, the interactions are as follows at the first tier of the relay: Broadcaster -> Relay Node ANNOUNCE SDP file with expiry info Relay Node -> Broadcaster Acknowledge ANNOUNCE Relay Node -> Broadcaster SETUP request to setup a stream from SDP Broadcaster -> Relay Node SETUP response Repeat the above two steps as many times as needed for the session. Relay Node -> Broadcaster PLAY request for the session Broadcaster -> Relay Node PLAY response w/ Range header, RTP-Info In other tiers of the relay, the upstream relay node plays the role of the Broadcaster. The broadcaster provides stream synchronization information in the PLAY response to the relay node requesting the content (except in the case of multicast). From this point on, each relay node can maintain its own NPT clock and a correspondence tuple of for each stream in the session. This will permit the node to convey this information to any of its recipients. In case the broadcast or source fails, the server will retry connecting to the source, every so often, until it receives notifcation that the SDP has been revoked or has expired. That is, the relay node is responsible for restart. Configurable timeouts for retry attempts may also be used. 5.2.1.1 Pull - Pros - Explicit correspondence, when this information is available from the source. - Streaming servers can request content from source as and when they need to (when there are downstream clients requesting this). 5.2.1.2 Pull - Cons - Authentication and authorization needs to be handled at source (so it can validate requests for content, and so it can validate itself when publishing content). The relay/server needs to validate itself at source before it can request for content (and validate downstream clients, as usual). - Source is now a RTSP server. - Extra administration, security and system complexity. 5.2.2 Push - Source Driven Approach In the Push approach the source or broadcaster initiates delivery of the streaming session to the relay/server. The source sends ANNOUNCE with SDP and expiry/delivery info. Next, the source sends SETUP with mode=receive and RECEIVE to the server. Another way to support this would be for the source to send SETUP_RECEIVE to the relay node, followed by RECEIVE. The interactions at the first tier of the relay are as follows: Broadcaster -> Relay Node ANNOUNCE SDP file with expiry info Relay Node -> Broadcaster Acknowledge ANNOUNCE Broadcaster -> Relay Node OPTIONS request to determine server push capability Relay Node -> Broadcaster OPTIONS response with 'RECEIVE' implies push capable. Broadcaster -> Relay Node SETUP_RECEIVE Relay Node -> Broadcaster SETUP_RECEIVE response with server-side port numbers. Repeat these two steps as many times as needed. Broadcaster -> Relay Node RECEIVE request w/ Range header and RTP-Info, if available. Relay Node -> Broadcaster RECEIVE response The relay node now has access to the streams and can deliver them to its recipients. If relay node receives streams over unicast UDP, it can select ports and return them in the SETUP or SETUP_RECEIVE response. The RECEIVE request contains Range nor RTP-Info headers, if available. The RECEIVE response will contain RTP-Info header with urls only (no sequence number or timestamp). If multicast UDP transport is used to send media to the relay node then the source/broadcaster determines the ports to be used. Also the RECEIVE request may contain a Range header, however the RECEIVE response will contain neither Range not RTP-Info headers. If the source provided Range and RTP-Info headers with synchronization information, then the relay node maintains an implicit correspondence between the NPT (from Range header) to the RTP sequence number and timestamps. 5.2.2.1 Push - Pros - All security issues are handled by the streaming server - it can validate the source, just as it validates clients. - Source/Broadcaster need not be a complete RTSP implementation. 5.2.2.2 Push - Cons - A relay node will have to receive the streams from the source, regardless of whether downstream clients ask for them or not. - No mechanism for relay node to request content after the ANNOUNCE. Relay node is forced to accept streams from the source or miss the session entirely. 5.2.2.3 New Primitives * A new RTSP method 'RECEIVE' is introduced, the sender of a RECEIVE request intends to send media to the recipient of the request. The receiver of this request can indicate whether it is ready to receive such streams in the RECEIVE response. * The RTSP method SETUP, if used with 'mode=receive' parameter, would be used in establishing transport for a new stream. The sender of a SETUP request with mode=receive attempts to establish the transport by providing its own transport parameters. The receiver of this request responds with its transport parameters, if it supports this mode. The sender of this request intends to use the transport for a subsequent RECEIVE request, by which it will send media streams to the recipient. Using the SETUP method with mode=receive will require only one additional RTSP parameter 'mode=receive' to be defined. This is similar to the usage of SETUP/RECORD in RFC 2326. OR A new RTSP method SETUP_RECEIVE, with the same headers as SETUP can be used instead. If this method is introduced, then SETUP would be used by a client requesting media from a server, and SETUP_RECEIVE would be used by a source/server intending to send media to a client. Using this method introduces a brand new method into RTSP. 5.3 Automated Publication of Live/Stored Content In both the Pull and Push mechanisms, the RTSP ANNOUNCE method signals availability of content. The SDP in the ANNOUNCE can use port number 0 to indicate that the relay node can pick a port number for this media. ANNOUNCE request can also contain headers to indicate the expiry of this content, with the inclusion of additional RTSP x- headers. Etags may also be used to indicate expiry. ANNOUNCE requests may be sent to relay nodes to revoke a previously announced SDP, as well. Typical use cases of using ANNOUNCE are: An ANNOUNCE client, such as a source/broadcaster sends ANNOUNCE. An ANNOUNCE server receives ANNOUNCE requests. An ANNOUNCE client and server implementation is recommended at relay/server nodes. 5.3.1 Automated Publication - Pros * When SDP is announced via RTSP ANNOUNCE , there is no need for external entity like a webserver or mail server for publishing the content. In cases where the SDP file is out-of-date, a new ANNOUNCE from the live source to the server will bring the SDP up-to-date. 5.3.2 Automated Publication - Cons * An additional RTSP method needs to be supported on clients and servers. 5.3.3 New Primitives The RTSP ANNOUNCE method described in RFC 2326 can be restored. Two new methods ANNOUNCE_RECEIVE and ANNOUNCE_RELAY can be used to indicate capability as well. * The RTSP method ANNOUNCE could be used to announce content available for multicast and also signal multicast push capability of the recipient, in the ANNOUNCE response. * A new RTSP method ANNOUNCE_RELAY could be used to announce content that is accessible via unicast pull mechanism in the relay. The recipient of a ANNOUNCE_RELAY can respond with its capability to handle unicast pull. * A new RTSP method ANNOUNCE_RECEIVE could be used to announce content that is accessible via unicast push mechanism in the relay. The recipient of a ANNOUNCE_RECEIVE can respond with its capability to handle unicast push. * New RTSP headers: "x-content-expire: " can be used to indicate the lifetime of the SDP being ANNOUNCE'd. "x-relay-recovery: " can be used to indicate the preferred relay recovery mechanism for this SDP. "x-revoke-content: true" can be used to indicate that the SDP being ANNOUNCE'd is no longer available to recipients. 5.4 N-tier Relay and Broadcast Issues 5.4.1 Synchronization Issues To address synchronization issues: (a) SDP t= line should be accurate about duration and actual time of a live session. Extra RTSP x- headers to indicate meta info about the SDP file would be good - for example, expiry of SDP. (b) PLAY response SHOULD contain Range header with an numeric time value, such as Range: npt:0- and not Range: now- (c) PLAY response SHOULD contain RTP-Info header - the timestamp is required for synchronization. The sequence number field is not essential - in fact for multicast/UDP case the client's use of the sequence should be relaxed to expect any packets with sequence numbers greater than or equal to that mentioned in the RTP-Info header (modulo rollover of the sequence number space). 5.4.2 Reliability In general it is better, if possible, to broadcast/relay over TCP using announced interleaved streams so you have a reliable broadcast until you get to an edge server. This is better than UDP streams in an uncontrolled network environment because UDP packet loss in a broadcast stream will be reproduced for all downstream clients. We also assume that using TCP transport will resolve firewall issues. 5.4.3 Failover and Recovery RTSP x- headers can be used to indicate desired behavior in case the broadcast or live source fails. Whether to disconnect and/or retry, maintain SDP reference to the streams etc. These headers should be included in the ANNOUNCE request that is used to indicate availability of the session. When clients request SDP that is no longer valid they will receive a RTSP 404 (Not Found) or 401 (Unauthorized). 5.4.4 Teardown Teardown - could be based on reference counting particularly in the multicast case. 5.5 Discussion of Pull and Push mechanisms 5.5.1 Push Implications The Push mechanism implies that the broadcaster/source need not be a full RTSP server implementation. However the first tier from the source should be an RTSP-server implementation - SETUP with mode=receive or SETUP_RECEIVE, along with RECEIVE; other interior nodes of the network may or may not be required to use the push scenario. The topology can support both push and pull scenarios at other tiers of the network. A Push-based relay will use the Reflection mode and not the Translation mode of operation (i.e. the SSRC generated by the origin will be retained throughout the network). 5.5.2 Pull Implications The Pull mechanism implies that the broadcaster/source has to be a full RTSP server implementation. The interior nodes (except the source) need to be RTSP clients and servers and do not need to support SETUP with mode=receive or SETUP_RECEIVE, nor RECEIVE methods. In a Pull-based relay a server (interior node) may retry connections to the origin until the SDP is revoked via an ANNOUNCE, say. In a Pull-based relay, when relay content is no longer available, the relay/server should send ANNOUNCE for all its configured relays and a End-of-stream notification to all of its recipients. The ANNOUNCE request should carry additional headers to indicate preferred relay behavior in the event that the origin server dies. In Pull-based relay nodes, the relay node reinitiates contact with upstream node for streams. In Push-based relay nodes, the relay nodes give the upstream a chance to recover before timing out the sessions. Pull-based relays allow alternate upstream relays. In case the source/upstream node dies, a single retry attempt is made to the source/upstream node, if that fails, the node can connect to an alternate upstream relay. The clients will see an effective PAUSE; i.e. timestamps will skip over the duration of the failover, and sequence numbers will increment by 1, as in case of a PAUSE. Can have NTP-like stratum failover. 5.5.3 Translation in Pull and Push Mechanisms. Translation is only possible with the following semantics in either the Pull or Push mechanisms: C-S SETUP PLAY S->C PLAY response Range: npt:x-y (x is a number, not 'now') RTP-Info OR C->S SETUP_RECEIVE RECEIVE Range: npt:x-y (x is a number, not 'now') RTP-Info In both cases, the Range header must contain a numeric start of range and not 'now', and the RTP-Info header must contain RTP timestamps and urls for each stream. 5.5.4 Interactions between Relay Pull and Push Clients and Servers A Relay Push Client talks to a Relay Push Server, by sending it SETUP w/ mode=receive or SETUP_RECEIVE request, followed by a RECEIVE request, and sends RTP/RTCP data to the Relay Push Server. A Relay Push Server would handle short periods of outage from the origin, and perform no translation of RTP packets and no failover of the Relay Push Client. A Relay Pull Client talks to a Relay Pull Server by sending it a SETUP request/s with mode=play and a PLAY request, and receives RTP/RTCP data from the Relay Pull Server. A Relay Pull Client would translate/transform RTP timestamps and sequence numbers and may use an alternate upstream relay node. A Relay Pull Client needs to be a ANNOUNCE server, if it supports ANNOUNCE methods. If there is a live broadcaster then the broadcaster is a Relay Pull Client or Relay Push Client in either case it is also a ANNOUNCE client, if it supports the ANNOUNCE methods. A relay node that is not a source node, edge node or player is: * an ANNOUNCE client+server if it supports the ANNOUNCE methods, and * one or both of (a) Relay Push Client & Server or (b) Relay Pull Client & Server. 5.5.5 Capability Determination The functionality supported by each interior relay node, which is typically a server can be indicated as follows in an RTSP OPTIONS response. Basic Server => DESCRIBE, SETUP, PLAY Multicast Push Server => ANNOUNCE, DESCRIBE, SETUP, PLAY Unicast Pull Server => ANNOUNCE_RELAY, DESCRIBE, SETUP, PLAY Unicast Push Server => ANNOUNCE_RECEIVE, DESCRIBE,SETUP, PLAY, RECEIVE Unicast Push & Pull Server => ANNOUNCE_RECEIVE, ANNOUNCE_RELAY, DESCRIBE, SETUP, PLAY, RECEIVE Multicast Push, Unicast Push, Unicasll Pull Server => ANNOUNCE, ANNOUNCE_RECEIVE, ANNOUNCE_RELAY, DESCRIBE, SETUP, PLAY, RECEIVE 5.6 Security Issues As mentioned earlier there are two main security concerns: The server may implement RTSP authentication with the Auth header. Authorization may be implemented by other means. In order to support media rights and distribution rights issues the source should not send content to an unauthorized or unauthenticated client. Security issues are orthogonal - and are probably not as much of a concern. Typically the source or relay node would generate the SDP to a set of downstream relay nodes. The reasons why security is probably not a huge concern are: (a) The list of relay nodes is likely to be configured manually - implies that arbitrary hosts won't be contacted. (b) The upstream server can control which SETUP/PLAY requests it can serve, and hence ensure authorized access. (c) ANNOUNCE is over RTSP over TCP, and intercepting TCP is not easy. Also downstream relay nodes can be configured to accept ANNOUNCE messages from a set of known hosts. Security concerns can be addressed if both the source/broadcaster and the server implement some authentication/authorization capabilties. 5.7 Use Cases * N-tier relay with Pull only Interior and edge nodes within the same network with no firewalls between them. When the source and servers are all part of the same network, with no firewalls between them, an n-tier relay using Pull mechanism can be set up. Source sends ANNOUNCE to Server; Server sends SETUP/PLAY to source; Source sends media to server. Server delivers streams to its recipients. * N-tier relay with Push only Interior relay node or source behind a firewall; edge node outside the firewall. In the case where the firewall restricts all access from entities outside the firewall, the Pull model cannot be implemented by the Edge node to access media from a relay node within the firewall. In such cases, the interior relay node has to use Push mechanism to send the streams over to the edge node. Source/Server sends ANNOUNCE, SETUP_RECEIVE and RECEIVE to edge node outside the firewall, and then sends streams over TCP to edge node. Edge Node delivers streams over UDP or TCP to its recipients. * N-tier relay with Push and Pull Source with partial RTSP implementation and servers as relay nodes makes up this topology. At the first tier, the source can use Push to send content to the servers. The servers in other tiers can use Pull to access streams from the upstream relay nodes. 6. Summary This document identifies the main issues in broadcast and relay of stored and live content and proposes two relay modes, Reflection and Translation, two mechanisms, Pull and Push. These modes and mechanisms together with the automatic publish mechanisms can enable a wide variety of n-tier relays. Several important use cases of relays have been demonstrated. New RTSP primitives are recommended. - SETUP with mode=receive and a RECEIVE method. This introduce only one new RTSP method, and re-use SETUP with the same semantics as SETUP/RECORD in RFC 2326. If the use of the existing RTSP SETUP method to support Push mechanism, is not desired, then another new RTSP method, SETUP_RECEIVE, is needed. - In addition three RTSP methods, ANNOUNCE, ANNOUNCE_RECEIVE and ANNOUNCE_RELAY are introduced to signal availability of content as well as to signal capability of the relay node. - A few additional RTSP headers are recommended for the purpose of identifying (a) content expiry, (b) relay failover/recovery options, (c) content revocation. These small changes to the core spec would go a long way towards enabling n-tier relays. 7. Acknowledgements The authors would like to thank Aravind Narasimhan and Thomas Weng for their feedback. 8. Authors Addresses Geetha Srikantan Email: geetha.srikantan@sun.com Sun Microsystems 15 Network Circle UMPK15-215 Menlo Park, CA 94025 USA John Murata Email: murata@apple.com Apple 1 Infinite Loop Cupertino CA 95014 USA Andrew Large Email: andrew.large@sun.com Sun Microsystems 15 Network Circle UMPK15-215 Menlo Park, CA 94025 USA 9. References [1] Schulzrinne, H., Rao, A., Lanphier, R., "Real Time Transport Protocol (RTSP)", RFC 2326, April 1998. [2] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [3] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [4] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., Narasimhan, A., "Real Time Streaming Protocol (RTSP)", draft-ietf-mmusic-rfc2326bis-05.txt, October 27, 2003. 10. IPR Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 11. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This Internet-Draft expires June 3 2004.