Subject: RE: RTSP - delivery to multiple destinations

From: Eric Fleischman <[email-masked]>
Date: Wed, 16 Apr 1997 10:17:03 -0700

RTSP seems to be undergoing some undesirable scope creep due to the
introduction that a user could register other addresses to also receive
a session. The original RTSP definition carved out a discreet domain,
explicitly stating that certain areas would be out-of-scope. These
included specific setup/registration/announcement approaches. I suggest
that we return to our original vision.

I believe that the provision of letting a user register other addresses
is something which should be apart of a "conference control" spec (e.g.,
H.323, MBONE) and therefore should be declared out-of-scope for RTSP.
Ditto with the concern of how to add/drop destinations. 

I would suggest that RTSP merely state that we envision RTSP working
with conference control specification(s) such as H.323 and that those
specifications will identify such things such as registering other
recepients, adding and dropping sessions, etc.

> -----Original Message-----
> From:	Henning Schulzrinne [SMTP:[email-masked]]
> Sent:	Wednesday, April 09, 1997 7:27 AM
> To:	Philip Lantz
> Cc:	[email-masked]
> Subject:	Re: RTSP - delivery to multiple destinations
> 
> Specifying several addresses in the same SETUP wouldn't be too hard.
> Adding/dropping destinations to the same session would seem to be
> messier. Suggestions solicited.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 16 Apr 1997 14:06:13 -0400

I agree that getting RTSP to add/drop participants is not appropriate -
just wanted to give people a chance to come up with
solutions/suggestions. No such suggestions, elegant or otherwise, have
been put forth, so I'd like to consider this issue closed at this point
(if there are no objections/ideas), particularly since this would likely
complicate the state machinery and protocol operation significantly.

To allow streaming of data through firewalls, the client has to be able
to specify the desired destination port. Allowing specification of a
single destination address (unicast or multicast) does not complicate
the protocol or change its operation in a material way [and simplifies
integration of RTSP servers into Mbone multicast sessions], but does
offer some 'improved' denial of service attack possibilities. It should
be noted, however, that UDP commands with faked source addresses also
offer remote-control packet bombing opportunities even if SETUP cannot
establish a destination address.

Henning

---

From: Jeff Smith <[email-masked]>
Date: Wed, 16 Apr 1997 13:01:34 -0700

I absolutely agree with Eric.  The originally RTSP (and the
discussions that we began in Montreal) clearly seperated the roles of
the channel/stream control vs. setup/invitation/adding/dropping etc.

SIP, SCCP (or other proposals) can take care of much of what we are
now seeing as suggested extensions of RTSP.

js