Subject: Re: Re : RTSP

From: Martin Dunsmuir <[email-masked]>
Date: Fri, 18 Oct 1996 10:40:30 -0700

I think it would be a great idea to have anyone interested meet soon in the
Bay Area to discuss RTSP.

Rob Lanphier is the contact here at Progressive. If NTT could host it would
be great, but we would also I am sure be able to meet at Netscape.

For what it is worth, I have attached a discussion of the RealAudio
applications model, which might be helpful in understanding RTSP.

-----------------------
The RealMedia Model
Martin Dunsmuir
Porgressive Networks

We have six elements in our current model: Servers, Splitters, License
Servers, System Managers, Players,  and Encoders. These elements form a tree
heirarchy for any given stream. Each stream has an identifier (URL) which
identifies the server originating it and the object in that server's
namespace (the RealAudio file). Both live and on-demand streams (the former
originating from live encoders and the latter originating from files) appear
in a single heirarchical namespace maintained by the server.

Servers accept connections from Players and other Splitters. Each such
connection takes the form of a TCP connection. Player connections support
the semantics needed for random access for on-demand (stop, start, seek,
pause and resume) and simple stop/start for live streams. The TCP connection
remains in place until the player terminates the connection, at which point
a single packet of quality of service information is forwarded to the server
over the TCP link before the player disconnects. The delivery of data from
the Server to the Player can be in three modes: UDP unicast, TCP unicast and
UDP multicast. To cope with packet loss uor players also support UDP-resend
requests for UDP unicast connections. The type of connection is a function
of the player, which chooses TCP or UDP and the server, which chooses
multicast or unicast for UDP connections. In the case of Multicast, the
Server communicates the UDP port and Class D address to listen on to the
Player at startup, in the case of Unicast the Server communicates the UDP or
TCP port (which is always the control port) on the Server's Class C IP
address. In the case of Splitters the connection is always TCP and the
control channel supports a protocol for license management, whereby the
Splitter can accept connections and cause the stream license of the
originating server to be decremented. This latter protocol is asynchronous
using a debit/credit system to prevent synchronous license requests from
killing the server. There is only one Server/Splitter connection per stream
being split by a given Splitter. The TCP delivery from Server to Splitter
assures that the stream is pure, at the cost of buffering in the Splitter
(the depth of the buffer being a configuration parameter of the Splitter).

Since Servers can be configured as multiple processes or Clusters of
different hosts, the Player-Server connection also supports "redirection",
whereby the Player is silently redirected to re-connect to another host
during connection to achieve load balancing. In the future we plan to use
redirection based on other heuridtics such as redirecting players to the
topologically closest Splitter or Cluster member. Splitters can also be
clustered.

Another aspect of our Server-Player protocol is "bandwidth negotiation". The
Player communicates its capabilities in terms of bandwidth and codecs to the
Server which selects a "profile" for delivery to the Player which matches
this, Currently profiles comprise single audio streams but in the future we
plan to support sessions with multiple streams, grouped into profiles. Also
the protocol supports the selection of streams by the Player on a dynamic
basis. For example, the user could choose to switch between cameras on a
multiple video session. In our more complete model the player should be able
to respond dynamically to a new stream arriving mid-session and route the
data to the appropriate Player module for play-back.

The Splitter is actually a function of the Server, but a Server can be
configured for Splitting alone.
Splitters look like Servers to players, the only difference being that they
are addressed as proxies, either within the Player by static configuration
(the default Splitter) or explicitly in the URL. Splitter URL's take the
form pnm://splitter/pnm://server/filename... The Player strips off the
pnm://splitter/ piece and passes the remaining URL to that Splitter over a
standard Player-Server connection. Splitters can be nested in URL's more
than one deep, in which case each level removes the splitter suffix and
forwards the remaining URL to that Splitter. Splitters too can be configured
with default proxies to use as their Splitters.

Splitters, like Servers, and although they always recieve their inputs via
TCP, can deliver data to Players via TCP or UDP (unicast and multicast).
There are many elements of splitting which need further work, specifically:
caching on-demand content, roll-up statistics to Servers and the forwarding
of user input to the Servers (e.g. interactive user choices); protocols for
finding Splitters by Players based on network topology and the insertion of
content as data travels through the Splitter heirarchy; and, setup of
Multicast over the Internet. Another area for future work is Player
Authentication. Today we support what we call validation, whereby the Server
or Splitter and Player ensure that they are bona-fide RealAudio components.
Authentication is the function of allowing access based on Player identity,
tickets or other criteria.

