Subject: scenarios for discussion at streams BOF to test protocol

From: Scott Petrack <[email-masked]>
Date: Tue, 22 Oct 1996 15:03:20 +0200

I would very much like to come to the StreamsControl BOF II, but I have just
begun a new job and am very far away. I would like to offer a few 
scenarios that I hope will illustrate my concerns. Perhaps you could
discuss them at the meeting.

There seems to some suggestion that RTSP has one scope, 
and perhaps Jeff Smith's protocol has another. My
basic concern is that these "scopes" overlap so much as to be
indistinguishable. I think that it is very possible to have a 
single protocol, and to say that one can always implement a subset
of the protocol if that's all that one needs. Not every client of
a protocol implements the full protocol.

1. Retrieving or leaving voicemail (or MM mail) from within
an IP phone application. More generally, switching in and out 
between some IVR system and an IP phone application. Also,
IP phone calls where one of the parties is an automated attendant.

	If the "streaming model" has one control protocol and the 
	"telephony model" has another, is it intended that a telephone
	client will have to implement two separate protocols?

	The differences between "streaming" and "collaboration"
	(I prefer this to "telephony") is that the requirements for 
	what delay and jitter are tolerable are different, and that you
	can perform some extra manipulations when streaming (e.g. fast forward).
	I don't see how this should affect the control protocol.

2. Listening to a streaming broadcast where the stored RTP streams 
are on physically different machines.

	Suppose I have one machine with video streams stored on it and
another machine with the sound tracks stored on it (perhaps because
for each video I have the sound track in 50 languages). I would like
to just send stream control info to some multicast group and have
the two servers listen. I would get much worse service if I
need to have two separate control channels (for example, when I
press fast forward).

	I think that this is what David called "many-to-one."

3. Many people, located in different places, all listening
to a single RealAudio broadcast at the same time, and discussing it 
together. 

	(How we "discuss together" isn't really relevant here. Let's
	say that we use vat or whatever. The important thing is the scenario
	that we are "watching the broadcast together.")

	The idea is that "I want to watch some TV with my friends,"
	except that my friends may be in a few different locations. Just like
	in real-life, let's say that only one person can control the stream
	at a time, but that the control might pass from person to person
	over time (as I fight with my friends for the remote control ;-)).

	This is trivial to do if my friends and I and the RealAudio server
	all share a multicast group. We will do whatever standard is available
	to ensure that only one person can send control info at a time. (e.g.SCCP)

	It seems hard to do if each friend needs to have his own control
	channel. 

	I believe that this is David's one-to-many scenario.

4. It's perfectly natural to combine 2 and 3: lots of people watching
together, and the stored RTP streams are spread accross multiple
machines. 

	I might even want to watch a film with my Japanese friends,
	and get the English audio stream while they get the Japanese one.
	But I'd like the control channel to be shared so that we can 
	be certain that we are seeing the same thing, and can pass the control
	around. 

There are many other very natural scenarios which combine 'streaming'
and 'collaboration', and which combine one/many to one/many control.	
I can definitely see the need for a simple lightweight playback
standard, but I would rather see this realized as a subset of a 
control protocol for RTP streams. And I think that the distinctions
between collaboration/telephony and streaming don't imply that there should
be different protocols - I'd like to use SxP for call setup, something
(SCCP?) for conference policy, and some not yet determined stream control
protocol for stream control. I'd like that to run use RTCP for transport,
so that it could take advantage of things like CNAMEs. Of course, many
atoms of this protocol are exactly what are in RTSP.

Scott

---

From: Mark Handley <[email-masked]>
Date: Tue, 22 Oct 1996 14:52:31 +0100

>a protocol implements the full protocol.

I very much agree with this sentiment.

>protocol for stream control. 

This was pretty much what was discussed at the Streams BOF in Montreal.

I see RTSP as being a potentially good basis for that stream control
protocol, but it would be necessary to extend its scope to do what
many of us require.  At UCL, we have a multimedia server which
(remotely) records and plays back Mbone sessions, and we're looking
for a control protocol to drive this - both for recording and
playback.  Playback would often be into a pre-existing Mbone session,
hence the use of SIP to tell the server about the session.

There's a huge amount in common between this, what Jeff's proposing
and RTSP.

>I'd like that to run use RTCP for transport,
>so that it could take advantage of things like CNAMEs. 

I'd prefer it to use RTP for transport because I don't like the way
RTCP is associated with a single media stream.  An additional
RTP-based control stream seems to have many of the right properties,
whilst maintaining good separation between session stream control and
media stream control.

>Of course, many atoms of this protocol are exactly what are in RTSP.

Agreed.

Mark