Subject: Re: RTSP "sessions", "streams", "components", and URIs

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Feb 1997 15:16:17 -0500

Thanks for pointing this out - all the authors are aware that the
current terminology is both inconsistently used within and outside the
document. One proposal would be use the terms "track" and
"presentation", since stream has too many conflicting uses already.
(RTSP "lives in" both the SDP name space and the RTP name space, for
better and for worse.) Just using "session" doesn't help, since we do
need to name individual media streams (say, only the audio part of a
movie).

I cc'ed this to confctrl, I think that's where the discussion belongs.

John H Wilson wrote:
> 
> IMHO, RTSP could avoid some confusion over the term "session" by being
> self-consistent.
> 
> SDP defines the term in one sense: a collection of streams with a common
> time-line.
> 
> RTP defines the term in another sense: a single media stream (along with
> its parallel "control" stream (RTP/RTCP).
> 
> RTSP has absorbed both terms.
> 
> In Section 1.3, it is used in the SDP sense; in section 6.2, GET
> retrieves a session description, and in section 6.11, SESSION allows the
> server to send the client a modified session description with new or
> deleted "components" (it is not clear, but I think "component" is
> synonymous with "stream".)
> 
> In section 8.24, session is clearly refering to a single stream
> (consistent with RTP, but RTSP does not insist on its use). It defines
> the session header field which identifies the state of a single stream
> on which SETUP(6.3), PLAY(6.4), PAUSE(6.5), and CLOSE(6.6) operate.
> 
> IMHO, "stream" should be used for SETUP, PLAY, PAUSE, CLOSE, and should
> replace the term "component" in the definition of the SESSION request.
> The "session" header field would become the "stream" header field.
> 
> On a minor, related, point, I wonder why all requests must contain a
> Request-URI. PAUSE and CLOSE, for example, must operate on an existing
> "stream"; if the Request-URI does not match the "stream" ID, I suppose
> it is a protocol error? What would the Request-URI be used for in these
> two requests?

You can PAUSE and CLOSE an individual track (say, the audio track)
without PAUSEing or CLOSEing the whole presentation (audio and video,
say) or you can indeed PAUSE the whole show. The session id is the same
in both cases, the URI is not. "Invalid session id" is, I think, one of
the possible error codes. (Whether Session should be a concept within
RTSP or whether RTSP should borrow the HTTP state maintenance mechanisms
for its purposes is another debate...)

> 
> [email-masked]

Henning
-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

---

From: John H Wilson <[email-masked]>
Date: Thu, 27 Feb 97 17:19:00 PST

Text item: 

OK, suppose we use "Presentation" instead of "Session"
               and "Track"        instead of "Stream"

I'm still a bit puzzled about the model:

>for its purposes is another debate...)

My questions are:

1. I assume SETUP is always track-specific; whether it is the intial 
   SETUP or not.

2. I assume that a PLAY that does not specify a track id, must 
   specifiy a track URI, and gets a track id in return. (I.e., 
   cannot operate on a presentation basis) True?

3. Is there such a thing as a presentation id? I assume not, since 
   I see no request that generates one.

4. If (as you say) the "session id" is the same to PAUSE/CLOSE either a         
   presentation or a track, and the difference is in the URI, then  to          
   PAUSE/CLOSE a presentation, I must be able to use ANY track id in the        
   presentation + the presentation URI....true? If this is the case, I 
   assume that, once a presentation has been PAUSEd, it can be resumed 
   by sending a PLAY with ANY track id + the presentation URI?

5. I assume that track id's are not client unique. If there are multiple        
   listeners to a track (it is being multicast), these clients can provide some 
   way to pass the track id around, so that any of them can use the same (track 
   id + URI) to PAUSE/PLAY/CLOSE the track. This is the so-called "pass the     
   remote" scenario, except that RTSP provides no mechanism to prevent "multiple
   remotes"?

[So far, I've concluded that SETUP is track-specific, while PLAY, PAUSE & CLOSE 
are not.]

Two presentation description questions:

  - SDP does not seem provide the necessary track-specific URI information; 
    do you intend to propose the necessary extensions?
  - where can I find a definition of SDF?

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Subject: Re: RTSP "sessions", "streams", "components", and URIs
CC: [email-masked], [email-masked], [email-masked]
To: John H Wilson <[email-masked]>
Organization: Columbia University, Dept. of Computer Science
From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Feb 1997 15:16:17 -0500
Sender: [email-masked]
ntel.com (8.7.6/8.7.3) with ESMTP id PAA08232; Thu, 27 Feb 1997 15:55:50 -0800 (
PST)
Return-Path: [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Feb 1997 20:52:55 -0500

The "Session" identifier (we should probably pick a different name for
that header if we change the naming...) is always for the whole
presentation and is conveyed by the server at the first opportunity,
regardless as to whether the request is for a track or the presentation.
There is no need for a track id.

[Sidenote: servers can generate dynamic session descriptions which
incorporate some form of presentation identifier and then don't need the
Session header. Client doesn't care; works either way.]

The presentation description ("extended SDP") must provide an RTSP URL
for the whole presentation as well as for each track. These may or may
not be hierarchical (e.g., the whole movie could be called a.mov and the
tracks b.mov and c.mov, without directory hierarchy).

Client says:

SETUP rtsp://foo.com/movie/audio.en

Server says:

200 OK
Session: 12345

12345 is now used for the whole presentation - Session ids are never for
a track. If a new client wants a different stream (unicast), it gets a
different identifier, but likely the same URI.

[Side remark: HTTP state maintenance makes that a bit clearer since it
includes the Path, thus it allows both types.]

Client then says:

PLAY rtsp://foo.com/movie
Session: 12345
Range: some range spec

Server says:

200 OK
Range: range we are actually playing

Client can issue a PAUSE or CLOSE for each track or for the whole
presentation. Session number (12345) is the same in either case, but URI
differs. Semantics of PAUSE for a track is more like muting, since the
rest of the presentation keeps on playing. PLAYing the track again
maintains synchronization (that is, you skip the track whatever piece of
the movie went by).

Hope that clarifies things a bit.