Subject: RE: SDP syntax with RTSP

From: "Anders Klemets (VXtreme)" <[email-masked]>
Date: Tue, 9 Sep 1997 21:00:40 -0700

On Sunday, September 07, 1997 11:31 PM, Stephen Casner
[SMTP:[email-masked]] wrote:
> If redirection is not allowed in the DESCRIBE, then you don't need the
> proxy attribute because it is implicit that the opaque URLs get sent
> to the same place whence the DESCRIBE came.  If redirection is allowed
> and the host that sent the DESCRIBE is the one that is going to
> provide control, then the URLs should start with its hostname.  The
> remainder of the URL tells where the data comes from, in any format
> that is legal and meaningful to the proxy.  The client doesn't need to
> know that proxying is going on, and should not be required to take any
> other special action.  (I think I've been making this argument
> before in a slightly differnt context.)
> 
> I don't see that the a=rtsp:DESCRIBE is needed, either.  When you
> start an interaction with an RTSP server, you do a DESCRIBE.  If that
> session description redirects you to another RTSP server (assuming
> we've made that choice), then you do another DESCRIBE on that new RTSP
> session.  If it doesn't, you don't.

I agree completely with the points that you are making here.

I think that when a client is redirected to a new server, it's in its
best interest to send a new DESCRIBE command to that server.  The client
should not take for granted that all the information in the presentation
description that it got from the first server was accurate, or complete.

There might be special cases where a redirecting server is tightly
synchronized with a server that it redirects to.  But I see this as an
exceptional situation.  In such a case, the client might not need to
send a second DESCRIBE command.  As an optimization, one may want to
inform the client that the second DESCRIBE is not needed.  This could be
done by adding a special attribute to the SDP record, such as this:
  a=rtsp:no-DESCRIBE

Anders

---

From: "Anders Klemets (VXtreme)" <[email-masked]>
Date: Wed, 10 Sep 1997 22:58:41 -0700

On Wednesday, September 10, 1997 4:23 PM, Stephen Casner
[SMTP:[email-masked]] wrote:
>     I think a case can be made for that, e.g., for multicast, where we
>     could have passive clients (without RTSP capability even), just
>     taking c= information as is, and 'remote control' clients that
>     have the ability to interact with the stream via RTSP, suitably
>     coordinated, naturally.
> 
> If we need to have both pieces of information in some uses of SDP,
> then I think we want the URL information to be provided by a means
> other than c= so that the URL is provided in the same way in all uses
> of SDP.
> 							-- Steve

Right.  For multicast sessions, the SDP media description might have to
specify both a URL for RTSP control as well as the multicast group onto
which data is sent.  However, I don't think it should be a problem,
because it appears to be possible to specify both "c=IN IP4" and "c=IN
URL" in the same media description.  Look at page 10 in version 4 of the
SDP draft, which was released just a few days ago.

There is an example on page 10 where multiple "c=" lines are used when
the server transmits on multiple multicast groups.  However, there is no
mention in the draft that the use of multiple "c=" lines would be
restricted to an MMG scenario.

Anders