Subject: RTSP - delivery to multiple destinations

From: Philip Lantz <[email-masked]>
Date: Tue, 08 Apr 1997 23:43:14 -0700

In today's meeting we discussed whether RTSP should support a client
requesting delivery of the media streams to multiple addresses. After the
discussion, I thought of some additional points.

We had decided that the client could request delivery of the media streams
to an address other than its own (with the caveat that the server may have
security policy that prohibits or restricts this usage). Given that
decision, we can use multiple SETUP and PLAY messages to achieve the effect
we want--unicast delivery of the media streams to each of the participants
in a conference. However, the use of a single RTSP session for all
recipients has some advantages:

1) The server can maintain a single state for all recipients, instead of
duplicating it for each, thus conserving server resources.

2) If the server is constrained by resources other than network bandwidth,
the use of a single session can allow the server to support more recipients
than it could if multiple sessions were used. For example, disk bandwidth
could limit the number of sessions a server can support, but if the same
disk file is being served to multiple recipients, the server could handle
additional recipients, up to the limit of its network connection.

3) It is easier for a client to be able to request support for all the
destinations in one operation (which may fail), rather than requesting them
one at a time and possibly having some succeed and some fail. (I admit the
client can solve this in other ways; it is a minor advantage.)

4) Although there is no requirement or expectation of a guarantee of the
maximum skew between the streams to the various destinations, I think it is
reasonable to expect that the skew will be minimized if all the streams are
started with a single PLAY message rather than a series of them.

Philip Lantz
Intel Corporation
[email-masked]

---

From: David Oran <[email-masked]>
Date: Wed, 09 Apr 1997 08:51:39 -0400

>discussion, I thought of some additional points.

Phil, a few comments on your comments...
>...in a conference. However, the use of a single RTSP session for all
True, except the server now has to handle the duplication of media data in
the session, and schedule multiple packets per stream, and handle the
problem that it may have enough resources to handle "n" delivery addresses
on the current session, but not "n+1". If a new destination joins, now you
have to disrupt ongoing media delivery to the existing participants in
order to start delivery to the newly-joined recipient. Ditto for a
participant leaving.

>additional recipients, up to the limit of its network connection.
I think you may have a point about disk bandwidth, but there are some known
schemes to control disk bandwidth in the presence of multiple recipients of
the same stream that work independently of whether the recipients are in
the same session or not (e.g. pyramid broadcasting). It's hard to make an
absolutely convincing case that the extra state caused by multiple sessions
is worse than the extra state needed to keep track of the multiple
recipients of a single stream in one session.

>client can solve this in other ways; it is a minor advantage.)
This could be seen as either an advantage or a disadvantage depending on
whether the client would rather have partial failure or complete failure if
not all destinations can be handled.

>started with a single PLAY message rather than a series of them.
Maybe, except we may be talking about an effect smaller in magnitude than
the delay dispersion among the recipients. What's your expectation of how
long it takes a server to service a PLAY command?

-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Apr 1997 10:26:44 -0400

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, 09 Apr 1997 10:26:44 -0400