Subject: RTSP Feedback Meeting

From: Rob Lanphier <[email-masked]>
Date: Tue, 12 Nov 1996 19:57:37 -0800

As Mike mentioned in an earlier mail, we are holding a review of RTSP at
Netscape between 10am and 2pm, Wednesday, November 13, 1996.  I just wanted
to alert the members of this list of two things:

1.  We will be broadcasting this using RealAudio.  For details, see:
    http://www.realaudio.com/prognet/rt

2.  We will be discussing the following agenda, which should be up on our
website tomorrow as well.  See:
    http://www.realaudio.com/prognet/rt/netscape-961113.html

We hope this stirs up the conversation a little bit.  Please send, comments,
etc. to this list or to [email-masked] (this will make it easier
to get comments while down in San Jose)

Thanks
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com
---------

                              RTSP Open Issues
                                      
   At the [1]Stream Control BOF II hosted by Jeff Smith at NTT, several
   issues with RTSP were brought to light. As a result, we'd like to move
   toward resolving these issues at the [2]RTSP Feedback Meeting,
   November 13, 1996 hosted by Netscape Communications.
    1. Scope of RTSP
         a. Compartmentalize The Protocol
         b. Joining Into Existing Conferences
         c. Metafiles/Session Descriptions
    2. RTSP Implementation Issues
         a. Use Of UDP For Delivery Of Control Messages
         b. Text-based Control Protocol
         c. Change Appendix C (families of stream types)
       
  Section 1: Scope of RTSP
  
      Compartmentalize The Protocol
       At the Streams BOF II, hosted by Jeff Smith at NTT, one of the
       principle points of discussion was striking the balance between
       the current RTSP proposal of having one protocol that accomplishes
       all necessary tasks and the proposal by several attendees that
       RTSP should be modularized, breaking it up into several
       components. At the end of that meeting, PN agreed to come up with
       a straw man for breaking up RTSP into smaller pieces.
       In the following, we set out to understand the position taken by
       those members. We don't agree that it should be broken up into as
       many pieces as we've outlined below. However, we'll go along with
       a well-reasoned consensus and allow it to evolve.
       
      RTSP Framework
       The RTSP Framework would provide a collection of application and
       transport-level control protocols providing an extensible
       framework to enable controlled, on-demand delivery of real-time
       data in a client-server fashion. This document would describe how
       the underlying protocols are assembled to provide a complete
       specification.
       
      Our Base Requirements
          + Must provide a complete set of functionality for one-to-many
            streaming of multimedia
          + Must support real-time audio/video files and live real-time
            feeds or any type of live or other paced-content information
          + Protocol must be usable over low-bandwidth connections
          + Must optionally be capable of delivering full start-to-finish
            functionality within a single TCP connection
       
      RTSP Control Protocol
       The RTSP Control Protocol is the protocol that provides stream
       control for the RTSP Framework. This would be similar to the work
       that the MMUSIC group did with CCCP.
       
      RTSP Format Descriptors
       Appendix C of the current RTSP spec specifies format descriptors
       and families. There has been an expressed desire from Mark Handley
       and Henning Schulzrinne to separate this from the "control" part
       and make them the stream description format.
       Barring a full decoupling of RTSP and the format specifiers, even
       if the spirit of Appendix C remains the same, splitting the
       document here may be beneficial to encourage the evolution of the
       data types independent of the core RTSP specification.
       
      Stream Description Format
       This may be a merge of the Stream Description Protocol (SDP)
       proposed by Mark Handley and the tenative RTSP format. Henning
       Schulzrinne has a proposal which he has placed at
       [3]http://www.cs.columbia.edu/~hgs/rtsp/sdf.html
       He proposes the name "Session Description Format", which is one
       possibility. For that matter, we could come up with more
       reasonable names by the pick-one-from-any-column mechanism:

      Column 1         Column 2        Column 3
      ========         ========        ========
      Session          Description     Format
      Clip             Metafile
      Presentation

      Streaming Stream Description Format
       This would provide stream description functionality in a streaming
       format, such that new streams can be dynamically added and removed
       within a single RTSP session, and that a single TCP connection
       (authenticated once) can handle the entire experience from start
       to finish. This would be similar to SIP, and perhaps could be
       merged with SIP.
       
      Compressed RTP
       This would be the definintion of the RTSP version of compressed
       RTP.
       
      SCP and Compressed SCP
       We'll work with Simon Spero and the appropriate working groups to
       define a format that works well for this.
       Simon has a new proposal for SCP at:
       [4]http://sunsite.unc.edu/ses/scp.html
       We haven't had time to fully evaluate it, but so far, it looks
       pretty good.
       
      Using RTSP Control over SCP
       This would define how the RTSP Control protocol would work over
       SCP.
       
      Using RTSP Control over UDP
       ...yet another proposal
    a.
       
    Joining Into Existing Conferences
       Intel came to the NTT BOF prepared with a presentation of
       H.323-RTSP interoperability, which unfortunately, we didn't have
       time to discuss at the last meeting. Basically, they've presented
       two different scenarios and the changes necessary in each.
          + _Proxy RTSP/RTP into an H.323/RTP conference_- The advantage
            here is that it would involve no changes to H.323 or RTSP.
            The disadvantage of this approach is that the RTSP-H.323
            proxy would be responsible for translating the individual RTP
            packets.
          + _Stream RTP directly from an RTSP server into an H.323
            conference_-The advantage here is that it free the proxy from
            the responsibility of dealing with the individual packets.
            The disadvantage is that it may require changes to the
            current RTSP specification.
    b.
       
    Metafiles/Session Descriptions
       In a metafile, we want to express:
          + programs of different languages, with a different audio
            channel for each language, but a common video channel. This
            could even change during the session, e.g., for a conference
            held in France, where the non-French speakers are
            automatically translated.
          + media with different encodings, e.g., to cater to different
            bandwidth capabilities
          + time-sequences of media, e.g., different audio clips to be
            collated into a single program or a video clip that is only
            active during a part of the session.
       This list does not include user interaction, e.g., branching for
       alternate movie endings or different paths through an educational
       video.
       Timing dependency is not strictly necessary, since we can have
       inactive media, with the potential problems of having to allocate
       screen real-estate, invoke applications, etc. even though the
       media stream may never be invoked.
       
      Dualing Requirements
       We have two possibly conflicting requirements. On one hand, we
       would like to have a metafile format which provides the client
       with everything necessary to passively listen on a multicast
       session. This would require very intimate knowledge of the streams
       involved. Packetization sizes and compression parameters would
       need to be included here, as well as all information that would
       typically be found in a RIFF header.
       On the other hand, we would like to have a simple format with
       which a "presentation author" may take streams stored on different
       machines and aggregate them into a presentation, with as little
       knowledge of the underlying protocol as necessary.
       A third requirement is somewhere in between. We need to have
       enough information in the metafile for the client to make an
       intelligent decision which streams it should select. In other
       words, it would need to know at least the raw bandwidth of the
       stream, and perhaps language characteristics.
       
  Section 2: RTSP Implementation Issues
  
    a.
       
    Use Of UDP For Delivery Of Control Messages
       UDP delivery of control messages is a tricky subject, On one hand,
       UDP makes a lot of sense for a real-time protocol. As Scott
       Petrack puts it:
       _"My experience shows that control messages over TCP can indeed be
       delayed or worse because of flow control. This happens typically
       when trying to get service from Israel to some server in the US in
       the heavily loaded hours of the internet. (There are often 14 hops
       between me and some server in the US). By "worse" I mean that the
       delay is so bad that the connection times out. This is because all
       the UDP stream traffic just totally overwhelms TCP traffic. This
       is one of those things that of course will be solved when the
       Messiah comes and RED is deployed, but until then my very
       "real-world" experience suggests that using TCP will result in
       significantly worse control function.
       "The problem is not so much a STOP message, since I can just stop
       the playout locally. The problem occurs with things like fast
       forward or even worse, slow motion. Within the true hard
       constraints of RTT, I would like to be able to play with the
       control buttons (like pause, slow down, fast forward, etc.), just
       like I could do at home. The constraint of RTT and jitter are very
       limiting, but my experience shows that using TCP in the control
       channel significantly reduces the amount of function I can get."
       _However, it does make it more difficult to implement over a
       firewall. Adrien de Croy, a developer on the Wingate Firewall, has
       this to say:
       _"For firewalls, it becomes very difficult to implement a proxy
       for a protocol where the protocol is not based on TCP or does not
       have a TCP component. This is because the proxy must allocate
       resources for a client request, and with UDP you get no
       information about when a request is completed (i.e close on a
       socket in TCP), and hence you have a problem about when to
       deallocate the resource - you can't tell when someone has finished
       unless you analyse the protocol to the nth degree, and the
       protocol includes a sign-off process.
       "You can do things like UDP relaying, but this has to rely on
       things like an inactivity timeout in order to deallocate
       resources, which is inefficient at best, and can cause problems
       with high volume sites (I have seen them - real easy to run out of
       sockets if you are even a couple of seconds out in your estimate
       of when to terminate a client session).
       "It is however very easy to create a proxy for a protocol that
       contains a mixture of protocols (i.e TCP and UDP). You can use the
       TCP connection to decide when to deallocate resources (i.e when
       the TCP connection closes, shut down the UDP sockets as well)."_
    b.
       
    Text-based control protocol
       Pros of having an text-based control protocol:
          + Header fields within the message reduce the number of
            messages required between client and server, for instance, an
            Accept request header field delimits the acceptable session
            description types for the response; an Allow response header
            field lists the methods supported by the resource indentified
            by the Request URI
          + Unrecognized methods can be handled in a reasonable way; new
            methods can be added (and used by clients) very easily
       The cons include:
          + More bandwidth on control message could increase response
            latency (increases the odds that message will be split among
            packets in TCP, any one of which may lost).
          + Parsing will be a bit more computationally expensive
          + Interleaving data/text within stream is difficult
       
      Change Appendix C (families of stream types)
       Microsoft has proposed the following changes to Appendix C of the
       protocol.
          + CODEC IDs should be UUIDs.
          + Modify Audio Family
          + Add Video Family
       
      CODEC IDs should be UUIDs.
       From [5]Microsoft's proposed changes:
       _"Given the rapid pace of development in this field it makes
       little sense to have these identifiers assigned by a standards
       body. If someone creates a CODEC and wants to release it
       immediately on the Internet, they should be able to do so by
       identifying the CODEC with a UUID that they generate which is
       almost certain to be unique instead of having to request and wait
       for an approved 32-bit identifier. The size difference (12 bytes)
       is not a legitimate concern given the low frequency of
       transmission (a few times during initial control communications)
       of these IDs. A client application that encounters a stream that
       uses an unknown CODEC could use CODEC location information to
       download (or order) the CODEC. We believe the use of UUIDs in RTSP
       allows the most freedom for the rapid development of new
       technologies. To support CODECs that are identified by FOURCCs,
       there is a one-to-one mapping from FOURCCs to UUIDs."_
       
      Modify Audio Family
       Microsoft also proposes the "number of frames" field be removed
       from the audio family in Appendix C, because it is already in the
       STREAM_HEADER message. See [6]Microsoft's full proposal for
       details.
       
      Add Video Family
       Microsoft also proposes the "number of frames" field be removed
       from the audio family in Appendix C, because it is already in the
       STREAM_HEADER message. See [7]Microsoft's full proposal for
       details.
       
  Feedback
  
   Send feedback to the _confctrl_ alias, which is run by the [8]IETF's
   MMUSIC group. Or, you may email [9][email-masked]. For
   other ways to provide feedback, check out our RTSP feedback page at
   [10]http://www.realaudio.com/prognet/rt/feedback.html

     _________________________________________________________________

