Subject: Concern about c=IN URL

From: Stephen Casner <[email-masked]>
Date: Sat, 6 Sep 1997 22:55:04 -0700 (PDT)

On Wed, 27 Aug 1997, Rob Lanphier wrote:
> NOTE: The examples below are slightly different than those in the
> draft03. This came from hallway discussions with various parties about how
> SDP and RTSP could be better integrated. The next draft will resolve this
> issue.

Rob mentioned in the Munich session that Mark Handley had suggested
the "c=IN URL" form.  This form bothers me, though I don't have a
strong argument against it.  Here are my reasons:

  - In traditional SDP usage, the c= line gives a destination address,
    not a source address.  That's true for both the multicast case,
    where the both have the multicast address in the SDP file, and in
    the unicast case, where each end gets an SDP file with the c= line
    giving the address of the other end.

  - For layered encodings, a "/n" suffix on the address specifies the
    number of addresses.  Where is this information going to go in the
    RTSP case?

I'm inclined to believe we have a fundamental problem with DESCRIBE
and SETUP.  As I understand it, the transport information is extracted
into the separate SETUP request and response to simplify the task of
proxies snooping on the RTSP control traffic to learn how to set up
for the data traffic.  In order to avoid having to specify a single
session description format, parts of the information that would
otherwise belong there are extracted into the SETUP command.  But it
looks to me like the setup command is likely to keep growing until it
becomes a session description format.
							-- Steve

---

From: Rob Lanphier <[email-masked]>
Date: Sun, 07 Sep 1997 10:24:16 -0700

At 10:55 PM 9/6/97 -0700, Stephen Casner wrote:
>otherwise belong there are extracted into the SETUP command.  

It's not that we are trying to avoid having a single session description
format, it's that, unlike with SAP/RTP-style multicast, the recipient has
some say in what the sender does.  This requires a reply/response mechanism
(ala SETUP).  Furthermore, there is a need to break media description away
from transport description, since informing the client of media description
is relatively static and doesn't necessarily involve any server state,
whereas the transport initialization does involve state on the server.

>But it

Not true.

*  There will never be media initialization information in the SETUP
command.  It is purely for transport information.  The bulk of session
description formats like SDP are media initialization.

*  There is one SETUP message per stream, as opposed to one SDP description
per session.  This greatly simplifies the syntax of the message.

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