Typically Servers will be configured to reserve some or all other their
connections for Splitters and can explicitly setup the IP addresses of those
Splitters. Splitters can be configured to explicitly allow Splitting of
certain Servers and streams. Player connections too can be confined to
certain IP addresses or subnets.

License Serving is another function of the Server. Servers can get their
licenses (for a number of streams) based on a static key in their local
configuration file, or from another "License Server" at startup. In fact the
two capabilities can work together, with a fixed local license augmented
from a License Server. Splitting functions always depend upon the dynamic
license protocol described above and are in addition to any "Server License"
which controls the origination of content at the server itself.

System Managers are entities which connect to Servers and Splitters and
allow the configuration to be dynamically viewed and modified, they use a
different protocol, which is a dialect of RBP (as are all our protocols
although the document you have only describes the Server/Player piece). Our
direction currently is the Server also support SNMP. The connection of a
System Manager to a Server is controlled in two ways: a password and the
ability of a Server to specify explicit IP addresses from which it will
accept System Manager connections. 

Players are pretty self-evident in their function, but it is important to
understand that we see the TCP connection between the Player and the
orginating point (Server or Splitter) of its session as very important to
allow the originators of content to gain explicit information about who is
listening. Looking down from the origination point the System Management
functions should allow a Server operator to see exactly who is connected to
all sessions originating from themselves. At any point in the
Splitter/Server Heirarchy the owner of a Splitter should be able to see all
traffic it is passing and who, downstream is connected. It is also explicit
in our model that connections are initiated upstream, although this could
change.

Finally, Encoders. Encoders take raw input, compress it and pass it over a
TCP connection to a Server. The encoder supplies a password to the Server
(and may have to be associated with explicit IP addresses setup on the
Server) and also provides a virtual filename and codec type for the stream.
Within the Server mutiple streams with the same filename, but different
sources are combined into a session with that filename, as seen by Players
or Splitters. Today the model does not fully support profiles within Live
Sessions but it should.

---

From: Jeff Smith <[email-masked]>
Date: Fri, 18 Oct 1996 12:47:04 -0700

I personally believe that a smaller meeting of "key individuals" would
be more productive (our research on collaboration shows max
10)... essentially a BOF.

I have not received massive response from my offer - about 5 or 6
people - so I still believe a smaller meeting is in line.

We also have facilities for mbone'ing the meeting so Mark and others
may be able to participate.

If people disagree then let me know I'm willing to be persuaded
otherwise - but I do not intend this meeting to "replace" discussions
at the IETF nor do I want it to be a "sell job" for RTSP.  I'm hoping
for focused, constructive discussion finding "common ground" and
exploring the various facets of stream control in 1:1,1:n,n:1,n:n
situations - this usually means a small number of people.

Rob Lanphier has contacted me as has a person from Microsoft.

 |>I think it would be a great idea to have anyone interested meet soon in the
 |>Bay Area to discuss RTSP.
 |>
 |>Rob Lanphier is the contact here at Progressive. If NTT could host it would
 |>be great, but we would also I am sure be able to meet at Netscape.

I hope to have an agenda and list of attendees up on the web beginning
of next week.  Probably in http://www.nttlabs.com/~sumisu/streams-bof/

js

--
 Jeffrey D. Smith     【ジェフリー・スミス】
 Nippon Telegraph and Telephone Corporation   
 Software Laboratories Palo Alto	              
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: [email-masked]

---

From: Jeff Smith <[email-masked]>
Date: Fri, 18 Oct 1996 14:50:33 -0700

>Martin Dunsmuir <[email-masked]>:
>I think it would be a great idea to have anyone interested meet soon
>in the Bay Area to discuss RTSP.

For all interested parties - I have ten people planning to attend the
Bay Area meeting to conduct preliminary discussions regarding finding
common ground between RTSP and other work taking place.  These people
include the authors of RTSP and the chair of AVT...

As I said in my last post - I really prefer a small, concentrated
gathering for this meeting.  I don't intend this to be "exclusive" but
I am going to have to go with the ten members we have now for the
first meeting.

I will multicast the session (look for announcement in SDR).

Those of you attending the Real Time Web workshop next week in France
please talk to the guys from Progressive and to Mark Handley - your
input will make it to the meeting this way.

js

---

From: Philipp Hoschka <[email-masked]>
Date: Sun, 20 Oct 1996 20:50:28 +0200

>input will make it to the meeting this way.

Note that Rob will give a talk on RTSP at this W3C workshop. 
It will talke place on Friday 25 at 2 MEST, and both
the talk and the discussion will be transmitted on the MBone.
See the announcement in sdr for further details.

-Philipp Hoschka