Subject: Why do we need 1-n-n anymore?

From: Alagu Periyannan <[email-masked]>
Date: Tue, 8 Jul 1997 13:28:46 -0700

Hi all,

Here are the arguments to drop 1-n-n,

- The primary need for 1-n-n was to be able to control each
media separately. The new 1-1-n proposal allows separate
control even though all streams are part of the same
RTSP session, since we can use the "streamid" header in the PLAY
method to differentiate between media.

- 1-n-n can be achieved by multiple 1-1-n sessions in
which n=1, i.e. you setup only one of the n media in the
container file. You might argue that this will cause the
container file to be opened multiple times rather than
only once. But the same problem exists in 1-n-n also.
Since there is no state sharing between DESCRIBE and
SETUP the server will probably need to open the file
n times. (If the server uses tricks  to open the file just
once and share it among n session, it can do it
for 1-1-n just as well as it can 1-n-n.)

- 1-n-n is confusing to servers. Are they supposed to
send the n streams synchronized to a single
timebase (i.e. timeline)? How do they know that these
n streams are from the same presentation?

Dropping 1-n-n will lead to better interoperability.

If you agree with the arguments to drop 1-n-n then
read my next email.

---------------------------------------------------
Alagu Periyannan                   [email-masked]

Interactive Multimedia Group
Apple Computer, Inc.

---

From: Rob Lanphier <[email-masked]>
Date: Wed, 09 Jul 1997 15:04:28 -0700

>for 1-1-n just as well as it can 1-n-n.)

Agreed.  Actually, what are the perceived differences between 1-n-n and
multiple 1-1-(n=1) sessions?  I would hope they are identical.

Presumably, the only difference would come on the second SETUP message
(presuming that we don't have a null SETUP message).
   C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
         Accept: application/sdp

   S->C: RTSP/1.0 200 1 OK
         Content-Type: application/sdp

         v=0
         o=- 2890844526 2890842807 IN IP4 192.16.24.202
         s=RTSP Session
         m=audio 0 RTP/AVP 0
         a=streamid:aud
         m=video 0 RTP/AVP 31
         a=streamid:vid
 
   C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2
         StreamID: aud
         Transport: rtp/udp;port=3056,
                    rtp/tcp
         
   S->C: RTSP/1.0 200 2 OK
         Session: 1234
         StreamID: aud
         Transport: rtp/udp;port=3056

  C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 3
         Session: 1234
         StreamID: vid
         Transport: rtp/udp;port=3058,
                    rtp/tcp

   S->C: RTSP/1.0 xxx 3 Multi-stream sessions not allowed

(where xxx is a yet-undefined error code).

At this point, the client would then know that it is going to have to
handle 1-n-n streaming.

So, if we want to force implementors to implement 1-1-n streaming when they
stream container files, then we don't need to define "xxx".

If we do define "xxx", the client or server should not treat this as a
fatal error.  It should just merrily go about 1-n-n.

Now, I think the point that Alagu is raising here is that anyone who is
going to deal with container files and is going to do 1-1-n because life is
just easier in the long haul.  Dropping 1-n-n means one less pathological
test case to deal with in clients.  I wholeheartedly agree with this.

Is there anyone out there who envisions *only* supporting 1-n-n *and*
supporting container files with 2 or more streams?  If there is, I would
like to understand the reasoning.

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