Subject: "seq" in Transport-Info

From: Philipp Hoschka <[email-masked]>
Date: Wed, 27 Aug 1997 00:45:10 +0200

12.36 Transport-Info

     This field is used to set Transport specific parameters in the PLAY
   response.

   seq:
          Indicates the sequence number of the first packet of the
          stream. This allows clients to gracefully deal with packets
          when seeking. The client uses this value to differentiate
          packets that originated before the seek from packets that
          originated after the seek.

Could somebody explain why this is needed ?

An example would be great - the one given in the text does not
convince me.

Assume the client has plaid a stream up to timecode 00:00:01, 
and now sends out a seek, e.g. to 00:00:05. In this case, the
client can compute which sequence number to expect in the first packet
after the seek, since it knows which seq-number the stream has 
started at, and it also knows the clockrate of the stream.

I guess the real reason is if the initial packets of the stream are
lost - in this case, subsequent seeks do not actually jump to the
right place in the stream when a randomized initial sequence number
is used (as is the case in RTP, for security reasons). 

Assume you loose the packets for the first second in the above 
example. Using the method described above, after the seek the 
client will then start playing packets starting from 00:00:06,
instead of 00:00:01. This is because with RTP, there is no
way for the client to find out that the first second of the 
stream was lost.

In this case, it seems enough to send only the initial
sequence number, e.g. as part of the session description, not
in every play request. This would avoid the race condition
between the play response and the stream data packets.

Moreover, using a randomized initial sequence number for 
security seems pointless if this initial sequence number is 
transported in cleartext in RTSP. 

Should we drop the random initial seq number for RTP streams
requested via RTSP, and simply start sequence numbers at 0 ? Hm, 
I guess the RTSP traffic could also be encrypted, but 
"known plaintext attacks" on RTSP are probably quite easy (if 
only because RTSP doesn't use randomized sequence numbers for 
its requests). Then again, I'm not a security expert.

Has anybody seriously considered to simply start RTP sequence 
numbers at 0 ? 

I have the feeling this isn't all that bad - it certainly
doesn't seem to make things less secure - and it would 
avoid a couple of problems in RTSP, especially the
race condition between stream data and the PLAY response. 

The only counter-argument I see is that existing RTP code 
would have to be hacked to do this, and, of course, that
it "breaks the RTP standard" - but RTP wasn't designed with
media on demand in mind, and adjusting the standard in this
respect seems better to me than kluding a work-around into
RTSP.

-Philipp Hoschka, W3C

---

From: [email-masked] (Anup Rao)
Date: Tue, 26 Aug 1997 18:24:51 -0700

> started at, and it also knows the clockrate of the stream.

Not necessarily. There's no telling how the stream is packetised - it
may be packets of variable length aligned at some weird boundary, there
just isn't an accurate way of saying timestamp "xx" is y packets from
now.

> is used (as is the case in RTP, for security reasons).

Yes, the fact that the first packet may be lost is the primary reason.
The first timestamp is usually known, but timestamps may be the same for
more than one packet.

> between the play response and the stream data packets.

Again, you don't necessarily know the number of packets that you expect
to receive before packets belonging to the next range are sent.

> race condition between stream data and the PLAY response.

I believe that  will not work. Lets say that the server has sent packets
65534, 65535, 0  to the client and they are between here and Europe. The
client sends a seek ,which results in a sequence number of 0 being sent.
There is no way to seperate out the two packets with sequence number 0.
Choosing a sequence number maximally distant from the last one ensures
that this problem does not occur.

I think the race condition is something we will have to tackle anyway,
either by forcing client buffering or adding a roundtrip somewhere.

--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : [email-masked]         Phone : (415) 937 3129
-----------------------------------------------------------------

---

From: Stephen Casner <[email-masked]>
Date: Tue, 26 Aug 1997 18:51:42 -0700 ()

Philipp,

>           originated after the seek.

It was suggested in Munich that this be changed to the PAUSE response
(giving the last sequence number before pause) in order to reduce
delay.  I prefer that to the other variation suggested which was to
have the client tell the server what sequence number to use.  See my
explanation below.

