Subject: ANNOUNCE command

From: Anders Klemets <[email-masked]>
Date: Tue, 12 Aug 1997 18:02:44 -0700

It seems to me that it would be useful to specify the Session ID in 
the ANNOUNCE command.  If the codec for a particular stream is 
changed in the middle of the presentation, the server may have to send
an ANNOUNCE command with the new presentation description.  This is
especially true in the case of a live event where it was not possible
to anticipate the codec change beforehand.  (For pre-recorded data,
all codecs could be listed in the initial presentation description.)
In addition, many commercial codecs need initialization parameters,
and those parameters may be conveyed as part of the presentation
description.  So if the codec changes, it might be absolutely
necessary for the client to receive the new presentation description.

If a RTSP TCP connection is used to control several RTSP sessions,
the client might not know which session the ANNOUNCE command refers to.
Any rtsp:// URI's that are in the presentation description may not
be sufficient to uniquely identify the session.
Including the Session ID as a parameter to the ANNOUNCE command
would solve this problem.

Another related problem is that if a codec changes in the middle of a
session, the client really needs to know the RTP sequence number of
the first packet using the new codec.  Otherwise, it is pretty clear
that the result is quite unpredictable.
Including a Transport-Info header, or something like that, with the
ANNOUNCE command would solve the problem.  Ugh, it's starting to get
a little bit messy.

Anders

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Aug 1997 07:40:54 -0400

Unless I'm missing something, the example should have included a Session
header. Rob, Anup: is this more than just an accidental omission? I've
added it to the example, before I forget...

For the codec changes, you would seem to be better off not reusing an
existing PT for a new codec. There are plenty of dynamic PTs around, so
I don't see the need to try to synchronize announcements and codec
changes that closely. This was the whole reason for having RTP PTs in
the first place. I think it is important to limit the necessary
communication between RTSP clients and media agent - they may well be
separate programs. Even asking them to learn about new PTs mid-stream is
probably pretty ambitious.

---

From: Anders Klemets <[email-masked]>
Date: Wed, 13 Aug 1997 17:54:11 -0700

> changes that closely.

Yes, if the RTP payload type of the codec changes, then the client
might not need to know the sequence number of the first packet that
contains data encoded with the new codec.  But consider the case where
all that is changed is some codec parameter.  Such as the sampling
rate for audio, or the colordepth for video.  The RTP payload type
will stay the same in this case.

Anders

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Aug 1997 22:21:00 -0400

> will stay the same in this case.

Given that we have dynamic PTs, anything that requires outside
information to understand SHOULD generate a new PT. Since PTs have fixed
sampling rates, changing the sampling rate most certainly falls into
this category. (MPEG audio is an exception, since all MPEG audio has a
TS rate of 90 kHz, but presumably MPEG audio packet are self-describing
in that regard.) Thus, if you need new outside information to parse a
packet, it should get a new PT. As I said, we went through this
discussion a few years ago and all such synchronization mechanisms tend
to fail badly with differential delays, besides being complex to
implement.

-- 
Henning Schulzrinne        email: [email-masked]
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs