Subject: Container files and various methods of dealing with them

From: Rob Lanphier <[email-masked]>
Date: Wed, 25 Jun 1997 13:23:16 -0700

I'd like to frame the current discussion we are having by separating the
various ways of streaming container files.

There are three scenarios that we are dealing with here:

1-1-1    One container file controlled by one RTSP session which streams to 
         one UDP port via RTP
1-1-n    One container file controlled by one RTSP session which streams to 
         n UDP ports via RTP
1-n-n    One container file controlled by n RTSP sessions which stream to 
         n UDP ports via RTP

1-1-1 has always been possible, and that is how PN plans to stream
container files.  The way that this is done in unicast is that the streams
are multiplexed using the SSRC, and the SSRC values are enumerated in the
session description.  It would probably be a good idea to do a more
rigorous definition of this.  If necessary for multicast, we could have
separate SSRC and a new field (added via standard RTP mechanism) so that
the SSRC selection and the stream id don't get mixed up.  A more rigorous
writeup is needed here.

1-1-n is not possible currently.  There are ways that I could imagine doing
this without changing the nature of the SETUP request/reply (which is
strictly an exchange of tranpsort information) and DESCRIBE (which is
strictly an exchange of media description information).  I'm opposed to
putting transport parameters in DESCRIBE when there are alternatives
available.  Rather than getting mired in how it should be done, the first
task is determining if 1-1-n is a requirement.

1-n-n is possible using the proposal that I made last Friday.  There are
still some subtleties of this that I hope don't get buried in the debate
above (for instance, should individual streams in a container have their
own URLs).  The need for 1-n-n streaming I believe is not contested.  The
whole point of being able to stream to multiple ports is to be able to
stream to different applications (which necessarily bind to different
ports).  When streaming to multiple applications, it is difficult to
conceive that anything less than full control will be needed for each of
the streams.

---
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/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

---

From: Stephen Casner <[email-masked]>
Date: Wed, 25 Jun 1997 19:43:59 -0700 ()

> the SSRC selection and the stream id don't get mixed up.  A more rigorous

I think this is a bad idea.  Section 5.2 of the RTP spec argues
against multiplexing multiple media into one RTP session for a list of
reasons.  Perhaps you could discount some of these for the unicast
case, but I think creating an RTP implementation that works only for
unicast is short-sighted.  Forcing SSRC id's to go into the session
description seems like a bad move to me.

Furthermore, I don't see how this avoids any of the hard problems that
arise in implementing 1-1-n or 1-n-n.  There still are individual
streams that you need to be able to control both individually and
collectively.  If it is just a matter of figuring out how to specify
the port numbers, that's got to be a solvable problem.

> available.

??? SDP has included transport parameters all along.

> The need for 1-n-n streaming I believe is not contested.  The
> ports).

No, section 5.2 lists several other reasons in addition to this.

							-- Steve

---

From: [email-masked] (Anup Rao)
Date: Wed, 25 Jun 1997 22:50:56 -0700

> 1-n-n    One container file controlled by n RTSP sessions which stream

I would urge that we view  this problem in a more general sense than a
"container file". A presentation comprised of two streams(particularly
if both were controlled and delivered by the same host) is also a
container. Clearly, in case of a container file where the actual streams
reside in a single physical file, there are  implementation, resource,
and efficiency considerations driving(I guess)  the need for 1-1-1.
However, from the RTSP point of view, they are really the same. Hence we
should try and consider them as such.

Could you also please elaborate on the reasoning for  1-1-1. I can think
of server resources and firewalls, is there anything else ?

-----------------------------------------------------------------
  Anup Rao
  Netscape Communications Corp.
  email : [email-masked]         Phone : (415) 937 3129
-----------------------------------------------------------------