References

   1. http://alicia.nttlabs.com/%7Esumisu/streams-bof/BOFII/
   2. http://www.realaudio.com/prognet/rt/netscape-961113.html
   3. http://www.cs.columbia.edu/~hgs/rtsp/sdf.html
   4. http://sunsite.unc.edu/ses/scp.html
   5.
http://alicia.nttlabs.com/%7Esumisu/streams-bof/BOFII/docs/RTSP-MSFT-Changes
-110796.html
   6.
http://alicia.nttlabs.com/%7Esumisu/streams-bof/BOFII/docs/RTSP-MSFT-Changes
-110796.html
   7.
http://alicia.nttlabs.com/%7Esumisu/streams-bof/BOFII/docs/RTSP-MSFT-Changes
-110796.html
   8. http://www.ietf.org/html.charters/mmusic-charter.html
   9. mailto:[email-masked]
  10. http://www.realaudio.com/prognet/rt/feedback.html

---

From: Philipp Hoschka <[email-masked]>
Date: Wed, 13 Nov 1996 21:14:56 +0100

>    http://www.realaudio.com/prognet/rt

Unfortunately, I get a "bad URL" message in the RealAudio Player
when trying to start the transmission :-(

----------------------------------------------------------------------
   Philipp Hoschka
   WWW: http://www.inria.fr/rodeo/personnel/hoschka/hoschka.html 
				|   INRIA - WWW Consortium
   [email-masked]      |   2004, Route des Lucioles, BP 93
   Tel:(+33) 93 65 79 84        |   06902 Sophia Antipolis Cedex
   Fax:(+33) 93 65 77 65        |   France
----------------------------------------------------------------------

---

From: Bill Strahm <[email-masked]>
Date: Wed, 13 Nov 1996 13:24:09 -0800

>    http://www.realaudio.com/prognet/rt
Any chance of multicasting this with VAT also(instead).  I don't think I can
get Real Audio through my companies firewall...  I would much prefer a
multicast VAT session announced with SDR instead.

Bill
Bill Strahm    |Programming today is a race between
bstrahm@       |software engineers striving to build
ibeam.intel.com|bigger and better idiot-proof programs,
(503) 264-4632 |and the Universe trying to produce
               |bigger and better idiots.  So far, the
               |Universe is winning.--Rich Cook
I am not speaking for Intel.  And Intel rarely speaks for me

---

From: Richard Core <[email-masked]>
Date: Wed, 13 Nov 1996 14:13:05 -0800 (PST)

Me too... all day!
Rich
> From [email-masked] Wed Nov 13 14:10 PST 1996
> To: Rob Lanphier <[email-masked]>
> Cc: [email-masked]
> From: Philipp Hoschka <[email-masked]>
> Subject: Re: RTSP Feedback Meeting 
> Date: Wed, 13 Nov 1996 21:14:56 +0100
> 
> 
>

---

From: Richard Core <[email-masked]>
Date: Wed, 13 Nov 1996 15:48:51 -0800 (PST)

> Date: Wed, 13 Nov 1996 13:24:09 -0800
> To: Rob Lanphier <[email-masked]>, [email-masked]
> From: Bill Strahm <[email-masked]>
Me too...!
Rich