Subject: RE: RTSP 1b & e. 1-1-n & Use of SDP within RTSP

From: "Anders Klemets (VXtreme)" <[email-masked]>
Date: Wed, 3 Sep 1997 22:32:19 -0700

On Thursday, August 28, 1997 10:47 AM, Rob Lanphier
[SMTP:[email-masked]] wrote:
> 
> What this approach allows is the clean creation of a coordinator
proxy.  By
> returning this presentation description, the RTSP server is
volunteering to
> make the coordination happen, and thus isn't imposing it on the
client.
> The client can then treat the URLs as opaque stream identifiers.

I think it is inconsistent to sometimes treat URLs as opaque stream
identifiers, and sometimes not.  Below is an example of how this problem
can be solved.

Suppose the host "proxy.com" is a coordinator proxy.  We want the client
to play a program called "something/other.dsp" that is maintained by the
server "foo.com".  
If a client gets an RTSP URL from an HTML EMBED or OBJECT tag, the URL
can look in two different ways:

rtsp://proxy.com/rtsp://foo.com/something/other.sdp

or

rtsp://foo.com/something/other.sdp

In this second case, the client needs to know, somehow, that it is
supposed to send the RTSP DESCRIBE command to "proxy.com".  Perhaps it
is a manual configuration parameter, or maybe a some client
autoconfiguration protocol is used for this purpose.

Now, assuming the client is connected to proxy.com, the RTSP messages
look like this:

C->S:
  DESCRIBE rtsp://proxy.com/rtsp://foo.com/something/other.sdp

S->C:
  RTSP/1.0 200 1 OK
  Date: Tue Jul 22 17:11:12 1997
  Content-Type: application/sdp
  Content-Length: 319
  
  v=0
  o=- 2890844256 2890842807 IN IP4 127.0.0.1
  s=<title string>
  i=<more info> 
  t=0 0
  m=video 8002 RTP/AVP 31
  c=IN URL rtsp://proxy.com/rtsp://oneplace.com/blah?trackID=47
  m=audio 8004 RTP/AVP 3
  c=IN URL rtsp://proxy.com/rtsp://theother.com/blech?trackID=48

C->S:
  SETUP rtsp://proxy.com/rtsp://oneplace.com/blah?trackID=47
  ...

In the example above, the proxy wants to stream the data to the client.
Since the URLs are not treated as opaque strings, the proxy needs to
prefix the URLs on the "c=" lines with "rtsp://proxy.com/" to make sure
that the client sends the SETUP commands directly to it, and not to
"oneplace.com".

Note that with this proposal there is no ambiguity about how RTSP URLs
are treated.  The thing between the "://" and the next "/" always refers
to an RTSP host, and you are supposed to send the RTSP commands to that
host.

Note also, that unless the proxy is some sort of "virtual" proxy, i.e.
it has multiple domain names, any RTSP commands that it gets will always
start with "rtsp://proxy.com".  Anything else should result in a 3xx (or
4xx?) error code.  It was for the sole purpose of supporting virtual
servers (e.g. "abc.com" and "cbs.com" handled by the same server) that
we decided to transmit the "rtsp://hostname:port" portion of the URL,
isn't that right?

It's also fine to do like Henning suggested, and let the proxy change
the name space.  So instead of saying:

  c=IN URL rtsp://proxy.com/rtsp://oneplace.com/blah?trackID=47

some proxies could choose to change the SDP to something like this:

  c=IN URL rtsp://proxy.com/blah?trackID=47

That's fine too, but proxies that choose to do this become somewhat more
complex to implement, because now they need to keep a table that maps
from the new name space to the original name space.

Anders

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 04 Sep 1997 23:30:34 -0700

At 10:32 PM 9/3/97 -0700, Anders Klemets (VXtreme) wrote:
>can be solved.  [double URL scheme proposed]
[...]
>  DESCRIBE rtsp://proxy.com/rtsp://foo.com/something/other.sdp

This is *not* the way HTTP is dealing with proxies, to the best of my
knowledge.  If a client is hooked up to a proxy, the client uses:

GET http://foo.com/something/other.html HTTP/1.1

I see no reason to deviate from that.

However, double URLs *are* the way that early proxies solved the problem in

>  c=IN URL rtsp://proxy.com/rtsp://theother.com/blech?trackID=48

My main problem with this then, is that when does one decide when to tear
off the "rtsp://proxy.com", and when doesn't it.  This isn't a terribly
hard problem, but I thnk ti's one we should acknowledge before we go down
this road. 

Not to sound like a broken record, but this does all become simpler when
the client and server both understand that the DESCRIBE response is for
*media initialization* and not *media indirection*.  We always get nervous
about session descriptions that come from one server, and streams that come
from another, because the likelihood for inaccurate information becomes far
less.  However, this idea that a DESCRIBE can lead to another DESCRIBE is
also no less palatable (how many DESCRIBES does one need to do?  It should
only have to ask for a description once for a session.).

As long as everyone is sensitive to the fact that servers that try to use
the DESCRIBE for media indirection aren't going to work with all
implementations of RTSP, I'm fine.  My problem comes when our client has
the feature foisted on it to synchronize streams from different servers as
a part of minimum compliance, that's when you have me up in arms.  If
people can assure me that this feature is not something that we aren't
going to foist on minimal implementations of multistream presentations, I'm
fine.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp