Subject: RTSP session model

From: Alagu Periyannan <[email-masked]>
Date: Tue, 8 Jul 1997 14:50:13 -0700

Hi all,

So now if we agree to drop 1-n-n, we are left with
1-1-1 and 1-1-n.

The terminology x-y-z started off as,

x = number of containers
y = number of RTSP sessions and PLAYs
z = number of Transports

The number of containers should not matter to RTSP.
In any case, if we decide to drop 1-n-n, then x=y
always.

The other problem is, the latest 1-1-n model allows
multiple PLAYs even though y=1 and so is confusing.

A better way to name these would be,

old name 1-1-1         new name MUX
old name 1-1-n         new name NONMUX

MUX refers to sending all the media multiplexed in one transport
and NONMUX refers to sending each media in a separate transport.
The response to DESCRIBE must clearly state which model to
use either MUX or NONMUX. Otherwise it will be hard to achieve
interoperability. THIS I THINK IS IMPORTANT.

The SETUP should be associated with each media not with each
transport as is currently envisioned. The number of SETUPs sent
should be left to the client with the following basic rules,

- In the case of MUX, the client can send one SETUP for
all the media or one SETUP for each. When sending multiple
SETUPs, the first SETUP negotiates most of the transport parameters.
(Multiple SETUPs allows adding media later.)

- In the case of NONMUX, the client MUST send one SETUP
for each media.

Whether one SETUP is sent or multiple are sent, they must
use the same RTSP session if they have to be streamed out
in a synchronized fashion by the server.

In either model one should be able to PLAY/PAUSE individual media
with the "streamid" header or PLAY/PAUSE all media together.

comments?

---------------------------------------------------
Alagu Periyannan                   [email-masked]

Interactive Multimedia Group
Apple Computer, Inc.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Jul 1997 09:40:49 +0200

> should be left to the client with the following basic rules,

That is not possible, since SETUPs primary role is to negotiate
transport parameters, so that each independent transport association
needs a separate SETUP. If one or more streams share 

The rule should be simple, regardless of whether multiple streams are in
a single transport or not. Mux and non-mux do not capture the variety of
scenarios that are possible, for example with 3 streams (audio, video,
animation). [The URL and transport header just gives the flavor; it's
known to be non-valid syntax...]

Here's my synopsis of the current thinking; I can't quite tell if this
is the same or different than what Alagu is proposing.

In each case, we assume that we got a session Id from the server via an
empty SETUP:

  SETUP movie

  200 OK
  Session: 123

Naturally, we could also use the first SETUP in each example below to
get the session id.

---------

(2+1) audio and video are together (maybe MPEG or some container
format), animation is separate:

  SETUP movie
  Session: 123
  Streamid: audio, video
  Transport: rtp/udp

  SETUP movie
  Session: 123
  Stremaid: anim
  Transport: tcp

  PLAY movie
  Session: 123
  Streamid: audio, video, anim

  # pauses delivery of the animation and audio
  PAUSE movie
  Session: 123
  Streamid: anim, audio

  # pauses delivery of the video
  PAUSE movie
  Session: 123
  Streamid: video

  # resume delivery of audio, video, animation; we don't need
  # the streamid here since it's the whole session
  PLAY movie
  Session: 123

  # tear down video (don't ask me why the client does this...):
  TEARDOWN movie
  Session: 123
  Streamid: video

  # tear down the remaining streams:
  TEARDOWN movie
  Session: 123

-------

(3) all three are in one transport
  SETUP movie
  Session: 123
  Stream: audio, video, animation

  PLAY and TEARDOWN is as in (2+1).

--------

(1+1+1) each of them is a separate stream

  SETUP movie
  Session: 123
  Stream: audio
  Transport: rtp/udp;port=3400

  SETUP movie
  Session: 123
  Stream: video
  Transport: rtp/udp;port=3456

  SETUP movie
  Session: 123
  Stream: animation
  Transport: tcp;port=10000

  PLAY and TEARDOWN as before

-----

The issue of how a session description format tells the client what to
do is beyond the scope of RTSP (and should be). If a server can't
control separate media within a transport stream (too lazy, say), there
are a number of choices:

- just keep shoveling the data and let the client sort it out
(client-side muting)

- indicate an error and hope that the client is smart enough to stop the
whole stream bundle 

> in a synchronized fashion by the server.

Note that synchronized streaming by the server is neither necessary nor
sufficient for synchronized presentation at the client. 

Henning

---

From: Alagu Periyannan <[email-masked]>
Date: Wed, 9 Jul 1997 10:58:45 -0700

>needs a separate SETUP. If one or more streams share

This boils down to, do we want SETUP to control a media or
a transport. If we have SETUP control a media, it will
allow addition and subtraction of media easily.

In your 2+1 example, is it possible to SETUP audio and animation
and later add video?

>is the same or different than what Alagu is proposing.

My simplification to MUX and NONMUX ignored the case where
you need a combination of both. I thought this would complicate
things leading to interoperability problems.

I am not opposed to a combination of MUX and NONMUX. However,
it is important that the client knows the grouping, i.e.
whether 1+1+1, 2+1 or 3 is used in your example.

This issue may be out of the scope of RTSP, but there must be
some mention in the spec. that the client can not arbitrarily
decide the grouping.

For those working on the SDP format for use with RTSP, I think
SDP should state the grouping being used.

On a separate issue, have we come to an agreement as to whether SDP
should carry any transport info. at all? Does RTSP require or prohibit
the media description format from carrying transport information?

>sufficient for synchronized presentation at the client.

I agree with your statement above. That is why I say that,
"they must use the same RTSP session IF they have to be
streamed out in a synchronized fashion by the server."

If the client does not want the server to stream it out
in a synchronized fashion, then each stream might as well
be in a separate RTSP session. (This is the same as my argument
for dropping 1-n-n.)