Subject: [MMUSIC] Proposal for Streaming Relays - RTSP additions

From: Geetha Srikantan <[email-masked]>
Date: Tue, 02 Dec 2003 16:16:41 -0800

Hello,

As discussed at the MMUSIC meeting in Minneapolis, we would like to
outline usage scenarios for certain RTSP methods. We'd like to propose a
few RTSP additions to support n-tier streaming relays. Enclosed 
is a proposal on the topic.

thanks
geetha

Streaming Relays
Date: 12/2/2003
Geetha Srikantan <[email-masked]>
John Murata	 <[email-masked]>
Andrew Large     <[email-masked]>

1.0 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. 

2.0 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.0 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.0 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.0 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 
<NPT, RTP sequence number, RTP timestamp> 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 <NPT, RTP sequence number, RTP timestamp> 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: <date/time>" can be used to indicate the lifetime
  of the SDP being ANNOUNCE'd.
  "x-relay-recovery: <retry frequency/duration>" 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 <url,timestamp>    
OR

C->S SETUP_RECEIVE
     RECEIVE Range: npt:x-y (x is a number, not 'now')
	     RTP-Info <url,timestamp>

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.0 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.0 Acknowledgements

The authors would like to thank Aravind Narasimhan and Thomas Weng for
their feedback. 

8.0 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.

-- 
Geetha Srikantan <[email-masked]>

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic