Subject: RTSP enhancement

From: John Carlton <[email-masked]>
Date: Wed, 22 Nov 2000 14:41:41 -0800

All,

There have been several occasions when we have wanted/needed to maintain
state prior to the SETUP request/response in the RNWK client/server
conversation. The best example is dynamic content, when successive
DESCRIBEs for the same URL will result in the server returning sdp for
different content. The server needs to know unambiguously at SETUP time
which content is being accessed. We have uncovered other cases where this
is desireable in our architecture as well.

The easiest way to maintain this state is simply to allow the client to
request early establishment of the session id. The idea that we have is to
allow the client to request a session id prior to SETUP by appending a
special header to the OPTIONS request by inserting the header "Pragma:
initiate-session" in our current beta version of our software. If the
server supports this it responds with a "Session" header, otherwise it is
ignored.

This works great and has the added benefit of making it easier for a proxy
to correlate detailed information in the SDP response with a given session
as well.

It is true that there are other ways to address the problems summarized
above.  Previous versions of RealServer and RealPlayer have used an ETag
solution that was discussed on this list a couple of years ago (though
never formally documented).  However, we've discovered that that creates
unnecessary complication to players and intermediate devices, and so we'd
like to propose a simplified version.

We believe that early establishment of a session id simplifies
implementation for the majority of applications and that ease of
implementation is important enough to justify including this feature in the
spec.

It may be worthwhile to issue an Internet draft documenting this extension
as a proposed extension (say: "Pragma: initiate-session"), but we'd like to
discuss this with the group first.  There's other things we've done to make
this work better with proxies ("Via" header tricks), but lets start with
the basics.

---

From: "Anders Klemets" <[email-masked]>
Date: Fri, 24 Nov 2000 14:04:24 -0800

The RTSP spec outlines the use of the "a=etag" SDP attribute.  It is my
understanding that the purpose of this SDP attribute is to solve exactly
the problem that you have in mind.  If an RTSP client obtains and SDP
record which contains the etag attribute, the client will then be able
to include the etag in the SETUP request's If-Match header.  This allows
state to maintained between SDP and the SETUP request.

Have you found problems with this approach?  I think the first thing we
need to do is to come to an understanding of why the Etag approach is
not working.  If everyone agrees on that using Etags is a flawed
mechanism, then we might be able to remove it from the spec and replace
it some new mechanism, such as your "Pragma: initiate-sesion".

Anders

-----Original Message-----
From: John Carlton [mailto:[email-masked]]
Sent: Wednesday, November 22, 2000 2:42 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RTSP enhancement

All,

which content is being accessed. We have uncovered other cases where
this

The easiest way to maintain this state is simply to allow the client to
request early establishment of the session id. The idea that we have is
to
allow the client to request a session id prior to SETUP by appending a
special header to the OPTIONS request by inserting the header "Pragma:
initiate-session" in our current beta version of our software. If the
server supports this it responds with a "Session" header, otherwise it
is
ignored.

This works great and has the added benefit of making it easier for a
proxy
to correlate detailed information in the SDP response with a given
session
as well.

unnecessary complication to players and intermediate devices, and so
we'd

We believe that early establishment of a session id simplifies
implementation for the majority of applications and that ease of
implementation is important enough to justify including this feature in
the
spec.

It may be worthwhile to issue an Internet draft documenting this
extension
as a proposed extension (say: "Pragma: initiate-session"), but we'd like
to
discuss this with the group first.  There's other things we've done to
make
this work better with proxies ("Via" header tricks), but lets start with
the basics.