Subject: RE: Container files and various methods of dealing with them

From: Brad Hefta-Gaub <[email-masked]>
Date: Fri, 27 Jun 1997 10:00:03 -0700

>> What are the costs you want to avoid with the 1-1-1 model?  Number of
>> sockets at the server?

* Number of sockets at the client.
* Number of sockets at the server. 
* Number of sockets at the firewall. 

My biggest concern is number of sockets at the firewall.

-Brad

---

From: Rob Lanphier <[email-masked]>
Date: Mon, 30 Jun 1997 12:16:25 -0700

At 01:23 PM 6/25/97 -0700, Rob Lanphier wrote:
>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-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.

Through this conversation and others, myself and others here at PN are
becoming convinced that 1-1-n is a necessity.  Here are the reasons:

1-1-n vs. 1-1-1
*  Demultiplexing RTP via anything other than port is non-standard, and the
resource trade-offs aren't worth bucking the standard.

1-1-n vs. 1-n-n
*  With on-demand streams, there is a necessity to get all RTP streams
referenced to a common NPT, and have PLAY/PAUSE apply to that common NPT.
*  Many container file formats support the concept of pre-interleaving.  We
would like to make it possible for the server to dump all of the streams
from a container onto the wire in a standard format without having to open
n instances of the same file.
*  Being able to record multiple streams into a single container is
something that an exclusively 1-n-n system wouldn't be able to handle.

I've got to put some polish on a 1-1-n proposal that we have, but I realize
that we don't necessarily have a consensus that 1-1-n is necessary.  Does
anyone have a fundemental problem with 1-1-n at this point, or can we move
the discussion onto the brass tacks of how to do 1-1-n?

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