Subject: RTSP: streaming and conferences

From: Rob McCool <[email-masked]>
Date: Fri, 22 Nov 1996 13:12:46 -0800

At the NTT BOF meeting and the Netscape partners meeting, the
question of introducing an RTSP stream into an existing
conference was raised. One example which has been brought up is
where a group of people could be having a conference, and all
want to watch the same video clip at the same time. One
conference participant would call up the video server via RTSP,
and begin playback of the clip to all of the members of the
conference. The person who started the playback would control
the stream (to stop, or seek it for example). The stream would
be delivered via one of the transports allowed by RTSP
(i.e. RTP, multicast or unicast).

This requirement seems to be most easily met by making one of
the following changes to the current RTSP SET_TRANSPORT
message:

* Add a new channel ID, which as its transport specific data
  takes a group of addresses. The addresses would not need to be
  the same as the address of the RTSP peer, and could
  potentially consist of a mix of multicast and unicast
  addresses. Upon delivery, the server would send packets to all
  of them.

* The requirement that the client never send channel ID 1 could
  be lifted. The transport specific messages for channel ID 0
  and 1 would be changed to take an address count and a set of
  addresses, which could again be any mix of unicast and
  multicast.

This raises a couple of questions:

Is this extension of the protocol scope wide enough to make it
useful to conference applications, yet narrow enough to keep the
protocol focused on streaming applications? If it's not enough
to be useful to conference applications, what additional
extensions would be required? Note that in this instance, the server
would not necessarily be sending RTCP packets about itself. The goal
is to leave any conference-specific information or techniques out of
the RTSP protocol.

Is it a security problem to allow the server to send data
packets to a different address than the one which requested the
data? The problem I can imagine is denial of service, where you
flood a mail server with unrequested packets for example. But
this is possible today without using RTSP, if there is no
firewall present.

One scenario is that someone has an RTSP-aware firewall which,
when a user behind the firewall makes an outgoing TCP connection
to an RTSP server, watches the TCP traffic looking for a
SET_TRANSPORT message. When it finds one, it opens the
corresponding UDP port and address and allows data to flow until
the TCP connection is closed. In this case, it might be possible
for someone to request a sensitive address (like that of a mail
server) behind the firewall, and the RTSP server could then
cause a disruption of service by flooding that address with
data. This case doesn't seem very interesting to me, because the
person requesting the address is behind the firewall to begin
with.

These security implications could be dealt with by placing the burden
of authentication on the server. That is, if the new channel ID
approach is used, implementation of that channel ID would be made
optional. This would allow a server to decide for itself if it trusted
a client enough to allow the client to tell the server to send data to
an arbitrary address.

--
Rob McCool, [email-masked] http://home.netscape.com/people/robm/
Stunt Programmer, Netscape Communications Corporation
But I only changed... oh.

---

From: Mark Handley<[email-masked]>
Date: Fri, 22 Nov 96 17:06:46 -0500

>  addresses. Upon delivery, the server would send packets to all

...

>extensions would be required?

It sounds like it's close, but the client must also specify encodings
to be used for playback (i.e, those that are being used in the
conference session).  If necessary, the server has to be able to reply
that it can't comply with the encodings.

>this is possible today without using RTSP, if there is no

I'm a little uneasy about "remote-controlled" unicast streams, but we
can possibly add some form of stream level handshake that the server
requires before it's willing to play (perhaps using RTCP APP packets
or something from the intended receiver) - this can be outside the
scope of the RTSP *control protocol*, so I don't think you need to
worry too much about it.

In principle (if not currently in practice) remote-controlled
multicast streams get pruned (with IGMPv3 and apps that can use it) so
the traffic won't go anywhere.

Mark

---

From: Rob McCool <[email-masked]>
Date: Mon, 25 Nov 1996 14:35:45 -0800

> that it can't comply with the encodings.

I'm assuming you mean data encodings such as which codec to use. This is
something which the current RTSP doesn't address, in the current model
the server simply tells the client what encoding a particular clip uses
after the client requests it. Any additional information or knowledge of
available encodings prior to the request is handled out of band. 

In your scenario, there would be only be one set of encodings, not one
encoding per client, right? Would having the set of available encodings
obtained out of band by the conference member who is controlling the
playback be unacceptable? Presumably this member would know which
encoding(s) the conference is using, and could obtain a metafile or
session description so that it would know whether or not the server had
the appropriate encodings available.

--Rob