The motivation is not for the initial PLAY, but for the scenario where
the user moves a position slider and then resumes play.  In an ideal
world with no delay, I would think the media should just keep playing
continously and the client would not really care where the boundary
was.  However, with network delay, folks from PN said they wanted the
media to freeze when you move the slider bar, then resume, after
buffering delay, with playout of the first packet after the
repositioning.  (There might need to be an implicit PAUSE command for
the above suggestion to work.)

> started at, and it also knows the clockrate of the stream.

For constant rate audio in constant size packets that might be true,
but not for most video codings.

> is used (as is the case in RTP, for security reasons). 

No, I don't think the randomized initial sequence number matters.  You
might want to know the binding between RTP timestamp and NPT to be
able to update the position slider.  That mapping could be given
explicitly since the initial RTP timestamp is also prescribed to have
a random offset.

> way for the client to find out that the first second of the 

You would need to know the initial sequence number.  However, here's
the point I want to make with this message:

    I contend that a playback stream with pauses and seeks should look
    to the RTP receiver just like a silence-suppressed live stream
    would look.  That means:

      - The sequence numbers should be kept contiguous across pauses
	and seeks so that the loss measurement functions of RTP can
	work.  That is, a gap in sequence numbers indicates a loss.

      - The advancement of the RTP timestamp should reflect the
	progress of real time at the server.  That is, during a pause,
	the RTP timestamp should keep ticking along with real time,
	and during a seek without a pause, the RTP timestamp should
	progress contiguously across the seek (no gap).  This avoids
	introducing shifts into the mapping between the server RTP
	timestamps and the local playout clock timestamps so that the
	playback point adaptation can work continuously.

This means that the mapping between RTP timestamp and NPT changes
during a pause and so it might have to be communicated explicitly at
each play.  The idea is that this mapping is a UI issue only, and not
a media playback issue.  That is, let the RTP streaming mechanism work
as it is supposed to, and handle the deviations introduced by control
operations at the control level.

> between the play response and the stream data packets.

If you do want to freeze the display immediately at the client and
then resume playing only after the seek point, as the PN guy said,
then you would need to know the sequence number on the seek.  Sequence
number is preferred over RTP timestamp because the timestamp may not
be monotonic (for example with MPEG).

> transported in cleartext in RTSP. 

I don't remember the details of the attacks, but for at least some of
them, the number just needs to be unpredictable, not secret.

> its requests). Then again, I'm not a security expert.

The numbers could be made to start at zero, but above I have argued
that the mappings may need to be communicated after a pause or seek,
so they might as well be communicated initially also.
							-- Steve

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 27 Aug 1997 19:20:29 -0400

The only time the sequence number matters is with an 'interrupt' PAUSE
(pause *now*). Otherwise, you want all of the segments played
consecutively and there's no need to flush anything. Thus, it seems to
make sense to include the last seq. no. in the PAUSE response, as that's
the earliest opportunity to do so.

There are few other alternatives to using RTSP to signal the sequence #,
since messing with the sequence numbers, as Steve pointed out, does not
appear to be a good idea, marker bits are not reliable and timestamps
should be continuous.

For completeness, here are the RTP-based ones that I can see:

(a) Use several dynamic PTs for the same encoding and cycle through
these for each segment. Thus, you just drop the packets with the current
PT when you send a PAUSE. May not work well when codec changes
mid-stream.

(b) Use generation numbers as PN did (apparently), as an RTP header
extension. Adds overhead and requires standardization.

(c) Switch SSRCs for each segment. When pausing, drop all packets with
the current SSRC. This should work, but restarts receiver reports, as
these are per SSRC.

Can't say any of them is that attractive.

Henning
-- 
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

---

From: [email-masked] (Anup Rao)
Date: Thu, 28 Aug 1997 18:10:38 -0700

> the earliest opportunity to do so.

  Also desirable  for the very first PLAY, I think.  Marker bits or
timestamps will not always be enough to tell  whether the first packet
was received or not.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 29 Aug 1997 07:54:34 -0400

> timestamps will not always be enough to tell  whether the first packet

May be useful, but there really isn't a whole lot you can do until you
get the first packet, so knowing this information only makes the error
reporting slightly more accurate. The receiver better be prepared to
start playing at any instant; the mapping from TS to NPT will have to be
done within RTCP. While I see inclusion of this information in the PLAY
response as harmless (and easy), we shouldn't require it, since some
systems may not be able to get at this information easily.