Subject: Transition to RTP audio on MBone

From: Stephen Casner <[email-masked]>
Date: Tue, 26 Mar 1996 02:11:44 -0800 (PST)

[This note is sent to the rem-conf list where followups should go, but
is blind-cc'd to the mbone list in case some folks are only there.]

To the MBone Community:

With the Real-time Transport Protocol (RTPv2) now published as
Proposed Standard RFC 1889, it is time for us to make a significant
transition and begin using RTP to carry audio on the MBone.  As the
chair of the IETF AVT working group, I'm sending this message to start
the process and will continue to "evangelize" as needed.

The key elements of this transition are:

  - running vat with the -r option to select RTPv2
  - using the new UCL tool sdr as a replacement for sd to
    automatically invoke vat with that option.  You should start
    running sdr now!

The native "vat protocol" (sometimes referred to as RTPv0) that
encapsulates the encoding formats implemented by the vat program has
served well since 1992.  However, vat version 4.0, which has been in
alpha test for a few months, implements RTPv2 in addition to the
native protocol and will use RTPv2 when started with the -r option.
Note that the authors of vat and sd at LBL fully support this
transition.  The vat 4.0 documentation says:

  RTP is far superior to the original vat protocol and we hope it
  will soon become the default but in the interim we have to figure
  out the right sequence of tool deployment and sd/sdr changes to
  coordinate an orderly transition between the two protocols. We
  encourage experimenters to use RTP mode whenever possible.

The transition from sd to sdr is necessary because the protocol
implemented in sd and the .sd.tcl files _as deployed_ do not provide
a means to specify the use of RTP and invoke vat with the -r option.
The sdr program implements a second generation of the Session
Directory Protocol (SDP) that can specify the use of RTP, and the
sdr program chooses RTP as the default for audio when creating
sessions.  Besides, sdr implements a bunch of nicer features that the
authors of sd have refrained from implementing because this
transition was planned.

What To Do
==========

1. Get sdr either from its home at UCL or the USA mirror site:

   ftp://cs.ucl.ac.uk/mice/sdr/
   ftp://parcftp.xerox.com/pub/net-research/apps/sdr/

   Binaries are there for 5 or 6 UNIX platforms.

2. Please start running sdr now so that you will see sessions using
   RTP audio that are only advertised in sdr.  There is a gateway
   which listens to the global sd advertisements and retransmits them
   to sdr, so you don't need to run sd.

3. If you have an old (3.x) version of vat, it is definitely time to
   upgrade.  Note that new versions of vat and vic, including
   binaries, have been posted in the past few days to:

   ftp://ftp.ee.lbl.gov/conferencing/vat/alpha-test
   ftp://ftp.ee.lbl.gov/conferencing/vic/alpha-test

   It is predicted that these programs will advance from alpha
   release status soon!

4. If you are transmitting a session, please help promote this
   transition by advertising your session with sdr rather than sd and
   using RTP (the default) for audio protocol (you may independently
   choose PCM, DVI or GSM encoding as before).  If you send email
   about your session, mention that listeners should find it with sdr.
   I hope to see all events make this transition by the time of the
   next IETF meeting (late June).

Try It Now
==========

Hugh LaMaster at NASA was kind enough to create an RTP test session
in sdr as a secondary channel for the current STS-76 shuttle mission
and possibly contining next week with other NASA Select programming.
You can use this session to make sure you've got all the necessary
software in place and to test out the new features of sdr and of
vat when operating in RTP mode.

Note that this RTP test session will appear in sdr in addition to
the STS-76 Audio and Video sessions that are gatewayed from sd.

This secondary shuttle channel is being sent at low bandwidth (64kb/s
for video, and GSM for audio) to conserve bandwith but also in
response to requests from folks who wanted to be able to watch over
128kb/s ISDN lines.

Comments welcome.
							-- Steve