Subject: confused about identifying RTSP sessions

From: Philipp Hoschka <[email-masked]>
Date: Fri, 23 May 1997 14:50:00 +0200

Section 1.1. of the current RTSP draft (March 29) states:

"There is no notion of an RTSP connection, instead, a server maintains
a session labeled by an identifier. .. Duringt an RTSP session, an RTSP
client mahy open and close many reliable transport connectsion to the server
to issue RTSP requests"

The question is: what is the identifier, and what are the rules for
using it ?

The current spec mentions three different identifiers

1) the "session" header
2) HTTP state management
3) unique URLs generated dynamically (in Appendix A: "A server may choose to
  generate dynamic presentation descriptions where the URL is unique for a
  particular RTSP session and thus may not need an explicit RTSP session
  identifier in the request header")

This seems to imply that the server MUST use either 1) or 2) (I didn't check
if 3) is really equivalent to 1) and 2) - if so, it shouldn't be mentioned
in the Appendix only)

Otherwise, it won't work, because:

- If the client doesn't get a ssession id from the server, it cannot
 cut the TCP connection before it ends the session, because there is no way to 
 identify requests that belong to the session

- The server doesn't know what the client will do in future, so it
  must send the session id (or use HTTP state maintainence)

On the other hand, most of the example requests in the document
do not contain any way to identify a session, which seems to 
imply that identifying the session is something which is optional.

Or are the requests in the examples uniquely identified by the URL ?

Could somebody clarify this ? It should also be made clearer in the
document.

---

From: Anup Rao <[email-masked]>
Date: Fri, 23 May 1997 10:07:38 -0700

>   identifier in the request header")

Thanks for pointing this out. Points 1), 2) are easy to clear up. 2) was
mentioned as an alternative to 1) and the choice between them was an
open issue at Memphis. This was decided in favour of 1). Hence the
Session: header will be sole identifier of a RTSP session across
transport connections. The references to HTTP state maintenance will go
away in the next draft.

At the time of the March 29th draft, we were debating on the means of
identifying sessions accross connections and client endpoints. As such,
3) (which might still work) seems to be an  overloading of URLs without
apparent gain. In the next draft, we should have a *clear and concise*
definition for session identification and that will be 1)(The Session:
header).

> imply that identifying the session is something which is optional.

The first example is pretty detailed, and has the Session: headers. The
others do not, (but I do believe that they mention that some of the
responses/headers are excluded for simplicity). We will take care of of
this in the next draft.

Regards,
-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : [email-masked]         Phone : (415) 937 3129       
-----------------------------------------------------------------